開発技術(1)

システム開発技術

システム開発のプロセス

　
業務プロセスに使うシステムを開発するには、一般的に「要件定義」から始まり、「システム設計」、「プログラミング」、「テスト」、「ソフトウェア受入れ」、「ソフトウェア保守」、「ソフトウェアの見積もり」といったプロセスを通過しますシステム開発プロセス

レビューの必要性

システム開発のプロセスごとに、「レビュー」を実施する必要がある。開発者個人で行う場合や、少人数のプロジェクトチームで行う場合、関係者全員で行う場合などがある。メリットは開発者以外の人が行うことで客観的なチェックができ、開発者が気付かなかったバグを発見できることである

レビュー

設計やシステムにバグ(間違い)がないかどうかをチェック・確認すること。潜在するバグを発見し、修正することで品質を高めることができる

要件定義

システム開発における「要件定義」とは、システムやソフトウェアに求められる機能や性能、内容などを明確化するためのもの。システムを利用する部門・部署の要望を調査、分析し、技術的な実現の可否などを見定めていく。「システム要件定義」、「ソフトウェア要件定義」などがある

システム要件定義

安定して稼働させるためのハードウェア的なスペックを規定するもの。一般的には、システムの信頼性(稼働時間、条件など)を規定する。また、システムの運用にあたって使用するハードウェアの性能やシステムの利用者に対する教育の条件なども規定する

システム設計

「要件定義」に基づいたシステムを設計していきます。「システム方式設計」、「ソフトウェア方式設計」、「ソフトウェア詳細設計」といった手順がありますシステム設計

システム方式設計（外部設計）

要件定義の内容を基にシステムの構成を設計する要件適宜にあるすべてのシステム要件を以下のように分類する。分類することで、利用者の作業範囲が明確になり、リスクを考慮した選択肢の提案や、効率的な運用、保守などを踏まえたシステム構成の設計が可能となる。内容は「システム方式設計書」として整理する

・ハードウェアで実現する内容(ハードウェア構成)
・ソフトウェアで実現する内容(ソフトウェア構成)
・使用者が手動で実現する内容(手作業)

ソフトウェア要件定義（外部設計）

システムを構成するソフトウェアごとに行われ、機能や能力などソフトウェアに必要な機能を明らかにする作業。明らかにする要素は、性能・機能のほか安全性、セキュリティの仕様、データ定義及びデータベースに対する要件も含まれる。「ヒューマンインタフェースの設計」、「データの設計」、「コードの設計」などがある。内容は「ソフトウェア要件定義書」として整理する

ヒューマンインタフェースの設計

システムの入出力の画面や帳票などの印刷イメージの設計

データの設計

リレーショナルデータベース（RDB）で用いるテーブルのデータ設計などを行う

コードの設計

顧客番号や製品番号といった規則性のある情報をコード化する際のルールを決める

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

システム開発部門が実施する。システム方式設計で決定した内容に基づき、システムに必要な内部機能を設計する。内容は「ソフトウェア方式設計書」として整理する

ソフトウェア詳細設計（プログラム設計）

システム開発部門が実施する。ソフトウェア方式設計に基づいたプログラム内の構造を設計します。プログラム内の機能詳細を定義したり、データベースへのアクセス方法など、プログラム構造の細かい処理単位を設計したりする。内容は「ソフトウェア詳細設計書」として整理する

開発（プログラミング）

システム設計の内容を基に個々のプログラムを作成していく。作成した個々のモジュール（プログラムを構成する最小単位）が「プログラム設計書」の通りに作動するかどうかを確かめるために、「単体テスト（モジュールテスト）」を行う。この単体テストで利用される手法や手段として、「ホワイトボックステスト」や「コンパイラ」などがある

プログラミングの保守性の向上

プログラミングの保守性を向上させるには、変数名やコメントの書き方、使用できない文字列や長さの制限、大文字と小文字の区別など、プログラミングのルールを守る必要がある。この守るべきルールのこと「プログラミング作法」という。プログラミング作法に従ってプログラミングすることで誰が見ても処理の内容が容易に理解でき、プログラミングの修正がしやすくなる

デバック

コンピュータのバグを探し、取り除く作業のこと。単体テストとは異なり、バグが存在することが判明した場合、その箇所を絞り、プログラムを修正する

モジュール

プログラムを構成する最小単位のこと。一般にひとつのプログラムは、ひとつ以上のモジュールからできている

コンパイラ

プログラム言語で記述されたプログラムをコンピュータが実行可能なコードに変換するソフトウェアのこと。コンパイラにより、作成したプログラムの誤り（バグ）をチェックすることができる

テスト

単体テストが済んだモジュールを組み合わせ、結合したプログラムが要求通りに動作するかどうかを検証するテスト手順

テストの技法

