【正文】 作量， ev是估算變量（ KLOC或 FP）。Gaffney模型 ? Maston， Bart和 Mellichamp模型 13 .39 54 5E FP? ? ?5 8 5 .7 1 5 .1 2E F P?? 企業(yè)通用業(yè)頻道 靜態(tài)單變量的估算模型 ? 從上面可以看出，對于相同的 KLOC或 FP，用不同的模型估算的結(jié)果各不相同。 ? 因此，必須根據(jù)當(dāng)前項(xiàng)目特點(diǎn)選擇適應(yīng)的估算模型，并依據(jù)需要對相應(yīng)模型作出調(diào)整。 ? 該模型把工作量看作是軟件規(guī)模和開發(fā)時(shí)間的函數(shù)，其形式如下： 0. 333 3 4( / ) ( 1 / )E L O C B P t? ? ? 企業(yè)通用業(yè)頻道 動態(tài)多變量模型 其中： ? E是以人月或人年為單位的工作量； ? t是以月或年為單位的項(xiàng)目持續(xù)時(shí)間； ? B是特殊因子，它隨著對測試、質(zhì)量保證、文檔及管理技術(shù)的需求的增加而緩慢增加。 企業(yè)通用業(yè)頻道 動態(tài)多變量模型 P的取值： 開發(fā)實(shí)時(shí)嵌入式軟件時(shí)， P的典型值為 20xx； 開發(fā)電信系統(tǒng)和系統(tǒng)軟件時(shí)， P=10000； 對于商業(yè)應(yīng)用軟件來說， P=28000。 企業(yè)通用業(yè)頻道 COCOMO模型 COCOMO模型 Constructive Cost Model ? 它是 Boehm于 1981年在靜態(tài)單變量模型基礎(chǔ)上提出的 “ 構(gòu)造性成本模型 ” 。 企業(yè)通用業(yè)頻道 COCOMO模型 ? 依據(jù)系統(tǒng)規(guī)模和考慮因素的多少，由三種類型的 COCOMO模型： ? 基本 COCOMO模型 ? 中間 COCOMO模型 ? 詳細(xì) COCOMO模型 企業(yè)通用業(yè)頻道 ① 獨(dú)立型（ Organic） 較簡單，對產(chǎn)品目標(biāo)理解充分，經(jīng)驗(yàn)豐富，對軟件開發(fā)環(huán)境熟悉，由小團(tuán)隊(duì)開發(fā)。 ② 半獨(dú)立型（ Semidetached) 項(xiàng)目較復(fù)雜，團(tuán)隊(duì)成員對系統(tǒng)可能有些經(jīng)驗(yàn)。 ③ 嵌入型（ Embadded) 項(xiàng)目復(fù)雜，軟件只是復(fù)雜系統(tǒng)的一部分，軟件、硬件、規(guī)則和操作規(guī)程關(guān)系緊密，對接口、數(shù)據(jù)結(jié)構(gòu)，算法要求較高。 軟件復(fù)雜度的三種類型 企業(yè)通用業(yè)頻道 基本 COCOMO模型 ? 基本 COCOMO模型是一個(gè)靜態(tài)單變量模型，它把軟件系統(tǒng)所需要的成本看作是程序大小單一變量(KLOC)的 (經(jīng)驗(yàn) )函數(shù)，用于系統(tǒng)級的粗略估算。 ? 估算方程： 151aiiE C K L O C f?? ? ? ?其中： E是開發(fā)工作量； C是模型系數(shù)； KLOC是估計(jì)代碼行數(shù)； a是模型指數(shù)； fi是成本因素 嵌入型 半獨(dú)立型 獨(dú)立型 a C 軟件類型 企業(yè)通用業(yè)頻道 ? 每個(gè)成本因素 Fi根據(jù)它的重要程度和影響大小賦予一定的值，可把這些成本因素劃分為 (共 15個(gè) )： ? 產(chǎn)品因素 ? 計(jì)算機(jī)因素 ? 人員因素 ? 項(xiàng)目因素。 ? 該模型則將軟件分為系統(tǒng)、子系統(tǒng)、模塊三個(gè)層次。 ? 中間 CoCoMo模型用于估算各個(gè)子系統(tǒng)的工作量和開發(fā)時(shí)間。 企業(yè)通用業(yè)頻道 人員管理 ? 人員是軟件機(jī)構(gòu)中最重要的資產(chǎn)，他們代表著智力資本。 ? 因此軟件項(xiàng)目管理的關(guān)鍵是人員管理。 ? 軟件機(jī)構(gòu)要尊重員工，管理者要激勵(lì)員工。 ? 經(jīng)驗(yàn)表明，人員組織的好壞決定著生產(chǎn)率的高低和產(chǎn)品質(zhì)量的好壞。 ? 切忌在開發(fā)過程中增加人員 ， 這將使人員之間的聯(lián)系增多 ， 造成通信成本的增加而導(dǎo)致效率降低 。 企業(yè)通用業(yè)頻道 Brooks定律 向一個(gè)進(jìn)度已經(jīng)落后的項(xiàng)目增派開發(fā)人員，可能使項(xiàng)目完成得更晚。 企業(yè)通用業(yè)頻道 項(xiàng)目組的組織方式 ? 軟件項(xiàng)目組的組織方式很多，如民主制程序員組、主程序員組、現(xiàn)代程序員組等。 ? 小組成員之間的通訊是平行的，如果小組有 n個(gè)成員，則可能的通訊信道為 n(n1)/2條。 ? 由小組全體成員討論協(xié)商決定應(yīng)該完成的工作，并依據(jù)各成員能力和經(jīng)驗(yàn)分配適當(dāng)?shù)娜蝿?wù)。 企業(yè)通用業(yè)頻道 民主制程序員組 ? 如果組內(nèi)多數(shù)成員是經(jīng)驗(yàn)豐富、技術(shù)熟練的程序員，采用該組織方式是非常有效的。 適合于研制周期長、難度大的項(xiàng)目。 企業(yè)通用業(yè)頻道 主程序員組 ?項(xiàng)目開發(fā)普遍存在以下事實(shí)： ?軟件開發(fā)人員多數(shù)比較缺乏經(jīng)驗(yàn)； ?程序設(shè)計(jì)過程有許多事務(wù)性的工作； ?多渠道通訊很浪費(fèi)時(shí)間，降低程序員的生產(chǎn)率。 企業(yè)通用業(yè)頻道 編程秘書負(fù)責(zé)完成與項(xiàng)目有關(guān)的全部事務(wù)性工作，如，維護(hù)項(xiàng)目資料庫和項(xiàng)目文檔，編譯、連接、執(zhí)行源程序和測試用例。所以后備程序員必須和主程序一樣優(yōu)秀，一樣深入了解項(xiàng)目。同時(shí)，利用人和計(jì)算機(jī)在事務(wù)性工作方面給主程序員提供充分支持，而且 保證所有通訊都通過一兩個(gè)人進(jìn)行 。 企業(yè)通用業(yè)頻道 主程序員組的重要特征 ? 專業(yè)化 該組每名成員僅完成他們受過專業(yè)訓(xùn)練的那些工作。 企業(yè)通用業(yè)頻道 主程序員組的不足 ? 雖然主程序員組有很多優(yōu)點(diǎn)，但是，我們還應(yīng)看到這種組織方式固有的不切實(shí)際的地方： ?主程序員既是高級程序員又是優(yōu)秀管理者，但現(xiàn)實(shí)中這種人才很難見到。人們希望后備程序員像主程序員一樣優(yōu)秀，但他們必須坐在“替補(bǔ)席”上，拿著較低的工資等待接替主程序員。專業(yè)的軟件技術(shù)人員一般都厭煩日常的事務(wù)性工作。他往往會把發(fā)現(xiàn)程序錯(cuò)誤與小組成員業(yè)績聯(lián)系起來，造成小組成員不愿意發(fā)現(xiàn)錯(cuò)誤的心理。這樣既解決了問題，又使尋找主程序員的人選不再那么困難。同時(shí)，變化也很容易失去控制。 ?軟件配置管理是在軟件項(xiàng)目啟動時(shí)就開始，并且一直持續(xù)到軟件軟件退役才終止的一組追蹤和控制軟件變動的保護(hù)性活動。是對工作成果的一種有效保護(hù)。 ? SCI是納入配置管理范疇的工作成果。 軟件開發(fā)過程的工作成果： 1) 計(jì)算機(jī)程序（源代碼和可執(zhí)行程序）； 2) 描述計(jì)算機(jī)程序的文檔（供技術(shù)人員或用戶使用）； 3) 數(shù)據(jù)（包括程序內(nèi)部和外部定義的數(shù)據(jù)）。 ? SCI的狀態(tài)有： 草稿 (Draft)、 正式發(fā)布 (Released)和 正在修改 (Changing)。在軟件配置項(xiàng)變成基線之前，可以迅速而非正式的修改它。 ? 基線的主要屬性有名稱、標(biāo)識符、版本、日期等。 變更控制規(guī)劃 提示：配置管理員簡述本項(xiàng)目的變更控制規(guī)則。 注： CCB為配置控制委員會 企業(yè)通用業(yè)頻道 配置項(xiàng)標(biāo)識 ? 目標(biāo)： 明確項(xiàng)目生存周期內(nèi)所要產(chǎn)生的文檔、程序以及確定文檔、程序的名稱和命名規(guī)則。 ?每個(gè)配置項(xiàng)都擁有一組能唯一標(biāo)識它的特征：名字、描述、資源列表和“實(shí)現(xiàn)”。 ? 變動控制，就是在生存期中對 SCI的變動建立 評審 及 核準(zhǔn) 的機(jī)制。 ? 當(dāng) SCI處于“正式發(fā)布”狀態(tài)，或該 SCI已經(jīng)成為某個(gè)基線的一部分，若要修改，必須按照變更控制規(guī)則執(zhí)行。 ? 當(dāng)軟件變更時(shí)，每個(gè)組件的變更記錄都應(yīng)該維護(hù)，這稱為： 組件的導(dǎo)出歷史 。 企業(yè)通用業(yè)頻道 版本標(biāo)識 ? 一個(gè)大型系統(tǒng)內(nèi)有數(shù)以百計(jì)的軟件組件，其中每種組件都可能有許多不同的版本。 ? 簡單的版本編號方式是使用線性導(dǎo)出： – V1, , , , 等。 企業(yè)通用業(yè)頻道 版本導(dǎo)出結(jié)構(gòu) 企業(yè)通用業(yè)頻道 版本導(dǎo)出規(guī)則 SCI版本號與 SCI狀態(tài)緊密相關(guān)： ① 處于“草稿”狀態(tài)的 SCI版本號格式為： ? YZ數(shù)字范圍為 01～ 99； ? 隨著草稿的不斷完善，“ YZ”值應(yīng)遞增，初值和增幅由規(guī)則定。 Y為次版本號，取值 1～ 9； ? SCI第一次“正式發(fā)布”時(shí)，版本號為 ； ? 如果 SCI版本升級幅度較小，一般只增加 Y值， X值保持不變，只有 SCI版本升級幅度較大，才允許增加 X值。參見規(guī)則 2。 ? 系統(tǒng)的發(fā)布版本不僅僅是系統(tǒng)的可執(zhí)行代碼，還包括： ?配置文件 ?數(shù)據(jù)文件 ?安裝程序 ?電子和書面文檔 ?包裝和相關(guān)的宣傳 ? 發(fā)布管理者不能想當(dāng)然認(rèn)為客戶總是想安裝新的系統(tǒng)版本。 企業(yè)通用業(yè)頻道 發(fā)布版本 我們來看一個(gè)例子，考慮以下情況： ① 系統(tǒng)的發(fā)布版本 1發(fā)布并投入使用； ② 發(fā)布版本 2隨后發(fā)布。 發(fā)布人員不能認(rèn)為發(fā)布版本 3所需要的文件已經(jīng)安裝在所在地點(diǎn)。有些地方則可能已經(jīng)根據(jù)具體情況對發(fā)布版本 2有關(guān)的數(shù)據(jù)文件做了修改。 企業(yè)通用業(yè)頻道 配置審計(jì) ? 配置審計(jì)主要目的是要保證基線在技術(shù)上、管理上的完整性，保證對 SCI的變動是服從需求規(guī)定的。 ? 在 SLC間，不斷進(jìn)行配置審計(jì)。 ? CSR主要是回答“發(fā)生了什么事情”、“誰做的”、”何時(shí)發(fā)生的“、“有什么影響”等問題。 企業(yè)通用業(yè)頻道 配置管理工具 ? SourceSafe ? Microsoft Visual Studio套件之一 ? 簡單易用，一學(xué)就會 ? 是國內(nèi)最流行的配置管理工具 ? CVS ? Concurrent Version System（并行版本系統(tǒng)） ? 開源工具，服務(wù)器用 JAVA編寫，用于 UNIX， LINUX ? 客戶端很雜，安裝使用不便 ? ClearCase ? Rational產(chǎn)品 ? 是軟件行業(yè)公認(rèn)的功能最強(qiáng)大、價(jià)格最昂貴的配置管理軟件 ? 不參加培訓(xùn)，基本不可能無師自通 企業(yè)通用業(yè)頻道 能力成熟度模型 CMM 美國卡內(nèi)基 梅隆大學(xué)軟件工程研究所 (SEI) 80年代中期 美國國防部 資助 提出 軟件能力成熟度模型 (Software Capability Maturity Model ) 軟件過程改進(jìn)工業(yè)標(biāo)準(zhǔn) 克勞斯比 漢弗萊 成熟度框架 企業(yè)通用業(yè)頻道 當(dāng)初，建立 CMM的目的主要是：為大型軟件項(xiàng)目的招投標(biāo)活動提供一種全面而客觀的評審依據(jù)，發(fā)展到后來，此模型又同時(shí)被應(yīng)用于許多軟件機(jī)構(gòu)內(nèi)部的過程改進(jìn)活動中。 問題判斷無基礎(chǔ)，難預(yù)料；進(jìn)度滯后時(shí)，常減少或取消評審、測試等保證質(zhì)量的活動。 無實(shí)際根據(jù)，硬件限定時(shí)，常在質(zhì)量上作讓步。 反應(yīng)式（消防式） 管理方式 有統(tǒng)一標(biāo)準(zhǔn)，且切實(shí)可行，并不斷改進(jìn)；通過培訓(xùn)，全員理解，各司其職，紀(jì)律嚴(yán)明。 ? 軟件過程成熟度 一個(gè)特定軟件過程被明確且有效地定義、管理、測量和控制的程度。 企業(yè)通用業(yè)頻道 ? 由于軟件危機(jī)等問題是由我們管理軟件過程的方法不當(dāng)引起的，所以 新軟件技術(shù) 的應(yīng)用 并不會 自動提高軟件的 生產(chǎn)率 和 質(zhì)量 。改進(jìn)的軟件過程將開發(fā)出質(zhì)量更好的軟件，使更多的軟件項(xiàng)目免受時(shí)間和經(jīng)費(fèi)超支之苦。 用以測量軟件機(jī)構(gòu)的軟件過程成熟度和評價(jià)其軟件過程能力。 管理是反應(yīng)式 (消防式 )。 處于 1級成熟度的軟件機(jī)構(gòu) ， 其過程能力不可預(yù)測 ， 軟件過程是不穩(wěn)定的 ， 產(chǎn)品質(zhì)量是根據(jù)相關(guān)人員的個(gè)人工作能力而不是軟件機(jī)構(gòu)的過程能力來預(yù)測 。制定了必要的過程規(guī)范，能重復(fù)早先類似應(yīng)用項(xiàng)目的實(shí)踐經(jīng)驗(yàn)成功完成新項(xiàng)目。 處于 2級的軟件機(jī)構(gòu)，其軟件項(xiàng)目的策略和跟蹤是穩(wěn)定的，已經(jīng)為一個(gè)有紀(jì)律的管理過程提供了可重復(fù)以前成功實(shí)踐的項(xiàng)目環(huán)境。 所有項(xiàng)目均使用經(jīng)批準(zhǔn)的 、 文檔化的標(biāo)準(zhǔn)軟件過程來開發(fā)和維護(hù)軟件 。 在第 3級成熟度的軟件機(jī)構(gòu)中 ， 有一個(gè)固定的過程小組從事軟件過程工程活動 。實(shí)施了培訓(xùn)計(jì)劃 ， 保證全體項(xiàng)目負(fù)責(zé)人和開發(fā)人員具有完成承擔(dān)的任務(wù)所要求的知識和技能 。 成本 、 進(jìn)度和質(zhì)量都受到控制 ， 且軟件質(zhì)量具有可追溯性 。軟件機(jī)構(gòu)收集了過程度量和產(chǎn)品質(zhì)量的方法并加以運(yùn)用，對軟件過程和產(chǎn)品都有定量的理解與控制。 處于 4級成熟度的軟件機(jī)構(gòu)，軟件過程是可度量的，軟件過程在可度量的范圍內(nèi)運(yùn)行。 4 已定量管理級 企業(yè)通用業(yè)頻道 過程的量化反饋和先進(jìn)的新思想 、 新技術(shù)促進(jìn)軟件過程不斷改進(jìn) 。 包含 4級的全部特征 。 5 優(yōu)化級 企業(yè)通用業(yè)頻道 CMM概述 ? 這 5個(gè)成熟度等級定義了一個(gè)有序的尺度，用以測量軟件機(jī)構(gòu)過程能力成熟度和評價(jià)其軟件過程能力。 ? CMM對 5個(gè)成熟度級別的描述，說明了不同級別之間軟件過程的主要變化。 企業(yè)通用業(yè)頻道 統(tǒng)計(jì)數(shù)字表明，提高一個(gè)完整的成熟度等級大約需要花 18個(gè)月到 3年時(shí)間，但從第 1級上升到第 2級有時(shí)要花 3年甚至 5年時(shí)間。 CMM概述 企業(yè)通用業(yè)頻道 軟件過程評估 ：目的是確定一個(gè)組織的當(dāng)前軟件過程的狀態(tài)，找出組織所面臨的急需解決的與軟件過程有關(guān)問題，進(jìn)而有步驟地實(shí)施軟件過程改進(jìn)，使組織的軟件過程能力不斷提高。 CMM應(yīng)用