復旦MSE復習資料-軟件工程部分(SE01 概論)

1、1軟件工程復旦大學MSE考前輔導2021年10月 2參考書?軟件工程：實踐者的研究方法第6版 ?美roger s.pressman(著) ，鄭人杰,馬素霞,白曉穎 等(譯) ，機械工業(yè)出版社，7111194004 |，2007-01-01軟件工程導論第四版張海潘 編著，清華大學出版社，2003軟件工程第二版齊治昌 譚慶平 寧洪著，高等教育出版社，2005實用軟件工程第二版鄭人杰、殷人昆、陶永雷，清華大學出版社，1997年3 計算機軟件 軟件生存周期 軟件開發(fā)模型軟件工程概論4計算機軟件 計算機軟件指計算機系統(tǒng)中的程序及其文檔。 程序是計算任務的處理對象和處理規(guī)那么的描述。任何以計算機為處理工具

2、的任務都是計算任務。處理對象是數(shù)據(jù)如數(shù)據(jù)、文字、圖形、圖象、聲音等，它們只是表示，而無含義或信息數(shù)據(jù)及有關(guān)的含義。處理規(guī)那么一般指處理的動作和步驟。程序必須裝入計算機內(nèi)才能工作。文檔是為了便于了解程序所需的說明性資料，文檔一般是給人看的，不一定裝入計算機。5計算機軟件 軟件的特點 軟件的分類6軟件的特點軟件是一種邏輯實體，而不是具體的物理實體，其開發(fā)本錢和進度難以估計軟件的開發(fā)過程中沒有明顯的制造過程，一旦軟件開發(fā)成功后，只須復制即可，但維護工作量大軟件的運行和使用沒有硬件那樣的機械磨損，老化問題標準定義1 能夠完成預定功能和性能的可執(zhí)行指令；2 使得程序能夠適當?shù)夭僮餍畔⒌臄?shù)據(jù)結(jié)構(gòu)；3 描述

3、程序的操作和使用的文檔。7各位大佬的定義Fritz Bauer曾在NATO會議上給出軟件工程的定義：軟件工程 是為了經(jīng)濟地獲得能夠在實際機器上高效運行的可靠軟件而建立和使用的一系列好的工程化原那么。1983年，IEEEInstitute of Electrical & Electronic Engineers，電氣與電子工程師協(xié)會給出了一個更為全面的定義：軟件工程 是研究和應用如何以系統(tǒng)化的、標準的、可度量的方法去開發(fā)、運行和維護軟件，即把工程化應用到軟件上。8軟件工程的層次化軟件工程是一種層次化的技術(shù)9 軟件工程的層次1 軟件工程必須以有組織的質(zhì)量保證為根底，全面質(zhì)量管理和過程改進使得更加成

4、熟的軟件工程方法的不斷出現(xiàn)。2 軟件工程過程是進行一系列有組織的活動，從而能夠合理地和及時地開發(fā)出計算機軟件。過程定義了技術(shù)方法的采用、工程產(chǎn)品包括模型、文檔、數(shù)據(jù)、報告、表格等的產(chǎn)生、里程碑的建立、質(zhì)量的保證和變更的管理。3 軟件工程方法為軟件開發(fā)提供如何做的技術(shù)，它涵蓋了工程方案、需求分析、系統(tǒng)設計、程序?qū)崿F(xiàn)、測試與維護等一系列的任務。4 軟件工具為過程和方法提供自動的或半自動的支持。這些軟件工具被集成起來，建立起一個支持軟件開發(fā)的系統(tǒng)，稱之為計算機輔助軟件工程CASE，Computer Aided Software Engineering。CASE集成了軟件、硬件和一個存放開發(fā)過程信息的

5、軟件工程數(shù)據(jù)庫，形成了一個軟件工程環(huán)境。10軟件和硬件的比照與硬件相比，軟件具有以下不同的特點：1 軟件是邏輯的，而不是物理的產(chǎn)品。邏輯往往實際只存在于人的頭腦當中，軟件人員好比“皇帝的新衣故事中的裁縫，軟件的開發(fā)過程極難加以控制。2 軟件是由開發(fā)或工程化而形成的，沒有明顯的制造過程。軟件本錢集中于“開上，意味著軟件工程不能象硬件制造工程那樣來管理。3軟件在運行和使用期間，不存在硬件那樣的磨損和老化問題，但它存在退化問題，開發(fā)人員必須維護軟件。 4 大多數(shù)軟件是自定的，而不是通過已有構(gòu)件組裝而成的。迄今為止，軟件的開發(fā)尚未完全擺脫手工的方式。5 軟件本錢相當昂貴。 6 軟件本身是復雜的。111

