第1章

軟件工程基礎(chǔ)軟件工程基礎(chǔ)

軟件系統(tǒng)與現(xiàn)代化文明

迄今為止，軟件系統(tǒng)已經(jīng)成為信息化的關(guān)鍵因素。研究表明軟件行業(yè)發(fā)展指數(shù)能夠展現(xiàn)一個(gè)民族和國家的現(xiàn)代化文明程度。然而，人類在軟件開發(fā)中遭遇了一系列困難，并且仍然沒有有效的辦法擺脫相關(guān)的困擾。因此，當(dāng)前階段，計(jì)算機(jī)行業(yè)的發(fā)展受制于軟件的發(fā)展。

軟件工程學(xué)科的誕生

為了解決軟件系統(tǒng)開發(fā)與維護(hù)過程中的困難，相關(guān)的計(jì)算機(jī)行業(yè)專家于1968年著手研究解決軟件困境的方法和管理措施，經(jīng)過若干年的發(fā)展和完善，形成了一門嶄新的學(xué)科——軟件工程。1.1軟件危機(jī)

1965年之前，每一個(gè)具體的應(yīng)用開發(fā)專用軟件；一般代碼量不大；開發(fā)者依據(jù)本人或者組織的實(shí)際需要開發(fā)；只保存很少的文檔資料；這對軟件的維護(hù)極其不利。

1965年至1975進(jìn)入了“軟件作坊”時(shí)代。繼續(xù)使用個(gè)性化的開發(fā)技術(shù)；各組織的軟件數(shù)量不斷增加。

需要對軟件實(shí)施維護(hù)的情況1.操作系統(tǒng)或者硬件更新后；3.在程序運(yùn)行過程中發(fā)現(xiàn)錯(cuò)誤時(shí)2.在軟件開發(fā)過程中或使用期間，用戶有了新的需求4.程序運(yùn)行過程中，存在影響系統(tǒng)安全的漏洞時(shí)軟件危機(jī)出現(xiàn)了！軟件工程學(xué)科誕生！

軟件維護(hù)代價(jià)越來越大，最嚴(yán)重的問題：程序開發(fā)者不在現(xiàn)場，軟件不可維護(hù)；

“軟件危機(jī)”出現(xiàn)！

1968年，專家們在聯(lián)邦德國召開會(huì)議，主題：什么是軟件危機(jī)？如何解決軟件危機(jī)？專家們提出“軟件工程”概念，標(biāo)志著“軟件工程”學(xué)科誕生。1.1.1有關(guān)軟件危機(jī)的介紹導(dǎo)致軟件危機(jī)的兩個(gè)問題：1.軟件需求日益增長，如何組織軟件開發(fā)？2.面對各組織中已開發(fā)的大量軟件，該如何維護(hù)？具體表現(xiàn)（1）開發(fā)成本估算、進(jìn)度預(yù)估不準(zhǔn)確。“已完成”的軟件不能滿足用戶要求。軟件開發(fā)過程中，沒有統(tǒng)一規(guī)范的過程模型，沒有詳細(xì)的文檔資料。運(yùn)行中，經(jīng)常出現(xiàn)讓人不滿意或故障具體表現(xiàn)（2）無法維護(hù)、升級或更新軟件開發(fā)生產(chǎn)率提高的速度跟不上技術(shù)進(jìn)步的步伐軟件成本所占比例逐年提高總結(jié)：實(shí)際項(xiàng)目中，

有更多的問題1.1.2原因與解決方法——原因（1）軟件是人類創(chuàng)造的最復(fù)雜的產(chǎn)品，規(guī)模龐大、結(jié)構(gòu)復(fù)雜，給軟件開發(fā)和維護(hù)帶來困難。（2）項(xiàng)目管理困難。軟件具有無形性，導(dǎo)致管理困難，尤其在進(jìn)度控制、質(zhì)量控制方面。（3）軟件開發(fā)費(fèi)用、

維護(hù)成本急劇上升，影響信息化、數(shù)字化推廣范圍。（4）開發(fā)技術(shù)無法緊跟時(shí)代要求。專家注重理論研究，忽視開發(fā)技術(shù)研究。（5）開發(fā)工具落后，生產(chǎn)效率偏低。（6）需求分析的重要性被忽視。開發(fā)人員、用戶的溝通不及時(shí)、不充分，文檔資料不全。（7）軟件運(yùn)行、維護(hù)過程中管理不善。1.1.2原因與解決方法——解決方法（1）應(yīng)用適合的軟件開發(fā)技術(shù)和方法。（2）使用適合的軟件工具。（3）實(shí)施良好的管理，各類人員默契配合。1.2軟件工程——定義和目標(biāo)1.定義

軟件工程是采用工程化的思維、原理、技術(shù)手段與方法，用以指導(dǎo)軟件開發(fā)全過程以及軟件維護(hù)的一門學(xué)科。NATO會(huì)議：“為了用較低的成本，開發(fā)出在設(shè)備設(shè)施上運(yùn)行軟件，而確立并使用的一系列工程原理?！盜EEE定義：“①把系統(tǒng)的、規(guī)范的、可度量的方法應(yīng)用于系統(tǒng)開發(fā)、軟件實(shí)施與維護(hù)過程，即把工程化思維應(yīng)用于軟件開發(fā)；②研究①中提到的方法?！?/p>

2.目標(biāo)（1）滿足客戶的全部功能需求、性能要求（2）開發(fā)成本盡量低（3）軟件企業(yè)須依據(jù)合同實(shí)施，及時(shí)交付軟件產(chǎn)品（4）軟件具有易于維護(hù)，較高的可靠性（5）軟件具有易用性、可重用性和可移植性1.2.2相關(guān)原理（1）01采用生命周期法管理軟件開發(fā)過程。02始終堅(jiān)持實(shí)施階段評審。03實(shí)行嚴(yán)格的產(chǎn)品控制。1.2.2相關(guān)原理（2）04使用現(xiàn)代的程序設(shè)計(jì)方法。05成果可以審查。06團(tuán)隊(duì)成員少而精。0507必須意識到逐步改進(jìn)并提升工程實(shí)踐的重要性和必要性。1.2.3軟件工程的進(jìn)步史01傳統(tǒng)的軟件工程階段03面向過程工程02面向?qū)ο蠊こ?4面向構(gòu)件工程1.3.1軟件過程

ISO9000，軟件過程：“將輸入轉(zhuǎn)化成輸出的一系列彼此相關(guān)聯(lián)的資源、活動(dòng)?！避浖^程是為了開發(fā)出較高質(zhì)量的軟件所需實(shí)現(xiàn)的一系列任務(wù)框架。

軟件過程：將用戶需求轉(zhuǎn)化為軟件需求，進(jìn)而轉(zhuǎn)化為設(shè)計(jì)方案，并用代碼實(shí)現(xiàn)設(shè)計(jì)，繼而完成測試和各階段的文檔編制工作，最終確認(rèn)軟件可以部署實(shí)施的過程。1.3.2軟件生存周期軟件生存周期是指從軟件研發(fā)開始到軟件停用的整個(gè)過程，

即從提出開發(fā)需求，

經(jīng)過分析、設(shè)計(jì)、開發(fā)、使用和維護(hù)等階段，直到淘汰的整個(gè)過程。軟件生存周期是由軟件定義、開發(fā)與維護(hù)三個(gè)階段組成，

并且每個(gè)階段又可以進(jìn)一步分成多個(gè)階段。1.3.2軟件生存周期——階段一：軟件定義（1）問題定義：“項(xiàng)目需要解決哪些問題？”調(diào)查和研究，寫出任務(wù)性質(zhì)、項(xiàng)目目標(biāo)、項(xiàng)目規(guī)模的報(bào)告，討論和研究分析，修改，形成一份書面報(bào)告，獲得用戶的確認(rèn)。生成結(jié)果：問題定義報(bào)告。（2）可行性研究：對當(dāng)前項(xiàng)目的功能需求、技術(shù)及市場情況進(jìn)行調(diào)研，并結(jié)合實(shí)際進(jìn)行初步分析，明確是否可以啟動(dòng)該項(xiàng)目?？尚行匝芯渴且淮魏喕能浖治雠c設(shè)計(jì)過程?？尚行匝芯抗ぷ鞅容^簡短，只是從較高層次研究問題范圍，研究該問題是否可以解決，是否值得解決，是否有可行的解決方案。參與人員：技術(shù)主管、技術(shù)人員。結(jié)果：可行性研究報(bào)告、技術(shù)方面的調(diào)研報(bào)告。（3）項(xiàng)目啟動(dòng)：由技術(shù)主管或相關(guān)負(fù)責(zé)人制定合同，啟動(dòng)項(xiàng)目，由項(xiàng)目經(jīng)理制定項(xiàng)目初步計(jì)劃。結(jié)果：任務(wù)（項(xiàng)目）計(jì)劃書、項(xiàng)目合同。1.3.2軟件生存周期——軟件開發(fā)（研發(fā)）階段需求分析：明確軟件必須具有哪些功能、性能等。任務(wù)：對項(xiàng)目進(jìn)行詳細(xì)的需求分析，并編寫需求文檔。對于B/S結(jié)構(gòu)的軟件應(yīng)制作靜態(tài)頁面效果圖。用戶：一般不懂技術(shù)，往往無法完整準(zhǔn)確表達(dá)清楚要求；開發(fā)人員：不懂業(yè)務(wù)。需求分析階段，

系統(tǒng)分析員必須與用戶密切配合，充分溝通。參與者：項(xiàng)目經(jīng)理、項(xiàng)目小組核心成員結(jié)果：項(xiàng)目計(jì)劃修訂說明、需求分析說明書、靜態(tài)演示頁面1.3.2軟件生存周期——軟件開發(fā)（研發(fā)）階段概要設(shè)計(jì)：軟件的總體(外部)結(jié)構(gòu)、組成模塊、模塊的層次結(jié)構(gòu)、調(diào)用關(guān)系及功能進(jìn)行設(shè)計(jì)，并對總體數(shù)據(jù)結(jié)構(gòu)進(jìn)行設(shè)計(jì)。任務(wù)：

依據(jù)需求分析規(guī)格說明書，

為詳細(xì)設(shè)計(jì)提供基礎(chǔ)。參與者：項(xiàng)目小組核心成員、項(xiàng)目經(jīng)理、技術(shù)主管；結(jié)果：概要設(shè)計(jì)說明書。詳細(xì)設(shè)計(jì)：對模塊的功能、性能等在技術(shù)層面進(jìn)行完整準(zhǔn)確的描述，并轉(zhuǎn)化成過程描述。任務(wù)：將每個(gè)模塊進(jìn)行詳細(xì)設(shè)計(jì)，明確實(shí)現(xiàn)各模塊的算法與數(shù)據(jù)結(jié)構(gòu)。若軟件比較簡單，可不單獨(dú)編寫，相關(guān)內(nèi)容與概要設(shè)計(jì)說明書一起編寫。參與者：小組成員、項(xiàng)目經(jīng)理；生成結(jié)果：軟件詳細(xì)設(shè)計(jì)說明書、項(xiàng)目計(jì)劃確定版本。編碼實(shí)現(xiàn)：寫代碼。任務(wù)：根據(jù)詳細(xì)設(shè)計(jì)編程實(shí)現(xiàn)，美工對操作界面進(jìn)行美化。參與者：項(xiàng)目經(jīng)理、程序員、美工。生成結(jié)果：軟件版本說明、軟件產(chǎn)品規(guī)格說明。1.3.2軟件生存周期—軟件開發(fā)（研發(fā)）階段測試：確保軟件質(zhì)量。使用各種工具和方法對軟件的功能、性能進(jìn)行檢測。任務(wù)：項(xiàng)目經(jīng)理提交測試申請，由測試部門實(shí)施測試，項(xiàng)目小組配合測試部門完成錯(cuò)誤修改。參與者：測試部門、項(xiàng)目經(jīng)理、程序開發(fā)人員結(jié)果：測試申請書、測試計(jì)劃書、測試報(bào)告系統(tǒng)驗(yàn)收：對項(xiàng)目實(shí)施驗(yàn)收工作參與者：技術(shù)部門主管、項(xiàng)目經(jīng)理、用戶結(jié)果：項(xiàng)目所有文檔和程序軟件過程與軟件生命周期：1.3.2軟件生存周期軟件交付并投入使用后，

