1、數據庫為收集到的數據提供結構化機制。任何類型的數據庫應包含以下特點：它不是將數據保存在網絡中的幾臺不同的服務器上，從而進行集中化管理。它的備份過程更加方便。它提供事務持續性。由于在一個中心位置保存和維護所有數據，它可以實現更大的一致性。它提供恢復和容錯能力。它允許多個用戶共享數據。它提供安全控制，執行完整性檢查、訪問控制和必要的機密性。數據庫模型：關系數據庫模型、層次數據庫模型、網絡數據庫模型、面向對象的數據庫模型、對象-關系數據庫模型。關系數據庫模型（Relational Database Model)使用屬性（行）和元組（列）包含和組織信息。關系數據庫模型是今天應用最廣泛的數據庫組織形式，

2、它以表(Table)的形式表示信息。一個關系數據庫由一些二維表構成，每個表包含行、列和存儲單元（行與列的交叉位置)。每個存儲單元僅包含一個數據值，表示一個特定元組的特殊屬性值主鍵（Primary Key)是將記錄中的所有數據與一個唯一值聯系起來的字段。層次數據庫模型（Hierarchical Database Model)是另一種通用的數據庫模型。數據元素之間的結構和關系與關系數據庫中不同。層次數據模型由記錄（Record)和字段（Field)構成，它們之間是邏輯的樹形關系。在層次數據庫中，父節點可以有一個子節點或者多個子節點，也可以沒有子節點。樹形結構包含許多分支（Branch)，分支又會有

3、一定數量的葉子（Leaf)，或者數據字段。這些數據有定義明確、預先指定的訪問路徑，但在建立關系方面不如關系數據庫靈活。層次數據庫通常用于映射一對多的數據關系。層次數據庫是人們最開始創建的數據庫模型，但它并不如關系數據庫應用普遍。最常用的層次模型為輕量級目錄訪問協議（Lightweight Directory Access Protocol,LDAP)模型。這種模型也用在Windows注冊表結構和不同的文件系統中，但最新的數據庫產品通常并不采用這種模型。網絡數據庫模型建立在層次數據庫模型之上。與層次數據庫模型不同，在網絡數據庫模型中，要找到一個數據元素，你不必知道如何從一個分支進入另一個分支，然

4、后從一個父節點進入一個子節點；網絡數據庫模型允許每個數據元素擁有多個父節點和子記錄。形成了一種類似網絡的冗余結構，而非嚴格的樹結構（網絡數據庫這個名稱并不表示數據在網絡上或在分布在整個網絡中，它只是描述數據元素的關系）。網絡模型為了實現冗余而建立一種類似于網狀網絡拓撲的結構；另外，與層次模型相比，網絡模型檢索數據的速度更快。這種模型使用一種記錄（Record)和集合（Set)的結構。一個記錄包含字段，它可以通過一個層次化的結構列出。集合是定義不同記錄之間的一對多的關系。一個記錄可以是任何數量的集合的“所有者”，同一個“所有者”又可能是許多不同的集合。這種結構可以為確立不同數據元素之間的關系提供

5、相當大的靈活性。面向對象的數據庫（Object-Oriented Database)可以管理多種不同類型的數據（如圖像、語音、文檔和視頻等)。在關系數據庫中，應用程序必須使用它自己的過程從數據庫中獲得數據，然后根據自己的需求處理這些數據；而傳統的關系數據庫并不像面向對象的數據庫那樣能提供訪問數據的過程。面向對象的數據庫用類（Class)來定義數據屬性和數據訪問過程。建立這種模型的目的在于突破關系數據庫在保存和處理大量數據時遇到的限制。另外，面向對象的數據庫并不依賴SQL進行交互，因此，并非SQL客戶端的應用程序也可以使用這種類型的數據庫。ODBMS并不如關系數據庫那樣用途廣泛，但它主要用于工程

6、和生物學等領域，并滿足金融領域的某些需求。對象-關系數據庫或對象-關系數據庫管理系統（ORDBM)是一種含有一個以面向對象編程語言編寫的軟件前端的關系數據庫。主要用于對保存的數據執行不同的商業邏輯。開放數據庫連接（ODBC) 是一個應用程序編程接口（API),允許應用程序與本地或者遠程的數據庫通信。應用程序向ODBC發出請求，ODBC把它翻譯成數據庫的命令。應用程序可以不用關心數據庫的驅動（Driver),這些都由ODBC完成。是一種針對基本的數據訪問技術（如OLEDB)的高級數據訪問編程接口。是一組用于訪問數據來源，而不只是數據庫訪問的COM對象。它允許開發者編寫程序來訪問數據，而不用知道數

