第四章 システム開発の基礎
４．１ システム開発の概要
□システム開発工程の概要
◇情報処理システムとシステム開発
情報処理：各種の組織体（会社、学校、団体など）において、その目的を達成するために行う情報の収集、加工、蓄積、伝達のこと。
情報処理システム：人間やコンピュータによる情報処理の仕組みのこと。
システム開発：情報処理システムを設計、作成し、稼動させるまでの作業工程のこと。
◇システム開発工程の概要
システム開発工程は、図４−１のような６つの段階から構成される。
| 基本計画 |
| ↓ |
| 外部設計 |
| ↓ |
| 内部設計 |
| ↓ |
| プログラム設計 |
| ↓ |
| プログラミング |
| ↓ |
| テスト |
なお、システム開発の工程の分類の仕方や名前は、現実には、上記のものと違うことが多い。
図４−１の分類の仕方や名前は、「高度情報化人材育成標準カリキュラム」に沿っている。
基本計画：ユーザの要求（システムに求めること、システムに備えておくべき機能、満たすべき条件など）を明確に定義する段階である。
外部設計：コンピュータから見て、外側部分（ユーザとのインタフェースをとる部分）の設計をする段階である。
基本計画の段階で作成された要求仕様書をもとに、
・システムのもつべき機能を確定し
・どのようなシステムにするかの概要を設計する
ため、概要設計とよばれることもある。
なお、外部設計の目的はユーザからの了承を得ることなので、コンピュータ内部の技術的部分は、基本的に考えなくてよい。
内部設計：情報システムの内部（ハードウェアや基本ソフトウェアに依存する部分）の設計をする段階である。
外部設計の段階で作成された外部設計書をもとに、
・システム構築上必要となる機能をプログラムに分割し
・プログラム間の処理の流れを明確にし
・プログラムを作成できるレベルまでシステム内部を詳細に設計する
ため、詳細設計とよばれることもある。
なお、内部設計の目的は、プログラマに対して、プログラムの要件を示すことである。
プログラム設計：前段階で作成した内部設計書をもとに、各プログラム内の構造設計を行い、モジュール（最小翻訳単位）に分解し、モジュール間のインタフェースを決める段階である。
プログラミング：プログラム設計段階で作成したプログラム設計書をもとに、アルゴリズムを考え、コーディングを行い、その後、単体テストを行う段階である。
テスト：前段階で作成した複数のプログラムを結合し、テストを行い、さらに、システム全体を通してのテストを行う段階である。
□ソフトウェア工学
◇ソフトウェア工学（software engineering）
・ソフトウェア工学の出現背景
ＬＳＩ技術の進歩によって、ハードウェアのコストパフォーマンス（価格性能比）が急速に向上した。
しかし、それに比べると、ソフトウェア開発技術は進歩が遅い。
また、要求されるシステムの規模は大きくなり、長時間の開発期間が必要になってきた。
このため、開発・運用を管理し、効果的に運用するための技術・道具が必要なってきた。
・ソフトウェア工学のもとになった考え方
自動車、テレビ、エアコンなどのハードウェアの製品をつくる際には、正しく動き、費用を安く、納期どおりにつくるために、工学的な考え方や技術を取り入れている。
ソフトウェアもハードウェアと同じように１つの製品であると考え、この工学的な技術を用いれば、質のいい製品を提供できるはずである。
・ソフトウェア工学とは
ソフトウェア工学とは、ソフトウェアの開発過程やライフサイクル全般に対して用いられている工学的アプローチで、ソフトウェア製品の組織的設計、開発および開発管理のための手法や技術全般のことである。
・ソフトウェアのライフサイクル（life cycle）
ソフトウェアが世に誕生してから死に至るまでの過程のこと。
一般に、ソフトウェアは、まずその必要性が明示、モデル化され、実現・テストを経て運用される。
その後、保守・運用が繰り返される。
・ソフトウェア工学の目的
次のような条件を満足するようなソフトウェアを製作するための技術を、確立することである。
・仕様を満足し、信頼がおける
・予定された費用内で完成させることができる
・納期を守れる
□システム開発の手法
システム開発の手法は、現在多くのものが提唱されている。
それには、基本的な開発モデルであるウォータフォールモデル、またウォータフォールモデルの欠陥を補うものとして考えられたプロトタイプモデルやスパイラルモデルがある。
◇ウォータフォールモデル（waterfall model）
ソフトウェアのライフサイクルの各段階（工程）をモデル化して表現したものの１つ。
ある工程における出力（成果物）が、次の工程の入力となり、さらにその工程における出力が、次の工程への入力となり、・・・というように反復される様子を滝（waterfall）になぞらえて表している。
原則として、基本計画からテストまで、滝の水のように、逆流することなく開発を進める。
現在、最も多く採用されている基本的な開発モデルである（図４−２）。
このウォータフォールモデルに対し、次のような批判がなされている。
（１）要求仕様の変更が、それ以下の全段階へ反映されてしまう。
（２）あとのほうの段階で生じた不都合を修正するための見直しが大きくなってしまう。
（３）エンドユーザとアナリスト間のコミュニケーションギャップが未解決である。
（４）ユーザ要求の変化への対応がしにくい。
こうした欠陥を補うものとして、プロトタイプモデルといった開発手法が提案されている。
◇プロトタイプモデル（prototype model）
prototypeとは、「原型、模範、試作品」の意味。
システム開発の初期の段階（プログラム設計以前の段階）で、そのシステムの機能の一部やユーザインタフェースなどを試作し、エンドユーザや設計担当者がこれを吟味、評価することによって、システムの仕様や条件を確認することである。
これによって、開発者とユーザとの認識の差、あいまいさを取り除ける。
プロトタイプモデルを用いてシステム開発することを、プロトタイピングという。
・プロトタイプモデルのメリット
要求仕様のもれやエンドユーザの潜在ニーズを早期に確認できる。
これによって、システム完成後の修正を減少させることができる。
◇スパイラルモデル（spiral model）
spiralとは、「螺旋」の意味。
ウォータフォールモデルとプロトタイプモデルの両方の手法を取り入れたモデルである。
開発の初期段階で独立性の高い部分単位に分けられる場合に、その部分単位ごとに、設計、プログラミング、テストを、順次繰り返していく手法である。
この繰返しが、「螺旋」のようなので、この名前がある。
・スパイラルモデルのメリット
大規模な開発を行う場合に、その時々でマンパワー（人間）を投入できるので規模を抑制できる。
４．２ 基本計画
□基本計画の構成
基本計画は、次の３種類からなる。
・システム化計画
・プロジェクト実行計画
・要求定義
◇システム化計画
目的：組織（会社、学校、団体など）のニーズに合った情報システム導入のための計画を作成すること。
成果物：システム化計画書
作業内容：
@現状の問題点を調査し、分析する（←問題点があるから、それを解消するために、情報システムを導入するのである）
A現状と理想との差を埋めるための解決策を検討し、その実現性を分析する（←本当に実現できるのか？ 実現できたとして、その効果が費用に見合ったものなのか？）
◇プロジェクト実行計画
目的：プロジェクト実施の決定にともない、実行計画を作成する。
成果物：開発計画書
作業内容：
@開発に使用するハードウェアの決定
A開発工数、開発コストの見積もり
B開発プロジェクトの体制作成
C開発スケジュールの作成
◇要求定義
目的：システム化の目的を明確にし、そのためには何があればよいか、何ができればよいかを分析、定義すること。
成果物：要求仕様書
作業内容：
@機能・性能、運用要件をはじめ、システム全体に対する要求を定義する
Aハードウェアおよびソフトウェアに対する要求を明確にする
Bシステムを適用する分野がどのような仕事をするのかを明確にする
Cどのような情報が必要なのかを明確にする
Dどのような事象（状態が変化すること）が発生するのかを明確にする
４．３ 外部設計
□外部設計とは
◇外部設計
外部設計は、ユーザから見たシステムとのインタフェースに相当する部分を決める段階である。
つまり、コンピュータの内部機能と切り離した、コンピュータの外側（外部）から見たシステムの機能を設計する段階である。
外部設計は、特定のコンピュータのハードウェアやソフトウェアとは独立している。
このことは、ある外部設計の結果が別のコンピュータに適用することも可能になることを意味している。
成果物：外部設計書と外部設計レビュー報告書
作業内容：
@要求仕様の確認
Aサブシステムの定義と展開
B画面設計、報告書設計
Cコード設計
D論理データ設計
E外部設計書作成とレビュー
以下、外部設計の作業について述べる。
□要求仕様の確認
◇要求仕様の確認
・前提
前段階の基本計画で要求仕様書が作成されている。
・「要求仕様の確認」の必要性
開発者がユーザの希望を正確に理解するのは、簡単なことではない。
この要求仕様の確認を怠ると、ユーザが希望していたものとは異なるものができてしまい、そのシステム開発は失敗となってしまう。
このようなことが起こらないように、ユーザと開発者の間で、要求仕様を十分に確認しておく必要がある。
・「要求仕様の確認」の作業内容
このシステムにふくめなければならないユーザの要求を明確にする。
具体的には、システムの目的、システムの体系、ユーザの要件の確認を行う。
高品質のシステムを、
・納期どおりに稼動させ
・その後の保守（メンテナンス）をスムーズに行う
ために重要な段階である。
・「要求仕様の確認」後の作業
要求仕様の確認後、次のことを行う。
・新システムの新業務フロー図を作成する
・要求を処理ごとにまとめる
・業務フロー
情報システムの責任者やユーザ部門に対して、運用方法を中心に図や表を用いて表現したもの。
□サブシステムの定義と展開
◇サブシステム（subsystem）
システムは、階層構造になっている。
あるシステムから見た下位のシステムをサブシステムという。
図４−３のシステムは、サブシステムＡからサブシステムＺで構成されている。
システムが目的としている仕事を、サブシステムＡからサブシステムＺまでが協同して、あるいは分担して行う。
「要求仕様の確認」で作成した業務フロー図を各処理の記述から、システム開発の運用上の効率/効果を考え、システムをいくつかのサブシステムに分割する。
□画面設計・報告書設計
入出力情報を具体的な形でユーザに提供するための設計として、画面設計・報告書設計がある。
◇画面設計と報告書設計
ユーザの立場から見たシステムの定義、つまりユーザとのインタフェースを中心としたシステム設計である。
ヒューマンインタフェースを意識して作成する必要がある。
・ヒューマンインタフェース
人間がコンピュータを使う際の仲立ちの役割をする仕組み、考え方のこと。
マンマシンインタフェースともいう。
・画面設計・報告書設計で注意すべき点
画面設計・報告書設計をする際に、注意しなければならないことは、ユーザにとって使いやすい（ヒューマンインタフェースのよい）画面・報告書をつくるように心がけることである。
ユーザにとって使いにくい画面設計だと、ユーザが間違ったデータを入力してしまったり、どのようなデータを入力したらよいのかを考えてしまったりして、生産性が落ちてしまう。
システムの開発者は、つい、つくりやすいシステムをつくりがちである。
しかし、誰のためのシステムなのかを常に頭に入れて、画面設計・報告書設計をする必要がある。
□コード設計
◇コード（code）
コンピュータは、情報を２進符号としてしか扱えない。
情報をコンピュータで処理するためには、一度、２進符号化しなければならない。
その、符号化された情報がコードである。
コンピュータで効率よく処理を行うために、情報の符号化をいかに適切に行うかが、重要である。
◇コード化の必要性と機能
・個々のデータの区別
社員には、ユニークな社員コードがふられている。
この理由の１つは、社内に同姓同名の社員がいたときに区別できるようにするためである。
・データの標準化・簡素化
社員名を漢字で入力するよりも、社員コードを入力したほうが簡単なので、間違いを起こしにくくなる。
・データを管理しやすくする
社員コードを見れば、その社員の入社年がわかるようにすることもできる。
◇コードのチェック方法
コードのチェック方法の代表的なものとして、チェックディジット法がある。
・チェックディジット法
コード番号に対してある計算を施した検査用の数字（チェックディジット）を、コードに付加する。
この数字をチェックすることで、入力データの誤りを見つけることができる。
例１）５けたの数字データを入力する。
ただし、最後の１けたは、チェックディジットとする。
先頭から４けたの数字の総和を、１０で割った余りをチェックディジットとする。
入力データ：２ ５ １ ７ ５
↓ ↓ ↓ ↓
２＋５＋１＋７＝１５
１５÷１０＝１ 余り ５
このチェック法の欠点は、例のデータでいえば、「２５１７５」と入力すべきところを、「２５７１５」としても、エラーにならないことである（このように、数字列の順番を間違えて入力してしまうことは多い）。
このような欠点を改良したチェック法を次に紹介する。
例２）５けたの数字データを入力する。
ただし、最後の１けたは、チェックディジットとする。
上位１けた目の数値には４を、２けた目の数値には３を、３けた目の数値には２を、４けた目の数値には１を掛けたあとに、総和を求め、その総和を１０で割った余りをチェックディジットとする。
入力データ：２ ５ １ ７ ２
× × × ×
４ ３ ２ １
↓ ↓ ↓ ↓
８＋15＋2+7＝３２
３２÷１０＝３ 余り ２
□論理データ設計
システムは、基本的に、入力データを加工して出力データを生成する。
このため、システム設計で必ず行わなければならないのが、そのシステムで用いるデータの設計である。
これは、論理データ設計と物理データ設計とに分けて考える。
なお、物理データ設計は、次の段階の内部設計で行う。
◇論理データ設計とは
システム内に格納するデータのデータ構造と、主要ファイルのデータ項目を決定する作業。
論理データ設計とは、本来あるべきデータの姿を表すもので、物理的制限を考慮しないものである。
ここで、物理的制限とは、ディスク容量、データの件数、通信回線のデータ転送速度などである。
論理データ設計の実作業は、次のとおりである。
・データ項目の洗い出し
・データの関連性の分析
・ファイル候補の決定
□外部設計書作成とレビュー
◇外部設計書作成
外部設計を文書にし、ユーザのシステム要件を機能中心にまとめた文書を外部設計書という。
◇外部設計レビュー
外部設計レビューは、外部設計書などのドキュメントの内容を見直して、検証し、設計結果の妥当性、正当正を確かめる。
このように、作業結果は必ず、レビュー工程で確認する。
そのレビュー結果も必ず文書としてまとめる。
４．４ 内部設計
□内部設計とは
◇内部設計
外部設計段階で作成したシステムの外部設計を、使用機種や使用言語、システムの最適化の観点から、コンピュータシステム上で実現するための、より詳細な設計を行う段階である。
コンピュータ側またはシステム側から見たシステムの定義ということになる。
要求される機能を、プログラムの側面から、
・どのように機能分割・階層構造化するか
・プログラム間の処理の流れをどのようにするか
・ファイルやデータベースの物理構造や内容はどのようにするか
などを決定し、文書化する。
成果物：内部設計書と内部設計レビュー報告書
作業内容：
@機能分割・構造化
A物理データ設計
B入出力詳細設計
C内部設計レビュー
以下、内部設計の作業内容について述べる。
□機能分割・構造化
外部設計では、システムを複数のサブシステムに機能分割した。
内部設計では、コンピュータ処理を念頭に、外部設計でブラックボックスとなっていた部分をより具体的にどのようにするかを考える。
◇機能分割・構造化とは
外部設計で定義された機能を、正確かつ効率よく実現するための処理方式を設計する。
プログラム全体を一気につくるのではなく、段階を追って順に、全体を小さな機能単位に分割して設計を進める。
・機能分割、構造化のメリット
機能単位に分割すると、考える範囲が狭まり、１つの機能に絞って考えることができるので、非常に理解しやすくなる。
このような構造化設計の考えから、階層構造的なモジュール分割と、モジュール間の関連をまとめたモジュール階層構造図を作成する。
・モジュール（Module）化
一般に、プログラムは機能単位に分割され、その単位で作成される。
また、このモジュールは、次の性質をもつ。
・固有の名前をもつ
・独立にコンパイル（あるいはアセンブル）できる
・ほかの複数のモジュールから呼び出されて使用されるものがある
モジュール間の関連（結合度）は弱いほどよいとされている。
その理由は、あるモジュールを変更してもほかのモジュールの動作に影響を及ぼさず、システム全体の信頼性や保守性の低下をまねかないためである。
結合度が弱い場合、モジュール間のデータはすべて引数としてのみ引き渡す。
モジュールが互いのデータを直接参照したりするのは、結合度の強い例である。
上手にモジュール化されたプログラムは、機能単位に分割された比較的短いモジュールから構成されており、ほかの人が見ても理解しやすい。
・分割、構造化のためのポイント
処理のタイミング：月次処理、日次処理などで分ける。
ファイルの共通性：同一ファイルを使用するプログラム群は、なるべく同じブロックとする。
保守のしやすさ、わかりやすさ：プログラム構造図を見ただけで処理内容がわかるように分割・構造化する。
その他、次のような点も考慮する。
・システムダウン時のリカバリのしやすさ
・並行処理の効率
・ハードウェア資源の使用効率
□物理データ設計
◇物理データ設計とは
論理データ設計で決めたファイルのデータ項目の使われ方から、ファイルの使用率、データの増加率などを検討し、ファイルの編成方法とレコードレイアウトを決める作業。
◇物理データ設計作成時の考慮ポイント
・データ特性
以下のような点を分析し、明確にする。
・現在のデータ量、これからのデータの増加率
・データの追加・削除・変更の比率
・更新処理の発生頻度（月次、日次、随時など）
・リアルタイム処理か、バッチ処理か
・一時的なデータか、保存すべきデータか
・トランザクションの発生頻度（ピーク時、平均）
・処理形態（シーケンシャル、ランダム）
・処理タイプ（参照のみタイプ、更新タイプ）
・ファイル媒体の決定
データの特性によって、
・磁気ディスク
・磁気テープ
・フロッピーディスク
などのファイルを格納する媒体を決定する。
・レコードレイアウトの決定
データの特性によって、
・レコード内のデータ項目の表現形式（文字、数字など）
・レコード内のデータ項目の大きさ（けた数）
・レコードの配置
を設計する。
また、将来の拡張に備えて予備項目が必要かを考える。
・ファイル編成方式の決定
以下の点を考慮して、ファイル編成を決定する。
・処理形態
・処理速度
・オペレーティングシステムの機能
□入出力詳細設計
◇入出力詳細設計
外部設計で行った画面設計・報告書設計をもとに、ハードウェアの制約などを考慮して、より詳細な仕様を作成する。
原票設計：日常使用している原票の様式を、そのまま画面に置き換えたものが、ユーザにとっては違和感なく使いやすい。
帳票設計：コンピュータで出力できる様式に整え、スペーシングチャート上に設計する。
このとき、内容項目の配置、けた数、編集（右詰め、左詰め、ゼロ抑制など）についても決定する。
画面設計：外部設計の段階では、どのような画面が必要か、どのような画面が相互に関連して使用されるかを検討した。
内部設計の画面設計では、すべての画面について具体的な項目の画面フォーマット、フィールド属性や対話の形態などを設計する。
画面フォーマット・・・画面レイアウト用紙に、出力位置、けた数編集形式を詳細に記入する。
フィールド属性・・・色・輝度指定、点滅・反転指定、拡大文字指定
対話の形態・・・ヘルプ画面、メニュー画面
入力チェック：入力データを正しく保つために、入力データ全項目に渡って考えられるエラーの種類を想定してチェックを行い、エラーデータの修正および救済方法を考える。
メッセージ設計：システムで共通のメッセージを決める。
メッセージは、ユーザの操作性を高める重要な要素である。
４．５ プログラム設計とプログラミング
□プログラム設計とプログラミングとは
◇プログラム設計
前段階で作成した内部設計書に基づいて、すべてのプログラムの構造設計を行う。
つまり、プログラムをいくつかのモジュール（最小翻訳単位）に分割し、モジュール間インタフェースを決定する。
成果物：
・プログラム設計書
・結合テスト計画書
・プログラム設計レビュー報告書
作業内容：
@プログラム構造化設計
Aプログラムのテストケースの設定
Bプログラム設計レビュー
◇プログラミング
プログラミングの作業は、次の「モジュール設計」「単体テスト計画」「コーディングと単体テスト」からなる。
（１）モジュール設計
成果物：
・モジュール設計書
・モジュール設計レビュー報告書
作業内容：すべてのモジュールをさらに基本制御構造に分割する。
（２）単体テスト計画
成果物：単体テスト計画書
作業内容：
@テストデータの作成
Aテスト日程の作成
（３）コーディングと単体テスト
成果物：
・原始（ソース）プログラムリスト
・単体テスト報告書
作業内容：
@すべてのモジュールのコーディング
A単体テスト
□プログラムの構造化設計
プログラムの構造化設計とは、次の作業を行うことである。
・プログラムを構成するすべてのモジュールを定義する
・定義されたモジュール間の階層構造を定義する
・各モジュール間のインタフェースを定義する
◇構造化設計の基本概念
・プログラム設計の問題点
プログラムが大きくなると、全体を同時に考えることが難しくなる。
このため、思考範囲を狭めるため、小さなプログラムに分割したほうが、プログラム作成が簡単になる。
しかし、無意味に分割してしまうと、逆に、複雑さを増加させ、わかりづらいものとなってしまう。
・よい分割の仕方の指針
・１つのモジュール内では、１つの機能を行う
・適切な大きさに分割する（開発言語によって異なるが、高水準言語で１モジュールが３００〜５００ステートメント程度が適当）
・複数のモジュールに共通の機能を分散・重複させない（適切階層構造にする）
・独立性
各モジュールが機能的にまとまっていて（モジュール強度が強い）、それぞれのモジュールの関連が単純（モジュール結合度が弱い）になるように分割する。
・階層構造化
１つのモジュールから呼び出す従属モジュールの数を制限し、階層もあまり深くならないよう（システムの大小によって異なるが、せいぜい５階層）にする。
□分割技法
◇代表的な分割技法
・源泉/変換/吸収分割（ＳＴＳ分割：Source
/ Transform / Sinkdecomposition）
データの流れに沿って、実行すべき機能を入力処理、変換処理、出力処理の機能に分割していく（図４−４）。
・トランザクション分割（transactional decomposition）
入力トランザクションの種類によって処理機能が異なるような場合に、入力トランザクションの種類ごとに分割する方法。
ＳＴＳ分割で分割された変換部分を、さらに細かく分割するときに用いるとよい。
・共通機能分割（functional decomposition）
システム全体に、共通として必要になる機能を洗い出し、共通機能として定義する方法。
ＳＴＳ分割やトランザクション分割で定義された各モジュールを、さらに詳細に分析し、共通機能を洗い出し、共用できるモジュールを取り出す。
・ジャクソン法
ジャクソンが提唱した手法である。
プログラムは、入力データ構造を出力データ構造に変換するもの、と考えられる。
ジャクソン法は、プログラムの構造は、入力データ構造と出力データ構造から決まるという考え方から成り立っている。
データ構造に着目した分割技法である。
□モジュール設計
モジュールの論理設計の最大の主眼は、論理を構造化することである。
そのためには、基本３構造（順次、選択、繰返し）で論理を組み立て、論理の中でＧＯ ＴＯ文がとびかうことがないようにする。
◇モジュール設計
・段落的詳細化
まず、細部にこだわらず、大まかに全体をいくつかの部分に分ける。
分けた部分をまたいくつかの部分に分ける。
このように、次第により細かいレベルを表現していく方法。
・基本３構造（図４−５参照）
（１）順次型（SEQUENCE型）
（２）選択型（IF THEN ELSE型）
（３）繰返し型（DO WHILE型）
なお、基本３構造を応用したものに、追加構造（DO
UNTIL型、CASE型）といわれるものがある（図４−６）。
・構造化定理
１つの入り口と、１つの出口をもつように設計されていれば、どのようなプログラムの論理でも、基本３構造の組合せで記述できる。
・構造化プログラミング
基本３構造だけを使って、プログラムを作成すること。
基本３構造だけを使うので、自然とGO TO文がなくなる。
このため、GO TO LESSともよばれる。
４．６ テスト
□テストの種類
プログラムは、（残念なことに）必ずといってよいほどエラーをふくんでいる。
それを取り除き、信頼性を向上させるには、テストを行わなければならない。
◇プログラムテスト（program test）
プログラムには、必ず仕様があるはずである。
作成したプログラムが、その仕様どおり動作するかについて検査することを、プログラムテストという。
プログラムの品質や信頼性を向上させるために、そのプログラムは誤りをふくんでいるという仮定のもと、誤りを発見するつもりでプログラムを実行させたり、調べたりする。
プログラムテストには、単体テスト、結合テスト、システムテストなどがある。
・単体テスト（モジュールテスト）
単体テストとは、個々のモジュールの動作を検査するものである。
そのモジュールを作成したプログラマが実施することが多い。
作業内容としては、テストのほかに次のようなものがある。
・テストデータの作成
・テスト日程の作成
単体テストの必要性：
複雑なソフトウェアをすべて組み合わせてからテストしたのでは、エラーが見つかった場合、その原因がどこにあるのかを探すのはたいへんである。
そのため、組み合わせる前に単体（モジュール）ごとにテストをしておく必要がある。
単体テストの成果物：単体テスト報告書
・結合テスト
結合テストは、単体テストを終えたモジュールを結合し、プログラムが機能仕様どおり正しく動作することを確認するためのテストである。
主として、単体テストではチェックできなかったテストやモジュール間のインタフェースが適切か否かを検査する。
モジュールを組み合わせてプログラム全体になるまでテストする。
テストの実施はテスト専任の者が行うことが多い。
結合テストの成果物：結合テスト報告書
結合テストには、各モジュールの結合順序や時期に応じて、次のような種類がある。
トップダウンテスト（top down test）：
プログラムのモジュール構造の上位のものからテストをしていくやり方を、トップダウンテストという（図４−８、図４−９）。
この場合、スタブ（stab）を用意する必要がある。
なお、スタブとは、上位モジュールのテストのために用いられる下位モジュールの役割をシミュレートするテスト用モジュールである。
テストされる上位モジュールから呼び出されたら、引数などの正当性をチェックし、適当な処理結果をテストモジュールへもどしてやる。
ボトムアップテスト（bottom up test）：
モジュール構造の下位のものからテストすることを、ボトムアップテストという（図４−８、図４−９）。
ドライバ（driver）を用意する必要がある。
なお、ドライバとは、下位モジュールをテストするときに上位モジュールの役割をシミュレートするテスト用モジュールである。
必要な引数をセットし、テストされる下位モジュールを呼び出し、テストされる下位モジュールの処理結果を表示したりする。
ブラックボックステスト：
ユーザから見た機能に従い、テストケースを決める方法。
プログラムの内部構造を意識しないテストである。
ホワイトボックステスト：
プログラムの内部構造に従ってテストケースを決める方法。
内部構造を意識するので、ブラックボックスに対してホワイトボックスという。
・システムテスト（総合テスト）
システムテストは、テスト済みのプログラムを組み合わせて、プログラム間のインタフェースが適切かどうかをテストする。
作業内容としては、次のようなものがある。
・システムの機能が正しく使えるかどうかのテスト
・操作性はどうかのテスト
・例外事項テスト（ほとんど起こらない例外処理のテスト）
・障害テスト（わざと障害を起こすテスト）
・処理速度テスト（レスポンスタイムをチェックするテスト）
システムテストの成果物：システムテスト報告書
・運用テスト
運用テストとは、本番稼動と同一のシステム環境と、データを使用し、実際に業務でそのシステムを使用する人がテストを行う。
運用テストの必要性：
ひととおりのテストが終了し、システムが完成しても、いきなり本番稼動するのは、たいへん危険である。
というのも、開発者が行ったテストは、どうしても実際の運用上の細かい使い方などのチェックが甘くなりがちだからである。
運用テストの成果物：運用テスト報告書
□デバッグの種類
◇デバッグ
プログラム作成のすべての段階で、プログラムの誤り（バグ：bug）を発見し、修正することをデバッグという。
プログラムの内部構造を作成している段階、またコーディングの段階で誤りがないように作業を進めるのが基本である。
誤りをおかす場合があっても、なるべく初期の段階でバグを発見するほうが修正の手間がかからない。
したがって、初期の机上デバッグは重要である。
・机上デバッグ
アルゴリズムやコーディングを机上（マシンを使わず）で検査し、バグを発見し、修正すること。
・マシンデバッグ
コンピュータ（マシン）を用いて行うデバッグをマシンデバッグという。
メモリダンプや、スナップショットダンプ、トレーサなどコンピュータ上に用意されたユーティリティを使用してデバッグを行う。
４．７ 入力データのチェック方法
入力データのチェックに、よく用いられる方法は次のとおり。
◇照合チェック
入力データを他のファイルのデータと突き合わせ、同じ値かどうかを検査する。
◇シーケンスチェック（sequence check）
入力データのシーケンス（順番）が、合っているかの検査。
◇チェックディジットチェック（check digit
check）
データの末尾に、検査用の数字（check digit）を付加し、データそのものに検査機能をもたせる方法。
◇ニューメリックチェック（numeric check）
入力データが数値（ニューメリック）であるかの検査。
◇フォーマットチェック（format check）
入力データが指定された書式（フォーマット）であるかの検査。
◇リミットチェック（limit check）
入力データが指定された限界内（リミット）であるかの検査。
レンジ（range：範囲内）チェックということもある。
４．８ オブジェクト指向
最近は、システム設計もプログラミングもオブジェクト指向で行うことが増えてきている。
このオブジェクト指向は、従来の方法と何が違うのであろうか？
□オブジェクトとは
オブジェクト指向は、データと処理を一体化（カプセル化）して扱う手法である。
従来のプログラムでは、データと処理を別々に扱っていた。
しかし、データと処理を一体化させておいたほうが、便利なことが多いとわかってきた。
オブジェクト指向を使用した例をあげると、パソコン上のソフトウェアがある。
パソコン上のソフトウェアの多くには、「ボタン」といわれているものがある。
「ボタン」は、どの位置に、どのくらいの大きさで、色は何色で、フォントが何で・・・というデータをもつ。
また、「ボタン」は、クリックされるとある処理が実行される。
つまり、この「ボタン」は、データと処理をもっているのでオブジェクトであるといえる。
「ボタン」を押すことにより、ある処理を実行するというメッセージがアプリケーションやオペレーティングシステムに伝えられる。
上の図では、「ボタン」が複数ある。
それぞれの「ボタン」は、大きさや位置などが異なる。
それぞれの「ボタン」がインスタンスである。
さて、「ボタン」とは、どのようなものだろうか？
この「ボタン」がどのようなものかを定義しているものが、クラスである。
◇オブジェクト（Object）
データと処理（メソッド、振る舞い）を一体化（カプセル化）させたもの。
◇クラス（Class）
共通の性質をもつものどうしをまとめたもの。
雛形のこと。
◇インスタンス（Instance）
クラス（＝雛形、枠組み）から、生成されたもの。
◇メッセージ（Message）
外部からオブジェクトに対し、その処理を実行させるための唯一の方法。
◇スーパークラス/サブクラス
スーパークラス：あるクラスの上位クラス。
サブクラス：あるクラスの下位クラス。
◇継承（インヘリタンス：Inheritance）
スーパークラスの性質を引き継ぐこと。
◇多様性（ポリモフィズム：Polymorphism）
複数の異なるオブジェクトに対し、同じメッセージを送ると、それぞれのオブジェクトが固有の処理を実行すること。