開発作業記録の形式化に基づくプロセス評価
松下誠Ý

実際に行われたプロセスがどのようなものであったかを評価する際には，その作業の内容自体を効率よく記録する方法が有用である．しかし，作業者に負担を強いるような形式の場合，それが逆に負担となり，正しい作業内容の把握を困難にする可能性がある．本稿では，プロセスの結果を可能な限り形式的に，かつ，効果的に収集する方法と，それに基づいたプロセスの評価方法について考察を行う．

Process Assessments Based on
Formalization of Process Activities
M AKOTO M AT SUSH ITAÝEffective recording all of the activities which went through actual software development processes is very
important for actual software process assessments. However, it is hard to establish if activity recording
enforces engineers to do some extra, monotonous, and unwanted activity. In this paper, I discuss about aformalization of effective recording activities and an assessment methodology based on them.

1. は じ め に
開発の初期段階において，何らかの方法でソフトウェア開発の手順をあらかじめ定め，それに基づいて実際の作業を行うという考え方は，この 10 年でソフ
トウェアプロセスの研究と共に広く普及してきた．ソ

そこで本稿では，すでに行われたソフトウェア開発を対象として，その作業記録から形式的な作業内容の記録を抽出し，それを用いたプロセス評価を行う方法について考察を行う．

2. 開発作業記録の形式化

フトウェアプロセスを「プロセスの定義」「プロセスソフトウェア開発には多様な形態があり，ポリシー，の実行」「プロセスの評価」という 3 つの軸で捉えた組織，ツールなどもまたさまざまである．しかし，ほ場合1) ，前者 2 つについては多くの研究成果が生まれ

とんどのソフトウェア開発においては「最終成果物でているが，プロセスの評価については，評価尺度の問あるソフトウェアやドキュメント等を作成する」とい

題や評価手順，評価の運用方法など，未だ多くの未解う一般的な目標が存在する．これらは普通ファイルと決課題を抱えている．また，実際に行われた開発が評して存在しており，比較的コンピュータ処理の対象と価の対象となるため，ある評価結果が一般的な性質をしやすいものである．

示しているかという問題や，評価結果自体の詳細を公開しにくいといった問題もある．

また，多くのソフトウェア開発では，ファイルは何らかの構成管理ツールによって管理されている．特行われたソフトウェアプロセスを実際に評価する際に，オープンソースソフトウェア開発においては，開には，「過去行われた作業内容がどのようなものであっ発時に用いられる数少ない基盤ツールであり，具体的たか」をより正確に，かつ確実に後から確認できる方には CVS3) などが広く用いられている．これら構成管法が必要である．また，用いる評価基準，評価手順に理ツールは，組織が用いるソフトウェアプロセスとは関わらず，その過程や結果を共有し，多くの人々によっ独立して用いることが可能である．て分析を行うことで，これまで困難とされてきた多く

そこで本稿では，ソフトウェアプロセスの評価を行の問題に対して何らかの解決を与えることができるとう際の評価対象として，構成管理ツール内に蓄積され考えられる．

た情報を元にすることを考える．この種の情報はすでにツール内に保存されているものであるため，形式的Ý 大阪大学大学院基礎工学研究科
Graduate School of Engineering Science, Osaka Universityなデータを比較的容易に抽出することが可能であると考えられる．また，抽出されたデータは実行されたソフトウェアプロセスに依存しないため，多様な評価手セスであると考えることができるため，評価の対象，法に適用させることが可能であると考えられる．

内容，目的，および手順などは，プロセスを形式的にすでに，この種の情報を使ってソフトウェアメトリ定義する手法と同様の手法を用いて，やはり形式的にクスを計測するための環境2) について研究を行ってき記述することが可能であろう．仮に運用上の問題が主た．この環境では，開発者に対して，構成管理ツール観的な要素として残されたとしても，どこまでがプロの存在をファイルシステムとして隠蔽することにより，セス標準で定められた範囲であり，どこからが主観的開発者に負担をかけることなく詳細なデータ収集を行に判断された部分なのかを明確にできるのではないだうことが可能となっている．しかし，本環境の本質はろうか．

版管理システムを用いてデータ収集を行う所にあり，これは一般のソフトウェア開発にそのまま適用できると考えている．
版管理システムから抽出した作業データは，その後に行われる各種分析ツールとの連携のために使われる．
一般的には，複数の異なるツール同士で何らかの連携を行う場合には，そのデータ統合が重要となる．そのために，作業データを XML 等を用いて形式的に扱えるようにすることが望まれる．この種の形式化のためには，一般的なソフトウェアプロセスの各要素を表現ことが可能な，何らかのモデルを構築するか，あるいは既存の標準的なプロセスモデルから導出することが必要になるであろう．

3. プロセス評価
プロセスの評価を確実に，かつ安定した結果として得るためには，なるべく主観を排除した形で評価を行うことが望ましい．つまり，仮に客観的なデータを前節の方法によって得られたとしても，その評価を主観的に行うことはできない．
これまで，多くの品質評価手法が提案されてきており，ISO/IEC 15504 などのような標準も生まれてきている．この種の標準は，実際に行われたプロセスの形態とは独立に，ソフトウェア開発作業として行わなければならない具体的な作業内容等について，その評価項目や評価基準を定めている．しかし，実際に「どのようにして」評価を行うかという観点については，評価を実施する個人あるいは組織に委ねられている部分もある．
個々のソフトウェア開発へプロセス標準が柔軟に対応するためには，何らかの形で，評価を実際に行う際にのみ決定し得る要素が存在していることは必要悪であるという考え方も可能であろう．しかし，それらが同時に，確実にかつ安定した評価結果を得るという本来の目的を達成することを妨げているとも言える．
そこで本稿では，前述した形式的な作業データに基づいて，主観を用いないプロセスの評価が必要であると考える．プロセス評価は，その手順自身もまたプロ

参考

文 献

1) 井上，松本，飯田: “ソフトウェアプロセス”，ソフトウェアテクノロジーシリーズ，共立出版 (2000).
2) 山本，松下，井上: “堆積型ファイルシステム
Moraine とメトリクス環境 MAME への適用”, コ
ンピュータソフトウェア, Vol.18, No.3, pp. 8–18
(2001).
3) Concurrent Versions System, http://www.cvshome.org/