Interstage Application Development Cycle Manager V10.1

解説書

B1WD-2771-01Z0(00)2009年12月

- 2 -

商標 Java およびすべての Java 関連の商標とロゴマークは、米国およびその他の国における Sun Microsystems, Inc.の商標または登録商標です。

Microsoft、Windows、Windows Server、Windows Vista は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

UNIX は米国およびその他の国における the Open Group の登録商標です。

Linux は Linus Torvalds 氏の登録商標です。

そのほか本マニュアルに記載されている会社名および製品名

は、それぞれの所有者の商標または登録商標です。

Copyright © FUJITSU LIMITED 2008-2009

他言語への翻訳を含め、富士通株式会社の書面による事前の許

可なしに、本マニュアルのいかなる部分もいかなる形によって

も複製することは禁じられています。

［高度な安全性が要求される用途への使用について］

本製品は、一般事務用、パーソナル用、家庭用、通常の産業等の一般的用途を想定して

開発・設計・製造されているものであり、原子力施設における核反応制御、航空機自動

飛行制御、航空交通管制、大量輸送システムにおける運行制御、生命維持のための医療

用機器、兵器システムにおけるミサイル発射制御など、極めて高度な安全性が要求さ

れ、仮に当該安全性が確保されない場合、直接生命・身体に対する重大な危険性を伴う

用途（以下「ハイセイフティ用途」という）に使用されるよう開発・設計・製造された

ものではありません。お客さまは本製品を必要な安全性を確保する措置を施すことなく

ハイセイフティ用途に使用しないでください。また、お客さまがハイセイフティ用途に

本製品を使用したことにより発生する、お客様または第三者からのいかなる請求または

損害賠償に対しても富士通株式会社およびその関連会社は一切責任を負いかねます。

- 3 -

本マニュアルについて 本マニュアルでは、Interstage Application Development Cycle Manager（以降、ADM と呼びます）の概要を説明します。

本マニュアルの構成は、以下のとおりです。

タイトル 説明

1章 ADMについて ADM とその主なコンポーネントおよびアーキテクチャーの概要を説明します。

2章 ライフサイクル管理（LCM）

LCM の機能と基本的な概念を説明します。

3章 ソフトウェア構成管理（SCM）

SCM の機能と基本的な概念を説明します。

4章 ドキュメント管理（DMS） DMS の機能と基本的な概念を説明します。

5 章 共通コンポーネント ADM の共通コンポーネントの概要を説明します。

6 章 共通機能 ADM のすべてのコンポーネントに共通する機能の概要を説明します。

本マニュアルの対象読者 本マニュアルは、本製品の導入を検討されているすべての方を対象に書かれています。本

マニュアルは本製品を知らない方、およびすでに本製品を使い始めている方を対象として

います。

略語 本マニュアルでは、Interstage プロダクトとコンポーネントに以下の略語を使用します。

BPM Interstage Business Process Manager

ADM Interstage Application Development Cycle Manager

COC コントロールセンター（Control Center）コンポーネント

DMS ドキュメント管理（Document Management）コンポーネント

LCM ライフサイクル管理（Lifecycle Management）コンポーネント

SCM ソフトウェア構成管理（Software Configuration Management） コンポーネント

- 4 -

関連ドキュメント 本マニュアルに加えて、本製品に関する以下のドキュメントを利用できます。

• 「インストールガイド」：インストールについて説明したマニュアルです。

• 「アンインストールガイド」：アンインストールについて説明したマニュアルです。

• 「ライフサイクル管理（LCM） ユーザーズガイド」：ライフサイクル管理（LCM）コンポーネントをクライアントインターフェースから操作する方法を説明したオンラ

インマニュアルです。

• 「 ソフトウェア構成管理（SCM） ユーザーズガイド」：ソフトウェア構成管理（SCM）コンポーネントをクライアントインターフェースから操作する方法を説明したオンラインマニュアルです。

• 「ドキュメント管理（DMS） ユーザーズガイド」：ドキュメント管理（DMS）コンポーネントをクライアントインターフェースから操作する方法を説明したオンライン

マニュアルです。

• 「コントロールセンター（COC） ユーザーズガイド」：コントロールセンター（COC）コンポーネントをクライアントインターフェースから操作する方法を説明したオンラインマニュアルです。

• 「管理者ガイド」：管理者向けの操作について説明したマニュアルです。

• 「カスタマイズガイド」：カスタマイズの方法を説明したマニュアルです。

• 「コマンドリファレンス」：コマンドラインインターフェースについて説明したマニュアルです。

- 5 -

目次

1 ADMについて ..................................................................... 7

1.1 アーキテクチャーとインターフェース...................................................10

1.2 運用とインストールの形態.....................................................................11

2 ライフサイクル管理（LCM）............................................. 13

2.1 アプリケーションとサービス .................................................................13

2.2 ナビゲーションと情報検索.....................................................................14

2.3 要件管理..................................................................................................15

2.4 変更管理..................................................................................................17

2.5 リリース管理...........................................................................................20

2.6 プロセス制御...........................................................................................22

2.7 セキュリティとアクセス制御 .................................................................26

2.8 カスタマイズと拡張................................................................................27

3 ソフトウェア構成管理（SCM） ......................................... 28

3.1 SCMのプロジェクト ...............................................................................28

3.2 プロジェクト定義 ...................................................................................30

3.3 リソースとバージョンの管理 .................................................................30

3.4 コンフィグレーションの管理 .................................................................34

3.5 プロダクト ..............................................................................................37

3.6 セキュリティとアクセス制御 .................................................................38

3.7 変更管理..................................................................................................40

3.8 LCMとの統合 ..........................................................................................40

- 6 -

3.9 開発環境との統合 ...................................................................................42

3.10 設定とカスタマイズ................................................................................42

4 ドキュメント管理（DMS） ................................................ 45

4.1 ドキュメントライブラリ ........................................................................45

4.2 ドキュメントの編集とバージョン化 ......................................................47

4.3 ドキュメントへの読み取り専用アクセス ...............................................49

4.4 ドキュメント検索 ...................................................................................50

4.5 DMSとSCM.............................................................................................51

4.6 セキュリティとアクセス制御 .................................................................52

4.7 変更管理..................................................................................................52

4.8 カスタマイズと拡張................................................................................53

5 共通コンポーネント............................................................ 54

5.1 コントロールセンター（COC）.............................................................54

5.2 リポジトリ ..............................................................................................57

6 共通機能 ............................................................................. 58

6.1 監査ログ..................................................................................................58

6.2 レポート..................................................................................................58

6.3 シングルサインオン................................................................................58

6.4 セキュリティとアクセス制御 .................................................................59

6.5 カスタマイズと拡張................................................................................60

用語解説 .............................................................................................. 61

- 7 -

1 ADMについて ADM は、サービス、ソフトウェアプロダクト、アプリケーションの管理を支援する製品です。要件管理、変更管理から、ソフトウェア開発、メンテナンス、リリース管理、ア

セット管理まで、サービスとアプリケーションのライフサイクルを管理します。

ADM の機能は、開発プロセス管理、開発とメンテナンスのコスト削減、関連規制法への適合、サービスとアプリケーションの統制に役立ちます。ADM は、リポジトリベースのテクノロジーとさまざまなインターフェースによって、拡張性、信頼性、柔軟性にたいへ

ん優れていて、高度なカスタマイズも可能なシステムになっています。

ADM は以下のコンポーネントから構成されています。白い囲みはプロダクトを、濃い灰色の囲みはプロダクトを構成するコンポーネントを示しています。

ライフサイクル管理 ADM のライフサイクル管理（LCM）コンポーネントによって、サービスやアプリケーションのライフサイクルに関連するすべてのアクティビティを開始し制御できます。

• 要件管理は、サービスとアプリケーションに関連するすべての要件の収集と分類をサポートします。新規サービスへの要望から既存のアプリケーションの機能強化提案ま