7、據庫如何運行。在使用ADO時，SQL命令不需要訪問數據庫。對象鏈接和嵌入數據庫（OLEDB) 是運行在客戶端或者服務器上的中間件，把數據分成多個部分。它提供底層接口，允許訪問不同數據庫的數據以及不同格式的數據。以下是OLE DB的一些特點：l 替代ODBC，擴展它的功能以支持更廣泛的非關系數據庫，如對象數據庫和不一定執行SQL的電子數據表。l 一組基于COM的接口，允許應用程序以統一的方式訪問保存在不同數據源中的數據。l 由于OLE DB以COM為基礎，因此它僅限于基于微軟Windows的客戶端工具使用（與OLE無關）。l 開發者通過ActiveX數據對象（ADO)訪問OLEDB服務。l 它允

8、許不同的應用程序訪問不同類型和來源的數據。ActiveX數據對象（ADO) 是一個API,允許應用程序訪問后臺數據庫系統。它是一組ODBC接口的集合，用可訪問（Accessible)的對象來展示數據庫的功能，進而操作數據庫。ADO通過OLE DB接口與數據庫連接，可以用多種不同的腳本語言開發，下面是他的特點：l 是一種針對基本的數據訪問技術（如OLEDB)的高級數據訪問編程接口。l 是一組用于訪問數據來源，而不只是數據庫訪問的COM對象。l 它允許開發者編寫程序來訪問數據，而不用知道數據庫如何運行。l 在使用ADO時，SQL命令不需要訪問數據庫。Java數據庫連接性（JDBC) 是一個API,

9、允許Java應用程序與數據庫通信。應用程序可以直接或者通過ODBC逹接到數據庫。以下是JDBC的一些特點：l 是一個提供和ODBC相同功能的API,但專門為Java數據庫應用程序設計。l 在Java平臺與一系列數據庫之間，使用獨立于數據庫的連接。l JDBC是一種使Java程序執行SQL語句的Java API。可擴展標記語言（XML) 個數據結構化的標準，用于基于Web技術的程序的數據交換。XML是一種自定義的標記語言，可以靈活地表現數據庫中的數據。Web瀏覽器可以解析XML的標簽，向用戶說明開發者如何表示數據。數據定義語言（DDL) 定義數據庫的結構（Structure)和數據架、構（Sch

10、ema)。結構說明表的大小、鍵位置、視圖和數據元素關系。數據架構描述數據庫存儲和操作的數據類型以及它們的屬性。DDL定義了數據庫的結構、訪問操作和完整性過程。數據操作語言（DML) 包含了使用戶能查看、操縱和使用數據庫的所有命令(view、add、modify、sort 和 delete 命令）。査詢語言（QL) 使用戶可以對數據庫提出査詢請求。報表生成器（Report Generator) 提供用戶定義的數據過程輸出。數據字典是數據元素定義、架構對象（Schema Object)和引用鍵（Reference Key)的集合。架構對象可以包含表、視圖、索引、過程、函數和觸發器。數據字典可以包含

11、列的默認值、數據完整性信息、用戶姓名、用戶的權限和角色，以及審計信息。它是一種通過控制數據庫中有關數據的數據集中管理數據庫各個部分的工具，提供成組數據元素和數據庫之間的交叉引用關系。數據庫管理軟件創建并讀取數據字典，確認架構對象存在，并檢查特定用戶的進程訪問權限。當檢索數據庫時，用戶對數據的訪問被特定的視圖所限制。在數據字典中，定義了對每個用戶的視圖權限設置。當需要增加新的記錄、表、視圖或者架構時，應該更新數據字典以反映這些變化。主鍵是一個行的唯一標識符，它用于在關系數據庫中編寫索引。每個行必須擁有一個主鍵。當用戶請求查詢一條數據記錄時，數據庫通過這個唯一的主鍵跟蹤這條記錄。數據庫軟件執行3種

