システム開発技術

目次

応用情報技術者試験（レベル３）シラバス－情報処理技術者試験における知識・技能の細目－ Ver.6.1 に基づき，「システム開発技術」の対策ノートを作成した。

本稿は，システムアーキテクト試験，プロジェクトマネージャ試験 午前Ⅱ 問題の対策としても活用できるようにしている。

• システム要件定義
• システム方式設計
• ソフトウェア要件定義
• ソフトウェア方式設計・ソフトウェア詳細設計
• ソフトウェア構築
• ソフトウェア結合・ソフトウェア適格性確認テスト
• システム結合・システム適格性確認テスト
• 導入
• 受入れ支援
• 保守・廃棄
• 本稿の参考文献

システム要件定義

(1) システム要件定義のタスク

要件定義の目的は，「システムの利害関係者（ステークホルダ）に対して，システムが必要とする機能や特性を明確に定義する」ことである。

(2) システム要件の定義

① システム化の目的と対象範囲

要件定義（requirements definition）とは、システムやソフトウェアの開発において、実装すべき機能や満たすべき性能などのを明確にしていく作業のこと。いわゆる上流工程の一部で、実際の開発・実装作業を始める前に行う作業の一つである。

要件定義では、利用者がそのシステムで何がしたいのかを元に、それを実現するために実装しなければならない機能や、達成しなければならない性能などを開発者が検討して明確にしていく。まとめられた成果は「要件定義書」として文書化されることが多い。一般的にこの段階では「何が」必要なのかを定義するに留め、それを「どのように」実現するかは後の工程で検討される。

共通フレーム 2013 では，要件定義プロセスの実施アクティビティとして，次の 5 つを挙げている。

1. 利害関係者の識別
2. 要件の識別
3. 要件の評価
4. 要件の合意
5. 要件の記録

② 機能及び能力の定義

システム機能仕様

レスポンスタイム

レスポンスタイム（Response Time）とは，システムや装置などに，処理の実行指示を与えてから最初の応答を得るまでの時間のこと。いわゆる応答時間。

レスポンスタイムが短いほど，利用者や他のシステムが応答を待つ「待ち時間」が少ないことを意味する。

情報システムなどの場合には，入力が終了した時点から，応答出力が開始される時間までの時間のことを指す。また，ネットワークを介して情報を送受信するようなシステムの場合は，送信が完了してから受信を開始するまでの時間を指す。

スループット

スループット（Throughput）とは，コンピュータやネットワークが単位時間当たりに処理できるデータ量（または，ジョブやトランザクションなどの処理件数）のことで，システムにおけるパフォーマンスの評価指標となる基準のこと。

③ 業務・組織及び利用者の要件

要求分析とは、システムやソフトウェアの開発の初期段階で、利用者がそのシステムに何を求めているのかを明確にしていく工程のこと。いわゆる上流工程の一部で、実際の開発・実装作業を始める前に行なう作業の一つである。

共通フレーム 2007 において，システム要件として定義するものは，業務，組織及び利用者の要件である。

性能要件

データベース要件

テスト要件

セキュリティ要件

移行要件

運用要件

運用手順

運用形態

保守要件

可用性

障害対応

教育

訓練

費用

保守の形態

保守のタイミング

CRUD マトリクス

各機能が，どのエンティティに対して，どのような操作をするかを一覧化したものであり，操作の種類には生成（Create），参照（Reference），更新（Update）及び削除（Delete）がある。

④ その他の要件

実行環境要件

周辺インターフェース要件

品質要件

品質要件には，機能性，信頼性，使用性，効率性，保守性，移植性がある。

機能要件

機能要件とは，システムの利用者に対して提供される具体的な価値で，システム利用者の何らかの目的を達成するために使われるものである。

非機能要件

非機能要件とは，システム利用者が機能を利用する時に補助的に必要なシステムの特性や性能のことである。

非機能要件を整理した例を次表に示す。

なお，IPA（独立行政法人 情報処理推進機構）が提唱する「非機能要求グレード」の中では，非機能要求を以下の 6 大項目に分類している。

可用性

システムやサービスを継続的に利用可能とするための要求

性能・拡張性

システムの性能，および，将来のシステム拡張に関する要求

運用・保守性

システムの運用と保守のサービスに関する要求

移行性

現行システム資産の移行に関する要求

セキュリティ

情報システムの安全性の確保に関する要求

システム環境・エコロジー

システムの設置環境やエコロジーに関する要求

(3) システム要件の評価及びレビュー

システム要求事項分析プロセスとは、JIS X 0160（ソフトウェアライフサイクルプロセス）で定義されているプロセス名で、共通フレーム 2013 におけるシステム要件定義プロセスに対応する。

JIS X 0160 では、システム要求事項は、次の基準を考慮して評価するとしている（共通フレーム 2013 も同様）。

• 取得ニーズの追跡可能性
• 取得ニーズとの一貫性
• テスト可能性
• システム方式設計の実現可能性
• 運用及び保守の実現可能性

追跡可能性

一貫性

テスト可能性

システム方式設計の実現可能性

運用及び保守の実現可能性

レビュー参加者

レビュー方式

レビューには，次表に示すようなものがある。

システム方式設計

(1) システム方式設計のタスク

ハードウェア構成品目

ソフトウェア構成品目

ソフトウェアライフサイクルプロセスのシステム方式設計では，ソフトウェア構成品目の明確化を行う。

手作業

機能要件（functional requirement）

機能要件とは、情報システムやソフトウェアの開発に際して定義される要件のうち、機能や挙動に関するもの。主に要求分析や要件定義などの工程で検討・決定される。

非機能要件（non-functional requirement）

非機能要件とは、情報システムやソフトウェアの開発に際して定義される要件のうち、機能面以外のもの全般。性能や信頼性、拡張性、運用性、セキュリティなどに関する要件が含まれる。

(2) システムの最上位の方式確立

① システム方式設計の目的

② ハードウェア・ソフトウェア・手作業の機能分割

利用者作業範囲

③ ハードウェア方式設計

④ ソフトウェア方式設計

ソフトウェア品目に対する要件を，最上位レベルの構造を表現する方式で，かつ，ソフトウェアコンポーネントを識別する方式に変換する。

ソフトウェア方式設計プロセスでは，次のタスクを実施する。

• ソフトウェア品目の外部インタフェース，及びソフトウェアコンポーネント間のインタフェースについて最上位レベルの設計を行う。
• データベースについて最上位レベルの設計を行う。
• ソフトウェア結合のために暫定的なテスト要求事項及びスケジュールを定義する。

⑤ システム処理方式設計

⑥ データベース方式設計

論理データモデル作成におけるトップダウンアプローチでもボトムアップアプローチでも，最終的な論理データモデルは正規化され，かつ，業務上の属性はすべて揃えていなければならない。

関係データベース（RDB : relational database）

関係データベースとは、データベースの構造の一つで、一件のデータを複数の属性の値の組として表現し、組を列挙することでデータを格納していく方式。属性を列、組を行とする表（テーブル）の形で示されることが多い。最も普及している方式で、単にデータベースといった場合はリレーショナルデータベースであることが多い。

NDB（Network Database：網型データベース）

親となるものが複数ある場合にも取り扱うことができる。1980 年頃まで汎用コンピュータで広く用いられていたが，関係データベースの性能が向上したことにより，現在ではあまり使われていない。

OODB（Object Oriented Database：オブジェクト指向データベース）

オブジェクト指向データベースは，「オブジェクト」という単位でデータを格納するデータベースである。オブジェクト指向は，1990 年代に Java をはじめとするオブジェクト指向プログラミング言語で注目され，その後広く普及した。

XML データベース

XML データベースは，XML (Extensible Markup Language) の形式でデータを格納するデータベースである。

XML データベースの大きな特徴は，あらかじめデータベースの構造（スキーマ）を定義しなくてもデータが格納できてしまう点である。XML データベースの場合は，最初にデータの構造（スキーマ）を定義しないため，いったんデータの格納が始まってから，格納するデータの種類が増えても，元から存在していたデータのパス（階層位置）が変わらなければアプリケーションプログラムへの影響がない。このため，データの構造が将来的に成長していくような（格納するデータの種類が増えていくような）データベースの場合には，XML データベースが適している。

一方で，XML データベースは，実データと一緒にタグデータを保持する必要があり，他のデータベースと比較して，データサイズが大きくなってしまう傾向がある。また，データがツリー構造であるため，たくさんのデータの中からある条件に合致するデータを全て取得する場合など性能面でリレーショナルデータベースに比べて分が悪い場合がある。

(3) システム結合テストの設計

テスト要求事項

テスト要求事項が定義されるアクティビティとテストの組合せを下図に示す。

(4) システム方式の評価及びレビュー

追跡可能性

一貫性

設計標準や方法の適切性

ソフトウェア品目の実現可能性

運用及び保守の実現可能性

レビュー参加者

レビュー方式

ソフトウェア要件定義

(1) ソフトウェア要件定義のタスク

ソフトウェア構成品目

(2) ソフトウェア要件の確立

① ソフトウェア要件定義の目的

② サブシステムの機能仕様とそのインタフェースの設計

サブシステム分割

サブシステム機能仕様定義

サブシステムインターフェース定義

サブシステム関連図

サービスの定義

③ 業務モデルとデータモデルの設計

システム化計画の立案において実施する作業で，その作業の結果を基に，後続の作業でシステム化機能を整理し，情報の処理の流れを明確にするものは，業務モデルの作成である。

業務モデリング

帳票設計

伝票設計

データモデリング

データベースの設計を失敗しないための最大のポイントは，取り扱うデータの構造をいかに正確に理解するかである。このための設計作業をデータモデリングと呼ぶ。

モデリングとは，ある対象を正確に理解し，何らかの形（図形や文章）で表現する作業のことである。データモデリングは，① 概念データ設計（概念データモデリング），② 論理データ設計（論理データモデリング），③ 物理データ設計（物理データモデリング）の 3 段階で設計していく。

システム業務フロー

④ セキュリティ設計

情報セキュリティ方針

セキュリティ要件

セキュリティ実現方式

安全性対策

信頼性対策

⑤ 保守性の考慮

無矛盾性

自己記述性

構造性

簡潔性

拡張性

(3) ソフトウェア要件の評価及びレビュー

追跡可能性

外部一貫性

内部一貫性

テスト可能性

ソフトウェア設計の実現可能性

運用及び保守の実現可能性

レビュー参加者

レビュー方式

(4) 業務分析や要件定義に用いられる手法

① ヒアリング

ヒアリング計画

ヒアリング議事録

② ユースケース

アクタ

システムのユーザが果たす役割を表し、システムと活発に情報交換をしたり、システムから受動的に情報を受け取ったりする。人間，ハードウェア，外部システムがアクターになりえる。

振舞い

ユースケース図

ユースケース図は、UML の 1 つでシステムに要求される機能を、利用者（アクタ : actor）の視点から示した図である。

主に要求分析段階でユーザの要件を特定するために作成され、ユースケース図を有効に活用することにより、システムの全体像を開発者と利用者が一緒に評価しやすくなる利点がある。

なお，ユースケースとは，アクターとシステムとの間の対話をモデル化したもので、アクターによって開始され、システムのある機能を実行する。システムのユーザがシステムを利用して遂行する単位業務のひとつを抽象化したものである。

ユースケース駆動開発は，システムが実現する機能を適切な単位のユースケース（利用者から見たシステムの振る舞いを記述したもの）に分割し，ユースケースを開発の基点にして要求分析から実装まで全ての工程をユースケース単位で進める開発手法である。分析，設計，実装，テストの各工程の成果物がユースケースごとに作成されるため，要件ごとの開発状況を把握することが可能となる。

③ モックアップ及びプロトタイプ

モックアップ（mock-up）とは、工業製品の設計・デザイン段階で試作される、外見を実物そっくりに似せて作られた実物大の模型のこと。ソフトウェアや Web サイト、印刷物などのデザインを確認するための試作品のこともこのように呼ばれることがある。

プロトタイプ（prototype）とは、原型、試作品などの意味を持つ英単語。IT の分野では、ハードウェア開発の際の量産前の試作品や、動作や機能を検証するために最小限の規模で試作されたソフトウェアなどのことを意味する。

プロトタイプで実際に動作する様子を見せることで，利用者に完成品のイメージを早期に理解させることができる。

プロトタイプ版評価

プロトタイプ版評価を行うことで，以下の理由から精度の高い要件定義が行うことができると考えられる。

• システムの使い勝手を実感できる。
• システムの特徴を正確に把握できる。
• システムの内容を正確に理解できる。

④ DFD

DFD（Data Flow Diagram，データフロー図）とは、情報システムの設計時などに作成される図の一つで、要素間のデータの流れを表した図。データがどこで発生し、どこからどこへ運ばれ、どこへ出力・保管されるのかを図示することができる。DFD では，処理・プロセス（〇），データの吸収先（□），データの流れ（→），データストア（＝）の 4 つの記号を用いて対象業務のモデル化を行う。

コンテキストダイアグラム

ミニスペック

段階的詳細化

構造化分析法

アクティビティ

データストア

ほかのデータストアと直接にデータフローで結ばれることはなく，処理が介在する。

データフロー

データの流れを示す。

プロセス

システムのもつ処理機能を示す。

⑤ E-R 図

E-R 図（Entity Relationship Diagram）とは、情報システムの扱う対象を、実体（entity）、関連（relationship）、属性（attribute）の三要素でモデル化する「ER モデル」を図示したもの。データベースの設計などでよく用いられる。

具体的には，管理の対象をエンティティ及びエンティティ間のリレーションシップとして表現する。

データ中心設計

