軟體專案管理在小軟體專案中的應用

【摘要】資訊科技的飛速發展已是無需爭論的事實，軟體產業的創造的價值也在逐年增加，在某些國家軟體開發已然成為了支柱產業。在看到我國軟體開發人員的不斷成熟，軟體開發環境不斷與國際社會接軌的同時，我們也不能忽視我國當前軟體行業存在的弊端：缺乏統一的行業標準和相應的法律法規，一些中小型軟體專案仍然以原始的個人或者小團體為主的手工作坊式的方式進行開發，在大量浪費人力物力的同時也使得程式設計師辛苦創造的價值在無形之中流失。很多人認為小型軟體專案不需要嚴格的管理，事實上恰恰與此相反，小型軟體專案不單需要進行專案管理，而且不能完全照搬大型軟體專案的管理方式和開發模式，應該遵循一種適合小型軟體專案的管理方式；但從另一個角度來看，專案的大與小並沒有本質的區別，很多方法是共通的。本文的目的是從作者的經驗來談談小專案開發的管理。 
【關鍵詞】小軟體專案 專案管理 軟體開發 

【正文】 

　　第一部分 軟體專案管理概述 

　　1-1軟體專案管理的目的 

　　從概念上講，軟體專案管理是為了使軟體專案能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。實際上，軟體專案管理的意義不僅僅如此，進行軟體專案管理有利於將開發人員的個人開發能力轉化成企業的開發能力，企業的軟體開發能力越高，表明這個企業的軟體生產越趨向於成熟，企業越能夠穩定發展（即減小開發風險）。  

　　軟體開發不同於其他產品的製造，軟體的整個過程都是設計過程（沒有製造過程）；另外，軟體開發不需要使用大量的物質資源，而主要是人力資源；並且，軟體開發的產品只是程式程式碼和技術檔案，並沒有其他的物質結果。基於上述特點，軟體專案管理與其他專案管理相比，有很大的獨特性。專案管理的根本焦點集中在T、Q、C、S上，即：開發進度（The progress of development）、特性與品質（Character and Quality）、成本（Cost）、顧客服務（Service）。其中最核心的是開發進度、特性與品質兩個方面。其它一切管理工作都必須圍繞這些焦點進行。 

　　1-2軟體專案管理的內容  

　　從軟體工程的角度講，軟體開發主要分為六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。不論是作坊式開發，還是團隊協作開發，這六個階段都是不可缺少的。  

　　1-3軟體專案管理的原則 

　　在八十年代初，著名軟體工程專家B．W．Boehm①總結出了軟體開發時需遵循的七條基本原則，同樣，我們在進行軟體專案管理時，也應該遵循這七條原則。它們是：  

　　（1）用分階段的生命週期計劃嚴格管理；  
　　（2）堅持進行階段評審；  
　　（3）實行嚴格的產品控制；
　　（4）採用現代程式設計技術；  。
　　（5）結果應能夠清楚地審查；  
　　（6）開發小組地人員應該少而精；  
　　（7）承認不斷改進軟體工程實踐地必要性。

第二部分 小軟體專案開發
　　2-1小專案的特點 

　　本文所說的“小軟體專案”是指直接開發人員的數目在3-10人，軟體開發的週期在1-5個月之間，程式碼數量在5000-20000行，子程式數量在100-500之間的小型軟體開發專案。  

　　大家知道，“軟體危機②”的出現起源於一些大型專案的不斷延遲甚至失敗。小專案相比之下，具有以下特點：

　　•專案功能相對較少 
　　•開發人員較少  
　　•開發週期較短  

　　另外，在現實中，有很多小專案的開發人員流動性較大，這也是不容忽視的一個現實。

　　2-2小專案開發中常犯的錯誤 　　 

　　小專案看起來比較簡單，比較容易成功，因而人們往往忽視了小專案的管理，其實這是一種誤解，從本人的經驗看來，小專案開發中容易犯以下的一些錯誤： 
　　
　　1、開發之前沒有認真地進行專案可行性和工作量的估計。往往由於專案較小，便很草率地制定一個開發日程表，沒有認真地估計專案難度，結果實際完成時間與估計完成時間往往有較大差別。 
　　
　　2、沒有真正的設計過程 
　　
　　開發人員少，意味著不同人員的程式之間互動、介面相對少一些。開發週期短意味著往往是同樣的幾個人從頭到尾負責一個專案。這兩者都讓人容易犯些錯誤。往往是幾個人碰一下頭，討論一下最基本的資料結構、函式介面便分頭去做自己的工作了，沒有一份較正式的文件。 
　　
　　這種做法潛在的危險之一是有的人可能會對討論出的介面、結構理解有偏差(應該承認人是會犯錯誤的)。一個誤解可能造成以後的返工。  
 
