Зная скорректированную сумму функциональных пунктов, можно вычислить количество строк кода:
LOC = FP * KFP,
где KFP - коэффициент количества команд на функциональный пункт.
Пример нескольких номинальных коэффициентов для расчета количества строк кода: C# (55), JAVA (55), C++ (55), SQL (13), Perl (20).
Если программа из 320 функциональных пунктов реализовывается на C#, то количество строк кода вычисляется как 55 * 320 = 17600 LOC.
Количество строк кода зависит не только от языка программирования, т но и от технологии разработки программного обеспечения, стиля оформления и др.
Более точно оценить LOC можно по историческим данным для определенного типа проектов.
С помощью метода оценки первого порядка можно рассчитать приблизительное время реализации проекта T. Для этого необходимо общее количество функциональных пунктов FP возвести в степень типа программы S. Для объектно-ориентированной программы средний показатель S равен 0,36, для клиент-серверной программы – 0,37, для бизнес систем – 0,39, для научной системы и публичной Интернет-системы – 0,4:
|
|
T = FPS, мес.
Например, разработка бизнес системы, состоящей из 320 функциональных пунктов, грубо оценивается в 9,5 календарных месяцев.
Другим методом оценки является метод ISBSG. В этом методе существует несколько формул определенных для типа проекта. Результатом формул является число, определяющее оценку в человеко-месяцах. Для преобразования значений «человеко-месяцы» в срок календарных месяцев можно воспользоваться базовой формулой для вычисления срока, которая основана на вычислении кубического корня из объема работ.
Например, для общего типа проекта в методе ISBSG применяется следующая формула:
W = 0,512* FP 0,392 * M 0,791,
где W трудоемкость проекта в человеко-месяцах;
FP – скорректированное по формуле (7.1) число функциональных пунктов;
M – максимальный размер группы, человек.
В уточненных методиках в расчетах оценок участвуют дополнительно такие критерии (факторы) как:
- фактор персонала;
- опыт работы в прикладной области – если персонал незнаком с прикладной областью проекта, то потребуется значительно больше времени;
- навыки владением языками и инструментарием – этот пункт противоположен предыдущему;
- постоянство персонала – текучесть кадров обходится дорого;
- размер базы данных, ограничения по объему хранимых данных – это значит, что большие базы данных требуют больших усилий на уровне проекта, соответственно и ограничения из-за платформы увеличивает объем работы проекта;
- объем необходимой документации – большое количество документации может отрицательно повлиять на проект;
- рассредоточенная (распределенная) разработка – если над проектом работает несколько команд или людей, находящиеся на разных географических площадках, то объем работ увеличивается;
|
|
- неустойчивость платформы – если платформа нестабильна, разработка требует больше времени;
- сложность продукта – этот фактор является основным в модели СОСОМО, он определяется типом создаваемой программы;
- требуемая надежность программного обеспечения – чем больше установлено требований к надежности системы, тем больше времени нужно на ее реализацию;
- ограничения по быстродействию – снижение времени отклика приводит к увеличению объема работ;
- использование программных инструментариев – использование современного инструментария снижает объем работ.
Для повышения эффективности оценок используют калибровки (коррекция по результатам выполнения проектов). Обычно, самой лучшей калибровкой является использование исторических данных.