，建立穩(wěn)定、可靠的系統(tǒng)架構(gòu)的里程碑目標(biāo)也從未達(dá)到。
在項(xiàng)目幾近成功、圓滿結(jié)束的時(shí)候，突然爆炸一顆碩大的“地雷”（嚴(yán)重的系統(tǒng)缺陷或問(wèn)題），導(dǎo)致項(xiàng)目進(jìn)度拖延甚至失控，人員失和，資金拖欠，這就是軟件開(kāi)發(fā)中最糟糕的一種情況。
不幸的是，這種在各種經(jīng)典教材中都能大量看到的案例，再一次地在已經(jīng)（部分）采用了敏捷XP、RUP實(shí)踐的PRM項(xiàng)目上重演了。那么，我們有沒(méi)有可能事先防范PRM項(xiàng)目這顆延遲爆炸的“地雷”呢？
當(dāng)年P(guān)RM項(xiàng)目已經(jīng)花了10個(gè)月的時(shí)間，卻仍未能通過(guò)客戶驗(yàn)收。前期用了2個(gè)月完成功能開(kāi)發(fā)，2個(gè)月部署和試運(yùn)行，從第5個(gè)月完成實(shí)際數(shù)據(jù)導(dǎo)入、開(kāi)始正式運(yùn)行起，就出現(xiàn)了嚴(yán)重的性能問(wèn)題。
隨后的6個(gè)月基本上都用在了系統(tǒng)的性能優(yōu)化和改進(jìn)上?？傮w上項(xiàng)目開(kāi)發(fā)給人一種手忙腳亂、進(jìn)度失控的感覺(jué)?，F(xiàn)在看來(lái)，PRM項(xiàng)目的進(jìn)度至少延誤了一倍時(shí)間。
軟件工程不相信眼淚
如果PRM團(tuán)隊(duì)和客戶從一開(kāi)始就意識(shí)到系統(tǒng)潛在的性能問(wèn)題，明確了對(duì)系統(tǒng)容量的要求;如果PRM系統(tǒng)的架構(gòu)師擁有足夠的設(shè)計(jì)經(jīng)驗(yàn)，系統(tǒng)表示層、控制層和數(shù)據(jù)資源層在上線之前就已經(jīng)得到優(yōu)化，提供了足夠的性能;如果架構(gòu)設(shè)計(jì)評(píng)審產(chǎn)生了真正的效用;如果 PRM 團(tuán)隊(duì)做到了完備的系統(tǒng)測(cè)試;如果時(shí)間能夠倒流……。
所有這些“如果”當(dāng)中，只要有一條靈驗(yàn)，那么那顆可惡的“地雷”可能就不復(fù)存在了。
PRM項(xiàng)目可不可以做得更成功呢？答案是肯定的，我們不妨逆向思維:如果PRM團(tuán)隊(duì)能夠把這個(gè)項(xiàng)目重頭再做一遍，把吸取到的教訓(xùn)和學(xué)到的軟件工程“新”知識(shí)都用上，在5個(gè)月內(nèi)提供滿足客戶實(shí)際要求的系統(tǒng)應(yīng)該足夠了，至少PRM團(tuán)隊(duì)下次再遇到類似的項(xiàng)目他們成功的幾率肯定會(huì)大許多。
規(guī)避風(fēng)險(xiǎn)，成熟的軟件工程可以設(shè)置幾道防線，采取許多措施。如果PRM項(xiàng)目按照RUP 風(fēng)險(xiǎn)驅(qū)動(dòng)的迭代方式來(lái)做，那么從項(xiàng)目一開(kāi)始我們就應(yīng)該對(duì)需求、架構(gòu)進(jìn)行更為細(xì)致、全面的分析，既包括功能，也包括非功能，還可以通過(guò)多次迭代反饋來(lái)確認(rèn)分析的結(jié)果。
假設(shè)如果不知道有哪些風(fēng)險(xiǎn)，我們又如何來(lái)防范？所以，關(guān)鍵是要建立一張隨著迭代演進(jìn)不斷被動(dòng)態(tài)更新維護(hù)的風(fēng)險(xiǎn)清單（RUP工件叫Risk List），制定出防范其中所有主要風(fēng)險(xiǎn)的預(yù)案。
就PRM項(xiàng)目而言，一方面，功能開(kāi)發(fā)不是一個(gè)重大風(fēng)險(xiǎn)，因?yàn)橛信f的PHP系統(tǒng)、源代碼和現(xiàn)成的算法可以參考。另一方面，J2EE的應(yīng)用架構(gòu)設(shè)計(jì)得不好可能會(huì)存在性能問(wèn)題。
因此，我們應(yīng)該把注意力更多放到系統(tǒng)的非功能風(fēng)險(xiǎn)上（性能、可靠性、可維護(hù)性等）。具體表現(xiàn)為:客戶應(yīng)用訪問(wèn)的最大并發(fā)用戶數(shù)到底是多少?我們交付到客戶手里的系統(tǒng)最大容量又是多少？怎樣才能保證系統(tǒng)的性能？如果上線后性能達(dá)不到，不能滿足客戶要求怎么辦？等等。
明確了項(xiàng)目所面臨的重大風(fēng)險(xiǎn)，比如系統(tǒng)的性能問(wèn)題，我們就可以根據(jù)需求和設(shè)計(jì)方案制定出完善的、有針對(duì)性的測(cè)試計(jì)劃。包括在客戶可接受的響應(yīng)時(shí)間要求下，系統(tǒng)最大能夠支持多少個(gè)用戶的并發(fā)訪問(wèn)（具體可細(xì)分為增、刪、改、查等多個(gè)操作類型）。
明確了項(xiàng)目的風(fēng)險(xiǎn)、需求還不行，作為風(fēng)險(xiǎn)預(yù)案的落實(shí)，我們還應(yīng)該進(jìn)行系統(tǒng)性能、可靠性等方面的設(shè)計(jì)，真正（通過(guò)編碼）做出一個(gè)符合要求的架構(gòu)（框架）基礎(chǔ)，通過(guò)迭代開(kāi)發(fā)、測(cè)試和評(píng)審對(duì)此進(jìn)行驗(yàn)證。
在開(kāi)發(fā)階段，系統(tǒng)還未部署，如果我們無(wú)法獲得真實(shí)的用戶和使用環(huán)境怎么辦？用模擬測(cè)試！對(duì)，如果嚴(yán)格按照 RUP 風(fēng)險(xiǎn)驅(qū)動(dòng)的迭代演進(jìn)式開(kāi)發(fā)進(jìn)行管理，在半年多的時(shí)間里應(yīng)該還是有機(jī)會(huì)盡早發(fā)現(xiàn)這個(gè)問(wèn)題的。
但是，這種方式可以消除局部的缺陷，但卻很難發(fā)現(xiàn)全局性的架構(gòu)問(wèn)題。對(duì)于軟件架構(gòu)，“頭痛醫(yī)頭，腳痛醫(yī)腳”的做法往往是行不通的。
PR項(xiàng)目雖然模仿X迭代周期，甚至每天都開(kāi)例會(huì)（這有點(diǎn)像Scrum），很容易獲得真實(shí)的項(xiàng)目情況，就像"掀開(kāi)地毯下面的東西"，保證了初始版本的準(zhǔn)時(shí)交付（在保證PRM前期進(jìn)度方面，迭代還是有功勞的），卻仍然沒(méi)有能夠防止較大風(fēng)險(xiǎn)的發(fā)生（交付系統(tǒng)幾個(gè)月后才逐漸暴露出性能和架構(gòu)上的質(zhì)量問(wèn)題）。
可以說(shuō)，這并沒(méi)有達(dá)到XP或RUP迭代開(kāi)發(fā)的最終目的。在項(xiàng)目初期，沒(méi)有把合同中已經(jīng)提到的數(shù)據(jù)遷移視為一個(gè)關(guān)鍵風(fēng)險(xiǎn)，是前期分析工作或者說(shuō)整個(gè)項(xiàng)目的一大失誤。轉(zhuǎn)貼于：http://www.vanceur.cn