軟件工程：理論、技術(shù)及實(shí)踐 課件全套 江頡 第1-11章 軟件工程概述- 軟件工程與社會(huì)

軟件工程

SoftwareEngineering共享“小黃Y”缺少專人維護(hù)車子使用的情況變差可正常使用自行車數(shù)量減少。校區(qū)間分布不均衡沒有經(jīng)費(fèi)可以用于校區(qū)間自行車搬運(yùn)捐贈(zèng)車子來源，設(shè)定唯一編號(hào)定期檢查，統(tǒng)計(jì)加鎖，開展免費(fèi)租用服務(wù)，允許走出校門。限制借還服務(wù)、異地還車網(wǎng)絡(luò)版，校園地圖

指示服務(wù)。校網(wǎng)服務(wù)移動(dòng)端兩年后，經(jīng)費(fèi)所剩無幾，原開發(fā)、管理的同學(xué)退出協(xié)會(huì)。同學(xué)有意見共享單車普及，購置單車同學(xué)逐漸變少，“小黃Y”服務(wù)是否需要繼續(xù)堅(jiān)持下去?誰來支付自行車維修的費(fèi)用?誰來維護(hù)這個(gè)功能愈見增多的代碼呢？這個(gè)學(xué)生社團(tuán)組織維護(hù)的代碼可以稱之為軟件嗎？可以稱這樣的開發(fā)和維護(hù)工作為一個(gè)軟件工程項(xiàng)目嗎？它與現(xiàn)在城市共享單車系統(tǒng)會(huì)有哪些差別呢？共享“小黃Y”課程教學(xué)目標(biāo)1.掌握軟件工程和軟件開發(fā)模型的基本概念，并了解軟件開發(fā)相關(guān)技術(shù)標(biāo)準(zhǔn)。2.掌握軟件需求分析、設(shè)計(jì)概念和一般性過程，能夠運(yùn)用這些知識(shí)對(duì)復(fù)雜軟件系統(tǒng)進(jìn)行需求分析、模塊劃分和詳細(xì)設(shè)計(jì)。3.掌握面向?qū)ο蟮能浖?xiàng)目開發(fā)特點(diǎn)以及項(xiàng)目管理方法，增強(qiáng)編程實(shí)踐、軟件測(cè)試與維護(hù)。4.掌握UML建模技術(shù)，能夠在軟件工程過程中使用常用建模工具對(duì)復(fù)雜軟件系統(tǒng)進(jìn)行需求分析和設(shè)計(jì)。5.掌握軟件工程需求、分析、設(shè)計(jì)等相關(guān)文檔的編寫。6.掌握軟件過程的管理和質(zhì)量控制，以及軟件項(xiàng)目的計(jì)劃、可行性分析和成本周期估算等知識(shí)。

第1章理解軟件工程軟件的發(fā)展1軟件的特性和分類2軟件工程的起源3軟件團(tuán)隊(duì)5軟件質(zhì)量467軟件工程的領(lǐng)域知識(shí)軟件工程師的職業(yè)道德1.1軟件的發(fā)展思考5個(gè)問題：我們用的是什么類型的計(jì)算？我們需要保存什么類型的信息或數(shù)據(jù)？對(duì)于需要長期保留的信息，哪些存儲(chǔ)方法最合適？面對(duì)復(fù)雜的選項(xiàng)或決策，哪些分析方法對(duì)我們有幫助？在進(jìn)行數(shù)據(jù)與知識(shí)的交流時(shí)，有哪些最佳方法？提示：縱覽計(jì)算機(jī)和軟件逐步用于解決這些問題的過程，從大歷史觀的角度來考慮這5個(gè)問題。軟件發(fā)展史？（課后閱讀《軟件工程通史》，在閱讀基礎(chǔ)上要求總結(jié)近20年世界軟件發(fā)展，以及中國軟件發(fā)展）。軟件的特性和分類無形性：邏輯實(shí)體，沒有物理形態(tài)，通過運(yùn)行表示智能性：凝聚大量人類腦力勞動(dòng)抽象性：邏輯實(shí)體的抽象性，開發(fā)的抽象性系統(tǒng)性：有機(jī)整體復(fù)雜性：服務(wù)于各種行業(yè)可復(fù)制性：拷貝演化性：環(huán)境、需求和技術(shù)變化1.21.2.1軟件的特性軟件特性和分類系統(tǒng)軟件應(yīng)用軟件支撐軟件可復(fù)用軟件1.21.2.2軟件的分類按照軟件的作用分類軟件特性和分類商業(yè)軟件公共軟件共享軟件自由軟件1.21.2.2軟件的分類按照版權(quán)保護(hù)標(biāo)準(zhǔn)分類1.3軟件工程的起源1.3.1軟件危機(jī)通常，把計(jì)算機(jī)軟件開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題稱為“軟件危機(jī)”。如今軟件開發(fā)技術(shù)已經(jīng)有了很大的進(jìn)步，但是隨著軟件規(guī)模的不斷擴(kuò)大，軟件需要解決的問題越來越復(fù)雜，“軟件危機(jī)”依舊存在?？紤]到“軟件危機(jī)”的周期長且難以預(yù)測(cè)，一些人將“軟件危機(jī)”稱為“軟件蕭條”。1.3軟件工程的起源開發(fā)者與用戶溝通存在障礙隨著軟件規(guī)模逐漸增加，相應(yīng)的軟件復(fù)雜性也呈指數(shù)型升高缺乏有效的經(jīng)驗(yàn)和數(shù)據(jù)積累以及估算工具來制定有效的計(jì)劃項(xiàng)目?jī)?nèi)部缺乏管理經(jīng)驗(yàn)軟件危機(jī)的典型表現(xiàn)1.3軟件工程的起源軟件產(chǎn)品的質(zhì)量低下軟件通常沒有文檔資料，或者文檔資料不夠完備軟件危機(jī)的典型表現(xiàn)1.3軟件工程的起源1968年在第一屆NATO會(huì)議上曾經(jīng)給出了軟件工程的一個(gè)早期定義：“軟件工程就是為了經(jīng)濟(jì)地獲得可靠的且能在實(shí)際機(jī)器上有效地運(yùn)行的軟件，而建立和使用完善的工程原理?！?990年IEEE進(jìn)一步給出了一個(gè)更全面更具體的定義：“軟件工程是：①應(yīng)用系統(tǒng)化的、規(guī)范的、可量化的方法，來開發(fā)、運(yùn)行和維護(hù)軟件，即將工程化方法應(yīng)用于軟件；②對(duì)①中各種方法的研究。1.3.2軟件工程的定義1.3軟件工程的起源軟件工程是指導(dǎo)計(jì)算機(jī)軟件開發(fā)和維護(hù)的工程性學(xué)科。以計(jì)算機(jī)科學(xué)理論和其他相關(guān)學(xué)科的理論為指導(dǎo)，采用工程化的概念、原理、技術(shù)和方法進(jìn)行軟件的開發(fā)與維護(hù)軟件，把經(jīng)過時(shí)間考驗(yàn)而證明正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來，以較少的代價(jià)獲得高質(zhì)量的軟件并有效地維護(hù)它，這就是軟件工程。1.3軟件工程的起源軟件過程是指生產(chǎn)軟件產(chǎn)品的一組活動(dòng)、動(dòng)作、任務(wù)的集合?；顒?dòng)主要是實(shí)現(xiàn)較為寬泛的目標(biāo)，動(dòng)作包含了主要工作制品生產(chǎn)過程中的一系列任務(wù)，任務(wù)則關(guān)注小而明確的目標(biāo)，能夠產(chǎn)生實(shí)際的制品。圖1-2概念性軟件開發(fā)框架1.3.3軟件過程軟件質(zhì)量軟件質(zhì)量是“反映軟件滿足明確和隱含的需求的能力的特性總和”。具體來說，軟件質(zhì)量是軟件符合明確敘述的功能和性能需求、文檔中明確描述的開發(fā)標(biāo)以及所有專業(yè)開發(fā)的軟件都應(yīng)具有的和隱含特征相一致的程度。為了解軟件質(zhì)量是否滿足要求，必須從軟件質(zhì)量屬性出發(fā)，通過考察軟件質(zhì)量屬性來評(píng)價(jià)軟件質(zhì)量，并依此給出提高軟件質(zhì)量的方法。1.4軟件質(zhì)量正確性健壯性可靠性性能易用性可理解性安全性可擴(kuò)展性兼容性可移植性

軟件質(zhì)量常見的屬性1.41.5

軟件團(tuán)隊(duì)如何從一個(gè)程序演化為一個(gè)有用的產(chǎn)品圖1-3編程系統(tǒng)產(chǎn)品的演進(jìn)軟件開發(fā)小組的組織結(jié)構(gòu)取決于組織的管理風(fēng)格、組里的人員數(shù)目及他們的技術(shù)水平和軟件項(xiàng)目需要解決問題的難易程度。Mantei提出了在確定采用何種軟件工程小組結(jié)構(gòu)時(shí)應(yīng)該考慮的與項(xiàng)目相關(guān)的7個(gè)問題。①項(xiàng)目待解決問題的困難程度。②項(xiàng)目要產(chǎn)生的程序的規(guī)模，以代碼行或者功能點(diǎn)來衡量。③小組成員需要一起工作的時(shí)間（小組生命期）。④需要解決的問題能夠被模塊化的程度。⑤待建造系統(tǒng)所要求的質(zhì)量和可靠性。⑥交付日期的嚴(yán)格程度。⑦項(xiàng)目所需要的社交性（通信）的程度。1.5

軟件團(tuán)隊(duì)1.5

軟件團(tuán)隊(duì)從歷史角度看：（1）民主小組（2）主程序員小組（3）現(xiàn)代程序員小組（4）同步—穩(wěn)定小組（5）敏捷過程小組（6）開源編程小組圖1-4主程序員小組組織結(jié)構(gòu)圖1-5現(xiàn)代程序員小組組織結(jié)構(gòu)1.6

軟件工程的知識(shí)領(lǐng)域1993年，IEEE計(jì)算機(jī)協(xié)會(huì)和ACM聯(lián)合建立的軟件工程協(xié)同委員會(huì)、加拿大魁北克大學(xué)以及美國MITRE公司共同承擔(dān)了ISO/ICE/JTCI“SWEBOK（SoftwareEngineeringBodyofKnowledge）指南”項(xiàng)目。該項(xiàng)目希望促進(jìn)世界范圍內(nèi)對(duì)軟件工程形成一致觀點(diǎn)；闡明軟件工程相對(duì)于其他學(xué)科（如計(jì)算機(jī)科學(xué)、項(xiàng)目管理、計(jì)算機(jī)工程和數(shù)學(xué)等）的位置，并確立它們的分界；刻畫軟件工程學(xué)科的內(nèi)容；提供使用知識(shí)體系的主題；為開發(fā)課程和個(gè)人認(rèn)證與許可材料提供基礎(chǔ)。1.6

軟件工程的知識(shí)領(lǐng)域2014年IEEE公布的SWEBOK3.0中提到了軟件工程的15個(gè)知識(shí)領(lǐng)域（KnowledgeArea，KA），其中包括：11個(gè)軟件工程實(shí)踐知識(shí)域——軟件需求、軟件設(shè)計(jì)、軟件構(gòu)造、軟件測(cè)試、軟件維護(hù)、軟件配置管理、軟件工程管理、軟件工程過程、軟件工程模型和方法、軟件質(zhì)量、軟件工程職業(yè)實(shí)踐；4個(gè)軟件工程教育基礎(chǔ)知識(shí)域——軟件工程經(jīng)濟(jì)學(xué)、計(jì)算基礎(chǔ)、數(shù)學(xué)基礎(chǔ)和工程基礎(chǔ)。1.7

