マインドマップギャラリー システムインテグレーションプロジェクトマネジメントエンジニア 第3版ソフトテスト中間第14章 決算処理グループ
システムインテグレーションプロジェクトマネジメントエンジニア 第3版/ソフト試験中間/第14章 クロージングプロセスグループ、クロージングプロセスグループは、プロジェクトまたはフェーズを完了するために必要なすべてのプロセスグループのすべてのプロセスが完了していることを確認し、プロジェクトを正式に宣言するように設計されています。またはフェーズの終了。
2024-03-13 06:01:00 に編集されましたクロージングプロセスグループ
まとめ
終了プロセス グループには、プロジェクト、フェーズ、または契約を正式に完了または終了するために実行されるプロセスが含まれます。
プロセス グループを終了する目的は、プロジェクトまたはフェーズを完了するために必要なすべてのプロセス グループのすべてのプロセスが完了したことを確認し、プロジェクトまたはフェーズの終了を正式に宣言することです。
終了プロセス グループの主な役割は、フェーズ、プロジェクト、契約が適切に終了することを確認することです。
10種類の仕事をこなす
1. すべてのプロジェクト契約が適切に締結されており、未解決の問題がないことを確認します。
2. 主要な利害関係者からプロジェクトの成果物の最終的な承認を得て、プロジェクトの目標が達成されたことを確認する
3. プロジェクトの成果物をスポンサーや顧客などの指定された関係者に引き渡します。この作業は多くの場合、最終的な承認と同時に実行できます。
4. 最終的なプロジェクトパフォーマンスレポートを作成して配布します。このレポートは、関係者がプロジェクトの最終パフォーマンスを理解するのに役立つだけでなく、プロジェクト後の評価の重要な基礎としても機能します。
5. プロジェクト データを収集、整理、アーカイブし、組織のプロセス資産を更新します。これは、プロジェクトの記録を保持し、関連する法律や規制を遵守し、その後の監査(必要な場合)に備え、また将来の他のプロジェクトで参照できるようにするためです。
6. プロジェクトに関する主要な関係者からフィードバックを収集し、満足度を調査する
7. プログラムのコンプライアンスを評価し、組織の変革を達成し、ビジネス価値を創造します
8. プロジェクト後の包括的な評価を実施し、経験と学んだ教訓を要約し、組織のプロセス資産を更新します。
9. 知識の共有と知識の移転を実施し、プロジェクト成果のその後の運用をサポートし、商品価値を実現します
10. 財務的、法的、および管理上の終了を実施し、プロジェクトの正式な終了を宣言し、プロジェクトの成果物の管理と使用に対する責任をスポンサーや顧客などの指定された利害関係者に移管します。
1工程
プロジェクトまたはフェーズの終了
I. 意味
プロジェクト、フェーズ、または契約のすべてのアクティビティを終了するプロセス。
II. 効果
プロジェクトまたはフェーズの情報をアーカイブして、計画された作業を完了し、組織チームのリソースを新しい作業のために解放します。
III. このプロセスは 1 回だけ、またはプロジェクト内の事前定義された時点でのみ実行されます。
IV. プロジェクトを終了するとき、プロジェクト マネージャーはプロジェクト管理計画をレビューして、すべてのプロジェクト作業が完了し、プロジェクトの目標が達成されていることを確認する必要があります。
V. プロジェクトまたはフェーズを終了するために必要なアクティビティは次のとおりです。
1. フェーズまたはプロジェクトの完了または終了基準を達成するために必要なアクションとアクティビティ
(1) すべての文書と成果物が最新であり、すべての問題が解決されていることを確認します。
(2) 成果物が顧客に届けられ、顧客から正式な承諾を得たことを確認します。
(3) すべてのコストがプロジェクトコスト勘定科目に記録されていることを確認します。
(4) プロジェクトアカウントを閉じます。
(5) 人員を再配置する。
(6) 余分なプロジェクト資料を処分します。
(7) プロジェクトの施設、機器、その他のリソースを再割り当てします。
(8) 組織のポリシーに従って詳細なプロジェクトの最終レポートを作成します。
2. プロジェクト契約契約またはプロジェクト段階契約契約を締結するために必要な活動
(1) 売り手の仕事が正式に受け入れられたことを確認します。
(2) 係属中の請求の最終処分。
(3) 最終結果を反映するためにレコードを更新します。
(4) 将来の使用のために関連情報をアーカイブします。
3. 以下のタスクを完了するために必要なアクティビティ
(1) プロジェクトまたはフェーズの記録を収集する
(2) プロジェクトの成功または失敗を監査する
(3) 知識の共有と伝達を管理する
(4) 経験と教訓をまとめる
(5) 組織で将来使用できるようにプロジェクト情報をアーカイブします。
4. プロジェクトの製品、サービス、または結果を次の段階、または生産および/または運用に引き渡すために必要なアクションおよびアクティビティ。
5. 組織のポリシーと手順を改善または更新するための提案を収集し、適切な組織単位に転送します。
6. ステークホルダーの満足度などを測定します。
VI. プロジェクトが完了前に途中で終了した場合、プロジェクトまたはフェーズのプロセスを終了するには、途中で終了した理由を調査して文書化する手順も必要になります。上記を達成するには、プロジェクト マネージャーは、プロジェクトまたはフェーズの終了に適切な関係者全員を巻き込む必要があります。
VII. 伊藤
i. 入力
1. プロジェクト計画書
プロジェクトの成功基準、承認要件、プロジェクト終了時に誰が承認するかが文書化されます。
2. プロジェクト管理計画
プロジェクト管理計画のすべてのコンポーネントは、プロジェクトまたはフェーズを終了するプロセスへの入力となります。
3. プロジェクトファイル
(1) 仮説ログ
仕様、見積もり、スケジュール、リスクなどに関連するすべての仮定と制約を文書化します。
(2) 推定根拠
実際の結果に基づいて、期間、コストとリソースの見積もり、およびコスト管理を評価するために使用されます。
(3) 変更ログ
プロジェクト全体またはフェーズ全体におけるすべての変更リクエストのステータスが含まれます。
(4) 問題ログ
すべての問題が解決され、未解決の問題がないことを確認するために使用されます。
(5) 教訓登録
学んだ教訓ナレッジ ベースに含める前に、フェーズまたはプロジェクト中に学んだ教訓の概要を完成させます。
(6) マイルストーンリスト
プロジェクトのマイルストーンが完了する最終日付がリストされています。
(7) プロジェクトコミュニケーション記録
プロジェクト全体にわたるすべてのコミュニケーションが含まれます。
(8) 品質管理測定結果
品質管理活動の結果は、品質要件への準拠を示すために記録されます。
(9) 品質レポート
コンテンツには、チームによって管理されているすべての品質保証事項、または報告が必要な品質保証事項、改善の提案、品質管理プロセス中に発見された不適合またはその他の事項の説明が含まれる場合があります。
(10) 要件文書
プロジェクトの範囲への準拠を示すために使用されます。
(11) リスクレジスター
プロジェクト中に発生するリスクに関する情報が提供されます。
(12) リスクレポート
リスクステータスに関する情報が提供され、プロジェクト終了時に未解決のリスクがないことが確認されます。
(13) その他受領に必要な関連書類
成果物、プロジェクト管理文書、契約書、調達文書などが含まれます。
4. 受領のための成果物
受け入れのための成果物には、承認された製品仕様、納品受領書、および作業実績文書が含まれる場合があります。段階的に開始または早期にキャンセルされたプロジェクトの場合は、部分的に完了した、または中間の成果物も含まれる場合があります。
5. プロジェクト管理文書
(1) 実現可能性調査レポート: ビジネス ニーズとプロジェクトの基礎となる費用対効果分析を文書化します。
(2) プロジェクト評価レポート: プロジェクトの目標利益の概要を説明します。
(3) プロジェクト管理は、プロジェクトが経済的実現可能性調査の期待された結果を達成したかどうかを判断するために使用されます。
6. プロトコル
調達を正式に完了するための要件は通常、契約条件で定義され、調達管理計画に含まれます。複雑なプロジェクトでは、複数の契約を同時にまたは順番に管理する必要がある場合があります。
7. 調達書類
契約を締結するには、すべての調達文書を収集し、インデックスを作成し、アーカイブする必要があります。契約の進捗状況、範囲、品質、コストパフォーマンスに関する情報は、すべての契約変更文書、支払い記録、検査結果とともにカタログ化されます。プロジェクトの終了時には、「実際の」計画(図面)または「初期準備」の文書、マニュアル、トラブルシューティング文書、およびその他の技術文書は、調達文書の不可欠な部分とみなされます。この情報は、学んだ教訓を引き出し、将来の契約に向けて請負業者を評価するための基礎として使用することができます。
8. 組織プロセス資産
ii. ツールとテクニック
1. 専門家の判断
2. データ分析
(1) ファイル分析
(2) 回帰分析
(3) トレンド分析
(4) 偏差分析
3. ミーティング
iii. 出力
1. プロジェクトファイルの更新
教訓登録
2. 最終的な製品、サービス、または結果
プロジェクトによって提供される最終製品、サービス、または結果 (またはフェーズ終了の場合は、フェーズの中間製品、サービス、または結果) を顧客に引き渡す。
3. プロジェクト最終報告書
(1) プロジェクトまたはフェーズの概要。
(2) 範囲の目的、範囲の評価基準、および完了基準が満たされていることを示す証拠。
(3) 品質目標、プロジェクトと製品の品質の評価基準、関連する検証情報、実際のマイルストーンの納期と逸脱の理由。
(4) 許容可能なコスト範囲、実際のコスト、逸脱の理由などを含むコスト目標。
(5) 最終的な製品、サービス、または結果について確認された情報の概要。
(6) 結果がプロジェクトの予想される利益を達成するかどうかを含む、進捗計画の目標。プロジェクトの終了時に利益が達成されない場合は、利益実現の程度を示し、将来の実現を推定します。
(7) 最終的な製品、サービス、または結果がビジネス ニーズをどのように満たすかについての概要: プロジェクトの終了時にビジネス ニーズが満たされなかった場合、ニーズがどのように満たされるかの指示と、ビジネス ニーズがいつ満たされるかの推定満たした;
(8) プロジェクト中に発生したリスクや問題点とその解決策などの概要。
4. 組織プロセス資産の更新
クロージングプロセスグループの主なタスク
i. プロジェクトの承諾
プロジェクトの承認は、プロジェクトの終了管理の最初のステップです。プロジェクトの承認が完了して初めて、プロジェクトの概要、システムの保守、プロジェクト後の評価という次の段階に進むことができます。
プロジェクトの正式な承認には、プロジェクト製品、ドキュメント、および完成した成果物の承認が含まれます。
システムインテグレーションプロジェクトの受注は、前段階で締結した契約内容とそれに対応する技術作業内容に基づいて行う必要があり、プロジェクトの遂行中に契約内容が変更された場合には、変更後の内容も基礎とする必要があります。プロジェクトの承認のために。ソフトウェアベースのシステムインテグレーションプロジェクトの場合、通常、プロジェクトの初期段階での契約内容に加えて、当事者AとBの双方が署名または承認したソフトウェア要件書が承認の根拠として必要となります。ソフトウェア プロジェクトの受け入れテストを実行する場合、受け入れテスト ケースはソフトウェア要件仕様内のすべての機能要件と非機能要件をカバーする必要があります。
プロジェクトの受け入れ作業では、正式な受け入れ報告書を作成する必要があります。この報告書には、受け入れの主な内容とそれに対応する受け入れ結論が記載されており、受け入れ結論に署名して確認し、受け入れ結果に対して相応の責任を負う必要があります。
仕事内容としては、
1. 受け入れテスト
両当事者間の契約で合意されたシステム環境に基づいて、システムの機能および技術設計が構築者の機能的および非機能的要件を満たし、正常に動作できることを確認するための、情報システムの包括的なテストです。 。
含む
(1) 受け入れテスト ケースを作成する
(2) 受け入れテスト環境を確立する
(3) 包括的な受け入れテスト
(4) 受入テストレポートの発行
(5) 受け入れテスト報告書の署名
2. システム試運転
主にデータの移行、日常のメンテナンス、不具合の追跡と修復などが含まれます。
3. システムドキュメントの受け入れ
システムを最終的に納品する前に、システムのすべてのドキュメントが双方によって受け入れられ、承認される必要があります。
受け入れに関する文書には、マントラ: ジャガー曰く、誕生のために
(1) システムインテグレーションプロジェクトのご紹介
(2) システム統合プロジェクト最終報告書
(3) 情報システム取扱説明書
(4) 情報システム保守マニュアル
(5) ソフトウェアおよびハードウェア製品マニュアル、品質保証書
4. プロジェクトの最終検査
システムの試運転後の合意された時期に、両当事者はプロジェクトの最終的な受け入れを開始できます。通常、大規模プロジェクトは試行と最終承認の 2 つのステップに分かれます。
最終検査作業には以下が含まれます
(1) 双方による受け入れテスト文書の認識と受け入れ
(2) システムの試験運用中の労働条件についての双方の認識と受諾
(3) 双方によるシステム文書の認識と受諾
(4) 両当事者によるプロジェクト作業の完了の認識と受諾
ii. プロジェクトの引き継ぎ
1. ユーザーへの引き継ぎ
2. 運用チームとサポートチームへの引き継ぎ
3. プロセス資産を組織に移管する
(1) プロジェクトファイル
(2) プロジェクトまたはフェーズの終了文書
(3) 技術と経営資産
iii. プロジェクト概要
プロジェクト概要はプロジェクトクローズの管理クローズに属します。管理上の終了とも呼ばれ、プロジェクト チームのメンバーと関連する利害関係者が要求どおりにすべての職務を遂行したかどうかを確認することです。
管理終了プロセスの実施には、プロジェクト記録の収集、プロジェクトの成功と失敗の分析、学んだ教訓の収集、組織が将来使用できるようにプロジェクト情報をアーカイブするなどの活動が含まれます。
意味(目的) ヒント:間違った経典を暗記する
(1) プロジェクトプロセス全体の作業状況と、関連するチームまたはチームメンバーのパフォーマンスを把握する
(2) 問題点を把握し、改善策をまとめる
(3) プロジェクトのプロセス全体で学んだ教訓を理解し、要約する
(4) 要約された文書について議論し、承認後に企業の知識ベースに保管することで、企業のプロセス資産に組み込みます。
プロジェクト概要作成作業
(1) プロジェクトプロセスの文書と学んだ教訓を収集および整理する
そのためには、プロジェクト マネージャーが一人で作業するのではなく、プロジェクト スタッフ全体が協力して作業する必要があります。プロジェクト マネージャーは、プロジェクトに関与する人々やチームにとって必要なタスクとして、この作業をプロジェクトの終了作業に含めることができます。
(2) 教訓の収集とプロジェクト総括会議の議論メモの作成
この最初のディスカッション ドラフトでは、プロジェクト マネージャーが、プロジェクトの実行プロセス中に優れた点と重大な欠点をいくつか挙げて、ディスカッション中に強調表示できるようにする必要があります。
プロジェクト概要
プロジェクトの概要プロセスは、プロジェクトの初期の価値と目標達成の概要、および業務経験と学んだ教訓の概要と分析です。プロジェクト マネージャーは、プロジェクト メンバー全員の参加を組織して、正式なプロジェクトの概要を作成します。プロジェクト総括会議で作成された文書は全員が確認する必要があり、この原則に違反する文書はプロジェクト総括会議の結果として使用することはできません。プロジェクト概要会議では、プロジェクトの自己評価も行う必要があります。これにより、その後のプロジェクトの評価と監査作業が容易になります。
ディスカッションの内容 ヒント: 文学的な鶏と犬は都市に入りたがっています
(1) プロジェクトの目的
参加するプロジェクトメンバー全員の共通の成果として、プロジェクトの価値や目標の達成度、具体的なプロジェクト計画の達成率などを含む
(2) 技術的パフォーマンス
最終的な作業範囲とプロジェクトの初期段階での作業範囲を比較した結果はどうなっていますか? プロジェクトに関連する変更は合理的ですか?変更はプロジェクトの品質、スケジュール、コストに重大な影響を及ぼしますか? 各作業が期待される品質基準を満たしているか、また顧客満足度を満たしているか?
(3) コストパフォーマンス
事業範囲の変更による予算増加も含め、最終的な事業費と当初事業予算との間に大きな乖離があるかどうか、また、事業の収益性はどの程度なのか。これには、プロジェクト チーム メンバーのパフォーマンスとボーナスの分配が含まれます。
(4) スケジュールパフォーマンス
最終的なプロジェクトのスケジュールと当初のプロジェクトのスケジュールを比較した結果、スケジュールが進んでいる、または遅れているのはなぜですか?
(5) プロジェクトコミュニケーション
完全かつ効果的に活用されたコミュニケーションシステムが確立されているか、顧客がプロジェクトの意思決定と実行に関与しているか、顧客がプロジェクトの状況を定期的に確認する必要があるか、定期的なコミュニケーションや段階総括会議が開催されているか顧客とのコミュニケーション、タイムリーな通知が行われているかどうか、顧客の潜在的な問題、問題解決への顧客の参加の呼びかけなど、プロジェクトのコミュニケーション計画がどのように完了しているか、プロジェクトの内部会議記録が完全かどうかなど。
(6) 問題を特定して解決する
プロジェクトで発生した問題は解決できたのか、問題の原因は回避できるのか、管理や実行をどのように改善するかなど。
(7) 改善のためのコメントと提案
プロジェクトメンバーは、プロジェクト運営そのものやプロジェクトの実行計画について合理的な意見や提案を持っているか、それらの意見や提案は参加メンバーの過半数に認識されているか、今後のプロジェクトにおいて改善できるか。