軟件工程學習筆記(一):軟件工程

1 計算機軟件

1.1 軟件

計算機軟件是指計算機系統中的程序以及文檔,程序是計算任務處理對象和處理規則的描述.

1.2 軟件特色

• 一種邏輯實體.
• 維護工做量大.
• 維護軟件過程當中會引入反作用.

1.3 軟件分類

1.3.1 系統軟件

最靠近硬件的一層,好比操做系統.

1.3.2 支撐軟件

軟件開發,維護與運行的軟件,好比各類IDE等.

1.3.3 應用軟件

應用於特定領域的軟件.

2 軟件語言

軟件語言主要包括需求定義語言,功能性語言,設計性語言,程序設計語言與文檔語言.

2.1 需求定義語言

用於書寫軟件需求定義的語言,包括功能需求與非功能需求.典型的語言有PSL.

2.2 功能性語言

書寫軟件功能規約的語言,描述軟件作什麼以及只作什麼.典型語言有廣譜語言,Z語言.

2.3 設計性語言

書寫軟件設計規約的語言,是軟件設計的嚴格而完整的描述.典型語言有PDL.

2.4 程序設計語言

即編程語言,能夠分爲低級語言與高級語言,過程式語言與非過程式語言,通用語言與專用語言,交互式語言與非交互式語言,順序語言與併發語言與分佈語言.

2.5 文檔語言

書寫軟件文檔使用的語言,好比Z語言.

3 軟件工程

軟件工程是創建和使用一套合理的工程原則,以便得到經濟的軟件,這種軟件是可靠的,能夠在實際機器上高效地運行.軟件工程是應用計算機科學理論以及工程管理原則的方法,按預算與進度實現知足用戶要求的軟件產品的工程,或以此爲研究對象的學科.

4 軟件工程的基本原則

4.1 適宜的開發規範

選用適宜的開發規範,以保證軟件開發的可持續性,並使最終的軟件產品知足客戶的需求.

4.2 合適的設計方法

要考慮軟件的模塊化,信息隱藏,局部化,一致性以及適應性等問題,採用合適的設計方法有助於支持問題的解決與實現.

4.3 高質量的工程支持

須要提供高質量的工程支持,例如配置管理,質量保證等.

4.4 有效的軟件工程管理

軟件工程的管理直接影響可用資源的有效利用,以提升軟件組織的生產能力.

5 軟件生存週期

軟件生存週期分爲6個階段:

5.1 計算機系統工程

計算機系統工程的任務是肯定待開發軟件的整體要求與範圍,以及該軟件與其餘計算機系統元素之間的關係,進行成本估算,做出進度安排,並進行可行性分析.

5.2 需求分析

需求分析主要解決待開發軟件要作什麼的問題,肯定軟件的功能,性能,數據,界面等要求,生成軟件需求規約.

5.3 設計

軟件設計主要解決待開發軟件怎麼作的問題,一般能夠分爲系統設計與詳細設計,系統設計的任務是設計軟件系統的體系結構,詳細設計的任務是設計各個組成成分的實現細節.

5.4 編碼

利用程序設計語言進行編碼.

5.5 測試

發現並糾正軟件中的錯誤與缺陷,包括單元測試,集成測試,確認測試與系統測試.

5.6 運行與維護

軟件運行期間須要進行維護,對軟件進行修改.

6 CMM

CMM是能力成熟度模型,定義了5個軟件過程成熟度等級,包括初始級,可重複級,已定義級,已管理級,優化級.

6.1 初始級

軟件過程的特色是無秩序的,甚至是混亂的,幾乎沒有什麼過程是通過妥善定義的.

6.2 可重複級

創建了基本的項目管理過程來跟蹤成本,進度與功能特性.制定了必要的過程紀律,能重複早先相似應用項目取得的成功.

6.3 已定義級

已將管理和工程活動兩方面的軟件過程文檔化,標準化,並綜合成該組織的標準軟件過程.全部項目均使用經批准,剪裁的標準軟件過程來開發與維護軟件.

6.4 已管理級

收集對軟件過程和產品質量的詳細度量值,對軟件過程和產品都有定量的理解與控制.

6.5 優化級

過程的量化反饋和先進的新思想,新技術促使過程不斷改進.

7 CMMI

CMMI是若干過程模型的綜合與改進,是支撐多個工程學科和領域的系統的,一致的過程改進框架,能適應現代工程的特色與須要,能提升過程的質量與工做效率.CMMI有兩種表示法:階段式模型與連續式模型.

7.1 階段式模型

階段式模型的結構相似於CMM,分爲5個成熟度等級:

7.1.1 初始的

過程不可預測且缺少控制.

7.1.2 已管理的

過程爲項目服務.

7.1.3 已定義的

過程爲組織服務.

7.1.4 定量管理的

過程已度量和控制.

7.1.5 優化的

集中與過程改進.

7.2 連續式模型

連續式模型關注每一個過程域的能力,一個組織對不一樣的過程域能夠達到不一樣的過程域能力等級.
CMMI包含了6個過程域能力等級,等級號爲0-5,能力等級代表了單個過程域中組織執行的好壞程度.能力等級包括共性目標及相關的共性實踐,能夠獨立地應用於任何單獨的過程域,各能力等級的含義:

7.2.1 CL0

未完成的,過程域未執行或未達到CL1中定義的全部目標.

7.2.2 CL1

已執行的,其共性目標是過程能夠將標識的輸入工做產品轉換成可標識的輸出工做產品,以實現支持過程域的特定目標.

7.2.3 CL2

已管理的,共性目標是集中於已管理的過程的制度化.根據組織政策規定過程的運做將使用哪一個過程,項目遵循已文檔化的計劃和過程描述,全部正在工做的人都有權使用足夠的資源,全部工做任務和工做產品都被監督,控制和評審.

7.2.4 CL3

已定義的,共性目標是集中於已定義的過程的制度化.過程是按照組織的剪裁指南從組織的標準過程集中剪裁獲得的,還必須收集過程資產和過程的度量,並用於未來對該過程的改進上.

7.2.5 CL4

定量管理的,共性目標是集中於可定量管理的過程的制度化.使用測量與質量保證來控制和改進過程域,創建和使用關於質量和過程執行的定量目標做爲管理準則.

7.2.6 CL5

優化的,使用量化手段改變和優化過程域,以應對客戶的要求的改變與持續改進計劃的過程域的功效.

8 軟件過程模型

軟件過程模型習慣上也叫軟件開發模型,是軟件開發所有過程,活動和任務的結構框架.

8.1 瀑布模型

1970年由W.Royce提出,給出了軟件生存週期活動的固定順序,上一階段的活動完成後向下一階段活動過渡,最終獲得開發的軟件產品.瀑布模型中上一階段的活動完成並通過評審後才能開始下一階段的活動,特徵是:

• 接受上一階段活動的結果做爲本階段活動的輸入.
• 依據上一階段活動的結果實施本階段應完成的活動.
• 對本階段的活動進行評審.
• 將本階段活動的結果做爲輸出,傳遞給下一階段.

8.1.1 優勢

最先出現應用最普遍的模型,確保軟件開發的順利進行,對提升軟件項目的質量和開發效率起到重要做用.

8.1.2 缺點

• 用戶難以清晰描述全部需求,開發過程當中需求也有可能發生改變.
• 發現錯誤時,爲了改正錯誤要回到前一階段,形成瀑布倒流.
• 在測試完成後才能夠看到可運行的軟件,發現問題的修改代價極大.

8.2 增量模型

增量模型將軟件的開發過程分紅若干個日程時間交錯的線性序列,每一個線性序列產生一個可發佈的增量版本,後一個版本是對前一個版本的修改和補充,重複增量發佈的過程,直至產生最終的完善產品.

8.2.1 優勢

適用於需求常常發生變化的軟件開發,之後的增量中能夠逐漸加入需求,另外能夠有計劃地管理技術風險.

8.2.2 缺點

須要良好的架構設計,避免加入的構件破壞已構造好的系統部分,須要對系統有好的全盤分析,不然容易退化成邊作邊改模型.

8.3 原型模型

原型是預期系統的一個可執行版本,反映了系統性質的一個選定的子集.一個原型沒必要知足目標軟件的全部約束,目的是能夠快速,低成本地構建原型.步驟是:

定義整體目標 --> 標識需求 --> 指定原型開發計劃--> 肯定原型目標和範圍--> 快速設計建模-->
構建原型 --> 交付使用--> 收集反饋意見 -- > 下一輪原型迭代開發--> 定義整體目標

8.3.1 優勢

用戶與開發者在原型上達成一致,減小錯誤,縮短開發週期,加快進度,下降成本.

8.3.2 缺點

不利於原型系統做爲最終產品,原型被建造僅僅是用戶用來定義需求,以後便會被部分或所有拋棄,準確的原型設計比較困難,不利於開發人員創新.

8.4 螺旋模型

螺旋模型將原型實現的迭代特徵與瀑布模型中的控制的和系統化的方面結合起來,增長了風險分析.螺旋模型沿着螺線自內向外旋轉,4個任務區域(4個象限)內分別完成如下任務:

• 第一象限:風險分析,評價所選方案,識別風險,清楚風險.
• 第二象限:制訂計劃,肯定軟件目標,選定實施方案,弄清項目開發的限制條件.
• 第三象限:客戶評估,評價開發工做,提出修正建議.
• 第四象限:工程實施,實施軟件開發,驗證工做產品.

(圖片來源:https://www.itread01.com/content/1544588849.html)

8.4.1 優勢

設計靈活,成本計算容易,客戶始終參加每一個階段的開發,能夠進行有效的互動.

8.4.2 缺點

週期長,須要豐富的風險評估經驗以及專門知識,若是未能及時標識風險,勢必形成重大損失.

8.5 噴泉模型

噴泉模型是一種支持面向對象開發的過程模型.噴泉體現了面向對象的迭代與無間隙特性.

8.5.1 優勢

各個階段沒有明顯的邊界,開發人員能夠進行同步開發,提升軟件項目的開發效率,節省開發時間.

8.5.2 缺點

不利於項目管理,要求嚴格編寫文檔,審覈難度大.

8.6 基於構件的開發模型

利用預先包裝的構件來構造應用系統.構件能夠是內部開發的構件,也能夠是商業化的構件.

8.6.1 優勢

構件可重用,易於維護,對提升軟件生產率,提升軟件質量,下降成本有很大的幫助.

8.6.2 缺點

很難找到100%合適的構件,就是現有的構件不必定很適合使用,但基於已有構件構造出的構件未必通過100%的測試,難以保證質量.

8.7 形式化方法模型

形式化方法是創建在嚴格的數學基礎上的一種軟件開發方法,用嚴格的數學語言和語義描述功能規約與設計規約,經過數學的分析與推導,易於發現需求的歧義性,不完整性與不一致性,易於對分析模型,設計模型和程序進行驗證.經過數學的演算,使得從形式化功能規約到形式化設計規約,以及從形式化設計規約到程序代碼的轉換成爲可能.

8.7.1 優勢

用數學語言解決了規格說明的二義性問題,提升了精確性用數學提供了確認手段,使得證實與驗證軟件按程序知足用戶和系統的需求成爲可能,能夠可視化地模擬/執行模型.

8.7.2 缺點

形式化的方法比其餘技術的抽象級別要低,容易陷入細節,須要提前肯定系統邊界,一般限於正確一致的模型,但大多數狀況下模型並不是正確與一致.