Transcript 第5章 システム設計書の作成 5-3

5章
5-6, 5-7, 5-8, 5-9は，uploadなし
5－１ システム設計書の
作成手順と構成
• システム設計書の作成段階で、システム化計
画で承認された要件定義の結果を、システム
開発できる段階まで詳細化する。
システム設計フェーズの考え方
• ユーザとのインターフェースや外部システムと
の関連を設計するシステム設計（「基本設計」
または「外部設計」ともいい、ユーザからの視
点で設計する）
• システム設計の仕様をどのような仕組みで実
現するのかを設計する詳細設計（「内部設
計」ともいい、プログラム製作者の視点で設
計する）
システム設計書の作成手順と構成
• 財団法人日本情報処理開発協会・中央情報
教育研究所が公表している「情報処理技術
者スキル標準」
• 情報システム開発プロジェクトにおけるSEに
とっての基本的な業務領域であるシステム開
発作業に関して「情報システム開発業務のプ
ロセス」が示されている。
第5章 システム設計書の作成
5-2 システム方式の選択
株式会社ディー・アート
上野淳三・広田直俊・白井伸児[著]
「システム設計の考え方」
H102124 宮澤新一
2005/11/13
タイトル
5
システム方式の設計
• システム方式の選択は、システム化要件定
義の段階で行われていることもあるが、シス
テム設計時に改めて見直しを行い、システム
設計書にハードウェアの構成、ネットワーク方
式、使用ソフトウェアの構成などを記述する。
2005/11/13
5-2 システム方式の選択
6
システム方式検討時の考慮点
• システム方式を検討するときには、以下のよ
うなことを決めていく。
– データ処理は集中処理か分散処理か
– 分散処理の形態としてクライアント/サーバシステ
ムで構築するのか
– ネットワークはLANかインターネットか
– データ管理などのミドルウェアは何か
– ソフトウェアパッケージを利用するのか
2005/11/13
5-2 システム方式の選択
7
システム方式検討時の考慮点
• 複数のシステム方式案がある場合は、コスト、
パフォーマンス、信頼性などのシステム化要
件でさらに詳細に詰めていく。
• 技術動向などの将来性も考慮に入れる。
2005/11/13
5-2 システム方式の選択
8
システム方式検討時の考慮点
2005/11/13
5-2 システム方式の選択
9
システム構成図の作成
• 選択したシステム方式のハードウェア、ネット
ワーク、ソフトウェアなどを整理してシステム
構成図を作成する。
2005/11/13
5-2 システム方式の選択
10
インターネットを利用したWeb型システムの構成図
2005/11/13
5-2 システム方式の選択
11
第5章 システム設計書の作成
5-3 業務仕様と業務処理フローの設計
株式会社ディー・アート
上野淳三・広田直俊・白井伸児[著]
「システム設計の考え方」
H102124 宮澤新一
2005/11/13
タイトル
12
業務仕様の整理
• システム設計書では、まず最初に新システム
のシステム化目的など、システム化要件定義
の内容を業務仕様として整理する。
2005/11/13
5-3 業務仕様と業務処理フローの
設計
13
業務仕様の整理
<業務仕様の内容>
1．システム化の目的
2．システム化の背景
3．システム化業務の概要
業務の位置づけ
概念図(組織と情報の流れ)
4．システムの制限事項
2005/11/13
5-3 業務仕様と業務処理フローの
設計
14
システム化の目的
• システムの作成に当たって、まずその目的を
明確にすることが必要。
• たとえば、目的が省力化にあるのか、管理レ
ベルの強化にあるのかなどによって、力点が
違い、システム設計の仕方も違ってくる。
2005/11/13
5-3 業務仕様と業務処理フローの
設計
15
システム化の目的
• 記述の方法はなるべく体系的に行う。
2005/11/13
5-3 業務仕様と業務処理フローの
設計
16
システム化の背景
• システムの設計に当たりそのシステム全体が
ユーザにうまく受け入れられるかを十分検討
する必要がある。
• 現場でのニーズ、運用担当者レベル、その他
そのシステムを導入する経緯や背景に応じて
記述する。
2005/11/13
5-3 業務仕様と業務処理フローの
設計
17
システム化業務の概要
• システム化する業務の範囲(今回導入するシ
ステム化部分)が、将来構想をも踏まえ、どの
ような位置づけにあるのかをシステム全体と
の対比で記述する。
2005/11/13
5-3 業務仕様と業務処理フローの
設計
18
システム化業務の概要
2005/11/13
5-3 業務仕様と業務処理フローの
設計
19
システム化業務の概要
• 組織と情報の流れがわかるシステム全体のイメージ
をシステム概念図などで示す。
2005/11/13
5-3 業務仕様と業務処理フローの
設計
20
システムの制限事項
• システムを開発するとき、実際にはユーザ側
と開発側の双方に技術的および経済的な制
約条件が存在する。
• ユーザとの合意のもとに、「制限事項」として
記述する。次項では、特にユーザとの確認で
重要な項目を列挙した。
2005/11/13
5-3 業務仕様と業務処理フローの
設計
21
システム化の制限事項
<制約事項の項目>
– 機能面・・・機能面での制約条件、要望事項で絞込めなかっ
た機能など
– 能力面・・・端末応答時間、データ処理時間など
– 拡張性・・・業務の拡張、対象事業所、端末数の追加範囲な
ど
– 互換性・・・旧システムからの移行処理、関連システムとのイ
ンターフェースなど
– 機密性・・・機密性が重要な意味を持つ場合、システムのセ
キュリティ機能の範囲・制限など
– 信頼性・・・システムの信頼性が重視される場合、障害児の
影響度など
– 運用面・・・システムのサービス時間帯、夜間バッチ処理など
2005/11/13
5-3 業務仕様と業務処理フローの
設計
22
業務処理フローの設計
• システム化要求定義で要求されている新シス
テムに求められる業務仕様を、どのようにコ
ンピュータ処理していくかを業務フロー設計で
行う。
2005/11/13
5-3 業務仕様と業務処理フローの
設計
23
業務処理フローの設計
• 下の図は処理の流れを、どのデータに対し(入力)、
どのような処理を行い(処理)、結果として何を得る
か(出力)という、入力・処理・出力の関係を表わした
処理フローである。
2005/11/13
5-3 業務仕様と業務処理フローの
設計
24
業務処理フローの設計
• 現在の主な設計手法としては、この業務の流
れを中心に考える方法から、データの流れや
変化を基本にし、それに内容を対応させてい
くDFD(データフローダイアグラム)がある。
2005/11/13
5-3 業務仕様と業務処理フローの
設計
25
データの流れでシステムを表現するDFD
• DFDはシステム対象領域の業務をデータの流れと
処理のプロセスで把握し、わかりやすく図で表現す
る方法である。
2005/11/13
5-3 業務仕様と業務処理フローの
設計
26
第5章 システム設計書の作成
5-4 サブシステムの分割
株式会社ディー・アート
上野淳三・広田直俊・白井伸児[著]
「システム設計の考え方」
H102124 宮澤新一
2005/11/13
タイトル
27
サブシステムの分割
• 特別に小規模なシステムでない限り、ひとつ
のシステムをいくつかの機能的に異なる部分
に分割し、サブシステムの構造を持たせる。
• どのように機能をまとめ、どうサブシステムを
分割していくかは、システム設計の要とも言
える大切な作業である。
2005/11/13
5-4 サブシステムの分割
28
サブシステム分割の仕方
• システム化要求定義をもとに新システムの業
務処理フロー(DFD)を作成した後、関連性が
高い機能をまとめたものがサブシステムであ
る。
2005/11/13
5-4 サブシステムの分割
29
サブシステム分割の仕方
• データ中心のDFDの場合は、新システムの
組織やリソース、処理サイクルといった具体
的な物理的要件を加味する。
• その上で、システムの各機能を整理、分類し、
関連性の高いものごとにまとめたものがサブ
システムとなる。
2005/11/13
5-4 サブシステムの分割
30
機能をまとめる方法
• 新システムの全体構想を描きながら、現状の
業務の流れなども考慮し、次項の方法で機能
をまとめ、サブシステムとして分割する。
2005/11/13
5-4 サブシステムの分割
31
機能をまとめる方法
• 独立性の高い業務(機能)ごとに分割する
• 処理サイクルや時間的関連によって分割す
る
• 運用単位によって分割する
2005/11/13
5-4 サブシステムの分割
32
機能をまとめる方法
• サブシステム構成の設計では、それぞれの
サブシステム間の関わりが弱くなるように、で
きるだけ独立性の高い分割を行う。
2005/11/13
5-4 サブシステムの分割
33
サブシステム構成図
2005/11/13
5-4 サブシステムの分割
34
処理構造の設計
• サブシステムの設計は、詳細設計の段階でさ
らに機能ごとにプログラム単位に細分化され
ていく。
• システムのこのような階層化や細分化を行う
ことは、システム開発を進める上で、次項か
ら示すような効果がある。
2005/11/13
5-4 サブシステムの分割
35
処理構造の設計
-階層化・細分化の効果(1)• それぞれのまとまった機能をひとつの単位と
して分割することによりプログラムの複雑さが
軽減され、結果として品質向上につながる。
• システム変更時、サブシステムにまとめておく
ことにより、一部のサブシステムで修正変更
を行っても、その影響をほかのサブシステム
に与えにくい。
2005/11/13
5-4 サブシステムの分割
36
処理構造の設計
-階層化・細分化の効果(2)-
• 並行してプログラム製作作業が可能となり、
システム開発期間の短縮が図れる。
• あるサブシステムやプログラム単位に、同一
既存ソフトウェアの再利用がしやすい。
2005/11/13
5-4 サブシステムの分割
37
５‐５ 入出力情報と
コードの設計
Ｈ１０２０４２ 小林弘晃
ユーザインタフェース設計
• 入出力画面、帳票はユーザから見た使いや
すさに最も関係する
• 設計する際には様々な操作ケースを考慮す
る必要がある
入力情報の設計
• 入力設計での注意点
– 不必要な情報は除外
– 類似情報はできる限り統合する
入力情報の選定、分類、内容設定
入出力情報となる画面設計
• ＧＵＩ（Graphical User Interface）設計ツールを用いる
入力チェック
• チェック方式
– ニューメリックチェック
– リミットチェック（限界検査）
– レンジチェック（範囲検査）
– シーケンスチェック
– 重複チェック
– 照合チェック
– チェックデジットチェック
出力情報の設計
• 出力設計での注意点
– 関係者が真に必要とする情報を網羅する
– 情報をタイムリーに効率的に取り出せる形にする
出力情報の選定、分類、内容設定
• 最終的に出力すべき情報を選定
• 機能、提供先、サイクル、出力機器などを基
準に分類
出力情報のレイアウト
コード設計
• コードとは
– データ項目を使用目的に応じて識別するために数字、文
字などを用いて表現したもの
• コード化の種類
コード表
• システムにおけるコードは、開発後の運用に
おいて常に重要である
↓
コード表に要領よくまとめる
コード表の書き方
５-１０ ドキュメンテーション技術
H102002
安島澄人
ドキュメントの重要性
• 情報システムの開発においてドキュメントは
非常に大切なものである。
• 目に見えない完成物のソフトウェアをユーザ
へ納入するとき、ソフトウェアを含め、システ
ム全体を説明したシステム設計書などをド
キュメントとした成果物がきわめて重要である。
ドキュメンテーションの標準化
• 例外もあるが、通常はシステム開発過程での
開発メンバー間の分業のためにも、しっかりと
したシステムの定義書である「システム設計
書」のドキュメンテーション作業（文章、仕様
書の作成）が必要不可欠である。
• 「システム設計書」の場合、世界的な標準は
なく、各会社が独自に標準化している。
ドキュメンテーションの違い
• システム設計書などのドキュメンテーションの
方法
（１）プロジェクトチームによっての違い
（２）業務系か制御系の違い
（３）ハードウェアのシステム方式が、ホストコン
ピュータか、クライアント/サーバ型かの違い
どれもドキュメントの重要性は同じ
ドキュメンテーションの意義
• システム設計書などは、ユーザ要求仕様の
概要、システムの構成、機能などを洩れなく
まとめ、検査・引渡しなどのときの承認申請
書となる。
• システム開発メンバー間の設計レベルを合わ
せ、効果的にシステム開発を進められる。
ドキュメンテーションの意義（２）
• システム納入後のバグによる不具合の対応
など、システム運用にも必要不可欠。
• システム運用後の機能追加など、システム保
守にも重要。
• 技術ノウハウの蓄積、技術移転にも役立つ。
５－１１ システム設計書の
構成イメージ例
• システム設計では、要件定義の「何を」システ
ム化するのかの概要を含め、「どうやって」実
現するのかシステムの機能説明を中心にシ
ステム全体の具体的イメージとしてドキュメン
トをまとめる。
システム設計書の構成
• システムの各設計資料を、システム目的など
のユーザの要件定義の概要、システムの全
体構成、各機能・仕様、制約事項なども洩れ
なく含め、システム全体をシステム設計書の
ドキュメント構成としてまとめる。
SEにとっての簡単な
コンサルティング技法
• SEにとってのコンサルティング技法とは、ユーザの
最も「関心」の持っていることを解決し、目標に導く
ための思考・行動のことである。
簡単なコンサルティング手順と
殺し文句