業務システムライフサイクル管理の実際

以下では、業務システムのライフサイクル管理をどのように実施していくかの例を示します。採用したツールに依存する部分がありますが、ここでは、Visual Studio 2010とTeam Foundation Server 2010を選択したケースとして記述します 。

事前準備

業務システムのライフサイクルを開始する際の事前準備について簡単に記述します。Team Foundation Server 2010では、開発者、プロジェクトマネージャー(PM)、テスターなどの各責務を割り当てられた人が共通の「チームプロジェクト」というリポジトリーにアクセスし作業をします(図 5)

開発者のコードをテスターが検証し、開発者のタスクやテスターの実施状況などをPMが管理するといった協調作業を実現するためのプラットフォームです。業務システムのライフサイクル管理を機能させるには、企業の特質や業務内容に応じてTeam Foundation Serverをどのように運用するかということを事前に決めておくことが重要です。

【図５】Team Foundation Serverによるプロジェクト管理

このホワイトペーパーはVisual Studio 2010 UltimateとTeam Foundation Server 2010のbeta2日本語版、およびRC英語版の機能に基づいて記述しています。

プロセス定義

Team Foundation Serverでは、MSF(Microsoft Solutions Framework )に基づくプロセスガイダンスを提供しており、MSF for AgileとMSF for CMMIをサポートしています。これらのプロセスをカスタマイズして自社標準に合わせることも可能です。最初は比較的軽いAgileを利用して、独自の管理項目を追加するのがよいかもしれません。MSF for Agileでは「ユーザーストーリー」で顧客の要件を管理しますが、「要件」や「ユースケース」などの項目を追加して管理することもできます。

構成管理

成果物の構成管理をどのように行うかも事前に決めておくことが重要です。

Visual Studio 2010のモデリング機能を採用する場合は、モデルはVisual Studioのソリューション配下にModeling Projectとして配置されます。
それ以外のUMLモデリングツールを採用する場合、採用したツール形式のファイルをSharePoint Serverで管理する方法が一般的ですが、そのツールが独自にリポジトリーを提供している場合は、Team Foundation Serverとの相互運用を考慮する必要があるでしょう。

同一のリポジトリーを使用できない場合は、管理コストが増加することを覚悟しなければなりません。モデル要素以外の成果物については、Excel, Word, Visio などのファイル形式のフォーマットを使用するケースが多いでしょうが、ユースケース記述のように、ユースケースモデルとの関連性が高いものについては、SharePointのカスタムリストで管理するというのもひとつの解決策です。
([コラム] SharePointのカスタムリストによるユースケース記述の管理 参照)

ソースコードの管理についても、チーム構成やリリース計画に基づいてどのようなディレクトリー構成を採用するか決めておく必要があります。ブランチ作成のポリシーについても決めておいた方がよいでしょう。

タスク管理

MSFのテンプレートにタスクの種類が予め用意されていますが、必要に応じてカスタマイズします。開発者のタスクとして、「ソースコードレビュー」や「リファクタリング」など頻繁に行う活動を登録するとよいでしょう。

問題管理

タスク管理と同様、問題管理についてもプロジェクトに合わせて項目をカスタマイズします。利用者からの問い合わせを登録するための「問い合わせ」を追加したりするのもよいでしょう。

要件

要件は、業務要件とシステム要件に分かれます。
このホワイトペーパーでは、業務要件とシステム要件の一部は発注者領域、システム要件は準委任領域に分類しています(図 3 システム開発地図に責任分界をオーバーレイ)。要件は、Visual Studio 2010のモデリング機能やOffice文書で管理することになります。

業務要件

業務要件は、Team Foundation Serverで項目管理します。
MSF for Agileの場合、ユーザーストーリーがありますが、これはどちらかというとシステム要件に近いため、項目を追加して管理した方がよいでしょう。ただ、実際にはシステム要件を項目管理した方が、管理コストが低くなるため、業務要件は、Office文書として管理するのもひとつの考え方です。

Visual Studio 2010では、業務フローはアクティビティー図(Activity Diagram)、概念モデルはクラス図(Class Diagram)で記述可能ですが、データフローなどは適切なダイアグラムが存在しないため、VisioなどOffice文書として管理するとよいでしょう。

システム要件

システム要件定義において、機能要件・非機能要件については、Team Foundation Serverの項目で管理します。
業務要件と同様、独自項目として追加するとよいでしょう。小規模なシステムでは、MS Agileのユーザーストーリーをシステム要件と捉えて管理するのもよいでしょう。
ユースケースやドメインモデルなどは、業務要件と同様Visual Studioのモデリング機能で作成し管理することができます。

ユースケースやビジネスロジックでは表現されないユーザビリティー要件については、画面のプロトタイプで詳細を確認するのも効果的です。Expression Blend 3のSketchFlowは、プロトタイピングツールですが、Visual Studioのソリューションとして管理できるため、チームプロジェクトで管理が可能です。
ユースケースから導き出されたテストケースもTeam Foundation Serverで管理可能です。ユースケースとテストケースを関連付けて管理できるため、要件から実装、テストにいたるトレーサビリティーを確保することが可能です(図 6)

【図6】ユースケースからテストケースのトレーサビリティー

[コラム] SharePointのカスタムリストによるユースケース記述の管理

ユースケース記述は、UMLモデリングツール内部で管理することが一般的ですが、Visual Studio のモデリング機能では、ユースケース記述を管理できません。納品物として管理したい場合、Excelを使用することも考えられますが、ユースケースモデルと別ファイルになり、トレーサビリティーを維持するのが煩雑になります。そこで、SharePointのカスタムリストを使って、ユースケース記述を管理する方法をご紹介します。SharePointの初歩的な知識があれば、ユースケース記述に必要なカスタムリストを簡単に作成できます(図 7)

【図７】SharePoint カスタムリストによるユースケース記述の管理

Visual Studio のユースケースモデルには、ハイパーリンクをコメントとして埋め込むことができます。SharePointのカスタムリストのURLをハイパーリンクとして埋め込めば、ユースケースモデルとユースケース記述の関連を管理できます(図 8)
また、SharePoint上に作ったリストはExcel表として出力できるため、納品物としての体裁を整えるのも容易です。

【図８】ユースケースモデルとユースケース記述の関連付け

SharePointサービスはTeam Foundation Serverと連携して様々な機能を提供しています(図 9)

図９】Team Foundation ServerにおけるSharePointの利用

※転載元の情報は上記執筆時点の情報です。
　上記執筆後に転載元の情報が修正されることがあります。