システム開発技術｜設計・テスト・導入・保守と見積り（FP法・類推見積法）【ITパスポート】

システムは、何を作るかを決めたあと、設計→プログラミング→テスト→導入・受入れと進んで使われ始め、その後も保守で手直しされ続けます。

開発の流れと、工程に対応するテスト
プログラミングとテスト
導入・受入れ ── 本番で使い始めるまで
保守 ── 使い始めたあとの修正・変更・改善
見積り ── 工数と見積りの方法
まとめ
この節で解ける公開問題

開発の流れと、工程に対応するテスト

開発の最初の工程は、システムに求める機能や性能をはっきりさせる要件定義です。業務要件・機能要件・非機能要件や、利用者と開発者の共同レビューは情報システム戦略の回で扱っています。そこから先の工程は、次の図のように進みます。

開発の流れとテストの対応をV字で表した図。左の腕を上から下へ、要件定義→機能設計→詳細設計→プログラミング。右の腕を下から上へ、単体テスト→統合テスト→システムテスト→受入れテスト。同じ高さの工程が点線で結ばれ、要件定義と受入れテスト、機能設計とシステムテスト、詳細設計と統合テスト、プログラミングと単体テストが対応する。受入れテストのあとは導入・保守へ進む。

左で決めたことを、右の同じ高さのテストで確かめます。

左の腕は「決めて作る」工程で、下へ行くほど細かくなります。機能設計では利用者から見た機能や画面・帳票を決め、詳細設計ではそれを実現するプログラムの内部の作りを決めます。システム全体の構成を決めるシステム設計と、ソフトウェアの中身を決めるソフトウェア設計がある、とも言います。

右の腕は「確かめる」工程で、小さい単位から大きい単位へ進みます。テストは、同じ高さの工程で決めたことを物差しにして確かめます。プログラムの中身は単体テストで、詳細設計で決めたつなぎ方は統合テストで、要件どおりかはシステムテストと受入れテストで確かめます。

要件を決めるときには、機能だけでなく品質特性も考えます。シラバスの例は機能性・効率性・使用性・信頼性などで、公開問題では次の8つに分けた形（規格 JIS X 25010 の2013年版の分け方）でも出ます。

ソフトウェアの品質特性（8つの分け方）

機能適合性　… 求められた機能を正しく果たすか

性能効率性　… 処理時間や使う資源が適切か

互換性　… ほかの製品と共存し、情報をやり取りできるか

使用性　… 分かりやすく、覚えやすく、操作しやすいか。例：新しく配属された人が、その日のうちに一人で操作できるようになる

信頼性　… 決めた期間・条件のもとで、止まらずに機能を果たし続けられるか

セキュリティ　… 許された人だけが情報を使えるか

保守性　… 直したり変えたりしやすいか

移植性　… 別の環境（OSや機器）へ移しても動かせるか

使用性は、利用者から見た使いやすさの話です。くわしくは情報デザインの回で扱っています。

プログラミングとテスト

設計に従ってプログラムを書くことをコーディングといいます。書いたプログラムは、ほかの人が読んで誤りを探すコードレビューにかけ、動かして見つかった誤り（バグ）の原因を探して直します。これがデバッグです。プログラミングの工程は、1つ1つのプログラムを確かめる単体テストまでを含みます。

ホワイトボックステストとブラックボックステストの比較。左＝ホワイトボックステスト：透明な箱の中の分かれ道を虫眼鏡でのぞく絵。中身（内部構造）を見る、命令や分岐を全部通す。右＝ブラックボックステスト：中の見えない黒い箱に入力の矢印が入り、出力の矢印が出る絵。入力と出力だけを見る、仕様どおりの出力か。

中身を見て通り道を試すのがホワイトボックス、入力と出力だけを見るのがブラックボックスです。

テストの作り方は、プログラムの中身を見るかどうかで2つに分かれます。ホワイトボックステストは中身（内部構造）を見て、すべての命令や、すべての分かれ道が少なくとも1回は通るようにテストデータを作ります（命令網羅、分岐網羅）。プログラムの中の通り道を内部パスともいい、それを漏れなくたどるテストです。主に単体テストで使い、実行した結果を予想した値と比べて、誤りがないかを分析します。ブラックボックステストは中身を見ずに、入力に対して仕様どおりの出力が返るかだけを確かめます。統合テストやシステムテストのように、プログラムの外から確かめる場面で使います。

単体テストが済んだプログラムを組み合わせ、要件どおりに動くかを確かめるのが統合・テストの工程です。

統合・テストで行うテスト

統合テスト　… 結合テストとも呼ぶ。プログラムどうしをつなぎ、受け渡し（インタフェース）が正しいかを確かめる

