Методы оценки программных средств и их классификация

МЕТОДЫ ОЦЕНКИ ПС И ИХ КЛАССИФИКАЦИЯ

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

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

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

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

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

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

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

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

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

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

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

результаты разных методов не станут достаточно близкими.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основными единицами измерения размера ПО являются:

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

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

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

Взаимосвязь между LOC и затрачиваемыми усилиями не является линейной .

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

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

Первостепенное значение имеет набор функциональных свойств и качество ПО , а не количество строк кода.

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

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

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

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

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

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

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

• программисты могут быть незаслуженно премированы за высокие показатели LOC в случае, если руководство

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

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

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

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