Унифицированный процесс разработки программного обеспесчения

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

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

5. Унифицированный процесс является интеративным и инкрементным

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

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

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

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

     Управляемый итеративный процесс имеет множество преимуществ:

• Управляемая итерация ограничивает финансовые риски затратами на одно приращение. Если разработчикам нужно повторить итерацию, организация теряет только усилия, затраченные на одну итерацию, а не стоимость всего продукта.
• Управляемая итерация снижает риск непоставки продукта на рынок в запланированные сроки. При раннем обнаружении соответствующего риска время, которое тратится на его нейтрализацию, вносится в план на ранних стадиях, когда сотрудники менее загружены, чем в конце планового периода. При традиционном подходе, когда серьезные проблемы впервые проявляются на этапе тестирования системы, время, требуемое для их устранения, обычно превышает время, оставшееся по плану для завершения всех работ, что почти всегда приводит к задержкам поставок.
• Управляемая итерация ускоряет темпы процесса разработки в целом, поскольку для более эффективной  работы разработчиков и быстрого получения ими хороших результатов короткий и четкий план предпочтительнее длинного и вечно сдвигающегося.
• Управляемая итерация признает часто отвергаемый факт — что желания пользователей  и связанные  с ними требования не могут быть определены в начале разработки.  Они  обычно уточняются в последовательных итерациях. Такой образ действий облегчает адаптацию к изменениям требований.

     Эти концепции — управляемая вариантами использования, архитектурно-ориентированная  и итеративная и инкрементная разработка — одинаково важны. Архитектура  предоставляет нам структуру, направляющую нашу работу в итерациях, в каждой из которых варианты использования  определяют цели и направляют нашу работу. Удаление одной из этих трех ключевых идей сильно уменьшит ценность Унифицированного процесса. Это как  треножник. Без одной ножки треножник  сразу же опрокинется.

     Теперь, когда мы познакомились с основными ключевыми концепциями, настало время рассмотреть весь процесс, его жизненный цикл, артефакты, рабочие процессы, фазы и итерации.

6. Жизненный цикл Унифицированного процесса

     Унифицированный процесс циклически повторяется. Эта последовательность повторений Унифицированного процесса, как показано на рис. 1.2, представляет собой жизненный  цикл системы. Каждый цикл завершается поставкой выпуска продукта заказчикам.

     Каждый  цикл состоит из четырех фаз —  анализа и планирования требований, проектирования, построения и внедрения. Каждая фаза как будет рассмотрено  ниже, далее подразделяется на итерации (рис. 1.3).

1. Продукт

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

     Окончательный продукт включает в себя требования, варианты использования, нефункциональные требования и варианты тестирования. Он включает архитектуру и визуальные модели — артефакты, смоделированные на Унифицированном языке моделирования. Фактически, он включает в себя все элементы, которые мы обсуждали в этой главе, поскольку они позволяют заинтересованным лицам — заказчикам, пользователям, аналитикам, проектировщикам, кодировщикам, тестерам и руководству—описывать, проектировать, реализовывать и использовать систему. Более того, именно эти средства позволяют заинтересованным лицам использовать систему и модифицировать ее от поколения к поколению.

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

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

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

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

2. Разделение  цикла на фазы

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

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

     На  рисунке 1.5 в левой колонке перечислены  рабочие процессы — определение  требований, анализ, проектирование, разработка и тестирование. Кривые приближенно  изображают (их не следует воспринимать слишком буквально) объемы рабочих  процессов, выполняемые в каждой из фаз. Напомним, что каждая фаза обычно дополнительно подразделяется на итерации или мини-проекты. Типичная итерация захватывает все пять рабочих  процессов, как это показано на рис. 1.5. 

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

• Что система должна делать в первую очередь для ее основных пользователей?
• Как должна выглядеть архитектура системы?
• Каков план и во что обойдется разработка продукта?

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

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