6、2軟件的特點軟件的開發(fā)和運行常受到計算機硬件的限制，對計算機硬件有著不同程度的依賴性軟件的開發(fā)至今尚未完全實現(xiàn)自動化軟件本錢相當昂貴相當多的軟件工作涉及到社會因素13軟件的分類系統(tǒng)軟件：屬于計算機系統(tǒng)中最靠近硬件的一層，其它軟件一般都通過系統(tǒng)軟件發(fā)揮作用，它與具體的應用領(lǐng)域無關(guān)。如操作系統(tǒng)、編譯程序等。支持軟件：支持軟件的開發(fā)和維護的軟件。如數(shù)據(jù)庫管理系統(tǒng)、網(wǎng)絡軟件、軟件開發(fā)環(huán)境等。應用軟件：特定應用領(lǐng)域?qū)Ｓ玫能浖?。如實時軟件、嵌入式軟件、科學和工程計算軟件、事務處理軟件、人工智能軟件等。按軟件功能進行劃分：14 按軟件規(guī)模進行劃分：類別 參加人員數(shù) 研制期限 源程序行數(shù) 微型 1 14周 0

7、.5k 小型 1 16月 1k2k中型 25 12年 5k50k大型 520 23年 50k100k甚大型 1001000 45年 1M(=1000k)極大型 20005000 510年 1M10M15 按軟件工作方式劃分： 實時處理軟件 分時軟件 交互式軟件 批處理軟件 按軟件效勞對象的范圍劃分： 工程軟件 產(chǎn)品軟件 軟件的分類軟件的開展16軟件工程的目標軟件工程旨在開發(fā)滿足用戶需要、及時交付、不超過預算和無故障的軟件，其主要目標如下：1 合理預算開發(fā)本錢，付出較低的開發(fā)費用；2 實現(xiàn)預期的軟件功能，到達較好的軟件性能，滿足用戶的需求；3 提高所開發(fā)軟件的可維護性，降低維護費用；4 提高軟件

8、開發(fā)生產(chǎn)率，及時交付使用。17軟件危機軟件危機爆發(fā)于20世紀60年代末期，雖然人們一直致力于發(fā)現(xiàn)解決危機的方法，但是軟件危機至今依然困繞著我們，并沒有一種靈丹妙藥可以完全治愈這種病痛。18軟件危機21 軟件開發(fā)的進度難以控制，經(jīng)常出現(xiàn)經(jīng)費超預算、完成期限一再拖延的現(xiàn)象。1979年，美國US Government Accounting Office對政府工程進行了調(diào)查，其中9個軟件工程的結(jié)果如下：19軟件危機32 軟件需求在開發(fā)初期不明確，導致矛盾在后期集中暴露，從而對整個開發(fā)過程帶來災難性的后果。3 由于缺乏完整標準的資料，加之軟件測試不充分，從而造成軟件質(zhì)量低下，運行中出現(xiàn)大量問題。20軟件

9、危機4由于認識到軟件的設計、實現(xiàn)、維護和傳統(tǒng)的工程規(guī)那么有相同的根底，于是北大西洋公約組織NATO于1967年首次提出了軟件工程Software Engineering的概念。關(guān)于編制軟件與其他工程任務類似的提法，得到了1968年在德國召開的NATO軟件工程會議的認可。委員會的結(jié)論是，軟件工程應使用已有的工程規(guī)那么的理論和模式，來解決所謂的軟件危機。軟件危機至今仍然困繞著我們，這說明軟件生產(chǎn)過程在許多方面和傳統(tǒng)的工程相似，但卻具有獨特的屬性和問題。2122 計算機軟件 軟件生存周期 軟件開發(fā)模型軟件工程概論23軟件生存周期 software life cycle軟件有一個孕育、誕生、成長、成熟

