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

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

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

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

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

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

Історія

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

Більшість досліджень фокусувались на створенні формальних моделей оцінки. Ранні моделі зазвичай базувались на регресійному аналізі чи математично запозичувались від теорій з інших предметних областей. Відтоді було опробувано багато підходів до моделювання, такі як обґрунтування на основі прецедентів, класифікація та регресійні дерева, симуляція, штучні нейронні мережі, Баєсівска статистика, лексичний аналіз специфікації вимог, генетичне програмування, лінійне програмування, нечітка логіка, статистичний бутстреп, та комбінація двох чи більше таких моделей. Можливо найбільш поширеними сьогодні методами оцінки є параметричні моделі оцінки COCOMO та SLIM. Обидвi моделi беруть за основу дослідження проведені в 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), аналіз очок історії користувача в гнучкій розробці
Групова оцінка Експертна оцінка Покер планування, Wideband Delphi
Механічна комбінація Комбінована оцінка Середнє оцінки на основі аналогії, та на основі структури декомпозиції робіт
Комбінація судженням Комбінована оцінка Судження експерта на основі оцінок з параметричної моделі та групової оцінки

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

Найбільш поширеною мірою середньої точності оцінювання є середня величина відносної помилки MMRE (англ. Mean Magnitude of Relative Error), де величина відносної помилки MRE кожної оцінки описується як:

MRE =

Ця міра критикувалась[14] і існує кілька альтернативних мір, таких як більш симетричні[15] , Зважене середнє квартилів відносних помилок (англ. Weighted Mean of Quartiles of relative errors, WMQ) [16] та Mean Variation from Estimate (MVFE).[17]

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

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

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

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

Див. також
  • Оцінка витрат в програмній інженерії
  • Перевищення запланованих витрат
  • Функціональна точка
  • Proxy-based estimating
  • Модель Путнема
  • Конус невизначеності

Зноски
  1. Jørgensen, M. A Review of Studies on Expert Estimation of Software Development Effort.
  2. Molokken, K. Jorgensen, M. A review of software surveys on software effort estimation.
  3. Jørgensen, M. Teigen, K.H. Ribu, K. Better sure than safe? Over-confidence in judgement based software development effort prediction intervals.
  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. Farr, L. Nanus, B. Factors that affect the cost of computer programming.[недоступне посилання з липня 2019]
  7. Nelson, E. A. (1966). Management Handbook for the Estimation of Computer Programming Costs. AD-A648750, Systems Development Corp.
  8. COCOMO використовується фірмою Cost Xpert Архівовано 14 вересня 2002 у Library of Congress а SLIM — QSM.
  9. Anda, B. Angelvik, E. Ribu, K. Improving Estimation Practices by Applying Use Case Models.[недоступне посилання з грудня 2021]
  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. Jørgensen, M. Shepperd, M. A Systematic Review of Software Development Cost Estimation Studies.
  12. Hill Peter (ISBSG) — Estimation Workbook 2 — published by International Software Benchmarking Standards Group ISBSG — Estimation and Benchmarking Resource Centre Архівовано 29 серпня 2008 у Wayback Machine.
  13. Morris Pam — Overview of Function Point Analysis Total Metrics — Function Point Resource Centre
  14. Foss, T. Stensrud, E. Kitchenham, B. Myrtveit, I. A Simulation Study of the Model Evaluation Criterion MMRE. IEEE.
  15. Miyazaki, Y. Terakado, M. Ozaki, K. Nozaki, H. Robust regression for developing software estimation models.
  16. Lo, B. Gao, X. Assessing Software Cost Estimation Models: criteria for accuracy, consistency and regression.
  17. Hughes, R.T. Cunliffe, A. Young-Martos, F. Evaluating software development effort model-building techniquesfor application in a real-time telecommunications environment.
  18. Grimstad, S. Jørgensen, M. A Framework for the Analysis of Software Cost Estimation Accuracy.
  19. Jørgensen, M. Grimstad, S. How to Avoid Impact from Irrelevant and Misleading Information When Estimating Software Development Effort.

Посилання
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.