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

Система Naumen Agile Tools (NAT) создается в рамках Федеральной целевой научно-технической программы «Исследования и разработки по приоритетным направлениям развития науки и техники», рассчитанной на 2002-2006 годы (www.fcntp.ru). NAT не конкурирует с коммерческими инструментами разработки. Задача системы состоит в формировании первоначальной технологии и культуры производства программного обеспечения. В дальнейшем компания-разработчик сможет осознанно выбирать более специализированный инструментарий. Кроме того, бесплатная, открытая и функционально полная система NAT может оказаться полезной при обучении студентов технологиям промышленной разработки программного обеспечения.

Проект NAT

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

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

К настоящему времени завершен первый, исследовательский этап проекта; проанализированы требования «скорых» технологий и стандартов качества, выработаны решения для поддержки стандартов качества; исследованы продукты для автоматизации разработки; по результатам анализа приняты решения, связанные с выбором компонентов NAT и продуктов для технической базы модулей, скорректированы требования к модулям системы; разработана концепция проекта, содержащая основные принципы, архитектурные решения, требования и общие технические решения для модулей; разработан рабочий макет системы.

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

Архитектура

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

Модульная структура

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

Рис. 1. Модульная структура NAT

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

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

Базовый процесс разработки

Базовый процесс разработки состоит в настройке процессного сервиса интеграционной среды (рис. 2). При этом можно задать любую методологию и любую модель разработки.

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

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

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

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

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

Основные сущности и связи

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

Рис. 3. Основные сущности и связи системы
  1. Проекты создаются в модуле «Проектный портал» и регистрируются в справочнике.
  2. На основе проектов в модуле «Управление требованиями» разрабатываются системы требований. Сами требования, их связи между собой и с проектами регистрируются в справочнике.
  3. На основе требований в модуле «Управление работами» создаются задачи. Вместе с их связями и требованиями они регистрируются в справочнике.
  4. В соответствии с запланированными задачами в модуле «Конфигурационное управление» создаются версии модулей разрабатываемого программного обеспечения, которые регистрируются в справочнике.
  5. На основе версий модулей в модуле «Управление работами» фиксируются отчеты о трудозатратах, которые регистрируются в справочнике вместе со связями с версиями и задачами.
  6. В соответствии с задачами в модуле «Тести?рова?ние» разрабатываются тесты. Они регистрируются в справочнике. В зависимости от типа теста регистрируются связи тестов с модулями и пакетами требований.
  7. В модуле «Управление ошибками и изменениями» формируются запросы. Они регистрируются в справочнике.
  8. В соответствии с запросами на изменения в модуле «Управление требованиями» разрабатываются пакеты изменений требований. Они регистрируются в справочнике вместе со связями с запросами на изменения.
  9. На основе запросов на исправление ошибок в модуле «Управление работами» планируются работы. Они регистрируются в справочнике вместе со связями с запросами на исправление ошибок.

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

Компоненты системы

Многие компоненты NAT представляют собой продукты, выполняющие отдельные функции (рис. 4). Компоненты были отобраны на основе исследования продуктов категории Open Source. В дальнейшем планируется вести постоянный мониторинг продуктов и при наличии должных оснований заменять версии или компоненты. Среди компонентов — и оригинальные разработки компании Naumen, в том числе модуль управления требованиями NAT RM, интеграционная среда и модуль управления методологией Naumen Kernel, проектный портал NAT PRG. Кроме того, в рамках проекта разрабатываются продукты, обеспечивающие адаптацию интегрируемых компонетов к интеграционной среде.

При отборе компонентов к ним предъявлялись такие требования, как стабильность работы, перспективность, тип лицензирования, поддержка определенных методологий разработки (прежде всего, гибких) и стандартов (преимущественно ISO 9001 и CMMI), наличие достаточной технической базы и интеграционных возможностей (качественный API, многопользовательский и многопроектный режимы работы, поддержка BPEL, IDE Eclipse, C++, Java 1.4, JDK 1.4, использование стандартов HTML 4.0, CSS, JavaScript 1.0, JSP, серверов Tomcat 5.x, Apache, СУБД PostgreSQL и FireBird).

Проектный портал

Основное требование к проектному порталу — поддержка стандарта JSR 168 на портлеты. Они позволяют существенно увеличить скорость разработки приложений, дополнительных модулей и избавляют от необходимости изучать код самого портала. Исследования показали, что выбор открытых компонентов для портала весьма ограничен. Были рассмотрены системы JBoss Portal, eXo Platform, LifeRay, JetSpeed. Наилучшим был признан JBoss Portal, но и он не вполне удовлетворяет общим требованиям, в том числе к функциональности и технической базе. Поэтому на данном этапе проекта принято решение о самостоятельной разработке проектного портала под рабочим названием NAT PRG.

Интеграционная среда и модуль управления методологией

Управление методологией рассматривается в двух аспектах. Первый аспект — управление ролями, процессами и ссылочными информационными связями; второй — управление номенклатурой и форматами документов, атрибутами сущностей. Интеграционную среду и модуль управления методологией следует рассматривать как связанную подсистему, включающую в себя компоненты следующих типов: сервисная шина, сервис процессной интеграции и соответствующие средства управления, сервис ссылочной интеграции («справочник») и соответствующие средства управления, средства управления внутренними настройками модулей NAT, связанными с методологией проектов.

