軟件工程原理與實踐（碩士）課件 02 軟件過程

高級軟件工程

SoftwareEngineering軟件過程02-軟件開發(fā)過程01-軟件過程概述03-軟件運維過程204-軟件過程的實施與改進軟件過程定義了軟件組織和人員在軟件產(chǎn)品的定義、開發(fā)和維護等階段所實施的一系列活動。軟件過程發(fā)展歷史20世紀50年代：包含在硬件工程中的編碼、測試等軟件開發(fā)相關活動。20世紀60年代：形成了“軟件工藝”的概念，以一種黑盒的方式存在（Code-and-Fix）20世紀70年代：在IBM360等大型項目經(jīng)驗基礎上逐漸形成規(guī)范化軟件過程的思想，出現(xiàn)瀑布模型等過程模型，顯式定義開發(fā)過程。20世紀90年代：開發(fā)優(yōu)秀軟件過程的重要性得到廣泛認同，CMUSEI提出了軟件開發(fā)能力成熟度模型CMM/CMMI，用于評估和改進軟件過程。21世紀00年代：敏捷開發(fā)的思想成為主流,出現(xiàn)了多種具有快速迭代反饋、適應需求變化等“輕量級”特點的開發(fā)過程。21世紀10年代：開發(fā)運維一體化（DevOps），打破開發(fā)和運維的界限，實現(xiàn)從運維到開發(fā)的快速反饋。3ISO/IEC12207軟件生命周期過程4軟件生存周期模型軟件生存周期模型：又稱軟件過程模型，是對開發(fā)人員所采用的軟件開發(fā)過程組織整體結(jié)構的抽象描述，表達了軟件過程的結(jié)構框架軟件生存周期模型的分類：線性順序模型WaterfallModel增量模型IncrementalModel演化模型EvolutionaryModel又稱迭代模型，是目前的主流模型敏捷過程是演化模型中的主流5線性順序模型最早的軟件開發(fā)模型1970年W.Royce提出又稱為瀑布(Waterfall)模型需求設計編碼測試運營和維護需求規(guī)約設計文檔系統(tǒng)被確認的系統(tǒng)6優(yōu)點重視需求和設計引入階段評審，強調(diào)質(zhì)量簡單缺點串行，進度慢無法應對需求變更測試太遲，無法及時獲得用戶反饋和質(zhì)量反饋增量（Incremental）模型需求和架構確定后，增量式進行開發(fā)，構造一系列可執(zhí)行的版本7優(yōu)點并行，加快了進度缺點未能緩解變更和質(zhì)量風險需求變更和架構重構時的返工成本大大增加需要大量的開發(fā)人員演化模型風險驅(qū)動的迭代過程首先執(zhí)行風險最大的任務并行開發(fā)每次迭代都有迭代的起因可以在細化所有需求之前啟動開發(fā)工作更多的需求設計編碼測試初始需求維護請求完整產(chǎn)品示例：迭代順序執(zhí)行的演化模型8優(yōu)點有效緩解了進度、變更、技術、質(zhì)量等風險缺點復雜，如何設計迭代？迭代原則每次迭代都應產(chǎn)生一個可執(zhí)行的軟件版本每次迭代本身都包括計劃、建模、需求、分析和設計、實現(xiàn)、測試、評估等活動?；陲L險，規(guī)劃迭代－－有計劃的迭代一個軟件開發(fā)項目通常由3~9個迭代組成，項目的風險越高，迭代就越多。風險越高的工作，越在早期的迭代中執(zhí)行。迭代周期一般是2~6周，這受軟件項目的規(guī)模和復雜性、開發(fā)組織的規(guī)范、穩(wěn)定性和成熟度、以及軟件開發(fā)的自動化程度等影響。迭代可以并行、重疊、串行。9增量模型vs演化模型10增量模型演化模型演化模型成為主流現(xiàn)代軟件過程都采用演化模型統(tǒng)一軟件過程RUP敏捷過程（SCRUM、XP等）凈室（Cleanroom）軟件過程……11不同復雜性的軟件應采用不同的過程模型12簡單的軟件–瀑布模型繁雜的軟件–增量模型復雜的軟件–演化模型混沌/模糊/無序的軟件–