10、、衰亡的生存過程。這個過程即為計算機軟件的生存周期軟件生存周期大體可分為如下幾個活動：計算機系統(tǒng)工程、可行性分析、軟件工程方案、軟件需求分析、軟件設計、程序編碼、測試及運行維護24計算機系統(tǒng)工程 計算機系統(tǒng)包括計算機硬件、軟件和使用計算機的人。計算機系統(tǒng)工程的任務是確定待開發(fā)軟件的總體要求和范圍，以及與之有關(guān)的硬件、支持軟件的要求?？尚行苑治?從經(jīng)濟、技術(shù)、法律等多個方面分析待開發(fā)的軟件是否有可行的解決方案，并在假設干個可行的解決方案中作出選擇。軟件生存周期 software life cycle25軟件工程方案 確定待開發(fā)軟件的目標，并對資源分配、本錢估算、進度安排等作出合理的方案。軟件需求

11、分析 確定待開發(fā)軟件的功能、性能、數(shù)據(jù)、界面等要求，即解決待開發(fā)軟件要“做什么的問題。軟件生存周期 software life cycle26軟件設計 主要解決待開發(fā)軟件“怎么做的問題。 軟件設計通?？煞譃橄到y(tǒng)設計也稱概要設計或總體設計和詳細設計。 系統(tǒng)設計的任務是設計軟件系統(tǒng)的結(jié)構(gòu)，包括軟件系統(tǒng)的組成成分、各成分的功能和接口、成分間的連接和通信，同時設計全局數(shù)據(jù)結(jié)構(gòu)； 詳細設計的任務是設計各個組成成分的實現(xiàn)細節(jié)，包括局部數(shù)據(jù)結(jié)構(gòu)和算法等。軟件生存周期 software life cycle27編碼 用某種程序語言為軟件編寫程序。測試 發(fā)現(xiàn)并糾正軟件中的錯誤和缺陷。運行和維護 在軟件運行期間，

12、當發(fā)現(xiàn)了軟件中潛藏的錯誤或需要增加新的功能或需將軟件移植到另一運行平臺等情況出現(xiàn)時對軟件進行修改。軟件生存周期 software life cycle28 計算機軟件 軟件生存周期 軟件開發(fā)模型軟件工程概論29軟件開發(fā)模型軟件開發(fā)模型是軟件開發(fā)全部過程、活動和任務的結(jié)構(gòu)框架也稱軟件過程模型或軟件生存周期模型軟件工程的主要環(huán)節(jié)3031軟件開發(fā)模型典型的軟件開發(fā)模型有：瀑布模型waterfall model演化模型evolutionary model增量模型incremental model螺旋模型spiral model噴泉模型water fountain model基于構(gòu)件的開發(fā)模型compo

13、nent-based development modelRUP開發(fā)模型敏捷過程模型最傻瓜的方法邊做邊改型。就是建立一個版本 用運行狀態(tài)的評估來確定 修改到用戶滿意為止！相當?shù)纳倒希?233瀑布模型可行性研究需求分析與規(guī)約設計與規(guī)約編碼與單元測試集成測試系統(tǒng)測試運行與維護341970年提出瀑布模型特征接受上一階段的結(jié)果作為本階段的輸入利用這一輸入實施本階段應完成的活動對本階段的工作進行評審將本階段的結(jié)果作為輸出，傳遞給下一階段缺點缺乏靈活性，難以適應需求不明確或需求經(jīng)常變化的軟件開發(fā)開發(fā)早期存在的問題往往要到交付使用時才發(fā)現(xiàn)，維護代價大瀑布模型快速原型模型快速原型模型的第一步是建造一個快速原型，

14、實現(xiàn)客戶或未來的用戶與系統(tǒng)的交互，用戶或客戶對原型進行評價，進一步細化待開發(fā)軟件的需求。通過逐步調(diào)整原型使其滿足客戶的要求，開發(fā)人員可以確定客戶的真正需求是什么；第二步那么在第一步的根底上開發(fā)客戶滿意的軟件產(chǎn)品。顯然，快速原型方法可以克服瀑布模型的缺點，減少由于軟件需求不明確帶來的開發(fā)風險，具有顯著的效果。快速原型的關(guān)鍵在于盡可能快速地建造出軟件原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，原型系統(tǒng)的內(nèi)部結(jié)構(gòu)并不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。 3536 軟件往往難以一次開發(fā)完成，我們可以在獲取了一組根本的需求后，通過快速分析，構(gòu)造出該軟件的一

