Для удовлетворения общих требований к разработке — снижения затрат путем повышения продуктивности труда разработчиков и уменьшения сложности разработки, не в ущерб качеству конечного продукта — традиционно используются интегрированные среды разработки (integration development environment, IDE), предоставляющие базовые инструменты. Однако за их пределами остаются ключевые этапы жизненного цикла приложений, такие как определение требований, моделирование, тестирование, развертывание и управление изменениями. Поддерживающие эти этапы инструменты, как правило, изолированы друг от друга. В результате группы специалистов, отвечающие за разные задачи в проекте — бизнес-аналитики, архитекторы, программисты, тестировщики — работают разрозненно. Как отмечают в Meta Group [1], подобное состояние вполне соответствует традиционной методологии разработки, когда отдельные процессы идут последовательно друг за другом, но отнюдь не отвечает современным требованиям повышения продуктивности и сокращения затрат. Метод «водопада», как правило, удлиняет время реализации программного проекта, приводит к превышению бюджета и не способствует созданию продукта, отвечающего ожиданиям заказчика. Это своего рода производственный конвейер, рассчитанный на массовый выпуск однотипной продукции.

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

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

Жизненный цикл программного продукта

Рис. 1. Жизненный цикл приложений и его реализация с помощью продуктов Borland

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

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

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

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

Тестирование и профилирование. Испытания разрабатываемой программы проводятся по мере готовности промежуточных версий. Взаимосвязь этого этапа с этапами проектирования и разработки позволяет подготавливать тесты на основе точных знаний о структуре и тонкостях реализации программы.

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

Цементирует все этапы в жизненном цикле процесс управления изменениями, который обеспечивает координацию действий между членами различных групп единой команды проекта. Здесь применяются системы управления конфигурацией программного обеспечения (software configuration management, SCM), в чьи функции входит централизованное хранение данных по проекту, контроль версий, управление внесением изменений в проект и т.д.

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

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

По определению IEEE [2], требование — это «условие или возможность, необходимые пользователю для решения той или иной проблемы или достижения той или иной цели». Управление требованиями определяется аналитиками Meta Group [3] как процесс, гарантирующий, что все специалисты, вовлеченные в проект разработки, знают об определенных требованиях к программному продукту и реализуют процессы, позволяющие эти требования удовлетворить. При всей очевидности того, какое значение имеет четкое задание требований для получения качественного конечного продукта и повышения продуктивности участников разработки, этот этап — и тем более его поддержка с помощью специальных автоматизированных средств — далеко не всегда реализуется со всей необходимой тщательностью. Разработчики часто избегают формализации требований как лишней бюрократической нагрузки, мешающей главному, по их мнению, процессу — собственно программированию. Заказчики также не всегда готовы формализовать и детализировать свои проблемы, полагая, что общей постановки задачи достаточно для того, чтобы разработчики поняли их нужды. Обе стороны заблуждаются. Формальное определение требований со стороны заказчика помогает ему прояснить свои потребности и избежать неясностей в толковании постановки задачи разработчиками. Последние, в свою очередь, получают большую свободу в выборе средств и методов реализации, когда задача понятна до деталей.

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

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

По данным Meta Group, 75% инсталляций систем управления требованиями принадлежит Borland, IBM Rational и Telelogic. При этом все три компании — относительные новички на этом рынке, поскольку решения по управлению требованиями были приобретены ими за последние два года. Так, система CaliberRM стала частью семейства продуктов Borland в результате покупки компании Starbase. В CaliberRM формируются шаблоны для наборов требований заказчика, которые собираются в центральном репозитории. Система предоставляет встроенную поддержку обсуждения требований различными участниками процесса. Права доступа к данным требований, привилегии и ответственность пользователей определяются в системе на ролевой основе.

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

Система обеспечивает экспорт данных в таблицы MS Access и импорт из Word, но пока не поддерживает обмен данными на базе XML Metadata Interchange. Табличное представление требований упрощает их сортировку и задание приоритетов в зависимости от затрат на реализацию и значимости. Для каждого требования реализуется независимый контроль версий. Предоставляются глоссарии для определения специфичных для отрасли, проекта или компании терминов с целью избежать нечеткости определения и двусмысленности толкования требований. CaliberRM поддерживает различные методы визуализации зависимостей между требованиями, с помощью которых пользователь может ограничить область анализа, необходимого в случае изменения того или иного требования. Имеется модуль, который использует данные требования для оценки трудозатрат, рисков и расходов, связанных с реализацией требований.

