Средства оценки трудоемкости

Ряд средств оценки является коммерческими продуктами — SLIM (Quantitative Systems Management), ESTIMACS (Computer Associates), KnowledgePLAN и CHECKPOINT (SPR). Эти про­дукты нельзя назвать совершенными, и все они требуют от поль­зователя высокого уровня квалификации (здесь, как и в других областях деятельности, действует принцип «что заложишь, то и получишь»). В лучшем случае с помощью таких продуктов можно получить оценку с точностью 10%. Даже если точность будет 50%, это все равно лучше, чем брать данные «с потолка».

Существуют специальные программные средства, автомати­зирующие проведение оценок по методу функциональных точек и позволяющие оценить, насколько быстро и с какими затратами в действительности удастся реализовать проект. Одним из таких средств является KnowledgePLAN - продукт фирмы SPR.

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

KnowledgePLAN обладает следующими возможностями:

1. формирование близкого к реальному плана работ по проекту;

2. определение трудоемкости и стоимости планируемых про­ектов;

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

4. проведение анализа «what — if» («что-если») для поиска луч­ших решений;

5. проведение сравнительного анализа качества и производи­тельности разработки разнотипных проектов, или однотип­ных проектов, при выполнении которых использовались различные технологии;

6. накопление статистической многомерной информации о проекте и его участниках;

7. классификация проектов для принятия решения о структу­ре управления проектом;

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

6.7.

Планирование итерационного процесса создания по

При планировании процесса создания ПО важно не только оценить длительность разработки (как это, например, предлага­лось сделать в подразд. 6.3.2), но и представлять себе соотноше­ние длительности различных стадий процесса создания ПО. Так, например, поданным компании Rational Software, распределение времени и объема работ по стадиям представлено в табл. 6.19.

Такое распределение справедливо для проекта, имеющего следующие характеристики:

1. средний размер проекта и средний объем работ;

2. незначительное число рисков и нововведений;

3. нахождение в начальном цикле разработки;

4. отсутствие предопределенной архитектуры.

Таблица 6.19

Распределение времени и объема работ по стадиям

Стадия	Время работы, %	Объем работы, %
Начальная стадия	10	5
Разработка	30	20
Конструирование	50	65
Ввод в действие	10	10

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

1. Если для определения области действия проекта, изыскания финансирования, изучения рынка или создания первона­чального прототипа нужно значительное время, — увеличи­вается начальная стадия.

2. Если отсутствует архитектура, предусматривается примене­ние новых (или незнакомых) технологий и (или) имеются жесткие ограничения производительности, значительное число технических рисков, а персонал большей частью сос­тоит из новичков, — увеличивается стадия разработки.

3. Если проект представляет собой разработку второго поколе­ния существующего продукта и в архитектуру не вносятся значительные изменения — уменьшаются стадии разработ­ки и конструирования.

4. Если нужно быстро выпустить продукт на рынок (из-за вы­сокой конкуренции) и спланировать постепенное заверше­ние разработки — уменьшается стадия конструирования и увеличивается стадия ввода в действие.

5. Если затруднено внедрение, например, при замещении од­ной системы другой без прерывания эксплуатации или при необходимости сертификации (в таких областях, как меди­цинское оборудование, ядерная промышленность или авиа­ционная электроника), — увеличивается стадия ввода в действие.

Следующий важный вопрос «Сколько итераций будет содер­жать каждая стадия?». Прежде чем принять решение по этому воп­росу, нужно рассмотреть продолжительность каждой итерации.

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

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

2. Если попытаться применить этот сценарий для группы из 20 человек, то это окажется затруднительным. Распределение работы, синхронизация подгрупп и интеграция будут зани­мать больше времени. В этом случае итерация может занять три—четыре недели.

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

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

Таблица 6.20

Длительность итерации

Количество строк кода	Число сотрудников	Длительность итерации
5000	4	2 недели
20000	10	1 месяц
100000	40	3 месяца
1000000	150	8 месяцев

После того как определена приемлемая длительность итера­ции, следует определить число итераций на каждой стадии.

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

На стадии разработки нужна, как минимум, одна итерация. Если отсутствует начальная архитектура и нужно адаптироваться к новым инструментальным средствам, технологиям, платформе или языку программирования, то следует планировать две—три итерации. Возможно, потребуется продемонстрировать прототип заказчику или конечным пользователям, чтобы уточнить требо­вания. Кроме того, дополнительная итерация может потребо­ваться для исправления ошибок, допущенных при разработке ар­хитектуры.

На стадии конструирования также нужно запланировать не менее одной итерации, при этом количество итераций зависит в основном от реализуемой функциональности (количества вари­антов использования).

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

В итоге можно определить три уровня проведения полного цикла разработки (табл. 6.21).

Таблица 6.21

Количество итераций по стадиям

Уровень	Начальная стадия	Разработка	Конструирование	Ввод в действие
Низкий	0	1	1	1
Типичный	1	2	2	1
Высокий	1	3	3	2

Таким образом, можно принять в качестве эмпирического правила, что средний итерационный проект включает 6 + 3 ите­рации.

! Следует запомнить

1. Оценка трудоемкости создания ПО является одним из наи­более важных видов деятельности в процессе создания ПО.

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

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

Основные понятия

Функциональный тип, функциональная точка.

? Вопросы для самоконтроля

1. К каким последствиям могут привести недооценка и пере­оценка стоимости, времени и ресурсов, требуемых для соз­дания ПО?

2. На какой стадии проекта и с какой точностью может вы­полняться оценка трудоемкости создания ПО?

3. Охарактеризуйте и сравните методы оценки трудоемкости создания ПО.

4. Что означает хорошая оценка трудоемкости?

5. В каких единицах измеряется размер ПО?

6. Какие факторы наиболее значительно влияют на трудоем­кость создания ПО?