　　另一個潛在的危險是由於討論時忽略了某些情況，等大家都按當時的分工完成屬於自己的工作後，才發現各個模組組合起來卻形不成一個完整的系統。其根源在於沒有一個負責協調的人員不斷監控整個開發過程。 
　　
　　第三個潛在的危險是一旦有人中途退出開發隊伍，其他人加入時，新來的人難以理解 以前別人做好的程式碼，索性自己從頭來。另外，沒有文件的程式，日後維護和版本升級都比較困難。 

3、不經過單元測試而直接進入系統測試 
　　
　　造成這一現象的原因是每個模組相對比較簡單，但是為了測試一個模組需要建立一些測試環境。例如，為了測試一個函式是否正確，應該用一些測試資料去呼叫該函式，需要編寫一些測試資料。但很多開發人員嫌麻煩，覺得反正其他模組也很快出來了，直接用真正的資料來執行幾次就行了。　　
　　殊不知，一旦直接進入系統測試，發現執行結果不正確後需要一步步查詢。由於模組間的呼叫關係，可能查了很久才發現是某個模組的問題。這種方法一來效率比較低，大量的時間用在了將一個錯誤定位在模組上了。另外由於這種測試不完全，真正執行系統，當呼叫某模組時，可能大部分時候都是正常資料，極少出現邊界情況，可能某些邊界情況容易被忽視，很久之後才被發現。但是如果對每個模組進行單元測試時都進行一下邊界測試，就會很容易消除一些隱患。真可謂欲速則不達也。 

　　2-3合理的開發流程  
　　
　　合理的開發模式，一句話形容就是“麻雀雖小，五臟俱全”，即使是小型專案的開發，仍然應該遵循軟體開發的一般規律，必須的步驟不能省略。但是小專案有它自身的一些特點，實行起來可以相對靈活些。 
　　
　　以下我從幾個方面描述一下我認為比較合理的模式。 

　　1、需求獲取 
　　
　　在進入正式開發之前，必須先從使用者處獲取準確的需求。在這上面花費相當時間是很必要的。 
　　
　　軟體專案可以大致分為專用軟體和通用軟體兩大類。 
　　
　　對於專用軟體，例如給某單位開發一套該單位專用的系統，一般使用者對於軟體要完成哪些功能已經有了一個比較清楚的輪廓，而且往往在開發合同中已經大致地規定了。 
　　
　　但是，開發合同上規定的只是一個大概的框架，在進入開發之前必須與使用者進行比較具體的交流和討論，瞭解清楚使用者心目中的產品究竟是什麼樣子。這個步驟如果沒有好好做，往往到了開發工作的後期才發現開發人員的理解和使用者的要求有一些誤解，那麼必然造成時間上的浪費。  
　　
　　對於通用軟體，在開發之前應該做一定的市場調查工作，一方面是從經濟效益考慮，調查產品的潛在市場有多大，另一方面是從技術的角度，必須瞭解清楚潛在使用者對軟體的各種技術上的要求，例如，使用者現有硬體配置如何，軟體配置如何，使用什麼網路，使用什麼資料庫等等，根據調查的統計結果決定即將開發的軟體的一些技術指標。 
　　
　　為了比較好地與使用者進行交流，使用一些工具是很有好處的。為了討論使用者介面，可以用VB, delphi等做一個原型，根據原型有針對性地與使用者討論需求。(原型開發不僅僅可以用於準確獲取使用者的需求，開發出來的原型本身可以作為下一步開發的基礎，增量式地完成開發) 
　　
　　為了討論軟體執行的流程，可以採用UML③的Use Case圖④。 

　　2、需求分析 

在瞭解使用者的需求之後，將需求用一種模型來表示，就是需求分析，目前比較流行的 分析方法是物件導向的方法，通過分析使用者需求，用類、類之間的各種關係來表示整個系統。 
　　
　　這部分涉及到具體的方法，在此不詳細討論，但是原則上是提取類->類之間關係,可能需要不斷修改而形成一份分析文件。 

