软件工程课件

第一章軟體工程

軟體工程概述現代軟體工程第一章軟體工程

軟體工程概述軟體工程的定義軟體工程的目標軟體工程的基本原則軟體工程的作用軟體工程基本流程ERCM第一章軟體工程

軟體工程概述--軟體工程的定義軟體工程(SoftwareEngineering，簡稱為SE)是一門研究用工程化方法構建和維護有效、實用和高質量的軟體的學科。它涉及到程式設計語言，資料庫，軟體開發工具，系統平臺，標準，設計模式等方面。為了解決軟體危機，1968年召開了北大西洋公約組織會議（NATO會議），會議上討論了擺脫軟體危機的辦法，德國人FritzBauer認為：“軟體工程是建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法”。在這次會議上，首次提出了軟體工程的概念。第一章軟體工程

軟體工程概述--軟體工程的目標軟體工程的目標是在付出相對較低的開發成本，給定進度的前提下，按時開發和交付出具有有效性、可靠性、可理解，可維護性、可重用性、可相容性、可適應性、可移植性、可追蹤性、可互操作性、且滿足用戶最終需求的產品。軟體工程的理論和技術性研究的內容主要包括：

⑴軟體開發技術

軟體開發技術包括：軟體開發方法學、開發過程、開發工具和軟體工程環境，其主體內容是軟體開發方法學。

⑵軟體工程管理

軟體工程管理包括：軟體管理學、軟體工程經濟學、軟體心理學等內容。第一章軟體工程

軟體工程概述--軟體工程的基本原則選擇適宜的開發模型採用合適的設計方法高質量的工程支持有效管理軟體工程過程第一章軟體工程

軟體工程概述--軟體工程的作用自從軟體工程概念提出以來，經過30多年的研究與實踐，雖然“軟體危機”沒有得到徹底解決，但在軟體開發方法和技術方面已經有了很大的進步。尤其應該指出的是，自80年代中期，美國工業界和政府部門開始認識到，在軟體開發中，最關鍵的問題是軟體開發組織不能很好地定義和管理其軟體過程，從而使一些好的開發方法和技術都起不到所期望的作用。根據調查，中國的現狀幾乎和美國10多年前的情況一樣，軟體開發過程沒有明確規定，文檔不完整，也不規範，軟體專案的成功往往歸功於軟體開發組的一些傑出個人或小組的努力。這種依賴於個別人員的成功並不能為全組織的軟體生產效率和品質的提高奠定有效的基礎，只有通過建立全組織的過程改善，採用嚴格的軟體工程方法和管理，並且堅持不懈地付諸實踐，才能取得全組織的軟體過程能力的不斷提高。第一章軟體工程

軟體工程概述--軟體工程基本流程ERCMPRD生成階段SPEC設計階段TESTPLAN設計階段TESTCASE設計階段產品代碼CC階段產品ER階段第一章軟體工程

軟體工程概述--軟體工程基本流程ERCMPRD生成階段。PRD（ProductRequirementsDocument）是產品需求文檔，它決定了產品需要做什麼，要實現哪些功能，它對整個專案具有指導作用，是軟體開發的基準。PRD通常由PM（產品經理）根據客戶的實際需求設計完成。PRD在生成階段，EM（工程部經理）、DEV（開發工程師）就會參與進來，閱讀PRD，並且提交發現的問題。QA（QualityAssurance）工程師會在PRD文檔生成之後，參與PRD的閱讀，提交發現的問題；PM會與DEV和QA對問題進行討論，並根據討論結果修改PRD。在PRD審閱完畢後，PM、EM、DEV和QA對產品需求的理解應該是一致的。第一章軟體工程

軟體工程概述--軟體工程基本流程ERCMSPEC設計階段。SPEC（Specification）是產品規格說明書，當PRD確定之後，EM就要根據PRD設計SPEC。在SPEC中，將根據PRD細化客戶的每個需求，詳細設計產品的每個功能，邏輯關係，產品介面風格等。當SPEC設計完之後，PM、DEV、QA必須共同對SPEC進行審閱，從各自的角度檢查SPEC是否有設計不合理的、遺漏的地方，並與EM共同討論，並按照討論結果進行修改。SPEC設計完成後，DEV就要開始根據SPEC設計開發文檔，QA開始進行TestPlan和TestCase的設計。第一章軟體工程

軟體工程概述--軟體工程基本流程ERCMTestPlan設計階段。測試計畫是QA工程師完成的，當SPEC中的內容最終確定之後，QA工程師就要開始制定測試計畫。在這個階段，開發工程師就要開始寫代碼。第一章軟體工程

軟體工程概述--軟體工程基本流程ERCMTestCase設計階段。測試用例同樣也是QA工程師完成的，它也是基於SPEC設計的，和TestPlan幾乎在同一個階段完成。開發工程師在這個階段，需要對自己寫的代碼，進行單元測試。第一章軟體工程

軟體工程概述--軟體工程基本流程ERCM產品代碼CC（CodeComplete）階段。在產品SPEC確定之後，開發工程師就開始寫代碼，到CC階段，就需要完成所有代碼設計，並且完成代碼的單元測試。第一章軟體工程

軟體工程概述--軟體工程基本流程ERCM產品CF（CodeFreeze）階段。當代碼完成之後（CC），測試工程師開始進入測試週期，一般經過兩到三輪測試之後，產品中存在的問題基本上全部被發現，再也找不到比較嚴重的產品缺陷，而且開發工程師把所有找到的產品缺陷修復，就可以達到CF標準。在CF之後，一般情況下，不允許輕易地改動代碼，即使需要改動，也必須經過一定的流程控制，以確保沒有Regression問題出現。第一章軟體工程

軟體工程概述--軟體工程基本流程ERCM產品ER（EngineerRelease）階段。當代碼CF之後，測試工程師需要經過一到兩輪的驗證測試，確定沒有較嚴重的缺陷存在時，產品就可以對外發佈，或與客戶一起進行驗收測試。第一章軟體工程

現代軟體工程開源軟體運動SAAS第一章軟體工程

現代軟體工程--

開源軟體運動典型的開源軟體ＬＡＭＰ（Linux+Apache+MySQL+PHP）開源軟體的特點：日常管理成本最小化易於移植人員組織靈活非正式交流良好的技術支持開發和設計不刻意遵循特定的原則採取獨特的、靈活的方式來解決標準、資源配置和進度安排等問題第二章軟體過程

軟體過程的定義軟體過程(SoftwareProcedure)是指軟體生存週期所涉及的一系列相關過程軟體過程可概括為三類：基本過程類：基本過程類包括獲取過程、供應過程、開發過程、運作過程、維護過程和管理過程。支持過程類：支持過程類包括文檔過程、配置管理過程、品質保證過程、驗證過程、確認過程、聯合評審過程、審計過程以及問題解決過程。組織過程類：組織過程類包括基礎設施過程、改進過程以及培訓過程。第二章軟體過程

軟體生命週期軟體生命週期是指軟體從開發直到報廢的生命週期軟體生命週期分為：計畫階段需求分析階段設計階段編碼階段測試階段運行維護階段第二章軟體過程

軟體過程的模型傳統模型：傳統的軟體過程是目前使用最普通的一種，按照軟體生命週期的先後順利進行，包括獲取、驗證、設計、開發、測試、維護等過程。快速應用開發模型：通過使用基於構件的建造方法獲得快速的應用程式開發。演化模型：演化模型利用的是一種迭代的思想方法。第二章軟體過程

軟體過程管理為確保軟體品質和提高產品競爭力，軟體組織需要規範軟體開發過程，實施軟體過程管理。軟體過程的改進軟體過程改進方法：ISO9000SW-CMMCMMI第三章專案可行性研究

可行性研究的目的與意義軟體專案可行性研究的主要目的是，在投資一個軟體專案之前，對所要開發的專案從技術和經濟的角度進行全面科學的分析與論證。軟體專案可行性研究的意義包括：軟體專案投資決策的基礎與依據軟體專案籌集資金和資源的依據編制每一階段計畫的依據第三章專案可行性研究

可行性研究的內容可行性研究的總體要求可行性研究的內容專案可行性研究分析報告第三章專案可行性研究

可行性研究的內容--可行性研究的總體要求技術可行性對要開發軟體專案的功能、限制條件和技術特點進行分析，確定在現有的資源條件下，專案是否能夠實現。經濟可行性對開發專案的成本以及將獲得的效益進行估算，確定該專案是否值得開發社會可行性應考慮專案是否存在任何侵權、責任等問題，考慮在現有的法規、制度下是否行得通，包括責任、法律和合同等多種因素。第三章專案可行性研究

可行性研究的內容--可行性研究的內容專案可行性研究的主要活動:專案運作的大環境分析專案的未來市場狀況專案的競爭對手的情況專案可行性研究的主要輸入:派遣調研小組進行市場調查開發者總結專案的功能特徵客戶的回饋專案可行性研究的主要輸出:軟體需求說明書制定專案進度表和分配專案開發資源可行性研究報告或工作陳述報告第三章專案可行性研究

