Технология RUP (rational Unified Process)

 

Одна из наиболее совершенных технологий, претендующих на роль мирового корпоративного стандарта — Rational Unified Process. RUP представляет собой программный продукт, разрабо­танный компанией Rational Software (www.rational.com), которая в настоящее время входит в состав IBM. RUP является результа­том объединения подходов Rational Approach и Objectory Process, происшедшего после слияния в 1995 году компаний Rational Software и Objectory AB (созданной Иваром Якобсоном).

RUP в значительной степени соответствует стандартам и нор­мативным документам, связанным с процессами ЖЦ ПО и оцен­кой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, СММ и др.). Ее основными принципами явля­ются:

1. Итерационный и инкрементный (наращиваемый) подход к созданию ПО.

2. Планирование и управление проектом на основе функцио­нальных требований к системе — вариантов использования.

3. Построение системы на базе архитектуры ПО.

Первый принцип является определяющим. В соответствии с ним разработка системы выполняется в виде нескольких крат­косрочных мини-проектов фиксированной длительности (от 2 до 6 недель), называемых итерациями. Каждая итерация включает свои собственные этапы анализа требований, проектирования, реализации, тестирования, интеграции и завершается созданием работающей системы.

Итерационный цикл основывается на постоянном расшире­нии и дополнении системы в процессе нескольких итераций с пе­риодической обратной связью и адаптацией добавляемых модулей к существующему ядру системы. Система постоянно разрас­тается шаг за шагом, поэтому такой подход называют итерацион­ным и инкрементным.

При таком подходе исключено и слишком быстрое написание кода (без детальной проработки) и чрезмерно длительный этап детального проектирования и построения моделей без обратной связи.

На рис. 5.6 показано общее представление RUP в двух изме­рениях:

1. горизонтальное измерение представляет время, отражает динамические аспекты процессов и оперирует такими поня­тиями, как стадии, итерации и контрольные точки;

2. вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как виды дея­тельности (технологические операции), рабочие продукты, исполнители и дисциплины (технологические процессы).

Рис. 5.6. Общее представление RUP

 

Динамический аспект

Согласно технологии RUP ЖЦ ПО разбивается на отдельные циклы, в каждом из которых создается новое поколение продук­та. Каждый цикл, в свою очередь, разбивается на четыре последо­вательные стадии:

· начальная стадия (inception);

· стадия разработки (elaboration);

· стадия конструирования (construction);

· стадия ввода в действие (transition).

Каждая стадия завершается в четко определенной контроль­ной точке (milestone). В этот момент времени должны достигать­ся важные результаты и приниматься критически важные реше­ния о дальнейшей разработке.

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

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

Результатами начальной стадии являются:

· общее описание системы: основные требования к проекту, его характеристики и ограничения;

· начальная модель вариантов использования (степень готов­ности - 10-20%);

· начальный проектный глоссарий (словарь терминов);

· начальный бизнес-план;

· план проекта, отражающий стадии и итерации;

· один или несколько прототипов.

На стадии разработки выявляются более детальные требова­ния к системе, выполняется высокоуровневый анализ предмет­ной области и проектирование для построения базовой архитек­туры системы, создается план конструирования и устраняются наиболее рискованные элементы проекта.

Результатами стадии разработки являются:

· модель вариантов использования (завершенная по крайней мере на 80%), определяющая функциональные требования к системе;

· перечень дополнительных требований, включая требования нефункционального характера и требования, не связанные с конкретными вариантами использования;

· описание базовой архитектуры будущей системы;

· работающий прототип;

· уточненный бизнес-план;

· план разработки всего проекта, отражающий итерации и критерии оценки для каждой итерации.

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

· модель предметной области, которая отражает понимание бизнеса и служит отправным пунктом для формирования основных классов предметной области;

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

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

Стадия разработки занимает около пятой части общей про­должительности проекта. Основными признаками завершения стадии разработки являются два события:

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

· идентифицированы все наиболее серьезные риски, и сте­пень понимания наиболее важных из них такова, что изве­стно, как справиться с ними.

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

Планирование завершается, когда определены место каждого варианта использования в некоторой итерации и дата начала каждой итерации. На данном этапе более детальное планирова­ние не делается.

RUP представляет собой итерационный и пошаговый про­цесс разработки, в котором программное обеспечение разрабаты­вается и реализуется по частям. На стадии конструирования пост­роение системы выполняется путем серии итераций. Каждая ите­рация является своего рода мини-проектом. На каждой итерации для конкретных вариантов использования выполняются анализ, проектирование, кодирование, тестирование и интеграция. Ите­рация завершается демонстрацией результатов пользователям и выполнением системных тестов с целью контроля корректности реализации вариантов использования.

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

Итерации на стадии конструирования являются одновремен­но инкрементными и повторяющимися:

· итерации являются инкрементными в соответствии с той функцией, которую они выполняют. Каждая итерация до­бавляет очередные конструкции к вариантам использова­ния, реализованным во время предыдущих итераций;

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

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

Главная особенность итерационной разработки заключается в том, что она жестко ограничена временными рамками, и сдвигать сроки недопустимо. Исключением может быть перенос реализа­ции каких-либо вариантов использования на более позднюю ите­рацию по соглашению с заказчиком. Смысл таких ограничений — поддерживать строгую дисциплину разработки и не допускать пе­реноса сроков.

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

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

· ПО, интегрированное на требуемых платформах;

· руководства пользователя;

· описание текущей реализации.

Назначением стадии ввода в действие является передача гото­вого продукта в распоряжение пользователей. Данная стадия включает:

· бета-тестирование, позволяющее убедиться, что новая сис­тема соответствует ожиданиям пользователей;

· параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;

· конвертирование баз данных;

· оптимизацию производительности;

· обучение пользователей и специалистов службы сопровож­дения.

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

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

На стадии ввода в действие продукт не дополняется никакой новой функциональностью (кроме самой минимальной и абсо­лютно необходимой). Здесь только вылавливаются ошибки. Хо­рошим примером для стадии ввода в действие может служить пе­риод времени между выпуском бета-версии и окончательной вер­сии продукта.

Статический аспект

Статический аспект RUP представлен четырьмя основными элементами:

· роли;

· виды деятельности;

· рабочие продукты;

· дисциплины.

Понятие «роль» (role) определяет поведение и ответствен­ность личности или группы личностей, составляющих проект­ную команду. Одна личность может играть в проекте много раз­личных ролей.

Под видом деятельности конкретного исполнителя понима­ется единица выполняемой им работы. Вид деятельности (activi­ty) соответствует понятию технологической операции. Он имеет четко определенную цель, обычно выражаемую в терминах полу­чения Или модификации некоторых рабочих продуктов (artifacts), таких, как модель, элемент модели, документ, исходный код или план. Каждый вид деятельности связан с конкретной ролью. Продолжительность вида деятельности составляет от нескольких часов до нескольких дней, он обычно выполняется одним испол­нителем и порождает только один или весьма небольшое количе­ство рабочих продуктов. Любой вид деятельности должен являть­ся элементом процесса планирования. Примерами видов дея­тельности могут быть планирование итерации, определение ва­риантов использования и действующих лиц, выполнение теста на производительность. Каждый вид деятельности сопровождается набором руководств (guidelines), представляющих собой методи­ки выполнения технологических операций.

Дисциплина (discipline) соответствует понятию технологичес­кого процесса и представляет собой последовательность действий, приводящую к получению значимого результата.

В рамках RUP определены шесть основных дисциплин:

· построение бизнес-моделей;

· определение требований;

· анализ и проектирование;

· реализация;

· тестирование; *

· развертывание;

· и три вспомогательных:

· управление конфигурацией и изменениями;

· управление проектом;

· создание инфраструктуры.

Основное содержание дисциплин построения бизнес-моде­лей, определения требований, анализа и проектирования было изложено в главах 3 и 4.

RUP как продукт входит в состав комплекса Rational Suite, причем каждая из перечисленных выше дисциплин поддержива­ется определенным инструментальным средством комплекса. Физическая реализация RUP представляет собой Web-сайт (рис. 5.7), включающий следующие компоненты:

· описание всех элементов динамического и статического ас­пекта RUP;

· навигатор по всем элементам RUP, глоссарий и средство быстрого обучения технологии;

· руководства для всех участников проектной команды, охва­тывающие весь жизненный цикл ПО. Руководства предс­тавлены в двух видах: для осмысления процесса на верхнем уровне и в виде подробных инструкций по отдельным видам деятельности;

· руководства по использованию инструментальных средств, входящих в состав Rational Suite;

· примеры и шаблоны проектных решений для Rational Rose;

· шаблоны проектной документации для SoDa;

· шаблоны в формате Microsoft Word, предназначенные для поддержки документации по всем процессам и действиям жизненного цикла ПО;

· планы в формате Microsoft Project, отражающие итерацион­ный характер разработки ПО.

 

Рис. 5.7. Электронная версия RUP

 

Адаптация RUP к потребностям конкретной организации или проекта обеспечивается с помощью Rational Process Workbench (RPW) - специального набора инструментов и шабло­нов для настройки и публикации Web-сайтов на основе RUP. RPW поддерживает три основные функции моделирования тех­нологических процессов:

· определение процесса;

· описание процесса;

· представление процесса.

Основой для определения процесса является модель RUP в среде CASE-средства Rational Rose, подобная модели на рис. 5.1.

Библиотека элементов процесса содержит текстовую инфор­мацию о каждом элементе в модели процесса, все текстовые стра­ницы RUP, a RPW - необходимые шаблоны для создания новых страниц описания. RPW генерирует описание процессов, вклю­чающее текст и графику, в виде Web-сайта, соединяя модели про­цессов и библиотеку описаний в единое целое.

Компания Rational Software поддерживает портал Rational Developer Network (www.rational.net), содержащий:

· статьи по инструментальным средствам и RUP;

· обзоры книг;

· курсы по обучению специалистов;

· инструкции по эксплуатации инструментальных средств;

· архивы дополнений и расширений к инструментальным средствам;

· базу знаний, основанную на реальных проектах.

RUP опирается на интегрированный комплекс инструмен­тальных средств Rational Suite. Он существует в вариантах:

· Rational Suite AnalystStudio - предназначен для определения и управления полным набором требований к разрабатывае­мой системе;

· Rational Suite DevelopmentStudio - предназначен для проек­тирования и реализации ПО;

· Rational Suite TestStudio — набор продуктов, предназначен­ных для автоматического тестирования приложений;

· Rational Suite Enterprise — обеспечивает поддержку полного жизненного цикла ПО и предназначен как для менеджеров проекта, так и отдельных разработчиков, выполняющих нес­колько функциональных ролей в команде разработчиков.

В состав Rational Suite, кроме самой технологии RUP как про­дукта, входят следующие компоненты:

· Rational Rose — средство визуального моделирования (ана­лиза и проектирования), использующее язык UML;

· Rational XDE — средство анализа и проектирования, интег­рируемое с платформами MS Visual Studio.NET и IBM WebSphere Studio Application Developer;

· Rational Requisite Pro — средство управления требованиями, предназначенное для организации совместной работы груп­пы разработчиков. Оно позволяет команде разработчиков создавать, структурировать, устанавливать приоритеты, отс­леживать, контролировать изменения требований, возника­ющих на любом этапе разработки компонентов приложения;

· Rational Rapid Developer — средство быстрой разработки приложений на платформе Java 2 Enterprise Edition;

· Rational ClearCase — средство управления конфигурацией ПО;

· Rational SoDA — средство автоматической генерации про­ектной документации;

· Rational ClearQuest — средство для управления изменениями и отслеживания дефектов в проекте на основе средств e-mail и Web;

· Rational Quantify — средство количественного определения узких мест, влияющих на общую эффективность работы программы;

· Rational Purify — средство для локализации трудно обнару­живаемых ошибок времени выполнения программы;

· Rational PureCoverage — средство идентификации участков кода, пропущенных при тестировании;

· Rational TestManager — средство планирования функцио­нального и нагрузочного тестирования;

· Rational Robot — средство записи и воспроизведения тесто­вых сценариев;

· Rational TestFactory — средство тестирования надежности;

· Rational Quality Architect — средство генерации кода для тес­тирования.

Одно из основных инструментальных средств комплекса Rational Rose представляет собой семейство объектно-ориенти­рованных CASE-средств; оно предназначено для автоматизации процессов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose реализует процесс объектно-ориентированного анализа и проектирования ПО, описанный в RUR В основе рабо­ты Rational Rose лежит построение диаграмм и спецификаций UML, определяющих архитектуру системы, ее статические и ди­намические аспекты. В составе Rational Rose можно выделить шесть основных структурных компонентов: репозиторий, графи­ческий интерфейс пользователя, средства просмотра проекта (браузер), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генераторы кодов для каждого поддерживаемого языка, состав которых меняется от версии к версии.

Репозиторий представляет собой базу данных проекта. Брау­зер обеспечивает «навигацию» по проекту, в том числе перемеще­ние по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства контроля и сбора статис­тики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе со­держащейся в репозиторий информации.

Средства автоматической генерации кода, используя инфор­мацию, содержащуюся в диаграммах классов и компонентов, формируют файлы описаний классов. Создаваемый таким обра­зом скелет программы может быть уточнен путем прямого прог­раммирования на соответствующем языке (основные языки, поддерживаемые Rational Rose — C++ и Java).

В результате разработки проекта с помощью Rational Rose формируются следующие документы:

· диаграммы UML, в совокупности представляющие собой модель разрабатываемой программной системы;

· спецификации классов, объектов, атрибутов и операций;

· заготовки текстов программ.

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

Инструментальное средство Rational XDE представляет собой развитие возможностей Rational Rose в части синхронизации мо­дели и кода (исключающей необходимость прямой и обратной генерации кода). Rational XDE обеспечивает:

· синхронизацию между кодом и моделью;

· отображение элементов кода Java и С# в UML;

· автоматическую синхронизацию с настраиваемым разреше­нием конфликтов;

· одновременное отображение кода и модели;

· постоянную синхронизацию модели UML как части проек­та Java или С#.

5.4.2.

ТЕХНОЛОГИЯ ORACLE

 

Методическую основу ТС ПО корпорации Oracle (www.ora-cle.com) составляет метод Oracle (Oracle Method) - комплекс ме­тодов, охватывающий большинство процессов ЖЦ ПО. В состав комплекса входят:

· CDM (Custom Development Method) — разработка приклад­ного ПО;

· PJM (Project Management Method) — управление проектом;

· AIM (Application Implementation Method) — внедрение прик­ладного ПО;

· BPR (Business Process Reengineering) — реинжиниринг биз­нес-процессов;

· OCM (Organizational Change Management) — управление из­менениями, и др.

Метод CDM оформлен в виде консалтингового продукта CDM Advantage - библиотеки стандартов и руководств (включа­ющего также PJM). Он представляет собой развитие достаточно давно созданного Oracle CASE-Method, известного по использо­ванию CASE-средств фирмы Oracle и книгам Ричарда Баркера. По существу CDM является методическим руководством по раз­работке прикладного ПО с использованием инструментального комплекса Oracle Developer Suite, а сам процесс проектирования и разработки тесно связан с Oracle Designer и Oracle Forms.

В соответствии с CDM ЖЦ ПО формируется из определен­ных этапов (фаз) проекта и процессов, каждый из которых вы­полняется в течение нескольких этапов (рис. 5.8):

· стратегия (определение требований);

· анализ (формулирование детальных требований к системе);

· проектирование (преобразование требований в детальные спецификации системы);

· реализация (написание и тестирование приложений);

· внедрение (установка новой прикладной системы, подго­товка к началу эксплуатации);

· эксплуатация.

Рис. 5.8. Этапы и процессы CDM

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

На этапе проектирования разрабатывается подробная архи­тектура системы, проектируются схема реляционной БД и программные модули, устанавливаются перекрестные ссылки между компонентами системы для анализа их взаимного влияния и контроля за изменениями.

