Существует ли методика расчета количества человекочасов для конкретного проекта ?
Подскажите пожалуйста ссылки на эту тему.

Здравствуйте, crazy25, Вы писали:

C>Существует ли методика расчета количества человекочасов для конкретного проекта ?
C>Подскажите пожалуйста ссылки на эту тему.

Можно посмотреть на этой ссылке:
http://sunset.usc.edu/research/COCOMOII/

Небольшая выдержка из описания этой методики:
"COCOMO II is a model that allows one to estimate the cost, effort, and schedule when planning a new software development activity."

Здравствуйте, crazy25, Вы писали:

C>Существует ли методика расчета количества человекочасов для конкретного проекта ?
C>Подскажите пожалуйста ссылки на эту тему.

Самый простой и действенный метод: прикинуть, за сколько это можно сделать, и умножить на 3
Кстати, серьезно.

Здравствуйте, crazy25, Вы писали:
C>Существует ли методика расчета количества человекочасов для конкретного проекта ?
Это похоже на

- Существуют ли способы управления женщинами?
— Да. Но оба не работают.

Так что практически оценка efforts для проекта — скорее исскусство, нежели технология.
Мы у себя обычно делаем следующее:
1. Готовим спецификации требований
2. Готовим набросок архитектуры, которая этим требованиям удовлетворяет
3. Готовим список задач, которые нужно выполнить в рамках этой архитектуры
4. Делаем оценку девелопмента на каждую задачу. Поскольку точных методик нет, это делает более-менее опытный архитектор на основании своего опыта.
5. Прибавляем расходы на QA, которые складываются из
— подготовки к тестированию (оценка исходит из количества test cases, которые предполагается подготовить. А оно зависит как от объема функциональных требований (п.1), так и от желаемого уровня качества.) Количество test case умножается на стоимость подготовки одного.
— собственно тестирования и отладки. Это, как правило, некий процент от п.4. (определяется для конкретной команды на основании метрик, снятых с предыдущих проектов. Если таких данных нет, то можно начать процентов с 40%)
6. Планируются ресурсы в соответствии с п.3:
6.1. На 3ем этапе у нас уже есть набор зависимостей по задачам. Длительность самой длинной цепочки определяет кратчайшую возможную длительность проекта. Отношение суммы человекочасов, полученных к этому моменту, к этой длительности, грубо определяет количество разработчиков, кои должны работать одновременно.
6.2. В соответствии с этой прикидкой, проджект менеджер накидывает девелоперов в проект, раздавая им в разных комбинациях задачи так, чтобы загрузить их более-менее равномерно. Ну и учесть всякие факторы типа того, что лучше сходную функциональность отдавать в одни руки — это облегчает комплектование команды.
6.3. Затем рассматривается список доступных ресурсов, и абстрактные личности типа "SQL Developer", "GUI Developer" превращаются в конкретных людей.
6.4. Оценки задач и графики работ корректируются с учетом индивидуальных особенностей этих организмов и их личных планов
6.5. Таким образом, получается примерный план проекта
7. Делается оценка стоимости менеджмента. Для того, чтобы ее произвести, полченная длительность проекта умножается на управленческую нагрузку. Она опять же сильно зависит от особенностей команды, и лучше использовать имеющийся опыт. Если его нет, можно прикинуть по армейскиим нормам — на команду из 8 человек потребуется один манагер с 50% загрузкой. Соответственно, для проекта длительностью в 2 человекомесяца с командой из 4х человек потребуется 80 часов менеджмента (40 рабочих дней по 25%, или 2 часа).

Результатом этого процесса является план проекта с предполагаемыми затратами, на основании которого можно оценку проекта. Если все участники делают все тщательно и не халтурят, прикидывая палец к носу, то точность оценок получается приемлемой.
На нее влияют следующие факторы:
1. Ошибки в оценке требований. Самая распространенная беда. Может привести к тому, что оценка будет занижена в 2-5 раз. Не беспокойтесь, завысить оценку аналогичным образом вам не дадут — избыточные требования будут мгновенно вычеркнуты заказчиком еще на 1м этапе.
2. Ошибки в выборе инструментов на шаге 2. Очень опасно закладывать неиспытанные технологии. Заверения маркетологов ничего не стоят. Первые впечатления — почти ничего не стоят. Стоит только опыт практического применения. Неожиданный грабль запросто может съесть в 10 раз больше времени на задачу, чем планировалось. Поэтому величина воздействия на затраты прямо зависит от того, какая из задач решается при помощи такого неизвестного средства.
3. Ошибки в планировании ресурсов. Они бывают двоякого рода: либо Вася, назначенный лид девелопером, забывает сказать о том, что он алкоголик/работает где-то еще/женится через неделю, либо мы неверно оценили производительность Васиного труда.
4. Неверная оценка усилий, которые потребуются для QA и, собственно, передаче результата труда заказчику.

Здравствуйте, crazy25, Вы писали:

C>Существует ли методика расчета количества человекочасов для конкретного проекта ?
C>Подскажите пожалуйста ссылки на эту тему.

В принипе существуют научные методы, например это рассчет объема кода через так низываемые Functional Points, а потом рассчет времени написания через CoCoMo. Описание данного метода есть, например, в книге "Технология Разработки программного обеспечения(Эрик Дж. Брауде)".
Однако подробные методы предполагают, что у тебя есть достаточно большой опыт рассчета(первый раз у тебя не получается и ты по результатам корректируешь методику рассчета на следующие разы), а так же много накопленной информации — типа сколько строк в день кто в команде пишет. Т.е. не факт что тебе это подойдет сразу.


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

Методика подсчета времени на пальцах:
Для того чтобы правильно подсчитать время нужно
1) разбить задачу на подзадачи
2) рекурсивно применить данную методику к каждой подзадаче
3) сложить результаты


Для начала пару понятных примеров:

Например, я тебя спрашиваю: вот у тебя есть форма, сколько времени займет на нее добавить кнопку? Как я понимаю такой вопрос обычно проблем не вызывает и все для своего языка способны дать ответ на месте.

Теперь я тебя спрашиваю: а сколько займет времени написать форму целиком, как правило большая часть людей тоже отвечают, но уже не так уверенно(или уверенно, но добавив в оценку час времени про запас ).

Вопрос номер 3: А сколько времени занимает написание приложения с 10 формами — ответить еще сложнее. С ходу на него обычно никто не отвечает, перед ответом считают время на форму * 10 + код-связка + дополнительный код.

Т.е. ты уже понял общую тенденцию: Чем больше задача тем сложнее дать оценку.

Поэтому основной метод оценки больших проектов это их декомпозиция. Т.е. ты разбиваешь задачу на подзадачи, и оцениваешь каждую из них. Если они все еще достаточно большие ты и их разбиваешь. Чем детальнее разобъешь тем точнее оценка. Но на каком то этапе стоит остановиться т.к. рискуешь на оценку времени потратить больше чем на реализацию.

При этом на оценку уходит достаточно много времени, для проекта в 1 месяц я трачу на оценку примерно день, у других людей соотношение может быть другим. Например для проектов которые разрабатывают по водопадной модели считается абсолютно нормальным, что на разработку Т.З. уходит 20% всего времени проекта. Т.е. если тебя просят дать оценку на проект не нужно делать умное лицо и говорить число с потолка, вполне нормально сказать "я дам тебе точную оценку завтра вечером, ждите".

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