開発方法論のまとめ　２ - 実践！情報処理試験講座

　前回の開発方法論で全体的な流れを書いたので、今回は、（ウォーターフォールにおける）開発の各工程の流れについて書いてみたいと思います。

●全体的な流れ

まず、全体的な流れを書くと、

　　提案依頼（ＲＦＰ）→提案→開発会社決定
　　　↓------------------（外部）
　　要求分析（ＳＡ）
　　　↓
　　外部設計（ＵＩ・ＳＳ）
　　　↓
　　詳細設計（ＰＳ）
　　　↓
　　プログラミング＆単体テスト（ＰＧ・ＰＴ）
　　　↓
　　結合テスト（ＩＴ）
　　　↓
　　総合テスト（ＳＴ・ＯＴ）
　　　↓-------------------（外部）
　　検収
　　　↓
　　運用

提案依頼書から、開発会社決定までは、開発の範囲には入りません。
また、検収以降も開発会社からみると、開発の範囲には入りません。

なので、上記の工程を含む内側の開発工程について書きます。

●提案依頼（ＲＦＰ）→提案→開発会社決定

　発注元（＝お客さん）が、受託見込み会社（＝開発会社（ただし見込み））に対し、
　ＲＦＰを示して、開発の提案（開発内容、費用、期間など）をしてもらい、
　発注元が、チェックシートなどをもとにチェックして？（いや、テキトーに）
　開発会社を決めるという工程です。

　なお、ＲＦＰの日本語訳として、
　　　民間の場合は、「提案依頼書」と訳し、
　　　国、自治体の場合は、「調達仕様書」と訳します。

　提案依頼書の見本としては、ＩＴコーディネーター協会が、

　　RFP/SLA見本
　　http://www.itc.or.jp/foritc/useful/rfpsla/rfpsla_doui.html

　として、見本がダウンロードできるようになっています。

　また、調達仕様書の記載内容は
http://www.duo.co.jp/images/topics/20090225seminar_02arakane.pdf
の１４枚目のシートをみるとはやいです。

また、そこにでてくる、「情報システムに係る政府調達の基本指針」は
http://www.soumu.go.jp/main_sosiki/gyoukan/kanri/pdf/070301_1.pdf
でしょうか？１８ページから、調達仕様書について書かれています。

　理想的には、このＲＦＰにおいて、

　・今回開発しようとしている内容
　・ドメインモデル（ＥＲ図で）

などが、示されることが理想です。

　なお、国の調達の場合、まだ生きてるんでしょうかね？ＥＡというものがあって
　ＥＡポータル
http://www.meti.go.jp/policy/it_policy/ea/index.html
　における、最適化計画などが、考慮されます。

　民間などでは、情報処理試験的には、ＢＳＣ（バランススコアカード）などに基づいて
　何を開発すべきか考えることになっていますが。。。勢いで決めているかも？

　とここまで書いてきましたが、現実問題、中小企業の発注では、ＲＦＰはないこともあります
　（提案してもらう必要がない：もともと１社にきまっているから）

●要求分析（ＳＡ）

　上記のＲＦＰに書かれた開発内容にもとづき、何を開発するかを規定します
　（どうやって？はこの後の設計工程になります）

　やるべきことは以下の（１）〜（５）です

- - -

（１）なにを開発するかを挙げる→ユースケース
　かならず開発したいものはあるはずです。なければ、その時点でプロジェクト終了です。
　開発したいもの１つを１ユースケース（＝利用場面）とします。
　できれば、ここで、入出力を定義したいものです。

　　このまとめ方ですが、
　　　　　ＵＭＬの場合は、ユースケース図と、ユースケースシナリオ（言葉で書く）
　　　　　国の場合は、ＤＭＭ（機能構成図）にまとまります。

- - -

（２）開発したいものを、現在どう行っていて、それをどう変えたいかを決める
　　　→業務フロー／アクティビティ

　上記のユースケースに対して、どうやって、仕事をしていくかということを、業務フローとしてまとめます。ユースケースに手順がある場合、ユースケース間の手順を業務フローにまとめることもあります。

　　このまとめかたですが、
　　　　国のＥＡの場合は、業務流れ図（WFA）にまとまります。
　　　　ＵＭＬの場合は、アクティビティ図にまとまります。
　　　　その他、ＢＰＥＬ、ＢＰＭＮなどにまとめることもあるかもしれません。

- - - -

（３）業務に使うデータをしらべまとめる

　上記の各業務では、データを取り扱うはずです。入力と出力データのほかに、作業用にデータを参照することもあるかもしれません。

　そして、データ間には、関係があり、構造があります。
　そこで、

　　　あ．プロセスの入出力データを確認する
　　　い．プロセスで入出力データのほかに、補助的に必要なデータも考える
　　　う．そのデータ間の関係やデータの構造を考える

　ということをします。

　この表現として、
　　　　国のＥＡの場合は、ＥＲ図または概念クラス図にまとまります。
　　　　ＵＭＬの場合は、クラス図にまとめざるをえません。

- - - -

（４）その他、今回の開発に必要な要件を挙げる

　上記までのもの、つまり業務とデータを機能要件といいます。
　それに対して、ユーザーインターフェースはどうのこうのとか、レスポンスは３秒以内といった、業務とデータではなく、使いやすさや信頼性にかかわる要件というのがあります。

　これを、非機能要件といいます。

　そして、これを挙げていきます。

- - - -

（５）上記の内容を、要求仕様書としてまとめます。

- - - -

　ちなみに・・

　プロセスとデータの関係をしらべて確認する方法として、国の場合、ＤＦＤを作成すれば気づきます。
　なので、ＤＦＤも作成します。

　ＵＭＬの場合、後述するＩＣＯＮＩＸを採用すれば、データとプロセスに矛盾があれば、破綻するので気づきます（後じゃ、だめジャン　＾＾；）。

　ただし、この段階では、あくまでも概念的、ざっくりとしたものです。

　結局、
　　機能要件として
　　　　何をしたいか(ユースケース）がまとまり、
　　　　　その業務フロー概要と、
　　　　　概念データモデルができます。

　　また、非機能要件がまとまります。

- - -

　この部分の標準として、

　　　国の場合にはもちろん、ＥＡがありますが
　　　世界的には、ＩＥＥＥ　８３０−　1998があります。

　　　富士通の場合、前回のダウンロードできる資料の「ＳＡ」のところをみてください。
　　　　　やまのように、ドキュメント書かないといけませんねえ（＾＾；）

　　　また、ここの部分は、各社の要求仕様書をまとめた？標準的なもの
　　　というか、ノウハウ集があります。

　　　　　機能要件に関しては
　　　　　　　発注者ビューガイドライン
　　　　　　　　　 http://sec.ipa.go.jp/reports/20080710.html

　　　　　非機能要件に関しては、チェックリストとして
　　　　　　　非機能要求グレード
　　　　　　　　　http://sec.ipa.go.jp/reports/20100416.html

　　　があります。また、ＪＵＡＳでは、両方のガイドラインをセットとして売ってます。

　　　　　要求仕様定義ガイドライン＆非機能要求仕様定義ガイドライン
　　　　　 http://www.juas.or.jp/product/detail/product.asp?id=445006

ながい、ながすぎます。ここで、切らせてください。
お昼食べるので

Ｐ．Ｓ・・・銀行行かなきゃ（＾＾；）