JaSST'10 Tokyo テクノロジーセッション資料

ソース解析ツールの活用による品質確保と全体品質の管理・統制方法

2010年
2010年1月28日
28日
株式会社富士通ソフトウェアテクノロジーズ
Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED目次
第１部 ソフトウェア品質の実態と課題
１．１ ソフトウェア品質の実態
１．２ 品質確保のための課題

第２部 プログラム品質の確保とソース解析ツールの活用
２．１ プログラム品質確保のためのアプローチ
２．２ ソース解析ツールの活用

第３部 プログラム品質の管理／統制
３．１ 管理／統制の必要性
３．２ プログラム品質の評価と見える化
３．３ 管理／統制の実施

第４部 製品・サービスのご紹介
４．１ PGReliefご紹介
４．２ ソース診断サービスご紹介
1

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED第１部 ソフトウェア品質の実態と課題

2

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED１．１ ソフトウェアの品質の実態3

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED出荷後の製品品質

不具合を起こしていない
製品は1/3だけ、2/3の製品で1回以上の不具合を起こしている

4

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED製品不具合の原因

製品出荷後の不具合
原因の8割は、ソフトウェアの不具合

5

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDソフトウェア不具合を作り込む原因工程

ソフトウェア不具合の半数を、実装工程で作り込んでいる

6

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED実装工程での問題(1/2)

多くのエンジニアが係わる↓
ソースコードの書き方がバラバラになる

エントリレベルのエンジニアが多い↓
経験・スキル不足で、ソースコードにミスが多い

7

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED実装工程での問題（2/2）

実装工程は不具合を最も作り込みやすい工程。にも係わらず、他工程とレビューの実施に差がない↓
実装時のレビューが十分でない

8

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED１．２ 品質確保のための課題

9

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED実装工程での問題と解決策
問題点：ソースコードにミスが多いソースコードの書き方がバラバラになるソースコードのレビューが十分でない

課題：

経験者のノウハウの活用が必要
レビュー効率化のために、統一した書き方が必要
レビューを十分に行うルールや体制が必要

解決策：

経験者のノウハウや統一した書き方を規定したコーディング規約の作成
コーディング規約の遵守をチェックする体制づくり

補足：実装工程での問題は、製品要求、設計、開発環境等にも起因するものがありますが、今回は「ソースコードの作成」に着目しています。
10

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED第２部 プログラム品質の確保とソース解析ツールの活用

11

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED２．１ プログラム品質確保へのアプローチ
１） コーディング規約のあり方

12

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDコーディング規約の実態
コーディング規約はあるが、運用が形骸化しているプロジェクトが多いのでは？
命名や書式に、こだわり過ぎている守れないルールになっている
チェックしづらいルールになっている
昔に作成したままで、現在の開発に合った更新がされていない全社ルールのままで、個々のプロジェクトに合っていない

現状のコーディング規約は、遵守してもソースコードの品質向上につながらない
13

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDコーディング規約の目的① 要件・仕様との整合
プロジェクトの要件や設計仕様をプログラム中に具現化するため② 信頼性・可読性・保守性の向上
プログラムの書き方を規定することによって、プログラムの信頼性・可読性・保守性を向上するため③ スキル移転
コーディング規約の中に推奨する書き方や注意事項を記載する
ことによって、経験の浅い開発者のスキルを向上するため

14

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDコーディング規約が保持すべき内容① 適用範囲などの全体情報
本コーディング規約の適用範囲を規定した情報、管理者情報および改版履歴などの全体情報を記載する。

② コーディング規約・作法
命名規約やプログラムスタイルなど、プログラムを作成する際の決め事を記載する。

③ 推奨・注意事項
推奨する書き方や誤りを未然に防ぐための注意事項を記載する。

15

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED書き方が統一されたソースコードの利点
書き方利点
ソースコードを理解しやすい
処理を誤解しないため、誤った修正を防止できる。
レビューが効率化され、バグ検出に集中できる。