CaliberRM обеспечивает функциональную (на базе прикладных интерфейсов) интеграцию с другими ALM-решениями Borland — системой конфигурационного управления StarTeam и средой моделирования Together, что позволяет отслеживать влияние изменений в требованиях на исходный код и гарантировать соответствие архитектуры системы задачам заказчика. Интеграция системы со средствами тестирования компании Mercury Interactive обеспечивает быстрый выбор необходимых тестовых испытаний для проверки выполнения заданных и измененных требований, а возможность экспорта данных в систему календарного планирования MS Project — отображение требований как задач проекта.

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

На следующем этапе проектирования разработчики отвечают на вопрос «Как должна быть построена система, чтобы реализовать определенные на предыдущем этапе требования». Признанным стандартом моделирования архитектуры объектно-ориентированных приложений сегодня стал язык UML. В системах проектирования на базе UML создаются диаграммы, которые в совокупности представляют единую концепцию программного продукта. Затем набор диаграмм переводится в конкретный язык программирования. Помимо разработки архитектуры новых приложений, средства проектирования позволяют создавать визуальные представления существующих систем и анализировать их внутреннюю структуру для повышения эффективности внесения изменений в такие программы. Безусловно, наиболее известным решением в области UML-проектирования остается система Rational Rose.

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

Together ControlCenter реализует генерацию исходных кодов по последовательности UML-диаграмм. В системе реализована технология LiveSource, которая обеспечивает синхронизацию между проектом приложения и изменениями — при внесении изменений в исходные тексты меняется модель программы, а при изменении модели надлежащим образом изменится текст на языке программирования. Все это происходит в реальном времени и исключает необходимость вручную модифицировать модель или переписывать коды. Наличие подобных возможностей наряду с соответствием стандарту UML в Aberdeen Group [4] считают ключевыми критериями выбора эффективной системы моделирования. Контроль версий осуществляется благодаря функциональной интеграции решений Together и системы StarTeam. Также поддерживается интеграция с системой конфигурационного управления Rational ClearCase. Помимо проектирования и разработки компонентных приложений для платформ J2EE и .Net, ControlCenter поддерживает визуальное XML-моделирование, моделирование бизнес-процессов, разработку Web-сервисов и баз данных.

Важной особенностью систем семейства Together является то, что они предоставляют средства автоматизированного инспектирования исходных кодов для повышения качества архитектуры и реализации программ. Сюда относятся средства аудита и оценки программ на базе метрик, дополняющие традиционные способы проверки кода вручную. Как отмечается в [5], проверка кода (code review) как важнейший инструмент повышения качества разрабатываемого продукта не теряет своей актуальности и в «быстрых» методиках. Скажем, в ХР проверка кода является непрерывным процессом, поскольку экстремальное программирование обязывает работать над исходными текстами в парах. Обычно результатом проверки кода становится рефакторинг (refactoring), т.е. изменение внутренней структуры программы с целью упрощения ее понимания и снижения затрат на модификацию.

Проверка кода является частью процесса инспектирования программных средств — оценка программного продукта, в ходе которой группа специалистов, среди которых не должно быть автора программы, проверяет требования, архитектуру или код программы с целью выявить ошибки, нарушения корпоративных стандартов и другие проблемы [2]. Что касается проверки кода, то она не только способствует тому, что программа становится более понятной и простой в сопровождении, но и позволяет повышать квалификацию новых специалистов в команде разработчиков. Определенная часть этой работы, например, оценка уровня реализации бизнес-логики программы, остается за человеком. Но для целого ряда функций автоматизация способна значительно повысить эффективность и продуктивность процесса проверки. Например, в компании TogetherSoft четырем специалистам было поручено провести в течение 15 минут аудит небольшого фрагмента программы на Java. За это время ими было выявлено 21 нарушение, в то время как средствами ControlCenter в том же фрагменте исходного кода всего за 2 секунды было обнаружено 150 несоответствий принятым стандартам программирования на Java [5].

Аудит — статическая проверка исходного кода программы с целью нахождения несоответствий принятым в организации стандартам использования языка программирования. В ControlCenter для языков Java и С++ реализованы такие категории аудита исходного кода, как стиль кодирования, критические ошибки моделирования, документирование, именование, производительность, общие ошибки использования языка, чрезмерный объем кода, ошибки в использовании EJB и др.

