第3章信息系統(tǒng)建設概論_第1頁
第3章信息系統(tǒng)建設概論_第2頁
第3章信息系統(tǒng)建設概論_第3頁
第3章信息系統(tǒng)建設概論_第4頁
第3章信息系統(tǒng)建設概論_第5頁
已閱讀5頁,還剩86頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、第第3章章 信息系統(tǒng)建設概論信息系統(tǒng)建設概論 第3章信息系統(tǒng)建設概論 本章主要內(nèi)容本章主要內(nèi)容 l3.1 信息系統(tǒng)建設是復雜的社會過程信息系統(tǒng)建設是復雜的社會過程 l3.2 信息系統(tǒng)建設的一般方法信息系統(tǒng)建設的一般方法 l3.3 信息系統(tǒng)的生命周期信息系統(tǒng)的生命周期 l3.4 基于生命周期的開發(fā)方法(信息系統(tǒng)開發(fā)過程)基于生命周期的開發(fā)方法(信息系統(tǒng)開發(fā)過程) l3.5 基于開發(fā)技術的開發(fā)方法(信息系統(tǒng)開發(fā)技術)基于開發(fā)技術的開發(fā)方法(信息系統(tǒng)開發(fā)技術) l3.6 信息系統(tǒng)開發(fā)的組織管理信息系統(tǒng)開發(fā)的組織管理 l3.7 信息系統(tǒng)開發(fā)工具(信息系統(tǒng)開發(fā)工具(CASE工具)工具) 3.1 信息系統(tǒng)

2、建設是復雜的社會過程信息系統(tǒng)建設是復雜的社會過程 1. 信息系統(tǒng)的復雜性體現(xiàn)在:信息系統(tǒng)的復雜性體現(xiàn)在: 技術手段復雜技術手段復雜 內(nèi)容復雜,目標多樣內(nèi)容復雜,目標多樣 投資密度大,效益難以計算投資密度大,效益難以計算 環(huán)境復雜多變環(huán)境復雜多變 技術的復雜性技術的復雜性 l計算機硬、軟件技術計算機硬、軟件技術 l數(shù)據(jù)通訊與網(wǎng)絡技術數(shù)據(jù)通訊與網(wǎng)絡技術 l各種信息采集與存貯各種信息采集與存貯 l各種控制與決策方法各種控制與決策方法 l建模與仿真技術建模與仿真技術 l人工智能技術人工智能技術 l技術方案難以檢驗證明技術方案難以檢驗證明( (樣品?實物模型?樣品?實物模型?) ) 內(nèi)容的復雜性內(nèi)容的復

3、雜性 l一個組織的管理與業(yè)務信息量大、面廣,形式多樣、一個組織的管理與業(yè)務信息量大、面廣,形式多樣、 來源繁雜,信息內(nèi)容和處理要求又涉及到廣泛的學來源繁雜,信息內(nèi)容和處理要求又涉及到廣泛的學 科和事業(yè)領域??坪褪聵I(yè)領域。 l一個組織的信息系統(tǒng)必是一個規(guī)模龐大,結構復雜,一個組織的信息系統(tǒng)必是一個規(guī)模龐大,結構復雜, 具備多種功能、實現(xiàn)多個目標的大系統(tǒng)具備多種功能、實現(xiàn)多個目標的大系統(tǒng) l一個組織內(nèi)各類機構和人員的信息需求不盡相同,一個組織內(nèi)各類機構和人員的信息需求不盡相同, 有些需求可能相互沖突,需求的不確定性和可變性有些需求可能相互沖突,需求的不確定性和可變性 非常大。非常大。 l組織和外部

4、環(huán)境之間的數(shù)據(jù)交換難以控制。組織和外部環(huán)境之間的數(shù)據(jù)交換難以控制。 投資的密集性投資的密集性 l信息系統(tǒng)的建設,需要巨額投資,是一種資金密集型信息系統(tǒng)的建設,需要巨額投資,是一種資金密集型 的建設項目的建設項目 l智力密集型或者知識密集型智力密集型或者知識密集型 l需用大量人工,是勞動密集型項目需用大量人工,是勞動密集型項目 l效益難以計算效益難以計算 信息系統(tǒng)建設的統(tǒng)計數(shù)據(jù)信息系統(tǒng)建設的統(tǒng)計數(shù)據(jù) l據(jù)國外據(jù)國外19951995年對年對365365家公司的調(diào)查:家公司的調(diào)查: 3131的信息系統(tǒng)項目在完成之前被取消的信息系統(tǒng)項目在完成之前被取消 5353的項目沒有達到預定功能的項目沒有達到預定

5、功能 在在36823682個項目中只有個項目中只有1212的項目按時和按預算完成的項目按時和按預算完成 l據(jù)某顧問公司據(jù)某顧問公司20042004年報告年報告( (對對4 4萬個信息系統(tǒng)項目的萬個信息系統(tǒng)項目的 調(diào)查調(diào)查) ) ERPERP失敗率達到失敗率達到70%70% 成功項目只能達到成功項目只能達到34%34% 有爭議的項目達到有爭議的項目達到51%51% 失敗項目達到失敗項目達到15%15% 成功的含義:在規(guī)定的時間內(nèi),以規(guī)定的預算完成規(guī)定的目標。成功的含義:在規(guī)定的時間內(nèi),以規(guī)定的預算完成規(guī)定的目標。 環(huán)境的復雜性環(huán)境的復雜性 l涉及到組織內(nèi)部各級機構、管理人員涉及到組織內(nèi)部各級機構

6、、管理人員 l涉及組織面臨的外部環(huán)境及發(fā)展趨勢涉及組織面臨的外部環(huán)境及發(fā)展趨勢 l要考慮管理體制、管理思想、管理方法和管理手段要考慮管理體制、管理思想、管理方法和管理手段 的相互匹配、相互促進的相互匹配、相互促進 l考慮人的習慣、心理狀態(tài)及現(xiàn)行的制度、慣例和社考慮人的習慣、心理狀態(tài)及現(xiàn)行的制度、慣例和社 會、政治諸因素會、政治諸因素 信息系統(tǒng)開發(fā)是一個社會過程信息系統(tǒng)開發(fā)是一個社會過程 l問題描述和方案驗證不同于一般技術工程問題描述和方案驗證不同于一般技術工程 技術工程問題明確,可以模擬,或制作實物模型、樣品進技術工程問題明確,可以模擬,或制作實物模型、樣品進 行驗證,信息系統(tǒng)的問題確定性差,

7、難以提前驗證解決方行驗證,信息系統(tǒng)的問題確定性差,難以提前驗證解決方 案。案。 l人的影響人的影響 信息系統(tǒng)是人機系統(tǒng),有來自于人的障礙。如了解、溝通、信息系統(tǒng)是人機系統(tǒng),有來自于人的障礙。如了解、溝通、 實施困難。實施困難。 l社會環(huán)境的影響社會環(huán)境的影響 如政策、競爭、文化觀念等對信息系統(tǒng)影響力很大,不同如政策、競爭、文化觀念等對信息系統(tǒng)影響力很大,不同 于純技術工程。于純技術工程。 3.2 信息系統(tǒng)建設的一般方法信息系統(tǒng)建設的一般方法 l3.2.1 早期方法的不足早期方法的不足 l早期,早期,人們對信息系統(tǒng)的復雜性缺乏足夠的認識,人們對信息系統(tǒng)的復雜性缺乏足夠的認識, 認為信息系統(tǒng)無非是

