---------------------------------------------------------------------
(設問ア)
---------------------------------------------------------------------
第I 業務の概要と監査業務とのかかわり
---------------------------------------------------------------------
1 業務の概要
----
(品質チェック)
私はパソコンからサーバ上で動作するソフトウェアの
品質管理を担当しており、ソフトウェア開発の開発計画、
システム設計から保守に到るまで開発工程での作業品質
とその成果物(ドキュメント、ソフトウェア等)の品質
を第三者の立場でチェック・管理する業務を行っている。
(検査業務)
さらにソフトウェア最終成果物(システム、パッケー
ジ等の製品)を実環境にて操作し、システム要求あるい
は製品仕様通りに正しく動作するかの検査業務も担当し
ている。
----
2 監査業務とのかかわり(立場、役割)
----
私は、基本ソフトウェアの品質管理業務のリーダーと
して、開発計画書、ソフトウェア仕様書、開発完了報告
書等、各開発工程での作業品質、成果物品質を第三者的
にチェックし、ソフトウェアの品質向上を指導する立場
にある。ソフトウェアの品質を確保する為に、従来は検
査中心でソフトウェア誤りを見つけ、開発部門にその誤
りを修正させることが主であった。しかし、近年はソフ
トウェアの品質は上流工程で作りこむという立場に立ち、
開発計画書、ソフトウェア仕様書のレビュー実施内容、
特にレビュー密度(指摘件数/頁)、開発計画段階での
試験計画内容(試験方針、試験密度計画、誤り検出目標
件数など)の内容を第三者的、かつ監査的立場でチェッ
クしシステムの信頼性を確保することに重点を置いて業
務を行っている。
---------------------------------------------------------------------
(設問イ)
---------------------------------------------------------------------
第II ソフトウェア品質特性とデザインレビュー
---------------------------------------------------------------------
1 ソフトウェアの品質特性
----
1.1 ソフトウェアの一般的品質特性
--
品質特性には機能性、信頼性、使用性、効率性、移植
性、保守性がある。また、ソフトウェアの品質特性のう
ち、充足されていて当たり前であり不十分であるとユー
ザに不満足を与える「当たり前品質」と、ユーザが製品
自体に魅力を感じ満足感をもつ「魅力的品質」に分ける
ことができる。その中でも当たり前品質としての信頼性
が確保されていないと顧客に多大な迷惑をかけることに
なる。その為、当社では信頼性が一番重要であるとの認
識に立ち、その確保に力点を置いている。
--
1.2 デザインレビューの重要性
--
ソフトウェアの品質はハードウェアと異なり、設計品
質が全てである(製造品質がない)。従って、ソフトウェ
ア開発は、誤りを作りこむ設計段階とその誤りを除去す
るテスト段階に分けることができる。しかし、誤りの修
正は後工程にいけばいくほど、その修正に費用と工数が
かかる為、設計段階の上流工程で如何に品質を作りこむ
かがキーポイントとなる。上流工程で品質、特に信頼性
を確保する為には、開発計画の段階から各開発段階の品
質目標を定め、それを達成する為の施策が必要である。
その施策として、開発計画、システム設計の各開発段階
でデザインレビューを実施することが品質向上に有効で
あると考え、デザインレビューの第三者的・監査的
チェックに力点をおいて業務を行っている。
----
2 開発局面に実施するデザインレビューの進め方
----
2.1 上流工程での品質確保
----
当社ではソフトウェアの品質特性の内でも「当たり前
品質」である信頼性が特に重要と考え、開発製品のプロ
ダクト信頼性目標(フィールド誤り率:フィールドで発
生した誤り件数/開発量にて算出)を設定している。その
目標を達成する為には開発の上流工程で品質を確保する
ことが必須であるとの認識に立ち、その実現手段として
デザインレビューを重点的に実施している。
----
2.2 デザインレビューの実施手順・審査項目
----
ソフトウェアの設計品質を客観的に評価するため、デ
ザインレビュー時の審査項目について品質管理部門、開
発部門のメンバで相談してチェックリストを作り、その
チェックリストに基き開発担当部門と関連部門とでデザ
インレビューを実施している。主なチェックポイントは
以下の通りである。
(1)開発計画書
a.顧客要求事項である顧客業務の概要、情報システムの
目的、役割、要求機能を記載した文書になっているか。
b.作成するドキュメント及びドキュメントの検認者を明
確にしているか。
c.ドキュメントに対するレビューを規則化したデザイン
レビュー実施細則に則して実施しているか、レビュー
実施者に開発部門の担当者だけでなく営業部門、品質
管理部門のメンバーが参画しているか。
d.現行システムから新システムへの移行について、計画
を立案する上での方針を記述しているか。
e.顧客に新システムを引き継いだ後の保守について、計
画を立案する上での方針を明確にしているか。
f.システムの信頼性目標値(フィールドでの誤り率(誤り
件数/開発量)及び性能目標とこれを達成する為の作業
品質(プロセス品質)目標(レビュー実施率、レビュー
工数、レビュー指摘率など)を設定しているか。
(2)システム仕様書
a.顧客要求事項、市場要求事項を充足した仕様となって
いるか。
b.システムの運用目的、運用上・保全上の制約、運用方
式、他システムとの接続が記述されているか。
c.操作性に一貫性があることを確認しているか。
d.前版との上位互換は考慮されていることを確認してい
るか。
e.バックアップ機能、フェールセーフ機能、イニシャラ
イズと立ち上げ機能及び異常処理が考慮されているか
を確認しているか。
f.システム運転の連続性に関する制限事項、拡張への配
慮がなされていることを確認しているか。
g.障害に対するシステムへの影響度(リスク分析)、障害
発生時の検出機能、障害からの回復機能、障害発生後
の解析手段を確認しているか。
---------------------------------------------------------------------
(設問ウ)
---------------------------------------------------------------------
第III デザインレビューにおける監査手続き
---------------------------------------------------------------------
私は日頃の品質管理業務の一環として、各開発のデザ
インレビューが適切に計画され、実施されているか否か
について以下の監査証拠を入手し、点検・評価を実施し
ている。
また、実際にデザインレビューに参加し、指摘事項あ
るいは議論された内容について第三者的・監査的立場で
チェックを行っている。
----
1.開発計画でのデザインレビュー計画
----
開発計画段階にデザインレビュー実施計画(対象物、
デザインレビュー方式(書面、会議等)、参加部門又は
参加者、レビュー時期等)を明確にしているかを確認す
る。
さらに、開発計画審査会の議事録を閲覧し、デザイン
レビュー計画が担当部門の承認を得ているか、かつ関連
部門において議論され、合意されているかを確認する。
----
2.デザインレビューの指摘事項シート・議事録
----
デザインレビュー実施時の指摘事項シートと議事録を
入手・閲覧し、定められた規則に則ってデザインレビュ
ーが実施されていること、その結果を責任部門長が承認
していることを確認する。
----
3.開発部門・関連部門での周知徹底
----
開発担当者、関連部門担当者にヒアリングを実施し、
デザインレビューを実施する際、定められた規則、基準
に則って実施することが周知徹底されているかを確認す
る。
----
4.デザインレビュー結果の評価・反映
----
デザインレビュー議事録を入手・閲覧し、デザインレ
ビューによって指摘された内容を評価した上でドキュメ
ントあるいはプログラムに反映すべきことが正しく反映
されているか、その内容が責任部門長に承認されている
か、かつ上位設計・下位設計担当者あるいは関連部門で
議論され合意を得ているかを確認する。
----
5.デザインレビュー細則の周知徹底
----
関連部門でのヒアリングを実施し、規則化したデザイ
ンレビュー実施細則が周知徹底されているかを確認する。
---------------------------------------------------------------------
第IV 今後の課題
---------------------------------------------------------------------
近年、当社でもプロトタイピング、DOA等の開発手法が
主流になりつつある。従来のウォータフォール開発手法
と異なり、その開発手法に応じたデザインレビュー実施
基準あるいは各開発段階での内部統制機能が必要となっ
てくる。従って、その開発手法の特徴を見極めた上で監
査ポイントの見直しを図っていく必要がある。
[ 戻る ]