OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 29 Март, 2024 17:06

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 173 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9  След.
Автор Сообщение
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Воскресенье, 09 Июнь, 2019 22:25 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Пётр Кушнир писал(а):
Зло держится на исполнителях, в любом случае.
Кстати да.

"Банальность зла".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Понедельник, 10 Июнь, 2019 01:33 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Comdiv писал(а):
Так что в итоге? Приборы не подводили и ПО не сбоило?

Все приборы отработали штатно в пределах оговоренных ограничений и режимов.
При выходе за границы допустимых режимов, ЕСТЕСТВЕННО, матмодели выдали фигню, что и отображалось на индикаторах.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Понедельник, 10 Июнь, 2019 11:49 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
А была явная индикация того, что был выход за границы допустимых диапазонов и мат.модели непригодны?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Понедельник, 10 Июнь, 2019 16:39 

Зарегистрирован: Пятница, 11 Январь, 2019 21:33
Сообщения: 88
PSV100 писал(а):
. . . крайне сомнительно, чтобы в тех краях ключевые системы управления кодили напрямую, непосредственно в С/С++.


Немного про "современный тренд" ...

Антон Карев "Программное ядро бортовой киберинфраструктуры унифицированного ударного истребителя F-35":
Цитата:
Некоторые [малочисленные] компоненты программного обеспечения бортовой киберинфраструктуры F-35 написаны на таких реликтовых языках, как Ada, CMS-2Y, FORTRAN. Программные блоки, написанные на Ada – как правило позаимствованы у истребителя F-22. [12] Однако код написанный на этих реликтовых языках, – это лишь небольшая часть программного обеспечения F-35. Основной для F-35 язык программирования – это C/C++.


Цитата:
Одна из первых значительных попыток исключить человеческий фактор из аналитической петли авионики – реализована в киберинфраструктуре истребителя F-22. На борту этого истребителя за качественное склеивание поступающих от всевозможных сенсоров данных, отвечает алгоритмически интенсивная программа, общий размер исходных кодов которой составляет 1,7 миллионов строк. При этом, 90% кода написано на языке Ada. Однако современная система авионики, – управляемая программой ALIS, – которой оснащён истребитель F-35, по сравнению с истребителем F-22 продвинулась значительно вперёд.


Прототипом ALIS послужило программное обеспечение истребителя F-22. Однако за склеивание данных теперь отвечают не 1,7 миллионов строк кода, – а 8,6 миллионов. При этом, подавляющая часть кода написана на C/C++.


Новости ( относительно недавние):

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

Причем после того, как один из японских F-35 упал в море и разбился серьезно заговорили о том, что программное обеспечение F-35A Lightning II и F-22 Raptor могло быть взломано во время обновления.


Другая версия катастрофы основывается на том, что произошла нештатная ситуация с системой генерации кислорода.

Все F-35 имеют бортовые системы генерации кислорода, или OBOGS, которые подают кислород пилоту в высокой концентрации в виде дыхательной смеси, осуществляя забор воздуха. Концентрации должно хватать для работы на больших высотах. ВВС США, ВМС и Корпус морской пехоты используют OBOGS более трех десятилетий в различных моделях, включая F-16 и F/A-18, а также в некоторых учебных самолетах.

Но с тех пор, как США OBOGS была смонтирована на F-22 Raptor в 2008 году, было зафиксировано более 20 случаев, когда пилоты «Раптор» испытывали симптомы, указывающие на недостаток кислорода, по-видимому, из-за проблем с системой. Один из подобных случаев привел к катастрофе F-22A в ноябре 2010 года.

Низкий уровень кислорода в крови, известный как гипоксия, может вызвать потоотделение, головные боли и головокружение, а также проблемы со зрением, проблемы с принятием решений и, в конечном итоге, потерю сознания. После крушения в 2010 году военные США временно прекратили использовать OBOGS на борту F-22 на время, необходимое для работы над решением проблемы и заменой компонентов в системе.