で、あらゆる種類の要件を管理できます。さまざまなレベルで詳細な要件を記述でき

ます。また、要件の変更、優先順位付けおよび分類や、要件間の依存関係の保守がで

きます。

- 8 -

• 変更管理は、サービスやアプリケーションに対して行われたすべての変更の制御をサポートします。あらゆる種類の変更指示を規定し、変更指示に関連するすべての情報

（例えば、インパクト分析の結果、設計ドキュメント、レビュードキュメントなど）

を保守できます。変更指示は、例えば SCM で管理しているソースコードのような、その変更指示が影響を与える項目にリンクさせることができます。変更指示の優先順

位と分類や、変更指示間の依存関係の保守ができます。

• リリース管理は、サービスやアプリケーションのさまざまなバージョンやリリースの作成、計画、および監視をサポートします。サービスやアプリケーションごとに任意

の数のリリースを定義できます。また、リリースを複数のイテレーションに分割でき

ます。各リリースは、例えば SCM で管理しているソースコードコンフィグレーションのような、リリースを構成する要素にリンクさせることができます。リリースの分

類や優先順位付け、各リリースの説明や関連情報の保守、およびリリース間の依存関

係の作成ができます。

要件や変更指示は、サービスやアプリケーション全体に対して定義できます。定義された

要件や変更指示は、実装されるリリースに対して割り当てられます。要件は、1 つまたは複数の変更指示となることがあります。変更指示は、1 つまたは複数のサービスやアプリケーションのさまざまなリリースで実装されます。

LCM で実行されるすべてのアクティビティは、プロセスによって制御されます。プロセスは、単純なワークフローであったり、Interstage Business Process Manager（BPM）で定義された複雑な業務プロセスであったりします。プロセス制御によって、すべてのアク

ティビティが適任者によって計画どおり適切に実施されます。

LCM には、さまざまなプロセスへの対応とカスタマイズ機能（ユーザー定義属性、拡張機能）があり、お客様のあらゆる環境に合わせることができます。さらに、LCM は、フロントエンドの顧客関係管理システムやバグ追跡システム、バックエンドのビルドシステム、

テストシステム、配備システムのような外部システムに統合できます。ADM の本リリースでは、最も人気の高いバグ追跡システムの 1 つである Bugzilla と連携できます｡

LCM は、ソフトウェア構成管理（SCM）コンポーネント、およびドキュメント管理（DMS）コンポーネントとセットで Interstage Application Development Cycle Manager（ADM）プロダクトとして提供されます。Enterprise Edition は、Standard Edition にはない、BPM との統合を提供します。

LCMの詳細と概念については、2章を参照してください。

ソフトウェアとドキュメントの管理 ADM のソフトウェアとドキュメントの管理コンポーネントによって、サービスやアプリケーションの開発プロジェクトに対して、チームサポート、コンフィグレーション管理、

およびバージョン管理のための機能を提供します。

• ソフトウェア構成管理（SCM）は、サービスやアプリケーションに関連するソースコードなどのリソースの管理をサポートします。SCMによって、単純なアプリケーションから複雑な分散型システムまで、さまざまなソフトウェア開発プロジェクトを

管理できます。また、複数ユーザーによるアクセスや並行開発をサポートするための

チェックイン、チェックアウト機能、同期機能、および高度なセキュリティ機構を提

- 9 -

供します。プロジェクトのリソースは、コンフィグレーションで管理されます。コン

フィグレーションは、リリースまたはプロダクトごとにグループ化して管理できます。

リソース、コンフィグレーション、リリースは、ADM のライフサイクル管理コンポーネントによって管理、統合できます。SCMは、Interstage StudioやEclipseでの利用に最適化されていますが、他の開発環境へも容易に統合できます。SCMの詳細と概念については、3章を参照してください。

• ドキュメント管理（DMS）は、サービスやアプリケーションに関連するドキュメントの作成や保守をサポートします。例えば、プロダクト定義、仕様書、レビューレポー

ト、ユーザー向けドキュメント、マーケティング資料などの、ソフトウェア開発のラ

イフサイクルの中で作成されるドキュメントをDMSで管理できます。ドキュメントの管理を実現するため、DMSは、SCMで管理するソフトウェア開発プロジェクトに対してドキュメント管理固有のビューを提供します。プロジェクトやドキュメントは、

そのままDMSでアクセスし、取り扱うことができます。DMSの詳細と概念については、4章を参照してください。

DMS は、SCM を基盤とし、SCM および LCM とセットで Interstage Application Development Cycle Manager（ADM）プロダクトとして提供されます。

共通コンポーネント 共通コンポーネントは、他のすべてのコンポーネントに対する基本機能と統合機能を提供

します。

• コントロールセンター（COC）は、ADM のコンポーネントに対して中核となるアクセス機能と共通機能を提供します。複数の ADM システムや、他のシステム（例：ファイルシステム、ソースコード制御システム）への参照やアクセスデータを、リポ

ジトリに保存して保守でき、これらのシステムに直接アクセスできるようになります。

また、データの構造化、データプロパティの記述、およびユーザーごとのお気に入り

リストの管理ができます。COC では、ADM の他のコンポーネントで使われるカテゴリーを定義できます。さらに COC により、さまざまな SCM プロジェクトや DMS ライブラリに対して全文検索ができます。

• Enabler は、ADM の中核を成すリポジトリ管理システムです。Enabler は、データの統合的な保存と管理、ユーザーやアプリケーションによる柔軟で高性能なデータアク

セス、およびチーム連携の基盤を提供します。ADM のすべてのコンポーネントは、データを 1 つまたは複数のリポジトリに保存します。

共通コンポーネントの詳細と概念については、5章を参照してください。

共通機能 ADMのコンポーネントにはいくつかの共通機能があります。共通機能には、セキュリティとアクセス制御の概念、シングルサインオン、ログ記録とレポート機能、カスタマイズ機

能、および拡張機能があります。詳細については、6章を参照してください。

- 10 -

1.1 アーキテクチャーとインターフェース 以下の図に、ADM のアーキテクチャーとインターフェースの概要を示します。

ADM のコンポーネントは、1 つまたは複数の Enabler サーバに置かれた Enabler リポジトリにデータを格納します。

SCM と DMS は、検索インデックスを基盤にした全文検索を提供します。これらのインデックスは、1 つまたは複数の検索サーバに作成して保守します。

ADM のユーザーは、以下のインターフェースで作業できます。

• クライアントインターフェース クライアントインターフェースは、ADM の全機能を提供するグラフィカルユーザーインターフェースです。クライアントインターフェースは、Eclipse 技術を基盤とし、プラグインとして実装されています。そのため、クライアントインターフェースは、

Interstage Studio 開発環境や Eclipse のプラグインとしてインストールされます。

• コマンドラインインターフェース コマンドラインインターフェースは、Microsoft Windows のバッチファイルと、

- 11 -

UNIX/Linux のシェルスクリプトから構成されています。コマンドラインインターフェースは、SCM の全機能と、他のコンポーネントの基本機能を提供します。コマンドラインインターフェースを使用することにより、例えばビルドのためのバッチ処

理を作成したり、プログラミングすることなく ADM 機能をサードパーティ製のツールやソリューションに統合したりできます。

• Web インターフェース SCM と DMS は、クライアントインターフェースの他に、Web インターフェースも提供します。Web インターフェースはサーブレットを基盤として、Web ブラウザでSCM や DMS の特定の操作を実行できます。

1.2 運用とインストールの形態 ADM は、ADM クライアント、アプリケーションサーバ、ADM サーバコンポーネントの 3層アプリケーションとして実装されています。

以下の図に、インストールおよび運用の形態の概要を示します。

- 12 -

ユーザーは、以下の方法で ADM コンポーネントとインターフェースを操作できます。

