管理信息系統(tǒng)的開發(fā)方式與方法

管理信息系統(tǒng)的開發(fā)方式與方法第一頁，共一百一十一頁，編輯于2023年，星期一內(nèi)容

內(nèi)容提要3.1MIS開發(fā)涉及的基本問題3.2MIS的開發(fā)方式3.3結(jié)構(gòu)化生命周期法3.4原型法（PrototypingApproach）3.5面向?qū)ο蟮姆椒?.6軟件開發(fā)工具3.7MIS開發(fā)的組織工作

小結(jié)

習(xí)題3

返回第二頁，共一百一十一頁，編輯于2023年，星期一內(nèi)容提要

MIS的開發(fā)是一個(gè)復(fù)雜的系統(tǒng)工程，它要受到多方面條件的制約。研究這些條件無疑將有助于MIS的開發(fā)，有利于對MIS開發(fā)中涉及到的有關(guān)問題的理解。在MIS建設(shè)的長期實(shí)踐中，已形成了多種系統(tǒng)開發(fā)的方式和方法。因此，為了保證系統(tǒng)開發(fā)工作的順利進(jìn)行，應(yīng)該根據(jù)所開發(fā)系統(tǒng)的規(guī)模大小、技術(shù)的復(fù)雜程度、管理水平的高低、技術(shù)人員的情況、資金與時(shí)間要求等各個(gè)方面的不同要求采用不同的開發(fā)方式與方法。

返回第三頁，共一百一十一頁，編輯于2023年，星期一學(xué)完本章后，應(yīng)該掌握以下內(nèi)容：

1．

MIS開發(fā)的基本原則

2．

MIS開發(fā)應(yīng)具備的條件

3．

MIS的開發(fā)策略

4．

MIS的開發(fā)方式

5．

MIS的常用開發(fā)方法

6.MIS開發(fā)的環(huán)境

返回第四頁，共一百一十一頁，編輯于2023年，星期一3.1MIS開發(fā)涉及的基本問題3.1.1

MIS開發(fā)的基本原則3.1.2MIS開發(fā)的條件3.1.3MIS的開發(fā)策略

返回

第五頁，共一百一十一頁，編輯于2023年，星期一3.1.1MIS開發(fā)的基本原則

⑴實(shí)用性原則

⑵系統(tǒng)性原則

⑶符合軟件工程規(guī)范的原則

⑷完善，逐步發(fā)展的原則

返回第六頁，共一百一十一頁，編輯于2023年，星期一⑴實(shí)用性原則

系統(tǒng)必須滿足用戶管理上的要求，既保證系統(tǒng)功能的正確性又方便實(shí)用，需要友好的用戶界面、靈活的功能調(diào)度、簡便的操作和完善的系統(tǒng)維護(hù)措施。

實(shí)用/系統(tǒng)/軟件工程/逐步/返回

第七頁，共一百一十一頁，編輯于2023年，星期一⑵系統(tǒng)性原則

在MIS的開發(fā)過程中,必須十分注重其功能和數(shù)據(jù)上的整體性、系統(tǒng)性。

實(shí)用/系統(tǒng)/軟件工程/逐步/返回第八頁，共一百一十一頁，編輯于2023年，星期一⑶符合軟件工程規(guī)范的原則

MIS的開發(fā)是一項(xiàng)復(fù)雜的應(yīng)用軟件工程，應(yīng)該按軟件工程的理論、方法和規(guī)范去組織與實(shí)施。

實(shí)用/系統(tǒng)/軟件工程/逐步/返回第九頁，共一百一十一頁，編輯于2023年，星期一⑷逐步完善,逐步發(fā)展的原則

MIS的建立不可能一開始就十分完善和先進(jìn)，而總是要經(jīng)歷一個(gè)逐步完善、逐步發(fā)展的過程。

實(shí)用/系統(tǒng)/軟件工程/逐步/返回

第十頁，共一百一十一頁，編輯于2023年，星期一3.1.2MIS開發(fā)的條件

1.MIS開發(fā)的條件

2.MIS開發(fā)前的準(zhǔn)備工作

返回第十一頁，共一百一十一頁，編輯于2023年，星期一1.MIS開發(fā)的條件⑴領(lǐng)導(dǎo)重視，業(yè)務(wù)人員積極性高;⑵必須有建立MIS的實(shí)際需求和迫切性;⑶必須要有一定的科學(xué)管理基礎(chǔ);⑷有必要的投資保證，并能提供系統(tǒng)維護(hù)人員的編制和維護(hù)費(fèi)用;⑸管理人員知識結(jié)構(gòu)應(yīng)滿足系統(tǒng)建設(shè)需要;⑹基礎(chǔ)數(shù)據(jù)要齊全規(guī)范。返回第十二頁，共一百一十一頁，編輯于2023年，星期一2.MIS開發(fā)前的準(zhǔn)備工作⑴建立開發(fā)領(lǐng)導(dǎo)機(jī)構(gòu)及組織開發(fā)隊(duì)伍；⑵借鑒同類系統(tǒng)的開發(fā)經(jīng)驗(yàn)；⑶選擇適合本企業(yè)實(shí)際的開發(fā)方式；⑷確定系統(tǒng)目標(biāo)、開發(fā)策略和投資金額；⑸收集和整理基礎(chǔ)數(shù)據(jù)。

