【12-E-2】　SEC流品質作りこみESQR 組込みソフトウェア開発向け品質作り込みガイドの紹介

SEC流品質作りこみESQR 組込みソフトウェア開発向け品質作り込みガイドのご紹介 12-E-2 山崎太郎 (独)情報処理推進機構(IPA) ソフトウェア・エンジニアリング・センター(SEC) 研究員

おいしいりんごの育て方日当たり •“虫”が入らないようにする農薬 •おいしく育てる肥料育てる過程の工夫が必要 •育て方が適切か •できた果実が消費者の好みに合っているか計測し評価し改善する 2

おいしいりんごって？育ち具合は？誰が食べるのか？大きさ自宅用色ご近所くらいには配る味出荷用傷み具合どのように作るのか？庭の木一本だけ/裏の畑/広いりんご畑ひとりで/人を雇って育てやすい品種？どうやって育てるか？肥料は何を、どのくらい水やりは何回、どのくらい農薬は何を、どのくらい摘果はいつ、どのくらい 3

品質評価指標を用いた品質目標設定指標：・有形、無形にかかわらず対象（物、作業、サービスなど）の特質を表現するための科学的な根拠をもったものさし・指標の計測方法も合わせて定義し、誰が計測しても同じように値を計測できることものさし・測り方・精度・単位指標の精度：計ろうとしている対象の特性を表現し得る適切な精度を意識して計ること指標の単位：指標値を表現するための単位系は指標定義と合わせて、明確に一つに決めておくこと 4

製品出荷後の不具合：原因別ソフトウェアの不具合は依然としてトップ →ソフトウェアの不具合がシステムの品質に直結製品出荷後の不具合：原因別製品企画・仕様の不具合ソフトウェアの不具合ハードウェアの不具合製造上の不具合運用・保守の不具合その他の不具合 0.0% 20.0% 40.0% 60.0% 80.0% 2008年版組込みソフトウェア産業実態調査プロジェクト責任者 Q6-1-2 5

製品に不具合を入れないためには開発時にバグを入れないバグを見つけるためには？どうしてもバグは入り込むレビューとテストではどうしたら？テスト、していますよね？入ったバグを見つけて取り去ればよいでは、レビューは？ 6

工程別レビュー実施の実態どの工程でもレビューを部分的ながらも実施している企業も多いが、「レビューを実施していない」も20％を超えている工程別レビュー実施状況企画・調査・要求獲得システム要求定義完全に実施システムアーキテクチャ設計部分的に実施ソフトウェア要求定義実施していないソフトウェア実装および単体テストソフトウェア結合・総合テストシステム結合・総合テスト 0% 20% 40% 60% 80% 100% 2008年版組込みソフトウェア産業実態調査プロジェクト責任者 Q7-7 7

組込みシステムの品質・信頼性向上開発管理力強化による信頼性向上プロセス設計 ESMR：高信頼に求められる ESMR：プロセスの設計と実装マネジメントガイドマネジメントガイド計画的マネジメント ESPR： ESPR：要求・設計の高信頼化開発プロセスガイド開発プロセスガイド高信頼性に着目したレビュー・テストプロセス強化ソフトウェア設計の考え方 SAP：安全関連プロセス ESQR： ESCR： ESQR： ESCR：設計・実装技術強化に品質作り込みガイドコーディング作法ガイド品質作り込みガイドコーディング作法ガイドよる信頼性向上品質定量化実装面での高信頼化コントロール見える化定型化コントロール 8

ESQRとは Embedded System development Quality Reference 組込みシステム（ソフトウェア）開発過程で客観的な品質指標を用いて品質要素の作りこみとコントロールを行うために体系的、整備された参照手法 •システムレベルの導出手法：システム・プロジェクトプロファイル、障害影響度診断等 •品質目標の評価手法、計測可能な指標およびシステムレベルに応じた参考値の提供 •定性的品質作り込みのためのヒント提供 9

ESQR-５つの特徴特徴1：システム障害震度フィールドのシステム障害を評価し、品質目標に反映特徴2：システムプロファイル対象システムに求められる品質要求をカテゴライズ特徴3：プロジェクトプロファイル開発プロジェクトや組織の特性を品質目標に反映特徴4：品質評価指標の定義と参考値ソフトウェアの品質を可視化し、品質目標を明確にする指標群を整備特徴5：作業チェック項目（ヒント）開発作業の質的な面の向上のためのヒントを提供 10

おいしいりんごって？誰が食べるのか？自宅用システムプロファイルご近所くらいには配る出荷用どのように、どのくらい作るのか？木の本数/畑の大きさ？プロジェクトプロファイルひとりで/人を雇って育てやすい品種？どうやって育てるか？肥料は、農薬は、プロセス品質評価指標剪定は、水やりは育ち具合は？大きさ・色プロダクト品質評価指標味・傷み具合 11

ESQRによる品質定量コントロールループ ▲ Step2. Step 3. システムプロファイリングプロジェクトプロファイリングシステムの特性を体系的にプロジェクトの特性を体系的に分析評価・把握 Stｅp 1. ST-SEISMIC Scale Step 4. の考え方品質目標設定実フィールドでのシステム障害をプロセス品質評価指標/プロ品質目標にフィードバックダクト品質評価指標を用いて品質目標値を設定 Step 5. ▲ 品質コントロール品質実プロジェクトで品質定量指標を計測作業の質の評価品質目標に近づけるようにコントロール時間 12

STEP1. ST-SEISMIC Scale 発生した不具合の影響度を分析、震度として評価 → システムプロファイルへ：次開発へのフィードバックを行う事後安全計画へ事前安全計画へのインプット 13

STEP2. システムプロファイルシステム利用・運用時に発生する可能性のあるシステム障害を想定し、人的面及び、経済面への影響や被害額をもとに対象システムを4つのシステムタイプに分類使う側の立場で分析 1万人のユーザがその製品を2日使えなくなる 1日当たりの被害額が5千円として、 1万人× 5千円×2日＝1億円 14

STEP3.プロジェクトプロファイルシステムの実装面や開発プロジェクトの特性などを考慮し、システムタイプに対する補正係数を算出作る側の事情を加味 15

STEP4. 品質指標の設定プロセスとプロダクトの2つの観点で、品質を確保するための活動について品質指標および目標値を設定ものさしと判断目安を決定プロセス品質評価指標：プロダクト品質評価指標：作業の十分性を評価成果物の出来を評価要求分析定義仕様書ドキュメントレビュー作業充当率システム設計品質評価指標設計書ソフトウェア設計レビュー作業実施率コード実装(コーディング) コード品質評価指標テスト作業充当率ソフトウェアテストテストテスト仕様書成績書品質評価指標システムテストテスト作業実施率 16

品質指標：プロセス品質評価指標プロセス品質評価指標⇒品質確認作業（レビュー、テスト )の十分性を評価する指標要求定義設計実装テスト ▲アーキテクチャ設計書・ ▲要求仕様書詳細設計書 ▲ソースコードレビュー作業充当率レビュー作業実施率 ▲テスト仕様書・レビューテスト報告書テスト作業充当率テスト実施テスト作業実施率作業充当率：作業の相対的な工数の十分性を評価（レビューまたはテスト作業工数／開発工数）作業実施率：作業の質的な十分性を評価（レビューまたはテスト作業工数／ソースコード全行数） 17

品質指標：プロダクト品質評価指標プロダクト品質評価指標 →中間成果物ならびに最終成果物の出来ばえを評価する指標要求定義設計実装テスト ▲アーキテクチャ設計書・ ▲要求仕様書 ▲ソースコード詳細設計書 ▲オブジェクトコードドキュメント品質評価指標 ▲テスト仕様書・作成コード品質評価指標 ▲テスト報告書テスト品質評価指標仕様書の記述量は十分か制御文の記述ドキュメント品質評価指標：作業のインプット/アウトプットとなるドキュメントの率は高くないか量とバランスを評価コード品質評価指標：ソフトウェアの基となるソースコードを静的に量と特性を評価テスト品質評価指標：ソフトウェア自身を動的評価するテストに対し、十分性と動作完全性を評価不具合はちゃんと直っているか 18

STEP5. 定量的なプロジェクトのコントロール適切な指標で状況を可視化対象製品対象プロジェクト目標値達成に向けて特性をコントロール考慮品質品質・信頼性目標値時間 19

