濟南軟件開(kāi)發(fā)之較小軟件項目開(kāi)發(fā)的管理

    一個企業的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的經(jīng)驗生搬硬套到 自己身上，可能(néng)會(huì)适得其反。同樣(yàng)，管理一個軟件項目也一樣(yàng)，大項目和小項目的方式不完全一樣(yàng)。但從另一個角度來看，項目的大與小并沒(méi)有本質的區别，很多方法是共通的。 

一、小項目的特點 
　　大家知道(dào)，“軟件危機”的出現起(qǐ)源于一些大型項目的不斷延遲甚至失敗。小項目相比之下，具有以下特點: 
    1、項目功能(néng)相對(duì)較少；2、開(kāi)發(fā)人員較少；3、開(kāi)發(fā)周期較短。
　　另外，在現實中，有很多小項目是由一些中小公司進(jìn)行開(kāi)發(fā)的，這(zhè)些公司往往人員流動性較大，這(zhè)也是不容忽視的一個現實。
二、小項目開(kāi)發(fā)中常犯的錯誤 
　　小項目看起(qǐ)來比較簡單，比較容易成(chéng)功，因而人們往往忽視了小項目的管理，其實這(zhè)是一種(zhǒng)誤解，從經(jīng)驗來看，小項目開(kāi)發(fā)中容易犯以下的一些錯誤: 
　　1、開(kāi)發(fā)之前沒(méi)有認真地進(jìn)行項目可行性和工作量的估計。 
　　往往由于項目較小，便很草率地制定一個開(kāi)發(fā)日程表，沒(méi)有認真地估計項目難度，結果實際完成(chéng)時間 
與估計完成(chéng)時間往往有較大差别。 
　　2、沒(méi)有真正的設計過(guò)程 
　　開(kāi)發(fā)人員少，意味著(zhe)不同人員的程序之間交互、接口相對(duì)少一些。開(kāi)發(fā)周期短意味著(zhe)往往是同樣(yàng)的幾個人從頭到尾負責一個項目。這(zhè)兩(liǎng)者都(dōu)讓人容易犯些錯誤。往往是幾個人碰一下頭，讨論一下最基本的數據結構、函數接口便分頭去做自己的工作了，沒(méi)有一份較正式的文檔。 
　　這(zhè)種(zhǒng)做法潛在的危險之一是有的人可能(néng)會(huì)對(duì)讨論出的接口、結構理解有偏差。一個誤解可能(néng)造成(chéng)以後(hòu)的返工。 
　　另一個潛在的危險是由于讨論時忽略了某些情況，等大家都(dōu)按當時的分工完成(chéng)屬于自己的工作後(hòu)，才發(fā)現各個模塊組合起(qǐ)來卻形不成(chéng)一個完整的系統。其根源在于沒(méi)有一個負責協調的人員不斷監控整個開(kāi)發(fā)過(guò)程。 
　　第三個潛在的危險是一旦有人中途退出開(kāi)發(fā)隊伍，其他人加入時，新來的人難以理解以前别人做好(hǎo)的 
代碼，索性自己從頭來。另外，沒(méi)有文檔的程序，日後(hòu)維護和版本升級都(dōu)比較困難。 
　　3、不經(jīng)過(guò)單元測試而直接進(jìn)入系統測試 
　　造成(chéng)這(zhè)一現象的原因是每個模塊相對(duì)比較簡單，但是爲了測試一個模塊需要建立一些測試環境。 
三、合理的開(kāi)發(fā)流程 
　　合理的開(kāi)發(fā)模式，一句話形容就(jiù)是“麻雀雖小，五髒俱全”，即使是小型項目的開(kāi)發(fā)，仍然應該遵循 
軟件開(kāi)發(fā)的一般規律，必須的步驟不能(néng)省略。但是小項目有它自身的一些特點，實行起(qǐ)來可以相對(duì)靈活些。 
比較合理的模式：
　　1、需求獲取 
　　在進(jìn)入正式開(kāi)發(fā)之前，必須先從用戶處獲取準确的需求。在這(zhè)上面(miàn)花費相當時間是很必要的。 
　　軟件項目可以大緻分爲專用軟件和通用軟件兩(liǎng)大類。 
　　對(duì)于專用軟件，例如給某單位開(kāi)發(fā)一套該單位專用的系統，一般用戶對(duì)于軟件要完成(chéng)哪些功能(néng)已經(jīng)有了一個比較清楚的輪廓，而且往往在開(kāi)發(fā)合同中已經(jīng)大緻地規定了。 
　　但是，開(kāi)發(fā)合同上規定的隻是一個大概的框架，在進(jìn)入開(kāi)發(fā)之前必須與用戶進(jìn)行比較具體的交流和讨論，了解清楚用戶心目中的産品究竟是什麼(me)樣(yàng)子。這(zhè)個步驟如果沒(méi)有好(hǎo)好(hǎo)做，往往到了開(kāi)發(fā)工作的後(hòu)期才發(fā)現開(kāi)發(fā)人員的理解和用戶的要求有一些誤解，那麼(me)必然造成(chéng)時間上的浪費。 
　　對(duì)于通用軟件，在開(kāi)發(fā)之前應該做一定的市場調查工作，一方面(miàn)是從經(jīng)濟效益考慮，調查産品的潛在 
    市場有多大，另一方面(miàn)是從技術的角度，必須了解清楚潛在用戶對(duì)軟件的各種(zhǒng)技術上的要求，例如，用戶現有硬件配置如何，軟件配置如何，使用什麼(me)網絡，使用什麼(me)數據庫等等，根據調查的統計結果決定即將(jiāng)開(kāi)發(fā)的軟件的一些技術指标。 