8、認為信息系統(tǒng)無非是“大程序大程序”,缺乏,缺乏科學的科學的開發(fā)方開發(fā)方 法法: 目標含糊目標含糊 通信誤解通信誤解 步驟混亂步驟混亂 缺乏管理控制缺乏管理控制 3.2.2 系統(tǒng)方法的應用系統(tǒng)方法的應用 l系統(tǒng)科學方法為人們提供了新的思維模式,是研究系統(tǒng)科學方法為人們提供了新的思維模式,是研究 復雜系統(tǒng)的有效工具。復雜系統(tǒng)的有效工具。 l錢學森曾指出錢學森曾指出“系統(tǒng)工程是組織管理系統(tǒng)的規(guī)劃、系統(tǒng)工程是組織管理系統(tǒng)的規(guī)劃、 研究、制造、試驗和使用的科學方法,使一種對所研究、制造、試驗和使用的科學方法,使一種對所 有系統(tǒng)都具有普遍意義的方法有系統(tǒng)都具有普遍意義的方法”。 l系統(tǒng)方法在信息系統(tǒng)建設中

9、的應用:系統(tǒng)方法在信息系統(tǒng)建設中的應用: 還原論與整體論相結合還原論與整體論相結合 微觀分析與宏觀綜合相結合微觀分析與宏觀綜合相結合 定性判斷與定量計算相結合定性判斷與定量計算相結合 嚴格生命周期階段與反復迭代相結合嚴格生命周期階段與反復迭代相結合 3.2.3 系統(tǒng)建模系統(tǒng)建模/模型化模型化 分析研究復雜系統(tǒng)問題,建模是一種基本手分析研究復雜系統(tǒng)問題,建模是一種基本手 段。段。 建模(建模(modeling)就是為描述系統(tǒng)的構成和)就是為描述系統(tǒng)的構成和 行為,對現(xiàn)實系統(tǒng)的各種因素進行適當篩選,行為,對現(xiàn)實系統(tǒng)的各種因素進行適當篩選, 用一定方式(數(shù)學公式、符號、圖形、圖像用一定方式(數(shù)學公式

10、、符號、圖形、圖像 等)表示現(xiàn)實系統(tǒng)的過程。等)表示現(xiàn)實系統(tǒng)的過程。 建模也稱模型化。建模也稱模型化。 1. 系統(tǒng)模型的概念系統(tǒng)模型的概念 l系統(tǒng)模型是指以某種確定的形式(如文字、符號、系統(tǒng)模型是指以某種確定的形式(如文字、符號、 圖表、實物、數(shù)學公式等),對系統(tǒng)某一方面本質(zhì)圖表、實物、數(shù)學公式等),對系統(tǒng)某一方面本質(zhì) 屬性的描述。屬性的描述。 l一個適用的系統(tǒng)模型應該具有如下一個適用的系統(tǒng)模型應該具有如下3個特征:個特征: 它是現(xiàn)實系統(tǒng)的抽象或模仿;它是現(xiàn)實系統(tǒng)的抽象或模仿; 它是由反映系統(tǒng)本質(zhì)或特征的主要因素(要素)構成的;它是由反映系統(tǒng)本質(zhì)或特征的主要因素(要素)構成的; 它集中體現(xiàn)了這

11、些主要因素之間的關系。它集中體現(xiàn)了這些主要因素之間的關系。 l根據(jù)抽象程度:概念模型、邏輯模型和物理模型。根據(jù)抽象程度:概念模型、邏輯模型和物理模型。 l根據(jù)對時間的依賴:靜態(tài)模型和動態(tài)模型。根據(jù)對時間的依賴:靜態(tài)模型和動態(tài)模型。 l全面徹底地描述一個系統(tǒng),通常需要使用多個模型。全面徹底地描述一個系統(tǒng),通常需要使用多個模型。 2. 管理系統(tǒng)模型管理系統(tǒng)模型 l管理模型描述組織的狀況,包括:管理模型描述組織的狀況,包括: 組織的靜態(tài)特征,如組織結構圖、實體關系圖組織的靜態(tài)特征,如組織結構圖、實體關系圖 動態(tài)特征,如任務分解圖、狀態(tài)轉(zhuǎn)換圖、甘特圖、動態(tài)特征,如任務分解圖、狀態(tài)轉(zhuǎn)換圖、甘特圖、PER

12、TPERT圖圖 業(yè)務流程,如流程圖業(yè)務流程,如流程圖 業(yè)務規(guī)則,如決策樹、決策表業(yè)務規(guī)則,如決策樹、決策表 管理系統(tǒng)管理系統(tǒng) 靜態(tài)特征靜態(tài)特征( (組織機構、對象、角色組織機構、對象、角色) ) 動態(tài)特征(行為動態(tài)特征(行為/ /事件事件/ /行動行動/ /狀態(tài)狀態(tài)) 業(yè)務流程業(yè)務流程 業(yè)務規(guī)則業(yè)務規(guī)則 . . 模型模型 3. 信息系統(tǒng)模型信息系統(tǒng)模型 l信息系統(tǒng)模型描述計算機信息系統(tǒng)的狀況。信息系統(tǒng)模型描述計算機信息系統(tǒng)的狀況。 l每種模型都有其標準符號、慣例、語法規(guī)則和用途,當這一組每種模型都有其標準符號、慣例、語法規(guī)則和用途,當這一組 符號和規(guī)則形成了一套完整嚴謹?shù)谋硎菊Z言,就形成建模語

13、言。符號和規(guī)則形成了一套完整嚴謹?shù)谋硎菊Z言,就形成建模語言。 l因為信息系統(tǒng)是為管理服務的,因此有些模型在管理系統(tǒng)和信因為信息系統(tǒng)是為管理服務的,因此有些模型在管理系統(tǒng)和信 息系統(tǒng)中通用,如流程圖、狀態(tài)圖息系統(tǒng)中通用,如流程圖、狀態(tài)圖 、決策樹、決策樹/決策表等。決策表等。 模型名稱模型名稱用途用途 業(yè)務流程圖業(yè)務流程圖描述不同職能部門業(yè)務活動分工和活動過程的模型描述不同職能部門業(yè)務活動分工和活動過程的模型 數(shù)據(jù)流圖數(shù)據(jù)流圖描述數(shù)據(jù)的產(chǎn)生、處理、存儲和去向的信息處理模型描述數(shù)據(jù)的產(chǎn)生、處理、存儲和去向的信息處理模型 程序流程圖程序流程圖描述程序完成順序、分支、循環(huán)等處理過程的模型描述程序完成順

14、序、分支、循環(huán)等處理過程的模型 實體關系圖實體關系圖描述系統(tǒng)中有價值的實體及其關系的數(shù)據(jù)模型描述系統(tǒng)中有價值的實體及其關系的數(shù)據(jù)模型 模塊結構圖模塊結構圖描述軟件功能模塊及其調(diào)用關系的層次模型描述軟件功能模塊及其調(diào)用關系的層次模型 判定表、判定樹判定表、判定樹描述決策條件及其行動關系的模型描述決策條件及其行動關系的模型 UMLUML ( (類圖、用例圖、順序圖類圖、用例圖、順序圖等等) ) 描述軟件系統(tǒng)結構及行為的一組模型描述軟件系統(tǒng)結構及行為的一組模型 信息系統(tǒng)模型的作用信息系統(tǒng)模型的作用 l建立信息系統(tǒng)模型有以下主要作用:建立信息系統(tǒng)模型有以下主要作用: 對復雜問題進行簡化描述,幫助有關人

