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