JК
Модель зрелости процессов разработки программного обеспечения :: Паулк Марк
Страница: 208 из 257 Независимая от разработчиков группа проверяет процедуры оценки объема промежуточных программных продуктов и дает рекомендации по использованию статистической информации из базы данных ППО для получения достоверных оценок.
Примером независимой группы может служить группа выполнения оценочных расчетов для составляющих проекта.
Примером метода определения достоверности оценок объема ПО может служить функциональное сравнение проектируемой системы с законченной.
Сотрудники, подготавливающие оценки объема, должны обеспечить соответствующий выбор процедур и данных, используемых при оценках.
Если достоверность оценки объема оказывается спорной, эта оценка проверяется группой экспертов.
2. При оценке объема каждого элемента ПО учитывается фактор непредвиденности, идентифицируемый как риск разработки.
Обоснование непредвиденных обстоятельств должно документироваться.
Оцениваются и документируются риски, связанные со снижением или устранением непредвиденности.
3. Определяются приобретаемые или повторно используемые программные компоненты.
Оценивается возможность повторного использования требований, архитектуры, кода, планов и процедур тестирования и т. п.
При оценках объема учитывается фактор трудоемкости модификации и внедрения повторно используемых компонентов.
4. Определяются и тщательно отслеживаются факторы, способные оказать значительное влияние на объем промежуточных программных продуктов.
5.
Примером независимой группы может служить группа выполнения оценочных расчетов для составляющих проекта.
Примером метода определения достоверности оценок объема ПО может служить функциональное сравнение проектируемой системы с законченной.
Сотрудники, подготавливающие оценки объема, должны обеспечить соответствующий выбор процедур и данных, используемых при оценках.
Если достоверность оценки объема оказывается спорной, эта оценка проверяется группой экспертов.
2. При оценке объема каждого элемента ПО учитывается фактор непредвиденности, идентифицируемый как риск разработки.
Обоснование непредвиденных обстоятельств должно документироваться.
Оцениваются и документируются риски, связанные со снижением или устранением непредвиденности.
3. Определяются приобретаемые или повторно используемые программные компоненты.
Оценивается возможность повторного использования требований, архитектуры, кода, планов и процедур тестирования и т. п.
При оценках объема учитывается фактор трудоемкости модификации и внедрения повторно используемых компонентов.
4. Определяются и тщательно отслеживаются факторы, способные оказать значительное влияние на объем промежуточных программных продуктов.
5.