Несмотря на принятые меры, на некоторых используемых моделях проблема осталась — том числе и на F-35A. Военные не выяснили причину, однако, судя по сообщениям в западной прессе, среди других мер предосторожности увеличили аварийную подачу кислорода, предоставляемую пилотам в случае отказа OBOGS. Грубо говоря, вместо отказа от проблемной системы сделано все, чтобы её сохранить.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Понедельник, 10 Июнь, 2019 19:54 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Вспомнилось выступление на тему возникшего здесь "трэша" (и про убийц с менеджерами, и про С++ и т.д.), попробую выделить ключевое (однако, вряд ли получится кратко):
Роберт Мартин: "Будущее программирования" / Robert Martin: "The Future of Programming"
https://infostart.ru/public/975789/
Цитата:
Роберт Мартин - автор книг "Чистый код", "Чистая архитектура", ряда других книг по разработке ПО, один из авторов Agile-манифеста...
[...]
В прошлое, чтобы понять настоящее
[...]
В том же году Алан Тьюринг пишет отчет о проделанной работе, в котором есть примечательные слова: "Нам потребуется большое количество способных математиков, потому что в будущем, вероятно, будет очень много подобной работы". И далее в этом тексте есть слова: "Одной из сложностей, с которой нам предстоит столкнуться, будет поддержание должной дисциплины, чтобы не сбиться с пути и не потерять то, что мы делаем".

Эти примечательные слова были сказаны им буквально после того как он написал первые несколько тысяч строк программного кода. Уже тогда он понимал проблему, с которой нам предстоит столкнуться на протяжении следующих 60-ти лет. Интересно, как он смог догадаться об этом? ))) Способные математики. Большое их число. И должная дисциплина.
[...]
Таким образом количество компьютеров в 1960 году стало порядка 100. От 100 до 900, но порядок был таким. А что можно сказать о программистах? Их было порядка 1000. Потому что в то время на один компьютер приходилось 10-15 программистов.
У нас не было операционных систем, у нас не было функциональных библиотек и фреймворков. Если какой-либо код выполнялся на этих машинах это был код, написанный нами. Чтобы писать такое количество кода нам нужно было много программистов.
Кто же становился программистами в то время? Программистов набирали из инженеров, ученых и математиков. У них были ученые степени. Они имели опыт в своей области и они редко были молоды. Обычно их возраст был 30, 40 , 50 лет. Это были зрелые люди. Они понимали что такое проект, что такое расписание и сроки, они не нуждались в куче менеджмента над собой. Это были люди, которым компании доверяли.
[...]
И к 1965 году количество компьютеров было уже порядка 10 000 , а количество программистов порядка 100 000. Скорее всего их было 200 000 или 300 000. А ведь прошло меньше 20 лет с тех пор, как Тьюринг написал первую строчку кода.

Откуда пришли все эти люди? Точно не из школ. По крайней мере не из компьютерных школ и университетов. Тогда не было компьютерных учебных программ. Инженеров, ученых и математиков уже не хватало и компании собирали лучшие умы там, где могли их найти: бухгалтеры, проектировщики. Среди тех кто имел хоть какой-то технический бэкграунд и мог думать так как думают программисты. И если компании им достаточно доверяли, они могли доверить им и программирование. Происходило кадровое перемещение с их прежних должностей на позиции программистов.

И вновь эти люди были зрелыми, они уже давно были в бизнесе, они понимали бизнес, менеджмент, планирование, дедлайны. Это были не 22-летние дети, вышедшие из школы. И хотя они не были математиками, они были опытными, дисциплинированными профессионалами. И мне кажется Тьюринг одобрил бы это: они и не были математиками, но у них по крайней мере была дисциплина.
[...]
1956 год. Появился LISP. Он был создан Джоном Маккарти для работ по искусственному интеллекту. И этот язык до сих пор отказывается умирать. Мы пытаемся убить его раз за разом, он он возвращается. Я бьюсь об заклад, мы все закончим тем, что будем программировать на LISP )) Потому что остальные языки умирают, а LISP всё время выживает.

И к слову сказать это первый язык для функционального программирования. А ведь мы только недавно начали понимать всю важность функционального программирования. Много лет спустя.
...
Это также был год, когда был создан первый объектно-ориентированный язык Simula-67. Он был создан Оле-Йоханом Далем и Кристеном Нюгором в городе Осло. Мы уже имели функциональное программирование и теперь получили объектно ориентированное программирование.
...
А в 1968 году Дейкстра написал свою знаменитую публикацию, где была обозначена вредоносность оператора GoTo и это было начало революции структурного программирования.

За эти 10 лет мы сделали три главных шага в нашей индустрии - функциональное, структурное и объектно-ориентированное программирование. Они все были сделаны в это время, этими профессионалами.

