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

Одной из наиболее совершенных технологий, претендующих на рольмирового корпоративного стандарта, является Rational Unified Process(RUP) – технология, разработанная компанией Rational Software (www. Rational.com), входящей в настоящее время в состав компании IBM.

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

Ее основными принципами являются:

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

2) планирование и управление проектом на основе функциональных требований к системе – вариантов использования;

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

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

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

 

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

 

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

Динамический аспект. Согласно технологии RUP ЖЦ ПО разбивается на четыре фазы (стадии), в каждой из которых создаетсяновое поколение продукта: начало (inception); разработка, или уточнение (elaboration); конструирование (construction); ввод в эксплуатацию (transition).

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

Результатами фазы «Начало» являются:

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

2) начальная модель вариантов использования (степень готовности – около 10…20%);

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

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

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

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

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

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

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

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

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

4) работающий прототип;

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

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

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

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

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

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

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

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

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

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

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

RUP представляет собой итерационный и пошаговый процессразработки, в котором программное обеспечение разрабатываетсяи реализуется по частям.

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

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

Тестирование и интеграция – это достаточно крупные задачи, они всегда занимают больше времени, чем ожидается. Чем позже выполнять тестирование и интеграцию, тем более трудными задачамиони становятся и тем более способны дезорганизовать весь проект.

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

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

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

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

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

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

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

На данной стадии разработчики должны иметь более глубокое представление о такой оценке.

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

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

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

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

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

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

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

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

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

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

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

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

Под видом деятельности конкретного исполнителя понимаетсяединица выполняемой им работы.

Вид деятельности (activity) соответствует понятию технологической операции. Он имеет четкоопределенную цель, обычно выражаемую в терминах получения илимодификации некоторыхрабочих продуктов (artifacts), таких какмодель, элемент модели, документ, исходный код или план. Каждыйвид деятельности связан с конкретной ролью.

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

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

В рамках RUP определены шесть основных дисциплин (построение бизнес-моделей; определение требований; анализ и проектирование; реализация; тестирование; развертывание) и три вспомогательных (управление конфигурацией и изменениями; управлениепроектом; создание инфраструктурыRUP как продукт входит в состав комплекса Rational Suite, причемкаждая из перечисленных ранее дисциплин поддерживается определенным инструментальным средством комплекса.

Физическая реализация RUP представляет собой веб-сайт, включающий в себя следующие компоненты:

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

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

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

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

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

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

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

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

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

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

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

Компания Rational Software поддерживает портал Rational Developer Network (www.rational.net), содержащий методические материалы(статьи, обзоры, архивы, база знаний и пр.) по инструментальнымсредствам и RUP.

 

Технология Oracle

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

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

2) PJM (ProjectManagementMethod) –управлениепроектом;

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

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

5) ОСМ (Organizational Change Management) –управлениеизменениямиидр.

Методы CDM и PJM оформлены в виде библиотеки стандартови руководств CDM Advantage – популярного консалтингового продукта, представляющего собой развитие давно известного OracleCASE-Method.

CDM является методическим руководством по разработке прикладного ПО с помощью CASE-средств Oracle Designer и OracleForms, входящих в состав инструментального комплекса Oracle Developer Suite.

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

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

 

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

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

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

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

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

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

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

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

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

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

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

Процессы CDM:

1) определение бизнес-требований, или постановка задачи(BusinessRequirementsDefinition);

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

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

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

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

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

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

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

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

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

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

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

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

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

Этапыклассического подхода (Classic) представлены на рис. 19.2.

Классический подход применяется для наиболее сложных и масштабных проектов, он предусматривает последовательный и детерминированный порядок выполнения задач.

Для таких проектов характерны большое количество реализуемыхбизнес-правил, распределенная архитектура, критичность приложения. Применение классического подхода также рекомендуется принехватке опыта у разработчиков, неподготовленности пользователей, нечетко определенной задаче. Продолжительность таких проектов – от 8 до 36 мес.

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

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

Так же, как и CDM, метод руководства проектом представляетсяв виде четко определенной операционной схемы, в которой выделяются процессы, этапы, задачи, результаты решения задач и зависимости между задачами:

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

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

3) управление ресурсами (Resource Management). Данный процесс решает задачи, связанные с обеспечением каждого этапа исполнителями;

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

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

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

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

