ソフトウエア開発マネジメントに関する考察 : ソフトウエア開発の品質マネジメント編

全文

(1)上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. 〈論文〉. ソフトウエア開発マネジメントに関する考察 ―ソフトウエア開発の品質マネジメント編― A Study on Management of Software Development ―Phase1 : Quality Management of Software Development―. 吉崎浩二 YOSHIZAKI Kouji. 現在の高度情報化社会ではあらゆる分野にコンピュータが適用され、今や社会のインフラになっているので、ひとたび故障すると大きな社会問題となる危険性が高い。また、規模的にもコスト的にも、ハードウェアに比してソフトウエアの占める割合が急増している。それゆえ、ソフトウエアシステムによる経済的損害、人的災害の発生する可能性が大きくなりつつあり、その影響は法的な責任の追及にまで至ることが多い。このように、ソフトウエア開発マネジメントの必要性は高まるばかりであるが、ソフトウエア開発の品質、コスト、開発期間そして満足度などに関して、十分にマネジメントされているとは言い難い。むしろますます大きな問題を抱えつつある。その大きな要因は「ソフトウエアを開発する者は開発状況を見せる努力と工夫が十分とはいえず、ソフトウエア開発を管理する者は見ようとする努力と工夫が十分ではない。」ところに課題があるといえる。なかでも、ソフトウエア開発の品質マネジメント、コストマネジメント、スケジュールマネジメントが重要であるが、ここでは特にソフトウエア開発の品質マネジメントについて考察する。. キーワードソフトウエア開発、マネジメント、ソフトウエア品質、ソフトウエア品質マネジメント、ソフトウエア品質特性、品質保証体系、品質保証活動、見せる努力と工夫、見る努力と工夫. ― 203 ―.

(2) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. 1 はじめに現在の高度情報化社会ではあらゆる分野にコンピュータが適用され、今や社会のインフラになっているので、ひとたび故障すると大きな社会問題となる危険性が高い。規模的にも、コスト的にもハードウェアに比してソフトウエアの占める割合が急増している。ハードウェア自体は LSI 化が進み品質はますます向上している中、コンピュータを動かすソフトウエアも高品質でなければならない。また、ソフトウエアシステムの社会的責任が拡大しつつある。その背景にはシステムの大規模化と複雑化がある。直接的または間接的にもその影響度は高くなりつつあり、かつ広範囲にわたる傾向が強い。このように、ソフトウエア開発のマネジメントの必要性は高まるばかりであるにもかかわらず、ソフトウエア開発の品質、コスト、開発期間そして満足度などに関して、十分にマネジメントされているとは言い難い。むしろますます大きな問題を抱えつつある。その大きな要因はソフトウエア開発のマネジメント教育が十分いきわたっていない事にある。また、「ソフトウエアを開発する者は開発状況を見せる努力や工夫が十分とはいえず、ソフトウエア開発を管理する者は見ようとする努力と工夫が十分ではない。」ところに課題があるといえる。ソフトウエア開発をマネジメントすべきことは品質、コスト、スケジュールと多々あるが、ここではソフトウエア開発の品質マネジメントについて考察する。. 2 今なぜソフトウエア開発マネジメントなのか今なぜソフトウエア開発マネジメントなのか。そのソフトウエア開発マネジメントの必要性について考察する。 2．1 ソフトウエア開発マネジメントの必要性その 1：開発規模やコスト面でのソフトウエアの占める割合が急増している。開発規模やコスト面で、ハードウェアに比してソフトウエアの占める割合が急増している。ハードウェア自体は LSI 化が進み品質はますます向上している中、コンピュータを動かすソフトウエアも高品質でなければならない。その 2：ソフトウエアシステムの社会的責任が拡大している。現在の高度情報化社会ではあらゆる分野にコンピュータが適用され、今や社会のインフラになっているので、ひとたび故障すると大きな社会問題となる危険性が高い。. ― 204 ―.

(3) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. その背景にはシステムの大規模化と複雑化がある。直接的または間接的にもその影響度は高くなりつつあり、かつ広範囲にわたる傾向が強い。その 3：法的責任が高まっている。その背景にはソフトウエアシステムによる経済的損害、人的災害の発生する可能性が大きくなりつつあり、その影響は法的な責任の追及にまで至ることが多い。その 4：ソフトウエアの品質の重要性と品質向上のニーズが高まっている。 NASA システム、国防省のシステムなどミッションクリティカルなシステムの必要性が高まる。また、銀行のオンラインシステム、航空機や新幹線の座席予約システムなどの大規模リアルタイムシステムの必要性も高まる。その 5：流通ソフトウエアの増大に伴い、ソフトウエア品質の影響がますます高まっている。たとえば ①人間の生命への影響 ②国家の安全保障 ③社会生活への影響（個人情報保護など） ④消費者保護 ⑤企業の生存競争 ⑥利用者の能率と満足などである。以上記述したように、ソフトウエアマネジメントの必要性は高まるばかりであるにもかかわらず、ソフトウエア開発の品質、コスト、開発期間そして満足度などに関して、十分にマネジメントされているとは言い難い。むしろますます大きな問題を抱えつつある。その大きな要因はソフトウエア開発のマネジメント教育が十分いきわたっていない事にある。また、「ソフトウエアを開発する者は開発状況を見せる努力や工夫が十分とはいえず、ソフトウエア開発を管理する者は見ようとする努力や工夫が十分ではない。」ところに課題があるといえる。ソフトウエアを開発する者もソフトウエア開発をマネジメントする立場の者もソフトウエア開発のマネジメントの手法や技法を身につけ、実践し試行錯誤し改善しながら自分たちのものにしてゆく必要がある。ソフトウエア開発をマネジメントするべきことは多々あるが、ここではソフトウエア開. ― 205 ―.

