17. Модель пошаговой разработки по.

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

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

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

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

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

Достоинства данной модели:

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

2) Можно использовать компоненты, полученные на первых шагах разработки, как прототипы.

3) Уменьшается риск общей системы ошибок.

4) Поскольку системные сервисы с высоким приоритетом разрабатываются первыми, а последующие компоненты интегрируются с ним, получается так, что наиболее важные подсистемы подвергаются более тщательному тестированию и проверке

18. Спиральная модель разработки по.

Каждый виток спирали соответствует одной стадии (итерации), процесса создания ПО. Самый внутренний виток, соответствует стадии принятия решения о создании ПО. На следующем витке определяются системные требования (производится проектирование системы и т.д.). Каждый виток разбит на 4 сектора.

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

2. Оценка и разрешение рисков. Проводится его детальный анализ и планируется мероприятие для уменьшения или разрешения рисков.

3. Разработка и тестирование. После оценки рисков выбирается модель процесса создания систем.

4. Планирование. Анализируется сам проект если это решение положительное то разрабатывается план на следующую стадию проекта ежели нет то возврат на стадию назад.

Первая итерация создания ПО начинается с (Функциональной возможности, эксплуатационный показатель, и т.п.). Каждая альтернатива путей достижения этих показателей должна оценивать стоимость её достижения. Результаты анализа возможных альтернатив, служат источником оценки проектных рисков. Для оценки рисков используется более детальный анализ альтернатив, Прототипирование, моделирование, и т.п. С учётом полученных оценок рисков выбирается тот, или иной подход, к разработке компонентов и далее он реализуется, затем планируется следующий этап процесса создания ПО.