Ch05-可重復(fù)性管理

1、軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生Chapter 5.可重復(fù)性管理“加強(qiáng)紀(jì)律性，革命無(wú)不勝?！避浖^(guò)程改進(jìn)方法與實(shí)踐案例王安生可重復(fù)性？ 雖然沒(méi)有兩場(chǎng)完全一樣的戰(zhàn)爭(zhēng)，但是軍事家們同樣可以總結(jié)出歷次戰(zhàn)爭(zhēng)過(guò)程的共性。通過(guò)對(duì)戰(zhàn)例的總結(jié)，獲得了面對(duì)新戰(zhàn)爭(zhēng)環(huán)境下如何能夠利用已有戰(zhàn)例經(jīng)驗(yàn)和教訓(xùn)，設(shè)計(jì)出“可重復(fù)”的戰(zhàn)爭(zhēng)過(guò)程?！凹o(jì)律性”是任何軍事組織所強(qiáng)調(diào)的第一個(gè)共性。鐵的紀(jì)律是實(shí)現(xiàn)“可重復(fù)”的基礎(chǔ)。 工業(yè)化生產(chǎn)的最高境界就是產(chǎn)品生產(chǎn)的可重復(fù)性。具有組織紀(jì)律、能夠進(jìn)行大規(guī)模生產(chǎn)的產(chǎn)業(yè)工人是傳統(tǒng)工業(yè)生產(chǎn)的基礎(chǔ)。當(dāng)今對(duì)于制造業(yè)，可重復(fù)生產(chǎn)的最佳途徑是無(wú)人值守工廠。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生 Process C

2、ategoriesManagementOrganizationalEngineeringLevels/1 Initial2 Repeatable3 Defined4 Managed5 OptimizingAd Hoc ProcessesIntegrated Software ManagementIntergroup CoordinationRequirements ManagementSoftware Project PlanningSoftware Project Tracking and OversightSoftware Subcontract ManagementSoftware Qu

3、ality AssuranceSoftware Configuration ManagementOrganization Process FocusOrganization Process DefinitionTraining ProgramSoftware Product EngineeringPeer ReviewsSoftware Quality ManagementQuantitative Software ManagementTechnology Change ManagementProcess Change ManagementDefect Prevention軟件過(guò)程改進(jìn)方法與實(shí)

4、踐案例王安生CMM Level 2 Key Process AreasRequirements Management需求管理(RM)Software ProjectPlanning軟件項(xiàng)目策劃(SPP)SoftwareConfiguration Management軟件配置管理(SCM)Software Quality Assurance軟件質(zhì)量保證(SQA)Software Subcontract Management軟件子合同管理(SSM)Software Project Tracking and Oversight軟件項(xiàng)目跟蹤和監(jiān)督(SPTO)軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生Requir

5、ements Management需求管理(RM)軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生需 求 管 理 軟件需求總是不清楚的。 有人把需求的獲取看作一個(gè)知識(shí)獲取或?qū)W習(xí)的過(guò)程。 需求的典型輸入是一個(gè)想法(idea)，理想的輸出是軟件規(guī)范說(shuō)明(Specification)。 一旦一個(gè)軟件需求能夠用形式化語(yǔ)言描述清楚，軟件的需求就變得100%清楚了。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生需求的獲取過(guò)程 客戶的抱怨：“我們不知道我們需要的軟件是什么，我們只知道你所交付的軟件不是我們所需要的，此軟件不好用?！?用戶需求 招標(biāo)/投標(biāo) 系統(tǒng)需求分析 分配給軟件的需求 分配給硬件 的需求 分配給其他 的要求 軟件需求文檔

6、 分配基線 需求變更 功能 需求 非功能 需求 軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生Requirements readers用戶需求客戶經(jīng)理系統(tǒng)最終用戶客戶工程師開(kāi)發(fā)方的經(jīng)理系統(tǒng)體系結(jié)構(gòu)師系統(tǒng)需求系統(tǒng)最終用戶客戶工程師軟件開(kāi)發(fā)人員系統(tǒng)體系結(jié)構(gòu)師軟件需求文檔軟件開(kāi)發(fā)人員系統(tǒng)體系結(jié)構(gòu)師客戶工程師(參考)需求類型需求類型讀者讀者軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生Requirements Management- Purpose 1. 需求管理的目的 建立客戶和項(xiàng)目開(kāi)發(fā)者之間的共同理解(common understanding) 2. 就客戶需求，建立和維護(hù)與客戶之間的協(xié)議(合同） 此協(xié)議(合同)表示為： s

7、ystem requirements allocated to the software. “customer”既可以解釋為系統(tǒng)工程組、市場(chǎng)組、企業(yè)內(nèi)部的一個(gè)部門，也可以解釋為外部客戶。 協(xié)議要包括技術(shù)和非技術(shù)性需求 協(xié)議作為建立、策劃、執(zhí)行、追蹤軟件項(xiàng)目整個(gè)生命周期活動(dòng)的基礎(chǔ)軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生系統(tǒng)需求系統(tǒng)需求分析分析/ / 設(shè)計(jì)設(shè)計(jì)HWCI 測(cè)試瀑布模型中的需求系統(tǒng)系統(tǒng)設(shè)計(jì)設(shè)計(jì)系統(tǒng)要系統(tǒng)要求分析求分析硬件研制軟軟件件開(kāi)開(kāi)發(fā)發(fā)功能功能基線基線分配分配基線基線開(kāi)發(fā)配置開(kāi)發(fā)配置系統(tǒng)系統(tǒng)集成集成 和測(cè)和測(cè)試試產(chǎn)品基線產(chǎn)品基線軟件軟件需求需求分析分析制造詳細(xì)設(shè)計(jì)初步設(shè)計(jì)硬件要求分析驗(yàn)收驗(yàn)

8、收/ /移交移交概要概要設(shè)計(jì)設(shè)計(jì)詳細(xì)詳細(xì)設(shè)計(jì)設(shè)計(jì)編碼編碼CSUCSU測(cè)試測(cè)試CSCCSC集集成和成和測(cè)式測(cè)式CSCICSCI測(cè)試測(cè)試發(fā)發(fā)用戶需求系統(tǒng)需求軟件需求分配的需求招標(biāo)招標(biāo)軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生分配的需求3. 系統(tǒng)需求的分配 通常，軟件只是系統(tǒng)的一部分。即使是在軟件密集的系統(tǒng)中，仍然是這樣的。必須把系統(tǒng)的要求分配給軟件需求、硬件需求、以及人(或其他)的操作需求： 這樣的分配過(guò)程，在大系統(tǒng)研制過(guò)程中，往往不是有軟件工程組決定的（例如，是由系統(tǒng)工程小組分配的）。因此，許多情況下，軟件工程組不能決定和控制這種分配。 在項(xiàng)目的約束條件下，軟件工程組要采用適當(dāng)?shù)牟襟E，保證系統(tǒng)分配給軟件的

