２００７／５月　総会発表内容（見積り手法）

Size: px

Start display at page:

Download "２００７／５月　総会発表内容（見積り手法）"

ありみちはらしない
4 years ago
Views:

1 Software Engineering Center Information-technology Promotion Agency, Japan ソフトウェアテスト見積りについて品質要件に応じた見積りとは 2008 年 10 月 28 日 ( 火 ) 独立行政法人情報処理推進機構ソフトウェアエンジニアリングセンター高橋茂

見積り手法に関する活動国内企業の成功事例収集特徴を分析 8 社 3 社 5 社見積りの重要ポイント

適用の拡大ソフトウェア改良開発見積り適用の拡大ソフトウェアテスト見積り ( 見積り適用推進 WG) 2005 年

ガイドブック新たな課題の検討 ( ソフトウェア価値評価検討 WG) ( 高生産性技術見積り検討 WG) 成果の普及

2 見積り手法に関する活動国内企業の成功事例収集特徴を分析 8 社 3 社 5 社見積りの重要ポイント見積りの重要性 & 能力向上に必要な活動見積り手法の適切な導入小冊子の内容を個別技術的に解説見積り向上の考え方適用の拡大ソフトウェア改良開発見積り適用の拡大ソフトウェアテスト見積り ( 見積り適用推進 WG) 2005 年 4 月小冊子 2006 年 4 月ガイドブック 2007 年 10 月 2008 年 9 月ガイドブックガイドブック新たな課題の検討 ( ソフトウェア価値評価検討 WG) ( 高生産性技術見積り検討 WG) 成果の普及規模見積り手法ユーザのための簡便手法見積り成熟度向上の方法 2006 年 2008 年啓蒙教材先進的な見積り手法国内企業で実証評価 1

3 本書の位置づけこれまでの書籍ではソフトウェアテスト工数コストはプロジェクト当初の見積りに包含されている前提但しテスト工数の見積りには様々な課題があるテスト終了時の残存欠陥の予測が困難テスト量と品質要求とのトレードオフテスト完了基準などユーザ / ベンダ間での合意非機能要件の把握とテスト量への反映本書は既発刊のガイドブックを補足しソフトウェアの品質検証と妥当性確認に関わるテスト見積り ( テスト量テスト生産性 ) の方法やノウハウを紹介 2

4 ソフトウェアテスト見積りガイドブック ( 目次 ) 目次構成第 1 部総論第 1 章ソフトウェアテスト見積りの課題 1.1 システムの信頼性向上からみたソフトウェアテスト見積りの課題レビューおよびテストを鑑みた残存欠陥の予測テスト量の論理的把握と品質の完全性保証改造開発および仕様変更におけるテスト量の把握非機能要件の把握と確認 1.2 ソフトウェア品質と価格の関係に関する認識の統一第 2 章開発プロセスモデルとテストテスト手法 2.1 品質保証から見た開発プロセスモデルとテスト方法 2.2 テストプロセスとソフトウェア開発プロセスモデル 2.3 テスト手法の一般的事項ソフトウェアテスト方法ソフトウェアテスト技法 2.4 ソフトウェアテストの見積りの範囲 2.5 テストプロセスおよびテストドキュメントテストプロセステストドキュメントの記述項目第 3 章ソフトウェアテスト見積りでの成功と失敗例 3.1 ソフトウェアテスト全般に関する事例 3.2 テスト戦略とソフトウェアテスト見積りに関わる事例 3.3 テスト進行中における品質管理と再テスト見積り 3.4 テスト戦略の重要性テストレベルテスト戦略第 4 章ソフトウェアテスト見積りの詳細 4.1 ソフトウェアテスト見積りの手順目次構成 4.2 テスト量と品質目標値一般的事項残存欠陥密度の設定レビューおよびテストでの欠陥検出戦略の統合ソフトウェアのテスト完了基準テストの網羅性とソフトウェアテスト量 4.3 テスト網羅性尺度とテスト量見積り方法ホワイトボックステストでの網羅性尺度とテスト量見積方法ブラックボックステストでの網羅性尺度とテスト量見積方法合理的なテスト量の削減方法 4.4 仕様変更量とテスト量仕様変更量と開発量 ( テスト量 ) との関係見積りを行う上での仕様変更の考慮点 4.5 テストの生産性に影響する変動要因 4.6 非機能要件の把握とテスト見積りへの反映非機能要件の把握と確認方法非機能要件のテスト見積りへの反映 4.7 欠陥修正に関わる工数の把握欠陥修正量 ( 工数 ) の把握欠陥修正による再テスト工数の把握第 5 章ソフトウェアテスト見積り精度の向上 5.1 見積りの前提条件のモニタリングとコントロール 5.2 見積り手法と継続的な改善 5.3 契約によるリスク解消の糸口見積りにおけるユーザ企業とベンダ企業の役割変動要因に関するユーザ企業とベンダ企業の調整プロセスソフトウェアテストの段階的な見積りと多段階契約の採用添付資料 ( 非機能要件の把握確認とテスト見積りへの影響表 ) 第 2 部事例編日本ユニシス日立製作所東京海上日動ジャステック NEC の 5 社の事例を紹介 3

5 第 2 章開発プロセスモデルとテスト手法品質保証の観点から見たモデル <V 字型モデル > 設計実装工程で作り込まれたソフトウェアの欠陥は当該設計実装工程のレビューおよび相対するテスト工程で検出する 4

6 第 2 章開発プロセスモデルとテスト手法 <W 字型モデル > テストファースト ( 開発初期段階からテストを計画しながら進める ) の考え方に基づき設計実装工程で作り込むソフトウェアの欠陥を当該設計実装工程のレビューで検出しさらに相対するテスト工程のテスト設計を開発工程の水準にあわせて同時並行して行う 5

7 第 2 章開発プロセスモデルとテスト手法テスト方法の分類ブラックボックステスト要求仕様や外部仕様を基にしてテストを設計する方法でユーザ視点で外部からの入力に対するアウトプットを検証するテストホワイトボックステストテスト対象ソフトウェアの内部パス構造設計情報に基づいてテスト設計する方法代表的なテスト技法ブラックボックステスト同値クラステスト境界値テスト異常値テスト / 無効値テストペア構成テスト ( オールペア法直交表 ) 状態遷移テストドメイン分析テストデシジョンテーブルテストユースケーステストホワイトボックステスト制御フローテスト / 制御パステストデータフローテスト 6

8 第 3 章ソフトウェアテスト見積りでの成功と失敗例事例 5: 保留していた仕様変更をシステムテストで対応しテスト負荷の増加と品質低下を招いた失敗事例課題となっている状況状態システムテスト工程で保留していた仕様変更と新たな仕様変更が大量に発生したがテスト期間や要員資源を限定されたため結果として十分なテストが実施できず品質低下を招いた成功と失敗例に関して見積りの成功 / 失敗の度合い 31 事例を紹介スケジュール厳守したが品質は大幅に低下したテスト密度( ケース数 / ソフト規模 ): 見積比 0.5 倍本番障害発生頻度: 見積比 5 倍教訓メッセージソフトウェアテスト全般に関する事例 (10 件 ) テスト戦略とソフトウェアテスト見積りに関わる事例 (18 件 ) ( 品質指標目標値コンポーネントの重要度テストプロセステスト環境テスト分担 ) テスト進行中における品質管理と再テスト見積りでの事例 (3 件 ) 同じ機能の仕様変更対応でもタイミング ( 取り込み工程 ) が異なると対応コストが増減する特質がある仕様変更の取り込みはシステムテスト工程が一番のコスト高 ( 棄却工数増など ) となるまたソフトウェアの品質劣化 ( デグレード ) を招きやすいこのような仕様変更の特質をユーザとベンダ相互に理解することが重要である 7

