【正文】 后果。8．瀑布模型本質(zhì)上是一種線性順序模型，增量模型本質(zhì)上是一種快速原型模型。10． 軟件生存周期模型包括瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型等。12． “軟件危機(jī)”是指軟件開發(fā)和維護(hù)中出現(xiàn)的一系列問題，成本高、生產(chǎn)率低、質(zhì)量得不到保證、需求不能充分理解都是是軟件危機(jī)的表現(xiàn)形式。14． 軟件工程中的各種方法是完成軟件工程項(xiàng)目的技術(shù)手段,． 研究開發(fā)所需要的成本和資源是屬于可行性研究中的經(jīng)濟(jì)可行性研究的一方面。17． 軟件工程由方法,工具和過程三部分組成,． 基于計(jì)算機(jī)系統(tǒng)的軟件要素中的軟部件由程序,． 瀑布模型是以文檔為驅(qū)動(dòng)、適合于軟件需求明確的軟件項(xiàng)目的模型。21． 從事物的組成部件及每個(gè)部件的屬性,。23． 面向?qū)ο?Object Oriented)方法是將現(xiàn)實(shí)世界的事物以對象的方式映射到計(jì)算機(jī)世界的方法。25． 為了充分發(fā)揮開發(fā)人員的潛力,縮短工期,軟件工程項(xiàng)目的任務(wù)分解與安排應(yīng)盡力挖掘可并行開發(fā)的部分。27． 任務(wù)是一項(xiàng)已經(jīng)定義得很好的工作，該工作可分配給一個(gè)項(xiàng)目參與者或分配給一個(gè)團(tuán)隊(duì)。30． 用戶對軟件需求的描述不精確,往往是產(chǎn)生軟件危機(jī)的原因之一。32． 需求規(guī)格說明書是需求分析階段最重要的技術(shù)文檔之一33． 需求分析最終結(jié)果是產(chǎn)生需求規(guī)格說明書 34． DFD中的每個(gè)加工至少需要一個(gè)輸入流和一個(gè)輸出流。37． 需求規(guī)格說明書的作用包括：作為軟件驗(yàn)收的依據(jù)、用戶與開發(fā)人員對軟件要做什么的共同理解、作為軟件設(shè)計(jì)的依據(jù)等38． 在結(jié)構(gòu)化分析方法中，用以表達(dá)系統(tǒng)內(nèi)數(shù)據(jù)的運(yùn)動(dòng)情況的工具有數(shù)據(jù)流圖。41． 在面向?qū)ο筌浖_發(fā)方法中，類與類之間主要有繼 承和聚集的關(guān)系。43． 軟件開發(fā)過程中，抽取和整理用戶需求并建立問題域精確模型的過程叫面向?qū)ο蟮姆治觥?5． 軟件模塊之間的耦合性越弱越好。47． 內(nèi)聚度標(biāo)志一個(gè)模塊內(nèi)部各成分彼此結(jié)合的緊密程度,按其高低程度可分為七級,內(nèi)聚度越高越好。模塊耦合越弱，則說明模塊的獨(dú)立性強(qiáng)。50． 為了提高模塊的獨(dú)立性,模塊內(nèi)部最好是功能內(nèi)聚，模塊的內(nèi)聚性最高的是功能內(nèi)聚。52． 當(dāng)一個(gè)模塊直接使用另一個(gè)模塊的內(nèi)部數(shù)據(jù)，這種模塊之間的耦合為內(nèi)容耦合。54． 變換型數(shù)據(jù)處理問題的工作過程大致分為三步，即取得數(shù)據(jù)，變換數(shù)據(jù)和給出數(shù)據(jù)。56． 衡量模塊的獨(dú)立性的兩個(gè)定性的度量標(biāo)準(zhǔn)是內(nèi)聚度和耦合度。58． 過程描述語言可以用于算法和數(shù)據(jù)結(jié)構(gòu)的描述。60． 在詳細(xì)設(shè)計(jì)階段,經(jīng)常采用的工具有盒圖、PAD圖、PDL語言、判定表和判定樹等工具，． 盒圖也稱為NS圖，種表達(dá)方式取消了流程線,． 當(dāng)模塊中包含復(fù)雜的條件組合,． 模塊的內(nèi)部過程描述就是模塊內(nèi)部的算法設(shè)計(jì)，它的表達(dá)形式就是詳細(xì)設(shè)計(jì)語言．64． 程序的三種基本控制結(jié)構(gòu)的共同特點(diǎn)是只有一個(gè)入口和一個(gè)出口。66． 匯編語言是面向機(jī)器的，可以完成高級語言無法完成的特殊功能，如與外部設(shè)備之間的一些接口工作。68． 面向?qū)ο蟮拈_發(fā)方法中,UML是面向?qū)ο蠹夹g(shù)領(lǐng)域內(nèi)占主導(dǎo)地位的標(biāo)準(zhǔn)建模語言。70． 是對軟件規(guī)格說明,軟件設(shè)計(jì)和編碼的最全面也是最后的審查。72． 動(dòng)態(tài)測試方法中根據(jù)測試用例的設(shè)計(jì)方法不同，． 黑盒測試無需考慮模塊內(nèi)部的執(zhí)行過程和程序結(jié)構(gòu)，只要了解模塊的功能即可。75． 在現(xiàn)實(shí)項(xiàng)目中，路徑測試和窮舉測試是經(jīng)常難以實(shí)現(xiàn)。77． 計(jì)算機(jī)輔助靜態(tài)分析是軟件測試方法中的靜態(tài)測試方法之一。79． 等價(jià)類劃分、邊界值分析測試等屬于黑盒測試技術(shù)。81． 將軟件組裝成系統(tǒng)的一種測試技術(shù)叫集成測試。83． 在設(shè)計(jì)測試用例時(shí)，邊界值分析是用的最多的一種黑盒測試方法。85． 質(zhì)量保證是為了保證產(chǎn)品和服務(wù)充分滿足消費(fèi)者要求的質(zhì)量而進(jìn)行的有計(jì)劃．有組織的活動(dòng)，質(zhì)量保證是為了使用產(chǎn)品實(shí)現(xiàn)用戶要求的功能。88． 為了提高測試的效率，應(yīng)該選擇發(fā)現(xiàn)錯(cuò)誤可能性大的數(shù)據(jù)作為測試數(shù)據(jù)。90． 黑盒測試在設(shè)計(jì)測試用例時(shí)，主要需要研究需求規(guī)格說明與概要設(shè)計(jì)說明。92． 軟件維護(hù)是軟件生命周期的最后一個(gè)階段，軟件生 命周期中所花費(fèi)用最多的階段是軟件維護(hù)。94． 為改正軟件系統(tǒng)中潛藏的錯(cuò)誤而進(jìn)行的維護(hù)活動(dòng)稱為糾錯(cuò)性維護(hù)。96． 為適應(yīng)軟件運(yùn)行環(huán)境的變化而修改軟件的活動(dòng)稱為適應(yīng)性維護(hù)。98． 軟件中因修改軟件而造成的錯(cuò)誤稱為維護(hù)的副作用。100． 維護(hù)中,因誤刪除一個(gè)標(biāo)識符而引起的錯(cuò)誤是編碼副作用。102． 軟件可靠性是指在給定的時(shí)間間隔內(nèi),程序成功運(yùn) 行的概率。104． 軟件可修改性,是指允許對軟件系統(tǒng)進(jìn)行修改而不增加其復(fù)雜性，105． 所有軟件維護(hù)申請報(bào)告要按規(guī)定方式提出，該報(bào)告也稱軟件問題報(bào)告。2． 軟件生存周期模型：． 數(shù)據(jù)字典(DD)：,無二義性的說明方式為系統(tǒng)的分析,． 內(nèi)聚性：是模塊獨(dú)立性的衡量標(biāo)準(zhǔn)之一,它是模塊的功能強(qiáng)度的度量,． 白盒測試：又稱結(jié)構(gòu)測試，是已經(jīng)知道產(chǎn)品內(nèi)部工作過程，檢驗(yàn)產(chǎn)品內(nèi)部動(dòng)作是否按規(guī)定正常使用的測試方法。7． 模塊化：就是將程序劃分為若干個(gè)獨(dú)立模塊的這樣一個(gè)過程，其中每個(gè)模塊完成一個(gè)特定子功能，每個(gè)模塊既是相對獨(dú)立的，又是相互聯(lián)系的，它們共同完成系統(tǒng)指定的各項(xiàng)功能。9． 驅(qū)動(dòng)模塊：用于模擬被測模塊的上級模塊。10． 模塊：模塊是一個(gè)擁有明確定義的輸入、輸出和特性的程序?qū)嶓w。12． 軟件工程：即運(yùn)用工程學(xué)的基本原理和方法來組織和管理軟件生產(chǎn)。14． 模塊的作用范圍：一個(gè)模塊的作用范圍是指受該模塊內(nèi)一個(gè)判定影響的所有模塊的集合。16． 集成測試也稱組裝測試或聯(lián)合測試。組裝模塊的方式有兩種：漸增式測試和非漸增式測試。18． 對象：是現(xiàn)實(shí)世界中個(gè)體或事物的抽象表示，是其屬性和相關(guān)操作的封裝。20． 聚集：現(xiàn)實(shí)世界中部分整體關(guān)系的模擬。（二）原理螺旋模型的適應(yīng)場合:支持需求不明確,特別是大型軟件系統(tǒng)的開發(fā),并支持面向規(guī)格說明,面向過程,面向?qū)ο?等多種軟件開發(fā)方法,是一種具有廣闊前景的模型。需求分析的任務(wù)是確定待開發(fā)的軟件系統(tǒng)“做什么”.具體任務(wù)包括確定軟件系統(tǒng)的功能需求,性能需求和運(yùn)行環(huán)境約束,編制軟件需求規(guī)格說明書,軟件系統(tǒng)的驗(yàn)收測試準(zhǔn)則和初步的用戶手冊。原型法模型一般適應(yīng)的場合：它適合于那些不能預(yù)先確切定義需求的軟件系統(tǒng)的開發(fā),更適合于那些項(xiàng)目組成員(包括分析員,設(shè)計(jì)員,程序員和用戶)不能很好交流或通信有困難的情況。非漸增式測試與漸增式測試的區(qū)別：非漸增式測試：分別測試每個(gè)模塊，再放在一起結(jié)合成所要的程序；漸增式測試：將下一個(gè)要測試的模塊同已測試好的模塊放在一起測試，類推結(jié)合成所要的程序；優(yōu)缺點(diǎn)：l 漸增式測試可以較早發(fā)現(xiàn)模塊間的接口錯(cuò)誤 l 非漸增式測試最后才組裝，因此錯(cuò)誤發(fā)現(xiàn)得晚。l 漸增式測試在不斷集成的過程中使模塊不斷在新的條件下受到新的檢測，測試更徹底。l 非漸增式測試可以同時(shí)并行測試所有模塊，能充分利用人力。軟件工程的內(nèi)容是：1）采用工程化方法和途徑來開發(fā)與維護(hù)軟件；2）應(yīng)該開發(fā)和使用更好的軟件工具；3）采取必要的管理措施。1軟件的可行性研究的目的：就是用最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定該軟件項(xiàng)目是否能夠開發(fā)，是否值得去開發(fā)。1文檔在軟件工程中的作用：(1)提高軟件開發(fā)過程的能見度；(2)提高開發(fā)效率；(3)作為開發(fā)人員階段工作成果和結(jié)束標(biāo)志；(4)記錄開發(fā)過程的有關(guān)信息便于使用與維護(hù)；(5)提供軟件運(yùn)行、維護(hù)和培訓(xùn)有關(guān)資料；(6)便于用戶了解軟件功能、性能。在數(shù)據(jù)字典中，工卡的數(shù)據(jù)條目定義如下：工卡 = 工號 + 英文名 + 年齡 + 性別 + 部門 工號 = 001..200 英文名 = 3{字母}20 年齡 = 1..200 性別 = [男|女] 部門 = [技術(shù)部|市場部|財(cái)務(wù)部|行政部] 解析:先明確要說明數(shù)據(jù)條目是誰，由哪些分量組成,這些分量是“+”的關(guān)系，還是“或”的關(guān)系，如本例的第一條是“+”的關(guān)系,然后分析它的組成是什么，再對其各個(gè)組成部分依次說明,如本例的第二至六條，要一條一條地寫出來，不要都寫到一條中。掌握變換型和事務(wù)性數(shù)據(jù)流圖轉(zhuǎn)化為系統(tǒng)結(jié)構(gòu)圖的原理，能根據(jù)給定的數(shù)據(jù)流圖畫出系統(tǒng)結(jié)構(gòu)圖。軟件工程師指導(dǎo)軟件開發(fā)和維護(hù)的一門工程學(xué)科，采用工程的概念、原理、技術(shù)和方法來開發(fā)與維護(hù)軟件，把經(jīng)過時(shí)間考驗(yàn)而證明正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來，就是是軟件工程。軟件生存期可分為三個(gè)大階段：軟件開發(fā)、使用、維護(hù)。需求分析的步驟有：調(diào)查研究、分析與綜合、書寫文檔、需求分析評審。模塊之間聯(lián)系越緊密，其耦合性就越強(qiáng)，模塊的獨(dú)立性就越差。1數(shù)據(jù)流圖一般可分為交換型和事物型兩類。1軟件結(jié)構(gòu)從形態(tài)上總的考慮是：頂層扇出數(shù)較高一些，中間層扇出數(shù)較少一些，底層扇入數(shù)較少一些。1軟件的詳細(xì)設(shè)計(jì)可以用來采用圖形、表格、語言三種形式描述工具表示模塊的處理過程。1程序流程圖又稱程序框圖，他是軟件開發(fā)者最熟悉的一種算法表達(dá)工具。1類的實(shí)例化是定義類的對象。類具有操作，它是對象的行為的抽象。2在UML用例圖中，橢圓表示用例，方框表示系統(tǒng)，小人狀圖案表示執(zhí)行者2軟件測試過程按測試的先后次序可先分為四個(gè)步驟進(jìn)行：單元測試、集成測試、確定測試和系統(tǒng)測試，最后進(jìn)行驗(yàn)收測試?；谟?jì)算機(jī)的測試還有兩種方法，分別是黑盒測試和白盒測試。2所有軟件維護(hù)申請報(bào)告要按規(guī)定方式提出，該報(bào)告也稱軟件問題報(bào)告。軟件危機(jī)：指計(jì)算機(jī)軟件的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題瀑布模型：是將軟件生存各個(gè)活動(dòng)規(guī)定為依線性順序聯(lián)接的若干階段的模型。它規(guī)定了由前至后，相互銜接的固定次序，如同瀑布流水，逐級下落。需求分析：需求分析是指開發(fā)人員要準(zhǔn)確理解用戶的需求，進(jìn)行細(xì)致的調(diào)查分析，將用戶非形式的需求陳述轉(zhuǎn)化成完整的需求定義，再由需求定義轉(zhuǎn)換到相應(yīng)的形式功能規(guī)約（需求規(guī)格說明）的過程。面臨