「信頼性向上のための情報システム開発上流工程における品 …i....

「信頼性向上のための

情報システム開発上流工程における

品質評価手法に関する調査」

調査報告書

２０１０年３月

2009年度産学連携ソフトウェア工学実践拠点

ソフトウェア・エンジニアリング・センター

目次

1.

はじめに1.

目的

４2.

スコープ

５3.

作業の流れ

６

2.

概形調査1.

収集

９2.

収集した情報の一覧化

１０3.

収集した情報の分類

１１4.

収集内容の妥当性確認（有識者レビュー）

１２5.

概形調査の結果

１４

3.

詳細調査1.

詳細調査対象の選定

５４2.

詳細調査の方法

５７3.

詳細調査の結果

５９4.

HyDEEPの調査結果

７３

4.

分析・体系化1.

個別分析

７７2.

比較分析

８６3.

体系化

８８

5.

考察・提案1.

利用する立場から見た品質評価手法

９８2.

今後の方向性

９９

6.

参考文献

１０１

１．はじめに

１．１

目的

i.

情報システムの信頼性確保のために、これまでも、信頼性ガイドライン、

信頼性評価指標など信頼性向上を柱とする施策が実施されている。

一方、障害を未然に防ぐための客観的な情報システム評価手法は確立

されておらず、実現が切望されている。

ii.

本調査では、特に重要な上流工程に関して、国内外で取り組まれてい

る情報システム開発の成果物の信頼性を評価するための手法を、研究

レベルから実用レベルまで精査し、現況を把握することと、新たに実現

可能な手法を提案することを目的とする。

１．２

スコープ

i.

上流工程の位置付け

本調査の対象とする上流工程は、図1-1に示す、「情報システム・モデル取引・契約

書」（経済産業省/2007年）に示された”システム化の方向性”、“システム化計画”、

“要件定義”と“システム設計”とする。

「経営者が参画する要求品質の確保」（情報処理推進機構編/2006年）において、

“システム化の方向性”、“システム化計画”、“要件定義”は超上流とし、システム

開発の信頼性確保に重要な工程であることを述べている。また、“システム設計”

は“要件定義”の後工程として、システム化すべき機能について、より具体的な情

報をインプットとして引き渡される工程であり、開発工程に進むことができるかを判

断する位置づけとしている。

ii.

本調査での主要な工程

本調査では、“要件定義”を中心とし、その品質確保や品質評価に関連して前後

の工程についても、調査を行う。

要件定義工程の詳細な開発タスクは、図1-2のとおり、「抽出」「分析」「仕様化」

「妥当性確認」の４タスクとする。

iii.

HyDEEPの取り扱いなお、「HyDEEP」は、実績データの有無にかかわらず適用可能な品質予測手法と

して注目を浴びているため、上流工程における適用可能性を調査するため、調査

対象に含める。

※

「システムライフサイクルフェーズ」は、経済産業省『情報システム・モデル取引・契約書（第一版）』2007年を引用

今回のスコープ

抽出分析仕様化妥当性確認

図1-1

システムライフサイクルフェーズ

システム

化の

方向性

システム化

計画要件

定義

システム設計（システム

外部設計）

システム

方式設計（システム

内部設計）

ソフトウェア設計プログラミング

ソフトウェアテスト

システム

統合システム

テスト

導入・

受入

支援

運用

テスト運用保守

図1-2

要件定義の詳細な開発タスク

１．３

作業の流れ

i.

図1-3に示す4つのステップで調査を実施した。a.

概形調査

公知の文献およびインターネット掲載情報を収集し、有識者意見を活用

して整理、検討する。

b.

詳細調査

事例ごとに文献の深堀およびヒアリング調査を行う。

c.

分析・体系化

概形調査、詳細調査によって得られた収集事例を分析した上で、体系

化する。

d.

考察・提案

分析結果をベースにして、上流工程における実現可能な品質評価手法

の考察および提案を行う。

候補

リスト

インターネット情報

文献

有識者意見

概形調査の調査結果

a.概形調査

c.分析・

体系化d.考察

・提案

報告書詳細調査の調査結果

分析並びに体系化成果

選定

図1-3

作業の流れ

b.詳細

調査

２．概形調査

２．

概形調査の目的と概要

i.

概形調査の目的

概形調査の目的は、国内外で取り組まれている情報システム開発の

成果物の信頼性を評価するための手法（以下、「評価手法」と記す）を、

広く国内外の研究レベルから実用レベルまで精査し、調査対象を

確定することである。

ii.

概形調査の概要

概形調査は、図2-1に示す内容である。

２．１

収集

２．２

収集した情報の

一覧化

２．３

収集した情報の

分類

２．４

収集内容の

妥当性確認（有識者レビュー）

公知の文献及びインターネット掲載情報から開発上流工程の品

質評価手法に関する研究報告、適用事例、紹介記事などを収集

する。

収集した情報を一覧化し、評価対象、実績の有無などを

比較検討できるように整理する。

整理した情報を、評価対象、評価方法、評価時期などにより

類型化する。

詳細調査対象の選定のために、収集内容の妥当性に関して有

識者の助言を得る。

２．５


概形調査の結果を整理し、詳細調査以降に有益な分類を加える。

図2-1

概形調査の概要

２．１

収集

i.

概形調査における文献収集は、以下のa.～c.の取組み・研究テーマを含

むように実施した。

a.

国家の研究開発戦略および信頼性確保の取組み

b.

先端的な研究機関・大学における研究テーマ

c.

民間企業における先端的な取組み

ii.

収集のための情報ソースは図2-2のとおりである。

政府

研究機関

学会／研究会／業界団体

民間

企業

海外

国内

海外

国内

•経済産業省

•(独)情報処理推進機構•(独）宇宙航空研究開発機構•国立情報学研究所•大学

•

カーネギーメロン大学ソフトウェア工

学研究所（SEI:Software

Engineering Institute）•

米航空宇宙局（NASA:the

National

Aero-nautics and Space Administration）

•

独フラウンホーファ協会実験ソフト

ウェア工学研究所（Fraunhofer Institute for Experimental Software Engineering）

•情報処理学会•電子情報通信学会•日本ソフトウェア科学会•電気学会•プロジェクトマネジメント学会•（社）情報サービス産業協会•（社）日本情報システム・ユーザ協会•（財）日本科学技術連盟•（財）日本規格協会

（INSTAC）

•

ACM（Association for Computing Machinery:ACM）

•

IEEE（The Institute of Electrical and Electronics Engineers, Inc.）

民間企業各社

•

クリティカルソフトウェアワークッショップ

(WOCS：Workshop of Critical Software)

•

ＣＯＭＰＳＡＣ:International Computer Software and Applications Conference

•

要求工学国際会議（ICRE: International Conference on Requirements Engineering）

•

ＲＥ：IEEE International Requirements

Engineering Conference•

ソフトウェア工学国際会議（ICSE：the International Conference on Software Engineering）

•

定量データ分析の国際会議（Mensura：

the International Conference on Software Process and Product Measurement)

•

Conference on Software Engineering Techniques (2007)

•

実践的ソフトウェア工学の国際会議

（ESEM：Empirical Software Engineering and Measurement ）

•NEC•NTTデータ•東芝•日本IBM•日本ユニシス•日立•富士通

図2-2

収集の情報ソース

２．２

収集した情報の一覧化

i.

概形調査結果を「文献一覧」に一覧化し、評価対象、実績の有無などを

比較検討できるように整理した。

文献一覧の項目は、以下のとおりである。

a.

管理番号：文献を一意に識別する通し番号

b.

誌名：文献が掲載された学会誌等の名称

c.

発表媒体：文献が掲載された巻号等

d.

題名：文献の題名

e.

発表者：文献の発表者名

f.

所属：発表者の所属する大学、研究機関、企業等の名称

g.

概要：文献から引用または要約した、文献のおおよその内容

２．３

収集した情報の分類

i.

収集した文献に含まれる情報は、以下の評価軸で整理し、概形調査

シート（単票）に記載したa.

発表時期：現在から約５年ごとに分割したどの年代に発表されたか•

1990年以前•

1991-1995年•

1996-2000年•

2001-2005年•

2006年以降b.

評価手法分類：レビュー、分析、プロトタイピング、シミュレーション、デモンスト

レーションのいずれか•

レビュー

•

分析

•

プロトタイピング

•

シミュレーション

•

デモンストレーション

•

その他

評価手法の分類は、「開発のためのCMMI 1.2版」（CMMI-DEV, V1.2

CMU/SEI-2006-

TR-008

ESC-TR-2006-008）の「検証(verification)」において、検証の手法として挙げら

れているものの中から、開発上流工程での使用に適するものを選択・統合したものである。

c.

実用レベル：実用段階にあるか、研究段階か•

実用段階

•

研究段階

d.

評価対象物：成果物を対象とするか、プロセスを対象とするか•

成果物

•

プロセス

•

成果物、プロセスの両方を対象とする

e.

利用時期：開発上流工程のどのタスクで利用する評価手法か•

「システム化方針／計画」

•

「要件定義」（抽出、分析、仕様化、妥当性確認）

•

「システム設計」

f.

システム分類：文献上、当該評価手法が対象としているシステムはどのよう

なものか•

重要インフラシステム

•

企業基幹システム

•

その他

g.

開発手法：評価手法が対象としているシステムの開発手法はどのようなもの

か•

ウォーターフォール

•

イテレーション

•

その他

２．４

収集内容の妥当性確認（有識者レビュー）

i.

有識者レビューの内容

概形調査では、収集方法や文献一覧に対して、有識者のレビューを受け、以下のaからcの

観点において、それぞれの専門分野に照らして助言を得た。

a.

要求工学や上流工程品質評価手法に関して、取り上げるべき企業・人物や研究テーマに

漏れは無いか

b.

上流品質評価や要求工学のトレンドについての意見

c.

その他、本調査に有益な意見

ii.

有識者レビューでの助言にしたがって、文献の追加や、詳細調査候補の精査を

行った。

iii.

有識者と、選定理由（敬称略）早稲田大学理工学部教授東基衞•

チーフエディタとしてISO9126（JIS X 0129)/14598（JIS X 0133）の規格化に参画

し、現在もISO/IEC JTC1/SC7/WG6 Convenor に従事している。南山大学数理情報学部教授青山幹雄•

要求工学分野における第一人者である。

東京大学大学院総合文化研究科教授玉井哲雄•


筑波大学大学院ビジネス科学研究科准教授中谷多哉子•


東洋大学経営学部准教授野中誠•

ソフトウェア開発コスト予測，品質マネジメントなどを専門としている。

情報処理学会ソフトウェア工学研究会幹事、日本科学技術連盟 SQiPソフトウェ

ア品質委員会副委員長などの活動においても活動している。

奈良先端科学技術大学院大学情報科学研究科助教森崎修司

•

ソフトウェアレビュー・インスペクション、ソフトウェア計測（メトリクス）に造詣が深い。

ＮＥＣコンピュータソフトウェア事業本部統括マネージャ誉田直美•

NEC汎用ソフトウェア開発部門の品質保証とプロセス改善に従事している。

また、日本科学技術連盟など社外でも活躍している。

なお、中谷多哉子先生、森崎修司先生には詳細調査対象としての調査にもご協力いただいた。

iv.

収集方法や文献一覧に対して有識者から得た代表的な意見を

表2-1に示す。

対象者文献一覧

自体への評価上流品質評価や

要求工学のトレンドその他の主な意見

早稲田大

東基衛教

授

海外文献を広く

見るべきである品質特性を実務での重要性に鑑みて適用するに

は、品質要求定義を行う人材の育成が大事

南山大

青山幹雄

教授

海外文献を広く

見るべきである要求獲得の研究が多い。検証は技術的な難しさも

あってか昔から少ない。獲得がうまくいかないと検証だけでは効果が少ない

Ｉ*を用いた仕様検討シミュレーションはドメインを特化したツールなら多

く存在

プロトタイピングは86-87年頃盛んだったが内容は素朴なもの

要求と実装のトレー

サビリティは最近の

話題の一つ。

東京大

玉井哲雄

教授

調査スコープに

対する網羅は

難しい（百数十

件程度ではない

はず）

評価手法単独ではなく要件抽出や仕様化、管理の方法論、ツールによるサポートが必須

非機能要件に注目

筑波大

中谷多哉

子准教授

大きく漏らして

いるものは無い顧客と開発者は対等ではないため、開発者が要

求を引き出せる仕掛けが必要。

東洋大

野中誠

准教授


いるものは無いビジネスケースからシステムの方向付けへのアプ

ローチ（海外では多い）

(社)日本情報システム・ユーザ協会（ＪＵＡＳ）では実運用の観点で収集されたデータの要件化を研究中

要件１件ごとの意味

と重要性を考慮して

影響範囲を検討す

べき

奈良先端

大

森崎修司

助教


いるものはない自然言語処理では、めざましいものは無い。（ＵＭ

Ｌで記述するのが限界）

米はコードレビューに投資して品質確保、欧州特に北欧は日本に近い上流重視

モデルチェッキングも有効である。形式仕様記述や形式検証も該当

NEC

誉田直美大きく漏らして

いるものはないＣＭＭＩレベル５の組織でも品質向上施策は定量

管理とピアレビューである上流品質評価はレ

ビューが中心となる

表2-1

有識者レビューの代表的な意見

i.

収集した文献は125件であった。

開発タスクによる収集文献の分布は表2-2に示すとおりである。

実用レベルでは「（要件定義の）妥当性確認」、「システム設計」に分類さ

れる文献が多く、研究レベルでは「（要件定義の）抽出」および「分析」が

多いことがわかる。（具体的な文献名については後述の表2-4を参照の

こと）

開発上流工程の開発タスク

システム化

方針／計画

要件定義システム

設計

上流工程

全般

（特定せず）抽出分析仕様化妥当性

確認

実

用

◆030,◆037,◆042,◆066,◆073,◆091

◆037(システム

化方針/計画～

抽出)

◆072,◆120, ◆124

◆014,◆021,

◆022,◆023,◆038,◆124

◆011,◆014, ◆021,◆022,

◆023,◆026, ◆027,◆029, ◆067,◆097,

◆114,◆123,

◆120,◆124

◆005,◆011, ◆014,◆021,

◆022,◆023, ◆024,◆027,

◆028,◆032,

◆066,◆067,

◆075,◆120

◆003,◆016,◆017,◆018,◆019,◆020, ◆025,◆034,◆035,◆125◆038,◆039,◆049,◆097

◆101

◆005,◆042,◆075,◆091,◆094

研

究

◆008,◆092, ◆107

◆001,◆002,

◆004,◆054,

◆064,◆065,

◆078,◆082,

◆112

◆009,◆040, ◆100,◆103,

◆116,◆117,◆118,◆119,

◆121

◆036,◆041,

◆056,◆057,◆076,◆079,◆081,◆095, ◆102,◆110,◆122

◆087,◆088,

◆089,◆090,◆093,◆100,◆102,◆106,◆119,◆122

◆093,◆112 ◆031,◆062,

◆070,◆104,

◆115

◆006,◆007,◆008,◆010,◆012,◆013,◆015,◆033,◆036,◆041,◆043,◆044,◆045,◆046,◆047,◆048,◆050,◆051,◆052,◆053,◆055,◆056,◆057,◆058,◆059,◆060,◆061,◆063,◆069,◆074,◆076,◆077,◆081,◆086,◆092,◆095,◆096,◆098,◆099,◆105 ,◆106,◆108,◆111

◆068,◆080

◆071,◆083,◆084,◆085,◆109,◆113

２．５


◆：XXX管理番号表2-2

開発タスクによる収集文献の分類

ii.

収集した文献の一覧を、開発タスク別に次ページからの表2-4に示す。

表2-3において、①～⑪は、表2-4の並び順を示している。

表2-3

文献一覧における開発タスクの並び順

開発上流工程の開発タスク

システム化

方針／計画

要件定義システム

設計

上流工程

全般

（特定せず）抽出分析仕様化妥当性

確認

実

用

◆030,◆037,◆042,◆066,◆073,◆091

◆037(システム

化方針/計画～

抽出)

◆072,◆120, ◆124

◆014,◆021,

◆022,◆023,◆038,◆124

◆011,◆014, ◆021,◆022,

◆023,◆026, ◆027,◆029, ◆067,◆097,

◆114,◆123,

◆120,◆124

◆005,◆011, ◆014,◆021,

◆022,◆023, ◆024,◆027,

◆028,◆032,

◆066,◆067,

◆075,◆120

◆003,◆016,◆017,◆018,◆019,◆020, ◆025,◆034,◆035,◆125◆038,◆039,◆049,◆097

◆101

◆005,◆042,◆075,◆091,◆094

研

究

◆008,◆092, ◆107

◆001,◆002,

◆004,◆054,

◆064,◆065,

◆078,◆082,

◆112

◆009,◆040, ◆100,◆103,

◆116,◆117,◆118,◆119,

◆121

◆036,◆041,

◆056,◆057,◆076,◆079,◆081,◆095, ◆102,◆110,◆122

◆087,◆088,

◆089,◆090,◆093,◆100,◆102,◆106,◆119,◆122

◆093,◆112 ◆031,◆062,

◆070,◆104,

◆115

◆006,◆007,◆008,◆010,◆012,◆013,◆015,◆033,◆036,◆041,◆043,◆044,◆045,◆046,◆047,◆048,◆050,◆051,◆052,◆053,◆055,◆056,◆057,◆058,◆059,◆060,◆061,◆063,◆069,◆074,◆076,◆077,◆081,◆086,◆092,◆095,◆096,◆098,◆099,◆105 ,◆106,◆108,◆111

◆068,◆080

◆071,◆083,◆084,◆085,◆109,◆113

１

３２

１１

９

８７

２３

４

５６

１６

１０

７

１１５４

９

表2-4

文献一覧

表2-4-①

システム化方針／計画

敬称略

表2-4-①

システム化方針／計画

表2-4-②

要件定義（抽出）

表2-4-③

要件定義（分析）

表2-4-④

要件定義（仕様化）

表2-4-⑤

要件定義（妥当性確認）

表2-4-⑥ システム設計

表2-4-⑦

要件定義（抽出～分析）

表2-4-⑧

要件定義（抽出～仕様化）

表2-4-⑨

要件定義（抽出～妥当性確認）

表2-4-⑩

要件定義（仕様化～妥当性確認）

表2-4-⑪

上流工程全般（システム化方針／計画～システム設計）

iii.

概形調査結果の評価手法の分布は以下のとおりである。

分布状況についての分析は、「４．３

体系化」を参照されたい。

評価手法の分類

レビュー分析シミュレーションプロトタイピング

実用

●025,●029,●034,●067,●094,●097,●114,●123■011,■024,■027,■030▲021,▲022,▲023,

▲028,▲032,▲042,▲073,▲075,▲091

●025,●034,●039,

●097,●114,●120■005,▲075

●097,▲075

●014,●109,▲075

研究

●031,●068,●122,■041,■070,▲071,▲110

●007,●015,●040,

●045,●050,●056,

●077,●080,●087,

●088,●089,●090,●092,●093,●100,

●105,●111,●113,

●116,●117,●119■001,■002,■004,

■006,■033▲010,▲071,▲110

●076,●111 ●013,●106,●109,

●113,●119

●成果物評価手法■プロセス評価手法▲プロセス＆成果物評価手法

表2-5

評価手法の分布

iv.

評価手法のメトリクス

明確にメトリクスを用いていると識別した9件のうち、成果物の定量評価手法に該

当するものは4件であった。

また、9件のうち、4件がIEEE

Std 830-1998 （IEEE Recommended Practice for Software Requirements Specifications –Description）を尺度に用いた評価を

行っている。

（下表の文献番号欄の★印）

管

理

番

号

開発工

程定量管理の目的

基本測定量プロセ

ス/

成果物

実用

レベル事例

導出測定量

045

★要件定

義要求仕様書の

IEEEstd830品質

特性の数値化（見

積もり）

優先度、貢献度（

AGORAゴー

ルグラフモデルの節や枝に評価

者が与えるー１０から１０の値）

成果物研究要求仕様書の品質特

性の見積もり（信州大）

（省略）

114

★要件定


IEEEstd830品質

特性の充足度把

握

チェック項目に対する評価（○、

×）成果物実用要件定義書第三者品

質スコアリング（NTT

データ）各項目の重み付け加重

124

★要件定


IEEEstd830品質

特性による文章精

度の把握

要求件数、曖昧要求件数成果物実用要求仕様書静的解析

（NEC通信システム）曖昧要求比率＝曖昧要求件数

/要求件数

004 要件定

義プロジェクトマネジ

メント課題とQCD

達成度の相関分

析

レビュー遅延日数、検出課題数、

対策日数、障害件数、出荷遅

延日数、コスト

プロセ

ス研究組込みSWの機能変更

PJにおける初期リスク

とQCD達成度の関係

に対する定量化分析

（日進システムズ、鳥取

大学）

重課題換算値、コスト超過率

005 要件定

義品質バイタルサイ

ンによる健全性測

定

成果物の最終更新日付、成果

物の最終更新時刻プロセ

ス実用 PJの健全性と品質傾

向（日本IBM）(省略)

表2-6

定量データをメトリクスに使用している事例(1/2)

管

理

番

号

開発工

程定量管理の目的

基本測定量プロセ

ス/

成果物

実用

レベル事例

導出測定量

021 要件定

義、シ

ステム

設計

インスペクションの

効果と効率の把握除去欠陥数、除去漏れ欠陥数、

成果物規模、インスペクション

所要時間、指摘欠陥数、全工

数

プロセ

ス研究インスペクションの定

量管理（東洋大学）

欠陥除去率=除去欠陥数÷（除

去欠陥数＋除去漏れ欠陥数）

欠陥除去規模密度=除去欠陥

数÷成果物規模

インスペクション速度=成果物規

模÷インスペクション所要時間

欠陥指摘工数密度=指摘欠陥

数÷全工数

027 要件定

義、シ

ステム

設計

成果物品質評価モジュール結合度、凝集度、

McCabeの循環的複雑度成果物実用品質保証レビュー（日

本ユニシス）

(省略)

024 システ

ム設計設計書レビューの

品質評価設計書ページ数、レビュー指摘

件数、レビュー時間プロセ

ス実用設計工程における品

質管理/評価につい

て（日立製作所）レビュー指摘率＝指摘件数/ペー

ジ数

レビュー速度＝ページ数/レビュー

時間

104

★上流全

般要求仕様書の

IEEEstd830品質

特性の充足度とコ

スト超過の関係分

析

チェック項目に対する評価（○、

×）,コストプロセ

ス研究要求品質とpjの成功

失敗の関連（IBM東

京研究所、東京大

学）重課題換算値、コスト超過率

表2-6

定量データをメトリクスに使用している事例(2/2)

３．詳細調査

３．

詳細調査の目的と概要

i.

詳細調査の目的

詳細調査の目的は、概形調査で把握した公知の文献の中から、現在取

り組まれている評価手法の中で代表的なもの、特徴的なもの、効果がめ

ざましいものを整理し、実施方法論、実施事例、効果・課題などについ

て情報を共有することである。

ii.

HyDEEP

なお、HyDEEPについての調査も詳細調査の一環とみなし、本章で結

果を報告する。

iii.

詳細調査の概要

詳細調査は、図3-1に示す内容である。

３．１

詳細調査対象の

選定

調査対象とする手法に関して、公知の文献、ならびにインターネット掲載情報から、関連情報を広く収集する。調査先および調査媒体の種類は、概形調査と同様とする。文献調査のみとするか、ヒアリングを実施するかを決定する。文献の深堀によって十分な情報が得られた場合、あるいは、調査先組織の事情によってヒアリングが実施できないと判断した場合は、IPAと相談の上、ヒアリング実施要否を決定する。文献の深堀で確認し得ない点に関し、ヒアリングを行う。以下の点は文献から知りえないため、ヒアリングでの情報収集に努める。

1.

文献・インターネットで公知になっていない情報2.

研究や手法実施に関する所感、現状、課題、今後の方

針など

選定基準に従い、詳細調査対象の候補を選定する。有識者の意見を加味し、候補を決定する。

３．２


詳細調査の結果を記録する。

３．３


HyDEEPの調査結果を記録する。同手法の上流工程での適用可能性について整理する。３．４

HyDEEPの

調査結果

図3-1

詳細調査の概要

３．１


i.

図3-2に示す選定基準に従って調査対象を選定した。a.

評価手法を扱った文献であることを最優先する。

b.

１つのフェーズについて研究・実践した評価手法ほど、深く追求されて

いると考え、対象とするフェーズが単独であることを２番目に優先する。

c.

これにHyDEEPを加えて調査対象を確定した。なお、調査対象の確定にあたり、有識者の意見を参考にしている。

次ページの表3-1に詳細調査対象の選定結果を示す。

概形

調査結果

詳細調査

有識者意見

選定

基準

詳細調査対象

優先

順位条件基準選定

評価手法を

扱う対象とする

フェーズが単独

１要件定義工程のみに対する品質評価手法

を扱っている○ ○ ○

２システム設計工程のみに対する品質評価

手法を扱っている○ ○ ○

３要件定義を含む、上流の複数の工程に対

する品質評価手法を扱っている○ ○

４要件定義の抽出、分析、仕様化の１つのタ

スクに対する品質向上を扱っている○

５要件定義の抽出、分析、仕様化を含む複

数のタスクの品質向上を扱っている

図3-2


No テーマ発表者／

ヒアリング

先

実

用ヒ

ア

リ

ン

グ

手法

分類概要概形調査収集資料

題名管理

番号

1 発注者視点品

質評価東京証券

取引所

清田辰巳

実

用○ R 重要インフラである次世代取引システ

ムの開発における発注者視点評価。

要件定義段階での品質評価、定量管

理によるバグ摘出強化を実施

「上流工程における発注

者視点の品質向上への

取り組み（「情報処理」

2009年5月）

022

2 要件定義書第

三者品質スコ

アリング

NTTデー

タ

木谷

強

実

用○ R,A IEEE

Std.830に基づく4つの品質特

性を定義し、要件定義書を専任チー

ムが評価してスコアリングし、品質改

善アドバイスとして開発者にフィード

バックする。

「記述漏れと曖昧な表記

の防止を目的とした要

件定義書の第三者品質

スコアリングに向けた試

み（「第28回ソフトウェ

ア品質シンポジウム

2009）

114

3 ＱＩ(Quality

Inspection)日本IBM

細川宣啓実

用○ R,A 成果物の更新時期・頻度、成果物内

部の用語用法使用頻度など様々な角

度から成果物の品質リスクを推定す

るデータを収集し、専任チームの見識

によって品質評価を行う。

「第三者インスペクショ

ンによる品質検査と欠

陥予防」（「情報処理」

50(5) pp.405-411 200905152009年5月）

023

4 ＩＶ＆Ｖ有人宇宙

システム

星野伸行

実

用○ R,A,S 独立した機関により、開発者が実施

しない評価（モデル検査、ハザード解

析等)を実施し開発者にフィードバック

する。

クリティカルソフトウェア

に対するIV&V : Independent Verification and Validation

他

025/

034

5 汎用ソフトウェ

ア開発におけ

る品質会計

ＮＥＣ

誉田直美実

用○ （評価

手法で

はない）

品質会計（作り込んだバグを負債とみ

なしレビュー・テストによって返済する

開発管理手法）を中心とした品質管

理の取り組み

「ソフトウェア開発におけ

るデザインレビュー」

（「クォリティマネジメント」

60(8) (777) pp.34～

41 2009/8）他

032

6 要求仕様書静

的解析

NEC通信

システム

日吉

昭

彦

実

用○ A 要求仕様書を要件管理ツールのアド

オンで解析しIEEE

Std.830視点で専

任チームにより解析して開発者に

フィードバックする。

豆蔵＆NCOS共同セミ

ナ（組込みソフトウェア品

質向上セミナー「仕様書

改善・設計改善の処方

箋」2009年10月）発表

資料

124

7 シナリオを用い

た要求抽出・

分析

立命館大

学

大西淳

研

究○ （評価

手法で

はない）

自然言語に制約をかけたシナリオ記

述言語の開発と、正常→異常、正常

→例外へのシナリオの拡大や、ター

ゲットとする視点からのシナリオ作成

を目指すシナリオ生成・変換プロセス

などの研究

A Generation Method of Exceptional Scenarios from a Normal Scenario (IEICE Trans. INF&SYST Vol.E91-

D,No4 IEICE Trans.

INF&SYST Vol.E91-

D,No4 他

083/

084/

085/

086

敬称略R:レビュー、A:分析、S:シミュレーション、

P:プロトタイピング表3-1

詳細調査先一覧(1/2)

No テーマ発表者／

ヒアリング

先

実

用ヒ

ア

リ

ン

グ

手法

分類概要概形調査収集資料

題名管理

番号

8 要求獲得モデ

ルPRINCE筑波大学

中谷多哉

子

研

究○ （評価

手法で

はない）

要求が全て獲得される時点をゴール

と考え、獲得率のモデルにより早期・

中期・後期成熟型に要件を分類して

獲得計画を策定する要求獲得手法。

「要求獲得計画に向け

たPRINCEモデルのため

の要求計測ガイドライ

ン」（電子情報通信学会

技術研究報告IEICE Technical Report

KBSE2009-16(2009-

7))

001

9 リスクベースド

リーディング奈良先端

森崎修司研

究○ R プロジェクト計画時点で定義したリス

クに応じてチェック項目作成と指摘の

優先順位を決定し、レビューリソース

の最適配分を目指す手法

「コスト最適化時代のレ

ビュー、どう実施していま

すか？」IBM Rational Software Conference2009

123

10 発注者視点品

質向上施策清水建設

寺田尚弘実

用○ R 共通フレーム2007を用いて、社内標

準を見直し、プロセスと成果物の両面

からの改善により、発注者企業として

要件定義力強化を行った

「ユーザー企業における

要件定義力強化の取り

組み」（SECセミナー講

演資料2009年3月）他

125

11 モデル検査に

よるソフトウェ

ア上流設計の

品質向上技術

東芝

池

田信之/高

田沙都子/

藤原聡子

研

究－ S 設計開始前にバグ早期発見を目指し

て実施するモデル検査において、不具

合解析の自動化ツールのアドオンと、

実時間仕様検査方法の開発を行った

事例。

「モデル検査によるソフト

ウェア上流設計の品質

向上施策（東芝レビュー

Vol.64

NO.4(2009)

026

12 品質機能展開

を用いたプロト

タイピング手法

松下電器

阿部/筑波

大学

吉

澤

研

究－ P プロトタイプ作成に関する方針検討、

計画、実施の局面で品質機能展開の

マトリクスを用いて適切な方針、計画

が策定できプロトタイプの効果を高め

る取組み。

「品質機能展開を用い

たプロトタイピング手法」

（日本品質管理学会「品

質」Journal of the Japanese Society for Quality Control 28(2) pp.73-85 19980415

119

13 要求の構造に

基づく要求品

質の管理

NTTデー

タ

服部昇、

山本修一

郎

研

究－ A 要求記述を構成要素に分解し、要求

不備の原因との関連を特定付け、要

求品質の向上をはかる手法。

「要求の構造に基づく要

求品質の管理」（電子情

報通信学会技術研究報

告107(505), 91-

96 ,20080225

071

14 品質予測手法

HyDEEP有人宇宙

システム

中尾春香

研

究○ （評価

手法で

はない）

品質に影響するリスクを経験者意見

から推測するHyDEEPの上流工程で

の適用可能性検証。要件定義工程

実データと、同手法により予測を行っ

た結果を突き合わせ、同手法での予

測が可能であることを確認した。

Managing Software Quality through a Hybrid Defect Content and Effectiveness Model

他

080

敬称略R:レビュー、A:分析、S:シミュレーション、

P:プロトタイピング表3-1

詳細調査先一覧(2/2)

３．２


i.

文献深堀

概形調査で収集した文献の情報に加えて、詳細調査対象とした文献に関する公

知の文献、ならびにインターネット掲載情報から、関連情報を広く収集した。

これには、調査先からの情報提供に基づき収集される文献も含んでいる。

調査先の事情により、ヒアリング実施が難しい場合は、公知の情報及び可能であ

れば調査先から提供を受ける情報によって、詳細調査項目を満足する情報の収

集を行った。

ii.

ヒアリング

文献の深堀で確認し得ない点に関し、ヒアリングを行った。

調査項目は表3-2のとおりである。

特に、以下のa,bの2点は文献から知り得ないため、ヒアリングにて情報を収

集した。a.

文献・インターネットで公知になっていない情報

b.

研究や手法実施に関する所感、現状、課題、今後の方針など

調査の観点調査項目手法の内容プロセスに関する手法か、成果物に関する手法か。

どの工程のどの時点で適用する手法か。

定量的データを用いた評価手法か。

その場合は、どのような評価指標（メトリクス）を用いているか。また、ベンチマー

クの取り組みをしている場合は、どのような内容か。手法適用の前提

条件この手法を適用するための前提条件はあるか。

・設計プロセスに条件はあるか

（例：ウォータフォールであること、など）

・設計書作成の標準化のあり方に条件はあるか。手法の実用レベ

ル当該手法の実用レベルは次のうちどれか。

・研究段階／研究成果の実証段階／手法として公開／実プロジェクトで適用

技法化（手法の適

用手順、実施手

順、ツール化など）

手法適用までの手順はあるか。それはどのようなものか。

手法実施の手順はあるか。それはどのようなものか。

テンプレート、フォーマット、ツールはあるか。

手法の有効性定量効果を確認しているか。

・どのような評価指標（メトリクス）を用いているか。

・うち、適用のコストは計測しているか。

・手法適用有無による、品質の違いはあるか。

・他の手法との効果の差を確認しているか。定性効果を確認しているか。

・手法適用先での実施者の所感は得られているか。それはどのようなものか。

定量効果、定性効果の確認に際し、ベンチマーキングを行っているか。それはど

のようなものか。手法の課題、問

題点現時点で把握している課題、問題点はあるか。それはどのようなものか。

・プロジェクト適用上の課題／普及上の課題今後の方針（研究に関して）今後の研究、実証方針・計画はあるか。それはどのようなもの

か。（適用組織・プロジェクトに対して）今後の適用方針・計画はあるか。それはどの

ようなものか。実施例手法を適用したプロジェクトはあるか。それはどのようなものか。件数はどのくら

いか

・プロジェクト規模／業種／業務／ミッションクリティカル性

表3-2

詳細調査項目

３．３


i.

詳細調査の結果を、次ページからのＮｏ．１～１３の事例シートに示す。

事例シートの構成は、図3-3のとおりである。

HyDEEPの調査結果は、３．４に示している。

図3-3

事例シートの構成

調査対象者：ヒアリングを行った場合はヒアリング対象

者、文献調査のみを行った場合は、当該

文献の発表者を示す。敬称は省略する。

内容：対象とした事例や評価手法の概念や目

的、実施手順などを示す。

事例・手法のポイント：開発上流工程での実施における効果や

課題などを示す。

事例No.1

発注者視点品質評価

1.

調査対象者

(株)東京証券取引所

品質管理部長

清田辰巳

2.

内容

次世代株式売買システムの開発に際して、図3-4に示すように、発注者視点で取り

組んだ要件定義、外部設計における一連の品質強化施策である。

3.

事例・手法のポイント

上流工程での施策の特徴は、以下のとおりである。

品質管理体制

•

ベンダ側での品質評価結果を受け取るだけでなく、発注者側専任チームを設け、要件定

義段階で品質評価を実施している。

•

要件定義段階でのCIO承認を明確化した。

開発プロセスと要件定義書記載内容の改善

•

要件定義の記載レベルの精緻化（要件番号の付番、フロー作成、アクタ定義）

•

要件定義書雛形の見直し

•

要件網羅性チェックシートによる、要件項目と成果物記載箇所の紐付け

要件定義書評価方法

•

検収テスト項目の早期作成：検収テスト計画書や、検収テストのチェックリストを上流工程

で作成着手する

•

要件定義書変更理由の分類：基本設計以降に発生する要件変更を分類し、見逃しが多

いと判断される場合は、要件定義書の再レビューなどのアクションを検討している。

図3-4

上流工程での品質作り込み

出典：清田辰巳「上流工程における発注者視点からの品質向上への

取り組み」『情報処理』Vol.50

No.5 2009年5月p.400-404

①要件定義書記載内容の改善◆3層構造の要件定義

第一階層：全体業務フロー図第二階層：業務フロー図第三階層：要件定義書

◆要件定義書雛形の改訂

②要件トレース◆要件トレーサビリティの確保

「要件網羅性チェックシート」の利用◆要件充足度のチェック

③要件定義書の評価◆検収テスト項目の抽出◆変更管理からの品質分析

④製造工程での詳細設計書の評価◆コーディング中に摘出された詳細設計

書のエラー管理（コードレビューで摘出

されるエラーと同等の管理）

1.

調査対象者(株)NTTデータ技術開発本部副本部長ソフトウェア工学推進センタ長木谷強

2.

内容開発プロジェクト外部の第三者が、手順書に従って記述漏れや曖昧な記述が無いことを系統的に確認し、要件定義書の品質を表すスコアを算出する。観点はIEEE Std.830（優先度付けを除く）を元に独自の４つの品質特性（合目的性、記述項目網羅性、明確性、追跡可能性）にまとめており、各項目について評価項目を細分化している。

•

表3-3に品質特性の定義とIEEE

Std.830の品質特性との関係を示す。評価者の能力や主観によるばらつきが大きくならないよう、要件定義書の項目レベルでチェック方法をガイドしている。また、スコア算出シートは配点表と自動計算機能を有しており、評価者は個々の項目の評価に集中できる。結果は定量的なスコアとともに、品質改善アドバイスとしてレポートしている。

3.

事例・手法のポイント手法の効果として以下のような結果が確認できた。

•

アドバイスの有用性について実施後のプロジェクトにヒアリングしている。

調査時点で完了した７件のＰＪの中で、平均８４．８％のアドバイスが有用だったとい

う回答を得た。•

第28回ソフトウェア品質シンポジウム2009（SQiPシンポジウム2009）での発表では、

１０件の要件定義書に対して、スキルの異なる第三者４人が評価を行い、バラツキ

が小さく（100点満点で平均値の前後±7.09点程度）、経験の少ない要員でも評価

が可能であることを確認している。

さらにこの手法は以下のような品質向上への施策に有効である。•

配点表はカスタマイズが可能であり、要件の重要度や業種・業務、システムの特性

などを考慮することにより、さらに評価結果の精度を高めることが出来る。•

基本的なスコアリングの考え方は、要件定義以外の設計書に対しても応用可能で

ある。

事例No.2

要件定義書第三者品質スコアリング

要件定義スコアリング

の品質特性定義

起源となる

ＩＥＥＥStd.830の品質

特性

合目的性開発するシステムの目的が明らかであり、全ての要件はその目的に適っている。 Correctness

記述項目網羅性要件定義書に書くべき項目が全て記載されている。 Completeness

明確性全ての記述内容の意味が明確である。 Unambiguity,

Verifiability

追跡可能性各記述内容の起源（提案書や企画書などの記述内容、要件定義所内のほかの記述内

容など）が明確であり、かつ、各記述内容が後肯定で参照しやすいよう容易に識別でき

るように記述されている。

Consistency,

Modifiability,

Traceability

出典：大杉直樹他

「記述漏れと曖昧な表記の防止を目的とした要件定義書の第三者品質スコアリングに向けた試み」第28回ソフトウェア品質シンポジウム2009（SQiPシンポジウム2009）

表3-3

要件定義スコアリングの品質特性

事例No.3

ＱＩ

( Quality

Inspection)

1.

調査対象者

日本アイ・ビー・エム(株)

アプリケーション開発事業

エンタープライズ・アーキテク

チャー＆テクノロジー

クオリティ・エンジニアリング

部長

細川宣啓

2.

内容開発作業と並行して、第三者（開発メンバ以外の外部の品質検査の専門家）による工程途中の「こまめな」インスペクションを行うことにより、欠陥の早期発見を実現する。欠陥指摘だけでなく、作成者の書き癖や記述ルールの準拠性をアドバイスすることにより、欠陥予防にも貢献している。図3-5に開発工程におけるＱＩの実施タイミングとプロセスを示す。独自の検証ツールや検証方法の開発により、プロジェクトの進捗に影響しない短時間のフィードバック、評価者のスキルの違いによるばらつきの最小化を実現する

3.


要件定義フェーズにおけるＱＩ実施の留意点と着眼点は以下の通りである。

留意点•

様々なドキュメントから総合的に判断して要件が表現できるか検証すること–

全ての種類のドキュメントから作成チーム別、作成者別に均一に対象を選定する

•

記述目的、存在理由を常に確認すること–

「これは要件か？」、「プロジェクトの目的達成に必須か？」、「実現できなかったらどうな

る？」といった質問を繰り返す。チェックリストを初めとするインスペクションツールに確認ポイ

ントとして列挙しておく。

着眼点の例•

文の曖昧さ–

作成者が確信を持っていない文、よく理解していない文は叙述的で読点が多い長文となる

傾向から、論理矛盾、不整合、一貫性欠如などに注意する。

•

文のコピー率–

文を安易にコピーすると文のコピー先の前後に欠陥が生じやすい傾向から、不整合や矛盾

などに注意する。この際、文を長さでソーティングするなど検証ツールを利用することにより、