　　3、設計過程 
　　
　　設計階段的工作包括： 
　　
　　對分析模型必要的修改。可能需要對某些類結構進行一些修改，這些修改的原因可能是程式設計環境的要求，或者為了重用以前的某些工作。定義介面部分、資料訪問(資料庫)部分。 
　　
　　由於目前很多程式語言都可以視覺化地設計介面，所以介面部分工作往往留到了編碼階段來完成。於是設計階段的工作量並不大。 

　　4、編碼 
　　
　　進入編碼工作之後，可能會發現前面分析或設計階段的某些錯誤，這時應返回到前面的階段進行必要的修改。 

　　5、測試 
　　
　　如前所述，即使是小專案，也應該嚴格地進行測試。 

　　2-4需要強調幾個問題 

　　一、是要分清問題域與系統責任。 

　　系統責任是指所要開發的軟體應該完成的功能，而問題域是包含所有相關的部分。例如你要開發一個程控機計費程式，程控機已經是現成，輸出的資料格式也已經是固定的，你的程式僅僅需要從程控機中讀取相應的資訊，那麼，程控機在你的系統裡只是一個外部的東西，把它作為一個類也許就是不必要的，僅僅需要一個類來完成讀資料的操作。又如，你需要在一個已經存在的資料庫上開發一些應用，資料庫的格式已經固定，並且已經有一個後臺程式在執行，你需要開發一個新的前臺程式，這時，伺服器程式對你來說就是一個外部的東西。但是，象這種外部的內容必須在分析文件中有一些說明，作為系統的外在約束。  

　　二、是需求獲取與需求分析的關係。 

　　用什麼方法來完成需求的獲取，在很大程度上影響了需求分析的做法。例如當初採用Use Case來表示使用者需求，那麼從各種序列圖中選出相互互動的各個實體，就是一個個類。

三、是分析與設計過程的銜接。 
　　
　　分析過程的內容是用類的結構來表示目標系統，並不設計具體實現，如採用什麼程式設計 語言，在什麼作業系統平臺上執行等等。這些具體實現是在設計階段來完成的。物件導向方法的優點是分析、設計、編碼過程表示法統一，能比較好的銜接。但是，是把分析和設 計階段分開，採用瀑布式開發，還是採用其他方式，要看具體的情況。 
　　
　　對於需求潛在變化不大的專案，可以採用瀑布模型，有一個很明顯的設計階段，這樣做的好處是有一份比較完整的分析文件，這樣以後如果需要採用不同的程式語言、或者採 用其他的平臺時，便可以以這份分析文件作為開發的基礎。 
　　
　　對於需求變化頻繁的專案，可能採用少量分析;少量設計少量編碼測試的方式更合適，而且隨時可能要返回到前面某個一階段去進行修改。但是這意味著可能沒有一份完整的分析文件。  
現在很多CASE工具⑤並不區分分析和設計的階段。但是，這並不意味著開發就可以對分析和設計不加區分，CASE工具如同一支筆，如何用好還得還人。 

　　四、人員的安排 
　　
　　比較小的專案，往往是幾個人來完成，這幾個人基本上從頭到尾參加開發。在這幾個人中，有一位專案負責人，負責分析、設計和協調的工作。由於專案小，專案負責人也要參加程式設計,那麼這人必須把時間合理運用。 

　　第三部分 小結 

　　很多專案基本上都存在這樣的問題： 

　　1．缺乏詳細的需求分析。習慣了的個人開發模式是，詳細瞭解專案的要求與功能之後，開一個基本的框架，即小樣。不斷與使用者溝通，細化到每個元件子程式的詳細功能，並進行測試,逐步完善。因為缺乏全域性的需求分析，經常反工，浪費大量的時間和人力物力。 

　　2．沒有完整的開發文件。一個完整的軟體專案應包括以下的相關文件： 

　　專案開發計劃 
　　測試分析報告  
　　概要設計說明書 
　　測試計劃
　　操作手冊  
　　模組開發卷宗 
　　使用者手冊  
　　專案開發總結報告 
　　詳細設計說明書

資料要求說明書 
　　軟體需求說明書 
　　可行性研究報告 
　　開發進度月報 
　　資料庫設計說明書 
　　模組開發卷宗 
　　使用者手冊 
　　專案開發計劃
　　專案開發總結報告 

　　而在實際中，只有簡單的使用者操作手冊和開發日誌。由於缺乏詳細的開發文件，導致軟體的開發完全脫離計劃，對開發週期有相當大的影響；所有的資料全部包含在軟體中，加大了和使用者溝通的難度；後期的軟體測試和維護無章可循。 

