Продукты 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: все упоминания о них вынесены в специальный раздел и отсутствуют в самом описании процессов.
Литература
- Уайттеккер, Дж. Воас, 50 лет программирования: основные принципы качества. // Открытые системы, 2003, № 3.
- Рамбо, Г. Буч, А. Якобсон, "Унифицированный процесс разработки программного обеспечения". СПб.: Питер, 2002.
- Ф. Крачтен, "Введение в Rational Unified Process". М.: Вильямс, 2002.
RUP определяет шесть основных процессов (дисциплин):
- моделирование деятельности организации;
- управление требованиями;
- анализ и проектирование;
- реализация;
- тестирование;
- развертывание
и три вспомогательных:
- поддержка среды разработки;
- управление проектом;
- конфигурационное управление и управление изменениями.