12、類型的完整性服務：語義完整性（Semantic Integrity),參考完整性（Referential Integrity)和實體完整性（Entity Integrity)。語義完整性機制保證結構化規則和語義規則得到遵守。這些規則與以下因素有關：數據類型、邏輯值、唯一性約束以及可能負面影響到數據庫結構的操作。如果所有外鍵參考現有的主鍵，則說明一個數據庫具有參考完整性。應通過某種機制確保沒有外鍵引用不存在的記錄的主鍵，或者空值。實體完整性保證了元組由主鍵值唯一確定。為了保持實體完整性，每一個元組必須包含個主鍵。如果不包含主鍵，數據庫就不能引用此元組。一些可配置的操作被用來幫助保護數據庫中數據的

13、完整性，這些操作包括回滾、提交、保存點和檢查點（Checkpoint)。回滾（Rollback)指的是結束當前事務并取消對數據庫做的更改。這些更改可能是數據本身發生的更改或者是架構（Schema)修改。執行回滾后，所做的變更被取消，數據庫恢復到先前的狀態。回滾發生在數據庫出現意想不到的故障或者外部接口處理程序出現錯誤時。數據庫恢復到原始狀態，而不是僅僅重傳或者更正部分數據。同時，數據庫會記錄錯誤和操作日志，以便日后審査。提交（Commit)是指結束事務操作，執行用戶做出的數據變更。顧名思義，一旦提交命令執行，用戶變更就得到確認，并反映到數據庫中。這些變更可以是數據或者數據架構,通過提交操作，其

14、他用戶或者應用程序就能訪問到更新的數據。如果用戶數據變更的提交命令沒有正確執行，那么數據庫會執行回滾命令。這保證了不會由于發生部分變更而引起數據混亂。保存點（Savepoint)用來保證系統發生故障或者探測到錯誤時，數據庫可以回到系統故障之前的狀態。兩階段提交（TwoPhase Commit)機制是數據庫用來確保數據完整性的另一種控制。數據庫通常會執行事務處理，表示用戶與數據庫同時進行交互。與事務處理相反的是批處理（Batch Processing),即數據庫變更的請求被放入一個隊列中并一次性激活而不是在用戶提交請求時立即激活。聚合是指這種情形：如果用戶沒有訪問特定信息的權限，但是他有訪問這些

15、信息的組成部分的權限。這樣，他就可以將每個組成部分組合起來，得到受限訪問的信息。用戶可以通過不同的途徑得到信息，再綜合得到本不具備明確訪問權限的信息。為了防止聚合，需要防止主體和任何主體的應用程序和進程獲得整個數據集合的權限,包括數據集合的各個獨立組成部分。客體可以進行分類并賦予較高的級別，存儲在容器中,防止低級別權限的主體訪問。對主體的查詢，可以進行跟蹤，并實施基于上下文的分類。這將記錄主體對客體的訪問歷史，并在聚合攻擊發生時限制訪問企圖。另一個安全問題是推理（Inference),和聚合很相似。推理指的是主體通過他可以訪問的信息推理出受限訪問的信息。當安全級別較低的數據可以描述出較髙級別的

16、數據時，就會發生推理攻擊。例如，假設一個職員不應該知道軍隊在某個國家的行動計劃，但是由于他可以訪問到食品需求表格和帳篷位置的文檔，那么他就可以根據食品和帳篷運送的目的地推算出軍隊正在向特定地區移動. 一個辦法是防止主體或者與主體有關的應用程序和進程間接得到能推論的信息。在數據庫開發過程中，可以實施基于內容或者基于情形的訪問控制來解決這個問題。基于內容的訪問控制（Content-Dependent Access Control)是根據數據的敏感程度實施訪問控制。數據越敏感，能夠訪問數據的個體就越少。基于上下文的訪問控制是指軟件根據請求的狀態和次序，“了解”應允許哪些行為。這表示，用戶必須追蹤用戶

17、以前的訪問嘗試，并知道什么順序的訪問步驟得到許可。基于內容的訪問控制就像是這樣：“Julio有權訪問文件A嗎？ ”系統在ACL上檢查文件A并返回一個響應：“Julio能夠文件這個文件，但只能讀取它。”基于上下文的訪問控制則更像是這樣：“Julio有權訪問文件A嗎？ ”系統然后檢查幾個數據：Julio做了哪些其他訪問嘗試？這個請求是否沒有按照安全請求的順序？這個請求是否在系統允許的訪問時間內（上午8時至下午5時）提出？如果所有這些問題的答案都與一組事先設置的參數相符，則Julio能夠訪問文件A。否則，他就不能訪問文件A。防止推理攻擊的常見措施有單元抑制（Cell Suppression)、采用數

