アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
完璧主義ですか? (スコア:1)
別に死人さえでなければ、少しぐらい失敗してもいいのじゃない。
というか、100%の成功しかゆるされないプロジェクトって、
無理ありすぎでしょう。
どれくらいの確立で失敗しても大丈夫なのかの、
リスク管理をしているのかは、気になりますが、、、。
というか、デスマーチです。 (スコア:4, すばらしい洞察)
失敗が、信頼性が問題になると、とたんに部品に実績のある骨董品を使えという圧力が増します。絶対に死なない衛星にしろという下知が下って、三軸衛星の筈がスピンモードを持つ羽目になります。素人設計では不安だと、大手メーカを中間に噛ませようとします。”緊急モード””サバイバルモード”を追加しろと、
Re:というか、デスマーチです。 (スコア:0)
>失敗は許容しない」というのは、リスクコントロール以前の
>問題ですね。
これまでに失敗も計算に入れているプロジェクトがあったら教えてちょうだいな。
mizuki殿。
高信頼性設計とは、失敗への対処。 (スコア:2, 興味深い)
「無欠陥なソフトウェアを作るのは当然だ。ハナから欠陥を前提にしてどうする。」
そんなセリフ、シラフで言われるとは思ってませんでした。
もしセンサの一つに不具合が発生したとしても、それが致命的にならないように設計するのは当然でしょう。
放射線で計算機のポインタが吹っ飛んだとしても、致命的な誤動作なくリブートを保証するシステムは、致命的でない誤動作を許容することは必須でしょう。
地上側の不注意で発行された間違ったコマンドから、システムを保護するのは当然過ぎる設計でしょう。
冗長設計というもの自体が、失敗に対応するためのシステムですよね。
当たり前の話です。設計者は、失敗に備えましょう。
失敗に対処できないのは、不注意な設計者と傍観者だけです。
Re:というか、デスマーチです。 (スコア:2, 興味深い)
>>「ハイリスクである事はわかっている。しかし、
>>失敗は許容しない」というのは、リスクコントロール以前の
>>問題ですね。
>これまでに失敗も計算に入れているプロジェクトがあったら教えてちょうだいな。
>mizuki殿。
リスクコントロールの話なのに、これではただの茶々入れにしか過ぎないでしょ。
普通、あらゆるプロジェクトの開始前に、
・失敗する確率
・失敗した際に、ノウハウ蓄積やスピンオフで回収できるコスト
等も考慮した上でGo/NoGoの判断を下しません?
逆に、失敗を全く計算に入れていないリスクコントロールがあったらおしえてちょうだいな。
#129329のAC殿。