Лекция 2. Жизненный цикл ПО. Процессы разработки ПО

Технологии программирования. Компонентный подход

Итак, как говорилось на прошлой лекции, «большую» программную систему построить «просто» невозможно. Ее разработка с неизбежностью будет тоже «большим», сложным предприятием.

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

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

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

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

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

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

Международными организациями, такими как IEEE (читается «ай-трипл-и», Institute of Electrical and Electronic Engineers, Институт инженеров по электротехнике и электронике), ISO (International Standards Organization, Международная организация по стандартизации), EIA (Electronic Industry Association, Ассоциация электронной промышленности), IEC (International Electrotechnical Commission, Международная коммиссия по электротехнике) а также некоторыми национальными исследовательскими институтами (ANSI, American National Standards Institute, Американский национальный институт стандартов; SEI, Software Engineering Institute, Институт программной инженерии), разработан набор стандартов, регламентирующих различные аспекты жизненного цикла ПО и вовлеченных в него процессов. Список и общее содержание этих стандартов таковы.

· Группа стандартов ISO

o ISO/IEC 12207 Standard for Information Technology — Software Life Cycle Processes (есть российский аналог ГОСТ Р-1999)
Определяет структуру процессов жизненного цикла ПО, которые, согласно ему, включают

§ Основные процессы:
Приобретение ПО, Передача ПО (в использование), Разработка ПО, Эксплуатация ПО, Поддержка ПО

§ Поддерживающие процессы:
Документирование, Управление конфигурациями, Обеспечения качества, Верификация, Валидация, Совместные экспертизы, Аудит, Разрешение проблем

§ Организационные процессы:
Управление проектом, Управление инфраструктурой, Усовершенствование процессов, Обучение

o ISO/IEC 15288 Standard for Systemы Engineering — System Life Cycle Processes
Отличается от предыдущего нацеленностью на рассмотрение систем в целом, т.е. программно-аппаратных систем.
В данный момент продолжается работа по интеграции этих двух стандартов.

o ISO/IEC 15504 (SPICE) Standard for Information Technology — Software Process Assessment
Определяет правила оценки процессов жизненного цикла ПО и их возможностей, опирается на модель CMMI (см. ниже) и ориентирован на оценку возможности улучшения процессов

· Группа стандартов IEEE

o IEEE Std 1074-1997 IEEE Standard for Developing Software Life Cycle Processes
Описывает структуру процессов разработки и сопровождения, а также связанных с ними, определяет основные виды деятельностей, выполняемых в рамках этих процессов и документы, требущиеся на входе и возникающие на выходе этих деятельностей.

o IEEE/EIA Std 12207-1997 IEEE/EIA Standard: Industry Implementation of International Standard ISO/IEC 12207:1995 Guide for Information Technology — Software Life Cycle Processes
Аналог ISO/IEC 12207, сменил ранее использовавшиеся
J-Std-016-1995 EIA/IEEE Interim Standard for Information Technology--Software Life Cycle Processes--Software Development Acquirer-Supplier Agreement
и стандарт министерства обороны США
MIL-STD-498

· Группа стандартов, связанная с моделью зрелости возможностей CMM (Capability Maturity Model)

o Собственно, модель CMM описывает различные степени зрелости процессов в организациях, определяя 5 уровней организаций

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

§ Уровень 2, повторяемый.
В таких организациях ведется учет затрат ресурсов и отслеживается ход проектов, установлены правила управления проектами, основанные на имеющемся опыте

§ Уровень 3, определенный.
В таких организациях имеется принятый, полностью документированный процесс разработки ПО, включающий как управленческие, так и технические подпроцессы.

§ Уровень 4, управляемый.
В этих организациях, помимо установленного и описанного процесса, используются показатели качества продуктов и процессов, позволяющие достаточно точно предсказывать объем ресурсов (времени, денег, персонала), необходимый для разработки продукта с определенным качеством

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

o CMMI
Результат интеграции моделей CMM для продуктов и процессов
http://www.sei.cmu.edu/cmmi/models/

В целом эти стандарты связаны следующим образом (стрелки указывают направления исторического развития).

Рисунок 1. Стандарты, описывающие структуры жизненного цикла ПО.

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

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

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

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

К последовательным моделям — в них предполагается, что работы разных видов выполняются в некоторой предписанной последовательности, т.е. что можно отождествить определенную фазу существования ПО с некоторой основной деятельностью, которая выполняется на этой фазе — относят так называемую водопадную (waterfall) модель, которая, как считается, была впервые четко сформулирована в работе [1] и впоследствии была принята как стандарт министерства обороны США в семидесятых-восьмидесятых годах XX века. Предлагаемая в этой статье последовательность шагов разработки выглядит так, как показано на рис. 1.

Рисунок 2. Последовательность разработки согласно «общепринятой» водопадной модели.

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

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

Расмотрим два основных примера итеративных процессов — это унифицированный процесс Rational (Rational Unified Process, RUP) и экстремальное программирование.