軟件工程教案(理論課程)

1、教師備課教案本(理論課程)系 別：計(jì)算機(jī)工程系課程名稱：軟件工程教師姓名：段琢華授課時間：20132014學(xué)年第 2 學(xué)期電子科技大學(xué)中山學(xué)院教師授課計(jì)劃*課程名稱軟件工程學(xué)分3課程類型1、普通教育必修課（ ）； 2、學(xué)科基礎(chǔ)必修課（ ）； 3、專業(yè)方向課（ ）；4、學(xué)科基礎(chǔ)選修課（ ）； 5、素質(zhì)教育選修課（ ）； 6、專業(yè)選修課（ ）。學(xué)時分配總學(xué)時：48 ；課堂講授： 32學(xué)時； 實(shí)踐（驗(yàn)）課 16學(xué)時授課起止周1-16授課班級游戲11，嵌入式11,網(wǎng)絡(luò)11班級人數(shù)56,69,50授課總次數(shù)*16教材名稱軟件工程案例教程：軟件項(xiàng)目開發(fā)實(shí)踐 第2版作者韓萬江 姜立新出版時間2011年10月

2、13日章節(jié)基 本 內(nèi) 容計(jì)劃學(xué)時1軟件工程總攬（軟件工程知識體系，軟件工程的三段論，方法、過程和工具的概述）62軟件開發(fā)模型及可行性研究2軟件需求（需求定義，需求層次，需求建模，需求規(guī)格說明，需求驗(yàn)證和變更控制）43分析建模（領(lǐng)域建模，架構(gòu)設(shè)計(jì)）44軟件設(shè)計(jì)（設(shè)計(jì)模式的應(yīng)用, 子系統(tǒng)設(shè)計(jì)）86軟件編碼（編碼方法，編碼過程）47軟件測試、發(fā)布與維護(hù)（測試方法，測試級別）4考核要求（根據(jù)課程實(shí)際情況，不做要求的項(xiàng)目可不寫）：1、平時成績的構(gòu)成比例和考核方式；20% 考勤和讀書筆記2、期中成績的構(gòu)成比例和考核方式；3、期末成績的構(gòu)成比例和考核方式；50% 綜合課程設(shè)計(jì)4、實(shí)驗(yàn)成績的構(gòu)成比例和考核方式

3、。30% 上機(jī)實(shí)驗(yàn)。 填表日期： 2014年 02月 25日 教案時間安排第 周 ，總第 次課 章節(jié)名稱第一章 總攬（4次課）教學(xué)目的講解軟件工程三個基本要素，通過比較各種軟件工程方法的優(yōu)缺點(diǎn)來給出面向?qū)ο筌浖こ谭椒ㄕ摗Ｍ瑫r講解各種軟件過程模型，以及uml建模語言的相關(guān)知識。教學(xué)重點(diǎn)與難點(diǎn)軟件工程的三個基本要素面向?qū)ο筌浖こ趟枷?，學(xué)會以對象的方式來思考問題uml表示法教學(xué)內(nèi)容與過程設(shè)計(jì)教學(xué)內(nèi)容與過程設(shè)計(jì)軟件工程的成果是為軟件設(shè)計(jì)和開發(fā)人員提供思想方法和工具，而軟件開發(fā)是一項(xiàng)需要良好組織、嚴(yán)密管理且各方面人員配合協(xié)作的復(fù)雜工作。軟件工程正是指導(dǎo)這項(xiàng)工程的一門科學(xué)。一、軟件工程知識體系（1）需

4、求定義為解決真實(shí)世界問題而必須展示的特性。（2）設(shè)計(jì)既是“定義一個系統(tǒng)或組件的體系結(jié)構(gòu)、組件、接口和其它特征的過程”，又是“這個過程的結(jié)果”。（3）軟件構(gòu)造指通過編碼、驗(yàn)證、單元測試、集成測試和排錯的組合，詳細(xì)創(chuàng)建一個可以工作的、有意義的軟件。（4）軟件測試由在有限測試用例集合上，根據(jù)期望的行為，對程序的行為進(jìn)行的動態(tài)驗(yàn)證組成，測試用例是從實(shí)際上是無限的執(zhí)行域中適當(dāng)?shù)倪x擇出來的。（5）軟件一旦投入運(yùn)行，就可能出現(xiàn)異常，運(yùn)行環(huán)境可能發(fā)生改變，用戶會提出新的需求。生命周期的維護(hù)階段從軟件交付時開始，但維護(hù)活動出現(xiàn)得還要早。（6）軟件配置管理（software configuration manag

5、ement，scm）是為了系統(tǒng)地控制配置的變更和維護(hù)配置在整個系統(tǒng)的生命周期中的完整性和可追蹤性，而標(biāo)識軟件在時間上不同點(diǎn)的配置的學(xué)科。（7）軟件工程管理知識域處理軟件工程的管理與度量，雖然度量是所有知識域的一個重要方面，但在這里涉及的是度量程序的主題。（8）軟件工程過程的知識域涉及軟件工程過程本身的定義、實(shí)現(xiàn)、評定、度量、管理、變更和改進(jìn)。（9）軟件工程工具和方法知識域包括軟件工程工具、軟件工程方法。（10）軟件質(zhì)量知識域處理跨越軟件生命周期過程的軟件質(zhì)量的考慮，由于軟件質(zhì)量在軟件工程中無處不在，其它知識域也涉及質(zhì)量問題，讀者可以注意到本知識域到其它知識域的指示器?？己朔绞剑航M隊(duì)，通過在整個

6、項(xiàng)目的實(shí)施過程中不斷貫徹軟件工程的思想，達(dá)到培養(yǎng)團(tuán)隊(duì)開發(fā)的目的。討論：小組人數(shù)最好多于3人，這是基于以下事實(shí)：給延期的項(xiàng)目增加人手會使項(xiàng)目進(jìn)一步延期。因?yàn)橄蝽?xiàng)目中增加人手，就必須花時間來進(jìn)行培訓(xùn)。因此最終結(jié)果變成了：新增人員貢獻(xiàn)非常慢，即使他們的效率確實(shí)很高時，那也只是耗盡了原有程序員的時間和精力。而且，項(xiàng)目中的程序員越多，程序員之間的相互交流就越復(fù)雜。該事實(shí)詮釋了一部軟件工程經(jīng)典著作的書名，the mythical man-month即人月神話。該書指出：雖然我們采用人月（people per month）為單位來安排人手，但是每個人對軟件的貢獻(xiàn)各不相同，所以這些人月也不盡相同。在項(xiàng)目后期加

7、入的人員更是如此，這些人的貢獻(xiàn)幾乎可以忽略不計(jì)。二、軟件工程概述人物簡介：watts s.humphrey瓦茨·s·漢弗萊在軟件工程領(lǐng)域享有盛譽(yù)，被美國國防軟件工程雜志crosstalk評為近幾百年來影響軟件發(fā)展的十位大師之一。瓦茨·s·漢弗萊在ibm工作了27年，負(fù)責(zé)管理ibm全球產(chǎn)品研發(fā)。離任后，受美國國防部委托，加入卡內(nèi)基·梅隆大學(xué)軟件工程研究所（sei），領(lǐng)導(dǎo)sei過程研究計(jì)劃，并提出了能力成熟模型（cmm）思想。在cmm浪潮席卷軟件工業(yè)界之時，他又力推個人軟件過程（personal software process，psp）和團(tuán)隊(duì)軟件

