ソフトウェアプロジェクト管理

ソフトウェア開発に従事するIT企業の仕事のパターンは2つの部分に分かれていることがわかります。

ソフトウェアの作成
ソフトウェアプロジェクト管理

プロジェクトは明確に定義されたタスクであり、目標を達成するために実行されるいくつかの操作のコレクションです（たとえば、ソフトウェアの開発と配信）。プロジェクトは次のように特徴付けることができます。

すべてのプロジェクトには、独自の明確な目標があります。
プロジェクトは日常的な活動や日常業務ではありません。
プロジェクトには開始時間と終了時間があります。
プロジェクトは、その目標が達成されたときに終了するため、組織の存続期間中の一時的なフェーズです。
プロジェクトには、時間、人的資源、資金、材料、知識バンクの面で十分なリソースが必要です。

ソフトウェアプロジェクト

ソフトウェアプロジェクトは、要件の収集からテストおよびメンテナンスまでのソフトウェア開発の完全な手順であり、実行方法に従って、目的のソフトウェア製品を実現するために指定された期間内に実行されます。

ソフトウェアプロジェクト管理の必要性

ソフトウェアは無形の製品と言われています。ソフトウェア開発は、世界のビジネスにおけるまったく新しい流れの一種であり、ソフトウェア製品の構築の経験はほとんどありません。ほとんどのソフトウェア製品は、クライアントの要件に合わせてカスタマイズされています。最も重要なのは、基盤となるテクノロジーが頻繁かつ急速に変化および進歩するため、ある製品の経験が他の製品に適用されない可能性があることです。このようなビジネスおよび環境の制約はすべて、ソフトウェア開発にリスクをもたらすため、ソフトウェアプロジェクトを効率的に管理することが不可欠です。

上の画像は、ソフトウェアプロジェクトの3つの制約を示しています。コストをクライアントの予算内に抑え、スケジュールどおりにプロジェクトを提供することは、ソフトウェア組織の重要な部分です。このトリプルコンストレイント三角形に影響を与える可能性のある、内部と外部の両方のいくつかの要因があります。3つの要因のいずれかが、他の2つの要因に深刻な影響を与える可能性があります。

したがって、ソフトウェアプロジェクト管理は、予算と時間の制約とともにユーザー要件を組み込むために不可欠です。

ソフトウェアプロジェクトマネージャー

ソフトウェアプロジェクトマネージャーは、ソフトウェアプロジェクトを実行する責任を負う人です。ソフトウェアプロジェクトマネージャーは、ソフトウェアが通過するSDLCのすべてのフェーズを完全に認識しています。プロジェクトマネージャーは、最終製品の生産に直接関与することは決してありませんが、生産に関連する活動を管理および管理します。

プロジェクトマネージャーは、開発プロセスを綿密に監視し、さまざまな計画を準備して実行し、必要かつ適切なリソースを手配し、コスト、予算、リソース、時間、品質、および顧客満足度の問題に対処するために、すべてのチームメンバー間のコミュニケーションを維持します。

プロジェクトマネージャーが負ういくつかの責任を見てみましょう-

管理人

プロジェクトリーダーとして行動する
ステークホルダーとの連絡
人的資源の管理
レポート階層の設定など。

プロジェクトの管理

プロジェクトスコープの定義と設定
プロジェクト管理活動の管理
進捗状況とパフォーマンスの監視
すべてのフェーズでのリスク分析
問題を回避または解決するために必要な措置を講じる
プロジェクトのスポークスパーソンとして行動する

ソフトウェア管理活動

ソフトウェアプロジェクト管理は、プロジェクトの計画、ソフトウェア製品の範囲の決定、さまざまな用語でのコストの見積もり、タスクとイベントのスケジューリング、およびリソース管理を含む多くのアクティビティで構成されます。プロジェクト管理活動には次のものが含まれます。

Project Planning
Scope Management
Project Estimation

プロジェクト計画

ソフトウェアプロジェクトの計画は、ソフトウェアの生産が実際に開始される前に実行されるタスクです。これはソフトウェアの作成のためにありますが、ソフトウェアの作成と方向性のある具体的な活動は含まれていません。むしろ、それはソフトウェアの生産を容易にする複数のプロセスのセットです。プロジェクトの計画には、次のものが含まれる場合があります。

スコープ管理

