軟件開發(fā)規(guī)范與開發(fā)流程實(shí)施

軟件開發(fā)標(biāo)準(zhǔn)

&

開發(fā)流程實(shí)施中山市森創(chuàng)公司軟件開發(fā)什么是軟件工程完成特定目的、符合用戶特定需求的軟件所需的組織結(jié)構(gòu)和過程、標(biāo)準(zhǔn)的集合軟件工程的實(shí)施需要周密的部署，合理的規(guī)章制度，符合工程的路線〔軟件過程〕，良好的工程管理和人員安排。相關(guān)流程軟件管理特點(diǎn)軟件生命周期過程確定需求開發(fā)規(guī)劃需求分析概要設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼與調(diào)試測試軟件集成、聯(lián)調(diào)內(nèi)部確認(rèn)復(fù)制、交付、安裝試運(yùn)行、用戶驗(yàn)收運(yùn)行、維護(hù)退役軟件管理配置與變更管理環(huán)境、工具和技術(shù)有關(guān)軟件的法規(guī)和標(biāo)準(zhǔn)周密籌劃以保證軟件管理特點(diǎn)軟件產(chǎn)品的特點(diǎn)軟件產(chǎn)品的質(zhì)量，完全取決于其設(shè)計(jì)和開發(fā)水平軟件需求的模糊性、變化性使軟件產(chǎn)品難以成熟任何一個(gè)軟件產(chǎn)品，或多或少總會(huì)存在一些故障(BUG)軟件人員廣泛存在的不標(biāo)準(zhǔn)的開發(fā)習(xí)慣使開發(fā)過程難以管理軟件質(zhì)量指標(biāo)難以量化軟件測試?yán)碚摵图夹g(shù)尚未解決軟件產(chǎn)品正確性的驗(yàn)證問題軟件產(chǎn)品質(zhì)量特性：滿足需求能力的一系列特性總和功能、可靠性、易用性、效率、維護(hù)性、可移植性軟件管理必須在市場(用戶)需求和軟件成熟性之間進(jìn)行權(quán)衡軟件生命周期過程確定需求開發(fā)規(guī)劃需求分析概要設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼與調(diào)試測試軟件集成、聯(lián)調(diào)內(nèi)部確認(rèn)復(fù)制、交付、安裝試運(yùn)行、用戶驗(yàn)收運(yùn)行、維護(hù)退役確定需求確定外部用戶需求上級下達(dá)的軟件開發(fā)課題本單位根據(jù)市場需要確定的開發(fā)課題用戶合同要求的軟件開發(fā)任務(wù)輸出可行性分析報(bào)告技術(shù)、經(jīng)濟(jì)、社會(huì)可行性，風(fēng)險(xiǎn)對策合同及評審記錄產(chǎn)品要求得到規(guī)定和滿足單位有能力滿足規(guī)定的要求開發(fā)規(guī)劃確定開發(fā)目標(biāo)確定工程開發(fā)的技術(shù)路線(開發(fā)的出發(fā)基線、對現(xiàn)有產(chǎn)品的復(fù)用、委托開發(fā)等)確定應(yīng)遵循的標(biāo)準(zhǔn)、法律和法規(guī)選任開發(fā)工程經(jīng)理劃分開發(fā)階段確定各階段的輸入和輸出文件確定質(zhì)量控制點(diǎn)(評審點(diǎn)、驗(yàn)證點(diǎn)和確認(rèn)點(diǎn))及其實(shí)施的責(zé)任人、實(shí)施方式等設(shè)計(jì)工程開發(fā)進(jìn)度確定開發(fā)人員并分配職責(zé)提出開發(fā)所需資源(軟件、硬件開發(fā)環(huán)境及工具軟件、設(shè)備、資金等)要求并予以落實(shí)制定配置管理方案和質(zhì)量保證方案開發(fā)規(guī)劃(續(xù))輸出籌劃報(bào)告開發(fā)工程實(shí)施方案配置管理方案質(zhì)量保證方案等需求分析確保工程的開發(fā)符合用戶的需求(可測試性)確定設(shè)計(jì)輸入任務(wù)委托書/招標(biāo)書前期對用戶的需求調(diào)研資料可行性分析報(bào)告/投標(biāo)書合同等編制內(nèi)部需求規(guī)格(說明)書需求變更控制需求的層次業(yè)務(wù)需求、用戶需求和功能需求概要設(shè)計(jì)確保產(chǎn)品的總體結(jié)構(gòu)和模塊間的關(guān)系與用戶需求的一致性內(nèi)容總體方案設(shè)計(jì)邏輯框圖接口及通訊協(xié)議選用現(xiàn)有產(chǎn)品軟件的選用邊界(約束)條件的設(shè)計(jì)運(yùn)行環(huán)境設(shè)計(jì)等輸出概要設(shè)計(jì)說明書詳細(xì)設(shè)計(jì)詳細(xì)設(shè)計(jì)說明書與概要設(shè)計(jì)說明書是否相一致內(nèi)容原型設(shè)計(jì)〔可選〕算法設(shè)計(jì)數(shù)據(jù)格式設(shè)計(jì)實(shí)現(xiàn)流程設(shè)計(jì)人機(jī)界面設(shè)計(jì)測試用例設(shè)計(jì)操作設(shè)計(jì)等輸出詳細(xì)設(shè)計(jì)說明書軟件組裝方案測試方案及測試用例安裝手冊(初稿)使用說明書(初稿)產(chǎn)品標(biāo)準(zhǔn)(初稿)編碼與調(diào)試內(nèi)容編寫程序代碼：源代碼→目標(biāo)代碼→可執(zhí)行代碼此階段還包括局部軟件模塊的局部測試、集成與聯(lián)調(diào)根據(jù)待開發(fā)軟件的規(guī)模、控制點(diǎn)及人員安排，可細(xì)分為多個(gè)小階段輸出軟件(源代碼、目標(biāo)代碼、可執(zhí)行代碼及相關(guān)數(shù)據(jù)文件)文檔(幫助文件等)遵循?編碼標(biāo)準(zhǔn)?，保證編碼風(fēng)格的一致性，易讀性；增強(qiáng)軟件源碼的可維護(hù)性測試按測試發(fā)生的順序劃分模塊測試：是對單個(gè)軟件模塊的測試單元測試：是對各個(gè)軟件功能單元的測試組裝測試：是對各軟件單元之間的互聯(lián)測試集成測試：是對硬件裝置、設(shè)備和軟件的參加性測試系統(tǒng)測試：工程組所在部門組織的對完成集成的系統(tǒng)的測試(是否滿足產(chǎn)品規(guī)格要)壓力測試：是對軟件的整體經(jīng)受超大訪問量壓力下能否保證平安、正確運(yùn)行的測試確認(rèn)測試：單位質(zhì)量控制部門進(jìn)行的測試(是否滿足產(chǎn)品規(guī)格要求)驗(yàn)收測試：在現(xiàn)場安裝、調(diào)試結(jié)束并經(jīng)試運(yùn)行后，與顧客一起，就滿足合同情況進(jìn)行的測試(是否滿足合同要求)ISO9001

&

CMMISO9001&CMM什么是ISO9001？ISO9001是ISO9000族標(biāo)準(zhǔn)所包括的一組質(zhì)量管理體系核心標(biāo)準(zhǔn)之一。ISO9000族標(biāo)準(zhǔn)是國際標(biāo)準(zhǔn)化組織〔ISO〕在1994年提出的概念，是指“由ISO/TC176〔國際標(biāo)準(zhǔn)化組織質(zhì)量管理和質(zhì)量保證技術(shù)委員會(huì)〕制定的國際標(biāo)準(zhǔn)。ISO9001質(zhì)量管理體系不是專門針對軟件開發(fā)的，還可以實(shí)施到其它行業(yè)比方生產(chǎn)、教育等。ISO9001質(zhì)量管理體系在軟件開發(fā)中，對軟件開發(fā)過程進(jìn)行嚴(yán)格的質(zhì)量控制。這個(gè)過程需要由企業(yè)本身和ISO審查小組聯(lián)合進(jìn)行質(zhì)量控制，分為內(nèi)審和外審。內(nèi)審：由企業(yè)內(nèi)部成立一個(gè)專門的質(zhì)量控制小組〔需經(jīng)過培訓(xùn)〕，參與到軟件開發(fā)的整個(gè)流程〔從立項(xiàng)到產(chǎn)品交付〕的文檔審查和質(zhì)量控制中。外審：由ISO審查小組派專員到企業(yè)中，對企業(yè)的軟件開發(fā)過程進(jìn)行審查〔只要審核各個(gè)流程生成的相關(guān)文檔是否齊備，符合標(biāo)準(zhǔn)等。還有能軟、硬件設(shè)施和人員也有一定的要求〕。ISO審查專員需要具備ISO9000外審員資格證書。ISO9001&CMM什么是CMM？

軟件能力成熟度模型(CapabilityMaturityModelForSoftware,簡稱SW-CMM/CMMI),是由美國卡內(nèi)基梅隆大學(xué)軟件工程研究所(CMUSEI)研究出的一種用于評價(jià)軟件承包商能力并幫助改善軟件質(zhì)量的方法，其目的是幫助軟件企業(yè)對軟件工程過程進(jìn)行管理和改進(jìn)，增強(qiáng)開發(fā)與改進(jìn)能力，從而能按時(shí)地、不超預(yù)算地開發(fā)出高質(zhì)量的軟件。CapabilityMaturityModel

軟件能力成熟度模型迄今為止學(xué)術(shù)界和工業(yè)界公認(rèn)的有關(guān)軟件工程和管理實(shí)踐的最好的評價(jià)模型。為評估軟件組織的生產(chǎn)能力提供了標(biāo)準(zhǔn)。為提高軟件組織的生產(chǎn)過程指明了方向。CMM五級軟件開發(fā)模型軟件開發(fā)模型統(tǒng)一軟件開發(fā)過程

&敏捷開發(fā)統(tǒng)一軟件開發(fā)過程&敏捷開發(fā)什么是統(tǒng)一軟件開發(fā)過程?RUP〔RationalUnifiedProcess，統(tǒng)一軟件開發(fā)過程，統(tǒng)一軟件過程)是一個(gè)面向?qū)ο笄一诰W(wǎng)絡(luò)的程序開發(fā)方法論。根據(jù)Rational(RationalRose和統(tǒng)一建模語言的開發(fā)者)的說法，好似一個(gè)在線的指導(dǎo)者，它可以為所有方面和層次的程序開發(fā)提供指導(dǎo)方針，模版以及事例支持。RUP和類似的產(chǎn)品--例如面向?qū)ο蟮能浖^程〔OOSP〕，以及OPENProcess都是理解性的軟件工程工具--把開發(fā)中面向過程的方面〔例如定義的階段，技術(shù)和實(shí)踐〕和其他開發(fā)的組件〔例如文檔，模型，手冊以及代碼等等〕整合在一個(gè)統(tǒng)一的框架內(nèi)。統(tǒng)一軟件開發(fā)過程用例驅(qū)動(dòng)用例:能向用戶提供有價(jià)值的系統(tǒng)的某種功能以架構(gòu)為中心軟件架構(gòu)：系統(tǒng)的最重要的靜態(tài)和動(dòng)態(tài)特征迭代和增量式迭代：工作流程的重復(fù)、每次的活動(dòng)都以上次的活動(dòng)為根底用例驅(qū)動(dòng)用戶所希望和需要的是什么系統(tǒng)能為每個(gè)用戶提供什么功能用例所描述和代表的是用戶與系統(tǒng)交互的一個(gè)過程，而這個(gè)過程滿足了用戶的某些需求所強(qiáng)調(diào)的是系統(tǒng)的功能以架構(gòu)為中心刻畫了系統(tǒng)的整體設(shè)計(jì)，忽略了細(xì)節(jié)設(shè)計(jì)，刻畫最重要的局部。什么是最重要的呢？依賴于判斷。判斷的依據(jù)是經(jīng)驗(yàn)。構(gòu)架的設(shè)計(jì)價(jià)值取決于執(zhí)行該任務(wù)的人的素質(zhì)受用戶需求〔用戶可能會(huì)增加那方面的需求〕、軟件應(yīng)用平臺(tái)〔計(jì)算機(jī)硬件、操作系統(tǒng)、數(shù)據(jù)庫、網(wǎng)絡(luò)等〕、實(shí)施問題、遺留系統(tǒng)集成等的影響用例和架構(gòu)用例是系統(tǒng)的功能和外衣架構(gòu)是系統(tǒng)的內(nèi)在形式兩方面必須并行進(jìn)化架構(gòu)只考慮核心功能(5-10%)架構(gòu)設(shè)計(jì)原那么：先考慮與用例無關(guān)的不會(huì)變動(dòng)的方面考慮考慮最重要的功能需求子集迭代和增量式控制迭代過程，劃分每次迭代的目標(biāo)迭代原那么：架構(gòu)上先實(shí)現(xiàn)最粗略的局部功能上先實(shí)現(xiàn)最重要的每次迭代盡可能的劃分的細(xì)，迭代數(shù)量不能太少每次迭代要有標(biāo)準(zhǔn)的檢查機(jī)制增量式每次迭代增加一局部設(shè)計(jì)和實(shí)現(xiàn)統(tǒng)一軟件開發(fā)過程&敏捷開發(fā)什么是敏捷開發(fā)？2001年，為了解決許多公司的軟件團(tuán)隊(duì)陷入不斷增長的過程泥潭，一批業(yè)界專家一起概括出了一些可以讓軟件開發(fā)團(tuán)隊(duì)具有快速工作、響應(yīng)變化能力的價(jià)值觀和原那么，他們稱自己為敏捷聯(lián)盟。敏捷開發(fā)過程的方法很多，主要有：SCRUM，Crystal,特征驅(qū)動(dòng)軟件開發(fā)〔FeatureDrivenDevelopment，簡稱FDD〕，自適應(yīng)軟件開發(fā)(AdaptiveSoftwareDevelopment，簡稱ASD)，以及最重要的極限編程(eXtremeProgramming,簡稱XP)。極限編程(XP)是于1998年由Smalltalk社群中的大師級人物KentBeck首先倡導(dǎo)的。敏捷開發(fā)快速適應(yīng)系統(tǒng)需求的變化提高軟件生產(chǎn)率突出企業(yè)自身特點(diǎn)，表達(dá)企業(yè)核心能力支持動(dòng)態(tài)聯(lián)盟和虛擬組織面向業(yè)務(wù)目標(biāo)持續(xù)改進(jìn)和重組敏捷軟件開發(fā)宣言個(gè)體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應(yīng)變化勝過遵循方案敏捷開發(fā)的特征輕量級的開發(fā)過程基于時(shí)間JustEnough并行基于組件的軟件工程敏捷開發(fā)過程軟件的需求是難以預(yù)期的，開發(fā)方法必需適應(yīng)變化的需求，在快速的迭代中不斷改進(jìn)小組成員并不完全按照完整的方法進(jìn)行開發(fā)，而根據(jù)具體問題和情況，靈活地去除非增值活動(dòng)僅僅執(zhí)行一些必須的活動(dòng)，使用必須的規(guī)那么，編寫必須的文檔人的因素被放在第一適合互聯(lián)網(wǎng)時(shí)代的開發(fā)要求主要敏捷開發(fā)方法eXtremeProgramming(XP)SCRUMDSDMAdaptiveSoftwareDevelopment(ASD)FeatureDrivenDevelopment(FDD)CrystalFamilyRationalRUP&UML軟件開發(fā)標(biāo)準(zhǔn)軟件開發(fā)標(biāo)準(zhǔn)開發(fā)標(biāo)準(zhǔn)的作用1)開發(fā)標(biāo)準(zhǔn)作用于團(tuán)隊(duì)開發(fā)內(nèi)部，保證不同的開發(fā)人員在工作環(huán)境設(shè)定，代碼開發(fā)標(biāo)準(zhǔn)以及日常開發(fā)的行為能夠到達(dá)共通的要求。2)開發(fā)標(biāo)準(zhǔn)用于開發(fā)的各個(gè)階段，保證開發(fā)中的各個(gè)問題能夠按照開發(fā)制定的標(biāo)準(zhǔn)進(jìn)行處理〔比方：代碼管理，版本沖突，代碼命名標(biāo)準(zhǔn)等等〕。3)開發(fā)標(biāo)準(zhǔn)作為最終開發(fā)產(chǎn)品代碼的檢測標(biāo)準(zhǔn),通過對最終產(chǎn)品代碼的再次檢測，來保證代碼的標(biāo)準(zhǔn)性，可維護(hù)性。開發(fā)標(biāo)準(zhǔn)作為開發(fā)中的檢測標(biāo)準(zhǔn)，來約束開發(fā)人員的開發(fā)行為，到達(dá)在團(tuán)隊(duì)內(nèi)部提高開發(fā)質(zhì)量和減少開發(fā)本錢的作用。軟件開發(fā)標(biāo)準(zhǔn)開發(fā)標(biāo)準(zhǔn)的要求1)制定開發(fā)時(shí)要求對于要求的內(nèi)容必須語義清晰，確保所制定的內(nèi)容不會(huì)有歧義發(fā)生。2)對于開發(fā)中說明性的內(nèi)容，以圖片說明為主，減少文字性的描述。3)對于開發(fā)標(biāo)準(zhǔn)防止在工程開發(fā)后發(fā)生對代碼命名，代碼邏輯分層等局部內(nèi)容的變更。4)如果開發(fā)標(biāo)準(zhǔn)發(fā)生變更，確保工程團(tuán)隊(duì)內(nèi)部所有的人員都按照最新的開發(fā)標(biāo)準(zhǔn)進(jìn)行開發(fā)。5)對于開發(fā)標(biāo)準(zhǔn)也要求進(jìn)行版本管理。開發(fā)標(biāo)準(zhǔn)的內(nèi)容〔一〕1)開發(fā)平臺(tái)的約定a)開發(fā)操作系統(tǒng)環(huán)境和最總用戶使用環(huán)境〔包含ServicePack版本號(hào)〕b)開發(fā)工具版本c)數(shù)據(jù)庫類型已經(jīng)版本d)網(wǎng)絡(luò)狀態(tài)e)版本控制工具f)開發(fā)使用硬件環(huán)境和組成g)開發(fā)標(biāo)準(zhǔn)的執(zhí)行問題開發(fā)標(biāo)準(zhǔn)的內(nèi)容〔二〕2)工作方式的約定a)開始工作前的行為〔每天開始工作先CheckOut代碼〕b)工作結(jié)束后的行為〔每天結(jié)束后需要CheckIn全部代碼〕c)版本控制行為〔代碼CheckIn的要求和發(fā)生沖突的解決方法〕d)文件保存要求〔新增代碼文件和備份文件的處理〕開發(fā)標(biāo)準(zhǔn)的內(nèi)容〔三〕3)代碼書寫約定a)代碼的命名規(guī)那么b)代碼的注釋要求c)代碼的修改履歷要求d)代碼的文件保存要求〔一個(gè)類保存在一個(gè)文件中等〕e)代碼的外觀要求〔代碼的對齊，換行要求〕f)數(shù)據(jù)庫代碼的書寫要求開發(fā)標(biāo)準(zhǔn)的內(nèi)容〔四〕4)程序的結(jié)構(gòu)約定

a)通用代碼的處理方式

b)接口的處理方式

c)代碼的內(nèi)部的邏輯劃分要求

d)程序的分層結(jié)構(gòu)要求

e)程序的異常處理要求開發(fā)標(biāo)準(zhǔn)的內(nèi)容〔五〕5)輔助工具的使用約定

a)版本控制工具使用說明

b)代碼生成工具的使用說明

c)單元測試工具的使用說明

d)Bug管理工具的使用說明開發(fā)標(biāo)準(zhǔn)的內(nèi)容〔六〕6)其他約定a)單元測試方法約定b)版本控制約定c)方案管理約定d)測試數(shù)據(jù)的約定開發(fā)標(biāo)準(zhǔn)的執(zhí)行問題1)制定問題a)鼓勵(lì)全部的工程開發(fā)人員都參與標(biāo)準(zhǔn)的制定b)制定標(biāo)準(zhǔn)是需要考慮代碼的維護(hù)性和實(shí)際開發(fā)的便利性2)執(zhí)行問題a)依照開發(fā)標(biāo)準(zhǔn)對于代碼進(jìn)行檢測，對于存在問題要求修正。b)通過團(tuán)隊(duì)內(nèi)部人員交叉檢測的方式來執(zhí)行開發(fā)標(biāo)準(zhǔn)版本控制工具的使用使用VSS〔VisualSourceSafe〕作為版本控制工具。工程配置的根本目錄結(jié)構(gòu)根據(jù)具體的工程設(shè)置配置庫的根本目錄結(jié)構(gòu)，并進(jìn)行根本的解釋，一般可以包含以下的一級目錄及二級目錄：01工程工作庫01準(zhǔn)備階段02需求分析階段03系統(tǒng)設(shè)計(jì)階段04系統(tǒng)實(shí)現(xiàn)階段--源代碼安放在此目錄05系統(tǒng)測試階段06運(yùn)行推廣階段07系統(tǒng)維護(hù)階段02工程管理庫01質(zhì)量保證02工程管理03配置管理04測試管理03工程共享庫01工程模版02工程標(biāo)準(zhǔn)03工程制度04共享資料04工程基線庫01方案基線02需求基線03設(shè)計(jì)基線04產(chǎn)品基線05個(gè)人工作庫下設(shè)每個(gè)工程組成員的目錄06其他BUG數(shù)據(jù)庫--MantisBUG數(shù)據(jù)庫〔Bug管理工具〕目前暫定為使用Mantis可通過://192.168.1.90:8081/Mantis進(jìn)行試用。用戶名：demo密碼：demoBUG數(shù)據(jù)庫--Mantis進(jìn)入查看問題列表顯示存在的問題數(shù)報(bào)告一個(gè)新的問題更新個(gè)人資料Mantis—我的視圖Mantis—提交問題問題的分類，將問題歸類起來，方便按分類統(tǒng)計(jì)問題問題的出現(xiàn)頻率：總是/有時(shí)/隨機(jī)/沒有試驗(yàn)/無法重視/不適用問題的嚴(yán)重性：新功能/小細(xì)節(jié)/文字/小調(diào)整/很嚴(yán)重/崩潰/宕機(jī)問題的優(yōu)先級：無/低/中/高/加急/特急將問題分派給誰，由誰來負(fù)責(zé)修改。對于測試員不清楚由誰負(fù)責(zé)，可分派給工程經(jīng)理，由工程經(jīng)理來重新分派。Mantis—統(tǒng)計(jì)報(bào)表軟件開發(fā)流程實(shí)施現(xiàn)存問題實(shí)現(xiàn)的功能不是最初的設(shè)計(jì)目標(biāo),既產(chǎn)品規(guī)格和產(chǎn)品開發(fā)的一致性團(tuán)隊(duì)成員之間缺乏有效溝通產(chǎn)品規(guī)格更改維護(hù)產(chǎn)品進(jìn)度無法控制測試方案文檔管理解決方法軟件開發(fā)過程管理資源管理,包括管理時(shí)間,管理本錢,管理人員產(chǎn)品管理,管理功能,實(shí)現(xiàn),質(zhì)量實(shí)施步驟團(tuán)隊(duì)建立-一個(gè)高效的團(tuán)隊(duì)具有如下特征目標(biāo)一致,信念明確積極有效溝通,不要假設(shè)別人已經(jīng)知道主動(dòng)做事,主動(dòng)促進(jìn)流程改進(jìn),主動(dòng)回復(fù)別人EMAIL等,主動(dòng)共享信息通過Process〔流程〕使成員各司其職,每件事情必須有負(fù)責(zé)人數(shù)字化管理實(shí)現(xiàn)方式:流程+工具+文檔+數(shù)字實(shí)施考慮軟件流程改進(jìn)實(shí)施前提條件-作為軟件企業(yè)的ERP系統(tǒng),改變必然涉及每一個(gè)人的日常工作和思維方式,必須有強(qiáng)有力的領(lǐng)導(dǎo)支持和自適應(yīng)的能力.企業(yè)已經(jīng)建立了有效的郵件管理機(jī)制和信息共享機(jī)制(通過內(nèi)部站點(diǎn)共享知識(shí)庫,資源等).潛意識(shí)的有效溝通-使每一次需求更改都被所有的團(tuán)隊(duì)成員知道高效率協(xié)作,沒有權(quán)利而是依靠權(quán)威和知識(shí)領(lǐng)先性的管理方法,結(jié)果是高創(chuàng)造性積極工作,發(fā)表意見,改進(jìn)流程實(shí)施誤區(qū)不考慮企業(yè)自身的情況,盲目實(shí)施流程過度強(qiáng)調(diào)工具的重要性:如過度強(qiáng)調(diào)自動(dòng)化測試工具而忽略了測試流程改進(jìn)本質(zhì)-注重溝通強(qiáng)調(diào)溝通,更注重實(shí)用性團(tuán)隊(duì)成員之間的相互牽制,三權(quán)分立;程序經(jīng)理〔PM〕開發(fā)組〔DevelopTeam〕測試組〔TestTeam〕溝通不會(huì)自動(dòng)發(fā)生日常會(huì)議里程碑總結(jié)(PostMotem)每日,每周匯報(bào)Bug檢討會(huì)議〔BugTriageMeeting〕代碼審核〔CodeReview〕流程改進(jìn)本質(zhì)-使軟件開發(fā)可控制使軟件過程開發(fā)成為一個(gè)可控制的過程數(shù)字化管理:基于數(shù)字的軟件開發(fā)度量樹立時(shí)間方案的權(quán)威性,有效控制時(shí)間軟件產(chǎn)品有清晰的標(biāo)準(zhǔn):功能規(guī)格書(FunctionalSpecification)作為全組的標(biāo)準(zhǔn),必須具有權(quán)威性基于功能的進(jìn)度方案和多個(gè)檢查點(diǎn)保證所有的功能實(shí)現(xiàn)符合功能規(guī)格書流程改進(jìn)本質(zhì)-持續(xù)主動(dòng)調(diào)整必須專門的人員監(jiān)測整個(gè)軟件開發(fā)流程,并加以調(diào)整.將盡可能多的流程書面化.流程的不斷變化和不同時(shí)期角色的工作重點(diǎn)調(diào)整工程初始化(一)軟件企業(yè)需要一個(gè)能夠滿足缺陷跟蹤和管理的工具,同時(shí)能夠?yàn)闆Q策提供支持.市場調(diào)查(市場人員),并給出產(chǎn)品需求書產(chǎn)品前景目標(biāo)用戶產(chǎn)品包和構(gòu)件平臺(tái)支持,硬件和軟件環(huán)境語言支持功能要求管理層決定實(shí)施該工程,并決定工程經(jīng)理,測試小組長,開發(fā)小組長人選管理層決定工程會(huì)議的時(shí)間工程初始化(二)工程發(fā)動(dòng)大會(huì)聽眾:所有可得到的人力資源主題宣布工程開始工程前景陳述團(tuán)隊(duì)組織人力資源獲得:招聘+培訓(xùn)工程發(fā)布時(shí)間工作準(zhǔn)那么-明確準(zhǔn)那么,積極工作〔一〕工程經(jīng)理的工作進(jìn)度監(jiān)控,樹立各種規(guī)格和進(jìn)度表的權(quán)威性溝通中心,對內(nèi)確保每一個(gè)理解產(chǎn)品的前景,功能和對外確保管理層的支持和滿足顧客需求工程經(jīng)理一般是整個(gè)團(tuán)隊(duì)的凝聚力所在工程經(jīng)理的主要工作以寫規(guī)格,開會(huì)和查看Email,進(jìn)度監(jiān)控,查看BUG數(shù)據(jù)庫和溝通為主開發(fā)小組長的工作通過CodeReview代碼審核提供高質(zhì)量代碼制定合理的時(shí)間方案技術(shù)選型,代碼重利用從而到達(dá)按時(shí)完成代碼總體構(gòu)架設(shè)計(jì)和通用程序設(shè)計(jì)團(tuán)隊(duì)成員溝通工作準(zhǔn)那么-明確準(zhǔn)那么,積極工作〔二〕測試小組長的工作測試環(huán)境的建立測試策略制訂測試方法和工具的選用測試案例的維護(hù)發(fā)布測試報(bào)告工作準(zhǔn)那么-明確準(zhǔn)那么,積極工作〔三〕工程管理〔M0〕目的設(shè)定項(xiàng)目目標(biāo)和計(jì)劃開始完成產(chǎn)品前景分析，需求分析，系統(tǒng)設(shè)計(jì)結(jié)束開始編碼項(xiàng)目經(jīng)理責(zé)任1.完成產(chǎn)品規(guī)格書;2.確定產(chǎn)品功能優(yōu)先級;3.確定項(xiàng)目日程表4.處理外部部件和其它組關(guān)系;測試計(jì)劃檢驗(yàn)開發(fā)組責(zé)任開發(fā)組日程表;代碼和構(gòu)架設(shè)計(jì);決定各個(gè)功能在哪個(gè)里程碑完成;規(guī)格書檢驗(yàn);測試計(jì)劃檢驗(yàn)測試組責(zé)任規(guī)格書檢驗(yàn);初始化缺陷數(shù)據(jù)庫;移植前一個(gè)版本中的延遲的缺陷數(shù)據(jù);添加支持部報(bào)告的缺陷;用戶培訓(xùn)規(guī)格書檢驗(yàn)(易用性,完整性和與其它產(chǎn)品的關(guān)系),并反饋給項(xiàng)目經(jīng)理;提供文檔資料計(jì)劃;日程安排管理層評估上個(gè)項(xiàng)目,并改進(jìn)流程;評估從項(xiàng)目中得到的數(shù)據(jù)(如缺陷數(shù)據(jù)分析,工作量統(tǒng)計(jì),缺陷質(zhì)量);定義不同團(tuán)隊(duì)之間的合作方式;同意項(xiàng)目計(jì)劃;其它工作人員培訓(xùn),熟練掌握各種工具.建立源代碼效勞器,培訓(xùn)工程組成員使用版本控制工具.確定各團(tuán)隊(duì)工作目錄確定常規(guī)會(huì)議,如周工程狀態(tài)會(huì)議新員工工作手冊,使新的員工能夠非常清楚的知道各個(gè)效勞器和環(huán)境安裝,及工作流程建立測試效勞器和發(fā)布效勞器測試團(tuán)隊(duì)建立BUG數(shù)據(jù)庫效勞器建立團(tuán)隊(duì)工作信息發(fā)布站點(diǎn),發(fā)布團(tuán)隊(duì)新聞,共享文檔資源,工程組員聯(lián)系方式,任務(wù)列表等.文檔模板-功能規(guī)格書人力資源+FeatureTeam(功能團(tuán)隊(duì))前景描述平臺(tái)要求語言支持(本地化和全球化)出錯(cuò)處理(日志,警告,信息)和最終返回錯(cuò)誤信息用戶場景(UserScenarios)功能細(xì)分和說明安裝程序快捷鍵要求性能目標(biāo)用戶培訓(xùn)文檔和進(jìn)度方案進(jìn)度方案(MicrosoftProject)UI設(shè)計(jì)文檔文檔模板-實(shí)現(xiàn)規(guī)格書實(shí)現(xiàn)文檔是一個(gè)文檔集,包括數(shù)據(jù)字典資源管理開發(fā)環(huán)境,技術(shù)選型,程序構(gòu)架和設(shè)計(jì)模式代碼重用模塊劃分出錯(cuò)處理多語言支持性能考慮數(shù)據(jù)庫設(shè)計(jì)公用接口設(shè)計(jì)文檔模板-測試方案(一)測試環(huán)境描述,包括效勞器,安裝程序描述人力資源劃分測試流程及不同階段的測試重點(diǎn)功能完備性測試測試目標(biāo),范圍和質(zhì)量標(biāo)準(zhǔn)測試區(qū)域劃分易用性測試性能測試可靠性測試平臺(tái)測試(使用矩陣)恢復(fù)測試回歸測試 缺陷跟蹤工具文檔模板-測試方案(二)測試策略描述,頻率和所有者測試案例開發(fā)和維護(hù),制訂測試案例覆蓋標(biāo)準(zhǔn)自動(dòng)化工具開發(fā),決定何時(shí)進(jìn)行自動(dòng)化工具開發(fā)存在大量的API和大量的測試案例測試案例只需要結(jié)果〞通過〞或〞不通過〞,不需要用戶的干預(yù)有大量的回歸測試案例雇開發(fā)人員寫自動(dòng)化工具比雇多個(gè)測試員廉價(jià)測試腳本開發(fā)測試工具源代碼分析工具測試進(jìn)度如何實(shí)現(xiàn)成功的進(jìn)度方案進(jìn)度方案由整個(gè)開發(fā)團(tuán)隊(duì)來制定進(jìn)度方案而不是工程經(jīng)理單獨(dú)制定事情無論大小,全部列入方案或算進(jìn)緩沖保證進(jìn)度方案的權(quán)威性.可以將進(jìn)度方案貼在作戰(zhàn)會(huì)議或工作房間的墻壁上工程經(jīng)理必須非常清楚最重要的事情并推動(dòng)執(zhí)行.尤其是在不同的里程碑切換時(shí).并將這一信息傳達(dá)給全組.在制訂方案時(shí),必須考慮到會(huì)議,假期,匯報(bào)工作,單元測試,病假,解決缺陷和不可預(yù)料的事件.緩沖一般為30%~50%.在固定發(fā)布日期條件下,尤其應(yīng)該增長緩沖.如何實(shí)現(xiàn)成功的進(jìn)度控制監(jiān)控和度量每天組員提交工程進(jìn)度日報(bào)每周工程經(jīng)理提交工程周報(bào),開發(fā)小組長和測試小組長分別提交工程周報(bào)對當(dāng)前工程狀態(tài)進(jìn)行總結(jié),這些報(bào)表的聽眾必須是所有團(tuán)隊(duì)成員,包括管理人員.周報(bào)的格式和日報(bào)格式相同 在周報(bào)中安排除了日常工作以外的其它必須檢查的事宜.這可以補(bǔ)充進(jìn)度方案的缺乏每周召開團(tuán)隊(duì)會(huì)議,總結(jié)工程當(dāng)前狀態(tài).工程管理〔M1〕目的開發(fā)產(chǎn)品,保證代碼質(zhì)量并降低BUG數(shù)量開始編碼開始結(jié)束測試團(tuán)隊(duì)認(rèn)為編碼按時(shí)符合規(guī)格書規(guī)范完成項(xiàng)目經(jīng)理責(zé)任管理產(chǎn)品規(guī)格書,管理功能組工作狀況,保持全組工作重點(diǎn),推動(dòng)工作進(jìn)度開發(fā)組責(zé)任設(shè)計(jì),記錄和編碼;單元測試,每日構(gòu)建;解決問題;保證按時(shí)完成;測試組責(zé)任設(shè)計(jì),記錄測試規(guī)范;寫自動(dòng)化測試編碼;在正式提交的代碼中進(jìn)行可接受測試;在里程碑時(shí)運(yùn)行所有的測試案例;報(bào)告和關(guān)閉缺陷;給出產(chǎn)品質(zhì)量和功能完成性評估報(bào)告;認(rèn)證功能完成;檢驗(yàn)用戶文檔用戶培訓(xùn)書寫用戶教育文檔;基于用戶任務(wù)來評估功能的完成;用戶輔助工具;用戶教育文檔測試計(jì)劃工作流程(一)開發(fā)組員檢查BUG數(shù)據(jù)庫和電子郵件.如果發(fā)現(xiàn)自己的BUG數(shù)量高于給定值,那么停止開發(fā),更改BUG.工程經(jīng)理和各組長檢查BUG數(shù)據(jù)庫和電子郵件.指派BUG給某一個(gè)組員.如果可爭議BUG太多,召開BUG檢討會(huì)議,討論BUG的優(yōu)先級.每天的發(fā)布版本中需要包含說明文件(本版本更正BUG,實(shí)現(xiàn)功能,改變的文件),如果是API測試應(yīng)包含類庫文檔工作流程(二)工程組員每天早上從源代碼效勞器下載代碼,更新其它程序員的改變。工程組員編輯自己的程序,實(shí)現(xiàn)程序功能。工程組員編譯自己的本地源代碼拷貝并進(jìn)行單元測試,如無錯(cuò)誤,交給測試組員測試.如果沒有錯(cuò)誤,提交到源代碼效勞器.通過這種方法保證源代碼效勞器中的程序始終是可運(yùn)行的.如果本次CHECKIN完成了某一個(gè)功能,提交到測試組測試,證明此功能已完成并可測試工程組員提交工程日報(bào).工作流程(三)測試組指定專門的可接受測試人員,并給出可接受的標(biāo)準(zhǔn).8:30-9:00,指定的測試人員每天早上運(yùn)行可接受測試,如果成功發(fā)EMAIL給全組.其它測試人員開始進(jìn)行功能測試.功能測試僅測試那些已經(jīng)提交測試的功能.測試組發(fā)現(xiàn)BUG,并登記在BUG數(shù)據(jù)庫中.測試組進(jìn)行其它測試,如性能測試,本地測試和平臺(tái)測試.測試頻率和目標(biāo)在測試方案中制定。測試組根據(jù)測試方案開發(fā)測試用例,編寫自動(dòng)化工具和測試腳本.測試組提交測試日報(bào)使用源代碼控制工具放入源文件,文檔資料和所有頻繁改動(dòng)的資料不要放入二進(jìn)制代碼,包括動(dòng)態(tài)庫DLL和可執(zhí)行文件EXE只修改需要改動(dòng)的代碼(SDEDIT)每次CheckIn時(shí),填寫變化列表。每次CheckIn之前,保證本地編譯通過,并通過代碼審核建立每日發(fā)布的源代碼標(biāo)簽,便于回滾到某一個(gè)特定的編譯生成時(shí)的源代碼.管理你的BUG數(shù)據(jù)庫建立并備份你的BUG數(shù)據(jù)庫定義BUG管理流程清楚地定義BUG類別和屬性建立起B(yǎng)UG的權(quán)威性,如果一個(gè)BUG可以方便地被重現(xiàn),該BUG必須被修復(fù).設(shè)定BUG數(shù)上限開發(fā)組員不能選擇〞不做修改〞和〞稍后處理〞作為一個(gè)BUG的解決方案監(jiān)測BUG數(shù)據(jù)庫,利用數(shù)字標(biāo)準(zhǔn)作為衡量標(biāo)準(zhǔn),并使全組人員知道這些數(shù)字.軟件開發(fā)質(zhì)量(一)前提條件,在實(shí)施的過程中和過程后收集大量數(shù)據(jù)工程開發(fā)過程中的數(shù)據(jù)收集每日,每周登記的缺陷和解決的缺陷(按照嚴(yán)重性統(tǒng)計(jì))跟蹤每日已激活缺陷和已解決缺陷數(shù)目修改缺陷數(shù)目;已解決的缺陷數(shù)目(除去重復(fù)和不可重復(fù)缺陷)跟蹤缺陷重新激活次數(shù)缺陷的發(fā)現(xiàn)途徑:隨即測試,測試案例開發(fā),可接受性測試解決缺陷的平均時(shí)間關(guān)閉缺陷的平均時(shí)間最老的缺陷軟件開發(fā)質(zhì)量(二)總結(jié)過程中的數(shù)據(jù)收集不同等級的缺陷百分比方案的測試工作量實(shí)際的測試工作量“SHOWSTOPPER〞缺陷的產(chǎn)生原因:缺乏測試案例由于修改其它缺陷引起的新缺陷,測試區(qū)域劃分導(dǎo)致沒有進(jìn)行測試,回歸測試配置測試,不是所有的機(jī)器上都可以重現(xiàn)錯(cuò)誤標(biāo)準(zhǔn)不完整最后加的功能如何作CodeReview(代碼審核)標(biāo)志代碼錯(cuò)誤,如通過編譯檢查的代碼拼寫錯(cuò)誤,違反編碼標(biāo)準(zhǔn),硬編碼(hardcode)字符串和配置;標(biāo)明算法錯(cuò)誤,如選擇錯(cuò)誤的算法或沒考慮邊界情況.標(biāo)志潛在的回歸式錯(cuò)誤標(biāo)志可改進(jìn)的地方教育開發(fā)人員CodeReview的步驟代碼應(yīng)該在多個(gè)平臺(tái)上編譯成功代碼首先必須被開發(fā)人員測試過.使用DEBUGGER單步執(zhí)行,或添加跟蹤語句.代碼必須被提交給代碼審核者,使用Windiff工具比較不同代碼審核的結(jié)果應(yīng)該是接受,有條件的接受和拒絕代碼審核的結(jié)果必須在下次審核之前更正,并提交.代碼審核CheckList是否符合編碼標(biāo)準(zhǔn)是否有HARDCODE字符串是否使用數(shù)字來定義數(shù)組大小,而不是使用常量或宏是否自己寫代碼而不使用類庫開發(fā)人員是否誤解了類庫的參數(shù)開發(fā)者是否假定某一平臺(tái)來開發(fā)程序,從而在其它平臺(tái)上不能運(yùn)行是否去除了