——軟件工程
是一門研究應用工程化方法構建和維護有效的、實用的和高質量的軟件的學科。
工程包括了管理、過程和技術三個方面，過程指軟件的開發、維護過程及管理過程。涉及程序設計語言、數據庫、軟件開發工具、系統平臺、標準、設計模式等。
目標：
達到要求的軟件功能。
取得較好的軟件性能。
付出較低的開發成本。
開發的軟件易於移植。
開發的軟件易於維護，需要較低的維護費用。
能按時完成開發任務，並交付使用。
注意：
軟件設計時，充分考慮軟件的可修改性、可擴展性。
軟件開發文檔齊備。
加強團隊合作精神。
——軟件工程過程
是指軟件生命週期所涉及的一系列相關過程，是產生一個最終能滿足需求且達到工程目標的軟件產品所需要的步驟。
包括開發過程、運作過程和維護過程。覆蓋了分析、設計、編碼、測試及支持。
分析包括問題分析和需求分析，需求分析生成功能規約。
設計包括概要設計和詳細設計。
概要設計建立整個軟件系統結構，包括子系統、模塊及相關層次的說明、每一模塊的接口定義。詳細設計產生程序員可用的模塊或類說明。
基本原則：
選取適宜的軟件開發模型
採用合適的軟件開發方法
提供高效的開發支撐環境
重視軟件開發過程的管理
建設高素質的軟件開發團隊
軟件生命週期：制定計劃、需求分析和定義、設計、編碼、測試、運行和維護。
通常要考慮軟件的模塊化、抽象與信息隱藏、可移植性、局部化、可適用性。
——UML統一建模語言
它使開發人員專注於建立系統的模型和結構，而不是選用具體的程序設計語言和算法來實現，當模型建立以後，模型可被UML工具轉化爲指定的程序設計語言代碼和數據庫結構。
用例圖：用於業務建模、需求捕獲，作爲測試的依據
類圖：描述類以及類之間的相互關係
對象圖：描述對象以及對象之間的關係
構件圖：描述構件及其相互依賴關係
部署圖：描述構件在各個節點上的部署情況
順序圖：強調時間順序的交互圖
協作圖：強調對象協作的交互圖
狀態圖：描述類所經歷的各種狀態以及狀態之間的轉換關係
活動圖：用於對工作流程建模
——Rational Rose
提供了一個集成環境，用來創建、查看和修改UML模型、視圖、圖和模型元素。
客戶服務系統：面對的是客戶，強調的是服務，注重的是管理。
性能指標：
滿足多人同時使用系統
保存半年曆史數據供查詢
10s內完成數據交互性操作
頁面訪問平均響應時間<=3s，峯值<=10s，並具備擴展功能
支持傳統的網絡傳輸協議
能夠抵禦常見的Hacker攻擊手段
本系統爲平臺化的應用系統，支持各種標準化數據接口
提供全部的數據庫表結構、數據字典和二次開發詳細參考文檔
——項目管理
利用系統的管理方法將職能人員（垂直體系）安排到特定的項目中（水平體系）
項目管理是面向成果的
項目管理是基於團隊的
項目管理藉助外部的資源提供跨職能部門的解決方案
項目管理是可變化的
項目劃分四個階段：
識別需求、提出解決方案、執行項目、結束項目
項目的質量因素：時間、費用、範圍
項目管理主要任務：項目計劃、項目組織、質量管理、費用控制、進度控制
知識領域：範圍管理、時間管理、費用管理、質量管理、人力資源管理、溝通管理、風險管理、採購管理、集成管理
工期 = 工時 / 資源投入
成本 = 固定成本 + 資源成本
資源成本 = 工時資源成本 + 資料資源成本
——WBS任務分解結構
使項目各參與方從整體上了解項目的各項工作便於進行整體的協調管理或從整體上了解自己承擔的工作與全局的關係。
關鍵路徑：指一系列必須按時完成的任務
項目監控管理：
跟蹤項目的實際運行狀態，包括設置比較基準，更新進度，查看項目進度
——軟件開發生命週期
制定計劃：分析人員、領域專家及用戶
需求分析和定義：分析人員、測試人員、領域專家及用戶
軟件設計：架構設計人員、軟件設計人員、數據庫設計員、用戶界面設計員、封裝體設計員、集成人員、測試人員
編碼：編程人員、測試人員
軟件測試：測試人員、開發人員、用戶
運行維護：系統支持人員
——軟件測試
首先單元測試：查找各模塊或類在功能和結構上存在的問題並加以修改，這個過程會反覆進行。
其次集成測試：驗證軟件單元集成後形成的模塊能否達到概要設計規格說明中各模塊的設計目標。
然後系統測試：對系統全面測試，確保滿足產品需求並遵循系統設計。
最後確認測試：檢查已實現的軟件是否滿足了需求規格說明書中確定的各種需求，包括功能需求和性能需求。
——瀑布模型
制定開發計劃、需求分析和定義、軟件設計、程序編寫、軟件測試、運行維護
自上而下，相互銜接。
核心思想是按工序將問題簡化，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。
優點：
爲軟件項目提供了按階段劃分的檢查點，強調開發的階段性
強調早期計劃及需求調查
強調產品測試和階段評審
強調文檔的重要性
缺點：
缺乏靈活性，無法理清本來不夠明確的需求，導致開發完成時才發現並非用戶所需。
一般適用於功能、性能明確、完整、無重大變化的軟件系統。
——演化模型
主要針對事先不能完整定義需求的軟件開發。
第一次迭代（需求->設計->編碼->測試->集成）—>反饋—>第二次迭代（...）—>反饋—>...
可以看作是重複執行的多個瀑布模型。
優點：
用戶在開發過程中可以看到，對發現的問題能夠提早解決
若在某次迭代中沒有滿足用戶需求，開發人員可以根據用戶反饋在下一次迭代中進行修正
將系統中難度較大、風險較高的部分安排在早期的迭代中，可增加項目的成功率
缺點：
由於項目需求在開發初期不明確，會給設計帶來困難，影響系統的完整性
若開發過程中缺乏嚴格的過程管理，可能會退化爲邊寫邊改模式
若沒有一定的約束條件，可能永遠無法得到一個最終的軟件產品
——螺旋模型
制定計劃、風險分析、實施工程、用戶評估
以風險分析爲驅動，一旦風險過大就要停止開發。
適用於產品研發和機構內部大型的複雜系統，不適用於合同項目。
優點：
設計上靈活，在項目的各個階段都可變更
以小的分段構件大的系統，使資源、成本、進度的估計變得容易
用戶參與到每個階段中，保證了項目的正確性與可控性
缺點：
需要具有豐富的風險評估經驗和專門知識
過多的迭代次數會增加軟件開發成本，延遲交付使用的時間
——增量模型
分批的逐步向用戶提交可操作的產品，客戶對每一個增量的使用和評估都作爲下一個增量發佈的新特徵和功能。
優點：
人員分配靈活
重要功能被首先交付使用，可以獲得最多的測試
早期發佈的可操作產品可以作爲原型爲後期增量開發提供需求
可以將技術難度較大的部分作爲早期的增量，能夠有效的管理與控制技術風險
缺點：
若不能控制並管理好需求的變更，容易退化爲邊寫邊改模式
加入的增量部分不能破壞已構造好的系統部分，這需要軟件具備開放式的體系結構
難以對所有增量進行有效的集成
——面向對象
方法特性：對象唯一性、封裝型、繼承性、多態性
封裝：隱藏某一方法的具體執行步驟，保護或防止數據或程序代碼被無意破壞，通過對象提供的公共消息接口來訪問對象。
封裝應具有的條件：
具有一個清晰的邊界，對象所有的私有數據、成員方法或函數的實現細節都被固定在這個邊界內。
具有一個接口，它描述了對象之間的交互作用，它就是消息。
對象內部的實現代碼受到封裝體的保護，其他對象不能直接修改本對象所擁有的數據和代碼。
——繼承
子類繼承父類時，既可以重新定義子類的某些屬性和方法，也可以重寫某些方法，來覆蓋父類原有的屬性和方法，使其獲得與父類不同的功能。
作用：避免代碼冗餘，提高可理解性和可維護性
代碼重用機制，使系統具有靈活性和適應性，使多態性成爲可能。
父類的成員若定義爲受保護或公有訪問域，子類是可以訪問的，若是私有則不可以。
重載：一個類中的操作具有不同的參數和相同的名稱。
簽名：操作名、參數及其類型和操作的返回類型合在一起。一個類中的所有操作都必須具有唯一的簽名。
——面向對象的軟件生命週期
是一個迭代的增量式過程。
系統分析階段：得出對象模型、動態模型、功能模型
系統設計階段：劃分子系統，確定整體框架結構
對象設計階段：將分析模型的邏輯結構映射到一個程序的物理組織，得到設計模型
實現階段：將類轉化爲代碼或數據庫
測試階段：面向對象的分析測試、設計測試、編程測試、單元測試、集成測試、系統測試
——RUP（統一軟件開發過程）：
利用其開發的軟件系統是由構件組成的，構件之間通過良好的接口相互聯繫。
它是用例驅動的過程：根據需求分析的用例來構建需要的系統行爲。用例定義了系統功能的使用環境和上下文，每個用例描述的是一個完整的系統服務。
它是迭代和增量式的過程：每次迭代都產生一個可執行的版本。每次迭代時，都選用一組還沒有實現的用例來作爲增量進行開發，優先識別並着手實現風險較大的用例。
它是以基本架構爲中心的過程：在開發之前首先根據平臺而不考慮用例來設計系統架構，然後選用其中幾個成熟的用例來修改或擴展先前的架構，用系統架構來概念化、建立管理和開發之中的系統。
RUP是一種軟件開發過程，包括開發過程、管理過程和支撐過程。
四個階段：每個階段以一個主要里程碑結束。
先啓階段：任務是爲系統建立業務模型並確定項目的軟件範圍和邊界條件，識別出系統的關鍵用例，確定至少一個體繫結構方案，評估整個的整體成本和進度安排、評估潛在風險，準備項目的支持環境。主要關注整個項目的業務和需求方面的主要風險。