Сообщений 0 
Оценка 360
[+0/-1]
Оценить 
| Сообщений 0 Оценка 360
[+0/-1]
Оценить
|
| Модель водопада Итеративная разработка RUP Гибкие методологии CMMI Выводы Литература |  |
Для успешного выполнения ИТ-проекта недостаточно выбрать эффективные технологии и средства разработки, обеспечить необходимый бюджет и найти квалифицированных разработчиков. В любой организации существуют правила и методики, по которым участники проекта (заказчики, аналитики, разработчики, тестеры, технические писатели) распределяют между собой задачи, взаимодействуют друг с другом, создают проектные артефакты (спецификации, исходный код, документацию). Эти правила могут быть четко организованными или хаотичными, быть формально документированными или существовать в головах проектной команды, но в любом случае именно их совокупность называется процессом разработки.
Процесс – частный случай более общего понятия методологии разработки ПО. Примерами методологий являются структурное программирование или объектно-ориентированный анализ и дизайн. В этой статье я ограничусь наиболее распространенными процессами разработки; методологии рассматриваются в тех случаях, когда они являются неотъемлемым атрибутом процесса.
Модель водопада (waterfall model или последовательная разработка) – наверное, самый известный, исторически появившийся одним из первых процесс разработки. Он был описан в статье Ройса (W.W.Royce) в 1970 году (на самом деле, Ройс критиковал этот процесс, предлагая в качестве альтернативы итеративную разработку). Основная идея заключается в том, что процесс разработки делится на четко определенные фазы, выполняемые строго последовательно. Название «водопад» появилось из-за внешнего вида диаграммы, изображающей процесс:
Рисунок 1.
Отдельные задачи, из которых состоит любой проект (не обязательно выполняемый по модели водопада), можно разделить между несколькими процессными областями. Классическая водопадная модель включает следующие области:
В модели водопада каждая из процессных областей представляет собой отдельную фазу проекта. Фазы выполняются строго последовательно, т.е. анализ и дизайн начинаются после завершения разработки требований, началу реализации предшествует завершение дизайна и т.д.
Основные соображения для использования такой модели разработки вполне очевидны. Как известно, стоимость исправления ошибок, сделанных в ходе выполнения проекта зависит от того, насколько быстро эти ошибки обнаруживаются и исправляются. Ошибку в требованиях достаточно просто исправить на этапе разработки требований, но если о ней становится известно после завершения развертывания, последствия могут быть катастрофическими. Модель водопада стремится уменьшить, насколько это возможно, число таких долгоживущих ошибок. Для этого разработка дизайна не должна начинаться, пока требования не будут определены с достаточным качеством, кодирование не начинается до появления полного дизайна системы и т.д.
Насколько эффективным оказался такой подход? Он хорошо работает в проектах, где требования могут быть четко определены и зафиксированы. В таких проектах модель водопада позволяет обеспечить заданный уровень качества (который может быть весьма высоким) и соблюдать бюджетные и временные ограничения. Благодаря этому она часто используется в больших организациях (таких как Министерство обороны США и NASA) при строгих требованиях к надежности создаваемого ПО.
Однако практика показала следующие недостатки этого процесса:
Модель водопада является разумным выбором для типовых, стандартных проектов или при наличии жестких требований к качеству (например, при создании mission critical-систем). Тем не менее, ее недостатки весьма существенны, и для разработки коммерческого ПО, как правило, существуют значительно более эффективные альтернативы.
Процесс итеративной (или инкрементальной) разработки стал эволюционным развитием модели водопада. Процесс состоит из серии повторяющихся итераций (их число зависит от конкретного проекта), каждая из которых фактически является полноценным мини-проектом с фазами определения требований, анализа, дизайна и т.д. В результате очередной итерации продукт приобретает новую функциональность или улучшения в существующей функциональности. Полный набор требований, зафиксированный границами проекта, оказывается реализованным после завершения финальной итерации.
Основываясь на специфике проекта и требованиях заказчика, разработчики могут выбирать, что они хотят получить в результате очередной итерации:
Рисунок 2.
Итеративная разработка обладает рядом преимуществ по сравнению с последовательной моделью.
Важно понимать, что все эти преимущества проявляются только при тщательном планировании итераций, в противном случае легко получить ухудшенный вариант модели водопада.
Итеративная модель используется во многих процессах разработки, включая RUP и гибкие методологии, описанные далее в этой статье.
Один из самых известных процессов, использующих итеративную модель разработки – Rational Unified Process (RUP). Он был создан во второй половине 1990-х годов в компании Rational Software. Основными разработчиками были Филипп Крачтен (Philippe Kruchten), Грейди Буч (Grady Booch), Джеймс Рамбо (James Rumbaugh) и Айвар Якобсон (Ivar Jacobson). Кстати, последние трое являются также создателями нотации UML.
Термин RUP означает как методологию разработки, так и продукт компании IBM (ранее – Rational) для управления процессами разработки. Методология RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать специализированный процесс, ориентированный на ее потребности.
Можно выделить следующие основные характеристики процесса RUP.
Для описания требований в RUP используются прецеденты использования (use cases). Это не слишком удивительно, учитывая, что один из создателей RUP, Айвар Якобсон, является также автором концепции прецедента использования. Полный набор прецедентов использования системы вместе с логическими отношениями между ними (прецеденты могут включать и расширять другие прецеденты) называется моделью прецедентов использования.
Каждый прецедент использования – это описание сценария взаимодействия пользователя с системой, полностью выполняющего конкретную пользовательскую задачу. Разумеется, не имеет смысла документировать в виде прецедентов нефункциональные требования (к производительности, качеству т.д.). Однако согласно RUP все функциональные требования должны быть представлены в виде прецедентов использования. Считается, что модель прецедентов дает более целостное представление о функциональности системы по сравнению с традиционным описанием требований (перечислением функций, которыми должна обладать система).
Проект в RUP состоит из последовательности итераций с рекомендованной продолжительностью от 2 до 6 недель. Основной единицей планирования итераций является прецедент использования. Перед началом очередной итерации определяется набор прецедентов использования, которые будут реализованы к ее завершению.
Итеративная модель, подробно описанная выше, позволяет вносить необходимые изменения в требования, проектные решения и реализацию в ходе проекта.
Можно сказать что RUP – ориентированная на архитектуру методология. Считается, что реализация и тестирование архитектуры системы должны начинаться на самых ранних стадиях проекта. RUP использует понятие исполняемой архитектуры (executable architecture) – основы приложения, позволяющей реализовать архитектурно значимые прецеденты использования. Основы исполняемой архитектуры должны быть реализованы как можно раньше. Это позволяет оценить адекватность принятых архитектурных решений и внести необходимые коррективы еще в начале проекта. Таким образом, для первых нескольких итераций необходимо выбирать прецеденты, которые требуют реализации большей части архитектурных компонентов.
RUP поощряет использование визуальных средств для анализа и проектирования. Как правило, используется нотация и, соответственно, средства моделирования UML (такие как Rational Rose). Модель предметной области документируется в виде диаграммы классов, модель прецедентов использования – при помощи диаграммы прецедентов, взаимодействие компонентов системы между собой описывается диаграммой последовательности и т д.
Жизненный цикл проекта RUP состоит из четырех фаз. Последовательность этих фаз фиксирована, но число итераций, необходимых для завершения каждой фазы, определяется индивидуально для каждого конкретного проекта. Фазы RUP нельзя отождествлять с фазами водопадной модели– их назначение и содержание принципиально различны.
Фаза Начало обычно состоит из одной итерации. В ходе выполнения этой фазы необходимо:
Если после завершения первой итерации заинтересованные лица приходят к выводу о целесообразности выполнения проекта, проект переходит в следующую фазу. В противном случае проект может быть отменен или проведена еще одна итерация фазы Начало.
В результате выполнения этой фазы на основе требований и рисков проекта создается основа архитектуры системы. Проектирование может занимать до двух-трех итераций или быть полностью пропущенным (если в проекте используется архитектура существующей системы без изменений). Целями этой фазы являются:
В отличие от модели водопада, основным результатом этой фазы является не множество документов со спецификациями, а действующая система с 20-30% реализованных прецедентов использования.
В этой фазе (длящейся от двух до четырех итераций) происходит разработка окончательного продукта. Во время ее выполнения создается основная часть исходного кода системы и выпускаются промежуточные демонстрационные прототипы.
Целями фазы Внедрения являются проведение бета-тестирования и тренингов пользователей, исправление обнаруженных дефектов, развертывание системы на рабочей площадке, при необходимости – миграция данных. Кроме того, на этой фазе выполняются задачи, необходимые для проведения маркетинга и продаж.
Фаза внедрения занимает от одной до трех итераций. После ее завершения проводится анализ результатов выполнения всего проекта: что можно изменить для улучшения эффективности в будущих проектах?
В терминах RUP участники проектной команды создают так называемые артефакты (work products), выполняя задачи (tasks) в рамках определенных ролей (roles). Артефактами являются спецификации, модели, исходный код и т.п. Задачи разделяются по девяти процессным областям, называемым дисциплинами (discipline). В RUP определены шесть инженерных и три вспомогательные дисциплины. В них входят:
Рисунок 3.
В ходе жизненного цикла проекта распределение усилий проектной команды между дисциплинами постоянно меняется. Например, как правило, в начале проекта большая часть усилий затрачивается на анализ и дизайн, а ближе к завершению – на реализацию и тестирование системы. Однако в общем случае задачи из всех девяти дисциплин выполняются параллельно. Рисунок 3 иллюстрирует выполнение проекта среднего размера.
Часто RUP считают тяжеловесным процессом с высоким уровнем формализма. Это не совсем так, поскольку процесс RUP может (и должен) быть настроен под специфику конкретной организации и проекта. Небольшие проекты требуют низкой степени формализма, крупные проекты с географически распределенной командой – высокой. С практической точки зрения, надо дать ответы на вопросы наподобие следующих:
Однако широкие возможности настройки не делают внедрение RUP простым. Эффективному использованию RUP препятствует множество сложностей. Часто последовательность фаз начало-проектирование-построение-внедрение ошибочно интерпретируют как фазы анализ-дизайн-реализация-внедрение из водопадной модели – это практически сводит на нет преимущества RUP. Для большинства людей оказывается непривычной концепция документирования требований в виде прецедентов использования – трудности возникают как с написанием, так и с пониманием прецедентов. В результате спецификация требований, созданная проектной командой, может оказаться совершенно невнятным документом, который никто не будет читать.
Для полноценного внедрения RUP организация должна затратить значительные средства на обучение сотрудников. При этом попытка обойтись своими силами скорее всего будет обречена на неудачу – необходимо искать специалиста по процессам (process engineer) с соответствующим опытом или привлекать консультантов.
В течение 1990-х годов все больше разработчиков ПО начинали искать альтернативу традиционным, как правило, основанным на модели водопада, процессам разработки. К 2000 году существовало уже целое множество так называемых легковесных (lightweight) методологий. (Я использую термин «методология», а не «процесс», поскольку гибкие методологии включают в себя множество практик и технологий, выходящих за рамки описания процессов.)
В 2001 году группа создателей и экспертов по различным легковесным методологиям провела семинар, на котором были сформулированы основные принципы гибкой разработки ПО (так называемый Agile Manifesto). На том же семинаре было предложено новое название легковесных методологий – гибкая разработка (agile software development).
Общими особенностями гибких методологий являются:
По всей видимости, из методологий гибкой разработки самое широкое распространение получило экстремальное программирование (eXtreme Programming, XP), поэтому именно его мы рассмотрим подробнее.
Методология XP была создана Кентом Беком (Kent Beck) в 1996 году в ходе попытки спасти провальный проект по разработке системы расчета зарплаты для компании Крайслер. В 2000 году проект был закрыт, но XP к тому времени уже получила известность и начала распространяться среди разработчиков ПО.
XP наследует все общие принципы гибких методологий, достигая их при помощи двенадцати инженерных практик. Ниже описаны самые интересные из специфических технологий и практик XP:
Жизненный цикл проекта в XP состоит из последовательности релизов. Каждый релиз – это полноценная версия продукта, которую может использовать заказчик, и содержащая дополнительную функциональность по сравнению с предыдущим релизом. Релиз появляется в результате одной или нескольких итераций, длящихся от одной до четырех недель.
В XP не рекомендуется тратить много времени на планирование; сам процесс планирования называется игрой (planning game). Подробный план составляется только на очередную итерацию и ближайшие один-два релиза.
Планирование релиза состоит из следующих шагов:
Итерация планируется аналогичным образом.
Периодически в ходе проекта измеряется фактическая производительность команды. Если она начинает сильно отличаться от значения, которое было использовано при планировании, график выхода релизов должен быть пересмотрен.
Во многом XP была создана как попытка описать процессы и практики, которые часто как бы сами собой появляются в эффективных, сплоченных командах разработчиков. Может показаться, что процесс в таких командах отсутствует, и, скорее всего, то же самое будут утверждать сами разработчики. Однако это не так, поскольку работа профессиональной команды всегда четко (хотя и неформально) организована и не имеет ничего общего с беспорядком и хаосом.
Это во многом определяет условия, необходимые для эффективного использования XP. Прежде всего, XP имеет шансы работать только в команде опытных, профессиональных разработчиков. Поскольку большую роль в XP играет прямое общение, команда не должна быть разбита на несколько частей – внедрение XP в распределенной географически команде будет крайне рискованным мероприятием. По той же причине возможный размер команды ограничен сверху – по всей видимости, числом в 10-15 человек.
Другие практики XP приносят свои ограничения. Далеко не всегда можно обеспечить постоянное присутствие представителя заказчика в проектной команде (например, если потенциальные пользователи системы делятся на несколько классов с частично конкурирующими требованиями).
Поскольку XP практически не делает попыток предотвратить размывание границ проекта (scope creep), будет не очень хорошей идеей использовать XP в проекте с фиксированной ценой. Фактически проекты XP обладают жестким графиком, но переменными границами, поэтому предпочтительным типом контракта будет повременная оплата (time&materials).
Практика поддержания максимально простой архитектуры может завести в тупик в конце проекта, когда окажется, что для реализации завершающих историй требуется полное перепроектирование системы (оказывается, нам нужно было предусмотреть возможность интеграции с системой SAP R/3, а также перевода на японский язык всего пользовательского интерфейса!). Даже если подобная ситуация не возникнет, нет никакой гарантии, что создаваемая ad hoc архитектура не будет намного более запутанной и сложной, чем было бы продуманное заранее решение.
Подобным образом может неконтролируемо откладываться разрешение некоторых нетехнологических рисков, наподобие неопределенных границ проекта.
Несмотря на все перечисленные ограничения, XP может замечательно работать в подходящих для него условиях. Благодаря крайне низким накладным расходам, в таких ситуациях этот процесс может показать исключительную эффективность.
XP является достаточно гибкой методологией. Не обязательно внедрять XP во всей компании, вполне разумно ограничиться теми командами и проектами, которые могут получить от этого реальный выигрыш. Например, для разработки ядра продукта можно использовать XP, а проекты по внедрению основывать на процессе RUP. Также не обязательно использовать все классические практики XP (на самом деле, мало кто это делает) – как правило, разумно ограничиться теми из них, которые сочетаются с корпоративной культурой и особенностями проектов.
Модель Capability Maturity Model Integration (CMMI) была разработана в течение 1990-х годов в университете Карнеги-Меллона (Carnegie Mellon University.) совместно с Software Engineering Institute (SEI) и другими организациями. Одним из главных спонсоров разработки стало Министерство обороны США. CMMI была создана путем объединения (отсюда слово Integration в названии) трех более ранних специализированных моделей разработки: CMM for Software (SW-CMM), Electronic Industries Alliance Interim Standard (EIA/IS) 731 и Integrated Product Development Capability Maturity Model (IPD-CMM). Последняя версия спецификации CMMI 1.2 была опубликована в августе 2006 года.
Цель внедрения CMMI – построить инфраструктуру процессов, устанавливающую общий стандарт выполнения проектов внутри организации. Для каждого отдельного проекта стандартный процесс должен быть модифицирован в соответствии со спецификой этого проекта. При помощи формальных метрик измеряется эффективность процессов, а сами процессы постоянно оптимизируются.
Необходимо сказать, что CMMI не описывает какой-то конкретный процесс разработки. CMMI-совместимым может быть проект с водопадным, итеративным или другим жизненным циклом. Правильнее думать о CMMI как о наборе элементов процессов, приемов и методик, из которых, как из конструктора, нужно собрать законченный процесс.
Внедрение CMMI в организации может происходить на непрерывной (continuous) или ступенчатой (staged) основе. Содержание модели CMMI в обоих случаях одно и тоже, меняется только ее представление. Непрерывное представление дает возможность производить улучшения в отдельных процессных областях в произвольном порядке. Ступенчатое представление определяет четкую последовательность шагов по внедрению CMMI; каждый шаг соответствует достижению так называемого уровня зрелости (maturity level). Организации необходимо принять решение, до какого уровня зрелости она намерена дойти, а также необходимо ли проходить официальную сертификацию на соответствие этому уровню.
Остановимся подробнее на ступенчатом представлении, поскольку именно оно чаще всего используется на практике.
Основными элементами модели CMMI являются процессные области, общие и специальные задачи, общие и специальные практики.
CMMI определяет 22 процессные области, такие как планирование проекта (Project Planning), управление рисками (Risk Management), разработка требований (Requirements Development) и т.д. В ступенчатом представлении процессные области сгруппированы по пяти уровням зрелости (от 1 до 5). В непрерывном представлении каждая процессная область находится на одном из шести (от 0 до 5) уровней производительности (capability level).
Процессы в каждой процессной области должны достигать ряда целей. Общие цели (generic goals) относятся к нескольким процессным областям. Специальные цели (specific goals) уникальны для своей процессной области.
Для достижения специальных и общих целей служат специальные и общие практики (practices). Практики – это деятельность или задачи, которые должны быть выполнены для достижения соответствующей цели.
Рисунок 4.
В качестве примера рассмотрим процессную область Планирование проекта (Project Planning). В нее входит определение проектных артефактов, разбиение работ на отдельные задачи и их оценка, планирование необходимых ресурсов, составление графика проекта, анализ рисков, и т.д. В результате планирования проекта создается план проекта (project plan) – основной документ для организации и контроля проектных работ, управления бюджетом и оценки доходности , управления изменениями и рисками.
| ПРИМЕЧАНИЕ Часто путают план (plan) и график (schedule) проекта. План проекта – более широкое понятие; как правило, он включает в себя график. |
Процессная область Планирование проекта должна достигать трех специальных и двух общих целей. В рамках этих целей необходимо:
Перечислим практики, позволяющие достичь цели «разработать проектный план».
Как уже говорилось, ступенчатое представление CMMI позволяет классифицировать организации по уровням зрелости.
В каких организациях и на каких проектах лучше всего работает CMMI? Для того чтобы понять это, необходимо выделить основные характеристики модели.
CMMI вполне заслуженно считается тяжеловесной методологией, причем требует ощутимых затрат как во время, так и после внедрения. Тяжеловесность процессов нарастает с продвижением по уровням зрелости. Уже первый из интересных в практическом смысле уровней зрелости – уровень 3 – требует значительных усилий по обучению проектной команды, ведению проектной документации, периодическому аудиту процессов.
Как уже говорилось, под требования CMMI можно подогнать самые разнообразные процессы разработки, однако некоторые сочетания явно не имеют смысла. К примеру, вряд ли можно найти разумное применение процессу XP, дополненному формальным документированием требований и сбором метрик.
Что получает организация в обмен на усилия и ресурсы, потраченные на внедрение CMMI? Прежде всего, предсказуемость сроков и бюджета выполнения более или менее аналогичных проектов. Точность планирования – это основная цель 3 и 4 уровней зрелости CMMI, эффективность разработки становится ключевым фактором лишь на уровне 5. Благодаря хорошо документированным процессам и промежуточным результатам работ становится возможным быстро подключать к проекту новых сотрудников (возможно, более типичная ситуация – заменять ушедших).
Таким образом, представляется целесообразным использование CMMI в следующих условиях.
Очевидно, что не имеет большого смысла использовать CMMI для одного или нескольких отдельных проектов. Внедрение должно происходить во всей организации, департаменте и т.д.
Вряд ли использование CMMI принесет какие-либо преимущества при разработке новых продуктов, а особенно в исследовательских проектах (research and development). Поскольку при этом отнюдь не исчезают все накладные расходы, связанные с этой моделью, на мой взгляд, нецелесообразно использовать CMMI для разработки новых продуктов или сервисов. Однако проекты по внедрению этих продуктов вполне могут эффективно использовать CMMI.
Мы увидели, что современные процессы, использующиеся в реальных проектах, весьма разнообразны. Каждый из них имеет свои преимущества, которые проявляются в соответствующих условиях. Даже, казалось бы, безнадежно устаревшая водопадная модель совершенна адекватна для некоторых проектов. Каждый процесс обладает также и рядом характеристик, которые ограничивают область его эффективного использования. Эта ситуация вполне типична для разработки ПО, где уже накоплено множество технологий и методик, но не существует универсального метода, оптимального для любой задачи.
Несомненно, область процессной инженерии еще далека от зрелости и в ближайшем будущем будут созданы новые методологии. Из существующих процессов, не описанных в статье, имеет смысл обратить внимание на методологию Microsoft Solutions Framework (MSF). Это гибкая и достаточно легковесная методология, построенная на итеративной модели разработки. Привлекательной особенностью MSF является большое внимание к созданию эффективной и небюрократизированной проектной команды. Для достижения этой цели MSF предлагает достаточно нетрадиционные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды.
Интересным примером является OpenUP – семейство открытых (в отличие от проприетарного RUP) процессов, создаваемое в рамках проекта Eclipse Process Framework (EPF). Процесс OpenUP/Basic основан на принципах RUP, максимально упрощенного для гибкой разработки небольших проектов. Одновременно с ним развивается OpenUP/MDD, следующий методологии разработки через моделирование (Model Driven Development).
OpenUP/Basic и OpenUP/MDD реализуются в виде расширений EPF Composer, средства для создания и настройки процессов. Пользователи EPF Composer могут создавать свои процессы, используя в качестве компонентов фрагменты процессов, доступные в расширениях наподобие OpenUP/Basic и OpenUP/MDD.
| Сообщений 0 Оценка 360
[+0/-1]
Оценить
|