作者：rick1126
email: rickzhang@sina.com
日期：8/15/2001 6:48:56 AM
第2章 可行性分析和需求確定


   【可行性分析】

   〖信息系統開發可行性〗

     . 可行性分析是位于系統計劃之后的一個可選的但是非常重要的系統分析和設計的分析階段的活動
     . 可行性分析的一個考慮因素就是是否有利可圖
     . 用來度量開發或者增強一個信息系統能夠給公司帶來多大收益
     . 增進用戶的信任 -- 隨著時間的推移, 加強用戶對所開發的信息系統的忠誠度和擁有程度
     . 在關鍵時刻了解項目的進展
       - 按照原定計劃繼續
       - 改變
       - 取消

   〖可行性類型〗

     . 操作可行性    度量給定環境的工作性能
     . 技術可行性    度量實用性和技術資源可用性
     . 經濟可行性    度量性能價格比 -- 給定時間內開發和運行信息系統的費用和財務回報

   〖相關費用和收益〗

     . 系統開發費用        一次性費用
     . 年運行費用        常年性費用

     . 可見收益
       - 處理        減少錯誤, 增強能力
       - 響應        更迅速
       - 消除工作等級    
       - 增收節支
       - 提高信譽
       - 減少信譽損失
       - 減少應收款項
     . 不可見收益
       - 增加客戶信任
       - 增強雇員士氣, 工作滿意度
       - 提供更好服務
       - 改善決策


ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ
   【需求確定】

   〖概念〗

     討論如何尋求記錄信息系統的真正需求

   〖難度〗
    
     . 需求確定是極具認知性和創造性的重復性循環漸進的活動
     . 問題域的動態性
     . 人和人之間的溝通問題
     . 其他因素

   〖問題域〗

     . 商業領域或者商業功能
     . 研究目的就是為了增強商業功能, 考慮是否購買, 新建, 改進信息系統
     . 確定問題域的范圍和邊界需要反復權衡和折衷

   〖需求確定技巧〗

     . 劃分需求主題領域的框架和方法, 不會遺漏需求領域
     . 如何向用戶提問的指南和經驗

   〖劃分問題域框架〗

     . 需求確定子活動

       - 需求期望        基于經驗和理解, 假定存在的某些需求
       - 需求引導        使用各種技巧向用戶征求需求
       - 需求驗證        和用戶一起確認需求的有效性和正確性
       - 需求規格說明    該活動的產品
       * 上面的4個活動相互聯系可以反復進行

     . PIECES框架

       - Performance(性能)    系統怎樣為用戶服務 = 處理能力 + 反應時間
       - Information(信息)    為持久性數據的信息模型或者數據模型奠定基礎
       - Economy    (經濟)    開發和運行維護費用, 以及一切系統相關的經濟目標和錯誤目標
       - Control    (控制)    與系統安全相關及編輯輸入數據有關
       - Efficiency (效率)    衡量方法正確與否 = 公司, 部門, 個人
       - Services   (服務)    功能相關, 還涉及易用性, 對持續使用維護系統, 培訓和文檔需求提供必要的支持

     . Kozar 需求模型

       - 比較特點: 將信息系統的目標和策略同商業目標和策略聯系, 需求模型的關鍵就是如何建立商業目標和信息系統之間的聯系
       - 模型層次
         內部/外部刺激    表達變革的要求或者希望
         商業目標        針對實現該機構目的的詳細書面陳述, 可度量的, 通常有明確的時間和資金規定, 安裝TQM觀點, 需要不斷提高和超越
         商業策略        實現商業目標的具體行動, 如果含有信息系統, 則形成兩個層次: 信息系統目標和策略
         信息系統目標    直接支持一個或者多個商業策略
         信息系統策略    如何實施信息系統的目標, 表示系統分析員和其他技術人員為達到系統目標而進行的工作

       - 基本原則: 更抽象或者更具體
       - 過程順序: 任務/意圖( 信息系統需要存在的理由 ) -> 目的( 總體系統陳述 ) -> 目標( 可度量的開發目標 ) -> 策略和要求( 如何實現目標 ) -> 信息系統( 用戶的行動支持 )

     . 需求模型的優缺點和適用范圍
       
       - 優勢在于利用良好的商業策略模型
       - 缺點在于如果現實中一般沒有非常精確完整的商業策略

       - 在商業模型不明確的時候, PIECES更好

   〖面向對象的需求確定建?；顒印?
     . 建模方法的基本思考概念
       - 對象    任意感興趣的研究對象
       - 模式    帶有典型責任和交互的模板, 模板可以復用, 是構成對象的基本材料; 其實模式就是類型即對于對象的抽象
       - 責任    對象自身了解( 屬性, 狀態 ); 對象相互關系( 聯系 ); 對象提供的服務( 功能 )
       - 場景    完成特定功能所需要的一組對象交互順序( 流程 )

     . 建模方法的步驟
       - 確定信息系統的目標和特點
       - 確定對象和模式
       - 建立對象的責任
       - 設計系統的動態場景

     . 模型的組成
       - 問題域
       - 人機交互
       - 數據管理
       - 系統交互

ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ
   【搜集信息系統需求的方法】

   〖角度〗
     
     . 全局
       - 主要是從歷史和橫向角度進行需求收集, 不直接面對用戶. 通過現有的文檔, 其他公司的商業目標/策略, 同類系統的目標/策略進行需求收集.
       - 優點: 有利于系統分析員熟悉新系統情況, 了解起碼的系統需求
       - 缺點: 著重當前或者以前的工作, 忽視未來的改進工作, 處于仿造角度考慮

     . 個人
       - 通過采訪用戶, 問卷或者調查方式, 建立原型期待用戶反饋等方式進行, 直接從用戶方面得到需求
       - 原型: 用戶直到看到自己不想要的東西的時候才知道自己需要什么
     
     . 團隊
       - 主要使用團隊頭腦風暴, 電子聯合應用開發, 團隊系統軟件等團隊討論手段, 是的用戶, 系統分析員, 開發小組一起討論需求
       - 優點: 增強團隊凝聚力, 用戶的想法得到承認, 用戶個人意見得到集中處理 ==> 綜合討論結果的自然方法
       - 缺點: 人際關系如果不能正確協調, 系統分析員不能從頭腦風暴中正確得到需要的信息, 對于項目是一場災難
       - 劃分: 按照 [現在必要] [將來需要] [不需要] 進行劃分
       - 可行性: 可見性, 技術可行性
       - 特點: 必須向用戶反饋得到確認, 需要上下文無關內容, 需要良好的溝通技巧

   〖需求的不確定性〗

     . 需求搜集作為一種高度感性的充滿不確定性的活動面臨各種潛在問題
       - 遺漏的需求 -- 顛覆系統的可能
       - 模棱兩可得措辭
       - 新加的成份 -- 自做主張

ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