【正文】 從系統(tǒng)應(yīng)該“定時(shí)記錄病人情況以形成患者日志”這項(xiàng)要求可以想到，還應(yīng)該有一個(gè)提供日期和時(shí)間信息的“時(shí)鐘”作為數(shù)據(jù)源點(diǎn)。這個(gè)模型適用于完成體系結(jié)構(gòu)設(shè)計(jì)之后的軟件開發(fā)階段。這3個(gè)層次的估算模型分別是： （1） 應(yīng)用系統(tǒng)組成模型：主要用于估算構(gòu)建原型的工作量，模型名字暗示在構(gòu)建原型時(shí)大量使用已有的構(gòu)件。演化提交是在瀑布模型的基礎(chǔ)上所有階段都使用增量開發(fā)也就是不緊使用增量開發(fā)也使用增量提交。增量模型是非整體開發(fā)的模型它采用漸增模型和原形模型，軟件的開發(fā)是用增量開發(fā)和增量提交。三種模型的關(guān)系：功能模型描述發(fā)生了什么，動(dòng)態(tài)模型確定什么時(shí)候發(fā)生，對(duì)象模型確定發(fā)生的客體。多態(tài)性：多態(tài)性是指子類對(duì)象可以像父類對(duì)象那樣使用，同樣的消息既可以發(fā)送給父類對(duì)象也可以發(fā)送給子類對(duì)象。在面向?qū)ο蟮某绦蛑?，把?shù)據(jù)和實(shí)現(xiàn)操作的代碼集中起來放在對(duì)象內(nèi)部。通常在這種描述中也包括對(duì)怎樣創(chuàng)建該類的新對(duì)象的說明。軟件的可維護(hù)性可以定義為:維護(hù)人員理解,改正和改動(dòng)軟件的難易程度。選擇一條主控制通路取決于應(yīng)用的特點(diǎn)，并且有很大任意性。1 測(cè)試階段的信息流：這個(gè)階段的輸入信息有兩類： (1)軟件配置，包括需求說明書、設(shè)計(jì)說明書和源程序清單等； (2)測(cè)試配置，包括測(cè)試計(jì)劃和測(cè)試方案。(3)定義初始模型：把實(shí)體和動(dòng)作表示成一個(gè)進(jìn)程模型，定義模型與現(xiàn)實(shí)世界的聯(lián)系。內(nèi)聚大使得模塊的可理解性和維護(hù)性大大增強(qiáng)。一個(gè)模塊內(nèi)部各個(gè)元素之間的聯(lián)系越緊密，則它的內(nèi)聚性就越高。耦合：是模塊之間的相對(duì)獨(dú)立性(互相連接的緊密程度)的度量。模塊是構(gòu)成程序的基本構(gòu)件。1 總體設(shè)計(jì)過程由兩個(gè)主要階段組成：①系統(tǒng)設(shè)計(jì)階段，確定系統(tǒng)的具體實(shí)現(xiàn)方案；②結(jié)構(gòu)設(shè)計(jì)階段，確定軟件結(jié)構(gòu)。③建立上標(biāo)系統(tǒng)的邏輯模型。主要工具：數(shù)據(jù)流圖、數(shù)據(jù)詞典、結(jié)構(gòu)化英語、判定表和判定樹。⑵通過結(jié)構(gòu)分析的方法對(duì)系統(tǒng)進(jìn)行分解,以確定軟件系統(tǒng)的主要成分或軟件系統(tǒng)的構(gòu)成。 什么是字據(jù)字典？其作用是什么？它有哪些條目？字據(jù)字典：簡稱ＤＤ，就是用來定義數(shù)據(jù)流圖中的各個(gè)成分具體含義的，它以一種準(zhǔn)確的、無二義性的說明方式為系統(tǒng)的分析、設(shè)計(jì)及維護(hù)提供了有關(guān)元素的一致的定義和詳細(xì)的描述。 (3)法律可行性?？尚行匝芯康娜蝿?wù)： (1)經(jīng)濟(jì)可行性。 數(shù)據(jù)流程圖：簡稱DFD,是描述數(shù)據(jù)處理過程的工具。②對(duì)可選方案和約束條件的強(qiáng)調(diào)有利于已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開發(fā)的一個(gè)重要目標(biāo)；減少了過多測(cè)試或測(cè)試不足所帶來的風(fēng)險(xiǎn)。②當(dāng)配備的人員不能在設(shè)定的期限內(nèi)完成產(chǎn)品時(shí)，它提供了一種先推出核心產(chǎn)品的途徑，這樣就可以先發(fā)布部分功能給客戶，對(duì)客戶起到鎮(zhèn)靜劑的作用。）主要模型：①瀑布模型；②增量模型；③螺旋模型；④噴泉模型；⑤變換模型；⑥基于知識(shí)的模型等瀑布模型：①它提供了一個(gè)摸板，這個(gè)摸板使分析、設(shè)計(jì)、編碼、測(cè)試和支持的方法可以在該摸板下有一個(gè)共同的指導(dǎo)；②雖然有不少缺陷但比在軟件開發(fā)中隨意的狀態(tài)要好得多。傳統(tǒng)方法：⑴結(jié)構(gòu)化開發(fā)方法，注重的是系統(tǒng)功能，自頂向下，從大到小的功能分解，從DFD到MSD，往往系統(tǒng)需求變化最大就是功能，一段較長的時(shí)間內(nèi)，商業(yè)的流程可能已經(jīng)發(fā)生了很大的變化，這樣基于功能和過程的方法顯然難以維護(hù)的，代碼重用率可想而知，而商業(yè)過程中的數(shù)據(jù)可能變化不會(huì)很大，⑵信息工程法，注重的是數(shù)據(jù)，事件流－＞信息流，（資金流，物流）－＞數(shù)據(jù)流，數(shù)據(jù)的輸入和轉(zhuǎn)化輸出，數(shù)據(jù)流程圖，狀態(tài)轉(zhuǎn)化圖，事件順序圖，過程依賴圖，兩者都是由事件驅(qū)動(dòng)．面向的是問題，是為了要解決某一個(gè)具體問題，其觀察事物的方法不是本體客體本身，而是對(duì)本體客體相互作用過程抽象，轉(zhuǎn)化成邏輯模型。簡單調(diào)試、演繹調(diào)試、遞歸調(diào)試、回溯調(diào)試。漸增式是逐個(gè)將未測(cè)試的模塊組裝到已經(jīng)測(cè)試過的模塊上去進(jìn)行集成測(cè)試，每加入一個(gè)就測(cè)試一次。而就有狀態(tài)的測(cè)試來說，就更麻煩了，尤其不是一個(gè)單獨(dú)的testcase造成的問題。從覆蓋源程序語句的詳盡程度分析，大致有以下一些不同的覆蓋標(biāo)準(zhǔn)：⑴語句覆蓋；⑵判定覆蓋；⑶條件覆蓋；⑷判定/條件覆蓋；⑸條件組合覆蓋；⑹點(diǎn)覆蓋；⑺邊覆蓋；⑻路徑覆蓋。在軟件開發(fā)完成并投入使用后，由于多方面的原因，軟件不能繼續(xù)適應(yīng)用戶的要求。整個(gè)測(cè)試過程分單元測(cè)試、組裝測(cè)試以及系統(tǒng)測(cè)試三個(gè)階段進(jìn)行。　　程序編碼　　此階段是將軟件設(shè)計(jì)的結(jié)果轉(zhuǎn)換成計(jì)算機(jī)可運(yùn)行的程序代碼。同樣需求也是在整個(gè)軟件開發(fā)過程中不斷變化和深入的，因此我們必須制定需求變更計(jì)劃來應(yīng)付這種變化，以保護(hù)整個(gè)項(xiàng)目的順利進(jìn)行。　問題的定義及規(guī)劃　　此階段是軟件開發(fā)方與需求方共同討論，主要確定軟件的開發(fā)目標(biāo)及其可行性。軟件工程方法學(xué)三要素是：①方法；②工具；③過程。面向?qū)ο蟮囊c(diǎn): ①把對(duì)象作為融合了數(shù)據(jù)及在數(shù)據(jù)上的操作行為的統(tǒng)一的軟件構(gòu)件。軟件工程的框架可概括為：①目標(biāo)、②過程和③原則。⑦開發(fā)的軟件可靠性高。③取得較好的軟件性能。軟件工程的內(nèi)容：１） 軟件開發(fā)技術(shù)：軟件開發(fā)方法、軟件開發(fā)過程、軟件開發(fā)工具和環(huán)境。(5) 軟件通常沒有適當(dāng)?shù)奈臋n資料。軟件危機(jī)典型表現(xiàn)：(1) 對(duì)軟件開發(fā)成本和進(jìn)度的估計(jì)常常很不準(zhǔn)確。④軟件開發(fā)技術(shù)落后。三、簡答題： 什么是軟件危機(jī)？產(chǎn)生軟件危機(jī)的原因？怎樣消除？答：軟件危機(jī)：是計(jì)算機(jī)軟件在它的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題，研制軟件系統(tǒng)需要投入大量的人力和物力，但系統(tǒng)的質(zhì)量卻難以保證，也就是說，開發(fā)軟件所需的高成本同產(chǎn)品的低質(zhì)量之間有著尖銳的矛盾，這種現(xiàn)象就是所謂的“軟件危機(jī)”。 ③軟件開發(fā)費(fèi)用不斷增加。包含兩方面的問題：⑴如何開發(fā)軟件，以滿足對(duì)軟件日益增長的需求；⑵如何維護(hù)數(shù)量不斷膨脹的已有軟件。(4) 軟件常常是不可維護(hù)的。 什么是軟件工程？包括哪些內(nèi)容？答: 軟件工程：用科學(xué)知識(shí)和技術(shù)原理來定義、開發(fā)、維護(hù)軟件的一門學(xué)科。②面到要求的軟件功能。⑥能按時(shí)完成開發(fā)任務(wù)，及時(shí)交付使用。它們覆蓋了需求、設(shè)計(jì)、實(shí)現(xiàn)、確認(rèn)以及維護(hù)等活動(dòng)。軟件工程方法學(xué)包括：①傳統(tǒng)方法學(xué)（結(jié)構(gòu)化范型）和②面向?qū)ο蠓椒▽W(xué)。④對(duì)象彼此之間僅能通過傳遞消息互相聯(lián)系。又劃分為：①問題定義、②可行性研究、③需求分析、④總體設(shè)計(jì)、⑤詳細(xì)設(shè)計(jì)、⑥編碼和單元測(cè)試、⑦綜合測(cè)試、⑧維護(hù)八個(gè)階段。唯一不變的是變化本身。好的軟件設(shè)計(jì)將為軟件程序編寫打下良好的基礎(chǔ)?！　≤浖y(cè)試　　在軟件設(shè)計(jì)完成后要經(jīng)過嚴(yán)密的測(cè)試，以發(fā)現(xiàn)軟件在整個(gè)設(shè)計(jì)過程中存在的問題并加以糾正?！　∵\(yùn)行維護(hù)　　軟件維護(hù)是軟件生命周期中持續(xù)時(shí)間最長的階段。 什么是白盒測(cè)試法？什么是黑盒測(cè)試法？答：白盒測(cè)試：所謂白盒測(cè)試就是在知道產(chǎn)品內(nèi)部工作過程或程序內(nèi)部結(jié)構(gòu)和處理過程的前提下,檢驗(yàn)產(chǎn)品內(nèi)部動(dòng)作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行或按照程序內(nèi)部的邏輯測(cè)試程序,。優(yōu)點(diǎn) 1. 基本上不用人管著，如果程序停止運(yùn)行了一般就是被測(cè)試程序crash了 2. 設(shè)計(jì)完測(cè)試?yán)螅聛淼墓ぷ骶褪撬?，?dāng)然更苦悶的是確定crash原因缺點(diǎn) 1. 結(jié)果取決于測(cè)試?yán)脑O(shè)計(jì)，測(cè)試?yán)脑O(shè)計(jì)部分來勢(shì)來源于經(jīng)驗(yàn)，OUSPG的東西很值得借鑒 2. 沒有狀態(tài)轉(zhuǎn)換的概念，目前一些成功的例子基本上都是針對(duì)PDU來做的，還做不到針對(duì)被測(cè)試程序的狀態(tài)轉(zhuǎn)換來作 3. 就沒有狀態(tài)概念的測(cè)試來說，尋找和確定造成程序crash的測(cè)試?yán)莻€(gè)麻煩事情，必須把周圍可能的測(cè)試?yán)龁为?dú)確認(rèn)一遍。非漸增式是將模塊先進(jìn)行單元測(cè)試然后組裝在一起進(jìn)行測(cè)試。 什么是確認(rèn)測(cè)試？該階段有那些工作？答：調(diào)試的目的是發(fā)現(xiàn)錯(cuò)誤