• クライアントインターフェースとコマンドラインインターフェース：ユーザーは、コマンドラインインターフェース、または ADM クライアント機能のすべてを含むクライアントインターフェースを使って ADM を操作できます。クライアントは、ADM Web アプリケーションをインストールしたアプリケーションサーバ経由で、HTTP または HTTPS によってリポジトリや ADM サーバにアクセスします。Web アプリケーションには、ADM API と ADM の機能が含まれています。Web アプリケーションは、クライアントからのリクエストやデータをリポジトリやサーバコンポーネントに転送

して、クライアントにレスポンスを返します。Web アプリケーションは、リモートインターフェースとも呼びます。

• SCM と DMS の Web インターフェース：ユーザーは、Web ブラウザからでも SCMと DMS を操作できます。HTTP や HTTPS、ADM Web アプリケーションをインストールしたアプリケーションサーバ経由で、リポジトリにアクセスします。

- 13 -

2 ライフサイクル管理（LCM） ライフサイクル管理（LCM）では、サービスやアプリケーションのライフサイクルに関連するすべてのアクティビティを開始し制御できます。

• 要件管理：サービスとアプリケーションに関連するすべての要件の収集と分類をサポートします。

• 変更管理：サービスやアプリケーションに対して行われたすべての変更の制御をサポートします。

• リリース管理：サービスやアプリケーションのさまざまなバージョンやリリースの作成、計画、および監視をサポートします。

ライフサイクル管理コンポーネントは、相互に密接に統合されています。コンポーネント

で実行されるすべてのアクティビティは、プロセスによって制御されます。これにより、

すべてのアクティビティが、適任者によって計画どおり適切に実施されます。

LCMで作成し管理するデータは、リポジトリに格納されます。ユーザーは、クライアントインターフェースを使用して、データにアクセスできます。ADMのプロダクト、コンポーネント、インターフェース、および運用の形態の詳細については、1章を参照してください。

以下では、LCM の機能とサービスの概要を説明し、基本的な概念を紹介します。

2.1 アプリケーションとサービス LCM では、アプリケーションやサービスのライフサイクルに関連するアクティビティを制御します。アプリケーションとは、例えば、ADM 自身やユーザーにより開発されたツールのようなソフトウェア製品などを指します。サービスには、インフラストラクチャー

サービスや Web サービスがあります。

LCM では、さまざまなアプリケーションやサービスを表現できます。アプリケーションやサービスごとに、複数のリリースを作成し保守できます。また、アプリケーションやサー

ビスに対して要件や変更指示を定義し、定義した要件や変更指示を実装先の個々のリリー

スに割り当てられます。

すべてのアプリケーション、サービス、リリース、要件、または変更指示は、LCM 上ではそれぞれに対応するアイテムで表されます。アイテムは、プロパティおよび他のアイテム

と関連付けて表示されます。さらに、カテゴリーを割り当てたり、各アイテムに添付ファ

イルとして複数の説明ファイルを追加したりできます。

以下の図に、クライアントインターフェースに表示された、リリース、要件、および変更

指示のあるアプリケーションとサービスの例を示します。

- 14 -

すべてのアイテムおよびアイテムに関連するすべてのデータは、リポジトリに格納されま

す。1 つのリポジトリを使用して、すべてのサービスとアプリケーションを管理できます。また、データを複数のリポジトリに分散させることもできます。ただし、ある特定のサー

ビスまたはアプリケーションに関連するすべての情報は、1 つのリポジトリに格納されます。

2.2 ナビゲーションと情報検索 LCM では、さまざまな方法を使用して、サービスやアプリケーションに関する情報や関連するリリース、要件、および変更指示を取得できます。

• ナビゲーション：クライアントインターフェースには、すべてのアイテムおよびアイテム間の関連がツリービューに表示されます。このツリービューは、一般的なフォル

ダー構造と同様にナビゲートできます。ツリービュー内でアイテムを選択すると、選

択したアイテムの詳細が表示されます。アイテムの詳細として、選択したアイテムの

情報や、選択したアイテムに関連するアイテムの情報が表示されます。

• フィルター：高性能のフィルター機能を使用して、目的の変更指示や要件だけに限定して表示できます。

- 15 -

• レポート：さまざまなアイテムに対するさまざまなレポートを使用して、必要な情報を取得できます。レポートは、必要に応じてカスタマイズできます。フィルター機能

は、レポートにも適用できます。また、レポートを HTML、XML、CSV、Microsoft Excel といった様々な形式でファイルシステムにエクスポートできるため、簡単にレポートを処理できます。

• 変更指示と要件のインポート：Microsoft Excel を使用して、変更指示や要件を定義できます。XLS ファイルを LCM にインポートできます。これにより簡単にデータのやり取りや再利用ができます。

2.3 要件管理 要件管理は、サービスやアプリケーションに関連するすべての要件の収集と分類をサポー

トします。

要件 要件は、特定のサービスまたはアプリケーションが、関係者にとって価値があり有用であ

るにはどうあるべきかという条件を文書化したものです。

以下のようなさまざまな種類の要件を定義して管理できます。

• ユーザーまたは顧客の要件：この要件を実現すると、ユーザーまたは顧客の業務や満足度が改善されます。例えば、新しい機能やサービスを提供してほしい、アプリケー

ションを使いやすくしてほしい、エラーを減らしてほしいなどの要望が含まれます。

• ビジネス要件：この要件を実現すると、自分自身の業務が改善されます。例えば、収益を増やしたい、インフラストラクチャーを強化したい、特定の市場向けのソフト

ウェアプロダクトを開発したいなどの要望があります。

• 機能要件と非機能要件：この要件を実現すると、制約を取り除いたり、アプリケーションまたはサービスの動作を変更したりできます。例えば、ソフトウェアプロダク

トを新しいプラットフォームに移行する、特定の品質基準を満たすなどの要件が含ま

れます。

要件の定義 特定のアプリケーションまたはサービスに対して要件を定義します。実現する必要がある

要件がある場合は、通常、要件をアプリケーションまたはサービスの関連するリリースに

割り当てます。

要件名は、連続する番号を使用して LCM によって自動的に生成されます。

要件の記述 要件は、さまざまな詳細レベルで説明を付加できます。

• 要件の概要を記述できます。

- 16 -

• 要件に関連する重要な情報を記述できます。HTML エディタを使用して記述をフォーマットできます。

• 要件を提示したステークホルダーを記述できます。

• 各要件の実装のリスクと効果を記述できます。

• 要件のユースケースを記述できます。

• 各要件には、顧客から提供された要件ドキュメント、サードパーティ製ツールによるユースケース分析など、より詳細な情報を提供するファイルを添付できます。

LCM のカスタマイズ機能を使用すると、組織の必要に応じて、要件に関する追加の説明プロパティを定義できます。

要件のグループ化と整理 LCM は、サービスやアプリケーションに関連付けられた要件を分類、グループ化、および整理するためのさまざまな方法を提供します。

• アプリケーションまたはサービスへの割当て：要件は、常に特定のサービスまたはアプリケーションに割り当てられています。要件は、まずサービスまたはアプリケー

ションへの割当てに基づいてグループ化され、ソートされます。アプリケーションや

サービスごとに、関連する要件を分類するための要件フォルダーを追加できます。

• 優先度とランク：各要件に優先度とランクを割り当てて、他の要件と比較した重要度を表せます。

• カテゴリー：要件に適切なカテゴリーを割り当てて、要件をグループ化およびソートできます。指定できるカテゴリーは COC で定義されます。

要件のスケジューリング 通常、要件のスケジューリングは、それらが満たされるべきアプリケーションやサービス

のリリースに割り当てることにより実施されます。１つの要件は、１つまたは複数のリ

リースに割り当てられます。リリースへの割当てとは無関係に、要件に対して、実現まで

の期限を設定できます。

要件に対して、時間、日、週、月、または年単位で工数を見積ることができます。

