需求分析

• 軟件需求是指用戶對新系統(tǒng)在功能渣触、行為、性能蟋字、設計約束等方面的期望。
• 根據(jù)IEEE的軟件工程標準詞匯表扭勉，軟件需求是指用戶解決問題或達到目標所需的條件或能力鹊奖，是系統(tǒng)或系統(tǒng)部件要滿足合同、標準涂炎、規(guī)范或其他正式規(guī)定文檔所需具有的條件或能力忠聚，以及反映這些條件或能力的文檔說明设哗。

需求的層次

1. 業(yè)務需求。是指反映企業(yè)或客戶對系統(tǒng)高層次的目標要求两蟀，通常來自項目投資人网梢、購買產(chǎn)品的客戶、客戶單位的管理人員赂毯、市場營銷部門或產(chǎn)品策劃部門等战虏。
2. 用戶需求。描述的是用戶的具體目標党涕，或用戶要求系統(tǒng)必須能完成的任務烦感。
3. 系統(tǒng)需求。是從系統(tǒng)的角度來說明軟件的需求膛堤，包括功能需求手趣、非功能需求和設計約束等。

質(zhì)量功能部署（Quality Function Deployment, QFD）

質(zhì)量功能部署（Quality Function Deployment, QFD）是一種將用戶要求轉(zhuǎn)化成軟件需求的技術肥荔。其目的是最大限度地提升軟件工程過程中用戶的滿意度绿渣。為了達到這個目標，QFD將軟件需求分為三類燕耿，分別是常規(guī)需求中符、期望需求和意外需求。

• 常規(guī)需求缸棵。用戶認為系統(tǒng)應該做到的功能或性能舟茶，實現(xiàn)越多用戶會越滿意。
• 期望需求堵第。用戶想當然認為系統(tǒng)應具備的功能或性能吧凉，但并不能正確描述白己想要得到的這些功能或性能需求。 如果期望需求沒有得到實現(xiàn)踏志， 會讓用戶感到不滿意阀捅，
• 意外需求。意外需求也稱為興奮需求针余，是用戶要求范圍外的功能或性能（但通常是軟件開發(fā)人員很樂意賦予系統(tǒng)的技術特性）饲鄙，實現(xiàn)這些需求用戶會更高興，但不實現(xiàn)也不影響其購買的決策圆雁。

需求獲取

常見的需求獲取方法包括用戶訪談忍级、問卷調(diào)查、采樣伪朽、情節(jié)串聯(lián)板轴咱、聯(lián)合需求計劃等。

需求分析

一個好的需求應該具有無二義性、完整性朴肺、一致性窖剑、可測試性、確定性戈稿、可跟蹤性西土、正確性、必要性等特性鞍盗，因此需了，需要分析人員把雜亂無章的用戶要求和期望轉(zhuǎn)化為用戶需求，這就是需求分析的工作橡疼。
在實際工作中援所，一般使用實體聯(lián)系圖（E-R圖）表示數(shù)據(jù)模型，用數(shù)據(jù)流圖（DFD）表示功能模型欣除，用狀態(tài)轉(zhuǎn)換圖（STD）表示行為模型住拭。

軟件需求規(guī)格說明書

• 軟件需求規(guī)格說明書（Software Requirement Specification, SRS）是需求開發(fā)活動的產(chǎn)物，編制該文檔的目的是使項目干系人與開發(fā)團隊對系統(tǒng)的初始規(guī)定有一個共同的理解历帚，使之成為整個開發(fā)工作的基礎滔岳。SRS是軟件開發(fā)過程中最重要的文檔之一，對于任何規(guī)模和性質(zhì)的軟件項目都不應該缺少挽牢。
  在國家標準GB/T 8567-2006中谱煤，規(guī)定SRS應該包括以下內(nèi)容：
  1. 范圍。
  2. 引用文件禽拔。
  3. 需求刘离。
  4. 合格性規(guī)定。
  5. 需求可追蹤性睹栖。
  6. 尚未解決的問題硫惕。
  7. 注解。
  8. 附錄野来。

需求驗證

需求驗證也稱為需求確認恼除，其活動是為了確定以下幾個方面的內(nèi)容：

1. SRS正確地描述了預期的、滿足項目干系人需求的系統(tǒng)行為和特征曼氛。
2. SRS中的軟件需求是從系統(tǒng)需求豁辉、業(yè)務規(guī)格和其他來源中正確推導而來的。
3. 需求是完整的和高質(zhì)量的舀患。
4. 需求的表示在所有地方都是一致的徽级。
5. 需求為繼續(xù)進行系統(tǒng)設計、實現(xiàn)和測試提供了足夠的基礎聊浅。

• 一般通過需求評審和需求測試工作來對需求進行驗證餐抢。

• UML
  是一種定義良好堵幽、易于表達、功能強大且普遍適用的建模語言弹澎。

• UML的結(jié)構包括

  • 構造塊，UML 有三種基本的構造塊努咐，分別是事物（thing）苦蒿、關系（relationship）和圖（diagram）。
  • 規(guī)則渗稍，規(guī)則是構造塊如何放在一起的規(guī)定
  • 公共機制

• UML中的事物

  1. 結(jié)構事物：結(jié)構事物在模型中屬于最靜態(tài)的部分佩迟，代表概念上或物理上的元素。
  2. 行為事物：行為事物是UML模型中的動態(tài)部分竿屹，代表時間和空間上的動作报强。
  3. 分組事物：分組事物是UML模型中組織的部分
  4. 注釋事物：注釋事物是UML模型的解釋部分。

• UML中的關系

  1. 依賴（dependency）：依賴是兩個事物之間的語義關系拱燃，其中一個事物發(fā)生變化會影響另一個事物的語義秉溉。
  2. 關聯(lián)（association）: 關聯(lián)描述一組對象之間連接的結(jié)構關系。
  3. 泛化（generalization）: 泛化是一般化和特殊化的關系碗誉，描述特殊元素的對象可替換一般元素的對象召嘶。
  4. 實現(xiàn)（realization）: 實現(xiàn)是類之間的語義關系，其中的一個類指定了由另一個類保證執(zhí)行的契約哮缺。

• UML視圖

  1. 邏輯視圖：邏輯視圖也稱為設計視圖弄跌，它表示了設計模型中在架構方面具有重要意義的部分，即類尝苇、子系統(tǒng)铛只、包和用例實現(xiàn)的子集。
  2. 進程視圖：進程視圖是可執(zhí)行線程和進程作為活動類的建模糠溜，它是邏輯視圖的一次執(zhí)行實例淳玩，描述了并發(fā)與同步結(jié)構。
  3. 實現(xiàn)視圖：實現(xiàn)視圖對組成基于系統(tǒng)的物理代碼的文件和構件進行建模诵冒。
  4. 部署視圖：部署視圖把構件部署到一組物理節(jié)點上凯肋，表示軟件到硬件的映射和分布結(jié)構。
  5. 用例視圖：用例視圖是最基本的需求分析模型汽馋。

面向?qū)ο蠓治?/h2>

image.png

ü 關聯(lián)關系侮东。關聯(lián)提供了不同類的對象之間的結(jié)構關系，它在一段時間內(nèi)將多個類的實例連接在一起豹芯。關聯(lián)體現(xiàn)的是對象實例之間的關系悄雅。

image.png

依賴關系。兩個類A和B, 如果B的變化可能會引起A的變化铁蹈，則稱類A依賴于類B宽闲。

image.png

泛化關系。泛化關系描述了一般事物與該事物中的特殊種類之間的關系，也就是父類與子類之間的關系容诬。繼承關系是泛化關系的反關系娩梨，也就是說，子類繼承了父類览徒，而父類則是子類的泛化狈定。

image.png

共享聚集。共享聚集關系通常簡稱為聚合關系习蓬，它表示類之間的整體與部分的關系纽什，其含義是“部分”可能同時屬于多個“整體"，"部分”與“整體”的生命周期可以不相同躲叼。

image.png

組合聚集芦缰。組合聚集關系通常簡稱為組合關系，它也是表示類之間的整體與部分的關系枫慷。與聚合關系的區(qū)別在于让蕾，組合關系中的”部分”只能屬于一個“整體", "部分”與“整體”的生命周期相同，“部分”隨著“整體”的創(chuàng)建而創(chuàng)建或听，也隨著“整體”的消亡而消亡涕俗。

image.png

實現(xiàn)關系。實現(xiàn)關系將說明和實現(xiàn)聯(lián)系起來神帅。接口是對行為而非實現(xiàn)的說明再姑，而類中則包含了實現(xiàn)的結(jié)構。一個或多個類可以實現(xiàn)一個接口找御，而每個類分別實現(xiàn)接口中的操作元镀。

軟件架構設計

• 軟件架構為軟件系統(tǒng)提供了一個結(jié)構、行為和屬性的高級抽象

• 包括：

  • 構件的描述
  • 構件的相互作用（連接件）
  • 指導構件集成的模式以及這些模式的約束

• 軟件架構風格

• 軟件架構設計的一個核心問題是能否達到架構級的軟件復用霎桅，也就是說栖疑，能否在不同的系統(tǒng)中，使用同一個軟件架構滔驶。

