Эволюционное прототипирование

В основе эволюционного прототипирования лежит идея разработки первоначальной версии продукта, ее пошаговой модификации вплоть до системы, соответствующей целям и требованиям проекта (рис. 4.6).

Такой подход сейчас является основой эволюционных моделей разработки программного обеспечения.

 

Рис. 4.6

Основные преимущества эволюционного прототипирования заключаются в том, что они позволяют:

1. Ускорить разработку программной системы. В некоторых случаях быстрая разработка и поставка системы, удобство и простота использования перевешивают факт ее функциональной неполноты.

2. Участвовать пользователям в процессе разработки. Взаимодействие пользователя с системой – это гарантии более полного учета их требований.

Проблемы эволюционного прототипирования возникают при разработке достаточно больших систем. Основная проблема – управление проектом. Если процесс разработки выполняется в соответствии с некоторой моделью, то для оценки выполнения работ на каждом этапе используются вехи и определенные контрольные артефакты. Прототипы могут изменяться так быстро, что создание контрольных элементов станет нерентабельным, и будет только задерживать проект.

2.4. Системные требования

Как уже было сказано системные требования – это более детальное описание требований пользователей, которое служит разработчикам в качестве базы для проектирования. Системные требования состоят из подробно сформулированного полного списка конкретных свойств и функциональности, которую должна иметь программная система. Каждое из этих требований должно идентифицироваться и отслеживаться по ходу разработки. Предполагается, что основная аудитория для системных требований – это разработчики, но пользователи также должны иметь возможность их понять или прокомментировать большинство из них, поэтому уровень детализации системных требований должен быть полным, но не чрезмерным.

Учитывая важность спецификации и различные группы ее читателей, основные требования к спецификации – это ясность и понятность.

Требования в спецификации могут быть записаны при помощи:

· структурированного естественного языка,

· языков описания программ,

· различных графических нотаций,

· математических спецификаций или специальных языков описания требований.

Структурированный естественный язык

Чтобы уменьшить неоднозначность естественного языка для спецификации требований используют его сокращенную форму, что позволяет сохранить выразительность и понятность языка и структурировать описание требований.

Для структурированности языка используют стандартизованные шаблоны (схемы) и четко определенную (в спецификации) терминологию. Стандартные формы описания функциональных требований, например, должны содержать:

· описание объекта или функции;

· описание входных и выходных данных их источников и приемников;

· предусловия и постусловия функции;

· побочные эффекты и т.д.

Стандартные схемы (шаблоны) спецификаций будут рассмотрены в следующем разделе.

Языки описания программ

Дальнейшее уточнение описаний возможно путем ограничения и формализации действий, структур данных и управления, используемых в структурированном естественном языке.

Примером такого подхода является язык описания программ PDL (program description language). Этот язык строится по образцу языков программирования, управляющие операторы которых определяют:

· внешний синтаксис, т.е. описание структуры управления;

· внутренний синтаксис – описание структур данных и процедур их обработки – не определен и выбирается проектировщиком.

С одной стороны такой подход позволяет использовать в описании предложения, написанные на естественном языке, для повышения читаемости требования. С другой – использовать конструкции известных языков программирования и проверять синтаксис и семантику требований существующими программными средствами. Очевидно, что такой подход позволяет получить очень подробные и детальные требования, которые будут доступны для понимания ограниченному числу пользователей спецификации.

Пример 4.4.

Если использовать в описании процесса на PDL предложения, написанные на естественном языке, то описание будет достаточно простым для понимания. На рис. 4.7 приведено описание процесса «Принять программу в архив», рассмотренного в разделе 3.

Рис. 4.7

Графические нотации

Для описания требований применяются различные графические нотации. Наиболее часто используются уже рассмотренные графические средства: диаграммы потоков данных, модели конечных автоматов, диаграммы “сущность-связь”, сценарии, варианты использования, диаграммы использования, диаграммы состояний и диаграммы последовательности UML.

2.5. Документирование системных требований

Документирование системных требований завершает их разработку и заканчивается созданием единого документа – спецификации системных требований, – описывающего все функциональные и нефункциональные системные требования. В связи с тем, что системные требования – основа для проектирования системы и предназначены для разработчиков, то уровень их описания может быть значительно более подробным. Основные требования к спецификации системных требований – это ясность и прослеживаемость требований.

3. Анализ спецификации требований

3.1. Оценка качества спецификации требований

Учитывая важность спецификации и различные группы ее читателей, к ней предъявляются противоположные требования. С одной стороны, она должна быть простой, ясной и понятной пользователю неспециалисту, а с другой, для разработчика, – точной, подробной и формальной.