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

Определение границ программного средства

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

Идентификация и оценка функциональности даннных (ILF, EIF)

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

Число типов элементов данных (DET) внутреннего логического файла равно шести:

1. n - количество строк в матрице. Количество строк равно количеству столбцов, так как расчет ведется для так называемых квадратных матриц.

2. Mas - заданная матрица.

3. - заданная точность.

4. x 0 - начальное приближение.

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

6. k - количество итераций, необходимых для вычисления максимального собственного числа матрицы с заданной точностью.

Число типов элементов записей (RET) для внутреннего логического файла равно четырем:

1. Mas - матрица.

2. x 0 - вектор.

3. n, k - целые числа.

4. , - вещественные числа.

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

Внешних интерфейсных файлов (ELF) данное программное средство не имеет.

Идентификация и оценка функциональности транзакций (EI, EO, EQ)

Данное программное средство предусматривает два внешних ввода (EI): ввод данных с клавиатуры и ввода данных из файла.

Для ввода данных с клавиатуры число типов элементов данных (DET) равно пяти: Mas, x 0 , n, а также кнопка «Ввести данные с клавиатуры». Количество используемых типов (FTR) равно пяти.

Уровень сложности для данного типа ввода определен как высокий.

Для ввода данных из файла результаты аналогичны результатам для ввода с клавиатуры, за исключение использования символьной строки с именем файла и соответствующей кнопки для загрузки данных. То есть, DET = 6, FTR=5. Уровень сложности для данного типа ввода определен как высокий.

Данное программное средство имеет только один внешний запрос (EQ) - запрос на корректность введенных данных. Для этого необходимы переменные Mas, x 0 , n, их значения проверяются соответственно: для матрицы - проверка на занесение недопустимых символом - знаков либо букв, для начального приближения - на равенство нулю, занесение недопустимых символов, для размера матрицы - принадлежность к заданным пределам, для точности - ограничение по порядку. Таким образом, DET=4, FTR=3. Информация на выходе данного запроса - «Введенная информация корректна» или «Введенная информация некорректна». То есть, DET=FTR=1. Таким образом, уровень сложности внешнего запроса определен как средний.

Данное программное средство предусматривает два внешних вывода: вывод данных в файл и вывод данных на экран. Для вывода данных на экран число типов элементов данных DET равно четырем: заданная точность, полученное максимальное собственное число матрицы, количество итераций, а также кнопка «Вычислить результаты». Количество используемых типов FTR равно трем. Таким образом, уровень сложности вывода на экран определен как средний.

Для записи данных в файл количество типов элементов данных DET равно пяти: максимальное собственное число, заданная точность, количество итераций, имя файла, а также кнопка «Записать результаты в файл». Количество используемых типов FTR равно четырем. Таким образом, уровень сложности вывода в файл определен как средний.

Определение нормирующего фактора (VAF)

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

Таблица 1. Расчет UFPC

Основные характеристики системы:

· Программное средство реализовано как единый пакет на автономном персонально компьютере - 0.

· Данные между компонентами программного средства и системы не передаются - 0.

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

· Явных или неявных ограничений на использование ресурсов не установлено - 0.

· Пиковые периоды транзакций не ожидаются - 0.

· Сложность диалоговых транзакций - более 30% обрабатываются в интерактивном режиме - 5.

· Эффективность программного средства для конечного пользователя - 2.

· Оперативное обновление отсутствует - 0.

· Сложность обработки данных - 3.

· В программном средстве нет кода, предназначенного для повторного использования - 0.

· Нет особых требований пользователя, и не требуется специальной установочной программы - 0.

· Простота использования - 1.

· При проектировании требования по установке программного средства были учтены, причем программное средство может выполняться, только на похожем (совместимом) аппаратном и / или программном обеспечении - 2.

· Изменение программного средства не предусмотрена - 0.

Нормирующий фактор (VAF) вычислим следующим образом:

VAF=0,65+0,01*TDI=0,65+0,01*(1+5+2+3+2)=0,78

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

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

APFC=UPFC*VAF=35*0,78=26,3

Оценка количества строк исходного кода с использованием бэкфайер-метода

Программное средство будет разрабатываться в среде MS Visual Studio 2008, поэтому значение языкового множителя равно 34. Таким образом, приблизительное количество строк законченное программы в среде MS Visual Studio 2008 будет равно.

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

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

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

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

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

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

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

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

Для окончательного подсчета количества функциональных точек, т.е меры ФТ для всего программного продукта, требуется дополнительно учесть 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++.

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

Дополнительные задачи

1. На основе уравнений базовой СОСОМО для систем распространенного типа построить зависимость трудоемкости разработки программного проекта от его размера при изменении объема кода от 10 до 120 ТСИК.

2. На основе уравнений базовой СОСОМО для систем распространенного типа построить зависимость сроков разработки программного проекта от его размера при изменении объема кода от 10 до 120 ТСИК.

3. На основе уравнений базовой СОСОМО для систем распространенного типа построить зависимость сроков разработки программного проекта от затрат труда при изменении его значений от 10 до 200 ЧМ.

4. На основе уравнений базовой СОСОМО для систем распространенно­го типа построить зависимость средней производительности труда от размера программного средства при изменении объема его кода от 10 до 120 ТСИК.

5. На основе уравнений базовой СОСОМО для систем распространенного типа построить зависимость средней штатной численности от его размера при изменении объема кода от 10 до 120 ТСИК.

6. Имеется матрица распределения усилий на разработку отдельных функциональных блоков программного изделия. Определить трудоемкость разработки каждого блока, трудоемкость разработки каждой работы (по всем блокам) и программного изделия в целом. На основе полученных результатов и уравнений базовой СОСОМО определить длительность разработки изделия, его размер в строках исходного кода и необходимую штатную численность ис­полнителей. Определить стоимость работ по видам деятельности и для системы в целом.

12.3.4. Метод функциональных точек

Общее описание метода оценки. Функционально-ориентированные метрики – это косвенные меры для оценки программного продукта и процесса его разработки; они фокусируют внимание на "функциональности" программного изделия или "полезности" программы. В 1979 г был предложен подход к измерению производительности труда разработчиков программного обеспечения , названный методом функциональной точки (FP –function point method).

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

Порядок расчета трудоемкости разработки ПО:

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

определение количества связанных с каждым функциональным типом элементарных данных (DET), элементарных записей (RET) и файлов типа ссылок (FTR);

определение сложности (в зависимости от количества DET, RET и FTR);

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

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

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

В состав функциональных типов (function type) включаются следующие элементы приложений разрабатываемой системы:

внутренний логический файл (Internal Logical File, ILF) - идентифицируемая совокупность логически взаимосвязанных записей данных, поддерживаемая внутри приложения посредством элементарного процесса;

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

входной элемент приложения (External Input, El) - элементарный процесс, связанный с обработкой входной информации приложения - входного документа или экранной формы. Обрабатываемые данные могут соответствовать одному или более ILF;

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

внешний запрос (External Query, EQ) - элементарный процесс, состоящий из комбинации «запрос/ответ», не связанной с вычислением производных данных или обновлением ILF (базы данных).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11. Предназначены ли созданные программы для повторного использования?

12. Включены ли в проект работы по вводу в действие и по адаптации системы?

13. Предусматривает ли конфигурация системы ее установку в различных организациях?

14. Предусмотрено ли в проекте удобство работы пользователей и простота внесения изменений?

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

Пример 4. Определение числа функциональных точек для программного продукта

Методические указания к выполнению примера 4.

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

Развитие функционального подхода.

Мера функциональной точки, первоначально предложенная для применения к приложениям в области деловых информационных систем, была затем распространена с некоторыми модификациями на другие приложения. Развитие этого метода оценки программных продуктов получило название метода характерных точек (feature points). Этот метод может быть применен для оценки проектов более широкого круга приложений. Мера характерных точек особенно пригодна для приложений с высокой степенью алгоритмической сложности, которая присуща системам реального времени, управленческим процессам и встроенным системам, поэтому именно для них целесообразно применять меру характерной точки (XT).

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

