軟體開發流程

邵老師首先介紹了軟體開發的流程，他把軟體開發分為了兩大類，即項目開發及產品開發。
項目開發是公司根據某一客戶的需求單獨為某一客戶訂製的軟體；
產品開發是公司針對某一市場需求而開發的軟體產品（比如WINDOWS、OFFICE等）。

這裡把流程圖用PS重新繪製了一下：

程式員的基本技能包括了以下幾個方面：
1、項目實踐
　　• 軟體工程理論
　　• 品質體系：ISO9001和CMM體系
　　• UML基本理論
　　• 測試理論和測試載入器使用
　　• 加密理論和加密方法
　　• 原始碼控制工具使用
　　• 說明書編寫
　　• 程式的安裝和部署
2、專業技能
3、程式員基本素質
　　• 團隊精神和協作能力（• 木桶理論、• 學習性組織）
　　• 文檔習慣（• 注釋、• 開發過程文檔：良好的文檔是正規研發流程中非常重要的環節，作為代碼程式員，30％的工作時間寫技術文檔是很正常的，而作為進階程式員和系統分析員，這個比例還要高很多。缺乏文檔，一個軟體系統就缺乏生命力，在未來的查錯，升級以及模組的複用時就都會遇到極大的麻煩。）
　　• 正常化，標準化的代碼編寫習慣（作為一些外國知名軟體公司的規矩，代碼的變數命名，代碼內注釋格式，甚至嵌套中行縮排的長度和函數間的空行數字都有明確規定，良好的編寫習慣，不但有助於代碼的移植和錯誤修正，也有助於不同技術人員之間的協作。• 代碼編寫規範• 介面設計規範）這裡邵老師強調了標準未必要固定，但在一個項目組中間要有統一的標準。
　　• 複用性，模組化思維能力（• 使用者控制項　• 組件技術）
　　• 測試習慣（• 單元測試　• 整合測試　• 系統測試　• 穩定性測試　• 軟體研發作為一項工程而言，一個很重要的特點就是問題發現的越早，解決的代價就越低，程式員在每段代碼，每個子模組完成後進行認真的測試，就可以盡量將一些潛在的問題最早的發現和解決，這樣對整體系統建設的效率和可靠性就有了最大的保證。）
　　• 學習和總結的能力（• 學習：程式員是人才很容易被淘汰，很容易落伍的職業，因為一種技術可能僅僅在三兩年內具有領先性，程式員如果想安身立命，就必須不斷跟進新的技術，學習新的技能。• 總結：善於總結，也是學習能力的一種體現，每次完成一個研發任務，完成一段代碼，都應當有目的的跟蹤該程式的應用狀況
和使用者反饋，隨時總結，找到自己的不足，這樣逐步提高，一個程式員才可能成長起來。）
4、職業素質
　　• 交際能力　　
　　• 表達能力　　
　　• 職業素養　　
5、個人素質
　　• 信心和恒心     
　　• 良好的個人品質
　　• 良好的個人習慣

• 關於品質控制和開發模板
• 項目組建設