Более «тонкой материей» в процессе проверки кода является оценка на базе метрик. Если аудит сосредоточен главным образом на синтаксическом анализе текста программы, то метрики позволяют оценить уровень ее объектной архитектуры. Метрики — это точные количественные данные, на основе которых оцениваются размер, сложность и зависимости в тексте программы, а реализация метрик — попытка подвести математическую основу под такую расплывчатую категорию, как качество программы. Оценка на базе метрик позволяет устранить нарушения базовых принципов объектно-ориентированной разработки и провести эффективный рефакторинг программы. Сбор и анализ метрик — крайне трудоемкая задача, поэтому оценка на базе метрик только выигрывает от автоматизации. Together обеспечивает анализ на базе метрик для таких категорий, как базовые эвристики, зависимости, связи, инкапсуляция, размер программы, наследование, соотношение комментариев и т.д., для языков программирования Java, C++, C#, Visual Basic 6 и VB.Net.

Разработка

В течение почти всей своей 20-летней истории деятельность Borland была сосредоточена именно на создании сред разработки, причем отличительной чертой этой компании был стабильный нейтралитет в отношении платформ — Borland предлагала инструментарий как для Java (JВuilder), так и для Windows (Delphi, C++Builder). Принципиальная позиция этой «Швейцарии» в мире разработки получила логическое продолжение в выпуске новых систем для платформы .Net.

Основные усилия по совершенствованию сред разработки Borland сосредотачивает сегодня на интеграции с другими этапами жизненного цикла приложений, прежде всего, с решениями по анализу и проектированию Together. Уже упоминалась редакция Together для системы JВuilder, которая обеспечивает разработку компонентных приложений на платформе J2EE. Связь со средствами моделирования программ реализована и в новой среде разработки C#Builder для платформы .Net Framework, которая имеет также возможности интеграции с системами тестирования и средствами развертывания приложений.

C#Builder — среда разработки на языках С# и Visual Basic .Net. Одно из ключевых свойств этой системы — предоставление единого интерфейса для работы с разными базами данных. В C#Builder поддерживаются драйверы доступа к данным из ADO.Net, но их возможности существенно расширены с помощью модуля Borland Data Provider (BDP). Пользователь выполняет все операции с данными и SQL-запросы с помощью общего для всех разновидностей баз данных интерфейса Data Explorer, а BDP осуществляет автоматическое преобразование типов данных .Net в типы для различных баз данных, включая Oracle 9i, IBM DB2, Microsoft SQL Server 2000, Borland InterВase. C#Builder включает широкий спектр технологий, необходимых для работы распределенных приложений: Web-сервисы, компонентные среды СОМ+ и .Net Remoting, а также CORBA и EJB, для которых используются механизмы еще одной новой разработки Borland — системы Janeva.

C#Builder поддерживает новую парадигму разработки, определяемую проектированием (design-driven development), известную также под названием МDA (model-driven architecture). Спецификации MDA разработаны консорциумом OMG [6], а Borland одной из первых реализовала MDA в конкретном инструментарии. Речь идет о системе Enterprise Core Objects (ECO), которая позволяет без программирования получить работающую программу для .Nеt непосредственно по UML-модели, созданной средствами Together или импортированной из другой системы моделирования с помощью механизмов XMI. На C# пишется только пользовательский интерфейс. Усилия разработчиков могут быть сосредоточены на бизнес-логике и ее воплощении в модели, а программу на C# они даже не видят.

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

Чем позже будут обнаружены ошибки и уязвимые места программы, тем дороже обойдется их исправление, поэтому наиболее оптимальное время разрешения проблем — разработка (рис. 2).

Рис. 2. Стоимость исправления недостатков производительности на разных стадиях жизненного цикла

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

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

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

Средства профилирования семейства Borland Optimizeit интегрированы с системой нагрузочного тестирования LoadRunner от Mercury Interactive. Кроме того, в среду разработки JВuilder интегрирован продукт Mercury ТestDirector для управления скриптами тестирования.

Развертывание

У того, кто ведет разработку на Java, есть широкие возможности выбора сервера приложений для развертывания готовой системы, в частности, Borland предлагает сервер приложений Enterprise Server: AppServer Edition для J2ЕЕ-приложений и Web-сервисов; VisiBroker Eition для распределенных приложений в гетерогенной среде, требовательных к времени отклика и ориентированных на инфраструктуру CORBA; Web Edition для Web-приложений.

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

