【基本情報技術者】システム開発について

白川秋

6か月前

山場も超えて、12章に突入です。あとは消化試合でしょうか。どうだろか？

ともかくやってみよー！

本日も気合を入れていきますよ！！

基本情報技術者～システム開発～
最後に

基本情報技術者～システム開発～

システム開発技術

基本情報技術者試験では、「システム」と「ソフトウェア」、この2つの用語を明確に使い分けています。試験で効率よく合格するためにも、この2つの違いを明確にして覚えておきましょう。

システムとソフトウェア

システムは、ハードウェアとソフトウェアから構成されています。ソフトウェアはシステムの一部です。

ソフトウェアライフサイクルプロセス

ソフトウェアライフサイクルプロセス（Software Life Cycle Process；SLCP）とは、ソフトウェアの企画、要件定義、開発、運用、保守までの一連の活動のことです。ソフトウェアライフサイクルプロセスは国際規格であり、ISO/IECで標準化されています（ISO/IEC 12207）。

共通フレーム

共通フレームとは、システム開発に関わる人たちが、同じ言語で話ができるように、用語などの定義を統一した本のことです。

共通フレームと2つのSLCPの関係
上で説明したソフトウェアライフサイクルプロセス（ISO/IEC 12207）と、システムライフサイクルプロセス（ISO/IEC 15288）は、それぞれ「ソフトウェア」「システム」に関する規格です。しかし、システムはソフトウェアを含む概念であることから、内容がかぶる部分もでてきます。そこで、この2つの規格をまとめてできたのが共通フレームというわけです。

5つのプロセス

プロセス	説明
企画	経営目標を達成するために、システムに必要な要件を集め、計画を立てるプロセス。
要件定義	システムが持つべき機能や性能を決めるプロセス。
開発	実際にシステムを作成するプロセス。
運用	システムの本番への移行や、システムを安定的に稼働させるプロセス。
保守	不具合の修正やソフトウェアのアップデートなどを行うプロセス。

開発プロセス

システム開発とは、必要なハードウェアを調達し、必要な機能を持ったソフトウェアを新たに作ることです。これは、手作業で行っているような作業をシステムに置き換えることです。

開発プロセスの概要
ひとつ注意したいのが、ソフトウェアライフサイクルプロセスの「要件定義」と、ここで出てくる「システム要件定義」は別物です。

家づくりの場合	工程	説明
打合せ	システム要件定義	システムで実現したいことを決める工程。
設計	システム設計	システム要件定義で決めたことを実現するために、ハードウェアとソフトウェアの仕様や動作を決める工程。
建築作業	プログラミング	実際にソースコードを書く工程。
品質確認・検品	テスト	システムが仕様どおりに動くか確認する工程。

（※上は、ウォーターフォールモデルと呼ばれる開発モデルの例）

開発プロセスの詳細
開発プロセスをより詳細な工程に分割してみたのがこちらです。

ひとつ注意したいのが、ソフトウェアライフサイクルプロセスの「要件定義」と、ここで出てくる開発プロセスの「システム要件定義」と、「ソフトウェア要件定義」はすべて別物です。

システム要件定義

システム要件定義とは

システム要件定義とは、システムに必要な条件（システム要件）を決める工程です。簡単にいうと「どのようなシステムを作るのかを、開発会社と明確にするプロセス」です。

システム要件とは
システム要件定義では「システム要件」を決めます。システム要件とは、業務要件（日々の仕事を行うために必要な条件）のうちのシステムで実現する要件のことで、システムに必要な「機能」や「性能」のことを指します。

システムには求められる機能や性能がある
世の中のあらゆるシステムは、そのシステムに求められる機能や性能があります。そのため、開発プロセスの一番最初に、システム要件定義をして、「機能」や「性能」を決める必要があるのです。

システム設計

システム要件定義でどのようなシステムを作るかが決まったら、次はシステム設計です。システム設計のプロセスは、次の4つの工程に分割することができます。

　（１）システム方式設計
　（２）ソフトウェア要件定義
　（３）ソフトウェア方式設計
　（４）ソフトウェア詳細設計

（１）システム方式設計

システム方式設計とは、システム要件定義プロセスで洗い出したシステム要件を、「ハードウェア」「ソフトウェア」「手作業」のいずれかに振り分けるプロセスです。手作業に振り分けられたプロセスは、手作業で実現します（システムには実装しない）。

（２）ソフトウェア要件定義

ソフトウェア要件定義とは、ソフトウェアの要件（機能や性能）を決める工程です。（１）システム方式設計で「ソフトウェア」に振り分けられたシステム要件を、この工程で具体化していきます。

代表的なソフトウェア要件には次のようなものがあります。

・インターフェースの要件（画面、帳票、ファイルなど）
・データの要件（データの種類、データベースの要件など）

業務モデル
ソフトウェア要件定義では「業務モデル」を作成して、ソフトウェアに求められる機能と性能を定義します。業務モデルを記述する方法として、DFD（データフロー図）があります。

DFD（データフロー図）
DFD（Data Flow Diagram：データフロー図）とは、データの流れを表す図です。

記号	名前	説明
	外部	業務プロセスに入力されるデータの発生源を表す。業務プロセス外の「人」「組織」「システム」など。業務プロセスが加工したデータの行き先を表す。DFDでは必ず、「外部」からデータが入力され、「外部」へ出力される。
	データフロー	データの流れを表す。
	プロセス（処理）	プロセス（処理）を表す。「外部」「データストア」、もしくは別の処理からデータを受け取り、データを加工する。データの加工は必ずこの「処理」で行われる。
	データストア	データの保管を表す。通常はデータベースを表すが、稀に紙媒体のデータを表す場合もある。「データストア」はデータの加工は行わない。

DFDでは、必ず次の条件を満たす必要があります。

・2つ以上の「外部」（入力と出力）
・1つ以上の「プロセス」（プロセスがないと何もしていないことになるため）

（３）ソフトウェア方式設計

ソフトウェア方針設計とは、（２）ソフトウェア要件定義で決めたソフトウェア要件（機能や性能）をプログラムの単位まで細分化する工程です。ソフトウェア要件をどのようにプログラムで実現するかを決めます。また、ソフトウェアは「プロセス」と「データ」の2つの要素で構成されています。

プロセス中心アプローチ
プロセス中心アプローチとは、処理（プロセス）に着目してソフトウェアを設計する手法です。従来は、この手法が主流でした。しかし、保守が大変でした。そこで、データ中心アプローチという考え方が誕生しました。

データ中心アプローチ
データ中心アプローチとは、データ構造に着目してソフトウェアを設計する手法です。データは実世界に存在するもので、ユーザーの要求で変化するものではないため、ユーザーの要求と切り離して設計することができます。データ中心アプローチでは、E-R図や、DFDを使って表します。

（４）ソフトウェア詳細設計

ソフトウェア詳細設計とは、（３）ソフトウェア方式設計で「プログラムの単位まで分割された要件」を、さらに「コーディングできる単位」まで落とし込む工程です。
具体的には、動作ロジックを検討し、その結果を流れ図（フローチャート）にして表します。

モジュール結合度
モジュール結合度とは、モジュール間の結び付きの強さです。モジュール結合度が弱いほど、各モジュールの保守性は高く、モジュール結合道が強いほど、各モジュールの保守性は低くなります。
このため、モジュールを作成する場合は、モジュール結合度が弱くなるように設計する必要があります。

以下は、モジュール結合度を6つのレベルに分類した表です。モジュール結合度が最も弱いのは「データ結合」となっています。

種類	説明	結合度
データ結合	モジュール間で「データ」を引数として受け渡す。	弱 ↑ \| \| \| \| \| \| ↓ 強
スタンプ結合	モジュール間で「データ構造」を引数として受け渡す。
制御結合	モジュール間で「制御フローをコントロールするデータ」を引数として受け渡す。
外部結合	モジュール間で「単一のデータ型のグローバル変数」を共有する。
共通結合	モジュール間で「複数のデータ型のグローバル変数」を共有する。
内容結合	あるモジュールが別のモジュールの内部を直接参照する。

外部設計と内部設計

システム設計には4つの下位工程がありますが、この工程を別の分類で分けることもできます。それが、「外部設計」と「内部設計」です。

外部設計
外部設計とは、ユーザーから見える箇所の設計です。ユーザーの立場から見た業務機能を中心に設計します。

内部設計
内部設計とは、ユーザーから見えない箇所の設計です。

小休止！お試しトライ！過去問①

問1 モジュール結合度

問題
モジュール結合度が最も弱くなるものはどれか。

令和元年度

ア．一つのモジュールで、できるだけ多くの機能を実現する。
イ．二つのモジュール間で必要なデータ項目だけを引数として渡す。
ウ．他のモジュールとデータ項目を共有するためにグローバルな領域を使用する。
エ．他のモジュールを呼び出すときに、呼び出したモジュールの論理を制御するための引数を渡す。

解答
ア．から順に見ていきます。

ア．モジュール強度の説明です。
イ．データ結合の説明です。一番強度は弱いです。
ウ．外部結合の説明です。
エ．制御結合の説明です。

従って、解はイ．となります。

プログラミングとオブジェクト指向

オブジェクト指向

上で解説した「データ中心アプローチ」の概念をさらに進めたものが「オブジェクト指向」です。
オブジェクト指向とは、クラスや継承という概念を使って、ソフトウェアを部品化することで、ソフトウェア開発の生産性を上げる手法です。
なお、プロセス中心アプローチやデータ中心アプローチで「処理」と呼んでいたものを、オブジェクト指向では「メソッド」と呼びます。

クラスとオブジェクト
クラスとは、ひな型のことです。車に例えると、設計図にあたります。また、オブジェクト（インスタンス）とは、実体です。車に例えると、設計図をもとに製造された車にあたります。

データとメソッド
データとは、オブジェクトの状態のことです。車に例えると、車体の色や走行距離などにあたります。また、メソッドとは、オブジェクトの操作です。車に例えると、車も動かしたり、止めたりすることにあたります。

オブジェクト指向のメリット

車のように、同じ規格の製品を大量に作ったほうが効率が良いという考えを取り入れ、ソフトウェア開発に応用したのがオブジェクト指向です。

オブジェクト指向の特徴
オブジェクト指向でも、まずクラス（ひな型）を定義して、その定義に基づいたオブジェクト（実体）を生成します。クラスさえ1度作ってしまえば、いくつでもオブジェクトを生成することができます。
例えば、スマートフォンのアプリを作成するようなときに、ボタンが必要になったとします。このボタンをクラスで定義し、オブジェクトで生成します。
ボタンを一度定義してしまえば、ボタンごとに見た目の異なるボタンをカスタイマイズして作成することも可能となります。
これがオブジェクト指向でソフトウェア開発を行うメリットです。

オブジェクト指向の特徴

カプセル化
カプセル化とは、データ（オブジェクトの状態）とメソッド（オブジェクトの操作）を1つにまとめて、外部から直接データにアクセスできないようにすることを指します。
カプセル化のイメージとしては、データをメソッドで包み込む感じです。
車に例えると、車では「走行距離」というデータを直接変更することはできません。「走行距離」を変更するには、それをくるんでいるメソッド「走る」を呼び出して、データ「走行距離」を変更します。

継承
継承とは、親クラス（親のひな型）のデータ（オブジェクトの状態）やメソッド（オブジェクトの操作）を子クラス（子のひな型）が引き継ぐことを指します。
このことにより、データやメソッドを子クラスで再度実装する手間が省けます。
また、子クラスの共通の性質を取り出して、親クラスを作ることを「汎化」といい、その逆、親クラスの性質を細かく分けて、子クラスを作ることを「特化」といいます。

