軟件工程課件

第一章軟體工程

軟體工程概述現(xiàn)代軟體工程第一章軟體工程

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

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

軟體工程概述--軟體工程的目標(biāo)軟體工程的目標(biāo)是在付出相對(duì)較低的開發(fā)成本，給定進(jìn)度的前提下，按時(shí)開發(fā)和交付出具有有效性、可靠性、可理解，可維護(hù)性、可重用性、可相容性、可適應(yīng)性、可移植性、可追蹤性、可互操作性、且滿足用戶最終需求的產(chǎn)品。軟體工程的理論和技術(shù)性研究的內(nèi)容主要包括：

⑴軟體開發(fā)技術(shù)

軟體開發(fā)技術(shù)包括：軟體開發(fā)方法學(xué)、開發(fā)過程、開發(fā)工具和軟體工程環(huán)境，其主體內(nèi)容是軟體開發(fā)方法學(xué)。

⑵軟體工程管理

軟體工程管理包括：軟體管理學(xué)、軟體工程經(jīng)濟(jì)學(xué)、軟體心理學(xué)等內(nèi)容。第一章軟體工程

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

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

軟體工程概述--軟體工程基本流程ERCMPRD生成階段SPEC設(shè)計(jì)階段TESTPLAN設(shè)計(jì)階段TESTCASE設(shè)計(jì)階段產(chǎn)品代碼CC階段產(chǎn)品ER階段第一章軟體工程

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

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

軟體工程概述--軟體工程基本流程ERCMTestPlan設(shè)計(jì)階段。測(cè)試計(jì)畫是QA工程師完成的，當(dāng)SPEC中的內(nèi)容最終確定之後，QA工程師就要開始制定測(cè)試計(jì)畫。在這個(gè)階段，開發(fā)工程師就要開始寫代碼。第一章軟體工程

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

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

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

軟體工程概述--軟體工程基本流程ERCM產(chǎn)品ER（EngineerRelease）階段。當(dāng)代碼CF之後，測(cè)試工程師需要經(jīng)過一到兩輪的驗(yàn)證測(cè)試，確定沒有較嚴(yán)重的缺陷存在時(shí)，產(chǎn)品就可以對(duì)外發(fā)佈，或與客戶一起進(jìn)行驗(yàn)收測(cè)試。第一章軟體工程

現(xiàn)代軟體工程開源軟體運(yùn)動(dòng)SAAS第一章軟體工程

現(xiàn)代軟體工程--

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

軟體過程的定義軟體過程(SoftwareProcedure)是指軟體生存週期所涉及的一系列相關(guān)過程軟體過程可概括為三類：基本過程類：基本過程類包括獲取過程、供應(yīng)過程、開發(fā)過程、運(yùn)作過程、維護(hù)過程和管理過程。支持過程類：支持過程類包括文檔過程、配置管理過程、品質(zhì)保證過程、驗(yàn)證過程、確認(rèn)過程、聯(lián)合評(píng)審過程、審計(jì)過程以及問題解決過程。組織過程類：組織過程類包括基礎(chǔ)設(shè)施過程、改進(jìn)過程以及培訓(xùn)過程。第二章軟體過程

軟體生命週期軟體生命週期是指軟體從開發(fā)直到報(bào)廢的生命週期軟體生命週期分為：計(jì)畫階段需求分析階段設(shè)計(jì)階段編碼階段測(cè)試階段運(yùn)行維護(hù)階段第二章軟體過程

軟體過程的模型傳統(tǒng)模型：傳統(tǒng)的軟體過程是目前使用最普通的一種，按照軟體生命週期的先後順利進(jìn)行，包括獲取、驗(yàn)證、設(shè)計(jì)、開發(fā)、測(cè)試、維護(hù)等過程?？焖賾?yīng)用開發(fā)模型：通過使用基於構(gòu)件的建造方法獲得快速的應(yīng)用程式開發(fā)。演化模型：演化模型利用的是一種迭代的思想方法。第二章軟體過程

軟體過程管理為確保軟體品質(zhì)和提高產(chǎn)品競(jìng)爭(zhēng)力，軟體組織需要規(guī)範(fàn)軟體開發(fā)過程，實(shí)施軟體過程管理。軟體過程的改進(jìn)軟體過程改進(jìn)方法：ISO9000SW-CMMCMMI第三章專案可行性研究

可行性研究的目的與意義軟體專案可行性研究的主要目的是，在投資一個(gè)軟體專案之前，對(duì)所要開發(fā)的專案從技術(shù)和經(jīng)濟(jì)的角度進(jìn)行全面科學(xué)的分析與論證。軟體專案可行性研究的意義包括：軟體專案投資決策的基礎(chǔ)與依據(jù)軟體專案籌集資金和資源的依據(jù)編制每一階段計(jì)畫的依據(jù)第三章專案可行性研究

可行性研究的內(nèi)容可行性研究的總體要求可行性研究的內(nèi)容專案可行性研究分析報(bào)告第三章專案可行性研究

可行性研究的內(nèi)容--可行性研究的總體要求技術(shù)可行性對(duì)要開發(fā)軟體專案的功能、限制條件和技術(shù)特點(diǎn)進(jìn)行分析，確定在現(xiàn)有的資源條件下，專案是否能夠?qū)崿F(xiàn)。經(jīng)濟(jì)可行性對(duì)開發(fā)專案的成本以及將獲得的效益進(jìn)行估算，確定該專案是否值得開發(fā)社會(huì)可行性應(yīng)考慮專案是否存在任何侵權(quán)、責(zé)任等問題，考慮在現(xiàn)有的法規(guī)、制度下是否行得通，包括責(zé)任、法律和合同等多種因素。第三章專案可行性研究

可行性研究的內(nèi)容--可行性研究的內(nèi)容專案可行性研究的主要活動(dòng):專案運(yùn)作的大環(huán)境分析專案的未來市場(chǎng)狀況專案的競(jìng)爭(zhēng)對(duì)手的情況專案可行性研究的主要輸入:派遣調(diào)研小組進(jìn)行市場(chǎng)調(diào)查開發(fā)者總結(jié)專案的功能特徵客戶的回饋專案可行性研究的主要輸出:軟體需求說明書制定專案進(jìn)度表和分配專案開發(fā)資源可行性研究報(bào)告或工作陳述報(bào)告第三章專案可行性研究

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

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

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

（包括兩個(gè)步驟）分析使用名詞片語表示屬性，形容詞表示可枚舉的具體屬性篩選把對(duì)象當(dāng)作屬性把關(guān)聯(lián)類的屬性當(dāng)作一般對(duì)象的屬性把內(nèi)部狀態(tài)當(dāng)成了屬性過於細(xì)化存在不一致屬性第7章面向?qū)ο蠓治雠c建模對(duì)象模型--識(shí)別繼承關(guān)係建立繼承關(guān)係實(shí)質(zhì)上是知識(shí)抽取過程，它反映出一定深度的領(lǐng)域知識(shí)。建立繼承關(guān)係一般有兩種方式：自底向上：抽象出現(xiàn)有類的共同性質(zhì)泛化出基類，模擬了歸納思維過程。自頂向下：現(xiàn)有類細(xì)化成更具體的子類，模擬了演繹思維過程。需要注意的是，在分析階段應(yīng)該避免過度細(xì)化。第7章面向?qū)ο蠓治雠c建模對(duì)象模型--反復(fù)修改軟體開發(fā)的過程就是一個(gè)反復(fù)修改，逐漸完善的過程。修改細(xì)化工作是在動(dòng)態(tài)模型和功能模型建立之後才開始的。系統(tǒng)分析師可以合併多個(gè)步驟放在一起完成，也可以初步完成幾項(xiàng)工作，再返回來加以完善。第7章面向?qū)ο蠓治雠c建模面向?qū)ο笮枨蠓治龇椒?-動(dòng)態(tài)模型建立動(dòng)態(tài)模型主要步驟：編寫典型交互行為的腳本。從腳本中提取出事件，確定觸發(fā)每個(gè)事件的動(dòng)作對(duì)象以及接受事件的目標(biāo)對(duì)象。排列事件發(fā)生的次序，確定每個(gè)對(duì)象可能有的狀態(tài)及狀態(tài)間的轉(zhuǎn)換關(guān)係，並用狀態(tài)圖描繪它們。比較各個(gè)對(duì)象的狀態(tài)圖，檢查它們之間的一致性，確保事件之間的匹配。第7章面向?qū)ο蠓治雠c建模面向?qū)ο笮枨蠓治龇椒?/p>

--功能模型系統(tǒng)中數(shù)據(jù)之間的依賴關(guān)係，以及有關(guān)的數(shù)據(jù)處理功能構(gòu)成了功能模型，它由一組數(shù)據(jù)流圖組成。數(shù)據(jù)流圖的表示方法第7章面向?qū)ο蠓治雠c建模實(shí)踐專案面向?qū)ο笮枨蠓治鯱ML簡(jiǎn)介核心UML模型圖RationalRoseEnterpriseArchitect開始實(shí)踐第7章面向?qū)ο蠓治雠c建模實(shí)踐專案面向?qū)ο笮枨蠓治?-UML簡(jiǎn)介UML是用來對(duì)軟體系統(tǒng)進(jìn)行可視化建模的一種語言。UML為面向?qū)ο箝_發(fā)系統(tǒng)的產(chǎn)品進(jìn)行說明、可視化、和編制文檔的一種標(biāo)準(zhǔn)語言。UML特點(diǎn)：UML統(tǒng)一了Booch、OMT和OOSE等方法中的基本概念。UML吸取了面向?qū)ο蠹夹g(shù)領(lǐng)域中其他流派的長處，也包括非OO方法的影響。UML在演變過程中還提出了一些新的概念。第7章面向?qū)ο蠓治雠c建模實(shí)踐專案面向?qū)ο笮枨蠓治?-核心UML模型圖用例圖類圖包和對(duì)象圖順序圖協(xié)作圖狀態(tài)圖活動(dòng)圖組件與配置圖第7章面向?qū)ο蠓治雠c建模核心UML模型圖--用例圖用例圖（UseCaseDiagram）描述了作為一個(gè)外部的觀察者的視角對(duì)系統(tǒng)的印象；強(qiáng)調(diào)的是這個(gè)系統(tǒng)是什麼而不是這個(gè)系統(tǒng)怎麼工作。第7章面向?qū)ο蠓治雠c建模核心UML模型圖--類圖類圖（ClassDiagram）通過系統(tǒng)的類以及這些類之間的關(guān)係來表示系統(tǒng)。類的實(shí)現(xiàn)關(guān)係圖第7章面向?qū)ο蠓治雠c建模核心UML模型圖--包和對(duì)象圖為了簡(jiǎn)單地表示出複雜的類圖，可以把類組合成包（Packages）。包圖實(shí)例第7章面向?qū)ο蠓治雠c建模核心UML模型圖--順序圖按時(shí)間順序?qū)刂屏鹘?，說明系統(tǒng)的動(dòng)態(tài)視圖，強(qiáng)調(diào)時(shí)間和順序。順序圖實(shí)例第7章面向?qū)ο蠓治雠c建模核心UML模型圖--協(xié)作圖協(xié)作圖也是互動(dòng)的圖表，展現(xiàn)了一組對(duì)象及相互間的連接及這組對(duì)象收發(fā)的消息。強(qiáng)調(diào)上下層次關(guān)係強(qiáng)調(diào)收發(fā)消息對(duì)象結(jié)構(gòu)組織，按組織結(jié)構(gòu)對(duì)控制流建模。在序列圖中，對(duì)象的角色放在上面而消息則是連接線。協(xié)作圖的每個(gè)消息都有一個(gè)序列號(hào)。頂層消息的數(shù)字是1。同一個(gè)等級(jí)的消息有同樣的數(shù)字首碼，再根據(jù)他們出現(xiàn)的順序增加一個(gè)尾碼1，2等等。第7章面向?qū)ο蠓治雠c建模核心UML模型圖--狀態(tài)圖狀態(tài)圖展示了一個(gè)特定對(duì)象的所有可能狀態(tài)及由於各種事件發(fā)生而引起的狀態(tài)間轉(zhuǎn)移。狀態(tài)圖實(shí)例第7章面向?qū)ο蠓治雠c建模核心UML模型圖--活動(dòng)圖活動(dòng)圖是一種特殊的狀態(tài)圖，描述需要做的活動(dòng)、執(zhí)行這些活動(dòng)的順序、工作流?；顒?dòng)圖實(shí)例第7章面向?qū)ο蠓治雠c建模核心UML模型圖--組件與配置圖配置圖展現(xiàn)了運(yùn)行時(shí)處理節(jié)點(diǎn)及其構(gòu)件的部署。它描述系統(tǒng)硬體的物理拓?fù)浣Y(jié)構(gòu)及在此結(jié)構(gòu)上執(zhí)行的軟體，它說明系統(tǒng)結(jié)構(gòu)的靜態(tài)部署視圖，即說明發(fā)佈、交付和安裝的物理系統(tǒng)。組件是代碼模組，組件圖是是類圖的物理實(shí)現(xiàn)。

第7章面向?qū)ο蠓治雠c建模建模工具RationalRose是Rational公司的一種面向?qū)ο蟮慕y(tǒng)一建模語言UML的可視化建模工具，用於可視化建模和公司級(jí)水準(zhǔn)軟體應(yīng)用的組件構(gòu)造。EnterpriseArchitectEnterpriseArchitect(簡(jiǎn)稱EA)，是由SparxSystemsPtyLtd.開發(fā)的一套UML設(shè)計(jì)軟體。第8章總體設(shè)計(jì)軟體設(shè)計(jì)應(yīng)遵循的基本原理抽象逐步細(xì)化模組化模組獨(dú)立性資訊隱藏第8章總體設(shè)計(jì)總體設(shè)計(jì)的過程明確系統(tǒng)的目的，劃分出系統(tǒng)的主要功能。約定系統(tǒng)的開發(fā)與運(yùn)行環(huán)境，這將影響著系統(tǒng)以何種方式開發(fā)。設(shè)計(jì)系統(tǒng)的總體結(jié)構(gòu)設(shè)計(jì)系統(tǒng)的功能模組數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)庫設(shè)計(jì)軟體系統(tǒng)的總體指標(biāo)匯總設(shè)計(jì)資訊、撰寫總體設(shè)計(jì)文檔評(píng)審總體設(shè)計(jì)第8章總體設(shè)計(jì)軟體設(shè)計(jì)原則多樣化設(shè)計(jì)設(shè)計(jì)可回溯到需求充分利用已有的模組設(shè)計(jì)應(yīng)該表現(xiàn)出一致性和規(guī)範(fàn)性設(shè)計(jì)的易修改性容錯(cuò)性設(shè)計(jì)設(shè)計(jì)的粒度要適當(dāng)在設(shè)計(jì)時(shí)就要開始評(píng)估軟體的品質(zhì)設(shè)計(jì)評(píng)審第8章總體設(shè)計(jì)總體設(shè)計(jì)的圖形描述工具-層次圖第8章總體設(shè)計(jì)總體設(shè)計(jì)的圖形描述工具-HIPO圖第8章總體設(shè)計(jì)總體設(shè)計(jì)的圖形描述工具-結(jié)構(gòu)圖第9章詳細(xì)設(shè)計(jì)詳細(xì)設(shè)計(jì)階段應(yīng)遵循下列原則：

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

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

編碼語言的選擇ASP.NETMVC簡(jiǎn)述ADO.NETEntityFramework簡(jiǎn)述第10章編碼實(shí)現(xiàn)ASP.NETMVC、EntityFramework專案實(shí)踐

準(zhǔn)備工作創(chuàng)建介面建立數(shù)據(jù)持久化層建立DAO層業(yè)務(wù)邏輯層創(chuàng)建Controller控制器類Web頁面配置URL路由web.config檔配置其他擴(kuò)展第11章專案測(cè)試測(cè)試計(jì)畫的制定

為何要制定測(cè)試計(jì)畫如何制定測(cè)試計(jì)畫測(cè)試計(jì)畫設(shè)計(jì)實(shí)例測(cè)試計(jì)畫修改與維護(hù)第11章專案測(cè)試測(cè)試計(jì)畫的制定--為何要制定測(cè)試計(jì)畫可以讓專案有條理有計(jì)畫的進(jìn)行。可以提前預(yù)知專案過程中可能出現(xiàn)的問題。有助於專案人員更好的理解這個(gè)專案內(nèi)容，明確測(cè)試的目標(biāo)，測(cè)試範(fàn)圍和測(cè)試重點(diǎn)。參與測(cè)試的專案成員，尤其是測(cè)試管理人員，可以明確測(cè)試任務(wù)和測(cè)試方法，保持測(cè)試實(shí)施過程的順暢溝通，跟蹤和控制測(cè)試進(jìn)度，應(yīng)對(duì)測(cè)試過程中的可能出現(xiàn)的各種變更。第11章專案測(cè)試測(cè)試計(jì)畫的制定--如何制定測(cè)試計(jì)畫

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

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

第12章軟體工程專案管理專案計(jì)畫和組織--專案計(jì)畫的制定制定專案計(jì)畫的步驟明確目標(biāo)制定專案工作範(fàn)圍在專案組內(nèi)分配任務(wù)職責(zé)統(tǒng)籌規(guī)劃專案間活動(dòng)的關(guān)聯(lián)制定專案計(jì)畫的原則制定一份能夠獲得批準(zhǔn)、總體結(jié)構(gòu)準(zhǔn)確且具有指導(dǎo)意義的專案計(jì)畫書短期計(jì)畫和長期計(jì)畫相結(jié)合專案計(jì)畫的確定可以採用目標(biāo)管理法制定專案計(jì)畫的工具工作分解結(jié)構(gòu)：將專案的“交付物”自頂向下逐層分解成易於管理的若干元素，以此結(jié)構(gòu)化地組織和定義了專案的工作範(fàn)圍。責(zé)任分配矩陣表：責(zé)任分配矩陣是以表格形式表示完