第十章资讯系统开发与管理.pptVIP

第十章 資訊系統開發與管理 治國之有法術賞罰，猶若陸行之有犀車良馬也，水行之有輕舟便輯也。 -- 韓非子 (B.C.280 – B.C. 233) There is no security on earth. There is only opportunity. (地球上沒有安全，只有機會) -- 麥克阿瑟將軍 綱要 一、企業內的企業 二、資訊系統開發 三、資訊系統經濟評估 (略) 四、資訊系統規劃 (略) 五、生命週期(SDLC)資訊系統開發方法 六、雛型開發方法 七、套裝軟體與企業資源規劃 八、資訊系統專案管理 (略) 九、使用者自建系統 十、資訊系統委外 十一、應用服務提供 (略) 十二、網路服務架構 (略) 十三、資訊系統建置 十四、資訊部門組織與地位 (略) 十五、資訊安全與控制 (略) 十六、資訊系統的評估與失敗的原因 一、企業內的企業 1980年代，資訊部門被稱為企業內的企業(a business in a business) 企業的功能: 生產、行銷、會計、財務、人力資源、研究發展、策略管理。 資訊部門: 生產作業的資訊、成本及計價(會計)的資訊、IT投資與效益分析(財務管理)。 1990年代，資訊科技或處理方式變化， 例如: 使用者自建系統、分散式處理、委外開發或處理。 資訊部門的界限模糊: 其功能分散到企業內各部門或企業外的委外公司。 資訊科技的應用不一定要跟著潮流走。 先入者優勢(first mover’s advantage )不是永遠是對的。 企業要評估自己的策略、規模、結構、文化、能力、技術、財務、外在的競爭，選擇適合的資訊科技應用。 二、資訊系統開發 五、生命週期資訊系統開發方法 生命週期法(System Development Life Cycle, SDLC)是開發資訊系統的傳統方法，又稱為瀑布模式(waterfall model)。 包括: 系統規劃、系統分析、系統設計、程式設計、系統測試、系統建置等階段，序列式進行，每個階段有其標準程序和文件。 修改資訊需求規格，按規定填寫變更需求申請單(change request)。 使用者在系統設計階段以後，資訊需求的變更就比較困難。 系統分析與設計 一般系統分析的本質: 調查整個系統問題的內涵，研究系統的目標、系統效果的標準，並且評估各方案的效果與成本。 系統分析可以應用於資訊系統的開發建立: 定義其成分及整體性的考量。 定義資訊處理子系統，說明邊界及介面。 系統的模式、回饋與控制功能。 開發計畫的時程，控制、監督開發過程。 指定專案主持人，負責劃分子系統、控制時間、成本、品質。 (一) 結構化分析與設計 由上而下(top-down)定義子系統。 階層式: 每個階層子系統之間的介面要清楚定義。 模組化: 邊界與介面都定義了，可以應用黑箱(black box)的觀念: 在高階層的設計中，可以將低階層的子系統視為黑箱。 例如: 訂單處理系統，信用檢查是它的子系統， 先將信用檢查當作黑箱，不定義如何檢查信用，只定義它的投入與產出(input and output)，訂單處理系統就可以繼續分析。 細部設計時，才根據投入與產出，定義信用檢查子系統。 減小聯繫力(coupling): 使各子系統愈獨立愈好。 將系統可能改變的影響，可以單獨處理，增進系統的適應性。 越容易修改一個子系統，而不影響其他的子系統。 (二) 物件導向分析與設計 物件(object)是系統中特定實體(entity)或有意義的概念 本身存有一組資訊來表示物件的現況(屬性、狀態) 擁有一組屬於該物件的行為(活動或操作)，可以改變此物件的現況。 物件導向(object-oriented)程式設計是近年來程式設計的新觀念， 站在人性化(使用者)的觀點，思考程式的邏輯。 將所需要的程式碼與資料放在一起，形成一個物件。 汽車物件: 屬性: 車型、排氣量、廠牌、汽缸數、顏色。 行為: 發動、開車門、開冷氣。 物件導向程式語言 80年代: Smalltalk 90年代: C++, Java 物件導向的基本法則 封裝(encapsulation): 物件 = 屬性 + 行為 所有物件的操作方式及介面，均定義在行為的部分。 撰寫程式時，可以利用黑箱的概念，輕鬆連結不同物件。 繼承(inheritance): 新的物件可以繼承原有的物件，修改增加新特性，適合新的應用程式。 多型(polymorphism): 同一名稱，可以因物件不同，賦予不同的意義。 例如: 令食物(food)物件具備計算所含熱量(calorie)的功能，不同的食物類別(class)可以有不同計算方式。 可以利用繼承關係，定義不同的計算所含熱量的功能。 六、雛型開發方法 雛型開發方法(prototyping)，或稱為快速應用設計(