АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Оценка многокомпонентного продукта

Читайте также:
  1. A) анализ и самооценка собственных достижений
  2. E. У продуктах та готових стравах не повинно бути токсичних речовин в шкідливих для організму концентраціях
  3. II. Оценка облигаций.
  4. II. ОЦЕНКА РАДИАЦИОННОЙ ОБСТАНОВКИ.
  5. II. Оценка соответствия наименования СИЗ и нормы их выдачи наименованиям СИЗ и нормам их выдачи, предусмотренным типовыми нормами
  6. III часть урока. Выставка, анализ и оценка выполненных работ.
  7. III. Бактериологическая оценка молока.
  8. III. Оценка наличия документов, подтверждающих соответствие СИЗ требованиям технического регламента
  9. V. Оценка эффективности выбора СИЗ
  10. VI. Оценка эффективности применения СИЗ
  11. VII. Комплексная оценка эффективности СИЗ
  12. А) Выявление и оценка химической обстановки при авариях (разрушениях) на химически опасных объектах.

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

Следует понимать, что суммарная трудоемкость проекта не равна простой сумме трудоемкостей разработки каждого из компонентов:

Простая сумма не учитывает взаимосвязи компонентов и трудозатраты на их интеграцию.

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

1. Суммарный размер продукта рассчитывается, как сумма размеров его компонентов:

2. Базовая трудоемкость проекта рассчитывается по формуле:

3. Затем рассчитывается базовая трудоемкость каждого компонента:

4. На следующем шаге рассчитывается оценка трудоемкости компонентов с учетом всех множителей трудоемкости, кроме множителя SCED.

5. И, наконец, итоговая трудоемкость проекта определятся по формуле:

 

Оценка длительности проекта

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

где

· С = 3,67; D = 0,28;

· PMNS — трудоемкость проекта без учета множителя SCED, определяющего сжатие расписания.

Выводы

Оценка трудоемкости должна быть вероятностным утверждением. Это означает, что для нее существует некоторое распределение вероятности, которое может быть очень широким, если неопределенность высокая, или достаточно узким, если неопределенность низкая.

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

Если собственный опыт аналогичных проектов отсутствует, а коллеги-эксперты недоступны, то необходимо использовать формальные методики, основанные на обобщенном отраслевом опыте. Среди них наибольшее распространение получили два подхода:

· FPA IFPUG — метод функциональных точек,

· метод COCOMO II, Constructive Cost Model.

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

Дополнительная литература и источники

1. С. Макконнелл, «Сколько стоит программный проект», «Питер», 2007.

2. Function Point Counting Practices Manual, Release 4.2, IFPUG, 2004.

3. Barry Boehm. «Software engineering economics». Englewood Cliffs, NJ:Prentice-Hall, 1981

4. Barry Boehm, et al. «Software cost estimation with COCOMO II». Englewood Cliffs, NJ:Prentice-Hall, 2000.

5. «Function Point Programming Languages Table», Quantitative Software Management, Inc., 2005.


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 |

Поиск по сайту:

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