a. 軟件過程是用於軟件開發及維護的一系列活動、方法及實踐。算法
b. 軟件過程分類(5大類):客戶-供應商過程,工程過程,支持過程,管理過程,組織過程。安全
c. 軟件過程模型:瀑布模型、快速原型模型、增量模型、螺旋模型、形式化方法模型、基於組件的開發模型網絡
軟件質量是軟件產品知足明確或隱含須要能力的性能和特性的整體架構
一級質量屬性:功能性functionablity框架
可靠性reliablity工具
易用性usability性能
效率efficiency測試
可維護性maintainability優化
可移植性portabilityspa
4個使用質量: 有效性effectiveness
生產率productivity
安全safety
滿意度satisfaction
質量管理是指肯定質量方針、目標和職責,並經過質量體系中的質量策劃、控制、保證和改進來使其實現的所有活動。
質量計劃 (Quality Plan):肯定項目應達到的質量標準,以及如何知足質量標準 的計劃安排和方法。
質量保證(Quality Assurance, QA):確保項目達到有關標準,而開展的有計劃、有組織的工做活動。」Is it done right?」
質量控制(Quality Control, QC):是肯定項目結果與質量標準是否相符,並及時糾正產品缺陷的過程。」Is it right done?」
項目:項目是爲完成某一獨特的產品、服務或成果所作的一次性努力。
項目管理:項目管理(PM)就是在項目活動中運用相關知識, 技能, 工具和技術知足項目的要求。
五大過程:啓動過程,計劃過程,執行過程,控制過程,收尾過程
十大知識領域:項目集成管理,項目範圍,管理項目,時間管理,項目成本管理 ,項目質量管理,項目人力資源管理,項目溝通管理,項目風險管理,項目採購管理,項目利益相關者管理
項目目標三角形,進度、成本、質量。
外部輸入類型、外部輸出類型、外部查詢類型、外部接口文件類型、外部邏輯文件類型。
概念:一個不肯定的事件或者狀況,若其一旦發生,會對項目的目標,例如,範圍、進度、成本和質量,產生積極或消極的影響
風險三要素:事件,機率,影響
框架:風險識別、風險分析、風險策劃、風險監督
計劃價值(已計劃工做的預測成本)---Planned value --- PV---200*5
掙值(已執行工做的預測成本)---Earned value ---EV---200*3.5
實際成本(已執行工做的實際成本)--- Actual Cost ---AC---1000
進度誤差(已完成的工做值與計劃的工做值的差)---Schedule Variance-- SV =EV-PV=700-1000
成本誤差(已完成工做的預算成本和實際成本的誤差)---Cost Variance --CV =EV-AC=700-1000
進度性能指標(Schedule Performance Index, SPI): SPI = EV / PV---大於1及比預期好
成本性能指標(Cost Performance Index, CPI): CPI = EV / AC----大於1及比預期好
連續式:根據商業目標及目的,選擇所關注的特定過程域,爲過程改進提供最大的靈活性(優勢)
階段式:提供一個預約義的組織級改進的路線圖,基於一組過程,其組成和順序及相關的組織關係已證實(優勢)
區別:連續式做爲單一過程域或者過程域集合,階段式做爲整個組織已創建的一個過程域集合
CMMI共有22個過程域:
等級2: | 需求管理、項目計劃項目監督和控制、供應商合同管理、過程和產品質量管理配置管理、度量和分析 |
---|---|
等級3: | 組織級過程焦點、組織級過程定義、組織級培訓、集成化項目管理、需求開發、技術解決方案、產品集成、驗證、確認、風險管理、決策分析和解決方案 |
等級4: | 項目定量管理、組織級過程性能 |
等級5: | 因果分析和解決方案、組織級改革和實施 |
等級 | 關鍵實踐活動 |
---|---|
GG1:達到特定目標 | 執行基礎實踐 |
GG2:制度化已管理過程 | 創建組織方針、策劃過程、提供資源、分配責任、培訓人員、管理配置、識別和包含利益相關者、監督與控制過程、客觀評價聽從性、與高層管理人員評審狀態 |
GG3:制度化已定義過程 | 創建已定義的過程、採集改進信息 |
GG4:制度化已定量管理過程 | 對過程創建定量目標、穩定子過程績效 |
GG5:制度化優化過程 | 確保連續過程改進、糾正問題的根本緣由 |
a. OST操做規格模板(UML:用例圖):描述了系統與外界的交互。描述了用戶與待設計系統的正常狀況下和異常狀況下的交互。
b. FST功能規格模板(UML:類圖):描述了系統能夠向用戶提供對外部可見的行爲說明書,以及與這些功能相關的系統行爲,變量和內部關係(繼承關係)。
c. SST狀態規格模板(UML:時序圖):用於描述系統中全部可能發生的狀態的集合,以及狀態之間轉換的條件,伴隨的動做。
d. 邏輯規格模板(無):用於描述系統中各有機組分(方法,項,算法等)的邏輯實現。
Rational Unified Process,統一軟件開發過程,面對對象的軟件工程的過程框架。
六大經驗:
迭代式開發,管理需求,基於組件的體系結構,可視化建模,驗證軟件質量,控制軟件變動
4個階段:
初始,細化,構造,交付。(每一個階段作什麼,作完的里程碑,中間產品是什麼?)
主要活動 | 里程碑 | 中間產品 | |
---|---|---|---|
起始(先啓/初始)階段 | ² 創建系統的業務模型² 捕獲系統的基本需求² 肯定系統的邊界² 識別關鍵任務² 肯定系統驗收標準² 進行項目風險評估² 進行項目資源的估計與效益分析² 制定項目開發計劃於重要里程碑 | 生命期目標 | ² 項目藍圖文檔:系統的核心需求、關鍵特性與主要約束² 初始的用例模型(完成10%~20%)² 初始的項目術語表² 業務用例模型,包括商業環境、驗收標準和財政預測² 初始的風險評估² 一個能夠顯示階段和迭代的項目計劃² 一個或多個原型² 初始的架構文檔 |
細化階段(最關鍵的階段) | ² 細化構想,創建對大多數關鍵用例的肯定理解² 分析問題域,創建堅實的架構² 細化機構並選擇組件² 捕獲80%的功能需求用例² 精化風險評估² 創建可執行的軟件原型² 定義非功能需求² 制定過程迭代計劃和迭代的評價標準 | 生命期構架 | ² 系統架構基線² UML靜態模型、UML動態模型、UML用例模型² 修訂的風險評估² 修訂的用例² 修訂的項目計劃² 可執行的原型 |
構造階段 | ² 資源管理、資源控制和過程優化² 完成組件開發並根據已定義的評價準則進行測試² 利用構想指定的準則對發佈的產品進行評估 | 初始運做功能。構造階段的結束時項目開發的第三個重要的里程碑。這個階段產生的版本一般被稱爲β版。 | ² 可運行的軟件系統² UML模型² 測試用例² 用戶手冊² 發佈描述 |
交付(轉化、產品化)階段 | ² 將軟件系統部署到用戶環境² 修復軟件的缺陷² 編制用戶手冊和其餘文檔² 培訓用戶和維護人員² 提供用戶諮詢 | 產品發佈 | ² 可運行的軟件產品² 用戶手冊² 用戶支持計劃 |
產品管理,程序管理,開發,測試,發佈管理,用戶體驗。
注重我的及互動 勝於 過程和工具
注重可用的軟件 勝於 詳盡的文檔
注重客戶協做 勝於 合同談判