15、個初始版本，稱為原型prototype，然后根據(jù)用戶在試用原型的過程中提出的反響意見和建議對原型進行改進，獲得原型的新版本，重復這一過程，最終可得到令用戶滿意的軟件產(chǎn)品。 演化模型采用迭代的思想，漸進地開發(fā)，逐步完成軟件版本。 增量模型、螺旋模型都屬于演化模型演化模型37增量模型38增量模型將軟件的開發(fā)過程分成假設干個日程時間交錯的線性序列，每個線性序列產(chǎn)生軟件的一個可發(fā)布的“增量版本，后一版本是對前一版本的修改和補充，重復增量發(fā)布的過程，直至產(chǎn)生最終的完善產(chǎn)品增量模型融合了瀑布模型的根本成分重復地應用和演化模型的迭代特征增量模型強調(diào)每一個增量都發(fā)布一個可運行的產(chǎn)品增量模型39增量模型特別適用

16、于：需求經(jīng)常變化的軟件開發(fā)市場急需，而開發(fā)人員和資金不能在設定的市場期限之前實現(xiàn)一個完善的產(chǎn)品的軟件開發(fā)增量模型能有方案地管理技術(shù)風險，如早期增量版本中防止采用尚未成熟的技術(shù)增量模型40于1988年提出是瀑布模型和演化模型的結(jié)合，并增加了風險分析螺旋模型沿著螺線旋轉(zhuǎn)，在四個象限上分別表達四個方面的活動，即： 制定方案：確定軟件目標，選定實施方案，弄清工程開發(fā)的限制條件 風險分析：分析所選方案，考慮如何識別和消除風險 工程實施：實施軟件開發(fā) 客戶評估：評價開發(fā)工作，提出修正建議螺旋模型41 42優(yōu)點：設計上的靈活性,可以在工程的各個階段進行變更。 以小的分段來構(gòu)建大型系統(tǒng),使本錢計算變得簡單容易

17、?？蛻羰冀K參與每個階段的開發(fā),保證了工程不偏離正確方向以及工程的可控性。隨著工程推進,客戶始終掌握工程的最新信息 , 從而他或她能夠和管理層有效地交互。缺點：采用螺旋模型需要具有相當豐富的風險評估經(jīng)驗和專門知識，在風險較大的工程開發(fā)中，如果未能夠及時標識風險，勢必造成重大損失。 過多的迭代次數(shù)會增加開發(fā)本錢，延遲提交時間。 螺旋模型43噴泉模型44噴泉模型是一種支持面向?qū)ο箝_發(fā)的模型，是一種以用戶需求為動力，以對象為驅(qū)動的模型，主要用于描述面向?qū)ο蟮能浖_發(fā)過程。該模型認為軟件開發(fā)過程自下而上周期的各階段是相互重疊和屢次反復的，就像水噴上去又可以落下來，類似一個噴泉。各個開發(fā)階段沒有特定的次序

18、要求，并且可以交互進行，可以在某個開發(fā)階段中隨時補充其他任何開發(fā)階段中的遺漏。 表達迭代和無間隙特征 迭代：各開發(fā)活動常常重復工作屢次，相關(guān)的功能在每次迭代中隨之參加演進的系統(tǒng) 無間隙：開發(fā)活動之間不存在明顯的邊界噴泉模型45優(yōu)點：開發(fā)人員可以同步進行開發(fā)，可以提高軟件工程開發(fā)效率，節(jié)省開發(fā)時間，適應于面向?qū)ο蟮能浖_發(fā)過程。缺點：由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于工程的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時參加各種信息、需求與資料的情況。 46支持軟件復用reuse利用預先包裝好的軟件構(gòu)件來構(gòu)造應用系統(tǒng)基于構(gòu)