• 將軟件架構分為

  • 數(shù)據(jù)流風格
  • 調(diào)用/返回風格
  • 獨立構件風格
  • 虛擬機風格
  • 倉庫風格遇革。

• 軟件架構評估
  從目前已有的軟件架構評估技術來看， 可以歸納為三類主要的評估方式揭糕，分別是基于調(diào)查問卷（或檢查表）的方式萝快、基于場景的方式和基于度量的方式。這三種評估方式中著角，基于場景的評估方式最為常用揪漩。

軟件設計

• 軟件設計是需求分析的延伸與拓展。需求分析階段解決“做什么”的問題吏口，而軟件設計階段解決“怎么做”的問題奄容。
• 結(jié)構化設計（SD）
  SD方法的基本思想是將軟件設計成由相對獨立且具有單一功能的模塊組成的結(jié)構冰更，分為概要設計和詳細設計兩個階段。
  • 在概要設計中昂勒，將系統(tǒng)開發(fā)的總?cè)蝿辗纸獬稍S多個基本的蜀细、具體的任務
  • 為每個具體任務選擇適當?shù)募夹g手段和處理方法的過程稱為詳細設計
• 面向?qū)ο笤O計（OOD）
  OOD是OOA方法的延續(xù)，其基本思想包括抽象戈盈、封裝和可擴展性审葬，其中可擴展性主要通過繼承和多態(tài)來實現(xiàn)。
• 設計模式
  • 根據(jù)處理范圍不同奕谭，設計模式可分為類模式和對象模式。
  • 根據(jù)目的和用途不同痴荐，設計模式可分為創(chuàng)建型模式血柳、結(jié)構型模式和行為型模式三種。

軟件工程的過程管理

• 軟件過程是軟件生命周期中的一系列相關活動生兆，即用于開發(fā)和維護軟件及相關產(chǎn)品的一系列活動难捌。
• 軟件產(chǎn)品的質(zhì)量取決于軟件過程，具有良好軟件過程的組織能夠開發(fā)出高質(zhì)量的軟件產(chǎn)品鸦难。

軟件測試及其管理

• 測試的方法

• 軟件測試方法可分為靜態(tài)測試和動態(tài)測試根吁。

• 靜態(tài)測試是指被測試程序不在機器上運行，而采用人工檢測和計算機輔助靜態(tài)分析的手段對程序進行檢側(cè)合蔽。

• 對文檔的靜態(tài)測試主要以檢查單的形式進行击敌，而對代碼的靜態(tài)測試一般采用桌前檢查（Desk Checking）、代碼走查和代碼審查拴事。

• 動態(tài)測試是指在計算機上實際運行程序進行軟件測試沃斤，一般采用白盒測試和黑盒測試方法。

  • 白盒測試也稱為結(jié)構測試刃宵，主要用于軟件單元測試中衡瓶。
  • 黑盒測試也稱為功能測試，主要用于集成測試牲证、確認測試和系統(tǒng)測試中哮针。

• 測試的類型
  根據(jù)國家標準GB/T 15532-2008, 軟件測試可分為單元測試、集成測試坦袍、確認測試十厢、系統(tǒng)測試、配置項測試和回歸測試等類別捂齐。

軟件集成技術

• 從單個企業(yè)的角度來說寿烟，EAI可以包括表示集成、數(shù)據(jù)集成辛燥、控制集成和業(yè)務流程集成等多個層次和方面筛武。
• 表示集成是黑盒集成缝其，常用的集成技術主要有屏幕截取和輸入模擬技術。
• 數(shù)據(jù)集成是白盒集成徘六。
• 控制集成也稱為功能集成或應用集成内边，是在業(yè)務邏輯層上對應用系統(tǒng)進行集成的〈猓控制集成的集成點存于程序代碼中漠其，集成處可能只需簡單使用公開的 API （ApplicationProgramming Interface，應用程序編程接口）就可以訪問竿音，當然也可能需要添加附加的代碼來實現(xiàn)和屎。
• 業(yè)務流程集成也稱為過程集成，這種集成超越了數(shù)據(jù)和系統(tǒng)春瞬，它由一系列基于標準的柴信、統(tǒng)一數(shù)據(jù)格式的工作流組成。
• EAI技術可以適用于大多數(shù)要實施電子商務的企業(yè)宽气，以及企業(yè)之間的應用集成如庭。EAI 使得應用集成架構里的客戶和業(yè)務伙伴痹雅，都可以通過焦成供應鏈內(nèi)的所有應用和數(shù)據(jù)庫實現(xiàn)信息共享。