前言:作為軟件開(kāi)發(fā)人員,一定要了解軟件工程學(xué),而這門(mén)科學(xué)的第一步是需求分析,打開(kāi)任何一本軟件工程的書(shū)籍翻看目錄知道了。在實(shí)際的一個(gè)項(xiàng)目中,在進(jìn)行需求分析之后,對(duì)這個(gè)項(xiàng)目進(jìn)行規(guī)劃、編碼,到后完成這個(gè)項(xiàng)目,看著這個(gè)項(xiàng)目后實(shí)施應(yīng)用,對(duì)我們開(kāi)發(fā)人員來(lái)說(shuō),這真是一種成感?墒窃谌蘸蟮氖褂眠^(guò)程中,客戶(hù)不停地提出各種意見(jiàn)和建議,讓我們沒(méi)法把精力投入到其他項(xiàng)目,而是不停地修改舊作,相信我們都遭遇過(guò)。
需求分析是指理解用戶(hù)需求,軟件功能與客戶(hù)達(dá)成一致,估計(jì)軟件風(fēng)險(xiǎn)和評(píng)估項(xiàng)目代價(jià),終形成開(kāi)發(fā)計(jì)劃的一個(gè)復(fù)雜過(guò)程。需求分析主要(還有很多,比如性能需求、可靠性需求、逆向需求、將來(lái)可能提出的需求,這里不做介紹)包括:業(yè)務(wù)需求、客戶(hù)需求和功能需求三個(gè)部分。業(yè)務(wù)需求(Business Requirement )意為客戶(hù)對(duì)產(chǎn)品的目標(biāo)或者要求;客戶(hù)需求(User Requirement )意為客戶(hù)在使用產(chǎn)品過(guò)程中需要完成的一系列任務(wù),功能需求(Functional Requirement )指定了產(chǎn)品系統(tǒng)必須提供的功能。在整個(gè)軟件系統(tǒng)的開(kāi)發(fā)過(guò)程中,其實(shí)有很多問(wèn)題是由于在需求分析階段沒(méi)有正確實(shí)施而產(chǎn)生的。下面一一列出:
1、對(duì)需求理解的錯(cuò)誤
我是從工程角度來(lái)理解的,當(dāng)甲方(客戶(hù))向乙方(開(kāi)發(fā)方)提出產(chǎn)品需求的時(shí)候,其描述過(guò)程往往是通過(guò)口述語(yǔ)言來(lái)表達(dá)出來(lái)的,但不可能的保證其描述正確,同時(shí)也不能保證收聽(tīng)者完全正確理解,這是產(chǎn)生了分歧。當(dāng)乙方將產(chǎn)品初期模型交給甲方看,甲方驚呼這不是我們要的東西,這時(shí)已經(jīng)浪費(fèi)了大量的時(shí)間、人力和物力。
2、實(shí)際應(yīng)用與初期預(yù)想有出入
當(dāng)客戶(hù)提出具體要求之前,其實(shí)他并不知道這個(gè)產(chǎn)品在實(shí)際使用中的情況,一切要求都是憑空想象出來(lái)的,客戶(hù)將要求提給開(kāi)發(fā)方,開(kāi)發(fā)方開(kāi)始工作,當(dāng)客戶(hù)拿到這個(gè)產(chǎn)品的Demo版的時(shí)候,開(kāi)始實(shí)際操作,他會(huì)慢慢對(duì)產(chǎn)品的界面、操作、易用性、功能等等有一些認(rèn)識(shí),這個(gè)時(shí)候很有可能對(duì)產(chǎn)品需求有更改需求。
3、每個(gè)客戶(hù)的情況不一
人的五根手指還不一樣長(zhǎng)呢,客戶(hù)也一樣,100人的公司和10000人的工廠(chǎng),實(shí)際應(yīng)用怎么可能完全一樣?但這里也不排除人為因素的存在。
4、產(chǎn)品本身的問(wèn)題
人無(wú)完人,我們會(huì)努力做到精益求精,力保產(chǎn)品的可靠性,但難免會(huì)遇到bug?蛻(hù)在使用了一段時(shí)間后,發(fā)現(xiàn)產(chǎn)品的自身問(wèn)題,可能是數(shù)據(jù)莫名丟失,也可能是系統(tǒng)崩潰,還可能是兼容性問(wèn)題,這個(gè)時(shí)候需要找到開(kāi)發(fā)方來(lái)進(jìn)行產(chǎn)品升級(jí)或者修改。 算需求分析很完善,整個(gè)項(xiàng)目進(jìn)行的一切順利,但每個(gè)開(kāi)發(fā)人員的能力參差不齊,造成產(chǎn)品自身問(wèn)題,這是根本無(wú)法避免的。
我們當(dāng)然希望客戶(hù)永遠(yuǎn)不會(huì)提出需求變更,但如果一定要變化,而我們又不得不面對(duì),我們?cè)撛趺崔k?
對(duì)需求分析人員培訓(xùn)
看了上面的分析,當(dāng)然第一個(gè)需要培訓(xùn)的是需求分析人員了,這是開(kāi)始,也是根源,還有是規(guī)范需求分析人員與客戶(hù)的溝通方式,以及規(guī)范記錄需求的文檔格式。爭(zhēng)取保證雙方和諧地完成溝通會(huì)談。如果還是不行,那只能更換作需求分析的員工了。
對(duì)開(kāi)發(fā)人員培訓(xùn)
我想這個(gè)不用多說(shuō)了吧,我們都該有緊迫感了。
保證需求文檔的有效性
工作以來(lái)我還從未看過(guò)正式的需求文檔,這也是軟件業(yè)普遍存在的問(wèn)題,因?yàn)槿藗儾恢匾曀,沒(méi)人關(guān)心它是否合理,沒(méi)人關(guān)心它是否實(shí)用,有的甚至是在日后慢慢補(bǔ)進(jìn)去的。所以希望開(kāi)發(fā)公司一定要重視需求文檔,要對(duì)需求文檔有一個(gè)合理性的審查。
從軟件工程學(xué)來(lái)看
首先要從系統(tǒng)分析和編碼入手,提高系統(tǒng)的可靠性,保證代碼的質(zhì)量,增加系統(tǒng)的可擴(kuò)展性和可移植性,降低因需求變更而帶來(lái)的風(fēng)險(xiǎn)和維護(hù)代價(jià)。
從測(cè)試入手,一定要保證測(cè)試的質(zhì)量,并且及時(shí)作測(cè)試。
采用面向?qū)ο?OO)技術(shù)
面向?qū)ο蠓椒▽W(xué)的出發(fā)點(diǎn)和基本原則,是盡可能地模擬人類(lèi)習(xí)慣的思維方式,使開(kāi)發(fā)軟件的方法與過(guò)程盡可能接近人類(lèi)認(rèn)識(shí)世界解決問(wèn)題的方法與過(guò)程,也是使描述問(wèn)題的問(wèn)題域與實(shí)現(xiàn)解法的求解域在結(jié)構(gòu)上盡可能一致。OO 的意義在于分析和設(shè)計(jì)軟件系統(tǒng)的思考方式,以及建立對(duì)象庫(kù)以后的軟件重用將給軟件系統(tǒng)的開(kāi)發(fā)帶來(lái)質(zhì)的改變,但是在建立OO 開(kāi)發(fā)體系之前的過(guò)程,一定會(huì)是一段荊棘遍布的路,需要付出加倍的努力以及達(dá)成思想的轉(zhuǎn)變。這里還有一個(gè)誤區(qū)需要澄清的是很多人以為用了C++,PB ,VB ,DELPHI 是面向?qū)ο蟮拈_(kāi)發(fā)了,其實(shí)只是用了一些面向?qū)ο蟮墓ぞ,骨子里仍然是結(jié)構(gòu)化的分析和設(shè)計(jì)方法,套上一層OOP 的外殼而已。
可見(jiàn),在面對(duì)需求變更時(shí),除了要對(duì)人員培訓(xùn)來(lái)提高開(kāi)發(fā)團(tuán)隊(duì)的整體素質(zhì)外,從系統(tǒng)分析和設(shè)計(jì)角度可以提高產(chǎn)品的可靠性,做到對(duì)需求變更的靈活應(yīng)對(duì),這些至少可以在一定程度上降低產(chǎn)品的風(fēng)險(xiǎn)和維護(hù)代價(jià),提高客戶(hù)的滿(mǎn)意度。
以上這些是我工作以來(lái)對(duì)軟件工程學(xué)以及實(shí)際工作中的一些認(rèn)識(shí),并且參考了一些書(shū)籍和網(wǎng)絡(luò)文獻(xiàn)寫(xiě)出來(lái)的,希望可以對(duì)大家在解決問(wèn)題中有一些實(shí)際的幫助。