|
|
От
|
Flanker
|
|
|
К
|
tarasv
|
|
|
Дата
|
12.05.2009 22:41:15
|
|
|
Рубрики
|
ВВС;
|
|
Re: Новые проблемы...
> Методология разработки софта не соответсвует стандарту, сам софт при этом может быть работоспосбным и надежным но не сертифицируемым в принципе.
Ну так бывает редко если он работоспособен и надежен то "подогнать" методологию под готовый софт можно, к тому же в принципе стандарт не запрещает использовать отличную методологию доказательства, но разраб должен показать что результат будет гарантированно не хуже.
Так что это все детский лепет :)
Чтоб не быть голословным ниже цитата из КТ-254 (это документ на "железо", но в 178 то же самое они родственнные и тесно переплетаються, КТ-178 в нете не нашел завтра на работе посмотрю)
"1.7. Альтернативные методы или процессы
Методы или процессы, отличные о тех, которые описаны в настоящем документе, могут использоваться для обеспечения качества проектирования аппаратуры. Эти методы и процессы должны быть оценены на основе их способности удовлетворять применяемым правилам. Альтернативные методы или процессы должны быть одобрены сертифицирующим органом до их внедрения. Вместо прямого сравнения с применяемыми правилами заявитель может использовать следующее руководство для уменьшения риска программы при оценке альтернативных методов или процессов путем сравнения с данным документом. Условия оценки альтернативных методов и процессов могут включать: Условия, когда использование вместо процессов, предписанных данным документом, процессов, удовлетворяющих одной или более задачам Разделов 2-9, должны показать эквивалентный уровень обеспечения качества проектирования. Влияние предложенных альтернативных методов или процессов на удовлетворение задач обеспечения качества проектирования аппаратуры должно быть оценено. Влияние предложенных альтернативных методов или процессов должно быть оценено
Рациональность использования предложенных альтернативных методов или процессов должна быть подтверждена очевидностью того, что методы или процессы дадут ожидаемые результаты.