在乙個軟體產品發布並使用之後，其中肯定有許多地方不如意和值得改進的地方。客戶在使用的過程中會發現一些問題，提出更高的需求，市場也在發生變化，我們的競爭對手也在發展，新的技術不斷地產生，這些因素推動著我們的產品不斷地向前發展，使軟體版本不停地往上增長。這些發展的需求不是一下子提出來的，在客戶使用的過程中發現某些不如意不方便的地方，他們會向我們提出寶貴的意見，而技術人員會把這些需求記錄下來，以便修改或成為下乙個版本的新特性或需求。
乙個軟體的開發主要分為需求、設計、編碼、測試、維護幾個重要的階段，下面就每個階段的一些管理措施提點愚見：
1．需求管理
在進入正式開發之前，必須先從使用者處獲取準確的需求。在這上面花費相當時間是很必要的。在軟體專案的開發過程中，需求變更貫穿了軟體專案的整個生命週期，從軟體的專案立項，研發，維護，使用者的經驗在增加，對使用軟體的感受有變化，以及整個行業的新動態，都為軟體帶來不斷完善功能
優化效能，提高使用者友好性的要求。在軟體專案管理過程中，專案經理經常面對使用者的需求變更。如果不能有效處理這些需求變更，專案計畫會一再調整，軟體交付日期一再拖延，專案研發人員的士氣將越來越低落，將直接導致專案成本增加、質量下降及專案交付日期推後。
這決定了專案組必須擁有需求管理策略。
在整個開發周期中期望使用者的需求一直保持不變是不大可能的，因為使用者對於如何應用計算機軟體並沒有乙個成熟的經驗。需求變化的原因很多，如：
一開始沒有調研全，需要增加需求；
客戶需求發生了變化，需求必須變化；
需求錯誤；
需求不清楚。
基於上述的問題，必須對需求進行管理，使需求能夠真正成為軟體工程和管理的基線。
一種比較明智的方法是在簽定開發合同（協議）時把使用者需求的改動和經濟利益掛鉤,如果使用者增加或改動了需求,那麼軟體的交付日期可以推遲,費用也應增加。
需求是一項複雜的工作，使用的方法也很多，不同的開發方式有不同的方法，這裡簡單介紹一些相關的方法：
可行性分析：在允許的成本、效能要求下，分析每項需求實施的可行性，提出需求實現相關風險，包括與其它需求的衝突，對外界因素的依賴和技術障礙。
快速原型：當使用者自身對有的需求不十分清楚時，我們可以建立乙個系統原型，使用者通過評價原型更好地理解所要解決的問題。
圖形分析模型：繪製圖形分析模型是編制軟體需求規格說明重要手段。它們能幫助分析人員理清資料、業務模式、工作流程以及他們之間的關係，找出遺漏、冗餘和不一致的需求。
這樣的模型包括資料流圖、實體關係圖、狀態變換圖、對話方塊圖、物件類及互動作用圖。
資料字典：資料字典是對系統用到的所有資料項和結構的定義，以確保開發人員使用統一的資料定義。在需求階段，資料字典至少應定義客戶資料項，確保客戶與開發小組是使用一致的定義和術語。
2．設計管理
專案經理把功能模組分配給每個開發人員，每個開發人員把自己相關的功能模組收集起來，同時預估時間，其中主要包括寫文件的時間、開發時間和單元測試的時間，一般要求精確到工作日。這些資訊返回給專案經理，專案經理再把本小組人員的任務和預估時間傳送給管理層，由管理層對此任務及進度進行評估審核，管理層會根據產品發布時間及客戶需求、市場因素等方面作出選擇，可能某些功能由於時間緊急會被推遲到下乙個版本中去。若預估出來的時間同預計的產品發布時間有較大衝突，而且此功能是本版本中必須得做的，則開發小組會被要求重新預估時間，加快開發速度來達到這個要求。
雖然這個開發進度時間是乙個大概的估計時間，但我們要盡力按照這個開發進度來執行。作為開發人員每個星期寫一篇周記，描述自己本週所做的工作，根據自己的描述來評估我們自己的工作，每個人手上的工作是否按照這個進度在走，是否有人延後了，是否延誤了別人的工作。在週記裡每個人都要報告自己的進度，同時還要報告上個星期做了什麼，正在做什麼，以及下個星期打算做什麼。
通過這個周記，會讓你覺得有人在監督你，無形之中迫使你不斷地督促自己不要使任務延後，如果有延後的跡象也會盡早發現而趕上。若某些經過努力不能趕上，那也沒有辦法，只能修改原先的進度表，因為那是我們的估計與現實發生了偏差，我們必須使我們的進度表符合實際情況。
3． 編碼管理
進入編碼工作之後，可能會發現前面分析或設計階段的某些錯誤，這時應返回到前面的階段進行必要的修改。由於我們用語言進行開發，因此我們借助了vs2005工具。關於**風格，我們基本上套用vs2005中自動的**格式編排。
良好的編碼習慣有利於我們提高整個團對的開發效率，比如變數的命名、寫**時要對類及函式提供詳細的注釋及說明等，基本做到看它們的說明就能知道這個變數、類或函式的功能以及主要演算法的實現原理。在開發過程中對主要的模組要編寫單元測試，同時要單元測試先行，當所有的單元測試**通過時，此功能也就基本上完成了。
我們採用vss進行**管理控制，其中存放了此產品的所有源**，各個部分存放在不同的目錄中。每天早上要求開發人員從vss中獲取最新的源**，然後進行編譯並開始一天的工作。在下班之前理論上要求員工簽入所有當天修改的**，在簽入之前要保證編譯是能通過的。
若有誰簽入的**導致執行失敗則會被要求某些懲罰措施或警告。有時我們編寫的**涉及到多個檔案，而且此改動是比較複雜需要花費多天的工作量，如果現在簽入進去可能會導致專案測試通不過，因為有些**沒有完全完成，而之前的**能測試通過，而且這些**基本上不會涉及到他人，在這種情況下可以不簽入進去，直到全部**完成能提交測試時再一起簽入進去。
我們的開發是基於網路的，在網際網路高速發展的今天，**的安全也是乙個不容忽視的問題，我們要注意**的洩漏和丟失，除了掌握一些基本的安全知識以外，還要進行**的備份（區域網備份和儲存裝置備份），這樣在出現意外的情況下可以及時的恢復系統的正常執行。
4．測試管理
在開發人員完成了功能模組後，測試人員開始了測試規劃，確定需要測試哪些方面，如何測試及進度安排。測試人員需要寫許多測試用例、測試報告等，有些測試**需要整合測試，有些可能需要進行單獨的測試，目的都是為了使產品符合要求，使開發人員容易找出問題所在並改正。產品功能是否符合了要求，是否能被發布是由測試人員決定的，因此測試人員也比較辛苦，責任重大。
通過了每天的測試，還有一些效能測試、相容性測試、災難測試等需要在產品發布前進行。在完成這些測試之後由測試人員決定本產品是否能發布出去了。
由於我們每天進行著測試，因此經常有bug被測試人員發現，一旦發現了新的bug，就會被新增進測試報告中，同時註明緊急程度，以便開發人員可以及時進行錯誤bug的修改。需要指出的是我們對bug的定義比較廣泛，一些新功能也可以作為bug被提出，只不過這些bug級別比較低，讓它們進入到下乙個版本中去實現。因此bug的建立者也可以是技術支援人員、市場人員甚至開發人員本身。
關於開發人員本身，因為他可能會找出一些bug，有些是其他開發者的，有些可能是此開發者本身的，把這個bug新增進測試報告中可以幫助開發人員在以後產生新問題時或類似的bug時有乙個借鑑和思路。
5． 維護管理
後期的軟體維護和管理也是乙個非常重要的任務。定期的公升級服務和培訓會讓客戶對軟體有個良好的映像。
6． 組織（團隊）管理
軟體專案開發過程中注重的是團隊精神的發揮，我們的目標是乙個軟體、系統而不是幾個模組的簡單組合。在軟體開發管理中，不能採用明令制度的方式來要求何限制開發人員，必須要有辦法激勵人的內動力，而激勵人的內動力最好的辦法是將付出和收益緊密的結合。團隊精神的凝聚主要的是信任與尊重。
正所謂「用人不疑，疑人不用」，如果沒有基本的尊重與信任，**來的凝聚力，何謂團隊精神？
軟體專案開發人員應該本著態度第
一、效率優先的工作原則，在平時的日常工作和生活中，大腦的休息和充足的睡眠可以保證開發人員有個良好的心態和精力。也許在it行業來說，程式設計師加班已經成為一種佳話，一種習俗，但我們要制止長期的加班和無效率的加班，在專案不緊張或者無專案的情況下可以適當的放鬆、休息來調節個人的情緒和精力。
作為軟體開發人員的大部分時間是在公司裡度過的，因此公司的生活成了大家主要組成部分。員工之間關係的融洽，交流的暢通顯得非常重要，同時大家也不想自己的生活這樣枯燥乏味，一直同機器打交道。溝通無處不在，交流隨時發生，有許多關係是在工作之外建立起來的。
軟體公司內是很容易產生各種矛盾的，因為這是由你的工作性質所決定的，比如測試人員或使用者會對你的實現不滿意，提出各種要求時，我相信你有時會有所抱怨的，無形之中就產生了對立，發展到後來會有牴觸心理。我相信大部分人都會有此感受，這不是你的錯，這主要是由我們的工作性質決定的。如果你的工作是把財富帶給對方，則對方會非常歡迎你的到來，把你奉為財神爺來對待，同你的關係會非常融洽友好。
因此我們需要在工作之外來消除這種對立矛盾的關係，建立一種融洽的工作氛圍。我們在平時吃飯的時候飯桌上大家互相聊天溝通，說一些幽默笑話之類的，給我們緊張的工作增加點輕鬆的氛圍。隔斷時間大家可以組織一下活動，增加了公司的凝聚力。
乙個產品發布後組織一次活動，讓繃緊的神經鬆弛一下，更好地迎接下乙個挑戰。
軟體開發專案管理
軟體開發專案管理，補習對軟體開發專案的工作範圍 可能遇到的風險 需求的資源 要實現的任務 經歷的里程碑 話費的工作量，以及進度的安排等等做到心中有數。而軟體專案管理可以提供這些資訊。軟體具有可見性差 定量化難等特殊性。但通常可以 根據以往開發類似軟體的經驗來進行成本估算。將軟體專案劃分為若干個子系統...
軟體專案開發計畫
專案名稱 部門級文件管理系統 專案編號 編寫人員 編寫日期 2004 5 10 審批人員 審批日期 歷史修改記錄 1.引言 3 1.1.編寫目的 3 1.2.專案標識 3 1.3.專案背景 3 1.4.術語定義 3 1.5.參考資料 3 1.6.約束和假定 4 2.專案概況 4 2.1.專案產品 4...
軟體專案開發計畫
1引言 1 1.1編寫目的 1 1.2 背景 1 1.3定義 1 1.4參考資料 1 2專案概述 1 2.1工作內容 1 2.2主要參加人員 1 2.3產品 2 2.3.1程式 2 2.3.2檔案 2 2.3.3服務 2 2.3.4非移交的產品 2 2.4驗收標準 2 2.5完成專案的最遲期限 2 ...