Transcript 5章のまとめ
５章まとめ まとめ者 ４４０５０５６ 玉井英一 1 目次 • • • • • • • • • • • システム設計書の作成手順と構成 システム方式の選択 業務仕様と業務処理フローの設計 サブシステムの分割 入力情報とコードの設計 ファイル設計とデータベース セキュリティ設計 システム移行設計 システム運用と保守 ドキュメンテーション技術 システム設計書の構成イメージ例 ｐ３～７ ｐ８～１３ ｐ１４～２８ ｐ２９～３６ ｐ３７～５１ ｐ５２～６１ ｐ６２～６７ ｐ６８～７３ ｐ７４～８０ ｐ８１～８５ ｐ８６～８８ 2 5-1 システム設計書の作成手順と 構成 作成者 玉井英一 3 システム設計フェーズの考え方 • システム設計フェーズ ・ システム設計 （「基本設計」、「外部設計」とも） ユーザとのインターフェースや外部システムとの 関連を設計する ・ 詳細設計 （「内部設計」とも） システム設計の仕様をどのような仕組みで実現するのか 4 を設計する システム設計書の作成手順と構成 財団法人日本情報処理開発協会・中央情報教育研究所 が公表している「情報処理技術者スキル標準」 「情報システム開発業務のプロセス」 5 システム設計書の作成手順と構成 図1 情報システム開発業務のプロセス 6 システム設計書の作成手順と構成 図2 システム設計書の構成例 7 5-2 システム方式の選択 作成者 三堀 慎太朗 8 システム方式の設計（1） システム方式検討時の考慮点 データ処理は集中処理 or 分散処理 分散処理の形態としてクライアント/サーバ システムで構築するのか ネットワークはLAN or インターネット データ管理などのミドルウェアは何か ソフトウェアパッケージを利用するのか 9 システム方式の設計（2） システム方式検討時の考慮点 複数のシステム方式がある場合 コスト、パフォーマンス、信頼性などのシステム化要件 で，さらに詳細に詰めていく ※ このとき技術動向などの将来性も考慮に入れる 10 システム方式の設計（3） 表１ システム方式検討時の考慮点 11 システム方式の設計（3） システム構成図の作成 選択したシステム方式のハードウェア、ネットワーク、 ソフトウェアなどを整理してシステム構成図を作成する 12 システム方式の設計（４） 図１ システム構成図（ハードウェア・ネットワーク構成）の例 13 ５-３ 業務使用と業務処理フロー の設計 14 業務仕様の整理（1） • システム設計書では、まず最初に新システ ムのシステム化目的など、システム化要件 定義の内容を業務仕様として整理する。 15 業務仕様の整理（2） <業務仕様の内容> 1．システム化の目的 2．システム化の背景 3．システム化業務の概要 ・業務の位置づけ ・概念図(組織と情報の流れ) 4．システムの制限事項 16 システム化の目的(1) • システムの作成に当たって、まずその目的を 明確にすることが必要。 • 目的が省力化にあるのか、管理レベルの強 化にあるのかなどによって、システム設計の 仕方も異なる 17 システム化の目的(2) 18 システム化の背景 • システムの設計に当たり、そのシステム全体 がユーザにうまく受け入れられるかを十分検 討する必要がある • 現場でのニーズ、運用担当者レベル、その他 そのシステムを導入する経緯や背景に応じて 記述する 19 システム化業務の概要(1) • システム化する業務の範囲(今回導入するシ ステム化部分)が、将来構想をも踏まえ、どの ような位置づけにあるのかをシステム全体と の対比で記述する。 20 システム化業務の概要(2) 21 システム化業務の概要(3) • 組織と情報の流れがわかるシステム全体の イメージをシステム概念図などで示す。 22 システムの制限事項(1) • システムを開発するとき、実際にはユーザ側 と開発側の双方に技術的および経済的な制 約条件が存在する • ユーザとの合意のもとに、「制限事項」として 記述する。次項では、特にユーザとの確認で 重要な項目を列挙した 23 システムの制限事項(2) <制約事項の項目> – 機能面・・・機能面での制約条件、要望事項で絞込め なかった機能など – 能力面・・・端末応答時間、データ処理時間など – 拡張性・・・業務の拡張、対象事業所、端末数の追加 範囲など – 互換性・・・旧システムからの移行処理、関連システム とのインターフェースなど – 機密性・・・機密性が重要な意味を持つ場合、システ ムのセキュリティ機能の範囲・制限など – 信頼性・・・システムの信頼性が重視される場合、障 害児の影響度など – 運用面・・・システムのサービス時間帯、夜間バッチ処 理など 24 業務処理フローの設計(1) • システム化要求定義で要求されている新 システムに求められる業務仕様を、どのよ うにコンピュータ処理していくかを業務フ ロー設計で行う • 次に示す図は、処理の流れを、どのデータ に対し(入力)、どのような処理を行い(処 理)、結果として何を得るか(出力)という、 入力・処理・出力の関係を表わした処理フ ローである 25 業務処理フローの設計(２) 26 データの流れでシステムを 表現するDFD • DFDはシステム対象領域の業務をデータの 流れと処理のプロセスで把握し、わかりやす く図で表現する方法である。 27 ５-４ サブシステム分割 28 サブシステム分割の仕方 • システム化要求定義をもとに新システムの業務 処理フロー(DFD)を作成した後、関連性が高い 機能をまとめたものがサブシステムである • データ中心のDFDの場合は、新システムの組織 やリソース、処理サイクルといった具体的な物理 的要件を加味し、システムの各機能を整理、分 類し、関連性の高いものごとにまとめたものがサ ブシステムとなる 29 機能をまとめる方法（1） • 新システムの全体構想を描きながら、現状 の業務の流れなども考慮し、次項の方法 で機能をまとめ、サブシステムとして分割 する １．独立性の高い業務(機能)ごとに分割する ２．処理サイクルや時間的関連によって分割 する ３．運用単位によって分割する 30 機能をまとめる方法（2） • サブシステム構成の設計では、それぞれの サブシステム間の関わりが弱くなるように、で きるだけ独立性の高い分割を行う 31 サブシステム構成図 32 処理構造の設計（1） • サブシステムの設計は、詳細設計の段階でさ らに機能ごとにプログラム単位に細分化され ていく • システムのこのような階層化や細分化を行う ことは、システム開発を進める上で、次項か ら示すような効果がある 33 処理構造の設計（2） • それぞれのまとまった機能をひとつの単位 として分割することによりプログラムの複 雑さが軽減され、結果として品質向上につ ながる • システム変更時、サブシステムにまとめて おくことにより、一部のサブシステムで修正 変更を行っても、その影響をほかのサブシ ステムに与えにくい 34 処理構造の設計（3） • 並行してプログラム製作作業が可能となり、 システム開発期間の短縮が図れる • あるサブシステムやプログラム単位に、同一 既存ソフトウェアの再利用がしやすい 35 5-5 入出力情報とコードの設計 作成者 山本恭平 36 ユーザインタフェース設計 • 入出力画面、帳票はユーザから見た使いや すさに最も関係する • ユーザの立場に立って設計する事が重要 37 入力情報の設計 • ポイント 不必要な情報は除外 類似情報はできる限り統合する 38 入力情報の選定、分類、内容設定 • 必要とされる入力情報を選定 • 入力情報を分類 39 入出力情報となる画面設計 • ＧＵＩ（Graphical User Interface）設計ツールを用いる 40 入力チェック • チェック方式 – ニューメリックチェック – リミットチェック（限界検査） – レンジチェック（範囲検査） – シーケンスチェック – 重複チェック – 照合チェック – チェックデジットチェック 41 出力情報の設計 • ポイント 関係者が真に必要とする情報を網羅する 情報をタイムリーに効率的に取り出せる形 にする 42 出力情報の選定、分類、内容設定 • 最終的に出力すべき情報を選定 • 機能、提供先、サイクル、出力機器などを基 準に分類 43 出力情報のレイアウト • 選定した出力情報を前提にレポート利用者の利用 目的に最適なレイアウトを設計していく 44 コード設計 • コードとは データ項目を使用目的に応じて識別するために数字、文字 などを用いて表現したもの システムの使いやすさ、利便性に大きく影響 • 判断基準 外部システムとの関連性を持っている 多くのインプット、アウトプット、ファイル情報に共通している 分類、集計、検索などを容易にする 情報の内容を他の情報から識別する 機密保持を強調する 桁数の節約をはかる 45 コード化の種類 46 コード化の例（１） • 順番コード 01北海道 02青森～４７沖縄 • 区分コード・・・グループ化し、予備コードを残す 01人事課 02厚生課 03～05予備・・・人事部 06経理課 07会計課 08～10予備・・・財務部 • 桁別コード・・・桁数に大中小の分類を持たせる 1101本社人事部人事課 1102本社人事部厚生課 2101東京支店総務部総務課 47 コード化の例（2） • 十進コード・・・十進法に従い細分化する 000一般 100哲学 320法律 325商法 3252社会法 32524株式会社法 • 表意コード・・・属性をコードに組み込む KMキロメートル GMグラム TNトン • 数字文字コード・・・文字を数字に置き換える 01A 02B 03Z • 合成コード・・・2種類以上のコードを組み合わせたもの 95001山田○○ 95002鈴木△△ 48 コード表 • システムにおけるコードは、開発後の運用に おいて常に重要 • コード表に要領よくまとめる 49 コード表の書き方 50 5-6 ファイル設計とデータベース設計 作成者 宮崎 雄吾 51 ファイル設計 • ファイルとは・・・ →ディスク等の記憶装置やメディアに 保存されたデータの集まり。 52 処理方式の選択（1） • シーケンシャル処理 →データを順番に処理。 • ランダム処理 →任意データを取り出す。 53 処理方式の選択（2） 54 ファイル情報の定義 １. ファイルの抽出とファイル名称、用途の設定 ２. 各ファイルの使用サイクルと情報量などの算出 ３. 各ファイルの項目と形式、桁数などの設定 ４. 格納媒体とファイル編成などの設定 55 データベースの設計 1. 現実のデータの洗い出し 2. 収集したデータ項目の整理、分類 3. データモデルへの落とし込み 56 スキーマの概念（1） データ定義 →実際のデータを格納するための「器」を 定義する。 スキーマ →データ構造や核データの関連を記述した設 計情報 57 スキーマの概念（2） 58 ３層スキーマモデル 59 ５-７ セキュリティ設計 作成者 加治正記 60 信頼性・安全性の設計 • 信頼性 ハードウェアやソフトウェア、データ、運用面など、 様々な対象に応じた要求が存在 • 安全性 障害や不正処理もしくは自然災害から、システム を防御・保護 これらをまとめて、コンピューターセキュリティ 61 セキュリティの対策（1） • 代表的な３種類の技術的対策 １．予防対策 ２．トラブルの早期発見、対応手段 ３．被害を最小限に食い止める対策 62 セキュリティの対策（2） 63 システム利用者の管理 • システム設計時に、アクセス権の許可の与え 方を決定 • 一般的には、ユーザＩＤとパスワード • 社内ＬＡＮでは、ワンタイムパスワードやコー ルバックのような認証方式を利用 64 アクセス権の設定 • アクセスコントロール 使用者にレベルに応じた使用権限を与える こと • ログオン時のユーザＩＤを基にアクセス権 限テーブルを参照して、権限を制限する • これらは、ＯＳやデータベースシステム（Ｄ 65 ＢＭＳ）が実現する場合もある ５-８ システム移行設計 作成者 小尾雅人 66 システム移行の設計 • システム開発では、開発するソフトウェア に注目しがち • 対象業務の継続運用には、移行の手段や データの変換、移行作業の時期的制約な ど、多くの問題がある • そのために、システム設計時のデータ変換 インターフェースの設計が必要 67 システム移行手順（1） • システムの移行 新システムの開発が完了し、検査後にユー ザに引き渡すこと • 既存システム（旧システム）がある場合 移行するデータを選定し、移行作業を行う 68 システム移行手順（2） 69 システム移行の方式（1） • 新システムに障害があると、業務に大きな影響 を与える • システム規模が大きい場合 旧システムを並行運用する期間を設け、順次移 行する • 中小規模の場合 短期間で全社的に一斉移行 70 システム移行の方式（2） 71 ５-９ システム運用設計と保守 作成者 坂本 康輔 72 実際に使う人のことを考えて・・ システムは情報の 入力 処理 出力 の繰り返し。同一のパターンが現れる周期を考 え、人の流れとカレンダーとを付き合わせて いく・・・ 73 くわしく説明すると（1） 1. 運用サービス時間帯（When） オンライン運用のサービス曜日・時間帯・夜間バッチ処理の 曜日、時間帯など 2. 運用基本サイクル（How many etc・・・） 目次、週次、月次、期末など処理内容に合わせた、システ ム全体の基本処理サイクル 3. 運用手順（How to, When） システムの立ち上げ、起動、停止、重要なデータやファイル 音バックアップ方法、障害時のバックアップ方法など 74 くわしく説明すると（2） 4. 利用者管理（Who） ユーザＩＤやパスワードの管理方法、アクセス権限 の管理方法など 5．運用支援ツール(How to) データの初期化、クリーンアップの方法、ジョブ管 理、異常通知、ログ、統計情報など 75 保守管理もしなくちゃ（1） • • • システムとは外部のより大きなシステムとも 繋がっている →環境の変化に対応できない場合は処置 が必要。これが保守管理 保守管理には３種類がある。 – 修正作業 – 変更作業 – 改訂作業 76 保守管理もしなくちゃ（2） • 改訂作業 – プログラムの不具合（バグ）が出てくる可能性は 高い • 変更作業 – 外部要因の変化（法律など）に対応する作業 • 改訂作業 – ユーザサイドの改善案や機能改良などをする作 業 77 故障してからじゃ遅いから・・ • 日々の予防が大切。 • 予防保守 – システムの故障や障害が発生するのを予防する ために行われる保守 • 定期保守 – 予め設計され、定期的に行われる保守 • 事後保守 – 障害が発生した後、障害を取り除くために行われ る保守 78 Ｃ０ＬＵＭＮ 家造りとシステム開発 システム化計画 要件定義 施 主 大 工 予算 イメージ その他イメージ 見積もり設計 見積書 制約条件 プログラム開発 システム設計 契約 建築 設計 図面 仕様変更 着 工 運用 コスト・納期 内装・外装 電気・佐官工事 外装・建具 棟上・屋根 基礎工事 検 査 引 き 渡 し 完 成 79 5-10 ドキュメンテーション技術 作成者 砂押 佳佑 80 ドキュメントの重要性 • ドキュメントとは、ソフトウェアのシステム全体 をユーザに説明するシステム設計 ↓ ゆえに、ドキュメンテーション作業（文章化） はＳＥの実作業で大きな比重を占める、非常 に重要なもの 81 ドキュメンテーションの標準化 • システム開発過程での開発メンバー間の分 業のためにも、しっかりとしたシステムの定義 書である「システム設計書」のドキュメンテー ション作業（文章、仕様書の作成）が必要不可 欠 • メーカー、開発会社が独自にシステム設計資 料などのドキュメント標準化をしているのが現 状 82 ドキュメンテーションの意義（1） • ドキュメントの重要性はどのシステム方式で も同じ • ＜ドキュメンテーションの意義＞ – システム設計書などは、ユーザ要求仕様の概要、 システムの構成、機能などをもれなくまとめ、検 査・引渡しなどのときの承認申請書となる。 – システム開発メンバー間の設計レベルに合わせ、 効果的にシステム開発が進められる 83 ドキュメンテーションの意義（2） ■システム納入後のバグによる不具合の対応 など、システム運用にも必要不可欠 – システム運用後の機能追加など、システム保守に も重要 – 技術ノウハウの蓄積、技術移転にも役立つ ■品質の高いシステムを開発し、運用していく ならば、ドキュメントをもれなく簡潔にまとめ ておくことが大事 84 5-11 システム設計書の 構成イメージ例 作成者 玉井英一 85 システム設計書の構成 • • • • 要件定義の概要 システムの全体構成 各機能、仕様 制約事項 など をシステム設計書のドキュメント構成として まとめる 86 システム設計書の目次例 目次 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. システムの目的 システムの位置づけ システム構成図 サブシステム構成図 業務処理フロー（DFD) 入力情報一覧と入力帳票レイアウト 画面体系図と画面フォーマット 出力情報一覧と出力帳票レイアウト コード仕様 ファイル一覧と項目定義 システムの制限事項 セキュリティ設計 システム移行設計 システム運用設計 87