最近在看乙個前輩的部落格（我在另一篇部落格中已經提到過），寫的很好，分類齊全，內容詳細，文筆表達也簡潔清晰，是我需要學習的，這也是促使了我想把自己的部落格寫好的動力。在他的部落格中對軟體的開發流程說的很清楚，在這裡我想結合自己當前的也是人生中第乙個專案做乙個比較，以便加深自己的理解。
軟體開發流程：
1. 需求確認（客戶和開發方就各種需求達成概念統一，雙方認同的意思要保持一致）
2. 開發流程設計（軟體的詳細設計和各個模組的程式流程，先單元測試，介面測試，再開發）
3. 開發階段 （按照設計好的程式流程設計，需求或程式變動時，程式流程也要做相應的變更，保證一致）
4. 驗證階段（測試階段，白盒測試或黑盒測試）
5. 發布（客戶驗收之後投入使用）
6. 維護（發布後的軟體如果有bug還要對其進行修改）
以上是乙個專案該有的流程，現在我來說說我人生中的這第乙個專案是什麼樣的：
1. 在我被緊急招進來時，專案已經進入了後期，所以這個時候需求文件早就已經確認過了，我拿起文件直接看就好。交接的同事告訴我：你只要稍微改一下現有的bug就行，沒有什麼大需求要變更了（藍而！我後來把整個模組重新做了，因為這個模組被公司外包出去了，和現有的專案框架不相容，我不明白是怎麼驗收通過的）。
2. 我們所有的文件是：需求文件+介面文件（設計的資料結構+函式），介面測試我沒做過，專案初期已經做過了，但是聽前輩說，測試的結果是上層**商（即我們這個專案組）說介面各種不好用，中間層**商就說：你們使用的方式不對，必須這樣這樣。然後不了了之。至於單元測試，我們pm說從來沒有做過，所以這2個測試我到現在不知道該怎麼弄，呵呵噠。
3. 需求經常變更，不知道這是不是甲方的通病？所以我就得按照新發布的需求文件做修改，有時介面文件也會有變更。對應新需求時，要考慮這個需求能不能做，很多時候我們的po都說這個不要做，會讓我們現有的系統產生新問題甚至壓根就做不到。所以有段時間客戶直接**我們部門boss把pm給投訴了=。=
注意：需求變更時要考慮它會不會造成新問題，因為之前的功能流程已經設計好了，新增或者更改乙個點，考慮不夠全面的話就會造成新問題；以及和這個功能相關的模組，要和該模組的同事確認，會不會更改之後造成別的模組的問題。
4. **更改之後都是自己先測試沒問題之後再上傳，測試拿新**測試。
這裡我們一開始都會發現乙個問題：新**自測ok後，測試人員再測試總是會發現問題。因為我們自測試一般都只測試修改的那乙個功能，而沒有從全域性來測試，所以忽略了可能影響到的其他功能。
5. 客戶驗收的具體流程我不知道，只看到pm開會開了一兩天。
6. 現在專案處於維護期，大部分人都轉去做新專案了，我還處於待命狀態，天吶。。。。我還是好好看書吧，要學的東西還有太多，好多東西都沒有經歷，感覺沒漲什麼經驗，傷心！
什麼是軟體開發
有乙個銷售的同事在會議上說，你們軟體開發人員真好，坐在電腦前打打 就可以完成工作了。還有一些對軟體開發不懂的老闆說，你們軟體開發不就是寫幾行 就可以了嗎。可見，沒有深入軟體開發的了解，永遠都是這麼膚淺的認識。其實軟體開發總共有11個過程 定義問題 需求分析 規劃構造 軟體架構 詳細設計 編碼與除錯 ...
對日軟體開發流程1
1 sa 系統分析 這個階段比較重要的工作是分析客戶的業務，進行業務建模，理解並發掘客戶現在面臨的問題，提出改進的模型，以及執行時的管理。提交的文件是需求定義式樣書等。2 rd 要件定義 3 ur user要件 4 sr 系統要件定義 5 bd 基本設計 也叫外部設計，所謂外部，就是面向外部的使用者...
什麼是程式設計？什麼是軟體開發？
在學校裡，為了實現課堂練習，為了完成作業，為了實現而實現的 過程，我將其定義為程式設計，這個時候，你只要正確的讓編譯器把你的 順利的編譯通過，輸出你希望的或者說你的導師希望的結果即可，你不需要考慮彈性 擴充套件性和維護性，也不需要考慮你的 是否強壯，也不需要考慮是否具有價值，因為你只是在程式設計。而...