Анализ точечных функций - серьезно переоценка техники?

Question

уточнение щедрости

Я знаю, что это субъективный вопрос. Идеальный ответ, который я ищу, - это тот, который объясняет, почему приведенный здесь сценарий был бы таким удивительным.

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

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

---

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

1. Сначала некоторые данные

Этот вопрос основан на учебнике . У него был раздел «Подсчет образцов», где он демонстрировал его шаг за шагом. Вы можете увидеть скриншотов его примера приложения здесь .

В итоге он вычислил ненастроенную FP как 99.

Есть еще одна статья об InformIT с отраслевыми данными по типичным часам / FP. Диапазон составляет от 2 часов / FP до 27,4 часа / FP. Давайте попробуем придерживаться 2 на данный момент (так как читатели SO, вероятно, являются более эффективной толпой: p).

2. Проверка реальности!?

Теперь просто посмотрите скриншоты снова.

Сделай немного математики здесь

99 * 2 = 198 hours
198 hours / 40 hours per week = 5 weeks

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

Теперь давайте попробуем оценить стоимость проекта. Сейчас мы будем использовать минимальную заработную плату в Нью-Йорке ( Википедия ), которая составляет 7,25

.

198 * 7.25 = $1435.5

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

(Кстати, на этом же сайте есть еще одна статья, в которой обсуждается производительность. Кажется, что они обычно используют 4.2 часа / FP, что дает нам еще более шокирующую статистику:

99 * 4.2 = 415 hours = 10 weeks = almost 3 whopping months!
415 hours * $7.25 = $3000 zomg

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

3. Я что-то здесь упускаю?

Прямо сейчас я мог бы предложить несколько возможных объяснений:

1. FPA действительно подходит только для больших проектов (более 1000 FP), поэтому он становится очень неточным в меньших масштабах.
2. Метрика часов / FP колеблется резко от команды к команде, от проекта к проекту. Для такого маленького проекта, как этот, мы могли бы использовать что-то вроде 0,5 часа / FP или что-то в этом роде. (Теперь этот вид делает оценку бессмысленной, если только моя фирма не занимается одним и тем же типом проектов в течение нескольких лет с одной и той же командой, не очень часто).

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

Что бы ответили эксперты ФП на это?

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

Лично я обнаружил, что 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 доллара. 1015 *

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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