軟件工程基礎

1、軟件工程基礎,需求工程劉 馳,講授內容,軟件需求需求工程過程需求建模形式化描述,1. 什么是需求？,需求是對系統(tǒng)應該提供的服務和所受約束的描述。由于需求要向不同類型的涉眾（讀者）傳達不同層次的信息，可以將需求分為：用戶需求(目標需求) ：用用戶所熟悉的表達形式給出需求描述。系統(tǒng)需求(產(chǎn)品需求)：詳細地給出系統(tǒng)將提供的服務以及系統(tǒng)所受到的約束，比用戶需求更具體，更形式化。軟件設計描述(設計層需求)：在系統(tǒng)需求描述的基

2、礎上再加入更加詳細的設計層面的需求細節(jié)。,示例1,示例2,R1. 預算誤差<5％R2. 支持報價注冊、更新，以及根據(jù)需求隨時調整報價R3. 產(chǎn)品應具有記錄、檢索歷史報價的功能R4.系統(tǒng)界面大致如附件xx所示,目標需求,業(yè)務需求,產(chǎn)品需求,目標需求,用自然語言描述的用戶需求描述不夠清楚（二義性）需求混亂（功能需求、非功能需求、系統(tǒng)目標和設計信息無法清晰地區(qū)分）需求混合（多個不同的需求交織在一起，以一個需求的形式給

3、出）描述系統(tǒng)需求可能用到多種不同模型，如：對象模型、數(shù)據(jù)流模型等,原則上講，系統(tǒng)需求僅僅描述做什么，而不應該描述如何實現(xiàn)。然而，要給出細節(jié)需求而不提到任何設計信息，事實上也是不可能的：通常系統(tǒng)需求依照構成系統(tǒng)的各個子系統(tǒng)結構來給出，即由初始的系統(tǒng)體系結構來構造需求描述；通常目標系統(tǒng)和已有系統(tǒng)互操作，這就約束了目標系統(tǒng)的設計，同時這些約束又構成了新系統(tǒng)的需求；某些特別的設計（如NVP）是系統(tǒng)的一個外部需求,系統(tǒng)需求描述工具,S

4、ADT: Structured Analysis and Design Techniques,2. 需求的另一種劃分,業(yè)務需求用戶需求功能需求非功能需求業(yè)務需求（Business Requirement）反映了組織機構或客戶對系統(tǒng)、產(chǎn)品的高層次目標要求反映目標系統(tǒng)所處領域的特點在項目視圖與范圍文檔中予以說明,用戶需求（User Requirement）用戶使用產(chǎn)品必須要完成的任務在使用用例文檔或方案腳本說明中予以說

5、明功能需求（Functional, Behavioral Requirement ）定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務，從而滿足了業(yè)務需求對系統(tǒng)應該提供的服務、如何對輸入做出發(fā)應以及系統(tǒng)在特定條件下的行為的描述。涉及與本系統(tǒng)有接口的其他系統(tǒng)的所有事情?？赡苄枰鞔_聲明系統(tǒng)不應該做什么。,非功能需求(Non-functional Requirement)對系統(tǒng)提供的服務或功能給出的約束，包括性能指標、

6、對質量屬性（quality attribute）的描述、外部接口以及設計與實現(xiàn)的約束（constraint）、時間約束、標準等。非功能需求最好是可以驗證的，但實際上對需求量化通常很難。非功能需求與功能需求有時會發(fā)生沖突。非功能需求之間會發(fā)生沖突。,非功能需求分類,,,業(yè)務需求,用戶需求,質量屬性,外部接口,系統(tǒng)要求,約束,功能需求,項目視圖和范圍文檔,使用實例文檔,需求規(guī)格說明 （SRS）,,,,,,,,,,,業(yè)務需求,,,,各類

7、需求之間的關系,功能需求示例：大學圖書館系統(tǒng),- 功能需求以不同的詳細程度重寫（需求1和3）- 含糊的表達，“多種瀏覽器”,容易忽略的非瑣碎要求（示例）,酒店房間預訂系統(tǒng)：R1：根據(jù)客房類型而不是客房號進行預訂（業(yè)務細節(jié)）R2：考慮到預訂客房的客戶有可能不入住，可以接受超過空閑客房數(shù)量的預訂 （邊界條件）R3：授權的系統(tǒng)管理員可以自定義單價（權限）,3.軟件需求文檔,SRS (Software Requirement Spec

8、ification)Heninger 對軟件需求文檔提出的6點要求：It should specify external system behavior.It should specify constraints on the implementation. It should be easy to change. It should serve as a reference tool for system maintaine