8、過程（team software process，tsp），成為軟件開發(fā)人員和開發(fā)團(tuán)隊(duì)的自修寶典。強(qiáng)調(diào)：這里需要注意“復(fù)雜”兩個字，過于簡單的應(yīng)用沒有必要是結(jié)構(gòu)復(fù)雜化，高級的體系結(jié)構(gòu)、框架、設(shè)計(jì)模式都是為復(fù)雜系統(tǒng)準(zhǔn)備的。軟件的復(fù)雜性：軟件是一個龐大的邏輯系統(tǒng)，此外，軟件主要依靠人腦的“智力”構(gòu)造出來，多種人為因素使得軟件難以統(tǒng)一化，更增加了其復(fù)雜性。軟件的復(fù)雜性使得軟件產(chǎn)品難以理解，難以生產(chǎn)，難以維護(hù)，更難以對生產(chǎn)過程進(jìn)行管理。許多軟件項(xiàng)目在某些方面非常復(fù)雜。例如，軟件所涉足的應(yīng)用領(lǐng)域往往包含復(fù)雜的專業(yè)知識，而懂得應(yīng)用領(lǐng)域?qū)I(yè)知識的人很可能不是實(shí)際編寫軟件的人。所以，這些領(lǐng)域的專家必須和負(fù)責(zé)軟

9、件開發(fā)的技術(shù)人員交流自己的需求。交流的過程是復(fù)雜的，軟件開發(fā)人員只有在理解了用戶面臨的問題和需求后，才能動手開發(fā)軟件。最后，許多進(jìn)行中的軟件項(xiàng)目規(guī)模非常大，不可能由一個人獨(dú)立完成，因而開發(fā)技術(shù)小組必須將開發(fā)任務(wù)分成易于管理的模塊，當(dāng)各個部分全部完成后，將它們組裝成可以協(xié)同工作的整體。將一個大項(xiàng)目分割成幾個小部分，每個小部分由不同的人來開發(fā)，并且保證這些部分可以在一起工作，這個工程成為軟件開發(fā)過程另一個復(fù)雜的來源。軟件發(fā)展過程強(qiáng)調(diào)軟件工程學(xué)科的發(fā)展沒有停止，而且這里面沒有教條，只有實(shí)踐。舉例：1、倫敦股票交易系統(tǒng)當(dāng)初預(yù)算4.5億英鎊，后來追加到7.5億英鎊，歷時五年，但最終還是失敗，導(dǎo)致倫敦股票

10、市場聲譽(yù)下跌。2、2007年北京機(jī)場信息系統(tǒng)癱瘓。2007年10月10日13時28分，設(shè)在北京首都國際機(jī)場的中國民航信息網(wǎng)絡(luò)股份公司離港系統(tǒng)突然發(fā)生故障，短短50分鐘內(nèi)，北京、廣州、深圳、長沙機(jī)場至少84個離港航班發(fā)生延誤。該系統(tǒng)是由美國某家公司研發(fā)，此事件引發(fā)信息系統(tǒng)安全的擔(dān)憂。3、2008年北京奧運(yùn)會售票系統(tǒng)于2007年10月30日上午11時癱瘓：北京奧運(yùn)會的指定獨(dú)家票務(wù)供應(yīng)商北京歌華特瑪捷票務(wù)公司成立于2006年9月，由美國特瑪捷公司、中體產(chǎn)業(yè)股份有限公司及北京歌華文化發(fā)展集團(tuán)三家出資構(gòu)建而成。售票系統(tǒng)癱瘓事件發(fā)生后，公眾普遍質(zhì)疑該公司是否具備承擔(dān)08年北京奧運(yùn)會的票務(wù)銷售能力。三、軟件

11、工程三個要素方法、工具、過程。軟件工程是一門建立在以質(zhì)量焦點(diǎn)為基礎(chǔ)，分過程、方法和工具三個研究層次的綜合技術(shù)。軟件工程的基層是過程層，軟件過程層是將方法和技術(shù)結(jié)合在一起的凝聚層，使得軟件能夠合理地、及時地開發(fā)出來。軟件方法：在軟件開發(fā)過程中所采用的技術(shù)，例如結(jié)構(gòu)化的方法、面向?qū)ο蟮姆椒ā＼浖^程：在軟件產(chǎn)品生產(chǎn)過程中，軟件人員所進(jìn)行的一系列的軟件工程活動。軟件工具：在軟件開發(fā)過程中為了實(shí)現(xiàn)某些方法而采用的手段，例如case工具，uml以及rose等。討論：一個有爭議的觀點(diǎn)：在軟件開發(fā)中，最重要的因素不是程序員采用的工具、技術(shù)和語言，也不是過程，而是程序員自身的質(zhì)量。這一觀點(diǎn)來源于peoplew

12、are人件。其中說道“我們工作中最重要的問題與其說是技術(shù)問題，還不如說它本質(zhì)上是社會問題?！辈⑻岢隽恕叭藛T的作用遠(yuǎn)遠(yuǎn)大于其他任何因素”。這本書還有一些獨(dú)到的見解，比如“工作環(huán)境對工作效率和產(chǎn)品質(zhì)量也有影響”。例如，“最好團(tuán)隊(duì)的工作空間是最差團(tuán)隊(duì)的1.7倍（測量可用地板空間），而最好團(tuán)隊(duì)的表現(xiàn)是最差團(tuán)隊(duì)的2.6倍。軟件工程的基本原理1. 用分階段的生命周期計(jì)劃嚴(yán)格管理2. 堅(jiān)持進(jìn)行階段評審3. 實(shí)行嚴(yán)格的產(chǎn)品控制4. 采用現(xiàn)代程序設(shè)計(jì)技術(shù)5. 結(jié)果應(yīng)能清楚地審查6. 開發(fā)小組的人員應(yīng)該少而精7. 承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性四、軟件方法論軟件描述的就是現(xiàn)實(shí)業(yè)務(wù)在計(jì)算機(jī)中的映射，說起來簡單，做

13、起來很難。因?yàn)楝F(xiàn)實(shí)業(yè)務(wù)越來越復(fù)雜，而用戶希望對軟件的操作是越直接越好。軟件分析設(shè)計(jì)方法的演變：1、沒有方法。即意大利面條：spaghetti code，意指包含復(fù)雜龐大控制結(jié)構(gòu)，雜亂無章的代碼，特別是大量使用goto語句的代碼等等。2、功能分解法功能分解功能子功能功能接口以系統(tǒng)需要提供的功能為中心來組織系統(tǒng)。適用于功能穩(wěn)定的應(yīng)用領(lǐng)域，如科學(xué)計(jì)算等。缺點(diǎn)：開頭容易，結(jié)束難。對眾多領(lǐng)域而言，功能易變。如企業(yè)管理和商業(yè)管理。對需求變化的適應(yīng)能力很差。局部錯誤和局部修改很容易產(chǎn)生全局性的影響。重視功能，忽略數(shù)據(jù)。【舉例】工資支付系統(tǒng)：更新工資信息；發(fā)放工資。更新工資信息：檢查員工信息；提交工作記錄；計(jì)

14、算應(yīng)發(fā)工資。發(fā)放工資：檢查員工信息；計(jì)算應(yīng)發(fā)工資；打印工資單；登記領(lǐng)取。3、數(shù)據(jù)流法：又稱作結(jié)構(gòu)化分析?；静呗允歉檾?shù)據(jù)流，即研究問題域中數(shù)據(jù)如何流動以及在各個環(huán)節(jié)上進(jìn)行何種處理，從而發(fā)現(xiàn)數(shù)據(jù)流和加工。4、信息建模法：信息建模實(shí)體（對象）屬性關(guān)系父類型/子類型關(guān)聯(lián)對象由實(shí)體關(guān)系法發(fā)展而來。與數(shù)據(jù)庫設(shè)計(jì)有很深的淵源。核心概念是實(shí)體和關(guān)系，實(shí)體描述問題域的事物，包含屬性。關(guān)系描述事物之間在數(shù)據(jù)方面的聯(lián)系，也可以帶有屬性。重視實(shí)體，而忽略功能。5、面向?qū)ο蠓椒ǎ好嫦驅(qū)ο蠓椒ǖ某霭l(fā)點(diǎn)和基本原則，是盡可能模擬人類習(xí)慣的思維方式，使開發(fā)軟件的方法與過程盡可能接近人類認(rèn)識世界解決問題的方法與過程，也就是使

15、描述問題的問題空間(也稱為問題域)與實(shí)現(xiàn)解法的解空間(也稱為求解域)在結(jié)構(gòu)上盡可能一致。五、面向?qū)ο蟮幕靖拍睿?）對象在應(yīng)用領(lǐng)域中有意義的、與所要解決的問題有關(guān)系的任何事物都可以作為對象，它既可以是具體的物理實(shí)體的抽象，也可以是人為的概念，或者是任何有明確邊界和意義的東西。例如，一名職工、一家公司、一個窗口、一座圖書館、一本圖書、貸款和借款等，都可以作為一個對象?？傊瑢ο笫菍栴}域中某個實(shí)體的抽象，設(shè)立某個對象就反映了軟件系統(tǒng)保存有關(guān)它的信息，并具有與它進(jìn)行交互的能力。對象的定義對象是封裝了數(shù)據(jù)結(jié)構(gòu)及可以施加在這些數(shù)據(jù)結(jié)構(gòu)上的操作的封裝體，這個封裝體有可以唯一標(biāo)識它的名字，而且向外界提供一

16、組服務(wù)。屬性表示對象的性質(zhì)，屬性值規(guī)定了對象所有可能的狀態(tài)。對象的操作是指該對象可以展現(xiàn)的外部服務(wù)。例如，大型客機(jī)可視為對象，它具有位置、速度、顏色、容量等屬性，對于該對象可施行起飛、降落、加速、維修等操作，這些操作將或多或少地改變飛機(jī)的屬性值(狀態(tài))。（2）類是具有相同數(shù)據(jù)結(jié)構(gòu)和相同操作的一組相似對象的抽象。即表示某些對象在屬性和操作方面的共同特征。例如：直升飛機(jī)、大型客機(jī)、轟炸機(jī)可歸為飛行器類。共同屬性有：位置、速度和顏色等共同操作有：起飛、降落、加速和維修等類是在對象之上的抽象，有了類以后，對象則是類的具體化，是類的實(shí)例。把一組對象的共同特性加以抽象并存貯在一個類中的能力，是面向?qū)ο蠹夹g(shù)

17、最重要的一點(diǎn)！（3）消息對象之間進(jìn)行通訊的一種構(gòu)造叫做消息。 當(dāng)一個消息發(fā)送給某個對象時，包含要求接收對象去執(zhí)行某些活動的信息。接收到消息的對象經(jīng)過解釋，然后予以響應(yīng)。這種通訊機(jī)制叫做消息傳遞。發(fā)送消息的對象不需要知道接收消息的對象如何對請求予以響應(yīng)。訪問一個方法的過程稱為向這個對象發(fā)送一個消息。例如：mycircle.show(green)，mycircle是接收消息的對象的名字，show是消息名，green是消息的變元。消息的理解a）如何要求對象完成一定的處理動作？對象間如何進(jìn)行聯(lián)系？所有這一切都只能通過消息傳遞來實(shí)現(xiàn)。b）傳遞消息的對象稱為發(fā)送者，接受消息的對象稱為接受者。c）消息中只包

18、含傳遞者的要求，它告訴接受者需要哪些處理，但并不指示接受者應(yīng)該怎樣完成這些處理。d）消息完全由接受者解釋，接受者獨(dú)立決定采用什么方式完成所需的處理，發(fā)送者對接受者不起任何控制作用。（4）封裝封裝幫助你管理復(fù)雜度的方法是不讓你看到那些復(fù)雜度。在面向?qū)ο蟮某绦蛑?，把?shù)據(jù)和實(shí)現(xiàn)操作的代碼集中起來放在對象內(nèi)部。一個對象好像是一個不透明的黑盒子，表示對象狀態(tài)的數(shù)據(jù)和實(shí)現(xiàn)操作的代碼與局部數(shù)據(jù)都被封裝在黑盒子里面，從外面是看不見的，更不能從外面直接訪問和修改這些數(shù)據(jù)和代碼。使用對象的時候只需要知道他向外界提供的接口的形式，無須知道它的數(shù)據(jù)結(jié)構(gòu)細(xì)節(jié)和實(shí)現(xiàn)操作的算法。信息隱藏的一個例子：假設(shè)你有一個程序，其中的

19、每個對象都是通過一個名為id的成員變量來保存一種唯一的id。這種設(shè)計(jì)方法是用一個整數(shù)來表示id，同時用一個名為g_maxid的全局變量來保存目前已分配的id的最大值。每當(dāng)創(chuàng)建新的對象時，你只要在該對象的構(gòu)造函數(shù)中簡單地使用id=+ g_maxid，就肯定能獲得一個唯一的id值，這樣設(shè)計(jì)有沒有問題？問題：1、如果你想把某些范圍的id留做它用該怎么辦？2、如果你想使用非連續(xù)的id來提高安全性？3、如果你想重新使用已銷毀對象的id？4、如果你的程序是多線程的，這種方法也不是線程安全的。創(chuàng)建新id的方法就是一種你應(yīng)該隱藏起來的設(shè)計(jì)決策。如果你在程序中到處使用+ g_maxid，你就暴露了創(chuàng)建新id的方

20、法。相反，如果你在程序中都使用id=newid()，那么就把創(chuàng)建新id的方法隱藏起來了。再假設(shè)你發(fā)現(xiàn)需要把id的類型由整型改為字符串。此時你會想到應(yīng)該隱藏id的類型。在c+里面，你可以簡單地使用typedef把id定義為idtype，或者定義一個idtype的類。（5）繼承廣義地說，繼承是指能夠直接獲得已有的性質(zhì)和特征，而不必重復(fù)定義它們。在面向?qū)ο蠹夹g(shù)中，繼承是子類自動地共享基類中定義的數(shù)據(jù)和方法的機(jī)制。（6）多態(tài)“this ability to manipulate more than one type with a pointer or a reference to a base cla

21、ssis spoken of as polymorphism” (c+ primer第838頁)。即用基類的指針/引用來操作多種類(基類和其派生類)的對象的能力稱之為多態(tài)。它是從語言實(shí)現(xiàn)的角度來考慮的?！皃olymorphism provides another dimension of separation of interface from implementation, to decouple what from how”(think in java3rd edtion)，即多態(tài)提供了另外一種分離接口和實(shí)現(xiàn)的尺度，即把“做什么”與“怎么做”分開 。它是從設(shè)計(jì)的角度考慮的。 “the ab

22、ility to use the same expression to denote different operations is refered to as polymorphism”，(object-oriented methods principles & practice3rd edition，第16頁)。簡單的說，多態(tài)就是“相同的表達(dá)式，不同的操作”，也可以說成“相同的命令，不同的操作”。這是從面向?qū)ο蟮恼Z義的角度來看的。三種說法分別從不同的角度來闡述了多態(tài)的實(shí)質(zhì)。其中第三種說法尤為確切：相同的表達(dá)式函數(shù)調(diào)用不同的操作根據(jù)不同的對象就有不同的操作比如在公司中有各種職責(zé)不同的

23、員工(程序員，業(yè)務(wù)員，文管等)，他們“上班”時，做不同的事情(也可以看作是一種業(yè)務(wù)邏輯)，我們把他們各自的工作都抽象為"上班"，關(guān)系如下： 不恰當(dāng)?shù)谋扔鳎簅o的精髓是繼承、封裝和多態(tài)。繼承就是說：你的愛人會繼承做你女朋友時的相當(dāng)多的優(yōu)點(diǎn)，因?yàn)檫@些優(yōu)點(diǎn)對你都是public的，但同時她也會繼承以前的更多的缺點(diǎn)，因?yàn)槠渲泻芏嗳秉c(diǎn)對你是protected，繼承后才讓你能訪問。 封裝就是說：許多不想讓你知道的東西她會封裝起來，你只能通過她提供的有限的接口來訪問到被接口函數(shù)做了手腳的東西。多態(tài)就是說：在她心情不同時，你去訪問以她為參數(shù)的一個函數(shù)得到的結(jié)果是不同的。比如對她說“我愛你”。

24、六、軟件過程過程模型的思想只有兩種：順序和迭代。順序：一年的時間，分成4個階段，每個階段完成一項(xiàng)任務(wù)。迭代：一年的時間，分成4個階段，每個階段作為一次迭代周期，每個迭代周期完成一系列任務(wù)。選擇順序方法的理由：1、需求相當(dāng)穩(wěn)定2、設(shè)計(jì)直截了當(dāng)，而且理解透徹。3、開發(fā)團(tuán)隊(duì)對于這一應(yīng)用領(lǐng)域非常熟悉。4、項(xiàng)目的風(fēng)險很小。5、后期改變需求，設(shè)計(jì)和編碼的代價很可能較昂貴。選擇迭代方法的理由：1、需求并沒有被理解透徹，或者出于其他理由你認(rèn)為它是不穩(wěn)定的。2、設(shè)計(jì)很復(fù)雜，或者有挑戰(zhàn)性。3、開發(fā)團(tuán)隊(duì)對于這一應(yīng)用領(lǐng)域不熟悉。4、項(xiàng)目包含許多風(fēng)險。5、后期改變需求，設(shè)計(jì)和編碼的代價很可能較低。1、瀑布模型瀑布模型的

25、特點(diǎn)：階段間具有順序性和依賴性；盡可能推遲程序的物理實(shí)現(xiàn)；基于文檔驅(qū)動的模型。瀑布模型的缺點(diǎn)：傳統(tǒng)的瀑布模型過于理想化，實(shí)際的瀑布模型是帶“反饋環(huán)”的。需求具有變更性，無法在最初就準(zhǔn)確無誤的確定下來。最終開發(fā)出的軟件產(chǎn)品可能并不是用戶真正需要的。所以瀑布模型的采用，一定要保證需求必須是準(zhǔn)確定義和相對穩(wěn)定的。2、快速原型模型快速原型模型是不帶反饋環(huán)的，軟件產(chǎn)品的開發(fā)基本上是線性順序進(jìn)行的。因?yàn)樵拖到y(tǒng)已經(jīng)通過與用戶交互而得到驗(yàn)證，據(jù)此產(chǎn)生的規(guī)格說明文檔正確地描述了用戶需求?？焖僭湍Ｐ偷谋举|(zhì)就是“快速”，一旦需求確定了，原型將被拋棄。制作原型：制作原型是指開發(fā)出系統(tǒng)中關(guān)鍵功能的實(shí)際模型。例如開發(fā)

26、出一部分用戶界面的原型可以判斷系統(tǒng)的可用性，開發(fā)出關(guān)鍵算法的原型可以確定功能的執(zhí)行時間，開發(fā)出典型數(shù)據(jù)集的原型能知道程序的內(nèi)存需求。3、增量模型把軟件產(chǎn)品作為一系列的增量構(gòu)件來設(shè)計(jì)、編碼、集成和測試。通常，第一個增量構(gòu)件往往實(shí)現(xiàn)軟件的基本需求，提供最核心的功能。交付產(chǎn)品時采用分批逐步向用戶提交產(chǎn)品，而不是一次性交付產(chǎn)品。使用增量模型的困難是，在把每個新的增量構(gòu)件集成到現(xiàn)有軟件體系結(jié)構(gòu)中時，必須不破壞原來已經(jīng)開發(fā)的產(chǎn)品。因此必須把軟件的體系結(jié)構(gòu)設(shè)計(jì)得具有開放性和擴(kuò)充性。增量模型具有可在軟件開發(fā)的早期階段使投資獲得明顯回報和較易維護(hù)的優(yōu)點(diǎn)。在進(jìn)行增量開發(fā)時，我們先做出軟件系統(tǒng)的一個盡可能簡單、但能

27、運(yùn)行的版本。它不必接受真實(shí)的輸入，也無需對數(shù)據(jù)進(jìn)行真正的處理，更不用產(chǎn)生真實(shí)的輸出它僅僅需要構(gòu)成一個足夠強(qiáng)壯的骨架，支撐起未來將要開發(fā)的真實(shí)系統(tǒng)。在骨架形成之后，你要一點(diǎn)點(diǎn)地在其上附著肌肉和皮膚：把每個虛假的類替換為真正的類；不再假裝接受輸入，而是把接收真實(shí)輸入的代碼替換進(jìn)去；不再假裝產(chǎn)生輸出，而是把產(chǎn)生真實(shí)輸出的代碼替換進(jìn)去。你一次增加一小部分代碼，直到得到一個完全可以工作的系統(tǒng)?！九e例】采用增量模型開發(fā)的字處理軟件，在第1個增量中提供基本的文件管理、編輯和文檔生成功能；在第2個增量中提供復(fù)雜的編輯和文檔生成功能；在第3個增量中提供拼寫和語法檢查功能；在第4個增量中提供高級頁面排版功能。4、

28、螺旋模型螺旋模型可以理解為帶有風(fēng)險分析過程的快速原型模型。構(gòu)建原型是一種能使某些類型的風(fēng)險降至最低的方法，但原型不能“包治百病”，對于某些類型的風(fēng)險（例如，聘請不到需要的專業(yè)人員，或關(guān)鍵的技術(shù)人員在項(xiàng)目完成前“跳槽”），原型方法是無能為力的。螺旋模型的基本思想是：使用原型及其他方法來盡量降低風(fēng)險。即每個階段之前都增加了風(fēng)險分析過程和快速原型模型。5、噴泉模型“噴泉”體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性。因?yàn)橛妹嫦驅(qū)ο蠓椒ㄩ_發(fā)軟件時，在分析、設(shè)計(jì)和編碼等項(xiàng)開發(fā)活動之間并不存在明顯的邊界。舉例：如何進(jìn)行迭代和進(jìn)化式分析和設(shè)計(jì)。假設(shè)在項(xiàng)目交付前，最終將有20次迭代。1）在第1次迭代之前，召開第