敏捷模型從瀑布到敏捷13瀑布vs敏捷StandishGroup2017ChaosReport1402-軟件開發(fā)過程統(tǒng)一軟件過程RUP敏捷過程XPSCRUMKanban01-軟件過程概述03-軟件運維過程1504-軟件過程的實施與改進RUP蘊涵了最佳實踐準則BestPracticesProcessMadePracticalDevelopIterativelyManageRequirementsUseComponentArchitecturesModelVisually(UML)ContinuouslyVerifyQualityManageChange16統(tǒng)一軟件過程RUP17RUP是一個風險驅(qū)動的、基于UML和構件式架構的迭代、遞增型開發(fā)過程

。InceptionElaborationConstructionTransitionRUP的四個階段LifecycleObjectiveMilestoneLifecycleArchitectureMilestoneInitialOperationalCapabilityMilestoneProductReleasetimeInception-DefinethescopeofprojectElaboration-Planproject,specifyfeatures,baselinearchitectureConstruction-BuildtheproductTransition-Transitiontheproductintoendusercommunity每個階段結(jié)束是一個大的里程碑18TypicalEffortandTimePercentagesbyPhaseIncElabConstTransEffort5%20%65%10%Time/Schedule10%30%50%10%TimePeopleConstElabTransInc19階段和迭代Planned(Technical)VisibilityPointsInceptionElaborationConstructionTransitionPreliminaryIterationArchitectureIterationArchitectureIterationDevelopment

IterationDevelopment

IterationDevelopment

IterationTransitionIterationTransitionIterationAcceptanceorendoflifeProductsufficiently

matureforcustomerstouse

(Haveasolution)Architecturebaselined

(Understandthesolution)ScopeandBusiness

Caseagreement

