27.2.1. Исключения в процессе создания по

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

1. Ключевые разработчики могут заболеть и не выйти на работу как раз перед решающей проверкой проекта.

2. Невозможен обмен данными вследствие неисправности линий связи.

3. Вполне вероятно изменение структуры компании, в результате чего менеджеры будут тратить больше времени на решение организационных вопросов, вместо того чтобы работать над проектом.

4. Возможно вовлечение большего количества персонала в разработку нового проекта, имеющего больший приоритет, чем текущий.

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

27.3. Измерение производственного процесса

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

Среди показателей процесса разработки выделим три вида:

1. Время, потраченное на выполнение отдельного этапа работ. Это может быть только рабочее время выполнения этапа, календарное время выполнения этапа или время работы отдельного специалиста.

2. Ресурсы, необходимые для реализации этапа работ. Ресурсы могут подсчитываться в человеко-днях, затратах на командировки либо ресурсах вычислительной техники.

3. Количество повторений одного и того же события. Среди таких событий можно назвать количество ошибок, обнаруженных при проверке программного кода, количество изменений в системных требованиях, среднее количество измененных строк кода и т.д.

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

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

Основная проблема, связанная с измерением процесса создания ПО, – необходимость знать, что именно следует измерить. Для решения этого вопроса предлагается парадигма GQM (Goal-Question-Metric – цель-вопрос-показатель), с помощью которой определяется вид измерения и способ его использования. Эта парадигма основана "на трех китах".

1. Цель. Что является целью компании по совершенствованию процесса создания ПО? Это может быть повышение производительности труда программистов, сокращение времени разработки, повышение надежности готового продукта и т.д.

2. Вопросы. Это детализация поставленной цели. Как правило, каждая цель соотносится с рядом вопросов. Приведем примеры вопросов к указанным выше целям.

• Как повысить количество строк кода, отлаженных программистом?

• Как сократить время заключительного этапа разработки требований?

• Как повысить эффективность проверки системы на надежность?

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

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

Подход GQM был объединен с описанной в следующем разделе моделью оценки уровня развития, разработанной Институтом инженерии программного обеспечения (США), что нашло свое воплощение в методе совершенствования процесса разработки ПО. Разработчики этого метода предлагают поэтапный подход к совершенствованию процесса создания ПО. Этот подход основан на введении измерений только после того, как организация достигнет достаточного уровня развития технологии. Подход предлагает руководство и практические советы по внедрению измерений в целях совершенствования производства.