(4) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. 発の品質マネジメントについて考察する。多くのソフトウエア開発が SE の並々ならぬ努力と尽力ににもかかわらず、品質的にもコスト的にも納期的にも不成功に終わっているケースが多いが、これはひとえに開発者の責任だけではない。むしろ、多くの場合はソフトウエアマネジメントの失敗が要因であることが多い。大いに反省すべきである。. 3 ソフトウエアの品質とはソフトウエア開発における品質マネジメントは特に重要であるにもかかわらず、マネジメントする管理者も開発する SE やプログラマーも「ソフトウエアの品質とは何か」という基本的な考えを理解せずに活動している場合が多い。ここではソフトウエア品質マネジメントの原点に戻って「ソフトウエアの品質とは」について考察する。 3．1 JIS 規格による品質の定義（JISX0129-1） JIS 規格によると品質とは品物またはサービスが、使用目的を満たしているかどうかを決定するための評価の対象となる固有の性質・性能の全体をいう。 3．2 ソフトウエア品質のとらえ方［1］［2］また、ソフトウエアの品質のとらえ方も見方によってさまざまである。ソフトウエア品質のとらえ方（その 1）「品質水準」によって下記のようなとらえ方がある。 ①当たり前品質製品が当然備えるべき最低限必要な品質を云う。 ②魅力的品質使用者が製品そのもののどんな点に魅力を感じるかを問う。ソフトウエア品質のとらえ方（その 2）「要求との比較」や評価視点から下記のようなとらえ方がある。 ①適合品質（外部品質）：ユーザの視点品質特性のうち、主として利用者の視点からの特性をいう一般に品質特性と言えば外部特性を意味する事が多い。 ②設計品質（内部品質）：開発者、管理者の視点品質特性のうち主として開発者視点からの特性を云う。. ― 206 ―.

(5) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. モジュールの独立性などはその例である。内部特性は外部特性に影響を与えると言う点で重要視される。 3．3 ソフトウエアの定義［3］ソフトウエアとはという質問に対して多くの関係者はプログラムであると答えることが多いが、それだけではないことに注意しなければならない。 JIS 規格（JISX0001-1987）においては v プログラムだけではなく、 v 手順：要求定義書、設計書、 v 規則：コーディング規約 v 関連文書：取り扱い説明書、運用マニュアルを含むと定義されている。［4］ WIPO（世界知的所有権機関）による定義では. v プログラムに加え、 v 設計書 v 関連資料を含む。ここで、注意しなければならないことは最も大切なものつまり、データ（情報）が明記されていないことである。おそらくデータ（情報）はプログラムの中に含まれていると思われるが、データオリエンテッドな情報システムではデータ（情報）が最も重要視されることを考えるとやはり、データ（情報）は明記すべきと思われる。以上のことから一般にソフトウエアとは v データ（情報：これが最も重要） v OS、アプリケーションプログラム、ユーティリティなどのプログラム v 仕様書、設計書、運用マニュアルなどのドキュメント v 開発マネジメント技法、開発設計技法、テスト技法などの開発手法 v 利用技術などから構成されるものである。したがって、ソフトウエア開発のマネジメントの対象はプログラムだけでなく、上記で定義したソフトウエア全体を含むことを忘れてはならない。 3．4 ソフトウエアの特徴（ハードウエアとソフトウエアの違い）下記のようなソフトウエアの特徴（ハードウエアとソフトウエアの違い）を理解した上. ― 207 ―.

(6) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. でソフトウエア開発のマネジメントを工夫する必要がある。 v 概念的（抽象的）である。 v 個人的開発になり易く、かつ人的な手作業による生産である。 v 工学的手法が確立されておらず、工業化が遅れている。したがって、効率が悪く生産性が低い。 v 開発要素が多く、ソフトウエアは開発が行われるのもので、製造が行われるものではない（設計部門の職種であって、製造部の職種ではない）。 v ほとんどのソフトウエアは既存の部品の組み合わせではなく特注品であり、経験的で定量化が困難である。 v 常に改良改善が要求され、保守業務が多い。 v 複写による複製が可能で、ソフトウエアは劣化しない。 v 特許よりは著作権で保護される。以下にソフトウエアとハードウェアの相違を表形式でまとめてみた。ソフトウエア開発をマネジメントするに当たり、この程度の相違を認識すべきである（表 3．1、3．2、3．3）。. 表 3．1 ソフトウエアの特徴（1）項目生産物生産性（過去 10 年間）信頼性論理的品質保証開発の仕方. ハードウエア目に見えやすい有形製品 50-100 倍磨耗、劣化がおこる可試作・評価後に量産. ソフトウエア目に見えにくい無形製品 2-3 倍永久に保証される完全には不可能多くは開発即製品化. 表 3．2 ソフトウエアの特徴（2）項目自動化有償化法的保護性能測定生産規模. ハードウエア進んでいる容易特許・実用新案容易（例）ロット数. ソフトウエア部分的に実現やや難しい著作権ハードウエアや人間に依存する事が多く、難しい人月・行数. 表 3．3 ソフトウエアの特徴（3）項目標準化保全の仕方部品化. ハードウェア進んでいるパッケージ交換標準部品. ― 208 ―. ソフトウエア一部の分野変更流用.

(7) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. 3．5 ソフトウエア品質の影響例ここで、ソフトウエア品質マネジメントの失敗例を考察しておく。（その 1）のぞみ号：プログラム修正ミスにより、一定以上のスピードアップが不可能になり、大幅にダイヤルが遅れてしまった。企業のイメージダウン、損害賠償問題につながる（www.kgtrain.net）。（その 2）システムのセキュリティコンピュータ犯罪：派遣技術者が開発中に銀行システムのテスト端末から無断でお金を引き出した。テスト中にもかかわらず本番ファイルの使用を許可してしまった。特定端末に限定すべきであった（www.sipec-squre.net）。（その 3）プログラミング・ミスアメリカの第 1 次金星ロケットが Fortran の DO 文 1 個のミスで失敗した［20］。（その 4）2000 年問題［5］ニュージランドの発電所にてマイコン制御の不具合が発生し、停電した。製造年月日印字にミスを発生：賞味期限内の商品を誤って破棄してしまった。（その 5）法的責任の追及される事例［21］システム：放射線治療機（Therac25）製造元：アトミック・エナジー社（カナダ）発生被害：死亡事故（2 名）原因：コンソール画面上のパラメータを修正する為に、「上向きキー」を利用すると、大量の放射線が照射される。責任の範囲：バグにより受けた損傷については、メーカーがほぼ確実に厳重な責任を負う。などの例がある。改めてソフトウエアの品質の重要性を実感する。 3．6 品質特性の考え方ソフトウエアの品質を評価する品質特性について考察する。（1）Wulf のソフトウエア品質特性［6］ソフトウエア品質は障害がないことによってのみ評価されるべきではないという立場から、Wulf が最初にソフトウエア品質特性を体系づけた。 v 保全性／更新性 v 堅ろう性 v 明確さ. ― 209 ―.