(Understandtheproblem)Planned(Business)DecisionPoints20ConditionsthatIncreasetheNumberofIterationsInceptionWorkingwithnewfunctionalityUnknownbusinessenvironmentHighlyvolatilescopeMake-buydecisionsElaborationWorkingwithnewsystemenvironment(newarchitecturalfeatures)UntestedarchitecturalelementsNeedforsystemprototypesConstructionLotsofcodetowriteandverifyNewtechnologyordevelopmenttoolsTransitionNeedforalphasandbetasConversionsofcustomerbaseIncrementaldeliverytocustomers21RUP按內(nèi)容組織Thedisciplinesare:BusinessModelingRequirementsAnalysis&DesignImplementationTestRUPcontentisorganizedintodisciplines.Adisciplineisacollectionofactivitiesthatareallrelatedtoamajor‘a(chǎn)reaofconcern’.DeploymentConfiguration&ChangeManagementProjectManagementEnvironment22多個迭代ReqDesignImplTestDeployIteration1Iteration2Iteration3Time23工件的演化Withtheiterativeapproach,artifactsetsmatureovertime.24案例：選課系統(tǒng)的RUP軟件過程現(xiàn)在計劃重新開發(fā)交大的選課系統(tǒng)。現(xiàn)有的系統(tǒng)存在很多問題，其中最大不足就是搶課時系統(tǒng)出現(xiàn)的性能問題。新系統(tǒng)計劃10月1日開始開發(fā)，要求1月1日上線，因為老師要選課了。注：學生選課在2月底。估計開發(fā)時間要4個月。請設計本項目的RUP軟件過程提示：迭代的設計要訣：風險高的、優(yōu)先級高的在前面的迭代完成階段和階段都是串行的每個迭代都包括需求分析、設計、編碼、測試、發(fā)布每個迭代都產(chǎn)生可運行的版本25討論：我們應該讓迭代“重疊”嗎？IBMRational對該問題的正式立場是不能重疊您的迭代。但許多成功的項目都宣稱按此方式運作的。它致使許多人懷疑，“非重疊迭代”策略是否僅是對于實踐概念的一種教條，或者在該策略背后是否真的存在某種原因。討論：1）我們應該讓迭代“重疊”嗎？為什么？2）迭代“重疊”的風險有哪些？3）在什么情況下可以讓迭代“重疊”？2602-軟件開發(fā)過程統(tǒng)一軟件過程RUP敏捷過程XPSCRUMKanban01-軟件過程概述03-軟件運維過程2704-軟件過程的實施與改進預想目標實際目標計劃執(zhí)行定義性的過程定義性的過程28預想目標實際目標經(jīng)驗性的過程經(jīng)驗性的過程29敏捷過程敏捷過程很容易適應變化并迅速做出自我調(diào)整，在保證質(zhì)量的前提下，實現(xiàn)企業(yè)效益的最大化。核心理念基于適應而非預測:通過快速、短迭代式的開發(fā)，不斷產(chǎn)出和演化可運行軟件，根據(jù)用戶的反饋信息作適應性調(diào)整，然后進入下一輪快速短迭代式開發(fā)以人為導向而非過程導向:努力營造誠信、開放的組織氛圍，根據(jù)項目中信息流通的具體情況，按高內(nèi)聚、松耦合的原則，將項目組劃分為若干個小組（每個小組以不超過10人為宜，組員均在一個工作間內(nèi)工作），通過小組內(nèi)各種渠道的溝通，來減少中間制品的工作負擔，提高應變能力--MartinFowler“NewMethodology”30XPSCRUMKanbanCrystalFDDDSDMASDLeanDevelopmentAgileThinkingExplainedNeedtorespondtoconstantchangesValuesPrinciplesPracticesThefundamentalreasonforanewparadigmDefinesthesetofbeliefsaboutwhatisthemostimportantDefinesasetofwaystomeetthevaluesDefinesindetailhowthisisimplementedinpractice31Value--敏捷宣言較之于過程和工具，更注重人及其相互作用的價值較之于無所不及的各類文檔，更注重可運行的軟件的價值較之于合同談判，更注重與客戶合作的價值較之于按計劃行事，更注重響應需求變化的價值322001年2月，敏捷過程的一些創(chuàng)始人在美國猶他州成立Agile聯(lián)盟()，制定了敏捷宣言Principles--敏捷過程的12條指導原則（1）在快速不斷地交付用戶可運行軟件的過程中，將使用戶滿意放在第一位以積極的態(tài)度對待需求的變化（不管該變化出現(xiàn)在開發(fā)早期還是后期）以幾周到幾個月為周期，盡快、不斷地交付可運行的軟件供用戶使用在項目中，業(yè)務人員和開發(fā)人員最好能一起工作以積極向上的員工為中心建立項目組，給予他們所需的環(huán)境和支持，對他們的工作予以充分的信任在項目組中，最有用、最有效的信息溝通手段是面對面的交談33Principles--敏捷過程的12條指導原則（2）測量項目進展的首要依據(jù)是可運行的軟件高度重視可持續(xù)開發(fā)項目發(fā)起者、開發(fā)者和用戶應能始終保持步調(diào)一致應時刻關注技術上的精益求精和設計的合理，這樣能提高軟件的快速應變力簡單化（盡可能減少不必要工作的藝術）最好的框架結(jié)構、需求和設計產(chǎn)生于自組織的項目組項目組要定期對其運作情況進行反思，提出改進意見，并進行相應的微調(diào)34敏捷過程的實踐效果敏捷過程對當今時代的作用可與CMM在八十年代和九十年代初的作用相媲美

--TomDeMarco,CutterTrendsReport敏捷過程在實踐中取得了巨大的成功

