Software & Systems

Усложнение программных изделий (ПИ), повышение требований к их надежности и качеству при постоянно растущих объемах производства неизбежно ведут к нехватке специалистов, квалификация которых соответствовала бы решаемым задачам. Создание и использование инфраструктуры, обеспечивающей внедрение и поддержку процесса разработки надежных ПИ, выработку методологии управления программными проектами, повторяемости и предсказуемости сроков поставки качественного ПИ – возможные пути решения данной проблемы [1].

В качестве методологии создания такой инфраструктуры выступают стандарты разработки программного обеспечения (ПО) и, например, модель зрелости способностей предприятия к разработке ПО (SEI SW – CMM) [2]. В соответствии с CMM, каждая организация определяет технологию производства ПО – стандартный процесс организации. Каждый новый проект разработки ПО должен выполняться в строгом соответствии со стандартным процессом (СП), описанным в специальной книге процесса.

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

«Производственный процесс проекта – это производственный процесс, используемый в конкретном проекте. Он представляет собой четко охарактеризованный и понятный производственный процесс, описанный в терминах программных стандартов, процедур, инструментов и методов. Этот процесс разрабатывается путем адаптации СППО к конкретным характеристикам проек- та» [2]. Таким образом, когда необходимо учесть особенности выполняемого проекта, осуществляется настройка СП под конкретный проект. Такие изменения должны выполняться по определенной в книге процесса формальной процедуре настройки СП на проектный процесс.

В работе [3] приводится методика разработки, внедрения и сопровождения СП в организации, разрабатывающей ПИ.

На первом этапе перед организацией ставятся реальные цели по достижению в хронологическом порядке уровней зрелости модели СММ и составляется долгосрочный план внедрения СП.

На втором этапе из множества требований ключевых областей модели СММ выбирается наиболее подходящее подмножество для конкретных условий работы данной организации и выделяется наиболее актуальное для реализации в первую очередь.

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

Для достижения следующих уровней зрелости СММ осуществляется доопределение компонентов СППО с последующей разработкой, внедрением и улучшением доопределенной части СП [3].

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

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

Возможна ситуация, когда в основе проектов, выполняемых организацией, лежит более чем один «типовой» проект. Например, в рамках одной и той же организации используются различные подходы к разработке ПИ – классический подход [4] и подход быстрой разработки [5]. В этом случае СППО должен содержать процессы, обеспечивающие успешную разработку различных типовых проектов. Назовем их типовыми проектными процессами (ТПП). Пусть в организации используется n типовых проектных процессов, присвоим им порядковые номера от 1 до n, например ТППj для процесса j-го типового проекта, тогда определение проектного процесса может быть представлено схемой, показанной на рисунке 2.

Здесь СППО определяется множеством типовых проектных процессов. В основе выбора ТПП лежит поиск проекта, аналогичного начинаемому, среди множества имеющихся типовых проектов. На схеме в качестве такого аналога взят j-й типовой проект, что определяет выбор связанного с ним проектного процесса (ТППj). После соответствующей настройки типовой процесс становится искомым процессом проекта i (ППji).

Рассмотрим ситуацию, когда начинаемый проект не имеет аналогов среди проектов, разрабатывавшихся ранее. Здесь главной проблемой становится гарантия успешности завершения проекта, так как представление об особенностях его реализации не имеет проверенного на опыте «процессного» обеспечения. Средством разрешения названной проблемы может быть введение в схему обратной связи, позволяющей судить, насколько адекватно реальному проекту определен его проектный процесс. Таким образом, сбор и анализ метрик (МПji) проводится не только в целях совершенствования СППО, но и в целях совершенствования текущего проектного процесса. При выявлении отклонений в зависимости от их серьезности уточняется либо настройка проекта, либо сборка с последующей настройкой на выполняемый проект.

Второе отличие связано с необходимостью повышения точности определения ПП. С этой целью СП организации представляется в виде множества элементов СППО, хранящихся в базе данных процесса. «Элемент процесса соответствует четко определенному и ограниченному набору тесно связанных задач (например, элементы оценки ПО, архитектуры ПО, кодирования, экспертной оценки). Описания элементов процесса могут представлять собой заполняемые шаблоны, подлежащие завершению фрагменты, абстрактные рассуждения, которые следует уточнить, или же полные описания, которые могут быть изменены при необходимости». База данных процесса «формируется в целях сбора и использования информации по производственным процессам и их промежуточным программным продуктам, в частности, по их отношению к СППО, содержит (непосредственно или в виде ссылок) фактические данные измерений и информацию, необходимую для их понимания и оценки их корректности и применимости» [2].

Именно наличие базы элементов позволяет сформировать ТПП для проектов, не имеющих аналогов (этап сборки) (рис. 3).

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

1.  Задание характеристик создаваемого изделия.

2.  Определение типа проекта по заданным характеристикам и поиск аналогов в базе данных стандартного процесса (БСП).

3.  Анализ результатов поиска:

•     аналог найден, переход к пункту 4;

•     аналог не найден, переход к пункту 5.

4.  Выбор из БСП ТПП, соответствующего найденному аналогу (рис. 2), переход к пункту 6.

5.  Сборка по заданным характеристикам проекта ТТП из хранящихся в БСП элементов СП (рис. 3).

6.  Настройка элементов процесса в соответствии особенностями создаваемого проекта.

7.  Реализация процесса, сбор метрик.

8.                    Анализ полученных метрик:

•                       процесс разработки изделия завершен, переход к пункту 9;

•                       процесс разработки идет в заданных границах, переход к пункту 7;

•                       отклонения в ходе проекта требуют уточнения настройки, переход к пункту 6;

•                       отклонения в ходе проекта требуют уточнения сборки, переход к пункту 5.

9.                    Обобщение опыта разработки изделия. Внесение необходимых изменений и дополнений в БСП организации.

10.                  Конец [6].

В заключение рассмотрим процедуру сборки ТПП. Сформулируем утверждения, определяющие условия успешности ее завершения.

Утверждение 1. Каждый элемент БСП обладает характеристиками, позволяющими определить возможность его включения в ТПП.

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

Утверждение 3. Пусть Х – множество характеристик элементов БСП и Хi множество характеристик проекта, для которого предстоит построить проектный процесс. Процедура сборки ТПП может быть успешна в том и только том случае, если множество характеристик проекта является подмножеством характеристик элементов СП, то есть Xi Ì X.

Утверждение 4. Пусть Х2j – множество характеристик пар взаимосвязанных элементов БСП, описывающих один из возможных проектных процессов, и Хi – множество характеристик проекта, для которого предстоит построить проектный процесс. Процедура сборки типового процесса будет успешна в том и только том случае, если во множестве характеристик элементов базы СП (X = È Х2j) найдется подмножество Х2k, притом единственное, такое, что Х2k = Хi.

Утверждение 3 дает необходимое условие успешности сборки, утверждение 4 – необходимое и достаточное [7]. Очевидно, что практическое использование утверждения 4 весьма затруднительно, поэтому в дальнейшем для решения проблемы успешности сборки предлагается использовать подходы, основанные на методах автоматического доказательства теорем.

Процедура сборки ТПП.

1.  Анализ необходимого условия успешного завершения процесса (утверждение 3):

•     условие не реализуется, переход к пункту 2;

•     условие реализуется, переход к пункту 3.

2.  Анализ возможности изменения характеристик проекта:

•     характеристики могут быть изменены, изменение характеристик, переход к пункту 1;

•     характеристики не могут быть изменены, сформировать процесс невозможно, переход к пункту 9.

3.  Поиск начального элемента процесса, удовлетворяющего характеристикам проекта.

4.  Анализ результатов поиска:

•     элемент найден, переход к пункту 5;

•     элемент не найден, сформировать процесс невозможно, переход к пункту 9.

5.  Определение выходного продукта элемента.

6.  Поиск элемента, удовлетворяющего характеристикам проекта и имеющего соответствующий входной продукт.

7.  Анализ результатов поиска:

•     элемент найден, переход к пункту 8;

•     элемент не найден; сформировать процесс невозможно, переход к пункту 9.

8.  Анализ типа найденного элемента:

•     найден выходной элемент, процедура построения проектного процесса завершена успешно, переход к пункту 9;

•     найден внутренний элемент, переход к пункту 5.

9.  Конец.

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

В 2003 году компания успешно прошла внешнее оценивание и аттестована на соответствие 3 уровню модели СММ.

Список литературы

1.  Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Процесс разработки программных изделий.-М.: Наука, Физматлит. - 2000. - 176 с.

2.  Паулк М., Куртис Б., Хриссис М.Б., Вебер Ч.В., Гарсия С.М., Буш М. Модель зрелости процессов разработки программного обеспечения - Capability Maturity Model for Software (CMM) / Пер. с англ. - М.: Интерфейс-Пресс, 2002. - 256 с.

3.  Домарацкий А.Н. Управление улучшением стандартного процесса и качеством программных изделий. // Программные продукты и системы. - №4. - 1998. - С.20-24.

4.  Боэм Б.У. Инженерное проектирование программного обеспечения: / Пер. с англ. - М.: Радио и связь, 1985. - 512 с.

5.  Бек К. Экстремальное программирование: / Пер. с англ. - СПб.: Питер, 2002. - 224 с.

6.  Морозов В.П., Пунтиков Н.И. Настройка стандартного процесса организации на реальный проект разработки программного изделия // Тр. СПИИРАН. - Вып. 2.- СПб.: СПИИРАН, 2004. (В печати).

7.  Пунтиков Н.И. Процедура настройки стандарт- ного процесса разработки программного изделия на реальный проект// IX Междунар. конф.: “Региональная информатика-2004” (СПб, 22-24 июня 2004 г.) // Тр. конф. - СПб., 2004. (В печати).