便進(jìn)入軟件維護(hù)階段。目的：讓軟件一直滿足用戶的需要。該階段是軟件生存周期的最后一

個(gè)階段，持續(xù)時(shí)間最長的階段。軟件維護(hù)階段1.4軟件開發(fā)過程模型

根據(jù)實(shí)踐的需要，對軟件開發(fā)過程進(jìn)行分類，形成多種風(fēng)格的軟件開發(fā)模型，稱為軟件生存周期模型，或稱為軟件開發(fā)范型。1.4.1瀑布模型軟件開發(fā)過程按照順序進(jìn)行，一步接著一步做。瀑布模型將軟件開發(fā)過程分為問題定義、可行性研究、需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、軟件實(shí)現(xiàn)、軟件測試、運(yùn)行維護(hù)。1.4.1瀑布模型瀑布模型較適合那些軟件需求較明確，開發(fā)技術(shù)較成熟，項(xiàng)目管理較嚴(yán)格的場合。使用瀑布模型實(shí)施項(xiàng)目具有3個(gè)特點(diǎn)：①按照順序開發(fā)軟件；②不要過早編程；③確保軟件質(zhì)量。各階段必須按照要求完成相關(guān)文檔資料的書寫和匯總，并且每個(gè)階段都要對書寫的文檔資料組織復(fù)審，及時(shí)發(fā)現(xiàn)相關(guān)隱患并排除。瀑布模型缺陷：將軟件實(shí)踐中相互疊加的過程分成若干階段。軟件規(guī)模越大帶來的問題越多。因此，人們對瀑布模型增加回溯和反饋的環(huán)節(jié)，對其加以改進(jìn)。1.4.2快速原型模型根據(jù)用戶的要求，先快速開發(fā)一個(gè)壓縮版的原型系統(tǒng)，并在此基礎(chǔ)上對客戶、潛在用戶進(jìn)行交流。

用戶對原型系統(tǒng)進(jìn)行評價(jià)，提出改進(jìn)意見，細(xì)化軟件需求。通過逐步構(gòu)建原型系統(tǒng)從而達(dá)到客戶要求，繼而準(zhǔn)確獲取客戶的實(shí)際需求；最終依據(jù)詳細(xì)且實(shí)際的需求組織開發(fā)軟件。1.4.3增量模型增量模型將一系列構(gòu)件實(shí)施集成和測試，每個(gè)構(gòu)件完成不同的功能，最終將其組合成在一起構(gòu)成完整功能軟件。增量模型的靈活性較強(qiáng)，較適用于需求不太明確、軟件設(shè)計(jì)方案具有一定風(fēng)險(xiǎn)的項(xiàng)目。見教材圖1.3。對比：瀑布模型是一種整體推進(jìn)的開發(fā)模型，

在進(jìn)行下一階

段的任務(wù)之前，

必須完成上一階段的工作。增量模型是一種非整體開發(fā)模型，

根據(jù)需要可以推遲某個(gè)階段甚至所有階段的具體細(xì)節(jié)，而較早實(shí)現(xiàn)軟件的研發(fā)。不過，增量模型也具有較明顯的缺陷。增量模型缺陷增量模型要求在研發(fā)的軟件具有開放式的體系架構(gòu)。原因是各個(gè)構(gòu)件是人工逐步并入到已存在的軟件體系結(jié)構(gòu)中的，因此，加入的新構(gòu)件不可以破壞已實(shí)現(xiàn)的軟件結(jié)構(gòu)。

對軟件過程的控制，容易失去整體性。實(shí)際的軟件開發(fā)中，用戶經(jīng)常對需求產(chǎn)生變化，在這方面，增量模型更適合這種變化，不過也很容易退化成一邊做一邊修改開發(fā)模型的情況。1.4.4螺旋模型計(jì)劃階段：明確軟件的目標(biāo)，確定最終實(shí)施方案，理清楚項(xiàng)目的約束條件；風(fēng)險(xiǎn)分析階段：評估選定的方案，設(shè)法識別并消除風(fēng)險(xiǎn)。實(shí)施階段：實(shí)施軟件開發(fā)，并對項(xiàng)目進(jìn)行驗(yàn)證。評估階段：對開發(fā)工作進(jìn)行評價(jià)，提出相應(yīng)的修改建議，并明確下一步的計(jì)劃。1.4.5噴泉模型噴泉模型以用戶的需求作為噴泉的起源，

以面向?qū)ο蠓椒榛A(chǔ)。開發(fā)過程可以分為四個(gè)階段：需求分析階段、總體設(shè)計(jì)階段、詳細(xì)設(shè)計(jì)階段、實(shí)現(xiàn)階段，并且每個(gè)階段可以繼續(xù)分成多個(gè)步驟。每個(gè)階段互相疊加，反映出軟件過程的并行性特征。解決了瀑布模型無法支持軟件重用及多個(gè)開發(fā)業(yè)務(wù)集成的問題，較適用于使用面向?qū)ο蠓椒ㄅc技術(shù)的項(xiàng)目。如圖1.5所示，展示了噴泉模型的特點(diǎn)：所示：1.4.7如何選定開發(fā)模型0102瀑布模型與原型模型是最常用的開發(fā)過程模型，

其次應(yīng)用較普遍的是增量模型。由于不同的模型具有不同的特點(diǎn)與優(yōu)缺點(diǎn)。到底如何選擇開發(fā)模型？（1）是否符合軟件自身的特點(diǎn)，其中包括軟件規(guī)模及其復(fù)雜性等方面。（2）是否滿足軟件開發(fā)的總體進(jìn)度要求。（3）盡可能識別軟件開發(fā)過程中的風(fēng)險(xiǎn)因素，并設(shè)法控制并消除這些風(fēng)險(xiǎn)。（4）是否具有相關(guān)輔助工具的支持，比如實(shí)現(xiàn)快速原型的工具。（5）選用模型是否與用戶和參與人員的知識背景及技能匹配。（6）是否有利于軟件項(xiàng)目的控制與管理。1.4.7如何選定開發(fā)模型

總結(jié)：事實(shí)上，

在實(shí)際的軟件開發(fā)過程中，

開發(fā)模型的選取不是照搬照抄，

需要依據(jù)開發(fā)目標(biāo)的要求實(shí)行修改、綜合運(yùn)用。討論和作業(yè)安排THEEND清華大學(xué)出版社第2章可行性研究張海藩，牟永敏編著第2章可行性研究并非任何問題都有簡單明顯的解決辦法，事實(shí)上，許多問題不可能在預(yù)定的系統(tǒng)規(guī)?；驎r(shí)間期限之內(nèi)解決。如果問題沒有可行的解，那么花費(fèi)在這項(xiàng)工程上的任何時(shí)間、人力、軟硬件資源和經(jīng)費(fèi)，都是無謂的浪費(fèi)。可行性研究的目的，就是用最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定問題是否能夠解決。主要內(nèi)容2.1可行性研究的任務(wù)2.2可行性研究過程2.3系統(tǒng)流程圖2.4數(shù)據(jù)流圖2.5數(shù)據(jù)字典2.6成本/效益分析主要內(nèi)容2.1可行性研究的任務(wù)2.2可行性研究過程2.3系統(tǒng)流程圖2.4數(shù)據(jù)流圖2.5數(shù)據(jù)字典2.6成本/效益分析2.1可行性研究的任務(wù)可行性研究的目的不是解決問題，而是確定問題是否值得去解決。首先，進(jìn)一步分析和澄清問題定義然后，分析員應(yīng)該導(dǎo)出系統(tǒng)的邏輯模型最后，探索若干種可供選擇的主要解法可行性研究分析過程：2.1

可行性研究的任務(wù)至少應(yīng)該從下述3個(gè)方面研究每種解法的可行性技術(shù)可行性使用現(xiàn)有的技術(shù)能實(shí)現(xiàn)這個(gè)系統(tǒng)嗎?經(jīng)濟(jì)可行性這個(gè)系統(tǒng)的經(jīng)濟(jì)效益能超過它的開發(fā)成本嗎?操作可行性系統(tǒng)的操作方式在這個(gè)用戶組織內(nèi)行得通嗎?主要內(nèi)容2.1可行性研究的任務(wù)2.2可行性研究過程2.3系統(tǒng)流程圖2.4數(shù)據(jù)流圖2.5數(shù)據(jù)字典2.6成本/效益分析2.2可行性研究過程怎樣進(jìn)行可行性研究呢?典型的可行性研究過程有下述8個(gè)步驟。復(fù)查系統(tǒng)規(guī)模和目標(biāo)研究目前正在使用的系統(tǒng)導(dǎo)出新系統(tǒng)的高層邏輯模型進(jìn)一步定義問題導(dǎo)出和評價(jià)供選擇的解法推薦行動(dòng)方針草擬開發(fā)計(jì)劃書寫文檔提交審查2.2

可行性研究過程復(fù)查系統(tǒng)規(guī)模和目標(biāo)分析員訪問關(guān)鍵人員，仔細(xì)閱讀和分析有關(guān)的材料，以便對問題定義階段書寫的關(guān)于規(guī)模和目標(biāo)的報(bào)告書進(jìn)一步復(fù)查確認(rèn)，改正含糊或不確切的敘述，清晰地描述對目標(biāo)系統(tǒng)的一切限制和約束。這個(gè)步驟的工作，實(shí)質(zhì)上是為了確保分析員正在解決的問題確實(shí)是要求他解決的問題。2.2可行性研究過程2.研究目前正在使用的系統(tǒng)現(xiàn)有的系統(tǒng)是信息的重要來源。顯然，如果目前有一個(gè)系統(tǒng)正被人使用，那么這個(gè)系統(tǒng)必定能完成某些有用的工作，因此，新的目標(biāo)系統(tǒng)必須也能完成它的基本功能；另一方面，如果現(xiàn)有的系統(tǒng)是完美無缺的，用戶自然不會(huì)提出開發(fā)新系統(tǒng)的要求，因此，現(xiàn)有的系統(tǒng)必然有某些缺點(diǎn)，新系統(tǒng)必須能解決舊系統(tǒng)中存在的問題。應(yīng)該仔細(xì)閱讀分析現(xiàn)有系統(tǒng)的文檔資料和使用手冊，也要實(shí)地考察現(xiàn)有的系統(tǒng)。常見的錯(cuò)誤做法是花費(fèi)過多時(shí)間去分析現(xiàn)有的系統(tǒng)。沒有一個(gè)系統(tǒng)是在“真空”中運(yùn)行的，絕大多數(shù)系統(tǒng)都和其他系統(tǒng)有聯(lián)系。2.2