LCM のカスタマイズ機能を使用することで、要件に対して任意のプロパティを定義し、定義したプロパティをスケジューリングや計画に使用できます。さらに、フィルターを指定

して要件のバックログを確認できます。このフィルターにより、まだスケジュールされて

いないすべての要件を簡単に確認できます。

要件の依存関係の管理 サービスやアプリケーションに関連付けられた任意の要件間の依存関係を作成および保守

できます。依存関係とは、特定の（依存）要件を実現する前に、別の（必須）要件を実現

する必要があるということを意味します。

- 17 -

要件のレビューと変更 要件は、そのライフサイクル内を進行する中で、変更やレビューを受けることができます。

要件のプロパティを更新できます。また、添付ファイルの追加や削除もできます。要件の

レビューアーは、例えば、要件を承認または拒否する理由を述べるなど、コメントを追加

できます。

要件と変更指示 通常、1 つの要件からは、1 つ以上の変更指示が生成されます。各要件に対して、新しい変更指示を作成したり、既存の変更指示を割り当てたりできます。要件をリリースに割り

当てることにより要件をスケジュールすると、対応する変更指示が自動的に作成されます。

レポートを使用すると、要件に関連付けられた変更指示、変更指示のステータス、変更指

示に対して実行されているアクティビティなどの包括的な情報を取得できます。

要件のエクスポートとインポート サービスやアプリケーションの要件を、Microsoft Excel 形式や CSV 形式でエクスポートできます。これにより、要件の保守、更新、他者への受け渡しなどを簡単に実施できます。

また、別のサービスやアプリケーションに要件をインポートできます。

2.4 変更管理 変更管理は、サービスやアプリケーションに対して行われたすべての変更の制御をサポー

トします。

変更指示 LCM では、アプリケーションやサービスへの変更を、変更指示によって記述および制御します。変更指示は、サービスやアプリケーションに対する特定の変更に対する指示を表し

ます。例えば、ソフトウェアプロダクトのコンポーネントのバグを修正するための指示や、

サービスの特定の動作を変更する指示などがあります。

通常、変更指示は、バグ追跡システムや顧客関係管理システムで報告された要件またはイ

ンシデントから作成されます。例えば、ソフトウェアプロダクトを新しいプラットフォー

ムに移行する要件により、影響を受けるそれぞれのコンポーネント、またはコードの各部

に対して、いくつかの変更指示が生成されます。

変更指示の定義 変更指示は、以下の方法で作成できます。

• リリースに要件を割り当てることにより要件をスケジュールする場合、変更指示が自動的に作成され、その要件を実現するために同じリリースに割り当てることができま

す。

- 18 -

• LCM は、さまざまなインシデント管理システムやバグ追跡システムと統合できます。このようなシステムでインシデントまたはバグが報告された場合は、対応する変更指

示が LCM で自動的に定義されます。 現在のリリースでは、LCM と Bugzilla バグ追跡システムを連携することができます。このシステムは、以下のように設定して使用できます。Bugzilla でバグが報告された場合は、対応する変更指示が自動的に作成され、Bugzilla のバグにリンクされます。Bugzilla がマスタになり、LCM 側では、バグに関する情報（ステート、優先度、責任元ユーザーなど）を継続的に同期します。

• アプリケーションやサービスに対して、任意の数の変更指示を明示的に定義し、それらを要件に関連付けて、実装先のリリースに割り当てることができます。

変更指示名は、連続する番号を使用して、LCM によって自動的に生成されます。

変更指示の記述 変更指示には、さまざまな詳細レベルで説明を付加できます。

• 変更指示の概要を記述できます。

• 変更指示に関連する重要な情報を記述できます。

• 各変更指示には、バグレポート、インシデントの分析と履歴、コードレビューレポートなど、より詳細な情報を提供するファイルを添付できます。

LCM のカスタマイズ機能を使用すると、変更指示に関する追加のプロパティを定義できます。カスタマイズしたプロパティを使用して、さらに詳細な記述や整理ができます。

変更指示のグループ化と整理 LCM は、サービスやアプリケーションに関連付けられた変更指示をソート、グループ化、および整理するためのさまざまな方法を用意しています。

• アプリケーションやサービスへの割当て：変更指示は、常に特定のサービスまたはアプリケーションに割り当てられています。変更指示は、まずサースまたはアプリケー

ションへの割り当てに基づいてグループ化され、ソートされます。アプリケーション

やサービスごとに、関連する変更指示を分類するための変更指示フォルダーを追加で

きます。

• 追加属性： 異なるタイプ（例えばバグ修正やエンハンス要望）、優先度、およびCOC で定義されたカテゴリーを割り当てることで、変更指示をグループ化、ソート、および整理できます。

変更指示のスケジューリングと実装 通常、変更指示は、サービスまたはアプリケーションの特定のリリースで実現されます。

そのため、適切なリリースに変更指示を割り当てることで、変更指示のスケジュールが決

まります。1 つの変更指示は、1 つのリリースに対してだけスケジュールできます。類似する変更指示を異なるリリースで実行する場合は、その変更指示を各リリースにコピーし

ます。さらに、フィルターを指定して変更指示のバックログを確認できます。このフィル

- 19 -

ターにより、特定のリリースやイテレーション割り当てられていないため、まだスケ

ジューリングされていない変更指示を簡単に確認できます。

変更指示に対して、期限を設定できます。通常、計画の立案は、変更指示に対してではな

く、変更指示の元となる要件に対して実施します。

変更指示を実現するには、通常、1 つ以上の特定のアイテム（アプリケーションの特定のソースコードファイル、サービスのコンフィグレーションアイテムなど）を作成、変更、

または削除する必要があります。一般に、これらのアイテムは、ソースコード管理システ

ム、またはSCMなどの構成管理システムで保守されています。これらのアイテムは、変更指示を割り当てるリリースに定義されているコンフィグレーションの 1 つに存在します。リリースコンフィグレーションの詳細については、「2.5 リリース管理」を参照してください。

アイテムを作成、変更、または削除する場合は、アイテムを対応する変更指示に割り当て

ます。例えば、SCM でソースコードファイルの変更をコミットするときに、対応する変更指示を指定できます（変更指示の指定が必須の場合もあります）。

LCM では、変更指示の影響を受けたアイテム（「変更アイテム」）は、リンクによって表されます。通常、ADM 内では、変更アイテムのリンクは、SCM で管理されているアイテムを指します。このリンクは、対応する SCM アクションが実行されると自動的に作成されます。このリンクから、それぞれの変更指示に対して実行されている変更の概要をいつ

でも取得できます。

変更指示の依存関係の管理 サービスやアプリケーションに関連付けられた任意の変更指示の間の依存関係を作成およ

び保守できます。依存関係とは、特定の（依存）変更指示を実現する前に、別の（必須）

変更指示を実装する必要があるということを意味します。

変更指示のエクスポートとインポート サービスやアプリケーションの変更指示を、Microsoft Excel 形式や CSV 形式でエクスポートできます。これにより、変更指示の保守、更新、他者への受け渡しなどを簡単に実

施できます。

また、別のサービスやアプリケーションに変更指示をインポートできます。

- 20 -

2.5 リリース管理 リリース管理は、サービスやアプリケーションのさまざまなバージョンやリリースの作成、

計画、および監視をサポートします。

リリース LCM で管理されるアプリケーションやサービスごとに、複数のリリースを作成および保守できます。リリースは、アプリケーションやサービスの初期バージョンまたはアップグ

レードバージョンです。リリースには、アプリケーションやサービス全体が完全に機能す

るために必要なすべての成果物が含まれます。

あらゆる目的とスコープでリリースを定義できます。例えば、ソフトウェアプロダクトの

リリースとして、製品の初版、新しいメジャーバージョン、新しいマイナーバージョン、

