Оцінка складності розробки ПЗ

Матеріал з testwiki
Перейти до навігації Перейти до пошуку

Оцінювання складності розробки ПЗ — процес передбачування найбільш ймовірного використання зусиль необхідних для розробки чи підтримки програмного забезпечення на основі неповних, неточних та зашумлених даних. Оцінка необхідних зусиль може використовуватись як вхідні дані планів проєкту, планів ітерації, бюджету, аналізу інвестицій, формування ціни, та раундів аукціону.

Практичні результати

Опубліковані опитування практики оцінювання стверджують що експертна оцінка є основною стратегією при оцінюванні зусиль необхідних для розробки ПЗ[1].

Зазвичай оцінки зусиль є надто оптимістичними і присутня надмірна впевненість в їх точності. Середнє перевищення оцінених зусиль дорівнює приблизно 30 % та не зменшується з часом. Для огляду опитувань про оцінку складності розробки, дивіться[2]. Щоправда, вимірювання помилки в оцінці не є проблемою, див Обчислення точності оцінки. Надмірна впевненість щодо точності оцінки зусиль ілюструється виявленням того факту що в середньому якщо інженер на 90 % або «майже впевнений» що необхідні зусилля увійдуть в інтервал мінімум-максимум, насправді частота попадання витрачених зусиль в інтервал оцінювання є лише 60-70 %[3].

Зараз термін «оцінка зусиль» використовується для позначення різних понять, таких як найбільш ймовірне використання зусиль (модальне значення), зусилля що відповідають 50 % ймовірності не перевищення (медіана) запланованих зусиль, зусиль що покриті бюджетом чи зусиль що використовуються для пропозиції ціни клієнту. Вважають що такі оцінки переважно неуспішні, через проблеми в комунікації що можуть виникнути та тому що ці поняття створені з різною метою[4][5].

Історія

Дослідники та практики звертали увагу на проблеми оцінки складності розробки для проєктів щонайменше з 1960-х, дивіться наприклад роботи Фарра[6] та Нельсона.[7]

Більшість досліджень фокусувались на створенні формальних моделей оцінки. Ранні моделі зазвичай базувались на регресійному аналізі чи математично запозичувались від теорій з інших предметних областей. Відтоді було опробувано багато підходів до моделювання, такі як Шаблон:Не перекладено, класифікація та регресійні дерева, симуляція, штучні нейронні мережі, Баєсівска статистика, лексичний аналіз специфікації вимог, генетичне програмування, лінійне програмування, нечітка логіка, статистичний бутстреп, та комбінація двох чи більше таких моделей. Можливо найбільш поширеними сьогодні методами оцінки є параметричні моделі оцінки COCOMO та SLIM. Обидві моделі беруть за основу дослідження проведені в 1970-х та 1980-х та відтоді відкалібровані новими даними. Останнім серйозним оновленням було COCOMO II в 2000-му році. Розробка обидвох моделей проводиться консультаційними фірмами.[8] Підходи до оцінки що базуються на вимірюванні розміру функціональності, наприклад функційні точки, також беруть за основу дослідження 70-х — 80-х, але були перекалібровані а також змінено підходи для вимірювання, як наприклад «точки історії користувача»[9] в 1990-х та COSMIC в 2000-х.

Підходи до оцінювання

Існує багато способів категоризації підходів до оцінювання складності.[10][11] Основними категоріями є наступні:

  • Експертна оцінка: Крок квантифікації, тобто крок на якому створюється оцінка, заснований на людських судженнях.
  • Формальна модель оцінки: Крок квантифікації базується на механічних процесах, наприклад використанні формули що походить від історичних даних.
  • Комбінована оцінка: Крок квантифікації проводиться за допомогою комбінації механічних та людських оцінок з різних джерел.

Нижче подано приклади підходів до оцінювання з кожної категорії.

Підхід до оцінювання Категорія Приклади втілення підходу до оцінювання
Оцінка на основі аналогії Формальна модель оцінки ANGEL, Weighted Micro Function Points
На основі WBS (оцінка знизу вверх) Експертна оцінка Системи управління проєктами, шаблони активності специфічні для компанії
Параметричні моделі Формальна модель оцінки COCOMO, SLIM, SEER-SEM
Моделі оцінки на основі розміру[12] Формальна модель оцінки Аналіз функціональних точок,[13] аналіз сценаріїв використання, SSU (Software Size Unit), аналіз очок історії користувача в гнучкій розробці
Групова оцінка Експертна оцінка Покер планування, Шаблон:Нп
Механічна комбінація Комбінована оцінка Середнє оцінки на основі аналогії, та на основі структури декомпозиції робіт
Комбінація судженням Комбінована оцінка Судження експерта на основі оцінок з параметричної моделі та групової оцінки

Вибір підходу до оцінювання

Шаблон:Section-stub

Обчислення точності оцінки

Найбільш поширеною мірою середньої точності оцінювання є середня величина відносної помилки MMRE (Шаблон:Lang-en), де величина відносної помилки MRE кожної оцінки описується як:

MRE = |actual effort−estimated effort|actual effort

Ця міра критикувалась[14] і існує кілька альтернативних мір, таких як більш симетричні[15] , Зважене середнє квартилів відносних помилок (Шаблон:Lang-en, WMQ) [16] та Mean Variation from Estimate (MVFE).[17]

Велику помилку в оцінці не можна одразу інтерпретувати як індикатор поганої здатності до оцінювання. Додатковими причинами можуть бути поганий контроль витрат проєкту, висока складність розробки, та випуск більшого функціоналу ніж планувалося. Фреймворк для покращеного використання та інтерпретації вимірювань помилки оцінювання подають в[18].

Психологічні проблеми

Існує багато психологічних факторів що потенційно пояснюють сильну тенденцію щодо надто оптимістичних оцінок, з якими треба справлятись зля збільшення точності оцінок. Ці фактори є суттєвими навіть при використанні формальних моделей оцінювання, тому що багато вхідних даних до цих моделей базуються на людських судженнях. Фактори що виявились важливими: прийняття бажаного за дійсне, ефект прив'язки, омана планування та когнітивний дисонанс. Обговорення цих та інших факторів може бути знайдене в роботах Йорґенсена та Грімстада.[19]

  • Легко оцінити те що ти знаєш.
  • Важко оцінити те що ти не знаєш.
  • Дуже важко оцінити те що ти не знаєш що ти не знаєш.

Див. також

Зноски

Шаблон:Reflist

Посилання

  1. ↑ Шаблон:Cite web
  2. ↑ Шаблон:Cite web
  3. ↑ Шаблон:Cite web
  4. ↑ Edwards, J.S. Moores, T.T. (1994), «A conflict between the use of estimating and planning tools in the management of information systems.». European Journal of Information Systems 3(2): 139—147.
  5. ↑ Goodwin, P. (1998). Enhancing judgmental sales forecasting: The role of laboratory research. Forecasting with judgment. G. Wright and P. Goodwin. New York, John Wiley & Sons: 91-112. Hi
  6. ↑ Шаблон:Cite webШаблон:Недоступне посилання
  7. ↑ Nelson, E. A. (1966). Management Handbook for the Estimation of Computer Programming Costs. AD-A648750, Systems Development Corp.
  8. ↑ COCOMO використовується фірмою Cost Xpert Шаблон:Webarchive а SLIM — QSM.
  9. ↑ Шаблон:Cite webШаблон:Недоступне посилання
  10. ↑ Briand, L. C. and I. Wieczorek (2002). Resource estimation in software engineering. Encyclopedia of software engineering. J. J. Marcinak. New York, John Wiley & Sons: 1160—1196.
  11. ↑ Шаблон:Cite web
  12. ↑ Hill Peter (ISBSG) — Estimation Workbook 2 — published by International Software Benchmarking Standards Group ISBSG — Estimation and Benchmarking Resource Centre Шаблон:Webarchive
  13. ↑ Morris Pam — Overview of Function Point Analysis Total Metrics — Function Point Resource Centre Шаблон:Webarchive
  14. ↑ Шаблон:Cite web
  15. ↑ Шаблон:Cite web
  16. ↑ Шаблон:Cite web
  17. ↑ Шаблон:Cite web
  18. ↑ Шаблон:Cite web
  19. ↑ Шаблон:Cite web
Отримано з https://uk.wiki.beta.math.wmflabs.org/w/index.php?title=Оцінка_складності_розробки_ПЗ&oldid=5496