システムテスト　… システム全体が要件どおりに動くかを確かめる。夜間の一括処理が朝の業務開始までに終わるかなど、全体の性能もここで見る

性能テスト　… 応答時間や処理時間が、求められた値を満たすか

負荷テスト　… 利用者の集中や大量のデータなど、重い負荷をかけても動くか

回帰テスト　… リグレッションテストとも呼ぶ。プログラムを直したあと、直していない部分に悪い影響が出ていないか

テストは、計画→実施→評価のサイクルで進めます。計画で「何件のテストをいつまでに行うか」などの目標を決め、実施したら、消化したテストの件数や見つかったバグの数といった実績を目標と比べて評価します。

給与計算システムで、税率の変更に合わせて税額を計算する部分だけを直しました。直していない残業代の計算や、振込データの作成が、前と同じように正しく動くかを確かめます。このテストに最も当てはまるものはどれですか。

導入・受入れ ── 本番で使い始めるまで

導入・受入れから保守までを、左から右へ5枚のカードで表した図。導入（本番環境に入れる）→受入れテスト（発注側が確かめる）→納入（問題がなければ）→教育訓練（利用者マニュアル）→保守（修正・変更・改善）。

発注側が受入れテストで確かめてから納入され、使い始めたあとは保守で手直しされます。

テストが終わったソフトウェアを、利用者が使う本番の環境に入れる工程がソフトウェア導入です。どの順でインストールし、何を設定するかを手順として書き出し、その手順のとおりに作業します。本番の業務に直接影響するので、手順・日時・止まる業務・うまくいかなかったときの戻し方などを導入計画書にまとめ、関係者の合意を得てから作業します。新しく作ったシステムでも、すでに動いているシステムに手を加える場合でも、社内向けのシステムでも、先に計画と合意、作業はそのあと、という順序は変わりません。

次に、発注した側（取得者・委託側）が、作った側（供給者・受託側）の支援を受けながら確かめます。

導入・受入れで行うこと

妥当性確認テスト　… 意図した運用環境でシステムを実際に使い、意図した用途を達成しているかを確かめる

受入れテスト　… 発注した側が、要件どおりかを確かめる。問題がなければシステムが納入される

移行　… 古いシステムから新しいシステムへ切り替える。データの移し替えも含む

教育訓練　… 運用する人、利用する人、その他の関係者に使い方を教える

利用者マニュアルは、利用者が日々の仕事でシステムを操作するときに開く手引きで、仕事の種類ごとに操作の手順をまとめた文書です。よくある質問と回答を集めたFAQや、サービスの水準を提供者と利用者で取り決めたサービスレベル合意書（SLA。くわしくはサービスマネジメントの回）、開発の前に求める機能や性能を書いたシステム要件定義書とは役割が違います。

保守 ── 使い始めたあとの修正・変更・改善

保守は、システムを安定して動かし続け、ITの進展や経営戦略の変化に対応するために、使い始めたあとのシステムやソフトウェアを修正・変更・改善することです。不具合を直すことだけではありません。業務のルールが変わってシステムの仕様を変える修正も、保守にあたります。

不具合を直すだけでなく、変化に合わせる修正や改善も保守です。

ソフトウェア保守の4つのタイプ

是正保守　… 運用中に見つかった不具合を直す

予防保守　… まだ表に出ていない欠陥を、トラブルとして現れる前に見つけて直す

適応保守　… 法律の改正や、業務・環境の変化に合わせて変える

完全化保守　… 性能や使いやすさを高める

保守かどうかは「納入して本番で使い始めたあとか」で決まります。同じ不具合の修正でも、納入前の開発期間中に行うものは開発（テスト）の工程の作業で、保守ではありません。

見積り ── 工数と見積りの方法

開発にかかる手間は工数で表します。単位の人月は、1人が1か月働く量です（人日はプロジェクトマネジメントの回）。1人月でどれだけ作れるかを生産性といい、作る量（規模）を生産性で割ると工数が出ます。工程ごとに生産性が違うときは、工程ごとに割ってから足します。

例：規模 60kステップ（1kステップ＝プログラム1,000行）
生産性：設計 5.0、製造 3.0（kステップ／人月）
工数＝規模÷生産性
設計：60 ÷ 5.0 ＝ 12人月
製造：60 ÷ 3.0 ＝ 20人月
全体：12 ＋ 20 ＝ 32人月
検算：12 × 5.0 ＝ 60、20 × 3.0 ＝ 60

設計も製造も、60kステップ分の作業をします。生産性を足して 60÷(5.0＋3.0) とすると 7.5人月になり、まちがいです。工数が出れば、開発期間の目安も出せます。32人月を4人で受け持てば、単純に割って8か月です。

見積りの方法は、何を手がかりにするかで分かれます。