第５章 システム設計所の作成 工学部第一部 経営工学科３年 ４４０４００８ 池辺 博昭 ５．１ システム設計書の作成手 順と構成 システム設計フェーズの考え方 システム設計フェーズ ・ システム設計 （「基本設計」、「外部設計」ともい う） ユーザとのインターフェースや外部システムとの 関連を設計する ・ 詳細設計 （「内部設計」ともいう） システム設計の仕様をどのような仕組みで実現する のか を設計する システム設計書の作成手順と構成 （１） 財団法人日本情報処理開発協会・中央情報教育研究所 が公表している「情報処理技術者スキル標準」 「情報システム開発業務のプロセス」 システム設計書の作成手順と構成 （２） 図1： 情報システム開発業務のプロセス システム設計書の作成手順と構成 （３） 図2： システム設計書の構成例 ５．２ システム方式の選択 システム方式の設計（１） システム方式検討時の考慮点 ・ データ処理は集中処理 or 分散処理 ・ 分散処理の形態としてクライアント/サーバ システムで構築するのか ・ ネットワークはLAN or インターネット ・ データ管理などのミドルウェアは何か ・ ソフトウェアパッケージを利用するのか システム方式の設計（２） システム方式検討時の考慮点 ● 複数のシステム方式がある場合 コスト、パフォーマンス、信頼性などのシステム化用 件で さらに詳細に詰めていく ※このとき技術動向などの将来性も考慮に入れる システム方式の設計（３） 図1： システム方式検討時の考慮点 システム方式の設計（４） システム構成図の作成 選択したシステム方式のハードウェア、ネットワー ク、 ソフトウェアなどを整理してシステム構成図を作成す る システム方式の設計（５） 図2： システム構成図（ハードウェア・ネットワーク構成）の例 ５．３ 業務使用と業務処理フ ローの設計 業務仕様の整理 システム設計書では、まず最初に新システ ムのシステム化目的など、システム化要件 定義の内容を業務仕様として整理する。 業務仕様の整理 <業務仕様の内容> 1．システム化の目的 2．システム化の背景 3．システム化業務の概要 ・業務の位置づけ ・概念図(組織と情報の流れ) 4．システムの制限事項 システム化の目的(1) システムの作成に当たって、まずその目的 を明確にすることが必要。 目的が省力化にあるのか、管理レベルの 強化にあるのかなどによって、システム設 計の仕方も異なる システム化の目的(2) システム化の背景 システムの設計に当たり、そのシステム全 体がユーザにうまく受け入れられるかを十 分検討する必要がある 現場でのニーズ、運用担当者レベル、その 他そのシステムを導入する経緯や背景に 応じて記述する システム化業務の概要(1) システム化する業務の範囲(今回導入する システム化部分)が、将来構想をも踏まえ、 どのような位置づけにあるのかをシステム 全体との対比で記述する。 システム化業務の概要(2) システム化業務の概要(3) 組織と情報の流れがわかるシステム全体 のイメージをシステム概念図などで示す。 システムの制限事項(1) システムを開発するとき、実際にはユーザ 側と開発側の双方に技術的および経済的 な制約条件が存在する ユーザとの合意のもとに、「制限事項」とし て記述する。次項では、特にユーザとの確 認で重要な項目を列挙した システムの制限事項(2) <制約事項の項目> 機能面・・・機能面での制約条件、要望事項で絞込め なかった機能など 能力面・・・端末応答時間、データ処理時間など 拡張性・・・業務の拡張、対象事業所、端末数の追加 範囲など 互換性・・・旧システムからの移行処理、関連システム とのインターフェースなど 機密性・・・機密性が重要な意味を持つ場合、システ ムのセキュリティ機能の範囲・制限など 信頼性・・・システムの信頼性が重視される場合、障 害児の影響度など 運用面・・・システムのサービス時間帯、夜間バッチ処 理など 業務処理フローの設計(１) システム化要求定義で要求されている新 システムに求められる業務仕様を、どのよ うにコンピュータ処理していくかを業務フ ロー設計で行う 次に示す図は、処理の流れを、どのデータ に対し(入力)、どのような処理を行い(処 理)、結果として何を得るか(出力)という、 入力・処理・出力の関係を表わした処理フ ローである 業務処理フローの設計(２) データの流れでシステムを表現する DFD DFDはシステム対象領域の業務をデータ の流れと処理のプロセスで把握し、わかり やすく図で表現する方法である。 ５．４ サブシステム分割 サブシステム分割の仕方 システム化要求定義をもとに新システムの業務 処理フロー(DFD)を作成した後、関連性が高い 機能をまとめたものがサブシステムである データ中心のDFDの場合は、新システムの組織 やリソース、処理サイクルといった具体的な物理 的要件を加味し、システムの各機能を整理、分 類し、関連性の高いものごとにまとめたものがサ ブシステムとなる 機能をまとめる方法（１） 新システムの全体構想を描きながら、現状 の業務の流れなども考慮し、次項の方法 で機能をまとめ、サブシステムとして分割 する １．独立性の高い業務(機能)ごとに分割する ２．処理サイクルや時間的関連によって分割 する ３．運用単位によって分割する 機能をまとめる方法（２） サブシステム構成の設計では、それぞれ のサブシステム間の関わりが弱くなるよう に、できるだけ独立性の高い分割を行う サブシステム構成図 処理構造の設計（１） サブシステムの設計は、詳細設計の段階 でさらに機能ごとにプログラム単位に細分 化されていく システムのこのような階層化や細分化を行 うことは、システム開発を進める上で、次 項から示すような効果がある 処理構造の設計（２） それぞれのまとまった機能をひとつの単位 として分割することによりプログラムの複 雑さが軽減され、結果として品質向上につ ながる システム変更時、サブシステムにまとめて おくことにより、一部のサブシステムで修正 変更を行っても、その影響をほかのサブシ ステムに与えにくい 処理構造の設計（３） 並行してプログラム製作作業が可能とな り、システム開発期間の短縮が図れる あるサブシステムやプログラム単位に、同 一既存ソフトウェアの再利用がしやすい ５．５ 入出力情報とコードの設 計 ユーザインタフェース設計 入出力画面、帳票はユーザから見た使い やすさに最も関係する 設計する際には様々な操作ケースを考慮 する必要がある 入力情報の設計 入力設計での注意点 不必要な情報は除外 類似情報はできる限り統合する 入力情報の選定、分類、内容設 定 入出力情報となる画面設計 ＧＵＩ（Graphical User Interface）設計ツールを用 いる 入力チェック チェック方式 ニューメリックチェック リミットチェック（限界検査） レンジチェック（範囲検査） シーケンスチェック 重複チェック 照合チェック チェックデジットチェック 出力情報の設計 出力設計での注意点 関係者が真に必要とする情報を網羅する 情報をタイムリーに効率的に取り出せる形に する 出力情報の選定、分類、内容設 定 最終的に出力すべき情報を選定 機能、提供先、サイクル、出力機器などを 基準に分類 出力情報のレイアウト コード設計 コードとは データ項目を使用目的に応じて識別するために数 字、文字などを用いて表現したもの コード化の種類 コード表 システムにおけるコードは、開発後の運用 において常に重要である コード表に要領よくまとめる コード表の書き方 ５．６ ファイル設計とデータベー ス設計 工学部第一部 経営工学科３年 ４４０４００８ 池辺 博昭 ファイル設計 ファイルとは・・・ ディスク等の記憶装置やメディアに 保存されたデータの集まり。 処理方式の選択（１） シーケンシャル処理 データを順番に処理 ランダム処理 任意データを取り出す 処理方式の選択（２） ファイル情報の定義 １、ファイルの抽出とファイル名称、用途の設 定 ２、各ファイルの使用サイクルと情報量など の算出 ３、各ファイルの項目と形式、桁数などの設 定 ４、格納媒体とファイル編成などの設定 データベースの設計 設計手順 １、現実のデータの洗い出し ２、収集したデータ項目の整理、分類 ３、データモデルへの落とし込み スキーマの概念（１） データ定義 実際のデータを格納するための「器」 を定義する スキーマ データ構造や核データの関連を記述し た設計情報 スキーマの概念（２） ３層スキーマモデル ５．７ セキュリティ設計 信頼性・安全性の設計 信頼性 ハードウェアやソフトウェア、データ、運用面など、 様々な対象に応じた要求が存在 安全性 障害や不正処理もしくは自然災害から、システム を防御・保護 これらをまとめて、コンピューターセキュリティ セキュリティの対策（１） 代表的な３種類の技術的対策 １．予防対策 ２．トラブルの早期発見、対応手段 ３．被害を最小限に食い止める対策 セキュリティの対策（２） システム利用者の管理 システム設計時に、アクセス権の許可の与 え方を決定 一般的には、ユーザＩＤとパスワード 社内ＬＡＮでは、ワンタイムパスワードや コールバックのような認証方式を利用 アクセス権の設定 アクセスコントロール 使用者にレベルに応じた使用権限を与える こと ログオン時のユーザＩＤを基にアクセス権 限テーブルを参照して、権限を制限する これらは、ＯＳやデータベースシステム（Ｄ ＢＭＳ）が実現する場合もある ５．８ システム移行設計 システム移行の設計 システム開発では、開発するソフトウェア に注目しがち 対象業務の継続運用には、移行の手段や データの変換、移行作業の時期的制約な ど、多くの問題がある そのために、システム設計時のデータ変換 インターフェースの設計が必要 システム移行手順（１） システムの移行 新システムの開発が完了し、検査後に ユーザに引き渡すこと 既存システム（旧システム）がある場合 移行するデータを選定し、移行作業を行 う システム移行手順（２） システム移行の方式（１） 新システムに障害があると、業務に大きな影響 を与える システム規模が大きい場合 旧システムを並行運用する期間を設け、順次移 行する 中小規模の場合 短期間で全社的に一斉移行 システム移行の方式（２） ５．９ システム運用設計と保守 システムの運用設計 システム開発段階から、システムの運用・保守を 意識 以下の事項を取り決める １．運用のサービス時間帯 ２．運用の基本サイクル ３．運用手順 ４．利用者管理 ５．運用支援ツール 事項の詳細（１） 運用サービス時間帯 オンライン運用のサービス曜日・時間帯、 夜間バッチ処理の曜日・時間帯など 運用基本サイクル 日次、週次、月次、期末など処理内容 に合わせた、システム全体の基本処理サ イクル 事項の詳細（２） 運用手順 システム立ち上げ、起動、停止、重要な データやファイルのバックアップ方法、障害 時のリカバー方法など 利用者管理 ユーザＩＤやパスワードの管理方法、ア クセス権の管理方法など 事項の詳細（３） 運用支援ツール データの初期化、クリーンアップ方法、 ジョブ管理、異常通知、ログ・統計情報など システム稼動後の保守（１） システム稼動後は、さまざまな運用環境変 化への対応や、ユーザからの新しい要求 発生などが生じ、迅速な対応が必要 新システムへの変更は不可能であるた め、機能の修正・変更改訂によって対応 システム稼動後の保守（２） システムの保守作業は ・修正作業 ・変更作業 ・改訂作業 ３種類存在する。 システム稼動後の保守（３） システム全体の安定稼動には、システム 保守業務が必要不可欠 定期的な保守から緊急時の保守に至るま で、さまざまなケースに対応できるように、 日頃から保守のルールを定め、それに 沿った体制作りが重要 システム稼動後の保守（４） 家造りとシステム開発（１） 家の入手には、自ら設計して造る「注文建 築」と出来上がっているものを購入する「建 売」がある システム開発にたとえると、 「注文建築」 新規のシステム開発 「建売」 パッケージのシステム購入 家造りとシステム開発（２） システム開発も家造りと同じ その家に住む人 ＝ 「システムの利用者」 がどんな家にするのか イメージを作ること ＝ 「システム設計」 が大切である ５．１０ ドキュメンテーション技 術 ドキュメントの重要性 情報システムの開発においてドキュメント は非常に大切なものである 目に見えない完成物のソフトウェアをユー ザへ納入するとき、ソフトウェアを含め、シ ステム全体を説明したシステム設計書など をドキュメントとした成果物がきわめて重要 である ドキュメンテーションの標準化 例外もあるが、通常はシステム開発過程 での開発メンバー間の分業のためにも、 しっかりとしたシステムの定義書である「シ ステム設計書」のドキュメンテーション作業 （文章、仕様書の作成）が必要不可欠 「システム設計書」の場合、世界的な標準 はなく、各会社が独自に標準化 ドキュメンテーションの違い システム設計書などのドキュメンテーションの方 法 （１）プロジェクトチームによっての違い （２）業務系か制御系の違い （３）ハードウェアのシステム方式が、ホストコン ピュータか、クライアント/サーバ型かの違い どれもドキュメントの重要性は同じ ドキュメンテーションの意義 システム設計書などは、ユーザ要求仕様 の概要、システムの構成、機能などを洩れ なくまとめ、検査・引渡しなどのときの承認 申請書となる システム開発メンバー間の設計レベルを 合わせ、効果的にシステム開発を進めら れる ドキュメンテーションの意義（２） システム納入後のバグによる不具合の対 応など、システム運用にも必要不可欠 システム運用後の機能追加など、システム 保守にも重要 技術ノウハウの蓄積、技術移転にも役立 つ ５．１１ システム設計書の構成 イメージ例 システム設計書の構成イメージ 例 システム設計では、要件定義の「何を」シ ステム化するのかの概要を含め、「どう やって」実現するのかシステムの機能説明 を中心にシステム全体の具体的イメージと してドキュメントをまとめる システム設計書の構成 システムの各設計資料を、システム目的な どのユーザの要件定義の概要、システム の全体構成、各機能・仕様、制約事項など も洩れなく含め、システム全体をシステム 設計書のドキュメント構成としてまとめる SEにとっての簡単なコンサルティン グ技法 SEにとってのコンサルティング技法とは、ユーザの 最も「関心」の持っていることを解決し、目標に導く ための思考・行動のことである 簡単なコンサルティング手順と 殺し文句
© Copyright 2024 ExpyDoc
