【正文】 。 ? TSP（ Personal Software Process）對群組軟件過程的定義、度量和改革提出了一整套原則、策略和方法，把 CMM要求實施的管理與 PSP要求開發(fā)人員具有的技巧結(jié)合起來，以按時交付高質(zhì)量的軟件，并把成本控制在預(yù)算的范圍之內(nèi)。 這個進化框架是學(xué)習(xí) PSP過程基本概念的好方法 ， 它賦予軟件人員度量和分析工具 ， 使其清楚地認識到自己的表現(xiàn)和潛力 ， 從而可以提高自己的技能和水平 。 PSP ? PSP是一個包括軟件開發(fā)表格 、 指南和規(guī)程的結(jié)構(gòu)化框架 ， 是一種可用于控制 、 管理和改進個人工作方式的自我改善過程 。 ? CMM和 CMMI模型的開發(fā)和廣泛應(yīng)用對加強軟件過程管理 、軟件項目管理 、 加強軟件組織自身建設(shè)起到了重要推動作用 ，同時也為客戶選擇軟件開發(fā)組織提供了依據(jù) 。 ? 軟件規(guī)模度量 、 成本估算 、 質(zhì)量度量 、 可靠性度量 、 復(fù)雜性度量是軟件度量的重要組成部分 ， 已引起人們和軟件組織的普遍重視 。 CMMI缺點 CMMI是兩種結(jié)構(gòu) 、 三種模型的綜合 ， 在這些結(jié)構(gòu)和模型尚需發(fā)展 ， 還不十分成熟的情況下 ， CMMI模型由于照顧各方面的意見顯得復(fù)雜 、 臃腫 ， 給使用和評估帶來困難 。 ? 按照某種需要抽取過程域 、 確定成熟度等級 ，建立能力特征圖 ， 并按此組織實踐活動 、 進行評審和上報 。 ? 綜合了階段式和連續(xù)式兩種結(jié)構(gòu) ? 組織的成熟度評價和項目的軟件過程能力評估系統(tǒng)性更強 、 適應(yīng)范圍更大 ? CMMI提供了 24個過程域 ， 組織可根據(jù)自身情況或項目的特點進行剪裁 ? 過程域采用 0至 5的記分法則 ， 過程域成熟度的評估比較準(zhǔn)確 ， 能反映過程域的實際情況 ，特別是優(yōu)勢和不足 。 ? CMM過程域的度量只有通過或不通過 ， 度量比較粗糙沒有反映優(yōu)勢和一般 。 ? 為組織負責(zé)人和管理者提供指導(dǎo)組織逐步成熟的 、明確的 、 有效的 、 單一路途 。 ? 連續(xù)式模型將 24個過程域按照功能劃分為 過程管理 、 項目管理 、 工程 、 支持 四個過程組 。 ? 對同一組織采用兩種模型分別進行 CMMI評估應(yīng)該得到相同的結(jié)論 。 能力成熟度模型集成 CMMI ? CMMI項目在 1998年正式啟動 ? 來自業(yè)界 、 政府部門和 SEI/CMU三個方面的 170多人 ， 經(jīng)過兩年的工作于 2022年發(fā)布 CMMISE/SW/IPPD ? CMMISE/SW/IPPD 軟件學(xué)科的 SWCMM 系統(tǒng)工程學(xué)科的 EIA/IS 731 集成化產(chǎn)品和過程開發(fā)領(lǐng)域的 IPD CMM 能力成熟度模型集成 CMMI ? CMMI繼承了 SWCMM的階段式表示法和EIA/IS 731的連續(xù)式表示法 。 能力成熟度模型集成 CMMI的產(chǎn)生 CMM公布后的若干年內(nèi)工程環(huán)境更加復(fù)雜 ，工程規(guī)模更大 、 參與工程項目的組織和人員更多 、 范圍更廣泛 ， 工程的施工涉及多學(xué)科 、交叉學(xué)科 、 并行工程 、 及更多的國際標(biāo)準(zhǔn) 。 ? 模型的繁衍導(dǎo)致模型框架 、 術(shù)語等方面的矛盾和不一致 。 ? i) 實際項目中應(yīng)用的文檔有： 項目配置管理計劃制定流程定義、項目配置管理活動流程定義、項目配置管理計劃、配置狀態(tài)報告、基線審計報告（見附表）、配置項變更申請表、項目配置管理活動進度表、配置管理工具操作指南 能力成熟度模型集成 CMMI 1能力成熟度模型集成 CMMI的產(chǎn)生 ? 軟件能力成熟度模型 CMM取得了成功 ， 產(chǎn)生了很大影響 。 ? g) 一旦同意變更，由配置管理人員 Check out需變更的配置項，然后對配置項進行變更，變更完成后再由配置管理人員Check in到配置管理庫中。 軟件配置管理的方法 ? e) 根據(jù)配置管理計劃對項目的配置項和基線定期（或里程碑處）進行審計，以驗證其是否與項目配置計劃或項目開發(fā)計劃一致。 ? c) 在 ClearCase創(chuàng)建項目的 VOB（版本對象庫），創(chuàng)建項目小組成員的工作區(qū)和集成區(qū)，項目組成員只在各自的工作區(qū)Check in 或 Check out操作，由配置管理人員進行合并，標(biāo)識出軟件配置項。 ? a) 項目設(shè)定配置管理人員，以 Rational ClearCase為配置管理工具，根據(jù)項目計劃擬定項目的配置管理計劃文檔，以Microsoft Project擬定項目配置活動的進度表。 一旦采用了嚴格的變更控制管理流程，才能了解變更造成的影響，所有項目組成員才了解變更，形成共識，接受變更。 ? b. 變更管理 圖五 描述了納入配置管理的配置項進行變更的完整流程。 配置管理項最顯著的特征就是包含版本號或發(fā)布日期 。 軟件配置管理可以分為兩方面的內(nèi)容 ， 一是配置項的識別和管理 ， 另一方面是變更管理 。 在給定時間點上確定軟件配置 ， 如工作產(chǎn)品及其說明 。 ? g) 實際項目中應(yīng)用的文檔有： 項目質(zhì)量保證流程定義、質(zhì)量保證計劃、流程審計報告、軟件工作產(chǎn)品復(fù)審報告、質(zhì)量保證計劃進度表、SQA問題跟蹤解決進度表。如果不能解決的由高層管理者協(xié)助解決。 ? d) 質(zhì)量保證人員組織人員對產(chǎn)出的工作產(chǎn)品進行復(fù)審，以驗證其是否與項目采用的標(biāo)準(zhǔn)一致，并形成報告。項目的質(zhì)量保證人員在項目開發(fā)計劃復(fù)審?fù)ㄟ^之后，擬定項目的質(zhì)量保證計劃，并提交給項目經(jīng)理和質(zhì)量保證經(jīng)理或高層管理者復(fù)審。 軟件質(zhì)量保證過程 ? a) 項目質(zhì)量保證人員以 Microsoft Word擬定項目質(zhì)量保證計劃文檔，以 Microsoft Project擬定項目質(zhì)量保證活動的進度表。 該流程描述了軟件質(zhì)量保證計劃的形成與復(fù)審 ， SQA人員根據(jù)質(zhì)量保證計劃開展質(zhì)量保證活動 ， 發(fā)現(xiàn)問題 ， 跟蹤解決問題 ， 并最終向高層管理者匯報項目的執(zhí)行情況 。 (5) 軟件質(zhì)量保證 (quality assurance) 評審軟件產(chǎn)品和活動 ， 檢驗它們是否與應(yīng)用的標(biāo)準(zhǔn)和規(guī)程保持一致 ， 對發(fā)現(xiàn)的問題應(yīng)采取必要措施予以解決 。 項目計劃跟蹤與監(jiān)控采取如下方式： (4) 軟 件 分 包 合 同 管 理 (subcontract management) 根據(jù)商業(yè)聯(lián)盟 、 過程能力和技術(shù)等因素選擇高質(zhì)量的軟件承制方 ， 承制軟件項目的部分子項目 。 ? d) 由高層管理者復(fù)審進度報告及問題報告，并敦促項目經(jīng)理修正其計劃及解決項目存在的問題和風(fēng)險。然后召集項目小組成員，對進度報告進行確認和修正。 ? a) 項目組使用 Rational 的工具進行管理，將 Microsoft Project 擬定的項目計劃進度表導(dǎo)入 ClearQuest，主要以 ClearC