IONA公司的Obix技術支持小組在采用了XP方法后，軟件生產(chǎn)率提高了67%SPG(softwareproductivitygroup)的CapersJones則稱，SCRUM方法可提高生產(chǎn)率6倍35敏捷過程的適用范圍適合采用敏捷過程的軟件項目：需求不確定、易揮發(fā)有責任感和積極向上的開發(fā)人員用戶容易溝通并能參與小于10個人的項目團隊3602-軟件開發(fā)過程統(tǒng)一軟件過程RUP敏捷過程XPSCRUMKanban01-軟件過程概述03-軟件運維過程3704-軟件過程的實施與改進極限編程（XP）－敏捷的軟件開發(fā)技術由KentBeck、WardCunningham、RonJeffries等人提出反響最大、最為完善的敏捷過程方法?，F(xiàn)場客戶（On-siteCustomer）計劃博弈（PlanningGame）系統(tǒng)隱喻（SystemMetaphor）簡化設計（SimpleDesign）集體擁有代碼（CollectiveCodeOwnership）結(jié)對編程（PairProgramming）測試驅(qū)動（Test-driven）小型發(fā)布（SmallReleases）重構（Refactoring）持續(xù)集成（Continuousintegration）每周40小時工作制（40-hourWeeks）代碼規(guī)范（CodingStandards）38現(xiàn)場客戶隨時能聯(lián)系客戶是XP方法的基本要求之一XP的所有階段都要求客戶的強參與需求的調(diào)研Release的反饋參與測試…最好有客戶派員直接參與開發(fā)組有時，派開發(fā)組進駐客戶現(xiàn)場39計劃博弈XP要求結(jié)合業(yè)務和技術情況，快速確定下一次發(fā)布的范圍。在項目計劃的4要素（費用、時間、質(zhì)量和范圍）中，由客戶選擇3個，而程序員可以選擇剩下的1個。通?？蛻魪臉I(yè)務角度確定項目范圍、需求優(yōu)先級和開發(fā)進度，開發(fā)人員則做出具體的成本和技術估計。XP強調(diào)簡短和突發(fā)性的計劃，有時只用幾個小時甚至幾分鐘就能完成，而且可以隨時按需進行多次計劃。40系統(tǒng)隱喻XP通過一個簡單的關于整個系統(tǒng)如何運作的隱喻性描述（story）來指導全部開發(fā)。隱喻可以看作是一種高層次的系統(tǒng)構想，通常包含了一些可以參照和比較的類和模式，它還給出了后續(xù)開發(fā)所使用的命名規(guī)則。XP不需要事先進行詳細地架構設計。41簡化設計需求是會經(jīng)常變化的，因此設計不能一蹴而就而應該是一項持續(xù)進行的過程。KentBeck認為對于XP來說，簡單設計應該滿足以下幾個原則：成功執(zhí)行所有的測試；不包含重復的代碼；向所有的開發(fā)人員清晰地描述編碼以及其內(nèi)在關系；盡可能包含最少的類與方法。42集體擁有代碼認為開發(fā)小組的每個成員都有更改代碼的權利，所有的人對于全部代碼負責。代碼全體擁有并不意味者開發(fā)人員可以互相推委責任，而是強調(diào)所有的人都要負責。如果一個開發(fā)人員的代碼有錯誤，另外一個開發(fā)人員也可以進行BUG的修復。沒有人會成為變更的瓶頸。43結(jié)對編程由兩名程序員在同一臺電腦上結(jié)成對子共同編寫解決同一問題的代碼。通常一個人寫代碼，另一個人同時負責保證代碼的正確性和可讀性，比如編寫單元測試程序、進行代碼走查。PP可以看作是一種非正式的持續(xù)進行的同行評審（peerreview）。44測試驅(qū)動先測試，再編碼；代碼未動，測試先行強調(diào)“測試先行”。在編碼開始之前，首先將測試寫好，而后再進行編碼，直至所有的測試都得以通過。注：測試的自動化。45小型發(fā)布強調(diào)在非常短的周期內(nèi)以遞增的方式發(fā)布新版本，從而可以很容易地估計每個迭代周期的進度，便于控制工作量和風險；同時，也可以及時處理用戶的反饋。用戶在發(fā)布后兩個工作日內(nèi)，向項目小組提交“用戶接收測試報告”，由項目經(jīng)理評估測試報告，將有效的BUG提交并分配給相應的開發(fā)人員。項目小組應該在下一個迭代周期結(jié)束前修復所有用戶提交的問題。46重構強調(diào)代碼重構在其中的作用，認為應該經(jīng)常進行重構。重構是指在不改變系統(tǒng)行為的前提下，重新調(diào)整、優(yōu)化系統(tǒng)的內(nèi)部結(jié)構以減少復雜性、消除冗余、增加靈活性和提高性能。重構不是XP所特有的行為，在任何的開發(fā)過程中都可能并且應該發(fā)生。47持續(xù)集成開發(fā)人員應不斷地將代碼集成到代碼庫中，幾小時一次，絕不超過1天每個人需要在最后的版本上工作持續(xù)集成能夠在早期避免或發(fā)現(xiàn)一些兼容性問題。“現(xiàn)在付錢還是以后付更多的錢？”48每周40小時工作制不加班，不熬夜超時工作會吞噬開發(fā)組的精神和熱情，加班不得連續(xù)超過兩周，否則反而會影響生產(chǎn)率利用版本計劃會來改變項目的范圍和時間要求項目進度拖延時通過增加資源來改進也不是推薦的方法49代碼規(guī)范所有代碼必須采用統(tǒng)一標準以便理解。代碼就是文檔。強調(diào)通過指定嚴格的代碼規(guī)范來進行溝通，盡可能減少不必要的文檔。50

