3.4. Конструирование модели процесса

На практике программирующие организации редко применяют приведенные абстрактные модели процессов в «чистом виде». Как правило, используя известные модели и учитывая конкретные особенности и условия, организация создает специфические модели «под се­бя», которые наилучшим образом учитывают особенности организации.

Основными «методами» конструирования конкретных процессов разработки являются, конечно, здравый смысл и опыт. Невозможно дать в учебнике короткий набор рекоменда­ций, заменяющих эти важнейшие качества. Но можно привести пример конструирования конкретного процесса.

Вообще говоря, есть много общего в процессе разработки и в процессе конструирования описания процесса разработки.¹⁸ Действительно, ведь само описание процесса разработки, как мы показали ранее, фактически является алгоритмом, только исполнителем этого ал­горитма является не компьютер, а программирующая организация. Следовательно, в про­цессе конструирования описания процесса разработки наблюдаются примерно те же фазы, что и в процессе разработки: выявление требований, выбор архитектуры, реализация и валидация. Применительно к конструированию процесса реализация подразумевает опреде­ление конкретных процедур (алгоритмов) по которым должен выполняться сконструиро­ванный процесс разработки.

Оставшаяся часть данного раздела до конца темы представляет собой пример сконструи­рованного конкретного процесса разработки для некоторой гипотетической программи­рующей организации.

¹⁷ Откуда и происходит название модели.

3.4.1. Выявление требований к процессу

Рассмотрим гипотетическую организацию, разрабатывающую программное обеспечение на заказ. Допустим, организация выявила у себя следующие особенности.

• Договорные отношения с заказчиками. Организация проводит проекты по раз­работке программного обеспечения для сторонних заказчиков на договорных нача­лах. Каждый проект регулируется отдельным договором. Комплект договорных документов соответствует сложившейся отечественной практике.

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

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

• Гарантированный конечный успех. Для расширения и стабилизации круга заказ­чиков требуется гарантированный конечный успех каждого отдельного проекта, даже если это требует дополнительных внутренних расходов на проведение проек­та.

¹⁸ Выражаясь терминами, принятыми в унифицированном языке моделирования UML, можно сказать, что процесс кон­струирования описания процесса разработки является мета процессом по отношению к процессу разработки.

Для такой организации целесообразно построить комбинированную модель процесса, и дифференцировать ее по типам проектов.

Сформулируем требования к конструируемой модели процесса.

• Учет особенностей организации. Процесс должен учитывать выявленные особен­ности организации и не должен им противоречить.

• Использование стандартных элементов. Процесс должен быть описан в терми­нах, приведенных в предыдущих разделах и опираться на известные абстрактные модели процессов. Использование принципиально новой модели нежелательно.

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

• Область применения. Конструируемое описание должно описывать только про­цесс разработки программного обеспечения. Другие процессы, например, договор­ные отношения с заказчиком, описывать нежелательно.

Замечание по конструированию. В число требований включены как свойства, которыми конструируемый процесс должен об­ладать, так и свойства, которыми он не должен обладать.