(8) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. v 性能 v コスト v 移植性 v 人間的要素から構成されるとした。その特長は信頼性という表現は含まれておらず、「堅ろうさ」という表現で表している。また、「コスト」が含まれていることに特徴がある。（2）Boehm（TWA 社）のソフトウエア品質特性［22］品質特性の構成が下記のように階層化されているのが特長である。 v 移植性 v 使用性 ° 信頼性 ° 効率 ° 人間工学 v 保全性 ° テスト容易性 ° 理解性 ° 更新性アメリカ国防省の要請に応じて研究し、第 2 回 ICSE（International Conference on Software Engineering）において上記モデルを発表している。［7］［8］（3）ソフトウエア品質特性（ISO）（ISO/IEC9126-1）. 現在ではこの ISO による六つのソフトウエア品質特性が最も多く知られている（表 3．4）。 v 機能性 v 信頼性 v 使用性 v 効率性 v 保守性 v 移植性. ― 210 ―.

(9) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. 表 3．4 ソフトウエア品質特性（ISO：ISO/IEC9126-1）品質特性機能性信頼性使用性効率性保守性移植性. 品質副特性（例）合目的性など成熟性など理解性、習得性など実行効率性など解析性、変更性など環境適応性など. （4）ソフトウエア品質特性（ISO：ISO/IEC9126-1）の詳細六つの ISO によるソフトウエアの品質特性はそれぞれいくつかの副特性から構成されている。機能性（Functionality）第一の観点（使用目的に対して基本的に要求される機能又は性質）から合目的性（suitability）明示された仕事に対する機能の集合が存在し、かつ適切である。正確性（accuracy）正しい結果と効果、または同意できる結果と効果をもたらすこと。を設定している。第二の観点（使用目的に対して補助的、支援的に必要な機能又は性質）から相互運用性（interoperability）明示されたシステムと相互作用できる能力。データやコマンドを相互にやり取りできる。標準適合性（compliance）応用分野に関係する規格もしくは用法、または、法律、法規を遵守する。セキュリティ（security）プログラム及びデータに対し、偶発的か又は故意かにかかわらず、不当なアクセスを排除する能力。を設定している。信頼性（reliability）明示された条件下で、明示された期間、ソフトウエアの達成のレベルを維持する能力。ソフトウエアに潜在する障害による誤動作や期待される動作からの逸脱。. ― 211 ―.

(10) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. 品質副特性として成熟性（maturity）故障の頻度（MTBF など）障害許容性（fault tolerance）ダウン回数／観測故障回数回復性（recoverability）平均ダウン時間を設定している。使用性（usability）使い勝手／使いやすさを表す。副特性として理解性（understandability）習得性（learnability）運用性（operability）を設定している。効率性（efficiency）如何に速く処理できるか、また如何に有効に資源を使用するかを示す属性である。副特性として時間効率性処理速度処理能力資源効率性資源使用量資源使用率を設定している。保守性（maintainability）改定を行うために必要な労力に影響する属性である。内部品質でもあるが、利用者にとっても大きな関心事。副特性として解析性（analyzability）変更性（changeability）. ― 212 ―.

(11) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. 安定性（stability）試験性（testability）を設定している。移植性（portability）ソフトウエアをある環境から他の環境へ移す際のソフトウエアの能力をもたらす属性である。副特性として環境適応性（adaptability）適用可能機種率適用化の OS 率など設置性（instability）パラメータ変更率再コンパイル率など規格適合性（conformance）置換性 replacability）ソースコード変更率などを設定している。以上、ソフトウエアの品質とは何かについて考察してきたが、ソフトウエアの品質をマネジメントするに当たり、最低限、ここで記述したソフトウエアの品質の定義については熟知しておく必要がある。ソフトウエアの品質のマネジメントを考えるに当たり、品質とは何かという原点に戻って考察することが重要であるにもかかわらず、このことを理解していないシステムエンジニア（SE）ならびに管理者が多いことに驚かされる。. 4 ソフトウエアの品質保証体系についてソフトウエアの品質を保証するためには生産者は消費者の要求する品質が十分に満足されることを保証するソフトウエアの品質保証体系（仕組み、体制）を準備する必要がある。にもかかわらず、このことを考慮することなく、ソフトウエアの品質向上のみを要求する管理者が多い。ここでは、品質を保証するとはどういうことか、そして、そのためにはいかなる品質保証体系が必要かを考察する。. ― 213 ―.

(12) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. 4．1 品質保証とは［9］ソフトウエアの品質を保証するとはどういうことか考察してみる。 JIS の定義（JIS Z 8101-1981）消費者の要求する品質が十分に満足されている事を保証するために生産者が行う体系的な活動のことをいう。品質保証は消費者指向でなければならない。品質保証はユーザの要求する機能を製品に実現し、ユーザの立場に立って、品質を作り出すことが重要である。 ISO の定義（ISO8402）製品またはサービスが、所与の品質要求を満たしている事の妥当な信頼感を与える為に必要な計画的および体系的活動のすべてをいう。 3 つの注をつけている。 ①顧客の要望を十分に反映している事。 ②設計または仕様の妥当性を常時評価すると共に、製造、据付けおよび検査作業の確認と監査も必要であること。 ③品質保証は経営の一つの道具である。 JIS と ISO との相違について JIS の考え方はどちらかというと品質中心（どちらかというとメーカ視点）である。 ISO の考え方は信頼を与える、信頼を得る（信用、責任）（どちらかというとカスタマー視点）である。 4．2 品質保証の変遷（1）1 次産業中心時代は買い手危険負担八百屋でスイカを買う際に、反射的に手でポンポンとたたきながら、その音を聞き、中にスが入ってないか聞き分ける。 2 次産業時代は、もはや買い手の単純な品質評価技術では良し悪しを判定する事は出来なくなった。（2）一定期間の保証（compensation）（3）売り手危険負担（4）消費者保護の立場 Consumer Movement（消費者運動）による品質保証である。以下の消費者保護の権利を保証するものでなければならない。. ― 214 ―.

(13) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. ①安全を求める権利 ②知らされる権利 ③選ぶ権利 ④意見を聞いてもらう権利 ⑤救済を求める権利 ⑥消費者教育を受ける権利 ⑦健康な環境を求める権利 4．3 品質保証の歴史的変遷 ①検査重点主義からはじまり、 ②工程管理による品質管理検査よりもまず工程〔製造工程）管理を行うことが先決 ③消費者指向の品質管理 ④「設計と工程」重視の品質保証プロセス重視設計と工程（上流工程）での品質を作り込み新製品開発の品質保証 ⑤「製品責任」に重点を置いた品質保証へ進展している。 4．4 ソフトウエア品質保証の歴史的変遷 ①デバッグ支援としての検査時代（プログラムの機能テストのみを請け負っていた。）からはじまり、 ②検査強権時代 ③生産技術・品質評価指向の時代計画・開発工程を重要視し、プロセスにおける品質評価と生産技術に重点を置く。 ④広義の品質に対する検査時代信頼性だけでなく、広義の品質（性能、保守性、使いやすさ）についての検査を重要視する。 ⑤組織による品質保証時代. ― 215 ―.

(14) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. TQC 活動（全組織、全階層、全員による品質活動の取り組み、経営戦略の核の一つとして品質重視） ISO9000 認定資格の取得等へ進展している。 4．5 品質保証と検査ソフトウエア品質は「設計工程」で作り込まなければならない。開発工程毎の品質の確保とソフトウエアバグが後工程にそのまま引き渡されないように品質の検査をする必要がある。検査の目的は工程がきちんと管理され、各工程の品質の作り込みがうまくいっていることを確認することである。それでもある程度のバグは必ずあるから検査によって未然に防止することが重要となる。ウォータフォールモデルではテスト工程をプロセスに組み込んでいる。要求分析から始まり、基本設計、機能設計、詳細設計、プログラミングに続いて、単体テスト、結合テスト、システムテスト、受け入れテストなどのテスト工程をくみこむ（V 字モデル）（図 4．1）。図 4．1 V 字モデル図［11］. 4．6 品質保証体系図品質保証を推進するための体系図を設定する必要がある。品質保証体系図を設計するに当たり、重要な留意点を考察する。（留意点 1）横軸に：ユーザ／トップ／各部門（職制）を設定すること。. ― 216 ―.

(15) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. 縦軸に：PDCA のプロセス（開発のステップ）を設定すること。（留意点 2）ソフトウエア品質保証体系図として次の観点で整備していく必要がある。 ①フィードバックのルートが明確である。 ②体系図の縦軸には開発のステップ横軸に職制が書かれ、責任者が明確であること。 ③システム運用のための手段・ツール・帳票・規定・標準が定められていること。 ④次のステップへの進行の可否を決めるための評価項目、評価方法が明確であること。 ⑤システム運営の経験の反省から、システムの改定が行えるようになっていること。（留意点 3）ソフトウエアのライフサイクルと品質保証ライフサイクルの各工程で品質を保証する必要がある。重要な Point は ①品質を早期に作り込むこと ②その品質が目標値を実現していることを検査する事 ③工程毎の品質を確認してはじめて次工程へと品質保証プロセスを推進してゆくことが大切である。ここでは代表的な事例を示す。図 4．2 ソフトウエア品質保証システムの代表事例［10］. ― 217 ―.

(16) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. 5 品質保証活動（ソフトウエア設計プロセスにおける） 5．1 品質保証活動品質保証活動とは品質保証体系に基づき品質を保証するための次の 2 つの活動（活動 1、活動 2）である。品質保証体系だけ存在しても魂が入ってなければ成果は出ない。積極的な品質保証を実現してゆくための具体的な活動と改善が継続的に行わなければならない［12］。活動 1 各開発工程における品質を作り込む活動である。活動 2 各工程でその品質が正しく作り込まれたか否かを評価し、その開発工程にフィードバックする活動である。品質評価活動である。ここでは、活動 1 の各設計工程での品質の作りこみについて考察する。活動 2 のテスト・検査工程での品質評価活動については次章で考察する。 5．2 品質保証活動の種類最も重要と考えられる品質保証活動の種類を下記に記述する。（その 1）教育活動新技術の教育とノウハウの蓄積と伝承（技術の共有化）に関する活動である。（その 2）設計基準・標準活動設計プロセスの設計、プロセスの設計活動の基準並びに設計手法 / 技法の基準設定に関する活動である。（その 3）上流プロセスでの設計審査活動設計プロセスでのデザインレビューやウォークスルーなどの設計審査活動である。（その 4）開発プロセスの機械化推進活動設計プロセスにおける CASE ツール等の活用方針の設定と実現活動である。（その 5）開発プロセスの管理技術の適応構成管理、工程管理、品質管理、コスト管理に関する技法や手法の適用活動である。（その 6）下流プロセスでのテスト／検証／検査活動検査プロセスにおいて、経済的かつ効率的に、適用可能な手法を用いて、開発工程で開発される生産物（ドキュメントとコード、開発成果物）を評価・判定し、次工程に問題を持ち越さない活動である。（その 7）クレーム分析と再発防止策の実施。. ― 218 ―.

(17) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. 保守プロセスにおいてクレーム内容を分析し、再発防止策を設定する。設計や検査プロセスでのチェックリストに反映する活動である。 5．3 ソフトウエア設計プロセスとレビュー（設計審査）についてここでは設計プロセスにおけるレビュー（設計審査）について考察する。（1）レビューの心構え［13］設計審査にあたり、次の 4 点の留意点を忘れてはならない。 ①レビュー結果にはレビュー参加者全員が責任を持つこと。 ②バグを見つけても原作者を非難してはならない ③若手のレビュアが発言しやすくすること。 ④自由で活発な発言ができるように明るくて自由な雰囲気をつくること。以上の 4 つの留意点は必ず守らなければならない。管理者は特に若手のレビュアが発言しやすくなるように配慮しなければならない。（2）要求分析工程での審査の観点要求分析プロセスにおける設計審査の重要な留意点を考える。 v 情報システムの目的が明確であるかを審査する。 ° 対象市場（どのような市場に参入するか）は明確か ° 情報システムで解決しようとする問題点はなにか ° 対象ユーザは明確か ° ユーザの視点からの分析がなされているかなどである。 v 情報システムの特長は明らかか（差別化、附加価値の明確化）を審査する。 ° 思想、概念（商品コンセプト）が明確か ° 情報システムの機能は明確か ° 品質特性を明らかにしているか v 当たり前品質はなにか v 特に、魅力的品質は何かを明確にしておく必要がある。 v なかでも、下記のような注意すべき品質特性を明確にする必要がある。 ° 危険分析をしておく。 v 安全性への配慮は十分か. ― 219 ―.

(18) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. ° 異常検出／警告の必要性と内容 ° フェールセイフ機能／フルプルーフ機能の必要性と内容など。 v 高信頼性への配慮 ° 多重化の必要性と内容 ° 待機冗長設計の必要性と内容などを明確にしておく必要がある。 ° 稼動環境への適合性は適切か v 制約条件が明らかか ° データ処理や通信データのピーク量やタイミングなどは明らかか v 応答速度と処理データ量などのトレードオフを明確にしているか v テスト方法とテストの可能性は検討されているかを明確にしておく必要がある。 ° マンマシン・インターフェースへの配慮 v 現場の利用するオペレータにとって使いやすい、わかりやすいインターフェースであるか（現場の声を反映することが大切である。システム設計者だけの声では見逃しやすいので注意すること）を明確にしておく必要がある。その他にも上記と重複する点もあるが下記の項目にも考慮すべきである。 v 関連特許・文献の調査はしたか v 他社・自社の比較はなされているか v システムの基本目標は明確か v 現状システムの問題点とニーズは明確か v システムの狙いはユーザ指向であるか v システムの特長は導入効果指向か v 外部システムとのインターフェースは明確か v 扱うデータの量と種類は明確か v 性能（レスポンスタイム、精度、データ量など）関する要求は明確か v ISO に品質特性について検討したか ° システム機能について検討されたか ° システム信頼性について検討されたか. ― 220 ―.

(19) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. ° システム使用性について検討されたか ° システム効率について検討されたか ° システム移植性について検討されたか ° システム保守性について検討されたか v 経済的導入効果は試算されているか v 省力的導入効果は試算されているか v 開発費は試算されているか v 人員計画はなされているか。 v セキュリティ、診断システム、ヘルプ機能などの附加価値機能は明確か v システム要求定義書はあるかなどが重要な留意点となる。（3）システム設計工程での審査の観点システム設計プロセスにおける設計審査の重要な留意点を考察する。 v システムの信頼性を確保しているか ° 危険要因と検出方法と信頼性向上策を検討しているか v 安全性について考慮しているか v ハードウェアとソフトウエアが整合しているか v 割り込み処理、異常処理、通信回線の方式や通信可能量などの制約を明確にし、整合性をとっているか v ハードウェアを適切に抽象化して、ソフトウエアとの分離を良くしているか v 使いやすさを十分に配慮したマンマシン・インターフェースが設計されているかなどに留意することが大切である。その他にも上記と重複する点もあるが下記の項目にも留意すべきである。 v ハードウェア規模構成（システム構成）は明確か v フェールセイフ対策はなされているか v システムの特長は明確か v CPU の負荷検討はなされているか v サブシステムに分割されているか v ハードウェアとの機能分担は明確か. ― 221 ―.

(20) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. v 高信頼性方式は確立されているか v 将来システムの拡張性について検討してあるか v ハードウェアの限界を考慮したか v ソフトウエアの過去のバージョンとの互換性はあるか v 使用する OS の検討はなされているか v 使用するデータベース構成は正しいか v 既存設計の流用・再利用方針は明確か v 他社ソフトウエア著作権は侵害していないか v サブシステム間のデータ入力出力は明確か v ソフトウエア開発環境は適切なものか準備されているか v システム試験項目と試験設備は準備されているか v 客先への教育計画は配慮してあるか v 設計手法・基準は設定されているか v システム設計書はあるかなどである。（4）プログラム設計工程での審査の観点プログラム設計プロセスにおける設計審査の重要な留意点を考察する。 v データの抽象化設計をおこなうこと ° 共通データは隠蔽化する v 論理設計の可視化をおこなうこと ° PAD、TFF など図形言語によって論理設計を可視化すること v 複雑な論理設計部分に特に注意して検証することが大切である v データ項目に不足はないか v データの定義域と値域を明確にしているか v ハードウェアを抽象化いているか v データベースの構造は正規化されているか v プログラム間のインターフェースは明確かなどの留意することが重要となる。そのほかにも上記と重複する点もあるが下記の項目も考慮すべきである。 v 既存ソフトウエアの再利用は配慮しているか. ― 222 ―.

(21) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. v ハードウエアインターフェースは明確に定義されているか v データは正規化されているか v 操作の仕方が統一されているか v 操作のやり直しができるか v 操作中、異常になったら元に戻れるか v 少ない操作で目的の機能を果たせるか v フォームは見やすいか v 表示画面に関して統一された設計になっているか v グローバルデータは隠蔽されているか v 支援ツールは準備しているか v 試験項目は明確化されているかなどである。（5）プログラミング工程での審査の観点プログラミング工程における設計検証の重要な留意点を考察する。下記の点に留意する必要がある。 v 構造化プログラミングが実施されているか v 単純なモジュール設計になっているか ° 分岐点は 10-20 以下であるか。そしてネストは 2-4 以下であるか確認すること v 出入り口は一つであるか v データのカプセル化は行われているか v モジュール間のインターフェースは合っているか v 防衛的モジュールとなっているか ° モジュールの入り口で異常な入力データを判定し、防衛することが大切となる v 未定義、無参照データを防止しているか v アルゴリズムを正しく設計しているか v 実行効率を考慮しているか v 例外を十分網羅しているかなどに十分留意することが重要である。. ― 223 ―.

