第4講工程立項(xiàng)、可行性分析與需求獲取課件

王少華武漢大學(xué)國(guó)際軟件學(xué)院空間信息與數(shù)字工程研究中心huazimail@126.com工程立項(xiàng)、可行性分析與需求獲取12/16/2022王少華工程立項(xiàng)、可行性分析與需求獲取12/14/20221結(jié)構(gòu)化分析設(shè)計(jì)過(guò)程階段關(guān)鍵問(wèn)題結(jié)束標(biāo)準(zhǔn)問(wèn)題定義問(wèn)題是什么？關(guān)于規(guī)模和目標(biāo)的報(bào)告書(shū)可行性研究有可行的解嗎？系統(tǒng)的高層邏輯模型數(shù)據(jù)流圖成本/效益分析需求分析系統(tǒng)必須做什么？系統(tǒng)的邏輯模型數(shù)據(jù)流圖數(shù)據(jù)字典算法描述

2006年9月28日6時(shí)52分結(jié)構(gòu)化分析設(shè)計(jì)過(guò)程階段關(guān)鍵問(wèn)題結(jié)束標(biāo)準(zhǔn)問(wèn)題定義問(wèn)題是什么？關(guān)2結(jié)構(gòu)分析設(shè)計(jì)過(guò)程階段關(guān)鍵問(wèn)題結(jié)束標(biāo)準(zhǔn)總體設(shè)計(jì)概括地說(shuō)，應(yīng)該如何解決這個(gè)問(wèn)題？可能的解法：系統(tǒng)流程圖成本/效益分析推薦的系統(tǒng)結(jié)構(gòu)；層次圖或結(jié)構(gòu)圖詳細(xì)設(shè)計(jì)怎樣具體地實(shí)現(xiàn)這個(gè)系統(tǒng)？編碼規(guī)格說(shuō)明：HIPO圖或PDL編碼和單元測(cè)試正確的程序模塊源程序清單；單元測(cè)試方案和結(jié)果綜合測(cè)試符合要求的軟件綜合測(cè)試方案和結(jié)果；完整一致的軟件配置維護(hù)持久地滿(mǎn)足用戶(hù)需要的軟件完整準(zhǔn)確的維護(hù)記錄2006年9月28日6時(shí)52分結(jié)構(gòu)分析設(shè)計(jì)過(guò)程階段關(guān)鍵問(wèn)題結(jié)束標(biāo)準(zhǔn)總體設(shè)計(jì)概括地說(shuō)，應(yīng)該如3本質(zhì)上是功能分解，以實(shí)現(xiàn)功能的過(guò)程為中心，而用戶(hù)的需求變化主要是針對(duì)功能的。這就使基于過(guò)程的設(shè)計(jì)不易被理解；且功能變化往往引起結(jié)構(gòu)變化較大，穩(wěn)定性不好。系統(tǒng)有明確的邊界定義，且系統(tǒng)結(jié)構(gòu)依賴(lài)于系統(tǒng)邊界的定義，這樣的系統(tǒng)不易擴(kuò)充和修改。數(shù)據(jù)與操作分開(kāi)處理，可能造成軟構(gòu)件對(duì)具體應(yīng)用環(huán)境的依賴(lài)，可重用性(reusability)較差.結(jié)構(gòu)化技術(shù)的缺點(diǎn)2006年9月28日6時(shí)52分本質(zhì)上是功能分解，以實(shí)現(xiàn)功能的過(guò)程為中心，而用戶(hù)的需求變化主4管理的范圍有效的項(xiàng)目管理集中于三個(gè)P上：人員(people)、問(wèn)題(problem)和過(guò)程(process)。其順序不是任意的。任何管理者如果忘記了軟件工程是人的智力密集的勞動(dòng)，他就永遠(yuǎn)不可能在項(xiàng)目管理上得到成功；任何管理者如果在項(xiàng)目開(kāi)發(fā)早期沒(méi)有支持有效的用戶(hù)通信，他有可能為錯(cuò)誤的問(wèn)題建造一個(gè)不錯(cuò)的解決方案。最后，對(duì)過(guò)程不在意的管理者可能冒把有效的技術(shù)方法和工具插入到真空中的風(fēng)險(xiǎn)。2006年9月28日6時(shí)52分管理的范圍有效的項(xiàng)目管理集中于三個(gè)P上：人員(people)5一、工程立項(xiàng)建議1、立項(xiàng)原因2、立項(xiàng)基礎(chǔ)3、國(guó)內(nèi)外研究現(xiàn)狀4、工程意義與目標(biāo)5、用戶(hù)調(diào)查6、投資條件7、投資周期8、技術(shù)力量與基礎(chǔ)9、軟件硬件價(jià)格與性能10、數(shù)據(jù)源狀況11、應(yīng)用前景12、效益評(píng)估13、可運(yùn)行性評(píng)價(jià)2006年9月28日6時(shí)52分一、工程立項(xiàng)建議1、立項(xiàng)原因2006年9月28日6時(shí)52分6問(wèn)題定義問(wèn)題定義階段必須回答的關(guān)鍵問(wèn)題是：“要解決的問(wèn)題是什么？”問(wèn)題定義階段的工作，系統(tǒng)分析員應(yīng)該提出關(guān)于問(wèn)題性質(zhì)、工程目標(biāo)和規(guī)模的書(shū)面報(bào)告。問(wèn)題定義階段是生命周期中最簡(jiǎn)短的階段，一般只需要一天甚至更少的時(shí)間。2006年9月28日6時(shí)52分問(wèn)題定義問(wèn)題定義階段必須回答的關(guān)鍵問(wèn)題是：“要解決的問(wèn)題是什7二、可行性研究這個(gè)階段要回答的關(guān)鍵問(wèn)題是：“對(duì)于上一個(gè)階段所確定的問(wèn)題有可行的解決辦法或值得做嗎？可行性研究比較簡(jiǎn)短，這個(gè)階段的任務(wù)不是具體解決問(wèn)題，而是研究問(wèn)題的范圍，探索這個(gè)問(wèn)題是否值得去解，是否有可行的解決辦法。做還是不做？聯(lián)想集團(tuán)領(lǐng)導(dǎo)人柳傳志曾說(shuō)：“沒(méi)錢(qián)賺的事我們不干；有錢(qián)賺但投不起錢(qián)的事不干；有錢(qián)賺也投得起錢(qián)但沒(méi)有可靠的人選，這樣的事也不干。”柳傳志為決策立了上述準(zhǔn)則，同時(shí)也為可以行性分析指明了重點(diǎn)。2006年9月28日6時(shí)52分二、可行性研究這個(gè)階段要回答的關(guān)鍵問(wèn)題是：“對(duì)于上一個(gè)階段所82.1可行性研究的任務(wù)可行性研究的目的就是用最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定問(wèn)題是否能夠解決，可行性研究的目的不是解決問(wèn)題，而是確定問(wèn)題是否值得去解，以及關(guān)鍵技術(shù)、難點(diǎn)、能否解決。必須分析幾種主要的可能解法的利弊，從而判斷原定的系統(tǒng)目標(biāo)和規(guī)模是否現(xiàn)實(shí)，系統(tǒng)完成后所能帶來(lái)的效益是否大到值得投資開(kāi)發(fā)這個(gè)系統(tǒng)的程度。一般說(shuō)來(lái)，可行性研究的成本只是預(yù)期的工程總成本的5%-10%。軟件領(lǐng)域的可行性分析主要考慮四個(gè)要素：經(jīng)濟(jì)、技術(shù)、社會(huì)環(huán)境和人。項(xiàng)目的意義（社會(huì)的意義）技術(shù)可行性經(jīng)濟(jì)可行性操作可行性2006年9月28日6時(shí)52分2.1可行性研究的任務(wù)可行性研究的目的就是用最小的代價(jià)在盡可93.1.1可行性研究的任務(wù)繼續(xù)項(xiàng)目

可行性分析的四個(gè)任務(wù)

