Software-engineering-software-project-management
ソフトウェアプロジェクト管理
ソフトウェア開発に携わるIT企業の職務パターンは、2つの部分に分かれています。
- ソフトウェア作成
- ソフトウェアプロジェクト管理
プロジェクトは明確に定義されたタスクであり、目標を達成するために行われたいくつかの操作の集まりです（たとえば、ソフトウェアの開発と配布）。 プロジェクトは次のように特徴付けられます。
- すべてのプロジェクトには、独自の明確な目標があります。
- プロジェクトは、日常的な活動や日常業務ではありません。
- プロジェクトには開始時刻と終了時刻があります。
- プロジェクトはその目標が達成されたときに終了するため、組織の存続期間における一時的な段階です。
- プロジェクトには、時間、人材、資金、材料、知識バンクの面で十分なリソースが必要です。
ソフトウェアプロジェクト
ソフトウェアプロジェクトは、要件の収集からテストとメンテナンスまでのソフトウェア開発の完全な手順であり、目的のソフトウェア製品を実現するために、指定された期間内に実行方法に従って実行されます。
ソフトウェアプロジェクト管理の必要性
ソフトウェアは無形の製品と言われています。 ソフトウェア開発は、世界のビジネスにおけるまったく新しい流れの一種であり、ソフトウェア製品の構築に関する経験はほとんどありません。 ほとんどのソフトウェア製品は、クライアントの要件に合わせてカスタマイズされています。 最も重要なことは、基盤となる技術が頻繁にかつ急速に変化および進歩するため、ある製品の経験が他の製品に適用されない可能性があることです。 こうしたビジネス上の制約や環境上の制約はすべて、ソフトウェア開発にリスクをもたらすため、ソフトウェアプロジェクトを効率的に管理することが不可欠です。
上の画像は、ソフトウェアプロジェクトの3つの制約を示しています。 高品質の製品を提供し、クライアントの予算内でコストを抑え、計画どおりにプロジェクトを実施することは、ソフトウェア組織の重要な部分です。 このトリプルコンストレイントライアングルに影響を与える可能性のある内部および外部のいくつかの要因があります。 3つの要因のいずれかが他の2つの要因に深刻な影響を与える可能性があります。
したがって、予算と時間の制約とともにユーザー要件を組み込むには、ソフトウェアプロジェクト管理が不可欠です。
ソフトウェアプロジェクトマネージャー
ソフトウェアプロジェクトマネージャーは、ソフトウェアプロジェクトを実行する責任を負います。 ソフトウェアプロジェクトマネージャーは、ソフトウェアが通過するSDLCのすべてのフェーズを完全に認識しています。 プロジェクトマネージャーは、最終製品の生産に直接関与することはありませんが、生産に関わる活動を管理および管理します。
プロジェクトマネージャーは、開発プロセスを綿密に監視し、さまざまな計画を準備および実行し、必要かつ適切なリソースを手配し、コスト、予算、リソース、時間、品質、顧客満足度の問題に対処するためにすべてのチームメンバー間のコミュニケーションを維持します。
プロジェクトマネージャーが負う責任をいくつか見てみましょう。
管理人
- プロジェクトリーダーとして行動する
- 利害関係者との連絡
- 人事管理
- レポート階層などの設定
管理プロジェクト
- プロジェクト範囲の定義と設定
- プロジェクト管理活動の管理
- 進行状況とパフォーマンスの監視
- あらゆる段階でのリスク分析
- 問題を回避または解決するために必要な措置を講じる
- プロジェクトスポークスマンとして行動する
ソフトウェア管理活動
ソフトウェアプロジェクト管理は、プロジェクトの計画、ソフトウェア製品の範囲の決定、さまざまな用語でのコストの見積もり、タスクとイベントのスケジューリング、およびリソース管理を含む多数のアクティビティで構成されます。 プロジェクト管理活動には以下が含まれます。
- プロジェクト計画
- スコープ管理
- プロジェクト見積もり
プロジェクト計画
ソフトウェアプロジェクトの計画はタスクであり、ソフトウェアの生産が実際に開始される前に実行されます。 ソフトウェア生産のためにありますが、ソフトウェア生産と方向性のある具体的な活動は一切含まれていません。むしろ、ソフトウェアの生産を促進する複数のプロセスのセットです。 プロジェクトの計画には次のものが含まれます。
スコープ管理
プロジェクトの範囲を定義します。これにはすべてのアクティビティが含まれ、成果物のソフトウェア製品を作成するためにプロセスを実行する必要があります。 スコープ管理は、プロジェクトで行われることと行われないことを明確に定義することでプロジェクトの境界を作成するため、不可欠です。 これにより、プロジェクトに限定された定量化可能なタスクが含まれるようになり、簡単に文書化でき、コストと時間の超過を回避できます。
プロジェクトスコープの管理中に、次のことが必要です-
- スコープを定義する
- 検証と制御を決定する
- 管理を容易にするために、プロジェクトをさまざまな小さな部分に分割します。
- スコープを確認する
- スコープに変更を組み込むことにより、スコープを制御します
プロジェクト見積もり
効果的な管理のためには、さまざまな測定値の正確な推定が必須です。 正しい見積もりにより、マネージャーはプロジェクトをより効率的かつ効果的に管理および制御できます。
プロジェクトの見積もりには、次のものが含まれます。
ソフトウェアサイズの見積もり
ソフトウェアのサイズは、KLOC（Kilo Line of Code）の観点から、またはソフトウェア内の機能ポイントの数を計算することによって推定できます。 コードの行はコーディング慣行に依存し、機能ポイントはユーザーまたはソフトウェアの要件によって異なります。
工数の見積もり
マネージャーは、ソフトウェアを作成するために必要な人員要件と工数の面で努力を見積もります。 労力を見積もるには、ソフトウェアのサイズがわかっている必要があります。 これは、管理者の経験、組織の履歴データ、またはソフトウェアのサイズを標準的な式を使用して成果に変換することにより導き出すことができます。
時間の見積もり
サイズと労力が見積もられると、ソフトウェアの作成に必要な時間を見積もることができます。 必要な努力は、要件の仕様およびソフトウェアのさまざまなコンポーネントの相互依存性に従って、サブカテゴリに分類されます。 ソフトウェアタスクは、ワークブレイクスルー構造（WBS）によって小さなタスク、アクティビティ、またはイベントに分割されます。 タスクは、毎日または暦月ごとにスケジュールされます。
すべてのタスクを数時間または数日で完了するために必要な時間の合計は、プロジェクトを完了するために費やされた合計時間です。
費用の見積もり
これは、これまでのどの要素よりも多くの要素に依存しているため、すべての中で最も難しいと考えられるかもしれません。 プロジェクトコストを見積もるには、以下を考慮する必要があります-
- ソフトウェアのサイズ
- ソフトウェア品質
- ハードウェア
- 追加のソフトウェアまたはツール、ライセンスなど
- タスク固有のスキルを持つ熟練した人材
- 関係する旅行
- コミュニケーション
- トレーニングとサポート
プロジェクト推定手法
サイズ、労力、時間、コストなど、プロジェクトの見積もりに関連するさまざまなパラメーターについて説明しました。
プロジェクトマネージャーは、広く知られている2つの手法を使用して、リストされた要因を推定できます。
分解技術
この手法は、ソフトウェアをさまざまな構成の製品として想定しています。
主に2つのモデルがあります-
- *コードの行*推定は、ソフトウェア製品のコードの行数に代わって行われます。
- *機能ポイント*推定は、ソフトウェア製品の機能ポイントの数に代わって行われます。
経験的推定手法
この手法では、経験的に導出された式を使用して推定を行います。これらの式はLOCまたはFPに基づいています。
- パトナムモデル +このモデルは、Lawrence Hによって作成されました。 パットナム、ノルデンの頻度分布（レイリー曲線）に基づいています。 パトナムモデルは、ソフトウェアサイズに必要な時間と労力をマッピングします。
- ココモ + COCOMOは、バリーWが開発したCOnstructive COst MOdelの略です。 ベーム。 ソフトウェア製品を、オーガニック、セミデタッチ、および組み込みの3つのソフトウェアカテゴリに分類します。
プロジェクトのスケジューリング
プロジェクトのプロジェクトスケジューリングとは、指定された順序で、各アクティビティに割り当てられたタイムスロット内で実行されるすべてのアクティビティのロードマップを指します。 プロジェクトマネージャーは、さまざまなタスクを定義し、プロジェクトのマイルストーンを作成し、さまざまな要因を考慮してそれらを調整する傾向があります。 タスクは、スケジュール内のクリティカルパスにあります。これは、特定の方法（タスクの相互依存性）で、厳密に割り当てられた時間内に完了するために必要です。 クリティカルパスの範囲外にあるタスクの配置は、プロジェクトのすべてのスケジュールに影響を与える可能性が低くなります。
プロジェクトをスケジュールするには、次のことが必要です-
- プロジェクトのタスクをより小さく管理しやすい形式に分解する
- さまざまなタスクを見つけて相関させる
- 各タスクに必要な推定時間枠
- 時間を作業単位に分割する
- 各タスクに適切な数のワークユニットを割り当てます
- プロジェクトの開始から終了までに必要な合計時間を計算する
資源管理
ソフトウェア製品の開発に使用されるすべての要素は、そのプロジェクトのリソースと見なされる場合があります。 これには、人的資源、生産的なツール、ソフトウェアライブラリが含まれる場合があります。
リソースは限られた量で利用可能であり、資産のプールとして組織にとどまります。 リソースの不足はプロジェクトの開発を妨げ、スケジュールより遅れることがあります。 追加のリソースを割り当てると、最終的に開発コストが増加します。 したがって、プロジェクトに十分なリソースを見積もり、割り当てる必要があります。
リソース管理に含まれるもの-
- プロジェクトチームを作成し、各チームメンバーに責任を割り当てることにより、適切な組織プロジェクトを定義する
- 特定の段階で必要なリソースとその可用性の決定
- 必要なときにリソース要求を生成し、不要になったときにリソースの割り当てを解除して、リソースを管理します。
プロジェクトリスク管理
リスク管理には、プロジェクトの予測可能および予測不可能なリスクの特定、分析、およびプロビジョニングに関するすべてのアクティビティが含まれます。 リスクには次のものが含まれます。
- プロジェクトを離れる経験豊富なスタッフと新しいスタッフがやってくる。
- 組織管理の変更。
- 要件の変更または要件の誤解。
- 必要な時間とリソースの過小評価。
- 技術変化、環境変化、ビジネス競争。
リスク管理プロセス
リスク管理プロセスには次のアクティビティが含まれます。
- *識別-*プロジェクトで発生する可能性のあるすべてのリスクをメモします。
- *分類-*既知のリスクを、プロジェクトへの影響の可能性に応じて、高、中、低のリスク強度に分類します。
- *管理-*さまざまな段階でリスクが発生する確率を分析します。 リスクを回避または直面する計画を立てます。 副作用を最小限に抑えるようにします。
- *監視-*潜在的なリスクとその初期症状を綿密に監視します。 また、それらを軽減または回避するために実行された手順の影響を監視します。
プロジェクトの実行と監視
このフェーズでは、プロジェクト計画に記述されているタスクがスケジュールに従って実行されます。
実行は、すべてが計画どおりに進んでいるかどうかを確認するために監視する必要があります。 監視とは、リスクの可能性を確認するために観察し、リスクに対処したり、さまざまなタスクのステータスを報告したりすることです。
これらの手段には以下が含まれます-
- *アクティビティの監視-*一部のタスク内でスケジュールされたすべてのアクティビティは、毎日監視できます。 タスク内のすべてのアクティビティが完了すると、完了したと見なされます。
- *ステータスレポート-*レポートには、特定の時間枠（通常は1週間）内に完了したアクティビティとタスクのステータスが含まれます。 ステータスは、完了、保留中、または進行中などとしてマークできます。
- *マイルストーンチェックリスト-*すべてのプロジェクトは、SDLCのフェーズに基づいて主要なタスク（マイルストーン）が実行される複数のフェーズに分割されます。 このマイルストーンチェックリストは、数週間に1回作成され、マイルストーンのステータスを報告します。
プロジェクトコミュニケーション管理
効果的なコミュニケーションは、プロジェクトの成功に不可欠な役割を果たします。 これは、クライアントと組織の間のギャップを、チームメンバーとプロジェクトのその他の利害関係者（ハードウェアサプライヤなど）の間で埋めます。
コミュニケーションは口頭でも書面でも可能です。 通信管理プロセスには、次の手順があります。
- 計画-このステップには、プロジェクトのすべての利害関係者の識別とそれらの間のコミュニケーションのモードが含まれます。 また、追加の通信機能が必要かどうかも考慮します。
- 共有-計画のさまざまな側面を決定した後、マネージャーは正しい情報を正しい時間に正しい人と共有することに集中します。 これにより、プロジェクトに関係するすべての人がプロジェクトの進捗状況とステータスを最新の状態に保ちます。
- フィードバック-プロジェクトマネージャーは、さまざまな手段とフィードバックメカニズムを使用して、ステータスおよびパフォーマンスレポートを作成します。 このメカニズムにより、さまざまな利害関係者からのインプットがフィードバックとしてプロジェクトマネージャーに送られます。
- 閉鎖-各主要イベントの終了時、SDLCのフェーズの終了時、またはプロジェクト自体の終了時に、電子メールの送信、文書のハードコピーの配布、またはその他の効果的な手段により、すべての利害関係者を更新するための管理上の閉鎖が正式に発表されますコミュニケーション。
閉鎖後、チームは次のフェーズまたはプロジェクトに移行します。
構成管理
構成管理は、製品の要件、設計、機能、および開発の観点からソフトウェアの変更を追跡および制御するプロセスです。
IEEEは、「システム内のアイテムを識別および定義し、ライフサイクル全体でこれらのアイテムの変更を制御し、アイテムおよび変更リクエストのステータスを記録および報告し、アイテムの完全性と正確性を検証するプロセス」と定義しています。
一般に、SRSが完成すると、ユーザーが変更を要求する可能性は低くなります。 それらが発生した場合、コストと時間のオーバーランの可能性があるため、変更は上級管理職の事前承認によってのみ対処されます。
ベースライン
SDLCのフェーズは、ベースライン化された場合、つまり、 ベースラインは、フェーズの完全性を定義する測定値です。 フェーズは、それに関連するすべてのアクティビティが終了し、十分に文書化されるとベースラインになります。 最終段階ではない場合、その出力は次の即時段階で使用されます。
構成管理は、組織管理の分野であり、フェーズのベースライン化後に変更（プロセス、要件、技術的、戦略的など）の発生を処理します。 CMは、ソフトウェアで行われた変更を常にチェックします。
変更管理
変更管理は構成管理の機能であり、ソフトウェアシステムに加えられたすべての変更が一貫性を保ち、組織の規則および規制に従って行われることを保証します。
製品の構成の変更は、次の手順を経て行われます-
- 識別-変更要求は、内部ソースまたは外部ソースから到着します。 変更要求が正式に識別されると、適切に文書化されます。
- 検証-変更要求の有効性が確認され、その処理手順が確認されます。
- 分析-変更要求の影響は、スケジュール、コスト、および必要な労力の観点から分析されます。 システムに対する将来の変更の全体的な影響が分析されます。
- コントロール-予想される変更がシステム内のエンティティに影響を与えすぎるか、避けられない場合、変更がシステムに組み込まれる前に、高い権限の承認を取ることが必須です。 変更を組み込む価値があるかどうかが決定されます。 そうでない場合、変更要求は正式に拒否されます。
- 実行-前のフェーズが変更要求の実行を決定した場合、このフェーズは変更を実行するために適切なアクションを実行し、必要に応じて徹底的な改訂を行います。
- 閉じるリクエスト-変更が正しい実装とシステムの他の部分とのマージのために検証されます。 このソフトウェアに新たに組み込まれた変更は適切に文書化され、リクエストは正式にクローズされます。
プロジェクト管理ツール
リスクと不確実性は、プロジェクトが設定された方法論に従って開発された場合でも、プロジェクトのサイズに関して複数倍に上昇します。
効果的なプロジェクト管理を支援するツールが利用可能です。 いくつかの説明があります-
ガントチャート
ガントチャートは、ヘンリーガント（1917）によって考案されました。 これは、期間に関するプロジェクトスケジュールを表します。 これは、プロジェクトのアクティビティとスケジュールされたアクティビティを表す横棒グラフです。
PERTチャート
PERT（プログラム評価とレビュー手法）チャートは、プロジェクトをネットワーク図として描写するツールです。 プロジェクトのメインイベントを並列的および連続的な方法でグラフィカルに表すことができます。 次々に発生するイベントは、前のイベントに対する後のイベントの依存関係を示します。
イベントは番号付きノードとして表示されます。 これらは、プロジェクト内のタスクのシーケンスを示すラベル付き矢印で接続されています。
リソースヒストグラム
これは、プロジェクトイベント（またはフェーズ）に必要なリソース（通常は熟練したスタッフ）の数を表す棒グラフまたはチャートを含むグラフィカルツールです。 リソースヒストグラムは、スタッフの計画と調整のための効果的なツールです。
image:/softwareengineering/histogram table.png [ヒストグラムテーブル] ヒストグラムチャート
クリティカルパス分析
このツールは、プロジェクト内の相互依存タスクを認識するのに役立ちます。 また、プロジェクトを正常に完了するための最短パスまたはクリティカルパスを見つけるのにも役立ちます。 PERTダイアグラムのように、各イベントには特定の時間枠が割り当てられます。 このツールは、前のイベントが完了した場合にのみイベントが次に進むことができると仮定して、イベントの依存関係を示します。
イベントは、可能な限り早い開始時間に従って配置されます。 開始ノードと終了ノードの間のパスはクリティカルパスであり、これ以上減らすことはできず、すべてのイベントを同じ順序で実行する必要があります。