9、需求被表達(dá)、編寫成正式文檔、并控制其變更。System Requirements系統(tǒng)需求Hardware Requirements硬件需求(項(xiàng))Software Requirements軟件需求(項(xiàng))Human Requirements操作人員需求(項(xiàng))軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生需求管理的目標(biāo) 1) 控制分配需求以建立軟件工程和管理所使用的基線。 通常系統(tǒng)工程組會(huì)將模糊的需求，或者，只要硬件沒(méi)法實(shí)現(xiàn)的，都交給軟件實(shí)現(xiàn)。高估軟件的能力，并帶來(lái)風(fēng)險(xiǎn)。 需求不清晰、以及今后的不斷變更造成項(xiàng)目的失敗。 建立基線，掌握“類似”的需求，從而達(dá)到“可重復(fù)”。 2) 軟件計(jì)劃、工作產(chǎn)品和活動(dòng)與分配需求相

10、一致。 開(kāi)發(fā)計(jì)劃往往會(huì)偏離實(shí)際的軟件需求，直接依據(jù)項(xiàng)目經(jīng)理或客戶要求，定義進(jìn)度和工作產(chǎn)品。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生需求與項(xiàng)目的可重復(fù)性 需求是項(xiàng)目的最基本輸入，也是決定項(xiàng)目之間是否具有類似的基本依據(jù)。 當(dāng)需求清晰后，我們就能對(duì)項(xiàng)目的規(guī)模、問(wèn)題領(lǐng)域、大致的軟件體系結(jié)構(gòu)、人員所需、時(shí)間進(jìn)度、軟件質(zhì)量要求(包括功能和非功能性)有一個(gè)大概的了解。 找出“類似”項(xiàng)目，達(dá)到可重復(fù)！ 一旦需求是非常不穩(wěn)定的(在開(kāi)發(fā)過(guò)程中，不斷變更)，以前的項(xiàng)目經(jīng)驗(yàn)就失去意義。項(xiàng)目的“可重復(fù)性”就成為空話！ 順利到達(dá)目的地的最快、最安全的路線是你最熟悉的路線！軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生 對(duì)功能性需求的理解，可以

11、澄清許多問(wèn)題，例如： 1) 軟件需求文檔中的用例圖(use cases)和部署圖能讓我們了解未來(lái)的系統(tǒng)如何使用和部署。 2) 哪些需求的實(shí)現(xiàn)難度大、風(fēng)險(xiǎn)大？軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生 通過(guò)對(duì)非功能性需求的理解, 可以澄清許多問(wèn)題，例如， 1) 對(duì)開(kāi)發(fā)環(huán)境、運(yùn)行環(huán)境的理解，能讓項(xiàng)目組估計(jì)出軟件的難度。 2) 對(duì)行業(yè)標(biāo)準(zhǔn)等的理解，可以掌握足夠的項(xiàng)目知識(shí)，建立與客戶的共同理解。 3) 對(duì)編程語(yǔ)言、數(shù)據(jù)庫(kù)等要求的理解，可以清楚對(duì)人力資源的要求。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生項(xiàng)目的類似性 通過(guò)對(duì)功能和非功能性需求的理解，我們能夠知道所謂的“類似項(xiàng)目”類似在哪些方面，例如，編程語(yǔ)言、用戶的行業(yè)背景

12、、數(shù)據(jù)庫(kù)、軟件規(guī)模、人力資源、進(jìn)度、軟件缺陷率的要求等。 特別是非功能性的要求，對(duì)于確定項(xiàng)目之間是否具有可比性，起著決定性的作用。 例如，實(shí)驗(yàn)室使用的求解微分方程的軟件與運(yùn)載火箭上求解微分方程軟件，在功能上是一樣的。 但是軟件質(zhì)量和運(yùn)行環(huán)境的差別，造就了后者比前者要付出幾十倍的費(fèi)用代價(jià)。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生例：針對(duì)非功能性需求的改進(jìn) Engineering Ingegneria Informattica SPA 意大利的一家大型軟件工廠，420員工，1994年?duì)I業(yè)額3500萬(wàn)ECU。 目的 解決預(yù)算的準(zhǔn)確性 方法 擴(kuò)展開(kāi)發(fā)理念，增強(qiáng)正式說(shuō)明書中非功能需求（例如易用性、可靠性、可移植

