(Microsoft PowerPoint - \220\303\211i24.ppt)

Transcription

1 委託開発管理とメトリックスモデル 2005 年 10 月 14 日 ( 金 ) SEPG Japan 2005@ 東京コンファレンスセンター 宇宙航空研究開発機構奈良先端科学技術大学院大学株式会社 SRA 静永誠 片平真史松本健一小嶋勉

2 ソフトウェア調達における問題 ソフトウェアを外部の組織から調達する場合 開発者と最終利用者との間には組織 文化などの面から多くの垣根が存在する それぞれの垣根毎に 最終利用者の要望と開発されるソフトウェアとが一致しなくなるリスクが増大する それぞれの垣根毎に 品質 納期などの保証が十分に行えなくなるリスクが増大する ソフトウェアソフトウェアソフトウェアソフトウェアの調達調達調達調達におけるにおけるにおけるにおけるリスクリスクリスクリスクを管理管理管理管理するたするたするたするためにめにめにめに適切適切適切適切な情報情報情報情報を識別識別識別識別することがすることがすることがすることが重要重要重要重要になるになるになるになる

3 発注元 ソフトウェア調達のリスク (1) 発注要求 要求は正しく伝わっているか? 委託先 本当に問題は何もないか? 各種報告 本当に品質は確保されているか? 試験結果

4 システム開発ソフトウェア開発発注元委託先開発依頼システム要求分析システム方式設計ソフトウェア要求分析ソフトウェア方式設計ソフトウェア詳細設計ソフトウェアコード作成及びテストソフトウェア結合ソフトウェア適格性確認テストシステム結合システム適格性確認テスト要求製品受け入れ及び完了進捗管理 品質管理 など設計文書要求の理解の漏れ品質記録不具合情報マイルストーン レビュー定期的なレビュー問題問題問題問題の早期発見早期発見早期発見早期発見が難しくなるしくなるしくなるしくなる分担分担分担分担が曖昧曖昧曖昧曖昧な作業作業作業作業が漏れ易くなるくなるくなるくなる品質品質品質品質の作り込みがみがみがみが難しくなるしくなるしくなるしくなる利用できる情報の制約コミュニケーションの阻害契約などで明示されてない作業の漏れ 重複ソフトウェア調達のリスク (2)

5 問題 : 委託先との作業の漏れ 重複 組織にまたがる作業でありながら入出力成果物のやり取りがない例 SW 調達での曖昧な作業分担 ( 例 ) JAXA 実現性調査依頼 委託先 実現性調査 要件定義 実現性調査結果 委託先を含めた 役割分担の明確化の必要性 SW 調達での重複作業 ( 例 ) JAXA 実現性調査依頼 委託先 実現性調査 要件定義 実現性調査結果 (JAXA) 実現性調査結果 ( 委託先 ) 同一成果物を複数プロセスで更新している例

6 問題 : 委託先作業の品質 技術変化 (SW/HW) への対応 調達 SW での品質管理 ( 例 ) JAXA 委託先 品質の確保 維持 向上の必要性 取得する品質記録と評価基準の確立 ( 定期的な監視 ) ソフトウェア要求分析 品質評価の基準確立 品質評価のタイミングの明確化 実行の監視 品質記録 ソフトウェア要求事項の確立 ソフトウェア要求事項の評価 安全性 信頼性への高い要求 取得する品質記録と評価基準の確立 ( マイルストーン毎の監視 ) レビュー ソフトウェア要求仕様書 品質記録

7 問題解決へのアプローチ SW 開発を外部に委託することにより 問題の早期発見が難しくなる分担が曖昧な作業が漏れ易くなる品質の作り込みの確認が難しくなる SW 開発の外部委託を成功させるために 委託先との役割分担を明らかにする 外部委託を行ったときの品質確保の方法を確立する プロセス改善の土台を作り 継続的な改善を可能にする 統合プロセスプロセスの検討 委託先管理に有効有効なメトリックスメトリックスの検討

8 統合プロセスについて (1) SW-CMM における ソフトウェア統合管理 の説明 ソフトウェア統合管理 の目的は ソフトウェアのエンジニアリング活動と管理活動とを一体化して 定義されたソフトウェアプロセスに統合することである 定義されたソフトウェアプロセスは 組織の標準ソフトウェアプロセス や関連したプロセス資産からテーラリングされたものである これらについては 組織プロセス定義 キープロセスエリアに記述されている SW-CMM における 組織プロセス定義 の説明 組織プロセス定義 の目的は プロジェクト横断的にプロセス実績を改善するのに利用できるソフトウェアプロセス資産を開発し維持し そして組織に累積的で長期的に利益をもたらす基盤を提供することである CMMI( 連続表現 ) における IPPD のための 統合プロジェクト管理 の 目的 統合プロジェクト管理 の目的は 組織の標準プロセスの集合 からテーラリングされる 統合され定義されたプロセスに従って プロジェクトおよび直接の利害関係者の関与を確立し管理することである [PA167] また 統合成果物プロセス開発 においては 統合プロジェクト管理 はプロジェクトの目標を成し遂げるために プロジェクトにとっての共有ビジョンを確立することと 統合チーム群のチーム体系を確立することも扱う [PA167.PE101] CMMI( 連続表現 ) における 組織プロセス定義 の目的は 利用できる組織プロセス資産の集合を確立し維持することである [PA153] DoD Guide to Integrated Product and Process Development (Version 1.0), February 5, 1996 A management technique that integrates all acquisition activities starting with requirements definition through production, fielding/deployment and operational support in order to optimize the design, manufacturing, business and supportability processes.

9 統合プロセスについて (2) JAXA 統合管理 委託先 ライフサイクルとプロセス構成要素の組み合わせ プロセス構成要素間の I/F 調整 プロセスを理解理解し記述記述するのにするのに必要な粒度粒度のプロセス構成要素に分解されている (SW-CMM, 組織プロセス定義 KPA, 活動 2.1) 組織プロセス プロセス構成要素構成要素の DB SW 品質管理構成管理など 検証 SW 要求分析 SW コード作成 フィードバックデータの提供 SW 要求分析 SW 品質保証各プロセス構成要素毎構成要素毎に ゴール 目的を明らかにする SW ライフサイクルの DB 変更提案の提供 ウォータフォール スパイラル

10 統合プロセス検討の動機 目的の整理 統合プロセス検討の動機となった問題 要求 委託先と JAXA との役割分担が不明確な部分があった 高い信頼性への要求などのために 委託開発であっても品質を確保する必要があった 技術の変化や開発期間の短縮など 環境の変化によりプロセス改善の必要性が強くなっていた 統合プロセス検討の目的 統合プロセス検討にあたって 次の目的を重視することにした 作業に対する責任の所在を明らかにする プロセス改善の基盤を作成する

11 統合プロセス検討の手順 ISO-12207(JIS X 0160) ソフトウェアライフサイクルプロセス 不明確な用語 一次案のフェーズと実際の開発との曖昧な対応付けなど 一次案の作成 関係者のレビュー レビュー結果の反映 共通フレーム 98 SLCP-JCF98 SLCP の用語と現場の用語との調整 実際の開発フェーズとの対応付けなど

12 発注元 / 委託先それぞれの実施作業明確化システム開発開発プロセスソフトウェア調達構成管理検証発注元委託先開発依頼要求製品受け入れ及び完了設計文書品質記録不具合情報マイルストーン レビュー定期的なレビュー統合プロセスによる監視データの検討 SW 品質保証品質保証構成管理調達者調達者調達者調達者としてとしてとしてとして利用可利用可利用可利用可能でかつでかつでかつでかつ有用有用有用有用な手段 データデータデータデータを検討検討検討検討 SW 結合 SW 方式設計 SW 要求分析発注元 / 委託先インタフェースの明確化各プロセス構成要素毎の ゴール 目的明確化ゴールゴールゴールゴール 目的目的目的目的の実現実現実現実現を確認するするするする手段手段手段手段 データデータデータデータの検討手段手段手段手段 データデータデータデータの一つとしてとしてとしてとして メトリックスメトリックスメトリックスメトリックスの検討検討検討検討データデータデータデータ取得取得取得取得上の制約制約制約制約発注元発注元発注元発注元 / 委託先委託先委託先委託先のインタフェースインタフェースインタフェースインタフェース

