第1章需求工程導論課件

需求工程

第一章:導論主要內(nèi)容軟件的需求問題需求問題的原因分析需求工程需求工程師1.1軟件需求技術的發(fā)展

——基本技術無需求處理草圖分析需求分析DFD/ERD需求分析面向?qū)ο?.290年代的軟件生產(chǎn)狀況調(diào)查

——StandishGroup1995365家公司的8380個項目成功項目Success：在預計的時間之內(nèi)，在預算的成本之下，完成預期的所有功能問題項目Challenged：已經(jīng)完成，軟件產(chǎn)品能夠正常工作，但在生產(chǎn)中或者超支，或者超期，或者實現(xiàn)的功能不全失敗項目Impaired：因無法進行而被中途撤銷，或者最終產(chǎn)品無法提交使用1.290年代的軟件生產(chǎn)狀況調(diào)查

——StandishGroup1995大公司開發(fā)項目的平均成本是232.2萬美元，中等公司是133.1萬美元，小型公司是43.4萬美元大約31％的項目在完成之前被取消，52.7％的項目成本是原來預算的189%大公司9%按預算交付，小公司16%按預算交付1.290年代的軟件生產(chǎn)狀況調(diào)查

——

影響因素[StandishGroup1995]成功項目的影響要素影響指數(shù)用戶參與15.9％高層管理支持13.9％清晰的需求說明13.0％正確的項目計劃9.6％切合實際的期望8.2％細化的項目里程碑7.7％員工能力7.2％主人翁精神5.3％清晰的目標和前景2.9％努力工作2.4％其他13.9％1.290年代的軟件生產(chǎn)狀況調(diào)查

——

影響因素[StandishGroup1995]問題項目的影響要素影響指數(shù)缺少用戶輸入12.8％不完整的需求說明12.3％需求變化11.8％缺乏高層管理支持7.5％技術能力不足7.0％缺乏資源6.4％不切實際的期望5.9％目標不清晰5.3％不現(xiàn)實的時間要求4.3％新技術的影響3.7％其他23.0％1.290年代的軟件生產(chǎn)狀況調(diào)查

——

影響因素[StandishGroup1995]失敗項目的影響要素影響指數(shù)不完整的需求說明13.1％缺少用戶輸入12.4％缺乏資源10.6％不切實際的期望9.9％缺乏高層管理支持9.3％需求變化8.7％缺乏計劃8.1％額外的無用功能7.5％缺乏IT管理6.2％技術能力不足4.3％其他9.9％1.290年代的軟件生產(chǎn)狀況調(diào)查

——

影響因素[StandishGroup1995]需求因素用戶參與（用戶輸入）高層管理支持清晰的需求說明切合實際的期望清晰的目標和前景需求變化額外的無用功能綜合來看，需求因素對成功項目的影響指數(shù)為53.9％對問題項目的影響指數(shù)為55.6％對失敗項目的影響指數(shù)為60.9％1.290年代的軟件生產(chǎn)狀況調(diào)查

——ESPITI，1996歐洲軟件協(xié)會ESI歐洲軟件過程改進培訓計劃項目ESPITI17個國家的超過3800個組織StandishGroup

199419961998200020042006200820102012成功(%)162726282935323739問題(%)533346495346444143失敗(%)314028231819242118排序2010年度2012年度影響因素指數(shù)影響因素指數(shù)1用戶參與20高層管理支持192高層管理支持15用戶參與183清晰的業(yè)務目標15清晰的業(yè)務目標154情感成熟度（Emotionalmaturity，即項目氛圍）12情感成熟度（Emotionalmaturity，即項目氛圍）125最優(yōu)化(Optimization)11最優(yōu)化(Optimization)116敏捷過程11敏捷過程97項目管理技能6項目管理技能78有技能的員工5有技能的員工59執(zhí)行力3執(zhí)行力410工具與設備2工具與設備11.290年代的軟件生產(chǎn)狀況調(diào)查

——需求問題的典型案例[Bray2002]PROMS（演出權益協(xié)會）,11M￡,1992,未能以常人能理解和檢查的形式表述軟件需求，軟件規(guī)格說明也考慮不周RISP（西薩克斯地區(qū)信息系統(tǒng)計劃）,43M￡,1990,缺少清晰的項目范圍定義TAURUS(倫敦股票交易),75M￡(0.14B￡),1993,未能協(xié)調(diào)不一致的需求LASDS(倫敦救護車服務派遣系統(tǒng)),1992,社會服務領域糟糕的需求分析ATC(空中交通控制系統(tǒng)),0.18B￡,1998-2001,缺乏健壯的需求規(guī)格說明主要內(nèi)容軟件的需求問題需求問題的原因分析應用軟件的模擬特性需求問題的技術原因分析需求工程需求工程師2.1應用軟件的模擬特性

