マインドマップギャラリー 第19章 プロジェクトの終了管理
ソフトウェア試験に合格/システム インテグレーション プロジェクト マネジメント エンジニア/第 19 章プロジェクトの終了管理 (プロジェクトの受け入れを含む)、 プロジェクト概要、システムメンテナンス、 事後評価等
2024-02-24 02:28:16 に編集されましたプロジェクト終了管理
プロジェクトの承諾
プロジェクトの承認は、プロジェクトの終了管理の最初のステップです。プロジェクトの承認が完了した後でのみ、その後のプロジェクトの概要、システムの保守、プロジェクト後の評価の段階に入ることができます。 プロジェクトの正式な受諾には、プロジェクト製品、ドキュメント、完成した成果物の受領が含まれます。 システムインテグレーションプロジェクトの受注は、前段階で締結した契約内容とそれに対応する技術作業内容に基づいて行う必要があり、プロジェクトの遂行中に契約内容が変更された場合には、変更後の内容も基礎とする必要があります。プロジェクトの承認のために。ソフトウェアベースのシステムインテグレーションプロジェクトの場合、通常、プロジェクトの初期段階での契約内容に加えて、当事者AとBの双方が署名または承認したソフトウェア要件書が承認の根拠として必要となります。ソフトウェア プロジェクトの受け入れテストを実行する場合、受け入れテスト ケースはソフトウェア要件仕様内のすべての機能要件と非機能要件をカバーする必要があります。 プロジェクトの受け入れ作業では、主に受け入れの主な内容とそれに対応する受け入れ結論を含む正式な受け入れ報告書を作成する必要があります。受け入れに関与するすべての関係者は、受け入れ結論に署名して確認し、受け入れ結果に対して相応の責任を負う必要があります。
仕事内容
受け入れテスト
意味
両当事者間の契約で合意されたシステム環境に基づいて、システムの機能および技術設計が構築者の機能的および非機能的要件を満たし、正常に動作できることを確認するための、情報システムの包括的なテストです。 。
含む
受け入れテスト ケースを作成する
受け入れテスト環境を確立する
受け入れテストを完了する
受入テストレポートの発行
受け入れテスト報告書の署名
システム試運転
主にデータの移行、日常のメンテナンス、不具合の追跡と修復などが含まれます。
システムドキュメントの受け入れ
システムが受け入れテストに合格した後、システムのドキュメントを段階的かつ包括的に顧客に引き渡す必要があります。システムを最終的に納品する前に、システムのすべてのドキュメントが双方によって受け入れられ、承認される必要があります。
含む
システムインテグレーションプロジェクトのご紹介
システム統合プロジェクト最終報告書
情報システム取扱説明書
情報システム保守マニュアル
ソフトウェアおよびハードウェア製品マニュアル、品質保証書
プロジェクトの最終検査
システムの試運転後の合意された時期に、両当事者はプロジェクトの最終的な受け入れを開始できます。大規模プロジェクトは試運転と最終承認の2段階に分かれます。
含む
両当事者による受け入れテスト文書の認識と受諾、
双方によるシステムの試験運用中の労働条件の認識と受け入れ、
双方によるシステム文書の認識と受諾、
両当事者によるプロジェクト作業の完了の認識と受諾
プロジェクト概要
プロジェクト概要はプロジェクトクローズの管理クローズに属します。管理上のクロージングとも呼ばれ、プロジェクト チームのメンバーと関連する利害関係者が要求どおりにすべての職務を遂行したかどうかを確認することです。
プロジェクト記録の収集、プロジェクトの成功と失敗の分析、学んだ教訓の収集、組織が将来使用できるようにプロジェクト情報をアーカイブするなどの活動が含まれます。
意義
(1) プロジェクトプロセス全体の労働条件と関連チームまたはチームメンバーのパフォーマンスを理解する
(2) 問題点の把握と改善策のまとめ
(3) プロジェクトの全プロセスを通じて得られた学びに値する経験を理解し、まとめる
(4) 要約された文書を議論し、後処理を通じて企業のナレッジベースに保管し、企業のプロセス資産に組み込みます。
プロジェクト総括会議の準備作業
プロジェクトプロセスの文書と学んだ教訓を収集および整理する
これはプロジェクト マネージャーだけで行うのではなく、プロジェクト スタッフ全員が実行する必要があります。プロジェクト マネージャーは、プロジェクトに関与する人々やチームにとって必要なタスクとして、この作業をプロジェクトの終了作業に含めることができます。
教訓の収集とプロジェクト総括会議の議論メモの作成
この最初のディスカッション ドラフトでは、プロジェクト マネージャーが、プロジェクトの実行プロセス中に優れた点と重大な欠点をいくつか挙げて、ディスカッション中に強調表示できるようにする必要があります。
プロジェクト概要会議
プロジェクトに関与するメンバー全員が参加する必要があり、すべての議論は文書化する必要があります。プロジェクト総括会議で作成された文書は全員が確認する必要があり、この原則に違反する文書はプロジェクト総括会議の結果として使用することはできません。
ディスカッション内容
プロジェクトのパフォーマンス
参加するプロジェクトメンバー全員の共通の実績として、プロジェクトの完了、具体的なプロジェクト計画の完了率、プロジェクト目標の達成などを含みます。
技術的パフォーマンス
最終的な作業範囲とプロジェクトの初期段階での作業範囲を比較した結果はどうなっていますか? プロジェクトに関連する変更は合理的ですか?変更はプロジェクトの品質、スケジュール、コストに重大な影響を及ぼしますか? 各作業が期待される品質基準を満たしているか、また顧客満足度を満たしているか?
コストパフォーマンス
事業範囲の変更による予算増加も含め、最終的な事業費と当初事業予算との間に大きな乖離があるかどうか、また、事業の収益性はどの程度なのか。これには、プロジェクト チーム メンバーのパフォーマンスとボーナスの分配が含まれます。
スケジュールパフォーマンス
最終的なプロジェクトのスケジュールと当初のプロジェクトのスケジュールを比較した結果、スケジュールが進んでいる、または遅れているのはなぜですか?
プロジェクトコミュニケーション
完全かつ効果的に活用されたコミュニケーションシステムが確立されているか、顧客がプロジェクトの意思決定と実行に関与しているか、顧客がプロジェクトの状況を定期的に確認する必要があるか、定期的なコミュニケーションや段階総括会議が開催されているか顧客とのコミュニケーション、タイムリーな通知が行われているかどうか、顧客の潜在的な問題、問題解決への顧客の参加の呼びかけなど、プロジェクトのコミュニケーション計画がどのように完了しているか、プロジェクトの内部会議記録が完全かどうかなど。
問題を特定して解決する
プロジェクトで発生した問題は解決できたのか、問題の原因は回避できるのか、管理や実行をどのように改善するかなど。
ご意見・ご提案
プロジェクトメンバーは、プロジェクト運営そのものやプロジェクトの実行計画について合理的な意見や提案を持っているか、それらの意見や提案は参加メンバーの過半数に認識されているか、今後のプロジェクトにおいて改善できるか。
システム・メンテナンス
システム統合プロジェクトの受入作業が完了すると、情報システムは初期構築段階から運用・保守段階へと移行します。
ソフトウェアプロジェクトのフォローアップ作業
ソフトウェアのバグ修正
ソフトウェアにバグがないことは困難ですが、ほとんどのバグはテストと受け入れの段階で発見されており、これらのバグはシステムの引き渡し時に対処されています。双方が合意した方法で処理されます。
ソフトウェアの更新
ソフトウェア保守期間中、顧客とサービスプロバイダーは、顧客のビジネスニーズの特有の特性、ソフトウェアアップグレードの難易度、ソフトウェアアップグレードの費用と期限、およびソフトウェアアップグレードに関連して考えられる影響に基づいて総合的な評価を行う必要があります。をクリックしてから、アップグレードするかどうかを決定します。
フォローアップ技術サポート
ソフトウェア保守業務の主な内容は、ソフトウェアシステムに対する技術サポート業務です。技術サポート業務の内容は、ソフトウェア保守サービス契約に定める必要があります。
システム統合プロジェクトのフォローアップ業務
情報システム日常保守業務
システム インテグレーターは、プロジェクトの保守期間中にサードパーティのテクニカル サポートを継続的に確保する方法を検討する必要があります。
ハードウェア製品のアップデート
ハードウェアに必要なアップデートが行われた場合、顧客とサービスプロバイダーは共同でハードウェア製品のアップグレード計画を策定し、それを共同で実装できます。
情報システムの新たなニーズに応える
情報システム サービス プロバイダーにとって、保守フェーズにおける重要なタスクの 1 つは、情報システムに対する顧客の新しいニーズと提案を収集して特定することです。
プロジェクト後の評価
情報システム事後評価は、情報技術、市場分析、統計調査、統計分析、経済管理、プロセス管理、プロジェクト管理などの分野を含む包括的な管理分野です。
情報システムの客観的評価
情報システムの事後評価の焦点は、情報システムの成功を評価するための重要な基準であり、情報システムが計画の開始時に設定されたさまざまな目標を達成したかどうかを分析する必要があります。あらかじめ設定されたプロジェクトの目標の正確性、合理性、有効性を評価するとともに、情報システムプロジェクトの設立時に設定された目標がどの程度達成されているかを判断します。
情報システムプロセス評価
プロセスの分析とレビューの観点から、プロセスの遵守性と合理性を評価します。 情報システムのプロセス全体の管理が計画に従って実行されているかどうか、およびプロセス管理の重大な逸脱がタイムリーに対応および分析されているかどうかに焦点を当て、プロセス管理とプロセス品質のレベルで対応する評価を行います。
情報システムのライフサイクル特性に応じて、主に次のものが含まれます。
情報システム予備実証段階
情報システム入札段階
情報システムの開発・構築段階
情報システムの運用保守
情報システムのメリット評価
情報システムの事後評価の主な内容であり、情報システムの運用効果を評価し、情報システムの持続可能性評価の判断材料となります。
情報システム技術評価
情報システム技術評価の主な内容は、情報システムの技術的ルート選択が正しいか、互換性や拡張性が良好か、情報システムの機能目標の実現度、情報システムプロジェクトリソースの利用効果などです。 、情報システムにおける技術革新や新技術の応用など。
情報システムの経済効果評価
情報システムの経済便益評価では、主に経済分析が中心となります。稼働中の情報システムの場合、経済的メリットには、プロジェクトの財務分析と関連する経済分析が含まれます。稼働していない情報システムの場合、投資分析、コスト分析、および関連する経済分析が含まれます。
情報システム管理メリットの評価
情報システムは、従来の手作業によるビジネスを拡張・延長したものと言えます。情報システムを活用した経営管理は、従来の手作業に比べて、従来のビジネスモデルにはない多くのメリットがあります。
情報システムの社会的便益評価
社会経済発展の促進と人々の生活の改善における情報システムの積極的な役割を評価することに主に焦点を当てており、評価内容には主に情報システムの社会的利益と社会的影響が含まれます。
情報システム環境影響評価
一般に、情報システムが自然環境に与える影響はほとんど無視できます。一部の種類の情報システムは、間接的な手段を通じて環境に影響を与えます。
情報システムの持続可能性評価
情報システムの持続可能性評価では、主に情報システムの継続的な運用・発展の可能性を評価し、情報システムの設定された目標を継続的に達成できるか分析し、将来にわたって情報システムを継続的かつ安定的に更新できるかどうかを評価します。組織の範囲内で、将来的に同様の情報システムプロジェクトを同様の方法で実施できるかどうか。