經(jīng)濟(jì)可行性經(jīng)濟(jì)實(shí)力經(jīng)濟(jì)效益社會(huì)可行性是否存在侵犯、妨礙行為技術(shù)可行性技術(shù)資源有效性開(kāi)發(fā)風(fēng)險(xiǎn)操作可行性項(xiàng)目的運(yùn)行方式在用戶(hù)組織內(nèi)是否行的通現(xiàn)有管理制度、人員素質(zhì)和操作方式是否可行2006年9月28日6時(shí)52分3.1.1可行性研究的任務(wù)繼續(xù)項(xiàng)目可行性分析的四個(gè)任務(wù)102.2可行性研究的步驟1系統(tǒng)定義，復(fù)查系統(tǒng)規(guī)模和目標(biāo)、性質(zhì)、范圍、約束和限制2研究目前正在使用的系統(tǒng)。研究現(xiàn)行系統(tǒng)（人工/舊軟件)，描繪系統(tǒng)流程圖，審核?，F(xiàn)有的系統(tǒng)必然有某些缺點(diǎn)，新系統(tǒng)必須能解決舊系統(tǒng)中存在的問(wèn)題。3.導(dǎo)出新系統(tǒng)的邏輯模型。分析員應(yīng)該畫(huà)出描繪現(xiàn)有系統(tǒng)的高層系統(tǒng)流程圖，并請(qǐng)有關(guān)人員檢驗(yàn)他對(duì)現(xiàn)有系統(tǒng)認(rèn)識(shí)是否正確。千萬(wàn)不要花費(fèi)太多時(shí)間去了解和描繪現(xiàn)有系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)，例如，除非是為了闡明一個(gè)特別關(guān)鍵的算法，否則不需要根據(jù)程序代碼畫(huà)出程序流程圖。2006年9月28日6時(shí)52分2.2可行性研究的步驟1系統(tǒng)定義，復(fù)查系統(tǒng)規(guī)模和目標(biāo)、性質(zhì)、112.3導(dǎo)出新系統(tǒng)的高層邏輯模型4.設(shè)計(jì)方案.優(yōu)秀的設(shè)計(jì)過(guò)程通?？偸菑默F(xiàn)有的物理系統(tǒng)出發(fā)，導(dǎo)出現(xiàn)有系統(tǒng)的邏輯模型，再參考現(xiàn)有系統(tǒng)的邏輯模型，設(shè)想目標(biāo)系統(tǒng)的邏輯模型，最后根據(jù)目標(biāo)系統(tǒng)的邏輯模型建造新的物理系統(tǒng)，并進(jìn)行可行性評(píng)價(jià)（4方面）分析員能夠使用數(shù)據(jù)流圖描繪數(shù)據(jù)在系統(tǒng)中流動(dòng)和處理的情況，從中概括地表達(dá)出他對(duì)新系統(tǒng)的設(shè)想。通常為了把新系統(tǒng)描繪得更清晰準(zhǔn)確，還應(yīng)該有一個(gè)初步的數(shù)據(jù)字典，定義系統(tǒng)中使用的數(shù)據(jù)。數(shù)據(jù)流圖和數(shù)據(jù)字典共同定義了新系統(tǒng)的邏輯模型，以后可以從這個(gè)邏輯模型出發(fā)設(shè)計(jì)新系統(tǒng)。2006年9月28日6時(shí)52分2.3導(dǎo)出新系統(tǒng)的高層邏輯模型4.設(shè)計(jì)方案.優(yōu)秀的設(shè)計(jì)過(guò)程通122.4重新定義問(wèn)題分析員應(yīng)該和用戶(hù)一起再次復(fù)查問(wèn)題定義、工程規(guī)模和目標(biāo)，這次復(fù)查應(yīng)該把數(shù)據(jù)流圖和數(shù)據(jù)字典作為討論的基礎(chǔ)?？尚行匝芯康那八膫€(gè)步驟實(shí)質(zhì)上構(gòu)成一個(gè)循環(huán)。分析定義問(wèn)題，分析這個(gè)問(wèn)題，導(dǎo)出一個(gè)試探性的解；在此基礎(chǔ)上再次定義問(wèn)題，再一次分析這個(gè)問(wèn)題，修改這個(gè)解；繼續(xù)這個(gè)循環(huán)過(guò)程，直到提出的邏輯模型完全符合系統(tǒng)目標(biāo)。2006年9月28日6時(shí)52分2.4重新定義問(wèn)題分析員應(yīng)該和用戶(hù)一起再次復(fù)查問(wèn)題定義、工程132.5導(dǎo)出和評(píng)價(jià)供選擇的解法5.推薦可行的方案。分析員應(yīng)該從他建議的系統(tǒng)邏輯模型出發(fā)，導(dǎo)出若干個(gè)較高層次的（較抽象的）物理解法供比較和選擇。其次可以考慮操作方面的可行性。考慮經(jīng)濟(jì)方面的可行性，對(duì)每個(gè)可能的系統(tǒng)進(jìn)行成本/效益分析。最后為每個(gè)在技術(shù)、操作和經(jīng)濟(jì)等方面都可行的系統(tǒng)制定實(shí)現(xiàn)進(jìn)度表，不需要（也不可能）制定得很詳細(xì)，通常中需要估計(jì)生命周期每個(gè)階段的工作量。2006年9月28日6時(shí)52分2.5導(dǎo)出和評(píng)價(jià)供選擇的解法5.推薦可行的方案。2006年9142.5.1經(jīng)濟(jì)可行性經(jīng)濟(jì)經(jīng)濟(jì)可行性分析主要包括：“成本——收益”分析和“短期——長(zhǎng)遠(yuǎn)利益”分析。成本-收益分析最容易理解，如果成本高于收益則表明虧損了，如果成本大大高于收益那就虧大了。2006年9月28日6時(shí)52分2.5.1經(jīng)濟(jì)可行性經(jīng)濟(jì)2006年9月28日6時(shí)52分152.6成本/效益分析直接效益服務(wù)節(jié)省開(kāi)支提高工作效率間接效益科學(xué)決策快速?zèng)Q策社會(huì)效益2006年9月28日6時(shí)52分2.6成本/效益分析直接效益2006年9月28日6時(shí)52分162.6.1成本考慮的方面（1）辦公室房租。（2）辦公用品，如桌、椅、書(shū)柜、照明電器、空調(diào)等。（3）計(jì)算機(jī)、打印機(jī)、網(wǎng)絡(luò)等硬件設(shè)備。（4）電話(huà)、傳真等通訊設(shè)備以及通訊費(fèi)用。（5）資料費(fèi)。（6）辦公消耗，如水電費(fèi)、打印復(fù)印費(fèi)等。（7）軟件開(kāi)發(fā)人員與行政人員的工資。（8）購(gòu)買(mǎi)系統(tǒng)軟件的費(fèi)用，如買(mǎi)操作系統(tǒng)、數(shù)據(jù)庫(kù)、軟件開(kāi)發(fā)工具等。有些老板買(mǎi)盜版的系統(tǒng)軟件，卻按市場(chǎng)價(jià)算成本，可從美國(guó)佬那里賺一筆。（9）做市場(chǎng)調(diào)查、可行性分析、需求分析的交際費(fèi)用。（10）公司人員培訓(xùn)費(fèi)用。（11）產(chǎn)品宣傳費(fèi)用。如果用Internet作宣傳，則要考慮建設(shè)Web站點(diǎn)的費(fèi)用。（12）如果客戶(hù)是政府部門(mén)，還要充分考慮用于吃喝玩樂(lè)、行賄的費(fèi)用。（13）如果公司的風(fēng)水不好，會(huì)有很多莫名其妙的管理費(fèi)。每戳一個(gè)紅艷艷的公章都要化一把鈔票。2006年9月28日6時(shí)52分2.6.1成本考慮的方面（1）辦公室房租。2006年9月2172.6.2短期——長(zhǎng)遠(yuǎn)利益分析人們喜歡吃著碗里的、看著鍋里的，還想著別人家里的。短期利益和長(zhǎng)遠(yuǎn)利益兼得是人們夢(mèng)寐以求的事。開(kāi)發(fā)策略2006年9月28日6時(shí)52分2.6.2短期——長(zhǎng)遠(yuǎn)利益分析2006年9月28日6時(shí)52分182.6.3成本估計(jì)-系統(tǒng)規(guī)模1、代碼行技術(shù)--面向規(guī)模的估計(jì)（代碼行KLOC）·每千行代碼(KLOC)的錯(cuò)誤數(shù)?！っ壳写a(KLOC)的缺陷數(shù)?！っ啃写a(LOC)的成本?！っ壳写a(KLOC)的文檔頁(yè)數(shù)?！っ咳嗽洛e(cuò)誤數(shù)?！っ咳嗽麓a行(LOC)?！っ宽?yè)文檔的成本。2、任務(wù)分解技術(shù)—面向功能的估計(jì)（功能點(diǎn)）用戶(hù)輸入數(shù)：計(jì)算每個(gè)用戶(hù)輸入，它們向軟件提供面向應(yīng)用的數(shù)據(jù)。輸入應(yīng)該與查詢(xún)區(qū)分開(kāi)來(lái)，分別計(jì)算。用戶(hù)輸出數(shù)：計(jì)算每個(gè)用戶(hù)輸出，它們向用戶(hù)提供面向應(yīng)用的信息。這里，輸出是指報(bào)表、屏幕、出錯(cuò)信息，等等。一個(gè)報(bào)表中的單個(gè)數(shù)據(jù)項(xiàng)不單獨(dú)計(jì)算。用戶(hù)查詢(xún)數(shù)：一個(gè)查詢(xún)被定義為一次聯(lián)機(jī)輸入，它導(dǎo)致軟件以聯(lián)機(jī)輸出的方式產(chǎn)生實(shí)時(shí)的響應(yīng)。每一個(gè)不同的查詢(xún)都要計(jì)算。文件數(shù)：計(jì)算每個(gè)邏輯的主文件(如數(shù)據(jù)的一個(gè)邏輯組合，它可能是某個(gè)大型數(shù)據(jù)庫(kù)的一部分或是一個(gè)獨(dú)立的文件)。外部接口數(shù)：計(jì)算所有機(jī)器可讀的接口(如磁帶或磁盤(pán)上的數(shù)據(jù)文件)，利用這些接口可以將信息從一個(gè)系統(tǒng)傳送到另一個(gè)系統(tǒng)。2006年9月28日6時(shí)52分2.6.3成本估計(jì)-系統(tǒng)規(guī)模1、代碼行技術(shù)--面向規(guī)模的估192.6.3問(wèn)題分解及過(guò)程分解