——軟件的三種類型軟件類別純工具型軟件應用型軟件專業(yè)用戶普通用戶評判標準功能的復雜性使用的高效性技術的先進性功能的有用性使用的方便性技術的可行性功能的“模擬”性使用的方便性技術的可行性關注點創(chuàng)新性有效性模擬性示例系統(tǒng)編程環(huán)境DBMSOffice語言翻譯MISEAI2.1應用軟件的模擬特性

——軟件的分析活動2.1應用軟件的模擬特性

——軟件模擬性的實踐調(diào)查對應用型軟件的“模擬”特性理解及應用問題CapersJones[Capers1996]在調(diào)查了幾百個公司之后發(fā)現(xiàn)超過75％的企業(yè)在需求處理環(huán)節(jié)存在不足。2000年Nikula等人在對芬蘭的中小型公司進行需求處理實踐情況評價時發(fā)現(xiàn)[Nikula2000]：在以30分為標準線的情況下，75%的公司竟然在10分以下。Hofmann等人在歐洲的需求工程實踐調(diào)查中發(fā)現(xiàn)僅有約1/3的項目有明確的需求處理過程[Hofmann2001]。Juristo等人在對歐洲的150多名RE實踐者進行調(diào)查后發(fā)現(xiàn)，在需求處理的諸多技術當中，需求獲取和沖突協(xié)商的技術沒有得到充分的應用[Juristo2002]。研究也發(fā)現(xiàn)當軟件生產(chǎn)面臨時間、市場等其他壓力時，漠視“模擬”特性的情況就更為嚴重[Lubars1993，F(xiàn)rancisco2003]2.2需求問題的技術原因分析非技術性和社會性因素組織機構文化、社會背景、商業(yè)目標、利益協(xié)商關注軟件系統(tǒng)和現(xiàn)實之間的互動效應軟件系統(tǒng)環(huán)境的組織機構文化、社會背景和系統(tǒng)涉眾的目標與利益比軟件內(nèi)部的數(shù)據(jù)流與狀態(tài)更應該得到重視解決方案和具體應用環(huán)境相關的不能忽視具體應用環(huán)境中的相關因素，例如組織機構的文化、組織結構的規(guī)范、組織的行業(yè)規(guī)范、組織的社會背景等等單純通過技術的運用來建立一個一致、完整的需求模型是不太可能的面對沖突要能夠分析社會原因和組織機構方面的原因，引導涉眾進行利益協(xié)商2.2需求問題的技術原因分析結構化分析和面向?qū)ο蠓治鼍哂幸欢ǖ南忍烊毕菥幊蹋?gt;設計－>分析設計和編程都有構建高質(zhì)量（健壯性、可維護性、適應性等等）軟件的共同目標，而且使用相同的概念和組織機制保證了從設計到編程的平滑過渡，所以，它們在設計領域的應用也取得了成功但是需求分析除了擁有構建高質(zhì)量軟件的目標之外，還有一個更加重要的目標是理解現(xiàn)實2.2需求問題的技術原因分析以“企業(yè)”為中心的軟件反映了軟件規(guī)模日益擴大一方面提高了需求處理中非技術性和社會性因素的影響比重另一方面也進一步放大了傳統(tǒng)技術在需求處理階段的不適應性2.2需求問題的技術原因分析需求錯誤的高代價性主要內(nèi)容軟件的需求問題需求問題的原因分析需求工程簡介基本活動需求工程與系統(tǒng)工程需求工程師3.1需求工程是軟件工程的一個分支它關注于軟件系統(tǒng)所應予實現(xiàn)的現(xiàn)實世界目標、軟件系統(tǒng)的功能和軟件系統(tǒng)應當遵守的約束同時它也關注以上因素和準確的軟件行為規(guī)格說明之間的聯(lián)系關注以上因素與其隨時間或跨產(chǎn)品族而演化之后的相關因素之間的聯(lián)系3.2需求工程的基本活動3.3需求工程與系統(tǒng)工程前期階段后期階段需求工程與系統(tǒng)工程1981年，BarryBoehm[Boehm1981]發(fā)現(xiàn)項目費用的6％和時間的9-12％被消耗在需求階段。在20年之后，隨著需求工程的發(fā)展，[Hofmann2001]發(fā)現(xiàn)項目對需求工程的投入也加大了許多：項目工作的15.7％和時間的38.6％被用于進行需求工程NASA(U.S.NationalAeronauticsandSpaceAdministration)提供的數(shù)據(jù)顯示[Young2002]：當在需求工程當中投入項目總成本的8-14％時，可以極大的降低項目的超支率。3.4需求工程的特性

