Оценка длительности разработки программного обеспечения

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

     Для расчета оценок существует множество методов и моделей, которые позволяют просчитать предварительные сроки разработки проекта. Регрессионная модель СОСОМО, метод ISBSG (International Software Benchmarking Standard Group), метод оценки первого порядка и многие другие.

     Модель конструктивных затрат (Constructive Cost Model, COCOMO) относится к числу наиболее широко применяемых технологий оценивания. Основа модели была разработана доктором Барри В. Боэмом (Dr. Barry W. Boehm) в начале 70-х годов 20-века. В первых моделях оценивался фактический размер (показатель LOC), понесенные трудозатраты и фактическая длительность разработки программного обеспечения.

     Одной из альтернатив метрики LOC являются функциональные пункты. Данная метрика может применяться для оценки размера проекта на ранних стадиях. Существует много разных методов для вычисления функциональных пунктов. Стандарт подсчета функциональных пунктов поддерживается группой International Function Point Users Group (IFPUG).

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

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

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

внешние запросы – комбинация входных/выходных элементов, в которых входному элементу ставится в соответствии простая выходная форма;

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

внешние интерфейсные файлы – файлы, находящиеся под контролем других программ, с которыми взаимодействуют измеряемая программа. К этой категории относятся все основные группы логических или управляющих данных, принимаемых или передаваемых программой.

    Для корректировки функциональных пунктов используются множители трех уровней сложности для каждого элемента и коэффициента влияния.

    Пример корректировки функциональных пунктов (ФП):

ФП = ((кол-во внешних входных элементов х 4) + (кол-во внутренних логических файлов х 10) + …) х коэф. влияния

Зная скорректированную сумму в функциональных пунктов можно вычеслить количество строк кода

LOC = ФП х коэффициент кол-ва команд на функциональный пункт

Пример нескольких номинальных коэффициентов для расчета количества строк кода: C# (55), JAVA (55), C++ (55), SQL (13), Perl (20).

Если программа из 320 функциональных пунктов реализовывается на C#, то количество строк кода вычисляется 55 х 320 = 17600 LOC.

     С помощью метода оценки первого порядка можно рассчитать приблизительное время реализации проекта. Для этого необходимо общее количество функциональных пунктов возвести в степень типа программы. Для объектно-ориентированной программы средний показатель равен 0,36, для клиент-серверной программы – 0,37, для бизнес систем – 0,39, для научной системы и публичной интернет системы – 0,4.

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

     Другим методом оценки является метод ISBSG. В этом методе существует несколько формул определенных для типа проекта. Результатом формул является число определяющее оценку в ЧеловекоМесяцы. Для преобразования значений «человеко-месяцы» в срок календарных месяцев можно воспользоваться базовой формулой для вычисления срока, которая основана на вычислении кубического корня из объема работ.

Например, для общего типа проекта в методе ISBSG применяется следующая формула:

ЧеловекоМесяцы = 0,512 х (ФП в степени 0,392) х (МаксимальныйРазмерГруппы в степени 0,791)

В расчетах оценок участвуют такие критерии (факторы) как:

1. Фактор персонала (мы объединили в этом факторе критерии, которые в старых моделях идут отдельными позициями):
• опыт работы в прикладной области – если персонал незнаком с прикладной областью проекта, то потребуется значительно больше времени
• навыки владением языками и инструментарием – этот пункт противоположен предыдущему
• постоянство персонала – текучесть кадров обходится дорого
2. Размер базы данных, ограничения по объему хранимых данных – это значит, что большие базы данных требуют больших усилий на уровне проекта, соответственно и ограничения из-за платформы увеличивает объем работы проекта.
3. Объем необходимой документации – большое количество документации может отрицательно повлиять на проект.
4. Рассредоточенная (распределенная) разработка – если над проектом работает несколько команд или людей, находящиеся на разных географических площадках, то объем работ увеличивается.
5. Неустойчивость платформы – если платформа нестабильна, разработка требует больше времени.
6. Сложность продукта – этот фактор является основным в модели СОСОМО, он определяется типом создаваемой программы.
7. Требуемая надежность программного обеспечения – чем больше установлено требований к надежности системы, тем больше времени нужно на ее реализацию.
8. Ограничения по быстродействию – снижение времени отклика приводит к увеличению объема работ.
9. Использование программных инструментариев – использование современного инструментария снижает объем работ.

     Для повышения эффективности оценок используют калибровки. Обычно, самой лучшей калибровкой является использование исторических данных. Для электронной версии расчета оценок использовалось несколько методик калибровки, включая и исторические данные. Калибровка оценок процесс трудоемкий и в данном механизме не описывается. В зависимости от жизненного цикла разработки программного обеспечения (SDLC, Software Development Life Cycle) производится адаптация оценки для калибровки, некий поэтапный контроль.

     На основе нескольких моделей для расчета оценок мы создали комбинированную модель (гибрид), выработанную на основе регрессионной модели СОСОМО, метода ISBSG (International Software Benchmarking Standard Group), статистики проведенных проектов и других методов корректировки. При проектировании гибридной модели мы учли множество факторов нашего времени и даже нашей культуры.

     Электронная версия, представленная на странице http://www.simplect.com.ua/Assess.aspx, основана на сокращенной комбинированной модели.

17.02.2008
Серенко Максим
Simplect™