Оценка и планирование программного обеспечения

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

Definition

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

Scope

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

Core questions

• Как измеряется размер программного обеспечения для получения оценок?
• Как сравниваются алгоритмические методы, методы аналогии и экспертной оценки?
• Как неопределенность представляется и уменьшается по мере выполнения проекта?
• Чем гибкое планирование с использованием скорости отличается от предварительного составления расписания?

Key theories

Алгоритмические модели стоимости

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

Определение размера по функциональным точкам

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

Clinical relevance

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

Evidence & guidelines

Эмпирические исследования точности оценки и такие модели, как COCOMO II, предоставляют научно обоснованные рекомендации, а подсчет функциональных точек регулируется стандартами IFPUG и ISO/IEC по измерению функционального размера.

History

Функциональные точки были введены Альбрехтом в конце 1970-х годов, а COCOMO — Боэмом в 1981 году, что придало оценке количественную основу; последующая работа уточнила модели (COCOMO II), изучила предвзятость оценки и представила легковесные методы относительного определения размера для гибкого планирования.

Debates

Оценка против движения «без оценок»

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

Key figures

• Barry Boehm
• Allan Albrecht
• Steve McConnell

Seminal works

• boehm1981
• albrecht1983
• mcconnell2006

Frequently asked questions

Почему оценки программного обеспечения так часто ошибочны?

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

Являются ли стори-пойнты просто замаскированными часами?

Нет. Стори-пойнты выражают относительный размер и сложность, а не абсолютное время; в сочетании с наблюдаемой скоростью команды они дают прогнозы, но приравнивание одного пойнта к фиксированному количеству часов подрывает их цель — отражение относительных усилий.