品質コントロールの例(その1) システム：計測器(無線通信波形計測、分析、信号発生) 既存製品の高周波対応展開、ユーザはメーカ等の開発者 Step1. システムプロファイル人的損失はない→Type3以下修理に1週間かかる、各ユーザの使用頻度は低い(毎日使うものではない) 損害額は1日2千円と見積もり経済損失：被害日数(5日)×ユーザ数(3,000人)×影響率(0.２)×損害額(2,000円) ＝6,000,000円 → Type1：Nに決定 ① ソフトウェア規模 □ 極めて小さい普通 □ 極めて大きい ② ソフトウェアの複雑さ □ 極めて単純普通 □ 極めて複雑 Step2. プロジェクトプロファイル ③ システム制約条件の厳しさ □ 制約ゆるい普通 □ 制約厳しい ④ 仕様の明確度合い極めて明確 □ 普通 □ 明確になっていない仕様は明確、他は突出した ⑤ 再利用するソフトウェアの品質レベル□ 極めて高品質普通 □ 極めて品質低い ⑥ 開発プロセスの整備度合い □ 整備できている普通 □ 整備できていない ⑦ 開発組織の分業化・階層化の度合い □ 開発組織が単純普通 □ 開発組織が複雑特徴は無い(右表参照) ⑧ 開発メンバーのスキル □ メンバースキル高い普通 □ メンバースキル低い ⑨ プロジェクトマネージャの経験とスキル PMスキル高い □ 普通 □ PMスキル低い → 補正係数：-0.1 ⑩ システム障害時のメーカ側損失額 □ 極めて小さい普通 □ 極めて大きい小計 -1 0 合計ポイント数 -1 20

品質コントロールの例(その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 21

品質コントロールの例(その3) Step4. 実際の開発フェーズでの指標値の測定と評価レビュー作業充当率の評価の例開発全工数の見積もり値： 27,900人時『結合テスト開始時点』(＝テスト関連のみ見積もり値、他は実績値)での全レビュー工数見積もり値：900人時レビュー作業充当率＝全レビュー工数 / 開発全工数＝ 900 / 27,900 ＝ 0.032 ＝ 3.2 (%) 目標値 3.6(%)に対して、若干少ないこれまでのレビューを再度見直す、テストを厚くするなどの対応を行う設計書ボリューム率の評価の例ソースコード全行数の見積もり値： 80KLOC 『設計書レビュー開始時点』(＝ソースコードはまだ存在しないため、全て見積もり値)での設計書ページ数：500ページ設計書ボリューム率＝設計書ボリューム / ソースコード全行数＝ 500 / 80 ＝ 6.25 目標値 8.00に対して、少ない設計書にもれ抜けがある可能性が高いことに気をつけ、レビューを実施する 22

高品質作り込みのためのヒント定量的コントロールだけでなく、品質作り込みを行うための定性的なコントロールのヒントを提供コミュニケーションと意思決定 1. ドキュメント 2. レビュー 3. テスト 4. 指標を用いた 5. 品質作り込み活動 23

ESQR：品質作り込みガイド目次構成 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 指標を用いた品質作り込み活動品質向上のためのヒント 24

想定する利用者実際の工程管理や品質管理を検討・決定するマネージャやリーダ開発プロセスの標準や品質に関する基本的な考え方を整備運用するメンバ品質保証など、ソフトウェア開発を間接的に支える支援グループのメンバ 25

得られる効果利用者側から見たシステムの適切な品質レベルを分析考察できる →品質確保のための作業の見直しを行うことができるプロジェクトの特性を客観的に捉えられる →品質目標の設定に反映目標値を設定して開発をすすめる →品質を実現するための必要十分な作業を行うことができる 26

ESQRを利用する場合の注意点 ESQRで提示した品質指標を全て利用する必要はない ⇒信頼性を抑えるための指標は決まっていますか？参考値をそのまま利用しない ⇒ 自部門の実力やシステム特性などを考慮して個別に事前検討し目標値を定める数値に振り回されない ⇒ 数値を達成することが目標ではなく、結果にいたるまでのコントロールが重要 ⇒ 定性的な側面や内容も合わせて考える実際のデータで議論しましょう ⇒ うまいやり方があればフィードバックをお願いします 27

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

【12-E-2】　SEC流品質作りこみESQR 組込みソフトウェア開発向け品質作り込みガイドの紹介

0 comments

Notes on slide 1

1 Event