あらけす屋＞情報処理技術者試験
午前問題対策（システム開発）
システム設計/プログラミング/テスト
システム設計
- ソフトウェア開発ライフサイクル( SDLC ； Software
Development Life Cycle )
- 顧客ニーズの把握
- 機能仕様の確定
- 対象物の詳細仕様の確定
- 行程計画・資源計画の策定
- 製造作業性能テスト・手直し
- 顧客への引き渡し
- 運用・保守
- ソフトウェアライフサイクル
- ベースライン
ソフトウェアライフサイクルにおいて、成果物の構成管理をするための基準となる構成要素の集合
- システムの運用・管理の観点から、システムのライフサイクルの終わりと判断するには不適切なもの
不正なアクセス、プログラムやデータの破壊、パスワードの盗難などが起きるようになってきた
- 外部設計
データ項目を洗い出して論理データ構造を決定する
- 入力画面の設計方針
画面上に説明が多いと煩雑に感じるので、説明が必要な入力項目についてはヘルプ機能を用意し、画面は簡素にする
- GUI画面の設計において、キーボード操作に慣れているユーザと、慣れていないユーザのどちらにも、操作効率の良いユーザインタフェースを実現するための留意点
使用頻度の高い操作に対しては、マウスとキーボードの両方のインタフェースを用意する
- アプリケーションが表示するエラーメッセージを設計するときの留意事項
利用者が何をすべきかを、簡潔かつ正確に表示する
- システム開発工程の外部設計局面で行う作業
- システムで使用するデータの識別や分類・配列を容易にするためのコードの設計
-
帳票設計
-
論理データ設計：データ項目の洗い出しとデータ構造の決定
- 内部設計
物理データ構造、データの処理方式やチェック方式などを決定する
- コード設計
- コード化対象の選定：コード設計の作業の中で、最初に行う作業
-
検査文字を採用する目的 ：コードの入力誤りや読取り誤りを検出する
- コードの入力ミスが業務に重大な影響を及ぼすと判断されるときは、入力したコードの値の誤りを検出するために検査文字（チェックディジットなど）を採用する
- 開発スタイル・手法
- プロトタイピング（プロトタイプモデル）
- システム開発の初期段階で試作品を作成して、ユーザ部門と開発部門との認識のずれや曖昧さを取り除き、利用者の要求を明確にすることによって、仕様を評価・確定し開発を推進する
- スパイラルモデル
- 要求分析から実装までの開発プロセスを繰り返しながら、システムを構築していくソフトウェア開発手法
- 大規模なアプリケーションを開発するときに、システムを独立性の高いサブシステムに分割して、設計、設計、プログラミング、テストの開発工程を反復しながらリスク分析を行い、開発機能の規模を拡大し、完成度を高めていく開発手法
-
開発コストなどによってリスクを評価しながら開発するので、リスクが最小となる
- ウォータフォールモデル
- 開発を上流から下流に一方向に進めるモデル
-
要求分析から設計、プログラミング、テストへと前フェーズの成果物を元に開発を進め、原則として後戻りを認めない
-
システム開発を工程順に進めるので、後戻りすればシステムの開発効率が著しく低下する
- 開発効率を高めるには、各工程内でのレビューやテストによって品質を確保し、前の工程への逆戻りが起こらないようにする
- 上流工程で作り込まれた誤りが後工程まで検出できずに残る危険がある
- 内部設計、プログラミング、単体テストなどの各工程の中で、並行作業を可能とするために開発要員を追加することで開発期間の短縮に効果が期待できる
- 成長モデル（インクリメンタルモデル）
-
最初にシステム全体の要求定義を行い、要求された機能を幾つかに分割して
分析→設計→製造→テストという開発行程を繰り返し、継続的にバージョンアップを施し、徐々に機能を追加していくプロセスモデル
-
段階的にリリースするので、すべての機能がそろっていなくても、最初のリリースからシステムの動作確認をすることができる
- ラウンドトリップ
オブジェクト指向開発において、分析と設計、プログラミングを何度か行き来しながらトライアンドエラーで完成させていく手法
- RAD(Rapid Application Development)
-
早期にアプリケーションを開発するための手法
-
プロトタイプを多用することで設計期間を短縮する
-
ライフサイクルの無制限な繰り返しを防ぐため、タイムボックスと呼ばれる一定の開発期間を設定する
- エクストリームプログラミング
ユーザー要求や仕様の変更リスクを軽減するために、顧客や開発者間のコミュニケーションを重視し、コーディングとテスト、リファクタリング（コードの書き直し）に重点を置いて、短期間のリリースを繰り返して開発を進めていくソフトウェア開発方法論
- リファクタリング
プログラムの外部仕様を変えずに、内部構造を分かりやすいものに変更すること
- リバースエンジニアリング
ソフトウェアの再利用技術
既存のプログラムを解析し、プログラムの仕様と設計の情報を取り出す手法
過去に作成されたソフトウェアの保守のときに利用される
- コンカレントエンジニアリング
既存のプログラムやファイルを解析して仕様書を作成し、これを参考にして同等の機能をもったプログラムやファイルを作成する開発手法
- エキスパートシステムの開発アプローチ
専門家と同等の知識をあらかじめ準備することが困難であるため、一般に進化型のアプローチをとる
進化型のアプローチ：部分的に定義された要求から開発を開始し、後続するいくつかの開発で要求を見直していく
- デザインパターン
度々発生する設計上の課題を解決するために繰り返し用いる、オブジェクトやクラスの構造を記述したもの
- ソフトウェアの再利用
再利用可能な部品の開発は、同一規模の通常のソフトウェアを開発する場合よりも工数、コストがかかる
- データ中心アプローチ
- データ資源の重複だけでなく、それに起因するプロセスの重複も排除することを目的としている
- データを共有資源と見なし、その一貫性や完全性維持を重視して資源側からソフトウェアを規定する、という考え方に基づく
- データ中心アプローチによる開発手順
- データモデリング
- データベース設計
- 標準プロセスの設計
- カプセル化
- 応用プログラム設計
- 開発資源
- 開発工数
- ハードウェア資源
- ソフトウェア資源
- 直接労務費
- 直接材料費
- 直接経費
- 間接経費
- 工数見積もり
- 経験値による見積もり
- 類似法
- 過去の類似システム開発の経験を元にして見積もる
- 経験豊富なメンバが必要
- 3点見積もり
- システムやモジュールの規模を推定する
- 最大値、最小値、最尤値（さいゆうち；もっとも確からしい値、最頻値とも）の加重平均により見積もる
- 見積値 = （ 最小値 ＋ 最尤値 x 4 + 最大値 ) / 6
- トップダウン見積もり
全体規模を見積もり、各サブシステムに所要開発量を割り振る
- ボトムアップ見積もり（標準値法）
開発システムを機能分割してサブシステムを決め、サブシステムごとの規模を推定し、これらを積み上げて全体規模や工数を推定する
- モデル化による工数見積もり
- Putnamモデル
レイリー分布に基づく予測式モデルにより時間の変化に応じて変化する必要工数を数式化する
- ファンクションポイント法
-
外部入出力や画面数、内部論理ファイルの数と開発の難易度から、システムの開発規模を見積もる方法
-
開発ソフトウェアの入出力数を用いて見積もる
-
開発工数を算出するためには実績データの収集や評価が必要になる
- COCOMOモデル
-
ソフトウェアの規模を入力変数として、コスト誘因とそれに対する計数を考慮しながら開発工数を計算してコストを見積もる
-
自社における生産性のデータ収集が不可欠
- COCOMOIIモデル
- COCOMOモデルの改良モデル
- ファンクションポイントによる規模見積もりを取り入れている
- レビュー
- ラウンドロビン
レビューに参加したメンバが持ち回りでレビューの責任者を務めながら、全体のレビューを遂行していく
参加者全員がそれぞれの分担について、レビュー責任者を務めながらレビューを行うので、参加者全員の参加意欲が高まる
- ウォークスルー
設計上の誤りを早期に発見することを目的として、各設計の終了時点で作成者と複数の関係者が設計書をレビューする方法
入力データの値を仮定してコードを追跡するように、手続きをステップごとにシミュレーションすることによってレビューを行う
プログラマの主催によって複数の関係者が集まり、プログラムリストを追跡し、プログラムのエラーを探す
- インスペクション
あらかじめ参加者の役割を決め、いくつかの選ばれた局面に注意を払い、迅速にレビュー対象を評価する
- デザインレビュー
実施のねらい：仕様の不備や設計の誤りなどを早期に発見し、手戻り工数の削減を図る
- 生産性
- 工程別の生産性が次のとき、全体の生産性を表す式
設計工程：Xステップ/人月
製造工程：Yステップ/人月
試験工程：Zステップ/人月
1/( 1/X + 1/Y + 1/Z )
- 広義のソフトウェア生産性
= ソフトウェア価値 / 作業工数
= ユーザニーズ適合性 x
狭義のソフトウェア生産性
- ユーザニーズ適合性
= ソフトウェア価値 / ソフトウェア生産量
- 狭義のソフトウェア生産性
= ソフトウェア生産量 / 作業工数
= ソフトウェア生産量 / ソフトウェア新製作量 x
ソフトウェア新製作量 / 作業工数
= 増幅効率 x 開発作業効率
-
開発工程の早期に欠陥が発見できれば、欠陥の修正に要する工数は少なくて済み生産性は高まる
- システムの移行
- 開発から運用への移行
システムの開発部門と運用部門が別々に組織化されているとき、開発から運用への移行を円滑かつ効果的に進めるためには、システム開発に運用部門からも積極的に参加し、運用性の観点から支援する
- ソフトウェア利用者向けマニュアルで、チュートリアル（導入手引）に記載すべき内容
ソフトウェアを使うために知っておくべき基本的な考え方と操作手順を、例題などを使って一通り説明する
- システム開発においてシステム運用部門が果たすべき役割
運用しやすいシステム作りや、本稼動へのスムーズな移行のために、システムの設計段階からプロジェクトに参加して運用ドキュメントの標準化を進める
プログラミング
- プログラム方式
- インタプリタ方式
原始プログラムを1命令ずつ解釈して実行するプログラム
プログラムの部分的な翻訳と実行を反復して行うことが容易
コンパイラ方式に比べ、プログラムの実行速度は遅い
- コンパイラ方式
最適化：プログラムコードを解析して実行時の処理効率を高め、実行時間を短縮できるオブジェクトコードを生成する
定数の畳込み：オブジェクトコードの所要記憶容量が削減できる
- 動的リンキング
プログラムを構成するモジュールの結合を、プログラムの実行時に行う方式
- クロスコンパイラ
あるコンピュータを使って、そのコンピュータとは異なる命令形式を持つコンピュータで実行できる目的プログラムを生成するための言語処理プログラム
- プログラミング言語
- Java
- インターネットや分散システム環境で利用されている、オブジェクト指向のプログラム言語
- Javaコンパイラがソースコードをバイトコードに変換し、Java仮想マシンがバイトコードを実行する
-
Javaコンパイラで翻訳したコードは、Java固有のバイトコードである
-
多重継承はできない（単一継承）
-
マルチスレッド機能が含まれている
-
プリプロセッサを持たない
- メモリ管理は自動的に行われ、メモリのガーベジコレクションの機能が働く
- Java Beans
Javaのプログラムにおいて、よく使われる機能などを部品化し、再利用できるようにコンポーネント化するための仕様
- EJB（Enterprise Java Beans）
オブジェクト指向によるシステムで利用される分析から設計、実装、テストまでを統一した表記法
サーバでの実行を前提とした基幹業務を意識したオブジェクト指向開発によるコンポーネントソフトウェアをJavaで構築するためのコンポーネント規約の仕様
- JSP ( Java Server Pages )
- プログラミング言語Javaで処理を記述する
- サーバサイドでServletのコードに翻訳されて実行される
- HTML文書にコードを記述する
- ブラウザで動作するアプレットなどを作成できる
- Javaアプレット
Javaで作成されたプログラムであって、Webサーバからダウンロードされ、ブラウザ上で実行されるもの
仮想マシンを実装した環境上であれば、どこでも実行できる
- Javaサーブレット(Java Servlet)
J2EE(Java2 Platform,Enterprise Edition)の構成技術の一つ
Web環境での動的処理を実現するプログラムであって、Webサーバだけで動作する
一度ロードされるとサーバに常駐し、スレッドとして実行されるWebコンポーネント
- JavaScript
HTMLファイル内に直接プログラムを記述し、ブラウザで実行する
- C言語（プログラム言語C）
高水準言語であるが、システムの細部までを記述でき、その成り立ちからシステム記述言語として位置づけられることが多い
- C++
多重継承が可能
マルチスレッド機能が含まれていない
プリプロセッサを持つ
- Prolog
述語論理を基盤とする言語
ユニフィケーションとバックトラックを使ってデータベースを探索する
- BASIC
初心者向きの対話型汎用言語
- Lisp
対話型言語の性格を持った関数型言語
集合演算や行列演算に特徴があるので、普及当初は科学技術計算向きとされた
- PostScript言語
主にプリンタ用に使用されるページ記述言語
- 論理型プログラミング
プログラムに”事実”と”規則”を記述し、プログラム言語の処理系が持つ導出原理によって結論を得るプログラミングパラダイムであって、エキスパートシステムの開発に適している
- データ中心設計法におけるカプセル化の特徴
データとその操作の実装がカプセル内に閉じ込められるので、カプセルの利用者と提供者を明確に切り分けることができる
- オブジェクト指向
クラス階層を導く手法として、汎化／特化、集約化／分解、グループ化などの抽象化操作がある
データは外部から隠蔽され、メソッドと呼ばれる手続によって間接的に操作される。プログラムは、データとメソッドをひとまとまりにしたものの集まりである。
継承という概念によって、モデルの拡張や変更の際に変更部分を局所化できる
- オブジェクト指向の特徴
- 汎化
下位クラスに共通する内容を抽出して上位クラスに定義すること
- 継承（インヘリタンス）
オブジェクト指向の概念で、上位のクラス(基底クラス)のデータやメソッドを下位のクラスで再利用できる性質
あるクラスの下にサブクラスを定義するとき、上のクラスで定義されたデータ構造と手続きをサブクラスで引き継いで使うことができる
後で下位のクラスを追加するとき、その上位クラスを利用して書かれた業務プログラムにメソッドを追加するだけでよく、再利用できる部分が多い
- インスタンス
クラスの定義に基づいてインスタンスが生成される
- ホワイトボックス型（開かれた）再利用
基底クラスに対してサブクラスを作ることによって、基底クラスのデータや機能を再利用すること
基底クラスで定義したデータや機能に対する差異をサブクラスに記述すればよく、開発効率が良い
- ブラックボックス型再利用
汎用的に作成されたクラス（コンポーネント）をそのまま利用する形態
- 抽象データ型
データとそれに対する操作を一体化して定義したものであり、データへのアクセスは定義された操作を用いて行う
- カプセル化
データとそれを操作する手続きを一つにして、オブジェクトの内部に隠蔽すること
オブジェクトの内部データ構造やメソッドの実装を変更しても、その影響を他のオブジェクトに及ぼしにくい
- 多様性（ポリモルフィズム）
同一メッセージを各オブジェクトに送っても、オブジェクトによって動作が異なるので、メッセージを受け取るオブジェクトの種類が増えても、メッセージを送るオブジェクトには影響がない
- CORBA
-
オブジェクト指向技術の標準化団体OMGが制定した、オブジェクト指向による分散処理環境を実現するためのオブジェクト管理プラットフォームの参照モデル
-
分散システム環境で異なったオブジェクト間でもメッセージの交換を可能にした共通仕様
- 遠隔地にあるデータベースにアクセスするプロトコルを規定している国際規格
- エージェント指向
利用者の意図を反映しながら進める機能
例：フライト（飛行便）予約システムにおいて、利用者が航空会社や時刻などを細かく指定しなくても、“水曜日午前中にニューヨークに着きたい”と指示すれば、条件に合うフライトを検索し、第１希望が満席なら次善のフライトを検索するといった一連の処理を、利用者の意図を反映しながら進める
- 機能分割・構造化
外部設計の成果物に基づいて、実現方法や処理効率を考慮しながら、システム開発者の立場から進める設計作業
- プログラミングツール
- インスペクタ
デバッグ時にデータ構造の内容を確認するためのツール
- 言語プロセッサ
- ジェネレータ
入力・処理・出力などの必要な条件をパラメタで指示することによって、処理目的の応じたプログラムを生成する
- ソフトウェア構成管理ツール
支援の対象とする作業：
バージョン管理
- CASEツール
適用する開発工程や範囲によって分類できる
- 上流CASEツール
要求分析の支援機能が含まれる
DFDの作成支援を提供する
- リポジトリ
ソフトウェアの開発および保守行程における様々な情報を一元的に管理するためのデータベース
データの定義情報（メタデータ）を保持し、データベースのデータディクショナリ又はデータディレクトリとして利用される
-
ソフトウェア開発・保守工程などの各工程での成果物を一元管理することによって、用語を統一することもでき、開発・保守作業の効率が良くなる
- 格納したデータについての複数のバージョンを管理する機能が必須
- チェックイン…セントラルリポジトリから分岐リポジトリへのデータのコピーのこと
- チェックアウト…分散リポジトリによるセントラルリポジトリのデータの更新のこと
- 必須の機能
格納したデータについての複数のバージョンを管理する機能
- マークアップ言語
文書中にタグを挿入することによって、文書の構造を記述できる言語
- SGML
-
タグを使って文書の論理構造や属性を記述する方法を定めた国際規格で、電子的な文書の管理や交換を容易に行うための標準文書記述言語
-
HTMLやXMLの基となったもので、図や表を含む文書データを取り扱うことができるISO標準の言語
-
論理構造をもった文書の作成に用いられる
-
文書を、宣言、文書型定義および文書実現値の3部の構成で記述する
- XML ( eXtensible Markup Language )
-
データの構造や意味をタグを用いて表現する言語
- インターネットを利用した企業間取引において、取引データをそのまま起票したり社内文書に変換したりするなど、
ネットワークを介した情報システム間のデータ交換を容易にするために、任意のタグを定義することができる
-
HTMLでは要素によっては終了タグを省略できるが、XMLでは開始タグと終了タグで内容を囲むか、空要素の形式で記述する必要がある
-
インターネットとの親和性が高い双方向リンク可能なハイパテキスト記述言語であり、文書の構造をDTDとして記述することで、ユーザ独自のタグが定義でき、文書中の文字列に属性を与えたり、文書中の文字列のデータ処理などが可能
-
要素の定義方法
データを開始タグと終了タグで囲んで構成する
要素の中に子要素を持つことができる
データがないこともある
W3C XML Schemaの用途
XMLで記述される文書の構造を定義する
-
DTD(Document Type Definition)
妥当なXML文書であるかを判定する
-
W3C XML Schema
XMLで記述される文書の構造を定義する
-
XMLパーサ
XMLの構文解析を行う
-
XSLT(eXtensible Stylesheet Language Transformation)
XML文書を別の文書構造を持つXML文書やHTML文書などに変換するための仕様
XMLのデータ構造を変換・加工する
- XHTML
HTMLをXMLの規格に合うように修正し定義したもの
- 制御構造
- ”前判定繰り返し”は、繰り返し処理の本体を1回も実行しないことがある
- 再帰的プログラムの特徴
実行中に自分自身を呼び出すことができる
- アルゴリズム
- ニュートン法
方程式 f ( x ) ＝ 0 の解の近似値を求めるアルゴリズム
幾何学的には、 y ＝ f ( x ) の接線を利用して解の近似値を求めるもの
- 線形探索法
配列上に不規則に並んだ多数のデータの中から、特定のデータを探し出すのに適したアルゴリズム
- モンテカルロ法
乱数を利用して、求める解や法則性の近似を得る手法
- API（ApplicationProgramInterface）
アプリケーションから、OSが用意する各種機能を利用するための仕組み
アーキテクチャの異なるCPU間でも、同じOSとそのAPIを使用することによって、プログラムの互換性を高め、移植時の工数を削減することが可能
- コンポーネントウェア
オブジェクト指向技術を基礎とした比較的自立性の強いソフトウェア部品を組み立てることによって、アプリケーションを開発する技術の総称
ActiveXやCORBA、JavaBeansなど
- 標準化
プログラミングに関する規約を設けることによって、プログラマの犯しやすい誤りを未然に防止する効果がある
- 命令語
命令の種類によっては、オペランドがないものもある
テスト
- プログラムのテストでは、正常なケースで正しく動作するかどうかだけではなく、意図しなかった動きがあるかどうか、あるいは誤った入力があった場合にも意図した動作（エラー処理など）をするかどうかを調べる必要がある
- テストの種類
- ブラックボックステスト
モジュールの内部構造ではなく、入力データと出力結果の関係だけに注目してテストデータを作成し、仕様書どおりに機能するかどうかをテストする
- 退行テスト（レグレッションテスト/リグレッションテスト）
保守のためにシステムの一部や、ソフトウェアに修正を加えときに、変更した箇所がほかの正常な部分（影響を受けないはずの箇所）に影響していないかどうかを確認する目的で行う
例）既存のシステムのある機能を修正したところ、今まで正常に動作していた機能を実行するとエラーが発生するようになった→退行テストが不十分であったと考えられる
- ホワイトボックステスト
プログラムのアルゴリズムやモジュールなどの内部構造に基づいてテストデータを作成する
- モジュール単体テスト
モジュール設計書を見ながら、原則としてすべてのロジックパスを一度は通るようなテストケースによって検証を行う
- 静的テスト
プログラムを実行することなくテストする手法であり、コード検査、静的解析などがある
- 移行テスト
新たなシステムを確実に稼働させるために、旧システムからの切り換えに関わるプロセスを安全性・効率性の観点から事前に確認する
現行システムを新システムに切り替える手順や作業時間に問題ないかを検証する
運用部門の担当者の役割：移行の作業手順を検討し、移行用マシンのシステム環境を準備する
- リミットチェック
入力データのチェック方式の一つ
データがある範囲にあるかどうかを検査する
- ボトムアップテスト
- 下位のモジュールから上位のモジュールへと順次結合してテストする
- システム開発の当初から、プログラミングと結合テストの並行作業が可能である
- ドライバが必要で、スタブは不要である
- トップダウンテスト
- 上位のモジュールから下位のモジュールへと順次結合してテストする
- ドライバは不要で、スタブが必要である
- テストケース設計法
- ブラックボックステスト
-
プログラムの機能仕様やインタフェース仕様に基づき、テストケースを設計する
- 稼動中のシステムから実データを無作為に抽出し、テストデータを作成する
-
機能仕様から同値クラスや限界値を識別し、テストデータを作成する
- 同値分割
仕様からデータを、意味のあるグループ（同値クラス）に分類し，各グループから代表値を選びテストを行う
例）
読み込んだデータが正しくないとき、エラーメッセージを出力するかどうかをテストするために、プログラム仕様書を基に、正しくないデータのクラスを識別し、その中から任意のひとつのデータを代表として選ぶ
- 境界値分析
同値クラスの間の境界の値（境界値）をテストデータとして選択する
- ホワイトボックス
- 分岐網羅
全ての判定条件文において、結果が真になる場合と偽になる場合の両方がテストされるようにテストケースを設計する
- 命令網羅
プログラム中のすべての命令を少なくとも1回実行するテスト
- テストの順序
-
単体テスト
テストツールを利用して、プログラムがコーディング基準を満足しているかを検証する
-
結合テスト
モジュール間やサブシステム間のインタフェースを検証するために行うテスト
- スタブ
階層構造のモジュール群からなるソフトウェアの結合テストを、上位のモジュールから行う場合に使用する、下位モジュールの代替となるテスト用のモジュール
- ドライバ
ボトムアップテストにおいて、被テストモジュールの上位モジュールの機能を代行するもの
テスト対象モジュールに引数を渡して呼び出す
-
システムテスト
オンライントランザクション処理のレスポンスタイムが要求仕様を満足するか検証する
システムの要求仕様に照らしたマニュアル検証やテストケース設計などを行う場合、ユーザ部門の要員に参画してもらう
- テストケース作成に対応させる仕様書
外部設計工程で作成した外部設計書
- システムテストを実施するとき、用意しておくべきテストデータ
実際に業務で使うデータや、業務上例外として処理されるデータ
-
運用テスト
- 完成プログラムを本稼動環境下で試行するテスト
- 原則としてユーザ部門の責任で利用者が主体となり、実際の業務プロセスに沿って機能用件や操作性を検証する
-
ユーザ部門が優先して確認すべき事項：決められた手順どおりに、システムが稼動すること
- テストにおけるユーザ部門の役割
システム開発における成果物に対して、業務的観点から内容確認を行う
プログラムの詳細設計は開発部門に任せる
システムテストの段階で参加する
用意された運用マニュアルが適切であることを確認する（運用テスト時）
- 品質の判断
- テスト消化率のグラフ
横軸：テスト項目消化件数
縦軸：累積バグ件数
テスト項目件数が増えるにつれて累積バグ件数は収束する
-
外部設計および内部設計の誤りは、プログラムだけでなく、マニュアルなどにも影響を与えるので、コーディングの誤りに比べて修復コストは高い
- バグ埋め込み法
テスト対象のプログラムにバグを埋め込んでおき、埋め込みバグの検出状況から、プログラム全体の検出状況を推定する
- 摘出した総バグ数：摘出した埋め込みバグ数＝総バグ数：埋め込みバグ数
- 潜在バグ数＝総バグ数−埋め込みバグ数−（摘出した総バグ数−摘出した埋め込みバグ数）
- バグ管理図
バグ管理図において、すべての線が横ばい状態になった状況から、解決困難なバグに直面しており、その後のテストが進んでいないことが推測できる
- トレーサ
動的デバッグツールの一つ
プログラムの実行過程を時系列的にモニタリングするために、メモリやレジスタの内容を書き出す
- アサーションチェッカ
変数の間で論理的に成立すべき条件を、プログラムの適切な箇所に挿入し、実行時にその条件を満たしているかどうかを検査するツール
- プログラムの変更管理の実施
変更実施結果の評価基準として、変更作業工数の予測値、障害発生率の目標値を決める
障害発生率：ここでは変更したことによる新たな障害の発生率を示す
- テストの事例
- 本社に設置したサーバのデータを、本社及び各事業所内のLANと、本社各事業所とを接続する通信回線とから構成されている自社ネットワークを介して、全国の事業所に提供するアプリケーションを開発する場合、システムテストを本社内のLAN環境で行うとき、応答時間の検証は困難