(22) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. そのほかにも上記と重複する点もあるが下記の項目も考慮すべきである。 v モジュール分割設計は正しいか v モジュール名のつけ方は統一されているか v 共有データは隠蔽されているか v モジュール間のンターフェースは明確か v 複雑度は適切か v ネスティングは適切か v テストデータは検討されたかなどである。（6）マニュアル設計工程での審査の観点［14］ v マニュアルの内容は十分性、正確性、必要性を満たしているか v マニュアルの表現は平易で簡明であるか。かつ具体性と自然性を満たしているか v マニュアルの構成は順序、配列がわかりやすいか v 誤字・脱字はないかなどに十分注意しなければならない。 5．4 設計審査（DR : Design Review）のまとめ以上の考察の結果、設計審査の要点として下記の 4 点を重視すべきであることがわかる。 ①開発プロセス毎にレビューポイント（DR のチェックリスト）を作成し、レビューポイントに基づいて、DR を実施する事。 ②レビューポイントは広くノウハウを集め、また、DR 実施後に追加・改定をするよう心掛けること ③ DR はフイードバック（F.B）的な審査になりがちである。チェックリストを活用しての F.B 的な審査と並行して、同時に前工程の DR の最後に次工程の DR のポイントを話し合うフイードフォアード（F.F）的な活動も重要視しなければならない。 ④製品に関わる全部門の審査者の参加による DR を実施するように心掛ける必要がある（開発部門だけではなく、営業部門や保守部門も含まなければならない）。. ― 224 ―.

(23) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. 6 品質保証活動（テスト / 検査プロセスにおける品質保証活動） 6．1 テスト / 検査の位置付け［15］［16］各設計工程では品質を作りこむフィードフォアード的な品質保証活動（F.F 活動）が重要であり、最も大切な活動である。テスト工程では各工程でその品質が正しく作りこまれたかを評価し、対応する設計工程にフィードバックする活動であり、いわゆるフィードバック的な品質保証活動（F.B 活動）が中心となる。 6．2 テストと検査テストと検査の違いを考察する。テストとはテストは、エラーを発見することを目的としてプログラムを実行する過程である。しかし、全てのエラーを検出する事は一般には不可能である。経済的、かつ効果的に適用可能な手法を用いて、より危険率の少ない、高品質なソフトウエアを目指してテストを行う。設計者が自ら適切に設計されているか確認するプロセスである。検査とはテストに加え評価・判定をする品質評価活動を総称して検査と呼ぶ。したがって、設計者が行うべきものではなく、設計部門から独立した検査部門が実施すべきものである。製品をユーザに提供して良いかどうかの品質評価と合否判定にあたることが重要であり、ユーザの立場にたった客観的な見方による厳しい評価が必要である。このことから、組織面でも独立した検査部門によって実施する事が要求される。最終段階だけでなく、開発の各段階においても品質把握に努め、品質向上施策を推進する事が重要である。テスト・検査プロセス広い意味ではいわゆる V 字モデルの上流設計プロセス（要求定義からシステム設計、基本設計、ソフトウエア設計（機能設計）、プログラム設計、モジュール設計）での設計レビューもテスト・検査プロセスであるが、一般には下流工程の単体テスト、モジュール結合テスト、プログラム結合テスト（機能テスト）、システムテスト（総合テスト）、運用テスト（検査）のことをいう。 6．3 検査の種類検査には製品検査と工程検査がある。. ― 225 ―.

(24) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. （1）製品検査開発工程の最終段階での検査である。品質特性（機能性、信頼性、移植性、効率性、保守性、効率性）それぞれの観点から検査を実施すべきである。（2）工程検査各開発工程においてその中間生産物の品質評価を行い、次工程に進んで良いか判定する。技術管理部門で実施することが多いが、検査部門も積極的に参加して、最終段階の製品検査の前段階での品質の作りこみに尽力すべきである。 ①ドキュメント評価を実施する。 ②コード・インスペクション／テストの評価を実施する。量的な十分性の評価の実施検出バグ数、レビュー工数、テスト時間、テスト項目の十分性を評価する。内容面の十分性評価バグの内容と傾向、テスト環境、バグの原因と処置についての十分性を評価する。 6．4 テストの種類テストプロセスは以下の 4 つのプロセスから構成される。単体テスト各モジュールのテストを実施する。結合テスト各モジュール間、プログラム間のインターフェースのテストを実施する。総合テスト（機能テスト）外部仕様どおりに機能することをテストする。検査（運用テスト）要求仕様書との適合性と矛盾性を検査する。 6．5 単体テストについての留意点［17］モジュールテストともいう。システムを構成する最少単位であるモジュールに着目して行うテストである。モジュールのロジックやインターフェース、モジュールの外部仕様をテストする。単体テストの手順としては ①モジュール外部仕様に着目したモジュール機能テストを行う。. ― 226 ―.

(25) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. ②これにより実行されていない経路を中心に内部構造に着目したモジュール・ロジックのテストを行う。事に留意すべきである。 6．6 結合テストタスク（プロセス、プログラム）とは OS の管理下で実行される仕事の単位のことをいう。ジョブとはユーザから見た仕事の単位のことをいう。したがって、ジョブは単一または複数のタスク（プロセス、プログラム）の結合によって実行される。結合テストは下記の 2 種類がある。 ①最少単位であるモジュールを結合してタスクのテストをする。 ②タスクを結合してジョブをテストする。モジュールの結合方法モジュールの結合テスト方法には下記の 3 種類がある。（その 1）ボトムアップによる結合最初プログラム構成の底辺にあるモジュールを開発してテストし、次にそれを呼び出すモジュールを開発し、既にテスト済みのモジュールを結合してそのモジュールをテストし、だんだんと頂上にあるモジュールを開発し、結合しながらテストする方法である。（その 2）トップダウンによる結合最初プログラム構成の頂上にあるモジュールを開発してテストし、次にこのモジュールが呼び出すモジュールを開発し、既にテスト済みのモジュールと結合してテストし、だんだんと底辺にあるモジュールを開発していく方法である。（その 3）ビッグバンによる結合個々のモジュールを独立に開発してテストし、各モジュールのテストが終了した時点で、1 度に結合してテストする方法である。どの方式が最善かどの方式が最善かはプログラムの特性やスケジュールによるが v ボトムアップ方式は ° テスト項目の設計がしやすい。 ° ドライバモジュールを必要とする。 ° 全体的なエラーの検出が遅れてしまう。. ― 227 ―.

(26) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. v トップダウン方式は ° プログラムの制御機能がテストできる。 ° スタブモジュールを必要とする。 ° テスト項目の設計が難しい。 v ビッグバン方式は ° 実質的なインターフェースのエラーが最終段階にならないと見つからない。 ° ドライバ、スタブモジュール双方が必要である。などの特性があるが、一般には、プログラム構造の上位レベルに対しはトップダウン方式を用い、下位レベルに対しては、ボトムアップ方式を組み合わせるという複合方式が最善と考える。 6．7 機能テスト（プログラム結合テスト） v 機能仕様書（外部仕様書）をベースにテストを実施する v 関連するプログラムのインターフェースに着目して行う必要がある。 v オンライン・シミュレータ、障害シミュレータなどを使用して効率的に実施する事が必要である。 6．8 システムテストシステムテストは、基本仕様書（製品目標を規定）をベースに、以下の観点からのテストを行う。 ①負荷テスト ②大容量テスト ③構成テスト ④適合性テスト ⑤機密保護テスト ⑥記憶域テスト ⑦性能テスト（効率性） ⑧信頼性テスト（信頼性） ⑨回復テスト ⑩保全性テスト（保全性） ⑪説明書テスト. ― 228 ―.

(27) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. ⑫使いやすさのテスト（使用性）以下詳細に考察する。 v 負荷テスト（stress test） ° 短期間に、極端に重い負荷をシステムにかけるテスト。例えば、TSS においては全てのユーザが同時にログオンするなどのテストをおこなう。 v 大容量テスト（volume test） ° 長い期間にわたって大容量のデータにシステムをさらすテスト。コンパイラに、非常に長いソースプログラムをコンパイルさせる等のテストをする。 v 構成テスト（configuration test） ° システムがサポートするハードウェア／ソフトウエア構成に関するテストである。 v 適合性テスト（degrade/compatibility test） ° 既存機能がそのまま動くかどうかのテストであり、ディグレイドテスト、互換性テストともいう。 v 機密保護テスト（security test） ° システムの保護機能テストのことをいう。他のユーザやプログラムが、容易に参照できないようになっているかどうかをテストする。 v 記憶域テスト（storage test） ° 主記憶、補助記憶量に関するシステム目標が達成されているかどうかのテストである。 v 性能テスト（performance test） ° 応答時間、スループット等のシステムの性能が達成されているかどうかのテストである。 v 信頼性テスト（reliability test） ° システムの信頼性目標（MTBF、残存バグ）が達成されているかどうかのテストである。 v 回復性テスト（recovery test） ° データベースにおける失われたデータの回復など、システムの回復に関するテストである。 v 保全性テスト（maintainability test）. ― 229 ―.

(28) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. ° 保全に関するツールやマニュアルに関するテストである。 v 説明書テスト（manual test） ° ユーザ向け説明書の正確さについてのテストである。特に記載漏れ、内容の誤り、あいまいさ、用語の不統一、表現不備などを中心とした正当性の確認をテストする。 v 使いやすさのテスト（usability test） ° システムの使いやすさに関するテストである。 6．9 テスト工程の手順各テストは次の 6 つの工程を経て順次進めるとよい。 ①テスト計画 ②テスト項目設計 ③テストプログラム設計 ④テストプログラム・コーディング ⑤テスト実施 ⑥テスト報告以下、詳細に考察する。 6．10 テスト計画書テスト計画書は基本設計、機能設計、プログラム設計、モジュール設計の各設計においてテストの方法、工程、工数、設備備などについて検討し、テスト計画書を作成すのがよい。テスト計画書には下記の内容を記述すべきである。 ①テスト対象 ②テスト環境 ③テスト方法 ④テスト支援ツールの利用 ⑤予定テスト項目数 ⑥バグ検出目標値 ⑦予定テスト工数 ⑧テストスケジュールと担当者割り当て 6．11 テスト報告書テスト報告書には、テスト項目数、検出バグ数、バグの種類、内容分析、品質分析、工. ― 230 ―.

(29) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. 数、残問題、今後の課題等についてまとめ、報告することが重要である。 6．12 テスト技法の 2 つの観点［16］下記のように、テスト技法にはブラックボックス・テスト技法とホワイトボックス・テストがある。 v プログラムの外部仕様（機能）に着目するブラックボックス・テスト（black box test） ° 外部仕様に着目し、入力される可能性のある入力値の組み合わせを与えてテストする（機能テスト） v プログラムの内部構造に着目するホワイトボックス・テスト（white box test） ° プログラムの内部構造を調べ、全ての処理の流れを網羅するようにテストを行う（構造テスト）ブラックボックス・テスト技法には ①同値分割 ②限界値分析 ③原因・結果グラフがある。最小限、①と②の技法は習得し、活用しなければならない。ホワイトボックス・テストには ①命令網羅 ②判定条件網羅 ③条件網羅 ④判定条件／条件網羅 ⑤複合条件網羅がある。命令網羅テストをすれば十分と思いがちだが、実際は①だけでは全く不十分でテスト不十分な判定条件や条件の組み合わせなどが網羅されていないケースが多く、②から⑤の条件を含むテストケースを設計する必要があり、相当の訓練が要求される。ソフトウエア品質をマネジメントするにはテスト技法の教育を欠かしてはならない。 6．13 テストの効率化ソフトウエアのテストには多くの費用がかかる。著者の経験によると多くのシステム開発では開発費の約 50％がテストに費やされている。テストの機械化・自動化をはかる必要がある。たとえば、. ― 231 ―.

