第10章信息系統(tǒng)開發(fā)10.1信息系統(tǒng)規(guī)劃10.2系統(tǒng)復雜性與需求的重要性10.3軟件開發(fā)模型10.4敏捷開發(fā)方法10.5系統(tǒng)分析與設(shè)計（結(jié)構(gòu)化方法）10.6系統(tǒng)分析與設(shè)計（面向?qū)ο蠓椒ǎ?第10章信息系統(tǒng)開發(fā)3掌握軟件開發(fā)模型掌握敏捷開發(fā)方法了解信息系統(tǒng)規(guī)劃了解系統(tǒng)分析與設(shè)計的結(jié)構(gòu)化方法了解系統(tǒng)分析與設(shè)計的面向?qū)ο蠓椒▽W習目標3案例廣東移動管理信息系統(tǒng)云計算體系研究10.1信息系統(tǒng)規(guī)劃信息系統(tǒng)規(guī)劃是一個識別支持企業(yè)戰(zhàn)略和目標的信息系統(tǒng)的過程。常見的信息系統(tǒng)規(guī)劃諾蘭階段模型法信息工程法價值鏈分析法企業(yè)系統(tǒng)規(guī)劃法關(guān)鍵成功要素法信息系統(tǒng)建設(shè)的六個階段（諾蘭模型）單系統(tǒng)獨立建設(shè)階段

引入數(shù)據(jù)處理系統(tǒng)，不關(guān)注系統(tǒng)的經(jīng)濟效益，用戶對信息系統(tǒng)抱著敬而遠之的態(tài)度。

系統(tǒng)規(guī)模建設(shè)階段

信息技術(shù)應(yīng)用開始擴散，管理者開始關(guān)注系統(tǒng)投資的經(jīng)濟效益，但還不存在實質(zhì)的控制。系統(tǒng)規(guī)劃發(fā)展階段

對管理信息系統(tǒng)的管控走向正規(guī)，啟動了系統(tǒng)建設(shè)規(guī)劃和項目管理計劃。系統(tǒng)嘗試整合階段

從管理計算機轉(zhuǎn)向管理信息資源，開始使用數(shù)據(jù)庫和遠程通信技術(shù)，努力整合現(xiàn)有的信息系統(tǒng)。系統(tǒng)綜合支撐階段

系統(tǒng)從支持單項應(yīng)用發(fā)展到支持綜合應(yīng)用，組織開始評估信息系統(tǒng)建設(shè)的成本和效益。全面信息化階段