各テストの実施方法には、ステムやプログラムのどこに着目するかによって、「ブラックボックステスト」と「ホワイトボックステスト」がある

ホワイトボックステスト

システムのテスト手法のうち、システムの内部構造を理解し、各モジュールが意図した通りに動作するかを確認するプログラムテストの方法。ホワイトボックステストでは、プログラムの外部仕様には着目せず、論理を実現するために使われている命令や、分岐が正しく動作するか、といった部分についてチェックが行われる。判定の度合いは網羅率（Coverage）によって示され、網羅率が100%となることを目指して進められる。チェックの観点に従い、命令網羅（C0）、分岐網羅（C1）、条件網羅（C2）などの種類に分けられる

命令網羅（CO）：全ての命令が正しく一度は実行されたかどうかをテストする

分岐網羅：全ての分岐が正しく一度は実行されたかどうかをテストする

条件網羅：複数条件の真偽の組み合わせについて全ての分岐が正しく一度は実行
　　　　　　　　されたかをテストする

ブラックボックステスト

データが正しく処理されているかを検証するテスト手法の中でも、入力データと出力データの結果だけに着眼し、それが仕様書どおりに正しく処理されているかを調べるテスト法のこと
ブラックボックステストでは、プログラムの内部的な仕組みは問題視せずに、あくまでも入力データの処理結果のみを確認する。内部構造が明らかでないもの、という意味で「ブラックボックス」と呼ばれている

テストの計画

テストでは、入力したデータに対して期待どおりの結果が出力されるかを検証する。しかし、正しいデータが入力された場合の結果を確認するだけで、テストを終了させるのでは不十分。実際の業務では、必ずしも正しいデータが入力される、また正常な状態でのシステムが使われるとは限らないため、さまざまなケースを想定して次のようなテストデータを用意する

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

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

ブラックボックステストを実施するためのテストデータを作成するには、主に「同値分割」と「限界値分析」がある

同値分割

入力するデータを「有効同値クラス」と「無効同値クラス」にクラス分けし、それぞれのクラスを代表する値をテストデータとして採用する方法。特徴は、テストデータを作成しやすいこと

有効同値クラス	入力データとして正常に処理される値の範囲
無効同値クラス	入力データとしてエラーとなるような値の範囲

限界地分析

同値分割のクラスの境界にあたる値を、テストデータとして採用する方法。境界の条件が複雑な場合には、テストデータの漏れが発生しやすいため注意が必要。条件を整理するときに決定表などが使われる

テストの実施

結合テスト

モジュールやプログラムを結合して、そのやりとりが正しく実行できるかを検証する。単体テストが完了したらモジュール間やプログラム間で実施する。結合テストには、「トップダウンテスト」と「ボトムアップテスト」がある。また、「サンドイッチテスト」、「ビックバンテスト」などもある

トップダウンテスト

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

ボトムアップテスト

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

サンドイッチテスト

トップダウンテストとボトムアップテストを組合せた方法。「折衷テスト」ともいう

ビックバンテスト

各モジュールのテストが終わったあとに全モジュールの結合の一斉テストを行う方法

システムテスト

プログラムを個々の機能と仕組みを総合し、全体像としてのシステムを対象に仕様書の通りに機能しているかをテストする

名　称	説　明
機能テスト	必要な機能がすべて含まれているかを検証する
性能テスト	レスポンスタイム、ターンアラウンドタイム(応答時間)やスループットなどの処理性能が要求を満たしているかを検証する
例外処理テスト	エラー処理機能や回復機能が正常に動作するかを検証する
限界テスト	無効な値と有効な値の境界付近のデータに対して正常に動作するかを検証する
負荷テスト (ラッシュテスト)	大量のデータの投入や同時に稼動する端末数を増加させるなど、システムに負荷をかけ、システムが耐えられるかを検証する
操作性テスト	利用者が操作しやすいかを検証する
ペネトレーションテスト（侵入テスト）	外部からの攻撃や侵入を実際に行ってみて、システムのセキュリティホールやファイアウォールの弱点(脆弱性)を検出する

運用テスト

実際の稼働環境で運用して検証を行うテスト。実際の業務で使ものと近しいテストデータを入力し、要求通りに機能するかをテストする

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

テスト結果の評価

システムを検収するためには、テストの結果が良好である必要がある。テストの結果を元にステムを評価する基準として「バグ管理図」や「稼働率」などがある

バグ管理図

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

テストカバー率

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

　
システム開発において、エラーの発生は避けて通れないが、どのタイミングでエラーを検出・処理するかによってその対応工数が異なる。初期段階では、プログラムが単体であることから、エラーの発生したプログラムの修正・テストとなり、対応工数が少なくなるが、後工程では、プログラムが結合され、エラーの発生したプログラムだけでなく、周囲のプログラムのテストも行う必要が出て、対応工数が増える。開発初期段階でのプログラムの品質を高めておく必要がある

