Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 199
Утопично. А вот ввести требования по оценке и сертификации сторонней организацией (как это принято сплошь и рядом в финансовом секторе) могли бы!
Общие критерии оценки безопасности информационных технологий уже разработаны и вовсю применяются на западе. Но, вот оказывается, не везде.
Функциональные требования ОК специфичны и нацелены на защиту информации, а вот требования оценки доверия можно применить в данном случае.
Достаточно выбрать нужный Оценочный Уровень Доверия от 1го до 7го и провести сертификацию в испытательной лаборатории.
Уровень выбирать можно в зависимости от критичности оцениваемой технологии.
Например, прошивка кардиостимулятора — самый жесткий 7 ОУД — вплоть до формальной верификации (благо прошивка обычно невелика по объёму кода).
А какой-нибудь монитор давления, контроллер кнопки вызова медсестры или контроллер управления моторизованной кроватью — уже ОУД послабее, так как прямой угрозы жизни нет.
Функциональные требования ОК специфичны и нацелены на защиту информации, а вот требования оценки доверия можно применить в данном случае.
Достаточно выбрать нужный Оценочный Уровень Доверия от 1го до 7го и провести сертификацию в испытательной лаборатории.
Уровень выбирать можно в зависимости от критичности оцениваемой технологии.
Например, прошивка кардиостимулятора — самый жесткий 7 ОУД — вплоть до формальной верификации (благо прошивка обычно невелика по объёму кода).
А какой-нибудь монитор давления, контроллер кнопки вызова медсестры или контроллер управления моторизованной кроватью — уже ОУД послабее, так как прямой угрозы жизни нет.
Беглый поиск на www.commoncriteriaportal.org показал, что пока разрабатываются только профили защиты для электронных медицинских карт (Common Criteria Protection Profile electronic Health Card (eHC)).
Интересно посмотреть на код наших мед. устройств.
Так я не понял, код ей показали?
никогда не проводит ревью исходного кода, пока с устройством не случится некоторая проблема, которая явно связана с ПО
— Давайте не будем проводить краш-тесты с манекенами, пока реальные люди не пострадают в авариях?
— Okay.
По-моему, варварство какое-то. Если выдаешь сертификат — то будь, блин, уверен в том, что устройство / ПО / etc прошло все тесты и максимальное количество смоделированных критических ситуаций.
— Давайте не будем проводить краш-тесты с манекенами, пока реальные люди не пострадают в авариях?
— Okay.
По-моему, варварство какое-то. Если выдаешь сертификат — то будь, блин, уверен в том, что устройство / ПО / etc прошло все тесты и максимальное количество смоделированных критических ситуаций.
А эта сертифицирующая организация несёт ответственность за сертефиуированное оборудование, или они просто так раздают?
Кто их знает, как там у них.
Хотя, вот эта фраза — Также, FDA, конечно же, не знакомо с аппаратным устройством создаваемой техники на уровне её производителя, а значит именно он (и только он) может решать, как именно должен быть построен софт, какие тесты он должен пройти и когда быть признан годным к уставновке в реальные устройства.
убеждает меня в том, что в случае косяка или ещё чего все претензии от пострадавших FDA будет переадресовывать к производителю, ибо «Это производитель сказал нам, какие тесты должно пройти ПО, мы же сами в этом не рубим нифига, им видней».
То есть, производитель укажет, что ПО должно проходить 3 каких-то простых левых теста, и на основании протокола прохождения этих тестов им дадут сертификат (с указанием пройденных тестов, опять же). А если будет большой косяк ПО из-за факторов, которые не учитывались при тестировании, вот тогда FDA умоет руки.
ИМХО.
Хотя, вот эта фраза — Также, FDA, конечно же, не знакомо с аппаратным устройством создаваемой техники на уровне её производителя, а значит именно он (и только он) может решать, как именно должен быть построен софт, какие тесты он должен пройти и когда быть признан годным к уставновке в реальные устройства.
убеждает меня в том, что в случае косяка или ещё чего все претензии от пострадавших FDA будет переадресовывать к производителю, ибо «Это производитель сказал нам, какие тесты должно пройти ПО, мы же сами в этом не рубим нифига, им видней».
То есть, производитель укажет, что ПО должно проходить 3 каких-то простых левых теста, и на основании протокола прохождения этих тестов им дадут сертификат (с указанием пройденных тестов, опять же). А если будет большой косяк ПО из-за факторов, которые не учитывались при тестировании, вот тогда FDA умоет руки.
ИМХО.
Производитель не заинтересован в трех простых левых тестах, потому что будет возмещать ущерб, а еще рискует нарваться на отзыв всего оборудования и его замену. Легко можно обанкротиться. Значительная часть бюджета в мед. оборудовании как раз и уходит на тесты и проверки, поэтому даже очень простая с виду электроника которую можно собрать на коленке там стоит в разы дороже — гарантия.
А сертификация — это вообше отдельная песня, например соответствие противопожарным нормам, применяемым материалам и т.п. вещи.
А сертификация — это вообше отдельная песня, например соответствие противопожарным нормам, применяемым материалам и т.п. вещи.
т.е. фактически можно сделать так:
собрать на коленке аппарат, нанять китайцев, чтобы они для него написали код. Прогнать пору простых тестов и получить лицензию, навешав лапши на уши. После чего продать пару тысяч экземпляров этого оборудования, окупив, так сказать, затраты и закрывать контору. И даже если и будет иск, то скорее всего после того, как контора будет закрыта?
собрать на коленке аппарат, нанять китайцев, чтобы они для него написали код. Прогнать пору простых тестов и получить лицензию, навешав лапши на уши. После чего продать пару тысяч экземпляров этого оборудования, окупив, так сказать, затраты и закрывать контору. И даже если и будет иск, то скорее всего после того, как контора будет закрыта?
Не пойму, за что вас минусуют, если бы не знать, сколько скандалов проходит в фармацефтической отрасли, в других областях, критичных для жизни (вроде автопрома, или авиастроительства), то можно было бы посчитать, что парни, которые делают медоборудование — милы и никогда не гонятся за прибылью в ущерб интересам больных.
На практике же, обычно, дай производителю возможность сэкономить — он сэкономит. Тут же производителя вообще никто не контролирует.
Насчет страховых выплат и ущерба, вспоминаются слова известного координатора по возврату крупной автокомпании из фильма «Бойцовский клуб»:
«Все сводилось к применению простой формулы… Берем количество выпущенных машин А, умножаем на долю машин с неисправностями B, и умножаем на стоимость урегулирования вопроса без суда С.
А*В*С=Х
Если Х меньше, чем стоимость возврата на доработку — возврата не будет!»
На практике же, обычно, дай производителю возможность сэкономить — он сэкономит. Тут же производителя вообще никто не контролирует.
Насчет страховых выплат и ущерба, вспоминаются слова известного координатора по возврату крупной автокомпании из фильма «Бойцовский клуб»:
«Все сводилось к применению простой формулы… Берем количество выпущенных машин А, умножаем на долю машин с неисправностями B, и умножаем на стоимость урегулирования вопроса без суда С.
А*В*С=Х
Если Х меньше, чем стоимость возврата на доработку — возврата не будет!»
В случае косяка FDA нехило наедет на производителя и кроме потери имиджа еще будут прямые и косвенные многомиллионные убытки. Так что с FDA обычно не шутят и проводят очень хорошее тестирование, особенно оборудование такого класса.
Вообще удивительно, но ревью более менее сложного проекта мало помогает предупреждать баги. Говорю только со свого опыта.
А вот функциональные испытания они проводят.
А вот функциональные испытания они проводят.
Так и представил себе что-то типа
while (true) {
$life=rand(0,100);
//we review this part of the code in next version
if ($life=0) {
die();
}
}
— Роджер, мне кажеться, что посиневший вид 100% пользователей намекает на серьезную проблему…
— Да Кенни, возможно не стоило так глупо путать присваивание и сравнение, исправим.
— Также врачи просили добавить else { // placebo }
— Нет проблем, уже закоммитил, уйдет в следующую партию.
— Ок, тогда текущую отзывать не будем — все текущие пользователи согласились с нашей EULA
— Да Кенни, возможно не стоило так глупо путать присваивание и сравнение, исправим.
— Также врачи просили добавить else { // placebo }
— Нет проблем, уже закоммитил, уйдет в следующую партию.
— Ок, тогда текущую отзывать не будем — все текущие пользователи согласились с нашей EULA
А и вправду было бы интересно почитать код. С одной стороны — ну что тому стимулятору делать — выдавать периодические электрические сигналы на сокращение мышц:
С другой стороны — нужно же как-то реагировать на давление, погоду, нагрузку, изменение возраста и т.д. А главное — на критические случаи сбоев (не здоровым людям же его ставят). Должно быть интересное чтиво.
while (true)
{
GenerateTone();
Sleep(1000);
}
С другой стороны — нужно же как-то реагировать на давление, погоду, нагрузку, изменение возраста и т.д. А главное — на критические случаи сбоев (не здоровым людям же его ставят). Должно быть интересное чтиво.
скрытое обновление кардиостимулятора было признано unstable и отозвано.
А вы жестокий…
Может лучше не всех убивать:
Может лучше не всех убивать:
if ($life==0) {
die();
}
В этом коде «die();» никогда не будет вызвано.
вообще то, в этом коде die() будет вызвано на первой же итерации цикла потому что оператор присваивания возвращает true
у вас баг, красивый:
if ($life=0) {убивать пациента вы будете со 100% шансом.
Все правильно. die() будет если после присваивания в момент проверки гамма квант сменит в памяти 0 на 1. Необычайно редко но реально.
В мед оборудовании я бы хранил каждое значение много раз и постоянно бы проверял целостность данных.
В мед оборудовании я бы хранил каждое значение много раз и постоянно бы проверял целостность данных.
На наши парашюты^W кардиостимуляторы еще никто не жаловался?
Если он всё же увидит код, боюсь сердцу его от этого будет только хуже. Потом жить с таким знанием… :)
Аналогично раньше было с чертежами. И? Были доступны чертежи?..
Да, чертежи доступны. Дома строятся по типовым проектам. Другое дело — до конца ли всё доступно? Правда, если Вы имеете в виду чертежи боевых самолётов, то тут «контент» закрыт на уровне доступа. Но все чертежи и исходный код доступны заказчику, он же пользователь. Пилот, к сожалению, просто очень производительный микроконтроллер.
Абсолютно согласен с Карен. И не считаю её мысль утопичной. Утопичным, скорее, является современное патентное право. Нравится нам это, или нет (я разработчик ПО), но всё идёт к тому, что скоро весь цифровой контент будет «open source». Закрывать «исходники», будь то программа, картинка или идея, полицейскими мерами, глупость несусветная. А сейчас пока просто инерция общества, не успевающего за собственным прогрессом. И потом, все прекрасно понимают, как обходить всевозможные комиссии. И не надо говорить, что только у нас знают как это делается. Думаю, предложение Карен единственно действующее. Плохо, что из-за инерции ещё будут гибнуть люди.
Поделитесь пожалуйста, почему вы думаете, что все идет к тому, весь что цифровой контент будет open source? Какие вы видите тенденции в этом направлении в части фильмов, музыки, ПО?.. Интересует статистика.
Когда по каждому из показателей, по вашей оценке, будет пройдено среднее значение *т.е. 50% всего потребляемого контента/используемого ПО будет OO*?
Очень интересно.
Второй вопрос — про бизнес-модели. Как вы видите модели производства ОО фильмов, музыки, софта?..
Когда по каждому из показателей, по вашей оценке, будет пройдено среднее значение *т.е. 50% всего потребляемого контента/используемого ПО будет OO*?
Очень интересно.
Второй вопрос — про бизнес-модели. Как вы видите модели производства ОО фильмов, музыки, софта?..
У Вас правильные вопросы. И не думайте, что у меня есть ответы. Это не громкие слова, но мы сейчас находимся в состоянии кризиса. Это не катастрофа, и, наверняка, выкрутимся, не впервой. Но все видят, что есть проблема. Этот топик тому подтверждение. Но никто не знает как это решать. Мораль и право всегда чуть отстают от прогресса.
Во второму вопросу могу сказать только вот что. Никогда раньше нельзя было скопировать щелчком пальцев много миллионное изделие. Отрезать щелкающие пальцы не выход. Это и есть кризис. С развитием 3D видео скоро трудно станет отбивать кинопрокатом вложения. И коммерческому кино придётся стать некоммерческим. Только поверьте, мне так же дико это как и вам. Может, это не будет так дико нашим детям. Производдителям цифрового контента придётся искать другие источники финансирования: сервисы, реклама и Бог знает что ещё. Думаю, нам не повезло и мы живём в интересное время.
А вот скоро в массы пойдут 3D-принтеры. И «цифрового» контента станет больше.
Как Вы поняли, у меня нет ответов.
Во второму вопросу могу сказать только вот что. Никогда раньше нельзя было скопировать щелчком пальцев много миллионное изделие. Отрезать щелкающие пальцы не выход. Это и есть кризис. С развитием 3D видео скоро трудно станет отбивать кинопрокатом вложения. И коммерческому кино придётся стать некоммерческим. Только поверьте, мне так же дико это как и вам. Может, это не будет так дико нашим детям. Производдителям цифрового контента придётся искать другие источники финансирования: сервисы, реклама и Бог знает что ещё. Думаю, нам не повезло и мы живём в интересное время.
А вот скоро в массы пойдут 3D-принтеры. И «цифрового» контента станет больше.
Как Вы поняли, у меня нет ответов.
Мне кажется, или Вы сторонник киберпанка?
С другой стороны, когда-то супермаркеты, где вначале берут товары, а потом оплачивают у кассы, тоже были в новинку… )
И одновременно с развитием цифрового контента (а значит увеличением % числа тех, кто участвует в его производстве, и «живет с этого»), будет повышаться сознание людей в части того, что копирование без оплаты близко к тому, чтобы отнимать хлеб у ближнего… (воровством сознательно не называю)
В общем разные есть тенденции, как мне кажется… какая возьмет верх, пока не совсем ясно…
И одновременно с развитием цифрового контента (а значит увеличением % числа тех, кто участвует в его производстве, и «живет с этого»), будет повышаться сознание людей в части того, что копирование без оплаты близко к тому, чтобы отнимать хлеб у ближнего… (воровством сознательно не называю)
В общем разные есть тенденции, как мне кажется… какая возьмет верх, пока не совсем ясно…
Я вот мысль Карен тоже не считаю утопической, а вот Вашу — да. Одно дело выложить в опен-соурс прошивку кардиостимулятора в которой дай Бог кто-то баг найдет и пофиксит, при этом ничем не рискуя (железо то мы никому не отдаём + весь механизм сертификации\тестов\продажи таких девайсов первый встречный не пройдет — так что денег мы не потеряем).
И совсем другое — переходить к мысли «всё всем нахаляву» — вот это утопия.
И совсем другое — переходить к мысли «всё всем нахаляву» — вот это утопия.
Беда в том, что фактически, цифровой контент уже стал «всё всем нахаляву». Это не так только юридически. Это не работает. Но никто не знает что с этим делать. Точнее, как за это взяться. Конечно должен быть механизм сертификации/тестов. Заказчик должен покупать разработку цифрового контента. А исходники так и так будут доступны. Их сейчас всегда можно вытащить и украсть. Идея в том, что продавать надо услугу, или сервис, а не исходники.
Вообще очень много вещей не так только юридически. Например почти все человеческие права.
Кстати например кино может быть бесплатным, а просмотр в кино на качественном дисплее и т.д платно. Музыка бесплатная, а концерты платные. + по сути решает например не то что мы сродни скачать, а то как скачать. Например новые фильмы на торрентах скачать сложно — мало кто раздает. А вот за платную подписку можно предоставлять доступ к серверам на высокой скорости. В итоге видео любого качества любой дорожки и языка онлайн в один клик. Всего например за 500р месяц. По сути как цифровое тв только удобнее. Ну и например доступ с мобильных устройств. Нажал кнопку и смотри на смартфоне сериал дальше в метро.
Интересно, на чём оно? Вдруг на php =)
[irony]ждём портирование android 4.0 на кардиостимулятор![/irony]
Похоже давно пора заводить факультет информационных технологий в каждом медицинском вузе. И хотя бы там внедрять в обучение теорию тестирования. Я знаю, что есть допустим в Новосибирском ГТУ на факультете автоматики и вычислительной техники специализация, которая относится к медицинским устройствам (тяжело там учиться, говорят...) Но медики должны сами тестировать все очень и очень жестко. Я не хотел бы попасть под аппарат, который разрабатывал бакалавр.
По-моему тестированием должны заниматься именно IT-специалисты в сотрудничестве со специалистами, для которых они писали софт.
У нас уже есть экономисты и менеджеры во всех ВУЗах страны, хоть IT-шников оставить мало-мальски профессионалами нужно.
У нас уже есть экономисты и менеджеры во всех ВУЗах страны, хоть IT-шников оставить мало-мальски профессионалами нужно.
Речь не идет о полноценных IT-специалистах, которые готовы написать софтину с нуля. Речь идет о людях, которые подготовлены для решения задач в смежной области, в данном случае между медициной и IT (уж извините — это очень далекие вещи!), поэтому я и предлагаю подготавливать специалистов, которые готовы профессионально (не с точки зрения IT, а с точки зрения медицины) тестировать софт, который был написан профессионалами в сфере IT.
Я имел ввиду, что лучше, чтобы софт тестировали сугубо SQA-специалисты. Такой факультет в медицинском ВУЗе будет малауместным и будет готовить очень узкопрофильных специалистов. Как-то не очень — и не медик и не тестировщик.
Вы знаете, у нас в медицинских вузах готовят педиатров. Так потом из педиатрии можно уйти в любую область, кроме стоматологии и фармацевтики. И большинство учатся на педиатров по причине высокого уровня образования, и потом разбредаются по различным интернатурам и ординатурам. В стоматологии сейчас уже достаточное количество протестированных IT-технологий, в фармацевтике тоже думаю достаточно. А вот во всех остальных областях как-то не всегда, о чем и рассказывает статья (да и комменты). Я соглашусь, что может быть не факультет, а может быть интернатура или ординатура в сфере QA.
По-моему, проще обучить медика тестировать (хотя бы грамотно ставить задачу тестировщику), чем тестировщика обучить медицине (или любой другой специфичной неинженерной предметной области)
FDA — это главный тормоз на пути прогресса в медицинской сфере США. Тем более показательно, что оно при этом не выполняет в полной мере даже свою основную функцию контроля за безопасностью сертифицируемых устройств. Их давно пора разогнать. Вот очередной маразматичный пример запускания FDAрастами своих щупалец даже в пациентов, которые спасаются от дорожающей бюрократии медицинским туризмом за рубеж: www.fightaging.org/archives/2011/12/when-you-make-medical-progress-illegal-what-results-is-a-black-market-in-medical-progress.php
" — А нет ли в коде этого кардиостимулятора ошибок?"
" — Да вы знаете, никто ещё не жаловался!"
" — Да вы знаете, никто ещё не жаловался!"
Будете удивлены, но медицина — это достаточно активно развивающаяся область. FDA можно понять, пока они разработают правила для устройств, на рынке будет уже третье-четвертое поколение этих устройств со совершенно иными требованиями и характеристиками.
Единственный способ это регулировать — жесткая ответсвенность (вплоть до уголовной) за правильность указанных характеристик устройств.
Единственный способ это регулировать — жесткая ответсвенность (вплоть до уголовной) за правильность указанных характеристик устройств.
так зачем тогда такой орган, который свою роль не выполняет под отмазкой «все равно не успеем»?
Почему не делкгировать тестирование оборудования другим лабораториям или ведомствам?
Тут главное не разводить бюрократию. В пример ее избыточности приведу БЕЛаЗ. Завод запросил у нас протокол согласования протокола rs232 over usb с разработчиком этого протокола. Извините за масло масленое. Вот так работать нкльзя.
Но и просто не работать — тоже бред. Тупое отнимание денег.
Почему не делкгировать тестирование оборудования другим лабораториям или ведомствам?
Тут главное не разводить бюрократию. В пример ее избыточности приведу БЕЛаЗ. Завод запросил у нас протокол согласования протокола rs232 over usb с разработчиком этого протокола. Извините за масло масленое. Вот так работать нкльзя.
Но и просто не работать — тоже бред. Тупое отнимание денег.
> так зачем тогда такой орган, который свою роль не выполняет под отмазкой «все равно не успеем»?
Вообще-то выполняет. Лекарства и продукты он проверяет ;)
> Почему не делкгировать тестирование оборудования другим лабораториям или ведомствам?
Так уже делегировал. Тестирование выполняют другие лаборатории, не FDA ;)
> Но и просто не работать — тоже бред. Тупое отнимание денег.
А кто сказал, что они не работают? :)
Вообще-то выполняет. Лекарства и продукты он проверяет ;)
> Почему не делкгировать тестирование оборудования другим лабораториям или ведомствам?
Так уже делегировал. Тестирование выполняют другие лаборатории, не FDA ;)
> Но и просто не работать — тоже бред. Тупое отнимание денег.
А кто сказал, что они не работают? :)
тогда что мы здесь перемалываем впустую?
Не знаю :) Людям не нравится, что FDA доверяет отчетам не своих лабораторий, а отчетам лабораторий производителя
т.е. я был прав, говоря о том, что FDA не занимается делов. Делегирование тестирования не производителю, а сторонней лаборатории — это же логичный шаг, просто необходимый для отлавливания недостатков серьезного оборудования.
вы только представьте себе:«Наши детские игрушки прошли тестирование в нашей лаборатории и мы выяснили, что пары ртути, входящей в состав изделия, никак не влияют на здоровье ребенка».
С мед. оборудованмем то же самое. Глупо доверять тестирование продукта его же разработчику.
вы только представьте себе:«Наши детские игрушки прошли тестирование в нашей лаборатории и мы выяснили, что пары ртути, входящей в состав изделия, никак не влияют на здоровье ребенка».
С мед. оборудованмем то же самое. Глупо доверять тестирование продукта его же разработчику.
> т.е. я был прав, говоря о том, что FDA не занимается делов.
Нет
> Делегирование тестирования не производителю, а сторонней лаборатории — это же логичный шаг, просто необходимый для отлавливания недостатков серьезного оборудования.
Как вы себе представляете этот процесс?
> вы только представьте себе:«Наши детские игрушки прошли тестирование в нашей лаборатории и мы выяснили, что пары ртути, входящей в состав изделия, никак не влияют на здоровье ребенка».
Для этого существуют банальные законы, которые тупо должны работать. Типа:
— уровень ртути и ртутьсодержащих материалов в потребительской продукции
— уровень ртути и ртутьсодержащих материалов в детских игрушках
При наличии законов, которые тупо работают, любой производитель просто не выпустит продукт с указанным выше описанием.
> С мед. оборудованмем то же самое.
Именно. С мед. оборудованием то же самое. Clinical trials стоят диких денег, и их проведение кладется на плечи именно производитля, а не сторонних лабораторий. Для того, чтобы описание соответсвовало содржимому есть толпы аконов, которые просто должны выполняться.
Задача FDA — следить, чтобы лекарства/ища/мед. оборудования проходили все стадии разработи и тестирования прежде, чем попадать на рынок.
Нет
> Делегирование тестирования не производителю, а сторонней лаборатории — это же логичный шаг, просто необходимый для отлавливания недостатков серьезного оборудования.
Как вы себе представляете этот процесс?
> вы только представьте себе:«Наши детские игрушки прошли тестирование в нашей лаборатории и мы выяснили, что пары ртути, входящей в состав изделия, никак не влияют на здоровье ребенка».
Для этого существуют банальные законы, которые тупо должны работать. Типа:
— уровень ртути и ртутьсодержащих материалов в потребительской продукции
— уровень ртути и ртутьсодержащих материалов в детских игрушках
При наличии законов, которые тупо работают, любой производитель просто не выпустит продукт с указанным выше описанием.
> С мед. оборудованмем то же самое.
Именно. С мед. оборудованием то же самое. Clinical trials стоят диких денег, и их проведение кладется на плечи именно производитля, а не сторонних лабораторий. Для того, чтобы описание соответсвовало содржимому есть толпы аконов, которые просто должны выполняться.
Задача FDA — следить, чтобы лекарства/ища/мед. оборудования проходили все стадии разработи и тестирования прежде, чем попадать на рынок.
я просто не понимаю, как избежать подлога? Как понять, а было ли тестирование?
Всю информацию о тестировании сдают в FDA, которая эту информацию (в теории) должна проверить. Безусловно, они проводят и какие-то свои тесты, но точно не все. Дальше все опирается на то, что закон должен работать.
В это сложно поверить в наших странах, но в развитых странах выгоднее не иметь проблем с законом ради сиюминутной выгоды, а иметь выгоды постоянно, соблюдая законы.
В это сложно поверить в наших странах, но в развитых странах выгоднее не иметь проблем с законом ради сиюминутной выгоды, а иметь выгоды постоянно, соблюдая законы.
Лично я за обязательное открытие кода в подобных медицинских устрйствах, так как от анализа бвгов зависят жизни людей.
вопрос не только к вам… скорее так интересно…
открытие кодов какого-то софта реально что ли дает вам возможность найти в нем баги?
ну откроют...200 страниц сишного кода написаного хз кем хз как… и что?
просто вспоминаются фразы которые иногда появляются на всяких линукс конфах на тему того что ну есть у вас код… ну и че вы с ним сделаете? и примеры где долго долго в коде открытом были кейлогеры и тп
мне было бы комфортнее если бы оно прошло какое-либо нормальное тестирование… или его бы верифицировали, к примеру, чем если бы мне дали вместе с соглашением на операцию диск с сорцами
открытие кодов какого-то софта реально что ли дает вам возможность найти в нем баги?
ну откроют...200 страниц сишного кода написаного хз кем хз как… и что?
просто вспоминаются фразы которые иногда появляются на всяких линукс конфах на тему того что ну есть у вас код… ну и че вы с ним сделаете? и примеры где долго долго в коде открытом были кейлогеры и тп
мне было бы комфортнее если бы оно прошло какое-либо нормальное тестирование… или его бы верифицировали, к примеру, чем если бы мне дали вместе с соглашением на операцию диск с сорцами
Если код будет открыт, то возможно сообщества добровольцев подтянутся для корректировки и тестирования данных девайсов. Возможно эти проекты будут объединены в базу, для централизованного анализа. Мечтать не вредно, но это бы упростило даже жизнь производителей мед-оборудования
Хы. Каждому человеку из сообщества выдадут установку, с формулировкой «ня, играйсо, мы потом поглядим». Вы сами верите? Тут конечно же можно возразить, типа «а вот эмулятор же есть», но эмулятор тоже писали люди, он тоже содержит ошибки.
Есть куча областей с открытым кодом: от микроконтроллеров до Линукса. И очень много где помогает совершенствованию сообщества. Я не верю что каждому желающему дадут кардиостимулятор, но я верю что коллектвный разум поможет общему делу. Так было, так есть и так будет. А вы не верите?
Ну вобщем-то верю, но брать ответственность за жизни людей, тестируя код на эмуляторе, я бы не стал.
А не кто и не заставляет. Но помочь делу и найти ошибки — это спасенные жизни.
Мне нечего ответить. Не потому что нечего совсем сказать. Просто я работал в конторе, которая занимается автоматизацией в энергетике под ключ. Если такой софт отправить в open source, то там еще года два не будет прогресса вообще, все будет переписываться-переписываться-переписываться. Ну потому что нечитабельно, отвратительно, но почему-то работает… Да, там утечки памяти, да, люди неделями живут в офисе не вылезая из отладки, но все работает, а рефакторинг прямо сейчас невозможен.
а open source код прям таки верх читабельности…
вспоминается статья «они пишут идеальную вещь»
зы- нам когда-то давно преподаватель по физике говорил «если вы ребята пойдете в ядерную энергетику вы только мне об этом заранее скажите я перееду куда-нибудь подальше..»
вспоминается статья «они пишут идеальную вещь»
зы- нам когда-то давно преподаватель по физике говорил «если вы ребята пойдете в ядерную энергетику вы только мне об этом заранее скажите я перееду куда-нибудь подальше..»
И мне пожалуйста сообщите, если вдруг соберетесь… А то я Вас боюс…
ну кстати open source не верх читабельности, но его можно отлаживать, хотя бы созданием своих юнит-тестов и выковыриванием того, что сильно режет глаз. я занимался подобным творчеством ради жизнедеятельности своего проекта.
Тестирование кода на эмуляторе сообществом может выявить ошибки, которые бы иначе выявились на реальном железе в реальных людях. То что вы, как член сообщества, какую-то ошибку не нашли никакую ответственность на вас не накладывает.
А кто предоставит гарантию того, что эмулятор написан стопроцентно без ошибок?
А такую гарантию на практике никто не даёт, максимум, что проходит тесты с такими-то входными данными и что готовы исправлять ошибки.
То есть Вы легли бы под аппарат, который произведен для осуществления общей хирургии, протестирован на паре десятков тестов, а у Вас так-то общий случай, но операция происходит на мениске? В случае неудачи (ну аппарат там всего-то на пару миллиметров ошибся, какая беда?) вы остаетесь инвалидом на всю жизнь.
При этом Вы же сами были членом сообщества и эту самую операцию тестировали бы на эмуляторе.
Я говорю вообще о разработке ПО. Никто не может дать реальную гарантию, что в софте (и окружении, которое тоже софт) нет ошибок. Могут дать гарантию их исправления и компенсации вреда, не более. Ну, не реально, грубо говоря, проверить корректность даже одной функции с 16-бит параметром, написав ручками 65536 тестов, а главное, безошибочно руками посчитав их результаты, даже если эта функция лишь тупо возвращает параметр.
В космических технологиях реально (NASA тому пример), в военных реально (наши комплексы С-300 и выше), а для граждан — это так, чтобы было? Не согласен.
У NASA или Роскосмоса не было эпик фэйлов из-за ошибок ПО? Вроде как как раз NASA служит хрестоматийным примером о возможном вреде ошибок, даже не логических, а банальных опечаток оператора (кодера в нынешних реалиях). Да и не столь давно (когда уже появилось ООП, автоматические тесты, методики разработки и контроля качества кода и т. п.) им пришлось взорвать самоуничтожить носитель с четырьмя спутниками на борту общей прямой стоимостью чуть ли не порядка миллиарда долларов, плюс вред экологии и т. д.
А разве ПО С-300 гарантирует, что ни при каких условиях им не будет сбит гражданский самолёт, как это было с С-200 на Украине.
А разве ПО С-300 гарантирует, что ни при каких условиях им не будет сбит гражданский самолёт, как это было с С-200 на Украине.
> При этом Вы же сами были членом сообщества и эту самую операцию тестировали бы на эмуляторе.
Ага. Прям так, разбежались. Общество тестирует операцию на мениске в эмуляторе. В обществе внезапно нашлось достаточно количсвто квалифицированных хирургов, чтобы оценить правильность операции?
Ага. Прям так, разбежались. Общество тестирует операцию на мениске в эмуляторе. В обществе внезапно нашлось достаточно количсвто квалифицированных хирургов, чтобы оценить правильность операции?
О том и речь, что нужны специалисты соответствующей квалификации.
Откуда они возьмутся?
То есть вот вам ситуация: открыли код ПО, используемого в хирургичесикх операциях. Дальше что?
То есть вот вам ситуация: открыли код ПО, используемого в хирургичесикх операциях. Дальше что?
Я выше писал, что надо бы уже начать организовывать выпуск специалистов такого профиля на базу медицинских вузов.
> надо бы уже начать организовывать выпуск специалистов такого профиля на базу медицинских вузов.
Какого профиля?
Повторю еще раз.
Для того, чтобы протестировать аппарат/эмулятор, делающий опрацию на мениске, нужен квалифицированный хирург, а не спец. IT широкого профиля.
Для того, чтобы протестировать, скажем, новые MRI, нужна толпа специалитов — нейрохирургов, гематологов, специалистов по тканям и т.д. и т.п.
Открытие кода — не панацея, как ту пытаются ее выставить. Даже при наличии открытого ода никакое сообщество в жизни ничео там не найдет кроме тривиальных ошибок.
Какого профиля?
Повторю еще раз.
Для того, чтобы протестировать аппарат/эмулятор, делающий опрацию на мениске, нужен квалифицированный хирург, а не спец. IT широкого профиля.
Для того, чтобы протестировать, скажем, новые MRI, нужна толпа специалитов — нейрохирургов, гематологов, специалистов по тканям и т.д. и т.п.
Открытие кода — не панацея, как ту пытаются ее выставить. Даже при наличии открытого ода никакое сообщество в жизни ничео там не найдет кроме тривиальных ошибок.
Я говорил не о IT-специалистах с широким медицинским кругозором, а о профильных медиках с полным пониманием QA.
> с полным пониманием QA
Полностью бесполезное знание для >99% врачей. Потому что >99% врачей после университета идут не аппараты разрабатывать, а лечить
Полностью бесполезное знание для >99% врачей. Потому что >99% врачей после университета идут не аппараты разрабатывать, а лечить
Думаете, что для тестирования аппаратов нужно такое же количество выпускников, как на среднестатистическом IT-факультете? Я не думаю, так что менее одного процента выпускников представляется мне вполне нормальной цифрой.
Что касается описанной ситуации — я бы туда не полез, потому что не хочу брать на себя такую ответственность. Однако в разговоре учавствует много людей, которые бы сорви голову понеслись помогать разработчикам ловить баги (ну и конечно же плодить новые).
А откуда внезапно появился эмулятор?
Ну а что, каждому по аппарату выдадут думаете? Нет конечно, эмулятор в лучшем случае.
Вы так и не сказали, откуда появится эмулятор :)
Если отправят на общественную доработку, выпустят и эмулятор. К тому же я почти наверное уверен, что разработчики в фирме-производителе непосредственно с устройством мало работают, скорее больше с эмуляторами.
> Если отправят на общественную доработку, выпустят и эмулятор.
С чего это вдруг? Ах, да, мантра опенсорса: «обязаны выпустить» :)
> К тому же я почти наверное уверен, что разработчики в фирме-производителе непосредственно с устройством мало работают, скорее больше с эмуляторами.
— Это не значит, что они выпустят эмулятор
— Это н значит, что выпущенный эмулятор вообще можно будет завести
Напомнило ситуацию с игровыми приставками. Когда на рынок выходит новая игровая приставка, компания-производитель приставок высылает игроделам не эмуляторы, а полноценные программно-аппаратные комплексы, потому что толку от эмулятора — ноль, особенно если там хитрые процессоры и/или их взаимодействие.
С мед. оборудованием все может быть точно так же.
С чего это вдруг? Ах, да, мантра опенсорса: «обязаны выпустить» :)
> К тому же я почти наверное уверен, что разработчики в фирме-производителе непосредственно с устройством мало работают, скорее больше с эмуляторами.
— Это не значит, что они выпустят эмулятор
— Это н значит, что выпущенный эмулятор вообще можно будет завести
Напомнило ситуацию с игровыми приставками. Когда на рынок выходит новая игровая приставка, компания-производитель приставок высылает игроделам не эмуляторы, а полноценные программно-аппаратные комплексы, потому что толку от эмулятора — ноль, особенно если там хитрые процессоры и/или их взаимодействие.
С мед. оборудованием все может быть точно так же.
Количество игроделов не соответствует количеству желающих поковыряться в открытом коде медицинского аппарата. На всех желающих аппаратов не выпустят. Представьте, что речь идет о рентген-аппарате, думаете каждому вышлют его со свинцовыми труселями в придачу?
> На всех желающих аппаратов не выпустят.
И я о том же.
> Представьте, что речь идет о рентген-аппарате, думаете каждому вышлют его со свинцовыми труселями в придачу?
Ну представьте. Как вы себе представляете эмулятор рентген-аппарата? Кто его будет писать? Где гарантия, что поведение эмулятора на 100% соответсвует поведению реального аппарата?
И я о том же.
> Представьте, что речь идет о рентген-аппарате, думаете каждому вышлют его со свинцовыми труселями в придачу?
Ну представьте. Как вы себе представляете эмулятор рентген-аппарата? Кто его будет писать? Где гарантия, что поведение эмулятора на 100% соответсвует поведению реального аппарата?
О поведении эмулятора я тоже писал выше. Однако же мне пытались доказать, что выправление багов на эмуляторе — это есть хорошо.
Ну вот мы вернулись к сути проблемы :)
Открытие исходного кода ПО не решает никаких проблем вообще. Сказки про сообщество, которое там будет править баги — всего лишь сказки. Может быть, можно будет исправить тривиальные баги (buffer overflow и т.п.) и какие-нибудь достаточно мелкие вещи (вряд ли код кардиостимулятора сложен).
Для всего остального — это сказки. Сложную аппаратуру не протестируешь, потому что нет доступа к реальной аппаратуре, и сложно найти достаточное количество специалистов, которые смогли бы онтролировать работу этой аппаратуры.
Открытие исходного кода ПО не решает никаких проблем вообще. Сказки про сообщество, которое там будет править баги — всего лишь сказки. Может быть, можно будет исправить тривиальные баги (buffer overflow и т.п.) и какие-нибудь достаточно мелкие вещи (вряд ли код кардиостимулятора сложен).
Для всего остального — это сказки. Сложную аппаратуру не протестируешь, потому что нет доступа к реальной аппаратуре, и сложно найти достаточное количество специалистов, которые смогли бы онтролировать работу этой аппаратуры.
кроме того — если код будет открыт, то каждый сможет сказать что-то вроде «кг/ам» и если подобных наберется много, то репутация устройства серьезно упадет.
Я это к вопросу объективности и нечестной конкуренции производителей.
Я это к вопросу объективности и нечестной конкуренции производителей.
Это хорошо еще, если только С-кода, а то ведь там и специфический asm может быть.
Буквально сегодня на работе обсуждали уместность функции assert() в коде кардиостимулятора.
Мне всегда казалось что ассерт — это концепция отладочная. И в Release код подобные проверки не компилируются.
Почему не? Я, обычно, мелкие alloc'и в assert заворачиваю. Если мне 500 байт не выдали, то мне только падать и остаётся. А без проверки можно что-то сломать капитальнее.
Но беседа там была о другом, как себя вести приложению, которое наткнулось на ошибку в входных данных.
Но беседа там была о другом, как себя вести приложению, которое наткнулось на ошибку в входных данных.
Зависит от языка. Если есть препроцессор с макросами, то достаточно легко сделать, чтобы не компилировалось, а вот в языках без такого проще вызывать функцию, которая проверяет параметр конфигурации или в релизе содержит пустое тело, чем синхронизировать отладочный и релизный код.
Так и представляю глаза кардиолога в местной больнице, у которого я попрошу вглянуть на исходники его аппаратуры. Наверное отправил в психотерапевту
> Исследования показывают, что 98% случаев сбоев таких устройств, случающихся по причинам багов в ПО, легко можно было бы избежать при должном уровне тестирования кода.
Какая-то желтизна в статье и в комментариях. Понятно что любые проблемы связанные с ошибками в ПО можно было бы избежать, при должном уровне тестирования, это тафталогия. Не знаю поможет ли чем-то открытые исходные коды, потому как я вижу как много довольно железяк используют люди которые тестируют оборудования связанное с кардиостимуляторами.
Какая-то желтизна в статье и в комментариях. Понятно что любые проблемы связанные с ошибками в ПО можно было бы избежать, при должном уровне тестирования, это тафталогия. Не знаю поможет ли чем-то открытые исходные коды, потому как я вижу как много довольно железяк используют люди которые тестируют оборудования связанное с кардиостимуляторами.
Помнится читал про то, насколько придирчиво подходят к сертификации ПО для авионики. Причины очевидны всем. Представляется странным, что применительно к ПО для обеспечения жизнедеятельности человека, ошибка в котором может стоить жизни, таких процедур контроля нет.
>>Испытывая законное любопытство, Карен спросила, что за программное обеспечение работает в нём и может ли она взглянуть на его код, перед тем, как доверить ему свою жизнь.
Это же симптом!
Это же симптом!
> Мы все знаем, что любое ПО содержит баги. Software Engineering Institute говорит о среднем числе в 1 баг на каждые 100 строк кода.
1 баг на 100 строк??? тут ноликов штуки три не забыли?
более-менее приличная программа просто не запустится при такой плотности багов
да и что считать багом? неправильное поведение алгоритма? это баг
неоптимальное поведение? отсутствие проверок входных данных?
1 баг на 100 строк??? тут ноликов штуки три не забыли?
более-менее приличная программа просто не запустится при такой плотности багов
да и что считать багом? неправильное поведение алгоритма? это баг
неоптимальное поведение? отсутствие проверок входных данных?
Видимо речь идет о статистической наблюдении. Т.е. если ваша программ больше 100 строк, есть высокая вероятность того, что в ней есть хотя бы один баг. Если программа занимает больше 1 млн строк, есть высокая вероятность, что в ней по меньше мере обнаружится 1000 багов. Если заглянуть в трекер любого крупного проекта, то видно, что это повседневная и еще не самая плохая картина.
Багом в общем случае считается любое поведение программы не соответствующее ожидаемому.
да и что считать багом? неправильное поведение алгоритма? это баг
неоптимальное поведение? отсутствие проверок входных данных?
Багом в общем случае считается любое поведение программы не соответствующее ожидаемому.
Я думаю даже не 1 на 100, а ближе к 1 на 20 строчек.
И прекрасно всё запускается.
Под багом имелся в виду наверное дефект. А дефект — как верно сказал тов. sdramare — это поведение не соотвествующее ожидаемому.
Почитайте Макконела — Идеальный код. Вы судя по всему с классикой вообще не знакомы.
И прекрасно всё запускается.
Под багом имелся в виду наверное дефект. А дефект — как верно сказал тов. sdramare — это поведение не соотвествующее ожидаемому.
Почитайте Макконела — Идеальный код. Вы судя по всему с классикой вообще не знакомы.
Карен однозначно права. Мне не совсем понятно, почему она решила ограничиться требованием исходных кодов только кардиостимулятора? Ведь когда она летает на самолёте, то она тоже доверяет свою жизнь программе, написанной неизвестными ей людьми, и она имеет законное право ознакомиться с кодом такой программы, поскольку от этой программы зависит её жизнь? А код системы управления лифтами? Управления системой пожаротушения в её офисе и в её кондоминимуме? Она должа лично проверить весь код, от которого зависит её жизнь, включая прошивку её автомобиля.
От прошивок автомобилей уже зависит жизнь водителя и пассажиров?
Конечно. Например в современных автомобилях даже гидроусилитель руля может управляться с контроллера. Представьте, что на скорости в 100км контроллер сойдет с ума и повернет руль резко влево.
По-моему, название «гидроусилитель» исключает использование даже аналоговой электроники в цепи управления. Плюс, не так давно ехал на машине без генератора, так она после отрубления всех систем, включая бортовой компьютер, всё же ехала, хотя по словам водителя руль крутить стало намного тяжелее, но всё же возможно. По крайней мере свернуть с проспекта на площадь и нормально припарковаться на стоянке мы смогли.
Нет, вы не совсем правы. Современные системы с гидроусилителем делают с контроллером для изменения уровня усилий в зависимости от скорости. Например SPSS, которая используются на тех же сузуки или шевроле. Например вот.
Значит мои данные устарели, я автопромом особо не интересуюсь, только как потребитель услуг, предоставляемых владельцем их продукции.
Почитайте про приусы которые управляются как самолеты — всем рулит компьютер, человек котолько направление указывает. И про машины которые сами паркуются тоже почитайте :)
«В декабре 2009 года, когда скандал вокруг Toyota только разгорался, журнал Consumer Reports изучил все зарегистрированные случаи непреднамеренного ускорения с участием машин 2008 модельного года в США. Всего таких случаев было зафиксировано 166, в том числе 128 — до истории с офицером Сэйлором.
Из этих 128 в 47 случаях ускорялись автомобили Toyota, в пяти — Lexus, что в сумме дает 41% от общего числа.
36 жалоб поступило на автомобили Ford, преимущественно на пикап F-150,
11 — на Chrysler,
7 — на модели General Motors,
5 — на Honda,
3— на Nissan.»
В некоторых случаях было виновато устройство механики педального узла, но так как в большинстве автомобилей педаль — т.н. "электронная", то в конце концов всё упирается в прошивку соответствующего контроллера.
В любом деле важно ДОВЕРИЕ к софту, который там используется.
Критерии доверия могут быть разные, но их число не бесконечно.
Их можно классифицировать, ранжировать и оценивать.
Первые шаги уже делаются — например, Общие критерии оценки безопасности информационных технологий.
Из этих 128 в 47 случаях ускорялись автомобили Toyota, в пяти — Lexus, что в сумме дает 41% от общего числа.
36 жалоб поступило на автомобили Ford, преимущественно на пикап F-150,
11 — на Chrysler,
7 — на модели General Motors,
5 — на Honda,
3— на Nissan.»
В некоторых случаях было виновато устройство механики педального узла, но так как в большинстве автомобилей педаль — т.н. "электронная", то в конце концов всё упирается в прошивку соответствующего контроллера.
В любом деле важно ДОВЕРИЕ к софту, который там используется.
Критерии доверия могут быть разные, но их число не бесконечно.
Их можно классифицировать, ранжировать и оценивать.
Первые шаги уже делаются — например, Общие критерии оценки безопасности информационных технологий.
В том же приусе, насколько знаю, не гидро, а электроусилитель.
Кстати, о вопросе интеллектуальной собственности кода для электронных органов вспоминается фильм
ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%82%D1%80%D0%BE%D1%88%D0%B8%D1%82%D0%B5%D0%BB%D0%B8
ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%82%D1%80%D0%BE%D1%88%D0%B8%D1%82%D0%B5%D0%BB%D0%B8
Почитав комменты, я задался вопросом: а что же делать людям, которые в исходном коде вообще не смыслят ничего? Может быть это рождение новой профессии? Типа «программист-страховщик(юрист)», то есть в случае чего программист берет исходный код аппарата и обеспечивает доказательную базу в суде, что в инвалидности (смерти) пациента виновато недостаточно протестированное ПО. Profit!
«Виноватость» ПО не означает виноватости фирмы-производителя и, тем более, конкретных физических лиц, если законом или договором такая «виноватость» явно не предусмотрена (и не является ничтожной в случае договора). Только в случае если ПО стоит на источниках повышенной опасности, потерпевший может рассчитывать на гражданскую ответственность владельца/продавца, а вот перспективы владельца удовлетворить регрессивный иск к производителю софта призрачны, если софт поставляется 'AS IS', как оно обычно и бывает.
«В США живёт 4% мирового населения и 50% мирового запаса юристов!» (С)
Логично предположить, что эта профессия появится в первую очередь там.
Если страховая компания выплатит страховые премии пострадавшим, а потом захочет возместить их за счёт компании-производителя, то они гарантированно найдут соответствующих специалистов. Даже не надо их в штат брать: "-Ну что, построишь летучий корабль? -Куплю!" ( (С) «Летучий корабль», диалог царя с Полканом)
Достаточно правильно поставить задачу фирме, специализирующейся на аудите кода.
Если при сертификации деньги в основном платятся за положительный результат, т.е. за ненахождение ошибок, то в данном случае — за найденные дефекты. А уж хотя-бы одна ошибка в программе всегда есть.
Логично предположить, что эта профессия появится в первую очередь там.
Если страховая компания выплатит страховые премии пострадавшим, а потом захочет возместить их за счёт компании-производителя, то они гарантированно найдут соответствующих специалистов. Даже не надо их в штат брать: "-Ну что, построишь летучий корабль? -Куплю!" ( (С) «Летучий корабль», диалог царя с Полканом)
Достаточно правильно поставить задачу фирме, специализирующейся на аудите кода.
Если при сертификации деньги в основном платятся за положительный результат, т.е. за ненахождение ошибок, то в данном случае — за найденные дефекты. А уж хотя-бы одна ошибка в программе всегда есть.
> Исследования показывают, что 98% случаев сбоев таких устройств, случающихся по причинам багов в ПО, легко можно было бы избежать при должном уровне тестирования кода
Это легко говорить в ретроспективе. Я думаю комании, производящие кардиостимуляторы понимают, что даже с точки зрения бизнеса у них будет много проблем после смерти пациента, поэтому следят за качеством кода. Просто потому что это выгодно. Ну и сами люди которые пишут код, в большинстве своём наверное тоже осознают ответственность.
Да и что-то не припомню, чтобы где-то были сообщения о смерти из-за кардиостимулятора.
Это легко говорить в ретроспективе. Я думаю комании, производящие кардиостимуляторы понимают, что даже с точки зрения бизнеса у них будет много проблем после смерти пациента, поэтому следят за качеством кода. Просто потому что это выгодно. Ну и сами люди которые пишут код, в большинстве своём наверное тоже осознают ответственность.
Да и что-то не припомню, чтобы где-то были сообщения о смерти из-за кардиостимулятора.
При всем огромном уважении к GNOME Foundation, какое дело Карен до ПО в стимуляторах, светофорах и стиральных машинах? Кто ее поймет вообще?! Какой код, о чем вы говорите, барышня? Есть прибор, тут надо нажать на кнопку, положить/вшить сюда, так как это предписано инструкциями производителя и подтверждено клиническими испытаниями. Это единое устройство, а не DIY с дебаггером! Ни сам производитель (сверх отдела R&D), ни FDA, занимающаяся тестированием прибора относительно заявленных параметров, ни тем более врачи не имеют дело с кодом. Что за дурацкие попытки связать цельное embedded устройство с опенсорсным чисто софтверным проектом? Прям воротит от таких медиа-поводов, честное слово. Микрокодами аппаратов для измерения давления она не интересовалась? ПО рентгеновских установок? Ультрасаунда? Системы выдачи номеров в очереди в поликлинике?
Отдельно отмечу мешанину из добровольного, энтузиастского (и не без багов, сказать по правде) проекта и совершенно других дисциплин и методик создания продуктов. На другом уровне и очень другой стоимости. Не верю, чтобы Карен никогда не слышала про 100% code coverage. А вот журналисты вполне могли и не слышать. Пусть фантазируют дальше, чо. «Во время установки стимулятора Карен плодотворно обсудила с кардиохирургом вопросы юнит-тестов и общие проблемы движения Open Source. Присутствовавшая на процедуре медсестра доложила о ситуации с code review...».
Отдельно отмечу мешанину из добровольного, энтузиастского (и не без багов, сказать по правде) проекта и совершенно других дисциплин и методик создания продуктов. На другом уровне и очень другой стоимости. Не верю, чтобы Карен никогда не слышала про 100% code coverage. А вот журналисты вполне могли и не слышать. Пусть фантазируют дальше, чо. «Во время установки стимулятора Карен плодотворно обсудила с кардиохирургом вопросы юнит-тестов и общие проблемы движения Open Source. Присутствовавшая на процедуре медсестра доложила о ситуации с code review...».
100% code coverage не гарантирует отсутствие ошибок (поведения ПО не соответствующее ожидаемому). Гарантировать может, наверное, только 100%*разрядность данных*длину данных, в общем по комбинаторике число всех возможных вариантов входных данных с вручную и без ошибок посчитанным ожидаемым выходом, что, естественно, не реально.
Про отсутствие ошибок речи не идет, конечно же. Но тестируют и сертифицируют такие вещи годами, с обязательным фидбеком и тщательным разбором каждой нештатной ситуации. Это очень долго и очень дорого. Другая область совсем, другая вселенная. С Gnome — ну никак не пересекается по методологии. Удивительно, что с журналистской точки зрения дама не поинтересовалась статистикой случаев нанесенного стимуляторами вреда (что сделал бы любой нормальный пациент: какие у меня риски?), не спросила про надежность и сертификацию батареи (что в стимуляторе чуть ли не главная вещь), а якобы озаботилась… программным обеспечением. WTF?
Некоторые вещи тестируют на живых людях, так называемые «клинические испытания». И далеко не всегда они длятся годами (после релиза, «бета-тесты» не имеются в виду). Я сам участвовал в разработке медицинских аппаратно-программных комплексов (PC+датчики+АЦП+софт) именно в качестве разработчика «прошивок». Возможно, что из-за моих багов погибли люди, которые не должны были погибнуть, если бы я не ошибался (софт не распознал кризисную ситуацию). Меня успокаивает лишь то, что без этого софта погибли бы не только они (для кого-то он распознал). Активного воздействия как в кардиостимуляторах у нас не было, лишь мониторинг и «алярмы» для медперсонала и потому ошибки второго рода для нас были не важны. Плюс данные для диагностики конечно же, но диагноз не ставили и даже не предполагали, просто информация для врача, которую традиционными способами получить затруднительно. Корреляцию между спектром сигнала и возможным диагнозом врач проводил сам на основании своего опыта и данных наблюдения конкретного пациента, имея лишь информацию, что некоторые сердечно-сосудистые заболевания проявляются в этом спектре с достаточно высоким, но не равным единице, коэффициентом корреляции. Особенно их (заболеваний) обострение.
В чём компетентна, тем и озаботилась. Что она сделала не так?
Некоторые вещи тестируют на живых людях, так называемые «клинические испытания»
Ну при чем тут это. Мой пост не о медицине совсем был, а о том, что кто-то поинтересовался совсем не тем, совершенно не там и абсолютно не у тех.
В чём компетентна, тем и озаботилась
Вы, если в электронике разбираетесь, тоже в магазине интересуетесь принципиальной схемой телевизора у продавца? И у того будут смущенные взгляды и переводы стрелок? Вас тупо не поймут. Можете минусовать дальше, но «новость» желтая и тупая до ужаса. Недостойная «новость».
Ну при чем тут это. Мой пост не о медицине совсем был, а о том, что кто-то поинтересовался совсем не тем, совершенно не там и абсолютно не у тех.
В чём компетентна, тем и озаботилась
Вы, если в электронике разбираетесь, тоже в магазине интересуетесь принципиальной схемой телевизора у продавца? И у того будут смущенные взгляды и переводы стрелок? Вас тупо не поймут. Можете минусовать дальше, но «новость» желтая и тупая до ужаса. Недостойная «новость».
>ПО рентгеновских установок?
Между прочим, и зря не интересовалась. Один из самых больших epic fail в истории программирования связан как-раз таки с переполнением буфера в ПО рентген-аппарата. Погибло что-то около десятка людей, еще многие получили травмы. Погуглите, если интересно. Если бы его софт был открытым — всегда бы нашлись желающие в нём покопаться и с некоторым отличным от нуля шансом, нашли бы этот баг.
Между прочим, и зря не интересовалась. Один из самых больших epic fail в истории программирования связан как-раз таки с переполнением буфера в ПО рентген-аппарата. Погибло что-то около десятка людей, еще многие получили травмы. Погуглите, если интересно. Если бы его софт был открытым — всегда бы нашлись желающие в нём покопаться и с некоторым отличным от нуля шансом, нашли бы этот баг.
Один из самых больших epic fail в истории программирования
Это был не fail в истории программирования, а нарушение протокола. Работа не по инструкции. Врачебная ошибка.
Если бы его софт был открытым — всегда бы нашлись желающие в нём покопаться
Извините, не верю. Копаться надо не в коде, а в целом продукте, вместе с самой рентгеновской установкой. Это диаметрально разные области и подходы.
Это был не fail в истории программирования, а нарушение протокола. Работа не по инструкции. Врачебная ошибка.
Если бы его софт был открытым — всегда бы нашлись желающие в нём покопаться
Извините, не верю. Копаться надо не в коде, а в целом продукте, вместе с самой рентгеновской установкой. Это диаметрально разные области и подходы.
>Это был не fail в истории программирования, а нарушение протокола
Вот смотрите, три цитаты:
«Одна и та же переменная применялась как для анализа введённых чисел, так и для определения положения поворотного круга. Поэтому при быстром вводе Therac мог иметь дело с неправильным положением поворотного круга (так называемое состояние гонки).»
«Деление на величину излучения, приводящее в некоторых случаях к ошибке деления на ноль и соотвественное увеличение величины облучения до максимально возможной.»
«Установка булевской переменной (однобайтовой) в значение «истина» производилось командой «x=x+1». Поэтому с вероятностью 1/256 при нажатии кнопки «Set» программа могла не пропустить информацию о некорректном положении диска.»
Такие вещи как реюз одной переменной для двух задач, деление на ноль и неверная работа с булевским типом за нефиг делать находятся: руками, статическим анализом, code review, тестами и кучей других методов.
В чём тут ошибка врачей? Почему Вы считаете, что для нахождения этих ошибок необходимо железо?
Вот смотрите, три цитаты:
«Одна и та же переменная применялась как для анализа введённых чисел, так и для определения положения поворотного круга. Поэтому при быстром вводе Therac мог иметь дело с неправильным положением поворотного круга (так называемое состояние гонки).»
«Деление на величину излучения, приводящее в некоторых случаях к ошибке деления на ноль и соотвественное увеличение величины облучения до максимально возможной.»
«Установка булевской переменной (однобайтовой) в значение «истина» производилось командой «x=x+1». Поэтому с вероятностью 1/256 при нажатии кнопки «Set» программа могла не пропустить информацию о некорректном положении диска.»
Такие вещи как реюз одной переменной для двух задач, деление на ноль и неверная работа с булевским типом за нефиг делать находятся: руками, статическим анализом, code review, тестами и кучей других методов.
В чём тут ошибка врачей? Почему Вы считаете, что для нахождения этих ошибок необходимо железо?
Ошибка врачей была в панамском случае: они нарушали инструкцию. Но мы постоянно скатываемся в частности, а я этого не хочу. Я говорил о принципе. Не дело оперсорсного проекта приходить со своим уставом в чужой монастырь. Она бы еще посоветовала производителям медоборудования «release early, release often». Это разные миры совершенно, не хуже и не лучше, просто разные. Какие «руками», какие code review, там каждое изменение (образно говоря) — это годы тестов, миллионы долларов сертификаций и тысячи часов обучения персонала. Как вообще чисто софтверный и некритичный проект с «nightly builds» и изменениями версий с 0.0.1 до 0.0.2 переносить какой-либо knowledge на другую область, где девелопмент — 0.1% от всего дела, а совфтерная его часть и того меньше?
Вот этот hype, надоедливые желтые лозунги «был бы открытый код, то кардиостимуляторы, Windows, чего-угодно еще УХ, как заработали б!», да еще и поданное жареным фактом (вы когда у врачей последний раз кодом интересовались?), раздражают неимоверно. И главное кто, гномовцы! «И эти люди запрещают мне ковыряться в носу (С)».
Вот этот hype, надоедливые желтые лозунги «был бы открытый код, то кардиостимуляторы, Windows, чего-угодно еще УХ, как заработали б!», да еще и поданное жареным фактом (вы когда у врачей последний раз кодом интересовались?), раздражают неимоверно. И главное кто, гномовцы! «И эти люди запрещают мне ковыряться в носу (С)».
>Но мы постоянно скатываемся в частности, а я этого не хочу. Я говорил о принципе.
Нет уж подождите, на Ваше замечание о том, что ошибки в софте такого рода ПРИНЦИПИАЛЬНО недетектируемы без железа и кучи дополнительных вещей, недоступных обычному человеку, я привел 3 примера, когда такие ошибки вполне могли бы быть найдены именно таким вот образом. У Вас есть какой-то контраргумент, почему ошибки «bool x=x+1» и «int a=0;… c = b/a» не могли быть найдены читателями кода, если бы он был выложен в opensource? Нету. А значит всех тех людей потенциально можно было спасти.
Нет уж подождите, на Ваше замечание о том, что ошибки в софте такого рода ПРИНЦИПИАЛЬНО недетектируемы без железа и кучи дополнительных вещей, недоступных обычному человеку, я привел 3 примера, когда такие ошибки вполне могли бы быть найдены именно таким вот образом. У Вас есть какой-то контраргумент, почему ошибки «bool x=x+1» и «int a=0;… c = b/a» не могли быть найдены читателями кода, если бы он был выложен в opensource? Нету. А значит всех тех людей потенциально можно было спасти.
Да, я утвержаю, что такие ошибки не могли быть найдены читателями кода, напрочь оторванными от продукта. Вы даже в коде GNOME не всегда можете исправить явную (для вас) ошибку, и это при условии возможности самостоятельной компиляции и живой, всамделишной проверки. Есть взаимоисключающие ошибки, есть ошибки «it's not a bug, it's a feature». Есть ошибки, которые обходятся на дальнейших стадиях эксплуатации, и где workaround отражен в протоколе. В медоборудовании вы не можете исправить эту ошибку, ибо:
а. Исправление ЧРЕЗВЫЧАЙНО дорого само по себе. Новые версии — это новые испытания, новые сертификации, учет разных версий в разных медучреждениях.
б. Вы должны исправить всю цепочку, от QA и документации и до support-a и professional services. Вы должны переучить всех техников и врачей, на обучение которых УЖЕ затрачены колоссальные ресурсы.
в. Усложнение протокола (если версия N делай так, а версия M — делай иначе) приведет к человеческим ошибкам и бОльшей опасности для пациента.
Если ошибка в коде приводит к тому, что колесико надо поворачивать на два деления влево вместо одного деления вправо, и это отражено во всей эксплутационной цепочке, то это НЕ ОШИБКА. Нельзя смотреть только на код! Затраты на код там мизерные и код чаще всего — данность. Как и железо, ушедшее в производство (остановить, исправить и пустить заново — лимон долларов на бочку). В пятый раз попытаюсь убедить, что это не Gmone, где завтрашняя версия может обрушить нафик нотификации из-за ошибки, а послезавтрашняя из репозитория — исправить обратно (попутно внеся пару новых ошибок). Это другая вселенная. Нельзя сравнивать персональный мир с нулевой стоимостью апдейта и мир enterprise (тем более, медицинский или военный) с бесконечной стоимостью апдейта. Да, если ошибки случаются рандомально, оборудование придется проапгрейдить, людей переучить, затраты списать. Надежность — один из главных факторов, но опенсорс тут — ни к селу, ни к городу, никакой не критерий.
Отдельно отмечу, что править код без железа, на котором тот бежит, не сможет даже Чак Норрис.
А значит всех тех людей потенциально можно было спасти
Да. Еще их можно было спасти, если б программисты пили зеленый чай вместо черного кофе. Связь одинаковая. Заголовок «Зеленый чай спасает пациентов» будет настолько же жареный, как и про опенсорц. И вообще, пусть для начала Гном сократит свои открытые тикеты в багтракере хотя бы на четверть. Хотя бы потенциально.
а. Исправление ЧРЕЗВЫЧАЙНО дорого само по себе. Новые версии — это новые испытания, новые сертификации, учет разных версий в разных медучреждениях.
б. Вы должны исправить всю цепочку, от QA и документации и до support-a и professional services. Вы должны переучить всех техников и врачей, на обучение которых УЖЕ затрачены колоссальные ресурсы.
в. Усложнение протокола (если версия N делай так, а версия M — делай иначе) приведет к человеческим ошибкам и бОльшей опасности для пациента.
Если ошибка в коде приводит к тому, что колесико надо поворачивать на два деления влево вместо одного деления вправо, и это отражено во всей эксплутационной цепочке, то это НЕ ОШИБКА. Нельзя смотреть только на код! Затраты на код там мизерные и код чаще всего — данность. Как и железо, ушедшее в производство (остановить, исправить и пустить заново — лимон долларов на бочку). В пятый раз попытаюсь убедить, что это не Gmone, где завтрашняя версия может обрушить нафик нотификации из-за ошибки, а послезавтрашняя из репозитория — исправить обратно (попутно внеся пару новых ошибок). Это другая вселенная. Нельзя сравнивать персональный мир с нулевой стоимостью апдейта и мир enterprise (тем более, медицинский или военный) с бесконечной стоимостью апдейта. Да, если ошибки случаются рандомально, оборудование придется проапгрейдить, людей переучить, затраты списать. Надежность — один из главных факторов, но опенсорс тут — ни к селу, ни к городу, никакой не критерий.
Отдельно отмечу, что править код без железа, на котором тот бежит, не сможет даже Чак Норрис.
А значит всех тех людей потенциально можно было спасти
Да. Еще их можно было спасти, если б программисты пили зеленый чай вместо черного кофе. Связь одинаковая. Заголовок «Зеленый чай спасает пациентов» будет настолько же жареный, как и про опенсорц. И вообще, пусть для начала Гном сократит свои открытые тикеты в багтракере хотя бы на четверть. Хотя бы потенциально.
Я согласен с Вашей мыслью о том, что один лишь только фикс кода — это лишь малая часть общего процесса разработки. Но что же получается — код вообще не надо фиксить, поскольку, дескать, придётся же и документацию переделывать и железо, и людей переучивать. Это что вообще за аргумент такой? Да, будет нужно. Точка.
А иначе мы уж вовсе скатываемся в отрицание возмножности фикса любых ошибок в больших системах. Понятное дело, что я, Вася с улицы, не буду напрямую коммитить код в репозитарий производителя мед.техники. Но я, блин, в состоянии найти в коде ошибку деления на ноль или работу с булевыми переменными методами «x=x+1». И я в состоянии поделиться моим открытием с производителем и общественностью. Дальше, конечно, как уже повезет — может он пофиксит мой баг и пройдет всю цепочку от изменения доков до новой железки, а может забьёт на это дело болт.
Но, внимание! Человек, который завтра будет ложиться под эту мед.технику, даже ничего не понимая в коде, а лишь только умея пользоваться гуглом, сможет найти мой багрепорт, узнать статус по нему, спросить у производителя — действительно ли это баг и пофикшен ли он в той версии железки с которой он будет иметь дело. И производитель будет вынужден давать внятные ответы, ибо иначе дорожащий своей жизнью пациент быстро пошлет его нафиг — благо в мире развитого капитализма всегда найдется более сговорчивый конкурент — ему и достанутся деньги.
А иначе мы уж вовсе скатываемся в отрицание возмножности фикса любых ошибок в больших системах. Понятное дело, что я, Вася с улицы, не буду напрямую коммитить код в репозитарий производителя мед.техники. Но я, блин, в состоянии найти в коде ошибку деления на ноль или работу с булевыми переменными методами «x=x+1». И я в состоянии поделиться моим открытием с производителем и общественностью. Дальше, конечно, как уже повезет — может он пофиксит мой баг и пройдет всю цепочку от изменения доков до новой железки, а может забьёт на это дело болт.
Но, внимание! Человек, который завтра будет ложиться под эту мед.технику, даже ничего не понимая в коде, а лишь только умея пользоваться гуглом, сможет найти мой багрепорт, узнать статус по нему, спросить у производителя — действительно ли это баг и пофикшен ли он в той версии железки с которой он будет иметь дело. И производитель будет вынужден давать внятные ответы, ибо иначе дорожащий своей жизнью пациент быстро пошлет его нафиг — благо в мире развитого капитализма всегда найдется более сговорчивый конкурент — ему и достанутся деньги.
Да, будет нужно. Точка.
Идеализм — это хорошо, когда мы ведем приятный посленовогодний разговор на Хабре. В реальности все сложнее, гораздо больше переменных, входных данных, влияющих на решения, гораздо сложнее компромиссы.
я, блин, в состоянии найти в коде ошибку деления на ноль
Даже чисто технически это не всегда так. в обработчик эксепшена деления на ноль кто-то мог вставить workaround. Вы не можете охватить проект настолько глубоко, чтобы абсолютно точно эмпирически находить ошибки. А если можете, вы занимаетесь им настолько плотно, что фактически работаете на производителя. Так работайте full time и получайте за это деньги!
Если бы ошибки было так легко находить, делиться и исправлять, то почему их, черт побери, так много?! Что в коммерческом коде, что в опенсорсном?
И я в состоянии поделиться моим открытием с производителем
Не в состоянии. У производителя нет такого внешнего инпута. Ему не интересны эмпирические ошибки. У проекта есть работники, которые занимаются конкретными проблемами: где, когда, кто делал, что *точно* делал, больной с каким диагнозом, какой курс лечения, что было до, что случилось после, ожидаемые побочные эффекты, какой силы, неожиданные побочные эффекты, комбинации лечения или диагностики. Это не обычный тикет в багтракере заполнить (который, к слову, не состоянии *правильно* заполнить и половина из профессионалов-технарей).
Человек, который завтра будет ложиться под эту мед.технику, даже ничего не понимая в коде, а лишь только умея пользоваться гуглом, сможет найти мой багрепорт, узнать статус по нему, спросить у производителя — действительно ли это баг и пофикшен
Вы в какой вселенной живете? :) Какой багрепорт, какой статус, какой производитель, мама дорогая?! :). Вы идете к врачу и говорите «Доктор, у меня болит это», а потом либо следуете назначенным процедурам, которые вы еще будете ждать пару месяцев, если они дорогостоящие, либо идете лесом. Вопросы про версию железок вам будет разрешено задать только в одном месте — в сумасшедшем доме.
иначе дорожащий своей жизнью пациент быстро пошлет его нафиг — благо в мире развитого капитализма
Дайте я угадаю. Вы очень молодой и/или до сих пор не сталкивающийся с медициной человек. Вы не до конца представляете себе стоимость проверок/страховок, страшный дефицит оборудования и длиннющие очереди на более-менее серьезные проверки или операции, особенно в мире развитого капитализма. Вы не предполагаете, что последнее, о чем вы будете говорить с врачами — это марка и багрепорты техники (если, опять же, врач — не психиатр). И не понимаете, что для медиков вы никакой не клиент. Как минмиум, не индивидуальный клиент. Если я ошибся, прошу считать это комплиментом :).
Идеализм — это хорошо, когда мы ведем приятный посленовогодний разговор на Хабре. В реальности все сложнее, гораздо больше переменных, входных данных, влияющих на решения, гораздо сложнее компромиссы.
я, блин, в состоянии найти в коде ошибку деления на ноль
Даже чисто технически это не всегда так. в обработчик эксепшена деления на ноль кто-то мог вставить workaround. Вы не можете охватить проект настолько глубоко, чтобы абсолютно точно эмпирически находить ошибки. А если можете, вы занимаетесь им настолько плотно, что фактически работаете на производителя. Так работайте full time и получайте за это деньги!
Если бы ошибки было так легко находить, делиться и исправлять, то почему их, черт побери, так много?! Что в коммерческом коде, что в опенсорсном?
И я в состоянии поделиться моим открытием с производителем
Не в состоянии. У производителя нет такого внешнего инпута. Ему не интересны эмпирические ошибки. У проекта есть работники, которые занимаются конкретными проблемами: где, когда, кто делал, что *точно* делал, больной с каким диагнозом, какой курс лечения, что было до, что случилось после, ожидаемые побочные эффекты, какой силы, неожиданные побочные эффекты, комбинации лечения или диагностики. Это не обычный тикет в багтракере заполнить (который, к слову, не состоянии *правильно* заполнить и половина из профессионалов-технарей).
Человек, который завтра будет ложиться под эту мед.технику, даже ничего не понимая в коде, а лишь только умея пользоваться гуглом, сможет найти мой багрепорт, узнать статус по нему, спросить у производителя — действительно ли это баг и пофикшен
Вы в какой вселенной живете? :) Какой багрепорт, какой статус, какой производитель, мама дорогая?! :). Вы идете к врачу и говорите «Доктор, у меня болит это», а потом либо следуете назначенным процедурам, которые вы еще будете ждать пару месяцев, если они дорогостоящие, либо идете лесом. Вопросы про версию железок вам будет разрешено задать только в одном месте — в сумасшедшем доме.
иначе дорожащий своей жизнью пациент быстро пошлет его нафиг — благо в мире развитого капитализма
Дайте я угадаю. Вы очень молодой и/или до сих пор не сталкивающийся с медициной человек. Вы не до конца представляете себе стоимость проверок/страховок, страшный дефицит оборудования и длиннющие очереди на более-менее серьезные проверки или операции, особенно в мире развитого капитализма. Вы не предполагаете, что последнее, о чем вы будете говорить с врачами — это марка и багрепорты техники (если, опять же, врач — не психиатр). И не понимаете, что для медиков вы никакой не клиент. Как минмиум, не индивидуальный клиент. Если я ошибся, прошу считать это комплиментом :).
>Вы не можете охватить проект настолько глубоко, чтобы абсолютно точно эмпирически находить ошибки...
Послушайте, Вы говорите неправду. В мире есть тысячи проектов с открытым кодом, где очень многие люди «со стороны» находят и фиксят ошибки, присылают патчноуты и т.д. Побродите по гитхабу, соурсфорджу и Вы найдете эти проекты. Я даже сам так делал пару раз, а однажды патч даже приняли. Зачем Вы мне здесь доказываете что то, что куча людей делает ежедневно, является невозможным?
>Не в состоянии. У производителя нет такого внешнего инпута.
Плевать мне на его внешний инпут. Открываем активный медицинский форум, формулируем проблему с указанием модели техники + письмо производителю. Всё. Вне зависимости ни от чего, топик на форуме будет находится гуглом по запросу модели девайса.
>Вы в какой вселенной живете?Я живу в не очень большом городе и к врачам правда обращаюсь не очень часто. Но! За те 2-3 обращения в течении нескольких последних лет мне четко давали выбор: вот можно ждать неопределенное время очередь в гос.клинику, где тебе сделают непонятно что (и нужно дать на лапу), либо вот частная клиника, где ты заплатишь вот ровно столько, примут тебя сразу, обследуют вот на такой вот технике и результат будет в тот же день. При этом даже в такой глубинке, как мой город, платных медицинских клиник больше одной, цены на услуги и модели техники, используемой в работе лежат в открытом доступе у них на сайтах и перед обращением я вполне могу делать выбор куда идти на основе этих данных. Да, там дорого. Но выбор есть, и информация есть. Исходников кода, конечно, нет. В этом и проблема, об этом и статья.
Послушайте, Вы говорите неправду. В мире есть тысячи проектов с открытым кодом, где очень многие люди «со стороны» находят и фиксят ошибки, присылают патчноуты и т.д. Побродите по гитхабу, соурсфорджу и Вы найдете эти проекты. Я даже сам так делал пару раз, а однажды патч даже приняли. Зачем Вы мне здесь доказываете что то, что куча людей делает ежедневно, является невозможным?
>Не в состоянии. У производителя нет такого внешнего инпута.
Плевать мне на его внешний инпут. Открываем активный медицинский форум, формулируем проблему с указанием модели техники + письмо производителю. Всё. Вне зависимости ни от чего, топик на форуме будет находится гуглом по запросу модели девайса.
>Вы в какой вселенной живете?Я живу в не очень большом городе и к врачам правда обращаюсь не очень часто. Но! За те 2-3 обращения в течении нескольких последних лет мне четко давали выбор: вот можно ждать неопределенное время очередь в гос.клинику, где тебе сделают непонятно что (и нужно дать на лапу), либо вот частная клиника, где ты заплатишь вот ровно столько, примут тебя сразу, обследуют вот на такой вот технике и результат будет в тот же день. При этом даже в такой глубинке, как мой город, платных медицинских клиник больше одной, цены на услуги и модели техники, используемой в работе лежат в открытом доступе у них на сайтах и перед обращением я вполне могу делать выбор куда идти на основе этих данных. Да, там дорого. Но выбор есть, и информация есть. Исходников кода, конечно, нет. В этом и проблема, об этом и статья.
Послушайте, Вы говорите неправду. В мире есть тысячи проектов с открытым кодом, где очень многие люди «со стороны» находят и фиксят ошибки, присылают патчноуты и т.д.
Я дико извиняюсь, но с моей стороны это была дружеская дискуссия в давно ушедшем в небытие треде, а не тренажер для уменьшения кармы. Найдите хоть одну причину по которой я хотел бы такую дискуссию продолжать. Помимо непрекращающихся минусов, что меня задевает персонально, вы серьезно не понимаете, что этим «тысячам проектов» нельзя доверить и управление детской железной дорогой, не говоря уже о emergency или medical/military grade устройствах.
Я дико извиняюсь, но с моей стороны это была дружеская дискуссия в давно ушедшем в небытие треде, а не тренажер для уменьшения кармы. Найдите хоть одну причину по которой я хотел бы такую дискуссию продолжать. Помимо непрекращающихся минусов, что меня задевает персонально, вы серьезно не понимаете, что этим «тысячам проектов» нельзя доверить и управление детской железной дорогой, не говоря уже о emergency или medical/military grade устройствах.
В каком-то смысле она права — это дело такое, что перепроверить не мешает.
ru.wikipedia.org/wiki/Therac-25
Therac-25 — аппарат лучевой терапии, медицинский ускоритель, созданный канадской государственной организацией Atomic Energy of Canada Limited и запущенный в серию в 1982 г. Этот аппарат был причиной как минимум шести передозировок радиации, некоторые пациенты получили дозы в десятки тысяч рад. Как минимум двое умерли непосредственно от передозировок.
Непосредственной причиной трагедий были ошибки в программном обеспечении аппарата, а принципиальной проблемой была неверная стратегия обеспечения безопасности. Эти программные ошибки считаются приведшими к одним из самых серьёзных последствий за всю историю использования компьютеров.
Однако как прецедент она действительно доведет дело до «покажите мне код автомобиля», а там как дело повернется…
И еще — из текста понятно, что это дело не тестируют в FDA, но разве это дело не тестируют производители самих устройств? Вон, в Харькове в подразделениях GlobalLogic тестируют (только тестируют) медицинский софт.
ru.wikipedia.org/wiki/Therac-25
Therac-25 — аппарат лучевой терапии, медицинский ускоритель, созданный канадской государственной организацией Atomic Energy of Canada Limited и запущенный в серию в 1982 г. Этот аппарат был причиной как минимум шести передозировок радиации, некоторые пациенты получили дозы в десятки тысяч рад. Как минимум двое умерли непосредственно от передозировок.
Непосредственной причиной трагедий были ошибки в программном обеспечении аппарата, а принципиальной проблемой была неверная стратегия обеспечения безопасности. Эти программные ошибки считаются приведшими к одним из самых серьёзных последствий за всю историю использования компьютеров.
Однако как прецедент она действительно доведет дело до «покажите мне код автомобиля», а там как дело повернется…
И еще — из текста понятно, что это дело не тестируют в FDA, но разве это дело не тестируют производители самих устройств? Вон, в Харькове в подразделениях GlobalLogic тестируют (только тестируют) медицинский софт.
А вот, еще из области неприятного — en.wikipedia.org/wiki/Multidata_Systems_International
A software product of the company was involved in an accidental overexposure of patients in Panama in 2001 when the treatment planning software RTP/2 (vers. 2.11, 1991) reportedly contributed to 28 patients receiving excessive amounts of radiation at a medical facility in Panama City. A panel of experts designated by the International Atomic Energy Agency delivered a comprehensive report in August 2001, finding that the software permitted incorrect forms of data entry which in turn had led to miscalculation of treatment times. Multidata began a recall and in-field correction of its radiation treatment planning software in September 2001 with the issue of a software correction and detailed description of the cause and circumstances of the incorrect data entry.
Ноябрь 2000 г. Национальный институт рака, Панама. Здесь произошла целая серия инцидентов, вызванная тем, что ПО для планирования радиационной терапии производства американской компании Multidata Systems International неправильно рассчитывало дозы облучения для пациентов. Программа позволяла врачу нарисовать на компьютерном экране расположение защитных металлических щитов, которые защищают тело от радиации. Но программа позволяла манипулировать только четырьмя щитами, тогда как врачи хотели задействовать пять. Они нашли способ “обхитрить” программу, если нарисовать все пять щитов в виде единого блока с дыркой посередине. Единственное, чего они не знали, что программа рассчитывает разные дозы радиации в зависимости от того, как нарисована дырка. Если рисовать ее особым образом, то устройство выдавало двойную дозу радиации. Как минимум восемь человек погибли, а еще 20 получили переоблучение. Врачи, которые должны были вручную перепроверять расчеты программы, были осуждены за убийство.
A software product of the company was involved in an accidental overexposure of patients in Panama in 2001 when the treatment planning software RTP/2 (vers. 2.11, 1991) reportedly contributed to 28 patients receiving excessive amounts of radiation at a medical facility in Panama City. A panel of experts designated by the International Atomic Energy Agency delivered a comprehensive report in August 2001, finding that the software permitted incorrect forms of data entry which in turn had led to miscalculation of treatment times. Multidata began a recall and in-field correction of its radiation treatment planning software in September 2001 with the issue of a software correction and detailed description of the cause and circumstances of the incorrect data entry.
Ноябрь 2000 г. Национальный институт рака, Панама. Здесь произошла целая серия инцидентов, вызванная тем, что ПО для планирования радиационной терапии производства американской компании Multidata Systems International неправильно рассчитывало дозы облучения для пациентов. Программа позволяла врачу нарисовать на компьютерном экране расположение защитных металлических щитов, которые защищают тело от радиации. Но программа позволяла манипулировать только четырьмя щитами, тогда как врачи хотели задействовать пять. Они нашли способ “обхитрить” программу, если нарисовать все пять щитов в виде единого блока с дыркой посередине. Единственное, чего они не знали, что программа рассчитывает разные дозы радиации в зависимости от того, как нарисована дырка. Если рисовать ее особым образом, то устройство выдавало двойную дозу радиации. Как минимум восемь человек погибли, а еще 20 получили переоблучение. Врачи, которые должны были вручную перепроверять расчеты программы, были осуждены за убийство.
не только тестируют :)
Независимо от того кто тестирует медицинские продукты — важно соблюдение процесса тестирование, а требования к такому процессу, как раз и предъявляет FDA.
Наверное прикольно тестировать то, от чего зависит твоя жизнь.
> Исследования показывают
Ссылка есть?
Ссылка есть?
Карен проявила полное незнание ни процесса разработки медицинских продуктов, ни функций FDA. Главная функция FDA методологическая и призвана регламентировать процесс. И если продукт подошел к тестированию FDA и какой-либо аспект процесса был нарушен, то продукт не попадет на рынок, обернувшись многомиллионными потерями для компании-разработчика.
Код. Зная изнутри, американские медицинские проекты могу сказать, что продукты создают несколько лет, даже, если это всего-лишь следующее поколение. Процесс разработки весьма регламентирован и стандартизирован с многоступенчатой проверки кода и тестов. А прежде, чем продукт пойдет на тестирование FDA, его тестируют в разных условия, потом на животных и потом на добровольцах. Только когда производитель сам уверен в своем продукте — его передают FDA, им ведь не нужны иски от пациентов.
Открытый код — это утопия, имея открытый код можно например наплодить кучу китайских подделок.
Если у Карен будут проблемы после внедрения кардио-стимулятора — она может выиграть суд. Причем серьезных проблем быть не должно, ведь железо и код проходили достаточно сложную и комплексную проверку.
Код. Зная изнутри, американские медицинские проекты могу сказать, что продукты создают несколько лет, даже, если это всего-лишь следующее поколение. Процесс разработки весьма регламентирован и стандартизирован с многоступенчатой проверки кода и тестов. А прежде, чем продукт пойдет на тестирование FDA, его тестируют в разных условия, потом на животных и потом на добровольцах. Только когда производитель сам уверен в своем продукте — его передают FDA, им ведь не нужны иски от пациентов.
Открытый код — это утопия, имея открытый код можно например наплодить кучу китайских подделок.
Если у Карен будут проблемы после внедрения кардио-стимулятора — она может выиграть суд. Причем серьезных проблем быть не должно, ведь железо и код проходили достаточно сложную и комплексную проверку.
Я вот нынче занимаюсь написанием ПО для комплексов лучевой терапии. Я могу сказать, что у начальства пока даже нет предположений, каким образом оно потом будет сертифицироваться. Да и пишем мы его вдвоём, никакого контроля программного кода, да даже ТЗ у нас нет. Контроль будет проводиться, когда будет вводиться в строй весь комплекс, под который мы это пишем (хотя возможности работы с другими комплексами пытаемся закладывать), да и то дозиметрический на выходе непосредственно с трубки излучателя, а не программного кода.
Но, тем не менее, внутренние тесты и предклинические исследования силами нашего института идут: людей туда посадят не раньше 2013, на февраль запланированы исследования полного цикла работы всего комплекса; в томограф посадят собаку, получат снимки, потом прогонят через нашу программу, потом облучат и будут смотреть.
Но, тем не менее, внутренние тесты и предклинические исследования силами нашего института идут: людей туда посадят не раньше 2013, на февраль запланированы исследования полного цикла работы всего комплекса; в томограф посадят собаку, получат снимки, потом прогонят через нашу программу, потом облучат и будут смотреть.
> FDA полагается на отчет производителя, в котором, конечно же, может быть написано всё, что угодно. Кроме общих стандартов по форматированию текста, никаких особых требований к этому документу нет.
Есть, и их весьма немало. Два года назад я писал backend на очень немаленький проект, который планировали сертифицировать под FDA. Проект касался офтальмологии, конкретно — расчетов интраокулярных линз (т.е. тех, что имплантируются в глаз). Ошибка там приводит максимум к замене линзы (что является отработанной операцией), так что это даже близко не кардиостимулятор. И тем не менее, этот код являлся частью medical device, и таким образом, подлежал обязательной сертификации по стандарту ISO 13485, и некоторым другим стандартам. Code Reviews, обязательное использование code versioning systems, поголовная валидация всего софта, использованного при создании кода (представьте себе валидацию Zend Studio, да), валидация всего runtime — это только часть марлезонского балета. Все это должно было быть представлено в строжайшей форме отчетности.
И заметьте, мы еще не начинали тестировать код. Там тоже весело — обязательное разделение кодеров, авторов test cases, и исполнителей оных. Разумеется, обязательный багтрекер, причем желательно с валидацией (ой). Опять же, строгая отчетность вплоть до скриншотов, валидация расчетов до клинически значимой точности (примерно 0.1 диоптрии), причем чтобы проверять расчеты, надо их сравнить с каким-то золотым стандартом — а его нет! В итоге представители QA заказчика предложили использовать в качестве золотого стандарта… Some_spreadsheet.XLS. QA fail, facepalm с нашей стороны… это к слову о том, что ISO надо тоже применять с головой. В конечном итоге пакет одной только тестовой документации потянул примерно на 1000 страниц. И еще одно — электронные подписи в США — это совсем не так просто, как кажется, несмотря на наличие 21 CFR Part 11, регламентирующего этот момент. Многие деятели в QA заказчика просто не хотят в этом разбираться, и в итоге мы вынуждены кидаться килограммовыми пачками бумаги через полстраны (спасибо UPS/FedEx), чтобы получить синенькую подпись — и это в 21 веке. Оценивать уровень идиотизма оставлю хабровчанам.
А проект в итоге был похоронен манагерами заказчика по политическим причинам, несмотря на 100% доказанную работоспособность.
P.S. Тем, кто думает, что PHP — это не самый удачный выбор для сложных математических расчетов, могу сказать, что около 40 тысяч человек, которые за последние 6 лет сняли очки (благодаря нашему другому проекту), возможно думают иначе :)
Есть, и их весьма немало. Два года назад я писал backend на очень немаленький проект, который планировали сертифицировать под FDA. Проект касался офтальмологии, конкретно — расчетов интраокулярных линз (т.е. тех, что имплантируются в глаз). Ошибка там приводит максимум к замене линзы (что является отработанной операцией), так что это даже близко не кардиостимулятор. И тем не менее, этот код являлся частью medical device, и таким образом, подлежал обязательной сертификации по стандарту ISO 13485, и некоторым другим стандартам. Code Reviews, обязательное использование code versioning systems, поголовная валидация всего софта, использованного при создании кода (представьте себе валидацию Zend Studio, да), валидация всего runtime — это только часть марлезонского балета. Все это должно было быть представлено в строжайшей форме отчетности.
И заметьте, мы еще не начинали тестировать код. Там тоже весело — обязательное разделение кодеров, авторов test cases, и исполнителей оных. Разумеется, обязательный багтрекер, причем желательно с валидацией (ой). Опять же, строгая отчетность вплоть до скриншотов, валидация расчетов до клинически значимой точности (примерно 0.1 диоптрии), причем чтобы проверять расчеты, надо их сравнить с каким-то золотым стандартом — а его нет! В итоге представители QA заказчика предложили использовать в качестве золотого стандарта… Some_spreadsheet.XLS. QA fail, facepalm с нашей стороны… это к слову о том, что ISO надо тоже применять с головой. В конечном итоге пакет одной только тестовой документации потянул примерно на 1000 страниц. И еще одно — электронные подписи в США — это совсем не так просто, как кажется, несмотря на наличие 21 CFR Part 11, регламентирующего этот момент. Многие деятели в QA заказчика просто не хотят в этом разбираться, и в итоге мы вынуждены кидаться килограммовыми пачками бумаги через полстраны (спасибо UPS/FedEx), чтобы получить синенькую подпись — и это в 21 веке. Оценивать уровень идиотизма оставлю хабровчанам.
А проект в итоге был похоронен манагерами заказчика по политическим причинам, несмотря на 100% доказанную работоспособность.
P.S. Тем, кто думает, что PHP — это не самый удачный выбор для сложных математических расчетов, могу сказать, что около 40 тысяч человек, которые за последние 6 лет сняли очки (благодаря нашему другому проекту), возможно думают иначе :)
Очень сомнительно, что она добьётся того, чтобы ей показали код. Причина проста:
На настоящий момент все производители используют практически одинаковые материалы и компоненты, им остаётся только конкурировать за счёт самого ПО.
Medtronic, Biotronic, Saint Jude и сотоварищи старательно работают над алгоритмами диагностики, предупреждения и лечения нарушений ритма (если говорить именно о кардиостимуляторах).
А насчёт безопасности: кардиостимуляторы проверяются производителем и непосредственно перед операцией — хирургом.
Впрочем, из приблизительно двух-трёх сотен стимуляторов, с которыми я имел дело, только один имел какую-то проблему с программным обеспечением, о чём предупреждал сам программатор (инструмент настройки кардиостимулятора). Случаи последующих сбоев (2 шт) были
На настоящий момент все производители используют практически одинаковые материалы и компоненты, им остаётся только конкурировать за счёт самого ПО.
Medtronic, Biotronic, Saint Jude и сотоварищи старательно работают над алгоритмами диагностики, предупреждения и лечения нарушений ритма (если говорить именно о кардиостимуляторах).
А насчёт безопасности: кардиостимуляторы проверяются производителем и непосредственно перед операцией — хирургом.
Впрочем, из приблизительно двух-трёх сотен стимуляторов, с которыми я имел дело, только один имел какую-то проблему с программным обеспечением, о чём предупреждал сам программатор (инструмент настройки кардиостимулятора). Случаи последующих сбоев (2 шт) были
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Могу ли я увидеть код?