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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ソフトウェアプロジェクト管理は、ソフトウェアプロジェクトを計画および主導する芸術と科学です。[1]これは、ソフトウェアプロジェクトが計画、実装、監視、および制御される プロジェクト管理のサブディシプリンです。

歴史

1970年代と1980年代に、コンピュータ会社がハードウェアの製造と回路に比べてソフトウェアの製造のコストが比較的低いことをすぐに認識したため、ソフトウェア業界は非常に急速に成長しました。新しい開発作業を管理するために、企業は確立されたプロジェクト管理方法を適用しましたが、特にユーザー仕様と提供されたソフトウェアの間のグレーゾーンで混乱が発生した場合、テスト実行中にプロジェクトスケジュール が遅れました。これらの問題を回避できるようにするために、ソフトウェアプロジェクト管理方法は、現在ウォーターフォールモデルとして知られている方法で、ユーザーの要件を提供された製品に一致させることに焦点を合わせました

業界が成熟するにつれて、ソフトウェアプロジェクト管理の失敗の分析により、次のことが最も一般的な原因であることが示されました。[2] [3] [4]

  1. 不十分なエンドユーザーの関与
  2. 顧客、開発者、ユーザー、プロジェクトマネージャー間のコミュニケーション不足
  3. 非現実的または明確でないプロジェクトの目標
  4. 必要なリソースの不正確な見積もり
  5. 正しく定義されていない、または不完全なシステム要件と仕様
  6. プロジェクトのステータスの報告が不十分
  7. 管理が不十分なリスク
  8. 未熟な技術の使用
  9. プロジェクトの複雑さを処理できない
  10. ずさんな開発慣行
  11. 利害関係者の政治(例:エグゼクティブサポートの欠如、または顧客とエンドユーザー間の政治)
  12. 商業的圧力

上記のリストの最初の5つの項目は、適切なリソースが適切なプロジェクト目標を達成できるように、クライアントのニーズを明確にすることの難しさを示しています。特定のソフトウェアプロジェクト管理ツールは便利で、多くの場合必要ですが、ソフトウェアプロジェクト管理の真の技術は、正しい方法を適用し、ツールを使用してその方法をサポートすることです。方法がなければ、ツールは無価値です。1960年代以降、いくつかの独自のソフトウェアプロジェクト管理方法がソフトウェアメーカーによって独自に開発されてきましたが、コンピュータコンサルティング会社も同様の方法をクライアント向けに開発してきました。今日、ソフトウェアプロジェクト管理方法はまだ進化していますが、現在の傾向は、ウォーターフォールモデルから、ソフトウェア開発プロセスを模倣するより循環的なプロジェクト提供モデルへと移行しています。

ソフトウェア開発プロセス

