軟件工程-3軟件要求定義

單擊此處編輯母版標(biāo)題樣式,單擊此處編輯母版文本樣式,第二層,第三層,第四層,第五層,*,軟件要求定義,第三講,軟件要求定義,1,學(xué)習(xí)內(nèi)容,可行性研究,項目開發(fā)計劃,軟件需求分析,2,項目來源,合同,：為別人做；,立項：為自己做；,失?。簾o盈利賠錢聲譽(yù)影響官司,失?。罕M賠錢公司倒閉東山再起難！,學(xué)到的遠(yuǎn)比失去的多！,3,可行性研究,（,Feasibility Study）,可行性研究的,目的,就是用最小的代價在盡可能短的時間內(nèi)確定該軟件項目是否能夠開發(fā)，是否值得開發(fā)，最后給決策者提供做與不做的依據(jù)可行性研究,實(shí)質(zhì),上是要進(jìn)行一次簡化、壓縮了的需求分析和設(shè)計過程，要在較高層次上以抽象的方式進(jìn)行需求分析和設(shè)計過程4,可行性研究的任務(wù),首先,需要進(jìn)行概要的分析研究，初步確定項目的規(guī)模和目標(biāo)，確定項目的約束和限制然后,進(jìn)行簡要的需求分析，抽象出該項目的邏輯結(jié)構(gòu)，建立邏輯模型最后,從邏輯模型出發(fā)，經(jīng)過壓縮的設(shè)計，探索出若干種可供選擇的主要解決辦法，對每種解決方法都要從以下三方面研究它的可行性技術(shù)可行性,經(jīng)濟(jì)可行性,社會可行性,5,技術(shù)可行性,在,現(xiàn)有資源,條件下，,項目,能否實(shí)現(xiàn)，,風(fēng)險,有多大（技術(shù)、資源是否成熟）。

社會可行性,是否存在侵權(quán)、軟件操作方式是否適合用戶所在組織、現(xiàn)有管理制度、人員素質(zhì)是否可行？,6,經(jīng)濟(jì)可行性,（成本效益分析）,成本效益分析首先是估算將要開發(fā)的系統(tǒng)的開發(fā)成本，然后與可能取得的效益進(jìn)行比較和權(quán)衡效益分有形效益和無形效益有形效益可以用貨幣的時間價值、投資回收期和純收入等指標(biāo)進(jìn)行度量；無形效益主要從性質(zhì)上、心理上進(jìn)行衡量，很難直接進(jìn)行量的比較貨幣的時間價值,：通常用利率表示F=P,(1+n i),不計復(fù)利,投資回收期,：就是使累計的經(jīng)濟(jì)效益等于最初的投資費(fèi)用所需的時間純收入,：就是在整個生存周期之內(nèi)的累計經(jīng)濟(jì)效益（折合成現(xiàn)在值）與投資之差7,提示,不是解決問題，而是確定是否可解值得解,所以不要花過多精力，占總成本的 5,10,%,例：實(shí)踐性大作業(yè) 3 方面考慮：,技術(shù)上-23 學(xué)生,7 周,電腦,開發(fā)經(jīng)驗，,決心，風(fēng)險（影響其它課程）.,社會上-產(chǎn)品有沒有人用,經(jīng)濟(jì)上-預(yù)算,盈利,.,8,可行性研究的具體步驟,1、確定項目規(guī)模和目標(biāo)，明確限制和約束我們認(rèn)為用戶要的 用戶要的,2、研究老系統(tǒng),解決老系統(tǒng)問題,老系統(tǒng)功能,新增,功能,注：,注意了解與其它系統(tǒng)的接口新系統(tǒng)效益,老系統(tǒng)效益,9,可行性研究的具體步驟,3、導(dǎo)出高層邏輯模型,(conceptual design),抽象,實(shí)現(xiàn),改進(jìn),老系統(tǒng),模型,新模型,新系統(tǒng),應(yīng)該告訴用戶“What”而不是“How”,10,系統(tǒng)流程圖（事務(wù)圖）,高層邏輯模型,11,可行性研究的具體步驟,3、邏輯模型,4、復(fù)查和重新定義,1、復(fù)查定義,注：此時合同未簽，應(yīng)考慮成本，不宜反復(fù)太多次。

5、導(dǎo)出和評價多種解法,進(jìn)度表,經(jīng)濟(jì)上合算,技術(shù)上可行,操作上可行,技術(shù)上不可行,用戶,不,可,能,操,作,不合算,12,可行性研究的具體步驟,6、推薦行動方針,Yes or No?,No,Yes,Why?,Which one is the best?,Why?(cost/benefit),8、審查、存檔,7、編寫可行性報告（開發(fā)計劃）,任務(wù)分解，確定負(fù)責(zé)人,大致進(jìn)度規(guī)劃,財務(wù)預(yù)算,風(fēng)險分析及對策,粗略,13,文檔：,可行性報告,參考GB856788中的可行性研究報告，進(jìn)行適當(dāng)裁剪14,項目開發(fā)計劃,是對開發(fā)項目的費(fèi)用、時間、進(jìn)度、人員組織、硬件設(shè)備的配置、軟件開發(fā)環(huán)境和運(yùn)行環(huán)境的配置等進(jìn)行說明和規(guī)劃是項目管理人員對項目進(jìn)行管理的依據(jù)，據(jù)此對項目的費(fèi)用、進(jìn)度和資源進(jìn)行控制和管理工具：Project,15,16,注意事項,標(biāo)書：我國對軟件成本認(rèn)識不足,人月不能互換：,需求的變更、人員的流動、環(huán)境的變化；,困難：就是缺乏數(shù)據(jù)估計，導(dǎo)致估計不科學(xué)；,估算,項目復(fù)雜度（熟悉程度）、規(guī)模,17,軟件需求分析：“做什么？”,需求分析的過程是開發(fā)人員與用戶共同協(xié)商，明確系統(tǒng)的全部功能、性能以及運(yùn)行規(guī)格，并且使用軟件開發(fā)人員和用戶都能理解的語言準(zhǔn)確地表達(dá)出來，即完成需求規(guī)格說明的過程。

18,軟件需求重要性例子,“喂，是Jack嗎？我是人力資源部的Tom,我們在使用你編寫的職員系統(tǒng)時遇到一個問題，一個職員想把她的名字改成Sparkle Starlight,而系統(tǒng)不允許，你能幫幫忙嗎？”,“她嫁給了一個姓Starlight的人嗎？”Jack問道不，她沒有結(jié)婚，而僅僅是要更改她的名字，”Tom回答，“就是這問題，好象我們只能在婚姻狀況改變時才能更改姓名當(dāng)然這樣，我從沒想到誰會莫名其妙地更改姓名，我也不記得你曾告訴我系統(tǒng)需要處理這樣的事情Jack說Tom說：“我想你當(dāng)然知道每個人只要愿意都可以隨時合法更改其姓名但不管怎樣，你在本周五之前解決這問題，否則Sparkle不能支付她的帳單這不是我的錯！我現(xiàn)在正忙著做一個新的系統(tǒng)，還要做一些別的需求變更請求很抱歉，只能下周才能修改19,故事帶給我們的啟示,影響,：作為客戶，很惱火，因為軟件系統(tǒng)不能進(jìn)行一項基本的操作哪怕開發(fā)者給其解決了，也不會感謝他作為開發(fā)者，也很煩人，迫使你增加了當(dāng)前的工作，又要你優(yōu)先處理原因,：由于收集、編寫、協(xié)商、修改需求過程的手續(xù)或方法失誤帶來的這里是非正式信息的收集、未確定或不明確的功能、未發(fā)現(xiàn)或未經(jīng)交流的假設(shè)、不完善的需求文檔，以及突發(fā)的需求變更過程所造成的。

解決辦法,：重視需求分析，派經(jīng)驗豐富的人員做，最大程度的減少類似情況發(fā)生20,定值整定,原則1：,按與相鄰接地距離保護(hù)配合整定；,原則2：,按相鄰零序電流保護(hù)配合整定；,1,2,3,1與2配；,1與3配；,方案1：,原則相鄰線,方案2：,相鄰線原則,21,需求分析的特點(diǎn),老問題：,問題的復(fù)雜性,交流障礙（講究技巧和原則）,不完備性和不一致性,需求易變性（動態(tài)性）,派經(jīng)驗豐富的人去干！,系統(tǒng)分析員,22,軟件需求的任務(wù),理解、分解、表達(dá)、評審,whf:,劃分系統(tǒng)所有,1.問題識別,：雙方確定問題的綜合需求功能需求：,系統(tǒng)必須做什么？,性能需求：,做得怎樣？,例：,response time,memory,back-up memory,環(huán)境需求：,運(yùn)行環(huán)境、軟硬件配置等用戶界面需求,可靠性、安全性、保密性、可移植性和可維護(hù)性等方面的需求將來可能提出的要求,共同理解！,23,軟件需求的任務(wù),2.分析與綜合,:導(dǎo)出軟件的邏輯模型對獲取的需求進(jìn)行一致性的分析檢查，在分析、綜合中逐步細(xì)化軟件功能，劃分成各個子功能也對數(shù)據(jù)域進(jìn)行分解，分配到各個子功能上，并用圖文結(jié)合的形式，建立起新系統(tǒng)的邏輯模型24,軟件需求的任務(wù),3.編寫文檔,：,編寫需求說明書,編寫初步用戶使用手冊,編寫確認(rèn)測試計劃,修改完善項目開發(fā)計劃,25,需求文檔,用戶需求報告,需求規(guī)格說明書,對外的，驗收依據(jù),對內(nèi)的，設(shè)計依據(jù),是合同的產(chǎn)物,是立項建議書的產(chǎn)物,由用戶需求報告可產(chǎn)生需求規(guī)格說明書,當(dāng)前系統(tǒng)，目標(biāo)系統(tǒng),目標(biāo)系統(tǒng)（數(shù)據(jù)字典，算法分析）,26,軟件需求的任務(wù),驗證需求的一致性,驗證需求的完整性,驗證需求的現(xiàn)實(shí)性,驗證需求的有效性,方法：,人工審查,開發(fā)原型系統(tǒng),探索型,使用軟件工具,完整性、一致性,基線,4.技術(shù)審查和管理復(fù)審,27,需求分析的方法,結(jié)構(gòu)化分析方法,：由數(shù)據(jù)流和數(shù)據(jù)字典構(gòu)成，適于數(shù)據(jù)處理領(lǐng)域問題。

