Материал: DO178 Учебное пособие_в183

6. Прототипная модель

Прототипная (prototyping) модель (Рис. 12) начинается с составления плана, после чего делается его быстрый анализ, создание некоторой базы данных, где будут копиться все данные о проекте и его рабочих продуктах, разрабатывается пользовательский интерфейс и после него разрабатываются прототипы, реализующие те функции, которые определяются спецификациями. Эти прототипы несколько раз совершенствуются, и дополняются новыми, которые реализуют все большее количество функций или реализуют их во все большем объеме.

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

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

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

Рис. 12. Прототипная модель

7. Выбор модели жизненного цикла

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

1. Доступность ресурсов: низкая или некоторая – ресурсы нельзя оценить или они недоступны; высокая – ресурсы можно определить, и они доступны.

2. Сложность проекта: низкая – все критерии сложности низкие; средняя – критерии сложности смешаны: 1-2 высокие, 1-2 низкие; высокая – все критерии сложности высокие.

3. Стоимость приложения: низкая – оценка меньше некоторой суммы; средняя – оценка равна этой сумме; высокая – оценка больше этой суммы.

4. Стоимость будущих обновлений: низкая – оценка меньше некоторой суммы; высокая – оценка стоимости больше этой суммы.

5. Дискретное изменений требований: малое – задевает не более 5 интерфейсов и включает не более 10 процессов; большое – задевает более 5 интерфейсов и включает более 10 процессов.

6. Легкость в использовании: просто – фазы и поставки понятны, процесс сфокусирован на разработку, а не на поддерживающие процессы; сложно – поддерживающие процессы требуют управления, наряду с разработкой.

7. Функциональные потребности приложения: смутные – трудно определимые; разработчики формулируют их сами; специфицированные – хорошо определены, если они измеряемы и тестируемы.

8. Постепенное изменение требований: малое – задевают небольшой объем системы; большое – требуют пересмотра большого числа интерфейсов.

9. Время жизни приложения: краткое – краткосрочное решение, например, на несколько дней; среднее – от 3 до 5 лет; долгое – более 5 лет.

10. Технология производства продукта: существующая – современная технология, уже применявшаяся разработчиками; новая – технология, ранее не применявшаяся данными разработчиками.

11. Отдача приложения: низкая – результаты анализа стоимость/выгоды меньше заданного значения или если выгоды несущественны; высокая – результаты анализа стоимость/выгоды больше заданного значения.

12. Качество результатов: сразу – нужное качество достигается с первого раза; переработка – для достижения нужного качества требуются переделки.

13. Изменчивость требований: низкая – требования изначально хорошо заданы и стабильны; средняя – минимальные изменения в требованиях допустимы; высокая – при высокой изменчивости эффект движущейся мишени.

14. Повторное использование продуктов и документации: низкое – возможность использования продуктов из других реализаций ограничена; высокое – предполагается их использование в интеграции и тестировании.

15. Перспективы управления рисками: нет – не рассматривается; да – управление рисками должно быть включено в данный ЖЦ.

16. Неопределенность требований: нет – требования определены и предсказуемы; да – есть неопределенность, и ЖЦ должен это учитывать.

17. Неизвестные требования: нет – все требования выявлены; да – некоторые требования могут быть упущены.

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

Табл. 4. Матрица выбора модели ЖЦ

Если сравнивать по легкости в использовании (критерий №6), то просто используемыми являются модели водопадная, быстрой разработки приложения (RAD), V-образная и прототипная, а более сложными – пошаговая и спиральная. Если же сравнивать по сложности проекта (критерий №2), то водопадная и V-образная модели подходят только для проектов с низкой сложностью, модели быстрой разработки приложения (RAD) и прототипная – для проектов средней сложности, а пошаговая и спиральная могут применяться и для проектов с высокой сложностью.

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

Подводя итог, можно дать следующие характеристики рассмотренным моделям жизненного цикла.

Водопадная модель подходит для небольших проектов с хорошо определенными требованиями и минимальным взаимодействием с заказчиком.

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

