Как тестируются программы, от которых зависит жизнь людей?

Недавно появилась статья, чем-то напоминающая много кем известную "Они пишут правильную вещь" (оригинал).

Мне кажутся интересными ряд моментов для передачи свойств предметной области. А вместо их выделения проще привести и перевести все целиком. Ниже мой перевод.

---

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

А никак. Что ставит другой вопрос: как этот тип программ тестируется?

Это было в небольшом посте блога, написанном Gene Spafford, профессором информатики в Purdue University, написанным на волне ответа на этот конкретный вопрос. Он ссылается на историю об истоках кокпитов, где началась применятся проводная связь — такие самолеты управляются в полете электроникой, внедрение чего случилось непосредственно в конце 1980х. Мы уже привыкли к таким самолетам, но тогда это был большой скачок вперед: прямой контроль был убран и передан в руки программного обеспечения, которое было разработано для телеуправления механическими приводами из кокпита. С того момента компьютер мог разбить самолет.

А фактом являлось то, что людей, которые отвечали за компьтеры, поместили непосредственно в тестируемую среду.

Spafford пишет:

В конце 1980х, где-то когда аэробус A340 был представлен (1991), тем из нас, кто работал над разработкой программного обеспечения, критичного к безопасности, рассказывали историю (возможно апокрифическую). Эта история о том, как программное обеспечение электронной авионики тестировалось на основных коммерческих авиалайнерах. Согласно истории, инженеры аэробуса реализовали и верифицировали согласно последним самым сильным формальным методам, предоставляли результаты проверки моделей и формального доказательства всего кода авионики. В то же время, согласно истории, Боинг выполнял обширное тестирование и рецензию кода, и принуждал всех своих инженеров программного обеспечения участвовать в первых полетах самолетов. Основным результатом истории было то, что для большинства из нас (как казалось) было то, что всем нам было более комфортнее лететь на самолете Боинга (было бы интересно посмотреть осталось ли таким же мнение сообщества программистов).

Таким образом, программисты Боинга имели дополнительную мотивацию потому, что им в будущем приходилось отдать свою жизнь в руки своего же программного обеспечения. Там, на высоте 9 000 метров, нет возможности что-то исправить — оно должно просто работать. И с чем вы будете более комфортно чувствовать: имея чей-то личный подход к верификации программного обеспечения (прим. оценка эксперта, рецензия), или, с другой стороны, имея кучу формальных доказательств и результатов имитационных испытаний?

Я бы предпочел и то и другое, но вопрос как тестируется это все интересен сам по себе. Ветка Stack Exchange 2011-го года предоставляет много интересного внутренней кухни данного процесса и его эволюции. Для начала, подход Боинга выходит из моды и в основном вышел из моды, согласно сообщению гуглера Uri Dekel:

Там серьезный шаг вперед в плане формальной верификации по сравнению со случайным функциональным тестированием. Государственные агенства, такие как НАСА и некоторые военные ведомства, тратят больше и больше денег на развитие этих технологий. Решение задач такого уровня все ещё PITA (pain in the ass — боль в заднице) для среднего программиста, но они намного более эффективны в тестировании систем, критичных по безопасности.

Scott Whitlock, инженер-программист, который поддерживает свою библиотеку для автоматического тестирования FluentDwelling, смотрит глубже, разьясняя проектные требования для безопасных трансляторов, являющихся системами промышленного применения для мониторинга оборудования, который передает сигналы предупреждения и может остановить сложное оборудование в случае необходимости. Они включают в себя, согласно Whitlock'y, "Два резервированных процессора, которые обычно запистываются от независимых источников питания, и выполненных конструкционно по-разному. Код, работающий на каждом процессоре, разработан двумя раными командами программистов, выполнивших свою работу в изолорованных друг от друга условиях. Результат вычислений обеих процессоров должен быть одинаков, иначе срабатывает реле безопасности."

"После того, как вы создали свою безопасную систему, то логика её контроля сама по себе может являтся большой проблемой." И Whitlock добавляет: "Программисты часто ломают машины, из-за чего наносится ущерб в тысячи долларов, но в их случаев никто не получает травм."

Но что насчет космического корабля? В терминах критичности, космический корабль приблизительно как самолет, плюс система жизнеобеспечения и плюс сложнейшие математические проблемы аэронавтики.

"Это программное обеспечение никогда не падает" — пишет Charles Fishman. "Оно никогда не требует перезагрузки. Это програмное обеспечение без багов. Оно совершенно настолько, насколько это возможно из всего того, что было создано человеком. Посмотрите на эту статистику: как минимум три версии программы — каждая по 420 000 строк кода, имело только по одной ошибке. Последний 11 версий имели в общей сложности 17 ошибок. Типичные программы на рынке такой сложности будут иметь 5000 ошибок."

Как программисты НАСА все это делают? Ну, в основном им просто приходится. Малейший баг создает риск потери миллиардов доллагоров и жизней людей. И все это под пристальным вниманием публики.

Для кода как такового, идаельность приходит как результат в основном засчет прямой противоположности тому, что обычно ассоциируется под словом "программист". Креативность в команде Шаттла не приветствуется; работа в режиме 9х5; хитрый код и программисты-суперзвезды не приживаются; более половины команды женщины; отладка (debugging) практически отсутствует, так как ошибки являются редчайшим явлением. Программирование стало продуктом не кодеров и инженеров, а Процесса.

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

И далее:

Группа разработки должна предоставить код, который полностью лишен ошибок, настолько идеальным, что тестировщики не должны ничего найти. Группа тестирования должна идти далеко во множестве сценариев полетов и моделирования, и стараются выявить настолько много недостатков, насколько это возможно. Результат — то, что Tom Peterson называет "дружественно-враждебные отношения". "Они соревнутся в том, что найдет ошибки." говорит Keller. "Иногда они дерутся как кошки и собаки. Разработчики хотят поймать все свои ошибки. Верификаторы возмущаются, что это забирает их время, выделенное на проверку программного обеспечения."

Итак, что вы думаете, астронавт будущего? Программист, который летит на орбиту под контролем своего программного обеспечения, или программист из группы НАСА?

Introduction to Astronomy

Прошел Coursera курс по астрономии, теперь есть диплом с отличием.

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

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

Курс для меня оказался объемным. Рассчитывал что нужно будет времени раза в 2-3 меньше. Но вместе с тем, по-моему и в общем, это один из самых хороших курсов на Coursera. Качественные материалы, доступный способ преподнесения, отличные задания (на то, чтобы разораться в предмете) — создают минимальный порог вхождения, подогревают интерес и позволяют самому определить глубину погружения в предмет.

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

Например, теперь знаю, что Галилей открыл первый закон Ньютона; Коперник победил Птолемея не потому что проще или точнее, а потому, что фазы Венеры и спутники Юпитера; как греются и насколько газовые гиганты изнутри; почему на Луне средняя и максимальная температура такая, она определяется физически очень точно и просто; как Юпитер выгнал остальных гигантов на более внешние орбиты; почему двойные и тройные системы важны; почему часы в подвале вашего дома идут не так, как на крыше; кто такой бозон Хиггса и зачем его искали; почему Вселенная практически наверняка плоская, и скорее всего не одна…

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

120 лет жизни — только начало

"120 лет жизни — только начало" — книга Алексея Москалёва (блогоссылка), только приехала с oz.by. Это наверно первая из книг по современной геронтологии, обладающая практическим применением, серьезностью и подтвержденностью изложения, а также не являющейся доступной для понимания обычным людям.

В oz-by варианте уже исправлены многие предыдущие опечатки.

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

По направленности и содержимому в некотором роде книга является русскоязычным аналогом Transcend. Но последний отличается тем, что вышел на 5 лет раньше (а за это время что-то изменилось), а также Transcend более методичен, т.е. многие вещи в нем готовы к использованию, а здесь просто общая информация и свою методику по ней не сделаешь, можно получить только несколько советов.

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

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

Необходимость одного приоритета — три разных причины

Когда появляется две важные задачи, Буриданов осёл начинает судорожно щипать траву…

Мое

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

Первая из них — Буриданов осел. Если у нас две задачи, то мы можем потерять кучу времени и сил на определение того, какую из них нужно раньше делать.

Вторую из них кажется, видел то ли у блоге, то ли на whiteboard Славы Костина. И там была такая картинка:

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

Кроме двух, ещё существует как минимум третья ловушка. Если первая была философско-логическая, а вторая организационная, то эта — психологическо-биологическая. Речь пойдет о т.н. эффекте «смещенная активность». О нем популярно показано тут, непопулярно можно почитать в книжках по дрессировке, а без популярности изложу сейчас сам (;

В любой момент времени у нас есть хотелки что-то сделать. Мотивации. Однако, в некоторых случаях они могут быть ослаблены. Например, если мы не можем определить, что важнее, делать задачу А или задачу Б. В такой момент времени у нас на базовом, нейробиологическом уровне, происходит следующее. Две задачи А и Б начинают бороться за то, чтобы быть выполненными. И, как результат, оказываются истощенными в этой борьбе. Но из-за этого истощения становится более важной и приоритетной задача В, которая в этой ситуации вообще никаким боком не является приоритетной! И картинка превращается в такую:

И человек, вместо того, чтобы заниматься важными А или Б, начинается заниматься фигней В.

Отличительная особенность этой штуки в том, что она прошита у нас на базовом аппаратном уровне, и если её не побеждать сознательно (усилием воли устанавливать один самый важный приоритет), то …

Податливый интеллект

Этот TED подвиг на написание данного сообщения.

Прежде всего речь идет о разнице в подходах к обучению и его оценке (но я бы расширил это понятие). Чаще всего в учебных заведениях по окончанию курса ставится оценка по числовой шкале или зачет/незачет. Здесь же приводится пример того, как учащийся по окончанию, за экзамен или работу получает не «незачтено» или «неуд», а «пока что ещё не сдано» (Not Yet). И особнность в том, что человек может сдать позже с лучшим результатом.

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

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

По ряду экспериментов эти две группы очень разные. Первая стремится получить опыт, узнать что-то новое, openness to experience, они не избегают трудностей. Эти люди вовлечены в процесс, они считают, что их способности могут быть улучшены (их интеллект является податливым), они меньше заботятся о социальном статусе и меньше ищут внешней награды, они подсознательно понимают силу «Not Yet» — находят ошибки, на них учатся, и идут дальше. Вторая же группа в случае трудностей пытается обойти проблему (например списать или подделать), оправдать себя в глазах окружающих (занизить чьи-то достижения), и в своих глазах (поискать кого-то хуже себя и сравнить себя с ним), важна оценка и здесь и сейчас.

Следующая ключевая мысль в том, что воспитывая и организуя процесс по-другому (например переходя к «Not Yet»), большее число людей переходят из второй группы в первую. А нынешняя система и вообще оценки в принципе ведут к повышению процента первой группы.

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

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

Следы и ссылки всех утверждений в TED-ролике и не только можно найти в публикации.

И до кучи ссылка на недавнее исследование, говорящее о том, что интеллект податлив и вполне по определенным причинам.

UPD 2015.02.11: Внезапно активизировался Интернет на эту тему.