返回

第十三頁，共一百一十一頁，編輯于2023年，星期一3.1.3MIS的開發(fā)策略

1.幾種可以考慮的開發(fā)策略2.選擇策略時(shí)應(yīng)注意的3個(gè)問題

返回第十四頁，共一百一十一頁，編輯于2023年，星期一1.幾種可以考慮的開發(fā)策略⑴接受式開發(fā)策略⑵直線式開發(fā)策略⑶迭代式開發(fā)策略⑷實(shí)驗(yàn)式開發(fā)策略⑸規(guī)劃式開發(fā)策略

圖3—1選擇開發(fā)策略的模型

返回第十五頁，共一百一十一頁，編輯于2023年，星期一⑴接受式開發(fā)策略

認(rèn)為用戶對信息的需求的敘述是正確的、完全的和固定的，并且以此作為開發(fā)的根據(jù)。

接受/直線/迭代/實(shí)驗(yàn)/規(guī)劃/模型/適合/返回第十六頁，共一百一十一頁，編輯于2023年，星期一適合：

小項(xiàng)目，高度結(jié)構(gòu)化，用戶需求明確和開發(fā)者有充分經(jīng)驗(yàn)的情形。

例如：對文件的轉(zhuǎn)換、從已有文件或數(shù)據(jù)庫中產(chǎn)生各種報(bào)表、以及某些簡單的、單用戶的系統(tǒng)等。

返回第十七頁，共一百一十一頁，編輯于2023年，星期一⑵直線式開發(fā)策略

從需求說明開始到最后開發(fā)直線的進(jìn)行下去,每完成一步都要進(jìn)行評審,以驗(yàn)證是否和需求一致。

接受/直線/迭代/實(shí)驗(yàn)/規(guī)劃/模型/適合/返回第十八頁，共一百一十一頁，編輯于2023年，星期一直線式開發(fā)策略適合：

用戶的應(yīng)用需求可較好的定義,且以后不需進(jìn)一步修改或只需稍作修改(如生命周期法)、系統(tǒng)規(guī)模較大,但結(jié)構(gòu)化程度高,用戶任務(wù)的綜合性強(qiáng)以及開發(fā)者具有熟練技術(shù)與豐富經(jīng)驗(yàn)的情形。

返回第十九頁，共一百一十一頁，編輯于2023年，星期一⑶迭代式開發(fā)策略

研制過程中驗(yàn)證需求不論是有錯還是不恰當(dāng)，都可以回到需求確定過程，對需求說明進(jìn)行修改，如此重復(fù)進(jìn)行,直到所開發(fā)的系統(tǒng)滿足需求為止。

若開發(fā)需求的不確定性比較高,直線式開發(fā)策略不能保證用戶真正的信息需求,就需要把傳統(tǒng)直線式過程加以改進(jìn),使其按迭代方式重復(fù)進(jìn)行。

接受/直線/迭代/實(shí)驗(yàn)/規(guī)劃/模型/適合/返回第二十頁，共一百一十一頁，編輯于2023年，星期一迭代式開發(fā)策略適合：

大型多用戶系統(tǒng)、對用戶或開發(fā)者來說是新的應(yīng)用領(lǐng)域的情形。

返回第二十一頁，共一百一十一頁，編輯于2023年，星期一⑷實(shí)驗(yàn)式開發(fā)策略

采用原型法或應(yīng)用的模擬,通過試驗(yàn)的方式去逐次近似并減少不確定信息需求,同時(shí)找出原型的缺點(diǎn),直到用戶對需求完全理解和需求得到保證為止。

接受/直線/迭代/實(shí)驗(yàn)/規(guī)劃/模型/下頁/返回第二十二頁，共一百一十一頁，編輯于2023年，星期一

若信息需求不確定性很高,則可通過一個(gè)實(shí)際工作系統(tǒng)來驗(yàn)證需求是否得到保證。如：高層管理決策支持系統(tǒng)、交互預(yù)測模型及多用戶的非結(jié)構(gòu)化系統(tǒng)等。

返回第二十三頁，共一百一十一頁，編輯于2023年，星期一⑸規(guī)劃式開發(fā)策略

從系統(tǒng)的戰(zhàn)略目標(biāo)、信息需求分析、資源分配和項(xiàng)目計(jì)劃等方面進(jìn)行規(guī)劃,合理的設(shè)計(jì)出系統(tǒng)的總體結(jié)構(gòu)。各個(gè)子系統(tǒng)的開發(fā),則根據(jù)其信息需求的不確定性程度,選擇不同的開發(fā)策略。

接受/直線/迭代/實(shí)驗(yàn)/規(guī)劃/模型/適合/返回第二十四頁，共一百一十一頁，編輯于2023年，星期一規(guī)劃式開發(fā)策略適用于：

MIS的規(guī)模特別大,復(fù)雜程度特別高,例如跨地區(qū)、跨部門的全國性的大系統(tǒng),其信息需求的不確定性程度特別大,必須做好MIS的總體規(guī)劃。

返回第二十五頁，共一百一十一頁，編輯于2023年，星期一圖3—1選擇開發(fā)策略的模型

接受/直線/迭代/實(shí)驗(yàn)/規(guī)劃/模型/返回

不確定因素不確定級別開發(fā)策略?項(xiàng)目的規(guī)則?結(jié)構(gòu)化程度?用戶對任務(wù)的理解程度?開發(fā)者對任務(wù)熟練程度低中高很高?接受式?直線式?迭代式?實(shí)驗(yàn)式?規(guī)劃式第二十六頁，共一百一十一頁，編輯于2023年，星期一2.選擇策略時(shí)應(yīng)注意的3個(gè)問題

(1)

關(guān)于總體規(guī)劃(2)開發(fā)的技術(shù)方法(3)

開發(fā)的進(jìn)程控制

返回第二十七頁，共一百一十一頁，編輯于2023年，星期一⑴關(guān)于總體規(guī)劃

在系統(tǒng)建立與開發(fā)過程的整體規(guī)劃上,應(yīng)采取“總體規(guī)劃,分期實(shí)施,逐步投資,逐步見效”的策略原則。具體的方法有以下兩種：①“自上而下”的方法②“自下而上”的方法

返回第二十八頁，共一百一十一頁，編輯于2023年，星期一⑵開發(fā)的技術(shù)方法

在考慮系統(tǒng)開發(fā)的技術(shù)方法上,必須注意應(yīng)用成熟的技術(shù),MIS開發(fā)不是搞科研,而是一項(xiàng)應(yīng)用軟件工程。

返回第二十九頁，共一百一十一頁，編輯于2023年，星期一(3)開發(fā)的進(jìn)程控制

在系統(tǒng)開發(fā)的進(jìn)程控制上，應(yīng)立足于采用增量實(shí)現(xiàn)的策略。

返回第三十頁，共一百一十一頁，編輯于2023年，星期一3.2MIS的開發(fā)方式3.2.1

自行開發(fā)3.2.2

委托開發(fā)3.2.3

合作開發(fā)3.2.4

利用現(xiàn)成軟件包開發(fā)

返回第三十一頁，共一百一十一頁，編輯于2023年，星期一3.2.1自行開發(fā)

——由用戶依靠自己的力量獨(dú)立完成系統(tǒng)開發(fā)的各項(xiàng)任務(wù)。

自行開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/注意/比較/返回第三十二頁，共一百一十一頁，編輯于2023年，星期一

適合

有較強(qiáng)專業(yè)開發(fā)分析與設(shè)計(jì)隊(duì)伍和程序設(shè)計(jì)人員系統(tǒng)維護(hù)使用隊(duì)伍的組織和單位如：大學(xué)、研究所、計(jì)算機(jī)公司、高科技公司等單位。

自行開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/注意/比較/返回第三十三頁，共一百一十一頁，編輯于2023年，星期一優(yōu)點(diǎn)

開發(fā)費(fèi)用少,容易開發(fā)出適合本單位需要的系統(tǒng),方便維護(hù)和擴(kuò)展,有利于培養(yǎng)自己的系統(tǒng)開發(fā)人員。

自行開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/注意/比較/返回第三十四頁，共一百一十一頁，編輯于2023年，星期一缺點(diǎn)

(1)容易受業(yè)務(wù)工作的限制，系統(tǒng)整體優(yōu)化不夠，開發(fā)水平較低。

(2)系統(tǒng)開發(fā)時(shí)間長，開發(fā)人員調(diào)動后，系統(tǒng)維護(hù)工作沒有保障。

自行開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/注意/比較/返回第三十五頁，共一百一十一頁，編輯于2023年，星期一注意（1）需要大力加強(qiáng)領(lǐng)導(dǎo)，實(shí)行“一把手”原則；（2）向?qū)I(yè)開發(fā)人士或公司進(jìn)行必要的技術(shù)咨詢，或聘請他們作為開發(fā)顧問。

自行開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/注意/比較/返回

第三十六頁，共一百一十一頁，編輯于2023年，星期一3.2.2委托開發(fā)

