AccuRev －プロセス指向構成管理・変更管理ツール－
変更管理への適用
ソフトウェア開発において、やっかいな問題であるデグレードの防止に効果を発揮する『変更管理』について、例を挙げながら、その重要性やAccuRevで実現する構成管理と変更管理の統合をご紹介します。
ソフトウェア資産の整合性の確保
ソフトウェア開発の現場においては、ユーザーの満足するサービスや製品をいち早く市場に投入するために高品質・短納期で高機能なソフトウェアを開発しなければなりません。その上、1つのソフトウェアにおいて派生開発と保守開発を並行して行うこともあり、1つのソフトウェア資産からたくさんの新たなソフトウェアが開発されています。ソフトウェアのほとんどが過去資産の流用であり、新規で開発されるソフトウェアの割合は減少しています。このような開発の現場においては、いかに効率的にソフトウェア資産の整合性を取るのかが重要となります。
以下にソフトウェアの整合性が取れていない例をご紹介します。
以下にソフトウェアの整合性が取れていない例をご紹介します。
過去に修正したはずの不具合が別の新しいリリースバージョンで再発してしまう（デグレード）
上のようなVersion1.1とVersion2.0の例であれば、比較的簡単に原因（どの修正が反映されていないために発生してしまったか）を特定できます。しかしながら、通常は原因を究明するには多大な工数が必要になります。ばあいによっては、過去の不具合修正をした担当者を呼び出し、修正した箇所を聞き取り、ソースコード中の該当箇所を特定しなければなりません。また、該当箇所が判明した後、過去の修正を反映（マージ）しようにも既にソフトウェアの構造が変わってしまったため、反映により新たな不具合を生みだしてしまう、という更なる悲劇が起るかもしれません。
どうすればこのような修正漏れを未然に防ぐことができたのでしょうか。
変更管理の重要性
ソフトウェア開発における変更管理とは「変更要求について影響を正しく把握し、計画を立て、変更作業を実施し、結果を確認する、という一連の作業を管理し、ソフトウェアの整合性を確保すること」
変更管理では開発者が理由なくソースコードを変更することを許可しません。変更には変更理由として変更要求が必ず関連付けられていなければなりません。これにより、意図しない変更がリリースバージョンに含まれることはありません。
変更管理を用いたソフトウェア開発を実施する場合、多くの障壁が存在します。成果物であるドキュメントやソースコードに対するすべての変更を手動で管理するには限界がありますし、変更管理のための開発プロセスを策定したとしても、それをすべての開発メンバーが順守するかどうかは個人の裁量に依存します。
また変更要求の管理に表計算ソフトを利用するケースを多く見受けられますが、この方法は手間がかかる割にうまく運用できず、管理が破綻するか不十分となりがちです。そのため、こちらはお勧めできません。その理由として、以下のようなことが考えられます。
- 変更要求の承認に人の力が必要になる
承認は特定の権限を持つ人物が行うべき処理です。しかし、表計算ソフトでの管理の場合、アクセス制限の機能が不十分なため、権限を持たない人物が承認情報を書き換えることができてしまいます。 - 履歴の管理ができない 過去の変更を誰がいつ追加・承認・実施したのかをデータとして入力してなければ後から参照することができません。
- 開発者の手間がかかる
開発者は構成要素を構成管理システムに登録しつつ、別途変更要求管理のドキュメントも更新しなければなりません。小規模の開発であれば選任者で処理できますが、将来のメンテナンス性や規模が大きくなった場合に対応できなくなってしまいます。
円滑な変更管理プロセスを実現するAccuRevの3つの柱
AccuRevは構成管理とプロセス管理を同時に行うことができ、さらに内部に課題管理の仕組みを持っています。
変更要求と成果物の変更を一元管理することができ、面倒な外部ドキュメントと成果物の関連付けを手動で行う必要がありません。
変更管理をAccuRevで実現した場合の特長をご紹介します。
図：AccuRevの変更管理プロセスのサポート
開発プロセスを見える化する
AccuRevに付属するStreamBrowserを用いることで、構成管理システム上にプロセスを表現できます。開発者は自身の作業結果（変更）をストリーム（プロセス）に登録することで、開発プロセス中のどのプロセスでどの変更を実施したかを自動的にAccuRevに記録させることができます。
変更要求によって、いつ、何が変更されたのか？を管理する
AccuRevにはAccuWorkという課題を管理する機能が付属しています。従来の構成管理ツールのように、外部の課題管理システムを準備する必要がありません。AccuWorkで変更要求を管理することにより、開発者がAccuRevに変更を登録する際にどの変更要求のための作業を実施したかを一緒に登録し管理できます。
「変更要求⇔構成要素」の関連を容易に知ることができるため、リリース前にどんな修正が含まれているソフトウェアかをレビューすることで、過去に修正した不具合が最新バージョンにて再発してしまうような問題の発生を未然に防止できます。
また、この「変更要求⇔構成要素」の関連付けを実施しないと登録できないように設定できるため、利用者に対して、この関連付けを強制できます。そのため、意図しない変更が含まれたソフトウェアがリリースされることはありません。
“承認プロセスの共有”と“開発者のプロセスの順守”を実現する
AccuWorkを用いて要求の承認状況を管理することができます。ある特定のメンバー（リーダーなど）のみが承認する仕組みを構築することで、開発者の独断により変更が登録されるようなことはありません。また、変更した構成要素の登録に関しても、権限設定を行うことでリーダー以外にはリリースバージョンのソフトウェアをパッケージングさせない、といったことも可能です。
- StreamBrowser：リリース用のストリームに権限の設定を行い、特定のメンバーのみがリリースバージョンを作成できるようにする
- AccuWork：AccuWorkの権限の設定により、特定のメンバーのみが要求をクローズすることができるようにする
要件の抜け漏れや影響範囲を特定する
ここまでに記載した機能を用いることによって、AccuRevにてトレーサビリティマトリクス※を生成することが可能です。以下に一例を記載します。
※トレーサビリティマトリクスとは、トレーサビリティを可視化するために、上位要求と下位要求や機能要求と関数名といった任意の関連を表に表したもの。
※トレーサビリティマトリクスとは、トレーサビリティを可視化するために、上位要求と下位要求や機能要求と関数名といった任意の関連を表に表したもの。
上のトレーサビリティマトリクスでは、変更要求とそれに関連する変更が開発プロセス中のどのプロセスで行われたかを示したものです。さらに細かい粒度のトレーサビリティマトリクスも取得が可能です。
最後に
変更管理を実現しようとして、プロセスを順守させるために「開発者が変更をシステムに登録する際にルール化されたコメントの入力を促す」などは、開発者の効率を下げることに繋がります。
AccuRevを利用することにより、開発者任せの“あいまいさ“が排除され、AccuRevを利用するだけで開発プロセス・承認プロセス・変更管理が実現できるという開発者にやさしい構成管理のインフラを提供できます。
AccuRevを用いた変更管理は、お使いの開発プロセスに柔軟に対応が可能です。この機会にぜひ、AccuRevをお試しください！
