1 / 76

PART 4 系統開發與社會性議題 Chapter 8 系統開發

PART 4 系統開發與社會性議題 Chapter 8 系統開發. 原則與學習目標. 有效的系統開發需要利害關係人、使用者、經理人、系統開發專員與各種支援人員的團隊努力,而且要從仔細規劃開始 系統開發通常可以選擇不同的方法與工具,像是傳統開發、建立原型、快速應用開發、最終使用者開發、電腦輔助軟體工程與物件導向開發方法,進行專案的實作與監視. 原則與學習目標 ( 續 ). 系統開發從調查與分析現有系統開始 不管是設計新系統,或是修改現有的系統,目標都是要協助組織達成使命

rance
Download Presentation

PART 4 系統開發與社會性議題 Chapter 8 系統開發

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. PART 4 系統開發與社會性議題 Chapter 8 系統開發

  2. 原則與學習目標 • 有效的系統開發需要利害關係人、使用者、經理人、系統開發專員與各種支援人員的團隊努力,而且要從仔細規劃開始 • 系統開發通常可以選擇不同的方法與工具,像是傳統開發、建立原型、快速應用開發、最終使用者開發、電腦輔助軟體工程與物件導向開發方法,進行專案的實作與監視

  3. 原則與學習目標(續) • 系統開發從調查與分析現有系統開始 • 不管是設計新系統,或是修改現有的系統,目標都是要協助組織達成使命 • 維護與檢討可以增加系統的使用壽命,但可能消耗大量的資源,因此可以套用系統開發中,使用的嚴格方法與專案管理技術

  4. 原則與學習目標(續) • 系統實作的主要重點是確保在正確的時間,以正確的格式,將正確的資訊,提供給正確的人員 • 辨識系統開發過程中的主要參與者,並討論他們的角色 • 定義資訊系統規劃,並討論專案規劃的重要性

  5. 原則與學習目標(續) • 討論傳統開發、建立原型、快速應用開發、最終使用者開發生命週期的主要特徵,以及它們的優缺點 • 說明系統調查的作用 • 討論效能與成本目標的重要性 • 說明系統分析的作用,並討論這個階段可以使用的工具與技術

  6. 原則與學習目標(續) • 說明系統設計的作用,並討論邏輯與實體系統設計間的差異 • 定義RFP,並討論如何使用這份文件取得硬體與軟體 • 說明系統實作的作用,並討論這個階段中相關的活動 • 說明系統與軟體維護的重要性,並討論它所涉及的活動 • 描述系統檢討的流程

  7. 簡介 • 如何啟動系統開發的流程,以及在資訊人員的協助下分析需求 • 如何規劃專案,配合企業的目標,快速地開發系統,以及其他的內容

  8. 系統開發簡介 • 在今天的企業中,經理人與員工在所有的功能領域中合作,並使用企業資訊系統 • 使用者需要協助開發的工作,在許多案例中,甚至居於領導的地位 • 系統開發的參與者,可以決定系統開發專案失敗的時機,對系統開發的成功也佔有重要的地位 管理資訊系統概論, chapter8 , 頁433

  9. 系統開發的參與者 • 開發團隊由利害關係人、使用者、經理人、系統開發專員與各種支援人員所組成 • 專案經理負責協調所有的人員與資源,以期準時完成專案的目標 • 利害關係人指的是會從系統開發專案獲利的人員 • 使用者指的是定期與系統互動的人員 管理資訊系統概論, chapter8 , 頁433

  10. 系統開發的參與者(續) • 系統分析人員指的是以分析與設計企業系統見長的專業人士 • 程式設計人員負責修改或開發程式,來滿足使用者的需求 管理資訊系統概論, chapter8 , 頁433

  11. 資訊系統的規劃及配合企業的目標 • 資訊系統規劃指的是將策略與組織目標,轉換為系統開發活動的過程 • 對任何成功的系統開發工作來說,配合組織目標與資訊系統目標都是相當重要的 • 組織目標與資訊系統目標的配合程度很難判斷 管理資訊系統概論, chapter8 , 頁435

  12. 圖8.2 資訊系統規劃 策略計畫 資訊系統規劃 系統開發活動 管理資訊系統概論, chapter8 , 頁435

  13. 系統開發的生命週期 • 系統開發流程也稱為系統開發生命週期(SDLC) • 常見的系統開發生命週期包括:傳統、建立原型、快速應用開發、與最終使用者開發等方法 管理資訊系統概論, chapter8 , 頁437

  14. 系統調查 了解問題 圖8.3 傳統的系統開發生命週期 系統分析 認識解決方案 系統設計 選擇與規劃最佳的解決方案 系統實作 讓解決方案上線使用 系統維護與檢討 評估解決方案的結果 管理資訊系統概論, chapter8 , 頁437

  15. 傳統的系統開發生命週期 • 在系統調查階段中,會從企業目標的觀點,辨識及考慮潛在的問題與機會 • 系統分析階段涉及研究現有的系統與工作流程,找出優勢、弱點、以及可以改善的機會 • 系統設計階段的主要結果是技術性的設計,描述的可能是新系統的設計內容,或是現有系統的修改方式 管理資訊系統概論, chapter8 , 頁438

  16. 傳統的系統開發生命週期(續) • 系統實作涉及建立或取得設計文件中載明的各種系統元件,將它們組裝起來,然後讓新的或修改後的系統上線使用 • 系統維護與檢討的作用,是確保系統能正常運行,以及對系統進行必要的修改,讓它能繼續滿足不斷改變的企業需求 管理資訊系統概論, chapter8 , 頁438

  17. 反覆作業1 圖8.4 原型法 決定需求 反覆作業2 (最後) 反覆作業3 分析替代方案 決定需求 決定需求 分析替代方案 指定設計 分析替代方案 實作設計 指定設計 指定設計 實作設計 使用者審查 實作設計 使用者審查 使用者審查 管理資訊系統概論, chapter8 , 頁439

  18. 快速應用開發、敏捷式開發、聯合應用開發與其他的系統開發方法快速應用開發、敏捷式開發、聯合應用開發與其他的系統開發方法 • 快速應用開發(RAD)所採用的工具、技術與方法論,都是為了加速應用程式的開發所設計的 • RAD可以減少書面的文件,自動產生程式的原始碼,並讓使用者參與設計與開發的活動 • 其他的快速開發方法,像是敏捷式開發或極致軟體製程(XP),都可以在系統開發的過程中,對它們進行修改 管理資訊系統概論, chapter8 , 頁440

  19. 快速應用開發、敏捷式開發、聯合應用開發與其他的系統開發方法(續)快速應用開發、敏捷式開發、聯合應用開發與其他的系統開發方法(續) • 敏捷式開發要求經常與系統開發人員和使用者面對面開會,因為他們需要修改、調整與測試系統滿足使用者需求的程度,以及系統應該具備的功能 • XP以兩名程式設計人員為一個單位,共同設計、測試與撰寫他們所開發的系統部份 • XP擁有反覆作業的本質,可以協助公司開發出功能強大的系統,而且發生的錯誤也比較少 管理資訊系統概論, chapter8 , 頁440

  20. 快速應用開發、敏捷式開發、聯合應用開發與其他的系統開發方法(續)快速應用開發、敏捷式開發、聯合應用開發與其他的系統開發方法(續) • 聯合應用開發(JAD)這是資料收集與需求分析的流程,其中由使用者、利害關係人與資訊專業人士一起分析現有的系統,提出可行的解決方案,並定義新的或修改系統的需求 • JAD通常使用群組支援系統(GSS),支持正面的群體互動,同時抑制負面的群組行為 管理資訊系統概論, chapter8 , 頁440

  21. 最終使用者系統開發生命週期 • 最終使用者系統開發指的是由企業經理人與使用者承擔主要成果的開發專案 • 資訊人員會藉由提供指導與支援鼓勵他們,提供技術協助,溝通標準,以及分享組織中的「最佳實務」 • 最終使用者開發的系統,可以與現有和即將使用的系統產生互補效果,而不會造成衝突 管理資訊系統概論, chapter8 , 頁441

  22. 委外與隨選運算 • 許多組織聘請外部的顧問公司或電腦公司,由這些以系統開發見長的公司,負責部份或全部的開發與操作活動 • 組織可以將資訊系統的任何層面委外處理,包括:硬體維護與管理、軟體開發、資料庫系統、網路與通訊、網際網路與企業內部網路操作、招募與聘任、以及有關資訊系統程序與規則的開發 管理資訊系統概論, chapter8 , 頁442

  23. 委外與隨選運算(續) • 降低成本、取得最新的技術、精簡人力與人事問題、以及提高技術方面的彈性,都是公司採用委外與隨選運算策略的理由 管理資訊系統概論, chapter8 , 頁442

  24. 電腦輔助軟體工程工具的用途 • 針對系統開發的許多必要性作業,電腦輔助軟體工程(CASE)工具都可以將它們自動化,並鼓勵按照SDLC執行 • 在整個系統開發過程中,注入相當高程度的嚴謹性與標準化色彩 • 如果CASE工具處理的是有關系統開發初期階段的活動,則被稱為前端CASE工具 • 後端CASE工具著重的是系統開發的實作階段,並能自動產生結構化的程式碼 管理資訊系統概論, chapter8 , 頁443

  25. 表8.2 CASE工具的優缺點分析 管理資訊系統概論, chapter8 , 頁444

  26. 物件導向系統開發 • 物件導向系統開發(OOSD)結合系統開發生命週期的邏輯,以及物件導向塑模與程式設計的功能 管理資訊系統概論, chapter8 , 頁444

  27. 物件導向系統開發(續) • 物件導向系統開發通常涉及下列的工作: • 辨識適合OO方法處理的組織潛在問題與機會 • 定義系統使用者需要的種類 • 設計系統 • 撰寫或修改模組 • 由使用者進行評估 • 定期檢討與修改 管理資訊系統概論, chapter8 , 頁445

  28. 系統調查 • 什麼是系統可以解決的主要問題? • 什麼是系統可以提供的機會? • 哪些新的硬體、軟體、資料庫、通訊、人員或程序,可以改善現有的系統,或是新系統所需要的? • 系統會發生哪些潛在的成本(變動與固定)? • 系統存有哪些相關的風險? 管理資訊系統概論, chapter8 , 頁446

  29. 啟動系統調查 • 想要讓資訊部門啟動系統調查的人員,需要填寫系統需求申請表 • 這張表單中包含以下的資訊: • 系統中的問題或機會 • 系統調查的目標 • 提議系統的簡介 • 提議系統的預期成本與效益 管理資訊系統概論, chapter8 , 頁446

  30. 可行性分析 • 可行性分析針對專案的技術、經濟、法律、作業與時間可行性所做的評估 • 技術可行性評估能否順利取得或開發解決問題所需的硬體、軟體與其他系統元件 • 經濟可行性判斷專案在財務上是否合理,以及預期的效益能否抵銷取得它們所需的成本與時間 管理資訊系統概論, chapter8 , 頁447

  31. 可行性分析(續) • 法律可行性判斷法規是否會阻止或限制系統開發專案 • 作業可行性測量專案的成果能否付諸實施 • 時間可行性判斷專案能否在合理的時間範圍內完成 管理資訊系統概論, chapter8 , 頁447

  32. 物件導向的系統調查 • 系統調查過程中可辨識出關鍵性的物件 • 使用案例圖是統一塑模語言(UML)的一部份,圖中的人形圖代表參與者,每個橢圓形的圖示都表示一個事件,稱為使用案例 管理資訊系統概論, chapter8 , 頁448

  33. 圖8.8 小船租賃應用程式的使用案例圖 將小船租給顧客 將新的船隻加 入庫存中 管理資訊系統概論, chapter8 , 頁448

  34. 系統調查報告 • 系統調查階段的主要結果就是系統調查報告 • 這份報告會摘要系統調查的結果,可行性分析的流程,並對後續做法提出建議:繼續進行系統分析,以某種方式修改專案,或將該專案撤銷 • 系統調查報告由高階主管負責審查,通常會組成諮詢委員會或指導委員會,由資深管理人員、資訊部門與其他功能領域的使用者共同組成 管理資訊系統概論, chapter8 , 頁448

  35. 圖8.9 系統調查報告的典型目錄 管理資訊系統概論, chapter8 , 頁449

  36. 系統分析 • 要回答的問題是:「如果要解決這項問題,資訊系統必須提供哪些功能?」 • 分析工作的整體重點是收集現有系統的資料,決定新系統的需求,考慮限制條件內的替代方案,以及調查這些解決方案的可行性 • 系統分析的主要結果是一份系統需求的清單,而且按照優先順序排列 管理資訊系統概論, chapter8 , 頁449

  37. 資料收集 • 辨識資料的來源:包括內部與外部的來源 • 資料收集可能需要用到許多工具與技術,像是訪談、直接觀察與問卷調查 • 結構化訪談事先將問題寫好的訪談 • 非結構化訪談事先不會將問題寫好的訪談 • 直接觀察由分析團隊的一名或多名成員,觀察現有系統的作業狀況 • 當資料來源分散在不同的地理區域時,可以使用問卷調查的方法 管理資訊系統概論, chapter8 , 頁449

  38. 圖8.10 系統分析中的內部與外部資料來源 管理資訊系統概論, chapter8 , 頁450

  39. 資料分析 • 資料分析是對收集到的資料進行處理,讓參與系統分析的開發團隊成員得以使用這些資料 • 資料塑模最常使用實體關係(ER)圖完成:物件、屬性、關聯 • 活動塑模會透過使用資料流程圖來完成 • 資料流程圖(DFD)透過描述資料在各種物件間的流動方式,建立物件、關聯與活動的模型 管理資訊系統概論, chapter8 , 頁451

  40. 圖8.12 資料與活動塑模 管理資訊系統概論, chapter8 , 頁452

  41. 圖8.12 資料與活動塑模(續) 管理資訊系統概論, chapter8 , 頁452

  42. 需求分析 • 需求分析的整體作用是決定使用者、利害關係人與組織的需求 • 需求分析的技術包括: • 直接提問:詢問使用者、利害關係人與其他經理人,有關他們想要的功能,以及對系統的期望 • 關鍵成功因素:經理人與決策人員列出,對他們負責領域成敗的重要因素 管理資訊系統概論, chapter8 , 頁453

  43. 需求分析(續) • IS計劃:會將策略與組織的目標,轉換為系統開發的想法 • 需求分析工具:CASE工具 管理資訊系統概論, chapter8 , 頁453

  44. 圖8.13 將組織的目標轉換為系統的需求 組織的目標與使命 系統的需求 管理資訊系統概論, chapter8 , 頁454

  45. 物件導向的系統分析 • 辨識問題或潛在的機會 • 辨識主要的參與者與收集資料 • 使用類別與一般化/特殊化的階層圖 管理資訊系統概論, chapter8 , 頁454

  46. 圖8.14 一般化/特殊化的階層圖 管理資訊系統概論, chapter8 , 頁455

  47. 系統分析報告 • 系統分析報告應該涵蓋以下的要素: • 從利害關係人的觀點,描述現有系統的優點與弱點 • 使用者/利害關係人對新系統的需求(也稱為功能性需求) • 組織對新系統的需求 • 說明如果要解決這項問題,新的資訊系統應該提供哪些功能 管理資訊系統概論, chapter8 , 頁455

  48. 系統設計 • 要回答的問題是:「資訊系統應該如何解決問題?」 • 系統設計階段的主要結果是技術設計,其中詳述系統的輸出、輸入與使用者介面,指定硬體、軟體、資料庫、通訊、人員與程序,並顯示這些元件的關聯性 • 設計可分為兩個維度:邏輯與實體 • 邏輯設計指的是系統的功能,描述的是系統的功能性需求 • 實體設計指的是完成工作的方式,包括元件間如何合作,以及每個元件要執行的工作 管理資訊系統概論, chapter8 , 頁456

  49. 物件導向的設計 • 在新的或更新的系統中,設計主要的物件與物件的類別 • 考慮問題領域、作業環境與使用者介面 • 考慮為了讓系統正確作業,事件必須以何種順序發生 • 事件順序被稱為情節,可以使用循序圖來表現 管理資訊系統概論, chapter8 , 頁457

  50. 圖8.16 新增Kayak Item情節的循序圖 Kayak Item Create[ ] getID ID Get Date Purchased Data Purchased 管理資訊系統概論, chapter8 , 頁458

More Related