Подсчет количества функциональных точек. Расчет по методу функциональных точек

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

Информационные параметры определяются следующим образом:

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

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

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

Число Файлов. Подсчитывается количество главных логических файлов (логических групп данных), которые могут входить в состав достаточно большой базы данных.

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

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

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

Нет влияния - 0.

Случайное влияние -1.

Умеренное влияние - 2.

Среднее влияние - 3.

Значительное влияние - 4.

Существенное влияние - 5.

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

1. Требует ли система надежного резервирования и последующего восстановления после отказа?

2. Требуется ли передача данных?

3. Имеются ли функции распределенной обработки?

4. Критична ли производительность программного продукта?

5. Будет ли система функционировать в существующей или в более сложной операционной обстановке?

6.Требует ли система онлайнового ввода данных?

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

8. Осуществляется ли обновление главного файла в онлайновом режиме?

9. Являются ли сложными входы, выходы, файлы или запросы?

10. Являются ли сложными алгоритмы обработки данных

Весовые коэффициенты приведены в табл.

Порядок расчета

1. Определяют параметры системы (входы/выходы)

2. Каждому параметру присваивают свой весовой коэффициент, учитывающий сложность реализации параметра

3. Определяют общий итог по всем параметрам

4. Число ФТ определяют по формуле ФТ=общий итог(0,65+0,01суммы коэффициентов)

ФТ можно использовать для определения производительности труда, стоимость разработки одной точки, количество страниц документации на одну точку и т.д.

ЛАБОРАТОРНАЯ РАБОТА № 4

Оценка размера и сложности программных средств методом функциональных точек с использованием пакета COSMOS

Цель работы

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

Расчет по методу функциональных точек

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

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

1. Установление границ данного ПС не вызывает трудностей, так как оно является полностью локальным, и обмен данными с другими ПС в нем не предусматривается.

2. В ПС имеется один внутренний логический файл (ILF) для хранения информации справочника. Причем, данные могут храниться как в обычном файле, так и в таблице СУБД.

Рис. 1. Экранная форма телефонного справочника

Число типов элементов записей (RET) для этого файла может быть равно единице, если данные в файле хранятся в виде однотипных записей: «Телефон», «Фамилия» и «Адрес», допустим, представлены в символьном формате. В случае же, если номер телефона будет представлен, как целое число, а фамилия и адрес в символьном формате, то тогда внутренний логический файл будет иметь два RET. Для определенности далее будем считать, что внутренний логический файл имеет два RET.

Число типов элементов данных (DET) внутреннего логического файла будет равно трем вне зависимости от формата представления номера телефона («Телефон», «Фамилия», «Адрес»). Таким образом, уровень сложности внутреннего логического файла – низкий.

Внешних интерфейсных файлов (EIF) данное ПС не имеет.

3. В ПС имеются два внешних ввода (EI): «Добавление записи» и «Удаление записи», поскольку именно эти две функции ПС модифицируют данные во внутреннем логическом файле. Так как внешний ввод «Добавление записи» ссылается на один внутренний логический файл и имеет пять элементов данных (поля «Телефон», «Фамилия», «Адрес», кнопка «Добавить» и сообщение, подтверждающее факт добавления записи), то уровень сложности этого ввода низкий (см. табл. 4.2). Аналогично, уровень сложности внешнего ввода «Удаление записи» также низкий, поскольку имеется один FTR и пять DET (поля «Телефон», «Фамилия», «Адрес», кнопка «Удалить» и сообщение, подтверждающее факт удаления записи).

В программе имеются два внешних запроса (EQ): «Вывод списка» отсортированных записей и «Поиск записи» в справочнике. Внешний запрос «Вывод списка» имеет низкий уровень сложности, так как ссылается на один внутренний логический файл и имеет четыре элемента данных («Телефон», «Фамилия», «Адрес» и группа радио-кнопок «Сортировка»). Уровень сложности «Поиска записи» в справочнике также низкий (один внутренний логический файл и пять элементов данных: «Телефон», «Фамилия», «Адрес», кнопка «Поиск», сообщение об отсутствии искомой информации).

В ПС имеется также один внешний вывод (EO): вывод уведомляющего сообщения при попытке добавить запись с существующим номером телефона. Уровень сложности этого внешнего вывода – низкий, так как он имеет один FTR и два DET: номер телефона и само сообщение.

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

