logo search

48. Методы оценки размера программного обеспечения при управлении программными проектами.

Методы оценки размера проектов

Методы оценки размера проектов разделяются на две основные группы: микрооценка и макрооценка.

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

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

Вероятно, одним из наиболее известных моделей данного рода является конструктивная  модель стоимости (Constructive Cost Model  – COCOMO), разработанная в конце 70х годов Барри Боэмом (Barry Boehm). Построенная на основе анализа ряда проектов, выполненных в основном в интересах Министерства Обороны США, она устанавливает соответствие между размером системы в тысячах условных строк кода и «классом» проекта, с одной стороны, и трудоемкостью разработки системы, с другой стороны.

Базовый тип модели COCOMO учитывает только класс проекта – естественный, полуинтегрированный, «встроенных систем». Естественные проекты – относительно маленькие и разрабатываются командами, знакомыми с прикладной областью.  Полуинтегрированные проекты – системы среднего размера и сложности, разрабатываемые группами разработчиков с различным опытом. Проекты «встроенных систем» выполняются при значтельных аппаратных, программных и организационных ограничениях.

Существенным недостатком данной модели является ее основанность на тысячах условных строк кода, как метрике размера программного комплекса. Видимо, одной из первых попыток отойти от данной метрики размера ПО была разработка Аланом Альбрехтом (Alan Albrecht) в середине 70-х годов метода функциональных точек с целью разработки механизма предсказания усилий, сопряженных с разработкой программных систем.

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

Групповая оценка

В 1940 году был разработан процесс Wide Band Delphi. Он зависит от групповой оценки: руководитель проекта выбирает секретаря и группу оценки. Беспристрастный секретарь организует совещания. Он также обеспечивает всеобщее участие. Руководитель проекта должен быть членом группы оценки, чтобы группа знала приоритетность требований.

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

Параметрическая оценка

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

Use Case Point (UCP)

Этот метод разработан в 1993 году. Он основан на использовании для оценки размера программного обеспечения примеров из унифицированного языка моделирования (Unified Modeling Language - UML). UCP оценивает многие элементы, такие как исполнители, техническая сложность и сложность среды. Затем все они вставляются в формулу для расчета общего размера.

UCP = (UUCW + UAW) × TCF × ECF

Где:

Function Point Analysis (FPA)

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

FP = UAF × VAF

Где:

Трехточечные оценки

Этот метод снимает неопределенности оценки с использованием метода оценки и анализа программы (Program Evaluation and Review Technique - PERT). Метод PERT вычисляет общую оценку по трем оценкам и анализирует результат с помощью математической формулы.

E = (O + 4M + P) /6

Где:

Гибкие методы оценки

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

Покер планирования

Покер планирования – один из самых популярных методов гибкой оценки. Он гарантирует активное участие всех членов через игру. Игра начинается с раздачи каждому члену группы набора карт. Каждый набор карт содержит собственный номер, в значительной степени соответствующий последовательности чисел Фибоначчи: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34 и т.д. Как видно из рисунка 4, эти числа представляют собой относительную оценку описания функциональности (сюжета). Ноль означает, что сюжет слишком тривиальный; 20 означает, что сюжет нужно разбить на более мелкие. Числа Фибоначчи используются для того, чтобы создать неопределенность, которая ведет к обсуждению, особенно при больших числах. Но вернемся к игре. Каждый член команды начинает оценивать некоторый сюжет и показывает карту с оценкой этого сюжета. Члены группы, давшие наибольшую и наименьшую оценки, излагают свои аргументы. Эти объяснения заставляют команду переосмыслить рассуждения, после чего участники обмениваются опытом и предположениями. Вся команда переоценивает сюжет снова и снова, пока не придет к консенсусу.