1.按照用于質量管理的能力成熟度模型（CMM）描述系統開發過程的動機。

2.區分系統生命周期和系統開發方法

3.描述系統開發的10個基本原理

4.定義問題、機會和指示——系統開發項目的能力

5.描述用于把問題、機會和指示進行分類的PIECES框架

6.描述系統開發基本階段。對于每個階段，描述它的目的、輸出和項目

7.描述覆蓋了多個系統開發階段的跨生命周期活動

8.描述貫穿系統開發基本階段的集中典型“開發路線”。描述不同的項目應該如何或者制定開發路線

9.描述用于系統開發的各種自動化工具

關鍵術語

能力成熟度模型（Capability Maturity Model，CMM）：用來評估組織的信息系統開發以及管理過程的產品的成熟度等級的框架，它由5個開發成熟度等級構成。

系統生命周期：分為兩個階段，①系統開發階段；②系統運行和支持階段，首先構造系統；然后使用系統，運行系統并支持系統；最后，從運行和支持階段再回到開發階段。

系統開發方法：為系統開發人員和項目管理者定義了一組活動、方法、最佳實踐、交付成果和自動化工具，用來開發和維護大部分或所有信息系統和軟件。

成本效益：在開發、維護和運行信息系統的成本與從系統中獲得的效益之間取得平衡。成本效益使用一種稱為成本效益分析的技術。

信息系統戰略規劃：一個正式的戰略規劃（一般3~5年），用于構造和改進信息技術架構以及使用該框架的信息系統。

企業戰略規劃：是整個企業的戰略規劃（一般3~5年），定義企業的任務、愿景、目標、戰略、基準和 評價準則。

逐步投入：在整個項目過程中都持續地重新評價可行性和風險，并相應地調整項目預算和最后期限。

風險管理：及早發現項目中可能出現的錯誤，防止它真正威脅信息系統的實現，對它們進行評估和控制。風險管理由風險分析和風險評估所驅動。

約束條件：是可能制約解決方案或問題解決過程的因素、限制條件或約束。

范圍蔓延：是一種常見現象，其中項目的需求和預期經常不顧對預算和進度的影響而緩慢增加。

系統模型：一幅系統的圖示，表示現實情況或者希望的情況。系統模型促進系統用戶、系統分析員、系統設計人員和系統構造人員之間的交流。

邏輯設計：將業務用戶需求轉換成系統模型，該模型僅僅描述了業務需求，而沒有描述這些需求的任何可能的技術設計和實現。

分析癱瘓癥：描述一種常見的項目狀態，這時過多的系統建模極大地減緩了實現系統方案的進度。

物理設計：將業務用戶需求轉換成系統模型，描述用戶的業務需求的技術實現。

系統支持：對系統用戶的不斷技術支持，以及處理可能出現的錯誤，失誤或新的需求所需的維護工作。

跨生命周期活動：存在于系統開發方法中多個階段或者所有階段的活動。例如：調查研究、記錄文檔、演示匯報、估計和度量、可行性分析、項目和過程管理、變化管理以及質量管理。

瀑布開發方法：一種系統分析和設計方法，要求每個階段必須在另一個階段之后“完成”。

迭代開發方法：在一系列連續的迭代中完成整個信息系統。每個迭代要進行足夠的分析、設計和構造。

模型驅動開發：強調繪制模型以可視化地分析問題、定義業務需求以及設計信息系統。

過程建模：以過程為中心的技術，其最流行的形式是結構化分析和設計方法，使用描述業務過程需求的模型推導出有效的軟件設計。

數據建模：以數據為中心的技術，用來建模業務數據需求，以及實現這些需求的數據庫系統。最常見的數據建模是實體關系圖。

對象建模：試圖在被稱為對象的單一結構中融合數據和過程要素。對象模型從對象和對象之間的角度文檔化系統。對象建模技術是面向對象分析和設計方法的基礎。

快速應用開發：一種系統開發策略，強調用戶深入地參與到一系列工作模型的快速進化和構造過程中，以加速系統的開發過程，系統工作原型最終將成為目標系統

原型：一個小規模的、有代表性的或者可工作的模型，反映了信息系統的用戶需求或建議設計。任何原型都可能忽略某些功能或特征，直到原型最終完全進化成需求的一個可接受的實現系統為止。

時間盒：一段不能延長的時間段（通常為60~90天），系統的第一個版本必須在這個時間段內投入運行。

建議申報書：一種與軟件供應商交流應用軟件包的業務、技術和支持需求的正式文檔，這些軟件供應商希望競爭銷售應用軟件包或服務。

報價申報書：一種與單個軟件供應商交流應用軟件包的業務、技術和支持需求的正式文檔，該軟件供應商已經被選中提供應用軟件包或服務。

差距分析：將對商用軟件包的業務和技術需求與特定商用軟件包的功能和特征進行比較，以定義不能滿足的需求。

計算機輔助軟件工程：使用支持系統模型的繪制和分析的自動化工具，有些CASE工具也提供原型設計和代碼生成能力。

