учебники, программирование, основы, введение в,

 

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

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

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

Фазы разбиваются на ряд этапов
В любой разработке программного обеспечения при управлении проектом надо отслеживать этапы, зафиксированные общепринятой моделью. Иное дело, что в ней этапы выстроены в порядке, который фиксирует их как последовательные непересекающиеся работы. Если попытаться спроецировать их на реальные процессы, становится очевидно, что фактический расклад чаще всего не соответствует схеме развития проекта. На это обращает внимание Брукс, распространяя критику на все виды моделей жизненного цикла с последовательными этапами. Но если рассматривать общепринятую модель только как систематизацию, то она может быть хорошей основой для мотивированного обсуждения работ программного проекта, которые всегда должен отслеживать менеджер.
Разработка начинается с идентификации потребности в новом приложении, а заканчивается передачей продукта разработки в эксплуатацию.
Первым этапом фазы разработки является постановка задачи и определение требований. Определение требований включает описание общего контекста задачи, ожидаемых функций системы и ее ограничений. На данном этапе заказчик совместно с разработчиками принимает решение о создании системы. В процессе согласования требований со стороны разработчиков в обсуждении участвует менеджер проекта, а также, возможно, планировщик как действующее лицо, заинтересованное в соблюдении условий ведения проекта с точки зрения фирмы и осведомленное о ее ресурсном потенциале. Принципиально, что на данном этапе самого проекта еще нет и можно говорить только о предпроектных работах, в которых участвуют исполнители, занимающие указанные выше роли.
Определение требований в фактических проектах не может ограничиваться лишь предпроектными работами. Для реально полезных проектов они поступают в течение всего их развития. Как следствие, нужно говорить о том, для каких ролей предусматривается соответствующая деятельность после предпроектной стадии. Но это уже отход от схемы общепринятой модели, который мы выполним в дальнейшем.
В случае положительного решения начинается этап спецификации системы в соответствии с требованиями. Разработчики программного обеспечения пытаются осмыслить выдвигаемые заказчиком требования и зафиксировать их в виде спецификаций системы. Назначение этих спецификаций — описывать поведение разрабатываемой системы, а не ее внутреннюю организацию, т.е. отвечать на вопрос, что она должна делать, а не как это будет реализовано. Здесь говорится о назначении, а не о форме спецификаций, поскольку на практике при отсутствии подходящего языка спецификаций, к сожалению, нередко приходится прибегать к описанию «что» посредством «как». Прежде чем приступать к созданию проекта по спецификациям, они должны быть тщательно проверены на соответствие исходным целям, полноту, совместимость (непротиворечивость) и однозначность.
На этапе спецификации системы активизируются функции архитектора, которые пока ограничены лишь задачами, связанными с гарантиями осуществимости задуманного в рамках выделяемых ресурсов. Это время с точки зрения управления можно считать фактическим началом работ над проектом, поскольку появляются лица, деятельность которых подконтрольна менеджеру проекта. Если говорить более точно, в проекте активизировались роли исполнителей, выполняющих анализ осуществимости задания.
Разработка проектных решений, отвечающих на вопрос о том, как должна быть реализована система, чтобы она могла удовлетворять специфицированным требованиям, выполняется на этапе проектирования. Поскольку сложность системы в целом может быть очень высока, главной задачей этого этапа является последовательная декомпозиция системы до уровня очевидно реализуемых модулей или процедур. Наиболее активная роль на данном этапе — архитектор, для которого декомпозиция системы есть главная задача в проекте.
Термином проектирование сегодня пользуются все реже, по-видимому, чтобы не путать с понятием ведения проекта в целом. Вместо него употребляют конструирование, что отражает направленность работ этапа на построение архитектурной конструкции, а часто ограничиваются транслитерацией английского слова дизайн. Чтобы не нарушать сложившиеся традиции и в соответствии с принятым в рамках различных подходов словоупотреблением мы будем применять все три термина равноправно. Мы также используем понятие декомпозиция проекта, которое употребляется в двух смыслах. Во-первых, это процесс построения архитектуры, а во-вторых — результат такого построения. Термин конструирование избавлен от двусмысленности, и его можно употреблять, например, в таких сочетаниях: конструирование архитектуры, конструирование дизайна (это одно и то же) и даже конструирование декомпозиции.
В некотором смысле понятия конструирования и декомпозиции противоположны: первое из них характеризует построение как создание чего-то из «деталей», тогда как второе есть разбиение будущей конструкции (дизайна) на составляющие. Все зависит только от точки зрения на проект. Декомпозиция предполагает будущее существование программной системы, построенной в соответствии со спецификациями, а потому использовать это слово, предполагая развитие архитектуры, не совсем правомерно. Таким образом, декомпозиция — это статичное понятие, отражающее фиксированность, заданность того, что должно быть построено, тогда как конструирование отражает динамику и подвижность, изменчивость и настраиваемость «конструкции».
На следующем этапе реализации, или кодирования каждый из модулей, выявленных при декомпозиции, программируется на наиболее подходящем для данного приложения языке. С точки зрения автоматизации этот этап традиционно является наиболее развитым. Основные действующие лица этапа — руководитель команды и разработчики. Традиционно именно данный этап считали основой проекта в целом, что, как мы уже успели убедиться, не отражает современного взгляда на проект как на постоянно развивающийся артефакт. В обсуждаемой модели специально не выделяется этап сборки, который заключается в комплексации (интеграции) построенных и используемых модулей в систему. Считается, что это один из видов работ этапа реализации.
В общепринятой модели фаза разработки заканчивается этапом тестирования (автономного и комплексного) и передачей системы в эксплуатацию — следующие два этапа.
В рамках представления общепринятой модели считается, что в проекте должен быть некоторый барьер, разделяющий разработку и эксплуатацию, назначение которого — не допустить передачу пользователю некачественного продукта. По существу, здесь игнорируется тот факт, что взаимоотношения между разработкой программной системы и ее проверкой более тонкие. Как было показано (см. обсуждение ролей и функций разработчиков в лекции 2), тестирование как обособленная функция в программном проекте осмысленна лишь по отношению к комплексной проверке работоспособности системы, а проверка модулей и раздельная проверка корректности выполнения функций есть часть деятельности разработчиков компонентов. Но соответствующее уточнение делается в других моделях жизненного цикла.
Фаза эксплуатации и сопровождения включает в себя всю деятельность по обеспечению нормального функционирования программных систем, в том числе фиксирование вскрытых во время исполнения программ ошибок, поиск их причин и исправление, повышение эксплуатационных характеристик системы, адаптацию системы к окружающей среде, а также, при необходимости, и более существенные работы по совершенствованию системы. Все это дает право говорить об эволюции системы. В связи с этим фаза эксплуатации и сопровождения разбивается на два этапа: собственно сопровождение и развитие. В ряде случаев на данную фазу приходится большая часть средств, расходуемых в процессе жизненного цикла программного обеспечения.
Понятно, что внимание программистов к тем или иным этапам разработки зависит от конкретного проекта. Часто разработчикам нет необходимости проходить через все этапы, например если создается небольшая программа с ясно поставленной целью. Проблемы сопровождения, плохо понимаемые разработчиками небольших программ для личного пользования, являются в то же время очень важными для больших систем.
В общепринятой модели распределение ролей остается за кадром. В рамках этой модели говорить о деятельности лиц, которые выполняют основную функцию каждого из этапов, не приходится. Уже из этого, очевидно, следует ограниченность данной модели.
Можно ли рекомендовать общепринятую модель в качестве инструмента менеджмента, используемого для организации планирования, учета и контроля? Ограниченность модели не позволяет говорить об этом в полной мере. Но ее значение не в том, чтобы скрупулезно фиксировать технологический процесс, а лишь в определении основных первичных понятий, необходимых при описании более развитых моделей.
Такова краткая характеристика общепринятой модели. В литературе встречается много вариантов, развивающих ее в сторону детализации и добавления промежуточных фаз, этапов, стадий и отдельных работ (например, по документированию и технической подготовке проектов) в зависимости от особенностей программных проектов или предпочтений разработчиков.

