【正文】 product ?ubees buildandfix expensive!lremember, put it together fast now you are gonna change it!uperformance constraints unlikely to be metuprototype in a different language to avoid this!u目的不同，側(cè)重點(diǎn)不同2023年 9月 28日 6時(shí) 52分Software Prototype4一個(gè)軟件原型是所提出的新產(chǎn)品的部分實(shí)現(xiàn)，它比開發(fā)人員常用的技術(shù)術(shù)語(yǔ)更易于理解。4使用過(guò)程：2023年 9月 28日 6時(shí) 52分Evolutionary Prototype4演化 式 原型適合于基于 Web應(yīng)用的系統(tǒng)開發(fā)，這種系統(tǒng)往往隨著開發(fā)的進(jìn)展本身的需求也在發(fā)生變化。有些高手真的很厲害，你還沒(méi)有開始問(wèn)，他就能講出前因后果。要經(jīng)常分析優(yōu)秀的和蹩腳的同類軟件，看到了優(yōu)點(diǎn)就盡量吸取，看到了缺點(diǎn)就引以為戒。 (與表格分析結(jié)合起來(lái)）2023年 9月 28日 6時(shí) 52分現(xiàn)行系統(tǒng)調(diào)查4 估計(jì)新建可能帶來(lái)的效益；4的問(wèn)題。4 發(fā)現(xiàn)現(xiàn)行系統(tǒng)存在的問(wèn)題4 初步確定系統(tǒng)的主要目標(biāo)4 技術(shù)力量的調(diào)查分析4 資金財(cái)力的調(diào)查分析4 數(shù)據(jù)資料的調(diào)查分析4 系統(tǒng)效益調(diào)查分析2023年 9月 28日 6時(shí) 52分系統(tǒng)分析4 分析現(xiàn)行運(yùn)作過(guò)程，獲得現(xiàn)行系統(tǒng)流程圖4 進(jìn)行數(shù)據(jù)分析，獲取數(shù)據(jù)字典u數(shù)據(jù)流條目：組成、流量、來(lái)源、去向；u文件條目：文件名、組成、存貯方式、存取頻率；u數(shù)據(jù)項(xiàng)條目：數(shù)據(jù)項(xiàng)名、類型、長(zhǎng)度、取值范圍；u加工條目：加工名、輸入數(shù)據(jù)、輸出數(shù)據(jù)、加工邏輯；u對(duì)隱含在有關(guān)圖形上的數(shù)據(jù)也應(yīng)引起足夠重視。 發(fā)現(xiàn)現(xiàn)行系統(tǒng)存在的問(wèn)題；4 或 需求重用4從客戶的具體業(yè)務(wù)著手，考察現(xiàn)場(chǎng)。 ” consult an expert（ ask for advice)。4使用過(guò)程：2023年 9月 28日 6時(shí) 52分Prototype Selection矛盾2023年 9月 28日 6時(shí) 52分Prototyping Methods and Tools4Fourth generation techniquesu enpass a broad array of database query and reporting languages, program and application generators and other very highlevel nonprocedural languagesu generate executable code quickly4Reusable software ponentsu Use a set of existing software ponents4Formal specification and prototyping environmentsu formal languagesu automated tools2023年 9月 28日 6時(shí) 52分Management Implications of Rapid Prototyping4Can use rapid prototyping to achieve consensus（一致意見(jiàn)）4Expectations must be managed in advance（提前管理期望）uimmediate delivery of finished productuinstant maintenance of operating product4RP shown to lead to products w/ less code effortuincentive to leave unessential features（非本質(zhì)） out of the RP often leave out of the final productualso lead to easier to learn use products4Waterfall model assumes get things right 1st timeubad assumption… iterative RP is more realistic4Be prepared for more client/user interaction2023年 9月 28日 6時(shí) 52分Questionnaire（問(wèn)卷調(diào)查）4The technique is useful when the opinions of hundreds of individuals need to be 。4作用：u 明確并完善需求；u 探索設(shè)計(jì)選擇方案；u 發(fā)展為最終的產(chǎn)品。4Because scenarios can be understood by users, the utilization of scenarios can ensure that the client and users play an active role throughout the requirements analysis 個(gè)進(jìn)程中扮演重要積極角色。4Structured vs. Unstructured(程式化和非程式化）uwhat is the difference? what are the tradeoffs折衷 ?u As we know, There are known knowns. There are things we know we know. We also know There are known unknowns. That is to say We know there are some things We do not know. But there are also unknown unknowns, The ones we don39。u 分析和整理所獲取的信息 從用戶一般性的陳述中提取用戶的真正需求。如果有二義性或前后相矛盾，則要重新分析此需求。 u由于客戶大多不懂軟件，他們可能覺(jué)得軟件是萬(wàn)能的，會(huì)提出一些無(wú)法實(shí)現(xiàn)的需求。4（ 3）分析人員或客戶理解有誤。4（ 2）需求自身經(jīng)常變動(dòng)；u需求肯定會(huì)變動(dòng)u（ 1）盡可能地分析清楚哪些是穩(wěn)定的需求，哪些是易變的需求。u如果客戶本身就懂軟件開發(fā)，能把需求說(shuō)得清清楚楚，這樣的需求分析將會(huì)非常輕松、愉快。2023年 9月 28日 6時(shí) 52分What is this Phase For?4Major misconception (誤解）uu 真正的 “需求 ”實(shí)際上存在人們的腦海中，任何文檔形式的需求（例如：需求規(guī)格說(shuō)明）僅是一個(gè)模型或一種敘述。本章的需求分析均不涉及編程，所以不考慮結(jié)構(gòu)化、面向?qū)ο蟮确治龇椒ā?023年 9月 28日 6時(shí) 52分書寫文檔提交審查4應(yīng)該把上述可行性研究各個(gè)步驟的結(jié)果寫成清晰的文檔，請(qǐng)用戶和使用部門的負(fù)責(zé)人仔細(xì)審查，以決定是否繼續(xù)這項(xiàng)工程以及是否接受分析員推薦的方案。 u如果學(xué)士、碩士被其它公司取光了，那只好撿幾個(gè)博士充數(shù)。 “ 人物 ” 畢竟是少數(shù)， “ 人才 ” 可是濟(jì)濟(jì)的。政策不當(dāng)將阻礙軟件公司的健康發(fā)展，可最怕的還是政府干預(yù)企業(yè)的正當(dāng)行為。學(xué)校教學(xué)尚可用用 DOS軟件，商業(yè)軟件公司則不可再去開發(fā) DOS軟件。如果供大于求，即軟件開發(fā)公司多，項(xiàng)目少，那么在競(jìng)標(biāo)時(shí)可能會(huì)出現(xiàn)惡性殺價(jià)的情形。如果軟件的質(zhì)量不好，將會(huì)導(dǎo)致維護(hù)的代價(jià)很高，企圖通過(guò)偷工減料而提高生產(chǎn)率，是得不償失的事。有些高風(fēng)險(xiǎn)的應(yīng)用對(duì)軟件的正確性與精確性要求極高，如果軟件出了差錯(cuò)而造成客戶利益損失，那么軟件開發(fā)方可要賠慘了。2023年 9月 28日 6時(shí) 52分技術(shù)可行性4（ 1） 在給定的時(shí)間內(nèi)能否實(shí)現(xiàn)需求說(shuō)明中的功能 。l假定年利率為 12%，利用上面計(jì)算貨幣現(xiàn)在價(jià)值的公式可以算出修改庫(kù)存清單系統(tǒng)后每年預(yù)計(jì)節(jié)省的錢的現(xiàn)在價(jià)值，如表所示。2023年 9月 28日 6時(shí) 52分貸幣的時(shí)間價(jià)值4假設(shè)年利率為 i,如果現(xiàn)在存入 P元，則 n年以后可以得到的錢數(shù)為：F=P（ 1+i） n就是 P元錢在 n年后的價(jià)值。 DOC是文檔數(shù)量 (以頁(yè)計(jì) )2023年 9月 28日 6時(shí) 52分制定計(jì)劃 4對(duì)軟件項(xiàng)目進(jìn)行估算的第三步是根據(jù)工作量 制定項(xiàng)目計(jì)劃 ，目的是用文件的形式，把對(duì)于在開發(fā)過(guò)程中 人員安排、工作量分解、開始和完成時(shí)間、開發(fā)進(jìn)度、所需經(jīng)費(fèi)預(yù)算、所需軟、硬件條件等 問(wèn)題作出的安排記載下來(lái)，以便根據(jù)本計(jì)劃 開展和檢查本項(xiàng)目 的開發(fā)工作。 S是人員需要量 (以人計(jì) )＝ 2023年 9月 28日 6時(shí) 52分成本估算4E 對(duì)項(xiàng)目成本的估算取決于公司所采用的成本核算方法。 Fi(i=1到 14)是基于對(duì)圖 46中問(wèn)題的回答而得到的 “ 復(fù)雜度調(diào)整值 ”(0 到 5)。 2023年 9月 28日 6時(shí) 52分2023年 9月 28日 6時(shí) 52分軟件規(guī)模的例子2023年 9月 28日 6時(shí) 52分 4 自動(dòng)估計(jì)成本技術(shù)u采用這種技術(shù)必須有長(zhǎng)期搜集的大量歷史數(shù)據(jù)為基礎(chǔ)，并且需要有良好的數(shù)據(jù)庫(kù)支持。2023年 9月 28日 6時(shí) 52分 4首先把軟件開發(fā)工程分解為若干個(gè)相對(duì)獨(dú)立的任務(wù)，估計(jì)每個(gè)任務(wù)的成本時(shí)，通常先估計(jì)完成該任務(wù)需要用的人力（以人月為單位），再乘以每人每月的平均工資而得出每個(gè)任務(wù)的成本。u用戶查詢數(shù) ： 一個(gè)查詢被定義為一次聯(lián)機(jī)輸入，它導(dǎo)致軟件以聯(lián)機(jī)輸出的方式產(chǎn)生實(shí)時(shí)的響應(yīng)。輸入應(yīng)該與查詢區(qū)分開來(lái)，分別計(jì)算。 每人月代碼行 (LOC)。 每千行代碼 (KLOC)的文檔頁(yè)數(shù)。 每千行代碼 (KLOC)的缺陷數(shù)。短期利益和長(zhǎng)遠(yuǎn)利益兼得是人們夢(mèng)寐以求的事。 （ 12）如果客戶是政府部門，還要充分考慮用于吃喝玩樂(lè)、行賄的費(fèi)用。 （ 9）做市場(chǎng)調(diào)查、可行性分析、需求分析的交際費(fèi)用。 （ 6）辦公消耗，如水電費(fèi)、打印復(fù)印費(fèi)等。 （ 2）辦公用品，如桌、椅、書柜、照明電器、空調(diào)等。u最后為每個(gè)在技術(shù)、操作和經(jīng)濟(jì)等方面都可行的系統(tǒng)制定實(shí)現(xiàn)進(jìn)度表，不需要（也不可能）制定得很詳細(xì)，通常中需要估計(jì)生命周期每個(gè)階段的工作量。2023年 9月 28日 6時(shí) 52分。 數(shù)據(jù)流圖和數(shù)據(jù)字典共同定義了新系統(tǒng)的邏輯模型 ，以后可以從這個(gè)邏輯模型出發(fā)設(shè)計(jì)新系統(tǒng)。 分析員應(yīng)該畫出描繪現(xiàn)有系統(tǒng)的高層系統(tǒng)流程圖，并請(qǐng)有關(guān)人員檢驗(yàn)他對(duì)現(xiàn)有系統(tǒng)認(rèn)識(shí)是否正確?，F(xiàn)有管理制度、人員素質(zhì)和操作方式是否可行2023年 9月 28日 6時(shí) 52分41系統(tǒng)定義， 復(fù)查系統(tǒng)規(guī)模和目標(biāo)、性質(zhì)、范圍、約束和限制42研究目前正在使用的系統(tǒng)。技術(shù)技術(shù)167。u項(xiàng)目的意義（社會(huì)的意義）u技術(shù)可行性u(píng)經(jīng)濟(jì)可行性u(píng)操作可行性2023年 9月 28日 6時(shí) 52分 可行性研究的任務(wù)繼續(xù)項(xiàng)目 可行性分析的四個(gè)任務(wù) 經(jīng)濟(jì)可行性經(jīng)濟(jì)可行性167。 2023年 9月 28日 6時(shí) 52分4可行性研究的目的就是用最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定問(wèn)題是否能夠解決，可行性研究的目的 不是解決問(wèn)題，而是確定問(wèn)題是否值得去解，以及關(guān)鍵技術(shù)、難點(diǎn)、能否解決 。4問(wèn)題定義階段是生命周期中最簡(jiǎn)短的階段，一般只需要一天甚至更少的時(shí)間。其順序不是任意的。HIPO圖或 PDL編碼和單元測(cè)試正確的程序模塊 源程序清單；單元測(cè)試方案和結(jié)果綜合測(cè)試 符合要求的軟件 綜合測(cè)試方案和結(jié)果；完整一致的軟件配置維護(hù) 持久地滿足用戶需要的軟件完整準(zhǔn)確的維護(hù)記錄2023年 9月 28日 6時(shí) 52分4本質(zhì)上是功能分解，以實(shí)現(xiàn)功能的 過(guò)程 為中心，而用戶的需求變化主要是針對(duì) 功能 的。 系統(tǒng)流程圖層次圖或結(jié)構(gòu)圖詳細(xì)設(shè)計(jì) 怎樣具體地實(shí)現(xiàn)這個(gè)系統(tǒng)？編碼規(guī)格說(shuō)明： 4數(shù)據(jù)與操作分開處理，可能造成軟構(gòu)件對(duì)具體應(yīng)用環(huán)境的依賴， 可重用性 (reusability)較差.結(jié)構(gòu)化技術(shù)的缺點(diǎn)2023年 9月 28日 6時(shí) 52分管理的范圍4有效的項(xiàng)目管理集中于三個(gè) P上： 人員 (people)、問(wèn)題 (problem)和過(guò)程 (process)。 2023年 9月 28日 6時(shí) 52分一、工程立項(xiàng)建議立項(xiàng)原因立項(xiàng)基礎(chǔ)國(guó)內(nèi)外研究現(xiàn)狀工程意義與目標(biāo)用戶調(diào)查投資條件投資周期技術(shù)力量與基礎(chǔ)軟件硬件價(jià)格與性能數(shù)據(jù)源狀況1應(yīng)用前景1效益評(píng)估1可運(yùn)行性評(píng)價(jià)2023年 9月 28日 6時(shí) 52分問(wèn)題定義4問(wèn)題定義階段必須回答的關(guān)鍵問(wèn)題是： “ 要解決的問(wèn)題是什么？ ”4問(wèn)題定義階段的工作，系統(tǒng)分析員應(yīng)該提出關(guān)于問(wèn)題性質(zhì)、工程目標(biāo)和規(guī)模的書面報(bào)告。 ”柳傳志為決策立了上述準(zhǔn)則，同時(shí)也為可以行性分析指明了重點(diǎn)。4軟件領(lǐng)域的可行性分析主要考慮四個(gè)要素： 經(jīng)濟(jì)、技術(shù)、社會(huì)環(huán)境和人。是否存在是否存在侵犯、妨礙侵犯、妨礙行為行為技術(shù)可行性技術(shù)可行性167。項(xiàng)目的運(yùn)行方式在用戶組織內(nèi)是否行的通167。通常為了把新系統(tǒng)描繪得更清晰準(zhǔn)確，還應(yīng)該有一個(gè)初步的數(shù)據(jù)字典，定義系統(tǒng)中使用的數(shù)據(jù)。分析定義問(wèn)題，分析這個(gè)問(wèn)題，導(dǎo)出一個(gè)試