2.0プロジェクト展開のフェーズ(パート1)

Table of contents

印心 #

プロジェクトの開始は、開始フェーズと呼ばれます。 このフェーズでは、プロジェクトのアイデアが調査および開発されます。 このフェーズの目標は、プロジェクトを実際に完了できるかどうかを確認することです。 誰が取り組みを主導するか、どの組織が参加するか、そしてビジネスが関係者から十分なサポートを受けるかどうかが選択されます。

このステップでは、既存または将来のプロジェクトリーダーが、上記の点を概説した提案を準備する必要があります。 事業計画や助成金申請は、この種のプロジェクト提案の例です。 プロジェクトの潜在的なスポンサーは、アプリケーションを評価し、承認された場合は必要な資金を提供します。 プロジェクトは正式に承認されて開始されます。 最初のフェーズでは、次の質問に対処する必要があります。

  • なぜこのプロジェクトなのか?
  • 物理的に可能ですか?
  • 望ましい結果は何ですか?
  • プロジェクトの制限は何ですか(プロジェクトのスコープに含まれるもの)?

「いいえ」と言う能力は、プロジェクトリーダーの重要な特徴です。 個人がプロジェクトに熱中すると、その範囲は拡大する傾向があります。 「私たちがそれに取り組んでいる間、私たちもそうかもしれません…」が根本的な考えです。 追加の目的が追加されたプロジェクト、および成長し続けるプロジェクトは、ほぼ確実に遅れて実行され、当初の目的を達成する可能性はほとんどありません。

最初のステップは、プロジェクトのすべての利害関係者の間で接続を確立することです。 範囲が十分に理解されていれば、プロジェクトの結果に関する非現実的な期待を回避できる可能性があります。 開始するには、関係するさまざまな人々の間の接続を確立します。 その範囲をしっかりと把握することが不可欠です。

特定の種類のプロジェクトに選択された方法は、その結果に大きな影響を与えます。 たとえば、研究開発の取り組みにより、アプリケーションの技術的な実行可能性を評価するレポートが提供される場合があります。 プロトタイプの開発につながるプロジェクトには、アプリケーションのすべての機能が含まれます。 それでも、特定の環境での使用に適している必要はありません(たとえば、数百人のユーザーによる)。 機能する製品を生産するプロジェクトは、保守、文書化、およびアプリケーション管理の問題にも対処する必要があります。

従事する人々のために多くの誤解や論争が発生しますプロジェクト管理これらの点については不明です。 プロジェクトチームのメンバーがプロトタイプを作成していると信じている間、顧客は機能的な製品を期待するかもしれません。 スポンサーは、プロジェクトが有用なソフトウェアになると考えるかもしれませんが、チームメンバーは、最初にその概念が技術的に実行可能かどうかを判断する必要があります。

意味 #

承認された開始プロジェクト計画の後、プロジェクトは2番目のフェーズである定義フェーズを開始しました。 このフェーズでは、プロジェクトの結果に関連する要件を可能な限り正確に指定します。 このフェーズでは、プロジェクトの開発に関与するすべての関係者の期待を決定する必要があります。 アーカイブにはいくつのファイルが必要ですか? メタデータはデータドキュメンテーションイニシアチブ(DDO)形式である必要がありますか、それともダブリンコア(DC)で十分ですか? ファイルは元の形式で許可されますか、それとも「優先標準」に準拠しているファイルのみが許可されますか? データセットがアーカイブで適切に処理されることを保証するのは寄託者の義務ですか、それともこれはアーキビストの責任ですか? プロジェクトの結果についてどのような保証が提供されますか? お問い合わせのリストは無期限に続く可能性があります。

プロセスのできるだけ早い段階でニーズを確立することが重要です。

Wijnen(2004)は、記憶補助として次のタイプのプロジェクトニーズを確立しています。

  • 前提条件
  • 機能の要件
  • 機能の要件
  • 設計上の制約

前提条件は、プロジェクトを実行する必要があるフレームワークを提供します。

法律、労働条件を管理する規則、および承認手順はすべて例です。 これらの基準は、プロジェクト内では不変です。

要件仕様は、最終出力の品質に関係する仕様、つまりプロジェクトの結果がどのように使用されるかに関連する技術仕様であることを覚えておくことが重要です。 たとえば、ソフトウェアプロジェクトの終了後、エラーの数を90%削減する必要があります。 一方、設計上の制限はプロジェクト固有の要件です。 例として、危険な化学物質や労働基準が疑わしい外国のパートナーをプロジェクトに含めることはできません。

主要な組織のコンソーシアム向けのWebアプリケーションの構築を含むプロジェクトの定義段階では、プログラムがサポートするブラウザーについての決定は行われませんでした。 コンソーシアムは、それがすべての人のブラウザだったので、MicrosoftExplorerになるだろうと考えました。

開発者はFirefoxでアプリケーションを構築しました。なぜなら、彼らはすでにブラウザに精通しており、開発全体を通して特に役立つ機能をいくつか持っていたからです。 Firefox用に設計されたほとんどのWebサイトは、Explorerでも見栄えがするため、最初は気付かなかった変更です。 しかし、プロジェクトの結論に向けて、クライアントはウェブサイトが「見栄えが良くなかった」と抗議し始めました。 Firefoxを介してサイトにアクセスしていたプログラマーは、苦情に当惑しました。

