天津理工大學-軟件工程總結(jié)考試

1、軟件過程的步驟或基本活動：1.軟件描述 2.軟件設計和實現(xiàn) 3.軟件有效性驗證 4.軟件進化軟件生命周期或軟件需求過程 1.需求分析和定義2.系統(tǒng)和軟件設計3.實現(xiàn)和單元測試4.集成和系統(tǒng)測試5.運行和維護增量式開發(fā)過程的好處是：1客戶無需等到整個系統(tǒng)的實現(xiàn)。第一個增量會滿足他們大多數(shù)關鍵的需求，因此，軟件馬上就能使用。2.客戶可以將早期的增量作為原型，從中獲得對后面系統(tǒng)增量的需求經(jīng)驗。3.項目總體性失敗的風險比較低。雖然可能在一些增量中遇到問題，但是其他一些增量將會成功的交付給客戶4.因為具有最高優(yōu)先權的服務被首先交付，而后面的增量也不斷被集成進來，這就使得最重要的系統(tǒng)服務肯定接受了最多的測

2、試。這就意味著在系統(tǒng)的最重要的部分，客戶不太可能遇到軟件失敗。第一章軟件工程和計算機科學的區(qū)別： 計算機科學側(cè)重理論和基礎，而軟件工程則側(cè)重于軟件開發(fā)和交付的實際活動軟件工程和系統(tǒng)工程的區(qū)別： 系統(tǒng)工程側(cè)重基于計算機系統(tǒng)開發(fā)的所有方面，包括硬件，軟件，和處理工程。軟件工程只是它的一部分1.軟件是計算機程序和所有使程序正確運行所需要的相關文檔和配置信息軟件產(chǎn)品分為：Generic通用、Bespoke (custom)定制2、軟件工程是一門工程學科，涉及軟件生產(chǎn)的各個方面。軟件工程人員運用的是系統(tǒng)的、有組織的工作方法。6、軟件過程模型 從特定角度提出的軟件過程的簡化表示形式Examples of

3、process perspectives are 工作流模型 數(shù)據(jù)流或活動模型 角色/動作模型軟件開發(fā)模型Waterfall瀑布型開發(fā)方法 Iterative development迭代式開發(fā)方法 Component-based software engineering（CBSE）基于組件的軟件工程7、the costs of software engineering軟件工程的成本軟件開發(fā)成本約占60%，測試成本占40%。對于定制軟件而言，進化成本常常高于開發(fā)成本。8、software engineering methods軟件工程方法：.軟件開發(fā)的結(jié)構(gòu)化研究方法，包括：系統(tǒng)模型、標記法、規(guī)劃

4、、設計忠告和過程指南9、CASE (Computer-Aided Software Engineering)計算機輔助軟件工程： 旨在使軟件過程活動自動化的軟件系統(tǒng)。CASE常用作方法支持10、the attributes of good software優(yōu)良軟件的特點：軟件應具有用戶所需的功能與性能，而且應該可維護、可靠、可用11、key challenges facing software engineering軟件工程面臨的主要挑戰(zhàn)：Legacy遺留 Heterogeneity多樣性挑戰(zhàn) delivery交付上的挑戰(zhàn) trust信任的挑戰(zhàn)2Software engineering cos

5、t analysis 軟件工程成本分析定制軟件：對于瀑布模型，系統(tǒng)描述、設計、實現(xiàn)和集成的成本獨立測算，其中系統(tǒng)集成和測試活動所需的費用最高，約占40%。對于迭代式開發(fā)，系統(tǒng)描述、設計和開發(fā)之間沒有嚴格的劃分界限，但系統(tǒng)描述的成本降低。在軟件開發(fā)活動中，系統(tǒng)描述、實際、實現(xiàn)、集成和測試是并行的。基于組件的軟件開發(fā)，描述部分約20%，開發(fā)成本約30%，集成和測試約50%除系統(tǒng)開發(fā)成本之外，在軟件投入使用后軟件的變更也需要成本。進化成本對許多使用期限長的軟件系統(tǒng)而言，有可能超過開發(fā)成本的34倍。相對于小的業(yè)務系統(tǒng)就降低許多了。為個人計算機配置的軟件產(chǎn)品這類產(chǎn)品通?；谝粋€概要描述，用進化式開發(fā)方法