可行性研究過程3.導(dǎo)出新系統(tǒng)的高層邏輯模型優(yōu)秀的設(shè)計(jì)過程通常是從現(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)。4.進(jìn)一步定義問題可行性研究的前4個(gè)步驟實(shí)質(zhì)上構(gòu)成一個(gè)循環(huán)。分析員定義問題，分析這個(gè)問題，導(dǎo)出一個(gè)試探性的解；在此基礎(chǔ)上再次定義問題，再一次分析這個(gè)問題，修改這個(gè)解；繼續(xù)這個(gè)循環(huán)過程，直到提出的邏輯模型完全符合系統(tǒng)目標(biāo)。2.2可行性研究過程5.導(dǎo)出和評價(jià)供選擇的解法分析員應(yīng)該從他建議的系統(tǒng)邏輯模型出發(fā)，導(dǎo)出若干個(gè)較高層次的物理解法供比較和選擇。其次可以考慮操作方面的可行性。分析員應(yīng)該根據(jù)使用部門處理事務(wù)的原則和習(xí)慣檢查技術(shù)上可行的那些方案，去掉其中從操作方式或操作過程的角度看用戶不能接受的方案。接下來應(yīng)該考慮經(jīng)濟(jì)方面的可行性。分析員應(yīng)該估計(jì)余下的每個(gè)可能的系統(tǒng)的開發(fā)成本和運(yùn)行費(fèi)用，并且估計(jì)相對于現(xiàn)有的系統(tǒng)而言這個(gè)系統(tǒng)可以節(jié)省的開支或可以增加的收入。最后為每個(gè)在技術(shù)、操作和經(jīng)濟(jì)等方面都可行的系統(tǒng)制定實(shí)現(xiàn)進(jìn)度表，這個(gè)進(jìn)度表不需要制定得很詳細(xì)，通常只需要估計(jì)生命周期每個(gè)階段的工作量。2.2可行性研究過程6.導(dǎo)出和評價(jià)供選擇的解法根據(jù)可行性研究結(jié)果應(yīng)該決定的一個(gè)關(guān)鍵性問題是：是否繼續(xù)進(jìn)行這項(xiàng)開發(fā)工程？分析員必須清楚地表明他對這個(gè)關(guān)鍵性決定的建議。如果分析員認(rèn)為值得繼續(xù)進(jìn)行這項(xiàng)開發(fā)工程，那么他應(yīng)該選擇一種最好的解法，并且說明選擇這個(gè)解決方案的理由。通常客戶主要根據(jù)經(jīng)濟(jì)上是否劃算決定是否投資于一項(xiàng)開發(fā)工程，因此分析員對于所推薦的系統(tǒng)必須進(jìn)行比較仔細(xì)的成本/效益分析。2.2

可行性研究過程7.草擬開發(fā)計(jì)劃分析員應(yīng)該為所推薦的方案草擬一份開發(fā)計(jì)劃，除了制定工程進(jìn)度表之外還應(yīng)該估計(jì)對各類開發(fā)人員和各種資源的需要情況，應(yīng)該指明什么時(shí)候使用以及使用多長時(shí)間。此外還應(yīng)該估計(jì)系統(tǒng)生命周期每個(gè)階段的成本。最后應(yīng)該給出下一個(gè)階段(需求分析)的詳細(xì)進(jìn)度表和成本估計(jì)。8.書寫文檔提交審查應(yīng)該把上述可行性研究各個(gè)步驟的工作結(jié)果寫成清晰的文檔，請用戶、客戶組織的負(fù)責(zé)人及評審組審查，以決定是否繼續(xù)這項(xiàng)工程及是否接受分析員推薦的方案。2.3

系統(tǒng)流程圖系統(tǒng)流程圖是概括地描繪物理系統(tǒng)的傳統(tǒng)工具。應(yīng)用：在進(jìn)行可行性研究時(shí)，需要分析現(xiàn)有系統(tǒng)，并以概括的形式表達(dá)對現(xiàn)有系統(tǒng)的認(rèn)識；進(jìn)入設(shè)計(jì)階段以后，也需要把新系統(tǒng)的邏輯模型轉(zhuǎn)變成物理模型，需要描繪未來的物理系統(tǒng)的概貌?；舅枷耄河脠D形符號以黑盒子形式描繪組成系統(tǒng)的每個(gè)部件(程序、文檔、數(shù)據(jù)庫、人工過程等)。系統(tǒng)流程圖表達(dá)的是數(shù)據(jù)在系統(tǒng)各部件之間流動(dòng)的情況，而不是對數(shù)據(jù)進(jìn)行加工處理的控制過程，因此盡管系統(tǒng)流程圖的某些符號和程序流程圖的符號形式相同，但是它卻是物理數(shù)據(jù)流圖而不是程序流程圖。第2章可行性研究2.1可行性研究的任務(wù)2.2可行性研究過程2.3系統(tǒng)流程圖2.4數(shù)據(jù)流圖2.5數(shù)據(jù)字典2.6成本/效益分析2.3系統(tǒng)流程圖2.3.1符號當(dāng)以概括的方式抽象地描繪一個(gè)實(shí)際系統(tǒng)時(shí)，僅僅使用圖2.1中列出的基本符號就可以了。見課本P39頁。當(dāng)需要更具體地描繪一個(gè)物理系統(tǒng)時(shí)，還需要更多的符號。見課本P39頁圖2.2。利用這些符號可以把一個(gè)廣義的輸入輸出操作具體化為讀寫存儲(chǔ)在特殊設(shè)備上的文件（或數(shù)據(jù)庫），把抽象處理具體化為特定的程序或手工操作等。2.3系統(tǒng)流程圖以概括的方式抽象地描繪一個(gè)實(shí)際系統(tǒng)時(shí)，僅僅使用下圖中列出的基本符號就足夠了需要更具體地描繪一個(gè)物理系統(tǒng)時(shí)還需要使用右圖中列出的系統(tǒng)符號2.3

系統(tǒng)流程圖以一個(gè)簡單的例子進(jìn)行講解。某裝配廠有一座存放零件的倉庫，倉庫中現(xiàn)有的各種零件的數(shù)量以及每種零件的庫存量臨界值等數(shù)據(jù)記錄在庫存清單主文件中。當(dāng)倉庫中零件數(shù)量有變化時(shí)，應(yīng)該及時(shí)修改庫存清單主文件，如果哪種零件的庫存量少于它的庫存量臨界值，則應(yīng)該報(bào)告給采購部門以便訂貨，規(guī)定每天向采購部門送一次訂貨報(bào)告。2.3.2例子2.3

系統(tǒng)流程圖該裝配廠使用一臺(tái)小型計(jì)算機(jī)處理更新庫存清單主文件和產(chǎn)生訂貨報(bào)告的任務(wù)。零件庫存量的每一次變化稱為一個(gè)事務(wù)，由放在倉庫中的CRT終端輸入到計(jì)算機(jī)中；系統(tǒng)中的庫存清單程序?qū)κ聞?wù)進(jìn)行處理，更新存儲(chǔ)在磁盤上的庫存清單主文件，并且把必要的訂貨信息寫在磁帶上。最后，每天由報(bào)告生成程序讀一次磁帶，并且打印出訂貨報(bào)告。如下圖所示。2.3系統(tǒng)流程圖一個(gè)比較好的方法是分層次描繪這個(gè)系統(tǒng)。首先用一張高層次的系統(tǒng)流程圖描繪系統(tǒng)總體概況，表明系統(tǒng)的關(guān)鍵功能。然后分別把每個(gè)關(guān)鍵功能擴(kuò)展到適當(dāng)?shù)脑敿?xì)程度，畫在單獨(dú)的一頁紙上。這種分層次的描繪方法便于閱讀者按從抽象到具體的過程逐步深入地了解一個(gè)復(fù)雜的系統(tǒng)。2.3.3分層面對復(fù)雜的系統(tǒng)時(shí)，怎么辦？主要內(nèi)容2.1可行性研究的任務(wù)2.2可行性研究過程2.3系統(tǒng)流程圖2.4數(shù)據(jù)流圖2.5數(shù)據(jù)字典2.6成本/效益分析2.4

數(shù)據(jù)流圖概念

數(shù)據(jù)流圖(DFD)是一種圖形化技術(shù)，它描繪信息流和數(shù)據(jù)從輸入移動(dòng)到輸出的過程中所經(jīng)受的變換。當(dāng)數(shù)據(jù)在軟件系統(tǒng)中移動(dòng)時(shí)，它將被一系列“變換”所修改。數(shù)據(jù)流圖中，沒有任何具體的物理部件，它只是描繪數(shù)據(jù)在軟件中流動(dòng)和被處理的邏輯過程。數(shù)據(jù)流圖是系統(tǒng)邏輯功能的圖形表示，即使不是專業(yè)的計(jì)算機(jī)技術(shù)人員也容易理解它。因此，數(shù)據(jù)流圖是分析員和用戶之間極好的通信工具。2.4

數(shù)據(jù)流圖2.4.1

符號正方形表示數(shù)據(jù)的源點(diǎn)或終點(diǎn)圓角矩形代表變換數(shù)據(jù)的處理開口矩形代表數(shù)據(jù)存儲(chǔ)箭頭表示數(shù)據(jù)流，即特定數(shù)據(jù)的流動(dòng)方向數(shù)據(jù)流四中基本符號附加符號基本符號

注意：

“處理”并不一定是一個(gè)程序。一個(gè)處理框可以代表程序的一個(gè)模塊、單個(gè)程序或一系列程序，也可以是人工處理過程（比如人工檢查數(shù)據(jù)正確性）。

“數(shù)據(jù)存儲(chǔ)”也不等同于一個(gè)文件，它可以表示一個(gè)文件、文件的一部分、數(shù)據(jù)庫的元素或者記錄的一部分。（例如查詢操作、修改某個(gè)記錄、某個(gè)字段）數(shù)據(jù)可以存儲(chǔ)在磁盤、磁帶、主存、磁鼓、微縮膠片、穿孔卡片等介質(zhì)上。數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)流的區(qū)別？

靜止、運(yùn)動(dòng)

注意：

數(shù)據(jù)流圖基本要點(diǎn)：描繪“做什么”，不考慮“怎樣做”。在數(shù)據(jù)流圖中應(yīng)該描繪所有可能的數(shù)據(jù)流向，而不應(yīng)該描繪出現(xiàn)某個(gè)數(shù)據(jù)流的條件。通常在數(shù)據(jù)流圖中忽略出錯(cuò)處理，也不包括諸如打開或者關(guān)閉文件等內(nèi)務(wù)處理。

易混淆的地方：數(shù)據(jù)流與程序流程圖（見P106圖5.10）中用箭頭表示的控制流有本質(zhì)區(qū)別，不要混淆。對程序流程圖比較熟悉的學(xué)生，在畫數(shù)據(jù)流圖時(shí)，往往試圖在數(shù)據(jù)流圖中表現(xiàn)分支條件或循環(huán)，這是錯(cuò)誤的，容易引起混亂。

2.4

數(shù)據(jù)流圖以簡單例子說明怎樣畫數(shù)據(jù)流圖？

假設(shè)一家工廠的采購部每天需要一張訂貨報(bào)表，報(bào)表按零件編號排序，表中列出所有需要再次訂貨的零件。對于每個(gè)需要再次訂貨的零件應(yīng)該列出下述數(shù)據(jù)：零件編號，零件名稱，訂貨數(shù)量，目前價(jià)格，主要供應(yīng)者，次要供應(yīng)者。零件入庫或出庫稱為事務(wù)，通過放在倉庫中的CRT終端把事務(wù)報(bào)告給訂貨系統(tǒng)。當(dāng)某種零件的庫存數(shù)量少于庫存量臨界值時(shí)就應(yīng)該再次訂貨。如何畫該系統(tǒng)的數(shù)據(jù)流程圖呢？2.4.2

例子2.4

數(shù)據(jù)流圖首先考慮數(shù)據(jù)的源點(diǎn)和終點(diǎn)，從上面對系統(tǒng)的描述可以知道“采購部每天需要一張訂貨報(bào)表”，“通過放在倉庫中的CRT終端把事務(wù)報(bào)告給訂貨系統(tǒng)”，所以采購員是數(shù)據(jù)終點(diǎn)，而倉庫管理員是數(shù)據(jù)源點(diǎn)。第一步可以從問題描述中提取數(shù)據(jù)流圖的4種成分：源點(diǎn)或終點(diǎn)、處理、數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)流2.4

