項目管理信息系統(tǒng)項目管理師考試輔導教程第版第章軟件工

管理師考試輔導教程(第版)者搞得術語混淆，下面我們一起來看看這些概念。通常問題定義本身就是業(yè)務需求。角度的需求。能需求、質(zhì)量屬性，以及其他非功能需求，還有設計約束。2.需求工程(1)需求開發(fā)：包括需求捕獲、需求分析、編寫規(guī)格說明書和需求驗證四個階段。在這個階段需為軟件規(guī)格說明書和需求分析模型、對需求進行評審等工作。(2)需求管理：通常包括定義需求基線、處理需求變更、需求跟蹤等方面的工作。而對于需求工進行驗證。使用的。2.1.2需求調(diào)查與問題定義這是因為大部分客戶無法完整地講述需求，而且也不可能看到系統(tǒng)的全貌。要想做接下來，我們就對這三個部分的內(nèi)容進行一些更加詳細的說明與描述。關的信息（如業(yè)務資料、組織結(jié)構圖、業(yè)務處理流程等)；二三是用戶對系統(tǒng)的特別期望與施加的任何約束信息。這樣才能夠有的放矢，不會顧此失彼。信息，這樣才有可能獲得所需信息，才知道工作進展是否順利，是否完成了目標。2.信息的來源產(chǎn)品、領域?qū)＜?、技術法規(guī)與標準里。而對于文檔、產(chǎn)品而言，則更容易有選擇地查閱。更加高效。行需求捕獲了。在此，我們列舉出一些最常用的需求捕獲技術。(1)用戶訪談。計劃清楚，應該保持良好的靈活性。一定的工作量和難度。訪談的效率大打折扣。在訪談時一定要注意保持輕松的氣氛，選認識，讓被訪談者能夠信任你。詢問過程中詢問被訪者還希望自己問他什么這看似簡單的技術，也需要分析人員擁有足夠多的經(jīng)驗和較強的溝通能力。(2)用戶調(diào)查。到的兩個問題。他們的表情等其他動作來獲取一些更隱性的信息;還有就是客戶有可能在心理上會不重視一張小組、整理、分析，以獲得基礎信息，然后再針對這個結(jié)果進行小范圍的用戶訪談，作補充。(3)現(xiàn)場觀摩。操作采用現(xiàn)場觀摩的方法來獲取需求。戶工作一小段時間。這樣就可以使得分析人員更加直觀地理解需求。(4)?文檔考古。件、表單、報告，從中獲得所需的信息。保密也是分析人員基本的職業(yè)道德。(5)聯(lián)合討論會。~18人，召開時間1~5小時。在會議之前，應該將與討論主題相關的材料提前分發(fā)給所有要參加會議的人。在會議開始之后，就是針對所列舉的問題進行逐項專題討論，然后對原有系統(tǒng)、類似系統(tǒng)的不足進行開放性交流，評審。這種聯(lián)合討論會將會起到群策群力的效果,對于一些最有歧義的問題和對需求最不清晰的領域都達到預想的效果。4.需求捕獲的策略再進行有針對性的需求捕獲工作。2.1.3可行性研究客戶的需要，實現(xiàn)客戶的目標呢這就需要大量的需求分析與可行性研究工作。1.可行性研究工作的基礎完整的問題定義。2.可行性研究工作的任務(1)技術可行性：現(xiàn)有的技術是否能夠有效地解決該問題?是否有多種不同的解決方案?現(xiàn)有的技(3)社會可行性：該解決方案是否符合企業(yè)實際情況?是否符合員工利益?是否符合相關法規(guī)和行3.可行性研究工作的步驟行性研究工作的步驟做一個總結(jié)性闡述。(1)核實問題定義與目標。次核實。具體來說，就是仔細閱讀問題定義的相關材料，對該問題所涉及的領域知識進行學習、考證，然后通過走訪相關人員進行驗證與核實。這一步驟的關鍵目標是：使問題定義更加清晰、明確、沒有歧義性，并且對系統(tǒng)的以及相關約束與限制條件做出更加細致的定義，確保可行性研究小組的所(2)研究分析現(xiàn)有系統(tǒng)。充分分析有助于新系統(tǒng)的開發(fā)。這么說的原因，主要是?現(xiàn)有系統(tǒng)已實現(xiàn)的功能通常也是新系統(tǒng)要實現(xiàn)功能的一部分。理解會容易產(chǎn)生一個常見的誤區(qū)，就是認為現(xiàn)有系統(tǒng)一定是軟件系統(tǒng)，其實這里的“現(xiàn)有系統(tǒng)”不僅包括舊的軟件系統(tǒng)，還包括舊的非計算機系統(tǒng)。(3)新系統(tǒng)建模。對新系統(tǒng)的框架認識、概念性認識。通常可以采用以下幾種技術。圍，實現(xiàn)共識。主要的實體，以及實體以間的關系即可。的工作中。(4)客戶復核。顯得十分重要。如果在這個過程中，發(fā)現(xiàn)模型與客戶的目標有不一致的地方，就應該再次通過訪談、現(xiàn)場觀摩、對現(xiàn)有系統(tǒng)分析等手段進行了解，然后在此基礎上修改模型。由此也可以看書1)~（4)的步驟是一個循環(huán)，周而復始，直至客戶確認了新的系統(tǒng)模型止。(5)提出并評價解決方案。法、經(jīng)濟角度明顯不可行的、違背企業(yè)或行業(yè)實際情況的解決方案應該直接過濾掉。(6)確定最終推薦的解決方案。最可行的解決方案，更加詳細地說明理由，并且還要對其進行更加完善的成本/效益分析。具體來說，成本效益分析可以分成兩個部分的內(nèi)容。學的評估，并在此基礎上進行計算是很必要的。?首先，進行工作任務分解，將目標細化。的分析法進行估算，并且將估算的結(jié)果與類似項目的歷史數(shù)據(jù)進行比較，做出隊、管理層和客戶很清晰地認識到。否則，即使違心地給出精確的估算值也顯得沒有任何意義。握方面。行效益分析時要借助以下幾個概念。?投資回收期：投資回收期的意思就是要多少年才能夠?qū)⑼顿Y回收，越短越有利。統(tǒng)的累計經(jīng)濟效益（折成現(xiàn)值）與投資之差?；貓舐剩≧OI),公式如下所示：其中，P代表總投資額，F(xiàn),?是第I年年底的收益，n是系統(tǒng)使用壽命，J就是投資回報率。.(7)草擬開發(fā)計劃。度安排。這也將作可行性分析的一個重要依據(jù)和立項開發(fā)后制訂項目計劃的基礎。(8)以書面的形式提交《可行性分析報告》并進行審查。作一些相應的講義，客戶和管理層做介紹和說明。2.1.4需求分析在細化地說明需求分析之前，我們先溫習一下分析的定義：所謂分析就是通過對問題域的研究，獲得對該領域特性及存在于其中（需要解決）的問題特性的透徹理解并用文檔說明。素之間的關系進行建模。含義并找出其中的錯誤、遺漏或其他不足的地方。(1)繪制系統(tǒng)上下文范圍關系圖：這種關系圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的(2)創(chuàng)建用戶接口原型：由于用戶界面對于一個系統(tǒng)來說是十分重要的，因此在需求分析階段通解決的問題，更好地理解需求。(3)分析需求的可行性：對所有獲得的需求進行成本、性能、技術實現(xiàn)方面的可行性研究，以及這些需求項是否與其他的需求項有沖突，是否有對外的依賴關系等。(4)確定需求的優(yōu)先級：這是一個很重要的工作，迭代開發(fā)已經(jīng)成為現(xiàn)代軟件工程方法論的一個滿意度/非滿意度指標進行說明（滿意度：取值1~5,表示當需求被實現(xiàn)時用戶的滿意程度。不(5)為需求建立模型：也就是建立分析模型，這些模型的表現(xiàn)形式主要是圖表加上少量的文字描述，正所謂一圖抵千字，圖形化地描述需求使其更加清晰、易懂。根據(jù)采用的分析技術的不同，化分析技術下的數(shù)據(jù)流圖等。(6)創(chuàng)建數(shù)據(jù)字典：數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結(jié)構進行定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。(7)使用質(zhì)量功能調(diào)配（QFD):這是在需求優(yōu)先級基礎上的一個升華，其原理與滿意度/非滿意度沒有也不會遭到責備。2.需求建模是需要把用文字表示的需求和用圖形表示的需求結(jié)合起來。而用圖形表示需求，就是需求建模，況進行有效的組合。以保持其可控性。2.1.5流行的需求分析方法論這時人們開始嘗試使用標準化的方法，開發(fā)和推出各種名“結(jié)構化分析軟系統(tǒng)方法：這是一個過渡性的方法論，并觀格格不入，而且在解決“不確定性”時顯得速發(fā)展。用和發(fā)展發(fā)現(xiàn)面向?qū)ο蠓治龇椒ㄒ泊嬖谥芏嗟牟蛔?，?.結(jié)構化分析結(jié)構化分析與面向?qū)ο蠓治龇椒ㄖg的最大差別是:結(jié)構化分析方法把系統(tǒng)看做一個過程的集合分析方法的特點是利用數(shù)據(jù)流圖來幫助人們理解問題，對問題進行分析。結(jié)構化分析一般包括以下工具，在本節(jié)的隨后部分將對它們一一做簡單介紹。?數(shù)據(jù)字典(DataDictionary,DD?結(jié)構化語言；?判定表；?判定樹。分析技術，也是完成需求規(guī)格化的有效技術手段。這個數(shù)據(jù)流圖中，可以包括一些非計算機系統(tǒng)中數(shù)據(jù)流及處理的命名，例如，部門名、崗位名、報表名等。這個過程可以幫助分析員有效地理解業(yè)務環(huán)境，在與用戶的充分溝通與交流中完成。(2)建立系統(tǒng)邏輯模型。當物理模型建立完成之后，接下來的工作是畫出相對真實系統(tǒng)的等價邏(3)劃清人機界限。最后，我們確定在系統(tǒng)邏輯模型中，哪些將采用自動化完成，哪些仍然保留手工操作。這樣就可以清晰地劃清系統(tǒng)的范圍。2.數(shù)據(jù)流圖個圖形模式只有五個符號需要記憶，所以深受分析人員的喜愛，因而廣流行。?過程：一步步地執(zhí)行指令，完成輸入到輸出的轉(zhuǎn)換。?外部實體：系統(tǒng)之外的數(shù)據(jù)源或目的。?數(shù)據(jù)存儲：存放數(shù)據(jù)的地方，一般是文件、數(shù)據(jù)庫等形式。?數(shù)據(jù)流：從一處到另一處的數(shù)據(jù)流向，如從輸入或輸出到一個過程的數(shù)據(jù)流。?實時連接：當過程執(zhí)行時，外部實體與過程之間的來回通信。(1)數(shù)據(jù)流圖的層次。正如前面提到的，結(jié)構化分析的思路是依賴于數(shù)據(jù)流圖進行自頂而下的分而且可以這樣逐一地分解下去，直至系統(tǒng)被清晰地描述出來。進出系統(tǒng)的數(shù)據(jù)流都畫在一張圖中。則就是1.1,1.2-,以及2.1，2.2-,依此類推,直到完成分析工作。加遺漏的。?每一個數(shù)據(jù)流命名：命名的好壞與數(shù)據(jù)流圖的可理解性密切相關，應避免使用空洞的名字。?加工命名：注意應用動賓短語。不考慮初始化和終點，暫不考慮出錯路徑等細節(jié)，不畫控制流和控制信息。決策表等方法。通過使用這些工具，能夠?qū)?shù)據(jù)流圖中描述不夠清晰的地方進行有效的補充。(1)結(jié)構化語言。結(jié)構化語言是結(jié)構化編程語言與自然語言的有機結(jié)合，可以采用順序結(jié)構、分ElseEndlfEndlf'ELSEEndlfEndlf有優(yōu)劣，決策表更嚴密，而決策樹更易讀。分析人員可以根據(jù)自己的實際需要來靈活選擇應用。(3)數(shù)據(jù)字典。數(shù)據(jù)字典技術是一種很實用、有效的表達數(shù)據(jù)格式的手段。它是對所有與系統(tǒng)相關的數(shù)據(jù)元素的一個有組織的列表和精確的、嚴格的定義，使用戶和系統(tǒng)分析員對輸入、輸出、存儲成分和中間計算機有共同的理解。通常數(shù)據(jù)字典的每一條目中包括以下信息。?名稱：數(shù)據(jù)或控制項、數(shù)據(jù)存儲或外部實體的主要名稱，如果有別名的還應該將別名列出來。?何處使用/如何使用：使用數(shù)據(jù)或控制項的加工列表，以及如何使用。?內(nèi)容描述：說明該條目內(nèi)容組成，通常采用以下符號進行說明。>*-*:表示特定限制的注釋。?補充信息：關于數(shù)據(jù)類型、默認值、限制等信息。4.實體-關系圖(1)實體。由于所有的系統(tǒng)都包括數(shù)據(jù)，而且是大量的數(shù)據(jù)。因此，我們在開發(fā)系統(tǒng)時，需要一圓角的矩形來表示，如圖2-7(a)所示。從這個概念上看,與面向?qū)ο蠓治龇椒ㄖ械念愑行┫嗨?。示實體的一個具體值，稱為實體實例。來描述實體的性質(zhì)或特征，可以直接在圓角矩形中填入這些屬性值，如圖2-7(b)所示。另外還值的后面，如圖2-7(c)所示。關于數(shù)據(jù)類型、域的說明如表2-4所示。對于整數(shù)，指定范圍丨最大~最小}{代表代碼及含義的表}AlternateKey等描述，如圖2-ra姓名：Text(10)t姓名：Text(10)JL地ib_TeXt(30}.」(c)(d)(2)關系。實體和屬性都不是孤立存在的，它們各自代表的事物互相交互，并且互相影響，共同件，也可以是純粹的邏輯關系。析目標以支持。但也存在著很多的先天不足：?對問題域的研究力度不夠大；?分析與設計之間缺乏清晰的界限；?沒有一個真正的功能規(guī)格說明；?需求實質(zhì)上是根據(jù)滿足該需求的某一特定系統(tǒng)的內(nèi)部設計來加以說明的；?內(nèi)部設計的開發(fā)使用的則是不可靠的內(nèi)部設計技術-功能分解：?不適用于很多類型的應用。代，不過，結(jié)構化分析方法中的具體工具仍然有很廣泛的應用空間。5.面向問題域的分析相對而言，面向問題域的分析是一項很新的技術，還處于研究階段，相關的文檔資料還不多。(2)關注解系統(tǒng)的待求行為：用一個文檔對解系統(tǒng)（即系統(tǒng)實現(xiàn)）的待求行為進行描述。該文檔將在需求規(guī)格說明時再完成。在面向問題域的分析方法中，對整個過程有著一個清晰的定義：?搜集基本的信息并開發(fā)問題框架，以建立問題域的類型；?在問題框架類型的指導下，進一步搜集詳細信息并給出一個問題域相關特性的描述?；谝陨蟽牲c，收集并用文檔說明新系統(tǒng)的需求。建模成一系列相互關聯(lián)的子域,而一個子域可以是那些可能算是精選出來的問題域題框架則是針對問題域的。也就是說，問題框架的目標就是大量地捕獲更多有關問題域的信息。2.2軟件設計從功能上的劃分來看，軟件設計應該是軟件設計師的工作,但作為一名項目管理師，首先自己必須懂得軟件設計的基本原則和理論，掌握基本的軟件設計方法，具有一定的軟件設計經(jīng)驗。2.2.1軟件設計基本原則1.信息隱蔽息隱藏。應該讓模塊僅僅公開必須要讓外界知道的內(nèi)容，而隱藏其他一切內(nèi)容。在信息隱蔽原則已成為軟件工程學中的一條重要原則。2.模塊獨立性果。一般采用兩個準則度量模塊獨立性，即模塊間耦合和模塊內(nèi)聚。元素之間的聯(lián)系越緊密，則它的內(nèi)聚性就越高，相對地，它與其他模塊之間的耦合性就會減低，而模塊獨立性就越強。由此可見，模塊獨立性比較強的模塊應是高內(nèi)聚低耦合的模塊。(1)內(nèi)聚。內(nèi)聚是信息隱蔽功能的自然擴展。內(nèi)聚的模塊在軟件過程中完成單一該只完成一件事。在設計模塊時應盡量爭取高內(nèi)聚。模塊各種屬性的關系。高*----------------------------內(nèi)聚性----------------------------低強*--------------------------模塊獨立性--------------------------弱功能單一----------------------------------------------------功能分散的，則稱該模塊功能內(nèi)聚模塊。它是內(nèi)聚程度最高的，也是模塊獨立性最強的模塊。操作，每一項功能有一個唯一的入口點。這個模塊將根據(jù)不同的要求，確定該執(zhí)行哪一個功能。信息內(nèi)聚模塊可以看成是多個功能內(nèi)聚模塊的組合，并且達到信息的隱蔽。即把某個數(shù)據(jù)結(jié)構、資源或設備隱蔽在一個模塊內(nèi)，不為別的模塊所知曉。三個模塊，這三個模塊都是過程內(nèi)聚模塊。塊和終止模塊。送給模塊的判定參數(shù)來確定該模塊應執(zhí)行哪一種功能。或者即使有聯(lián)系，這種聯(lián)系也很松散，則稱這種模塊巧合內(nèi)聚模塊，它是內(nèi)聚程度最低的模塊。(2)耦合。耦合是程序結(jié)構中模塊相互關聯(lián)的度量。耦合取決于各個模塊間接口的復雜程度、調(diào)用模塊的方式，以及哪些信息通過接口。.耦合的強度依賴于以下幾個因素：?一個模塊對另一個模塊的調(diào)用；?一個模塊向另一個模塊傳遞的數(shù)據(jù)量；?一個模塊施加到另一個模塊的控制的多少；?模塊之間接口的復雜程度。低----------------------------耦合性"髙強**-------------------------模塊獨立性--------------------------弱.標記耦合不一定中中中全是通過主模塊的控制和調(diào)用來實現(xiàn)的，這就是非直接耦合。這種耦合的模塊獨立性最強。是控制參數(shù)、公共數(shù)據(jù)結(jié)構或外部變量）來交換輸入、輸出信息的，則稱這種耦合數(shù)據(jù)耦合。控制選擇另一模塊的功能，就是控制耦合。而且不是通過參數(shù)表傳遞該全局變量的信息，則稱外部耦合。?耦合有兩種情況。松散公共耦合和緊密公共耦合。2.2.2結(jié)構化設計方法起來的，該方法實施的過程如下。(1)總結(jié)出系統(tǒng)應有的功能，對一個功能，從功能完成的過程考慮，將各個過程列出，標志出過程轉(zhuǎn)向和傳遞的數(shù)據(jù)。這樣，可以將所有的過程都畫出來。(2)細化數(shù)據(jù)流。確定應該記錄的數(shù)據(jù)。(3)分析各過程之間的耦合關系，合理地進行模塊劃分以提高它們之間的內(nèi)聚性。目標，大多數(shù)系統(tǒng)做不到完全因子分解。(a)(b)(c)(d)*傳入模塊：圖2-11(a),從下屬模塊取得數(shù)據(jù)，經(jīng)過某些處理，再將其傳送給上級模塊。它傳送?傳出模塊：圖2-11(b),從上級模塊取得數(shù)據(jù)，進行某些處理，傳送給下屬模塊。它傳送的數(shù)據(jù)流叫做邏輯輸出數(shù)據(jù)流。?變換模塊：圖2-11(c),從上級模塊取來數(shù)據(jù)，進行特定處理后，送回原上級模塊。它加工的數(shù)據(jù)流叫做變換數(shù)據(jù)流。調(diào)模塊應在較高層出現(xiàn)。及執(zhí)行順序所依賴的條件。結(jié)構圖則著眼于軟件系統(tǒng)的總體結(jié)構，則用來表達執(zhí)行程序的具體算法。定建筑面積和樓屋有多少時，就己經(jīng)開始砌磚了。這顯然是不合適的。不明白。我知道你相信我有車票，但……我要去哪里呢’”有太多項目失敗就是因它們沒有明確的目標就開始了。程。結(jié)構圖中的主要成分有四種。(1)模塊。以矩形框表示，框中標有模塊的名字。對于已定義（或者已開發(fā)）的模塊，則可以用(2)模塊間的調(diào)用關系。兩個模塊，一上一下，以箭頭相連，上面的模塊是調(diào)用模塊，箭頭指向(3)模塊間的通信。以表示調(diào)用關系的長箭頭旁邊的短箭頭表示，短箭頭的方向和名字分別表示在結(jié)構圖中條件調(diào)用所依賴的條件和循環(huán)調(diào)用的循環(huán)控制條件通常都無需注明。3.常用的系統(tǒng)結(jié)構圖常用的系統(tǒng)結(jié)構圖有以下幾種。結(jié)構圖分別如圖2-17(a)和（b)所示。事務的類型，選擇調(diào)用某一個處理事務模塊。(3)混合型系統(tǒng)結(jié)構圖。在實際中，一些大型問題往往既不是單純的變換型問題，也不是單純的的下層結(jié)構圖可以按通常的變換型問題映射方法獲得。2.2.3用戶界面設計像人類追求心靈美和外表美那樣，軟件系統(tǒng)也追求（內(nèi)在的）功能強大和（外表的）界面友好。美的界面能消除用戶由感覺引起的乏味、緊張和疲勞（情緒低落)，大從而進一步為發(fā)揮用戶技能和完成任務做出貢獻。從人-機界面發(fā)展歷史與趨勢上可以看出人們對界面美的需求，以及美在界面設計中的導向作用。界面設計已經(jīng)經(jīng)歷了兩個界限分明的時代。生活空間，例如，虛擬現(xiàn)實環(huán)境。界面的美充分體現(xiàn)了人_機交互作用中人的特性與意圖，越來越多的用戶將通過具有吸引力而令人愉快的人-機界面與計算機打交道。一個好的用戶界面應具有以下特點。1.可使用性(1)使用的簡單性；(2)用戶界面中所用術語的標準化和一致性；(3)擁有幫助功能；(4)快速的系統(tǒng)響應和低的系統(tǒng)成本；(5)用戶界面應具有容錯能力。2.靈活性(1)考慮用戶的特點、能力、知識水平，應當使用戶界面能夠滿足不同用戶的要求；(2)用戶可以根據(jù)需要制訂和修改界面方式；(3)系統(tǒng)能夠滿足用戶的希望和需要；(4)與其他軟件系統(tǒng)應有標準的接口。3.復雜性和可靠性(1)用戶界面的規(guī)模和組織的復雜程度就是界面的復雜性；(2)用戶界面的可靠性是指無故障使用的間隔時間。2.2.4設計評審下一個階段。設計評審一般采用評審會議的形式來進行。?設計負責人職責：一般工程設計均由軟件公司選派設計負責人，設計負責人承擔該項工程的全部設計管理任務；對設計質(zhì)量、進度編寫總說明，匯編總概算。?高級管理人員職責：確定主審員、審批評審記錄。?主審員職責：在評審會前提出項目的書面評審意見、確定評審組、確定評審結(jié)果并填寫評審記錄。?評審組職責：專業(yè)評審組評委表決通過項目初評結(jié)論并報綜合評審會議通過設計報告。2.3軟件測試軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程,是根據(jù)程序開發(fā)階段的規(guī)格說明及程序內(nèi)部結(jié)構而精心設計的一批測試用例（輸入數(shù)據(jù)及其預期結(jié)果的集合)，并利用以發(fā)現(xiàn)程序錯誤的過程。件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可接受該產(chǎn)品。包括合理的輸入條件和不合理的輸入條件；充分注意測試中的群集現(xiàn)象。經(jīng)驗表明,測試后程序應當對每一個測試結(jié)果做全面檢查；妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告，為軟件維護提供方便。計、詳細設計，以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設計規(guī)格說明、詳細設計規(guī)格說明，以及源程序，都應成為軟件測試的對象。2.3.1測試用例設計1.黑盒測試求規(guī)格說明書，檢查程序的功能是否符合它的功能說明，又稱功能測試或數(shù)據(jù)驅(qū)動測黑盒測試方法主要是在程序的接口上進行測試，主要是為了發(fā)現(xiàn)以下錯誤。?是否有不正確或遺漏了的功能；在接口上，能否正確的接收輸入，能否輸出正確的結(jié)果；錯誤；確的輸出；有時測試數(shù)據(jù)量太大，是不現(xiàn)實的。黑盒測試的測試用例設計方法主要有如下幾種。(1)等價類劃分。等價類劃分是一種典型的黑盒測試方法，使用這一方法時，完全不考慮程序的計測試用例要經(jīng)歷劃分等價類（列出等價類表）和選取測試用例兩步。重復這一步，直到所有的無效等價類都被覆蓋止。(2)邊界值分析。邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充。人們從長期當選取正好等于、剛剛大于或剛剛小于邊界的值作測試(3)錯誤推測法。人們也可以靠經(jīng)驗和直覺推測程序中可能存在的各種錯誤，從而有針對性地編情況，根據(jù)它們選擇測試用例。據(jù)這些關系，畫出因果圖；這些特殊情況，在因果圖上用一些記號標明約束?把因果圖轉(zhuǎn)換成判定表；?把判定表的每一列拿出來作依據(jù)，設計測試用例。 的狀態(tài)是否與預期的狀態(tài)一致，又稱為結(jié)構測試或邏輯驅(qū)動測試。?對程序模塊的所有獨立的執(zhí)行路徑至少測試一次；?對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次；?在循環(huán)的邊界和運行界限內(nèi)執(zhí)行循環(huán)體；?測試內(nèi)部數(shù)據(jù)結(jié)構的有效性等。3.邏輯覆蓋定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋、路徑覆蓋等。?語句覆蓋：就是設i恃千個測棚例，運行被測程序，使每一可執(zhí)行語^至少執(zhí)行一次。?判定-條件覆蓋：設計足夠的測試用例，使判斷中每個條件的所有可能取值至少執(zhí)行一次，每個判斷中的每個條件的可能取值至少執(zhí)行一次。至少執(zhí)行一次。?路徑覆蓋：設計足夠的測試用例，覆蓋程序中所有可能的路徑。2.3.2軟件測試策略單元測試、集成測試（又稱組裝測試)、確認測測試則正好相反，以上這些過程就是自底向上，逐步集成的。1.單元測試多個模塊可以平行地對立地測試。通常在編碼階段進行，必要的時候要制作驅(qū)動模塊和粧模塊。的程序。打開了文件；在結(jié)束文件處理時是否關閉了文件；正文書寫/輸入錯誤；I/O錯誤是否做了檢查并做了處理等。影響等。環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。起系統(tǒng)的干預等。?邊界條件測試：注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。2.集成測試劃、集成測試規(guī)格說明和集成測試分析報告。接受的程度。程序的模塊結(jié)構中位于較高的層次，較復雜易發(fā)生錯誤，有明確定義的性能要求。3.確認測試確認測試驗證軟件的功能、性能及其他特性是否與用戶的要求一致。試的基礎。確認測試的主要步驟如下。（可移植性、兼容性、出錯自動恢復、可維護性等）都要進行測試。有維護階段所必需的細節(jié)，而且已經(jīng)編排好分類的目錄。和性能外，還應對軟件的可移植性、兼容性、可維護性、錯誤的恢復功能等進行確認。確認測試應交付的文檔有：確認測試分析報告；最終的用開發(fā)總結(jié)報告。與系統(tǒng)的定義不符合或與之矛盾的地方。確認測試過程中產(chǎn)品達到一定的穩(wěn)定和可靠程度之后再開始。由于P測試時，開發(fā)者通常并不在測試現(xiàn)場。因而試的最后階段。同時，產(chǎn)品的所有手冊文本也應該在此階段完全定稿。2.3.3軟件測試類型測試大致可以分為如下幾大類。(1)功能測試。功能測試是在規(guī)定的一段時間內(nèi)運行軟件系統(tǒng)的所有功能，以驗證這個軟件系統(tǒng)有無嚴重錯誤。(2)可靠性測試。如果系統(tǒng)需求說明書中有對可靠性的要求，則需進行可靠性測試。(3)強度測試。強度測試是要檢查在系統(tǒng)運行環(huán)境不正常乃至發(fā)生故障的情況下，系統(tǒng)可以運行要占用最大存儲量或其他資源的測試用例進行測試；設計出在虛擬存儲管理機制中引起“顛簸”的一個變種就是敏感性測試。敏感性測試是指在程序有效數(shù)據(jù)界限內(nèi)一個小范圍內(nèi)的-可能引起這種不穩(wěn)定性或不正常處理的某些數(shù)據(jù)組合。(4)性能測試。性能測試是要檢查系統(tǒng)是否滿足在需求說明書中規(guī)定的性能，特別是對實時系統(tǒng)沖區(qū)、工作區(qū)的大小、數(shù)據(jù)處理精度等。(5)恢復測試。恢復測試是要證實在克服硬件故障（包括掉電、硬件或網(wǎng)絡出錯等）后，系統(tǒng)能件故障，故意造成軟件出錯等。并由此檢查錯誤探測功能：作業(yè)和系統(tǒng)狀態(tài);在系統(tǒng)恢復后能否從最后記錄下來的無錯誤狀態(tài)開始繼續(xù)執(zhí)行作業(yè)，等等。掉源恢復時從保留的斷點處重新進行操作。(6)啟動/停止測試。這類測試的目的是驗證在機器啟動及關機階段，軟件系統(tǒng)正確處理的能力。盡可能多的情況下關機。(7)配置測試。這類測試是要檢查計算機系統(tǒng)內(nèi)各個設備或各種資源之間的相互聯(lián)結(jié)和功能分配態(tài)及哪個設備是壞的，并用自動或手工的方式進行配置狀態(tài)間的轉(zhuǎn)換。(8)安全性測試。安全性測試是要檢驗在系統(tǒng)中己經(jīng)存在的系統(tǒng)安全性、保密性措施是否發(fā)揮作信息)，以獲取如口令、安全碼、譯碼關鍵關鍵字；瀏覽那些邏輯上不存在，但物理上還存在的各種記錄和資料等。(9)可使用性測試。可使用性測試主要從使用的合理性和方便性等角度對軟件系統(tǒng)進行檢查，發(fā)問題；軟件文檔全面、正規(guī)、確切。有多種選擇，例如，要分配和裝入文件與程序庫、布置適用的硬件配置，以及進行程序的聯(lián)結(jié)；生并確有所需要的內(nèi)容，硬件的配置是否合理，等等。完成的過程也需要經(jīng)過仔細的檢查，這就是所謂的過程測試。頻率達到最大。在使系統(tǒng)的全部資源達到“滿負荷”的情況下，測試系統(tǒng)的承受能力。(13)文檔測試。這種文檔測試是檢查用戶文檔（如用戶手冊）的清晰性和精確性。測試：向下兼容和交錯兼容。2.3.4面向?qū)ο蟮能浖y試開發(fā)模型，結(jié)合傳統(tǒng)的測試步驟劃分，提出一種面向?qū)ο蟮男袦y試，如成員函數(shù)間的相互作用，類間的消息傳遞等。傳統(tǒng)的面向過程分析是一個功能分解的過程,把一個系統(tǒng)看成可以分解的功能的集合。這種傳統(tǒng)提供平臺。的屬性和實例關聯(lián)的測試；對定義的服務和消息關聯(lián)的測試。2.面向?qū)ο笤O計的測試通常結(jié)構化的設計方法是用面向作業(yè)的設計方法，它把系統(tǒng)分解后，提出一組作業(yè),這些作業(yè)是入。?對認定的類的測試；?對構造的類層次結(jié)構的測試；?對類庫的支持的測試?，F(xiàn)全部功能的結(jié)構框架。此，測試如下幾個方面：?類層次結(jié)構是否包含了所有定義的類；?子類是否具有父類沒有的新特性；?子類間的共同特性是否完全在父類中得以體現(xiàn)。3.面向?qū)ο缶幊痰臏y試和讀寫的可能性，降低了傳統(tǒng)程序中對數(shù)據(jù)非法操作的測試。繼承使傳統(tǒng)測試遇到了一個難題，兩個方面：(1)數(shù)據(jù)成員是否滿足數(shù)據(jù)封裝的要求；(2)類是否實現(xiàn)了要求的功能。4.面向?qū)ο蟮膯卧獪y試際測試類成員函數(shù)。傳統(tǒng)的單元測試方法在面向?qū)ο蟮膯卧獪y試中都可以使用。面向?qū)ο缶幊痰奶匦允沟脤Τ蓡T函數(shù)的測試,又不完全等同于傳統(tǒng)的函數(shù)或過程測試。尤其是繼下的考慮。(1)繼承的成員函數(shù)是否都不需要測試。對父類中已經(jīng)測試過的成員函數(shù)，下面兩種情況需要在(2)對父類的測試是否能照搬到子類。只需在父類測試要求和測試用例上添加對子類函數(shù)的新的測試要求和增補相應的測試用例。5.面向?qū)ο蟮募蓽y試面向?qū)ο蟮募蓽y試通常需要在整個程序編譯完成后進行。此外，面由于程序的控制流往往無法確定，因此也只能對整個編譯后的程序做基于黑盒子的集成測試。作用。面向?qū)ο蟮募蓽y試可以先進行靜態(tài)測試，再進行動態(tài)測試。 依據(jù)類間傳遞的消息，達到對所有執(zhí)行線程的一定覆蓋率，達到類的所有狀態(tài)的一定覆蓋率等。 用例時，不但要設計確認類功能滿足的輸入，還應該有意識地設計一些被禁止的例子,確認類是 否有不合法的行為產(chǎn)生,如發(fā)送與類狀態(tài)不相適應的消息，要求不相適應的服務等。6.面向?qū)ο蟮南到y(tǒng)測試系統(tǒng)測試應該盡量搭建與用戶實際使用環(huán)境相同的測試平臺,保證被測系統(tǒng)結(jié)合需求分析做仔細的測試分析，建立測試用例。2.4軟件維護2.4.1軟件的可維護性個階段。1.軟件具有可維護性它，可以維護它。依據(jù)軟件本身的特點，軟件具有可維護性主要由以下三個因素決定：軟件維護人員通過了解同樣的思路，可以理解軟件。(2)可測試性。借助人工的經(jīng)驗或者先進的測試工具，維護人員可以對運行的軟件進行測試，找(3)可修改性。任何軟件都是通過某種開發(fā)工具來完成的，都有源碼，運用同樣的工具，維護人2.采用軟件工程提高軟件的可維護性增加了軟件的可維護性。所以，對于維護人員來說文檔比程序源碼更為重要。軟件系統(tǒng)的文檔可分為用戶文檔和系統(tǒng)文檔兩大類。用戶文檔主要是描述軟件功能和使用方法。至少應包括以下幾個方(1)功能說明：說明系統(tǒng)能做什么。(2)安裝文檔：說明系統(tǒng)安裝過程及所需軟硬件配置。(3)用戶使用手冊：通過詳盡的例子向終端用戶介紹如何使用這個系統(tǒng)。(4)參考手冊：從技術的角度對系統(tǒng)進行形式化的描述。(5)管理員指南：說明系統(tǒng)管理人員如何處理使用中出現(xiàn)的各種情況。計劃等。3.注重可維護性的開發(fā)過程維護性。行考慮。具體如下：移植性進行討論，形成解決方案。各方面條件都滿足，應該使用面向?qū)ο蟮脑O計方法。?在測試階段，一方面，測試的目的本質(zhì)上是為了減少各種維護的工作量，尤其是糾錯型維護。性循環(huán)。冊等保證系統(tǒng)的一致性；同時，在大的維護之后，交付之前，一定要及時做好用戶的培訓工使用手冊描述不清楚而造成的。4.可維護性的度量?分析問題需要的時間；?確定改動方案的時間；?執(zhí)行改動花費的時間；?測試改動花費的時間；?其他管理浪費的時間。幾個方面。優(yōu)劣，選擇出對環(huán)路數(shù)影響最小的作為最優(yōu)的方案。(2)軟件規(guī)模。通常，可以認為軟件包含的組件越多，軟件就越復雜，可維護性就越差；(3)其他因素。包括嵌套深度、系統(tǒng)用戶數(shù)等?？椬陨淼慕?jīng)驗，建立合適的經(jīng)驗模型。一般情況下，可以按如下步驟建立經(jīng)?首先，確定影響可維護性的若干主要因素，并為其制訂尺度；?其次，用大量的現(xiàn)有案例，計算出一個包含影響因素及其權值的多項式模型；?再次，利用這個經(jīng)驗模型分析新的軟件，再根據(jù)實際的維護活動的感受進行校準；?重復這一校準過程，就能逐步建立起逼近實際的基本穩(wěn)定的模型。這個模型最常用的是其比較特性,也就是說,可以據(jù)此對問題的維護難度進行排序。2.4.2軟件維護的分類軟件的維護從性質(zhì)上分為：糾錯型維護、適應型維護、預防型和完善型維護。各種應用環(huán)境的變化，錯誤仍會頑固地暴露出來，此時就要進行糾錯型維護。護。完善等。種維護所占的比例很小，因它耗資巨大。在的情況并沒有多大變化。2.4.3軟件維護的工作量如，熟悉原有軟件的代碼，理解原有軟件的結(jié)構等)。度上升。響外，還有如下一些因素也會影響到維護工(1)維護工作本身是否規(guī)范，是否按軟件工程的正確方法進行，對后續(xù)的維護工作量的影響同樣不可忽視。如果維護工作不規(guī)范，代碼修改與文檔修改不同步，會導致維護更加難以理解，難以熟悉，維護工作量也會以指數(shù)速度增加。(2)軟件系統(tǒng)的類型不同，維護工作量也有區(qū)別。通常，一個系統(tǒng)越依賴于真實世界，就越可能系統(tǒng)的維護工作量最小，模擬系統(tǒng)的維護工作量最大。(3)硬件因素。不可靠的硬件系統(tǒng)會使軟件系統(tǒng)產(chǎn)生一些令人惱火的隨機性的問題，使追蹤問題量豈有不大之理。維護人員作服務的窗口，逐漸被重視，因只有維護做好了，才能鞏固已有客戶。2.4.4軟件維護作業(yè)的實施和管理不管是哪種類型的維護，都需要類似開發(fā)的過程，本質(zhì)上說，維護過程是修改和壓縮了的開發(fā)過程。1.建立維護組織護必然會帶來變動，因此需要維護配置員至少做好如下的變動控制：?變動的時間；?執(zhí)行變動的人員；?變動的內(nèi)容；?變動的結(jié)果；?批準變動的人員；?變動的通知范圍；?變動的級別。2.提出維護需求戶說明如何記錄碰到的軟件問題，以便規(guī)范用戶完整描述其維護需求。?問題發(fā)現(xiàn)人姓名及其所在的部門；?發(fā)現(xiàn)問題的時間；?發(fā)生問題的子系統(tǒng)名稱；?問題產(chǎn)生前進行的操作；?問題的界面或描述；?問題的后果描述，比如退出當前操作，退出應用系統(tǒng)還是導致死機。置管理。如果同時有多個維護需求，維護管理員則應根據(jù)對用戶的影響程度，首先確定維護的優(yōu)先順序，再依次安排維護活動。每一次維護活動的實施都要經(jīng)歷如下的步驟：?確認維護需求；?制訂維護計劃；?編碼；?測試；?交付用戶。險控制計劃對保證維護按時保質(zhì)的完成非常重結(jié)構有關的代碼段的修改不被遺漏?；貧w測試則可以有效地查明修改程序代碼對原有軟件的影件問題（比如數(shù)據(jù)庫崩潰等）時，維護組織就會以“有時間進行計劃評審，此時軟件開發(fā)商應派出技術4.記錄維護要素在維護活動中需要及時記錄維護的有關信息，用以考查維護技術的有效性，估計軟件的“優(yōu)良”程度，確定維護的實際代價，同時這些記錄將作后續(xù)評價活動的依據(jù)。?源碼行數(shù)；?使用的開發(fā)語言；?程序的安裝日期；?從安裝至今程序運行的次數(shù)；?從安裝至今程序失效的次數(shù)；?程序變動的標志；?因變動而增加的源碼行數(shù)；?因變動而刪除的源碼行數(shù)；?每個改動耗費的人時數(shù)；?程序改動的日期；?修改者的姓名；?維護需求表的標志；?新維護需求是否源于以前的維護工作；?維護類型；?維護開始和完成曰期；?累計用于維護的人時數(shù)；?已完成的維護創(chuàng)造的直接和間接的效益。對于每項維護工作，都要收集上述數(shù)據(jù)’而且可以基于這些數(shù)據(jù)建立起維護數(shù)據(jù)庫。5.評價維護活動借助于維護記錄，可以對維護工作做一些定量的統(tǒng)計。通常從以下幾個方面進行度量:?以前維護工作引起的新維護占總維護需求的比例；?程序的平均失效次數(shù)；?每一類維護活動的總?cè)藭r數(shù)及維護工作量占比；?維護需求表的平均周轉(zhuǎn)時間；?維護活動中增加一條源碼花費的平均人時數(shù)；?維護活動中刪除一條源碼花費的平均人時數(shù)；?按維護的程序、開發(fā)語言和維護類型統(tǒng)計程序變動數(shù)；?維護分類占比。度量的結(jié)果可以作為以后調(diào)整維護工作的參考，對于合源分配、有針對性地強化對參與某類維護的人員的技術作用。2.4.5軟件再生工程對于很久以前開發(fā)的軟件，由于“未采用軟件工程思想”等各種原因，導致文檔缺失，甚至只剩下能運行的軟件系統(tǒng)，這種情況大多考慮進行程思想開發(fā)的軟件，由于文檔相對齊全，則可以進行全部再生。通常，軟件的再生工程包括以下六類活動（可根據(jù)具體情況取舍)》應該著重對以下三類模塊進行考查：(1)確定將使用多年的；(2)正在成功運行的；(3)近期將做重大變更的。2.文檔重構對于早期的軟件，這項活動非常耗費精力，應分輕重緩急分(1)對于相對穩(wěn)定的程序，暫且使其保持現(xiàn)狀；(2)對于當前正在修改的部分建立完整的文檔，其他部分則在使用中逐步建立文檔；(3)對于支撐用戶核心業(yè)務的程序，必須建立完整的文檔，但也最好想方設法地降低建立文檔的工作量。3.逆向工程處理過程的設計信息。4.代碼重構題代碼，經(jīng)過復審和測試生成最終的重構代碼，同時更新有關