(30) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. ①プログラムの静的解析ツール ②プログラムの動的解析ツール ③テスト実施支援ツール（テストの自動化など）の自動化ツールなどを可能な限り活用すべきである。（例 1）プログラムの静的解析ツール（その 1）対象とするプログラムを実行せずに解析するツールである。 v フローダイアグラムを描く v 全ての経路を数え上げたりして、テスト項目の設計を支援する v 未定義の値を持つ変数のリストアップ v モジュール間のインターフェースの不一致 v 実行される事のないコード等の問題点を発見する機能をもつ。（例 2）プログラムの静的解析ツール（その 2）コード分析ツールソースコードの構文解析やデータタイプのチェックを行うプログラム構造分析プログラムのパスを階層的に解析し、ホワイトボックス・テストの項目設計を支援するモジュール・インタフェース・チェック・ツールデータ構造の宣言中における不一致やモジュール間の不適切な連携をチェックする。イベントシーケンス・チェック・ツールファイル読みこみの前に、ファイル・オープンされているかなどのチェックを行う。（例 3）プログラムの静的解析ツール（その 3） PRL 社の QA-C［18］ QA-C は、ソースコード全体を解析して、問題となる箇所に対して警告を出力することができるので、より安全なソースコードに改変すべき箇所、あるいは言語規格やコーディング標準から逸脱している箇所を検査することができる。開発の早い段階でソースコードを静的に解析することにより、単体テストなどの動的テ. ― 232 ―.

(31) 吉崎浩二：ソフトウエア開発マネジメントに関する考察―ソフトウエア開発の品質マネジメント編―. ストの実施前に潜在的なバグを発見できるため、開発コストと時間を大幅に削減できる。ソースコードの安全性、信頼性、移植性、保守性を上げることができるため、ソースコードの品質向上と将来の保守コストの削減ができる。 45 種類以上のソフトウエア・メトリックスを用いてソースコードを計算し、ソースコードの品質を客観的かつ定量的に評価できる。品質を定量的に表すことによって、対象ソースコードを自社あるいは産業界の基準と比較でき、品質改善の指標とすることができる。（例 4）プログラムの動的解析ツール ①トレーサ／ダンプ機能 ②テスト網羅チェック ③メモリーアクセス・エラー検出機能などを持つ Boundchecker による動的解析の例［19］ v メモリーエラー（下記のようなメモリーエラーを検出する） ° ダイナミックメモリオーバラン ° ロックされているハンドルを開放しょうとしている ° ロックされていないハンドルをアンロックしょうとしている ° メモリー読みこみオーバフロー ° 未初期値化メモリーからの読みこみ ° スタックメモリーオーバラン ° メモリー書きこみオーバフロー v ポインターエラー（下記のポインターエラーを検出する） ° 範囲を超えた配列の読みこみ ° 有効範囲外を示すポインタのコピー ° ダングリングポインタの演算 v メモリリーク（下記のメモリリークを検出する） ° メモリブロックが割り当てられたまま、開放されていない。ハードウェア設計では CAD や CAE ツールがよく活用されているのに比して、ソフトウエア開発では CASE ツールを活用していないケースが多い。CASE ツールをいかに活用していくかはソフトウエア品質マネジメントにおいて不可欠な要素である。. ― 233 ―.

(32) 上武大学ビジネス情報学部紀要第 11 巻第 2 号（2012 年 12 月）. 7 まとめ以上、ソフトウエア品質のマネジメントについて考察してきたが、忘れてはならないことは、まず、管理者だけでなく、SE もプログラマーも双方向にソフトウエア開発の状況を「見せる努力」と「見る努力」の工夫を継続的に続けてゆくことである。次に、「ソフトウエア品質とは何か」をよく理解したうえでマネジメントを考察することが大切である。さらに、組織においてもプロジェクトにおいてもソフトウエア品質を保証するための体系（仕組み、体制）を正しく整備することが重要である。一時凌ぎのマネジメントであってはならない。そのうえで、ソフトウエアの品質を保証する活動は教育活動から、上流プロセスの設計審査、CASE ツールの活用、下流プロセスでの検査活動から、クレーム分析と再発防止活動まで、広く地道に取り組むことが必要である。. 参考文献［ 1 ］菅野文友：ソフトウエアの品質管理（日科技連ソフトウエア品質管理シリーズ）、日科技連出版社（1986/6）［ 2 ］星野香保子並木秀明菊池宜志日比野吉弘：組込みソフトウエア開発入門∼組込みシステムの基本を―ハードウェアとソフトウエアの両面から学ぶ！、技術評論社（2008/8/29）［ 3 ］安藤秀樹／門田俊輔：図解でわかるソフトウエア開発のすべて、Mint 著（2000 年 7 月 30 日初版、現在は 17 刷）［ 4 ］増田雅史、生貝直人：デジタルコンテンツ法制、朝日新聞出版（2012/3/7）［ 5 ］深野一幸：2000 年問題日本壊滅、成星出版（1999/03）［ 6 ］Wulf : “Report of a Workshop on Programming Methodology,” Proceedings of a Symposium on the High Cost of Software, Naval Postgraduate School, Monterey, California, September 1973 ［ 7 ］ISO/IEC 9126-1 Software engineering - Product quality - Part1 : Quality model ［ 8 ］JIS X 0129-1 ソフトウエア製品の品質―第 1 部：品質モデル［ 9 ］保田勝通、奈良隆正：ソフトウエア品質保証入門―高品質を実現する考え方とマネジメントの要点、日科技連出版社（2008/05）［10］奈良隆正：ソフトウエア品質保証の方法論、NARA コンサルティング、2009 年 10 月 5 日［11］ja.wikipedia.org/wiki/v モデル［12］中山秀夫：設計レビューが形骸化していませんか、日経 SYSTEMS（2010/02/25）［13］森口繁一（編集）：ソフトウエア品質ガイドブック、日本規格協会（1990/07）. ― 234 ―.