Управление программными проектами. Учебное пособие

(персональные дни), либо (наиболее часто) человеко-месяцы (персональные месяцы).

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

Одним из основных вопросов, является применение инструмента оценки трудозатрат, графика и остальных затрат, СОСОМО (ConstructiveCostModel,

конструктивная модель затрат). При этом предполагается, что в каждом человеко-

месяце содержится 19 рабочих человеко-дней и 152 человеко-часа. Эти значения подсчитываются путем учета среднего количества праздничных и выходных дней в США в случае с другими странами эти значения могут отличаться.

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

включают следующее:

–задачи, выполняемые в будущем: (VVBS):

–задачи по разработке ПО (проект, код, тестирование);

–дополнительные задачи по разработке (требования, система);

–задачи поддержки (CM, QA, менеджмент);

–задачи, требующие дополнительных трудозатрат (документы и т.д.)

–дополнительные денежные затраты (поездки, оборудование и т.д.);

–опенка размера ПО;

–хронологические данные по трудозатратам и производительности;

–график высокого уровня;

91

–процесс и методы;

–язык программирования;

–операционная система для целевой системы;

–используемые инструменты;

–уровень профессионального опыта.

Простое вычисление трудозатрат основывается на хронологических данных:

размер × хронологическая производительность = трудозатраты.

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

Предположим, что текущие хронологические данные показали следующую производительность:

–сложное ПО: 4 SLOC на человеко-день;

–простое ПО: 8 SLOC на человеко-день.

Таким образом, если размер нового ПО оценивается в 8000 SLOC, то в случае разработки сложного ПО может потребоваться до 2000 человек-дней. Если программа является простой, может потребоваться до 1000 человеко-дней.

Типичные значения производительности:

–50-300 SLOC/месяц (2-13 SLOC/день) для языком высокого уровня;

–60-500 SLOC/месяц для языков ассемблера.

Минимальные значения характерны для правительственных проектов,

которые имеют весьма серьезные ограничения (например, встроенные системы реального времени, надежность которых жизненно важно для обеспечения безопасности людей). Более высокие значения характерны для коммерческих приложений с несколькими ограничениями. Высокие значения этого показателя могут также достигаться в случае использования языков 4GL, высокой степени повторного использования и в некоторых других подобных ситуациях.

Ниже приводится соответствующий пример.

Трудозатраты на разработку сложного ПО варьируются от 2 до 8строк SLOC

на человеко-день, причем среднее значение равно 5 SLOC на один человеко-день. В

92

этом случае ожидаемые трудозатраты на создание программного кода объемом в

5000 SLOC составят 1000 человеко-дней. Однако это значение может составлять

2500 человеко-дней либо 625 человеко-дней (минимальное и максимальное значения).

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

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

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

Этапы оценивания.

Этап 1. Достижение целей, связанных с оценкой затрат.

1 Следует четко представлять, каким образом может применяться оценивание. Может ли оно применяться при составлении контракта с фиксированной ценой работ/услуг? Требуется ли внешнее финансирование?

2 При оценивании скорректируйте цели таким образом, чтобы они соответствовали принимаемым решениям: абсолютное оценивание требуется при планировании ресурсов или рабочего потенциала; относительные оценки могут использоваться для выбора какого-либо решения; либеральные оценки могут увеличить степень достоверности решения (но сравнению с консервативными оценками).

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

Этап 2. Разработка плана действий при оценивании; план распределения ресурсов.

1В плане определяется ожидаемая точность в процессе оценивания затрат.

2Рассматривайте действия по оцениванию в разрезе «мини проекта».

Качественное оценивание, как и все другие действия по разработке ПО,

предполагает достаточное количество затраченного времени и труда (большие

93

инвестиции приносят больше прибыли). Оценка, выполненная за 30 минут, будет не столь точной, как оценки отдельных системных компонентов, на основе корректно разработанной структуры WEB. Мини план включает набор заметок, выполненных на рани стадиях проекта, в которых определяется порядок выполнения оценивания.

Этап 3. Определение требований но разработке ПО.

1Определите требования, необходимые для достижения целей оценивания.

2Сформулируйте спецификации ПО таким образом, чтобы они были, по возможности, четкими и однозначными (желательно исчисляемые). Соответствие ПО имеющимся спецификациям проверяется с помощью тестов.

Этап 4. Учет максимального количества деталей.

1 При определении целей оценивания учитывайте необходимость их

совместимости.

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

3По мере роста объема оцениваемого ПО согласно закону больших чисел,

уменьшается отклонение результатов оценивания от фактических значений.

4 Чем больше мы будем размышлять относительно всех программных функций, тем меньшей будет вероятность того, что напрасно будут потрачены средства на пользование менее очевидных функций.

Этан 5. Использование нескольких независимых методик.

1Ни один из методов не может быть лучше других методов во всех отношениях.

2Преимущества и недостатки различных методов являются взаимно дополняемыми.

3Комбинация применяемых методик позволяет преодолеть недостатки отдельных методов.

Этан 6. Сравнение, понимание и последовательный просмотр оценок.

выполнить исследование причин необходимости проведения различных оценок

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

3 Проявляется феномен закона Парето (Pareto): 80% затрат приходится на создание 20% компонентов. Обращайте более пристальное внимание именно на эти компоненты.

Этап 7. Обзор точности оценивания

1Правильно подбирайте методики и модели оценивания.

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

Исходя из предположения о незавершенности оценок ПО, можно заключить,

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

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

5.3 Регрессионная модель COCOMO

Модель конструктивных затрат (ConstructiveCostModel, СОСОМО) относится к числу наиболее широко применяемых технологий оценивания. Основанная на использовании регрессии модель была разработана доктором Барри В. Боэмом

95

(Dr.BarryW. Boehm) в начале 1970 годов. В то время Барри работал в фирме TRW.

Он начал с анализа 63 программных проектов различных типов. При этом оценивался фактический размер (показатель LOC), понесенные трудозатраты, а

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

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

Регрессионный анализ обладает следующими признаками.

1Метод регрессии применяется для создания количественного прогноза значения одной переменной, полученного на основе значении других переменных.

2Используется статистическая техника при поиске взаимосвязей между переменными в целях прогнозирования дальнейших значений.

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

В статистических моделях значение параметра, для данного значения вычисляется по формуле

где а и b являются константами.

В этих моделях прогнозирование выполняется с учетом использования линейной регрессии.

При использовании множественной регрессии зависимая переменная рассматривается в качестве зависящей от более чем одного независимого значения.

96

В модели COCOMO используются три режима, с помощью которых

классифицируется сложность системы, а также среды разработки.

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

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

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

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

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

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

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

проекта, которые могут являться результатом более ли менее значительных

97

трудозатрат. Произведение драйверов затрат называется корректировочным множителем среды (Environmentaladjustmentfactor, EAF).

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

Рассмотрим базовую модель COCOMO.Базовая формула оценки трудозатрат СОСОМО определяется по формуле Трудозатраты

где a и b – константы, определенные на этапе регрессионного анализа (в

зависимости от проекта); размер – тысячи строк кода (KLOC);

Е – трудозатраты, выраженные в человеко-месяцах.

Базовые формулы оценки трудозатрат для трех режимов модели СОСОМО:

1Трудозатраты для органического режима: Е = 2,4 × (размер)1,05

2Трудозатраты для сблокированного режима: Е = 3,0 × (размер)1,12

3Трудозатраты для внедренного режима: Е = 3,6 × (размер)1,20

Оценка длительности проекта при использовании базовой модели СОСОМО:

1Длительность проекта в органическом режиме: TDEV = 2,5 × (Е)0,38

2Длительность проекта в сблокированном режиме: TDEV = 2,5 × (Е)0,35

3Длительность проекта во внедренном режиме: TDEV = 2,5 × (Е)0,32

Оценка средней численности персонала при использовании базовой модели СОСОМО определяется по формуле:

98

Оценка производительности при использовании базовой модели СОСОМО определяется по формуле:

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

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

Формула для промежуточной модели СОСОМО: − Трудозатраты (Е) = а × (размер)b × С

Коэффициенты и экспоненты, измененные по сравнению с базовой моделью:

1Трудозатраты для органического режима: Е = 3,2 × (размер)1,05× С

2Трудозатраты для сблокированного режима: Е = 3,0 × (размер)1,12× С

3Трудозатраты для внедренного режима: Е = 2,8 × (размер)1,20× С

Концепция, связанная с фактором корректировки трудозатрат, заключаются в

том, что он создает эффект увеличения либо уменьшения трудозатрат, а

99

следовательно, и затрат, в зависимости от набора факторов среды. Факторы среды иногда называются факторами корректировки затрат [C, s] либо драйверами затрат.

Определение этого фактора-множителя происходит в два этапа.

На этапе 1 драйверам затрат назначают числовые значения.

На этапе 2 происходит перемножение драйверов затрат, в результате чего генерируется фактор корректировки трудозатрат, т.е. С.

Фактор EAF представляет собой произведение факторов корректировки затрат. Факторы корректировки затрат могут сказываться на оценках графика и затрат проекта, изменяя их в 10 и более раз.

Произведение драйверов затрат образует фактор корректировки затрат.

EAF = C1 × C2 × . . . × Cn

Ci = степень фактора корректировки затрат,

Сi= драйвер затрат не применим,

Сi> драйвер затрат увеличивает затраты,

Сi< драйвер затрат уменьшает затраты.

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

−требуемая надежность – как правило, применяется в системах реального

времени;

−размер базы данных – в основном применяется в приложениях обработки

данных;

−сложность продукта – ограничения на время выполнения.

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

−ограничения времени выполнения – применяются в том случае, когда быстродействие процессора является ограниченным;

−ограничения основного хранилища – применяется в случае, когда размер

памяти является ограниченным;

100