Таблица 1. Данные для расчета числа UFPC телефонного справочника

4. Подсчитаем теперь с помощью табл. 2. и формулы (2) итоговую степень влияния (TDI) общих характеристик системы и нормирующий фактор (VAF).

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

· «Диалоговый ввод данных», который оценивается с весом – 5, поскольку все 100% транзакций в ПС являются интерактивными;

· «Эффективность для конечного пользователя», которая оценивается с весом – 1, поскольку в ПС имеются функции автоматической установки курсора, скроллинга и интерфейс с мышью;

· «Простота использования», которая оценивается с весом – 5, поскольку в ПС все функции автоматизированы за исключением загрузки/выключения и имеется автоматическое восстановление после ошибок;

· «Распространенность», которая оценивается с весом – 2, поскольку ПС рассчитано на работу на совместимом аппаратном/программном обеспечении;

· «Легкость изменения», которая оценивается с весом – 2, поскольку ПС хранит информацию в таблицах, поддерживаемых пользователем в диалоговом режиме.

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

Нормирующий фактор (VAF) определится как

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

В заключение, оценим количество строк исходного кода с использованием бэкфайер-метода, исходя из того, что программу необходимо разработать с использованием языка программирования C++:

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

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

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

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

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

Самой простой и наиболее широко используемой метрикой является размер программы в строках ее кода (lines of code, LOC) . Ее основное достоинство - понятность и простота вычисления. Ее недостатки - не очень хорошая адекватность в качестве метрики трудоемкости разработки программы, зависимость от используемых языков и технологий и трудность предварительной оценки размера ПО. Практика показывает, что качественная программа часто имеет несколько меньший объем, чем программа с теми же функциями, но менее удобная для сопровождения или совершающая больше ошибок. В то же время, на разработку первой программы может уйти в два-три раза больше усилий.

С другой стороны, производительность разных разработчиков очень сильно отличается, но обычно руководители групп и организаций примерно представляют себе среднее значение по группе или организации. В терминах строк кода она обычно лежит в пределах от 5000 до 50000 строк хорошо отлаженного кода без учета комментариев за 1 человеко-год.

Более хитрой метрикой сложности программы являются функциональные точки (functional points, FP) , . Количество функциональных точек в программной системе вычисляется примерно следующим образом.

Выделяются обращения к системе с целью ввода данных, с целью получения каких-то уже имеющихся в ней данных (отчеты), и с запросами, в ходе которых данные вводятся в систему, перерабатываются и выдаются какие-то результаты. Дополнительно определяются группы взаимосвязанных данных (называемые файлами) внутри системы и аналогичные группы, лежащие вне ее, но используемые в ее работе.
Для всех данных из перечисленных пяти категорий оценивается их сложность (по шкале "низкая"–"средняя"–"высокая").
Итоговая сложность программной системы вычисляется как сумма сложностей выявленных отдельных представителей этих пяти категорий. Сложность ввода, вывода, запроса или группы данных вычисляется умножением оценки сложности составляющих данных на весовой коэффициент, который можно найти в стандартах , или определить на основе собственного опыта. Обычно весовые коэффициенты групп данных больше, чем коэффициенты для вводов, выводов или запросов.

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

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

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

Наиболее известным методом оценки трудоемкости и времени проекта, основанным на большом количестве данных из проведенных ранее проектов, является конструктивная модель стоимости версии II (Constructive Cost Model II , COCOMO II ) , , .

В рамках этой модели оценки трудоемкости проекта и времени, требующегося на его выполнение, определяются тремя разными способами на разных этапах проекта:

На самых ранних этапах, когда примерно известны только общие требования, а проектирование еще не начиналось, используется модель состава приложения (Application Composition Model) . В ее рамках трудоемкость проекта оценивается в человеко-месяцах по формуле
Effort = A*Size.
- Size представляет собой оценку размера в терминах экранов, форм, отчетов, компонентов и модулей будущей системы. Каждый такой элемент оценивается с коэффициентом от 1 до 10 в зависимости от своей сложности.
- Коэффициент A учитывает возможное переиспользование части компонентов и производительность разработки, зависящую от опытности команды и используемых инструментов и оцениваемую числом от 4 до 50.
  A = (100 – (процент переиспользования))/производительность.
