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

 

Технологические аспекты развития программных систем в моделях жизненного цикла

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

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

Этим задачам посвящена данная лекция.
Схемы итеративного развития программных систем в большей степени, чем классические схемы, отражают фактический ход многих реальных проектов. Поэтому вполне закономерно, что именно итеративные жизненные циклы привлекают внимание специалистов. С помощью моделей, отражающих итеративность, описываются полезные свойства процессов разработки программных систем. Мы продемонстрировали это при обсуждении контрольных точек и производственных функций модифицированной модели Гантера (см. лекцию 9). Далее будет показано, как при моделировании отражается возможность параллельного выполнения итераций и какое место эта возможность занимает в арсенале средств менеджера программных проектов. Затем мы обратимся к вопросу о том, в какой мере модели жизненного цикла могут способствовать реальному управлению, и с этой точки зрения рассмотрим ряд общеупотребительных моделей.
Параллельное выполнение итераций
Любой программный проект, заслуживающий привлечения менеджера для поддержки разработки, — это процесс, реализуемый коллективно. Следовательно, подчиняя моделирование жизненного цикла задачам менеджмента проекта, уместно ставить вопрос о том, как отражается в модели одновременность деятельности исполнителей.
В модели жизненного цикла, следующей гантеровской схеме фазы—функции, это качество процесса разработки программного изделия отражено с помощью функционального измерения, показывающего, какие технологические функции выполняются одновременно. Кроме того, эта модель описывает явно совместную работу на смежных этапах, которую при надлежащей организации труда в коллективе можно рассматривать как технологический параллелизм.
В рамках направления итеративного наращивания возможностей явно выделяется еще один вид технологического параллелизма: одновременная разработка нескольких итераций разными группами исполнителей (словосочетание «разные группы» не надо понимать буквально — по существу, это групповые роли, и конкретная группа исполнителей вполне может одновременно отвечать за разработку сразу нескольких итераций). Однако из принципиальной осуществимости одновременной разработки нескольких итераций не следует разрешение их механического слияния. Причиной тому — зависимость работ последующей итерации от результатов предыдущей. К примеру, невозможно наращивание еще не построенной системы классов, нельзя использовать функцию с неизвестными условиями ее выполнения. Говоря о совмещении работ, нужно всегда помнить о подобных видах зависимости. Вопрос зависимости между работами в свое время мы еще рассмотрим, а пока ограничимся общими положениями, достаточными для анализа возможностей параллельного выполнения итераций. Следует различать:

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

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

