OberonCore

Вычислительная машина 5Э92б: Бессмертная душа "Алдана"
http://www.computerra.ru/vision/644463/

Кстати, то, что Липаев говорит о разработке систем "в малом" и "в большом", коррелирует с определением у Б. Мейера "любительской" и "профессиональной" разработки программ. Что, впрочем, неудивительно - одинаково смотрят как на инженерную деятельность...

Тут есть один тонкий нюанс.

Режим работы не-промышленный является более удобным, "интеллекутальным", а не формальным, и т.п. Т.е. он является часто решением задачи в более чистом виде. Каждый мечтает свести сложность системы к такому порогу, при котором возможно разработать его малой командой (1-3 человека), получить отличную надёжность без спец. организованного контроля качества и т.п.
Но увы, в какой-то момент приходится переходить к промышленному масштабу работы - с резким скачком накладным расходов, уменьшением соотношения думание/рутина и т.п.

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

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

Эта цифра сама по себе ни о чём не говорит. Может у них алгоритмы очень сложные (их очень долго надо придумывать), но строчек занимают мало?

Вон, я однажды за целый месяц упорного труда родил в сухом остатке около 400 строчек на Delphi. То есть около 20 строчек в день. При этом на самом деле каждый день писалось, а потом отправлялось в мусорную корзину несколько сотен строк вспомогательного кода. Решал задачу коммивояжёра.

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

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

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

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