整套電子課件：軟件工程與項目實(shí)踐教程

項目一成立項目小組項目問題某軟件公司剛成立，從學(xué)校招聘了一些新的開發(fā)人員。最近，該公司通過關(guān)系從市場接到一個網(wǎng)上書店的軟件項目。由于公司剛成立，新招的開發(fā)人員都只有編程的經(jīng)驗，沒有完整的項目開發(fā)經(jīng)驗。該公司該如何開展網(wǎng)上書店的項目開發(fā)呢？2軟件危機(jī)代價高進(jìn)度難控制工作量和成本估算難質(zhì)量差維護(hù)難用戶不滿意軟件生產(chǎn)率提高的速度跟不上計算機(jī)應(yīng)用迅速

普及深入的趨勢1979年，美國USGovernmentAccountingOffice的調(diào)查1999年，美國StandishGroup的調(diào)查3軟件的特點(diǎn)邏輯實(shí)體，具有抽象性軟件生產(chǎn)屬于智力活動，軟件質(zhì)量控制必須著重于開發(fā)維護(hù)復(fù)雜，與硬件維修有本質(zhì)差別4軟件的特點(diǎn)（續(xù)）對計算機(jī)系統(tǒng)的依賴性而產(chǎn)生“軟件移植”的問題軟件開發(fā)尚未完全走出“手工藝”階段對軟件人員的要求很高成本昂貴5問題歸結(jié)軟件生命期階段計劃需求設(shè)計實(shí)現(xiàn)測試維護(hù)主觀盲目地制定計劃；成本、資源、工作量估算不準(zhǔn)；進(jìn)度計劃無法遵循需求提出不明確或者表達(dá)不準(zhǔn)；需求錯誤；需求說明書質(zhì)量不高沒有統(tǒng)一的、公認(rèn)的方法論和規(guī)范指導(dǎo)；設(shè)計資料不完整；忽視接口；編碼不規(guī)范、難讀；程序文檔不完整；修改隨意，與設(shè)計有偏差，無修改記錄變更隨意不規(guī)范；維護(hù)文檔不完整；維護(hù)錯誤測試不充分；測試文檔不完整；測試過程缺乏控制不注意回歸測試6消除軟件危機(jī)的途徑消除“軟件就是程序”的錯誤觀念按照工程化的原則和方法組織軟件開發(fā)工作，是擺脫軟件危機(jī)的一個主要出路7軟件神話管理人員：我們已經(jīng)有了關(guān)于開發(fā)軟件的標(biāo)準(zhǔn)和規(guī)范的書籍，難道它們不能給人們提供所有其需要知道的信息嗎？如果我們已經(jīng)落后于計劃，可以增加更多的程序員來趕上進(jìn)度。8軟件神話用戶：有一個對目標(biāo)的概括描述就足以著手編寫程序了，許多細(xì)節(jié)可以在以后再補(bǔ)充。用戶對軟件的要求不斷變化，然而軟件是柔軟而靈活的，可以輕易地改動。9軟件神話軟件開發(fā)人員：所謂軟件開發(fā)就是編寫程序并設(shè)法使它運(yùn)行。在程序真正運(yùn)行之前，沒有辦法評估其質(zhì)量。10什么是軟件工程定義（1983，IEEE）：軟件工程是開發(fā)、運(yùn)行、維護(hù)和修復(fù)軟件的系統(tǒng)方法三要素：軟件工程方法軟件工程工具軟件工程過程11軟件工程方法為軟件開發(fā)提供了“如何做”的技術(shù)在時間上將軟件開發(fā)工作劃分為若干階段，為每一階段規(guī)定了若干任務(wù)，并提供為完成這些任務(wù)所需的各種技術(shù)是一種使用早已定義好的技術(shù)集和符號表示習(xí)慣來組織軟件生產(chǎn)的過程12軟件工程工具為支援軟件人員的開發(fā)和維護(hù)活動而使用的軟件項目估算工具、需求分析工具、設(shè)計工具、編程和調(diào)試工具、測試工具和維護(hù)工具、……13軟件工程過程將軟件工程的方法和工具綜合起來，達(dá)到合理、及時地進(jìn)行計算機(jī)軟件開發(fā)的目的定義方法使用的順序、要求交付的文檔資料、為保證質(zhì)量和協(xié)調(diào)變化所需要的管理、及軟件開發(fā)各個階段完成的里程碑等14軟件過程15邊做邊改模型“作坊式”開發(fā)，主要問題在于：缺少規(guī)劃和設(shè)計環(huán)節(jié)，導(dǎo)致軟件無法繼續(xù)修改忽略需求環(huán)節(jié)沒有考慮測試和程序的可維護(hù)性16瀑布模型自上而下，相互銜接17原型實(shí)現(xiàn)模型先開發(fā)一個“原型”軟件，完成部分主要功能，展示給用戶并征求意見，然后逐步完善，最終獲得滿意的軟件產(chǎn)品18用戶測試運(yùn)行原型建造/修改原型

