【12-E-2】　SEC流品質作りこみESQR...

山崎

太郎(独)情報処理推進機構(IPA)ソフトウェア・エンジニアリング・センター(SEC)研究員

12-E-2

SEC流品質作りこみESQR 組込みソフトウェア開発向け

品質作り込みガイドのご紹介

プレゼンター�

プレゼンテーションのノート�

１．自己紹介　　ユニシスでの仕事、IPA/SECでの仕事２．SEC ソフトウェア開発力の強化 2004年10月1日設立「ものづくり」としての高品質なソフトウェア開発を目指す産学官連携拠点技術者スキル領域：組込みソフトウェア技術者の育成推進エンジニアリング領域：開発手法、技術の整備公的な支援機関(SEC)として組込みソフトウェアに適したソフトウェアエンジニアリング技術の整備・普及推進を図る３．ESQR SECでは、昨年11月に「組込みソフトウェア開発向け品質作り込みガイド」ESQRを刊行しました。このガイドでは、定量的品質コントロールを行うための概念、手法、品質指標、参考値を提示しています。 �

2

日当たり日当たり農薬農薬肥料肥料

•“虫”が入らないようにする•おいしく育てる

育てる過程の工夫が必要

•育て方が適切か•できた果実が消費者の好みに合っているか

計測し計測し評価し評価し改善する改善する

おいしいりんごの育て方おいしいりんごの育て方



最初に唐突と思われるかもしれませんが、たとえ話として「美味しいりんごの育て方」を話したいと思います。私たちの業界では「品質の良いソフトウェア」の育て方ということになるでしょうか。美味しいりんごを育てるとき、農家の方々はどんなことをしているでしょうか？専門家ではありませんが、おそらく、美味しいりんごを育てるために、・消費者の好みはどうか、どんな品種を作るのか、・そのために日当たりはどの程度にするのか・どんな、農薬や肥料を使い、どの程度あげるのかといった、育てる上で様々な工夫をしているのではないでしょうか。そして、育ち方をみて日当たりや農薬、肥料を調整して、最終的に美味しいりんごを収穫する作る相手によってレベルややることが変わる(自分で食べるのか、人に上げるのか、売るのか) ウェッジウッドきちんと作ることときちんと検品すること�

3

おいしいりんごおいしいりんごって？って？

誰が食べるのか？

自宅用

ご近所くらいには配る

出荷用

どのように作るのか？庭の木一本だけ/裏の畑/広いりんご畑

ひとりで/人を雇って

育てやすい品種？

どうやって育てるか？

肥料は何を、どのくらい

水やりは何回、どのくらい

農薬は何を、どのくらい

摘果はいつ、どのくらい

育ち具合は？大きさ

色

味

傷み具合



我々の身の回りには実にたくさんの“もの”が存在しています。我々は常日頃から、こうしたさまざまな“もの”について、それらが持つ特質について言及することが少なくありません。たとえば、「りんご」というものを考えてみると、「りんご」がもつ特質− たとえば、重さであり、大きさ、色などさまざまな性質−を感覚的にとらえ、その特質を評価しています。ところが「大きいりんご」を考えた場合、大きい小さいはそれを受けとる人の感覚に左右されてしまいます。たとえば、商品として大きさを基準にりんごの価格を決める場合、こうした人の感覚に頼った大きさの評価はきわめて曖昧で、ある意味、あまり参考にならないかもしれません。このため、一般的には「りんご」の直径を測り、数値として表現することで、個人的な感覚の差異をなくし、より科学的に“もの”のもつ特質を表現することが行われています。そして、りんごの直径がある値より大きいものを大玉、ある値からある値までのものを中玉などといった具合に、直径と基準値を利用してりんごのクラス分けをしたりします。この場合、「りんごの直径」は「りんご」という“もの”の大きさを評価するための指標ということになります。このように、世の中に存在するどのようなものも、それぞれの特質をもっており、それを測り評価するための指標が存在するということになります。 �

4

指標：

指標の精度：計ろうとしている対象の特性を表現し得る適切な精度を意識して計ること

指標の単位：指標値を表現するための単位系は指標定義と合わせて、明確に一つに決めておくこと

品質評価指標を品質評価指標を用用いた品質目標設定いた品質目標設定

ものさし・測り方・精度・単位

・有形、無形にかかわらず対象（物、作業、サービスなど）の特質を表現するための科学的な根拠をもったものさし

・指標の計測方法も合わせて定義し、誰が計測しても同じように値を計測できること



先に示した「りんごの直径」という指標をもう少し考えてみましょう。「りんごの直径」といっても、図1-2に示すようにりんごのどの部分を測るかで変わってきます。たとえば、りんごの球体の中心を通る面で切ったところで直径を測るのか、もう少し上側の面で切ったところの直径を測るのかで、りんごの直径の値は変わってしまいます。このように測り方によって指標の値が変わってしまっては意味がありません。このように指標はその測り方とセットにして定義を与えておかないと、意味のないものになってしまいます。また、りんごを測るときに、どのような粗さのものさしを利用するかもまた考えておく必要があります。すなわち、最小目盛が1センチメートルのものさしで直径を測れば、おおよそ10センチメートルとか、7センチメートルといった値が得られます。これに対し、最小目盛が0.1ミリメートルのものさしを用意し、りんごの直径が7.13 センチメートルとか7.14センチメートルと騒いでみたところで、0.01センチメートルの差はあまり意味をもちません。この例からわかるように、指標で測る対象の特質に応じた精度を考えて測る必要があるといえます。さらに、長さの単位を考えると、センチメートル、ミリメートルなどのメートル法のものもありますが、インチといった単位もあります。りんごの直径について考えると、特にメートル法でなければいけないといったことはありませんが、直径を測る人によって、センチメートルだったり、インチだったりと単位が異なってしまうと、りんごの直径を比較したりする場合に混乱が起きてしまいます。ここまでの例をもとに指標の測り方と単位・精度などを整理すると次のようになります。指標は何のために決め、測るのでしょうか？　「りんごの直径」を考えてみると、たとえば、「りんごの直径」が基準値よりも大きければ、「より良いりんごとして出荷してもよさそうだ」という判断をすることができるかもしれません。一方、極端に基準値を下回ったりんごは、発育不良という判断をして、その場で収穫をせずにもう少し木にぶら下げておいて大きくなるのを待つ、といった判断をすることもできます。このように、実際に計測された指標は、たとえば収穫や出荷などの判断に使うといった利用法が考えられます。さてここでもう一つ別の指標「りんごの軸（果柄）の太さ」を考えてみましょう。軸の太さの基準値を2ミリメートルと考え、いくつかのりんごをそれより太いもの、細いものに分けてみましょう。「りんごの軸の太さ」に応じて2つに分けたグループに何か意味はあるでしょうか？　確かに「りんごの軸の太さ」を測ることはできますが、それの太い・細いは商品としてのりんごの価値にはほとんど影響なさそうです。この例のように、指標の対象が有する特質はさまざまであり、それぞれ指標を測ることは可能です。しかし、中には測れるからといって計測しても、ほとんど意味を持たないであろう指標があります。一般的に、「指標を計測する」ということは、測り評価することでその結果を何かに利用することが前提になります。すなわち、指標を決める場合には、まず、「指標を用いて何を言いたいのか、あるいは指標を何に利用したいのか」を明確にしたうえで、それに適した指標を選ぶことがきわめて重要になります。 �

5

製品出荷後の不具合：原因別製品出荷後の不具合：原因別

ソフトウェアの不具合は依然としてトップ→ソフトウェアの不具合がシステムの品質に直結

プロジェクト責任者

Q6-1-22008年版

組込みソフトウェア産業実態調査

製品出荷後の不具合：原因別

0.0% 20.0% 40.0% 60.0% 80.0%

製品企画・仕様の不具合

ソフトウェアの不具合

ハードウェアの不具合

製造上の不具合

運用・保守の不具合

その他の不具合



このグラフは右下隅に書いてありますが、2008年版の経産省「組み込みソフトウェア産業実態調査」というのを毎年行っています。データは経産省が公開しています。SECのWebサイトからも辿れます。その中の、プロジェクト責任者向けへの質問の回答をグラフにしたものです。製品出荷後の不具合は何が原因でしたか？という問いへの答えです。言うまでもないですが、ソフトウェアの不具合、という回答がダントツです。�

6

製品に不具合を入れないためには製品に不具合を入れないためには

開発時にバグを入れない

どうしてもバグは入り込む

ではどうしたら？

入ったバグを見つけて取り去ればよい

バグを見つけるためには？

レビューとテスト

テスト、していますよね？

では、レビューは？



さて、製品に不具合を入れないようにするにはどうしたらよいでしょうか？開発時にバグを入れないのが良いですね。でも、どうしてもバグは入り込みます。ではどうしたらよいでしょう？入ったバグを見つけて取り去ればよいのですでは、バグを見つけるためにはどうしたらよいでしょう？レビューとテストをすればよいですねテストしていない企業は少ないですよね？では、レビューは？世の中の実態を見てみましょう �

7

工程別レビュー実施の実態工程別レビュー実施の実態

工程別レビュー実施状況

0% 20% 40% 60% 80% 100%

システム結合・総合テスト

ソフトウェア結合・総合テスト

ソフトウェア実装および単体テスト

ソフトウェア要求定義

システムアーキテクチャ設計

システム要求定義

企画・調査・要求獲得

完全に実施

部分的に実施

実施していない

プロジェクト責任者

Q7-72008年版

組込みソフトウェア産業実態調査

どの工程でもレビューを部分的ながらも実施している企業も多いが、「レビューを実施していない」も20％を超えている



これも先ほどと同じ、組込みソフトウェア産業実態調査から持ってきたデータをグラフ化したものです。レビューをしていますか？という問いに対し、工程別毎に答えていただいています。どの工程でもレビューの実施状況はそれほど大差ないのですが、実施していないという回答がどの工程でも 20％を超えています。皆さんの職場ではいかがですか？ちょっと胸に手を当てて考えてみてください。 �

8

組込みシステムの品質・信頼性向上組込みシステムの品質・信頼性向上

計画的マネジメント

ESMR：

マネジメントガイド

ESMR：

マネジメントガイド

要求・設計の高信頼化

高信頼性に着目した

ソフトウェア設計の考え方

定型化コントロール

プロセス設計高信頼に求められるプロセスの設計と実装

レビュー・テストプロセス強化SAP：安全関連プロセス

ESPR：

開発プロセスガイド

ESPR：

開発プロセスガイド

開発管理力強化による信頼性向上

実装面での高信頼化

ESCR：

コーディング作法ガイド

ESCR：

コーディング作法ガイド

見える化

品質定量化コントロール

設計・実装技術強化による信頼性向上

ESQR：

品質作り込みガイド

ESQR：


9

ESQRESQRとはとは

Embedded System development Quality Reference

組込みシステム（ソフトウェア）開発過程で

客観的な品質指標を用いて

品質要素の作りこみとコントロールを行うために

体系的、整備された参照手法

•システムレベルの導出手法：システム・プロジェクトプロファイル、障害影響度診断等

•品質目標の評価手法、計測可能な指標およびシステムレベルに応じた参考値の提供

•定性的品質作り込みのためのヒント提供

10

ESQRESQR--５つの特徴５つの特徴

特徴1：

システム障害震度フィールドのシステム障害を評価し、品質目標に反映

特徴2：

システムプロファイル対象システムに求められる品質要求をカテゴライズ

特徴3：

プロジェクトプロファイル

開発プロジェクトや組織の特性を品質目標に反映

特徴4：

品質評価指標の定義と参考値ソフトウェアの品質を可視化し、品質目標を明確にする指標群を整備

特徴5：

作業チェック項目（ヒント）開発作業の質的な面の向上のためのヒントを提供



さて、ESQRの特徴のご紹介です。まず、5つの特徴をお話します。これ、キーポイントですから、頭の隅に置いてくださいね。まず、耳慣れない言葉と思いますが、ST-SEISMIC Scaleというものがあります。 ESQRでの造語です。 SEISMICとは地震の震度のことです。ST-SEISMIC Scaleはこれをソフトウェアというかシステムに当てはめてみて表にしたものです。これは、トラブルが発生した際の分析に使用します。自分たちの製品の不具合が世の中にどのような影響を及ぼしているか、と言うことを考え、震度に当てはめてみます。それをシステムプロファイルの分析に適用していきます。つぎに、システムプロファイルです。これはエンドユーザから求められる品質はどんなものか、ということを分析します。言い換えれば、どういうものを作るかを決める、ということです。例えば、リモコンは1回ボタンを押してうまく行かなかったらもう1回押せばまあ、よいですよね？不具合があったとしても気づかないかもしれない。でも、エンジンが時々止まる、なんていうのは許せないですよね？このように、製品によってユーザが求められる品質の程度、というものがあります。当たり前のことですが、それを皆さんご自分の製品でどうか、ということはなんとなくはわかっていらっしゃると思いますが、きちんと分析することを行います。その次は、プロジェクトプロファイルです。プロジェクトの制約条件と追い風になる条件を見極めるという作業です。例えば、数百行のサンプルプログラムと、数10万行のシステムでは、入り込むバグの量、すなわち取り去らなければならないバグの量が指数的に異なるのはみなさん、実感していらっしゃると思います。また、プロジェクトにベテランがいるかどうか、とか、プロジェクトマネージャの経験値はどうか、とかいうことで製品を作るときに気をつけなければいけない程度、というのが変ってきます。これらをプロジェクトプロファイルで分析します。その先にあるのが品質指標です。これは物を作るときの作業、プロセスとものそのもの、プロダクトのできが十分であるか、ということを測るための「ものさし」です。うまく行っているかどうかをきちんと見極めるためには測るという行為が必要なんですが、測るためには適切なものさしを用意しておく必要があります。ソフトウェアを測るためのものさし、をESQRでは提供します。最後にヒント集です。これは、開発作業やプロジェクトそのものの質が良いものであるかを見極めるためのチェック項目を挙げているものです。定量的には測れない、定性的な物事が多く書かれています。 �

11

おいしいりんごって？

誰が食べるのか？

自宅用

ご近所くらいには配る

出荷用

どのように、どのくらい作るのか？木の本数/畑の大きさ？

ひとりで/人を雇って

育てやすい品種？

どうやって育てるか？

肥料は、農薬は、

剪定は、水やりは

育ち具合は？

大きさ・色

味・傷み具合

システムプロファイル

プロジェクトプロファイル

プロセス品質評価指標

プロダクト品質評価指標

12

ESQRESQRによる品質定量コントロールループによる品質定量コントロールループ

Step 3.プロジェクトプロファイリングプロジェクトの特性を体系的に分析

Step 5.品質コントロール実プロジェクトで

品質定量指標を計測作業の質の評価

品質目標に近づけるようにコントロール

Stｅp 1.ST-SEISMIC Scaleの考え方実フィールドでのシステム障害を品質目標にフィードバック

Step2.システムプロファイリングシステムの特性を体系的に評価・把握

▲

▲

Step 4.品質目標設定プロセス品質評価指標/プロ

ダクト品質評価指標を用いて

品質目標値を設定

時間

品質

時間

品質



ST－SEISMIC、システムプロファイリング、プロジェクトプロファイリングを適用してシステム及びプロジェクトの分析を行い、�何をどのように造るかを可視化する。その分析結果を用いて品質目標の選択と目標値の設定を行う。品質目標値を使用して品質コントロールを行う。�その結果を用いて次製品の分析をより詳細に行う、�というようにフィードバックをかけながらコントロールループをまわしていく。�

13

STEP1. STEP1. STST--SEISMIC ScaleSEISMIC Scale

発生した不具合の影響度を分析、震度として評価→ システムプロファイルへ：次開発へのフィードバックを行う

事後安全計画へ事前安全計画へのインプット



まずは震度：自分たちのシステムがトラブルを起こした時にきちんと分析して、事後安全計画を立てることまた、システムプロファイルを行い、事前安全計画に生かすことその結果を使って定量目標を決め、コントロールを行うことさて、ST-SEISMIC Scaleの話を次に行いましょう。ST-SEISMIC Scaleは、ここにありますように、発生した不具合の影響度を分析、震度として評価し、システムプロファイル、次開発へのフィードバックを行うということです。不具合が出てしまった場合に、その不具合がユーザ及びシステムへ及ぼす影響を「殆ど気づかない」から「殆どのユーザに被害が出、社会的不安を引き起こす」まで、8段階に分類する方法を示しています。昨今、ソフトウェアの不具合を目にしない日はないという感じですが、その不具合は本当に社会に影響を及ぼしているのか、及ぼしているとしたらどのくらいなのか、と言うことをこの表を使って判断してみて下さい。また、自分たちのシステムでも不具合が出た場合にどれほどの影響度があったのかを判断し、システムプロファイルのときの判断目安に反映してみて下さい。 �

14

STEP2. STEP2. システムプロファイルシステムプロファイル

システム利用・運用時に発生する可能性のあるシステム障害を想定し、人的面及び、経済面への影響や被害額をもとに対象システムを4つのシステムタイプに分類

使う側の立場で分析

1万人のユーザがその製品を2日使えなくなる1日当たりの被害額が5千円として、

1万人× 5千円×2日＝1億円



Normal と Normal Quality Requiredの違い：販売台数とか、システム規模では、一つ一つ細かく説明していきます。システムプロファイルというのはここにありますように、システム利用・運用時に発生する可能性のあるシステム障害を想定し、人的面及び、経済面の影響額や被害額をもとに対象システムを4つのシステムタイプに分類する、ということです。そして、その分類にはこのようなフローチャートを用います。例えば、携帯電話。携帯電話のｼｽﾃﾑ不具合で直接人的被害、すなわち、亡くなったり大怪我したり、と言うことは考えにくいですね。したがって、このフローでは最初の分岐は下に落ちます。次に経済損失を考えます。この経済損失と言うのは、リコールなどの企業側での被害額損害額ではありません。システム、この場合は携帯電話を使う人が直接被る被害額を考えます。最近の携帯電話はファームをダウンロードなどしますから、何かあっても復旧は割りと楽です。携帯電話の普及数を考えても、延べの被害が10億円に達することはないでしょう。1万人のユーザがその携帯を2日使えなくなったとして、1日当たりの被害額が5千円、で、1億円になります。いかがでしょう、感覚とあっていますか？ということで、ある携帯１機種の場合のシステムタイプは２、すなわち、Normal Quality Requiredとなります。�

15

STEP3.STEP3.プロジェクトプロファイルプロジェクトプロファイル

システムの実装面や開発プロジェクトの特性などを考慮し、システムタイプに対する補正係数を算出

作る側の事情を加味



次に、プロジェクトのプロファイルを行います。プロジェクトプロファイルは、ここにありますように、システムの実装面や開発プロジェクトの特性などを考慮し、システムタイプに対する補正係数を算出することです。プロジェクトプロファイルでは10の項目のチェックシートを使用します。チェック項目はここにありますように、ソフトウェアの性質を問うもの、プロジェクトの構成等を問うものなどがあります。いずれも、開発を行う場合に障害となるものまたは追い風となる項目を示しています。これで、障害となりそうな項目はマイナス、追い風となりそうな項目はプラスのチェックを行います。これらチェックの値を元に、システムプロファイルで行ったシステムタイプに対して補正を行います。補正については、次の品質指標のところでお話します。�

16

STEP4. STEP4. 品質指標品質指標の設定の設定

プロセスとプロダクトの2つの観点で、品質を確保するための活動について品質指標および目標値を設定

要求分析定義

システム設計

ソフトウェア設計

実装(コーディング)

ソフトウェアテスト

システムテスト

プロセス品質評価指標：作業の十分性を評価

レビュー作業充当率

レビュー作業実施率

テスト作業充当率

テスト作業実施率

プロダクト品質評価指標：成果物の出来を評価

仕様書

設計書

コード

テスト仕様書成績書

ドキュメント

品質評価指標

コード

品質評価指標

テスト

品質評価指標

要求分析定義

システム設計

ソフトウェア設計

実装(コーディング)

ソフトウェアテスト

システムテスト

プロセス品質評価指標：作業の十分性を評価





プロダクト品質評価指標：成果物の出来を評価

仕様書

設計書

コード

テスト仕様書成績書

ドキュメント

品質評価指標

コード

品質評価指標

テスト

品質評価指標

ものさしと判断目安を決定



ものさし：単位とどこを測るか、を明確にしておくさて、いよいよ品質指標の設定です。品質指標の設定とはここにありますように、プロセスとプロダクトの2つの観点で品質を確保するための活動について品質指標および目標値を設定する、ことです。品質指標とは、品質コントロールを行っていくために計測する指標すなわち、ものさしのことです。目標値というのは判断目安です。たとえば、唐突ですが、りんごの大きさを測る時、まあ、目測が多いと思うのですが、そこそこ厳密に測ろうとした時はものさしやメジャーを使いますね。それも、１ｍｍくらいまで測れるもの。これが大玉ころがしの玉だったら、もう少し大きなものさしを用意します。このように、物事の大きさを測るにはそれに適したものさしを用意することが必要になります。ソフトウェアの品質を測るためにも、ものさしは必要です。それを品質指標と呼んでいます。次に、先ほどりんごの例を出しましたが、もいでよいかどうかを判断する目安として、色、というのもありますが、適当な大きさになっているか、と言うこともあると思います。りんごをもいでよいか、と判断するためにはある一定以上の直径になっているか、と言うことがあるでしょう。ソフトウェアも同じで、次の工程に行ってよいか、という判断を行うために、品質指標の目標値を定めておくのはとても有効なことです。�

17

品質指標：プロセス品質評価指標品質指標：プロセス品質評価指標

要求定義設計実装テスト

▲要求仕様書 ▲アーキテクチャ設計書・

詳細設計書▲ソースコード

▲テスト仕様書・

テスト報告書レビュー

テスト実施



プロセス品質評価指標⇒プロセス品質評価指標⇒品質確認作業（レビュー、テスト品質確認作業（レビュー、テスト

))の十分性を評価する指標の十分性を評価する指標



作業充当率

：

作業の相対的な工数の十分性を評価

（レビューまたはテスト作業工数／開発工数）

作業実施率

：

作業の質的な十分性を評価

（レビューまたはテスト作業工数／ソースコード全行数）



作業充当率：レビュー、テストの作業が開発の作業と「相対的」に十分かを見ます。つまり、「妥当な」割合を期待するので、極端に多くても少なくてもいけません。作業実施率：レビュー、テストの作業のボリュームに対する量を見ます。一定のボリュームに対してどのくらい工数をかけたかを見るので、多いほどよいということになります。ただし、多すぎるのは、レビュー効率がよくないとか、ものの質が悪すぎるとかの背景が考えられます。さて、品質指標のうち、まずはプロセス品質評価指標についてお話しましょう。プロセスというのは工程、ともいいます。物を作っていく過程のことですね。プロセス品質評価指標では、各プロセスにおける、品質を確認するための作業すなわち、レビューとテストが十分に行われているかどうかを評価します。プロセス品質評価指標はさらに、充当率と実施率の2つに分かれます。充当率は作業の量的な十分性を評価し、実施率は質的な十分性を評価します。(ここで、時間があれば上の説明)�

18

品質指標：プロダクト品質評価指標品質指標：プロダクト品質評価指標

要求定義設計実装テスト

▲要求仕様書 ▲アーキテクチャ設計書・

詳細設計書 ▲ソースコード

▲テスト仕様書・作成

▲テスト報告書

ドキュメント品質評価指標

コード品質評価指標

▲オブジェクトコード

テスト品質評価指標

ドキュメント品質評価指標

：

作業のインプット/アウトプットとなるドキュメントの

量とバランスを評価

コード品質評価指標

：

ソフトウェアの基となるソースコードを静的に量と特性を評価

テスト品質評価指標

：

ソフトウェア自身を動的評価するテストに対し、十分性と動作

完全性を評価

→中間成果物ならびに最終成果物の出来ばえを評価する指標→中間成果物ならびに最終成果物の出来ばえを評価する指標プロダクト品質評価指標プロダクト品質評価指標

仕様書の記述量は

十分か

制御文の記述

率は高くないか

不具合はちゃんと

直っているか



次に、品質指標のもうひとつ、プロダクト品質評価指標を説明します。プロダクト品質評価指標は、製品が出来上がっていく中で作られる生成物、すなわち中間成果物及び最終成果物のでき映えを評価する指標です。プロダクトには３つのカテゴリを用意しています。すなわち、ドキュメント、コード、テストの3つです。ドキュメントは各工程の作業のインプットおよびアウトプットとなります。それらの量的な十分性と、内容のバランスを見ます。コードは、ソースコード、すなわちソフトウェアを静的に評価する対象となります。コードがコントローラブルな量で記述されているか、ということと、制御文やコメントなどの特性を評価します。テストは、ソフトウェアそのものを動的に評価する行動です。それらを行うためのテスト項目の密度などの十分性及び、検出した不具合の修正度合いなどから、動作の完全性を評価します。�

19

STEP5.STEP5.

定量的なプロジェクトのコントロール定量的なプロジェクトのコントロール

品質・信頼性目標値

時間

対象製品対象プロジェクト

特性を考慮

適切な指標で状況を可視化

目標値達成に向けてコントロール品

質

20

品質コントロールの例品質コントロールの例((そのその11))

システム：計測器(無線通信波形計測、分析、信号発生)既存製品の高周波対応展開、ユーザはメーカ等の開発者

Step1. システムプロファイル

人的損失はない→Type3以下

修理に1週間かかる、各ユーザの使用頻度は低い(毎日使うものではない)損害額は1日2千円と見積もり

経済損失：被害日数(5日)×ユーザ数(3,000人)×影響率(0.２)×損害額(2,000円)

＝6,000,000円 → Type1：Nに決定

Step2. プロジェクトプロファイル

仕様は明確、他は突出した

特徴は無い(右表参照)→ 補正係数：-0.1

①ソフトウェア規模 □極めて小さい普通 □極めて大きい②ソフトウェアの複雑さ □極めて単純普通 □極めて複雑③システム制約条件の厳しさ □制約ゆるい普通 □制約厳しい④仕様の明確度合い極めて明確 □普通 □明確になっていない⑤再利用するソフトウェアの品質レベル□極めて高品質普通 □極めて品質低い⑥開発プロセスの整備度合い □整備できている普通 □整備できていない⑦開発組織の分業化・階層化の度合い□開発組織が単純普通 □開発組織が複雑⑧開発メンバーのスキル □メンバースキル高い普通 □メンバースキル低い⑨プロジェクトマネージャの経験とスキル□PMスキル高い普通 □PMスキル低い⑩システム障害時のメーカ側損失額 □極めて小さい普通 □極めて大きい小計 -1 0合計ポイント数 -1



(モデルはESMRから引用) では、例をちょっと見て見ましょう。この例は、ESMR：マネジメントガイドから持ってきたものです。オシロのような計測器の高級機版、と思ってください。改造開発ですね。まずシステムプロファイルです。人が亡くなったり、怪我したりすることはないです。ですのでまず、Type２以下ということがわかります。次に経済損失ですが、計算すると、高々600万円、1億円以下ですので、Type1にします。次に、プロジェクトプロファイルですが、可もなく不可もなく、と言うプロジェクトと言うことで、補正係数はー0.1ということにいたします。詳細を知りたい方は、後でじろじろこの表を見に来て下さい。 �

21

品質コントロールの例品質コントロールの例((そのその2)2)

Step3. 品質評価指標の選定と目標値の設定

品質評価目標の選択

レビュー作業充当率、設計書ボリューム率を仮に選択

計測すべき基礎指標の確認レビュー作業充当率＝全レビュー工数 / 開発全工数

設計書ボリューム率＝設計書ボリューム / ソースコード全行数

品質目標値の設定

レビュー作業充当率補正値の算出：補正ベース値：4.00 、補正係数： -0.1 ∴ 補正値＝4.00×(-0.1)＝ -0.4品質目標値の設定：レビュー作業充当率のType1:Nの参考値＝4.00 ∴ 4.00 - 0.4 = 3.6

設計書ボリューム率補正値の算出：補正ベース値：10.00、補正係数： -0.1 ∴ 補正値＝10.00×(-0.1)= -1.00品質目標値の設定：設計書ボリュームのType1:Nの参考値＝ 9.00 ∴ 9.00 – 1.00 = 8.00

参考(見積もり値)開発全工数(見積もり値)：20人×9ヶ月×155時間＝27,900人時

開発ソフトウェア：8万Lines



次に、品質評価指標の目標値の設定です。ここでは便宜的に、(時間もありませんので)レビュー作業充当率、ならびに設計書ボリューム率を仮に選択しました。前のページでシステムタイプは１：Normal、補正係数は-0.1が出ていましたので、それと表の参考値を見ながら算出します（それぞれ、スライドイン・アウト) これで、レビュー作業充当率は３．６、設計書ボリューム率は８．０ということになりました。 (参考) レビュー作業充当率の開発全工数から逆算した理想の全レビュー工数：(3.6/100)*27900=1004.4 設計書ボリュームの開発ソフト行数から逆算した理想の設計書ボリューム：8*80=640 �

22

品質コントロールの例品質コントロールの例((そのその3)3)

Step4. 実際の開発フェーズでの指標値の測定と評価

レビュー作業充当率の評価の例開発全工数の見積もり値： 27,900人時

『結合テスト開始時点』(＝テスト関連のみ見積もり値、他は実績値)での

全レビュー工数見積もり値：900人時

レビュー作業充当率＝全レビュー工数 / 開発全工数

＝ 900 / 27,900 ＝ 0.032 ＝ 3.2 (%)目標値 3.6(%)に対して、若干少ないこれまでのレビューを再度見直す、テストを厚くするなどの対応を行う

設計書ボリューム率の評価の例ソースコード全行数の見積もり値： 80KLOC『設計書レビュー開始時点』(＝ソースコードはまだ存在しないため、

全て見積もり値)での設計書ページ数：500ページ

設計書ボリューム率＝設計書ボリューム / ソースコード全行数

＝ 500 / 80 ＝ 6.25目標値 8.00に対して、少ない

設計書にもれ抜けがある可能性が高いことに気をつけ、レビューを実施する



つぎに今までに決定した目標値を使った品質コントロールの例を見ていきましょう、結合テスト開示時点でのレビュー作業充当率の見積もりを取った場合に、3.2という値を得たとします。これは目標値３．６に対して少ないですね。なので、テストを始める前にこれまでのレビューにもれはないか、手は抜いていないかなどを見直す、または危なそうなのでテストを追加する、などの措置をとるきっかけとすることができます。もう一つ、設計書ボリュームですが、設計書の仮バージョンができた段階で、６．２５と言う値が得られたとします。これは目標値8,00に対して少ないわけです。もれぬけはないか、レビューする段階で特に気をつけるという判断を行うことができます。このようにして、品質指標及び目標値を使用して、品質コントロールを行っていくわけです。 (参考) レビュー作業充当率の開発全工数から逆算した全レビュー工数：2120.4�

23

高品質作り込みのためのヒント高品質作り込みのためのヒント

1. コミュニケーションと意思決定

2. ドキュメント

3. レビュー

4. テスト

5. 指標を用いた

品質作り込み活動

定量的コントロールだけでなく、品質作り込みを行うための定性的なコントロールのヒントを提供



さいごに、ESQRの手法ではないですが、ヒント集をご紹介します。品質作りこみを行っていくためには、今まで説明してきました、ESQRの定量コントロールだけでは達成できません。その前に、品質を作りこむこと、すなわちバグを埋め込まない、埋め込んだ場合には速やかに取り去る、といった人間的な活動が必要です。そのために、4つの側面コミュニケーション、ドキュメント、レビュー、テストを行う上でのヒント、およびこの本を読むためのヒントと言う形でそれぞれ12個ずつ、まとめてあります。例えば、これはコミュニケーションに関するチェック項目ですが、なかなかいろんなことが書いてあります。これらを職場に持ち帰って～あまり真剣にやると、きっと反感買いますから、軽い感じで～ちょっと眺めていただいても良いかと思います。�

24

システムプロファイリングプロジェクトプロファイリング

ESQRESQR：品質作り込みガイド：品質作り込みガイド

目次構成目次構成

1章

品質作り込みガイドの読み方1.1 品質作り込みガイドの目的と位置づけ1.2 品質指標に基づく組込みシステム開発1.3 本ガイドの想定利用者・利用方法と得られる効果1.4 品質作り込みガイドの構成1.5 本ガイドの利用に関する注意事項1.6 関連規格

2章

システムプロファイリングを利用した品質目標値の設定2.1 組込みシステムの特性を考えた品質目標設定の考え方2.2 Step -

1：システムプロファイリング2.3 Step -

2：プロジェクトプロファイリング2.4 Step -

3：品質目標値の設定2.5 プロファイリングの事例2.6 システム障害の評価とシステムプロファイリングへの反映

3章

品質指標の定義と参考値3.1 品質指標の定義と意味、利用法3.2 品質指標のカテゴライズ3.3 品質指標

－

利用上の注意3.4 プロセス品質評価指標

－

定義と参考値3.5 プロダクト品質評価指標

－

定義と参考値3.6 基礎指標

－

定義と参考値

4章

高品質作り込みのためのヒント4.1 開発におけるコミュニケーションと意思決定4.2 ドキュメント4.3 レビュー4.4 テスト4.5 指標を用いた品質作り込み活動

ガイドの読み方

品質指標・目標値の設定

品質向上のためのヒント



さて、長く話してきましたが、ESQR、この本の構成はこのようになっています。説明(軽く�

25

想定する利用者想定する利用者

実際の工程管理や品質管理を検討・決定するマネージャやリーダ実際の工程管理や品質管理を検討・決定するマネージャやリーダ

開発プロセスの標準や品質に関する基本的な考え方を整備運用するメンバ開発プロセスの標準や品質に関する基本的な考え方を整備運用するメンバ

品質保証など、ソフトウェア開発を間接的に支える支援グループのメンバ品質保証など、ソフトウェア開発を間接的に支える支援グループのメンバ



想定する利用者はこのような人たちです・開発プロジェクトや開発組織などをマネジメントし、個々の開発案件において実際の工程管理や品質管理を検討・決定するマネージャやリーダ・組込みソフトウェアを開発する組織において、組織や部門の開発プロセスの標準や品質に関する基本的な考え方を整備し、その運用を支援するメンバ・組込みソフトウェアを開発する組織において、品質保証など、ソフトウェア開発を間接的に支える支援グループのメンバもちろん、品質のコントロールをする組織においては開発に＋αの工数が発生しますので、経営者層の理解・支援やバックアップが必要であることは言うまでもありません �

26

得られる効果得られる効果

利用者側から見たシステムの適切な品質レベルを分析考察できる利用者側から見たシステムの適切な品質レベルを分析考察できる→品質確保のための作業の見直しを行うことができる→品質確保のための作業の見直しを行うことができる

プロジェクトの特性を客観的に捉えられるプロジェクトの特性を客観的に捉えられる→品質目標の設定に反映→品質目標の設定に反映

目標値を設定して開発をすすめる目標値を設定して開発をすすめる→品質を実現するための必要十分な作業を行うことができる→品質を実現するための必要十分な作業を行うことができる



一番目がstep1:システムプロファイルの効果、二番目がstep2:プロジェクトプロファイルの効果、三番目がstep3:品質目標の選択と品質目標値の設定の効果となります得られる効果としては、品質コントロールを行えるようになる、はもちろんですが、これに＋αして、このようなことがあります。・利用者側から見たシステムの適切な品質レベルを分析考察でき、品質確保のために必要な作業/不必要な作業の見直しを行うことができる・プロジェクトの特性が品質面にどのような効果があるかを客観的に考える機会が得られ、品質目標の設定に反映できる・目標値を設定して開発をすすめることで求める品質を実現するために必要十分な作業を行うことができるようになる �

27

ESQRESQRを利用する場合の注意点を利用する場合の注意点

ESQRESQRで提示した品質指標を全て利用する必要はないで提示した品質指標を全て利用する必要はない

⇒信頼性を抑えるための指標は決まっていますか？⇒信頼性を抑えるための指標は決まっていますか？

参考値をそのまま利用しない参考値をそのまま利用しない⇒⇒

自部門の実力やシステム特性などを考慮して自部門の実力やシステム特性などを考慮して個別に事前検討し目標値を定める個別に事前検討し目標値を定める

数値に振り回されない数値に振り回されない⇒⇒

数値を達成することが目標ではなく、数値を達成することが目標ではなく、結果にいたる結果にいたるまでのコントロールがまでのコントロールが重要重要

⇒⇒

定性的な側面や内容も合わせて考える定性的な側面や内容も合わせて考える

実際のデータで議論しましょう実際のデータで議論しましょう⇒⇒

うまいやり方があればフィードバックをお願いしますうまいやり方があればフィードバックをお願いします

28

フィードバックのお願いフィードバックのお願い

ESQRはアンケートやヒアリングを行って各社さんからの情報を基にまとめたものです。これからもデータの精査を重ねていきます。是非、SECへのフィードバックをお願いします



指標をきちんと決めたとしても、実際のデータで議論しないと先に進めないうまいやり方があればフィードバックかけてほしい規格に踊らされて本質見失っちゃだめ、中身の工夫、議論をするべき巻末、また出版社である翔泳社のWebサイトにこのフォームおよび送付方法が掲載してありますいかがでしたでしょうか。こんなもんかなー、と言う感じはお分かりいただけましたか？ ESQRは今日のセミナも、本も、まだ歩き始めたばかりです。品質目標、参考値など、皆さんのデータのフィードバックを行っていきたいと考えています。本の巻末と、お問い合わせのWebサイトに、このようなフォームを掲載しています。ESQRは皆さんから提供されるデータを元に、改善を考えていきます。ぜひ、ご協力ください�

29

ご清聴ありがとうございましたご清聴ありがとうございました

ISBN978-4-7981-1884-0

組込みソフトウェア開発向け


翔泳社

©2008 IPA



何でクリティカルといわれているソフトウェアなのに技術に関するブレークスルーがないのか外側の円を議論してもだめ、内側の議論をすべき →ESQR等を整えている信頼性を抑えるための指標は決まっていますか？結果を見るのみならず、結果にいたるまでのコントロールが必要指標をきちんと決めたとしても、実際のデータで議論しないと先に進めない各論よりもどこをどう押さえてどう進めていくかが重要まずは震度：自分たちのシステムがトラブルを起こした時にきちんと分析して、事後安全計画を立てることまた、システムプロファイルを行い、事前安全計画に生かすことその結果を使って定量目標を決め、コントロールを行うことうまいやり方があればフィードバックかけてほしい規格に踊らされて本質見失っちゃだめ、中身の工夫、議論をするべき �

【12-E-2】　SEC流品質作りこみESQR...

Documents

Transcript of 【12-E-2】　SEC流品質作りこみESQR...

【12-E-2】 SEC流品質作りこみESQR...

Documents

Transcript of 【12-E-2】 SEC流品質作りこみESQR...

【12-E-2】　SEC流品質作りこみESQR...

Transcript of 【12-E-2】　SEC流品質作りこみESQR...