9、rs. It should record forethought about the life cycle of the system. It should characterize acceptable responses to undesired events.,Introduction Purpose Definitions System overview References Overall description

10、 Product perspective System Interfaces User Interfaces Hardware interfaces Software interfaces Communication Interfaces Memory Constraints Operations Site Adaptation Requirements Product functions User charact

11、eristics Constraints, assumptions and dependencies Specific requirements External interface requirements Functional requirements Performance requirements Design constraints Standards Compliance Logical database r

12、equirement Software System attributes Reliability Availability Security Maintainability Portability Other requirements,SRS結構,SRS撰寫要求,正確性無二義性（需求確實是用戶所需嗎？）完整性（完備性，包括用戶需要的每一功能或性能）一致性（需求之間不能互相矛盾）可檢驗性（非計算機人員可以理解）可

13、實現(xiàn)性（有效性，需求是能夠現(xiàn)實的嗎？需要什么硬件系統(tǒng)支持？）可修改性可跟蹤性注釋,講授內容,軟件需求需求工程需求建模形式化描述,1. 什么是需求工程？,需求工程是對服務和約束的發(fā)現(xiàn)、分析、描述和檢驗的過程。需求工程的4個高層通用過程：可行性研究需求導出和分析需求描述和文檔編寫需求有效性驗證,需求分析的涉眾,合同監(jiān)管人員(PM)：提出里程碑(Milestones)和約束系統(tǒng)開發(fā)進度的計劃需求者：客戶(Custome

14、r)和使用者(User)。開發(fā)者系統(tǒng)分析人員設計人員，依據(jù)需求提出可接受的解決方案。測試人員，確保軟件系統(tǒng)滿足每一需求。系統(tǒng)集成人員,系統(tǒng)分析人員應具有的素質,綜合能力總體規(guī)劃，抽象和分解能力保證整個過程的善始善終的能力交流、理解和表達能力技術水平了解問題域和描述解空間的能力,重視需求分析,軟件項目中40%—60%的缺陷都是由需求分析階段的過失所致（Davis 1993，Leffingwell 1997）對歐洲軟件

15、行業(yè)的大規(guī)模調查顯示：確定和管理用戶需求是問題最多的兩個環(huán)節(jié)（ESPITI 1995）許多軟件問題都源于收集、記錄、協(xié)商和修改產(chǎn)品需求過程中的方式不當信息收集方式不正規(guī)沒有明確提出想要的功能常常存在未經(jīng)溝通的錯誤假設需求的定義不夠充分未經(jīng)仔細考慮進行需求變更 ······,2. 可行性研究,焦點問題：系統(tǒng)是否符合總體目標？系統(tǒng)是否能在現(xiàn)有條件和預算內按時完成？

16、目標系統(tǒng)能與已有系統(tǒng)集成？技術可行性經(jīng)濟可行性社會可行性操作可行性,可行性研究是高層的分析和設計,學生在學校教材科購買教材的系統(tǒng)的例子,一、通過對現(xiàn)實環(huán)境的研究，獲得系統(tǒng)具體物理模型,購書發(fā)票,購書單,書,購書證明,購書申請,,,,,,學生,學生,李保管,孫出納,錢會計,趙秘書,學生在學校教材科購買教材的系統(tǒng)的例子,二、去掉具體模型的非本質因素，抽取出邏輯模型,發(fā)票,購書單,書,有效單,購書單,,,,,,學

17、生,學生,發(fā)書,開領書單,開發(fā)票,有效性,學生在學校教材科購買教材的系統(tǒng)的例子,三、分析當前系統(tǒng)和目標系統(tǒng)的差別，建立目標系統(tǒng)的邏輯模型。,發(fā)票,購書單,書,購書單,,,,,學生,學生,發(fā)書,開領書單,審查并開發(fā)票,學生在學校教材科購買教材的系統(tǒng)的例子,四、對目標系統(tǒng)進行完善和補充，寫出完整的需求說明。五、對需求說明進行復審，直到確認文檔齊全并符合用戶的全部需求為止。,無效書單,,發(fā)票,購書單,購書單,,,,學生,學生,開

18、領書單,審查并開發(fā)票,可行性研究報告,（1）引言（2）可行性研究前提（3）對現(xiàn)有系統(tǒng)的分析（4）所建議系統(tǒng)的技術可行性分析（5）所建議系統(tǒng)的經(jīng)濟可行性分析（6）社會因素可行性分析（7）其它可供選擇方案（8）結論意見,需求與什么相關？,物理環(huán)境(Physical Environment)接口(Interfaces)用戶或人的因素(Factors)功能(Functionality)文檔(Documentation)數(shù)

