專案管理的內容: 配置管理, 評審, 變更; 三個內容都是不可缺少的.屬於公共的流程.
配置管理:（核心是版本管理）
類似於 「圖書管理員」. 但是配置管理是通過平台來操作的.
配置管理所使用的"工具": svn, git
配置管理所管理的"內容": (軟體、程式、需求文件, 測試用例)的版本; 專案中所有的**; 專案中用到的所有工具; 所有資料—這些內容都叫做專案管理的 「配置項」.
圖書管理員管理的是圖書, 給圖書進行編號, 給圖書編上標籤, 放到相應的書架上,
而配置管理員則會把專案中所有的程式, 需求文件, 測試用例, **, 工具, 資料等全部管理起來, 放到svn和git上, 給這些配置項也會進行編號命名, 編上標籤, 放到svn或者git上進行管理
git上的預設分支是master. svn建立分支是打個tag, 即就是給它起個名字.
分支: 即就是管理不同的專案上的功能點. 分支起到的作用就是版本管理. 即就是儲存每個版本的**, 給每個版本都建立乙個分支. 下個版本是在上個版本的基礎上完成的, 即就是下個版本能夠覆蓋上個版本的功能.
舉個例子:產品上線出現bug, 需要進行回滾, 而此刻再除錯本版本的**已經來不及了, 並且容易出錯. 因此將上個版本的**拿出來進行除錯即可. 即一旦出現問題就可以回滾回去, 這樣的話能夠降低成本.
配置管理的流程: 編寫配置計畫–配置管理
評審:評審的內容: 針對專案裡 " 核心文件, 測試用例, 設計文件, 需求文件, **, 計畫類的文件 " 進行評審.
對於研發裡的**評審, 一般稱為 「**走查, **審查, coderivwer」
文件檢查和**檢查用的方法不一樣.
評審類別: 分為 「正式評審」 和 「非正式評審」.
正式評審需要召開會議, 提前發會議通知, 邀請專案組中所有成員(研發測試人員等)到會議室進行開會
非正式評審不需要開會, 只需乙個人或多個人將**檢查一遍
評審的流程: 提交申請–會議討論–後期跟蹤
評審的目的: 找bug, 驗證文件和**的正確性
變更:變更和配置管理息息相關
舉個例子, 第一分支有10個功能, 第二分支有20個功能, 在第三分支中要把第二分支的20個功能裡面多餘的5個功能去掉. 去掉哪5個功能, 去掉的原因, 在需求變更文件裡面都會詳細地說明.(1) 變更的原因.(2)分析變更會帶來的風險.(3)再反覆確定是否需要進行變更.
雖然使用者是上帝, 但是如果使用者提出的變更需求不合理, 是不能隨意變更的. 不然會引起一系列的bug以及不可預估的風險.變更是要有一套完整的流程的.
變更的流程: 申請變更–評估變更–實施變更–驗證變更–發布上線
**變更之後, 新版本還是需要在配置管理庫進行管理, 因此變更和配置管理是息息相關的.一旦變更, 就需要進行配置管理.
項管 配置管理 變更管理 文件管理 知識管理及其他
配置管理 配置管理6個主要活動 制訂配置管理計畫 配置標識 配置控制 配置狀態報告 配置審計 發布管理和交付。配置項的類別 基線配置項 設計文件和源程式等。非基線配置項 各類計畫和報告等。配置項的狀態 草稿 正式 修改。配置項建立時為草稿，通過評審後為正式，以後更改配置項，狀態為修改。版本號 草稿狀...
資料 配置管理
目前國內外常見的10種配置管理工具一覽 配置管理不是單純的指軟體的 版本管理,上面的資料介紹的主要是 級管理.配置管理的目的是為了準確交付，減少事故.當專案本身是由多個語言，多個部門來開發，採用了較多開源和第三方的軟體例項時，需要好的配置管理.配置管理之路 scmroad 軟體測試網 軟體測試管理 ...
cmmi配置管理
配置管理的目的是通過執行版本控制 變更控制等規程，以及使用配置管理軟體，來保證所以配置項的完整性和可跟蹤性。配置管理是對工作成果的一種有效保護。凡是納入配置管理範疇的工作成果統稱為配置項 comfiguration item,ci 配置項主要有兩大類 屬於產品組成部分的工作成果，如需求文件 設計文件...