12. Жизненный цикл по (жц). Структура жц, основные фазы жц.

ЖЦ ПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его изъятия из эксплуатации. Основным нормативным документом, который регламентирует ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO – Международная организация по стандартизации , IEC – Международная комиссия по электротехнике).

Этот стандарт определяет структуру ЖЦ, его фазы, действия и задачи, которые должны быть выполнены в процессе разработки и эволюции ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

1. Основные процессы:

   1. разработка;

   2. использование (сопровождение);

   3. эволюция (модификация).

Это 3 основные фазы жизненного цикла ПО.

2. Вспомогательные процессы:

   1. документирование;

   2. обеспечение качества ПО;

   3. верификация;

   4. аттестация;

   5. оценка;

   6. управление конфигурацией.

3. Организационные процессы:

   1. управление проектом;

   2. улучшение самого ЖЦ;

   3. обучение и другие

13. Организация процесса разработки пс (методы, средства, процедуры).

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

Методы обеспечивают решение следующих задач:

• планирование и оценка проекта;

• анализ системных и программных требований;

• проектирование алгоритмов, структур данных и программных структур;

• кодирование;

• тестирование;

• сопровождение.

Средства (утилиты) обеспечивают автоматизированную поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы, как уже отмечалось, принято сегодня называть CASE-системами (средствами, инструментами). (Аббревиатура CASE расшифровывается как Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).)

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

• порядок применения методов и утилит;

• формирование отчетов и форм по соответствующим требованиям;

• контроль, который помогает обеспечивать качество и помогает управлять изменениями;

• формирование сроков (говорят, “вех” (ага, может, ещё “эпох”, нэ?)), по которым руководители оценивают проект.

Поэтому процесс конструирования ПО состоит из последовательности шагов, использующих методы, утилиты и процедуры. Эти последовательности шагов часто называют парадигмами ТР ПО.

14. Модели процесса разработки пс (каскадная, спиральная)

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

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

Модель ЖЦ ПО включает в себя:

1. Стадии;

2. Результаты выполнения работ на каждой стадии;

3. Ключевые события — точки завершения работ и принятия решений.

В 1970 году Уинстон Ройс (компания TRW) предложил модель разработки, известную как модель “водопада” (или “каскадная” модель). Схематично ее можно изобразить следующим образом:

В модели “водопада” содержатся следующие усовершенствования строго “пошаговой” модели:

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

2. Появились петли обратной связи между этапами, т.е. есть возможность вернуться на этап выше, если необходимо.

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

4. Возросла роль анализа требований – они являются основой для проектирования и кодирования.

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

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

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

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

Недостатки:

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

Спиральная модель

Впервые эту модель предложил Боэм в 1988 году. Модель базируется на лучших свойствах классической модели и макетирования, к которым добавляется новый элемент – анализ риска. И еще появился новый этап – системный анализ.

Схематично спиральную модель можно изобразить следующим образом:

Итак, модель определяет 4 основных действия, которые представлены четырьмя квадрантами спирали.

1. Планирование – определение целей, требований, ограничений, а также составление плана разработки витка спирали (начиная со 2-го витка спирали, планирование проводится уже на основе оценки и рекомендаций заказчика).

2. Анализ риска (на 1-м витке спирали анализ риска на основе начальных требований, на следующих – на основе реакции заказчика).

3. Конструирование – разработка ПС (на 1-м витке – начальный макет, на 2-м – следующий уровень макета, на последнем – готовая система).

4. Оценивание – оценка заказчиком текущих результатов конструирования.

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

Достоинства спиральной модели:

• наиболее реально (в виде эволюции) отображает разработку ПО;

• позволяет явно учитывать риск на каждом витке эволюции разработки;

• использует моделирование для уменьшения риска.

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

• повышенные требования к заказчику;

• трудности контроля и управления временем разработки (практически трудно составить план перехода на каждый этап.