軟件工程師職業(yè)道德軟件工程師應(yīng)履行其實(shí)踐承諾，使軟件的需求分析、規(guī)格說明、設(shè)計(jì)、開發(fā)、測(cè)試和維護(hù)成為一項(xiàng)有益和受人尊敬的職業(yè)。（1）公眾——軟件工程師應(yīng)當(dāng)始終如一地以符合公眾利益為目標(biāo)。（2）客戶和雇主——在保持與公眾利益一致的原則下，軟件工程師應(yīng)滿足客戶和雇主的最高利益。（3）產(chǎn)品——軟件工程師應(yīng)當(dāng)確保他們的產(chǎn)品和相關(guān)的改進(jìn)符合可能達(dá)到的最高專業(yè)標(biāo)準(zhǔn)。（4）判斷——軟件工程師在進(jìn)行相關(guān)的專業(yè)判斷時(shí)，應(yīng)該堅(jiān)持正直、誠實(shí)和獨(dú)立的原則。（5）管理——軟件工程的管理和領(lǐng)導(dǎo)人員在軟件開發(fā)和維護(hù)的過程中，應(yīng)自覺遵守、應(yīng)用并推動(dòng)合乎道德規(guī)范的管理方法。（6）專業(yè)——軟件工程師應(yīng)當(dāng)自覺推動(dòng)本行業(yè)所提倡的誠實(shí)、正直的道德規(guī)范，并自覺維護(hù)本行業(yè)的聲譽(yù)，使軟件行業(yè)更好地為公眾利益所服務(wù)。（7）同事——軟件工程師對(duì)其同事應(yīng)持平等互助和支持的態(tài)度。（8）自身——軟件工程師應(yīng)終生不斷地學(xué)習(xí)和實(shí)踐其專業(yè)知識(shí)，并在學(xué)習(xí)和實(shí)踐的過程中不斷提高自身的道德規(guī)范素養(yǎng)。小結(jié)1.了解軟件的發(fā)展2.理解軟件的特性3.了解影響軟件工程發(fā)展的各種因素4.認(rèn)識(shí)軟件工程學(xué)科5.理解軟件工程對(duì)軟件發(fā)展所起的作用6.了解軟件產(chǎn)業(yè)的發(fā)展現(xiàn)狀作業(yè)與思考作業(yè)：1.簡(jiǎn)述近20年軟件發(fā)展趨勢(shì)和重大事件，分國內(nèi)和國外描述。2.總結(jié)軟件特性有哪些。3.比較傳統(tǒng)軟件工程和面向?qū)ο筌浖こ痰膮^(qū)別。思考：1.思考“共享小黃Y”提出的后續(xù)問題。第2章軟件工程發(fā)展2.1軟件工程發(fā)展歷程1.第一代軟件工程－－傳統(tǒng)的軟件工程2.第二代軟件工程－－對(duì)象工程3.第三代軟件工程－－過程工程4.第四代軟件工程－－構(gòu)件工程軟件工程已經(jīng)歷四個(gè)重要發(fā)展階段1.第一代軟件工程－－傳統(tǒng)的軟件工程2.第二代軟件工程－－對(duì)象工程3.第三代軟件工程－－過程工程4.第四代軟件工程－－構(gòu)件工程

60年代末到70年代為了克服“軟件危機(jī)”(Softwarecrisis)提出“軟件工程”的名詞,將軟件開發(fā)納入工程化的軌道，基本形成軟件工程的概念、框架、技術(shù)和方法，稱為傳統(tǒng)的軟件工程。軟件工程已經(jīng)歷四個(gè)重要發(fā)展階段2.1軟件工程發(fā)展歷程1.第一代軟件工程－－傳統(tǒng)的軟件工程2.第二代軟件工程－－對(duì)象工程3.第三代軟件工程－－過程工程4.第四代軟件工程－－構(gòu)件工程

80年代中到90年代，面向?qū)ο蟮姆椒ㄅc技術(shù)得到發(fā)展，研究的重點(diǎn)轉(zhuǎn)移到面向?qū)ο蟮姆治雠c設(shè)計(jì)，演化為一種完整的軟件開發(fā)方法和系統(tǒng)的技術(shù)體系，稱為對(duì)象工程。軟件工程已經(jīng)歷四個(gè)重要發(fā)展階段2.1軟件工程發(fā)展歷程1.第一代軟件工程－－傳統(tǒng)的軟件工程2.第二代軟件工程－－對(duì)象工程3.第三代軟件工程－－構(gòu)件工程4.第四代軟件工程－－服務(wù)工程

20世紀(jì)90年代起，基于構(gòu)(Component)的開發(fā)方法取得重要進(jìn)展，軟件系統(tǒng)的開發(fā)可通過使用現(xiàn)成的可復(fù)用構(gòu)件組裝完成，而無需從頭開始構(gòu)造，以此達(dá)到提高效率和質(zhì)量，降低成本的目的。軟件工程已經(jīng)歷四個(gè)重要發(fā)展階段2.1軟件工程發(fā)展歷程軟件工程已經(jīng)歷四個(gè)重要發(fā)展階段1.第一代軟件工程－－傳統(tǒng)的軟件工程2.第二代軟件工程－－對(duì)象工程3.第三代軟件工程－－構(gòu)件工程4.第四代軟件工程－－服務(wù)工程市場(chǎng)需求的快速變化，要求企業(yè)系統(tǒng)具有敏捷服務(wù)、快速重構(gòu)、資源重用及自由擴(kuò)充等特點(diǎn)，由此面向服務(wù)的架構(gòu)SOA應(yīng)運(yùn)而生。它定義了構(gòu)成系統(tǒng)的服務(wù)，通過描述服務(wù)之間的交互提供特定的功能特性。2.1軟件工程發(fā)展歷程2.2軟件工程中新技術(shù)的影響1.云計(jì)算與軟件工程2.大數(shù)據(jù)與軟件工程3.移動(dòng)應(yīng)用與軟件工程新技術(shù)的新特點(diǎn)使得軟件工程也產(chǎn)生了變化。云計(jì)算技術(shù)的發(fā)展對(duì)于軟件開發(fā)影響越來越大。1.云計(jì)算對(duì)開發(fā)模式的影響2.云計(jì)算對(duì)開發(fā)工具的影響3.云計(jì)算對(duì)開發(fā)者的影響4.云計(jì)算對(duì)軟件測(cè)試的影響2.2軟件工程中新技術(shù)的影響圖2-1云計(jì)算框架2.2軟件工程中新技術(shù)的影響軟件工程中的大數(shù)據(jù)是由眾多軟件開發(fā)和使用過程中的工具自然產(chǎn)生和記錄的軟件演化及參與者活動(dòng)的日志，散布在互聯(lián)網(wǎng)的軟件倉庫、軟件公司以及個(gè)體的各種環(huán)境中。1.軟件項(xiàng)目樣本多2.產(chǎn)生的日志數(shù)據(jù)種類和格式多（結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)）3.總體規(guī)模巨大且時(shí)刻變化。軟件工程中的大數(shù)據(jù)具有的主要特點(diǎn)：2.2軟件工程中新技術(shù)的影響移動(dòng)應(yīng)用本質(zhì)上仍是軟件，同樣存在圍繞軟件生命周期的各項(xiàng)軟件工程任務(wù)。與傳統(tǒng)的桌面軟件相比，除了新的開發(fā)框架和平臺(tái)以外，移動(dòng)應(yīng)用的開發(fā)還具有以下特點(diǎn)。1.需求工程2.軟件重用3.能耗2.2軟件工程中新技術(shù)的影響2.3軟件工程中人的因素典型的軟件開發(fā)項(xiàng)目在時(shí)間、人力、資金方面都是有限制的，軟件開發(fā)的任何一步都需要人的參與。人的行動(dòng)、想法以及決策都會(huì)影響軟件的開發(fā)。而每一個(gè)人都是具有一定特點(diǎn)的個(gè)體，這些特點(diǎn)可能與受過怎樣的教育、喜歡怎樣的工作方式有關(guān)，也可能與他們所生活的社會(huì)文化環(huán)境有關(guān)。人的這些特點(diǎn)會(huì)在軟件開發(fā)過程中不同程度地影響軟件質(zhì)量、軟件開發(fā)速度，因而研究人的特性對(duì)整個(gè)軟件開發(fā)具有重要意義。1.作為個(gè)體的人對(duì)軟件開發(fā)的影響2.作為團(tuán)隊(duì)的人對(duì)軟件開發(fā)的影響3.作為客戶的人對(duì)軟件開發(fā)的影響2.3軟件工程中人的因素2.4軟件工程的未來發(fā)展軟件的本質(zhì)是演化性和構(gòu)造性，軟件開發(fā)將伴隨計(jì)算機(jī)技術(shù)的發(fā)展而進(jìn)步。軟件工程的未來發(fā)展主要趨勢(shì)：1.全球化軟件協(xié)作交付2.開放性計(jì)算被廣泛應(yīng)用3.智能化的軟件開發(fā)方法小結(jié)1.了解軟件工程的發(fā)展歷程2.了解云計(jì)算及其對(duì)軟件工程的影響3.了解大數(shù)據(jù)及其對(duì)軟件工程的影響4.了解移動(dòng)應(yīng)用開發(fā)的特點(diǎn)5.明確軟件開發(fā)中人的因素6.思考軟件工程的未來發(fā)展趨勢(shì)第3章軟件過程軟件生命周期模型1統(tǒng)一過程2敏捷開發(fā)3開源軟件4軟件過程的改進(jìn)5軟件過程軟件過程是生產(chǎn)軟件的方式，不同的軟件組織有不同的軟件生產(chǎn)過程。例如：初創(chuàng)公司的資本和人力條件有限，因此為開發(fā)出能迅速響應(yīng)市場(chǎng)需求的軟件產(chǎn)品，會(huì)更關(guān)注完成產(chǎn)品的核心功能并盡早發(fā)布，新功能的加入以及產(chǎn)品質(zhì)量的提高往往放在軟件交付以后。長期開發(fā)行業(yè)應(yīng)用軟件的公司對(duì)同類產(chǎn)品需求的把握更精準(zhǔn)，對(duì)設(shè)計(jì)和實(shí)現(xiàn)軟件所需要花費(fèi)的工作量和時(shí)間的估算更準(zhǔn)確，從而能更“有秩序”地進(jìn)行相關(guān)軟件生產(chǎn)，提交給用戶穩(wěn)定、可靠的軟件產(chǎn)品。

軟件生命周期模型：對(duì)構(gòu)建軟件所應(yīng)遵循的步驟的理論性描述。

軟件生命周期模型是跨越整個(gè)生存期的系統(tǒng)開發(fā)、運(yùn)作和維護(hù)所實(shí)施的全部過程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架。

瀑布模型快速原型模型

增量模型 螺旋模型

噴泉模型

可以用過程流來描述組織框架活動(dòng)、動(dòng)作和任務(wù)的次序，分為線性、迭代、演化和并行。軟件過程瀑布模型（waterfallmodel）是在1970年由WinstonRoyce提出的，其過程流是線性的。瀑布模型的關(guān)鍵是每個(gè)階段要完成指定的文檔并且該階段的產(chǎn)品被軟件質(zhì)量保證小組認(rèn)可之后，才能進(jìn)入下一個(gè)階段。3.1軟件生命周期模型3.1.1瀑布模型圖3-1瀑布模型軟件生命周期模型3.1瀑布模型被稱為經(jīng)典的軟件生命周期模型。在有明確需求并且需求保持穩(wěn)定的情況下，它是一個(gè)非常有效的過程模型。瀑布模型不適應(yīng)軟件需求不明確或者在開發(fā)過程中需求經(jīng)常變化的情況。軟件生命周期模型3.1.1瀑布模型3.1快速原型模型通過使用原型來輔助軟件開發(fā)。在需求分析階段要得到準(zhǔn)確、合理的需求說明可能比較困難，用戶可能并不清楚自己需要的是什么樣的系統(tǒng)。快速原型模型適合預(yù)先不能確切定義需求的軟件系統(tǒng)的開發(fā)。

軟件生命周期模型3.1.2快速原型模型3.1圖3-2快速原型模型

軟件產(chǎn)品的開發(fā)基本上是線性順序進(jìn)行的。

