機能規模測定手法 COSMIC 法を用いた画面生産性の分析事例 藤井 拓†, 細川 亮二††, 木村めぐみ† 本論文では, 1 つのプロジェクト内での画面毎の 1. はじめに 生産性（画面生産性）を機能規模測定手法COSMIC 従来からソフトウェア開発プロセスの改善を行 法[1]の測定値に基づいて求める方法を説明する. うために, 以下のような測定が行われてきた. さらに, A) 開発工程にレビュー作業を組み込み, その 分析するために用いた作業の分類方法について報 レビュー回数, 指摘件数とテスト段階で検 告する. 画面生産性のバラつきを生んだ要因を 出した欠陥数とを測定し, これらのデータ から欠陥を効果的に予防できるように開発 プロセスを改善する B) 2. 開発生産性と規模 開発生産性は, 一般的に開発対象のソフトウェ 開発終了時点のコード行数, 労力, 欠陥数 アの規模と開発に要した労力より以下のように求 を測定し, めることができる. それらから開発生産性や欠陥密 度を求める 開発生産性 ൌ A)は, ウォーターフォール型の開発ライフサイク 規模 実績労力 ルに基づく標準的な開発プロセスが用いられ, ド この式の「規模」としては, ソースファイルのコ メインや技術にも共通性があるような開発組織に ード行数の測定値を使うことも COSMIC 法のような おいて用いられていることが多い. その一方で, 開発途上で要求の追加や変更が多く発生したり, 顧客によってドメイン, 開発プロセス, 技術がマ チマチな受託開発では, A)のような測定や改善を 行う事が難しい. B)は, 開発プロセスの違いによらず測定できる. 機能規模測定手法の測定値を使うこともできる. 本論文では, 前者をコード規模, 後者を機能規模 と呼ぶ. COSMIC法は, ファクションポイント(IFPUG) 法[2]と並んでISO標準およびJIS標準になってい る機能規模測定手法である. COSMIC法では, 以下 の 2 つの境界を出入りするデータの種類を数える しかし, 開発終了時点でプロジェクト全体の開発 ことで機能規模を定量化する. 生産性や欠陥密度などを測定しても, その結果か z システムと外界との境界 ら個別の開発作業が効果的に行われたかという点 z システムと永続ストレージとの境界 や, 要求の追加/変更が開発生産性にどのような IFPUG 法と比べて, COSMIC 法が魅力的な点は以下 影響を及ぼしたかという点などを読み取ることは のとおりである. 困難である. そのため, 測定結果からプロセスを z 測定方法が比較的シンプルである 改善するためのヒントを得ることは困難である. z 測定マニュアルやガイドラインが一般に公 これら従来の測定や分析が難しい原因の 1 つは, ライフサイクルや適用する技術等の生産性や品質 に影響を与える因子が異なるプロジェクトの間で 比較を行おうとしている点にあると考えられる. 開されている 一方, COSMIC 法の弱い点は以下の点である. z 測定手法としての普及度が日本では低い z ビジネス分野での測定実績や評価が日本で は少ない ライフサイクルや適用する技術等の前提が同じ 1 著者らは, COSMIC 法の長所に注目し, ビジネス系 つのプロジェクトに限定すれば, プロジェクト内 ソフトウェアの機能規模測定での有効性を明らか の生産性や欠陥密度のバラつきに影響を与える因 にするために自社の開発プロジェクトにおいて 子も限定される. そのため, それらの因子と生産 COSMIC 法を適用している. 性や欠陥密度との因果関係が明らかになる可能性 がある. 機能規模を用いて開発生産性を求める場合とコ ード規模を用いて開発生産性を求める場合とを比 べると, 両者には表 1 で示されるような長所と短 † (株)オージス総研 技術部ソフトウェア工学センター ††(株)オージス総研ソリューション開発本部 BS3 部 所がある. 表1 開発生産性を求める 2 つの方法の比較 長所 z z 手動測定が必要 z 設計/実装構造によって開発 z コード行数が測れないものは 発生産性の評価が可能 機能規模を用いる場 合 短所 設計/実装構造によらない開 z コード行数が測れないものも z 測定の自動化が可能 開発生産性が求まる コード規模を用いる 生産性が変わる 場合 開発生産性が求まらない 著者らは, 機能規模を用いる場合の長所 2 点が魅 非 UI 部分の作業難易度や負荷」の 2 つの因子に注 力的だと考え, 本研究では機能規模を用いた開発 目した. UI はモデル-ビュー-コントローラー(MVC) 生産性の定量化を行った. のビュー部分の機能, 非 UI はモデル及びコントロ ーラー部分の機能に対応する. そのため, 開発作 3. 画面生産性と作業の分類 業を表 2 に示されるような大分類と中分類で分類 して実績労力を記録した. 同一プロジェクト内での開発生産性のバラつき この表の大分類は前 を定量化する方法としては, 以下の式で求まるよ 述した A), B), C)の 3 分類に対応し, 中分類は作 うな画面生産性を考えることができる. 業対象により UI, 非 UI, どちらでもないの 3 種類 画面生産性画面 ൌ 機能規模画面 に分類している. 実績労力画面 いる. 中分類の「どちらでもない」は UI と非 UI のどちらかに帰属できない作業を表して ここで機能規模 画面 , 実績労力 画面 は各々画面単位 の機能規模の測定値, 画面単位の実績作業労力を 表す. 実際の開発作業では, 以下のような 3 種類 の開発作業が発生する. A) 画面固有の機能の設計, 実装, テスト作業 B) 画面共通の機能の設計, 実装, テスト作業 C) プロジェクト管理等の特定の機能を対象と しない作業 画面生産性の算出においては A)の実績労力だけを 用いる. プロジェクト全体の開発生産性は, 画面 毎の機能規模の総和と上記 A), B), C)の合計であ る実績労力から求める. B),C)の実績労力を除外し ているため, 画面生産性の値はプロジェクト全体 の開発生産性よりも高めの値となる. 4. 最後に ワークショップでは, 本論文で提案した画面生 産性と作業労力の分類を適用の結果を示し, 分析 方法の有効性について議論したいと考えている。 参考文献 [1] COSMIC 法 ver3.0 測 定 マ ニ ュ ア ル , http://www.jfpug.gr.jp/cosmic/CFFP-ind ex.html [2] デービット・ガーマス他, ファクションポイ ントの計測と分析, ピアソン・エデュケーショ 本研究では画面生産性のバラつきに影響する因 ン, 2002 子として, 「画面間の共通機能の括りだし」と「UI/ 表 2 作業労力の分類 中分類 画面固有 大 分 画面共通 類 プロジェ クト共通 z z UI 詳細設計(UI) 実装・単体テスト (UI) z z z z 非 UI 詳細設計(非 UI) 実装・単体テスト (非 UI) 詳細設計(非 UI) 実装・単体テスト (非 UI) z どちらでもない 設計 z 設計 z z 設計 プロジェクト管 理
© Copyright 2024 ExpyDoc
