閉環(huán)跟蹤
--提高軟件開發(fā)質(zhì)量，推動過程改進(jìn)
有幸在07年5月24日參加Telelogic組織的“閉環(huán)跟蹤”研討會。John Carrillo在會上做了精彩的演講，會議開始就提出了主題“如何提高軟件開發(fā)質(zhì)量，推動過程改進(jìn)”。
John提出提高軟件開發(fā)質(zhì)量，主要以下三點(diǎn)：
(1) 業(yè)務(wù)流程優(yōu)化 BPO (Business Process Optimization)
(2) 應(yīng)用生命周期 ALM (Application Lifecycle Management)
(3) 模型驅(qū)動開發(fā) MDD (Model-Driven Development)
創(chuàng)新、簡化開發(fā)流程及開發(fā)業(yè)務(wù)，遵循規(guī)則開發(fā)、依據(jù)規(guī)則管理，可以有效提高生產(chǎn)率。
John在談及“提前管控質(zhì)量”時，以例說明，你要去瑞士參加重要會議，剛下飛機(jī)，將隨身攜帶的旅行箱丟失，里面有你的正裝，而你又要去參加一個重要會議，這時你怎么辦？。John提出的例子很有說明性，其實(shí)你可能想再買一套就可以啦，那為什么不去考慮怎么可以在丟失之前去管控呢。項(xiàng)目中也如此，John提出數(shù)據(jù)，從項(xiàng)目開始發(fā)現(xiàn)問題到最終版本發(fā)現(xiàn)問題，這時最終版本發(fā)現(xiàn)問題會比開始發(fā)現(xiàn)問題的損失增長成百上千倍，那項(xiàng)目中需要管控有哪些呢？
(1) 最終發(fā)行版本僅反映最初所分配需求的52%。
其導(dǎo)致原因無非兩點(diǎn),1)需求調(diào)研的需求與客戶提出需求不符。2)需求多，膨脹，軟件開發(fā)商做不到。
(2) 需求劇變，John提出數(shù)據(jù)，以1年項(xiàng)目為例，每月1%-13%的需求變更，最終30%的需求變更。
導(dǎo)致原因：1)引發(fā)客戶變更。2)系統(tǒng)需求變更
(3) 發(fā)布版本。
導(dǎo)致原因：1)需求變量對發(fā)布有影響
最終John提出結(jié)論：70%功能缺陷，不具備可操作性，無法交付。
John開始進(jìn)入主題，“閉環(huán)跟蹤”，其實(shí)這種研討會無非就是宣傳公司產(chǎn)品，開始宣傳他的思想，讓你接受他的思想，好，他又用軟件產(chǎn)品實(shí)現(xiàn)了他的思想，買吧。
正題，閉環(huán)跟蹤主要有三種方法：
1) 自上而下
a) 收集“客戶反饋”，確保在整個開發(fā)生命周期中有效管理、審查并跟蹤客戶請求。
b) 需求工作流程管理，通過靈活和可重復(fù)流程來保持對需求變更的跟蹤。
c) 需求執(zhí)行，確保需求變更在最終產(chǎn)品中得以執(zhí)行。
2) 自下而上
a) 需求執(zhí)行，任務(wù)執(zhí)行。
b) 任務(wù)追述到需求，再從需求追述到客戶反饋。
c) 需求驗(yàn)證任務(wù)是否滿足客戶反饋是否相符，確認(rèn)軟件可以滿足用戶提出的需求。
3) 提高跨生命周期的可見性和可預(yù)測性
a) 通過自上而下和自下而上兩種方法，利益相關(guān)者無疑可以輕松地在整個產(chǎn)品工作流程中保持對需求變更和變更請求的跟蹤。管理需借助自上而下的狀態(tài)信息來確定開發(fā)團(tuán)隊達(dá)成其目標(biāo)的具體方式。警報和考核有助于項(xiàng)目經(jīng)理及他人開展對期限、需求、項(xiàng)目分配和軟件開發(fā)其它方面的跟蹤。各級經(jīng)理不但可以清晰把握開發(fā)進(jìn)程的各個階段，還可以了解不同角色的與組件間的互動方式。定期警報將協(xié)助項(xiàng)目經(jīng)理針對進(jìn)度或預(yù)處中所出現(xiàn)的偏差迅速作出響應(yīng)，并在事況惡化前及時修改。
以上是Telelogic白皮書中介紹的，其實(shí)總結(jié)出來，無非就是出些報表、駐狀圖、餅圖什么的，再加上可以配置一些預(yù)警。
John強(qiáng)調(diào)CMMI只是告訴你“做什么。”不會告訴你“應(yīng)該怎么去做”，一般過CMMI的過程：參考模型->培訓(xùn)課程->評估方法（打“對號”，就是哪項(xiàng)滿足規(guī)范就打個對號）。CMMI需要三個主要組成元素：人，規(guī)則，工具。而CMMI不會告訴你做什么，這時就有我們的工具規(guī)范你怎么去做，唉，終于提正題，介紹Telelogic公司的產(chǎn)品了。
茶歇
該演示產(chǎn)品了，首先是需求管理工具Doors，說白了其實(shí)就是一個流程，首先用戶提出需求->審核（是否同意）系統(tǒng)需求->用例->提出實(shí)施請求（使用狀態(tài)跟蹤）。Doors可以按項(xiàng)目及需求說明書、概要設(shè)計、詳設(shè)逐一關(guān)聯(lián)，舉個例子，提出功能A需求，可關(guān)聯(lián)功能A概要設(shè)計，功能A的詳細(xì)設(shè)計。不就是我們一個工單嗎？拿這種產(chǎn)品來唬人，不過人家的思想是先進(jìn)的，我們?nèi)∑渚A。其實(shí)人家也是有特點(diǎn)的。
下面就說說配置管理工具Synergy CM，其實(shí)我看CM代碼管理部分就像Source safe，只是人家將Doors與CM有機(jī)的集成在一起，其實(shí)感覺就數(shù)據(jù)源一樣就解決集成了。一樣Doors提出的請求實(shí)施與CM的任務(wù)聯(lián)系在一起，例：我在Doors提出A功能的請求實(shí)施并派給實(shí)施人，然后實(shí)施人登入CM將看到派來的任務(wù)，之后實(shí)施人分析派來的任務(wù)，這時就要source safe了，實(shí)施人員check out要完成任務(wù)所涉及的代碼，完成后commit。在CM中可以追述Doors的數(shù)據(jù)，也就是說有提出提出實(shí)施請求，用例，審核，需求人是誰（這就是自下而上了）CM提供類似Source safe,svn ,cvs的功能，代碼比較，目錄比較，形成基線。基線比較，任務(wù)比較。提供任務(wù)，代碼，基線告等的報告，統(tǒng)計、總體實(shí)施進(jìn)度等。典型的自下而上，代碼->任務(wù)->實(shí)施請求->需求。CM提供eclipse plugin
ＯＫ，總算說完了，我總結(jié)下吧。其實(shí)John的思想是好的，需求不斷的變更導(dǎo)致項(xiàng)目的成本增加，管理難度增大。John提出了使用Doors工具來管理需求，來規(guī)范化，梳理你的開發(fā)流程，而又用CM來管理開發(fā)人員的開發(fā)任務(wù)管理。而Doors與CM集成更是一把利器，梳理你的開發(fā)流程。其實(shí)Doors及CM根本沒有什么技術(shù)難度，但它可以解決像CMMI無法幫你解決的，如Jhon所說，CMMI只是告訴你做什么，而Telelogic會告訴你怎么做。
2007-5-25