名前の付け方式や文の書き方

ソースコードを修正しやすい
処理がまとまっているため、修正漏れを防止できるインタフェイス変更が容易のため、類似コードが増えない。

ライブラリの使い方
関数インタフェース

16

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDコーディング規約の適用
計画書、要件定義書

規約作成① 本プロジェクトで考慮すべき要件や仕様をコーディング規約としてまとめる

コーディング規約

コーディング

ソース
プログラム

レビュー

ソース
プログラム

PDCA

設計書

③ 機能だけでなく、コーディング規約を遵守しているかもレビュー② 設計書だけでなく、コーディング規約も常に参照しながらコーディ
ング遵守監視17④ コーディング規約の遵守状況を監視して、改善していく
Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED２．１ プログラム品質確保へのアプローチ
２） コーディング規約の作成

18

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDコーディング規約の作成手順①コーディング規約の作成方針の決定②作成方針に沿ったルールの選択③適用範囲の決定④適用を除外するルールの選択
19

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED①作成方針の決定
ソースコードがどう書かれるべきかの方針を、プロジェクト要件から検討し、決定する■製品特性
人命に係わる製品 ⇒不具合発生時の被害を抑えているソースコード24時間稼動製品 ⇒異常停止させないソースコード■開発体制
新人が多い⇒バグ（過去の失敗）がないソースコード

ベテランが多い ⇒引継ぎを意識した分かりやすいソースコード■今後の展開カスタマイズ要求が多い ⇒機能拡張を考慮したソースコード

20

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

②作成方針に沿ったルールの選択(1/2)■既にコーディング規約がある場合
作成方針と照らし合わせて、ルールの変更・削除を実施
一般的なコーディング規約（※）と比較し、抜けているルールがあればルールを追加■コーディング規約がない場合
作成方針に基づいて、一般的なコーディング規約（※）から、プロジェクトに合ったルールを選択※一般的なコーディング規約（C/C++）
・IPA/SEC ESCR・MISRA C/C++・GNU Cogding Standards
・JSF Air Vehicle – C++ Coding Standards
・Effective C++、More Effective C++
・C++ Coding Standards

21

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

②作成方針に沿ったルールの選択(2/2)
コーディング規約から、プロジェクトに合ったルールを選択(例：IPA/SEC
例：IPA/SEC ESCR)

初期化漏れによる異常終了を防止したい

品質概念

作法

ルール

選択

信頼性

領域は、初期化してから使用する

自動変数は宣言時に初期化する。または使用する直前に初期値を代入する。

○

const型変数は、宣言時に初期化する。

○

初期化は過不足無いことがわ
かるように記述する

要素数を指定した配列の初期化では、初期値の数は、指定した要素数と一致させる。

○

列挙型のメンバの初期化は、定数を全く指定しない、すべてを指定する、または最初のメンバだけを指定する、のいずれかとする。

×

構造化プログラ
ミングを行う(1)goto文を使用しない(2)goto文は、多重ループを抜ける場合とエラー処理に分岐する場合だけに使用する○(2)を選択

保守性

continue文を使用してはならない

×

ソースコードを読みやすくしたい
22

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

③適用範囲の決定
開発スタイルに合わせたルール決めが肝要。
開発スタイルスクラッチ開発
新規
流用開発

保守

改造開発

適用方針
コーディング規約をしっかり決め、静的解析ツールをフルに利用します。
流用ソースのコーディングスタイルに注意。
規模大 ⇒ 流用ソースに従う
規模小 ⇒ 新規にスタイルを策定
スタイル系ルールは適用しない。
既存ソースを一括解析し、バグ検出系ルールへの対応方針を決める。
以降、改造部分のみのバグ検出系ルールに対応していく。
23

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

④適用を除外するルールの選択
同一製品でも機能により、ソースコードに求める形が異なる。
機能単位に、ルールのカスタマイズを実施。
[手順]
除外するルールの選択除外する理由の文書化（明確化）