企業の業務活動は環境の変化に合わせて刻々と変化しているが，システムで取り扱われているデータは企業の経営内容が変わらない限りほとんど変化しない。データ中心アプローチ (DOA : Data Oriented Approach) は，この安定したデータ基盤を共有資源として先に設計し，そのデータに基づいてソフトウェアを設計するという方法論である。

実体

関連

⑥ UML

UML（Unified Modeling Language）とは、オブジェクト指向のソフトウェア開発において、データ構造や処理の流れなどソフトウェアに関連する様々な設計や仕様を図示するための記法を定めたもの。ソフトウェアのモデリング言語の標準としてとして最も広く普及している。

クラス図

クラスの仕様と，クラスの間の静的な関係が記述できる。

多重度とは，関連するクラス同士において，あるクラスの 1 つのインスタンスに別のクラスのインスタンスが対応する数を表す。

操作

属性

ロール図

パッケージ図

アクティビティ図

ある振る舞いから次の振る舞いへの制御の流れを表現する。多くの並行処理を含むシステムの，オブジェクトの振る舞いが記述できる。

ユースケース図

ステートチャート図

ある特定のオブジェクトに注目して，そのライフサイクルをモデリングする。

シーケンス図

コミュニケーション図

オブジェクト群がどのようにコラボレーションを行うか記述できる。

イベントフロー分析

バックトラック

コントロールフロー

分析と設計の役割分担

エージェント指向

モデル

フレームワーク

コンポーネント図

システムのコンポーネント間の物理的な関係が記述できる。

⑦ その他の手法

決定表（デシジョンテーブル）

決定表（デシジョンテーブル）は，条件とそれに対応する処理を表形式で表す図式表現である。複雑な条件判定を伴う要件定義の記述手段として有効である。

SysML（Systems Modeling Language）

システムの設計及び検証を行うために用いられる，UML仕様の一部を流用して機能拡張したグラフィカルなモデリング言語。

ソフトウェア方式設計・ソフトウェア詳細設計

(1) ソフトウェア方式設計のタスク

ソフトウェア方式設計では，ソフトウェア要件設計の内容に基づいて，どのようにプログラムやシステムを実現すればよいかを具体的に定める。ソフトウェア方式設計で設計するものは，次のとおり。

1. 機能分割／階層構造化
2. 物理データ設計
3. 入出力詳細設計
4. ソフトウェア結合テスト使用の作成

ソフトウェアコンポーネント

ソフトウェアコンポーネント分割

ソフトウェアコンポーネント間インタフェース設計

ソフトウェア結合のためのテスト要件

(2) ソフトウェア詳細設計のタスク

ソフトウェアコンポーネントの単位

機能階層図

ソフトウェアユニット

ユニット分割

コンポーネント詳細設計

ソフトウェアコンポーネントインタフェース詳細設計

ソフトウェアユニット間インタフェース設計

データベース詳細設計

(3) ソフトウェア方式設計

要求事項を実装し，それに対して検証できるソフトウェアの設計を提供する。ソフトウェア方式設計では，次のタスクを実施する。

• ソフトウェア品目の外部インタフェース，及びソフトウェアコンポーネント間のインタフェースについて最上位レベルの設計を行う。
• データベースについて最上位レベルの設計を行う。
• ソフトウェア結合のために暫定的なテスト要求事項及びスケジュールを定義する。

構造化

ソフトウェアコンポーネント機能仕様決定

コンポーネント間インタフェース設計

基本機能

部品

入出力設計

物理データ設計

物理データ設計では，データベースを実装する準備作業として，DBMS を意識した設計を行い，物理データモデルを作成する。まずは，エンティティとその属性に物理名を付与する。

次に，属性に対してデータ型と文字列長を定義する。データ型とは，その属性に格納できるデータの種類を表すものである。代表的なデータ型には，文字型，数値型，日付／時刻型などがある。

部品化

再利用

(4) ソフトウェア詳細設計

要求事項及びソフトウェア方式に対して実装し，検証でき，コーディング及びテストを可能にするために十分に詳細である設計をソフトウェアのために提供する。

コンポーネントインタフェース

データベース

物理データ設計が完了すると，DBMS 上へのデータベースの構築が可能となる。リレーショナルデータベースでは，SQL のデータ定義言語 (DLL : Data Definition Language) を用いることで DBM 上にデータベースを構築できる。

モジュール分割

ソフトウェア詳細設計では，ソフトウェア方式設計で決めた各プログラムをモジュールの単位に分割する。モジュール化することで，プログラム変更時の影響範囲を局所化でき，保守が容易になる。また，他のアプリケーションへの再利用が行える。分割後は，各モジュールの処理内容（アルゴリズム）を次工程のプログラミングで記述できるように文章化し，設計書として示す。ソフトウェア詳細設計で設計する者は，次のとおり。

1. モジュール分割
2. 単体テスト（プログラムがモジュール単位で正常に動作するかを確かめるテスト工程）仕様の作成

モジュール強度とは、モジュール内部の関連性の強さを表し、暗合的強度（最も弱い）から機能的強度（最も強い）までの 7 種類があります。モジュール強度が高いほど独立したソフトウェア部品として再利用や拡張がしやすくなる。

暗合的強度（最も弱い）

関係のない機能をまとめたモジュール

論理的強度

関連する複数の機能をまとめたモジュール。例として，二つの機能 A, B のコードは重複する部分が多いので，A, B を一つのモジュールにまとめ，A，B の機能を使い分けるための引数を設けた。

時間的強度

プログラムの開始時など、ある特定の時期に実行する機能をまとめたモジュール。例として，複数の機能のそれぞれに必要な初期設定の操作が，ある時点で一括して実行できるので，一つのモジュールにまとめた。

手順的強度

関連ある逐次的な機能をまとめたモジュール

連絡的強度

関連ある逐次的な機能で要素が連絡し合うものをまとめたモジュール。例として，二つの機能 A, B は必ず A, B の順番に実行され，しかも A で計算した結果を B で使うことがあるので，一つのモジュールにまとめた。

情報的強度

同じデータ構造や資源を扱う機能を一つにまとめたモジュール。例として，ある木構造データを扱う機能をデータとともに一つにまとめ，木構造データをモジュールの外から見えないようにした。

機能的強度（最も強い）

一つの機能を実現するためだけのモジュール

モジュール仕様

セグメント化

制御構造

制御セグメント

データ処理

加工セグメント

プログラム設計

(5) インタフェース設計

入出力詳細設計

GUI

画面設計

画面設計の成果物には，次のものがある。

• UI 設計ポリシー
• 画面遷移図
• 画面一覧
• 画面モックアップ
• 画面入力チェック仕様書

帳票伝票設計

レイアウト設計

インタフェース設計基準

タイミング設計

インタフェース条件

インタフェース項目

ヒューマンインタフェース

画面構成

フォームオーバレイ

リミットチェック

(6) ソフトウェアユニットのテストの設計

テスト要件

チェックリスト

ホワイトボックステスト

