天天看點

複旦大學961-軟體工程-第一章-軟體過程軟體過程的概念經典軟體過程模型的特點過程評估與CMM/CMMI的基本概念靈活宣言與靈活過程的特點課後習題

961全部内容連結

文章目錄

  • 軟體過程的概念
  • 經典軟體過程模型的特點
    • 瀑布模型
    • 演化模型
    • 增量模型
    • 統一過程模型
  • 過程評估與CMM/CMMI的基本概念
    • CMM的基本概念
    • CMMI的概念
  • 靈活宣言與靈活過程的特點
    • 靈活宣言
    • 靈活方法的共同特征
    • 精益思想的5條原則
  • 課後習題
    • 1.1 什麼是計算機軟體?軟體的特點是什麼
    • 1.2 簡述軟體的分類,并舉例說明
    • 1.3 簡述軟體語言的分類,并舉例說明
    • 1.4 什麼是軟體工程?
    • 1.5 簡述軟體工程的基本原則
    • 1.6 軟體生存周期分哪幾個階段?分别簡述各個階段的任務
    • 1.9 簡述各類軟體過程模型的特點

軟體過程的概念

  1. 軟體過程是生産一個最終滿足需求且達到工程目标的軟體産品所需的步驟。
  2. 軟體過程是軟體生命周期中的一系列相關的過程。
  3. 過程是活動的集合,活動是任務的集合。
  4. 軟體過程有三層含義:①個體含義,指軟體産品或系統在生存周期中的某一類活動的集合,如軟體開發過程,軟體管理過程等;②整體含義:指軟體産品或系統在所有上述含義下的軟體過程的總體。③工程含義:指解決軟體過程的工程,應用軟體工程的原則、方法來構造軟體過程模型,并結合軟體産品的具體要求進行執行個體化,以及在使用者環境下的運作,以此進一步提高軟體生産率,降低成本。
吐槽下:你們寫書的都非要這樣嘛,我怎麼感覺自己在背政治

經典軟體過程模型的特點

瀑布模型

瀑布模型給出了軟體生存周期的固定順序,上一階段的活動完成後向下一階段的活動過渡,最終得到所開發的軟體産品。

優點:①能確定軟體開發的順利進行、提高軟體項目的品質和開發效率起到了重要的作用。②其他軟體過程都包含了瀑布模型的成分

缺點:①客戶需求存在不确定性。②活動中的錯誤往往由前一階段造成,導緻必須回到前一階段。③修改軟體的代價高

複旦大學961-軟體工程-第一章-軟體過程軟體過程的概念經典軟體過程模型的特點過程評估與CMM/CMMI的基本概念靈活宣言與靈活過程的特點課後習題

演化模型

許多項目早期對需求不确定,為了減少不确定性為軟體開發帶來的風險,可以在擷取了一組基本需求後,通過快速分析,構造出該軟體的一個初始可運作版本,稱為原型。根據使用者試用原型的過程中提出的意見和建議,或者增加新需求,對原型進行改造,獲得原型的新版本,重複這一過程,最終得到令客戶滿意的軟體産品。

演化模型:實際上就是從構造初始的原型出發,逐漸将其演化成最終軟體産品的過程。

适用性:對軟體需求缺乏準确認識的情況。

典型的演化模型:增量模型、原型模型、螺旋模型。

增量模型

增量模型将軟體的開發過程分成若幹個日程時間交錯的線性序列,每個線性序列産生軟體的一個可釋出的“增量”版本,後一個版本是前一個版本的修改和補充,重複增量釋出得過程,直到産生最終的完善産品。

特點:

  • 融合了瀑布模型的基本成分和演化模型的疊代特征
  • 适用于需求經常發生變化的軟體開發
  • 能有計劃地管理技術風險

統一過程模型

統一過程(RUP)模型來自于UML上的工作以及相關的統一軟體開發過程。它集合了所有一般過程模型的要素,并給出了在描述和設計上的好的實踐。

RUP一般從三個視角描述過程:

  • 動态視角,給出模型中随時間所經曆的各個階段
  • 靜态視角,給出所進行的過程活動
  • 實踐視角,提出在過程中可以采用的良好實踐的建議
複旦大學961-軟體工程-第一章-軟體過程軟體過程的概念經典軟體過程模型的特點過程評估與CMM/CMMI的基本概念靈活宣言與靈活過程的特點課後習題

RUP是一個階段化的模型,識别出軟體過程當中的4個獨立階段:

  1. 開端:開端階段的目标是建立系統的一個業務案例。識别和定義所有與系統互動的外部實體。
  2. 細化:細化階段的目标是增進對問題域的了解,建立系統的體系架構,給出項目計劃并識别關鍵項目風險。
  3. 構造:構造階段主要關心系統設計、編碼和測試。
  4. 轉換:該階段關注如何将系統從開發機關轉移到使用者機關,并使之在真實環境中工作。

過程評估與CMM/CMMI的基本概念

過程評估:評價軟體過程的能力。通常使用軟體過程成熟度等級進行評判(個人了解)

CMM的基本概念

CMM(Capability Maturity Model,能力成熟度模型)模型定義了5個軟體過程成熟度等級(成熟度由低到高):

  • 初始級:軟體過程的特點是無秩序且混亂的。
  • 可重複級:建立了基本的項目管理過程來跟蹤成本、進度和功能特性。能重複早先類似應用項目取得的成功。
  • 已定義級:将管理和工程活動兩方面的軟體過程文檔化、标準化。所有項目使用标準軟體過程來開發和維護。
  • 已管理級:收集對軟體過程和産品品質的詳細路徑成本,對軟體過程和産品都有定量的了解和控制。
  • 優化級:過程的量化回報和先進的新思想、新技術促進過程不斷改進。
複旦大學961-軟體工程-第一章-軟體過程軟體過程的概念經典軟體過程模型的特點過程評估與CMM/CMMI的基本概念靈活宣言與靈活過程的特點課後習題

CMM的結構

複旦大學961-軟體工程-第一章-軟體過程軟體過程的概念經典軟體過程模型的特點過程評估與CMM/CMMI的基本概念靈活宣言與靈活過程的特點課後習題
  • 關鍵過程域,是企業需要集中力量改進的軟體過程,用于達到增加過程能力的效果。
  • 關鍵實踐,是指關鍵過程域中的一些主要實踐活動。每個關鍵過程域最終由關鍵實踐所組成,通過實作這些關鍵實踐達到關鍵過程域的目标。

CMMI的概念

CMMI的全稱為Capability Maturity Model Integration,即能力成熟度模型內建。CMMI是CMM模型的最新版本。CMMI是若幹過程模型的綜合和改進,能提高過程的品質和工作效率。

CMMI提供了兩種表示法:階段式模型和連續式模型。

  1. 階段式模型,類似于CMM,關注組織的成熟度。分為以下幾個
  • 初始的:過程不可預測且缺乏控制
  • 已管理的:過程為項目服務
  • 已定義的:過程為組織服務
  • 定量管理的:過程已度量和控制
  • 優化的:集中于過程改進
  1. 連續式模型關注每個過程域的能力,一個組織對不同的過程域可以達到不同的過程域能力等級。包括6個過程域能力等級:
  • CL0 未完成的:過程域未執行或未到達CL1中定義的所有目标。
  • CL1 已執行的:其共性目标是過程将可識别的輸入工作産品轉化為可識别的輸出工作産品,已實作支援過程域的特定目标。
  • CL2 已管理的:其共性目标集中于已管理的過程的制度化
  • CL3 已定義的:其共性目标集中于已定義的過程的制度化。
  • CL4 定量管理的:其共性目标集中于可定量管理的過程的制度化。
  • CL5 優化的:使用量化(統計學)手段改變和優化過程域,以對付客戶要求的改變和持續改進計劃中的過程域的功效。

靈活宣言與靈活過程的特點

軟體開發的3個特征(由此引出了靈活式開發):

  • 提前預測需求是困難的
  • 軟體設計和建構是交錯進行的(軟體的詳細設計和開發是交錯進行的)
  • 從制定計劃的角度來看,分析、設計、建構和測試活動并不容易預測

比較常用的靈活開發方法:極限程式設計、Scrum、看闆方法、精益軟體開發方法

靈活宣言

個體和互動 重于 過程和工具

工作的軟體 重于 詳盡的文檔

客戶合作 重于 合同談判

響應變化 重于 遵循計劃

靈活方法的共同特征

  • 緻力于降低變化帶來的成本
  • 強調價值
  • 強調人的作用
  • 使用增量和疊代的開發方法

精益思想的5條原則

  • 識别價值:價值是客戶願意購買産品的原因,也是産品開發的根本價值所在。“是否有助于增加價值”是精益方法衡量過程活動的準則
  • 定義價值流:價值流描述了組織為了傳遞價值所采取的一系列有增值的活動
  • 保持價值流的流動:良好的系統應該讓價值迅速流動,進而用較低的成本生産出正确的産品(價值流是指從原材料轉變為成品、并給它賦予價值的全部活動)(這句話的意思就是快點做(迅速流動),别停(保持流動),效率高點(低成本))
  • 拉動系統:拉動系統是基于目前客戶的需求,向上遊環節逐級回報(這個環節有問題很可能是上一個或者更之前的環節出問題了),每個環節都基于下一個環節的需求而進行生産
  • 持續改善:持續改善是精益思想的最重要支柱。精益思想的核心就是不斷進行改善進而最大化價值

課後習題

1.1 什麼是計算機軟體?軟體的特點是什麼

計算機軟體指計算機系統中的程式及其文檔。

軟體的特點:

  • 軟體是一種邏輯實體,而不是有形的系統元件,其開發成本和進度難以準确得估算
  • 軟體是被開發的或被設計的,沒有明顯的制造過程,一旦開發成功,隻需複制即可,但其維護的工作量大
  • 軟體的使用沒有硬體那樣的機械磨損和老化問題

1.2 簡述軟體的分類,并舉例說明

軟體分為系統軟體、支撐軟體和應用軟體:

  • 系統軟體:系統軟體居于計算機系統中最靠近硬體的一層,其他軟體一般都通過系統軟體發揮作用。系統軟體與具體的應用領域無關。例如:編譯程式、作業系統等
  • 支撐軟體:支撐軟體是支撐軟體的開發和維護的軟體。例如:資料庫管理系統、網絡軟體、軟體工具、軟體開發環境等
  • 應用軟體:應用軟體是特定應用領域專用的軟體。例如:工程/科學計算軟體、嵌入式軟體、産品線軟體、web應用軟體、人工智能軟體。

1.3 簡述軟體語言的分類,并舉例說明

  • 需求定義語言:用于書寫軟體需求定義的語言。如PSL
  • 功能性語言:用于書寫軟體功能規約的語言。如廣譜語言,Z語言等
  • 設計性語言:用于書寫軟體設計規約的語言。如PDL
  • 程式設計語言:用于書寫計算機程式的語言。如C,Java
  • 文檔語言:用于書寫計算機軟體文檔的語言。如ER圖,資料流圖等。

1.4 什麼是軟體工程?

軟體工程是應用計算機科學、數學及管理科學等原理,開發軟體的工程

1.5 簡述軟體工程的基本原則

  • 圍繞适宜的開發模型
  • 采用合适的設計方法
  • 提供高品質的工程支撐
  • 重視軟體工程的管理

1.6 軟體生存周期分哪幾個階段?分别簡述各個階段的任務

軟體生存周期有計算機系統工程、需求分析、設計、編碼、測試、運作和維護6個階段:

  • 計算機系統工程: 任務是确定待開發軟體的總體要求和範圍,以及該軟體與其他計算機系統元素之間的關系,進行成本估算,做出進度安排,并進行可行性分析,即從經濟、技術、法律等方面分析待開發的軟體是否有可行的解決方案,并在若幹個可行的解決方案中做出選擇
  • 需求分析:主要解決待開發軟體要“做什麼”的問題,确定軟體的功能、性能、資料、界面等要求,生成軟體需求規約
  • 軟體設計:軟體設計隻要解決待開發軟體“怎麼做”的問題。軟體設計通常可分為系統設計和詳細設計。系統設計的任務是設計軟體系統的體系結構,包括軟體系統的組成成分、各成分的功能和接口、成分間的連接配接和通信,同時設計全局資料結構。詳細設計的任務是設計各個組成成分的實作細節,包括局部資料結構和算法等
  • 編碼:編碼階段的任務是用某種程式設計語言,将設計的結果轉換為可執行的程式代碼
  • 測試:測試階段的任務是發現并糾正軟體中的錯誤和缺陷。測試主要包括單元測試、內建測試、确認測試和系統測試
  • 運作和維護:軟體完成各種測試後就可傳遞使用,在軟體運作期間,需對投入運作的軟體進行維護,即可發現了軟體中潛藏的錯誤或需要增加新的 功能或使軟體适應外界環境的變化等情況出現時,對軟體進行修改

1.9 簡述各類軟體過程模型的特點

典型的軟體過程模型有:瀑布模型、演化模型(增量模型、原型模型、螺旋模型)、噴泉模型、基于構件的開發模型和形式方法模型等

  • 瀑布模型:上一階段的活動完成并經過評審後才能開始下一階段的活動,其特征是:①接受上一階段活動的結果作為本階段活動的輸入;②依據上一階段活動的結果實施本階段應完成的活動;③對本階段的活動進行評審;④将本階段活動的結果作為輸出。
  • 增量模型:将軟體的開發過程分成若幹個日程時間交錯的線性序列,每個線性序列産生軟體的一個可釋出的增量版本,後一個版本是對前一個版本的修改和補充,重複增量釋出的過程,直至産生最終的完善産品。
  • 原型模型:從軟體工程師與客戶的交流開始,其目的是定義軟體的總體目标,辨別需求。然後快速制定原型開發的計劃,确定原型的目标和範圍,采用快速設計的方式對其模組化,并構模組化型。被開發的原型應傳遞給客戶使用,并收集客戶的回報意見,這些回報意見可在下一輪疊代中對原型進行改進。在前一個原型需要改進,或者需要擴充其範圍的時候,進入下一輪原型的疊代開發
  • 螺旋模型:将原型模型實作的疊代特征與瀑布模型中控制的和系統化的方面結合起來,不僅展現了這兩種模型的優點而且還增加了風險分析
  • 噴泉模型:是一種支援面向對象開發的過程模型。類及對象是面向對象方法中的基本成分。在分析階段,辨別類及對象,定義類之間的關系,建立對象-關系模型和對象-行為模型。在設計階段,從實作的角度對分析模型進行調整和擴充。在編碼階段,用面向對象語言實作類及對象,通過消息機制實作對象之間的通信,完成軟體的功能。在面向對象方法中,分析模型和設計模型采用相同的符号表示體系,開發的各個活動沒有明顯的邊界,各個活動經常重複,疊代地交替進行
  • 基于構件的開發模型:基于構件的開發是指利用預先包裝的建構來構造應用系統。構件可以是組織内部開發的建構,也可以是商業化的、現存的軟體構件
  • 形式化方法:形式化方法是建立在嚴格數學基礎上的一種軟體開發方法。軟體開發的全過程中,從需求分析、規約、設計、程式設計、系統內建、測試、文檔生成,直至維護等各個階段,凡是采用嚴格的數學語言,具有精确的數學語義的方法,都稱為形式化方法。形式化方法用嚴格的數學語言和語義描述功能和設計規約,通過數學的分析和推導,易于發現需求的歧義性、不完整性和不一緻性,易于對分析模型、設計模型和程式進行驗證。通過數學的演算,使得從形式化功能規約到形式化設計規約,以及從形式化設計規約到程式代碼轉換成為可能
961

繼續閱讀