- おすすめ
不具合未然防止の基本と実務への適用《事例で学ぶ FMEA/FTA/DRBFMの効果的な使い方》(セミナー)
2024/12/3(火)9:30~16:30
お問い合わせ
03-6206-4966
ソフトウェア開発(システム開発)における品質管理は、ハードウェアと全く異なる発想で進められます。
その理由は完成したソフトウェアの良し悪しをハードウェア製品のように手に取りその動きを確認できないためです。ソフトウェア品質は、コンピューター内部のソフトウェアの動きや、プログラミング言語で書かれたソースコードを確認するしかないのです。
本記事では、ソフトウェア開発の基礎と、各開発段階での品質管理の重要ポイントについて解説します。
目次
ソフトウェアの開発方法には大きく2つの方法があります。
1つはウォーターフォール型と呼ばれるタイプです。もう一つはアジャイル型です。
具体的な開発方法の違いについては次に説明します。
【図1 ウォーターフォール型開発手法】
注:図に示された用語の説明
|
ウォーターフォール型とは、開発が「滝の水が上から下へ落ちるように順番に進む」ためその名がつけられています。
ソフトウェアの開発当初では、お客様の要求仕様をまとめ、その後、設計・実装と順番に進みます。最後に各種の確認テストを実施しソフトウェアをリリースします。(図1参照)
この方法はソフトウェアの主流となる開発手法で、大型プロジェクト開発から小規模システムまで多くのケースで利用されています。
お客様の要望や仕様を伺い、それをソフトウェアのシステムとして整理し一つの文書(「要件定義書」)にまとめます。
ウォーターフォール型には、次のようなメリット・デメリットがあります。
実際の具体例として、大規模システムや信頼性が担保される開発(例:銀行システム、交通システム等)に多く用いられています。
【図2 アジャイル型開発手法】
アジャイル(英:Agile)型とは、『素早い』『活発な』を意味する開発手法です。
アジャイル型開発は、短い期間での開発サイクル(設計→実装→テスト)を何度も繰り返し、ソフトウェアを完成に導く手法です。
特にお客様の仕様が、部分的機能しか決まっていない段階でソフトウェア開発をスタートする場合に用いられます。(図2参照)
アジャイル型の開発には、次のようなメリット・デメリットがあります。
アジャイル型は、お客様のニーズ変化が激しい業界に向いていることが多いです。
具体例として「日本航空(JAL)の予約・発券システム」の開発にも採用されているようです。
ソフトウェア開発では、一般的に図3に示すような工程(開発プロセス)で行われます。
【図3 ソフトウェアの開発工程と作成文書(成果物)】
システムの構想・全体像を具体化するための要件定義や設計を行う工程を「上流工程」と呼び、コーディング(実装)やテストの工程を「下流工程」と呼ぶことが多いです。
また、レビュー記録とは、ソフトウェア開発時に作成する文書やソースコードについて、レビュー(評価・改善指摘)を行なった記録を残す作業です。具体的には、レビュー時に行われた審議内容や指摘事項、改善提案などを記載します。会議時間などの進捗状況や参加メンバーを記載し、各種設計やテストにてバグが発生した場合の見直し資料として使用されます。
ソフトウェア開発の設計仕様を固める上流工程についてその進め方や管理ポイントを説明します。
ソフトウェアの設計は、一般的に大きく次の3つのステップに分類されます。
「要件定義」とは、開発するソフトウェアの要件(機能、仕様、性能、品質、納期、コスト、開発工数等)を明確にする工程です。この要件がしっかりできていないと、後から「追加仕様」や「矛盾した機能」が発生し納期や費用が大幅に増加します。
そのためお客様や関係者と十分すり合わせた「要件定義書」を完成させる必要があります。
基本設計では、「要件定義」に基づいて、システムの構造や仕様を詳細にまとめた「基本設計書」を作成します。この「基本設計書」には、システムのすべての機能やデータベース構成(テーブル定義やER図)、画面や帳票のレイアウトなどの他、テスト計画が盛り込まれることもあります。
詳細設計では、必要なコンポーネント(小さなプログラム単位)の処理、バッチ処理等を設計します。また、画面や帳票まわりの細部の設計、システムが取り扱うデータファイルの仕様設計、詳細なデータベース設計(物理設計)などを行い「詳細設計書」を作成します。
これらの設計工程では、各設計書のレビュー(評価、改善指摘)が重要です。
各設計書間で、上位の設計書の内容が下位の設計書に漏れなく、また矛盾なく引き継がれるようになっていることもチェックします。
コーディングは前述の詳細設計書に基づいてプログラムを書く作業です。
その構造に基づき使用する必要な変数や関数、制御文(ifなど)を決定します。さらにデータベースとの連携から関数の使用方法や変数の取扱い方法を選択します。
コードレビューでは、明確で読みやすいコードで書かれているか?テストしやすいコードか?セキュリティ面に問題ないか?といったチェックが必要となります。
テスト工程のイメージとして、V字モデルの流れを図4に示します。
【図4 ソフトウェア開発のテスト検証(V字モデル)】
このV字モデルは、ソフトウェア開発における「要件定義」から「システムテスト」までの一連の流れを表したモデルです。
V字の左側は、上流工程の「要件定義」から順番に右下がりに記載します。V字の右側は、テスト工程を右上がりに記載します。V字の左右部分を比較し、各テスト工程がどの設計工程を検証するためのテストなのか、何に着目したテストかを理解することができます。
各テスト工程では、各設計工程の要求仕様や設計内容を分析して検査すべきテスト項目を設計します。これを「テスト設計」と呼びます。
「単体テスト」とは、ソフトウェアのソースコードの最小単位で構成されるプログラム(モジュール)毎に、詳細設計通りに動くか否かを確認するテストです。
具体的には、使用するデータ、使用手順、操作方法も含めて問題の有無を判断します。このテストにより、プログラム内のバグ(障害)を早期に発見・修正することができます。
「結合テスト」とは、開発したソフトウェアが、基本設計通りに動くか否かを確認するテストです。単体テストが完了したすべてのモジュールを結合し、求められた機能が正しく動作するかを確認します。
具体的には、本番環境と同様の使用環境において、組み合わせたモジュールの機能にバグが有るか否かを確認することが主な目的です。このテストにより各モジュール間の連携や、モジュール内バグの発見・修正が可能となります。
「システムテスト」とは、ソフトウェア開発の最終工程で、ソフトウェア全体の動作・振る舞いや能力が、要件定義で規定された仕様通りであるかを確認するテストです。「総合テスト」と呼ばれることもあります。
システムテストは、単体テスト、結合テストの後に行われます。
具体的には、お客様での運用を想定したテストであり、お客様にソフトウェアをリリースする直前の最終確認として実施されます。
テスト工程での品質管理は、各テストで発生した問題(バグ等)を解決し、再発防止につなげる活動です。
各テスト工程で摘出したバグは、事前に予測した目標値を超えているか、バグの中身は軽度か重度か?他のモジュールでも同様のバグが起こっている等の傾向分析もあわせて実施します。
さらに、上記バグが発生した原因や見逃した原因を、上位の検査工程、コーディング工程だけでなく設計工程まで遡って対策を行います。
ソフトウェア開発の品質管理において特に重要なポイントは、次の3点です。
ソフトウェアの品質管理では、上流工程の文書(ドキュメント類)の品質とテスト工程でのバグ収束状況が重要な管理ポイントとなります。
その結果から、リリース後に問題を起こさないという保証が得られるのです。
(アイアール技術者教育研究所 NKJ)
《引用文献・参考文献》