Оцінка складності розробки ПЗ: відмінності між версіями

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
Наступне редагування →
Вилучено вміст Додано вміст
ВізуальнийВікірозмітка
Створена сторінка: '''Оцінювання складності розробки ПЗ''' - це процес передбачування найбільш ймовірного в...
(Немає відмінностей)

Версія за 05:05, 27 квітня 2014

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

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

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

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

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


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

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

MRE =

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

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

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

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

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

Див. також

Зноски

  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. ↑ Shepperd, M. Cartwright, M. Kadoda, G. On Building Prediction Systems for Software Engineers.
  7. ↑ Kitchenham, B. Pickard, L.M. MacDonell, S.G. Shepperd,. What accuracy statistics really measure.
  8. ↑ Foss, T. Stensrud, E. Kitchenham, B. Myrtveit, I. A Simulation Study of the Model Evaluation Criterion MMRE. IEEE.
  9. ↑ Miyazaki, Y. Terakado, M. Ozaki, K. Nozaki, H. Robust regression for developing software estimation models.
  10. ↑ Lo, B. Gao, X. Assessing Software Cost Estimation Models: criteria for accuracy, consistency and regression.
  11. ↑ Hughes, R.T. Cunliffe, A. Young-Martos, F. Evaluating software development effort model-building techniquesfor application in a real-time telecommunications environment.
  12. ↑ Grimstad, S. Jørgensen, M. A Framework for the Analysis of Software Cost Estimation Accuracy.
  13. ↑ Jørgensen, M. Grimstad, S. How to Avoid Impact from Irrelevant and Misleading Information When Estimating Software Development Effort.

Посилання

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