Аттестация требований. Экспертиза спецификации. Процесс экспертизы спецификации. Тестирование требований
Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности: экспертиза спецификации, прототипирование,
автоматизированный анализ.
Экспертиза спецификации требований позволяет эффективно выявить неполные и некорректные требования, требования неясные или неподдающиеся проверке, несогласованные и не тестируемые требования.
Неофициальные экспертизы проводится во время разработки спецификации, знакомства с продуктом и не носят регулярный характер.
Официальная проверка – это документированный процесс, завершением которого является отчет, содержащий мнения рецензентов о приемлемости спецификации.
Процесс экспертизы:
Планирование - Председатель (координатор) совместно с автором спецификации определяют число и состав участников, материалы, которые должны получить эксперты до первого совещания, количество совещаний, темп проведения экспертизы.
При подготовке к встрече эксперты анализируют спецификацию с целью определения возможных дефектов, используя списки типичных дефектов. Этот этап очень важен, т.к. большинство дефектов определяется на нем.
На совещании автор знакомит экспертов с каждым требованием спецификации, перефразируя их своими словами. Цель совещания выявить как можно больше ошибок. При обсуждении дефектов и других проблем они заносятся в протокол. В заключение совещания принимается решение: принять спецификацию без изменений, с незначительными изменениями или значительно ее переработать.
После выявления дефектов, автор спецификации перерабатывает ее с учетом сделанных замечаний.
На этапе обработки результатов экспертизы председатель совместно с автором должны убедиться, что все проблемы разрешены, а ошибки исправлены.
Экспертиза спецификации требований – это просмотр документа, для которого не требуется компьютер. Тестирование – процесс динамический, который выполняется на компьютере, и поэтому может быть применен только для функциональных требований.
Для того, чтобы представить себе, как будет в определенных условиях вести себя система, нужно на основе требований, записанных в спецификации, разработать варианты тестирования. Варианты тестирования – это еще один способ анализа и выявления дефектов требований. Варианты тестирования, разрабатываемые совместно разработчиком и пользователем, позволяют не только выработать общее понимание работы продукта, но и будут незаменимы для оценки моделей, прототипов и требований.
Управление требованиями. Причины изменений требований. Принципы управления требованиями: базовая версия требований, процесс управления требованиями, контроль версий, идентификация отдельных требований, статус требования.
Практика показывает, что требования к разрабатываемой программной системе постоянно изменяются. Это обусловлено тем, что проектирование системы довольно длительный процесс, во время которого:
- понимание пользователями возможностей системы, решаемых ею задач, может измениться;
- происходят изменения в деловой среде, техническом, программном (и т.д.) обеспечении системы, которые должны быть учтены;
- понимание разработчиками поставленных перед ними задач меняется.
Это приводит к негативному влиянию на качество продукта, увеличиваются затраты.
Для исключения негативного влияния изменений требований управлению требованиями должно быть уделукта, увеличиваются затраты.
Для исключения негативного влияния изменений требований управлению требованиями должно быть уделено достаточно большое и серьезное внимание.
Под управлением требованиями понимают все действия, направленные на поддержание целостности, точности и актуальности спецификации требования в процессе проектирования: управление изменениями и версиями спецификации, контроль состояния требования и его взаимосвязи с другими требованиями и элементами системы.
К действиям по управлению требованиями относятся:
1. Определение основной (базовой) версии спецификации требований для конкретной версии продукта;
2. Анализ предлагаемых изменений требований, оценка воздействия и стоимости каждого изменения до его принятия;
3. Включение одобренных изменений при помощи определенной процедуры;
4. Согласование плана проекта с требованиями;
5. Отслеживание отдельных требований от проектирования до кода приложения и его тестирования;
6. Отслеживание статуса требований и действий по изменению на протяжении всего проекта.
Базовая версия требований.Под базовой версией спецификации понимается спецификация требований, содержащая набор функциональных и нефункциональных требований, которые разработчики обязались реализовать в определенной версии продукта. Базовая версия проходит процесс разработки и согласования
Процесс управления требованиями.В организации (или проекте) должны быть определены действия по управлению требованиями. Эти действия должны быть задокументированы и выполняться всеми участниками проекта.
Контроль версийпредполагает, что каждый участник проекта должен иметь доступ к текущей версии спецификации и других документов. Каждая версия спецификации должна иметь уникальное имя и содержать историю переработки, описывающую кто, когда, по какой причине внес изменение.
Идентификация отдельных требований.Минимальной единицей управления в спецификации требований является отдельное требование, поэтому вопрос идентификации требования достаточно важен.
Статус требования.В процессе выполнения проекта требование, обычно, изменяет свое состояние от начального («предложено»), до конечного, например, «реализовано». Статус требований позволяет оценить степень готовности проекта.