TOP
＞
プロジェクト管理
＞ クラスデザイナ
開発ライフサイクルとVisual Studio 2005という選択肢
第２回：アーキテクチャ策定における有効性を探る
著者：
日本ユニシス 塚田 高弘
2005/11/8
前のページ
1
2
3
4
次のページ
クラスデザイナ
クラスデザイナでは、完全にコードと同期したクラス図を記述できます。つまりクラス図を記述するだけで自動的にコードが生成されるのです。モデル図とコードは常に同期しているため、コードの側を変更してもクラス図がリバースエンジニアリングされ、常に整合性を取った状態で開発が進められます。
Team Explorer
VS2005 Team Systemでは、Visual Studio Team Foundation Serverという開発を支える新しい基盤製品が提供されています。Team Architectsに限らず、Team Developers、Team Testersにも、Team Foundation Serverを利用するためのクライアントが含まれています。この機能に関しては第4回で詳しく述べますので、今回は割愛させていただきます。
「LUCINA for .NET」の開発プロセス概要
次に「LUCINA for .NET」の開発プロセスの概要について解説します。
開発プロセスとは要求をシステムにする過程であり、一般的な開発プロセスは要求分析・外部設計・内部設計・実装・テスト…と1つずつ目的別・工程別に分かれていますが、LUCINAのプロセスは図9のように「業務分析フェーズ」「システム構築フェーズ」の簡素化した2フェーズから成っています。
図9：LUCINAの開発プロセス
（画像をクリックすると別ウィンドウに拡大図を表示します）
業務分析フェーズはウォータフォールモデルにおける要件定義と外部設計にあたり、システム構築フェーズは詳細設計・実装・テストにあたります。
業務分析フェーズでの重要ポイント
さて業務分析フェーズにおけるVSTE for SAを重要ポイントに対して評価したいと思いますが重要ポイントってどこでしょうか。
それは機能要件と非機能要件の双方の要求を正確に満たすための「機能要求変化・管理」「最適なアーキテクチャの定義と検証」および「プロセス全体における成果物の連携」です。
機能要求の変化・管理
業務分析フェーズの重要な2つの柱（図9の黄色の線で囲んだ上の部分）の1つに「機能要件」の設計があり、この中で難易度を高めるのが顧客の要求の変化です。
システム受託開発に携わったことのある方であれば実感できると思いますが、システム開発中に顧客の機能要件が変化していくことが多々あります。LUCINAでは各フェーズでの繰り返し型のライフサイクルモデルを採用し、この要求の変化に柔軟に対応しています。
最適なアーキテクチャの定義と検証
業務分析フェーズのもう1つの柱は、「非機能要件」の実現を左右するアーキテクチャ策定です（図9の黄色の線で囲んだ下の部分）。
アーキテクチャ（注1）は「システムの非機能要件に影響を与える設計の主要な要素」と定義しています。「システムの非機能要件」は、パフォーマンス、セキュリティ、保守性、信頼性などを指し、そしてこれらに影響を与える設計の主要な要素とは、システムを構成する部品の種類、インターフェース、内部構造、全体を特徴づける要素技術のことを指します。
※注1：
アーキテクチャというと一般的にアプリケーション・アーキテクチャを指すことが多いのですが、ここでは基盤配置も含めた広義のアーキテクチャを指します。
アーキテクチャを確立する際には、機能や論理構造そしてそれらを実現するサブシステムやコンポーネントの構成、ネットワークトポロジ、物理的な分散や配置の仕組みが明確に規定され、かつ十分に検証されていなければなりません。
アーキテクチャは名前のとおりシステムの構造であり、これを誤ると手戻り時の影響範囲が大きく「計画工数オーバー」「納期大遅延」などの問題へと発展してしまうケースが多いのです。そのため正しいアーキテクチャの定義と検証は開発プロジェクト成功の重要要因なのです。
成果物の連携
大人数による大規模開発の場合は、次のプロセスの担当者が異なる場合が多く、ドキュメント（成果物）がコミュニケーションの大きな要素となりますので、各プロセスで決定されたことを次のプロセスの人に「いかに無駄がなく効率よく伝達するか」がポイントになります。
また繰り返しで進めることにより、成果物はプロジェクトメンバーにより頻繁に改定・更新が行われますので、ツールと成果物の連携が重要になります。連携がとれていないツールを使用し、人の手で更新がたびたび行われると、どんなに注意をしてもミスは避けられません。どれが最新であるかを管理するのも大変であり、管理を怠ると成果物の信憑性を失ってしまいます。
これは業務分析フェーズ内に限ったことではなく、業務分析フェーズからシステム構築フェーズへの連携、さらには保守フェーズまで成果物が利用されるためすべてのプロセスでいえることです。
それではVSTE for SAの新機能に着目して、「分散システムデザイナ」と「クラスデザイナ」の主な対象範囲（図9の赤い線で囲まれた部分）であるアーキテクチャ策定における有効性を検討していきましょう。
前のページ
1
2
3
4
次のページ
著者プロフィール
日本ユニシス株式会社 塚田 高弘
.NETビジネスディベロプメント所属
日本ユニシスにて推進する.NETサービスビジネスのなかで、とくにコラボレーティブアプリケーション関連の企画・開発・推進を実施。現在は、.NETにてコラボレーティブソリューションであるSymphonic Collaborationの拡販を担当。
INDEX
第2回：アーキテクチャ策定における有効性を探る
はじめに
アプリケーションデザイナ：Application Connection Designer
クラスデザイナ
アーキテクチャ策定におけるVSTE for SAの有効性
