信息系統開發第一頁，共四十頁，2022年，8月28日本章主要內容3.1系統開發過程3.2FAST開發過程3.3開發路線和方法3.4自動化工具和技術第二頁，共四十頁，2022年，8月28日3.1系統開發過程堅持使用現代的嚴格的方法學可以在兩年內使70%的系統開發組織的生產率至少提高30%。使用一致的系統開發過程：提高效率，管理層可以在項目之間調動資源；產生一致的文檔，減少維護系統的生命期費用；改善質量第三頁，共四十頁，2022年，8月28日能力成熟度模型第四頁，共四十頁，2022年，8月28日3.1.1能力成熟度模型初始級:系統開發項目沒有規定的過程可以遵循開發成敗主要取決于項目團隊的經驗和技能項目開發過程不可預測、不可重復項目之間的文檔不一致可重復級:建立項目管理過程和實踐跟蹤項目成本、進度、功能組織采用開發過程，但項目與項目之間的開發過程可能不同開發成敗仍主要取決于項目團隊的經驗和技能.可以重復早期項目的成功經驗第五頁，共四十頁，2022年，8月28日能力成熟度模型已定義級:標準化系統開發過程(有時稱為“方法學”)所有項目都使用這個過程的裁減版本來開發和維護系統或軟件每個項目都產生一致且高質量的文檔和交付成果開發過程穩定、可預測、可重復已管理級:建立可度量的質量和生產率目標標準系統開發過程和產品質量的度量數據存在數據庫里，并根據數據提高項目管理水平管理層主動而不是被動應對系統開發問題系統遇到不可預期問題時，開發過程仍可以根據對問題的影響的預測和度量進行調整第六頁，共四十頁，2022年，8月28日3.1.1能力成熟度模型優化級:根據4級建立的度量和數據分析，對標準化過程進行持續監督和改進。調整開發過程中的技術和最佳實踐，包括調整開發過程本身。經驗教訓在組織內共享，保證質量，并消除低效率。注意，每個等級都是下一等級的先決條件。第七頁，共四十頁，2022年，8月28日3.1.1能力成熟度模型CMMProjectStatisticsforaProjectResultingin200,000LinesofCodeOrganization’sCMMLevelProjectDuration(months)ProjectPerson-MonthsNumberofDefectsShippedMedianCost($millions)LowestCost($millions)HighestCost

