Стадии, определенные ГОСТом

· Основные:

o Приобретение (действия и задачи заказчика, приобретающего ПО)

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

o Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)

o Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)

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

· Вспомогательные

o Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)

o Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).

o Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)

o Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)

o Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)

o Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)

o Аудит (определение соответствия требованиям, планам и условиям договора)

o Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)

· Организационные

o Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)

o Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)

o Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)

o Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

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

Этапы проекта в соответствии с каскадной моделью:

1. Формирование требований;

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

3. Реализация;

4. Тестирование;

5. Внедрение;

6. Эксплуатация и сопровождение.

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

· Полная и согласованная документация на каждом этапе;

· Легко определить сроки и затраты на проект.

Недостатки:

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

2. Эволюционная модель Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью.

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

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно.

Различают два подхода:

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

· Макетирование (прототипирование) – цель поэтапное уточнение требований к программному продукту.

Достоинства

· Спецификация может разрабатываться постепенно по мере того как пользователь (заказчик) осознает и сформулирует задачи.

· снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

· организация эффективной обратной связи проектной команды с потребителем (а также заказчиками, стейкхолдерами) и создание продукта, реально отвечающего его потребностям;

· акцент усилий на наиболее важные и критичные направления проекта;

· непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

· раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

· более равномерная загрузка участников проекта;

· эффективное использование накопленного опыта;

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

· затраты распределяются по всему проекту, а не группируются в его конце

Недостатки

· Многие процессы не документированы.

· Постоянные изменения в требованиях приводят к ошибкам в структуре ПО

3. Спиральная модель – классический пример применения эволюционной стратегии конструирования. Спиральная модель (автор Барри Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент — анализ риска, отсутствующий ранее.

На каждой итерации оцениваются:

· риск превышения сроков и стоимости проекта;

· необходимость выполнения ещё одной итерации;

· степень полноты и точности понимания требований к системе;

· целесообразность прекращения проекта.

Достоинства:

· Ускорение разработки (раннее получения результата за счёт макетирования)

· Постоянное участие заказчика в процессе разработки

· Разбиение большого объема работ на небольшие части

· Снижение риска (повышение вероятности предсказуемого поведения системы)

Недостатки:

· Повышенные требования к заказчику

· Трудности контроля и управления временем разработки

· Сложность планирования

· Сложность применения с точки зрения менеджеров и заказчиков

· Напряженный режим работы для разработчика

Проблема качества созданной системы

Веб дизайн