А вот и Кен Томпсон и Деннис Ритчи. Тот же самый 1968 год. Мы всё ещё в 22 годах от появления первых строк кода. Эти ребята сидят в подвале AT&T и создают язык С и Unix. И это были дисциплинированные математики.
[...]
1970 год. Компания DEC (Digital Equipment Corporation) создает компьютер PDP8 и это был не единственный мини-компьютер того времени. Это была эра, когда все выпускали мини-компьютеры. 50 000 этих PDP8 было лишь вершиной айсберга.

Количество компьютеров было порядка 100 000 , а количество программистов порядка 1 000 000. Миллионы программистов спустя 25 лет с первых строк кода. Снова произошло десятикратное увеличение количества программистов за 5 лет.

Кто были все эти люди?
...
К 1970 году десятки тысяч выпускников CS и EE (Сomputer Science и Electrical Engineering) начали заканчивать школы. Компьютерные курсы можно было пройти в колледжах. В среде выпускников попасть в индустрию ИТ считалось престижным. Конечно в этом они были правы. И эти десятки тысяч выпускников, устремившиеся в ИТ имели кое-что общее. Мы все были юными. И почти все мы были мужчинами. Именно здесь произошел сдвиг. Доминирование мужчин в ИТ началось здесь. Я помню себя в ВУЗе, как я прикасался к компьютеру, телетайпу, подключенному к компьютеру в Технологическом Институте. Почти все кто был рядом были парнями, всего одна или две девчонки.

Когда я пришел на свою первую работу у нас было около 24 программистов и половина из них были женщинами. Это было то место, где я программировал на Коболе. А 10 лет спустя у моего работодателя было 50 программистов. И всего три женщины. Я даже помню их имена, чего не скажешь о всех мужчинах из тех пяти десятков. Подавляющее большинство из нас было мужчинами. Точнее говоря мальчиками.

Чтобы не быть голословным, вот графики, которые впоследствии стали известными. Это количество женщин в различных областях науки. Оранжевая линия - это количество женщин в компьютерных науках. Что-то странное произошло, не так ли? Заметьте этот пик и резкое падение в начале 80-ых.
...
Бизнес нуждался в программистах. И хотя молодым парням не хватало дисциплины, но у них была энергия. Они могли работать сумасшедшее количество часов в день над поставленной задачей. Они были гиперсфокусированы, правда иногда на неправильных вещах )) И они были дёшевы.

Моя первая работа как программиста давала всего лишь 6 900 долларов в год, 570 в месяц. Но для возраста 19 лет это была куча денег. Я даже мог купить машину. Я даже мог съехать от родителей. Это было круто.

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

Какой подход к разработке они использовали?

Если бы мы отправились назад и понаблюдали за ними, то узнали бы в их процессе некую разновидность "Agile". Как говорят, Agile - это то, что дисциплинированные профессионалы используют в дикой природе ))

Мы знаем что разработчики программ для Шаттла работали итерациями длинной в 6 недель. Да, по нынешним меркам это долго, но всё же это интересный факт. Они закрывали каждый цикл разработки каждые 6 недель. Мы знаем что программисты для марсианской капсулы писали юнит-тесты на разработанные модули с утра и добивались их прохождения к вечеру. Это было чем-то похоже на TDD.

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

В 1970 году Уинстон Ройс разработал водопад просто как модель со словами "эй, это не работает". Но похоже что эти слова никто не услышал. Его картинка была взята на вооружение, украдена прямо из его оригинальной публикации и путем копирования-вставки разошлась по документам того времени. Водопад стал процессом, применяемым по умолчанию.

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

Посмотрите на график - экспоненциальный рост. Количество программистов удваивается каждые 5 лет. Мы начинали всего с нескольких, а сейчас их сотни миллионов. И важное следствие из этого - половина программистов имеет менее 5 лет опыта.

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

И это ведет к еще одной удручающей ситуации - у нас не хватает учителей, чтобы учить новичков. Поэтому новички обречены на повторение тех же ошибок, что и их более опытные коллеги. Они обречены набить те же шишки и наступить на те же грабли. Снова и снова и снова. И кажется, что у нас нет лекарства от этого.
[...]
Что еще поменялось помимо “демографической картины” в отрасли? Поменялось железо.
...
Что НЕ изменилось? Вам это не понравится.
Не изменились программы.
...
Если мы и сделали какие-то подвижки в разработке программного обеспечения с 1945 года - это в понимании того, что не следует делать.
Структурное программирование - это о том, что не следует делать. Не использовать опасный GoTo.
Функциональное программирование : не используйте присваивание.
Объектно ориентированное программирование : не используйте указатели на функции.
Что мы узнали за последние 74 года - это больше о том, что не следует делать, чем о том что нужно делать. Искусство написания программ остается в грубом приближении тем же самым, каким оно было в 1945 году, хотя и с налётом современности.

