マインドマップギャラリー IT 業界で優れたプロジェクト マネージャーになる方法 プロジェクト構成管理
プロジェクト構成管理は、プロジェクト環境管理やドキュメント ライブラリ管理とも呼ばれます。ファーウェイでは、環境は開発環境、テスト環境、本番環境、標準製品ライブラリ環境に分かれています。現在、DingTalk IT プロジェクト管理ドキュメント テンプレートやプロセス ツール、Feishu OKR プロジェクト管理、ソフトウェア ツールによるチーム管理など、非常に優れたツールがあり、目標、タスク、コードの結果、パフォーマンス、コミュニケーションなどを適切に管理できます。コーディネートされた。
2021-02-01 19:40:51 に編集されました優れたプロジェクトマネージャーになるにはどうすればよいでしょうか? 07 プロジェクトドキュメントライブラリ管理
1. ドキュメントと構成管理の知識ポイント
1. 書類の分類
2. 文書および構成管理に関する用語
設定項目
ベースライン
ステータスレポートを構成する
CCB: コントロールボード構成の変更 コントロールボード
3. 構成ライブラリの定義と分類
4. 制御プロセスを変更します。
5. 構成監査と構成監査の定義と機能、および構成監査の分類
2. 書類の分類
1. 情報システム関連書類
データ媒体とそこに記録されたデータ。
永続的で人間または機械が読み取り可能で、人間が読み取り可能なものを記述するために使用されます。
ソフトウェア エンジニアリングでは、ドキュメントは、アクティビティ、要件、プロセス、または結果を説明、定義、指定、報告、または認証する書面またはグラフィック情報を記述するためによく使用されます。
2.「コンピュータソフトウェア製品開発ドキュメントガイド」
ソフトウェアプロジェクトドキュメントの具体的な分類
重要な側面と品質要件
非公式文書
正式な文書
プロジェクトサイクル
開発ドキュメント
製品ドキュメント
文書の管理
詳細分類:14種類の文書
実現可能性調査報告書
プロジェクト開発計画
ソフトウェア要件仕様
データ要件に関する声明
概略設計仕様書
詳細な設計手順
データベース設計手順
ラピッドプロトタイピング手法: 製品プロトタイプとドキュメントに集約
ユーザーマニュアル
取扱説明書
モジュール開発関係書類
テスト計画
テスト分析レポート
開発進捗月報
プロジェクト開発概要レポート
3. 文書および構成管理関連の用語
1. 構成管理は一連のメソッドです
2. 管理対象
ソフトウェア開発中に生成される資産
コード
書類
データなど
3. 変更を合理的、秩序正しく、完全で履歴を追跡できるようにするために、適切なメカニズムを通じて変更を保存および変更し、記録し、変更を制御します。
4. 設定項目
一連の機能情報を使用する
名前、説明、リソースのセット、実装
6種類
1. 環境カテゴリー
ソフトウェア開発・運用保守環境
例: コンパイラ、オペレーティング システム、編集ソフトウェア、管理システム、開発ツール、 テストツール、プロジェクト管理ツール、ドキュメントツールなど
2. クラスを定義する
要件分析とシステム定義フェーズの後に得られた結果
例: 要件仕様、プロジェクト開発計画、設計標準または設計ルール、受け入れテスト計画など。
3.デザイン部門
設計段階で得られた結果
例: システム設計指示、プログラム仕様、データベース設計、コーディング標準、ユーザー インターフェイス設計、テスト標準、システム テスト計画、ユーザー マニュアル。
4. コーディングカテゴリー
コーディングと単体テスト後に得られた結果
例: ソース コード、ターゲット コード、単体テスト ケース、データ、テスト結果。
5.試験区分
システムテスト完了後の作業、システムテストケース、テスト結果、運用マニュアル、導入マニュアル。
6. メンテナンスカテゴリー
メンテナンス段階の製品作業、変更が必要な上記のソフトウェア構成項目。
5. ベースライン
ベースライン: ソフトウェア ライフ サイクルの各開発フェーズの終了時の特定の時点。マイルストーンとも呼ばれます。
マイルストーンでは、フェーズ作業が終了し、正式なフェーズ製品が形成されているため、元々継続していた開発作業がこれらの時点で分割され、フェーズ作業の結果のテストと確認がより容易になり、また、変更管理。
ベースライン規定では、別の開発段階の作業結果を変更するためにマイルストーンを越えることは禁止されており、設定されたマイルストーンの完了段階の結果の一部は凍結されていると考えられます。
6. ステータスレポートの構成
構成ステータスの説明とレポート
タスク: レポート管理構成に必要な情報を効果的に記録する。その目的は、構成項目の現在の状況をタイムリーかつ正確に関係者が理解できるように提供し、構成管理作業を強化することです。
7. 構成のレビュー
タスク: 構成アイテムと構成フラグの整合性を検証します。
ソフトウェア開発の実践では、変更管理とバージョン管理を実現するために構成項目にマークが付けられていることがわかります。チェックや検証が行われていない場合、依然として混乱が生じる可能性があります。
8. 設定フラグ
構成アイテムに名前を付ける方法と、構成アイテムを説明するためにどのような情報を使用するかを決定します。
9. 変更管理委員会
構成品目の変更を監視する組織。
タスク: 構成アイテムに対する提案された変更を評価および承認し、承認された変更の実装を監督します。
メンバー:
プロジェクトマネージャー
ユーザー代表
ソフトウェア品質コントローラー
コントローラーを設定します。
常設の機関である必要はなく、プロジェクト作業のニーズに応じて設立できます。
2017年から2020年の構成
プロジェクトマネージャー
ユーザー代表
プロダクトマネージャー
プロダクトディレクター
研究開発ディレクター
品質センターディレクター
テストマネージャー
製品の焦点: 製品バージョンと開発計画。
10. 設定項目
設定項目
構成管理により制御・管理される基本ユニット
構成ID
ソフトウェアのライフサイクルでは、さまざまな種類の構成アイテムを分類および選択し、構成アイテムの種類を定義し、それらに識別子を割り当てるプロセスです。
重要な内容
構成アイテムを識別して名前を付けます。
構成ID
構成管理の基本的な作業と、構成アイテム管理を管理するための前提条件。
構成フラグ
構成アイテムを形成するためにどのようなコンテンツを構成管理に入力するかを決定し、構成アイテムに名前を付ける方法と、構成アイテムを説明するためにどのような情報を使用するかを決定します。
構成管理システムを確立する手順
1. バージョン管理
バージョンフラグ
バージョンの区別、科学的な命名
数字、年の四半期、年と月の名前、花など。
2. ステータスレポートを構成する
構成ステータスの説明とレポート
タスク: 構成の管理に必要な情報を効果的に記録および報告します。
目的: 関係者が構成管理を理解し、強化できるように、構成アイテムの現在のステータスをタイムリーかつ正確に提供します。
3. 構成のレビュー
タスク: 構成アイテムと構成フラグの整合性を検証します。
目標: ソフトウェア構成管理の有効性を確保するために、構成管理の最も基本的な要件が実装され、混乱が許されません。
4. 構成ライブラリ
構成項目ライブラリ、構成管理のための強力なツール
ギット
SVN。
ソフトウェア エンジニアリングでは、主に次の 3 種類の構成ライブラリがあります。
1. 開発ライブラリ
開発プロセス中に保持する必要があるさまざまな情報を、開発者専用に保管します。
ライブラリを開発するユーザーが必要であると考える限り、ライブラリの変更が頻繁に行われる可能性があります。これ以上の制限は必要ありません。プロジェクトの他の部分に影響を与えないことが前提となります。
2. 管理ライブラリ
ソフトウェア開発の特定の段階が完了すると、作業成果物または関連情報が保存されます。
保存される情報には、コンピューターが読み取り可能なドキュメントと人間が読み取り可能なドキュメントが含まれます。
ライブラリ内の情報の読み取り、書き込み、または変更を制御します。
3. 製品ライブラリ
開発されたソフトウェア製品はシステムテストが完了すると、最終製品として倉庫に保管され、ユーザーへの納品や現場での設置を待ちます。図書館内の情報は管理されるべきです。
述べる:
開発環境
テスト環境
本番環境または本番環境
標準製品ライブラリ
プロジェクト製品ライブラリ
設定項目変更フローチャート
設定OK
ソフトウェア構成項目
構成制御
変化
構成監査
欠陥
現状報告
ステータスレポートオンラインデータベースの構成
ステータスレポートを構成する
原則として、管理対象の構成項目は変更できませんが、さまざまな理由で変更が必要な場合は、変更リクエストを送信できます。
変更リクエストが共同レビューと責任リーダーによって承認された後、変更が完了してレビューされた後、変更が正しいことを確認してから再実行できます。ライブラリに入力され、制御された状態に復元されます。
5. 構成のレビュー
1. 機能構成の見直し
構成アイテムの開発が正常に完了したかどうか。
構成項目が規定の性能・機能に達しているか
設定項目の運用およびサポート文書が完成し、要件を満たしているか。
正式なテスト文書をレビューし、テストデータに基づいて検証および検証レポートをレビューし、すべての承認された変更をレビューし、変更されたドキュメントをレビューし、設計レビューレポートをスポットチェックして、すべてのテストが機能に基づいて実行されたことを確認します。およびパフォーマンス要件。
2. 物理構成の検討
構築された各構成アイテムが対応する技術文書に準拠しているかどうか。
構成アイテムが構成ステータスレポートの情報に対応しているかどうか
システムの仕様が完全であるかどうかを確認します。
アーキテクチャ設計と詳細設計コンポーネントを比較して一貫性を確保します。
モジュールリストを確認して、承認されたコーディング標準への準拠を確認します。
マニュアル (ユーザーマニュアル、操作マニュアルなど) の形式と完全性、およびシステム機能の説明への準拠を確認します。