ホワイトボックステストにおけるテストケースの設計方法には，命令網羅，判定条件網羅（分岐網羅），条件網羅，判定条件／条件網羅，複数条件網羅がある。

ホワイトボックステストのテスト項目の作成方法としては，以下のようなものがある。

• ユニット内の条件判定の組合せ全てを少なくとも 1 回は実行する。
• ユニットの全ての分岐を少なくとも 1 回は実行する。
• ユニットの全ての命令を少なくとも 1 回は実行する。

(7) ソフトウェア結合テストの設計

ソフトウェア結合テスト仕様

テスト要件

チェックリスト

ブラックボックステスト

システムの内部構造が明らかでない状態で検証を行うことからブラックボックステストと呼ばれている。

ブラックボックステストにおけるテストケースの設計方法には，同値分割，限界値分析，因果グラフ（原因－結果グラフ），エラー推測がある。

ブラックボックステストのテスト項目の作成方法としては，以下のようなものがある。

• ユニットへの入力データの値の範囲を分割し，各代表値で実行する。
• ユニットへの入力と出力の因果関係を網羅するように実行する。

(8) ソフトウェア設計の評価及びレビュー

追跡可能性

外部一貫性

内部一貫性

設計方法や作業標準の適切性

テストの実現可能性

運用及び保守の実現可能性

レビュー参加者

レビュー方式

(9) ソフトウェア品質

JIS X 25010

JIS X 25010:2013 は、システム及びソフトウェア製品の品質を評価する基準で、ISO/IEC 25010 を基に JIS X 0129 の後継規格として標準化されたものである。

JIS X 25010:2013 においては、機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性の 8 つの特性と、それぞれの品質特性をさらに細分化した 32 の副特性が定められている。

機能適合性 (functional suitability)

明示された状況下で使用するとき，明示的ニーズ及び暗黙のニーズを満足させる機能を，製品又はシステムが提供する度合い
（機能適合性） = （利用者からの改良要求件数） ÷ （出荷後の経過月数）

性能効率性 (performance efficiency)

明記された状態（条件）で使用する資源の量に関係する性能の度合い

互換性 (compatibility)

同じハードウェア環境又はソフトウェア環境を共有する間，製品，システム又は構成要素が他の製品，システム又は構成要素の情報を交換することができる度合い，及び／又はその要求された機能を実行することができる度合い

使用性 (usability)

明示された利用状況において，有効性，効率性及び満足性をもって明示された目標を達成するために，明示された利用者が製品又はシステムを利用することができる度合い

信頼性 (reliability)

明示された時間帯で，明示された条件下に，システム，製品又は構成要素が明示された機能を実行する度合い
（信頼性の評価指標） = （最終成果物に含まれる誤りの件数） ÷ （最終成果物の量）

セキュリティ (security)

人間又は他の製品若しくはシステムが，認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように，製品又はシステムが情報及びデータを保護する度合い

保守性 (maintainability)

意図した保守者によって，製品又はシステムが修正することができる有効性及び効率性の度合い
（保守性の評価指標） = （修正時間の合計） ÷ （修正件数）

移植性 (portability)

一つのハードウェア，ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に，システム，製品又は構成要素を移すことができる有効性及び効率性の度合い
（移植性の評価指標） = （変更が必要となるソースコードの行数） ÷ （移植するソースコードの行数）

"満足性" に対するリスクとして分類される，リスクとその評価の事例は「操作に習熟していない利用者が，誤った使い方をしたときの対処方法が分からずに困惑し，快適でないと評価される」である。

ISO 9000

① 利用時の品質モデル

利用時の品質モデルは，特定の利用者が特定の利用状況において，有効性，効率性，リスク回避性及び満足性に関して特定の目標を達成するためのニーズを満たすために，製品又はシステムを利用できる度合いのことである。

利用時の品質の特徴は，有効性，効率性，満足性，リスク回避性及び利用状況網羅性の五つの特性に分類される。

有効性（effectiveness）

明示された目標を利用者が達成する上での正確さ及び完全さの度合い。

効率性（efficiency）

利用者が特定の目標を達成するための正確さ及び完全さに関連して，使用した資源の度合い。

満足性（satisfaction）

製品又はシステムが明示された利用状況において使用されるとき，利用者ニーズが満足される度合い。

リスク回避性（freedom from risk）

製品又はシステムが，経済状況，人間の生活又は環境に対する潜在的なリスクを緩和する度合い。

利用状況網羅性（context coverage）

明示された利用状況及び当初明確に識別されていた状況を超越した状況の両方の状況において，有効性，効率性，リスク回避性及び満足性を伴って製品又はシステムが使用できる度合い。

② 製品品質モデル

機能適合性（functional suitability）

明示された状況下で使用するとき，明示的ニーズ及び暗黙のニーズを満足させる機能を，製品又はシステムが提供する度合い

性能効率性（performance efficiency）

明記された状態（条件）で使用する資源の量に関係する性能の度合い

互換性（compatibility）

同じハードウェア環境又はソフトウェア環境を共有する間，製品，システム又は構成要素が他の製品，システム又は構成要素の情報を交換することができる度合い，及び／又はその要求された機能を実行することができる度合い

使用性（usability）

明示された利用状況において，有効性，効率性及び満足性をもって明示された目標を達成するために，明示された利用者が製品又はシステムを利用することができる度合い。

ソフトウェアの使用性を向上させる施策として，オンラインヘルプを充実させ，利用方法を理解しやすくする。

信頼性（reliability）

明示された時間帯で，明示された条件下に，システム，製品又は構成要素が明示された機能を実行する度合い。

信頼性を向上させる施策として，ファイルを分散して配置し，障害によるシステム停止のリスクを減らす。

セキュリティ（security）

人間又は他の製品若しくはシステムが，認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように，製品又はシステムが情報及びデータを保護する度合い

保守性（maintainability）

意図した保守者によって，製品又はシステムが修正することができる有効性及び効率性の度合い

移植性（portability）

一つのハードウェア，ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に，システム，製品又は構成要素を移すことができる有効性及び効率性の度合い

(10) ソフトウェア設計手法

① プロセス中心設計

② データ中心設計

DOA（Data Oriented Approach：データ中心アプローチ）

データ中心アプローチ（DOA : Data Oriented Approach）は，様々な要因により変更される可能性のある業務プロセスと比較して，データが安定した資源である事に注目して，データやデータ構造を中心に据えてシステム及びソフトウェアの設計を行う手法である。

データ中心アプローチは下図の手順で分析・設計を進める。

E-R 図

実体

関連

正規化

一事実一箇所

③ 構造化設計

(a) 機能分割と構造化

階層

段階的詳細化

複合設計

(b) 構造化設計の手法

順次

選択

繰返し

NS（Nassi-Shneiderman：ナッシシュナイダマン）図

HIPO（Hierarchy plus Input Process Output）

ブロック図

バブルチャート

階層構造図

イベントトレース図

ジャクソン法

ワーニエ法

(c) プログラムの構造化設計

