システム開発の流れメモ

日本語名	略名表示	英名	備考
企画	SP	System Planning
要求分析	SA	System Analize
要件定義	RD	Requirements Definition
基本設計	BD	Basic Design
基本設計	UI	User Interface
基本設計	SS	System Structure Design	構造設計
基本設計	FD	Function Design	機能設計
基本設計	DbD	Database Design	データベース設計
詳細設計	DD	Detail Design
詳細設計	PD	Program Design
詳細設計	PS	Program Structure Design
製造/単体	PG	ProGraming
製造/単体	UT	Unit Test	メソッド単位のテスト
製造/単体	FT	Function Test	機能試験/機能単位のテスト
結合テスト	IT	Integration Test	結合試験
総合テスト	ST	System Test
運用テスト	OT	Operation Test

1. 企画(SP)

   受託：超概算見積もり

   依頼が曖昧で超概算見積もりができない場合、要件分析フェーズを行う

2. 要件分析（SA）

   受託：コンサル業務

   その他：市場分析

   要件分析結果を顧客に送付し、了解を得られた後、企画に戻り超概算見積もりを行う

3. 要件定義（RD）

   受託：要求定義の請求

   • 要求定義(顧客側が提出するもの)

     • 利用者の希望
     • すでにあるものの詳細（リプレイスの場合）
     • 既存の問題点と改善要望（リプレイスの場合）

   • 要件定義（受託側が制作するもの）

     • システムの定義（言語）
     • インフラ構成
     • 通信の有無
     • システムを利用してできることの定義

4. 基本設計（BD・UI・SS・FDA・DbD）

   1. BD(Basic Design)

      基本設計という概念

      要求定義（要件定義）がしっかりしていないと破綻する

   2. SS(System Structure Design)

      構造設計→振る舞い図・構造図の作成
      要求定義を満たす構造、セキュリティ、工数（費用）に応じた構造図を作成する

      • 振る舞い図
        • アクティビティ図
        • シーケンス図
        • ユースケース図
      • 構造図
        • クラス図・パッケージ図
        • 状態遷移図
        • コンポジット構造図（インプット・アウトプット）
        • コンポーネント図
        • 配置図
        • CRUD図（DBアクセス）
      • コード定義

   3. UI(User Interface)

      画面設計・帳票設計

   4. FD(Function Design)

      • ビジネスロジック設計

        構造図を機能単位で記述したもの

      • バッチ設計

      • IF設計
        WEB-API連携などの定義

        • URI設計
        • レスポンス設計

   5. DbD(Database Design)

      • テーブル定義
      • 項目定義

5. 詳細設計（DD・PD・PS）

   1. DD(Detail Design)

      コーディング規約など

   2. PS(Program Structure Design)

      SS(System Structure Design)を実装可能なレベルに展開する。

      • インターフェース仕様書の作成

        ソースを直接記述して自動生成しても良い
        （JavaDocから）

        共通機能の設計の場合、必ず戻り値がNULLになるかならないかの記述を行うこと

      • インプット・アウトプット、データベースアクセスの項目マッピング

      • 処理フロー

      • 実装補助用のサードライブラリの指定（Lombok）等

   3. PD(Program Design)

      • 例外設計
      • ログ設計
      • その他、プログラム時におけるメモ

6. 製造（PG・UT・FT）

   1. PG(ProGraming)

      詳細設計から起こした実装で発生した不整合はフィードバックを必ず行う

      不整合の修正が発生した場合は、フェーズを遡って修正が必要となるため、PL（あるいはプログラミングリーダー）はフィードバックを視野に入れた工数を保持、あるいは作業の代替ができるようにすること

   2. UT(Unit Test)

      • 注意点

        不必要なテストパターンを作成しない。組み合わせの結果、処理が同一となるパターンは不要とする

        ただし、閾値テストにおいては同一であることを考慮せずテストを実施すること

   3. FT(Function Test)

      1. データフローテスト

         定義・使用・消滅の確認

      2. 制御フローテスト

         分岐、エラーハンドリング、メソッド連携の確認

7. 結合テスト（IT）

   結合の単位は全体とは限らない。スケジュールに応じて実施の精度を分離することができる。

   例）マスタに登録するテストに対し、そのマスタの値がフロントで表示されるなどといった組み合わせは総合テストとし、マスタの登録にフォーカスを当ててテストを行う。

   ただし、状態遷移において影響が及ぼす場合は、状態遷移の範囲に渡ってテストを実施すること。

   上記場合も、いずれは１つの機能単位に基づいた機能テストを必ず実施すること。

   • 状態遷移図に則った状態遷移の確認
   • 機能確認

8. 総合テスト（ST）

   1. セキュリティテスト

   2. 負荷テスト

      同時にスレッドを起動する、DB要件の最大値での実行など

   3. 性能テスト

      処理能力の確認を行う

   4. ロングランテスト

      例）Linuxなどでtmpディレクトリを利用しているなど、自動削除が発生するディレクトリに情報を保持している場合、一定期間で削除される可能性がある。そのような設計になっていないかの確認など。

      例）うるう年での動作

      例）昭和100年問題対応(2025年問題)

      例）容量圧迫の確認。ログや添付ファイルなどでサーバ上の容量が圧迫されるまでの期間とその対応についての考慮。

9. 運用テスト（OT）

   いわゆる受け入れテスト

全てを真面目にやったらとてつもない金額になるので、どこを抜くかを見極めなければならない