サービスパック、修正版などが考えられます。サービスのリリースは、例えば、ユーザー

に新機能を提供したり、新しいユーザーグループがサービスを使用できるようにしたりす

るために作成されます。

リリースの定義 アプリケーションまたはサービスのリリースの定義には、以下が含まれます。

• 新規リリースまたは後継リリース：新規リリースの他に、既存のリリースの後継リリースを定義できます。先行リリースがないリリースは、通常、サービスまたはアプ

リケーションの最初のリリースです。それ以降のリリースは、通常、以前のリリース

の後継リリースとして定義されます。 さらに、同じリリースから別のブランチを作成できます。 LCM は階層的なフォルダー構造でリリースを整理します。新規リリースと後継リリースは階層の同じレベルにあります。ブランチリリースは、元のリリースの１つ下

のレベルに追加されます。

• リリース名：リリースには任意の名前を付けることができます。通常、名前は、自身の組織の規則に従い、バージョン番号と識別子が含まれます（例：「V3.0 SP2」、「7.0.1.8」）。

• 説明：リリースは、さまざまなレベルで説明を付加できます。リリースの目的を示す概要と、詳細な説明を記述できます。さらに、リリース計画書、設計書、仕様書など

さまざまなファイルを添付ファイルとしてリリースに追加できます。

• 要件と変更指示：リリースに対して実行する必要がある作業の多くは、LCMで管理される要件と変更指示によって定義されます。したがって、各リリースには、そのリ

リースで実現する必要がある要件と変更指示を割り当てます。要件と変更指示の詳細

については、それぞれ「2.3 要件管理」、「2.4 変更管理」を参照してください。

• 成果物：リリースは、リリース全体の構成と機能に必要な成果物で構成されます。リリースを構成する成果物の性質は、さまざまです。例えば、ソフトウェアプロダクト

のリリースには、複数のプロジェクトで開発されたコードやドキュメントが含まれる

- 21 -

ことがあります。成果物は、通常、SCM のようなソースコードやコンフィグレーションを管理するシステムで開発および保守されます。 このようなシステム内の関連する構造へのリンクを作成することで、リリースの内容

を定義します。このようなリンクを必須コンフィグレーションと呼びます。ADM では、LCM 内のコンフィグレーションは、通常、SCM のコンフィグレーションにリンクしています。LCM と SCM では、例えば SCM コンフィグレーションの名前が変更された場合や、SCM リリースが分割された場合などに、SCM へのリンクを常に最新の状態に維持できます。 また、LCM コンフィグレーションとして、URL で指定できる任意の外部システムやサイトへのリンクとして設定できます。

• カスタムプロパティ：LCM のカスタマイズ機能を使用すると、組織の必要に応じて、リリースに追加の説明プロパティを定義できます。

クライアントインターフェースでは、リリースとその定義の概要をいつでも参照できます。

さらに、用意されているさまざまなレポートから、リリース、割り当てられている変更指

示、要件、コンフィグレーション、それらのアイテムのステータス、およびそれらのアイ

テムで実行されているアクティビティに関する包括的な情報を取得できます。

リリースのスケジューリングと計画 リリースのスケジューリングと計画に関するデータは、以下の方法で保守できます。

• 任意のツールで作成したさまざまな形式のリリースのスケジュールや計画を、添付ファイルとして各リリースに追加できます。

• LCM は、フィルターを指定して、要件や変更指示のバックログを確認できます。このフィルターにより、特定のリリースやイテレーション割り当てられていないため、

まだスケジューリングされていないすべての要件や変更指示を簡単に確認できます。

• リリースごとに投入予定日を指定できます。LCM のカスタマイズ機能を使用して、スケジューリングや計画のために追加のリリースプロパティを定義できます。

リリースの実装 リリースは、リリースのコンフィグレーションで必要な変更を実行することで実装されま

す。この変更は、リリースに割り当てられた変更指示によって管理されます。

リリースのビルド、検証、および配備 LCM は、リリースの定義、計画、進捗状況の監視に機能の重点が置かれています。リリースをビルド、検証、配備するためのツールは、適切なプロセスおよび LCM のカスタマイズ機能と拡張機能を使用して、LCM に統合できます。

リリースイテレーションの使用 アジャイル開発などの目的で、1 つのリリースを複数のイテレーションに分割できます。例えば、品質保証部門にアプリケーションの複数のビルドを配布したり、1 人または複数

- 22 -

の顧客にアルファ版またはベータ版を出荷したりするために、イテレーションを定義でき

ます。

それぞれのイテレーションは、リリースにスケジュールされている要件や変更指示全体の

特定の部分を満たします。イテレーションは、他のイテレーションとは関係なく完了およ

び配備できます。

イテレーションは、それに割り当てられている要件や変更指示をリリースと共有します。

つまり、あるイテレーションで満たされた要件や変更指示はすべて、リリースでも満たさ

れたとみなされます。

イテレーションは、リリースと同じプロパティで記述され、独自のプロセスが割り当てら

れます。

リリースへの関連情報のリンク リリースの実装が、他のアプリケーション、サービス、または外部システムのアクティビ

ティや情報の影響を受ける場合があります。例えば、1 つのアプリケーションのリリースが他のアプリケーションの特定のリリースに依存する場合です。

一方、リリース自身が、他のアプリケーション、サービス、または外部システムのデータ

やアクティビティに影響を及ぼす場合もあります。例えば、Web サービスは、別のサービスの特定のリリースの開発に依存している場合があります。

LCM では、他のシステムのさまざまなアイテムやデータに対してリンクを作成することで、このようなリリースの依存関係を表せます。このようなリンクは、以下の項目に関連付け

られます。

• LCM で管理されるアプリケーションやサービス

• SCM のプロジェクト、リリース、およびコンフィグレーション

• DMS で管理されるドキュメントライブラリ

• URL で指定できる外部のシステムやファイル（例えば、ファイルシステム内のフォルダー、Web ページ、WebDAV のドキュメントやコレクション、Bugzilla のインシデント）

LCM、SCM、または DMS のアイテムに関連付けられたリンクから、ADM のクライアントインターフェースの適切なパースペクティブを開き、アイテムの作業をすぐに開始でき

ます。例えば、SCM リンクから「Interstage-SCM」パースペクティブを開けます。リンクで参照される SCM プロジェクトがナビゲーターで選択されるため、直ちにそのリソースを参照して操作できます。外部のシステムやファイルに関連付けられたリンクからは、

Web ブラウザで対応する URL を開けます。

2.6 プロセス制御 LCM で、アプリケーション、サービス、要件、変更指示、リリース、イテレーションに対して実行されるすべての作業は、プロセスによって制御されます。プロセス制御により、

すべてのタスクが、適任者によって計画どおり適切に実施されます。

- 23 -

プロセスとアクティビティ プロセスは、アプリケーション、サービス、リリース、イテレーション、要件、または変

更指示のライフサイクルで実行される必要がある、または実行される可能性があるアク

ティビティ、およびそれらのアクティビティ間で起こり得る遷移を定義します。また、プ

ロセスは、1 つの開始点と、プロセスの終了を定義する 1 つ以上の終了点を持ちます。

以下の図は、変更指示またはリリースに対する簡単なプロセスの例を示します。

このプロセスは、図の四角形の中に記載されている「Plan（計画）」、「Implement（実装）」、および「Test（テスト）」というアクティビティを定義しています。「start（開始）」はプロセスの開始点、「completed（完了）」と「rejected（却下）」は終了点です。矢印は、プロセスの開始からアクティビティや終了までの間に起こり得る遷移を示します。

遷移には、「reject（却下）」、「fix（修正）」などの名前を付けることができます。名前を付けない場合は、遷移先のアクティビティが遷移名として使用されます。

LCM は、任意の複雑度と粒度を持つプロセスをサポートします。上記の例では、プロセスは単純で、アクティビティの粒度は非常に粗くなっています。複雑なプロセスでは、計画、