但該方法的一個難點(diǎn)是確定數(shù)據(jù)流之間的變換，而且數(shù)據(jù)字典的規(guī)模也是一個問題，對數(shù)據(jù)結(jié)構(gòu)的強(qiáng)調(diào)很少功能分解法：,系統(tǒng)功能子功能功能接口過程抽象觀點(diǎn)，很難與軟件設(shè)計明確分離基點(diǎn)放在功能上，不穩(wěn)定，難以適用需求的變化28,需求分析的方法,信息建模方法,：從數(shù)據(jù)角度來對現(xiàn)實(shí)世界建?；竟ぞ呤?E-R圖,，數(shù)據(jù)不封閉，每個實(shí)體和它的屬性的處理需求不是組合在同一實(shí)體中，沒有繼承性和消息傳遞機(jī)制來支持模型是面向?qū)ο蠓治龅幕A(chǔ)面向?qū)ο蟮姆治?：采用了實(shí)體、關(guān)系和屬性等信息模型分析中的概念，同時采用了封閉、類結(jié)構(gòu)和繼承性等面向?qū)ο蟪绦蛟O(shè)計語言中的概念29,ER模型（,Entity-Relationship Approach,）,實(shí)體：客觀世界中存在且可相互區(qū)分的事物用矩形框代表聯(lián)系：事物間是有聯(lián)系的1:1、1:N、M:N),用連接相關(guān)實(shí)體的菱形框表示屬性：實(shí)體或聯(lián)系所具有的性質(zhì)用橢圓形或圓角矩形表示教師,學(xué)生,課程,教,學(xué),學(xué)號,職,稱,成績,學(xué)分,1,N,N,M,30,注意事項,在需求分析時要注意用戶對軟件開發(fā)的了解程度避免造成兩種極端認(rèn)識需求的變動或新增是一個極為普遍的問題，既然普遍，所以軟件開發(fā)人員不僅應(yīng)該在心理上接受這種變動，還應(yīng)該在需求分析時,積極的發(fā)掘需求,。

需求人員與用戶廣泛交流，從深度和廣度挖掘可能的需求，并應(yīng)形成規(guī)范的需求文檔，,經(jīng)用戶確認(rèn),如果為寫文檔而寫文檔，不進(jìn)行及時更新，甚至準(zhǔn)備在軟件開發(fā)完成后再補(bǔ)文檔，這是,絕對,錯誤的觀點(diǎn)31,可能錯誤,沒有足夠,用戶,從參與（類型、數(shù)量）,開發(fā)方與用戶溝通可能處于劣勢,不要錦上添花，畫蛇添足,不要寫的過于簡練，過于模糊；,計劃需求的時間少了，導(dǎo)致需求不完整,另外，要注意：,需求在簽約前要與決策者溝通好；,到競爭對手那兒找不足,不要被過細(xì)的不成熟的細(xì)節(jié)影響,記下不明確的需求，約定期限明確，否則易遺漏,32,總結(jié),熟練掌握：軟件需求分析的任務(wù)及分析的方法,掌握：可行性研究的任務(wù)了解：其余作一般了解33,作業(yè),一人組：交實(shí)驗三；,二人組：交實(shí)驗三、實(shí)驗四,三人組：交實(shí)驗一/二、實(shí)驗三、實(shí)驗四,四人組：交實(shí)驗一/二、實(shí)驗三、實(shí)驗四、實(shí)驗五,34,35,。