Использует ли методология тестирования программного обеспечения некорректные данные?

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

Однако оказывается, что этих данных никогда не было . Данные, цитируемые Code Complete, по- видимому, не показывают такой корреляции затрат / времени разработки, а аналогичные опубликованные таблицы показывают только корреляцию в одних особых случаях и плоскую кривую в других (то есть без увеличения стоимости).

Есть ли какие-либо независимые данные, чтобы подтвердить или опровергнуть это?

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

Использует ли методология тестирования программного обеспечения некорректные данные?

Да, наглядно. Изучение кривой гибкой стоимости изменений показывает, что часть работы Кента Бека над XP (я не уверен, была ли она частью его мотивации или его оправдания) заключалась в том, чтобы «сгладить кривую» затрат на дефекты, основываясь на знании « экспоненциальная кривая, которая лежит за таблицей Code Complete. Так что, да, работа по крайней мере над одной методологией - той, которая больше всего способствовала популяризации разработки, основанной на тестах, - по крайней мере частично основана на некорректных данных.

Есть ли какие-либо независимые данные, чтобы подтвердить или опровергнуть это?

Да, безусловно, есть и другие данные, которые вы можете посмотреть - самое большое исследование, которое мне известно, - это анализ дефектов, выполненных на Hughes Aircraft в рамках их программы оценки CMM . Оттуда отчет показывает, как стоимость дефектов зависела от фазы для них : хотя данные в этом отчете не содержат отклонений, поэтому вам следует опасаться делать слишком много выводов «эта вещь стоит больше, чем эта вещь». Вы также должны заметить, что, независимо от методологии, в период с 1980-х годов по сегодняшний день произошли изменения в инструментах и ​​методах, которые ставят под сомнение актуальность этих данных.

Итак, предполагая, что у нас все еще есть проблема, оправдывающая эти цифры:

как это влияет на методологию разработки программного обеспечения?

Тот факт, что мы полагались на числа, которые невозможно проверить, не останавливал людей, делающих успехи на основе анекдотов и опыта: так же, как и многие мастер-ученики. Я не думаю, что в средневековье существовал « Журнал масонства, основанного на доказательствах» , но целая куча больших, впечатляющих и долговечных зданий, тем не менее, была построена с заметным успехом. Это означает, что мы в основном основываем нашу практику на «что сработало для меня или людей, с которыми я встречался»; Нет ничего плохого, но, возможно, не самый эффективный способ улучшить поле миллионов людей, которые являются краеугольным камнем нынешнего технологического века.

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

• что проприетарный характер большинства практик разработки программного обеспечения не препятствует сбору достаточного количества полезных и актуальных данных;
• что выводы, сделанные на основе этих данных, в целом применимы (поскольку разработка программного обеспечения является квалифицированной профессией, личные различия в опыте, способностях и вкусе могут повлиять на такую ​​применимость);
• что инженеры-программисты «на местах» могут и мотивированы использовать полученные результаты; а также
• что мы на самом деле знаем, какие вопросы мы должны задавать в первую очередь. Это, очевидно, самый важный момент: когда мы говорим об улучшении разработки программного обеспечения, что мы хотим улучшить? Какое измерение? Улучшает ли это измерение действительно результат или улучшает игру? В качестве примера предположим, что руководство моей компании решило, что мы собираемся уменьшить соотношение между фактической стоимостью проекта и прогнозируемой стоимостью проекта. Я мог бы просто начать умножать все мои оценки затрат на коэффициент выдумки, и я бы достиг этой «цели». Должно ли это стать стандартной отраслевой практикой, чтобы обмануть все оценки?

С моей стороны, ответ на вопрос «как это влияет на методологию разработки программного обеспечения» - «немного».

Независимо от того, пойман ли разработчик или конечный пользователь, требуется ли больше денег для его исправления после того, как он был пойман пользователем, или нет, факт остается фактом: в системе обнаружена ошибка. Если поймано разработчиком, надеюсь , это быстрое решение. Та же надежда имеет место для ошибок, пойманных пользователем.

Независимо от фактических затрат разработчиков в час на исправление ошибки, обнаруженной конечным пользователем, существует нематериальная стоимость поддержания стереотипа, который кодеры сосут из-за того, что они делают. Когда пользователь находит ошибку, виноват разработчик. Следовательно, каждая ошибка, обнаруженная конечным пользователем, снижает доверие пользователя к системе. Это все равно что совершить поездку по дому, который вы хотите купить, и увидеть пятно воды, проходящее через потолок в одном углу дома. Само по себе это легко исправить, но вам интересно, что вызвало это и что еще могло повлиять на эту основную причину. Сколько стоит ваше душевное спокойствие? Возможно, вам придется оторвать стены обратно к стойкам и визуально осмотреть все, чтобы убедиться, что пятно было от изолированного инцидента, который был исправлен. Знание, что это возможно, не делает вас очень уверенным в доме. По аналогии,

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

