軟件工程

• CMM(能力成熟模型)

  • 五個級別
    • 初始級(雜亂無章很混亂，沒有明確定義的步驟，完成依賴英雄式核心人物的作用)
    • 可重復級(建立基本的項目管理過程和實踐來跟蹤項目費用、進度和功能特性)
    • 已定義級(管理和工程兩方面的軟件過程已經文檔化、標準化，綜合成標準軟件過程)
    • 已管理級(軟件過程的產品質量被開發組織成員所理解和控制)
    • 優化級(接受了過程質量的反饋、新觀念、新技術，不斷持續改進)

• CMMI(能力成熟模型集合)

  • 階段式模型
    • 初始的 過程不可預測且缺乏控制
    • 已管理的 過程為項目服務
    • 已定義的 過程為組織服務
    • 定量管理的 過程已度量和控制
    • 優化的 集中于過程改進
  • 連續式模型
    • 未完成的 過程域未執行或者未得到
    • 已執行的 可標識的輸入工作產品轉換成輸出
    • 已管理的 集中已管理的過程的制度化
    • 已定義級的 集中已定義的過程制度化
    • 定量管理的 可定量管理的過程的制度化
    • 優化的 使用量化手段改變和優化過程域

• 軟件過程模型

  • 軟件開發全部過程、活動和任務的結構框架
  • 瀑布模型
    • 需求分析、設計、編碼、測試、運行與維護
    • 由前至后相互銜接的固定次序，到是某個階段可以不需要關心前面的階段，必須要就需要回朔成本很大
    • 優點:容易理解、管理成本低，強調開發的階段性早期計劃及需求調查和產品測試
    • 缺點:客戶必須完整清晰表達需求，需要到項目結束之前才可以演示，前期的問題到后面才可以發現問題，風險控制能力較弱
  • V模型 是瀑布模型的變體，描述了質量保證活動和溝通、建模相關活動以及早期構建相關的活動之間的關系
    • 提供了一種將驗證確認活動應用于早期軟件工程工作中的方法。有一系列測試
  • 增量模式
    • 將需求分段為一系列增量產品，每一個增量可以分別開發
    • 第一個增量往往是核心的產品1.0，往后都是增加新的功能2.0 3.0
    • 優點:有瀑布模型的所有優點，第一個可交付版本所需要的成本和時間很少；風險較小；減少用戶需求的變更
    • 缺點:沒有對用戶的變更要求進行規劃，會對后來的增量的不穩定；不像早期思考的穩定，一些增量可能需要重新開發；可能會超出組織的能力
  • 演化模型(原型模型和螺旋模型)
    • 是迭代的過程模型，使得軟件開發人員能夠逐步開發出更完整的軟件版本。適用于對軟件需求缺乏準確認識的情況
    • 原型模型
      • 比較適合于用戶需求不清、需求經常需要變化的情況 不適于大規模軟件
      • 目的是快速低成本地構建原型，迅速給用戶看到一個系統框架，在提出需求
      • 交流=》快速計劃=》快速設計方式建模=》構建原型=》部署交付和反饋
    • 螺旋模型 加入風險分析
      • 適用于龐大、復雜化并且有高風險的系統；支持用戶需求的動態變化
      • 需要開發人員豐富的評估經驗和專門知識，過多的迭代次數增加成本，延遲提交時間
      • 螺旋周期的四個步驟
        • 制定計劃：確定軟件的目標，選定實施方案，明確項目開發的限制條件
        • 風險分析：分析所選的方案，識別風險，消除風險
        • 實施工程：實施軟件開發，驗證階段性產品
        • 用戶評估：評價開發工作，提出修改建議，建立下一個周期的開發計劃
    • 噴泉模型
      • 以用戶需求為動力，以對象作為驅動的模型，適用于面向對象的開發方法
      • 開發過程具有迭代性(常常需要重復多次)和無間隙性(沒有明顯的邊界)
      • 允許各開發活動交叉、迭代地進行
      • 優點:提高軟件項目的開發效率節省開發時間，缺點是:需要大量人員，不利于項目的管理，要求嚴格管理文檔，使得審核的難度加大

• 統一過程(UP)模型

  • 用例和風險額驅動、以架構為中心，迭代(5個核心工作流)并且增量的開發過程，由UML方法和工具支持
  • 袖珍項目:計劃、分析和設計、構造、集成和測試，以及內部和外部發布
  • 4個技術階段
    • 起始階段：生命周期目標
    • 精化階段：生命周期架構
    • 構造階段：初始運作功能
    • 移交階段：產品發布
  • 統一過程的典型代表是RUP。RUP是UP的商業擴展，完全兼容UP，但比UP更完整、更詳細

