Файл: Инфрам.pdf

106 сти совпадать с набором целей, указанных заказчиком продукта, то есть все требования должны быть выполнены.
Процесс предполагает эволюционирование моделей; итерация цикла разработки однозначно соответствует определенной версии модели про- граммного обеспечения. Каждая из итераций содержит элементы управления жизненным циклом программного обеспечения: анализ и дизайн (моделирование), реализация, интегрирование, тестирование, внедрение. В этом смысле RUP является реализацией спиральной моде- ли, хотя довольно часто изображается в виде графика-таблицы (рис.
3.11).
На данном рисунке представлены два измерения: горизонтальная ось представляет время и показывает временные аспекты жизненного цикла процесса; вертикальная ось представляет дисциплины, которые опреде- ляют физическую структуру процесса. На рис. 0 видно, как с течением времени изменяются акценты в проекте. Например, в ранних итерациях больше времени отводится требованиям; в поздних итерациях больше времени отводится реализации. Горизонтальная ось сформирована из временных отрезков - итераций, каждая из которых является самостоя- тельным циклом разработки, цель которого принести некоторую зара- нее определенную осязаемую доработку в конечный продукт, полезную с точки зрения заинтересованных лиц.
Рис. 3.11. Рациональный унифицированный процесс
По оси времени жизненный цикл делится на четыре основные фазы:
1. Начало (Inception) – формирование концепции проекта, понима- ние, что мы создаем, представление о продукте (vision), разработка биз- нес-плана (business case), подготовка прототипа программы или частич- ного решения. Это фаза сбора информации и анализа требований, опре- деление образа проекта в целом. Цель – получить поддержку и финан-

107 сирование. В конечной итерации результат этого этапа – техническое задание.
2. Проектирование, разработка (Elaboration) – уточнение плана, по- нимание, как мы это создаем проектирование, планирование необходи- мых действий и ресурсов, детализация особенностей. Завершается этап исполняемой архитектурой, когда все архитектурные решения приняты и риски учтены. Исполняемая архитектура представляет собой рабо- тающее программное обеспечение, которое демонстрирует реализацию основных архитектурных решений. В конечной итерации это – техниче- ский проект.
3. Реализация, создание системы (Construction) – этап расширения функциональности системы, заложенной в архитектуре. В конечной итерации это – рабочий проект.
4. Внедрение, развертывание (Transition). Создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю (тиражирование, доставка и обучение).
Вертикальная ось состоит из дисциплин, каждая из которых может быть более детально расписана с точки зрения выполняемых задач, от- ветственных за них ролей, продуктов, которые подаются задачам на вход и выпускаются в ходе их выполнения и т.д. По этой оси распола- гаются ключевые дисциплины жизненного цикла RUP, которые часто на русском языке называют процессами, хотя это не совсем верно с точки зрения данной методологии, поддерживаемые инструментальными средствами IBM (и/или третьих фирм):
1. Бизнес анализ и моделирование (Business modeling) обеспечивает реализацию принципов моделирования с целью изучения бизнеса организации и накопления знаний о нем, оптимизации бизнес про- цессов и принятия решения об их частичной или полной автоматиза- ции
2. Управление требованиями (Requirements) посвящено получению информации от заинтересованных лиц и ее преобразованию в набор требований, определяющих содержание разрабатываемой системы и подробно описывающих ожидания от того, что система должна де- лать.
3. Анализ и проектирование (Analysis and design) охватывает процеду- ры преобразования требований в промежуточные описания (модели), представляющие, как эти требования должны быть реализованы.
4. Реализация (Implementation) охватывает разработку кода, тестирова- ние на уровне разработчиков и интеграцию компонентов, подсистем и всей системы в соответствии с установленными спецификациями.
5. Тестирование (Test) посвящено оценке качества создаваемого про- дукта.
6. Развертывание (Deployment) охватывает операции, имеющие место при передаче продуктов заказчикам и обеспечении доступности про- дукта конечным пользователям.
7. Конфигурационное управление и управление изменениями
(Configuration management) посвящено синхронизации промежуточ-