品質特性

モジュール分割

④ オブジェクト指向設計

オブジェクト指向設計では，クラスライブラリを利用して，新規プログラムを開発する。

クラス

オブジェクト指向設計では，機能を詳細化する過程で，モジュールの独立性が高くなるようにプログラムを分割していく。オブジェクト指向において親クラスと子クラスの関係には、is-a（汎化－特化）関係と、part-of（集約－分解）関係がある。

is-a（汎化－特化）関係

「動物－犬」や「家電－テレビ」などのように「…は、○○である」で表される関係。

part-of（集約－分解）関係

「コンピュータ－CPU」や「自転車－サドル」などのように「…は、○○の一部である」で表される関係。

オブジェクトに共通する性質を定義したものがクラスであり，クラスを集めたものがクラスライブラリである。

ロバスト分析

オブジェクト指向開発におけるロバストネス分析で行うことは，ユースケースから抽出したクラスを，バウンダリクラス，コントロールクラス，エンティティクラスの三つに分類し，クラス間の関連を定義して図に表すことである。

(11) コンポーネントの設計

① コンポーネント分割の考え方

コンポーネント指向プログラミングでは，既存のプログラムを部品化し，それらの部品を組み合わせて，新規プログラムを開発する。

ファイルの統合

ファイルの分割

レコード処理

処理の周期

② プログラム分割基準

分かりやすさ

安全性

開発の生産性

運用性

処理能力

保守性

再利用性

(12) モジュールの設計

① 分割手法

STS（Source Transform Sink）分割

TR（Transaction：トランザクション）分割

共通機能分割

論理設計

領域設計

サブルーチン

再帰プログラム

② 分割基準

モジュールの制御領域

モジュールの影響領域

分割量

モジュール再分割

従属モジュール

機能的結束性

情報的結束性

データ結合

制御結合

③ モジュール仕様の作成

流れ図

PSD（Program Structure Diagram）

DSD（Design Structure Diagram）

SPD（Structured Programming Diagrams）

HCP（Hierarchical and Compact description）チャート

PAD（Problem Analysis Diagram）

決定表（デシジョンテーブル）

ワーニエ法

ジャクソン法

NS 図

論理構造図

プログラミングテーブル

(13) 部品化と再利用

コンポーネントウェア

ホワイトボックス型

ブラックボックス型

クラスライブラリ

デザインパターン

デザインパターンは，変更に強く問題が起きにくいプログラムを作成するために，クラス構造や機能をパターン化した「設計のひな形」である。オブジェクト指向におけるデザインパターンは，システムの構造や機能について，典型的な設計上の問題とその解決策を示し，再利用できるようにしたものである。

ストラテジパターン（Strategy パターン）は，アルゴリズムをクラスとして独立させたパターンである。アルゴリズムの切替えが簡単になり，システム戦略の変更に容易に対応できる。

レガシーラッピング

クラスライブラリ

オブジェクトに共通する性質を定義したものがクラスであり，クラスを集めたものがクラスライブラリである。

(14) アーキテクチャパターン

MVC モデル

MVC（model-view-control）は、対話型アプリケーションを、モデル、ビュー、コントローラという 3 つのコンポーネントに分割して設計・実装するアーキテクチャパターンである。

モデル層

そのアプリケーションが扱う領域のデータと手続きを表現する要素。多くのアプリケーションにおいてはデータベースの機能が、この層に該当する。

ビュー層

モデル層のデータを取り出してユーザが見るのに適した形で表示する要素。WebシステムではHTMLを生成して、動的にデータを表示するためのプログラムなどが、この層に該当する。

コントローラ層

ユーザの入力に対して応答し、それを処理する要素。受け取った入力に応じてモデル層やビュー層に処理を依頼する。

ソフトウェアアーキテクチャパターンのうち，仕様の追加や変更による影響が及ぶ範囲を限定できるようにするために，機能を業務ロジック，画面出力，それらの制御という，三つのコンポーネントに分ける。

(15) デザインパターン

デザインパターンとは、ソフトウェアの設計時に直面しがちな問題とその典型的な解決策を整理し、様々な場面で応用・再利用できる形にまとめたもの。

1995 年にオブジェクト指向プログラミングの分野で有名な「GoF」（Gang of Four：四人組）の通称で知られる研究者グループ、エーリヒ・ガンマ（Erich Gamma）氏、リチャード・ヘルム（Richard Helm）氏、ラルフ・ジョンソン（Ralph E. Johnson）氏、ジョン・ブリシディーズ（John M. Vlissides）氏による共著「オブジェクト指向における再利用のためのデザインパターン」（原題 “Design Patterns: Elements of Reusable Object-Oriented Software”）の中で 23 のパターンが紹介されたことを契機に広まった。

GoF のデザインパターンでは，生成，構造，振る舞いの三つのカテゴリから構成される 23 個のパターンをオブジェクト指向開発のためのパターンとして提唱している。

生成

• Abstract Factory：関連する一連のインスタンスを生成する
• Builder：インスタンスを組み合わせて生成する
• Factory Method：インスタンスを生成する
• Prototype：インスタンスをコピーする
• Singleton：インスタンスが単一であることを保証する

構造

• Adapter：2 つのクラスを接続するクラスを作る
• Bridge：実装へ橋渡しする
• Composite：再帰的な構造を実現する
• Decorator：動的に付加機能を追加する
• Facade：窓口となる共通のインタフェースを提供する
• Flyweight：多数のインスタンスを共有する
• Proxy：利用者からのアクセスを代理する

振舞い

• Chain of Responsibility：メッセージを連鎖的に送る
• Command：命令をクラスで表す
• Interpreter：構文解析の結果をツリー構造で表す
• Interator：オブジェクトに順番にアクセスする
• Mediator：オブジェクト間を仲介する
• Memento：状態を記録する
• Observer：状態の変化を監視する
• State：状態をクラスで表す
• Strategy：アルゴリズムを切替える
• Template Method：具体的な処理をサブクラスに任せる
• Visitor：クラスを訪問して処理を行う

(16) レビュー

レビュー（review）とは、再検討（する）、再考（する）、復習（する）、論評（する）、講評（する）、検査（する）、精査（する）、点検（する）、査察（する）、審査（する）、回顧（する）などの意味を持つ英単語。

① レビューの目的と手順

② レビューの対象と種類

プログラム設計レビュー

コードレビュー

テスト仕様レビュー

利用者マニュアルレビュー

デザインレビュー

インスペクション（Inspection）

インスペクションは、事前に役割を決められた参加者が責任のある第三者（モデレータ）の下で成果物を確認する、最も公式なレビュー技法である。通常 3 人から 6 人が参加して実施する。他のレビュー法との違いは、参加者の役割が明確になっていること、チェックリストなど形式的な文書に基づいて実施すること、正式な記録を強調することである。

インスペクションの参加者に割り振られる役割には，以下の 5 種類がある。

モデレータ（Moderator）

議長・司会としてインスペクション全体を運営する

