新規プロジェクトを成功させるには
フレームワーク・プロジェクトを成功に導くには以下のような手順を追っていくことが必要です。
1. プロトタイプを作成し、これを再検討後、エンドユーザーの代表と開発者が正式に合意し、承認します。 ユーザー側は何が出来上がるのかを理解し、開発者側は何を提供するのかを把握します。
これは期待管理の基本の形であり、以前からあるITプロジェクトの問題点、例えばユーザーの合意がとれていないケースや予期せぬ仕様変更などを避けられます。
2. 最低限サポートされる構成(MSC)に関するドキュメントを作成します。ここにはアプリケーションがどのサーバーやクライアントのプラットフォーム、Webブラウザをサポートするのかも含め、ソリューションが実際にサポートする最低限の構成を正式に記述します。
- 最低限のハードウェア要件（詳細は「コンピュータのシステム要件」を参照）
- 最低限のソフトウェア要件
- サポートされる画面解像度
- 最低限のネットワーク能力
- 最大データ量
正式な最低限サポートされる構成(MSC)には以下も含まれます。
- 全体のソリューションにかかるコストに関する決定を通知します。
- ソリューションの配布または後から加えられたパッチやホットフィックスをテストする際に必要な環境を確立します。
- 経営陣にこの”MSC以下”のソリューションを導入した場合のリスクを認識してもらいます。
詳細は 「アプリケーションのパフォーマンス」を参照してください。
開発を行う一方で最低限のプラットフォームでのパフォーマンスのテストを定期的に行います。 プロジェクトの最中もこのドキュメントの管理を行い、再発行します。
3. ビシネスの価値提案を発行します。ここではアプリケーションのビジネス価値を正式に定義します。特に既存のIBM i 5250アプリケーションが新しくなったり、置換される場合は必要です。
このアプリケーションにより、どのようにして、そして何故今までよりより良く、より早く、より賢明にビジネスを行うことができるのかを正式に説明します。 アプリケーションの価値提案を言葉や画像で定義できないと、これをソフトウェアに導入できる可能性は極めて低くなります。
ビジュアル・コンポーネント（例えばラジオ・ボタン、ドロップダウン・メニュー、メニュー・バーや色の諧調など）の導入自体が大きなビジネス価値になることはめったにありません。 エンドユーザーがITプロジェクトのビジネス価値についてほとんど説明を受けていない、もしくは全く説明されていないことは今までも繰り返されてきた悪い習慣です。
4. プロジェクト計画に配布とテストにかける十分な時間を設けます。 開発者はよく「これは数日で終わる」と短縮してしまいがちです。 こういったことにより、ITプロジェクトのコストが見積もりを超えてしまうことがよくあります。
通常のアプリケーション・レベルでの単体および結合テストに加え、配布戦略を設計する時間、それを導入して全てのサポートされるプラットフォームでテストする時間をそれぞれ織り込む必要があります。 専用のテスト要員やハードウェア・リソースをアプリケーション・テストだけに充てるというオプションも考えられるでしょう。