首先把軟件開(kāi)發(fā)工程分解為若干個(gè)相對(duì)獨(dú)立的任務(wù)，估計(jì)每個(gè)任務(wù)的成本時(shí)，通常先估計(jì)完成該任務(wù)需要用的人力（以人月為單位），再乘以每人每月的平均工資而得出每個(gè)任務(wù)的成本。最常用的辦法是按開(kāi)發(fā)階段劃分任務(wù)。如果軟件系統(tǒng)很復(fù)雜，由若干個(gè)子系統(tǒng)組成，則可以把每個(gè)子系統(tǒng)再按開(kāi)發(fā)階段進(jìn)一步劃分成更小的任務(wù)。典型環(huán)境下各個(gè)開(kāi)發(fā)階段需要使用的人力的百分比大致如表所示。2006年9月28日6時(shí)52分2.6.3問(wèn)題分解及過(guò)程分解首先把軟件開(kāi)發(fā)工程分解為若干個(gè)202006年9月28日6時(shí)52分2006年9月28日6時(shí)52分21軟件規(guī)模的例子2006年9月28日6時(shí)52分軟件規(guī)模的例子2006年9月28日6時(shí)52分22

3、自動(dòng)估計(jì)成本技術(shù)采用這種技術(shù)必須有長(zhǎng)期搜集的大量歷史數(shù)據(jù)為基礎(chǔ)，并且需要有良好的數(shù)據(jù)庫(kù)支持。2006年9月28日6時(shí)52分3、自動(dòng)估計(jì)成本技術(shù)2006年9月28日6時(shí)52分23參考書(shū)籍軟件成本估算：COCOMOII模型方法出版社：機(jī)械工業(yè)出版社

作者：[美]勃姆(Boehm,B.W)等/

譯者：李師賢/杜云梅/李衛(wèi)華等/功能點(diǎn)分析—成功軟件項(xiàng)目的測(cè)量實(shí)踐

作者：（美）DavidGarmus&DavidHerron/

