Пример 1. П о д Х о д к оценке (гэри Кобб)

Одним прекрасным утром я получил по электронной почте письмо, которое начиналось так: " Можете ли вы предложить какие-либо методы оценки объемов трудозатрат и не­ о б х о д и м ы х ресурсов для проведения работ по тестированию программного обеспече­ н и я, а также для расчета графика этих работ? " Далее в письме говорилось: " Наша груп-па разработала таблицу результатов, в которую сводятся результаты измерений харак-теристик нашего процесса и прогнозы относительно текущего состояния проекта в це-лом, в зависимости от которых ему присваивается " красное", " желтое" или " зеленое" состояние. Чтобы осуществить это мероприятие, мы назначили некоторым из наших групп статус ведущих, в то время как другие получили такие названия, как, например, консультант PCQA (Product Certification and Quality Assessment — сертификация и управ­

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

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

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

2. Воспроизведите полный рабочий график двух последних успешно завершенных про­ ектов, например, поставленных заказчику в установленные сроки, без перерасхода сметной стоимости и приемлемого качества, и распределите временной ресурс и финансовую смету по ролям, определенным в пункте 1.

3. Вычислите величину показателя LOE (Level Of Effort — уровень трудозатрат) для ка­ ждой роли, т.е. LOE(j) для каждого j = 1,..., п, где п есть число ролей, выраженное через временной эквивалент FTE (Full-Time-Equivalent — эквивалент полного рабочего дня) в человеко-месяцах.

' 4. Вычислите сумму S в человеко-месяцах для каждого из этих показателей LOE по ка­ ждому проекту. Подсчитайте, какая доля в процентном отношении от общих трудо­ затрат приходится на каждую такую роль, например, как LOE(j)/S, для j = 1 п в рамках каждого проекта, и сравните обе таблицы процентных отношений.

5. Вычислите среднее значение LOE(j)/S, для j = 1,..., n для обоих проектов, чтобы ка­ либровать модель значений LOE(j), предназначенную для прогнозирования значений LOE(j) для новых проектов.

6. Оцените размер программного продукта в тысячах строк KESLOC (Estimated Source Lines Of Codes — предполагаемое количество строк исходного кода) для каждого проекта. KESLOC можно получить путем прямого подсчета строк исполняемого ко ­ да, отличных от комментариев, включая строки всех сценариев, которые не являются частью продукта, но были разработаны для вспомогательных целей. В качестве аль­ тернативы можно подсчитать все функциональные баллы (рассмотренные далее в главе) и при помощи таблицы перевода Кейперса Джонса (Capers Jones), которая приводится в таблице 12.1, получить KESLOC для функциональных баллов.

7. Вычислите коэффициент EAF (Effort Adjustment Factor — коэффициент уточнения трудозатрат) из уравнения EAF = S/(2.4*(KESLOC**1, 05)). Отсюда может быть вы­ ведена формула перевода размера продукта в трудозатраты:

S = EAF*2.4*(KESLOC**1, 05),

где EAF получена на основании базиса оценок, a KESLOC прогнозируется на основе задокументированных требований.