51XP與RUP的共性基礎都是面向?qū)ο蠓椒ǎㄈ〈鷤鹘y(tǒng)的結(jié)構化方法）都重視代碼、文檔的最小化和設計的簡化采用動態(tài)適應變化的演進式迭代周期（取代傳統(tǒng)的瀑布型生命周期）需求和測試驅(qū)動鼓勵用戶積極參與52XP與RUP的區(qū)別XP以代碼為中心，編碼和設計活動融為一體，弱化了架構的概念。RUP過程通常以架構為中心，細化階段的主要目的就是構造出一個可運行的架構原型，作為將來添加需求功能的穩(wěn)固基礎。XP不包含業(yè)務建模、部署、過程管理等概念。RUP適合各種規(guī)模的項目，XP只適用于小團隊。5302-軟件開發(fā)過程統(tǒng)一軟件過程RUP敏捷過程XPSCRUMKanban01-軟件過程概述03-軟件運維過程5404-軟件過程的實施與改進Scrum－敏捷的軟件項目管理1994年由KenSchwaber和JeffSutherland提出的敏捷過程Scrum一詞來源于橄欖球運動，意為兩隊并列爭球Scrum過程的核心：TeamEmpowerment自我管理IterativeDevelopment迭代開發(fā)55Scrum過程框架Sprint

(沖刺)：固定周期的迭代;Backlog(待辦列表)：需求列表DailyScrum（每日站會）：每日15分鐘簡會56Scrum項目組團隊組成（理想規(guī)模是7±2）ProductOwnerAddsitemstoproductbackloglistSetprioritiesTeamDeterminessprintlistDevelopssoftwareScrumMasterResponsibleforScrumprocessRemovesimpediments57團隊要求自主管理（Self-managing）以前領導布置了任務，我們實現(xiàn)就可以了，現(xiàn)在要自己挑選任務；每次Sprint結(jié)束之后，還要總結(jié)不足，提出改進，并實施。自我組織（Self-organizing）以前做好自己的事情就好了，現(xiàn)在每個人要聯(lián)合起來對項目負責，有人工作落后了還要幫助他改進，項目缺少某類資源還要自己頂上去。多功能型（Cross-functional）以前需求分析由需求分析員來做，測試由測試人員來做，現(xiàn)在每個人都全面負責，進行需求分析、設計和編碼，同時自己測試。Backlog產(chǎn)品待辦列表（ProductBacklog）是囊括了開發(fā)產(chǎn)品可能需要的所有事項的優(yōu)先排列表。由ProductOwner負責，排出優(yōu)先級，并估算開發(fā)時間Sprint待辦列表（SprintBacklog）包含了在一個Sprint內(nèi)將產(chǎn)品待辦事項列表轉(zhuǎn)化成最終可交付產(chǎn)品增量的所有任務。在Sprint計劃會議上，Team選擇并承諾實現(xiàn)SprintBacklog。在Sprint過程中，任何人無權改動SprintBacklog，直至Sprint結(jié)束。58一個SprintSprintPlanningmeeting(two4hoursegments)Productowner

&Team:identifiesbacklogitemstobedeliveredinsprint/TeamcommitsTeamplansdetailsinSprintBacklogDailyScrumMeeting(15minutes)Team:Reviewpriorday,identifyimpediments,plandaySprintReviewMeeting(4hours)Team:demonstratescompletedfunctionality-toProductOwner

