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

How do you estimate costs in your software?

Я бачив такі речі:

Вартість = (HoursOfWork + EstimatedIddle) * Почасовий рейтинг

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

EDIT Я знайшов кілька пов'язаних питань щодо 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.swproposed.com та декілька інших. Я не пам’ятаю всього списку. Ми робили дослідження давно. Сподіваюся, що це може допомогти.

Добре питання - як точно оцінити. Як ми вважаємо, немає 100% правильної оцінки. Єдиний спосіб - розділити повний обсяг роботи на якомога менше завдань. Чим менше завдань у вас є більш детальний огляд та аналіз проекту, який ви виконуєте. Так що все одно збільшується точність.