Вот такая статья, возможно, известная (курсив мой; спасибо за [url=http://devlab.netne.net/wiki/doku.php/devel/start#методика_разработки_по]ссылку[/url] Роману М.):
...
"Это подобно дошумерской цивилизации," – говорит Брэд Кокс, который написал ПО для компьютера Стива Джобса NeXT и профессор университета имени Джорджа Меэйсона. "Тот способ, которым мы создаем ПО – это эра охотников и собирателей".
Джон Мансон, программист и профессор информатики университета Айдахо еще более категоричен. "Пещерное искусство" – он говорит. "Это примитив. Считается, что мы обучаем компьютер науке. Но здесь нет науки вообще."
Программное обеспечение может быть двигателем для постиндустриального мира, но его создание остается доиндустриальным ремеслом. Согласно исследования SEI, около 70% программистских организаций застряли на первых двух уровнях по шкале SEI: хаос и нечто лучшее, чем хаос. Ситуация настолько тяжелая, что некоторые пионеры программирования ушли из компаний, подобных Микрософт, чтобы преподавать искусство создания ПО.
...
Но это не относится к бортовой группе шаттла. Их рабочие места – это кабинеты, населенные конторскими служащими. Наиболее впечатляет то, насколько заурядно они выглядят. Если не считать небольших памятных вещей с шаттлов, вы можете подумать, что оказались в офисе любой небольшой фирмы или правительственного учреждения. У каждого есть свой небольшой офис, в которых есть доска, персональный компьютер, немногочисленные личные вещи. Люди на работе носят сдержанно элегантные вещи, аккуратные, но не бросающиеся в глаза и, естественно, чистые.
Они работают с 8 до 5 – работа допоздна случается, но это, скорее, исключение. Программисты работают напряженно, но сдержано. Многие из них отдали годы работе либо в IBM (куда входила группа шаттла до 1994 года), либо непосредственно в разработке программного обеспечения для шаттлов. Они взрослые люди, у них есть супруги, дети и личная жизнь помимо их поразительных программ.
...
Другой момент – это порядок, детали и методические повторения. Данное совещание, классическое мероприятие в НАСА – это репетиция практически идентичного совещания, которое произойдет через несколько недель. Оно состоит из прогона невероятных объемов данных и изображений – графы, которые описывают прогресс и состояние программного обеспечения по каждой строке. За исключением Келлеровских лирических отступлений, тон, в целом, деловой, почти формальный, изображения – диаграммы мелькают настолько быстро, насколько они могут восприниматься, смесь из аббревиатур, диаграмм и графиков.
То, что происходит здесь – это основная работа, которая определяет движитель группы к совершенству – движитель, который особенно нетерпим к единоличным решениям. В бортовой группе шаттла нет суперзвезд. Основной подход к разработке ПО умышленно разработан таким образом, чтобы не зависеть от конкретного человека.
Точно также культура не терпит творчества, индивидуальной показухи и признаков классической индустрии ПО. "Люди спрашивают, разве такой процесс не душит творчество? Вы должны делать все в точности так, как говорит руководство, и у вас есть некто, кто заглядывает вам через плечо" – говорит Келлер. "Ответом будет – да, этот процесс действительно душит творчество".
И вот именно в этом все дело – вы не можете позволить людям быть свободными художниками при написании кода, который управляет космическим кораблем вместе с людьми, чьи жизни зависят от этого. Попробуйте-ка исправить такой код, когда он уже на орбите. "Хьюстон, у нас проблемы" – это скорее подходит для хорошего фильма; это недопустимо при написании ПО. "Люди должны направлять свое творчество в изменение самого процесса", – говорит Келлер – "а не в изменение программного обеспечения".
...
Процесс может быть сведен к четырем предложениям:
1. Продукт хорош настолько, насколько хорош план для него.
В бортовой группе шаттла, около трети процесса по написанию ПО происходит до того, как кто-либо напишет хоть одну строку кода. НАСА и группа из Локхид Мартин достигают соглашения в самых подробных описаниях, касательно всего, что новый код должен будет делать – и затем они фиксируют достигнутые договоренности на бумаге с такой скрупулезностью и точностью, которую обычно можно наблюдать при ксерокопировании. Ничто в спецификациях не может быть изменено без согласия и полного понимания с обеих сторон.
...
"Наши требования – это практически псевдокод", говорит Уильям Претт, который руководит этим проектом в НАСА. "Они говорят – вы должны делать именно это, именно таким образом, в данных условиях и при данных обстоятельствах".
...
2. Лучшая работа в команде – это здоровая конкуренция.
В группе разработчиков ПО для шаттла существуют подгруппы и субкультуры. Но то, что в других организациях может быть собственной офисной политикой, здесь является критической частью всего процесса.
Центральная группа разделяется на две ключевые команды: разработчики – люди, которые сидят и пишут код, и проверяющие – люди, которые пытаются найти дефекты в коде. Обе команды отчитываются разным начальникам и имеют прямо противоположные задачи. Группа разработки обязана выпустить абсолютно безошибочный код, настолько безупречный, чтобы тестеры не нашли дефектов вовсе. Группа тестирования обязана истязать этот код при помощи сценариев полета и симуляций, чтобы обнаружить как можно больше дефектов.
...
В результате такой дружеской конкуренции группа шаттла сейчас обнаруживает 85% ошибок до начала формального тестирования, и 99.9% до того, как программа отправляется в НАСА.
...
3. База данных – это фундамент программного обеспечения.
Есть программное обеспечение. Но кроме этого, существуют еще базы данных, две громадных базы данных, энциклопедичных по полноте хранимой информации.
Одна из них – это история, собственно, кода, где каждая строчка снабжена комментарием, говорящим о каждом случае, когда она была изменена, почему она была изменена, когда это произошло, с какой целью это было сделано, какие спецификации описывают это изменение. Все что происходит с программой записывается в этой сводной истории. Родословная каждой строчки кода, для чего и создавалась эта база данных, мгновенно доступна каждому.
Другая база данных – это база данных ошибок, является своего рода памятником тому пути, которым прошла бортовая группа шаттла в своей работе. Здесь содержатся все ошибки, которые были когда-либо допущены при написании или при работе с ПО, на протяжении почти 20 лет. Для каждой ошибки в базе данных хранятся записи о том, когда эта ошибка была обнаружена; какой набор команд привел к ней; кто обнаружил ошибку; на какой стадии ошибка была обнаружена – при тестировании, при тренировке или в полете. Здесь отслеживается как ошибка проявилась в программе; как ошибке удалось просочиться сквозь фильтры на каждой стадии поиска ошибок – почему она не была обнаружена при проектировании? при ревизиях кода? при тестировании? В конечном итоге база данных содержит информацию о том, как ошибка была исправлена и не могли ли подобные ошибки просочиться сквозь эти дыры.
Группа собрала настолько большой объем данных о том, как она работает, что были написаны программы, которые моделируют процесс написания кода. Подобно тому как компьютер моделирует предсказания погоды, модели кодирования предсказывают сколько ошибок следует ожидать при написании каждой новой версии программы. И если разработчики или тестеры находят слишком мало ошибок, то все исследуют процесс до тех пор пока реальность и предсказания не совпадут.
"Мы никогда не пускаем ничего на самотек", – говорит Претти Торнтон, старший менеджер. – "Мы делаем прямо противоположное: мы допускаем, чтобы все нас беспокоило."
4. Мало исправить ошибку – в первую очередь, необходимо исправить все, что позволило этой ошибке случиться.
Процесс является настолько всеобъемлющим, что он оказывается в ответе за каждую ошибку – если есть дефект в программе, значит что-то не в порядке с процессом написания кода, что-то что должно быть исправлено. Любая ошибка, не обнаруженная на стадии планирования, проникла, по крайней мере, сквозь несколько проверок. Почему так случилось? Что-то не в порядке с ревизиями кода? Или в контрольный список следует добавить новый пункт?
Важно заметить, что группа избегает обвинять людей в ошибках. Все обвинения берет на себя процесс – и именно процесс подвергается анализу, чтобы определить как и почему произошла ошибка. В то же время, ответственность является принципом команды: ни один человек не отвечает единолично за написание или ревизию кода. "Вас не будут наказывать за то, что вы допускаете ошибки", – говорит Маджори Сейтер, старший сотрудник технического персонала. "Если я делаю ошибку, а другие проверяют мою работу, значит я не одинок. Меня не будут обвинять в этом."
...
Процесс работает таким образом, что он обнаруживает ошибки не только в ПО. Он обнаруживает ошибки в самом себе.
...
В то время когда остальной мир еще осваивает основы, бортовая группа шаттла постепенно продвигается к совершенному программному обеспечению. Естественно, у них есть масса преимуществ перед остальным миром разработки программного обеспечения. Они разрабатывают всего лишь один продукт: одну программу, которая управляет одним космическим кораблем. Они знают свою программу досконально на протяжении всего времени работы над ней. У группы только один заказчик, причем, весьма разумный. К тому же, деньги здесь не являются ограничивающим фактором: бюджет группы размером в 35 миллионов долларов является незначительным кусочком НАСА’вского пирога, но в пересчете на количество строк кода это делает группу одной из наиболее дорогостоящих организаций по разработке ПО в США.
И еще такой момент: этот процесс настолько исключительный, стремление к совершенству настолько выражено, что это показывает что же необходимо для достижения неизменно высоких результатов. Наиболее важные вещи, которые делает группа шаттла, такие как: тщательное планирование будущего ПО заранее, написание кода только после того, когда завершен процесс проектирования, никаких изменений без изменения соответствующих спецификаций, хранение полной и аккуратной истории кода – не являются дорогостоящими. Это даже не относится исключительно к космической науке. Это стандартные приемы практически в любой инженерной отрасли, за исключением, создания программного обеспечения.
...
Наверное, можно считать основой при подготовке программистов. Сам процесс сформировался в определённых условиях - и в то же время кажется верным замечание, что основные принципы м.б. перенесены и в другие.
В этой связи актуально замечание минских товарищей, что нужно учить в школе и программированию. А также - что нужна учебная телепрограмма...