聽取用戶意見增量模型19項目日歷時間軟件功能性和特征12345第2次增量發(fā)布增量212345第n次增量發(fā)布增量n12345第1次增量發(fā)布增量1┇5部署（發(fā)布，反饋）4構(gòu)造（編碼，測試）3建模（分析，設(shè)計）2計劃1交流螺旋模型20極限編程敏捷（Agile）聯(lián)盟讓軟件開發(fā)團(tuán)隊具有快速工作、響應(yīng)變化能力的價值觀和原則極限編程：一種敏捷方法。由一系列簡單卻互相依賴的實(shí)踐組成21敏捷軟件開發(fā)宣言個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應(yīng)變化勝過遵循計劃

雖然上述右項也有價值，但我們認(rèn)為左項具有更大的價值。22RUP統(tǒng)一建模過程23討論假設(shè)你被指定為項目負(fù)責(zé)人，你的任務(wù)是開發(fā)一個應(yīng)用系統(tǒng)，該系統(tǒng)類似于你的小組以前做過的那些系統(tǒng)，但是規(guī)模更大且更復(fù)雜一些。客戶已經(jīng)寫出了完整的需求文檔。你將選用哪種項目組結(jié)構(gòu)？為什么？你打算采用哪種軟件過程模型？為什么？24公司組織結(jié)構(gòu)項目組模型職能模型矩陣形模型25組織結(jié)構(gòu)對比26程序設(shè)計小組主程序員制小組民主制小組層次式小組27人員配備28軟件分類系統(tǒng)軟件應(yīng)用軟件工程/科學(xué)軟件嵌入式軟件產(chǎn)品線軟件Web應(yīng)用軟件人工智能軟件29實(shí)訓(xùn)任務(wù)成立5-6人的項目小組選舉項目經(jīng)理選擇實(shí)訓(xùn)項目確定項目章程30項目二策劃網(wǎng)上書店項目問題某書店為了進(jìn)一步提書店的企業(yè)形象，同時借助現(xiàn)有的網(wǎng)絡(luò)技術(shù)來實(shí)現(xiàn)異地的產(chǎn)品在線展示和銷售，決定開發(fā)一套網(wǎng)上書店。該軟件的主要功能包括：商品管理、配送支付管理、訂單管理、會員分組、會員管理、查詢統(tǒng)計和多項商品促銷功能等。該企業(yè)準(zhǔn)備投入10萬元進(jìn)行該系統(tǒng)的開發(fā)，時間要求是5-8周。該軟件項目的計劃開始時間是2007.5.1日。項目組長在接到這個項目后，由于是初次獨(dú)立承擔(dān)項目，不知道該先做什么。要解決的問題需要做什么？要如何去做？可不可能完成？可行性分析在市場調(diào)研的基礎(chǔ)上，分析立項的必要性（是否有市場前景）和可能性（是否有能力實(shí)現(xiàn)），并具體列出系統(tǒng)的功能、性能、接口和運(yùn)行環(huán)境等方面的需求、當(dāng)前客戶群的情況，以及投入產(chǎn)出分析?？尚行苑治鋈蝿?wù)技術(shù)可行性現(xiàn)有技術(shù)、資源及限制能否支持和實(shí)現(xiàn)系統(tǒng)的功能、性能。主要是技術(shù)風(fēng)險問題開發(fā)的風(fēng)險資源的有效性技術(shù)儲備可行性分析任務(wù)經(jīng)濟(jì)可行性進(jìn)行成本估算及效益評估，確定項目是否值得開發(fā)成本-效益風(fēng)險分析長期公司經(jīng)營策略開發(fā)成本和資源潛在的市場前景可行性分析任務(wù)社會可行性系統(tǒng)開發(fā)后能否運(yùn)行，是否存在合同、責(zé)任、侵權(quán)、用戶組織管理等方面的問題是否存在任何侵犯、妨礙他人責(zé)任問題運(yùn)行方式在用戶組織是否可行現(xiàn)有的管理制度、人員素質(zhì)和操作方式是否可行可行性分析過程確定項目規(guī)模和目標(biāo)研究現(xiàn)行系統(tǒng)（如果存在）建立系統(tǒng)的高級邏輯模型，用系統(tǒng)流程圖或數(shù)據(jù)流圖（DFD圖）描述提出實(shí)現(xiàn)高層邏輯模型的各種方案，并對各方案進(jìn)行評價推薦可行的方案編寫可行性報告確定項目規(guī)模和目標(biāo)問題定義階段確定的系統(tǒng)規(guī)模和目標(biāo)進(jìn)一步確認(rèn);改正含糊或不確切的敘述,清晰地描述對目標(biāo)系統(tǒng)的限制和約束我們認(rèn)為用戶要的?

