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

Подход декомпозиции был обсужден с двух различных точек зрения: декомпозиция проблемы и декомпозиции процесса. Оценки одни и те же Но прежде, чем оценка может быть сделана, проектный планировщик должен понять возможности разрабатываемого программного обеспечения, и произвести оценку его "размера".

4.6.1 Калибровка Программного обеспечения

Точность оценки проекта программного обеспечения основана в ряде вещей: (1) степень точности оценки размера; (2) способность перевести оценки размера в человеческие усилия, календарное время, и доллары (функция пригодности(готовности) надежной метрики программного обеспечения от мимо проектов); (3) степень, в которой план проекта отражает способности команды программного обеспечения; и (4) стабильность требований изделия и окружающей среды, которая поддерживает программное обеспечение техническое усилие.

В контексте планирования проекта, размер относится к измеримому результату проекта программного обеспечения. Если прямой подход принят, размер может быть измерен в LOC. Если косвенный подход выбран, размер представлен как FP.

Putnam и Myers [PUT92] предлагают четыре различных подхода проблеме измерения размеров:

Измерение р-ов " Нечеткая логика ".

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

пункта(точки) Функции.

Планировщик развивает оценки информационных обсужденных характеристик области.

Измерение размеров стандартных компонентов

Программное обеспечение составлено из множества различного " стандартные компоненты " которые являются родовыми к специфической прикладной области.

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

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

4.6.2 Проблемно-основанная Оценка

Строки кода и функциональных точек функции были описаны как меры, на основании которых метрика производительности может быть вычислена. LOC и FP данные используются двумя способами в течение оценки проекта программного обеспечения: (1) как переменная оценки "размера" каждого элемента программного обеспечения и (2), как базовая метрика, полученная из предыдущих проектов и используемая в сочетании с оценками стоимости и усилий.

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

Метрика базовой производительности (например, LOC/pm или FP/PM) применяется к соответствующей переменной оценки стоимости или усилий для функции. Оценки Функции объединены, чтобы произвести полную оценку для полного проекта.