ソフトウェア開発プロセスは、ソフトウェアツールなどの技術的側面ではなく、主にソフトウェア開発の生産的側面に関係していますこれらのプロセスは、主にソフトウェア開発の管理をサポートするために存在し、一般的にビジネス上の懸念に対処することに偏っています。多くのソフトウェア開発プロセスは、一般的なプロジェクト管理プロセスと同様の方法で実行できます。例は次のとおりです。

  • 対人コミュニケーション紛争の管理と解決積極的で頻繁かつ誠実なコミュニケーションは、プロジェクトの成功の可能性を高め、問題のあるプロジェクトを軽減する上で最も重要な要素です。開発チームは、エンドユーザーの関与を求め、開発プロセスへのユーザーの意見を促す必要があります。ユーザーが関与していないと、要件の誤解、変化する顧客のニーズに対する鈍感さ、およびクライアント側の非現実的な期待につながる可能性があります。ソフトウェア開発者、ユーザー、プロジェクトマネージャー、顧客、およびプロジェクトスポンサーは、定期的かつ頻繁に連絡を取る必要があります。これらの議論から得られた情報により、プロジェクトチームは長所、短所、機会、脅威(SWOT)を分析し、その情報に基づいて行動し、機会から利益を得て、脅威を最小限に抑えます。悪いニュースでさえ、それが比較的早く伝えられれば良いかもしれません。なぜなら、問題が発見されるのが遅すぎなければ、問題を軽減できるからです。たとえば、ユーザー、チームメンバー、およびその他の利害関係者とのカジュアルな会話は、正式な会議よりも早く潜在的な問題を明らかにすることがよくあります。すべてのコミュニケーションは、知的に正直で本物である必要があり、穏やかで、敬意を持って、建設的に提供される限り、開発作業に対する定期的、頻繁、高品質の批判が必要です。、非告発的、非怒りのファッション。プロジェクトをエンドユーザーにとって関連性があり、有用で効果的なものに保ち、完了できる範囲内に収めるためには、開発者とエンドユーザーの間、およびプロジェクトマネージャーとクライアントの間で頻繁にカジュアルなコミュニケーションをとる必要があります。効果的な対人コミュニケーションと紛争管理および解決は、ソフトウェアプロジェクト管理の鍵です。コミュニケーションにおける深刻な問題や対人対立の管理ミスを克服できる方法論やプロセス改善戦略はありません。さらに、そのような方法論とプロセス改善戦略に関連する成果は、より良いコミュニケーションによって強化されます。コミュニケーションは、チームがプロジェクト憲章を理解しているかどうかに焦点を当てる必要がありますチームがその目標に向かって進歩しているかどうか。エンドユーザー、ソフトウェア開発者、およびプロジェクトマネージャーは、災害が発生する前に問題を特定するのに役立つ、基本的で簡単な質問を頻繁に行う必要があります。エンドユーザーの参加、効果的なコミュニケーション、チームワークは十分ではありませんが、良い結果を確実にするために必要であり、それらがないことはほぼ確実に悪い結果につながります。[3] [4] [5]
  • リスク管理は、リスクを測定または評価し、リスクを管理するための戦略を開発するプロセスです。一般に、採用される戦略には、リスクを別の当事者に移転すること、リスクを回避すること、リスクの悪影響を減らすこと、および特定のリスクの結果の一部またはすべてを受け入れることが含まれます。ソフトウェアプロジェクト管理のリスク管理は、プロジェクトを開始するためのビジネスケースから始まります。これには、費用対効果の分析と、緊急時対応計画と呼ばれるプロジェクト失敗のフォールバックオプションのリストが含まれます
    • リスク管理のサブセットは機会管理です。これは、潜在的なリスクの結果がマイナスではなくプラスの影響を与えることを除いて、同じことを意味します。理論的には同じように扱われますが、「リスク」というややネガティブな用語ではなく「オポチュニティ」という用語を使用すると、スピンオフプロジェクト、ウィンドフォールなど、プロジェクト内の特定のリスクレジスターのポジティブな結果にチームが集中できるようになります。 、および追加のリソースを解放します。
  • 要件管理は、要件を特定、引き出し、文書化、分析、追跡し、優先順位を付けて合意し、変更を管理して関連する利害関係者に伝達するプロセスです。新規または変更されたコンピュータシステム[1]要件分析を含む要件管理は、ソフトウェアエンジニアリングプロセスの重要な部分です。これにより、ビジネスアナリストまたはソフトウェア開発者がクライアントのニーズまたは要件を特定します。これらの要件を特定すると、ソリューションを設計できるようになります。
  • 変更管理は、スコープの変更(プロジェクト管理)を特定、文書化、分析、優先順位付け、および合意し、変更を管理して関連する利害関係者に伝達するプロセスです。変更レベルでの要件分析を含む、新規または変更されたスコープの変更影響分析は、ソフトウェアエンジニアリングプロセスの重要な部分です。これにより、ビジネスアナリストまたはソフトウェア開発者クライアントの変更されたニーズまたは要件を特定します。これらの要件を特定すると、ソリューションを再設計または変更できるようになります。理論的には、各変更はソフトウェアプロジェクトのタイムラインと予算に影響を与える可能性があるため、定義上、承認前にリスクと利益の分析を含める必要があります。
  • ソフトウェア構成管理は、スコープ自体を識別して文書化するプロセスです。スコープ自体は、進行中のソフトウェア製品であり、すべてのサブ製品と変更を含み、これらを関連する利害関係者に伝達できるようにします。一般に、採用されるプロセスには、バージョン管理命名規則(プログラミング)、およびソフトウェアアーカイブ契約が含まれます。
  • リリース管理は、ソフトウェアのリリースを特定、文書化、優先順位付け、合意し、リリーススケジュールを管理し、関連する利害関係者に連絡するプロセスです。ほとんどのソフトウェアプロジェクトは、ソフトウェアをリリースできる3つのソフトウェア環境にアクセスできます。開発、テスト、および本番。分散チームがユーザーにリリースする前に作業を統合する必要がある非常に大規模なプロジェクトでは、多くの場合、ユーザー受け入れテスト(UAT) にリリースする前に、単体テストシステムテスト、または統合テストと呼ばれるテスト環境が増えます。
    • 注目を集めているリリース管理のサブセットはデータ管理です。明らかに、ユーザーは自分が知っているデータに基づいてのみテストでき、「実際の」データは「本番」と呼ばれるソフトウェア環境にのみ存在します。したがって、プログラマーは自分の作業をテストするために、「ダミーデータ」または「データスタブ」を作成する必要があります。従来、この目的で古いバージョンの本番システムが使用されていましたが、企業がソフトウェア開発を外部の貢献者にますます依存するようになると、企業データが開発チームに公開されない場合があります。複雑な環境では、データセットが作成され、ソフトウェアリリーススケジュール全体と同様に、テストリリーススケジュールに従ってテスト環境間で移行される場合があります。
  • メンテナンスと更新は、要件と顧客のニーズが常に関与するプロセスです。彼らは間違いなくバグを見つけ、新しい機能を要求し、さまざまな機能やより多くの更新を要求するかもしれません。したがって、これらの要求はすべて、顧客の要件と満足度を確認して満たす必要があります。

