ソフトウェア開発の流れと品質管理の重要ポイントを解説《初心者向け》

Pocket

ソフトウェア開発の品質管理【基礎編】

ソフトウェア開発(システム開発)における品質管理は、ハードウェアと全く異なる発想で進められます。
その理由は完成したソフトウェアの良し悪しをハードウェア製品のように手に取りその動きを確認できないためです。ソフトウェア品質は、コンピューター内部のソフトウェアの動きや、プログラミング言語で書かれたソースコードを確認するしかないのです。

本記事では、ソフトウェア開発の基礎と、各開発段階での品質管理の重要ポイントについて解説します。

1.ソフトウェア開発の種類・方式

ソフトウェアの開発方法には大きく2つの方法があります。
1つはウォーターフォール型と呼ばれるタイプです。もう一つはアジャイル型です。
具体的な開発方法の違いについては次に説明します。

 

(1)ウォーターフォール(Waterfall)型開発手法

 

ウォーターフォール型開発手法
【図1 ウォーターフォール型開発手法】


注:図に示された用語の説明

  • 要件定義:ソフトウェア開発などのプロジェクトを開始する前に、必要な機能や要求を分かりやすくまとめる作業を示しています。
  • 設計:ソフトウェアに必要な機能や要求を決めたのちに、ソフトウェアの振る舞いや詳細な機能を決めて文書に落とし込む作業です。
  • 実装:設計で定めたソフトウェアの振る舞いや機能を実現するため、実際に動くプログラムを作る作業です。この工程では、プログラマーがプログラミング言語を使用してソースコードを記述します。
  • テスト:開発したプログラムが問題なく動くか、不具合(「バグ」と言う)が無いかを確認する作業です。もし、バグが発生した場合はそれを修正します。
  • リリース:開発したソフトウェアをお客様へ提供する作業です。この段階ではお客様が自らソフトウェアを運用することが可能となります。

 

ウォーターフォール型とは、開発が「滝の水が上から下へ落ちるように順番に進む」ためその名がつけられています。
ソフトウェアの開発当初では、お客様の要求仕様をまとめ、その後、設計・実装と順番に進みます。最後に各種の確認テストを実施しソフトウェアをリリースします。(図1参照)
この方法はソフトウェアの主流となる開発手法で、大型プロジェクト開発から小規模システムまで多くのケースで利用されています。
お客様の要望や仕様を伺い、それをソフトウェアのシステムとして整理し一つの文書(「要件定義書」)にまとめます。

 

《ウォーターフォール型の特徴》

ウォーターフォール型には、次のようなメリット・デメリットがあります。

  • 「要件定義書」(「システム設計書」と呼ぶこともあります)に基づいてソフトウェアの振る舞いや機能を決める設計書(「基本設計書」、「詳細設計書」)に展開することが可能。
  • 設計書に基づいてプログラムを作成し、動作テストを行うことができる。
  • 最初の時点でソフトウェアの仕様を固めるため、品質や納期、コストが管理しやすくなる。
  • 途中で仕様変更が入った場合には、大幅な設計変更やプログラム変更が伴いますので工数(「人×日数」)が大幅に増加するデメリットがある。

実際の具体例として、大規模システムや信頼性が担保される開発(例:銀行システム、交通システム等)に多く用いられています。

 

(2)アジャイル(Agile)型開発手法

 

アジャイル型開発手法
【図2 アジャイル型開発手法】

 

アジャイル(英:Agile)型とは、『素早い』『活発な』を意味する開発手法です。

アジャイル型開発は、短い期間での開発サイクル(設計→実装→テスト)を何度も繰り返し、ソフトウェアを完成に導く手法です。
特にお客様の仕様が、部分的機能しか決まっていない段階でソフトウェア開発をスタートする場合に用いられます。(図2参照)

 

《アジャイル型の特徴》

アジャイル型の開発には、次のようなメリット・デメリットがあります。

  • ソフトウェア機能ごとに小さな開発サイクルを何度も繰り返すことができる。
  • お客様からのフィードバックや市場の要求が変化した場合に応じて、柔軟に仕様を変えることができる。
  • 開発を進める際にはソフトウェア開発者とお客様の緊密なコミュニケーションが必要となる。
  • 「開発計画遅れ」や「設計文書の完成度不足」となる可能性があり、ソフトウェア全体の品質管理や工数管理に課題が発生する場合がある。

アジャイル型は、お客様のニーズ変化が激しい業界に向いていることが多いです。
具体例として「日本航空(JAL)の予約・発券システム」の開発にも採用されているようです。

 

2.ソフトウェア開発の工程

ソフトウェア開発では、一般的に図3に示すような工程(開発プロセス)で行われます。

 

ソフトウェア開発の工程
【図3 ソフトウェアの開発工程と作成文書(成果物)】

 

システムの構想・全体像を具体化するための要件定義や設計を行う工程を「上流工程」と呼び、コーディング(実装)やテストの工程を「下流工程」と呼ぶことが多いです。

また、レビュー記録とは、ソフトウェア開発時に作成する文書やソースコードについて、レビュー(評価・改善指摘)を行なった記録を残す作業です。具体的には、レビュー時に行われた審議内容や指摘事項、改善提案などを記載します。会議時間などの進捗状況や参加メンバーを記載し、各種設計やテストにてバグが発生した場合の見直し資料として使用されます。

 

(1)要件定義と設計

ソフトウェア開発の設計仕様を固める上流工程についてその進め方や管理ポイントを説明します。

ソフトウェアの設計は、一般的に大きく次の3つのステップに分類されます。

  • 要件定義
  • 基本設計
  • 詳細設計(※詳細設計を「下流工程」の一部とする考え方もあります)

 

