アカウント名:
パスワード:
でもそれはスペックには現れないのでなかなか評価されず後回しになるものです。 特に予算が決まっているお話(って事はほぼ全てだけど)では。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
でもさ・・・ (スコア:1)
衝突したりするわけですよね。以前も、航空管制の人的ミスで
ニアミス起こすわ急激な高度変化で乗客に怪我が出たりしま
したよね?
私もコーディングしますが、研究のコーディングで多少バグっ
たり対処後回ししたりします。今回のは人命にかかわること
だと思うので・・・ずいぶん簡単に考えてたなぁ>>NEC
-- gonta --
"May Macintosh be with you"
Re:でもさ・・・ (スコア:2, すばらしい洞察)
ずいぶん簡単に考えていた、ではなく、簡単にその影響を調べることが
できなかったのではないか、ということではないかと気になります。当
のNECが影響の大きさを検証できていなかった、または、検証できる環
境がなかったのではないか、と。ケアレスミスだった場合は、弁護の余
地はありませんが。
航空管制のハードっておそらく、そんな二つも三つも用意できるもので
はないですよね?全く本番とハードウェア的にも、入力データについて
も同じ環境構築を用意できないと、どれだけ単体テストをしても本番実
施までみえないことがあります。特に、今回の件、システム間連携の部
分がらみということで、評価がかなりやりにくいところだったのではな
いでしょうか。
また、NEC側の想定が甘かったとして、それを指摘できる人間が航空管
制部側にいない、ということも問題のひとつだと思います。そして、そ
れらを総合して、リスク管理のできていないNECと発注元の責任という
のも、決して少なくないと思います。
発注元がNECに対して損害賠償請求をしたりするのは勝手ですが、それ
でことを済ませるのではなく自分の足下を見直すようにするべきでしょ
う。
# 別に関係ないといえば関係ないんだけどAC
Re:でもさ・・・ (スコア:1)
影響の想定が甘かったのかそうでなかったのかはわかりませんが、結果としてはバグの存在を全く報告しなかったのが問題のように思います。
もしバグの存在が知られていれば、後者のプログラム変更と同時に該当バグを見つける試験項目を挙げることも、あるいはバグ修正も可能であったようにも思います。
ま、バグを報告して修正しないままにするというのも難しいかもしれませんが。
Re:報告していても(でもさ・・・) (スコア:1, 興味深い)
仕様上あり得ない。事実、(他の部分の)仕様が変わるまでなかった。
将来に渡ってあり得ないと断言できなくても、発生する可能性も断言できない。
手を加えることのリスクとコストを考えれば、顕在可能性の低い穴は放置が基本。
これはソフトに限らず、ハードでも、人事でも、何でもそうです。
あり得そうにない事態に対処するために、必要かどうかもわからない
冗長性を新たに追加するなんて、常識ではあり得ないことです。
国土交通省に報告が行っていても、同じ判断になったでしょう。
あり得そうにない事態を想定した時に起こる不具合なんてのは、いくらでもあります。
そんなものをいちいち報告していたら、妄想癖のレッテルを貼られて病院送りです。
NECが報告を上げてなかったと言っても、それが当然で、もしいちいち報告したら
国土交通省の業務はそれだけでパンクするでしょうね。
Re:報告していても(でもさ・・・) (スコア:1)
穴がある間、その周りを通る人は注意深くなります。
今回と同じ結果になる確率はそれなりに下がるでしょう。
>そんなものをいちいち報告していたら、妄想癖のレッテルを貼られて病院送りです。
それはただの言い訳ですな。
Re:報告していても(でもさ・・・) (スコア:0)
可能性のあるBUGは、必ず発現する。
コストで一番大きいのは (スコア:0)
でもそれはスペックには現れないのでなかなか評価されず後回しになるものです。
特に予算が決まっているお話(って事はほぼ全てだけど)では。
Re:報告していても(でもさ・・・) (スコア:0)
仕様上ありえない、ていったいどういうこと?
仕様を守っていない他のサブシステムの影響を受けない様にするのはよくあることだと思うけど。
今回の件に関して、NECに肯定的な意見が多いけど、汎用機のプログラムを開発してきたおじさんからすると、
信じられませんなぁ。
Re:報告していても(でもさ・・・) (スコア:1, 参考になる)
私も汎用機10年くらいやったことあるが、他システムから渡ってくるデータはファイルレイアウトをを信じてプログラムしてたよ。
それで数値項目に数値以外のものを入れられてたらABENDするはずだが、だからといって入り口のプログラムで全数値項目に対してNUMERICチェック入れたりはしなかったがなぁ。
なんせCOBOLの時代では1行いくらって費用計算もあったわけで、仕様上不要な処理をぼんぼん入れてたら「水増しするな」って言われることもあるし。
Re:でもさ・・・ (スコア:0, フレームのもと)
Re:でもさ・・・ (スコア:2, 参考になる)
Re:でもさ・・・ (スコア:1)
#IEのCSSバグが直ると、バグを前提としたページが崩れる、みたいな。
Re:でもさ・・・ (スコア:0)
Re:でもさ・・・ (スコア:1)
オープンソースの場合:
まず直す→不具合が出たらそこを直す→また不具合が出たらそこを直す→…
大規模な基幹システムとかでこの手法を使ったら、
一回のリリースごとに一人の首が飛んだりするのかなぁ…
#屋上から飛ぶのに比べれば首が飛ぶほうがマシだとは思う
# mishimaは本田透先生を熱烈に応援しています
Re:でもさ・・・ (スコア:0)
少なくとも問題が発生したらオープンソースでも安定版にはリリースはしないのであ?
オープンソースでもよく開発用ソースと比較的安定重視のバージョンを分けてます
効率的な離陸が出来なくなるだけですよ (スコア:2, 参考になる)
将来的には飛行機の管制業務の自動化もあるかもしれませんが、現在のところは計画をデータベース化して閲覧しやすくするためのシステムにすぎません。
すでに離陸した飛行機はフライトプランを承認され、計画通りに飛行する限りは安全を保証されているわけです。
衝突の回避と緊急時の指示は、自動化できないため従来通りに管制官が行っているので、FDPの障碍で飛行中や着陸する飛行機が事故を起こすことはありません。
・・・だからといって、対処を後回しにしていいわけじゃないんですけどね。実際、離陸は中断され、由緒正しい手作業での確認を余儀なくされたわけですし。
--- どちらなりとご自由に --- --
Re:効率的な離陸が出来なくなるだけですよ (スコア:2, 参考になる)
でも、管制官向けのストリップは適宜最新状況を反映した
ものが渡されるのだけど、FDPがとまるとこれができな
くなるわけなんですよ。
空港管制だった管制官の範疇に近いので管制官の技量でなん
とかなるだろうけど、航路管制だと割り振りが難しいことに
なりそうで、それが尾をひきそう。管制官のストレスにはな
りそうで、ミス誘発とかありそう。
# FADP関連のお仕事をむかしやっていたのでAC
最も集中するところ (スコア:2, 参考になる)
途中の飛行経路は高度毎に進行方向を分けられた、一方通行の高速道路みたいなものですから、飛行計画が適正である限りは非常事態の発生や、パイロットが故意に高度・速度・進路を変更しなければニアミスは発生しません。
そもそも途中経路は東京コントロールの管制下にある為、飛行計画承認の為に各空港から送られてきた最新情報が利用可能だと思います。
一番の問題はレーダー画面上に便名が表示されなくなることですが、トランスポンダーから送信される高度や速度の情報は表示されているので、管制官本人がチェックを怠らなければニアミスは回避できます。
当然、非常時に備えてレーダーと無線のみで全ての管制を行なう訓練は受けているはずですしね。それに、そもそも離陸中断で飛行中の期待の数は一定量以上に増えることなく、逆に減っていくわけですから。
レーダーとラジオが生きていれば、管制官は管制業務を継続することができます。頼りのレーダーすら使えなくなる状況 [cinemakun.net]というのも、想定できるわけですから・・・。
--- どちらなりとご自由に --- --
Re:効率的な離陸が出来なくなるだけですよ (スコア:1)
すみません、読売だけじゃわからないですね。
どこで資料を見かけたんだっけなー・・・。(w;
--- どちらなりとご自由に --- --
Re:効率的な離陸が出来なくなるだけですよ (スコア:2, 参考になる)
Re:でもさ・・・ (スコア:1)
などの場合は、正直いって「次回改修時にまとめて」といった 対策を取る事は多いんじゃないかと思います。
たとえ1行の修正でも、単体テスト・複合テスト・変更申請・入れ替え・立会いと
ものすごい手間とコストが掛かる場合がありますし
「修正したことによって問題が発生する」事も多々ありますから・・・