第 3 章 軟件開發過程管理,本章內容提要,CMM和ISO9000,傳統軟件開發生命周期模型,擴展軟件開發生命周期模型,3.1,質量計劃,3.4,案例分析,3.5,本章小結,3.6,復習思考題,3.7,3.2,3.3,軟件過程 是指人們用于開發和維護軟件及其相關產品的一系列活動、方法、實踐和革新。 軟件開發過程管理 是指在軟件開發過程中，除了先進技術和開發方法外，還有一整套的管理技術。 軟件過程改進 是針對軟件生產過程中會對產品質量產生影響的問題而進行的，它的直接結果是軟件過程能力的提高。 現在常見的軟件過程改進方法：ISO 9000，SW-CMM和由多種能力模型演變而來的CMMI。,3.1 CMM和ISO9000,3.1.1 SW-CMM和CMMI,SW-CMM簡介 為了保證軟件產品的質量，1991年美國卡內基梅隆大學軟件工程研究所（CMU/SEI）將軟件過程成熟度框架進化為軟件能力成熟度模型（Capability Maturity Model For Software，簡稱SW-CMM），并發布了最早的SW-CMM 1.0版。 SW-CMM為軟件企業的過程能力提供了一個階梯式的進化框架，階梯共有五級。,3.1.1 SW-CMM和CMMI,1 初始級,2 可重復級,3 已定義級,4 已管理級,5 優化級,無序、混亂的軟件過程。依賴個別人的努力和機遇。,建立基本的項目管理過程。相似項目，重復以往成果。,文檔化、標準化和標準的軟件軟件過程。,軟件過程和產品質量有詳細的度量標準。,持續的對過程進行改進。,圖 CMM分級標準,3.1.1 SW-CMM和CMMI,KPA及KP 除第一級外，SW-CMM的每一級都是按完全相同的結構組成的。每一級包含了實現這一級目標的若干關鍵過程域（KPA），每個KPA進一步包含若干關鍵實施活動（KP），無論哪個KPA，它們的實施活動都統一按六個公共屬性進行組織，即每一個KPA都包含六類KP： 1. 目標 2. 實施保證 3. 實施能力 4. 執行活動 5. 度量分析 6. 實施驗證,3.1.1 SW-CMM和CMMI,CMMI簡介 由于不同領域能力成熟度模型存在不同的過程改進，重復的培訓、評估和改進活動以及活動不協調等一些問題。于是由美國國防部出面，美國卡內基梅隆大學軟件工程研究所（CMU/SEI）于2001年12月發布的CMMI 1.1版本包括四個領域：軟件工程（SW）、系統工程（SE）、集成的產品和過程開發（IPPD）、采購（SS）。,3.1.1 SW-CMM和CMMI,CMMI有兩種不同的實施方法 連續式主要是衡量一個企業的項目能力 階段式主要是衡量一個企業的成熟度 CMMI的五個臺階 完成級 管理級 定義級 量化管理級 優化級 每一個臺階都是上面一階臺階的基石。要上高層臺階必須首先踏上較低一層臺階。,3.1.2 ISO9000質量標準,ISO9000 所謂“ISO9000”不是指一般意義上的一個質量保證標準，而是一族系列標準的統稱。,作用 強化品質管理，提高企業效益；增強客戶信心，擴大市場份額； 獲得了國際貿易“通行證”，消除了國際貿易壁壘； 節省了第二方審核的精力和費用； 在產品品質競爭中永遠立于不敗之地； 有效地避免產品責任； 有利于國際間的經濟合作和技術交流。,3.1.3 三者之間的比較,選擇SW-CMM還是CMMI的考慮 實施企業的業務特點。 實施企業對過程改進的熟悉程度。 實施企業對過程改進項目的預算。 實施企業是否可以使用階段式的演進路線。 實施CMM與CMMI可以平滑的轉換。 ISO9001與CMM的關系 ISO9001和CMM既有區別又相互聯系，兩者不可簡單地互相替 代。 取得ISO9001認證并不意味著完全滿足CMM某個等級的要求。 取得CMM第2級(或第3級)不能籠統地認為可以滿足ISO9001的要求。,本章內容提要,CMM和ISO9000,傳統軟件開發生命周期模型,擴展軟件開發生命周期模型,3.1,質量計劃,3.4,案例分析,3.5,本章小結,3.6,復習思考題,3.7,3.2,3.3,軟件生命周期 軟件從需求確定、設計、開發、測試直至投入使用，并在使用中不斷地修改、增補和完善，直至被新的系統所替代而停止該軟件的使用的全過程。 可劃分為以下子階段 1.可行性研究 2.需求分析和定義 3.總體設計 4.詳細設計 5.編碼（實現） 6.軟件測試、運行/維護 據此相繼產生了瀑布模型、螺旋模型、進化模型、原型模型、增量模型等。本節分別對這幾種傳統的軟件開發生命周期模型予以介紹。,3.2 傳統軟件開發生命周期模型,3.2.1 瀑布模型,瀑布模型總結 文檔驅動的模型 階段間具有順序性和依賴性 項目開發周期較長 實際項目很少按照該模型給出的順序進行,3.2.2 原型模型,3.2.2 原型模型,Prototyping model特點 在需求定義之前，需要快速構建一個系統 根據構建系統的優缺點，用戶給開發人員提出反饋意見 根據反饋意見修改軟件需求規格，以便系統可以更正確地反映用戶的需求 減少各種假設以及風險,3.2.3 增量模型,3.2.3 增量模型,增量模型總結 融合了瀑布模型和原型的迭代特征。 每一個增量均發布一個可操作產品。,3.2.4 進化模型,這個模型可看作是重復執行的多個瀑布模型。,3.2.5 螺旋模型,3.2.5 螺旋模型,螺旋模型總結 基于風險驅動的開發模型, 使用原型法或其它方法來盡量降低風險。 適用于需求不明確的大規模軟件項目,本章內容提要,CMM和ISO9000,傳統軟件開發生命周期模型,擴展軟件開發生命周期模型,3.1,質量計劃,3.4,案例分析,3.5,本章小結,3.6,復習思考題,3.7,3.2,3.3,3.3.1 極限模型,極限模型簡介 2001年，為了避免許多公司的軟件團隊陷入不斷增長的過程泥潭，一批業界專家一起概括出了一些敏捷開發過程的方法：SCRUM，Crystal，特征驅動軟件開發（Feature Driven Development，簡稱FDD），自適應軟件開發（Adaptive Software Development，簡稱ASD），以及最重要的極限編程（eXtreme Programming,簡稱XP）。,3.3.1 極限模型,極限編程將開發階段的4個活動（分析、設計、編碼和測試）混合在一起，在全過程中采用迭代增量開發、反饋修正和反復測試。,3.3.1 極限模型,XP開發模型核心思想： 交流（Communication） 簡單（Simplicity ） 反饋（Feedback） 進取（Aggressiveness）,3.3.1 極限模型,優點 采用簡單計劃策略，不需要長期計劃和復雜模型，開發周期短； 在全過程采用迭代增量開發、反饋修正和反復測試的方法，能夠適應用戶經常變化的需求。,缺點 目前主要在小規模項目上應用并取得成功，但是否適用于中等規模或大規模軟件產品，需慎重考慮； 由于這個模型較新產品交付后維護成本是否降低，不能確定； 對編碼人員的經驗要求高,3.3.2 Rational統一過程 （RUP）,3.3.2 Rational統一過程 （RUP）,用例驅動 Concise, simple, and understandable 以體系結構為中心 Effective basis for large-scale reuse 增量和迭代開發 基于風險前驅的原則，漸進地展開分析、設計及其相關活動，每個迭代都會提供一次驗證和調整模型機會，推動軟件質量的提升。,3.3.3 微軟產品開發周期模型,微軟產品周期模型,產品規劃階段,測試階段,產品開發階段,發布階段,M1Mn,CC,ZBB,RTM/W,RC1RCn,Alpha,Golden Masters,Beta,Product Vision,Function Spec,QFEs,本章內容提要,CMM和ISO9000,傳統軟件開發生命周期模型,擴展軟件開發生命周期模型,3.1,質量計劃,3.4,案例分析,3.5,本章小結,3.6,復習思考題,3.7,3.2,3.3,3.4.1 質量與質量規劃,軟件質量 是“所有描述計算機軟件優秀程度的特性的組合”。 軟件質量度量模型由三層組成 第一層為質量特性 第二層為質量子特性 第三層稱為度量,3.4.1 質量與質量規劃,ISOIEC9126 1991（GBT16260 1996）標準標準定義的6個質量特性 功能性 可靠性 易使用性 高效性 可維護性 可移植性 質量規劃 指識別哪些質量標準適用于軟件項目，并確定如何滿足這些標準的要求,3.4.2 質量體系、質量手冊和質量計劃,質量體系 指為保證產品、過程或服務質量，滿足規定（或潛在）的要求，由組織機構、職責、程序、活動、能力和資源等構成的有機整體。 質量手冊 是描述企業質量體系的文件。 質量計劃 是質量管理（質量計劃編制、質量保證和質量控制）的第一過程域 。,3.4.2 質量體系、質量手冊和質量計劃,質量體系、質量手冊和質量計劃之間的關系 質量體系好比一個國家的法制機構，質量手冊就如同憲法，是質量體系的文檔化的體現。而為每個項目制定的質量計劃類似地方法規，它在符合質量手冊的前提下，根據自身的要求與特殊性，通過適當的裁減修正而來。,關系圖,3.4.3 項目質量計劃的內容,項目實施總體目標 質量 時間 成本 三者是一個相互制約、相互影響的統一體，其中任一項目標變化，都會引起另兩個目標變化，并受其制約。 項目分類 質量傾斜型體系 工期傾斜型體系 成本傾斜型體系,3.4.3 項目質量計劃的內容,編寫軟件質量計劃涉及的范圍相當廣，不論是項目選型、軟件開發各階段，還是配置管理、崗位職責與團隊組織，又或是其他如項目制度的制定等等方面，都應該是包含在項目質量計劃中的內容。,3.4.4 質量目標,軟件生命周期三大階段（以傳統的瀑布模型為例） 軟件定義 軟件開發 軟件使用與維護,3.4.4 質量目標,各階段的關鍵元素,3.4.5 項目質量計劃的編寫,質量計劃 應說明項目管理小組如何具體執行它的質量策略。 目的 規劃出哪些是需要被跟蹤的質量工作，并建立文檔，此文檔可以作為軟件質量工作指南，幫助項目經理確保所有工作按計劃完成。 編寫準則 具體情況具體對待，沒有統一定律。,3.4.6 按照質量計劃實施有效的質量控制,質量計劃確定后，按其建立的質量管理體系，各責任單位必須按PDCA質量環的要求，實施有效的質量控制。 質量控制可分為兩個階段 監測 控制 質量控制應貫穿于項目的整個過程。 項目收尾的兩個階段 項目評估 項目終止 項目收尾階段的質量控制是一個非常重要而又容易忽視的內容。,本章內容提要,CMM和ISO9000,傳統軟件開發生命周期模型,擴展軟件開發生命周期模型,3.1,質量計劃,3.4,案例分析,3.5,本章小結,3.6,復習思考題,3.7,3.2,3.3,3.5 案例分析,HRMS系統 即人力資源管理系統，是為某跨國企業的ISS部門而開發的。 HRMS系統生存期模型選擇過程 針對本項目的開發特點，參考企業的生存期模型說明和軟件過程體系，決定采用迭代增量式模型。,3.5 案例分析,H R M S 項 目 生 存 期 模 型,本章內容提要,CMM和ISO9000,傳統軟件開發生命周期模型,擴展軟件開發生命周期模型,3.1,質量計劃,3.4,案例分析,3.5,本章小結,3.6,復習思考題,3.7,3.2,3.3,3.6 本章小結,講述了軟件開發過程管理需要掌握的部分知識。 介紹了ISO9000，CMM和CMMI三種常見的軟件過程改進方法，并比較了它們之間的異同，對于選取哪種方法給予了建議。 詳細介紹了多種軟件開發生命周期模型的特點、優缺點，對于軟件開發中的相當重要的項目選型工作提供了參照。 此外還介紹了質量計劃的定義和詳細的模版。(質量計劃的制定對于軟件質量控制的重要性非同小可，它涉及的范圍很廣，需要制定的內容相當多，部分內容讀者可以在其它章節去詳細了解。),本章內容提要,CMM和ISO9000,傳