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にとってのコンサルティング技法とは、ユーザの 最も「関心」の持っていることを解決し、目標に導く ための思考・行動のことである。 簡単なコンサルティング手順と 殺し文句
© Copyright 2024 ExpyDoc