На этапе реализации создается БД, строятся прикладные сис­темы, производится их тестирование, проверка качества и соот­ветствия требованиям пользователей. Создается системная доку­ментация, материалы для обучения и руководства пользователей.

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

Процессы CDM:

· определение бизнес-требований, или постановка задачи (Business Requirements Definition);

· исследование существующих систем (Existing Systems Examination). Выполнение этого процесса должно обеспе­чить понимание состояния существующего технического и программного обеспечения для планирования необходимых изменений;

· определение технической архитектуры (Technical Architecture);

· проектирование и реализация базы данных (Database Design and Build). Процесс предусматривает проектирование и реа­лизацию реляционной базы данных, включая создание ин­дексов и других объектов БД;

· проектирование и реализация модулей (Module Design and Build). Этот процесс является основным в проекте. Он включает непосредственное проектирование приложения и создание кода прикладной программы;

· конвертирование данных (Data Conversion). Цель этого про­цесса — преобразовывать, перенести и проверить согласо­ванность и непротиворечивость данных, оставшихся в нас­ледство от «старой» системы и необходимых для работы в новой системе;

· документирование (Documentation);

· тестирование (Testing);

· обучение (Training);

· внедрение, или переход к новой системе (Transition). Этот процесс включает решение задач установки, ввода новой системы в эксплуатацию, прекращения эксплуатации ста­рых систем;

· поддержка и сопровождение (Post-System Support).

Процессы состоят из последовательностей взаимосвязанных задач.

CDM предоставляет возможность выбрать требуемый подход к разработке. Это возможно, поскольку каждый процесс базиру­ется на известных зависимостях между задачами одного типа и не зависит от того, на какие этапы будет разбит проект.

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

В соответствии с этими факторами в CDM выделяются два основных подхода к разработке:

Классический подход (Classic). Этапы данного подхода предс­тавлены на рис 5.7. Классический подход применяется для наи­более сложных и масштабных проектов, он предусматривает пос­ледовательный и детерминированный порядок выполнения за­дач. Для таких проектов характерно большое количество реализу­емых бизнес-правил, распределенная архитектура, критичность приложения. Применение классического подхода также реко­мендуется при нехватке опыта у разработчиков, неподготовлен­ности пользователей, нечетко определенной задаче. Продолжи­тельность таких проектов от 8 до 36 месяцев.

Подход быстрой разработки (Fast Track). Данный подход, в от­личие от каскадного классического, является итерационным и основан на методе DSDM (Dynamic Systems Development Method). В этом подходе четыре этапа — стратегия, моделирова­ние требований, проектирование и генерация системы и внедре­ние в эксплуатацию. Подход используется для реализации не­больших и средних проектов с несложной архитектурой системы, гибкими сроками и четкой постановкой задач. Продолжитель­ность проекта от 4 до 16 месяцев.

PJM— это определенная дисциплина ведения проекта, позво­ляющая гарантировать, что цели проекта, четко определенные в его начале, остаются в центре внимания на протяжении всего проекта. В основе PJM лежит метод, ориентированный на выпол­нение самостоятельных процессов (под процессом понимается набор связанных задач, выполнением которых достигается опре­деленная цель проекта). Так же, как и CDM, метод руководства проектом представляется в виде четко определенной операцион­ной схемы, в которой выделяются процессы, этапы, задачи, ре­зультаты решения задач и зависимости между задачами:

· Управление проектом и предоставление отчетности (Control and Reporting). Этот процесс содержит задачи, в результате решения которых определяются границы проекта и подход к разработке, происходит управление изменениями и конт­ролируется возможный риск;

· Управление работой (Work Management). Процесс содержит задачи, помогающие контролировать работы, выполняемые в проекте;

· Управление ресурсами (Resource Management). Здесь реша­ются задачи, связанные с обеспечением каждого этапа ис­полнителями;

· Управление качеством (Quality Management). Процесс уп­равления качеством гарантирует, что проект отвечает требо­ваниям пользователя в течение всего процесса разработки;

· Управление конфигурацией (Configuration Management).

