軟體文件可分為三類：
1> 開發文件：可行性研究報告、專案任務書、需求規格說明書等
2> 產品文件：培訓手冊、產品手冊、使用者指南等
3> 管理文件：開發團隊的職責定義
文件質量可分為四級：
1> 最低限度文件（1級）
2> 內部文件（2級）
3> 工作文件（3級）
4> 正式文件（4級）
文件分類編號規則：
1> 生命週期法各階段
2> 各階段的文件
3-4> 文件內容
5-6> 流水碼
軟體文件的歸檔應滿足以下條件：
> 歸檔的文件應是經過鑑定或評審的
> 文件應簽署完整、成套、格式統
一、字跡工整
> 印製本、列印本以及各種報告應裝訂成冊，並按規定進行編號、簽署
> 軟體文件應在專案開發過程每個階段結束後及時歸檔
配置管理：
> 配置控制委員會（configuration control board，ccb）
> 配置管理員（configuration management officer，cmo）
> 配置基線
配置項：
> 所有配置項的操作許可權應由配置管理員嚴格管理
> 基線配置項向developer開放讀取的許可權
> 非基線配置項向pm、ccb及相關人員開放
配置項狀態：
> 草稿
> 正式
> 修改
配置項版本號：
> 草稿，版本號格式為0.yz
> 正式，版本號格式為x.y（第一次為1.0）
> 修改，版本號格式為x.yz
配置項版本管理：
對配置項的任何修改都將產生新的版本，不能拋棄舊版本
配置庫：
> 開發庫，也稱動態庫
> 受控庫，也稱主庫
> 產品庫，也稱靜態庫、發行庫、軟體倉庫，包含已發布使用的各種跡象的存檔，被置於完全的配置管理之下。
配置庫許可權設定：
> read
> check
> add
> destroy
受控庫的許可權設定
產品庫的許可權設定
配置審計：
功能配置審計是審計配置項的一致性，即：配置項的實際功效是否與需求一致
物理配置審計是審計配置項的完整性，即：配置項的物理存在是否與預期一致
配置管理的過程：
> 制定配置管理計畫
> 配置標識（識別配置量，建立和控制基線）
> 配置控制
> 配置狀態報告
> 配置審計
> 發布管理和交付
編寫配置管理計畫：
> 建立和維護配置管理系統
> 建立和維護配置庫
> 配置項識別
> 建立和管理基線
> 版本管理和配置控制
> 配置狀態報告
> 配置審計
> 發布管理和交付
> 配置管理培訓
> 配置管理系統
變更管理：
變更管理是為了使專案實際執**況和專案基準相一致而對專案變更進行管理，其可能的結果是拒絕變更或調整基準。
專案變更的分類：
按變更性質，分為：重大變更、重要變更、一般變更；可通過不同審批許可權控制
按變更的迫切性，分為：緊急變更、非緊急變更；可通過不同變更流程控制
變更管理的基本原則：
建立專案基準、變更控制流程和變更控制委員會（ccb）
1> 基準管理：基準是變更的依據
2> 建立變更控制流程
3> 建立變更控制委員會（ccb）
4> 完整體現變更的影響
5> 變更產生的相關文件應納入配置管理中
變更管理的角色職責：
1> 變更申請人
2> 專案經理
3> 變更控制委員會（ccb）
4> 變更實施人
5> 配置管理員
變更管理的工作程式：
1> 提出變更申請：所有變更申請都必須以書面方式記錄，並納入配置管理系統
2> 變更影響分析
3> ccb審查批准
4> 實施變更
5> 監控變更實施
6> 結束變更：變更通知，成果納入配置管理系統中
系統 整合系統映象
首先附上工具 2 開啟虛擬光碟機，根據映象個數載入相應虛擬光碟機個數 3 將imagex.exe放到可用空間較大的碟符中，我以d盤為例，開啟cmd介面，進入d盤根目錄下，輸入imagex.exe 結果如下圖所示 這裡我們需要使用到兩條命令，第一條是imagex.exe info 系統映象對應虛擬光碟...
舊系統整合Spring
原來有個老的系統,是用struts1.2 hibernate3開發.後來又增加了一些新的功能,加入了spring.現在的系統是亂得不能再亂.一部分的sh,一部分的ssh.效能也是不能忍受.真得不想再去碰這個系統了.不想做,但還得去做啊.首先就是sh部分加入spring.火大,不知道當初是怎麼設計這個...
系統整合專案操作流程
專案前期準備工作 市場調研 專案立項 專案情況週報 意向協議 合作協議 市場調研報告 專案立項策劃方案 專案立項報告 專案委任書 評審報告 專案推進管理 投標過程控制表 投標總結報告 專案推進策劃案 專案合同策劃案 技術方案 投標書合同審批會簽表 評審報告 專案情況週報 專案方案 專案合同推進 合同...