29、一個時間定量的需求工作會議，例如確切的定義為兩天時間。業(yè)務(wù)和開發(fā)人員（包括首席架構(gòu)師）需要出席。在第一天上午，進(jìn)行高階需求分析，例如僅僅確定用例和特性的名稱，以及關(guān)鍵的非功能性需求。這種分析不可能是完美的。通過咨詢首席架構(gòu)師和業(yè)務(wù)人員，從高階列表中選擇10列表項(xiàng)，假設(shè)為3個用例，這些項(xiàng)目需要具備以下三種性質(zhì)：1、具有重要的架構(gòu)意義，2、具有高業(yè)務(wù)價值。3、具有高風(fēng)險。在剩下的一天半內(nèi)，對這3個用例的功能和非功能性需求進(jìn)行詳細(xì)的分析。完成這一過程后，對10進(jìn)行了深入分析，90進(jìn)行了高階分析。2）在第一次迭代之前，召開迭代計(jì)劃會議，選擇3個用例的子集，在特定時間內(nèi)進(jìn)行設(shè)計(jì)、構(gòu)造和測試。3）在三到四

30、周內(nèi)完成第一次迭代（選擇時間定量，并嚴(yán)格遵守時間）。在開始兩天內(nèi)，開發(fā)者和其他成員分組進(jìn)行建模和設(shè)計(jì)工作，畫出uml草圖。然后，開發(fā)者摘掉其“建模帽子”并帶上“編程帽子”，開始編程、測試和集成工作并且剩余的時間均用于完成這項(xiàng)工作。進(jìn)行大量的測試，包括單元測試、驗(yàn)收測試、負(fù)載測試和可用性測試。在結(jié)束前的一周，檢查是否能夠完成初始的迭代目標(biāo)；如果不能，則縮小迭代范圍，將次要目標(biāo)置回任務(wù)列表中。在最后一周的星期二，凍結(jié)代碼，必須檢入、集成和測試所有代碼，以建立迭代的基線。4）在第一次迭代即將結(jié)束時，召開第二次需求工作會，對上一次會議的所有材料進(jìn)行復(fù)查和精化。然后選擇具有重要架構(gòu)意義和高業(yè)務(wù)價值的另外

31、10到15的用例，用一到兩天對其進(jìn)行詳細(xì)分析。這項(xiàng)工作完成后，會詳細(xì)記錄大概25的用例和非功能性需求。當(dāng)然，這也不是完美的。5）與周五上午，舉行下一次迭代的迭代計(jì)劃會議。6）以相同的步驟進(jìn)行第2次迭代。7）反復(fù)進(jìn)行四次迭代和五次需求工作會，這樣在第4次迭代結(jié)束時，可能已經(jīng)詳細(xì)記錄了約8090的需求，但是只實(shí)現(xiàn)了系統(tǒng)的10。8）我們大概推進(jìn)了整個項(xiàng)目過程的20。在up的術(shù)語里，這是細(xì)化階段的結(jié)束。9）此后，一般不需要再召開需求工作會；需求已經(jīng)穩(wěn)定了。接下來是一系列為期三周的迭代，在最后一個周五召開的迭代計(jì)劃會上選擇適宜的下一步工作。總結(jié)：最重要的up思想迭代開發(fā)在這種方法中，開發(fā)被組織成一系列固

32、定的短期小項(xiàng)目，稱為迭代；每次迭代都產(chǎn)生經(jīng)過測試的、經(jīng)過集成的和可執(zhí)行的系統(tǒng)。每次迭代都有自己的需求分析、設(shè)計(jì)、實(shí)現(xiàn)和測試活動。迭代的輸出不是實(shí)驗(yàn)性或?qū)G棄的原型，迭代開發(fā)也不是原型開發(fā)。與之相反，其輸出是最終系統(tǒng)的產(chǎn)品的子集。迭代開發(fā)不是要通過在實(shí)現(xiàn)前試圖完整和正確地描述、凍結(jié)和“終止”一個已凍結(jié)的需求集和設(shè)計(jì)來應(yīng)對軟件開發(fā)中出現(xiàn)的不可避免的變更，而是要基于擁抱變更和適應(yīng)調(diào)整的態(tài)度將變更和調(diào)整作為迭代開發(fā)中不能避免且真正必要的驅(qū)動力。每次迭代選擇一小組需求，并快速設(shè)計(jì)、實(shí)現(xiàn)和測試，可以得到快速的反饋來自用戶、開發(fā)人員和測試（例如負(fù)載測試和可用性測試）的反饋。迭代開發(fā)的優(yōu)點(diǎn)：1、 在早期而不是

33、晚期緩解高風(fēng)險（技術(shù)、需求、目標(biāo)、可用性等方面的風(fēng)險）。2、 早期可見的發(fā)展。3、 早期反饋、用戶參與和調(diào)整，會得到一個更接近項(xiàng)目相關(guān)人員真實(shí)需求的經(jīng)過精化的系統(tǒng)。4、 可控復(fù)雜性；開發(fā)組不會被“分析癱瘓”或長期復(fù)雜過程所淹沒。5、 在一次迭代中學(xué)到的知識可以被有系統(tǒng)地用于改進(jìn)開發(fā)過程本身，下一次迭代也是如此，依次類推，進(jìn)行下去。up階段和流程（1） 初始階段：大體上的構(gòu)想，業(yè)務(wù)案例，范圍，模糊評估。（2） 細(xì)化階段：已精化的構(gòu)想，核心架構(gòu)的迭代實(shí)現(xiàn)，高風(fēng)險的解決，大多數(shù)需求和范圍的識別，更為現(xiàn)實(shí)的評估。（3） 構(gòu)造階段：迭代實(shí)現(xiàn)遺留下來的風(fēng)險較低和比較容易的元素，準(zhǔn)備部署。（4） 移交階段：

34、beta測試，部署。細(xì)化階段的一些關(guān)鍵思想和最佳實(shí)踐包括：1、 做短時間分區(qū)的、風(fēng)險驅(qū)動的迭代。2、 盡早開始編程。3、 適應(yīng)性地設(shè)計(jì)、實(shí)現(xiàn)并測試架構(gòu)的核心和風(fēng)險部分。4、 盡早、經(jīng)常、實(shí)際地測試。5、 基于來自測試、用戶、開發(fā)人員的反饋信息進(jìn)行調(diào)整。6、 通過一系列的研討會，每個細(xì)化迭代一次，詳細(xì)編寫大部分用例和需求。細(xì)化階段中在架構(gòu)方面重要的是什么：1、早期的迭代建立和證明核心架構(gòu)。（1）采用“寬且淺”的設(shè)計(jì)和實(shí)現(xiàn)方案。即識別單獨(dú)的過程、層、軟件包和子系統(tǒng)以及它們高層的職責(zé)和接口，為了連接它們以及闡明接口而部分實(shí)現(xiàn)它們。（2）細(xì)化模塊間的本地和遠(yuǎn)程接口。（3）集成已有的組件。2、為了得到反

35、饋信息，調(diào)整并證明核心架構(gòu)是健壯的，細(xì)化階段測試是重要的。七、軟件工具：umluml也稱為統(tǒng)一建模語言。它提供了一個可視化的建模語言，所謂可視化即通過一些很直觀，容易理解的圖形化來描述系統(tǒng)。因此用uml實(shí)現(xiàn)的文檔形式為：“圖形化文本描述 相應(yīng)文檔”uml語言很全面，龐大，可以表示各種復(fù)雜的問題。這樣一個豐富的語言，我們只需要用其20%部分，描述80的問題，因此學(xué)習(xí)中，我們只需要掌握常用的基本組成部分，關(guān)鍵是要對這些組成部分了解之后，能夠應(yīng)用他所提供的表示方法，進(jìn)行分析和設(shè)計(jì)。實(shí)際上在真正應(yīng)用里面，活用uml是非常關(guān)鍵的，雖然它是一個語言，但是應(yīng)用這個語言要根據(jù)分析設(shè)計(jì)里面需要描述設(shè)計(jì)模型的需要

36、來應(yīng)用。而不是說死記一些條目，很死板的去應(yīng)用。只有活用，才能感受到uml語言的威力。一個比喻：uml中所提供的標(biāo)準(zhǔn)的圖符，相當(dāng)于音樂五線譜里的樂符，學(xué)會看樂符才能看得懂樂譜，才能進(jìn)一步創(chuàng)造音樂。同樣，懂得uml中的圖符，才能進(jìn)行系統(tǒng)分析和設(shè)計(jì)。應(yīng)用uml的三種方式（1）uml作為草圖非正式的、不完整的圖（通常是在白板上手繪草圖），借助可視化語言的功能，用于探討問題或解決方案空間的復(fù)雜部分。（2）uml作為藍(lán)圖相對詳細(xì)的設(shè)計(jì)圖，用于：1）逆向工程，即以uml圖的方式對現(xiàn)有代碼進(jìn)行可視化，使其易于理解。2）代碼生成（前向工程），一般情況下，代碼生成工具使用圖生成一些代碼，然后由開發(fā)者編寫并填充其他

37、代碼。（3）uml作為編程語言用uml完成軟件系統(tǒng)可執(zhí)行規(guī)格說明?？蓤?zhí)行代碼能夠被自動生成，但并不像通常一樣為開發(fā)者所見或修改，但是目前在理論、工具的健壯性和可用性方面仍然處于發(fā)展階段。說明：uml和銀彈思想，即相信軟件中存在某種特殊的工具或技術(shù)，可以在生產(chǎn)率、缺陷減少、可靠性和簡易性等方面帶來極大的變化。工具無法彌補(bǔ)設(shè)計(jì)上的疏漏。uml的應(yīng)用對象建模是用例驅(qū)動（即建立用例模型，從分析到設(shè)計(jì)都是以用例為核心來設(shè)計(jì)）：優(yōu)勢于功能列表（不是站在用戶的角度考慮問題）以體系結(jié)構(gòu)為中心（整個系統(tǒng)中強(qiáng)調(diào)體系結(jié)構(gòu)的設(shè)計(jì)）迭代開發(fā)過程（由于開發(fā)過程不是一下子能夠全部完成的，強(qiáng)調(diào)迭代化的開發(fā)，可以在用例的設(shè)計(jì)過

38、程中不斷的設(shè)計(jì)和補(bǔ)充）41視圖在用uml語言建立相應(yīng)系統(tǒng)模型時，具體對于軟件系統(tǒng)是用什么樣的視圖描述，通常uml建議采用415 個視圖的描述。用例視圖：整個系統(tǒng)核心，它是從用戶角度對系統(tǒng)的參與和要求的交互過程。描述整個系統(tǒng)具有什么樣的功能。它也是后續(xù)設(shè)計(jì)、實(shí)現(xiàn)、實(shí)施、測試等等所有階段的核心和基礎(chǔ)，所有后續(xù)階段或其他視圖都以它為根本。邏輯視圖：描述該系統(tǒng)，即用例中的所有功能 ，其內(nèi)部結(jié)構(gòu)是什么，組成關(guān)系是什么。主要應(yīng)用于分析設(shè)計(jì)人員，建立相應(yīng)結(jié)構(gòu)。象靜態(tài)結(jié)構(gòu)方面：類，對象，及其關(guān)系；動態(tài)行為方面：并發(fā)，消息等相互聯(lián)系。建立了邏輯視圖之后，還要對系統(tǒng)進(jìn)程、并發(fā)等機(jī)制進(jìn)行描述。進(jìn)程視圖：處理并發(fā)和同

39、步的線程和進(jìn)程。實(shí)現(xiàn)視圖：具體開發(fā)時，怎樣把大的復(fù)雜系統(tǒng)分解成若干小的不同系統(tǒng)，進(jìn)行搭建，或不同組件進(jìn)行組合。一般大系統(tǒng)可能有不同組件，到底有哪些組件，哪些文件，這些組件，這些文件怎樣連接，構(gòu)成所要實(shí)現(xiàn)的系統(tǒng)。分布視圖：系統(tǒng)開發(fā)完成后，系統(tǒng)可能是在分布式環(huán)境、網(wǎng)絡(luò)環(huán)境下運(yùn)行，系統(tǒng)不同部分在網(wǎng)絡(luò)環(huán)境下怎樣分布、布置，在部署視圖中提供?？偨Y(jié)：由這樣5個視圖從不同方面完整的表示了系統(tǒng)的所有功能和需要提供各個方面的要求。uml的組成：uml的詞匯表包括3種構(gòu)造模塊：元素、關(guān)系、圖。（1）元素：模型中重要的抽象。結(jié)構(gòu)元素：uml模型中的名詞。是模型中主要的靜態(tài)部分，代表了概念的或物理的元素。1、用例與協(xié)

40、作：前面講過的用例是表示系統(tǒng)要實(shí)現(xiàn)的一個具體功能，要完成這個功能，實(shí)際需要一組對象類，及其對象類之間的互相關(guān)聯(lián)來實(shí)現(xiàn)的，因此協(xié)作是對具體用例的實(shí)現(xiàn)進(jìn)行建模，表示方法為虛橢圓。區(qū)別： 用例只是描述對外呈獻(xiàn)的行為，不關(guān)心這些具體功能是怎樣實(shí)現(xiàn)的，而協(xié)作描述要實(shí)現(xiàn)這個用例的功能，具體需要哪些類，類與類之間的關(guān)系怎樣。因此用例和協(xié)作之間是實(shí)現(xiàn)的關(guān)系。2、主動類：在類里面有一種類和一般類有一定區(qū)別，這種類具有主動的行為，一般來講它可以主動的啟動一些控制的活動，對實(shí)現(xiàn)來說它通常擁有一個進(jìn)程或線程。它的表示方式是在外邊框加粗。例如：事件管理器，它對事件隊(duì)列有掛起，刷新功能，該類有一個進(jìn)程對應(yīng)，有主動控制的行

41、為，稱為主動類。3、構(gòu)件：在大的系統(tǒng)開發(fā)過程中，往往把復(fù)雜的系統(tǒng)分成不同的構(gòu)件，所以系統(tǒng)里面真正可以替代的構(gòu)件在uml里面也有相應(yīng)的描述，構(gòu)件往往和接口一起使用的，因?yàn)槿魏螛?gòu)件的對外服務(wù)都是通過接口來描述的。行為元素：uml模型中的動態(tài)部分，它是模型中的動詞，代表了跨越時間和空間的行為。uml中有兩種主要的行為元素：交互作用（interaction）和狀態(tài)機(jī)（state machine）。1、 交互作用：由在特定上下文中為完成特定目的而在對象間交換的消息集組成的行為。交互作用包括許多其他元素：消息、動作序列（由消息激活的行為）、連接（對象間的連接）。2、狀態(tài)機(jī)：對象真正在創(chuàng)建到消亡的過程中，即

42、實(shí)際生命周期里，是通過響應(yīng)一定的事件，經(jīng)歷了不同的狀態(tài)，所以狀態(tài)機(jī)來描述對象所經(jīng)歷的狀態(tài)的序列，及觸發(fā)狀態(tài)變化的事件。例如：命令處理的狀態(tài)轉(zhuǎn)換。開始系統(tǒng)一啟動，進(jìn)入初始狀態(tài)，在初始狀態(tài)進(jìn)行初始化，準(zhǔn)備工作；初始化完成后，進(jìn)入空閑狀態(tài)，循環(huán)等待輸入的狀態(tài)。如果接收了鍵盤輸入，就使得系統(tǒng)從空閑狀態(tài)進(jìn)入命令處理狀態(tài)，可能一個命令是由多個字符組成，所以它在接收相應(yīng)按鍵之后把相應(yīng)字符存入命令隊(duì)列中，然后返回空閑狀態(tài)，當(dāng)下一次再有按鍵進(jìn)入時，又繼續(xù)進(jìn)行處理，如果完整的命令輸入完之后，可能要調(diào)用相應(yīng)的命令處理程序執(zhí)行，如果命令是一個結(jié)束的命令，則整個狀態(tài)機(jī)就結(jié)束了。所以狀態(tài)機(jī)有一個開始狀態(tài)，多個結(jié)束狀態(tài)，中

43、間還有不同的中間狀態(tài)，每個狀態(tài)轉(zhuǎn)換都有相應(yīng)的事件觸發(fā)。分組元素：是uml模型中用來組織元素的元素。在基本的事物組成中，經(jīng)常把大量事物通過分包的方式進(jìn)行組合。包：把一類基本元素分類，按照分包的原則可以各種各樣。注釋元素：是uml模型中解釋性的部分。（2）關(guān)系：事物之間的連接。真正要構(gòu)成一個系統(tǒng)，事物之間是有一些關(guān)系的。例如：課表和課程之間，課程可以加到課表里，或從課表里刪除。課程變化時，課表相應(yīng)發(fā)生變化。課程和課表之間是依賴關(guān)系。關(guān)聯(lián)關(guān)系：屬性可見性。通常需要保持長期，穩(wěn)定存在的關(guān)系。依賴關(guān)系：非屬性可見性（局部、本地、全局可見性），通常只需要保持短期的，局部的關(guān)系。實(shí)現(xiàn)關(guān)系：把具體形式化的描述

44、與具體實(shí)現(xiàn)分離的方法。好處：把對外的形式化描述和具體實(shí)現(xiàn)分離，分離后如果內(nèi)部實(shí)現(xiàn)改變，只要對外形式化描述不變，跟外部交互連接的部分不受到影響。（3）圖：把事物通過關(guān)系連接起來形成圖。真正描述模型是用一個個圖來描述的。uml的9種圖：用例圖：定義了系統(tǒng)的功能需求，它完全是從系統(tǒng)的外部觀看系統(tǒng)功能，并不描述系統(tǒng)內(nèi)部對功能的具體實(shí)現(xiàn)。類圖：描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，表示系統(tǒng)中的類以及類與類之間的關(guān)系。對象圖：描述了一組對象以及它們之間的關(guān)系，表示類的對象實(shí)例。組件圖：描述組件以及它們之間的關(guān)系，表示系統(tǒng)的靜態(tài)實(shí)現(xiàn)視圖。具體系統(tǒng)可能劃分成不同組件和模塊，有哪些模塊，組件之間的關(guān)系怎樣由組件圖描述。例子：在課

45、程注冊管理系統(tǒng)中，有兩個子系統(tǒng)：收費(fèi)系統(tǒng)，注冊系統(tǒng)。注冊系統(tǒng)分為：課程組件，人員管理組件。注冊系統(tǒng)在課程注冊完后，通過接口調(diào)用收費(fèi)系統(tǒng)，將學(xué)生相應(yīng)注冊信息傳遞給收費(fèi)系統(tǒng)，形成對學(xué)生的收費(fèi)單，通知學(xué)生交費(fèi)。課程系統(tǒng)又通過接口管理相應(yīng)課程信息，即課程模塊。對于學(xué)生教師人員進(jìn)行管理。通過這兩個模塊，實(shí)現(xiàn)存取相應(yīng)人員和課程信息，最后實(shí)現(xiàn)相應(yīng)功能。部署圖：反映系統(tǒng)中軟件和硬件的物理架構(gòu)，表示系統(tǒng)運(yùn)行時的處理節(jié)點(diǎn)，以及節(jié)點(diǎn)中組件的配置。時序圖和協(xié)作圖：都表示一組對象之間的動態(tài)協(xié)作關(guān)系。其中時序圖反映對象之間發(fā)送消息的時間順序，協(xié)作圖反映收發(fā)消息的對象的結(jié)構(gòu)組織。時序圖和協(xié)作圖是同構(gòu)的，即兩者之間可以相互轉(zhuǎn)

46、換。狀態(tài)圖：強(qiáng)調(diào)同一個類里對象狀態(tài)變化過程，和相應(yīng)事件觸發(fā)過程。所謂狀態(tài)，是對對象屬性值的一種抽象。各對象之間相互觸發(fā)（即作用）就形成了一系列的狀態(tài)變化。我們把一個觸發(fā)行為稱作一個事件。對象對事件的響應(yīng)，取決于接受該觸發(fā)的對象當(dāng)時所處的狀態(tài)，響應(yīng)包括改變自己的狀態(tài)或者又形成一個新的觸發(fā)行為。狀態(tài)有持續(xù)性，它占用一段時間間隔。狀態(tài)與事件密不可分，一個事件分開兩個狀態(tài)，一個狀態(tài)隔開兩個事件。事件表示時刻，狀態(tài)代表時間間隔。活動圖：反映系統(tǒng)中從一個活動到另一個活動的流程，強(qiáng)調(diào)對象間的控制流程。八、敏捷宣言agile software 敏捷過程作為對慣例性過程的挑戰(zhàn)，由17位方法學(xué)家于2001年2月提

47、出。在該方法論中，他們提出了4項(xiàng)價值以鼓勵更好的開發(fā)軟件：1、個人和交互高于過程和工具。開發(fā)過程中，最重要的因素是必須考慮到開發(fā)者是如何在一起工作的，因?yàn)槿绻麄儾荒軘[正態(tài)度的話，最好的工具和過程也將會失去作用。2、可工作軟件高于詳盡的文檔。3、與客戶合作高于合同談判。只有客戶才能告訴開發(fā)者他們想要什么。與客戶建立合同是重要的，但合同不能代替相互之間的溝通。4、對變化及時做出響應(yīng)高于遵循計(jì)劃。變化是軟件開發(fā)的現(xiàn)實(shí)。教學(xué)后記*“教學(xué)后記”是授課完畢之后，教師對授課準(zhǔn)備情況、授課過程及授課效果的回顧與總結(jié)，因此，教師應(yīng)及時手寫補(bǔ)充完整本部分內(nèi)容。時間安排第 周 ，總第 次課章節(jié)名稱需求工程（4次課

48、）教學(xué)目的1、 需求的定義和需求的層次。2、 什么是用例，如何編寫用例。3、 如何構(gòu)建需求模型，如何編寫需求規(guī)格說明書。教學(xué)重點(diǎn)與難點(diǎn)1、需求捕獲的方法。2、用例。3、需求模型的構(gòu)建。4、需求規(guī)格說明書的編寫。教學(xué)內(nèi)容與過程設(shè)計(jì)教學(xué)內(nèi)容與過程設(shè)計(jì)啟動軟件項(xiàng)目是由于軟件需求的存在，資料表明，軟件項(xiàng)目中4060的問題都是在需求分析階段埋下的隱患。軟件開發(fā)中返工開銷占開發(fā)總費(fèi)用的40，而其中7080的返工是由需求方面的錯誤所導(dǎo)致。因此一個項(xiàng)目成功的關(guān)鍵因素之一就是對需求分析的把握程度。而項(xiàng)目的整體風(fēng)險往往表現(xiàn)在需求分析不明確，業(yè)務(wù)流程不合理，所以，需求分析是軟件開發(fā)的重要一環(huán)。軟件的需求具有模糊性、

49、不確定性、變化性和主觀性的特點(diǎn)，相比硬件的需求，是有形的、客觀的、可描述的、可檢測的。一、需求的定義需求，是指對用戶需要解決的問題的整體描述。需求是軟件實(shí)現(xiàn)之源，沒有了需求，軟件也就無從談起。在ieee軟件工程標(biāo)準(zhǔn)詞匯表中定義需求為：（1）用戶解決問題或達(dá)到目標(biāo)所需要的條件或能力（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文檔所需具有的條件或能力（3）一種反映上面（1）或（2）所描述條件或能力的文檔說明二、需求的層次軟件需求是指用戶對軟件的功能和性能的要求。軟件人員要準(zhǔn)確理解用戶的要求，進(jìn)行細(xì)致的調(diào)查分析，將用戶非形式化的需求陳述轉(zhuǎn)化為完整的需求定義，再由需求定義轉(zhuǎn)化到相應(yīng)形式的需

50、求規(guī)格說明。有時也可以將軟件需求按照層次來說明（如上圖）。業(yè)務(wù)需求：反映了組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們在項(xiàng)目視圖與范圍文檔中說明。用戶需求：用戶使用產(chǎn)品必須要完成的任務(wù)，它們通常使用用例文檔（use case）進(jìn)行說明。功能需求：開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。非功能需求：描述系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。包括：產(chǎn)品必須遵循的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計(jì)或?qū)崿F(xiàn)的約束條件；質(zhì)量屬性。通常也可以總結(jié)為 furps+：functional（功能性）：特性、功能、安全性。usability（可用性）：人性化因素

51、、幫助、文檔。reliability（可靠性）：故障頻率、可恢復(fù)性、可預(yù)測性。performance（性能）：響應(yīng)時間、吞吐量、準(zhǔn)確性、有效性、資源利用率。supportability（可支持性）：適應(yīng)性、可維護(hù)性、國際化、可配置性。：表示一些輔助性的和次要的因素，比如：實(shí)現(xiàn)（implementation）：資源限制、語言和工具、硬件等。接口（interface）：強(qiáng)加于外部系統(tǒng)接口之上的約束。操作（operation）：對其操作設(shè)置的系統(tǒng)管理。包裝（packaging）：例如物理的包裝盒。授權(quán)（legal）：許可證或其他方式。軟件需求規(guī)格：軟件需求規(guī)格充分描述了軟件系統(tǒng)應(yīng)具有的外部行為，它描

52、述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；非功能性需求（例如性能要求等）；設(shè)計(jì)或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。軟件需求規(guī)格說明在開發(fā)、測試、質(zhì)量保證、項(xiàng)目管理以及相關(guān)項(xiàng)目功能中都起到重要的作用。為了強(qiáng)調(diào)非功能需求，舉例說明：2月27日，中央電視臺“第一時間”報道了北京市二中院開庭審理程稚瀚涉嫌盜取北京移動通信公司充值卡密碼一案，程稚瀚曾是ut斯達(dá)康深圳分公司工程師，被指控利用網(wǎng)絡(luò)技術(shù)手段侵入北京移動通信公司充值中心數(shù)據(jù)庫，修改充值卡原始數(shù)據(jù)并竊取了充值卡密碼，并通過淘寶網(wǎng)和qq向他人出售，致使北京移動通信公司損失近380萬元。該欄目主持人認(rèn)為

53、：1.2億元網(wǎng)絡(luò)安全投入，居然不堪一擊，中國移動也該好好總結(jié)一下了。事實(shí)上，程稚瀚在作案過程中使用的大多都是些沒有技術(shù)含量的攻擊手段，但是偏偏沒有技術(shù)含量的攻擊事件，在電信、銀行、證券、保險業(yè)卻屢屢得逞另一個案例：兩大學(xué)生利用網(wǎng)通adsl用戶升級時系統(tǒng)的漏洞，在一個月內(nèi)盜取了價值70余萬元的網(wǎng)易一卡通虛擬游戲點(diǎn)卡。不能不令我們深思。三分技術(shù)，七分管理”的網(wǎng)絡(luò)安全體系建立原則幾乎被每個電信和銀行業(yè)的企業(yè)所強(qiáng)調(diào)，并成為指導(dǎo)其安全管理體系建設(shè)的基本原則。 三、需求工程20世紀(jì)80年代中期，形成了軟件工程的子領(lǐng)域需求工程。需求工程是指應(yīng)用已證實(shí)有效的技術(shù)、方法進(jìn)行需求分析，確定客戶需求，幫助分析人員理

54、解問題并定義目標(biāo)系統(tǒng)的所有外部特征的一門學(xué)科。四、需求問題的代價在早期階段，軟件是無形的，除了一些文檔性的規(guī)格說明以外沒有什么具體有形的東西，而且比較容易修改。但隨著時間的推移，軟件產(chǎn)品越來越詳細(xì)（在設(shè)計(jì)階段），越來越具體（在編碼階段），越來越固定（當(dāng)代碼逐漸接近最終的方案時）。在早期可以輕易改變的東西，越到后期就越難得多。很多人不理解這些前期準(zhǔn)備的重要性，其實(shí)我們可以把軟件過程比作食物鏈。其中程序員是軟件食物鏈的最后一環(huán)。架構(gòu)師吃掉需求，設(shè)計(jì)師吃掉架構(gòu)，而程序員則消化設(shè)計(jì)。在健康的生態(tài)環(huán)境中，海鷗吃新鮮的鮭魚。這對海鷗是營養(yǎng)豐富的大餐，因?yàn)轷q魚吃的是新鮮的青魚，而青魚吃的是新鮮的水蝽。這是一

55、條健康的食物鏈。在軟件開發(fā)中如果食物鏈的每一級都是健康的食物，那么最終由程序員編寫出的代碼也是健康的。而在受污染的環(huán)境中，水蝽在核廢料中游泳，青魚被聚氯聯(lián)二苯污染，而吃青魚的鮭魚又在泄漏的原油中游蕩。海鷗，就成為最不幸的了，因此它吃下去的不僅僅是不健康的鮭魚體內(nèi)的原油，還有青魚體內(nèi)的聚氯聯(lián)二苯和水蝽體內(nèi)的核廢料。在軟件開發(fā)中，如果需求污染了，它就會污染架構(gòu)，而架構(gòu)就會污染編碼。這樣會導(dǎo)致程序員脾氣暴躁、營養(yǎng)失調(diào)；開發(fā)出的軟件具有放射性污染，而且周身都是缺陷。五、需求面臨的困難“石頭”問題：說客戶常常會交給她一些項(xiàng)目，她稱之為“給我一塊石頭”?？墒钱?dāng)你把石頭交給客戶時，他會看一會“石頭”，然后說：“是的，但是，實(shí)際上我想要的是一塊小一點(diǎn)的藍(lán)色石頭?！倍?dāng)你交出一塊小一點(diǎn)的藍(lán)色石頭時，又會引發(fā)“一塊圓的小一點(diǎn)的藍(lán)色石頭”的要求。最終的結(jié)果可能是，客戶一直都在想要一塊小一點(diǎn)的藍(lán)色大理石或者他也許根本不能確定他到底要什么，而不是一塊小小的藍(lán)色大理石甚至是貓眼大小的藍(lán)色大理石就已經(jīng)足夠了。而他會在你交出第一塊（大的）石頭和第三塊（藍(lán)色的?。┦又g不斷改變對需求的想法。開發(fā)人員在與客戶會談時總會提這樣的問題：“你想要它做什么？”當(dāng)開發(fā)人員按照客戶預(yù)先的需求經(jīng)過艱苦努力終于交