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

L>Наибольшая сложность всех подобных проектов сейчас приходится как раз на программную часть. И, соответственно, львиная доля рисков тоже.
Угу. Только сколько угодно опытный программист не заменит инженеров отвечающих за качество/надежность, тестирующих аппаратуру на программно-аппаратных стендах, составляющих спецификации и алгоритмы на основании которых создается чисто программная часть.

L>Но, при этом именно софт — как раз наименее затратная часть с точки зрения изменений. Более того, софтом можно нивелировать и компенсировать как принципиальные аппаратные ограничения, так и возникающие неисправности по ходу мисии.
Можно, но сколько угодно опытный программист не знает когда и как это возможно. Если он только программист.

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

L>>Наибольшая сложность всех подобных проектов сейчас приходится как раз на программную часть. И, соответственно, львиная доля рисков тоже.
_>Угу. Только сколько угодно опытный программист не заменит инженеров отвечающих за качество/надежность, тестирующих аппаратуру на программно-аппаратных стендах, составляющих спецификации и алгоритмы на основании которых создается чисто программная часть.

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

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


L>>Но, при этом именно софт — как раз наименее затратная часть с точки зрения изменений. Более того, софтом можно нивелировать и компенсировать как принципиальные аппаратные ограничения, так и возникающие неисправности по ходу мисии.
_>Можно, но сколько угодно опытный программист не знает когда и как это возможно. Если он только программист.

Опять путаем необходимое условие с достаточным.

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