Ответ 1

Примерно десять лет назад мой приятель-приятель дал мне действительно большую мудрость. В любой консультации по проекту задайте три вопроса: 1. В чем проблема, которую мы пытаемся решить? 2. Каковы результаты? 3. Как мы узнаем, когда мы закончим? Он добавил, что никогда не следует использовать какой-либо проект, для которого не было ответа на любой из вопросов до начала проекта.

В данном случае у нас есть еще одна история ужасов метода оценки программного обеспечения, в которой оценка кажется смехотворной. Я бы ответил на его ужасную историю, указав, что он не дал ответов на второй и третий вопросы, и он на самом деле не ответил на первый, кроме как сказать: "Мы хотим построить что-то, что работает примерно так".

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

Лично я обнаружил, что 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 цента будут вам полезны.

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

Подключите значения из примера, который вы указали в этом удобном онлайн-калькуляторе точки функции (http://developergeeks.com/functionpoint.aspx), который вычисляет скорректированные FP и принимает учитывая различные другие весовые коэффициенты, я получаю следующие результаты, предполагая производительность 2 FPs в час, так как система в примере настолько проста:

• Скорректированные FP: 42.9
• Предполагаемый месяц: 0.54

Предполагая 160 часов в течение рабочего месяца, это составляет около 86,4 часа или примерно две недели работы для одного разработчика. Не пять недель, как вы это сделали на шаге 2. Учитывая, что развивающиеся системы для оплаты клиентов требуют немного больше внимания и усилий, чем просто выпустить какой-то код поздно вечером для собственного развлечения, я не думаю, что необоснованная оценка на все.

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

Ответ 10

Из моего опыта работы с несколькими показателями программного обеспечения Function Point действительно не легкий показатель. Если значение часа /FP колеблется так много, то какой смысл, может быть, я мог бы пойти с User Story Очки, которые намного быстрее получить и, возможно, почти такие же неопределенные.

Точка, в которой есть функция Point Point Analysis, имеет какие-то правила/рекомендации, которые являются объективными и стандартными, чтобы в конечном итоге она (в определенной степени) давала вам одинаковое количество функциональных точек в приложении и/или проекте, независимо от того, какой эксперт подсчитал его, если правила применяются последовательно и правильно. Производительность на каждую функциональную точку, как вы обнаружили, очень зависит от многих факторов, таких как командный опыт, инструменты, язык программирования, платформа и т.д. Поэтому отраслевые стандарты приятно знать, но в большинстве случаев совершенно бесполезны (по моему скромному мнению). Основное значение в повторном подсчете - это создание собственного "benchnmark" на основе собственной истории производительности вашей команды. Это, в свою очередь, поможет вам увидеть тенденции, а также поможет планировать и прогнозировать часы, необходимые для будущих изменений. Если вы ищете скорость, просто применяйте глобальные подсчеты вместо подробных подсчетов. Когда вы делаете несколько примеров (например, при подготовке к экзаменам), вы заметите, что разница между подробным подсчетом и глобальным счетом недостаточно велика, чтобы потерять сон (на%).

Ответ 11

Это обсуждение абсолютно вводит в заблуждение, поскольку вопрос уже предполагает, что FPA - это метод оценки усилий. Это не.

Функциональный размер (выраженный в точках функций) может быть одним из многих факторов ввода для модели оценки (например, COCOMO). Не более, но не менее, если мы согласны с тем, что "количество" функциональных требований является драйвером усилий для программных проектов.