用戶要的研究目前正在使用的系統(tǒng)正在使用的系統(tǒng)人工系統(tǒng):需要計算機(jī)化計算機(jī)系統(tǒng):需要改進(jìn)或完善研究現(xiàn)有系統(tǒng)的文檔資料和使用手冊,了解:原系統(tǒng)能做什么;為什么這樣做;現(xiàn)有系統(tǒng)使用的代價;用戶對新系統(tǒng)的要求;該系統(tǒng)的邊界(與其他系統(tǒng)的關(guān)系).建立系統(tǒng)的高級邏輯模型根據(jù)對現(xiàn)有系統(tǒng)的研究,導(dǎo)出現(xiàn)有系統(tǒng)的邏輯模型,設(shè)計出目標(biāo)系統(tǒng)的邏輯模型.使用的工具:系統(tǒng)流程圖數(shù)據(jù)流圖數(shù)據(jù)字典…………抽象實(shí)現(xiàn)改進(jìn)老系統(tǒng)物理模型模型邏輯模型新模型邏輯模型新系統(tǒng)物理模型技術(shù)評估技術(shù)的成熟程度實(shí)驗室技術(shù)經(jīng)過中試的技術(shù)已經(jīng)工業(yè)化應(yīng)用的技術(shù)市場需求顯在潛在：轉(zhuǎn)化為顯在的條件競爭態(tài)勢：與競爭技術(shù)相比，所采用技術(shù)的優(yōu)勢及缺陷技術(shù)轉(zhuǎn)換成本支撐體系與條件：原料、銷售網(wǎng)絡(luò)、用戶體系、政策技術(shù)發(fā)展趨勢及所采用技術(shù)的發(fā)展前景技術(shù)方案選擇要考慮的制約條件需求制約：現(xiàn)存的需求結(jié)構(gòu)及需求結(jié)構(gòu)可能的變化資源制約：資金、人力資源、自然資源、其它要素環(huán)境制約：經(jīng)濟(jì)技術(shù)環(huán)境、社會文化環(huán)境、自然環(huán)境選擇原則經(jīng)濟(jì)性原則：以最小的投入取得最好的效果發(fā)展原則：發(fā)展的前景及適應(yīng)發(fā)展的能力兼容性原則：與原有經(jīng)濟(jì)、技術(shù)、環(huán)境、社會的兼容性相關(guān)效果原則：相關(guān)的經(jīng)濟(jì)、技術(shù)、環(huán)境、社會效果選擇視角技術(shù)先進(jìn)性技術(shù)適用性軟件項目計劃工作確定詳細(xì)的項目實(shí)施范圍定義遞交的工作成果評估實(shí)施過程中主要的風(fēng)險制定項目實(shí)施的時間計劃、成本和預(yù)算計劃、人力資源計劃項目目標(biāo)項目目標(biāo)就是實(shí)施項目所要達(dá)到的期望結(jié)果，是衡量項目成功與否的標(biāo)準(zhǔn)。約束性目標(biāo)進(jìn)度、費(fèi)用、質(zhì)量三重約束成果性目標(biāo)要完成的產(chǎn)品WBS(工作結(jié)構(gòu)分解)通過工作分解的方式，將工作范圍細(xì)分為活動，然后對每項活動分配時間和資源，而活動結(jié)果的總和就是工作范圍任務(wù)分解就是將項目可交付成果分成幾個小的、更易管理的單元。制訂WBS計劃步驟分解工作任務(wù)將一個總的工作范圍逐漸細(xì)分到合適的粒度，以便對任務(wù)計劃、執(zhí)行和控制定義活動依賴關(guān)系對這些活動之間的依賴關(guān)系做出定義分配時間和資源為每項活動分配相應(yīng)的時間和資源分解步驟總項目子項目或主體工作任務(wù)主要工作任務(wù)次要工作任務(wù)具體工作包WBS分解結(jié)果要求可管理、可定量測量、可獨(dú)立分配任務(wù)的可以進(jìn)行費(fèi)用和時間的估計不體現(xiàn)工期和活動的先后順序包括管理活動分解完后需進(jìn)行核對計劃制定的原則具體的（Specific）反對陳詞濫調(diào)和假、大、空的套話，應(yīng)該學(xué)會用簡短的語言明確說出目標(biāo)?？珊饬康模∕easurable）盡量用量化語言來描述你的目標(biāo)，而不是你的目的和愿望。能夠達(dá)到（Attainable）制定的目標(biāo)應(yīng)該是經(jīng)過科學(xué)論證可以實(shí)現(xiàn)的，而不是主觀臆斷和憑空想象。相關(guān)的（Relevant）制定的目標(biāo)應(yīng)該與目的是相關(guān)聯(lián)的，目標(biāo)是實(shí)現(xiàn)目的步驟。限定時間的（Time-Bound）必須有起點(diǎn)、終點(diǎn)和時間段。項目三需求分析項目問題軟件開發(fā)人員經(jīng)常困惑于軟件分明是按照需求做出來的，可是為什么客戶仍不滿意客戶總是困惑為什么軟件和自己想要的差距會那么大現(xiàn)象的起因該怎么解決需求分析任務(wù)要準(zhǔn)確地定義新系統(tǒng)的目標(biāo)，為了滿足用戶需求，回答系統(tǒng)必須“做什么”的問題需求分析的過程調(diào)查研究分析與綜合編寫需求分析文檔需求分析評審準(zhǔn)備調(diào)查需求調(diào)查準(zhǔn)備工作圍繞三項展開：（1）調(diào)查什么？（2）通過什么方式去調(diào)查？（3）“何人”在“何時”調(diào)查？準(zhǔn)備調(diào)查首先，需求分析員應(yīng)當(dāng)起草需求調(diào)查問題表，將調(diào)查重點(diǎn)鎖定在該問題表內(nèi)，否則調(diào)查工作將變得漫無邊際。問題表可以有多份，隨著調(diào)查的深入，問題表將不斷地被細(xì)化。根據(jù)經(jīng)驗，用戶通常沒有耐心回答復(fù)雜的“論述題”，所以問題表應(yīng)當(dāng)以“選擇題”和“是非題”為主。準(zhǔn)備調(diào)查其次，需求分析員應(yīng)當(dāng)確定需求調(diào)查的方式，例如：與用戶交談，向用戶提問題。參觀用戶的工作流程，觀察用戶的操作。向用戶群體發(fā)調(diào)查問卷。與同行、專家交談，聽取他們的意見。分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求。從Internet上搜查相關(guān)資料。準(zhǔn)備調(diào)查最后，需求分析員與被調(diào)查者建立聯(lián)系，確定調(diào)查的時間、地點(diǎn)、人員等，撰寫需求調(diào)查計劃。要特別留意的是不要漏掉典型的用戶。調(diào)查與記錄準(zhǔn)備工作完畢后，需求分析員按照計劃執(zhí)行調(diào)查。在調(diào)查過程中隨時記錄（或存儲）需求信息，建議采用表格的形式。需求分析技術(shù)在傳統(tǒng)的和面向?qū)ο蟮拈_發(fā)過程中，常常通過典型的使用情景來了解需求1992年由Jacobson提出了用例（UserCase）什么是用例建模？一種描述功能性需求的方法清晰地定義系統(tǒng)的邊界詳細(xì)描述系統(tǒng)和外部環(huán)境的交互用例模型不僅僅是圖形用例建模中的主要模型元素什么是用例？用例是由系統(tǒng)所執(zhí)行的一系列動作，為相關(guān)的參與者提供有價值的服務(wù)用例描述了系統(tǒng)需求每一個用例表達(dá)了系統(tǒng)向參與者所提供的某種服務(wù)也表述了參與者是如何使用系統(tǒng)的描述了系統(tǒng)和參與者之間的一段對話通訊關(guān)聯(lián)參與者和用例之間進(jìn)行對話的一個渠道用一條帶或不帶箭頭的線來表示箭頭表示是誰發(fā)起了這次對話沒有箭頭表示任何一方都可以發(fā)起對話箭頭并不表示數(shù)據(jù)的流向，數(shù)據(jù)流向總是雙向的場景是用例的一個實(shí)例場景一輸入提款金額提取現(xiàn)金退出系統(tǒng)，取回卡場景二輸入提款金額，金額大于2500元系統(tǒng)提示限額信息并提示客戶重新輸入輸入正確金額提取現(xiàn)金退出系統(tǒng)，取回卡用例圖用例方法的好處為需求提供了應(yīng)用環(huán)境把系統(tǒng)定義在一個使用環(huán)境中幫助解釋為什么需要該系統(tǒng)有助于保證沒有需求的遺漏易于理解站在系統(tǒng)使用者的立場上來定義需求使用客戶和用戶都能理解的術(shù)語和表述易于客戶對于需求的審核可以為其他開發(fā)環(huán)節(jié)所重用項目計劃、設(shè)計、測試、用戶手冊內(nèi)容什么是用例建模用例的開發(fā)過程找出參與者找出用例描述用例框架細(xì)化用例描述管理用例模型的復(fù)雜度找出參與者找出參與者系統(tǒng)有那些用戶？有誰想從系統(tǒng)中獲取信息誰負(fù)責(zé)向系統(tǒng)提供信息？系統(tǒng)將會在哪些部門使用？是誰負(fù)責(zé)管理和維護(hù)系統(tǒng)？有沒有其他的系統(tǒng)會和該系統(tǒng)發(fā)生交互？抽象出參與者系統(tǒng)邊界決定參與者系統(tǒng)邊界僅限于ATM機(jī)本身系統(tǒng)邊界擴(kuò)大至整個銀行系統(tǒng)特殊的參與者――系統(tǒng)時鐘系統(tǒng)內(nèi)部定時地執(zhí)行一些操作，如檢測系統(tǒng)資源使用情況、定期地生成統(tǒng)計報表等等對于參與者的描述參與者之間的關(guān)系什么是用例建模用例的開發(fā)過程找出參與者找出用例描述用例框架細(xì)化用例描述管理用例模型的復(fù)雜度找出用例找出用例每一個參與者想達(dá)到的目標(biāo)是什么？為什么該參與者需要使用該系統(tǒng)？該參與者會在系統(tǒng)中創(chuàng)建、修改、刪除或訪問任何數(shù)據(jù)嗎？當(dāng)外部有事件發(fā)生的時候，該參與者需要通知系統(tǒng)嗎？當(dāng)系統(tǒng)內(nèi)部有某些事件發(fā)生時，需要通知該參與者嗎？已定義的系統(tǒng)功能是否足以滿足所有的業(yè)務(wù)需求？ATM系統(tǒng)用例圖用例的包含關(guān)系查詢-基本事件流1.用戶插入信用卡2.輸入密碼3.選擇查詢4.查看帳號余額5.包含用例"打印回執(zhí)"6.退出系統(tǒng)，取回信用卡用例的擴(kuò)展關(guān)系用例的泛化關(guān)系內(nèi)容什么是用例建模用例的開發(fā)過程找出參與者找出用例描述用例框架細(xì)化用例描述管理用例模型的復(fù)雜度描述每一個用例的框架事件流一個基本流最順利的場景從開始到結(jié)束一切都順利的場景很多個備選流除基本流之外的另外一些正常場景偶爾發(fā)生的場景異?；蝈e誤處理流：是指一系列的步驟表示基本流和備用流用例名稱1.簡要說明2.事件流

