あなたの開発標準をもっと効果的に実践してみませんか？
こんな課題抱えていませんか？
- 開発標準は作ったけれども、
なかなかプロジェクトに徹底できない
- 開発標準を改善していきたいが、
プロジェクトからのフィードバックをどうやって集める？
- 品質向上のためにトレーサビリティーを管理したいが、
コストがかかりすぎる
- 仕様の変更や追加が起きるたびに、
影響分析に大きなコストを費やしている
MDAD/ProjectTower®が解決します！
ProjectTower®は、あなたのソフトウェア開発標準を実行するソフトウェアファクトリー環境を提供することで、
ソフトウェアのライフサイクルを通して、開発生産性の向上と成果物品質の安定に大きな効果を発揮します。
MDADが提供するメタモデルを利用して、あなたのソフトウェア開発標準をUMLモデル化して、
ProjectTower®に搭載することで、その開発標準が採用する開発方法論にかかわらず、
ProjectTower®は搭載された開発標準に則って、プロジェクトを駆動します。ProjectTower®は、
ソフトウェア開発プロセスをより効果的にマネージメントすることで、品質の安定、製品開発の時間短縮、
コスト削減をより高いレベルで実現することを目的としています。
▲pagetop
MDAD（Model-Driven Adaptive Development/モデル駆動適用型開発）
MDADはオフショア活用によってソフトウェア開発産業のデリバリーモデルが広域化するなかでも、
高品質なソフトウェア開発を提供するトレーサビリティー中心（Traceability-centric）のアプローチです。
これまでのプロセス中心（Process-centric）のアプローチとはちがい、
プロジェクトのライフサイクル中に作成されるべき様々な要求・仕様とそれらの依存関係
（トレーサビリティー）をプロセス定義や成果物定義の根拠としています。
MDADで言うところの"モデル駆動"は、UMLで表現されたクラス図からのコード自動生成ではありません。
MDADのアプローチでは、プロジェクトに適用する開発標準を、仕様の構成（トレーサビリティー）、成果物の構成、
タスクの構成とその前後関係という3つの視点でUMLモデルに定義し、これらをソフトウェア（ProjectTower®）によって駆動することで、
開発標準（モデル）に準拠している成果物（インスタンス）しか生成させません。すなわち、生成される成果物は開発標準に定義されている範囲を超えることはなく、
プロジェクトのライフサイクル期間中に、将来何がいつ生成されるかは予測可能ということになります。このことが、過不足の無い開発活動を可能にするとともに、
下流工程での予期せぬ設計バグの発覚等を予防し、開発標準の改善活動を安全且つ効率的に行うことを可能にします。
開発標準のモデル化にあたっては、OMG（Object Management Group）が提唱するモデル化アーキテクチャーを踏襲しています。
MDADのモデル化アーキテクチャーでは、3つのメタモデルとモデル化のためのガイドラインをM2-levelの層に開発標準のモデル化の方針として定義し、
そのモデル化方針に準拠して策定された開発標準をM1-levelの層に定義します。
この開発標準の層には、3つのモデルと各種仕様書のテンプレート、標準工程表、標準利用のためのガイドラインが定義されます。
そしてM0-levelの層は、M1-levelの開発標準に準拠して実際に遂行された個々のプロジェクトであり、
実際に作成された工程表や成果物を現します。
すなわち、開発標準に準拠するすべてのプロジェクトは、M1-levelに定義された標準工程表に沿って実施され、
そのプロジェクトに従事するすべての開発者はM1-levelに定義された各種の仕様書テンプレートに仕様を記述しなければなりません。
プロジェクトを実施することでM0-levelに蓄積されたノウハウや露呈した問題は、抽象化されたのちにM1-levelへとフィードバックされ、
開発標準を次第に成熟させていくことができます。
M1-levelの仕様構成モデルに準拠して生成されるM0-levelのインスタンスをトレーサビリティー（追跡可能性）と記載していますが、
上流の仕様が下流の仕様に具体化されるという依存関係は、その依存関係を遡った場合、一般的にトレーサビリティーと呼ばれている概念と同じであり、
仕様という細かい粒度でトレーサビリティーが管理されていることは、仕様変更が起きた場合の影響分析や手戻り工程の導出にとって大きなアドバンテージとなります。
▲pagetop
ProjectTower® ソフトウェア開発標準駆動エンジン
ProjectTower®は、 MDADアプローチの実現形であり、
搭載された開発標準モデルに則ってプロジェクトを駆動するソフトウェアファクトリーエンジンです。
ProjectTower®は、リポジトリー（構成管理サーバー）のバックエンドに配置され、
プロジェクトメンバーのリポジトリーへの成果物登録操作に呼応して実行されます。
ProjectTower®は、構成管理サーバ（Subversion®）のバックエンドに配置されていますので、
通常お使いの構成管理クライアント（TortoiseSVN®など）以外にクライアントアプリを必要としません。
また、実際の工程表や仕様書の作成に関しては、MS-Project®やMS-Word®、Excel®を使って行いますので、
特別なツールの利用知識を必要としません。プログラム作成に関しましては、
Eclipse®など使い慣れたツールをご利用いただけます。
ProjectTower®には、成果物作成のワークフローと成果物変更のワークフローがビルトインされています。
成果物作成のワークフロー
プロジェクト管理者が基準計画を登録することによって、プロジェクトが開始され、 ProjectTower®からタスクの担当者に順次、作業開始の指示が出されます。
各担当者は、ウェブ画面によって自分への指示を確認し、これに対して作業開始を宣言することで、 ProjectTower®はタスクが開始されたことを認識します。
担当者は、指示に記載されている仕様書テンプレートを取得し、指示とともに記載されている作業ガイドに従って、成果物の作成を行います。
成果物の作成が終了したところで、レビューを開催し、その結果をウェブ画面で登録します。
レビューの評価が「合格」で登録された場合にのみ、ProjectTower®は、タスクが完了したと判断して、後続のタスクの担当者に作業開始の指示を出します。
レビュー報告には、レビュー結果の他に、欠陥発生件数、欠陥除去件数、作業時間（開発作業時間、レビュー準備時間、レビュー実施時間）の記載が必須となっていますが、
チェックリストや欠陥表などを記載することで、より効果的なレビューを行うことができます。
成果物変更のワークフロー
仕様変更などに対応するための成果物の変更は、ウェブ画面によって変更依頼を起票し、 ProjectTower®に登録することによって開始されます。
変更依頼書が登録されることによって、 ProjectTower®はそれまでに蓄積されているトレーサビリティ情報をもとに仕様変更による影響範囲と影響度を算出します。
影響度が大きいと判定した場合には、成果物構成とプロジェクトライフサイクルの情報から手戻り工程表を生成し、プロジェクト管理者に通知します。
プロジェクト管理者は、通知情報に記載されている手戻り工程表と変更依頼をウェブ画面で確認した後に、手戻り工程を実施する場合には、変更依頼を承認し再登録します。
手戻り工程に、日程、期間、リソースなどの変更を加えた場合は、手戻り工程も再登録します。
ProjectTower®は、この操作によって、手戻り工程が承認されたと判断し、担当者に変更作業の指示出します。
これ以降は、前述の成果物作成のワークフローに従って、手戻り工程が推進されます。
▲pagetop
もっと詳しい内容を読む
ソリューション&サービス一覧