進階程式員的基本素質：
　　1. 需求分析能力
　　對於程式員而言，理解需求就可以完成合格的代碼，但是對於研發項目的組織和管理者，他們不但要理解客戶需求，更多時候還要自行制定一些需求，為什麼這麼說呢？
　　2. 項目設計方法和流程處理能力
　　程式設計者必須能夠掌握不少於兩到三種的項目設計方法（比如自頂至下的設計方法，比如快速原型法等等），並能夠根據項目需求和資源搭配來選擇合適的設計方法進行項目的整體設計。設計方法上選擇不當，就會耽誤研發周期，浪費研發資源，甚至影響研發效果。
　　3. 複用設計和模組化分解能力
　　一個成熟的軟體行業，在一些相關項目和系統中，不同的組件是可以隨意換裝的，比如微軟的許多案頭軟體，在很多操作模組（如開啟檔案，儲存檔案等等）都是複用的同一套功能模組，而這些介面又通過一些類庫提供給了傳統型應用程式開發人員方便掛接，這就是複用化的模組設計明顯的一個佐證。
　　4. 整體項目評估能力
　　作為系統設計人員，必須能夠從全域出發，對項目又整體的清醒認識，比如公司的資源配置是否合理和到位，比如工程進度安排是否能最大化體現效率又不至於無法按期完成。評估項目整體和各個模組的工作量，評估項目所需的資源，評估項目可能遇到的困難，都需要大量的經驗積累，換言之，這是一種不斷總結的累計才
能達到的境界
　　5. 團隊組織管理能力
　　首先是工作的量化，沒有量化就很難做到合適的績效考核，而程式量化又不是簡單的程式碼數可以計算的，因此要求技術管理員需要能真正評估一個模組的複雜性和工作量。
　　其次是對團隊協作模式的調整，一般而言，程式開發的協作通常分為小組進行，小組有主程式員方式的，也有民主方式的，根據程式員之間的能力水平差距，以及根據項目研發的需求，選擇合適的組隊方式，並能將責權和成員的工作任務緊密結合，這樣才能最大發揮組隊的效率。

品質/過程標準部分的介紹

品質/過程標準是什麼，有什麼用？
• 開始並沒有什麼品質標準或者過程標準，但有些組織和企業呢，做的很成功，而有些則不成功。那麼有人就去分析為什麼，這些組織和企業成功了呢？他們有哪些的共同的特徵嗎？答案是有，於是這些特徵被歸納出來（比如9000中的立項，開發策劃，cmm中需求管理、組態管理等），並應用管理理論的成果，使之成為一種體系。
他能做到什麼和不能做到什嗎？
• 當操作者有意識時，標準可以幫忙。假如你沒做產品立項，或者作了，但沒有市場分析報告，標準可以幫忙，因為SQA會來說，這違背了規程，我們必須先做產品立項，並且必須基於市場分析報告。
• 但大家沒有意識時，比如產品立項時，假如與會人員多數認為沒有市場，或者我們沒有能力去做這個產品，但最終仍然立項通過，標準無能為力。
如何應用標準？
• 標準的目的？
– 可控制– 可追溯
• 開發模板
– 使用者需求規格說明書　– 需求評審報告
– 系統設計書　　　　　– 系統開發進度計劃
– 項目驗收標準　　　　– 使用者手冊項目組文檔

接下來的課程中邵老師又介紹了下面的內容：
• 編碼規範           
• 項目組規則         
• 工作計劃總結       
• Sourcesafe使用規範
• 公用幾類和常用代碼  

Sourcesafe使用
一、版本管理的必要性
• 如果說70年代的軟體危機導致了軟體工程思想的誕生和理論體系的發展，那麼80～90年代尤其是90年代軟體產業的迅猛發展導致了另一種新思想的產生和實現，這就是軟體的版本管理。
• 以往的那種被譽為具有良好編程風格的做法，諸如在對他人的來源程式進行修改時注釋修改原因，修改人和日期，如果是多個成員同時進行了修改，那麼需要進行及時的人工的差異比較和綜合以便形成一個統一的新版本。這種做法在當前的大型軟體的開發中已經越來越沒有空間了，可以說是一種以小作坊的形式來面對軟體的社會化大生產，再也不可能行得通了
二、Visual SourceSafe 6.0(VSS 6.0)簡介
• Microsoft的VSS 6.0解決了軟體開發小組長期所面臨的版本管理問題，它可能有效地協助項目開發組的負責人對項目程式進行管理，將所有的項目源檔案（包括各種檔案類型）以特有的方式存入資料庫。
• 開發組的成員不能對該資料庫中的檔案進行直接的修改，而是由該版本管理器將該項目的來源程式或是子項目的來源程式拷貝到各個成員自己的工作目錄下進行調試和修改，然後將修改後的專案檔作Checkin提交給VSS，由它進行綜合更新。
• VSS的用戶端和服務端的安裝
• VSS服務端和用戶端的使用