風險分析
分四個不同活動：風險識別（檢視系統化地確定對專案計劃的威脅。其中一個方法是建立風險條目檢查表）、風險預測（風險發生的可能性或概率；以及如果風險發生了所產生的後果）、風險評估（風險評估時，建立如下形式的三元組（ri，Li，Xi）、和風險控制（風險管理者採取各種措施和方法減少風險事件發生的各種可能性，或減少風險事件發生造成的損失。四種基本方法：風險迴避，損失控制，風險轉移和風險保留）
• 人員管理
• 極限程式設計（XP）
• 是一個輕量級、靈巧的軟體開發方法；同時它也是一個非常嚴謹和周密的方法。XP提倡在開始寫程式之前先寫單元測試（不懂後面會講） 。開發人員應該經常把開發好的模組整合到一起並重新執行單元測試；發現BUG就要增加相應的測試。
• XP中程式設計師一般結對（兩個程式與並排一起在同一臺機器上構建）進行程式設計開發。任何結對的程式設計師都可以在任何時候改進程式碼，它的基礎和價值觀是交流（加強交流）、樸素（從簡單做起）、反饋（尋求反饋）和勇氣（用於實事求是）。
• XP是一種近螺旋式的開發方法，它將複雜的開發過程分解為一個個相對比較簡單的小週期；通過積極的交流、反饋以及其他一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際情況及時的調整開發過程
• XP重要思想：重視客戶的反饋——開發的目的就是為了滿足客戶的需要。
• 常見生命週期模型:
• 從提出軟體開發計劃開始直到軟體在實際應用中完全報廢為止就是一個完整的軟體生存週期（SDLC，軟體生命週期），軟體生存週期的提出是為了更好的開發、管理和維護軟體。
• 軟體生命週期六個階段：問題的定義及規劃（此階段是軟體開發方與需求方共同討論，即待開發軟體系統的總體開發目標及其可行性。另外對資源分配，進度安排等做合理規劃）、需求分析（確定使用者對待開發系統的功能、經費需求、效能和使用者介面、安全保密、可靠、進度需求等方面的需求）、軟體設計（核心階段，根據需求分析的結果對整個軟體系統進行設計，分為總體設計和詳細設計）、程式編碼（將軟體設計的結果轉換成採用某種程式設計編寫的原始碼並生成語言計算機可執行的程式程式碼，這是軟體設計師和程式設計師都需要共同參與的）、軟體測試（軟體設計完成後進過嚴密的測試以發現軟體在整個設計過程中出現的問題並加以糾正，分單元測試，組裝測試以及系統測試）、執行維護（是軟體生命週期中持續時間最長的階段）
• 軟體工具：軟體開發工具，軟體維護工具，軟體管理和軟體支援工具
• CASE：是一組工具和方法的集合，可以鋪助軟體開發生命週期各階段進行軟體開發，在軟體開發、維護過程中提供計算機鋪助支援，並在軟體開發、維護中引入工程化方法。CASE技術有兩類，一是支援軟體開發過程本身的技術，二是支援軟體開發過程管理的技術
• UML圖
• 統一建模語言（UML）是用來對軟體密集系統進行視覺化建模的一種語言。
• UML的重要內容由下列五類圖定義
用例圖：從使用者角度描述並指出系統功能的操作者
靜態圖：包括類圖，物件圖，包圖
行為圖：包括互動圖和行為圖和組成物件間的互動關係,互動圖又分為時序圖和協作圖，行為圖又分為狀態圖（物件的可能狀態）和活動圖（描述用例和物件按時間順序的各個活動的流程）
互動圖：描述物件間的互動關係
實現圖。
• UML的用例之間的關係：兩種特殊的關係：擴充套件（擴充套件用例到基本用例的關係，它指定了擴充套件用例定義的行為如何擦入到為基本用例定義的行為中）和包含（從基本用例到包含用例的關係，它指定如何將為包含用例定義的行為明確地插入到為基本用例定義的行為中）。
• 類之中的關係：UML中規定，類中共有4種基本關係：依賴（即其中一個事物（獨立事物）發生變化會影響另一個事物（依賴事物））、關聯（是一種結構關係，它描述了一組鏈，鏈是物件之間的連線。）泛化（是一種特殊/一般關係，特殊元素（子元素）的物件可替代一般元素（父元素）的物件，用這種方法，子元素共享了父元素的結構和行為）、實現（是類元之間的語義關係，其中一個類元指定了由另一個類元保證執行的契約）
• 系統分析與設計
• 結構化分析方法：是面向資料流的需求分析方法，強調開發方法的結構合理性以及待開發軟體系統的結構合理性的系統分析方法。結構化開發方法提出了一組提高軟體結構合理性的準則，如分解與抽象、模組獨立性和資訊隱蔽等。結構化分析方法一般利用圖形表達使用者需求，使用的手段主要有資料流圖（DFD，。採用圖形方式表達系統的邏輯功能）、資料字典（使用者可以訪問的記錄資料庫或應用程式元資料的以類似字典的目錄：註釋形式描述的元資料集合）、結構化語言、判定表以及判定樹等。
• 面向物件分析模型五個層次：主題層，物件類層、結構層、屬性層和服務層
• 結構化分析的步驟：（1）分析當前的情況，做出反映當前物理模型的DFD、（2）推匯出等價的邏輯模型的DFD或等價的盒圖，判定樹等、（3）根據邏輯模型設計新的邏輯系統，生成資料字典和基元描述、（4）提出各種可能的方案並確定各種方案的成本和風險、（5）選擇一種方案、（6)建立完整的需求規約
• 結構化設計方法：是一種面向資料流的設計方法，可以與SA銜接、SA採用基於模組，自頂向下，結構化程式設計等程式設計技術將軟體設計成由相對獨立且具有單一功能的模組組成的結構。
• 面向物件分析與設計方法
• 面向物件分析方法：就是抽取和整理使用者需求並建立問題域精確模型的過程。系統分析員應該深入理解使用者需求，抽象出目標系統的本質屬性，並用模型準確的表示出來。面向物件建模得到的模型包含物件的三個要素：靜態結構、互動次序（又稱動態模型）和資料交換（又稱功能模型）。面向物件分析過程中建立物件模型的5項主要活動：找出類和物件；識別結構；識別主題；定義屬性；定義服務。
• 面向物件設計方法：是設計分析模型和實現相應原始碼，在目的碼環境中這種原始碼可以實行。主要步驟：設計問題定義、設計人機介面、設計任務管理、設計資料管理。
• 面向物件設計原則：封裝（將一個完整的概念組成一個獨立的單元，然後通過一個名字來引用它）、資訊隱蔽（通過物件的封裝實現的。類的結構分離了介面和實現，所以對於類的使用者來說，屬性的表示和操作的實現都是隱蔽的）、高內聚，低耦合（一個服務完成且僅完成一個功能）
• 耦合關係
內容耦合： 一個模組直接訪問另一個模組內的內部資料，或一個模組不能通過正常入口轉到另一個模組內容，或兩個模組有一部分程式程式碼重疊，則兩個模組就發生了內容耦合