Что же мы должны были поменять? Уровень профессионализма, который мы потеряли из-за потока юных программистов. И уровень дисциплины, большой недостаток которой мы до сих пор испытываем. Старой гвардии, поддерживавшей дисциплину, больше не было в отрасли. Даже первая волна программистов-карьеристов уже шагнула за свои 40 лет. В 1995 году мы уже видели необходимость изменений.
[...]
[...]
[...]
Что же нам нужно изменить в этот раз, спустя 15 лет?

Превое. Мы, как Agile-сообщество, должны повзрослеть. Мы, как программисты, должны определить нашу профессию. Мы должны выбирать наши практики и дисциплины. Быть ли TDD, применять ли парное программирование, непрерывную интеграцию, непрерывное развертывание? Ведь это наши практики! Давайте их применять. Давайте решим, что значит быть программистом. Мы должны вновь объединить мастерство и Agile. И начать вести за собой.

Кому то в любом случае придется быть первыми. Потому что есть большая проблема.

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

Кто нибудь знает сколько строк кода в современной машине? 10 миллионов строк кода. Зная, как создаются программы, это вас не пугает? Конечно не все они управляют двигателем, большая часть сидит в GPS и развлекательных устройствах. Но в современной машине дроссель управляется программным обеспечением. Есть софт, управляющий тормозами и акселераторами. Машина моей жены корректирует поворот руля, если она неправильно паркуется. Сколько людей убивает ПО в автомобилях? Тысячи. Много примеров когда машина таким образом теряла управляемость и разбивалась. Мы убиваем людей. Мы пришли в этот бизнес не для того, чтобы убивать людей, но так получается. И будет только хуже. Наша цивилизация всё больше полагается на нас. Хотя она пока этого не понимает, да и мы тоже.

Сколько из вас видели как СEO североамериканской Volkswagen давал показания перед конгрессом, обвиняя пару разработчиков программного обеспечения в том, что они подделали результаты тестов? "Ооо, это была пара программистов, которые с чего-то накосячили".

А знаете в чем дело? Это действительно была пара программистов. Может быть даже больше. Это они написали тот код, обманывающий тесты. Некоторые программисты так делают:
Код:
Если РежимТестирования Тогда

     Сообщить("Все хорошо"); // никакого намека на модули форм в типовых конфигурациях, все совпадения случайны
     Возврат;

КонецЕсли;

Я даже думаю, что они осознавали, что делают. И в этом проблема. И будет день, когда кто-то из нас напишет программу, которая приведет к интересным газетным заголовкам. Что это может быть за программа? Да что угодно, от софта управляющего самолетом, до софта управляющего футбольным стадионом. Это просто вопрос времени.

Тогда политики начнут делать то, что должны. Они укажут своими пальцами прямо на нас и зададут вопрос "как вы это допустили?" Они не укажут на менеджеров, потому что менеджеры скажут: “Это не мы, это разработчики написали такой софт, мы не знаем почему они так поступили”. И тоже укажут пальцами на нас. И наш ответ "О, мой начальник заставил меня написать такой алгоритм" не прокатит. "О, начальник поставил мне дедлайн". Простите, но нет. Это не сработает.

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

Возможно мы можем этого избежать? Как? Сделав это первыми. Первыми начав регулировать нашу индустрию, как это давно сделали другие отрасли. Создав принципы и этику. Установить базовый уровень морали и дисциплины и отказываться опускаться ниже. Иногда это значит сказать вашему боссу "нет", как это может например сделать врач, давший профессиональную клятву.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Четверг, 13 Июнь, 2019 02:37 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Comdiv писал(а):
А была явная индикация того, что был выход за границы допустимых диапазонов и мат.модели непригодны?