15、員快速、簡單直觀、對復雜問題進行簡化描述,幫助有關人員快速、簡單直觀、 準確地了解系統(tǒng);準確地了解系統(tǒng); 建模的過程使得分析師和設計師能更全面地研究系統(tǒng),深建模的過程使得分析師和設計師能更全面地研究系統(tǒng),深 思熟慮,減少遺漏,以形成更成熟的方案;思熟慮,減少遺漏,以形成更成熟的方案; 各階段產(chǎn)生的模型為后續(xù)階段的有關人員提供了工作依據(jù);各階段產(chǎn)生的模型為后續(xù)階段的有關人員提供了工作依據(jù); 為項目各類人員提供了統(tǒng)一的交流工具,利于溝通和團隊為項目各類人員提供了統(tǒng)一的交流工具,利于溝通和團隊 合作;合作; 為項目驗收和將來的維護工作提供了文檔依據(jù);為項目驗收和將來的維護工作提供了文檔依據(jù); 利用工

16、具將模型映射為特定平臺的可執(zhí)行代碼(利用工具將模型映射為特定平臺的可執(zhí)行代碼(MDDMDD, Model-Driven DevelopmentModel-Driven Development),減少開發(fā)人員工作量。),減少開發(fā)人員工作量。 4. 統(tǒng)一建模語言統(tǒng)一建模語言UML l統(tǒng)一建模語言統(tǒng)一建模語言UML(unified modeling language )是由單一元模型支持的一組圖示法。這些圖示法)是由單一元模型支持的一組圖示法。這些圖示法 有助于表達與設計軟件系統(tǒng),特別是采用面向?qū)ο笥兄诒磉_與設計軟件系統(tǒng),特別是采用面向?qū)ο?方法構造的軟件系統(tǒng)。方法構造的軟件系統(tǒng)。 lUML通過不

17、同的圖來描述系統(tǒng)的結構(通過不同的圖來描述系統(tǒng)的結構(structure) 、行為(、行為(behavior)、交互過程()、交互過程(interaction)。)。 lUML 2.2中一共定義了中一共定義了14種圖(種圖(diagram):): 系統(tǒng)結構:類圖、對象圖、包圖、構件圖、部署圖等系統(tǒng)結構:類圖、對象圖、包圖、構件圖、部署圖等 系統(tǒng)行為:活動圖、狀態(tài)圖、用例圖系統(tǒng)行為:活動圖、狀態(tài)圖、用例圖 交互過程:通信圖、順序圖、計時圖等交互過程:通信圖、順序圖、計時圖等 3.3 信息系統(tǒng)的生命周期信息系統(tǒng)的生命周期 l信息系統(tǒng)開發(fā)圍繞信息系統(tǒng)生命周期來進行,有時信息系統(tǒng)開發(fā)圍繞信息系統(tǒng)生命周

18、期來進行,有時 也稱系統(tǒng)開發(fā)生命周期(也稱系統(tǒng)開發(fā)生命周期(SDLCSDLC,System System Development Life CycleDevelopment Life Cycle),體現(xiàn)系統(tǒng)工程的思想。),體現(xiàn)系統(tǒng)工程的思想。 l包含包含5 5個階段:個階段: 規(guī)劃、分析、設計、實施、運維規(guī)劃、分析、設計、實施、運維 生命周期的階段生命周期的階段 可行性可行性 研究研究 開發(fā)開發(fā) 請求請求 詳細詳細 調(diào)查調(diào)查 系統(tǒng)系統(tǒng) 轉(zhuǎn)換轉(zhuǎn)換 總體總體 設計設計 邏輯邏輯 設計設計 審批審批 初步初步 調(diào)查調(diào)查 驗收驗收 系統(tǒng)系統(tǒng) 維護維護 系統(tǒng)系統(tǒng) 評價評價 詳細詳細 設計設計 審查審查

19、編程編程 調(diào)試調(diào)試 審查審查 運行維護運行維護 系統(tǒng)規(guī)劃系統(tǒng)規(guī)劃 系統(tǒng)實施系統(tǒng)實施系統(tǒng)分析系統(tǒng)分析 系統(tǒng)設計系統(tǒng)設計 1. 階段任務階段任務 2. 設計文檔設計文檔 各階段任務各階段任務 l系統(tǒng)規(guī)劃系統(tǒng)規(guī)劃 確定信息系統(tǒng)的發(fā)展規(guī)劃;企業(yè)業(yè)務流程的識別、改革與確定信息系統(tǒng)的發(fā)展規(guī)劃;企業(yè)業(yè)務流程的識別、改革與 創(chuàng)新;對建設新系統(tǒng)的需求作出初步研究,確定信息系統(tǒng)創(chuàng)新;對建設新系統(tǒng)的需求作出初步研究,確定信息系統(tǒng) 的總體結構;確定系統(tǒng)的備選方案,對這些方案進行可行的總體結構;確定系統(tǒng)的備選方案,對這些方案進行可行 性分析性分析 l系統(tǒng)分析系統(tǒng)分析 詳細調(diào)查,確定系統(tǒng)的基本目標和邏輯功能要求詳細調(diào)查,

20、確定系統(tǒng)的基本目標和邏輯功能要求 l系統(tǒng)設計系統(tǒng)設計 根據(jù)系統(tǒng)說明書中規(guī)定的功能要求,考慮實際條件,具體根據(jù)系統(tǒng)說明書中規(guī)定的功能要求,考慮實際條件,具體 設計實現(xiàn)邏輯模型的技術方案設計實現(xiàn)邏輯模型的技術方案 l系統(tǒng)實施系統(tǒng)實施 計算機等設備的購置、安裝和調(diào)試;編寫、調(diào)試和測試程計算機等設備的購置、安裝和調(diào)試;編寫、調(diào)試和測試程 序;人員培訓;數(shù)據(jù)準備或轉(zhuǎn)換;系統(tǒng)調(diào)試與轉(zhuǎn)換序;人員培訓;數(shù)據(jù)準備或轉(zhuǎn)換;系統(tǒng)調(diào)試與轉(zhuǎn)換 l系統(tǒng)維護系統(tǒng)維護 運行情況的記錄;必要的修改;評價和總結等運行情況的記錄;必要的修改;評價和總結等 信息系統(tǒng)開發(fā)方法信息系統(tǒng)開發(fā)方法 生命周期是指導性方針,很抽象,具體的信息生

21、命周期是指導性方針,很抽象,具體的信息 系統(tǒng)開發(fā)方法有很多,主要研究方向有兩類:系統(tǒng)開發(fā)方法有很多,主要研究方向有兩類: l針對開發(fā)過程針對開發(fā)過程 不同的信息系統(tǒng)開發(fā)過程模型。關注整個開發(fā)采取哪些步不同的信息系統(tǒng)開發(fā)過程模型。關注整個開發(fā)采取哪些步 驟,每個步驟包含哪些任務,由什么人完成,任務的成果驟,每個步驟包含哪些任務,由什么人完成,任務的成果 如何體現(xiàn)等如何體現(xiàn)等 也稱為不同的生存周期模型也稱為不同的生存周期模型 l針對開發(fā)技術針對開發(fā)技術 不同的建模方法,從不同的觀點來反映系統(tǒng)的全貌,并采不同的建模方法,從不同的觀點來反映系統(tǒng)的全貌,并采 用不同技術手段予以實現(xiàn)用不同技術手段予以實現(xiàn)

22、 3.4信息系統(tǒng)開發(fā)過程模型信息系統(tǒng)開發(fā)過程模型 (基于生命周期的開發(fā)方法)(基于生命周期的開發(fā)方法) l開發(fā)過程的研究和經(jīng)驗的總結:開發(fā)過程的研究和經(jīng)驗的總結: 瀑布模型(開發(fā)方法)瀑布模型(開發(fā)方法) 原型模型(開發(fā)方法)原型模型(開發(fā)方法) 增量模型(迭代開發(fā)方法)增量模型(迭代開發(fā)方法) 螺旋模型(開發(fā)方法)螺旋模型(開發(fā)方法) 噴泉模型(開發(fā)方法)噴泉模型(開發(fā)方法) 敏捷開發(fā)過程(開發(fā)方法)敏捷開發(fā)過程(開發(fā)方法) 3.4.1 瀑布模型瀑布模型 l強調(diào)階段的劃分和階段嚴格的順序強調(diào)階段的劃分和階段嚴格的順序 l各階段工作任務明確,要求文檔完備性各階段工作任務明確,要求文檔完備性 l

23、是一種嚴格線性的按階段順序的、逐步細化的開發(fā)是一種嚴格線性的按階段順序的、逐步細化的開發(fā) 模式,消除了軟件開發(fā)的隨意性模式,消除了軟件開發(fā)的隨意性 規(guī)劃規(guī)劃 分析分析 設計設計 編程編程 測試測試 維護維護 瀑布模型的特點瀑布模型的特點 l簡單易用,容易理解簡單易用,容易理解 l開發(fā)的進程一個順著一個,沒有反饋過程,需要嚴開發(fā)的進程一個順著一個,沒有反饋過程,需要嚴 密控制密控制 l允許基線和配置早期接收控制允許基線和配置早期接收控制 l一個新的項目不適合這個模型一個新的項目不適合這個模型 l用戶直到項目結束才能看到質(zhì)量如何用戶直到項目結束才能看到質(zhì)量如何 l不允許或者嚴格限制變更不允許或者嚴

24、格限制變更 瀑布模型(后來實際)瀑布模型(后來實際) 實際的瀑布模型 瀑布模型的不足瀑布模型的不足 l需求:客戶常常難以表達真正的需求,而這種模型需求:客戶常常難以表達真正的需求,而這種模型 卻要求嚴格的階段性成果,返工困難,變更代價很卻要求嚴格的階段性成果,返工困難,變更代價很 大大 l風險:客戶要等到開發(fā)周期的晚期才能看到程序運風險:客戶要等到開發(fā)周期的晚期才能看到程序運 行的測試版本,這時若發(fā)現(xiàn)大的錯誤,可能引起客行的測試版本,這時若發(fā)現(xiàn)大的錯誤,可能引起客 戶的驚慌,其后果也可能是災難性的戶的驚慌,其后果也可能是災難性的 l效率:因為前后任務的依賴關系,成員不能并行工效率:因為前后任務

25、的依賴關系,成員不能并行工 作,有可能花在等待的時間比開發(fā)的時間要長,即作,有可能花在等待的時間比開發(fā)的時間要長,即 所謂的所謂的“堵塞狀態(tài)堵塞狀態(tài)” 適用于一些需求已明確并且變化較少的信息系統(tǒng)適用于一些需求已明確并且變化較少的信息系統(tǒng) 3.4.2 原型開發(fā)方法原型開發(fā)方法 l原型原型快速建立起來的可以在計算機上運行的程快速建立起來的可以在計算機上運行的程 序,通常選取信息系統(tǒng)中某個關鍵功能作為原型。序,通常選取信息系統(tǒng)中某個關鍵功能作為原型。 編程測試編程測試 分析分析 定義需求定義需求 設計設計 原型原型 實施完成實施完成 再構造再構造 原型方法的基本思想和開發(fā)步驟原型方法的基本思想和開發(fā)

26、步驟 l基本思想基本思想 在投入大量的人力、物力之前,在限定的時間內(nèi),在投入大量的人力、物力之前,在限定的時間內(nèi), 用最經(jīng)濟的方法構造一個系統(tǒng)原型,使用戶盡早看用最經(jīng)濟的方法構造一個系統(tǒng)原型,使用戶盡早看 到系統(tǒng)的概貌,在系統(tǒng)原型的實際運行中與用戶一到系統(tǒng)的概貌,在系統(tǒng)原型的實際運行中與用戶一 起發(fā)現(xiàn)問題,提出修改意見,不斷完善原型,使它起發(fā)現(xiàn)問題,提出修改意見,不斷完善原型,使它 逐步滿足用戶要求逐步滿足用戶要求 l開發(fā)步驟開發(fā)步驟 明確用戶基本信息需求明確用戶基本信息需求 建立初始原型(集成原則、最小系統(tǒng)原則)建立初始原型(集成原則、最小系統(tǒng)原則) 評價原型評價原型 修改和完善原型修改和完

27、善原型 快速原型的開發(fā)工具快速原型的開發(fā)工具 l第四代技術第四代技術 l可復用軟件構件可復用軟件構件 l形式化規(guī)約和原型環(huán)境形式化規(guī)約和原型環(huán)境 快速原型的類型快速原型的類型 l拋棄式原型。將開發(fā)原型看做是溝通工具,永遠也拋棄式原型。將開發(fā)原型看做是溝通工具,永遠也 不會將一次式原型引入正式運行環(huán)境中。主要解決不會將一次式原型引入正式運行環(huán)境中。主要解決 需求的不確定性,二義性,不完整性等。需求的不確定性,二義性,不完整性等。 l進化式原型。會在未來的系統(tǒng)中包含的原型。這種進化式原型。會在未來的系統(tǒng)中包含的原型。這種 方法能夠?qū)⒆畲罅康墓ぷ魍度氲秸较到y(tǒng)中。方法能夠?qū)⒆畲罅康墓ぷ魍度氲秸较到y(tǒng)

28、中。 l水平原型也稱為行為原型,用來探索預期系統(tǒng)的一水平原型也稱為行為原型,用來探索預期系統(tǒng)的一 些特定行為,并達到細化需求的目的。水平原型通些特定行為,并達到細化需求的目的。水平原型通 常只是功能導航,并未真實實現(xiàn)功能。主要用在用常只是功能導航,并未真實實現(xiàn)功能。主要用在用 戶界面上。戶界面上。 l垂直原型也稱為結構化原型,實現(xiàn)了一部分功能。垂直原型也稱為結構化原型,實現(xiàn)了一部分功能。 主要用在復雜的算法實現(xiàn)上。主要用在復雜的算法實現(xiàn)上。 拋棄式原型模型拋棄式原型模型 演化式原型模型演化式原型模型 是是 交付目標系交付目標系 統(tǒng)統(tǒng) 建立建立/完善原型完善原型 系統(tǒng)充分嗎系統(tǒng)充分嗎 ? 否否

29、軟件過程的演化式原型模型軟件過程的演化式原型模型 使用原型系統(tǒng)使用原型系統(tǒng)需求抽象描述需求抽象描述 快速原型的典型應用快速原型的典型應用 快速原型的評價快速原型的評價 l這個原型所實現(xiàn)的功能與你所期望的一致嗎?這個原型所實現(xiàn)的功能與你所期望的一致嗎? l有遺漏的功能嗎?有遺漏的功能嗎? l有多余的功能嗎?有多余的功能嗎? l你能考慮一下這個原型所沒有涉及到的一些出錯情你能考慮一下這個原型所沒有涉及到的一些出錯情 況嗎?況嗎? l這些功能導航的邏輯性和完整性如何?這些功能導航的邏輯性和完整性如何? l有更簡單的方法來完成這一任務嗎?有更簡單的方法來完成這一任務嗎? 原型模型的特點和應用場合原型模

30、型的特點和應用場合 l用戶積極參與用戶積極參與 l原型的開發(fā)沒有嚴密的階段性原型的開發(fā)沒有嚴密的階段性 l短期獲得測試版本,降低風險短期獲得測試版本,降低風險 應用于以下場合:應用于以下場合: 需求含糊,用戶不能標識出詳細的輸入、需求含糊,用戶不能標識出詳細的輸入、 處理和輸出需求處理和輸出需求 設計方案不明確,開發(fā)人員不能確定算法設計方案不明確,開發(fā)人員不能確定算法 的有效性、操作系統(tǒng)的適應性或人機交互的有效性、操作系統(tǒng)的適應性或人機交互 的有效性的有效性 原型模型的不足原型模型的不足 l降低風險的同時,引入了其他風險:降低風險的同時,引入了其他風險: 用戶隨意無止境的需求變化,因為用戶容易

31、產(chǎn)生誤解,認用戶隨意無止境的需求變化,因為用戶容易產(chǎn)生誤解,認 為系統(tǒng)很容易被構造和修改為系統(tǒng)很容易被構造和修改 如果采用原型基礎上繼續(xù)構造,由于修補過度,軟件質(zhì)量如果采用原型基礎上繼續(xù)構造,由于修補過度,軟件質(zhì)量 不易于保證不易于保證 開發(fā)人員為了快速構造原型,可能會采用不合適的操作系開發(fā)人員為了快速構造原型,可能會采用不合適的操作系 統(tǒng)、語言、算法等,造成后期風險,如系統(tǒng)適應性差、維統(tǒng)、語言、算法等,造成后期風險,如系統(tǒng)適應性差、維 護困難等護困難等 3.4.3 迭代開發(fā)過程迭代開發(fā)過程 l一條直線一次性到達目的總是困難的。一條直線一次性到達目的總是困難的。 l緊迫的市場期限和快速變化使得

32、難以一次性完成整緊迫的市場期限和快速變化使得難以一次性完成整 個軟件產(chǎn)品,解決方法是先提交一個有限的版本,個軟件產(chǎn)品,解決方法是先提交一個有限的版本, 細節(jié)部分逐步增加,即多次迭代后完成系統(tǒng)。融合細節(jié)部分逐步增加,即多次迭代后完成系統(tǒng)。融合 了瀑布方法和原型方法。了瀑布方法和原型方法。 l整個開發(fā)工作被組織為一系列的短小的、固定長度整個開發(fā)工作被組織為一系列的短小的、固定長度 的小項目,被稱為一系列的迭代。的小項目,被稱為一系列的迭代。 l有兩種迭代:有兩種迭代: 迭代增量:迭代周期完成一個增量,然后集成迭代增量:迭代周期完成一個增量,然后集成 迭代進化:迭代周期內(nèi)包含演化和完善迭代進化:迭代

33、周期內(nèi)包含演化和完善 增量模型(增量迭代)增量模型(增量迭代) 增量模型增量模型融合了瀑布模型的基本成分和原型的迭融合了瀑布模型的基本成分和原型的迭 代特征。采用隨著日程時間的進展而交錯的線性序代特征。采用隨著日程時間的進展而交錯的線性序 列。列。 搭積木的方式,如按子系統(tǒng)劃分增量搭積木的方式,如按子系統(tǒng)劃分增量 分析分析 分析分析 分析分析 分析分析 設計設計 設計設計 設計設計 設計設計 編碼編碼 編碼編碼 編碼編碼 編碼編碼 測試測試 測試測試 測試測試 測試測試 增量增量1 增量增量2 增量增量3 增量增量4 功能功能 時間時間 增量模型(增量迭代)的特點增量模型(增量迭代)的特點 l

34、以功能遞增的方式進行軟件開發(fā)(可并行化)以功能遞增的方式進行軟件開發(fā)(可并行化) l能較快地產(chǎn)生可操作的系統(tǒng)能較快地產(chǎn)生可操作的系統(tǒng) l在每一步遞增中,都可以把用戶在每一步遞增中,都可以把用戶/ /開發(fā)者的經(jīng)驗結合開發(fā)者的經(jīng)驗結合 到不斷求精的下一個增量中到不斷求精的下一個增量中 l可改善測試效果和降低軟件開發(fā)總成本。可改善測試效果和降低軟件開發(fā)總成本。 l這個過程好比搭積木。這個過程好比搭積木。 進化迭代的特點進化迭代的特點 l進化迭代與增量迭代的區(qū)別是在每個迭代周期是對進化迭代與增量迭代的區(qū)別是在每個迭代周期是對 上一次迭代的演化和完善。上一次迭代的演化和完善。 l比如可以將一個軟件功能的

35、編程劃分了多個迭代周比如可以將一個軟件功能的編程劃分了多個迭代周 期,每個迭代是對該功能的補充和進化。期,每個迭代是對該功能的補充和進化。 l這個過程好比滾雪球。這個過程好比滾雪球。 增量模型的應用場合增量模型的應用場合 l項目開始,明確了需求的大部分,但是需求可能會項目開始,明確了需求的大部分,但是需求可能會 發(fā)生變化發(fā)生變化 l對于市場和用戶把握不是很準,需要逐步了解對于市場和用戶把握不是很準,需要逐步了解 l對于有龐大和復雜功能的系統(tǒng)進行功能改進,本身對于有龐大和復雜功能的系統(tǒng)進行功能改進,本身 就需要一步一步實施的。就需要一步一步實施的。 迭代開發(fā)過程示例迭代開發(fā)過程示例 l例子:設計

36、一個字處理軟件例子:設計一個字處理軟件 增量增量1 1:實現(xiàn)軟件的基本需求,提供最核心:實現(xiàn)軟件的基本需求,提供最核心 的功能。的功能。 增量增量2 2:提供更完善的編輯和文檔生成功能。:提供更完善的編輯和文檔生成功能。 增量增量3 3:實現(xiàn)拼寫和語法檢查功能。:實現(xiàn)拼寫和語法檢查功能。 增量增量4 4:完成高級的頁面排版功能。:完成高級的頁面排版功能。 迭代開發(fā)過程的應用場合迭代開發(fā)過程的應用場合 l項目開始,明確了需求的大部分,但是需求可能會項目開始,明確了需求的大部分,但是需求可能會 發(fā)生變化發(fā)生變化 l對于市場和用戶把握不是很準,需要逐步了解對于市場和用戶把握不是很準,需要逐步了解 l

37、對于有龐大和復雜功能的系統(tǒng)進行功能改進,本身對于有龐大和復雜功能的系統(tǒng)進行功能改進,本身 就需要一步一步實施的。就需要一步一步實施的。 3.4.4 螺旋模型螺旋模型 l螺旋方法螺旋方法把軟件開發(fā)過程定義成不斷上升的螺把軟件開發(fā)過程定義成不斷上升的螺 旋周期,每個周期劃分為計劃、旋周期,每個周期劃分為計劃、風險分析、實施和風險分析、實施和 評價四個方面。沿螺線自內(nèi)向外每旋轉(zhuǎn)一圈便開發(fā)評價四個方面。沿螺線自內(nèi)向外每旋轉(zhuǎn)一圈便開發(fā) 出更為完善的一個新的軟件版本。出更為完善的一個新的軟件版本。 這里的原型不是用于驗這里的原型不是用于驗 證的原型系統(tǒng),而是最證的原型系統(tǒng),而是最 終要交付的成品系統(tǒng)。終要

