本文件的編寫旨在探尋規範的軟體開發流程、加快軟體開發速度、提高軟體開發質量、降低專案綜合成本。
it界有一句格言：
"you can do it right; you can do it fast; you can do it cheap. pick two." 而我們要做的就是：提供優質服務、專案周期短、成本低廉。
專案從使用者需求說明書的提出，到系統的第乙個完整版本的交付使用經歷了若干或複雜或簡單的過程，但不管專案大小如何一般需要經歷以下幾個步驟：
1． 需求分析
2． 撰寫需求規格說明書
3． 總體設計
4． 詳細設計
5． 編碼實現
6． 測試、試執行、上線
7． 驗收
8． 日常維護
9． （下乙個版本的迴圈開發）
在以上各步驟中尤其重要的是系統分析和撰寫需求規格說明書。當定義好《需求規格說明書》後需要使用者簽字確認，以此作為專案驗收的依據，在中大型專案中尤其重要。
失敗的專案原因很多但以下幾點比較普遍：（1）商務運作中為了拉住「單子」對客戶的眾多紛繁複雜的要求一味的妥協讓步滿口答應。專案開發計畫、時間表等完全依照客戶意見，不以具體專案的客觀事實為依據，不做認真細緻嚴格的專案複雜度、專案工作量的評估。（2） 不做細緻的使用者需求分析導致專案後期的需求變更較大不能按期完成專案。
在專案開發的各階段時間比例方面，中小專案一般控制在
1： 40% 設計
2： 40% 編碼
3： 20% 總體設計/試執行
研究客戶需求，從中找出需求中模糊不清的地方，反覆討論確認。在不斷的確認中，包括需求的總體認知、需求邊界定義、目前技術條件下的可實現需求、使用者介面等。通過專案組內討論、與客戶（直接客戶、間接客戶）討論等方式不斷清晰客戶真正的需求，從而撰寫《需求規格說明書》，在取得客戶認可後簽字，以此做為專案開發的第乙個里程碑。在專案驗收時以此作為驗收的主要依據。
在系統分析階段與客戶的溝通方式可以通過：（1）專案靜態圖、專案靜態介面demo（2） 系統用例圖（例如：rose軟體的用例圖） 等方式與客戶溝通。
本階段要完成的工作有：1．撰寫專案需求分析報告，本報告主要目的是專案分析人員提出需求的疑難不清問題，為與客戶有效、準確溝通準備必要的材料。2．畫用例圖 ，描述系統各個不同使用者型別與本系統及其他系統等的互動過程。3．建立專案靜態介面demo，使得使用者在專案初期就可以看到專案上線實施後的使用介面和使用方法等4． 做必要的技術預研等。
需求規格說明書的撰寫主要目的是把客戶天馬行空、紛繁複雜、憑想象等的理想需求中變成在一定時間段、一定技術條件下可實現的需求。不然專案會很難滿足客戶的理想需求，永遠被客戶的理想需求所限制，陷入一種非常被動的狀態。在完成專案需求規格說明書後，就進入專案總體設計的階段。
在總體設計階段需要完成的文件有：
1． 《專案總體設計---概要設計說明書》
2． 《資料庫設計報告》
3． 《專案總體開發時間表》
在此階段應該建立專案的正式開發環境、專案測試環境、建立專案基本開發框架且匯入專案管理配置工具中（例如：cvs、vss等）等
在專案的以上階段完成後，建議進行專案總體設計和總體開發準備情況的評審工作。在公司、集團專家組評審通過後本階段結束，這算做專案的第二個里程碑。
1：《需求規格說明書》
2：《專案總體設計概要說明書》
3：《專案介面設計說明書》（及介面demo）
4：《專案資料庫設計說明書》等
5：《專案總體開發時間表》
在專案完成總體設計和搭建完畢開發環境後，就可以進行專案的詳細設計。在專案中建議詳細設計由專案編寫「後台」程式的資深人員編寫。主要完成每個負責的業務模組從介面到業務實現到資料庫連線操作的主要步驟和資料庫的實現sql。最好在條件允許的情況下編寫模組單元測試程式，在整個模組編碼階段完成後進行程式單元測試工作（「測試驅動」的開發理念）。
詳細設計目的是在不編寫**和少量**的情況下，完成專案模組的模擬程式設計實現。在詳細設計階段可以對專案某模組做準確的工作量統計，依此為依據整個專案比較準確的工作量就可以被統計出來。
1.需求獲取與分析
a)不要在需求獲取和分析過程中吝嗇你的時間，對需求的明確可以減少你以後設計和開發的改動，提高你所開發軟體的可用性。你對它的輕視只可能換來對你的產品修改、計畫延遲等方面的懲罰。
b)要使盡各種辦法，盡量多的獲取客戶的需求，主要的方法包括：仔細閱讀合同標書和市場資料、與客戶直接的談話交流、讓使用者**或使用原型介面提出意見。另外不要忽略內部客戶的一些合理需求如測試人員等。
c)進行正規的需求管理，如建立需求文件或使用需求管理資料庫等。在文件或資料庫中要保留每個需求的詳細描述及其**，最好還能記錄一些其他細節資訊（如使用者的一些原始描述等），另外別忘了確定每個需求的優先順序。
d)在設計前組織你的設計人員開會進行需求理解和討論。由於閱讀文本性的資訊容易造成一些誤解和歧義，最好讓需求制定者組織會議，給相關人員（如各子系統設計人員）講解需求並進行設計討論。這樣做有兩個好處，一是避免設計與需求出現偏差，二是激發設計人員產生初步的設計想法。
2.確定結構及系統設計
a)頂層設計必須要有多人及專家參與。乙個好的設計方案不可能完全出自乙個人的腦袋，它往往是經歷多次討論甚至爭論、多次改進與融合而最終形成的乙個有創造性的妥協產物。但你要避免爭論的過分激烈而導致的負面效果。轉貼於：中國專案管理資源網
b)乙個好的設計應包含簡單的框架，細節隱藏其下。組塊和模組是乙個好的設計所具有的特徵，在頂層設計裡人們看到的是簡捷的框架和功能明確的組快，在每個組快內部又能發現乙個簡單的框架和其他一些自包含的的組塊或模組。
c)在系統設計時想想你的使用者將怎樣使用你的軟體工作。很多時候設計人員會習慣性地從技術角度考慮系統地布局和劃分，可這種技術上地合理有時可能跟使用上的合理是衝突的，所以此時考慮一下你的使用者將降低你今後修改的風險。
3.有關詳細設計
a)詳細設計沒有必要過於精細準確。目前對有關底層詳細設計是否需要以及它該詳細到何種程度還存在一定的爭論，但認為可以不要和必須寫得非常精確這兩種極端思想都是有害的。詳細設計的作用在於開發人員編碼前整理思路，同時讓別人通過審核詳細設計文件檢驗你的思路是否正確，防止出現錯誤。
4.測試問題
a)繁雜但極富成效的單元測試。如果想將你的軟體質量提高到乙個新的檔次，對開發的軟體模組進行完整的單元測試是乙個很好的途徑，它能使開發者對自己的**成果更加有信心。雖然一些軟體專案單元測試做的很少甚至沒有，並且產品在最終測試後也執行的不錯，但它只能保證在與最終測試環境類似的環境中執行是安全的，超出這樣一種環境範圍則可能充滿雷區。
b)必不可少的最終測試。如果你的專案受時間、人力等資源影響沒法進行過多的單元測試，那最終測試就成了你軟體產品的唯一質量保證，千萬別把這一保證也丟了，沒有它你的軟體產品就毫無質量可言。最終測試的另一大用處是通過它可以發現一些單元測試的漏洞，完善單元測試用例。
c)根據你的軟體特性選擇自動測試。自動測試如果能在你的專案中使用上，將是個不錯的訊息，雖然目前的自動測試工具對一些特殊情況和特殊資料的細節處理略顯笨拙，但用它來檢驗產品的基本可用性和**修改的影響卻是高效的。有時自動測試還可能幫你發現手工測試幾乎不可能出現的錯誤情況，例如極短時間內觸發多個操作造成的衝突等。
5.有關重構
a)頂層結構的重新設計。通常當你的專案出現這種情況是非常不幸的，出現的原因一般是由於原來的結構不能支援新補充的特性而不得不進行修改。這種重新設計要注意兩點，一是時機最好選擇在乙個大的工作階段開始時，二是在新結構中盡量移動原有**而不是編寫新**。
b)底層模組的改進。由於當初編寫時的倉猝或考慮不周使得現有模組存在這樣或那樣的問題並且難於理解，這種情況下進行重構改進是很有必要的。修改的方法通常為對已有**進行整理和注釋，增加模組的封閉性和穩健性。
6.新技術的運用
a)評估新技術，確定它是否可以給專案帶來好處。合適的新技術可以提高產品開發效率和質量，判斷某一新技術對你的專案是否合適通常需要派專人或乙個小組進行小範圍考察和驗證。採用新技術的時機最好選擇在專案開始時或專案的某些重要階段開始時，另外千萬別忘了培訓你的開發人員使用它。
b)避免幾種使用新技術的動機。一是為了學習新技術而在專案中使用新技術，這樣只能使你的專案變成乙個實驗田，專案產品最終也成了實驗產品。二是不要指望使用新技術能拯救陷入困境的專案，如果乙個專案陷入困境，它通常需要的是清晰和穩定，未知的新技術很可能導致更大的混亂。
軟體專案需求開發基本步驟
由於軟體開發專案和組織文化的不同，對於需求開發沒有乙個簡單的 公式化的途徑。下面列出了一些基本步驟，可以利用它們指導需求開發活動。對於需求的任何子集，那麼你就可以很有信心地繼續進行系統的每一部分的設計 構造，因為你將開發出乙個好的產品 1.定義專案的檢視和範圍，確定每個功能的實現目的。2.確定使用者...
軟體開發心得
在我剛開始學習程式設計的時候，就對乙個程式的實際落實性產生了更大的興趣，也就是能否落地，在大一上學期的c語言學習裡，我們詳細的學習了c語言的基礎知識，為下學期的c 學習中的軟體開發打好了基礎，在下學期開始學習物件導向的程式設計並嘗試進行軟體設計時，那種茫然瞬間湧上心頭，在此之前，我從未接觸過任何有關...
專案開發中的心得
在專案開發過程中需要經常做活動之類的，每個月都有活動，而活動毫無規矩可循，這樣的話就只能每個活動都寫不同的程式了 這時候如果在已經穩定的 中去寫活動的話會很容易出錯，而且可維護性不高，因為活動都是短期的，過了就基本上沒有什麼用了，所有，建議放在登入頁裡面，使用者登入的時候判斷是否參與活動等等，因為登...