9.8 KiB
| title | localeTitle |
|---|---|
| Actual Time Estimation | Оценка фактического времени |
Оценка фактического времени
Оценка фактического времени - это процесс прогнозирования наиболее реалистичных усилий (выраженных в единицах человеко-часов или денег), необходимых для разработки или обслуживания программного обеспечения на основе неполного, неопределенного и шумного ввода. Оценки усилий могут использоваться в качестве вклада в планы проектов, планы итераций, бюджеты, анализ инвестиций, процессы ценообразования и раунды торгов.
Государство-оф-практики
Опубликованные исследования по практике оценки предполагают, что экспертная оценка является доминирующей стратегией при оценке усилий по разработке программного обеспечения.
Как правило, оценки усилий чрезмерно оптимистичны, и существует высокая степень уверенности в их точности. Среднее превышение усилий, по-видимому, составляет около 30% и не уменьшается со временем. Для обзора обследований ошибок оценки усилия см. Однако измерение ошибки оценки является проблематичным, см. Оценка точности оценок. Сильная чрезмерная уверенность в точности оценок усилий иллюстрируется тем фактом, что в среднем, если профессионал программного обеспечения на 90% уверен или почти уверен, чтобы включить фактические усилия в минимально-максимальный интервал, наблюдаемая частота включения фактическое усилие составляет всего 60-70%.
В настоящее время термин «оценка усилий» используется для обозначения различных концепций, таких как наиболее вероятное использование усилий (модальное значение), усилия, которые соответствуют вероятности 50% не превышающей (медианной), запланированных усилий, бюджетных усилий или усилие, используемое для того, чтобы предлагать цену или цену клиенту. Это считается неудачным, потому что проблемы коммуникации могут возникать и потому, что концепции служат различным целям.
история
Исследователи и практические работники программного обеспечения рассматривают проблемы оценки усилий для проектов разработки программного обеспечения с по крайней мере в 1960-х годах; см., например, работу Фарра и Нельсона.
Большая часть исследований была сосредоточена на построении формальных моделей оценки программного обеспечения. Ранние модели обычно основывались на регрессионном анализе или математически выведены из теорий из других доменов. С тех пор было оценено большое количество подходов к моделированию, таких как подходы, основанные на основанных на конкретных случаях рассуждениях, классификации и деревьях регрессии, моделировании, нейронных сетях, байесовской статистике, лексическом анализе спецификаций требований, генетическом программировании, линейном программировании, экономическом производстве модели, мягкие вычисления, моделирование нечеткой логики, статистический бутстрапинг и комбинации двух или более из этих моделей.
Пожалуй, наиболее распространенными методами оценки сегодня являются модели параметрической оценки COCOMO, SEER-SEM и SLIM. Они имеют свою основу в оценочных исследованиях, проведенных в 1970-х и 1980-х годах, и с тех пор обновляются с новыми калибровочными данными, последний последний выпуск которого является COCOMO II в 2000 году. Подходы к оценке основаны на функциональных размерах, основанных на функциональности, например, функции также основаны на исследованиях, проведенных в 1970-х и 1980-х годах, но были повторно откалиброваны с использованием мер изменения размера и различных подходов к подсчету, таких как точки использования или точки объекта в 1990-х годах и COSMIC в 2000-х годах.
Фактическая оценка времени - это временный метод оценки работы по разработке.
Крайне важно иметь возможность оценить время завершения проекта Agile, к сожалению, это также одна из самых сложных частей планирования Agile-проекта.
Его цель состоит в том, чтобы наилучшим образом приблизиться к количеству времени, необходимого для выполнения заданной задачи развития.
Один из методов, который вы можете использовать, - это оценить время, необходимое для завершения пользовательских историй. Когда вы это делаете, не забудьте проконсультироваться с другими членами вашей гибкой команды. Для каждой истории пользователей убедитесь, что вы оцениваете время, которое является реалистичным и выполнимым, но не настолько, чтобы клиент был переплачен за простую работу. Проконсультируйтесь с членами вашей команды, чтобы вы могли использовать свой опыт, чтобы понять, сколько требуется работы и сколько времени потребуется. Когда у вас есть консенсус для каждой истории пользователей, вы можете добавить время, чтобы придумать оценку времени.
Поскольку требования проекта меняются со временем, вы можете обновить оценку. Если проект теряет некоторые ресурсы, первоначально выделенные для него, вам может потребоваться сократить пользовательские истории, чтобы они могли завершить их за такое же количество общего времени. Аналогичным образом, если вы хотите улучшить качество приложения, вам может потребоваться выделить больше времени для каждой истории пользователей, чтобы убедиться, что ваша команда успевает закончить приложение с требуемым качеством.
Как правило, эти оценки рассчитываются с использованием идеальных инженерных часов.
Примеры:
Эта задача будет завершена через 10 дней.
Или же…
Эта задача будет завершена к 10 января.
Или же…
Для завершения этой задачи потребуется 25 часов разработки.