Я собираюсь предвосхитить это тем фактом, что большая часть того, что я обнаружил, относится к 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, но со временем разговоры развивались, поскольку его идеи были усовершенствованы.

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

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

Это просто простая логика.

Ошибка обнаружена в спец.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

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

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

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

Я считаю, что это и всегда было, об управлении рисками и экономике. Какова стоимость сокращения количества дефектов по сравнению с текущей стоимостью воздействия будущих дефектов. Траектория желтой птицы, слегка отклоненной от Angry Birds, не приравнивается к траектории вылета крылатой ракеты «Томагавк». Разработчики программного обеспечения в любом проекте не могут принимать решения на основе этой таблицы. В связи с этим ничего не меняется.

Я думаю, что это имеет тенденцию работать через обратную связь, дорогие ошибки на местах заставляют компании ужесточать свои процессы качества, в то время как никакие жалобы на местах не заставляют компании расслабляться. Таким образом, со временем компании-разработчики программного обеспечения будут стремиться сходиться или колебаться вокруг чего-то, что работает для них (+/-). Code Complete может повлиять на некоторые начальные значения или может немного потянуть компании. Компания, которая тратит слишком много усилий на устранение дефектов, которые никто не заметил бы, вероятно, потеряет бизнес для конкурента, который имеет более оптимизированный подход. С другой стороны, компания, выпускающая ошибочные продукты, также обанкротится.

Некоторые релевантные статьи из быстрого поиска (прочитайте полные статьи, сделайте больше исследований и составьте собственное мнение):

Систематический литературный обзор исследований стоимости программного обеспечения качества (2011)

«Хотя сообщество, таким образом, выработало четкое понимание структуры области исследования, часто не хватает эмпирической проверки. Лишь около трети проанализированных статей представляет тематическое исследование или более обширные эмпирические результаты. По-видимому, этого недостаточно для исследования стоимости качества программного обеспечения. , которая сильно полагается на количественные данные для получения новых результатов. Таким образом, существует необходимость в новых подходах для сбора качественных данных о затратах, а также в более тесном сотрудничестве между промышленностью и исследованиями для обеспечения доступности таких данных ».

Оценка стоимости качества программного обеспечения (1998)

«Наконец, мы увидели, что важно отслеживать расходы на соответствие и несоответствие программного обеспечения, чтобы политики соответствия могли быть скорректированы для снижения общих затрат на качество программного обеспечения».

Стоимостное поведение дефектов программного обеспечения (2004)

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

Тестовое покрытие и дефекты после проверки: многократное исследование (2009)

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

Преодоление разрыва между процессом тестирования программного обеспечения и стоимостью для бизнеса: пример из практики

Я не могу ответить на вашу первую часть вопроса, так как я просто не проверил. Но я могу сформулировать ответ на ваш второй вопрос и, возможно, намекнуть на возможный ответ на первый.

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

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

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

Я считаю, что реалии конкуренции в отрасли негативно влияют на использование методов повышения качества при разработке программного обеспечения, сохраняя низкое качество программного обеспечения как показатель постоянного успеха.

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

Есть исключения. Я уверен, что Google не будет работать в своем темпе без каких-либо твердых практик, поддерживаемых звездными разработчиками. И другие, вероятно, в той же ситуации. Но для большинства программного обеспечения, я бы не удивился , если данные действительно фактически подтверждает утверждение в полном коде .

Еще один ответ! На этот раз, чтобы ответить на заглавный вопрос "Мортодолигия программного обеспечения опирается на некорректные данные".

Реальный ответ - «нет данных». Поскольку нет большого надежного массива данных о программных проектах, есть дефекты, успехи на рынке и т. Д.

Все попытки собрать такие данные были недостаточно профинансированы, статистически ошибочны или настолько специфичны для конкретного проекта, что невозможно сделать общие выводы.

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

Единственные организации, которые публикуют данные о стоимости и успешности программных проектов,
- это правительственные департаменты, и только тогда, когда они должны это делать, да, эти цифры сильно смущают, независимо от того, насколько они массируют цифры.

Таким образом, в заключение все исследования программного обеспечения обязательно являются чисто субъективными, потому что нет реальных данных, на которых можно основывать объективное заключение.