9 第 3 章ソフトウェアテスト見積りでの成功と失敗例事例 11: 標準的な品質目標値をそのまま使用して失敗した事例課題となっている状況状態基盤開発でユーザ提示のテスト密度 (50 項目 /KS) とテストケース抽出方法を前提にテスト見積りを行ったがテスト量 ( テストケース数 ) の増加となった見積りの成功 / 失敗の度合い抽出方法が細かかったためテストケース増加となったが幸いにも 1 ケースあたりのテスト実施時間が短時間で済んだためコストへの影響は少なくて済んだテスト密度 ( ケース数 / ソフト規模 ): 見積比 2.0 倍テストコスト : 見積比 1.05 倍教訓メッセージ標準的な品質目標値をそのままテスト対象システムに適用することはきわめて危険である品質目標値はテスト戦略において対象システムの特質などを見きわめ ( 分析評価 ) その結果をテスト見積りの入力情報にすることが必要である 8

10 第 3 章ソフトウェアテスト見積りでの成功と失敗例テスト戦略の必要性事例を鑑みて見積り精度向上のためにはプロジェクトの見積り時点でテスト戦略を定めこれを見積りのインプットにすることが重要テスト戦略の具体例テスト技法の選択同値クラスペア構成 ( 直交表 ) 状態遷移など品質指標目標値の設定テスト密度テスト網羅率欠陥密度などテスト環境自動化テストツール結果照合ツールなどテスト分担ユーザとベンダの役割などテスト進行中における品質管理信頼度成長曲線テスト完了基準など 9

11 第 4 章ソフトウェアテスト見積りの詳細テスト見積りの基本手順テスト量 I = 開発規模基準テスト密度 I (1+α) α: 基準テスト密度 I でのカバレッジ率とシステム毎の顧客要求 ( テスト戦略 ) カバレッジ率との差分によるテスト密度の変動率 10

12 第 4 章ソフトウェアテスト見積りの詳細テスト戦略に基づく品質目標値品質目標値は次のような品質指標に基づいてテスト戦略策定を通して設定残存欠陥密度工程ごとの欠陥検出密度テスト完了基準テスト網羅率残存欠陥密度 ( 欠陥検出戦略 ) の設定出荷時の残存欠陥数を測ることは困難出荷後に発見した欠陥数を測定するしかないユーザと出荷時の残存欠陥密度を合意する必要がある現実にはソフトウェアテストをどこまで実施するかということをユーザと合意することになる工程ごとの欠陥除去数と残存欠陥数との関係は次頁のとおり 11

13 第 4 章ソフトウェアテスト見積りの詳細設計実装工程とテスト工程での欠陥除去数と残存欠陥数との関係基本設計 PKG 設計フロクラム設計コード化単体テスト統合テストシステムテスト ( 工程 1) ( 工程 2) ( 工程 3) ( 工程 4) ( 工程 5) ( 工程 6) ( 工程 7) ( レビューによる ) 欠陥数欠陥除去数欠陥除去数 ( テストによる ) 工程独自欠陥混入数残存欠陥数顧客と合意ジャステック社からの出典 12

14 第 4 章ソフトウェアテスト見積りの詳細テスト網羅性の尺度とテスト量見積り方法ホワイトボックステスト命令網羅率 (C0), 分枝網羅率 (C1), 条件網羅率 (C2) 開発規模基準テスト密度上記網羅率などからテスト量を算出ブラックボックステストユースケース網羅状態遷移網羅などテスト網羅率 =( 実際にテストするテスト項目の数抽出されうる全てのテスト項目の数 ) 100 テスト項目の抽出対象 : 要件定義設計書マニュアル類 13

第 4 章ソフトウェアテスト見積りの詳細合理的なテスト量削減方法 ( 例 : 直交表 ) ( 直交表が網羅する組合せ ) ( 全組合せ ) L4 直交表太字斜体下線テストNo.1 OFF OFF OFF 全組合せ太字斜体下線 L4 テストNo.1 OFF OFF OFF No.1 因子テスト No.2 OFF ON ON テスト No.2 OFF OFF ON テストNo.

15 第 4 章ソフトウェアテスト見積りの詳細合理的なテスト量削減方法 ( 例 : 直交表 ) ( 直交表が網羅する組合せ ) ( 全組合せ ) L4 直交表太字斜体下線テストNo.1 OFF OFF OFF 全組合せ太字斜体下線 L4 テストNo.1 OFF OFF OFF No.1 因子テスト No.2 OFF ON ON テスト No.2 OFF OFF ON テストNo.3 ON OFF ON テストNo.4 ON ON OFF OFF 太字 ON テストNo.3 OFF ON OFF テストNo.4 OFF ON ON No.2 テストNo.5 ON OFF OFF テストNo.6 ON OFF ON No.3 テストNo.7 ON ON OFF No.4 OFF 太字 ON 水準テスト No.8 ON ON ON ON ON ON ON 斜体 OFF OFF 下線斜体 OFF OFF 下線 2 機能間の組合せが全て存在している ( この状態を組合せ網羅率 100% と定義する ) 全組合せでは直交表に存在しない組合せも出現するよく見ると直交表では現れない No2, 3, 5 は単機能テスト内容 ( 出典 ) ソフトウェアテストにおける直交表の活用 ( 富士ゼロックス株式会社秋山浩一 ) 14

16 第 4 章ソフトウェアテスト見積りの詳細非機能要件の把握とテスト見積りへの反映資料非機能要件の把握確認とテスト見積りへの影響表 ( 保守性 1/4) 品質特性副品質特性詳細分析ニーズ ( 測定目的 ) 測定項目項目定義と測定方法測定尺度と導出式解釈組織統制要求定義要件定義設計プログラム作成システムテスト運用テスト当)プロセス保守運用 I S O ( 該見積変動対象 ( 該当 ) テスト量テスト生産性活動記録保有能力の評価 ( 故障原因の解析のため ) 故障原因解析能力の評価データログ実装率状況監視データ取得成功率診断機能実装率故障原因判明率故障の原因となった特定の操作を見つけるために記録することになっているデータ項目の中実際に記録されるデータ項目数の割合ソフトウェアの状態を記録したモニターデータについて保守担当者が取得しようとしたケースの中取得できた割合仕様で要求される診断機能のうち実装された診断機能の比率登録されている故障のうち原因が分かっている故障の数の割合実勢に記録されたデータ項目数 / 記録することになっているデータ項目数モニタデータについて 1- ( 取得できなかったケース数 / 全ケース数 ) 診断機能実装数 / 診断機能要求数 01 高いほど良い 01 高いほど良い 01 1-( 原因不明の故障数 / 高いほど良全故障数 ) い測定項目 01 * ( 約 180 項目 ) について高いほど良いテスト量およびテスト生産性に影響する項目を識別した保守性解析性解析容易性の評価故障解析時間保守ドキュメント充足故障解析にかかった平均時間解析容易性向上につながる保守ドキュメントについて実際に用意できているドキュメント数以下に具備候補の保守ドキュメント例を挙げる機能仕様書 DB クロスリファレンスデータ項目クロスリファレンストランザクションリファレンス変更手順書 ( 組織変更制度変更限度額変更等 ) 故障解析に要した時間数 / 故障数 ( 原因が判明した故障のみの統計値 ) 実際に用意できている保守ドキュメント数 0 短いほど良い *: 機能性信頼性使用性効率性保守性移植性運用性障害抑制性 0 重複しない内容で多いほど良いトレースツール利用率実装機能をトレースする際にトレースツールを利用できた機能数の割合ツールを用いてトレースできた実装機能数 / トレースした実装機能数 01 高いほど良いプログラムプログラムソースに組み込んだコソースコメンメント行の割合ト率 01 実装したコメント率 / 組織高いほど良で定めている標準コメント率い : 要求仕様の決定 ( ユーザの役割 ) 2: 要求を実現するための仕様提示 ( ベンダSE またはユーザSE) 3: 設計仕様への盛り込み ( および確認 ) 4: 実装結果の確認 5: 最終確認 JUAS 非機能要求仕様定義ガイドラインを利用 15

17 第 4 章ソフトウェアテスト見積りの詳細欠陥修正に関わる工数の把握欠陥修正量は作り込んだ工程での修正量と先行する工程の欠陥修正によって修正される量の総和 ( 下図参照 ) 欠陥修正工数 I = Σ 欠陥修正量 I 欠陥修正生産性 i さらに欠陥修正量を入力として再テスト工数を算出再テスト工数 I = Σ 欠陥修正量 I 再テスト生産性 i 16

18 第 2 部 1 日本ユニシスの事例品質強化への取り組みと留意点概要日本ユニシス社では V モデルと V&V( 検証および妥当性確認 ) を基本の考えとし大きく設計のフェーズとテストのフェーズに分けて遵守すべき手順と管理指標を設定また更なる品質強化へ向け改めてテスト技術にフォーカスするとともに Wモデル開発の推進に取り組んでいる本書では開発工程の大きな割合を占めコストに大きく影響するテストに焦点をあて見積り及びテスト進行中の品質制御と再テスト見積りに関し留意している事項について紹介 17

19 第 2 部 1 日本ユニシスの事例品質強化への取り組みと留意点標準的な開発モデル :V モデルと V&V( 検証および妥当性確認 ) ユーザ要求ユーザー要求システム稼動システム受入れテスト結果レビュー要件定義 / 論理設計機能の十分性操作性評価性能評価物理設計機能分割の正当性データフローの正当性制御の正当性要件定義 / 論理設計レビューテスト戦略計画レビューシステム受入れテスト計画レビュー物理設計レビュー統合テスト計画レビューシステム受入れ総合受け入れテストテスト計画計画結合テスト計画統合テスト計画単体テスト計画システム受入れテスト統合テストインタフェース確認負荷バランス調整目標値達成評価運用確認システム受入れテスト仕様レビュー統合テスト結果レビュー統合テスト仕様レビュープログラム設計詳細ロジックの保証性能目標の保証仕様書レビュー単体テスト計画レビュープログラム開発プログラム作成ロジックとソースコードの等価性確認ソースコードレビュー単体テストカバレッジ確認性能 / リソース確認単体テスト仕様レビュー単体テスト結果のレビュー 18

20 第 2 部 2 日立製作所の事例品質マップによるプログラムの早期品質確保概要日立社における品質指標を活用したテスト進行中における品質管理と再テスト見積りの事例特にプロジェクト自身の実績データを活用した品質マップによるプログラムの早期品質確保の事例を紹介品質マップとは縦列に現象を横列に原因などでマトリクスで表示して不良摘出の実績データを記入したもの本事例では品質マップによる不良の収束性を分析することにより追加テストの方針を導き出すことができた 19

21 C6 C2 カウンタ操SQL出力処理判定仕様誤り処理抜け編集T3TK3K4K3 K10S1K21 K1第 2 部 2 日立製作所の事例品質マップによるプログラムの早期品質確保品質マップによる分析とその評価結果の例原因規約定義設定現象面表示形式不正面項目出力不正1画表示不正結果不正エラーチェック不正画面遷移不正異常終了操作不能 1画 T T42 T52 KK 作KKK T92 不良の傾向不良の偏り画面表示形式項目出力不正表示不正摘出不足エラー処理不良が少ない評価結果画面形式や編集処理などの不良に偏っており判定処理などのロジックに起因した不良が摘出されていない ( テスト項目の十分性を確認 ) エラーチェック処理に関する摘出不足結果不正の不良の摘出不足 20

22 第 2 部 3 東京海上日動システムズの事例テスト品質と障害発生状況の分析概要ソフトウェアテストの品質とテスト工程の見積りの関係について社内プロジェクトの実績をもとにソフトウェアテストの品質と生産性や本番での障害発生状況に関する分析結果を紹介 ( 品質評価報告書の導入) テスト工程の見積りのブレを早期に是正する仕組みとしてテスト工程のなかで中間評価を行い品質を低下させる要因の芽を早期に発見し対応要員期間の確保などの調整を行うこと要件変更ペンディング状況などの残作業も明確にし開発チーム内外と調整を行う取り組みを紹介 21

23 第 2 部 3 東京海上日動システムズの事例テスト品質と障害発生状況の分析品質評価報告書の例タイトル会社名案件名あああああああああ規模 (Kstep) 25.0 作成日所属名本番予定日 2008 年 2 月 1 日工数 ( 人月 ) 25.0 開発主担当フルネーム案件 No XXXXXXXX 子案件 No XXXXXXXXYY 発注 No ZZZZZZ 開発主担当 TEL (Tel:1234) 全体評価信頼度成長曲線ペンディング件数未解決バグ件数仕様変更収束率全体評価レーダーチャート収束率総合評価障害率テスト密度テストケース消化障害密度今回前回テストケース数信頼度成長曲線月 1 日 10 月 8 日 10 月 15 日 10 月 22 日 10 月 29 日 11 月 5 日 11 月 12 日 11 月 19 日 11 月 26 日 12 月 3 日 12 月 10 日 12 月 17 日 12 月 24 日 12 月 31 日 1 月 7 日 1 月 14 日評価点評価指標項番評価指標前回今回中間品質評価最終品質評価指標実績値見解 X 月 X 日実施 X 月 X 日実施 1 テスト密度 ST 34.0 ( 件 /Kstep) 当初のケースの挙げ方では機能による偏りがあったため中間評価時に見直しを行ったその結果テ xxxx 件 /Kstep 2 4 OT 6.0 ( 件 /Kstep) スト密度は標準実績値より高くなったが十分なテストが出来たと評価する ( システム毎に設定 ) テストケース数 /Kstep テストケース設定の十分性評価合計 40.0 ( 件 /Kstep) 2 テストケース消化残数 / 総数残割合中間評価時は想定より早いペースでテストケース消化していたが障害摘出率が低かったテストケースの挙げ方に中間 : 残数 / 総数 ( 残 40%) 問題があると判断しケース見直しを実施しケースを追加した残ケースは大量テスト性能テストプレ本番環境で / % 最終 : 残数 (0)/ 総数のリモメン対象画面の確認のXケースであり現在最終確認中 X 月 X 日に完了予定テストケース数消化件数消化見通しを評価 3 障害密度 ST 1.2 ( 件 /Kstep) 平均値より少ないが単純改訂が多いためであり問題ないと判断する xxxx 件 /Kstep 4 4 OT 0.2 ( 件 /Kstep) 平均値より多いがテスト初期で環境不備によるものが多発したためバグ数としては平均的 ( システム毎に設定 ) 平均値より多いのはXX 機能の品質不足と判断し品質向上施策を追加実施し改善障害件数 /Kstep 問題摘出の過不足を評価合計 1.4 ( 件 /Kstep) 4 障害率 ST 3.5% 中間評価時は障害率が1% と低かったがテストの観点を見直しケースを追加してテストを実施した結果 xxxx% 3 4 OT 2.7% 標準的な数値となった ( システム毎に設定 ) 障害発生率が低いためテストケースを見直したが内容範囲とも問題なし単純改訂によるものと判断障害件数 / テストケース 100 テストケース設定内容の妥当性評価合計 3.4% 5 収束率 ST 100.0% 目標値 30 テストケースの消化に応じて障害検出も収束しており問題はない中間 :6070% 2 4 OT 80.0% 目標値 5 X 月 X 日の週前後に山があるがテストケース内容の見直しを行ったためであり問題ない状況と判断す最終 :100% る累積摘出件数 / 推定障害総数 ( 摘出目標値 ) 100 問題摘出十分性評価合計 97.1% 最終週バグ数 0 バグ摘出目標値はⅡ 期実績値 2 0 件 /Ks 開発規模とした 6 仕様変更収束率残数 / 総数残割合オーナテスト時に帳票のレイアウトについて仕様変更が発生全体への影響は少ないと判断し対応 ( 対応必須の要件変更残存数 / 12 0% を行い完了しており問題はない要件追加変更未解決件数 / 総発生件数仕様 FIX 度評価 7 未解決バグ件数残数 / 総数残割合未対応の障害はない中間 : 残数 / 総数 / 34 3% 未対応の障害は1 件あるが本番稼働はC/Oの2W 後であり対応は完了する見込最終 : 残数 (0)/ 総数画面項目の誤字があるが社内利用であり次回対応でオーナ了解済み残対策問題点件数 / 総発生件数 C/Oへの影響評価 8 ペンディング件数残数 / 総数残割合ペンディング事項は別紙記載のX 件いずれもC/O 直後には影響なし / 3 33% 未解決懸案事項 / 総発生件数 C/Oへの影響評価 9 総合評価テスト内容障害検出状況ともに問題ないと判断するテスト段階でXX 機能に要件変更がいくつか発生しその分障害の収束も遅れた追加テストを実施し問題ないレベルに達したと判断する上記評価項目の平均 ( 中間品質評価スポット品質評価 ) 4 点 : このままテストケースを消化し品質確保可能 3 点 : 品質確保可能だが若干の軌道修正が必要 2 点 : 品質確保不安有り追加テスト要 1 点 : 品質確保不十分工程見直し要 ( 最終品質評価 ) 4 点 : 品質確保十分懸案無し 3 点 : 品質確保したが調整懸案有り 2 点 : 品質確保不安有り追加テスト要 1 点 : 品質確保不十分やり直し累積バグ数 22

24 第 2 部 4 ジャステックの事例ソフトウェアの生産管理に基づくテスト見積り概要ジャステック社の見積モデルの基本アルゴリズムは生産物量見積り方式および生産性見積り方式から成り立ちさらにおのおのの方式において開発環境の違いや品質要求の多寡による変動を吸収する環境変数と呼ぶパラメータを導入しているソフトウェアのテストに焦点を当ててテスト見積りソフトウェアテストの管理およびソフトウェアテスト効率の改善などに対するジャステック社の取り組みを紹介 23

25 第 2 部 4 ジャステックの事例ソフトウェアの生産管理に基づくテスト見積り環境特性変動要素評価表 ( 生産性に影響する外部環境変数 ) の例主特性副特性変動要素要件定義ベースラインからの変動率 (%) 設計製作テスト業務特性業務ナレッジ顧客の開発対象業務に対する業務ナレッジが生産性に及ぼす影響ハードウェア特性安定度 / 信頼度 / 使用度システムもしくは製品となるハードウェアの安定度信頼度ソフトウェア特性安定度 / 信頼度 / 使用度システム / 製品に組み込む他社作成ソフトウェアもしくは COTS の安定度信頼度コミュニケーション特性顧客窓口特性意思決定能力 ( 期限遵守決定事項の覆る度合 ) 工期の厳しさ基準工期 ( 月 )=2.7 ( 人月 ) 1/3 に対し 30% 限度とした短期化度合コミュニケーション基盤開発拠点分散資料など情報共有電子媒体システム具備など物理的基盤充実度レビュー体制無駄なレビュー ( 重複多段階など ) の排除およびレビュー効率向上への工夫度合

26 第 2 部 5 日本電気 (NEC) の事例ソフトウェア品質会計制度の適用概要 NEC 社における品質指標をもとにした上流工程からの品質管理とソフトウェアテストの取り組みについて紹介 NEC 社では上流工程からの品質管理としてソフトウェア品質会計制度と呼ぶ管理手法を採用し上流工程からの欠陥管理ソフトウェアテストの計画ならびに評価を行っている本書ではソフトウェア品質会計制度を中心にその概要と上流工程下流工程それぞれの工程における適用方法適用効果について紹介 25

27 第 2 部 5 日本電気 (NEC) の事例ソフトウェア品質会計制度の適用開発工程における欠陥の作り込みと摘出 26

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

日経ビジネス Center 2

日経ビジネス Center 2 Software Engineering Center Information-technology Promotion Agency, Japan ソフトウェアの品質向上のために仕様を厳密に独立行政法人情報処理推進機構ソフトウェアエンジニアリングセンター調査役新谷勝利 Center 1 日経ビジネス 2012.4.16 Center 2 SW 開発ライフサイクルの調査統計データソフトウェア産業の実態把握に関する調査

２００７／５月 総会発表内容（見積り手法）

２００７／５月　総会発表内容（見積り手法）