CASE資料庫：一個系統開發人員的數據庫。是開發人員存儲系統模型、詳細描述和說明以及系統開發的其他商品的地方。資料庫的同義詞包括字典和百科全書。

正向工程：CASE工具的一種能力，能夠直接從系統模型生成初始軟件或數據庫代碼。

逆向工程：CASE工具的一種能力，能夠直接從軟件或數據庫代碼生成初始的系統模型。

應用開發環境：集成的軟件開發工具、它提供了以最快的速度和最高質量開發新應用程序所需的全部工具。常用的同義詞有集成開發環境（IDE）

過程管理軟件：一個 自動化工具，幫助記錄文檔與管理一套方法學和開發路線、交付成果以及質量管理標準。

項目管理軟件：一個自動化工具，幫助規劃系統開發活動、估計和分配資源、調度活動和資源、按照進度和預算監督進展、控制和修改進度和資源，以及報告項目進展。

系統開發基本原理

讓系統用戶參與

使用一套問題解決步驟

確立開發階段和開發活動

在開發過程中記錄文檔

建立標準（數據庫技術、軟件技術、接口技術）

管理過程和項目

將信息系統作為重要的投資看待

不必害怕取消和返工

分而治之

設計系統時應考慮到增長和變化

能力成熟度模型

初級級（不一致的方法）

可重復級（一致的項目管理）

已定義級（使用一致的過程）

已管理級（已管理和測量的過程）

優化級（持續過程改進）

系統生命周期和系統開發方法

范圍定義階段——項目啟動

問題分析階段——項目啟動和系統分析

需求分析階段——系統分析

邏輯設計階段——系統分析

決策分析階段——（系統分析到設計的轉換階段）

物理設計和集成階段——系統設計

構造和測試階段——系統設計繼續和系統實現

安裝和發布階段——系統實現

運行和維護階段

選擇開發路線和策略

模型驅動開發策略

優點：

需求說明往往更加全面而且被更好地文檔化

使用圖形比使用語言更容易驗證業務需求和系統設計

更容易確定、概念化和分析多種技術方案

設計說明更合理、更穩定、更具適應性、更靈活，因為它們是基于模型的，并且在構建前被全面地分析過。

當使用全面而且清楚的基于模型的規格說明構造系統時，更容易首次就正確地構造出來。

缺點：

項目持續時間很長，需要時間收集事實、繪制模型、驗證模型。如果用戶需求不確定或者不明確，這種情況就更明顯。

模型所能達到的需求理解程度最多只能與用戶的理解程度一樣。

圖形不是軟件，所以有人認為這種方法降低了用戶在項目中的主動參與成分。

模型驅動方法被認為不夠靈活——用戶在設計之前必須完全說明需求，設計必須完全記錄技術說明才能構造。

快速應用開發策略

優點：

它適合于用戶需求不確定或者不明確的項目

它鼓勵用戶和管理層主動地參與，這增加了最終用戶對項目的熱情

項目具有較高的可視性和支持程度，因為用戶深入參與到整個開發過程中

用戶和管理層看到可工作的基于軟件的方案比模型驅動開發要快得多

在原型中錯誤和遺漏往往比在系統模型中更早地被發現

測試和培訓是基本原型方法的一個自然副產品

迭代方法顯得更“自然”，因為開發過程中變化時必然的

缺點：

增加了運行、支持和維護系統所需的費用

因為省略了問題分析階段，所有RAD原型一個易犯的錯誤是解決了錯誤的問題

RAD原型可能不會鼓勵分析員考慮其他更有價值的技術方案

有時最佳方案是拋棄原型，但關聯人員經常不愿意這樣做，因為他們把這看做是當前產品的時間和精力的損失

RAD對速度的重視會對質量造成影響，因為這種方法中充斥著大量不明智的捷徑

商用應用軟件包實現策略

優點：

可以更快地實現新系統，因為不再需要大量的編程工作

許多企業沒有能力提供人力和專業知識開發內部方案

應用軟件供應商將它們的開發費用平攤到購買軟件的所有用戶身上。這樣，他們可以不斷地投資以改進軟件的特點，功能和可用性，這往往是單個企業無法做到的

應用軟件供應商對重大的系統改進和錯誤修改承擔責任

在一個行業內部，許多企業的動能相似性多于差異性。

缺點：

成功的COTS實現依賴軟件供應商的長期成功和生存能力——如果供應商不干了，你就會失去技術支持和未來的改進

購買的系統很少能反映理想方案，而企業可以通過內部開發實現理想方案。內部開發可以按照管理層和用戶的精確期望進行定制

改變業務過程以適應軟件幾乎總是會遇到一些阻力，一些用戶將不得不放棄或者分配新工作；而有些人或抵制變化，他們認為這些變化是技術驅動的，而非業務驅動的

轉載于:https://www.cnblogs.com/zpfbuaa/p/5943761.html

總結

以上是生活随笔為你收集整理的信息系统开发内容的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。