andotherinterestedpartiesSprintRetrospectivemeeting(3hours)Team:howtoimprovenextsprintormakemoreenjoyable59Sprint的規(guī)則時間盒：限期N個連續(xù)日歷日Team將利用這段時間構建為stakeholder提供重大效益的功能，并保證它能交付若Sprint發(fā)生異常，ScrumMaster可非正常終止Sprint。Team若認定無法在Sprint內(nèi)兌現(xiàn)SprintBacklog承諾，可與ProductOwner協(xié)商從當前Sprint中刪除部分條目。若刪除條目過多，導致Sprint失去價值，ScrumMaster應非正常終止Sprint。Team若認定可在Sprint內(nèi)超額處理Sprint計劃的SprintBacklog，可與ProductOwner協(xié)商，添加額外的條目。60Sprint期間的交流和管理1)Scrum任務板2)Scrum每日立會3)燃盡圖（Burndown）611)Sprint任務板62ToDo待處理的任務Doing進行中的任務Done已完成的表示任務2)ScrumMeeting團隊通過每日例會（ScrumMeeting）來面對面的交流，團隊成員大多站著開會，所以又稱每日立會：我昨天做了啥我今天要做啥我碰到了哪些問題每日立會強迫每個人向同伴報告進度，迫使大家把問題擺在明面上。同時團隊要啟動每日構建，讓大家每天都能看到一個逐漸完善的版本。633)燃盡圖Sprintburndown64發(fā)布燃盡圖（ReleaseBurndown）衡量在一個發(fā)布計劃的時間段內(nèi)剩余的產(chǎn)品待辦事項列表。Sprint燃盡圖（SprintBurndown）衡量在一個Sprint時間段內(nèi)剩余的Sprint待辦事項列表條目。1用戶注冊52登入商品133展示商品54搜索商品35在線交易86交易狀態(tài)確認27特色商品推廣58第三方支付139高級搜索功能310信用評價511返點活動支持312虛擬商品支持813物流跟蹤814投訴處理5發(fā)布燃盡圖Sprint1Sprint2Sprint….Sprintn產(chǎn)品代辦事項優(yōu)先級內(nèi)容大小Sprint待辦事項Sprint

燃盡圖Sprint計劃會議Sprint評審Sprint回顧每日scrum會議項目啟動1.產(chǎn)品開發(fā)過程1.1高度透明1.2不斷反饋調(diào)整PODEVDEVDEV/QAQASMDEV/QA2.團隊2.1多功能2.2自組織3.持續(xù)改進3.1將改進嵌入開發(fā)過程3.2不斷暴露和解決問題改善65案例：Scrum的好處通過“限定時間”避免過分追求完美通過“增量交付”改進工程實踐通過“放權”和“自組織”激發(fā)創(chuàng)造力，更好地處理復雜問題，提升員工滿意度66導致SCRUM項目失敗的主要原因軟件團隊不是自組織團隊，團隊由項目經(jīng)理或ScrumMaster進行指導和組織。ProductOwner或客戶不參與每次迭代，不進行需求優(yōu)先級劃分，不參與每次演示，并且不為下一迭代選擇具有最高商業(yè)價值的項。在迭代期內(nèi)給團隊成員追加新的需求或額外的任務。6702-軟件開發(fā)過程統(tǒng)一軟件過程RUP敏捷過程XPSCRUMKanban01-軟件過程概述03-軟件運維過程6804-軟件過程的實施與改進什么是kanban看板方法源自豐田的JIT（just-in-time）生產(chǎn)方式?？窗宸椒ㄊ怯糜诟咝Ч芾碥浖_發(fā)流程的新技術。三大要素：流程可視化限制WIP

(work-in-progress,在制品)量度生產(chǎn)周期69kanban的特點kanban沒有規(guī)定角色開發(fā)需求測試運維71kanban的特點kanban沒有固定時長的迭代72kanban的特點反饋環(huán):

改變=>檢查結(jié)果=>從中學習=>繼續(xù)改變73kanban的特點

