軟件工程知識點

第一章軟件危機的表現(xiàn)：(1)軟件開發(fā)進度和成本難以限制。(2)軟件產(chǎn)品難以滿足用戶的需求。(3)軟件質(zhì)量難以得到保證。(4)軟件產(chǎn)品難以進行維護。(5)軟件的文檔資料難以管理。(6)軟件產(chǎn)品的生產(chǎn)率(1)對軟件開發(fā)缺乏正確的理論指導。(2)軟件開發(fā)人員及用戶缺乏充分的溝通。(3)對軟件開發(fā)過程缺乏整體相識。(4)對軟件產(chǎn)品缺軟件工程發(fā)展的四個階段：(1)傳統(tǒng)軟件工程階段：用工程化思想指段：這一階段的發(fā)展是以"對象"為基礎綻開的。(3)過程工程的軟簡答第一大題衡量軟件質(zhì)量的因素：(1):可理解性：它對軟件體軟件所實現(xiàn)的功能和達到的性能及滿足用戶實際需求的程度(3)平或硬件環(huán)境的簡潔程度。1,用分階段的生命周期支配嚴格管理。2,堅持進行階段評審。3,執(zhí)行嚴格的產(chǎn)品質(zhì)量限制4,接受現(xiàn)代程序設計技術5,結果應能清楚地審查。6,開發(fā)人員應少而精。7,承認不斷改進軟件工程的必要性軟件實現(xiàn)的是一個從現(xiàn)實問題域(輸入)到信息域的解(輸出)的過1,可行性及支配探討階段。2需求分析階段。3,設計階段。4,實(1)瀑布模型：1,特點：簡潔，嚴格(每一階段過程都始于前一原型模型不適宜開發(fā)大型軟件項目，是在需求不明確的狀況下開發(fā)(3)增量模型：1,特點：靈敏性(可以依據(jù)用戶需求有選擇地先起先進行系統(tǒng)中重要部分內(nèi)容的分析及設計),降低風險。2,適用足用戶需求為要旨),變更(靈敏過程模型要能反映這種變更，并將變更剛好反映在軟件的設計和實現(xiàn)中),有目的的建模(多及團隊人員溝通，及客戶溝通，保證建模的正確性和足夠詳細),快速到反饋，快速反饋是建立在團隊合作的基礎上)2,優(yōu)點：綜合瀑布型(建模),最終定義需求規(guī)格說明書，并經(jīng)技術審查和管理復審，操作可行性。(3)經(jīng)濟可行性：運用軟件成本估算技術(成本/效益分析等方法)推斷是否盈利。(4)法律可行性。文檔經(jīng)過評審以后),就確定了這組軟件配置項的基線。統(tǒng)將要開發(fā)的功能是什么?,When:什么時候開發(fā)?,Who:系統(tǒng)由的業(yè)務處于整個系統(tǒng)的什么位置?,How:完成系統(tǒng)的開發(fā)目標技術上接受何種方法?管理上如何進行?,Howmuch:開發(fā)系統(tǒng)須要那些資源?須要多少?)(2)調(diào)查問卷。(3)面對用例的場景分析：訪談對象(實體),對象屬性和對象間關系。一對多多對多)接口。(2)畫出頂層(0層)DFD圖。(3)第一次精化：劃分系統(tǒng)的于說明轉(zhuǎn)換到該狀態(tài)的特定動作。(2)exit事務：用于說明觸發(fā)該狀態(tài)的特定動作。(3)do事務：用于說明處于當前狀態(tài)時執(zhí)行的動1,數(shù)據(jù)統(tǒng)一存儲和管理，確保了數(shù)據(jù)的實時性2,數(shù)據(jù)倉庫對數(shù)據(jù)困難性的統(tǒng)一封裝有利于數(shù)據(jù)共享3,接受黑板模型，及某類數(shù)據(jù)有關的應用系統(tǒng)能剛好獲得數(shù)據(jù)4,接受數(shù)據(jù)訂閱推送模型，應高了數(shù)據(jù)管理效率5,各應用系統(tǒng)間僅通過數(shù)據(jù)倉庫完成數(shù)據(jù)交1,增加了數(shù)據(jù)倉庫設計的困難性，降低了數(shù)據(jù)傳遞的效率2,應的結構及數(shù)據(jù)倉庫在數(shù)據(jù)上的匹配3,數(shù)據(jù)共享帶來的訪問限制的題，影響了倉庫模型的有效利用。1,共享：實現(xiàn)了數(shù)據(jù)共享，云計算的提出還能進一步實現(xiàn)云計算共享2,異構型：客戶端/服務器允許軟件配置不同3,開放性：只要符合互聯(lián)網(wǎng)協(xié)議，任何計算機，局域網(wǎng)，智能設備和物品等都可連入互聯(lián)網(wǎng)。4,易修改性：由于用戶界面，系統(tǒng)邏輯和數(shù)據(jù)訪問分布的不同，各部分具有較強的獨立性，易于系統(tǒng)的修改和維護5,透亮性：分布式結構中僅須要知道服務器的服務位置，而對后端的邏輯實現(xiàn)，數(shù)據(jù)存儲，數(shù)據(jù)訪問等不必清楚其架構和訪問方式。簡答其次大題可能啟發(fā)式規(guī)則：1、改進軟件結構，提高模塊獨立性2,模塊規(guī)模適中3,軟件結構的寬度，深度，扇出度和扇出度都應適中4,模塊的作用域應在模塊限制域之內(nèi)5,設計單入口，單出口的模塊，并力爭降低模塊接口的困難度。可能其次大題簡答模塊的作用域是指模塊內(nèi)定義的全部元素(如數(shù)據(jù)，變量等)各自有效的運用范圍。模塊的限制域是指模塊所能操作和調(diào)用的全部元素(如其他模塊等)的集合。模塊的作用域應在模塊的限制域之內(nèi)TheoMandel提出的界面設計黃金三原則：1、置用戶及限制之下2,削減用戶的記憶負擔3,保持界面一樣。MVC軟件設計模型：模型—視圖一限制器。1、一個模型對應多個不同的視圖2,模型的自包含性3,限制層請求4,MVC分層模式使得只修改其中某層就能滿足用戶新的需求，使系統(tǒng)達到不同的效果，且更易于系統(tǒng)的更新升級5,MVC1,增加了系統(tǒng)的困難性2,導致修改的連鎖反應3,數(shù)據(jù)訪問第四章結構化設計方法*變換分析法還是事務分析法是以數(shù)據(jù)流圖為基礎，并依據(jù)數(shù)據(jù)*結構化設計的詳細設計階段，主要完成系統(tǒng)各模塊功能的過程測試的V模型測試W模型測試H模型主要特點3留意測試用例的設計和選擇4增量式測試5充分留意測試的群集現(xiàn)象軟件中的錯誤不是勻整分布在各部分中的，而是出現(xiàn)扎堆的現(xiàn)6合理支配測試支配，嚴格執(zhí)行測試支配7全面統(tǒng)計和分析檢測試結果8保存測試文檔，并剛好更新1語句覆蓋(最弱)2判定覆蓋3條件覆蓋4判定/條件覆蓋5條件組合覆蓋邊界值分析是對等價類劃分的有益補充。再劃分等價類的過程錯誤推想是依據(jù)測試人員的閱歷和直覺來推想程序中可能存在1模塊接口2局部數(shù)據(jù)結構3執(zhí)行路徑4邊界條件5異樣處理系統(tǒng)測試的范圍1功能測試2性能測試3壓力測試4容量測試5平安測試6文檔測試7復原性測試8備份測試UML的構成1視圖2圖3模型元素4通用機制UML的