——由使用單位(甲方)委托通常是有豐富開發(fā)經(jīng)驗(yàn)的機(jī)構(gòu)或?qū)I(yè)開發(fā)人員(乙方),按照用戶的需求承擔(dān)系統(tǒng)開發(fā)的任務(wù)。

委托開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/注意/比較/返回第三十七頁，共一百一十一頁，編輯于2023年，星期一適合

使用單位(甲方)沒有MIS的系統(tǒng)分析、系統(tǒng)設(shè)計(jì)及軟件開發(fā)人員或開發(fā)隊(duì)伍力量較弱、但資金較為充足的單位。

委托開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/注意/比較/返回

第三十八頁，共一百一十一頁，編輯于2023年，星期一優(yōu)點(diǎn)

省時(shí)、省事，開發(fā)的系統(tǒng)技術(shù)水平較高。

委托開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/注意/比較/返回第三十九頁，共一百一十一頁，編輯于2023年，星期一缺點(diǎn)費(fèi)用高、系統(tǒng)維護(hù)與擴(kuò)展需要開發(fā)單位的長期支持，不利于本單位的人才培養(yǎng)。

委托開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/注意/比較/返回第四十頁，共一百一十一頁，編輯于2023年，星期一注意

⑴使用單位(甲方)的業(yè)務(wù)骨干要參與系統(tǒng)的論證工作；⑵開發(fā)過程中需要開發(fā)單位(乙方)和使用單位(甲方)雙方及時(shí)溝通，進(jìn)行協(xié)調(diào)和檢查。

委托開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/注意/比較/返回第四十一頁，共一百一十一頁，編輯于2023年，星期一3.2.3合作開發(fā)——由使用單位(甲方)和有豐富開發(fā)經(jīng)驗(yàn)的機(jī)構(gòu)或?qū)I(yè)開發(fā)人員(乙方),共同完成開發(fā)任務(wù)。雙方共享開發(fā)成果,實(shí)際上是一種半委托性質(zhì)的開發(fā)工作。

合作開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/比較/返回第四十二頁，共一百一十一頁，編輯于2023年，星期一適合

使用單位(甲方)有一定的MIS分析、設(shè)計(jì)及軟件開發(fā)人員，但開發(fā)隊(duì)伍力量較弱，希望通過MIS的開發(fā)建立、完善和提高自己的技術(shù)隊(duì)伍，便于系統(tǒng)維護(hù)工作的單位。

合作開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/比較/返回第四十三頁，共一百一十一頁，編輯于2023年，星期一優(yōu)點(diǎn)

相對于委托開發(fā)方式比較節(jié)約資金,可以培養(yǎng)、增強(qiáng)使用單位的技術(shù)力量,便于系統(tǒng)維護(hù)工作,系統(tǒng)的技術(shù)水平較高。

合作開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/比較/返回

第四十四頁，共一百一十一頁，編輯于2023年，星期一缺點(diǎn)

雙方在合作中溝通易出現(xiàn)問題,因此,需要雙方及時(shí)達(dá)成共識,進(jìn)行協(xié)調(diào)和檢查。

合作開發(fā)/適合/優(yōu)點(diǎn)/缺點(diǎn)/比較/返回

第四十五頁，共一百一十一頁，編輯于2023年，星期一3.2.4利用現(xiàn)成軟件包開發(fā)

——利用現(xiàn)成的軟件包開發(fā)MIS，可購買現(xiàn)成的應(yīng)用軟件包或開發(fā)平臺,如財(cái)務(wù)管理系統(tǒng)、小型企業(yè)MIS、供銷存MIS等等。

包開發(fā)/軟件包/適合/優(yōu)點(diǎn)/缺點(diǎn)/比較/返回第四十六頁，共一百一十一頁，編輯于2023年，星期一應(yīng)用軟件包

是預(yù)先編制好的、能完成一定功能的、供出售或出租的成套軟件系統(tǒng)。它可以小到只有一項(xiàng)單一的功能，比如打印郵簽，也可以是有50萬行代碼的、400多個(gè)模塊組成的復(fù)雜的運(yùn)行在主機(jī)上的大系統(tǒng)。

包開發(fā)/軟件包/適合/優(yōu)點(diǎn)/缺點(diǎn)/比較/返回第四十七頁，共一百一十一頁，編輯于2023年，星期一適合

對于功能單一的小系統(tǒng)開發(fā)頗為有效。但不太適用于規(guī)模較大、功能復(fù)雜、需求量的不確定性程度比較高的系統(tǒng)的開發(fā)。

包開發(fā)/軟件包/適合/優(yōu)點(diǎn)/缺點(diǎn)/比較/返回

第四十八頁，共一百一十一頁，編輯于2023年，星期一優(yōu)點(diǎn)

能縮短開發(fā)時(shí)間,節(jié)省開發(fā)費(fèi)用,技術(shù)水平比較高,系統(tǒng)可以得到較好的維護(hù)。

