構造化手法によるソフト開発プロセス　その１

概要手順

1. 要求分析
2. 設計
3. 最終コーディングとデバッグ
4. 検査

大まかな手順は上記のようになります。基本はウォーターフォールスタイルになります。

世間で誤解されているような、あともどり無しのウォーターフォールではなく提唱者とされている W. W. ロイスの提唱しているあともどりもあるプロセスが良いと思います。その方が現代的エンジニアリングにもかなっている考え方です。

各フェーズをさまざまなレベルで並列（コンカレント）に実施して、結果をすばやく小刻みにフィードバックしてプロセス全体を修正しながらすすめて、最終成果物を得るまでのリードタイムを短縮することを目指す方が現実的でしょう。

並列しすぎると、これもまたコストがかさむので、その辺りの匙加減はプロジェクトマネージャやプロセスデザイナーの腕の見せ所です。

要求分析の成果物

構造化手法の場合の要求分析の成果物として、最低限のものは、

• 要求 DFD（データ・フロー・ダイアグラム）
• 要求 DD（データ・ディクショナリー）
• ミニ仕様書

といったところがデマルコの言うところのものでしょう。

この中でミニ仕様書（ミニスペック）は、決定木や決定表、構造化言語など、あまり厳密に決まっていません。個人的には、今なら VDM などの仕様記述言語などが好い気がします。事前・事後・不変条件さえ記述されていれば、表記手段が何であっても大して困らないと思います。

ここで手順的なことを書き出すと、つい実現方法へ思考が行ってしまって、要求分析初期の段階では余計なお世話的状態のアウトプットになってしまいがちですから、あまり処理の流れはこだわらない方が良いでしょう。ただ、ワークフローなどが要求として問題になるなら、その範囲でなんらかの記述は必要にはなります。

設計の成果物

設計とは「どう作るか」を決めるプロセスですから、ここでの成果物は「それを見れば作れるもの」でなければいけません。

構造化手法的には

• 設計 DFD（最終成果物というよりは中間成果物）
• 設計 DD
• モジュール構造図
• モジュールのミニ仕様
• モジュール間の制御フロー

実際のところ、大掛かりなソフトウェアの場合はこれでは全然足りないでしょうけれど、最低限上記のものが必要です。

現実には、例えばデータベースを使うならそのためのデータやテーブルの定義仕様が必要でしょうし、制御系のプログラムの場合はタイミングチャートの様なものも必要になるでしょう。それこそ「それらを見れば作れる」ものが揃っていないといけません。逆に言えば「それが無いと作れないもの」は、ここで準備されるわけです。

最終的な設計 DD は、設計 DFD に従ったものより、モジュール構造図上のデータ形式が全て記述されているものになります。その上で DFD のコンテキストダイアグラム上のデータフロー上のデータも完全に表記され、矛盾がない状態になっていなければなりません。

そうなっていれば、要求仕様とも矛盾がなく、相当したものになっているはずです。

ここでのモジュールミニ仕様は、事前・事後・不変条件が明確でないと困るでしょう。実用性などの見地からアルゴリズムなどの指定が必要な場合は、なんらかの手段でそれを提示します。

フローチャートでも良いですし、構造化言語でもかまいませんし、VDM などの仕様記述言語でも良いでしょう。場合によっては、ターゲットプログラミング言語での記述でも構わないでしょう。この場合、試作コードは流用可能かもしれません。

試作コードをこの目的で流用する場合、可読性、理解容易性が低く書かれたコードだと、むしろ効率が低下して、コストがかさむことがあるので、この場合は整理して書き直した方が良いです。また、あくまでもアルゴリズムなどを提示する目的のコードであり、製品レベルで必要なエラー処理などが欠けていることを明確にして、そのまま流用されないように注意しておくこもと必要です。

モジュール間の制御フローは、フローチャートでもなんでも構わないでしょう。ここも、VDM など仕様記述言語が利用可能です。

最終コーディングとデバッグの成果物

言うまでも無く

• ちゃんと動く実行コード
• ソースコード
• ビルド指示（メイクファイルやプロジェクトファイルなど）

となります。

ソースコードを設計の最終成果物と考えるなら、設計の方にこれをおいても構わないでしょう。いずれにせよ、最終成果物としては「ちゃんと動く実行コード（ソフトウェア）は必須です。

検査の成果物

• 要求仕様に合致したものであることが検証確認されたちゃんと動く実行コード
• 検査報告書

まあ、ここは構造化云々は関係ないところではあります。