38、交付的成品系統(tǒng)。 螺旋模型的特點和應用場合螺旋模型的特點和應用場合 l風險驅(qū)動,可以在生命周期早期強制性的確定項目風險驅(qū)動,可以在生命周期早期強制性的確定項目 中存在的風險中存在的風險 l需要開發(fā)人員具有相當豐富的風險評估經(jīng)驗和專門需要開發(fā)人員具有相當豐富的風險評估經(jīng)驗和專門 知識知識 l要求用戶參與階段評價,對用戶要求較高要求用戶參與階段評價,對用戶要求較高 適用于:適用于: 單位內(nèi)部開發(fā)的大規(guī)模軟件項目單位內(nèi)部開發(fā)的大規(guī)模軟件項目 風險是項目的主要制約因素風險是項目的主要制約因素 可能會發(fā)生重大變更可能會發(fā)生重大變更 采用新技術采用新技術 3.4.5 噴泉模型噴泉模型 l噴泉模型噴泉模型主

39、要用于面向?qū)ο蠹夹g的軟件開發(fā)項主要用于面向?qū)ο蠹夹g的軟件開發(fā)項 目,它克服了瀑布模型不支持軟件重用和多項開發(fā)目,它克服了瀑布模型不支持軟件重用和多項開發(fā) 活動集成的局限性,噴泉模型使開發(fā)過程具有迭代活動集成的局限性,噴泉模型使開發(fā)過程具有迭代 性和無間隙性。性和無間隙性。 噴泉模型以面向?qū)ο蟮能浖_發(fā)方法為基礎,噴泉模型以面向?qū)ο蟮能浖_發(fā)方法為基礎, 以用戶需求作為噴泉模型的源泉,屬于面向?qū)ο蟮囊杂脩粜枨笞鳛閲娙P偷脑慈?,屬于面向?qū)ο蟮?軟件過程模型。軟件過程模型。 噴泉模型 特點: 各階段相互重疊,它反映了軟件過 程并行性的特點 體現(xiàn)認識事物的往返過程 強調(diào)增量開發(fā),整個過程是一個迭 代

40、的逐步提煉的過程。 開發(fā)活動之間的無間隙性和循環(huán)迭 代性 適用于面向?qū)ο蟮拈_發(fā)過程 強調(diào)無明顯的活動階段劃分 集成和測試集成和測試 階段階段 編碼階段編碼階段 面向?qū)ο笤O面向?qū)ο笤O 計階段計階段 面向?qū)ο蠓置嫦驅(qū)ο蠓?析階段析階段 需求階段需求階段 進一步開發(fā) 進行狀態(tài) 維護期 第3章信息系統(tǒng)建設概論 3.4.6 敏捷開發(fā)過程敏捷開發(fā)過程 l敏捷過程(敏捷過程(agile process)是一系列輕量的過程模)是一系列輕量的過程模 型的總稱,致力于在無過程和過于繁瑣的過程中達型的總稱,致力于在無過程和過于繁瑣的過程中達 到一種平衡,強調(diào)對需求變化的敏捷響應,以不多到一種平衡,強調(diào)對需求變化的敏

41、捷響應,以不多 的步驟過程獲取滿意的結果。的步驟過程獲取滿意的結果。 l敏捷軟件開發(fā)宣言:敏捷軟件開發(fā)宣言: 1 1個體和交互勝過過程和工具個體和交互勝過過程和工具 2 2可以工作的軟件勝過面面懼到的文檔可以工作的軟件勝過面面懼到的文檔 3 3客戶合作勝過合同談判客戶合作勝過合同談判 4 4響應變化勝過遵循變化響應變化勝過遵循變化 雖然右項也有價值,但我們認為左項具有更大的價值。雖然右項也有價值,但我們認為左項具有更大的價值。 l基于迭代開發(fā)方法探索出的成功實踐?;诘_發(fā)方法探索出的成功實踐。 開發(fā)過程的代表產(chǎn)品開發(fā)過程的代表產(chǎn)品 一些公司或團體紛紛推出規(guī)范化的過程產(chǎn)品:一些公司或團體紛紛

42、推出規(guī)范化的過程產(chǎn)品: lIBM統(tǒng)一過程統(tǒng)一過程RUP(Rational Unified Process,迭,迭 代過程的代表,重量級過程)代過程的代表,重量級過程) l微軟微軟MSF(Microsoft Solutions Framework ) l敏捷:極限編程、敏捷:極限編程、Scrum(輕量級過程)(輕量級過程) l 練習題練習題 l假設要開發(fā)一個軟件,該軟件的功能是對特定項目假設要開發(fā)一個軟件,該軟件的功能是對特定項目 進行一項驗證計算(假定計算方法十分確定、成進行一項驗證計算(假定計算方法十分確定、成 熟),一旦實現(xiàn)后將用于該項目的測試驗證中,由熟),一旦實現(xiàn)后將用于該項目的測試驗

43、證中,由 于項目的特殊性,所以,該軟件產(chǎn)品在完成使命后于項目的特殊性,所以,該軟件產(chǎn)品在完成使命后 將被拋棄。將被拋棄。 軟件需求明確,算法確定、成熟,故無須原型來驗證。軟件需求明確,算法確定、成熟,故無須原型來驗證。 一旦驗證完成之后將被拋棄,故無須使用提高軟件可維一旦驗證完成之后將被拋棄,故無須使用提高軟件可維 護性的迭代模型和螺旋模型。護性的迭代模型和螺旋模型。 綜上所述,為了開發(fā)此軟件,使用瀑布模型即可。綜上所述,為了開發(fā)此軟件,使用瀑布模型即可。 3.5 信息系統(tǒng)開發(fā)技術信息系統(tǒng)開發(fā)技術 (基于開發(fā)技術的開發(fā)方法)(基于開發(fā)技術的開發(fā)方法) l信息系統(tǒng)通常十分復雜,通常會借助于模型對

44、它進信息系統(tǒng)通常十分復雜,通常會借助于模型對它進 行研究、認識、描述和設計。行研究、認識、描述和設計。 l本節(jié)從模型化的角度探討信息系統(tǒng)不同開發(fā)方法的本節(jié)從模型化的角度探討信息系統(tǒng)不同開發(fā)方法的 形成和各自特點。形成和各自特點。 3.5.1 管理模型到信息模型管理模型到信息模型 l信息系統(tǒng)模型最核心的是信息處理模型,應考慮兩信息系統(tǒng)模型最核心的是信息處理模型,應考慮兩 個方面:個方面: 信息處理模型最核心的是軟件結構模型,而軟件模型由信息處理模型最核心的是軟件結構模型,而軟件模型由 計算機程序語言的特性來決定。計算機程序語言的特性來決定。 機器語言、匯編語言、機器語言、匯編語言、C、C+ 1.