Цикл решения задач PJM состоит из отдельных этапов. Коли­чество этапов зависит от выбранного подхода к разработке. Зада­чи PJM можно распределить внутри каждого процесса по трем группам — задачи планирования, управления и завершения, и по уровням — отнести задачу на уровень проекта или на уровень от­дельного этапа.

По аналогии с CDM, в PJM предусмотрено широкое исполь­зование шаблонов разрабатываемых документов.

Комплекс Oracle Developer Suite содержит набор интегриро­ванных средств разработки для быстрого создания приложений. Он включает средства моделирования, программирования на Java, разработки компонентов, бизнес-анализа и составления от­четов. Все эти средства используют общие ресурсы, что позволя­ет совместно работать над одним проектом группе разработчи­ков. Oracle Developer Suite интегрирован с Oracle Database и Oracle Application Server, образуя единую платформу для создания и установки приложений.

Oracle Developer Suite поддерживает стандарты J2EE: Enterprise Java Beans (EJB), сервлеты и страницы JavaServer (JSP). В него также входят анализатор XML, процессор XSLT, процессор схем XML и XSQL-сервлет для разработки XML-приложений.

В Oracle Developer Suite встроена поддержка языка UML для разработки приложений на основе моделей. Модели хранятся в общем репозитории Oracle, который предназначен для поддерж­ки больших коллективов разработчиков.

Oracle Developer Suite включает в себя:

· Oracle Designer — средство моделирования и генерации при­ложений;

· Oracle Forms — средство быстрой разработки приложений;

· Oracle Reports - визуальное средство разработки отчетов;

· Oracle JDeveloper — средство визуального программирова­ния на языке Java;

· Oracle Discoverer — средство для разработки аналитических приложений;

· Oracle Warehouse Builder - система для построения храни­лищ данных;

· Oracle Portal — средство разработки информационного пор­тала организации.

CASE-средство Oracle Designer является интегрированным средством, обеспечивающим в совокупности со средствами раз­работки приложений поддержку ЖЦ ПО.

Oracle Designer представляет собой семейство методов и под­держивающих их программных продуктов. Базовый метод Oracle Designer (CDM) — структурный метод проектирования систем, охватывающий полностью все стадии ЖЦ ПО. Версия Oracle Designer для объектно-реляционной СУБД Oracle содержит так­же расширение в виде средств объектного моделирования, бази­рующихся на стандарте UML.

Oracle Designer обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозитории. В состав Oracle Designer входят следующие компо­ненты:

· Repository Administrator — средства управления репозитори-ем (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);

· Repository Object Navigator — средство доступа к репозито-рию, обеспечивающее многооконный объектно-ориентиро­ванный интерфейс доступа ко всем элементам репозитория;

· Process Modeler - средство анализа и моделирования биз­нес-процессов;

· Systems Modeler — набор средств построения функциональ­ных и информационных моделей проектируемой системы, включающий средства для построения диаграмм «сущ­ность-связь» (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объ­ектов репозитория различных типов (Matrix Diagrammer);

· Systems Designer — набор средств проектирования ПО, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построе­ния диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);

· Server Generator - генератор описаний объектов БД Oracle (таблиц, индексов, ключей, последовательностей и т.д.);

· Forms Generator — генератор приложений для Oracle Forms. Генерируемые приложения включают в себя различные эк-., ранные формы, средства контроля данных, проверки Огра­ничений целостности и автоматические подсказки;

· Repository Reports — генератор стандартных отчетов, интег­рированный с Oracle Reports.

Репозиторий Oracle Designer представляет собой хранилище всех проектных данных и может работать в многопользовательс­ком режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования авто­матически поддерживаются перекрестные ссылки между объек­тами словаря и могут генерироваться более 70 стандартных отче­тов о моделируемой предметной области. Физическая среда хра­нения репозитория — база данных Oracle.

5.4.3.

ТЕХНОЛОГИЯ BORLAND

 

Компания Borland (www.borland.com) в результате развития собственных разработок и приобретения ряда компаний предста­вила интегрированный комплекс инструментальных средств, реализующих управление полным жизненным циклом приложений (Application Life Cycle Management, ALM). В соответствии с тех­нологией Borland процесс создания ПО включает в себя пять ос­новных этапов:

· определение требований;

· анализ и проектирование;

· разработка;

· тестирование и профилирование;

· развертывание.

Выполнение всех этапов координируется процессом управле­ния конфигурацией и изменениями.

Определение требований реализуется с помощью системы уп­равления требованиями CaliberRM, которая стала частью семей­ства продуктов Borland в результате покупки компании Starbase. CaliberRM сохраняет требования в базе данных, документы с их описанием создаются с помощью встроенного механизма генера­ции документов MS Word на базе заданных шаблонов. Система обеспечивает экспорт данных в таблицы MS Access и импорт из MS Word. CaliberRM поддерживает различные методы визуализа­ции зависимостей между требованиями, с помощью которых пользователь может ограничить область анализа, необходимого в случае изменения того или иного требования. Имеется модуль, который использует данные требования для оценки трудозатрат, рисков и расходов, связанных с реализацией требований.

Средство анализа и проектирования Together ControlCenter разработано компанией TogetherSoft. В основе его применения лежит один из вариантов подхода «Быстрой разработки ПО» под названием Feature Driven Development (FDD)[29] [Палмер-02].

Together ControlCenter — интегрированная среда проектирова­ния и разработки, поддерживающая визуальное моделирование на UML с последующим написанием приложений для платформ J2EE (Java) и.Net (C#, C++ и Visual Basic). Кроме базовой версии, имеется уменьшенный вариант системы для индивидуальных раз­работчиков и небольших групп (Together Solo), а также редакции для платформы IBM WebSphere и среды разработки Jbuilder.

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

Инструментальные средства тестирования появились в соста­ве комплекса Borland в результате покупки компании Optimizeit. К ним относятся Optimizeit Suite 5, Optimizeit Profiler for.NET и Optimizeit ServerTrace. Первые две системы позволяют выявить потенциальные проблемы использования аппаратных ресурсов — памяти и процессорных мощностей на платформах J2EE и.Net соответственно. Интеграция Optimizeit Suite 5 в среду разработки Jbuilder, a Optimizeit Profiler — в C#Builder и Visual Basic.Net поз­воляет проводить контрольные испытания приложений по мере разработки и ликвидировать узкие места производительности. Система Optimizeit ServerTrace предназначена для управления производительностью серверных 12ЕЕ-приложений с точки зре­ния достижения заданного уровня обслуживания и сбора конт­рольных данных по виртуальным Java-машинам.

Сущность концепции ALM сосредоточена в системе управле­ния конфигурацией и изменениями: именно она объединяет ос­новные фазы ЖЦ ПО. Такой системой является StarTeam, разра­ботанная компанией Starbase. Она выполняет функции контроля версий, управления изменениями, отслеживания дефектов, уп­равления требованиями (в интеграции с CaliberRM), управления потоком задач и управления проектом.

StarTeam совместима с интерфейсом Microsoft Source Code Control и интегрируется с любой системой разработки, которая поддерживает этот API. Кроме того, в системе реализованы сред­ства интеграции со средствами разработки и моделирования Together, JBuilder, Delphi, C++Builder и C#Builder.

В технологии Borland выделяются три уровня интеграции. Функциональная (touch-point) интеграция позволяет обратиться из одной системы к функциям другой, выбрав соответствующий пункт меню. Например, интерфейс управления изменениями StarTeam непосредственно отображается в системах Together, C#Builder и Visual Studio.Net. Такая интеграция дает возможность разделять информацию между системами, но не обеспечи­вает единого рабочего пространства, вынуждает пользователя пе­реключать окна и приводит к дублированию процессов управле­ния структурой проекта. Встроенная (embedded) интеграция обес­печивает работу с одной системой непосредственно в среде дру­гой. Например, не выходя из среды разработки Jbuilder, можно просматривать графики производительности, которые создает система Optimizeit. Самый высокий уровень интеграции — синергетический (synergistic), позволяющий сочетать функции двух различных продуктов незаметно для разработчиков. Для боль­шинства продуктов Borland и других поставщиков синергетическая интеграция пока остается делом будущего, однако ее принци­пы уже начинают реализовываться.

5.4.4.