13、性）說(shuō)明，使得這些因素對(duì)軟件造成的影響可以在整個(gè)開(kāi)發(fā)過(guò)程中被跟蹤 建立自我加強(qiáng)型的生命周期，了解這些因素的影響，從而更好地制定評(píng)估和項(xiàng)目計(jì)劃。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生例：針對(duì)非功能性需求的改進(jìn) 商業(yè)收益 實(shí)驗(yàn)的6個(gè)項(xiàng)目，從最初的25%預(yù)算誤差減少到8%（方法只用于不小于250 000ECU的項(xiàng)目）將非功能性需求文檔化基于以前的經(jīng)驗(yàn)計(jì)劃合適的活動(dòng)精確費(fèi)用預(yù)算和資源分配培訓(xùn)客戶關(guān)于軟件質(zhì)量的問(wèn)題展示軟件能力項(xiàng)目管理和利潤(rùn)率改進(jìn)從需求到開(kāi)發(fā)活動(dòng)映射的相關(guān)知識(shí)軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生Software Project Planning軟件項(xiàng)目策劃(SPP)軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生

14、項(xiàng) 目 策 劃 策劃的目的和目標(biāo) “項(xiàng)目策劃”的目的在于建立并維護(hù)規(guī)定項(xiàng)目各項(xiàng)活動(dòng)的計(jì)劃。 “項(xiàng)目策劃”包括制訂項(xiàng)目計(jì)劃、與共益者(stakeholders)進(jìn)行適當(dāng)交流并且就計(jì)劃達(dá)成一致和維護(hù)計(jì)劃。 “策劃工作”是從那些規(guī)定產(chǎn)品和項(xiàng)目的需求開(kāi)始，包括對(duì)工作產(chǎn)品和作業(yè)的屬性及所需資源進(jìn)行評(píng)價(jià)、協(xié)商各項(xiàng)承諾、擬訂進(jìn)度，以及識(shí)別和分析項(xiàng)目風(fēng)險(xiǎn)。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生項(xiàng)目計(jì)劃的開(kāi)發(fā)過(guò)程 談判承諾iate Commitment 估計(jì)規(guī)模 估計(jì)資源ate Project Resources 開(kāi)發(fā)進(jìn)度 Schedule 初始 需求需求 談判 WBS SLOC 程 序 員人 月 和機(jī)時(shí) 項(xiàng)目 進(jìn)度

15、 Schedule 實(shí)際als 估計(jì) Y N 交付產(chǎn)品 比較 分解 需求 進(jìn)度要求？ 開(kāi)發(fā) 軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生優(yōu)化級(jí)-不斷改進(jìn) 個(gè)人簡(jiǎn)歷jian 用戶 需求 企業(yè)需求 運(yùn)行需求 系統(tǒng)環(huán)境需求 系統(tǒng)性能需求 實(shí)踐驗(yàn)證過(guò)的 項(xiàng)目控制方法 員工 組織方法 可使用的技術(shù) 和項(xiàng)目方法 軟件開(kāi)發(fā)計(jì)劃 1.目的和范圍 2.與其他文檔的關(guān)系 3. 軟件開(kāi)發(fā)管理 3.1 項(xiàng)目組織與資源 3.2 進(jìn)度和里程碑 3.3 風(fēng)險(xiǎn)管理 3.4 安全保密 3.5 與其他承制方的接口 3.6 轉(zhuǎn)承制方的管理 4 軟件工程 4.1 組織和資源 4.2 軟件開(kāi)發(fā)標(biāo)準(zhǔn) 4.3 非開(kāi)發(fā)軟件 5 正式合格性測(cè)試 6 軟件

16、評(píng)審 7 軟件配置管理 項(xiàng)目控制需求 承包商 進(jìn)度 預(yù)算 開(kāi)發(fā)過(guò)程 模型 合同 計(jì)劃 發(fā)展 方向 系統(tǒng) 要求 接口 定義 性能 需求 軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生項(xiàng)目策劃中的問(wèn)題 制定一個(gè)項(xiàng)目計(jì)劃的關(guān)鍵是對(duì)產(chǎn)品規(guī)模、資源、時(shí)間進(jìn)度制定一個(gè)項(xiàng)目計(jì)劃的關(guān)鍵是對(duì)產(chǎn)品規(guī)模、資源、時(shí)間進(jìn)度的估計(jì)。的估計(jì)。COCOMO最初發(fā)表于1981年巴里勃姆(Barry Boehm)軟件工程經(jīng)濟(jì)學(xué)一書中，作為在軟件項(xiàng)中估算工作量、成本以及時(shí)間進(jìn)度表的模型。巴里勃姆于1981年在該公司擔(dān)任軟件研究與技術(shù)總監(jiān)。COCOM是基于對(duì)TRW飛機(jī)制造公司的63個(gè)項(xiàng)目的研究。這些項(xiàng)目所包含的代碼量從2000行到10000行，包

17、含的編程語(yǔ)言從匯編語(yǔ)言到PL/I。這些項(xiàng)目采用瀑布模型進(jìn)行軟件開(kāi)發(fā)，這種開(kāi)發(fā)模式是在1981年時(shí)主流的軟件開(kāi)發(fā)模式。1997年開(kāi)始研發(fā)“COCOMO II”，并最終于2001年發(fā)表于軟件成本估算：COCOMO 模型方法 軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生項(xiàng)目開(kāi)發(fā)中的交流方式1 line3 lines10 linesN persons need n(n-1)/2 lines6 lines自設(shè)計(jì)/自編程/自測(cè)試/一包到底, communication easy軟件開(kāi)發(fā)是“個(gè)人藝術(shù)”，而不是工程軟件的工程管理軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生項(xiàng)目的組織結(jié)構(gòu)JuniorProgarmmersSeinor