オーナー（Owner）

レビュー対象となる成果物の作成者で、発見された問題に応じて成果物の修正を行う

インスペクタ（Inspector）

評価者としてレビュー対象となる成果物の問題発見を行う

プレゼンタ（Presenter）

ミーティングにて参加者に資料の説明を行う

スクライブ（Scribe）

書記としてレビューで発見された問題などを記録する

モデレータ

モデレータ（Moderator）は，議長・司会としてインスペクション全体を運営する

文書化手法

ウォークスルー

開発者が主体となりエラーの早期発見を目的としてプログラムのステップごとにシミュレーションを行いながら確認をしていくレビュー技法

共同レビュー

パスアラウンド

パスアラウンドは、電子メールなどを使って、対象の成果物を複数のレビュアに配布・回覧し、フィードバックを求めるレビュー技法

③ 妥当性評価の項目

機能

性能

容量・能力

信頼性

操作性

安定性

運用の容易性

技術的整合性

合目的性

実現可能性

開発の合理性

経済性

投資効果

④ その他の妥当性評価手法

ヒアリング

アンケート

チェックリスト

ソフトウェア構築

(1) ソフトウェア構築のタスク

コーディング

プログラム言語

プログラム書法

(2) ソフトウェアユニットの作成

セグメント化

アルゴリズム

データ処理

加工セグメント

構造化プログラミング

論理型プログラミング

並列処理プログラミング

(3) ソフトウェアコード及びテスト結果の評価基準

追跡可能性

外部一貫性

内部一貫性

テスト網羅性

コーディング方法及び作業標準の適切性

ソフトウェア結合及びテストの実現可能性

運用及び保守の実現可能性

(4) コーディング標準

インデンテーション

ネスト

命名規則

命名規則ではないが，コードを読みやすくするという意味では，以下の点も気にかけておきたい。

• 名前からデータの内容を類推できる
• 長すぎない，短すぎない
• ローマ字での命名は避ける
• 見た目に紛らわしくない
• 記法を統一する
• 予約語は利用しない

記法の統一には，次表のようなものがある。

PHP の世界では，変数／関数は camelCase 記法，定数は大文字のアンダースコア記法，クラスは Pascal 記法で表すのが一般的である。（出典）独習 PHP 第4版

記法を統一することで，記法そのものが識別子の役割を明確に表現してくれる。

使用禁止命令

(5) コーディング支援手法

コード補完

コードオーディタ

シンタックスハイライト

(6) コードレビュー

メトリクス計測

コードインスペクション

ピアコードレビュー

ピアレビュー（Peer Review）の「ピア（peer）」には同僚という意味があり、ドキュメントやコーディング作業が終了したソースコードに対して、作成者の同僚や研究仲間など立場の近いもの同士が実施しあうレビューのことを特にピアコードレビューという。成果物の品質や生産性の向上、及びチーム内での知識共有を促進することを目的として実施され、「欠陥の有無」や「コーディング規約の遵守」「仕様書の内容が反映されているか」などが検証される。

(7) デバック

デバック環境

静的解析

静的テストとは，プログラムを実行することなくテストする手法であり，コード検査，静的解析などがある。

動的テスト

ダイナミックテスタは，プログラムの動的な振る舞いを検証するための動的テストツールである。

アサーション

デバッガ

デバッガは，デバッグ作業においてバグの発見や訂正を支援するソフトウェアである。

(8) ソフトウェアユニットのテスト

① テストの目的

障害

欠陥

障害分析

② テストの手順

③ テストの実施と評価

デバッガ

ドライバ

スタブ

テストデータジェネレータ

テスト設計と管理手法（バグ曲線，エラー除去，バグ管理図）

欠陥密度の管理図を下図に示す。この図の縦軸は欠陥密度，横軸はユニット ID である。管理図分析では，しきい値モデルを使用し，データの分布が UCL（Upper Control Limit : 上部管理限界）と LCL（Lower Control Limit : 下部管理限界）に対して，どの位置にプロットされるかを見て，データが正常値であるか異常値であるかを判断する。

障害密度の実績値が基準値の下限に満たない機能について想定されることは，以下のとおり。

• 十分な品質が確保できている場合
• 十分なテストが行われていない場合（テストケースが不足している場合） → 障害を検出しきれていない場合

一方，テスト密度の実績値が基準値の範囲外となる機能については，テストケースに着目した適切な対応が行われたかどうかを確認する。

• テストケースの妥当性を確認する。
• テストケースの再レビューを行う。

バグ管理図は，検出したバグの累積数や未消化のテストの項目数をテスト時間に伴ってプロットしたグラフである。テストが順調に進んだ場合の予測に対し，実績をプロットすることで，テスト工程によって生じる様々な問題を把握することができる。

バグ管理図は，順調型，停滞型，見かけ上高品質型，低品質型，深刻型に分類される。

テスト自動化

④ テストの手法

メトリクス計測

テストケース

命令網羅

すべての命令を少なくとも1回は実行する。

条件網羅

判定条件が複数ある場合に、それぞれの条件が真・偽の場合を組み合わせたテストケースを設計する。

判定条件網羅（decision coverage）

判定条件の真偽を少なくとも1回は実行する。

複数条件網羅（multiple condition coverage）

判定条件のすべての可能な結果の組合せを網羅し、かつ、すべての命令を少なくとも1回は実行するようにテストケースを作成する。

経路組合せ網羅

網羅率

カバレージ

限界値分析法

データ範囲を「有効値」及び「有効値超過」「有効値未満」の 3 つに分割し、テストケースに有効範囲の上限値とそれを 1 つ上回る値、および下限値とそれを 1 つ下回る値を利用する手法である。

同値分析法

原因結果グラフ法

エラー埋込法

実験計画法

ソフトウェア結合・ソフトウェア適格性確認テスト

(1) ソフトウェア結合のタスク

テスト要件

テスト手順

テストデータ

(2) ソフトウェア適格性確認テストのタスク

ソフトウェア要件

監査

(3) ソフトウェア結合テスト

ソフトウェア結合テストのテスト手法には，代表的な方法として，結合するモジュールを徐々に増やしながらテストを行う増加テスト（ボトムアップテスト，トップダウンテスト，折衷テスト）と，すべてのモジュールを結合し，一度にテストを行う非増加テスト（ビッグバンテスト）がある。

増加テストは，大規模なシステムに適したテスト方法，一方，非増加テストは，小規模なシステムに適したテスト方法である。

テスト計画

テスト準備（テスト環境，テストデータなど）

ソフトウェア結合テスト報告書

トップダウンテスト

トップダウンテストは、結合テストのときに上位のモジュールから下位のモジュールへと順に結合しながらテストをしていく手法である。

ボトムアップテスト

ボトムアップテストは、結合テストのときに下位のモジュールから上位のモジュールへと順に結合しながらテストをしていく手法である。

ドライバ