軟件生命周期模型3.1快速原型模型最大的特點(diǎn)在于“快速”。對(duì)于采用何種形式、何種策略運(yùn)用快速原型主要取決于軟件項(xiàng)目的特點(diǎn)、團(tuán)隊(duì)成員素質(zhì)、可供支持的原型開發(fā)工具和技術(shù)等，需要根據(jù)實(shí)際情況來做出決定。軟件生命周期模型3.1.2快速原型模型3.1如果軟件有明確需求，整個(gè)開發(fā)過程不要求按照線性過程流執(zhí)行，同時(shí)要求團(tuán)隊(duì)迅速為用戶提供一套功能有限的軟件產(chǎn)品，并允許在后續(xù)版本中再進(jìn)行細(xì)化和擴(kuò)展，在這種情況下，可采用增量模型比較適用。

軟件生命周期模型3.1.3增量模型3.1圖3-3增量模型

軟件生命周期模型3.1增量模型的最大特點(diǎn)就是將待開發(fā)的軟件系統(tǒng)模塊化和組件化。增量式開發(fā)有利于從總體上降低軟件項(xiàng)目的技術(shù)風(fēng)險(xiǎn)。但增量模型對(duì)軟件設(shè)計(jì)有更高的技術(shù)要求：軟件體系結(jié)構(gòu)具有良好的開放性與穩(wěn)定性，能夠順利地實(shí)現(xiàn)構(gòu)件集成；同時(shí)增量構(gòu)件應(yīng)具有很強(qiáng)的功能獨(dú)立性，能夠方便地與系統(tǒng)集成。軟件生命周期模型3.1.3增量模型3.1為了讓軟件開發(fā)能更適應(yīng)風(fēng)險(xiǎn)的控制，Barry

Boehm在1988年提出軟件系統(tǒng)開發(fā)的螺旋模型，將瀑布模型和快速原型模型結(jié)合起來，強(qiáng)調(diào)風(fēng)險(xiǎn)分析。螺旋模型以快速原型法為基礎(chǔ)，以進(jìn)化的開發(fā)方式為中心，在每個(gè)項(xiàng)目階段使用瀑布模型法。它的基本做法是在每一個(gè)開發(fā)階段前引入風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)分析和風(fēng)險(xiǎn)控制。軟件生命周期模型3.1.4螺旋模型3.1圖3-4螺旋模型軟件生命周期模型3.1B.H.Sollers和J.M.Edwards在1990年提出的噴泉模型是一種以用戶需求為動(dòng)力，以對(duì)象為驅(qū)動(dòng)的模型，主要用于描述面向?qū)ο蟮能浖_發(fā)過程。軟件生命周期模型3.1.5噴泉模型3.1圖3-5噴泉模型1994年10月，JamesRumbaugh和GradyBooch開始合作致力于建模語言工作，于1995年10月發(fā)布了統(tǒng)一方法UM0.8（UnitiedMethod0.8）。1995年，經(jīng)過Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分別發(fā)布了UML0.9和UML0.91，并將UM重新命名為統(tǒng)一建模語言（UnifiedModelingLanguage，UML）。UML是現(xiàn)今較為成熟的軟件建模技術(shù)和語言。3.2.1RUP的產(chǎn)生3.2統(tǒng)一過程在創(chuàng)建UML開始階段，UML的三位創(chuàng)始人就認(rèn)識(shí)到軟件開發(fā)除了需要建模技術(shù)和語言之外，還需要一個(gè)更高層次、能夠指導(dǎo)軟件開發(fā)人員進(jìn)行開發(fā)活動(dòng)的開發(fā)過程方法學(xué)。1998年，統(tǒng)一過程（RationalUnifiedProcess，RUP）正式發(fā)布，并且將UML作為其建模語言。RUP并不是具體的一系列步驟，而應(yīng)被視為一種自適應(yīng)的方法學(xué)，可以根據(jù)實(shí)際開發(fā)的軟件產(chǎn)品進(jìn)行修改。3.2.1RUP的產(chǎn)生3.2統(tǒng)一過程圖3-6RUP發(fā)展過程

3.2.1RUP的產(chǎn)生統(tǒng)一過程3.2圖3-7RUP過程模型

RUP軟件過程模型是一個(gè)二維的軟件開發(fā)模型，也是一種用例驅(qū)動(dòng)、以體系結(jié)構(gòu)為核心、迭代遞增的軟件過程框架。3.2.2RUP的過程模型統(tǒng)一過程3.2RUP包含了軟件開發(fā)積累下來的六大經(jīng)驗(yàn)：1.迭代和遞增式開發(fā)2.管理需求3.基于組件的體系結(jié)構(gòu)4.可視化建模5.驗(yàn)證軟件質(zhì)量6.控制軟件變更

3.2.3RUP的特點(diǎn)統(tǒng)一過程3.22001年，17位在當(dāng)時(shí)被稱為“輕量級(jí)方法學(xué)家”的軟件開發(fā)者、軟件工程作家以及軟件咨詢師（敏捷聯(lián)盟）共同簽署了“敏捷軟件開發(fā)宣言”。3.3.1敏捷原則3.3敏捷開發(fā)敏捷軟件開發(fā)宣言個(gè)體和交互勝過過程和工具可以工作的軟件

勝過

面面俱到的文檔

客戶合作

勝過

合同談判

響應(yīng)變化

勝過

遵循計(jì)劃“我們正在通過親身實(shí)踐以及幫助他人實(shí)踐，揭示更好的軟件開發(fā)方法。通過這項(xiàng)工作，我們認(rèn)識(shí)到：雖然右項(xiàng)也具有價(jià)值，但我們認(rèn)為左項(xiàng)具有更大的價(jià)值?！泵艚蓍_發(fā)3.3敏捷聯(lián)盟制定了12項(xiàng)原則，將敏捷理念落實(shí)到具體可操作的層面。敏捷軟件開發(fā)項(xiàng)目以12項(xiàng)原則為基石，但并不是每一個(gè)敏捷模型都同等使用這12項(xiàng)原則，一些模型可以選擇忽略或淡化其中的一項(xiàng)或多項(xiàng)原則的重要性。敏捷開發(fā)3.33.3.1敏捷原則（1）最優(yōu)先要做的是通過盡早、持續(xù)地交付有價(jià)值的軟件來使客戶滿意。（2）即使在開發(fā)的后期，也歡迎需求變更。敏捷過程利用變更為客戶創(chuàng)造競(jìng)爭(zhēng)優(yōu)勢(shì)。（3）經(jīng)常交付可運(yùn)行軟件，交付的間隔可以從幾個(gè)星期到幾個(gè)月，交付的時(shí)間間隔越短越好。（4）在整個(gè)項(xiàng)目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須每天都在一起工作。（5）激發(fā)個(gè)體的斗志，以他們?yōu)楹诵拇罱?xiàng)目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。（6）不論團(tuán)隊(duì)內(nèi)外，傳遞信息效果最好和效率最高的方式是面對(duì)面的交談。敏捷開發(fā)3.3（7）可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)。（8）敏捷過程倡導(dǎo)可持續(xù)開發(fā)。責(zé)任人、開發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù)。（9）不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會(huì)增強(qiáng)敏捷能力。（10）要做到簡(jiǎn)潔，即盡最大可能減少不必要的工作。這是一門藝術(shù)。（11）最好的架構(gòu)、需求和設(shè)計(jì)來自于自組織團(tuán)隊(duì)。（12）每隔一定時(shí)間，團(tuán)隊(duì)要反思如何才能更有效地工作，并相應(yīng)調(diào)整自己的行為。敏捷開發(fā)3.3極限編程（XP）Scrum精益開發(fā)（Lean）OpenUP3.3.2敏捷過程應(yīng)用最廣泛的敏捷開發(fā)方法框架有：敏捷開發(fā)3.3極限編程（ExtremeProgramming，XP）是目前敏捷軟件開發(fā)使用最為廣泛的方法之一，其主要目標(biāo)在于降低因需求變更而帶來的成本。極限編程的創(chuàng)始人KentBeck為XP的實(shí)施確定了五個(gè)基礎(chǔ)要素：溝通、簡(jiǎn)明、反饋、鼓勵(lì)和尊重。3.3.3極限編程敏捷開發(fā)3.3圖3-8

XP過程

3.3.3極限編程敏捷開發(fā)3.3Scrum最早由JeffSutherland在1993年提出，KenSchwaber在1995年OOPSLA會(huì)議上形式化了Scrum開發(fā)過程，并向業(yè)界公布。Scrum已經(jīng)是業(yè)界常用的敏捷開發(fā)方法之一。使用Scrum的產(chǎn)品生命周期一般包含三個(gè)階段：●產(chǎn)品定義（計(jì)劃）：進(jìn)行迭代所需要的項(xiàng)目準(zhǔn)備、項(xiàng)目計(jì)劃和技術(shù)分析?！竦_發(fā)（執(zhí)行）：在固定時(shí)間的迭代中實(shí)現(xiàn)需求（產(chǎn)品待辦列表中的條目）?！窠Y(jié)束：準(zhǔn)備最終的發(fā)布，結(jié)束項(xiàng)目。3.3.4Scrum敏捷開發(fā)3.3圖3-9Scrum過程敏捷開發(fā)3.3每個(gè)過程模式定義了一系列開發(fā)活動(dòng)：●待辦列表（Backlog）：能為用戶提供商業(yè)價(jià)值的項(xiàng)目需求或者特征的優(yōu)先級(jí)列表?！駴_刺（sprint）：是由一系列必須在規(guī)定時(shí)間完成的工作單元組成，這些工作單元是為了實(shí)現(xiàn)待定需求而必需的。在沖刺過程中，不允許進(jìn)行任何變更，以確保短期內(nèi)的穩(wěn)定性●Scrum例會(huì)：團(tuán)隊(duì)每天召開短會(huì)，幫助團(tuán)隊(duì)盡早發(fā)現(xiàn)問題。●演示：向客戶交付軟件增量，由客戶對(duì)其進(jìn)行評(píng)價(jià)。3.3.4Scrum敏捷開發(fā)3.31.產(chǎn)品負(fù)責(zé)人2.ScrumMaster3.Scrum團(tuán)隊(duì)1.產(chǎn)品代辦列表2.發(fā)布燃盡圖3.Sprint代辦列表4.Sprint燃盡圖1.Sprint2.發(fā)布計(jì)劃會(huì)議3.Sprint計(jì)劃會(huì)議4.每日例會(huì)5.Sprint評(píng)審會(huì)6.Sprint回顧會(huì)議Scrum敏捷過程由三個(gè)角色、四個(gè)工件、六個(gè)時(shí)間箱組成。三個(gè)角色四個(gè)工件六個(gè)時(shí)間箱敏捷開發(fā)3.3圖3-10

Scrum中的燃盡圖敏捷開發(fā)3.31998年，BrucePerens和EricRaymond創(chuàng)立了開放源代碼促進(jìn)會(huì)（OpenSourceInitiative），發(fā)起了“開放源代碼”運(yùn)動(dòng)。開源已經(jīng)成為軟件領(lǐng)域技術(shù)、產(chǎn)品創(chuàng)新的一種重要模式，也是驅(qū)動(dòng)信息產(chǎn)業(yè)變革、強(qiáng)化信息產(chǎn)業(yè)基礎(chǔ)的關(guān)鍵要素。在云計(jì)算、大數(shù)據(jù)等新興領(lǐng)域，基于開源模式的技術(shù)創(chuàng)新對(duì)產(chǎn)業(yè)發(fā)展的影響力日益提升。移動(dòng)網(wǎng)絡(luò)、云計(jì)算、大數(shù)據(jù)等技術(shù)的不斷創(chuàng)新，帶動(dòng)了OpenStack、Hadoop等開源軟件的迅速發(fā)展。3.4.1開源軟件的發(fā)展3.4開源軟件針對(duì)開源軟件開發(fā)的特點(diǎn)，Raymond提出兩種開源軟件開發(fā)模型的概念。一種是在每個(gè)軟件版本之中源代碼均可以獲得，但是能夠開發(fā)不同版本代碼的人員僅限于項(xiàng)目開發(fā)組內(nèi)部。另一種是指通過Internet來組織代碼開發(fā)，它允許有很多底層的變化，代碼經(jīng)常可以得到修正，對(duì)于來自外部的代碼也來者不拒。大部分的開源開發(fā)屬于第二種模型。開發(fā)者和軟件的使用者構(gòu)成了開源社區(qū)。形成開源社區(qū)的兩個(gè)基本特征是：①社區(qū)成員有一個(gè)共同目標(biāo)，即所要開發(fā)的軟件；②基于這個(gè)共同目標(biāo)，社區(qū)成員遵循一些標(biāo)準(zhǔn)和原則執(zhí)行各自的開發(fā)任務(wù)。3.4.2開源軟件的開發(fā)過程開源軟件3.4開源軟件過程與傳統(tǒng)不開源軟件過程比較有以下不同：需求的確定性設(shè)計(jì)意圖更容易取得團(tuán)隊(duì)認(rèn)可。分散開發(fā)、配置管理嚴(yán)格。積極查找與改進(jìn)缺陷的態(tài)度。代碼實(shí)現(xiàn)與測(cè)試交替進(jìn)行。3.4.2開源軟件的開發(fā)過程開源軟件3.4表3-1軟件過程特性3.5.1軟件過程特性3.5軟件過程的改進(jìn)能力成熟度模型（CMM）是美國卡內(nèi)基·梅隆大學(xué)軟件工程研究所（SEI）在美國國防部資助下建立的，是一組用于改進(jìn)軟件過程的相關(guān)策略。該模型最初是為了提供一種評(píng)價(jià)軟件承接方能力的方法，為大型軟件項(xiàng)目的招投標(biāo)活動(dòng)提供一種全面而客觀的評(píng)審依據(jù)，后來同時(shí)被軟件組織用于改進(jìn)其軟件過程。3.5.2能力成熟度模型軟件過程的改進(jìn)3.5表3-2CMM的五個(gè)等級(jí)軟件過程的改進(jìn)3.5圖3-11IDEAL過程改進(jìn)模型3.5.3IDEAL模型美國卡內(nèi)基·梅隆大學(xué)軟件工程研究所提出了IDEAL過程改進(jìn)模型。軟件過程的改進(jìn)3.53.5.4個(gè)人軟件過程美國卡內(nèi)基·梅隆大學(xué)軟件工程研究所的WattsS.Humphrey主持開發(fā)了個(gè)人軟件過程（PersonalSoftwareProcess,PSP）。個(gè)人軟件過程為基于個(gè)體和小型的群組軟件過程的優(yōu)化提供了具體和有效的途徑，例如如何制訂計(jì)劃、如何控制質(zhì)量、如何與他人相互協(xié)作等，解決了能力成熟度模型和個(gè)體軟件人員之間的問題。軟件過程的改進(jìn)3.5圖3-12PSP過程改進(jìn)模型軟件過程的改進(jìn)3.5總結(jié)軟件生命周期模型

（定義、瀑布、快速原型、增量、螺旋、噴泉）統(tǒng)一過程（RUP）敏捷開發(fā)（敏捷過程與極限編程、微軟過程、開源過程）軟件過程的改進(jìn)（軟件過程的特性、能力成熟度模型）

第4章

理解需求本章學(xué)習(xí)目標(biāo)1.了解有關(guān)需求的基本知識(shí)。2.掌握需求工程的主要活動(dòng)及它們之間的關(guān)系。3.掌握需求獲取主要方法。4.應(yīng)用用例和場(chǎng)景對(duì)需求建模。5.應(yīng)用用戶故事地圖建立項(xiàng)目需求。