プロジェクトの範囲を定義します。これにはすべてのアクティビティが含まれ、成果物のソフトウェア製品を作成するためにプロセスを実行する必要があります。スコープ管理は、プロジェクトで何が行われ、何が行われないかを明確に定義することによってプロジェクトの境界を作成するため、不可欠です。これにより、プロジェクトに限定された定量化可能なタスクが含まれるようになり、簡単に文書化できるため、コストと時間の超過を回避できます。

プロジェクトスコープの管理中に、次のことが必要です。

スコープを定義する
その検証と制御を決定する
管理を容易にするために、プロジェクトをさまざまな小さな部分に分割します。
スコープを確認する
スコープへの変更を組み込むことによってスコープを制御します

プロジェクトの見積もり

効果的な管理のためには、さまざまな対策を正確に見積もる必要があります。正しい見積もりがあれば、マネージャーはプロジェクトをより効率的かつ効果的に管理および制御できます。

プロジェクトの見積もりには、以下が含まれる場合があります。

Software size estimation
ソフトウェアのサイズは、KLOC（Kilo Line of Code）の観点から、またはソフトウェアのファンクションポイントの数を計算することによって見積もることができます。コード行はコーディング慣行によって異なり、ファンクションポイントはユーザーまたはソフトウェア要件によって異なります。
Effort estimation
管理者は、ソフトウェアの作成に必要な人員要件と工数の観点から作業量を見積もります。労力の見積もりについては、ソフトウェアのサイズを知っておく必要があります。これは、マネージャーの経験から導き出すことができ、組織の履歴データまたはソフトウェアのサイズを、いくつかの標準的な公式を使用して取り組みに変換することができます。
Time estimation
サイズと労力を見積もると、ソフトウェアの作成に必要な時間を見積もることができます。必要な作業は、要件仕様およびソフトウェアのさまざまなコンポーネントの相互依存性に従って、サブカテゴリに分類されます。ソフトウェアタスクは、ワークブレークスルーストラクチャ（WBS）によって、より小さなタスク、アクティビティ、またはイベントに分割されます。タスクは、毎日または暦月にスケジュールされます。

すべてのタスクを数時間または数日で完了するために必要な時間の合計は、プロジェクトを完了するために費やされた合計時間です。
Cost estimation
これは、以前のどの要素よりも多くの要素に依存しているため、すべての中で最も難しいと見なされる可能性があります。プロジェクトの費用を見積もるには、以下を考慮する必要があります。

ソフトウェアのサイズ
ソフトウェアの品質
Hardware
追加のソフトウェアまたはツール、ライセンスなど。
タスク固有のスキルを持つ熟練した担当者
関係する旅行
Communication
トレーニングとサポート

プロジェクト推定手法

サイズ、労力、時間、コストなど、プロジェクトの見積もりに関連するさまざまなパラメータについて話し合いました。

プロジェクトマネージャーは、広く認識されている2つの手法を使用して、リストされた要因を見積もることができます。

分解技術

この手法は、ソフトウェアをさまざまな構成の製品として想定しています。

2つの主要なモデルがあります-

Line of Code 見積もりは、ソフトウェア製品のコード行数に代わって行われます。
Function Points 見積もりは、ソフトウェア製品のファンクションポイントの数に代わって行われます。

経験的推定手法

この手法では、経験的に導き出された式を使用して推定を行います。これらの式は、LOCまたはFPに基づいています。

Putnam Model
このモデルは、Nordenの度数分布（レイリー曲線）に基づいたLawrence H.Putnamによって作成されています。パトナムモデルは、ソフトウェアのサイズに必要な時間と労力をマッピングします。
COCOMO
COCOMOは、Barry W.Boehmによって開発されたCOnstructiveCOstMOdelの略です。ソフトウェア製品は、オーガニック、セミデタッチド、エンベデッドの3つのソフトウェアカテゴリに分類されます。

プロジェクトのスケジューリング

プロジェクトのプロジェクトスケジューリングとは、指定された順序で、各アクティビティに割り当てられた時間枠内で実行されるすべてのアクティビティのロードマップを指します。プロジェクトマネージャーは、さまざまなタスクを定義し、マイルストーンをプロジェクトして、さまざまな要素を念頭に置いてそれらを調整する傾向があります。彼らは、スケジュールのクリティカルパスにあるタスクを探します。これは、特定の方法で（タスクの相互依存性のために）、厳密に割り当てられた時間内に完了する必要があります。クリティカルパスから外れたタスクの配置は、プロジェクトのすべてのスケジュールに影響を与える可能性が低くなります。

プロジェクトをスケジュールするには、次のことが必要です-