2.1基本流步驟1

步驟2

步驟3

步驟42.2備用流

2.2.1A1… 2.2.2A2…2.2.3A3… 2.2.4A4… 2.2.5A5…什么是場景？事件流：一系列的步驟用例：描述所有的流場景：用例的某一個實(shí)例，從用例開始直到它的某一個結(jié)束點(diǎn)描述用例框架基本流是什么事件啟動了用例？用例是如何結(jié)束的？用例中最常用到的行為是什么？備選流在用例中有無可選執(zhí)行的情況？那些行為是偶爾才發(fā)生的？是否有沒有包含在基本流中的正常情況？發(fā)生錯誤的情況下該如何處理？ATM示例：提款提款-基本事件流

1.用戶插入信用卡

2.輸入密碼

3.輸入提款金額

4.提取現(xiàn)金

5.退出系統(tǒng)，取回信用卡提款-備選事件流

備選流一：用戶可以在基本流中的任何一步選擇退出，轉(zhuǎn)至基本流步驟5。 備選流二：在基本流步驟1中，用戶插入無效信用卡，系統(tǒng)顯示錯誤并退出信用卡，用例結(jié)束。 備選流三：在基本流步驟2中，用戶輸入錯誤密碼，系統(tǒng)顯示錯誤并提示用戶重新輸入密碼，重新回到基本流步驟2;三次輸入密碼錯誤后，信用卡被系統(tǒng)沒收，用例結(jié)束。

