D)詳細設計 成果物作成要領

Home » エンタープライズアプリケーション開発 » D)詳細設計 成果物作成要領

詳細設計工程の成果物作成要領を記す。

この工程では基本設計で作成した設計内容に対して物理的な情報を確定していく。
ただし、全ての作業を基本設計の後に後回しにしてまとめて実施するというわけではなく、基本設計の際に物理的に不可能なことや致命的な制約がないか合わせて確認することは重要である。
(作業工程の概念は論理的な作業順序なので、物理的な実現性の確認が十分に取れていない設計事項に関しては、基本設計と合わせて実施する必要がある。)

ここでは、プログラムのアルゴリズムや内部的な処理の詳細な動作(IF文とCASE文のどちらを使うか等)について文書化することを詳細設計の作業としていない。
プログラムと内容がほぼ重複した詳細な設計内容を文書化することは、開発の費用対効果とシステムリリース後のメンテナンス性を考えると、作業量の多さゆえに現実的ではない可能性が高いからである。

 

# 成果物名 作成要領 サンプル
1  共通詳細設計

・画面アーキテクチャ・共通設計
 ・動作環境
  (基本設計のページに物理的な確認点も記載しているのでそちらを参照)

 ・画面の分類/デザイン/レイアウト
  画面分類毎に画面の物理名称やデザインのルールが統一できて
  いるか、各画面の設計後に確認する。

 ・画面の遷移の実装方法
  画面遷移時に利用する処理を決定する。(Class/Method名等)

 ・表示・入力規則
  ・表示規則(日付・時間等)を物理的に指定する。(→DATE型等に指定)

 ・エラー処理
  ・エラー処理の物理的な共通処理を決定する。(Class/Method等)

  
 ・チェック機能
  ・クライアントまたはサーバ上のチェック機能の共通処理
   を決定する。
(Class/Method等)

   <チェック機能の対象例>
     ・データ形式チェック
     ・値の範囲チェック
     ・データ間の関連チェック
     ・参照チェック(外部参照データが存在するか等)
     
 ・利用者・権限の設計
  ・権限定義の物理的な実装方法
   ・登録/更新で使用する物理的な処理を決定する。(Class/Method名等)
   ・データ(テーブル/テーブル項目等)の物理名称も決定する。

・帳票アーキテクチャ・共通設計

 ・帳票出力方式
  ・帳票出力の実装方法を決定する。(Class/Method名等)
   (基本設計のページに媒体/出力装置/出力先に関する物理的な
   確認点も
記載しているのでそちらも参照)
  
 ・帳票の分類/デザイン/表示項目
  帳票分類毎に帳票の物理名称やデザインのルールが統一できてい
  るか、
各帳票の設計後に確認する。
  
 ・帳票の再作成(再印刷)
  帳票再作成に関する処理を決定する。(Class/Method名等)
  <対象の処理>
   ・業務上の再作成
   ・プリンタエラー
   ・スプールエラー
  
 ・利用者・権限の設計
  (画面と同様)

・I/Fアーキテクチャ・共通設計
 ・実装方法(バッチ/オンラインバッチ処理等のClass/Method名等)を決定する。
 ・インタフェースに関する物理名称のルールが統一できているか、
  各インタフェースの設計後に確認する。

・バッチ・ロジックアーキテクチャ・共通設計
 ・通常処理とエラー処理に関する物理的な実装方法(Class/Method等)
  を決定する。
 ・バッチ処理の物理名称が統一できているか、各バッチ処理の設計後に
  確認する。

 -
2  開発ガイドの作成

・詳細設計ガイドライン
 ・設計書とプログラムの自動生成
  ・設計書からプログラムを自動生成
   基本設計書と詳細設計書を活用して、プログラムを自動生成する
   方法を採用する場合、
その自動生成の手順を具体的に固める。
   また、実際に自動生成するためのツールを作成する。

  ・プログラムから設計書を自動生成
   設計書よりも先にプログラムを作成し、詳細設計書作成の工数を
   削減することを
意図した設計方法。
   例えば、データの物理設計に関して、基本設計書とSQL(DDL)を
   元にして
情報を自動生成する等がこのケースに該当する。
   これらの作業に関する手順書とツールを作成する。   
   開発言語にJavaを使用する場合は、Javadocの扱いをどうするか
   決定する。
   (後述の実装機能一覧の代替物とする等)

  
  ・フレームワーク利用ガイド(フレームワーク設計書)
   構築するシステムがフレームワークを利用している場合、
   フレームワークの
各部品の利用方法を記載する。

 

・環境構築手順
 下記の各環境を開発者の開発環境・テスト環境に構築するための手順を
 記載する。

  ・コーディング/コンパイル環境構築手順
  ・開発/テストサーバの環境構築手順
  ・開発/テスト環境へのアクセス手順(ログイン方法/ディレクトリ構成等)
  ・構成管理ツールを利用したソースコード/設定ファイル/
   ドキュメント管理手順

・コーディングガイドライン
 ・コーディング実施方法の説明
  ・コーディング/コンパイル/デバッグ手順
  ・構成管理ツールからのチェックアウト/チェックイン方法
   
・単体テストガイドライン
 ・単体テスト環境構築手順
 ・単体テストツールの利用方法(実行/結果確認手順)
 ・単体テストの結果のとりまとめ方法
 
・コーディング規約
 ・命名規約を定義する。
  <命名規約の対象例>
  ・名前空間
  ・クラス・メソッド・変数(以下に具体例を記す)
   ・クラス名は役割がわかる名前にする
   ・クラス名はPascal形式で記述する(例:ProductName)
   ・メソッド名は目的がわかる名前にする
   ・メソッド名はCamel形式で記述する(例:productName)
   ・変数名には意味のある名前を付ける
   ・変数名はCamel形式で記述する。
  ・定数
  ・関数  

 ・コーディングスタイルを定義する
  <コーディングスタイルの例>
  ・インデント
   半角スペース4文字分のタブを利用する。
  ・カッコと改行
   カッコの前後の半角スペースの有無やカッコの後の改行の有無
  ・引数
   引数が複数ある場合の記載方法を決める。
    (例:半角スペースとカンマで区切る)
  ・1行の長さは100文字までにする(読みやすさを考慮する)
  ・ローカル変数とグローバル使い分け方法を決める
   (例:ローカル変数の使いまわし禁止)
  ・名前には英単語を使用する

  ・コメントは英語で記載する

- 
3 アプリケーション基盤設定  ・アプリケーション基盤設定
 ここでは、フレームワーク、ミドルウェア(DB除く)の設定を定義する。
WEBアプリケーション基盤構成例          (上表でいえば、Apache,Spring,独自フレームワーク)
 ・WEBサーバー
  <Apacheの設定例>
  ・Webサーバホスト名
  ・ポート番号
  ・エラードキュメント(Status-Code毎のエラーページURL設定)
    401 Unauthorized ユーザー認証失敗
    403 Forbidden アクセス拒否
    404 Not Found リソース(ファイル)が存在しない
    500 Internal Server Error サーバがリクエストを実行できない
    501 Not Implemented リクエストを処理できる機能がサーバにない 
  ・ドキュメントルート(Index.htmlの保存ディレクトリ)
 
 ・アプリケーションサーバー
  <Springの設定例>
  ・DI設定(Bean定義)
   Beanの生成パターン(Singleton/prototype等)
  ・DB接続(datasource)設定
  
  <独自フレームワークの設定例>
  ・WebSocket接続タイムアウト設定
   (チャット機能等の双方向機能における接続時間)

- 
4  データベース設計
(物理・索引)

・データベース物理設計
 データベースの物理名称やパフォーマンスを考慮したマシンリソースの
 割り当て等を行う。

  ・データベース/テーブル/カラムの物理名称設定
   (アプリ個別で使用するテーブル/カラムの物理設計は
アプリ実装設計
    として実施するが作業内容は同じ)

  ・データベースファイル設定
   ・表領域/ログファイルへのディスク割り当て
   ・ソフトウェアRAID(ミラーリングorストライピイグ)の設定
  ・DBプログラムへのメモリ割り当て
  ・AP-DB間のコネクションプール設定(プール最大数)
  ・文字コードの設定

・索引設計
  検索のパフォーマンスを向上させる目的でデータベースに
  インデックスを設定する。

  テーブルに多くのカラムが含まれていたり大量のデータが格納されて
  いる場合、
データ検索に多大な時間がかかることがある。
  索引設計は、このような場合に適切なカラムにインデックスを作成
  しておくことで
検索を高速化することを意図している。
  一方で、データ追加時の処理が重くなるというデメリットもあるので、
  必ずしも
全てのテーブルに設定する必要はない。 
  <インデックスによる検索の高速化が見込めるケースの特徴(例)>
   ・テーブル内のデータ量が多く、少量のレコードを検索されることが多い
   ・列の値(コード値)の種類が多い
   ・NULL値が多い(インデックスはNull値を検索対象に含めないため)

- 
5  ネットワーク環境設計

ネットワーク環境設計に関する主な作業を記す。
・ネットワーク通信速度の確保
 アプリケーションの利用で想定している通信速度を確保するために、
 ネットワーク帯域幅(回線能力)とネットワーク構成(負荷分散装置等)を
 設計する。

・ネットワークセグメントの設計
 ・開発/テスト環境と本番環境のネットワークセグメントを分離する。
 (データ漏洩・改ざんに関するリスクへの対応)
 ・各環境間で通信できるネットワークポートを設定する。

・各サーバーへのIPアドレス割り当て
 仮想化マシンにIPアドレスを割り当てる場合は、仮想マシンと
 物理マシン間で
通信する仮想ネットワークの設定も必要。

– 
6 ハードウェア・ミドルウェア
環境設定

ハードウェア環境設定
 <主な設定例>
 ・BIOS設定
 ・ディスク割り当て

・ソフトウェア環境設定
 <主な設定例>
 ・OS
  ・管理ユーザー/パスワード設定
  ・ディスク/パーティション設定
  ・ネットワーク設定(IPアドレス、ドメイン、HOST名称)
  ・日時設定

 ・HA(High Availabilityクラスタリングソフト
  ・ハートビート通信(生死確認)設定
  ・フェールオーバー設定(生死監視対象の設定)

– 

7  システム運用設計

・システム監視定義
 下記の点についてサーバ毎に物理的な監視設定項目/方法を定義する

  ・死活監視  :Ping疎通/プロセス生存/エージェント通信/SQL疎通/
            HTTP疎通

  ・エラー監視 :ログ確認(syslog、アプリ等)/SNMP Trap通知/
            イベント通知

  ・リソース監視: モニタ機能/ログ出力・収集/イベント通知/
            ツール・コマンド実行

  ・性能監視  : ログ確認(処理時間、開始終了時間)
  ・実行監視  : 実行ツール通知/ログ確認

・ジョブフロー定義
 ジョブ一覧、ジョブフローに物理情報(ジョブネットID/ジョブID)を追記する。

・バックアップ/リカバリ定義
 バックアップ/リカバリに関して使用する機能の物理情報を
定義する。
  <定義の例>
   ・バックアップ処理のコマンドと引数の定義
   ・リストア処理のコマンドと引数の定義 
   ・バックアップファイルの保存ディレクトリの定義
 
・システム運用手順書の作成
 システム運用に関する手順書を作成(物理情報の追記)する。
 ・システム監視手順
 ・バックアップ/リストア手順
 ・障害調査/復旧手順(サーバプロセスの再起動等)
 ・定期保守手順
  ・計画停止
  ・ユーザメンテナンス
  ・パッチ適用/活性保守

– 
8 アプリケーション実装設計

この工程では、基本設計工程で作成した論理設計に物理情報を付加する。
 ・実装機能一覧

  実装する機能を一覧化する。
   例:Java Class/Methodの一覧(Javadocで代替する)
  
 ・アクション/イベント一覧
  画面設計で作成したアクション一覧の業務アクション名に物理名称
  を追記する。
(右記の画面設計内にサンプルあり)
  
 ・ロジック設計(物理)

  ・各ロジックが使用するClassやMethodを決定し、物理名称を
   定義する。
  ・ロジックのInput/Outputデータの物理名称を定義する。
   この設計は、I/F設計や、データ設計と合わせて実施する。

 ・画面設計(物理)

  画面を構成するコンポーネント(ラベル、テキストフィールド、ボタン等)
  の物理名称を定義する。

 ・帳票設計(物理)
  帳票の表示項目の物理名称を定義する。

 ・インタフェース設計(物理)
  インタフェース項目の物理名称を定義する。  

 ・ジョブ設計(物理)
  ジョブ内の処理の物理名称(ClassやMethod)を決定する。
  
 ・データ設計(物理)
  テーブル/カラムの物理名称を定義する。

画面設計画面設計

 

Excel帳票設計

Excelインタフェース
設計

Excelジョブ設計

Excelデータ設計

9 単体テスト計画

全体テスト計画を踏まえて、テストスコープと検証方法を具体化する。
単体テストは原則的にプログラマー自身がコーディングの延長戦上でテストを実施する

・単体テストの考え方を整理する
 ・ホワイトボックステスト
  ホワイトボックステストでは、プログラムの制御構造に合わせて、
  単体テストにおけるテストカバレッジ(網羅率)を設定する。
  テスト期間とコストを考慮してどのレベルまで網羅するかを決定する。 
  ホワイトボックステストの検証観点は、プログラムの処理経路を
  網羅的に実行して、
正しく動作するか否かである。
  主要なホワイトボックステストの手法である制御パステストでは、
  網羅性の考え方を下記のように整理している。
 
  <制御パステストにおけるテストカバレッジ>

   ・C0網羅(命令網羅)
    処理経路を構成するすべての命令を最低1回実行する
   ・C1網羅(分岐網羅)
    すべての条件分岐の真と偽の両方を最低1回テストする
   ・C2網羅(条件網羅)
    条件分岐の真と偽のすべての組み合わせをテストする
  
 ・ブラックボックステスト 
  ・同値分割
   テストの入力値を有効値の集合と無効値の集合に分けて、
   それぞれの集合から代表値を選んでテストする

  ・境界値分析
   有効値と無効値の境界値とその前後の値を選んでテストする
  
 ・その他のテスト
  ・プログラムの実行確認
   (本当にプログラムが実行されたか否かの確認)

  ・メモリー領域の確保・開放の確認(メモリーリーク防止)
  ・プログラム単体のパフォーマンス検証(多重ループ処理の有無)

 ・テスト自動化の検討
  ユニットテスト・フレームワーク(xUnit系ツール等)やカスタムツールの
  導入を検討する。
どのテストが自動化に適しているか、費用対効果を
  検証する。
(一般的にテストの自動化率は2-3割)

・開始終了基準
 <開始基準>

   ・実装作業の完了状況:タスクの完了状況、クリティカルな残課題の有無
   ・テスト設計状況 :テスト項目件数、密度の分析
   ・テスト準備状況 :環境、データの準備状況
  <終了基準>
   ・テスト実施状況 :テストケース消化率
   ・不具合発生状況 :発生(摘出件数、テスト項目数比)分析
   ・不具合修正状況 :積み残しバグの取り扱い
                (バグの影響度定義と判断基準)

   ・不具合分析、収束状況 :発生傾向分析、収束状況、残課題の
                    対応方針等の
確認

テスト検証観点テスト検証範囲と確認観点 
(再掲)
 

 

 

 

 

  

 

10  結合テスト計画 全体テスト計画を踏まえて、テストスコープと検証方法、テスト期間中の
運営方法を具体化する。

 ・テストシナリオの設定
  どのようなテスト手順にすると確認したいテスト内容をカバーできるか
  を考えて、
テストシナリオを設定する。
  結合テストでは基本設計書に記載のあるシステムの機能全てが
  対象となる。

  
 ・検証観点の整理
  結合テストの検証観点概要は、下記の2点。どの観点のテストを
  実施するか整理する。

   ・システム内部で起こりうるの全ての動作を検証する。
   (観点の詳細は右記の「テスト検証範囲と確認観点」を参照)
   ・インタフェース(外部システムとの結合)の疎通レベルの確認を
    済ませる。

  
 ・テストケースの粒度の設定
  テストシナリオと検証観点を踏まえて、結合テストの1つのケースを
  どの粒度にするかを決定する
  <結合テストケースの粒度の例>
   ・画面機能
    ・画面からDBにデータが登録されるまでの1つのトランザクション
   ・バッチ処理
    データ取得→加工→データ保存の一連の処理の実行   
  
 ・テスト自動化範囲の整理
  テストを自動化する場合は、どのシナリオ/ケースを自動化対象と
  するかを整理する。

 ・テスト開始/終了基準
  テストの開始基準と終了基準を定める。
  <開始基準>
   ・前工程の完了状況:タスクの完了状況、クリティカルな残課題の有無
   ・テスト設計状況 :テスト項目件数、密度の分析
   ・テスト準備状況 :環境、データの準備状況
  <終了基準>
   ・テスト実施状況 :テストケース消化率
   ・不具合発生状況 :発生(摘出件数、テスト項目数比)分析
   ・不具合修正状況  :積み残しバグの取り扱い
                 (バグの影響度定義と判断基準)

   ・不具合分析、収束状況 :発生傾向分析、収束状況、
                    残課題の対応方針等の
確認
    
 ・テスト環境の情報の整理
  テスト環境に関する下記の情報を整理し、開発者に周知する。
  ・結合テストで使用するテスト環境(WEBサーバ、アプリケーションサーバ、
   DBサーバ、クライアント)

  ・各環境への接続情報(ユーザID、パスワード)
  ・構成管理ツールからの資源移行ルール
  
 ・テスト実施の体制の具体化
  役割分担と作業体制を明確にする。具体的に担当者を個人レベル
  まで割り当てる。

  ・テスト設計、開発(ケース設計/ツール設計/データ設計)
  ・準備(データ作成/環境構築)
  ・実行(ケース実行/検証、不具合対応/構成管理)
  ・管理(ケース/バグ/進捗状況)

 ・スケジュールの確定(WBSの作成)
  テストスケジュールを作成する。体制で定義した担当者に
  スケジュールを割り当てる。

  ・テストの実施期間を決めて、各シナリオの実施日程を決定する。
  ・環境利用スケジュールを明確にする。

 ・テスト管理
  テスト管理項目と運営方法を定義する。
  ・管理項目
   ・テスト進捗管理(ケース消化予定/実績)
   ・不具合管理(不具合の発生数/解決数)
   ・テスト品質管理(ケース密度、バグ密度)
   ・テスト結果報告
  ・テスト期間中のコミュニケーション
   ・進捗、不具合、テスト品質に関する状況確認方法
    (会議設定、報告テンプレートの用意)

11  総合テスト計画

全体テスト計画を踏まえて、テストスコープと検証方法、テスト期間中の運営方法を具体化する。
 ・総合テストの検証の観点
  総合テストではシステム外部を含めた業務全体での運用の妥当性を
  検証する。

  結合テストまではシステム内部の検証が主だったテスト範囲だったが、
  この工程では、
ユーザ業務の確認と、外部システムとの連携が
  検証ポイントになる。
外部システムに対しては、データ提供、
  シナリオ作成、環境利用時期の調整を
入念に実施する必要がある。
  この工程で、システム運用に関する手順の確認も実施する。

  
 ・テストケースの粒度の設定
  テストシナリオと検証観点を踏まえて、結合テストの1つのケースを
  どの粒度にするかを決定する
  <総合テストケースの粒度の例>
   ・要件定義時に作成した業務サイクル/業務シナリオ単位
   ・外部システムと連携する一連の処理
   ・システム障害検知から調査までの一連の作業

  
 --以下の計画項目は結合テストと同様--
 ・テスト自動化範囲の決定
  テストを自動化する場合は、どのシナリオ/ケースを自動化対象と
  するかを決定する。


 ・テスト開始/終了基準
  テストの開始基準と終了基準を定める。
  <開始基準>
   ・前工程の完了状況:タスクの完了状況、クリティカルな残課題の有無
   ・テスト設計状況 :テスト項目件数、密度の分析
   ・テスト準備状況 :環境、データの準備状況
  <終了基準>
   ・テスト実施状況 :テストケース消化率
   ・不具合発生状況 :発生(摘出件数、テスト項目数比)分析
   ・不具合修正状況  :積み残しバグの取り扱い
                 (バグの影響度定義と判断基準)
   ・不具合分析、収束状況 :発生傾向分析、収束状況、
                    残課題の対応方針等の確認
    

 ・テスト環境の情報の整理
  テスト環境に関する下記の情報を整理し、開発者に周知する。
  ・総合テストで使用するテスト環境
   (WEBサーバ、アプリケーションサーバ、DBサーバ、クライアント)

  ・各環境への接続情報(ユーザID、パスワード)
  ・構成管理ツールからの資源移行ルール
  
 ・テスト実施体制の具体化
  役割分担と作業体制を明確にする。具体的に担当者を個人レベル
  まで割り当てる。

  ・テスト設計、開発(ケース設計/ツール設計/データ設計)
  ・準備(データ作成/環境構築)
  ・実行(ケース実行/検証、不具合対応/構成管理)
  ・管理(ケース/バグ/進捗状況)

 ・スケジュールの確定(WBSの作成)
  テストスケジュールを作成する。体制で定義した担当者に
  スケジュールを割り当てる。

  ・テストの実施期間を決めて、各シナリオの実施日程を決定する。
  ・環境利用スケジュールを明確にする。

 ・テスト管理
  テスト管理項目と運営方法を定義する。
  ・管理項目
   ・テスト進捗管理(ケース消化予定/実績)
   ・不具合管理(不具合の発生数/解決数)
   ・テスト品質管理(ケース密度、バグ密度)
   ・テスト結果報告
  ・運営方法
   ・進捗、不具合、テスト品質に関する状況確認方法
    (会議設定、報告テンプレートの用意)

 12
 
 システムリリース設計・
 リリースリハーサル計画

 システムリリース関連の成果物として下記の4点を作成する。
 ・リリースタイムチャート 
 ・リリース手順書
 ・稼動確認手順書
 ・リリースリハーサル計画

・リリースタイムチャート
 リリースタイムチャートは、移行作業全体の進捗状況を把握するための資料。

 移行作業について、あるチェックポイントから次のチェックポイントまでの
 作業を1つの単位として定義する。

  例)チェックポイント①
     Aシステムのデータ移行完了 5月3日12時 
    チェックポイント②
     Aシステムの資源リリース完了 5月3日15時(切り戻し判断)
 リリース作業の流れだけでなく、切り戻し判断ポイント(時刻)と
 コンティンジェンシープラン発動時のタイムチャートも明記する。

・リリース手順書
 リリース手順書には下記の情報を記す。
 具体的な手順書のイメージは右記のサンプルファイルを参照。
 ・作業を実施する対象サーバ
 ・作業時に利用するシステムログインID
 ・作業内容の説明
 ・実行手順(実行コマンド)
 ・各手順の予想所要時間
 ・各手順を開始する予定時刻
 ・実際に手順が完了した実績時刻
 ・実行者
 ・確認者(レビュー者)
 ・確認結果(実行結果がOKか問題があったか)

 手順書は机上で作らずに、開発サーバに実際に資源を配置しながら実施
 するなど、具体的な手順を確認しながら作成することを推奨する。
 これは、机上で作成した手順は考慮漏れが多く、リハーサルを実施した際に
 ミスが多すぎてリハーサル(検証)の必要最低限の品質に至らないリスクが
 あるからである。
 
・稼働確認手順
 ・システムリリース後の初期稼働確認の手順書を作成する。
 ・IT担当者が確認できる項目(アプリケーションサーバのプロセス起動確認等)と、
  業務ユーザによる稼働確認の双方を洗い出す。

 ・稼働確認手順のフォーマットはリリース手順書と同等のものを利用する。

 ・リリースリハーサル
 リリースリハーサルの実施計画を作成する。
 ・関係者とリハーサルスケジュールを調整し、スケジュールを確定する。
  本番リリースを想定したリハーサルの実施日時を決定する。
  実施時間、実施者などの諸条件を本番同等にして実施するため
  関係者との調整が必要。
  <関係者の例>
   ・プロジェクトマネージャ
   ・アプリケーションリリース担当者
   ・システム基盤(DB、OS,HW・NW)担当者/運用担当者
   ・関連システム担当者
   ・業務ユーザ担当者

 ・体制を決定する
  本番リリースを想定してシステムリリース前後の体制を決定する。
  ・役割の確認
   ・リリース作業者(アプリ、基盤、運用それぞれの担当)
   ・リリース作業レビュー者
   ・リリース判定者(システム責任者、業務ユーザ責任者)
   ・リリース後のシステム初期稼働確認者(システム、業務)
   ・業務ユーザの初期稼働確認者

  ・緊急連絡方法
   ・電話、メール等による緊急時の連絡方法を決め、連絡先を
    取りまとめて関係者に周知する。
 

Excel リリース
手順書