108 ных и конечных продуктов и управлению их развитием в ходе про- екта и поиском скрытых проблем.
8. Управление проектом (Management) посвящено планированию про- екта, управлению рисками, контролю хода его выполнения и непре- рывной оценке ключевых показателей.
9. Управление средой (Environment) включает элементы формирования среды разработки информационной системы и поддержки проектной деятельности.
В зависимости от специфики проекта могут быть использованы лю- бые средства IBM Rational, а также третьих фирм. В RUP рекомендова- но следовать шести практикам, позволяющим успешно разрабатывать проект: итеративная разработка; управление требованиями; использо- вание модульных архитектур; визуальное моделирование; проверка качества; отслеживание изменений.
Неотъемлемую часть RUP составляют артефакты (artefact), преце- денты (precedent) и роли (role).

109 ляющий собой единую среду для связывания всех ошибок и доку- ментов между собой;
Rational SoDA – продукт для автоматического генерирования про- ектной документации, позволяющий установить корпоративный стандарт на внутрифирменные документы. Возможно также приве- дение документации к уже существующим стандартам (ISO, CMM);
Rational Purify, Rational Quantify Rational PureCoverage, – средства тестирования и отладки:
Rational Visual Quantify – средство измерения характеристик для разработчиков приложений и компонентов, программирующих на
C/C++, Visual Basic и Java; помогает определять и устранять узкие места в производительности ПО,
Rational Visual PureCoverage – автоматически определяет области кода, которые не подвергаются тестированию;
Rational ClearCase – продукт для управления конфигурацией про- грамм (Rational’s Software Configuration Management, SCM), позво- ляющий производить версионный контроль всех документов проек- та. С его помощью можно поддерживать несколько версий проектов одновременно, быстро переключаясь между ними. Rational Requisite
Pro поддерживает обновления и отслеживает изменения в требова- ниях для группы разработчиков;
SQA TeamTest – средство автоматизации тестирования;
Rational TestManager – система управления тестированием, которая объединяет все связанные с тестированием инструментальные сред- ства, артефакты, сценарии и данные;
Rational Robot – инструмент для создания, модификации и автомати- ческого запуска тестов;
SiteLoad, SiteCheck – средства тестирования Web-сайтов на произво- дительность и наличие неработающих ссылок;
Rational PerformanceStudio – измерение и предсказание характери- стик производительности систем.
Этот набор продуктов постоянно совершенствуется и пополняется.
Так, например, недавний продукт IBM Rational Software Architect (RSA) является частью IBM Software Development Platform – набора инстру- ментов, поддерживающих жизненный цикл разработки программных систем. Продукт IBM Rational Software Architect предназначен для по- строения моделей разрабатываемых программных систем с использова- нием унифицированного языка моделирования UML 2.0, прежде всего моделей архитектуры разрабатываемого приложения. Тем не менее,
RSA объединяет в себе функции таких программных продуктов, как
Rational Application Developer, Rational Web Developer и Rational
Software Modeler, тем самым предоставляя возможность архитекторам и аналитикам создавать различные представления разрабатываемой ин- формационной системы с использованием языка UML 2.0, а разработ- чикам – выполнять разработку J2EE, XML, Web-сервисов и т.д.

