Открытая система поддержки разработки

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

Система 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. Кроме того, в рамках проекта разрабатываются продукты, обеспечивающие адаптацию интегрируемых компонетов к интеграционной среде.