丁二玉南京大學軟件學院《軟件工程與計算II》

ch22軟件開發過程模型主要內容軟件開發各典型階段軟件生命周期模型軟件過程模型第4～21章開發活動總結階段目標關注點工作基礎方法主要任務執行者制品需求工程建立解決方案理解現實；制定解決方案（成本效益比有效）客戶、用戶、環境等結構化分析（DFD、ERD等）；面向對象分析（用例圖、概念類圖、順序圖、狀態圖等）需求開發系統需求開發需求工程師需求分析模型與需求文檔軟件需求開發需求基線需求管理所有開發人員

軟件設計建立由抽象軟件實體組成的軟件結構整體功能組織與質量特征（各種質量屬性）系統需求模塊結構（UML:包圖、構件圖、部署圖）軟件體系結構設計體系結構師體系結構原型、體系結構模型和文檔模塊內部的結構及質量（易開發、可復用、可維護等）軟件體系結構軟件需求結構化方法（結構圖）；面向對象方法（包圖、類圖、順序圖等）軟件詳細設計設計師軟件詳細設計模型和文檔人機交互質量（易用性）軟件需求人機交互設計方法人機交互設計人機交互設計師界面原型第4～21章開發活動總結軟件構造構建軟件程序的質量（可讀、可靠、性能、可維護等）軟件設計方案結構化程序設計；面向對象程序設計編程、集成、測試與調試等程序員源代碼可執行程序軟件測試保障軟件產品的質量質量（程序正確性和對需求的符合度）保障軟件需求軟件設計程序代碼黑盒、白盒等測試方法測試設計、執行單元測試程序員或測試人員測試報告通過測試的軟件產品集成測試測試人員系統測試測試計劃測試報告軟件交付將軟件交付給用戶交付的有效性可執行程序

安裝與部署、用戶培訓、文檔支持專門人員用戶使用手冊已交付軟件產品軟件維護產品終結前的正常使用變更時控制效益和質量的綜合平衡已交付軟件產品軟件演化方法（重構、逆向工程、再工程）重復上述各階段任務維護人員

主要內容軟件開發各典型階段軟件生命周期模型軟件過程模型軟件生命周期人們將軟件從生產到報廢的生命周期分割為不同階段，每段階段有明確的典型輸入/輸出、主要活動和執行人，各個階段形成明確、連續的順次過程，這些階段劃分就被稱為軟件生命周期模型。典型的軟件生命周期可以有不同的生命周期劃分方式例如第21章的軟件演化生命周期模型主要內容軟件開發各典型階段軟件生命周期模型軟件過程模型構建-修復模型瀑布模型增量迭代模型演化模型原型模型螺旋模型Rational統一過程敏捷過程軟件過程模型軟件過程模型在生命周期模型的基礎則進一步詳細說明各個階段的任務、活動、對象及其組織、控制過程。與簡略的軟件生命周期模型不同，軟件過程模型可以被看作是網絡化的活動組織不同的生命周期模型有不同的軟件過程模型階段劃分不一樣同一個生命周期模型也會有多個不同的軟件過程模型雖然階段劃分一樣，但是各個階段的時間安排、先后銜接等執行過程不一樣本書案例適用的軟件過程模型主要內容軟件開發各典型階段軟件生命周期模型軟件過程模型構建-修復模型瀑布模型增量迭代模型演化模型原型模型螺旋模型Rational統一過程敏捷過程構建-修復模型最早也是最自然產生的軟件開發模型不能算是一個軟件過程模型，因為它對軟件開發活動沒有任何規劃和組織，是完全依靠開發人員個人能力進行軟件開發的方式。缺點在這種模型中，沒有對開發工作進行規范和組織，所以隨著軟件系統的復雜度提升，開發活動會超出個人的直接控制能力，構建-修復模型就會導致開發活動無法有效進行而失??；沒有分析需求的真實性，給軟件開發帶來很大的風險；沒有考慮軟件結構的質量，使得軟件結構在不斷的修改中變得質量越來越糟，直至無法修改；沒有考慮測試和程序的可維護性，也沒有任何文檔，軟件的維護十分困難。適用性軟件規模很小，只需要幾百行程序，其開發復雜度是個人能力能夠勝任的；軟件對質量的要求不高，即使出錯也無所謂；只關注開發活動，對后期維護的要求不高，甚至不需要進行維護。主要內容軟件開發各典型階段軟件生命周期模型軟件過程模型構建-修復模型瀑布模型增量迭代模型演化模型原型模型螺旋模型Rational統一過程敏捷過程瀑布模型[Royce1970]通過分析早期（1960s）的軟件開發活動后發現，如果將軟件開發活動劃分為不同的階段，并且保障每一個階段工作的正確性和有效性（尤其是重視分析和設計階段），那么會取得比構建-修復方式好得多的表現，包括更高的質量、更低的成本和更小的風險。瀑布模型允許活動出現反復和迭代重點在于要求每個活動的結果必須要進行驗證文檔驅動優點為軟件開發活動定義了清晰的階段劃分（包括了輸入/輸出、主要工作及其關注點），這讓開發者能夠以關注點分離的方式更好地進行那些復雜度超越個人能力的軟件項目的開發活動。缺點對文檔的過高期望具有局限性。一方面會耗費很大的工作量和成本另一方面很難為經常變化的需求建立完備可靠的文檔。對開發活動的線性順序假設具有局限性。要求一個階段的工作經過驗證后才能進入后續階段是不切實際的。在實際開發中，常常需要進行一定的后續工作才能驗證當前的工作是否正確、可靠?？蛻?、用戶參與具有局限性。成功的項目開發需要客戶、用戶從始至終的參與，而不僅僅是一個階段。里程碑粒度具有局限性。里程碑粒度過粗，基本喪失了“早發現缺陷早修復”這一思想。適用性需求非常成熟、穩定，沒有不確定的內容，也不會發生變化；所需的技術成熟、可靠，沒有不確定的技術難點，也沒有開發人員不熟悉的技術問題；復雜度適中，不至于產生太大的文檔負擔和過粗的里程碑。思考課程實驗是瀑布模型嗎？為什么？IID=Incrementaliterativedevelopment主要內容軟件開發各典型階段軟件生命周期模型軟件過程模型構建-修復模型瀑布模型增量迭代模型演化模型原型模型螺旋模型Rational統一過程敏捷過程迭代過程增量迭代模型