18、據庫分隔，或者噪聲和擾動。單元抑制是一種用來隱藏或者不顯示特定存儲單元內容的技術，防止這些信息被用來進行推理攻擊。分隔數據庫（Partitioning a Database)包括將數據庫分成不同的部分，使未授權用戶很難訪問到可以用于推理攻擊的相關數據。噪聲和擾動（Noise and Perturbation)是一種在數據庫中插入偽造信息的技術，目的是誤導和迷惑攻擊者，使得真實的推理攻擊不能成功。多數情況下，數據庫在規劃和開發過程中并沒有將安全集成進來。安全需要事后考慮，作為替代，往往需要開發一個數據庫可信前端（Front End)。這種方法限制了安全粒度及可以發揮作用的安全功能。數據庫可以允許

19、一個組或者一個特定用戶訪問特定信息，而限制另一個組訪問。這種功能通過數據庫視圖（Database View)實現。多實例（Polyinstantiation)建立了相同主鍵的多元組和由安全級別定義的實例之間的關系。當一條信息插入到數據庫中時，需要限制低級別用戶訪問這條信息。通過建立另一組數據迷惑低級別用戶，使用戶認為他得到的信息是真實的，而不是僅僅限制信息的訪問。聯機事務處理（Online Transaction Processing, OLTP)用于多數據庫集群提供容錯和高性能的情況。OLTP提供一種監測問題的機制，并在問題發生時立即進行適當處理。OLTP的主要作用是確保事務正確發生或根本不

20、發生。通常，事務處理表示一些不可分割的操作獨立發生。如果其中一個操作失敗，則剩下的操作需要回滾，以確保只向數據庫中輸入準確的數據。處理事務的一組系統由一個軟件OLTP產品管理和監控，以確保一切順利平穩地進行。OLTP可以對入站請求做負載均衡。OLTP要實時記錄所出現的事務（Transaction)。在一個分布式環境下，這個過程同時修改多個數據庫。這個復雜的舉動會引起許多關于完整性的威脅，所以數據庫軟件應該具有一種叫做ACID測試的特性。原子性（Atomicity) 把事務分成多個工作單元，確保所有的修改都生效或者沒有一個修改生效。數據庫接受所有修改或者不接受任何修改。致性（Consistenc

21、y) 事務必須遵守每個數據庫的完整性策略，保證在不同數據庫中的數據的一致性。隔離性（Isolation) 事務完全分開進行，事務之間互不影響。在事務完成之前,所有的修改都沒有生效。持久性（Durability)旦事務在所有的系統上都被認為是正確的，它就要提交，數據庫不能拒絕它。為了信息檢索和數據分析，將多個數據庫或數據源聯合成一個大的數據庫。從各個不同的數據庫中提取數據傳輸到一個中央數據存儲區，這個存儲區就叫做數據倉庫（Data Warehousing)。這些數據被標準化，也就是說刪除冗余的信息，并以數據倉庫期望的方式對其進行格式化。這使得用戶只需查詢一個實體，而不用訪問和查詢不同的數據庫。數

22、據倉庫提取數據的數據源是用于操作。建立數據倉庫是為了進行分析，從而做出商業預測決策，確定營銷效率、商業趨勢甚至是欺詐行為。相關數據會先進行總結和相互關聯，然后再呈現給用戶。用戶得到的并不是最初的每一項數據，而是最能適合他的需求的更加精簡的數據。盡管數據倉庫提供更方便的訪問控制，但是由于它的集中性，數據倉庫需要更嚴格的安全。如果入侵者進入數據倉庫，那么他就可以立即訪問整個組織的數據信息了。數據挖掘（Data Mining)是對數據倉庫中的數據進行進一步處理以得到更有用信息的過程。數據挖掘工具被用來發現數據的聯系和相關性來生成元數據（Metadata)。元數據可以揭示單個信息子集中隱含的相關性，可

23、以用來發現不明顯的異常模式。數據挖掘可以檢查復雜的數據，通過模糊邏輯（Fuzzy Logic)、集合理論(SetTheory)、專家系統（Expert System)技術來簡化查詢，執行數學函數，查找到數據中的隱含模式。元數據比它的原始數據來源更有價值。數據倉庫和數據挖掘的目標是提取信息，以了解與組織活動和趨勢有關的知識，數據挖掘是一個分析數據倉庫的過程，它在不知道數據所包含意義的情況下，用一些工具去分析數據的趨勢、相關性、關聯和異常。元數據（Metadata)就是把數據放在數據庫中，然后用工具挖掘出來的結果。數據進入數據庫，而元數據從數據庫中出來。數據挖掘也稱作數據庫知識發現（Knowled