19、據(jù)(Data)資源(Resources)安全性(Security)質量保證(Quality Assurance),設備的主要用途，在哪里發(fā)揮什么作用？所須設置設備的多少？環(huán)境限制等，如溫度、濕度或干擾？,1）物理環(huán)境 (Physical Environment),來自一個或多個其他系統(tǒng)的輸入？ 對一個或多個其它系統(tǒng)的輸出？數(shù)據(jù)是否必須預先進行規(guī)定的格式化處理？數(shù)據(jù)是否需要預先存放的介質？,2） 接口描述（Interfac

20、e Description）,誰使用系統(tǒng)？有幾種類型的用戶？每種類型用戶的技術水平怎樣？對每型用戶需要什么樣的培訓？用戶理解、使用系統(tǒng)的難易度怎樣？用戶誤用系統(tǒng)的困難程度怎樣？,3） 用戶和人為因素,系統(tǒng)將做什么？系統(tǒng)將在何時做？有幾種操作方式？系統(tǒng)能在何時、怎樣被改變或增強？對執(zhí)行速度，響應時間或數(shù)據(jù)流量有何限制和約束？,4）功能描述（Function Description）,5） 文檔（Documents）,需要

21、多少文檔？是聯(lián)機文檔還是靜態(tài)文檔或者二者皆可？文檔所面向的對象（讀者）？,6）數(shù)據(jù)（Data）,I/O數(shù)據(jù)格式應該是什么樣的？數(shù)據(jù)收或發(fā)的頻度？數(shù)據(jù)的精確度數(shù)據(jù)流量？數(shù)據(jù)必須在何時予以保存，保存多久？,7） 資源描述（Resource Description）,建立和維護系統(tǒng)都要什么材料、人員或其他資源？開發(fā)者必須具有哪些技術？系統(tǒng)占用空間？開發(fā)時間表？資金限制？,對系統(tǒng)或信息的存取必須在我們的控制之下？不同用戶的

22、數(shù)據(jù)之間將如何實現(xiàn)隔離？不同用戶程序之間，以及和操作系統(tǒng)間怎樣隔離？系統(tǒng)如何備份？備份副本必須被存于一個不同的位置？物理安全：應采取措施防火，防水防盜等安全措施？,8）安全性描述 (Security),系統(tǒng)必須有效檢測并隔離故障？平均無故障時間規(guī)定為多少？對一次失敗后重啟系統(tǒng)有一個最大時間？系統(tǒng)如何將變化合并到設計？維護僅僅是糾正錯誤，還是包括改進系統(tǒng)？對資源和響應時間使用什么樣的有效度量？系統(tǒng)移植性、可維護性等要

23、求？如何向別人示范系統(tǒng)的特征？,9）質量保證 (Quality Assurance),4. 需求驗證,驗證是為了確保需求說明準確、完整地表達必要的質量特點審查需求文檔以需求為依據(jù)編寫測試用例寫出黑盒功能測試用例編寫用戶手冊要用淺顯易懂的語言描述出所有對用戶可見的功能確定合格的標準,驗證的方法復審和進一步需求分析實現(xiàn)原型系統(tǒng)支持需求分析工具驗證的主要內容一致性驗證現(xiàn)實性驗證（需求是現(xiàn)實的嗎？）完整性（完備性）

24、和有效性驗證,5. 需求管理,需求管理是對需求變更了解和控制的過程。需求管理的任務是“與客戶就軟件需求達成并保持一致”（Paulk 1995）持久的需求與易變的需求一個變更管理過程由三個階段問題分析和變更描述變更分析和成本計算變更實現(xiàn),需求管理活動,定義需求基線審查變更請求，評估可能產(chǎn)生的影響以決定是否批準以可控的方式將批準的變更融入項目中保持項目計劃與需求的同步基于對需求變更影響的估計協(xié)商新的需求約定跟蹤每項需求

25、（找到對應的設計、代碼和測試用例）在項目的開發(fā)過程中始終跟蹤需求的狀態(tài)和變更,需求變更,分析、記錄審閱、協(xié)商,需求變更過程,市場營銷 客戶 管理層,,,,需求開發(fā),需求管理,,,,,,市場營銷客戶管理層,項目變更,項目環(huán)境,對項目需求狀況作出快速評估（1）,項目前景(vision)和范圍(scope)未曾明確定義客戶太忙，沒時間與需求分析和開發(fā)人員一起討論需求用戶代理（如開發(fā)經(jīng)理、用戶負責人、營銷人員等）