公共耦合 ：一組模組都訪問同一個公共資料環境
外部耦合： 一組模組都訪問同一全域性簡單變數而不是同一全域性資料結構
控制耦合 ：一個模組把控制資訊傳遞給另一個模組，對其功能進行控制
標記耦合： 一組模組通過引數表傳遞記錄資訊，這組模組就是標記模組，注意：事實上模組共享了某一資料結構的子結構，而不是簡單變數
資料耦合 ：一個模組訪問另一個模組彼此之間通過資料引數（不是控制引數，公共資料結構或外部變數）來交換輸入，輸出資訊
非直接耦：兩個模組之間沒有直接關係，它們間的聯絡完全通過主模組的控制和呼叫來實現的|

軟體質量管理與質量保證
• IOS/IEC 9126軟體質量模型的6個質量特性：功能性、可靠性、易用性、效率、可維護性、可移植性。這六種質量特性都由質量特性（第一層6個），子特性（第二次21個）和度量（第三次由度量者定義的可定量化度量指標）三個層次組成
• McCall軟體質量模型
產品執行 正確性（滿足設計規格和語氣目標的程度）、可靠性（在規定時間和條件下不出故障）、效率、完整性、可使用性
產品修正 可維護性、可測試性、靈活性
產品轉移 可移植性、可複用性、互用性
• 模組化設計
• 模組化是解決負責軟體系統的最好方法。模組化的指導原則中最著名的是“高聚合，低耦合”，其中耦合包括：元素B是元素A的屬性，或者元素A引用了元素B的例項；元素A呼叫了元素B的方法；元素A直接或間接成為元素B的子類；元素A是介面B的實現。高聚合：內聚即功能內聚，如果模組內各功能具有高度相關的職責，缺一不可，除了這些職責內的任務外，沒有其他過多的工作，那麼該元素就具有高內聚性，反之則為低內聚性
• 模組設計原則：提高模組獨立性、模組規模應該適中、適當選擇深度，寬度，扇出和扇入、係數、分解-協調原則、模組的作用域應該在控制域之內、降低模組介面的複雜程度、模組功能應可以預測、模組規模要適當。
• 測試的分類
• 黑盒測試：是一種功能測試，就是將被測系統看成一個黑盒，單純從外界取得輸入後進行輸出。整個黑盒測試都只基於需求文件，不能使用與被測系統內部結構有關的任何資訊，看是否能滿足需求文件中的所有要求
• 白盒測試：邏輯測試，也叫做結構測試，它把程式看成白盒，即測試時瞭解被測物件的內部邏輯結構，並且以程式內部的設計結構及具體的程式碼實現為基礎來設計測試用例
• 軟體測試分四步：單元測試（基於程式模組進行正確性驗證的測試，採用白盒測試法）、整合測試（在單元測試基礎上，將所有模組按照設計要求組裝成子系統或系統，進行整合測試）、系統測試（在實際執行環境下對計算機系統進行一系列的組裝測試和確認測試）、確認測試。
• 專案成本估算
• 它的開發成本是一次性開發過程所花費的代價來計算的，所以軟體開發成本的估算從軟體計劃、需求分析、設計、編碼、單元測試、整合測試到認證測試，以整個開發過程所花費的代價作為依據，因此很難再專案完成前準確地估算出開發所需工作量和費用、通常以根據過開發類似軟體經驗來進行成本估算，也可以將軟體專案劃分成若干個子系統或按照軟體生存週期各個階段分別估算其成本，然後彙總出整個軟體的成本。
• 進度管理
• 考試涉及的進度管理工具包括Gantt圖和PERT圖兩種影象化管理方法
• 甘特圖（Gantt）：也稱條狀圖，在1917年甘特開發的，基本是線條圖，橫軸表示時間，縱軸表示活動（專案）。具有簡單，醒目和便於編制等特點。甘特圖能形象地描繪每個子任務（作業）的開始時間和結束時間，因此是進度計劃和進度管理的有力工具。另外甘特圖有三個主要缺點：不能顯示的描述各項作業彼此間的依賴關係；進度計劃的關鍵部分不明確導致難以判定哪些部分應當是主攻和主控的物件；計劃中有潛力的部分及潛力的大小不明確從而造成潛力的浪費。也因為這些缺點，尤其是第一個，從而採用了PERT圖描述。
• PERT圖：20世紀50年代，它將任務以精心計劃的，關鍵路徑網路的圖形化形式表示出來。即PERT圖是專案執行的視覺化計劃圖，
• CMM和軟體過程改進
• 統一過程：是軟體工程的過程。他提供了在開發組織中分派任務和責任的紀律化方法。它的目標是在可預見的日程和預算前提下，確保滿足終端使用者需求的高質量產品。統一過程模型是一種“用例驅動，以體系結構為核心，迭代及增量”的軟體過程框架，由UML方法和工具支援
• 極限程式設計：見上面
• CMM：軟體能力成熟度模型（Capability Maturity Model for Software，SW-CMM，CMM）是對於軟體組織在定義、實施、度量、控制和改善其軟體過程的實踐中各個發展階段的描述。CMM分5個等級：初始級、可重複級（有些基本的軟體專案的管理行為、設計和管理技術是基於相似產品中的經驗）、已定義級（軟體過程的管理方面和技術方面都明確地做了定義，並按需要不斷地改進過程，而且採用評審的辦法來保證軟體的質量）、已管理級（管理部門能區分出隨機偏離和有深刻含義的質量或生產目標的偏離）和優化級（連續的改進軟體過程）。
• 系統開發模型
• 瀑布模型：是一個特別經典，甚至有點老套的週期模型，一般情況下將其分為計劃、需求分析、概要設計、詳細設計、編碼以及單元測試、測試、執行維護等幾個階段。瀑布模型的週期是環環相扣的。每個週期中互動點都是一個里程碑，上一個週期的結束需要輸出本次活動的工作結果，本次的活動的工作結果將會作為下一個週期的輸入。這樣，當某一個階段出現了不可控的問題的時候，就會導致返工，返回到上一個階段，甚至會延遲下一個階段。
• 原型化模型：是動態確定軟體需求的方法之一，適應於需求不確定性高的系統，彌補了瀑布模型的缺點
• 螺旋模型：尤其重視風險分析階段，特別適用於龐大並且複雜，非常高風險的專案。通常螺旋模型由四個階段組成：制定計劃、風險分析、實施工程和客戶評估。螺旋模型中，釋出的第一個模型甚至可能是沒有任何產出的，可能僅僅是紙上談兵的一個目標，但是隨著一次次的交付，每一個版本都會朝著固定的目標邁進，最終得到一個更加完善的版本。

演化模型：也是一種原型化開發，但與快速原型不同的是，快速原型模型在獲得真實需求時，就將拋棄原型。而演化模型則不然，它將從初始的模型中逐漸演化為最終軟體產品，是一種“漸進式”原型法。其應用場合也是需求不明確的專案。
• 噴泉模型：是一種以使用者需求為動力，以物件為驅動的模型，主要用於描述面向物件的軟體開發過程。