1. Понятие измерений, мер и метрик программного проекта .Их назначение

Начало проекта содержит следующие действия:

• установление цели и проблемной области проекта;

• выявление и рассмотрение альтернативных решений;

• выявление технических и управленческих ограничений.

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

Измерения помогают понять как процесс разработки, так и сам продукт. Измерения процесса производятся с целью его улучшения, а измерения продукта – для повышения качества. В результате измерения определяется:

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

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

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

На стадии анализа риска исследуется область неопределенности, имеющаяся в наличии при создании проекта. Анализируется ее влияние на проект, и ищутся ответы на вопросы:

• Нет ли скрытых от внимания трудных технических проблем?

• Не станут ли изменения, проявившиеся в ходе проектирования, причиной недопустимого отставания по срокам?

В результате принимается решение – выполнять проект или нет.(ДАЛЬШЕ МНЕ ККАЖЕТСЯ ВОДА!!!!))))

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

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

• перераспределены ресурсы;

• реорганизованы задачи;

• пересмотрены выходные обязательства.

Основной задачей планирования является определение структуры распределения работ (WBS – Work Breakdown Structure), которая составляется с помощью утилиты планирования проекта.

Системный анализ проводится с целью:

1. выяснения потребностей заказчика;

2. оценки выполнимости системы;

3. выполнения экономического и технического анализа;

4. распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т.д.);

5. определения стоимости и ограничений планирования;

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

Анализ требований дает возможность:

1. определить функции и характеристики программного продукта;

2. обозначить интерфейс продукта с другими системными элементами;

3. определить проектные ограничения программного продукта;

4. построить модели: процесса, данных, режимов функционирования продукта;

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

2. Размерно-ориентированные метрики: способы определения, преимущества и недостатки

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC-оценка (LOC – Lines Of Code) – количестве строк в программном продукте.

Исходными данными для расчета этих метрик являются:

• затраты (человеко-месяцы);

• Стоимость (денежные единицы);

• KLOC (в тысячах LOC);

• программные документы (количество страниц);

• ошибки (количество);

• количество людей, задействованных в проекте.

На основе исходных данных вычисляются размерно-ориентированные метрики производительности и качества проекта:

Достоинства размерно-ориентированных метрик:

• широкое распространение и легкая адаптируемость;

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

• непосредственная связь с конечным продуктом;

• легкая оценка до завершения проекта;

• оценка размеров ПО на основе точки зрения разработчика – физическая оценка созданного продукта.

Недостатки размерно-ориентированных метрик:

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

• строки исходного кода могут различаться в зависимости от типов языков программирования, методов проектирования, стиля и способностей программиста;

• применение методов оценки с помощью подсчета количества строк кода не регламентируется промышленными стандартами;

• разработка ПО может быть связана с большими затратами, которые прямо не зависят от размеров программного кода (спецификации требований, руководства пользователя и т.д.);

• при подсчете количества LOC следует различать автоматически и вручную созданный код;

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

3. Функционально-ориентированные метрики: способы определения.

Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки, при этом рассматривается функциональность или полезность продукта. Используется 5 информационных характеристик:

1. Количество внешних вводов.

2. Количество внешних выводов.

3. Количество внешних запросов.

4. Количество внутренних логических файлов.

5. Количество внешних интерфейсных файлов.

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

После сбора всей необходимой информации осуществляется расчет метрики – количества функциональных показателей FP – Function Point (автор А. Албрехт, 1979). Исходные данные для расчета сводятся в таблицу.

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

где F_i – коэффициенты регулировки сложности, которые могут принимать следующие значения: 0 – нет влияния, 1 – случайное, 2 – небольшое, 3 – среднее, 4 – важное, 5 – основное.

После вычисления FP на его основе формируются метрики производительности, качества и т.д.:

Преимущества функционально-ориентированных метрик:

• не зависят от языка программирования;

• легко вычисляются на любой стадии проекта.

Недостаток: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.