($millions)130600615.51.8100+218.5143121.3.961.7315807.728.518.933系統開發過程對質量影響第八頁，共四十頁，2022年，8月28日系統生命周期與開發方法Lifecyclestage使用系統選擇的IT系統開發使用系統開發方法學運行與維護Lifecyclestage報廢轉換系統生命期系統生命周期第九頁，共四十頁，2022年，8月28日系統生命周期與開發方法系統開發方法是一個十分正式且精確的系統開發過程，它為系統開發人員和項目管理者定義了一組活動、方法、最佳實踐、交付成果和自動化工具，用來開發和維護大部分或所有的信息系統和軟件。系統開發方法確保：提供一個一致且可再生的方法降低了錯誤的風險為各個項目生成完整且一致的文檔由于所有人都使用同樣的過程，所以可以在項目之間靈活的分配系統分析員、設計人員和構造人員后來者可以方便的獲得和理解以前的工作成果。第十頁，共四十頁，2022年，8月28日3.1.3系統開發基本原理讓用戶參與：系統用戶的參與對于成功的系統開發是必需的。交流不暢和誤解仍是系統開發中存在的主要問題。使用一套問題解決步驟：問題包括真正的問題、改進的機會、來自管理層的指示研究并理解問題、問題的上下文和問題的影響定義方案必須滿足的需求確定滿足需求的侯選方案，并選擇最佳方案設計和/或實現選出的方案觀察并評估該方案的影響，相應的細化該方案第十一頁，共四十頁，2022年，8月28日3.1.3系統開發基本原理確立開發階段和開發活動：不同的作者、專家以及公司對開發階段和開發活動的數量和范圍的描述都不盡相同。在開發過程中記錄文檔：為了促進不斷變化的關聯人員之間的有效交流，文檔必須隨同整個系統開發工作同時展開。第十二頁，共四十頁，2022年，8月28日3.1.3系統開發基本原理建立標準：為了實現或者改進系統集成，組織需要遵從標準。數據庫技術軟件技術接口技術管理過程和項目過程管理確保一個組織選定的過程在所有項目中得到一致的運用。過程管理還定義和改進選定的過程。項目管理確保以最小的開銷、在規定的時間內、以可接受的質量開發信息系統。第十三頁，共四十頁，2022年，8月28日3.1.3系統開發基本原理將信息系統作為重要的投資看待成本效益分析在整個系統開發過程中都要進行分階段的系統開發方法提供了幾次重新評價成本效益、風險和可行性的機會大多數系統所有者想從其系統中獲得超出投資范圍之外的功能不必害怕取消和返工建立多個可行性檢查點在每個檢查點上，所有的費用都被認為是過去的，所以它們同決策無關在每個檢查點上，分析員應考慮如果項目不再可行就取消它；如果項目范圍增加了，就重新評價并調整費用和進度；如果不能改變項目預算和進度，并且項目預算和進度不足以實現所有的項目目標，就減少范圍。第十四頁，共四十頁，2022年，8月28日3.1.3系統開發基本原理分而治之：通過不斷的將一個大系統分解成更容易管理的小系統，分析員可以簡化問題解決的過程設計系統時應考慮到增長和變化：企業在不斷的變化，業務需求在變，業務的優先次序在變。相應的，支持業務的信息系統也必須不斷變化。第十五頁，共四十頁，2022年，8月28日3.2FAST系統開發過程FAST3.2.1項目確定3.2.2項目階段3.2.3跨生命周期活動第十六頁，共四十頁，2022年，8月28日3.2.1項目確定項目的推動力解決問題利用機會執行指示PIECES框架性能Performance信息Information經濟Economics控制Control效率Efficiency服務Service第十七頁，共四十頁，2022年，8月28日3.2.2FAST項目階段經典項目階段：范圍定義階段問題分析階段需求分析階段邏輯設計階段決策分析階段物理設計和集成階段構造和測試階段安裝和發布階段第十八頁，共四十頁，2022年，8月28日3.2.2項目階段第十九頁，共四十頁，2022年，8月28日3.2.3跨生命周期活動調查研究（信息收集和數據收集）：調查研究對于一個項目的早期階段至關重要。記錄文檔和演示匯報：這兩種溝通技術在系統開發項目中很常見。可行性分析：技術可行行、運行可行性、經濟可行性、進度可行行、風險可行性項目管理和過程管理：過程管理定義了每個項目使用的方法。項目管理則是把管理方法應用于單個項目時的實例。第二十頁，共四十頁，2022年，8月28日3.2.4順序開發和迭代開發順序開發：要求每個階段在另一個階段之后完成，直到信息系統終結。瀑布開發方法：各個階段可以在時間上一定程度地相互重疊迭代（增量）開發方法：完成足夠的分析、設計和實現以便能夠完全開發新系統的一部分并將其盡快投入運行。一旦系統的這個版本實現了，該策略就進行另外的分析、設計和實現，以便發布系統的下一個版本。第二十一頁，共四十頁，2022年，8月28日3.3選擇開發路線和策略系統開發方法學和策略分類第二十二頁，共四十頁，2022年，8月28日3.3選擇開發路線和策略3.3.1模型驅動開發路線3.3.2快速應用開發路線3.3.3商用應用軟件包開發路線3.3.4混合開發路線第二十三頁，共四十頁，2022年，8月28日3.3.1模型驅動開發策略第二十四頁，共四十頁，2022年，8月28日模型驅動開發策略優點：需求分析更全面更好地文檔化使用圖形比使用語言更容易驗證業務需求和系統設計更容易確定、概念化和分析多種技術方案設計說明更合理、穩定、適應性使用全面規格說明，容易正確地構造系統缺點：項目持續時間長，需要時間收集實事、繪制和驗證模型模型能達到的需求理解程度最多和用戶理解程度一樣降低用戶在項目中的主動參與不夠靈活，用戶在設計之前必須完全說明需求，設計必須完全記錄下技術說明才能構造第二十五頁，共四十頁，2022年，8月28日模型驅動開發策略三種流行的模型驅動開發技術：過程建模流程圖數據流圖數據建模實體關系圖對象建模對象第二十六頁，共四十頁，2022年，8月28日3.3.2快速應用開發策略RAD基本思想：讓用戶主動參與到分析、設計和構造活動中將系統開發組織成重點突出的研討會，讓所有關聯人員一同參與通過一種迭代的構造方法加速需求分析與設計階段提前使用戶看到可工作系統原型–小規模、有代表性的或者可工作的模型，這個模型反映了信息系統的用戶需求或者建議設計。任何原型都可能忽略某些功能和特征，直到原型最終完全進化成需求的一個可接受的實現系統為止。第二十七頁，共四十頁，2022年，8月28日3.3.2快速應用開發策略第二十八頁，共四十頁，2022年，8月28日3.3.2快速應用開發策略時間盒

