Исследование «Ошибки в производственной среде в 100 раз дороже исправлять», возможно, даже не существует

ИсследованиеОшибкивпроизводственнойсредев100раздорожеисправлятьвозможнодаженесуществует

«Исследования программного обеспечения – это крушение поезда», – говорит Хиллел Уэйн, консультант по программному обеспечению из Чикаго, специализирующийся на формальных методах, подтверждая полученное мнение о том, что исправлять ошибки намного дороже после того, как программное обеспечение

Уэйн провел небольшое исследование , отметив, что «если вы погуглите стоимость ошибки программного обеспечения ‘вы получите массу статей, в которых говорится:’ ошибки, обнаруженные в требованиях: 171 x дешевле, чем ошибки, обнаруженные в реализациях ». Все они используют эту диаграмму из «Института системных наук IBM» … Есть одна крошечная проблема с исследованием Института системных наук IBM: его не существует ».

Лоран Боссавит , эксперт по методологии Agile и технический советник в консалтинговой компании CodeWorks в Париже, посвятил этому вопросу некоторое время и опубликовал сообщение на GitHub под названием ” Степени интеллектуальной нечестности “. Bossavit сослался на успешную 1987 книгу Роджера С. Прессмана под названием Разработка программного обеспечения: подход практикующего специалиста , который гласит: «Чтобы проиллюстрировать влияние затрат на раннее обнаружение ошибок, мы рассматриваем ряд относительных затрат, которые основаны на на данных о фактических затратах, собранных для крупных программных проектов . “

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

Боссавит нашел время, чтобы исследовать существование Института системных наук IBM, заключив, что это была «внутренняя программа обучения для сотрудников». Нет данных, подтверждающих цифры в диаграмме, которая показывает аккуратный x стоимость исправления ошибки после того, как программное обеспечение находится на обслуживании. “Исходные данные проекта, если таковые существуют, не старше 1981 и, вероятно, старше; и может быть таким же старым, как 1981 », – сказал Боссавит, который также описал« желание залезть в яму, когда я сталкиваюсь с чушью, маскирующейся под эмпирическое подтверждение утверждения, такого как «исправление дефектов стоит дороже, чем позже вы их исправляете» ».

Чем позже обнаруживаются дефекты программного обеспечения, тем дороже стоит их устранение? «Я думаю, что объем исследований пока ориентировочно указывает в этом направлении, в зависимости от того, как вы интерпретируете« поздняя стадия »,« ошибки »и« дороже », – сказал Уэйн. больше повреждений), чем другие, и указанные ошибки, как правило, являются проблемами в конструкции. “

Вот 2016 бумага [PDF] чьи авторы “исследовали 171 программное обеспечение проекты, выполненные между 2014 и 2014, “все из которых использовали методологию, называемую Team Software Process. Исследователи пришли к выводу, что” время для решения проблем в разное время обычно существенно не различались “.

Уэйн так же озабочен состоянием исследований программного обеспечения, как и самим вопросом о дефекте. Он заметил, что в статьях, подобных упомянутой выше,” используются разные определения дефекта “, что затрудняет выводы. Он сказал, что сторонник эмпирической программной инженерии (ESE), использующий данные для изучения того, что работает в разработке программного обеспечения, но сказал, что «академические структуры стимулирования не согласованы таким образом, чтобы дать отрасли полезную информацию. Существует гораздо больше стимулов для создания новых моделей и внедрения новых инноваций, чем для выполнения необходимой «черновой работы», которая была бы наиболее полезной ».

Он предложил сосредоточиться на том, что« в подавляющем большинстве случаев показывают эмпирические исследования, Проверка кода “это то” – хороший способ найти ошибки в программном обеспечении и распространить знания о программном обеспечении. Это также показывает, что более короткие циклы итераций и циклы обратной связи приводят к более качественному программному обеспечению, чем длительные сроки выполнения ».

Роль« IBM Systems Sciences Institute »в укреплении авторитета исследований это может не существовать, это напоминание о важности первоисточников, которые может быть трудно обнаружить в эхо-камере Интернета.

Прямо по команде в нашем почтовом ящике выскочил небольшое «исследование» PR-агентства относительно доходов пяти ведущих поставщиков облачных услуг на основе «опроса Statista». Statista, однако, не является в первую очередь исследовательской компанией. Вместо этого она «консолидирует статистические данные по более чем 81, 04 темы из больше, чем 22 , 1609 исходники, “ согласно его собственному описанию.

Упомянутое исследование не происходит от Statista, но от м Облачные войны . Ссылка на Statista в качестве источника – все равно что приписывать утверждение, обнаруженное в поиске Google, как имеющее авторитет Google. Риск такой путаницы заключается в том, что плохой источник может быть повышен до лучшего (и это не означает, что данные Cloud Wars неточны). ®

Leave a comment

Your email address will not be published. Required fields are marked *