18、progarmmersLibarariesAdministrationTest teamassitanr chiefprogarammerChiefProgarmmer1972年，首次在IBM使用軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生矩陣式的組織結(jié)構(gòu)GUI應(yīng)用服務(wù)數(shù)據(jù)庫(kù) 話費(fèi)數(shù)據(jù)采集QA測(cè)試項(xiàng)目 1XXXX項(xiàng)目 2XXXXXX項(xiàng)目 3XXXSEM1M2M3M4T1T2T3T4T5T6T7T8T9T10T11T12RequirementsDesignCodingIntegration/testingDelivery以瀑布模型為基礎(chǔ)的項(xiàng)目計(jì)劃網(wǎng)絡(luò)圖例M: 評(píng)審點(diǎn)T: 工程任務(wù)關(guān)鍵路徑時(shí)間進(jìn)度軟件過(guò)程改進(jìn)

19、方法與實(shí)踐案例王安生活動(dòng)時(shí)間線軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生員工工作分配4/711/718/725/1/88/815/822/829/85/912/919/9T4T8T11T12T1T3T9T2T6T10T7T5張三李四AnneMaryJim軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生風(fēng)險(xiǎn)管理 Boehm的十個(gè)頂級(jí)風(fēng)險(xiǎn)項(xiàng)（Risk Item） 人員流失（Personnel shortfalls） 不實(shí)際的進(jìn)度和財(cái)政預(yù)算 開(kāi)發(fā)錯(cuò)誤的軟件功能 開(kāi)發(fā)錯(cuò)誤的用戶界面 種金子 不斷的需求更改 外部完成的任務(wù)的不滿足 外部提供部件的不滿足 實(shí)時(shí)性能不滿足 過(guò)分強(qiáng)調(diào)計(jì)算機(jī)科學(xué)的能力軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生計(jì)劃

20、的可重復(fù)性 簡(jiǎn)單的計(jì)算往往是不可行的。 簡(jiǎn)單公式：所需人天 = 工作量/工作效率 并假：設(shè)員工隨時(shí)可用 實(shí)際上 企業(yè)的管理者不希望員工沒(méi)事做 一個(gè)員工可能要同時(shí)做多個(gè)項(xiàng)目 員工的風(fēng)險(xiǎn)是最大的風(fēng)險(xiǎn) 可重復(fù)： 預(yù)計(jì)到一系列的風(fēng)險(xiǎn) 考慮到各種資源等 參考原先成功項(xiàng)目的經(jīng)驗(yàn) 吸取失敗項(xiàng)目的教訓(xùn)軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生Software Project Tracking and Oversight軟件項(xiàng)目跟蹤和監(jiān)督 (SPTO)軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生項(xiàng)目跟蹤與監(jiān)督 軟件項(xiàng)目跟蹤和監(jiān)督要達(dá)到的目標(biāo)為： 1) 依據(jù)軟件項(xiàng)目計(jì)劃跟蹤實(shí)際結(jié)果和性能。 2) 在實(shí)際結(jié)果和性能明顯偏離軟件計(jì)劃時(shí)，采

21、取糾正措施并加以管理，直到結(jié)束。 3) 受影響的組和個(gè)人同意對(duì)軟件承諾的更改。 按照(文檔化的)估計(jì)、承諾和計(jì)劃，跟蹤和評(píng)審軟件各階段完成的情況和結(jié)果，并根據(jù)實(shí)際完成情況和結(jié)果調(diào)整這些計(jì)劃。 “軟件項(xiàng)目計(jì)劃”是跟蹤軟件活動(dòng)、通報(bào)狀態(tài)和修訂計(jì)劃的依據(jù)。 項(xiàng)目管理者需要監(jiān)控軟件項(xiàng)目活動(dòng)的狀態(tài)。特別是在項(xiàng)目計(jì)劃規(guī)定的里程碑和基線處，一定要將實(shí)際完成的軟件規(guī)模、工作量、成本和進(jìn)度與計(jì)劃進(jìn)行比較，以準(zhǔn)確判斷實(shí)際進(jìn)展情況。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生跟蹤的準(zhǔn)確性 從軟件的開(kāi)發(fā)角度來(lái)看，大多數(shù)情況下，0%和99%的完成，其效果幾乎是一樣的。提升軟件開(kāi)發(fā)過(guò)程可見(jiàn)性的方法是，在0%與100%之間設(shè)立合理的刻

22、度(度量指標(biāo))，用更精確的指標(biāo)讓管理者更清楚實(shí)際的進(jìn)展情況。下面的例子是對(duì)刻度的一些建議： 每個(gè)檢查點(diǎn)必須是特定的和可測(cè)量的，例如： 50%的需求文檔全部通過(guò)評(píng)審，而不是每個(gè)文檔都完成50%。 50%模塊設(shè)計(jì)完成、執(zhí)行設(shè)計(jì)評(píng)審以及糾錯(cuò)工作。 25%模塊通過(guò)編譯，而沒(méi)有錯(cuò)誤。 15%的程序通過(guò)測(cè)試，執(zhí)行沒(méi)有錯(cuò)誤。 用戶手冊(cè)的第一個(gè)草稿完成，并提交技術(shù)評(píng)審。在項(xiàng)目計(jì)劃中以及監(jiān)督時(shí)，使用數(shù)字要有準(zhǔn)確的百分比，否則就失去意義，例如： 50%的模塊完成設(shè)計(jì)，應(yīng)當(dāng)規(guī)定為，共有100個(gè)模塊，其中的50個(gè)模塊100%完成，而不是所有的模塊平均完成50%(可能意味著，一個(gè)模塊也沒(méi)完成)。 所有的測(cè)試用例都測(cè)過(guò)一