正式的信息資源計劃和控制系統(tǒng)投入使用，信息資源管理的效用充分體現(xiàn)出來。10.1信息系統(tǒng)規(guī)劃——諾蘭諾蘭模型是第一個描述信息系統(tǒng)發(fā)展階段的抽象化模型諾蘭模型的假設(shè)：企業(yè)只有不斷學習才能推動階段間的轉(zhuǎn)移10.1信息系統(tǒng)規(guī)劃——BSP企業(yè)系統(tǒng)規(guī)劃（BusinessSystemPlanning，BSP）法是對企業(yè)管理信息系統(tǒng)進行規(guī)劃和設(shè)計的結(jié)構(gòu)化方法BSP法主要基于利用信息技術(shù)和信息系統(tǒng)支持企業(yè)運營的思想，是把企業(yè)目標轉(zhuǎn)化為信息系統(tǒng)戰(zhàn)略的全過程BSP方法所支持的目標是企業(yè)各層次的目標，實現(xiàn)這種支持需要許多子系統(tǒng)。10.1信息系統(tǒng)規(guī)劃——CSF關(guān)鍵成功因素法（CriticalSuccessFactors，CSF）可用來幫助進行信息系統(tǒng)規(guī)劃和需求分析。關(guān)鍵成功因素總是與那些能確保企業(yè)具有競爭能力的方面相關(guān)的。在不同類型的業(yè)務(wù)活動中，關(guān)鍵成功因素會有很大的不同，即使在同一類型的業(yè)務(wù)活動中，在不同時間內(nèi)，其關(guān)鍵成功因素也會不同。如產(chǎn)品性價比、用戶體驗、品牌理念……10.1信息系統(tǒng)規(guī)劃——比較主要優(yōu)點在于它對信息系統(tǒng)問題提出了一個全面的觀點；而且能夠明確顯示信息系統(tǒng)功能在哪方面影響企業(yè)由于該模型的范圍僅限于企業(yè)內(nèi)的信息系統(tǒng)功能，成長階段方法基本上是一個效率導向型方法成長階段法使信息技術(shù)人員與其他人員一起考查企業(yè)工作的過程；而且能幫助企業(yè)對數(shù)據(jù)類有一個清晰的了解沒有指明哪個信息系統(tǒng)應(yīng)用最為重要，因此，其分析結(jié)果必須在能夠定出信息系統(tǒng)應(yīng)用優(yōu)先次序的更大架構(gòu)內(nèi)解釋企業(yè)系統(tǒng)規(guī)劃法目的是要確定企業(yè)成功最重要的因素，并確保企業(yè)獲得信息系統(tǒng)應(yīng)用的支援。因此其重點放在商業(yè)環(huán)境下取得成功的關(guān)鍵因素上此方法注重企業(yè)的競爭性和有效性關(guān)鍵成功因素法10.2系統(tǒng)復雜性與需求的重要性系統(tǒng)需求環(huán)節(jié)中的主要問題（1）缺少規(guī)劃和設(shè)計環(huán)節(jié)，軟件的結(jié)構(gòu)隨著不斷的修改越來越糟，導致無法繼續(xù)修改；（2）忽略需求環(huán)節(jié)，再精心設(shè)計的軟件也可能很難匹配用戶的需求，導致要么被拒絕，要么花費昂貴的代價重建。（3）沒有考慮測試和程序的可維護性，也沒有任何文檔，軟件的維護十分困難。10.2系統(tǒng)復雜性與需求的重要性（續(xù)）圖10-1需求變更對系統(tǒng)開發(fā)成本的影響越早開始寫代碼，花費的時間越長！10.3軟件開發(fā)模型軟件開發(fā)模型(SoftwareDevelopmentModel)是指軟件開發(fā)全部過程、活動和任務(wù)的結(jié)構(gòu)框架。軟件開發(fā)過程包括需求分析、設(shè)計、編碼和測試等階段，有時也包括維護階段。典型開發(fā)模型生命周期模型（Lifecyclemodel）原型模型（Prototypemodel）螺旋模型（Spiralmodel）敏捷模型（Agilemodel）10.3軟件開發(fā)模型（續(xù)）10.3.1生命周期模型（瀑布模型）圖10-2生命周期模型確定系統(tǒng)、設(shè)定范疇、指定計劃需求分析，避免后續(xù)階段出現(xiàn)需求變更構(gòu)建未來系統(tǒng)的技術(shù)藍圖技術(shù)框架、數(shù)據(jù)庫和程序單元測試（通常由開發(fā)人員完成）、功能測試、系統(tǒng)集成測試以及用戶接受測試保障系統(tǒng)持續(xù)滿足業(yè)務(wù)需求，并進行必要的修補10.3軟件開發(fā)模型（續(xù)）10.3.1生命周期模型——局限性該模型假設(shè)用戶能夠在項目開始階段就明確自己的需求，并且能夠清楚地表達給開發(fā)人員缺乏靈活性，是個線性的過程，不便于通過必要的迭代或并發(fā)活動澄清本來不夠明確的需求要求階段之間產(chǎn)生大量詳盡的文檔，作為后續(xù)開發(fā)工作的依據(jù)。需求，設(shè)計階段的問題10.3軟件開發(fā)模型（續(xù)）10.3.2快速原型模型原型的必要性在于：用戶需要借助具體的設(shè)計來描述需求；用戶缺乏想象設(shè)計效果的能力；用戶沒有能力對技術(shù)設(shè)計文檔作評論；幾乎不可能為用戶界面提供一種完全、一致、可用的描述；有利于盡早開始進行有用戶參與的連續(xù)性測試。10.3軟件開發(fā)模型（續(xù)）10.3.2快速原型模型（續(xù)）圖10-3快速原型模型舉例：紀檢監(jiān)察部網(wǎng)站改版10.3軟件開發(fā)模型（續(xù)）10.3.3螺旋模型螺旋模型將生命周期模型和快速原型模型結(jié)合起來，強調(diào)其他模型所忽略的風險分析，比快速原型模型更加適合于大型復雜系統(tǒng)螺旋模型沿著螺線進行若干次迭代：制定計劃明確該階段的目標從風險角度分析備選方案實施開發(fā)客戶評價開發(fā)結(jié)果，提出建議10.3軟件開發(fā)模型（續(xù)）10.3.3螺旋模型（續(xù)）圖10-4螺旋模型10.3軟件開發(fā)模型（續(xù)）10.3.3螺旋模型——局限性說服大客戶接受這樣的演進式系統(tǒng)開發(fā)可能比較困難，合同管理和項目控制都比較難螺旋模型強調(diào)風險分析，因此對軟件開發(fā)人員要求較高，他們必須擅長識別和評估風險10.3軟件開發(fā)模型（續(xù)）10.3.4敏捷模型敏捷模型是應(yīng)對快速變化和不確定性需求的一種