Следует отметить, что оба метода (ФТ и XT) отражают одну и туже сторону программного продукта - его "функциональность" и "полезность". И тот и другой подходы дают близкие результаты для обычных инженерных вычислительных задач и информационных систем. Для более сложных систем осо­бенно реального времени итоговое значение для XT на 20-35% выше, чем итог, определенный с использованием ФТ.

Согласование размеро-ориентированных и функционально-ориентированных подходов к оценке программных проектов.

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

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

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

Таблица 12.3.10 – Соотношение метрик функциональных точек и строк кода

Язык программирования

Ассемблер

Объектно-ориентированные языки

Языки 4-го поколения

Генераторы кода

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

12.3.5 Подходы к оценке производительности труда группы разработчиков

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

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

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

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

Наиболее простой подход построен на предположении, что персонал группы исполнителей вынужден общаться в процессе работы друг с другом, чтобы решать возникающие в процессе работы проблемы. Это общение уменьшает производительное время работников и может оцениваться коэффициентом k относительного сокращения производительного времени. Число информационных связей, возникающих при этом, можно оценивать либо как число возможных взаимных связей, равное числу сочетаний из n по 2, либо полагать, что каждый решает свои личные проблемы с остальными n - 1 участниками разработки. Поэтому при оценке производительности труда группы исполнителей целесообразно рассматривать оба варианта взаимодействия.

Второй подход основан на использовании для расчетов установленной эмпирической закономерности - производительность труда отдельного работника падает пропорционально корню кубическому из n. Это так называемый закон Филиппа.

Третий подход использует модель Путнема, в которой (также на основании опытных данных) представлена взаимосвязь основных параметров программного проекта. В результате использования этой модели также появляется возможность выявить зависимость производительности труда от числа исполнителей n.

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

учет взаимосвязей людей в группе (две модификации);

учет закона Филиппа при оценке производительности труда;

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

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

12.3.5.1. Учет числа взаимосвязей между разработчиками в группе

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

Если в качестве параметра модели использовать относительные затраты времени на одну информационную взаимосвязь по отношению к общему времени работы разработчика, то для ряда значений этого параметра k (например, 0,01, 0,05), можно оценить общую производительность труда группы и трудоемкость разработки проекта.

Можно отметить, что с ростом числа исполнителей в группе общая производительность труда будет возрастать, а затем начнется ее снижение.

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

Пример 5.1. Определение производительности труда группы взаимодействующих исполнителей

Методические указания к выполнению примера 5.1.

Будем полагать, что группа состоит из заданного числа n разработчиков, между которыми осуществляются взаимосвязи. Число таких попарных связей определяется как число сочетаний из л по 2 и равно n*(n-1)/2. Принимая за k относительную долю времени (по отношению к общему времени работы), затрачиваемую на одну взаимосвязь, определить зависимость средней производительности труда одного работника и суммарной производительности группы, длительности и трудоемкости разработки проекта от числа работников в группе n. Определить также оптимальное значение числа работников, обеспечивающее максимальную общую производительность труда группы. Расчеты провести при нескольких значениях параметра k. Данные о производительности труда одного исполнителя и о размерах программного продукта взять из первого задания.

Последовательность выполнения задания

1.Назовем время, затрачиваемое на разработку программного изделия, полезным временем, т. е. будем вычитать из общего времени работы исполни­теля Т1 ту часть k, которая тратится на обсуждение и согласование возникаю­щих проблем с другими членами группы. Тогда легко показать, что полезное время работы одного сотрудника равно

а полезное время работы группы

2.Формулы, приведенные в предыдущем пункте, позволяют определить изменение производительности труда одного исполнителя от размера группы. Очевидно, что с ростом численности группы производительность труда отдельного исполнителя ПТ1 будет уменьшаться в соответствии с формулой

