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

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

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

Практичні результати[ред. | ред. код]

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

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

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

Історія[ред. | ред. код]

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

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

Вибір підходу до оцінювання[ред. | ред. код]

Цей розділ потребує доповнення. (січень 2017)

Обчислення точності оцінки[ред. | ред. код]

Найбільш поширеною мірою середньої точності оцінювання є середня величина відносної помилки 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]

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

Див. також[ред. | ред. код]

Зноски[ред. | ред. код]

  1. ↑ Jørgensen, M. A Review of Studies on Expert Estimation of Software Development Effort (англ.). Архів оригіналу за 27 квітня 2014. Процитовано 27 квітня 2014.
  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. Архів оригіналу за 13 квітня 2021. Процитовано 27 квітня 2014.
  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 [Архівовано 2012-09-12 у Archive.is]
  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. Архів оригіналу за 27 квітня 2014. Процитовано 27 квітня 2014.
  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. Архів оригіналу за 18 серпня 2009. Процитовано 27 квітня 2014.
  19. ↑ Jørgensen, M. Grimstad, S. How to Avoid Impact from Irrelevant and Misleading Information When Estimating Software Development Effort. Архів оригіналу за 23 жовтня 2016. Процитовано 27 квітня 2014.

Посилання[ред. | ред. код]

Отримано з https://uk.wikipedia.org/w/index.php?title=Оцінка_складності_розробки_ПЗ&oldid=41725941