Введение в пи 9 лекция (10.11.11) Спиральная модель разработки по.

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

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

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

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

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

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

Спецификация программного обеспечения.

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

4 основных этапа разработки требований.

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

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

3. Специфицирование требований, осуществляется перевод всей совокупности информации, собранные на предыдущем этапе, в документ определяющий множество требований, этот документ как правило, содержит 2 типа требований, пользовательские – обобщённые представления заказчику и пользователей о системе. Детализированные – описывают функциональные показатели систем.

4. Утверждение требований. Проверяется выполнимость, согласованность и полнота множества требований,