漸進交付模型（IncrementalDelivery）迭代式、漸進交付和并行開發共同促使了增量迭代模型的產生和普及。優點迭代式開發更加符合軟件開發的實踐情況，具有更好的適用性；并行開發可以幫助縮短軟件產品的開發時間；漸進交付可以加強用戶反饋，降低開發風險。缺點由于各個構件是逐漸并入已有的軟件體系結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟件具備開放式的體系結構。

增量交付模型需要一個完備、清晰的項目前景和范圍以進行并發開發規劃，但是在一些不穩定的領域，不確定性太多或者需求變化非常頻繁，很難在項目開始就確定前景和范圍。適用性因為能夠很好地適用于大規模軟件系統開發，所以增量迭代模型在實踐中有著廣泛的應用，尤其是比較成熟和穩定的領域。年度發布&&軟件演化生命周期模型思考如果不考慮學習順序的問題，課程實驗能不能使用增量迭代模型？為什么？主要內容軟件開發各典型階段軟件生命周期模型軟件過程模型構建-修復模型瀑布模型增量迭代模型演化模型原型模型螺旋模型Rational統一過程敏捷過程演化模型演化模型與增量迭代模型相比都是迭代、并行開發和漸進交付，都適合大規模軟件開發演化模型能夠更好地應對需求變更，更適用于需求變更比較頻繁或不確定性較多的領域。Ch21：演化模糊了維護與新開發的界限優點使用了迭代式開發，具有更好的適用性，尤其是其演化式迭代安排能夠適用于那些需求變更比較頻繁或不確定性較多的軟件系統的開發；并行開發可以幫助縮短軟件產品的開發時間；漸進交付可以加強用戶反饋，降低開發風險。缺點無法在項目早期階段建立項目范圍，所以項目的整體計劃、進度調度、尤其是商務協商事宜無法準確把握；后續迭代的開發活動是在前導迭代基礎上進行修改和擴展的，這容易讓后續迭代忽略設分析與設計工作，蛻變為構建-修復方式。適用性在實踐中，不穩定領域的大規模軟件系統開發適合使用演化模型進行組織。思考如果不考慮學習順序的問題，課程實驗能不能使用演化模型（Evolution）？為什么？主要內容軟件開發各典型階段軟件生命周期模型軟件過程模型構建-修復模型瀑布模型增量迭代模型演化模型原型模型螺旋模型Rational統一過程敏捷過程原型模型大量使用拋棄式原型解決需求不確定性的過程模型拋棄式原型它通過模擬“未來”的產品，將“未來”的知識置于“現在”進行推敲，解決不確定性。演化式原型在迭代中構建，是系統的核心，并不斷擴充，最終成為真正的軟件產品。優點對原型方法的使用加強了與客戶、用戶的交流，可以讓最終產品取得更好的滿意度；適用于非常新穎的領域，這些領域因為新穎所以有著大量的不確定性。缺點原型方法能夠解決風險，但是自身也能帶來新的風險，例如原型開發的成本較高，可能會耗盡項目的費用和時間；實踐中，很多項目負責人不舍得拋棄“拋棄式原型”，使得質量較差的代碼進入了最終產品，導致了最終產品的低質量。適用性實踐中，原型模型主要用于在有著大量不確定性的新穎領域進行開發活動組織。思考課程實驗能不能使用原型模型（Prototyping）？為什么？主要內容軟件開發各典型階段軟件生命周期模型軟件過程模型構建-修復模型瀑布模型增量迭代模型演化模型原型模型螺旋模型Rational統一過程敏捷過程螺旋模型螺旋模型的基本思想是盡早解決比較高的風險，如果有些問題實在無法解決，那么早發現比項目結束時再發現要好，至少損失要小得多。風險是指因為不確定性（對未來知識了解有限）而可能給項目帶來損失的情況原型能夠澄清不確定性，所以原型能夠解決風險迭代與瀑布的結合開發階段是瀑布式的風險分析是迭代的過程描述螺旋模型優點可以降低風險，減少項目因風險造成的損失。缺點風險解決需要使用原型手段，也就會存在原型自身帶來的風險，這一點與原型模型相同；模型過于復雜，不利于管理者依據其組織軟件開發活動；適用性在實踐中，螺旋模型在高風險的大規模軟件系統開發中有著較多的應用。思考課程實驗能不能使用螺旋模型（Spiral）？為什么？WhentousetheWaterfallModelRequirementsareverywellknownProductdefinitionisstableTechnologyisunderstoodNewversionofanexistingproductPortinganexistingproducttoanewplatform.DocumentDrivenWhentousetheIncrementalDeliveryModelMostoftherequirementsareknownup-frontbutareexpectedtoevolveovertimeAneedtogetbasicfunctionalitytothemarketearlyOnprojectswhichhavelengthydevelopmentschedulesRequirementsdrivenWhentousetheEvolutionModelManyoftherequirementsareunknownup-frontorchangefrequentlyUsersareunsureoftheirneedsRequirementsarecomplexNewproductlineSignificantchangesareexpected(researchandexploration)AneedtogetbasicfunctionalitytothemarketearlyOnprojectswhichhavelengthydevelopmentschedulesRequirementdrivenWhentousePrototypingRequirementsareunstableorhavetobeclarifiedAstherequirementsclarificationstageofawaterfallmodelDevelopuserinterfacesNew,originaldevelopmentRequirementdrivenWhentouseSpiralModelWhencostsandriskevaluationisimportantFormediumtohigh-riskprojectsRiskUsersareunsureoftheirneedsRequirementsarecomplexNewproductlineSignificantchangesareexpected(researchandexploration)Risk-drivenUseoftheModelsinPractice主要內容軟件開發各典型階段軟件生命周期模型軟件過程模型構建-修復模型瀑布模型增量迭代模型演化模型原型模型螺旋模型Rational統一過程敏捷過程Rational統一過程模型RUP總結和借鑒傳統上的各種有效經驗，建立最佳實踐方法的集合，并提供有效的過程定制手段，允許開發者根據特定的需要定制一個有效的過程模型。RUP核心實踐方法1、迭代式開發，這是過去被反復證明的最佳實踐方法；2、管理需求，重視需求工程中除了需求開發之外的需求管理活動；3、使用基于組件的體系結構，它幫助建立一個可維護、易開發、易復用的軟件體系結構；4、可視化建模，利用UML進行建模；5、驗證軟件質量，盡早和持續地開展驗證，以盡早發現缺陷，降低風險和成本；6、控制軟件變更，適應1990s以后需求變更越來越重要的事實。RUP裁剪RUP是一個通用的過程模板，在一個項目使用RUP指導開發活動組織時，需要對RUP進行裁剪和配置。1、確定本項目需要哪些工作流。RUP的9個核心工作流并不總是需要的，可以取舍。2、確定每個工作流需要哪些制品。3、確定4個階段之間如何演進，決定每個階段要哪些工作流，每個工作流執行到什么程度，制品有哪些。4、確定每個階段內的迭代計劃。5、規劃工作流的組織，這涉及人員、任務及制品，通常用活動圖的形式給出。優點吸收和借鑒了傳統上的最佳實踐方法，尤其是其核心的6個實踐方法，能夠保證軟件開發過程的組織是基本有效和合理的。RUP依據其定制機制的不同，可以適用于小型項目，也可以適用于大型項目的開發，適用面廣泛。RUP有一套軟件工程工具的支持，這可以幫助RUP的有效實施。缺點沒有考慮交付之后的軟件維護問題；裁剪和配置工作不是一個簡單的任務，無法保證每個項目都能定制一個有效的RUP過程。適用性RUP是重量級過程，能夠勝任大型軟件團隊開發大型項目時的活動組織。但RUP經過裁剪和定制，也可以變為輕量級過程，也能夠勝任小團隊的開發活動組織。主要內容軟件開發各典型階段軟件生命周期模型軟件過程模型構建-修復模型瀑布模型增量迭代模型演化模型原型模型螺旋模型Rational統一過程敏捷過程敏捷過程傳統的過程模型在應對需求變更和重視用戶價值等發展時遇到了極大的挑戰。傳統的軟件過程模型過度強調了“紀律”，忽視了個人的能力，尤其是過度強調了計劃、文檔和工具，導致項目開發失去了靈活性，不能快速地應對需求變更和用戶反饋。針對傳統過程模型的缺陷和新的形勢，人們總結實踐中的經驗和最佳實踐方法，嘗試建立輕量級過程方法。TheAgileAgilemethodsareafamilyofdevelopmentprocesses,notasingleapproachtosoftwaredevelopment.In2001,17prominentfigures

