Я збираюся передмовити це тим, що більшість того, що я знаходжу, походить з 1970-х та початку 1980-х років. За цей час послідовні моделі процесів були набагато більш поширеними, ніж ітеративний та / або поступовий підходи (модель спіралі або спритний метод). Значна частина цієї роботи будується на цих послідовних моделях. Однак я не думаю, що це руйнує взаємозв'язок, але однією з переваг ітеративного / поступового підходів є швидке звільнення функцій (цілого вертикального фрагмента програми) та виправлення проблем у ньому перед тим, як вводити залежності та складність кожної фази висока.
Я щойно витягнув свою копію Software Engineering Economics і знайшов посилання на дані, що стоять за цією діаграмою, в главі 4. Він цитує "Інспекції дизайну та коду для зменшення помилок у розробці програми" від ME Fagan ( IEEE , PDF від UMD ), EB "Управління інженерією програмного забезпечення" Далі, "Аналіз ресурсів, використовуваних у розробці програмного забезпечення захисних систем" ( ACM ), і "декілька проектів TRW" Делі .
... відносна вартість виправлення помилок програмного забезпечення (або внесення інших змін в програмне забезпечення) як функція фази, в якій вносяться виправлення чи зміни. Якщо помилка вимог до програмного забезпечення виявлена та виправлена на етапі планування та вимог, її виправлення є відносно простим питанням оновлення специфікації вимог. Якщо та сама помилка не буде виправлена до етапу технічного обслуговування, виправлення передбачає значно більший опис специфікацій, коду, посібників користувача та технічного обслуговування та навчального матеріалу.
Крім того, пізні виправлення передбачають набагато більш офіційний процес затвердження змін та контролю, а також набагато більш масштабну діяльність щодо відновлення виправлення. Ці фактори поєднуються, щоб зробити помилку, як правило, у 100 разів дорожче виправити у фазі технічного обслуговування великих проектів, ніж на етапі вимог.
Bohem також розглядав два менші, менш формальні проекти та виявив збільшення собівартості, але набагато менш значне, ніж у 100 разів, визначене у великих проектах. Зважаючи на діаграму, різниці виявляються в 4 рази більшими для виправлення дефекту вимог після роботи системи, ніж на етапі вимог. Він пов'язував це з меншою кількістю запасів предметів, що складаються з проекту, та зниженою формальністю, що призвело до можливості швидшого впровадження простішого виправлення.
Виходячи з Boehm в економіці програмного забезпечення, таблиця в Code Complete є досить роздутою (низький кінець діапазонів часто занадто високий). Вартість, щоб внести будь-які зміни в рамках фази, дійсно є 1. Екстраполюючи з рисунка 4-2 в Економіці програмного забезпечення, зміна вимог повинна бути в 1,5-2,5 рази в архітектурі, 2,5-10 в кодуванні, 4-20 в тестуванні і 4- 100 в обслуговуванні. Сума залежить від розміру та складності проекту, а також від формальності використовуваного процесу.
У Додатку Е Баррі Бума та Річарда Тернера " Збалансованість спритності та дисципліни" міститься невеликий розділ про емпіричні висновки щодо вартості змін.
У вступних параграфах цитується Кента Бека Екстремальне програмування, пояснене, цитуючи Бека. У ньому йдеться про те, що якщо вартість змін зростатиме повільно з часом, рішення приймаються якомога пізніше, і буде реалізовуватися лише те, що потрібно. Це відоме як "плоска крива", і саме це рухає Екстремальне програмування. Однак попередня література виявила «круту криву», коли малі системи (<5 KSLOC) мали зміну 5: 1, а великі системи мали зміну 100: 1.
У розділі цитується Центр емпірично заснованої програмної інженерії Меріленду (за підтримки Національного наукового фонду). Вони здійснили пошук доступної літератури і виявили, що результати, як правило, підтверджують співвідношення 100: 1, а деякі результати вказують на діапазон від 70: 1 до 125: 1. На жаль, це, як правило, проекти "великого дизайну на передній план" та керовані ними послідовно.
Є зразки "малих комерційних Java-проектів", які виконуються за допомогою програми Extreme Programming. Для кожної історії було відстежено велику кількість зусиль для виправлення помилок, нового дизайну та рефакторингу. Дані показують, що в міру розвитку системи (впроваджено більше історій користувачів) середні зусилля мають тенденцію до збільшення нетривіальної швидкості. Зусилля у рефакторингу збільшуються приблизно на 5%, а зусилля на фіксацію зусиль збільшуються приблизно на 4%.
Я дізнаюся, що складність системи відіграє велику роль у кількості необхідних зусиль. Створюючи вертикальні зрізи через систему, ви сповільнюєте швидкість кривої, повільно додаючи складність, а не додаючи її в палі. Замість того, щоб мати справу з масою складності вимог, що супроводжується надзвичайно складною архітектурою, за якою слід надзвичайно складна реалізація тощо, ви починаєте дуже просто і додаєте.
Який вплив це має на витрати, які потрібно виправити? Зрештою, можливо, не дуже. Однак у нього є переваги, що дозволяють забезпечити більший контроль над складністю (через управління технічним боргом). Крім того, часті результати, часто пов'язані з гнучким, означають, що проект може закінчитися швидше - замість того, щоб доставити "систему", шматки будуть доставлені доти, доки потреби бізнесу не будуть задоволені або кардинально не зміниться на нову систему (а отже, новий проект) потрібен.
Метрики та моделі Стівена Кан в інженерії якості програмного забезпечення має розділ у розділі 6 про економічну ефективність видалення дефектів фази.
Він починає, цитуючи статтю Фагана 1976 року (також цитується в програмі Економіка програмного забезпечення), щоб стверджувати, що переробку, виконану у дизайні високого рівня (архітектура системи), низькорівневому дизайні (детальний дизайн) та впровадженні, може бути в 10 і 100 разів менш дорогим. ніж робота, виконана під час тестування компонентів та системного рівня.
Він також цитує дві публікації Фрідмана та Вайнберга (1982 і 1984), які обговорюють великі системи. Перший - "Довідник покрокових інструкцій, інспекцій та технічних оглядів", а другий - "Огляди, покрокові інструкції та інспекції". Застосування оглядів на початку циклу розробки може зменшити кількість помилок, які досягають етапів тестування, в 10 разів. Це зменшення кількості дефектів призводить до зниження витрат на тестування на 50% до 80%. Мені довелося б прочитати дослідження більш докладно, але виявляється, що вартість включає також пошук та виправлення дефектів.
У дослідженні Remus 1983 р. "Комплексна перевірка програмного забезпечення з огляду на перевірки / огляд" було вивчено вартість усунення дефектів на різних фазах, зокрема перевірки дизайну / коду, тестування та обслуговування, використовуючи дані лабораторії Санта-Тереза IBM у Каліфорнії. Наведені результати вказують на коефіцієнт витрат 1:20:82. Тобто, дефект, виявлений при перевірці дизайну чи коду, має змінитись у вартість 1. Якщо той самий дефект уникне тестування, він обійдеться у 20 разів дорожче. Якщо він уникне повного шляху до користувача, він збільшить витрати на виправлення до 82. Кан, використовуючи зразкові дані з IBM Rochester, Minnessota, встановив, що вартість усунення дефектів для проекту AS / 400 є аналогічною о 1:13:92. Однак він вказує, що збільшення вартості може бути пов’язане із збільшенням труднощів у пошуку дефекту.
У публікаціях Гілба 1993 р. ( "Огляд програмного забезпечення" ) та 1999 р. ("Оптимізація специфікації інженерії програмного забезпечення та процесів контролю якості") про перевірку програмного забезпечення підтверджуються інші дослідження.
Додаткову інформацію можна знайти на сторінці Construx, присвяченій збільшенню витрат на дефекти, яка містить ряд посилань на збільшення вартості виправлення дефектів. Слід зазначити, що Стів МакКоннелл, автор Code Complete, заснував і працює для Construx.
Я недавно слухав бесіду, Real Software Engineering , дану Гленн Vanderburg в Lone Star Ruby - конференції в 2010 році він дав той же розмову в шотландської рубіновим конференції і Erubycon в 2011 році, QCon Сан - Франциско в 2012 році , і O'Reilly Software Architecture конференції у 2015 році . Я слухав лише Конференцію самотньої зірки Рубі, але розмова розвивалася з часом, коли його ідеї були вдосконалені.
Вендербург припускає, що всі ці історичні дані фактично показують вартість виправлення дефектів у міру просування часу, а не обов'язково, коли проект рухається по фазах. Багато проектів, що розглядалися в згаданих раніше працях і книгах, були послідовними проектами "водоспад", де фаза і час рухалися разом. Однак подібна закономірність з'явиться в ітераційних та поступових проектах - якщо дефект було введено за одну ітерацію, виправити цю ітерацію було б відносно недорого. Однак у міру проходження ітерацій багато чого відбувається - програмне забезпечення стає складнішим, люди забувають деякі незначні деталі щодо роботи в конкретних модулях чи частинах коду, вимоги змінюються. Все це збільшить витрати на виправлення дефекту.
Я думаю, що це, мабуть, ближче до реальності. У проекті водоспаду вартість збільшується через кількість артефактів, які необхідно виправити через проблему, що виходить за течією. У ітеративних та поступових проектах вартість збільшується через збільшення складності програмного забезпечення.