Жизненный цикл по

Согласно стандарту IEEE 610.12, жизненным циклом ПО называется период времени, с момента принятия решения о необходимости создания ПО, до момента его полного изъятия из эксплуатации.

Разработка ПО как правило, включает:

1. Анализ.

2. Проектирования.

3. Реализацию.

После процесса реализация, идет тестирования, документирование и эксплуатация. Эксплуатация – включает в себя:

1. Работы по внедрению компонентов ПО в эксплуатацию.

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

Стратегия и модели конструирования по. Начальные этапы конструирования по. Стратегия и модели конструирования по

Стратегия конструирования ПО – определяет общий характер конструирования ПО.

Три основные стратегии конструирования:

1. Каскадная – линейная последовательность этапов конструирования.

2. Инкрементная стратегия – итерационное повторение проходов, с целью наращивания функциональности ПО.

3. Эволюционное стратегия – это инкрементная стратегия с постепенным уточнениям требований.

Каскадная стратегия

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

Схема каскадной разработки ПО:

Преимущества:

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

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

Недостатки:

1. Запаздывание с получением результатов.

2. Согласование результатов с пользователями возможно только после завершения какого-либо этапа работы.

3. Сложности с внесением изменений, при изменении требований.

Эволюционная стратегия

Эволюционная стратегия заключается в повторении процесса разработки ПО выпуском новой версии. К существующим этапам жизненного цикла разработки ПО добавляются этапы:

1. Планирования цикла

2. Анализ рисков.

Схема:

…

…

Преимущества:

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

2. Пользователи очень быстро могут увидеть работоспособную версию продукта.

3. Пользователи могут оперативно вносить уточнения в требования к продукту.

Недостатки:

1. Более сложный механизм управления и документирования процессом разработки.

2. Структура разрабатываемого программного обеспечения не всегда несет целостную идею.

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

В инкрементной стратегии не происходит переопределение требований.

24.09.2012.

Модель формальной разработки систем

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

Формальная спецификация записывается с помощью специальной математической нотации (последовательные действия):

1. Определение требований

2. Формальная спецификация

3. Формальное преобразование

4. Сбор и тестирование системы

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

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

Недостатки:

1. Большинство систем трудно поддаются описаниям методам формальных спецификаций.

2. Большой объем сопроводительной документации.