Час, витрачений на потреби та його вплив на успіх проекту та час розробки

Чи є якісь докази, що свідчать про те, що час, витрачений на написання або роздуми над вимогами, матиме якийсь вплив на час розробки? Дослідження, проведене Standish (1995), свідчить про те, що неповні вимоги частково (13,1%) сприяли провалу проектів. Чи проводяться якісь дослідження, які показують, що час, витрачений на аналіз потреб, матиме будь-який вплив на час розробки проекту або наскільки успішним буде проект.

Див. Кодекс повний, Стів Макконнелл, Таблиця 3-1. Він порівнює середню вартість виправлення дефектів на основі їх введення та виявлення. Виявлення під час будівництва коштує в 5-10 разів більше, ніж виявлення за вимогами, і в 10-100 разів більше після випуску.

Таблиця базується на таких джерелах:

1. "Інспекції дизайну та коду для зменшення помилок у розробці програми" (Фаган 1976)

2. Видалення програмного дефекту (Данн 1984)

3. "Вдосконалення програмних процесів на літаках Х'юз" (Хамфрі, Снайдер та WIllis 1991)

та ще кілька

Так, досліджень на цю тему багато. Звичайно, питання є надто загальним, щоб відповісти на всі види проектів з розробки програмного забезпечення, але є дані з декількох контекстів, які підтримують уявлення про те, що правильний аналіз вимог матиме позитивний вплив на етапі впровадження. Ці докази частково зібрані в "закони", і ось три приклади:

Закон Скло: Нестача вимог є основним джерелом невдач проекту.

Цей закон підкріплений даними, отриманими на прикладі досліджень з великих проектів розробки програмного забезпечення. Скло встановив, що в невдалих випадках було занадто багато вимог, вони були нестабільними через пізні зміни, і вони були неоднозначними та неповними.

Це говорить про те, що існує залежність між якістю вимог та результатом проекту.

Перший закон Бома : Помилки є найчастішими під час виконання вимог та проектних робіт і тим дорожчі, чим пізніше вони усуваються.

Це також підкріплюється доказами прикладної справи і сприяє відповіді на питання наступним чином: правильне виконання вимог зменшить кількість помилок у системі, а виправлення помилок перед початком впровадження буде менш дорогим, ніж їх полювання. вниз, коли впровадження вже розпочато (або ще гірше, коли система вже завантажена).

Другий закон Бома : прототипування (значно) зменшує вимоги та помилки проектування, особливо для користувальницьких інтерфейсів.

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

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

Посилання на ці закони:

Закон про скло: Glass, RL: Software Runaways. Уроки, отримані в результаті провалів програм масового програмного забезпечення. Річка Верхнього Сідла, штат Нью-Джерсі: Зал Prentice 1998

Перший закон Boehm: Boehm, BW, McClean, RK, Urfrig, DB: деякий досвід автоматизованих посібників для проектування надійного програмного забезпечення великого масштабу. IEEE Trans on Software Engineering 1, 1 (1975), 125–133

Другий закон Бома: Бум, Б.В., Грей, ТЕ, Севальдт, Т.: Прототипізація версій із зазначенням: багатопроектний експеримент. IEEE Trans on Software Engineering 10, 3 (1984), 290–302

Також можуть бути цікаві такі посилання: Endres, A. і Rombach, D. Handbook of Software and System Engineering. Емпіричні спостереження, закони та теорії. Серія Fraunhofer IESE з інженерії програмного забезпечення. Аддісон Веслі, 2003.