23、遍，通過(guò)率達(dá)100%，而不是簡(jiǎn)單地說(shuō)：通過(guò)測(cè)試。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生開(kāi)發(fā)隊(duì)伍的組織形式 層次組織形式 矩陣形式 主程序員形式 SWAT形式 Agile 形式 開(kāi)源軟件開(kāi)發(fā)軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生開(kāi)發(fā)隊(duì)伍的組織形式 層次組織形式TABCDE子系統(tǒng) A子系統(tǒng) B子系統(tǒng) QA測(cè)試軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生開(kāi)發(fā)隊(duì)伍的組織形式 矩陣形式- 移動(dòng)網(wǎng)絡(luò)實(shí)時(shí)信號(hào)采集GIS 開(kāi)發(fā)數(shù)據(jù)庫(kù)開(kāi)發(fā)QA測(cè)試項(xiàng)目 A項(xiàng)目 B項(xiàng)目 C 軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生 主程序員形式JuniorProgarmmersSeinor progarmmersLibarariesAdministrationT

24、est teamassitanr chiefprogarammerChiefProgarmmer軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生開(kāi)發(fā)隊(duì)伍的組織形式 SWAT形式 采用漸進(jìn)式、迭代的過(guò)程 SWAT(Skilled With Advanced Tools) 4-5人左右，一起辦公 信息交流快捷，無(wú)正式會(huì)議 頭腦風(fēng)暴或白板畫圖 增量式開(kāi)發(fā) 重用部件 良好的工作流程管理 高昂的工作激情軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生開(kāi)發(fā)隊(duì)伍的組織形式 Agile 形式 某些類似于SWAT 更依賴于人，而不是隊(duì)伍 “計(jì)劃驅(qū)動(dòng)” 在這里成為個(gè)人能力充分發(fā)揮，而不受到任何的約束 項(xiàng)目的跟蹤變得苦難！ 避免項(xiàng)目風(fēng)險(xiǎn)要靠人Le

25、vel人的能力Agile3Fluent能夠很靈活地從一種方法到另一種。能夠修正方法，適應(yīng)未遇到的情況?？捎茫芨櫰涔ぷ?-Detaching對(duì)某種方法適應(yīng)?？梢詫W(xué)習(xí)其他方法，能接受未遇到過(guò)情況的方法。1Following只能遵循一種方法，對(duì)于其他新方法就會(huì)暈乎。能夠按部就班地執(zhí)行步驟，例如，填寫Web網(wǎng)頁(yè)代碼，或運(yùn)行測(cè)試。不可用/不可跟蹤軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生被動(dòng)使用者開(kāi)發(fā)隊(duì)伍的組織形式 開(kāi)源軟件開(kāi)發(fā) “沒(méi)有圍墻的公司” 沒(méi)有合同 開(kāi)發(fā)進(jìn)度沒(méi)有計(jì)劃， 缺乏文檔 出現(xiàn)Bug，不知何時(shí)能定位和解決 沒(méi)法做到項(xiàng)目跟蹤和監(jiān)督積極使用者合作開(kāi)發(fā)者核心隊(duì)伍軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生實(shí)際與

26、計(jì)劃差異 實(shí)際情況總是與計(jì)劃具有差異的 計(jì)劃顆粒度越細(xì)，差異可能越大， 越理想的計(jì)劃，差異越大 各種風(fēng)險(xiǎn)的發(fā)生，可能導(dǎo)致計(jì)劃的很大程度上的改變 記錄這些差異(進(jìn)度、工作量、費(fèi)用等) 估計(jì)和計(jì)算出員工生產(chǎn)能力的曲線 今后項(xiàng)目的計(jì)劃可能做的更準(zhǔn)確軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生項(xiàng)目跟蹤與監(jiān)督顆粒度和工作量 計(jì)劃跟蹤的顆粒度越細(xì)，工作量越大 作為項(xiàng)目經(jīng)理，如果你跟蹤到每行代碼，你會(huì)抱怨“還不如自己開(kāi)發(fā)”，你就又把工程做成了“藝術(shù)”。 記錄這些偏差(進(jìn)度、工作量、費(fèi)用等) 避免太頻繁的干涉細(xì)小的偏差 用經(jīng)驗(yàn)，使其偏差在容忍的范圍內(nèi) 如果一個(gè)項(xiàng)目的報(bào)告中講，進(jìn)度和質(zhì)量(缺陷)沒(méi)有任何的偏差，這篇報(bào)告極可

27、能就是假的。 如果每天都開(kāi)評(píng)審會(huì)議，額外工作量將引起員工的疲憊，導(dǎo)致代碼或文檔質(zhì)量的下降軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生Software Quality Assurance軟件質(zhì)量保證(SQA)軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生軟件質(zhì)量保證 當(dāng)“哥們式”的生產(chǎn)關(guān)系被打破后 就需要建立一套制度，以便于： 1) 尋找擺脫繁雜的管理工作的方法，使得經(jīng)理們有更多的時(shí)間開(kāi)展或監(jiān)督員工的開(kāi)發(fā)工作； 2) 雇傭一些人做審計(jì)工作； 3) 鼓勵(lì)員工相互監(jiān)督質(zhì)量。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生質(zhì)量管理過(guò)程與開(kāi)發(fā)過(guò)程的獨(dú)立性 軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生過(guò)程質(zhì)量觀點(diǎn)對(duì)于制造類的產(chǎn)品，過(guò)程與產(chǎn)品質(zhì)量具有直接的關(guān)聯(lián)

28、關(guān)系對(duì)于軟件，問(wèn)題要復(fù)雜的多，因?yàn)?個(gè)人能力和經(jīng)驗(yàn)的重要性外部因素，如，新的發(fā)明，進(jìn)度加快等，都會(huì)導(dǎo)致質(zhì)量問(wèn)題.統(tǒng)計(jì)學(xué)的質(zhì)量控制方法，對(duì)于軟件是適用的軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生過(guò)程質(zhì)量觀點(diǎn)定義過(guò)程開(kāi)發(fā)產(chǎn)品評(píng)估產(chǎn)品質(zhì)量質(zhì)量OK？改進(jìn)開(kāi)發(fā)過(guò)程標(biāo)準(zhǔn)過(guò)程軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生定義標(biāo)準(zhǔn)，如:評(píng)審規(guī)則配置管理等監(jiān)督開(kāi)發(fā)過(guò)程，保證標(biāo)準(zhǔn)得到執(zhí)行將質(zhì)量報(bào)告給項(xiàng)目管理和軟件購(gòu)買者實(shí)施過(guò)程中的質(zhì)量軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生定義標(biāo)準(zhǔn)是進(jìn)行有效質(zhì)量管理的關(guān)鍵國(guó)際、國(guó)家、企業(yè)、項(xiàng)目標(biāo)準(zhǔn)項(xiàng)目管理者的重點(diǎn)是剪裁和定義出適合項(xiàng)目的標(biāo)準(zhǔn)產(chǎn)品標(biāo)準(zhǔn)(Product standards) 定義軟件部件的特性，如編

29、程風(fēng)格。過(guò)程標(biāo)準(zhǔn)(Process standards) 定義軟件的開(kāi)發(fā)過(guò)程質(zhì)量保證和標(biāo)準(zhǔn)軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生 采納最好的實(shí)踐，避免錯(cuò)誤的重復(fù) 質(zhì)量保證過(guò)程框架， 檢查標(biāo)準(zhǔn)的兼容性 連續(xù)性 新員工可以很好地理解組織的規(guī)定、項(xiàng)目的規(guī)定標(biāo)準(zhǔn)的重要性軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生產(chǎn)品和過(guò)程標(biāo)準(zhǔn)例子軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生軟件質(zhì)量保證的目標(biāo) 1) 軟件質(zhì)量保證活動(dòng)是有計(jì)劃的。 2) 軟件產(chǎn)品及其活動(dòng)遵循所用的標(biāo)準(zhǔn)、規(guī)程和需求的情況得到客觀的驗(yàn)證。 3) 受影響的組和個(gè)人接到軟件質(zhì)量保證活動(dòng)和結(jié)果的通知。 4) 高層管理者處理軟件項(xiàng)目?jī)?nèi)部無(wú)法解決的不符合問(wèn)題。軟件過(guò)程改進(jìn)方法與實(shí)踐案

30、例王安生對(duì)SQA的誤解 1) 把SQA的工作簡(jiǎn)單地等同于軟件測(cè)試工作。當(dāng)軟件質(zhì)量問(wèn)題比較大時(shí)，認(rèn)為是測(cè)試人員測(cè)試不夠所引起的。 這種觀點(diǎn)忘記了“測(cè)試只能表明程序的錯(cuò)誤，而不能證明程序正確”的論斷。 2) 把SQA作為一種擺設(shè)，只是對(duì)外部客戶的宣稱，讓新來(lái)的員工擔(dān)任就行。 這種觀點(diǎn)，削弱了SQA應(yīng)當(dāng)承擔(dān)的過(guò)程可視性的作用。 3) 認(rèn)為SQA人員要解決一切質(zhì)量問(wèn)題。SQA人員要做所有的評(píng)審、測(cè)試等工作。 這種觀點(diǎn)，將SQA人員的工作過(guò)度理想化。 4) 除非開(kāi)發(fā)經(jīng)理要求SQA幫助做些工作，否則SQA就不管開(kāi)發(fā)的事。 這種觀點(diǎn)，將使得SQA不能發(fā)揮作用，長(zhǎng)此以往，軟件開(kāi)發(fā)隊(duì)伍將逐步退化為黑箱式的開(kāi)發(fā)狀

31、態(tài)(回到CMM一級(jí)所描述的混亂狀態(tài))。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生SQA責(zé)任 建立SQA制度和小組，并要確保SQA能夠： 1) 評(píng)審所有(或抽檢)的開(kāi)發(fā)計(jì)劃和質(zhì)量計(jì)劃是否完整 2) 作為審查的協(xié)調(diào)人，參加設(shè)計(jì)和代碼的審查； 3) 評(píng)審所有的測(cè)試計(jì)劃，是否遵循標(biāo)準(zhǔn)； 4) 對(duì)重要的測(cè)試結(jié)果進(jìn)行評(píng)審，確定是否符合計(jì)劃要求； 5) 定期對(duì)SCM的工作和性能進(jìn)行評(píng)審，確定是否符合標(biāo)準(zhǔn)； 6) 定期參加所有項(xiàng)目的階段評(píng)審，確認(rèn)標(biāo)準(zhǔn)和規(guī)程是否得到合理的滿足。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生SQA人員培養(yǎng) SQA的重要性是由承擔(dān)SQA工作人員所擔(dān)負(fù)的。 SQA人員的挑選和培養(yǎng)對(duì)于企業(yè)是十分重要的。這就像

32、國(guó)家的審計(jì)人員一樣，需要從“德”和“技”兩個(gè)方面挑選和培養(yǎng)SQA人員。 一種可能的解決方案是，讓那些準(zhǔn)備提升的項(xiàng)目經(jīng)理，在上任前擔(dān)當(dāng)一段SQA工作； 或者，讓項(xiàng)目經(jīng)理與SQA人員進(jìn)行互換。這種方法可以確保開(kāi)發(fā)隊(duì)伍和SQA人員的相互理解，增強(qiáng)共同合作的精神。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生Software Configuration Management軟件配置管理(SCM)軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生 配置管理(Configuration Management) 更準(zhǔn)確的應(yīng)當(dāng)稱為：配置項(xiàng)管理，也就是對(duì)生產(chǎn)過(guò)程中能夠單獨(dú)存在、功能獨(dú)立的項(xiàng)進(jìn)行有效的管理。 例如，可獨(dú)立配置的軟件項(xiàng)、部件、單元

33、、數(shù)據(jù)文件及其操作等。 配置管理并不是軟件行業(yè)的發(fā)明。在現(xiàn)代工業(yè)生產(chǎn)中，最成熟配置管理也許是機(jī)械行業(yè)。 那里的配置項(xiàng)是：一個(gè)部件、一臺(tái)發(fā)動(dòng)機(jī)、一個(gè)螺釘?shù)龋?例如，在汽車行業(yè)的研發(fā)、生產(chǎn)、使用和維護(hù)。特別是為汽車使用安全所建立的缺陷招回制度，是對(duì)配置管理成功的應(yīng)用。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生建立SCM的需要 在軟件的開(kāi)發(fā)和使用，同樣存在配置管理問(wèn)題。隨著企業(yè)規(guī)模的擴(kuò)大，所承擔(dān)的項(xiàng)目越來(lái)越多。 如果每個(gè)項(xiàng)目都從第一行代碼編起，也許這家公司永遠(yuǎn)也沒(méi)法獲得利潤(rùn)。 有效的方法是建立可以重復(fù)使用的軟件庫(kù)。 事實(shí)上，我們?cè)诔绦蜷_(kāi)發(fā)中基本上都在使用其他人已經(jīng)做好的軟件庫(kù)，進(jìn)行軟件的開(kāi)發(fā)。 例如，我們使用

34、C語(yǔ)言編程時(shí)，一旦需要使用數(shù)學(xué)庫(kù)，我們只需要在程序中寫上#include ，就意味著，我們使用編譯產(chǎn)品廠家提供的數(shù)學(xué)庫(kù)。因此，我們不用再編寫sin(x)、log(x)等的程序。 在C語(yǔ)言的編程中，可能最普遍使用的是#include 。stdio（標(biāo)準(zhǔn)輸入輸出）庫(kù)提供了最基本的輸入輸出，例如，printf等。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生建立SCM的需要 要做到項(xiàng)目的可重復(fù)，最基本的做法也是盡可能地重復(fù)使用其他人做好的或先前項(xiàng)目使用過(guò)的代碼。即，建立可重用庫(kù)，從項(xiàng)目上做到對(duì)代碼的重用。 重用庫(kù)的代碼可以是二進(jìn)制目標(biāo)碼的形式，也可以是源代碼的形式。 可重用的運(yùn)行庫(kù)，既可以是靜態(tài)庫(kù)，也可以是動(dòng)態(tài)庫(kù)

35、。 靜態(tài)庫(kù)中提供的函數(shù)功能，在進(jìn)行連接(link)時(shí)，被加入到可執(zhí)行程序中。而動(dòng)態(tài)庫(kù)在連接(link)時(shí)，只是說(shuō)明了庫(kù)函數(shù)加載的地址，只有在運(yùn)行時(shí)才加載。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生必須建立新的軟件版本，隨著下面因素的變化：不用的硬件和OS；提供不同的功能；針對(duì)客戶需求的定制和剪裁。配置管理涉及到對(duì)軟件進(jìn)化的管理系統(tǒng)更改時(shí)一個(gè)團(tuán)隊(duì)活動(dòng)；CM的目的 之一是控制軟件更改中所產(chǎn)生的費(fèi)用和工作量軟件版本變更軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生建立SCM的需要 1) 軟件的需求是不斷變化，從而導(dǎo)致主要功能一樣的軟件可具有多個(gè)版本； 2) 軟件中的錯(cuò)誤，導(dǎo)致軟件版本的不斷升級(jí)； 3) 一段代碼是多個(gè)程序員

36、共同完成的，某個(gè)人對(duì)自己那塊代碼的修改，可能引起整個(gè)或其他人的代碼的錯(cuò)誤。 4) 代碼被大家共享，一旦修改，而沒(méi)有通知到其他使用者，版本的管理就會(huì)出錯(cuò)； 5) 企業(yè)的許多客戶已經(jīng)在使用我們的軟件，而每個(gè)客戶可能使用的版本都不一樣。企業(yè)需要保留和維護(hù)每個(gè)客戶的版本，從而造成人力資源(越來(lái)越多的維護(hù)工程師)的極大浪費(fèi)。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生SCM的步驟 1）確定被管理的對(duì)象（級(jí)別等）確定被管理的對(duì)象（級(jí)別等） 2）管理（入庫(kù)、修改等）的權(quán)限）管理（入庫(kù)、修改等）的權(quán)限 3）給被管理對(duì)象唯一的一個(gè)編號(hào)）給被管理對(duì)象唯一的一個(gè)編號(hào)(標(biāo)識(shí)號(hào)標(biāo)識(shí)號(hào)) 4）控制對(duì)被管理對(duì)象的修改）控制對(duì)被管理對(duì)象

37、的修改 5）跟蹤和記錄其修改）跟蹤和記錄其修改軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生實(shí)現(xiàn)SCM的關(guān)鍵 首先，首先，要搞清被管理的項(xiàng)。依據(jù)管理的精細(xì)度，一個(gè)被管理項(xiàng)可以劃分為一個(gè)軟件系統(tǒng)或子系統(tǒng)、一個(gè)計(jì)算機(jī)軟件配置項(xiàng)(CSCI)、一個(gè)計(jì)算機(jī)軟件部件(SC)、一個(gè)計(jì)算軟件單元(CSU)，甚至是一段關(guān)鍵的核心代碼。 除此之外，被管理項(xiàng)還應(yīng)當(dāng)包括相關(guān)的軟件開(kāi)發(fā)、使用和維護(hù)性的文檔，以及開(kāi)發(fā)環(huán)境、運(yùn)行環(huán)境等。 一旦確定或定義了被管理項(xiàng)，就要給其一個(gè)唯一的標(biāo)識(shí)號(hào)(ID)。這個(gè)ID應(yīng)當(dāng)在其生命周期里是始終有效的，且是唯一的。 唯一性能夠讓用此軟件項(xiàng)進(jìn)行項(xiàng)目開(kāi)發(fā)的開(kāi)發(fā)人員、使用人員和維護(hù)人員，能夠依據(jù)ID正確識(shí)別被

38、管理的項(xiàng)。這就像社會(huì)管理部門要分發(fā)給每個(gè)人一個(gè)身份證號(hào)一樣。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生實(shí)現(xiàn)SCM的關(guān)鍵 其次，其次，對(duì)被管理項(xiàng)建立了唯一標(biāo)識(shí)號(hào)后，接下來(lái)的問(wèn)題是如何控制對(duì)被管理項(xiàng)的狀態(tài)和修改。 例如，在交通管理中，汽車作為被管理項(xiàng)。交通部門給每輛汽車一個(gè)牌號(hào)，并對(duì)汽車的發(fā)動(dòng)機(jī)編號(hào)、車架的編號(hào)也進(jìn)行登記備案。其目的是防止對(duì)汽車在其生命周期內(nèi)輕易地更改，以便于控制 對(duì)于被管理的軟件項(xiàng)，同樣要控制其更改。與汽車中的配置項(xiàng)更改不同的是，軟件的更改不僅是本軟件開(kāi)發(fā)者的事情，還會(huì)涉及所有使用此軟件項(xiàng)的軟件系統(tǒng)、使用者、相關(guān)的程序員。 另一方面，軟件代碼的修改可見(jiàn)性(例如，比汽車牌號(hào)等修改的可見(jiàn)性)差

39、。人們很難發(fā)現(xiàn)被修改的代碼，以及無(wú)法估計(jì)所修改的代碼會(huì)產(chǎn)生多大的影響(包括正面和負(fù)面的)。 因此在企業(yè)中，最好的方法是建立一個(gè)更改控制委員會(huì)(CCB)，站在企業(yè)的高度審視和評(píng)審各種修改，把修改所帶來(lái)的負(fù)面影響降到最低。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生 再者，再者，人們的記憶能力是有限的。解決的方法是對(duì)任何軟件項(xiàng)的修改、委員會(huì)決定是否修改的意見(jiàn)、以及與修改相關(guān)的各種情況進(jìn)行記錄與存檔。 以便，人們能夠?qū)π薷倪^(guò)程進(jìn)行評(píng)審和回顧。 綜合上述，我們看到，實(shí)現(xiàn)配置管理里的關(guān)鍵是：標(biāo)識(shí)（被管理的項(xiàng)）、控制（其標(biāo)識(shí)（被管理的項(xiàng)）、控制（其修改）、記錄（其狀態(tài)）修改）、記錄（其狀態(tài)）。軟件過(guò)程改進(jìn)方法與實(shí)踐案

40、例王安生SCM的流程 標(biāo)識(shí)（被管理的項(xiàng)）、控制（其修改）、記錄（其狀態(tài)）標(biāo)識(shí)（被管理的項(xiàng)）、控制（其修改）、記錄（其狀態(tài)） 建立新的基線 將確認(rèn)的更改入庫(kù) 提取官方版本 更改請(qǐng)求單 源/目標(biāo)碼/ 文檔/工具等 產(chǎn)品基線庫(kù) 更改庫(kù) 需求/設(shè)計(jì)/使用 建立/修改基線 確認(rèn)基線 CCB：授權(quán) 開(kāi)發(fā)組： 實(shí)現(xiàn)更改 確認(rèn)更改 CCB：批準(zhǔn)更改 初始 版本產(chǎn)品 軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生 更改庫(kù)，則要存放確認(rèn)的更改，包括： 1) 每個(gè)模塊的修改層次。 2) 所使用的匯編器、編譯器、連接器、裝載程序以及可執(zhí)行程序和測(cè)試。 3) 測(cè)試用例和修改層次。 4) 測(cè)試數(shù)據(jù)。 5) 所使用的文件。 6) 組成系

41、統(tǒng)的軟件、硬件、外圍設(shè)備以及硬件的更改層次。 7) 操作和使用過(guò)程。 8) 如果有非單獨(dú)的測(cè)試，還要給出執(zhí)行的(批命令)流程。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生 配置管理的顆粒度 顆粒度的定義要考慮下列幾個(gè)主要因素： 1) 代碼的重要性。 2) 模塊的大小。 3) 企業(yè)的人力資源狀況。 4) 產(chǎn)品的研發(fā)周期等。 顆粒度可以簡(jiǎn)單地劃分為：重用庫(kù)級(jí)的、部件級(jí)的、單元級(jí)的。軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生配置管理級(jí)別和工作量CSCICSCCSCCSUCSCCSUCSCCSCCSCCSUCSU庫(kù)非開(kāi)發(fā)軟件SystemCSCICSCI單元單元/語(yǔ)句級(jí)別語(yǔ)句級(jí)別部件部件/庫(kù)級(jí)別庫(kù)級(jí)別配置項(xiàng)級(jí)別配置項(xiàng)級(jí)別系統(tǒng)級(jí)別系統(tǒng)級(jí)別管理工作量管理工作量小小大大軟件過(guò)程改進(jìn)方法與實(shí)踐案例王安生版本的標(biāo)識(shí) 版本標(biāo)識(shí)的規(guī)程，確保所標(biāo)識(shí)的部件版本沒(méi)有二義性 是那種基本方法： 版本編號(hào)(Version numbering); 屬