プロジェクトタスクをより小さく、管理しやすい形式に分割します
さまざまなタスクを見つけて、それらを相互に関連付けます
各タスクに必要な時間枠を見積もる
時間を作業単位に分割する
各タスクに適切な数のワークユニットを割り当てます
プロジェクトの開始から終了までに必要な合計時間を計算します

資源管理

ソフトウェア製品の開発に使用されるすべての要素は、そのプロジェクトのリソースと見なすことができます。これには、人的資源、生産的なツール、およびソフトウェアライブラリが含まれる場合があります。

リソースは限られた量で利用可能であり、資産のプールとして組織にとどまります。リソースの不足はプロジェクトの開発を妨げ、スケジュールより遅れる可能性があります。追加のリソースを割り当てると、最終的に開発コストが増加します。したがって、プロジェクトに適切なリソースを見積もり、割り当てる必要があります。

リソース管理には以下が含まれます-

プロジェクトチームを作成し、各チームメンバーに責任を割り当てることにより、適切な組織プロジェクトを定義します。
特定の段階で必要なリソースとその可用性の決定
リソースが必要になったときにリソース要求を生成し、不要になったときに割り当てを解除することで、リソースを管理します。

プロジェクトリスク管理

リスク管理には、プロジェクトにおける予測可能なリスクと予測不可能なリスクの特定、分析、および準備に関連するすべての活動が含まれます。リスクには以下が含まれる場合があります。

経験豊富なスタッフがプロジェクトを去り、新しいスタッフが入ってきます。
組織管理の変更。
要件の変更または要件の誤解。
必要な時間とリソースの過小評価。
技術の変化、環境の変化、ビジネス競争。

リスク管理プロセス

リスク管理プロセスには、次のアクティビティが含まれます。

Identification - プロジェクトで発生する可能性のあるすべてのリスクをメモします。
Categorize - プロジェクトへの影響の可能性に応じて、既知のリスクを高、中、低のリスク強度に分類します。
Manage - さまざまな段階でリスクが発生する確率を分析します。リスクを回避または直面する計画を立てます。それらの副作用を最小限に抑えるようにしてください。
Monitor - 潜在的なリスクとその初期症状を注意深く監視します。また、それらを軽減または回避するために実行された手順の影響を監視します。

プロジェクトの実行と監視

このフェーズでは、プロジェクト計画に記載されているタスクがスケジュールに従って実行されます。

すべてが計画どおりに進んでいるかどうかを確認するために、実行を監視する必要があります。モニタリングとは、リスクの可能性を確認し、リスクに対処したり、さまざまなタスクのステータスを報告したりするための対策を講じることです。

これらの対策には以下が含まれます-

Activity Monitoring - 一部のタスク内でスケジュールされたすべてのアクティビティは、日常的に監視できます。タスク内のすべてのアクティビティが完了すると、完了したと見なされます。
Status Reports - レポートには、特定の時間枠（通常は1週間）内に完了したアクティビティとタスクのステータスが含まれます。ステータスは、完了、保留中、または進行中などとしてマークできます。
Milestones Checklist - すべてのプロジェクトは複数のフェーズに分割され、SDLCのフェーズに基づいて主要なタスクが実行されます（マイルストーン）。このマイルストーンチェックリストは、数週間に1回作成され、マイルストーンのステータスを報告します。

プロジェクトコミュニケーション管理

効果的なコミュニケーションは、プロジェクトの成功に不可欠な役割を果たします。これは、クライアントと組織の間、チームメンバー間、およびハードウェアサプライヤなどのプロジェクトの他の利害関係者の間のギャップを埋めます。

コミュニケーションは口頭または書面で行うことができます。通信管理プロセスには、次の手順があります。

Planning -このステップには、プロジェクトのすべての利害関係者の識別と、それらの間のコミュニケーションのモードが含まれます。また、追加の通信機能が必要かどうかも検討します。
Sharing -計画のさまざまな側面を決定した後、マネージャーは正しい情報を正しい人と正しい時間に共有することに焦点を合わせます。これにより、プロジェクトに関係するすべての人がプロジェクトの進捗状況とそのステータスを最新の状態に保つことができます。
Feedback -プロジェクトマネージャーは、さまざまな測定値とフィードバックメカニズムを使用して、ステータスとパフォーマンスのレポートを作成します。このメカニズムにより、さまざまな利害関係者からの入力がフィードバックとしてプロジェクトマネージャーに確実に届きます。
Closure -各主要イベントの終了時、SDLCのフェーズの終了時、またはプロジェクト自体の終了時に、電子メールの送信、ドキュメントのハードコピーの配布、またはその他の効果的なコミュニケーション手段によってすべての利害関係者を更新するための管理上の閉鎖が正式に発表されます。

