Тогда как случай с Ариан-5 как раз один из описываемых у Аджиева. И как я понял в этом изложении - причина того, что программа гироскопа отказалась чего-то там во что-то преобразовывать, кроется на самом деле в пренебрежениями правилами компоновки системы. Что этот гироскоп с Ариан-4 тупо перенесли в среду новой ракеты, где условия его работы не соответствовали спецификации...
И это как раз в тему сказанного:
...
Ну так вывод то какой (желательно коротко, без ссылок своими словами,...) .
Например, мой - в том случае если будет поставляться с метод. литературой и сделано ""на уровне", пригодно для обучения на начальном этапе программирования и только.
...
Раз уж мой вывод кого-то интересует
- хорошо. Тема ведь стартовала с того, что "вот тут на Коре обозначен поодход, широко практикуемый в ВУЗах страны"... и далее была предложена альтернатива (в основе своей - самообразование через взаимное обучение - топикстартер поправит, если я "отжал" суть неверно).
Так вот. Мне неясно - какие именно особенности того или другого подхода обеспечат формирование специалиста, который не будет пренебрегать свойствами готовых и/или разработанных им компонентов при их включении в систему?
И какие особенности обеспечат, чтобы специалист не игнорировал "принцип двухканальности" построения систем (часто называемый по имени Б.Н. Петрова)?.. А ведь это послужило главной причиной неоднократных убийств по халатности разработчиков (давайте называть вещи своими именами) при помощи Therac-25 (это второй пример из Аджиева)... Точнее, видимая причина - непродуманная логика многозадачного управления рентгеновским излучателем для реализации попременно диагностическоого и лечебного назначений. Однако реальная причина - в том, что контроль суммы параметров, определяющих дозу, был реализован среди других задач в общем контуре управления. Реализация была отработана на предыдущей - 20-й - модели прибора. Но новая модель имела изменения, опять же ставившие блок управления в другие условия (та же ситуация, что с Арианами). А разработчики самонадеянно решили, что это не играет роли...
Тогда как специалисты, адекватные как системотехники, ввели бы для этих жизненно важных параметров отдельный контур контроля (и блокировки) - возможно, не чисто программный, а на "жёсткой" (или микрокодовой) логике. И с продуманной индикацией оператору и логикой восстановления после блокировки... А не занимались бы героическим выявлением дефектов программной логики совмещённого контура... на жизнях пациентов...
В обсуждении я ничего раскрывающего эту тему не увидел - потому и вывод такой... неопределённый...