　　3．沒有專門的美工和測試人員。開發出的軟體成品，外觀較差；自己設計的程式碼自己測試，這是軟體測試的大忌，給後期的系統全域性測試留下較多的隱患。是開發週期變長，成本變大。幾乎全域性測試要佔用整個開發週期的一半以上！ 

　　經驗告訴我幾條原則： 

　　1、協調幾個人的工作比自己完成一段編碼更重要。 
　　
　　由於協調上出了漏洞，可能導致很大的問題，所以專案負責人必須隨時監控各開發人員的工作，包括內容是否與要求發生偏差，進度是否滯後等等。  
　　
　　只有在完成這些工作之後，專案負責人剩下的時間才能用於程式設計。  
　　
　　2、給每個開發人員明確的任務書。 
　　
　　不管是用物件導向或者其他方法開發，分析、設計模型只是從功能的角度來描述系 統。但是，具體開發時每個開發人員必須非常明確自己的任務，這些任務應該採用明確的文件來表示。 
　　
　　3、讓大家都大致熟悉設計模型。 

　　讓每個開發人員都清楚自己所做的工作在整個系統中處於什麼地位，有時侯可能會發現設計模型中的漏洞，避免了各人的程式碼編寫完畢之後又要修改的後果。

【註釋】 
①Barry W.Boehm博士是軟體業中最有影響的專家之一，他開創並發展了COCOMO II模型。他的經典著作《Software Engineering Economics》（軟體工程經濟學）奠定了軟體成本估算領域的基礎。Boehm博十與美國南加州大學軟體工程中心的其他同事—起，引領著軟體成本估算技術的發展。 

②軟體危機指的是在計算機軟體的開發和維護過程中所遇到的一系列嚴重問題。 1968年北大西洋公約組織的電腦科學家在聯邦德國召開的國際學術會議上第一次提出了“軟體危機”(software crisis)這個名詞。概括來說，軟體危機包含兩方面問題：一、如何開發軟體，以滿足不斷增長，日趨複雜的需求；二、如何維護數量不斷膨脹的軟體產品。  

③Unified Modeling Language，統一建模語言。1997年，OMG組織（Object Management Group物件管理組織）釋出了統一建模語言。UML的目標之一就是為開發團隊提供標準通用的設計語言來開發和構建計算機應用。UML提出了一套IT專業人員期待多年的統一的標準建模符號。通過使用UML，這些人員能夠閱讀和交流系統架構和設計規劃--就像建築工人多年來所使用的建築設計圖一樣。UML是一種定義良好、易於表達、功能強大且普遍適用的建模語言。它溶入了軟體工程領域的新思想、新方法和新技術。它的作用域不限於支援物件導向的分析與設計,還支援從需求分析開始的軟體開發的全過程。 

④用例檢視(use case view)。用例圖描述了系統提供的一個功能單元。用例圖的主要目的是幫助開發團隊以一種視覺化的方式理解系統的功能需求，包括基於基本流程的"角色"（actors，也就是與系統互動的其他實體）關係，以及系統內用例之間的關係。用例圖一般表示出用例的組織關係--要麼是整個系統的全部用例，要麼是完成具有功能（例如，所有安全管理相關的用例）的一組用例。要在用例圖上顯示某個用例，可繪製一個橢圓，然後將用例的名稱放在橢圓的中心或橢圓下面的中間位置。要在用例圖上繪製一個角色（表示一個系統使用者），可繪製一個人形符號。角色和用例之間的關係使用簡單的線段來描述，如圖所示。 

⑤CASE，Computer-Aided Software Engineering。一般認為，UML CASE工具應該有一些共同的特性：  
•方便地製圖及糾錯  
•管理模型的資訊，修改具有關聯性  
•在模型元素之間易於導航  
•支援多使用者協同工作  
•支援程式碼框架生成  
•支援逆向轉換，即由程式碼生成模型  
•支援更多的開發環境  
•其它  
目前的CASE工具可能並不相互相容。由此也產生了模型互換的概念，就是某個工具產生的模型要能夠應用到其它工具中去。各種工具一般都是用自己的資料庫來儲存模型資訊，而實現模型互換的前提是將這樣的儲存模型的格式標準化，標準化的益處是顯而易見的，但是目前還沒有相應的標準。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780914/viewspace-409942/，如需轉載，請註明出處，否則將追究法律責任。