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

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

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

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

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

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

Історія

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

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

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

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

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

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

Підхід до оцінювання	Категорія	Приклади втілення підходу до оцінювання
Оцінка на основі аналогії	Формальна модель оцінки	ANGEL,
На основі WBS (оцінка знизу вверх)	Експертна оцінка	Системи управління проєктами, шаблони активності специфічні для компанії
Параметричні моделі	Формальна модель оцінки	, SLIM,
Моделі оцінки на основі розміру	Формальна модель оцінки	Аналіз функціональних точок, аналіз сценаріїв використання, SSU (Software Size Unit), аналіз очок історії користувача в гнучкій розробці
Групова оцінка	Експертна оцінка	Покер планування, ^[en]
Механічна комбінація	Комбінована оцінка	Середнє оцінки на основі аналогії, та на основі структури декомпозиції робіт
Комбінація судженням	Комбінована оцінка	Судження експерта на основі оцінок з параметричної моделі та групової оцінки

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

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

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

MRE = ${\frac {|{\text{actual effort}}-{\text{estimated effort}}|}{\text{actual effort}}}$

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

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

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

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

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

Див. також

Функціональна точка

Зноски

Jørgensen, M. (англ.). Архів оригіналу за 27 квітня 2014. Процитовано 27 квітня 2014.
Molokken, K. Jorgensen, M. A review of software surveys on software effort estimation (англ.).
Jørgensen, M. Teigen, K.H.Ribu, K. Better sure than safe? Over-confidence in judgement based software development effort prediction intervals (англ.).
Edwards, J.S. Moores, T.T. (1994), «A conflict between the use of estimating and planning tools in the management of information systems.». 3(2): 139—147.
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
Farr, L.Nanus, B. Factors that affect the cost of computer programming.^{[недоступне посилання з липня 2019]}
Nelson, E. A. (1966). Management Handbook for the Estimation of Computer Programming Costs. AD-A648750, Systems Development Corp.
COCOMO використовується фірмою Cost Xpert [Архівовано 14 вересня 2002 у Library of Congress] а SLIM — QSM.
Anda, B.Angelvik, E.Ribu, K. Improving Estimation Practices by Applying Use Case Models.^{[недоступне посилання з грудня 2021]}
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.
Jørgensen, M.Shepperd, M. . Архів оригіналу за 13 квітня 2021. Процитовано 27 квітня 2014.
Hill Peter (ISBSG) — Estimation Workbook 2 — published by International Software Benchmarking Standards Group ISBSG — Estimation and Benchmarking Resource Centre [ 29 серпня 2008 у Wayback Machine.]
Morris Pam — Overview of Function Point Analysis Total Metrics — Function Point Resource Centre [Архівовано 2012-09-12 у Archive.is]
Foss, T.Stensrud, E.Kitchenham, B. Myrtveit, I. A Simulation Study of the Model Evaluation Criterion MMRE. IEEE.
Miyazaki, Y.Terakado, M.Ozaki, K.Nozaki, H. Robust regression for developing software estimation models.
Lo, B.Gao, X. . Архів оригіналу за 27 квітня 2014. Процитовано 27 квітня 2014.
Hughes, R.T.Cunliffe, A.Young-Martos, F. Evaluating software development effort model-building techniquesfor application in a real-time telecommunications environment.
Grimstad, S.Jørgensen, M. . Архів оригіналу за 18 серпня 2009. Процитовано 27 квітня 2014.
Jørgensen, M.Grimstad, S. . Архів оригіналу за 23 жовтня 2016. Процитовано 27 квітня 2014.

Посилання

Jungmann, Dr Sven; Loijos, Alex. How to fix agile teams that are notoriously bad at hitting release dates. TechCrunch. Процитовано 4 січня 2017. - стаття про застосування методу ^[en] для оцінки складності розробки
Evans, Jon. On the dark art of software estimation. TechCrunch. Процитовано 6 листопада 2016.
, .. «Mastering Software Estimation: Best Practices, Tools and Techniques for Software Project Estimators», .
Industry Productivity data for Input into Software Development Estimates and guidance and tools for Estimation — International Software Benchmarking Standards Group: http://www.isbsg.org
Free first-order benchmarking utility from Software Benchmarking Organization:
General forecasting principles: http://www.forecastingprinciples.com
Mike Cohn's Estimating With Use Case Points from article from Methods & Tools: http://www.methodsandtools.com/archive/archive.php?id=25
Ресурси з оцінювання від : http://www.construx.com/Estimation/
Resources on Software Estimation from :
Estimation in Software Development (article): http://www.targetprocess.com/articles/estimates-software-development.html

[1] Jørgensen, M. (англ.). Архів оригіналу за 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.». 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. . Архів оригіналу за 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. . Архів оригіналу за 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. . Архів оригіналу за 18 серпня 2009. Процитовано 27 квітня 2014.

[19] Jørgensen, M.Grimstad, S. . Архів оригіналу за 23 жовтня 2016. Процитовано 27 квітня 2014.