ボトムアップテストで必要となるドライバは、未完成の上位モジュールに代わり、テスト対象の下位モジュールに適切な引数を与えて呼び出すなどの役割を担う。

スラブ

スタブは、モジュール結合テストの手法であるトップダウンテストにおいて必要となるテスト用のモジュールである。未完成の下位モジュールの代わりとして、テスト対象の上位モジュールからの呼び出しに対して、下位モジュールが返すべき適切な値を返却するなどの役割を担う。

テストベッド

結合テスト報告書

テスト結果の文書化

文書化基準

(4) ソフトウェア適格性確認テスト

機能テスト

非機能要件テスト

性能テスト

負荷テスト

システムがどこまでの負荷に耐えられるかを確認するテスト。一定時間システムを連続稼働させて安定稼働できるかどうかを確認するロングラン・テスト，単位時間あたりの処理件数を測定する高頻度テスト，データのサイズや量の限界を確認するボリューム・テスト，メモリやディスクなどを極端に少なくした状態での動作を確認するストレージ・テストなどがある。

セキュリティテスト

セキュリティ・ポリシーがシステムに正しく反映されていることを確認するテスト。チェック項目としては，外部からの不正アクセス，内部での権限／承認コントロール，情報の漏洩などがある。

回帰テスト（レグレッションテスト），退行テスト

回帰テスト（リグレッションテスト）は、情報システムに変更作業を実施した場合に、それによって以前まで正常に機能していた部分に不具合や影響が出ていないかを検証するテストである。

パフォーマンステスト

負荷を増した時，システムの挙動やボトルネックを確認するテスト。システムへの負荷のかけ方が負荷テストと同様であるため，負荷テストと合わせて実施されることが多い。

障害テスト

テストシステムの設計や要件で想定されている障害に対しての動作を確認するテスト。システムが正しく動作すること，意図しない動作や新たな障害が発生しないことなどを確認する。

構成テスト

システムのハードウェア，OS，ミドルウェア，データベース，通信ソフトウェアなどが設計仕様書通りか，それで問題ないか，仕様書から変更した場合にどのような影響が出るかを確認するテスト。

ソフトウェア適格性確認テスト報告書

(5) テスト結果の評価

① テスト実施後のタスク

② ソフトウェア結合の評価

追跡可能性

外部一貫性

内部一貫性

テスト網羅性

テスト標準及び方法の適切性

ソフトウェア適格性確認テストの実現可能性

運用及び保守の実現可能性

③ ソフトウェア適格性確認テストの評価

期待した結果に対する適合性

システム結合及びテストの実現可能性

システム結合・システム適格性確認テスト

(1) システム結合のタスク

ハードウェア構成品目

ソフトウェア構成品目

手作業

(2) システム適格性確認テストのタスク

システム要件

(3) システム結合テスト

システム結合テストでは，システムとして要求された機能や操作性，性能などに問題がないかを確認する。システム結合テストの種類を下表に示す。

テスト計画

テスト準備（テスト環境，テストデータなど）

システム結合テスト報告書

システム結合テストにおける開発チームに関する管理指標を次表のように定義して，遅延チームが発生する予兆の検知や，遅延チームの進捗遅れの影響を評価する。（出典）平成24年度 春期 プロジェクトマネージャ試験 午後Ⅰ 問題 問4 組込みシステム開発の結合テスト計画

• 管理指標 No. 4 で，開発チームの障害改修の作業品質を確認する。
• 管理指標 No. 3 で，開発チームが改修完了予定日を適切に設定しているか，当初設定した改修完了予定日を守れているかを評価する。
• 管理指標 No. 1，管理指標 No. 2，及び開発チーム別の今後に計画されている作業工数から，残障害見込数と改修能力のアンバランスを起因として遅延チームになりそうな開発チームがないかを監視する。管理指標 No. 2 と開発チーム別の今後に計画されている作業工数から求めた改修可能な障害数が，管理指標 No. 1 よりも少ない場合は，応援メンバの投入などの具体的な対策を実施する。

テスト結果の文書化

文書化基準

(4) システム適格性確認テスト

共通フレーム 2013 におけるシステム開発プロセスのアクティビティであるシステム適格性確認テストでは，システム要件について実装の適合性をテストし，システムの納入準備ができているかどうかを評価する。

テストの種類

回帰テスト（リグレッションテスト）

回帰テスト（リグレッションテスト）は，情報システムに変更作業を実施した場合，それによって以前まで正常に機能していた部分に不具合や影響が出ていないかを検証するテストである。退行テストともいう。

システム適格性確認テスト報告書

(5) テスト結果の評価

① テスト実施後のタスク

テスト実施後のタスク

② システム結合の評価

テスト網羅性

テスト方法及び作業標準の適切性

期待した結果への適合性

システム適格性確認テストの実現可能性

運用及び保守の実現可能性

レビュー

③ システム適格性確認テストの評価

テスト方法及び作業標準の適切性

導入

(1) システム又はソフトウェアの導入のタスク

(2) システム又はソフトウェアの導入計画の作成

導入要件

移行要件

導入可否判断基準

インストール計画の作成

導入作業

リプレース

並行稼働対応

導入文書

(3) システム又はソフトウェアの導入の実施

業務の効率向上や意思決定の迅速化などを目的に情報システムの導入を計画し，システム要件どおりに導入したが，活用が進まず，導入の目的を達成できない場合がある。活用が進まない原因として，例えば次のようなことが考えられる。

• 情報システムの機能を十分に活用するためのノウハウの共有が不十分で，利用者は一部の機能しか使っていない。
• 利用部門の管理者のリーダシップが足りないので，利用者に情報システムの利用を徹底できない。
• 正確なデータがタイムリに入力されないので，必要とする情報が必要なときに入手できない。

このような例では，活用を進めるための直接的な対策として，情報システム活用のノウハウに関するトレーニング，管理者の意識改革，データ入力チェックリストの制定などが挙げられる。

しかり，直接的な対策だけでは，活用が進まないことがある。多くの場合，幾つかの原因があって，それらの間に関連があったり，隠れた原因があったりする。したがって，IT ストラテジストは活用が進まない真の原因を分析し，有効な対策を検討する必要がある。その上で，実行手順・対象範囲・期間・体制などを明確にした情報システム活用の促進策を立案しなければならない。

導入手順

導入体制

利用部門

システム運用部門

(4) 利用者支援

受入れ支援

(1) システム又はソフトウェアの受入れ支援のタスク

納品

(2) システム又はソフトウェアの受入れレビューと受入れテスト

受入れ手順

受入れ基準

受入れテスト

受入れテストでは，業務担当者や情報システム担当者などが，システムの機能や性能を確認する。具体的には，通常の業務で行うのと同様にデータを入力し，「正しく業務が処理できているか」「操作性や運用面で問題がないか」「性能は十分か」「法律・安全基準・規制などの面で問題ないか」などをチェックする。

検収

受入テストで問題がないことが確認できれば，検収印をもらい，開発プロジェクトは終了となる。

検収基準