數(shù)據(jù)流圖因此必須有一個(gè)用于產(chǎn)生報(bào)表的處理。事務(wù)的后果是改變零件庫存量，然而任何改變數(shù)據(jù)的操作都是處理，因此對事務(wù)進(jìn)行的加工是另一個(gè)處理。注意，在問題描述中并沒有明顯地提到需要對事務(wù)進(jìn)行處理，但是通過分析可以看出這種需要。第二步：接下來考慮處理，再一次閱讀問題描述，“采購部需要報(bào)表”，顯然采購部沒有這種報(bào)表2.4

數(shù)據(jù)流圖系統(tǒng)把訂貨報(bào)表送給采購部，因此訂貨報(bào)表是一個(gè)數(shù)據(jù)流；事務(wù)需要從倉庫送到系統(tǒng)中，顯然事務(wù)是另一個(gè)數(shù)據(jù)流。(此例子的事務(wù)指：零件入庫或出庫)產(chǎn)生報(bào)表和處理事務(wù)這兩個(gè)處理在時(shí)間上明顯不匹配——每當(dāng)有一個(gè)事務(wù)發(fā)生時(shí)立即處理它，然而每天只產(chǎn)生一次訂貨報(bào)表。因此，用來產(chǎn)生訂貨報(bào)表的數(shù)據(jù)必須存放一段時(shí)間，也就是應(yīng)該有一個(gè)數(shù)據(jù)存儲(chǔ)。下表給出了上述分析成果，其中加星號標(biāo)記的是在問題描述中隱含的成分。第三步：最后，我們考慮數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)分析結(jié)果步驟一：

把數(shù)據(jù)流圖的4種成分都分離出來以后（上圖所示），就可以著手畫數(shù)據(jù)流圖了步驟二：步驟三：把基本系統(tǒng)模型細(xì)化，描繪系統(tǒng)的主要功能步驟四：對功能級數(shù)據(jù)流圖中描繪的系統(tǒng)主要功能進(jìn)一步細(xì)化2.4

數(shù)據(jù)流圖

數(shù)據(jù)流圖中每個(gè)成分的命名是否恰當(dāng)，直接影響數(shù)據(jù)流圖的可理解性。因此，給這些成分起名字時(shí)應(yīng)該仔細(xì)推敲。2.4.3

命名2.4數(shù)據(jù)流圖數(shù)據(jù)流命名時(shí)應(yīng)注意的問題名字應(yīng)代表整個(gè)數(shù)據(jù)流的內(nèi)容，而不是僅僅反映它的某些成分不要使用空洞的、缺乏具體含義的名字在為某個(gè)數(shù)據(jù)流(或數(shù)據(jù)存儲(chǔ))起名字時(shí)遇到了困難，則很可能是因?yàn)閷?shù)據(jù)流圖分解不恰當(dāng)造成的，應(yīng)該試試重新分解2.4

數(shù)據(jù)流圖為處理命名時(shí)應(yīng)注意的問題通常先為數(shù)據(jù)流命名，然后再為與之相關(guān)聯(lián)的處理命名。名字應(yīng)該反映整個(gè)處理的功能，而不是它的一部分功能。名字最好由一個(gè)具體的及物動(dòng)詞加上一個(gè)具體的賓語組成。通常名字中僅包括一個(gè)動(dòng)詞，如果必須用兩個(gè)動(dòng)詞才能描述整個(gè)處理的功能，則把這個(gè)處理再分解成兩個(gè)處理可能更恰當(dāng)些。如果在為某個(gè)處理命名時(shí)遇到困難，則很可能是發(fā)現(xiàn)了分解不當(dāng)?shù)嫩E象，應(yīng)考慮重新分解。2.4數(shù)據(jù)流圖1、畫數(shù)據(jù)流圖的基本目的是利用它作為交流信息的工具。2、數(shù)據(jù)流圖的另一個(gè)主要用途是作為分析和設(shè)計(jì)的工具。3、數(shù)據(jù)流圖輔助物理系統(tǒng)的設(shè)計(jì)時(shí)，以圖中不同處理的定時(shí)要求為指南，能夠在數(shù)據(jù)流圖上畫出許多組自動(dòng)化邊界，每組自動(dòng)化邊界可能意味著一個(gè)不同的物理系統(tǒng)。4、一張數(shù)據(jù)流圖包含多少個(gè)元素合適？分層，把功能級數(shù)據(jù)流圖細(xì)化后得到的處理超過9個(gè)時(shí)，應(yīng)該畫分圖。2.4.4

用途主要內(nèi)容2.1可行性研究的任務(wù)2.2可行性研究過程2.3系統(tǒng)流程圖2.4數(shù)據(jù)流圖2.5數(shù)據(jù)字典2.6成本/效益分析2.5

數(shù)據(jù)字典概念

數(shù)據(jù)字典是關(guān)于數(shù)據(jù)的信息的集合，也就是對數(shù)據(jù)流圖中包含的所有元素的定義的集合。2.5數(shù)據(jù)字典2.5.1

內(nèi)容數(shù)據(jù)字典數(shù)據(jù)流數(shù)據(jù)存儲(chǔ)處理數(shù)據(jù)流分量

一般說來，數(shù)據(jù)字典應(yīng)該由對下列4類元素的定義組成。數(shù)據(jù)元素的別名就是該元素的其他等價(jià)的名字，出現(xiàn)別名主要有下述3個(gè)原因：對于同樣的數(shù)據(jù)，不同的用戶使用了不同的名字。一個(gè)分析員在不同時(shí)期對同一個(gè)數(shù)據(jù)使用了不同的名字。兩個(gè)分析員分別分析同一個(gè)數(shù)據(jù)流時(shí)，使用了不同的名字。2.5

數(shù)據(jù)字典2.5

數(shù)據(jù)字典由數(shù)據(jù)元素組成數(shù)據(jù)的方式只有下述3種基本類型：順序即以確定次序連接兩個(gè)或多個(gè)分量。選擇即從兩個(gè)或多個(gè)可能的元素中選取一個(gè)。重復(fù)即把指定的分量重復(fù)零次或多次。2.5.2定義數(shù)據(jù)的方法2.5

數(shù)據(jù)字典第4種關(guān)系算符=意思是等價(jià)于(或定義為)；+意思是和(即連接兩個(gè)分量)；［］意思是或(即從方括弧內(nèi)列出的若干個(gè)分量中選擇一個(gè))，通常用“|”號隔開供選擇的分量；{}意思是重復(fù)(即重復(fù)花括弧內(nèi)的分量)；()意思是可選(即圓括弧里的分量可有可無)。2.5

數(shù)據(jù)字典2.5.3

數(shù)據(jù)字典的用途數(shù)據(jù)字典最重要的用途是作為分析階段的工具數(shù)據(jù)字典中包含的每個(gè)數(shù)據(jù)元素的控制信息是很有價(jià)值的數(shù)據(jù)字典是開發(fā)數(shù)據(jù)庫的第一步，而且是很有價(jià)值的一步。2.5數(shù)據(jù)字典目前，數(shù)據(jù)字典幾乎總是作為CASE“結(jié)構(gòu)化分析與設(shè)計(jì)工具”的一部分實(shí)現(xiàn)的。在開發(fā)大型軟件系統(tǒng)的過程中，數(shù)據(jù)字典的規(guī)模和復(fù)雜程度迅速增加，人工維護(hù)數(shù)據(jù)字典幾乎是不可能的。2.5.4數(shù)據(jù)字典的實(shí)現(xiàn)2.5

數(shù)據(jù)字典在開發(fā)小型軟件系統(tǒng)時(shí)暫時(shí)沒有數(shù)據(jù)字典處理程序，建議采用卡片形式書寫數(shù)據(jù)字典，每張卡片上保存描述一個(gè)數(shù)據(jù)的信息。下面給出第2.4節(jié)的例子中幾個(gè)數(shù)據(jù)元素的數(shù)據(jù)字典卡片，以具體說明數(shù)據(jù)字典卡片中上述幾項(xiàng)內(nèi)容的含義。2.5.4數(shù)據(jù)字典的實(shí)現(xiàn)2.5

數(shù)據(jù)字典2.6成本/效益分析主要內(nèi)容2.1可行性研究的任務(wù)2.2可行性研究過程2.3系統(tǒng)流程圖2.4數(shù)據(jù)流圖2.5數(shù)據(jù)字典2.6成本/效益分析第2章可行性研究2.6成本/效益分析軟件開發(fā)成本主要表現(xiàn)為人力消耗(乘以平均工資則得到開發(fā)費(fèi)用)。成本估計(jì)不是精確的科學(xué)，因此應(yīng)該使用幾種不同的估計(jì)技術(shù)以便相互校驗(yàn)。下面簡單介紹3種估算技術(shù)。2.6.1

成本估計(jì)代碼行技術(shù)任務(wù)分解技術(shù)自動(dòng)估計(jì)成本技術(shù)2.6成本/效益分析任務(wù)分解技術(shù)最常用的辦法是按開發(fā)階段劃分任務(wù)。典型環(huán)境下各個(gè)開發(fā)階段需要使用的人力的百分比大致如下表所示:2.6成本/效益分析成本/效益分析方法主要從四個(gè)方面考慮2.6.2

成本/效益分析的方法貨幣的時(shí)間價(jià)值投資回收期純收入投資回收率貨幣的時(shí)間價(jià)值通常用利率的形式表示貨幣的時(shí)間價(jià)值。假設(shè)年利率為i，如果現(xiàn)在存入P元，則n年后可以得到的錢數(shù)為：F=P(1+i)n這也就是P元錢在n年后的價(jià)值。反之，如果n年后能收入F元錢，那么這些錢的現(xiàn)在價(jià)值是：P=F/(1+i)n2.6成本/效益分析2.6.2成本/效益分析的方法第2章可行性研究貨幣的時(shí)間價(jià)值

例如，修改一個(gè)已有的庫存清單系統(tǒng)，使它能在每天送給采購員一份訂貨報(bào)表。修改已有的庫存清單程序并且編寫產(chǎn)生報(bào)表的程序，估計(jì)共需5000元；系統(tǒng)修改后能及時(shí)訂貨，這將消除零件短缺問題，估計(jì)因此每年可以節(jié)省2500元，5年共可節(jié)省12500元。但是，不能簡單地把5000元和12500元相比較，因?yàn)榍罢呤乾F(xiàn)在投資的錢，后者是若干年以后節(jié)省的錢。

假定年利率為12%，利用上面計(jì)算貨幣現(xiàn)在價(jià)值的公式可以算出修改庫存清單系統(tǒng)后每年預(yù)計(jì)節(jié)省的錢的現(xiàn)在價(jià)值，如下表所示。2.6成本/效益分析貨幣的時(shí)間價(jià)值2.6成本/效益分析本章小結(jié)1.了解可行性研究的必要性，以及如何進(jìn)行可行性研究2.學(xué)習(xí)系統(tǒng)流程圖、數(shù)據(jù)流圖3.學(xué)習(xí)數(shù)據(jù)字典的概念、用途及實(shí)現(xiàn)4.成本/效益分析方法本章結(jié)束第3章

需求分析需求分析01需求分析

可行性研究的目標(biāo)：在較短的時(shí)間內(nèi)用較小的代價(jià)給出項(xiàng)目是否可行的方案。因此，在可行性階段，軟件開發(fā)團(tuán)隊(duì)只是掌握了用戶的軟件項(xiàng)目目標(biāo)和大體的功能要求，因此，如果想開發(fā)出符合用戶要求的軟件，必須進(jìn)行用戶需求分析。