4. Процесс оценки проекта на основе размерно-(функционально-)ориентированных метрик

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC-оценка (LOC – LinesOfCode) – количестве строк в программном продукте.

Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки, при этом рассматривается функциональность или полезность продукта. Расчет метрики – количество функциональных показателей FP – FunctionPoint.

Выполнение оценки проекта на основе LOC- или FP-метрик

Цель этой деятельности – сформировать предварительные оценки, которые позволят:

• предъявить заказчику корректные требования по стоимости и затратам на разработку программного продукта;

• составить план программного проекта.

При выполнении оценки возможны два варианта использования LOC- и FP-данных:

• в качестве оценочных переменных, определяющих размер каждого элемента продукта;

• в качестве метрик, собранных за прошлые проекты и входящие в метрический базис фирмы.

Шаги процесса оценки:

Шаг 1: Область назначения проектируемого продукта разбивается на ряд функций, каждую из которых можно оценить индивидуально: f₁,f₂,...,f_n.

Шаг 2: Для каждой функции f_i планировщик формирует лучшую, худшую и вероятную оценку (LOC- или FP-). Используются опытные данные (из метрического базиса) или интуиция.

Шаг 3: Для каждой функции f_i в соответствии с β-распределением вычисляется ожидаемое значение LOC- (или FP-) оценки: LOC_ожид = (LOC_лучш+LOC_худш+4×LOC_вер) / 6.

Шаг 4: Определяется значение LOC- или FP-производительности разработки функции: Используется один из трех подходов:

1. для всех функций принимается одна и та же метрика средней производительности ПРОИЗВ_ср, взятая из метрического базиса;

2. для i-ой функции на основе метрики средней производительности вычисляется настраиваемая величина производительности: , где LOC_сред – средняя LOC-оценка, взятая из метрического базиса (соответствует средней производительности);

3. для i-ой функции настраиваемая величина производительности вычисляется по аналогу, взятому из метрического базиса: .

Первый подход обеспечивает минимальную точность (при максимальной простоте вычислений), а третий подход – максимальную точность (при максимальной сложности вычислений).

Шаг 5: Вычисляется общая оценка затрат на проект:

для первого подхода:

для второго и третьего подхода:

Шаг 6: Вычисляется общая оценка стоимости проекта:

для первого и второго подходов: , где УД_СТОИМОСТЬ_ср – метрика средней стоимости одной строки, взятая из метрического базиса.

для третьего подхода: , где УД_СТОИМОСТЬ_анi – метрика стоимости одной строки аналога, взятая из метрического базиса.

4. Cocomo 81: принципы оценки, иерархия , типы по

Авторконструктивной модели стоимости - Барри Боэм дал ей название COCOMO 81 (COnstructiveCOstModel), используется в качестве модели для оценки трудоемкости, себестоимости и плана-графика для проектов по разработке программного обеспечения. Боэм ввел в ее в состав три разные по сложности статистические подмодели:

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

• промежуточнаяCOCOMO – дополнительно учитывает атрибуты стоимости, включающие основные оценки продукта, аппаратуры, персонала и проектной среды;

• усовершенствованнаяCOCOMO – объединяет все характеристики промежуточной модели, дополнительно учитывает влияние всех атрибутов стоимости на каждый этап процесса разработки ПО (анализ, проектирование, кодирование, тестирование и т.д.).

Подмодели COCOMO 81 могут применяться к трем типам программных проектов:

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

• полунезависимый тип – средний по размеру проект, выполняется группой разработчиков с разным опытом, устанавливаются как мягкие, так и жесткие требования к проекту;

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

Уравнения базовой модели имеют вид:

Трудоемкость - E=a*(KLOC)^b (чел-месяц) 

Срок разработки или длительность – D=c*E^d (месяцев)

Число разработчиков = Трудоемкость/ Срокразработки  (человек)

где E – затраты в человеко-месяцах, D – время разработки, KLOC – количество строк в программном продукте. Коэффициенты a, b, c, d берутся из таблицы, в которой указаны фиксированные значения для каждого типа проекта.