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

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

На рис. 4.5. приведен процесс использования экспериментального прототипа для анализа требований.

Рис. 4.5

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

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

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

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

Рис. 4.6

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

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

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

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

Риски прототипирования

Прототипирование позволяет уменьшить риски проекта, но имеет и свои собственные риски [19, 23]:

1.Заинтересованные в проекте лица могут принять работающий прототип за начальную версию системы.

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

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

Пользователи не должны забывать, что на этапе уточнения требований они должны думать, что они хотят видеть в системе, т.е. заниматься разработкой и анализом требований.

3.Пользователи системы могут использовать работающий прототип для определения характеристик качества системы.

Если при разработке прототипа использовались быстрые, но менее эффективные средства и алгоритмы, то соответствующей будет и его производительность.

4.Разработчики могут много сил и средств потратить на разработку прототипа.

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

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

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

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

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

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

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

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

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

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