На следующих этапах, когда требования уже в основном известны и начинается разработка архитектуры ПО, используется модель этапа предварительного проектирования (Early Design Model) и следующие формулы.
Для трудоемкости (в человеко-месяцах):

Effort = A*(Size) B *M E + (трудозатраты на автоматически генерируемый код)

Для времени (в месяцах):
После того, как разработана архитектура ПО, оценки должны выполняться с использованием постархитектурной модели (Post-Architecture Model) .
Формула для трудоемкости (в человеко-месяцах):

Effort= A*(K req *Size) B *M P + (трудозатраты на автоматически генерируемый код)

Для времени - та же формула, что и в предыдущей модели (в месяцах):

Time = T*Effort S (0.28+0.2*(B-1.01)) *Sced.
- Size = (размер нового кода в тыс. строк) + RSize , где
  RSize = (размер переиспользуемого кода в тыс. строк) * (100 – AT)/100 * (AA + 0,4*DM + 0,3*CM + 0,3*IM + SU)/100
  - AT - процент автоматически генерируемого кода;
  - AA - фактор трудоемкости перевода компонентов в повторно используемые, от 0 до 8;
  - DM - процент модифицируемых для переиспользования проектных моделей;
  - CM - процент модифицируемого для переиспользования кода;
  - IM - процент затрат на интеграцию и тестирование повторно используемых компонентов;
  - SU - фактор понятности переиспользуемого кода, от 10 для простого, хорошо структурированного, до 50 для сложного и непонятного; равен 0 , если CM = DM = 0 .
- Все коэффициенты, кроме K req и M P , имеют те же значения, что и в предыдущей модели.
- Коэффициент K req вычисляется как (1 + (процент кода, выброшенного из-за изменений в требованиях)/100).
- Коэффициент M P является произведением 17 коэффициентов затрат, имеющих значения от 1 до 6:
  - надежность продукта;
  - сложность продукта;
  - размер базы данных разрабатываемого приложения;
  - требуемый уровень повторного использования;
  - требуемый уровень документированности;
  - уровень производительности по времени;
  - уровень требований к занимаемой оперативной памяти;
  - изменчивость платформы;
  - возможности аналитика проекта;
  - возможности программистов;
  - опыт работы команды в данной предметной области;
  - опыт работы команды с используемыми платформами;
  - опыт работы команды с используемыми языками и инструментами;
  - уровень текучести персонала в команде ;
  - возможности используемых инструментов;
  - возможности общения между членами команды ;
  - фактор сжатия графика проекта.

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

Этот метод используется для измерения производительности взамен устаревшего линейного подхода, где производительность измерялась количеством строк программного кода. Впервые функциональные точки (function points) были предложены сотрудником IBM Аланом Альбрехтом в 1979 г. .

Преимуществом данного метода является то, что поскольку применение функциональных точек основано на изучении требований, то оценка необходимых трудозатрат может быть выполнена на самых ранних стадиях работы над проектом. Для поддержки и развития данного метода в 1986 г. была создана Международная группа пользователей функционального измерения (IFPUG - International Function Point User Group).

Метод заключается в следующем.

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

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

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

Далее полученные значения умножаются на коэффициенты сложности для каждого фактора (по данным 1РР1Ю) и суммируются для получения полного размера программного продукта. Значения этих коэффициентов приведены в табл. 9.1.

Таблица 9.1. Значения коэффициентов сложности

Для рассматриваемого нами примера возьмем значения, приведенные в табл. 9.2.

Размер нашей функции составит:

ФР =1хЗ+1х4+1х5+1х7+1х7 = 26.

Это число является предварительной оценкой и нуждается в уточнении.

Таблица 9.2. Пример коэффициентов сложности

Параметр
Параметр
Внешние входы
Внешние выходы
Внешние запросы
Внутренние логические файлы
Внешние логические файлы

Следующим шагом в определении размера программного кода методом функциональных точек является присвоение веса (от 0 до 5) каждой характеристике проекта. Перечислим эти характеристики:

1. Требуется ли резервное копирование данных?
2. Требуется обмен данными?
3. Используются распределенные вычисления?
4. Важна ли производительность?
5. Программа выполняется на сильно загруженном оборудовании?
6. Требуется ли оперативный ввод данных?
7. Используется много форм для ввода данных?
8. Поля базы данных обновляются оперативно?
9. Ввод, вывод, запросы являются сложными?
10. Внутренние вычисления сложны?
11. Код предназначен для повторного использования?
12. Требуется преобразование данных и установка программы?
13. Требуется много установок в различных организациях?
14. Требуется поддерживать возможность настройки и простоту использования?

Значения для данных характеристик определяются следующим образом: 0 - никогда; 1 - иногда; 2 - редко; 3 - средне; 4 - часто; 5 - всегда.

Эти характеристики для примера функции сведены в табл. 9.3.

Таблица 9.3. Пример характеристик проектов

Характеристика	Значение в примере	Характеристика	Значение в примере

Определяется 5 - сумма всех весов.

И наконец, уточненный функциональный размер вычисляется по формуле

УФР = ФР X (0,65 + 0,01 X 5). (9.3)

Уточненный функциональный размер функции выбор метода будет следующим:

УФР = 26 х (0,65 + 0,01 х 29)= 17,19.

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

В настоящее время существует несколько модификаций метода функциональных точек .

Точки свойств

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

Метод Mark II

Метод Mark II был представлен Чарльзом Саймонсом также в 1988 г. Этот метод более пригоден для оценки сложных систем, чем классический метод функциональных точек. Он позволяет добиться одного и того же результата как при оценке системы в целом, так и при суммировании оценок, полученных для составляющих ее подсистем.

Трехмерные функциональные точки

В 1991 г. софтверным подразделением корпорации Boeing было предложено еще одно решение - метод трехмерных функциональных точек. Отличием от классического метода является то, что сложность программного продукта оценивается по трем направлениям - данные, функции и управление. Достоинством метода является его применимость не только к оценке программных проектов, но и к оценке трудоемкости задач в других сферах деятельности.

Объектные точки

Метод объектных точек адаптирует оригинальный метод функциональных точек к объектно-ориентированной технологии программирования.

Метод функциональных точек используется для оценки времени разработки на ранних стадиях (этапах) проекта, например, на этапе логического и концептуального проектирования. Для использования данного метода необходимо иметь перечень требований к разрабатываемому программному обеспечению. Точность оценки зависит от уровня детализации требований. Данный метод используется для оценки производительности труда разработчиков и объема работы.

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

– определение типа оценки;

– определение области оценки и границ продукта;

– подсчет функциональных точек, связанных с данными;

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

– определение суммарного количества не выровненных функциональных точек;

– определение значения фактора выравнивания;

– расчет количества выровненных функциональных точек.

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

К недостаткам метода следует отнести определенную сложность использования.

Метод функциональных точек основывается на экспертных оценках сложности. Следовательно, точность оценок будет зависеть от квалификации экспертов в данной предметной области. Также на точность оценки будет влиять качество спецификаций (функциональных требований) и качество их отображения в конкретных технических решениях.

2. Cocomo

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

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

В состав модели входит 21 параметр.

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

Модель прототипа,

Модель этапа проектирования,

Модель детальной разработки.

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

3. Метод pert

Инженерный метод оценки трудоемкости проекта PERT (Program / Project Evaluation and Review Technique). Входом для данного метода оценки служит список элементарных пакетов работ.

Диапазон неопределенности характеризуется тремя оценками:

Мi – наиболее вероятная оценка трудозатрат;

Оi – минимально возможные трудозатраты на реализацию пакета работ;

Рi – пессимистическая оценка трудозатрат. все риски реализовались.

Оценка средней трудоемкости по каждому элементарному пакету работ определяется по формуле:

Ei = (Pi + 4Mi+ Oi)/6

Для расчета среднеквадратичного отклонения используется формула:

CKOi= (Pi – Oi)/6

Тогда для оценки суммарной трудоемкости проекта, которую мы не превысим с вероятностью 95%, можно применить формулу:

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

Особенностью модели COCOMO является чувствительность к точности большого числа параметров, входящих в состав модели (до 21 параметра), влияющих на точность результирующей оценки.

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

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

Имитационная модель позволяет исключить «случайность оценки» (необоснованный оптимизм или пессимизм эксперта) за счет большого количества имитаций (10 000), а также путем ввода коэффициентов компетентности экспертов. Оценка длительности проекта по данной модели является менее трудозатратной по сравнению с представленными выше.