ОБЗОРЫ

Борис Позин, Дмитрий Лапыгин

Проблемы групповой разработки ПО знакомы любому руководителю софтверной фирмы. Для систематизации таких работ и повышения их эффективности предназначена технология программной инженерии, называемая “Конфигурационное управление” (КУ; Configuration management).

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

Эти задачи решаются при помощи КУ, позволяющего:

- установить регламент работ над проектом (никогда не надо забывать правило “80/20”: успешность проекта на 80% определяется регламентом работ и только на 20% - применяемым инструментарием);

- скоординировать действия сотрудников;

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

- ограничить усложнение проекта;

- выделять и повторно использовать базовые компоненты разрабатываемого ПО;

- всегда иметь полный и достоверный перечень версий элементов, участвовавших в процессе сборки продукта;

- определять текущее состояние проекта, выявлять узкие места и своевременно перераспределять ресурсы.

Чтобы грамотно использовать средства версионного контроля, предварительно нужно выделить набор объектов, определяющих структуру будущей системы, и затем контролировать их состояния (из множества заранее определенных) и ход работ по каждому из них (для этого существуют конкретные методологии, например RUP или CMM).

Такими объектами могут быть функционально-логическая модель системы, реляционная модель БД, модули прототипов системы (экраны, меню, отчеты, тексты процедур или классов), системные и программные спецификации, документация. Желательно также контролировать планы проведения тестирования, спецификации тестовых процедур.

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

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

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

Рынок систем КУ

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

Управление конфигурацией

Продукты КУ по их возможностям можно поделить на четыре группы:

1. Обеспечивающие контроль версий (Rational ClearCase, Merant PVCS, Microsoft Visual SourceSafe).

2. Обеспечивающие контроль версий и изменений (Rational ClearCase/ClearQuest, PVCS Professional).

3. Обеспечивающие параллельную разработку, контроль версий, изменений и рабочих процессов (Rational ClearCase/ClearQuest, PVCS Dimensions, CCC:Harvest фирмы Computer Assotiates).

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

Рассмотрим конкретные продукты версионного контроля. Тройка лидеров на этом рынке для платформ Windows/Unix к 2000 г. выглядит так: Rational Software (ClearCase/Quest) принадлежит 37% рынка, Merant (PVCS) - 24%, Microsoft (Visual SourceSafe) - 8%.

Продукт ClearCase, пожалуй, наиболее мощный и соответственно дорогой. Он лучше всего подходит для проектов, в которых участвует не менее 10 разработчиков и которые направлены на создание крупных систем или на выпуск тиражируемого ПО, когда особенно актуальны проблемы отслеживания версий. У ClearCase немало сильных сторон, он, в частности, тесно интегрирован со всеми основными средствами разработки производства Microsoft, Oracle, IBM, Inprise, редактором MS Word, что позволяет отслеживать версии готовящихся в нем материалов и организовывать работу коллектива технических писателей над одним большим документом. В числе недостатков ClearCase - мелкие нестыковки с методологией RUP, а также необходимость серьезного администрирования (нагрузка при работе с продуктом перекладывается с конечных пользователей на администратора).

Продукт PVCS, встроенный во многие системы разработки, предлагает более простой по сравнению с ClearCase версионный контроль. Он хуже автоматизирует работу пользователей и сложнее в применении, но зато не требует отдельного сотрудника-администратора для поддержки небольших групп разработчиков. К его преимуществам можно отнести меньшую стоимость, простоту сопровождения, к недостаткам - определенные проблемы перехода от PVCS Professional к PVCS Dimensions (PVCS Dimensions - это приобретенный Merant продукт сторонней фирмы), слабые средства настройки клиентских мест (в PVCS Tracker нельзя, например, ограничить для конкретного разработчика варианты переходов между состояниями доступных ему объектов, что допускается в ClearQuest).

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

Некоторые фирмы выпускают системы, предназначенные только для отдельных этапов КУ. Это, например, уже упоминавшийся CCC:Harvest, который хорошо автоматизирует процессы параллельной работы при ведении проектов на мэйнфреймах. Кстати, заметим, что в 2001 г. в рамках соглашения между IBM и Rational Software появится новая версия ClearCase для мэйнфреймов, сопряженная со средствами разработки фирмы IBM.