26、自詡可以代表用戶，其實不能準確說出用戶的要求需求只存在于那些所謂專家的腦子里，沒有被記錄下來客戶堅持所有需求都很重要，不愿排出它們的優(yōu)先次序開發(fā)人員在編碼過程中發(fā)現(xiàn)需求有歧義，缺少足夠的信息，只能去猜測,對項目需求狀況作出快速評估（2）,開發(fā)人員與客戶溝通時只關心用戶界面，忽略了用戶需要用軟件做什么客戶簽字確認了需求卻又一直提出修改要求項目范圍因接受需求變更而擴大，卻沒有相應地增加投入或剪裁功能，進度因而被延誤需求變更的請求

27、被弄丟，開發(fā)人員和客戶都不了解所有變更請求的狀態(tài)開發(fā)人員按照客戶要求實現(xiàn)的功能無人問津需求規(guī)格說明中的要求都實現(xiàn)了客戶卻不滿意,講授內容,軟件需求需求工程需求建模形式化描述,需求模型,模型是系統(tǒng)的抽象視圖，它忽略了系統(tǒng)中的所有細節(jié)。從不同的角度（外部、行為或結構）表達系統(tǒng)，形成不同類型的模型：上下文模型、行為模型、結構模型。上下文模型（系統(tǒng)環(huán)境模型）表達系統(tǒng)在整個環(huán)境中與其它系統(tǒng)和過程的位置關系。如：用例模型狀態(tài)機模型用

28、來描述系統(tǒng)的行為，以響應內部和外部的事件。它是一種行為模型。結構模型包括體系結構模型和數(shù)據(jù)結構模型。數(shù)據(jù)流模型用來描述數(shù)據(jù)是怎樣一步步在處理序列中流動的，它不僅可以描述系統(tǒng)內的處理過程（行為），也能夠有效地描述系統(tǒng)的上下文。E-R模型是一種最廣泛使用的數(shù)據(jù)結構模型。對象建模在一定程度上是結構建模和行為建模的結合。UML已經(jīng)被OMG認定為對象建模標準。,用例模型,狀態(tài)機模型,Entity-Relationship Model,概念

29、模型（E-R圖）邏輯模型（二維表的定義）物理模型（存儲空間的定義，如定義各個字段的大?。?shù)據(jù)庫的設計一般應經(jīng)過由概念模型到邏輯模型，再到物理模型的映射過程。,Decision Table,Warnier-Orr Diagrams,,Softwareproducts,System,Application,,,OS(n1)Compiler(n2)Software Tool,,Editor(n3)Test driver(n4

30、)CAD tool(n5),8 fundamental building blocks,,IPO Diagrams,Fence Diagram showing State Transitions (Example: Hotel reservations),,,,,,,(Null),Requested,On waiting list,Confirmed,Used,Canceled,Archive,,,,,,,,,,Use UML to

31、Represent OO,OMG (Object Management Group) have adopted UML as the OO notational standard.UML can be used to visualize, specify, or document a problem.UML can be used throughout the software development process.,13 (!!

32、) Kinds of UML Diagrams,ActivityClassCommunicationComponentComponent structureDeploymentInteraction,ObjectPackageSequenceState machineTimingUse case,64,Example: Class Diagram,http://www.agiledata.org/images/oo

33、101ClassDiagram.gif,,Class,Class Name,Attribute : type,Operation (arg list) : return typeAbstract operation,,,Object,,ObjectName: Class Name,Attribute : type,Operation (arg list) : return typeAbstract operation,,,Role

34、of A,Role of B,Edges,,Class A,,Class B,,,Source,,Target,,Role name,,Client,,Supplier,,Dependency,Navigability,Association,Role name,Multiplicities on Edges (Cardinalities),1Exactly one*Many (any number)0..1Opti

35、onal (zero or one)m..nSpecified range{ordered}*Ordered,Generalization (Inheritance),,Supertype,,Subtype 1,,Subtype 2,,,,,,,,Comment about an item,,,,,,,,,,Some item eg class,Note (Comment),Example: Sequence Diagram,

36、Elements of Sequence Diagrams,There is also notation for loops, conditions, etc.,UML Modeling Tools,Rational Rose (www.rational.com) by IBMTogetherSoft Control Center, Borland (http://www.borland.com/together/index.htm

37、l)ArgoUML (free software) (http://argouml.tigris.org/ ) OpenSource; written in Java Others http://www.objectsbydesign.com/tools/umltools_byCompany.html,,Rational Rose,StandardToolbar,Browser,DocumentationWin