Для Borland отсутствие приверженности отдельно взятой платформе или стеку протоколов — почти религиозный принцип. Очередной важный шаг на этом пути состоит в выпуске продукта, обеспечивающего прозрачную совместимость приложений для .Net с инфраструктурами J2EE и CORBA. Речь идет о системе Janeva.

Janeva предоставляет клиентским и серверным программам для .NET возможность обращаться к гетерогенным серверным компонентам J2EE и CORBA, причем совершенно прозрачно для разработчика этих программ и не требуя использования дополнительных аппаратных или программных ресурсов (см. рис. 3). Janeva включает компиляторы Java-to-C# и CORBA IDL-to-C#, которые автоматически генерируют коммуникационные элементы — стабы (stubs) и сборки (assemblies) на языке C#. Тем самым обеспечивается возможность обращения к .Net из Java-программ и объектов CORBA. Кроме того, Janeva предоставляет библиотеки времени выполнения, которые вызываются .Net-приложением для преобразования удаленных вызовов этой платформы в вызовы по IIOP (Internet Intеr-ORB Protоcol) — производительному, масштабируемому и защищенному протоколу для связи распределенных компонентов в среде CORBA. Таким образом, пользователь Janeva продолжает работать в привычной среде .Net, используя интерфейсы, процедуры определения свойств и вызова методов и типы данных, и при этом получает доступ к объектам CORBA и компонентам EJB. В результате совместимость двух платформ достигается минимальными усилиями и практически без риска для проекта. Janeva поддерживает Microsoft Common Language Runtime, поэтому может быть использована для любого языка программирования, совместимого с CLR, включая C#, J#, Visual Basic .Net и Visual C++ .Net.

Рис. 3. Интеграция платформ средствами Janeva

В целом, Borland предлагает три основные возможности интеграции для развертывания разнородных систем:

  • интеграция низкого уровня на базе технологий Janeva;
  • создание модели бизнес-системы и затем разработка компонентов этой системы для разных платформ. Поскольку среда проектирования Together позволяет генерировать исходные тексты программ как на C#, так и на Java, на основе одной UML-модели с помощью средств Together можно создавать прикладные компоненты для разных платформ.

Координация и управление изменениями

В системе управления конфигурациями и изменениями сосредоточена сущность концепции ALM: именно она объединяет основные фазы жизненного цикла приложения и интегрирует продукты, эти фазы поддерживающие, поэтому управление изменениями вместе с системой StarTeam расположено в центре круговой диаграммы управления жизненным циклом «от Borland» (рис. 1).

StarTeam, появившаяся у компании в результате приобретения Starbase, имеет развитую функциональность, которая помимо базовых для систем конфигурационного управления задач контроля версий включает управление изменениями, отслеживание дефектов, пересмотр файлов, управление требованиями (в интеграции с CaliberRM), управление потоком задач и управление проектом, а также дискуссионные форумы. Система рассчитана на распределенные проектные группы и поддерживает совместную работу участников, в том числе географически удаленных, через Сеть.

StarTeam предоставляет централизованный репозиторий для хранения и совместного использования членами проектной группы информационных активов проекта, которые привязываются к соответствующим инструментальным средствам и процессам жизненного цикла. Система обеспечивает доступ к актуальной информации по проекту тем членам группы, которым она предназначена, осуществляя контроль прав доступа на разных уровнях — от проекта в целом вплоть до отдельного ресурса. Система управляет потоком запросов на изменения, выставляет приоритеты и исключает дублирование, проверяет выполнение изменений и обеспечивает генерацию сообщений ответственным за изменение членам проектной команды. StarTeam предоставляет возможности управления задачами, обеспечивая назначение работ определенным группам специалистов в проектной команде. Например, завершение разработки некоторой части приложения будет отражено в подсистеме управления изменениями, затем StarTeam выдаст задание на проведение соответствующих тестов. Этот компонент системы интегрирован с MS Project. Кроме того, в StarTеam формируется база знаний о проблемах, которая используется членами команды во время проведения централизованных дискуссионных форумов.

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

Виды интеграции