——必要性軟件開發(fā)是這樣一個工程問題利用通用的計算機結構，構建一個有用的軟件系統(tǒng)，來滿足人們的某些目的計算機應用于現(xiàn)實世界的廣泛性新的問題和新的解決方案定義問題就是需求工程的任務3.4需求工程的特性

——重要性FrederickBrooks[Brooks1987]“開發(fā)軟件系統(tǒng)最為困難的部分就是準確說明開發(fā)什么。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。同時這也是一旦做錯，將最終會給系統(tǒng)帶來極大損害的部分，并且以后再對它進行修改也極為困難。”容易忽略需求工程重要性的地方問題廣為人知電梯調(diào)度、圖書管理問題小而簡單出錯也無所謂主要內(nèi)容軟件的需求問題需求問題的原因分析需求工程需求工程師現(xiàn)實世界方面與技術方面的橋梁好的需求工程師更應該扮演好涉眾代理的角色，站在涉眾的立場想問題，替涉眾跟蹤和監(jiān)控軟件開發(fā)過程，保護涉眾的利益4.2需求工程師需要具備的技能軟技能交流觀察抽象分析和問題解決（抽象、整合、系統(tǒng)化）寫作關系協(xié)調(diào)與團隊工作需求工程師行為創(chuàng)新？團隊案例分析：法律法規(guī)與利益協(xié)商

深圳手機打車軟件被緊急叫停

2013年05月23日

11:03

深圳特區(qū)報

市交委認為，手機打車軟件部分功能存在安全隱患并違反相關規(guī)定，影響了出租車行業(yè)運價體系和營運秩序，交通主管部門將依法進行監(jiān)管和規(guī)范。出租車企業(yè)負責人表示由于打車軟件功能設置和技術運用不夠成熟，給行業(yè)監(jiān)管帶來了問題，如駕駛員注冊準入缺乏認證、提供加價議價功能、操作方式存在行車安全隱患、投訴爭議處理困難等，影響了出租車行業(yè)運價體系和營運秩序。案例分析：文化背景

Twitter工程師眼中的新浪微博

Twitter之簡約vs.新浪微博之豐富新浪微博……各式各樣的新功能馬不停蹄地上線(微刊，微人脈，微盤，微視頻，總之各種微)。新浪將‘微博’極大地‘豐富’了：微博，長微博，即時聊天，看新聞，參與熱點討論，交朋友，社交，看公知們爭奇斗艷等等。在Twitter工程師看來，新浪微博的整體設計原則卻并不很清晰：改版很多次，幾百個功能五花八門。相形之下，Twitter推崇的是‘至簡’原則，(Simplify是公司的10個核心價值之一)……Twitter無意在附加功能上做文章，而是希望把大家的注意力都引向正中間的推文上，這是信息實質(zhì)的所在……從誕生到現(xiàn)在，Twitter一直遵循一個產(chǎn)品邏輯，堅定地將自己定位成一個移動端信息廣播平臺……滿足大家伙兒的表達欲和分享欲，通過碎片化信息告訴世人“Whatareyoudoing?”(你在做什么)。新浪社交裝酷，Twitter專注新聞新浪在微博平臺里‘人為’加入了一些話題歸納和引導，比如“熱門微博”和“風云榜”等等。抓住我們國人喜歡圍觀和跟風的心理，新浪微博通過極易操作的轉(zhuǎn)發(fā)+評論等功能引導大家參與討論，置身事內(nèi)……成就了自己的‘微論壇’基因“新浪微博在設計上……花了很多功夫讓大家注意到一條微博，但并沒有花太多心思去組織信息，不能引導大家以一種更客觀的方式查看信息本身”。如此一來，大家傾向于膚淺地參與一些沒有實質(zhì)內(nèi)涵的表演型討論;你來我去，大家都在“消費情緒，而非真相”……不知不覺養(yǎng)起了一堆說話似是而非的大號，充斥著很多情緒性的作秀文字。跟新浪微博不同，