А вот здесь сработала та ситуация, которую я здесь постоянно упоминаю:
"как только заказчик (что - пол-беды") или (не приведи, Господи!) разработчик начинает употреблять выражения, типа:
- такого никогда не будет
или
- вероятность возникновения такой ситуации, практически, равна нулю
... ----> ВСЁ, сливайте воду, сушите весла!"
Употребление таких слов в проекте - самое страшное преступление!
Считалось, что, при разработанном бортовом ПО, "скачкообразно-мгновенного" перехода к вышеописанной ситуации быть, В ПРИНЦИПЕ, не могло. Просто в силу природы и интенсивности протекания физических процессов в системе "самолёт-окружающая среда".
И это имело под собой все основания...
До тех пор, пока самолёт эксплуатировался в штатном режиме. Даже - в тяжелейших метеоусловиях или - при УЖЕ создавшейся аварийной ситуации.
Приборы и начали показывать, что самолёт выходит за пределы допустимых режимов.
Однако сработали три фактора:
- шапкозакидательство и бравада перед потенциальными заказчиками
- погодные условия и неточность определения высоты нижней кромки облачности
- умышленный неучёт показаний приборов, потому, что самолёт сознательно ввели в непредусмотренный режим с выходом за штатный диапазон по куче параметров.

В результате, когда вынырнули из-под нижней кромки облачности и увидели, что земля уже рядом, резко дёрнули ручку на себя. В следствие чего хвостовая часть - просто оторвалась от перегрузки. Причём разрыв произошёл - по заклёпкам. Если бы было Советское Время, то отрыва не произошло бы. Потому, что тогдашние стандарты по заклёпкам из ТОГО металла предусматривали КРАТНЫЙ запас прочности по максимально допустимым нагрузкам. А сегодняшние "эффективные собственники", "оптимизировав расходы", поставили заклёпки с чуть ли не половинной нагрузкой на разрушение...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Четверг, 13 Июнь, 2019 08:32 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
PSV100 писал(а):
попробую выделить ключевое (однако, вряд ли получится кратко)
Вполне адекватно получилось, большое спасибо.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Четверг, 13 Июнь, 2019 08:36 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Wlad писал(а):
сегодняшние "эффективные собственники", "оптимизировав расходы"
выбрали гуано -- потому что гуано много и оно дешёвое.

И это касается всего -- включая программистов и их инструменты.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Четверг, 13 Июнь, 2019 20:52 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Info21 писал(а):
выбрали гуано -- потому что гуано много и оно дешёвое.
И это касается всего -- включая программистов и их инструменты.

Ну-дык, а - что ж вы хотите, Фёдор Васильевич?!
Бег по кругу (вернее - по арене) - уже штатным режимом отрасли стал.
Вы попробуйте прийти куда-нибудь и начать про обероны рассказывать.
Как минимум пальцем у иска покрутят.
Рулит парадигма "ПОСТисправлений".
Во всём.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Четверг, 13 Июнь, 2019 21:58 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Мне-то зачем эти советы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Суббота, 15 Июнь, 2019 01:05 

Зарегистрирован: Среда, 31 Январь, 2018 19:54
Сообщения: 244
Пётр Кушнир писал(а):
Зло держится на исполнителях, в любом случае.

Ещё и на менеджерах
Уинстон Ройс, которому приписывают разработку Waterfall - водопадной системы разработки - пытался, но не смог докричаться, что он не то имел в виду - он говорил об итеративной разработке.

В этой ошибке виноваты менеджеры и ... американские военные, которым был срочно нужен какой-нибудь стандарт, для разработки своего ПО. Потом подключились европейские военные ))) - им тоже был нужен стандарт ...
Подъем и падение "водопада":
https://cartmendum.livejournal.com/44064.html


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Суббота, 15 Июнь, 2019 11:59 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
Джеймс Гордон писал(а):
Английские железные дороги тянулись ровно и прямо через холмистый английский ландшафт благодаря щедрому использованию насыпей, выемок и прекрасных каменных и чугунных виадуков. Вся эта инженерная роскошь определялась наличием средств и рабочих рук, которыми в изобилии располагала викторианская Англия. Совершенно другие условия были в Америке: расстояния были гигантскими, капиталы скудными, зарплата даже неквалифицированных рабочих весьма велика, множество дилетантов, квалифицированные мастера европейского типа были чрезвычайно редки.

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Суббота, 15 Июнь, 2019 13:38 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Спасибо, классная цитата, архивирую.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Понедельник, 17 Июнь, 2019 15:47 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 470
Откуда: Москва
http://bit.ly/2wYauH5
Цитата:
Глава Boeing признал ошибку
в реакции на проблему
с системой предупреждения


Обновлено 17 Июнь, 2019 09:46
Associated Press
Деннис Мюлленбург

