Камень в огород Toyota

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

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

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

Источники: статья по теме, отчет экспертов NASA, решение суда.

Комментарии

Казалось бы,

Казалось бы, причем здесь аджайл!

1000 глобальных переменных совсем не похоже на tdd. Про конкретную группу известно, какими практиками они пользовались?

Изображение пользователя Serguei_Tarassov.

Вариантов немного

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

Разработка "от тестов" при наличии четких спецификаций для встроенных систем - это полный нонсенс. Тесты разрабатываются согласно тем же спецификациям, и проверяющая контора (Exponent) вполне удовлетворилась их результатами.
7.8 Test Data/Validation Report Review
Exponent also reviewed the software test reports provided by Toyota as part of the software
analysis. Test documentation reviewed included:
- Modified Condition/Decision Coverage (MC/DC) test reports
- Static test reports including reports generated using the following tools:
-- C-Checker
-- QA-C (A deep flow static analysis tool)
-- CAST
- Dynamic test reports
- Task interference test reports
- Other software reports.
Exponent did not identify any scenario through a review of the test reports that could explain the
alleged incidents of unintended acceleration.

И еще, неплохо бы представляться из вежливости. Мол я - Вася Петров, работаю тыщу лет в аджайле, все проекты успешные. Анонимам - один ответ максимум.

>>>в отличие от

>>>в отличие от пропагандистов "наживульки", не считает нужным распространять некоторые прижившиеся на материальном производстве методики на свое софтостроение

Это значит, что скорее "существует такое проект, в котором не желает распространять...". Чтобы утверждать, что она вообще не считает нужным, надо набрать какую-то статистику проектов. Вы имеете ввиду какого-то конкретного пропагандиста? И какой-то конкретный аджайл? Мне, например, вспоминается книжка Alistair Cockburn где приведен спектр методологий и рассматривается применимость в зависимости от размера команды и типа задач.

>>>Разработка "от тестов" при наличии четких спецификаций для встроенных систем - это полный нонсенс

Почему?

>>>И еще, неплохо бы представляться из вежливости.

Добавил ссылку на linked.in

Изображение пользователя Serguei_Tarassov.

Не желает распространять

Максим, Тойота не желает распространять свои производственные методики, не только на один упомянутый проект, а на все. Принятая в Тойоте методика софтостроения - классический V-цикл, "водопад", распространяющийся на системы вплоть до уровня 10М строк кода, что, по моим понятиям, сильно превышает порог применимости и "водопада", и скрамов-аджайлов.

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

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

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

Прочитал,

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

Итого, если в исходное сообщение добавить эти детали получается. "В Toyota, на которую молятся agile-энтузиасты есть подразделение по разработке встроенного ПО, которое использует водопад и в результате получается опасное для жизни ПО"

Аджайл понятие, кстати, растяжимое. У того же Алистера Кобёрна в книжке приведен спектр методологий, которые применяются в зависимости от размера команды, серьезности потенциальных ошибок и прочее.

>>>Термин "разработка от тестов" при наличии спецификации превращается в бессмысленную игру слов.

Если посмотреть в википедию, термин TDD обычно относится к юнит тестам (мы же говорим о них?). С них не начинается процесс как таковой даже в XP. Если писать тесты до кода, даже если есть спецификация, то можно:
- проверить тесты тем, что они валятся при отсутствии кода
- проверить текущий кусок кода соответствующим тестом без ручного воспроизведения всего окружения
- не выбрасывать весь контекст из головы между моментами написания кода и теста.

Изображение пользователя Serguei_Tarassov.

Нет, не только

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

Если вы листали мою книжку "Софтостроение изнутри", там приведен анти-пример реализации подрядчиком части такой системы (по методе "стыд-и-скрам") со входными спецификациями порядка 2000 страниц, благополучно отложенных в сторонку для периодической фрагментарной сверки. Я не поленился тогда сделать несколько фото. Черненькие листки - это макеты экранов "пользователей"-водителя и пассажиров. Бортовой компьютер (Linux x86/64) управляет даже контактами с мобильного телефона. Разработка ведется на C++/Qt.

    

Собственно, и в статье, которую вы прочли, прямо говорится о системах более 10М строк кода. Это больше, например, чем объем кода тиражируемой ERP-системы для крупного госпиталя. И в отличие от внутренних ERP, CRM и прочих, это ПО критичное, продуктовое, полностью разрабатываемое производителем, являющееся непосредственной частью добавленной стоимости конечной продукции - автомобиля.

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

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

Спиральные методики - это конец 1980-х - середина 1990-х, когда ни о каком XP или скраме никто не слышал. Тем не менее, уже давно существовал MSF и активно продвигался RUP. Если вы полистаете книжку А.М.Вендрова "CASE-технологии." (1997 года), там уже в первых главах описывается спиральный подход. Кокберн и прочие просто пользуются некомпетентностью своих слушателей (и совершенно правильно делают с точки зрения бизнеса). Если Кокберн расширяет понятие, то Microsoft сужает, и предлагает кастрированную версию MSF с пометкой for agile. Каждый зарабатывает в силу своих возможностей.

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

Нет, не только

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

"We had the great honour of meeting Satoshi Ishii, manager of the embedded software division" - я так понял, что они все это называют embedded.

С критичностью и продуктовостью согласен, со словом "предпочитает" не совсем:
"We asked if he was happy with this way of developing. The answer was No. He told us about all kinds of problems they are having, most of them familiar to anyone that has experienced waterfall-style software development"
"He was aware of Agile and liked the ideas, and said they will probably move in that direction."

Плюс еще облом, о котором рассказывается в вашем корневом посте.

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

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

Есть ли научное определение слова agile? Обычно толкования термина ссылаются на манифест, который, скорее про ценности, а не про конкретные практики организации и разработки. Каким научным определением этого слова вы пользуетесь?

Если Кокберн расширяет понятие, то Microsoft сужает, и предлагает кастрированную версию MSF с пометкой for agile. Каждый зарабатывает в силу своих возможностей.

Microsoft в лице своего подразделения Engineering Excelence продвигает аджайл и внутрь.

Ограничивать разработку от тестов тестами модульными - это совершенно неправомерное упрощение ситуации. Возвращаясь к разработке по спецификации, нет нужды покрывать весь код модульными тестами, достаточно ограничиться наиболее сложными/критичными его частями. Ни о каком удвоении объемов за счет модульных тестов речь не идет. Остальное покрывается функциональными тестами согласно закрепленному в спецификации API.

Я упрощаю не ситуацию, а сам термин TDD (есть еще ATDD). Насколько я знаю, весь код вообще никто не рекомендует покрывать кроме некоторых маргиналов. Интересно было бы подробнее узнать о методологии разработки, которой вы занимаетесь и насколько реальность отличается от идеала. Я купил вашу книжку на litres (ссылка на сайт издательства не работает). Надеюсь почерпнуть что-то там и задать тут дополнительные вопросы.

Изображение пользователя Serguei_Tarassov.

ЖЦ разработки

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

Признаюсь честно, до вашего вопроса я её даже не читал, но сейчас, найдя по кросс-ссылке из французской вики, вижу что её авторы придерживаются той же классификации, что использую и я. Как вы можете заметить, итеративный цикл эволюционной разработки (то что сейчас подается, как откровение agile) был предложен еще в 1970 годах, тогда как спиральный - в середине 1980-х. Это должно наводить на определенные мысли.

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

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

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