在整個(gè)軟件研發(fā)過程中，需求分析是一個(gè)特別重要的階段。是否完整準(zhǔn)確的獲取用戶需

求，關(guān)系軟件研發(fā)的成敗。需求分析的主要任務(wù)是確定軟件必須“做什么”，即確定軟件的功能需求、性能需求、可靠性等要求。最后，軟件分析員（產(chǎn)品經(jīng)理）應(yīng)寫出《需求規(guī)格說

明書》，以文字、表格、模型等形式描述軟件的需求。注意，《需求分析規(guī)格說明書》的書寫工作是一項(xiàng)非常復(fù)雜且艱巨的任務(wù)。系統(tǒng)分析員與用戶之間需溝通的信息非常多，并且在交流過程中，

很容易遺漏重要信息，經(jīng)常會(huì)產(chǎn)生二義性。所以，較全面地掌握需求分析技術(shù)是非常重要的工作。3.1任務(wù)與步驟

需求分析明確用戶需求

需求分析(RequirementsAnalysis)是為了明確用戶的具體需求，主要包括功能需求、數(shù)據(jù)需求、性能需求、可靠性與安全性要求、拓展要求以及運(yùn)行環(huán)境等要求，并且創(chuàng)建軟件的邏輯模型，寫出“軟件需求規(guī)格說明(SRS)”等文檔。

首先，進(jìn)行用戶意圖分析。將用戶提出來的各種問題和要求進(jìn)行歸納整理，通常而言，

用戶需求反映在說明書上是功能點(diǎn)列表、數(shù)據(jù)列表、流程等內(nèi)容，

不是站在軟件開發(fā)人員的

角度說明問題。因此，

需要既懂技術(shù)又懂業(yè)務(wù)的系統(tǒng)分析員獲取用戶需求，

搞清楚用戶實(shí)際上要做什么，應(yīng)該做什么，并且把獲取的信息清晰明確地表達(dá)出來。

其次，

對用戶需求進(jìn)行規(guī)范化。當(dāng)搞清楚用戶需求后，

在《需求規(guī)格說明書》中建立系

統(tǒng)分析模型，完整、準(zhǔn)確且規(guī)范地描述將要開發(fā)的軟件，

務(wù)必與用戶一起確認(rèn)，

保證它能夠完全符合用戶的要求。3.1.1任務(wù)需求分析的主要任務(wù)是？？？3.1.1任務(wù)1.用戶要求功能需求即將開發(fā)的軟件必須實(shí)現(xiàn)的功能，通過功能列表列出軟件必須實(shí)現(xiàn)的全部功能。該部分是最重要的工作。性能需求性能需求是指所開發(fā)軟件的技術(shù)性能指標(biāo)，

即系統(tǒng)需要滿足哪些約束條件，

通常情況下括軟件平均響應(yīng)時(shí)間、安全性、網(wǎng)絡(luò)速率、服務(wù)器配置等方面的要求。環(huán)境需求系統(tǒng)在運(yùn)行時(shí)需要各種軟、硬件條件。比如該軟件對服務(wù)器、操作系統(tǒng)、外設(shè)、數(shù)據(jù)庫軟件等具體要求。3.1.1任務(wù)接口需求描述軟件與外部環(huán)境通信的要求，

常見的形式有：

硬件接口需求、用戶接口需求、通信接口需求、軟件接口需求。界面需求用戶界面是人機(jī)交互的媒介，界面是否美觀大方也是用戶非?？粗氐?。未來需求通過與用戶交流，

列出不屬于當(dāng)前開發(fā)范疇的需求。

不過，

根據(jù)分析業(yè)務(wù)或行業(yè)發(fā)展趨勢，未來非?？赡苄枰瓿傻墓δ?，便于后期擴(kuò)展軟件功能。3.1.1任務(wù)2.分析數(shù)據(jù)需求

分析軟件的數(shù)據(jù)需求。數(shù)據(jù)由數(shù)據(jù)元素組成。使用數(shù)據(jù)字典對數(shù)據(jù)進(jìn)行全面地描述和

定義。數(shù)據(jù)字典缺點(diǎn)：不直觀。使用圖形工具來輔助，

層次方框圖和Warnier圖。3.創(chuàng)建系統(tǒng)的邏輯模型

結(jié)合上述獲取的結(jié)果進(jìn)行分析與確認(rèn)，

以確保軟件的組成及主要元素是否全面，

并用圖

文與符號結(jié)合的方式，

導(dǎo)出軟件的邏輯模型，

一般會(huì)用到數(shù)據(jù)流圖（DFD）、狀態(tài)轉(zhuǎn)換圖、實(shí)體聯(lián)系圖（E-R圖）、數(shù)據(jù)字典及主要的算法描述該邏輯模型。4.編寫軟件需求報(bào)告

明確定義目標(biāo)軟件的需求、軟件構(gòu)成及相關(guān)的接口。軟件需求規(guī)格說明書：準(zhǔn)確體現(xiàn)用戶真實(shí)需求，

易理解、直觀、易修改等特點(diǎn)。盡可能采用標(biāo)準(zhǔn)的表格、圖形與簡單容易的符號表示，不用專業(yè)性強(qiáng)的術(shù)語，讓用戶看懂，便于交流。3.1.1任務(wù)5.需求分析評審（2）

構(gòu)建評審小組，

組織評審并修改需求和開發(fā)計(jì)劃。確?！败浖枨笠?guī)格說明”真實(shí)無遺漏地反映用戶的需求。（1）需求分析規(guī)格說明書需要經(jīng)過嚴(yán)格且仔細(xì)的評審，主要是查找需求分析過程中存在的缺陷、錯(cuò)誤；3.1.2關(guān)于需求分析步驟01獲取用戶需求調(diào)查研究法。需求獲取階段，不同的系統(tǒng)開發(fā)方法，采取不同的方式。02提煉用戶需求分析建模法。將用戶提供的信息創(chuàng)建分析模型。包含數(shù)據(jù)流圖、E-R圖，狀態(tài)轉(zhuǎn)換圖、控制流圖等。04驗(yàn)證用戶需求系統(tǒng)分析員與用戶一起對需求分析說明書進(jìn)行仔細(xì)、嚴(yán)格的驗(yàn)證、審查。03描述用戶需求編寫《用戶需求規(guī)格說明書》。3.2.1常用方法對重要用戶組織訪談訪談是最早使用且至今仍廣泛適用的需求分析技術(shù)?？蛻粼L談既能熟悉高層的戰(zhàn)略需求，又可以聽取普通用戶的需求?？蛻粼L談可以分為正式的與非正式的。采訪用戶：采用情景分析法；調(diào)查大量人員的意見：發(fā)放調(diào)查表。組建軟件聯(lián)合分析小組由用戶、系統(tǒng)分析人員、領(lǐng)域內(nèi)專家一起組建的軟件聯(lián)合分析小組。這樣對軟件分析員、用戶之間的交流以及需求獲取非常有用。3.2.1常用方法相關(guān)問題的分析、確認(rèn)

使用傳統(tǒng)的需求獲取方法獲取用戶的需求時(shí)，容易讓用戶產(chǎn)生被動(dòng)的感覺。采用面向團(tuán)隊(duì)的需求獲取方法，簡易的應(yīng)用規(guī)格說明技術(shù)。

開發(fā)者與用戶

一起標(biāo)識問題，

共同提出解決方案，討論不同方案以及共同指定基本需求。

優(yōu)點(diǎn)：用戶與開發(fā)者齊心協(xié)力、不分彼此、密切配合，

一起完成需求獲取工作。

用戶很難在一兩次的交談中闡述清楚需求，需要進(jìn)行多次訪問，訪問后，

須及時(shí)整理并分析用戶提供的信息，

排除無關(guān)信息以及錯(cuò)誤信息，整理有價(jià)值內(nèi)容，便于與用戶下一次見面交流時(shí)，

由用戶確認(rèn)，

并籌備下次訪問用戶時(shí)，

進(jìn)一步理清細(xì)節(jié)。3.2.1常用方法——合作開展需求分析？初步交流，籌備會(huì)議①通過一兩次的交流，初步明確待解決的問題范圍以及解決方案；②用戶、開發(fā)者分別寫出“軟件需求”，選定商談會(huì)議時(shí)間、地點(diǎn)，指定協(xié)調(diào)人。嚴(yán)格審查各自需求，確定需求列表在會(huì)前幾天，每位與會(huì)者須仔細(xì)審查軟件需求，并且詳細(xì)列出功能列表、約束條件列表和性能列表。經(jīng)過上會(huì)討論，創(chuàng)建組合列表雙方與會(huì)者展示列表，經(jīng)過大家討論后，共同創(chuàng)建一份組合列表。由指定的協(xié)調(diào)人主持并討論這些列表。根據(jù)實(shí)際情況進(jìn)行分組，制定更細(xì)的規(guī)格說明根據(jù)需要，將與會(huì)者劃分成更小的小組，每個(gè)小組都要將其制定的小型規(guī)格說明向與會(huì)者展示，并且供大家討論。完善并確認(rèn)標(biāo)準(zhǔn)，草擬需求規(guī)格說明報(bào)告全體與會(huì)者制定軟件的確認(rèn)標(biāo)準(zhǔn)，并提交討論，擬寫完整的《軟件需求規(guī)格說明書》。3.2.2快速建立軟件原型模型來獲取需求

在軟件開發(fā)中，快速原型法是常用的一種用戶需求獲取方法?？焖僭头ǖ幕舅悸罚?/p>

在很短時(shí)間內(nèi)建立一個(gè)包含基本數(shù)據(jù)庫和基礎(chǔ)功能的軟件提供用戶試用，依據(jù)用戶意見對原型實(shí)施修改，直到用戶滿意。是否采用快速原型法，采用以下6個(gè)問題判斷：當(dāng)前用戶的需求已經(jīng)建立，并且需求是穩(wěn)定的嗎？(×)項(xiàng)目研發(fā)人員與用戶已理解目標(biāo)軟件的應(yīng)用場景嗎？(√)當(dāng)前的問題是否可以被模型化？(√)是否用戶可以明確系統(tǒng)的基本需求？(√)是否存在模糊的需求？(√)已知的需求中存在矛盾嗎？(√)需求分析的常用方法

系統(tǒng)分析員獲取用戶需求停留在文字、圖表階段，

需用專業(yè)方法分析理清楚用戶的實(shí)際需求轉(zhuǎn)變成邏輯模型。

方法1—功能分解法：將一個(gè)軟件看作由若干個(gè)功能組成的集合，且每個(gè)功能又可進(jìn)一步劃分成若干子功能，并且一個(gè)子功能又可以繼續(xù)分解為若干子功能。因此，這種方法最終產(chǎn)生主功能、子功能與功能接口，該方法是最早應(yīng)用于需求分析的方法。該方法將系統(tǒng)需求當(dāng)作一棵倒過來的功能樹，

其中每個(gè)節(jié)點(diǎn)代表一個(gè)具體的功能，因此，樹根是總功能，

而樹枝是子功能，最終樹葉為子功能的子功能。功能分解法依據(jù)“自頂向下、逐步求精”的方式，這也符合傳統(tǒng)程序設(shè)計(jì)人員的思維特征，不過，這種方法很難與系統(tǒng)設(shè)計(jì)分開，所以，較難適應(yīng)需求的變化。

方法2—結(jié)構(gòu)化分析方法：普遍采用的一種結(jié)構(gòu)化分析方法，是從問題空間到具體映射方法，軟件的功能是由數(shù)據(jù)流圖表示，即由數(shù)據(jù)流圖與數(shù)據(jù)字典共同組成的邏輯模型。此方法使用起來簡單，更適用于數(shù)據(jù)的處理領(lǐng)域。具體內(nèi)容將在3.4節(jié)中介紹。

方法3—信息建模方法：此方法的基本表達(dá)工具是E-R圖，由實(shí)體、屬性與聯(lián)系組成。此方法從需求資料中找到實(shí)體，再用屬性描述實(shí)體。ER圖是面向?qū)ο蠓治黾夹g(shù)的基礎(chǔ)，不過它的數(shù)據(jù)是不封閉的無繼承機(jī)制，也沒有消息傳遞機(jī)制的支持。

方法4—面向?qū)ο蟮姆椒ǎ簩-R圖與面向?qū)ο蟮某绦蛟O(shè)計(jì)語言相關(guān)概念結(jié)合后構(gòu)成一種新的分析方法。面向?qū)ο?/p>

分析技術(shù)的關(guān)鍵是識別、定義類、對象，并分析出它們的關(guān)系，

依據(jù)問題域的操作規(guī)則及內(nèi)存性質(zhì)而建立的模型。（軟件項(xiàng)目、畢業(yè)設(shè)計(jì)常用）3.4結(jié)構(gòu)化分析的方法介紹

結(jié)構(gòu)化開發(fā)方法是軟件研發(fā)方法中應(yīng)用最廣泛、最成熟的一種方法。其特點(diǎn)是自然、快速。該方法的思想是“自頂向下、逐步求精”（如圖3.1所示），它的基本原則分為兩步：

抽象與分解。

（1）分解。面對較復(fù)雜的問題，通常將其分解成若干個(gè)相對容易的小問題，然后再進(jìn)

一步解決。

一般情況，

可以忽略細(xì)節(jié)，

即先考慮問題的本質(zhì)，

構(gòu)成問題的高層次概念；

然后再逐步添加細(xì)節(jié)。

（2）抽象。在分析問題時(shí)，事先考慮問題最重要的屬性，暫時(shí)忽略細(xì)節(jié)，再逐層增加細(xì)節(jié)，直到實(shí)現(xiàn)全部內(nèi)容。

對于復(fù)雜的軟件系統(tǒng)，系統(tǒng)分析工作都可以依據(jù)上面的策略進(jìn)行有計(jì)劃和按步驟推進(jìn)。3.4.2面向結(jié)構(gòu)化分析的建模工具

數(shù)據(jù)流圖：

一種圖形化的系統(tǒng)模型。運(yùn)用圖形方式描述系統(tǒng)內(nèi)部的數(shù)據(jù)流，表達(dá)系統(tǒng)的各處理環(huán)節(jié)之間的數(shù)據(jù)聯(lián)系，是結(jié)構(gòu)化系統(tǒng)分析方法的表達(dá)工具。

數(shù)據(jù)字典：對數(shù)據(jù)流圖中的元素進(jìn)行定義的集合。比如，可以定義數(shù)據(jù)流圖中的“加工”和“數(shù)據(jù)”。

結(jié)構(gòu)化語言：是一種介于形式語言與自然語言的半形式化語言。結(jié)構(gòu)化語言具有三種形式，分別是順序結(jié)構(gòu)、循環(huán)結(jié)構(gòu)、選擇結(jié)構(gòu)。

判定樹：又稱為決策樹，它的思路和結(jié)構(gòu)化語言幾乎完全類似，主要用它描述某個(gè)功能模塊的邏輯處理過程。

判定表即決策表，相對于決策樹而言，其優(yōu)點(diǎn)是可以把所有條件組合完全表達(dá)出來。不過，缺點(diǎn)也非常明顯，即判定表的創(chuàng)建過程非常復(fù)雜，并且表達(dá)方式不容易理解。3.4.3數(shù)據(jù)流圖數(shù)據(jù)流圖（DataFlowDiagram，DFD）是一種圖形化技術(shù)，用于表示系統(tǒng)邏輯模型，它以直觀的圖形清晰地描述了系統(tǒng)數(shù)據(jù)的流向與處理的過程。數(shù)據(jù)流圖只能描述部分主要數(shù)據(jù)在系統(tǒng)中流動(dòng)與被處理的過程，

哪怕非計(jì)算機(jī)工作者也很容易理解，

所以，

數(shù)據(jù)流圖是系統(tǒng)

分析員和用戶之間非常好的交流工具。畫數(shù)據(jù)流圖時(shí)，

一般只需考慮軟件的邏輯流程，無需考慮如何實(shí)現(xiàn)功能。所以，數(shù)據(jù)流圖也是軟件設(shè)計(jì)工作的基礎(chǔ)。數(shù)據(jù)流圖是從軟件項(xiàng)目中提取四種組成元素的結(jié)果，分別是數(shù)據(jù)源點(diǎn)與終點(diǎn)、處理或加工、數(shù)據(jù)的存儲(chǔ)及數(shù)據(jù)的流向：（1）數(shù)據(jù)的源點(diǎn)與終點(diǎn)：通常指的是軟件外部的實(shí)體，是幫助理解軟件接口引入的。

可以是其它的軟件、人及物等，

而這些信息在數(shù)據(jù)流圖中無需作進(jìn)一步說明。通常來講，

只需要出現(xiàn)在數(shù)據(jù)流圖的頂層圖中。（2）處理與加工：即對數(shù)據(jù)進(jìn)行加工的單元，并對數(shù)據(jù)流實(shí)施變換，描述要執(zhí)行的功

能。對于每個(gè)加工處理過程都是要求有名字的，

一般是動(dòng)詞短語。通常的做法，

為了便于管理和識別，需要對加工步驟進(jìn)行編號。（3）數(shù)據(jù)的存儲(chǔ)：

依據(jù)“加工”與“數(shù)據(jù)存儲(chǔ)”間的箭頭方向，

可以將其分為讀數(shù)據(jù)、寫入數(shù)據(jù)以及既要讀數(shù)據(jù)又要寫數(shù)據(jù)3種情況。（4）數(shù)據(jù)流：數(shù)據(jù)在系統(tǒng)內(nèi)的運(yùn)動(dòng)方向。對于每個(gè)數(shù)據(jù)流都必須起一個(gè)合適的名字，

然而，

通常對從數(shù)據(jù)存儲(chǔ)流出或者流向數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)流不需要起名字，

只需要對數(shù)據(jù)存儲(chǔ)起個(gè)合適的名字即可。3.4.3數(shù)據(jù)流圖2.原則（1）在數(shù)據(jù)流圖中的符號必須是前面的基本符號和附加符號（2）

頂層圖即主圖，

須涵蓋基本元素中的全部符號（四種），因此，

不能缺少任意一種元素（3）數(shù)據(jù)流圖頂層圖上的數(shù)據(jù)流須封閉在外部實(shí)體之間（4）變換處理（加工）至少需要有1個(gè)輸入數(shù)據(jù)流與1個(gè)輸出數(shù)據(jù)流，才能得到加工的數(shù)據(jù)來源、加工結(jié)果（5）

任意子圖須與其上一級父圖的某個(gè)“加工”對應(yīng)，

即父圖中有多少個(gè)“加工”，就可能有幾張子圖，兩者的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流必須一致，這樣才達(dá)到平衡（6）

一般采用“自頂向下逐層分解”的方法：①不要一下子引入過多細(xì)節(jié)，應(yīng)該逐步

增加細(xì)節(jié)。

一張數(shù)據(jù)流圖包含的處理不能太多,一般不多于5-9（7+2個(gè)），

否則難以理解。

需進(jìn)一步分層。

②分層的DFD圖,一般分為頂層、中間層、底層。層次的編號按照頂層、

一層、二層……次序編排的。其中，頂層圖和一層圖只有一張。3.4.3數(shù)據(jù)流圖3.畫數(shù)據(jù)流圖的典型步驟畫數(shù)據(jù)流圖的步驟①先找到外部的實(shí)體（比如人、物或者其它系統(tǒng)），當(dāng)找到外部實(shí)體后，軟件的源點(diǎn)與終點(diǎn)便找到了。②找出與外部實(shí)體之間的輸入、輸出數(shù)據(jù)流。③在數(shù)據(jù)流圖的邊沿處畫出軟件的外部實(shí)體。④從外部實(shí)體的源點(diǎn)出發(fā)，

依據(jù)軟件的邏輯需要，

逐漸畫出變換數(shù)據(jù)的加工，直到找到外部實(shí)體需要的終點(diǎn)，構(gòu)成數(shù)據(jù)流的閉環(huán)。⑤按照上述的原則展開檢查與修改。⑥按照上述的步驟描繪出所有的子圖。3.4.3數(shù)據(jù)流圖4.注意事項(xiàng)（1）當(dāng)設(shè)計(jì)數(shù)據(jù)流圖的時(shí)候，

一般不考慮數(shù)據(jù)流的動(dòng)態(tài)關(guān)系，而只考慮其靜態(tài)關(guān)系。（2）畫數(shù)據(jù)流圖時(shí)，只考慮常規(guī)狀態(tài)，不考慮異常狀態(tài)。（3）

注意數(shù)據(jù)流圖和程序流程圖的區(qū)別。數(shù)據(jù)流圖不描述做的順序與“怎么做”，只描述“做什么”。（4）數(shù)據(jù)流圖需要經(jīng)過多次反復(fù)修改才能完成，因此，不要期望一次畫成。（5）復(fù)雜軟件的數(shù)據(jù)流圖都很大，很難用幾張紙描繪清楚，

一般采用的方法是分層進(jìn)行描述這個(gè)系統(tǒng)。在進(jìn)行分層描繪時(shí)，必須堅(jiān)持信息的連貫性，即每次只細(xì)畫一個(gè)加工。3.4.4數(shù)據(jù)流圖實(shí)例

某高?！案咝?shí)習(xí)信息服務(wù)平臺(tái)”分為四個(gè)子系統(tǒng)，其用戶分為3類：企業(yè)的管理員、學(xué)校管理員、大學(xué)生。該系統(tǒng)分為四個(gè)模塊。

注冊/登錄模塊

①

用戶：企業(yè)管理員、學(xué)校管理員、大學(xué)生

②

功能：注冊、登錄與驗(yàn)證

招聘模塊

①

用戶：實(shí)踐企業(yè)

②

功能：企業(yè)發(fā)布崗位信息、查詢學(xué)生應(yīng)聘信息、發(fā)面試通知。

應(yīng)聘管理模塊

①用戶：大學(xué)生

②功能：

使用手機(jī)、PAD等移動(dòng)設(shè)備查詢企業(yè)招聘信息，

發(fā)送應(yīng)聘簡歷、查詢面試通知。

系統(tǒng)管理模塊

①

用戶：學(xué)校管理員

②

功能：對實(shí)習(xí)企業(yè)進(jìn)行審核、對招聘信息進(jìn)行統(tǒng)計(jì)。

上述系統(tǒng)的數(shù)據(jù)流圖采用“自上而下，

由外到內(nèi)”的原則，

按照三個(gè)層次進(jìn)行梳理，

其主要的數(shù)據(jù)流圖如圖3.2、圖3.3、圖3.4所示。

（1）首先畫頂層數(shù)據(jù)流圖。將該系統(tǒng)看作一個(gè)整體，通過查看系統(tǒng)與外部的聯(lián)系，著

重分析從外部獲取的信息就是系統(tǒng)輸入信息；若是系統(tǒng)向外部輸出的數(shù)據(jù)就是系統(tǒng)輸出信息

（2）畫出系統(tǒng)內(nèi)部的一層數(shù)據(jù)流圖。數(shù)據(jù)流圖主要描述內(nèi)部處理流程，圖3.3是一層數(shù)據(jù)流圖。

（3）畫出系統(tǒng)的二層數(shù)據(jù)流圖，如圖3.4所示。3.4.4數(shù)據(jù)流圖實(shí)例

3.4.4數(shù)據(jù)流圖實(shí)例

3.4.5數(shù)據(jù)字典