需求工程1軟件需求獲取2用例和場(chǎng)景3用戶故事地圖40理解需求Brooks曾描述“構(gòu)建一個(gè)軟件系統(tǒng)最困難的部分是確定構(gòu)建什么，其他部分工作不會(huì)像這部分工作一樣，在出錯(cuò)之后會(huì)如此嚴(yán)重地影響隨后實(shí)現(xiàn)的系統(tǒng)，并且以后修補(bǔ)竟會(huì)如此的困難?！?.1需求工程需求工程的介紹對(duì)軟件工程師來說，理解項(xiàng)目的需求是什么是他們所面臨的最困難的工作之一。很多時(shí)候客戶也不確切知道自己需要的是什么。他們能夠接受在軟件開發(fā)過程中需求的不斷變化：有些是由溝通引起的，有些是外部干預(yù)者強(qiáng)加的，還有一些是客戶隨著項(xiàng)目演進(jìn)不斷提高對(duì)系統(tǒng)需求的認(rèn)識(shí)所導(dǎo)致的。需求工程（RequirementsEngineering，簡(jiǎn)稱RE）不能清晰地解決上述所有問題，但是項(xiàng)目總要有一個(gè)起始點(diǎn)，可以把需求工程理解為解決上述問題的一個(gè)較為可靠的途徑。4.1需求工程需求工程劃分為五個(gè)獨(dú)立的階段：（1）需求獲取階段需求獲取指通過與各利益相關(guān)者交流、觀察現(xiàn)有系統(tǒng)以及對(duì)任務(wù)進(jìn)行探討，從而捕獲、導(dǎo)出和不斷修訂用戶的需求的過程。在需求獲取階段，可以確定的一些利益相關(guān)者有：最終用戶、軟件工程師、產(chǎn)品工程師、業(yè)務(wù)運(yùn)行管理人員、產(chǎn)品管理人員、市場(chǎng)銷售人員、支持和維護(hù)工程師等。4.1需求工程需求工程劃分為五個(gè)獨(dú)立的階段：（1）需求獲取階段下列因素導(dǎo)致了導(dǎo)出需求的困難：①范圍：系統(tǒng)的邊界不清楚、或是客戶（用戶）說明中帶有不必要的技術(shù)細(xì)節(jié)，混淆而不是澄清系統(tǒng)的整體目標(biāo)。②理解：客戶（用戶）并不能完全確定需要什么。③易變：需求會(huì)隨著時(shí)間發(fā)生變化。在給定有限資源情況下，客戶或者用戶可能提出過高的要求，利益相關(guān)者也可能提出了相互沖突的需求，并強(qiáng)調(diào)他們各自要求的重要性。需求工程師必須通過協(xié)商過程來調(diào)節(jié)這些沖突。4.1需求工程需求工程劃分為五個(gè)獨(dú)立的階段：（2）需求分析階段需求分析是通過前面階段全面的需求獲取后，對(duì)需求進(jìn)行的整理、規(guī)范和分析，用以說明軟件的功能、特征和信息等各個(gè)方面。該階段的任務(wù)主要集中于得到一個(gè)精確的需求模型。4.1需求工程需求工程劃分為五個(gè)獨(dú)立的階段：（3）需求定義階段需求定義是指在對(duì)所要開發(fā)的產(chǎn)品達(dá)成共識(shí)后，形成一份需求的一致性定義，也就是需求規(guī)格說明。如：IEEE的需求規(guī)格說明書模板。4.1需求工程需求工程劃分為五個(gè)獨(dú)立的階段：（4）需求確認(rèn)階段需求確認(rèn)主要是就需求定義和利益相關(guān)者進(jìn)行溝通，并獲得利益相關(guān)者的認(rèn)可。在需求確認(rèn)階段需要做到以下幾點(diǎn)：①軟件需求規(guī)格說明正確描述了預(yù)期的滿足各方需求的系統(tǒng)能力和特征。②從系統(tǒng)需求、業(yè)務(wù)規(guī)則或其他來源中正確地推導(dǎo)出軟件需求。③需求是完整的、高質(zhì)量的。④需求的表述在所有地方都是一致的。⑤需求為繼續(xù)進(jìn)行產(chǎn)品設(shè)計(jì)和構(gòu)造提供了充分的基礎(chǔ)。⑥可以預(yù)先設(shè)計(jì)一些需求確認(rèn)檢查表來檢查每項(xiàng)需求是否是有用的。4.1需求工程需求工程劃分為五個(gè)獨(dú)立的階段：（5）需求跟蹤和變更控制階段需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對(duì)應(yīng)關(guān)系，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)，建立與維護(hù)“需求——設(shè)計(jì)——編程——測(cè)試”等后續(xù)工作之間的一致性，確保所有工作成果符合用戶需求。4.2軟件需求獲取需求提取是發(fā)現(xiàn)用戶真實(shí)需要的過程，也稱需求捕獲。軟件需求提取可以分成兩個(gè)步驟：理解應(yīng)用領(lǐng)域和建立商業(yè)過程模型。例如：開發(fā)一個(gè)移動(dòng)終端的實(shí)驗(yàn)室監(jiān)管系統(tǒng)可以使用UML中的用例（UseCase）圖、用例描述、活動(dòng)圖等來對(duì)業(yè)務(wù)過程建模。4.2.1需求獲取方式4.2軟件需求獲取軟件需求的獲取方式主要有以下幾種：1.直接與用戶訪談和組織會(huì)談2.用戶工作環(huán)境體驗(yàn)和資料采集3.潛在用戶調(diào)查報(bào)告4.市場(chǎng)相關(guān)產(chǎn)品調(diào)研5.快速原型方法4.2軟件需求獲取我們對(duì)系統(tǒng)建立的初始理解可以開始于對(duì)項(xiàng)目所處應(yīng)用領(lǐng)域的了解。利用術(shù)語表完成對(duì)該領(lǐng)域中應(yīng)用技術(shù)詞匯的列表解釋。例如：建立一個(gè)智慧教室系統(tǒng)智慧教室（SmartClassroom）的研究始于歐洲。從2005年英國雷丁大學(xué)研究智慧教室的學(xué)生交互行為開始，針對(duì)智慧教室的研究正式進(jìn)入大眾的視野。4.2.2應(yīng)用領(lǐng)域理解4.2軟件需求獲取智慧教室主要是指借助互聯(lián)網(wǎng)技術(shù)、智能技術(shù)等構(gòu)建起來的新型教室。智慧教室旨在為教學(xué)活動(dòng)提供人性化、智能化的互動(dòng)空間；通過物理空間與數(shù)字空間的結(jié)合，本地與遠(yuǎn)程的結(jié)合，改善人與學(xué)習(xí)環(huán)境的關(guān)系，在學(xué)習(xí)空間實(shí)現(xiàn)人與環(huán)境的自然交互，促進(jìn)個(gè)性化學(xué)習(xí)、開放式學(xué)習(xí)和泛在學(xué)習(xí)。該類新型教室通過各類智能裝備的輔助更好地呈現(xiàn)教學(xué)內(nèi)容、便利獲取多樣化學(xué)習(xí)資源、促進(jìn)在課堂上展開多重交互，實(shí)現(xiàn)情境感知與環(huán)境管理功能的自動(dòng)調(diào)節(jié)。4.2.2應(yīng)用領(lǐng)域理解4.2軟件需求獲?。?）提供圖像識(shí)別系統(tǒng)，可以實(shí)現(xiàn)人臉考勤、用戶行為分析、用戶情感分析等。（2）提供物聯(lián)設(shè)備系統(tǒng)，可以實(shí)時(shí)監(jiān)控教室溫度、濕度等環(huán)境變化，并自動(dòng)做出調(diào)整；能夠自動(dòng)控制教室設(shè)備。（3）提供互動(dòng)交互系統(tǒng)，通過智能錄課將線下課堂與云課堂結(jié)合，支持云端回看，同時(shí)配有電子白板和電子書包等?，F(xiàn)有的智慧教室的主要功能有：4.2軟件需求獲取表4-1智慧教室實(shí)例初始術(shù)語表術(shù)語解釋考勤系統(tǒng)考勤系統(tǒng)是指一套管理出勤記錄等相關(guān)情況的管理系統(tǒng)人臉考勤通過教室攝像頭記錄識(shí)別人臉信息完成考勤用戶行為分析學(xué)生課堂情緒與行為的檢測(cè)，包括對(duì)學(xué)生考勤、情緒、低頭及交頭接耳行為等進(jìn)行識(shí)別物聯(lián)教室實(shí)時(shí)監(jiān)控教室溫度、濕度等環(huán)境變化，并自動(dòng)做出調(diào)整，能夠自動(dòng)控制教室設(shè)備智能錄課自動(dòng)錄制課程并上傳到云端供學(xué)生課后查看云課堂基于云計(jì)算技術(shù)的一種高效、便捷、實(shí)時(shí)互動(dòng)的遠(yuǎn)程教學(xué)課堂形式電子白板顯示上課內(nèi)容，保存板書供學(xué)生課后學(xué)習(xí)電子書包利用信息化設(shè)備進(jìn)行教學(xué)的便攜式終端4.2軟件需求獲取圖4-1智慧教室系統(tǒng)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)4.2.3應(yīng)用實(shí)例需求獲取智慧教室管理系統(tǒng)人臉考勤業(yè)務(wù)主要流程：（1）生物信息采集用智能終端采集人臉照片，并上傳到后臺(tái)系統(tǒng)中，由教師確認(rèn)照片為學(xué)生本人無誤后，交由后臺(tái)識(shí)別軟件識(shí)別生成人臉信息庫。4.2軟件需求獲取4.2.3應(yīng)用實(shí)例需求獲取（2）考勤學(xué)生在教室就坐后，由教師提醒學(xué)生抬頭，并向智慧教室終端發(fā)送簽到指令，啟動(dòng)考勤服務(wù)。通過教室的攝像頭采集教室里的學(xué)生圖像，通過網(wǎng)絡(luò)發(fā)送給云端服務(wù)軟件進(jìn)行識(shí)別，并將識(shí)別結(jié)果和人臉信息庫中的信息進(jìn)行匹配比對(duì)，若相似度大于設(shè)定的某個(gè)閾值，則考勤成功，反之則考勤失敗，暫記作缺勤處理。在上課期間，考勤系統(tǒng)持續(xù)工作，抓拍學(xué)生人臉圖像進(jìn)行比對(duì)，對(duì)缺勤記錄進(jìn)行修正。下課前，由老師關(guān)閉考勤服務(wù)。（3）統(tǒng)計(jì)結(jié)果考勤后，統(tǒng)計(jì)應(yīng)到學(xué)生數(shù)和實(shí)到學(xué)生數(shù)，并將對(duì)接的教務(wù)系統(tǒng)中請(qǐng)假的學(xué)生作標(biāo)注，最終得到本次的考勤結(jié)果。4.2軟件需求獲取4.2.3應(yīng)用實(shí)例需求獲?。?）人臉考勤時(shí)的特殊情況①錄入：錄入時(shí)學(xué)生可能會(huì)誤操作上傳其他人臉的照片，所以需要教師確認(rèn)照片是學(xué)生本人無誤后再交由后臺(tái)處理。②考勤：考勤時(shí)學(xué)生可能低著頭未被攝像頭采集到人臉信息，所以需要學(xué)生主動(dòng)抬起頭，或者在上課期間，多次補(bǔ)充人臉信息采集。③統(tǒng)計(jì)：可能存在學(xué)生請(qǐng)假，但未在教務(wù)系統(tǒng)上申請(qǐng)的情況，所以要提供可以修改考勤結(jié)果的途徑。④可能還有其他的異常情況會(huì)產(chǎn)生，需要在多次溝通后逐步調(diào)整需求。用例圖描述的是參與者所理解的系統(tǒng)功能，幫助人們以一種可視化的方式理解系統(tǒng)的功能需求，講述了最終用戶如何在一個(gè)特定環(huán)境下和系統(tǒng)交互。用例圖有四個(gè)部分：用例（UseCase）、參與者（Actor）、系統(tǒng)邊界、關(guān)系。（1）用例是參與者可以感受到的系統(tǒng)服務(wù)或功能單元。（2）參與者是與系統(tǒng)交互的人或物，是在將要說明的功能和行為環(huán)境內(nèi)使用系統(tǒng)或產(chǎn)品的外部實(shí)體或角色。參與者可以是人、其他軟件系統(tǒng)、硬件設(shè)備或其他與系統(tǒng)進(jìn)行交互的實(shí)體。（3）系統(tǒng)邊界指系統(tǒng)與系統(tǒng)之間的界限。把系統(tǒng)邊界以外的同系統(tǒng)相關(guān)聯(lián)的其他部分稱為系統(tǒng)環(huán)境。4.3用例和場(chǎng)景4.3.1UML用例和場(chǎng)景4.3用例和場(chǎng)景4.3.1UML用例和場(chǎng)景（4）在用例圖中表示的關(guān)系有四種：關(guān)聯(lián)、泛化、包含和擴(kuò)展。①關(guān)聯(lián)關(guān)系圖4-2用例圖中的關(guān)聯(lián)關(guān)系②泛化關(guān)系圖4-3父用例和子用例的關(guān)系圖4-4參與者之間存在泛化關(guān)系4.3用例和場(chǎng)景4.3.1UML用例和場(chǎng)景（4）在用例圖中表示的關(guān)系有四種：關(guān)聯(lián)、泛化、包含和擴(kuò)展。③包含關(guān)系圖4-5用例之間包含關(guān)系示意圖④擴(kuò)展關(guān)系圖4-6用例之間擴(kuò)展關(guān)系4.3用例和場(chǎng)景4.3.1UML用例和場(chǎng)景在用例圖中，場(chǎng)景通常被定義為特定用例的一個(gè)或多個(gè)實(shí)例，用以描述系統(tǒng)如何與外部參與者交互以實(shí)現(xiàn)特定目標(biāo)或功能。場(chǎng)景描述了參與者如何與系統(tǒng)交互，觸發(fā)特定用例，以及系統(tǒng)對(duì)這些觸發(fā)的響應(yīng)。用例和場(chǎng)景之間的區(qū)別在于用例提供了整個(gè)功能的一般描述，而場(chǎng)景是用例的特定實(shí)例，就如對(duì)象是類的一個(gè)實(shí)例。場(chǎng)景的定義應(yīng)簡(jiǎn)潔明了，利益相關(guān)者通過場(chǎng)景可以更好地理解系統(tǒng)的功能和行為。通過建立特定場(chǎng)景可以進(jìn)一步提取需求。4.3.2應(yīng)用實(shí)例業(yè)務(wù)模型業(yè)務(wù)模型是對(duì)商業(yè)過程的描述，可以通過訪談，結(jié)合調(diào)查問卷、檢查業(yè)務(wù)上使用的各種表格以及對(duì)用戶直接觀察等方法來獲取業(yè)務(wù)模型信息。4.3用例和場(chǎng)景4.3.2應(yīng)用實(shí)例業(yè)務(wù)模型（1）初始系統(tǒng)用例智慧教室的人臉考勤業(yè)務(wù)模型概述為：學(xué)生在智慧教室后端上傳學(xué)生人臉照片，并由教師審核通過后存入人臉信息庫。上課時(shí)，教師通過智慧教室終端發(fā)送考勤指令，教室攝像頭采集學(xué)生人臉信息，交由后臺(tái)處理并將識(shí)別結(jié)果和人臉信息庫中的信息進(jìn)行匹配比對(duì)，若存在相似度大于閾值的人臉信息，則考勤成功；反之則考勤失敗，先計(jì)成缺課處理。將所有教室里的學(xué)生進(jìn)行考勤后，統(tǒng)計(jì)應(yīng)到學(xué)生數(shù)和實(shí)到學(xué)生數(shù)，減去對(duì)接的教務(wù)系統(tǒng)中已請(qǐng)假的學(xué)生，最終生成本次的考勤結(jié)果，并記錄在數(shù)據(jù)庫中。4.3用例和場(chǎng)景4.3.2應(yīng)用實(shí)例業(yè)務(wù)模型圖4-7系統(tǒng)初始用例圖初始需求時(shí)，由于對(duì)一些具體的業(yè)務(wù)流程還不清楚，在用例描述中可以不記錄詳細(xì)的操作步驟。表4-2課堂管理用例描述用例名稱課堂管理用例描述對(duì)智慧教室上課時(shí)系統(tǒng)進(jìn)行操作與管理參與者教師與學(xué)生4.3用例和場(chǎng)景4.3.2應(yīng)用實(shí)例業(yè)務(wù)模型表4-3課程管理用例描述用例名稱課程管理用例描述對(duì)課程信息進(jìn)行管理，如添加、修改、刪除課程信息、課程信息發(fā)布、教學(xué)班維護(hù)等操作參與者教師4.3用例和場(chǎng)景圖4-7系統(tǒng)初始用例圖4.3.2應(yīng)用實(shí)例業(yè)務(wù)模型表4-4考勤管理用例描述用例名稱考勤管理用例描述對(duì)考勤情況進(jìn)行管理，如添加、修改、刪除考勤記錄等操作參與者教師、學(xué)生4.3用例和場(chǎng)景圖4-7系統(tǒng)初始用例圖4.3.2應(yīng)用實(shí)例業(yè)務(wù)模型表4-5教室管理用例描述用例名稱教室管理用例描述對(duì)上課教室管理，如教室基本信息維護(hù)，教室申請(qǐng)等操作參與者教師、樓管4.3用例和場(chǎng)景圖4-7系統(tǒng)初始用例圖4.3.2應(yīng)用實(shí)例業(yè)務(wù)模型表4-6設(shè)備管理用例描述用例名稱設(shè)備管理用例描述對(duì)智慧教室的設(shè)備進(jìn)行管理，如設(shè)備信息錄入，設(shè)備分配等操作參與者系統(tǒng)管理員4.3用例和場(chǎng)景圖4-7系統(tǒng)初始用例圖4.3.2應(yīng)用實(shí)例業(yè)務(wù)模型表4-7用戶管理用例描述用例名稱用戶管理用例描述對(duì)智慧教室系統(tǒng)的用戶進(jìn)行管理，如添加教師、添加學(xué)生等操作參與者系統(tǒng)管理員4.3用例和場(chǎng)景圖4-7系統(tǒng)初始用例圖（2）用例迭代需求獲取是一個(gè)迭代的過程，隨著需求獲取工作的深入展開，應(yīng)逐步細(xì)化用例和用例描述。4.3用例和場(chǎng)景4.3用例和場(chǎng)景表4-8人臉考勤用例描述用例名稱人臉考勤用例描述系統(tǒng)對(duì)學(xué)生人臉信息進(jìn)行獲取與驗(yàn)證參與者教師基本路徑1.教師發(fā)出考勤指令（1）教師選擇課程的人臉考勤選項(xiàng)（2）發(fā)出考勤指令（3）相關(guān)設(shè)備開始工作2.收集學(xué)生人臉信息并識(shí)別（1）智慧教室攝像頭采集教室內(nèi)照片（2）攝像頭識(shí)別出學(xué)生人臉交給后臺(tái)處理（3）后臺(tái)第三方圖像處理軟件處理人臉照片（4）將處理的結(jié)果與已有的人臉信息庫比對(duì)（5）比對(duì)結(jié)果相似度大于90%為考勤成功（6）比對(duì)結(jié)果相似度小于90%為考勤失敗3.對(duì)已請(qǐng)假的學(xué)生做處理（1）調(diào)用考勤管理用例中已請(qǐng)假的學(xué)生信息（2）將請(qǐng)假的學(xué)生作請(qǐng)假處理4.生成考勤結(jié)果并儲(chǔ)存（1）將考勤成功、缺勤和請(qǐng)假的學(xué)生標(biāo)記（2）將標(biāo)記后的結(jié)果存入數(shù)據(jù)庫異常路徑1.學(xué)生在教室但考勤失敗，到教師機(jī)專用考勤攝像頭補(bǔ)錄入或者手動(dòng)考勤2.學(xué)生已請(qǐng)假，但是未在教務(wù)系統(tǒng)申請(qǐng)圖4-8課堂管理用例圖4.3用例和場(chǎng)景表4-9AI視頻錄課用例描述用例名稱AI視頻錄課用例描述AI智能錄課，并上傳云端供學(xué)生課后復(fù)習(xí)參與者教師和學(xué)生基本路徑1.教師在智慧教室終端點(diǎn)擊上課按鈕2.系統(tǒng)提示開始上課3.系統(tǒng)自動(dòng)錄制上課內(nèi)容4.將錄制的內(nèi)容整理后系統(tǒng)自動(dòng)上傳到智慧教室云課堂5.學(xué)生在智慧教室云課堂查看課程內(nèi)容異常路徑1.未在規(guī)定時(shí)間內(nèi)上課2.未點(diǎn)擊上課按鈕圖4-8課堂管理用例圖4.3用例和場(chǎng)景表4-10智慧白板應(yīng)用用例描述用例名稱智慧白板應(yīng)用用例描述智慧白板記錄上課板書，并上傳云端供學(xué)生課后復(fù)習(xí)查看參與者教師與學(xué)生基本路徑1.教師在智慧教室終端點(diǎn)擊上課按鈕2.系統(tǒng)提示開始上課3.系統(tǒng)自動(dòng)記錄白板內(nèi)容4.系統(tǒng)將記錄的內(nèi)容整理后自動(dòng)上傳到智慧教室云課堂5.學(xué)生在智慧教室云課堂查看課程內(nèi)容異常路徑1.未在規(guī)定時(shí)間內(nèi)上課2.未點(diǎn)擊上課按鈕圖4-8課堂管理用例圖4.3用例和場(chǎng)景表4-11智能環(huán)境監(jiān)控用例描述用例名稱智能環(huán)境監(jiān)控用例描述智慧教室系統(tǒng)自動(dòng)監(jiān)控教室溫濕度環(huán)境情況并做出調(diào)節(jié)參與者智慧教室系統(tǒng)基本路徑1.教師在智慧教室終端點(diǎn)擊上課按鈕2.系統(tǒng)提示開始上課3.教室系統(tǒng)智能環(huán)境監(jiān)控開始工作4.環(huán)境監(jiān)控系統(tǒng)記錄監(jiān)控?cái)?shù)據(jù)5.若監(jiān)控?cái)?shù)據(jù)發(fā)現(xiàn)異常，自動(dòng)提醒設(shè)備做出調(diào)節(jié)異常路徑1.未在規(guī)定時(shí)間內(nèi)上課2.未點(diǎn)擊上課按鈕圖4-8課堂管理用例圖4.3用例和場(chǎng)景表4-12課程信息維護(hù)用例描述圖4-9課程管理用例圖用例名稱課程信息維護(hù)用例描述教師對(duì)課程信息進(jìn)行管理參與者教師基本路徑1.在課程管理菜單中選擇課程信息管理選項(xiàng)2.選擇增加、刪除、修改、查詢課程信息操作3.輸入相關(guān)信息并確認(rèn)課程主要信息：課程號(hào)、課程名稱、課程簡(jiǎn)介、課時(shí)、學(xué)分4.系統(tǒng)將相關(guān)數(shù)據(jù)保存到數(shù)據(jù)庫中4.3用例和場(chǎng)景表4-13課程發(fā)布用例描述用例名稱課程發(fā)布用例描述教師發(fā)布課程參與者教師基本路徑1.在課程管理菜單中選擇要發(fā)布的課程選項(xiàng)2.選擇可以看到課程發(fā)布的對(duì)象3.單擊發(fā)布按鈕4.系統(tǒng)提示是否確認(rèn)發(fā)布5.確認(rèn)后，系統(tǒng)顯示發(fā)布成功圖4-9課程管理用例圖4.3用例和場(chǎng)景表4-14教學(xué)班維護(hù)用例描述用例名稱教學(xué)班維護(hù)用例描述教師對(duì)教學(xué)班進(jìn)行管理參與者教師基本路徑1.在課程管理菜單中選擇教學(xué)班管理選項(xiàng)2.選擇增加、刪除、修改、查詢教學(xué)班操作3.輸入相關(guān)信息并確認(rèn)教學(xué)班主要信息：教學(xué)班編號(hào)、教學(xué)班名稱、教學(xué)班簡(jiǎn)介、人數(shù)、所屬學(xué)院、學(xué)生名單4.系統(tǒng)將相關(guān)數(shù)據(jù)保存到數(shù)據(jù)庫中圖4-9課程管理用例圖4.3用例和場(chǎng)景表4-15考勤結(jié)果修改用例描述圖4-10考勤管理用例圖用例名稱考勤結(jié)果修改用例描述教師修改錯(cuò)誤的考勤結(jié)果參與者教師基本路徑1.在考勤管理菜單中選擇考勤結(jié)果修改選項(xiàng)2.輸入學(xué)生學(xué)號(hào)3.選擇考勤時(shí)間4.輸入正確的考勤結(jié)果5.單擊提交按鈕，系統(tǒng)顯示修改考勤結(jié)果成功4.3用例和場(chǎng)景表4-16考勤結(jié)果申訴用例描述用例名稱考勤結(jié)果申訴用例描述學(xué)生申訴錯(cuò)誤的考勤結(jié)果參與者學(xué)生基本路徑1.在考勤管理菜單中選擇考勤結(jié)果申訴選項(xiàng)2.輸入學(xué)生學(xué)號(hào)3.選擇考勤時(shí)間4.輸入正確的考勤結(jié)果5.單擊申訴按鈕，系統(tǒng)顯示考勤結(jié)果申訴提交成功擴(kuò)展路徑1.學(xué)生申訴不予通過圖4-10考勤管理用例圖4.3用例和場(chǎng)景表4-17請(qǐng)假申請(qǐng)用例描述用例名稱請(qǐng)假申請(qǐng)用例描述學(xué)生在智慧教室系統(tǒng)中提交請(qǐng)假申請(qǐng)參與者學(xué)生基本路徑1.在考勤管理菜單中選擇請(qǐng)假申請(qǐng)選項(xiàng)2.輸入學(xué)生學(xué)號(hào)3.選擇請(qǐng)假時(shí)間4.輸入請(qǐng)假原因5.單擊申請(qǐng)請(qǐng)假按鈕，系統(tǒng)顯示申請(qǐng)請(qǐng)假提交成功擴(kuò)展路徑1.不在該課程請(qǐng)假時(shí)間范圍內(nèi)，請(qǐng)假失敗圖4-10考勤管理用例圖4.3用例和場(chǎng)景表4-18請(qǐng)假管理用例描述用例名稱請(qǐng)假管理用例描述教師在智慧教室系統(tǒng)中審批學(xué)生請(qǐng)假信息參與者教師基本路徑1.在考勤管理菜單中選擇請(qǐng)假管理選項(xiàng)2.選擇請(qǐng)假學(xué)生3.系統(tǒng)顯示請(qǐng)假原因和請(qǐng)假時(shí)間4.單擊同意按鈕，系統(tǒng)顯示該學(xué)生請(qǐng)假成功，或者單擊不同意按鈕，系統(tǒng)顯示該學(xué)生請(qǐng)假不成功圖4-10考勤管理用例圖4.3用例和場(chǎng)景表4-19教室信息管理用例描述圖4-11教室管理用例圖用例名稱教室信息管理用例描述樓管對(duì)教室信息進(jìn)行管理參與者樓管基本路徑1.在教室管理菜單中選擇教室信息管理選項(xiàng)2.選擇增加、刪除、修改、查詢教室信息操作3.輸入相關(guān)信息并確認(rèn)教室信息包括：教室編號(hào)、教室位置、教室類型、座位數(shù)量、教室用途4.系統(tǒng)將相關(guān)數(shù)據(jù)保存到數(shù)據(jù)庫中4.3用例和場(chǎng)景表4-20教室使用申請(qǐng)用例描述用例名稱教室使用申請(qǐng)用例描述樓管與教師對(duì)智慧教室使用申請(qǐng)進(jìn)行管理參與者樓管與教師基本路徑1.教師在教室管理菜單中選擇使用申請(qǐng)選項(xiàng)2.選擇增加、刪除、修改、查詢操作3.教師輸入相關(guān)申請(qǐng)信息并提交申請(qǐng)管理信息包括：申請(qǐng)時(shí)間、教室編號(hào)、申請(qǐng)用途、申請(qǐng)人編號(hào)4.樓管對(duì)教室申請(qǐng)信息進(jìn)行確認(rèn)5.系統(tǒng)將相關(guān)數(shù)據(jù)保存到數(shù)據(jù)庫中圖4-11教室管理用例圖4.3用例和場(chǎng)景表4-21設(shè)備登記用例描述圖4-12設(shè)備管理詳細(xì)用例圖用例名稱設(shè)備登記用例描述系統(tǒng)管理員登記新設(shè)備參與者系統(tǒng)管理員基本路徑1.在設(shè)備管理菜單中選擇設(shè)備登記選項(xiàng)2.選擇需要登記的設(shè)備3.輸入相關(guān)登記信息并點(diǎn)擊登記登記信息包括：設(shè)備名稱、設(shè)備型號(hào)、生產(chǎn)廠商、產(chǎn)品序列號(hào)、登記的時(shí)間4.相關(guān)信息保存到數(shù)據(jù)庫中4.3用例和場(chǎng)景表4-22設(shè)備分配用例描述用例名稱設(shè)備分配用例描述系統(tǒng)管理員分配設(shè)備到智慧教室參與者系統(tǒng)管理員基本路徑1.在設(shè)備管理菜單中選擇設(shè)備分配選項(xiàng)2.選擇需要分配的設(shè)備3.選擇需要分配到的教室4.確認(rèn)后點(diǎn)擊分配按鈕5.保存到數(shù)據(jù)庫中異常路徑1.設(shè)備無法分配圖4-12設(shè)備管理詳細(xì)用例圖4.3用例和場(chǎng)景表4-23用戶信息管理用例描述圖4-13用戶管理用例圖用例名稱用戶信息管理用例描述系統(tǒng)管理員管理用戶信息參與者系統(tǒng)管理員基本路徑1.在用戶管理菜單中選擇用戶信息管理選項(xiàng)2.選擇增加、刪除、修改、查詢課程信息操作3.輸入相關(guān)信息并確認(rèn)教師信息包括：教師號(hào)、姓名、性別、密碼、手機(jī)、頭像學(xué)生信息包括：學(xué)號(hào)、姓名、性別、密碼、班級(jí)、頭像、手機(jī)號(hào)樓管信息包括：樓管賬號(hào)、姓名、性別、密碼、所處大樓、手機(jī)號(hào)其他人員信息包括：編號(hào)、姓名、性別、密碼、手機(jī)4.系統(tǒng)將相關(guān)數(shù)據(jù)保存到數(shù)據(jù)庫中4.3用例和場(chǎng)景表4-24用戶權(quán)限管理用例描述用例名稱用戶權(quán)限管理用例描述系統(tǒng)管理員修改指定的用戶權(quán)限參與者系統(tǒng)管理員基本路徑1.在用戶管理菜單中選中指定用戶2.點(diǎn)擊用戶權(quán)限管理按鈕3.對(duì)用戶權(quán)限進(jìn)行增、刪、改操作4.單擊保存按鈕5.系統(tǒng)提示是否確認(rèn)保存6.確認(rèn)后，系統(tǒng)顯示保存成功圖4-13用戶管理用例圖4.4用戶故事地圖用戶故事（userstory）是從用戶角度來描述用戶渴望得到的功能。它是敏捷過程實(shí)踐中的一個(gè)重要環(huán)節(jié)。一個(gè)基本的用戶故事包括三個(gè)要素：角色、活動(dòng)、商業(yè)價(jià)值，其一般描述格式：“作為什么角色，我想要進(jìn)行什么活動(dòng)（想要什么功能），以此來實(shí)現(xiàn)什么商業(yè)價(jià)值?！崩缫粋€(gè)故事可能是：作為學(xué)生可以查看他（她）的考勤記錄，以了解出勤情況。4.4.1用戶故事4.4用戶故事地圖極限創(chuàng)始人之一RonJeffries提出了一個(gè)關(guān)于用戶故事的3C描述：（1）卡片（Card）：用戶故事一般寫在小的記事卡片上。卡片上可能會(huì)寫上故事的簡(jiǎn)短描述，工作量估算等。（2）交談（Conversation）：用戶故事背后的細(xì)節(jié)來源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通。（3）確認(rèn)（Confirmation）：通過驗(yàn)收測(cè)試確認(rèn)用戶故事被正確完成。用戶故事通常由客戶團(tuán)隊(duì)而不是開發(fā)人員編寫，每個(gè)客戶團(tuán)隊(duì)?wèi)?yīng)包括確保軟件符合潛在用戶需求的相關(guān)人員。整個(gè)故事使用商業(yè)用語，而不是技術(shù)術(shù)語。客戶團(tuán)隊(duì)與開發(fā)人員共同確定故事細(xì)節(jié)并安排故事的優(yōu)先級(jí)順序。4.4.1用戶故事一個(gè)好的用戶故事應(yīng)該具有6個(gè)特性：1.獨(dú)立性（Independent）2.可協(xié)商性（Negotiable）3.對(duì)用戶或者客戶有價(jià)值（Valuable）4.可估算性（Estimable）5.短?。⊿mall）6.可測(cè)試性（Testable）4.4用戶故事地圖4.4用戶故事地圖用戶故事與用例比較：用戶故事比用例的范圍更小。用例的主要目的是以客戶和開發(fā)人員都可以接受的格式，記錄客戶和開發(fā)團(tuán)隊(duì)之間的協(xié)議。用例描述會(huì)涉及用戶界面和細(xì)節(jié)問題，并在整個(gè)軟件生命周期中都存在。用戶故事主要目的是用于溝通，啟動(dòng)后期的分析和談話，它不涉及更多的細(xì)節(jié)，也不完全對(duì)應(yīng)于用例的主要正常場(chǎng)景，可以被存檔或者拋棄。4.4.1用戶故事4.4用戶故事地圖在編寫合理的用戶故事以后，需要對(duì)項(xiàng)目進(jìn)行估算并制定各類的項(xiàng)目計(jì)劃。如果以用戶故事來描述系統(tǒng)功能，敏捷方法中通常會(huì)選用故事點(diǎn)來估算用戶故事。故事點(diǎn)是對(duì)故事復(fù)雜度、工作量或工期的相對(duì)估算。例如，一個(gè)故事點(diǎn)可以定義為沒有打擾情況下一個(gè)理想工作日所能完成的工作。4.4.2用戶故事估算和計(jì)劃4.4用戶故事地圖4.4.2用戶故事估算和計(jì)劃WidebandDelph估算法用迭代方式進(jìn)行估算：1.所有參與的客戶和開發(fā)人員聚在一起，由客戶隨機(jī)抽取第一個(gè)故事開始，詳細(xì)講解故事直到所有人都清楚了解這個(gè)故事。2.然后每個(gè)開發(fā)人員以團(tuán)隊(duì)共同定義的一個(gè)故事點(diǎn)可以完成的任務(wù)為單位，先寫下自己估算這個(gè)故事的完成時(shí)間。3.接著大家展示自己的估算，然后每個(gè)人解釋為什么估算出這個(gè)值。4.經(jīng)過討論和再次個(gè)人估算，直到經(jīng)過論證，團(tuán)隊(duì)估算出一個(gè)所有人都認(rèn)可的值，再繼續(xù)下一個(gè)故事的估算。4.4用戶故事地圖4.4.2用戶故事估算和計(jì)劃在估算數(shù)個(gè)故事后，對(duì)估算結(jié)果做三角測(cè)量：在估算一個(gè)故事時(shí)，根據(jù)這個(gè)故事與其他一個(gè)或多個(gè)故事的關(guān)系來估算。假定一個(gè)故事估算為4個(gè)故事點(diǎn)，第二個(gè)故事為2個(gè)故事點(diǎn)，把這兩個(gè)故事放在一起考慮的時(shí)候，程序員都應(yīng)該認(rèn)可4個(gè)故事點(diǎn)的故事大小是2個(gè)故事點(diǎn)的故事的2倍，其他3個(gè)故事點(diǎn)的故事的大小應(yīng)該介于4個(gè)故事點(diǎn)的故事和2個(gè)故事點(diǎn)的故事之間。如果上面的三角測(cè)量的結(jié)果不對(duì)，團(tuán)隊(duì)就應(yīng)該重新估算。4.4用戶故事地圖4.4.3用戶故事地圖JeffPatton提出用戶故事地圖（UserStoryMapping），以結(jié)構(gòu)化的方式來組織用戶故事圖4-14用戶故事地圖舉例4.4用戶故事地圖4.4.3用戶故事地圖圖4-15智慧教室用戶故事地圖的脈絡(luò)5個(gè)主要步驟：（1）產(chǎn)品的定義（2）梳理骨干故事（3）拆分故事（4）確定優(yōu)先級(jí)和發(fā)布計(jì)劃（5）反饋修正故事小結(jié)1.了解有關(guān)需求的基本知識(shí)。2.掌握需求工程的主要活動(dòng)及它們之間的關(guān)系。3.掌握需求獲取主要方法。4.掌握通過用例和場(chǎng)景對(duì)需求建模。5.掌握用戶故事地圖建立項(xiàng)目需求。作業(yè)與思考作業(yè)：1.試對(duì)智慧教室的物聯(lián)設(shè)備做進(jìn)一步探究，了解相關(guān)的應(yīng)用領(lǐng)域

