開発ドキュメント編 -
第３１章 システム保守ドキュメント
３１．１ 基本計画書
説明
一般的に、システム開発における企画書・計画書は、開発に入る以前に戦略的・政治的な側面から既に決定がなされているだろう。
Dropでは、このようにして作成された計画書をベースとしながら、要求仕様を具体化していく過程で発生する期間調整や戦略変更を行うフェーズとして問題領域分析フェーズを位置付けている。従って、基本計画書は、問題領域分析フェーズによって、より具体的で信頼の置ける計画書となる。
対象フェーズ
対象ワークショップ
記載項目
システム概要
開発するシステムの概要を述べる。システムがいくつかのアプリケーションに分けられる場合は、システム全体の概要とアプリケーション毎の概要を述べる。
システム概要図
開発するシステムがどのようなハード構成、ソフト構成を前提とするものであるか、Dropシステム構造モデルを参考に概要図を記述する。
システムの目的
開発するシステムが必要とされる背景。システムとして果たすべき目的を記述する。
開発のシナリオ
開発が長期になる場合など、どのような計画で開発を進めていくかといった企業戦略的なシナリオが記述される。この段階で、開発計画の中で予定されるプロダクトに対して、開発コード名（またはプロジェクト名）を付与するとよい。
主要機能一覧
システムを構成する代表的な機能とその概要の一覧
ハードウェア資源
予定される利用環境と開発環境のハードウェア資源
ソフトウェア資源
予定されるソフトウェアコンポーネント
開発コスト
予想される開発工数と設備費用
開発スケジュール
「開発のシナリオ」に沿った、長期・短期のスケジュールを記述する。
教育スケジュール
新たな開発環境やソフトウェアに慣れさせるために、開発者の教育スケジュールを計画する。
チェックリスト
- 開発期間が長期（たとえば１年以上）の場合、長期・短期両方のスケジュール計画がなされているか。
長期のみしか計画されていない場合、「第１０章開発サイクルの基本形」の大規模システム型（アプリケーション積み上げ反復戦略）を検討せよ。 - 開発スケジュールの信頼度を要求計画ワークショップで合意し、変更時の対策を示しているか。
どの程度信頼のおける計画であるかを、ユーザや上級管理職を含めて要求計画ワークショップで意識を統一しておく必要がある。最新技術を駆使するような開発では、はっきりとした計画が立てられないこともあるからである。このような場合、計画変更の際、どのようにワークショップを通じて対処すべきかについて事前打ち合わせを行う。
３１．２ 要求仕様書
説明
開発依頼側の要求を調査し、システムに要求される事項を記述する。
要求を文書化することで、開発依頼者の要求を明確に残す役割がある。要求仕様書は、最終的に依頼者の合意を得る必要がある。
対象フェーズ
対象ワークショップ
記載項目
システム概要
開発するシステムの概要を述べる。システムがいくつかのアプリケーションに分けられる場合は、システム全体の概要とアプリケーション毎の概要を述べる。
システム概要図
開発するシステムがどのようなハード構成、ソフト構成を前提とするものであるか、Dropシステム構造モデルを参考に概要図を記述する。
要求条件
以下のようなシステムに対する要求条件を記述する。
| 機能 | システムの機能の一覧とその概要解説 |
| 性能 | 処理の性能や動作の性能を要求条件として入れる必要がある場合 |
| 信頼性 | 保証すべきデータやセキュリテイに関する記述 |
| ユーザインターフェース | 特殊なマウス操作やキーボード操作が必要とされる場合 |
| 構造 | ソフトウェアアーキテクチャ構造に対して要求する場合 |
| 期間 | 要求条件に対する期間 |
拡張要求
システム基本計画書において次期開発として計画されているシステムに対する要求があれば記述する。
要求モデル
システムの提供する機能の重要部分をシネマスコープモデルのシナリオを使って解説したドキュメント。
DROによって作成されたいくつかのモデル図と以下の添付ドキュメント。
- オブジェクトレイアウトカード
- インタフェースカード
- ストラクチャカード
チェックリスト
- 要求に矛盾はないか。
- 現在のソフトウェア技術水準を大幅に越えた実現性のない要求はないか。
技術的問題が存在する場合は、技術検証のためのプロトタイプ開発や、代替案などを早急に検討しなければならない。 - 要求は本質的なものか、何をしなければならないかが明確に記述されているか
ユーザが求める要求の本質は何か？または必要とされるべきシステム要求は何か？に着目した記述がなされているか。 - 今期開発要求と次期開発要求が明確にされているか、また、それがシステム基本計画書と矛盾していないか。
要求仕様書には、将来的な要求も含まれるかもしれない。この場合、将来的な要求と、開発スケジュールに準拠した範囲での要求を区別すること。要求仕様とは、開発スケジュールに準拠した範囲での要求のことであり、それ以外は「拡張要求」に記録しておくようにしなければならない。
３１．３ 開発基盤検討書
説明
実装基盤ワークショップにおいて調査・プロトタイプ開発などに基づいて決定された、ハード、ソフトの基盤コンポーネントについて記述する。
対象フェーズ
対象ワークショップ
記載項目
システム基盤要求条件
システムの基盤となるハードウェアやソフトウェアの選択について、選択の必要性はどのような要求から来るものなのかを箇条書きしたもの。たとえば、「下記のプラットフォームに対応する」「ORBは言語非依存が望まれる」「現在使用しているデータベースを利用できなければならない」などを書いたもの。
システムの動作環境
- 動作ハードウェア
- 動作OS
- GUI
使用する開発環境と開発ツール
開発に既に使用することが決まっている下記のものについて記述する。
- 開発言語：(例) JDK1.2
- 開発支援ツール：開発に必要となるCASEツール、ビジュアル開発環境、デバッグツール、ドキュメントツールなどを列挙する。
- コンポーネント製品・フレームワーク製品：使用が予定される市販のコンポーネント製品やフレームワークを記述する。
- データベース製品：RDBMSなどデータベース製品の使用が既に予定されていればここに記述する。
- ネットワーク製品：ORBなどネットワーク製品が既に予定されていればここに記述する。
チェックリスト
- 決定項目に対して事前調査もしくは予備知識を十分に持っているか。
この調査を行う能力に欠ける場合は、その分野のエキスパートに聞くなどして、実現可能性（工数、期間も含め）について充分に確証を得なければならない。 - 早期決定を行うためのキーエキスパートを実装基盤ワークショップに参加させたか。
実装基盤ワークショップは、勉強会ではない。早期にシステムの実装基盤を決定するためにキーとなるエキスパートを探し、決定を委ねる機構である。 - 決定した項目に対して、実装可能な技術者は存在するか。
新しい技術などを基盤とする場合は、この点が重要である。もし、この点で十分でなければ、開発スケジュールの変更に柔軟でなければならない。（つまり研究的な要素を含む開発とする）、または、調査・研究期間を別のスケジュールとするのが得策である。
３１．４ システム開発環境標準
説明
システム開発の中で統一すべき開発ルールを記述する。これは、ODGの作成するパッケージ開発環境標準に準拠する形で作成される。
対象フェーズ
対象ワークショップ
記載項目
コーディングルール
ADGのコーデイングルールは、基本的にODGのパッケージコーディングルールに準拠する。しかし、やむを得ず異なるルールを定義しなければならない時や、追加すべきルールについては、ここに記述する。
ファイル名付与規約
システム開発におけるソースファイルや何らかの資源ファイルについて管理しやすい名前になるよう。ここにファイル名付与規約を記述する。
システムリソース管理方法
個々のアプリケーションをシステムとして統合化する際の手順や、ファイルデイレクトリ構成、バックアップ方式、バージョン管理方式などについて記述する。
コンパイルリンクオプション規約
システムとして統合した後のデバッグ時リリース時のコンパイルリンクオプションをのようにすべきか統一的な定義を記述する。ビジュアル開発ツールを使っている場合も、コンパイルリンクオプションを開発メンバが統一して利用できるようルール化しておく。
デバックツールの利用方式
選定したデバッグツールをどのように利用するかのガイドラインを記述する。
チェックリスト
- システムとして統合化した時の開発環境が明確に定義されたか。
これがなされない場合、ファイル名、クラス名、ライブラリ名などの名前の衝突、実行ファイル作成段階でのトラブルなど多くの問題が最終テストフェーズで発生する。
３１．５システムアーキテクチャ仕様書
説明
システムの基本構成を示す図や、システムを構成するアプリケーションの分類とアプリケーション間のコミュニケーション方法、共通データ管理などの方式を記述する。システムアーキテクチャ仕様書に記述される内容は、システムに共通的に決定すべき事項の全てである。ここで決定された方針や方式仕様は、フレームワーク化や再利用コンポーネント化の検討がなされる。
対象フェーズ
対象ワークショップ
記載項目
設計方針
システム開発におけるソフトウェアアーキテクチャに対する基本的な設計方針を記述する。
これは、開発基盤検討書により選択されたハードウェアやソフトウェアをベースとする、システム共通設計の中においてもっとも重要とされる設計方針を説明する。
システム構造図
設計方針の説明を補足としてシステムを構成するソフトウェアコンポーネントの構成図を書いたもの。
「第１９章 システム構造モデル」のシステム構造図を参考とする。
アプリケーション構成図
利用者から見た実行単位であるアプリケーションの一覧とそのイメージ図。なおイメージ図については特にDropで定めたものはないので自由に記述する。
方式仕様
下記それぞれの方式の決定を示す。
- ユーザインターフェース共通設計
統一的なユーザインタフェース提供のためのルールを記述。必要ならばRADツールを使ったプロトタイプ画面を印刷して利用する。 - データストア設計
要求モデルのDataManage部分に属するオブジェクトをデータストア方式（OODB、RDB、一般ファイル等）に適合させたアーキテクチャモデルとしてのクラス図とその説明文を示す。 - プロセス・スレッド設計
単一マシンにおけるオブジェクトの存在空間とその並行性を設計したものをシステム構造図により示し、必要ならば説明文を示す。 - ネットワーク設計
システムがネットワーク対応の場合について、ネットワーク対応ミドルウェア（またはフレームワーク）をベースとして設計されたものをシステムシステム構造図と説明文によって示す。 - 信頼性設計
システムの全体的なエラー処理レベルを統一化するための設計結果を説明文や簡単なイメージ図を使って示す。 - アプリケーション相互作用
アプリケーション間のデータ交換プロトコルや連動方式を設計したものをシステム構造図と解説文によって示す。
アーキテクチャモデル
システム共通設計により作成されたアーキテクチャモデルとしてのクラス図やコラボレーション図などとその説明文を示す。
クラス辞書
もし、データベースにおけるスキーマ構造が複雑になると判断した場合、クラス図だけではデータ構造を理解できにくいことがある。そのような場合は、データベース設計の延長上でクラス辞書を記述する。
- 属性名 :属性の名前(プログラムで使用する名前)
- 説明 :属性の説明
- データ型 :プログラムで使用されるデータ型
- データサイズ :固定長配列の場合にはそのサイズ
- キー種別 :インスタンスタンスをユニークに示すキーとなる属性
- 有効値 :データの取り得る有効な値の範囲がある場合、範囲の記述
- DB関連 :RDBを使用する場合、関連するカラム名の記述
- 画面関連 :画面と直接的な関連がある属性について、画面番号の明示
チェックリスト
- 記述された基本方針や設計方式は、開発期間や開発コストを考慮したものであるか。期間やコストを考えないものは絵に描いた餅である。
３１．６ システム機能仕様書
説明
システムを構成するアプリケーション全体の機能を解説する。
画面／帳票レイアウトと操作イメージは、画面作成プロトタイピングに優れたビジュアルツールで作成し、その印刷イメージを使用する。
対象フェーズ
対象ワークショップ
記載項目
概説
システムの機能の使われ方や、代表的な機能について説明する。
機能一覧
システムの機能一覧と機能の説明。 システムがアプリケーションで構成されているなら、アプリケーション別に機能を説明する。
できるだけイメージ図などを使って解説するとよい。
責任範囲
システムがアプリケーションで構成されているならば、また、アプリケーションが他のアプリケーションと連携動作するのなら、双方のアプリケーションで行うべき責任についてここで取り上げる。たとえば、「生成アプリケーションに引き渡すファイル名の拡張子およびデータヘッダ日付のチェックは編集アプリケーションで行うこと」などを記述する。
画面レイアウト
システムで使用する画面アウトと操作イメージ（アプリケーション別に階層化する）。
帳票レイアウト
システムで使用する出力帳票のレイアウト（アプリケーション別に階層化する）。
チェックリスト
- 画面／帳票レイアウトの変更可能期間および変更に対するコストについて、利用者（または開発依頼者）と話し合いがなされているか。
プロトタイプを使って画面／帳票レイアウトを作成すると、利用者はいつでも変更・追加できるものと勘違いしやすいものである。どの次期に仕様を凍結するのかを明確に定め、その後の変更は、スケジュールに影響を及ぼすことを理解してもらわなければならない。
３１．７ アプリケーション設計書
説明
アプリケーション設計書は、システム機能仕様に書かれているアプリケーション機能を実現するためのアプリケーションレイアに位置づけられるクラスの内部構造を示す設計書である。
対象フェーズ
対象ワークショップ
記載項目
アプリケーション構造の解説
アプリケーションの機能の実装する面で重要となる以下のような設計内容を記載する。
- アプリケーション固有（システムで共通化していない）に使用されるファイルのフォーマット
- アプリケーション固有に使用されるソフトウェアコンポーネントの使用方法と、実際に使用するための呼び出し手順などで特記すべきこと
静的モデル図
ODGから提供される再利用コンポーネントをベースとするアプリケーションレベルのクラス図
動的モデル図
アプリケーションに適したモデルを使ってオブジェクトの動的側面をモデル化する。
クラスライブラリ利用方式
ODGの提供するコンポーネントの利用方式についてサンプルプログラムを交えながら説明する。
クラス一覧
アプリケーションクラスの一覧
- クラス名
- クラスの主とする役割・機能
- 主要なメソッド名、パラメータ、戻り値
チェックリスト
- クラスを実装することが可能なレベルまで記述されているか。
- サンプルプログラムによる説明がなされているか。
３１．８ テスト項目票
説明
テストを効率的に実施し、開発するシステムや再利用コンポーネントの品質を保つためのテスト項目を記述する。
テスト項目表は、テスト・評価フェーズに先立ち設計フェーズにおいて作成される。
対象フェーズ
アプリケーション設計・実装フェーズ、コンポーネント設計・実装フェーズ
対象ワークショップ
システム共通ワークショップ、再利用コンポーネントワークショップ
記載項目
作成日
作成者
テストレベル
パツケージレベル、コンポーネントレベル、システムレベル、アプリケーションレベルの何れかを選択。
テスト種別
要求、連動、操作、障害、資源、品質、機能、フィールドなどレベルに応じたテスト名を選択。
詳しくは、「コンポーネントテスト・評価フェーズ」、「アプリケーションテスト・評価フェーズ」を参照のこと。
テスト名
テストのタイトルを記入
繰り返し項目
以下を繰り返し記入する。
- テスト項目．．テストの概要
- テスト日．．．テストを行った日付
- 結果 ．．．テストの結果
- 問題点．．．テストの結果発生した問題
３１．９ バグシート
説明
バグシートは、開発システムに何らかのトラブルが発生した段階から作成され、その原因が判明し、解決した後、新たなバージョンとしてソフトウェアがリリースされるまでの記録を保持するものである。
対象フェーズ
システムテスト・評価フェーズ、パッケージテスト・評価フェーズ
対象ワークショップ
システム共通ワークショップ、再利用コンポーネントワークショップ
記載項目
発行番号
開発システム名
問題発生日
問題の発生頻度
発行者（氏名、会社名、連絡先）
問題内容
解決希望日
回答者（氏名、会社名、連絡先）
回答日
問題原因
解決予定日
原因となったクラス名
解決状況
１．解決済み ２．解析中 ３．その他
解決方法
解決後ソース修正日
バグ対応ソースのバージョン
修正担当者
原因分析情報
以下の項目より選択する。（複数選択可）
- Ａ．分析フェーズ
- 仕様の理解不足
- 仕様の不明確
- 仕様の誤り
- Ｂ．設計・実装フェーズ
- クラス設計検討不足
- コンポーネント使い方誤り（クラス名［ ］）
- （変数または資源）の初期化忘れ
- （変数または資源）の後始末忘れ
- 標準関数（クラス）の使い方誤り
- エラーチェック忘れ
- ロジックの誤り
- 言語の理解不足
- Ｃ．導入
- 動作環境の設定誤り
- 動作環境の仕様上の誤り