V-образная модель проста в использовании и в ней делается упор на тестирование через его сопряжение с разработкой; нисходящая и восходящая ветви процесса хорошо согласованы между собой.

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

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

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

Табл. 5. Комбинация моделей ЖЦ в разработке MS-DOS, версии 6.0

При разработке больших программных систем могут применяться разные модели жизненного цикла для разных ее компонентов, как это показано в Табл. 5 на примере разработки ОС MS-DOS, версии 6.0.

Этот пример показывает, что к выбору модели ЖЦ следует подходить творчески, учитывая особенности данного проекта, создаваемого в нем продукта и его подсистем.

5. Задания для самопроверки

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

Сформулируйте основные характеристики и критерии успешности для этого проекта.

Используя матрицу выбора ЖЦ, примите решение, какой ЖЦ или комбинация ЖЦ наиболее подходит для Вашего проекта, и обоснуйте Ваш выбор.

Определите набор метрик, которые должны собираться в Вашем проекте и дайте его обоснование.

2.Типовой каркас для разработки по

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

Рис. 13. Пример каркаса для процесса разработки ПО

Классический каркас по разработке программного обеспечения представлен на Рис. 13. Он является определенной структуризацией рассмотренной ранее обобщенной схемы процесса разработки (Рис. 6) и состоит из вложенных друг в друга групп взаимосвязанных деятельностей, каждая из которых в той или иной степени необходима для успешного создания программного продукта.

6. Программная разработка

Самой внутренней частью этой «матрешки» является собственно программная разработка (Software Development), состоящая из трех взаимосвязанных крупных групп деятельностей: Определять (Define), Разрабатывать (Develop), Сопровождать (Maintain).

Деятельности в группе «Определять» отвечают на вопрос «Что?» и состоят в основном в планировании проекта и сборе и анализе требований к нему. Результатом этих деятельностей является задокументированное четкое понимание исполнителем и заказчиком того, что именно предстоит создать в качестве результата данного программного проекта. Это понимание фиксируется в документах «Положение о работе», «Техническое задание», «План разработки» и «Спецификация требований», обязательно утверждаемых заказчиком.

Деятельности в группе «Разрабатывать» отвечают на вопрос «Как?» и включают в себя проектирование, кодирование, тестирование, документирование и выпуск продукта (сдачу его заказчику). Программный продукт создается в соответствии с полученными ранее ответами на вопрос «Что?» и принятыми решениями «Как?». Рабочими продуктами, создаваемыми в этой группе, помимо собственно программного продукта, являются его внутренняя и пользовательская документация в виде документов «Высокоуровневый проект», «Тестовые примеры и процедуры тестирования», «Руководство пользователя», «Руководство по установке» и других.

Наконец, деятельности в группе «Сопровождать» отвечают на вопрос: «Какие изменения?» и включают в себя действия по внесению изменений в уже работающий продукт и в конце его жизненного цикла вывод этого продукта из эксплуатации.

Обычно разработка «Положения о работе» (Statement of Work – SOW) или «Технического задания» (ТЗ) ведется до начала собственно разработки силами лиц, заинтересованных в запуске проекта, которыми могут быть как представители заказчика, так и будущие ключевые исполнители проекта. Контракт (договор) на исполнение разработки заключается уже после того, как готово SOW или ТЗ, которое включается в него как приложение. Типичная структура этих документов приведена в Приложении 1.51. Главное отличие SOW от ТЗ в том, что SOW описывает работу на более высоком уровне абстракции, чем ТЗ, и поэтому оно более компактно и менее трудоемко в своей разработке.

Важным шагом в определении работы является выявление структуры разбиения работ (Work Breakdown Structure – WBS), которая дает логическое разделение работ, исходя их структуры программного будущего продукта. Типичный верхний уровень WBS для разработки полной системы, состоящей из N подсистем, приведен на Рис. 14.

Рис. 14. Типичный верхний уровень структуры разбиения работ

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

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