на каком этапе разработки дороже всего устранить баг
Относительные расходы на исправление багов
Институт Системных Исследований при IBM (Systems Sciences Institute at IBM) утверждает, что стоимость устранения бага, обнаруженного после релиза программы в 4-5 раз выше, чем если бы его обнаружили на стадии дизайна и до 100 раз больше на стадии технического обслуживания.
Стоимость бага растет по мере движения по циклу разработки программного обеспечения (Software Development Life Cycle): чем дальше, тем дороже. Это эффект домино – чем позже обнаружена ошибка, тем больше изменений необходимо сделать, тем больше частей кода будет задействовано и, возможно, некоторые части придется переписывать и согласовать с остальными. Это в свою очередь может привести к запуску цикла разработки программного обеспечения заново, что приведет к срыву сроков сдачи и к финансовым потерям.
К примеру, если баг будет обнаружен на стадии формирования требований к программному обеспечению, стоимость его устранения будет 100 условных единиц. Если эта же ошибка будет обнаружена на стадии тестирования ПО, стоимость ее устранения будет 1500 условных единиц. После релиза баг будет стоить 10 000 условных единиц. А если он никогда не будет обнаружен, то ущерб, наносимый компании, может исчисляться огромными суммами.
Исследование, проведенное Национальным институтом стандартов и технологий США в 2003 году, показало, что ошибки в программном обеспечении обходятся экономике США в 60 млрд. долларов ежегодно.
Вот некоторые выдающиеся примеры того, какие потери понесли компании, в результате позднего обнаружения ошибок в программном обеспечении.
• Ма́ринер-1: космический аппарат был запущен в 1962 году и потерпел аварию через 293 секунды после старта: антенна аппарата потеряла связь с наводящей системой на Земле, в результате управление взял на себя бортовой компьютер, программа которого содержала ошибку. Согласно официальным отчетам, причиной аварии стал пропущенный дефис (в других источниках – пропущенная черта над символом). Стоимость ракеты, как сообщается, более 18 млн долларов США на тот момент.
• Отзывы автомобилей Toyota в 2009 году: все отзывы были связаны с заклиниванием педали акселератора. Один из пассажиров Lexus ES350 позвонил в службу спасения – автомобиль начал неконтролируемо ускоряться на скорости 100 км\ч и перестал реагировать на педаль тормоза. Погибли четверо пассажиров. В ноябре 2009 дилерам было предписано укоротить педаль газа, обновить программное обеспечение автомобилей и протестировать приложение, которое содержало ошибку, которая вызывала задержку в работе тормозной системы. Таким образом, к 2010 году было отозвано более 9 млн автомобилей, потери компании составили 3 млрд долларов США.
• Торговые нарушения Knight Capital Group: в августе 2012 года одна из крупнейших трейдинговых компаний США ошибочно разослала более четырех миллионов сток ордеров менее чем за час. Эти ордера должны были быть распределены на несколько дней. Эта ошибка стоила полмиллиарда долларов и должна была привести к банкротству компании, если бы на выручку не пришла группа инвесторов с 400 млн долларов в качестве помощи. Проблема заключалась в том, что обновление не было загружено на все серверы, а серверы со старым кодом сгенерировали миллионы ордеров. Эта ошибка принесла ущерба на сумму 440 млн долларов США, что в четыре раз превышает прибыль компании за 2011 год.
Все эти примеры показывают, к каким огромным финансовым потерям могут привести ошибки в программном обеспечении. Чтобы минимизировать издержки от таких находок, рекомендуется проводить тестирование программного обеспечения до его релиза.
Ликвидировать нужно не баги, а причину их появления: кейс от разработчика игр
От переводчика: сегодня публикуем для вас статью опытного геймдев-тестировщика Ричарда Тейлора. Статья будет полезна как начинающим, так и опытным разработчикам, — обсудить тут точно есть что.
Я создал множество игр. Обычно завершающий этап разработки весьма болезненный. Ведь именно в конце мы сталкиваемся с багами, и лишь после этого можно уже окончательно наводить лоск на продукт. Ситуация ухудшается, когда у разработчика есть минимум времени на завершение проекта. Работать приходится быстро, и баги в этом случае — частые гости. Как можно справиться с ними? Очень просто: допускать меньше ошибок, только и всего (это ирония автора — примечание переводчика).
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Снижаем количество багов
Поскольку все баги — в коде, то, наверное, просто достаточно попросить команду разработки допускать меньше ошибок?
Если вам смешно в этом месте, я не удивлюсь. И действительно, ведь никто (ну или практически никто) не совершает их по собственной воле. Так что же можно предложить команде, чтобы она делала меньше ошибок в коде, с тем, чтобы в нем не было багов?
Начинаем новый проект. Шаг первый — не повторяем предыдущих ошибок
Наша команда работала над несколькими ААА-проектами. Перед тем, как начать один из них, мы решили провести брейнсторминг на тему «Как допустить минимальное количество ошибок». Никто из нас не хотел провести последние пару месяцев работы над проектом в поиске багов и зачистке кода. Одна из основных задач — распределение ответственности и обязанностей. Каждому типу работ был назначен старший.
Шаг первый — определиться, зачем все это нужно. «Зачем» верхнего уровня объясняется просто: мы хотим снизить количество времени, требуемого на ликвидацию багов, оптимизировать затраты и повысить общее качество проекта.
Речь идет о том, чтобы освободить время на выполнение интересных задач, тех, что позволяют радостно просыпаться утром и тут же браться за реализацию таска. Это то, что сделало нас всех разработчиками — возможность использоваться свое время на по-настоящему крутые штуки!
Кстати, даже если есть четкая задача создавать меньше багов, она настолько общая, что может быть попросту бессмысленной. Это заявление о намерении, которое необходимо уточнить и разбить на ряд четких заданий, адресованных отдельным членам команды.
Отвечая на вопрос, как это сделать, необходимо следовать основам научного метода: наблюдение, гипотеза, тест, повторение.
Наблюдение
Откройте базу данных багов вашего последнего проекта и просмотрите ее. Разновидностей багов много, так что просто сказать: меньше ошибок — попросту бесполезно.
Для того, чтобы лучше разобраться в вопросе, нужно определиться со спецификой. Снизить нужно в первую очередь количество тех проблем, на обнаружение и решение которых нужна прорва времени.
После составления списка самых трудоемких багов следующий шаг — попытка найти общее в этих ошибках, а также понять причину их появления. Анализируйте и интерпретируйте!
В конечном итоге мы создали ряд шаблонов для поиска специфических багов, что позволило понять, почему их поиск и ликвидация съедает столько времени. После этого мы были готовы перейти к исходному коду для поиска первопричины проблемы.
Работая с техническими специалистами, мы обнаружили больше fix changes. Затем составили новые списки систем, файлов и строк кода, связанных с крупными багами. В итоге мы сделали список необходимых изменений кода, который можно было обсудить с командой разработчиков.
Мы же вам говорили!
Затем мы провели встречу вместе с программистами для того, чтобы обсудить наши находки. Как оказалось, ребята знали о большинстве проблемных мест в коде. Но если это так, какой смысл был в том, чтобы проводить встречу?
Ответ: у нас получилось провести параллель между конкретными местами кода и временными потерями, связанными с этими проблемами. А это, в свою очередь, дало возможность объективно оценивать любое предложение по обслуживанию кода.
Таким образом, мы пересмотрели участки кода, которые можно было назвать приемлемо плохими. Когда мы оценили их с нашими наработками в руках, оказалось, что нужен рефакторинг. При этом инженерная команда ранее отказалась от него потому, что «работы слишком много» или «это попросту невозможно».
В самом деле, многие проблемы были системными. Многие «невидимые» аспекты приводили к цепочке событий, которые обусловливали появление ошибки. К слову, причины проблем были настолько системными, что проект пришлось начинать практически с нуля.
В итоге у нас накопилось достаточно результатов эмпирических наблюдений и анализа для того, чтобы сформировать гипотезы. В этом процессе принимала участие вся команда.
Гипотезы
Гипотеза 1. Специфические паттерны кодинга, вероятно, приведут к появлению багов в крупном программном проекте.
Гипотеза 2. Время, которое требуется на исправление ошибок в проекте, можно сократить, если избежать шаблонов поведения, определенных в первой гипотезе.
Давайте определимся с тем, что такое большой проект. Это около 25 программистов, 12 месяцев разработки. Для него справедливы следующие утверждения:
А. Любой код будет жить достаточно долго, так что стоимость обслуживания в итоге превысит стоимость самой разработки.
Б. Сложность соединения отдельных систем проекта выше, чем сложность конкретно взятой системы.
Почему это так важно? В небольших проектах вы можете справиться практически со всем, здесь программная структура не так важна. Код весь в вашем распоряжении.
Если проект большой, то все меняется. Вы можете работать с кодом, назначения которого вы не понимаете, можно даже не знать, к какой части проекта относится определенный участок.
После нашего обсуждения мы получили вот такую формулировку результатов: «Данные показывают, что эти конкретные шаблоны программирования были общим фактором, связанным с различными багами/проблемами. Мы считаем, что избегая этих паттернов, сможем сократить время, которое тратится на исправление ошибок, и одновременно улучшить качество».
Теперь приступаем к практической реализации.
Тестирование
Что дальше?
А дальше у нас появилась возможность начать новый проект, разработку новой игры. Мы смогли создать игровой движок с нуля и завершить все в срок, причем относительно небольшой командой программистов. Багов было немного, а код получился хорошим. При этом времени на его обслуживание потребовалось немного.
Все это стало возможным, потому что мы не использовали проблемные паттерны, как будто их и не существует больше. У нас даже появилась мантра «Усложни появление ошибки».
Вся команда была рада таким результатам, работать стало интереснее, ведь снова стало возможным тратить время на то, что тебе нравится.
пятница, 23 марта 2018 г.
Стоимость исправления ошибки на разных этапах разработки ПО
Если мы заметили ошибку на этапе написания требований, то исправить ее — дело 1 минуты, просто скорректировали предложение в тексте, и все.
Пока придумывают архитектуру будущего кода, стоимость уже дороже. Представьте, что архитектор уже придумал, как это будет выглядеть, а вы хотите изменить фундамент:
Но это еще реально. А вот если мы уже все построили (написали код), то некоторые изменения просто нельзя внести и приходится мириться с багом. А даже если можно, то стоить это будет сильно дороже:
— аналитику поправить ТЗ;
— архитектору придумать, как поправить минимальными усилиями;
— разработчикам внести правки.
Почему на картинке Lee Copeland есть еще Release с самой большой стоимостью?
 |