，建立物聯(lián)設(shè)備的術(shù)語表。2.請(qǐng)?jiān)O(shè)計(jì)教材以外的一個(gè)智慧教室的應(yīng)用場(chǎng)景，并對(duì)本節(jié)中的用例加以改進(jìn)。3.請(qǐng)給出“查看考勤結(jié)果”用例描述。4.選取一個(gè)實(shí)例，用用戶故事地圖來建立實(shí)例的二維視圖。思考：1.如何理解“如果產(chǎn)品能以20%的功能滿足80%的人的需求，那么這個(gè)產(chǎn)品就成功了一大步”這句話。它的背后隱含著什么定律或者原則。第5章

需求分析本章學(xué)習(xí)目標(biāo)1.理解需求分析的主要任務(wù)。2.理解不同需求分析方法解決問題的本質(zhì)3.掌握傳統(tǒng)的結(jié)構(gòu)化分析方法。4.掌握面向?qū)ο蟮姆治龇椒ā?.熟練應(yīng)用UML建立需求分析模型。6.了解軟件形式化分析技術(shù)。

面向數(shù)據(jù)流的結(jié)構(gòu)化分析1形式化分析技術(shù)5結(jié)構(gòu)化分析實(shí)例2面向?qū)ο蟮姆治?面向?qū)ο蠓治鰧?shí)例4需求分析的主要任務(wù)在需求工程的起始階段，項(xiàng)目利益相關(guān)者建立起基本的問題需求，定義重要的項(xiàng)目約束條件并描述項(xiàng)目的功能和主要特征。這些信息經(jīng)過各種需求收集活動(dòng)后，在需求導(dǎo)出階段記錄下來。在進(jìn)入需求的精化階段，需求會(huì)得到進(jìn)一步的精煉，并擴(kuò)展為分析模型。創(chuàng)建需求分析模型原則Ariow和Neustadt提出了在創(chuàng)建需求分析模型時(shí)應(yīng)注意的原則：（1）分析模型應(yīng)關(guān)注問題域或業(yè)務(wù)域內(nèi)可見的需求，并注意提高抽象級(jí)別。（2）分析模型的每個(gè)元素都應(yīng)能增加對(duì)軟件需求的整體理解，并提供對(duì)信息域、功能和系統(tǒng)行為域的深入理解。（3）關(guān)于基礎(chǔ)結(jié)構(gòu)和其他非功能的模型應(yīng)推遲到設(shè)計(jì)階段再考慮。（4）應(yīng)最小化整個(gè)系統(tǒng)內(nèi)的關(guān)聯(lián)，減少類和功能間的直接依賴關(guān)系和相互作用。（5）確認(rèn)分析模型為項(xiàng)目所有利益相關(guān)者都能帶來價(jià)值。（6）盡可能保持模型簡(jiǎn)潔。需求建模方法在需求建模過程中，軟件工程具體關(guān)注的焦點(diǎn)是“系統(tǒng)要做什么”，而不是“系統(tǒng)該怎么做”。關(guān)注的主要問題有“在特定的應(yīng)用環(huán)境下，發(fā)生了哪些用戶交互？系統(tǒng)處理哪些對(duì)象？系統(tǒng)必須執(zhí)行什么功能？系統(tǒng)對(duì)外界展示什么行為？系統(tǒng)與外界有哪些接口？受到什么樣的約束？”等。需求建模方法傳統(tǒng)的面向數(shù)據(jù)和面向處理的需求建模方法被稱為結(jié)構(gòu)化分析，其中處理是將數(shù)據(jù)作為獨(dú)立實(shí)體加以轉(zhuǎn)換，表示了數(shù)據(jù)對(duì)象在系統(tǒng)內(nèi)流動(dòng)時(shí)，系統(tǒng)是如何處理和如何轉(zhuǎn)換數(shù)據(jù)。面向?qū)ο蟮男枨蠓治龇椒ǎ瑒t是關(guān)注于識(shí)別和定義類，通過類之間的協(xié)作來響應(yīng)客戶的需求。5.1.1半形式化分析技術(shù)（1）數(shù)據(jù)流圖數(shù)據(jù)流圖有時(shí)也被稱為數(shù)據(jù)流程圖（DataFlowDiagram，簡(jiǎn)稱DFD），是一種便于用戶理解和分析系統(tǒng)數(shù)據(jù)流程的圖形工具。表5-1數(shù)據(jù)流程圖基本符號(hào)5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析在繪制分層數(shù)據(jù)流圖時(shí)應(yīng)注意以下事項(xiàng)：①自頂向下、逐層分解。②數(shù)據(jù)流必須經(jīng)過加工環(huán)節(jié)。③每個(gè)加工必須既有輸入數(shù)據(jù)流，又有輸出數(shù)據(jù)流。④數(shù)據(jù)存儲(chǔ)環(huán)節(jié)一般作為兩個(gè)加工環(huán)節(jié)的界面來安排。⑤適當(dāng)?shù)貫閿?shù)據(jù)流、加工、數(shù)據(jù)存儲(chǔ)、外部實(shí)體命名，名字應(yīng)反映該成分的實(shí)際含義，避免空洞的名字。在繪制分層數(shù)據(jù)流圖時(shí)應(yīng)注意以下事項(xiàng)：⑥編號(hào)。⑦保持?jǐn)?shù)據(jù)守恒。⑧局部數(shù)據(jù)存儲(chǔ)的隱蔽性。⑨保持父圖與子圖平衡。⑩只繪制所描述的系統(tǒng)穩(wěn)定工作情況下的數(shù)據(jù)流圖。?畫數(shù)據(jù)流而不要畫控制流。5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析（2）判定樹和判決表判定樹又稱決策樹（decisiontree），是一種描述加工的圖形工具，適合描述問題處理中具有多個(gè)判斷，并且每個(gè)決策與若干條件有關(guān)，導(dǎo)致不同的結(jié)果。5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析例如有關(guān)退票改簽費(fèi)有如下規(guī)定：

