軟件開發的基本知識
軟件開發生命週期模型
軟件開發生命週期模型的基本知識點如下：
瀑布模型
是一種將系統按軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等6個基本活動，並且規定了它們自上而下、相互銜接的固定次序的系統開發方法。瀑布模型強調文檔的作用，並要求每個階段都要仔細驗證，它適用於需求明確或很少變更的項目。
V模型
是瀑布模型的一種演變模型，將測試和分析與設計關聯進行，加強分析與設計的驗證。
演化模型
主要針對需求不明確的軟件開發項目。根據用戶的需求，首先開發核心系統。當該核心系統投入運行後，用戶試用並有效地提出反饋。開發人員根據用戶的反饋，實施開發的迭代過程。每一次迭代過程由需求、設計、編碼、測試和集成等階段組成，爲整個系統增加一個可定義的、可管理的子集。也可將該模型看做是重複執行的多個“瀑布模型”。
螺旋模型
是指將瀑布模型和演化原型模型結合起來，強調風險分析的一種開發模型。
噴泉模型
基於對象驅動，主要用於描述面向對象的開發過程。其開發過程具有迭代性和無間隙性，“迭代”意味着模型中的開發活動常常需要多次重複，每次重複都會增加或明確一些目標系統的性質，但卻不是對先前工作結果的本質性改動。“無間隙”是指在開發活動(如分析、設計、編程)之間不存在明顯的邊界，而是允許各開發活動交叉、迭代地進行。
增量開發
增量開發是把軟件產品作爲一系列的增量構件來設計、編碼、集成和測試。每個構件由多個相互作用的模塊構成，並且能夠完成特定的功能。其優點包括：能在較短的時間內向用戶提交可完成一些有用工作產品；逐步增加產品的功能可以使用戶有較充分的時間學習和適應新產品；項目失敗的風險較低；優先級高的服務首先交付，使得最重要的系統服務接受最多的測試。
軟件開發過程
需求分析確定軟件要完成的功能及非功能要求；概要設計將需求轉化爲軟件的模塊劃分，確定模塊之間的調用關係；詳細設計將模塊進行細化，得到詳細的數據結構和算法；編碼根據詳細設計進行代碼的編寫，得到可以運行的軟件，並進行單元測試。
軟件設計原則
結構化分析與設計
軟件設計必須依據軟件的需求來進行，結構化分析的結果爲結構化設計提供了最基本的輸入信息，其關係爲：
（1）根據加工規格說明書和控制規格說明進行過程設計；
（2）根據數據字典和實體關係圖進行數據設計；
（3）根據數據流圖進行接口設；
（4）根據數據流圖進行體系結構設計。
高內聚，低耦合
內聚是指模塊內部各元素之間聯繫的緊密程度，也就是代碼功能的集中程度。耦合是指模塊之間相互聯繫的緊密程度。
模塊內聚通常可以分爲7種，根據內聚度從高到底排序表如下：
| 內聚類型 | 描述 |
|---|---|
| 功能內聚 | 完成一個單一功能，各個部分協同工作，缺一不可 |
| 順序內聚 | 處理元素相關，而且必須順序執行 |
| 通信內聚 | 所有處理元素集中在一個數據結構的區域上 |
| 過程內聚 | 處理元素相關，而且必須按特定的次序執行 |
| 瞬時內聚 | 所包含的任務必須包含在同一時間隔內執行（如初始化模塊） |
| 邏輯內聚 | 完成邏輯上相關的一組任務 |
| 偶然內聚 | 完成一組沒有關係或鬆散關係的任務 |
模塊的耦合性類型通常分爲如下7種，根據耦合度從低到高排序如下：
| 耦合類型 | 描述 |
|---|---|
| 非直接耦合 | 沒有直接聯繫，互相不依賴對方 |
| 數據耦合 | 藉助參數表傳遞簡單數據 |
| 標記耦合 | 一個數據結構的一部分藉助於模塊接口被傳遞 |
| 控制耦合 | 模塊間傳遞的信息中包含用於控制模塊內部邏輯的信息 |
| 外部耦合 | 與軟件以外的環境有關 |
| 公共耦合 | 多個模塊引用同一個全局數據區 |
| 內容耦合 | 一個模塊訪問另一個模塊的內部數據 一個模塊不通過正常入口轉到另一個模塊的內部 兩個模塊有一部分程序代碼重疊 一個模塊有多個入口 |
ISO/IEC9126的軟件質量模型
(1)功能性。
功能性是指與軟件所具有的各項功能及其規定性質有關的一組屬性， 包括:
●適合性:與規定任務能否提供一組功能以及這組功能的適合程度有關的軟件屬性。適合程度的例子是面向任務系統中由子功能構成的功能是否合適、表容量是否合適等。
●準確性:與能否得到正確或相符的結果或效果有關的軟件屬性。此屬性包括計算
值所需的準確程度。
●互操作性(互用性):與同其他指定系統進行交互的能力有關的軟件屬性。爲避免可能與易替換性的含義相混淆，此處用互操作性(互用性)而不用兼容性。●依從性:使軟件遵循有關的標準、約定、法規及類似規定的軟件屬性。
●安全性:與防止對程序及數據的非授權的故意或意外訪問的能力有關的軟件屬性。
eg:將每個用戶的數據和其他的用戶的數據隔離開，是考慮了軟件的安全性質量子特性。隸屬於功能特性。
(2)可靠性。
可靠性是指在規定運行條件下和規定時間週期內，與軟件維護其性能級別的能力有關的一組屬性。 可靠性反映的是軟件中存在的需求錯誤、設計錯誤和實現錯誤而造成的失效情況，包括:
●成熟性:與由軟件故障引起失效的頻度有關的軟件屬性。
容錯性:與在軟件故障或違反指定接口的情況下，維持規定的性能水平的能力有關的軟件屬性。指定的性能水平包括失效防護能力。
●可恢復性:與在失效發生後，重建其性能水平並恢復直接受影響數據的能力以及爲達此目的所需的時間和努力有關的軟件屬性。
(3)可用性。
可用性是指根據規定用戶或隱含用戶的評估所作出的與使用軟件所衢要的努力程度有關的一一組屬性，包括:
●可理解性:與用戶爲認識邏輯概念及其應用範圍所花的努力有關的軟件屬性。
●易學性)與用戶爲學習軟件應用，(如運行控制、輸入、輸出)的努力有關的軟件屬性。
●可操作性:與用戶爲操作和運行控制的努力有關的軟件屬性。
(4)效率。
效率是指在規定條件下，與軟件性能級別和所用資源總量之間的關係有關的-組屬性。包括:
●時間特性:與軟件執行其功能時響應和處理時間以及吞吐量有關的軟件屬性。
●資源特性:與在軟件執行其功能時所使用的資源數量及其使用時間有關的軟件屬性。
(5)可維護性。
可維護性是指與對軟件進行修改的難易程度有關的一組屬性，包括:
●可分析性:與爲診斷缺陷或失效原因及爲判定待修改的部分所需努力有關的軟件屬性。
●可改變性:與進行修改、排除錯誤或適應環境變化所需努力有關的軟件屬性。.穩定性:與修改所造成的未預料結果的風險有關的軟件屬性。
●可測試性:與確認已修改軟件所需的努力有關的軟件屬性。此子特性的含義可能
會被研究中的修改加以改變。
(6)可移植性。
可移植性是指與一個軟件從一個環境轉移到另一個環境運行的能力有關的一組屬性。包括:
●適應性:與軟件無須採用爲該軟件準備的活動或手段就可能適應不同的規定環境
有關的軟件屬性。
●可安裝性:與在指定環境下安裝軟件所需努力有關的軟件屬性。
●遵循性(-致性):使軟件遵循與可移植性有關的標準或約定的軟件屬性。
●可替換性:與軟件在該軟件環境中用來替代指定的其他軟件的機會和努力有關的軟件屬性。爲避免可能與互操作性(互用性)的含義相混滑，此處用可替換性而不用兼容性。特定軟件的可替換性並不隱含此軟件可由所考慮的軟件所替代。可替換性可能包含可安裝性和適應性這兩個屬性。由於此概念的重要性，它以被採用作爲一個獨立的子特性。
軟件測試
軟件測試的目的就是在軟件投入生產性運行之前，儘可能名地發現軟件產品(主要是指程序)中的錯誤和缺陷。而根據理論推測，是不可能發現軟件中所以錯誤的。而一個高效的測試是指用少量的測試用例，發現被測軟件儘可能多的錯誤。軟件測試所追求的目標是以儘可能少的時間和人力發現軟件產品中儘可能多的錯誤。
測試過程
單元測試
單元測試也稱模塊測試，通常可以放在編程階段，由程序員對自己編寫的模塊進行測試，檢查模塊是否實現了詳細設計說明書中規定的功能和算法。單元測試主要發現編程和詳細設計中產生的錯誤，單元測試計劃應該在詳細設計階段之前。單元測試期間着重從以下幾個方面對模塊進行測試:模塊接口、局部數據結構、重要的執行通路、出錯處理通路、邊界條件等。
集成測試
集成測試也稱組裝測試，它是對由各模塊組裝而成的程序進行測試，主要目標是發現模塊間的接口和通信問題，驗證模塊間是否按照規定的方式正確工作。例如，數據字過接口可能丟失:一個模塊對另一個模塊可能由於疏忽而造成有害影響:把子功能組合起來可能不產生預期的主功能:個別看來是可以接受的誤差可能積累到不能接受的程度:全程數據結構可能有問題等。集成測試主要發現設計階段產生的錯誤，集成測試計劃應該在概要設計階段制定。
確認測試
確認測試主要依據軟件需求說明書檢查軟件的功能、性能及其他特徵是否與用戶的需求致。確認測試計劃應該在需求分析階段制定。一般情況下，通過確認測試後的軟件就可以交付使用了。
系統測試
系統測試的對象是完整的、集成的計算機系統，系統測試的目的是在真實系統工作環境下，驗證完整的軟件配置項能否和系統正確連接，並滿足系統子系統設計文檔和軟件開發合同規定的要求。系統測試的技術依據是用戶需求或開發合同，除應滿足一股測試的准入條件外，在進行系統測試前，還應確認被測系統的所有配置項已通過測試，對需要固化運行的軟件還應提供固件。
軟件測試方法
白盒測試
又稱結構測試，主要用於單元測試階段。它把程序看成裝在”個透明的白盒子裏，測試者完全知道程序的結構和處理算法。
邏輯覆蓋
輯的覆蓋程度。主要的覆蓋標準有六種:語句覆蓋(SC)、判定覆蓋(DC)、條件覆道(CC)、判定/條件覆蓋(CDC)、組合條件覆蓋(MCC)和路徑覆蓋。
(1)語句覆蓋是指選擇足夠多的測試用例，使得運行這些測試用例時，被測程序的每個語句至少執行一一次。 顯然，語句覆蓋是一種很弱的覆蓋標準。
(2)判定覆蓋又稱分支覆蓋，它的含義是不僅每個語句至少執行-次， 而且每個判定的每種可能的結果(分支)都至少執行一次。 判定覆蓋比語句覆蓋強。
(3)條件覆蓋的含義是不僅每個語句至少執行一次，而且使判定表達式中的每個條件都取到各種可能的結果。(因此條件覆蓋不一定包含判定覆蓋，判定覆蓋也不-定包含條件覆蓋。
(4)判定/條件覆蓋就是同時滿足判定覆蓋和條件覆蓋的邏輯覆蓋。它的含義是，選取足夠的測試用例，使得判定表達式中每個條件的所有可能結果至少出現-次，而且每個判定本身的所有可能結果也至少出現-次。
(5)條件組合覆蓋的含義是，選取足夠的測試用例，使得每個判定表達式中條件結果的所有可能組合至少出現一次。 (因此，滿足條件組合覆蓋的測試用例，也-定滿足判定/條件覆蓋。
(6)路徑覆蓋的含義是，選取足夠的測試用例，使得程序的每條可能執行到的路徑都至少經過一次(如果程序中有環路，則要求每條環路至少經過一次)。
路徑覆蓋實際上考慮了程序中各種判定結果的所有可能組合，因此是一種較強的覆蓋標準。但路徑覆蓋並未考慮判定中的條件結果的組合，並不能代替條件覆蓋和條件組合覆蓋。
黑盒測試
黑盒測試又稱功能測試，主要用於集成測試和確認測試階段。它把軟件看作一個不透明的黑盒子，完全不瞭解軟件的內部結構和處理算法，它只檢查軟件功能是否能按照軟件需求說明書的要求正常使用，軟件是否能適當地接收輸入數據併產生正確的輸出信息，軟件運行過程中能否保持外部信息的完整性等，常見的黑盒測試方法包括等價類量分、邊值分析、錯誤推測和因果圖等。
等價類劃分
所謂等價類劃分就是某個輸入域的集合，對於一個等價類中的輸入值來說，他們揭示程序中錯誤的作用是等效的。也就是說，如果等價類中的一個輸入輸入數據能檢測出一個錯誤，那麼 等價類中的其他輸入數據也能檢測出同一個錯誤。 等價類可以分爲有效等價類和無效等價類，其中如果個等 價類內的數據是符合(軟件需求說明書)要求的、合理的數據，則稱這個等價類爲有效等價類:否則，則稱這個等價類爲無效等價類，無效等價類主要用來檢驗軟件的容錯性。
採用等價類劃分方法來設計測試用例的步驟如下:
(1)根據軟件的功能說明，對每一一個輸入條件確定若干個有效等價類和若千個無效等價類，併爲每個有效等價類和無效等價類編號。
(2)設計一個測試用例，使其覆蓋儘可能多的尚未被覆蓋的有效等價類。重複這一步，直至所有的有效等價類均被覆蓋。
(3)設計一個測試用例，使其覆蓋一一個尚未被覆蓋的無效等價類。 重複這一步，直至所有的無效等價類均被覆蓋。
a測試
a測試是用戶在開發者的場所由開發者指導完成的測試。開發者負責記錄發現的錯誤和使用中遇到的問題，換句話說，al 測試是在“受控的"環境中進行的。
β測試
β測試是在一一個或多 個用戶的現場由該軟件的最終用戶實施的，開發者通常不在現場，用戶負責記錄發現的錯誤和使用中遇到的問題並把這些問題報告給開發者。也就是說，β測試是在“非受控的"環境中進行的。
迴歸測試
迴歸測試是測試軟件變更之後，變更部分的正確性和對變更需求的符合性，以及軟件原有的、正確的功能、性能和其他規定的要求的不損害性，因此，只要軟件發生了變更，都應該進行相應的迴歸測試。
軟件測試準則
另外，在做軟件測試時，要注意以下準則:
(1)應該儘早地、不斷地進行軟件測試，把軟件測試貫穿於開發過程的始終。
(2)所有測試都應該能追溯到用戶需求。從用戶的角度看，最嚴重的錯誤是導致軟件不能滿足用戶需求的那些錯誤。
(3)應該從“小規模”測試開始，並逐步進行“大規模”測試。
(4)應該遠在測試之前就制定出測試計劃。
(5)根據Pareto原理，80%的錯誤可能出現在20%的程序模塊中，測試成功的關鍵是怎樣找出這20%的模塊，因此，對發現錯誤較多的程序段，應進行更深入的測試。
(6)應該由獨立的第三方從事測試工作。
(7)對非法和非預期的輸入數據也要像合法的和預期的輸入數據一樣編寫測試用例。
(8)檢查軟件是否做了應該做的事僅是成功的半，另半是看軟件是否做了不該做的事。
(9)在規劃測試時不要設想程序中不會查出錯誤。
(10)測試只能證明軟件中有錯誤，不能證明軟件中沒有錯誤。
能力成熟度模型CMM
CMM模型將軟件過程的成熟度分爲5個等級。
(1)初始級:
軟件過程的特點是無秩序的，有時甚至是混亂的。軟件過程定義幾處於無章法和步驟可循的狀態，軟件產品所取得的成功往往依賴極個別人的努力和機初始級的軟件過程是未加定義的隨意過程，項目的執行是隨意甚至是混亂的。也許，些企業制訂了- -些軟件工程規範，但若這些規範未能覆蓋基本的關鍵過程要求，且執沒有政策、資源等方面的保證，那麼仍然被視爲初始級。（特點是混亂和不可預測）
(2) 可重複級:
已經建立了基本的項目管理過程，可用於對成本、進度和功能特進行眼蹤。對類似的應用項目，有章可循並能重複以往所取得的成功。焦點集中在軟管理過程上。一個可管理的過程則是- - 個可重複的過程，一一個可重複的過程則能逐漸化和成熟。從管理角度可以看到一個按計劃執行的、階段可控的軟件開發過程。(項目得到管理監控和跟蹤，有穩定的策劃和產品基線)
(3)定義級:
用於管理和工程的軟件過程均已文檔化、標準化，並形成整個軟件織的標準軟件過程。全部項目均採用與實際情況相吻合的、適當修改後的標準軟件過來進行操作。要求制定企業範圍的工程化標準，而且無論是管理還是工程開發都需要套文檔化的標準，並將這些標準集成到企業軟件開發標準過程中去。所有開發的項目需根據這個標準過程，剪裁出與項目適宜的過程，並執行這些過程。過程的剪裁不是隨意的，在使用前需經過企業有關人員的批准。(通過軟件過程的定義和制度化確保對產品質量的控制)
(4)管理級:
軟件過程和產品質量有詳細的髮量標準，軟件過程和產品質量得到了定量的認識和技制。(特點是產品質量得到策劃，軟件過程基於度量的跟蹤)
(5)優化級:
通過對來自過程、新概念和新技術等方面的各種有用信息的定最分析，能夠不斷地)將續地進行過程改進。(持續的過程能力改進)
系統轉換
本題主要考查系統轉換的概念。
新老系統之間的轉換有三種方式:直接轉換、並行轉換和分段轉換。
下面詳細1這三種轉換各自的特點。
- 直接轉換就是在確定新系統運行無誤時，立刻啓用新系統， 終止老系統運行。)方式對人員、設備費用很節省，一般適用於處理過程不太複雜、 數據不很重要的場臺
- 並行轉換是讓新老系統並行段時間，經過一段時間的考驗以後， 新系統正式智老系統。對於較複雜的大型系統，它提供了一個與老系統運行結果進行比較的機會，以對新老兩個系統並行工作，消除了尚未認識新系統時的緊張和不安。在銀行、財務一些企業的核心繫統中，這是一種經常 使用的轉換方式。它的主要特點是安全、可靠但費用和工作量都很大，因爲在相當的長時間內系統要兩套班子並行工作。
- 分段轉換又稱逐步轉換、嚮導轉換、試點過渡法等。這種轉換方式實際上是以上種轉換方式的結合。在新系統全部正式運行前，一部分 部分地代替 老系統。那些在換過程中還沒有正式運行的部分，可以在一個模擬環境中繼續試運行。這種方式既保了可靠性，又不至於費用太大。但是這種分段轉換要求子系統之間有一定的獨立性，又系統的設計和實現都有一定 的要求，否則就無法實現分段轉換的設想。
統一過程UP
統-過程(UP)的基本特徵是“用例驅動、以架構爲中心的和受控的迭代式增量開發”一個UP可分爲若千個週期，每個週期的開發過程被分爲4個階段，每個階段可進行若干次迭代。
UP將一個週期的開發過程劃分爲如下的4個階段。
(1)初始階段:該階段的主要任務包括確定項目範圍和邊界，識別系統的關鍵用例，展示系統的侯選架構，估計項目費用和時間，評估項目風險。其意圖是建立項目的範圍和版本，確定業務實現的可能性和項目目標的穩定性。提交結果包括原始的項目需求和業務用例。
(2)精化階段:該階段的主要任務包括分析系統問題領域，建立軟件架構基礎，淘汰最高風險元素。其意圖是對問題域進行分析，建立系統的需求和架構，確定技術實現的可行性和系統架構的穩定性。提交結果包括系統架構及其相關文檔、領域模型、修改後的業務用例和整個項目的開發計劃。
(3)構建階段:該階段相對簡單一一些， 其主要任務包括資源管理、控制和流程優化，開發剩餘的構件，然後進行構件組裝和測試等。其主要意圖是增量式地開發一個可以交付用戶的軟件產品。
(4)提交階段:該階段的主要任務包括進行β測試，製作發佈版本，用戶文檔定稿，確認新系統，獲取用戶反饋，培訓、調整產品使最終用戶可以使用產品。其主要意圖是將軟件產品提交用戶。
軟件開發過程管理
敏捷開發方法之XP
軟件項目管理
軟件項目管理的基礎知識點如下：
軟件項目計劃安排進度的方法
甘特圖也就做進度管理圖。他是一種簡單的水平條形圖，它以日曆爲基準描述項目任務，水平軸表示日曆時間線，每一個線條表示一個任務，任務名稱垂直的列在左邊列中，圖中的線條的起點和終點對應水平軸上的時間，分別表示任務的開始時間和結束時間，線條的水平長度表示該任務的持續時間。同一時間短內有多個線條，表示這些任務是併發進行的。
甘特圖特點：能清晰的描述每個任務從何時開始，到何時結束，以及任務之間的並行關係。但是他不能清晰的反應出各任務的依賴關係。
PERT圖是一個有向圖，圖中剪頭表示任務，它可以標上完成該任務的時間，途中的節點表示流入節點的任務的結束，並開始流出結點任務，這裏把結點稱爲事件。只有當流入該結點的所有任務都結束時，結點所表示的 事件纔出現。在PERT圖中，最早時刻表示在此時刻之前從該事件出發的任務不可能開始，最遲時刻表示從該事件出發的任務必須在此時刻之前開始。鬆弛時間，表示在不影響整個工期的前提下，完成任務有多少機動餘地。如圖：
PERT圖特點：不僅給出了每個任務的開始時間、結束時間和完成該任務所需的時間，還給出了任務之間的關係。
在PERT圖中，關鍵路徑是圖中最長的一條路徑。而鬆弛時間則反映了完成某些任務時可以推遲其開始時間或延長其所需完成的事件。但是PERT圖不能反應任務之間的並行關係。
備註：
- 1. 結點（事件）：圖中的圓，表示流入結點任務的結束，並開始流出節點的任務。只有當流入該結點所有任務均結束，結點事件纔出現，流出結點任務纔開始。
- 2. 關鍵路徑：圖中花費時間最長的事件和活動的序列。
- 3. 最早時刻：此刻之前從該事件出發的任務不可能開始。
- 4. 最遲時刻：從該事件出發的任務必須在此時刻之前開始，否則整個工程不能如期完成。
- 5. 鬆弛時間：表示不影響整個工期前提下完成該任務的機動餘地。
例如我們求如上PERT圖的的關鍵路勁和鬆弛時間
該題要求求出工程的最少時間，即關鍵路徑。
首先計算出各個路徑長度：
1ABEGJ:3+15+2+7=27
2.ACFGJ:6+4+3+7=20
3.ACFHJ:6+4+20+10=40
4.ADFGJ:10+8+3+7=28
5.ADFHJ:10+8+20+10=48
6.ADFIHJ:10+8+4+10=32
7.ADFIJ:10+8+4+12=34
綜上最長爲48，故最少時間爲48
求活動FG鬆弛時間
首先應弄清楚四個概念的計算：
①最早開始時間（某段工程開始點之前最長的輸入流之和），
②最晚開試（關鍵路徑-開始點到最後整個工程最後結束點的距離），
③最早結束（某段工程結束點之前最長的輸入流之和），
④最晚結束（關鍵路徑-該結束點到整個工程最後結束點的距離）
根據上述概念可求得
①10+8=18
②48-3-7=38
③10+8+3=21
④48-7=41
鬆弛時間=最晚開始-最早開始②-①=38-18=20
鬆弛時間=最晚結束-最早結束④-③=41-21=20
另一種較爲簡單的方法：用關鍵路徑-所求活動在的最長路徑即48-10-8-3-7=20求得鬆弛時間。
軟件工程文檔
軟件文檔也稱文件，通常指的是一些記錄的數據和數據媒體，它具有固定不變的形式，可被人和計算機閱讀。它和計算機程序共同構成了能完成特定功能的計算機軟件(有人把源程序也當作文檔的一部分)。 我們知道，硬件產品和產品資料在整個生產過程中都是有形可見的，軟件生產則有很大不同，文檔本身就是軟件產品。沒有文檔的軟件，不成其爲軟件，更談不到軟件產品。軟件文檔的編制在軟件開發工作中佔有突出的地位和相當的工作量。高效率、高質量地開發、分發、管理和維護文檔對於轉讓、變更、修正、擴充和使用文檔，對於充分發揮軟件產品的效益有着重要意義。
軟件文檔可以分開發文檔、管理文檔和用戶文檔三大類。
開發文檔
開發文檔包括《功能要求》、《投標方案》、 《需求分析)、《技術分析》、《系統分析》、《數據庫文檔》、《功能函數文檔》、《界面文檔》、 《編譯手冊》、(QA文檔》、(項目總結》等。
管理文檔
管理文檔包括(產品簡介》、《產品演示》、《疑問解答》、(功能介紹》、《技術白皮書》、《評測報告》等。
用戶文檔
用戶文檔包括《安裝手冊》:《使用手冊》、《維護手冊》、《用戶報告》、《銷售培調》等。
軟件開發風險分析
風險分析：
風險分析實際上是4個不同的活動：風險識別、風險預測、風險評估和風險控制。在對風險進行優先級排序時，需要根據風險概率和後果來進行排序。
風險識別
風險識別是試圖系統化地確定對項目計劃（估算、進度、資源分配）的威脅。
風險預測
風險預測又稱爲風險估算，它從兩個方面評估一個風險：風險發生的可能性或概率；以及如果風險發生時所產生的後果。
風險預測一共有四個預測活動
（1）建立一個尺度，以反映風險發生的可能性。
（2）描述風險的後果。
（3）估算風險對項目及產品的影響。
（4）標註風險預測的整體精確度，以免產生誤解。
風險評估
風險評估根據風險及其發生的概率和產生的影響預測是否影響 參考水平值。
風險控制
風險控制的目的是輔助項目組建立處理風險的策略，有效的策略應考慮風 險避免、風險監控、風險管理及意外事件計劃。而其中風險避免是最好的風險控制策略。
軟件維護
根據引起軟件維護的原因不同，軟件維護通常可分爲以下四種類型:
改正性維護:
在軟件交付使用後，必然會有一部分隱藏的錯誤被帶到運行階段來。這些隱藏下來的錯誤在某些特定的使用環境下就會暴露出來。爲了糾正這些錯誤而對軟件進行的維護工作就是改正性維護。該類維護一般佔總維護 工作量的25%。
適應性維護:
隨着計算機的飛速發展，外部環境(新的硬、軟件配置)或數據環境(數據庫、數據格式、數據輸入/輸出方式、數據存儲介質)或應用環境可能發生變化，爲了使軟件適應這種變化，而去修改軟件的過程就叫做適應性維護。該類維護-般佔總維護工作量的20%。
完善性維護:
在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求。爲了滿足這些要求，需要修改或再開發軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件的可維護性。這種情況下進行的維護活動叫做完善性維護。該類維護一般佔總維護工作量的50%。
eg:針對應用在運行期的數據特點，修改器排序算法使其更高效，屬於完善性維護。
預防性維護:
爲了提高軟件的可維護性、可靠性等而提出的一種維護類型， 它爲以後進步改進軟件打下良好基礎。通常，預防性維護定義爲:“把今天的方法學用於昨天的系統以滿足明天的需要”。也就是說，採用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分 (重新)進行設計、編制和測試。該類維護般佔總維護工作量的 50%
軟件危機
軟件危機是指在計算機軟件開發和維護過程中所遇到的一系列嚴重問題。軟件危機主要表現在：軟件需求的增長得不到滿足，軟件生產成本高、價格昂貴，軟件生產進度無法控制，軟件需求定義不夠明確，軟件質量不易保證，軟件可維護性差。歸納起來，產生軟件危機的內在原因歸結爲兩個重要方面：一方面是由於軟件生產成本存在着複雜性；另一個方面是與軟件開發所使用的方法和技術有關。