軟件工程專題講座管理篇.ppt

1 管理篇第四章軟件風險管理 什么是風險 風險分析風險管理 2 4 1什么是風險 由于軟件的規(guī)模增大 復雜度增強 靈活性要求高而導致新一輪的軟件危機 因此而引發(fā)軟件的負面結論 軟件開發(fā)的效率和質(zhì)量問題是經(jīng)濟增長的主要障礙 軟件失效造成巨大的經(jīng)濟損失 用傳統(tǒng)的軟件工程技術來控制軟件成本和質(zhì)量也無法盡善盡美 因此 軟件風險是存在的 特別是對于大型復雜軟件 軟件風險 是指軟件有可能造成的傷害或者損失 3 4 1什么是風險 軟件風險是任何軟件開發(fā)項目中普遍存在的問題 與項目的大小成正比 因為 在制定軟件計劃時 系統(tǒng)分析員必須回答 項目的需求是什么 不可能準確無誤地回答需要投入多少資源 只能憑經(jīng)驗估計給出初步設想如何安排開發(fā)進度 這樣就存在風險 4 4 1什么是風險 進度過分緊迫 預算過分緊張 性能過分的超群 軟件可靠性要求過高 人員缺乏經(jīng)驗 組織結構不適宜 期望過高而不現(xiàn)實 沒有明確或理解合同的條款 軟件規(guī)模估計不恰當 管理部門缺乏經(jīng)驗 風險分析和管理不恰當 缺乏政策性支持 不熟悉技術或過程 不熟悉必要的硬件 需求不一致 或定義不充分 需求不斷變動 軟件開發(fā)計劃不恰當 軟件開發(fā)過程模型不適用 缺乏軟件工程技術和方法 缺乏自動化工具的支持 常見的軟件風險類別 進度 經(jīng)費 性能 組織 管理 人事 過程 方法 工具等 如下例證 5 4 2風險分析 條件 軟件的風險對于系統(tǒng)的成敗有關鍵影響時才進行風險分析 因此 先要進行風險估計 步驟 標識潛在風險項 收集信息 標明相關的風險 觀察風險的征兆 理解其原因 估計每個風險的大小及其出現(xiàn)的可能性 度量風險的后果和嚴重程度 風險評估 要考慮風險間的相互作用 6 4 3風險管理 風險管理的本質(zhì) 制定防止風險的計劃 并監(jiān)管風險 風險是不可能消除的 只能防止 風險管理的時機 已經(jīng)發(fā)現(xiàn)存在重要的軟件風險 這些風險可能影響項目的目標 這些風險將使系統(tǒng)花費大量的運行費用及支持費用 這些風險是可能防止的 7 4 3風險管理 風險管理的任務 制定風險計劃 風險管理計劃 RMP和風險排除計劃 RA version P 進行風險控制 執(zhí)行風險計劃中體現(xiàn)風險排除策略的控制機制 確定風險排除策略 確定風險排除戰(zhàn)術 建立風險管理計劃 對風險進行監(jiān)管 監(jiān)管軟件工程過程和產(chǎn)品 確定風險排除策略是否達到預期目標 是否有可能進一步改進風險排除計劃 為控制新的風險提供一些必要的決策信息等 8 管理篇第五章軟件項目管理與計劃 項目管理過程軟件度量軟件項目估算軟件開發(fā)成本估算進度安排軟件項目的組織與計劃 9 5 1項目管理過程 項目管理的對象 軟件工程項目 范圍覆蓋整個軟件工程過程 項目管理生命期 開始于技術工作啟動之前 持續(xù)于軟件分析 設計與實現(xiàn)過程中 最后終止于軟件工程過程結束之時 項目管理的過程 啟動一個軟件項目 軟件度量 軟件估算 風險分析 進度安排 追蹤和控制 10 5 2軟件度量 項目管理主要關心軟件生產(chǎn)率和軟件產(chǎn)品質(zhì)量的度量 軟件工程過程度量屬性 投入的成本和工作量 軟件產(chǎn)品度量屬性 產(chǎn)生的代碼行 LOC 執(zhí)行速度 存儲量大小 周期報告錯誤數(shù) 功能性 復雜性 效率 可靠性 可維護性 和其它質(zhì)量特性等 11 5 2軟件度量 度量方法 面向規(guī)模的度量 收集諸如工作量 投入成本 KLOC 文檔頁數(shù) 錯誤數(shù) 投入的人數(shù) 計算軟件的生產(chǎn)率和質(zhì)量 面向功能的度量 收集軟件數(shù)據(jù)域的一些計數(shù)度量 如用戶輸入數(shù) 用戶輸出數(shù) 用戶查詢數(shù) 文件數(shù) 外部接口數(shù)等 利用軟件復雜性估計的經(jīng)驗關系式導出功能點 12 5 2軟件度量 軟件質(zhì)量度量 廣泛使用的事后度量 驗收度量 包括 正確性度量 每KLOC的差錯數(shù) 可維護性度量 平均變更等待時間 MTTC 以及故障損失 完整性度量 從系統(tǒng)的危險性和安全性考慮 可使用性度量 用戶友好性 學習系統(tǒng)需要的技能 有效使用需要的時間 生產(chǎn)率凈增值 用戶主管評價 13 5 2軟件度量 軟件度量的目的 通過對軟件生產(chǎn)率和軟件質(zhì)量進行度量 可以對軟件提出要求和評價 進而可以建立改進軟件工程過程的目標 軟件度量的使用 使用軟件度量建立項目基線 收集項目當前的生產(chǎn)率和質(zhì)量狀態(tài) 利用基線對項目當前狀態(tài)進行評價 并確定軟件工程過程的改進目標 14 5 3軟件項目估算 軟件項目估算是項目計劃活動的基礎 項目管理人員應該估算項目需要的資源 成本和工作量 估算前要明確軟件的范圍 包括 功能 性能 限制 接口 可靠性 這些因素都影響資源 成本和工作量的估算 資源 人力資源 硬件和軟件資源等 成本和工作量 先對問題進行分解 然后利用LOC和FP方法 結合基線生產(chǎn)率度量計算每個子功能的成本和工作量 集成后為整個項目的成本和工作量 15 5 4軟件開發(fā)成本估算 軟件開發(fā)成本 主要是指軟件開發(fā)過程中所花費的工作量及相應的代價 不包括原材料和能源的消耗 主要是指人的勞動消耗 估算的依據(jù) 從軟件計劃 需求分析 設計 編碼 單元測試 集成測試和確認測試整個軟件開發(fā)過程所花費的人工代價 16 5 4軟件開發(fā)成本估算 基于分解和類推的估算方法 自頂向下 自底向上 差別估計等 專家判定技術 Delphi 經(jīng)驗模型 IBM模型 Putnam模型 COCOMO ConstructiveCostModel 模型 17 5 5進度安排 合理分配人員的工作量和花費的時間 嚴密監(jiān)控軟件開發(fā)的進展情況 使軟件開發(fā)進度不致拖延 過程 確定軟件開發(fā)小組人數(shù) 人員之間的通信會影響軟件生產(chǎn)率 因此 軟件小組人數(shù)要適宜 一般在2 8人左右 18 5 5進度安排 確定任務及其并行性 確定任務之間的從屬關系 確定各個任務的先后次序和銜接 確定各個任務完成的持續(xù)時間 從中抽取出關鍵路徑 制定開發(fā)進度計劃 工作量和時間的分配 一般 計劃階段占2 3 需求分析占10 25 軟件設計占20 25 編碼占15 20 測試和調(diào)試占30 40 19 5 5進度安排 用圖示表達進度安排 明確標明各個任務的計劃開始時間 完成時間 各個任務完成的標志 各個任務與參與工作的人數(shù) 各個任務與工作量之間的銜接情況 完成各個任務所需的物理資源和數(shù)據(jù)資源 Gantt圖 PERT和CPM項目的追蹤和控制 20 5 6軟件項目的組織與計劃 制定計劃 規(guī)定待完成的任務 要求 資源 人力和進度等 建立項目組織 建立分工明確的責任制機構 配備人員 任用各種層次的技術人員和管理人員 指導 鼓勵和動員軟件人員完成所分配的工作 檢驗 對照計劃和標準監(jiān)督并檢查實施的情況 21 管理篇第六章軟件過程改進 CMM簡介CMM內(nèi)容CMM可視化分析CMM內(nèi)部結構CMM應用CMM的問題CMM與ISO9000的區(qū)別PSP TSP 22 6 1CMM簡介 CMM是國際公認的對軟件公司進行成熟度等級認證的重要標準 CMM最早的工作開始于1986年11月 當時的情況 軟件需求越來越大 所解決問題的復雜程度增長速度超過了人們開發(fā)和維護的能力 產(chǎn)品不能如期交付 質(zhì)量不能令用戶滿意 軟件開發(fā)的開銷超過了預算 更好的軟件開發(fā)技術也不能解決問題 軟件過程的管理 23 6 1CMM簡介 人們逐步認識到 軟件開發(fā)中的個人因素并不是很重要 關鍵是軟件開發(fā)機構的成熟程度 卡內(nèi)基 梅隆大學的SEI受美國國防部的委托和資助 評估軟件供應商能力并幫助其改善軟件質(zhì)量 在Mitre公司的協(xié)助下 于1987年9月發(fā)布了能力成熟度框架以及一套成熟度問卷 四年后的1991年推出CMM1 0 1993年SEI又推出了CMM1 1 適用于500人以上規(guī)模的軟件公司 近幾年 SEI又推出了CMM2 0 同時進入ISO體系 稱為ISO IEC15504 即SPICE 軟件過程改進能力評估 24 6 1CMM簡介 軟件過程能力 描述在遵循一個軟件過程后所期待結果的界限范圍 軟件過程效果 描述在遵循一個軟件過程后得到的實際結果 軟件過程成熟度 指一個具體的軟件過程被明確地定義 管理 度量 控制和實施的程度 CMM中的軟件過程包括 軟件工程過程 軟件管理過程 軟件組織過程 25 6 1CMM簡介 軟件過程改進是持續(xù)的 因此 需要設計一個過程改進路線指導軟件機構 CMM可指導軟件機構在開發(fā)和維護軟件時如何控制軟件過程 如何改進軟件工程和管理 方法是 1 指導軟件機構確定現(xiàn)在所處的能力成熟度等級 2 確定提高軟件質(zhì)量和過程應該注意的關鍵問題 3 選擇過程改進策略 26 6 1CMM簡介 CMM提供了一個結構框架 組織成五個成熟度級別 主要特征如下 1 初始級 軟件過程是雜亂無章甚至混亂的 幾乎沒有明確定義的的步驟 項目的成功依靠個人或核心人物的努力 2 可重復級 建立了基本的項目管理過程來跟蹤成本 進度和性能 有必要的過程準則來重復以前在同類項目的成功 3 確定級 軟件工程和管理過程已經(jīng)文檔化 標準化 并綜合成整個軟件開發(fā)組織的標準軟件過程 針對具體項目裁減后用于實際的項目開發(fā)和維護中 4 管理級 制定了軟件產(chǎn)品和過程質(zhì)量的詳細度量標準 軟件過程和產(chǎn)品的質(zhì)量都被開發(fā)組織的成員所理解和控制 5 優(yōu)化級 根據(jù)過程執(zhí)行的反饋信息以及新技術 新觀念的吸納來持續(xù)地改進和優(yōu)化執(zhí)行步驟 使企業(yè)的軟件過程能不斷持續(xù)地改進 27 6 2CMM內(nèi)容 28 6 2CMM內(nèi)容 可重復級 在項目一級建立了過程管理條例和過程實施準則 確定級 在全企業(yè)建立標準的軟件過程 并由SEPG負責軟件過程活動 CMM管理級 對軟件過程進行定量分析 優(yōu)化級 缺陷防范 主動技術變動管理 過程變動管理 29 6 3CMM可視化分析 CMM5個成熟度等級之間的差別主要反映在軟件過程管理水平的高低上 進一步反映在軟件過程提供管理信息的能力上 管理信息取得決定于軟件過程的可視性 即軟件過程對于管理人員的透視性 CMM中不同成熟度等級采納了不同的管理方式 軟件過程提供管理信息的能力也不同 30 6 3CMM可視化分析 31 6 4CMM內(nèi)部結構 為了在軟件過程改進實踐中體現(xiàn)CMM模型的可操作性 CMM給出了每一個成熟度級的詳細結構規(guī)定 實施保證實施能力實施活動度量與分析驗證實現(xiàn) 32 6 5CMM應用 CMM是標準 CMM建立了一個可用的標準描述 項目招標方與中標方簽訂合同時可以利用這些標準對風險進行評估 CMM是框架 軟件組織可以利用這些標準改進組織內(nèi)部的軟件開發(fā)和維護過程 也就是說代表了軟件改進的道路 CMM是參考模型 CMM描述了成熟軟件組織的特征 標志了可期望的開發(fā)效果 33 6 5CMM應用 軟件過程評估關注于軟件組織內(nèi)部的軟件過程 發(fā)現(xiàn)缺陷 提出改進的方向 軟件能力評價確定特定項目中的風險 包括合作者是否有能力按計劃開發(fā)軟件產(chǎn)品 以及是否能按預算完成等 34 6 5CMM應用 方法的特點 考察中運用成熟度問題集作為出發(fā)點 CMM為考察指引方向 對照KPA發(fā)現(xiàn)差異 定義軟件過程中的優(yōu)缺點 從要求滿足KPA的目標出發(fā) 分析滿意程度 并提出書面報告 35 6 6CMM的問題 CMM指明該做什么 但沒有指明如何做 它不是方法論 沒有給出特定應用領域內(nèi)的專門技術 CMM是一個用于改進軟件產(chǎn)品和管理過程的結構化模型 但是僅描述軟件過程的本質(zhì)屬性 并非涉及軟件工程的所有問題CMM是從軟件過程角度定義了成熟的軟件過程的實踐活動 但是對于成熟的軟件組織而言 人的因素和技術的因素也同樣重要 36 6 7CMM與ISO9000 共同點 強調(diào)了軟件產(chǎn)品的質(zhì)量 不同點 1 CMM是專門針對軟件工業(yè)的 而ISO9001則面向所有工業(yè) 因此 相對而言 CMM更具體些 ISO9001更抽象些 2 CMM是面向內(nèi)部的軟件過程改善框架 而ISO9001是供需關系下基于過程的質(zhì)量需求 強調(diào)的是質(zhì)量的衡量準則 沒有告訴軟件開發(fā)人員如何達到好的目標 如何避免差錯 3 CMM通過KPA中的關鍵實踐活動的執(zhí)行程度判斷軟件過程的能力成熟性 ISO9001針對合同環(huán)境下設計 開發(fā) 生產(chǎn) 服務等環(huán)節(jié)給出了所需要的最基本的質(zhì)量要素 通過這些要素實施的有效程度判斷企業(yè)是否符合要求 4 CMM的結構是層次化的結構 由等級 KPA 公共屬性 關鍵實踐活動組成 ISO9001是簡單的線性結構 包含20個質(zhì)量要素 5 在應用概念上 CMM強調(diào)企業(yè)內(nèi)部素質(zhì) 而ISO9001重在整體 實施CMM的最大益處是可以較大程度避免形式主義 37 6 8PSP TSP CMM的成功與否與組織內(nèi)部的相關人員的積極參與和創(chuàng)造性活動密不可分 而且CMM并未提供KPA關鍵實踐活動實施所需要具備的具體知識和技能 PSP PersonalSoftwareProcess 為基于個體和小型群組軟件過程的優(yōu)化提供了具體而有效的途徑 在設計階段 PSP的著眼點在于軟件缺陷的預防 具體辦法是強化設計結束準則 而不是設計方法的選擇 PSP的研究結果表明 絕大多數(shù)軟件缺陷是由于對問題的錯誤理解或簡單的失誤造成的 只有很少一部分是由于技術問題而產(chǎn)生的 因此 PSP保障軟件產(chǎn)品質(zhì)量的一個重要途徑是提高設計質(zhì)量 38 6 8PSP TSP 實踐證明 僅有PSP是不夠的 CMM SEI在PSP基礎上發(fā)展出了TSP TeamSoftwareProcess 的方法 TSP指導項目組中的成員如何有效地規(guī)劃和管理所面臨的項目開發(fā)任務 并且告訴管理人員如何指導軟件開發(fā)隊伍始終以最佳狀態(tài)來完成工作 TSP實施集體管理與自己管理自己相結合的原則 最終目的在于指導開發(fā)人員如何在最少的時間內(nèi) 以預定的費用生產(chǎn)出高質(zhì)量的軟件產(chǎn)品 所采用的方法是對群組開發(fā)過程的定義 度量和改