責任者（開発リーダ）の承認

24

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED２．１ プログラム品質確保へのアプローチ
３） コーディング規約の運用

25

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

運用方法
実装開始

実装

自己レビュー

対面レビュー遵守監視コーディング規約を理解する

実装者は、コーディング規約に沿って、ソースコードを作成する
実装者は、自身が作成したソースコードに、コーディング規約違反がないかチェックするレビューアは、実装者が作成したソースコードに、コーディング規約違反がないかチェックするリーダーは、開発者がコーディング規約違反を遵守しているかを監視する
26

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDコーディング規約の充実
コーディング規約の振り返りを実施し、次回への見直しが重要振り返り項目:効果が低いルールや扱いにくいルールはないかテスト工程で検出されたバグをコーディング規約で検出できないか
運用時に負担に感じた作業はないか
V1
コーディング規約（※）

V1開発

見直し

V2
コーディング規約

V2開発

見直し

V3
コーディング規約

V3開発※アドバイス：
初回のコーディング規約は、効果が高いルールのみを運用しましょう。
27

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED開発者に定着させる施策
やる気

開発開始時

コーディング規約説明会の開催

遵守

コーディング時コーディング規約遵守の監視

達成感

開発完了時

効果（品質向上、工数減）の提示

改善

次開発に向けて ルールや運用方法を振り返り、次回開発に向けた見直し※定着には、推進役(開発リーダーや品証の方)の活動が重要です28

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED２．１ プログラム品質確保へのアプローチ
４） 事例

29

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDＡ社様の事例（１／２）
「実施タイミングの早さが負担とミスを防ぐカギ」とＦ社様。
開発者に負担を掛けず、やる気を起こす工夫を実施。
■工夫した点ＷＧで選択ルールを協議、その際「ルール違反数／コード量」を測定し、対応可能なルールへ調整導入モデルプロジェクトに、実現確率が高いプロジェクトを選定
「修正ファイルの違反ルールは、新規・既存に関係なく対処する」ルールで運用
推進役が、週１回、残違反ルール数を開発者へ広報推進役が、よく発生するルール違反の修正方法を広報
推進役が、「開発時メトリクス」と「開発者アンケート」で効果を広報

30

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDＡ社様の事例（２／２）■効果コーディング効率が、キロステップあたり約2時間短縮
コードレビューにおける問題点の指摘率が30%軽減
潜在的なバグを5000件以上消し込み
全テスト段階における問題点の指摘数を22.8%削減

31

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED２．２ ソース解析ツールの活用
１） 活用メリット

32

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDソース解析ツールのメリット
人手によるコーディング規約のチェックは効率が悪く、漏れが発生しやすいため、静的解析ツールを活用する。
ソース解析ツールの活用による利点：
チェック時間を短縮
チェック漏れ（自己レビュー時、対面レビュー時）を防止
チェック精度のバラつきを防止
違反数の把握が容易
ソース解析ツールを活用した運用方法の改善：
自己レビューは、静的解析ツールでコーディング規約のチェックを実施
対面レビューは、機能漏れや実現方式についてのレビューに専念
遵守監視は、ソース解析ツールの結果を集計することで把握

33

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDコーディング規約の作成
ソース解析ツールで用意されているチェックルールには、多くのプログラミング・ノウハウが詰まっている。
経験豊富なプログラマの知識
著名なプログラミング書籍
・・・

コーディング規約

チェックルール

有償ソース解析ツールは、チェックルールをカスタマイズする専用のビジュアルツールを提供されており、簡単に編集が可能です。

34

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDコーディング規約の運用
チェックルール（コーディング規約）を共有しながら、確実なコーディング規約の運用を可能にし、また、遵守・監視が低コストで実現。
プロジェクト管理者

開発担当者
配布
ルール定義
ファイル

