Адаптация оценки для процесса поэтапного контроля

Во многих крупных организациях используется определенный жизненный цикл разработки программного обеспечения (SDLC, Software Development Life Cycle). Такие жизненные циклы обычно являются частью процессов поэтапного контроля — процессов, определяющих жизненный цикл продуктов в виде нескольких

«этапов» и «контрольных точек» (Cooper 2001).

На рис. 17.1 показан типичный процесс поэтапного контроля.

alt="Рис. 17.1. Типичный процесс поэтапного контроля разработки программного продукта" />

Контрольная              12              3              4              5

точка

Рис. 17.1. Типичный процесс поэтапного контроля разработки программного продукта

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

Таблица 17.1. Типичный процесс поэтапного контроля, ориентированный на программный продукт (сокращенный вариант)

продолжение amp;

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

Одна из стандартных проблем заключается в том, что разработка часто представляется в виде одного этапа (этап 3 в табл. 17.1). Операции, выполняемые в процессе разработки, занимают от 75 до 90 % общего объема работы программного проекта, и в общем случае я бы предпочел видеть на этом этапе несколько промежуточных контрольных точек вместо одной точки, обозначающей конец этапа. Это одна из ситуаций, в которых следует периодически пересматривать оценки во время этапа. Тем самым обеспечивается эффективное планирование и управление проектом независимо от того, как относится организация к пересмотру оценок на в середине этапа.

Вторая стандартная проблема: этапы анализа требований и планирования, определенные в табл. 17.1, часто объединяются в один этап. Фактически это означает, что контрольная точка 3 находится в фазе сужения конуса неопределенности до ±25 %, что может происходить когда угодно от 15 до 35 % календарного времени проекта (эти процентные показатели более подробно рассматриваются в главе 21). Участникам проекта, не связанным с технической стороной, часто приходится объяснять, какие операции по разработке программного обеспечения должны быть завершены для получения осмысленного представления о «контрольной точке № 3». Количество и глубина таких операций часто превышают ожидания.

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

В табл. 17.2 показан пример соответствия между диапазонами оценки и процессами SDLC.

Таблица 17.2. Типичное соответствие между контрольными точками SDLC и оценками

СОВЕТ № 78

Координируйте стандартизированную процедуру оценки с процессом SDLC, принятым в вашей организации.

В двух следующих разделах представлены примеры стандартизированных процедур оценки. В разделе 17.3 описан пример процедуры, используемой в последовательных проектах, а в разделе 17.4 — пример процедуры для итеративных проектов.