19、件的開發(fā)模型融合了螺旋模型的許多特征印度做的很好基于構(gòu)件的開發(fā)模型47軟件構(gòu)件是一個獨立發(fā)布的功能局部，可以通過其接口訪問它的效勞。它可以是被封裝的對象類、一些功能模塊、軟件框架framework、設計模式Pattern等。 基于構(gòu)件的開發(fā):開發(fā)者在設計和詳細描述階段，使用內(nèi)部開發(fā)的構(gòu)件和公開市場的構(gòu)件來為他們的應用軟件提供盡可能多的功能。然后，開發(fā)者編寫其它的構(gòu)件來粘聯(lián)代碼，把構(gòu)件一一連接。他們可以把新寫的構(gòu)件放進公司的知識庫，以至于其它人就可以使用這些構(gòu)件的功能。這種做法有效提高了軟件重用的效率并降低了開發(fā)本錢?；跇?gòu)件的開發(fā)模型優(yōu)點和缺點48模型優(yōu)點缺點瀑布模型文檔驅(qū)動系統(tǒng)可能不滿足客戶

20、的需求快速原型模型關(guān)注滿足客戶需求可能導致系統(tǒng)設計差、效率低，難于維護增量模型開發(fā)早期反饋及時，易于維護需要開放式體系結(jié)構(gòu)，可能會設計差、效率低螺旋模型風險驅(qū)動風險分析人員需要有經(jīng)驗且經(jīng)過充分訓練49 RUP模型50RUP模型 UML過程的根本特征是：用例驅(qū)動，以架構(gòu)為核心，迭代并且增量用例驅(qū)動： 用例獲取系統(tǒng)的功能需求，它們“驅(qū)動需求分析之后的所有階段的開發(fā)。在分析階段，它們被用于獲取所需的功能并經(jīng)客戶確實認。在設計和實現(xiàn)階段，用例必須被實現(xiàn)，在測試階段，用例用于驗證系統(tǒng)。RUP模型RUPRational Unified Process，統(tǒng)一軟件開發(fā)過程，統(tǒng)一軟件過程)是一個面向?qū)ο笄一诰W(wǎng)

21、絡的程序開發(fā)方法論。根據(jù)Rational(Rational Rose和統(tǒng)一建模語言的開發(fā)者)的說法，好似一個在線的指導者，它可以為所有方面和層次的程序開發(fā)提供指導方針，模版以及事例支持。 RUP和類似的產(chǎn)品-例如面向?qū)ο蟮能浖^程OOSP，以及OPEN Process都是理解性的軟件工程工具-把開發(fā)中面向過程的方面例如定義的階段，技術(shù)和實踐和其他開發(fā)的組件例如文檔，模型，手冊以及代碼等 等整合在一個統(tǒng)一的框架內(nèi)。51AOPAOP，aspect objected programming,較好的說法是面向切面編程，按我的理解是，它能減少和系統(tǒng)的其他局部的耦合，是系統(tǒng)能更好的維護和重構(gòu)，叫他切面，就

22、是說他可以在需要 它的時候?qū)⑵鋮⒓拥较到y(tǒng)中，且能很好的和原系統(tǒng)配合，當不需要的時候就可以去除，也不會重新修改代碼。在Spring開源框架中最重要的就是依賴注入和AOP了，利用它，可以讓程序員能更好的管理事務和業(yè)務bean,DAO bean,用它來做系統(tǒng)運行日志，就是個例子。52形式化方法模型用于開發(fā)計算機系統(tǒng)的形式化方法是描述系統(tǒng)性質(zhì)的基于數(shù)學的技術(shù)，這樣的形式化方法提供了一個框架，可以在框架中以系統(tǒng)的而不是特別的方式刻劃、開發(fā)和驗 證系統(tǒng)。 如果一個方法有良好的數(shù)學根底，那么它就是形式化的，典型地以形式化規(guī)約語言給出。這個根底提供一系列精確定義的概念，如：一致性和完整性，以及定義標準 的實現(xiàn)

