Пиши Дома Нужные Работы

Обратная связь

Выполнение оценки в ходе руководства проектом

Оценка проекта на основе LOC- И FP-метрик

 

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

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

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

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

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

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

Алгоритм процесса оценки:

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

f1, f2,...,fn.

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

Шаг 3. Для каждой fi в соответствииβ-распределением вычисляется ожидаемое значение LOC- (или FP) оценки:

LOCож i = (LOCлучш i + LOCхудш i + 4 * LOCвероятн i) / 6.

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

Используется один из трёх подходов:



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

2) для i-й функции на основе метрики средней производительности вычисляется настраиваемая величина производительности:

ПРОИЗВi = ПРОИЗВср * (LOCср / LOCож i),

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

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

ПРОИЗВi = ПРОИЗВан i * (LOC ан i / LOCож i).

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

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

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

ЗАТРАТЫ = ∑i=1n (LOCож i ) / ПРОИЗВср [чел.-мес];

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

ЗАТРАТЫ = ∑i=1n (LOCож i / ПРОИЗВi )[чел.-мес].

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

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

СТОИМОСТЬ = ( ∑i=1n LOCож i ) * УД_СТОИМОСТЬср,

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

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

СТОИМОСТЬ = ∑i=1n (LOCож i * УД_СТОИМОСТЬан i ),

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

 

Конструктивная модель стоимости COCOMO

 

В данной модели для вывода формул использовался статический подход – учитывались реальные результаты огромного количества проектов. Автор оригинальной модели – Барри Боэм (1981) – дал ей название COCOMO 81 (Constructive Cost Model) и ввёл в её состав три разные по сложности статические подмодели .

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

Подмодели СОСОМО 81 могут применяться к трём типам программных проектов. По терминологии Боэма, их образуют: распространённый тип – небольшие программные проекты, над которыми работает небольшая группа разработчиков с хорошим стажем работы, устанавливаются мягкие требования к проекту; полунезависимый тип – средний по размеру проект, выполняется группой разработчиков с разным опытом, устанавливаются как мягкие, так и жёсткие требования к проекту; встроенный тип – программный проект разрабатывается в жёстких условиях аппаратных, программных и вычислительных ограничений.

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

E = ab * (KLOC)bb [чел-мес];

D = cb * (E)db [мес],

где E – затраты в человеко-месяцах, D – время разработки, KLOC – количество строк в программном продукте. Коэффициенты ab, bb, cb, db берутся из таблицы 14.

 

Таблица 14. Коэффициенты для базовой модели СОСОМО 81

Тип проекта ab bb cb db
Распространённый 2,4 1,05 2,5 0,38
Полунезависимый 3,0 1,12 2,5 0,35
Встроенный 3,6 1,20 2,5 0,32

 

В 1995 году Боэм ввёл более совершенную модель СОСОМО II, ориентированную на применения в программной инженерии XXI века.

 

Контрольные вопросы

 

  1. Что такое метрика?
  2. Охарактеризуйте рекомендуемое правило распределения затрат проекта.
  3. Какие размерно-ориентированные метрики вы знаете?
  4. Для чего используются размерно-ориентированные метрики?
  5. Определите достоинства и недостатки размерно-ориентированных метрик.
  6. Что такое функциональный указатель?
  7. Что такое указатель свойств?
  8. От каких информационных характеристик зависит функциональный указатель?
  9. Как вычисляется количество функциональных указателей?
  10. От каких характеристик зависит указатель свойств?
  11. Что такое коэффициенты регулировки сложности в метрике функциональных указателей?
  12. В чем отличие расчета метрик для информационных и инженерных задач?
  13. Что показывает производительность, рассчитываемая с помощью LOC или FP?
  14. Что показывает качество, рассчитываемое с помощью LOC или FP?
  15. Из чего складываются затраты, учитываемые при расчете метрик?
  16. Определите достоинства и недостатки функционально-ориентированных метрик?
  17. Можно ли перейти от LOC-оценок к FP-оценкам?
  18. В чем суть предварительной оценки проекта с помощью LOCи FP-метрик?
  19. Что такое метрический базис?
  20. Что такое конструктивная модель стоимости и для чего она применяется?

 

 

Глава 4. Структурное проектирование

Классические методы анализа. Структурный анализ

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

Диаграммы потоков данных

Структурный анализ - один из формализованных методов анализа требований к ПО. Автор этого метода – Том Де Марко (1979). В этом методе программное изделие рассматривается как преобразователь информационного потока данных. Основной элемент структурного анализа – диаграмма потока данных.

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

Дальше уточнение (например, преобразователя F3) приводит к диаграмме 2-го уровня. Говорят, что ППД1 разбивается на диаграммы 2-го уровня.

 
 
Внешний объект

 


Источник или потребитель информации

Преобразователь (принимает и обрабатывает данные)

 

Скорость

Поток данных (должен иметь метку)

Хранилище

данных Запоминает информацию, используемую преобразователем

рис. 1. Элементы диаграммы потоков данных

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

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

Внешний объект
Внешний объект
А В ПДД0

       
   


X Z

А В

ПДД1


Y V

Y1

Y Y2 V

ПДД2

Рис.2 Пример диаграммы потоков данных

 

Словарь требований (данных) содержит описания потоков данных и хранилищ данных. Словарь требований является неотъемлемым элементом любой CASE-утилиты автоматизации анализа. Структура словаря зависит от особенностей конкретной CASE-утилиты. Тем не менее можно выделить базисную информацию типового словаря требований. Большинство словарей содержит информацию.

  1. Имя (основное имя элемента данных, хранилища или внешнего объекта.)
  2. Прозвище (Alias) – другие имена того же объекта.
  3. Где и как используется объект - список процессов, которые используют данный элемент, с указанием способа использования (ввод в процесс, вывод из процесса, как внешний объект или как память).
  4. Описание содержания – запись для представления содержания.
  5. дополнительная информация – дополнительные сведения о типах данных, допустимых значениях, ограничениях и т.д.

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






ТОП 5 статей:
Экономическая сущность инвестиций - Экономическая сущность инвестиций – долгосрочные вложения экономических ресурсов сроком более 1 года для получения прибыли путем...
Тема: Федеральный закон от 26.07.2006 N 135-ФЗ - На основании изучения ФЗ № 135, дайте максимально короткое определение следующих понятий с указанием статей и пунктов закона...
Сущность, функции и виды управления в телекоммуникациях - Цели достигаются с помощью различных принципов, функций и методов социально-экономического менеджмента...
Схема построения базисных индексов - Индекс (лат. INDEX – указатель, показатель) - относительная величина, показывающая, во сколько раз уровень изучаемого явления...
Тема 11. Международное космическое право - Правовой режим космического пространства и небесных тел. Принципы деятельности государств по исследованию...



©2015- 2022 pdnr.ru Все права принадлежат авторам размещенных материалов.