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

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

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

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

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

• разработка,

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

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

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

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

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

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

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

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

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

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

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

в таких сочетаниях: конструирование архитектуры, конструирование ди­зайна (это одно и то же) и даже конструирование декомпозиции.

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

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

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

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

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

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

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

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

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

Классическая итерационная модель

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

Таковы мотивы классической итерационной модели жизненного цикла (см. рис. 7.2).

Стрелки, идущие вверх, обозначают возвраты к предыдущим этапам, квалифицируемые как требование повторить этап для исправле­ния обнаруженной ошибки. В связи с этим может показаться странным переход от этапа «Эксплуатация и сопровождение» к этапу «Тестирование и отладка». Дело в том, что рекламации, предъявляемые в ходе эксплуата­ции системы, часто даются в такой форме, что нуждаются в перепроверке. Чтобы понять, о каких ошибках идет речь в рекламации, разработчикам полезно предварительно воспроизвести пользовательскую ситуацию у се­бя, т.е. выполнить действия, которые обычно относят к тестированию.

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

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

Безусловно, представленная идея становится реальностью лишь при условии, что у разработчиков программного обеспечения есть поддержка сохранения старого полезного кода, причем без потери эффективности. Такая поддержка сегодня почти повсеместно связывается с объектно-ориентированными методами программирования и проектирования. Бо­лее того, многие считают это чуть ли не единственным способом реализа­ции итеративного наращивания [8). Отдавая должное методике объект­ной ориентированности, а также разработке методологий поддержки ве­дения проектов в рамках этого подхода, стоит обратить внимание на то, что он вовсе не всеобъемлющ, как утверждают его апологеты. Так, разра­ботчики программных проектов, пользуясь им, вынуждены связывать се­бя множеством соглашений, без которых итеративное наращивание было бы просто непознаваемым. Помощь, которую оказывают объектно-ори­ентированные CASE-системы (например, [30]), достаточно очевидна, чтобы оспаривать ее. Однако приходится констатировать, что эти систе­мы либо заставляют разработчика оставаться в жестких рамках, которые появляются в результате проектных ограничений конкретных и не всегда хорошо сбалансированных частных решений, либо предусматривают привнесение средств, концептуально противоречащих идеологии подхо­да. Да и сами объектно-ориентированные языки можно упрекнуть в той же эклектике и противоречивости (подробнее об этом см. в [16]).

Итеративное наращивание имеет целью повышение гибкости систе­мы, обеспечение возможности ее адаптации к меняющимся требованиям к программе и условиям развития проекта. Можно сказать, что разбиение на итерации есть средство повышения адаптивности проекта, а потому проблема не в том, используются или нет для реализации итеративности объектно-ориентированные языки или CASE-системы, а в том, насколь­ко сам проект приспособлен к изменениям. Это в корне противоречит и традиционным методологиям, и объектным, если при использовании как тех, так и других не закладывать в процесс разработки и в архитектуру си­стемы адаптационные механизмы. В объектном подходе такие механизмы более развиты, но и они имеют границы применимости.

Объектно-ориентированный подход как основа целой идеологии развития программных проектов заслуживает внимательного изучения во всех своих аспектах, и в первую очередь с точки зрения менеджмента раз­работки и поддержки программного обеспечения. Для программной сис­темы в иелом подход требует и новых моделей жизненного никла, отража­ющих его особенности, отмеченные ранее. Об этом будет идти речь после изучения основных вариантов традиционных моделей жизненного цикла. Адаптивность проекта — это альтернатива точке зрения на программ­ный проект, согласно которой его развитие считается предсказуемым. В ма­териальной сфере предсказуемость проекта означает, что его развитие/производство полностью подчинено заранее разработанным планам. Именно в этом отношении программные проекты отличаются от материальных: необ­ходимость учета изменчивости требований, о чем в данном курсе речь впе­реди, влечет за собой их явную зависимость от внешних факторов.

В частности, по этим причинам появляются подходы к ведению проектов, которые пытаются учитывать потребность адаптивности. Это уже обсуждавшиеся методологии быстрого развития (см. лекцию 5). Ча­ще всего новые методологии в целом остаются объектно-ориентирован­ными, но отходят от наиболее жестких установок этого подхода. Так, в методиках экстремального программирования жесткости и неизменно­сти первичной декомпозиции проекта (дизайн системы) противопоста­вляется предписание переделки дизайна по мере продвижения разра­ботки к удовлетворению уточняющихся потребностей пользователей [3]. Это нарушение канона компенсируется рядом организационных мер, позволяющих сгладить противоречия. По существу, предлагается специальный вариант менеджмента программных проектов. И, как это часто бывает сегодня, об ограничениях нового подхода упоминается лишь вскользь. В свое время мы еще будем иметь возможность обсудить ситуацию.