Время, потраченное на требования и его влияние на успех проекта и время разработки

Есть ли доказательства того, что время, потраченное на написание или размышления о требованиях, повлияет на время разработки? Исследование, проведенное Standish (1995), показывает, что неполные требования частично (13,1%) способствовали провалу проектов. Проводятся ли какие-либо исследования, которые показывают, что время, потраченное на анализ требований, окажет какое-либо влияние на время разработки проекта, или насколько успешным будет проект.

software-engineering

— Кен Ли
источник

Как гибкие модели подходят здесь? Можно утверждать, что они проводят время требований (вкл. И выкл.), Но «фаза» требований как таковая отсутствует.

— Рафаэль

Согласитесь с @Raphael. Собираемся ли мы отвечать на вопросы по разработке программного обеспечения? Или официальная политика сайта заключается в том, что на данном этапе не стоит проводить различие между «информатикой» и «разработкой программного обеспечения»?

— Patrick87

@ Patrick87 Давайте перейдем к мета .

— Рафаэль

Мне кажется, что этот вопрос лучше подходит для существующих сайтов разработки программного обеспечения и управления проектами .

— Адам Лир

Ответы:

См. Code Complete, Стив Макконнелл, Таблица 3-1. Он сравнивает среднюю стоимость исправления дефектов на основе того, когда они были обнаружены и обнаружены. Обнаружение во время строительства обходится в 5-10 раз дороже, чем обнаружение во время требований, и в 10-100 раз дороже после выпуска.

Таблица основана на следующих источниках:

«Дизайн и проверки кода для уменьшения ошибок в программной разработке» (Fagan 1976)
Удаление дефектов программного обеспечения (Dunn 1984)
«Совершенствование программного обеспечения на самолетах Hughes» (Хамфри, Снайдер и Уиллис, 1991)

и еще несколько

— Джо
источник

Одного этого недостаточно. Дорогие ошибки должны происходить достаточно часто, и их нужно ловить достаточно часто, чтобы составить соответствующие требования. В противном случае дополнительные затраты на разработку требований могут все же перевесить ошибки.

— Рафаэль

Это правда. Мы должны предположить, что до определенного момента отсутствие поспешных требований означает, что в требованиях меньше ошибок, но это не кажется слишком большой натяжкой.

— Джо

Да, есть много исследований на эту тему. Конечно, этот вопрос слишком общий, чтобы отвечать на все виды проектов разработки программного обеспечения, но есть свидетельства из нескольких контекстов, которые поддерживают идею о том, что правильное выполнение анализа требований окажет положительное влияние на этап внедрения. Эти доказательства были частично собраны в «законы», и вот три примера:

Закон Гласса: недостаток требований - основной источник провалов проекта.

Этот закон подкреплен примерами из крупных проектов по разработке программного обеспечения. Гласс обнаружил, что в неудачных случаях было слишком много требований, они были нестабильны из-за поздних изменений, и они были неоднозначными и неполными.

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

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

Это также подтверждается данными тематических исследований и способствует ответу на вопрос следующим образом: правильное выполнение требований уменьшит количество ошибок в системе, а исправление ошибок перед началом внедрения будет дешевле, чем их поиск. вниз, когда реализация уже началась (или хуже, когда система уже отправлена).

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

Это подтверждается контролируемыми экспериментами в студенческом контексте. Одна из возможных интерпретаций заключается в том, что требования и этапы проектирования не обязательно должны быть полностью основаны на документации и являются теоретическими. Вместо этого выполнение прототипирования как часть этапов требований и проектирования - что означает потратить время на размышления над требованиями - повлияет на успех проекта и время реализации.

Существует также множество других свидетельств, указывающих в том же направлении: затраты времени на подготовку к внедрению окупаются в виде меньшего риска и меньшей вероятности превышения графика из-за неожиданностей. Хотя вопрос не в тестировании, надлежащая подготовка также положительно влияет на тестирование.

Ссылки на эти законы:

Закон Гласса: Glass, RL: Software Runaways. Уроки, извлеченные из массовых сбоев программных проектов. Аппер-Ривер, Нью-Джерси: Прентис Холл, 1998

Первый закон Бома: Бём Б.В., МакКлин Р.К., Урфриг Д.Б .: Опыт работы с автоматизированными средствами проектирования крупномасштабного надежного программного обеспечения. IEEE Trans по программной инженерии 1, 1 (1975), 125–133

Второй закон Бома: Бём, BW, Грей, TE, Seewaldt, T .: Прототипирование против Спецификации: Мультипроектный эксперимент. IEEE Trans по программной инженерии 10, 3 (1984), 290–302

Также могут представлять интерес следующие ссылки: Эндрес А. и Ромбах Д. Справочник по программному обеспечению и системному проектированию. Эмпирические наблюдения, законы и теории. Серия Fraunhofer IESE по разработке программного обеспечения. Аддисон Уэсли, 2003.

— Фабиан Фагерхольм
источник