針對數(shù)據(jù)流圖中的元素，

需要專門工具解釋，

即數(shù)據(jù)字典。在軟件分析與設(shè)計(jì)中用于給研發(fā)人員提供數(shù)據(jù)描述。數(shù)據(jù)流圖與數(shù)據(jù)字典的關(guān)系密切，

沒有數(shù)據(jù)字典，

人們就看不懂?dāng)?shù)據(jù)流圖，

沒有數(shù)據(jù)流圖，而數(shù)據(jù)字典也失去了存在的價(jià)值。它們一起構(gòu)成了軟件的邏輯模型內(nèi)容。數(shù)據(jù)字典是供軟件研發(fā)工程師查找數(shù)據(jù)流圖中相關(guān)數(shù)據(jù)項(xiàng)的說明。應(yīng)該將條目按照規(guī)則排列以供查閱。通常，數(shù)據(jù)字典由四類元素構(gòu)成：（1）數(shù)據(jù)流（信息流）；（2）數(shù)據(jù)流分量；（3）數(shù)據(jù)存儲(chǔ)（文件）；（4）加工（處理）

其中，數(shù)據(jù)流分量是組成數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)的最小單位項(xiàng)；

源點(diǎn)和終點(diǎn)是為了幫助理解系統(tǒng)和外界接口而列入的，不在系統(tǒng)之內(nèi)，故一般不在字典中說明。對于數(shù)據(jù)處理的定義，使用PDL或者IPO圖描述會(huì)更加方便定義數(shù)據(jù)的方法。3.4.5數(shù)據(jù)字典3.實(shí)例（1）數(shù)據(jù)流條目：對數(shù)據(jù)流圖中的數(shù)據(jù)流進(jìn)行定義，

主要包括：

數(shù)據(jù)流的名稱、簡述、數(shù)據(jù)流的來源、去向、數(shù)據(jù)的流通量、數(shù)據(jù)流的構(gòu)成。例3-1章節(jié)3.4.4中“招聘信息”條目數(shù)據(jù)流的名稱：崗位信息簡介：公司發(fā)布崗位信息來源：獲得許可的公司流向：加工處理2“招聘管理”數(shù)據(jù)量：1000份/month構(gòu)成：公司編碼+公司名稱+公司崗位+實(shí)習(xí)人數(shù)+職位條件+實(shí)習(xí)工資3.4.5數(shù)據(jù)字典3.實(shí)例（2）文件條目：即給定某個(gè)文件的定義，

通常列出由文件記錄構(gòu)成的數(shù)據(jù)流，

還可以指明文件的組織方式例3-23.4.4中企業(yè)注冊文件數(shù)據(jù)文件的名稱：公司信息表簡介：存儲(chǔ)公司基本信息構(gòu)成：公司編號＋名稱+性質(zhì)＋注冊資金＋人數(shù)＋地址＋企業(yè)代表＋主營范圍存儲(chǔ)方法：順序方式存儲(chǔ)組織方法：以“公司編號”作為關(guān)鍵碼頻率：5000次/day3.4.5數(shù)據(jù)字典3.實(shí)例（3）數(shù)據(jù)項(xiàng)條目：提供某數(shù)據(jù)項(xiàng)的解釋，一般是該數(shù)據(jù)項(xiàng)取值范圍、值類型等。

例3-3企業(yè)性質(zhì)的數(shù)據(jù)項(xiàng)

數(shù)據(jù)項(xiàng)的名稱：企業(yè)的性質(zhì)

簡介：略

類型：字符串

取值長度：30

值域:[國有企業(yè)|有限責(zé)任公司|中外合資企業(yè)|外商獨(dú)資企業(yè)|集體企業(yè)|個(gè)體企業(yè)]（4）加工條目

其是對數(shù)據(jù)流圖的補(bǔ)充，事實(shí)上是“加工處理的額外說明”。因?yàn)椤凹庸ぬ幚怼笔菙?shù)據(jù)

流圖非常重要的組成部分，

通常需要單獨(dú)說明。所以，

數(shù)據(jù)字典是對數(shù)據(jù)流圖包含的各種元

素，

包括數(shù)據(jù)項(xiàng)、特征、結(jié)構(gòu)、加工、流向等)的集合。對4類條目描述：

數(shù)據(jù)流、數(shù)據(jù)項(xiàng)、文件及基本加工進(jìn)行描述。3.4.6處理過程描繪

通過數(shù)據(jù)流圖對用戶需求進(jìn)行描述，然而一些詳盡的信息無法在DFD中表示，比如業(yè)務(wù)的詳細(xì)流程、數(shù)據(jù)項(xiàng)及相關(guān)的數(shù)據(jù)結(jié)構(gòu)。常用來描述處理過程的方法是：結(jié)構(gòu)化語言、判定樹和判定表。1.結(jié)構(gòu)化語言：它是一種半形式化語言，

介于自然語言與形式語言之間。它既具有清晰易讀的特點(diǎn)，又具有簡單易懂的優(yōu)勢。結(jié)構(gòu)化語言有以下3種形式

（1）順序結(jié)構(gòu)。一般由一組選擇語句、祈使語句及重復(fù)語句按照一定規(guī)則組成。

（2）選擇結(jié)構(gòu)。常用IF-THEN(-ELASE)-ENDIF或CASE-ENDCASE等關(guān)鍵詞構(gòu)成的語句結(jié)構(gòu)

（3）循環(huán)結(jié)構(gòu)。常用DO-WHILE-ENDDO或者REPEAT-UNTIL等詞例3-4假設(shè)某數(shù)據(jù)流圖中有“職工二次分配”的加工（處理），指的是根據(jù)企業(yè)實(shí)際情

況，

對職工的工作進(jìn)行再分配。規(guī)則如下：

按照職工的年齡、性別及學(xué)歷等情況，

安排不一

樣的工作。若年齡小于（含）25歲，初中學(xué)歷，

將實(shí)施脫產(chǎn)學(xué)習(xí)，

而高中學(xué)歷安排當(dāng)普工；

年齡大于25小于等于40歲的，

學(xué)歷是中學(xué)的男性安排當(dāng)鉗工，

若是女性安排做車工，

如果

是大學(xué)學(xué)歷做技術(shù)員；

對于年齡大于40小于等于50歲的員工，

初中學(xué)歷的安排到一線當(dāng)安檢員，大學(xué)學(xué)歷的當(dāng)技術(shù)員。采用結(jié)構(gòu)化語言編寫上述規(guī)則，描述如下3.4.6處理過程描繪2.判定樹判定樹又稱為決策樹。使用判定樹描述數(shù)據(jù)處理過程，類似于結(jié)構(gòu)化語言，不過，判定樹更直觀，主要用來描述一般組合條件，缺點(diǎn)是不易輸入計(jì)算機(jī)下面以一個(gè)實(shí)例，說明判定樹的組織方式。見圖3.5所示：例3-5畫出此項(xiàng)處理的判定樹某學(xué)校的特招筆試考核計(jì)算機(jī)、英語與數(shù)學(xué)，

其復(fù)試及錄取規(guī)則約定如下：

①總分大于

等于240時(shí)錄取。②總分大于等于180

分且小于240分時(shí)，若數(shù)學(xué)、英語成績均在60分以

上（含），需要參加面試；

如果數(shù)學(xué)或英語中有1門成績在60分以下（不含）

的，

需復(fù)試該課程后再?zèng)Q定是否錄取。③其他情況不錄取。3.4.6處理過程描繪

判定表：使用if-then-else就比較困難，即便是可以使用，但對問題的描述不夠清晰。對于此類問題，則可以采用另一種描述工具——判定表。判定表采用表格化的形式，應(yīng)用于含有復(fù)雜判斷的加工邏輯。條件越復(fù)雜規(guī)則越多，越適宜用這種表格化的方式描述。判定表由四部分組成判定表也稱為決策表，與結(jié)構(gòu)化語言和判定樹方法相比，其優(yōu)點(diǎn)是能夠清晰地表示復(fù)雜

的條件組合與應(yīng)做的動(dòng)作之間的對應(yīng)關(guān)系。缺點(diǎn)是判定表的建立過程較為繁雜，且表達(dá)方式不如前兩者簡便。判定表主要由4個(gè)部分構(gòu)成：

①在左上方列出全部條件

②在左下方是全部可能做的動(dòng)作

③右上方是把各種條件組合起來的矩陣

④右下方是與每種條件進(jìn)行組合后對應(yīng)的動(dòng)作

判定表的右半部分的每一列，事實(shí)上是一條規(guī)則，明確了與特定的條件組合相對應(yīng)的動(dòng)作以下以行李空運(yùn)為例說明判定表的使用方法：例3-6某航空公司運(yùn)價(jià)表顯示：當(dāng)行李重量不大于20kg時(shí)，免費(fèi)托運(yùn)；當(dāng)行李重量大于20kg時(shí)，對乘坐頭等艙的乘客超重部分收費(fèi)4元/千克，對乘坐經(jīng)濟(jì)艙的國內(nèi)乘客超重部分收費(fèi)6元/千克，對乘坐飛機(jī)的外國乘客，每千克收費(fèi)比國內(nèi)乘客高一倍，對殘疾乘客而言，超重部分收費(fèi)比普通乘客每千克少一半。用判定表對航空公司運(yùn)費(fèi)核算過程進(jìn)行分析見表3-4所示：

123456789乘客（國內(nèi)）

TTTTFFFF頭等艙乘客

TFTFTFTF乘客（殘疾）

FFTTFFTT行李≤20kgTFFFFFFFF免費(fèi)×

(W-20)×2

×

(W-20)×3

×

(W-20)×4

×

×

(W-20)×6

×

×(W-20)×8

×

(W-20)×12

×

3.4.7狀態(tài)轉(zhuǎn)換圖

在需求分析時(shí)，除了建立軟件的數(shù)據(jù)模型與功能模型，還需要建立軟件的行為模型，比如，在不同狀態(tài)下，數(shù)據(jù)對象會(huì)出現(xiàn)各種不同的操作，因此，應(yīng)分析數(shù)據(jù)對象的狀態(tài)，畫出狀態(tài)轉(zhuǎn)換圖，便于正確識別數(shù)據(jù)的狀態(tài)。該圖形工具通過描繪軟件系統(tǒng)的狀態(tài)以及導(dǎo)致系統(tǒng)狀態(tài)轉(zhuǎn)變的事件，以表示系統(tǒng)當(dāng)前的行為。圖中的狀態(tài)主要有：初始態(tài)、終止態(tài)和中間態(tài)。在一個(gè)圖中，只有一個(gè)初態(tài)，而終止?fàn)顟B(tài)有0至多個(gè)。①初始態(tài)：系統(tǒng)啟動(dòng)時(shí)進(jìn)入的狀態(tài)；②終止態(tài)：運(yùn)行結(jié)束到達(dá)的狀態(tài)；③狀態(tài)遷移：

從一個(gè)狀態(tài)到另一狀態(tài)轉(zhuǎn)變。一般用箭頭來表示從某一種狀態(tài)向另一狀態(tài)轉(zhuǎn)變；④事件：某時(shí)刻出現(xiàn)的事情，即從某個(gè)狀態(tài)轉(zhuǎn)變到另一狀態(tài)的外部事件的抽象。

例3-7

在生活中，經(jīng)常使用打印機(jī)，其工作過程大致如下：

一開始處于Ready狀態(tài)。復(fù)印機(jī)工作流程解析：當(dāng)接到復(fù)印命令則進(jìn)入復(fù)印狀態(tài)，

完成一個(gè)復(fù)印命令規(guī)定的工作后，

又回到Ready狀態(tài)，

等

待下一個(gè)命令；如果執(zhí)行復(fù)印命令時(shí)發(fā)現(xiàn)缺紙，則進(jìn)入缺紙狀態(tài)，并發(fā)出警告，等待裝紙，