閉鎖後、チームは次のフェーズまたはプロジェクトに進みます。

構成管理

構成管理は、製品の要件、設計、機能、および開発の観点から、ソフトウェアの変更を追跡および制御するプロセスです。

IEEEは、これを「システム内のアイテムを識別および定義し、ライフサイクル全体でこれらのアイテムの変更を制御し、アイテムのステータスと変更要求を記録および報告し、アイテムの完全性と正確性を検証するプロセス」と定義しています。

一般に、SRSが完成すると、ユーザーからの変更が必要になる可能性は低くなります。それらが発生した場合、コストと時間の超過の可能性があるため、変更は上級管理職の事前の承認がある場合にのみ対処されます。

ベースライン

SDLCのフェーズは、ベースライン化されている場合に想定されます。つまり、ベースラインはフェーズの完全性を定義する測定値です。フェーズは、それに関連するすべてのアクティビティが終了し、十分に文書化されたときにベースライン化されます。それが最終段階ではなかった場合、その出力は次の即時段階で使用されます。

構成管理は組織管理の分野であり、フェーズのベースライン化後に変更（プロセス、要件、技術、戦略など）の発生を処理します。CMは、ソフトウェアで行われた変更を常にチェックします。

変更管理

変更管理は構成管理の機能であり、ソフトウェアシステムに加えられたすべての変更に一貫性があり、組織の規則や規制に従って行われることを保証します。

製品の構成の変更は、次の手順で実行されます-

Identification-変更要求は、内部ソースまたは外部ソースから到着します。変更要求が正式に特定されると、適切に文書化されます。
Validation -変更要求の有効性がチェックされ、その処理手順が確認されます。
Analysis-変更要求の影響は、スケジュール、コスト、および必要な労力の観点から分析されます。システムに対する予想される変更の全体的な影響が分析されます。
Control-予想される変更がシステム内の非常に多くのエンティティに影響を与えるか、それが避けられない場合は、変更をシステムに組み込む前に、高官の承認を得る必要があります。変更を組み込む価値があるかどうかが決定されます。そうでない場合、変更要求は正式に拒否されます。
Execution -前のフェーズで変更要求を実行することを決定した場合、このフェーズは変更を実行するために適切なアクションを実行し、必要に応じて徹底的な改訂を行います。
Close request-変更は、正しく実装され、システムの他の部分とマージされているかどうかが検証されます。この新しく組み込まれたソフトウェアの変更は適切に文書化され、リクエストは正式にクローズされます。

プロジェクト管理ツール

プロジェクトが設定された方法論に従って開発された場合でも、リスクと不確実性はプロジェクトのサイズに関して何倍にも上昇します。

効果的なプロジェクト管理を支援するツールが利用可能です。いくつか説明されています-

ガントチャート

ガントチャートは、ヘンリーガント（1917）によって考案されました。これは、期間に関するプロジェクトのスケジュールを表します。これは、プロジェクト活動に予定されている活動と時間を表す棒グラフの横棒グラフです。

PERTチャート

PERT（Program Evaluation＆Review Technique）チャートは、プロジェクトをネットワーク図として表すツールです。プロジェクトの主要なイベントを並行して連続してグラフィカルに表現することができます。次々に発生するイベントは、前のイベントに対する後のイベントの依存関係を示しています。

イベントは番号付きノードとして表示されます。これらは、プロジェクト内の一連のタスクを表すラベル付きの矢印で接続されています。

リソースヒストグラム

これは、プロジェクトイベント（またはフェーズ）に時間の経過とともに必要なリソース（通常は熟練したスタッフ）の数を表す棒グラフまたはグラフを含むグラフィカルツールです。リソースヒストグラムは、スタッフの計画と調整に効果的なツールです。

クリティカルパス分析

このツールは、プロジェクト内の相互に依存するタスクを認識するのに役立ちます。また、プロジェクトを正常に完了するための最短パスまたはクリティカルパスを見つけるのにも役立ちます。PERT図と同様に、各イベントには特定の時間枠が割り当てられます。このツールは、前のイベントが完了した場合にのみイベントが次のイベントに進むことができると想定して、イベントの依存関係を示します。

イベントは、可能な限り早い開始時間に従って配置されます。開始ノードと終了ノードの間のパスはクリティカルパスであり、これ以上減らすことはできず、すべてのイベントを同じ順序で実行する必要があります。