在一個軟件產(chǎn)品發(fā)布并使用之后，其中肯定有許多地方不如意和值得改進的地方�？蛻粼谑褂玫倪^程中會發(fā)現(xiàn)一些問題，提出更高的需求，市場也在發(fā)生變化，我們的競爭對手也在發(fā)展，新的技術(shù)不斷地產(chǎn)生，這些因素推動著我們的產(chǎn)品不斷地向前發(fā)展，使軟件版本不停地往上增長。這些發(fā)展的需求不是一下子提出來的，在客戶使用的過程中發(fā)現(xiàn)某些不如意不方便的地方，他們會向我們提出寶貴的意見，而技術(shù)人員會把這些需求記錄下來，以便修改或成為下一個版本的新特性或需求。

一個軟件的開發(fā)主要分為需求、設(shè)計、編碼、測試、維護幾個重要的階段，下面每個階段的一些管理措施提點愚見：

1. 需求管理

在進入正式開發(fā)之前，必須先從用戶處獲取準(zhǔn)確的需求。在這上面花費相當(dāng)時間是很必要的。在軟件項目的開發(fā)過程中，需求變更貫穿了軟件項目的整個生命周期，從軟件的項目立項，研發(fā)，維護，用戶的經(jīng)驗在增加，對使用軟件的感受有變化，以及整個行業(yè)的新動態(tài)，都為軟件帶來不斷完善功能 ，優(yōu)化性能，提高用戶友好性的要求。在軟件項目管理過程中，項目經(jīng)理經(jīng)常面對用戶的需求變更。如果不能有效處理這些需求變更，項目計劃會一再調(diào)整，軟件交付日期一再拖延，項目研發(fā)人員的士氣將越來越低落，將直接導(dǎo)致項目成本增加、質(zhì)量下降及項目交付日期推后。這決定了項目組必須擁有需求管理策略。

在整個開發(fā)周期中期望用戶的需求一直保持不變是不大可能的，因為用戶對于如何應(yīng)用計算機軟件并沒有一個成熟的經(jīng)驗。需求變化的原因很多，如：

一開始沒有調(diào)研全，需要增加需求;

客戶需求發(fā)生了變化，需求必須變化;

需求錯誤;

需求不清楚。

基于上述的問題，必須對需求進行管理，使需求能夠真正成為軟件工程和管理的基線。 一種比較明智的方法是在簽定開發(fā)合同(協(xié)議)時把用戶需求的改動和經(jīng)濟利益掛鉤，如果用戶增加或改動了需求，那么軟件的交付日期可以推遲，費用也應(yīng)增加。

需求是一項復(fù)雜的工作，使用的方法也很多，不同的開發(fā)方式有不同的方法，這里簡單介紹一些相關(guān)的方法：

可行性分析：在允許的成本、性能要求下，分析每項需求實施的可行性，提出需求實現(xiàn)相關(guān)風(fēng)險，包括與其它需求的沖突，對外界因素的依賴和技術(shù)障礙。

快速原型：當(dāng)用戶自身對有的需求不十分清楚時，我們可以建立一個系統(tǒng)原型，用戶通過評價原型更好地理解所要解決的問題。

圖形分析模型：繪制圖形分析模型是編制軟件需求規(guī)格說明重要手段。它們能幫助分析人員理清數(shù)據(jù)、業(yè)務(wù)模式、工作流程以及他們之間的關(guān)系，找出遺漏、冗余和不一致的需求。這樣的模型包括數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。

數(shù)據(jù)字典：數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應(yīng)定義客戶數(shù)據(jù)項，確�？蛻襞c開發(fā)小組是使用一致的定義和術(shù)語。

2. 設(shè)計管理

項目經(jīng)理把功能模塊分配給每個開發(fā)人員，每個開發(fā)人員把自己相關(guān)的功能模塊收集起來，同時預(yù)估時間，其中主要包括寫文檔的時間、開發(fā)時間和單元測試的時間，一般要求精確到工作日。這些信息返回給項目經(jīng)理，項目經(jīng)理再把本小組人員的任務(wù)和預(yù)估時間發(fā)送給管理層，由管理層對此任務(wù)及進度進行評估審核，管理層會根據(jù)產(chǎn)品發(fā)布時間及客戶需求、市場因素等方面作出選擇，可能某些功能由于時間緊急會被推遲到下一個版本中去。若預(yù)估出來的時間同預(yù)計的產(chǎn)品發(fā)布時間有較大沖突，而且此功能是本版本中必須得做的，則開發(fā)小組會被要求重新預(yù)估時間，加快開發(fā)速度來達到這個要求。

雖然這個開發(fā)進度時間是一個大概的估計時間，但我們要盡力按照這個開發(fā)進度來執(zhí)行。作為開發(fā)人員每個星期寫一篇周記，描述自己本周所做的工作，根據(jù)自己的描述來評估我們自己的工作，每個人手上的工作是否按照這個進度在走，是否有人延后了，是否延誤了別人的工作。在周記里每個人都要報告自己的進度，同時還要報告上個星期做了什么，正在做什么，以及下個星期打算做什么。通過這個周記，會讓你覺得有人在監(jiān)督你，無形之中迫使你不斷地督促自己不要使任務(wù)延后，如果有延后的跡象也會盡早發(fā)現(xiàn)而趕上。若某些經(jīng)過努力不能趕上，那也沒有辦法，只能修改原先的進度表，因為那是我們的估計與現(xiàn)實發(fā)生了偏差，我們必須使我們的進度表符合實際情況。

3. 編碼管理

進入編碼工作之后，可能會發(fā)現(xiàn)前面分析或設(shè)計階段的某些錯誤，這時應(yīng)返回到前面的階段進行必要的修改。由于我們用asp.net(c#)語言進行開發(fā)，因此我們借助了VS2005工具。關(guān)于代碼風(fēng)格，我們基本上套用VS2005中自動的代碼格式編排。良好的編碼習(xí)慣有利于我們提高整個團對的開發(fā)效率，比如變量的命名、寫代碼時要對類及函數(shù)提供詳細的注釋及說明等，基本做到看它們的說明能知道這個變量、類或函數(shù)的功能以及主要算法的實現(xiàn)原理。在開發(fā)過程中對主要的模塊要編寫單元測試，同時要單元測試先行，當(dāng)所有的單元測試代碼通過時，此功能也基本上完成了。

我們采用VSS進行代碼管理控制，其中存放了此產(chǎn)品的所有源代碼，各個部分存放在不同的目錄中。每天早上要求開發(fā)人員從VSS中獲取新的源代碼，然后進行編譯并開始的工作。在下班之前理論上要求員工簽入所有當(dāng)天修改的代碼，在簽入之前要保證編譯是能通過的。若有誰簽入的代碼導(dǎo)致運行失敗則會被要求某些懲罰措施或警告。有時我們編寫的代碼涉及到多個文件，而且此改動是比較復(fù)雜需要花費多天的工作量，如果現(xiàn)在簽入進去可能會導(dǎo)致項目測試通不過，因為有些代碼沒有完全完成，而之前的代碼能測試通過，而且這些代碼基本上不會涉及到他人，在這種情況下可以不簽入進去，直到全部代碼完成能提交測試時再一起簽入進去。