Продукты 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.

Михаил Кумсков (kumskov@mail.ru ) — сертифицированный инструктор Rational, профессор кафедры вычислительной математики мехмата МГУ (Москва).

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

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

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

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