実装、およびテストの各段階で、1 つではなく複数のアクティビティが定義されます。通常、アプリケーション、サービス、イテレーション、および要件には比較的単純なプロセ

スを使用し、変更指示とリリースには複雑なプロセスを使用します。LCM はそれらすべてに対してあらかじめ定義されたプロセスを提供します。

アプリケーション、サービス、リリース、イテレーション、要件、または変更指示が、そ

れぞれのライフサイクル内を進行する間に、さまざまなユーザーがプロセスによって定義

されたアクティビティを実行します。特定のアクティビティの実行が割り当てられている

ユーザーを、そのアクティビティの責任元ユーザーと呼びます。上記のプロセスの例では、

「Plan（計画）」アクティビティをプロジェクト管理者、「Implement（実装）」アクティビティをソフトウェア開発者、「Test（テスト）」アクティビティを品質保証チームのメンバーに割り当てられます。プロセスアクティビティを定義する際は、指定したユー

ザーロールの少なくとも 1 つを持つユーザーに、有効な責任元ユーザーを制限できます。

プロセスの定義 LCM で使用するプロセスは、以下のいずれかの方法で定義できます。

• Interstage Business Process Manager（BPM）：BPM では、任意の複雑度と粒度を持つプロセスの定義を可能にします。また、定義したプロセスの実行環境も提供し

ます。これは、ユーザーが LCM で実行するアクティビティが BPM によって制御されることを意味します。LCM は、アクティビティに関連付けられたプロセスとデータ

Implement（実装）

Plan （計画）

start （開始）

Test （テスト）

completed（完了）

reject （却下）

reject （却下）

rejected （却下）

fix （修正）

- 24 -

へのリンクをリポジトリで管理します。また、アクティビティを操作するためのユー

ザーインターフェースと、BPM と同期するための機能も提供します。 LCM で使用される BPM のプロセスは、特定の規則に従い、LCM から提供される特定のノードとアクションを使用する必要があります。詳細については、「カスタマイズ

ガイド」を参照してください。

• XML ファイル：XML ファイルでプロセスを定義し、その定義をアプリケーションやサービスを管理しているリポジトリにインポートできます。これは、比較的単純で粒

度の粗いワークフロープロセスに適しています。このようなプロセスのアクティビ

ティは、LCM の制御下で実行されます。

LCM では、上記の両方に対するプロセス定義のサンプルを用意しています。これらをユーザーの環境でそのまま使用することも、必要に応じてカスタマイズすることもできます。

アイテムへのプロセスの割当てとプロセス実行の開始 LCM で作成したアプリケーション、サービス、リリース、イテレーション、要件、および変更指示ごとに、そのアイテムのライフサイクル内で従うプロセスを指定できます。自動

的に作成されるアイテム（例えば、要件をリリースに割り当てたときに作成される変更指

示）には、デフォルトプロセスが割り当てられます。アプリケーションまたはサービスご

とに異なるデフォルトプロセスをリリース、イテレーション、要件、および変更指示に指

定できます。

プロセスによって定義されている最初のアクティビティは、自動的に作成およびアクティ

ブ化され、責任元ユーザーがそのアクティビティの作業を開始できます。プロセスで、プ

ロセスの開始後に並行する複数のアクティビティが定義されている場合は、並行する複数

のアクティビティがすべて作成され、アクティブ化されます。ただし、この例外として、

LCM と同期化されない BPM のプロセスとサブプロセスのアクティビティがあります。

プロセスによって定義されているそれ以降のアクティビティは、開始時には自動的に作成

されません。それらのアクティビティは、アプリケーション、サービス、リリース、イテ

レーション、要件、または変更指示がそれぞれのライフサイクル内で前進し、必要になっ

たときに作成されます。ただし、このような後続のアクティビティは、例えば、計画立案

の目的で、いつでも手動で作成できます。プロセスの実行時に手動で作成したアクティビ

ティに到達すると、そのアクティビティがアクティブ化されます。

作業は、アクティブなアクティビティ、つまりプロセスの実行時に到達してアクティブ化

されたアクティビティに対してだけ実行できます。

- 25 -

アクティビティの計画 デフォルトでは、アクティビティは、計画作業量、推定作業量、開始日、終了日など、詳

細な計画データを指定するためのオプションを提供しません。LCM のカスタマイズ機能を使用することで、必要に応じてプロパティを変更したり、新しいプロパティを定義したり

できます。指定されたデータを評価するためのプロジェクト計画ツールを統合することも

できます。

アクティビティの作業 アクティビティに対する作業とは、アクティビティに含まれるタスクを実行することです。

例えば、上記のサンプルプロセスの「Implement（実装）」アクティビティの作業では、プロセスが割り当てられている変更指示に応じて、ソースコードやドキュメントが変更さ

れます。

作業は、アクティビティがアクティブである限り、アクティビティの責任元のユーザーが

実行できます。

アクティビティとプロセスの完了 アクティビティに含まれるすべてのタスクの実行が完了すると、アクティビティが完了し

ます。アクティビティを完了することで、プロセスによって定義されている後続のアク

ティビティのいずれか、またはプロセスの終了点のいずれかへの遷移が実行されます。

プロセスの終了点に到達すると、プロセスが完了します。それ以降、このプロセスが割り

当てられているアプリケーション、サービス、リリース、イテレーション、要件、または

変更指示を変更できなくなります。プロセス完了後に変更が必要になった場合は、該当す

るプロセスを最初から再開するか、新しいアイテムを作成し、それに割り当てたプロセス

を実行します。

サブアクティビティの使用 サブアクティビティを使用すると、アクティビティに含まれる作業を分割できます。例え

ば、上記の例の「Implement（実装）」アクティビティのように、プロセスで比較的粗いアクティビティが定義されている場合は、サブアクティビティを定義して、いくつかのタ

スクを個々に実行したり、個々の開発者に割り当てたりできます。

サブアクティビティは、未完了であればどのアクティビティに対しても定義できます。親

アクティビティがアクティブである限り、必要に応じてサブアクティビティを個々に完了

したり再アクティブ化したりできます。親アクティビティをアクティブ化または完了する

と、すべてのサブアクティビティもアクティブ化または完了されます。

- 26 -

アクティビティの情報 LCM は、アクティビティに関する情報を取得するためのさまざまな方法を用意しています。

• 個人用アクティビティリスト：クライアントインターフェースで、自分が責任元ユーザーとして割り当てられているすべてのアクティビティを一覧表示できます。必要に

応じて、リストをフィルタリングしたり、詳細表示をカスタマイズしたりできます。

• アプリケーション、サービス、リリース、イテレーション、要件、および変更指示のアクティビティリスト：クライアントインターフェースには、アプリケーション、

サービス、リリース、イテレーション、要件、および変更指示ごとのアクティビティ

が一覧表示されます。

• レポート：アクティビティとサブアクティビティに関する情報を含むさまざまなレベルのレポートを利用できます。

• 通知：アクティビティが完了し、後続のアクティビティまたはプロセス終了への遷移が実行されたときに電子メールでユーザーに通知できます。BPM で定義されたプロセスでは、アクティビティの予定開始日や終了日になった場合などの通知も可能です｡

2.7 セキュリティとアクセス制御 LCMは、ロールとオーソリティに基づくセキュリティおよびアクセス制御機能によって制御されます。これらの機能は、ADMのすべてのコンポーネントで共通です。これらの機能についての詳細は、「6.4 セキュリティとアクセス制御」で説明しています。以下では、LCM独自の追加機能について説明します。

ロールとオーソリティ ルートノードでは、リポジトリ内のすべてのサービスとアプリケーションに対するロール

およびロール内のオーソリティの割当てを定義できます。これは、リポジトリのすべての

サービスやアプリケーションで有効なユーザーに管理者ロールを割り当てることを意味し

