Рассмотрим еще один процесс разработки программного обеспечения 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:

1. Движемся внутри, отталкиваясь от требований пользователя.
2. Движемся наружу, отталкиваясь от основных абстракций предметной области.
3. Спускаемся вниз от высокоуровневых моделей к детальному проекту.

Процесс 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.