В моей предыдущей компании мы рассчитывали бы так - особенно если кто-то хочет, чтобы заплатил за это;)

Я просто чувствую, что этого не произойдет {{1 }} у любого приличного программиста требуется больше времени, чем одна неделя (я даже не говорю о выходных) , чтобы завершить его?

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

Судя по тому, что я видел из снимков экрана, это приложение - это небольшое приложение для улучшения Excel. Я мог бы купить MS Office Pro за 200 долларов, что дает мне большую совместимость (файлы .xls) и { {1}} гибкость (электронные таблицы).

Вы сравниваете цену на программное обеспечение, полностью разработанное по индивидуальному заказу, с тем, которое продается миллионными копиями? Серьезно?

Реальность такова, что большинство методов оценки программного обеспечения на самом деле недооценивают, хотя на первый взгляд это кажется нелогичным. Когда-то я работал в компании, где 300 строк кода на человеко-месяц считалось ВЫСОКОЙ оценкой, а в большинстве месяцев мы выходили на 200-250. Но давайте остановимся на 200. Это 10 строк кода в рабочий день. Кто не может написать 10 строк кода за рабочий день? Да ладно! Я могу написать от 50 до 100 и более строк кода в хороший день! И все же компании, использующие такие цифры, постоянно завершают свои проекты с отставанием от графика и превышением бюджета. Почему так происходит? Ну, как говорит Майкл Боргвардт, одной из основных причин является "ползучесть". Но давайте на минуту отвлечемся от этого и предположим, что заказчик и клиент все сделали правильно с первого раза. Почему компания оценивает только 10 строк кода в день?

• Анализ требований
• Проектирование программного обеспечения на основе требований
• Встречи для согласования интерфейсов и архитектуры с членами команды.
• Накладные расходы (статусные встречи с руководством, больничные, отпуска, ...)
• Написание модульных тестов
• Написание плана тестирования для всего приложения
• Тестирование на уровне приложения

Это вся повседневная программная инженерия, которую я могу вспомнить за 3 минуты, я уверен, что пропустил еще что-то, но помогает ли это получить более полную картину того, откуда берутся эти оценки?

Не эксперт по FP. Однако сейчас мы смотрим на FP. В частности, мы выполняем анализ FP для старых проектов, у нас есть показатели усилий / затрат и т. Д. Затем мы можем оценить его полезность для нас в проектах оценки / определения размера.

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

Еще одна мысль - затраты / усилия на функциональную точку (то есть функциональное требование) будут зависеть от нефункциональных требований, которые требуются для системы. Как только вы начнете учитывать безопасность, доступность, производительность, ведение журнала (и оповещения), ремонтопригодность, переносимость, соответствие нормативным требованиям и т. Д., Затраты / усилия на FP значительно возрастут. Теперь это может не рассматриваться для цитируемого однопользовательского примера приложения. Но если это приложение важно для компании или потенциально их клиентов или широкой части населения, необходимость учитывать эти нефункциональные требования, безусловно, возрастет.

Я практиковал FP в нескольких проектах и обнаружил, что он дает довольно точную оценку. Иногда он может переоценить, а иногда недооценить, в зависимости от типа приложения. Как правило, для научных приложений FP может быть недооценен. FP учитывает все время разработки проекта, а не только время написания кода. Конечно, не существует мероприятий по разработке, таких как создание тестовой среды и т.д., и они должны оцениваться отдельно. Я не большой сторонник FP, но ценю его использование. Если это не точная оценка, то при правильной практике (идентификация файлов и элементов записи) она, по крайней мере, подтверждает полноту ваших требований.

В некотором смысле, мы должны сказать, что FP хорош для средних и больших проектов, масштабируемых более 350-400 FP.

Лично я обнаружил, что FPA вводит в заблуждение ... изначально.

Если у вас нет исторических данных FPA по предыдущим проектам, FPA определенно может в конечном итоге переоценить все, используя отраслевые стандарты.

Я узнал, что VAF - хороший указатель для использования при работе с FPA. Хотя это дает вам 35% -ный диапазон вариации вашего подсчета FP, кто мешает аналитику / руководителю проекта превратить это в 50-процентный вариант.

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

Я бы сказал, что если вы используете лучший сценарий -35% для нескорректированного подсчета, вы достигнете скорректированного количества FP ~ 64. Дает вам примерно 3 с половиной недели оценки. Исходя из опыта, я бы сказал, что приложение такого типа МОЖЕТ быть выполнено намного раньше, но любое тщательное тестирование, отладка, документация и другие документы могут растянуть его еще больше, и FP это учитывает. Вполне возможно, что ваша команда делает 1 FP в час. По нормальным стандартам на кодирование и тестирование приходится 25% от общего числа FP, поэтому в этом случае, даже если взять вашу цифру в 99 FP, часть кодирования и тестирования упадет до 25 FP, что более понятно с учетом ситуации.

На практике я также видел, что некоторые компании разработали свои собственные таблицы сложности, поэтому, если 3 RET и 10 DET означают среднюю сложность для одной компании, другая оценила бы ее как низкую сложность. Это в значительной степени повлияет на окончательный подсчет FP.

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

В качестве примечания: я думаю, что оценка затрат на такое простое программное обеспечение, как это, сегодня показалось бы нелепым, когда аутсорсинг и фриланс - это лучший способ.Крупные компании, которые занимались этим бизнесом, по-прежнему берут за разработку программного обеспечения смехотворно высокую плату. Например, если вы хотите, чтобы инженер поддержки 3-го уровня помогал вам с вашими серверами в хорошей хостинговой компании, он будет взимать 250 долларов в час, однако вы можете получить тот же совет от кого-то, находящегося в другом месте в мире, за 25 или даже 2,5 доллара.

Надеюсь, мои 2 цента вам пригодятся.

Повременные платежи косвенно приводят к снижению производительности. Я помню проекты с повременной оплатой, в которых я много исследовал каждый аспект проекта, в то время как, если бы у него был метод оплаты, основанный на проекте, возможно, я этого не делал. Это подсознание, а не этика. Лучшая практика - ссылаться на определение «Проект» (в рамках ограниченного времени и бюджета) и принимать решение на основе ограничений. Дело не в самой работе, т. Е. В дождливый день вы платите за зонт намного больше, чем при обычной покупке. Не беспокойтесь о том, что было сделано и сколько это стоит. Сосредоточьтесь на ценности работы для клиента и его выбора.