На основе этой формулы построить зависимость ПТ1 от n для ряда значений параметра k. Для каждого выбранного значения параметра k определить размер группы, при котором производительность отдельного работника становится равной 0.

3.Зная производительность труда одного работника, определить суммарную производительность труда группы ПТС как ПТС=n*Т1Т1.

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

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

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

12.3.5.2. Связи каждого участника группы с остальными

Общее описание метода оценки производительности.

Этот подход аналогичен предыдущему за небольшим изменением. Поскольку каждый член группы должен взаимодействовать с остальными работниками, число информационных взаимосвязей оказывается равным n*(n-1), т. е. в 2 раза превышает предыдущее значение.

Пример 5.2 . Определение производительности труда группы исполнителей при взаимодействии каждого с остальными

Методические указания к выполнению примера 5.2

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

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

12.3.5.3. Применение модели Филиппа

Общее описание метода.

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

Таким образом, этот подход позволяет определить в зависимости от размера группы:

1)производительность труда одного исполнителя, работающего в группе как

2) общую суммарную производительность труда группы, как

3)трудоемкость разработки проекта как

4)длительность разработки проекта как

Пример 5.3 . Определение параметров программного проекта с использованием модели производительности группы

Методические указания к выполнению примера 5.3.

Заданы размер программного продукта РП (строк кода) и средняя производительность труда СПТ (строк кода на человеко-месяц) отдельного разработчика. Определить зависимость суммарной производительности труда, трудоемкости и длительности разработки программного продукта от числа разработчиков в группе.

Последовательность выполнения задания.

1. Определить суммарную производительность труда группы из n человек как полагая, что производительность одного человека в группе ПТ1 уменьшается в корень кубический из n раз по сравнению со сред­ней производительностью труда отдельного разработчика. Построить зависимость ПТ1 и ПТС от n.

2.Определить трудоемкость разработки программного продукта как

И построить зависимость трудоемкости разработки от числа разработчиков n.

3.Определить длительность разработки программного продукта как

И построить зависимость длительности разработки от числа разработчиков n в группе.

Дополнительные задачи.

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

2. Построить в виде графика функцию относительного (по сравнению с одним исполнителем) увеличения трудоемкости разработки программного продукта группой разработчиков в зависимости от числа участников разработки n.

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

4. Провести сопоставительный анализ относительного (по сравнению с одним исполнителем) увеличения трудоемкости разработки программного продукта группой разработчиков в зависимости от числа участников разработки n для случая попарных взаимосвязей между участниками группы и при использовании закона Филиппа. Расчеты провести для двух значений параметра k.

5. Провести сопоставительный анализ относительного (по сравнению с одним исполнителем) увеличения трудоемкости разработки программного продукта группой разработчиков в зависимости от числа участников разработ­ки n для случая информационных взаимосвязей каждого исполнителя с остальными членами группы и при использовании закона Филиппа. Расчеты провести для двух значений параметра k.

6. Имеются данные о средней производительности труда одного работника СПТ, численности группы ШЧ и о размерах разрабатываемого программного продукта РП. Определить, как изменится длительность разработки проекта ДР, если по истечении половины времени разработки штатная численность будет увеличена в 1,5 раза.

12.3.5.4. Применение модели Путнема

Общее описание метода.

Модель Путнема, или модель Релея-Нордена для больших проектов дает существенно нелинейный прогноз взаимосвязи количества разработчиков и хронологического времени для выполнения проекта.

Модель Путнема связывает трудозатраты (ТР) с длительностью разра­ботки проекта (ДР) и размером программного продукта (РП) следующей фор­мулой:

ТР - усилия на разработку проекта (человеко-лет);

РП - число строк кода;

ДР - хронологическое время разработки проекта (годы);.

С - технологическая константа, отражающая технологический уровень в разработке проекта (на практике С=2000 для низкого уровня разработки, С=8000 для хорошей методологии и средств разработки и С более 11000 - для исключительно высокого уровня).

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

