Управление проектом программного обеспечения, страница 8

Как только функции проблемы и действия процесса - melded, планировщик оценивает усилие (например, человек-месячный) который будет требоваться, чтобы выполнить каждую деятельность процесса программного обеспечения для каждой функции программного обеспечения. Эти данные составляют центральную матрицу стола в Числе(фигуре) 2.2. Составьте в среднем трудовые нормы(разряды) (то есть, усилие стоимости / единицы) тогда применяется к усилию, оцененному для каждой деятельности процесса. Вероятно, что  трудовая норма(разряд) изменится для каждой задачи. Старший штат, тяжело вовлеченный в ранние действия вообще более дорог чем младший штат, вовлеченный в более поздние задачи проекта, закодирует поколение, и рано испытание.

Изобразите 4.5 Процесс-основанных стол оценки

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

4.7 МОДЕЛИ ЭМПИРИЧЕСКОГО ОЦЕНИВАНИЯ

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

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

4.7.1 Структура Моделей Оценки

Типичная модель оценки получена, используя РЕГРЕССИОННЫЙ АНАЛИЗ данных, собранных от прошлых проектов программного обеспечения. Полная структура таких моделей берет форму [MAT94]

Где A, B, и C опытным путем получены, константы, E - усилие в человек-месячном, и ev - переменная оценки (или LOC или FP). В дополнение к отношениям, отмеченным в Уравнении (4-2), большинство моделей оценки имеет некоторую форму проектного(строительного) компонента регулирования, который позволяет E быть отрегулированным(приспосабливаемым) в соответствии с другими проектными(строительными) характеристиками (например, сложностью проблемы, опытом штата, окружающая среда развития). Среди многих LOC-ОРИЕНТИРОВАННЫХ моделей оценки, предложенных в литературе

FP-oriented models have also been proposed. These include

Быстрая экспертиза этих моделей указывает, что каждый выдаст(уступит) различный результат за те же самые ценности LOC или FP. Значение ясно. Модели Оценки должны быть калиброваны для местных потребностей!

4.7.2 COCOMO Модель

В его классической книге по " программное обеспечение техническая экономика, " Барри Боехм [BOE81] представил иерархию моделей оценки программного обеспечения, несущих название(имя) COCOMO, для КОНСТРУКТИВНОЙ МОДЕЛИ СТОИМОСТИ. Оригинал COCOMO модель стал одним из наиболее широко используемые и обсужденные модели оценки стоимости программного обеспечения в промышленности. Это развилось в более всестороннюю модель оценки, называемую COCOMO ВТОРОЙ [BOE96, BOEOO]. Подобно его предшественнику, COCOMO ВТОРОЙ - фактически иерархия моделей оценки, которые адресуют следующие области: