上流工程（要件開発工程）から実践する qcd向上施策 ·...

© Hitachi Solutions, Ltd. 2012. All rights reserved.

上流工程（要件開発工程）から実践するQCD向上施策

株式会社日立ソリューションズエンベデッドソリューション本部


１. MICrewサービスから見えた開発現場の課題

２. 上流工程（要件開発工程）支援

３. ソースコード分析ソリューション


Contents



１. MICrewサービスから見えた開発現場の課題


１．１上位管理層と開発現場との乖離

33

Ｑ（品質）－出荷後の不具合やトラブルをなくしたい

Ｃ（コスト）－コスト削減が必要

Ｄ（納期）－競合他社より早く製品をリリースしたい

上位管理層の期待Ｑ（品質）

－バグが多発し、品質が収束しない

Ｃ（コスト）－手戻りによる追加作業多発で、費用増大

Ｄ（納期）－計画外の作業が多発し、納期遅延

開発現場は、バグ修正、トラブル対応等、対応しても、対応しても・・・

モグラたたき状態

開発現場の課題・悩み

表面的な課題対応だけでなく、根本原因対策が重要

そのためには、現場の真の課題抽出が重要

MICrew（エムアイクルー）サービス

上位管理層/現場との

乖離


１．２ MICrewサービスとは・・・

4

・コードチェッカ・トレーサビリティ向上・状態遷移表・テスト自動化・モデル駆動，ｅｔｃ

ツール

・ CMMI入門・品質管理・プロジェクト管理・ピアレビュー/テスト技法,ｅｔｃ

教育

・プロジェクト管理支援・品質保証支援・受託開発, etc

技術力補完

・品質/プロセス診断・ CMMI成熟度レベル判定・ソースプログラム検証・品質分析, ｅｔｃ

分析・診断

・クラウド分散開発環境・統合プロジェクト管理環境, etc

開発環境

・ SEPG支援・プロセスQA支援・ソフト調達プロセス改善

支援, ｅｔｃ

開発プロセス

組織力

技術力

マネージメント

改善力

組織力

基準・規則・手順

開発環境・設備

レビュー

コーディングデザイン

テスト・評価

ソフトウェア開発

開発現場の実態把握による課題抽出

開発現場のモノづくり力

向上

弊社ソリューション

弊社ソリューション

支援

支援


１．３ MICrewサービスの改善ステップ

5

初期診断効果分析施策実施施策決定施策提案詳細診断

４

・ヒアリングによる

初期診断の実施

・「初期診断結果」

のご報告

・改善活動の

振り返り

・実行結果に対する

定量的分析

・施策の実施

・改善活動の定着

・施策の決定

・優先順位付け

・施策計画の策定

・課題解決のため、

具体的解決施策

の提案

・データ分析による

詳細診断の実施

・「詳細診断結果」

のご報告

・具体的施策一覧

・改善施策計画書

アクション

成果物

「MICrew」サービスの改善ステップ

３５

・ヒアリング結果報告書・詳細診断分析提案

・詳細診断結果報告書

６１２

開発現場の課題抽出から

・施策結果報告書

・次期改善目標

・各種施策の成果物


１．４ MICrew初期診断サービス

6

ヒアリングで現場に潜む問題点、気付きを見つける

まずは開発現場の課題抽出から

【MICrew 初期診断サービス】

経験豊富な技術者と日立のモノづくりノウハウにより効率的に問題点を抽出

1週間程度で分析結果から具体的な改善策まで報告書を提出

『安価・短期間でのヒアリングにより、少ない現場負担で開発現場の課題を抽出』

経営幹部や開発現場（プロジェクトリーダ、開発担当者）へのヒアリングにより、開発の課題や問題点を抽出また、初期診断から得られた課題、問題点に対して、具体的な解決施策を提案


１．４ MICrew初期診断サービスから見えた課題

7

【事例】開発現場ヒアリングによる課題の抽出(プロセス観点より)

上流工程（特に、要件開発、要件（変更）管理）における課題が多く見受けられる・顧客要件を引き出し要件定義としてまとめる『要件開発/管理プロセス』が整備されていない

・『要件の妥当性』が十分に確認されていない

・要件変更に対する『影響範囲』の特定が行われていないため、デグレードが発生している

・・・等

CMMI成熟度レベル２

要件管理

CMMI成熟度レベル３

要件開発


１．５ MICrew詳細診断サービス

8

実績データの定量分析により、問題点を特定し、改善策を提案

【MICrew 詳細診断サービス】

● 実績データによる定量的な分析 → 真の問題点の発見● IPAのデータ白書や経済産業省の実態調査報告書等、

統計データとの比較で改善成果を数値で明確化

● 具体的な目標値 → 改善目標の共有、改善計画の推進

現場も理解しやすい

改善予算の確保

メリット

さらに

『ヒアリングに加え、プロジェクト実績データの分析により開発現場の課題を数値で把握』

顧客の開発現場のプロジェクト実績データ（ドキュメント、QCD等に関するデータ）に対して、統計的手法を用いて定量的に分析より具体的な課題・問題点を抽出し、これらの課題、問題点に対して具体的な解決施策を提案


上流（要件定義/設計）工程のバグが下流（テスト）工程に流出している・下流（テスト）工程に依存したバグの摘出が行われている

・本来摘出すべき上流（要件定義/設計）工程のバグの多くが見逃されている

上流（要件定義/設計）工程での品質確保が十分に行われていない

１．５ MICrew詳細診断サービスから見えた課題（１）

9

3.0%3.6% 7.0% 6.4% 19.6% 30.4% 30.0%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

経産省報

告書

企画・調査・要求獲得システム要求定義システムアーキテクチャ設計ソフトウェア要求定義ソフトウェア実装・単体テストソフトウェア結合・総合テストシステム結合・総合テスト

0.0

1.0

1.0

0.0

0.0

0.0

0.0

2.0

1.9

14.3

10.2

10.5

14.3

3.1

3.8

0.0

1.0

1.0

0.0

5.1

4.8

0.0

3.1

2.9

0.0

6.1

5.7

14.3

27.6

26.7

28.6

30.6

30.5

28.6

10.2

11.4

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Ver 01

Ver 02

合計

工程別バグ検出数

システム構造設計ユーザインタフェース設計プログラム構造設計内部レビュー外部レビュープログラミング/UT設計UTCTST設計STフリー操作市場指摘

※経済産業省商務情報政策局情報処理振興課発行「2010年版組込みソフトウェア産業実態調査報告書－プロジェクト責任者向け調査－」

約77％

約60％

【事例】工程別バグ検出数による課題の抽出

約23％

約40％

© Hitachi Solutions, Ltd. 2012 All rights reserved.

１．５ MICrew詳細診断サービスから見えた課題（２）

10

仕様漏

れ, 43%

ソースコー

ド,12%

管理・プ

ロセ

ス,12%

影響範囲

特定不

足, 11%

仕様変更漏

れ,6%

単体テスト, 6%

トレーサビリ

ティ,6%対応項目一覧

3%仕様理解不

足, 1%

【事例１】製品Ａの動機的要因の課題別分析

仕様漏

れ, 30%

流用母体

の品質26%

影響範囲特

定不

足, 15%

仕様理解不

足, 8%

管理・プロ

セス, 6%

ソースコー

ド, 5%

対応項目一

覧, 4%

仕様変更漏

れ, 4%トレーサビリ

ティ, 1% 単体テスト, 1%

【事例２】製品Ｂの動機的要因の課題別分析

テスト工程で発見されたバグの動機的要因・要件開発/管理プロセスの未整備、整備不足・仕様の理解不足、仕様漏れ・流用母体の品質が悪い（潜在不良が多発）・影響範囲の特定漏れによるデグレードの発生・流用母体の品質が悪く、潜在不良がテスト工程で多く見つかる

・・・等

【事例】バグの動機的要因分析による課題の抽出


１．６ MICrewサービスから見えた開発現場の課題（まとめ）

11

今回注目した現場の課題（４項目）

① 要件定義として行うべき作業/手順が不明確⇒ ２．１要件定義/要件管理プロセス定義の支援

・ CMMIモデル、弊社開発標準、等の活用

② 要件定義の内容に不備、不足が多い⇒ ２．２～２．４要件定義書の品質向上支援

・ IEEE８３０の活用・状態遷移表の活用・ピアレビューの活用

③ 流用母体（ソースコード）の潜在不良が顕在化⇒ 流用母体の品質向上

④ 要件変更時の影響範囲の特定漏れによるデグレード⇒ 影響範囲特定方法の改善による修正漏れ防止



２. 上流工程（要件開発工程）支援


２．１要件定義/管理プロセス定義支援

13

CMMI開発参照モデル、弊社開発ノウハウ（開発標準）等の活用により、要件定義/要件変更管理プロセス定義の整備を支援

要件定義の流れ（例）要件定義書（例）

要件定義書として必要な文書、

記載項目の定義

要件定義の作業手順

要件定義/管理プロセスのポイント・要件開発の計画策定（レビュー実施、要件確定/凍結時期、等）

・要件開発の体制と役割、責任分担、要件受付窓口等の明確化

・要求事項とその理由、および仕様事項との分離

・要件に対する見積もり条件の明確化・機能要件、非機能要件の抽出と、製品コンポーネント、モジュールへの（暫定）割り当て

・要件の妥当性確認（プロトタイプ、サンプル、シミュレーション、ユースケース、シナリオ等）

・変更管理方法（変更手順、要件分析、レビュー実施方法、承認ルート等）の明確化

・トレーサビリティ方法の確立・・・等


２．２要件定義書の品質向上支援 IEEE８３０

14

要件の確認観点チェックリスト（一部抜粋）

①正当であること：要件の出所や根拠が明確であること②曖昧でないこと：文章表現に曖昧さがなく、誰が要件を読んでも一意に解釈

できること③完全であること：要件定義書で定義すべき品質特性のうち機能性について

必要十分な項目を網羅していること④矛盾がないこと：要件の文書内部や外部要件に矛盾を含んでいないこと⑤実現が可能であること：要件がシステム稼働環境における既知の性能や

制約の範囲内であること⑥検証できること：要件を満たしているか確実に判断できる手段があること⑦変更が容易であること：要件の文書は、構造や様式を維持したまま容易に

変更できること⑧追跡が容易であること：要件の発生源へたどれること(上流工程）⑨重要性・変更可能性がランクづけられていること：要件に優先順位がつけら

れていること

IEEE８３０（ソフトウェア要求に対する推奨プラクティス）を活用して、要件定義書の未確定要素・曖昧性を確認


２．３要件定義書の品質向上支援状態遷移表（１）

15

■要件漏れを防ぐための設計手法（状態遷移表）

イベントにより，状態が変化する状況を，マトリクス形式で表現

状態とイベントの組み合わせで，システムの振る舞いを設計

仕様の可視化に効果的な設計手法

Ｓ状態１状態２状態３

イベント０１２

イベントＡ０状態２状態２

処理Ａ処理Ｅ

イベントＢ１状態３

処理Ｂ

イベントＣ２― 状態１

処理Ｄ処理Ｃ


２．３要件定義書の品質向上支援状態遷移表（２）

16

■ 仕様の検討漏れ／抜けを発見しやすい

全ての状態とイベントを網羅的に表現

表の空欄箇所は，仕様の検討が漏れている箇所

フローチャートや状態遷移図では，異常/例外ケースが漏れやすい

空欄（未検討）箇所が、仕様として必要かどうかを検討することが重要

状態２

状態３

状態１

イベントＡ／処理Ａ

イベントＢ／処理Ｂ

イベントＣ／処理Ｃ

イベントＣ／処理Ｄ

S 状態１状態２状態３

E ０１２

イベントＡ０状態２

？？処理Ａ

イベントＢ１？状態３

？処理Ｂ

イベントＣ２？― 状態１

処理Ｄ処理Ｃ

状態遷移図状態遷移表


２．３要件定義書の品質向上支援状態遷移表（３）

17

■ 上流工程での品質確保

上流工程において、状態遷移表による仕様検討漏れの早期摘出により、

深刻な仕様不良を下流（テスト）工程に持ち込まない

【ご参考】シミュレータ（ツール活用）による状態遷移表の動的検証により、

不良修正に伴う、手戻り負荷/コストを大幅削減

コーディング設計要件定義テスト

従来の開発

状態遷移表による開発

大きな手戻りが発生

要件漏れの早期摘出安定した品質

仕様不良


２．３要件定義書の品質向上支援状態遷移表（４）

18

・表形式で網羅的に状態を表現

⇒ 実装の抜けや漏れを防止

・状態遷移表(モデル)のシミュレーション実行

⇒ 上流工程での動作確認による早期品質向上

効果1: 手戻り工数の削減

状態遷移表からソースコードの自動生成機能により

・コーディングミスによる欠陥を削減

・コーディング工数の削減

効果2: 欠陥の削減

A社事例1)

コーディングミス

48%減

構造設計以降の

手戻り工数

43%減

1)出典：新海良一、他「組込みソフトウェア開発プロセス改善の取り組みと支援サービス」日立評論Vol.91(2009.5)

状態遷移表、モデリングツールを活用することにより、上流工程で仕様漏れを防ぎ、下流工程でのバグの発生を抑えることを実現！！

【事例】状態遷移表とモデリングツールの導入事例とその効果


【ご参考】状態遷移表とモデリングツール活用のメリット

19

■ システム保守性の向上

状態遷移表からソースコードを自動生成することで、

設計書とソースコードの内容を一致させることが可能

自動生成

状態遷移表Ｃソースコード

仕様書とソースが一致

シミュレータの自動試験機能を利用し、

エンハンス時のリグレッションテストを効率的に実施

ログ出力自動試験

状態遷移表結果ログ

繰り返し試験が可能

試験用ドキュメント

© Hitachi Solutions, Ltd. 2012. All rights reserved. 20

– 弊社の品質方針

– 別の言葉で言い換えると

上流工程での品質確保

テストの前に勝負を決めろ！

２．４要件定義書の品質向上支援ピアレビュー（１）

ピアレビュー手法の導入により、要件定義書の品質を向上

レビューは単に内容を読み合わせるだけでなく、要件定義書としての不明瞭な点、不足項目、不備等の潜在的な問題点やバグを効率的に摘出することが重要

解決策は、ドキュメント（要件定義書）への『レビュー』の実施


２．４要件定義書の品質向上支援ピアレビュー（２）

解決策は、ピアレビュー（Peer Review）の実施– ペアレビュー（2人でやるレビュー？）ではない

– ピュアレビュー（純粋レビュー？）でもない

– もちろんビアレビュー（枝豆で一杯？）でもない

• ピアレビューとは？

– × 承認レビュー

– △ 同僚(Peer) が実施するレビュー

– ○ 欠陥摘出・削除を目的に行う成果物に対する技術的なレビュー

• ピアレビューの実施により・・・・要件定義としての不備や不十分な記述を特定・有識者やユーザの参加により、専門的な観点、利用者目線で要件を確認

・成果物品質の安定化（レビューパフォーマンス分析による）


２．４要件定義書の品質向上支援ピアレビュー（３）

22

計画概要説明

机上レビュー

ミーティング

修正

フォローアップ原因分析

レビュー資料一式

課題ログ

インスペクション実施報告書

プロセス改善提案

実施計画、役割、レビュー手法等を

決定

指摘の７０％以上は、机上レビューで摘出可能

机上レビューの指摘に対して議論

指摘の分析を通じて、再発防止とプロセスへの反映し、改善を組織へ展開

ピアレビュー（フェイガンインスペクション）の実施順序


レビューNo. 準備時間時間人数サイズ指摘件数内改善要件数1 3 13 10 120 19 82 2 3 9 40 2 03 2 35 6 60 2 24 2 15 8 30 9 45 2 2 9 20 1 16 3 7 8 80 13 87 3 2 8 30 2 28 3 5 8 200 11 109 2 2 7 30 3 310 3 3 7 50 5 511 2 3 6 40 5 512 2 3 5 50 12 613 3 5 7 80 6 5

レビューデータ

レビュー速度

指摘密度

（分析例）8件目のレビュー速度が管理上限を超えている。原因を調査して、必要に応じて再レビューする。

２．４要件定義書の品質向上支援ピアレビュー（４）

ピアレビューパフォーマンス分析による成果物品質の向上

ピアレビューの実施状況を定量的分析

レビュー品質の安定化による成果物品質向上を目指す


２．４要件定義書の品質向上支援ピアレビュー（５）

24

ピアレビュー実施の推進により、要件定義書の不備や不具合を上流工程で早期に洗い出し、下流（テスト）工程へのバグの流出を避けることができる

ピアレビューテスト

修正工数が半減

テストでの欠陥発見・修正に比べピアレビューでは約２倍の効率化が可能

ﾋﾟｱﾚﾋﾞｭｰｼｽﾃﾑﾃｽﾄ出荷後

1 $13 $

92 $ｽﾍﾟｰｽｼｬﾄﾙ搭載

ｿﾌﾄｳｪｱﾌﾟﾛｼﾞｪｸﾄ

[１件当り修正コスト]

②他社事例①弊社事例

①出典：小室睦、男澤康、木村好秀「開発現場の実態に基づいたピアレビュー手法改善と改善効果の定量的分析」 SEC journal創刊号②出典：Karl E. Wiegers 著、大久保雅一監訳「ピアレビューー高品質ソフトウェア開発のためにー」

【事例】ピアレビュー導入事例とその効果


２．５上流工程支援導入事例と効果

25

組織プロセス定義の再整備・浸透、およびピアレビューの導入により、

下流工程（SQA）へのバグ流出を大幅に削減し、バグ率改善も実現

【事例】不具合発見工程の変化

SQA

結合

製造・単体

調査・設計

設計不具合摘出率：８３％

改善前（2006/8）改善後（2008/2）

設計不具合摘出率：４３％

© Hitachi Solutions, Ltd. 2012. All rights reserved.© Hitachi Solutions, Ltd. 2012. All rights reserved.

【ご参考】プロセス改善支援サービス

26

