マインドマップギャラリー ソフトウェア入学試験 - プロジェクト管理全般
高度なソフトウェア試験の情報システムプロジェクトマネージャー、プロジェクト管理全体のナレッジマップ。プロジェクト管理計画の策定、プロジェクト作業の指導と管理、プロジェクト作業の監視、全体的な変更管理の知識ポイントの概要の実装などの重要な内容が含まれます。
2023-02-16 14:21:06 に編集されましたソフトウェア入学試験 - プロジェクト管理全般
プロジェクト管理全体の概要
意味: 全体的なプロジェクト管理知識フィールドには、各プロジェクト管理プロセス グループ内のさまざまなプロセスとプロジェクト管理活動を特定、決定、結合、統合、調整するために必要なさまざまなプロセスと活動が含まれます。これは、全体的かつ包括的な管理です。
全体的なプロジェクト管理には何が含まれますか?
1. リソース割り当て計画を選択します
2. 競合する目標と取り組みのバランスを取る
3. さまざまな知識領域間の依存関係の共同プロジェクト管理
プロジェクト管理全体の主なプロセス
1. プロジェクト憲章を作成する
プロジェクトを正式に承認し、プロジェクトマネージャーを任命します
2. プロジェクト管理計画の作成
プロジェクト管理計画の作成
3. プロジェクト作業の指導と管理
プロジェクト作業を実行し、変更を実装する
4. プロジェクトの作業を監視する
プロジェクトの進捗状況を監視し、パフォーマンス目標を決定する
5. 全体的な変更管理の実装
変更を確認、承認、管理し、変更の結果を伝達する
6. プロジェクトまたはフェーズを終了する
プロジェクト活動を完了し、プロジェクトを正式に終了する
インテグレーターとしてのプロジェクトマネージャーが持つべき資質
1. プロジェクト関係者との積極的かつ包括的なコミュニケーションを通じて、プロジェクトに対するニーズを理解します。
2. 競合する利害関係者間のバランスを見つけます。
3. 真剣かつ丁寧な共同作業を通じて、さまざまなニーズのバランスをとり、統合を実現します。
インテグレーターは、プロジェクトマネージャーが果たす重要な役割の 1 つであり、コミュニケーションを通じて協力し、コラボレーションを通じて統合します。
プロジェクトマネジメント実施プロセス全体の重要な内容
プロジェクト計画書
プロジェクト憲章の作成
入力
1. プロジェクト作業明細書
意味
作業明細書は、プロジェクトによって提供される製品またはサービスについて書面で説明したものです。
作業明細書には以下の事項が記載されています
1. ビジネスニーズ
組織のビジネス ニーズは、トレーニングのニーズ、市場の需要、技術の進歩、法的要件、または政府の基準に基づいている場合があります。
2. 製品範囲の仕様
プロジェクトによって作成された製品またはサービスの要件と特性を文書化した文書です。
3. 戦略計画
すべてのプロジェクトは組織の戦略的目標をサポートする必要があります。
2. ビジネスケース
意味
プロジェクトが投資する価値があるかどうかを判断するために、ビジネスの観点から必要な情報を提供します。
ビジネス ケースでは、プロジェクトを正当化し、プロジェクトの境界を決定するために、ビジネス ニーズと費用対効果の分析が実行されます。
3. 同意
意味
この契約は、プロジェクト開始の当初の意図を定義します。
形状
1. 契約
2. メモを理解する
3. 同意
4. 意向表明書
5. 口頭による合意
6. 電子メールまたはその他の書面による契約
外部クライアントのプロジェクトに取り組む場合、契約は契約です。
4. 事業環境要因
1. 政府の基準
2. 業界の基準と規制
専門規定
品質基準
労働者保護規制
3. 組織文化と構造
4. 市況
5. 組織プロセス資産
1. 組織の標準プロセス
2. ポリシーとプロセスの定義
3. テンプレート[プロジェクト憲章テンプレートなど]
4. 歴史的情報と教訓の知識ベース
1. プロジェクトの記録と文書
2. プロジェクト終了の情報と書類を完成させる
3. 過去の事業採択決定結果及び過去の事業実績に関する情報
4. リスク管理活動において発生する情報
ツール技術
1. 専門家の判断
2. 誘導技術
出力
プロジェクト計画書
プロジェクト憲章を作成する重要性
1. プロジェクトが正式に承認され、プロジェクト マネージャーがプロジェクト活動で組織リソースを使用する権限が与えられます。
2. プロジェクト憲章の承認は、プロジェクトの正式な開始を意味します。
3. プロジェクトがプロジェクト外部の人々によって承認されている
1. イニシエーター
2. プロジェクト管理委員会 CCB
4. プロジェクト憲章には開始者が署名しています。これは、プロジェクトが承認されたことを意味します。
プロジェクト憲章の内容
1. プロジェクトの一般的な説明とプロジェクトの製品の説明
2. プロジェクトの目的またはプロジェクトを承認する理由
3. プロジェクトの全体的な要件
4. 測定可能なプロジェクト目標と関連する成功基準
5. プロジェクトの主なリスク
6. 全体的なマイルストーンの進捗計画
7.全体の予算
8. プロジェクトの承認要件、つまりプロジェクトの計画、実行、監視、終了プロセス中に誰が承認する必要があるか
9. プロジェクトマネージャーとその責任と権限を任命する
10. プロジェクト憲章を承認したスポンサーまたはその他の者の名前と権限
プロジェクト憲章の役割
1. プロジェクトマネージャーを決定し、プロジェクトマネージャーの権限を規定します。
2. プロジェクトの存在を正式に確認し、プロジェクトに法的地位を与えます。
3. 範囲、時間、コスト、品質など、プロジェクトの全体的な目標を指定します。
4. プロジェクトを立ち上げる理由を説明することで、プロジェクトを実行組織の日常業務や戦略計画と結び付けます。
プロジェクト管理計画を立てる上で重要な要素
プロジェクト管理計画を作成する
入力
1. プロジェクト憲章
2. 他のプロセスの出力
3. 事業環境要因
4. 組織プロセス資産
ツール技術
1. 専門家の判断
2. 誘導技術
出力
1. プロジェクト管理計画
3 つの主要なベンチマーク
1. スコープのベンチマーク
2. 進捗状況のベンチマーク
3. 原価ベース
プロジェクト作業を指示および管理する
プロジェクトの実行を指示および管理する
入力
1. プロジェクト管理計画
2. 承認された変更リクエスト
3. 事業環境要因
4. 組織プロセス資産
ツール技術
1. 専門家の判断
2. プロジェクト管理情報システム
3. 打ち合わせ
出力
1. 成果物
定義: プロジェクトを完了するために生成および提供する必要がある、プロジェクト管理計画文書に文書化された固有で検証可能な製品、結果、またはサービス機能。
成果物のタイムライン
1. 成果物
プロジェクトの実行を指示および管理する
2. 検証された成果物
品質管理
3. 受け入れ可能な成果物
範囲の確認
4. 最終製品、サービスまたは結果の引き渡し
プロジェクトまたはフェーズの終了
2. 作業実績データ
3. 変更リクエスト
4. プロジェクト管理計画の更新
5. プロジェクトファイルの更新
キックオフミーティング
キックオフミーティング
招集時間
プロジェクト管理計画が完了した後、それが実施される前。
会議の目的
1. プロジェクト チームのメンバーはお互いを知っています。
2. プロジェクトの背景と計画を紹介し、包括的なプロジェクト管理計画を正式に承認し、関係者間の合意に達します。
3. 具体的なプロジェクト作業を実施し、個人およびチームの責任範囲を明確にし、チームメンバーからのコミットメントを得て、プロジェクトの実行段階に入る準備をします。
4. 行われたこと
1. プロジェクトの組織構造は通常、決定されています。
2. チームメンバーの役割と責任が定義されています。
キックオフミーティング前に完了してください。
5. 既存のファイル
1. 現時点では、プロジェクトを導くためのプロジェクト管理計画が作成されています。
2. キックオフミーティングでは、通常、プロジェクトの範囲、スケジュール、コスト、リスク対応等を確認し、関係者間の合意形成を図る必要があります。
プロジェクト管理情報システム [PMIS]
定義: コンピューター技術に基づいたプロジェクト管理システムです。
システム構成
1. 企画体制
2. 制御システム
サブシステム
1. 構成管理システム
定義: このシステムには、変更提案の提出、変更提案のレビューおよび承認システムの追跡、変更の承認レベルの決定、および承認された変更方法の確認のプロセスが含まれます。
構成管理ソフトウェアツール
1.CVS
2.VSS
3.クリアケース
2. 変更管理システム
プロジェクトの成果物と文書の管理、変更、承認を決定するために使用される手段と方法。
ミーティング
出席者には、プロジェクト マネージャー、プロジェクト チームのメンバー、議論されている問題に関連するか影響を受ける関係者が含まれます。
効果的な参加を確保するには、各参加者の役割を明確に定義する必要があります。
会議は次のように分けられます
1. 情報交換
2. ブレーンストーミング、プログラム評価、またはプログラム設計。
3. 決定を下します。
プロジェクトの作業を監視する
プロジェクトの作業を監視する
入力
1. プロジェクト管理計画
2. 進捗予想
進捗予測は、実際の進捗と進捗ベースライン、つまり完了までの推定時間[ETC]との比較に基づいて計算されます。進捗偏差[SV]と進捗パフォーマンス指標[SPI]を使用して予測することもできます。 。
3. コスト予測
コストベースラインと実際の進捗状況の比較に基づいて計算される完成度を見積もる必要があります [ETC] コスト偏差 [CV] およびコストパフォーマンス指標 [CPI] もコスト予測に使用できます。
4. 確認された変更点
5. 勤務実績情報
6. 事業環境要因
7. 組織プロセス資産
ツール技術
1. 専門家の判断
2. 解析技術
定義: プロジェクトまたは環境変数の起こり得る変化、およびそれらの他の変数との関係に基づいて、潜在的な結果を予測するために使用される分析手法。
1. 回帰分析
2. グループ化方法
3. 原因に基づく分析【RCA】
1. 特性要因図
2. ブレーンストーミング
3. 原因と結果の分析[特性要因図]
これは、問題の根本原因を徐々に特定し、理解するために使用される構造化された問題解決方法です。
4. 予測方法
1. シナリオ分析
2. シミュレーション[モンテカルロ解析]
5. 故障モードと影響解析 [FMEA]
これは、コンセプトや設計の初期段階にある人々が、製品やプロセスの起こり得る障害シナリオと、そのような障害が発生した場合の影響を特定するのに役立つ一連のプロセスとツールです。
6. 傾向分析手法
1. トレンド平均法
2. 指数平滑法
3. 直線トレンド法
4. 非線形トレンド法
傾向予測とも呼ばれ、プロジェクトのパフォーマンスの時間の経過に伴う変化を検出し、パフォーマンスが向上しているか低下しているかを判断するために使用されます。主な利点は、時系列の傾向が考慮されることです。
3. プロジェクト管理情報システム
4. 打ち合わせ
出力
1. 変更リクエスト
2. 業務実績報告書
3. プロジェクト管理計画の更新
4. プロジェクトファイルの更新
データケーブル
仕事のパフォーマンスデータ
で生産された
プロジェクトの作業プロセスを指示および管理する
生成時間
いつでも
主目的
プロジェクトの実行状況を記録します。
質問に答える
それは何ですか。
ユーザー
プロジェクトチーム
例
今月末までに10万件分の作業が完了しました。
仕事のパフォーマンス情報
で生産された
範囲の確認、管理範囲、管理進捗状況、コスト管理、品質管理、コミュニケーションの監督、リソースの管理、リスクの管理、調達の管理、ステークホルダーの参加プロセスの監督。
生成時間
一定の間隔で、頻繁に
主目的
プロジェクトの実行と計画の間の逸脱を反映して、変更が必要かどうかを判断します
質問に答える
なぜそうなるのか
ユーザー
プロジェクトチーム
例
今月末現在、計画と比べて進捗は計画より10万元遅れており、主に職員の技能レベルが低いことが原因で管理基準を超えている。
仕事のパフォーマンスレポート
で生産された
プロジェクトの作業プロセスを監視する
生成時間
より長い間隔で、定期的に、または必要に応じて
主目的
プロジェクト全体レベルでの計画と実行のより詳細または包括的な比較を行い、変更やその他のアクションが必要かどうかを判断します。
質問に答える
問題の解決方法と予防方法を準備する
ユーザー
プロジェクト チーム、スポンサー、上級管理職、顧客、その他の主要な関係者
例
今月末現在、進捗偏差は-100,000となっており、管理限界値を超えており、進捗に追いつき、再び遅れをとらないように人材育成を強化し、スキルレベルを向上させる必要がある。
総合的な変更管理を実装する
変更要求
1. 是正措置
2. 予防措置
3. 不具合の改善
4.アップデート
承認された変更リクエスト
承認された変更リクエストとは、変更管理委員会 [CCB] によって検討および承認されたものです。
承認された変更アクティビティの実装には以下が含まれます。
1. 是正措置
2. 予防措置
3. 不具合の改善
確認された変更点
承認された変更は、全体的な変更管理プロセスの実装の結果です。それらが正しく実装されていることを確認するには、実装を確認する必要があります。確認された変更には、変更が正しく実装されたことを示すデータが必要です。
プロジェクト変更管理委員会 [CCB]
プロジェクト変更管理委員会 [CCB] の責任
1. これは意思決定機関であり、運営機関ではありません。
2. CCB の仕事は、レビュー手法を通じてプロジェクトを変更するかどうかを決定することであり、変更計画を提案するものではありません。
プロジェクトマネージャーの責任
1. 変更提案者の要求に応じる
2. プロジェクトおよび対応計画に対する変更の影響を評価する
3. 技術要件を承認者が決定するためのリソース要件に変換する
4. レビュー結果に基づいてプロジェクト ベンチマークを実装および調整し、プロジェクト ベンチマークがプロジェクトの実施状況を反映していることを確認します。
全体的な変更を実装するための重要な知識ポイント
1. プロジェクト全体を通じて全体的な変更管理プロセスを実装し、プロジェクトのすべての段階に適用します。プロジェクトマネージャーはこれに対する最終的な責任を負います。
2. プロジェクトの関係者は誰でも変更リクエストを送信できます。口頭で行うこともできますが、すべての変更要求は書面で文書化し、変更管理および構成管理システムに組み込む必要があります。
3. 文書化された各変更要求は、責任者 (通常はプロジェクト マネージャーまたはプロジェクト スポンサー) によって承認または拒否されなければなりません。
4. 特定の特定の変更リクエストは、CCB の承認後、既に CCB のメンバーでない限り、顧客またはスポンサーによる承認も必要になる場合があります。
5. 変更管理委員会は、プロジェクトの主要な利害関係者の代表で構成されるグループです。プロジェクト マネージャーはメンバーの 1 人になることができますが、通常はチーム リーダーではありません。
6. 構成管理は、成果物と各プロセスの技術仕様との一致に焦点を当てますが、変更管理は、プロジェクト文書、成果物、またはベースラインに対する変更の特定、記録、承認、または拒否に焦点を当てます。
7. 全体的な変更管理の実装中の構成管理アクティビティの一部は次のとおりです。
1. 構成の識別
2. 構成ステータスの記録
3. 構成の検証と監査
変更管理管理のフローチャート
変更ログ
1. プロジェクト中に発生した変更を記録する
2. これらの変更は関連する利害関係者に伝えられ、プロジェクトの時間、コスト、リスクへの影響が評価される必要があります。
3. 未承認の変更リクエストも変更ログに記録する必要があります。
プロジェクトまたはフェーズの終了
プロジェクトの終了
1. 事務処理の終了
主な仕事
1. 製品の検証
2. 決算
3. プロジェクト記録を更新する
4. 経験と教訓を要約し、プロジェクト後評価を実施する
5. 組織プロセス資産を更新する
6. プロジェクトに関するプロジェクト関係者間の関係を終了し、プロジェクトチームを解散します。
行政の締めくくりの結果
1. プロジェクト製品の正式受注
2. プロジェクトファイルを完成させる
3. 組織プロセス資産の更新
4. リソースの解放
管理終了
2. 契約締結
これは、契約作業の終了、調達監査の実施、当事者間の契約関係の終了、関連情報の収集と提出を指します。
3. 共通性
1. それらはすべてプロジェクトクロージングプロセスグループの作業です
2. 全員が学んだ教訓を要約して記録し、組織プロセス資産を更新する必要があります。
4.連絡先
1. プロジェクト全体については、最初に契約を完了する必要があり、プロジェクト終了時の管理上の完了を実行する前に、各契約を完了する必要があります。
2. すべての契約締結を完了することは、プロジェクト全体の管理クロージングを実行するために必要な条件の 1 つです。
5. 違い
1. 事務処理はプロジェクト段階およびプロジェクト全体を対象とします。管理上の閉鎖は、各フェーズおよびプロジェクト全体の終了時に実行されます。契約の締結 契約の場合、契約の終了時に契約の締結を行う必要があります。
2. 管理上の終了とは、プロジェクトまたはフェーズのプロセスを終了する作業です。契約締結は、調達プロセスを締結する作業です。
3. プロジェクト全体の観点からは、契約の締結が最初に行われ、管理の完了は最後に行われます。
4. 管理上の終了は内部的なものであり、プロジェクト フェーズまたはプロジェクト全体が終了したことを示す書面による証明書をプロジェクト マネージャーに発行します。契約の締結は対外的なものであり、買い手が売り手に契約全体が締結されたことを示す書面による証明書を発行することになります。
6. 定義
契約締結
契約終了、決済、外部顧客への引き渡しなどの手続き。契約の早期終了は、契約終了の特殊なケースです。
管理上の終了
内部プロジェクトの終了手順。
7. 発生時期
契約締結
契約終了時に
管理上の終了
各プロジェクトまたはフェーズの終了時
8. 体験のまとめ
契約締結
調達監査
管理上の終了
経験と教訓のまとめ
9. 承認者
契約締結
不動産購入の購買管理者は売主に書面による確認書を発行します。
管理上の終了
スポンサーまたは経営陣がプロジェクトマネージャーに発行した書面による確認書
10. 引継ぎ対象
契約締結
外部顧客との引き継ぎ
管理上の終了
社内引き継ぎ
11. シーケンス
最初に社外顧客との引き継ぎを行い、次に社内で引き継ぎを行います。したがって、契約のクローズが最初に行われ、次に管理上のクローズが行われます。
12. 製品の検証
製品検証が成果物の完全性の受け入れとして定義されている場合、両方に製品検証が必要です。
どちらかを選択しなければならない場合は、契約終了を選択することをお勧めします
受領のための成果物
受け入れのための成果物には、承認された製品仕様、納品受領書、および作業実績文書が含まれる場合があります。
段階的に進行したプロジェクトまたはキャンセルされたプロジェクトには、未完了または中間の成果物が含まれる場合があります。
最終製品、サービス、または出力の引き渡し