Теперь, считая, что ТР и ДР в этом выражении соответствуют достаточно оптимальным значениям, а величина А может рассматриваться в каче­стве константы, можно довольно просто оценить, как изменяется трудоемкость при сокращении или при увеличении сроков разработки. Одновременно можно определить необходимую численность группы разработчиков, а также среднюю производительность труда одного человека в группе.

Пример 5.4. Определение характера изменения параметров про­граммного проекта при отклонениях от номинальной длительности разработки с использованием модели Путнема

Методические указания к выполнению примера 5.4.

Заданы или были определены с использованием модели СОСОМО для конкретного программного продукта значения трудоемкости разработки ТР (человеко-месяцев), длительность разработки ДР (месяцев) и соответствующая им штатная численность разработчиков ШЧ (человек). Приняв эти значе­ния за исходные данные для расчета, определить, как будет изменяться по отношению к этим условиям трудоемкость и требуемая штатная численность при изменении сроков разработки программного продукта. Диапазон изменения длительности разработки ДР относительно исходного (номинального) значения задать в диапазоне от 0.5 до 1.5 с интервалом 0.1.

Последовательность выполнения задания.

1. Для определения исходных данных для оценки влияния длительности разработки на трудоемкость и другие параметры программного продукта можно воспользоваться экспертной оценкой размера продукта РП. На основе дан­ных о числе строк кода с помощью ресурсной модели КОМОСТ определить трудоемкость ТР (в человеко-годах) и длительность разработки ДР в (годах) проекта для условий близких к оптимальным. Одновременно следует опреде­лить штатную численность группы разработчиков и их производительность труда.

2. На основе данных о ТР и ДР по формуле Путнема определить кон­станту А, равную

3. Изменяя значение длительности разработки программного проекта ДР относительно исходной оценки, определить относительное изменение трудоемкости ТР (относительные параметры определять относительно исходных данных, подсчитанных по СОСОМО). Диапазон изменения длительности разработки проекта принять соответствующим заданию.

4. Изменяя значение длительности разработки программного проекта ДР относительно исходного определить относительное изменение штатной численности разработчиков ШЧ. Диапазон изменения длительности разработ­ки проекта принять соответствующим заданию 8.

5. Изменяя значение длительности разработки программного проекта ДР относительно исходного, определить относительное изменение средней производительности труда разработчика в группе ПТ1. Диапазон изменения длительности разработки проекта принять соответствующим заданию.

12.4. Примеры выбора метода и расчета оценок эффективности

12.4.1. Информационной системы управления инновационным учебным заведением

Необходимо разработать информационную систему управления инновационным учебным заведением. Для оценки эффективности разработки выбран функционально-стоимостной анализ ФСА (англ. ABC – Activity Based Costing).

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

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

Именно при разработке ФМ определяются излишние функции, выявляются основные причинно-следственные связи рассматриваемых объектов ФСА.

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

Основные функции определяют принцип действия объекта и включают функции ввода энергии, информации, их преобразования и вывода. Вспомогательная функция обеспечивает реализацию одной или нескольких основных, а также второстепенных внешних функций изделия. Нейтральные функции в построении ФМ не участвуют (рисунок 12.4.1.1).

Рисунок 12.4.1.1 – Функциональная модель

Для определения значимости функций строятся матрицы парного сравнения (таблицы 12.4.1.1 – 12.4.1.5).

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

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

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

Таблица 12.4.1.1 – Матрица парного сравнения функций 1-го уровня

Индекс функции

Количество

предпочтений

Значимость

Итого

Таблица 12.4.1.2 – Матрица парного сравнения функций 2-го уровня (F1)

Общее описание метода оценки

Функционально-ориентированные метрики - это косвенные меры для оценки программного продукта и процесса его разработки; они фокусируют внимание на "функциональности" программного изделия или "полезности" про­граммы. В 1979 г был предложен подход к измерению производительности труда разработчиков программного обеспечения, названный методом функ­циональной точки (FP - function point method ).

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

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

Таблица 7

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

