開発技術(4)

開発(プログラミング)

ソフトウェアコード作成

ソフトウェア詳細設計書を基にして、ソフトウェアコードで作成することをプログラミング、またはコーディングという

コードレビュー

作成したソフトウェアコードをレビューすることで、プログラミング基準を守っているか、ソフトウェア詳細設計書に基づいているかを確認する
コードレビューは、共同レビューを行い、テスト工程に入る前に実施し、バグをなくすことが目的

デバッグ

ソフトウェアのバグ(誤り)を見つけ、その原因を調査し、修正すること
デバッグを支援するソフトウェアを「デバッガ」と呼ぶ
●机上デバッグ：ペーパー上を目で探すため、単純なミスは発見しやすいが、
　　見落とす場合も多い
●デバッガを使ったデバッグ：精度にも依存するが、一般的に漏れなくバグを
　　発見し、修正可能

デバッガを使ったデバッグ方法

トレーサ	コードを1行ずつ実行しながら、処理の順番やメモリの内容を確認する方法。 処理のある個所にブレークポイント(停止位置)を設定し、コードの処理をそこまでの範囲だけに注目して動作を確認できる
ダンプ	プログラムの内容確認のため、ファイルやメモリの内容をディスクに出力すること メモリダンプ：ソフトウェアの異常終了のタイミングでメモリ内容を出力したもの スナップショットダンプ：コードの特定の命令を実行したタイミングでメモリ内容を出力したもの
アサーション	プログラミングでコード内の変数値などをチェックする機能 言語による違いはあるが、共通するのは、満たさなければならない条件を指定する

テスト

テスト

ソフトウェアユニットテスト(モジュールテスト、単体テスト)

モジュール単体で行うテスト。システム開発部門(一般的には開発者自身)が行う

テストケースの設計

テストでは、入力したデータに対して期待どおりの結果が出力されるかを検証する。さまざまなケースを想定して次のようなテストデータを用意する

正常データ	業務が正常に処理されることを確認する
例外データ	業務で発生する例外データが例外として処理されるかを確認する
エラーデータ	誤ったデータがエラーとして正確に検出されるかを確認する

※まず、正常データでのテストを行ってから、次に、例外データやエラーデータでのテストを行う

テストの実施

ブラックボックステスト

入力データと出力データの結果だけに着目し、それが仕様書どおりに正しく処理されているかを調べるテストのこと。プログラムの内部的な仕組みは問題視せずに、あくまでも入力データの処理結果のみを確認する

ホワイトボックステスト

システムの内部構造を理解し、各モジュールが意図した通りに動作するかを確認するプログラムテストの方法。アルゴリズムに着目し、コンポ―ネントの内部構造や論理をチェックする方法

テスト結果の評価

網羅率(テストカバー率)

テストを網羅した比率のこと。この比率が100％になるとテストが完了したと判断できる。テストカバー率によって、成果物の品質を評価することができる。「網羅率」「カバレッジ」とも呼ばれる

バグ管理図

テスト時間と検出されたバグ(エラー)の累積数の関係をグラフにしたもの。理想的なバグ管理図は、「ゴンベルツ曲線」(信頼度成長曲線)と呼ばれる形の曲線になる

ソフトウェア結合テスト

モジュールやプログラムを結合して、そのやり取りが正しく実行できるかを検証。単体テストが完了したらモジュール間やプログラム間で実施

テストの実施

結合テストには、「トップダウンテスト」と「ボトムアップテスト」がある
また、「サンドイッチテスト」、「ビックバンテスト」などもある

トップダウンテスト

上位のモジュールから順番にテストしていく方法。すべての下位のモジュールが完成していないことが多いため、上位のモジュールに呼び出される仮のモジュール「スタブ」を用意する
※stab：「試み」という意味

ボトムアップテスト

下位のモジュールから順番にテストしていく方法。上位のモジュールが完成していない場合は、下位のモジュールを呼び出す仮のモジュール「ドライバ」を用意する

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

ソフトウェア要件定義どおりに実現されているかを確認する
利用者が主体となって行う

システム結合テスト

システム全体が要求したとおりに作られているかどうかをテストする

名称	説明
機能テスト	必要な機能がすべて含まれているかを検証する
性能テスト	応答時間やターンアラウンドタイム、スループットなどの処理性能が要求を満たしているかを検証する
負荷テスト	大量のデータの投入や長時間の稼働に耐えられる処理性能を持っているかを検証する。性能テストも同時に実施
操作性テスト	操作性や表示されるメッセージの適切さをテスト
例外処理テスト (異常時テスト)	わざと間違えたデータを入力し、その異常部分が正しく処理されるかどうかなど、エラーの処理や例外処理が正しく行われるかテストする
レグレッションテスト (退行テスト)	システムの修正・新機能の追加をしたときに、他の部分に影響が及んでいないかどうかをテストする
ペネトレーションテスト (侵入テスト)	外部からの攻撃や侵入を実際に行ってみて、システムのセキュリティホールやファイアウォールの弱点を検出する

システム適格性確認テスト

実際に業務で使うデータや、業務上例外として処理されるデータを用いてシステムを検証するテスト

テスト項目

項目	説明
業務機能	業務を行う上で必要な機能を満たしているかを検証する
操作性	ユーザが操作しやすいシステムかを検証する
異常対策	データ異常、異常な操作、機器異常などの場合の対策がとられているかを検証する
処理能力	現行の機器構成で処理能力が十分か検証する
処理時間	応答時間などが許容範囲か検証する

導入・受入れ

導入

システム導入計画

以下のような点を明確にする。作成した導入計画は「システム導入計画書」として文書化する

●システムの稼働に必要な環境整備(ハードウェア) ●システムの導入・運用にかかる費用 ●移行のタイミング ●データを移行する際のbackupの方法 ●システムの導入による業務への影響とその対処方法 ●システムの導入にかかわるスケジュール ●システムの導入にかかわる支援体制

導入

システム導入手順や体制が整ったら、導入計画にもとづいてシステムの導入作業を行う

受入れ

承認テスト(受入テスト)

開発者側からエンドユーザにシステムを引き渡す際に行う。エンドユーザからの要求が、全て満たされているかを検証する

利用者マニュアル

ソフトウェアやシステムの利用方法が書かれた説明書のこと。システムを利用するための運用手順、コンピュータの操作方法、運用規定などが文書化されている。稼働前に利用者マニュアルを使用して操作教育が行われたり、稼働後に業務内容に合わせてマニュアルを確認しながら作業を習得したりする

運用・保守

保守要件

項目	説明
保守の実現可能性	保守を実現する可能性を明確にする。実施する保守を明確にする
保守手順	実施する保守について、手順を明確にする
保守体制	実施する保守について、体制を明確にする
保守テスト	保守時に行うテストのテストケースを明確にする

リグレッションテスト

システムの修正・新機能の追加をしたときに、他の部分に影響が及んでいないかどうかを確認するテスト

保守の形態

名称		説明
予防保守	日常点検	日常的に実施するシステム点検
	定期点検	月末・週末など定期的に実施するシステム点検
事後保守	緊急保守	システム停止などにより緊急で実施する保守
	臨時保守	システムの動きの悪さなどにより臨時に実施する保守

保守の手順