・抽出課題に対する対策案、その実施順序（優先度）をどう考えたらよいかわからない。・組織として改善を推進・定着させるための計画や実現案・具体策をどう作ればよいかわからない。・組織としてのプロセスを定義・定着させたいが、どのように作成、推進すればよいかわからない。・改善作業を進めているが、要員リソースが足りず、どのような体制が必要かもわからない。

・課題の分析や現場の課題の具体的な解決策を検討し、開発現場とともに取り組みます。・組織の事業目標を明確にし、改善計画（組織や仕組み、必要な作業など)を策定し、計画的に課題解決を推進します。・組織の文化や現場の実態、実情を尊重した、現場重視の継続性のあるプロセスの構築を目指します。・改善のノウハウを持つ弊社スタッフが直接現場に入り込み、現場に根付いた改善活動を推進します。

効果

課題

サービス概要（特徴）

プロセス改善支援サービス効果的なプロセス改善活動(立ち上げから定着まで)をご支援します！

・開発ライフサイクルの全フェーズにわたってご支援いたします

改善のサイクル・改善推進組織立上げ

・課題の解決策、優先度・

重要度を決め、改善計画

を策定

組織の実情を尊重した

改善策の検討・提案

MICrew診断サービス

により課題を明確化

組織と共に

改善を実施

改善結果の

評価・分析・報告

評価・分析から得られた結果を改善活動に

フィードバック

計画

実行

アクション

立上げ・改善計画チェック


ピアレビューは、欠陥除去を目的に行う、成果物に対する技術的なレビューです。

下流工程から上流工程に前倒しで欠陥摘出が可能となり、欠陥修正のコストを大幅に削減できます。

本講座によって、ピアレビューの効果的な実施方法を学習できます。

【ご参考】ピアレビュー技法教育

27

上流工程での品質確保を目指した、ピアレビュー技法の習得

講義内容

◆講義（１日）・ピアレビューとは何か、レビューの重要性・代表的な手法とその使い分け・フェイガン・インスペクション・良いピアレビューを実施する秘訣

◆演習（１日）・実際のチームで参加し、実際の成果物（設計書や

ソースコードなど）を対象にピアレビューを実施する

◆現場経験豊富なインストラクタが、現場の視点でトレーニングを実施いたします。◆受講者が実際に作成した成果物を演習の教材として使用するため、効果的なレビューを体感でき、受講のその日から効果が現れます。

講座の特長

27



３.ソースコード分析ソリューション


３．１流用母体（ソースコード）に関する課題の解決施策

29

要件変更時の修正漏れをなくしたい

３．７影響範囲の特定による修正漏れ防止

抽出した課題解決施策必要となる分析アプローチ

流用母体の潜在不良をなくしたい

３．４潜在不良の修正による流用母体の品質向上

ソフトウェアフットプリントを圧縮したい

デッド関数の削除によるフットプリントの圧縮

リファクタリングへの活用流用母体の保守性を向上させたい

３．６「クローン分析」による類似ロジックの抽出

３．５「構造分析」による依存関係の明確化

３．３「品質分析」による潜在不良の特定

「複雑度分析」による関数の複雑度の明確化

「デッドロジック分析」によるデッド関数の特定

© Hitachi Solutions, Ltd. 2012. All rights reserved.© Hitachi Solutions, Ltd. 2012. All rights reserved. 30

３．２ソースコード分析ソリューション全体

ソースコードを分析し、「流用母体の品質向上」と

「要件変更時の修正漏れ」を防ぎます

３．３品質分析

複雑度分析

３．６クローン分析

移行性分析

デッドロジック分析

３．５構造分析

類似ロジックを抽出

依存関係明確化

潜在不良の特定


３．３品質分析（１）

31

・品質分析とは、

機能やモジュール毎の品質傾向を明確にします。

潜在不良を抽出し、各不良についての詳細分析を行い、即時修正の要否を判断します。

anyWarp CodeDirector 画面イメージ

流用母体の潜在不良を抽出し、流用母体の品質向上につなげます。


３．３品質分析（２）レポート例

32

・品質分析（レポートの一例）

機能規模評価項目

設計上の問題保守性性能移植性信頼性

A機能 30.2 kstep ○ △ × ○ △

B機能 25.0 kstep △ × ○ △ ×

C機能 101.4 kstep ○ ○ △ ○ ○

：：：：：：：

機能毎の品質傾向分析

欠陥の種類メモリリーク場所 /PowerMonitor12/src/os/win32/readdir.c: 48説明 27 行目で malloc() により確保されたメモリ領域のポインタは、23 行目で定義されたローカ

