土曜日, 7月 14, 2007

要求考古学 Part.2

前回に引続き、6月末の要求開発アライアンス 勉強会合宿で見つけたキーワード「要求考古学」に関する考察です。いくぶん妄想(暴走)気味ですのでご注意を。記載内容は私の考えであって、内容は誤っているかもしれません。


■近代的要求考古学

現行システムを「観察する」ことによって得られる情報は、限られています。というわけで、より深く調査をするのであれば、「分解する」する必要があります。というわけで、仮にこれを(前回評した古典的要求考古学に対するものとして)近代的要求考古学アプローチとでも呼ぶことにします。
「分解する」とひとことで言っても、実際のところは設計作業をもういちど行う、つまり「再設計する」事に等しく、ひょっとしたら「分析」「解析」というキーワードが適切かもしれません。
言うまでもなく、現行システムを完全に解体し設計書を全て再作成することは困難なだけではなく、その労力を考えると現実的ではありません。また、次のプログラミングの基本法則により、実際の作業は見かけよりも難しいと言えます。引用元は書籍化もされている、システム開発に関する有名BlogのJoel on Softwareからです。

プログラマがいつでも既存のコードを捨てて最初からやり直したいと思うのには、ちょっとした理由がある。その理由というのは、古いコードがクズだと思っているからだ。そしてここに興味深い観察事実がある。 彼らはたぶん間違っている。 彼らが古いコードがクズだと思うのは、プログラミングの基本法則のためだ。

プログラムというのは書くのより読むほうが難しい。

これがコード再利用がかくも難しい理由だ。あなたのチームのプログラマが、文字列を分割して配列にするための関数に、みんな違うものを使っているのはこのためなのだ。彼らが自分で関数を書いている理由は、古い関数をどうやって使うのか調べるよりも、そのほうが簡単だし、楽しいからだ。
Joel On Software/Joel Spolsky
■分解する方法について

さて、分解の方法としては、いくつかの戦略を取る事ができます。それぞれのメリットやデメリットを整理してみます。
  • データ中心アプローチ
    • 入力(人間系や外部システムから)から出力(画面や帳票、外部システムまで)まで、データの流れを中心に分解する方法です。一般的にはデータフローダイアグラム(DFD)を作成していく形になります。(要求開発アライアンスの提唱する開発方法論 Openthologyでは、UMLクラス図をカスタマイズしたTFP分割手法を提言していますが、これも一種のデータフローダイアグラムと言えます)
    • メリット
      • システムの堅牢性、確かさの側面で深く分析がされます。
      • 機械的な作業であるため、人海戦術を用いて実行することができます。
      • 誤解の入る余地があまりありません
      • システム対象業務固有の知識を、あまり意識する必要がありません。
    • デメリット
      • 対象の規模にもよりますが、コストと期間を要します。
      • システムの使いやすさや、特徴は表現されません。
      • 分析結果は利用者には分かりにくいものになります。よって、レビューなどによる確認が難しくなります。
  • 機能中心アプローチ
    • システムの有する機能(メニューや機能名)中心にシステムの構成要素を分解する方法です。結果として、システムユースケース図に近い成果物を作成する事になります。
    • メリット
      • システムの使いやすさや、特徴が現れます。
      • 利用者にもわかりやすい分析アプローチのため、分析作業やレビューに参加してもらうことが容易です。
    • デメリット
      • データ中心アプローチと異なり、分析に漏れが発生する可能性が高くなります。これは、データと異なり機能は隠されたり、分散されている事があるからです。
      • システム対象業務固有の知識が必要です。用語集などを作成しなければ、誤解を生じる可能性があります。
  • 構造中心アプローチ
    • システムを構成するプログラムの構造を中心にした分析です。一種のリバースエンジニアリングに近く、コードを元に分析を行います。データライフサイクルの観点でプログラムとデータの関係を整理する(CRUD図)、プログラムの構造を図式化する(UMLクラス図等)ことになります。
    • メリット
      • 作業の機械化が可能です(実際に、このような分析を行うツールは様々なものがあります)
    • デメリット
      • 既存システムの品質(保守性やコードの可読性、充分な共通化)によっては、結果が使い物にならない可能性があります。スパゲティプログラムを分析しても、わかる事は限られています。
      • 分析結果は利用者には分かりにくいものになります。よって、レビューなどによる確認が難しくなります。

ここまで書いて息が切れました。というわけで、次回に戦略面での考察を続けます。

0 件のコメント: