资讯系统开发

資訊系統開發主講人：巫沛倉副教授義守大學工業工程與管理系資訊系統的特性資訊系統的特性垃圾進垃圾出人機配合快速性即時性經濟性動態性整合性資訊系統開發的過程初步設計(preliminarydesign)經濟可行性技術可行性作業可行性系統分析資訊需求組織需求控制需求機器設備需求系統設計根據「系統需求說明」進一步訂出電腦該作些什麼工作，又如何去做，稱為「程式規格」(programspecifications)。人工作業該作些什麼工作，又如何去做，稱為「作業程序規格」(procedurespecifications)。系統設計電腦與人工的作業規格合起，一般稱為「系統規格」(systemscpecifications)。做完系統設計階段工作後，就有一份詳細的「系統規格說明書」或稱「技術設計規範書」。系統發展依照「系統規格」編寫電腦程式與設計人工作業程序。電腦程式是給電腦的工作命令，編寫之後，最重要的是到電腦上試作，此一試作工作稱為「程式測試」。人工作業程序是給人的工作命令，設計好後，也要在組織中試用。要分別編寫「程式說明書」與「人工作業程序手冊」。系統推行此階段是正式啟用電腦資訊系統。當上一階段設計好了電腦程式與人工作業程序之後，必須完成其他一些配合事項，系統才能正式啟用，這些配合事項包括：人員的訓練。檔案轉換。若原企業組織沒有電腦，則要進行機器的選購安裝。資訊系統的生命週期初步設計系統分析系統設計系統發展系統推行五○年至七○年代

資訊系統開發的概念與技術傳統結構化系統設計方法採用資料流程圖(dataflowdiagram,DFD)作為描述整體資料與處理間的關係。採用資料辭典(datadictionary)，用統一格式，以正式定義資料。採用各種工具，以描述處理邏輯。用結構圖(structurechart)定義程式模組。傳統結構化系統設計方法1970年代早期——結構化程式設計結構化程式設計規則由上而下的程式設計Parnas

的資訊隱藏(informationhiding)Dijkstra的抽象程度(levelsofabstraction)Wirth的步進改善(stepwiserefinement)傳統結構化系統設計方法1970年代中期——結構化設計Yourdon/Constantine的結構化設計Jackson的設計方法Warnier-Orr的設計方法傳統結構化系統設計方法1970年代末期——結構化分析與資料庫技術DeMarco的結構化分析Gane與Sarson的分析SADT(structuredanalysisanddesigntechniques)需求設計語言(requirementsdesignlanguage)Codd的第三正常化格式(third-normalform)資料模式(datamodeling)傳統結構化系統設計方法1970年代，許多公司使用結構化方法開發資訊系統的好處：增進規律性可信度和錯誤校正有效運用資源著重在系統開發的初期工作1970年後期，尚有兩種系統開發的新方法亦可說明系統開發初期工作之重要：資料駕馭的設計方法(data-drivendevelopment)——先定義系統所使用的資料，因為它相對於處理邏輯而言，較為穩定不變，然後再定出程式處理邏輯。小組設計會議的誕生，集合使用者、經理人員、資訊專業人員密集會議，以便能夠更迅速地確認新系統的需求和設計。八○年代資訊系統開發的

概念與技術使用4GL之雛型系統設計方法為了讓使用者能界定他們所需的資訊，而產生了一種新的系統設計的作法，就是先行儘快地完成一個雛型系統(prototypesystem)，這個系統的功能並不完整，通常只具備一些主要功能，就開始交給使用者使用。使用後，使用者會不斷地提出改進意見，如此一直反複修改，直到使用者滿意為止。這種作法就叫雛型系統設計方法(prototypingapproach)。使用者自建系統所謂使用者自建系統，即使用者直接親自控制資訊處理活動的各個階段。使用者基本上並不具備電腦技術經驗，透過成熟而友善的各種軟體工具，如4GL，使用者可以運用電腦分析資料、繪圖、查詢、產生報表、或建立簡單的決策支援系統，而不需要資訊專業人員的介入。八○年代的資訊系統開發技術1980年代早期——自動化技術(automatedtechniques)HOS公司的自動化核驗(automaticverification)自動化資料模式(automateddatamodeling)智力型資料模式(intelligentdatamodels)行動圖(actiondiagram)

八○年代的資訊系統開發技術1980年代末期——CASE(computeraidedsoftwareengineering)Martin的資訊工程(informationengineering)系統分析師的圖形工作檯4GL的行動圖編譯器法則基礎的系統(rule-baseedsystem)可自動產生程式碼的問題定義語言八○年代的資訊系統開發技術一個功能較為完整的CASE環境，包含：資訊貯存器系統模式建立及模擬工具系統分析／設計工具程式編寫工具測試及品質保證工具專案管理工具反轉工程工具九○年代資訊系統開發的

