システム開発技術

目次

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

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

• システム要件定義
• 設計
• 実装・構築
• 統合・テスト
• 導入・受入れ支援
• 保守・廃棄
• 本稿の参考文献

システム要件定義

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

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

(2) システムの境界の定義

① システムの境界の定義の目的

② システム化の目標と対象範囲

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

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

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

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

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

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

② 機能及び能力の定義

システム機能仕様

レスポンスタイム

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

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

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

スループット

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

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

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

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

性能要件

データベース要件

テスト要件

セキュリティ要件

移行要件

運用要件

運用手順

運用形態

保守要件

可用性

障害対応

教育

訓練

費用

保守の形態

保守のタイミング

CRUD マトリクス

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

④ その他の要件

実行環境要件

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

品質要件

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

機能要件

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

非機能要件

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

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

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

可用性

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

性能・拡張性

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

運用・保守性

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

移行性

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

セキュリティ

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

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

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

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

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

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

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

追跡可能性

一貫性

テスト可能性

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

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

レビュー参加者

レビュー方式

システム要件のレビューには，次表に示すようなものがある。

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

(6) ソフトウェアの境界及び要件の定義

① ソフトウェアの境界及び要件の定義の目的

② ソフトウェアの機能仕様とそのインタフェースの仕様の識別

③ 業務モデルとデータモデルの識別

④ セキュリティ要件の識別

⑤ 保守性の考慮

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

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

① ヒアリング

② ユースケース

アクタ

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

ユースケース図

ユースケース図は、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 モデル」を図示したもの。データベースの設計などでよく用いられる。

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

⑥ UML

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

クラス図

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

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

⑦ ユーザーストーリー

⑧ その他の手法

設計

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

(2) システム設計

① システム設計の目的

ハードウェア構成品目

ソフトウェア構成品目

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

手作業

機能要件（functional requirement）

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

非機能要件（non-functional requirement）

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

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

③ ハードウェア構成の決定

④ ソフトウェア構成の決定

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

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

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

⑤ システム処理方式の決定

⑥ データベース方式の決定

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

関係データベース（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) アーキテクチャ及びシステム要素の評価及びレビュー

(5) ソフトウェア設計のタスク

(6) ソフトウェア設計

① ソフトウェア設計

物理データ設計

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

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

② インタフェース設計

③ ソフトウェアユニットのテストの設計

ホワイトボックステスト

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

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

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

④ ソフトウェア統合テストの設計

ブラックボックステスト

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

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

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

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

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

(8) ソフトウェア品質

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)

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

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

① 利用時の品質モデル

② 製品品質モデル

機能適合性（functional suitability）

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

性能効率性（performance efficiency）

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

互換性（compatibility）

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

使用性（usability）

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

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

信頼性（reliability）

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

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

セキュリティ（security）

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

保守性（maintainability）

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

移植性（portability）

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

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

① プロセス中心設計

② データ中心設計

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

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

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

③ 構造化設計

(a) 機能分割と構造化

(b) 構造化設計の手法

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

モジュール分割

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

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

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

暗合的強度（最も弱い）

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

論理的強度

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

時間的強度

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

手順的強度

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

連絡的強度

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

情報的強度

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

機能的強度（最も強い）

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

④ オブジェクト指向設計

クラス

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

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

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

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

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

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

汎化

オブジェクト指向における汎化では，幾つかのクラスに共通する性質をもつクラスを定義する。

ロバスト分析

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

⑤ ドメイン駆動設計（DDD）

(10) ソフトウェア要素の設計

① ソフトウェア要素分割の考え方

② プログラム分割基準

モジュールの設計

① 分割手法

② 分割基準

③ モジュール仕様の作成

(12) 部品化と再利用

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

MVC モデル

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

モデル層

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

ビュー層

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

コントローラ層

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

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

(14) デザインパターン

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

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：クラスを訪問して処理を行う

(15) レビュー

① レビューの目的と手順

② レビューの対象と種類

③ 妥当性評価の項目

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

実装・構築

(1) 実装・構築のタスク

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

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

(4) コーディング標準

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

(6) コードレビュー

(7) デバック

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

① テストの目的

② テストの手順

③ テストの実施と評価

④ テストの手法

統合・テスト

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

(2) ソフトウェア検証テストのタスク

(3) ソフトウェア統合

(4) ソフトウェア統合テスト

(5) ソフトウェア検証テスト

(6) ソフトウェア統合及びソフトウェア検証テスト結果の評価

① テスト実施後のタスク

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

③ ソフトウェア検証テストの評価

(7) システム統合のタスク

(8) システム検証テストのタスク

(9) システム統合

(10) システム統合テスト

(11) システム検証テスト

(12) システム統合及びシステム検証テスト結果の評価

① テスト実施後のタスク

② システム統合の評価

③ システム検証テストの評価

導入・受入れ支援

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

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

(3) 妥当性確認テストのタスク

(4) 導入

① システム及び／又はソフトウェアの導入計画の作成

② システム及び／又はソフトウェアの導入の実施

③ 利用者支援

(5) 受入れ支援

① システム及び／又はソフトウェアの受入れレビューとテスト

② システム及び／又はソフトウェアの納入と受入れ

③ 教育訓練

カークパトリックの教育効果の 4 段階モデル

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

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

レベル1　反応（Reaction）

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

レベル2　学習（Learning）

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

レベル3　行動（Behavior）

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

レベル4　成果（Results）

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

④ 利用者用文書類（利用者マニュアル）

(6) 妥当性確認テスト

① 妥当性確認テストの実施

② 妥当性確認テストの結果の管理

③ 妥当性確認テストの手法又は技法

保守・廃棄

(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日発行
• 要件定義～システム設計ができる人材になれる記事