包開發(fā)/軟件包/適合/優(yōu)點(diǎn)/缺點(diǎn)/比較/返回第四十九頁，共一百一十一頁，編輯于2023年，星期一缺點(diǎn)

功能比較簡單,通用軟件的專用性比較差,難以滿足特殊要求,需要有一定的技術(shù)力量根據(jù)使用者的要求做軟件改善和編制必要的接口軟件等二次開發(fā)的工作。

包開發(fā)/軟件包/適合/優(yōu)點(diǎn)/缺點(diǎn)/比較/返回第五十頁，共一百一十一頁，編輯于2023年，星期一表3.1

開發(fā)方式的比較

自行開發(fā)/委托開發(fā)/合作開發(fā)/軟件包開發(fā)/返回

方式特點(diǎn)比較自行開發(fā)委托開發(fā)合作開發(fā)利用現(xiàn)成軟件包開發(fā)分析和設(shè)計(jì)能力的要求較高一般逐漸培養(yǎng)較低編程能力的要求較高不需要需要較低系統(tǒng)維護(hù)的要求容易較困難較容易較困難開發(fā)費(fèi)用少多較少較少第五十一頁，共一百一十一頁，編輯于2023年，星期一3.3結(jié)構(gòu)化系統(tǒng)開發(fā)方法3.3.1結(jié)構(gòu)化開發(fā)方法的基本思想3.3.2結(jié)構(gòu)化開發(fā)方法的特點(diǎn)3.3.3系統(tǒng)開發(fā)的生命周期3.3.4結(jié)構(gòu)化生命周期法的優(yōu)缺點(diǎn)

返回第五十二頁，共一百一十一頁，編輯于2023年，星期一3.3.1

結(jié)構(gòu)化開發(fā)方法基本思想自頂向下逐層解決結(jié)構(gòu)化的分析描述方式

返回

第五十三頁，共一百一十一頁，編輯于2023年，星期一3.3.2結(jié)構(gòu)化開發(fā)方法基本特點(diǎn)自頂向下設(shè)計(jì)，自底向下開發(fā)用戶至上深入調(diào)查研究嚴(yán)格區(qū)分工作階段預(yù)料發(fā)生的變化開發(fā)過程工程化

返回

第五十四頁，共一百一十一頁，編輯于2023年，星期一3.3.3

系統(tǒng)開發(fā)生命周期

生命周期

基本思想

圖3-2MIS的生命周期

返回

第五十五頁，共一百一十一頁，編輯于2023年，星期一生命周期

從提出要建立一個(gè)MIS開始,到完全建成的全過程,是一個(gè)連續(xù)發(fā)展的過程,即一個(gè)階段的完成就是下一個(gè)階段的開始,這個(gè)過程稱為系統(tǒng)的開發(fā)生命周期(SystemDevelopmentLifeCycle,簡稱SDLC)。

返回

第五十六頁，共一百一十一頁，編輯于2023年，星期一基本思想

返回

將系統(tǒng)的生命周期劃分為:系統(tǒng)規(guī)劃、系統(tǒng)分析、系統(tǒng)設(shè)計(jì)、系統(tǒng)實(shí)施、系統(tǒng)運(yùn)行和維護(hù)等階段。應(yīng)用系統(tǒng)工程的方法,按照規(guī)定的步驟和任務(wù)要求,使用一定的圖表工具完成規(guī)定的文檔,在結(jié)構(gòu)化和模塊化的基礎(chǔ)上進(jìn)行MIS的開發(fā)工作。

第五十七頁，共一百一十一頁，編輯于2023年，星期一3.3.2結(jié)構(gòu)化生命周期法的主要工作1.

系統(tǒng)規(guī)劃階段2.

系統(tǒng)分析階段3.

系統(tǒng)設(shè)計(jì)階段4.

系統(tǒng)實(shí)施階段5.

系統(tǒng)運(yùn)行和維護(hù)階段圖2-3生命周期法的開發(fā)過程

返回第五十八頁，共一百一十一頁，編輯于2023年，星期一1.系統(tǒng)規(guī)劃階段

對企業(yè)的環(huán)境、目標(biāo)、現(xiàn)行系統(tǒng)的狀況進(jìn)行初步調(diào)查，根據(jù)企業(yè)目標(biāo)和發(fā)展戰(zhàn)略，確定MIS的發(fā)展戰(zhàn)略，對建設(shè)新系統(tǒng)的需求做出分析和預(yù)測，同時(shí)考慮建設(shè)新系統(tǒng)所受的各種約束，研究建設(shè)新系統(tǒng)的必要性和可行性。輸出：可行性分析報(bào)告、系統(tǒng)設(shè)計(jì)任務(wù)書

返回第五十九頁，共一百一十一頁，編輯于2023年，星期一2.系統(tǒng)分析階段

——邏輯設(shè)計(jì)階段

根據(jù)系統(tǒng)任務(wù)書所確定的范圍，對現(xiàn)行系統(tǒng)進(jìn)行詳細(xì)調(diào)查，描述現(xiàn)行系統(tǒng)的業(yè)務(wù)流程，指出現(xiàn)行系統(tǒng)的局限性和不足之處，確定新系統(tǒng)的基本目標(biāo)和邏輯功能要求，即提出新系統(tǒng)的邏輯模型。輸出：系統(tǒng)分析報(bào)告

返回第六十頁，共一百一十一頁，編輯于2023年，星期一3.

系統(tǒng)設(shè)計(jì)階段

——物理設(shè)計(jì)階段

根據(jù)系統(tǒng)分析報(bào)告中規(guī)定的功能要求，考慮實(shí)際條件，具體設(shè)計(jì)實(shí)現(xiàn)邏輯模型的技術(shù)方案即設(shè)計(jì)新系統(tǒng)的物理模型。

總體設(shè)計(jì)物理設(shè)計(jì)階段

詳細(xì)設(shè)計(jì)

輸出：系統(tǒng)設(shè)計(jì)說明書

返回

第六十一頁，共一百一十一頁，編輯于2023年，星期一4.

系統(tǒng)實(shí)施階段

將設(shè)計(jì)的系統(tǒng)付諸實(shí)施。購置、安裝、調(diào)試計(jì)算機(jī)等設(shè)備，編寫程序，調(diào)試程序，人員培訓(xùn)，數(shù)據(jù)文件轉(zhuǎn)換，系統(tǒng)調(diào)試，系統(tǒng)轉(zhuǎn)換。

返回第六十二頁，共一百一十一頁，編輯于2023年，星期一5.

系統(tǒng)運(yùn)行和維護(hù)階段

記錄系統(tǒng)的運(yùn)行情況，根據(jù)一定的規(guī)格對系統(tǒng)進(jìn)行必要的修改，評價(jià)系統(tǒng)的工作質(zhì)量和經(jīng)濟(jì)效益。

下頁第六十三頁，共一百一十一頁，編輯于2023年，星期一圖3—3生命周期法的開發(fā)過程

生命周期/規(guī)劃/分析/設(shè)計(jì)/實(shí)施/返回提出要求初步調(diào)查可行性研究可行性分析報(bào)告審批修改目標(biāo)、追加資源、等待條件A停止研制否修改是請按鍵★第六十四頁，共一百一十一頁，編輯于2023年，星期一圖4—3生命周期法的開發(fā)過程

生命周期/規(guī)劃/分析/設(shè)計(jì)/實(shí)施/返回A詳細(xì)調(diào)查邏輯設(shè)計(jì)系統(tǒng)分析報(bào)告審批B修改說明書停止研制否修改是請按鍵★第六十五頁，共一百一十一頁，編輯于2023年，星期一圖3—3生命周期法的開發(fā)過程

生命周期/規(guī)劃/分析/設(shè)計(jì)/實(shí)施/返回B總體設(shè)計(jì)詳細(xì)設(shè)計(jì)系統(tǒng)設(shè)計(jì)說明書審批停止研制修改設(shè)計(jì)方案C否修改是請按鍵★第六十六頁，共一百一十一頁，編輯于2023年，星期一圖3—3生命周期法的開發(fā)過程

生命周期/規(guī)劃/分析/設(shè)計(jì)/實(shí)施/返回C系統(tǒng)實(shí)施調(diào)試修改系統(tǒng)驗(yàn)收交付使用是修改請按鍵★第六十七頁，共一百一十一頁，編輯于2023年，星期一3.3.4

結(jié)構(gòu)化生命周期法的優(yōu)缺點(diǎn)優(yōu)點(diǎn)：從系統(tǒng)整體出發(fā)，強(qiáng)調(diào)在整體優(yōu)化的條件下“自上而下”地分析和設(shè)計(jì)，保證了系統(tǒng)的整體性和目標(biāo)的一致性；遵循用戶至上原則；嚴(yán)格區(qū)分系統(tǒng)開發(fā)的階段性；每一階段的工作成果是下一階段的依據(jù)，便于系統(tǒng)開發(fā)的管理和控制；文檔規(guī)范化，按工程標(biāo)準(zhǔn)建立標(biāo)準(zhǔn)化的文檔資料。

返回第六十八頁，共一百一十一頁，編輯于2023年，星期一3.3.4

結(jié)構(gòu)化生命周期法的優(yōu)缺點(diǎn)缺點(diǎn)：1.用戶介入系統(tǒng)開發(fā)的深度不夠，系統(tǒng)需求難以確定(原因)；2.開發(fā)周期長，文檔過多；3.各階段文檔的審批工作困難。