24、ge Discovery In Database, KDD),它組合了發現有效及有用模式的各種技巧。下面是KDD系統用于發現這些模式的3種方法：l 分類根據共同的相似性來組合數據。l 可能性確定數據之間的相互依賴關系，并將可能性應用到它們的關系中。l 統計確定數據元素之間的關系，并使用規則發現。系統或者產品通常會遵循如下生命周期階段:項目啟動（Project Initiation )。功能設計分析和規劃（Functional Design and Planning)。系統詳細設計（System Design Specifications)。軟件開發（Software Development)。

25、.安裝/實施（Installation/Implementation)。運行/維護（Operational/Maintenance)。處理（Disposal)。安全計劃（Security Plan)應該在項目開發之初就制定，并且集成到功能計劃中，以保證安全不被忽視。第一個安全計劃應該是廣泛的，涉及各個方面，并且引用其他參考文檔以得到更詳細的信息。這些參考文檔包括計算機標準（如RFC文檔、IEEE標準和一些最佳實踐)、先前項目文檔、安全策略、認證聲明、事件處理計劃以及國家或國際安全指南（如橘皮書、紅皮書、通用準則等)。這些文檔將使安全計劃更易讀易用。安全計劃應該有自己的生命周期。安全計劃和項目管

26、理活動需要進行審計，以保證安全相關的決定可被理解。項目啟動項目組的每一個人都應當充分理解項目需求和項目使用的范圍。這個階段包括對市場上已有產品的評估，明確現有廠商沒有滿足的用戶需求。需求也可能是來自現有客戶和潛在客戶的對特定產品的直接要求。這個建議書將被提交到高級管理層，來決定是否啟動項目，或者還需要向他們提供進一步的信息。在這個階段中將明確用戶需求，確認產品的基本安全目標。本階段必須明確產品是否進行敏感信息的處理，定義這些信息的敏感度級別（Level of Sensitive)。在風險管理過程建立之后，應該設計一個基本安全框架。風險管理將在整個項目的生命期內持續進行。風險管理風險管理階段最重

27、要的一個方面就是明確要提問的正確問題。風險分析進行風險分析的目的是鑒別相關風險和潛在的危險后果。項目組需要分析與項目失敗相關的風險，這與安全風險分析有很大的不同。安全風險包括其他不同的威脅和問題。功能設計分析和規劃在這個階段，需要制定項目計劃來定義安全行為，制定安全檢查點（Security Checkpoint)來保證安全控制措施（Security Control)的質量控制，以及識別配置過程和變更控制過程。在這個階段，進行資源確定、形成測試計劃和評估準則來保證安全控制措施的正確測試。正式的功能基線的形成意味著以一種正式的方式，通常是文檔化，勾勒出產品的期望輪廓。測試計劃在每個階段需要被更新，

28、以保證所有問題都被正確測試。在生命周期中可能需要不止一次風險分析。因此在編碼開始之前，需要有明確的目標和方向,系統詳細設計信息模型（Informational Model) 規定被處理信息的類型以及如何進行處理。功能模型（Functional Model) 概括應用程序需要執行的任務和功能。行為模型（Behavioral Model)說明應用程序在特定事務發生過程中和發生之后的狀態。這個階段需要確認任務分解結構（Work Breakdown Structure, WBS),包括開發階段和實施階段。WBS包含測試、開發、分段實施、集成測試和產品發布等各個階段的時限和詳細活動。系統設計是用來描述用

29、戶需求和系統內部行為的工具，它通過映射這兩個方面來描繪系統是如何通過內部行為完成用戶需求的。在本階段的開始，需要考慮產品的更多細節以及產品的工作環境。功能性需求在最后確定。本階段解決了提供這種功能所需的工作機制，決定如何進行編碼、測試和實施。產品的模塊化和重用（Modularity and Reusability)問題，或者說產品組件問題，需要在這個階段解決。提供關鍵安全功能的代碼設計應該盡量簡潔，以便能夠以盡可能明確的方式發現錯誤。在早期階段，需要考慮產品和組件的可測試性，而不是在后期考慮。在這個階段，需要進一步仔細考慮在項目啟動階段提出的問題，保證詳細設計中解決了每一個問題。在設計階段所作