6、開發(fā)。描述成本相對較低，但由于要用在不同的配置中，所以測試成本比較多。通用軟件產(chǎn)品進化成本很難估算。多數(shù)情況下，產(chǎn)品的進化過程并不大。通用軟件的進化成本不能像定制軟件一樣獨立評估，而是作為該系統(tǒng)的下一個版本的開發(fā)成本。第二章1System engineering process 系統(tǒng)工程過程系統(tǒng)退役系統(tǒng)進化系統(tǒng)安裝系統(tǒng)集成子系統(tǒng)開發(fā)系統(tǒng)設計需求定義2System modeling 系統(tǒng)建模在系統(tǒng)需求和設計活動中，系統(tǒng)被建模成一系列組件和組件間的關系。通常是以圖的形式描述在系統(tǒng)體系結(jié)構(gòu)模型中。系統(tǒng)體系結(jié)構(gòu)模型通常以方塊圖來描述，展現(xiàn)一些主要的子系統(tǒng)以及這些子系統(tǒng)之間的關聯(lián)。3System evo

7、lution 系統(tǒng)進化大型和復雜的系統(tǒng)都會有一個非常長的生存期。在整個生存期內(nèi)，必須改進原有的系統(tǒng)需求中的錯誤進而滿足出現(xiàn)的新需求。使用系統(tǒng)的機構(gòu)可能重新改組并且因此一種不同的方式使用系統(tǒng)4System procurement process 系統(tǒng)采購過程系統(tǒng)的采購過程主要是對機構(gòu)以最佳方式獲得系統(tǒng)做出決策并決定系統(tǒng)的最佳提供商簽訂開發(fā)合同合同談判選擇投標人發(fā)出招標請求選擇供應商發(fā)出招標請求選擇系統(tǒng)調(diào)整需求對現(xiàn)有系統(tǒng)做市場調(diào)查第四章進化式開發(fā)有兩個基本類型; 探索式開發(fā) 其目標是與用戶一起工作，共同探索系統(tǒng)需求，知道最后交付系統(tǒng)。這類開發(fā)是從需求較清楚的部分開始，根據(jù)用戶的建議逐漸向系統(tǒng)中添加

8、功能。 拋棄式原型 這種開發(fā)方法的目標是理解用戶需求，然后在給系統(tǒng)需求有更深刻理解時，能夠很快在軟件過程的好處是描述可以不斷地補充完整?；谶M化式方法的軟件過程的好處是描述可以不斷地補充完善 存在兩個問題 1.過程不可見 管理者需要經(jīng)常性得交付來把握進度，如果系統(tǒng)開發(fā)速度很快，要產(chǎn)生每個版本的文檔來反應變更就很不劃算了一、軟件工程模型software process model二、（1）waterfall model瀑布模型：直到上一階段完成，下一階段才能啟動（2）Evolutionary development進化式開發(fā)：優(yōu)勢：描述可以不斷補充完善劣勢：過程不可見;系統(tǒng)結(jié)構(gòu)通常較差進化式開發(fā)

9、的兩種基本類型：Exploratory development 探索式開發(fā)、Throw-away prototyping拋棄式原型（3）Component-based software engineering基于組件的軟件工程（Reuse-oriented development面向復用的軟件開發(fā)方法）其過程模型如下圖：三、Spiral development螺旋式開發(fā)它不是將軟件過程用一系列活動和活動間的回溯來表示，而是將過程用螺旋線表示。每個回路表示軟件過程的一個階段。2、四部分：目標設置 風險評估和規(guī)避、開發(fā)和有效性驗證、規(guī)劃.四、Software validation軟件有效性驗證：是

10、要看系統(tǒng)是否符合它的描述以及系統(tǒng)是否符合客觀的預測目標。5、 測試過程的階段：組件測試、系統(tǒng)、接收測試五、Activities in CASE (Computer-aided software engineering) 六、CASE classification分類：從功能角度看；從過程角度看；從集成角度看Fuggetta提出的分類：工具，工作平臺,環(huán)境第五章一、 Management activities管理活動.提出書面建議 .項目規(guī)劃和調(diào)度 .項目成本 項目監(jiān)督和審評 .人員選擇和評價 .寫作并稱述工作報告二、 Types of planning計劃的類型質(zhì)量計劃、有效性驗證計劃、配置管

11、理計劃、維護計劃、人員開發(fā)計劃三、 Milestones in the requirements process需求過程里程碑：四、 Project scheduling process項目調(diào)度五、 three main project management： 項目風險 產(chǎn)品風險 業(yè)務風險types of risk in project management：技術風險、人員風險、機構(gòu)風險、需求、估算.第六章1Functional requirement and examples 功能需求和舉例 功能需求描述系統(tǒng)所預期提供的功能或服務。取決于開發(fā)的軟件類型，軟件未來的用戶以及開發(fā)的系統(tǒng)類型。LI

12、BSYS-大學圖書館系統(tǒng)幾種功能需求：用戶能從總的數(shù)據(jù)庫中查詢或者是選擇其中的一個子集系統(tǒng)能提供適當?shù)臑g覽器供用戶閱讀館藏文獻每次借閱能對應一個獨特的識別符(order_id)，可拷貝到用戶賬戶的常備儲存區(qū)內(nèi)2Non-functional requirement and examples 非功能需求和舉例對系統(tǒng)提供的服務或功能給出的約束，與系統(tǒng)的總體特性相關。圖書館系統(tǒng)的LIBSYS的產(chǎn)品需求，機構(gòu)需求和外部需求的實例：產(chǎn)品需求：它應該能將所有APSE和用戶之間的必須的通信用標準的Ada字符集表達機構(gòu)需求：系統(tǒng)開發(fā)過程和可交付的文檔將遵照XYZCo-SP-STAN-95中的相關定義外部需求：系

13、統(tǒng)不應該對系統(tǒng)的操作人員公開客戶出名字和索引代碼之外的任何個人的信息三、types of Non-functional requirement四、metrics in Non-functional requirement Requirements measures非功能需求度量性質(zhì)度量方法速度每秒處理的事務用戶/事件響應時間屏幕刷新時間規(guī)模K字節(jié)RAM芯片數(shù)易用性培訓時間幫助畫面數(shù)可靠性失敗平均時間無效的概率失敗發(fā)生率有效性魯棒性失敗之后的重啟次數(shù)事件引起失敗的百分比失敗中數(shù)據(jù)崩潰的可能性可移植性依賴于目標的語句百分比目標系統(tǒng)數(shù)5Documents used in software requi

14、rements 軟件需求文檔軟件需求文檔是對系統(tǒng)開發(fā)者應當實現(xiàn)的內(nèi)容的正式陳述。包括系統(tǒng)的用戶需求和一個詳細的系統(tǒng)需求描述。需求文檔中內(nèi)容的詳細程度，取決于所要開發(fā)的系統(tǒng)的類型，以及所使用的開發(fā)過程。第七章1The process of requirement engineering 需求工程的過程系統(tǒng)可行性研究；需求導出和分析；需求描述；需求有效性驗證需求有效性驗證可行性研究需求描述用戶需求和系統(tǒng)需求可行性報告需求文檔需求導出和分析系統(tǒng)模型2The main content of feasibility studies 可行性研究的主要內(nèi)容進行一項可行性研究包括信息評估，信息匯總和報告生成3

15、Process activities in requirement elicitation and analysis 需求導出和分析的過程活動需求發(fā)現(xiàn)；需求分類和組織；優(yōu)先排序和沖突解決；需求文檔編制4Requirement validation techniques(three) 需求有效性驗證技術需求評審；原型建立；測試用例生成5Requirement change management 需求變更管理三個基本階段：問題分析和變更描述過程：始于一個被識別的需求問題或是一份明確的變更提議變更分析和成本計算：使用可追溯性信息和系統(tǒng)需求的一般知識對被提議的變更產(chǎn)生的影響進行評估變更實現(xiàn)：必要的話，