開車前8天（不含）以上退票的，不收取退票費(fèi)；票面乘車站開車時(shí)間前48小時(shí)以上的按票價(jià)5%計(jì)，24小時(shí)以上、不足48小時(shí)的按票價(jià)10%計(jì)，不足24小時(shí)的按票價(jià)20%計(jì)。辦理車票改簽時(shí)，新車票票價(jià)高于原車票的，收取票價(jià)差額。新車票票價(jià)等于原車票，不收取費(fèi)用。新車票票價(jià)低于原車票的，退還差額。5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析圖5-1判定樹表示購票5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析表5-2購買火車票判定表5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析（3）數(shù)據(jù)字典數(shù)據(jù)字典是元數(shù)據(jù)(metadata)的結(jié)構(gòu)化存儲(chǔ)庫，它提供所用數(shù)據(jù)的全面描述。其主要目的是提供一種共同的語言，以幫助軟件項(xiàng)目的涉眾理解數(shù)據(jù)、數(shù)據(jù)的含義以及數(shù)據(jù)與其他數(shù)據(jù)元素的關(guān)系。在結(jié)構(gòu)化分析中，數(shù)據(jù)字典的作用是給數(shù)據(jù)流圖中每個(gè)成分加以定義和說明，數(shù)據(jù)流圖和數(shù)據(jù)字典共同構(gòu)成系統(tǒng)的邏輯模型。5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析1.數(shù)據(jù)項(xiàng)：數(shù)據(jù)流圖中數(shù)據(jù)塊的數(shù)據(jù)結(jié)構(gòu)中的數(shù)據(jù)項(xiàng)說明。數(shù)據(jù)項(xiàng)描述={數(shù)據(jù)項(xiàng)名，數(shù)據(jù)項(xiàng)含義說明，別名，數(shù)據(jù)類型，長度，取值范圍，取值含義，與其他數(shù)據(jù)項(xiàng)的邏輯關(guān)系}2.數(shù)據(jù)結(jié)構(gòu)：數(shù)據(jù)流圖中數(shù)據(jù)塊的數(shù)據(jù)結(jié)構(gòu)說明。數(shù)據(jù)結(jié)構(gòu)描述={數(shù)據(jù)結(jié)構(gòu)名，含義說明，組成：{數(shù)據(jù)項(xiàng)或數(shù)據(jù)結(jié)構(gòu)}}3.數(shù)據(jù)流：數(shù)據(jù)流圖中流線的說明。數(shù)據(jù)流描述={數(shù)據(jù)流名，說明，數(shù)據(jù)流來源，數(shù)據(jù)流去向，組成：{數(shù)據(jù)結(jié)構(gòu)}，平均流量，高峰期流量}4.數(shù)據(jù)存儲(chǔ)：數(shù)據(jù)流圖中數(shù)據(jù)塊的存儲(chǔ)特性說明。數(shù)據(jù)存儲(chǔ)描述={數(shù)據(jù)存儲(chǔ)名，說明，編號(hào)，流入的數(shù)據(jù)流，流出的數(shù)據(jù)流，組成：{數(shù)據(jù)結(jié)構(gòu)}，數(shù)據(jù)量，存取方式}5.處理過程：數(shù)據(jù)流圖中功能塊也就是加工的說明。處理過程描述={處理過程名，說明，輸入：{數(shù)據(jù)流}，輸出：{數(shù)據(jù)流}，處理：{簡(jiǎn)要說明}}5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析5.1.2