30、的決定，對開發階段而言是關鍵的。設計是用戶需求轉化為軟件的唯途徑；這樣，軟件設計就是整個產品開發的基礎。軟件開發在這個階段，程序員和開發者都需要深度參與。在這個階段，程序員應當持一種不允許產生軟件缺陷的態度進行工作。正式或者非正式的測試應該盡快開始。單元測試（Unit Testing)可以在開發早期開始。不同的環境類型（開發、測試和生產）應當敢正確分離，功能和操作不應該重疊。安全測試應當針對項目早期識別出的風險。在這個階段通常需要進行安全攻擊和滲透測試來發現任何遺漏的軟件缺陷，功能、性能和抗滲透性被進一步評價。產品應該在不同的環境中測試不同的應用、不同的配置和不同的硬件平臺。安裝/實施實施階段

31、著重于如何使用和操作開發好的系統或者應用程序。在這個階段，用戶已經購買了開發好的產品，并安裝到工作環境中。產品需要配置到一個正確的保護等級，通過執行功能和性能測試并進行結果分析，驗證產品是否滿足用戶的安全需求。系統配置應當被記錄到文檔中。要開發出用戶指南和運行維護手冊，以使用戶知道如何正確使用系統，使技術人員知道在需要時如何正確配置產品。需要監視安全活動，以確保系統或應用以服務水平協議（Service Level Agreement, SLA)保證的方式運行。認可（Accreditation)應當在開發之后，系統應用開始運行之前進行。這個過程需要遵循認證過程，正式或者非正式地測試所有的安全特征

32、，以確認產品是否完成所需的安全功能。認證（Certmcation)是一個檢查和評估安全控制的過程，通常由外部獨立的機構執行。認可是管理層對系統的正式接受，也是明確對風險的接受。旦確認新系統提供的安全功能并且理解和接受殘余風險，管理層應當發布一個正式的認可聲明。應當打開審計功能并監視事故恢復計劃（Contingency Recovery Planning),開發響應程序并進行測試，以保證系統和產品在系統故障和緊急情況下能夠正確響應。運行/維護運行保證（Operational Assurance)通過以下活動執行：進行弱點測試、系統行為監控、事件審計。測試類型單元測試（Unit esting) 體

33、組件位于一個受控的環境中，程序員在這里確認數據結構、邏輯和邊界條件。集成測試（Integration Testing) 驗組件是否按設計規范中規定的那樣協同工作。驗收測試（Acceptance Testing) 保代碼滿足客戶的需求。回歸測試(Regression Testing) 進行系統變更后重新進行測試，以確保功能性、性能和保護級別。垃圾收集（Garbage Collection)是操作系統自動執行內存管理任務的一種方式。事后回顧事后回顧應該是有組織的活動，有人主持會議和進行記錄，但對每一個成員應該有寬松和諧的氣氛，以使他們更好地表達觀點和想法。重要的一點是，會議不應該成為指責和抱怨的場

34、所。項目是一個不斷學習的過程，其職責是以最短的時間和最低的成本制造出最好的產品。理解這兩點的益處，使事后回顧成為每個項目的一部分，這對管理層來說是有益的。最成功的情況是能夠簡化項目過程和項目管理，使之成為一個能夠達到期望質量等級的可重復過程，然后繼續考慮如何改善項目和進一步積累。瀑布(waterfall)使用分離的開發階段的經典方法，在進入項目的下一個階段之前，要求正式的評審和文檔記錄。螺旋模型(spiral model)建立于瀑布方法之上的一種方法，著重強調在開發周期不同階段的風險分析、原型化和模擬。這種方法定期重訪前面的階段，以更新和驗證設計需求。結構化編程開發(structured pr

35、ogramming development)這種編程方法涉及使用邏輯塊以實現應用過程化編程的系統設計。結構化程序布局最小化轉移控制語句(如GOTO)的隨意使用，并強調單個進出點。這種層次化方式使得稍后能夠更容易地理解和更改程序。結構化編程鼓勵模塊重用，從而優化內存利用。迭代開發(iterative development)這種方法通過循環方式進行軟件開發。與傳統模型不同的是，迭代開發關注通過持續評估項目的當前狀態來籌劃項目里程碑，而評估借助基于資源、時段和執行計劃的初始目標。迭代開發提供了一種評估項目整體狀態的動態方法，并且允許通過修正來改善項目的效率。改進原型模型(Modified Prot

36、otype Model, MPM)作為在Web應用程序開發中所面對的挑戰而專門開發的一種方法，改進原型模型允許開發人員即時將客戶需求轉換為可顯示的產品或原型。改進原型通常用于開發人員和客戶對產品的最終特性沒有把握的情況。使用可改進的原型使得最終產品能夠成為更清晰的系統規范。探索模型(exploratory model)這種方法用于項目目標未被清楚定義的場合。探索模型關注的不是顯式任務，而是依賴于一組可能融入最終產品工作的隱式規范。測試是探索開發的一個重要部分，以便確定項目的當前階段是否遵從可能的實現場景。聯合分析開發(Joint Analysis Development, JAD)這種方法在一