什么是用例建模用例的開發(fā)過程找出參與者找出用例描述用例框架細(xì)化用例描述管理用例模型的復(fù)雜度為什么細(xì)化用例描述？描述軟件需求為后續(xù)的開發(fā)準(zhǔn)備一個系統(tǒng)功能描述在事件流中描述更為詳細(xì)的信息參與者做了什么動作系統(tǒng)是如何響應(yīng)的系統(tǒng)和參與者之間交換了哪些信息描述用例場景成功場景失敗場景描述額外的用例信息特殊需求前置條件后置條件描述額外的用例信息特殊需求

特殊需求通常是非功能性需求，為一個用例所專有。前置條件

執(zhí)行用例之前必須存在的系統(tǒng)狀態(tài)后置條件

用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)

ATM示例：提款用例描述應(yīng)該有多細(xì)？用例的粒度用例圖以參與者為中心的用例圖以用例為中心總結(jié)：用例模型項目四設(shè)計網(wǎng)上書店項目問題對于任何產(chǎn)品都是在有了設(shè)計方案以后才能付諸實(shí)現(xiàn)（如時裝、建筑等），設(shè)計階段的工作質(zhì)量直接決定了產(chǎn)品的最終質(zhì)量。在蓋房子之前，都必須畫出藍(lán)圖來。在完成網(wǎng)上書店的需求分析之后，那該如何創(chuàng)建給程序員進(jìn)行開發(fā)的“圖紙”呢？系統(tǒng)設(shè)計任務(wù)在《需求規(guī)格說明書》確定之后，就正式進(jìn)入到設(shè)計階段在設(shè)計階段，首先只是描繪出軟件的概貌（概要設(shè)計）在此基礎(chǔ)上再將起細(xì)化，得到一個非常接近于源代碼的設(shè)計表達(dá)形式（詳細(xì)設(shè)計）概要設(shè)計任務(wù)回答“怎樣實(shí)現(xiàn)目標(biāo)系統(tǒng)?”設(shè)計出實(shí)現(xiàn)目標(biāo)系統(tǒng)的幾種可能的方案描述每種可能的方案，分析每種方案的優(yōu)缺點(diǎn)，并在充分權(quán)衡各種方案的利弊的基礎(chǔ)上，推薦一個最佳方案制定出實(shí)現(xiàn)所推薦的方案的詳細(xì)計劃概要設(shè)計程序應(yīng)該模塊化設(shè)計程序的體系結(jié)構(gòu)確定程序由哪些模塊組成以及模塊間的關(guān)系詳細(xì)設(shè)計任務(wù)

回答“應(yīng)該怎樣具體地實(shí)現(xiàn)這個系統(tǒng)”設(shè)計出程序的詳細(xì)規(guī)格說明任務(wù)1：網(wǎng)上書店體系結(jié)構(gòu)設(shè)計

