1．軟體工程：研究一個包含一系列方法和工具的架構，同時研究軟體產生，發展，應用，維護等過程中的理論，方法和工具
2. Software
l 指令的集合，通過執行這些指令可以滿足預期的特徵，功能和效能要求
l 資料結構，使得程式可以充分利用資訊
l 描述程式操作和使用的文檔
3. 遺留軟體
l 調整來滿足新的計算環境或技術的需要
l 改善來實現新的業務需求
l 擴充使得它能和其它更加現代的系統或資料庫進行互動
l 重新架構使得它在新的網路環境中可實施
過程綜述品質關注點（目的）–過程（約束，架構）—方法（指導，保證）–工具（手段）
溝通—策劃—建模（需求分析和設計）—構建（編碼和測試）—部署
l 作為一個連續的模型，每個過程域都根據特定的目標和實踐要求進行嚴格的評估
l 作為一個階段性模型，定義五個成熟度等級，達到等級需要達到相應的目標
提供一個模板，一種描述軟體過程中重要特徵的一致性方法。
過程模型溝通—策劃—建模—構建—部署
第一個增量往往是核心產品，滿足了基本需求
是瀑布模型的高速變體，側重於短暫開發週期的增量軟體過程模型
原型是為定義需求服務的
5. 演化過程模型—螺旋模型
原型迭代性質+瀑布模型的系統性和可控制性。採用迴圈方式逐步加深系統定義和實現深度同時降低風險，確定一系列裡程碑確保共利益者都支援解決方案
定義一系列事件，這些事件將觸發SE活動、動作或者任務的狀態轉換
7．專用過程模型
基於構件的開發—商品化成品軟體構件。形式化方法模型—產生電腦軟體形式化的數學規格說明。AOSD面向方面的軟體開發。
一種用例驅動，以架構為核心，迭代並且增量的軟體過程。起始—細化—構建—轉換—生產
敏捷開發l 讓客戶滿意和軟體儘早發布
l 小而高度自主的項目團隊
l 非正式的方法
l 最小化軟體工程產品以及整體精簡開發
l 有效響應變化
l 共同利益者之間有效溝通
l 把客戶拉入團隊
l 組織一個隊伍，使得該隊伍為目前執行的任務所用
l 由客戶描述的需求驅動
l 識別出計劃是短期的
l 迭代的開發軟體，重點強調構建行為
l 交付多個軟體增量
l 適應隨時發生的變化
4．極限編程
l XP策劃
l XP設計
l XP編程
l XP測試
l 思考—啟動軟體項目並完成自適應迴圈計劃
l 協作—協作，信任
l 學習—開始開發構件時，重點是完成迴圈的方向學習儘可能多的東西
l 可行性研究
l 業務研究
l 功能模型迭代
l 設計和構件迭代
l 實現
l 強調定義特徵（特徵是使用者可以方便描述的小塊的可發布的功能）
l 建立特徵列表並且執行特徵導向的計劃
l 設計和構建在FDD中是融合在一起的
系統工程1.Elements of a computer-based system
l Software
l Hardware
l People
l Database
l Documentation
l Procedures
2.系統架構
l 資料架構：為業務或業務功能的資訊需求提供了架構
l 應用架構：包含那些為某些業務目的而在資料架構範圍內進行轉換的系統要素
l 技術基礎設施：為資料架構和應用架構提供基礎
需求工程起始—匯出—精化—協商—規格說明—確認—需求管理
構建分析模型需求分析l 產生軟體操作特徵的規格說明
l 指明軟體和其他系統元素的介面
l 建立軟體必須滿足的約束
域分析識別，分析和詳細說明來自某個特定應用領域的公用需求，特別是那些在該應用領域內被多重專案重複使用的。
l 定義要分析的領域
l 收集該領域應用有代表性的樣本
l 分析樣本中的每個應用
l 為對象開發分析模型
資料建模l 獨立於過程地檢查資料對象
l 專註於資料領域
l 建立一個在客戶的抽象層次上的模型
l 指示出資料對象如何相互關聯
資料對象幾乎任何必須被軟體理解的複合資訊的表示。複合資訊是指具有若干不同特徵或屬性的事物
l 對象的每個執行個體必須能夠被唯一的識別
l 每個資料對象在系統中都是不可缺少的，即不訪問對象執行個體系統功能無法實現
l 每個資料對象都由資料項目形式的屬性來描述
關係l 必須被系統記住的一個事實，而且不能被計算，也不能被推導得出
l 可以存在一個關係的多個執行個體
l 對象可以以多種不同方式相關聯
CRC模型職責：類封裝的屬性和操作（類所知道的或能做的任何事）
協作：那些提供完成某個職責所需要的資訊的類（協作意味著資訊請求或者動作請求）
實體類：模型和業務類，從問題說明中直接提取出來的，這些類一般代表儲存在資料庫中的和貫穿應用程式的事物。
邊界類：用於建立使用者可見的和互動的介面，被設計成負責管理實體物件對使用者的不同方式
控制類：管理工作單元，包括管理實體類的建立和更新等。
系統狀態l State—一組刻畫在既定時間系統行為的可觀察的特徵
l State transition—從一個狀態到另一個狀態的轉移
l Event—導致系統資料表現出可預測行為形式的發生
l Action—作為一個狀態轉移的結果發生的過程
設計工程品質指導原則l 設計應展示出以下資料結構：（已經使用可識別的體繫結構或模式建立，由展示出良好設計特徵的構件構成，能夠以演化的方式實現）
l 設計應該模式化
l 設計應該包含資料、體繫結構，介面和構件的清楚表示
l 設計應匯出資料結構，這些資料結構適用於要實現的類
l 設計應匯出顯示獨立功能特徵的構件
l 設計應匯出介面，這些介面降低了構件之間以及構件與外部環境串連的複雜性
l 設計的匯出應根據軟體需求分析過程中擷取的資訊採用可重複使用的方法進行
基本概念l 抽象—過程抽象，資料抽象
l 體繫結構—軟體的整體結構
l 模式—一個經過驗證的解決方案的本質的表達
l 模組化— 資料和功能的劃分
l 隱藏—每個模組對其他所有模組都隱藏自己的設計決策
l 功能獨立—專一功能和低耦合
l 求精—逐步細化所有的抽象
l 重構—一種重新組織的技術，可以簡化構件的設計或代碼而無需改變其功能和行為
軟體結構l 結構模型—將體繫結構表示為程式構件的一個有組織的集合
l 架構模型—可以提高設計抽象層級
l 動態模型—強調程式體繫結構的行為方面，指明結構或系統配置作為外來事件的函數將如何變化
l 過程模型—注重系統必須提供的業務設計或技術流程設計
l 功能模型—可以用來表示系統的功能階層
訊息隱藏l 無意間引入錯誤並傳播到軟體其他部分的可能性很小
l 限制了局部設計決定對全域的影響
l 強調通過控制介面進行互動
l 不鼓勵使用全域資料
l 導致封裝—高品質的設計的一個屬性
l 為了設計出高品質的軟體
重構一種重新組織的技術，可以簡化構件的設計或代碼而無需改變其功能和行為。
重構時需要檢查以下方面：
l 冗餘性
l 未使用的設計項目
l 低效或者不必須的設計演算法
l 拙劣或者不恰當的資料結構
l 以及其他設計不足，修改這些不足以獲得更好的設計
設計模式元素l 資料設計項目（資料結構，資料庫結構描述）
l 體繫結構設計項目（應用域，分析類，模式和類型）
l 介面設計項目（使用者介面，和其他系統裝置的外部介面，各種設計構件之間的內部介面）
l 構件級設計項目
l 部署級設計項目
體繫結構設計體繫結構是一種表達，使得軟體工程師能夠
l 分析設計在滿足規定需求方面的有效性
l 在設計變更相對容易的階段，考慮體繫結構可能的選擇方案
l 降低與軟體構造相關聯的風險
體繫結構風格l 以資料為中心的體繫結構
l 資料流體繫結構
l 調用返回體繫結構
l 物件導向體繫結構
l 層次體繫結構
體繫結構模式l 並發性—很多應用系統必須以一種類比並行的方式來操作多個任務
l 持久性—如果資料從建立它的進程執行以來一直存在，則該資料是持久性存在的資料
l 分布性—系統或系統中構件在一個分布的環境中相互連信的方式（實體間串連方式，實體間通訊）
構件級設計構件：系統中某一定型化的、可配置的和可替換的組件，該組件封裝了實現，並暴露一系列的介面。
設計原則l 開關原則：模組應該是對外延具有開放性，對修改具有關閉性
l 替換原則：子類可以替換他們的基類
l 依賴倒置原則：依賴於抽象而非具體實現
l 介面分離原則：多個使用者專用介面比一個通用介面要好
l 發布複用等價性原則：複用的粒度就是發布的粒度
l 共同封裝原則：一同變更的類應該合在一起
l 共同複用原則：不能一起複用的類不能被分到一組
內聚性構件的專誠性，意味著構件或者類只封裝那些相互關係密切，以及與構件或類自身有密切關係的屬性和操作。
l 功能內聚
l 分層內聚
l 通訊內聚
l 順序內聚
l 過程內聚
l 暫時內聚
l 實用內聚
耦合類之間彼此聯絡程度的一種定性度量
l 內容耦合
l 共用耦合
l 控制耦合
l 印記耦合
l 資料耦合
l 常式調用耦合
l 類型使用耦合
l 包含或匯入耦合
l 外部耦合
軟體測試策略測試是交付終端使用者之前帶著特定尋找錯誤的意圖來演習程式的過程
策略：
l 單元測試：測試介面，局部資料結構，邊界條件，獨立路徑，錯誤處理路徑
l 整合測試：一步到位，增量整合
l 確認測試
l 系統測試
OOT策略類的測試等價於單元測試（測試類別內部的操作，檢查類的狀態行為）
三種不同的策略整合測試：
l 基於線程的測試—整合響應系統的一個輸入或事件所需的一組類
l 基於使用的測試—整合響應一個使用用例的所需的一組類
l 簇測試—整合顯示一個協作所需的一組類
煙霧測試 (Smoke Test)常用的整合方法，是時間關鍵性項目的步進機制，讓軟體團隊頻繁地對項目進行評估
l 將已經轉換成代碼的軟體構件整合為一個build
l 設計一系列測試以暴露影響build正確地完成其功能的錯誤
l 每天該build與其他builds及整個軟體產品整合起來進行煙霧測試 (Smoke Test)
調試策略：蠻力法，回溯法，原因排除法
測試戰術可測試性l 可操作性—啟動並執行越好，越能有效測試
l 可觀察性—你所看見的就是你所測試的
l 可控制性—對軟體控制的越好，測試越能被自動執行和再現
l 可分解性—通過控制測試的範圍，能夠更快地分解問題，完成更靈巧的再測試
l 簡單性—減少複雜的構架和邏輯來簡化測試
l 穩定性—變更越少，對測試的破壞越小
l 易理解性—對設計的理解
白盒測試計算環複雜性：簡單決策數+1 或者 封閉地區數+1. 環複雜性越高，出錯的可能性越大
專案管理管理因素l 人員—成功項目最重要因素
l 產品—要構造的軟體
l 過程—為了完成軟體構造的一組架構活動和軟體工程任務
l 項目—實現產品所需要的所有工作
MOI modell 激勵—通過推或拉鼓勵技術人員發揮最大才能的一種能力
l 組織—形成能夠將最初概念轉換成最終產品的現有過程的能力
l 思想和創新—即使必須在特定軟體產品或應用的約束下工作，也能鼓勵人們去創造並讓人感到有創造性的一種能力
組織範型l 封閉式範型—按照傳統的權利層次來組織團隊
l 隨機式範型—鬆散地組織團隊，團隊工作依賴於團隊成員個人的主動性
l 開放式範型—試圖以一種既具有封閉式範型的控制性，又包含隨機式範型的創新性方式來組織團隊
l 同步式範型—依賴於問題的自然劃分，組織團隊成員各自解決問題的一部分，他們之間沒什麼主動交流
過程和項目度量過程度量l 品質相關的—關注於工作產品和交付物的度量
l 生產率相關的—與花費的工作量有關的工作產品的生產
l 統計的軟體品質保證資料—錯誤分類與分析
l 缺陷使效率受損—過程中的錯誤從一個行為傳播到另一個行為
l 資料重用—生產的組件的數目和它們的重用程度
項目度量通過進行為了避免拖延和減輕潛在的問題與風險所必需的調整來減少開發花費的時間
l 輸入—工作完成需要的資源的度量
l 輸出—在軟體工程過程中創造的可交付物或工作產品的度量
l 結果—度量可以表明可交付物的效力
面向規模的度量l 每千行代碼的錯誤數
l 每千行代碼的缺陷數
l 每千行代碼的成本
l 每千行代碼的文檔頁數
l 每人月的錯誤數
l 每個檢查小時的錯誤數
l 每人月千程式碼
l 每頁文檔的成本
面向功能的度量l 每個功能點的錯誤數
l 每個功能點的缺陷數
l 每個功能點的成本
l 每個功能點的文檔頁數
l 每人月的功能點數
物件導向的度量l 情境指令碼的數量（用例）
l 關鍵類的數量，問題域的核心
l 支援類的數量（實現系統需要的但是與問題域並不直接相關）
l 每個關鍵類的平均支援類的數量（分析類）
l 子系統的數量，子系統是實現某個功能的類的集合
測量品質l 正確性—程式完成所要求的功能的程度
l 可維護性—遇到錯誤時程式能夠被修改的容易程度，環境發生變化時程式能夠適應的容易程度
l 完整性—測量一個系統對安全性攻擊的抵抗能力
l 可用性—程式容易使用的程度
缺陷排除率：DRE=E/(E+D) 接近1為好
E—軟體交付給終端使用者之前發現的錯誤數， D-軟體交付給終端使用者之後發現的缺陷數
軟體項目估算專案計劃的總目標就是為了控制，跟蹤和監視一個複雜的技術項目建立切實可行的戰略
估算技術l 過去類似的項目經驗
l 傳統估算技術（任務細目和工作量估算，規模估算）
l 經驗模型
l 自動工具
項目進度安排安排原則l 劃分—必須將項目劃分為多個可以管理的活動
l 相互依賴性—明確任務之間的依賴關係
l 時間分配—每個安排了進度計劃的任務必須分配一定數量的工作單位
l 工作量確認—每個項目都有預定的人員參與
l 確認責任—每個安排了進度計劃的任務應該指定特定的成員來負責
l 明確結果—每個安排了進度計劃的任務都應該有個明確的輸出結果
l 確定裡程碑—每個任務或工作群組都應該與一個項目裡程碑相關聯
風險管理風險識別l 產品規模—與要開發或者要修改的軟體的總體規模相關的風險
l 商業影響—與管理者或者市場所施加的約束相關的風險
l 客戶特性—與客戶素質以及開發人員和客戶定期溝通的能力相關的風險
l 流程定義—與軟體工程定義的程度以及該過程被開發組織遵守的程度相關的風險
l 開發環境—與用來開發產品的工具可獲得性及品質相關的風險
l 開發技術—與待開發軟體的複雜性及系統所包含技術的新奇性相關的風險
l 人員才幹及經驗—與軟體工程師的總體技術水平及項目經驗相關的風險
風險因素l 效能風險—產品能夠滿足需求且符合其使用目的的不確定程度
l 成本風險—能夠維持項目預算的不確定程度
l 支援風險—開發出的軟體易於錯誤修正、修改及升級的不確定程度
l 進度風險—那個維持項目進度且按時交付產品的不確定程度
品質管理軟體品質：遵循清楚陳述的功能和效能的要求，明確的記錄開發標準，所有專業開發的軟體預期的隱性的特徵
軟體可靠性：可靠性簡單測量，平均失效間隔時間。
軟體可用性：某個給定時間點上程式能夠按照需求執行的效率。
變更管理基準（baseline）
已經通過正式評審和獲批准的規格說明或產品，他可以作為進一步開發的基礎，並且只有通過正式的變更控制規程才能改變它
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
