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

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.