可行性研究的內容--專案可行性研究分析報告報告包括如下內容：引言可行性研究的前提對現有系統的分析所建議的系統可選擇的其他系統方案投資及效益分析結論第四章軟體需求分析軟體需求概述軟體需求的三個層次軟體需求的主要內容軟體需求的主要特徵軟體需求的Kano模型第四章軟體需求分析軟體需求概述--軟體需求的三個層次業務需求：反映了組織機構或客戶對系統、產品高層次的目標要求，它們在專案視圖與範圍文檔中予以說明。用戶需求：文檔描述了用戶使用產品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明。功能需求：定義了開發人員必須實現的軟體功能，使得用戶能完成他們的任務，從而滿足了業務需求。第四章軟體需求分析軟體需求各層之間的關係第四章軟體需求分析軟體需求概述--軟體需求的主要內容概述：目的，範圍，縮略語，引用文檔，文檔概述整體說明：產品總體效果，產品功能，用戶特徵等具體需求：功能性需求，可用性需求，可靠性需求，性能需求，可支持性需求，設計約束，用戶文檔與幫助檔需求，需購買的支持組件，介面需求支持資訊：功能需求之外的其他需求第四章軟體需求分析軟體需求概述--軟體需求的主要特徵正確性簡明性無歧義性必要性可行性完全性可驗證性可跟蹤性可分配性涉及獨立性無冗餘性第四章軟體需求分析軟體需求概述--軟體需求的Kano模型軟體需求除了包括功能性需求外，還包括性能、可用性等非功能性需求，為了更好地理解軟體需求這個特點，我們可以借鑒品質管理領域的Kano模型第四章軟體需求分析需求分析的目標與過程需求分析的目標需求分析的過程需求分析方法第四章軟體需求分析需求分析的目標與過程--需求分析的目標軟體需求分析的目標是深入描述軟體的功能和性能，確定軟體設計的約束和軟體同其他系統元素的介面細節，定義軟體的其他有效性需求。需求分析階段研究的對象是軟體專案的用戶要求。一方面，必須全面理解用戶的各項要求，但又不能全盤接受所有的要求，另一方面，要準確地表達被接受的用戶要求。只有經過確切描述的軟體需求才能成為軟體設計的基礎。第四章軟體需求分析需求分析的目標與過程--需求分析的過程需求分析分成以下四個過程：問題識別：系統分析人員要確定對目標系統的綜合要求，即軟體的需求。分析與綜合：問題分析和方案的綜合是需求分析的第二方面的工作。編制需求分析階段文檔：已經確定下來的需求應當得到清晰準確的描述。需求分析評審：作為需求分析階段工作的復查手段，應該對功能的正確性、文檔的一致性、完備性、準確性和清晰性，以及其他需求給予評價。第四章軟體需求分析需求分析的目標與過程--需求分析的原型分析法原型的分類廢棄型追加型或演化型原型的生存期快速分析構造原型運行和評價原型修正和改進判定原型完成判斷原型細部是否說明原型細部的說明判定原型效果整理原型和提供文檔第四章軟體需求分析需求管理需求管理包括在工程進展過程中，維持需求約定集成性和精確性的所有活動。需求管理強調以下幾點：控制對需求基線的變動。保持專案計畫與需求一致。控制單個需求和需求文檔的版本情況。管理需求和聯繫鏈之間的聯繫或管理單個需求和其他專案可交付品之間的依賴關係。跟蹤基線中需求的狀態。第四章軟體需求分析需求管理活動示意圖第五章專案實施的成本效益分析軟體專案實施的成本軟體專案實施成本的相關概念軟體專案實施成本估算的類型與支持工具軟體專案實施成本構成及相應的指標體系軟體專案實施成本估算方法第五章專案實施的成本效益分析軟體專案實施成本的相關概念基本概念與特徵軟體專案的成本是指為實現專案目標所耗用資源的成本總和軟體專案成本的兩大特徵投入的先期性成本的確定性與專案生命週期的關係軟體專案生命週期的基本階段分為概念、開發、實施和收尾四個階段。概念和開發的主要工作是計畫，被稱為專案可行性階段，後兩個階段是開展實際工作，被稱為專案獲取階段。概念階段：做一個前期的大致成本估算專案開發階段：給出準確的成本估算實施階段：給出最終準確的成本估算第五章專案實施的成本效益分析軟體專案生命週期不同階段的成本分析第五章專案實施的成本效益分析軟體專案實施成本估算的類型與支持工具成本估算的類型量級估算：它提供了專案成本的粗略概念，它在專案早期甚至在專案正式開始前應用預算估算：被用來將資金劃入組織的預算最終估算：提供一個精確的專案成本估算，常用於採購決策的制定，因為這些決策需要精確的估算，也常用於估算最終專案成本第五章專案實施的成本效益分析軟體專案實施成本構成及相應的指標體系確定性成本分析固定成本分析無形資產投資(軟體成本)經營成本財務費用風險性成本分析軟體專案人才流失造成的損失

病毒及駭客襲擊造成的損失新技術的發展所導致的硬軟體的更新換代第五章專案實施的成本效益分析專案成本估算典型問題成本的估算是一項複雜的任務，需要巨大的努力。很多估算必須迅速進行，並且要求在明確系統需求前做出。成本的估算沒有足夠多的精確、可靠的數據作為專案估算依據。人們有低估的傾向。如高級資訊技術人員可能以他們自身的能力為基礎做估算，而忘記他的下級也將進行專案工作。估算者也可能忘記考慮大型軟體專案綜合和測試所需要的額外成本。管理者可能要求做估算，但他們真正想要的可能是一個數字，管理者的支持不夠。第五章專案實施的成本效益分析軟體專案實施成本估算方法經驗估算法估算人根據自己的工作經驗和專業知識對成本進行估算，提出一個近似的數字，這其實是一種近似的猜測因素估算法它利用數學知識以過去為根據來預測未來，是比較科學的一種傳統估算方式WBS基即利用WBS方法，先把專案任務進行合理的細分，分到可以確認的程度礎上的全面詳細估算第五章專案實施的成本效益分析軟體專案實施的效益軟體專案實施效益的相關概念軟體專案實施效益指標體系組成軟體專案實施效益分析方法第五章專案實施的成本效益分析軟體專案實施效益的相關概念軟體專案的經濟效益，可以定義為組織在實施軟體專案的過程中所發生的勞動佔用或勞動消耗與產出之間的比較。概括地說就是其投入產出比。對軟體開發方來說，軟體專案的效益是軟體需求方交付的開發款項與開發軟體所投入的所有的人力、非人力總成本之間的比較。對軟體需求方來說軟體專案的效益是軟體開發所提供的款項，以及軟體開發、實施過程中所產生的所有人力、非人力總成本與軟體實施中實際獲得的有形的、無形的、可量化的、不可量化的效益之間的比較。第五章專案實施的成本效益分析軟體專案實施效益的特徵效益的長期性軟體專案的長期性是指組織運用軟體系統後，其經濟效益將表現長期性特點。效益的不確定性實施軟體專案的過程中受到各種風險因素的影響，評估方法、工具等選擇的不同，導致效益估算存在著不確定性。軟體專案實施效益的構成對於軟體開發方來說：產出為軟體需求方交付的軟體開發款項；投入為軟體專案開發的各項成本。對於軟體需求方來說：投入為支付的各項費用；產出為管理成本的降低、庫存的減小、向客戶交貨速度的提高、工作人員的減少、給顧客提供更佳的服務等等。第五章專案實施的成本效益分析軟體專案效益的內容和指標財務收益財務收益是指實施軟體專案帶來的可以用貨幣計量的收益，它可以根據現金流的情況選擇使用收益現值或收益年值進行度量，它所包含的指標一般都是數量指標。戰略效益戰略效益是指實施軟體專案對組織全局和長遠利益所做的貢獻，主要體現為組織市場競爭能力的提高。外部影響組織不僅要追求盈利和發展，還要承擔一定的社會責任。第6章專案計畫與團隊建立制定專案計畫為何要制定專案計畫怎樣設計專案計畫專案計畫設計實例專案計畫修改與維護第6章專案計畫與團隊建立制定專案計畫--為何要制定專案計畫專案計畫在節省時間、節約資金,以及解決其他問題上發揮重要作用軟體專案計畫主要包括：確定詳細的專案實施範圍定義遞交的工作成果評估實施過程中主要的風險制定專案實施的時間計畫 成本和預算計畫人力資源計畫等專案計畫的目標是為專案負責人提供一個框架，使之能合理地估算軟體專案開發所需的資源、經費和開發進度，並控制軟體專案開發過程按此計畫進行第6章專案計畫與團隊建立制定專案計畫--怎樣設計專案計畫（專案計畫包含的內容）引言編寫目的背景專案概述專案目標專案工作內容應交付成果專案開發環境專案驗收方式與依據專案團隊組織組織結構人員分工協作與溝通專案團隊外部溝通與協作模式實施計畫風險評估及對策工作流程總體進度計畫第6章專案計畫與團隊建立制定專案計畫--

專案計畫設計實例以“IBloger博客系統”為例介紹專案計畫與團隊建立第6章專案計畫與團隊建立制定專案計畫--專案計畫修改與維護在專案進行的過程中，可能由於資源、時間的限制以及市場需求的改變，需要對開發的專案做必要的調整，此時，開發計畫也要有相應的改動專案文檔應該由專人進行維護與管理，避免出現多個版本修改時，應該在每一處有改動的地方，做出明顯的標記，並且在版本資訊裏添加索引，方便查閱第6章專案計畫與團隊建立建立專案團隊專案團隊的定義為何要建立專案團隊如何建立和管理專案團隊專案團隊的組織結構第6章專案計畫與團隊建立建立專案團隊--專案團隊的定義專案團隊是指“專案的中心管理小組，由一群人集合而成並被看作是一個組，他們共同承擔專案目標的責任，兼職或者全職地向專案經理進行彙報”。專案團隊不同於一般的群體或組織，它是為實現專案目標而建設的，一種按照團隊模式開展專案工作的組織，是專案人力資源的聚集體。第6章專案計畫與團隊建立建立專案團隊--為何要建立專案團隊任何事情都不可能一個人來完成，尤其對於軟體開發過程來說，需要許多人共同協作來完成一個專案從立項到成功發佈，需要很多部門人員的參與，如果組建一個專案團隊能夠有效地協同工作直接決定了該專案的成功與否第6章專案計畫與團隊建立建立專案團隊--如何建立和管理專案團隊什麼是高效專案團隊明確的目標與共同的價值觀是前提清晰的分工與精誠的協作是關鍵融洽的關係及通暢的溝通是保證高昂的士氣與高效的生產力是標誌如何建立高效專案團隊加強專案團隊領導鼓舞專案團隊士氣提高專案團隊效率第7章面向對象分析與建模面向對象需求分析方法面向對象需求分析的基本過程需求陳述動態模型功能模型定義服務第7章面向對象分析與建模面向對象需求分析方法--面向對象需求分析的基本過程-1概述面向對象的需求分析過程，一般以分析與陳述用戶需求的文檔作為起點。在進行需求分析的過程中，系統分析師需要反復多次與用戶討論、交流，還應該調研現有類似的系統。對目標系統的本質屬性進行抽象，並使用模型表示出來第7章面向對象分析與建模面向對象需求分析方法--面向對象需求分析的基本過程-2三個子模型對象模型、動態模型和功能模型第7章面向對象分析與建模面向對象需求分析方法--面向對象需求分析的基本過程-3模型的五個層次主題層、類與對象層、結構層、屬性層和服務層第7章面向對象分析與建模面向對象需求分析方法--需求陳述需求陳述描述用戶的需求而不是提出解決問題的方法，即闡明“做什麼”而不是“怎樣做”需求描述的內容一般包括：問題範圍，功能需求，性能需求，應用環境及假設條件等需求陳述，應儘量做到表達準確、語法正確需求描述並不是一成不變的文檔，它需要經過全面、深入分析，才能逐步完善、準確、有效第7章面向對象分析與建模面向對象需求分析方法--對象模型確定類與對象確定關聯確定主題確定屬性識別繼承關係反復修改第7章面向對象分析與建模對象模型--確定類與對象類與對象的表示方法確定類與對象的一般步驟找出候選的類與對象篩選出正確的類與對象第7章面向對象分析與建模對象模型--確定關聯關聯是指兩個或多個對象之間的相互依賴、相互作用的關係確定關聯步驟：初步確定關聯篩選進一步完善第7章面向對象分析與建模對象模型--確定主題為了降低複雜度，一般將系統進一步劃分成幾個不同的主題。開發大型複雜的系統過程中需要劃分主題，而對於中小型或業務相對簡單的系統，則無須引入主題層。主題的確定一般根據問題領域進行，並遵循不同主題內的對象相互依賴和交互最少的原則。第7章面向對象分析與建模對象模型--確定屬性

（包括兩個步驟）分析使用名詞片語表示屬性，形容詞表示可枚舉的具體屬性篩選把對象當作屬性把關聯類的屬性當作一般對象的屬性把內部狀態當成了屬性過於細化存在不一致屬性第7章面向對象分析與建模對象模型--識別繼承關係建立繼承關係實質上是知識抽取過程，它反映出一定深度的領域知識。建立繼承關係一般有兩種方式：自底向上：抽象出現有類的共同性質泛化出基類，模擬了歸納思維過程。自頂向下：現有類細化成更具體的子類，模擬了演繹思維過程。需要注意的是，在分析階段應該避免過度細化。第7章面向對象分析與建模對象模型--反復修改軟體開發的過程就是一個反復修改，逐漸完善的過程。修改細化工作是在動態模型和功能模型建立之後才開始的。系統分析師可以合併多個步驟放在一起完成，也可以初步完成幾項工作，再返回來加以完善。第7章面向對象分析與建模面向對象需求分析方法--動態模型建立動態模型主要步驟：編寫典型交互行為的腳本。從腳本中提取出事件，確定觸發每個事件的動作對象以及接受事件的目標對象。排列事件發生的次序，確定每個對象可能有的狀態及狀態間的轉換關係，並用狀態圖描繪它們。比較各個對象的狀態圖，檢查它們之間的一致性，確保事件之間的匹配。第7章面向對象分析與建模面向對象需求分析方法

--功能模型系統中數據之間的依賴關係，以及有關的數據處理功能構成了功能模型，它由一組數據流圖組成。數據流圖的表示方法第7章面向對象分析與建模實踐專案面向對象需求分析UML簡介核心UML模型圖RationalRoseEnterpriseArchitect開始實踐第7章面向對象分析與建模實踐專案面向對象需求分析--UML簡介UML是用來對軟體系統進行可視化建模的一種語言。UML為面向對象開發系統的產品進行說明、可視化、和編制文檔的一種標準語言。UML特點：UML統一了Booch、OMT和OOSE等方法中的基本概念。UML吸取了面向對象技術領域中其他流派的長處，也包括非OO方法的影響。UML在演變過程中還提出了一些新的概念。第7章面向對象分析與建模實踐專案面向對象需求分析--核心UML模型圖用例圖類圖包和對象圖順序圖協作圖狀態圖活動圖組件與配置圖第7章面向對象分析與建模核心UML模型圖--用例圖用例圖（UseCaseDiagram）描述了作為一個外部的觀察者的視角對系統的印象；強調的是這個系統是什麼而不是這個系統怎麼工作。第7章面向對象分析與建模核心UML模型圖--類圖類圖（ClassDiagram）通過系統的類以及這些類之間的關係來表示系統。類的實現關係圖第7章面向對象分析與建模核心UML模型圖--包和對象圖為了簡單地表示出複雜的類圖，可以把類組合成包（Packages）。包圖實例第7章面向對象分析與建模核心UML模型圖--順序圖按時間順序對控制流建模，說明系統的動態視圖，強調時間和順序。順序圖實例第7章面向對象分析與建模核心UML模型圖--協作圖協作圖也是互動的圖表，展現了一組對象及相互間的連接及這組對象收發的消息。強調上下層次關係強調收發消息對象結構組織，按組織結構對控制流建模。在序列圖中，對象的角色放在上面而消息則是連接線。協作圖的每個消息都有一個序列號。頂層消息的數字是1。同一個等級的消息有同樣的數字首碼，再根據他們出現的順序增加一個尾碼1，2等等。第7章面向對象分析與建模核心UML模型圖--狀態圖狀態圖展示了一個特定對象的所有可能狀態及由於各種事件發生而引起的狀態間轉移。狀態圖實例第7章面向對象分析與建模核心UML模型圖--活動圖活動圖是一種特殊的狀態圖，描述需要做的活動、執行這些活動的順序、工作流。活動圖實例第7章面向對象分析與建模核心UML模型圖--組件與配置圖配置圖展現了運行時處理節點及其構件的部署。它描述系統硬體的物理拓撲結構及在此結構上執行的軟體，它說明系統結構的靜態部署視圖，即說明發佈、交付和安裝的物理系統。組件是代碼模組，組件圖是是類圖的物理實現。

第7章面向對象分析與建模建模工具RationalRose是Rational公司的一種面向對象的統一建模語言UML的可視化建模工具，用於可視化建模和公司級水準軟體應用的組件構造。EnterpriseArchitectEnterpriseArchitect(簡稱EA)，是由SparxSystemsPtyLtd.開發的一套UML設計軟體。第8章總體設計軟體設計應遵循的基本原理抽象逐步細化模組化模組獨立性資訊隱藏第8章總體設計總體設計的過程明確系統的目的，劃分出系統的主要功能。約定系統的開發與運行環境，這將影響著系統以何種方式開發。設計系統的總體結構設計系統的功能模組數據結構和數據庫設計軟體系統的總體指標匯總設計資訊、撰寫總體設計文檔評審總體設計第8章總體設計軟體設計原則多樣化設計設計可回溯到需求充分利用已有的模組設計應該表現出一致性和規範性設計的易修改性容錯性設計設計的粒度要適當在設計時就要開始評估軟體的品質設計評審第8章總體設計總體設計的圖形描述工具-層次圖第8章總體設計總體設計的圖形描述工具-HIPO圖第8章總體設計總體設計的圖形描述工具-結構圖第9章詳細設計詳細設計階段應遵循下列原則：

模組的邏輯描述正確可靠、清晰易讀