Компания не сообщала регуляторам о проблеме, которая позднее привела к двум авиакатастрофам

ПАРИЖ – Глава Boeing заявил, что компания допустила «ошибку», столкнувшись с проблемой в системе предупреждения самолетов 737 Max, которая возникла еще до того, как в результате двух авиакатастроф погибли 346 человек. Деннис Мюленбург пообещал прозрачность в работе компании по возобновлению полетов лайнеров этой серии.

Перед началом Парижского авиасалона исполнительный директор Boeing Мюленбург заявил журналистам, что контакты компании с регуляторами, клиентами и общественностью «были непоследовательными».

«И это неприемлемо», – отметил он.

Федеральное управление гражданской авиации США (ФУГА) обвинило Boeing в том, что компания больше года не сообщала регуляторам о неправильной работе индикатора безопасности в кабине самолета.

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

«Мы допустили явную ошибку с этим оповещением», – заявил Мюленбург.

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

Мюленбург выразил уверенность, что американские и другие регуляторы по всему миру допустят самолеты Boeing 737 Max к полетам до конца года.

По его словам, компания будет работать столько, сколько нужно, чтобы удостовериться в безопасности полетов самолетов этой серии.

Полеты Boeing 737 Max были приостановлены три месяца назад. Регуляторы должны одобрить долгожданные исправления в программном обеспечении, прежде чем самолеты смогут вновь подняться в небо.

Мюленбург назвал аварии самолетов авиакомпаний Lion Air и Ethiopian Airlines «определяющим моментом» для Boeing, но предположил, что результатом этого станет появление «более сильной компании».

В США компания Boeing столкнулась с пристальным вниманием со стороны членов Конгресса и ФУГА по поводу того, как она докладывала о проблеме, связанной с предупреждающим сигналом в кабине.

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

Считается, что крушения самолетов Lion Air в Индонезии в октябре прошлого года и Ethiopian Airlines в марте этого года были вызваны сбоями в работе датчиков измерения угла атаки. Из-за неверной работы датчиков автоматика толкала нос самолета вниз. Пилоты не могли вернуть себе управление самолетами.

Компания сообщила ФУГА о том, что она знала с 2017 года, только после аварии в Индонезии.

Восстановление доверия к самолетам Max является важнейшим приоритетом компании, заявил Мюленбург, – более важным, чем модернизация самолетов серии 777 и работа над будущим дальнемагистральным самолетом NMA.

Max, будучи новейшей версией бестселлера Boeing-737, имеет решающее значение для будущего компании. Эта модель была прямым ответом на экономичный самолет А320neo – один из самых популярных самолетов европейского конкурента Boeing, компании Airbus. Airbus опережает Boeing по продажам в этой категории.

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

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

По его словам, Boeing повысил долгосрочный прогноз глобального спроса на самолеты, особенно в связи с устойчивым ростом в Азии.

По оценкам Boeing, в ближайшие 20 лет авиакомпаниям понадобится 44 тысячи самолетов, а не 43 тысячи, как прогнозировалось ранее.

Мюленбург предположил, что в ближайшие десять лет общий объем авиационного рынка, включая пассажирские, грузовые и военные самолеты, составит 8,7 триллиона долларов, в то время как раньше он оценивался в 8,1 триллиона долларов.

Обе оценки выше, чем аналогичные прогнозы Airbus, который ожидает замедление роста в будущем.

Тем не менее, Airbus появился на Парижском авиасалоне, демонстрируя уверенность. Ожидается, что компания объявит о нескольких контрактах на продажу самолетов и представит дальнемагистральный самолет A321 XLR. Руководство Airbus заявляет, что аварии с самолетами Max не повлияли на стратегию продаж компании, но стали напоминанием для всей отрасли о важности обеспечения безопасности.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Вторник, 18 Июнь, 2019 20:00 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Я не в курсе конкретики, но создаётся впечатление, что в данном случае базовое ключевое в этом (во всяком случае в разрезе моделирования):
Цитата:
В 2017 году компания обнаружила, что предупреждающий сигнал, который должен был оповещать пилотов о возможных сбоях в работе датчиков, измеряющих наклон носа самолета, работал только в том случае, если авиакомпании закупали дополнительную функцию.

Т.е. исходная проблематика в верификации требований в контексте управления вариантами конфигураций архитектуры системы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Вторник, 18 Июнь, 2019 22:23 

