軟考系統(tǒng)分析師：誰最應(yīng)該學(xué)用例
9年前，我們開發(fā)一個(gè)商業(yè)連鎖公司的業(yè)務(wù)管理系統(tǒng)，開發(fā)組興致勃勃地第一次使用了UML建模語言進(jìn)行系統(tǒng)的分析和設(shè)計(jì)。開發(fā)組花了大概2個(gè)月的時(shí)間完成了對業(yè)務(wù)系統(tǒng)的分析，并使用Use Cases描述用戶需求和軟件功能------盡管對這兩個(gè)元素的區(qū)分那時(shí)還經(jīng)常混為一談，最后形成了一個(gè)幾十頁的需求文檔。裝訂成冊后，一天下午由項(xiàng)目經(jīng)理和一個(gè)博士分析師兩人去甲方哪里溝通，并期望對需求達(dá)成一致，并獲得甲方的簽字。大家認(rèn)為，使用這樣清晰和結(jié)構(gòu)化的表達(dá)方式，需求真的已經(jīng)比較清楚了?？墒?，意想不到的事情發(fā)生了。
甲方看了文檔后，說“我看不懂！……我不能簽字！”后來，無論我們的項(xiàng)目經(jīng)理和博士怎么一一就需求講給他聽，他都無法，或者不愿意把聽到的和需求文檔里的那些陌生的符號（小人和橢圓）關(guān)聯(lián)起來------他不相信他看不懂的東西，他無法對他看不懂的東西承擔(dān)責(zé)任、簽字畫押。生氣的自然是我們的項(xiàng)目經(jīng)理，可是甲方錯(cuò)了嗎？
其實(shí)，這是一個(gè)典型的甲乙方溝通問題。而問題的關(guān)鍵是，雙方?jīng)]有約定彼此認(rèn)可的、相同的溝通語言。就好像你說中文，他說西文；就好像RAS非對稱密鑰，你用一種密鑰加密，而要求他用另一種密鑰解密。這在人與人的溝通世界里，簡直就是痛苦----雙方的痛苦！那時(shí)候，有人笑侃，“這是加密了的需求，要用UML這把鑰匙才能把它打開，才能翻譯成自然語言文本。” 人類在語言上不斷地進(jìn)步，最終出現(xiàn)了非常好用、溝通自由、表達(dá)準(zhǔn)備的“自然語言”?？墒?，在計(jì)算機(jī)世界里，自然語言卻失去了它的價(jià)值。我們似乎需要反達(dá)爾文進(jìn)化，把自然語言再符號化、結(jié)構(gòu)化。另外，當(dāng)我們對復(fù)雜現(xiàn)實(shí)世界（如：專業(yè)業(yè)務(wù)系統(tǒng)等）進(jìn)行描述的時(shí)候，由于我們自然語言的過于靈活，使得我們溝通的雙方出現(xiàn)了理解偏差，而且隨著復(fù)雜性的增大，偏差越大。直到現(xiàn)在，關(guān)于復(fù)雜業(yè)務(wù)系統(tǒng)的溝通，在軟件工程師和客戶之間，還依然存在著理解的偏差。這是需求工程中的一個(gè)全球性疑難問題。
那么，既然如此，UML可以作為一個(gè)面向?qū)I(yè)業(yè)務(wù)系統(tǒng)的描述語言，來表達(dá)實(shí)際業(yè)務(wù)嗎？我想，UML之父Ivar Jacobson 、Booch 和 James Rumbaugh 已經(jīng)幫助我們回答了這個(gè)問題。但是，接下來，你能強(qiáng)迫你的客戶去懂得UML嗎？有人說，在過去20年來，軟件工程師是最辛苦的職業(yè)，因?yàn)樗麄儾粌H要懂計(jì)算機(jī)，還要懂甲方的業(yè)務(wù)，更重要的是，還要讓甲方相信你懂他的業(yè)務(wù)。而甲方，也許什么不懂都沒有什么大不了的。這種交易中的不對等，溝通中的不對等嚴(yán)重地束縛了軟件產(chǎn)業(yè)的發(fā)展，返工、重開發(fā)等等幾乎在每個(gè)軟件企業(yè)里發(fā)生過；也因此造成了甲方許多投資失敗。想想吧，所有的產(chǎn)業(yè)鏈中，沒有那個(gè)產(chǎn)業(yè)象軟件業(yè)一樣，把它和它的客戶如此緊密的聯(lián)系在一起。所以，在一個(gè)共同的“生存鏈條里”，我們需要一起成長，一起進(jìn)步。當(dāng)需求的問題日日夜夜糾纏著我們彼此的大腦的時(shí)候，我們需要共同的努力，需求結(jié)構(gòu)化我們的需求，需要在溝通上創(chuàng)造新的方式，那就是：共同使用UML來確認(rèn)需求。當(dāng)然，除過UML之外，還有IDEF0、Workflow等輔助技術(shù)。
因此，甲方的項(xiàng)目人，如果你還停留在初級的需求表達(dá)上，請進(jìn)入U(xiǎn)ML的世界吧，請?jiān)囉糜美睦靼?。它幫助你分解需求，關(guān)聯(lián)需求，結(jié)構(gòu)化需求，和快速理解需求。
【編輯推薦】