開発プロジェクトの標準となるルール（開発規約）を作成する

解析ツールによるチェック

必要ならルールの 品質管理者
見直しを依頼チェック結果開発担当者から渡されるチェック結果により品質状況を判断
35

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED品質状況の監視
コーディング規約への遵守結果から、それを集計・分析することで現状の品質状況が容易に確認できる。

36

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED修正不要なメッセージへの対処
ソース解析ツールには、次回以降の実行時からメッセージを抑止する機能が存在する。修正な不要な場合に使用すると便利。
①GUIで設定する方法②ソースにコメントとして設定する方法：
pfOpneFile = fopen( szFName,”R”) ;if( pfOpenFile == NULL ) {nErrCode = OPENERR;
goto L_ERR; /* M3.1.2 */}：L_ERR:：

37

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED２．２ ソース解析ツールの活用
２） 活用アドバイス38

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDツール導入失敗パターン「とりあえず導入してみようか！」では失敗します。
えっ！凄い指摘の数だ！
何で、こんなこと指摘するんだ！
これは、どう対処しますか？

結局、リーダも開発者もツールに振り回されてしまう。

事前に「何のチェックをツールに任せるか（コーディング規約の作成）」と「どのように遵守・監視するか」を皆で合意することが重要。
39

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED目的にあったツールを選ぶ
ソース解析ツール達は、それぞれ特長を持っている。各ツールの特長を理解して導入すること。
■チェック観点で選ぶ
チェック観点で選ぶ
保守性

移植性

効率性

スタイルチェック系

信頼性
バグ検出系

スタイルチェックが得意

バグ検出が得意オールラウンド系
全てのチェック項目をカバー■適用工程
適用工程で選ぶ
適用工程で選ぶ
コーディングレビュー/
レビュー/単体テスト

プログラム単体のソース記述問題検出

結合テスト
システム全体のソース記述問題検出40

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

各プロセスにおける検出問題の明確化「ソース解析ツール」
ソース解析ツール」 ⇒ 「目視レビュー」 ⇒ 「動作テスト」の順で、重点的につぶす問題を明確にすること。
ソース解析ツール

目視レビー

動作テスト

◎×

×

単純誤り

◎××

論理誤り

○

◎

×

インタフェイス誤り

×○

◎

機能誤り×

○

◎

検出プロセス
問題種類
スタイル誤り41

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED既存ソースのバグをどうするか？
既存ソースのバグ予備軍（潜在問題）は、いずれ不具合になる恐れあり。
[コーディング後]
新規ソース[コーディング規約チェック後][テスト後]

コーディング規約チェック
テスト

既存ソース：不具合、：不具合に変化するバグ予備軍（読みにくい、修正しにくい等）
テストでバグ予備軍は検出できない

バグ予備軍は、品質問題の火種です。
静的解析ツールは、新規も既存も関係なく検出します。
既存部までの対処を検討してみてはいかがでしょうか。
42

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED第３部 プログラム品質の管理／統制

43

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED３．１ 管理／統制の必要性

44

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDサービスイン後のトラブルを未然に防ぐためシステムのサービスイン後のトラブルを未然に防ぐには、単なるバグ取りだけでなく、「プログラム品質を見える化して、必要な対策を実施する」という、プログラム品質の管理／統制が必要
要件の要件の変化：
変化：

開発スタイルの開発スタイルの変化
スタイルの変化：変化：

ITシステムのITシステムの安定稼動
システムの安定稼動が安定稼動が社会的責任と社会的責任となり、なり、開発プログラムの開発プログラムの品質確保プログラムの品質確保が品質確保がますます重要ますます重要になってきている
重要になってきているプログラム開発
プログラム開発の開発の一括発注や一括発注や過去資産の流用など流用など、など、開発プログラムがブラック開発プログラムがブラックボックス化
ボックス化が増えている

ソフトウェア開発
UI
設計

構造
設計

プログラミ
ング

