軟體開發流程

課程的主講老師是msdn的特約講師邵志東先生。課程中間，邵志東老師介紹了軟體開發流程、程式設計師基本素質、關於質量控制和開發模板及專案組建設。

邵老師首先介紹了軟體開發的流程，他把軟體開發分為了兩大類，即專案開發及產品開發。

專案開發是公司根據某一客戶的需求單獨為某一客戶訂製的軟體；

產品開發是公司針對某一市場需求而開發的軟體產品（比如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服務端和客戶端的使用

軟體開發流程

軟體開發流程

軟體開發流程

軟體開發流程

相關推薦