Набрел на сайт посвященный чернобылю - http://www.chornobyl.ru/
Материал слишком куцый, результат копи-паста из других источников.
После этого почитал статью Внутри и вне Саркофага опубликованную в журнале «Природа» в №11, 1990 год.
Вот это действительно оказалось интересным.
От некоторых цитат волосы встают дыбом.
По расчетам проектировщиков, Саркофаг должен простоять 20-30 лет - а время-то на исходе - 24 года прошло (Строительство завершилось в ноябре 1986 г.).
Если роботы не ломались на старте, они застревали в самых неподходящих местах или вообще отказывались «повиноваться» в мощных полях излучения. Поэтому разведку вели люди...
Разведчикам удалось пройти, проползти, а чаще всего пробежать по многим помещениям блока и установить там постоянные контрольные приборы. - жуть просто, страшно подумать о последствиях для этих людей.
При аварии все барьеры безопасности, предусмотренные создателями реактора, были сразу же разрушены взрывом...- к слову о Качестве разрабатываемых продуктов, что в программировании что в любом другом виде деятельности. Очень красноречивый пример :(
Последняя часть статьи "Будущее Саркофага" создает особенно позитивный настрой (учитывая что По расчетам проектировщиков, Саркофаг должен простоять 20-30 лет):
При обрушении строительных конструкций внутри Саркофага радиоактивная пыль через щели в кровле и стенах (а суммарная площадь таких щелей оценивается в 1000 м2) может выйти наружу.
Однако ясно, что со временем коррозия металлических конструкций, разрушение отдельных бетонных блоков и плит заставят почти беспрерывно вести работы по укреплению отдельных конструкций, расположенных внутри объекта.
В ближайшие годы внешнюю часть Саркофага нужно будет перестроить.
Особенно напрягает то что все это находится в ведении Украины, которая имхо является образцом балагана в последние годы.
По словам вице-премьера Украины, в настоящее время для строительства объекта не хватает 550 млн. евро.
Скинемся?
Да вообще веселуха читать всё, что с этим делом связано. Я когда-то читал мемуары академика Легасова. Поразило то, что даже академик не представлял себе реальных последствий для его собственного организма.
ОтветитьУдалитьС качеством разрабатываемых продуктов все достаточно просто. Вот, по словам академика Легасова, одна из причин появления реактора типа Чернобыльского:
ОтветитьУдалить"Вторым следствием замедления в развитии атомной энергетики послужило то обстоятельство, что мощности по производству, скажем, корпусов для реактора ВВЭР (а это все таки наиболее распространенный в мире тип реактора, и при его сооружении и эксплуатации можно было учитывать не только собственный опыт, но и опыт всего мирового сообщества) у нас не хватало. То есть, не хватало мощности машиностроительных предприятий, что бы в нужном количестве изготавливать корпуса и другое оборудование для реакторов типа ВВЭР.
И в это время часть энергетиков вышла с предложениями: для того, что бы не снижать планы ввода атомных мощностей и, учитывая перегруженность машиностроительной промышленности, создать параллельную веточку в атомной энергетике, которая позволяла бы строить достаточно мощные реакторы, не используя корпусной принцип, не загружая машиностроительную промышленность сложной технологией изготовления высоконадёжных корпусов реакторов, которые требуются при ВВЭР.
Так появилась идея реактора РБМК канального типа с графитовыми блоками и т д. и т д."
Т.е. не было средств и сил делать надежные реакторы. А необходимость в них была. Поэтому было решено идти в сторону более дешовых и простых в производстве, но менее надежных.
В производстве ПО аналогично: выпуск качественного софта будет обходиться намного дороже и требовать больше времени. Поэтому и идут по другому пути.
Действительно, все как в разработке ПО. До боли знакомая ситуация. И что тоже характерно - когда принимаются решения о "параллельных веточках" - никто из тех кто принимает решения в кабенетах не рассматривает всерьез последствия. "Авось пронесет". А когда не проносит - начинают искать козлов отпущения, как будто это может исправить или текущую ситуацию или предупредить такие ситуации в будущем.
ОтветитьУдалить>или предупредить такие ситуации в будущем
ОтветитьУдалитьНу пока в промышленности (машиностроение, строительство, авиация, космонавтика и пр.) как раз эффективно учитывают опыт прошлых катастроф. Этим у них ситуация в лучшую сторону отличается от программирования. У нас же произойдет какой-нибудь баг, найдут его и тихо исправят. Даже толком не расскажут, в чем было дело. И не предложат способов недопущения в будущем.
Я думаю что в этих отраслях не монтеры да слесаря предлагают способы недопущения в будущем. Во всяком случае это не их желание или нежелание. Это работает методика по исправлению и анализу, в которой обязательно существует и анализ, и база знаний и обучение с передачей опыта. В программировании тоже есть такие понятия, методики. Вопрос только в использовании их.
ОтветитьУдалитьАга, есть. Что-то вроде формального доказательства корректности и статического анализа кода. А не используются потому, что:
ОтветитьУдалить- очень дорого;
- очень медленно;
- работает на очень маленьких и сильно специализированных программах.
Например, недавно были опубликованны результата эксперимента в США. Там разрабатывали систему автоматического контроля за электронными замками. На специальной технологии SPARK. Трое человек писали программу из 10K строк 10 месяцев.
Согласен с тем что дорого и медленно. Но цена - говнософт на выходе. Причем заказчик уже не вспомнит что торопил и сам согласился на говнософт.
ОтветитьУдалитьА что касается "работает на маленьких проектах" - то не совсем согласен. Можно довести любую методику до маразма. Но что мешает использовать такие банальные вещи как митинги/семинары как по ходу выполнения проекта так и по его завершении, регулярные митинги внутри команды. Вопрос только в культуре их проведения, в том чтобы разработчики понимали что это нормально - вынести на всеобщее обсуждение вопрос которых их смущает или ошибки которые они допустили. Конечно, это очень сложно - обсудить чужие ошибки так чтобы не задеть ничье самолюбие.
Ну и сразу писать софт который должен будет подвергаться тестированию. Учитывать это в архитектуре. Иначе работы по доказательству корректности работы ПО просто невозможно выполнить за обозримое время.
>А что касается "работает на маленьких проектах" - то не совсем согласен. Можно довести любую методику до маразма.
ОтветитьУдалитьТам дело не в доведении до маразма. А в том, что с увеличением объема программы сумашедшим образом увеличивается количество состояний, возможных переходов между ними и последствий этих переходов. Поэтому для более-менее больших программ эти методы доказательства на работают, просто физически.
>Но что мешает использовать такие банальные вещи как митинги/семинары как по ходу выполнения проекта так и по его завершении, регулярные митинги внутри команды.
Тут уже человеческий фактор :(
Есть, правда, одно средство, которое хорошо работает. Это маленькие команды. Внутри них все лучше коммутируется и отслеживается.
Но это, опять таки дорого обходится. И долго. И тяжело управляемо.