プログラ
ムテスト

インタフェ システムーステスト テスト

運用
テスト

品質の品質の管理／管理／統制が統制が必要：
必要：
プログラム品質プログラム品質を品質を見える化える化して、して、危険箇所に箇所に対して対策して対策を対策を実施する
実施する
45

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

品質劣化を把握するため
V1, V2, &と複数世代に渡って開発が続く場合、各世代での改版に伴ってプログラム品質は劣化していく傾向にある。
そうした品質劣化は、保守コストの増加を招いたり、将来的トラブルの温床になったりするので、世代間での管理／統制が重要である。
プログラム品質が劣化しやすい
クローン増加
Ｖ１開発
Ｖ２開発

当初の開発設計を無視して更新
Ｖ３開発

・・・

プログラム品質の管理／統制が必要
46

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED３．２ プログラム品質の評価と見える化

47

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDプログラム品質の評価
プログラム品質プログラム品質プログラム品質は以下の６つの性質で構成される (JIS X0129-1)
機能性

使用性

信頼性

効率性

保守性

移植性


プログラム品質の評価方法
プログラム品質の評価方法
以下の方法で開発プログラムに対する６つの性質を評価する
機能性

外部仕様とプログラムを突き合わせて十分性を評価

使用性
信頼性

運用設計に基づくユーザビリティテストの結果を評価
I/F違反や例外発生に対する処置などを評価
違反や例外発生に対する処置などを評価

効率性

適切なAPIを使っているか冗長な処理がないかを評価を使っているか冗長な処理がないかを評価
適切な

保守性

プログラムの文体や複雑度などを評価

移植性システム依存や処理系依存のコードを評価

上記６つの評価結果をポイント換算する（換算方法は要件や特性で決定）48

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDプログラム品質の見える化（１／２）
プログラム全体を見える化したい観点でカテゴライズして、各プログラムの評価値を集計し、分析する。
カテゴライズの例：
機能単位、開発メンバ単位、発注単位、新規開発/流用単位
品質分析の例：
機能性

80

信頼性
効率性
保守性

70
60

移植性

50
40

100
80
60
40200

外注A
外注B
外注C
使用性

30

保守性

20

信頼性

100

受付け

突合せ

DB更新

転送

効率性

品質が低い処理はどれか？
その理由は何故か？

外注のスキルに問題ないか？
49

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDプログラム品質の見える化（２／２）
品質分析の例：100

世代毎のプログラム性質の遷移

80
保守性
信頼性
効率性
移植性

60
40
200V1V2V3V4

V4開発で、保守・信頼性が劣化した理由は？
現状プロセスで、V5開発を進めて大丈夫か？
50

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDソース解析ツールの活用プログラム品質の評価は人手と時間がかかる。
また、人による評価はバラつきが出やすい。
⇒ 評価作業の効率化／平準化のためには、ソース解析ツールを活用するとよい＜ソース解析ツール活用のポイント＞
・ ソースコード解析の特性から、品質の６つの性質のうち信頼性/効率性/保守性/移植性の４性質が評価可能
・ ソース解析ツールの選定にあたっては、ツールに該当機能があるか否かを確認
・ 自社内で評価作業ができない場合は、品質サービスなどの活用を検討

51

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED３．３ 管理／統制の実施

52

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

管理／統制の実施
プログラム品質の管理
プログラム品質の管理
 プログラム品質は開発の節目ごとに定点観測し、品質見える化する
例えば、各工程の終了時や納品受入れ時など V1, V2, &と何世代かに渡って開発が続く場合、各世代ごとの品質評価をを残しておき、世代間の劣化が確認できるようにする

プログラム品質の統制
プログラム品質の統制
 品質見える化によって、現在の開発プログラムに重大な欠陥が検出された
場合、開発完了までに是正処置を講じる
例えば、ある機能の再設計や他に類似問題がないかの見直しなど
 次回開発で見直すべき課題について、次回開発での強化項目とする
