SlideShare a Scribd company logo
1 of 29
Download to read offline
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-5つの特徴

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

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

特徴3: プロジェクトプロファイル
     開発プロジェクトや組織の特性を品質目標に反映

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


特徴5: 作業チェック項目(ヒント)
     開発作業の質的な面の向上のためのヒントを提供

                                 10
おいしいりんごって?

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


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


                                   ▲
          Step2.                            Step 3.
          システムプロファイリング                      プロジェクトプロファイリング
          システムの特性を体系的に                      プロジェクトの特性を体系的に分析
          評価・把握




Step 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)×損害額(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
ご清聴ありがとうございました




         ISBN978-4-7981-1884-0
         組込みソフトウェア開発向け
         品質作り込みガイド
         翔泳社 ©2008 IPA


                                 29

More Related Content

What's hot

enNetforum Fukuoka Panelist
enNetforum Fukuoka PanelistenNetforum Fukuoka Panelist
enNetforum Fukuoka PanelistForum
 
enNetforum Wakamatsu Presentation
enNetforum Wakamatsu PresentationenNetforum Wakamatsu Presentation
enNetforum Wakamatsu PresentationForum
 
プログラマのためのテスト1
プログラマのためのテスト1プログラマのためのテスト1
プログラマのためのテスト1Kuniaki Igarashi
 
Jaws2008 Presen12
Jaws2008 Presen12Jaws2008 Presen12
Jaws2008 Presen12umekoumeda
 
0423mitsubishi
0423mitsubishi0423mitsubishi
0423mitsubishiloftwork
 
Copyright and Creative Commons
Copyright and Creative CommonsCopyright and Creative Commons
Copyright and Creative CommonsJun Nogata
 
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収Hiroshi Tokumaru
 
2009年4月8日セミナー 4.レコメンデーション Q&A
2009年4月8日セミナー 4.レコメンデーション Q&A2009年4月8日セミナー 4.レコメンデーション Q&A
2009年4月8日セミナー 4.レコメンデーション Q&APreferred Networks
 
2009年4月8日セミナー 2.Sedue新機能
2009年4月8日セミナー 2.Sedue新機能2009年4月8日セミナー 2.Sedue新機能
2009年4月8日セミナー 2.Sedue新機能Preferred Networks
 
2009年4月8日セミナー 3.SSD向け全文検索エンジン
2009年4月8日セミナー 3.SSD向け全文検索エンジン2009年4月8日セミナー 3.SSD向け全文検索エンジン
2009年4月8日セミナー 3.SSD向け全文検索エンジンPreferred Networks
 
変異型コロナウイルスが爆発的感染拡大を生む(続編ver2)
変異型コロナウイルスが爆発的感染拡大を生む(続編ver2)変異型コロナウイルスが爆発的感染拡大を生む(続編ver2)
変異型コロナウイルスが爆発的感染拡大を生む(続編ver2)Yuichi Iino
 
変異型コロナウイルスが爆発的感染拡大を生む(改訂版)
変異型コロナウイルスが爆発的感染拡大を生む(改訂版)変異型コロナウイルスが爆発的感染拡大を生む(改訂版)
変異型コロナウイルスが爆発的感染拡大を生む(改訂版)Yuichi Iino
 

What's hot (17)

enNetforum Fukuoka Panelist
enNetforum Fukuoka PanelistenNetforum Fukuoka Panelist
enNetforum Fukuoka Panelist
 
enNetforum Wakamatsu Presentation
enNetforum Wakamatsu PresentationenNetforum Wakamatsu Presentation
enNetforum Wakamatsu Presentation
 
rrds08
rrds08rrds08
rrds08
 
プログラマのためのテスト1
プログラマのためのテスト1プログラマのためのテスト1
プログラマのためのテスト1
 
Jaws2008 Presen12
Jaws2008 Presen12Jaws2008 Presen12
Jaws2008 Presen12
 
0423mitsubishi
0423mitsubishi0423mitsubishi
0423mitsubishi
 
Copyright and Creative Commons
Copyright and Creative CommonsCopyright and Creative Commons
Copyright and Creative Commons
 
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
 
SIG-SWO-A801-04
SIG-SWO-A801-04SIG-SWO-A801-04
SIG-SWO-A801-04
 
Okayama_1
Okayama_1Okayama_1
Okayama_1
 
2009年4月8日セミナー 4.レコメンデーション Q&A
2009年4月8日セミナー 4.レコメンデーション Q&A2009年4月8日セミナー 4.レコメンデーション Q&A
2009年4月8日セミナー 4.レコメンデーション Q&A
 
3
33
3
 
マニュアル
マニュアルマニュアル
マニュアル
 
2009年4月8日セミナー 2.Sedue新機能
2009年4月8日セミナー 2.Sedue新機能2009年4月8日セミナー 2.Sedue新機能
2009年4月8日セミナー 2.Sedue新機能
 
2009年4月8日セミナー 3.SSD向け全文検索エンジン
2009年4月8日セミナー 3.SSD向け全文検索エンジン2009年4月8日セミナー 3.SSD向け全文検索エンジン
2009年4月8日セミナー 3.SSD向け全文検索エンジン
 
変異型コロナウイルスが爆発的感染拡大を生む(続編ver2)
変異型コロナウイルスが爆発的感染拡大を生む(続編ver2)変異型コロナウイルスが爆発的感染拡大を生む(続編ver2)
変異型コロナウイルスが爆発的感染拡大を生む(続編ver2)
 
変異型コロナウイルスが爆発的感染拡大を生む(改訂版)
変異型コロナウイルスが爆発的感染拡大を生む(改訂版)変異型コロナウイルスが爆発的感染拡大を生む(改訂版)
変異型コロナウイルスが爆発的感染拡大を生む(改訂版)
 

More from devsumi2009

【12-E-4】 『脱Excel』を実現!統合プロジェクト管理パッケージ『SI Object Browser PM』を利用してIT企業も近代化しよう~PM...
【12-E-4】 『脱Excel』を実現!統合プロジェクト管理パッケージ『SI Object Browser PM』を利用してIT企業も近代化しよう~PM...【12-E-4】 『脱Excel』を実現!統合プロジェクト管理パッケージ『SI Object Browser PM』を利用してIT企業も近代化しよう~PM...
【12-E-4】 『脱Excel』を実現!統合プロジェクト管理パッケージ『SI Object Browser PM』を利用してIT企業も近代化しよう~PM...devsumi2009
 
【12-B-1】 実例で学ぶ Objective-C 2.0 と GUI の関係~ iPhone アプリ開発を視野に入れて
【12-B-1】 実例で学ぶ Objective-C 2.0 と GUI の関係~ iPhone アプリ開発を視野に入れて【12-B-1】 実例で学ぶ Objective-C 2.0 と GUI の関係~ iPhone アプリ開発を視野に入れて
【12-B-1】 実例で学ぶ Objective-C 2.0 と GUI の関係~ iPhone アプリ開発を視野に入れてdevsumi2009
 
【13-C-3】 RIA 開発をとりまく技術の進化と環境の変化
【13-C-3】 RIA 開発をとりまく技術の進化と環境の変化【13-C-3】 RIA 開発をとりまく技術の進化と環境の変化
【13-C-3】 RIA 開発をとりまく技術の進化と環境の変化devsumi2009
 
【13-C-5】 パネルディスカッション 帳票開発の肝
【13-C-5】 パネルディスカッション 帳票開発の肝【13-C-5】 パネルディスカッション 帳票開発の肝
【13-C-5】 パネルディスカッション 帳票開発の肝devsumi2009
 
【13-B-3】 企業システムをマッシュアップ型に変えるには
【13-B-3】 企業システムをマッシュアップ型に変えるには【13-B-3】 企業システムをマッシュアップ型に変えるには
【13-B-3】 企業システムをマッシュアップ型に変えるにはdevsumi2009
 
【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~
【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~
【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~devsumi2009
 
【13-D-3】 プロとしてのOracleアーキテクチャ入門 ~ 番外編 ~
【13-D-3】 プロとしてのOracleアーキテクチャ入門 ~ 番外編 ~【13-D-3】 プロとしてのOracleアーキテクチャ入門 ~ 番外編 ~
【13-D-3】 プロとしてのOracleアーキテクチャ入門 ~ 番外編 ~devsumi2009
 
【13-B-4】 Java VMへの処方箋 ~先進のメモリ管理技術とは~
【13-B-4】 Java VMへの処方箋 ~先進のメモリ管理技術とは~【13-B-4】 Java VMへの処方箋 ~先進のメモリ管理技術とは~
【13-B-4】 Java VMへの処方箋 ~先進のメモリ管理技術とは~devsumi2009
 
【13-B-2】 パネルディスカッション:クラウド時代のプログラミングスタイルを語り合おう
【13-B-2】 パネルディスカッション:クラウド時代のプログラミングスタイルを語り合おう【13-B-2】 パネルディスカッション:クラウド時代のプログラミングスタイルを語り合おう
【13-B-2】 パネルディスカッション:クラウド時代のプログラミングスタイルを語り合おうdevsumi2009
 
【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~
【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~
【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~devsumi2009
 
【13-E-1】 システムの見える化~エンドユーザーの立場から
【13-E-1】 システムの見える化~エンドユーザーの立場から【13-E-1】 システムの見える化~エンドユーザーの立場から
【13-E-1】 システムの見える化~エンドユーザーの立場からdevsumi2009
 
【13-E-1】 システムの見える化~エンドユーザーの立場から
【13-E-1】 システムの見える化~エンドユーザーの立場から【13-E-1】 システムの見える化~エンドユーザーの立場から
【13-E-1】 システムの見える化~エンドユーザーの立場からdevsumi2009
 
【13-E-1】 システムの見える化~エンドユーザーの立場から
【13-E-1】 システムの見える化~エンドユーザーの立場から【13-E-1】 システムの見える化~エンドユーザーの立場から
【13-E-1】 システムの見える化~エンドユーザーの立場からdevsumi2009
 
【13-D-4】 アナタのアプリ性能改善の秘訣、オラクルが教えます!
【13-D-4】 アナタのアプリ性能改善の秘訣、オラクルが教えます!【13-D-4】 アナタのアプリ性能改善の秘訣、オラクルが教えます!
【13-D-4】 アナタのアプリ性能改善の秘訣、オラクルが教えます!devsumi2009
 
【13-D-1】 ERP5に見るストレージ技術
【13-D-1】 ERP5に見るストレージ技術【13-D-1】 ERP5に見るストレージ技術
【13-D-1】 ERP5に見るストレージ技術devsumi2009
 
【12-B-4】 並列処理開発を支援するコンパイラの機能
【12-B-4】 並列処理開発を支援するコンパイラの機能【12-B-4】 並列処理開発を支援するコンパイラの機能
【12-B-4】 並列処理開発を支援するコンパイラの機能devsumi2009
 
【12-D-2】 WPF アプリケーション開発
【12-D-2】 WPF アプリケーション開発【12-D-2】 WPF アプリケーション開発
【12-D-2】 WPF アプリケーション開発devsumi2009
 
【12-D-3】 ASP.NET MVC - 概要と仕組み
【12-D-3】 ASP.NET MVC - 概要と仕組み【12-D-3】 ASP.NET MVC - 概要と仕組み
【12-D-3】 ASP.NET MVC - 概要と仕組みdevsumi2009
 
【12-A-2】 ケーススタディ:不景気と戦うシステムインテグレート
【12-A-2】 ケーススタディ:不景気と戦うシステムインテグレート【12-A-2】 ケーススタディ:不景気と戦うシステムインテグレート
【12-A-2】 ケーススタディ:不景気と戦うシステムインテグレートdevsumi2009
 
【13-C-4】 「もう業務はとまらない!オフライン機能を使った業務アプリケーションの実例と最新 Curl 情報」
【13-C-4】 「もう業務はとまらない!オフライン機能を使った業務アプリケーションの実例と最新 Curl 情報」【13-C-4】 「もう業務はとまらない!オフライン機能を使った業務アプリケーションの実例と最新 Curl 情報」
【13-C-4】 「もう業務はとまらない!オフライン機能を使った業務アプリケーションの実例と最新 Curl 情報」devsumi2009
 

More from devsumi2009 (20)

【12-E-4】 『脱Excel』を実現!統合プロジェクト管理パッケージ『SI Object Browser PM』を利用してIT企業も近代化しよう~PM...
【12-E-4】 『脱Excel』を実現!統合プロジェクト管理パッケージ『SI Object Browser PM』を利用してIT企業も近代化しよう~PM...【12-E-4】 『脱Excel』を実現!統合プロジェクト管理パッケージ『SI Object Browser PM』を利用してIT企業も近代化しよう~PM...
【12-E-4】 『脱Excel』を実現!統合プロジェクト管理パッケージ『SI Object Browser PM』を利用してIT企業も近代化しよう~PM...
 
【12-B-1】 実例で学ぶ Objective-C 2.0 と GUI の関係~ iPhone アプリ開発を視野に入れて
【12-B-1】 実例で学ぶ Objective-C 2.0 と GUI の関係~ iPhone アプリ開発を視野に入れて【12-B-1】 実例で学ぶ Objective-C 2.0 と GUI の関係~ iPhone アプリ開発を視野に入れて
【12-B-1】 実例で学ぶ Objective-C 2.0 と GUI の関係~ iPhone アプリ開発を視野に入れて
 
【13-C-3】 RIA 開発をとりまく技術の進化と環境の変化
【13-C-3】 RIA 開発をとりまく技術の進化と環境の変化【13-C-3】 RIA 開発をとりまく技術の進化と環境の変化
【13-C-3】 RIA 開発をとりまく技術の進化と環境の変化
 
【13-C-5】 パネルディスカッション 帳票開発の肝
【13-C-5】 パネルディスカッション 帳票開発の肝【13-C-5】 パネルディスカッション 帳票開発の肝
【13-C-5】 パネルディスカッション 帳票開発の肝
 
【13-B-3】 企業システムをマッシュアップ型に変えるには
【13-B-3】 企業システムをマッシュアップ型に変えるには【13-B-3】 企業システムをマッシュアップ型に変えるには
【13-B-3】 企業システムをマッシュアップ型に変えるには
 
【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~
【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~
【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~
 
【13-D-3】 プロとしてのOracleアーキテクチャ入門 ~ 番外編 ~
【13-D-3】 プロとしてのOracleアーキテクチャ入門 ~ 番外編 ~【13-D-3】 プロとしてのOracleアーキテクチャ入門 ~ 番外編 ~
【13-D-3】 プロとしてのOracleアーキテクチャ入門 ~ 番外編 ~
 
【13-B-4】 Java VMへの処方箋 ~先進のメモリ管理技術とは~
【13-B-4】 Java VMへの処方箋 ~先進のメモリ管理技術とは~【13-B-4】 Java VMへの処方箋 ~先進のメモリ管理技術とは~
【13-B-4】 Java VMへの処方箋 ~先進のメモリ管理技術とは~
 
【13-B-2】 パネルディスカッション:クラウド時代のプログラミングスタイルを語り合おう
【13-B-2】 パネルディスカッション:クラウド時代のプログラミングスタイルを語り合おう【13-B-2】 パネルディスカッション:クラウド時代のプログラミングスタイルを語り合おう
【13-B-2】 パネルディスカッション:クラウド時代のプログラミングスタイルを語り合おう
 
【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~
【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~
【13-C-6】 帳票開発に時間かけすぎていませんか?~もっと簡単に「作る」現場、「使う」現場の最適解を探る~
 
【13-E-1】 システムの見える化~エンドユーザーの立場から
【13-E-1】 システムの見える化~エンドユーザーの立場から【13-E-1】 システムの見える化~エンドユーザーの立場から
【13-E-1】 システムの見える化~エンドユーザーの立場から
 
【13-E-1】 システムの見える化~エンドユーザーの立場から
【13-E-1】 システムの見える化~エンドユーザーの立場から【13-E-1】 システムの見える化~エンドユーザーの立場から
【13-E-1】 システムの見える化~エンドユーザーの立場から
 
【13-E-1】 システムの見える化~エンドユーザーの立場から
【13-E-1】 システムの見える化~エンドユーザーの立場から【13-E-1】 システムの見える化~エンドユーザーの立場から
【13-E-1】 システムの見える化~エンドユーザーの立場から
 
【13-D-4】 アナタのアプリ性能改善の秘訣、オラクルが教えます!
【13-D-4】 アナタのアプリ性能改善の秘訣、オラクルが教えます!【13-D-4】 アナタのアプリ性能改善の秘訣、オラクルが教えます!
【13-D-4】 アナタのアプリ性能改善の秘訣、オラクルが教えます!
 
【13-D-1】 ERP5に見るストレージ技術
【13-D-1】 ERP5に見るストレージ技術【13-D-1】 ERP5に見るストレージ技術
【13-D-1】 ERP5に見るストレージ技術
 
【12-B-4】 並列処理開発を支援するコンパイラの機能
【12-B-4】 並列処理開発を支援するコンパイラの機能【12-B-4】 並列処理開発を支援するコンパイラの機能
【12-B-4】 並列処理開発を支援するコンパイラの機能
 
【12-D-2】 WPF アプリケーション開発
【12-D-2】 WPF アプリケーション開発【12-D-2】 WPF アプリケーション開発
【12-D-2】 WPF アプリケーション開発
 
【12-D-3】 ASP.NET MVC - 概要と仕組み
【12-D-3】 ASP.NET MVC - 概要と仕組み【12-D-3】 ASP.NET MVC - 概要と仕組み
【12-D-3】 ASP.NET MVC - 概要と仕組み
 
【12-A-2】 ケーススタディ:不景気と戦うシステムインテグレート
【12-A-2】 ケーススタディ:不景気と戦うシステムインテグレート【12-A-2】 ケーススタディ:不景気と戦うシステムインテグレート
【12-A-2】 ケーススタディ:不景気と戦うシステムインテグレート
 
【13-C-4】 「もう業務はとまらない!オフライン機能を使った業務アプリケーションの実例と最新 Curl 情報」
【13-C-4】 「もう業務はとまらない!オフライン機能を使った業務アプリケーションの実例と最新 Curl 情報」【13-C-4】 「もう業務はとまらない!オフライン機能を使った業務アプリケーションの実例と最新 Curl 情報」
【13-C-4】 「もう業務はとまらない!オフライン機能を使った業務アプリケーションの実例と最新 Curl 情報」
 

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

  • 1. SEC流品質作りこみESQR 組込みソフトウェア開発向け 品質作り込みガイドのご紹介 12-E-2 山崎 太郎 (独)情報処理推進機構(IPA) ソフトウェア・エンジニアリング・センター(SEC) 研究員
  • 2. おいしいりんごの育て方 日当たり •“虫”が入らないようにする 農薬 •おいしく育てる 肥料 育てる過程の工夫が必要 •育て方が適切か •できた果実が消費者の 好みに合っているか 計測し 評価し 改善する 2
  • 3. おいしいりんごって? 育ち具合は? 誰が食べるのか? 大きさ 自宅用 色 ご近所くらいには配る 味 出荷用 傷み具合 どのように作るのか? 庭の木一本だけ/裏の畑/広いりんご畑 ひとりで/人を雇って 育てやすい品種? どうやって育てるか? 肥料は何を、どのくらい 水やりは何回、どのくらい 農薬は何を、どのくらい 摘果はいつ、どのくらい 3
  • 4. 品質評価指標を用いた品質目標設定 指標: ・有形、無形にかかわらず対象(物、作業、サービスなど)の 特質を表現するための科学的な根拠をもったものさし ・指標の計測方法も合わせて定義し、誰が計測しても同じように 値を計測できること ものさし ・測り方 ・精度 ・単位 指標の精度: 計ろうとしている対象の特性を表現し得る適切な 精度を意識して計ること 指標の単位: 指標値を表現するための単位系は指標定義と合わせて、 明確に一つに決めておくこと 4
  • 5. 製品出荷後の不具合:原因別 ソフトウェアの不具合は依然としてトップ →ソフトウェアの不具合がシステムの品質に直結 製品出荷後の不具合:原因別 製品企画・仕様の不具合 ソフトウェアの不具合 ハードウェアの不具合 製造上の不具合 運用・保守の不具合 その他の不具合 0.0% 20.0% 40.0% 60.0% 80.0% 2008年版 組込みソフトウェア産業実態調査 プロジェクト責任者 Q6-1-2 5
  • 6. 製品に不具合を入れないためには 開発時にバグを入れない バグを見つけるためには? どうしてもバグは入り込む レビューとテスト ではどうしたら? テスト、していますよね? 入ったバグを見つけて 取り去ればよい では、レビューは? 6
  • 7. 工程別レビュー実施の実態 どの工程でもレビューを部分的ながらも実施している企業も 多いが、「レビューを実施していない」も20%を超えている 工程別レビュー実施状況 企画・調査・要求獲得 システム 要 求 定 義 完全に実施 シ ス テ ム ア ー キ テ ク チャ 設 計 部分的に実施 ソ フ ト ウ ェア 要 求 定 義 実施していない ソ フ ト ウ ェア 実 装 お よ び 単 体 テ ス ト ソ フ ト ウ ェア 結 合 ・ 総 合 テ ス ト システム 結 合 ・ 総 合 テスト 0% 20% 40% 60% 80% 100% 2008年版 組込みソフトウェア産業実態調査 プロジェクト責任者 Q7-7 7
  • 8. 組込みシステムの品質・信頼性向上 開発管理力強化による 信頼性向上 プロセス設計 ESMR: 高信頼に求められる ESMR: プロセスの設計と実装 マネジメントガイド マネジメントガイド 計画的マネジメント ESPR: ESPR: 要求・設計の高信頼化 開発プロセスガイド 開発プロセスガイド 高信頼性に着目した レビュー・テストプロセス強化 ソフトウェア設計の考え方 SAP:安全関連プロセス ESQR: ESCR: ESQR: ESCR: 設計・実装技術強化に 品質作り込みガイド コーディング作法ガイド 品質作り込みガイド コーディング作法ガイド よる信頼性向上 品質定量化 実装面での高信頼化 コントロール 見える化 定型化 コントロール 8
  • 9. ESQRとは Embedded System development Quality Reference 組込みシステム(ソフトウェア)開発過程で 客観的な品質指標を用いて 品質要素の作りこみとコントロールを行うために 体系的、整備された参照手法 •システムレベルの導出手法:システム・プロジェクトプロファイル、 障害影響度診断等 •品質目標の評価手法、計測可能な指標およびシステムレベルに 応じた参考値の提供 •定性的品質作り込みのためのヒント提供 9
  • 10. ESQR-5つの特徴 特徴1: システム障害震度 フィールドのシステム障害を評価し、品質目標に反映 特徴2: システムプロファイル 対象システムに求められる品質要求をカテゴライズ 特徴3: プロジェクトプロファイル 開発プロジェクトや組織の特性を品質目標に反映 特徴4: 品質評価指標の定義と参考値 ソフトウェアの品質を可視化し、品質目標を明確にする 指標群を整備 特徴5: 作業チェック項目(ヒント) 開発作業の質的な面の向上のためのヒントを提供 10
  • 11. おいしいりんごって? 誰が食べるのか? 自宅用 システムプロファイル ご近所くらいには配る 出荷用 どのように、どのくらい作るのか? 木の本数/畑の大きさ? プロジェクトプロファイル ひとりで/人を雇って 育てやすい品種? どうやって育てるか? 肥料は、農薬は、 プロセス品質評価指標 剪定は、水やりは 育ち具合は? 大きさ・色 プロダクト品質評価指標 味・傷み具合 11
  • 12. ESQRによる品質定量コントロールループ ▲ Step2. Step 3. システムプロファイリング プロジェクトプロファイリング システムの特性を体系的に プロジェクトの特性を体系的に分析 評価・把握 Step 1. ST-SEISMIC Scale Step 4. の考え方 品質目標設定 実フィールドでのシステム障害を プロセス品質評価指標/プロ 品質目標にフィードバック ダクト品質評価指標を用いて 品質目標値を設定 Step 5. ▲ 品質コントロール 品 質 実プロジェクトで 品質定量指標を計測 作業の質の評価 品質目標に近づけるように コントロール 時間 12
  • 13. STEP1. ST-SEISMIC Scale 発生した不具合の影響度を分析、震度として評価 → システムプロファイルへ:次開発へのフィードバックを行う 事後安全計画へ 事前安全計画へのインプット 13
  • 14. STEP2. システムプロファイル システム利用・運用時に発生する可能性のあるシステム障害を想 定し、人的面及び、経済面への影響や被害額をもとに対象システ ムを4つのシステムタイプに分類 使う側の立場で分析 1万人のユーザがその製品を2日使えなくなる 1日当たりの被害額が5千円として、 1万人× 5千円×2日=1億円 14
  • 16. STEP4. 品質指標の設定 プロセスとプロダクトの2つの観点で、品質を確保するための活動 について品質指標および目標値を設定 ものさしと判断目安を決定 プロセス品質評価指標: プロダクト品質評価指標: 作業の十分性を評価 成果物の出来を評価 要求分析定義 仕様書 ドキュメント レビュー作業充当率 システム設計 品質評価指標 設計書 ソフトウェア設計 レビュー作業実施率 コード 実装(コーディング) コード 品質評価指標 テスト作業充当率 ソフトウェアテスト テスト テスト仕様書 成績書 品質評価指標 システムテスト テスト作業実施率 16
  • 17. 品質指標:プロセス品質評価指標 プロセス品質評価指標⇒品質確認作業(レビュー、テスト )の十分性を評価する指標 要求定義 設計 実装 テスト ▲アーキテクチャ設計書・ ▲要求仕様書 詳細設計書 ▲ソースコード レビュー作業充当率 レビュー作業実施率 ▲テスト仕様書・ レビュー テスト報告書 テスト作業充当率 テスト実施 テスト作業実施率 作業充当率 : 作業の相対的な工数の十分性を評価 (レビューまたはテスト作業工数/開発工数) 作業実施率 : 作業の質的な十分性を評価 (レビューまたはテスト作業工数/ソースコード全行数) 17
  • 18. 品質指標:プロダクト品質評価指標 プロダクト品質評価指標 →中間成果物ならびに最終成果物の出来ばえを評価する指標 要求定義 設計 実装 テスト ▲アーキテクチャ設計書・ ▲要求仕様書 ▲ソースコード 詳細設計書 ▲オブジェクトコード ドキュメント品質評価指標 ▲テスト仕様書・作成 コード品質評価指標 ▲テスト報告書 テスト品質評価指標 仕様書の記述量は 十分か 制御文の記述 ドキュメント品質評価指標 : 作業のインプット/アウトプットとなるドキュメントの 率は高くないか 量とバランスを評価 コード品質評価指標 : ソフトウェアの基となるソースコードを静的に量と特性を評価 テスト品質評価指標 : ソフトウェア自身を動的評価するテストに対し、十分性と動作 完全性を評価 不具合はちゃんと 直っているか 18
  • 19. STEP5. 定量的なプロジェクトのコントロール 適切な指標で状況を可視化 対象製品 対象プロジェクト 目標値達成に向けて 特性を コントロール 考慮 品 質 品質・信頼性 目標値 時間 19
  • 20. 品質コントロールの例(その1) システム:計測器(無線通信波形計測、分析、信号発生) 既存製品の高周波対応展開、ユーザはメーカ等の開発者 Step1. システムプロファイル 人的損失はない→Type3以下 修理に1週間かかる、各ユーザの使用頻度は低い(毎日使うものではな い) 損害額は1日2千円と見積もり 経済損失: 被害日数(5日)×ユーザ数(3,000人)×影響率(0.2)×損害額(2,000円) =6,000,000円 → Type1:Nに決定 ① ソフトウェア規模 □ 極めて小さい 普通 □ 極めて大きい ② ソフトウェアの複雑さ □ 極めて単純 普通 □ 極めて複雑 Step2. プロジェクトプロファイル ③ システム制約条件の厳しさ □ 制約ゆるい 普通 □ 制約厳しい ④ 仕様の明確度合い 極めて明確 □ 普通 □ 明確になっていない 仕様は明確、他は突出した ⑤ 再利用するソフトウェアの品質レベル□ 極めて高品質 普通 □ 極めて品質低い ⑥ 開発プロセスの整備度合い □ 整備できている 普通 □ 整備できていない ⑦ 開発組織の分業化・階層化の度合い □ 開発組織が単純 普通 □ 開発組織が複雑 特徴は無い(右表参照) ⑧ 開発メンバーのスキル □ メンバースキル高い 普通 □ メンバースキル低い ⑨ プロジェクトマネージャの経験とスキル PMスキル高い □ 普通 □ PMスキル低い → 補正係数:-0.1 ⑩ システム障害時のメーカ側損失額 □ 極めて小さい 普通 □ 極めて大きい 小計 -1 0 合計ポイント数 -1 20
  • 21. 品質コントロールの例(その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
  • 22. 品質コントロールの例(その3) Step4. 実際の開発フェーズでの指標値の測定と評価 レビュー作業充当率の評価の例 開発全工数の見積もり値: 27,900人時 『結合テスト開始時点』(=テスト関連のみ見積もり値、他は実績値)での 全レビュー工数見積もり値:900人時 レビュー作業充当率=全レビュー工数 / 開発全工数 = 900 / 27,900 = 0.032 = 3.2 (%) 目標値 3.6(%)に対して、若干少ない これまでのレビューを再度見直す、テストを厚くするなどの対応を行う 設計書ボリューム率の評価の例 ソースコード全行数の見積もり値: 80KLOC 『設計書レビュー開始時点』(=ソースコードはまだ存在しないため、 全て見積もり値)での設計書ページ数:500ページ 設計書ボリューム率=設計書ボリューム / ソースコード全行数 = 500 / 80 = 6.25 目標値 8.00に対して、少ない 設計書にもれ抜けがある可能性が高いことに気をつけ、レビューを実施する 22
  • 23. 高品質作り込みのためのヒント 定量的コントロールだけでなく、品質作り込みを行うための 定性的なコントロールのヒントを提供 コミュニケーションと意思決定 1. ドキュメント 2. レビュー 3. テスト 4. 指標を用いた 5. 品質作り込み活動 23
  • 24. 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. 想定する利用者 実際の工程管理や品質管理を検討・決定するマネージャやリーダ 開発プロセスの標準や品質に関する基本的な考え方を整備運用するメンバ 品質保証など、ソフトウェア開発を間接的に支える支援グループのメンバ 25
  • 26. 得られる効果 利用者側から見たシステムの適切な品質レベルを分析考察できる →品質確保のための作業の見直しを行うことができる プロジェクトの特性を客観的に捉えられる →品質目標の設定に反映 目標値を設定して開発をすすめる →品質を実現するための必要十分な作業を行うことができる 26
  • 27. ESQRを利用する場合の注意点 ESQRで提示した品質指標を全て利用する必要はない ⇒信頼性を抑えるための指標は決まっていますか? 参考値をそのまま利用しない ⇒ 自部門の実力やシステム特性などを考慮して 個別に事前検討し目標値を定める 数値に振り回されない ⇒ 数値を達成することが目標ではなく、結果にいたる までのコントロールが重要 ⇒ 定性的な側面や内容も合わせて考える 実際のデータで議論しましょう ⇒ うまいやり方があればフィードバックをお願いします 27
  • 29. ご清聴ありがとうございました ISBN978-4-7981-1884-0 組込みソフトウェア開発向け 品質作り込みガイド 翔泳社 ©2008 IPA 29