Модели традиционного представления о жизненном цикле

Общепринятая модель

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

• разработка,
• сопровождение.

Фазы разбиваются на ряд этапов (см. рис. 7.1).

увеличить изображение
Рис. 7.1. Общепринятая модель жизненного цикла программного обеспечения

В любой разработке программного обеспечения при управлении проектом надо отслеживать этапы, зафиксированные общепринятой моделью. Иное дело, что в ней этапы выстроены в порядке, который фиксирует их как последовательные непересекающиеся работы. Если попытаться спроецировать их на реальные процессы, становится очевидно, что фактический расклад чаще всего не соответствует схеме развития проекта. На это обращает внимание Брукс [ 7 ] , распространяя критику на все виды моделей жизненного цикла с последовательными этапами. Но если рассматривать общепринятую модель только как систематизацию, то она может быть хорошей основой для мотивированного обсуждения работ программного проекта, которые всегда должен отслеживать менеджер.

Разработка начинается с идентификации потребности в новом приложении, а заканчивается передачей продукта разработки в эксплуатацию.

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

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

В случае положительного решения начинается этап спецификации системы в соответствии с требованиями. Разработчики программного обеспечения пытаются осмыслить выдвигаемые заказчиком требования и зафиксировать их в виде спецификаций системы. Назначение этих спецификаций — описывать поведение разрабатываемой системы, а не ее внутреннюю организацию, т.е. отвечать на вопрос, что она должна делать, а не как это будет реализовано. Здесь говорится о назначении, а не о форме спецификаций, поскольку на практике при отсутствии подходящего языка спецификаций, к сожалению, нередко приходится прибегать к описанию "что" посредством "как"^{1Проблемы языка спецификаций не в том, что нельзя (или трудно) строго и четко описать, что требуется в проекте. В большей степени они связаны с необходимостью добиваться и поддерживать соответствие описания "что" нечетким, неточным и часто противоречивым требованиям со стороны внешних по отношению к проекту людей. Нет оснований полагать, что эти люди будут знакомы с "самым хорошим языком спецификаций", что они будут заботиться о корректности своих требований. Задача этапа спецификаций в том и состоит, чтобы описание программы выстроить в виде логически выверенной системы, понятной как для заказчика данной разработки и будущих пользователей, так и для исполнителей проекта.}. Прежде чем приступать к созданию проекта по спецификациям, они должны быть тщательно проверены на соответствие исходным целям, полноту, совместимость (непротиворечивость) и однозначность.

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

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

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

В некотором смысле понятия конструирования и декомпозиции противоположны: первое из них характеризует построение как создание чего-то из "деталей", тогда как второе есть разбиение будущей конструкции (дизайна) на составляющие. Все зависит только от точки зрения на проект. Декомпозиция предполагает будущее существование программной системы, построенной в соответствии со спецификациями, а потому использовать это слово, предполагая развитие архитектуры, не совсем правомерно. Таким образом, декомпозиция — это статичное понятие, отражающее фиксированность, заданность того, что должно быть построено, тогда как конструирование отражает динамику и подвижность, изменчивость и настраиваемость "конструкции".

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

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

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

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

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

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

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

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