Зарегистрирован: Среда, 31 Январь, 2018 19:54
Сообщения: 244
https://www.thesun.co.uk/tech/7814050/n ... -freezing/
Пользователи смарт-термостатов Netatmo замерзли, после того, как термостаты перестали работать. Неисправность была вызвана отключением сервера, что препятствовало пользователям управлять термостатами с помощью смартфонов или веб-сайта компании. Как пояснила компания Netatmo в Twitter, проблемы были вызваны сбоем сервера, что помешало смарт-термостатам и их приложениям соединиться друг с другом, а серверы, которые продолжали работать, не смогли справиться с большим количеством запросов.

Множество пользователей собрались в Twitter, чтобы пожаловаться на то, что их приложения Netatmo не работают, в результате чего они не могут обогреть свои дома. Представители компании ответили, что отсутствие подключения к Интернету не означает, что интеллектуальные термостаты перестают работать полностью, и что люди должны сидеть в своих домах в пальто. Когда серверы не отвечают, интеллектуальный термостат работает так же, как «обычный» термостат, и увеличить или уменьшить температуру можно вручную.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Вторник, 18 Июнь, 2019 22:25 

Зарегистрирован: Среда, 31 Январь, 2018 19:54
Сообщения: 244
https://www.thesun.co.uk/tech/5755746/w ... -echo-dot/

AMAZON'S Alexa пообещала исправить ошибку, из-за которой устройство личного помощника издает «злые» смеющиеся звуки. Торговый гигант заверил пользователей, что они работают над исправлением, чтобы остановить случайный и спонтанный смех.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Среда, 19 Июнь, 2019 09:49 

Зарегистрирован: Среда, 31 Январь, 2018 19:54
Сообщения: 244
По поводу систем управления безопасностью данных:

Цитата:
https://thebell.io/facebook-hranil-sotni-millionov-parolej-v-nezashifrovannom-vide/

" 21 марта 2019 ...Facebook хранил сотни миллионов паролей пользователей в незашифрованном виде, сообщил сайт Krebs on Security и подтвердила сама компания".

Цитата:
https://rtvi.com/news/twitter-poprosil-vsekh-polzovateley-smenit-paroli-v-tselyakh-bezopasnosti/

" 4 Мая 2018 г. ... Сервис микроблогов Twitter посоветовал всем своим больше чем 330 млн пользователям немедленно сменить пароли после того, как разработчики обнаружили ошибку в системе хранения паролей. Об этом компания сообщила вечером 3 мая в корпоративном блоге.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Среда, 19 Июнь, 2019 18:08 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Кардиостимуляторы Medtronic можно взломать удаленно из-за отсутствия проверки цифровых подписей

22 ноября 2018 года появилась информация о том, что дуэт хакеров успешно взломал искусственный водитель сердечного ритма от компании Medtronic. Несложная уязвимость позволяет дистанционно остановить сердце владельца кардиостимулятора, в то время как компания-производитель не спешит реагировать на угрозу и устранять недочёты, пишет Ars Technica.

источник

"Несложная уязвимость". Программисты-убийцы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Суббота, 22 Июнь, 2019 17:12 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Info21 писал(а):
Кардиостимуляторы Medtronic можно взломать удаленно из-за отсутствия проверки цифровых подписей

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

Откуда и получили "качество".

Есть одна очень интересная черта у всех таких "медтроникофф" ТАМ:
(и - пусть меня обвинят в разжигании...) практически все они, или основаны, или потом перекуплены НЕ американцами (в смысле - не "белыми", выходцами с Ближнего и Дальнего Востока и с Индостана).
Там - несколько иная "культура" "ведения бизнеса". Начиная от межличностных отношений в коллективах и заканчивая самими "моделями" ведения рабочих процессов.

Будучи одно время сопричастным к другой тематике Медтроника, я, с самого начала, неимоверно удивился тому количеству работников, которое было на проекте. Штаты были перераздуты, все рабочие процессы - неимоверно заформализованы, забюрокрачены и усложнены, с кучей (форм) документов и этапов их согласований. Из своего опыта предыдущих разработок, я увидел, что там, где могли справиться два-три грамотных/опытных разработчика, у Медтроника пыхтит В СТО РАЗ БОЛЬШЕ человек, с неимоверно худшим результами на выходе. Сопоставляя даже системную архитектуру в другом проекте, могу предположить, что в кардиостимуляторе - не меньший бардак и лажа.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 173 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB