ソフトウェア 設計

ソフトウェア設計後に、チェックしなければいけないことを確認できます。

images/cards/software-development-g4602773a5_640.webp

目次

0. Introduction

  • 対象となる読者
    • ソフトウェア設計を任されている方
  • 本記事の価値
    • ソフトウェア設計後に、チェックしなければいけないことを確認できます。
  • 前提
    • 特になし

1. ソフトウェア設計の種類

  • 外部設計(基本設計、概略設計)

    • 要件定義で決定した機能や性能、制約条件などを基にしてシステムの基本となる設計を行います。操作画面や操作方法、データ出力など、ユーザーから見えるインターフェース部分の仕様を決定したり、セキュリティや運用規定、システム開発のスケジュールや費用などを設計したりと、基本的にユーザーに向けた仕様を設計するのが外部設計です。
  • 内部設計

    • 内部設計とは、外部設計をもとにして、システム内部の動作や機能といったユーザーから見えにくい部分の設計を行うことです。詳細設計とも言います。内部設計は、その後の実際のプログラミングの工程に入れるよう、プログラマが何をどのように作ればいいかを定めた指示書といったイメージです。内部設計がしっかり出来ていないと、プログラミングの生産性が落ちてしまうことにつながります。

2. 外部設計書に記載する内容

  • 業務フロー
  • 機能一覧表
  • ネットワーク構成図
  • テーブル定義
  • ER 図
  • 画面レイアウト
  • 帳票レイアウト

3. 内部設計書に記載する内容

  • 機能仕様書
  • データフロー図
  • データベース物理設計書
  • クラス図
  • モジュール構造図
  • アクティビティ図
  • シーケンス図
  • IPO

4. 設計書作成後のチェックリスト

1. 外部設計書

  • すべての設計項目は、要件にひもづけれらているか
  • 設計項目は、要件を次元するために十分か
  • 未定義の要件に対応する機能部分は明確にされているか
  • システム構成がすべて決定し、妥当か
  • 各構成要素に割り当てた機能にモレや無駄がなく、かつ妥当か
  • ハードウェアとソフトウェアの切り分けは明確になっているか
  • ハードウェアのスペックは機能・性能を実現するのに十分か
  • ネットワーク機器のスペックは機能・性能を実現するのに十分か
  • ソフトウェアが実現する機能は十分で実現可能か
  • 使用するソフトウェア、ハードウェア等に実績があるか
  • 外部接続先とのインターフェースについて相手方と合意したか
  • 画面等ユーザインターフェースについてオペレータと合意したか
  • 構成要素間のインターフェースは正確で妥当か
  • 機能の局所化、共通化は妥当か
  • ソフトウェアの動作シナリオ、動作シーケンスが明確かつ妥当か
  • ソフトウェアの状態遷移が明確かつ妥当か
  • 並行処理、異常処理、性能に考慮して振る舞いを設計しているか
  • 異常状態やエラーを漏れなく整理してコードを割り振っているか
  • 画面出力するメッセージをすべて定義してコードを割り振っているか
  • データベースおよびファイル(内部処理用を除く)を定義したか
  • データベースの正規化は妥当か
  • 外部とのデータ送受信に関するメッセージ一覧を作成したか
  • 要件や設計に変更があった時の影響範囲の特定は容易か
  • 設計を内部設計が可能な単位に分割できるか
  • 設計から統合テストのテストケース、判断基準を作成可能か
  • 未決事項、要検討が明確で、その確定は確実であるか

2. 内部設計書

  • すべての設計項目は、要件及び外部設計に紐づけられかつ十分か
  • 必要なモジュール・プログラムをすべて識別して定義しているか
  • モジュール・プログラムの大きさは適切か
  • モジュール・プログラムごとの処理内容が明確で妥当か
  • モジュール・プログラムの共通化、構造化は明確で適切か
  • モジュール・プログラムのカプセル化や結合度は妥当か
  • モジュール・プルグラムは再利用性・保守性を考慮して設計したか
  • モジュール・プログラム間のインターフェースをすべて設計したか
  • モジュール・プログラム間でのやりとりするデータとどの制御を設計したか
  • すべての入出力情報のデータ構造、サイズ、初期値、意味は明確か
  • すべての変数の初期値と定数の値を定義したか
  • 処理ロジックを適度に分割し、第三者にもわかりやすくしたか
  • すべての条件分岐について「その他の場合」を定義したか
  • 条件分岐のネストは深すぎないか(三階層程度まで)
  • 例外処理エラー処理をすべて定義し、設計したか
  • 異常処理をすべて定義し、設計したか
  • プログラム内で使用する配列やマトリクスは妥当で効率的か
  • 設計内容から性能要件(速度・容量等)を満たすことを説明できるか
  • OS やライブラリが使用するメモリ量を見積もったか
  • 使用可能なメモリ容量の中で、動作可能な設計になっているか
  • 共通で使用するデータ領域を検討しメモリ容量を見積もったか
  • ハードウェア機能の制御方法、タイミング、設定値を設計したか
  • すべての入出力・イベントとそれに基づく振る舞いが明確か
  • OS システムコール、ライブラリ関数の機能を設計したか
  • 割り込み、排他制御、多重起動、機能完連携の対策を考慮したか
  • 排他的処理が必要な共通データの Lock/Unlock のタイミングは明確か
  • 設計から統合テスト・単体テストのテストケース、判断基準を作成可能か
  • 未決事項、要検討が明確で、その確定は確実であるか

参考文献

  • 「なぜ、システム開発は必ずモメるのか?49 のトラブルから学ぶプロジェクト管理術」 細川義洋著,日本実業出版社
  • 「実践的ソフトウェア工学 第 2 版」, 浅井治著, 近代科学社

関連記事