inthefieldofagiledevelopment(thencalled“light-weightmethods”)cametogetherattheSnowbirdskiresortinUtahtodiscusswaysofcreatingsoftwareinalighter,faster,morepeople-centricway.TheycreatedtheAgileManifesto,widelyregardedasthecanonicaldefinitionofagiledevelopmentandaccompanyingagileprinciples.敏捷原則1. 我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。2. 欣然面對需求變化，即使在開發后期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。3. 經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期。4. 業務人員和開發人員必須相互合作，項目中的每一天都不例外。5. 激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。6. 不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。敏捷原則7. 可工作的軟件是進度的首要度量標準。8. 敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。9. 堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。10. 以簡潔為本，它是極力減少不必要工作量的藝術。11. 最好的架構、需求和設計出自自組織團隊。12. 團隊定期地反思如何能提高成效，并依此調整自身的舉止表現。踐行敏捷思想與原則的過程方法極限編程XP（eXtremeProgramming）Scrum特性驅動開發（FDD/FeatureDrivenDevelopment）自適應軟件開發（ASD/AdaptiveSoftwareDevelopment）動態系統開發方法（DSDM/DynamicSystemsDevelopmentMethod）……極限編程極限編程XP的一個重要思想是極限利用簡單、有效的方法解決問題（這也是它被稱為極限編程的原因），例如：如果單元測試好用，那么就讓所有人一直做單元測試（測試驅動）；如果集成測試好用，那么就一直做集成測試（持續集成）；如果代碼評審好用，那么就一直做評審（結對編程）；如果簡潔性好用，那么就只做最簡潔的事情（簡單設計）；如果設計好用，那么就一直設計（重構）；如果短迭代好用，那么就把迭代做的足夠小（小版本發布）；如果用戶參與好用，那么就讓用戶始終參與（現場客戶）?！瓨O限編程的實踐方法開發活動實踐方法方法描述迭代規劃規劃游戲計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性需求開發現場客戶用戶代表作為開發團隊的一份子，始終參與軟件開發活動軟件設計系統隱喻將整個系統聯系在一起的全局視圖；它是系統的未來影像，是它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那么你就知道該模塊是錯誤的簡單設計保持設計簡潔，滿足需求，但不要包含為了未來預期而進行的設計重構不改變系統外部行為的情況下，改進軟件內部結構的質量極限編程的實踐方法開發活動實踐方法方法描述軟件實現結對編程兩個人坐在一臺電腦前一起編程，一個程序員控制電腦進行編程時，另外一個人進行代碼評審。編程控制權可以互換編碼規范所有人都遵循一個統一的編程標準，因此，所有的代碼看起來好像是一個人寫的，每個程序員更容易讀懂其他人寫的代碼代碼集體所有權每個人都對所有的程序負責，每個人都可以更改程序的任意部分軟件測試測試驅動在編程之前，先寫好程序的設計用例和測試框架，然后再編寫程序持續集成頻繁地進行系統集成，每次集成都要通過所有的單元測試；每個用戶任務完成后都應該進行集成軟件交付小版本發布頻繁地發布軟件，如果有可能，應該每天都發布一個新版本；在完成任何一個改動、集成或者新需求后，就應該立即發布一個新版本其他每周40小時工作制保持團隊可持續開發能力，長時間加班工作會降低開發的質量和效率Fall200468TheOverallXPLifecycle特點敏捷過程包含的方法眾多，各有特點，除了共同的思想和原則之外，很難準確描述它們的共同點，所以也無法確切界定它們的優缺點。適用性從敏捷聯盟聲明的思想和原則來看，它們反映了1990s之后軟件工程的發展趨勢，所以得到了廣泛的應用，尤其是能夠適應于快速變化或者時