The Design of Expert Systems專家系統設計流程.pptVIP

Expert Systems Expert Systems sstseng 第9章 Outline 本章節提出一整體建立實際專家系統的指引，而不是研究用的雛型系統 為了建立一符合成本效益和有效率的專家系統，我們將討論一些軟體工程的方法論 影響專家系統專案的因素 組織內部的影響 管理單位 決策者 使用單位 教育人事單位 軟體開發部門 組織外部的影響： 客戶 供應商 協力廠商 政府主管機關 建置專家系統專案 (1)工作項目管理 (Activity Management) 規劃 (Planning) 定義工作項目、優先順序 列出資源需求、訂定里程碑 執行過程 責任 排程 (Scheduling) 指定開始及結束時間 解決同樣優先權之工作排程衝突 紀錄 (Chronicling) 監視專案效率 分析 (Analysis) 分析以上相關的工作項目 (2)產品設定管理 (Product configuration management) 產品管理 (Product management) 管理產品之不同版本 變異管理 (Change management) 管理變異規劃及評估影響大小 指定適當人員引發變異 安裝新的產品版本 (3)資源管理 (Resource management) 預測資源需求 擷取需求 指定最佳資源使用效率的回應 提供適當且必要的資源以縮小專案瓶頸 可行性研究 快速雛形設計 商用品質設定—壓力測試 遞送問題 (The Delivery Problem) 應該在早期開發過程中考慮 在標準硬體上執行 最好要考慮花費 考慮與其他程式的通訊和協調 維護與演進 (Maintenance and Evolution) 比傳統程式更複雜 必須要有系統化和有效率的方法從使用者收集問題回報 維護工作: 系統程式碼維護 系統功能維護 資料庫維護 發展階段的錯誤 (Errors in Development Stages) 專家的知識錯誤 語意錯誤 語法錯誤 推論引擎錯誤 推論鏈錯誤 忽略的限制錯誤 – 人類專家了解系統的知識範圍和效能優雅地忽略的邊降低. 資料庫系統與專家系統的關係 傳統軟體專案概念 知識工程概念 專家系統專案與知識工程之間關係概念 部分專家系統軟體品質的評量 給定正確輸入而有正確輸出 給定正確輸入而有完整的輸出 給定相同的輸入而有一致的輸出 穩定，且不會常因為臭蟲而當機 對使用者是合用的且最好是容易使用地 可維護的 可增進的 經過驗證去證明系統滿足使用者的需求 經過測試後證明正確性和完整性 有效率的 可重複使用的程式碼用在其他的應用程式 容易移轉到其他的硬體/軟體環境 容易與其他軟體連接 容易理解的程式碼 精確的 優雅的在知識的邊緣降低 可以嵌入其他語言的能力 驗證知識庫 解釋機制 專家系統的生命週期 1.維護成本 (Maintenance Costs) 一般軟體 (Conventional software) 60 ~ 80 % 的軟體花費、二到四倍原本的開發花費 專家系統 (Expert systems) 可能更糟 2.瀑布模型 (Waterfall Model) 一個傳統軟體開發的生命週期模型 圖9-5 下一歩要完成什麼? 下一階段要花多少時間完成? 一個詳細的生命週期模型 線性模型在圖 9-7 包含從規劃到系統評估的步驟 描述在系統開發過程中哪些點的功能將被評估 驗證和證實步驟可以在開發過程中平行處理 重要的是根據相同的步驟程序來維護專家系統的品質 1.問題分析，定義及工作規劃(Planning) 產生正規的工作規劃 一些文件集用來導引和評估開發流程 表 9-2 動機與問題確認 資料導向 (Data driven) 由下而上專案 (Bottom-up project) 資料純化 (Data cleansing) 資料轉換 (Data transformation) 圖 9-13 目標導向 (Goal driven) 由上而下專案 (Top-down project) 兩階段 第一階段: 列出所有可能目標 (possible target list) 第二階段: 針對所有列出之目標架構階層關係，建立目 標階層（Targets hierarchy） 資料導向的問題確認流程 可行性評估 定性分析 需求 資源、知識來源、支援人力 風險 問題難易度如何 ? 知識是否容易取得 ? 專案人員能力是否足夠 ? 發展之技術原理是否合理 ? 技術是否容易維護 ? 定量分析 成本效益 專家系統專案計劃書 2.知識定義，擷取及技術評估(Knowledge Definition) 定義專家系統所需的知識 包含兩個工作 定義知識來源 知識的選擇