110
Следуя принципам RUP, Rational Software Architect позволяет созда- вать необходимые модели в рамках рабочих процессов таких дисцип- лин, как: бизнес анализ и моделирование (Business modeling); управление требованиями (Requirements); анализ и проектирование (Analysis and Design); реализация (Implementation).
Кроме того, Rational Software Architect поддерживает технологию разработки, управляемой моделями (model-driven development, MDD), позволяющую моделировать программное обеспечение на различных уровнях абстракции с возможностью трассируемости. Последняя версия
RSA 8.0 представляет собой основной релиз семейства продуктов IBM®
Rational® Software Architect. Программный пакет RSA был собран зано- во в виде продукта базового уровня, который можно расширять в соот- ветствии с необходимыми предметно-ориентированными возможностя- ми. Кроме того, для расширения поддерживаемых технологий, повыше- ния продуктивности и простоты использования существенно обновлен набор базовых функциональных возможностей [28].
IBM® Rational® Software Modeler и IBM Rational Software Architect
Standard Edition теперь объединены в один основной продукт: Rational
Software Architect. Он предоставляет нотацию BPMN 2 (Business Process
Modeling Notation), моделирование на UML 2 (Unified Modeling Lan- guage), визуализацию кода и согласованную поддержку моделирования для Java™, C# и VB.NET (Microsoft® Visual Basic®.NET). Эту базовую платформу можно наращивать при помощи набора расширений, кото- рые обеспечивают дополнительные возможности, от совместной работы и имитационного моделирования до моделирования развертывания и использования интегрированных архитектурных сред.
При помощи расширения Simulation в RSA 8.0 можно имитировать любое UML-поведение (диаграммы деятельности, диаграммы последо- вательности, диаграммы коммуникации или диаграммы состояний).
Можно пройти по поведению так, как будто вы пошагово проходите по коду; при этом ваша текущая позиция будет подсвечиваться на диа- грамме поведения, а также, возможно, на диаграмме композитной структуры или топологии. Это дает ряд преимуществ: лучшее понимание поведения системы на более ранних этапах, дающее возможность устранить потенциальные дефекты поведения. понимание того, как повлияет на статическую структуру модели ан- нотирование диаграммы композитной структуры. учет влияния поведения на топологию развертывания, а также пони- мание потенциального воздействия имеющейся инфраструктуры на поведение приложения.
3.7.8. SCRAM-методология
В большинстве случаев программирование – слабо определенный процесс, требующий творческого подхода. Scrum – одна из первых ме-

111 тодологий циклического наращивания функциональности и корректи- ровки хода проекта на основе анализа обратной связи.
Термин Scrum был впервые озвучен в работе Х. Такеучи и И. Нона- ка, опубликованной в Harvard Business Review, где авторы отметили успешность проектов, использующих небольшие команды без жесткой специализации. Такие команды чем-то напоминают конструкцию схват- ки (scrum) в регби, которая назначается при нарушении правил или ос- тановке игры. Д. Сазерленд использовал эту работу при создании мето- дологии для корпорации Easel в 1993 году, которую по аналогии и назвал Scrum, а К. Швабер формализовал процесс для использования в индустрии разработки программного обеспечения, представив в 1995 году работу на конференции Object-Oriented Programming
Systems, Languages & Applications [5].
Методология Scrum устанавливает правила управления процессом разработки и позволяет использовать уже существующие практики ко- дирования, корректируя требования или внося тактические изменения.
Использование этой методологии дает возможность выявлять и устранять отклонения от желаемого результата на более ранних эта- пах разработки программного продукта.
Основа Scrum – итеративная разработка. Scrum определяет правила, по которым должен планироваться и управляться список требований к продукту для достижения максимальной прибыльности от реализо- ванной функциональности: правила планирования итераций для максимальной заинтересован- ности команды в результате; основные правила взаимодействия участников команды для макси- мально быстрой реакции на существующую ситуацию; правила анализа и корректировки процесса разработки для совер- шенствования взаимодействия внутри команды.
Каждую итерацию можно представить следующим образом: плани- руем – фиксируем – реализуем – анализируем. За счет фиксирования требований на время одной итерации и изменения длины итерации можно управлять балансом между гибкостью и планируемостью разра- ботки.
Scrum – простой каркас, который можно использовать для организа- ции команды и достижения результата более продуктивного и с более высоким качеством за счет анализа сделанной работы и корректировки направления развития между итерациями. Методология позволяет ко- манде выбрать задачи, которые должны быть выполнены, учитывая бизнес-приоритеты и технические возможности, а также решить, как их эффективно реализовать. Это позволяет создать условия, при которых команда работает с удовольствием и максимально продуктивно. Напри- мер, возможность самостоятельного выбора объема и пути решения задач без внешнего давления позволяет всем участникам команды по- чувствовать себя активными игроками, вовлеченными в процесс, а не простыми исполнителями, от которых требуется лишь четкая реализа- ция поручений.