13 ソフトウエアメトリクスの様々な意味 (EASE プロジェクト公開資料より ) N. E. Fenton, Software Metrics: A Rigorous Approach, Chanpman&Hall Number( 数値 ) ソフトウェア開発のプロダクト, プロセス, あるいは, 開発に要する資源から得られる具体的な数値. 例 : プログラム行数, リリース後の故障数. 一月当たりの開発行数 Scale( 尺度 ) 計測のものさし, 分類基準. 例 : 混入工程に基づくバグ分類. 重大さに基づく故障分類 Attribute( 属性 ) プロダクト, プロセス, あるいは開発に要する資源を特徴づける性質. 例 : モジュール間結合度 ( 非直接結合, データ結合, スタンプ結合, 制御結合, 外部結合, 共通結合, 内容結合 ) 例 : ソフトウェア信頼性 ( 一定期間内に故障を起こさない確率 ) Model( モデル ) プロダクト, プロセス, あるいは開発に要する資源の間の関係を表す理論的モデル, あるいは実測データに基づいて構築されたモデル. 例 : COCOMO, ファンクションポイント, ソフトウェア信頼度成長モデル メトリクスの対象の種類 Process( プロセス ) Product( 製品 ) Resource( 資源 )

14 ISO15939 ISO/IEC 15939:2002, Software engineering Software measurement process.) J. McGarry, D. Card, C. Jones, B. Layman, E. Clark, J. 5 つのレベル 情報ニーズ 情報成果物 情報成果物 解釈モデル 指標 判断基準 指標 分析モデル 導出測定量 ( 尺度 ) 導出測定量 導出測定量 基本測定量 ( 尺度 ) 基本測定量 測定関数 基本測定量 実体 属性 測定方法 属性 基本測定量 属性 奈良先端大松本健一教授資料より

15 目的 直接製品評価 発注元によるによるプロセスプロセス監視深度監視深度と履行方法 インタフェース 運用性評価 直接製品検査 ( 文書レビューなど ) プロダクト評価 間接製品評価 サマリーレポート 委託先レビュー結果の点検 メトリクス評価 分析レポート 情報成果物評価 指標判断 測定量分析 直接プロセス評価 各種報告書評価 直接記録検査 ( 立会い検査 ) プロセス評価 間接プロセス評価 サマリーレポート 委託先記録検査結果の点検 メトリクス評価 分析レポート 情報成果物評価 指標判断 測定量分析 プロセス測定量測定量がプロダクトプロダクト評価評価にもにも利用利用されるされる場合場合がある ( 例 : 作業遅延 製品品質 ) プロダクト測定量測定量がプロセスプロセス評価評価にもにも利用利用されるされる場合場合がある ( 例 :TBD 残数 プロセス停滞 ) 深度が深いほどいほどコストコストがかさむ 製品 記録記録を分析分析するのかするのか メトリクスメトリクスを分析分析するのかするのか またはそのまたはその組み合わせか それぞれのゴールゴールに対してのしての履行方法履行方法 深度深度の設定設定 調整調整をおこなう コスト対効果対効果を考慮考慮し 統合統合プロセスプロセスの中に入れ込む

16 統合統合統合統合プロセスプロセスプロセスプロセスにおけるにおけるにおけるにおける適用方法適用方法適用方法適用方法の検討検討検討検討情報成果物情報成果物指標指標導出測定量導出測定量解釈モデル分析モデル測定関数判断基準判断基準導出測定量導出測定量基本測定量基本測定量属性属性測定方法評価コスト適用可能時期評価コスト適用可能時期基本測定量基本測定量属性属性測定方法評価コスト適用可能時期評価コスト適用可能時期基本測定量基本測定量属性属性測定方法評価コスト適用可能時期評価コスト適用可能時期情報成果物情報成果物指標指標導出測定量導出測定量解釈モデル分析モデル測定関数判断基準判断基準基本測定量基本測定量属性属性測定方法評価コスト適用可能時期評価コスト適用可能時期基本測定量基本測定量属性属性測定方法評価コスト適用可能時期評価コスト適用可能時期トータル評価コスト適用可能時期トータル評価コスト適用可能時期例 : 統合プロセス上のインタフェースポイント例 : 統合プロセス上のインタフェースポイント例 : 統合プロセス上のインタフェースポイント

17 まとめ ソフトウェア調達に存在するリスクについて検討した 問題の早期発見が難しくなる 分担が曖昧な作業が漏れ易くなる 品質の作り込みが難しくなる ソフトウェア調達の改善アプローチとして統合プロセスの検討を実施した 作業分担 インタフェースを明確化した プロセス構成要素と その目的 ゴールなどを明確化した ソフトウェア調達リスクを管理するために有効な手段の一つとして メトリックスの検討を実施した メトリックスの分類 ( 数値 尺度など ) 対象 解釈モデルについて整理した 取得データと委託先への介入の深さとの関係を整理し 調達者から見てのデータ取得上の制約について整理した