1、讀軟件工程案例教程有感對于學習軟件工程這門課程，我認為有許多東西要學習。其實在我看來學習這門課程的精髓是學習一種方法。是一個如何去分析和處理問題的過程，應該說其范疇已經(jīng)遠遠不止局限于該門課程，成為了一個綜合的一個能夠解決問題的思想集合。讀完軟件工程案例教程這本書，我覺得自己受益匪淺。整本書的內(nèi)容邏輯很清晰明了，由淺入深循序漸進，首先我就大概描述下我們所學的內(nèi)容，第一章是從整體分析軟件工程這門學科的發(fā)展和所處的社會環(huán)境，接著后面的幾章深入分析了軟件開放過程和模式、軟件項目管理、計算機工程、需求分析、結(jié)構(gòu)化分析建模以及基于UML面向?qū)ο蠓治鼋：蜏y試等。對于這本書我主要對需求分析和測試比較感興趣，

2、在這我要著重的談一些自己的心得體會以及自己的看法。1 需求分析 1.1需求分析的重要性一款成功的軟件是建立在成功的需求分析之上的，而高質(zhì)量的需求來源于用戶與開發(fā)人員之間有效的溝通與合作。當用戶有一個問題可以用計算機系統(tǒng)來解決，而開發(fā)人員開始幫助用戶解決這個問題，溝通就開始了。由此我們可以看出需求分析的重要性。需求獲取可能是最困難、最關鍵、最易出錯及最需要溝通交流的活動。對需求的獲取往往有錯誤的認識：用戶知道需求是什么，我們所要做的就是和他們交談從他們那里得到需求，只要問用戶系統(tǒng)的目標特征，什么是要完成的，什么樣的系統(tǒng)能適合商業(yè)需要就可以了，但是實際上需求獲取并不是想象的這樣簡單，這條溝通之路布

3、滿了荊棘。首先需求獲取要定義問題范圍，系統(tǒng)的邊界往往是很難明確的，用戶不了解技術實現(xiàn)的細節(jié)，這樣造成了系統(tǒng)目標的混淆。 其次是對問題的理解，用戶對計算機系統(tǒng)的能力和限制缺乏了解，任何一個系統(tǒng)都會有很多的用戶或者不同類型的用戶，每個用戶只知道自己需要的系統(tǒng)，而不知道系統(tǒng)的整體情況，他們不知道系統(tǒng)作為一個整體怎么樣工作效率更好，也不太清楚那些工作可以交給軟件完成，他們不清楚需求是什么，或者說如何以一種精確的方式來描述需求，他們需要開發(fā)人員的協(xié)助和指導，但是用戶與開發(fā)人員之間的交流很容易出現(xiàn)障礙，忽略了那些被認為是很明顯的信息。最后是需求的確認，因為需求的不穩(wěn)定性往往隨著時間的推移產(chǎn)生變動，使之難以

4、確認。為了克服以上的問題，必須有組織的執(zhí)行需求的獲取活動。1.2需求分析的原則（1） 需求分析必須能夠表達和理解問題的數(shù)據(jù)域和功能域。數(shù)據(jù)域包括數(shù)據(jù)流、數(shù)據(jù)內(nèi)容和數(shù)據(jù)結(jié)構(gòu)，而功能域反映上述 3 方面的控制信息。（2）需求分析要把一個復雜問題按功能進行分解并逐層細化。通常，軟件系統(tǒng)要處理的問題如果太大、太復雜就很難理解，若劃分成幾部分，并確定各部分間的接口，就可完成整體的功能。在需求分析過程中，軟件系統(tǒng)的用戶需求中的數(shù)據(jù)、功能和行為都應細化。（3）需求建模。模型可以幫助系統(tǒng)分析人員更好地理解軟件系統(tǒng)的數(shù)據(jù)、功能和行為，這些模型是軟件工程中下一階段進行系統(tǒng)設計的基礎。1.3需求分析的注意事項（1）

5、確定詳細的需求，否則經(jīng)費就算不準。經(jīng)費估計錯誤的原因多為：用戶需求頻繁變動、遺漏重要需求、與用戶交流不夠、需求規(guī)格說明書質(zhì)量低劣、需求分析不充分等。（2）在編寫需求規(guī)格說明書之前，應明確要解決的問題。在試圖解決問題之前，要保證已考察了全部可替代的方案。要搞清哪地方有問題，真正的問題出在哪里。這樣，在編寫需求規(guī)格說明書時做到有的放矢，把存在的問題暴露出來。（3）立即確定需求，并記錄下該需求的背景。沒有明確問題，就進行下一步的設計，想回避矛盾，可能會帶來更大的問題。用戶不確定需求，軟件設計人員自己決定需求，將會帶來嚴重的問題。為了避免將來可能出現(xiàn)的問題和軟件工程項目能夠盡快地進入到下一個階段的系統(tǒng)

6、設計中，要盡可能迅速地把用戶需求確定下來。任何決定總比沒有決定要好。（4）一旦在需求規(guī)格說明書中發(fā)現(xiàn)問題，立即改正。如果把存在的問題拖延到系統(tǒng)設計階段去改正，就可能要花數(shù)倍的時間和精力才能糾正同一錯誤。（5）在眾多用戶需求中確定各個需求的優(yōu)先順序，并確定可能存在的子集，以便為軟件設計、實施和項目管理等后續(xù)階段提供有利條件。（6）需求分析時，不要進行系統(tǒng)設計的工作。需求分析的主要目的是確定軟件系統(tǒng)的外部特征，充分反映軟件系統(tǒng)應有的面貌，便于讓軟件設計人員根據(jù)用戶需求，去全面地考慮軟件系統(tǒng)的體系結(jié)構(gòu)、算法等。在需求分析階段要集中精力解決用戶需求存在的問題，盡可能避免產(chǎn)生遺留問題。（7）對于復雜的軟

7、件系統(tǒng)，要從多種視角進行需求分析。根據(jù)軟件系統(tǒng)的本質(zhì)，切合實際地組織多種視角的需求。例如，可從根據(jù)用戶的類型，或根據(jù)響應的類型，或根據(jù)對象的軟件工程案例教程類型，或根據(jù)系統(tǒng)的模式等視角來組織用戶需求。通過多個視角來研究用戶需求問題，把可得到的不同的“投影”組合起來形成完整系統(tǒng)的描述。當試圖從整體觀點來描述軟件系統(tǒng)發(fā)生困難，或者有可能發(fā)生錯誤，或者很有可能遺失軟件系統(tǒng)的某些特性。而從不同的視角來描述軟件系統(tǒng)，因為每個視角限制了研究的范圍并能夠?qū)⒆⒁饬杏诖?，所以很容易保證所研究的問題是真正完整的。（8）重視形式化方法，但不放棄自然語言。為了用戶需求表達的精確性和方便用戶的可理解性，一個好方法是

8、把自然語言的表達與形式化規(guī)格說明并立，互相對照，而且在一般情況下，先用自然語言寫出，再給出它的形式模型。（9）用戶需求中不應存在“待確定”的條款。如若有這種需要，應同時說明：何時由誰來解決該問題。1.4用戶需求的類型需求分析是從用戶最初的非形式化需求到滿足用戶要求的軟件產(chǎn)品的映射過程。它實際上是一個對用戶意圖不斷進行揭示和判斷的過程，其目的在于細化、精化軟件的作用范圍，確定擬開發(fā)軟件的功能和性能、約束、環(huán)境等?？蓪⒂脩舻男枨蠓譃閮纱箢悾汗δ苄孕枨蠛头枪δ苄孕枨?。（1）功能性需求。功能性需求主要說明了系統(tǒng)各功能部件與環(huán)境之間的相互作用的本質(zhì)，即擬開發(fā)軟件在職能上實際應做到什么。一般來說，它是用戶

9、最主要的需求，通常包括系統(tǒng)的輸入、系統(tǒng)能完成的功能、系統(tǒng)的輸出以及其他反應。在功能性需求中還應包括備選功能的定義識別。（2）非功能性需求。非功能性要求主要從各個角度對所考慮的可能的解決方案起約束和限制作用。1.5需求分析的方法在軟件工程中，常用的需求分析方法有面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（簡稱 SA）和面向?qū)ο蟮姆治龇椒ǎê喎Q OOA）。此外，還有以用戶為中心的需求分析方法。這些方法都采用圖文結(jié)合的方式，可以直觀地描述軟件的邏輯模型。這里僅介紹結(jié)構(gòu)化分析方法和以用戶為中心的需求分析方法。2. 軟件測試2.1軟件測試概述軟件本身無形態(tài)，它是復雜的知識高度密集的邏輯產(chǎn)品，其中不可能沒有錯誤。軟件實施

10、工程過程中必須伴隨著軟件質(zhì)量保證的活動，而軟件測試是主要活動之一。在開發(fā)軟件的過程中，人們使用了許多保證軟件質(zhì)量的方法分析、設計和實現(xiàn)軟件，但難免還會在工作中犯錯誤。這樣，在軟件產(chǎn)品中就會隱藏許多錯誤和缺陷。對于規(guī)模大、復雜性高的軟件更是如此。在這些錯誤中，有些是致命的錯誤，如果不排除，就會導致生命與財產(chǎn)的重大損失。2.2軟件測試的目的測試的目的是“說明程序能正確地執(zhí)行應有的功能”，還是“表明程序沒有錯誤”？基于不同的立場，存在著兩種完全不同的測試目的。從用戶的角度出發(fā)，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可以接受該產(chǎn)品。而從軟件開發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)

11、品中不存在錯誤的過程，驗證該軟件已正確地實現(xiàn)了用戶的要求，確立人們對軟件質(zhì)量的信心。因此，他們會選擇那些導致程效概率小的測試用例，回避那些易于暴露程序錯誤的測試用例。同時，也不會刻意去檢測、排除程序中可能包含的副作用。顯然，這樣的測試對完善和提高軟件質(zhì)量毫無價值。因為在程序中往往存在著許多預料不到的問題，可能會被疏漏，許多隱藏的錯誤只有在特定的環(huán)境下才可能暴露出來。如果不把著眼點放在盡可能查找錯誤這樣一個基礎上，這些隱藏的錯誤和缺陷就查不出來，會遺留到運行階段中去。如果站在用戶的角度，替他們設想，就應當把測試活動的目標對準揭露程序中存在的錯誤。在選取測試用例時，考慮那些易于發(fā)現(xiàn)程序錯誤的數(shù)據(jù)。

12、2.3軟件測試的原則（1）應當把“盡早地和不斷地進行軟件測試”作為軟件開發(fā)者的座右銘。由于原始問題的復雜性、軟件的復雜性和抽象性、軟件開發(fā)各個階段工作的多樣性，以及參加開發(fā)各種層次人員之間工作的配合關系等因素，使得開發(fā)的每個環(huán)節(jié)都可能產(chǎn)生錯誤。所以不應把軟件測試僅僅看成是軟件開發(fā)的一個獨立階段，而應當把它貫穿到軟件開發(fā)的各個階段中。在需求分析階段就應該制訂測試計劃，以保證每個需求，每個設計單元都是可測試的，便于測試。堅持在軟件開發(fā)的各個階段的技術評審，這樣才能在開發(fā)過程中盡早發(fā)現(xiàn)和預防錯誤，把出現(xiàn)的錯誤克服在早期，杜絕某些隱患，提高軟件質(zhì)量。 （2）測試用例應由測試輸入數(shù)據(jù)和與之對應的預期輸出

13、結(jié)果這兩部分組成。測試以前應當根據(jù)測試的要求，選擇在測試過程中使用的測試用例（Test Case）。測試用例主要用來檢驗程序員編制的程序，因此不但需要測試的輸入數(shù)據(jù)，而且需要針對這些輸入數(shù)據(jù)的預期輸出結(jié)果。如果對測試輸入數(shù)據(jù)沒有給出預期的程序輸出結(jié)果，那么就缺少了檢驗實測結(jié)果的基準，就有可能把一個似是而非的錯誤結(jié)果當成正確結(jié)果。 （3）程序員應避免檢查自己的程序。測試工作需要嚴格的作風、客觀的態(tài)度和冷靜的情緒。自己測試自己的軟件不容易發(fā)現(xiàn)錯誤，程序員應避免測試自己的程序。測試是一種“挑剔性”的行為，人們常常由于各種原因具有一種不愿否定自己工作的心理，認為揭露自己程序中的問題總不是一件愉快的事，

14、這一心理狀態(tài)就成為測試自己程序的障礙。心理狀態(tài)和思維定式是測試自己程序的兩大障礙，應由別人或另外的機構(gòu)來測試程序員編寫的程序。另外，程序員對軟件規(guī)格說明理解錯誤而引入的錯誤則更難發(fā)現(xiàn)。如果由別人來測試程序員編寫的程序，可能會更客觀、更有效，并更容易取得成功。要注意的是，這點不能與程序的調(diào)試（Debugging）互相混淆，調(diào)試由程序員自己來做可能更有效。 （4）在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗證程序正確的輸入條件，而不合理的輸入條件是指異常的、臨界的、可能引起問題變異的輸入條件。在測試程序時，人們常常傾向于過多地考慮合法的和期望的輸入條件，以檢查程序是否做了它應該做的事情，而忽視了不合法的和預想不到的輸入條件。事實上，軟件在投入運行以后，用戶的使用往往不遵循事先的約定，使用了