Аннотация:
В статье предлагаются принципы процесса разработки ПО, которые позволят улучшить качество и надежность обычного программного обеспечения. Все принципы основаны на рекомендациях, дающихся авиационными стандартами разработки критического программного обеспечения 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 содержится в википедии — смотрите.
__>Дискутировать достаточно трудно, если имеешь дело с максимализмом.
С вами никто не дискутирует. Мне, например, все понятно .
Re[3]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, t_o_l, Вы писали:
__>Сколько стоит такая разработка, в статье не говорится. В ней так же не говорится, сколько будет стоить на рынке ПО ваш продукт, если вы его сертифицируете согласно авиационным стандартам, в сравнении с аналогичным программным обеспечением, но без большой печати сертифицирующей власти, а, следовательно, не имеющим разрешения быть использованным в опасных для человека системах.
На каком рынке?
99.(9)% софтвария не используют в опасных для человека системах не по причине отсутствия Большой Печати, а по причине, что в таких системах этот софтварий нафиг не нужен. Взять, к примеру, веб провсер — к чему ему самолетная сертификация?
Не надо относиться к Большой Печати, как к некоторому самоценному идолу. Она — лишь одно из требований заказчика, наряду с прочими. А требования зависят от предназначения программы. Нужна заказчику самолетная сертификация — значит, будем работать по самолетному процессу. Не нужна — будем использовать более дешевый процесс.
Re[4]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, Gaperton, Вы писали:
G>А вот телефонистов слушать не будем. Во-первых, это не про самолеты с ракетами и реакторами, т.е. объективно недостаточно надежно, и вообще — некруто, потому, что слишком понятно.
Телефонисты успешно борятся с избытком надежности. Достаточно сравнить надежность старомодных проводных телефонов с гораздо более технологически современной сотовой связью. Старомодный телефон на моей памяти ломался считанное количество раз, с сотовым что-то не работает постоянно.
Re[4]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, Pzz, Вы писали:
Pzz>99.(9)% софтвария не используют в опасных для человека системах не по причине отсутствия Большой Печати, а по причине, что в таких системах этот софтварий нафиг не нужен. Взять, к примеру, веб провсер — к чему ему самолетная сертификация?
Pzz>Не надо относиться к Большой Печати, как к некоторому самоценному идолу. Она — лишь одно из требований заказчика, наряду с прочими. А требования зависят от предназначения программы. Нужна заказчику самолетная сертификация — значит, будем работать по самолетному процессу. Не нужна — будем использовать более дешевый процесс.
Да некто же не заставляет вас разрабатывать ПО согласно авиационным стандартам, а затем его сертифицировать. Это действительно долго, дорого и сложно. Смысл данной статьи — вот такие принципы лежат в основе разработки авиационное ПО, посмотрите, может и для разработки вашего ПО, вы найдете в этом что-то полезное, что затем положительно скажется на его надежности.
Re[9]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, t_o_l, Вы писали:
__>> Подход DO-178B оказался настолько успешным, что например новый стандарт для авионики DO-254, полностью его реализует.
G>DO-254 — стандарт для разработки электронного оборудования. Он не может "реализовывать" стандарт DO-178B, касающийся софта, ни полностью, ни частично. Ни технически, ни исторически — бортовая электроника появилась куда как раньше, чем бортовые компьютеры.
__>>Про "устаревший частный стандарт" — это вы, конечно, очень сильно выразились.
G>Я выразился не "сильно", а точно. Он устаревший — ему двадцать лет, и у него есть новая ревизия. И он частный — относится к разработке софта в авиаиндустрии.
G>Нет никакого смысла рассказывать про ревизии стандартов двадцатилетней давности (B) при наличии свежих ревизий (C). Нет никакого смысла пытаться обобщать частные стандарты (DO-178) на общий случай, если обобщение уже сделали за вас умные дяди (IEC 61508).
__>> Если в основе IEC 61508 лежит отличная от DO-178B идея, сформулируйте ее, пожалуйста. Было бы очень интересно про это узнать. Я всегда думал, что в атомной промышленности используется та же идея, но может быть я неправ.
G>Вы неправы совершенно точно. Общая информация об IEC 61508 содержится в википедии — смотрите.
__>>Дискутировать достаточно трудно, если имеешь дело с максимализмом.
G>С вами никто не дискутирует. Мне, например, все понятно .
Я работаю в компании, которая много лет профессионально занимается сертификаций авиационного оборудования и программного обеспечения. Я принимал непосредственное участие в разработке и сертификации ПО под DO-178B, а сейчас занимаюсь сертификацией под DO-178С. Я общался, знаком, работал вместе с разработчиками стандартов DO-178B, DO-178С и различными сотрудниками сертифицирующих органов. Так что можете мне поверить, я немножко знаком с различными стандартами авиационной сертификации и их положениями, причем не из википедии.
Re[5]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, t_o_l, Вы писали:
__>Да некто же не заставляет вас разрабатывать ПО согласно авиационным стандартам, а затем его сертифицировать. Это действительно долго, дорого и сложно. Смысл данной статьи — вот такие принципы лежат в основе разработки авиационное ПО, посмотрите, может и для разработки вашего ПО, вы найдете в этом что-то полезное, что затем положительно скажется на его надежности.
Тогда subject надо сменить.
Re[9]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, t_o_l, Вы писали:
__>> Если про нее двумя словами: мы не можем точно сказать, как и когда сломается наше ПО, поскольку мы не можем проверить каждый байт его кода, но мы можем по определенным правилам построить процесс его разработки, постоянно доказывая, что мы делаем то что хотим, именно так как мы запланировали.
AL>Идея несколько странная, не находите? А что, если мы хотим не то, что нужно, да еще и запланировали не так, как было надо на самом деле? По поводу "не можем точно сказать" Вы, вероятно, имели в виду "мы утверждаем, что при работе нашего ПО возможны следующие отказы, и вероятность такого-то отказа составляет столько-то и столько-то за такой-то период, вероятность ложного отказа -- столько-то и столько-то за тот же период, и обеспечена эта уверенность тем-то и тем-то". Или Вы имели в виду буквально "не можем точно сказать"?
А программное обеспечение само по себе — вещь странная: потрогать ее нельзя, нельзя повесить на нее груз, и определить при каких нагрузках оно сломается, нельзя так же запихнуть ПО в холодильник и выяснить при каких температурах оно перестанет функционировать. Оно так же очень сильно зависит от "железа" на которым оно работает и от другого программного окружения, в котором оно работает. Поэтому мы не можем точно утверждать, что вот с такой вероятностью наше ПО сломается, как это делается для "железа". Поэтому в авиации для ПО идут другим путем: исходя из нашего опыта разработки программного обеспечения мы описали несколько процессов его создания. С каждым процессом мы связали определенную степень вероятности отказов ПО. Выбирайте нужный вам процесс, исходя из требуемой частоты отказов, и следуйте ему. Но даже если вы будете точно следовать выбранному процессу создания ПО, мы не гарантируем вам, что ваше ПО будет иметь желаемую частоту сбоев. Но вероятность того, что это будет так — достаточно высока, хотя и не 100%.
Если "мы хотим не то, что нужно, да еще и запланировали не так, как было надо на самом деле" то, согласно DO-178B/C, про слова "надежность" и "безопасность" мы должны забыть.
Re[5]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, Pzz, Вы писали:
G>>А вот телефонистов слушать не будем. Во-первых, это не про самолеты с ракетами и реакторами, т.е. объективно недостаточно надежно, и вообще — некруто, потому, что слишком понятно.
Pzz>Телефонисты успешно борятся с избытком надежности. Достаточно сравнить надежность старомодных проводных телефонов с гораздо более технологически современной сотовой связью. Старомодный телефон на моей памяти ломался считанное количество раз, с сотовым что-то не работает постоянно.
Недостаточно. Во-первых, надежность телефонного аппарата здесь не при чем. Причем здесь — сервисы связи. Но раз уж зашла речь о телефонах — смартфоны строго говоря телефонами не являются, у них основное предназначение не разговоры вести. "Телефон" — это, например, современный IP телефон.
Во-вторых, с точки зрения телефонистов, сбой отдельного телефонного разговора (базовый сервис) не является трагедией. Трагедия — это сбой АТС, приводящий к массовому отказу. И именно к АТС предъявляются действительно серьезные требования к надежности.
В третьих, качество связи и надежность сервисов по сравнению с "старомодными телефонами" повысились. Может отметить любой, звонивший по межгороду в 80-е.
Re[6]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, Gaperton, Вы писали:
G>Недостаточно. Во-первых, надежность телефонного аппарата здесь не при чем. Причем здесь — сервисы связи. Но раз уж зашла речь о телефонах — смартфоны строго говоря телефонами не являются, у них основное предназначение не разговоры вести. "Телефон" — это, например, современный IP телефон.
Я не про аппарат. Я именно про надежность сети, в плане предоставления базовых услуг связи.
G>В третьих, качество связи и надежность сервисов по сравнению с "старомодными телефонами" повысились. Может отметить любой, звонивший по межгороду в 80-е.
Качество передачи голоса, да, повысилось. В остальном, стало хуже (я не с межгородом сравниваю, он 20-30 лет назад просто не работал, я про локальные звонки, которые, как раз, работали очень надежно).
Re[7]: Двадцать основных принципов, без которых нельзя обойтись при создании над
Здравствуйте, Pzz, Вы писали:
G>>Недостаточно. Во-первых, надежность телефонного аппарата здесь не при чем. Причем здесь — сервисы связи. Но раз уж зашла речь о телефонах — смартфоны строго говоря телефонами не являются, у них основное предназначение не разговоры вести. "Телефон" — это, например, современный IP телефон.
Pzz>Я не про аппарат. Я именно про надежность сети, в плане предоставления базовых услуг связи.
Про связь все ровно наоборот. Современный UMTS обеспечивает на порядок более надежную и качественную связь, чем древний AMPS . Он, например, с отраженным сигналом в городе куда как лучше умеет работать .
Современную проводную связь тоже никак не сравнить с олдскульной, гхм, релейной коммутацией. Ни в плане качества, ни в плане надежности.
G>>В третьих, качество связи и надежность сервисов по сравнению с "старомодными телефонами" повысились. Может отметить любой, звонивший по межгороду в 80-е.
Pzz>Качество передачи голоса, да, повысилось. В остальном, стало хуже (я не с межгородом сравниваю, он 20-30 лет назад просто не работал, я про локальные звонки, которые, как раз, работали очень надежно).
Как это не работал? Работал. Я лично говорил по междугородней связи из почтовых отделений. Жесть. Шипит, скворчит, булькает, и соседние разговоры слышно.
Локальные разговоры по тогдашним проводным телефонам правильно сравнивать с современными проводными. Сейчас они работают на голову надежнее.
Re: Двадцать основных принципов, без которых нельзя обойтись при создании надежн
Здравствуйте, Титов Анатолий Анатольевич, Вы писали:
Прочитал статью. Сделал такие выводы:
1. Статья носит декларативный, а не процедурный характер.
2. Сведения, изложенные в статье, известны и преподаются в любом вузе, обучающем специальности «программное обеспечение вычислительной техники и автоматизированных систем».
3. Проблемы с внедрением процессов разработки ПО связаны не с тем, что люди не знают, ЧТО нужно делать. Они связаны с тем, что люди не понимают, КАК это нужно делать.
4. Чтобы статья была полезной, она должна содержать методики и конкретные примеры применения изложенного в статье материала. Иными словами, статья должна отвечать на вопрос «КАК», а не «ЧТО».
Чтобы показать, как могла бы выглядеть полезная статья о процессах разработки программного обеспечения, далее рассмотрю лишь несколько вопросов из исходной статьи, конкретизирую их и иллюстрирую примерами (см. здесь).
.