23、和正確性。 形式化方法的本質(zhì)是基于數(shù)學的方法來描述目標軟件系統(tǒng)屬性的一種技術(shù)。不同的形式化方法的數(shù)學根底是不同的，有的以集合論和一階謂詞演算為根底如Z和 VDM，有的那么以時態(tài)邏輯為根底。形式化方法需要形式化規(guī)約說明語言的支持53形式化方法的分類根據(jù)說明目標軟件系統(tǒng)的方式，形式化方法可以分為兩類1面向模型的形式化方法。面向模型的方法通過構(gòu)造一個數(shù)學模型來說明系統(tǒng)的行為。 2面向?qū)傩缘男问交椒?。面向?qū)傩缘姆椒ㄍㄟ^描述目標軟件系統(tǒng)的各種屬性來間接定義系統(tǒng)行為。 54根據(jù)表達能力，形式化方法可以分為五類：1基于模型的方法：通過明確定義狀態(tài)和操作來建立一個系統(tǒng)模型使系統(tǒng)從一個狀態(tài)轉(zhuǎn)換到另一個狀態(tài)。用

24、這種方法雖可以表示非功能性需求諸如時間需求，但不能很好地表示并發(fā)性。如：Z語言，VDM，B方法等。 2基于邏輯的方法：用邏輯描述系統(tǒng)預期的性能，包括底層規(guī)約、時序和可能性行為。采用與所選邏輯相關(guān)的公理系統(tǒng)證明系統(tǒng)具有預期的性能。用具體的編程構(gòu) 造擴充邏輯從而得到一種廣譜形式化方法，通過保持正確性的細化步驟集來開發(fā)系統(tǒng)。如：ITL區(qū)間時序邏輯，區(qū)段演算DC，hoare 邏輯，WP演算，模態(tài)邏輯，時序邏輯，TAM時序代理模型，RTTL實時時序邏輯等。 3代數(shù)方法：通過將未定義狀態(tài)下不同的操作行為相聯(lián)系，給出操作的顯式定義。與基于模型的方法相同的是，沒有給出并發(fā)的顯式表示。如：OBJ， Larch族

25、代數(shù)規(guī)約語言等； 4過程代數(shù)方法：通過限制所有容許的可觀察的過程間通信來表示系統(tǒng)行為。此類方法允許并發(fā)過程的顯式表示。如：通信順序過程CSP，通信系統(tǒng)演算 CCS，通信過程代數(shù)ACP，時序排序規(guī)約語言LOTOS，計時CSP(TCSP，通信系統(tǒng)計時可能性演算TPCCS等。 5基于網(wǎng)絡的方法：由于圖形化表示法易于理解，而且非專業(yè)人員能夠使用，因此是一種通用的系統(tǒng)確定表示法。該方法采用具有形式語義的圖形語言，為系統(tǒng)開發(fā)和再工程帶來特殊的好處。如 Petri圖，計時Petri圖，狀態(tài)圖等。達能力，形式化方法可以分為五類5556以體系結(jié)構(gòu)為中心： 首先定義一個根底的體系結(jié)構(gòu)，然后將它原型化并加以評估，最

26、后進行精化。體系結(jié)構(gòu)給出系統(tǒng)的映象，它定義系統(tǒng)的不同局部、它們的關(guān)系和交互，它們的通信機制以及關(guān)于如何增加或修改體系結(jié)構(gòu)中的成分的全部規(guī)那么。體系結(jié)構(gòu)涉及到功能性和非功能性兩個方面，要定義一個易修改、易理解和允許復用的系統(tǒng)。57迭代： 用UML建模最好經(jīng)過假設干次較小的迭代，不要試圖一次就定義模型或圖的所有細節(jié)，開發(fā)是逐步進行的，每次迭代增加一些新的信息和細節(jié)。每次迭代都要對前次的結(jié)果評價，并用于下一次迭代的輸入。迭代的過程提供連續(xù)的反響，這些反響不僅改善了最終的產(chǎn)品，而且改善了過程本身。 在決定每一次迭代應做什么時，要考慮這次迭代對系統(tǒng)的最大影響或最高風險?？紤]最大影響的迭代意味著使系統(tǒng)能盡

27、早提交給用戶，考慮最高風險的迭代意味著盡早處理工程中的難點，以降低工程的風險。 58增量 ：增量開發(fā)是在屢次迭代的過程中每次增加一些功能或用例的開發(fā)，每次迭代都包含分析、設計、實現(xiàn)、測試等階段，通過假設干次增量開發(fā)完成整個系統(tǒng)的開發(fā)，這樣的開發(fā)過程分解了開發(fā)的風險，不至于把風險留到開發(fā)的后期。每次迭代集中在幾個功能或用例的開發(fā)上，如發(fā)現(xiàn)問題，其錯誤往往比較小，相應的風險也小，修改也相對容易。 59敏捷聯(lián)盟：敏捷軟件開發(fā)宣言2001個體和交互勝過過程和工具；可工作軟件勝過寬泛的文檔；客戶合作勝過合同談判；響應變化勝過遵循方案。敏捷建模60我們的最高目標是，通過盡早和持續(xù)地交付有價值的軟件來滿足客

