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