Практика
В каких организациях и на каких проектах лучше всего работает CMMI? Для того чтобы понять это, необходимо выделить основные характеристики модели.
CMMI вполне заслуженно считается тяжеловесной методологией, причем требует ощутимых затрат как во время, так и после внедрения. Тяжеловесность процессов нарастает с продвижением по уровням зрелости. Уже первый из интересных в практическом смысле уровней зрелости – уровень 3 – требует значительных усилий по обучению проектной команды, ведению проектной документации, периодическому аудиту процессов.
Как уже говорилось, под требования CMMI можно подогнать самые разнообразные процессы разработки, однако некоторые сочетания явно не имеют смысла. К примеру, вряд ли можно найти разумное применение процессу XP, дополненному формальным документированием требований и сбором метрик.
Что получает организация в обмен на усилия и ресурсы, потраченные на внедрение CMMI? Прежде всего, предсказуемость сроков и бюджета выполнения более или менее аналогичных проектов. Точность планирования – это основная цель 3 и 4 уровней зрелости CMMI, эффективность разработки становится ключевым фактором лишь на уровне 5. Благодаря хорошо документированным процессам и промежуточным результатам работ становится возможным быстро подключать к проекту новых сотрудников (возможно, более типичная ситуация – заменять ушедших).
Таким образом, представляется целесообразным использование CMMI в следующих условиях.
В относительно больших организациях, которые могут позволить себе значительные накладные расходы на внедрение и использование процесса.
При высокой текучести кадров, когда тем не менее необходимо поддерживать скорость разработки и качество продуктов на достойном уровне.
В случаях, когда организация выполняет большое количество более или менее однотипных проектов, CMMI позволяет достаточно точно планировать сроки и бюджет, и выполнять проекты в этих рамках.
Важная, а часто и определяющая причина для внедрения CMMI – возможность официальной сертификации на достижение определенного уровня зрелости. Нередко наличие или отсутствие сертификации по CMMI является решающим фактором в выборе компании-подрядчика.
Очевидно, что не имеет большого смысла использовать CMMI для одного или нескольких отдельных проектов. Внедрение должно происходить во всей организации, департаменте и т.д.
Вряд ли использование CMMI принесет какие-либо преимущества при разработке новых продуктов, а особенно в исследовательских проектах (research and development). Поскольку при этом отнюдь не исчезают все накладные расходы, связанные с этой моделью, на мой взгляд, нецелесообразно использовать CMMI для разработки новых продуктов или сервисов. Однако проекты по внедрению этих продуктов вполне могут эффективно использовать CMMI.
Рассмотрим еще один процесс разработки программного обеспечения ICONIX.
ICONIX разработал Дуг Розенберг (Doug Rosenberg) в компании ICONIX Software Engineering, Inc
Хотя название процесса пишется прописными буквами, оно не является аббревиатурой как разъяснили мне в ICONIX Software. По их словам, этот процесс был создан даже раньше, чем UML получил широкое распространение. В то время, когда UML только создавался усилиями "трех друзей" из Rational Software, пропагандировавших объектно-ориентированные методы разработки, Дуг Розенберг создавал средство объектного моделирования - ObjectModeler. Он обнаружил, что люди, покупавшие его средство не всегда успешно могли его применить, поскольку ObjectModeler требовал специального обучения для работы с ним. Особенно это касалось тех, кто только начинал работать с этим средством и плохо разбирался в объектных технологиях.
В отличие от довольно сложного RUP, ICONIX не требует привлечения консультантов, которые бы преобразовывали этот процесс для конкретной компании. RUP полностью покрывает весь жизненных цикл разработки программного обеспечения. ICONIX же фокусирует свое внимание на фазе анализа и дизайна. В настоящее время для RUP есть подключаемый модуль ICONIX, разработанный по заказу Rational Software, который упрощает процесс разработки для разработчиков, использующих RUP. Таким образом, можно использовать и тот и другой процесс, применяя ICONIX в наиболее подходящей для этого фазе - анализа и дизайна системы.
ICONIX, как и RUP базируется на UML, однако создатели сознательно использует только 20% типов UML диаграмм и в этом его основное отличие. Особенностью этого процесса, по словам автора, будет простое использование UML. Процесс ICONIX компактнее, легче в изучении и больше подходит для небольших проектов по сравнению с RUP.
ICONIX также как и RUP основан на прецедентах, является итеративным и инкрементным. Его основная задача найти ответ на вопрос: каким образом максимально быстро добраться от прецедентов к работающей системе используя минимум промежуточных шагов.
Основные этапы процесса следующие:
Анализ требований
Предварительное проектирование
Проектирование
Реализация
Процесс основан на построении минимального
количества моделей, которые отражают
будущую систему. Это динамические и
статические модели (см рис. 5).
На этапе анализа создаются модели прецедентов (Use Case), модель пользовательского интерфейса и модель сущностей предметной области.
На этапе предварительного проектирования создается диаграмма пригодности (Robustness Diagram). Также дополняется модель прецедентов и модель сущностей предметной области.
Диаграмма пригодности похожа на диаграмму кооперации (CollaborationDiagram), однако имеет существенное отличие, поскольку на ней изображаются не экземпляры, а классы со стереотипами «актер», «граничный объект», «сущность», «контроллер». Эта диаграмма, по мнению Розенберга, является связующим звеном между прецедентами и ответом на вопрос «что нужно» и классами и ответом на вопрос «как это сделать».
На этапе детального проектирования создается диаграмма последовательности (Sequence Diagram) и создается диаграмма классов.
На этапе реализации создается исходный код. При этом возможно создание диаграммы развертывания и диаграммы компонентов, если вы считаете, что это необходимо.
Нельзя забывать, что каждый этап завершается вехой рецензирования, когда созданные диаграммы необходимо обсудить с коллегами.
Основные принципы процесса ICONIX:
Движемся внутри, отталкиваясь от требований пользователя.
Движемся наружу, отталкиваясь от основных абстракций предметной области.
Спускаемся вниз от высокоуровневых моделей к детальному проекту.
Процесс ICONIX полезен для ответа на следующие вопросы о системе:
Каковы пользователи системы (актеры) и что они пытаются сделать;
Что такое объекты "реального мира" (предметной области) и какие между ними ассоциации;
Какие объекты участвуют в каждом прецеденте;
Как учесть ограничения, налагаемые режимом реального времени;
Как будет выглядеть система на самом нижнем уровне.
Выводы
Современные процессы, использующиеся в реальных проектах, весьма разнообразны. Каждый из них имеет свои преимущества, которые проявляются в соответствующих условиях. Даже, казалось бы, безнадежно устаревшая водопадная модель совершенна адекватна для некоторых проектов. Каждый процесс обладает также и рядом характеристик, которые ограничивают область его эффективного использования. Эта ситуация вполне типична для разработки ПО, где уже накоплено множество технологий и методик, но не существует универсального метода, оптимального для любой задачи.
Несомненно, область процессной инженерии еще далека от зрелости и в ближайшем будущем будут созданы новые методологии. Имеет смысл обратить внимание на методологию 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.
Домашнее задание
Подготовить конспект по моделям Microsoft Solutions Framework (MSF) и OpenUP: характеристика, этапы процесса, принципы, прменение.