Gane和Sarsen結(jié)構(gòu)化系統(tǒng)分析Gane和Sarsen的結(jié)構(gòu)化系統(tǒng)分析方法作為主流的傳統(tǒng)需求分析技術(shù)是以系統(tǒng)中數(shù)據(jù)流動(dòng)為重點(diǎn)，對(duì)數(shù)據(jù)出入系統(tǒng)邊界形態(tài)、系統(tǒng)內(nèi)部處理進(jìn)行研究來分析用戶的要求。其分析過程分為9個(gè)步驟。5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析分析過程分為以下9個(gè)步驟：（1）在需求初步獲取的基礎(chǔ)上運(yùn)用逐步求精的方法畫數(shù)據(jù)流圖，數(shù)據(jù)流圖分層描述。（2）決定軟件系統(tǒng)實(shí)現(xiàn)數(shù)據(jù)流圖中哪些部分。（3）確定數(shù)據(jù)流圖中數(shù)據(jù)流的細(xì)節(jié)。（4）定義數(shù)據(jù)流圖中加工的處理邏輯。（5）定義數(shù)據(jù)流圖中涉及的數(shù)據(jù)存儲(chǔ)。（6）定義滿足項(xiàng)目需要的物理資源。（7）確定項(xiàng)目需要滿足的輸入－輸出規(guī)格說明。（8）確定系統(tǒng)中輸入數(shù)據(jù)、中間計(jì)算結(jié)果、輸出數(shù)據(jù)的大小。（9）根據(jù)步驟（8）中的計(jì)算結(jié)果，確定硬件要求和約束。5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析5.2結(jié)構(gòu)化分析實(shí)例5.2.1逐步求精數(shù)據(jù)流圖智慧教室是一個(gè)較為復(fù)雜的問題，一次性得到一張完整的DFD比較困難，可以按照系統(tǒng)抽象層次結(jié)構(gòu)進(jìn)行逐步求精，并采用分層數(shù)據(jù)流圖表示。圖5-2頂層數(shù)據(jù)流圖圖5-3第一次細(xì)化數(shù)據(jù)流圖5.2結(jié)構(gòu)化分析實(shí)例圖5-4課堂管理細(xì)化數(shù)據(jù)流圖5.2結(jié)構(gòu)化分析實(shí)例圖5-5人臉考勤管理細(xì)化數(shù)據(jù)流圖5.2結(jié)構(gòu)化分析實(shí)例5.2.2定義數(shù)據(jù)字典表5-3人臉考勤管理數(shù)據(jù)字典部分詞條5.2結(jié)構(gòu)化分析實(shí)例5.2.3建造實(shí)體-關(guān)系模型5.2結(jié)構(gòu)化分析實(shí)例面向?qū)ο蠓治?.3.1面向?qū)ο蠓椒ê徒Y(jié)構(gòu)化方法結(jié)構(gòu)化方法求解問題的基本策略是從功能的角度審視問題域。它將應(yīng)用程序看成實(shí)現(xiàn)某些特定任務(wù)的功能模塊。在每個(gè)功能模塊中，用數(shù)據(jù)結(jié)構(gòu)描述待處理數(shù)據(jù)的組織形式，用算法描述具體的操作過程。在面向?qū)ο蟮募夹g(shù)中，對(duì)象由數(shù)據(jù)和操作組成。對(duì)程序設(shè)計(jì)者而言，對(duì)象是一個(gè)具有信息性內(nèi)聚的程序模塊；對(duì)其他用戶而言，對(duì)象是程序提供給他們的服務(wù)，通過知悉對(duì)象接口形式就可以調(diào)用，并不需要了解它們的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)。5.3面向?qū)ο蠓治?.3.2面向?qū)ο蠓治鲋械闹饕夹g(shù)面向?qū)ο蠓治觯∣OA）是一種半形式化的分析技術(shù)。在多種面向?qū)ο蟮能浖こ谭椒ㄖ?，比較有影響的應(yīng)用有Booch、OOSE、OMT，以及后面出現(xiàn)的統(tǒng)一過程等。5.3面向?qū)ο蠓治?.3.2面向?qū)ο蠓治鲋械闹饕夹g(shù)GradyBooch是面向?qū)ο蠓椒ㄗ钤绲某珜?dǎo)者之一。他于1986年提出了“面向?qū)ο蠓治雠c設(shè)計(jì)（OOAD）”。

Booch提出的開發(fā)模型包括邏輯模型、物理模型、靜態(tài)模型和動(dòng)態(tài)模型。①發(fā)現(xiàn)類和對(duì)象，在一定抽象層面標(biāo)識(shí)出類和對(duì)象；②確定類和對(duì)象的語義，將期望的行為賦予對(duì)象類；③標(biāo)識(shí)類和對(duì)象之間的關(guān)系。Booch方法有很強(qiáng)的表達(dá)能力，其迭代和增量的思想對(duì)很多軟件工程開發(fā)設(shè)計(jì)階段的建模提供了重要的指導(dǎo)。5.3面向?qū)ο蠓治鯫MT（ObjectModelingTechnique）方法是由Loomis，Shan和JamesRumbaugh在最先提出的實(shí)體和關(guān)系模型基礎(chǔ)上進(jìn)一步擴(kuò)展了類、行為以及繼承等得來。①對(duì)象模型：表述對(duì)象靜態(tài)的結(jié)構(gòu)以及它們之間的相互作用關(guān)系。②動(dòng)態(tài)模型：描述系統(tǒng)動(dòng)態(tài)的變化特點(diǎn)，包括狀態(tài)和活動(dòng)等。③功能模型：描述與數(shù)據(jù)值的變換有關(guān)的系統(tǒng)特征，不同數(shù)據(jù)值之間在系統(tǒng)內(nèi)的轉(zhuǎn)換，包括處理、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)流等概念。5.3面向?qū)ο蠓治鯦acobson提出了“面向?qū)ο筌浖こ蹋∣OSE）”方法，其核心是用例驅(qū)動(dòng)，建立面向?qū)ο蟮姆治瞿Ｐ秃驮O(shè)計(jì)模型。主要用五種模型來描述系統(tǒng)：①需求模型（Requirementmodel，簡(jiǎn)稱RM）。②分析模型（Analysismodel，AM）。③設(shè)計(jì)模型（Designmodel，簡(jiǎn)稱DM）。④實(shí)現(xiàn)模型（Implementationmodel，IM）。⑤測(cè)試模型（Testingmodel，簡(jiǎn)稱TM）。OOSE的開發(fā)活動(dòng)主要包括分析、構(gòu)造、測(cè)試三個(gè)過程。5.3面向?qū)ο蠓治鼋y(tǒng)一過程使用統(tǒng)一建模語言（UnifiedModelingLanguage，簡(jiǎn)稱UML）來表示要開發(fā)的軟件。UML是面向?qū)ο箝_發(fā)中一種通用的圖形化建模語言?；赨ML建?？梢苑譃殪o態(tài)和動(dòng)態(tài)兩類：基于用例圖、對(duì)象圖以及類圖等創(chuàng)建的模型為靜態(tài)模型，基于狀態(tài)圖、活動(dòng)圖等創(chuàng)建的模型為動(dòng)態(tài)模型。表5-4UML部分語法描述5.3面向?qū)ο蠓治?.3.3面向?qū)ο蟮姆治龇椒ê椭饕襟E面向?qū)ο蠓治龅哪繕?biāo)主要是完成對(duì)求解問題的分析，建立系統(tǒng)的需求分析模型，包括對(duì)象模型、動(dòng)態(tài)模型和功能模型等。（1）對(duì)象模型：對(duì)用例模型進(jìn)行分析，把系統(tǒng)分解成互相協(xié)作的分析類，通過類圖和對(duì)象圖描述對(duì)象、對(duì)象的屬性以及對(duì)象間的關(guān)系。對(duì)象模型是對(duì)系統(tǒng)的靜態(tài)建模。（2）動(dòng)態(tài)模型：描述系統(tǒng)的動(dòng)態(tài)行為，通過順序圖、協(xié)作圖描述對(duì)象的交互，以揭示對(duì)象間如何協(xié)作來完成每個(gè)具體的用例。單個(gè)對(duì)象的狀態(tài)變化、動(dòng)態(tài)行為可以通過狀態(tài)圖來表示。（3）功能模型：描述系統(tǒng)應(yīng)該做什么，最直接地反映了用戶對(duì)目標(biāo)系統(tǒng)的需求。通常功能模型由一組數(shù)據(jù)流圖或一組用例圖組成。5.3面向?qū)ο蠓治?.3.3面向?qū)ο蟮姆治龇椒ê椭饕襟E可以把面向?qū)ο蟮姆治鲞^程分成三個(gè)主要活動(dòng)：用例建模、類建模和動(dòng)態(tài)建模。(1)

用例建模：建立以用例模型為主體的需求模型，提出所有用例的場(chǎng)景，又稱功能建模。(2)類建模：確定類和它們的屬性，以及類間的相互關(guān)系和交互作用。(3)動(dòng)態(tài)建模：確定由每個(gè)類或者子類執(zhí)行的活動(dòng)或?qū)λ鼈冞M(jìn)行的行為。5.3面向?qū)ο蠓治?.3.3面向?qū)ο蟮姆治龇椒ê椭饕襟E面向?qū)ο蠓治?/p>