ВВЕДЕНИЕ
Проекты разработки программного обеспечения неизменно работают лучше, когда требования тщательно документированы, спроектированы и разработаны. Однако во многих случаях пользователи и заинтересованные стороны проектов не совсем ясно выражают свои требования к продукту (Jones, 1997). Сложность визуализации конечного продукта делает задачу по сбору и документированию всех требований к программному продукту сложной, если не откровенно трудной. Без четкой и полной документации требований разработчики часто должны строить полную, сложную систему, исходя из единственного представления о продукте, которое обычно имеет какое-либо реальное значение для пользователя, — вездесущего списка функций. Этот список – который, будем надеяться, находится в предложении по проекту – становится де-факто описанием нового или обновленного программного продукта.
Но даже полная, утвержденная документация требований часто упускает элементы, критически важные для успеха программного проекта. Требование может быть просто предположено заказчиком, могло быть рассмотрено, но не задокументировано, или в начале проекта просто было неизвестно. Пропущенные требования могут быть обнаружены в процессе сборки или тестовом цикле. К сожалению, некоторые требования остаются совершенно необнаруженными до тех пор, пока продукт не выпущен или не внедрен, и терпит неудачу или оказывается серьезно дефектным при первом использовании из-за «ошибок», некоторые из которых на самом деле могут быть пропущенными требованиями.
Хотя возможно и даже вероятно упустить некоторые функциональные требования к продукту, основная часть действительно пропущенных требований лежит за пределами сферы функций/возможностей программного продукта (Leffingwell and Widrig, 2003). Такие факторы, как производительность продукта, пределы нагрузки, целевые среды установки и применимые стандарты, обычно не считаются основными требованиями к программному продукту, но играют ключевую роль в его успехе (или провале). Хотя хорошая и хорошо структурированная документация требований охватит многие из этих экологических требований, те, что пропущены на этапе требований, часто остаются пропущенными и при выпуске продукта. В той мере, в какой они действительно являются требованиями для успеха продукта, их раннее обнаружение в проекте может быть критическим фактором успеха, помогая создать проект разработки ПО «в срок и в рамках бюджета», который оправдывает ожидания как заказчика, так и заинтересованных сторон.
Различные методологии – объектно-ориентированная, спиральная (Boehm, 2000), унифицированная разработка, экстремальное программирование (Jeffries, 2001) и многие другие жизненные циклы разработки (Kay, 2002) – по-разному решают вопрос детализации требований, и хотя они обычно не сосредоточены на управлении требованиями, признают важность базовых требований. Независимо от выбранной методологии, распознавание важных требований на поздних стадиях жизненного цикла продукта влечет за собой дорогостоящие последствия.
В этой статье мы рассматриваем фундаментальные элементы требований проекта и предполагаем, что всеобъемлющий план тестирования обеспечит среду для определения и классификации более полного списка требований, выходящего за рамки обычно используемой функциональной ориентации. Это усиление акцента на плане тестирования будет использовано, чтобы помочь нам понять ключевые сильные и слабые стороны типичных методологий требований. Мы предлагаем заполнить шаблон плана тестирования, который должен позволить менеджеру разработки ПО лучше понять полные требования программного проекта, выходящие за рамки функциональных требований, — и, таким образом, привести к более успешным проектам
ОБЩИЕ ТРЕБОВАНИЯ К ПРИЛОЖЕНИЯМ
Отправной точкой нашего исследования является определение «требований». Типичное использование этого термина требование — это «утверждение о потребности, нечто, что хочет какой-то класс пользователей или других заинтересованных сторон» (Alexander and Stevens, 2002). Другое определение требований предлагают авторы по инженерии требований Дорфман и Тайер (1990) в двух частях:
- Возможность программного обеспечения, необходимая пользователю для решения проблемы или достижения цели.
- Возможность программного обеспечения, которая должна быть удовлетворена или possessed системой или компонентом системы для соответствия контракту, стандарту, спецификации или другому формально наложенному документу.
В обоих этих определениях основной акцент делается на функциональности программного продукта, тех функциях, которые удовлетворяют потребности пользователя. Александр и Стивенс (2002) далее определяют функцию как «... нечто, что система или подсистема делает, предположительно потому, что требование сделало это необходимым». Они также заявляют, что часто используемый термин «функциональное требование» «на практике ... означает то же самое, что и функция».
Обратите внимание, что вторая часть определения требований Дорфмана и Тайера (1990) выходит за рамки потребностей программного продукта, переходя в «контракт, стандарт, спецификацию или другой формально наложенный документ». Как правило, именно в этих документах – контрактах, стандартах, спецификациях и т.д. – будут найдены скрытые или пропущенные требования. Конечно, мы можем упустить функциональные требования, но именно в области формы, соответствия, отделки и интеграции мы с большей вероятностью упустим требования проекта, и именно в «тестировании» этих менее документированных требований процесс создания плана тестирования может помочь выявить пропущенные требования проекта.
Уоттс Хамфри (1990) ссылается на неизвестные требования и позднее неправильно понятые требования. Неправильно понятое требование часто записывается, но ему не хватает некоторого контекстного ссылки, которая позволила бы полностью понять требование.
Почему нас должны волновать эти другие требования, которые не влияют напрямую на функциональность приложения? Просто: соответствие второму классу требований является предпосылкой для принятия проекта. Невыполнение спецификации может препятствовать оплате проекта. Может потребоваться доработка для выполнения стандарта. Пропуск установленной контрактом даты поставки может сократить оплату и/или повлечь штрафы за просрочку поставки со стороны поставщика. Очевидно, что в наших интересах как менеджеров проектов полностью понимать все требования проекта и, делая это, снижать риск пропуска или неверного толкования любых требований. Мы предполагаем, что эти требования не будут забыты, если всеобъемлющий план тестирования будет включен в фазу определения требований.
Требования бывают разных форм, и четкое, всестороннее понимание всех требований проекта является предпосылкой для всеобъемлющего плана тестирования. Рассматривая широко, мы можем классифицировать требования по крайней мере на шесть различных типов.
Функциональные требования- Что приложение должно делать. Функциональные требования являются самыми базовыми из всех требований к программному обеспечению и проекту, и многие книги и статьи, включая «Managing Software Requirements» (Leffingwell and Widrig, 2003) и «Writing Better Requirements» (Alexander and Stevens, 2002), были написаны на эту тему. Проще говоря, функциональные требования программного продукта должны давать ответ на вопрос: «Что должен делать программный продукт?», чтобы быть успешным приложением. Этот, казалось бы, простой вопрос становится все более сложным по мере вовлечения большего числа заинтересованных сторон и пользователей в процесс требований. Функциональные требования могут и часто конфликтуют друг с другом. Примером потенциального конфликта требований может быть: «простота в использовании» и «полнота функций».
Собрав все требования, может и должен быть процесс разрешения конфликтов требований, чтобы, где это возможно, мы сформировали функциональные требования в наилучший возможный пакет. Например, учитывая упомянутые ранее требования «богатый функционал» и «простота использования», может быть введено новое требование под названием: «разрешить настраиваемые уровни пользователя», чтобы разрешить кажущийся конфликт требований. В других случаях некоторые функции могут быть просто отброшены как избыточные в ходе всестороннего обзора требований.
Поскольку практически все усилия по разработке программных продуктов имеют ограничения по ресурсам, менеджеры программных продуктов обычно разделяют функциональные требования на «потребности» и «желания». Балансирование потребностей, желаний, даты/времени поставки и затрат по проекту является самой сутью управления программными проектами
Если мы упускаем требования или приоритеты требований, процесс выбора критически важных функциональных требований должен быть flawed, поскольку у нас нет всей информации, необходимой для полностью информированного выбора. Но здесь заключается важность создания плана тестирования, который мог бы определить все приоритеты требований для успешного программного проекта.
И предполагая, что у нас есть полный набор требований, полностью ли они поняты? В конечном счете, существует тест для хороших требований – сами ли они тестируемы? Использование подхода плана тестирования может улучшить процесс функциональных требований, обеспечивая большую точность требований, т.е. их тестируемость. Хорошая тестируемость функциональных требований – это важный вклад в процесс требований, помогающий выявить неоднозначности в функциональных требованиях.
Архитектура приложения – Как это подходит? Требования к программной архитектуре и среде обычно касаются целевой вычислительной среды для программного продукта. В идеале эта информация включается в требования проекта, и, к счастью, в большинстве случаев это так. Однако полные последствия целевой среды могут не учитываться, особенно для некоторых статистических выбросов в целевой среде. Примером может служить цель – определенный класс рабочих станций, только чтобы обнаружить на этапе внедрения, что не все отделы имеют указанное или ожидаемое оборудование. И, что еще хуже, какой-то другой обязательный к использованию программный пакет препятствует обновлению их оборудования.
Если это требование к архитектуре включено в план тестирования, то «пропущенное» требование здесь может быть легко исправлено на раннем этапе цикла разработки, вместо того чтобы быть обнаруженным на более поздних этапах внедрения, что вызвало бы серьезные и дорогостоящие задержки развертывания и/или переделку приложения для адаптации к «требуемой» конфигурации оборудования.
Требования окружения – Где это будет работать? Факторы окружения могут следовать по схожему пути: быть включенными в той или иной форме в первоначальные требования проекта, но оставаться неполными в каком-то критическом отношении ко времени бета-тестирования и/или внедрения. Ссылаясь на список целей проекта Майерса (Myers, 2003), эффективность приложения, совместимость, безопасность и несколько атрибутов надежности можно классифицировать как особенности или требования окружения программных приложений.
В конечном счете, эта ветвь дерева требований проекта является наиболее продуктивной областью для спецификации в плане тестирования, особенно поскольку наши вычислительные среды становятся все более сложными (Schneberger, 1995). Преднамеренное включение или исключение конкретной среды для программного продукта в наш план тестирования будет представлять собой известное и учтенное требование. Планы тестирования программного обеспечения, которые четко указывают «включенные» и «исключенные» факторы окружения, помогают сосредоточить внимание на этой области.
Аппаратные и программные стандарты – Соответствует ли оно стандартам? Стандарты представляют собой абстракцию аппаратных и программных операционных сред. Указание применимых стандартов для любого программного продукта должно быть частью требований проекта (Patton, 2001), и большинство шаблонов инженерии требований предусматривают цитирование применимых стандартов. Практически ни один программный продукт не существует без какого-либо стандартного контекста, если уж на то пошло, целевой операционной системы (систем). Когда никакие стандарты не указаны или не признаны, проект разработки программного обеспечения находится под угрозой, так как любое изменение цели развертывания вне среды разработки может рассматриваться либо как неудачная реализация, либо как неконтролируемое изменение требований проектa.
Указание применимых аппаратных/программных стандартов снизит факторы риска проекта. Таким образом, использование стандартов в требованиях проекта необходимо для надежного проекта разработки программного продукта.
Надежный план тестирования выполняет две ценные функции в области соответствия. Во-первых, это проверка того, что программный продукт действительно соответствует своим целевым стандартам. Во-вторых, типичные надежные планы тестирования и связанные с ними тестовые случаи будут подталкивать границы требований соответствия, чтобы определить, как приложение реагирует за пределами стандартных настроек. Обычно называемые тестами на граничные условия, план тестирования и соответствующие результаты тестов могут помочь менеджерам продукта понять, как программный продукт работает при применении вне требуемого стандарта.
Функциональные атрибуты – Удовлетворяет ли оно вторичные группы пользователей? Существует целый ряд других функциональных требований для успеха программных продуктов, многие из которых не специфически идентифицированы целевой группой пользователей для конкретного продукта. Основное внимание большинства наборов требований сосредоточено на функциональности, необходимой для того, чтобы вызвать интерес у конкретной группы(п) пользователей к покупке, переходу на или иному принятию конкретного пакета приложений. Но есть вторичные группы пользователей, на которых это повлияет – и у них есть свои собственные требования. Их набор функциональных требований слишком часто упускается из виду в процессе требований.
В этой области подходят несколько других «Целей продукта» Майерса (Myers, 2003), включая документацию, эффективность, установку и несколько атрибутов надежности. При работе с шаблонами требований высокого уровня эти области часто действительно будут затрагиваться – по крайней мере, у них может быть заголовок раздела в документе требований. Но слишком часто они просто рассматриваются на высоком уровне и поэтому теряются по мере развертывания проекта разработки ПО.
Расплывчатые и неоднозначные требования к эффективности и надежности могут легко потеряться в процессе проектирования приложения. Документация по продукту слишком часто прикрепляется к проектам разработки ПО или – что еще хуже – полностью исключается, приносятся в жертву для снижения затрат по проекту, сокращения начального цикла разработки продукта или чтобы позволить включить больше функциональности в продукт. Если требования к эффективности, надежности и документации не четко сформулированы и не являются частью плана тестирования программного продукта, весьма вероятно, что они также могут оказаться пропущенными, когда продукт будет доставлен заказчику.
Точно так же программные продукты, которые устанавливаются в общей среде (например, на рабочей станции конечного пользователя) и которые либо вызывают сбой другого приложения, и/или сами «повреждаются» установкой другого программного пакета, являются низкокачественными и ненадежными. Если мы не создаем truly turn key аппаратно-программные приложения, возможность установки приложения должна быть частью плана тестирования.
Роль плана тестирования в этой области имеет наибольшую вероятность выявить пропущенные требования. Планы тестирования или тестовые сценарии, изображающие использование вторичными группами пользователей, могут указать на glaring holes в требованиях к продукту. Надежные планы тестирования будут рассматривать программный продукт со всех точек зрения: основные пользователи, вторичные пользователи, продвинутые пользователи и случайные пользователи. Все эти сценарии и соответствующие тестовые случаи могут дать как представление о пропущенных или потенциально пропущенных требованиях, так и обеспечить проверку существующих функций, включенных в требования.
Требования к безопасности продукта и системы – Безопасно ли это? Безопасность в некотором отношении похожа на предыдущую группу тем, что она является как функциональной, так и необходимой для большинства программных приложений. Функциональный аспект заключается в том, что большинство программных приложений должны учитывать и обеспечивать безопасность приложения и данных. Однако требование проекта здесь немного шаткое – должно ли приложение обеспечивать безопасность? Или среда, в которой работает приложение, т.е. операционная система?
Конечно, мы можем считать безопасность приложения и данных функциональной – функцией, которую приложение должно предоставлять. Это можно считать окружением – некоторой комбинацией функциональности приложения и функций операционной системы может сделать приложение «безопасным». Или даже функциональным требованием вторичной группы пользователей – безопасность является ответственностью системного администратора, а не основного пользователя приложения. К сожалению, если оставить это в любой из этих категорий, возможности безопасности могут оказаться недостаточными до поздних, возможно, очень поздних стадий цикла разработки. Требования безопасности особенно важно хорошо знать и хорошо понимать на ранних стадиях цикла разработки.
Безопасность – это еще одна область, где план тестирования может помочь выявить как комплексные потребности в безопасности программного продукта. Особый атрибут вычислительной безопасности заключается в том, что функциональное требование довольно легко сформулировать – приложение и его данные должны быть защищены. Мы можем даже перейти к определению некоторых атрибутов – данные должны быть доступны тем, кому это нужно, но не тем, кому не нужно. Детальные планы тестирования, включающие методы атаки на приложение, могут быть значительным подспорьем в процессе проектирования приложения для выделения различных возможностей атаки на приложение и данные, которые проекты могут не учитывать до слишком поздних стадий проекта разработки или слишком поздно после успешной атаки на данные выпущенного приложения.
ПЕРСПЕКТИВА ПЛАНА ТЕСТИРОВАНИЯ – ПРОВЕРКА ФУНКЦИОНАЛЬНОСТИ, ПОИСК ДЕФЕКТОВ
Мы можем применить всеобъемлющий план тестирования, определяя все требования в этом плане тестирования на этапе инженерии требований. Этот подход снижает вероятность того, что пропущенные требования будут обнаружены поздно в процессе разработки, когда их исправление обходится дороже.
Использование контрольных списков является общепринятой практикой в большинстве формальных методологий разработки и является хорошо принятой техникой для обеспечения учета всех важных требований проекта в плане разработки программного продукта. Процесс сбора функциональных требований генерирует список функций, который становится функциональным контрольным списком как для мероприятий по обеспечению качества программного обеспечения, так и для приемки пользователем. Сравнимый контрольный список плана тестирования может быть использован для разумной уверенности в том, что все требования проекта были учтены в плане проекта.
Функциональные тесты, отображенные прямо или косвенно на цели продукта и функциональные требования, часто будут составлять основную часть плана тестирования программного обеспечения. Безусловно, программный продукт должен соответствовать функциональным требованиям, чтобы быть приемлемым. Основная часть плана тестирования, скорее всего, будет направлена на классические области модульного тестирования, интеграционного тестирования [модулей], функционального/черного ящика и т.д. В основном, все эти тесты, конечно, необходимы и будут служить для проверки как дизайна приложения, так и подтверждения соответствия приложения функциональным требованиям.
Как только мы выходим за рамки функциональных требований, в плане тестирования требуются другие атрибуты программного продукта. Обычно называемые «системным тестированием» в документах плана тестирования, эти области с большей вероятностью поймают пропущенные требования к продукту. К сожалению, однако, в типичном жизненном цикле продукта эти тесты обычно не планируются до поздних стадий проекта, поскольку они обычно требуют функционирующего приложения для выполнения теста.
Это отнесение на поздние стадии жизненного цикла несет риск увеличения стоимости исправления и более высокой вероятности влияния на график поставки продукта. Но взгляд на программный продукт с точки зрения тестирования программного обеспечения дает другое видение, выходящее за рамки функциональных атрибутов продукта, как показано ниже на Рисунке 1. Вот почему так ценна четкая формулировка плана тестирования на раннем этапе.
Естественно, план тестирования, инициированный на ранней стадии цикла разработки продукта, должен идти в ногу с разрабатываемым приложением. По мере того как приложение прогрессирует через цикл проектирования, разработки, тестирования, изменения, повторного выпуска, повторного тестирования, будут открываться новые области для тестирования на системном уровне. Полный и хорошо разработанный план тестирования будет нуждаться в обслуживании так же, как и приложение, которое он проверяет, разрабатывается и поддерживается.
«Тестирование» программного приложения не обязательно ждать, пока приложение действительно заработает. Часть плана тестирования, созданного на этапе анализа, может иметь пункты для тестирования на каждом из следующих этапов. Требования, спецификации и дизайн приложения все поддаются тестированию, даже по документации.Проекты, использующие методы быстрой разработки приложений (RAD) или экстремального программирования (XP), фактически будут иметь тестируемое программное обеспечение раньше в жизненном цикле проекта.
Даже когда методы RAD и XP не используются, каждый результат работы проекта разработки ПО в некотором смысле тестируем. Если не другим методом, то путем проверки документации, требования отдельных компонентов системы могут быть протестированы с помощью анализа сценариев, чтобы увидеть влияние этих компонентов на большую систему. Простой пример: функция дизайна, которая позволяет веб-сервису ограниченное время, несколько секунд задержки, даже если интранет или экстранет медленно реагируют на запрос веб-сервиса. Если бы одна и та же служба использовалась многократно в одной транзакции, общее время отклика для транзакции могло бы превысить целевые показатели дизайна для транзакции. В этом случае мы можем «протестировать» транзакцию без построения какого-либо кода. Сравнение спецификаций дизайна с требованием или целью производительности достаточно, чтобы увидеть возможность сбоя транзакции.