Концепцию управления жизненным циклом приложения невозможно реализовать без интеграции инструментальных средств, используемых на разных этапах. Стратегическая задача Borland на ближайшие несколько лет — обеспечить полную прозрачность и отслеживаемость всех процессов разработки в течение жизненного цикла; она решается путем интеграции всех систем в полное ALM-решение [7]. Уже сегодня многие системы Borland имеют развитые возможности взаимосвязи не только друг с другом, но и с системами других поставщиков. Так, совместная работа системы проектирования Together с системой согласования требований CaliberRM позволяет рассматривать в процессе проектирования только те функции, которые предусмотрены на этапе определения требований. Интеграция Together Edition for Jbuilder и IDE Jbuilder обеспечивает непосредственное отображение изменений UML-модели в тексте программы. Аналогичные возможности существуют для среды IBM WebSphere. Система StarTeam управляет этими изменениями, а новые редакции инструментов Borland для платформы .Net позволяют использовать в качестве среды разработки не только C#Builder, но и Visual Studio .Net.

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

Более перспективны высокие уровни интеграции. «Встроенная» (embedded) интеграция обеспечивает работу с окном одной системы, находясь при этом в другой. Например, не выходя из среды разработки Jbuilder можно просматривать графики производительности, которые создает система испытаний Optimizeit. И наконец, самый высокий уровень интеграции — «синергетический» (synergistic), позволяющий прозрачно сочетать функции двух различных продуктов, так чтобы разработчики даже не замечали, что работают с разными системами. Для большинства решений Borland и других поставщиков синергетическая интеграция — дело будущего, однако ее принципы уже реализованы с помощью технологий Janeva. Janeva обеспечивает взаимное конвертирование между платформами J2EE и .Net, так что программные продукты для .Net могут напрямую использовать компоненты на Java, при этом от разработчиков таких приложений не требуется знаний в области объектных технологий CORBA и EJB.

***

По прогнозам IDC [8], рынок средств разработки и развертывания приложений, испытавший определенный кризис в 2002 году, в ближайшее пятилетие ожидает устойчивый рост в среднем на 6,3% в год. Определяющим фактором для развития этой положительной тенденции является стремление компаний-разработчиков повысить продуктивность своей работы, сократить сроки вывода новых продуктов на рынок, контролировать расходы и быстро получать отдачу на сделанные инвестиции. Инструментом для достижения этих целей становится использование сред разработки, позволяющих снизить сложность процессов создания программных продуктов, увеличить их эффективность, уменьшить затраты на разработку и максимально использовать потенциал новых технологий. Аналитики сходятся на том, что основное направление развития инструментальных средств — их сквозная интеграция, переход от сред к интегрированным пакетам, объединяющим возможности определения требований, моделирования, разработки, тестирования, управления изменениями и развертывания приложений. В ближайшие годы такие пакеты поддержки жизненного цикла, помимо перечисленных возможностей будут включать в себя средства управления потоками работ и проектами. Рынок таких инструментальных средств ожидает глобальная консолидация, обещающая принести значительные выгоды разработчикам.

Литература
  1. T. Murphy, Accelerating J2EE Application Delivery. Meta Group White Paper, June 2003.
  2. IEEE Standard Glossary of Software Engineering Terminology, 1997.
  3. T. Murphy, Mastering the requirements of requirements management. Meta Group, April 2003.
  4. W. Kernochan, Design-driven development: good only if done well. Aberdeen Group, March 2003.
  5. R.C. Gronback, Software remodeling: improving design and implementation management. TogetherSoft, 2002.
  6. R. Soley and the OMG Staff Strategy Group, Model Driven Architecture. OMG White Paper, November 2000.
  7. Наталья Дубова, Управление жизненным циклом приложений. Интервью с Дэвидом Интерсимоном. // Открытые системы, 2003, № 6.
  8. Worldwide application development and deployment forecast summary, 2003-2007. IDC, March 2003.

В методологии Rational Unified Process (RUP), предложенной компанией Rational Software, определяются пять уровней зрелости управления требованиями:

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

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

MDA

Вся эволюция программирования, основанная на стремлении снизить сложность и повысить продуктивность процессов разработки, сопровождалась повышением уровня абстракции написания программ — от машинных кодов к ассемблеру, от ассемблера к высокоуровневым языкам. Предложенный OMG подход MDA (model-driven architecture) позволяет при создании приложений сконцентрироваться на создании абстрактной бизнес-модели, практически полностью автоматизировав ее перевод в коды на базе конкретной инфраструктуры промежуточного слоя — CORBA, EJB, COM+, .Net и т.д.