システムの導入・受け入れ

導入手順

システム導入計画

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

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

導入

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

受け入れ

テストが完了し、各機能が要求通りに稼働することを確認したら、システムの利用者（ユーザー）への引き渡しを行う。その際、ユーザは要求通りの機能が働いているかシステムのテスト（ユーザー承認テスト）を行う。ユーザ承認テストが終わり、問題がなければ、開発部門はシステムを納入し、利用者は検収を行い、実際に利用者の環境に対するシステムを構築する。その際、システムの操作手順や利用の仕方などを記述した「利用者マニュアル」を作成するなどして、実際に利用する部門や部署へシステムの活用を促す

承認テスト（受け入れテスト）

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

利用者マニュアル

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

システムの導入・受け入れ

システム開発が完了すると、利用者はシステムを運用し始める。「ソフトウェア保守」では、システムの利用状況や稼働状況を監視し、問題点があれば修正を行う。システムが安定稼働し始めた場合でも、情報技術の進展や経営戦略の変化に対応させるために、適時プログラムの修正や変更を行うこともある

運用・保守に関する留意点

・本稼働中のプログラムは直接修正せず、あらかじめバックアップしてから修正作業を行
　う。また、プログラムの修正後は、本番環境と同等レベルの環境でテストを行う
・プログラムを変更した場合、変更内容は、障害要因などを調査する際にも役立つの
　で、必ず修正履歴を記録しておく。また、リグレッションテストを実施し、ほかのプログ
　ラムに影響がないことを確認する
・システム開発にかかわるドキュメント一式(設計書や操作手順書など)は、常に、最新の
　状態を維持する
・データ量の増加によるディスク不足が起きていないかどうか、性能劣化が発生してい
　ないかどうかなどを監視して、必要に応じて改善・対処する

ドキュメントの保存

ドキュメントは、システム開発のプロセスごとに残しておくことが重要。具体的なドキュメントして、「要件定義書」「設計書」「開発したプログラム」「テスト実施計画書」「テスト実施報告書」などが挙げられる

システムの保守

保守の形態	説　明
予防保守	将来の障害の発生に備え、未然に障害の原因を取り除いておく
定期保守	定期的に日常点検する。また、専門の業者と保守契約を締結し、ハードウェアの点検を依頼する
リモート保守	専門業者との保守契約を締結し、専門の業者と利用者を通信回線で接続して、リモート(遠隔操作)で障害の原因を取り除く

システムの障害対策

システムの運用を維持していく上で重要なのは、システムに障害が起こらないように予防措置を講じておくこと。でも、予期しない事態が発生することも。発生した障害によってシステム全体に影響が及んだり業務が停止したりすることがないように、開発時に十分な対策を用意しておくことが重要。しかし、障害にも規模があり、発生率が極めて低い場合や、発生時の被害額が微少である場合は、その事前対策にかかる費用との兼ね合いで事前対策を用意しないという選択肢もある

外部委託の方法

請負契約
委任契約
派遣契約

ソフトウェアの見積

　
システムの開発規模や開発費用、開発環境などに基づき、総合的な開発費用を「見積り」を作成します。システム開発の見積りにはいくつかの方法が知られています

プログラムステップ法

プログラムのステップ数（行数）をもとにして、システムの開発費用を見積もる手法
プログラムステップ法は、プログラムが既に存在していれば、容易に見積りを出すことができるという特徴がある。一方、プログラムが存在しない場合には、過去の開発事例を参考にするなどしてステップ数を割り出して見積もる

ファンクションポイント法（FP法）

システムの機能の数を判断材料として、入出力画面や使用するファイル数、データ項目数など、開発する機能の難易度を数値化した独自のファンクションポイントを設定し、開発費用を見積もる手法のこと。GUIやオブジェクト指向でのプログラムの開発の見積に向いている
FP法では、ソフトウェア内で行われる全ての処理を抜き出して、その機能を分類して、さらにそれらを複雑さによって分類する。これらのいくつかの項目から個々の機能（function）に得点（point）を与えてゆくと、定量が導き出せる

COCOMO

ソフトウェア開発費用を見積もる手法のひとつで、開発に必要とする段階の数、各工程の難易度、あるいはチームの開発能力などを補正係数として掛け合わせて、工程数や人員を見積もる手法のことである。COCOMOの計算法は、プログラム言語の難度など左右されないため、比較的客観性を保つことができるということを大きな特徴としている
1997年には、COCOMOの計算手法を改良し、ソフトウェアの機能を評価の指針とする「ファンクションポイント法」などを取り入れて、拡張および厳密化を施した「COCOMO II」が発表されている