Здравствуйте, t_o_l, Вы писали:

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

На каком рынке?

99.(9)% софтвария не используют в опасных для человека системах не по причине отсутствия Большой Печати, а по причине, что в таких системах этот софтварий нафиг не нужен. Взять, к примеру, веб провсер — к чему ему самолетная сертификация?

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

Здравствуйте, Gaperton, Вы писали:

G>А вот телефонистов слушать не будем. Во-первых, это не про самолеты с ракетами и реакторами, т.е. объективно недостаточно надежно, и вообще — некруто, потому, что слишком понятно.

Телефонисты успешно борятся с избытком надежности. Достаточно сравнить надежность старомодных проводных телефонов с гораздо более технологически современной сотовой связью. Старомодный телефон на моей памяти ломался считанное количество раз, с сотовым что-то не работает постоянно.

Здравствуйте, Pzz, Вы писали:

Pzz>99.(9)% софтвария не используют в опасных для человека системах не по причине отсутствия Большой Печати, а по причине, что в таких системах этот софтварий нафиг не нужен. Взять, к примеру, веб провсер — к чему ему самолетная сертификация?

Pzz>Не надо относиться к Большой Печати, как к некоторому самоценному идолу. Она — лишь одно из требований заказчика, наряду с прочими. А требования зависят от предназначения программы. Нужна заказчику самолетная сертификация — значит, будем работать по самолетному процессу. Не нужна — будем использовать более дешевый процесс.

Да некто же не заставляет вас разрабатывать ПО согласно авиационным стандартам, а затем его сертифицировать. Это действительно долго, дорого и сложно. Смысл данной статьи — вот такие принципы лежат в основе разработки авиационное ПО, посмотрите, может и для разработки вашего ПО, вы найдете в этом что-то полезное, что затем положительно скажется на его надежности.

Здравствуйте, 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С и различными сотрудниками сертифицирующих органов. Так что можете мне поверить, я немножко знаком с различными стандартами авиационной сертификации и их положениями, причем не из википедии.

Здравствуйте, t_o_l, Вы писали:

__>Да некто же не заставляет вас разрабатывать ПО согласно авиационным стандартам, а затем его сертифицировать. Это действительно долго, дорого и сложно. Смысл данной статьи — вот такие принципы лежат в основе разработки авиационное ПО, посмотрите, может и для разработки вашего ПО, вы найдете в этом что-то полезное, что затем положительно скажется на его надежности.

Тогда subject надо сменить.

Здравствуйте, A.Lokotkov, Вы писали:

AL>Здравствуйте, t_o_l, Вы писали:

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

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

А программное обеспечение само по себе — вещь странная: потрогать ее нельзя, нельзя повесить на нее груз, и определить при каких нагрузках оно сломается, нельзя так же запихнуть ПО в холодильник и выяснить при каких температурах оно перестанет функционировать. Оно так же очень сильно зависит от "железа" на которым оно работает и от другого программного окружения, в котором оно работает. Поэтому мы не можем точно утверждать, что вот с такой вероятностью наше ПО сломается, как это делается для "железа". Поэтому в авиации для ПО идут другим путем: исходя из нашего опыта разработки программного обеспечения мы описали несколько процессов его создания. С каждым процессом мы связали определенную степень вероятности отказов ПО. Выбирайте нужный вам процесс, исходя из требуемой частоты отказов, и следуйте ему. Но даже если вы будете точно следовать выбранному процессу создания ПО, мы не гарантируем вам, что ваше ПО будет иметь желаемую частоту сбоев. Но вероятность того, что это будет так — достаточно высока, хотя и не 100%.
Если "мы хотим не то, что нужно, да еще и запланировали не так, как было надо на самом деле" то, согласно DO-178B/C, про слова "надежность" и "безопасность" мы должны забыть.

Здравствуйте, Pzz, Вы писали:

G>>А вот телефонистов слушать не будем. Во-первых, это не про самолеты с ракетами и реакторами, т.е. объективно недостаточно надежно, и вообще — некруто, потому, что слишком понятно.

Pzz>Телефонисты успешно борятся с избытком надежности. Достаточно сравнить надежность старомодных проводных телефонов с гораздо более технологически современной сотовой связью. Старомодный телефон на моей памяти ломался считанное количество раз, с сотовым что-то не работает постоянно.

Недостаточно. Во-первых, надежность телефонного аппарата здесь не при чем. Причем здесь — сервисы связи. Но раз уж зашла речь о телефонах — смартфоны строго говоря телефонами не являются, у них основное предназначение не разговоры вести. "Телефон" — это, например, современный IP телефон.

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

В третьих, качество связи и надежность сервисов по сравнению с "старомодными телефонами" повысились. Может отметить любой, звонивший по межгороду в 80-е.

Здравствуйте, Gaperton, Вы писали:

G>Недостаточно. Во-первых, надежность телефонного аппарата здесь не при чем. Причем здесь — сервисы связи. Но раз уж зашла речь о телефонах — смартфоны строго говоря телефонами не являются, у них основное предназначение не разговоры вести. "Телефон" — это, например, современный IP телефон.

Я не про аппарат. Я именно про надежность сети, в плане предоставления базовых услуг связи.

G>В третьих, качество связи и надежность сервисов по сравнению с "старомодными телефонами" повысились. Может отметить любой, звонивший по межгороду в 80-е.

Качество передачи голоса, да, повысилось. В остальном, стало хуже (я не с межгородом сравниваю, он 20-30 лет назад просто не работал, я про локальные звонки, которые, как раз, работали очень надежно).

Здравствуйте, Pzz, Вы писали:

G>>Недостаточно. Во-первых, надежность телефонного аппарата здесь не при чем. Причем здесь — сервисы связи. Но раз уж зашла речь о телефонах — смартфоны строго говоря телефонами не являются, у них основное предназначение не разговоры вести. "Телефон" — это, например, современный IP телефон.

Pzz>Я не про аппарат. Я именно про надежность сети, в плане предоставления базовых услуг связи.

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

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

G>>В третьих, качество связи и надежность сервисов по сравнению с "старомодными телефонами" повысились. Может отметить любой, звонивший по межгороду в 80-е.

Pzz>Качество передачи голоса, да, повысилось. В остальном, стало хуже (я не с межгородом сравниваю, он 20-30 лет назад просто не работал, я про локальные звонки, которые, как раз, работали очень надежно).

Как это не работал? Работал. Я лично говорил по междугородней связи из почтовых отделений. Жесть. Шипит, скворчит, булькает, и соседние разговоры слышно.

Локальные разговоры по тогдашним проводным телефонам правильно сравнивать с современными проводными. Сейчас они работают на голову надежнее.

Здравствуйте, Титов Анатолий Анатольевич, Вы писали:

Прочитал статью. Сделал такие выводы:

1. Статья носит декларативный, а не процедурный характер.
2. Сведения, изложенные в статье, известны и преподаются в любом вузе, обучающем специальности «программное обеспечение вычислительной техники и автоматизированных систем».
3. Проблемы с внедрением процессов разработки ПО связаны не с тем, что люди не знают, ЧТО нужно делать. Они связаны с тем, что люди не понимают, КАК это нужно делать.
4. Чтобы статья была полезной, она должна содержать методики и конкретные примеры применения изложенного в статье материала. Иными словами, статья должна отвечать на вопрос «КАК», а не «ЧТО».

Чтобы показать, как могла бы выглядеть полезная статья о процессах разработки программного обеспечения, далее рассмотрю лишь несколько вопросов из исходной статьи, конкретизирую их и иллюстрирую примерами (см. здесь).