45、1.信息處理模型來源于管理模型,而管理系統(tǒng)模型包含以信息處理模型來源于管理模型,而管理系統(tǒng)模型包含以 下方面:下方面: 管理系統(tǒng)管理系統(tǒng) 靜態(tài)特征靜態(tài)特征( (對象、屬性、關系對象、屬性、關系) ) 動態(tài)特征(行為動態(tài)特征(行為/ /事件事件/ /行動行動/ /狀態(tài)狀態(tài)) 業(yè)務流程業(yè)務流程 業(yè)務規(guī)則業(yè)務規(guī)則 . . 模型模型 信息處理模型信息處理模型 l管理模型抽象描述了需要解決的管理問題(問題空管理模型抽象描述了需要解決的管理問題(問題空 間),而信息處理模型則回答信息系統(tǒng)將如何解決間),而信息處理模型則回答信息系統(tǒng)將如何解決 問題(解空間)問題(解空間) l這個求解過程中最這個求解過程中最

46、核心的內(nèi)容核心的內(nèi)容在于在于信息處理模型中信息處理模型中 的的軟件軟件系統(tǒng)系統(tǒng)。 管理領域及問題 管理模型 信息處理模型 系統(tǒng)實現(xiàn)條件 信息系統(tǒng) 技術環(huán)境 信 息 系 統(tǒng) 學 科 信息處理模型信息處理模型 l信息系統(tǒng)包含硬件、軟件、信息等組成要素。信息系統(tǒng)包含硬件、軟件、信息等組成要素。 l但其中軟件系統(tǒng)的狀態(tài)比硬件系統(tǒng)的狀態(tài)往往要多但其中軟件系統(tǒng)的狀態(tài)比硬件系統(tǒng)的狀態(tài)往往要多 若干數(shù)量級,只有找到控制和降低軟件復雜性的方若干數(shù)量級,只有找到控制和降低軟件復雜性的方 法,才能根本地控制和降低信息系統(tǒng)復雜性。法,才能根本地控制和降低信息系統(tǒng)復雜性。 l人們不斷研究新的軟件開發(fā)技術,試圖縮小計算機

47、人們不斷研究新的軟件開發(fā)技術,試圖縮小計算機 世界和現(xiàn)實世界之間的鴻溝,從而讓管理模型與信世界和現(xiàn)實世界之間的鴻溝,從而讓管理模型與信 息處理模型有更高的一致性,易于轉(zhuǎn)換和實現(xiàn)。息處理模型有更高的一致性,易于轉(zhuǎn)換和實現(xiàn)。 設計優(yōu)秀的軟件結構設計優(yōu)秀的軟件結構 l優(yōu)秀的軟件結構應具有以下特性:優(yōu)秀的軟件結構應具有以下特性: 能真實、充分地反映現(xiàn)實世界,包括事物和事物之間的聯(lián)能真實、充分地反映現(xiàn)實世界,包括事物和事物之間的聯(lián) 系,能滿足用戶對數(shù)據(jù)的處理要求;系,能滿足用戶對數(shù)據(jù)的處理要求; 易于理解,方便開發(fā)人員之間、開發(fā)人員與用戶之間交換易于理解,方便開發(fā)人員之間、開發(fā)人員與用戶之間交換 意見;

48、意見; 易于更改,當應用環(huán)境和應用要求改變時,能容易地對系易于更改,當應用環(huán)境和應用要求改變時,能容易地對系 統(tǒng)進行修改和擴充;統(tǒng)進行修改和擴充; 易于向計算機支持的數(shù)據(jù)結構轉(zhuǎn)換。易于向計算機支持的數(shù)據(jù)結構轉(zhuǎn)換。 l軟件結構從簡單到復雜,走過了從機器指令、語句、軟件結構從簡單到復雜,走過了從機器指令、語句、 模塊封裝到類封裝、再到構件和服務封裝的歷史發(fā)模塊封裝到類封裝、再到構件和服務封裝的歷史發(fā) 展過程,不同的開發(fā)技術和軟件結構催生了不同的展過程,不同的開發(fā)技術和軟件結構催生了不同的 開發(fā)方法。開發(fā)方法。 軟件結構設計的基本原則軟件結構設計的基本原則 l抽象第一抽象第一 抽象是人類認識世界的基

49、本法則之一。對實際的事物進行抽象是人類認識世界的基本法則之一。對實際的事物進行 處理,抽取所關心的、共同的、本質(zhì)特征的屬性,并對這處理,抽取所關心的、共同的、本質(zhì)特征的屬性,并對這 些事物及其特征屬性進行描述。由于抽取的是共同的、本些事物及其特征屬性進行描述。由于抽取的是共同的、本 質(zhì)特征的屬性,從而大大降低了系統(tǒng)元素的絕對數(shù)量。質(zhì)特征的屬性,從而大大降低了系統(tǒng)元素的絕對數(shù)量。 l層次劃分層次劃分 復雜系統(tǒng)可以先分解為子系統(tǒng),逐層分解。分解的每個子復雜系統(tǒng)可以先分解為子系統(tǒng),逐層分解。分解的每個子 集互不相交,能使注意力集中與某個子集內(nèi)部及與其他子集互不相交,能使注意力集中與某個子集內(nèi)部及與其

50、他子 集的聯(lián)系。層次和每層子集的數(shù)目為短時記憶最大容量集的聯(lián)系。層次和每層子集的數(shù)目為短時記憶最大容量 7 72 2的范圍之內(nèi)。的范圍之內(nèi)。 l模型化模型化 提出以模型代替真實系統(tǒng)進行模擬實驗,達到認識真實系提出以模型代替真實系統(tǒng)進行模擬實驗,達到認識真實系 統(tǒng)特性和規(guī)律性的方法。統(tǒng)特性和規(guī)律性的方法。 信息系統(tǒng)的開發(fā)技術信息系統(tǒng)的開發(fā)技術 l信息系統(tǒng)的開發(fā)技術(基于軟件技術的開發(fā)方法):信息系統(tǒng)的開發(fā)技術(基于軟件技術的開發(fā)方法): 結構化開發(fā)技術結構化開發(fā)技術 面向數(shù)據(jù)開發(fā)技術面向數(shù)據(jù)開發(fā)技術 面向?qū)ο箝_發(fā)技術面向?qū)ο箝_發(fā)技術 面向服務開發(fā)技術面向服務開發(fā)技術 3.5.2 結構化開發(fā)技術結

51、構化開發(fā)技術 l結構化方法論(結構化方法論(Structured Methodology)是計算)是計算 學科的一種典型的系統(tǒng)開發(fā)方法論。學科的一種典型的系統(tǒng)開發(fā)方法論。 它采用了系統(tǒng)科學的思想方法,從層次的角度,自頂向下它采用了系統(tǒng)科學的思想方法,從層次的角度,自頂向下 地分析和設計系統(tǒng),即抽象與分解。地分析和設計系統(tǒng),即抽象與分解。 系統(tǒng)可用高級的抽象概念來理解和構造系統(tǒng)可用高級的抽象概念來理解和構造, , 這些高級的抽象這些高級的抽象 概念又可用較低級的抽象概念來理解和構造,如此進行下概念又可用較低級的抽象概念來理解和構造,如此進行下 去,直到最低層次的模塊可以表示成某種程序設計語言的去

52、,直到最低層次的模塊可以表示成某種程序設計語言的 語句為止。語句為止。 結構化開發(fā)技術結構化開發(fā)技術 l也稱為也稱為 面向功能面向功能/ /面向過程面向過程/ /面向數(shù)據(jù)流面向數(shù)據(jù)流 的軟件開的軟件開 發(fā)方法發(fā)方法 l結構化方法包括結構化分析(結構化方法包括結構化分析(Structured Analysis, 簡稱簡稱SA)、結構化設計()、結構化設計(Structured Design,簡,簡 稱稱SD)和結構化程序設計()和結構化程序設計(Structured Program, 簡稱簡稱SP)三部分內(nèi)容:)三部分內(nèi)容: 結構化分析(結構化分析(SASA)對軟件進行需求分析,以數(shù)據(jù)流圖表示)

