アカウント名:
パスワード:
これは、みずほ証券が苦しい。
無理筋を通すため屁理屈をこねるしかない立場は判るが、そのためにソフトウェア工学を誤用してまで持ち出すのは見苦しい。一般には「ソフトウェア工学」が何なのか判らない人が多いので、これで要らぬ誤解が広まらないことを願う。
ソフトウェア工学的には「実装と仕様ドキュメントは整合している『べき』だが、現実にはそうではない」という立場。では、どうするか。仕様から実装への自動生成なり、実装から仕様へのリバースエンジニアリングなり、一貫性をできるだけ(100%は不可能)維持するためのソフトウェアプロセスなり、実装と仕様を一致させ
ソフトウェア工学的には「実装と仕様ドキュメントは整合している『べき』だが、現実にはそうではない」という立場。では、どうするか。仕様から実装への自動生成なり、実装から仕様へのリバースエンジニアリングなり、一貫性をできるだけ(100%は不可能)維持するためのソフトウェアプロセスなり、実装と仕様を一致させる文芸的プログラミングなり、『べき』でしかない理想論を、精神論ではなく科学的・工学的に実現するのがソフトウェア工学。
大規模システム構築の経験がある技術者ならだれでも知っていることだが、ドキュメントと実装が乖離するのは現実。アジャイルでもウォーターフォールでも。一方、前記の研究はまだ完成には程遠い(完璧な自動生成w、完璧な仕様書生成w)。ならば、現実に起こっている問題に対し、実践可能な選択肢の中から、コスト・効果の兼ね合いを考えつつ最適の選
> ドキュメントのメンテは”当然”の事
そもそもここに錯誤があって、元記事の1行まとめやタレコミが恣意的な誘導を行っているとしか思えないんだが、東証がメンテしていないっていうドキュメントはごく一部のみなんだよね。なのに、一読しただけでは、まるですべてのドキュメントをメンテしないように受け取れるように書いている。このストーリーでも案の定、大量に釣られてる。
それもメンテしていないのは、ソースコードと1対1に対応する実装と等価レベルの詳細なやつ。「a++」の代わりに「変数aに1を加える」といった類のもの。ここの読者なら、書くことが馬鹿らしい、無駄って思え
そういう話じゃなくてあなたのおっしゃっているような上位のドキュメントでもメンテしておらず、担当者のノウハウという名の業務知識として埋没する事がありかつそういう現場ではシステムの整合性を管理把握している人間がいないので書いたんですが
ドキュメント化しない事の欠点を一つどの現場でも担当者の質は新規開発が最高で保守開発では年々劣化するのが常上記で書いたノウハウ=業務知識が単なる対処療法なのか、基本的な仕様なのかを把握出来ていないこれがドキュメント整備がなされていない業務系システム開発の現場だと思うのですがあなたの携わっていたドキュメント整備がなされていない業務系システムでは状況が異なるのでしょうか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
ソフトウェア工学の誤用甚だしい (スコア:1)
これは、みずほ証券が苦しい。
無理筋を通すため屁理屈をこねるしかない立場は判るが、
そのためにソフトウェア工学を誤用してまで持ち出すのは見苦しい。
一般には「ソフトウェア工学」が何なのか判らない人が多いので、これで要らぬ誤解が広まらないことを願う。
ソフトウェア工学的には「実装と仕様ドキュメントは整合している『べき』だが、現実にはそうではない」という立場。
では、どうするか。仕様から実装への自動生成なり、実装から仕様へのリバースエンジニアリングなり、
一貫性をできるだけ(100%は不可能)維持するためのソフトウェアプロセスなり、
実装と仕様を一致させ
Re: (スコア:0)
ソフトウェア工学的には「実装と仕様ドキュメントは整合している『べき』だが、現実にはそうではない」という立場。
では、どうするか。仕様から実装への自動生成なり、実装から仕様へのリバースエンジニアリングなり、
一貫性をできるだけ(100%は不可能)維持するためのソフトウェアプロセスなり、
実装と仕様を一致させる文芸的プログラミングなり、
『べき』でしかない理想論を、精神論ではなく科学的・工学的に実現するのがソフトウェア工学。
大規模システム構築の経験がある技術者ならだれでも知っていることだが、
ドキュメントと実装が乖離するのは現実。アジャイルでもウォーターフォールでも。
一方、前記の研究はまだ完成には程遠い(完璧な自動生成w、完璧な仕様書生成w)。
ならば、現実に起こっている問題に対し、実践可能な選択肢の中から、
コスト・効果の兼ね合いを考えつつ最適の選
Re: (スコア:5, 参考になる)
> ドキュメントのメンテは”当然”の事
そもそもここに錯誤があって、元記事の1行まとめやタレコミが恣意的な誘導を行っているとしか思えないんだが、
東証がメンテしていないっていうドキュメントはごく一部のみなんだよね。
なのに、一読しただけでは、まるですべてのドキュメントをメンテしないように受け取れるように書いている。
このストーリーでも案の定、大量に釣られてる。
それもメンテしていないのは、ソースコードと1対1に対応する実装と等価レベルの詳細なやつ。
「a++」の代わりに「変数aに1を加える」といった類のもの。
ここの読者なら、書くことが馬鹿らしい、無駄って思え
Re:ソフトウェア工学の誤用甚だしい (スコア:0)
そういう話じゃなくて
あなたのおっしゃっているような上位のドキュメントでも
メンテしておらず、担当者のノウハウという名の業務知識として埋没する事があり
かつそういう現場ではシステムの整合性を管理把握している人間がいないので書いたんですが
ドキュメント化しない事の欠点を一つ
どの現場でも担当者の質は新規開発が最高で保守開発では年々劣化するのが常
上記で書いたノウハウ=業務知識が単なる対処療法なのか、基本的な仕様なのかを把握出来ていない
これがドキュメント整備がなされていない業務系システム開発の現場だと思うのですが
あなたの携わっていたドキュメント整備がなされていない業務系システムでは状況が異なるのでしょうか?