Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

оценка трудозатрат

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

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

оценка трудозатрат

  1. 1. Оценка трудозатрат при разработке ПО
  2. 2. Оценка трудозатрат Рассмотрим методы прогнозирования трудозатрат, которые: Позволяют оценивать трудозатраты на ранних этапах, в условиях неопределенности. Позволяют учесть влияние рисков в сроках прогнозов. Снижают влияние тенденции экспертов к систематической недооценке сложности задач. Дают механизмы проверки достоверности сроков, основанные на метриках. При этом, практичны и просты в применении.
  3. 3. Оценка вариации сроков Как учесть неопределенность в прогнозе
  4. 4. Оценка вариации срока Оценки сроков неточны: Эксперты часто имеют тенденцию к систематической недооценке сложности; Присутствие рисков не позволяет дать точных оценок; Имея единственную оценку нельзя понять, на что заложился эксперт, когда ее давал. Выход – давать оценки оптимистичного и пессимистичного сценариев. Critical Chain Project Management PERT
  5. 5. Метод PERT Estimation Обрабатывает три экспертных оценки срока. L - «раньше не справлюсь точно, даже если повезет»; H - «успею гарантированно, даже если все риски сыграют»; M – «наиболее вероятно успею» Формулы PERT: PERT Estimation (μ) =( L + 4M + H ) / 6 PERT Deviation (σ) = ( H – L ) / 6 Задача уложится в срок μ+σ с вероятностью 72 %.
  6. 6. Основа PERT Estimation Длительность задачи - случайная величина, имеющая бета- распределение. PERT Estimation и Deviation – матожидание и среднеквадратичное отклонение Между крайними оценками – 6 сигм
  7. 7. Свойства задач с независимыми прогнозами Для суммы независимых случайных величин верно: σ = √(σ12 + σ22 + … + σn2) Сигма суммы независимых случайных величин в процентах уменьшается при увеличении их количества: n 0 Таким образом, чем больше в плане «независимых» задач, тем точнее суммарная оценка сроков. Погрешности планирования разных задач компенсируют друг друга.
  8. 8. Зависимость сигмы от количества задач Показана зависимость общей сигмы плана в процентах от количества независимых задач. Задачи имеют равные длительности и сигму 100%. 35% 30% 25% 20% σ/μ 15% 10% 5% 0% 0 50 100 150 200 250 300 350 400 450 500
  9. 9. Какие задачи независимы? Независимых задач в разработке много: Все задачи разработки, которые могут выполняться независимо друг от друга и впараллель; Все задачи, относящиеся к непересекающемуся функционалу; Большинство заданий, возникающих при поддержке ПО (исправление дефектов, реализация feature requests, и прочее). Прогнозы задач зависимы, если их реальные длительности зависят от одних и тех же факторов Зависимые задачи обычно связанны связью «окончание-начало». Например, фазы разработки зависимы по прогнозу между собой.
  10. 10. Оценки для группы задач Для суммы случайных величин верно: μ = μ1 + μ2 + ... + μn; Ожидаемое время выполнения задач просто суммируется. Сигма для группы задач: Суммируется для зависимых прогнозов; Может быть оценена как корень из суммы квадратов для независимых прогнозов. Распределение суммы случайных величин меняется, приближаясь к нормальному, при увеличении их количества. PERT: сумма задач уже не имеет бета- распределения.
  11. 11. Нормальное распределение «Не справлюсь точно» (вероятность <2%) = μ - 2σ «Успею с запасом» (вероятность 98%) = μ + 2σ Между крайними оценками 4 сигмы
  12. 12. PERT Estimation PERT Deviation лишен внятного смысла для суммы задач. «Задача уложится в μ+σ с вероятностью 72 %» - для суммы задач уже не верно. Сколько сигм надо добавить к прогнозу сроков всего проекта, чтобы успеть с вероятностью 85% («скорее всего»)? PERT Estimation не лучше простой пары оценок «оптимистичная – пессимистичная» Центральная оценка с весом 4 забивает крайние, и доминирует в прогнозе. В результате, PERT на практике не позволяет работать с большой неопределенностью в прогнозе.
  13. 13. Модифицируем формулу PERT В предположении, что срок выполнения задачи имеет нормальное распределение: «Не справлюсь точно» (вероятность <2%) = μ - 2σ «Успею с запасом» (вероятность 98%) = μ + 2σ «Normal Estimation»: μ =( L + H ) / 2 σ=(H–L)/4 Распределение сохраняется при суммировании. Проект уложится в срок μ+σ c вероятностью ≈85%.
  14. 14. Применение метрик в планировании Практический подход
  15. 15. Основные метрики Базовые метрики Время работы (дни, часы) Объем работы Строки кода (SLOC) Функциональные точки Количество классов, функций, и т. д. Количество ошибок Производные метрики Продуктивность = Объем / Время Плотность ошибок = Количество / Объем
  16. 16. Свойства метрик Базовые метрики дают корелляции Объем vs Время Объем vs количество ошибок Производные метрики устойчивы и колеблются в границах коридора. Фактические значения метрик с завершенных проектов могут быть измерены и использованы при планировании. PSP/TSP – пример методологии разработки построенной на применении метрик.
  17. 17. Корелляция SLOC и времени работ quot;Estimating With Objectsquot;, Watts S. Humphrey, Carnegie-Mellon SEI
  18. 18. Метрика SLOC Дает лучшие корелляции с временем и количеством ошибок. Учитываются только те строки, в которых можно допустить ошибки. Не учитываются комментарии, пустые строки, и автоматически генерируемый код. Можно не учитывать операторные скобоки (begin- end, { }, прочее). Может быть посчитана автоматически. Может быть использована как промежуточная метрика (proxy-based estimation), рассчитанная из других метрик объема (классы, функции, функциональные точки, и т.д.)
  19. 19. Время разработки Время должно включать в себя все основные активности разработки, на которых вносятся ошибки: проектирование; кодирование; отладка; а, также, возможно, работу с требованиями. Корелляции с объемом проявляются: На законченных проектах; На задачах, которые могут быть раздельно протестированы.
  20. 20. Метрика «продуктивности» Осмысленна при наличии корелляции время-объем. Более стабильна на больших отрезках времени, в том числе и для группы программистов. Колеблется в некотором коридоре, зависящем от: языка программирования; характера и сложности задачи; стиля программиста – разные люди решают одинаковые задачи с разным размером кода; качества результата – чем меньше в нем ошибок, тем меньше «продуктивность». Нельзя применять как показатель эффективности работы. Программист, тратящий меньше времени на проектирование, и пишущий больше кода для той же задачи – покажет высокую «продуктивность».
  21. 21. Применение в планировании Получение сроков от оценки объема: Выполнить прогноз объема в удобной метрике (например – количество модулей или классов) Перейти к SLOC (proxy-based estimation). Пользуясь корелляцией SLOC/time, выполнить прогноз времени. Недостатки Сложно учесть в прогнозе риски. Сложно учесть тенденцию экспертов к недооценке сложности. Требуется аккуратно подойти к выбору базы для снятия метрик. Альтернатива: Выполнить раздельный прогноз сроков и объема Использовать «продуктивность» как проверочный коэффициент
  22. 22. Правила проверки Метрика «продуктивности» должна находится в коридоре исторических колебаний по аналогичным завершенным проектам. Вылет за коридор чаще всего означает грубую ошибку в прогнозе срока или объема. «Продуктивность» должна отражать представление о сложности задачи. Сложная задача не может иметь «продуктивность» у верхней границы коридора, и наоборот. Для двух задач, одна из которых сложнее другой – «продуктивность» более сложной должна быть меньше. Невыполнение правила указывает на ошибку в оценках как минимум одной из задач.
  23. 23. Спасибо за внимание! Владислав Балин, НТЦ «Модуль» gaperton@gmail.com gaperton.livejournal.com

    Be the first to comment

    Login to see the comments

  • jvetrau

    May. 25, 2009
  • toivo

    May. 30, 2009
  • nickolajscerbina

    Feb. 23, 2011
  • AlexeySuchkov

    Jun. 1, 2011
  • alexander.nemtsov

    Nov. 5, 2012
  • IIporpammep

    Jun. 6, 2015
  • kkazakov

    Oct. 19, 2015
  • micierJaraevi

    Mar. 21, 2018
  • DmytroL

    Jul. 8, 2019

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

Views

Total views

5,820

On Slideshare

0

From embeds

0

Number of embeds

32

Actions

Downloads

152

Shares

0

Comments

0

Likes

9

×