| Картинка из книги Lee Copeland |
Потому что пока мы на этапе тестирования нашли проблему, то да, придется исправлять много кода, но все же этот код написан в последний месяц (или сколько времени у нас занимает выпуск одной версии продукта).
А вот если мы выпустили версию и уже сделали другую, третью пятую, десятую… А потом нашли баг в самой первой, то на том коде уже столько всего понастроено, в том числе и костылей. Что исправить вашу хочу-шку будет особенно сложно.
Тем не менее такой подход до сих пор используют в больших организациях на сотни человек. Там с требованиями работает один отдел аналитики, потом передают дальше и так по каскаду все приходит в тестирование. С проблемами ошибки в требованиях приходится мириться…
Так что запоминаем: чем раньше найдена ошибка, тем проще ее исправить!
Поэтому тестировщики так важны. Чем раньше они заметят проблемы, тем проще будет их исправить!
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Цена ошибки: кто и сколько платит за промахи программистов?
Современные программисты живут в интересное время, когда программное обеспечение проникает буквально во все сферы жизни человека и начинает существовать в бесчисленном количестве устройств, плотно вошедших в наш обиход. Сейчас уже никого не удивишь программами в холодильниках, часах и кофе-машинах. Однако, параллельно с торжеством удобства растет и зависимость людей от умной техники. Неизбежное последствие: на первый план выходит надежность программного обеспечения. Сложно кого-то напугать взбесившейся кофеваркой, хотя и она может натворить много бед (литры кипящего кофе стекают по вашей белоснежной мраморной столешнице. ). Но мысль о растущих требованиях к качеству ПО важна, поэтому поговорим об ошибках в коде, которые повлекли за собой существенные траты времени и денег.
Цель повествования — борьба с идеей, что к дефектам в программах можно относиться так же пренебрежительно, как и раньше. Теперь ошибки в программах — это не только неправильно нарисованный юнит в игре, сейчас от кода зависит сохранность имущества и здоровье людей. В этой статье я хочу привести несколько новых примеров необходимости трепетного отношения к коду.
Нельзя отрицать, что сложные программы все активнее входят в нашу жизнь: управляемая со смартфона бытовая техника, гаджеты, наделенные таким функционалом, о котором еще 10 лет назад не приходилось и мечтать и, конечно, более сложное ПО на заводах, в автомобилях и т.д. Любая программа создается человеком и, чем она умнее, тем опаснее ее сбой.
Поговорим о деньгах, потерянных из-за ошибок в программном обеспечении, и росте нашей зависимости от программного кода. Тема неоднократно обсуждаемая (в том числе моим коллегой — Андреем Карповым — «Большой Калькулятор выходит из-под контроля»), и каждый новый пример доказывает: качество кода — не то, чем можно пренебрегать.
Космос
Дорогой дефис
Спутник Mariner 1 в 1962 году должен был отправиться к Венере. Стартовав с мыса Канаверал, ракета практически сразу сильно отклонилась от курса, что создало серьезную угрозу падения на землю. Для предотвращения возможной катастрофы NASA было принято решение запустить систему самоуничтожения ракеты. Спустя 293 секунды с момента старта, Mariner 1 был ликвидирован.
Ревизионная комиссия провела расследование, в ходе которого было выявлено: причиной аварии послужила программная ошибка, из-за которой поступали неверные управляющие сигналы.
Программист неправильно перевел написанную формулу в компьютерный код, пропустив макрон или надчёркивание (что значит «n-ое сглаживание значения производной радиуса R по времени»).
Программа даже незначительные изменения скорости воспринимала как весьма существенные и проводила корректировку курса (источник).
Цена «пропущенного дефиса» — 18 млн долларов (на тот момент).
Российский GPS, опустившийся на дно
Ярким примером того, как из-за программной ошибки могут быть потеряны миллионы, является относительно недавний случай. Казалось бы, в 21 веке есть все необходимое для написания надёжных программ, особенно, если речь идет о космической отрасли. Опытные специалисты с отличным образованием, хорошее финансирование, возможность использования лучших инструментов для проверки программного обеспечения. Все это не помогло. 5 декабря 2010 года ракета-носитель «Протон-М» с тремя спутниками «Глонасс-М» — российский аналог GPS, упала в Тихий океан.
Причину аварии, после завершения расследования, озвучил официальный представитель Генпрокуратуры РФ Александр Куренной: «Установлено, что причиной аварии стало применение неверной формулы, в результате чего масса заправленного в бак окислителя разгонного блока жидкого кислорода на 1582 кг превысила максимально допустимую величину, что повлекло выведение ракеты-носителя на незамкнутую орбиту и его падение в акваторию Тихого океана» (источник).
Интересный момент в этой истории — документ о необходимости корректировки формулы был, но его списали как исполненный. Руководство же не удосужилось проверить выполнение своих указаний. Все причастные к аварии лица были привлечены к уголовной ответственности и крупным штрафам. Но это не компенсирует потери, составившие 138 миллионов долларов.
Автомобили
Еще в 2009 году профессор информатики в Техническом университете Мюнхена, эксперт по программному обеспечению в автомобилях Манфред Бра, сказал: «Программное обеспечение автомобиля премиум-класса содержит около 100 миллионов строк кода» (источник). С того момента прошло уже восемь лет, и совсем не обязательно быть поклонником передачи Top Gear, чтобы заметить: современные автомобили — это настоящие интеллектуальные машины.
По заявлению все того же эксперта, стоимость программного обеспечения и электроники в автомобиле составляет порядка 40% от его цены на рынке. И это касается бензиновых моторов, что же говорить о гибридах и электрокарах, где это значение равно примерно 70%!
Когда электронная начинка становится сложнее механической, то возрастает ответственность разработчиков программного обеспечения. Баг в одной из ключевых систем, например, торможения, представляет гораздо большую опасность, чем порвавшийся тормозной шланг.
Садиться за руль современных комфортных и «умных» авто или ездить на олдскульных, но понятных машинах? Решать вам, я же предлагаю небольшую подборку багов в программном обеспечении автомобилей.
И снова Toyota
Японские автомобили Toyota имеют положительную репутацию, но периодически в СМИ попадает информация об отзыве некоторого количества машин. В нашем блоге уже есть статья о программной ошибке в Toyota — «Toyota: 81 514 нарушений в коде», но этот случай, к сожалению, не единичный.
В 2005 году было отозвано 160 тыс. гибридов Toyota Prius 2004 года выпуска и начала 2005. Проблема заключалась в том, что машина могла в любой момент остановиться и заглохнуть. На устранение бага было затрачено около 90 минут на одно транспортное средство или около 240 тыс. человеко-часов.
Chrysler и Volkswagen
В мае 2008 года Chrysler отозвал 24535 автомобилей Jeep Commanders 2006 года выпуска. Причина — программная ошибка в модуле управления автоматической трансмиссией. Сбой приводил к неконтролируемой остановке двигателя.
В июне того же года Volkswagen отзывает около 4000 Passat и 2500 Tiguans. Здесь ошибка в программном обеспечении оказывала воздействие на увеличение оборотов двигателя. Показания тахометра начинали ползти вверх при включенном кондиционере.
Стоит ли говорить о том, что процесс отзыва автомобилей связан с огромными финансовыми затратами. Но для таких крупных компаний-производителей гораздо страшнее не денежные потери, а упадок доверия потребителей. При огромной конкуренции на автомобильном рынке, одна такая оплошность может обернуться очень и очень негативными последствиями. Восстановление репутации надежного производителя — дело нелегкое.
Tesla
Выше речь шла об обычных автомобилях, причем не самых последних годов выпуска. Как видите, даже в них возможны программные ошибки, что уж говорить об активно популяризируемых экологически безопасных электрокарах.
Поговорим, конечно же, о Tesla Model S. 7 мая 2016 Джошуа Браун, прославившийся благодаря своим роликам на YouTube, посвященным восхвалениям электромобиля, попал в автокатастрофу. Он находился за рулем Tesla Model S. Будучи на 100% уверенным в интеллекте машины, он доверился автопилоту. Результат доверия трагичный — от полученных травм Джошуа скончался на месте.
Катастрофа получила широкую огласку. Началось расследование. Удалось установить, что, по всей видимости, Браун самостоятельно не следил за дорогой, а автопилот столкнулся с ситуацией, которая не нашла отражение в его программном коде. Перед Tesla Джошуа двигался грузовик с прицепом. Автомобиль планировал выполнить маневр — левый поворот, соответственно, требовалось сбавить скорость. Но Tesla, едущий позади, не начал тормозить, т.к. системы автопилота не распознали находящийся впереди объект.
Произошло это, скорее всего, из-за яркого солнца. Лучи отражались от прицепа и автопилот воспринял грузовик единым целым с небом. В официальном докладе это объяснялось следующим образом: «Системы автоматического торможения Теслы являются технологией избегания столкновения в редких случаях и не спроектированы для надежного выполнения во всех режимах аварии, включая столкновения в результате пересечения путей» (источник). Полный отчет об аварии находится в свободном доступе.
Иными словами, автопилот призван помогать водителю (более совершенный круиз-контроль, грубо говоря), а не заменять его функции. Конечно, репутацию Tesla такое оправдание не сильно спасло. Работы над совершенствованием программного обеспечения продолжились, но Tesla Model S с дорог отозваны не были.
С одной стороны, такая статистика свидетельствует о том, что электрокар безопаснее, но готовы ли вы доверить свою жизнь, жизнь пассажиров и других участников дорожного движения программе?
И это не риторический вопрос. Судя по новостям биржи, вопреки нашумевшей аварии, акции Tesla выросли на 50% с начала 2017 года. Способствуют этому два значимых фактора: популярность движений, выступающих за улучшение экологии в мире, и высокий личный рейтинг главы Tesla — Илона Маска.
Всеобщий масштаб — Беда 2038 года
Не могла не привести в завершении статьи этот пример. Подробно о Беде 2038 года вы можете прочитать в статье «2038: остался всего 21 год», я же остановлю внимание на одном важном моменте.
Оборудование для заводов: всевозможные станки, конвейеры; бытовая техника и другие сложные агрегаты, оснащенные специализированным программным обеспечением, имеют достаточно продолжительный срок службы. Вероятность того, что выпущенный в 2017 году станок будет функционировать и в 2038 очень и очень велика. Отсюда логично сделать вывод: проблема, когда 32-битные значения типа time_t больше не смогут корректно отображать даты, уже актуальна!
Если сейчас разработчики программного обеспечения не будут брать ее в расчет, то что же ждет программистов в 2038 году?! Есть все шансы на то, что ПО для встроенных систем устроит немало сюрпризов. Но, думаю, мы будем тому свидетелями.
Заключение
Возможно, приведенные в статье примеры покажутся слишком эпичными. Безусловно, широкую огласку получают только трагические случаи. Но я уверена, что в каждой компании, занимающейся разработкой программного обеспечения, есть история о том, как всего одна ошибка повлекла за собой множество проблем, пусть и в локальном масштабе.
Можно ли найти виновного? Иногда да, иногда — нет. Но смысл не в том, чтобы найти крайнего и каким-то образом покарать его. Идея в другом — программы усложняются, они все больше входят в нашу жизнь, а значит и требования к надежности кода растут. Увеличивается цена типовых ошибок, ответственность за качество кода тяжелой ношей ложится на плечи разработчиков.
Какой же выход? Модернизировать процесс разработки. Дать программистам помощников — специальные программы для выявления и устранения ошибок. Комплексное использование современных методик существенно снижает вероятность того, что баг в коде не будет обнаружен на этапе разработки.
Желаю вам не допускать промахов, а вашим проектам никогда не попасть в подборку, аналогичную той, что приведена в этой статье.