53、對軟件進行需求分析,以數(shù)據(jù)流圖表示 結構化設計(結構化設計(SDSD)進行總體設計,以結構圖表示)進行總體設計,以結構圖表示 結構化編程(結構化編程(SPSP),以程序流程圖表示),以程序流程圖表示 結構化開發(fā)方法的形成結構化開發(fā)方法的形成/1 l結構化程序設計結構化程序設計SP方法的產(chǎn)生方法的產(chǎn)生 結構化方法起源于結構化程序設計語言。在使用結構化方法起源于結構化程序設計語言。在使用SPSP之前,之前, 程序員都是按照各自的習慣和思路來編寫程序,沒有統(tǒng)一程序員都是按照各自的習慣和思路來編寫程序,沒有統(tǒng)一 的標準,這樣編寫的程序可讀性差,更為嚴重的是程序的的標準,這樣編寫的程序可讀性差,更為嚴重

54、的是程序的 可維護性極差,經(jīng)過研究發(fā)現(xiàn),造成這一現(xiàn)象的根本原因可維護性極差,經(jīng)過研究發(fā)現(xiàn),造成這一現(xiàn)象的根本原因 是程序的結構問題。是程序的結構問題。 19661966年,年,C.BC.Bhmhm和和G.JacopiniG.Jacopini提出了關于提出了關于“程序結構程序結構” 的理論,并給出了任何程序的邏輯結構都可以用順序結構、的理論,并給出了任何程序的邏輯結構都可以用順序結構、 選擇結構和循環(huán)結構來表示的證明。在程序結構理論的基選擇結構和循環(huán)結構來表示的證明。在程序結構理論的基 礎上,礎上,19681968年,戴克斯特拉提出了年,戴克斯特拉提出了“GOTOGOTO語句是有害的語句是有害的

55、” 的問題,并引起普遍重視,的問題,并引起普遍重視,SPSP逐漸形成,并成為計算機軟逐漸形成,并成為計算機軟 件領域的重要方法,對計算機軟件的發(fā)展具有重要的意義。件領域的重要方法,對計算機軟件的發(fā)展具有重要的意義。 伴隨著伴隨著SPSP的形成,相繼出現(xiàn)了的形成,相繼出現(xiàn)了Modula-2Modula-2、C C以及以及AdaAda等結構等結構 化程序設計語言?;绦蛟O計語言。 結構化開發(fā)方法的形成結構化開發(fā)方法的形成/2 l結構化設計方法結構化設計方法SD的形成的形成 結構化程序設計需要事先設計好每一個具體的功能模塊,結構化程序設計需要事先設計好每一個具體的功能模塊, 然后將這些設計好的模塊組

56、裝成一個軟件系統(tǒng)。然后將這些設計好的模塊組裝成一個軟件系統(tǒng)。 源于結構化程序設計思想的結構化設計方法就是要解決模源于結構化程序設計思想的結構化設計方法就是要解決模 塊的構建問題。塊的構建問題。19741974年,年,W.StevensW.Stevens、G.MyersG.Myers和和 L.ConstantineL.Constantine等人在等人在IBMIBM系統(tǒng)系統(tǒng)(IBM SystemIBM System)雜志上)雜志上 發(fā)表了發(fā)表了結構化設計結構化設計(Structured DesignStructured Design)論文,為)論文,為 結構化設計方法奠定了思想基礎。結構化設計方法

57、奠定了思想基礎。 l結構化分析方法結構化分析方法SA的形成的形成 結構化設計方法建立在系統(tǒng)需求明確的基礎上。如何明確結構化設計方法建立在系統(tǒng)需求明確的基礎上。如何明確 系統(tǒng)的需求,就是結構化分析所要解決的問題。系統(tǒng)的需求,就是結構化分析所要解決的問題。 結構化分析方法產(chǎn)生于結構化分析方法產(chǎn)生于2020世紀世紀7070年代中期,最初的倡導者年代中期,最初的倡導者 有有Tom DemarcoTom Demarco、Ed YourdonEd Yourdon等人。等人。 結構化分析在結構化分析在2020世紀世紀8080年代又得到了進一步的發(fā)展,并隨年代又得到了進一步的發(fā)展,并隨 著著Ed Yourdo

58、nEd Yourdon于于19891989年所著的年所著的現(xiàn)代結構化分析現(xiàn)代結構化分析 (Modern Structured AnalysisModern Structured Analysis)的出版而流行開來。現(xiàn))的出版而流行開來?,F(xiàn) 代結構化分析更強調(diào)建模的重要性。代結構化分析更強調(diào)建模的重要性。 結構化方法五個基本原則結構化方法五個基本原則 l面向用戶的觀點面向用戶的觀點 l嚴格區(qū)分工作階段,每個階段有明確的任務和應得嚴格區(qū)分工作階段,每個階段有明確的任務和應得 的成果的成果 l按照系統(tǒng)的觀點,自頂向下地完成系統(tǒng)的研制工作按照系統(tǒng)的觀點,自頂向下地完成系統(tǒng)的研制工作 l充分考慮變化的情

59、況充分考慮變化的情況 l工作成果文獻化、標準化工作成果文獻化、標準化 結構化分析結構化分析數(shù)據(jù)流圖數(shù)據(jù)流圖 顧客顧客 編編 輯輯 訂貨單訂貨單 訂貨單訂貨單 配件庫存配件庫存 1.11.1 確確 定定 顧顧 客客 訂訂 貨貨 1.21.21.31.3 業(yè)務業(yè)務 員員 產(chǎn)產(chǎn) 生生 暫暫 存存 訂貨單訂貨單 1.41.4 不合格不合格 顧客顧客 D D2 2 D D3 3 可發(fā)可發(fā) 訂貨訂貨 不滿足不滿足 的訂貨的訂貨 暫存訂貨單暫存訂貨單 D D4 4 銷售歷史銷售歷史 D D5 5 應收款明細賬應收款明細賬 D D1010 合格的訂貨單合格的訂貨單 檢檢 索索 庫庫 存存 1.51.5 經(jīng)理經(jīng)

60、理 查詢請求查詢請求 庫庫 存存 狀狀 態(tài)態(tài) 開發(fā)貨單開發(fā)貨單 并并 修改庫存修改庫存 顧客顧客 發(fā)貨單發(fā)貨單 模型中的某個功能的分解圖:模型中的某個功能的分解圖: 結構化設計結構化設計模塊結構圖模塊結構圖 銷售子系統(tǒng) 暫 存 訂 貨 單 處 理 登 記 訂 貨 單 查 詢 打 印 發(fā) 貨 單 作 廢 訂 貨 單 查 詢 訂 貨 單 查 詢 庫 存 暫暫 存存 處處 理理 修修 改改 庫庫 存存 沖 賬 結構化模型結構化模型數(shù)據(jù)流圖數(shù)據(jù)流圖 模型的層次和分解:模型的層次和分解: 結構化模型結構化模型模塊結構圖模塊結構圖 圖書館管理系統(tǒng)圖書館管理系統(tǒng) 圖書管理圖書管理 讀者管理讀者管理 借還書管

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論