單元六產(chǎn)品開發(fā)流程及有關(guān)知識6．1產(chǎn)品開發(fā)流程16．2小項目開發(fā)管理36．1產(chǎn)品開發(fā)流程6．2小項目開發(fā)管理一個公司的管理，大公司有大公司的方式，小公司也有小公司的方式，假如把他人的經(jīng)驗生搬硬套到自己身上，可能會事與愿違。相同，管理一個開發(fā)項目也相同，大項目和小項目的方式不完好相同。但從另一個角度來看，項目的大與小并無實質(zhì)的差異，好多方法是共通的。６．２．1小項目的特色大家知道，"軟件危機"的出現(xiàn)發(fā)源于一些大型項目的不停延緩甚至失敗。小項目對比之下，擁有以下特色:項目功能相對較少開發(fā)人員較少開發(fā)周期較短此外，在現(xiàn)實中，有好多小項目是由一些中小公司進(jìn)行開發(fā)的，這些公司常常人員流動性較大，這也是不容忽視的一個現(xiàn)實.６．２．2小項目開發(fā)中常犯的錯誤小項目看起來比較簡單，比較簡單成功，因此人們常常忽視了小項目的管理，其實這是一種誤會，小項目開發(fā)中簡單犯以下的一些錯誤:開發(fā)從前沒有仔細(xì)地進(jìn)行項目可行性和工作量的預(yù)計。常常因為項目較小，便很輕率地擬訂一個開發(fā)日程表，沒有仔細(xì)地預(yù)計項目難度，結(jié)果實質(zhì)達(dá)成時間與預(yù)計達(dá)成時間常常有較大差異。沒有真實的設(shè)計過程開發(fā)人員少，意味著不一樣人員的模塊之間交互、接口相對少一些。開發(fā)周期短意味著常常是相同的幾個人重新到尾負(fù)責(zé)一個項目。這二者都讓人簡單犯些錯誤。常常是幾個人碰一下頭，議論一下最基本的；軟硬件構(gòu)造、函數(shù)接口便分頭去做自己的工作了，沒有一份較正式的文檔。這類做法潛伏的危險之一是有的人可能會對議論出的接口、構(gòu)造理解有誤差(應(yīng)當(dāng)認(rèn)可人是會出錯誤的)。一個誤會可能造成此后的返工。另一個潛伏的危險是因為議論時忽視了某些狀況，等大家都按當(dāng)時的分工達(dá)成屬于自己的工作后，才發(fā)現(xiàn)各個模塊組合起來卻形不可一個完好的系統(tǒng)。其本源在于沒有一個負(fù)責(zé)協(xié)調(diào)的人員不停監(jiān)控整個開發(fā)過程。第三個潛伏的危險是一旦有人半途退出開發(fā)隊伍，其余人加入時，新來的人難以理解從前他人做好的代碼，干脆自己重新來。此外，沒有文檔的程序，往后保護(hù)和版本升級都比較困難。不經(jīng)過單元測試而直接進(jìn)入系統(tǒng)測試造成這一現(xiàn)象的原由是每個模塊相對照較簡單，可是為了測試一個模塊需要成立一些測試環(huán)境。比如，為了測試一個函數(shù)能否正確，應(yīng)當(dāng)用一些測試數(shù)據(jù)去調(diào)用該函數(shù)，需要編寫一些測試數(shù)據(jù)。但好多開發(fā)人員嫌麻煩，感覺反正其余模塊也很快出來了，直接用真正的數(shù)據(jù)來運轉(zhuǎn)幾次就行了。卻不知，一旦直接進(jìn)入系統(tǒng)測試，發(fā)現(xiàn)運轉(zhuǎn)結(jié)果不正確后需要一步步查找。因為模塊間的調(diào)用關(guān)系，可能查了好久才發(fā)現(xiàn)是某個模塊的問題。這類方法一來效率比較低，大批的時間用在了將一個錯誤定位在模塊上了。此外因為這類測試不完好，真實運轉(zhuǎn)系統(tǒng)，當(dāng)調(diào)用某模塊時，可能大多數(shù)時候都是正常數(shù)據(jù)，很少出現(xiàn)界限狀況，可能某些界限狀況容易被忽視，好久以后才被發(fā)現(xiàn)。可是假如對每個模塊進(jìn)行單元測試時都進(jìn)行一下界限測試，就會很簡單除去一些隱患。真堪稱欲速則不達(dá)也。６．２．3合理的開發(fā)流程合理的開發(fā)模式，一句話形容就是"麻雀雖小，五臟俱全"，即便是小型項目的開發(fā)，仍舊應(yīng)當(dāng)按照項目開發(fā)的一般規(guī)律，一定的步驟不可以省略?？墒切№椖坑兴约旱囊恍┨攸c，推行起來能夠相對靈巧些。以下從幾個方面描繪一下比較合理的模式.需求獲得在進(jìn)入正式開發(fā)從前，一定先從用戶處獲得正確的需求。在這上邊花銷相當(dāng)時間是很必需的。項目能夠大概分為拜托開發(fā)和公司立項開發(fā)兩大類。關(guān)于拜托開發(fā)，比如給某單位開發(fā)一套該單位專用的系統(tǒng)，一般用戶關(guān)于項目要達(dá)成哪些功能已經(jīng)有了一個比較清楚的輪廓，并且常常在開發(fā)合同中已經(jīng)大概地規(guī)定了。可是，開發(fā)合同上規(guī)定的不過一個大體的框架，在進(jìn)入開發(fā)從前一定與用戶進(jìn)行比較詳細(xì)的溝通和議論，認(rèn)識清楚用戶心目中的產(chǎn)品終究是什么樣子。這個步驟假如沒有好好做，常常到了開發(fā)工作的后期才發(fā)現(xiàn)開發(fā)人員的理解和用戶的要求有一些誤會，那么必定造成時間上的浪費。關(guān)于公司立項開發(fā)的項目，在開發(fā)從前應(yīng)當(dāng)做必定的市場檢查工作，一方面是從經(jīng)濟效益考慮，檢查產(chǎn)品的潛伏市場有多大，另一方面是從技術(shù)的角度，一定認(rèn)識清楚潛伏用戶對產(chǎn)品的各樣功能上的要求，比如，用戶此刻使用什么產(chǎn)品，對該產(chǎn)品有什么建議和要求等等，依據(jù)檢查的統(tǒng)計結(jié)果斷定馬上開發(fā)的產(chǎn)品的一些技術(shù)指標(biāo)。為了比較好地與用戶進(jìn)行溝通，使用一些工具是很有利處的。需求剖析在認(rèn)識用戶的需求以后，將需求用一種模型來表示，就是需求剖析。這部分波及到詳細(xì)的方法，在此不詳盡議論，可是原則上可能需要不停改正而形成一份剖析文檔。重申幾個問題:（1）要分清問題域與系統(tǒng)責(zé)任系統(tǒng)責(zé)任是指所要開發(fā)的項目應(yīng)當(dāng)達(dá)成的功能，而問題域是包含全部有關(guān)的部分。比如你要開發(fā)一個程控機計費程序，程控機已經(jīng)是現(xiàn)成，輸出的數(shù)據(jù)格式也已經(jīng)是固定的，你的程序不過需要從程控機中讀取相應(yīng)的信息，那么，"程控機"在你的系統(tǒng)里不過一個外面的東西，把它作為一個類或許就是不用要的，不過需要一個類來達(dá)成讀數(shù)據(jù)的操作。又如，你需要在一個已經(jīng)存在的數(shù)據(jù)庫上開發(fā)一些應(yīng)用，數(shù)據(jù)庫的格式已經(jīng)固定，并且已經(jīng)有一個后臺程序在運轉(zhuǎn)，你需要開發(fā)一個新的前臺程序，這時，服務(wù)器程序?qū)δ銇碚f就是一個外面的東西。可是，象這類外面的內(nèi)容一定在剖析文檔中有一些說明，作為系統(tǒng)的外在拘束。2）需求獲得與需求剖析的關(guān)系用什么方法來達(dá)成需求的獲得，在很大程度上影響了需求剖析的做法。比如當(dāng)初采納UseCase來表示用戶需求，那么從各樣序列圖中選出互相交互的各個實體，就是一個個類。3）剖析與設(shè)計過程的連接剖析過程的內(nèi)容是用類的構(gòu)造來表示目標(biāo)系統(tǒng)，其實不設(shè)計詳細(xì)實現(xiàn)，如采納什么編程語言，在什么操作系統(tǒng)平臺上運轉(zhuǎn)等等。這些詳細(xì)實現(xiàn)是在設(shè)計階段來達(dá)成的。面向?qū)ο蠓椒ǖ拈L處是剖析、設(shè)計、編碼過程表示法一致，能比較好的連接。可是，是把剖析和設(shè)計階段分開，采納瀑布式開發(fā)，仍是采納其余方式，要看詳細(xì)的狀況。關(guān)于需求潛伏變化不大的項目，能夠采納瀑布模型，有一個很顯然的設(shè)計階段，這樣做的利處是有一份比較完好的剖析文檔，這樣此后假如需要采納不一樣的編程語言、或許采納其余的平臺時，便能夠以這份剖析文檔作為開發(fā)的基礎(chǔ)。關(guān)于需求變化屢次的項目，可能采納少許剖析;少許設(shè)計;少許編碼;測試的方式更適合，并且隨時可能要返回到前面某個一階段去進(jìn)行改正。可是這意味著可能沒有一份完好的剖析文檔。此刻好多CASE工具其實不劃分剖析和設(shè)計的階段。可是，這其實不意味著開發(fā)就能夠?qū)ζ饰龊驮O(shè)計不加劃分，CASE工具好像一支筆，怎樣用好還得還人。設(shè)計過程設(shè)計階段的工作包含:對剖析模型必需的改正?？赡苄枰獙δ承╊悩?gòu)造進(jìn)行一些改正，這些改正的原由可能是編程環(huán)境的要求，或許為了重用從前的某些工作。定義界面部分、數(shù)據(jù)接見(數(shù)據(jù)庫)部分。因為當(dāng)前好多編程語言都能夠可視化地設(shè)計界面，因此界面部分工作常常留到了編碼階段來達(dá)成。于是設(shè)計階段的工作量其實不大。編碼進(jìn)入編碼工作以后，可能會發(fā)現(xiàn)前面剖析或設(shè)計階段的某些錯誤，這時應(yīng)返回到前面的階段進(jìn)行必需的改正。測試如前所述，即便是小項目，也應(yīng)當(dāng)嚴(yán)格地進(jìn)行測試。６．２．4人員的安排比較小的項目，常常是幾個人來達(dá)成，這幾個人基本上重新到尾參加開發(fā)。在這幾個人中，有一位項目負(fù)責(zé)人，負(fù)責(zé)剖析、設(shè)計和協(xié)調(diào)的工作。因為項目小，項目負(fù)責(zé)人也要參加編程,那么此人一定把時間合理運用，注意以下以點原則:1.協(xié)調(diào)幾個人的工作比自己達(dá)成一段編碼更重要.因為協(xié)調(diào)上出了破綻，可能致使很大的問題，因此項目負(fù)責(zé)人一定隨時監(jiān)控各開發(fā)人員的工作，包含內(nèi)容能否與要求發(fā)生誤差，進(jìn)度能否滯后等等。只有在達(dá)成這些工作以后，項目負(fù)責(zé)人剩下的時間才能用于編程。2.給每個開發(fā)人員明確的任務(wù)書.不論