Классическая итерационная модель
Общепринятая модель жизненного цикла является идеальной уже потому, что только очень простые задачи проходят все этапы без каких-либо итераций — возвратов на предыдущие шаги производственного процесса. При программировании, например, может обнаружиться, что реализация некоторой функции очень громоздка, неэффективна и вступает в противоречие с требуемой от системы производительностью. В этом случае необходимо перепроектирование, а может быть, и переделка спецификаций. При разработке больших нетрадиционных систем итеративность возникает регулярно на любом этапе жизненного цикла как из-за допущенных на предыдущих шагах ошибок и неточностей, так и из-за изменений внешних требований к условиям эксплуатации системы.
Таковы мотивы классической итерационной модели жизненного цикла (
Стрелки, идущие вверх, обозначают возвраты к предыдущим этапам, квалифицируемые как требование повторить этап для исправления обнаруженной ошибки. В связи c этим может показаться странным переход от этапа «Эксплуатация и сопровождение» к этапу «Тестирование и отладка». Дело в том, что рекламации, предъявляемые в ходе эксплуатации системы, часто даются в такой форме, что нуждаются в перепроверке. Чтобы понять, о каких ошибках идет речь в рекламации, разработчикам полезно предварительно воспроизвести пользовательскую ситуацию у себя, т.е. выполнить действия, которые обычно относят к тестированию.
Классическая итерационная модель абсолютизирует возможность возвратов на предыдущие этапы. Однако это обстоятельство отражает существенный недостаток программных разработок, проводимых в традиционном стиле: стремление заранее предвидеть все ситуации использования системы и невозможность в подавляющем большинстве случаев достичь этого. Все подобные методологии программирования направлены лишь на то, чтобы минимизировать возвраты. Но суть от этого не меняется: при возврате всегда приходится повторять построение того, что уже считалось готовым.
Иначе обстоит дело с методологиями, которые реализуют поддержку итерационного развития проектов. В этом случае отказываются от завершенности фаз и этапов, вместо чего предлагается распределять наращивание функциональности и интерфейсных возможностей по итерациям. В результате можно ослабить требование переделки старого при возвратах. По существу, классическая схема остается верной, но только в рамках одной итерации и с одной важной поправкой: все полезное, что было сделано ранее, сохраняется.
Безусловно, представленная идея становится реальностью лишь при условии, что у разработчиков программного обеспечения есть поддержка сохранения старого полезного кода, причем без потери эффективности. Такая поддержка сегодня почти повсеместно связывается с объектно-ориентированными методами программирования и проектирования. Более того, многие считают это чуть ли не единственным способом реализации итеративного наращивания . Отдавая должное методике объектной ориентированности, а также разработке методологий поддержки ведения проектов в рамках этого подхода, стоит обратить внимание на то, что он вовсе не всеобъемлющ, как утверждают его апологеты. Так, разработчики программных проектов, пользуясь им, вынуждены связывать себя множеством соглашений, без которых итеративное наращивание было бы просто непознаваемым. Помощь, которую оказывают объектно-ориентированные CASE-системы , достаточно очевидна, чтобы оспаривать ее. Однако приходится констатировать, что эти системы либо заставляют разработчика оставаться в жестких рамках, которые появляются в результате проектных ограничений конкретных и не всегда хорошо сбалансированных частных решений, либо предусматривают привнесение средств, концептуально противоречащих идеологии подхода. Да и сами объектно-ориентированные языки можно упрекнуть в той же эклектике и противоречивости (подробнее об этом ).
Итеративное наращивание имеет целью повышение гибкости системы, обеспечение возможности ее адаптации к меняющимся требованиям к программе и условиям развития проекта. Можно сказать, что разбиение на итерации есть средство повышения адаптивности проекта, а потому проблема не в том, используются или нет для реализации итеративности объектно-ориентированные языки или CASE-системы, а в том, насколько сам проект приспособлен к изменениям. Это в корне противоречит и традиционным методологиям, и объектным, если при использовании как тех, так и других не закладывать в процесс разработки и в архитектуру системы адаптационные механизмы. В объектном подходе такие механизмы более развиты, но и они имеют границы применимости.
Объектно-ориентированный подход как основа целой идеологии развития программных проектов заслуживает внимательного изучения во всех своих аспектах, и в первую очередь с точки зрения менеджмента разработки и поддержки программного обеспечения. Для программной системы в целом подход требует и новых моделей жизненного цикла, отражающих его особенности, отмеченные ранее. Об этом будет идти речь после изучения основных вариантов традиционных моделей жизненного цикла.
Адаптивность проекта — это альтернатива точке зрения на программный проект, согласно которой его развитие считается предсказуемым. В материальной сфере предсказуемость проекта означает, что его развитие/производство полностью подчинено заранее разработанным планам. Именно в этом отношении программные проекты отличаются от материальных: необходимость учета изменчивости требований, о чем в данном курсе речь впереди, влечет за собой их явную зависимость от внешних факторов.
В частности, по этим причинам появляются подходы к ведению проектов, которые пытаются учитывать потребность адаптивности. Это уже обсуждавшиеся методологии быстрого развития (см. лекцию 5). Чаще всего новые методологии в целом остаются объектно-ориентированными, но отходят от наиболее жестких установок этого подхода. Так, в методиках экстремального программирования жесткости и неизменности первичной декомпозиции проекта (дизайн системы) противопоставляется предписание переделки дизайна по мере продвижения разработки к удовлетворению уточняющихся потребностей пользователей. Это нарушение канона компенсируется рядом организационных мер, позволяющих сгладить противоречия. По существу, предлагается специальный вариант менеджмента программных проектов. И, как это часто бывает сегодня, об ограничениях нового подхода упоминается лишь вскользь. В свое время мы еще будем иметь возможность обсудить ситуацию.

Каскадная модель
Более строгой разновидностью классической итерационной модели является так называемая каскадная модель, которую можно рассматривать в качестве показательного примера того, какими методами можно минимизировать возвраты.
Характерные черты каскадной модели:

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

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

  • верификация отвечает на вопрос, правильно ли создана программная система;
  • аттестация отвечает на вопрос, правильно ли работает программная система.

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

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

  • оно противоречиво, т.е. содержит несовместимые или невыполнимые требования;
  • не выработаны критерии для выбора одного из возможных вариантов решения.

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

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

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

Она примечательна в нескольких отношениях.

  • Принята более абстрактная схема, которая указывает лишь на наличие этапов, а не на их содержание: этапы-работы обозначаются стрелками, соединяющими так называемые вехи (контрольные точки). Для реального проекта всегда этапы и вехи конкретизируются. Изображение вех как «осязаемых» фигур и работ как лишь соединительных линий соответствует тому, что активность менеджмента возрастает именно в контрольных точках.
  • В связи с абстрактностью модели появляются претензии на универсальную ее применимость, что фактически означает размытость границ адекватного использования. Абстрактная схема может автоматически поддерживаться только на универсальном уровне, тогда как в реальных ситуациях требуется различная поддержка качественно различающихся этапов.
  • Модель строго последовательная, отличающаяся от схемы общепринятой модели лишь явным указанием на наличие вех, прохождение которых (с подтверждением, верификацией и аттестацией, остающимися за кадром), означает завершение этапа.
  • Как следствие предыдущего, не учитываются только что рассмотренные моменты строгой каскадной модели: разделение труда и совместная работа на соседних этапах. В результате соответствующие аспекты не формализуются и их приходится объяснять дополнительно.
  • Модель работает, когда на начальном этапе проекта или на последовательно развиваемой его части можно четко определить неизменный набор требований к разрабатываемому решению. Однако это условие редко соответствует реальности.

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

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика