Не так сложен SPICE, как его написали

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

Большинство стандартов, даже будучи международными, имеют американское происхождение. Отечественные программисты, работающие на американских заказчиков, уже обратили внимание на национальные особенности стилей мышления. Американец большей частью мыслит индуктивно, собирая факты и складывая их один за другим, мало заботясь об их упорядоченности (корова, белая корова, коза, теленок...). Нам же, по-видимому, вследствие математического тренинга, пройденного еще в средней школе, необходима некая общая схема (вид — пол — возрастная группа — цвет). К сожалению, многие перечни (на сотни пунктов) в стандартах выглядят подобным образом. Для того чтобы стандарт прижился на отечественной почве, необходимо его не просто перевести, но и представить в некоторой структурно упорядоченной форме.

Попробуем схематически интерпретировать базовые элементы стандарта SPICE (Software Process Improvement Capability dEtermination), официально именуемого ISO/IEC TR 15504 — «Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем» [1]. В отличие от других стандартов ISO, он открыт (см. http://www.sqi.gu.edu.au/spice).

Стандартов, регламентирующих программные процессы и качество программ, а также способы их усовершенствования, довольно много. SPICE — попытка объединить наиболее значимые из них. Это, прежде всего ISO 12207, регламентирующий процессы жизненного цикла программного обеспечения; CMM, определяющий модель зрелости процесса разработки ПО; стандарты серии ISO 9000, рассматривающие проблемы управления качеством, а также ряд национальных стандартов и нормативов крупных компаний. В результате, несмотря на отсылки к смежным стандартам ISO, при уточнении деталей объем SPICE превысил 500 страниц. Если же учесть, что являющаяся сердцевиной стандарта модель программных процессов содержит перечни и таблицы в сотни пунктов, то становится понятно, почему его сторонятся менеджеры проектов.

Основные цели SPICE — помощь потребителям (заказчикам) программной продукции в выборе надежного поставщика и поддержка поставщика (разработчика) в его стремлении усовершенствовать процессы разработки. Для достижения поставленной цели предлагается оценить, как ведется работа. Оценка, в свою очередь, производится путем сравнения с эталонной моделью (фактически той же, но несколько менее детальной, что и в ISO 12207). Рассмотрим модель и оценочные показатели, на основе которых производится сравнение: это, с одной стороны, наиболее сложные, а с другой, ключевые для понимания стандарта в целом компоненты. Остальное в основном связано с установкой рейтингов, подбором команды оценщиков и т.п., все это наглядно и толково сопровождается иллюстративными примерами из жизни — и более связано с общими проблемами управления, чем со спецификой программирования.

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

Эталонная модель SPICE

Деятельность по созданию и приобретению программного продукта или услуги, в соответствии с эталонной моделью SPICE представляет собой взаимодействующие процессы без каких-либо ограничений на последовательность. Каждый процесс должен включать в себя некоторые базовые операции (base practice). Процессы оцениваются в зависимости от степени организации/управления:

• 0 - не выполняется;
• 1 - выполняется неформально;
• 2 - планируется и контролируется;
• 3 - четко определяется;
• 4 - количественно регулируется;
• 5 - постоянно совершенствуется.

Для того чтобы оценить уровень процесса, проверяется наличие у него некоторых общих свойств, формулируемых в терминах обобщенных операций (generic practice). Такая операция представляет собой действия, уместные для любого процесса: выполнение, планирование, фиксация состояния, подготовка методики, использование количественных оценок, обучение персонала распределение ответственности и т. п.

В SPICE заявлена наглядная форма, иллюстрирующая отношения процессов и их базовых операций к обобщенным операциям. Форма представляет собой таблицу, в столбцах которой размещаются категория процесса, потребитель, а в строках — уровень, общие свойства, обобщенная операция. Тот факт, что некоторый процесс X использует обобщенную операцию Y (крестик на пересечении соответствующего столбца и строки), означает наличие определенной базовой операции в этом процессе. К сожалению, в стандарте не дается заполненной таблицы. Вместо этого базовые операции приведены списками для соответствующих процессов. Ясное сопоставление базовых операций обобщенным отсутствует. Более того, некоторые из обобщенных операций вынесены в базовые операции служебных (supporting) процессов (документирование, управление конфигурациями и др.). По-видимому, исторически сложившийся и унаследованный из ранних стандартов список базовых операций не был упорядочен, в соответствии с позднее выдвинутой наглядной и компактной двумерной формой.

В более наглядной форме уровни возможностей процессов можно представить охватывающими операцию слоями операций, способствующих ее успеху (рис. 1.).

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

Модель была бы более наглядной, если бы в качестве обобщенной операции была выделена операция «Обеспечение связи/коммуникации». Чрезвычайно важным свойством SPICE является то, что вслед за ISO 12207 в явной форме рассмотрены проблемы взаимоотношения различных сторон. Обсуждение контракта, приемка/сдача готового продукта, определение взаимоотношений между разработчиками, информирование об изменениях, а также многие другие операции являются конкретными формами реализации этой операции. Такого рода операции уместно отнести ко второму уровню возможностей.

Рабочие продукты SPICE

Основным инструментом оценки процессов в соответствии со SPICE являются их показатели (process indicators). Для оценки адекватности процесса или операции предлагается исследовать наличие и содержание рабочих продуктов (work product), составляющих его вход/выход. К сожалению, как список рабочих продуктов (состоит из 109 неупорядоченных пунктов), так и двадцатистраничная таблица соответствия «базовая операция — входные/выходные рабочие продукты» в SPICE представлены в неудобоваримом сложном виде.

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

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

Целью разработки в соответствии со SPICE является создание Системы. Очень полезное свойство SPICE — явное разделение Системы и Программного продукта (Software). Собственно программный продукт составляет лишь часть Системы, в которую, кроме того, входит оборудование, персонал, средства инфраструктуры. Разработчики с советским стажем вспомнят соответствующие этому разделению стандарты на автоматические системы и программное обеспечение [2]. SPICE выделяет в целевые рабочие продукты некоторые части Системы (Компонент системы, Интегрированный программный продукт, Клиентская документация, Тестовый план клиентской документации).

Чтобы достичь поставленной цели, разработка (инженерные процессы) детализирует и формализует исходную информацию, закрепляя промежуточные результаты в рабочих продуктах озаглавленных Требования, Проект (Design) [Общий/Детальный(High/Low Level)].

В SPICE перечислены не все возможные инженерные рабочие продукты, причем это касается не только иерархии целевой Системы, представленной избранными компонентами, но и промежуточных документов. Например, выделяется Проект Базы данных (Database Design), но ничего не говорится относительно целевой Базы данных и относительно проектов, выделяемых компонентов Системы. Полную картину всех возможных инженерных продуктов может представить таблица, в строках которой перечисляются элементы иерархии целевой Системы, а в графах — уровни разработки (Требования, Проекты, Реализация). Клетки таблицы будут соответствовать возможным рабочим продуктам.

2. Управленческие рабочие продукты. Создание/приобретение программного продукта проводится группой людей в некоторые сроки с использованием определенного оборудования. Выделение работ, сроков, распределение между персоналом, обеспечение ресурсами — все это фиксируют управленческие рабочие продукты: Планы, Графики, Обязательства и пр. Рабочие продукты этого класса являются результирующими для операций, соотнесенных с обобщенными операциями Планирование, Определение ответственности, Распределение ресурсов.

3. Оперативные рабочие продукты. Оперативные рабочие продукты — документы, фиксирующие некоторые факты, в частности, как соотносится текущее состояние разрабатываемых продуктов и их окружения с ожидаемым, наличие дефектов, проблем, запросов на изменение, предложений, ответов и пр. В терминах SPICE — это, прежде всего, всевозможные Записи (Records), а также Отчеты (Reports), Протоколы собраний и др., которые можно рассматривать как агрегаты Записей. Запись содержит определенное число полей, большинство из которых имеет четко очерченный набор значений. Часть из них определяет контекст: дату, автора, ссылочные документы/продукты. Другие представляют оценочные значения, причем чтобы обеспечить однозначность в интерпретации (избежать сравнения «неплохой» с «нормальный») необходима нормативная регламентация используемых значений. С точки зрения обобщенных операций оперативные рабочие продукты, прежде всего, представляют результаты Контроля. Суть оперативных рабочих продуктов в передаче информации для сведения (принятия решения, исправления, ответа) от одного лица к другому (другим), а также ее фиксации (для памяти). Таким образом, они составляют предмет опеки для выделенных нами операций коммуникации.

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

5. Конфигурационные рабочие продукты. Состав сложных рабочих продуктов, история их изменения, а также информационные и причинно-следственные связи между ними задаются при помощи конфигурационных рабочих продуктов. Они озаглавливаются Список, Отображение (Mapping). С конфигурационными рабочими продуктами имеют дело не только операции Управления конфигурации в том смысле, в котором они упоминаются в SPICE, но и все операции, для которых существенен сложный состав рабочих продуктов.

6. Инструментальные рабочие продукты. В качестве входных/выходных продуктов для базовых операций в SPICE перечислен ряд инструментальных рабочих продуктов (инструментов): Коммуникационный механизм, Хранилище повторно используемых объектов, Средства управления конфигурациями. Представленный список, конечно же, не исчерпывает всех используемых в разработке инструментов, но выделяет наиболее важные с точки зрения оценки организованности проведения работ.

Перечислим отношения между рабочими продуктами: обобщение — конкретизация; целое — часть; исходный — результирующий документ операции; предыдущая — следующая версия/вариант; задание — результат выполнения задания; объект — результат контроля; методика — результат применения методики; инструмент — формируемый инструментом продукт.

Первые два неявно наблюдались уже в исходном списке SPICE (например, План — План Проекта, Система — Компонент). Все остальные представляют различные варианты явно определяемого SPICE отношения вход— выход базовой операции. Такое разделение позволяет существенно упростить описание соответствующих операций, и в то же время, создает условия для более полного отражения функционирования программных процессов. В частности, появляется возможность отследить для каждой операции, как формулируется задание, контролируется результат, какие методики и инструменты используются.

С «продуктоцентрической» точки зрения (аналогичной «программированию от данных») большинство действий программных процессов формулируются как действия над рабочими продуктами:

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

Оставшиеся действия — это действия с персоналом (подбор, обучение, управление) и оборудованием (приобретение/подготовка и обеспечение работоспособности).

В операциях (в том числе, в базовых операциях SPICE) возможно присутствие нескольких действий при превалировании одного. Например, при создании некоторого продукта может выявиться наличие дефектов в исходных данных, что соответствует их контролю. Действия по разработке характерны для инженерных процессов, планированию, подготовке методик, инструментов. Их результат подвергается изменениям.

Результат действий по контролю, под которыми понимается не только аудит или обсуждение (review), но и тестирование, представляет факты, фиксируемые «здесь и сейчас». Он сохраняется, рассылается, но изменению уже не подлежит. В случае тестирования тестовые примеры и сценарии рассматриваются как компоненты нормативно-методического обеспечения, подлежащие разработке специальной операцией.

На рис. 2 представлены операции разработки и контроля, пунктиром отмечены отношения между рабочими продуктами.

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

Увы, многие программисты пользуются объектно-ориентированными языками значительно успешнее, чем языком естественным. Когда, пытаясь навести порядок в потоке экстремального программирования, менеджер проекта предлагает: «Иван, положи свой таск в прожект» (зафиксируй свое задание в проектном списке), Иван выдает текст, состоящий в основном из обернутых в приставки и суффиксы английских аббревиатур расширений файлов. А ведь его в школе учили: «Дано: — Требуется доказать:», и его задание должно быть сформулировано подобным же образом:

Исходный документ X версии N. Требуется скорректировать результирующий документ Y версии M, так чтобы он отвечал запросам на изменения Z1. Z2. Результирующий документ должен соответствовать стандарту S, версии K, а при его разработке должен использоваться инструмент I конфигурации IC версии J.

Выводы

Стандарт SPICE может быть представлен в структурированной компактной форме. Тогда накопленные в нем богатства (рекомендации и типовые решения, способствующие успеху программных разработок) были бы донесены до широкой аудитории. Основным препятствием для этого является отсутствие единой терминологии. Отдельные переводы не помогают; пока не появится некий консорциум заинтересованных лиц, организаций, в том числе государственных, который мог бы обсудить, согласовать общий глоссарий, не приходится надеяться на какое-либо их продвижение.

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

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

Наталья Маркова (markova@amsd.com) — независимый эксперт.

Литература