返回第六十九頁，共一百一十一頁，編輯于2023年，星期一3.4原型法3.4.1

原型法基本原理3.4.2原型的種類及構(gòu)造方法3.4.3

原型法開發(fā)過程3.4.4

原型法的優(yōu)點(diǎn)及存在的問題

返回第七十頁，共一百一十一頁，編輯于2023年，星期一3.4.1原型法基本原理

原型：可以逐步改進(jìn)成運(yùn)行系統(tǒng)的模型開發(fā)者在初步了解用戶需求的基礎(chǔ)上，構(gòu)成、設(shè)計(jì)和開發(fā)一個(gè)系統(tǒng)初始模型，該模型稱為原型或骨架。(一個(gè)可以實(shí)現(xiàn)的系統(tǒng)應(yīng)用模型。)

開發(fā)人員和用戶在此基礎(chǔ)上共同探討、改進(jìn)和完善方案，開發(fā)人員再根據(jù)方案對原型進(jìn)行修改得到新的原型，再征求用戶意見，如此反復(fù)，直至用戶滿意為止。

返回第七十一頁，共一百一十一頁，編輯于2023年，星期一3.4.2原型法運(yùn)用方式1.

探索型2.

實(shí)驗(yàn)型3.

演化型

示意圖/返回第七十二頁，共一百一十一頁，編輯于2023年，星期一3.4.3原型法開發(fā)過程1.

確定用戶的基本需求2.

開發(fā)初始原型系統(tǒng)3.

對原型進(jìn)行評價(jià)4.

修正和改進(jìn)原型系統(tǒng)(循環(huán)、不斷修改完善)

示意圖/返回第七十三頁，共一百一十一頁，編輯于2023年，星期一

返回原型法開發(fā)MIS的過程示意圖確定用戶基本要求構(gòu)造初始模型評價(jià)、使用系統(tǒng)原型用戶滿意？系統(tǒng)轉(zhuǎn)換、系統(tǒng)維護(hù)與評價(jià)修改、完善系統(tǒng)原型圖3—4原型法開發(fā)過程YN請按鍵★第七十四頁，共一百一十一頁，編輯于2023年，星期一3.4.4

原型法的優(yōu)點(diǎn)及存在的問題1.

原型法的優(yōu)點(diǎn)2.

原型法的缺點(diǎn)

返回第七十五頁，共一百一十一頁，編輯于2023年，星期一1.

原型法的優(yōu)點(diǎn)⑴開發(fā)周期短⑵增加用戶的滿意度⑶加強(qiáng)了開發(fā)過程中的用戶參與程度⑷降低系統(tǒng)開發(fā)中的風(fēng)險(xiǎn)⑸降低系統(tǒng)開發(fā)的成本⑹易學(xué)易用，減少對用戶的培訓(xùn)時(shí)間⑺可產(chǎn)生正確的系統(tǒng)需求描述

返回請按鍵★第七十六頁，共一百一十一頁，編輯于2023年，星期一2.

原型法的缺點(diǎn)

⑴對于大系統(tǒng)，復(fù)雜系統(tǒng)，不適于直接使用；

⑵開發(fā)過程管理困難；

⑶用戶較早看到原型，錯認(rèn)為就是新系統(tǒng)，使用戶缺乏耐心；

⑷開發(fā)人員很容易用原型取代系統(tǒng)分析。

請按鍵★返回第七十七頁，共一百一十一頁，編輯于2023年，星期一原型法與傳統(tǒng)的生命周期法的比較1.原型法的特點(diǎn)2.原型法與生命周期法的比較(表1)

返回第七十八頁，共一百一十一頁，編輯于2023年，星期一1.原型法的特點(diǎn)⑴開發(fā)過程是一個(gè)循環(huán)往復(fù)的反饋過程⑵將模擬的手段引入系統(tǒng)分析的初期階段返回第七十九頁，共一百一十一頁，編輯于2023年，星期一2.原型法與生命周期法的比較(表—1）

方法內(nèi)容

原型法生命周期法開發(fā)路徑循環(huán)、迭代型嚴(yán)格、順序型文檔數(shù)量較少多用戶參與程度高低開發(fā)過程的可見度好差對功能需求或環(huán)境變化的適應(yīng)性較好差用戶的信息反饋早遲對開發(fā)環(huán)境、軟件工具的要求高低對開發(fā)過程的管理和控制較困難較容易返回第八十頁，共一百一十一頁，編輯于2023年，星期一3.5

面向?qū)ο蟮姆椒?.5.1

面向?qū)ο蠓椒ê喗?.5.2

面向?qū)ο箝_發(fā)方法基本思想3.5.3

以對象為主題的面向?qū)ο蠓椒?.5.4面向?qū)ο蠓椒ǖ拈_發(fā)過程

返回第八十一頁，共一百一十一頁，編輯于2023年，星期一3.5.1面向?qū)ο蠓椒ê喗?/p>