効率よく確認できるように工夫している。

出典：細川宣啓「第三者インスペクションによる品質検査と欠陥予防」『情報処理』Vol.50

No.5 2009年5月p.405-411

図3-5

ＱＩ（第三者インスペクション）の実施タイミングとプロセス

事例No.4

ＩＶ＆Ｖ

1.

調査対象者

有人宇宙システム(株)安全開発保証部

星野

伸行

2.

内容

発注者、およびベンダなどの開発組織から独立した、検証（verification）と妥当性確認

（validation）の取組みであるＩＶ＆Ｖを、宇宙航空研究開発機構（ＪＡＸＡ）の宇宙機ソフト

ウェア開発に対して遂行している。図3-6に概要を示す。

3.

事例・手法のポイント発注者、およびベンダなど開発組織からの「独立」は、以下の3つを指している。

体制的独立•

ＩＶ＆Ｖを実施している有人宇宙システムは、発注者（ＪＡＸＡ）、開発組織（各ベンダ）と異なる組織に

属している。

•

ＩＶ＆Ｖの評価結果は、発注者に直接報告した後、発注者から開発組織に対してフィードバックされる。

•

評価スケジュールも開発スケジュールと独立して組まれている。

予算的独立•

ＩＶ＆Ｖの費用は、開発費とは別に確保されている。そして、一定規模以上の開発においては、ＩＶ＆Ｖ

を実施することがＪＡＸＡの方針となっている。

技術的独立（開発上流工程で実施している主なＶ＆Ｖ技法）•

チェックリストに基づくレビュー：姿勢制御チェックリスト、ボイジャー・ガリレオチェックリスト

•

モデル検査：一貫性・完全性分析、処理タイミング解析、耐故障性解析

等

•

ハザード解析：ＳＦＴＡ（ソフトウェア故障木解析）でのソフトウェア故障箇所特定・解析(図3-7）等

データ処理

異常

ノミナル機能不全

にいたる不具合機能維持不能

にいたる不具合安全性機能不能

にいたる不具合

データ処理

ロジック誤りデータ停止

処理異常

データ停止値定義ミス

データ

識別抜け

設定誤り

図3-7

SFTAにおけるソフトウェア不具合ツリー

IV&V

: Independent Verification & Validation

図3-6

ソフトウェアＩＶ＆Ｖ出典：「クリティカルソフトウェアに対するIV&V : Independent Verification and Validation」『情報処理学会研究報告.

ソフトウェア工学研究会報告』IPSJ SIG Notes 2007(33) pp.81-87 20070322

事例No.5

汎用製品開発における品質会計

1.

調査対象者

日本電気(株)コンピュータソフトウェア事業本部統括マネージャ

誉田直美

2.

内容

品質会計手法を、汎用製品ソフトウェア開発における品質施策検討のインプット、

効果の検証手段として活用している事例である。

品質会計手法の概要は以下のとおりである。図3-8に概念図を示す。設計・製造工程で作り込んだバグを負債とみなし、レビュー・テストによるバグ抽出によりこの負債を返済し、負債が０になった時点で出荷することを基本としたソフトウェア開発管理の方法論であり、1970年代にNECが提唱し、30年の運用実績を持つ。各工程でのバグを予測し、工程ごとに、組織知見に基づく「やるべきこと」を完遂し、残存項目無しを確認して次工程に進むことを厳守する。

特に、上流工程でのバグ抽出を重要と考えてテストではなくレビューによるバグ摘出を重視し、基本設計～コーディングまでのバグ摘出率を高めることを目標にする。

設計・製造過程レビュー・テスト

バグバグバグ

製品

作り込み

製品

摘出

3.


オペレーティングシステム等の汎用製品ソフトウェアは、同一製品の多数顧客での使用、

派生開発による複数製品への同一ソフトウェアの適用などの特徴がある。バグ１件の影

響範囲が広いのはもちろんのこと、品質向上によるプラスの影響も大きいため、品質管

理において表3-4に見られるような「品質の見える化」施策を講じている。

・レビュー技術の向上（レビュー十分性の分析）、テスト技術の向上・回帰型モデルによるバグ予測技法、予測見直しノウハウの確立・上工程品質会計、テスト工程品質会計の精緻化、遵守・バグ分析の2方向化（ツールによる自動分析と、会議での深い議論）・責任者と有識者による工程移行判断

・開発プロセスの詳細な定義（入出力、バグの意味も明確化）と遵守・設計技術自体の向上（UMLの導入等）・第三者検査の実施（機能テスト後、品質保証チームによる）

品質評価・

開発管理

プロセスの

施策

開発

プロセスの

施策

・バグを確実に

摘出する・残存バグを

０にする

バグを

作り込みにくい

品質確保

ポイント

予測値

実績値

図3-8

品質会計の概念図

表3-4

汎用製品ソフトウェア開発での品質向上施策

事例No.6

要求仕様書静的解析

1.

調査対象者日本電気通信システム(株) 組込システム事業本部第二組込システムソリューション事業部シニアコンサルティングエキスパート日吉昭彦

2.

内容解析ツールによる自動解析と、解析結果の専門家による評価を組み合わせた、要求仕様書の解析手法である。解析の観点を、曖昧、未凍結、複数仕様の単数化、複数条件有り、抜け道、階層、オブジェクト区切り不適当、受身、一貫性の９つのカテゴリにまとめ、さらに各々にサブカテゴリを用意している。これらのカテゴリはIEEE Std.830が提示する良いソフトウェア要求仕様書の8特性の中で7特性に対応している。

•

図3-9に解析結果の事例として、９つのカテゴリに対する問題の検出結果と、解析の観点の一つであ

る“曖昧”についてサブカテゴリ毎の検出結果を示す。

“Ｂｏｉｌｅｒｐｌａｔｅ”に準拠した記述ガイドにより良い書き方を具体的に示している。利用者による検出条件の絞込みや、新たな条件の追加が容易であり、これらをカスタマイズすることにより、特定の業種や業務について精度の高い解析が可能となる。

3.

事例・手法のポイント自動解析により弱点を見極め、効率よく問題を抽出できる。

•

あるプロジェクトの要件文書で適用したところ、全要件項目の３０％に当たる１００件の要件で致命的欠陥を検

出した。特に仕様の漏れについて多くの問題が検出されたことから、機能要件に着目して動作と場合分けのマト

リクス表で分析したところ、その時点で仕様の６０％しか記述されておらず、４０％については漏れていることを

確認できた。

Ｂｏｉｌｅｒｐｌａｔｅに準拠した要件文書を作成することにより、精度向上が可能である。•

記述する人の書き方のバラツキを抑え、曖昧さのない要件定義書を作成できる。

•

上記プロジェクトでＢｏｉｌｅｒｐｌａｔｅに従い要件定義書を作成しなおしたところ、改訂版では機能要件が約１０倍

（７００件）となった。

出典：日吉

昭彦「要求仕様書、使えますか？～要求仕様書のあるべき姿を構造・記述の観点で捉える～」豆蔵＆ＮＣＯＳ共同セミナ（組込みソフトウェア品質向上セミナー「仕様書改善・設計改善の処方箋」

図3-9

解析ツールによる静的解析結果の事例

1.

調査対象者

立命館大学

情報理工学部教授

大西

淳

2.

内容a.

ソフトウェア開発におけるシナリオを以下のように定義している。•

システムに求められる振る舞いを、利用視点から描いたものである。

•

開発のあらゆる段階で、様々なステークホルダ間の情報共有、相互理解に役立つ。

特に、ユーザに理解可能な表現でシステムの振る舞いを描くことが出来るため、開発上流工程にお

いて発注者と開発者との間で要求を具体化するプロセスに非常に有効な手法である。

b.

シナリオを用いた要求獲得・分析の内容は図3-10に示すとおりである。•

シナリオ作成–

日本語に動詞・名詞の制限をかける「制限言語」を用いて、シナリオを作成する。

–

システムの振舞いをすべて網羅するために、正常系シナリオを正常、代替、例外シナリオに進化させる。

–

当該作業を主体的に行うプレイヤーの視点にシナリオを変換する。

•

ルールの生成–

イベントと、イベントの起きる時期や順番を記載する。

•

ルールによるシナリオのチェック–

ルールとシナリオを突き合わせ、一貫性を検証する。

事例No.7

シナリオを用いた要求獲得・分析

3.


汎用化への課題として、以下の研究を進めている。

ドメインに特化した制限言語の辞書を用意することが、正確なシナリオ作成に必要であり、幅広いドメインでの実証実験が必要である。

ルールの生成は工数を要するところであるが、自動化が可能であり、研究を継続している。

シナリオ正常典型的

異常

典型的でない

正常シナリオ

代替シナリオ

例外シナリオ


異常

典型的でない

正常シナリオ

代替シナリオ

例外シナリオ


異常

典型的でない

正常シナリオ

代替シナリオ

例外シナリオ


異常

典型的でない

正常シナリオ

代替シナリオ

例外シナリオ

作成

※ドメインごとの作成が必要

制限言語の辞書(※)名詞

動詞

名詞

動詞

制限言語の辞書(※)名詞

動詞

名詞

動詞

名詞

動詞

名詞

動詞

ルールDBルールDB 適切なルール

の選択

チェック

視点の変換

別の視点からのシナリオ

ある視点からのシナリオ


異常

典型的でない

正常シナリオ

代替シナリオ

例外シナリオ


異常

典型的でない

正常シナリオ

代替シナリオ

例外シナリオ

統合したシナリオ

要求

作成

図3-10

シナリオを用いた要求獲得・分析の概念

事例No.8

要求獲得モデルPRINCE

1.

調査対象者

筑波大学大学院ビジネス科学研究科准教授

中谷多哉子2.

内容PRINCEモデルは、開発プロセスの中で、最終的に要求が全て獲得されるまでを

要求獲得のプロセスと捉える考え方に基づく。

図3-11に示すとおり、「要求獲得モデル」、「要求獲得

の計画方法」、「開発中要件の獲得状況観測方法」

からなる。a.

要求獲得モデル•

プロジェクトの遂行期間を「早期」「中期」「後期」

に分け、要求の持つ特性によって、Ｅ、Ｍ、Ｌ、Ｕの

4種類の成熟パターンを定義する。–

Ｅタイプ：早期成熟型–

Ｍタイプ：中期成熟型–

Ｌタイプ：後期成熟型–

Ｕタイプ：突発型

•

それぞれの時点で「要求者のゴール」「プロジェクト

のゴール」「開発者のゴール」がどのような状態に

なっているべきかを定義したものが表3-5である。

図3-11

PRINCEモデルにおける要求獲得モデル出典：中谷多哉子「要求獲得計画に向けたPRINCEモデルのための

要求計測ガイドライン」『電子情報通信学会技術研究報告』

IEICE

Technical Report

KBSE2009-16(2009-7)

PRINCE : Pre Requirements Intelligence Net Consideration and Evaluation

開発段階要求者のゴールプロジェクトのゴール開発者のゴール

早期ソフトウェアの具体的なイメージお

よび効果を理解している開発するソフトウェアの概要が定義

済みになっている要求の妥当性について、要求者の

合意を得ている

中期ソフトウェアが現実世界へ与える影

響を検証しており、検証結果にも合

意している

ソフトウェアの内部の詳細な構造が

決定されており、その妥当性も確認

されている

ソフトウェアの検証事項を決定して

おり、開発者間でも合意している

後期導入されるソフトウェアを利用する

ための準備を完了させているソフトウェアを導入可能な状態にして

いる構築されたソフトウェアの検証、お

よび妥当性を確認済みにしてある

表3-5

PRINCEモデルにおける開発段階の分類

b.

要求獲得計画立案•

表3-5に基づき、各段階で獲得すべき要求を想定し、要求獲得計画を策定する。–

Ｅ（開発経験やドメイン知識が豊富）：外部設計時までに獲得する

–

Ｍ（業務知識不足や顧客からの技術移転の困難が予想される）：内部設計時までに獲得する

–

Ｌ（短納期の場合や、専門知識を持つ要員のアサインが後期になる）：実装時までに獲得する

–

Ｕ（法規制や、外部インタフェースの変更、経営環境の変化などの影響を受ける）：発生した時点で

再計画する

c.

開発中要件の獲得状況観測方法•

要求獲得を計画した後は、以下のガイドラインに従って、要求の変更や追加が無いかを観測する。

–

要求仕様書第1版をベースラインとし、以降の

追加、変更、削除を新たな要求獲得１件と

みなし、測定し、状況を分析する。

–

要求は、その性質により安定性や成熟度が

異なると考え、表3-6のような分類を定義して

観測の参考とする。

機能要求非機能要求

支援要求：組織内

部要求に基づくもっともリスク

が低い

3番目にリスク

が高い

戦略要求：外部環

境により変化

2番目にリスク

が高いもっともリスク

が高い

表3-6

要求変更・追加のリスクの例

（※）

※当該事例におけるリスクのランクである。機能/非機

能要求それぞれの内容により、ランク付けは異なる3.

事例・手法のポイントa.

詳細な要求であるほど、要求の根拠や、要求が達成すべきゴールが明確になっているかど

うかで結果の精度に差が生じるため、これらを確実にすることがポイントである。b.

2009年度中にPRINCEモデルのガイドラインを発行し、一般公開する予定である。

1.

調査対象者

奈良先端科学技術大学院大学

情報科学研究科助教

森崎修司

2.

内容レビューの観点をあらかじめ定め、観点ごとに担当者を割り当てることにより、有効なレビュー指摘を実現する。誤字・脱字や表現上の指摘ではなく、重大欠陥を引き起こす問題の指摘や修正コストの低減に役立つ指摘の抽出に効果的な手法である。観点の絞込みは定義したリスクや前バージョンでの不具合から行う。リスクベースドレビューの効果として、図3-12にソフトウェア開発に従事する実務者による外部仕様書レビューの実験結果を示す。

•

観点（リスク）が設定されていないレビューは、指摘総数は多いが、表現上の指摘や

リスク低減には関係のないものが大半となり、レビュー実施の効果（早期発見による

修正コスト削減）が小さくなる。•

観点を設定し、さらに指摘ごとにリスクの確認をしたレビューは、指摘総数は少ない

が、リスク低減や修正コスト低減に関係する欠陥の検出が大半となり、レビュー実施

の効果が大きくなる。

事例No.9

リスクベースドリーディング（観点設定型レビュー）

図3-12

ソフトウェア開発に従事する実務者を対象とした実験結果出典：森崎修司「コスト最適化時代のレビュー、どう実施していますか？～先進的事例と国際研究動向

の紹介をまじえて」、IBM Rational Software Conference2009

3.

事例・手法のポイントリスクベースドリーディングの効果を高める工夫を以下にあげる。

•

計画段階で、重要な観点が抽出できるよう、過去のデータの蓄積や熟練者のノウハ

ウを明文化する。•

後工程での修正・確認工数の低減に役立つ指摘が出来たかを検証し、観点や分担

の見直しに活かす

1.

調査対象者

清水建設(株)

情報システム部

システム運営グループ長

寺田

尚弘2.

内容a.

「共通フレーム２００７」をベースとしてシステム開発の自社標準を見直し、上流工程の

プロセス評価を強化した事例である。b.

改善の契機となった要因は以下の２点であり、共に、上流工程のプロセスに影響を与

えるものであった。•

システムのオープン系、Webへの移行に伴う要件の複雑化•

ステークホルダの増加による、要件合意の難易度上昇

c.

図3-13にあるように、「共通フレーム２００７」の他、「経営者が参画する要求品質の確

保～超上流から攻めるIT化の勘どころ～

第2版」（SEC

BOOK）、「システム管理基

準・追補版」（経済産業省）を参考にした。

事例No.10

超上流プロセスの改善によるプロセス評価の強化2009年3月

ＳＥＣセミナー資料より

（旧）システム開発標準（新）システム開発標準共通フレーム2007

超上流冊子

システム管理基準

3.

事例・手法のポイントa.

(新)システム開発標準の強化ポイント•

成果物作成要領と実システムの事例をベースにしたサンプル集を作成した。

•

非機能要件を大幅に追加定義した。

•

表3-7にあるように、各工程においてQCD確保の観点で必要なレビューを定義した。

上記には、要件定義内容（RFP）を、要件定義工程の終了時点で関係者によるレビューを行い、

以降の工程の投資決裁を行うプロセスの明確化を含む。

•

システム部門だけでなく、業務部門の役割を明確化した。

b.

(新)システム開発標準の効果•

「仕事の進め方」が詳細に定義されたため、個人の経験や仕事の進め方による開発作業のバラ

ツキが軽減された。

•

システム化計画、要件定義という超上流工程からテスト、運用、保守にいたるライフサイクル全

般にわたって必要な作業の検討が可能となった。

•

新たなプロセスの追加時に、共通フレーム準拠であることから、情報システム部の内部やベンダ

に対して必要性を説明しやすくなった。

工程各工程でのレビュー承認者

名称目的業務

所管部門情報

システム部

システム化

計画システム化

計画レビューシステム化計画の確認 XXXX YYYYYY

要件定義要件定義

レビュー要件定義内容（ＲＦＰ）の承認

：システム化の企画を反映した要件定義内容（機能要件、

非機能要件）について関係者の承認を得る

XXXX YYYYYY

システム開発

計画レビューシステム開発計画の承認 XXXX YYYYYY

表3-7

超上流工程でのプロジェクトレビュー一覧

図3-13

標準見直しのインプットとなったドキュメント

1.

調査対象者

(株)東芝

ソフトウェア技術センター

ソフトウェア設計技術開発担当参事

池田信之

他

2.

内容

モデル検査の概念は、図3-14に示すものである。•

形式的検証の実現技術の一つであり、ソフトウェアを、仕様の段階で機械的かつ網羅的に探索して

不具合を検出する手法。

•

システムの振る舞いや動作環境を記述した「検査モデル」、システムが満たすべき性質を定義した

「検査条件」を用意し、システムの仕様を記載した「状態モデル」を入力して検査を実行する。

•

状態モデルに問題があった場合は、検査条件を満たさないケースが出力され、不具合を解析して状

態モデルに反映する。

事例No.11

モデル検査によるソフトウェア上流設計の品質向上東芝レビュー

Vol.64

No.4

(2009)

仕様試験実装設計モデル

検査

早期

バグ発見

3.

事例・手法のポイント不具合解析の自動化ツール（図3-15参照）を開発し、検査工数を圧縮した。図3-16に示すように、モデル検査に実時間仕様検査を実施する技術を取り入れ、実施した。

検査モデルと検査条件の

作成等、準備工数が必要

図3-15

反例解析ツール

図3-16

実時間仕様を検査するためのモデル化手法

実時間仕様検査社会インフラ系での制御システム等での利用例(1)データ生成から参照までの時間差の計測(2)CPU使用率の計測(3)優先度逆転の発生と処理遅延時間の計測

図3-14

モデル検査の概念図

事例No.12

品質機能展開を用いたプロトタイピング手法品質機能展開＝ＱＦＤ（Ｑｕａｌｉｔｙ

Ｆｕｎｃｔｉｏｎ

Ｄｅｐｌｏｙｍｅｎｔ）

3.


プロトタイピングの各段階（フェーズ１～３）で、品質機能展開のマトリクス群を適用。

•

フェーズ１

：ＱＦＤの「システム要求／概略仕様対応表」を用いて、開発者とユーザ

（要件提供者）が検討した上でプロトタイピングの種類を決める。

•

フェーズ２

：ユーザインタフェースを中心に、プロトタイプの開発、評価、修正を繰り

返す。明確になったシステム要求は展開表に随時反映。

•

フェーズ３

：技術課題の検証を中心に、ステップ１～４を実施し、ステップ３～４を

繰り返しながらシステム要求を明確化。

図3-17

QFDを組み合わせたプロトタイピングの概念図

1.

調査対象者

(株)ＮＴＴデータ

服部

昇

他

2.

内容

要求記述を構成要素に分割し、要求不備の原因との関連を特定付ける手法。

手法の定義•

ソフトウェアに対する機能要求は「依頼者が、ある状況の下で、何かのイベントを契機として行う入力

により、指定された処理が実行、出力され、期待する結果が結果の受領者にもたらされる」と定義し、

これらの1つずつの要素を「要求記述の構成要素」と呼び、要求の誤りはこれらのいずれか、またはそ

の対応関係に問題があると判断する。

分析方法•

①要求を図3-18の順序で構成要素ごとに検討して定義する•

②要求定義以降の工程で、要求誤りに起因するエラーが発生した時、構成要素のどこに原因があ

るかを特定する

•

③不備のあった構成要素の最上流に遡って不具合を修正する

事例No.13

要求の構造に基づく要求品質の管理

依頼元アクタ

結果アクタ

依頼元アクタ状況

構成要素をこの順序で検討する

要求不備の

原因となった

構成要素を特定不備のあった

構成要素の最上流に

遡って不具合を修正

これらの構成要素の網羅性を、仕様化完了基準、レビュー観点に使用する

３２

１

①～③：

分析の順序

④：完了基準、

レビュー基準への応用

結果

アクタ状況出力処理入力イベント

要求記述の構成要素

出典：信学技報IEICE Technical Report SS2007-72(2008-3)

図3-18

手法の概要

3.


手法の応用として、以下のような期待を持っている。

実プロジェクトにおいて、構成要素ごとの要求誤りのデータが蓄積されれば誤り発生の傾向が明確になり、要求定義工程での資源投入計画にも役立つ。

この構成要素を、要求仕様化の完了基準や要求レビューの評価基準に応用する。

構成要素ごとに網羅性を確保すべき工程が特定できれば、構成要素に紐付けて発注者とベンダの検討責任の分担が切り分け可能となると推測している。

３．４

HyDEEPの調査結果

1.

上流工程においてHyDEEPが適用可能かどうかを研究した事例の調査を行った。CoBRA法(※)研究の進展と並行して、同手法との連携という観点で注目しているHyDEEPの上流工程での実用可能性を調査することが目的である。

※CoBRA法については、情報処理推進機構ソフトウェアエンジニアリングセンター著, SEC BOOKS「ソフトウェア開発見積りガイドブック」を参照のこと

2.

調査の概要実在プロジェクトにおける、既に完了した活動を題材に、HyDEEPによる品質予測結果と実際の品質を比較し、上流工程での適用可否を検討した研究成果を調査した。

対象とした活動は、有人宇宙システム（株）において実施した、５件の宇宙機ソフトウェア開発プロジェクトのＩＶ＆Ｖである。

既に完了した、ＩＶ＆Ｖの要件定義書レビュー活動を対象に、実際にレビューを実施したメンバーに、レビューの品質に影響を与える因子を指摘してもらい、HyDEEPによる品質予測を実施している。

3.

結論HyDEEPによる予測結果と、実際のプロジェクトにおける要件定義書レビューの品質の傾向は一致した。（実施メンバーは、HyDEEPの予測結果と実際の品質の傾向が一致することに同意した）

このことから、要件定義においてHyDEEPを適用した品質予測ならびに品質保証活動計画の策定は可能であると推察する。

要件定義工程においては、今後、活動中のプロジェクトでの実証を進めるとともに、定量的評価が可能な指標の研究を進めることを期待したい。

No.14

HyDEEP

1.

調査対象者

有人宇宙システム(株)

中尾春香

2.

内容経験者の知見による「QA(品質保証)活動に影響を与える因子の評価」と、「入手可能な過去プロジェクトデータ」を組み合わせる品質予測モデル「HDCE」を中核にした品質予測手法である。図3-19にHDCEの概念図を示す。

検証結果•

HyDEEPで計算した欠陥検出傾向は、５件のプロジェクトの

実際の欠陥検出傾向と一致した。（経験者は、プロット結果

に同意した）（図3-21）•

HyDEEPは要件定義工程でのレビューにおいて欠陥検出の

予測に有効である（＝要件定義工程でのレビュー計画策定

に有効である）ことが確認できた

プロジェクトの過去

データ（オプション）

現行プロジェクトの

特性

実施者の意見（対象とす

る活動に対する効果／

潜在欠陥の程度を

３段階で評価）

効果

潜在欠陥

図3-19

HDCE概念図

ＨＤＣＥの

適用手順

3.


JAMSSの要件定義書レビューにおける検証実施内容は、図3-20のとおりである。

•

5件の過去プロジェクトの実際の要件定義工程における要件定義書のレビューを題材に、HyDEEP

の適用可否を検証した。

•

5件のプロジェクトの要件定義書レビューでの影響因子を経験者に挙げさせ、ＨＤＣＥを適用して品質

を推定した。

潜在欠陥・効果の

方程式

HyDEEP：Hybrid

Defect Content and Effectiveness Early PredictionHDCE:Hybrid Defect Content and Effectiveness

１２

３

４

５

①過去プロジェクトデータを収集する②実施者の意�

「信頼性向上のための 情報システム開発上流工程における 品 …i....

Documents

「信頼性向上のための情報システム開発上流工程における品 …i....