Методы оценки и их классификация

1. Алгоритмическое моделирование. Метод основан на анализе статистических данных о ранее выполненных проектах, при этом определяется зависимость трудоемкости проекта от какого-ни­будь количественного показателя программного продукта (обыч­но это размер программного кода). Проводится оценка этого по­казателя для данного проекта, после чего с помощью модели прогнозируются будущие затраты.

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

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

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

· в организации аккуратно документируются реальные ре­зультаты предыдущих проектов;

· по крайней мере, один из предыдущих проектов (а лучше несколько) имеет аналогичный характер и размер;

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

4. Закон Паркинсона. Согласно этому закону усилия, затра­ченные на работу, распределяются равномерно по вьщеленному на проект времени. Здесь критерием для оценки затрат по проек­ту являются человеческие ресурсы, а не целевая оценка самого программного продукта. Если проект, над которым работают пять человек, должен быть закончен в течение 12 месяцев, то зат­раты на его выполнение исчисляются в 60 человеко-месяцев.

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

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

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

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

Хорошая оценка трудоемкости разработки ПО:

· создается и поддерживается менеджером проекта и коман­дами архитекторов, разработчиков и тестировщиков, ответ­ственными за выполнение работы;

· воспринимается всеми исполнителями как амбициозная, но выполнимая;

· основывается на подробно описанной и обоснованной мо­дели оценки;

· основывается на данных по аналогичным проектам, кото­рые включают в себя аналогичные процессы, технологии, среду, требования к качеству и квалификации работников;

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

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

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

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

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

· возможностей персонала, участвующего в разработке ПО, в особенности его профессионального опыта и знания пред­метной области проекта;

· среды, которая состоит из инструментов и методов, исполь­зуемых для эффективного выполнения разработки ПО и ав­томатизации процесса;

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

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

Трудоемкость = (Персонал) • (Среда) • (Качество) • (Размер ).

Наиболее влиятельный фактор оценки трудоемкости в этих моделях — размер программного продукта. Процедура оценки трудоемкости разработки ПО состоит из следующих действий:

1. оценка размера разрабатываемого продукта;

2. оценка трудоемкости в человеко-месяцах или человеко-часах;

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

4. оценка стоимости проекта.

Оценка размера продукта базируется на знании требований к системе. Для такой оценки существуют два основных способа.

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

· Путем подсчета размера по определенным алгоритмам на
основе исходных данных — требований к системе.

· Проблемы оценки размера ПО.

· Проблема может быть недостаточно хорошо понята разра­ботчиками и (или) заказчиками из-за того, что некоторые факты были упущены или искажены.

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

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

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

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

· Возможности оценивания существенно зависят от субъек­тов, вовлеченных в процесс оценивания.

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

Точность оценки стоимости и размера ПО в зависимости от стадии проекта определяется следующим графиком (рис. 6.1). Основными единицами измерения размера ПО являются:

· количество строк кода (LOC - Lines of Code);

· функциональные точки (FP — Function Points).

Количество строк кода — исторически самая известная и до недавнего времени распространенная единица измерения. Одна­ко при ее использовании возникает ряд вопросов:

· Каким образом можно определить количество строк кода до того, как они фактически будут написаны либо просто спроектированы?

· Как показатель количества строк кода может отражать вели­чину трудозатрат, если не будет учитываться сложность про­дукта, способности (стиль) программиста либо возможнос­ти применяемого языка программирования?

· Каким образом разница в количестве строк кода может быть трансформирована в объем эквивалентной работы?

Рис. 6.1. Точность оценки стоимости и размера ПО в зависимости от

стадии проекта

Эти и другие вопросы привели к тому, что строки кода как единицы измерения получили «дурную репутацию», хотя они по-прежнему остаются наиболее широко используемыми. Взаимо­связь между LOC и затрачиваемыми усилиями не является ли­нейной. Несмотря на появление новых языков программирова­ния, средняя производительность работы программистов за двад­цать лет осталась неизменной и составляет около 3000 строк кода на одного программиста в год. Это говорит о том, что уменьше­ние времени, затрачиваемого на цикл разработки, не может быть достигнуто за счет значительного повышения производительнос­ти труда программистов. Причем это не зависит от усовершен­ствований языка программирования, усилий со стороны менед­жеров или сверхурочных работ. На самом деле первостепенное значение имеет набор функциональных свойств и качество ПО, а не количество строк кода.

Преимущества использования LOC в качестве единиц изме­рения:

· широкое распространение и легкая адаптируемость;

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

· непосредственная связь с конечным продуктом;

· легкая оценка до завершения проекта;

· оценка размеров ПО на основе точки зрения разработчика — физическая оценка созданного продукта (количество напи­санных строк кода).

· Недостатки применения LOC:

· LOC затруднительны в применении при оценке размера ПО на ранних стадиях разработки;

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

· применение методов оценки с помощью подсчета количест­ва строк кода не регламентируется промышленными стан­дартами (например, ISO);

· разработка ПО может быть связана с большими затратами, которые прямо не зависят от размеров программного кода — «фиксированными затратами», такими, как спецификации требований и пользовательские документы, не включенны­ми в прямые затраты на кодирование;

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

· при подсчете количества LOC следует различать автомати­чески и вручную созданный код - эта задача является бо­лее сложной, чем простой подсчет, который может быть выполнен на основе листинга, сгенерированного компи­лятором, либо с помощью утилиты, выполняющей подсчет строк кода;

· показатели LOC не могут применяться при осуществлении нормализации в случае, если применяемые платформы раз­работки или языки являются различными;

· единственный способ учета с помощью LOC по отношению к разрабатываемому ПО заключается в использовании ме­тода аналогии на основе сравнения функциональных свойств у подобных программных продуктов, либо в ис­пользовании мнений экспертов (однако эти методы не от­носятся к числу точных);

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

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

6.2.