【正文】 適合大人小孩老人各類人們都可以很方便操作使用。用Jackson圖描繪一列火車的構(gòu)成的方法至少有兩種，一種方法是把火車分為一個(gè)車頭和兩個(gè)車頭兩類，另一種方法是把后車頭作為可選的。車廂分為硬座車廂、硬臥車廂和軟臥車廂等3種。本系統(tǒng)包含的數(shù)據(jù)存儲(chǔ)是：修改信息，主文件和修改后的主文件。注意，問題陳述中所描述的“系統(tǒng)安裝記錄號(hào)把修改信息順序排列好”，是具體的實(shí)現(xiàn)方法。最后，系統(tǒng)輸出一份修改報(bào)告供文件管理員參閱。綜上所述，采用增量模型來完成這個(gè)項(xiàng)目比較恰當(dāng)。你打算采用哪種軟件生命周期模型？為什么？。答：對(duì)這個(gè)軟件的需求很明確，實(shí)現(xiàn)開平方功能的算法也很成熟，因此，既無須通過原型來分析需求也無須用原型來驗(yàn)證設(shè)計(jì)方案。第一篇：軟件工程期末復(fù)習(xí)題軟件定義：問題定義、可行性研究，需求分析軟件開發(fā)：總體設(shè)計(jì)，詳細(xì)設(shè)計(jì)，編碼和單元測試，綜合測試軟件維護(hù)：改正性維護(hù)、適應(yīng)性維護(hù)、完善性維護(hù)、預(yù)防性維護(hù)軟件過程：瀑布模型，快速原型模型，增量模型，螺旋模型，噴泉模型，Rational統(tǒng)一過程，敏捷過程與極限編程，微軟過程從3個(gè)方面研究每種解決的可行性：技術(shù)可行性、經(jīng)濟(jì)可行性、操作可行性軟件需求分析階段的工作：可以分為以下4個(gè)方面：對(duì)問題的識(shí)別、分析與綜合、編寫需求分析文檔以及需求分析評(píng)審設(shè)計(jì)原理：模塊化、抽象、逐步求精、信息隱藏和局部化、模塊獨(dú)立性（耦合、內(nèi)聚）決定軟件可維護(hù)性的因素：可理解性、可測試性、可修改性、可移植性、可重用性一、假設(shè)要求你開發(fā)一個(gè)軟件，該軟件的功能是把讀入的浮點(diǎn)數(shù)開平方，所得到的結(jié)果應(yīng)該精確到小數(shù)點(diǎn)后4位。此外，一旦實(shí)現(xiàn)并測試完之后，該產(chǎn)品將被拋棄，因此也無須使用有助于提高軟件可維護(hù)性的增量模型或螺旋模型來開發(fā)該軟件。答：對(duì)這個(gè)項(xiàng)目的一個(gè)重要要求是，嚴(yán)格按照已對(duì)外公布了的日期完成產(chǎn)品開發(fā)工作，因此，選擇生命周期模型時(shí)應(yīng)該著重考慮哪些模型有助于加快產(chǎn)品開發(fā)的進(jìn)度。三、考慮一個(gè)修改磁帶上主文件的系統(tǒng)。請(qǐng)分層次地畫出上述主文件修改系統(tǒng)的數(shù)據(jù)流圖。在數(shù)據(jù)流圖中無須描述具體實(shí)現(xiàn)方法，因此，在本系統(tǒng)的數(shù)據(jù)流圖中不需要包含“排序”功能。四、用Jackson圖描繪下述的一列火車的構(gòu)成：一列火車最多有兩個(gè)火車頭。硬座車廂在車內(nèi)所有車廂的前面部分，軟臥車廂在所有車廂的后面部分。解法1（b）解法2五、為方便出乎，某銀行擬開發(fā)計(jì)算機(jī)儲(chǔ)蓄系統(tǒng)，儲(chǔ)戶填寫的存款單或取款單由業(yè)務(wù)員輸入系統(tǒng)，如果是存款，系統(tǒng)記錄存款人姓名、住址、存款類型、存款日期、利率等信息，并印出存款單給儲(chǔ)戶，如果是取款，系統(tǒng)計(jì)算利息并印出利息清單給儲(chǔ)戶。還有，要有經(jīng)過培訓(xùn)的專業(yè)人員在指導(dǎo)，以便當(dāng)儲(chǔ)戶有什么疑難問題時(shí)能及時(shí)得到正確的答復(fù) 社會(huì)、政策允許的可行性：全部軟件購買正版，機(jī)器設(shè)置通過正當(dāng)途徑購得六、確定每個(gè)模塊的內(nèi)聚類型。重復(fù)調(diào)用“讀取地點(diǎn)、時(shí)間和溫度”、“創(chuàng)建新的溫度記錄”、“計(jì)算特定地點(diǎn)的日平均溫度”和“存儲(chǔ)溫度記錄”等模塊，直至計(jì)算出并保存好所有指定地點(diǎn)的日平均溫度。但是，初始化變量sum是本程序特有的操作，而打開文件是硬件要求的操作，是任何使用文件的程序都包含的一個(gè)操作，并非本程序特有的操作。，確定模塊之間的耦合類型。當(dāng)模塊q把控制返還給模塊p時(shí)，它傳回一個(gè)狀態(tài)標(biāo)志。另一個(gè)控制耦合的例子是把控制開關(guān)作為一個(gè)參數(shù)傳遞。模塊q和s之間（接口4）的耦合情況與此類似。，正確的是(D)。，產(chǎn)生困難的根本原因是(大型系統(tǒng)的復(fù)雜性)。、設(shè)計(jì)、實(shí)現(xiàn)、測試、交付使用以及維護(hù)等活動(dòng)。（軟件工程管理）、信息隱藏、模塊化、局部化、確定性、一致性、完備性和可驗(yàn)證性。增量型則先建立一個(gè)不完全的系統(tǒng)，通過對(duì)需求的理解再進(jìn)一步擴(kuò)充和完善。需求分析將創(chuàng)建所需的數(shù)據(jù)模型、功能模型和 控制模型：需求獲取、需求分析、編寫需求規(guī)格說明書、需求評(píng)審下列工具中屬于需求分析常用工具的是(D)。下列圖符名標(biāo)識(shí)的圖符不屬于數(shù)據(jù)流圖合法圖符的是(A)。三、結(jié)構(gòu)化設(shè)計(jì)方法軟件設(shè)計(jì)的基本概念，下面任務(wù)不屬于設(shè)計(jì)階段的是(D)A)數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì) B)給出系統(tǒng)模塊結(jié)構(gòu) C)定義模塊算法 D)定義需求并建立系統(tǒng)模型、數(shù)據(jù)、接口和過程設(shè)計(jì)，其中軟件的過程設(shè)計(jì)是指(系統(tǒng)結(jié)構(gòu)部件轉(zhuǎn)換成軟件的過程描述)。一個(gè)模塊與其它模塊的耦合性越強(qiáng)，則它的模塊獨(dú)立性越 弱。，軟件功能分解屬于下列軟件開發(fā)中的階段是(C) ，常用的軟件結(jié)構(gòu)設(shè)計(jì)工具是 結(jié)構(gòu)圖(sc)，也稱程序結(jié)構(gòu)圖。將變換型映射成結(jié)構(gòu)圖稱為 變換分析。理想的情況是(模塊的作用范圍應(yīng)在控制范圍內(nèi))詳細(xì)設(shè)計(jì) 的任務(wù)是為軟件結(jié)構(gòu)圖中的每一個(gè)模塊確定實(shí)現(xiàn)算法和局部數(shù)據(jù)結(jié)構(gòu)，用選定的表達(dá)工具表示算法和數(shù)據(jù)結(jié)構(gòu)的細(xì)節(jié)。 降低復(fù)雜性。靜態(tài)測試包括 代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量量度 等白盒測試和黑盒測試都屬于 動(dòng)態(tài)測試白盒測試的主要方法： 邏輯覆蓋、基本路徑測試 等 黑盒測試的主要方法： 等價(jià)類劃分法、邊界值分析法、錯(cuò)誤推測法、因果圖 等(B)。常用的黑箱測試有等價(jià)分類法、邊界值分析法、因果圖法和錯(cuò)誤推測法4種。集成測試：測試和組裝模塊的過程，主要是發(fā)現(xiàn)與接口有關(guān)的錯(cuò)誤，依據(jù)是概要設(shè)計(jì)說明書。系統(tǒng)測試：將軟件與硬件、用戶、數(shù)據(jù)等組合，在實(shí)際運(yùn)行環(huán)境下對(duì)整個(gè)系統(tǒng)進(jìn)行集成測試和確認(rèn)測試。四、程序的調(diào)試軟件調(diào)試(Debug，即排錯(cuò))的任務(wù)是診斷和改正程序中的錯(cuò)誤，與軟件測試不同，軟件測試是盡可能多地發(fā)現(xiàn)軟件中的錯(cuò)誤。六、軟件維護(hù)：校正性維護(hù)、適應(yīng)性維護(hù)、完善性維護(hù)和預(yù)防性維護(hù)。程序是能夠完成預(yù)定功能和性能的可執(zhí)行的指令序列；數(shù)據(jù)是使程序能夠適當(dāng)?shù)靥幚硇畔⒌臄?shù)據(jù)結(jié)構(gòu)；文檔是開發(fā)、使用和維護(hù)程序所需要的圖文資料。（理解，判斷）：軟件工程關(guān)注與大型程序的構(gòu)造，軟件工程的中心課題是控制復(fù)雜性，軟件經(jīng)常變化，開發(fā)軟件的效率非常重要，和諧地合作是開發(fā)軟件的關(guān)鍵，軟件必須有效地支持它的用戶，在軟件工程領(lǐng)域中通常由具有一種文化背景的人替具有另一種文化背景的人創(chuàng)造產(chǎn)品。這個(gè)時(shí)期的工作通常又稱為系統(tǒng)分析，有系統(tǒng)分析員負(fù)責(zé)完成。其中前兩個(gè)階段又稱為系統(tǒng)設(shè)計(jì)，后兩個(gè)階段又稱為系統(tǒng)實(shí)現(xiàn)。：問題定義、可行性研究、需求分析、總體設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼和單元測試、綜合測試。5．成本估計(jì)技術(shù)有：代碼行技術(shù)、任務(wù)分解技術(shù)、自動(dòng)估計(jì)成本技術(shù)。:在軟件開發(fā)和維護(hù)的過程中存在這么多嚴(yán)重問題，一方面與軟件本身的特點(diǎn)有關(guān)，另一方面也和軟件開發(fā)與維護(hù)的方法不正確有關(guān)。總之，為了解決軟件危機(jī)，既要有技術(shù)措施（方法和工具），又要有必要的組織管理措施。:用分階段的生命周期計(jì)劃嚴(yán)格管理堅(jiān)持進(jìn)行階段評(píng)審實(shí)行嚴(yán)格的產(chǎn)品控制采用現(xiàn)代程序設(shè)計(jì)技術(shù)結(jié)果應(yīng)能清楚地審查開發(fā)小組的人員應(yīng)該少而精承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性 軟件工程方法學(xué):通常把在軟件生命周期全過程中使用的一整套技術(shù)方法的集合稱為方法學(xué)，也稱為范型。軟件開發(fā)的四個(gè)階段：總、詳（系統(tǒng)設(shè)計(jì)）、編、綜（系統(tǒng)實(shí)現(xiàn)）軟件生命周期每個(gè)階段:軟件過程是為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。缺點(diǎn)：瀑布模型是由文檔驅(qū)動(dòng)的: 可行性研究的目的，就是用最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定問題是否能夠解決。然后從系統(tǒng)邏輯模型出發(fā)，探索若干種可供選擇的主要解法（即系統(tǒng)實(shí)現(xiàn)方案）。一般來說，可行性研究的成本只是預(yù)期的工程總成本的5%10%。在數(shù)據(jù)流圖中應(yīng)該描繪所有可能的數(shù)據(jù)流向，而不應(yīng)該描繪出現(xiàn)某個(gè)數(shù)據(jù)流的條件。數(shù)據(jù)流圖的4種成分：源點(diǎn)或終點(diǎn)，處理，數(shù)據(jù)存儲(chǔ)，數(shù)據(jù)流數(shù)據(jù)流圖的基本目的是利用它作為交流信息的工具，另一個(gè)主要用途是作為分析和設(shè)計(jì)的工具。開發(fā)具有獨(dú)立功能而且和其他模塊之間沒有過多的相互作用的模塊，就可以做到模塊獨(dú)立。如果只有兩個(gè)模塊有公共環(huán)境，那么這種耦合有下面兩種可能。如果兩個(gè)模塊共享的數(shù)據(jù)很多，都通過參數(shù)傳遞可能很不方便，這時(shí)可以利用公共環(huán)境耦合。一個(gè)模塊不通過正常入口而轉(zhuǎn)到另二個(gè)模塊的內(nèi)部。事實(shí)上許多高級(jí)程序設(shè)計(jì)語言已經(jīng)設(shè)計(jì)成不允許在程序中出現(xiàn)任何形式的內(nèi)容耦合。簡單地說，理想內(nèi)聚的模塊只做一件事情。功能內(nèi)聚是最高程度的內(nèi)聚。考慮程序代碼的質(zhì)量時(shí)必須注意，程序的“讀者”有兩個(gè)，那就是計(jì)算機(jī)和人。詳細(xì)設(shè)計(jì)的目標(biāo)不僅僅是邏輯上正確地實(shí)現(xiàn)每個(gè)模塊的功能，更重要的是設(shè)計(jì)出的處理過程應(yīng)該盡可能簡明易懂。在設(shè)計(jì)人機(jī)界面過程會(huì)遇到下面4個(gè)問題：系統(tǒng)響應(yīng)時(shí)間，用戶幫助設(shè)施，出錯(cuò)信息處理和命令交互。用戶界面評(píng)估周期如下，完成初步設(shè)計(jì)之后就創(chuàng)建第一級(jí)原型，用戶使用并評(píng)估該原型，直接向設(shè)計(jì)者表述對(duì)界面的評(píng)價(jià)，設(shè)計(jì)中根據(jù)用戶意見修改設(shè)計(jì)并實(shí)現(xiàn)下一級(jí)原型。正確認(rèn)識(shí)測試的目標(biāo)是十分重要的，測試目標(biāo)決定了測試方案的設(shè)計(jì)。此外，應(yīng)該認(rèn)識(shí)到測試決不能證明程序是正確的。怎樣才能達(dá)到軟件測試的目標(biāo)呢？為了能設(shè)計(jì)出有效的測試方案，軟件工程師必須深人理解并正確運(yùn)用指導(dǎo)軟件測試的基本準(zhǔn)則。“小規(guī)?！睖y試開始，并逐步進(jìn)行“大規(guī)模”測試。囚此，測試只能證明程序中有錯(cuò)誤，不能證明程序中沒有錯(cuò)誤。由于前面已經(jīng)講過的原因，開發(fā)軟件的軟件工程師并不是完成全部測試工作的最佳人選（通常他們主要承擔(dān)模塊測試工作）。也就是說，黑盒測