① 要件定義

要件定義」とは、開発するソフトウェアの要件(機能、仕様、性能、品質、納期、コスト、開発工数等)を明確にする工程です。この要件がしっかりできていないと、後から「追加仕様」や「矛盾した機能」が発生し納期や費用が大幅に増加します。

そのためお客様や関係者と十分すり合わせた「要件定義書」を完成させる必要があります。

 

② 設計工程(基本設計、詳細設計)

基本設計では、「要件定義」に基づいて、システムの構造や仕様を詳細にまとめた「基本設計書」を作成します。この「基本設計書」には、システムのすべての機能やデータベース構成(テーブル定義やER図)、画面や帳票のレイアウトなどの他、テスト計画が盛り込まれることもあります。

詳細設計では、必要なコンポーネント(小さなプログラム単位)の処理、バッチ処理等を設計します。また、画面や帳票まわりの細部の設計、システムが取り扱うデータファイルの仕様設計、詳細なデータベース設計(物理設計)などを行い「詳細設計書」を作成します。

これらの設計工程では、各設計書のレビュー(評価、改善指摘)が重要です。
各設計書間で、上位の設計書の内容が下位の設計書に漏れなく、また矛盾なく引き継がれるようになっていることもチェックします。

 

(2)コーディング(実装)

コーディングは前述の詳細設計書に基づいてプログラムを書く作業です。
その構造に基づき使用する必要な変数や関数、制御文(ifなど)を決定します。さらにデータベースとの連携から関数の使用方法や変数の取扱い方法を選択します。

コードレビューでは、明確で読みやすいコードで書かれているか?テストしやすいコードか?セキュリティ面に問題ないか?といったチェックが必要となります。

 

(3)テスト工程

テスト工程のイメージとして、V字モデルの流れを図4に示します。

 

ソフトウェア開発のテスト検証(V字モデル)
【図4 ソフトウェア開発のテスト検証(V字モデル)】

 

このV字モデルは、ソフトウェア開発における「要件定義」から「システムテスト」までの一連の流れを表したモデルです。

V字の左側は、上流工程の「要件定義」から順番に右下がりに記載します。V字の右側は、テスト工程を右上がりに記載します。V字の左右部分を比較し、各テスト工程がどの設計工程を検証するためのテストなのか、何に着目したテストかを理解することができます。

各テスト工程では、各設計工程の要求仕様や設計内容を分析して検査すべきテスト項目を設計します。これを「テスト設計」と呼びます。

 

① 単体テスト

「単体テスト」とは、ソフトウェアのソースコードの最小単位で構成されるプログラム(モジュール)毎に、詳細設計通りに動くか否かを確認するテストです。

具体的には、使用するデータ、使用手順、操作方法も含めて問題の有無を判断します。このテストにより、プログラム内のバグ(障害)を早期に発見・修正することができます。

 

② 結合テスト

「結合テスト」とは、開発したソフトウェアが、基本設計通りに動くか否かを確認するテストです。単体テストが完了したすべてのモジュールを結合し、求められた機能が正しく動作するかを確認します。

具体的には、本番環境と同様の使用環境において、組み合わせたモジュールの機能にバグが有るか否かを確認することが主な目的です。このテストにより各モジュール間の連携や、モジュール内バグの発見・修正が可能となります。

 

③ システムテスト(別名「総合テスト」)

「システムテスト」とは、ソフトウェア開発の最終工程で、ソフトウェア全体の動作・振る舞いや能力が、要件定義で規定された仕様通りであるかを確認するテストです。「総合テスト」と呼ばれることもあります。
システムテストは、単体テスト、結合テストの後に行われます。

具体的には、お客様での運用を想定したテストであり、お客様にソフトウェアをリリースする直前の最終確認として実施されます。

 

④ 各テスト工程での品質管理

テスト工程での品質管理は、各テストで発生した問題(バグ等)を解決し、再発防止につなげる活動です。
各テスト工程で摘出したバグは、事前に予測した目標値を超えているか、バグの中身は軽度か重度か?他のモジュールでも同様のバグが起こっている等の傾向分析もあわせて実施します。
さらに、上記バグが発生した原因や見逃した原因を、上位の検査工程、コーディング工程だけでなく設計工程まで遡って対策を行います。

 

3.文書の品質向上とバグ収束がポイント

ソフトウェア開発の品質管理において特に重要なポイントは、次の3点です。

  • 1) 各設計レビューでは、優秀なレビューアと十分なレビュー時間を設けることが、バグ防止には非常に大切です。
  • 2) コードレビュー作業では各コード自体のレビューの他に、セキュリティーの脆弱性を防ぐコード確認が必要となります。
  • 3) テスト工程の目的はリリース後に問題を起こさないことです。そのため各テストのバグ有無確認及びそのバグの改善だけでなく、潜在バグが摘出されていることに注意を払います。

ソフトウェアの品質管理では、上流工程の文書(ドキュメント類)の品質テスト工程でのバグ収束状況が重要な管理ポイントとなります。
その結果から、リリース後に問題を起こさないという保証が得られるのです。

 

(アイアール技術者教育研究所 NKJ)
 


《引用文献・参考文献》


Pocket

製造業eラーニングTech e-L講座リスト

製造業向けeラーニングライブラリ

アイアール技術者教育研究所の講師紹介

製造業の新入社員教育サービス

技術者育成プログラム策定の無料相談受付中

スモールステップ・スパイラル型の技術者教育

技術の超キホン

機械設計マスターへの道

生産技術のツボ

早わかり電気回路・電子回路

品質保証塾

機械製図道場

スぺシャルコンテンツ
Special Contents

導入・活用事例

テキスト/教材の制作・販売