ます。つまり、サービスやアプリケーションを作成できるユーザーを定義できます。

各アプリケーションまたはサービスでは、そのアプリケーションまたはサービスだけで有

効な特定のロールを割り当てられます。あらかじめ定義されたロールにより、アプリケー

ションまたはサービス自体へのアクセスを制御したり、アプリケーションまたはサービス

に含まれる要件、変更指示、およびリリースへのアクセスを制御したりできます。

アプリケーション、サービス、リリース、要件、および変更指示に対するアクションと、

これらのアイテムの特定のプロパティや添付ファイルに対するアクションには、オーソリ

ティがあらかじめ定義されています。プロセスのアクティビティは、対応するアプリケー

ション、サービス、リリース、リリースのイテレーション、要件、または変更指示に定義

されているオーソリティによって制御されます。

LCM では、ロールやオーソリティとその有効範囲をカスタマイズできます。例えば、アイテムの特定のプロパティを変更するために必要なオーソリティを指定したり変更したりで

きます。

- 27 -

責任元ユーザー 各アプリケーション、サービス、リリース、イテレーション、要件、および変更指示には、

同時に 1 人以上の責任元ユーザーが存在します。責任元ユーザーと、ロールとして適切な書き込み権限オーソリティを持つユーザーだけが、アイテムに変更を加えられます。

アプリケーション、サービス、リリース、イテレーション、要件、または変更指示の責任

元ユーザーは、アイテムに対応するアクティブな全プロセスアクティビティの責任元ユー

ザーと同じです。アクティビティとそのアクティビティに対応するアイテムの両方で、責

任元ユーザーを変更できます。

保護の更新と削除 アプリケーション、サービス、リリース、イテレーション、要件、変更指示、およびそれ

らのアイテムのプロパティ、添付ファイル、他のアイテムとの関連は、ユーザーのロール

やオーソリティとは関係なく、変更や削除されないように保護できます。このような保護

は、ユーザーによってではなく、アイテムを制御するプロセスによって設定されます。例

えば、プロセスが完了すると、関連するアプリケーション、サービス、リリース、イテ

レーション、要件、または変更指示は、それ以上変更されないように保護されます。

2.8 カスタマイズと拡張 LCM は、必要に応じて LCM を設定およびカスタマイズするためのさまざまなオプションを備えています。

以下の機能は、サービスやアプリケーションを管理するためのリポジトリごとにカスタマ

イズできます。

• ユーザーロールとオーソリティ：あらかじめ定義されているユーザーロールやオーソリティを変更したり、新しいロールやオーソリティを追加したりできます。

• プロセス：LCM に用意されているプロセスを変更したり、追加のプロセスを定義したりできます。

• 関連：アイテム間で可能な関連を変更したり、関連がユーザーインターフェースで表示および処理される方法を変更したりできます。

• ユーザー定義属性：アイテムの特定のプロパティを変更したり、追加のプロパティを定義したりできます。変更または定義できるプロパティをユーザー定義属性と呼びま

す。ユーザー定義属性ごとに、ユーザーインターフェースに表示するかどうか、フィ

ルターとして使用できるかどうか、対応するアイテムの作成時に編集可能にするかど

うかなどを指定できます。

LCM のカスタマイズおよび拡張の詳細については、「カスタマイズガイド」を参照してください。

- 28 -

3 ソフトウェア構成管理（SCM） ソフトウェア構成管理（SCM）は、サービスやアプリケーションに関連するソースコードなどのリソースの管理をサポートします。SCM によって、単純なアプリケーションから複雑な分散型システムまで、さまざまなソフトウェア開発プロジェクトを管理できます。

また、複数ユーザーによるアクセスや並行開発をサポートするためのチェックイン、

チェックアウト機能、同期機能、および高度なセキュリティ機構を提供します。プロジェ

クトのリソースは、コンフィグレーションで管理されます。コンフィグレーションは、リ

リースまたはプロダクトごとにグループ化して管理できます。リソース、コンフィグレー

ション、リリースは、LCM によって管理、統合できます。SCM は、Interstage Studio やEclipse での利用に最適化されていますが、他の開発環境へも容易に統合できます。

SCMが管理するソフトウェア開発プロジェクトは、1 つまたは複数のリポジトリに格納されます。ユーザーは、クライアントインターフェース、コマンドラインインターフェース、

およびWebインターフェースを使用して、リポジトリのデータにアクセスできます。ADMのプロダクト、コンポーネント、インターフェースおよび運用の形態の詳細については、

1章を参照してください。

以下では、SCM の機能とサービスの概要を説明して、基本的な概念を紹介します。

3.1 SCMのプロジェクト SCM は、ソフトウェアプロダクトやコンポーネントを構成するリソース（フォルダーやファイル）をプロジェクトで管理します。プロジェクトは、小さなアプリケーションから、

さまざまなコンポーネントとサブコンポーネントから構成される大きなソフトウェアシス

テムまで、どのような規模のソフトウェア開発プロジェクトにも適用できます。

各 SCM プロジェクトは、1 つまたは複数のコンフィグレーションから構成されます。コンフィグレーションは、プロダクトやコンポーネントの特定のビルドのような、プロジェ

クトリソースの特定の状態を表します。コンフィグレーションは、リソースの作成、変更、

削除ができる作業コンフィグレーションと、変更できない保護されたコンフィグレーショ

ン（スナップショット）に分類されます。

プロジェクトのコンフィグレーションは、ソフトウェアプロダクトやコンポーネントの特

定のバージョンやエディションなどを表すために、別々のリリースとしてグループ化でき

ます。

SCMでプロジェクトを作成すると、そのプロジェクトの最初のリリース（デフォルト名：1.0）が作成されます。新しいリリースには、作業コンフィグレーション（デフォルト名：MAIN）と、ベースコンフィグレーション（デフォルト名：BASE）と呼ばれる最初のスナップショットが含まれます。この初期状態から、必要に応じて新しいコンフィグレー

ションやリリースを作成していきます。リリースやコンフィグレーション管理の詳細につ

いては、「3.4 コンフィグレーションの管理」を参照してください。

- 29 -

以下の図に、SCM が管理している「Interstage QA」プロジェクトを示します。このプロジェクトには「1.0」と「2.0」の 2 つのリリースがあります。リリース「2.0」は、作業コンフィグレーション「MAIN」、3 つのスナップショット「Build 1 –2007-08-01」、「Build 2 –2007-08-15」、およびベースコンフィグレーション「BASE」から構成されています。「MAIN」の下のフォルダー「SCM」が開かれていて、このコンフィグレーションが管理しているリソースを示しています。

SCM プロジェクトとプロジェクトに含まれるリソースは、リポジトリに格納されます。リポジトリには、複数のプロジェクトを保存できます。SCM のユーザーは、同じリポジトリに保存されているプロジェクトにも、同じサーバまたは異なるサーバにある異なるリ

ポジトリに保存されているプロジェクトにもアクセスできます。これにより、拡張性のあ

る高性能なソフトウェア構成管理環境が実現され、多数の開発チームの管理が可能となり

ます。

プロジェクト

作業 コンフィグレーション

リリース

スナップショット

リリース

スナップショット ベースコンフィグレーション

- 30 -

3.2 プロジェクト定義 SCM プロジェクトは、以下の方法で作成します。

• Interstage Studio または Eclipse プロジェクトやフォルダーの共有：Interstage Studio または Eclipse のローカル開発環境のプロジェクトは、クライアントインターフェースの「プロジェクトの共有」チームサポート機能を使用して、SCM プロジェクトとして共有できます。同様に、コマンドラインインターフェースによって、ファ

イルシステムのどのフォルダーも SCM プロジェクトとして共有できます。共有するとは、最初のリリース、作業コンフィグレーション、およびベースコンフィグレー

ションを含む SCM プロジェクトを、既存または新規のリポジトリに作成するということです。共有したプロジェクトに対して、「コミット」チームサポート機能によっ

