開発技術(2)
システム設計
システム設計の流れ

システム方針設計(外部設計)
●システム要件定義書をもとに
●ハードウェア、ソフトウェアなどのシステム構成を設計
●利用者が主体となってシステム開発部門と共同で実施
●システム方式設計書に整理する
システム構成の設計
システム要件定義書にあるすべてのシステム要件を以下の3つのサブシステムに分ける
▲ハードウェアで実現する内容(ハードウェア構成)
▲ソフトウェアで実現する内容(ソフトウェア構成)
▲利用者が手作業で実現する内容(手作業)
分割をもとに、サブシステムへの要求の実現、リスクなどを考慮した選択肢の提案、効率的な運用・保守などを検討・決定し、システムの構成を設計する
項目 | 説明 |
---|---|
ハードウェア方式 | 信頼性や性能要求に基づいて、ハードウェアの二重化、フォートトレラント設計、サーバやハードディスクなどの機能分散、負荷分散などを検討、ハードウェア構成を決定する |
ソフトウェア方式 | 総て新規で開発するか、市販のソフトウェアを利用するかなどを作業コストや作業効率の面からソフトウェアの開発方針を決定する。使用するミドルウェアの選択などを検討し、ソフトウェア構成を決定する |
アプリケーション方式 | 業務に応じた集中処理、分散処理の選択、Webシステム、クライアントサーバシステムなど、システムの処理方式を検討・決定する |
データベース方式 | システムで使用するデータベースの種類を検討・決定する |
システム結合テストの設計
システム方式設計書に整理された要件をすべて満たしているかを確認するため、システム結合テストの設計を行う。テストの範囲、テスト計画、テスト手順などを明確にして「システム結合テスト仕様書」に定義する
システム方式設計の評価
レビュー方式に基づき、設計したシステム方式がシステム要件に合致しているか、実現可能かなどをシステムの利用者・開発者が共同レビューを行う
利用者がシステムを利用時に参照する「利用者マニュアル」の暫定版も作成する
ソフトウェア要件定義
●システム方式設計書をもとに
●業務モデリング、ヒューマンインタフェースの設計など利用者から見える部分の
要件を定義する
●利用者が主体となってシステム開発部門と共同で実施
●ソフトウェア要件定義書に整理
業務モデリング
業務の詳細な流れを明確にする手法
●データモデリング :データ(情報)を中心に業務モデリングを行う
●プロセスモデリング:プロセス(処理)を中心に業務モデリングを行う
DFDやE-R図、UMLなどの手法を利用
ヒューマンインタフェースの設計
画面設計や帳票設計、コード設計を行う
ヒューマンインタフェース(ユーザインタフェース)
人間とコンピュータとの接点にあたる部分のこと
データベースの概念設計・倫理設計
システムで関係データベースを利用するために、対象データすべてを洗いだし、正規化を行い、関係データベースの表・表内の項目・データ型・主キーなどの複数の表の関連、制約を定義する
その他の要件
項目 | 説明 |
---|---|
ソフトウェア適格性要件 | ソフトウェアに求められる品質要件を明確化 |
セキュリティの実現方式の要件 | セキュリティに関する実現方式を明確化。アクセス制限など |
保守性の要件 | ソフトウェアを保守する際の求められる要件を明確化 |
ソフトウェア要件定義に用いられる手法
DFD
「データフロー」「プロセス」「ファイル」「外部」の4つの要素を使い、業務やシステムをモデリングし、業務の流れをデータの流れとして表現する手法のこと

DFDの表現例

E-R図
実体である「エンティティ(Entity)」と、関連を表す「リレーションシップ(Relationship)」を使い、データの関連を図で表現する手法。実体関連図などとも呼ばれる

詳細E-R図:データベースの論理設計を利用して、さらに詳しく表現したもの
アトリビュート:1つの組(行)を構成する項目やその集合のこと
ソフトウェア要件定義の評価
レビュー方式に基づき、決定したソフトウェアの要件がシステム方式に合致しているか、実現可能かなどをシステムの利用者・開発者が共同レビューを行う
評価する手段として「プロトタイプ(試作品)」を使った評価がある
プロトタイピング
早い段階からプロトタイプを作成して、りようしゃの確認を得ながら開発を進めること
ソフトウェア方針設計(内部設計)
●ソフトウェア要件定義書をもとに
●コンポーネントの設計やインタフェースの設計、データベースの物理設計などを
行う
●システム開発部門が実施
●ソフトウェア方針設計書に整理、利用者マニュアルを更新する
コンポーネントの設計
サブシステムをコンポーネントの単位まで分割する
各コンポーネントの機能仕様、コンポーネント間の入出力インタフェース(処理の手順や関係)を決定し、ソフトウェアの構造を明確にする

