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 缺點
形式化的方法比其他技術的抽象級別要低,容易陷入細節,需要提早確定系統邊界,通常限於正確一致的模型,但大多數情況下模型並非正確與一致.