1.世界的一切都是對象2.相似的對象劃分成為類3

子類和父類等層次結(jié)構(gòu)關(guān)系4對象之間通過消息相互聯(lián)系

返回第八十二頁，共一百一十一頁，編輯于2023年，星期一3.5.2面向?qū)ο蠓椒ɑ魉枷?/p>

1.

基本概念2.面向?qū)ο蟮奶卣?/p>

返回第八十三頁，共一百一十一頁，編輯于2023年，星期一1.

基本概念⑴對象⑵類⑶消息⑷繼承

返回第八十四頁，共一百一十一頁，編輯于2023年，星期一⑴對象對象＝數(shù)據(jù)＋操作

對象／類／消息／繼承／返回

——客觀現(xiàn)實(shí)世界中（問題空間）的任何事物。計(jì)算機(jī)（求解空間）所創(chuàng)建的對象就是對客觀事物進(jìn)行表達(dá)和模擬的一種數(shù)據(jù)模型，包括形狀數(shù)據(jù)和行為特征的數(shù)據(jù)模型。即一個(gè)對象與一個(gè)客觀實(shí)體相對應(yīng)，由實(shí)體抽象的形狀數(shù)據(jù)和對此數(shù)據(jù)進(jìn)行的各種操作一起封裝構(gòu)成一種數(shù)據(jù)和操作包體。(學(xué)生例子)第八十五頁，共一百一十一頁，編輯于2023年，星期一⑵類——具有相同屬性（數(shù)據(jù)和操作）對象的集合的描述或定義。是一組具有相同模板或子模板對象類型的抽象和說明。模板（子）表示對象集合中每個(gè)對象所具有的數(shù)據(jù)和操作。

對象／類／消息／繼承／返回第八十六頁，共一百一十一頁，編輯于2023年，星期一⑶消息

對象之間相互作用和相互協(xié)作的一種機(jī)制。對象之間的相互操作、調(diào)用和應(yīng)答多是通過發(fā)送消息到對象的外部接口來實(shí)施的。消息是為完成某些操作而向?qū)ο笏l(fā)送的命令和命令說明。

對象／類／消息／繼承／返回第八十七頁，共一百一十一頁，編輯于2023年，星期一⑷繼承

相關(guān)對象類層次之間的一種數(shù)據(jù)和操作（程序代碼）的共享機(jī)制。如果類Ｂ繼承了類Ａ，則在Ａ中所定義的數(shù)據(jù)和操作也將成為Ｂ的組成部分。

對象／類／消息／繼承／返回第八十八頁，共一百一十一頁，編輯于2023年，星期一3.5.3.

以對象為主體的面向?qū)ο蠓椒?/p>

⑴封裝性

⑵繼承性

⑶多態(tài)型

⑷可維護(hù)性

返回第八十九頁，共一百一十一頁，編輯于2023年，星期一⑴封裝性

將自由數(shù)據(jù)與操作(方法)封閉在一起(即放于同個(gè)對象中)使自身的狀態(tài)、行為局部化(對數(shù)據(jù)的操作只通過該對象本身的方法來進(jìn)行)。

封裝／繼承／多態(tài)／可維護(hù)／返回第九十頁，共一百一十一頁，編輯于2023年，星期一⑵繼承性

通過對類繼承可以彌補(bǔ)由封裝對象而帶來的諸如數(shù)據(jù)或操作冗余的問題。通過繼承支持重用，實(shí)現(xiàn)軟件資源共享、演化以及增強(qiáng)擴(kuò)充。

封裝／繼承／多態(tài)／可維護(hù)／返回

第九十一頁，共一百一十一頁，編輯于2023年，星期一⑶多態(tài)型

同樣的消息為不同的對象接受后，會因不同對象所含操作的不同，而導(dǎo)致完全不同的行動，使軟件開發(fā)設(shè)計(jì)更便利，編碼更靈活。

封裝／繼承／多態(tài)／可維護(hù)／返回

第九十二頁，共一百一十一頁，編輯于2023年，星期一⑷可維護(hù)性

由于面向?qū)ο蟮某橄蠓庋b使對象信息隱藏在局部，當(dāng)對象進(jìn)行修改，或?qū)ο笞陨懋a(chǎn)生錯誤的時(shí)候，由此帶來的影響僅僅在對象內(nèi)部而不會波及其他對象乃至整個(gè)系統(tǒng)環(huán)境，極大方便了軟件設(shè)計(jì)、構(gòu)造和運(yùn)行過程中的檢錯、修改。

封裝／繼承／多態(tài)／可維護(hù)／返回第九十三頁，共一百一十一頁，編輯于2023年，星期一3.5.2

面向?qū)ο箝_發(fā)方法的特征及優(yōu)點(diǎn)1.

面向?qū)ο箝_發(fā)方法