WIP上限74kanban中的原則看板的原則是“一件出去，一件進來”（由WIP驅(qū)動），所以看板團隊的響應時間（多久才能響應優(yōu)先級的變化）就等于他們要花多長時間才能把手頭的事情做完。75kanban中的團隊看板不強制要求跨功能團隊，看板圖也不是獨歸某個團隊所有?？窗鍒D對應的是流程，不必非得是一個團隊。76看板圖示例77看板圖示例78看板圖示例79看板圖示例80看板圖示例81看板圖示例82看板圖示例83看板圖示例84看板圖示例85看板圖示例86看板圖的例子87看板圖示例88過程的選擇軟件過程的選擇應綜合考慮以下多種因素，進行敏捷和規(guī)范的平衡：產(chǎn)品/項目自身的特點“重”量級的軟件過程適合需求相對穩(wěn)定、項目規(guī)模較大、開發(fā)周期較長、質(zhì)量攸關、產(chǎn)品/項目較廣的情形。而以敏捷開發(fā)為代表的“輕”量級過程比較適合需求變化快、項目規(guī)模小、開發(fā)周期短、項目干系人少的項目。團隊的實際情況和企業(yè)文化敏捷開發(fā)為主的軟件過程對團隊成員的要求非常高，無論是專業(yè)技能、溝通技巧還是職業(yè)精神。要求軟件組織對開發(fā)團隊充分信任、充分授權、積極支持。客戶的影響通?？蛻舨粫苯咏槿腴_發(fā)團隊對過程的選擇。但是大型客戶對于供應商可能有強制的過程標準。8902-軟件開發(fā)過程01-軟件過程概述03-軟件運維過程9004-軟件過程的實施與改進軟件運維的實踐現(xiàn)狀2006年10月13日，民航總局離港系統(tǒng)主機發(fā)生故障，導致長沙、北京、上海和廣州等全國多個機場離港系統(tǒng)癱瘓；2006年4月20日，中國銀聯(lián)全國性癱瘓8小時；2002年7月23日，首都機場因電腦系統(tǒng)故障，150多駕飛機延誤；2002年5月29日上午，南京火車站電腦售票系統(tǒng)由于電腦升級換代，調(diào)試時線路發(fā)生故障，引發(fā)系統(tǒng)癱瘓。2002年9月5日廣東省工行因系統(tǒng)故障，全線停業(yè)一個半小時，這是工行實施全國統(tǒng)一平臺運作后的首次故障。91從系統(tǒng)管理到IT服務管理20世紀80年代，英國中央計算機與電信開發(fā)了一套IT服務管理方法，即ITIL（InformationTechnologyInfrastructureLibrary），它被公認為IT管理的最佳實踐。2005年以ITIL為基礎的英國國家標準BS15000被國際標準化組織接受，成為IT服務管理ISO/IEC20000國際標準。92軟件運維過程（Operation&Maintenance）93開發(fā)運維一體化DevOps很多組織將開發(fā)和運維劃分成不同的部門。開發(fā)部門的驅(qū)動力通常是“頻繁交付新特性”，而運維部門則更關注IT服務的可靠性和IT成本投入的效率。兩者目標的不匹配，造成了鴻溝。DevOps將敏捷的精神延伸到運維階段，提出軟件開發(fā)和運維之間的溝通、協(xié)作和集成所采用的一體化流程、方法和體系，以提高軟件交付的價值、速度和質(zhì)量。94快速迭代的增量開發(fā)持續(xù)的自動化測試持續(xù)集成頻繁部署持續(xù)的質(zhì)量和性能監(jiān)控快速的反饋和改進機制實現(xiàn)價值從開發(fā)到運維的快速流動持續(xù)集成和持續(xù)交付（CICD)開發(fā)人員能快速地完成開發(fā)、集成、驗證，并將代碼更新部署到生產(chǎn)環(huán)境中，從而有效地將前置時間（從開發(fā)任務產(chǎn)生到交付相應的價值的這段時間）縮短到小時直至分鐘級別9502-軟件開發(fā)過程01-軟件過程概述03-軟件運維過程9604-軟件過程的實施與改進IDEALModel

97過程實施NewProcessCompletely

ImplementedPlanImplementationDefineProcessEvaluateProcessAssessDevelopmentOrganization45326EstablishProcessInfrastructureDeployProcess-MakeToolsWork-TrainPeople-…1981)EstablishProcessInfrastructureToestablishsoftwarelifecycleprocess,itisnecessarytohaveanappropriateinfrastructureinplace,meaningthattheresourcesmustbeavailable(competentstaff,tools,andfunding)andtheresponsibilitiesassigned.Whenthesetaskshavebeencompleted,itisanindicationofmanagement’scommitmentto,andownershipof,thesoftwareengineeringprocesseffort.Variouscommitteesmayhavetobeestablished,suchasasteeringcommitteetooverseetheSEprocesseffort.TheSoftwareEngineeringProcessGroup(SEPG)992)AssessDevelopmentOrganizationBusinessContextExternalFactorsInternalFactorsProductCharacteristicsProcessImplem