• 敏捷方法

  • 盡可能早地、持續地對有價值的軟件的交付使客戶滿意 每一種方法基于一套原則(敏捷宣言)

  • 極限編程XP

    • 價值觀、原則、實踐和行為4個部分
      

  • 水晶法Crystal

    • 水晶法人為每一個不同的項目都需要一套不同的策略、約定和方法論

  • 并列爭求法Scrum

    • 把每30天一次的迭代稱為一個沖刺

  • 自適應軟件開發ASD
    

  • 敏捷統一過程AUP

    • 采用大型上連續，小型上迭代的原理來構建軟件系統
    • 迭代執行活動:建模、實現、測試、部署、配置及項目管理、環境管理

• 軟件需求
  

• 系統設計

  • 系統設計的結果是一系列的系統設計文件，是實現信息系統的重要基礎
  • 概要設計階段
    • 設計軟件系統結構:將一個復雜的系統按功能劃分成模塊:確定每個模塊的功能；調用模塊之間的調用關系；確定模塊之間的接口既模塊之間傳遞的信息；評價模塊結構的質量。是概要設計關鍵一步，直接影響下一階段詳細設計與編碼的工作
    • 數據結構與數據庫設計 數據庫設計:概念、邏輯、物理設計
    • 編寫概要設計文檔:文檔有概要設計說明書、數據庫設計書、用戶手冊以及修改測試計劃
    • 評審:實現了需求規定的功能、性能，設計方法的可行性，內外接口定義的正確性進行評審
  • 詳細設計
    • 對每個模塊進行詳細的算法設計
    • 對模塊內的數據結構設計
    • 對數據庫進行物理設計，既確定數據庫的物理結構
    • 其他設計:代碼設計 輸入/輸出格式設計 用戶界面設計
    • 編寫詳細設計說明書
    • 評審:對處理過程的算法和數據庫的物理結構都要評審

• 系統測試

  • 意義:為了發現錯誤而執行程序的過程，成功的測試是發現了至今尚未發現的錯誤
  • 目的:希望以最少的人力和時間發現潛在的各種錯誤與缺陷 一般都是軟件測試
  • 保證系統質量和可靠性的關鍵步驟，系統分析系統設計的最后復查 遵循以下原則
    • 盡早并不斷地進行測試
    • 測試工作應由專門人員來進行，這樣會更客觀、更有效
    • 設計測試方案時，將實際輸出結果與預期結果相比較就能發現測試對象是否正確
    • 設計測試用例時，合理的、不合理的都要輸入測試
    • 測試程序時，檢查有沒有多余的工作
    • 嚴格按照測試計劃來進行
    • 妥善保存測試計劃測試用例，作為軟件文檔的組成部分，為維護提供方便
    • 測試用例都是精心設計出來的，可以為重新測試或者追加測試提供方便
    • 系統測試階段的測試目標來自于需求分析階段

• 軟件測試

  • 單元測試(模塊測試)
    • 在模塊編寫完成且無編譯錯誤后就可以進行 白盒測試
    • 測試內容:單元測試主要檢查模塊以下的五個特征

      • 模塊接口:保證測試模塊的數據流正確的流入流出
        

      • 局部數據結構

        • 變量的說明是否合適
        • 是否使用未賦值或為初始化的變量
        • 變量的初始值或默認值是否正確
        • 變量名是否有錯

      • 重要的執行路徑

      • 出錯處理

      • 邊界條件

    • 單元測試過程
      • 模塊不是獨立運行的，各模塊之間存在調用被調用的關系，對模塊測試時，需要開發兩種模塊
        • 驅動模塊:接收測試例子的數據，送到測試模塊，輸出測試結果
        • 樁模塊:內部可以進行少量數據處理，目的是為了檢驗入口，輸出調用和返回的信息
  • 集成測試
    • 自頂向下集成測試
      • 一種構造軟件體系結構的增量方法；最上面是驅動模塊(主控模塊)，后面替換成樁模塊(抽象到具體)，以深度或廣度優先方式逐步向下。
      • 不用編寫驅動模塊，需要編寫樁模塊
    • 自底向上集成測試
      • 不需要編寫樁模塊，需要編寫驅動模塊
      • 連接底層的樁模塊變成簇；編寫驅動模塊；測試簇；去掉驅動模塊，繼續向上連接簇
    • 回歸測試
      • 重新執行已執行過的某些子集，已確保變更沒有傳播不期望的副作用
      • 保證變更不引入無意識行為或額外的錯誤
    • 冒煙測試
  • 確認測試
  • 系統測試

