可行性研究
並非任何題都有簡單明顯的解決辦法,事實上,許多間題不可能在定的係使觀模或時間期限之內解決,如果問題沒有可行的解,那麼花費在這項工程上的任何時間、人力、軟硬體資源和經費,都是無謂的浪費
研究的目的是用最小的代價在盡可能短的時間確定問題是否能夠解決。
2.1可行性研究的任務
必須時刻記住，可行性研究的目的不是解決問題，而是確定問題是否值得解決。怎麼樣達到這個目的呢？當然不能靠主觀猜想而只能靠客觀分析,必須分析幾種主要的可能解法的利弊,從而判斷原定的系統規模和目標是否現實,系能完成後所能帶來的效益是否大到值得投資開發這個系統的程度。因此,可行性研究實質上是要進行一次大大壓縮簡化了的系統分析和設計的過程,也就是在較高層次上以較抽象的方式進行的系統分析和設計的過程。
首先需要進一步分析和澄清間題定義。在問題定義階段初步確定的規模和目標,如果是正確的就進一步加以肯定,如果有錯誤就應該及時改正,如果對目標系統有任何約束和限制,也必須把它們清楚地列舉出來。在澄清了問題定義之後,分析員應該匯出系統的邏輯模型,然後從系統邏輯模型出發,探常若干種可供選擇的主要解法(即系統實現方案)。對每種解法都應該仔細研究它的可行性,一般說來,至少應該從下述3個方面研究每種解法的可行性。
(1)技術可行性 使用現有的技術能實現這個系統嗎?
(2)經濟可行性 這個系統的經濟效益能超過它的開發成本嗎?
(3)操作可行性 系統的操作方式在這個使用者組織內行得通嗎?
？（4）社會可行性
必要時還應該從法律,社會效益籤更廣泛的方面研究每種解法的可行性。
分析員應該為每個可行的法定乙個粗略的實現進度。
當然,可行性研究最根本的任務是對以後的行動方針提出建議,如果問題沒有可行分析員應該建議停止這項開發工程,以避免時間,資置、人力和金錢的浪費;如果問題值得解,分析員應該推薦乙個較好的解決方案,並且為工程定乙個初步的計畫。
可行性研究需要的時長短取決於工程的模,一說來,可行性研究的成本只是預期工程總成本的5%~10%。
2.2 可行性研究過程
怎樣進行可行性研究呢?典型的可行性究過程有下述一些步驟。
1.複查系統規模和目標
分析員訪問關鍵人員,仔細閱讀和分析有關的材料,以便對間題定義階段書寫的關於規模和目標的報告書進一步複查確認,改正含糊不清或不確切的敘述,清晰地描述對目標系統的一切限制和約束,這個步驟的工作,實質上是為了確保分析員正在解決的問題確實是要求他解決的同題。
2.研究目前正在使用的系統
現有的系統是資訊的重要**,顯然,如果目前有乙個系統正被人使用,那麼這個系統必定能完成某些有用的工作,因此,新的目標系統必須也能完成它的基本功能;另一方面,如果現有的系統是完美無缺的,使用者自然不會提出開發新系統的要求,因此,現有的系統必然有某些缺點,新系統必須能解決舊系統中存在的問題,此外,執行舊系統所需要的費用是乙個重要的經濟指標,如果新系統不能增加收人或減少使用費用,那麼從經濟角度看新系統就不如舊系統。
應該仔細閱讀分析現有系統的文件資料和使用手冊,也要實地考察現有的系統。應該注意了解這個系統可以做什麼,為什麼這樣做,還要了解使用這個系統的代價。在了解上述這些資訊的時候顯然必須訪問有關的人員。
常見的錯誤做法是花費過多時間去分析現有的系統,這個步驟的目的是了解現有系統能做什麼,而不是了解它怎樣做這些工作。分析員應該畫出描繪現有系統的高層系統流程圖(見系統流程圖),並請有關人員檢驗他對現有系統的認識是否正確。千萬不要花費太多時間去了解和描繪現有系統的實現細節。
沒有乙個系統是在「真空」中執行的,絕大多數系統都和其他系統有聯絡。應該注意了解並記錄現有系統和其他系統之間的介面情況,這是設計新系統時的重要約束條件。
3.匯出新系統的高層邏模型
優秀的設計過程通常是從現有的物理系統出發,匯出現有系統的邏輯模型,再參考現有系統的邏輯模型,設想目標系統的邏輯模型,最後根據目標系統的邏輯模型建造新的物理系統。
通過前一步的工作,分析員對目標系統應該具有的基本功能和所受的的束已有一定了解,能夠使用資料流圖,描繪資料在系使中流動和處理的情況,從而概括地表達出他對新系統的設想,通過為了把系統繪得更清準確,還應該有乙個初步的資料字典,定義系統中使用的資料,資料流圖和資料字典共同定義了新系統的邏輯模型,以後可以從這邏輯模型出發設計新系統。
4.進一步定義問題
新系統的判模實質上表達了分析員對新系統必須做什麼的看法,使用者是否也有同樣的看法呢?分析員應該和用一起再次複查問題定義,工程規模和目標,這次複查應該把資料流圖和資料字典作為討論的基礎,如果分析員對同題有誤解或者使用者曾經遺漏了某些要求,那麼現在是發現和改正這些錯誤的時候了。
可行性研究的前4個步實質上構成乙個環,分析員定義同題,分析這個問題，匯出乙個試探性的解;在此基礎上再次定義問題,再一次分析這個問題,修改這個解:繼續這個迴圈過程,直到提出的邏輯模型完全符合系統目標。
5.匯出和評價供選擇的解法
分析員應該從他建議的系統邏輯模型出發,導著若干個較高層次的(較軸象的)物理解法供比較和選擇,匯出供選擇的解法的最簡單的途徑,是從技術角度出考慮解決問題的不同方案,後面將舉例說明在資料流圖上劃分不同的自動化邊界從面出不同物理方案的方法,分析員可以確定幾組不同的自動化邊界,然後針對每一組邊界考慮如何實現要求的系統。還可以使用組合的方法匯出若干種可能的物理系統,例如,在每一類計算機上可能有幾種不同型別的系統,組合各種可能將有微處理機上的批處理系統、微處理機上的互動式系統、小型機上的批處理系統等方案,比外還應該把現有系統和人工系統作為兩個可能的方案一起考慮進去。
當從技術角度提出了一些可能的物理系統之後,應該根技術可行性的考慮初步排一些不現實的系統,例如,如果要求系統的響應時不超過幾秒鐘,顯然應該排除任何批處理方案,把技術上行不通的解法去掉之後,就剩下了一組技術上可行的方案。
其次可以考慮操作方面的可行性。分析員應該要據使用部門處理事務的原則和習慣檢查技術上可行的那些方案,去掉其中從操作方式或操作過程的角度看使用者不能接受的方案。
接下來應該考慮經濟方面的可行性,分析員應該值計餘下的每個可能的系統的開發成本和執行費用,並且估計相對於現有的系統而言這個系統可以節省的開文或可以增加的收人,在這些估計數字的基礎上,對每個可能的系統進行成本/效益分析,一說來,只有投資預計能帶來收利的系統才值得進一步考慮。
最後為每個在技術、操作和經濟等方面都可行的系統制定實現進度表,這個進度表不需要(也不可能)制定得很詳細,通常只需要估計生命週期每個階段的工作量。
6.推薦行動方針
根據可行性研究結果應該決定的乙個關鍵性問題是:是否繼續進行這項開發工程?分析員必須清楚地表明他對這個關鍵性決定的建議。如果分析員認為值得繼續進行這項開發工程,那麼他應該選擇一種最好的解法,並且說明選擇這個解決方案的理由。通常客戶主要根據經濟上是否划算決定是否投資於一項開發工程,因此分析員對於所推薦的系統必須進行比較仔細的成本/效益分析。
7.草擬開發計畫
分析員應該為所推薦的方案草擬乙份開發計畫,除了制定工程進度表之外還應該估計對各類開發人員(例如,系統分析員、程式設計師)和各種資源(計算機硬體、軟體工具等)的需要情況,應該指明什麼時候使用以及使用多長時間,此外還應該估計系統生命週期每個階段的成本。最後應該給出下乙個階段(需求分析)的詳細進度表和成本估計。
8.書寫文件提交審查
應該把上述可行性研究各個步驟的工作結果寫成清晰的文件,請使用者、客戶組織的負責人及評審組審查,以決定是否繼續這項工程及是否接受分析員推薦的方案。
軟體生存週期的過程，活動和任務
定義，分析需求或委託供方進行需求分析而後認可 招標準備 合同準備以及驗收 評審需求 準備投標 簽訂合同 制訂並實施專案計畫 開展評審及評價 交付產品 過程實施 系統需求分析 系統結構設計 軟體需求分析 軟體結構設計 軟體詳細設計 軟體編碼和測試 軟體整合 軟體合格測試 系統整合 系統合格測試 軟體安...
簡析軟體需求的分析過程
itpub論壇2009 06 15 文字tag 需求分析 it168 技術文章 最近正在做新產品的需求分析，對需求分析階段的很多問題又有了重新的認識，在此結合以前的經驗，就軟體 需求分析階段的各個任務，做一下總結，與大家分享。眾所周知，軟體需求分析是軟體生命週期的第二階段，主要對前期軟體定義及計畫階...
軟體工程中需求分析的任務是什麼？
一。確定對系統的綜合要求 1.功能需求 這方面的需求指定系統必須提供的服務。通過需求分析應該劃分出系統必須完成的所有功能。2.效能需求 效能需求指定系統必須滿足的定時約束或容量約束，通常包括速度 響應時間 資訊量速率 主存容量 磁碟容量 安全性等方面的需求。3.可靠性和可用性需求 可靠性需求定量地指...