◎システム要件定義
システム要件の定義、システム要件の評価、システム要件の共同レビューを実施する。
●システム化の目標と対象範囲
システム化の目標、対象範囲（対象業務・対象部署）をまとめる。
●機能及び能力の定義
システムの機能要件、性能要件（レスポンスタイム、スループット）をまとめる。
●業務・組織及び利用者の要件
利用者の業務処理手順、入出力情報要件、操作要件（システム操作イメージ）の定義
など、業務、組織、利用者からの要求事項をシステム開発の項目に対応させ、明確に
定義する。
●その他の要件
システム構成条件、設計条件、適格性要件（開発するシステムが利用可能な品質であ
ることを確認する基準）の定義、開発環境の検討などを行う。
◎システム要件の評価
システム要件定義書の作成後、システムの取得者及び供給者が共同でレビューを行う。
◎システム方式設計のタスク
システムの最上位レベルでの方式確立、利用者文書（暫定版）の作成、システム方式の
評価、システム方式設計の共同レビューを実施する。
システムのハードウェア構成、ソフトウェア構成を明確にする。
◎システム方式設計の目的
すべてのシステム要件をハードウェア、ソフトウェア、手作業に振り分け、それらを実
現するために必要なシステムの構成を決定すること、システム要求仕様が実現できるか
リスクなどを考慮した選択肢の提案は可能か、効率的な運用及び保守ができるかなどを
考慮しシステム方式を選択する。
◎ハードウェア・ソフトウェア・手作業の機能分割
業務効率、作業負荷、作業コストなどの観点から検討し決定する。（利用者作業範囲）
●ハードウェア方式設計
信頼性や性能要件に基づいて、冗長化やフォールトトレラント設計、サーバの機能配
分、信頼性配分などを検討しハードウェア構成を決定する。
●ソフトウェア方式設計
システムの供給者が自社ですべて開発するか、ソフトウェアパッケージなどを利用す
るかなどの方針、使用するミドルウェアの選択などを検討する。
●システム処理方式設計
業務に応じた集中処理、分散処理の選択、Ｗｅｂシステム、クライアントサーバシス
テムなど、システムの処理方式を検討する。
●データベース方式設計
システムで使用するデータベースの種類を決定する。
◎システム方式の評価
決定したシステム方式がシステム要件に合致しているか、実現可能かなど、システム方
式を評価する際の基準を作成しシステムの取得者及び供給者が共同でレビューを行う。
◎ソフトウェア要件の確立
業務モデル、論理データモデルを作成して、システムを構成するソフトウェアに求めら
れる機能、能力、インタフェースなどを決定し、ソフトウェア適格性要件を定める。
◎ソフトウェア要件の評価
決定したソフトウェアの要件がシステム要件、システム方式に合致しているか、実現可
能かなど、ソフトウェア要件を評価する。また、ソフトウェア要件定義書の作成後、シ
ステムの取得者及び供給者が共同でレビューを行う。
◎ヒアリングユースケース
●ヒアリング
ソフトウェアに何が要求されているかを明らかにし、理解するためには、利用者から
のヒアリングが有効である。
●ユースケース
一つの目標を達成するための利用者とシステムのやり取りを定義するために用いる。
◎プロトタイプ
ソフトウェア要求分析において、外部仕様の有効性、仕様の漏れ、実現可能性などの評
価を行い、手戻りを防ぐためにプロトタイプを作成する。
◎ＤＦＤ(Data Flow Diagram:データフローダイアグラム)
データの流れを中心にして簡単な記号を用いて業務を表現する。事務処理システム
開発向き。新システム構築時の手順は下記の通り。
・現物理モデル
・現論理モデル
・新論理モデル
・新物理モデル
□─→○ ┌→○─→ □ データの源泉（アクティビティ）
│┌─┘ ↑ → データの流れ（データフロー）
↓│ │ ○ データの処理（プロセス）
─── ─── ── データの蓄積（データベース）
─── ─── ── （データストア）
│ ↑
↓ │
○────┘
※ペトリネット図
事象応答分析に使用。
○ ◎トークン
↓ ↓
───トランジション（事象）
↓
○プレース（状態）
◎Ｅ－Ｒ(Entity Relationship)図
実世界を「実体」(Entity)と実体間の関連(Relationship)で表すモデル。
/\
┌───┐ / \ ┌───┐ □ 実体(Entity)
│ 商品 ├───仕入───┤仕入先│ ◇ 関連(Relationship)
└───┘ \ / └───┘
\/
※関係（カーディナリティ）
─┼─ １対１ ─┼<─１対Ｎ ─○─┼─ １対１または０
◎ＵＭＬ(Unified Modeling Language)
オブジェクト指向分析／設計で用いられる、オブジェクトモデルを表記するための
表記法。
※ＵＭＬにおける静的に表現するクラス図がＥ－Ｒ図に相当する。
◎ソフトウェア構造とコンポーネントの設計
ソフトウェア方式設計書を基に、各ソフトウェアコンポーネントをコーディング、コン
パイル、テストを実施するソフトウェアユニット（単体、クラス、モジュール）のレベ
ルに詳細化し、文書化する。
◎インタフェース設計
ソフトウェア要件定義書を基に、操作性、応答性、視認性、ハードウェア及びソフトウ
ェアの機能、処理方法を考慮して、入出力装置を介して取り扱われるデータに関する物
理設計を行う。出力詳細設計、ＧＵＩ、画面設計、帳票伝票設計を行い、インタフェー
ス設計基準を設ける。
◎ソフトウェアユニットのテストの設計
ソフトウェア詳細設計書で提示された要件をすべて満たしているかどうかを確認するた
めに、テストの範囲、テスト計画、テスト方式を定義し、ソフトウェアユニットのテス
ト仕様書を作成する。ここではホワイトボックステストの設計を行う。
◎ソフトウェア結合テストの設計
ソフトウェア方式設計書で提示された要件をすべて満たしているかどうかを確認するた
めに、テストの範囲、テスト計画、テスト方式を定義し、ソフトウェア結合テスト仕様
書を作成する。
◎ソフトウェア品質
JIS X 0129(ISO/IEC 9126)ソフトウェア品質特性は以下の通り。
●機能性（functionality）
機能とその特性に影響する特性群。機能には、必要性が明確に述べられているものと
暗に示されているものがある。
○合目的性（suitability）
○正確性（accuracy）
○相互運用性（interoperability）
○機密性（security）
○標準適合性（compliance）
●信頼性（reliability）
ある状況がある時間続いたときにソフトウェアがどの程度機能するかに影響する特性
群。
○成熟性（maturity）
○障害許容性（fault tolerance）
○回復性（recoverability）
○標準適合性（compliance）
●使用性（usability）
利用するのにかかる手間、個人の努力などに影響する特性群。
○理解性（understandability）
○習得性（learnability）
○運用性（operability）
○注目性 (attractiveness)
○標準適合性（compliance）
●効率性（efficiency）
ソフトウェアの性能やそれに要するリソース量に影響する特性群。
○時間効率性（time behaviour）
○資源効率性（resource behaviour）
○標準適合性（compliance）
●保守性（maintainability）
何らかの変更を加えるのにかかる手間に影響する特性群。
○解析性（analyzability）
○変更性（changeability）
○安定性（stability）
○試験性（testability）
○標準適合性（compliance）
●移植性（portability）
別の環境にソフトウェアを移行させる可能性に影響する特性群。
○環境適応性（adaptability）
○設置性（installability）
○共存性 (co-existence)
○置換性（replaceability）
○標準適合性（compliance）
◎レビュー（ウォークスルー等）
●ウォークスルー
生産物のエラーの発見ために実施する検討会(レビュー)である。
＃成果物の評価でもなければ、エラーの発生の責任追及でも無い。
開発の担当者が主体となって実施する。資料は事前に配布し内容を見ていることを
前提とする。要求段階や設計段階の初期には、エンドユーザ（利用者）にも参加し
てもらうのが望ましい。
●インスぺクション
ソースコードやテスト仕様書などを１行づつチェックしながら品質を管理する。
ウォークスルーとは違い、モデレータと呼ばれるエラー管理者のもとで組織的に
行われる。
●ラウンドロビン
参加者全員がそれぞれの分担について、レビュー責任者を務めながらレビューを
行う。参加者全員の参画意欲が高まる。
◎ソフトウェア設計評価
ソフトウェア設計内容がソフトウェア要件に合致していること、ソフトウェアコンポー
ネント間やソフトウェアユニット間の内部一貫性などのソフトウェア設計を評価する。
また、ソフトウェア方式設計書、詳細設計書について作成後にレビューを行う。
◎プロセス中心設計
業務で扱うデータの構造や流れに着目し、システム設計を行う手法。
◎データ中心設計
業務で扱うデータの構造や流れに着目し、システム設計を行う手法。企業で扱うデータ
の統一的なデータベースを作り、一元化することで個々のシステム設計をシンプルにす
るというアプローチである。
◎オブジェクト指向設計
データとそれを操作する手続きをオブジェクトと呼ばれるひとまとまりの単位として
一体化し、オブジェクトの組み合わせとしてプログラムを記述するプログラミング技法。
プログラムの部分的な再利用がしやすくなるなどのメリットがある。
※代表的なオブジェクト指向言語
C++
C言語にオブジェクト指向的な拡張を施した言語。
Java
Sun Microsystems社が開発した純粋なオブジェクト指向言語。
Smal Talk
Xerox社の開発した、マウス操作による記述が可能なオブジェクト指向言語。
Objective-C
NeXT社(現在はApple Computer社の一部門)が自社のOSであるNeXT STEP向け
アプリケーション開発用に開発したC言語ベース言語。
●オブジェクト
現実世界に存在する物理的・概念的なもの。
●クラス
共通の属性を持つオブジェクトをまとめたもの。
●汎化と特化（特化 is a 汎化）-----------------------------クラスの概念
汎化は、下位クラスの共通する性質をまとめ、抽象化することができる。
特化は、上位クラスの性質を分割して具体化すること。
┌───┐
│ │自動車│ ↑
│特化 └─┬─┘ │汎化
↓ ┌───┴───┐ │
┌─┴─┐ ┌─┴──┐
│ バス │ │トラック│
└───┘ └────┘
●集約と分解（分解 part of 集約）（集約 has a 分解）---オブジェクトの概念
集約は下位オブジェクトの共通する部分をまとめて抽象化すること。
分解は上位オブジェクトの部分を分割して具体化すること。
●インスタンス
オブジェクトの具体的な値。
●カプセル化
データやそのデータを操作するふるまい(メソッド)及び制約をオブジェクト内に
封じこめること。
●継承（インヘリタンス）
クラス階層の間で上位クラス(スーパークラス)の属性を下位クラス(サブクラス)に
引き継ぐこと。
●多様性（ポリモフィズム）
複数の異なるオブジェクトに対し、同じメッセージを送るとそれぞれのオブジェク
トが固有の振る舞いをする。
●委譲（アグリゲーション）
上位クラスが処理の窓口となってメッセージを受け取り、他の下位クラスに定義した
メソッドで処理を代行してもらうことができること。
メソッドは上位・下位クラス両方に定義する。
●再定義（オーバライド）
上位クラスから引き継いだ同じメソッドを下位クラスで定義しなおすこと。
※コンポーネントウェア
オブジェクト指向技術を基盤としたソフトウェア部品を組み立てることによってア
プリケーションを開発するための技術の総称。
◎モジュール設計
＜モジュール分割技法＞
●源泉／変換／吸収分割法（ＳＴＳ法、データフロー分割法）
７つほどの機能に分けた後、データの流れにより、以下の３つに分割していく。
入力処理（源泉：Source）
↓-------------------------------最大抽象入力点
変換処理（変換：Transform）
↓-------------------------------最大抽象出力点
出力処理（吸収：Sink）
●トランザクション分割法（ＴＲ法）
入力トランザクション毎に処理機能が異なる場合、それ毎に分割する。
オンラインリアルタイム処理など。
トランザクションってなに？
＞関連する複数の処理をまとめた一つの処理単位。
●ジャクソン法
設計時点で入出力データの構造が明確な場合、データ構造を分析して、それをもと
にプログラムの制御構造を導き出す方法。「連接・選択・繰り返し」で表現。
・順序的不一致
・境界不一致
・脈略不一致
●ワーニエ法
ジャクソン法同様、データ構造に着目するが、入力構造のみを中心にプログラム構造
を決定する。事務処理プログラム向き。 ▲▲▲▲▲▲
＜モジュール強度＞
弱 ・暗号的強度 機能の間に何も関連性がない
↑ ・論理的強度 「論理的な機能」によってモジュールが構成されている
│ ・時間的強度 機能の間の関連性は低いが、同じタイミングで実行される
│ ・手順的強度 機能の間の関連性は低いが、実行順序では関連性がある
│ ・連絡的強度 手順的強度を持ち、さらに機能間でデータを受け渡す
↓ ・情報的強度 全機能が同一のデータ構造を操作する・機能的強度、単一機能を持つ
強 ・機能的強度 単一機能を持つ
◎アーキテクチャパターン
ソフトウェア構造のパターンであることなどの特徴を踏まえて、アーキテクチャパター
ンを利用する。
※ＭＶＣモデル
処理の中核を担う「Model」、表示・出力を司る「View」、入力を受け取ってその内
容に応じてViewとModelを制御する「Controller」の3要素の組み合わせでシステムを
実装するソフトウェアの設計モデル方式。
◎デザインパターン
主にオブジェクト指向設計に用いられ、生成に関するパターン、構造に関するパターン
、振る舞いに関するパターンの３種類に分類されることなどの特徴を踏まえて、デザイ
ンパターンを利用する。
◎プログラミング手法
●手続き型（構造化）プログラミング
対象とする問題の解決手順を手続きによって記述する方式。
例）COBOL、FORTRAN、PASCAL、C
●論理型プログラミング
事実と推論規則を用いて、「論理」を記述する方式。
例）Prolog
●関数型プログラミング
「関数」を記述する方式。
例）LISP
●オブジェクト指向プログラミング
オブジェクトの状態とその振る舞いを記述する方式。
例）C++、Java、SmalｌTalk、Objective-C
◎ソフトウェアコード作成
定められたコーディング基準、プログラム言語の仕様に従い、ソフトウェア詳細設計書
に基づいてプログラミングを行う。
◎コーディング基準
インデンテーション、ネスト、命名規則、使用禁止命令など、定められたコーディング
基準に基づいてコーディングを行う。
◎コーディング支援手法
●コード補完
テキストエディタや統合型開発環境のソースエディタなど、ソースコードを記述する
場面において、人間のうろ覚えな記憶を補って、直前の入力内容から、そこに書くべ
きコードの一覧を表示するなど、入力を補完してくれる機能のこと。
●コードオーディタ
独自に決めたプログラムコードの書き方の規約に違反しているものがないかをチェッ
クするための静的な解析ツール。
●シンタックスハイライト
テキストエディタの機能であり、テキスト中の一部分をその分類ごとに異なる色やフ
ォントで表示するもの。
◎コードレビュー
●メトリクス
ソフトウェアの品質を評価することを目的として取得される情報であり、ソフトウェ
アの開発プロセスや成果物に関する何らかの尺度を表す。
●コードインスペクション
コーディングし終わったプログラムが規定どおりに書かれているかを確認する作業。
●ピアコードレビュー
コーディングに関する専門家による評価や検証のこと。
◎デバッグツール
●トレーサ
誤りの箇所が特定できないときに、実行順に命令とその実行結果を出力する。
●ダンプリスト
磁気テープファイルや磁気ディスクファイルなどの内容を出力する。
●メモリダンプ
プログラム実行中にエラーが発生したとき、メモリの内容を出力する。
●スナップショット
プログラムの特定の命令を実行するごとに、指定されたメモリの内容を出力する。
◎テスト手法
テスト：仕様通りであるかを調べる作業。
※ブラックボックステスト・ホワイトボックステスト共に「増加テスト」。
●ブラックボックステスト
外部仕様通りであるか、入力の可能性がある値のすべての組合せをテストする。
○同値分割
仕様上正常データ・異常データによるパターンに分けてテストを行う。
○限界値分析
実データから無作為にテストデータを抽出するのではなく、
仕様の入出力条件から、その境界値を中心にテストを行う。
○原因―結果グラフ
仕様の入出力条件から関連グラフ、テーブルを作成し、テストを行う。
●ホワイトボックステスト
内部仕様通りであるか、ロジックを調べすべての経路が実行されるようにテストする
手法である。理想的には、全ての処理パターンについてテストを行えればいいのだが、
現実には困難であるため、以下のようないろいろな技法が考えられている。
○命令網羅
プログラム内の全ての命令を最低１回は実行させる。
○条件網羅
プログラム内の全ての判定条件で全ての組み合わせを満たすようテストする。
※ロジスティック曲線（≒ゴンペルツ曲線）
バグ発見数
↑
│ ＊＊＊
│ ＊＊
│ ＊
│＊
└───────→時間
※レグレッションテスト（デグレードテスト、回帰テスト、退行テスト）
変更のないはずの機能に影響がないことを確認するテスト。
◎結合テスト技法
●トップダウンテスト
上位モジュールから下位モジュールへと順次結合してテストを行う。
被テストモジュールが呼び出す「スタブ」が必要。
●ボトムアップテスト
下位モジュールから上位モジュールへと順次結合してテストを行う。
被テストモジュールが呼び出される「ドライバ」が必要。
●ビッグバンテスト
単体テストの完了したモジュールを一挙に結合して行うテスト。
長所：単体テストと並行して実施でき、モジュール間のインタフェースだけを
テストすれば良いのでテスト工数を削減できる。
短所：エラー個所の特定が困難なため、大規模なプログラムテストには不向き。
システム結合計画の作成、システム結合テストの実施、利用者文書の更新、システム適格
性確認テストの準備、システム結合テストの評価、システム結合の共同レビューを実施す
る。
ソフトウェア導入（インストール）計画の作成、ソフトウェア導入を実施する。
システムの取得者の受入れレビュー、受入れテストの支援、ソフトウェア製品の納入、
取得者への教育訓練、支援を実施する。
◎システムの障害管理
●障害回復手順
○障害の把握（システムコンソールメッセージチェック）
システムメッセージなどをチェックし、何が起きているかを確認。
○切り離し（アイソレーション）
障害部分を切り離し、他への波及を阻止する。
○暫定処理
一時的対応を行う。
○恒久処置
原因を究明し、再発を防止する処置を行う。
○暫定処置解除
一時的対応を解除する。
●障害の種類別回復手順
○ハードウェア障害
障害機器の切り離し、障害機器の修復、バックアップ機への切り替え
○ソフトウェア障害
以前のバージョンへの切り替え
○データ障害
不良データを除去してリスタート
◎資源管理
●プログラム管理
バージョン管理、更新手続き、確認方法、変更履歴の保存に注意。
●ライブラリ管理
スペース管理、破損等の障害管理に注意。
◎ドキュメント管理
●計画・要求定義：プロジェクト計画書
●外部設計 ：外部設計書
●内部設計 ：内部設計書
●プログラミング：プログラム仕様書、プログラムリスト、単体テスト成績書
●テスト ：結合テスト成績書、システムテスト成績書、運用テスト成績書
●納入 ：プロジェクト完了報告書
●運用 ：システム操作手順書、業務処理実行手順書、障害復旧手順書
◎コスト管理
●コストの種類
○初期費用
情報システム導入時に必要となる費用。
○運用費用（定常コスト、ランニングコスト）
情報処理システムを運用していく上で定常的に発生する費用。
●コスト管理の留意点
○予実績管理
○原価管理と配賦
○課金
※ＴＣＯ（Total Cost of Ownership）
情報システムのライフサイクルの中で用いられる運用費用や保守費用、
要員の教育費用など導入後における費用を全て含めたシステム費用の総和。
▲▲▲▲▲▲▲
◎保守の形態
●保守の時期
○定期保守
○事後保守
○予防保守
●保守の理由
○物理保守
○適応保守
○完全化保守
○拡張保守
●保守の活動
○応急保守
○予防保守
○計画保守
◎保守契約
保守契約書に記載する事項は次の通り。
●定期保守実施周期
●費用
●障害時の保証、対応