例えば、保守性に関する書き方統一や外注時に渡すべき資料見直しなど

53

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED第４部 製品・サービスのご紹介

54

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED４．１ PGReleifご紹介

55

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDPGReliefの特徴
 高いヒット率
いヒット率
データフロー解析・ロジックフロー解析により、プログラム欠陥の可能性を的確に指摘します。

 充実したドキュメント
充実したドキュメント
各々の指摘メッセージについて、詳細な解説が用意されています。
簡単な例を交えて、そのメッセージが指摘された理由や対処例なども記載されていますので的確に対処することができます。

 安心なサポート
安心なサポート
開発およびサポートは、日本国内で行っています。
問題対応、お問い合わせの回答は、迅速に行っています。
また、ご要望もお聞きし、製品へ反映しています。
56

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDPGRelief C/C++ 関数間問題検出強化
PGRelief C/C++ 2010(10年2010(10年6月出荷予定)
月出荷予定)では、検出の範囲を関数間に広げ、関数間に潜んでいるメモリリークやバッファオーバーラン等を検出します。

関数：main関数：mainvoid main( ) {int array[1010]
10 ;sub(sub array );}10個の配列を渡す
10個の配列を渡す

関数：sub関数：subvoid sub(sub int *p) {for( i=0 ; i < 50 ; i++ )p[ i ] = 0 ;}チェック観点
メモリリーク△⇒○バッファオーバーラン△⇒○0番地参照番地参照

△⇒○

初期化漏れ

△⇒○

データ欠落・データ型不整合○return）
記述忘れ（break,）
記述忘れ（○

意味の無い演算、式、条件、文

○

副作用問題

今回強化

命名規約違反ﾊﾞｯﾌｧｵｰﾊﾞｰﾗﾝが発生！

