Реферат: Сравнительный анализ каскадной и спиральной моделей разработки программного обеспечения

--PAGE_BREAK--Итерации по спирали
Спиральная модель разработки ПО, в тех или иных версиях используемая во множестве конкретных прикладных методик, построена на следующем шаблоне. Прежде всего в ходе общения с заказчиком определяется набор наиболее важных и критичных возможностей будущей системы. Далее совместными усилиями определяются желаемые сроки для реализации этой базовой функциональности. Формируется план, начинаются работы и отслеживается их выполнение.
В основу спиральной модели заложены две посылки. Многочисленными исследованиями подтверждено, что и заказчик и исполнитель обычно слишком оптимистично относятся к срокам и бюджету, даже при использовании хороших методик оценки объема работ (по функциональным точкам и т. п.). Поэтому результаты таких оценок предлагается увеличивать (ухудшать) достаточно серьезно — примерно на 50%. Кроме того, заказчик обычно слабо представляет архитектуру будущей системы, поэтому ее следует проектировать, закладываясь на открытые технологии и максимально гибкие возможности расширения и наращивания функциональности. Уточнение конкретных требований выполняется итерационно, при этом на каждом витке проектной спирали создается все более точная версия, соответствующая пожеланиям заказчика.
Шесть шагов спиральной модели

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

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

3. Согласовываются временные рамки проекта. Часто для этого применяются методики стоимостного прогнозирования. Далее исполнитель решает, сколько функциональных возможностей в соответствии с их приоритетами удастся реализовать в оговоренный срок.
4. На данном этапе определяются архитектура и ядро будущей системы. Это наиболее ответственный момент, так как здесь необходимо учесть пока еще не детализированные полностью требования к проекту — а они вполне могут быть противоречивыми.

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

Этот шаг выполняется, как правило, в два и большее число итерационных циклов.

5. Готовится план работ. Он ориентирован на сроки, определенные на третьем этапе, и нацелен на скорейшую реализацию ядра системы. Взаимодействуя с работающим прототипом, заказчик быстрее и точнее вырабатывает и уточняет дальнейшие требования и корректирует приоритеты.

6. Разработка системы в соответствии с планом.

Для этого этапа характерны три типичных класса проблем:

— изменения в требованиях к проекту;

— изменения параметров самого проекта (сроков, бюджета, качества);

— временные задержки, связанные с текущими вопросами (техникой, персоналом).

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

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


Этап планирования  и анализа требований
Цель:
— получение требований ;
— выработка производных от них требований для этапа оценки безопасности.
Входные данные:
— требования к системе, аппаратный интерфейс, архитектура системы;
— план разработки ПО;
— стандарты на требования к ПО.

Первичный результат — данные о требованиях.
Основные принципы:
— интерфейсные и функциональные требования к системе, реализуемые на базе ПО, должны быть проанализированы на предмет противоречий, несоответствия и неопределенности;
— неадекватные и некорректные входные данные должны быть направлены на выработавшие их подэтапы для разъяснения или исправления;
— каждое требование к системе, реализуемое на базе ПО, должно быть включено в требования;
— должны быть особо отмечены требования, соответствующие системным требованиям по предотвращению выхода системы из строя;
— требования  должны соответствовать стандартам на требования к ПО;
— требования  должны формулироваться в количественных терминах;
— требования  не должны описывать детали разработки или тестирования, за исключением указанных и проверенных ограничений конструкции;
— каждое системное требование, реализуемое на базе ПО, должно быть сводимо к одному или более требованиюУ к ПО;
— каждое требование, за исключением производных требований, должно быть сводимо к одному или нескольким системным требованиям;
— производные требования  должны быть направлены этапу оценки безопасности системы.
На этапе планирования разработки ПО создаются планы и выбираются стандарты, которые направляют этап разработки и интегрированный этап. Его целью является определение средств для создания ПО, которое будет удовлетворять требования, предъявляемые к нему и обеспечивать достаточный уровень надежности. На этом этапе производиться:
определение действий на этапах разработки и интегрированном этапе, которые будут посвящены определению системных требований и уровня ПО;
определение ЖЦ ПО, включая взаимодействие между этапами, механизм взаимного влияния этапов, критерии оценки ПО при переходе от одного этапа к другому;
определение среды ЖЦ, т.е. методы и инструментальные средства, используемые на каждом этапе;
формирование дополнительных замечаний к ПО;
рассмотрение стандартов разработки ПО, соотношение их с системными целями безопасности, относящиеся к разрабатываемому ПО;
разработка плана создания ПО;
доработка и проверка плана создания ПО.
Эффективность планирования — определяющий фактор при разработке ПО. Основные руководящие принципы этого этапа следующие.
1. План разработки ПО должен быть разработан в такой момент ЖЦ, чтобы обеспечить своевременное управление конкретными действиями на этапе разработки и интегрированном этапе.
2. Стандарты разработки ПО, используемые в проекте, должны быть строго определенными и четкими.
3. Выбранные методы и инструментальные средства должны быть такие, чтобы обеспечили предотвращение ошибок на этапе разработки или свели их к минимуму.
4. Этап планирования разработки ПО должен обеспечить координацию между остальными этапами с целью согласования их стратегий в плане разработки ПО.
5. Этап планирования разработки ПО должен включать в себя средства проверки плана на этапе реализации проекта.
6. На завершающей стадии этапа планирования, план и стандарты разработки ПО должны быть проанализированы на предмет полноты и непротиворечивости.
Другие этапы ЖЦ могут быть начаты до окончания этапа планирования при условии, что имеются планы и процедуры для действий на этих этапах.




    продолжение
--PAGE_BREAK--