出版社：清華大學(xué)出版社2006年9月28日6時(shí)52分參考書(shū)籍軟件成本估算：COCOMOII模型方法2006年924功能點(diǎn)分析法功能點(diǎn)分析法(FPA：functionpointanalysis)是在需求分析階段基于系統(tǒng)功能的一種規(guī)模估算方法，是基于應(yīng)用軟件的外部、內(nèi)部特性以及軟件性能的一種間接的規(guī)模測(cè)量。功能點(diǎn)可以用于“需求文檔”、“設(shè)計(jì)文檔”、“源代碼”、“測(cè)試用例”度量，根據(jù)具體方法和編程語(yǔ)言的不同，功能點(diǎn)可以轉(zhuǎn)換為代碼行。2006年9月28日6時(shí)52分功能點(diǎn)分析法功能點(diǎn)分析法(FPA：functionpoin25功能點(diǎn)分析法的步驟2006年9月28日6時(shí)52分功能點(diǎn)分析法的步驟2006年9月28日6時(shí)52分26功能點(diǎn)分析法FP=總計(jì)數(shù)值×［0.65＋0.01×ΣFi］其中，“總計(jì)數(shù)值”是所有功能點(diǎn)條目的總和。Fi(i=1到14)是基于對(duì)圖4-6中問(wèn)題的回答而得到的“復(fù)雜度調(diào)整值”(0到5)。等式中的常數(shù)和信息域值的加權(quán)因子是根據(jù)經(jīng)驗(yàn)確定的。Fi：1.系統(tǒng)需要可靠的備份和復(fù)原嗎？2.需要數(shù)據(jù)通信嗎？3.有分布處理功能嗎？4.性能很關(guān)鍵嗎？5.系統(tǒng)是否在一個(gè)已有的、很實(shí)用的操作環(huán)境中運(yùn)行？6.系統(tǒng)需要聯(lián)機(jī)數(shù)據(jù)項(xiàng)嗎？7.聯(lián)機(jī)數(shù)據(jù)項(xiàng)是否需要在多屏幕或多操作之間切換以完成輸入？8.需要聯(lián)機(jī)更新主文件嗎？9.輸入、輸出、文件或查詢(xún)很復(fù)雜嗎？10.內(nèi)部處理復(fù)雜嗎？11.代碼需要被設(shè)計(jì)成是可復(fù)用的嗎？12.設(shè)計(jì)中需要包括轉(zhuǎn)換及安裝嗎？13.系統(tǒng)的設(shè)計(jì)支持不同組織的多次安裝嗎？14.應(yīng)用的設(shè)計(jì)方便用戶(hù)修改和使用嗎？2006年9月28日6時(shí)52分功能點(diǎn)分析法FP=總計(jì)數(shù)值×［0.65＋0.01×ΣFi］27總計(jì)數(shù)值信息域值樂(lè)觀值可能值悲觀值估算數(shù)權(quán)值記數(shù)值輸入數(shù)20243024496輸出數(shù)12152216580查詢(xún)數(shù)16222822488主控文件數(shù)44541040外部接口數(shù)2232714總計(jì)數(shù)值

3182006年9月28日6時(shí)52分總計(jì)數(shù)值信息域值樂(lè)觀值可能值悲觀值估算數(shù)權(quán)值記數(shù)值輸入數(shù)2028因子值因子值備份和還原4信息域值復(fù)雜度5數(shù)據(jù)通訊2內(nèi)部處理復(fù)雜度5分布式處理0設(shè)計(jì)成可復(fù)用的代碼4關(guān)鍵性能4設(shè)計(jì)中的轉(zhuǎn)換及安裝3先有的操作環(huán)境3多次安裝5聯(lián)機(jī)數(shù)據(jù)登錄4方便修改的應(yīng)用設(shè)計(jì)5多屏幕輸入切換5復(fù)雜度調(diào)整因子1.17估算14個(gè)復(fù)雜度加權(quán)因子（Fi,根據(jù)問(wèn)題對(duì)項(xiàng)目的影響取值范圍是0～5），表3給出了因子值。FP=總計(jì)數(shù)值×[0.65+0.01×ΣFi]=3662006年9月28日6時(shí)52分因子值因子值備份和還原4信息域值復(fù)雜度5數(shù)據(jù)通訊2內(nèi)部處理復(fù)29工作量估算2006年9月28日6時(shí)52分工作量估算2006年9月28日6時(shí)52分30工作量估算語(yǔ)言每功能點(diǎn)的SLOC默認(rèn)C++53Delphi518HTML414VisualBasic624SQLdefault13默認(rèn)Java2462006年9月28日6時(shí)52分工作量估算語(yǔ)言每功能點(diǎn)的SLOC默認(rèn)C++53Delphi31工作量估算用java2完成上述項(xiàng)目(366功能點(diǎn))時(shí)，將大約需要下列SLOC數(shù)：

L=366×46=16836行=16.836KLOC

E＝5.2×L0.91＝5.2×16.3860.91

＝66人/月

DOC＝49×L1.01＝49×16.3861.01

＝826頁(yè)

2006年9月28日6時(shí)52分工作量估算用java2完成上述項(xiàng)目(366功能點(diǎn))時(shí)，將32成本估算項(xiàng)目的成本估算包括許多因素：人力成本、辦公費(fèi)用、管理費(fèi)用、設(shè)備和軟件等的購(gòu)置費(fèi)用、場(chǎng)地租金、旅差費(fèi)等等。對(duì)項(xiàng)目成本的估算取決于公司所采用的成本核算方法。有的公司某些費(fèi)用并沒(méi)有計(jì)入項(xiàng)目成本中，而是按管理費(fèi)用等分?jǐn)?。有的從歷史數(shù)據(jù)求出生產(chǎn)率度量和每行成本，即行／PM(人月)和元／行，則LOC的值與元／行相乘得到成本，用LOC的值與行／PM相除得到工作量。具體可按公司的具體情況選擇。2006年9月28日6時(shí)52分成本估算項(xiàng)目的成本估算包括許多因素：人力成本、辦公費(fèi)用、管33成本估算E＝5.2×L0.91，L是源代碼行數(shù)(以KLOC計(jì))，E是工作量（以PM計(jì)）D＝4.1×L0.36，D是項(xiàng)目持續(xù)時(shí)間(以月計(jì))S＝0.54×E0.6，S是人員需要量(以人計(jì))DOC＝49×L1.01。DOC是文檔數(shù)量(以頁(yè)計(jì))2006年9月28日6時(shí)52分成本估算E＝5.2×L0.91，L是源代碼行數(shù)(以KLO34制定計(jì)劃對(duì)軟件項(xiàng)目進(jìn)行估算的第三步是根據(jù)工作量制定項(xiàng)目計(jì)劃，目的是用文件的形式，把對(duì)于在開(kāi)發(fā)過(guò)程中人員安排、工作量分解、開(kāi)始和完成時(shí)間、開(kāi)發(fā)進(jìn)度、所需經(jīng)費(fèi)預(yù)算、所需軟、硬件條件等問(wèn)題作出的安排記載下來(lái)，以便根據(jù)本計(jì)劃開(kāi)展和檢查本項(xiàng)目的開(kāi)發(fā)工作?？梢愿鶕?jù)自己的歷史數(shù)據(jù)或行業(yè)模型決定所需的資源并落實(shí)到項(xiàng)目計(jì)劃。可以采用上述的IBM模型或McConnell給出的方法粗略地給出項(xiàng)目持續(xù)時(shí)間（以IBM模型為例）：項(xiàng)目需要的人員S＝0.54×E0.6＝0.54×660.6＝7人項(xiàng)目持續(xù)時(shí)間D＝4.1×L0.36＝4.1×16.3860.36＝11月2006年9月28日6時(shí)52分制定計(jì)劃對(duì)軟件項(xiàng)目進(jìn)行估算的第三步是根據(jù)工作量制定項(xiàng)目計(jì)劃35成本/效益分析的方法成本/效益分析的第一步是估計(jì)開(kāi)發(fā)成本、運(yùn)行費(fèi)用和新系統(tǒng)將帶來(lái)的經(jīng)濟(jì)效益。應(yīng)該比較新系統(tǒng)的開(kāi)發(fā)成本和經(jīng)濟(jì)效益，以便從經(jīng)濟(jì)角度判斷這個(gè)系統(tǒng)是否值得投資，投資是現(xiàn)在進(jìn)行的，效益是將來(lái)獲得的，不能簡(jiǎn)單地比較成本和效益，應(yīng)該考慮貨幣的時(shí)間價(jià)值。2006年9月28日6時(shí)52分成本/效益分析的方法成本/效益分析的第一步是估計(jì)開(kāi)發(fā)成本、運(yùn)36貸幣的時(shí)間價(jià)值假設(shè)年利率為i,如果現(xiàn)在存入P元，則n年以后可以得到的錢(qián)數(shù)為：F=P（1+i）n就是P元錢(qián)在n年后的價(jià)值。反之，如果n年后能收入F元線(xiàn)，那么這些錢(qián)的現(xiàn)在價(jià)值是:P=F/（1+i）n修改一個(gè)已有庫(kù)存清單系統(tǒng)，使它能在每天送給采購(gòu)員一份定貨報(bào)表。修改已有的庫(kù)存清單程序并且編寫(xiě)產(chǎn)生報(bào)表的程序，估計(jì)共需5000元；系統(tǒng)修改后能及時(shí)定貨將消除零件短缺問(wèn)題，估計(jì)因此每年可以節(jié)省2500元，五年共可省12500元。但是，不能簡(jiǎn)單地把5000元和12500元相比較，因?yàn)榍罢呤乾F(xiàn)在投資的錢(qián)，后者是若干年以后節(jié)省的錢(qián)。假定年利率為12%，利用上面計(jì)算貨幣現(xiàn)在價(jià)值的公式可以算出修改庫(kù)存清單系統(tǒng)后每年預(yù)計(jì)節(jié)省的錢(qián)的現(xiàn)在價(jià)值，如表所示。2006年9月28日6時(shí)52分貸幣的時(shí)間價(jià)值假設(shè)年利率為i,如果現(xiàn)在存入P元，則n年以后可372006年9月28日6時(shí)52分2006年9月28日6時(shí)52分38投資回收期所謂投資回收期就是使累計(jì)的經(jīng)濟(jì)效益等于最初投資所需要的時(shí)間。例如，修改庫(kù)存清單系統(tǒng)兩年以后可以節(jié)省4225.12元，比最初的投資（5000）元還少774.88元，第三年以后將再節(jié)省1779.45元。774.88/1779.45=0.44因此，投資回收期是2.44年。2006年9月28日6時(shí)52分投資回收期所謂投資回收期就是使累計(jì)的經(jīng)濟(jì)效益等于最初投資所39技術(shù)可行性（1）在給定的時(shí)間內(nèi)能否實(shí)現(xiàn)需求說(shuō)明中的功能。如果在項(xiàng)目開(kāi)發(fā)過(guò)程中遇到難以克服的技術(shù)問(wèn)題，麻煩就大了。輕則拖延進(jìn)度，重則斷送項(xiàng)目。（2）軟件的質(zhì)量如何？有些應(yīng)用對(duì)實(shí)時(shí)性要求很高，如果軟件運(yùn)行慢如蝸牛，即便功能具備也毫無(wú)實(shí)用價(jià)值。有些高風(fēng)險(xiǎn)的應(yīng)用對(duì)軟件的正確性與精確性要求極高，如果軟件出了差錯(cuò)而造成客戶(hù)利益損失，那么軟件開(kāi)發(fā)方可要賠慘了。（3）軟件的生產(chǎn)率如何？如果生產(chǎn)率低下，能賺到的錢(qián)就少，并且會(huì)逐漸喪失競(jìng)爭(zhēng)力。在統(tǒng)計(jì)軟件總的開(kāi)發(fā)時(shí)間時(shí)，不能漏掉用于維護(hù)的時(shí)間。軟件維護(hù)是非常拖后腿的事，它能把前期拿到的利潤(rùn)慢慢地消耗光。如果軟件的質(zhì)量不好，將會(huì)導(dǎo)致維護(hù)的代價(jià)很高，企圖通過(guò)偷工減料而提高生產(chǎn)率，是得不償失的事。技術(shù)可行性分析可以簡(jiǎn)單地表述為：做得了嗎？做得好嗎？做得快嗎？2006年9月28日6時(shí)52分技術(shù)可行性（1）在給定的時(shí)間內(nèi)能否實(shí)現(xiàn)需求說(shuō)明中的功能。如果40社會(huì)環(huán)境社會(huì)環(huán)境的可行性至少包括兩種因素：市場(chǎng)與政策。市場(chǎng)又分為未成熟的市場(chǎng)、成熟的市場(chǎng)和將要消亡的市場(chǎng)。涉足未成熟的市場(chǎng)要冒很大的風(fēng)險(xiǎn)，要盡可能準(zhǔn)確地估計(jì)潛在的市場(chǎng)有多大？自己能占多少份額？多長(zhǎng)時(shí)間能實(shí)現(xiàn)？擠進(jìn)成熟的市場(chǎng)，雖然風(fēng)險(xiǎn)不高，但油水也不多。如果供大于求，即軟件開(kāi)發(fā)公司多，項(xiàng)目少，那么在競(jìng)標(biāo)時(shí)可能會(huì)出現(xiàn)惡性殺價(jià)的情形。國(guó)內(nèi)第一批賣(mài)計(jì)算機(jī)的、做系統(tǒng)集成的公司發(fā)了財(cái)，別人眼紅了也擠進(jìn)來(lái)，這個(gè)行業(yè)的平均利潤(rùn)也就下降了。將要消亡的市場(chǎng)就別進(jìn)去了。盡管很多程序員懷念DOS時(shí)代編程的那種淋漓盡致，可現(xiàn)在沒(méi)人要DOS應(yīng)用軟件了。學(xué)校教學(xué)尚可用用DOS軟件，商業(yè)軟件公司則不可再去開(kāi)發(fā)DOS軟件。政策對(duì)軟件公司的生存與發(fā)展影響非常大。整個(gè)90年代，中國(guó)電信的收費(fèi)相當(dāng)高，僅此一招就把國(guó)內(nèi)互聯(lián)網(wǎng)企業(yè)打得奄奄一息。某些軟件行業(yè)的利潤(rùn)很高，但可能存在地方保護(hù)政策，使競(jìng)爭(zhēng)不公平。政策不當(dāng)將阻礙軟件公司的健康發(fā)展，可最怕的還是政府干預(yù)企業(yè)的正當(dāng)行為。2006年9月28日6時(shí)52分社會(huì)環(huán)境社會(huì)環(huán)境的可行性至少包括兩種因素：市場(chǎng)與政策。241人有句名言：“人分四類(lèi)——人物，人才，人手，人渣?！?董軍,軟件工程思想)如果一個(gè)軟件公司里上述四類(lèi)人齊全了，那么最好的分工是讓“人物”當(dāng)領(lǐng)導(dǎo)，“人才”做第一線(xiàn)的開(kāi)發(fā)人員，“人手”做行政人員，“人渣”負(fù)責(zé)市場(chǎng)（行賄）。這里只談公司的領(lǐng)導(dǎo)與開(kāi)發(fā)人員“行還是不行”?！叭宋铩碑吘故巧贁?shù)，“人才”可是濟(jì)濟(jì)的。舉重若輕的那類(lèi)“人才”可以做領(lǐng)導(dǎo)，舉輕若重的那類(lèi)人才適合做軟件開(kāi)發(fā)人員。假如一群持有學(xué)士、碩士和博士文憑的畢業(yè)生到軟件公司應(yīng)聘，該如何錄用呢？董軍的建議如下：先選擇本科畢業(yè)生，因?yàn)樗麄冋?dāng)青春、干勁十足、不擺架子、不恥下問(wèn)、要求不高、奉獻(xiàn)甚多。其次選擇碩士畢業(yè)生，如果該生沒(méi)象范進(jìn)中舉時(shí)那么老，并且在讀碩士時(shí)沒(méi)有天天去造文章而丟棄了編程工作，那么讓有經(jīng)驗(yàn)的學(xué)士程序員帶他們煅練幾個(gè)月就可以用了。如果學(xué)士、碩士被其它公司取光了，那只好撿幾個(gè)博士充數(shù)。博士到了軟件公司有什么用呢？我想不出有什么用，只知道他們挺值得可憐的：從碩士讀到博士出頭，這六七年時(shí)間，真本事沒(méi)學(xué)多少，倒學(xué)會(huì)“眼高手低”甚至“弄虛作假”；2006年9月28日6時(shí)52分人有句名言：“人分四類(lèi)——人物，人才，人手，人渣?！?董軍,426、推薦行動(dòng)方針可行性分析的關(guān)鍵是提出是否繼續(xù)進(jìn)行這項(xiàng)開(kāi)發(fā)工程。并且說(shuō)明選擇這個(gè)解決方案的理由。2006年9月28日6時(shí)52分6、推薦行動(dòng)方針可行性分析的關(guān)鍵是提出是否繼續(xù)進(jìn)行這項(xiàng)開(kāi)發(fā)工437、草擬開(kāi)發(fā)計(jì)劃除了工程進(jìn)度表之外還應(yīng)該估計(jì):對(duì)各種開(kāi)發(fā)人員（系統(tǒng)分析員，程序員，資料員等）各種資源（計(jì)算機(jī)硬件，軟件、數(shù)據(jù)、工具等等）的需要情況應(yīng)該指明什么時(shí)候使用多長(zhǎng)時(shí)間還應(yīng)該估計(jì)系統(tǒng)生命周期每個(gè)階段的成本。2006年9月28日6時(shí)52分7、草擬開(kāi)發(fā)計(jì)劃除了工程進(jìn)度表之外還應(yīng)該估計(jì):2006年9月448、書(shū)寫(xiě)文檔提交審查應(yīng)該把上述可行性研究各個(gè)步驟的結(jié)果寫(xiě)成清晰的文檔，請(qǐng)用戶(hù)和使用部門(mén)的負(fù)責(zé)人仔細(xì)審查，以決定是否繼續(xù)這項(xiàng)工程以及是否接受分析員推薦的方案。OVER2006年9月28日6時(shí)52分8、書(shū)寫(xiě)文檔提交審查應(yīng)該把上述可行性研究各個(gè)步驟的結(jié)果寫(xiě)成清453.Analysis&Specification需求分析不論是為客戶(hù)做軟件項(xiàng)目還是為自己做軟件產(chǎn)品，都要進(jìn)行需求分析。需求分析最?lèi)廊酥幨请y以在項(xiàng)目剛啟動(dòng)時(shí)搞清楚需求，如果在項(xiàng)目做了一大半時(shí)需求發(fā)生了變化，那將使項(xiàng)目陷入困境。3.3節(jié)解釋需求分析為什么困難，3.4節(jié)講述如何進(jìn)行需求分析。本章的需求分析均不涉及編程，所以不考慮結(jié)構(gòu)化、面向?qū)ο蟮确治龇椒?。Requirementselicitation（需求獲取）：Theprocessofdiscoveringtheclient’srequirements.Requirementsanalysis(需求分析）：Theprocessofrefiningandextendingtheinitialrequirementsdetermined.2006年9月28日6時(shí)52分3.Analysis&Specification需求分析46RequirementsDefinitionRequirements

Definition（需求定義）Customer-orienteddescriptionsofthesystem’sfunctionsandconstraintsonitsoperation（功能描述與操作約束）Arequirementisafeatureofthesystemoradescriptionofsomethingthesystemiscapableofdoinginordertofulfillthesystem’spurpose.實(shí)現(xiàn)2006年9月28日6時(shí)52分RequirementsDefinitionRequire47RequirementsDefinitionIEEE用戶(hù)解決問(wèn)題或達(dá)到目的所需的條件或能力。系統(tǒng)或系統(tǒng)部件要滿(mǎn)足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。一種反映上面兩條所描述的條件或能力的文檔說(shuō)明。真正的“需求”實(shí)際上存在人們的腦海中，任何文檔形式的需求（例如：需求規(guī)格說(shuō)明）僅是一個(gè)模型或一種敘述。2006年9月28日6時(shí)52分RequirementsDefinitionIEEE20048需求分析的重要性開(kāi)發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說(shuō)明開(kāi)發(fā)什么。最為困難的概念性工作便是編寫(xiě)出詳細(xì)技術(shù)需求，這包括所有面向用戶(hù)、面向機(jī)器和其它軟件系統(tǒng)的接口。同時(shí)這也是一旦做錯(cuò)，將會(huì)最終給系統(tǒng)帶來(lái)極大損害的部分，而且以后再對(duì)它進(jìn)行修改也極為困難。2006年9月28日6時(shí)52分需求分析的重要性開(kāi)發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說(shuō)明開(kāi)發(fā)什49WhatisthisPhaseFor?Majormisconception(誤解）

determiningwhatclientwants

“IknowyoubelieveyouunderstoodwhatyouthinkIsaid,butIamnotsureyourealizethatwhatyouheardisnotwhatImeant!”(我知道你相信你理解了你認(rèn)為我所說(shuō)的，但我不能確定你是否認(rèn)識(shí)到你所聽(tīng)到的并不是我所意指的，GeorgeRomney)Mustdetermineclient’s&user’sneeds,Nottheclientwants.chancesforsuccessslimifyoudon’tfigurethisout!2006年9月28日6時(shí)52分WhatisthisPhaseFor?Majorm50thegoalofthespecificationorsystemanalysisphasethegoalofthespecificationorsystemanalysisphaseistobuildamodelofthesoftwareproductthattheclientrequires.Theinformationdomainofaproblemmustberepresentedandunderstood.理解和描述問(wèn)題的信息范圍Thefunctionsthatthesoftwareistoperformmustbedefined.定義軟件的功能Thebehaviorofthesoftware(asaconsequenceofexternalevents)mustberepresented.描述軟件對(duì)外部事件的響應(yīng)Themodelsthatdepictinformation,function,andbehaviormustbepartitionedinamannerthatuncoversdetailinalayered(orhierarchical)fashion.描述信息、功能和行為的模型必須以分層的方式顯示細(xì)節(jié)來(lái)劃分開(kāi)Theanalysisprocessshouldmovefromessentialinformationtowardimplementationdetail.描述2006年9月28日6時(shí)52分thegoalofthespecification51需求分析為什么困難（1）客戶(hù)說(shuō)不清楚需求；有些客戶(hù)對(duì)需求只有朦朧的感覺(jué)，當(dāng)然說(shuō)不清楚具體的需求。有些客戶(hù)心里非常清楚想要什么，但卻說(shuō)不明白。如果客戶(hù)本身就懂軟件開(kāi)發(fā)，能把需求說(shuō)得清清楚楚，這樣的需求分析將會(huì)非常輕松、愉快。如果客戶(hù)全不懂軟件，但信任軟件開(kāi)發(fā)方，這事也好辦。分析人員可以引導(dǎo)客戶(hù)，先闡述常規(guī)的需求，再由客戶(hù)否定不需要的，最終確定客戶(hù)真正的需求。最怕的就是“不懂裝懂”或者“半懂充內(nèi)行”的客戶(hù)，他們會(huì)提出不切實(shí)際的需求。（2）需求自身經(jīng)常變動(dòng)；需求肯定會(huì)變動(dòng)（1）盡可能地分析清楚哪些是穩(wěn)定的需求，哪些是易變的需求。以便在進(jìn)行系統(tǒng)設(shè)計(jì)時(shí)，將軟件的核心建筑在穩(wěn)定的需求上，否則將會(huì)吃盡苦頭。（2）在合同中一定要說(shuō)清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。（3）分析人員或客戶(hù)理解有誤?？蛻?hù)表達(dá)的需求，不同的分析人員可能有不同的理解。寫(xiě)好需求說(shuō)明書(shū)后，要請(qǐng)客戶(hù)方的各個(gè)代表驗(yàn)證。如果問(wèn)題很復(fù)雜，雙方都不太明白，就有必要請(qǐng)開(kāi)發(fā)人員快速構(gòu)造軟件的原型，雙方再次論證需求說(shuō)明書(shū)是否正確。由于客戶(hù)大多不懂軟件，他們可能覺(jué)得軟件是萬(wàn)能的，會(huì)提出一些無(wú)法實(shí)現(xiàn)的需求。2006年9月28日6時(shí)52分需求分析為什么困難（1）客戶(hù)說(shuō)不清楚需求；2006年9月252如何進(jìn)行需求分析-應(yīng)該了解什么Toelicittheclient’sneeds,themembersoftherequirementsteammustbefamiliarwiththeapplicationdomain.(熟悉客戶(hù)領(lǐng)域知識(shí)）Tobuildaglossary(術(shù)語(yǔ)表）用正確的術(shù)語(yǔ)進(jìn)行正確的交流應(yīng)該先了解宏觀的問(wèn)題，再了解細(xì)節(jié)的問(wèn)題。2006年9月28日6時(shí)52分如何進(jìn)行需求分析-應(yīng)該了解什么Toelicitthe53（1）最好為每個(gè)需求注釋“為什么”，這樣可讓程序員了解需求的本質(zhì)，以便選用最合適的技術(shù)來(lái)實(shí)現(xiàn)此需求。（2）需求說(shuō)明不可有二義性，更不能前后相矛盾。如果有二義性或前后相矛盾，則要重新分析此需求。2006年9月28日6時(shí)52分（1）最好為每個(gè)需求注釋“為什么”，這樣可讓程序員了解需求的54TypeofRequirementsBussinessrequirementsAsystemrequirement(alsocalledabusinessrequirement)isadescriptionoftheneedsanddesiresforaninformationsystem.Arequirementmaydescribefunctions,features(attributes),andconstraints.（系統(tǒng)需求是對(duì)信息系統(tǒng)的需求描述）Userrequirements用戶(hù)使用產(chǎn)品必須要完成的任務(wù)（業(yè)務(wù)需求）2006年9月28日6時(shí)52分TypeofRequirementsBussiness55TypeofRequirementsFunctionalrequirements（功能需求）Afunctionalrequirementisafunctionorfeaturethatmustbeincludedinaninformationsystemtosatisfythebusinessneedandbeacceptabletotheusers.（滿(mǎn)足系統(tǒng)需求的、被用戶(hù)認(rèn)可的系統(tǒng)功能或者特征）Afunctionalrequirementdescribesaninteractionbetweenthesystemanditsenvironment..（系統(tǒng)與環(huán)境間的交互）2006年9月28日6時(shí)52分TypeofRequirementsFunctional56TypeofRequirementsnon-functional

requirementsAnonfunctionalrequirementisadescriptionofthefeatures,characteristics,andattributesofthesystemaswellasanyconstraintsthatmaylimittheboundariesoftheproposedsolution.(限定范圍）Anonfunctionalrequirementoraconstraintdescribesarestrictiononthesystemthatlimitsourchoicesforconstructingasolutiontotheproblem.（限定選擇的解決方案）2006年9月28日6時(shí)52分TypeofRequirementsnon-functi57Non-functionalRequirementsDefinesystempropertiesandconstraintse.g.reliability,responsetimeandstoragerequirements.ConstraintsareI/Odevicecapability,systemrepresentations系統(tǒng)表現(xiàn),etc.Processrequirementsmayalsobespecifiedmandating要求

aparticularCASEsystem,programminglanguageordevelopmentmethod(過(guò)程要求）Non-functionalrequirementsmaybemorecriticalthanfunctionalrequirements.Ifthesearenotmet達(dá)到,thesystemisuseless2006年9月28日6時(shí)52分Non-functionalRequirementsDef58Non-functionalRequirementsNon-functionalRequirementsProductRequirementsOrganizationalRequirementsExternalRequirementsUsabilityRequirementsEfficiencyRequirementsReliabilityRequirementsPortabilityRequirementsDeliveryRequirementsImplementationRequirementsStandardsRequirementsInteroperabilityRequirementsEthicalRequirementsLegislativeRequirementsPerformanceRequirementsSpaceRequirementsPrivacyRequirementsSafetyRequirements法制2006年9月28日6時(shí)52分Non-functionalRequirementsNon59LevelofRequirements業(yè)務(wù)需求項(xiàng)目視圖與范圍文檔用戶(hù)需求用例文檔質(zhì)量屬性功能需求系統(tǒng)需求軟件需求規(guī)格說(shuō)明其他非功能需求約束條件2006年9月28日6時(shí)52分LevelofRequirements業(yè)務(wù)需求項(xiàng)目視圖與60TypesofRequirementsTherequirementsdefinitionandspecificationdocumentsdescribeeverythingabouthowthesystemistointeractwithitsenvironment.Includedarethefollowingkindsofitems.PhysicalEnvironmentWhereistheequipmenttofunction?Isthereonelocationorseveral?Arethereanyenvironmentalrestrictions,suchastemperature溫度,humidity濕度,ormagneticinterference磁干擾?2006年9月28日6時(shí)52分TypesofRequirementsTherequi61InterfacesIstheinputcomingfromoneormoreothersystems?Istheoutputgoingtooneormoreothersystems?Isthereaprescribedwayinwhichthedatamustbeformatted?Isthereaprescribedmediumthatthedatamustuse?UsersandFactorsWhowillusethesystem?Willtherebeseveraltypesofusers?Whatistheskilllevelofeachtypeofuser?Howeasywillitbeforausertounderstandandusethesystem?Howdifficultwillitbeforausertomisuse誤用thesystem?TypesofRequirements2006年9月28日6時(shí)52分InterfacesTypesofRequirement62FunctionalityWhatwillthesystemdo?Whenwillthesystemdoit?Arethereseveralmodesofoperation?Howandwhencanthesystembechangedorenhanced?Arethereconstraintsonexecutionspeed,responsetime,orthroughput?DocumentationHowmuchdocumentationisrequired?Shoulditbeon-line,inbookformat,orboth?Towhataudienceiseachtypeofdocumentationaddressed?TypesofRequirements2006年9月28日6時(shí)52分FunctionalityTypesofRequirem63DataForbothinputandoutput,whatshouldtheformatofthedatabe?Howoftenwilltheybereceivedorsent?Howaccuratemusttheybe?Towhatdegreeofprecisionmustthecalculationsbemade?Howmuchdataflowthroughthesystem?Mustanydataberetainedforanyperiodoftime?TypesofRequirements2006年9月28日6時(shí)52分DataTypesofRequirements2006年64ResourcesWhatmaterials,personnel,orotherresourcesarerequiredtobuild,use,andmaintainthesystem?Whatskillsmustthedevelopershave?Howmuchphysicalspacewillbetakenupbythesystem?Whataretherequirementsforpower,heating,orairconditioning?Isthereaprescribedtimetablefordevelopment?Istherealimitontheamountofmoneytobespentondevelopmentoronhardwareandsoftware?TypesofRequirements2006年9月28日6時(shí)52分ResourcesTypesofRequirements65SecurityMustaccesstothesystemortoinformationbecontrolled?Howwilloneuser’sdatabeisolatedfromothers?Howwilluserprogramsbeisolatedfromotherprogramsandfromtheoperatingsystem?Howoftenwillthesystembebackedup?Mustthebackupcopiesbestoredatadifferentlocation?Shouldprecautionsbetakenagainstfire,waterdamage,ortheft?TypesofRequirements2006年9月28日6時(shí)52分SecurityTypesofRequirements266QualityAssuranceWhataretherequirementsforreliability,availability,maintainability,security,andtheotherqualityattributes?Howmustthecharacteristicsofthesystembedemonstratedtoothers?Mustthesystemdetectandisolatefaults?Whatistheprescribedmeantimebetweenfailures?Isthereamaximumtimeallowedforrestartingthesystemafterafailure?Howcanthesystemincorporatechangestothedesign?Willmaintenancemerelycorrecterrorsorwillitalsoincludeimprovingthesystem?Whatefficiencymeasureswillapplytoresourceusageandresponsetime?Howeasyshoulditbetomovethesystemfromonelocationtoanotherorfromonetypeofcomputertoanother?TypesofRequirements2006年9月28日6時(shí)52分QualityAssuranceTypesofRequ67CharacteristicsofRequirementsAretherequirementscorrect?正確Aretherequirementsconsistent?一致Aretherequirementscomplete?完整Aretherequirementsrealistic?現(xiàn)實(shí)Doeseachrequirementdescribesomethingthatisneededbythecustomer?必需？Aretherequirementsverifiable?可證明Aretherequirementstraceable?可跟蹤2006年9月28日6時(shí)52分CharacteristicsofRequiremen68ProblemsofSoftwareRequirementsStakeholdersdon’tknowwhattheyreallywant.Stakeholdersexpressrequirementsintheirownterms.Differentstakeholdersmayhavesomeconflictingrequirements.Organisationalandpoliticalfactorsmayinfluencethesystemrequirements.Therequirementschangeduringthedevelopmentprocess.Newstakeholdersmayemerge.Requirementsspecificationistoosimple.Requirementsproblemsresultin40-60%softwareproblems.2006年9月28日6時(shí)52分ProblemsofSoftwareRequireme69RequirementsDevelopment確定產(chǎn)品所期望的用戶(hù)類(lèi)；獲取每個(gè)用戶(hù)類(lèi)的需求；了解實(shí)際用戶(hù)任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求；分析源于用戶(hù)的信息，以區(qū)別用戶(hù)任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息；將系統(tǒng)級(jí)需求分為若干子系統(tǒng)，并將需求中的一部分分配給軟件組件；了解相關(guān)質(zhì)量屬性的重要性；商討實(shí)施優(yōu)先級(jí)的劃分；將所收集的用戶(hù)需求編寫(xiě)成規(guī)格說(shuō)明和模型；評(píng)審需求規(guī)格說(shuō)明，確保對(duì)用戶(hù)需求達(dá)到共同的理解與認(rèn)識(shí)，并在整個(gè)開(kāi)發(fā)小組接受說(shuō)明之前將問(wèn)題都弄清楚。2006年9月28日6時(shí)52分RequirementsDevelopment確定產(chǎn)品所期70RequirementsManagement定義需求基線(xiàn)；評(píng)審提出的需求變更，評(píng)估每項(xiàng)變更的可能影響，從而決定是否實(shí)施它；以一種可控制的方式將需求變更融入到項(xiàng)目中；使當(dāng)前的項(xiàng)目計(jì)劃與需求一致；估計(jì)變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾；讓每項(xiàng)需求都能與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測(cè)試用例聯(lián)系起來(lái)以實(shí)現(xiàn)跟蹤；在整個(gè)項(xiàng)目過(guò)程中跟蹤需求狀態(tài)及其變更情況。2006年9月28日6時(shí)52分RequirementsManagement定義需求基線(xiàn)；71RequirementElicitation需求獲取的工作內(nèi)容聆聽(tīng)用戶(hù)需求分析人員應(yīng)與各種層次的客戶(hù)交流和溝通，盡量清楚理解。分析和整理所獲取的信息從用戶(hù)一般性的陳述中提取用戶(hù)的真正需求。形成文檔化的描述問(wèn)題和需求都需要形成文檔化的描述，使各種人員一致理解和認(rèn)可。需求獲取的關(guān)鍵溝通和交流正確和清楚地理解2006年9月28日6時(shí)52分RequirementElicitation需求獲取的工作72Stakeholders2006年9月28日6時(shí)52分Stakeholders2006年9月28日6時(shí)52分73RequirementsAnalysisTechniquesInterviewing（訪(fǎng)談）Questionnaires（問(wèn)卷）consultanexpert、askforadvice（請(qǐng)教專(zhuān)家）Formsanalyses（表格分析）Existingsystemsanalysis(現(xiàn)存系統(tǒng)分析）Scenarios（情景）Rapidprototyping（快速原型）2006年9月28日6時(shí)52分RequirementsAnalysisTechniqu74Interviewing直接與客戶(hù)交談。如果分析人員生有足球評(píng)論員的那張“大嘴”，就非常容易侃出需求，或名記者的提問(wèn)技巧。Structuredvs.Unstructured(程式化和非程式化）whatisthedifference?whatarethetradeoffs折衷?"Asweknow,Thereareknownknowns.Therearethingsweknowweknow.WealsoknowThereareknownunknowns.ThatistosayWeknowtherearesomethingsWedonotknow.Buttherearealsounknownunknowns,Theoneswedon'tknowWedon'tknow."–DonaldRumsfield,February12,2002,DepartmentofDefensenewsbriefingSpecific，preplaned,close-endedquestionsvs.Open-endedQuestions(謹(jǐn)防滿(mǎn)無(wú)目的地）ContextualInquiry（打破砂鍋問(wèn)到底、順藤摸瓜，Why？）Wayofunderstandingusers’needs&workpracticesmaster–apprenticemodel（師徒）allowscustomertoteachuswhattheydo!masterdoesthework&talksaboutitwhileworkingweinterrupttoaskquestionsastheygoTheWhere,How,andWhatexposetheWhy2006年9月28日6時(shí)52分Interviewing直接與客戶(hù)交談。如果分析人員生有足球75Communication用戶(hù)采購(gòu)者市場(chǎng)人員需求分析員開(kāi)發(fā)人員產(chǎn)品代表用戶(hù)管理員系統(tǒng)設(shè)計(jì)員2006年9月28日6時(shí)52分Communication用戶(hù)采購(gòu)者市場(chǎng)人員需求分析員開(kāi)發(fā)人76ContextualInquiryPrinciplesContextgototheworkplace&seetheworkasitunfoldspeoplesummarize,butwewantdetails–keepitconcrete“Weusuallygetreportsbyemail”,ask“CanIseeone?”P(pán)artnership（合伙）master-apprenticerelationship,yes;othermodels,noavoidinterviewer/interviewee(stopswork)allowsmoreapprenticeinteraction(alternate:watching&probing尋根究底)Interpretation（解釋?zhuān)ゞoodfactsonlythestartingpoint–designsbasedoninterpretationsValidate（確認(rèn)）–runinterpretationsbytheusertoseeifyouarerightFocusinterviewerneedsdataaboutspecifickindofwork“steer”conversationtostayonusefultopics（駕馭談話(huà)主題）2006年9月28日6時(shí)52分ContextualInquiryPrinciplesC77UIDesignProcessSpecProductionDesignRefinementDesignExplorationDiscoveryAssessneeds評(píng)估需求understandclient’sexpectations(期望)determinescopeofprojectcharacteristicsofusersevaluateexistingsiteand/orcompetition2006年9月28日6時(shí)52分UIDesignProcessSpecProducti78CommentonHumanFactorsHUIHuman-computerinterfaceKeyaspectofsuccessfulsoftwareproductintendedusersmustinteractw/itNeedtoconsider(考慮的因素）expertiseofintendedusers(資深專(zhuān)家型）&cognitiveabilities(who)whattaskstheydonow&willdo(what)Becarefulofbook’shintthatgoodUIdesignmightjustbe“commonsense”canonlybemadesuccessfulbyinvolvinguserinrepeatedprocessofdesign,prototype,test（使用戶(hù)成功參與設(shè)計(jì)、原型、測(cè)試的重復(fù)進(jìn)程）showntobetruetime&timeagaindesigneregobias(自我偏見(jiàn)）–wearenottheusersanymoreUser-friendlinessTakeSSD4ifyouwanttoreallylearnthis2006年9月28日6時(shí)52分CommentonHumanFactorsHUIHu79ScenariosIllustratethemajorevents/actionstousersAscenarioisawayausermightutilizethetargetproducttoaccomplishsomeobjective.利用目標(biāo)產(chǎn)品完成某一功能的方式oftenusestoryboards（情景板）&paperprototypesespeciallyusefulforUIdesignTolisttheactionscomprisingthescenario2006年9月28日6時(shí)52分ScenariosIllustratethemajor80RequirementsAnalysisTechniquesIllustratethemajorevents/actionstousersoftenusestoryboards&paperprototypesespeciallyusefulforUIdesign2006年9月28日6時(shí)52分RequirementsAnalysisTechniqu812006年9月28日6時(shí)52分2006年9月28日6時(shí)52分822006年9月28日6時(shí)52分2006年9月28日6時(shí)52分83FromScenariostoRapidPrototypes2006年9月28日6時(shí)52分FromScenariostoRapidProtot84TheusefulofScenariosTheycanbedemonstratethebehavioroftheproductinawaythatiscomprehensibletouser.Thiscanresultinadditionalrequirementscomingtolight.用用戶(hù)理解的方式說(shuō)明軟件行為，并能發(fā)現(xiàn)額外的需求。Becausescenarioscanbeunderstoodbyusers,theutilizationofscenarioscanensurethattheclientandusersplayanactiverolethroughouttherequirementsanalysisprocess.在需求分析的整個(gè)進(jìn)程中扮演重要積極角色。Scenarios(UseCases)playanimportantroleinobject-orientedanalysis.情景在面向?qū)ο蠓治鲋邪缪葜匾巧?006年9月28日6時(shí)52分TheusefulofScenariosTheyca85RapidPrototypingAllowusersto“see”&useproposedsolutionsDevelopspecificationfromtheprototype/requirementsproceedwithrestofstagesinwaterfallmodelPrototypemustbeconstructed&changedquicklykeyfunctionalityomitsthingslikescalability,errorchecking,saving,etc.donotspendalotoftimeperfectingthecode/structureitisOKifithardlyworksorcrasheseveryfewminutesplantothrowitaway!becauseyouwill!putinfrontofcustomerASAP(盡快）&modifyinresponse2006年9月28日6時(shí)52分RapidPrototypingAllowuserst86RapidPrototypingTools&TechniquesUIprototyping&otherrapiddevtoolshelpe.g.,DENIMHTML/HypertextsimplymockingupaUIinHTMLtoflipscreensalsodoneinPowerPoint,Director,HyperCard,etc.Interpretedlanguages&dev.environmentsSmalltalk,Lisp,java2006年9月28日6時(shí)52分RapidPrototypingTools&Techn87DangerousVariantsofRPUsetherapidprototypingasthespecification?“productwilldowhatRPdoesplusfileupdating,etc.”notimewasteddrawingupspecsproblemsunlikelytobeacceptedasalegalcontracthardtomakegoodtestcasesw/oaspec.thereisnospecificationtorefertoduringmaintenanceRefinetherapidprototypeuntilitistheproduct?becomesbuild-and-fix->expensive!remember,putittogetherfast&nowyouaregonnachangeit!performanceconstraintsunlikelytobemetprototypeinadifferentlanguagetoavoidthis!目的不同，側(cè)重點(diǎn)不同2006年9月28日6時(shí)52分DangerousVariantsofRPUseth88SoftwarePrototype一個(gè)軟件原型是所提出的新產(chǎn)品的部分實(shí)現(xiàn)，它比開(kāi)發(fā)人員常用的技術(shù)術(shù)語(yǔ)更易于理解。建立原型的主要原因是為了解決在產(chǎn)品開(kāi)發(fā)的早期階段需求不確定的問(wèn)題，用戶(hù)、經(jīng)理和其他非技術(shù)項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者發(fā)現(xiàn)在確定和開(kāi)發(fā)產(chǎn)品時(shí)，原型可以使他們的想象更具體化。作用：明確并完善需求；探索設(shè)計(jì)選擇方案；發(fā)展為最終的產(chǎn)品。類(lèi)型：拋棄式原型和演化式原型2006年9月28日6時(shí)52分SoftwarePrototype一個(gè)軟件原型是所提出的新89ThrowawayPrototype