設計過程中應採用逐步細化的實現方法第9章詳細設計結構程式設計在總體設計階段採用自頂向下逐步求精的設計方法，可以把一個複雜問題分解細化為為一個由若干模組組成的層次結構的軟體系統;在詳細設計階段採用自頂向下逐步求精的設計方法,可以把一個模組的功能逐步分解和細化為一系列具體的處理步驟或某種高級語言的語句。第9章詳細設計控制結構第9章詳細設計詳細設計描述工具程式流程圖盒圖（N-S圖）PAD圖判定表判定樹過程設計語言（PDL）第10章編碼實現編碼概述

編碼語言的選擇ASP.NETMVC簡述ADO.NETEntityFramework簡述第10章編碼實現ASP.NETMVC、EntityFramework專案實踐

準備工作創建介面建立數據持久化層建立DAO層業務邏輯層創建Controller控制器類Web頁面配置URL路由web.config檔配置其他擴展第11章專案測試測試計畫的制定

為何要制定測試計畫如何制定測試計畫測試計畫設計實例測試計畫修改與維護第11章專案測試測試計畫的制定--為何要制定測試計畫可以讓專案有條理有計畫的進行。可以提前預知專案過程中可能出現的問題。有助於專案人員更好的理解這個專案內容，明確測試的目標，測試範圍和測試重點。參與測試的專案成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的可能出現的各種變更。第11章專案測試測試計畫的制定--如何制定測試計畫

產品基本情況調研測試需求說明時間計畫表測試資源配置系統風險估計測試的策略和記錄問題跟蹤報告測試計畫的發佈第11章專案測試測試計畫的制定--測試計畫設計實例以“IBloger博客系統”為例，詳細介紹測試設計的內容和書寫格式第11章專案測試測試計畫的制定--測試計畫修改與維護在專案進行的過程中，由於資源，時間的限制，以及市場需求的改變，需要對開發的專案做必要的調整，此時，測試計畫也要有相應的改動。文檔應該由一個人維護或者把文檔統一存放於類似CVS的工具裏。修改文檔時，應該在每一處有改動的地方，做出明顯的標記，並且在版本資訊裏添加索引，方便查找。第11章專案測試單元測試分析單元測試的任務設計單元測試用例選擇單元測試工具執行單元測試第11章專案測試單元測試--分析單元測試的任務測試函數的基本功能是否正確。

