Аннотация:
В статье предлагаются принципы процесса разработки ПО, которые позволят улучшить качество и надежность обычного программного обеспечения. Все принципы основаны на рекомендациях, дающихся авиационными стандартами разработки критического программного обеспечения RTCA DO178B/DO178С.
Re: Двадцать основных принципов, без которых нельзя обойтись при создании надежн
В конечном итоге, все определяет не процесс, а человеческий фактор.
ТАА>Аннотация: ТАА>В статье предлагаются принципы процесса разработки ПО, которые позволят улучшить качество и надежность обычного программного обеспечения. Все принципы основаны на рекомендациях, дающихся авиационными стандартами разработки критического программного обеспечения RTCA DO178B/DO178С.
А сколько стоит разработка софта с использованием авиационного процесса, в статье говорится?
Re[2]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, Pzz, Вы писали:
Pzz>А сколько стоит разработка софта с использованием авиационного процесса, в статье говорится?
Наверняка нет — да и к чему такие мелочи. Ждем продолжения, про разработку уберсупернадежного софта, на основе рекомендаций разработчикам управляющего ПО ядерных реакторов .
Re[3]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Pzz>>А сколько стоит разработка софта с использованием авиационного процесса, в статье говорится?
G>Наверняка нет — да и к чему такие мелочи. Ждем продолжения, про разработку уберсупернадежного софта, на основе рекомендаций разработчикам управляющего ПО ядерных реакторов .
А вот телефонистов слушать не будем. Во-первых, это не про самолеты с ракетами и реакторами, т.е. объективно недостаточно надежно, и вообще — некруто, потому, что слишком понятно.
А во-вторых, они, лохи педальные, со своими пятью девятками надежности, и половины принципов не выполняют .
Re: Двадцать основных принципов, без которых нельзя обойтись при создании надежн
Pzz>В конечном итоге, все определяет не процесс, а человеческий фактор.
ТАА>>Аннотация: ТАА>>В статье предлагаются принципы процесса разработки ПО, которые позволят улучшить качество и надежность обычного программного обеспечения. Все принципы основаны на рекомендациях, дающихся авиационными стандартами разработки критического программного обеспечения RTCA DO178B/DO178С.
Pzz>А сколько стоит разработка софта с использованием авиационного процесса, в статье говорится?
Сколько стоит такая разработка, в статье не говорится. В ней так же не говорится, сколько будет стоить на рынке ПО ваш продукт, если вы его сертифицируете согласно авиационным стандартам, в сравнении с аналогичным программным обеспечением, но без большой печати сертифицирующей власти, а, следовательно, не имеющим разрешения быть использованным в опасных для человека системах.
Re[3]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Pzz, Вы писали:
Pzz>>А сколько стоит разработка софта с использованием авиационного процесса, в статье говорится?
G>Наверняка нет — да и к чему такие мелочи. Ждем продолжения, про разработку уберсупернадежного софта, на основе рекомендаций разработчикам управляющего ПО ядерных реакторов .
Если я не ошибаюсь, в ядерной промышленности на западе в каких-то ее областях так же используется DO-178B/C. Еще его можно найти в медицине. Для самого верхнего уровня критичности ( уровень "А") этот стандарт требует обеспечения вероятности отказа меньше 10-9. ( На этом уровне, например, сам компилятор должен быть сертифицирован согласно DO-178B/C под уровень "А").
Re[4]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, Gaperton, Вы писали:
Pzz>>>А сколько стоит разработка софта с использованием авиационного процесса, в статье говорится?
G>>Наверняка нет — да и к чему такие мелочи. Ждем продолжения, про разработку уберсупернадежного софта, на основе рекомендаций разработчикам управляющего ПО ядерных реакторов .
G>А вот телефонистов слушать не будем. Во-первых, это не про самолеты с ракетами и реакторами, т.е. объективно недостаточно надежно, и вообще — некруто, потому, что слишком понятно.
G>А во-вторых, они, лохи педальные, со своими пятью девятками надежности, и половины принципов не выполняют .
Как говорилось в пункте 3, надежность ПО нужно доказать, иначе веры в вероятность декларируемой отказоустойчивости — нет. Для доказательства нужно использовать какой-то подход. В гражданской авиации — нужно доказать что ПО соответствует всем требованиям стандарта DO-178B/C в зависимости от выбранного уровня критичности этого ПО. Уровень критичности определяется в зависимости от того какой вред может причинить ПО человеку, в диапазоне от смертельного и кончая никаким. А что используют "телефонисты" для такого доказательства?
Re[5]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, t_o_l, Вы писали:
__>Как говорилось в пункте 3, надежность ПО нужно доказать, иначе веры в вероятность декларируемой отказоустойчивости — нет. Для доказательства нужно использовать какой-то подход. В гражданской авиации — нужно доказать что ПО соответствует всем требованиям стандарта DO-178B/C в зависимости от выбранного уровня критичности этого ПО. Уровень критичности определяется в зависимости от того какой вред может причинить ПО человеку, в диапазоне от смертельного и кончая никаким. А что используют "телефонисты" для такого доказательства?
Ничего. ПО телефонных свитчей не может причинить вреда человеку. Что не мешает ему быть достаточно надежным by design и по практике эксплуатации — пять девяток аптайма все приличные продукты на практике обеспечивают. Некоторые, как например, AXD301, фактически обеспечивают девять девяток.
При этом, практическая надежность "телефонного" многократно перекрывает все разумные требования к надежности обычного ПО, не говоря уже о современных веб-сервисах, где в процессе разработки вполне сознательно жертвуют надежностью в пользу скорости внесения изменений.
У слова "надежность" очень много граней, это не бинарный признак. Есть разные подходы к обеспечению надежности, и все они стоят денег.
Например, при разработке системы автоматической посадки Бурана отдельная команда занималась восстановлением исходников на Фортране из машинного кода, и сравнением исходников с оригиналом. В результате было найдено две ошибки в компиляторе, из-за которых Буран непременно упал бы. Я лично знаком с руководителем этой команды.
Дает ли этот опыт нам что-то полезное? Нет. Надо быть сумасшедшим, чтобы использовать эту практику в коммерческой разработке.
Re[6]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, t_o_l, Вы писали:
__>>Как говорилось в пункте 3, надежность ПО нужно доказать, иначе веры в вероятность декларируемой отказоустойчивости — нет. Для доказательства нужно использовать какой-то подход. В гражданской авиации — нужно доказать что ПО соответствует всем требованиям стандарта DO-178B/C в зависимости от выбранного уровня критичности этого ПО. Уровень критичности определяется в зависимости от того какой вред может причинить ПО человеку, в диапазоне от смертельного и кончая никаким. А что используют "телефонисты" для такого доказательства?
G>Ничего. ПО телефонных свитчей не может причинить вреда человеку. Что не мешает ему быть достаточно надежным by design и по практике эксплуатации — пять девяток аптайма все приличные продукты на практике обеспечивают. Некоторые, как например, AXD301, фактически обеспечивают девять девяток.
G>При этом, практическая надежность "телефонного" многократно перекрывает все разумные требования к надежности обычного ПО, не говоря уже о современных веб-сервисах, где в процессе разработки вполне сознательно жертвуют надежностью в пользу скорости внесения изменений.
G>У слова "надежность" очень много граней, это не бинарный признак. Есть разные подходы к обеспечению надежности, и все они стоят денег.
G>Например, при разработке системы автоматической посадки Бурана отдельная команда занималась восстановлением исходников на Фортране из машинного кода, и сравнением исходников с оригиналом. В результате было найдено две ошибки в компиляторе, из-за которых Буран непременно упал бы. Я лично знаком с руководителем этой команды.
G>Дает ли этот опыт нам что-то полезное? Нет. Надо быть сумасшедшим, чтобы использовать эту практику в коммерческой разработке.
Спасибо за ответ. Очень интересная информация про Буран. Я хоть сам когда-то имел отношение к космосу, но про это не знал. Что касается, того, что такой опыт не является полезным для коммерческих разработок, то тут я с вами не согласен. Сертификация ПО на уровень "А" и "В" стандарта DO-178B/C, как раз и идет каким-то похожим путем. И даже если компилятора сам сертифицирован на уровень "А" в нем могут быть ошибки, поэтому могут потребоваться какие-то сложные пути обеспечения надежности. Так что если вы разрабатываете, например, автопилот для самолета, который и по железу и по программному обеспечению должен иметь уровень критичности "А" или "В", такой опыт может очень сильно пригодиться.
Re[2]: Двадцать основных принципов, без которых нельзя обойтись при создании над
другое дело что в 99.99% оно не нужно. ну и в 0.09% случаев из этого всего можно выкусить пару тройку идей для порактического использования. однако в остальных 99.9% случаяев оно не нужно вообще от слова совсем.
Re[4]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, t_o_l, Вы писали:
__>Если я не ошибаюсь, в ядерной промышленности на западе в каких-то ее областях так же используется DO-178B/C. Еще его можно найти в медицине. Для самого верхнего уровня критичности ( уровень "А") этот стандарт требует обеспечения вероятности отказа меньше 10-9. ( На этом уровне, например, сам компилятор должен быть сертифицирован согласно DO-178B/C под уровень "А").
Там используется IEC 61508 (Safety Integrity Levels).
bloß it hudla
Re[5]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, t_o_l, Вы писали:
__>>Если я не ошибаюсь, в ядерной промышленности на западе в каких-то ее областях так же используется DO-178B/C. Еще его можно найти в медицине. Для самого верхнего уровня критичности ( уровень "А") этот стандарт требует обеспечения вероятности отказа меньше 10-9. ( На этом уровне, например, сам компилятор должен быть сертифицирован согласно DO-178B/C под уровень "А").
AL>Там используется IEC 61508 (Safety Integrity Levels).
Ключевая редакция стандарта DO-178B вышла в конце 1992 года. Опыт его применения в авиации оказался достаточно успешным, и его положения и принципы легли в основу других промышленных стандартов, но не связанных с авиацией. Насколько я знаю, DO-178B существенно повлиял на развитие стандартов в таких отраслях, как железнодорожный и автомобильный транспорт, ядерная энергетика и медицина. Так что базовые принципы DO-178B, вы можете найти и в IEC 61508.
Re[6]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, t_o_l, Вы писали:
__>Ключевая редакция стандарта DO-178B вышла в конце 1992 года. Опыт его применения в авиации оказался достаточно успешным, и его положения и принципы легли в основу других промышленных стандартов, но не связанных с авиацией. Насколько я знаю, DO-178B существенно повлиял на развитие стандартов в таких отраслях, как железнодорожный и автомобильный транспорт, ядерная энергетика и медицина. Так что базовые принципы DO-178B, вы можете найти и в IEC 61508.
"Базовые принципы DO-178B" можно гарантировано найти в DO-178С. Который был сделан с учетом накопившихся претензий к B.
Since the release of DO-178B, there have been strong calls by DERs (FAA Designated Engineering Representatives) for clarification/refinement of the definitions and boundaries between the key DO-178B concepts of High Level Requirements, Low Level Requirements, and Derived Requirements and a better definition of the exit/entry criteria between systems requirements and system design (see ARP4754) and that of software requirements and software design (which is the domain of DO-178B). Other topics such as what does verification mean in a model-based development paradigm and can model simulation or formal methods replace some or all software testing activities. The release of DO-178C and the companion documents DO-278A (Ground Systems), DO-248C (Additional information), DO-330 (Tools), DO-331 (Modeling), DO-332 (Object Oriented), and DO-333 (Formal Methods) were created to address the criticisms noted.
Что до IEC 61508, он, в отличии от DO0178*, is intended to be a basic functional safety standard applicable to all kinds of industry. Что как бэ чуточку было бэ более релевантно для "общего случая", чем устаревший частный стандарт для авионики .
Но большинству, с концепцией good enough software, все равно похрен.
Re[7]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, Gaperton, Вы писали:
G>Но большинству, с концепцией good enough software, все равно похрен.
И это правильно. Одной компании пришлось потратить несколько сот тысяч евро и около 300 чел/мес на сертификацию по SIL2/SIL3 небольшой рантайм-системы в TÜV SÜD. Общее впечатление -- все это придумано на радость сертифицирующих органов, которые в итоге все равно никак не отвечают за последствия катастрофических отказов.
bloß it hudla
Re[7]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, Gaperton, Вы писали:
G>"Базовые принципы DO-178B" можно гарантировано найти в DO-178С. Который был сделан с учетом накопившихся претензий к B.
G>
G>Since the release of DO-178B, there have been strong calls by DERs (FAA Designated Engineering Representatives) for clarification/refinement of the definitions and boundaries between the key DO-178B concepts of High Level Requirements, Low Level Requirements, and Derived Requirements and a better definition of the exit/entry criteria between systems requirements and system design (see ARP4754) and that of software requirements and software design (which is the domain of DO-178B). Other topics such as what does verification mean in a model-based development paradigm and can model simulation or formal methods replace some or all software testing activities. The release of DO-178C and the companion documents DO-278A (Ground Systems), DO-248C (Additional information), DO-330 (Tools), DO-331 (Modeling), DO-332 (Object Oriented), and DO-333 (Formal Methods) were created to address the criticisms noted.
G>Что до IEC 61508, он, в отличии от DO0178*, is intended to be a basic functional safety standard applicable to all kinds of industry. Что как бэ чуточку было бэ более релевантно для "общего случая", чем устаревший частный стандарт для авионики .
G>Но большинству, с концепцией good enough software, все равно похрен.
Стандарт DO-178C на 90% (если не больше) — это DO-178B. В дополнении к DO-178B, в DO-178C появились некоторые уточняющие положения, которые вынесли в дополнительные документы, перечисленные в вашем тексте. Плюс в его текст вошли мелкие изменения, опять же указанные в вашем перепосте. Никаких кардинальных изменений в DO-178C нет. Любой, кто имел дело с DO-178B/C, может вам это подтвердить. Так же не изменилась основная концепция DO-178B. Если про нее двумя словами: мы не можем точно сказать, как и когда сломается наше ПО, поскольку мы не можем проверить каждый байт его кода, но мы можем по определенным правилам построить процесс его разработки, постоянно доказывая, что мы делаем то что хотим, именно так как мы запланировали. Этот подход существенно отличается от большого количества других авиационных стандартов, касающихся "железа", поскольку в отличии от ПО, вы у "железа" всегда можете экспериментально проверить когда оно выйдет из строя. Подход DO-178B оказался настолько успешным, что например новый стандарт для авионики DO-254, полностью его реализует. Если в основе IEC 61508 лежит отличная от DO-178B идея, сформулируйте ее, пожалуйста. Было бы очень интересно про это узнать. Я всегда думал, что в атомной промышленности используется та же идея, но может быть я неправ.
Про "устаревший частный стандарт" — это вы, конечно, очень сильно выразились. Дискутировать достаточно трудно, если имеешь дело с максимализмом. Хочу лишь сказать, что ни один гражданский самолет на западе, будь то огромный лайнер или маленький частный самолет, не может подняться в воздух, если используемое им ПО (будь то программы автопилота или ПО для системы развлечения пассажиров) не сертифицировано под DO-178B (а для самолетов, разработанных начиная с 2012, под DO-178С). Но может быть они неправы? Все эти FAA, EASA, Transport Canada. Нужно было бы все сертифицировать под IEC 61508, который "applicable to all kinds of industry".
То что "большинству все равно похрен" — то тут я с вами полностью согласен. Отсюда и идет вся кривизна ПО.
Re[8]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Gaperton, Вы писали:
G>>Но большинству, с концепцией good enough software, все равно похрен.
AL>И это правильно. Одной компании пришлось потратить несколько сот тысяч евро и около 300 чел/мес на сертификацию по SIL2/SIL3 небольшой рантайм-системы в TÜV SÜD. Общее впечатление -- все это придумано на радость сертифицирующих органов, которые в итоге все равно никак не отвечают за последствия катастрофических отказов.
Я знаю несколько случаев, когда были потрачены миллионы долларов и несколько лет работы, а авиационная сертификация провалилась, и разрабатываемые проекты были закрыты. Действительно, сертификационной власти "до лампы", какие у вас возникли трудности (материальные, ресурсные, временные) во время сертификации, поскольку зарплата их штатных сотрудников не зависит от того удастся или нет вам сертифицировать ваше изделие. Но если они поставили печать, то ответственность на косяки в вашем продукте ложиться на их плечи (точнее на конкретных людей, проводивших сертификацию) и уже они попадут под суд, если выяснится, что они что-то недоглядели.
Re[9]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, t_o_l, Вы писали:
__>Здравствуйте, A.Lokotkov, Вы писали:
AL>>Здравствуйте, Gaperton, Вы писали:
G>>>Но большинству, с концепцией good enough software, все равно похрен.
AL>>И это правильно. Одной компании пришлось потратить несколько сот тысяч евро и около 300 чел/мес на сертификацию по SIL2/SIL3 небольшой рантайм-системы в TÜV SÜD. Общее впечатление -- все это придумано на радость сертифицирующих органов, которые в итоге все равно никак не отвечают за последствия катастрофических отказов.
__>Я знаю несколько случаев, когда были потрачены миллионы долларов и несколько лет работы, а авиационная сертификация провалилась, и разрабатываемые проекты были закрыты. Действительно, сертификационной власти "до лампы", какие у вас возникли трудности (материальные, ресурсные, временные) во время сертификации, поскольку зарплата их штатных сотрудников не зависит от того удастся или нет вам сертифицировать ваше изделие. Но если они поставили печать, то ответственность на косяки в вашем продукте ложиться на их плечи (точнее на конкретных людей, проводивших сертификацию) и уже они попадут под суд, если выяснится, что они что-то недоглядели.
А что касается "концепции good enough software", то представьте себе такую гипотетическую ситуацию: вы садитесь в самолет, а пилот вам объявляет: "Для пилотирования на нашем самолете установленные новейшие многофункциональные дисплеи, которые отображают все инструменты пилотирования, а так же навигационные карты и погоду. Все дисплеи сертифицированы согласно требованиям FAA, а вот ПО для них мы купили у индийской фирмы, потому что их ПО было самым дешевым на рынке. Мы не стали его сертифицировать, поскольку сертификация ПО "придумана на радость сертифицирующих органов, которые в итоге все равно никак не отвечают за последствия катастрофических отказов". Но не волнуйтесь, в индийской фирме нас заверили, что большинство их юнит-тестов прошло нормально, и мы можем смело лететь через Атлантику". Останетесь ли вы после такого сообщения на борту этого самолета?
Re[8]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, t_o_l, Вы писали:
__> Если про нее двумя словами: мы не можем точно сказать, как и когда сломается наше ПО, поскольку мы не можем проверить каждый байт его кода, но мы можем по определенным правилам построить процесс его разработки, постоянно доказывая, что мы делаем то что хотим, именно так как мы запланировали.
Идея несколько странная, не находите? А что, если мы хотим не то, что нужно, да еще и запланировали не так, как было надо на самом деле? По поводу "не можем точно сказать" Вы, вероятно, имели в виду "мы утверждаем, что при работе нашего ПО возможны следующие отказы, и вероятность такого-то отказа составляет столько-то и столько-то за такой-то период, вероятность ложного отказа -- столько-то и столько-то за тот же период, и обеспечена эта уверенность тем-то и тем-то". Или Вы имели в виду буквально "не можем точно сказать"?
bloß it hudla
Re[8]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, t_o_l, Вы писали:
__> Подход DO-178B оказался настолько успешным, что например новый стандарт для авионики DO-254, полностью его реализует.
DO-254 — стандарт для разработки электронного оборудования. Он не может "реализовывать" стандарт DO-178B, касающийся софта, ни полностью, ни частично. Ни технически, ни исторически — бортовая электроника появилась куда как раньше, чем бортовые компьютеры.
__>Про "устаревший частный стандарт" — это вы, конечно, очень сильно выразились.
Я выразился не "сильно", а точно. Он устаревший — ему двадцать лет, и у него есть новая ревизия. И он частный — относится к разработке софта в авиаиндустрии.
Нет никакого смысла рассказывать про ревизии стандартов двадцатилетней давности (B) при наличии свежих ревизий (C). Нет никакого смысла пытаться обобщать частные стандарты (DO-178) на общий случай, если обобщение уже сделали за вас умные дяди (IEC 61508).
__> Если в основе IEC 61508 лежит отличная от DO-178B идея, сформулируйте ее, пожалуйста. Было бы очень интересно про это узнать. Я всегда думал, что в атомной промышленности используется та же идея, но может быть я неправ.
Вы неправы совершенно точно. Общая информация об IEC 61508 содержится в википедии — смотрите.
__>Дискутировать достаточно трудно, если имеешь дело с максимализмом.
С вами никто не дискутирует. Мне, например, все понятно .
.