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

How do you estimate costs in your software?

Я видел такие вещи, как:

Стоимость = (HoursOfWork + EstimatedIddle) * HourlyRate

Это не то, что я хочу, я ищу правильно (с научной точки зрения) определенную модель стоимости

РЕДАКТИРОВАТЬ Я нашел несколько связанных вопросов по SO:

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

В случае, если вы застряли в режиме «Водопад», единственный достаточно точный метод, который я использовал, это:

1. Создать структуру декомпозиции работ
2. Убедитесь, что он достаточно подробный, чтобы вы могли связать масштаб каждой задачи с тем, что вы (или кто-то, с кем вы можете поговорить) делали раньше.
3. Для каждой задачи подберите числа для наилучшего, вероятного и наихудшего случаев, основанные на опыте. В лучшем случае, если все прошло идеально, в худшем случае, если вам пришлось сделать это заново (возможно, дважды), и, вероятно, где-то там.
4. Используйте некоторую весовую формулу, например (1 * лучший + 4 * вероятный + 1 * худший) / 6, чтобы получить оценку для каждой задачи, которая учитывает диапазон.
5. Я также видел варианты, в которых вы можете добавить компонент «риск» для каждой задачи. Три уровня риска: 0, 1 и 2. Риск 0 означает, что вы сделали это раньше (или что-то очень близкое), 1 означает, что вы не делали этого раньше, но это регулярно делается в вашей отрасли, 2 означает, что это, вероятно, никогда не было сделано раньше в отрасли. Вы берете число риска и умножаете его на приближение «стандартного отклонения» вашей оценки. Добавьте это к вашей взвешенной оценке. Таким образом, риск 0 не сдвигает его, но риск 2 перемещает его довольно близко к вашему наихудшему числу.
6. Сложите все задачи.
7. Добавьте непредвиденные расходы (несколько%) для «неизвестных неизвестных».

Вы получите очень точное число. Я не говорю, что это точно, но это будет точно.

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

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

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

За 30 лет, прошедших с 81 года, индустрия многому научилась. Оценка как это никогда не работала. Благодаря повальному увлечению Agile, в основном переписавшему пейзаж, мы используем «исторические точки», представляющие некоторую смутную «сравнительную трудность». Затем мы набираем «скорость», чтобы грязные гадости могли делать свои оценки $$ с некоторым количеством эмпирических данных.

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

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

Я прекратил его использовать, потому что моя организация слишком неблагополучна, чтобы получать выгоду от оценок программного обеспечения, но я немного отношусь к группе Cost Xpert и ее инструменту; но это очень дорого и, вероятно, не стоит затрат и кривой обучения для подавляющего большинства организаций.

Очень сложно оценить усилия и затраты, но если вы хотите что-то более точное, то:

• разделите HoursOfWork на 3 компонента:

  1. лучшая оценка,
  2. наиболее вероятная оценка,
  3. худшая оценка.

• удалить EstimatedIddle.

Обратите внимание, что все, что занимает более 8 часов, приведет к огромной ошибке.

Обычно мы делим полный объем работ на основные модули / элементы, которые можно рассматривать как подпроект. Другими словами, это те рабочие части, которые клиент рассматривает как отдельные части проекта, и которые клиент хочет оценить отдельно.

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

Последний шаг - распределение задач между этапами. Мы делаем это так, чтобы после каждого этапа клиент получал видимые результаты. Это помогает пройти один этап и перейти к другому. Итак, наконец мы получаем что-то вроде:

Модуль 1

    <ol>
        <li>
            Primary task 1 - 5 hrs
            <ol>
                <li>Subtask 1.1 – 3 hrs</li>
                <li>Subtask 1.2 – 2 hrs</li>
            </ol>
        </li>
        <li>
            Primary task 2 - 9 hrs
            <ol>
                <li>Subtask 2.1 – 1 hrs</li>
                <li>Subtask 2.2 – 2 hrs</li>
                 <li>Subtask 2.2 – 5 hrs</li>
            </ol>

Изначально мы делали это, используя лист Excel. Но более двух лет назад мы начали использовать программный инструмент для этого. Есть несколько подобных продуктов, которые помогают с этим www.evenflow.com , www.swproposal.com и несколько других. Я не помню весь список. Мы провели исследование давно. Надеюсь, что это может помочь.

Хороший вопрос, как точно оценить. Там нет 100% правильной оценки, как мы полагаем. Единственный способ - разделить весь объем работ на как можно более мелкие задачи. Чем меньше у вас задач, тем более детальный обзор и анализ проекта вы делаете. Так что в любом случае точность увеличивается.