學習軟體工程的方法已經有一段時間了，深深的感覺到，乙個軟體的成功與優秀的開發流程有著必然的聯絡。近期思考了很多關於軟體開發流程方面的東西，也檢視了一些相關的文章。今天就在這裡理一理思路，一來方便自己以後檢視，二來還可以接受網友們的批評和指正。正因為是新手所以還有很長的學習道路要走。
學校中的專案除了科研專案以外，大多都是通過使用者提出需求、我們提供方案、修改方案、簽署合同、進行開發、測試、提交成果這個流程來進行的。仔細閱讀了infoq的《為什麼有些公司敏捷實施不成功？》這篇文章後，我個人覺得敏捷開發的相關方法和原則，針對學校中做專案的流程而言，並不能全盤照搬。所以以下我寫的流程還只是傳統的軟體開發的方法。
提供方案
這一部分是在使用者提出需求後，我們對使用者需求的細節部分進行估計、同時也通過查詢相應的技術文件，制定出初步的技術路線。在軟體工程裡我覺得這部分的工作更像是做乙個概要設計。當然我們的估計存在相應的偏差，但大多數情況下在這個階段，使用者的需求也是模糊的。使用者也僅僅能夠說出大概他們想要乙個什麼東西，更深的需求使用者自身也不是很清楚。可悲的是在這種情況下，雙方就要簽署相關的合同了，然後專案宣布啟動。
開發階段
由於使用者的需求不明了，合同可能寫的含糊其辭，使用者腦中的系統，和開發人員腦中的系統有可能是兩種截然不同的東西。但有一點可以肯定。這時候方案中的大體思路是沒有問題的，開發人員在上一部分中提出的需要解決的關鍵技術是基本沒有問題的。畢竟技術這東西，只有開發人員才曉得。而事實上，在高校，開發人員往往是學生，沒有什麼經驗。提出的關鍵技術大多都是看資料上是什麼樣的，就寫什麼。所以必須經歷下乙個重要的步驟：關鍵技術核實與突破
1.關鍵技術核實與突破
針對方案中的關鍵技術，開發人員需要盡可能的進行使用，通過構建相關的例子程式進行技術突破，俗稱把路子打通。例如關鍵技術中有一條：利用sql server2005 構建多資料庫聯合查詢的框架。這個功能需要哪些技術進行支援？是有關分布式的技術、還是sql server本身是否提供了多資料庫的聯合查詢，畢竟專家給出的建議是：如果乙個事情資料庫本身可以完成，就不要把這個事情交給應用程式來做。在做關鍵技術突破的過程中，**編寫規則相對鬆散，其目的是做到關鍵技術的快速突破。有時候這個過程可能要花一點的時間，我個人認為是值得的。
2.快速構建原型系統
當關鍵技術全部突破以後，開發人員需要講這個分散的技術結合起來，來構建乙個原型出來。原型的構建，最主要的工作是模組的基本劃分，系統構架的建立。為什麼要構建原型，一來，這時候開發人員心裡也沒有底，到底能不能完成這個東西。二來，使用者的需求還是不明確的。我們需要用原型系統來進一步挖掘使用者的需求。
3. 使用者交流
通過原型系統的演示，與使用者進行交流。畢竟：使用者只有看到他不想要的東西，他才知道自己想要什麼。這時候需要落實合同中的每乙個需求到底後面有多大，雙方的對合同中的認識到底有沒有差異。當然前期的合同簽署時，這個差異已經消除的差不多了，但此時要進一步落實，使用者到底想要什麼功能，怎麼操作，什麼介面，怎麼管理流程等等。在這一階段需要雙方建立需求控制組，這個組的作用是對使用者的需求進行挖掘，同時也進行控制。大概看過原型後，使用者總是會冒出一些新的點子，這時候我認為，要對使用者提出的需求進行分析，是否是合同中的涉及項，技術上是否可行等等。對使用者的需求即尊重、又限制才是最高境界。
4.總體設計
有了前期工作的鋪墊，使用者需求相對明朗。系統基本框架、模組劃分的工作也相對容易。這時候重新進行系統的總體設計是十分重要的。這時候開發人員對系統的認識也會比較有把握。需要注意的是測試人員在這一階段就需進入，目的是要讓測試人員做到對系統的構架有清晰的認識。這一階段完成系統的總體設計文件、測試大綱。當然這部分完成後要與使用者做簡單的溝通。
5.詳細設計
基本的技術路線已經打通，開發人員對關鍵技術的使用已經有了把握，對於每個模組下，有多少個類，設計模式是怎樣的，如何通訊等問題都做詳細的設計。每個類的引數傳遞是怎麼樣的，模組與模組之間的通訊時怎麼完成的。一般而言現在開發都是以元件開發為主，做到介面**與功能**分離，模組間**分離等等。這一階段開發人員要完成軟體的詳細設計書，測試人員要開始著手單元測試用例的編寫。
6.**編寫
針對**的編寫與管理，是這部分的重點。開發人員為前期詳細設計中的每乙個類中的函式體新增內容，使之成為真正的函式。當開發人員編寫完部分函式後，**需要走以下基本流程：**除錯、**回顧、函式的單元測試、模組的夥伴測試、**的效率測試、最後完成**的提交。**除錯，主要是開發人員來做，將錯誤消除。**回顧主要是開發人員和測試人員一起回顧，針對**的命名規範、**的邏輯結構、**注釋的編寫、**解釋文件的編寫等。函式單元測試、主要是測試人員對**的輸入輸出進行檢查。**效率測試、需要測試人員對**的效率進行監控。最後由測試人員提交**塊。
7.**整合
將**塊進行整合，測試人員進行整合測試，注重模組與模組間的呼叫效率等問題。對於組裝好的系統，測試人員就要開始做系統測試了。此時針對系統測試，測試人員需要制定詳細的測試計畫、需要建立測試測試用例的編寫、週報制度和buglist管理。測試人員與開發人員的互動在乙個測試用例的4步曲中完成。首先，測試人員編寫測試用例、然後測試人員按照測試用例對軟體進行測試、接著測試人員將buglist提交給開發人員修改、最後測試人員對修改後的程式進行複測。
8. 效能及壓力測試
此部分測試人員借助相關的測試工具，進行效能測試和壓力測試。
9. 發布系統
首先系統需要構建安裝包，編寫相關手冊說明。此時系統正式進入發布階段、首先發布的版本叫做阿爾法版。該版本由所有開發人員和測試人員一起使用，發現bug,進行修復。在阿爾法版完成後、發布貝塔版。這時候就可以將該系統發放給使用者體驗，收集使用者體驗資訊。做出相應的簡單調整。
10. 專案驗收
提交相關源**，技術文件，開發文件，測試文件，安裝手冊，使用者手冊，配置手冊等。
至此整個開發結束，小小乙個軟體需要經歷如此複雜的過程，才能夠讓方便使用者的工作流程，完美的幫助使用者解決現有的問題。這不得不說是乙個值得驕傲的過程。嘿嘿，以上是我將自己的思路進行整理的結果，不一定正確，還望大家多多批評指正。
vincent
關於軟體開發工作的思考
關於軟體開發工作的思考 挨踢界小人物 工作中時常遇到這樣一種情況，在做網頁的時候，我會秉承使用者體驗的原則，視自己為使用者的心態，去設計和改造介面，但並非老闆喜歡，老闆要的只是系統穩定，不要搞出事情，所有多數情況我的改造優化都不能上線成為正式產品，然後會指揮你怎麼做，怎麼做！而你會怎麼抉擇。在這種情...
關於搭建軟體開發環境的思考
近幾日需要了解人臉識別方面的知識，於是在網上找到開源專案。該專案有關配置的說明很少，所以很難按部就班來操作。然後通過專案說明給的一點點提示開始安裝，然後通過執行指令碼，報的錯誤來發現有哪些依賴沒有安裝，還有那些模組需要載入。但是這個過 的很漫長，對於很多個不熟悉的庫，只能在安裝過程中通過各種試錯，來...
軟體開發流程的一些思考
1.大型通用軟體的開發就是以質量第一的原則 軟體在賣到幾十套的時候，質量只要過的去就可以了，但一旦軟體賣到上千套，質量就絕不能以對付了事，否則維護部門的 就要被打爆。測試人員一般的能達到開發人員的1 3就比較合理了，如果是剛起步的公司，考慮到 成本因素，而且大多是以開發專案為主，所以在測試上可以相對...