概念與技術物件導向技術物件導向技術的興起所謂物件導向，其精神在於強調：通電軟體系統的設計應以物件(object)作為思考的核心，並以物件作為軟體的基本模組單元(module)電腦應用領域的變化軟體工程上的問題物件導向技術物件導向分析與設計：物件的定義物件與物件間的關係．類別(Classification)．組合(Aggregation)．特殊化或一般化(SpecialiationandGeneralization)物件導向分析與設計物件導向技術用物件導向的方法來設計資訊系統，較著名的有下列六種：Booch的物件導向發展(Ojbect-Orienteddevelopment)Rumbaugh

的物件導向模式化技術(Oblect-orientedmodelingtechnique,OMT)Shlaer&Mellor的物件導向方法論物件導向技術Jacobson的物件導向方法論Yourdon的物件導向分析與設計(Oblect-orientedanalysis/object-orienteddesign，OOA/OOD)Martin&Odell的物件導向方法論網際網路應用系統之開發工具強調快速的資訊系統開發方法九○年代強調快速的開發方法，以八○年代的聯合應用系統開發方法(jointapplicationdevelopment,JAD)為核心的快速開發(RapidDevelopment,RD)應運而生。JAD是以使用者為主導，以管理者為核心，再由資訊人員輔導的群體系統開發方法，此法能夠以最的時間開發出高品質的系統，特別適用於開發需求複雜且跨部門的大型系統。大型整合應用系統

九○年代資訊系統開發的另一項特色是整合型套裝軟體的興起。這種整合型套裝軟體隱含了最佳實務(bestpractice)的企業流程，主要程式模組都已完成，只需挑選適合的模組來整合，再加上部份外掛模組即可，因此以系統開發的過程來看，著重在系統推行(implementation)，可以顯著縮短開發時間。資訊系統開發的管理問題資訊系統開發的管理問題如何度量程式設計人員的生產力如何度量系統效益系統開發專業的風險管理EUC管理策略如何度量程式設計員的生產力IBM公司的AllanAlbrecht在1970年代中期，以使用者的觀點，發展了一套度量方式，嚴謹而實用，稱為「機能點分析」(functionpointanalysis)。如何度量程式設計員的生產力依程式的五種功能度量程式複雜度：外部輸入(externalinput)外部輸出(externaloutput)外部查詢(externalinquiry)內部邏輯檔(logicalinternalfiles)外部介面檔(externalinterfacefiles)如何度量程式設計員的生產力度量程式複雜度的14個問項：該程式是否用到資料傳輸(datacommunication)？該程式之資料或功能是否分散？該程式是否要滿足特殊的需求，如回應時間在數秒之內？該程式是否將在一部作業擁擠的電腦上執行，因此程式編寫需要特別考慮？如何度量程式設計員的生產力該程式的異動資料量是否很大？是否有線上資料輸入？該程式是否特別顧慮使用效率？該程式是否有線上更新？該程式是否有複雜的處理？該程式是否考慮可為其他資訊系統借用？如何度量程式設計員的生產力該程式是否有與使用者對話的功能，並強調安裝的便利性？該程式是否要求便於操作？該程式是否會給好幾個電腦中心使用？該程式是否會要求特殊設計，以便於修改？如何度量程式設計員的生產力程式的功能分數(functionpoints)之用途：據以估計程式的行數。據以估計程式編寫所需之時間，可為派工之參考。據以斷定程式設計人員的工作效率。如何衡量系統效益將系統效益用金錢表達使用代理變數發展工作輪廓矩陣系統開發專案的風險管理

一般而言，風險管理要從預估風險做起，先評估該系統開發專案風險的大小，再依不同的風險採用不同的專案管理工具，以期能降低風險。風險的評估專案小組外的整合性專案管理工具：使用者擔任專案經理成立一個使用者推動委員會，作使用單位最高的決策單位和使用者推動委員會經常開會，深入討論由使用者來管理變革控制流程經常而詳細地向關鍵使用者發佈專案消息風險的評估選擇使用者為專案成員採用正式的使用者規範同意程序向公司的推動委員會定期報告由使用者負責教育訓練和系統安裝由使用者主管決定重大的行動日程風險的評估專案小組組內的整合工具：選擇有經驗的IT專業人員領導專案小組專案小組經常開會關鍵性的設計決策要定期知會組員儘量不要更換專案小組成員專案小組成員最好曾經有合作的經驗讓專案小組成員參與決定目標和工作時程向外尋求技術協助風險的評估正式規劃工具：工作評核術(programevaluation&reviewtechniques,PERT)系統規範標準可行性研究規範專案批準程序專案事後審查程序風險的評估正式控制工具：定期的正式狀況報告，

並與計劃情況作比對變革控制之紀律定期進度審查EUC的管理策略推動EUC管理策略的具體作法：必須有一明確的EUC策略。必須明確界定資訊部門和使用者雙方的權責，並鼓