軟件工程總結(jié).docVIP

1. 軟件指計(jì)算機(jī)系統(tǒng)中的程序及其文檔2. “五個面向”理論:面向流程分析、面向數(shù)據(jù)設(shè)計(jì)、面向?qū)ο髮?shí)現(xiàn)、面向功能測試、面向過程管理。3. 軟件發(fā)展階段:程序設(shè)計(jì)階段50至60年代、程序系統(tǒng)階段60至70年代、軟件工程階段70年代以后4. 軟件工程的概念：(1)把系統(tǒng)化的、規(guī)范化的、可度量的途徑應(yīng)用于軟件開發(fā)、運(yùn)行和維護(hù)的過程，也就是把工程化應(yīng)用于軟件中；（2）研究、建立并使用完善的工程化原則，以較經(jīng)濟(jì)的手段獲得能在實(shí)際機(jī)器上有效運(yùn)行的可靠軟件的一系列方法5. 軟件開發(fā)的工作量估算需要考慮哪些因素：軟件產(chǎn)品屬性、計(jì)算機(jī)屬性、人員屬性、項(xiàng)目屬性6. 需求文檔有哪些用途：作為系統(tǒng)設(shè)計(jì)的輸入、軟件維護(hù)的基礎(chǔ)、系統(tǒng)測試用例編寫的基礎(chǔ)7. 軟件有一個孕育、誕生、成長、成熟、衰亡的生存過程。這個過程即為計(jì)算機(jī)軟件的生命周期。8. 軟件生命周期的六個步驟，即制定計(jì)劃、需求分析、設(shè)計(jì)、程序編碼、測試及運(yùn)行維護(hù)。9. 瀑布模型的主要思想：軟件開發(fā)過程與軟件生命周期是一致的，相鄰二階段之間存在因果關(guān)系，需對階段性產(chǎn)品進(jìn)行評審；10. 瀑布模型的局限性：缺乏靈活性，如用戶需求一開始很難確定；到最后階段才能得到可運(yùn)行的軟件版本11. 增量模型將軟件的開發(fā)過程分成若干個日程時間交錯的線性序列，每個線性序列產(chǎn)生軟件的一個可發(fā)布的“增量”版本，后一個版本是對前一版本的修改和補(bǔ)充，重復(fù)增量發(fā)布的過程，直至產(chǎn)生最終的完善產(chǎn)品。12. 增量模型特點(diǎn)是強(qiáng)調(diào)每一個增量都發(fā)布一個可運(yùn)行的產(chǎn)品（第一個增量是核心產(chǎn)品）增量模型融合了瀑布模型的基本成分（重復(fù)地應(yīng)用）和演化模型的迭代特征。13. 增量模型特別適用于：需求經(jīng)常變化的軟件開發(fā)、市場急需而開發(fā)人員和資金不能在設(shè)定的市場期限之前實(shí)現(xiàn)一個完善的產(chǎn)品的軟件開發(fā)、增量模型能有計(jì)劃地管理技術(shù)風(fēng)險(xiǎn)，如早期增量版本中避免采用尚未成熟的技術(shù)。14. 原型模型：原型應(yīng)該包括目標(biāo)系統(tǒng)的關(guān)鍵問題和反映目標(biāo)系統(tǒng)的大致面貌，展示目標(biāo)系統(tǒng)的全部或部分功能、性能。原型模型兩個階段（1）原型開發(fā)階段（2）目標(biāo)軟件開發(fā)階段15. 原型的使用策略：廢棄（throw away）策略、追加（add on）策略16. 原型模型的優(yōu)點(diǎn)：有助于獲取用戶需求，加強(qiáng)對需求的理解、盡早發(fā)現(xiàn)軟件中的錯誤、支持需求的動態(tài)變化、適合于需求動態(tài)變化、事先難以確定的系統(tǒng)。不足之處：不能支持風(fēng)險(xiǎn)分析17. 螺旋模型：螺旋模型是瀑布模型、原型模型的有機(jī)結(jié)合，同時增加了風(fēng)險(xiǎn)分析。18. 螺旋模型沿著螺線旋轉(zhuǎn)，在四個象限上分別表達(dá)四個方面的活動：制定計(jì)劃、風(fēng)險(xiǎn)分析、實(shí)施工程、客戶評估19. 螺旋模型的優(yōu)點(diǎn)：有助于獲取用戶需求，加強(qiáng)對需求的理解，盡早發(fā)現(xiàn)軟件中的錯誤，支持需求的動態(tài)變化，支持風(fēng)險(xiǎn)分析，可降低或者消除軟件開發(fā)風(fēng)險(xiǎn)，適合于需求動態(tài)變化，事先難以確定并且開發(fā)風(fēng)險(xiǎn)較大的系統(tǒng)20. 噴泉模型是一種支持面向?qū)ο箝_發(fā)的模型，體現(xiàn)迭代和無間隙特征，該模型認(rèn)為軟件開發(fā)過程自下而上周期的各階段是相互重疊和多次反復(fù)的，就像水噴上去又可以落下來，類似一個噴泉。各個開發(fā)階段沒有特定的次序要求，并且可以交互進(jìn)行，可以在某個開發(fā)階段中隨時補(bǔ)充其他任何開發(fā)階段中的遺漏。21. 噴泉模型的優(yōu)點(diǎn)：該模型的各個階段沒有明顯的界限，開發(fā)人員可以同步進(jìn)行開發(fā)?？梢蕴岣哕浖?xiàng)目開發(fā)效率，節(jié)省開發(fā)時間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程。22. 缺點(diǎn)：由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項(xiàng)目的管理。此外這種模型要求嚴(yán)格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。23. 形式化方法模型：形式化方法是建立在嚴(yán)格數(shù)學(xué)基礎(chǔ)上的一種軟件開發(fā)方法。軟件開發(fā)的全過程中，從需求分析、規(guī)約、設(shè)計(jì)、編程、系統(tǒng)集成、測試、文檔生成，直至維護(hù)等各個階段，凡是采用嚴(yán)格的數(shù)學(xué)語言，具有精確的數(shù)學(xué)語義的方法，都稱為形式化方法。24. 基于計(jì)算機(jī)的系統(tǒng)是指：通過處理信息來完成某些預(yù)定義目標(biāo)而組織在一起的元素的組合25. 組成基于計(jì)算機(jī)系統(tǒng)的元素26. 可性行分析的任務(wù)：開發(fā)一個基于計(jì)算機(jī)的系統(tǒng)通常都受到資源（人力、財(cái)力、設(shè)備等）和時間上的限制，可行性分析主要從經(jīng)濟(jì)、技術(shù)、法律等方面分析所給出的解決方案是否可行，能否在規(guī)定的資源和時間的約束下完成。27. 軟件需求：用戶對目標(biāo)系統(tǒng)在功能、行為、性能等方面的要求28. 需求工程：運(yùn)用相關(guān)技術(shù)與方法進(jìn)行需求分析的過程。細(xì)分為：需求獲取、需求分析與協(xié)商、系統(tǒng)建模、需求規(guī)約、需求驗(yàn)證以及需求管理6個階段。29. 需求工程的任務(wù)：明確軟件到底“做什么”，以及應(yīng)具備的性能。30. 軟件需求規(guī)約：通過建立完整的信息描述、詳細(xì)的功能和行為描述、性能需求和設(shè)計(jì)約束的說明、合適的驗(yàn)收標(biāo)準(zhǔn)，給出對目標(biāo)軟件的各種需求31. 軟件設(shè)計(jì)的任務(wù)：使用一種設(shè)計(jì)方法，軟件分析模型中通過數(shù)據(jù)、功能和行為模型所展示的軟件需求的信息被傳送給設(shè)計(jì)階段，產(chǎn)生數(shù)據(jù)/類設(shè)計(jì)、體系結(jié)構(gòu)設(shè)計(jì)、接口設(shè)計(jì)、構(gòu)件級設(shè)計(jì)32. 軟件設(shè)計(jì)的兩個階段：概要設(shè)計(jì)（軟件體系結(jié)構(gòu)設(shè)計(jì)階段）和詳細(xì)設(shè)計(jì)（部件級設(shè)計(jì)階段）。33. 軟件設(shè)計(jì)的過程：制定規(guī)范、體系結(jié)構(gòu)和接口設(shè)計(jì)、數(shù)據(jù)/類設(shè)計(jì)、構(gòu)件級（過程）設(shè)計(jì)、編寫設(shè)計(jì)文檔、設(shè)計(jì)評審34. 常見的軟件體系結(jié)構(gòu):單主機(jī)結(jié)、C/S（Client/Server）結(jié)構(gòu)、B/S（Browser/Server）結(jié)構(gòu)35. 模塊化，即把軟件按照規(guī)定原則，劃分為一個個較小的，相互獨(dú)立的但又相互關(guān)聯(lián)的部件，實(shí)際上是系統(tǒng)分解和抽象的過程。模塊是數(shù)據(jù)說明、可執(zhí)行語句等程序?qū)ο蟮募?，它是單?dú)命名的，并且可以通過名字來訪問36. 模塊設(shè)計(jì)的原則：1.在選擇模塊設(shè)計(jì)的次序時，必須對一個模塊的全部直接下屬模塊都設(shè)計(jì)完成之后，才能轉(zhuǎn)向另一個模塊的下層模塊的設(shè)計(jì)；2.是按子系統(tǒng)求精。37. 模塊的作用域與控制域：1.模塊的控制范圍包括它本身及其所有的從屬模塊。2.模塊的作用范圍是指模塊內(nèi)一個判定的作用范圍，凡是受這個判定影響的所有模塊都屬于這個判定的作用范圍。3.如果一個判定的作用范圍包含在這個判定所在模塊的控制范圍之內(nèi)，則這種結(jié)構(gòu)是簡單的，否則，它的結(jié)構(gòu)是不簡單的。38. 信息隱藏：每個模塊的實(shí)現(xiàn)細(xì)節(jié)對于其它模塊來說應(yīng)該是隱蔽的，塊中所包含的信息(包括數(shù)據(jù)和過程)不允許其它不需要這些信息的模塊使用，通過信息隱藏，則可定義和實(shí)施對模塊的過程細(xì)節(jié)和局部數(shù)據(jù)結(jié)構(gòu)的存取限制39. 內(nèi)聚(cohesion)是一個模塊內(nèi)部各個元素彼此結(jié)合的緊密程度的度量；耦合(coupling)是模塊之間的相對獨(dú)立性(互相連接的緊密程度)的度量40. 構(gòu)件級設(shè)計(jì)技術(shù)的描述方法：程序流程圖、N-S圖、PAD 41. 結(jié)構(gòu)化分析模型：42. 系統(tǒng)響應(yīng)時間長會使用戶感到不安和沮喪。穩(wěn)定的響應(yīng)時間（如1秒）比不定的響應(yīng)時間（如0.1秒到2.5秒）要好。43. 界面設(shè)計(jì)的黃金原則：讓用戶擁有控制權(quán) 、減少用戶的記憶負(fù)擔(dān) 、保持界面一致44. 標(biāo)識符的命名規(guī)則：1.選擇含義明確的名字，使其能正確提示標(biāo)識符所代表的實(shí)體2.名字不要太長，太長會增加打字量，且易出錯。必要時可使用縮寫3.不用相似的名字，相似的名字容易混淆，不易發(fā)現(xiàn)錯誤4.不用關(guān)鍵字作標(biāo)識符5.同一個名字不要有多個含義6.名字中避免使用易混淆的字符。45. 程序的注釋分為序言性注解和功能性注解序言性注釋：通常置于每個程序模塊的開頭部分，主要描述：模塊的功能；模塊的接口：包括調(diào)用格式、參數(shù)的解釋、該模塊需要調(diào)用的其它子模塊名；重要的局部變量：包括用途、約束和限制條件；開發(fā)歷史：包括模塊的設(shè)計(jì)者、評審者、評審日期、修改日期以及對修改的描述功能性注釋：通常嵌在源程序體內(nèi)，主要描述程序段的功能。書寫功能性注解時應(yīng)注意的問題：注解要正確，錯誤的注解比沒有注解更壞；為程序段作注解，而不是為每一個語句作注解；用縮進(jìn)和空行，使程序與注釋容易區(qū)分；注解應(yīng)提供一些從程序本身難以得到的信息，而不是語句的重復(fù)。46. 代碼的視覺組織：通過在程序中添加一些空格、空行和縮進(jìn)等技巧，幫助人們從視覺上看清程序的結(jié)構(gòu)47. 數(shù)據(jù)說明的規(guī)范：數(shù)據(jù)說明的次序應(yīng)當(dāng)規(guī)范化、說明語句中變量安排有序化、使用注解說明復(fù)雜數(shù)據(jù)結(jié)構(gòu)48. 語句構(gòu)造的規(guī)則：1. 在一行內(nèi)只寫一條語句2. 程序編寫首先應(yīng)當(dāng)考慮清晰性3.程序要能直截了當(dāng)?shù)卣f明程序員的用意。4.讓編譯程序做簡單的優(yōu)化5.盡可能使用庫函數(shù)6.避免不必要的轉(zhuǎn)移。6.盡量只采用三種基本的控制結(jié)構(gòu)來編寫程序。49. 測試是一個為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程，以下為軟件測試的四個階段：50. 各種邏輯覆蓋之間的關(guān)系：判定覆蓋包含語句覆蓋，判定條件覆蓋包含判定、條件、語句覆蓋，條件組合包含全部，路徑覆蓋包含判定，跟其他的沒什么關(guān)系。51. 相關(guān)測試的對象：系統(tǒng)工程需求分析設(shè)計(jì)編碼系統(tǒng)測試確認(rèn)測試集成測試單元測試52. 單元測試的任務(wù)：1.模塊接口：確保模塊的輸入/輸出參數(shù)信息是正確的。2.局部數(shù)據(jù)結(jié)構(gòu)：確保臨時存儲的數(shù)據(jù)在算法執(zhí)行的整個過程中都能維持其完整性。3.邊界條件：確保程序單元在極限或嚴(yán)格的情況下仍能正確地執(zhí)行。4.所有獨(dú)立路徑：確保模塊中的所有語句都至少執(zhí)行一次。5.所有錯誤處理路徑：單元測試應(yīng)該對所有的錯誤處理路徑進(jìn)行測試。53. 集成測試：非增量式集成、增量式集成（增量式集成又可分為自頂向下集成和自底向上集成。）54. 自底向上集成的優(yōu)點(diǎn)：不需要樁模塊，所以容易組織測試；將整個程序結(jié)構(gòu)分解成若干個簇，對同一層次的簇可并行進(jìn)行測試，可提高效率。自底向上集成的缺點(diǎn)：整體性的錯誤發(fā)現(xiàn)得較晚。55. 回歸測試：回歸測試就是對已經(jīng)進(jìn)行過的測試的子集的重新執(zhí)行，以確保對程序的改變和修改，沒有傳播非故意的副作用。56. 測試是由一個用戶在開發(fā)者的場所進(jìn)行的，軟件在開發(fā)者對用戶的“指導(dǎo)下”進(jìn)行測試。經(jīng)測試后的軟件稱為版軟件。57. 測試是由軟件的最終用戶在一個或多個用戶場所進(jìn)行的，與測試不同，開發(fā)者通常不在測試現(xiàn)場，因此，測試是軟件在一個開發(fā)者不能控制的環(huán)境中的“活的”應(yīng)用，用戶記錄所有在測試中遇到的（真正的或想象的）問題，并定期把這些問題報(bào)告給開發(fā)者，在接到測試的問題報(bào)告后，開發(fā)者對軟件進(jìn)行最后的修改，然后著手準(zhǔn)備向所有的用戶發(fā)布最終的軟件產(chǎn)品。58. 測試完成的標(biāo)準(zhǔn)：如果一個在按照概率的方法定義的環(huán)境中，1000個CPU小時內(nèi)不出錯運(yùn)行的概率大于0995的話，那么我們就有95%的信心說，我們已經(jīng)進(jìn)行了足夠的測試59. 軟件維護(hù)：是指軟件系統(tǒng)交付使用以后，為了改正錯誤或滿足新的需要而修改軟件的過程 60. 四種軟件維護(hù)：糾錯性維護(hù)：為了改正軟件系統(tǒng)中的錯誤，使軟件能夠滿足預(yù)期的正常運(yùn)行狀態(tài)的要求而進(jìn)行的維護(hù)；適應(yīng)性維護(hù)：為了使軟件適應(yīng)內(nèi)部或外部環(huán)境變化，而去修改軟件的過程；改善性維護(hù)：滿足使用過程中用戶提出增加新功能或修改已有功能的建議維護(hù)；預(yù)防性維護(hù)：為了提高軟件的可維護(hù)性、可靠性等，為以后進(jìn)一步改進(jìn)軟件打下良好基礎(chǔ)而修改軟件的活動（改善性維護(hù)所占比例最大）61.62. 提高可維護(hù)性的方法:確定質(zhì)量管理目標(biāo)和優(yōu)先級、規(guī)范化程序設(shè)計(jì)風(fēng)格、選擇可維護(hù)性高的程序設(shè)計(jì)語言、改進(jìn)程序文檔、保證軟件質(zhì)量審查方法63. 軟件質(zhì)量：與軟件產(chǎn)品滿足明確或隱含需求的能力有關(guān)的特征和特性的總和64. 軟件可靠性是指在規(guī)定的條件下和規(guī)定的時間內(nèi)軟件按規(guī)格說明要求不引起系統(tǒng)失效的概率65. 可靠性的度量：MTTF (Mean Time to Failure)平均失效等待時間，理解為平均無故障時間，系統(tǒng)平均能夠正常運(yùn)行多久才發(fā)生一次故障；MTBF (Mean Time Between Failures) 平均失效間隔時間，是指兩次相繼失效之間的平均時間。MTBFMTTFMTTR其中：MTBF(meantimebetweenfailer)是平均故障間隔時間，MTTF(meantimetofailer)是平均故障時間，MTTR(meantimetorepair)是平均修復(fù)時間66. 軟件配置項(xiàng)(Software Configuration item，SCI)：為配置管理設(shè)計(jì)的軟件的集合，它在配置管理過程中作為單個實(shí)體對待67. 軟件配置(Soft