裝滿紙后繼續(xù)復(fù)議未完成的工作；

若復(fù)印時(shí)卡紙，

立即停止復(fù)印，

并發(fā)出警告，

當(dāng)排除故障后，返回到Ready狀態(tài)。用狀態(tài)轉(zhuǎn)換圖描述打印機(jī)的活動(dòng)。見圖3.6所示：其它工具

文字描述不直觀，容易產(chǎn)生二義性。因此，在需求分析文檔中常用圖形工具代替部分文

字?jǐn)⑹?。前面章?jié)已介紹了數(shù)據(jù)流圖、狀態(tài)圖，本節(jié)將簡單介紹經(jīng)常用到的其它三種工具，分別是層次方框圖、維納圖和IPO圖。3.5.1層次方框圖

在需求分析階段，常用層次方框圖描述數(shù)據(jù)的層次結(jié)構(gòu)，用多層矩形框描繪數(shù)據(jù)信息的層次結(jié)構(gòu)。該圖的最上層是一個(gè)單獨(dú)的矩形框，用來表示數(shù)據(jù)結(jié)構(gòu)的最上層；下面每一層矩形框表示數(shù)據(jù)子集；最下層的矩形框表示不可再分割的數(shù)據(jù)元素。由于軟件架構(gòu)的細(xì)化，采用層次方框圖描述數(shù)據(jù)結(jié)構(gòu)時(shí)需要更詳細(xì)的信息。該工具比較適合需求分析階段的需要。系統(tǒng)分析員從最上層開始，順著每條路徑逐步細(xì)化，直到數(shù)據(jù)結(jié)構(gòu)的全部細(xì)節(jié)確定為止。正如下面的例子，某公司主營以下產(chǎn)品和服務(wù)，現(xiàn)嘗試構(gòu)建一個(gè)基本的層次方框圖，如圖3.7所示：3.5.2維納圖（Warnier）Warnier圖是由J.D.Warnier提出，用來表示數(shù)據(jù)層次的一種圖形工具。該工具比層次圖提供更豐富的描繪手段。在Warnier圖中使用以下幾種符號：

①大括號{}:用來區(qū)分信息的層次；

②異或符號⊕：

指出一個(gè)信息類或一個(gè)數(shù)據(jù)元素在一定條件下出現(xiàn)，符號上、下方的名。③圓括號（）：指出這類數(shù)據(jù)重復(fù)出現(xiàn)的次數(shù)。例

3-8

設(shè)某高校有

10

個(gè)學(xué)院，學(xué)院下設(shè)

15

個(gè)系，30

個(gè)科室，6

個(gè)實(shí)驗(yàn)中心，每個(gè)系

分若干個(gè)專業(yè)，各個(gè)系的專業(yè)個(gè)數(shù)并不相同；校一級機(jī)關(guān)具有

2

個(gè)室、4

個(gè)部、5

個(gè)處，每個(gè)處分別設(shè)有若干個(gè)科室和中心，如圖

3.8

所示。3.5.3IPO圖

在需求分析階段，我們需要對數(shù)據(jù)的輸入、處理、輸出過程建模，常用的建模工具是IPO圖。IPO圖由IBM公司發(fā)起并逐步完善的一種圖形工具，用來描述數(shù)據(jù)的輸入、處理、

輸出過程，其基本形式是3個(gè)矩形框，在最左邊的矩形中列出需要向軟件系統(tǒng)輸入的數(shù)據(jù)，

在中間的矩形框中填入需要對前面的信息做哪些處理，在最右面的矩形中列出產(chǎn)生的結(jié)果。在圖中需要用粗大箭頭指出數(shù)據(jù)流動(dòng)的方向。

在需求分析階段，

軟件研發(fā)團(tuán)隊(duì)總體上理解了用戶的具體需求，

核實(shí)并匯總軟件的功能記錄軟件所需要的數(shù)據(jù)來源，

描述處理相關(guān)數(shù)據(jù)的方式。最終，

把這些材料進(jìn)行整理，

形成《軟件需求規(guī)格說明書》。例3-9

圖3.9所示為某省公務(wù)員考試成績管理系統(tǒng)的IPO圖，通過這個(gè)簡單的例子可以了解IPO圖的用法：作業(yè)安排第4章

概要設(shè)計(jì)概要設(shè)計(jì)01概要設(shè)計(jì)新課導(dǎo)入

前一階段的工作中，

已經(jīng)清楚必須“做什么”了，接下來進(jìn)入軟件的概要設(shè)計(jì)階段，即將“做什么”轉(zhuǎn)變成“怎樣做”。同時(shí)，可以把軟件設(shè)計(jì)階段的成果寫到《軟件設(shè)計(jì)規(guī)格說

明書》。概要設(shè)計(jì)是軟件設(shè)計(jì)階段的第一步驟，所以，僅描繪軟件的整體結(jié)構(gòu)，而在詳細(xì)設(shè)計(jì)階段，才是對軟件結(jié)構(gòu)進(jìn)一步的細(xì)化。4.1概要設(shè)計(jì)階段的目標(biāo)與任務(wù)

概要設(shè)計(jì)階段的目標(biāo)是整體上軟件如何實(shí)現(xiàn)？即明確軟件是由哪些模塊構(gòu)成，理清每個(gè)模塊的功能、模塊之間的調(diào)用關(guān)系以及通信接口等軟件設(shè)計(jì)之?dāng)?shù)據(jù)流圖基礎(chǔ)在進(jìn)行軟件的結(jié)構(gòu)設(shè)計(jì)時(shí)，主要以數(shù)據(jù)流圖作為主要依據(jù)進(jìn)行設(shè)計(jì)。因此，數(shù)據(jù)流圖是

軟件設(shè)計(jì)人員進(jìn)行方案設(shè)計(jì)的基礎(chǔ)。

第一，軟件分析人員可以在可選擇的方案中選擇多個(gè)可

實(shí)現(xiàn)的方案；

第二，

通過比較分析這些方案；

第三，

從這些方案中推薦最佳方案給用戶負(fù)責(zé)人。

用戶中的技術(shù)專家需要認(rèn)真審查推薦的最佳方案，

若該方案確實(shí)完全符合需要，

而且在目前的條件下完全可以實(shí)現(xiàn)，那么，下一步提交使用部門（業(yè)務(wù)部門）負(fù)責(zé)人審查。若使用

部門（業(yè)務(wù)部門）

負(fù)責(zé)人同意該方案，接下來進(jìn)入軟件的結(jié)構(gòu)設(shè)計(jì)階段。需要將較復(fù)雜的軟

件實(shí)施功能分解，即將部分復(fù)雜的功能適當(dāng)分解成較簡單的功能，

進(jìn)而對軟件的結(jié)構(gòu)進(jìn)行設(shè)計(jì)。4.1概要設(shè)計(jì)階段的目標(biāo)與任務(wù)

為了明確軟件的結(jié)構(gòu)，第一步，從實(shí)現(xiàn)的角度將軟件較復(fù)雜的功能實(shí)施進(jìn)一步分解。軟

件分析人員將結(jié)合算法的描述分析數(shù)據(jù)流圖中的每一個(gè)處理過程，若一個(gè)處理過程過于復(fù)雜，須將其進(jìn)行適當(dāng)分解，直到分解為若干較簡單的功能為止。一般情況，

軟件的一個(gè)模塊

需要實(shí)現(xiàn)一個(gè)子功能。所以，將軟件的模塊應(yīng)該具有較清晰的層次結(jié)構(gòu)，

且頂層的模塊通過

調(diào)用其下一層的模塊，

從而實(shí)現(xiàn)軟件的完整功能，并且下層模塊將繼續(xù)調(diào)用下一層模塊，

實(shí)現(xiàn)軟件的一個(gè)子功能，所以，在最下面的模塊將實(shí)現(xiàn)具體功能。

一般而言，軟件都需要與數(shù)據(jù)庫交互，

因此，

對于該類軟件，軟件研發(fā)人員在需求分析

階段就需要明確軟件的數(shù)據(jù)需求，繼而進(jìn)一步設(shè)計(jì)數(shù)據(jù)庫。最終通過制定軟件的測試計(jì)劃書寫《軟件概要設(shè)計(jì)規(guī)格說明書》并組織相關(guān)人員進(jìn)行復(fù)審。4.2.1軟件結(jié)構(gòu)設(shè)計(jì)的準(zhǔn)則

經(jīng)過長期積累，在軟件開發(fā)過程中人們總結(jié)了大量的經(jīng)驗(yàn)，即得到了下面關(guān)于軟件設(shè)計(jì)方面的準(zhǔn)則：

關(guān)于軟件結(jié)構(gòu)設(shè)計(jì)的準(zhǔn)則如下：

（1）軟件的體系結(jié)構(gòu)是對復(fù)雜軟件的抽象。較好的軟件結(jié)構(gòu)可有效地處理多種個(gè)體需求。

（2）在一定時(shí)間內(nèi)，軟件的體系結(jié)構(gòu)需要保持穩(wěn)定。從而有效地確保軟件接口的一致性。

（3）軟件體系結(jié)構(gòu)的好壞決定了未來軟件是否高效、穩(wěn)定、可靠。4.2.2模塊設(shè)計(jì)的準(zhǔn)則

當(dāng)軟件結(jié)構(gòu)初步設(shè)計(jì)方案完成后，

為了實(shí)現(xiàn)模塊的獨(dú)立性，

須對軟件結(jié)構(gòu)進(jìn)行審查與分

析，

經(jīng)過一系列分解、合并模塊操作，

以降低耦合度，

從而起到提高模塊內(nèi)聚性的要求。比

如，

若干模塊共享某個(gè)子功能，

此時(shí)，

建議分解出來一個(gè)公共子模塊，

來定義一個(gè)內(nèi)聚度更

高的模塊，

便于其它模塊調(diào)用；

有時(shí)候，

可以將耦合度較高的模塊施行合并，

從而降低模塊接口的復(fù)雜度，正如圖4.1所示。1.提高軟件模塊的內(nèi)聚性，同時(shí)降低軟件模塊間的耦合性4.2.2模塊設(shè)計(jì)的準(zhǔn)則

2.軟件應(yīng)該保持合理的深度、寬度以及扇入與扇出

軟件深度是指軟件結(jié)構(gòu)中模塊層次的數(shù)量，

其在一定意義上講，

可以反映軟件的規(guī)模與復(fù)雜度。若軟件的深度過大，則表明軟件的層數(shù)太多，須審查某些模塊是否可以合并軟件的寬度是指在同一層次中存在的最大的模塊數(shù)。通常來說，

寬度越大的系統(tǒng)，

軟件的結(jié)構(gòu)也越復(fù)雜。模塊的扇出是影響軟件寬度的最大因素。軟件扇出是指某個(gè)模塊可以直接調(diào)用的模塊數(shù)量。一般而言，

一個(gè)較好的軟件結(jié)構(gòu)，

其

平均扇出數(shù)不會(huì)大于9。因?yàn)樯瘸鎏蟊砻髂K過多，此時(shí)可適當(dāng)提高中間層次的模塊數(shù)；

若扇出過小也不行。如果扇出太小，

可將下級模塊進(jìn)行分解成若干子模塊，

或者將其合并到上級模塊。軟件扇入是指某個(gè)模塊被若干上級模塊調(diào)用的數(shù)目。若某個(gè)模塊的扇入過大，表明共享

該模塊的上層模塊數(shù)量越多，

這種情況是比較認(rèn)可的。不過，

一般不要違背軟件模塊的獨(dú)立性原理，過分追求高扇入。通常來講，

一個(gè)較好的軟件結(jié)構(gòu)，

一般是第一層扇出要高，

中間的層次扇出少，

下面