て、Interstage Studio や Eclipse のローカル開発環境のプロジェクトやフォルダーのコンテンツの全部または一部を SCM プロジェクトに追加できます。

3.3 リソースとバージョンの管理 SCM は、リソース管理やバージョン管理など、ソフトウェア構成管理システムに要求されるすべての基本機能をサポートしています。バージョン管理をすることで、変更が記録

され、必要に応じてプロジェクトを以前の状態に戻すことが可能となります。

リソースとリソースバージョン SCM のリソースとは、プロジェクトを構成するすべてのファイルとフォルダーのことです。すべてのリソースがバージョン管理可能です。SCM プロジェクトに新しいリソースをコミットすると、最初のバージョンがリポジトリに作成されて、バージョン管理が有効

になります。ユーザーがローカル開発環境のプロジェクトのリソースに対して行った変更

をコミットするごとに、新しいバージョンのリソースが作成されます。新しいバージョン

のフォルダーは、必要に応じて SCM が自動的に作成します。

SCM プロジェクトのリソースは、コンフィグレーションで管理されます。1 つのコンフィグレーションには、リソースの 1 つのバージョンだけが含まれます。一方、リソースの 1つのバージョンは、複数のコンフィグレーションに含めることができます。

リソース作成 ローカル開発環境で、SCM から独立してリソースを作成します。リソースは、SCM プロジェクトの作業コンフィグレーションにコミットすることで共有されます。例えば、

Interstage Studio や Eclipse では、自分のローカルワークスペースにフォルダーやファイルを作成できます。対応する SCM プロジェクトに、これらのリソースがコミットされるまでは、すべての SCM アクションはこれらのリソースを無視します。これには、一時的なリソース構造やプライベートなリソース構造が、SCM の操作に影響を与えたり受けたりしないで、ローカルワークスペースの SCM で管理しているリソースと共存できるという利点があります。

- 31 -

SCM は、既存 SCM プロジェクトへの新しいリソースの追加をサポートする、同期化機能とマージ機能を提供します。また、同期化やマージの操作で無視するローカルリソースの

ファイル名パターンも定義できます。

チェックアウトとコミット チェックアウトとコミットにより、SCM プロジェクトのリソースをローカル開発環境に取り出したり、ローカル開発環境のリソースを SCM プロジェクトに追加したりすることができます。

SCM プロジェクトのリソースを変更するための基本的な流れを、以下に示します。

1. SCM プロジェクトの作業コンフィグレーションから、ローカル開発環境にリソースをチェックアウトします。チェックアウトすると、ローカル開発環境に新しいプロ

ジェクトが作成されるか、または既存のプロジェクトが更新され、SCM プロジェクト内のリソースの最新のバージョンがローカルのプロジェクトにコピーされます。

チェックアウトは、SCM プロジェクト全体、プロジェクトの下部構造、または単独のリソースを指定できます。

2. ローカル開発環境でリソースを変更します。この作業は、SCM プロジェクトやリポジトリへの接続状態とは関係なく実施できます。また、変更を実施する編集ツールも

選びません。

3. 変更したリソースを SCM プロジェクトの作業コンフィグレーションにコミットします。ファイルごとに、変更を含む新しいバージョンが作成されます。作業コンフィグ

レーションの旧バージョンは、新しいバージョンに置き換わります。

コミットの実行前に、SCM はローカル開発環境のリソースと、リポジトリに保存している最新バージョンおよび旧バージョンのリソースを比較します。このため、ローカルで変

更したリソースだけがリポジトリにコピーされ、他のユーザーが変更してすでにリポジト

リに保存しているリソースに対しての変更は上書きされません。この場合、他のユーザー

の変更を反映するためにローカルのリソースをリポジトリのリソースとマージするか、他

のユーザーの変更を無視して、ローカル開発環境のリソースでリポジトリのリソースを上

書きしてコミットできます。

同期化と更新 SCM は、複数のユーザーによるプロジェクトでの同時作業をサポートします。SCM は、ローカル開発環境のリソースをリポジトリに保存したリソースと同期化させるのに役立つ

機能やオプションを提供します。

ローカル開発環境にチェックアウトしたリソースと、リポジトリ内にあるリソースの最新

バージョンをいつでも比較できます。クライアントインターフェースは、リソースのどの

バージョンがより最新かという情報など、相違点を表示するグラフィカルビューを提供し

ます。Interstage Studio や Eclipse の比較エディタや、SCM 用に構成できる外部エディタを使用して、ファイルの内容の比較もできます。

ローカル環境のリソースとリポジトリ内のリソースに相違がある場合には、以下の操作を

実行できます。

- 32 -

• ローカル開発環境のリソースをリポジトリにコミットできます。他のユーザーによるリソースの変更を、ローカルのリソースで上書きしてコミットできます。

• ローカル開発環境のリソースを、リポジトリに保存されているリソースで更新できます。ローカル開発環境で変更したリソースを、リポジトリのリソースで上書きして更

新できます。

• ローカル開発環境のリソースの変更を、リポジトリのリソースの変更とマージして、その結果をリポジトリにコミットできます。マージは、比較エディタなどを使用して

手動で行うか、SCM が提供する自動マージ機能を使用して行えます。自動マージ機能は、変更がファイルの違う行同士で行われた場合など、競合しない変更を含むファ

イルをマージするときに有効です。

バージョンヒストリ SCM は、各ファイルリソースのすべてのバージョンについて正確なヒストリを保持します。ヒストリには、各リソースバージョンや各バージョンについて以下の付帯情報があり

ます。

• 先行バージョン、後継バージョン、および並行バージョン

• バージョンの作成日時

• バージョンの作成ユーザー

• バージョンがマージ操作の結果かどうかに関する情報

• バージョンを作成したコミット操作に対してユーザーが記入したコメント

• LCM で管理している、バージョンを作成した変更指示

ファイルリソースのバージョンヒストリを、クライアントインターフェースと Web インターフェースで表示できます。必要に応じてツリービューとフィルターを使用できます。

バージョンヒストリでは、以下の操作を実行できます。

• 各バージョンの内容を確認できます。

• あるバージョンのリソースをエクスポートできます。

• 内部または外部の比較エディタを使用して、バージョン同士を比較できます。

• 古いバージョンのリソースを復元して、古いバージョンを最新のバージョンにできます。

リソースの削除 リソースは、SCM プロジェクトの作業コンフィグレーションから削除できます。削除しても、リソースバージョンは物理的には削除されず、リポジトリ内に保存したままになり

ます。これは、リソースバージョンが他のコンフィグレーションの一部である可能性があ

るためです。必要に応じて、削除したリソースのバージョンをバージョンヒストリから取

り出して、元の状態に戻せます。

- 33 -

リソースロック SCM プロジェクトのリソースは、排他制御のためにロックできます。リソースをロックしたユーザーだけが、そのリソースに変更をコミットできます。リソースのロックは、頻

繁なマージ作業を避け、リソースバージョンの数を減らすのに役立ちます。複数の開発者

が同じリソースで作業する分散型開発環境では、特に有効です。

ローカルリソースの監視 リソースのチェックアウトで作成したどのローカルプロジェクトに対しても、監視を設定

できます。監視によって、まだコミットしていないローカル開発環境の変更を把握できま

す。例えば、リソースを変更またはロックする前に、他のユーザーがそのリソースで作業

したかどうかを簡単に発見できます。このため、競合や頻繁なマージ作業を避けられます。

各 SCM プロジェクトに対して、ローカルリソースの監視を強制できます。強制しない場合は、チェックアウトごとに有効にしたり、後でローカルプロジェクトにおいてアクティ

ブ化したり非アクティブ化したりできます。

読み取り専用アクセスとエクスポート SCM プロジェクト内のリソースを変更しないように、読み取り専用アク