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

Все сложные проекты разработки программных средств наталкиваются на "стандартные" проблемы: отставание от графика; превышение сметы расходов; несоответствие продукта требуемым функциональным возможностям при формальном выполнении технического задания; низкая производительность и невысокое качество программного обеспечения; высокие затраты на сопровождение, составляющие от 60 до 80% суммарных затрат, выделяемых на развитие ИТ. Если не предпринимать специальных мер, то чем выше техническая сложность проекта, тем острее будут проявляться эти проблемы. Часто проблемы проекта связаны с тем, что: потребности пользователей выявлены не полностью; требования изменяются в ходе проекта, что приводит к большим объемам переделок; серьезные ошибки в проектных решениях обнаруживаются только в конце проекта; управляемость командой разработчиков низка.

В какой-то мере контролировать выполнение проекта позволяет методология Rational Unified Process (RUP), предлагающая использовать в проектах итеративную разработку, управление требованиями, компонентную архитектуру, визуальное моделирование, постоянную проверку качества и контроль изменений. Для реализации этих принципов нужно создать общий репозиторий проекта, а также ввести правила работы с ним как внутри команды разработчиков, так и при взаимодействии с заказчиками.

Репозиторий может быть создан при помощи таких инструментальных средств от IBM/Rational Software, как RequisitePro, ClearQuest, ClearCase, TestManager, а правила работы определяются на основе методологии RUP. В ряде случаев эти правила позволяют снять "болевые точки" проекта и повысить качество создаваемого программного обеспечения, за счет введения процессов с большим или меньшим уровнем формализма и использования единого информационного пространства.

Где взять процесс?

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

Каково положение дел в России? С одной стороны, имеется стандарт ГОСТ Р ИСО МЭК 12207-99 "Информационные технологии. Процессы жизненного цикла программных средств", введенный в действие в июле 2000 года, который определяет, что нужно делать, в том числе, при разработке программных средств и при их сопровождении. Стандарт описывает пять основных процессов.

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

С другой стороны, с процессами и стандартом 12207 не все так просто: подход "бери стандарт и применяй" не проходит. Об этом говорит хотя бы тот факт, что в России в 2002 году были введены в действие два дополнительных ("руководящих") стандарта: стандарт ГОСТ Р ИСО/МЭК ТО 16326-2002 "Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом" и стандарт ГОСТ Р ИСО/МЭК ТО 15271-2002 "Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)". В Rational Software разработано и поддерживается типизированное описание процессов, которым можно следовать на практике [2, 3]. Остается "маленькая" проблема - процессы и поддерживающие их инструментальные средства нужно внедрять - внедрять так же, как и сложные системы управления наподобие ERP.

ERP и Rational

У внедрения систем ERP и инструментальных средств Rational есть принципиально схожие черты.

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

Данные особенности диктуют основные принципы внедрения:

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

С чего начать внедрение? Состав шагов достаточно прозрачен и действительно напоминает внедрение ERP-системы на предприятии. Необходимо:

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

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

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

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

Работы процессов разработки с репозиторием проекта нуждаются в инструментальной поддержке. Важной особенностью RUP является его "независимость" от средств Rational: все упоминания о них вынесены в специальный раздел и отсутствуют в самом описании процессов.

Литература

1. Уайттеккер, Дж. Воас, 50 лет программирования: основные принципы качества. // Открытые системы, 2003, № 3.
2. Рамбо, Г. Буч, А. Якобсон, "Унифицированный процесс разработки программного обеспечения". СПб.: Питер, 2002.
3. Ф. Крачтен, "Введение в Rational Unified Process". М.: Вильямс, 2002.

RUP определяет шесть основных процессов (дисциплин):

• моделирование деятельности организации;
• управление требованиями;
• анализ и проектирование;
• реализация;
• тестирование;
• развертывание

и три вспомогательных:

• поддержка среды разработки;
• управление проектом;
• конфигурационное управление и управление изменениями.