Основным требованием к сервисной шине является поддержка стандарта Java Business Integration 1.0 (JSR-208). Подключение сервисов по протоколу SOAP 1.1 через HTTP, а систем обмена сообщениями — по интерфейсу JMS. От нее ожидают выполнения трансформации XML через XSLT, динамической маршрутизации сообщений (XPath, XQuery), подключения внешней BPEL-среды для управления процессами. Наконец, сервисная шина должна иметь средства управления по протоколу JMX или спецификациям WS-Management, отслеживать неотправленные сообщения и инициировать их повторную доставку, поддерживать аудит обмена сообщениями между компонентами, ведение протоколов событий.

В ходе исследований были рассмотрены семь открытых продуктов для построения сервисных шин (ServiceMix, Open ESB, ObjectWeb Petals, Mule ESB, ObjectWeb Celtix, Mule JBI, Apache Synapse) и 11 коммерческих. Наиболее функционально полными среди открытых продуктов признаны Mule ESB и ServiceMix. В качестве компонента системы выбран ServiceMix, поскольку он, в частности, полностью реализует стандарт JBI.

Основным требованием к средствам управления процессами является реализация стандарта BPEL (в частности, BPEL4WS 1.1) и стандарта JBI для подключения к сервисной шине. Были исследованы шесть открытых продуктов, реализующих BPEL (Active BPEL Engine, Apache Agila, Bexee BPEL Execution, Eclipse ALF, eMAXX MOBE, Process eXecution Engine PXE). В качестве компонента NAT выбран PXE как наиболее функциональный, соответствующий стандарту JBI и имеющий средства управления, достаточные для реализации соответствующего подмодуля управления методологией.

Готовых открытых продуктов, реализующих ссылочную интеграцию в соответствии с концепцией NAT, не найдено. Данная часть интеграционной среды и модуля управления методологией проектов реализуется как самостоятельная разработка в рамках проекта под рабочим названием Naumen Kernel. Аналогичная ситуация сложилась и с адаптацией модулей: эта специфическая задача также будет реализована в рамках Naumen Kernel и, возможно, NAT PRG.

Модуль управления требованиями

Основное требование к модулю управления требованиями — ведение взаимоувязанных систем требований на протяжении всего проекта, увязка требований с работами, релизами, тестами и т.п., а также трассировка требований и контроль за их состоянием на основе состояний связанных сущностей. В ходе исследований были рассмотрены девять открытых продуктов управления требованиями (Ophelia DRES, Essential Management, RegSimile, OpenShore, Report Requirement Documenter, Rambutan, Jeremia, Enager, RAVE), но, как выяснилось, ни один из них не пригоден в качестве компонента системы NAT. Решено самостоятельно разработать модуль под рабочим названием NAT RM.

С учетом важности управления требованиями в современных проектах дополнительно были рассмотрены 46 соответствующих коммерческих продуктов. Составлен перечень характеристик «идеальной» системы управления требованиями: поддержка внешних исходных документов, содержащих требования; визуальное оформление требований; ведение связей требований между собой, с работами, кодом, релизами, тестами и т.п.; трассировка требований по связям; управление семействами подобных требований; автоматизированный аудит и анализ систем требований, наличие средств оценки и ранжирования требований; учет истории и авторства изменений требований; анализ влияния изменений; сбор, обработка и использование статистики требований; наличие средств ведения дискуссий по требованиям. Сейчас модуль реализован как рабочий макет на платформе wiki.

Модуль управления работами

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

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

Модуль управления ошибками и изменениями

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

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

Модуль конфигурационного управления

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

В проекте NAT к подмодулю управления версиями предъявляются такие дополнительные требования: наличие централизованного репозитория кодов; транзакционная атомарность операций с репозиторием, гарантирующая его постоянно стабильное состояние; отслеживание построчной истории файлов. Мы проанализировали 33 открытых продукта для управления кодом, и явным лидером оказался Subversion, который и был принят как компонент NAT. При благоприятных условиях Bazaar-NG и GIT тоже могут оказаться предпочтительными.

Специфическим требованием к модулю управления релизами и конфигурациями является поддержка полного цикла выпуска релиза, в том числе компиляции приложения, создания документации и полностью скомплектованных дистрибутивов, размещения приложения на сервере и генерации отчетов о работе системы. Мы рассмотрели 24 открытых продукта и выбрали Apache Maven 2, Apache Ant и Continuum. В качестве компонента NAT, служащего для управления релизами, выбран Apache Maven 2. В будущем, при включении в NAT функций автоматической и непрерывной сборки, для этой цели предполагается использовать систему Continuum.

Модуль управления тестированием

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

Были проанализированы особенности 33 открытых продуктов. Сформирован набор из восьми продуктов для использования в качестве компонентов NAT: модульное тестирование — Junit; проверка кода — Checkstlye; интеграционное тестирование — MockCreator; тестирование Java GUI — Abbot; тестирование Web GUI — Jameleon; нагрузочное тестирование — Jmeter; профилирование и анализ покрытия кода — Eclipse TPTP; генерация данных — TestGen.

Управление требованиями в NAT

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

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

Wiki — платформа управления требованиями

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

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

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

Тем не менее модуль управления требованиями на базе wiki вполне можно рассматривать как «легкий» вариант для начального применения. Для промышленной реализации будет создан модуль на основе Naumen Kernel — открытой платформы для разработки бизнес-приложений. Он включает в себя стандартный Web-сервер, установленную на нем wiki-платформу MoinMoin и пакет макросов для управления требованиями. Запуск системы сводится к созданию начальной страницы с вызовом инсталляционного макроса, который формирует необходимую совокупность вложенных wiki-страниц. После этого система готова к работе.

Алексей Сивенцев ( info@naumen.ru ) — технический директор проекта Naumen Agile Tools, компания Naumen (Москва).