體系結(jié)構(gòu)設(shè)計主要是根據(jù)《需求規(guī)格說明書》對系統(tǒng)進(jìn)行分解，確定子系統(tǒng)的功能和子系統(tǒng)之間的關(guān)系以及模塊的功能和模塊之間的關(guān)系。主要工作流程

(1) 設(shè)計準(zhǔn)備(2) 確定影響系統(tǒng)設(shè)計的約束因素(3) 確定設(shè)計策略(4) 系統(tǒng)分解與設(shè)計(5) 撰寫體系結(jié)構(gòu)設(shè)計文檔(6) 體系結(jié)構(gòu)設(shè)計評審“建筑體系結(jié)構(gòu)”一個人可完成。僅需： 最小的建模 簡單的過程 簡單的工具狗窩的體系結(jié)構(gòu)設(shè)計“鳥巢”的設(shè)計團(tuán)隊工作，高效而及時地完成。需要： 建模； 規(guī)范的過程； 強(qiáng)大的工具。軟件體系結(jié)構(gòu)的概念（M.Shaw）軟件體系結(jié)構(gòu)定義為：程序/系統(tǒng)各構(gòu)件的結(jié)構(gòu)它們之間的內(nèi)部關(guān)系指導(dǎo)它們的設(shè)計并隨時間而演變的原理和方針精簡定義為(3C)：

體系結(jié)構(gòu)=組件+連接件+約束

（Architecture=Components+Connectors+Constrains

）層次體系上層子系統(tǒng)可以使用下層子系統(tǒng)的功能，而下層子系統(tǒng)不能夠使用上層子系統(tǒng)的功能一般下層每個程序接口執(zhí)行當(dāng)前的一個簡單的功能，而上層通過調(diào)用不同的下層程序，并按不同的順序來執(zhí)行這些下層程序典型計算機(jī)網(wǎng)絡(luò)的OSI參考模型客戶機(jī)/服務(wù)器結(jié)構(gòu)C/S軟件體系結(jié)構(gòu)，即Client/Server(客戶機(jī)/服務(wù)器)結(jié)構(gòu)，是基于資源不對等，且為實(shí)現(xiàn)共享而提出來的二層C/S結(jié)構(gòu)服務(wù)器(后臺)負(fù)責(zé)數(shù)據(jù)管理客戶機(jī)(前臺)完成與用戶的交互任務(wù)三層C/S結(jié)構(gòu)表示層是應(yīng)用的用戶接口部分，擔(dān)負(fù)著用戶與應(yīng)用間的對話功能它用于檢查用戶從鍵盤等輸入的數(shù)據(jù)，顯示應(yīng)用輸出的數(shù)據(jù)功能層相當(dāng)于應(yīng)用的本體將具體的業(yè)務(wù)處理邏輯編入程序中數(shù)據(jù)層是數(shù)據(jù)庫管理系統(tǒng)負(fù)責(zé)管理對數(shù)據(jù)庫數(shù)據(jù)的讀寫瀏覽器/服務(wù)器(B/S)結(jié)構(gòu)在B/S體系結(jié)構(gòu)下，用戶界面完全通過WWW瀏覽器實(shí)現(xiàn)，一部分事務(wù)邏輯在前端實(shí)現(xiàn)，但是主要事務(wù)邏輯在服務(wù)器端實(shí)現(xiàn)僅僅需要一個瀏覽器就可運(yùn)行全部的模塊，真正達(dá)到了"零客戶端"的功能任務(wù)2：網(wǎng)上書店靜態(tài)設(shè)計

在完成網(wǎng)上的體系結(jié)構(gòu)設(shè)計之后，將針對不同的模塊進(jìn)行具體的模塊設(shè)計軟件設(shè)計的原則⑴軟件實(shí)體有明顯的層次結(jié)構(gòu)，利于軟件元素間控制；⑵軟件實(shí)體應(yīng)該是模塊化的，模塊具有獨(dú)立功能；⑶軟件實(shí)體與環(huán)境的界面清晰；⑷設(shè)計規(guī)格說明清晰、簡潔、完整和無二義性模塊化原則模塊化－－把軟件按照規(guī)定原則，劃分為一個個較小的，相互獨(dú)立的但又相互關(guān)聯(lián)的部件，實(shí)際上是系統(tǒng)分解和抽象的過程模塊化的目的：降低軟件的復(fù)雜性模塊的概念模塊是數(shù)據(jù)說明、可執(zhí)行語句等程序?qū)ο蟮募希菃为?dú)命名的，并且可以通過名字來訪問例如，過程、函數(shù)、子程序、宏等模塊的特征：接口，模塊的輸入輸出；功能，指模塊實(shí)現(xiàn)什么功能，有什么作用；邏輯，描述模塊內(nèi)部如何實(shí)現(xiàn)需求及所需數(shù)據(jù)；狀態(tài)，該模塊的運(yùn)行環(huán)境，模塊間調(diào)用與被調(diào)用關(guān)系。模塊的獨(dú)立性模塊獨(dú)立性：模塊完成獨(dú)立的功能與其他模塊的接口簡單符合信息隱蔽和信息局部化原則模塊間關(guān)聯(lián)和依賴程度盡可能小模塊獨(dú)立的重要性功能被劃分，并且接口被簡化，所以具有有效模塊化的軟件更易于開發(fā)由于因設(shè)計和編碼修改引起的副作用受到局限，錯誤傳播被減小，并且模塊復(fù)用成為可能，所以獨(dú)立的模塊更易于維護(hù)和測試模塊獨(dú)立性的度量內(nèi)聚（cohesion）：是一個模塊內(nèi)部各個元素彼此結(jié)合的緊密程度的度量耦合(coupling)：是模塊之間的相對獨(dú)立性（互相連接的緊密程度）的度量內(nèi)聚性內(nèi)聚是模塊功能強(qiáng)度（一個模塊內(nèi)部各個元素彼此結(jié)合的緊密程度）的度量一個內(nèi)聚程度高的模塊（在理想情況下）應(yīng)當(dāng)只做一件事一般模塊的內(nèi)聚性分為七種類型耦合性模塊之間的相對獨(dú)立性（互相連接的緊密程度）①方式：調(diào)用模塊的方式②作用：塊間傳送的共用信息（參數(shù)）類型③數(shù)量：塊間傳送的共用信息的數(shù)量取決于耦合性的七種類型數(shù)據(jù)方式作用少多數(shù)量控制混合直接調(diào)用過程調(diào)用分析活動：從用例導(dǎo)出對象

