IBM Rational Software Delivery Platform V7 チーム製品 を用いた統合的な変更・構成管理の実装 日本アイ・ビー・エム株式会社
by user
Comments
Transcript
IBM Rational Software Delivery Platform V7 チーム製品 を用いた統合的な変更・構成管理の実装 日本アイ・ビー・エム株式会社
IBM Rational Software Delivery Platform V7 チーム製品 を用いた統合的な変更・構成管理の実装 日本アイ・ビー・エム株式会社 SWG Rational TS&S 2007-04-04 -1- 目次 1 管理対象範囲の考察..................................................................................................................................... 3 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 2 ソフトウェア成果物 ................................................................................................................................. 3 開発工程................................................................................................................................................. 4 変更依頼................................................................................................................................................. 4 組織......................................................................................................................................................... 5 ソフトウェア製品のサービス提供期間................................................................................................... 5 派生製品................................................................................................................................................. 6 対応プラットフォーム .............................................................................................................................. 6 範囲のまとめ .......................................................................................................................................... 7 IBM RATIONAL SOFTWARE DELIVERY PLATFORM（SDP）による実装 ................................. 8 -2- 本稿では Rational Software Delivery Platform V7 デスクトップ製品を用いた統合的な変更・構成管理に ついて説明していきます。 ツールを用いた統合的な変更・構成管理は非常に強力なソリューションですが、その実装のためには正確 な構成管理計画が必須となります。 今回は、構成管理計画を立てるための第一歩として管理の対象となる範囲について詳細に見ていきます。 本稿で対象としているのは、ソフトウェア開発に関する変更管理と構成管理です。 変更とは、ソフトウェア成果物に対して修正を行う要因を意味します。具体的には、障害や要求や仕様変更、機 能追加をさし、これらをまとめて変更依頼と呼びます。 構成とは、ソフトウェア成果物の構成を意味します。 1 管理対象範囲の考察 構成管理計画を立案するに当たって、一番大切なことは、「範囲」について検討することです。そして、その検討結果 を構成管理計画書として記述することです。では、「範囲」とは、何をさしているのか？ ここで挙げている項目は、 ひょっとすると全てが網羅されているものではないかもしれません。読み進めていただく中でお気づきになれば、その 項目も追加してご検討ください。 ここでは、以下の項目について検討します。 1.1 ・ ソフトウェア成果物 ・ 開発工程 ・ 変更依頼 ・ 組織 ・ ソフトウェア製品のサービス提供期間 ・ 派生製品 ・ 対応プラットフォーム ソフトウェア成果物 すぐ簡単にあげられるのは、ソフトウェア成果物だと思われます。しかも、ソースコードと思われる方々が大半だと思 いますが、いかがでしょうか？ なぜ、ここでこの話をするかと言うと・・・・実は、これを読まれる方のお立場によ って、お考えになる「範囲」がまちまちだと言うことです。設計書を管理対象にするとお考えになられる方や、テスト データとテスト仕様書も必要だと思われる方がいらっしゃると思います。いえいえ、テスト結果も必要でしょう！ ま た、出荷担当者の方だとどうでしょうか？・・・・ コンパイラや開発ツールも「範囲」に含める必要があるとお考え の方も中にはおいでになりませんか？ 役割によって、構成管理の対象としたいソフトウェア成果物が異なっていると 言うことです。 1.1.1 ソフトウェア成果物の範囲 ソフトウェア製品は、その開発過程において、さまざまなソフトウェア成果物を生み出します。その全ての構成をき ちんと管理し必要なときに必要なものを参照可能な環境にしておくことが必要です。 ソフトウェア成果物の管理対象の範囲は、理想で言うならばソフトウェア成果物、全てが対象ということになります。 （ここでは、一例を記述します） ・ ソースコード ・ 設計書（要求仕様書、機能仕様書） ・ モデル ・ テストデータ、テスト結果 -3- ・ サードパーティ提供のソフト ・ 実行モジュールやオブジェクト ・ マニュアル（取扱説明書） 立場によって範囲が違ってくることをご理解ください。また、管理対象になるソフトウェア成果物によって変更や更 新の手続きが異なります。 1.1.2 構成管理計画立案上のポイント 一般的には、実行モジュールやオブジェクトおよびソースコードを対象として始められることがほとんどのケースに なります。ここで注意しておかないといけないのは、ソフトウェア製品は、その開発過程において、さまざまなソフト ウェア成果物を生み出しており、ファイルとして格納される形式が異なることです。ファイル形式が違う場合、変更や 編集の手順が異なりますから、お間違えのないように注意が必要です。また、ベースラインを目的にあわせて明確に規 定することが大切です。目的別のベースラインを誰がどのようなタイミングで作成するのか！ これをしっかりと決め ておくことです。 1.2 開発工程 開発工程のどのタイミングから変更や構成の管理を始めましょうか？ まさか、納品するまで全く実施する必要が無 いとお考えでは無いと思いますが・・・・ 新規開発の場合に良く聞くのは、単体テストが完了して結合テストを開始 するタイミングで始めようとされる方が非常に多いようです。これは、前述のソフトウェア成果物の管理「範囲」とし てソースコードを対象としてお考えになられていることによる結果のようです。それまでは、管理対象となるソースコ ードが無いのだから管理を考える必要は無いだろうと言うことのようです。 1.2.1 開発工程の範囲 では、ソフトウェア成果物、全てが管理対象「範囲」と考えると、管理を始めるのは結合テスト開始のタイミングで はなくなることは、ご理解いただけると思います。結合テスト工程前のさまざまなソフトウェア成果物が既に作成され ているからです。設計書として、さまざまなファイルが作成されています。これらの構成を維持しながら管理すること が必要です。たとえば、要求仕様書に記述されている内容から、機能仕様書が記述されていくのは一般的な開発工程に 基づいて実施される作業の結果だと思います。ここで大切なのは、要求仕様書、機能仕様書、ソースコードの関連を維 持しながら管理することです。要求のトレーサビリティを管理できる環境にあることです。ですから、開発工程の全て を「範囲」とすることが必要なのです。ソフトウェア製品を作成する要因を明確に示しているのが要求仕様書です。こ の仕様書から全てが始まるわけですから、それらのソフトウェア成果物と関連付けて管理するためにも開発工程の全て を対象にしませんか！ 1.2.2 構成管理計画立案上のポイント ソフトウェア成果物をベースラインによって構成管理することからはじめてはいかがでしょうか？ そうすることで ファイルのバージョンの関連を捉えることが可能となります。次のステップとしては、Excel などを利用してトレーサ ビリティ・マトリクスを作成してはいかがでしょうか？ ファイルの関連が整理でき、各仕様書間やソースコードとの 関連性を記録することができます。更に後述する変更管理ツール「ClearQuest」のレコードタイプにトレーサビリテ ィ・マトリクスを作成して管理することも可能です。 1.3 変更依頼 ソフトウェア開発の中では、障害管理や変更管理、要求管理などの管理と名のつくいくつかのものがありますが、 「範囲」と考えたときに、どこからはじめようとお考えですか？ どこから、変更と考えるかが問題になりますか？ 問題として管理して内容の分析後に障害や仕様変更として対応策を決定し対応しますか？ どこからはじめるのでしょ うか？ 1.3.1 変更依頼の範囲 本稿では、新規開発にしてもメンテナンスにしても、ソフトウェア製品に対して、編集、変更や修正などの行為をま とめて変更依頼と定義します。したがって、要望を明確に要求に顕在化させ、要求仕様書として纏め上げるところから、 ソフトウェア開発が始まっても、既存のシステムで障害が発生して修正する場合や既存のシステムに機能追加のために 修正を行っても変更依頼です。全ての変更依頼が「範囲」になります。たとえば、レビュー記録は、どうでしょうか？ -4- レビューを実施した記録をとります。レビューを実施するとその結果、問題点として指摘され修正を行わないとならな い場合があります。この場合でも、これは、ソフトウェア成果物に変更を行う作業ですから「範囲」に含まれます。 1.3.2 構成管理計画立案上のポイント ソフトウェア成果物の構成を管理されていないことがあっても、変更を管理されていないと言うことは無いはずです。 現在、管理されている変更依頼の範囲を、ソフトウェア成果物の管理対象を広げるのにあわせて徐々に広げて行くこと がごく自然な実装ステップです。 1.4 組織 次に管理する組織の「範囲」を検討しましょう！ あるプロジェクトの中だけをお考えですか？ そのプロジェクト メンバーは、どのような構成でしょうか？ 少人数のプロジェクトで、設計・製造・テストを一人の担当者がアサイン されて実施しているとか、あるいは、開発部門と品質評価部門が分かれていますか？ 協力会社が何社か参加されてい ますか？ 全社共通でお考えになっていますか？ あなたの立場は、どのようなお立場ですか？ 現在、プロジェクト 管理者で上司から、今回のとりまとめを依頼された・・・・・ システム管理部門で、社内の標準化を検討中で、自社 の開発現場の状況は良くわからないが、ヒアリングや状況調査をしながら進めようと考えている。 実は、ここでも立場により求める結果が違ってくるので「範囲」が違ってきます。「範囲」が違うと、必要とされる ものも違ってきます。 1.4.1 組織の範囲 ソフトウェア製品を作り出していくために構成される組織は、さまざまな組織で構成されているのが現実です。最近 では、大規模開発やオフショア開発などのように組織が物理的に別々の場所に分散しているような環境が良く見受けら れます。物理的に分散された組織の中で実施されているソフトウェア開発は、お互いの組織の状況が非常に見えにくい 状況にあります。したがって、役割を明確にした組織を定義して、その組織が果たす責任を定義します。一般的には、 プロジェクト規模が小さければ、コミュニケーションが良いプロジェクトが構成されますから、細かく規定することは ありませんし、逆に人数が少ないので細かく規定しても管理工数が増加して実施できないわけです。ところが、大規模 開発やオフショア開発になると物理的に離れた場所で実施されている作業をきちんと把握することが要求されます。こ のように、組織の範囲の違いによって大きく変わってきますから、「範囲」を明確にし、その「範囲」に適した役割と 責任を規定する必要がありますし、組織の範囲が変更されれば、再検討を行わないといけない（同じものは通用しな い）訳です。 1.4.2 構成管理計画立案上のポイント 特に、組織については、目的が異なるがために切り分けられているはずです。また、その組織を構成するメンバーに よっても代わってきます。ですから、その組織に関わる人達に対して変更・構成管理の目的を説明し、その目的を達成 するための役割と責任を理解してもらいます。そしてコミットメントをきちんと得ることが必要です。 1.5 ソフトウェア製品のサービス提供期間 対象ソフトウェア製品の提供サービスの開始から終了までの期間は、どうなっているのでしょうか？ ソフトウェア 開発を担当される方にとっては、あまり、関心の無いことなのでしょうか？ 新規開発が完了して運用が始まります。 運用中には、あまり起こってほしくは無いことですが、障害が発生します。また、機能改善要求が挙がってきます。こ れらに問題なく対応するためにどのようにすればよいでしょうか？ 一般的には、開発期間より運用期間のほうが長い のではないでしょうか？ 開発段階の体制をそのまま維持することはありませんから、きちんとしたソフトウェア成果 物の管理を行っておく必要があります。構成管理が必要です。数ヶ月前に修正されたことはわかるのですが、なぜ、そ こが修正されたのか判断することはできますか？ いえいえ、変更が頻繁に入るから、そんな数ヶ月前のことがわかっ ても所詮意味が無いこと・・・ などとお考えでしょうか？ 変更依頼の管理が必要です。 1.5.1 サービス提供期間 ソフトウェア製品のサービスが終了するまでですから、「範囲」は全てと言うことに異論は無いはずです。しかし、 その期間が長ければ長いほど、いろいろな対策が必要です。構成と変更を管理して、ベースラインでコントロールする ことをお奨めします。 1.5.2 構成管理計画上のポイント サービス提供期間全体に渡って変更と構成をきちんと管理し、実装すべきです。 -5- 1.6 派生製品 各ソフトウェア製品の派生製品とは、どのようなものですか？ どのように定義すればよいのでしょうか？ あるベ ースになるソフトウェア製品が既に存在しています。このソフトウェア製品に対して、標準的な機能追加であればバー ジョンアップと言うことになるのですが、独自の機能追加を行うような場合に派生製品が出来上がると考えます。どこ までを「範囲」と考えますか？ 別製品として管理しますか？同じようなファイル名が複数存在し、条件によってビル ド環境が異なり、管理が煩雑になるため、極力、統合して管理したいとお考えになられる結果として、ソースコードの ロジックの中に判定分などを追加して組み込まれる方法を取られている場合もあるようです。しかし、それにも限界が ありますし、機能追加を検討する際に条件が多すぎて、簡単に作業を完了させることができなくなります。 1.6.1 派生製品の範囲 これも、「範囲」は、全てということで異論は無いはずです。しかし、その派生の量が多ければ多いほど、いろいろと 対策が必要となります。構成と変更を管理して、ベースラインでコントロールすることをお奨めします。 1.6.2 構成管理計画立案上のポイント 変更と構成の管理をきちんと実施するべきですが、それだけでは不十分であることはご理解いただけると思いま す。詳細は別稿に譲り、ここで詳細に触れることはしません。 1.7 対応プラットフォーム 各ソフトウェア製品の対応しているプラットフォームは、オープン系？ Windows 環境、Linux、UNIX・・・どの環境 で動作するのでしょうか？ フロントエンドとバックエンドでは、異なっていたりしますよね？ でも、システムと言 うくくりで見ると同じシステムであるが、プラットフォームが異なっているような場合は、どのように「範囲」を考え ますか？ 1.7.1 対応プラットフォームの範囲 これも、全てを「範囲」とすることに異論は無いはずですが、なかなか 1 つのルールや手順でまとめることは難しい ようです。しかし、運用手順などの整理はきちんと行っておく必要があります。 1.7.2 構成管理計画立案上のポイント 個別のプラットフォーム対応した手順を纏める。できれば、同じ手順で纏めることを考えましょう。 -6- 1.8 範囲のまとめ 構成管理計画を立案するための第一歩として「範囲」について考察してきました。ここに挙げた項目で全てで しょうか？ お気づきになられたらこれを機会に、ご検討ください。「範囲」によって、検討しないといけない 項目が変わってくることは十分にご理解いただいていることと思います。また、段階的な実装を考慮した場合に も、「範囲」が変わりますから、同じものが流用されることは無いこともご理解いただけると思います。統合的 な変更と構成管理の実装は、小さく初めて大きく広げることが必要です。ですから、時間がかかるのです。 1.8.1 現状調査 まずは、何はともあれ、現状調査です。どんな組織がありますか？ その組織やそれぞれの役割を持っ た方からのヒアリングが必要です。どんな役割の方がいますか？ その方々から、統合的な変更と構成を実 施するうえでの現在の問題点と良い点をヒアリングしましょう！ プロジェクト管理者 開発責任者 開発担当者 アーキテクト ビジネスモデル分析者 実装担当者 ジニア システム管理者 システム分析者 システム統合担当者 テスト設計者 構成管理者 etc. プロセスエン そして、洗い出された問題や良い点の特徴を整理して、「範囲」を決定しましょう。「理想で言うならば全てが対象 ということになります。」 でも全ての「範囲」を対象にするためには段階的なステップが必要となるでしょう。 上述の「範囲」と言う観点で 7 つの項目を検討してきました。それらの項目を各役割の違う人の要求で整理していく と必要とされる「範囲」が明らかになるはずです。（関連する方々を改めてリストアップしてください。） ソフトウェア 成果物 開発工程 変更依頼 組織 提供期間 派生製品 対応プラット フォーム CEO/CIO システム管 理者 PM 開発担当者 1.8.2 「範囲」の決定 繰り返しが基本です。上述の「範囲」でリストした項目のそれぞれについての「範囲」を決定しましょう。それぞれ の「範囲」を繰り返し少しずつ広げていくことが必要です。 ある組織のある開発の工程が進むにつれてさまざまなファイル形式をしたソフトウェア成果物を結果として作り上げ ることになります。作り上げられたソフトウェア成果物は、その段階で別のファイル形式として切り分けられて作成さ れます。また、そのソフトウェア成果物を作成する開発組織にも壁が存在します。 開発組織の分散化に対応しながら、その物理的な壁をシームレスに構成する環境が必要となります。 -7- 2 IBM Rational Software Delivery Platform（SDP）による実装 構成管理計画を立案するためにはまだまだたくさん決定しなければいけないことがありますが、それは別 稿でお伝えすることにします。 構成管理計画を実装する際には IBM Rational Software Delivery Platform V7 チーム製品を用いた統合的 な変更と構成の管理ソリューションが有効です。 監査とアセットのトラッキング 開発 ビルド デプロイ 実装と 繰り返し開発 ビルドと ステージング プロビジョニング /サーバーの検証 運用環境 IBM Rational ClearQuest 開発 アセット ビルド アセット デプロイ アセット IBM Tivoli Provisioning Manager IBM Rational Build Forge IBM Rational ClearCase 開発と運用をつなぐ 変更管理はClearQuest、構成管理はClearCaseを利用して実装します。ClearQuestに蓄えられる変更依頼と、ClearCase に蓄えられる成果物を関連付けることで、いつ、誰が、どのような理由で、どのように変更して、どのバージョンの成 果物が作成されたかを把握することができます。最近ではコンプライアンス遵守やJ-SOX法を視野に入れなければなりま せん。予め計画された手順で間違いなく作業を実施しているということを明確にする必要がありますのでこうした機能 は非常に重要になっていきます。 SDP V7 では、更にビルドの自動化を行うBuild Forge、出来上がったソフトウェア製品のデプロイやシステム運用監視 を行うTivoli®製品群と連携することができます。 ソフトウェア開発からビルド、デプロイを自動化し、運用監視によりソフトウェア製品の改善点を明らかにする統合ソ リューションを、SDP V7 チーム製品によって実現可能です。 -8- Copyright© International Business Machines Corporation, 2007. All rights reserved. 本記事は、全部または一部を IBM 社の事前の書面による許可なしに複製することはできません。本書の内容は、予告なく変更されるこ とがあります。 本書の内容および関連する Rational ソフトウェアは IBM かそのライセンス管理者、またはその両者の所有物であり、米国著作権法、特 許法、その他の国際条約により保護されています。一部または全部を複製することは禁じられています。本書またはソフトウェアの追加 の複製に関しては、IBM にお問い合わせください。 IBM、IBM のロゴ、Rational、Rational のロゴ、Tivoli、Tivoli のロゴ、Rational ClearCase、Rational ClearQuest、Rational Buildforge は、 IBM Corporation の米国およびその他の国における商標または登録商標です。 Java およびすべての Java 関連の商標およびロゴは Sun Microsystems, Inc.の米国およびその他の国における商標です。 他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。 -9-