UML

UML（Unified Modeling Language）とは、オブジェクト指向のソフトウェア開発で、ソフトウェアの設計を図示するための表記法です。

図	説明
クラス図	クラス間の関係を表す。
オブジェクト図	オブジェクト（インスタンス）間の関係を表す。
アクティビティ図	ある振る舞いから次の振る舞いへの制御の流れを表す。
シーケンス図	オブジェクト間の相互作用を時系列に表す。

小休止！お試しトライ！過去問②

問1 継承

問題
オブジェクト指向において、あるクラスの属性や機能がサブクラスで利用できることを何というか。

平成30年度

ア．オーバーライド　　　　　イ．カプセル化
ウ．継承　　　　　　　　　　エ．多相性

解答
単純に、オブジェクト指向のところで習ったのは、カプセル化と継承です。
そして、問題文の説明と一致するのは、継承です。

従って、解はウ．となります。

問2 カプセル化

問題
オブジェクト指向におけるカプセル化を説明したものはどれか。

平成28年度

ア．同じ性質をもつ複数のオブジェエクトを抽象化して、整理すること
イ．基底クラスの性質を派生クラスに受け継がせること
ウ．クラス間に共通する性質を抽出し、基底クラスを作ること
エ．データとそれを操作する手続を一つのオブジェクトにして、データと手続の詳細をオブジェ
　　クトの外部から隠蔽すること。

解答
カプセル化を表すキーワードとして、外部からの隠蔽というワードが挙げられます。

従って、解はエ．となります。

テスト

テストとは

テストとは、システムが仕様通りに動くかを確認するための工程です。テストを行うことで、不具合を見つけ、不具合を潰していきます。また、それと同時に、要件定義プロセスで明確にした「業務に必要な条件（業務要件）」がきちんと実装されているかを確認します。

設計・開発工程とテスト工程は1対1の関係にある
要件定義と運用テスト、外部設計とシステムテスト、内部設計と結合テスト、プログラミングと単体テストというように、設計・開発工程とテスト工程は1対1の関係にあります。下図を見ていただくとその関係がわかりやすいかと思います。

種類	説明	担当者
単体テスト	プログラムに誤りがないかを検証する。通常、「ホワイトボックステスト」でテストする。	開発者
結合テスト	単体テストが完了したプログラム同士を組み合わせ、データの受け渡し、連携がうまくいっているかを検証する。通常、「ブラックボックステスト」でテストする。	開発者
システムテスト	システムの要件通りに動作するかを検証する。	開発者
運用テスト	本番環境と同じ条件下でシステムを運用し、業務要件通りにシステムが動くかを検証する。	ユーザー
リグレッションテスト	システムに修正や機能追加をしたときに、別のところで新しいバグが出ていないかを検証する。	開発者

インターフェースとは
インターフェースとは、あるモノとあるモノをつなぐ部分のことです。例として、ハードウェアインターフェースがあります。ハードウェアインターフェースとは、あるハードウェアと別のハードウェアをつなぐ部分（接続部分）のことを指します。
プログラムとプログラムをつなぐインターフェースを、「ソフトウェアインターフェース」と呼びます。結合テストでは、単体テストが完了したプログラム間のインターフェースをテストします。

ホワイトボックステスト

通常、単体テストで「ホワイトボックステスト」が行われます。ホワイトボックステストでは、プログラムの内部構造まで見て、プログラムに記述されているすべての処理を実行し、動作を確認します。

テストケース
テストケースとは、ソフトウェアをテストする際に用意する「入力」と「期待される出力」の組み合わせです。ホワイトボックステストでは、フローチャートに記載されているすべての経路を網羅するようにテストケースが組まれます。
しかし、すべての経路を網羅するというのは現実的ではありません。そこで重要となるのが、網羅性（網羅の程度）です。ホワイトボックステストでは、以下の5つの網羅性のレベルに基づいてテストケースが設計されます。

　　（１）命令網羅
　　（２）判定条件網羅（分岐網羅）
　　（３）条件網羅
　　（４）判定条件／条件網羅
　　（５）複数条件網羅

流れ図の記号の読み方

テストケースの数を算出するには、流れ図を正しく読める必要があります。

名称	説明
判定条件（もしくは分岐）	ひし形の中に記載する。下図の例では「X>0 かつ Y>0」が判定条件。
条件	ひし形の中に記載する。下図の例では「X>0」と「Y>0」の2つが条件。
命令	長方形の中に記載する。下図の例では「3→X」が命令。

（１）命令網羅

命令網羅とは、すべての「命令」を少なくとも1回は実行するテストです。「判定条件」は考慮せず、5つの網羅性テストの中で最も網羅性が低いテストになります。

（２）判定条件網羅（分岐網羅）

判定条件網羅（分岐網羅）とは、プログラム中のすべての「判定条件」で、真と偽の両方を少なくとも1回は実行するテストです。判定条件の真と偽を1回ずつ通るようなテストになります。

（３）条件網羅

条件網羅とは、判定条件が複数の条件からなる場合に、それぞれの条件の真と偽の両方を少なくとも1回は実行するようなテストです。ここまで来ると見えてきたと思いますが、（１）が網羅性が低く、（５）に向かうほど網羅性の高いテストとなっています。

（４）判定条件／条件網羅

判定条件／条件網羅とは、判定条件網羅と条件網羅を組み合わせたテストです。テストケースは、3つとなります。

（５）複数条件網羅

複数条件網羅とは、すべての条件の真と偽の組み合わせを少なくとも1回は実行するテストです。これが一番手間がかかり、めんどくさいテストとなります。

ホワイトボックステストの問題では、流れ図が提示され、各網羅性のテストケースの数を問う問題がよく出題されます。

ブラックボックステスト

結合テストとシステムテストでは「ブラックボックステスト」が行われます。
ブラックボックステストとは、入力と出力だけに注目し、ある入力に対して期待通りの出力が得られるかをテストします。

各テストのメリットとデメリット

種類	メリット	デメリット
ホワイトボックステスト	すべての処理（分岐経路）を検証できる。	プログラマの誤解による不具合（バグ）は見つけられない。
ブラックボックステスト	仕様通りの動作をするかを検証できる。	すべての処理をテストしないので、珍しい不具合（バグ）が残る可能性がある。

トップダウンテストとボトムアップテスト

結合テストには、ブラックボックステストの他にも、トップダウンテストやボトムアップテストといったものがあります。これらを扱った設問では、「モジュール」という用語が登場します。

モジュール
モジュールとは、プログラムを機能で分けた単位です。モジュールは、上位モジュールと下位モジュールに分類されます。
呼び出し元のモジュールを「上位モジュール」といい、呼び出し先のモジュールを「下位モジュール」といいます。プログラムの開始時に最初に呼び出されるモジュールを「最上位モジュール」と呼びます。

トップダウンテスト
トップダウンテストとは、上位モジュールから順に下位モジュールへとテストを行う方法です。上位モジュールから1つ下位のモジュールを呼び出し、呼び出したモジュールから更に下位のモジュールを呼び出すという方法でテストを行います。
このとき、下位モジュールが未完成のときはどうするかといいますと、「スタブ」と呼ばれるダミーの下位モジュールを作成してテストを行います。

ボトムアップテスト
ボトムアップテストとは、下位モジュールから順に上位モジュールへとテストを行う方法です。1つ上のモジュールから下位モジュールを呼び出し、1つ上のモジュールから更に上のモジュールから先ほど呼び出しに使った1つ上のモジュールを呼び出すという方法でテストを行います。
このとき、上位モジュールが未完成のときはどうするかといいますと、「ドライバ」と呼ばれるダミーの上位モジュールを作成してテストを行います。