アカウント名:
パスワード:
仕様書やドキュメントがないからメンテも移行も出来ないと受け取れる。これは別の言語に置き換えてもあんまし変わらない気もするな～
700万行にも及ぶ仕様書もドキュメントも無い○○言語で書かれた給与システムのメンテもしくは新システム導入
なわけだが、実際問題こんなお題のモノは炎上どころじゃないプロジェクトになりそうな予感・・・
入力・出力・状態遷移の動作仕様が明確になっていれば、その動作仕様の範囲内で実装方法を自由に変えられる(修正できる)。
一方、動作仕様が明確になっていないと、ソースコードの自身が動作仕様になっていく。つまり、ソースコードの改変は動作仕様の変更を意味するようになる。かくして、700万行の動作仕様のプログラムが生まれたというわけだ。
すべての動作仕様を理解する必要はないとは言え、そう考えると正気の沙汰ではない分量ではある。
・近代的なソフトウェア開発の手法が導入される以前のプロジェクトで、・COBOLが採用されているのは古いプロジェクトが多いことから相関関係が生まれるんでしょう。因果関係は知らね
COBOLで700万行もあるんじゃ仕様を起こしなおすのも大変でしょうねぇ。メインフレームから他のシステムへ移行した場合コード量は一気に跳ね上がるでしょう。もっともほとんどの追加コードはUIとか例外処理に費やされるんですが。
大昔、DoDは各社のCOBOLコンパイラの検定（仕様適合確認）をやっていた。そのためのテストベンチで本当に必要なコードは1割もなかったりして。
書き込みが遅れてこの記事今更なんだが、
COBOLや仕様書が無いことは問題じゃないはず！最新のPM論と開発プロセスを駆使すれば、失敗しないんだよね！と問いつめてみたい。
プロジェクト憲章は失敗の定義から始めますか・・・
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
COBOLが原因ではない (スコア:5, すばらしい洞察)
仕様書やドキュメントがないからメンテも移行も出来ないと受け取れる。
これは別の言語に置き換えてもあんまし変わらない気もするな～
700万行にも及ぶ仕様書もドキュメントも無い○○言語で書かれた給与システムのメンテもしくは新システム導入
なわけだが、
実際問題こんなお題のモノは炎上どころじゃないプロジェクトになりそうな予感・・・
Re:COBOLが原因ではない (スコア:1)
入力・出力・状態遷移の動作仕様が明確になっていれば、その動作仕様の範囲内で実装方法を自由に変えられる(修正できる)。
一方、動作仕様が明確になっていないと、ソースコードの自身が動作仕様になっていく。つまり、ソースコードの改変は動作仕様の変更を意味するようになる。かくして、700万行の動作仕様のプログラムが生まれたというわけだ。
すべての動作仕様を理解する必要はないとは言え、そう考えると正気の沙汰ではない分量ではある。
Re: (スコア:0)
・近代的なソフトウェア開発の手法が導入される以前のプロジェクトで、
・COBOLが採用されているのは古いプロジェクトが多い
ことから相関関係が生まれるんでしょう。因果関係は知らね
Re: (スコア:0)
COBOLで700万行もあるんじゃ仕様を起こしなおすのも大変でしょうねぇ。
メインフレームから他のシステムへ移行した場合コード量は一気に跳ね上がるでしょう。
もっともほとんどの追加コードはUIとか例外処理に費やされるんですが。
Re: (スコア:0)
大昔、DoDは各社のCOBOLコンパイラの検定（仕様適合確認）をやっていた。そのためのテストベンチで本当に必要なコードは1割もなかったりして。
Re: (スコア:0)
書き込みが遅れてこの記事今更なんだが、
COBOLや仕様書が無いことは問題じゃないはず！
最新のPM論と開発プロセスを駆使すれば、失敗しないんだよね！
と問いつめてみたい。
プロジェクト憲章は失敗の定義から始めますか・・・