性能デットロック57○○
× (2010以降以降)
以降

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED指摘例① メモリリーク(2010)
例１
int*
int* p;void inip(inip( ) { p=malloc
p=malloc(malloc( sizeof(int)sizeof(int) * 10 ); }void endp(endp( ) { free(p);free(p); }void proc()proc() {inip(inip( ) ;inip(inip( ) ;endp(endp( );}PGRelief2010：
PGRelief2010：
・pに格納されている資源が解放されない

例２
void endp(endp( int * p ) {free(p);free(p);}void proc()proc() {int *p1 = malloc(malloc( sizeof(int)*10sizeof(int)*10 );int *p2 = malloc(malloc( sizeof(int)*10sizeof(int)*10 );：endp(p2);}

PGRelief2010：
PGRelief2010：
・p1に格納されている資源が解放されない
p1に格納されている資源が解放されない58

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED指摘例② 領域外アクセス(2010)
例１
void array_sum(array_sum( int * p ) {for( i = 0 ; i < 100 ; i++ )total += p[i];p[i];}void proc(proc( ) {int array[10];array_sum(array_sum( array );}PGRelief2010：
PGRelief2010：・array変数に対して、array変数に対して、 領域外アクセスが発生する

例２
int array[10];int sub( int index ) {return array[index];array[index];}
void proc( ) {for( i = 0 ; i < 100 ; i++ )total += sub(i);sub(i);}

PGRelief2010：
PGRelief2010：・array変数に対して、array変数に対して、 領域外アクセスが発生する

59

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED指摘例③ 0番地参照／初期化漏れ(2010)
例（0例（0番地参照）
void proc( int * p ) {int x = *p;}void func(func( ) {int *p=NULL;
int i = 0;proc( p );proc( &i );}PGRelief2010：
PGRelief2010：
・proc関数内でproc関数内で0関数内で0番地参照が発生する例（外部変数の初期化漏れ）
int gnum;gnum;
void sub( ) {int i = gnum ;}void main( ) {sub( );}PGRelief2010：
PGRelief2010：
・外部変数gnum
・外部変数gnumを初期化せずに参照してgnumを初期化せずに参照している60

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED４．２ ソース診断サービスご紹介

61

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDサービス実施内容
静的解析ツール（主にPGRelief）と目視による調査
ースコードの問題点検出
ツールと目視調査でバグやバグの可能性が高い問題箇所を検出コーディングルールで許容されているものは除外
バグの種類や重大度ごとに分析/評価し、改善案を提示

参考） ソースコードの問題点の具体例

ースコードの品質特性分析（オプション）
信頼性/保守性/移植性/効率性(性能)/機能性(セキュリティ)の観点で分析
お客様指定の観点(業務/チーム/コンポーネント/バグ種類)で分析
弱点や注力観点を洗い出し、改善案を提示※）本サービスの対象は、C/C++）本サービスの対象は、C/C++およびC/C++およびJava
およびJava言語で記述されたソースコードです
Java言語で記述されたソースコードです
62

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED診断結果例（問題点検出）
重大度を記号で表記★：バグ▲：バグの可能性□：改善

問題点検出結果、問題傾向／評価

バグ箇所のソースを抜粋

バグの解説、改善指針を提示

バグおよびバグの可能性がある箇所の件数一覧

63

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED診断結果例（品質特性分析）
品質特性ごとの指摘内訳グラフ
品質特性観点ごとの評価

業務単位ごとの傾向グラフ

指摘ごとの解説64

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITEDサービス基盤支えるのは・・・ コンパイラ開発で培った“プロの目”

確な指摘
コンパイラ開発経験が豊富な、高い言語スキルを持つ専門技術者チームが診断
率的な解析
静的解析ツール(PGRelief)開発経験者が、ツール活用ノウハウを駆使して解析重要度が高く改善効果が大きい問題点を効率的に抽出
富な分析手法
お客様指定観点と品質特性を絡め、さまざまな観点からわかりやすく解説
豊富なアプリ開発経験から、弱点や注力観点を分析

サービス活用により、静的解析ツール導入費用、教育費用といったコストが不要
らに・・・
ツールセットアップ、解析、利用ノウハウ蓄積といった手間が不要
65

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED事例紹介
対象プロジェクト
言語： C/C++言語
規模： 1.4Mstep
工程： PT中

診断実施期間： 11営業日
プロジェクト概要： 金融営業系システム機能追加
開発形態： 社外への委託開発

問題検出を効率化
問題の早期検出弱点箇所の強化

ソースコード診断サービス

診断結果

お客様の対処バグ指摘： 312件(27種)
バグの可能性： 63件(11種)
傾向分析： 異常系処理に弱点
C++仕様理解不足の可能性

全件修正(27種)
43件修正(7種)、既存資産分は保留
異常系処理の強化レビュー実施
指摘事項をＰｒｊ内に横展開

お客様のご感想 PTで検出できなかったコーディングミスやレビュー漏れによるバグを効率的に検出できました
PTで検出できなかったコーディングミスやレビュー漏れによるバグを効率的に検出できました バグを早期に検出できたことで、ＩＴ工程以降で手戻りが発生するといった品質リスクが減少しました
バグを早期に検出できたことで、ＩＴ工程以降で手戻りが発生するといった品質リスクが減少しました テストでは見つけられない保守性、移植性の問題もわかり、今後の保守効率の向上が期待できます
テストでは見つけられない保守性、移植性の問題もわかり、今後の保守効率の向上が期待できます66

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED公開情報、お問い合わせ先

公開Webサイト
http://jp.fujitsu.com/fst/services/pgr/

お問合せ先
株式会社富士通ソフトウェアテクノロジーズ

PGReliefお問い合わせ窓口
PGReliefお問い合わせ窓口
E-mail：mail：fstfst-pgrpgr-sales@cs.jp.fujitsu.com

67

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED68

Copyright 2010 FUJITSU SOFTWARE
Copyright
TECHNOLOGIES2007 FUJITSU LIMITED