ソフトウェア開発プロセス改善モデルCMMI

126
ソフトウェア開発プロセス改善モデル CMMI-DEV の
関連プロセス領域ネットワークの中心性分析
日下部茂林信宏大森洋一荒木啓二郎
ソフトウェア開発の品質や効率の向上には要素技術だけでなく，ソフトウェア開発のプロセスも重要とされている．
我々は要素技術として形式手法に着目し，その導入によるプロセスの改善について研究している．実際の開発に形式
手法を導入する場合，プロセスのテーラリングについても考慮する必要があるが，具体的な実プロセスの多様性を
ふまえプロセス改善のモデルを用いたテーラリングの検討も有効と考える．本稿では，プロセス改善モデルの一つ
CMMI-DEV の，関連プロセス領域の関係に着目しネットワークの中心性を分析した．その結果，形式仕様記述の
導入成功事例の分析結果と共通するプロセス改善の指針を得ることができた．
In this paper, we discuss the issue of how to define and develop a software development process with formal methods from a view point of software process improvement. We use a standard development process
improvement model, CMMI-DEV, as a reference which is a compilation of best practices in software development process. We expect this approach can lead to the exploitation of knowledge and findings obtained
in the successful cases of introducing formal methods. In this work, we analyzed the process area network
using the relationship of Related Process Areas components in the process improvement model CMMI-DEV.
We compared the results with succeeded cases using formal methods in real projects and found similarities
between observations on the process networks and the lessons learned from the succeeded cases.
善点について研究している．
1 はじめに
ソフトウェアの利用範囲は拡大を続けており，ソフ
1. 1 ソフトウェア開発プロセス改善モデル
トウェアの信頼性や安全性は以前にも増して重要と
ソフトウェアの品質はその開発に用いられたプロ
なっている．その一方で，ソフトウェアシステムの開
セスに影響を受けるといった考えがある．高い品質
発にかける期間やコストの短縮が求められている [6]．
のソフトウェアを効率よく開発するために，開発の
ソフトウェア開発における品質や効率の向上のための
プロセスに着目し，プロセスのアセスメントや，ア
要素技術の提案や開発が行われる一方，ソフトウェア
セスメント結果にもとづくプロセス改善といった活
開発のプロセスも重要であるとしてその提案や提案
動も行われている．ソフトウェア開発のプロセスを
に基づく改善活動も行われている．我々は要素技術と
改善して高品質のソフトウェアを作る代表的なプロ
して形式手法に着目し，その導入によるプロセスの改
セス改善のフレームワークとして能力成熟度モデル
CMM(Capability Maturity Model) やその発展版の
Centrality Analysis of Related Process Areas in a Process Improvement Model CMMI-DEV.
Shigeru Kusakabe, Hsin-Hung Lin, Yoichi Omori, Keijiro Araki, 九州大学大学院システム情報科学研究院,
Faculty of Information Science and Electrical Engineering, Kyushu University.
コンピュータソフトウェア, Vol.32, No.3 (2015),pp.126–136.
[研究論文] 2014 年 10 月 1 日受付.
大会同時投稿論文
能力成熟度モデル統合 CMMI(Capability Maturity
Model Integration) フレームワークがある．そのフ
レームワークにもとづく，開発のための CMMI-DEV
[3] は，ソフトウェア開発のプラクティス，つまり日々
の業務で必要とされる概念や原則，必要な技術，手
法，ツール，管理ノウハウといったものの集合から，
ベストプラクティスを体系化したモデルとされてい
Vol. 32 No. 3 Aug. 2015
127
る．CMMI-DEV は，システム開発の調達条件として
受発注の提案依頼書にその成熟度レベルが記載される
こともあるため，レベル獲得の側面が重視されること
も多い．しかしながら，本来はレベル獲得に限定され
ず，自らがプロセスを改善する際に有効なツールとし
て利用できたり，新しい技術を導入し使用するための
手段を提供するようなモデルとして提案されている．
1. 2 形式手法導入とプロセス改善
図1
標準プロセスモデルを用いた比較検討
ソフトウェアの機能や安全性を保証しながら，よ
り高い，もしくはある一定の品質のソフトウェアを
導入の知見も，図 1 のように，標準的なプロセス改
効率よく開発するために有効な手法として形式手法
善モデルを介することで，参照や比較が容易になると
(formal methods) が提案され，実際に産業界でも活
考える．
用されている [19]．日本においても，形式手法に関し
本稿では，プロセスモデルとして CMMI フレーム
ては，様々な研究活動だけでなく，事例報告による知
ワークに基づくモデル，新しい技術として特に形式
見の共有やテキストの公開，セミナーの実施といった
手法を想定した取り組みについて論じる．CMMI は
実際の開発現場での活用を促進するための普及活動
チームレベルのプロセスとの対応関係も議論されてお
も行われている [1] [4] [5] [12] [13]．
り [15]，図 1 の中で上下方向に位置する，組織，チー
実際の開発プロセスに新たに形式手法を導入する
ム，個人の異なるレベルのプロセス [9] [17] の間の対
場合には以下のような課題があり，形式手法導入の成
応も取りやすいと考えており，既にいくつかの取り組
否やその効果を一律に述べることは困難である．
みも行っている [10] [11] [14] [18]．
• 形式手法導入の難易度や利害得失に対しては同
本稿では，特に開発のための CMMI-DEV におけ
一組織の中であっても様々な見方があり得るた
る，成熟度ごとの関連プロセス領域ネットワーク中の
め，導入の合意形成は必ずしも容易ではない．
中心性を解析し，その結果を形式仕様記述適用の成功
• 形式手法と総称されていても，実際には具体的
事例の分析結果 [5] と比較検討を行う．ソフトウェア
な手法として形式手法群と呼べるほど様々な手法
開発のベストプラクティスを反映した標準的参照プロ
があり，それぞれ長所・短所が異なる．
セスモデルに，形式手法導入に成功したプロセス実例
• 実際の開発で用いられる開発プロセスにも様々
でのベストプラクティスを反映できれば，形式手法を
なものがあり得るため，形式手法自体の難易度に
用いるソフトウェア開発の標準的参照プロセスも構築
加え，開発プロセスを変更する難易度も考慮する
可能と考えている．
必要がある．
本稿の以降の構成は以下の通りである．第 2 節で
• ベースとなるプロセスが一定のレベルに達して
CMMI-DEV の概要の説明を行う．第 3 節で，CMMI-
いない場合，形式手法のような新しい手法を導入
DEV のモデル要素のうち関連プロセス領域に着目し
する前に他に改善すべき点に取り組んでおかな
た中心性分析について述べる．第 4 節では，CMMI-
いと形式手法導入に失敗する可能性が高い．
DEV の段階表現での成熟度レベルごとの特徴につい
効果的なプロセスは新しい技術を導入し使用するた
て考察し，形式仕様記述導入事例との関連付けを通し
めの手段も提供するとされており，我々は，既存のプ
て取り組みの有効性について議論する．第 5 節で関
ロセスアセスメントやプロセス改善のモデルと形式
連研究について述べる．
手法の導入を関連付ける試みを行っている．我々は，
直接的な比較が困難な個別のプロセスへの形式手法
コンピュータソフトウェア
128
表1
開発のための能力成熟度モデル統合 (CMMI-DEV) のプロセス領域
段階表現での成熟度レベルとプロセス領域
2: 要件管理 (REQM: Requirements Management)
2: プロジェクト計画策定 (PP: Project Planning)
2: プロジェクトの監視と制御 (PMC: Project Monitoring and Control)
2: 供給者合意管理 (SAM: Supplier Agreement Management)
2: 測定と分析 (MA: Measurement and Analysis)
2: プロセスと成果物の品質保証 (PPQA: Process and Product Quality Assurance)
2: 構成管理 (CM: Configuration Management)
3: 要件開発 (RD: Requirements Development)
3: 技術解 (TS: Technical Solution)
3: 成果物統合 (PI: Product Integration)
3: 検証 (VER: Verification)
3: 妥当性確認 (VAL: Validation)
3: 組織プロセス重視 (OPF: Organizational Process Focus)
3: 組織プロセス定義 (OPD: Organizational Process Definition)
3: 組織トレーニング (OT: Organizational Training)
3: 統合プロジェクト管理 (IPM: Integrated Project Management)
3: リスク管理 (RSKM: Risk Management)
3: 決定分析と解決 (DAR: Decision Analysis and Resolution)
4: 組織プロセス実績 (OPP: Organizational Process Performance)
4: 定量的プロジェクト管理 (QPM: Quantitative Project Management)
5: 組織実績管理 (OPM: Organizational Performance Management)
5: 原因分析と解決 (CAR: Causal Analysis and Resolution)
連続表現での区分
プロジェクト管理
プロジェクト管理
プロジェクト管理
プロジェクト管理
支援
支援
支援
エンジニアリング
エンジニアリング
エンジニアリング
エンジニアリング
エンジニアリング
プロセス管理
プロセス管理
プロセス管理
プロジェクト管理
プロジェクト管理
支援
プロセス管理
プロジェクト管理
プロセス管理
支援
は共有のプロセス領域で，5 つは開発固有のプロセス
2
CMMI-DEV
ここでは，ソフトウェア開発のための代表的なプロ
セスモデルとして CMMI-DEV 1.3 を用い，特にそ
のプロセス領域に着目して考える．CMMI-DEV 1.3
のモデルは，
『CMMI 1.3 版のアーキテクチャと枠組
み』から生成された，政府や産業界からの開発のベス
領域である．この 5 つの開発固有のプロセス領域は，
開発に固有のプラクティスに焦点を合わせたもので，
「要件開発」，
「技術解」，
「成果物統合」，
「検証」，およ
び「妥当性確認」である．
各プロセス領域を構成する要素は，以下のように分
類される．
トプラクティスの集まりである．CMMI でのプロセ
• Required Components(必要とされる構成要
ス領域とは，ある領域における関連するプラクティス
素)—あるプロセス領域におけるプロセス改善
のひとまとまりであり，それらがひとまとまりとして
を達成するために必須の CMMI 構成要素，
実装されると，その領域で改善を行うために重要であ
ると見なされている一連のゴールが満たされる．
• Expected Components(期待される構成要素)—
必要とされる CMMI 構成要素を達成するにあ
たって重要である活動を記述した CMMI 構成
2. 1 モデルの構成要素
要素，
CMMI-DEV には，表 1 に示す 22 のプロセス領域
• Informative Components(参考の構成要素)—
が含まれている．段階表現での成熟度レベル，連続
CMMI の必要とされる構成要素および期待さ
表現でのカテゴリ (区分) については後述する．これ
れる構成要素をモデル利用者が理解することを
らのプロセス領域のうち，16 個は CMMI の他のモデ
助ける CMMI 構成要素．
ル (取得のためのモデル CMMI-ACQ，サービスのた
めのモデル CMMI-SVC) にも共通する中核のプロセ
ス領域である．それ以外のプロセス領域のうち，1 つ
具体的には，各プロセス領域は次の要素を含んで
いる．
• 目的の記述文 (Purpose Statements: Informa-
Vol. 32 No. 3 Aug. 2015
tive)
表2
• 導入説明 (Introductory Notes: Informative)
• 関連プロセス領域 (Related Process Areas: In-
• 固有プラクティス (Specific Practices:
4
5
—
レベル
0
1
Ex-
2
pected)
• 固有プラクティスのサブプラクティス (Specific
Sub-practices: Informative)
• 作業成果物の例 (Example Work Products: In-
能力レベルと成熟度レベルの比較
連続表現
能力レベル
Incomplete
(不完全な)
Performed
(実施された)
Managed
(管理された)
Defined
(定義された)
—
formative)
• 固有ゴール (Specific Goals: Required)
129
3
formative)
段階表現
成熟度レベル
—
Initial
(初期)
Managed
(管理された)
Defined
(定義された)
Quantitatively Managed
(定量的に管理された)
Optimizing
(最適化している)
• 共通ゴール (Generic Goals: Required)
• 共通プラクティス (Generic Practices:
Ex-
pected)
• 共通プラクティスのサブプラクティス (Generic
Sub-practices: Informative)
• 共通プラクティスの詳細説明 (Generic Practices
Elaborations: Informative)
構成要素を使って本質的には同じ内容を提供してい
るが，異なる方法で編成されている．段階表現では，
プロセス領域は成熟度レベルにより編成され，連続
表現では，プロセス領域は，プロセス管理，プロジェ
クト管理，エンジニアリング，支援，という 4 つの区
分により編成される．段階表現では，あらかじめ定義
例えば，ある固有ゴールは 1 つのプロセス領域に
されたプロセス領域の集合に一つ一つ順番に取り組
適用され，そのプロセス領域を満たすために存在しな
むことにより，関連するプロセスの集合を改善するこ
ければならない特有の性質を記述する，必要とされる
とを可能にする．連続表現では，モデルで選択された
構成要素である．固有プラクティスは，期待される構
個々のプロセス領域もしくはプロセス領域の集合に対
成要素で，プロセス領域の固有ゴールの達成につなが
応する，実プロセスを一つ一つ改善していくことを可
ることが期待される活動である．共通ゴールは，プロ
能にする．段階表現には，成熟度レベルというレベル
セス領域を実装するプロセスを制度化するために存在
を，連続表現には，能力レベルというレベルを用いる
しなければならない特性を記述している，必要とされ
(表 2 参照)．
る構成要素で，複数のプロセス領域に同じゴール記述
連続表現の観点からソフトウェア開発プロセスを形
文が現れる．共通ゴールの達成は，そのプロセス領域
式手法で改善するとした場合，改善の目的に応じてプ
に関連するプロセスの計画と実装における改善され
ロセス領域もしくはプロセス領域群に着目し適切な
た制御を意味している．共通プラクティスは，プロセ
手法や技術を選ぶことが考えられる．段階表現の観点
ス領域と関連するプロセスが効果的で，反復でき，持
からソフトウェア開発プロセスを形式手法で改善する
続的なものであることを確実なものにする活動で，期
とした場合，段階表現の成熟度の向上に有効な形式手
待される構成要素である．関連プロセス領域は，関連
法を選ぶことが考えられる．
するプロセス領域への参照を列挙し，プロセス領域間
の高いレベルの関係を表す，参考の構成要素である．
3 関連プロセス領域に着目した中心性分析
実際のプロジェクトは，形式手法のような特定の技
2. 2 段階表現と連続表現
術のみで成功できるわけではない．一方，形式手法を
CMMI のモデルには段階表現と連続表現の二種類
導入すると，その手法が直接的に対象とするプラク
の表現がある．どちらの表現も，目標を達成するため
ティスや作業成果物に対する効果だけでなく，それ以
にプロセス改善を実装する方法を提供し，同じモデル
外のものに対する間接的な効果もプロジェクトも成
コンピュータソフトウェア
130
図2
区分をまたがる関連プロセス領域にもとづいたプロセス領域間の関連
功に寄与するという報告もある [1] [12]．このような形
Eng.，支援は Support と記した四角で囲んでいる．
式手法導入の効果をプロセスモデルで検討する場合，
図は，特定の区分のプロセス領域を改善するための
直接的な効果に関しては主にプロセス領域内の固有
手法が，他の区分のプロセス領域にも効果や影響を
ゴールや固有プラクティスに主に焦点を当てて形式手
与え得ることを，プロセス領域間の関連により示し
法の導入を検討することが考えられる．間接的な効果
ている．例えば，プロジェクト計画策定 PP は要件開
に関しては，関連プロセス領域 (群) の間の関係に着
発 RD や技術解 TS を参照している．また，要件管理
目して形式手法を導入することが考えられる．プロセ
REQM は，要件開発 RD や技術解 TS と相互に参照
ス領域間の関連付けでどのようなグループ化を行う
しあっている．
かは，前述の段階表現における成熟度レベルごとの編
成や，連続表現におけるプロセス領域の区分など様々
3. 2 段階表現でのプロセス領域間の関係
な観点のものを考えることができる．
段階表現の各成熟度レベルに含まれるプロセス領域
に対して，ネットワーク中心性の分析を行った．分析
3. 1 連続表現での関連プロセス領域間の関係
対象のネットワークは，対象成熟度レベルに含まれる
CMMI-DEV の公式文書の，各プロセス領域の説
プロセス領域をノードとし，各プロセス領域のモデル
明中，関連プロセス領域の部分に記述されている参照
要素のうち関連プロセス領域に記述されている参照
関係に基づいて，図 2 に，プロセス領域の間の関連
関係に基づいてノード間のリンクを求めた．ただし，
をグラフ化して示す．グラフ化には Graphviz ツール
参照元のプロセス領域だけでなく参照先のプロセス領
[8] を用いた．楕円形のノードはプロセス領域を表し，
域も対象とする成熟度レベルに含まれるような参照関
矢印のアークは関連プロセス領域に記述された参照
係だけを有効なリンクとした．段階表現の成熟度レベ
関係を示す．ノード A からノード B への矢印は，プ
ルの評定で，対象成熟度レベルより低いレベルに含ま
ロセス領域 A の関連プロセス領域の説明にプロセス
れるプロセス領域も含めて考えるのと同様に，対象と
領域 B への参照があることを表す．プロセス領域の
する成熟度レベルとそれより低いレベルに含まれるプ
区分を示すために，プロセス管理は Process M.，プ
ロセス領域を合わせてネットワークの分析を行った．
ロジェクト管理は Project M.，エンジニアリングは
Vol. 32 No. 3 Aug. 2015
表 3 成熟度レベル (ML) ごとの関連プロセス領域の
ネットワーク中の入次数中心性の値.(各成熟度レベルの
プロセス領域数で標準化し成熟度レベル 3 の値でソート)
プロセス領域
RD
PP
PMC
REQM
TS
VER
RSKM
OPD
DAR
CM
MA
VAL
SAM
IPM
OPF
PI
OT
PPQA
OPP
QPM
OPM
CAR
ML2
0.571
0.571
0.429
0.286
0.286
0.000
0.000
ML3
0.444
0.389
0.333
0.333
0.333
0.333
0.278
0.222
0.222
0.222
0.167
0.167
0.056
0.056
0.056
0.056
0.000
0.000
ML4
0.400
0.350
0.350
0.300
0.300
0.300
0.250
0.250
0.200
0.200
0.250
0.150
0.100
0.100
0.050
0.050
0.000
0.000
0.050
0.050
ML5
0.364
0.318
0.318
0.273
0.273
0.273
0.227
0.227
0.227
0.182
0.318
0.136
0.091
0.091
0.091
0.045
0.045
0.000
0.091
0.091
0.182
0.091
131
表 4 成熟度レベルごとの関連プロセス領域のネット
ワーク中の媒介中心性の値.(成熟度レベル 3 の値でソート)
プロセス領域
RD
PP
MA
REQM
DAR
VER
IPM
TS
OPD
PI
RSKM
PMC
CM
VAL
SAM
OT
OPF
PPQA
QPM
OPP
OPM
CAR
ML2
0.119
0.119
0.119
0.119
0.000
0.000
0.000
ML3
0.347
0.342
0.173
0.163
0.156
0.137
0.126
0.121
0.105
0.104
0.092
0.087
0.021
0.009
0.005
0.000
0.000
0.000
ML4
0.281
0.318
0.433
0.173
0.117
0.122
0.129
0.101
0.095
0.050
0.077
0.133
0.026
0.007
0.027
0.000
0.000
0.000
0.143
0.000
ML5
0.261
0.283
0.387
0.122
0.084
0.111
0.092
0.296
0.032
0.040
0.056
0.070
0.010
0.020
0.018
0.007
0.004
0.000
0.144
0.000
0.265
0.014
ば，プロジェクト計画策定 PP は要件開発 RD を参
3. 2. 1 関連プロセス領域ネットワークでの
入次数中心性
照しており，形式手法を導入することで要件開発 RD
プロセス領域が変更されると，プロジェクト計画策定
モデル要素である関連プロセス領域に着目し，ネッ
PP も変更がある可能性がある．プロジェクトの監視
トワーク分析による中心性を求めた．入次数 (in-
と制御 PMC はプロジェクト計画策定 PP を参照して
degree) による中心性の結果を表 3 に示す．表では成
おり，プロジェクト計画策定 PP に変更があるとプロ
熟度レベル (以降 ML と略記)3 での値が降順となる
ジェクトの監視と制御 PMC に変更がある可能性が
ようにプロセス領域をソートしている．要件開発 RD
ある．こういった関係を分析するために，プロセス領
は ML3 から含まれ，以降 ML5 まで高い入次数中心
域間の参照関係をもとにネットワーク分析による媒介
性の値を持っており，関連プロセス領域という関係で
中心性 (Betweenness centrality) を求め，その結果を
構成されたネットワークの中心的な存在と言える．段
表 4 に示す．この表でも ML3 での値が降順となるよ
階表現を用いたプロセス改善では，あらかじめ定義さ
うにプロセス領域をソートしている．入次数中心性
れた集合に含まれるプロセス領域に取り組むことに
の分析結果と同様に，要件開発 RD は ML3 のプロセ
より，関連するプロセスの集合を改善することを可能
ス領域では高い値を持っており，要件開発 RD にま
にする．その際に要件開発 RD にまず取り組むこと
ず取り組むことが，関連するプロセス領域の改善に
が，関連するプロセス領域の改善に対して波及効果が
対して波及効果が大きいのではないかと推測できる．
大きいのではないかと推測できる．
しかしながら，入次数中心性の分析結果と異なる点も
3. 2. 2 関連プロセス領域ネットワークでの
媒介中心性
形式手法を導入することで，その直接的な効用だ
けでなく，間接的な効用もあるといわれている．例え
ある．ML4 以降では要件開発 RD は必ずしも最も高
い値ではない．ML4 や ML5 で重視されている観点
での間接的な影響を考えると，重点を置くべき他のプ
ロセス領域がある可能性がある．
コンピュータソフトウェア
132
図 3 CMMI-DEV 1.3 における成熟度レベルごとの，
関連プロセス領域ネットワーク中の入次数中心性の視覚化．
図 4 CMMI-DEV 1.3 における成熟度レベルごとの，
関連プロセス領域ネットワーク中の媒介中心性の視覚化
心性の値に比例した大きさを持つ．ノードにはプロセ
4 議論
ス領域名も併記されており，その文字の大きさも中心
成熟度に合わせて重視すべきプロセス領域を分析
性の値の大きさに比例している．
する．また，形式手法導入事例報告との関連付けを通
して我々の取り組みの有効性を議論する．
図 4 は，関連プロセス領域ネットワークでの媒介
中心性を図 3 同様に成熟度レベルごとに視覚化した
ものである．
4. 1 成熟度レベルごとの関連プロセス領域
ネットワークの視覚化
プロセス領域をノードとして各成熟度ごとに関連
4. 2 成熟度レベルごとの特徴の考察
視覚化の結果もふまえ，以下のような考察を行った．
プロセス領域のネットワークを図示する際に，中心性
• 形式手法の導入に直接的に関係するプロセス領
の値が大きいほどノードを大きくするように視覚化
域はエンジニアリング区分に属すると考えられ
し，成熟度レベルごとの特徴の把握の促進を試みる．
る．しかしながら ML2 のプロセス領域にはエン
視覚化にはツール Gephi [7] を用いた．
ジニアリング区分のプロセスが含まれず，形式手
図 3 は，関連プロセス領域ネットワークでの入次
法の導入でエンジニアリング区分のプロセス領域
数中心性を成熟度レベルごとに視覚化したものであ
が改善されるとしても，ML2 では形式手法導入
る．図中の円形のノードはプロセス領域に相当し，中
の直接的な効果をモデル上で関連付けられない．
Vol. 32 No. 3 Aug. 2015
133
• 成熟度レベル ML3 で定義されたプロセス領域群
心性の分析の結果を用いることを提案する．モデルレ
では，エンジニアリング区分の中で強調すべきプ
ベルでの中心性の分析の結果として重要と考えられ
ロセス領域の識別の手掛かりが得られる．入次数
る観点が，実際の事例の分析で重要とされた観点と符
中心性での直接的参照関係を考慮した分析では，
合するかどうかを確認する．
要件開発 RD に加え，検証 VER と技術解 TS の
この報告書は，上流工程における文書化の不十分さ
プロセス領域も大きな値を持っている．一方，媒
に起因する品質の低下や開発コストの上昇を低減す
介中心性の解析では要件開発 RD 以外は必ずし
るための手法として形式手法に着目したものである．
も大きな値を持っておらず，より広い範囲でのつ
上流工程における仕様書作成に形式手法を用いて成
ながりを重視する場合はまず要件開発 RD に着
功した事例を対象として，以下のような観点からヒア
手するのが良いと考えられる．
リング調査を行ったものである．
• 実装に近いレベルの検証に有効な形式手法とい
うより，上位レベルの仕様の記述に有効な形式手
法を用い，要件開発 RD のプロセス領域が改善
されると，より大きな効果が他のプロセス領域に
波及する可能性がある．
• 測定と分析 MA プロセス領域は，入次数中心性
分析の結果では ML5 まで大きな値を持たない．
• 形式手法が仕様書作成に関連する諸問題をどの
ように改善したか
• 形式手法を導入することでどのような効果があっ
たのか
• ステークホルダ―や協力組織とのコミュニケー
ションをどのようにしたのか
• どのような教育をしたのか
媒介中心性の分析結果では，ML3 から ML4 へ
調査対象は，国内 3 事例，海外 8 事例，計 11 事例で
の遷移で要件開発 RD とプロジェクト計画策定
ある．
PP の値が小さくなる一方，MA はより大きな値
どの事例でも要求から厳密な仕様を記述すること
を持っている．より広い範囲での定量的な管理や
でコミュニケーションの質が向上しプロジェクトに良
最適化を重視する場合は測定と分析 MA プロセ
い効果を与えている．これは，厳密な仕様記述によ
ス領域の重要度が高いことが推測される．
り要件開発 RD が改善されることで，ML3 の多くの
• 媒介中心性分析の ML4 から ML5 への遷移では，
プロセス領域も改善されることに相当すると考える．
技術解 TS の値が大きくなっており，最適化を目
プロセス改善モデルに対するどちらの中心性の分析
指す状態では技術解 TS のプロセス領域の重要性
でも，要件開発 RD が成熟度 ML3 レベルのプロセス
が高まっている．
領域の中で中心的な位置にあった．調査報告書では，
厳密な仕様をプロジェクト全体から参照される辞書あ
4. 3 形式仕様記述導入成功事例との関連付け
るいは情報のハブとすることを推奨している．これ
ここでは，厳密な仕様記述における形式手法成功事
は要件管理 REQM の実装に相当すると考える．中心
例調査報告書 [5] で紹介されている事例の分析結果と
性に関して，要件開発 RD ほどではないが要件管理
照らし合わせることで，我々の取り組みの有効性につ
REQM も一定の高い値を持っており，そのような推
いて確認する．図 1 のような形式手法導入に関する
奨に相当するテーラリングを検討する手掛かりも得
比較検討で CMMI-DEV を利用する場合の問題とし
られていると考える．
て，CMMI-DEV は 20 を超えるプロセス領域を持ち
また，仕様の記述を，粒度の揃った網羅的記述に保
公式文書は 400 ページを超える分量があるため，ど
つ事ができるならば，プロジェクトの状況を定量的に
のような観点を手掛かりとして比較検討するのがよ
解析することが可能になり，変更に対するコスト (工
いのか大域的な観点から総合的な判断をするのが容
数，工期) などの情報も蓄積しやすいとの知見が得ら
易でないという点がある．このような問題に対する取
れている．これは，先の分析結果で示された，成熟度
り組みとして，関連プロセス領域のネットワークの中
が高まるにつれ測定と分析 MA の重要度が増すこと
134
コンピュータソフトウェア
を，形式仕様記述が支援できることを示すと考える．
このように，先の分析で暗示されたプロセス改善
モデルが重視すべきプロセス領域と，形式仕様記述
の導入によってどう強化すべきか関連付けて考える
ことができ，形式手法を導入したプロセスモデルに
対しての見通しを得ることができた．ただし，報告書
[5] は形式手法普及促進の観点から一般性の高い事例
を中心に紹介していると考えると，そのような事例
と汎用のプロセス改善モデルとの対応がつけやすかっ
たとも考えられる．実際の開発プロセスや形式手法の
導入には様々なバリエーションがあり，上記の議論が
そのままは当てはまらない場合もあり得ると考える．
そのようなバリエーションについての調査研究は今後
の課題である．
図 5 構成管理 CM プロセス領域における固有プラク
ティス (SP: Specific Practice) の間の依存関係
(文献 [2] より)
5 関連研究
関連プロセス領域に着目して，プロセス領域間の互
セス領域における固有プラクティス (SP: Specific
いの関連性を評価した研究に [16] がある．この研究で
Practice) の間の依存関係を示したものである．灰色
は各成熟度でのプロセス領域間の依存関係をマトリ
の四角は固有プラクティスを表し，それらの間の依存
クスやネットワークで表現し評価を行っている．我々
関係を矢印で表している．このような図は，個別のプ
の研究では，単にネットワークで表現するだけでな
ロセス領域内だけでも，ネットワーク図は煩雑になる
く，ネットワーク中のプロセス領域に対し 2 つの異
可能性があり，多数のプロセス領域に対して俯瞰的な
なる種類の中心性を求めている．さらに中心性の値
分析を行おうとしても対応が困難になることが予想
に応じてプロセス領域のノードの大きさを変えてネッ
される．
トワークを視覚化することで，より俯瞰的に特徴を把
握できるようにしている．
本稿では，必ずしもエンジニアに限定せず管理者層
も含めたステークホルダーの間で形式手法のような
関連プロセス領域以外のモデル構成要素に焦点を当
新しい技術を導入する際の認識を共有することも想
てたものとして，固有プラクティスに焦点を当てた研
定し，俯瞰的な視点での分析を指向している．俯瞰的
究 [2] がある．CMMI-DEV の公式文書では，固有プ
な手法で範囲を限定した後，対象範囲を詳細に分析
ラクティスのうち，どれをどの順番で実装するといっ
する，といった際には，上記の関連研究のようなアプ
たことが明記されていないため，固有プラクティスの
ローチが有効な可能性がある．そのような，複合的な
依存関係を示すことで実装の順序関係の指針を示そ
アプローチについては今後の研究課題とする．
うとするものである．公式文書のテキストを分析し，
各作業成果物とそれを生成，利用する固有プラクティ
6 おわりに
スを識別した上で，プロセス領域内，プロセス領域間
本研究では，抽象度の高いプロセス改善モデルの 1
での，固有プラクティスの間の依存関係を識別してい
つ CMMI-DEV を対象に，モデル構成要素の 1 つで
る．しかしながら，対象は成熟度レベル ML2 のプロ
ある，関連プロセス領域に着目した，俯瞰的な観点か
セス領域だけであり，より多くのプロセス領域を含み
らの分析や視覚化を行った．モデルレベルの俯瞰的な
より高い成熟度のレベルでは分析していない．
観点により，形式手法導入の効果について系統的に考
図 5 は文献 [2] からのもので，構成管理 CM プロ
察することができた．例えば，エンジニアリング区分
Vol. 32 No. 3 Aug. 2015
のプロセス領域へ形式手法を導入したとしても，その
効果・影響が，他の区分，支援，プロジェクト管理，
プロセス管理の区分にも及ぶ可能性をモデルで示す
ことができた．また，成熟度ごとのプロセス領域の集
合に対して，関連プロセス領域に指定された関係を用
いて構成したネットワークの中心性を分析し視覚化す
ることで，形式仕様記述の成功事例でのベストプラク
ティスがプロセス改善モデル上での分析結果を関連付
けることができた．このような結果を利用すること
で，形式手法導入についてより建設的な検討ができる
と考える．
謝辞本研究の一部は，科学研究費補助金基盤 (S)
「アーキテクチャ指向形式手法に基づく高品質ソフト
ウェア開発法の提案と実用化」(24220001，代表：荒
木啓二郎) の助成を受けたものである．
参考文献
[ 1 ] 荒木啓二郎：ソフトウェア開発現場への形式手法導
入−形式手法適用の実経験から得られた知見−, SEC
journal, Vol. 6, No. 2(2010)pp. 104–107.
[ 2 ] Chen, X., Staples, M. and Bannerman, P.: Analysis of Dependencies between Specific Practices in
CMMI Maturity Level 2, in Proceedings of 15th
European Conference, EuroSPI 2008, 2008, pp. 94–
105.
[ 3 ] CMMI for Development, Version 1.3, http://
cmmiinstitute.com/resources (2015 年 4 月 20 日閲覧)
[ 4 ] 独立行政法人情報処理推進機構: 実務家のための形
式手法教材「厳密な仕様記述を志すための形式手法入
門」，ソフトウェア・エンジニアリング・センター報告
書, 2012.
[ 5 ] 独立行政法人情報処理推進機構: 厳密な仕様記述に
おける形式手法成功事例調査報告書，ソフトウェア・エ
ンジニアリング・センター報告書, 2013.
[ 6 ] 独立行政法人情報処理推進機構, ソフトウェア開発
データ白書, http://sec.ipa.go.jp/publish/whitepaper
(2015 年 4 月 20 日閲覧)
[ 7 ] Gephi, The Open Graph Viz Platform, https:
//gephi.github.io/(2015 年 4 月 20 日閲覧)
[ 8 ] Graphviz - Graph Visualization Software, http:
//www.graphviz.org(2015 年 4 月 20 日閲覧)
[ 9 ] Humphrey, W. S.: PSP: A Self-improvement
Process For Software Engineers, Addison-Wesley
Pub, 2005.
[10] 金丸将平，岡部正臣，山本大輔，三善浩司，青山慎
二，松村成樹，荒木啓二郎，日下部茂，大森洋一，吉
武浩，岩崎孝司，山田浩，日下部雄三：規範的チーム
開発プロセス TSPi に基づく産学連携 PBL の事例報
告∼Openflow コントローラ開発への形式手法導入∼，
135
情報処理学会ソフトウェア工学研究会研究報告，2013,
2013–SE–179 (26).
[11] 小材健，日下部茂，大森洋一，荒木啓二郎：測定可
能な個人プロセスを対象とした形式手法導入に関する
提案，情報処理学会ソフトウェア工学研究会研究報告，
2009(31), pp. 161–167.
[12] 栗田太郎, 太田豊一, 中津川泰正：携帯電話組み込み
用“ モバイル FeliCaIC チップ ”開発における形式仕様
記述手法の適用とその効果, ソフトウェア・シンポジウ
ム 2006, 2006, pp. 49–66.
[13] 栗田太郎: モバイル FeliCa の開発における形式仕
様記述を通して, SEC journal, Vol. 7, No. 1 (2011),
pp. 34–39.
[14] 日下部茂，大森洋一，荒木啓二郎：規律を重視した
ソフトウェア開発プロセストレーニングコースを利用し
た個人レベルでの形式手法導入の試み，ソフトウェアシ
ンポジウム SS2011 予稿集, 2011.
[15] McHale, J. and Wall, D. : Mapping TSP to
CMMI, Software Engineering Institute, Carnegie
Mellon University, Pittsburgh, Pennsylvania, Technical Report CMU/SEI-2004–TR–014, 2005.
[16] Monteiro, P., Machado, R., Kazman, R. and
Henriques, C. : Dependency analysis between
CMMI process areas, in Proceedings of the 11th international conference on Product-Focused Software
Process Improvement (PROFES’10), 2010, pp. 263–
275.
[17] Team Software Process, http://www.sei.cmu.
edu/tsp/(2015 年 4 月 20 日閲覧)
[18] 山田真也，日下部茂，大森洋一，荒木啓二郎：ソフ
トウェア開発チームプロセス演習 TSPi へのモデル指向
形式手法 VDM の導入事例，ソフトウェア技術者協会
ソフトウェアシンポジウム SS2012 予稿集, 2012.
[19] Woodcock, J., Larsen, P. G., Bicarregui, J. and
Fitzgerald, J. : Formal methods: Practice and experience, ACM Comput. Surv., Vol. 41, No. 4(2009),
pp. 19:1–19:36.
日下部茂
1989 年九州大学工学部情報工学科卒
業．1991 年同大学大学院総合理工学
研究科情報システム学専攻修士課程
修了．同専攻助手を経て，現在，九
州大学大学院システム情報科学研究院情報知能工学
部門准教授．関数型言語，並列処理，細粒度マルチス
レッド処理，ソフトウェア工学，形式仕様記述，プロ
セス改善モデルなどの研究に従事．博士 (工学)．
コンピュータソフトウェア
136
林信宏
2011 年北陸先端科学技術大学院大学
情報科学研究科博士学位取得．2012
テム設計及び組込みシステムソフトウェアに関する
研究に従事．情報処理学会, 電子情報通信学会, IEEE
Computer Society 会員．
年台湾中央研究院情報科学研究所ポ
荒木啓二郎
スドク研究員．2013 年九州大学大学
九州大学大学院工学研究科情報工学
院システム情報科学研究院学術研究員，現在に至る．
専攻修士課程修了．九州大学工学部
博士 (情報科学)．ソフトウェア検証技術，形式手法
助教授，奈良先端大教授，などを経
をソフトウェア工学に適用する研究に従事．ACM,
IEEE 会員．
て，現在，九州大学主幹教授，大学
院システム情報科学研究院情報知能工学部門．九州大
大森洋一
1993 年京都大学・工学部情報工学科
卒．1998 年奈良先端科学技術大学院
大学博士課程修了．同年高知工科大
学工学部助手．2004 年九州大学助手．
2007 年同助教，現在に至る．博士 (工学)．高次シス
学伊都図書館長，九州大学アーキテクチャ指向フォー
マルメソッド研究センター長，などを兼務．工学博
士．日本学術会議連携会員．形式仕様記述，フォーマ
ルメソッドに基づくソフトウェア開発方法論，などの
研究に従事．

Download Report