在一段不能延長的時間內（通常60-90天），系統的某個版本必須在這個時間段內投入運行。優點：有規律向用戶和管理層發布運行系統，提高和保持管理者和用戶對項目的熱情，因為系統工作版本按照有規律的模式進行發布。第二十九頁，共四十頁，2022年，8月28日快速應用開發策略RAD優點：

適用于用戶需求不確定不明確的項目鼓勵用戶和管理層主動參與項目具有較高可視性和支持程度用戶和管理層看到可工作的方案更快些錯誤和遺漏更早發現測試和培訓是原型法的自然副產品迭代方法更自然，因為變化是必然的RAD缺點：–可能增加運行、支持和維護費用–省略問題分析階段–RAD可能不鼓勵分析員考慮其他更有價值的技術方案–對速度的重視可能會破壞質量–拋棄原型可能被視為產品的時間和精力的損失第三十頁，共四十頁，2022年，8月28日商用軟件包開發策略為了實現業務需求，必須仔細地選擇封裝式軟件方案封裝式軟件方案不僅需要花錢購買，而且也可能更需要花錢實現軟件包通常必須定制并集成到企業中軟件包很少能實現讓用戶完全滿意的所有業務需求第三十一頁，共四十頁，2022年，8月28日3.3.3商用軟件包開發策略第三十二頁，共四十頁，2022年，8月28日商用軟件包開發策略優點更快實現系統許多企業沒有能力提供人力和專業知識開發內部方案將開發費用平攤到客戶軟件供應商負責對軟件進行改進和修改利用同行業的相似性，減少重復開發缺點形成對供應商的依賴購買系統很少能反映理想方案改善業務過程以適應軟件會遇到阻力第三十三頁，共四十頁，2022年，8月28日混合策略任何一個項目都可以選擇使用多條開發路線的組合使用什么開發路線總是在范圍定義階段期間進行選擇，并作為工作陳述的一部分進行協商一種常見的混合了模型驅動開發路線和快速應用開發路線的策略是增量開發策略。第三十四頁，共四十頁，2022年，8月28日3.3.5系統維護第三十五頁，共四十頁，2022年，8月28日3.4自動化工具和技術3.4.1計算機輔助系統工程3.4.2應用開發環境3.4.3過程和項目管理器第三十六頁，共四十頁，2022年，8月28日3.4.1CASE

Computer-aidedsoftwareengineering(CASE)

–使用支持系統模型的繪圖和分析的自動化工具。有些CASE工具提供原型和代碼產生能力。CASE資料庫（CASErepository

）–系統開發人員的數據庫，存儲系統模型、詳細描述和說明、以及系統其他開發產品的地方。也稱字典或者百科全書。正向工程–CASE工具的一種能力，能夠直接從系統模型生成初始的軟件或者數據庫代碼。

逆向工程–CASE工具的一種能力，能夠直接從軟件或者數據庫代碼生成初始的系統模型。第三十七頁，共四十頁，2022年，8月28日計算機輔助系統工程第三十八頁，共四十頁，2022年，8月28日3.4.2應用開發環境應用開發環境Applicationdevelopmentenvironments(ADEs)–集成化的軟件開發工具，提供了以最快速度和最高質量開發新系統程序所需要的全部工具。也稱集成開發環境integrateddevelopmentenvironment(IDE)ADE工具:程序語言或者解釋器界面構造工具