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

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

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

Спиральная модель обладает следующими достоинствами:

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

2. Заказчики принимают активное участие в разработке ПП.

3. В модели воплощены преимущества каскадной и многопроходной моделей.

Недостатки спиральной модели:

1. Усложненная структура.

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

Использование спиральной модели целесообразно, если существует хотя бы одна из следующих причин:

1. Целесообразно создание прототипа.

2. Организация обладает навыками, требуемыми для адаптации модели.

3. Требуется выполнять проекты со средней и высокой степенями риска.

4. Заказчики не уверены в своих потребностях.

5. Требования слишком сложные.

6. Проект очень большой

20.Документы, создаваемые на этапах жц пп

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

Процесс документирования предусматривает: Формализованное описание информации созданные в течении Ж.Ц.П.П.

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

Процесс документирования включает в себя:

1. Подготовительная

2. Проектирование и разработка документации.

3. Выпуск

4. Сопровождение.

21.Кризис программирования и способ выхода из него

В начале 1970-х готов в США был отмечен кризис программирования. Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный ПП не обладал требуемыми функциональными возможностями, производительность его была низка, качество не устраивало потребителей.

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

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