Измеряемый параметр		Весовой коэффициент
Входы пользо­вателей
Выходы пользо­вателей
Запросы поль­зователей
Внешние ин­терфейсы
Общий итог

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предназначены ли созданные программы для повторного использования?

Включены ли в проект работы по вводу в действие и по адаптации системы?

Предусматривает ли конфигурация системы ее установку в различ­ных организациях?

Предусмотрено ли в проекте удобство работы пользователей и про­стота внесения изменений?

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

Задание 4. Определение числа функциональных то­чек для программного продукта

Методические указания к выполнению задания 4

На основе требований пользователя и схем потоков данных будущей программной системы провести подсчет числа функциональных точек ФТ. С этой целью провести анализ информационной области проектируемого про­граммного продукта и определить 5 ее информационных параметров (см. табл. 7), оценив важность каждого. Проанализировать и оценить каждый из перечисленных выше 14 факторов, характеризующих особенности функцио­нирования разрабатываемой информационной системы.

Примечание . Задание выполняется при курсовом проектировании информационной системы студентами специальности "Информационный ме-неджемент".

Последовательность выполнения задания.

1. Составить табл. 7 для заполнения экспертными оценками и после­дующего определения основных параметров программного продукта.

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

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

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

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

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

ФТ = общий итог*(0.65+ 0.01* сумма коэффициентов),

где общий итог - это сумма всех строк последнего столбца табл. 7.

После того как значение функциональных точек вычислено, оно может использоваться, как и в случае с числом строк кода, для определения относи­тельных мер: производительности труда (число функциональных точек на один человеко-месяц), стоимости разработки одной точки, количества стра­ниц документации на одну точку и т.д. Мера функциональных точек может ис­пользоваться для сравнения различных проектов, для оценки производитель­ности, достигнутой в организации и т.п.

Развитие функционального подхода.

Мера функциональной точки, первоначально предложенная для приме­нения к приложениям в области деловых информационных систем, была за­тем распространена с некоторыми модификациями на другие приложения. Развитие этого метода оценки программных продуктов получило название метода характерных точек (feature points ). Этот метод может быть применен для оценки проектов более широкого круга приложений. Мера характерных то­чек особенно пригодна для приложений с высокой степенью алгоритмической сложности, которая присуща системам реального времени, управленческим процессам и встроенным системам, поэтому именно для них целесообразно применять меру характерной точки (XT).

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

Следует отметить, что оба метода (ФТ и XT) отражают одну и туже сторону программного продукта - его "функциональность" и "полезность". И тот и другой подходы дают близкие результаты для обычных инженерных вычислительных задач и информационных систем. Для более сложных систем осо­бенно реального времени итоговое значение для XT на 20-35% выше, чем итог, определенный с использованием ФТ.

Согласование размеро-ориентированных и функционально-ориентированных подходов к оценке программных проектов.

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

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

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

Таблица 8.

Соотношение метрик функциональных точек и строк кода

Язык программирования
Ассемблер
Объектно-ориентированные языки
Языки 4-го поколения
Генераторы кода

Очевидно, что обе метрики не совершенны и при их определении много субъективных оценок экспертов. Защитники функционально-ориентированного подхода считают его более прогрессивным по сравнению с методом, основан­ным на оценке размеров программного продукта, поскольку ФТ не зависит от языка программирования. Кроме этого, поскольку функционально-ориентированная метрика основана на данных, вытекающих из анализа пред­метной области, то меру ФТ более просто определить уже на ранних этапах разработки проекта. В результате оценка ресурсов при планировании разра­ботки оказывается более обоснованной. Оппоненты этого метода утверждают, что функционально-ориентированный подход основан в большей степени на субъективных оценках, а мера функциональных точек не имеет физического смысла, т.к. выражается абстрактным числом. Несмотря на критические заме­чания оба подхода дают менеджеру полезную информацию, позволяющую уже на начальных этапах получить оценки проекта с достоверностью, соот­ветствующей начальному этапу проектирования.