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