包括：

標(biāo)識對象將用例映射成對象（使用順序圖）建模對象之間的交互標(biāo)識對象之間的關(guān)系標(biāo)識對象的屬性和行為分析模型評審類圖描述系統(tǒng)的結(jié)構(gòu),用于表示系統(tǒng)中的類以及類與類之間的關(guān)系是創(chuàng)建其它圖的基礎(chǔ)類的描述主要包括：類的屬性和操作類圖中的關(guān)聯(lián)聚集組合關(guān)聯(lián)泛化依賴細(xì)化（實(shí)現(xiàn)）例題判斷以下描述中的合適的UML類間關(guān)系。在學(xué)校中，一個導(dǎo)師可以指導(dǎo)多個研究生，一個研究生可以由多個導(dǎo)師指導(dǎo)，那么導(dǎo)師和研究生之間的關(guān)系是：類A的一個操作調(diào)用類B的一個操作，且這兩個類之間不存在其他關(guān)系，那么類A和類B之間的關(guān)系是：森林和樹木之間的關(guān)系是：在MFC類庫中，Window類和DialogBox類之間的關(guān)系是：參數(shù)類及其實(shí)例類之間的關(guān)系是：關(guān)聯(lián)依賴聚合泛化實(shí)現(xiàn)任務(wù)3：網(wǎng)上書店的動態(tài)結(jié)構(gòu)設(shè)計

在完成系統(tǒng)靜態(tài)結(jié)構(gòu)后，需要對系統(tǒng)的功能如何執(zhí)行操作要進(jìn)行描述，UML一般是通過時序圖、狀態(tài)圖來描述系統(tǒng)的動態(tài)結(jié)構(gòu)構(gòu)建動態(tài)模型描述系統(tǒng)的動態(tài)行為，它們指明系統(tǒng)中的對象如何響應(yīng)外部的事件，執(zhí)行任務(wù)評估所有的用例，理解系統(tǒng)中交互的序列，標(biāo)識驅(qū)動交互序列的事件，理解這些事件如何和特定的對象相關(guān)聯(lián)為系統(tǒng)建造順序圖、活動圖為主要對象建造狀態(tài)機(jī)圖復(fù)審動態(tài)模型，以驗證準(zhǔn)確性和一致性順序圖：將用例映射成對象

順序圖將用例與對象聯(lián)系在一起。表達(dá)了用例行為在其參與對象之間是怎樣分布的建模了對象之間的交互順序，同時將功能分配給該用例可幫助開發(fā)者標(biāo)識出新的參與對象、發(fā)現(xiàn)遺漏的對象或界限不明的領(lǐng)域順序圖關(guān)注于消息的順序，給出對象之間發(fā)送消息的先后順序順序圖例子銀行轉(zhuǎn)賬業(yè)務(wù)的順序圖狀態(tài)圖一個狀態(tài)圖表示一個狀態(tài)機(jī)。狀態(tài)圖用來描述某個對象的所有可能狀態(tài)及其狀態(tài)轉(zhuǎn)換信息。一個狀態(tài)圖包括一系列的狀態(tài)及狀態(tài)之間的轉(zhuǎn)移狀態(tài)是對象執(zhí)行了一系列活動的結(jié)果。當(dāng)某個事件發(fā)生后，對象的狀態(tài)將發(fā)生變化，狀態(tài)的改變叫做轉(zhuǎn)移不是每個類都應(yīng)該有一個狀態(tài)圖。只對“感興趣的”狀態(tài)的類（也就是說，在系統(tǒng)活動期間具有三個或更多潛在狀態(tài)的類）才進(jìn)行狀態(tài)圖描述。浸泡洗滌漂洗脫水狀態(tài)圖：電梯活動圖活動圖用于對計算流程和工作流建模，描述完成一個操作所需要的活動，或者是一個用例實(shí)例（場景）的活動?；顒訄D使用狀態(tài)機(jī)圖的符號表示與狀態(tài)機(jī)圖不同的是，活動圖中動作狀態(tài)之間的遷移不是靠事件觸發(fā)的，當(dāng)動作狀態(tài)中的活動完成時遷移就被觸發(fā)

