Анализ точечных функций - серьезно переоценка техники?
Разъяснение щедрости
Я знаю, что это субъективный вопрос. Идеальный ответ, который я ищу, это тот, который объясняет, почему приведенный здесь сценарий был бы таким удивительным.
Если вы считаете, что приведенный сценарий на самом деле неудивителен и ожидаем, пожалуйста, разбейте шаги, чтобы доказать, как такое маленькое приложение может занять месяц разработки и несколько тысяч долларов. Я пошел довольно далеко, чтобы сделать расчеты (например, поиск минимальной заработной платы), поэтому я ожидаю, что идеальный ответ сделает то же самое.
Если вы считаете, что приведенный сценарий действительно переоценен, пожалуйста, точно укажите ваши причины. Какие ошибки вы можете заметить в его вычислениях, которые привели к таким огромным затратам для такого простого приложения? Как бы вы сделали это по-другому? (не нужно писать весь процесс, но детали вместо обобщенных чувств были бы хорошими)
Я знаю, что вопросы о 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. Я что-то здесь упускаю?
Прямо сейчас я мог бы предложить несколько возможных объяснений:
- FPA действительно подходит только для больших проектов (более 1000 FP), поэтому он становится очень неточным в меньших масштабах.
- Метрика часов / FP резко колеблется от команды к команде, от проекта к проекту. Для такого маленького проекта, как этот, мы могли бы использовать что-то вроде 0,5 часа / FP или что-то в этом роде. (Теперь этот вид делает всю оценку бессмысленной, если только моя фирма не занимается однотипными проектами в течение нескольких лет с одной и той же командой, не очень часто).
Исходя из моего опыта работы с несколькими метриками программного обеспечения, Function Point на самом деле не является легкой метрикой. Если час / FP сильно колеблются, то какой смысл, возможно, я мог бы пойти с User Story Points, который получить гораздо быстрее и, возможно, почти так же неопределенно.
Что бы ответили эксперты ФП на это?
11 ответов
Около десяти лет назад мой собутыльник подарил мне действительно великую мудрость. На любой консультации по проекту задайте три вопроса: 1. Какую проблему мы пытаемся решить? 2. Каковы результаты? 3. Как мы узнаем, когда закончим? Он добавил, что никогда не следует брать на себя какой-либо проект, для которого ни один из вопросов не был дан ответ до начала проекта.
В данном случае у нас есть еще одна ужасная история с методом оценки программного обеспечения, в которой оценка кажется невероятно высокой. Я бы ответил на его ужасную историю, указав, что он не дал ответов на второй и третий вопросы, и на самом деле он не ответил на первый, кроме как сказать: "Мы хотим создать что-то, что работает примерно так".
Я хотел бы остановиться на этом, указав, что он явно даже не спросил, какие задачи включает в себя оценка функциональных баллов или исключает их из оценочной суммы. Сколько дополнительных усилий, например, дает оценщик функциональных точек для документации? Если его оценка относится к приложению без какой-либо документации, а оценка оценщика функциональной точки была для приложения с полной документацией, я бы сказал, что есть некоторое место для разногласий по поводу общего объема работы (и времени), необходимого.
Неужели у меня такое чувство, что порядочному программисту не понадобится больше недели (я даже не говорю о выходных), чтобы завершить его?
Разработчики всегда склонны недооценивать, сколько времени нужно, чтобы что-то закончить. Они думают, что не будет никаких ошибок, никаких изменений в требованиях и ничего, что они никогда не делали раньше, и им придется потратить дни на выяснение ситуации.
Судя по скриншотам, это небольшое приложение для улучшения Excel. Я мог бы купить MS Office Pro за 200 долларов, что дает мне большую совместимость (файлы.xls) и гибкость (электронные таблицы).
Вы сравниваете цену за совершенно нестандартную часть программного обеспечения с той, которая продается миллионами копий? Шутки в сторону?
Реальность такова, что большинство методов оценки программного обеспечения фактически недооценивают, хотя на первый взгляд кажется нелогичным. Однажды я работал в компании, в которой 300 строк кода на человека в месяц считались ВЫСОКОЙ оценкой, и в большинстве случаев мы получали более 200-250. Но давайте перейдем к 200. Это 10 строк кода на рабочий день. Кто не может написать 10 строк кода в рабочий день? Давай! Я мог бы написать от 50 до 100 или более строк кода в хороший день! И все же компании, использующие такие цифры, неоднократно завершают свои проекты с опережением графика и сверх бюджета. Это почему? Ну, масштабная крипта, как предполагает Майкл Боргвардт, большая. Но давайте на минуту вытащим это изображение и предположим, что клиент и клиент сделали это правильно с первого раза. Почему компания оценивает только 10 строк кода в день?
- Анализ требований
- Разработка программного обеспечения на основе требований
- Встречи для координации интерфейсов и архитектуры с товарищами по команде.
- Накладные расходы (статусные встречи с руководством, больничные, отпуска, ...)
- Написание юнит-тестов
- Написание плана тестирования для всего приложения
- Тестирование на уровне приложений
Вот и вся повседневная разработка программного обеспечения, которую я могу выполнить за 3 минуты, уверен, я пропустил еще немного, но помогает ли это получить более полное представление о том, откуда берутся эти оценки?
Лично я нашел 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 цента вам пригодятся.
Не эксперт по ФП. Однако сейчас мы смотрим на FP. В частности, мы проводим анализ FP по старым проектам, у нас есть метрики для усилий / затрат и т. Д. Затем мы можем оценить его полезность для нас при оценке / оценке проектов.
На данный момент я считаю, что это будет полезная оценка "порядка" сверху вниз, чтобы дополнить оценку снизу вверх. Всегда хорошо, если можно применить более одной методики оценки, чтобы подтвердить, что получаемые числа "удерживаются".
Еще одна мысль - стоимость / усилие на функциональную точку (то есть функциональное требование) будет зависеть от нефункциональных требований, которые требуются для системы. Как только вы начнете принимать во внимание безопасность, доступность, производительность, ведение журналов (и оповещений), ремонтопригодность, переносимость, соответствие нормативным требованиям и т. Д., Затраты / усилия на ПП значительно возрастают. Теперь они могут не учитываться для приведенного примера приложения для одного пользователя. Но если это приложение важно для компании или, возможно, для ее клиентов или для широкой части широкой общественности, необходимость учитывать эти нефункциональные требования, безусловно, возрастет.
В моей предыдущей компании мы бы рассчитали так - особенно если кто-то хочет заплатить за это;)
Платежи, основанные на времени, косвенно снижают производительность. Я помню проекты с оплатой по времени, когда я проводил много исследований для каждого аспекта проекта, в то время как если бы у него был метод оплаты по проекту, возможно, я этого не делал. Это бессознательный разум, а не этика. Наилучшей практикой является обращение к определению "Проект" (в течение ограниченного времени и бюджета) и принятие решения на основе ограничений. Речь идет не о самой работе, то есть вы платите за зонтик в дождливый день гораздо больше, чем когда вы покупаете обычно. Не беспокойтесь о том, что сделано и сколько это стоит. Сосредоточьтесь на ценности работы для клиента и его выбора.
Я практиковал FP в нескольких проектах и обнаружил, что он дает довольно точную оценку. Иногда это можно переоценить, а иногда недооценивать в зависимости от типа приложения. Обычно для научных применений FP может быть недооценен. FP обеспечивает все время разработки проекта, а не только время написания кода. Конечно, нет никаких действий по разработке, таких как настройка тестовой среды и т. Д., И они должны оцениваться отдельно. Я не большой сторонник FP, но ценю его использование. Если неточная оценка, если ее правильно применять (с указанием файлов и элементов записи), она как минимум проверяет полноту ваших требований.
В некотором смысле, мы должны сказать, что FP подходит для средних и крупных проектов, с масштабированием более 350-400 FP.
Исходя из моего опыта работы с несколькими метриками программного обеспечения, Function Point на самом деле не является легкой метрикой. Если час /FP сильно колеблются, то какой смысл, возможно, я мог бы пойти с User Story Points, который получить гораздо быстрее и, возможно, почти так же неопределенно.
Смысл анализа функциональных точек состоит в том, чтобы иметь какие-то правила / руководящие принципы, которые являются объективными и стандартными, чтобы в конечном итоге он (в пределах определенного предела) давал одинаковое количество функциональных баллов по приложению и / или проекту, независимо от какой эксперт это посчитал, если правила применяются последовательно и правильно. Как вы обнаружили, производительность в расчете на одну функциональную точку во многом зависит от многих факторов, таких как опыт команды, инструменты, язык программирования, платформа и т. Д. И т. Д. Поэтому отраслевые стандарты приятно знать, но в большинстве случаев совершенно бесполезны (по моему скромному мнению).). Основная ценность повторного подсчета - это создание собственного "эталона", основанного на истории вашей собственной продуктивности команды. Это, в свою очередь, поможет вам увидеть тенденции, а также поможет спланировать и предсказать часы, необходимые для будущих изменений. Если вы ищете скорость, просто примените глобальные подсчеты вместо подробных подсчетов. При выполнении нескольких примеров (например, при подготовке к экзаменам) вы заметите, что разница между подробным и глобальным счетами недостаточно велика, чтобы потерять сон (на%).
Это обсуждение абсолютно вводит в заблуждение, поскольку вопрос уже предполагает, что FPA - это метод оценки усилий. Это не так.
Функциональный размер (выраженный в функциональных точках) может быть одним из многих входных факторов для модели оценки (такой как COCOMO). Не больше, но и не меньше, если мы согласны с тем, что "количество" функциональных требований является драйвером усилий для программных проектов.
Подставляя значения из примера, который вы цитировали, в этот удобный онлайн-калькулятор функций ( http://developergeeks.com/functionpoint.aspx), который вычисляет скорректированные FP и учитывает различные другие весовые коэффициенты, я получаю следующие результаты, предполагая, что производительность 2 FP в час, так как система в примере очень проста:
- Скорректированные FP: 42,9
- Предполагаемое количество человеко-месяцев: 0,54
Предполагая 160 часов в рабочем месяце, это составляет примерно 86,4 часа, или примерно две рабочих недели для одного разработчика. Не пять недель, как вы пришли к выводу на шаге 2. Учитывая, что разработка систем для платных клиентов требует лишь немного больше внимания и усилий, чем просто постучать какой-нибудь код поздно ночью для собственного удовольствия, я не думаю, что это необоснованная оценка все.
Я имею в виду, не поймите меня неправильно, анализ FP в чужих руках, вероятно, ужасная идея. Но если у вас есть опыт работы с разработчиком, вы можете обратиться к подсчету FP и интуиции, проверяя различные весовые коэффициенты, это не плохой способ получить разумную оценку, которая не основана на чистой фантазии, когда у вас нет подробных спецификаций дизайна Полностью документированные требования или подробный план проекта на уровне задач. Но вы должны использовать здравый смысл, чтобы заставить его работать на вас.