ル変数 filespec へ代入されます。このメモリ領域を参照するポインタは他にないため、48行目で filespec がスコープ範囲を抜けると、このメモリ領域へのアクセスは不可能（メモリは確保されたままだが、到達不可能）になります。

条件 39 行目の条件式 (handle = _findfirst(filespec, &(dp->fileinfo))) < 0 が

false と評価されたときソースコードの抜粋20 API_EXPORT(DIR *) opendir(const char *dir)21 {22 DIR *dp;23 char *filespec;…27 filespec = malloc(strlen(dir) + 2 + 1);28 strcpy(filespec, dir);

:37 dp->dir = strdup(dir);3839 if ((handle = _findfirst(filespec, &(dp->fileinfo))) < 0) {40 if (errno == ENOENT) {41 dp->finished = 1;

:45 free(filespec);46 }47 dp->handle = handle;48 return dp;49 }

特定された潜在不具合

機能毎の品質傾向分析

重点的なテストの実施、効率的な品質向上施策

の実施が可能

特定した潜在不具合に対して、実際に不具合動

作を引き起こす際の条件などを記載した詳細レポート報告


３．４品質分析による流用母体の品質向上

33

欠陥の種類メモリリーク場所 /PowerMonitor12/src/os/win32/readdir.c: 48説明 27 行目で malloc() により確保されたメモリ領域のポインタは、23 行目で定義されたローカ

ル変数 filespec へ代入されます。このメモリ領域を参照するポインタは他にないため、48行目で filespec がスコープ範囲を抜けると、このメモリ領域へのアクセスは不可能（メモリは確保されたままだが、到達不可能）になります。

条件 39 行目の条件式 (handle = _findfirst(filespec, &(dp->fileinfo))) < 0 が

false と評価されたときソースコードの抜粋20 API_EXPORT(DIR *) opendir(const char *dir)21 {22 DIR *dp;23 char *filespec;…27 filespec = malloc(strlen(dir) + 2 + 1);28 strcpy(filespec, dir);

:37 dp->dir = strdup(dir);3839 if ((handle = _findfirst(filespec, &(dp->fileinfo))) < 0) {40 if (errno == ENOENT) {41 dp->finished = 1;

:45 free(filespec);46 }47 dp->handle = handle;48 return dp;49 }

品質分析より特定された潜在不具合

【品質分析結果】特定した潜在不具合に

対して、実際に不具合動作を引き起こす際の条

件などを記載した詳細レポート

Original.c

バグ

潜在不良の少ないソース

潜在不良を修正

品質分析により明確になった潜在不良の修正を実施することで流用母体の潜在不良を軽減し、流用母体の品質を向上できます。

派生開発のベースライン


３．５構造分析（１）

34

・構造分析とは、

FUNC_MAIN

FUNC_SUB2FUNC_SUB1

FUNC_SUB4 FUNC_SUB5

Class A

Class C Class DClass B

Class D

プログラム間に存在する要求依存関係および提供依存関係を明確にし、要件変更時の修正による影響範囲を特定し、修正漏れを防ぎます。

クラスの依存関係抽出イメージ関数のコール関係抽出イメージ

C言語の関数コール関係、C++言語などのオブジェクト指向型言語のクラス依存関係を抽出します。

抽出した情報はマトリクス化し、プログラム間に存在する要求依存関係および提供依存関係を明確にします。


３．５構造分析（２）レポート例

35

・構造分析（レポートの一例）

# 1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

ファイル

規模(単体)

37

37

57

44

44

151

39

244

722

568

206

391

638

445

380

提供file数

0 0 0 0 0 0 1 1 3 1 1 1 7 1 1

要求file数

規模(関連)

0 0 0 0 0 0

151

445

1651

445

445

445

2956

391

445

1 File1.c 37 0 0

2 File2.c 37 0 0

3 File3.c 57 0 0

4 File4.c 44 0 0

5 File5.c 44 0 0

6 File6.c 151 1 39 ●

7 File7.c 39 0 0

8 File8.c 244 1 638 ●

9 File9.c 722 1 638 ●

10 File10.c 568 2 1360 ● ●

11 File11.c 206 1 638 ●

12 File12.c 391 2 1083 ● ●

13 File13.c 638 1 722 ●

14 File14.c 445 7 3149 ● ● ● ● ● ● ●

15 File15.c 380 1 638 ●

# モジュール単体規模

要求提供

依存ファイル数

依存規模

合計規模(単体+依存)

増加率依存

ファイル数依存規模

合計規模(単体+依存)

増加率

1 module A 5963 1 769 6732 113% 0 0 5963 100%

2 module B 510 2 901 1411 277% 0 0 510 100%

3 module C 1647 0 0 1647 100% 0 0 1647 100%

4 module D 8232 9 7928 16160 196% 0 0 8232 100%

5 module E 8562 0 0 8562 100% 66 90440 99002 1156%

関数コール関係マトリクス

モジュール別依存関係

例えば、ファイル8 はファイル13 の関数を

呼び出し

呼び出し関係を関数別に視える化

モジュール毎の依存度・依存傾向が把握可能

module C は要求依存・提供依存が共に存在しておらず、独立性が高い事

がわかる


ファイル間や関数間のコードクローン関係を抽出します。

抽出した情報はマトリクス化し、プログラム間に存在する類似処理関係を明確にします。

３．６クローン分析（１）

36

・クローン分析とは、

Original Func()

Original.c Clone.c

Clone Func()

クローン

クローン

クローン分析の画面イメージファイル・関数単位のクローンペアを抽出

ファイル間や関数間に存在するコードクローン関係を明確し、要件変更時の修正対象と類似する処理への修正漏れを防ぎます。


３．６クローン分析（２）レポート例

37

・クローン分析（レポートの一例）

ファイル 1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

1 file1.c * 100% 100% 100% 100%

2 file2.c 100% * 100% 100% 100%

3 file3.c * 100% 100%

4 file4.c 100% * 100%

5 file5.c * 99%

6 file6.c 100% 100% * 100% 100%

7 file7.c 100% 100% *

8 file8.c 100% 100% 100% * 100%

9 file9.c * 100%

10 file10.c 100% *

11 file11.c 100% 100% 100% 100% *

12 file12.c * 71% 100%

13 file13.c 71% * 71%

14 file14.c 100% 71% *

15 file15.c 99% *

関数情報クローン関数情報クローン率ID ファイル名関数規模 ID ファイル名関数

41 File1.c void FuncA() 20 step 42 File2.c void FuncB() 99%

42 File2.c void FuncB() 20 step 41 File1.c void FuncA() 99%

190 File3.c void FuncC() 25 step 4528 File6.c void FuncI() 99%

191 File3.c void FuncD() 55 step 4529 File6.c void FuncJ() 100%

193 File3.c void FuncE() 36 step 4531 File6.c void FuncK() 99%

194 File4.c void FuncF() 24 step 4532 File7.c void FuncL() 99%

196 File4.c void FuncG() 30 step 4534 File7.c void FuncM() 99%

205 File5.c void FuncH() 90 step 4554 File8.c void FuncN() 100%

ファイル11 はファイル6 の100%クローンファイルであることを示している

ファイル間のクローン関係を示すマトリクス

関数間のクローン関係を示す一覧

FuncJ() は FuncD() の100%クローン関数

であることを示している


３．７構造分析とクローン分析による要件変更時の修正漏れ防止

38

Original.c Clone.c

クローンバグバグ

コードクローンではバグごとクローン化されるケースが多い

SubModule.c

依存関係

依存関係

コードクローンでは、ロジカルな依存関係が存在しないケースが多く、

プログラムをトレースするだけでは修正漏れとなってしまう危険性がある

・クローン分析結果より

修正時やソースコードレビュー時に、クローン分析結果を参照することで、

コードクローンへの修正漏れを防止する事が可能

修正個所と依存関係・提供関係があるプログラム、および類似処理のプログラム修正可否を検討することで、影響範囲を特定し、要件変更時の修正漏れを防ぎま

す。

# 1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

ファイル

規模(単体)

37

37

57

44

44

151

39

244

722

568

206

391

638

445

380

提供file数

0 0 0 0 0 0 1 1 3 1 1 1 7 1 1

要求file数

規模(関連)

0 0 0 0 0 0

151

445

1651

445

445

445

2956

391

445

5 File5.c 44 0 0

6 File6.c 151 1 39 ●

7 File7.c 39 0 0

8 File8.c 244 1 638 ●

9 File9.c 722 1 638 ●

10 File10.c 568 2 1360 ● ●

File13.c に修正を実施する際、提供依存の関係が存在する

ファイルは影響を受ける可能性が高い

・File8.c, File9.c, File10.c

影響範囲の調査対象とする

・構造分析結果より


【ご参考】デッドロジック分析（１）

39

・デッドロジック分析とは、

FUNC_MAIN

FUNC_SUB2FUNC_SUB1 FUNC_SUB3

FUNC_SUB4 FUNC_SUB5 FUNC_DEAD

上位関数が存在しない

C言語の関数コール関係を抽出いたします。

上位関数を辿っていき、どこからもコールされていない関数（デッド関数）を抽出いたします。

ビルド構成情報（makeファイルなど）の解析を行い、ビルド対象となっていないファイル・参照されていないヘッダー（デッドファイル）の抽出をいたします。

上位関数が存在しない関数（デッド関数）を抽出

どこからもコールされていない関数・ファイルを明確にし、ソフトウェアフットプリントを圧縮します。


【ご参考】デッドロジック分析（２）（レポート例）

40

・デッドロジック分析（レポートの一例）

# ファイル名関数規模

1 File1.c FuncA(char*,int,long long) 210 step

2 File2.c FuncB(PARAMINFO,int*) 19 step

3 File3.c FuncC(char*,int,long long) 210 step

4 File4.c FuncD(PARAMINFO,int*) 19 step

5 File5.c FuncE(char*,char*) 4 step

# ファイル名規模

1 DeadFile1.c 30 step



4 DeadFile4.h 109 step

5 DeadFile5.h 42 step

上位関数が存在しない関数（デッド関数）と規模の一覧。

ビルド対象となっていないファイルと規模

どこからも読み込まれていないヘッダーと規模

デッド関数一覧

デッドファイル一覧


【ご参考】デッド関数の削除によるフットプリントの圧縮

41

・デッドロジック分析によるソフトウェアフットプリントの圧縮

# ファイル名関数規模

1 File1.c FuncA(char*,int,long long) 210 step

2 File2.c FuncB(PARAMINFO,int*) 19 step

3 File3.c FuncC(char*,int,long long) 210 step

4 File4.c FuncD(PARAMINFO,int*) 19 step

5 File5.c FuncE(char*,char*) 4 step

分析結果を基にデッドロジックを除去

プログラムサイズが縮小される事で、フットプリントの圧縮が可能。

デッド関数（デッドロジック）を削除することで、プログラムサイズ・フットプリントの圧縮が可能です。

・デッドロジック分析結果より


【ご参考】複雑度分析

42

・複雑度分析とは、

結果をリファクタリングなどにつなげることができます。

また、構造化分析の結果を併せることにより、エンハンスの影響範囲の複雑度を把握して、エンハンスの潜在的なリスクやテスト工数、フィジビリティ（実現可能性）などを事前に洗い出すことが可能になります。

anyWarp CodeDirector 画面イメージ

関数の複雑さを明確にし、構造的な問題解決につなげます。


【ご参考】複雑度分析（レポート例）

43

・複雑度分析（レポートの一例）

ディレクトリ毎の複雑度

循環的複雑度

散布図（複雑度・step数）

複雑度・30以上：構造的なリスクあり・50以上：テスト不可能・75以上：修正が困難で、誤修正を

引き起こす可能性が高い


【ご参考】リファクタリングへの活用

44

・リファクタリングへの活用

要求依存

多少

提供依存多 ④ リスク：大、投資対効果：大 ③ リスク：中、投資対効果：中

少 ② リスク：中、投資対効果：中 ① リスク：小、投資対効果：小

クローン率の高い組み合わせのソースについて、依存関係を併せて検討することで、リファクタリングの容易さ・投資効果を図ることができます。

影響範囲の少ない箇所や複雑度の高い箇所から、複数の段階に分けてリファクタリングを実施する、などのリファクタリング計画の足がかりとなります。

・構造分析・クローン分析の結果より

パターン③

パターン①

パターン②

パターン④

パターン①

ファイル規模要求依存ファイル数

提供依存ファイル数

クローンファイル

規模要求依存ファイル数

提供依存ファイル数

クローン率

File1.c 100 0 3 File2.c 100 0 3 100%

File3.c 150 0 0 File4.c 150 0 0 100%

File3.c 150 0 0 File5.c 145 0 0 90%

File6.c 80 2 0 File7.c 120 2 0 40%

File8.c 110 4 8 File9.c 115 1 6 70%

関数の依存関係、クローン率により、リスク・投資対効果を評価し、リファクタリングの

対象を選定

保守性向上のため、複雑度の高い関数順に、関数の分割や

単純化を検討



END

株式会社日立ソリューションズエンベデッドソリューション本部

・CMMIはカーネギーメロン大学によってアメリカ合衆国特許商標庁に登録されています。・ ZIPCはキャッツ株式会社の登録商標です。・その他記載されている会社名、製品名は、それぞれの会社の商号、登録商標または商品名称です。・本書に記載の製品を輸出される場合は、外国為替および外国為替法並びに米国の輸出関連法規をご確認の上、必要な手続きをお取り下さい。なお、ご不明な場合は、弊社営業にお問合せ下さい。

上流工程（要件開発工程）から実践する qcd向上施策 ·...

Documents