Рис. Три этапа реализации Model-Driven Architecture

Разработка в соответствии с принципами MDA проходит в три этапа (рис.4). На первом создается полностью независимая от среды разработки и платформы визуальная UML-модель, описывающая бизнес-логику будущего приложения (доменная модель). Для ее формирования стандарт OMG MDA предоставляет несколько базовых моделей, описывающих структуру определенной бизнес-среды, например, базовая модель Enterprise Computing с компонентной структурой и взаимодействием на основе транзакций или модель Real-Time Computing с специальными механизмами контроля ресурсов. На следующем этапе абстрактная модель «конкретизируется», преобразуясь в UML-модель приложения для определенной платформы. Модель приложения включает специфические для данной архитектуры элементы построения и интеграции прикладных систем, сохраняя семантику доменной модели. Третий этап завершает трансформацию модели в коды программы. Для автоматизации последовательного преобразования модели от этапа к этапу используются шаблоны, отображающие специфику технологической платформы и языка реализации приложения.

Формирование логики приложения на самом высоком уровне абстракции и автоматическая генерация всех элементов, связанных с платформой реализации приложения способствуют сокращению сроков проектирования, тестирования и развертывания, полностью исключая затраты времени и сил на кодирование. Последнее обстоятельство гарантирует высокое качество кода. Примеры реализации MDA — системы Compuware OptimalJ и Borland ECO.

«Живое» программирование

Требования рынка заставляют ускорять циклы разработки, но не позволяют снижать качество. Необходимость делать все быстро подчас вынуждает отказываться от следования строго документированным процессам разработки, однако отсутствие четкой организации труда отрицательно сказывается на продуктивности команды и, в итоге, на конечном результате их работы. Поиск компромисса между сложными формальными процессами и облегченными методами быстрой разработки привел к появлению методологии разработки под названием agile («проворный», «быстрый», «живой»). Принципы данного подхода сформулированы в Agile Manifesto (www.agilemanifesto.org), который был написан в феврале 2001 года семнадцатью представителями ряда «нетрадиционных» направлений в программировании, включая XP [1], Feature Driven Development, Crystal, Adaptive Software Development, SCRUM.

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

  • Модульность. Процесс разработки разбивается на отдельные задачи, которые в совокупности позволяют преобразовать концепцию системы в реализацию. Задача - единица работы, имеющая определенную цель.
  • Итеративность. Процесс разработки разбивается на короткие по времени циклы. В ходе каждой итерации выполняется некоторое множество задач, итерации завершаются в течение нескольких недель. Итеративность отвечает тем реалиям разработки, что в системе невозможно сразу удовлетворить все требования заказчика, приходится постоянно вносить изменения, чтобы устранить ошибки и точнее следовать поставленным целям. Поэтому итеративность подразумевает непрерывное взаимодействие с заказчиком.
  • Ограниченность во времени. Для каждой итерации задаются жесткие ограничения по времени, и в соответствии с этим составляется календарный план проекта.
  • Экономичность. В процесс разработки включается минимальное число задач, необходимых, чтобы достичь поставленной цели и снизить риски проекта.
  • Адаптивность. В ходе разработки могут возникнуть новые риски, не учтенные при планировании проекта, и может оказаться так, что ранее определенные задачи не позволяют реализовать проект. В этом случае список задач, составляющих процесс, может быть изменен.
  • Постепенность. Проект разбивается на части, которые могут разрабатываться параллельно, в разное время и с разной скоростью. Модульное тестирование для разных частей проекта проводится независимо, по его завершении часть интегрируется в систему.
  • Ориентация на людей. Для реализации каждой части проекта формируются небольшие группы разработчиков, что позволяет им не чувствовать себя изолированно в большом коллективе проекта.
  • Коллаборативность. Стимулируется постоянное сотрудничество между участниками проекта. Это необходимо для того, чтобы эффективно интегрировать разные компоненты системы при параллельной работе.
  • Взаимодополняемость. Некоторые задачи, будучи реализованы в совокупности, дают лучший результат по сравнению с реализацией изолированно друг от друга. Определенные задачи можно использовать для оценки и улучшения результатов ранее выполненных задач.
Литература
  1. К. Бек, Экстремальное программирование. // Открытые системы, 2000, № 1-2.
  2. R. Miller, The Dynamics of Agile Software Processes. Borland Development Network, February 2003.