Оценка затрат на проект. Мера и метрика

Оценка затрат на проект. Мера и метрика Измерения помогают понять как процесс разработки продукта, так и сам продукт. Измерения процесса производятся в целях его улучшения, измерения продукта — для повышения его качества. В результате измерения определяется мера — количественная характеристика какого-либо свойства объекта. Путем непосредственных измерений могут определяться только опорные свойства объекта. Все остальные свойства оцениваются в результате вычисления тех или иных функций от значений опорных характеристик. Вычисления этих функций проводятся по формулам, дающим числовые значения и называемым метриками. В IEEE Standard Glossary of Software Engineering Terms метрика определена как мера степени обладания свойством, имеющая числовое значение. В программной инженерии понятия мера и метрика очень часто рассматривают как синонимы. При планировании программного проекта надо оценить людские ресурсы (в человеко-месяцах), продолжительность (в календарных датах), стоимость (в денежных единицах). Обычно исходят из прошлого опыта. Если новый проект по размеру и функциям похож на предыдущий проект, вполне вероятно, что потребуются такие же ресурсы, время и деньги. Планирование проектных задач Основной задачей при планировании является определение WBS — Work Breakdown Structure (структуры распределения работ). Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рис. 2.2. Первыми выполняемыми задачами являются системный анализ и анализ требований. Они закладывают фундамент для последующих параллельных задач. Системный анализ проводится с целью: 1) выяснения потребностей заказчика; 2) оценки выполнимости системы; 3) выполнения экономического и технического анализа; 4) распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т. д.); 5) определения стоимости и ограничений планирования; 6) создания системной спецификации. В системной спецификации описываются функции, характеристики системы, ограничения разработки, входная и выходная информация. Анализ требований дает возможность: 1) определить функции и характеристики программного продукта; 2) обозначить интерфейс продукта с другими системными элементами; 3) определить проектные ограничения программного продукта; 4) построить модели: процесса, данных, режимов функционирования продукта; 5) создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования. Результаты анализа сводятся в спецификацию требований к программному продукту. Как видно из типовой структуры, задачи по проектированию и планированию тестов могут быть распараллелены. Благодаря модульной природе ПО для каждого модуля можно предусмотреть параллельный путь для детального (процедурного) проектирования, кодирования и тестирования. После получения всех модулей ПО решается задача тестирования интеграции — объединения элементов в единое целое. Далее проводится тестирование правильности, которое обеспечивает проверку соответствия ПО требованиям заказчика. Ромбиками на рис. 2.2 обозначены вехи расставлены — процедуры контроля промежуточных результатов. Очень важно, чтобы вехи были через регулярные интервалы (вдоль всего процесса разработки ПО). Это даст руководителю возможность регулярно получать информацию о текущем положении дел. Вехи распространяются и на документацию как на один из результатов успешного решения задачи. Параллельность действий повышает требования к планированию. Так как параллельные задачи выполняются асинхронно, планировщик должен определить межзадачные зависимости. Это гарантирует «непрерывность движения к объединению». Кроме того, руководитель проекта должен знать задачи, лежащие на критическом пути. Для того чтобы весь проект был выполнен в срок, необходимо выполнять в срок все критические задачи. Основной рычаг в планирующих методах — вычисление границ времени выполнения задачи. Обычно используют следующие оценки: 1. Раннее время начала решения задачи in Т min (при условии, что все предыдущие задачи решены в кратчайшее время). in 2. Позднее время начала решения задачи Т max (еще не вызывает общую задержку проекта). 3. Раннее время конца решения задачи out Т min . out in Tmin  Tmin  T реш . out 4. Позднее время конца решения задачи Т max . out in Tmax  Tmax  T реш . 5. Общий резерв — количество избытков и потерь планирования задач во времени, не приводящих к увеличению длительности критического пути Тк.п. Все эти значения позволяют руководителю (планировщику) количественно оценить успех в планировании, выполнении задач. Рекомендуемое правило распределения затрат проекта — 40-20-40:  на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ — 5%);  на кодирование — 20%;  на тестирование и отладку — 40%. Размерно-ориентированные метрики Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC-оценках (Lines Of Code). LOC-оценка — это количество строк в программном продукте. Исходные данные для расчета этих метрик сводятся в таблицу (табл. 2.1). Таблица 2.1. Исходные данные для расчета LOC-метрик Проект ааа01 bbb02 ссс03 Затраты, чел.-мес 24 62 43 Стоимость, тыс. $ 168 440 314 KLOC, тыс. LOC 12,1 27,2 20,2 Прогр. док- Ошибки ты, страниц 365 29 1224 86 1050 64 Люди 3 5 6 Таблица содержит данные о проектах за последние несколько лет. Например, запись о проекте aaa01 показывает: 12 100 строк программы были разработаны за 24 человекомесяца и стоили $168 000. Кроме того, по проекту aaa01 было разработано 365 страниц документации, а в течение первого года эксплуатации было зарегистрировано 29 ошибок. Разрабатывали проект aaa01 три человека. На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества (для каждого проекта): Производительность  Качество  Ошибки  Единиц  ; Длина  тыс.LOC  Удельная стоимость  Документирванность  Длина  тыс.LOC  ; Затраты  чел. - мес  Стоимость  Тыс$  ; Длина  LOC  Страниц Документа  Страниц   тыс.LOC  . Длина Достоинства размерно-ориентированных метрик: 1) широко распространены; 2) просты и легко вычисляются. Недостатки размерно-ориентированных метрик: 1) зависимы от языка программирования; 2) требуют исходных данных, которые трудно получить на начальной стадии проекта; 3) не приспособлены к непроцедурным языкам программирования. Функционально-ориентированные метрики Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC-оценки при этом рассматривается не размер, а функциональность или полезность продукта. Используется 5 информационных характеристик. 1. Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно. 2. Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных внутри отчета отдельно не подсчитываются. 3. Количество внешних запросов. Под запросом понимается диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует выполнения вычислений. Подсчитываются все запросы — каждый учитывается отдельно. 4. Количество внутренних логических файлов. Подсчитываются все логические файлы (то есть логические группы данных, которые могут быть частью базы данных или отдельным файлом). 5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение. Вводы, выводы и запросы относят к категории транзакция. Транзакция — это элементарный процесс, различаемый пользователем и перемещающий данные между внешней средой и программным приложением. В своей работе транзакции используют внутренние и внешние файлы. Приняты следующие определения. Внешний ввод — элементарный процесс, перемещающий данные из внешней среды в приложение. Данные могут поступать с экрана ввода или из другого приложения. Данные могут использоваться для обновления внутренних логических файлов. Данные могут содержать как управляющую, так и деловую информацию. Управляющие данные не должны модифицировать внутренний логический файл. Внешний вывод — элементарный процесс, перемещающий данные, вычисленные в приложении, во внешнюю среду. Кроме того, в этом процессе могут обновляться внутренние логические файлы. Данные создают отчеты или выходные файлы, посылаемые другим приложениям. Отчеты и файлы создаются на основе внутренних логических файлов и внешних интерфейсных файлов. Дополнительно этот процесс может использовать вводимые данные, их образуют критерии поиска и параметры, не поддерживаемые внутренними логическими файлами. Вводимые данные поступают извне, но носят временный характер и не сохраняются во внутреннем логическом файле. Внешний запрос — элементарный процесс, работающий как с вводимыми, так и с выводимыми данными. Его результат — данные, возвращаемые из внутренних логических файлов и внешних интерфейсных файлов. Входная часть процесса не модифицирует внутренние логические файлы, а выходная часть не несет данных, вычисляемых приложением (в этом и состоит отличие запроса от вывода). Внутренний логический файл — распознаваемая пользователем группа логически связанных данных, которая размещена внутри приложения и обслуживается через внешние вводы. Внешний интерфейсный файл — распознаваемая пользователем группа логически связанных данных, которая размещена внутри другого приложения и поддерживается им. Внешний файл данного приложения является внутренним логическим файлом в другом приложении. Каждой из выявленных характеристик ставится в соответствие сложность. Для этого характеристике назначается низкий, средний или высокий ранг, а затем формируется числовая оценка ранга. Для транзакций ранжирование основано на количестве ссылок на файлы и количестве типов элементов данных. Для файлов ранжирование основано на количестве типов элементов-записей и типов элементов данных, входящих в файл. Тип элемента-записи — подгруппа элементов данных, распознаваемая пользователем в пределах файла. Тип элемента данных — уникальное не рекурсивное (неповторяемое) поле, распознаваемое пользователем. В качестве примера рассмотрим табл. 2.2. В этой таблице 10 элементов данных: День, Хиты, % от Сумма хитов, Сеансы пользователя, Сумма хитов (по рабочим дням), % от Сумма хитов (по рабочим дням), Сумма сеансов пользователя (по рабочим дням), Сумма хитов (по выходным дням), % от Сумма хитов (по выходным дням), Сумма сеансов пользователя (по выходным дням). Отметим, что поля День, Хиты, % от Сумма хитов, Сеансы пользователя имеют рекурсивные данные, которые в расчете не учитываются. Таблица 2.2. Пример для расчета элементов данных Уровень активности дня недели День Хиты Понедельник 1887 Вторник 1547 Среда 1975 Четверг 1591 Пятница 2209 Суббота 1286 Воскресенье 1004 9209 Сумма по рабочим дням 2290 Сумма по выходным дням % от Сумма хитов 16,41 13,45 17,17 13,83 19,21 11,18 8,73 80,08 19,91 Сеансы пользователя 201 177 195 191 200 121 111 964 232 Примеры элементов данных для различных характеристик приведены в табл. 2.3, а табл. 2.4 содержит правила учета элементов данных из графического интерфейса пользователя (GUI). Таблица 2.3. Примеры элементов данных Информационная характеристика Внешние Вводы Внешние Выводы Внешние Запросы Элементы данных Поля ввода данных, сообщения об ошибках, вычисляемые значения, кнопки Поля данных в отчетах, вычисляемые значения, сообщения об ошибках, заголовки столбцов, которые читаются из внутреннего файла Вводимые элементы: поле, используемое для поиска, щелчок мыши. Выводимые элементы — отображаемые на экране поля Таблица 2.4. Правила учета элементов данных из графического интерфейса пользователя Элемент данных Группа радиокнопок Группа флажков (переключателей) Командные кнопки Списки Правило учета Так как в группе пользователь выбирает только одну радиокнопку, все радиокнопки группы считаются одним элементом данных Так как в группе пользователь может выбрать несколько флажков, каждый флажок считают элементом данных Командная кнопка может определять действие добавления, изменения, запроса. Кнопка ОК может вызывать транзакции (различных типов). Кнопка Next может быть входным элементом запроса или вызывать другую транзакцию. Каждая кнопка считается отдельным элементом данных Список может быть внешним запросом, но результат запроса может быть элементом данных внешнего ввода Например, GUI для обслуживания клиентов может иметь поля Имя, Адрес, Город, Страна, Почтовый Индекс, Телефон, Email. Таким образом, имеется 7 полей или семь элементов данных. Восьмым элементом данных может быть командная кнопка (добавить, изменить, удалить). В этом случае каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8 элементов данных (7 полей плюс командная кнопка). Обычно одному экрану GUI соответствует несколько транзакций. Типичный экран включает несколько внешних запросов, сопровождающих внешний ввод. Обсудим порядок учета сообщений. В приложении с GUI генерируются 3 типа сообщений: сообщения об ошибке, сообщения подтверждения и сообщения уведомления. Сообщения об ошибке (например, Требуется пароль) и сообщения подтверждения (например, Вы действительно хотите удалить клиента?) указывают, что произошла ошибка или что процесс может быть завершен. Эти сообщения не образуют самостоятельного процесса, они являются частью другого процесса, то есть считаются элементом данных соответствующей транзакции. С другой стороны, уведомление является независимым элементарным процессом. Например, при попытке получить из банкомата сумму денег, превышающую их количество на счете, генерируется сообщение Не хватает средств для завершения транзакции. Оно является результатом чтения информации из файла счета и формирования заключения. Сообщение уведомления рассматривается как внешний вывод. Данные для определения ранга и оценки сложности транзакций и файлов приведены в табл. 2.5-2.9 (числовая оценка указана в круглых скобках). Использовать их очень просто. Например, внешнему вводу, который ссылается на 2 файла и имеет 7 элементов данных, по табл. 2.5 назначается средний ранг и оценка сложности 4. таблица 2.5. Ранг и оценка сложности внешних вводов Ссылки на файлы 0-1 2 >2 Элементы данных 1-4 Низкий (3) Низкий (3) Средний (4) 5-15 Низкий (3) Средний (4) Высокий (6) >15 Средний (4) Высокий (6) Высокий (6) Таблица 2.6. Ранг и оценка сложности внешних выводов Ссылки на файлы 0-1 2-3 >3 Элементы данных 1-4 Низкий (4) Низкий (4) Средний (5) 5-19 Низкий (4) Средний (5) Высокий (7) >19 Средний (5) Высокий (7) Высокий (7) Таблица 2.7. Ранг и оценка сложности внешних запросов Ссылки на файлы 0-1 2-3 >3 Элементы данных 1-4 Низкий (3) Низкий (3) Средний (4) 5-19 Низкий (3) Средний (4) Высокий (6) >19 Средний (4) Высокий (6) Высокий (6) Таблица 2.8. Ранг и оценка сложности внутренних логических файлов Типы элементов- Элементы данных записей 1-19 20-50 >50 1 Низкий (7) Низкий (7) Средний (10) 2-5 Низкий (7) Средний (10) Высокий (15) >5 Средний (10) Высокий (15) Высокий (15) Таблица 2.9. Ранг и оценка сложности внешних интерфейсных файлов Типы элементов- Элементы данных записей 1-19 20-50 >50 1 Низкий (5) Низкий (5) Средний (7) 2-5 Низкий (5) Средний (7) Высокий (10) >5 Средний (7) Высокий (10) Высокий (10) Отметим, что если во внешнем запросе ссылка на файл используется как на этапе ввода, так и на этапе вывода, она учитывается только один раз. Такое же правило распространяется и на элемент данных (однократный учет). После сбора всей необходимой информации приступают к расчету метрики — количества функциональных указателей FP (Function Points). Автором этой метрики является А. Албрехт (1979) [7]. Исходные данные для расчета сводятся в табл. 2.10. Таблица 2.10. Исходные данные для расчета FP-метрик Имя характеристики Ранг, сложность, количество Низкий Средний Высокий Итого Внешние вводы 0x3 = __ 0x4 = __ 0x6 = __ =0 Внешние выводы 0x4 = __ 0x5 = __ 0x7 = __ =0 Внешние запросы 0х3 = __ 0x4 = __ 0x6 = __ =0 Внутренние логические файлы 0x7 = __ 0x 10= __ 0x15 = __ =0 Внешние интерфейсные файлы 0x5 = __ 0x7 = __ 0x10 = __ =0 Общее количество =0 В таблицу заносится количественное значение характеристики каждого вида (по всем уровням сложности). Места подстановки значений отмечены прямоугольниками (прямоугольник играет роль метки-заполнителя). Количественные значения характеристик умножаются на числовые оценки сложности. Полученные в каждой строке значения суммируются, давая полное значение для данной характеристики. Эти полные значения затем суммируются по вертикали, формируя общее количество. Количество функциональных указателей вычисляется по формуле 14 FP = Общее количество х (0,65+ 0,01 x  Fi ), (2.1) i 1 где Fi — коэффициенты регулировки сложности. Каждый коэффициент может принимать следующие значения: 0 — нет влияния, 1 — случайное, 2 — небольшое, 3 — среднее, 4 — важное, 5 — основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл. 2.11). Таблица 2.11. Определение системных параметров приложения № 1 2 3 Системный параметр Передачи данных Описание Сколько средств связи требуется для передачи или обмена информацией с приложением или системой? Как обрабатываются распределенные данные и функции обработки? Распределенная обработка данных Производительность 4 Распространенность используемой конфигурации 5 Скорость транзакций 6 7 8 Оперативный ввод данных Эффективность работы конечного пользователя Оперативное обновление 9 Сложность обработки 10 Повторная используемость 11 Легкость инсталляции 12 Легкость эксплуатации 13 Разнообразные условия размещения 14 Простота изменений Нуждается ли пользователь в фиксации времени ответа или производительности?. Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение? Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц) Какой процент информации надо вводить в режиме онлайн? Приложение проектировалось для обеспечения эффективной работы конечного пользователя? Как много внутренних файлов обновляется в онлайновой транзакции? Выполняет ли приложение интенсивную логическую или математическую обработку? Приложение разрабатывалось для удовлетворения требований одного или многих пользователей? Насколько трудны преобразование и инсталляция приложения? Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления? Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций? Была ли спроектирована, разработана и поддержана в приложении простота изменений? После вычисления FP на его основе формируются метрики производительности, качества и т. д.: Производитель  Качество  ФункцУказатель  FP    ; Затраты чел.  мес  Ошибки  Единиц ; ФункцУказатель  FP  Удельная стоимость  Документированность  Область применения метода Стоимость  Тыс.$  ; ФункцУказатель  FP  СтраницДокумента  Страниц  . ФункцУказатель  FP  функциональных указателей — коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики указателей свойств (Features Points). Они применимы к системному и инженерному ПО, ПО реального времени и встроенному ПО. Для вычисления указателя свойств добавляется одна характеристика — количество алгоритмов. Алгоритм здесь определяется как ограниченная подпрограмма вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки. Для формирования указателя свойств составляется табл. 2.12. Таблица 2.12. Исходные данные для расчета указателя свойств № Характеристика 1 2 3 4 5 6 Вводы Выводы Запросы Логические файлы Интерфейсные файлы Количество алгоритмов Количество Общее количество Сложность Итого х4 х5 х4 х7 х7 х3 =0 =0 =0 =0 =0 =0 =0 После заполнения таблицы по формуле (2.1) вычисляется значение указателя свойств. Для сложных систем реального времени это значение на 25-30% больше значения, вычисляемого по таблице для количества функциональных указателей. Достоинства функционально-ориентированных метрик: 1. Не зависят от языка программирования. 2. Легко вычисляются на любой стадии проекта. Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения. FP-оценки легко пересчитать в LOC-оценки. Как показано в табл. 2.13, результаты пересчета зависят от языка программирования, используемого для реализации ПО. Таблица 2.13. Пересчет FP-оценок в LOC-оценки Язык программирования Ассемблер С Кобол Фортран Паскаль C++ Java Ada 95 Visual Basic Visual C++ Delphi Pascal Smalltalk Perl HTML3 LISP Prolog Miranda Haskell Количество операторов на один FP 320 128 106 106 90 64 53 49 32 34 29 22 21 15 64 64 40 38 Выполнение оценки в ходе руководства проектом Процесс руководства программным проектом начинается с множества действий, объединяемых общим названием планирование проекта. Первое из этих действий — выполнение оценки. Оно закладывает фундамент для других действий по планированию проекта. При оценке проекта чрезвычайно высока цена ошибок. Очень важно провести оценку с минимальным риском. Выполнение оценки проекта на основе LOC- и FP-метрик Цель этой деятельности — сформировать предварительные оценки, которые позволят:  предъявить заказчику корректные требования по стоимости и затратам на разработку программного продукта;  составить план программного проекта. При выполнении оценки возможны два варианта использования LOC- и FP-данных:  в качестве оценочных переменных, определяющих размер каждого элемента продукта;  в качестве метрик, собранных за прошлые проекты и входящих в метрический базис фирмы. Обсудим шаги процесса оценки.  Шаг 1. Область назначения проектируемого продукта разбивается на ряд функций, каждую из которых можно оценить индивидуально: f1, f2,…,fn.  Шаг 2. Для каждой функции fi, планировщик формирует лучшую LOCлучшi (FРлучшi), худшую LOCхудшi (FРхудшi) и вероятную оценку LOCвероятнi (FРвероятнi). Используются опытные данные (из метрического базиса) или интуиция. Диапазон значения оценок соответствует степени предусмотренной неопределенности.  Шаг 3. Для каждой функции в соответствии с  -распределением вычисляется ожидаемое значение LOC- (или FP-) оценки: LOCожi =(LOCлучшi + LOCхудшi +4x LOCвероятнi )/ 6.  Шаг 4. Определяется значение LOC- или FP-производительности разработки функции. Используется один из трех подходов: 1) для всех функций принимается одна и та же метрика средней производительности ПРОИЗВср, взятая из метрического базиса; 2) для i-й функции на основе метрики средней производительности вычисляется настраиваемая величина производительности: ПРОИЗВi =ПРОИЗВсрх(LOCср /LOCожi), где LOCcp — средняя LOC-оценка, взятая из метрического базиса (соответствует средней производительности); 3) для i-й функции настраиваемая величина производительности вычисляется по аналогу, взятому из метрического базиса: ПРОИЗВi =ПРОИЗВанiх(LOCанi /LOCожi). Первый подход обеспечивает минимальную точность (при максимальной простоте вычислений), а третий подход — максимальную точность (при максимальной сложности вычислений).  Шаг 5. Вычисляется общая оценка затрат на проект: для первого подхода n ЗАТРАТЫ  ( LOCожi ) / ПРОИЗВср чел. - мес ; i 1 для второго и третьего подходов n ЗАТРАТЫ   (LOCожi / ПРОИЗВi )чел. - мес . i 1  Шаг 6. Вычисляется общая оценка стоимости проекта: для первого и второго подходов n СТОИМОСТЬ  ( LOCожi ) УД_СТОИМОСТЬ ср , i 1 где УД_СТОИМОСТЬср — метрика средней стоимости одной строки, взятая из метрического базиса. для третьего подхода n СТОИМОСТЬ   (LOCожi УД_СТОИМОСТЬ анi ), i 1 где УД_СТОИМОСТЬанi — метрика стоимости одной строки аналога, взятая из метрического базиса. Пример применения данного процесса оценки приведем ниже.