• 測試方法

  • 靜態測試:不在機器上運行
    • 人工檢測
    • 計算機輔助靜態分析
  • 動態測試
    • 黑盒測試
      • 等價類劃分：有效等價類50和無效等價類101 0-100
      • 邊界值分析：0-100 輸入0 -1 100 101
      • 錯誤推測：憑感覺
      • 因果圖 轉換為判定表
      • ps:兩個輸入都是不合理的時候那它就是不合理的測試用例
      • McCabe度量法
        • 環路的個數公式:V(g)=m-n+2 m是G中的有向弧 n是節點數 或者 閉合區域+1
    • 白盒測試
      • 原則：所有獨立路徑至少執行一次；取真或假的兩種情況至少都能執行一次；循環在邊界跟一般條件個執行一次；測試程序內部數據結構的有效性
      • 邏輯覆蓋
        • 語句覆蓋
          • 選擇足夠的測試數據，使被測試程序中的每條語句至少執行一次，是很弱的邏輯覆蓋
        • 判定覆蓋(分支覆蓋)
          • 真分支、假分支都要執行一次
        • 條件覆蓋
          • 每一語句中的每個邏輯條件的各種可能的值至少滿足一次(判斷語句里面每一個條件的真假值都要)
        • 判定/條件覆蓋
          • 上面兩種的結合
        • 條件組合覆蓋
          • 判定條件的各種可能值的組合都至少出現一次
        • 路徑覆蓋
          • 覆蓋被測試程序中所有可能的路徑 強的邏輯覆蓋
      • 循環覆蓋：執行足夠的測試用例，使得循環中的每個條件都得到驗證
      • 基本路徑測試

• 系統維護概述

  • 軟件維護是軟件生命周期的最后一個階段，不屬于系統開發過程

  • 系統可維護概念

    • 維護人員理解、改正、改動和改進這個軟件的難易程度。
    • 可維護性的評價指標
      • 可理解性、可測試性、可修改性
    • 硬件維護、軟件維護、數據維護

  • 軟件維護

    • 文檔是軟件可維護性的決定因素，很重要的
    • 維護期通常比開發長的多，投入也多
    • 可維護性是每個軟件都應具有的特點，必須在開發階段保證軟件具有可維護性，每一階段都應該考慮提高可維護性
    • 進行質量保證審查可以提高軟件產品的可維護性，可維護性是衡量軟件質量的一個重要特性
    • 維護內容
      • 正確性維護：改正錯誤 17-21%
      • 適應性維護：適應信息技術變化和管理需求變化而進行的修改 18-25%
      • 完善性維護：擴充功能和改善性能而進行修改 比重較大50-60%
      • 預防性維護：主動增加預防性的新的功能 4%

  • 軟件文檔

    • 文檔也是軟件產品的一部分，沒有文檔的軟件就不能稱之為軟件
    • 編寫高質量文檔可以提高軟件開發的質量
    • 軟件文檔的編制在軟件開發工作中占比突出的地址和相當大的工作量
    • 高質量文檔對于軟件產品的效益有著重要的意義
    • 總的來說，軟件文檔只好不壞，選項中說軟件文檔不好就是錯的

  • 軟件的質量屬性
    

  • 溝通路徑

    • 有主程序員:n-1 無主程序員:n(n-1)/2

• 軟件項目估算

  • COCOMO模型：是一種精確的、易于使用的成本估算模型
    • 基本COCOMO模型是靜態單變量模型
    • 中級COCOMO模型是靜態多變量模型，分為系統和部件
    • 詳細COCOMO模型，分為系統、子系統和模塊
  • COCOMOII模型(規模估算選擇)
    • 應用組裝模型(對象點)
    • 早期設計階段模型(功能點)
    • 體系結構階段模型(代碼行)

• 進度管理

  • Gantt圖(甘特圖)
    • 清晰地描述每個任務從何時開始到何處結束，任務的進展情況以及各個任務之間的并行性
    • 不能清晰地反應各個任務之間的依賴關系，難以確定項目的關鍵所在，不能反應計劃中有潛力的部分
  • PERT圖(項目計劃評審技術圖)
    • 有向圖，箭頭表示任務，可以標上該任務需要的時間；不能反應任務的并行關系，可以依賴
    • 流入結點的任務就為結束，流出結點的為開始，結點為事件；都結束了才出現才可以開始
    • 開始結點:沒有指向它的任務，最早時刻是0，可以有多個，
    • 結束結點：沒有指向出去的任務，最遲時刻跟最早時刻同一天，只有一個
    • 最早時刻：在此時刻之前該時間出發任務不可能開始，前面那個的最早時刻加任務時間就是自己的最早時刻，如果多個就取最大值的最早時間
    • 最遲時刻：出發的任務最遲在此時刻開始，不然工程不能如期完成；前面的最遲時刻減去任務時刻，遇到多個取最小值時刻
    • 松弛時間=最遲時刻-最早時刻 多條也要單獨算出來
    • 關鍵路徑:松弛時間都是為0的路徑
  • 項目活動圖
    • 頂點是項目里程碑，連接頂點的邊表示活動，邊上的值表示完成活動所需要的時間
    • 關鍵路徑的長度等于結束頂點的最遲時刻

• 軟件配置管理

  • 配置數據庫：開發庫、受控庫、產品庫
    

• 軟件風險管理

  • 不確定性和損失

    • 項目風險：威脅到項目計劃，項目復雜度、規模及結構不確定也屬于
    • 技術風險：威脅到開發軟件的質量跟交付時間。原因是問題比我們所想的更加難以解決
    • 商業風險：威脅到開發軟件的生存能力，且常常危害到項目或產品；五個項目風險:市場、策略、銷售、管理、預算

  • 風險識別

    • 系統化的指出項目計劃(估算、進度、資源分配等)的威脅，識別后盡可能的回避，控制風險，不可能完全避免的，能避免就避免，實在不行只能干預降低風險

    • 風險條目檢查表識別以下幾種類型的風險
      

    • 風險因素包括性能、成本、支持和進度
      

  • 風險預測(風險估計)：從兩個風險概率和后果方面評估風險；建立風險表 嚴重程度高到低1 2 3 4
    

    • 評估風險影響:風險的本質、范圍、時間會影響風險所產生的后果
    • 風險暴露RE=P*C P發生的概率 C后果

  • 風險評估

    • 對風險評估很有用的技術定義風險參照水準(成本、進度、性能是典型的風險參照水準)三元組(風險、概率、后果)

  • 風險控制

    • 輔助項目組建立處理風險的策略；
    • 應對風險最好就是主動避免風險；
    • 風險監控：項目管理者監控某些因素
    • RMMM計劃(風險管理策略)：可以包含在軟件項目計劃中 ；試圖找到起源

• 軟件質量

  • ISO/IEC9126軟件模型:第一層質量特性，第二層質量子特性，第三層度量指標
    

• Mc Call軟件質量模型:

• 軟件評審

  • 設計的規格說明書符合用戶的要求稱為設計質量
    • 評價軟件的規格說明是否合乎用戶的要求
    • 可靠性:是否能避免輸入異常、一間失效及軟件失效所產生的失效
    • 評審軟件是否有復用性、可測試性、可修改性、可擴充性、可互換性、可移植性
    • 評審性能，保密措施、操作特性實現情況
  • 程序按照設計規格說明所規定的情況正確執行稱為程序質量
    • 軟件本身的結構、運行環境的接口以及變更帶來的影響而進行的評審活動
    • 結構：功能結構、功能的通用性、模塊的層次(靜態)、模塊結構、處理過程的結構
      • 模塊結構：控制類結構、數據流結構、模塊結構與功能結構直接的對應消息
    • 與運行環境的結構
      • 與硬件的接口、與用戶的接口
    • 正式技術評審的目標發現軟件中的錯誤

• 軟件容錯技術

  • 實現容錯的主要手段是冗余:結構冗余(靜態動態冗余、混合冗余)、信息冗余、時間冗余、冗余附加技術
    

• 軟件工具

  • 用來輔助軟件開發、運行、維護、管理和支持等過程中的活動的軟件
  • 軟件開發工具
    • 需求分析工具、設計工具、編碼與排錯工具、測試工具
  • 軟件維護工具
    • 版本控制工具、文檔分析工具、開發信息庫工具、逆向工程工具、再工程工具

• 拓展

  • 面向對象方法有：Booch方法、Coad方法、OMT方法
  • 軟件復雜性度量：規模、結構、難度、智能度
  • 軟件工程基本要素:方法、工具、過程

總結

以上是生活随笔為你收集整理的软件设计师（软件工程）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。