軟件工程基礎(chǔ)

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

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

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

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

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

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

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

8、ification)Heninger 對(duì)軟件需求文檔提出的6點(diǎn)要求：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結(jié)構(gòu),SRS撰寫要求,正確性無二義性（需求確實(shí)是用戶所需嗎？）完整性（完備性，包括用戶需要的每一功能或性能）一致性（需求之間不能互相矛盾）可檢驗(yàn)性（非計(jì)算機(jī)人員可以理解）可

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29、模型（E-R圖）邏輯模型（二維表的定義）物理模型（存儲(chǔ)空間的定義，如定義各個(gè)字段的大?。?shù)據(jù)庫(kù)的設(shè)計(jì)一般應(yīng)經(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