2つのブラウザに互換性がないことが明らかになったとき、プログラマーは防御的に応答しました。「Firefoxをインストールできませんか? 結局のところ、それは無料です」。 一方、組織は、何らかの理由でExplorerと一緒にFirefoxをインストールすることを拒否した政府のシステム管理者を義務付けました。

それをインストールしたいと思ったとしても、手順は長く、システム管理者が仕事に費やした時間に関連する追加費用が発生していました。 最後に、アプリケーションをExplorerに適合させる必要があると判断しました。 これにはかなり多くの労力が必要であり、その結果、プロジェクトは予定よりも大幅に遅れ、追加コストの交渉が必要になりました。 その後の調査により、さまざまな組織が異なるバージョンのMicrosoftExplorerを使用していることが明らかになりました。

プロジェクトに関与するすべての利害関係者、特にプロジェクトの結果を利用するエンドユーザーが、定義フェーズ全体を通じて参加することが重要です。 多くの場合、エンドカスタマーはプロジェクトを注文するものではないため、無視されることがよくあります。 定義段階では、プロジェクトの料金を支払う顧客が要件に貢献するように求められます。 それにもかかわらず、イニシアチブは将来のユーザーを招待することによって得られます。 出発点として、プロジェクトの定義フェーズ全体を通じて、すべての利害関係者との会議を確立することが有益です。

その後、ユーザー(若者)が教育ビデオゲームの開発に携わりました。 ゲームの準備がほぼ整うと、若者のグループでテストすることにしました。 彼らの最初の評価は中程度で友好的であるように見えました。 しかし、プッシュされたとき、彼らはゲームが「非常に鈍い」と感じ、「自分でプレイしない」ことを認めました。 これらの若い個人がプロジェクトの早い段階で従事していれば、ゲームは間違いなく成功していたでしょう。 現在、ゲームはインターネットWebサイトにほとんど配置されていません。

定義フェーズでは、プロジェクトに関与するすべての利害関係者からのニーズのリストが作成されます。 もちろん、各条件には逆があります。

仕事が複雑になるほど、より多くの時間とお金が必要になります。 さらに、一部の基準は互いに衝突する可能性があります。 より環境にやさしいことを目的とした新しいコピー機。また、火災安全基準を満たさなければなりません。 火災安全を管理する規制は、環境にやさしくない難燃性材料の使用を義務付けています。 この画像に示されているように、対処する必要があります。

最後に、明確な基準のリストが作成され、承認のためにプロジェクトの意思決定者に提出されます。 リストの承認後、設計プロセスが開始される場合があります。クライアントとプロジェクトチーム間の合意の大部分は、定義フェーズの終わりまでに到達します。

要件リストは、プロジェクトが動作しなければならないパラメータを確立します。

このリストは、プロジェクトチームを評価するために使用されます。 その結果、クライアントは定義フェーズの後にニーズを追加できません。

プロジェクトの一環として作成されたコンピューターのインスタレーションには、美術館での新しい展示が含まれています。 プロジェクトには明確な段階がなかったため、美術館と施設の建設責任者の間で具体的な交渉は行われませんでした。 インスタレーションのコンピューターが途中で故障したとき、博物館はプロジェクトの保証がそれをカバーすると信じていました。 プロジェクトチームは反対の立場を取りました。合意に達するには、取締役間の交渉が必要でした。

設計 #

定義フェーズの一連の要件は、設計上の決定を導くために使用できます。 設計段階では、プロジェクトの目的を達成していると思われる1つ以上の設計が作成されます。 設計段階では、プロジェクトのトピックに応じて、ジオラマ、図面、フローチャート、サイトツリー、HTML画面デザイン、プロトタイプ、画像の印象、およびUMLスキーマを作成できます。 プロジェクトリーダーは、これらの図面を使用して、プロジェクトの最終設計を選択します。 その後、開発フェーズが始まります。 デザインが選択されると、定義フレーズのように、プロジェクトの後続の段階全体で変更することはできません。

この場合、「設計部門」というフレーズは適切ではありませんでした。むしろ、コラボレーションしたデザイナーのグループを指していました。 さらに、部門の責任者を含め、全員が忙しすぎました。

あるプロジェクトでは、プロジェクトの成功に不可欠なさまざまなデザインを作成する必要がありました。 プロジェクトチームの若いデザイナーによって開発されたデザイン。 設計チームの責任者は最終的に設計を担当しましたが、設計をレビューするプロジェクトチーム会議に出席することはありませんでした。 投影している上司は一貫して彼を招待し、彼の若い同僚による図面を含む電子メールを彼に送信しましたが、電子メールは無視されました。 プロジェクトリーダーと若い設計者は、部門長が設計を受け入れたと誤って信じていました。 実装のフェーズが始まりました。 プロジェクトがほぼ完了したとき、結果を部門長に渡しました。部門長は激怒し、すべてをやり直すことができるように命じました。