16、需求文檔，系統(tǒng)設計和實現(xiàn)都要做修改第八章* 1Principle system model 上下文模型context model 行為模型 Behavioural models數(shù)據(jù)模型 data model 對象模型 object model 結(jié)構(gòu)化方法 structured methods2Examples of system models(5) 系統(tǒng)模型實例數(shù)據(jù)流模型(data processing model)；組成模型(composition model)；體系結(jié)構(gòu)模型(architectural model)；分類模型(classfication model)；激勵-響應模型(sti

17、mulate/response model)3Definition of data-flow models 數(shù)據(jù)流模型的定義（自上而下的模型）數(shù)據(jù)流模型是從功能角度來看待系統(tǒng)而得到的模型表示，對數(shù)據(jù)的每一個變換用一個函數(shù)或過程來描述，描述了所發(fā)生的完整的行動序列，從對輸入的處理到系統(tǒng)的響應。第十一章1 Content of architectural models 體系結(jié)構(gòu)模型的內(nèi)容靜態(tài)結(jié)構(gòu)模型；動態(tài)結(jié)構(gòu)模型；接口模型；關系模型；分布模型2 Major components of Client-sever model 客戶機/服務器模型的主要組成部分一組給其他子系統(tǒng)提供服務的單機服務器；一組向

18、服務器請求服務的客戶機；一個連接客戶機和服務器的網(wǎng)站第十七章1 Describe incremental development and prototyping by figure 用圖形描述增量式開發(fā)和原型構(gòu)造可執(zhí)行原型+系統(tǒng)描述交付的系統(tǒng)概要需求拋棄式原型構(gòu)造進化式開發(fā)2 Tools included in a Rapid Application Development 快速應用開發(fā)的工具數(shù)據(jù)庫編程語言；界面生成器；與辦公應用的連接；報告生成器第二十三章1Model of the software testing process 軟件測試過程的模型系統(tǒng)測試；組件測試；測試用例設計；測試自動

19、化設計測試用例將結(jié)果與測試用例進行比較用測試數(shù)據(jù)運行程序準備測試數(shù)據(jù)測試報告測試結(jié)果測試數(shù)據(jù)測試用例2Structural testing 結(jié)構(gòu)化測試結(jié)構(gòu)化測試是根據(jù)軟件的結(jié)構(gòu)知識和實現(xiàn)知識導出測試的測試用例設計方法，又稱為“白盒測試”一、軟件需求分析1、需求分析的任務就是借助于當前系統(tǒng)的邏輯模型導出目標系統(tǒng)的邏輯模型，解決目標系統(tǒng)的 “做什么” 的問題。2、結(jié)構(gòu)化分析方法l 面向數(shù)據(jù)流進行需求分析的方法l 結(jié)構(gòu)化分析方法適合于數(shù)據(jù)處理類型軟件的需求分析l 具體來說，結(jié)構(gòu)化分析方法就是用抽象模型的概念，按照軟件內(nèi)部數(shù)據(jù)傳遞、變換的關系，自頂向下逐層分解，直到找到滿足功能要求的所有可實現(xiàn)的軟件為

20、止描述銀行取款過程的數(shù)據(jù)流圖：4、結(jié)構(gòu)花英語：是一種介于自然語言和形式化語言之間的語言，語言的正文用基本控制結(jié)構(gòu)進行分割，加工中的操作用自然語言短語來表示其基本控制結(jié)構(gòu)有三種：簡單陳述句結(jié)構(gòu)：避免復合語句；重復結(jié)構(gòu)：while_do 或repeat_until 結(jié)構(gòu)。判定結(jié)構(gòu)：if_then_else 或case_of 結(jié)構(gòu)；例子：商店業(yè)務處理系統(tǒng)中“檢查發(fā)貨單”：if 發(fā)貨單金額超過$500 then if 欠款超過了60天 then 在償還欠款前不予批準 else （欠款未超期） 發(fā)批準書，發(fā)貨單 else （發(fā)貨單金額未超過$500） if 欠款超過60天 then 發(fā)批準書，發(fā)貨單及賒

21、欠報告 else （欠款未超期） 發(fā)批準書，發(fā)貨單 5、判定表（大題）：如果數(shù)據(jù)流圖的加工需要依賴于多個邏輯條件的取值，使用判定表來描述比較合適。 例子：以“檢查發(fā)貨單”為例 二、軟件設計方法1、 軟件設計的目標和方法根據(jù)用信息域表示的軟件需求，以及功能和性能需求，進行數(shù)據(jù)設計、系統(tǒng)結(jié)構(gòu)設計、過程設計。軟件設計任務：從工程管理角度來看，軟件設計分兩步完成l 概要設計，將軟件需求轉(zhuǎn)化為數(shù)據(jù)結(jié)構(gòu)和軟件的系統(tǒng)結(jié)構(gòu)。l 詳細設計，即過程設計。通過對結(jié)構(gòu)表示進行細化，得到軟件的詳細的數(shù)據(jù)結(jié)構(gòu)和算法2、 軟件設計過程制定規(guī)范 軟件系統(tǒng)結(jié)構(gòu)的總體設計 處理方式設計 數(shù)據(jù)結(jié)構(gòu)設計 可靠性設計 編寫概要設計階段

22、的文檔 概要設計評審3、 信息隱藏：是指每個模塊的實現(xiàn)細節(jié)對于其它模塊來說是隱蔽的。也就是說，模塊中所包含的信息（包括數(shù)據(jù)和過程）不允許其它不需要這些信息的模塊使用。4、 模塊獨立性：是指軟件系統(tǒng)中每個模塊只涉及軟件要求的具體的子功能, 而和軟件系統(tǒng)中其它的模塊的接口是簡單的 例如, 若一個模塊只具有單一的功能且與其它模塊沒有太多的聯(lián)系, 則稱此模塊具有模塊獨立性一般采用兩個準則度量模塊獨立性。即模塊間耦合和模塊內(nèi)聚耦合是模塊之間的互相連接的緊密程度的度量。 內(nèi)聚是模塊功能強度(一個模塊內(nèi)部各個元素彼此結(jié)合的緊密程度)的度量。 模塊獨立性比較強的模塊應是高內(nèi)聚低耦合的模塊。5、 變換型系統(tǒng)結(jié)構(gòu)

23、：變換型數(shù)據(jù)處理問題的工作過程大致分為三步，即取得數(shù)據(jù)，變換數(shù)據(jù)和給出數(shù)據(jù)。相應于取得數(shù)據(jù)、變換數(shù)據(jù)、給出數(shù)據(jù)，變換型系統(tǒng)結(jié)構(gòu)圖由輸入、中心變換和輸出等三部分組成。6、 事務性系統(tǒng)結(jié)構(gòu)：它接受一項事務，根據(jù)事務處理的特點和性質(zhì)，選擇分派一個適當?shù)奶幚韱卧缓蠼o出結(jié)果。在事務型系統(tǒng)結(jié)構(gòu)圖中，事務中心模塊按所接受的事務的類型，選擇某一事務處理模塊執(zhí)行。各事務處理模塊并列。每個事務處理模塊可能要調(diào)用若干個操作模塊，而操作模塊又可能調(diào)用若干個細節(jié)模塊。7、 變換分析方法由以下四步組成：l 重畫數(shù)據(jù)流圖；l 區(qū)分有效(邏輯)輸入、有效(邏輯)輸出和中心變換部分；l 進行一級分解，設計上層模塊；l 進行

24、二級分解，設計輸入、輸出和中心變換部分的中、下層模塊。8、 文件設計文件設計過程主要分為兩個階段。第一個階段是文件的邏輯設計，主要在概要設計階段實施。一般要根據(jù)文件的特性，來確定文件的組織方式。順序文件：連續(xù)文件、串聯(lián)文件。 直接存取文件：無關鍵字直接存取文件、帶關鍵字直接存取文件、桶式直接存取文件。索引順序文件：其基本數(shù)據(jù)記錄按順序文件組織，記錄排列順序必須按關鍵字值升序或降序安排，且具有索引部分，也按同一關鍵字進行索引。 分區(qū)文件：這類文件主要用于存放程序。它由若干稱為成員的順序組織的記錄組和索引組成。二、 程序編碼1、 結(jié)構(gòu)化程序設計結(jié)構(gòu)化程序設計主要包括兩方面：l 在編寫程序時，強調(diào)使

