アカウント名:
パスワード:
ソフトウェアのいいところはバグを潰しきれれば、その部分は安全であり、経年劣化や疲労などの心配をしないで済むということですね。事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
安全係数 (スコア:3, 興味深い)
ギリギリの安全係数で設計して、その代わりに検査で問題点を摘出するというアプローチしか取れません。
また、いったん飛び立ってしまえば着陸するまで修理は出来ないし、あちこち飛び回っているので、
どの時点で修理をするかを決め、必要機材を先回りして準備しておかなければいけないといった事情あり、
予測ということが重要でしょう。
これが地上の構築物であれば思いっきり安全係数を掛けて、検査を軽くするという
ライフサイクルコストを考えたアプローチも取れるのですが。
ソフトウェアのいいところはバグを潰しきれれば、その部分は安全であり、経年劣化や疲労などの心配をしないで済むということですね。
事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。
Re:安全係数 (スコア:1, 興味深い)
運用環境の違いや、それに合わせたコンフィギュレーションの差異なんかは個体差といって差し支えないし、そのような設定の変更を繰り返すうちに元に戻せなくなる場合も珍しくはない。交換=再インストールで解決したりとかね。
これをオペレーションの問題でありソフトの不備では無いと言い張るならそれで構わないけれど、現実にはそんなに厳密なオペレーションが可能な設計でもなければマニュアル等が完備されてるわけでもない場合が珍しくないわけです。そのような不備をも含めて「バグ」と称するなら確かに元コメントの言うとおりではあるけれど、見方によっては「ソフトウェアも経年劣化や疲勞を起こすし、そうなったら交換すれば良い」という考えの元、コストダウンを図っているといえなくもないでしょう。
個人的にそれよりも気になるのは「ソフトウェアに製造工程はなく試作品がそのまま出荷される」ということをよく理解してない開発者が非常に多いということですね。敢えて飛行機ではなくガレージキットで例えさせてもらいますが、ガレキなら試作品、つまり原型が「切った貼った削った盛った」のツギハギだらけであろうと、型さえしっかり取れば量産品は継目なしの一体成形で出荷することもできるわけです。ところがソフトウェアの場合、出荷される製品はあくまで試作品のコピー、ツギハギまでも含めた良くも悪くも完全なコピーなのです。
酷い場合、バグを潰すのではなく、バグによって壊されたデータの修正ルーチンを別途組み込む、といった場当たり的なツギハギが、必然性もないまま放置され、出荷されてしまうことすらも。で試験に漏れた特定の条件で修正ルーチンが走らなかったり、2回以上走ったりとか。