測試函數的入口的邊界值。在邊界值出現錯誤是軟體開發中的常見錯誤。軟體經常在邊界上失效，採用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。測試函數的異常。我們知道Java中經常有異常，當遇到異常時，應當處理異常。如果不處理異常，有時候會產生嚴重的後果以至於伺服器死機。第11章專案測試單元測試--設計單元測試用例單元測試用例一般根據源代碼進行設計。單元測試用例要覆蓋到每個類，每個類的方法，每個方法的邊界值。第11章專案測試集成測試分析集成測試的任務和目標設計集成測試用例選擇集成測試工具執行集成測試集成測試報告第11章專案測試集成測試--分析集成測試的任務和目標集成測試的任務是確保各單元組合在一起後能夠按既定意圖協作運行，並確保增量的行為正確。集成測試的內容包括單元間的介面以及集成後的功能。第11章專案測試IBloger博客系統的集成測試確定哪些單元模組之間存在數據的存在介面第11章專案測試集成測試--設計集成測試用例集成測試用例的設計必須基於集成測試的任務和目標，覆蓋所有需要測試的介面，保證單元之間、多個單元之間、乃至整個系統能夠正常、正確的運行測試用例的編寫分為三步：劃分測試模組繪製測試流程圖設計詳細的測試用例第11章專案測試集成測試--選擇集成測試工具為了能更有效的執行集成測試，在測試過程中經常需要借助一些工具分析工具主要是用於捕捉訪問日誌、數據。然後通過對數據、日誌進行分析，找到缺陷的根本原因，發現測試中無法發現的缺陷測試工具測試工具主要用來設計自動化測試腳本、進行自動化測試第11章專案測試集成測試--執行集成測試測試用例設計完成後，就可以按照測試計畫執行集成測試。在執行集成測試的過程中，各個角色負責的內容不一樣：專案負責人測試工程師開發專案經理產品經理第11章專案測試集成測試--集成測試報告集成測試完成後，測試工程師需要提交自己測試任務的狀態：功能的運行情況、存在的問題、沒有測試的部分、以及沒有測試的理由。專案負責人搜集所有的測試任務狀態，編寫測試報告，提交給專案經理，或者產品經理。第11章專案測試確認測試分析確認測試的任務和目標設計確認測試用例選擇確認測試工具執行確認測試用例確認測試報告第11章專案測試確認測試--分析確認測試的任務和目標確認測試是驗證被測軟體是否能完全滿足需求規格說明書所列出的需求第11章專案測試確認測試--設計確認測試用例以“IBloger博客系統”為例設計測試用例第11章專案測試確認測試--選擇確認測試工具Badboy是一個強大的開源測試工具，是用C++開發的，被設計用於測試和開發複雜的動態應用。Badboy功能豐富，使得測試和開發更加容易。Badboy監控internetexplorer的活動，提供錄製/回放功能。第11章專案測試確認測試--執行確認測試用例以Badboy來做確認測試的工具以IBloger博客系統系統為例編寫測試腳本和測試第11章專案測試確認測試--確認測試報告根據確認測試結果，編寫測試報告第11章專案測試系統測試分析系統測試的任務和目標設計系統測試用例利用JMeter進行系統測試實例系統測試報告第11章專案測試系統測試--分析系統測試的任務和目標系統測試的任務系統測試的目的是充分運行系統，驗證系統各部件是否都能正常工作並完成所賦予的任務。這裏所謂的系統不僅僅包括軟體本身，而且還包括電腦硬體及其相關的週邊設備、實際運行時大批量數據、非正常操作(如駭客攻擊)等。系統測試的目標系統測試的目標是模仿客戶真實的使用環境，發現一切可能的情況下所可能發生的問題。是軟體測試的不可缺少的一個階段，隨著軟體品質要求的不斷提高，系統測試也更加的重要了。第11章專案測試系統測試--設計系統測試用例壓力測試壓力測試是模擬實際應用的軟硬體環境，以及用戶使用過程的系統負荷，長時間或超大負荷地運行測試軟體，來測試被測系統的性能、可靠性、穩定性等。容量測試通過測試預先分析軟體系統應用特徵的某項指標的極限值（如最大併發用戶數、資料庫記錄數等），系統在其極限值狀態下沒有出現任何軟體故障或還能保持主要功能正常運行。性能測試通過測試確定系統運行時的性能表現，如得到運行速度、回應時間、佔有系統資源等方面的系統數據。安全性測試檢查系統對非法侵入的防範能力，目前也是軟體測試中較重視的部分。相容性測試檢查產品和硬體軟體之間的相容性。第11章專案測試系統測試--利用JMeter進行系統測試以“IBloger博客系統”為例，介紹如何使用JMeter做壓力測試第11章專案測試系統測試--系統測試報告以“大學學籍管理系統”為例,編寫系統測試報告第11章專案測試驗收測試制訂專案驗收標準設計驗收測試用例執行驗收測試編寫驗收品質報告第11章專案測試驗收測試--制訂專案驗收標準功能和非功能標準確定具體的客戶任務，商業流程，或者專案結束時必須有的功能。問題或缺陷定義哪些缺陷是可接受的。性能由於很難衡量性能的品質，通常用回應時間來進行衡量。所希望的性能要求應該被清晰的定義成一個範圍，例如客戶登錄時間在1-2s內。第11章專案測試驗收測試--設計驗收測試用例驗收測試環境驗收測試是在客戶參與下的測試，一般都是在客戶的現場環境中進行。驗收策略正式驗收非正式驗收或Alpha（α）測試Beta（β）測試設計驗收測試用例以“IBloger博客系統”編寫驗收測試用例第12章軟體工程專案管理軟體專案管理簡介什麼是專案專案就是為創造獨特的產品、服務或結果而進行的臨時性事情什麼是軟體專案管理通過合理地組織和利用一切可以利用的資源，按照計畫的成本和進度，完成一個計畫的目標。軟體專案管理的特點軟體產品是無形的；沒有統一的標準；專案管理需要集權領導和建立專門的專案組織；專案負責人在專案管理中起著非常重要的作用。軟體專案管理的主要職能制定計畫、建立組織、配備人員、指導、檢驗軟體專案管理活動提出專案建議書；規劃與進度；成本管理；專案監督和評審；人員管理；擬定工作報告第12章軟體工程專案管理專案計畫和組織專案計畫的制定專案成員的組織和管理

第12章軟體工程專案管理專案計畫和組織--專案計畫的制定制定專案計畫的步驟明確目標制定專案工作範圍在專案組內分配任務職責統籌規劃專案間活動的關聯制定專案計畫的原則制定一份能夠獲得批准、總體結構準確且具有指導意義的專案計畫書短期計畫和長期計畫相結合專案計畫的確定可以採用目標管理法制定專案計畫的工具工作分解結構：將專案的“交付物”自頂向下逐層分解成易於管理的若干元素，以此結構化地組織和定義了專案的工作範圍。責任分配矩陣表：責任分配矩陣是以表格形式表示完