活動圖用來描述用例描述用例的活動圖[未付款][已付款]*[對每一訂單項][有貨][缺貨]取消并退回訂單收到訂單付款認(rèn)可檢查訂單項制作并發(fā)放提貨單更新庫存制作并發(fā)放缺貨單制作并發(fā)放采購單數(shù)據(jù)庫ER模型實(shí)體聯(lián)系模型（E-R模型）是廣泛被采用的概念模型設(shè)計方法基本元素是：實(shí)體、聯(lián)系和屬性實(shí)體實(shí)體是一個數(shù)據(jù)對象，指應(yīng)用中可以區(qū)別的客觀存在的事物，如人、部門、表格、物體、項目等。在E-R模型中，實(shí)體用方框表示，方框內(nèi)注明實(shí)體的命名實(shí)體名常用大寫字母開頭的有具體意義的英文名詞表示屬性實(shí)體的某一特性稱為屬性。如人有姓名、性別、年齡、性別等屬性在E-R圖中，屬性用橢圓形框表示，加下劃線的屬性是碼。聯(lián)系聯(lián)系表示一個或多個實(shí)體之間的關(guān)聯(lián)關(guān)系在E-R圖中，聯(lián)系用菱形框表示，并用線段將其與相關(guān)的實(shí)體連接起來ER圖實(shí)例項目五實(shí)現(xiàn)網(wǎng)上書店項目問題為什么要進(jìn)行煩人的單元測試？那些剛剛接觸完全測試概念的開發(fā)人員常常遇到這個問題。144常見誤解單元測試?yán)速M(fèi)了太多的時間它僅僅是證明這些代碼做了什么我是個很棒的程序員，我是不是可以不進(jìn)行單元測試？不管怎樣，集成測試將會抓住所有的Bug145解決方案關(guān)鍵任務(wù)是寫出正確的容易理解、容易維護(hù)的程序模塊

根據(jù)目標(biāo)系統(tǒng)的性質(zhì)和實(shí)際環(huán)境，選取一種適當(dāng)?shù)母呒壋绦蛟O(shè)計語言（必要時用匯編語言）把說細(xì)設(shè)計的結(jié)果翻譯成用選定的語言書寫的程序仔細(xì)測試編寫出的每一個模塊。146常見錯誤編碼不規(guī)范不重視單元測試147編程規(guī)約和規(guī)范的審查代碼檢查包括代碼走查、代碼審查等檢查內(nèi)容代碼和設(shè)計的一致性代碼對標(biāo)準(zhǔn)的遵循、可讀性代碼的邏輯表達(dá)的正確性代碼結(jié)構(gòu)的合理性代碼走查和代碼審查的區(qū)別項目走查審查準(zhǔn)備通讀設(shè)計和編碼應(yīng)準(zhǔn)備好需求描述文檔、程序設(shè)計文檔、程序的源代碼清單、代碼編碼標(biāo)準(zhǔn)和代碼缺陷檢查表形式非正式會議正式會議參加人員開發(fā)人員為主項目組成員包括測試人員主要技術(shù)方法無缺陷檢查表注意事項限時、不要現(xiàn)場修改代碼限時、不要現(xiàn)場修改代碼生成文檔會議記錄靜態(tài)分析錯誤報告目標(biāo)代碼標(biāo)準(zhǔn)規(guī)范，無邏輯錯誤代碼標(biāo)準(zhǔn)規(guī)范，無邏輯錯誤代碼審查清單數(shù)據(jù)引用錯誤數(shù)據(jù)聲明錯誤計算錯誤比較錯誤控制流程錯誤子程序參數(shù)錯誤輸出錯誤其他檢查單元測試的優(yōu)點(diǎn)它是一種驗證行為它是一種設(shè)計行為它是一種編寫文檔的行為它具有回歸性單元測試的內(nèi)容模塊接口測試局部數(shù)據(jù)結(jié)構(gòu)測試路徑測試錯誤處理測試邊界測試項目六

測試網(wǎng)上書店項目問題當(dāng)開發(fā)組完成實(shí)現(xiàn)階段工作，就可以正式交付給測試組開始軟件測試階段的工作了，這個階段是保證軟件質(zhì)量的重要階段，只有這個階段完成良好，才能保證交付給用戶的產(chǎn)品是符合用戶需求的產(chǎn)品。154解決方案軟件測試是程序的一種執(zhí)行過程，目的是盡可能發(fā)現(xiàn)并改正被測試軟件中的錯誤，提高軟件的可靠性。是軟件生命周期中一項非常重要且非常復(fù)雜的工作155基于Web的系統(tǒng)測試方法

基于Web的系統(tǒng)測試與傳統(tǒng)的軟件測試不同需要檢查和驗證是否按照設(shè)計