Жизненный цикл программной системы
Жизненный цикл программного обеспечения (ПО) – это период времени с момента принятия решения о необходимости создания программной системы до момента ее полного изъятия из эксплуатации.
Основным международным стандартом определения жизненного цикла ПО является ISO/IEC 12207:2008 «System and software engineering – Software life cycle processes» (российский аналог – ГОСТ Р ИСО/МЭК 12207—2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств). Наряду с ним в России применяется ГОСТ 34.601—90.
ГОСТ 34.601—90
Стандарт ГОСТ 34.601—90 был создан еще в СССР и предусматривает следующие стадии и этапы создания автоматизированной системы (АС).
1. Формирование требований.
– Обследование объекта и обоснование необходимости создания АС.
– Формирование требований пользователя к АС.
– Оформление отчета о выполнении работ и заявки на разработку АС.
– Разработка концепции АС.
– Изучение объекта.
– Проведение необходимых научно-исследовательских работ.
– Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей.
– Оформление отчета о проделанной работе.
2. Техническое задание – разработка и утверждение технического задания на создание АС.
3. Эскизный проект.
– Разработка предварительных проектных решений по системе и ее частям.
– Разработка документации на АС и ее части.
4. Технический проект.
– Разработка проектных решений по системе и ее частям.
– Разработка документации на АС и ее части.
– Разработка и оформление документации на поставку комплектующих изделий.
– Разработка заданий на проектирование в смежных частях проекта.
– Рабочая документация.
– Разработка рабочей документации на АС и ее части.
– Разработка и адаптация программ.
5. Ввод в действие.
– Подготовка объекта автоматизации.
– Подготовка персонала.
– Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).
– Строительно-монтажные работы.
– Пусконаладочные работы.
– Проведение предварительных испытаний.
– Проведение опытной эксплуатации.
– Проведение приемочных испытаний.
6. Сопровождение АС.
– Выполнение работ в соответствии с гарантийными обязательствами.
– Послегарантийное обслуживание.
Эскизный, технический проекты и рабочая документация – это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.
Данный стандарт не вполне подходит для проведения разработок в настоящее время: многие процессы отражены недостаточно, а некоторые положения устарели.
ГОСТ Р ИСО/МЭК 12207—2010
Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. принят стандарт ГОСТ Р ИСО/МЭК 12207—2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering – Software life cycle processes».
Данный стандарт, используя устоявшуюся терминологию, устанавливает общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии. Стандарт определяет процессы, виды деятельности и задачи, которые используются при приобретении программного продукта или услуги, а также при поставке, разработке, применении по назначению, сопровождении и прекращении применения программных продуктов.
Стандарт ГОСТ Р ИСО/МЭК 12207—2010 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Стандарт группирует различные виды деятельности, которые могут выполняться в течение жизненного цикла программных систем, в семь групп процессов. Каждый из процессов жизненного цикла в пределах этих групп описывается в терминах цели и желаемых выходов, списков действий и задач, которые необходимо выполнять для достижения этих результатов.
Группы процессов:
процессы соглашения – два процесса;
процессы организационного обеспечения проекта – пять процессов;
процессы проекта – семь процессов;
технические процессы – одиннадцать процессов;
процессы реализации программных средств – семь процессов;
процессы поддержки программных средств – восемь процессов;
процессы повторного применения программных средств – три процесса.
Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия.
Инициирование приобретения.
Подготовка заявочных предложений.
Подготовка и корректировка договора.
Надзор за деятельностью поставщика.
Приемка и завершение работ.
Каждое действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать:
Формирование требований к системе.
Формирование списка программных продуктов.
Установление условий и соглашений.
Описание технических ограничений (среда функционирования системы).
Модель жизненного цикла ПО – структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Она зависит от специфики, масштаба и сложности проекта и особенностей условий, в которых система создается и функционирует.
Модель ЖЦ ПО включает несколько стадий.
Стадия – часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.
На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207—2010, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.
Модели жизненного цикла ПО
Выделяют следующие возможные модели ЖЦ ПО:
– Водопадная
– Итерационная
– Спиральная
Водопадная (каскадная, последовательная) модель
Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Этапы проекта в соответствии с каскадной моделью:
Формирование требований;
Проектирование;
Реализация;
Тестирование;
Внедрение;
Эксплуатация и сопровождение.
Преимущества каскадной модели:
– полная и согласованная документация на каждом этапе;
– легко определить сроки и затраты на проект.
В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится возвращаться к ранней фазе проекта. В результате требуемая переработка приводит не только к нарушению графика, но и к существенному росту затрат.
По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем.
Итерационная модель
Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также название эволюционной модели.
Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение – инкремент – к его возможностям, которые, следовательно, развиваются эволюционно.
По выражению Т. Гилба, «эволюция – прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность „отката“ к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте».
Недостатки подхода IID:
– отсутствие целостного понимания возможностей и ограничений проекта на ранних итерациях;
– необходимость переделывать часть сделанной ранее работы;
– снижение добросовестности специалистов при выполнении работ (всё равно всё можно будет переделать и улучшить позже).
Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).
Спиральная модель
Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.
Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
На каждой итерации оцениваются:
– риск превышения сроков и стоимости проекта;
– необходимость выполнения ещё одной итерации;
– степень полноты и точности понимания требований к системе;
– целесообразность прекращения проекта.
Спиральная модель является усовершенствованным вариантом эволюционной модели (модели IID). Ее отличительной особенностью является специальное внимание, уделяемое рискам, влияющим на организацию разработки. Наиболее распространёнными являются следующие группы рисков.
– Дефицит специалистов.
– Нереалистичные сроки и бюджет.
– Реализация несоответствующей функциональности.
– Разработка неправильного пользовательского интерфейса.
– Перфекционизм, ненужная оптимизация и оттачивание деталей.
– Непрекращающийся поток изменений.
– Нехватка информации о внешних компонентах, определяющих окружение системы.
– Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
– Недостаточная производительность получаемой системы.
– Разрыв в квалификации специалистов разных областей.
Для преодоления рисков при реализации проектов предлагается использовать так называемые контрольные точки, характеризующие разные стадии готовности проекта.
– Concept of Operations (COO) – концепция (использования) системы;
– Life Cycle Objectives (LCO) – цели и содержание жизненного цикла;
– Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
– Initial Operational Capability (IOC) – первая версия создаваемого продукта, пригодная для опытной эксплуатации;
– Final Operational Capability (FOC) – готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.