南京大學(xué)-軟件工程-22-軟件開發(fā)過程模型

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

ch22軟件開發(fā)過程模型主要內(nèi)容軟件開發(fā)各典型階段軟件生命周期模型軟件過程模型第4～21章開發(fā)活動總結(jié)階段目標關(guān)注點工作基礎(chǔ)方法主要任務(wù)執(zhí)行者制品需求工程建立解決方案理解現(xiàn)實；制定解決方案（成本效益比有效）客戶、用戶、環(huán)境等結(jié)構(gòu)化分析（DFD、ERD等）；面向?qū)ο蠓治觯ㄓ美龍D、概念類圖、順序圖、狀態(tài)圖等）需求開發(fā)系統(tǒng)需求開發(fā)需求工程師需求分析模型與需求文檔軟件需求開發(fā)需求基線需求管理所有開發(fā)人員

軟件設(shè)計建立由抽象軟件實體組成的軟件結(jié)構(gòu)整體功能組織與質(zhì)量特征（各種質(zhì)量屬性）系統(tǒng)需求模塊結(jié)構(gòu)（UML:包圖、構(gòu)件圖、部署圖）軟件體系結(jié)構(gòu)設(shè)計體系結(jié)構(gòu)師體系結(jié)構(gòu)原型、體系結(jié)構(gòu)模型和文檔模塊內(nèi)部的結(jié)構(gòu)及質(zhì)量（易開發(fā)、可復(fù)用、可維護等）軟件體系結(jié)構(gòu)軟件需求結(jié)構(gòu)化方法（結(jié)構(gòu)圖）；面向?qū)ο蠓椒ǎò鼒D、類圖、順序圖等）軟件詳細設(shè)計設(shè)計師軟件詳細設(shè)計模型和文檔人機交互質(zhì)量（易用性）軟件需求人機交互設(shè)計方法人機交互設(shè)計人機交互設(shè)計師界面原型第4～21章開發(fā)活動總結(jié)軟件構(gòu)造構(gòu)建軟件程序的質(zhì)量（可讀、可靠、性能、可維護等）軟件設(shè)計方案結(jié)構(gòu)化程序設(shè)計；面向?qū)ο蟪绦蛟O(shè)計編程、集成、測試與調(diào)試等程序員源代碼可執(zhí)行程序軟件測試保障軟件產(chǎn)品的質(zhì)量質(zhì)量（程序正確性和對需求的符合度）保障軟件需求軟件設(shè)計程序代碼黑盒、白盒等測試方法測試設(shè)計、執(zhí)行單元測試程序員或測試人員測試報告通過測試的軟件產(chǎn)品集成測試測試人員系統(tǒng)測試測試計劃測試報告軟件交付將軟件交付給用戶交付的有效性可執(zhí)行程序

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

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

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

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

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