Комплекс Oracle Developer Suite содержит набор интегрированныхсредств разработки для быстрого создания приложений. Он включаетв себя средства моделирования, программирования на Java, разработки компонентов, бизнес-анализа и составления отчетов. Все этисредства используют общие ресурсы, что позволяет совместно работать над одним проектом группе разработчиков. OracleDeveloperSuiteинтегрировансOracleDatabaseиOracleApplicationServer, образуяединую платформу для создания и установки приложенийOracleDeveloperSuiteподдерживаетстандартыJ2EE: Enterprise, JavaBeans (EJB), сервлетыистраницыJAVASERVER (JSP). В него также входят анализатор XML, процессор XSLT, процессор схем XMLи XSQL-сервлет для разработки XML-приложений. В Oracle Developer Suite встроена поддержка языка UML для разработки приложений на основе моделей. Модели хранятся в общемрепозитории Oracle, который предназначен для поддержки большихколлективов разработчиков.

Комплекс Oracle Developer Suite включает в себя:

1) Oracle Designer – средство моделирования и генерации приложений;

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

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

4) Oracle JDEVELOPER – средство визуального программированияна языке Java;

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

6) Oracle Warehouse Builder – система для построения хранилищданных;

7) Oracle Portal – средство разработки информационного портала организации.

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

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

Oracle Designer обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области.

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

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

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

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

4) Systems Modeler – набор средств построения функциональныхи информационных моделей проектируемой системы, включающий в себя средства для построения диаграмм «сущность – связь» (Entity-RelationshipDiagrammer), диаграммфункциональныхиерархий (FunctionHierarchyDiagrammer), диаграммпотоковданных (DataFlow Diagrammer) и средство анализа и модификации связей объектов, репозитория различных типов (Matrix Diagrammer;

5) Systems Designer – набор средств проектирования ПО, включающий в себя средство построения структуры реляционной базыданных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуруи логику приложений, реализуемую хранимыми процедурами на языкеPL/SQL (ModuleDataDiagrammer, ModuleStructureDiagrammerиModuleLogicNavigator;

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

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

8) Repository Reports – генератор стандартных отчетов, интегрированный с Oracle Reports.

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

Физическая среда хранения репозитория – база данных Oracle.

 

5. Технология Borland

Компания Borland (www.borland.com) в результате развития собственных разработок и приобретения ряда компаний представилаинтегрированный комплекс инструментальных средств, реализующих управление полным жизненным циклом приложений (ApplicationLifeCycleManagement (ALM)). В соответствии с технологиейBorland процесс создания ПО включает в себя пять основных этапов: 1) определение требований; 2) анализ и проектирование; 3) разработка; 4) тестирование и профилирование; 5) развертывание.

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

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

Средство анализа и проектирования Together CONTROLCENTER разработано компанией TOGETHERSOFT. В основе его применения лежитодин из вариантов подхода «быстрой разработки ПО» под названиемFeatureDrivenDevelopment (FDD).

TogetherCONTROLCENTER–интегрированнаясредапроектированияи разработки, поддерживающая визуальное моделирование на UML, с последующим написанием приложений для платформ J2EE (Java) и.Net (С#, C++ иVisualBasic). Кроме базовой версии имеется уменьшенный вариант системы для индивидуальных разработчиков и небольших групп (Together Solo), а также редакции для платформы IBMWEBSPHERE и среды разработки Jbuilder.

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

Инструментальные средства тестирования появились в составекомплекса Borland в результате покупки компании Optimizeit. Книмотносятся Optimizeit Suite 5, Optimizeit Profiler for.NET и OptimizeitSERVERTRACE. Первые две системы позволяют выявить потенциальныепроблемы использования аппаратных ресурсов – памяти и процессорных мощностей на платформах J2EE и.Net соответственно. Интеграция Optimizeit Suite 5 в среду разработки Jbuilder, а Optimizeit Profiler – в C#Builder и Visual Basic.Net позволяет проводить контрольныеиспытания приложений по мере разработки и ликвидировать «узкиеместа» производительности. Система Optimizeit SERVERTRACE предназначена для управления производительностью серверных J2ЕЕ-приложений с точки зрения достижения заданного уровня обслуживанияи сбора контрольных данных по виртуальным 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 и других поставщиков синергетическая интеграцияпока остается делом будущего, однако ее принципы уже начинаютреализовываться.