【正文】 ng4Tools TechniquesuUI prototyping other rapid dev tools helpl ., DENIMuHTML / Hypertextlsimply mocking up a UI in HTML to flip screenslalso done in PowerPoint, Director, HyperCard, etc.uInterpreted languages dev. environmentslSmalltalk, Lisp, java2023年 9月 28日 6時 52分Dangerous Variants of RP4Use the rapid prototyping as the specification ?u“product will do what RP does plus file updating, etc.”lno time wasted drawing up specsuproblemslunlikely to be accepted as a legal contractlhard to make good test cases w/o a spec.lthere is no specification to refer to during maintenance4Refine the rapid prototype until it is the 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時 52分Software Prototype4一個軟件原型是所提出的新產(chǎn)品的部分實現(xiàn)，它比開發(fā)人員常用的技術(shù)術(shù)語更易于理解。4需求獲取的關(guān)鍵u 溝通和交流u 正確和清楚地理解2023年 9月 28日 6時 52分Stakeholders2023年 9月 28日 6時 52分Requirements Analysis Techniques4Interviewing（訪談）4Questionnaires（問卷）4consult an expert、 ask for advice（請教專家）4Forms analyses（表格分析）4Existing systems analysis(現(xiàn)存系統(tǒng)分析）4Scenarios（情景）4Rapid prototyping（快速原型）2023年 9月 28日 6時 52分Interviewing4直接與客戶交談 。2023年 9月 28日 6時 52分4（ 1）最好為每個需求注釋 “ 為什么 ” ，這樣可讓程序員了解需求的本質(zhì)，以便選用最合適的技術(shù)來實現(xiàn)此需求。u（ 2）在合同中一定要說清楚 “ 做什么 ” 和 “ 不做什么 ” 。 “I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!”( 我知道你相信你理解了你認(rèn)為我所說的，但我不能確定你是否認(rèn)識到你所聽到的并不是我所意指的， Gee Romney)4Must determine client’s user’s needs, Not the client wants.uchances for success slim if you don’t figure this out!2023年 9月 28日 6時 52分the goal of the specification or system analysis phase4 the goal of the specification or system analysis phase is to build a model of the software product that the client requires. u The information domain of a problem must be represented and understood. 理解和描述問題的信息范圍u The functions that the software is to perform must be defined. 定義軟件的功能u The behavior of the software (as a consequence of external events) must be represented. 描述軟件對外部事件的響應(yīng)u The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion. 描述信息、功能和行為的模型必須以分層的方式顯示細(xì)節(jié)來劃分開u The analysis process should move from essential information toward implementation detail. 描述2023年 9月 28日 6時 52分需求分析為什么困難 4（ 1）客戶說不清楚需求；u有些客戶對需求只有朦朧的感覺，當(dāng)然說不清楚具體的需求。l系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。并且說明選擇這個解決方案的理由。 ” (董軍 ,軟件工程思想 )如果一個軟件公司里上述四類人齊全了，那么最好的分工是 讓 “ 人物 ” 當(dāng)領(lǐng)導(dǎo)， “ 人才 ” 做第一線的開發(fā)人員， “ 人手 ” 做行政人員， “ 人渣 ” 負(fù)責(zé)市場（行賄）。l將要消亡的市場就別進(jìn)去了。在統(tǒng)計軟件總的開發(fā)時間時，不能漏掉用于維護(hù)的時間。u例如，修改庫存清單系統(tǒng)兩年以后可以節(jié)省，比最初的投資（ 5000）元還少 元，第三年以后將再節(jié)省 ?？梢圆捎蒙鲜龅?IBM模型或McConnell給出的方法粗略地給出項目持續(xù)時間（以IBM模型為例）： 項目需要的人員 S＝ E ＝ 66 ＝ 7人項目持續(xù)時間 D＝ L ＝ ＝ 11月2023年 9月 28日 6時 52分成本 /效益分析的方法4成本 /效益分析的第一步是估計開發(fā)成本、運(yùn)行費(fèi)用和新系統(tǒng)將帶來的經(jīng)濟(jì)效益。4S 有的從歷史數(shù)據(jù) 求出生產(chǎn)率度量和每行成本，即行／ PM(人月 )和元／行 ，則 LOC的值與元／行相乘得到成本，用 LOC 的值與行／ PM相除得到工作量。 4功能點(diǎn)可以用于 “ 需求文檔 ” 、 “ 設(shè)計文檔 ” 、“ 源代碼 ” 、 “ 測試用例 ” 度量，根據(jù)具體方法和編程語言的不同，功能點(diǎn)可以轉(zhuǎn)換為代碼行。u作者　　： [美 ]勃姆 (Boehm,) 等 / u文件數(shù) ： 計算每個邏輯的主文件 (如數(shù)據(jù)的一個邏輯組合，它可能是某個大型數(shù)據(jù)庫的一部分 或是一個 獨(dú)立的文件 )。 每頁文檔的成本。 每行代碼 (LOC)的成本。每戳一個紅艷艷的公章都要化一把鈔票。 （ 8）購買系統(tǒng)軟件的費(fèi)用，如買操作系統(tǒng)、數(shù)據(jù)庫、軟件開發(fā)工具等。 4成本 收益分析最容易理解，如果成本高于收益則表明虧損了，如果成本大大高于收益那就虧大了。4可行性研究的前四個步驟實質(zhì)上構(gòu)成一個循環(huán)。u現(xiàn)有的系統(tǒng)必然有某些缺點(diǎn)，新系統(tǒng)必須能解決舊系統(tǒng)中存在的問題。經(jīng)濟(jì)效益經(jīng)濟(jì)效益社會可行性社會可行性167。4做還是不做？4聯(lián)想集團(tuán)領(lǐng)導(dǎo)人柳傳志 曾說： “ 沒錢賺的事我們不干；有錢賺但投不起錢的事不干；有錢賺也投得起錢但沒有可靠的人選，這樣的事也不干。4系統(tǒng)有明確的邊界定義，且系統(tǒng)結(jié)構(gòu)依賴于系統(tǒng)邊界的定義，這樣的系統(tǒng) 不易擴(kuò)充和修改 。2023年 9月 28日 6時 52分結(jié)構(gòu)分析設(shè)計過程階段 關(guān)鍵問題 結(jié)束標(biāo)準(zhǔn)總體設(shè)計 概括地說，應(yīng)該如何解決這個問題？可能的解法：這就使基于過程的設(shè)計 不易被理解 ；且 功能 變化往往引起結(jié)構(gòu)變化較大， 穩(wěn)定性不好 。2023年 9月 28日 6時 52分二、可行性研究4這個階段要回答的關(guān)鍵問題是： “ 對于上一個階段所確定的問題有可行的解決辦法或值得做嗎？ 可行性研究比較簡短，這個階段的任務(wù)不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。經(jīng)濟(jì)實力經(jīng)濟(jì)實力167。 研究現(xiàn)行系統(tǒng)（人工 /舊軟件 )，描繪系統(tǒng)流程圖，審核。2023年 9月 28日 6時 52分u分析員應(yīng)該和用戶一起再次復(fù)查 問題定義、工程規(guī)模和目標(biāo) ，這次復(fù)查應(yīng)該把數(shù)據(jù)流圖和數(shù)據(jù)字典作為討論的基礎(chǔ)。2023年 9月 28日 6時 52分4經(jīng)濟(jì) u經(jīng)濟(jì)可行性分析主要包括： “ 成本 —— 收益 ” 分析和 “ 短期 —— 長遠(yuǎn)利益 ” 分析。 （ 7）軟件開發(fā)人員與行政人員的工資。 （ 13）如果公司的風(fēng)水不好，會有很多莫名其妙的管理費(fèi)。uu每一個不同的查詢都要計算。 2023年 9月 28日 6時 52分參考書籍4軟件成本估算： COCOMO II模型方法u出版社?。?機(jī)械工業(yè)出版社 u 出版社： 清華大學(xué)出版社2023年 9月 28日 6時 52分功能點(diǎn)分析法4功能點(diǎn)分析法 (FPA： function point analysis)是在需求分析階段基于系統(tǒng)功能的一種規(guī)模估算方法，是基于應(yīng)用軟件的外部、內(nèi)部特性以及軟件性能的一種間接的規(guī)模測量。有的公司某些費(fèi)用并沒有計入項目成本中，而是按管理費(fèi)用等分?jǐn)偂?D是項目持續(xù)時間 (以月計 ) 可以根據(jù)自己的歷史數(shù)據(jù)或行業(yè)模型決定所需的資源并落實到項目計劃。2023年 9月 28日 6時 52分2023年 9月 28日 6時 52分 投資回收期4所謂投資回收期就是使累計的經(jīng)濟(jì)效益等于最初投資所需要的時間。 4（ 3） 軟件的生產(chǎn)率如何？ 如果生產(chǎn)率低下，能賺到的錢就少，并且會逐漸喪失競爭力。國內(nèi)第一批賣計算機(jī)的、做系統(tǒng)集成的公司發(fā)了財，別人眼紅了也擠進(jìn)來，這個行業(yè)的平均利潤也就下降了。2023年 9月 28日 6時 52分人有句名言： “ 人分四類 —— 人物，人才，人手，人渣。博士到了軟件公司有什么用呢？我想不出有什么用，只知道他們挺值得可憐的：從碩士讀到博士出頭，這六七年時間，真本事沒學(xué)多少，倒學(xué)會 “ 眼高手低 ”甚至 “ 弄虛作假 ” ；2023年 9月 28日 6時 52分推薦行動方針4可行性分析的關(guān)鍵是提出是否繼續(xù)進(jìn)行這項開發(fā)工程。 4Requirements elicitation（ 需求獲取 ）： The process of discovering the client’s requirements.4Requirements analysis(需求分析） ： The process of refining and extending the initial requirements determined.2023年 9月 28日 6時 52分Requirements Definition4Requirements Definition（需求定義）uCustomeroriented descriptions of the system’s functions and constraints on its operation（功能描述與操作約束）uA requirement is a feature of the system or a description of something the system is capable of doing in order to fulfill the system’s purpose.實現(xiàn)2023年 9月 28日 6時 52分Requirements DefinitionIEEEl用戶解決問題或達(dá)到目的所需的條件或能力。determining what client wants以便在進(jìn)行系統(tǒng)設(shè)計時，將軟件的核心建筑在穩(wěn)定的需求上，否則將會吃盡苦頭。2023年 9月 28日 6時 52分如何進(jìn)行需求分析 應(yīng)該了解什么 4To elicit the client’s needs, the members of the requirements team must be familiar with the application domain.(熟悉客戶領(lǐng)域知識）4To build a glossary(術(shù)語表） 用正確的術(shù)語進(jìn)行正確的交流4應(yīng)該先了解宏觀的問題，再了解細(xì)節(jié)的問題。u 形成文檔化的描述 問題和需求都需要形成文檔化的描述，使各種人員一致理解和認(rèn)可。4Scenarios (Use Cases) play an important role in o