軟件工程導論要點

重點:編程能力很強不代表軟件工程能力強!

1、學習軟件工程的意義:
(1)所有發達國家的經濟都依賴軟件
(2)軟件工程這門課涉及到職業軟件開發流程,幫助你更加了解實際上軟件是如何生產的

2、評判軟件好壞的標準
(1)軟件費用 (2)開發時間(一旦交付太晚可能會被他人搶先一步)
3、什麼是軟件
(1)軟件 = 程序 + 文檔
(2)軟件包括通用產品和定製產品。通用產品一般是直接生產後供人使用,定製產品是先了解相關需求,再生產產品。

4、什麼是軟件過程
(1)軟件開發的過程
(2)開發、維護軟件的過程,是所有軟件過程中共通的活動
(3)包括軟件描述(需求分析、寫文檔)、軟件開發、軟件有效性驗證(產品測試)、軟件進化(根據客戶需求變化而變化)。
(4)陳xx老師重點講兩頭,也就是軟件描述(需求分析、寫文檔)、軟件進化
(5)軟件過程沒有定式,不同的公司有不同的軟件過程,但是有一些通用模型。這些模型不是萬能的,但基本有效。

5、軟件工程
(1)軟件工程:做軟件
(2)系統工程:做硬件
(3)開發成本60%,測試成本40%
(4)對於定製軟件,軟件測試成本大於生產成本(通常開發出來無法完全滿足要求,要修改程序)
(5)軟件工程的交付物:需求規格說明書、總體設計書、測試表格

6、軟件工程方法
(1)軟件工程方法是一種軟件開發的結構化方法,目的在於提高軟件的性價比。

7、結構化軟件工程方法
(1)曾經的軟件開發喜歡使用goto,但是被循環、選擇、順序結構所取代。goto使得程序結構混亂,而後者使得程序完全有三種結構所組成,實現結構化編程
(2)結構化分析方法:需求也可以分解爲一個個結構,實現結構化分析方法

8、計算機輔助軟件工程CASE
(1)computer assisted software engineering
9、優良軟件必備屬性
(1)可維護性(能不斷進化滿足變化的需求) (2)可依賴性 (值得信賴,如一個錯誤率99.9999999%的計算機不被信賴)(3)有效性(不浪費資源) (4)可用的(指用戶能用,不僅僅是開發者能用,也要方便用戶能用)
10、軟件工程面臨的挑戰
(1)遺留系統。舊的有價值的系統需要更新,但是沒有人懂遺留系統,遺留系統的規則和現在軟件規則可能不相同,遺留系統遺留的文檔不足
11、軟件過程
(1)描述
(2)設計、開發(有時候只說設計或者只說開發,實際上同時指設計開發)
(3)有效性驗證
(4)進化
12、瀑布模型
(1)將開發過程劃分爲若干階段
(2)只有當前一個階段完成後才進行下一個階段
(3)一般有若干階段:需求定義、系統和軟件設計、實現和單元
測試、集成和系統測試、操作和維護
(4)優點:邏輯清楚。大項目適合使用瀑布模型
(5)缺點:對需求更改沒有適應性
在這裏插入圖片描述
13、瀑布模型擴展-V模型
在這裏插入圖片描述進行需求分析之後就可以敲定如何進行系統、交付

14、進化式開發
(1)爲了理解適應不充分的需求
(2)探索式原型:和客戶一起工作,從最初的需求草案進化到最後的系統。應該從理解最清楚的需求開始
(3)拋棄式原型:目的是理解系統需求。從理解較差的需求開始。
(4)進化式開發本質上是弄幾個模型出來,讓客戶看看,讓其選擇,從而理解客戶的需求。幾個原型是可以同時進行描述、開發、驗證的
(5)缺點:缺乏過程可見性,系統結構通常較差,需要特殊的工具和計數(比如快速建立原型的技術)
(6)適用性:適用於中小型交互式系統,適用於大型系統的一部分(如用戶界面),適用於生命週期短的系統。
(7)注意:凡是交互式界面都不容易弄清楚需求,因此交互式系統適合用進化式開發

15、形式化開發
(1)優點:只需要進行形式化描述就可以免去開發的而麻煩;適用於嚴格的系統,特別是安全性和保密性極高的系統
(2)缺點:需要專業技能和訓練;形式化開發不是萬能的,一些方面難以描述, 如用戶界面

在這裏插入圖片描述

16、面向組件的開發
(1)基於已有組件的系統;COTS系統 (commercial off-the-shelf商用現成品)
(2)階段:分析組件、需求修正(這種開發方式的最大特點)、基於組件重用的系統設計、開發和集成
17、增量式開發
(1)系統不是一次性開發的,而是將要求的功能分成多次增量進行開發和交付。
(2)用戶的需求是有優先順序的, 優先級最高的需求在最初的增量當中
18、增量式開發的優勢
(1)系統可以較早地被看到
(2)較早的增量可以作爲原型幫助理解後面增量的需求
(3)項目總體失敗的風險降低
(4)最高優先級的系統功能是最早的增量,得到最多的測試

在這裏插入圖片描述
19、螺旋式開發和增量式開發的區別
(1)增量式開發就好像是畫中國地圖,一個 一個省份來畫
(2)螺旋式開發好像是先畫輪廓、再畫省份、再畫市

20、需求工程過程
(1)需求工程過程
(2)圓角矩形表示動詞,直角矩形表示名詞

在這裏插入圖片描述
21、測試、檢驗、有效性驗證
(1)測試,跑程序
(2)檢驗verification,強調過程
(3)有效性驗證validation,強調結果

22、CASE
計算機輔助軟件工程

**PM PL PG **在這裏插入圖片描述
23、系統交付物
(1)代碼
(2)需求規格書
(3)系統設計書
(4)測試報告書
(5)運行環境

24、風險矩陣
在這裏插入圖片描述
25、python語法
(1)def main:這個函數裏面的程序只有當該python腳本直接作爲執行程序時纔會運行,當該python腳本作爲module被導入時main函數的內容不執行

在這裏插入圖片描述
(2)if name = ="main"這句話就是用來判斷本腳本是不是直接作爲可執行文件執行的。如果滿足條件,就說明該腳本是直接執行,運行main函數。如果不滿足條件,說明該腳本是被調用的。

26、database schema table
(1)schema是若干table的集合

27、風險管理
(1)風險識別
需求不明確(讓用戶參與開發)、硬件兼容性
(2)風險分析
(3)風險規劃
(4)風險監控

** 28、項目管理和開發進度表管理**
(1)項目分解
(2)子項目排序(注意前置項目需要串行,非前置項目可以並行)
(3)估算子項目時長(注意顆粒度)
(4)項目分工
(5)做出甘特圖

29、功能需求和非功能需求
(1)功能需求:描述系統的服務,如何響應特定的輸入,系統在特定情形下應該如何動作
(2)非功能要求:一些額外的約束,如符合一定標準、隱私性要求

30、目標和可檢驗非功能需求
(2)用戶目標一般是比較模糊,要轉化成可檢驗的非功能需求
(1)系統目標:要求一個系統有易用性
(2)可檢驗的非功能需求:經過兩小時培訓,有經驗的管理員應該能使用所有的系統功能。經過培訓後,有經驗用戶的平均錯誤數量不超過2個錯誤/天

31、MTTF和MTBF
mean time to failure 平均失效前時間
mean time between faliure 平均失效間隔時間
mean time to restoration 平均恢復前時間

32、用戶需求和系統需求
(1)用戶需求是寫給用戶看的
(2)系統需求是寫給開發者看的
(3)系統需求是比用戶需求更詳細的需求

33、需求文檔
(1)需求文檔的英文翻譯是需求規格書。其實需求規格書就是需求文檔,描述了所有需求。
(2)需求規格書不是系統文檔,是寫要幹什麼不寫怎麼幹
(3)需求文檔是對需求的正式表達
(4)需求文檔一條需求和一個章節寫完,如果本頁還有留白也不能在留白上寫下一需求和下一章節。要在下一頁寫嚇一跳需求和下一章節,方便以後有添加。滿足容易改變的特點。
(5)寫需求可以使用特定的軟件
(6)需求文檔包含用戶需求和系統需求,通常寫在一份文檔當中。系統需求要用結構化的方式來表示
34、需求文檔的需求需要有編號
(1)需求要編號
(2)需求要刪除,就用刪除線刪除掉。但不能直接刪除

35、需求文檔包含用戶需求和系統需求

36、需求工程的過程
在這裏插入圖片描述

需求工程
1、需求工程的產出物是需求規格書
2、需求工程過程包括:需求導出、需求分析、需求驗證、需求管理
3、需求導出的基本出發點是,關於具體的需求客戶自己說不出來,需要自己去挖掘,也就是從客戶的腦子裏導出。需求導出有面向視點的導出、有VORD方法

用例
在這裏插入圖片描述

序列圖
在這裏插入圖片描述
豎線代表軟件執行的時間方向。矩形代表運行的程序,箭頭代表事件。事件激活一段程序運行或者不運行。
序列圖描述的是具體的時間,程序流程圖更加具體(因爲寫了if else等邏輯)。程序流程圖是最詳細的,對於大型軟件一般不會再用程序流程圖,而是用序列圖。

需求規格說明書(SRS)格式
一、概述(或者叫引言)
1、編寫目的【讀者是誰,編寫需求規格書的目的是什麼】
2、產品背景
3、產品功能
二、標準和規範
1、術語定義
2、數據描述(數據流圖DFD、數據字典DD)
2、參考資料
三、接口
1、用戶界面
2、硬件界面
3、軟件界面
三、功能需求編號和描述(需要結構化描述)
(1)需求編號
(2)需求名稱
(3)需求概述
(4)輸入
(5)輸出
(6)功能處理
(7)備註
四、非功能需求(性能需求)
(1)安全性
(2)易用性
(3)反應時間、
五、特殊需求

對象模型
在這裏插入圖片描述
(1)面向對象的典型操作的是繼承,存在繼承就存在層級。一般層級不能太多,防止系統混亂。上面的圖當中,頂上的是父類,是被繼承的。個人感覺箭頭的指向不對。

(2)對象和類本質上就是抽象數據結構APT,一些相同的對象構成類。也就是對象是個體,類是整體。

UI開發
(1)大多數情況下用戶不會有完整的UI需求,因此要使用原型開發,沒有別的方式。
(2)原型開發的目的是爲了導出系統需求

數據流圖DFD和數據字典DD
(1)數據流圖和數據字典是需求規格說明書SRS中的標準和規範當中的部分
(2)數據流圖DFD,基本格式是 輸入->操作->輸出,其中操作用圓圈圈起來,輸入和輸出數據寫在箭頭上。
(3)數據字典DD是對數據流圖DFD中出現過的數據名稱加以說明。格式如下:
數據流名:發票
說明:用作學生已付書款的證據
數據流來源:
數據流去向:
數據流組成:學生+姓名+書號+單價總和+書費合計

信息安全
(1)信息安全(security)其實是信息保密

V(verify)&V(valid)
(1)verify檢驗和valid有效性驗證
(2)verify考慮寫的代碼有沒有語法錯誤
(3)valid考慮結果有沒有錯誤

在這裏插入圖片描述

沿觸發和電平觸發
(1)沿觸發,推薦用non-blocking(實際上可以的)
(2)電平觸發,推薦用blocking(實際上可以的)
(3)這樣規定只是爲了將non-blocking和blocking分開,方便閱讀。如:
m=5;
n=4;
n<=m;
r=n;
這裏non-blocking是最後執行的,所以r實際山是4。
(4)不要在多個always模塊裏面對同一個變量賦值,由於他們之間的順序不確定,結果也是不確定的。
(5)setup time,hold time,clock to output,process,voltage,temperature。電壓高延時低,溫度低延時低
在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章