軟件開發(fā)論。敏捷開發(fā)方法Scrum極限編程（ExtremeProgramming,?？s寫為XP）敏捷統(tǒng)一過程（AgileUnifiedProcess,?？s寫為AUP）10.3軟件開發(fā)模型（續(xù)）10.3.4敏捷模型（續(xù)）圖10-5理想的XP生命周期10.4敏捷開發(fā)方法—以Scrum為例Scrum，暫譯為“密集沖刺”，這是種輕量級敏捷項目管理方法，特別適合在需求多變不確定的情況下，以快速迭代和增量式開發(fā)軟件系統(tǒng)和產(chǎn)品。三個基本原則是高可視度、頻繁檢查和適應(yīng)高可視度（Visibility）指確保中間環(huán)節(jié)的可觀察性；頻繁檢查（Inspection）提供了及時評估中間成果和發(fā)現(xiàn)問題的可能；適應(yīng)（Adaptation）就是調(diào)整，對不符合標準的過程和操作進行修改和完善。Scrum敏捷項目管理目錄敏捷的背景與動機敏捷宣言及原則敏捷方法的實踐Scrum的角色Scrum流程和工作產(chǎn)品26Scrum是英語中橄欖球運動的一個專業(yè)術(shù)語，表示“爭球”，有時也翻譯成“密集沖刺”。軟件項目的復雜性橫軸代表需求的復雜度縱軸表示技術(shù)的復雜度還有人力資源的復雜度27敏捷開發(fā)模型舉例——互聯(lián)網(wǎng)時代的出版模式作者最開始的時候并沒有想出一本書，而只是把多年的積累梳理出來寫成了博客，憑借博客的成功最后得到了出版商和紙版讀者的認可。在寫成本書的過程中，作者是漸進式的進行的，每寫完一個章節(jié)，放到博客上去征求讀者的反饋，很多反饋意見在后面的章節(jié)或修訂中及時地體現(xiàn)出來，這樣就形成了與讀者之間的良好反饋，在出版之前就鎖定了大量的讀者。這就是敏捷開發(fā)提倡的“增量迭代、及時交付”的思想。這種模式能最大程度地不偏離客戶需求的本質(zhì)。目錄敏捷的背景與動機敏捷宣言及原則敏捷方法的實踐Scrum的角色Scrum流程和工作產(chǎn)品29敏捷價值觀之敏捷宣言30敏捷開發(fā)的核心思想是：以人為本，適應(yīng)變化。敏捷價值觀之敏捷宣言-1個體和交互勝過過程和工具人是軟件項目獲得成功最為重要的因素合作、溝通能力以及交互能力比單純的軟件編程能力和工具更為重要方法和工具是死的，人是活的，人要是太“面”或者協(xié)作不好，再強大的方法和工具都是白扯；31敏捷價值觀之敏捷宣言-2可以工作的軟件勝過面面俱到的文檔過多的面面俱到的文檔往往比過少的文檔更糟軟件開發(fā)的主要和中心活動是創(chuàng)建可以工作的軟件直到迫切需要并且意義重大時，才進行文檔編制編制的內(nèi)部文檔應(yīng)盡量短小并且主題突出32敏捷價值觀之敏捷宣言-3客戶合作勝過合同談判客戶不可能做到一次性地將他們的需求完整清晰地表述在合同中為開發(fā)團隊和客戶的協(xié)同工作方式提供指導的合同才是最好的合同33敏捷價值觀之敏捷宣言-4響應(yīng)變化勝過循環(huán)計劃變化是軟件開發(fā)中存在的現(xiàn)實計劃必須有足夠的靈活性與可塑性短期的迭代的計劃比中長期計劃更有效JiangsuMicrosoftTechnologyCenter34敏捷開發(fā)的12個原則我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。即使到了開發(fā)的后期，也歡迎改變需求。經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。圍繞被激勵起來的個人來構(gòu)建項目。在團隊內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。