主に情報システム部門が機能，性能，保守性，ドキュメントなどをチェックする。

(3) システム又はソフトウェアの納入と受入れ

受入れ体制

(4) 教育訓練

教育訓練計画

教育訓練の準備

教育訓練体制

教育訓練結果の評価方法

新システムの受入れ支援において，利用者への教育訓練に対する教育効果の測定を，カークパトリックモデルの 4 段階評価を用いて行ことがある。

カークパトリックのモデルの 4 段階評価とは，反応，学習，行動，成果の 4 段階で教育や研修の効果を測定するモデルである。

レベル1　反応（Reaction）

教育・研修実施後のアンケートやヒアリングで，受講者の理解度や満足度を測定する。

レベル2　学習（Learning）

教育・研修当日から数日後にテストや試験を実施して，受験者の理解度や習得度合いを測定する。

レベル3　行動（Behavior）

教育・研修から 1 か月 ～ 1 年経過後に，本人または上司・同僚からのヒアリングやアンケートをして，受講者の行動変容を測定する。

レベル4　成果（Results）

教育・研修から一定期間経過後に，受講者が組織にどのような業績成果を与えたのかを，定量的な指標で測定する。

(5) 利用者マニュアル

運用規程

利用者マニュアル

システム利用文書

ソフトウェア利用文書

チュートリアル

保守・廃棄

(1) 保守のタスク

保守手順

保守体制

保守の実現可能性

保守テスト

回帰テスト（リグレッションテスト）

回帰テスト（リグレッションテスト）は，情報システムに変更作業を実施した場合，それによって以前まで正常に機能していた部分に不具合や影響が出ていないかを検証するテストである。退行テストともいう。

リバースエンジニアリング

リバースエンジニアリングは、既存ソフトウェアの動作やそのソースプログラムを解析するなどして、製品の仕組み、構造・構成技術等を調査し、そこから製造方法や動作原理、設計図、ソースコードなどの情報を得る手法である。

自社製品の保守及びセキュリティ強化などの目的で実施されるほか、他社製品の技術仕様を明らかにする目的でも行われる。

(2) 廃棄のタスク

組織の運用の完整性（integrity）

JIS X 0160:2021（ソフトウェアライフサイクルプロセス）によれば，廃棄プロセスのタスクのうち，アクティビティ "廃棄を確実化する" において実施すべきタスクにおいて，廃棄後の，人の健康，安全性，セキュリティ及び環境への有害な状況が識別されて対処されていることを確認する。

(3) 保守のタイプ及び形態

保守契約

保守要件の定義

ハードウェア保守

ツールレス保守は，ドライバや専用工具を用いることなく，障害が発生したハードウェアの部品を交換できるように設計する技術である。部品交換を迅速に行うことができ，MTTR を短くすることが期待される。

ソフトウェア保守

JIS X 0161 によれば，システムやソフトウェアに対する保守は，その目的により，"訂正" の性質をもつ「是正保守」「予防保守」，及び "改良" の性質をもつ「適応保守」「完全化保守」の 4 つのタイプに大別される。

是正保守

ソフトウェア製品の引渡し後に発見された問題を訂正するために行う受身の修正

予防保守

引渡し後のソフトウェア製品の潜在的な障害が運用障害になる前に発見し、是正を行うための修正

適応保守

引渡し後、変化した又は変化している環境において、ソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の修正。例えば，オペレーティングシステムの更新によって，既存のアプリケーションソフトウェアが正常に動作しなくなることが判明したので，正常に動作するように修正することは，適応保守となる。

完全化保守

引渡し後のソフトウェア製品の潜在的な障害が、故障として現れる前に、検出し訂正するための修正

ソフトウェアの保守で修正依頼を保守のタイプに分けると次表のようになる。また，次の図のように分類できる。

ソフトウェア保守は，運用開始後のソフトウェアに対して変更や機能改善への対応，プログラムの欠陥（バグ）への対応，ビジネス環境の変化に応じたプログラムの修正作業などを実施するプロセスである。

日常点検

是正保守

予防保守

故障の前兆となる現象を事前にとらえて，対象となる部品を取り替える。

適応保守

完全化保守

オンサイト保守

遠隔保守

異常が発生した場合，現場から離れた保守センタから障害状況を調査する。

ライフサイクルの評価

(4) 保守の手順

① 保守プロセス開始の準備

保守プロセスは，ソフトウェアを中心としたシステムの現状を，業務ならびに環境に適合するように維持，変更，管理する組織のアクティビティからなる。保守プロセスについては，ISO/IEC 12207 (JIS X 0160) で定義された保守プロセスの詳細企画 ISO/IEC 14764 (JIS X 0161) がある。

開発プロセスからの保守に必要な成果物の引継ぎ

計画及び手続きの作成

問題管理手続きの確立

修正作業の管理

プログラムの変更実施の結果の評価基準として，変更作業工数の予測値，障害発生率の目標率を定める。

保守のための文書作成

② 問題把握及び修正の分析

問題報告又は修正依頼の分析

問題の再現又は検証

修正実施の選択肢の用意

③ 修正の実施

修正するシステム又はソフトウェアや関連文書の決定

機能追加

性能改良

問題の是正

④ 保守レビュー及び／又は受入れ

修正されたシステム又はソフトウェアの完整性（integrity）

既存システム改修をソフトウェア要件定義アクティビティから始めるとき，最後に実行するアクティビティは，ソフトウェア適格性確認テストである。

⑤ 再発防止策の実施

システム信頼性のための解析技法（FTA，FMEA ほか）

故障の予防を目的とした解決手法である FMEA は，個々のシステム構成要素に起こり得る潜在的な故障モードを特定し，それらの影響度を評価する。

FMEA (Failure Mode and Effects Analysis) とは，製品や工程の信頼性を高め不具合を減らすための解析手法の一つで，構成要素に起こりうるトラブルの様式（故障モード）を列挙し，発生頻度や影響の範囲，大きさなどを評価して致命的なものを未然に対策すること。

⑥ 移行

移行計画の文書化と検証

関係者全員への移行計画などの通知

新旧環境の並行運用と旧環境の停止

関係者全員への移行の通知

移行結果の検証

移行評価

旧環境関連データの保持と安全性確保

(5) 廃棄

廃棄プロセスは，運用を終えたハードウェア，ソフトウェア製品及びサービスの破棄をするアクティビティからなる。

廃棄計画の立案

廃棄計画などの利用者への通知

新旧環境の並行運用と利用者の教育訓練

関係者全員への廃棄の通知

廃棄関連データの保持とアクセス可能性の確保

本稿の参考文献

• 共通フレーム 2013
• JIS X 0160 : 2012「ソフトウェアライフサイクルプロセス」
• JIS X 25010 : 2013「システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル」
• テクノロジックアート，「アジャイルソフトウェア開発技術シリーズ（基礎編） データベース」，東京電機大学出版局，2013年6月20日発行
• 要件定義～システム設計ができる人材になれる記事