プロジェクトの計画、実行、監視、および制御

プロジェクト計画の目的は、プロジェクトの範囲を特定し、関連する作業を見積もり、プロジェクトスケジュールを作成することです。プロジェクト計画は、開発するソフトウェアを定義する要件から始まります。次に、プロジェクト計画は、完了につながるタスクを説明するために作成されます。プロジェクトの実行は、プロジェクト計画で定義されたタスクを完了するプロセスです。

プロジェクトの監視と制御の目的は、プロジェクトの進捗状況についてチームと管理者を最新の状態に保つことです。プロジェクトが計画から逸脱した場合、プロジェクトマネージャーは問題を修正するためのアクションを実行できます。プロジェクトの監視と制御には、チームからステータスを収集するためのステータス会議が含まれます。変更が必要な場合は、変更管理を使用して製品を最新の状態に保ちます。

発行

コンピューティングでは、「問題」という用語は、システムの改善を達成するための作業単位です。[要出典] 問題は、バグ、要求された機能、タスク、不足しているドキュメントなどである可能性があります。

たとえば、OpenOffice.orgは、変更されたバージョンのBugzillaIssueZillaを呼び出していました。2010年9月の時点で、彼らは自分たちのシステムをIssueTrackerと呼んでいます。[更新が必要]

重大度

多くの場合、問題は重大度レベルの観点から分類されます。重大度の定義は企業によって異なりますが、最も一般的なものは次のとおりです。

高い
バグまたは問題はシステムの重要な部分に影響を及ぼし、通常の動作を再開するには修正する必要があります。
中くらい
バグまたは問題はシステムのマイナーな部分に影響しますが、その動作にはある程度の影響があります。この重大度レベルは、システムの非中央要件が影響を受ける場合に割り当てられます。
低/固定
バグまたは問題はシステムのマイナーな部分に影響を及ぼし、その動作にはほとんど影響を与えません。この重大度レベルは、システムの非中央要件(および重要度が低い)が影響を受ける場合に割り当てられます。
些細な(化粧品、美的)
システムは正常に動作しますが、外観が期待どおりではありません。例:色が間違っている、コンテンツ間の間隔が大きすぎる、または小さすぎる、フォントサイズが正しくない、タイプミスなど。これは最も重大度の低い問題です。

問題管理

多くのソフトウェア会社では、[どちらですか?]問題は、品質保証アナリストがシステムの正当性を検証するときに調査され、問題の解決を担当する開発者に割り当てられることがよくあります。これらは、ユーザー受け入れテスト(UAT)フェーズ 中にシステムユーザーが割り当てることもできます。

問題は、問題または欠陥追跡システムを使用して伝達されます。他のいくつかのケースでは、[必要な例]電子メールまたはインスタントメッセンジャーが使用されます。

哲学

プロジェクト管理のサブディシプリンとして、ソフトウェア開発の管理を製造の管理に類似していると考える人もいます。これは、管理スキルはあるがプログラミングスキルはない人が実行できます。John C. Reynoldsはこの見解に反論し、ソフトウェア開発は完全に設計作業であると主張し、プログラミングできないマネージャーと、書くことができない新聞編集長比較します[6]

参考文献

  1. ^ a b ステルマン、アンドリュー; グリーン、ジェニファー(2005)。応用ソフトウェアプロジェクト管理オライリーメディア。ISBN 978-0-596-00948-92015-02-09にオリジナルからアーカイブされました。
  2. ^ 「ソフトウェアが失敗する理由」 IEEEスペクトラム
  3. ^ a b オープンソースソフトウェアの作成:成功する無料ソフトウェアプロジェクト(電子書籍、無料でダウンロード可能)を実行する方法、Karl Fogel
  4. ^ a b RobertFreseおよびVickiSauter、「ソフトウェアプロジェクトの成功の可能性を高める」、IEEE Engineering Management Review Vol。42、No。4、2014年12月第4四半期
  5. ^ フィリップ・グリーンスパン、ジェシカ・リビングストンの創設者の仕事(2007)、 ISBN 1-59059-714-1 
  6. ^ John C. Reynolds、プログラミングおよびプログラミング言語の教育に関するいくつかの考え SIGPLAN Notices、第43巻、第11号、2008年11月、p.108:「プログラミング能力がなくてもソフトウェア生産を管理できると主張する人もいます。この信念はソフトウェアの生産は製造の一形態であるという誤った見方から生じますが、製造は同一のオブジェクトの繰り返しの構築であり、ソフトウェアの生産は固有のオブジェクトの構築であり、つまりプロセス全体が設計の形態であるため、より近いものになります。新聞の制作に[原文のまま] —プログラミングできないソフトウェアマネージャーは、書くことができない管理編集者に似ています。」
全般的

外部リンク

プロジェクトの失敗