コンポーネント(ソフトウェアコンポーネント、プログラム)
ソフトウェアを構成する機能の単位のこと
コンポーネントの分割基準
処理パターンや処理タイミング、処理効率の違いや同時にデータが利用できるか、入出力装置の違いなどを考慮し、決定する
分かりやすさ、安全性、開発の生産性・運用性、保守性、再利用性、処理能力などを考慮
コンポーネントの部品化と再利用
再利用頻度の高いコンポーネントを部品化することで開発コストを大幅に削減可能
コンポーネントウェア
再利用できる部品を組み合わせて、ソフトウェアを動作させる技術の総称
ヒューマンインタフェースの詳細設計
ソフトウェア要件定義書をもとに操作性、応答性、視認性などを考慮し、画面や帳票などのヒューマンインタフェースを詳細に設計する
データベースの物理設計
表やログファイルのハードディスク上への配慮など、データベースの物理的な構造を設計する
ソフトウェア結合テストの設計
ソフトウェア方式設計書に整理された要件をすべて満たしているかを確認するため、ソフトウェア結合テストの設計を行う
テストの範囲、テスト計画、テスト方式を明確にし、「ソフトウェア結合テスト仕様書」にまとめる
ソフトウェア方式設計の評価
レビュー方式に基づき、設計したソフトウェア方式が、ソフトウェア要件に合致しているか、ソフトウェアコンポーネント内の一貫性が正しいかなどを複数の関係者が共同レビューを行う
ソフトウェア詳細設計(プログラム設計)
●ソフトウェア方式設計書をもとに
●モジュールの設計
●システム開発部門
●ソフトウェア詳細設計書に整理する
モジュールの設計
分割されたコンポーネントをモジュールの単位まで分割する
モジュールの分割手法、分割基準を踏まえて実施し、モジュールの処理内容や、分割したモジュール間の入出力インタフェースを明確にする

モジュール(ソフトウェアユニット、クラス)
コンポーネントを構成する最小単位のこと
モジュールの分割手法
データの流れに着目したモジュール分割
名称 | 説明 |
---|---|
STS分割 | 「源泉」「変換」「吸収」の3つのモジュールに分割する方法 ●源泉(Source):データの入力処理をする部分 ●変換(Transform):データの変更処理をする部分 ●吸収(Sink):データの出力処理をする部分 |
TR分割 | トランザクションの種類ごとにモジュールとして分割する方法 |
共通機能分割 | 共通する機能を取り出し、共通モジュールとして分割する方法 共通する機能を共通モジュールとして利用できるので効果的 |
データの構造に着目したモジュール分割
名称 | 説明 |
---|---|
ジャクソン法 | 入力データと出力データの構造を対比させ、主に出力データの構造をもとにモジュールを分割する方法 |
ワーエニ法 | 入力データが「いつ、どこで、何回」使われるかをもとにモジュールに分割する方法 |
モジュールの分割基準
モジュール同士の関係に着目し、基本的にモジュールの独立性を高くするように考慮する
モジュールの強度
モジュールの結合度
分割量
コンポーネントのステップ数(行数)を基準にして、モジュールを分割する方法のこと。モジュールが大きくなり過ぎないようにするため、ステップ数に制限を設ける。制限を超えた場合は、モジュールを再分割する
モジュールの部品化と再利用
再利用頻度の高いモジュールを部品化すると開発コストを大幅に削減可能
モジュール仕様書の作成
分割したモジュールについて、モジュールの処理内容や、モジュールのインタフェースなど各モジュール内における使用を記述した「モジュール仕様書」を作成する
流れ図、決定表、ジャクソン法、ワーニエ法、NSチャートなどの手法を用いて作成
ソフトウェアユニットテストの設計
分割したモジュール単位で、ソフトウェア詳細設計書に整理された要件をすべて満たしているかを確認するため、ソフトウェアユニットテストの設計を行う
テストの範囲、テスト計画、テスト方式を明確にし、「ソフトウェアユニットテスト仕様書」にまとめる
ソフトウェア詳細設計の評価
レビュー方式に基づき、設計したソフトウェアの詳細がソフトウェア方式に合致しているか、モジュール間の内部一貫性が正しいかなどを複数の開発者が共同レビューを行う
 