Иллюстративные и инструментальные модели жизненного цикла
Моделирование жизненного цикла может иметь по крайней мере две цели: модель предназначается для иллюстрации каких-либо положений или служит основой для организации проектных работ. В первом случае мы говорим об иллюстративной модели, а во втором — об инструментальной. Конечно же, это разграничение не является строгим. Любая иллюстрация, приводимая, например, в обосновании проекта, сама по себе служит направляющей организационных мероприятий, а потому можно говорить о степени инструментальности или иллюстративности конкретной модели. Тем не менее, если цели моделирования ограничиваются иллюстрацией, то огрубление, выделяющее значимый аспект рассмотрения, оправданно, тогда как использование модели как инструмента должно способствовать повышению качества процесса управления, а потому требуется точность.
Какими качествами должна обладать инструментальная модель? Прежде всего, она должна давать менеджеру полную картину процесса разработки и развития проекта. В этой картине выделяются уровни, предназначенные для организации планирования процесса, в частности для определения графика работ, для выделения и отслеживания их ресурсной обеспеченности. Как следствие должна быть по крайней мере принципиальная возможность перехода от модели жизненного цикла к работам каждого из этапов, доступа к истории развития проекта. Хорошая модель должна позволять видеть текущее состояние проекта и варианты его продвижения вперед. Наконец, если говорить о реальной поддержке деятельности менеджера на основе модели жизненного цикла, то нужно предоставить ему средства декомпозиции процесса разработки, т.е. согласованного с моделью разбиения общих этапов на вложенные этапы и работы. Эти средства следует рассматривать в качестве основного инструмента планирования развития проекта.
Однако реализация столь значительных требований к моделированию жизненного цикла может приводить к потере наглядности модели. Это противоречие в принципе преодолимо в CASE-системах, если бы они строились с ориентацией на определенные типы моделей жизненного цикла. Но чаще всего их разработчики пытаются представлять системы для пользователей как универсальные, на все случаи жизни. А фиксированный тип жизненного цикла препятствует универсальности. В результате обычно в CASE-системах модели жизненного цикла остаются иллюстративными. Так, наиболее популярная сегодня методология RUP (по данным статьи Р. Харитта, 51% программных систем разрабатываются в рамках использования этой методологии ) ориентируется исключительно на иллюстративную модель, которая никак не связана с использованием системы моделей UML. Подобное положение занимает и модель жизненного цикла MSF — шаблона проектирования, претендующего на универсальность. Мы еще будем иметь возможность в этом убедиться.
Инструментальность модели жизненного цикла — качество относительное. Даже тогда, когда модель приспособлена для использования в качестве инструмента управления, менеджер не обязательно будет следовать деятельности, предписываемой инструментом. В результате инструментальная модель используется как иллюстративная. С другой стороны, то, что для некоторой модели не разработаны CASE-средства, не означает, что они никогда не появятся и не обеспечат ее инструментального применения. Поэтому имеет смысл рассматривать модели жизненного цикла с точки зрения не реальной, а принципиальной возможности их инструментального применения. Есть еще одна причина, из-за которой целесообразно такое рассмотрение: средства поддержки реального применения всегда выстраиваются вокруг конкретной методологии, предписывающей те или иные способы включения их в деятельность пользователя. В результате суть понятий заслоняется конкретными аспектами их воплощения.
Инструментальная модель дает возможность оперировать своими элементами, а через это — влиять на ход моделируемого процесса, в данном случае – процесса выполнения проекта. Для этого она должна обладать следующими качествами.

  1. Атрибутивность — с элементами модели связаны определенные атрибуты, необходимые для управления проектом. Эти атрибуты можно задавать или извлекать, т.е. размещать информацию о проекте в некотором хранилище или получать ее из хранилища.
  2. Расширяемость — элементы модели допускают пополнение, в результате чего модель становится более детализированной, точнее отражающей реальный процесс. Для модели жизненного цикла расширяемость означает возможность ее достраивания элементами, указывающими на составляющие процесса разработки, т.е. на добавляемые этапы и на продолжения поэтапного дробления процесса на задачи, работы и др.
  3. Масштабируемость — возможность увидеть модель с разной степенью детализации, от охвата всего процесса и до конкретной работы.
  4. Интегрированность с другими инструментами поддержки. Это качество не самой модели, а CASE-средств, совместно с которыми она используется.

Мера, в которой модели обладают этими свойствами, может служить основой для сравнения их инструментальных возможностей.
Обсудим инструментальность ранее рассмотренных моделей (см. лекции 7–9). За исключением модифицированной модели фазы—функции все они имеют отношение лишь к последовательному развитию проектов, а потому, в принципе, могут применяться в итеративных методологиях лишь фрагментарно, т.е. на уровне отдельной итерации. Схемы, которые мы обсуждали до каскадной модели, претендовали лишь на иллюстративную роль. Поэтому заслуживают внимания лишь строгая каскадная модель и матрица фазы—функции. Обе они могут удовлетворить качеству расширяемости: блоки каскадной модели и линия жизненного цикла вполне пригодны для того, чтобы определять дополнительные самостоятельные и дополнительные вложенные этапы (этому вопросу мы еще уделим внимание). При этом, как было показано в лекции 8 и при построении модифицированной модели Гантера в лекции 9, линия жизненного цикла может расщепляться, создавая основу для отражения технологического параллелизма (см. предыдущий раздел). Атрибутивность матрицы фазы—функции выше каскадной атрибутивности за счет явного выделения функционального измерения. К тому же в каскадной модели не очень наглядно было бы показывать дополнительные атрибуты. Эта модель ориентирована на связи и контроль. Масштабируемость обеих моделей примерно одинакова, однако за счет того, что для каскадной модели существует достаточно много инструментов поддержки в рамках CASE-систем, пусть даже слабо интегрирующих ее с другим инструментарием, можно говорить о ее фактически более развитых средствах масштабирования.

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

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

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

  • Определение целей, альтернативных вариантов и ограничений.

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

  • Оценка альтернативных вариантов, идентификация и разрешение рисков.

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

  • Разработка и тестирование продукта на очередной итерации.

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

  • Планирование следующей итерации.

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

 

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