既存の情報システムの再構築における要件定義あるいは設計に関する質問です。


既存アプリケーションを、新しい技術・プラットホームなどで再構築する際に、既存のアプリケーションのソースコードを開示がされれば、その既存アプリケーションの全機能をソースコードから解析できるために、要件定義あるいは設計の精度が増す、あるいはユーザ側の関与を減らせるという意見があります。

個人的には賛成できないのですが、反論するためには材料が必要です。
ソースコードのみから初めて見るアプリケーションの機能をすべて把握することは難しく、現実的ではないということが書かれている論文、記事(書籍、雑誌、Webなど)があれば教えて欲しいです。

既存アプリケーションが、古いメインフレームで動いていてCOBOLの解析ができるエンジニアが少ないというような状況は想定せずに、技術的には比較的新しいWindowsやVB.NETなどを使っているケースを考えています。

回答の条件
  • 1人2回まで
  • 登録:2009/09/09 09:54:41
  • 終了:2009/09/16 09:55:03

回答(2件)

id:azuco1975 No.1

azuco1975回答回数613ベストアンサー獲得回数162009/09/09 10:21:28

ポイント35pt

>その既存アプリケーションの全機能をソースコードから解析できるために、

>要件定義あるいは設計の精度が増す、あるいはユーザ側の関与を減らせるという意見があります。

これがそのままデメリットでなのですが・・・。

勝手な要件定義、バグありの設計をされ、ユーザーが余り関与しないので、出来上がったシステムは、

システムとしては正しいが、業務としては使えないものになる。

ソースコードを開示の前に、既存システムの要件定義書、設計書を開示するのが先でしょう。

それがないのなら、ソース開示は必要でしょうね。

id:mikamikoujijp

例え、既存アプリケーションの再構築であっても、アプリケーションの要件や仕様はユーザの協力のもと明確に定義するべきだと思うんです。

よって、既存アプリケーションの要件定義書、設計書も解決策にはならないと考えています。

A社が作った要件定義書、設計書、ソースコードを別のB社に渡して、B社が全ての機能を把握することを要求するのは無理がある、というようなことを主張したいんです。

そのために第三者の客観的で、できるだけ権威があるような記事や論文があると助かるんです。

2009/09/09 10:34:56
id:OhYeah No.2

オーイェー回答回数81ベストアンサー獲得回数142009/09/09 13:42:22

ポイント35pt

>A社が作った要件定義書、設計書、ソースコードを別のB社に渡して、B社が全ての機能を把握することを要求するのは無理がある

B社が、要件定義書、設計書、ソースコードだけをみて、実行ファイルを実行しないのなら、


http://ja.wikipedia.org/wiki/%E9%9D%99%E7%9A%84%E3%82%B3%E3%83%B...

実行時エラーを全て検出することは不可能であることが証明されており、任意のプログラムが正しく動作するかエラーになるかを判定する機械的手法はない。これは1930年代のアラン・チューリングやライスの研究で判明した

とありますね。

id:mikamikoujijp

それは、別の議論としては興味深いですけど、ちょっとボクの意図しているものとは違いますね。

例えば、この「はてな」の様々なシステムが、A社によってASP.NETで作られたと仮定します。

はてな社は、全てのシステムを別のB社にPHPで作り直して欲しいとします。

通常、システム構築をする際は要件定義や設計をしますが、それらを大幅にはしょって、その代わりに既存システムの全ASP.NETの

ソースコードを提供するから、B社は既存の機能をすべてPHPで再現できるだろーと主張するのは無理がある、あるいは非現実的という、第三者的な記事や論文が欲しいです。

2009/09/09 16:24:27
  • id:standard_one
    コンピュータは書かれている命令を実行するだけです。
    論理バグのあるプログラムをコンピュータに実行させれば、コンピュータは人間の命令どおり清く正しく論理バグを実行します。
    つまり「そう書いてある」と「そう動かしたかった」は別の話です。
    まぁこういう事柄は、ちゃんと試験する職場ではドキュメントもちゃんとしているし、ちゃんと試験しない職場はドキュメントもないのが相場ですよね。
    「既存アプリケーションの全機能をソースコードから解析できる」などという間の抜けた考え方をしてる人間は間違いなく後者の職場しか知らない、素人に毛の生えた程度の人間でしょうから、理想を言えばそういう人とは関わらないのが吉かと。

    よっぽどプロジェクトの規模が小さければ別ですが、典型的なデスマの入り口に立ってると思いますよ。
  • id:mikamikoujijp
    mikamikoujijp 2009/09/09 10:57:48
    その通りで、ボクは分かっているんです。
    分からない人が分かるようにするための、材料が欲しいんです。

    関わらないという選択肢はなく、むしろ既に関わっているので質問しています。
  • id:OhYeah
    「ソースコードからの解析はするな」という資料でなく、ある意味逆の資料になりますが、

    [リファクタリング―プログラムの体質改善テクニック]や[レガシーコード改善ガイド]
    という書籍はどうでしょうか(※URLは下に貼っておきます。)
    既存のコードを分析して新しいコードを書くときの注意点が書かれている本です。
    ただ、書き換えたコードが前のコードと同じ動きをしているのかを誰がどうやって確かめるのかなど
    実際にプロジェクトで気になりそうな点についてかなり細かく書かれています。

    そのプロジェクトでの注意点が、実現するのがそんなに簡単じゃなかったりする感じのことが多いです。
    ※全員のモチベーションが高いチームだったり、みんなを引っ張っていけるリーダーがいたりしないと
     今までのやり方の方が安定するんじゃないかと思ってしまうくらいです。

    ということで、
    「やるならコレくらいしっかりやらなきゃダメなんだ・・・」という方向で攻めるのはどうでしょうか?


    http://www.amazon.co.jp/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E2%80%95%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%81%AE%E4%BD%93%E8%B3%AA%E6%94%B9%E5%96%84%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF-Object-Technology-%E3%83%9E%E3%83%BC%E3%83%81%E3%83%B3-%E3%83%95%E3%82%A1%E3%82%A6%E3%83%A9%E3%83%BC/dp/4894712288

    http://www.amazon.co.jp/%E3%83%AC%E3%82%AC%E3%82%B7%E3%83%BC%E3%82%B3%E3%83%BC%E3%83%89%E6%94%B9%E5%96%84%E3%82%AC%E3%82%A4%E3%83%89-Object-Oriented-SELECTION-%E3%83%9E%E3%82%A4%E3%82%B1%E3%83%AB%E3%83%BBC%E3%83%BB%E3%83%95%E3%82%A7%E3%82%B6%E3%83%BC%E3%82%BA/dp/4798116831
  • id:mikamikoujijp
    mikamikoujijp 2009/09/10 06:22:56
    ありがとうございます。
    ですが、ちょっと問題の焦点と方向性がずれている気がします(^_^;

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません