C)基本設計 成果物作成要領

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

基本設計工程の成果物作成要領を記す。

成果物名  作成要領  サンプル
 1  アーキテクチャ/共通設計 ・画面アーキテクチャ・共通設計
 画面アーキテクチャ・共通設計は、画面に関する前提やルールを設定する
  作業。
設計者や画面毎のバラツキなく統一性を持たせることを目的とする。
 以下に、検討のポイントを挙げる。

 ・動作環境の設定
   画面が動く環境(ブラウザ等)を決定する。
   この環境がテストにおける動作検証環境になる。
   動作環境として設定していない環境での動作保証は
   しないことになるためユーザーと認識を合わせる必要がある。

   <環境を設定する際に気をつけるポイントの例>
    ・HTMLやCSS解釈の違いによるレイアウト変化
    ・Scriptsの動作の可否
    ・同じブラウザ、実行環境でのバージョンによる表現・仕様の違い
    ・OSに依存する機能の有無(Vesrionによって動作可否が異なる等)
    ・クライアント実行環境(製品、ランタイム)/バージョン
    ・解像度(古いPCでの利用がある場合に注意)
    ・色数(古いPCでの利用がある場合に注意)
    ・文字の大きさ(ブラウザ利用時の表示サイズ設定)
    ・ウィンドウ(表示領域)の大きさ(最大化した状態など)
    ・ネットワーク回線速度(サイズが大きい画像ファイルの扱い可否など)

 ・画面の分類
  システムで用意する画面を分類する。
  分類することで画面デザインや遷移を統一することにつながる。
  <画面の分類例>
   A). 参照画面
    ①. 一覧画面(検索→一覧)
     ある共通な条件に一致するデータを一覧表示する画面
    ②. 詳細画面
     1件のデータを表示する画面
   B). 登録(更新)画面
    ①. 一括(一覧)登録画面
      複数件を一括して登録・更新することを可能にする画面
    ②. 単(明細)登録画面
      1件の登録・更新を行う画面
   C). 共通画面
    業務の主対象ではないが補助的に使用する画面
    ①ログイン画面、エラー画面、ヘルプ画面
    ②検索入力画面(補助的な検索[郵便番号検索など])

 ・画面のレイアウト
  画面のレイアウトを定義する。
  画面分類(用途)にあわせてユーザビリティの高いパターンを設定する。
画面レイアウト例

 ・画面のデザイン
  統一性のある画面デザインにするために、
  色や文字フォント、文字配置などを定義する。
  ・レイアウトの検討対象(例)
   ヘッダー、フッター、メインなどの各領域のデザインを定義する。
   ・文字フォント:フォント種類、文字サイズ、色、スタイル
   ・背景    :色
   ・枠     :線の種類・太さ等の装飾
   ・文字配置 :上下(上揃え/中央揃え/下揃え)
              左右(左揃え/中央揃え/右揃え)
  ・画面部品のデザイン(例)
   画面上で使用する部品とそのデザインを定義する。
   各部品に対して色、フォント、文字配置、画像利用等を決定する。
   ・テキストボックス /テキストエリア / 日付入力テキストボックス
   ・ラジオボタン / チェックボックス / リストボックス / ドロップダウンリスト
   ・ボタン /アイコン 
   ・グリッド
   ・グラフ

   通常時以外のエラー時、非活性時など状況別のデザインも
       定義する。

 ・画面設計の規約
  画面やラベルの命名の仕方や、画面遷移(特に更新系)
  についての方針を決める。
  ユーザビリティに影響するので利用ユーザとの認識あわせが必要。
  ・命名規則 
   画面に表示される文言(画面タイトル、ラベル)のルールを設定する。
   (ルール論理名と物理名の双方を定義する)
   業務用語、社内の共通用語に合わせる。
   <命名例>
    ・一覧表示の画面
      『XX一覧』、『XXリスト』 ⇒ “XX一覧”に統一する
    ・コード設定の項目
      『○○コード』、『○○CD』 ⇒ “○○CD”に統一する
    
  ・更新系画面の遷移方針
   データ更新を行う画面のアクションについて、
   更新実行時のユーザ確認方法(更新確認画面の有無)を検討する。
   更新のパターンが異なるとユーザの利用時や保守開発において
   混乱を招くため、画面遷移を統一する。
  
 <更新系画面の遷移パターン例>
    A)入力画面→確認画面→完了画面 のパターン
      更新前に確認画面を挟むことで誤入力による更新を防止する。
      但し、画面操作が多くなる。

    B)入力画面→完了画面 のパターン
      操作を少なくし、更新結果は完了画面で確認する。
      但し、バリデーション項目以外のデータを誤って登録する
               可能性が増す。

    C)入力画面→一覧画面等 ※確認画面なし のパターン
      作業スピード重視。更新結果は遷移画面の表示結果で
              判断する。

      確認画面が無いので更新内容の確認は難しい。

  ・参照系画面の遷移方針
   データの検索を行う画面・アクションにおいて、
   実行時の結果表示について検討する。
   更新系と同様に、統一された画面遷移を考える。
   
<検索系画面の遷移パターン例>
    A)検索入力画面と結果表示画面が同じ(同じ画面に表示する)
     画面遷移が発生しないため、操作しやすい。

    B)検索入力→検索結果画面への遷移パターン
     ①. ユーザが検索条件を入力し検索を実行する。
     ②. 結果画面に遷移し、検索結果が表示される。
       トップページ等の共通検索入力欄からの遷移などで使用する

    C)検索入力→結果検索(子画面起動)のパターン
     ①. ユーザが検索条件を入力し検索を実行する。
     ②. 子画面が表示(起動)され、検索結果が表示される。
       住所入力の際に、郵便番号検索から該当住所を選択する
                 など、
本画面の補助が必要になるケース。

  ・ 表示・入力規則
   表示や入力方法に対してのルールを設定する。
   項目の分割ルールなどを設定することで入力方法も統一性を持たせる。
   <表示規則の例>
    ・日付 YYYY/MM/DD 形式で表示する。
          YYYY:西暦4桁(1900~9999)
          MM:月1~2桁(1~12)  先頭0は除去
          DD:日1~2桁(1~31)  先頭0は除去
    ・時間 hh:mm:ss 形式で表示する。
         hh:時 24時間(1~24)
          mm:分1~2桁(0~59)  先頭0は除去
          ss:秒1~2桁(0~59)  先頭0は除去
   <入力規則>
    ・日付  西暦(4桁)、月(2桁)、日(2桁)の3つの入力領域に分ける。
           西暦は直接入力、月と日はドロップダウンリストから選択する。
    ・単位  入力欄の外側に単位を記載する。単位を入力しない。
    ・ボタン 権限等により使用できないボタンは非表示にする。
          状況により非活性表示(クリックしても動作しない)

  ・エラー処理
   エラーが発生した場合の表示内容と遷移の方針を定義する。
   ・エラー分類:業務エラー/システムエラー
   ・エラー画面と遷移:分類別にエラー表示の方法と遷移を設定する。
    <処理の例>
     ・業務エラー
      画面遷移せず(アクションを実行した画面)、
      エラーメッセージをメッセージエリアに表示する。
      項目チェックで複数項目でエラーが発生した場合は、
      該当項目のフィールドをエラー時のデザインで表示する。
     ・システムエラー
      エラー画面に遷移し、エラー画面のメッセージ領域に
      エラーメッセージを表示する。
      トップ画面への遷移のみ可能にする。

  ・チェック機能
   画面に入力された項目の値のチェック方法を定義する。
   ・チェックする場所
    クライアント/サーバのどこでチェックするか定義する。
    ロジック設計での設計項目に影響する。
    (クライアントでチェック / サーバでチェック)”
    ・項目チェックの方針
     共通的なチェック方法とルールを定義する。
     画面や項目ごとにチェック方法が異なるような状況を防ぐ。
     ・データ形式チェック
     ・値の範囲チェック
     ・データ間の関連チェック
     ・参照チェック(外部参照データが存在するか等)

  ・利用者・権限の設計
   利用者や部署に設定される権限による画面の参照や
   入力の可否についての方針を定義する。
    ・利用者、部署についての権限定義
     業務に必要なロールを定義する。
    ・画面機能と上記のロールをひもづける。
     画面参照不可時の動作や遷移、項目別の非活性表示の方針を
     検討する。

    ・権限コントロールの実現方法(仕組み)を定義する。

・帳票アーキテクチャ・共通設計
 帳票アーキテクチャ・共通設計は、設計者や帳票毎のバラツキなく
 統一性を持たせることを目的とする。
以下に、検討のポイントを挙げる。
 ・帳票出力方式
  帳票のフォーマットや印刷する環境を設計する。
  この工程で設計した内容が、テストにおける動作検証環境になる。
  ここで設定した以外の環境では動作保証しないことになるので
  ユーザーとの認識合わせが必要。
  ・媒体
   システムで取り扱う帳票の様式、媒体(ファイル、紙)を決定する。
   ・ページサイズ、向き :対応する紙の大きさと出力向きを決める。
   ・出力形式:電子ファイル(PDF、Excel、テキスト)
         印刷(汎用紙、専用紙(印字枠が設定されているもの))
         
  ・出力装置
   帳票の出力装置を定決定する。
   印刷能力により表現範囲が限定されるため。
   <出力装置の例>
    ・プリンタ種別(レーザプリンタ/ ドットプリンタ) と 機種・型番
    
  ・出力先
   帳票の出力先(場所、部署)を定義する。
   <出力先の例>
    ・○○部 XXXビル3F西 XXプリンタ
    ・□□部 YYYYビル1F  XXプリンタ

 ・帳票の分類
  システムで対象にする帳票分類を定義する。
  <帳票分類の定義例>
   A). 単票
     1件のデータを記載する帳票
   B). 表形式
     複数件を一覧化して記載する帳票
   C). 複合
     単票部分+表形式で構成される帳票

 ・デザイン
  統一性のある画面デザインにするように色や文字フォント、
  文字配置など決定する。
  ・レイアウトの各領域
   レイアウトの各領域のデザインを定義する。
   ・文字フォント:フォント種類、サイズ、色、スタイル
   ・背景    :色
   ・枠      :線の種類・太さ等
   ・文字配置 : 上下(上揃え/中央揃え/下揃え)
             左右(左揃え/中央揃え/右揃え)
  ・表現形式
    表、図(ロゴ)、グラフ、バーコードなど、
    利用できる表現の形式を定義する。
    個別設計において、バラバラに使用されて煩雑化することを防ぐ。

 ・表示項目
  デザイン(表示箇所)に対してデータが大きくなる場合の
  表示のルールを決定する。
  <表示ルールの例>
  ・項目編集(項目内折り返しなど)
   対象項目の表示桁数より大きくなる場合の表示方法。
   ・折り返し :表示項目の桁数に達したら改行してデータを表示する。
           改行することで改ページが発生することも考慮に入れる。
   ・フォントサイズを変更 :フォントサイズを小さくして改行せずに表示する。
   ・省略   :表示できる桁数のみ。超えた分は省略する。

  ・改ページ
   表示件数により、複数ページに跨る場合にデータ途中での改ページが
   必要になる。
改ページが発生する際の出力方法を決める。
   ・改ページ発生時のデザイン
    改ページした次ページ以降の表示についてレイアウト/デザインを
    どうするか。
見出しの有無、等
   ・データの取り扱い
    ページ途中で改ページさせる/改ページしない(表示可能な件数のみ扱う)
    複合形式の場合は次ページに送る、等

 ・命名規則
  帳票に表示される文言(タイトル、ラベル)のルールを決定する。
  (ルール論理名と物理名の双方を定義する)
  業務用語、社内の共通用語に合わせる。
  <命名例>
   一覧表示の画面 『XX一覧』、『XXリスト』 ⇒”XX一覧”に統一する。
   コード設定の項目 『○○コード』、『○○CD』  ⇒”○○CD”に統一する

 ・帳票の再作成(再印刷)
  業務上、またはシステムエラーにより再印刷や再作成が
  必要になった場合への対応を設計する。
  処理方法や履歴保持の方法に影響するため、システム方式設計や
  データ共通設計も考慮に入れる必要がある
  ・業務上の再作成
   業務で帳票の再印刷が必要となった場合への対応方針を定義する。
   <対応のパターンの例>
    ・帳票履歴を保存。該当期間の帳票を抽出させる
     帳票データとして履歴を持たせる。
    ・期間指定をして帳票作成を再実行する
     条件を変えて再計算が必要になるケース。
     対応するUI・機能を用意する必要あり。
     
  ・エラー時の再作成
   帳票作成中のエラー処理について方針を定義する。
   帳票作成時のエラー発生は、ロジックのエラー処理と同じ仕組みで良いが、
   ここで検討するのは帳票データが作成されたが後続の印刷でエラーになる場合。
   再処理の方法によって、機能分割やデータ保持の方法に影響がある。
   ・プリンタエラー
    プリンタ故障により出力できない状態。
    紙詰まり、トナー切れなど印刷途中で停止してしまった場合。
    プリンタ機能で継続出来る場合もあるし、再作成(再印刷)が
    必要になる場合もある。
    状況を洗い出して、どの処理から再実行するか方針を決める。
   ・スプールエラー
    スプールにデータ送信できない、スプールからプリンタに
    データ送信出来ない状態。
    状況を洗い出して、どの処理から再実行するかの方針を決める。

 ・利用者・権限の設計(画面と同様)
   利用者や部署に設定される権限による帳票の参照や出力
   についての方針を定義する。
    ・利用者、部署についての権限定義
     業務に必要なロールを定義する。
    ・帳票機能と上記のロールをひもづける。
     帳票出力不可時の動作や遷移、項目別の非活性表示の方針を検討する。
    ・権限コントロールの実現方法(仕組み)を定義する。

・I/Fアーキテクチャ・共通設計
 I/Fアーキテクチャ・共通設計では、設計者やI/F毎のバラツキなく統一性を
 持たせることを目的とする。以下に、検討のポイントを挙げる。
 ・接続方式
  外部システムとの接続方式を可能な限り共通化する。
  接続方式が増えると、その分保守が複雑になり保守性が低下するため。
  ・同期/非同期の決定
   インタフェース先のシステムと状態を同期する必要があるか業務要件と
   接続先システムの技術的仕様を確認する。
   
  ・接続技術
   - DB接続(View/テーブル参照)
   - ファイル連携(CSV,TSVその他の定型ファイル)
   - MQ連携
   - SOAP通信
   - REST通信 等
   
 ・命名規則
  インタフェースで使用する文言のルールを統一する。
  (ルールは論理名と物理名の双方を定義する
  業務用語、社内の共通用語に合わせる。

  <命名例>
   『契約・会計向けI/F』『会計向けI/F』⇒”契約・会計向けI/F”のルールに統一
    (情報の内容と送付先を名前に組み込む)

・バッチ/ロジックアーキテクチャ・共通設計
 バッチ・ロジック共通設計は、バッチに関する前提やルールを設定する作業。
 設計者やバッチ毎のバラツキなく統一性を持たせることを目的とする。
 ・バッチ起動方式の統一
   ・ジョブスケジューラ(JP-1等の製品)
   ・OS(cron、Windowsタスクスケジューラ等)
   ・運用サーバが起動する/アプリケーションサーバが起動する
  
 ・処理方式の統一
  ・バッチ処理の内部プロセスを規定する。
  <処理プロセスの例>
   ・①データ取得プロセス ⇒②データ加工プロセス ⇒③データ保存プロセス。
    この処理プロセスでは、取得・加工・保存の3つの内部プロセスを保持
    しており、設計・開発者がロジックを作りこむ場合には②のデータ加工
    プロセスに記載する。
    また、①や③のように単純な処理(データ取得/保存)は共通関数を用意
    するなどの工夫によって開発工数の削減を図る。

   ・エラー処理
    ①バッチエラー(DB接続エラー)→自動再実行
     バッチ処理でエラーが発生したい場合には、トランザクションの一貫性を
     担保したうえで自動的に再実行する。
    ②バッチエラー(DB接続エラー)→処理ステータス=エラーで終了
     バッチ処理でエラーが発生したい場合には、処理ステータスを”エラー”として、
     処理を終了する。


・データ共通設計
 データ共通設計は、データに関する前提やルールを決める作業。
 以下に、検討のポイントを挙げる。
 ・命名規則
  データの項目名やデータベースのオブジェクトなどの
  名称のルール(論理名、物理名)を定義する。
  名称を統一することはテーブルや項目の意図を把握しやすくすることや、
  共通用語を使用することで認識違いや確認漏れを防ぐ。
  
<名称定義の例>
   ・データベース
   ・データオブジェクト
    スキーマ / テーブル / ビュー / インデックス / シーケンス / シノニム
   ・データ項目(カラム)
   ・ID (コード / メッセージ)
   
 ・オブジェクト分類
  保持データや利用用途からオブジェクトの分類を定義する。
  分類することで管理するデータの重要度を把握出来るようになる。
  
<テーブルの定義例>
  ・テーブル
   - マスタ :部署や社員、商品などの基本的な属性情報をまとめた台帳情報。
         外部システムから連携するものとシステムでユーザが登録する
         2種類が存在。

   - トランザクション:約定や会計などの業務で発生するイベントや取引の情報を
            表すデータ。
時系列に記録する。
   - テンポラリ :処理を行うために一時的にデータを格納する作業用テーブル。
  
  ・ドメイン定義
   データ(項目)に対して用途と型・桁のルールを設定して分類する。
   同じ意味を持つデータで型・桁がバラバラにより設計・製造で不整合
   を起こすことを防ぐ。
   <分類対象例>
    ID/コード/区分、フラグ/日付、時刻/金額、数量
    
 ・コード決定方式
  マスタやトランザクションのテーブルにおける、プライマリーキーやユニークインデックスキーの
  決定方法やコード体系の方針を定義する。
  状況に応じて採用する方針を決めることになるが、データ設計時にテーブル構成
  を統一する。

  ・プライマリーキーの考え方
   プライマリキーを構成する要素と採用ケースの考え方を定義する。
   <プライマリキーの構成要素>
    ・業務で利用する値:業務上意味のある値でキーを決定できる(複合キーも含む)
    ・業務で利用しない値:DBが採番する連番や時間など、業務的な意味を
     持たない値をキーにする

    <採用ケース例>
     ・トランザクションデータの業務コードでは、同じ値が複数存在する
      → シーケンス番号をキーにする
     ・トランザクションデータの業務コードで一意にすることができる
      → 複合キーにする。
     ・マスタデータで新たにマスタを作成する
      → 新たにキーとなるコードを作成する。
      
  ・コード体系の統一
   ステータスやコードなどの名称と値(キー)を決定するための方法を定義する。
   同一亜種または派生コードを数多く作らないためのルール。
   <定義する項目の例>
    ・コード区分、名称
    ・コード値
    
 ・メッセージ設計
  ログや画面に出力するメッセージの管理方法を定義する。
  ・ID体系:IDを見るだけで発生システムや状況、事象が把握できるものが良い
   ・システム識別子:システムを判別出来る
   ・メッセージ分類:通常/エラーなどを把握できる
   ・機能識別子  :問題が発生した箇所や事象を把握できる
   ・連番     :機能やサブシステムで連続番号を付与する

  ・メッセージ:文体や長さ、プログラム埋め込みの指定方法を定義する。
   <メッセージの例>
    [機能ID]でエラーが発生しました。( [ ]はプログラムがセットする)

  ・メッセージの管理方法
   設計書の管理や、設計書→定義への自動生成などの管理方法を検討する。

  ・多言語対応
   システムを使用するユーザに合わせた言語を用意する。(日本語、英語等)   

・コード・メッセージ一覧
  コード・メッセージを一覧でひとつの台帳で管理する。
  コード値やメッセージの揺れ(亜種の増加)が発生していないか確認できる。

・共通機能一覧

 機能共通設計は、機能(ロジック)に関する前提やルールを設定する作業。
 設計者や機能毎のバラツキなく統一性を持たせることを目的にしている。
 共通化の検討は、各層をバラバラに検討するのではなく、1処理は各層に
 連動して影響を及ぼす為、大局的・横断的に検討を進める。
 以下に、検討のポイントを挙げる。

 ・レイヤー毎の共通化方針
  ロジック設計において、画面⇔機能/機能⇔データを結びつける作業を行う。
  その際に、各レイヤーの動きを意識することになるので、
  各レイヤーの役割と動き、共通機能での提供などのルールを定義する。
   → 設計者間でのばらつきを抑制することになる。
  ・プレゼンテーション層(ユーザインタフェース)
   レイヤー間(プレゼンテーション層⇔ビジネスロジック層)の受け渡し方法を共通化する。
  ・ビジネスロジック層(サービス、ロジック)
   トランザクション、DBロック、ロギング、共通関数についての処理を共通化する。 
  ・データ層
   テーブルやファイルへのアクセス方式を共通化する。
   
 ・共通化機能・部品 実装方法
  共通として提供する機能・部品の仕様や設計上の使い方を定義する。
  ・プレゼンテーション層
   ・ユーザインタフェース部品(表示部品)
   ・レイヤー間のデータ受け渡しインタフェース機能
   ・画面遷移の制御  
  ・ビジネスロジック層
   ・トランザクション制御
   ・DBロック制御
   ・ログ出力
   ・編集処理の共通化(関数)
  ・データ層
   ・テーブルアクセス制御
   ・ファイルアクセス制御

 ・共通化した処理を一覧化して他の開発者が利用できるようにする。

- 
 2  運用設計 ・運用範囲と体制
 ・システム運用の範囲

  システム運用として対応する範囲、作業内容を定義する。
  ・システム監視
   システム異常発生の検知や異常予測のために行う。
   - ネットワーク
   ハードウェア
    ミドルウェア
    アプリケーションの死活
    エラー
    リソース(CPU/Memory/Disc)
   バッチアプリケーション(ジョブ)の実行状況の管理
   システム稼動状況の報告、閾値超過時期の分析

  ・データ運用(ファイル/データベース運用)
   障害発生時のリカバリや、リソース圧迫・性能劣化防止のために行う。
   ・ バックアップ/リストアの実施
   ・ ファイル・データ運用 (パージ、ローテーション)
   ・ バックアップ媒体の管理

  ・障害管理
   障害発生時の迅速な対応と、対応状況の把握をする。
   ・障害対応ワークフローの管理
   ・障害発生時の初動(連絡、一時切り分け)のルール、マニュアルの整備

  ・構成管理
   設計書やモジュールを管理し、デグレードを防止する。
   ・ネットワーク、ハードウェア、OS、ミドルウェアの情報管理
   ・アプリケーション ソースコード・ドキュメントのバージョン管理
   ・本番/開発/テスト環境の構成を管理

  ・定期保守
  システムの正常な動作を維持するために、ハードウェア、ミドルウェアの
  メンテナンスを行う。

   ・ 断片化解消、領域拡張、マスターデータのメンテナンス等の事前計画済みの
    システム停止作業

   ・ハードウェア、ミドルウェアの保守契約、定期保守作業の頻度の管理
   ・ パッチ適用、活性保守 等の作業

  ・セキュリティ対策
   情報セキュリティに関する規程/ルール/法令に従い、安全なシステム環境を
   提供するために対策を実施する。

    ・ 不正アクセス/データ改ざん/ウィルス侵入の監視
    ・ マルウェア、ネットワーク対策、セキュリティパッチの適用

  ・災害時運用(事業継続計画 BCP)
   災害など不測の事態における業務継続の対応策を決定する。
   ・ 災害時のユーザ業務/システム運用の範囲と実施方法を策定
   ・ 災害訓練の計画を策定

  ・サービスデスク、利用者支援
   システム利用者からの問合せ業務、システム変更依頼への対応を整理する。
    ユーザからの問合せ対応/作業依頼の対応フロー

 ・運用体制
 システム運用の範囲で洗い出した作業に対して担当者/関係者、役割を定義する。
 
「システム化要件定義支援 主管部署・関連ユーザ一覧」を入力情報にして精査する。
  ・主担当部署
  ・関係部署
  ・外部機関
  ・ベンダー(ハードウェア/ミドルウェア、開発/保守 等)

・運用スケジュール
 システム運用における稼働日/停止日のスケジュールを定義する。
 ・システム運用日、カレンダーの作成
  ユーザ業務、システム運用業務にあわせて運用日について定義する。
  ・1日の定義
    – ユーザ業務      : 営業日、非営業日
    – システム運用業務 : 稼働日、メンテナンス日、非稼働日(停止日)
      一般的なカレンダー(平日、休日・祝日)との関係を確認
   - 日替り時刻 (何時から何時までを1日と考えるか)
  → 上記を踏まえて
運用カレンダー(システムで管理するカレンダー)を作成

 ・システム運用のスケジュール
  ユーザ業務/システム運用業務のどちらも含む、1日の稼動スケジュール。

  ・稼働日、メンテナンス日、非稼働日のスケジュール
   - ユーザ業務  : オンライン/バッチ実行の時間帯
   - システム運用  : 監視/ジョブ運用/バックアップ/再起動の時間帯

・ジョブ運用
 ジョブ運用の方針を定義する。
 全体最適を考慮して、現行システムのジョブ運用を確認すること。
 ・ジョブ運用の方法
  
ジョブの実行を管理する仕組みを定義する。
  <ジョブの実行方法(例)>
   ・ジョブ運用ツールを利用する⇒OSスケジューラ(cron等)を使用する
   ・時刻の同期方法:NTPサーバーとの時刻同期

  <ジョブの定義方法>
   ・ジョブの定義方法、反映方法の確認(ジョブ運用ツールやOSに依存する)
   ・カレンダーの適用や日替り時の実行予約を定義する。
    ツールで提供されている際はその旨記載する。
   ・ジョブ定義の変更方法は、構成管理に含めて管理する。

 ・ジョブ(自動実行化)の一覧化
  システム運用業務で自動化する作業(ジョブ)を定義する。
  システム監視、データ管理等のシステム運用から抽出し、ジョブ一覧へ反映する。

・システム監視
 システム監視(障害検知、稼働状況の把握)を設計する。
 ・ 監視項目と対象の定義
  システムの異常を検知・把握するために行う監視の定義を行う。
  ・監視項目
   - 死活監視  : サーバ・ネットワーク機器、プロセスの稼動監視
    – エラー監視  : サーバ、ミドルウェア、アプリケーションで発生したエラーの検知
    - リソース監視 : サーバのCPU、メモリ、ディスク利用率、
               ミドルウェアのメモリ、データ容量の監視
   - 性能監視  : アプリケーションの処理時間、利用数(アクセス数)の監視
   - 実行監視  : バッチアプリケーションの実行監視

  ・監視対象(監視対象に対してどの監視項目を行うかを結びつける)
    - ネットワーク
    - ハードウェア(サーバ/ストレージ)
    - ミドルウェア(OS、データベース、アプリケーションサーバ 等)
    - アプリケーション
  ・監視頻度
    監視項目について確認間隔を定義する
  ・通知レベル
    検知・通知するレベル(情報、警告、エラー、致命的エラー等)を定義する
  ・閾値レベル
    数値で管理できるものについては、通知レベルに対して閾値を定義する

 ・監視方法
  監視対象に対して監視項目毎に検知する方法を定義する。
  監視ツールや方式を定義する。以下に例を記す。  
  <監視ツール>
   JP1、Tivoli NetCool、OSS(ZABBIX、Hinemos) 等
  <監視方法>
   ・死活監視  : Ping疎通/プロセス生存/エージェント通信/SQL疎通/HTTP疎通
   ・エラー監視  : ログ確認(syslog、アプリ等)/SNMP Trap通知/イベント通知
   ・リソース監視: モニタ機能/ログ出力・収集/イベント通知/ツール・コマンド実行
   ・性能監視  : ログ確認(処理時間、開始終了時間)
   ・実行監視  : 実行ツール通知/ログ確認
  
機器やソフトウェアの作り込み等が必要な場合は、その手段を記載する。
  
 ・稼動統計の分析と報告
  稼動統計の分析や報告の運用業務について定義する。
  
分析・報告対象(例)
   ・ リソース利用率
   ・処理性能 オンライン(アクセス数、平均・最大処理時間)、バッチ(処理時間)
   ・ リソース、処理時間の閾値超過時期の算出

 ・監視業務設計
  具体的な監視項目に対して、監視レベル(閾値など)や情報収集方法を決定する。

  ・論理サーバ/物理サーバ単位で監視定義を作成
   ・監視対象毎に障害等のイベント発生~検知までの作業の流れを設計

・データ管理
 システムのバックアップ/リストアや、ファイル(ログ/データ)やデータベース運用を設計する。
 データ保持期間等は、業務目的の他にシステム監査/FISC/関連法律も確認する。
 社内標準のデータ管理ルール、現行システムの運用を確認する。
 機器やミドルウェアの故障、大規模災害についても考慮する。
  ・バックアップ対象
  システムショウガイガハッセイシタサイに、迅速に回復させるためのバックアップ対象を定義する。
   <対象>
   ・サーバ(OS)、ミドルウェア、アプリケーション
   ・データベースデータ
   ・ファイル
  <取得頻度、取得単位、保存期間・世代、保存場所・媒体>
   ・日次/週次/月次、システム変更時のみ
   ・全量/差分
   ・保存期間、世代管理
   ・保存場所(論理、物理)、媒体

 ・バックアップ/リストアの方法
  バックアップ対象に対してのバックアップとリストア方針を定義する。
  <バックアップ/リストア方法>
   OS,DBツール等での実施方法、バックアップデータ参照要否の確認

   ・実施方法:サーバ(OS)、ミドルウェア、アプリケーション
   ・対象:データベース、ファイル
  <バックアップや媒体の管理方法>
   ・取得したバックアップの管理方法、世代管理の方針
    それぞれの保管方法と期間を明確にする。
   ・バックアップ対象のサイズ、保管分のサイズを見積もる。

  <リストアの整合性>
   ・障害発生時のリストア順序
    データ消失、機器/ミドルウェアの故障や大規模災害も考慮する
    リストア時の業務データ整合性の確保、又は制限事項
    業務復旧までの流れと他システムの協力要否を明確にする

   
 ・ファイル、データベース管理
  単純増加や断片化発生など、放置するとシステム運用に影響を与えるファイル、
  データベースの管理方針を定義する。

  ・ ファイル(例)
   - 対象分類 :ログファイル/インタフェースファイル 等
   - 制約    :保存期間(システム監査準拠、アプリケーション都合) 等
   - 運用方法 :パージ/ローテーション/バックアップ

  ・データベース(例)
  <データ>
   - 対象分類:トランザクション/マスタ/中間データ
   - 制約   :保存期間(システム監査準拠、アプリケーション都合) 等
   - 運用方法:パージ/バックアップ(退避・保存)       
  <データベースメンテナンス(例)>
   定期的なメンテナンスとして実施するメンテナンス内容を決定する。
   - データベース統計情報の更新
   - インデックス再構築
   - 断片化解消(表領域の再編成)

・障害管理
 障害発生時の影響範囲とその対応方法についてケース毎に定義する。
 業務データへの影響(トランザクションの抜け等)があるケースには特に注意が必要。
 対処方法で、システム化するものはその旨記載する。
 設備障害(電源使用不可、大規模災害)のケースについては社内のBCPに準拠する。
 
<障害ケース整理の観点>
 ・障害発生箇所と影響範囲
   システム内で障害が発生した場合の障害箇所とその影響範囲
  ・発生箇所
   ネットワーク機器/WEB・APサーバ/DBサーバ/クライアント端末/運用管理サーバ 等
  ・影響範囲
   業務・システムの継続性に対する影響
  ・対処方法
   障害発生時の復旧方針・復旧方法
 
  <DBサーバに障害が発生するケース(例)>
   ・影響範囲 :DBサーバは2台の冗長化構成。
           1台が停止してもDBが停止することは無い。
            →業務影響は発生しない。
   ・対処方法 :故障箇所の部品交換

 ・障害対応業務設計
   「障害発生箇所と影響範囲」で検討した対処方法について、
   「ジョブ運用」「システム監視」「データ管理」の情報を踏まえて
   具体的な方法を設計する。

    ・システム障害発生時の連絡体制、連絡経路・情報の管理方法を定義する。
    ・手順を作成する。  
     ・システム監視/リカバリ手順書
     ・リカバリ用のジョブやツールの設計 など

・構成管理
 構成管理の対象と管理方法(手段、フロー・役割)を設計する。
 ・構成管理の対象
  構成管理の対象を定義する。
  <対象要素>
   ・ネットワーク/ハードウェア
   ・ミドルウェア(OS、DB、ミドルウェア)
   ・アプリケーション
   ・マスタデータ
  <対象成果物>
   ・設計書、マニュアル、テスト関連証跡(表示結果等)
   ・プログラム・定義ファイル、データ、
   ・テストプログラム・テストデータ
  <対象環境>
   ・本番/テスト/開発 等

 ・構成管理の方法 
  管理対象について管理方法を定義する。
  ・管理開始タイミング
  ・対象成果物の管理手段:ツール利用 最新バージョン管理/バックアップ管理
                   手作業(更新履歴作成)
  ・変更時の管理方法   :プログラム・定義ファイル、データの変更・反映方法
                   システム環境への資源反映方法
                   文書の変更・反映方法
 ・構成管理プロセス
  システムに変更が発生する際の作業プロセスを定義する。
  ・作業の内容と順序
  ・作業の担当者、役割(権限)
  ・状況、ステータスの定義

 ・構成管理手順とツールの設計 
  実際の管理手順や使用や作成するツールの設計、ガイドを作成する。

 ・開発/テスト/本番/環境一覧の作成
  各環境にアクセスする為に必要な情報を一覧化する。
   ・サーバ名/データベース名
   ・システムユーザーID
   ・システムユーザーパスワード
    (社内のセキュリティポリシーに従い、必要に応じてパスワードは別紙に記載する)

・定期保守
 保守におけるメンテナンス作業(計画停止で行う作業)、
 ハードウェア・ソフトウェアへのパッチ適用について方針を定義する。
 ・メンテナンス、計画停止
  定期的に実施するメンテナンス作業と計画停止について定義する。
   ・メンテナンスや点検作業の洗出し。システム停止の要否確認
   ・計画停止の作業を定義 (サーバの定期再起動等)
 ・ユーザ管理
   システムのを利用ユーザ(ログインID)の更新作業、利用有無の点検作業を定義する。
   ・システム利用/業務利用のユーザ更新
   ・利用有無の点検
 
 ・パッチ適用、活性保守の範囲と方法
  稼動開始後の製品バージョンアップ、ファームウェアやパッチ適用、活性保守について定義する。
  ・バージョンアップ、ファームウェア/パッチ適用の方針
  ・活性保守の実施方針
  ・適用範囲の定義

 ・製品の保守契約、定期保守作業の定義
  ハードウェア、ソフトウェアの保守契約と定期保守について定義する。
  ・保守契約の対象
  ・契約内容(サービスレベル)、期間
  ・定期保守(実施内容と時期)の確認
  
 ・定期保守の手順作成
  実施する保守作業の具体的な方法(手順)を設計する。
  ・システム停止/再起動手順
  ・ユーザ管理手順

  ・パッチ適用、活性保守の手順

・セキュリティ対策
 システムのセキュリティ対策について設計する。

 社内のセキュリティポリシーに準拠する。
 インターネット上に公開しているシステムかどうかを確認する。
 ・対策対象と箇所・方法の定義
  セキュリティ・インシデントの脅威に対する対策と検知方法を定義する。
  <セキュリティ・インシデント脅威>
   ・外部からの不正アクセス
   ・マルウェア(ウィルス、ワーム、ボット等)の感染
   ・データ改ざん
   ・なりすまし
  <検知方法>
   ・セキュリティ監視ツールの導入
   ・ログ監視
   ・データ検証
  <対策方法>
   ・脆弱性診断の実施
   ・認証機能、データ暗号化機能の作成
   ・パスワード管理、変更運用の定義
   ・セキュリティツールの導入 :導入箇所と設定方法、メンテナンス方法
     ・ネットワーク、ハードウェア
     ・ミドルウェア、アプリケーション
   ・認証機能、データ暗号化機能の設計
   ・パスワード管理機能の設計

・災害時運用(BCP)
 社内のBCPに準拠する。
 大規模災害によるBCP発動時の業務継続・システム運用について定義する。
 
・災害時のユーザ業務/システム運用
  BCP発動時に業務継続対象になるユーザ業務/システム運用を定義する。
  定義した上でシステムとして必要な機能/状況を洗い出す。
  ・稼動対象となるサーバ、機能
  ・データ状態
  ・利用部署(物理的な場所)
  
 ・災害訓練の実施方針、作業範囲
   災害訓練の実施方針、作業範囲を定義する。
   環境の制限事項、準備方法など考慮や準備が必要なことを明確にする。

・サービスデスク、利用者支援
 アプリケーション担当者、システム基盤・運用担当者との役割を明確にする。
 業務ユーザからの問合せの受付、その後の対応や担当部署への仲介、
 問合せ記録の管理方法、などを定義する。

 ・各担当者の対応範囲、業務
 ・初期対応の方法(切り分け、各担当部署への仲介ぎ等)
 ・問合せの記録方法

・運用に関する開発対象(機能、マニュアル)の一覧
 システム運用に関する機能やマニュアルを一覧化する。

・H/W、M/W設計
  サーバ(物理、論理)の環境を設計する。
 ・リソース割当の決定
  物理・論理サーバ、ミドルウェアに割り当てるリソースを決定する。
  ・CPU、メモリ、ディスク容量を決定する
   性能要件(障害時における性能確保含む)を満たすよう確認する。
  ・全体設計、可用性/性能設計の方針に従い、負荷分散を考慮して再検証する
   検討結果だけでなく、性能、拡張等の方針からの算出根拠を記載する。

 ・冗長、拡張の実装
  <冗長>
   可用性確保の実装方法を定義する。(可用性設計で取り決めた方針に従う)
   ・構成要素(機器、部品)単位での冗長化有無と実現方法
   ・災害対策、隔地配置
  
  <拡張>
   処理能力・容量不足時の性能確保の実装方法を定義する。
   (性能設計の方針に従う)
   ・機器、部品の構成単位での実現手段(スケールアップorスケールアウト)
   ・スケールアップの場合は、最大拡張容量を確認する(ハードウェアに依存)
   ・拡張時のサーバ・機器追加構成を整理する
   ・システムのライフサイクル(出荷年数、システム更改期間)を考慮する

 ・ディスク構成設計
  運用や性能を考慮してディスク構成を検討する。
   ・ストレージ/サーバ(ローカル)のディスク配置
   ・パーティション構成、ボリューム配置、スライス設定、ドライブ割当
    - 業務単位での配置 (バックアップ/リカバリの容易さ)
    - 集中化を防止(重要データの集中、高負荷業務の集中の性能面を配慮)
     データ特性を確認すること

 ・ディレクトリ構成設計
  ディスク構成設計からOS、ミドルウェア、アプリケーション資源の配置を検討する。
   ・運用や性能を考慮しディレクトリ構成を決定
   ・ディレクトリの権限を設定
   ・利用用途による配置ルールを作成
    - 業務アプリケーション担当者が勝手に配置/利用することを避ける
    - 性格の異なるファイルが混在することによる運用上の混乱を避ける
    - バックアップやファイルの管理を容易にする”
    
 ・ファイル設計
  ディレクトリと配置されるファイル用途を確認する。
  ・用途毎にファイルの削除タイミングをルール化。
   - 保存期間の確認
   - 削除タイミングの設定:利用者タイミング、自動化(定時実行)
  ・ファイル破損時のリカバリー方法
   - バックアップからの復元
   - アプリケーション再実行による再編成
    
 ・主要パラメータ
  上記までの作業からハードウェア、ミドルウェアの主要パラメータを定義する。
  設計をせずにデフォルト値を適用するのではなく、根拠を明確にする。
  ・カーネルパラメータ
  ・インストール時オプション
  ・環境変数 等
  <設定例> 
  ・OS Unix,Linux系
   - プロセス 最大プロセス数(システム全体/ユーザ毎)、 最大ログイン数
   - ファイル オープンできる最大ファイル数、最大ファイルサイズ
   - メモリ  共有メモリサイズ(システム全体/プロセス毎)、セグメント数、
         セマフォ数、スワップ頻度、ライトバック割合
   - ネットワーク 1ソケットあたりのメモリ使用量、送信用/受信用ウィンドウサイズ、
           Negleアルゴリズム/遅延Ack
  ・データベース
   - データベース・ブロックサイズ
   - バッファキャッシュ、共有プールのメモリサイズ
   - 最大プロセス数
   - 最大ファイル数
   - 1セッション当たりの最大カーソル(アクティブなSQL文)数
   - 制御ファイルの管理数
   
 ・ユーザ管理
  ミドルウェア(OS、データベース等)で定義するユーザとその権限を定義する。
  ディレクトリ構成、ファイル設計を反映する。”

・ネットワーク設計
 利用目的と将来予測を確認する。
 ・事前確認
  ・ユーザー数と増減予測
  ・アプリケーションの通信要件
   ・通信方式(HTTP、FTP等)
   ・通信先(対外システム、クライアント)、ロケーション、媒体(モバイル)
   ・データ量
   ・性能要件
  ・セキュリティ要件
   ・暗号化
   ・外部からの攻撃回避
  ・物理的条件
   ・設置場所
   ・配線・配管の数量
   ・環境(本番、テスト、開発 等)
   
 ・ネットワーク構成
設計
  ネットワークの設計を行う。
  ・ネットワーク構成(論理)
   システム、アプリケーションで必要となるネットワークの論理的な
   要件・構成を整理する。
   ・サーバ間の接続(相手先サーバの場所)
   ・クライアント/取引先(業務ユーザの取引関係者)との接続
  ・ネットワーク機器の冗長化・多重化
   システム構成、可用性・信頼性設計の点で多重化する箇所と方法を決定する。
   ・サーバ、機器の障害時に通信断が発生する箇所
   ・性能面でボトルネックが発生する箇所
   
  ・セキュリティの確保
   外部からの攻撃、ネットワーク機器のウィルス感染への
   ネットワーク構成上のセキュリティを検討する。
   ・外部
からの攻撃対策
   ・ソフトウェア、アプリケーションの利用ポートの確認
   ・通信制限の要否
   
 ・セグメント
  サーバ・アプリケーションの利用用途によりネットワークセグメントの
  分離を検討する。
  ・利用用途(業務、運用、開発 等)
  ・システム拡張(サーバ等)のセグメント追加の考え方を決定する。
  
 ・物理構成の決定
  ・ネットワーク機器の接続状況・根とワーク経路の確認
   機器の使用ポート/空きポートの確保
  ・IPアドレス/ホスト名
   セグメント/サーバに対するIPアドレス割当と割当ポリシーを決定する。
  ・ホスト名とIPアドレスの一覧を作成
する

・環境定義・構成管理定義
 システム方式・共通設計、非機能設計を通して設計した環境・構成管理情報の
 整合性を確認する。

 開発プロジェクト期間中と、システムリリース後の環境管理、構成管理に関する
 運営ルールを定める。

 ・環境管理/構成管理関連の管理帳(環境一覧・成果物一覧等)を定義し、
   更新ルールを決定する。

 ・開発/テスト環境のサーバディレクトリ構成を決定する。
 ・詳細設計以降の工程で、各設計者がサーバ名・DB名等の環境情報を容易に
  入手できるように、
環境一覧資料を最新化する。

 -
 3  全体フロー・一覧

 基本設計工程の個別設計を着手するにあたり、各種一覧作成または
 最新化する。対象の成果物を記す。要件定義工程で作成済みの成果物は
 更新が必要ないか確認する。

 <一覧系資料>
 ・業務フロー(要件定義工程で作成済み)
 ・データフロー(要件定義工程で概要レベルの版を作成済み)
 ・機能一覧(要件定義工程で作成済み)

 ・画面一覧(要件定義を踏まえて当工程で作成する)
  ・業務一覧/機能一覧と照らし合わせる
   業務一覧のシステムフロー欄から画面として用意するものを抽出して一覧化する。
  ・システムフローに出現する画面を全て記載する 
   <必須記載事項>
    ・画面名/画面概要/対応する業務ID
     この作業では漏れがないことを優先し、重複排除や共通化は意識せずに
     全ての画面を洗い出す
   
  ・画面アクション、画面分類を整理する
   各画面についてアクション(画面でユーザが実施すること)、画面分類を整理する
   ・アクション : 利用者視点からの業務や操作を記載する
   ・画面分類 : 画面概要、アクションから分類(画面共通設計で定義)を定義する
   
  ・画面の共通化を検討する
   複数の画面を1画面で対応できる場合は、画面を集約する。
   (システム利用者の権限やデータの状態等が違うだけなど)
   ただし、表示制御の複雑さ、異なる業務(目的)利用が混在するなど、
   集約することでかえって処理が複雑になる場合は集約しないことも考える。
   画面の共通化を踏まえて、画面を一覧を最新化する。 

 ・帳票一覧(要件定義を踏まえて当工程で作成する
  設計対象の帳票を一覧化する。
  ・業務一覧と照らし合わせる。
    業務一覧/機能一覧のシステムフロー欄から帳票として用意するものを
    抽出して一覧化する。
  ・システムフローに登場する帳票を全て記載する。
   <記載事項>
    ・帳票名/用途/帳票分類(帳票共通設計で定義)/対応する業務ID
   この作業では漏れがないことを優先し、重複排除や共通化は意識せずに
   全てを洗い出す

  ・帳票の共通化を検討
   ただし、表示制御の複雑さ、異なる業務(目的)利用が混在するなど、
   集約することでかえって処理が複雑になる場合は集約しないことも考える。
   帳票の共通化を踏まえて、帳票を一覧を最新化する。

 ・ジョブ一覧(要件定義を踏まえて当工程で作成する
  バッチ処理の実行フローとスケジュール、実行方法を一覧化する。 
  ジョブ :システムが(主にバッチ処理で)実行する処理の単位
      (= ここでは起動の単位と考える)
  ジョブネット:ジョブのまとまり。ジョブを管理する単位。
       業務単位、期間(日次/週次)などでまとめられたもの

  ・ジョブに関する情報
   ジョブネットの中にジョブ(実行する単位)を定義する。
   実行する順番で記載する
   システム運用業務(運用設計)を取り込む
    <記載内容>
     ・名称
     ・対応する業務ID
     ・ジョブ概要(ジョブの実行条件)
      ジョブ実行の条件
      ジョブの実行順序、多重実行数の有無、ジョブネット間のつながりを考慮。
      ・サイクル    :ユーザ業務、システム運用業務の運用日定義
      ・時刻       :ジョブの開始時刻
      ・終了予定時刻 :通常時のジョブの終了時刻
                 他システムとの連携や後続ジョブへの影響を考慮する
      ・打ち切り時間  :処理遅延が発生した際に処理を打ち切る時間
                 他システムとの連携や後続ジョブへの影響を考慮する
      ・起動条件 :ジョブを起動する判断(スケジュール設定、前ジョブの終了待ち
      ・再実行方法 :ジョブが異常終了した場合の再実行の方法
               単純再実行/スキップ 等
  ・ジョブネット
   業務特性からバッチ処理のまとまりを定義する。
   ジョブ運用の1つの管理単位とする。
    <記載内容>
     - 業務単位(Lv1、Lv2)
     - 期間(日次/週次/月次)
     - 業務時間(オンライン)、業務時間外(オフライン)

 ・インタフェース一覧(要件定義工程で概要レベルの版を作成済み

 (テーブル・ファイル一覧) 
  基本設計工程のデータ設計が完了するまでに作成する。
  当ページのデータ設計の欄に記載。

業務フロー業務フロー 
 

データフローデータフロー 

機能一覧機能一覧

画面一覧画面一覧

帳票一覧帳票一覧

ジョブ一覧ジョブ一覧

IF一覧IF一覧

 

 4  画面設計

・画面レイアウト、項目定義
 画面のレイアウト(表示項目、配置)、ボタン押下時や表示時の制御動作を定義する
 画面の設計は実際に業務で利用するユーザ、システム運用担当者と
 確認しながら作業を進める。
モックアップ画面を用意するなど、
 可能な限り利用者が直感的に内容を
把握出来る進め方にする。
 特に業務ユーザが利用する画面の遷移/レイアウトは、ユーザの合意を得ること。

 ・画面レイアウト

  画面に表示する内容や配置を定義する。
  ・画面概要(業務目的)
   ・レイアウト:表示項目と配置をモックアップで表す。
    - 初期表示  他の画面から遷移してきて初めて表示する際の内容や動作
    - 動作仕様  画面を操作した後の表示変化(ボタン押下など)
    - 表示件数  性能影響(処理負荷)の目安になる
    
  ・画面項目定義
   - コンポーネント名/コンポーネント種別/データ型・長さ 等の表示内容を定義
    (画面共通で定義した共通項目は除く)
   - エンティティ一覧、ER図(概要)を参照し、各エンティティに対して
    不足している項目があれば足す
    →画面とエンティティの結びつけをしながら項目情報を定義する
    (= データ設計のインプット情報)
    <考慮点の例>
     表形式での表示件数の妥当性
     - 見やすさ(該当箇所の把握のしやすさ)
     - ページ送り(ページネーション等)の利用
     - 画面表示時間への影響
  
  ・バリデーションの定義
   入力(文字入力、リスト選択 etc)時の入力値チェックを定義する。
   ・項目定義欄    バリデーションの実施有無
   ・バリデーション 欄  検証内容
   
  ・アクションの定義
   ボタン、リンク選択後の動作(呼び出される機能 等)を記載する。
   ・画面と機能の結び付けを意識する ・・・ 分割した機能粒度を再検証する
   ・呼び出される機能は必ず業務一覧と結びつける。結びつかない場合は
    業務一覧の見直しをする。

   ・画面遷移、アクション一覧と整合を取る。

・画面遷移/アクション
  ・画面遷移、アクション
  画面遷移を図式化し、画面構成を確認する。
  ・画面遷移図の作成
   業務一覧(システムフロー)と画面一覧から画面遷移を作成する。
   業務一覧のLv3 または1 Lv2単位で作成する。
   ・すべての遷移が記載されている
   ・アクションは、画面一覧、アクション一覧と整合が取れている
  ・アクション一覧の作成
   業務一覧(システムフロー)と画面一覧からアクション一覧を作成する。
   ・アクションに対して、実行可能ロールを定義する。
   ・業務一覧のシステムフローと整合を取る。
   ・画面遷移図と整合が取る。

画面設計 
 5  帳票設計

 帳票のレイアウト(表示項目、配置)、帳票作成時の動作を定義する
 帳票の設計は実際に業務で利用するユーザ、システム運用担当者と
 確認しながら作業を進める。実際の帳票と同じレイアウトの帳票を
 用意し、可能な限り利用者が直感的に内容を把握出来る進め方にする。

 ・帳票レイアウト
  帳票に表示する内容や配置を定義する。
  指定レイアウト(会社指定、法定帳票 等)の有無を確認する
  ・帳票概要(業務目的)
  ・レイアウト : 表示項目と配置を図で表す
            項目編集(項目内折り返しなど)
            改ページ(改ページ発生時のデザイン)
            1ページの表示件数

  ・レイアウトに影響を与える設計内容を付記する
   - 表示対象  掲載対象のデータや基準日などの業務面の意図
   - 処理件数  1回の処理で出力する帳票件数。性能影響(処理負荷)の目安
  
  
・帳票項目定義
   - コンポーネント名/形式/長さ 等の表示内容を定義
   - エンティティ一覧、ER図(概要)を参照し、各エンティティに対して
    不足項目を足していく

    →帳票とエンティティの結びつけをしながら項目情報を定義する

帳票設計 
 6  インタフェース設計

・インタフェース項目定義
 データ抽出元(入力)とデータ編集後(出力)のフォーマットを定義する。
 他システムと連携するフォーマット(テーブル定義書等)を入手する。
 ・データ型
 ・長さ(数値の場合は、整数桁/小数桁)
 ・必須項目

 <考慮点>
 ・任意項目の扱い  :NULL/空白設定など
 ・項目の0や空白埋め :無し/右寄せ(前方の0・空白埋め)/
                左寄せ(後方の0・空白埋め)

 ・フォーマット   :カンマ編集/日付編集
 ・特殊文字の扱い  :エスケープシーケンスの編集
 ・長さ       :全角・半角、フォーマットの考慮(カンマ編集のカンマ含むなど)
 ・エンティティ一覧、ER図(概要)を参照し、エンティティとの結びつけて設計する。

・インタフェース編集仕様
 データ編集後(出力)の各項目についての編集方法を定義する。
 ・データ抽出元(入力)との結びつけ
 ・データ編集方法

 <考慮点>
 ・データ抽出元(入力)が存在している。
  他システムと連携する場合には、本番データ相当のサンプルデータを
  提供してもらう。

 ・データ編集や計算箇所の業務仕様が明確になっている
 ・桁数あふれが発生しない。または、桁あふれが発生時の制御仕様が
  決まっている。

IF設計 
 7  ジョブ設計 ・ジョブフロー
  ジョブ一覧で検討したジョブネット、ジョブの流れを図式化する。
   ・ジョブネット内の実行順序が把握できる記載にする
   ・ジョブネット間の連携を把握できる記載にする
   ・実行多重度(単独、複数)が把握できる
    フローで表せないものは(ある時刻での多重実行数など)は特記する。
ジョブ設計
8  データ設計

・テーブル(データ項目)定義/エンティティ一覧・ER図の更新
 要件定義工程で作成したエンティティ一覧、ER図(概要)を基本にして、
 画面設計、帳票設計、インタフェース設計の情報をもとに、
 テーブル・ファイル一覧、各項目定義を作成する。また、エンティティ一覧、
 ER図を更新する。
 
・データ項目の定義
  画面、帳票、インタフェース設計の結果をもとにデータ項目を定義する。
  データ項目名称はシステム内(および社内全体で)標準化する。
  
 ・エンティティの最新化
  画面、帳票、インタフェース設計の結果を踏まえてエンティティ一覧・ER図を
  最新化する

 ・テーブルの正規化
  エンティティ1つずつに対して、
  正規化(第1-第3のどのレベルまで正規かするか)を検討する。

 <正規化の目的>
  冗長なデータを排除し、従属関係を整理して格納場所(テーブル)を
  分割することでシンプル(一意に判別できる)で且つ、データ更新で
  不整合が発生しない構造にすること。
  One Fact in One Place (1つの事実は、1つの所で管理する)

 <正規化しない場合のデメリット例>
  ・更新/参照対象が1つのテーブルが集中する。処理の分散化が出来ない
  ・修正(項目追加/削除)の影響範囲が把握できなくなる。
   項目間での関連性が分からない
  ・項目数が増加し(冗長)、格納領域を消費する。
   検索性能(キャッシュヒット率)が低下する

  この時点では、検索性能の高速化や業務上のデータ可読性を目的にした
  非正規化のままにすることは考えない。
  しかし、業務設計としての最適なデータモデリングをこの後に行う。
  また検索性能の高速化はテスト工程におけるチューニングとして実施する。
  
  <正規化の基本>
   ・第1正規化 :エンティティに 主キーを設定する。
           繰り返しの項目を複数のレコードに分割して,
           繰り返しを排除する。
           
   ・第2正規化 :部分関数従属する(主キーの一部に従属する)
           項目を別のエンティティに分離する。
           分離した(従属する)エンティティと従属関係を結ぶ。
           外部キーを設定する。
           
   ・第3正規化 :主キー以外のキーに関数従属する(ある項目が定まると
           他の項目が定まる)項目を分離する。
           分離した(従属する)エンティティと従属関係を結ぶ。
           外部キーを設定する。
           
 ・全体最適化
  個別に設計したエンティティを、全体を通して見直す。
   ・重複するデータ、エンティティは統合・排除する
   ・同じデータが異なる業務Lv間やシステム間で存在している場合
   ・名前が違うが同じ意味のデータが存在している場合
  
  ・エンティティ分類の見直し
   ・トランザクション、マスタの分類が正しいか。
   ・無駄な中間エンティティが存在しないか。
   ・格納されるデータ内容でエンティティ分割(または統合)を検討する。
    <エンティティを分割する例>
     ・1つのエンティティ内で機能や区分の分割を行う
      ・商品属性の細分化 株式/先物
      ・組織属性の細分化 個人客/法人客 本社/支社
    <エンティティを統合(非正規化)する例>
     ・第3正規化まで行ったが、1つの業務で扱うエンティティが多くに
      分割されてしまい、直感的に関係性が把握できない。

・テーブル・ファイル一覧の作成
 エンティティ・テーブルの構成が決まったところで、
 テーブル・ファイル一覧に情報をまとめる。
 <テーブル・ファイル一覧を作成する目的>
  ・データ設計対象の抜け漏れがないか確認しやすくなる。
  ・テーブルを横串で管理しやすくなり、重複データの有無の確認等に活用できる。

・CRUD表の作成
 エンティティ一覧またはテーブル・ファイル一覧に対して、
 登録(C)、参照(R)、更新(U)、削除(D)を行う機能のマトリックスを作成する。

 <CRUD表作成の目的>
  ・CRUD表にまとめることで、機能横断的にデータの取得更新が
   設計できているか確認しやすくなる。
   例えば、商品データを取得する機能が複数あったとして、
   どの機能も取得元の同一のテーブルからデータを取得しているか確認する等。
   
  ・『テーブルに項目追加を行う際、影響プログラムの抽出を迅速に行う事』など、
   後工程で追加対応が必要になった際に、影響調査を効率良く、漏れなく進める
   ために役立つ。
   システムリリース後の保守開発時に、素早く適切な対応をするためにも重要な
   成果物となる。

         <データ設計作業イメージ>
データ設計

データ設計 
9  ロジック設計  ・前提の設計資料の確認
 該当機能の入出力(画面、帳票、インタフェース)設計、
 ジョブ設計、データ設計が揃っていることを確認する。
 これらの情報が不十分の場合、ロジック設計において手戻りが
 発生する可能性が高くなる。
 ・画面、帳票の項目が決定している。
 ・インタフェースで取得する項目が決定している。
 ・システムが出力するテーブルやファイルの項目が決定している。
 ・ジョブのフロー(前後関係)が決定している。

・ロジック設計
 処理の流れ、内容(入力・編集・出力)を設計する。
 ・処理の複雑性を考慮した設計
   ・機能の分割で整理したシステムフローを基本フローとして定義。
    機能と入力・出力情報を結び付け、入力→出力の各項目をつなぎ合わせる。
   ・入力・出力データが、複数テーブル(ファイル)に格納されるケースを考慮する。
   ・入力情報のパターンにより処理が異なるケースを考慮する。
   ・入力情報のパターンに対して状態により処理が異なるケースを考慮する。
 
 ・例外(業務的/システム的に起こる例外状況)を考慮した設計
  ・業務的な例外:業務ユーザのデータ入力誤りなど
  ・システム的な例外 予期しない障害(システムリソース不足や故障)
   →例外発生時の動作(ロールバック、継続 )を設計する。
 
 ・共通化、統合を検討
  ・入力値や利用者権限が違うだけで、処理の流れに変わりがないものは
   共通化を検討する。

  ・無理な共通化によってロジックが複雑・難解にならないようにする。
   システムの変更のしやすさを担保するため。
   <共通化がシステムメンテナンス性を低下させる例>
   ・ロジック内部の条件分岐が多い、判断条件が多い
   ・全く関連の無い判断条件が共存している
   (業務Lv1、Lv2異なるがLv3で仕様が似ているため共通化している)

・データ設計、画面設計、帳票設計、インタフェース設計、ジョブ設計の更新
 ロジック設計で発生したデータ、入出力、ジョブの設計の変更を反映する。
 更新する際は、要件定義や共通設計/非機能設計の内容を再確認し、
 矛盾が起きないこと/新たな要件(変更要件)になっていないか注意する。h

フリー
フォーマット 
10  全体テスト計画  テスト目的や範囲と基準、テスト工程全体の構成、体制・スケジュールを定義する。
テスト工程、目的と範囲を設定は、ソフトウェア開発のV字モデルを利用して整理する。
        <ソフトウェア開発のV字モデル>

V字モデル
        <テスト工程と業務の関係>(クリックすると拡大)
テスト工程と業務の関係
・テスト工程・目的と範囲の設定
 単体テスト・結合テスト・総合テスト・UATのそれぞれのテスト工程における
 テストスコープを設定する。
 それぞれのテスト工程におけるテスト観点を決定し、一覧を作成する。
 <テスト検証範囲のポイント> 詳細は「テスト検証範囲と確認観点」参照
  ・単体テスト
   ・ソース単位で異常終了しないことを確認する。
   ・性能劣化を埋め込んでいないことを確認する。
    (後続工程でのパフォーマンスチューニング作業をできる限り減らす)
  
  ・結合テスト
   ・システムとして起こりうる全ての動作を確認する
   ・外部システムとの接続が可能なこと(総合テストの準備)
  
  ・総合テスト
   ・ユーザ業務/システム運用業務を適正に実施できることを確認する
    機能・非機能の双方を含む。
    自システムに限らず、接続先の外部システムを含む
   ・想定外の状況下での動作を確認する
  
  ・UAT
   ・ユーザによる受入/検収作業
   ・ユーザによる追加要望の有無の確認
   
  単体・結合・総合テストで実施するテスト範囲は、文章による説明だけでなく、
  システム概要図とシステム構成図を用いて図で表現する。
  (設計者や関連システム担当者にテスト範囲が誤って伝わることを防ぐため)
  
 <テストの観点(概要)>
  下記のテスト観点に関する具体的なテストケースを各工程にて設定する。
  テスト計画ではその観点の洗い出しと、それぞれの観点のテストの
  実施要否を確認する。

  ・機能(正常/例外/エラー)
  ・非機能(ユーザビリティ/性能・耐久/運用・保守/可用性/セキュリティ)

・テスト自動化の検討
・テスト自動化の検討
 テストの自動化は作業効率の向上とコスト削減、正確性の担保を目的としている。
 自動化の実現方法と対象スコープを検討する。
 ・テスト自動化の手法(ツール)の確認
  自動化できる機能とその準備のために必要な作業コスト、ライセンス料金
  の有無を確認する。
  ・SeleniumやAppium等のOSSや、QTP(有償)等の自動化ツールの利用を
   検討する。
  ・カスタムツールの作成を検討する。
  
 ・自動化対象のテストスコープの検討
  単体テスト/結合テスト/総合テストのうちどのテストを自動化するかを
  検討する。後述のテスト自動化の効果検証を踏まえて、スコープを決定する。
  
  ・テストの自動化による効果の確認
   ・テスト範囲を検討する。
    自動化の効果(効率化・工数削減・正確性の担保)が得られるテストが何かを
    割り出す。技術的に自動化が可能であることと、メリットが得られるかは
    別である。
    <テスト自動化の効果を出しやすいケースの例>
     ・繰り返し実行を行い、仕様が変わりにくい部分のテスト
      仕様変更が発生するとテストスクリプトの変更作業が必要になるため
      コストメリットが出にくい。
     ・リグレッションテスト、スモークテスト
      例えば、画面項目の仕様変更が発生した際に、画面遷移や基本的な
      データ登録機能などに影響が出ていないか都度確認しなければいけない。
      このようなルーチン化したテストはテスト自動化ツールによる効率化の
      メリットが出やすい。
     ・数百人の同時接続を想定した性能テスト
      数百人分の担当者を同時にアサインすることは現実的に難しいことが
      多く、テスト自動実行が有効。
     ・数週間連続稼動させる耐久テスト
      連続稼働テストは人件費の増加や担当者のアサイン可否を踏まえると
      テスト自動実行が有効。
      
     ・テスト自動化によるデメリット
      テストの自動化は効果が見込める一方で、デメリットもある。
      デメリットを洗い出し、デメリットを差し引きしても自動化の効果が
      得られるのかを検証する。
      <自動化によるデメリットの例>
       ・自動テストスクリプトの設計、実装、セットアップが追加になる。
        テスト準備の工数が2割程度は増加することをプロジェクト計画段階
        で織り込む必要がある。
       ・自動テストスクリプトの構成管理が追加になる(管理作業の増加/複雑化)
    
   ・自動化する作業要素が何かを検討する。
    メリット/デメリットを踏まえて、何を自動化するかを検討する。
    この際には、対象とするテストと、各テストの中のどの作業を自動化するか、
    という二段階で検討する。テスト実行で効果が得られなくても、テストの
    検証や結果報告であれば自動化の効果が出る可能性もある。
     <テストに関する作業>
      ・テスト実行(操作、駆動)
      ・テスト結果検証(判定)
      ・テスト結果報告
      
   ・テスト自動化スコープの決定
    上記の費用対効果と実現性の検討を踏まえて、テストを自動化する
    対象範囲を決定する。
  

・テストで使用する環境の定義
 テストで使用するシステム環境やデータを定義する。
 関連システムがテストに参加する場合は、関連システムの環境も確認する。
 ・ハードウェア/サーバの構成や配置、スペックを把握する。
  ・各工程において使用するシステム環境を整理する
  ・本番環境との差異とテスト結果への影響を把握(想定)する
  ・環境準備方法(リリース・移行のテスト/リハーサルとの関係)を確認する
  ・テストに先だって必要な環境構築作業
   (関連システムとの調整や担当者のアサイン)

  ・テストに使用するデータの要件(本番データの利用有無、
   テスト用データ作成のポイント)

  ・テストツールの利用有無
  
・検証を行う上での制限や仮定事項を明確にする
 <制限・仮定の例>
  ・環境の性能・容量違い
   本番環境とテスト環境のハードウェア処理性能・容量比に合わせたデータ量、
   処理件数を限定して実施。
  ・接続先システムのデータ、システム環境を利用できない
    インタフェースデータの本番データを提供してもらえない
    提供元システムで本番データ提供が不可。
    その為、本番のデータ分類・分布、パターン確認が不可。
    →代替案としてテスト環境において想定データを接続先システム側に
      作成してもらう

  ・接続先システムのシステム環境を利用できない
    本番環境で提供されるAPIが利用できない。
    →テスト用ドライバを自システムで用意して代替する。 
  ・他の開発プロジェクトと時期が重なり、最新版のモジュールの結合ができない
   →テスト用スタブ、ドライバを用意して代替する
   
・各テストの実施体制とスケジュールの決定
 ・体制
  役割分担と作業体制を明確にする
  ・テスト設計(テストケース設計/テストツール設計/テストデータ設計)
  ・準備(テストデータ/テスト環境準備/テストツール開発)
  ・実行(テストケース実行/検証、不具合対応/構成管理)
  ・バグ解消(テスト実行者と分けるか否か)
  ・テスト管理(テストケース/バグ/進捗、報告)”

・スケジュール
 テストスケジュールを作成する。
  ・各テストの実施時期
  ・各テストの計画、設計、準備時期(テスト実行より先だって実施)
  ・関連案件スケジュールとの相互影響の確認
  ・テスト環境利用スケジュール

・テスト管理の準備
 テストを運営するにあたり、管理対象とその運営方法や指針を定義する。
 ・テストケース管理
  ・ケース設定、ケース密度の方針。
  ・規模あたりのテスト項目件数、ケースの質的内容(正常、異常、限界)割合等
 ・バグ管理
  ・テスト実行によって発生したバグの検出数、規模あたりの
   不良摘出件数(バグ密度)の管理方針。

   バグ対応状況の管理方法、摘出バグの分類と分析方法 等
 ・テスト進捗管理
  ・テスト進捗の方針。テストケース消化率での進捗把握 等
 ・コミュニケーション管理
  ・テスト状況を確認するための定例会議の開催、QAや課題の共有方法 等
 ・構成管理
  テスト実施期間中の構成管理方法
  (不具合修正タイミングと環境への反映方法 など)

   <管理対象>
   ・ソースコード
   ・データベース定義
   ・マスターデータ
   ・設計文書
   
 ・成果物定義
  計画、設計、準備、テスト(実施後)の各成果物を定義する。
  
 ・テスト開始/終了判断基準
  各テスト(又は工程)の開始と終了基準の方針を定義する。
  テスト管理項目として設定した内容と整合性をとる。
  特に数値で管理するものは評価基準を明確にする。
  <開始基準>
   ・前工程の完了状況:タスクの完了状況、クリティカルな残課題の有無
   ・テスト設計状況 :テスト項目件数、密度の分析
   ・テスト準備状況 :環境、データの準備状況
  <終了基準>
   ・テスト実施状況 :テストケース消化率
   ・不具合発生状況 :発生(摘出件数、テスト項目数比)分析
   ・不具合修正状況  :積み残しバグの取り扱い
                 (バグの影響度定義と判断基準)

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

テスト観点テスト検証範囲と確認観点
 
11  システムリリース計画  システムリリース、移行(データ、システムや設備)の概要を整理し、
それに伴う準備/テストの進め方を計画する。
(業務移行(新業務フローに関するユーザへのトレーニングを伴う)は含まない)

・リリース方針の整理
 ・リリース資源の整理
  要件/仕様(設計書)からリリース対象の資源を特定する。
  ・要件/設計書とリリース資源を一致させる(詳細は後工程で最終化する)
  ・廃止(削除)する資源を特定する。
  ・対象資源: プログラム/定義ファイル/データ/ハードウェア 等
  
 ・リリースの作業規模と影響の整理
  リリース資源から作業規模や業務影響を洗い出す。
  ・リリース資源の作業規模(作業の複雑度、移行量 等)、作業時間の概算
    - 複雑度:過去の類似案件の有無を確認(参考にする)
         新規システムリリースの場合は、リリース時のシステム停止要否、
         ツール開発の要否、バッチ運用/データ状態の考慮 など
  ・リリース中、または失敗した際の業務(ユーザ業務、システム運用)や
   他システムへの影響
  ・既存システム環境/業務運用での業務継続可否(限界時期)
 
・リリース計画(概要)
 業務影響リスクを軽減するリリース方法(新システム/業務への切
 替方法と期間、
実施順序 等)を決定する。
 リリース資源単位での検討後に、システム全体で調整する。

  <切替方法>
   ・一括リリース:システム(機能)を一度で切り替える
   ・段階リリース:サブシステム、データ単位で除々に切り替える
   ・並行運用  :旧システムと新システムを一定期間は両方を稼動する
  <期間>
   ・段階移行や並行運用の概算スケジュール
  <実施タスクと順序>
   ・リリース、移行(データ、システム)の実施内容と順序の概要を検討する。
    <実施内容の例>
     - データ移行の場合
      - マスターデータ投入後に、過去取引にかかわる
       トランザクションデータ投入の順で実施
      - マスターデータは名寄せを施す
      - 過去の取引データはマスタデータの名寄せに
       合わせて補正(クレンジング)を施す

 -