25、用幾種基本控制結(jié)構(gòu)，通過組合嵌套，形成程序的控制結(jié)構(gòu)。盡可能避免使用GOTO語句。l 在程序設計過程中，盡量采用自頂向下和逐步細化的原則，由粗到細，一步步展開。2、程序設計風格：程序?qū)嶋H上也是一種供人閱讀的文章，有一個文章的風格問題。應該使程序具有良好的風格。 源程序文檔化、 數(shù)據(jù)說明、 語句結(jié)構(gòu)、 輸入輸出方法3、程序復雜性度量程序復雜性主要指模塊內(nèi)程序的復雜性。它直接關聯(lián)到軟件開發(fā)費用的多少，開發(fā)周期的長短和軟件內(nèi)部潛伏錯誤的多少。減少程序復雜性，可提高軟件的簡單性和可理解性，并使軟件開發(fā)費用減少，開發(fā)周期縮短，軟件內(nèi)部潛藏錯誤減少。三、 軟件測試1、 軟件測試目的：基于不同的立場，存在著

26、兩種完全不同的測試目的：從用戶的角度出發(fā)，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可接受該產(chǎn)品。從軟件開發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗證該軟件已正確地實現(xiàn)了用戶的要求，確立人們對軟件質(zhì)量的信心。測試的目的是l 想以最少的時間和人力，系統(tǒng)地找出軟件中潛在的各種錯誤和缺陷。如果我們成功地實施了測試，我們就能夠發(fā)現(xiàn)軟件中的錯誤。l 測試的附帶收獲是，它能夠證明軟件的功能和性能與需求說明相符合。l 實施測試收集到的測試結(jié)果數(shù)據(jù)為可靠性分析提供了依據(jù)。l 測試不能表明軟件中不存在錯誤，它只能說明軟件中存在錯誤2、 測試與軟件工程各階段的關系n 軟件開發(fā)

27、過程是一個自頂向下，逐步細化的過程n 軟件計劃階段定義軟件作用域n 軟件需求分析建立軟件信息域、功能和性能需求、約束等n 軟件設計n 把設計用某種程序設計語言轉(zhuǎn)換成程序代碼3、 黑盒測試這種方法是把測試對象看作個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。黑盒測試又叫做功能測試或數(shù)據(jù)驅(qū)動測試。n 黑盒測試方法是在程序接口上進行測試，主要是為了發(fā)現(xiàn)以下錯誤:u 是否有不正確或遺漏了的功能?u 在接口上，輸入能否正確地接受? 能否輸出正確的結(jié)果?u 是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息(例如數(shù)據(jù)文件)訪問錯誤?u 性能上是否能夠滿

28、足要求?u 是否有初始化或終止性錯誤?n 用黑盒測試發(fā)現(xiàn)程序中的錯誤，必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù)，來檢查程序是否都能產(chǎn)生正確的輸出。4、 白盒測試：此方法把測試對象看做一個透明的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序的狀態(tài)，確定實際的狀態(tài)是否與預期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。軟件人員使用白盒測試方法，主要想對程序模塊進行如下的檢查：u 對程序模塊的所有獨立的執(zhí)行路徑至少測試一次；u 對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次；u 在循環(huán)的邊界和運

29、行界限內(nèi)執(zhí)行循環(huán)體；u 測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等。5、 邏輯覆蓋：邏輯覆蓋是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎的設計測試用例的技術。它屬白盒測試。語句覆蓋、 判定覆蓋、條件覆蓋判定條件覆蓋、 條件組合覆蓋、 路徑覆蓋。L1 ( a à c à e )= (A>1) and (B=0) and (A=2) or (X/A>1)= (A>1) and (B=0) and (A=2) or (A>1) and (B=0) and (X/A>1)= (A=2) and (B=0) or (A>1) and (B=0) and (X/A>1) L2 ( aà b à d )= not(A&