　　爲了比較好(hǎo)地與用戶進(jìn)行交流，使用一些工具是很有好(hǎo)處的。 
　　2、需求分析 
　　在了解用戶的需求之後(hòu)，將(jiāng)需求用一種(zhǒng)模型來表示，就(jiù)是需求分析，目前比較流行的分析方法是面(miàn)向(xiàng)對(duì)象的方法，通過(guò)分析用戶需求，用類、類之間的各種(zhǒng)關系來表示整個系統。 
　　這(zhè)部分涉及到具體的方法，在此不詳細讨論，但是原則上是提取類->類之間關系,可能(néng)需要不斷修改而形成(chéng)一份分析文檔。 
　　對(duì)于需求潛在變化不大的項目，可以采用瀑布模型，有一個很明顯的設計階段，這(zhè)樣(yàng)做的好(hǎo)處是有一 
份比較完整的分析文檔，這(zhè)樣(yàng)以後(hòu)如果需要采用不同的編程語言、或者采用其他的平台時，便可以以這(zhè)份 
分析文檔作爲開(kāi)發(fā)的基礎。 
　　對(duì)于需求變化頻繁的項目，可能(néng)采用少量分析->少量設計->少量編碼->測試的方式更合适，而且随時 
可能(néng)要返回到前面(miàn)某個一階段去進(jìn)行修改。但是這(zhè)意味著(zhe)可能(néng)沒(méi)有一份完整的分析文檔。 
　　現在很多CASE工具并不區分分析和設計的階段。但是，這(zhè)并不意味著(zhe)開(kāi)發(fā)就(jiù)可以對(duì)分析和設計不加區 
分，CASE工具如同一支筆，如何用好(hǎo)還(hái)得還(hái)人。 
　　3、設計過(guò)程 
　　設計階段的工作包括：
　　對(duì)分析模型必要的修改。可能(néng)需要對(duì)某些類結構進(jìn)行一些修改，這(zhè)些修改的原因可能(néng)是編程環境的要求，或者爲了重用以前的某些工作。 
　　由于目前很多編程語言都(dōu)可以可視化地設計界面(miàn)，所以界面(miàn)部分工作往往留到了編碼階段來完成(chéng)。于是設計階段的工作量并不大。 
　　4、編碼 
　　進(jìn)入編碼工作之後(hòu)，可能(néng)會(huì)發(fā)現前面(miàn)分析或設計階段的某些錯誤，這(zhè)時應返回到前面(miàn)的階段進(jìn)行必要的修改。 
　　5、測試 
　　如前所述，即使是小項目，也應該嚴格地進(jìn)行測試。 
四、人員的安排 
　　比較小的項目，往往是幾個人來完成(chéng)，這(zhè)幾個人基本上從頭到尾參加開(kāi)發(fā)。在這(zhè)幾個人中，有一位項目負責人，負責分析、設計和協調的工作。由于項目小，項目負責人也要參加編程,那麼(me)這(zhè)人必須把時間合理運用。
　　經(jīng)驗告訴我幾條原則: 
　　1、協調幾個人的工作比自己完成(chéng)一段編碼更重要。
　　由于協調上出了漏洞，可能(néng)導緻很大的問題，所以項目負責人必須随時監控各開(kāi)發(fā)人員的工作，包括内容是否與要求發(fā)生偏差，進(jìn)度是否滞後(hòu)等等。 
　　隻有在完成(chéng)這(zhè)些工作之後(hòu)，項目負責人剩下的時間才能(néng)用于編程。 
　　2、給每個開(kāi)發(fā)人員明确的任務書。
　　不管是用面(miàn)向(xiàng)對(duì)象或者其他方法開(kāi)發(fā)，分析、設計模型隻是從功能(néng)的角度來描述系統。但是，具體開(kāi)發(fā)時每個開(kāi)發(fā)人員必須非常明确自己的任務，這(zhè)些任務應該采用明确的文檔來表示。 
　　3、讓大家都(dōu)大緻熟悉設計模型。
　　讓每個開(kāi)發(fā)人員都(dōu)清楚自己所做的工作在整個系統中處于什麼(me)地位，有時侯可能(néng)會(huì)發(fā)現設計模型中的漏洞，避免了各人的代碼編寫完畢之後(hòu)又要修改的後(hòu)果。