28、戶。 歡送對需求提出變更即使是在工程開發(fā)后期。要善于利用需求變更，幫助客戶獲得競爭優(yōu)勢。 要不斷交付可用的軟件，周期從幾周到幾個月不等，且越短越好。 工程過程中，業(yè)務人員與開發(fā)人員必須在一起工作。 要善于鼓勵工程人員，給他們以所需要的環(huán)境和支持，并相信他們能夠完成任務。 無論是團隊內(nèi)還是團隊間，最有效的溝通方法是面對面的交談。 敏捷宣言背后的12條原那么61可用的軟件是衡量進度的主要指標。 敏捷過程提倡可持續(xù)的開發(fā)。工程方、開發(fā)人員和用戶應該能夠保持恒久穩(wěn)定的進展速度。 對技術(shù)的精益求精以及對設計的不斷完善將提升敏捷性。 要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術(shù)。 最正確的架構(gòu)、

29、需求和設計出自于自組織的團隊。 團隊要定期反省如何能夠做到更有效，并相應地調(diào)整團隊的行為。 敏捷宣言背后的12條原那么62極限編程Extreme Programming，XP( P57圖4-1，生命周期：籌劃、設計、編碼、測試。XP原那么：現(xiàn)場客戶、簡單設計、測試驅(qū)動、結(jié)對編程、代碼全體擁有、持續(xù)集成、小型發(fā)布自適應軟件開發(fā)Adaptive Software Development,ASD)(P61,圖4-2，生命周期：思考、協(xié)作、學習動態(tài)系統(tǒng)開發(fā)方法Dynamic SystemDevelopment Method，DSDM敏捷過程模型63動態(tài)系統(tǒng)開發(fā)方法Dynamic SystemDevel

30、opment Method，DSDM：使用迭代軟件過程，每一個迭代都遵循80%原那么如果交付整個系統(tǒng)需用100%時間，那么80%的應用系統(tǒng)可以用20%的時間交付。DSDM生命周期的敏捷過程模型：可行性研究業(yè)務研究功能模型迭代設計和構(gòu)建迭代實現(xiàn)敏捷過程模型64Scrum敏捷過程模型P63圖4-3原那么(和敏捷宣言一致：組織小型團隊以到達：溝通最大化，負擔最小化，非語言描述、非形式化知識。過程對技術(shù)和業(yè)務變化必須具有適應性，以“保證制造具有最好可能的產(chǎn)品。過程生產(chǎn)頻繁發(fā)布“可檢查、可調(diào)整、可測試、可文檔化、可構(gòu)建的軟件增量。開發(fā)工作和開發(fā)人員劃分為“清晰的、低耦合的局部或包。堅持在產(chǎn)品構(gòu)建過程中進

31、行測試和文檔化。Scrum過程提供“在任何需要的情況下都能完成產(chǎn)品的能力。敏捷過程模型65特征驅(qū)動開發(fā)Feature Drive Developmeng,FDDP65圖4-4特征-是可以在2周或者更短時間實現(xiàn)的具有客戶價值的功能。FDD更加強調(diào)工程管理原那么和技術(shù)。在特征設計和構(gòu)建階段定義6個里程碑：設計走查，設計，設計檢查，編碼，代碼檢查，促進構(gòu)建敏捷過程模型軟件神話什么都是浮云不要用機械工程的概念來套用6667觀點之一我們擁有一套講述如何開發(fā)軟件的書籍，書中充滿了標準與示例，可以幫助我們解決軟件開發(fā)中遇到的任何問題。 客觀事實好的參考書無疑能指導我們的工作，充分利用書籍中的方法、技術(shù)和技巧

32、，可以有效地解決軟件開發(fā)中大量常見的問題。但實踐者并不能依賴于書籍，因為在現(xiàn)實工作中，由于條件千差萬別，即使是相當成熟的軟件工程規(guī)范，常常也無法套用。另外，軟件技術(shù)日新月異，沒有哪一種軟件標準能長盛不衰。觀點之二如果我們已經(jīng)落后于計劃，可以增加更多的程序員來趕上進度?？陀^事實軟件開發(fā)不同于傳統(tǒng)的機械制造，人多不見得力量大。如果給落后于計劃的項目增添新人，可能會更加延誤項目。因為新人會產(chǎn)生很多新的錯誤，使項目混亂，并且原有的開發(fā)人員向新人解釋工作和交流思想都要花費時間，使實際的開發(fā)時間更少，所以制定恰如其分的項目計劃是很重要的?！局v解】假設一個項目估計需要12人月工作量，指定由3個人在4個月內(nèi)完

33、成，如果第一個月的任務花了兩個月才完成，那么增加人力的結(jié)果如何？假設增加2個人參加項目，不論新增加的人適應能力有多強，總需要有人去幫助了解熟悉情況，如果這些工作占用了一個月的時間，這樣又有3個人月工作量在新計劃之外。由于人員增加，工作任務需要重新劃分，到第3個月結(jié)束時雖然有5個人在工作，實際上余留下7個人的工作量。觀點之三項目需求總是在不斷變化，但這些變化能夠很容易地滿足，因為軟件是靈活的。客觀事實軟件需求確實是經(jīng)常變化的，但這些變化產(chǎn)生的影響會隨著其引入時間的不同而不同。對需求把握得越準確，軟件的修修補補就越少。有些需求在一開始時很難確定，在開發(fā)過程中要不斷地加以改正。軟件修改越早代價越少，

34、修改越晚代價越大，就跟治病一樣道理。 觀點之四有了對目標的一般描述就足以開始寫程序了，我們以后可以再補充細節(jié)?？陀^事實不完善的系統(tǒng)定義是軟件項目失敗的主要原因。關(guān)于待開發(fā)軟件的應用領(lǐng)域、功能、性能、接口、設計約束和標準等需要詳細的描述，而這些只有通過用戶和開發(fā)人員之間的通信交流才能確定。越早開始寫程序，就要花越長時間才能完成它。觀點之五一旦我們寫出了程序并使其正常運行，我們的工作就結(jié)束了。人們有時認為，只有差的軟件產(chǎn)品才需要維護?？陀^事實從如圖1.12所示的統(tǒng)計數(shù)據(jù)來看，軟件投入的50%70%是花費在交付給用戶之后。品質(zhì)差的產(chǎn)品被丟棄，只有好的產(chǎn)品才需要維護和改進。觀點之六一個成功的項目唯一應

35、該提交的就是運行程序。客觀事實軟件包括程序、數(shù)據(jù)和文檔，其中文檔是成功開發(fā)的基礎，為軟件維護提供了指導。 幫助回憶觀點一：開放軟件源代碼就一定好。 觀點二：軟件質(zhì)量問題可通過軟件測試得到徹底解決。68觀點一一般人都認為開放源代碼對一個軟件系統(tǒng)的完善有很好的促進作用，因為這樣可以集合很多人的智慧，但這種觀點并不完全正確。大家贊同開放源碼，其實很大程度上是因為先有了Linux成功的例子，而Linux的出現(xiàn)和成功是有它一定的背景的，很大程度上是因為不支持源碼開放的代表-微軟的緣故。開放源代碼對促進全球軟件和信息技術(shù)行業(yè)的快速開展是很有益處的，但是關(guān)于源代碼的GPL授權(quán)方式目前還看不到它對軟件企業(yè)開展的好處。一味強調(diào)過度開放源代碼，在現(xiàn)在盜版泛濫的時代，擁有源代碼的公司如何得到回報，沒有回報就沒有進一步研發(fā)資金，軟件的開展從何而來。 69觀點二為了克服軟件危機和提高軟件質(zhì)量，人們進行了大量的研究和實踐。最初的重點是著眼于技術(shù)革新，從各種軟件工具如編輯、編譯、調(diào)試工具等等研制開始，開展成為對開發(fā)各階段進行全面支持的計算機輔助軟件工程CASE環(huán)境。同時，注重軟件開發(fā)模型研究，也就是如何劃分軟件開