敏捷開發(fā)的12個原則工作的軟件是首要的進度度量標準。敏捷過程提倡平穩(wěn)的開發(fā)節(jié)奏；發(fā)起人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力。簡單化是根本（不做過度設(shè)計和預測）。最好的構(gòu)架、需求和設(shè)計出自于自組織的團隊。每隔一定時間，團隊會在如何才能更有效地工作方面進行反思并對自己的行為進行相應(yīng)調(diào)整。目錄敏捷的背景與動機敏捷宣言及原則敏捷方法的實踐

Scrum的角色Scrum流程和工作產(chǎn)品37敏捷關(guān)鍵實踐1——增量迭代每個迭代有一個大約為1～4周的時間框，在SCRUM里稱為一次沖刺（超過1個月的詳細計劃往往偏差很大）每次迭代都應(yīng)該有明確的目標每次迭代都應(yīng)該有明確的可演示的工作成果迭代過程中項目團隊應(yīng)該盡量免受打擾迭代可以將項目的壓力分解到每個小的階段，風險也能同時分解38敏捷關(guān)鍵實踐2——面對面交流雖然如今通訊工具花樣繁多，但面對面交流在某些場合下仍然是不可替代的；敏捷開發(fā)把交流缺失問題考慮在內(nèi)，要求團隊成員彼此直接協(xié)作，盡量創(chuàng)造面對面交流的機會；尤其當業(yè)務(wù)分析師和軟件開發(fā)人員一起工作的時候，面對面的交流是很重要的。匿名共享需求文檔只會打開曲解和誤解之門，更不用說書面信息比口頭交流還要慢很多。39敏捷方法的其它實踐結(jié)對編程每日站立短會用戶故事團隊工作室頻繁發(fā)布自組織團隊重構(gòu)40目錄敏捷的背景與動機敏捷宣言及原則敏捷方法是什么？敏捷方法的實踐Scrum的角色Scrum流程和工作產(chǎn)品41Scrum框架42www.海頤軟件Scrum角色Scrum角色之ProductOwner產(chǎn)品負責人（ProductOwner）的職責如下：確定產(chǎn)品的功能。決定發(fā)布的日期和發(fā)布內(nèi)容。為產(chǎn)品的profitabilityoftheproduct(ROI)負責。根據(jù)市場價值確定功能優(yōu)先級。每個Sprint（即迭代周期），根據(jù)需要調(diào)整功能和優(yōu)先級（每個Sprint開始前調(diào)整）。接受或拒絕接受開發(fā)團隊的工作成果。44Scrum角色之ScrumMaster作為TeamLeader和Productowner緊密地工作在一起，他可以及時地為團隊成員提供幫助。他必須:保證團隊資源完全可被利用并且全部是高產(chǎn)出的。保證各個角色及職責的良好協(xié)作。解決團隊開發(fā)中的障礙。做為團隊和外部的接口，屏蔽外界對團隊成員的干擾。保證開發(fā)過程按計劃進行，組織DailyScrum,SprintReviewandSprintPlanningmeetings。45Scrum角色之ScrumTeam一般情況人數(shù)在5-9個左右團隊要跨職能（包括開發(fā)人員、測試人員、用戶界面設(shè)計師等）團隊成員需要全職。（有些情況例外，比如數(shù)據(jù)庫管理員）在項目向?qū)Х秶鷥?nèi)有權(quán)利做任何事情已確保達到Sprint的目標。高度的自我組織能力。向ProductOwner演示產(chǎn)品功能。團隊成員構(gòu)成在sprint內(nèi)不允許變化。46目錄敏捷的背景與動機敏捷宣言及原則敏捷方法是什么？敏捷方法的實踐Scrum的角色Scrum流程和工作產(chǎn)品4710.4敏捷開發(fā)方法—以Scrum為例10.4.2Scrum的過程框架圖10-6Scrum過程框架Sprints(沖刺)Scrum的項目過程由一系列的Sprint組成。Sprint的長度一般控制在2-4周。通過固定的周期保持良好的節(jié)奏。產(chǎn)品的設(shè)計、開發(fā)、測試都在Sprint期間完成。Sprint結(jié)束時交付可以工作的軟件。在Sprint過程中不允許發(fā)生變更。49Scrum框架50Scrum儀式之Sprint計劃會議計劃會議要有足夠的時間取出部分產(chǎn)品需求做成sprint需求，并寫成索引卡確定并細分每一個索引卡的故事（Story）進行工作認領(lǐng)（不是分配）確定每日站立會議的時間和地點確定好評審會議和回顧會議的日期Scrum儀式之Sprint計劃會議JiangsuMicrosoftTechnologyCenter52Scrum儀式之每日Scrum會議(DailyScrum)每日Scrum會議，即團隊每日例會，條件允許的話，每天都應(yīng)該在同樣的時間和地點，組織所有成員站立進行。最好是每天早晨開，一般15分鐘左右，時間比較短，也有利于團隊成員安排好當天的工作。只有團隊成員可以在例會上發(fā)言，其他人員有興趣可以參加，但只能旁聽，不能發(fā)言。每日Scrum會議由ScrumMaster主持，Scrum團隊所有成員輪流回答以下3個問題：昨天我完成了什么工作？今天我打算做什么？我在工作中遇到了什么困難？JiangsuMicrosoftTechnologyCenter53場景展示-每日站立會議Scrum任務(wù)板(TaskBoard)JiangsuMicrosoftTechnologyCenter56任務(wù)板（墻）展現(xiàn)了在Sprint過程中所有要完成的任務(wù)。在Sprint過程中我們要不斷的更新它。如果某個開發(fā)人員想到了一個任務(wù)他就可以把這個任務(wù)寫下來放在任務(wù)墻上。無論每日站會過程中或者之后，如果估計發(fā)生了變化，任務(wù)會根據(jù)變化在任務(wù)墻上做相應(yīng)的調(diào)整。通常的任務(wù)板是下面這個樣子:場景展示-任務(wù)看板Scrum儀式之Sprint評審會議Sprint評審會用來演示在這個Sprint中開發(fā)的產(chǎn)品功能給ProductOwner.ProductOwner會組織這階段的會議并且邀請相關(guān)的干系人參加。團隊展示Sprint中完成的功能一般是通過現(xiàn)場演示的方式展現(xiàn)功能和架構(gòu)不要太正式團隊成員都要參加可以邀請所有人參加JiangsuMicrosoftTechnologyCenter59Scrum儀式之Sprint回顧會議JiangsuMicrosoftTechnologyCenter60團隊的定期自我檢視，發(fā)現(xiàn)什么是好的，什么是不好的。一般控制在15-30分鐘每個Sprint都要做全體參加ScrumMaster產(chǎn)品負責人團隊可能的客戶或其它干系人Sprint回顧會議上，全體成員討論有哪些好的做法可以啟動，哪些不好的做法不能再繼續(xù)下去了，哪些好的做法要繼續(xù)發(fā)揚。Scrum框架61Scrum物件之產(chǎn)品訂單(ProductBacklog)一個需求的列表。一般情況使用用戶故事來表示backlog條目理想情況每個需求項都對產(chǎn)品的客戶或用戶有價值Backlog條目按照商業(yè)價值排列優(yōu)先級優(yōu)先級由產(chǎn)品負責人來排列在每個Sprint結(jié)束的時候要更新優(yōu)先級的排列JiangsuMicrosoftTechnologyCenter62Scrum物件之產(chǎn)品訂單(ProductBacklog)JiangsuMicrosoftTechnologyCenter63Imp：重要性；Est：大致相當于一個“理想的人天（man-day）”Scrum物件之沖刺訂單(SprintBacklog)管理Sprint的backlog:團隊成員自己挑選任務(wù)，而不是指派任務(wù)對每一個任務(wù)，每天要更新剩余的工作量估算每個團隊成員都可以修改Sprintbacklog，增加、刪除或者修改任務(wù)JiangsuMicrosoftTechnologyCenter64Scrum物件之燃盡圖(BurnDownChart)656667推薦書籍：《人月神話》第1章焦油坑第2章人月神話第3章外科手術(shù)隊伍第4章貴族專制、民主政治和系統(tǒng)設(shè)計第5章畫蛇添足第6章貫徹執(zhí)行第7章為什么巴比倫塔會失敗第8章胸有成竹第9章削足適履第10章提綱挈領(lǐng)第11章未雨綢繆第12章干將莫邪第13章整體部分第14章禍起蕭墻第15章另外一面第16章沒有銀彈……1、人月神話：向一個已經(jīng)延后的項目中投入更多的人力資源只會讓它更延后2、沒有銀彈：沒有一種策略，技術(shù)或者技巧可以極大地提高程序員的生產(chǎn)力10.5系統(tǒng)分析與設(shè)計—結(jié)構(gòu)化方