37、個面向工作間的環境中釆用工作組的方式開發應用程序。快速應用開發(Rapid Application Development, RAD) 一種判斷用戶需求并快速開發系統以滿足即時需要的方法。重用模型(reuse model)這種模型通過使用日益增多的模型來進行軟件開發。通過逐漸更改原有的原型以滿足客戶的需求，可重用程序不斷演變。因為重用模型不需要從頭構建程序，所以顯著減少了開發成本和時間。凈室(cleanroom)通過遵循結構化且規范的開發和測試方法來力圖防止錯誤和問題的解決途徑。這種模型用于高質量和嚴要求的應用程序(通過嚴格的認證過程)。組件型開發(component-based develo

38、pment)這種模型將獨立、標準的模塊裝配在可服務程序內。每個標準模塊都由一個功能算法或指令集組成，并且被提供一個與其他模塊通信的接口。經常用在面向對象的編程中的“對象”是這些模塊的一個常見示例。組件型開發在程序中添加了可重用性和可插入的功能性，它廣泛用在現代編程中，以擴大程序的連貫性，并大大降低了軟件維護成本。極限編程(extreme programming)這種方法通常在要求快速適應以改變客戶需求的場景中實現。極限編程強調客戶的反饋，從而評估項目結果和分析可能需要進行一步注意的項目作用域。極限編程的編碼原則舍棄了傳統的、為代碼重用所執行的長期規劃，并致力于創建為同期工作而優化的簡單代碼。極

39、限編程承認客戶需求在整個項目生命周期中可能顯著變化的事實，并且使用開發進程來調整這些變化。CASE工具的目標就是在軟件開發過程中支持一個或多個軟件工程任務和活動，它們使用特定的工具在開發和詳細分析中應用工程原理。很多情況下，有必要根據己搜集的軟件產品需求開發一個模型供用戶和開發人員使用。這個模型叫做原型（Prototype),它可以向用戶說明開發小組的前進方向以及對用戶需求的解釋。原型使用戶可以了解開發方向，得到開發完成后產品的外觀概念，向用戶進一步解釋需求方面的問題和疑惑。在開發過程中，原型還可以使測試工作更早地進行，以及早發現和解決問題或錯誤。有的項目龐大，可能需要劃分產品，以便每一部分都

40、可以檢查或建立其原型。如果沒有正確處理，開發和生產過程中的變更可能造成大量混亂。發生變更有幾種原因。在開發階段，用戶可能會改變需求，增加、刪除或者修改某些特定的功能。在生產階段，變更可能會由環境改變造成，如對產品或系統的新的需求、新發布的補丁程序或者升級程序。這些變化應當被嚴格控制，以保證每個變更都被批準、正確合并以及不會對原來的功能造成負面影響。配置管理（Configuration Management)是控制產品生命周期和記錄時必要的變更控制活動的過程。通常開發經理必須通報項目經理，如果引入變更會需要多少額外的工作量，應該采取哪些步驟保證變更不會影響產品中的其他組件。此外，安全不能遭到破壞，變更必須由管理層批準。當一個程序員改變源代碼時，這種改變應該在代碼的測試版本上進行。對源代碼的變更絕對不能在代碼的生產版本上進行。發生變更的代碼，經過測試才能進入代碼庫中。生產代碼只能從代碼庫中得到，而不能從程序員或者測試環境中得來。能力成熟度模型（Capability Maturity Model，CMM)描述軟件開發流程的基本規程、原則和實踐。該模型幫助軟件公司改善軟件開發過程，將一些“突發奇想”的行為變成一個有規律、可重復的步驟，從而提高軟件質量，縮短開發周期，提供更好的項目管理