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