1、計算機網(wǎng)絡(luò)課件 制作人：謝希仁,張 磊 博士 副教授 ,第2章 軟件生存周期與軟件過程,課件制作人：謝希仁,2.1 軟件生存周期 2.2 軟件生存期模型 2.3 問題定義 2.4 可行性研究 2.5 可行性論證報告的主要方面 2.6 項目計劃,課件制作人：謝希仁,軟件有一個孕育、誕生、成長、成熟、衰亡的生存過程。這個過程即為計算機軟件的生存周期。 一般說來，軟件生命周期劃分為三個時期：計劃時期、開發(fā)時期、運行時期。 計劃時期劃分為問題定義和可行性研究； 開發(fā)時期又劃分為需求分析、概要設(shè)計、詳細設(shè)計、編碼和測試階段； 運行時期主要是在運行中完成各類維護。,2.1 軟件生存周期,課件制作人：謝希仁

2、,課件制作人：謝希仁,2.1.1計劃時期,1.問題定義 確定要開發(fā)軟件系統(tǒng)的總目標。 給出功能、性能、可靠性以及接口等方面的要求，系統(tǒng)定義。 2.可行性研究 估計可利用的資源(計算機硬件，軟件，人力等)、成本、效益、開發(fā)進度。 制定出完成開發(fā)任務(wù)的實施計劃和解決方案,可行性研究報告。,課件制作人：謝希仁,2.1.2開發(fā)時期,1.需求分析 對待開發(fā)軟件提出的需求進行分析并給出詳細的定義。 編寫軟件需求說明書或系統(tǒng)功能說明書及初步的系統(tǒng)用戶手冊。 提交管理機構(gòu)評審。,課件制作人：謝希仁,2.概要設(shè)計 把各項需求轉(zhuǎn)換成軟件的體系結(jié)構(gòu)，結(jié)構(gòu)中每一組成部分都是意義明確的模塊，每個模塊都和某些需求相對應(yīng)。

3、 編寫概要設(shè)計說明書。 3.詳細設(shè)計 對每個模塊要完成的工作進行具體的描述，為源程序編寫打下基礎(chǔ)。 編寫詳細設(shè)計說明書。,課件制作人：謝希仁,4.編碼 把軟件設(shè)計轉(zhuǎn)換成計算機可以接受的程序代碼，即寫成以某一種特定程序設(shè)計語言表示的“源程序清單”。 寫出的程序應(yīng)當是結(jié)構(gòu)良好、清晰易讀的，且與設(shè)計相一致的。 5.測試 單元測試，查找各模塊在功能和結(jié)構(gòu)上存在的問題并加以糾正。 組裝測試，將已測試過的模塊按一定順序組裝起來。 按規(guī)定的各項需求，逐項進行有效性測試，決定已開發(fā)的軟件是否合格，能否交付用戶使用。,課件制作人：謝希仁,2.1.3運行時期,運行時期的主要工作是維護 改正性維護 運行中發(fā)現(xiàn)了軟件

4、中的錯誤需要修正。 適應(yīng)性維護 為了適應(yīng)變化了的軟件工作環(huán)境，需做適當變更。 完善性維護 為了增強軟件的功能需做變更。,課件制作人：謝希仁,各階段工作小結(jié),階段,關(guān)鍵問題,結(jié)束標準,問題定義,問題是什么,關(guān)于規(guī)模和目標的報告書,可行性研究,有可行的解,系統(tǒng)的高層邏輯模型,需求分析,系統(tǒng)必須做什么,系統(tǒng)邏輯模型,總體設(shè)計,概括地說，應(yīng)該如何解決問題,可能解法,詳細設(shè)計,怎樣具體實現(xiàn),編碼規(guī)格說明,課件制作人：謝希仁,階段,關(guān)鍵問題,結(jié)束標準,編碼和單元測試,正確的程序模塊,源程序清單，單元測試 方案和結(jié)果,綜合測試,符合要求的軟件,綜合測試方案和結(jié)果， 完整一致的軟件配置,維護,持久地滿足用戶需

5、要的軟件,完整準確的維護記錄,課件制作人：謝希仁,2.2 軟件生存期模型,軟件生存期模型是跨越整個生存期的系統(tǒng)開發(fā)、運作和維護所實施的全部過程、活動和任務(wù)的結(jié)構(gòu)框架。 軟件開發(fā)模型是對軟件過程的建模 邊做邊改模型 瀑布模型 原型模型 增量模型 螺旋模型 RUP過程 敏捷過程 極限編程 微軟過程模型,課件制作人：謝希仁,2.2.1邊做邊改模型,遺憾的是，許多產(chǎn)品都是使用“邊做邊改”模型來開發(fā)的。在這種模型中，既沒有規(guī)格說明，也沒有經(jīng)過設(shè)計，軟件隨著客戶的需要一次又一次地不斷被修改。,課件制作人：謝希仁,2.2.2瀑布模型,1970年Winston Royce提出了著名的瀑布模型，直到80年代早期

6、，它一直是唯一被廣泛采用的軟件開發(fā)模型。 該模型將基本的過程活動、描述、開發(fā)、有效性驗證和進化，看成是一些界限分明的獨立的過程階段，如：需求描述階段、軟件設(shè)計階段、實現(xiàn)階段、測試階段等。 該模型也可以看成是軟件的生命周期模型。 該模型是計劃驅(qū)動的，理論上，在開始工作之前，必須對所有的過程活動制定計劃并給出進度安排。,課件制作人：謝希仁,2.2.2瀑布模型,課件制作人：謝希仁,問題定義,編 碼,需求分析,軟件設(shè)計,可行性研究,運行與維護,測 試,開發(fā) 時期,運行 時期,計劃時期,(目標與范圍說明書),(可行性論證論告),(維護報告),(測試報告),(程序),(設(shè)計文檔),(需求說明書),課件制作

7、人：謝希仁,瀑布模型的特點 1階段間具有順序性和依賴性關(guān)系 順序性的含義是必須待前一階段的工作完成之后，才能進行下一階段的工作。 依賴性的含義是前一階段的輸出就是后一階段的輸入，只有前一階段的輸出正確，后一階段的工作才有可能獲得正確的結(jié)果。,課件制作人：謝希仁,2推遲實現(xiàn) 實踐表明，編碼開始得越早完成開發(fā)工作所需要的時間反而越長。 這是因為，前期階段的工作沒完全做好，就急于考慮程序?qū)崿F(xiàn)，其結(jié)果導(dǎo)致大量返工，有時甚至產(chǎn)生無法彌補的問題，帶來嚴重后果。,課件制作人：謝希仁,3質(zhì)量保證 各階段都必須完成規(guī)定的文檔。完整、正確、合格的文檔不僅是軟件開發(fā)時期各類人員之間相互通信的媒介，也是軟件維護的重要

8、依據(jù)。 各階段結(jié)束前都要對所完成的文檔進行評審，以便及時發(fā)現(xiàn)問題，改正錯誤。,課件制作人：謝希仁,瀑布模型的缺點 （1） 各個階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量。 （2） 由于開發(fā)模型是線性的，用戶只有等到整個過程的末期才能見到開發(fā)成果，從而增加了開發(fā)的風險。 （3） 早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn)，進而帶來嚴重的后果。,課件制作人：謝希仁,2.2.3快速原型模型,由于在項目開發(fā)的初始階段人們對軟件的需求認識常常不夠清晰，因而使得開發(fā)項目難于做到一次開發(fā)成功，出現(xiàn)返工再開發(fā)在所難免。做兩次或多次：,第一次只是試驗開發(fā)，其目標只是在于探索可行性，弄清軟

9、件需求。 第二次則在此基礎(chǔ)上獲得較為滿意的軟件產(chǎn)品。,課件制作人：謝希仁,快速原型模型特點 在需求定義之前，需要快速構(gòu)建一個系統(tǒng)。 根據(jù)構(gòu)建系統(tǒng)的優(yōu)缺點，用戶給開發(fā)人員提出反饋意見。 根據(jù)反饋意見修改軟件需求規(guī)格，以便系統(tǒng)可以更正確地反映用戶的需求。 減少各種假設(shè)以及風險。,課件制作人：謝希仁,2.2.4增量模型,在增量模型中，軟件被作為一系列的增量構(gòu)件來設(shè)計、實現(xiàn)、集成和測試，每一個構(gòu)件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構(gòu)成 。 增量模型在各個階段并不交付一個可運行的完整產(chǎn)品，而是交付滿足客戶需求的一個子集的可運行產(chǎn)品。整個產(chǎn)品被分解成若干個構(gòu)件，開發(fā)人員逐個構(gòu)件地交付產(chǎn)品

10、，這樣做的好處是軟件開發(fā)可以較好地適應(yīng)變化，客戶可以不斷地看到所開發(fā)的軟件，從而降低開發(fā)風險。,課件制作人：謝希仁,在使用增量模型時，第一個增量往往是實現(xiàn)基本需求的核心產(chǎn)品。 核心產(chǎn)品交付用戶使用后，經(jīng)過評價形成下一個增量的開發(fā)計劃，它包括對核心產(chǎn)品的修改和一些新功能的發(fā)布。 這個過程在每個增量發(fā)布后不斷重復(fù)，直到產(chǎn)生最終的完善產(chǎn)品。,課件制作人：謝希仁,增量模型也存在以下缺陷 （1）由于各個構(gòu)件是逐漸并入已有的軟件體系結(jié)構(gòu)中的，所以加入構(gòu)件必須不破壞已構(gòu)造好的系統(tǒng)部分，這需要軟件具備開放式的體系結(jié)構(gòu)。 （2）在開發(fā)過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應(yīng)這種變化的能力大大

11、優(yōu)于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟件過程的控制失去整體性。,課件制作人：謝希仁,增量模型總結(jié) 融合了瀑布模型和原型的迭代特征。 每一個增量均發(fā)布一個可操作產(chǎn)品。,課件制作人：謝希仁,2.2.5螺旋模型,螺旋模型沿著螺線旋轉(zhuǎn)，在四個象限上分別表達了四個方面的活動，即： 制定計劃確定軟件目標，選定實施方案，弄清項目開發(fā)的限制條件。 風險分析分析所選方案，考慮如何識別和消除風險。 工程實現(xiàn)實施軟件開發(fā)。 評審評價開發(fā)工作，提出修正建議。,課件制作人：謝希仁,課件制作人：謝希仁,螺旋模型的限制條件 （1）螺旋模型強調(diào)風險分析，但要求許多客戶接受和相信這種分析，并做出相關(guān)

12、反應(yīng)是不容易的，因此，這種模型往往適應(yīng)于內(nèi)部的大規(guī)模軟件開發(fā)。 （2）如果執(zhí)行風險分析將大大影響項目的利潤，那么進行風險分析毫無意義，因此，螺旋模型只適合于大規(guī)模軟件項目。 （3）軟件開發(fā)人員應(yīng)該擅長尋找可能的風險，準確地分析風險，否則將會帶來更大的風險。,課件制作人：謝希仁,螺旋模型總結(jié) 基于風險驅(qū)動的開發(fā)模型， 使用原型法或其它方法來盡量降低風險。 適用于需求不明確的大規(guī)模軟件項目。,課件制作人：謝希仁,增量模型和螺旋模型的主要區(qū)別 （1）增量模型的通過避免使用未成熟技術(shù)和經(jīng)常的客戶反饋等方法減少風險；而螺旋模型中直接增加了風險分析，評價所選方案，識別和消除風險。 （2）增量模型經(jīng)常是先做

13、總體需求分析和設(shè)計，然后在編碼和測試中逐個增量開發(fā)；螺旋模型在每個開發(fā)周期內(nèi)采用簡化瀑布模型或快速模型。 （3）增量模型通過迭代來逐步添加功能和需求，以完善產(chǎn)品；螺旋模型是事先定義大部分需求,開發(fā)過程中計劃性比較強。,課件制作人：謝希仁,2.2.6 RUP過程(統(tǒng)一過程),課件制作人：謝希仁,用例驅(qū)動 Concise, simple, and understandable 以體系結(jié)構(gòu)為中心 Effective basis for large-scale reuse 增量和迭代開發(fā) 基于風險前驅(qū)的原則，漸進地展開分析、設(shè)計及其相關(guān)活動，每個迭代都會提供一次驗證和調(diào)整模型機會，推動軟件質(zhì)量的提升。

14、,課件制作人：謝希仁,迭代式開發(fā) 容納需求變更/減少風險。 管理需求 使用用例和腳本。 使用基于構(gòu)件的體系結(jié)構(gòu)。 可視化建模。 驗證軟件質(zhì)量 質(zhì)量評估內(nèi)建在貫穿于整個開發(fā)過程的、由全體成員參與的所有活動中。 控制軟件變更。,課件制作人：謝希仁,核心工作流 業(yè)務(wù)建模 需求分析與設(shè)計 實現(xiàn) 測試 部署 生成目標系統(tǒng)的可運行版本，移交給用戶 配置與變更管理跟蹤維護開發(fā)過程中Artifacts的完整 性和一致性 項目管理提供項目管理框架，為軟件開 發(fā)項目制定計劃、人員配備、執(zhí)行和監(jiān)控等方面的使用準則，并為風險管理提供框架 環(huán)境提供軟件開發(fā)環(huán)境，包括過程管理和工具支持,課件制作人：謝希仁,工作階段 In

15、ception：建立業(yè)務(wù)模型，定義最終產(chǎn)品視圖，確定項目的范圍。 Elaboration：設(shè)計并確定系統(tǒng)的體系結(jié)構(gòu)，制定項目計劃，確定資源需求。 Construction：開發(fā)所有構(gòu)件和程序，集成為可戶需要的產(chǎn)品，測試所有功能。 Transition：把開發(fā)出的產(chǎn)品提交給用戶使用。,課件制作人：謝希仁,2.2.7 敏捷過程,敏捷過程（2001/2敏捷軟件開發(fā)宣言 The Manifesto of the Agile Alliance ） 敏捷過程的價值觀 個體和交互勝過過程和工具。 可以工作的軟件勝過面面俱到的文檔。 客戶合作勝過合同談判。 響應(yīng)變化勝過遵循計劃。,課件制作人：謝希仁,敏捷過程

16、的原則 我們最優(yōu)先要做的是通過盡早的，持續(xù)的交付有價值的軟件來使客戶滿意。 即使到了開發(fā)的后期，,也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。 經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。 在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。 圍繞被激勵起來的個人來構(gòu)建項目。給他們提供所需要的環(huán)境和支持，并且信任他們能夠完成工作。,課件制作人：謝希仁,敏捷過程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。 在團隊內(nèi)部，最具有效果并且富有效率的傳遞信息的方法,就是面對面的交談。 工作的軟件是首要的進度度量

17、標準。 不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力。 簡單是根本的。 最好的架構(gòu)、需求和設(shè)計出自于自組織的團隊。 每隔一段時間，團隊就會在如何才能更有效地工作方面進行反省，然后相應(yīng)地對自己的行為進行調(diào)整。,課件制作人：謝希仁,2.2.8 極限編程（eXtreme Programming, XP）,極限編程是敏捷過程中最富盛名的一個，其中“極限”的含義是指把最好的開發(fā)實踐運用到極致。目前極限編程已經(jīng)成為一個典型的開發(fā)方法，廣泛應(yīng)用于需求模糊且經(jīng)常改變的場合。 特點： 對變化和不確定性反應(yīng)更快速，更敏捷。 快速的同時保持可持續(xù)的開發(fā)速度。,課件制作人：謝希仁,客戶作為開發(fā)團隊的成員。 使用用戶素

18、材。 短交付周期（每兩周完成一次迭代）。 驗收測試。 結(jié)對編程。 測試驅(qū)動的開發(fā)。 集體所有（程序代碼屬于整個開發(fā)小組，每個成員都有修改代碼的權(quán)利，都對全部代碼負責）。,極限編程的有效實踐,課件制作人：謝希仁,持續(xù)集成（一日內(nèi)多次集成，不斷回歸測試）。 可持續(xù)的開發(fā)速度（周工作時間不超過40小時，連續(xù)加班不超過兩周）。 開放的工作空間。 及時調(diào)整計劃。 重構(gòu)。 使用隱喻（隱喻是把整個系統(tǒng)聯(lián)系在一起的全局視圖，描述系統(tǒng)如何運做，如何把新功能加入到系統(tǒng)中）。,課件制作人：謝希仁,極限編程的整體開發(fā)過程,課件制作人：謝希仁,極限編程的迭代過程,結(jié)對編程與人員輪換；持續(xù)地優(yōu)化設(shè)計；循環(huán)冗余檢測,課件制

19、作人：謝希仁,2.2.9 微軟過程模型,Microsoft公司自己獨特的軟件開發(fā)過程，綜合了RUP和XP的許多優(yōu)點，是對眾多成功項目的開發(fā)經(jīng)驗的正確總結(jié)。 不足： 方法工具和產(chǎn)品等方面的論述不如RUP和XP全面。 人們對它的某些準則本身也有不同意見。,課件制作人：謝希仁,微軟過程準則,項目計劃應(yīng)該兼顧未來的不確定因素。 用有效的風險管理來減少不確定的因素。 經(jīng)常生成并快速地測試軟件的過渡版本。 采用快速循環(huán)、遞進的開發(fā)過程。 用創(chuàng)造性的工作來平衡產(chǎn)品特性和產(chǎn)品成本。 項目進度表應(yīng)該具有較高的穩(wěn)定性和權(quán)威性。 使用小型項目組并發(fā)地完成開發(fā)工作。 在項目早期把軟件配置項基線化。,課件制作人：謝希仁

20、,使用原型驗證概念。 把零缺陷作為追求的目標。 里程碑評審會強調(diào)改進工作，避免相互指責。,課件制作人：謝希仁,微軟軟件生命周期,課件制作人：謝希仁,規(guī)劃階段 確定產(chǎn)品目標。 獲取競爭對手的信息。 完成對客戶和市場的調(diào)研分析。 確定新版本產(chǎn)品應(yīng)該具備的主要特性。 確定相對于前一版本而言，新版本應(yīng)該解決的問題和需要增加的功能。,課件制作人：謝希仁,設(shè)計階段 根據(jù)產(chǎn)品目標編寫系統(tǒng)的特性規(guī)格說明書，這份說明書主要描述軟件特性、系統(tǒng)結(jié)構(gòu)、各構(gòu)件之間的相關(guān)性以及接口標準。 從系統(tǒng)高層開始著手進行系統(tǒng)設(shè)計。 描述整個系統(tǒng)的設(shè)計方案。 繪制系統(tǒng)結(jié)構(gòu)圖。 確定系統(tǒng)中存在的風險因素。 分析系統(tǒng)的可重用性。,課件制

21、作人：謝希仁,劃分出系統(tǒng)中的子系統(tǒng)，給出各個子系統(tǒng)和各個構(gòu)件的規(guī)格說明。 根據(jù)產(chǎn)品特性規(guī)格說明書制定產(chǎn)品開發(fā)計劃。 開發(fā)階段 編寫程序代碼/書寫文檔。 穩(wěn)定階段 測試和調(diào)試。 發(fā)布階段 發(fā)布產(chǎn)品和解決方案，把項目移交到運營和支持人員手中。,課件制作人：謝希仁,各種模型的比較,每個軟件開發(fā)組織應(yīng)該選擇適合于該組織的軟件開發(fā)模型，并且應(yīng)該隨著當前正在開發(fā)的特定產(chǎn)品特性而變化，以減小所選模型的缺點，充分利用其優(yōu)點，下表列出了幾種常見模型的優(yōu)缺點。,課件制作人：謝希仁,課件制作人：謝希仁,2.3 問題定義 2.4 可行性研究 2.5 可行性論證報告的主要方面 2.6 項目計劃,課件制作人：謝希仁,問題

22、定義,可行性研究,可行否？,否,是,終止項目,.,課件制作人：謝希仁,2.3 問題定義,是計劃時期的第一個階段 該階段必須回答的問題是“是什么” 其目的是弄清用戶需要解決的問題,以及項目所需的資源和經(jīng)費 關(guān)鍵性任務(wù)就是確定問題的性質(zhì)、工程的目標和規(guī)模,課件制作人：謝希仁,【目的】 明確用戶要計算機解決的問題是什么。 【任務(wù)】 確定問題的性質(zhì)、待開發(fā)系統(tǒng)的目標和范圍。 【方式】 口頭形式了解用戶的要求； 閱讀用戶提供的相關(guān)資料； 形成調(diào)查提綱，要求用戶填寫。 【成果】 軟件開發(fā)任務(wù)書,課件制作人：謝希仁,系統(tǒng)開發(fā)任務(wù)書,系統(tǒng)分析員對用戶提出的問題有了明確的認識后，應(yīng)該整理出一份書面調(diào)查報告，并提

23、交用戶和部門負責人進行審查 應(yīng)包括項目名稱、開發(fā)背景、項目目標、項目范圍、初步設(shè)想等內(nèi)容,課件制作人：謝希仁,軟件開發(fā)任務(wù)書內(nèi)容 項目名稱 開發(fā)背景 當前工作中存在的問題； 項目目標 用戶對新系統(tǒng)的目標； 項目范圍 初步想法 在用戶提出的需求的基礎(chǔ)上，分析人員考慮可以實現(xiàn)的其他功能 提出可行性研究的計劃,課件制作人：謝希仁,【例】教材科開發(fā)一個教材銷售系統(tǒng)。 項目名稱：教材銷售系統(tǒng) 開發(fā)背景：人工發(fā)售教材手續(xù)繁瑣，且易出錯。 項目目標： 建立一個高效率、無差錯的微機教材銷售系統(tǒng)。 項目范圍 利用現(xiàn)有計算機，C/S模式； 軟件開發(fā)費用不超過. 初步想法： 建議在系統(tǒng)中增加對缺書的統(tǒng)計與采購功能。

24、 提出可行性研究的計劃 建議進行大約10天的可行性研究,課件制作人：謝希仁,【例2】開發(fā)一個傳送帶分類系統(tǒng)的軟件(CLSS) 問題描述：,1,6,ID 121,ID 110,ID 111,ID 100,2,3,4,5,傳送帶移動方向(2米/秒),條形碼,分類站,分流器,課件制作人：謝希仁,【例2】開發(fā)一個傳送帶分類系統(tǒng)的軟件(CLSS) 項目范圍軟件功能 讀取條形碼輸入 CLSS軟件以和傳送帶速度一致的時間間隔接受來自條形碼閱讀器的信息。 解碼零件數(shù)據(jù) 條形碼數(shù)據(jù)被解碼成盒子的標識格式。 檢索數(shù)據(jù)庫 軟件可在最多可容納1000個條目的零件號數(shù)據(jù)庫中進行檢索，以確定當前在分類站位置的盒子應(yīng)該放到

25、哪個箱子中。,課件制作人：謝希仁,確定合適的箱子 箱子的信息被送到分流器，以把盒子放進合適的箱子中。 維護盒子目的地的記錄 每一個盒子所放進的箱子的記錄均被保存起來一供以后提取及報告。,課件制作人：謝希仁,項目范圍軟件性能 性能取決于傳送帶的速度； 每個盒子的處理必須在下一個盒子到達條形碼閱讀器之前完成。 項目范圍外部接口 運行軟件的設(shè)備、由軟件控制的設(shè)備 PC、條形碼閱讀器、分流器 已存在、且必須與新軟件連接的軟件 銷售軟件和分類軟件配合，制作已經(jīng)發(fā)貨的列表 通過鍵盤或其他I/O設(shè)備使用軟件的人,課件制作人：謝希仁,2.4 可行性研究,一個項目并非一定可行，存在大量失敗的例子 目的不是解決問

26、題，而是確定問題是否值得去解 是一次在較高層次上以比較抽象的方式進行的大大壓縮簡化的系統(tǒng)分析和設(shè)計過程,課件制作人：謝希仁,2.4.1可行性研究的任務(wù),1. 復(fù)查項目目標和規(guī)模 2. 市場調(diào)查 3. 研究當前系統(tǒng) 4. 得出目標系統(tǒng)解決方案 5. 方案的選擇與評價 6. 制訂開發(fā)計劃,課件制作人：謝希仁,解決方案應(yīng)該包含的工作內(nèi)容,物理分析的任務(wù)是：了解實際業(yè)務(wù)活動狀況，特別對一些活動要點進行分析，明確在這些要點之間什么東西在流動，如何進行流動，對物理流量進行分析，對其模型化，得到實際當前系統(tǒng)的物理模型。 功能分析的任務(wù)是：決定系統(tǒng)應(yīng)具備的功能，分析功能的結(jié)構(gòu)，功能如何展開和功能分配，分析各功

27、能之間的關(guān)系，整理它們之間傳遞的信息，利用數(shù)據(jù)流圖，描述信息在系統(tǒng)流動與處理的情況。,課件制作人：謝希仁,信息分析的任務(wù)是：調(diào)查系統(tǒng)的輸入、輸出、保存信息，明確信息的結(jié)構(gòu)及各信息之間的關(guān)系，調(diào)查各信息的信息量，調(diào)查各種報表和文件的格式，建立粗略的數(shù)據(jù)詞典，定義系統(tǒng)中使用的數(shù)據(jù)。 動態(tài)分析的任務(wù)是：系統(tǒng)內(nèi)每一部分有幾種狀態(tài)，各種狀態(tài)轉(zhuǎn)換的條件，同步產(chǎn)生的條件與同步后狀態(tài)的變化。,課件制作人：謝希仁,選擇與評價方案,多種候選方案 對同一功能，可以分配不同的系統(tǒng)元素 為選取最有效的分配方案，使用一組權(quán)衡準則進行評價,課件制作人：謝希仁,2.4.2可行性研究的內(nèi)容,開發(fā)任何一個基于計算機的系統(tǒng)都要受到

28、時間和各種資源等的限制。 風險評估就是在開發(fā)之前，就軟件系統(tǒng)目標、用戶可能提供的時間和資源等條件進行可行性研究，以避免錯誤的決策，造成人力、物力及財力上的浪費，甚至提高成本、拖延工期，更嚴重的會導(dǎo)致軟件失敗。 在項目計劃階段主要進行風險識別和風險估計。 1. 經(jīng)濟可行性 2. 技術(shù)可行性 3. 運行可行性 4. 法律可行性,值得開發(fā),可能實現(xiàn),課件制作人：謝希仁,1. 經(jīng)濟可行性,粗略地估算成本 估算可能取得的效益 提出可能需要的資源，包括人員、硬件、軟件等,課件制作人：謝希仁,【任務(wù)】 用戶多長時間可以回收成本？ 評估項目的開發(fā)成本，估算開發(fā)成本是否會超過項目預(yù)期的全部利潤。 【方法】 費用

29、估計 效益估計 成本效益分析,課件制作人：謝希仁,經(jīng)濟可行性【費用估計】 設(shè)備 計算機硬件、空調(diào)、電源、機房及其它設(shè)施； 系統(tǒng)軟件，DBMS，各種應(yīng)用軟件(包括軟件包)的估算； 人力 管理人員、研制人員、數(shù)據(jù)錄人員、維護人員的工資、獎金以及他們的培訓(xùn)費用； 差旅費用。 日常開銷 水、電、打印紙等易耗物品及設(shè)備的維修費用。 評審費用,課件制作人：謝希仁,經(jīng)濟可行性【效益估計】 新軟件提供哪些以前不能做或難以做到的工作； 提供信息的速度、精度、質(zhì)量有什么提高； 使用新系統(tǒng)增加的收入、節(jié)省的運行費。 如： 本系統(tǒng)可以高速、準確地處理和提供管理工作所需的各類統(tǒng)計報表和分析報告，避免工作過程中可能出現(xiàn)的

30、文件丟失、計算失誤、文件流程多、審閱慢、報表報告格式不規(guī)整、存檔管理復(fù)雜等情況. 可以減輕基層工作人員大量繁瑣的書寫、計算工作，節(jié)約管理成本，提供有關(guān)工程的準確全面細致的決策信息，促使管理人員決策科學(xué)化，管理水平上新臺階. 估計每年可以節(jié)省管理費用10萬元.,課件制作人：謝希仁,經(jīng)濟可行性【成本效益分析】 資金的時間價值計算公式： FP ( 1i ) N 其中： F：投資的將來值； P：投資的現(xiàn)在值； i：利率； N：年數(shù)； 把5000元存入銀行3年(利率0.12)，3年后的價值為 F=5000(1+0.12)3=7024.64 要在3年底獲得5000元的收入，現(xiàn)在要投資為 P=F/(1+i)

31、N=5000/(1+0.12)3=3558.90,課件制作人：謝希仁,經(jīng)濟可行性【成本效益分析】 【例3】某系統(tǒng)投入使用后，5年內(nèi)每年節(jié)約人民幣1000元，其投資3000元，試計算其效益。年利率12%,年,效益,利率,當前值,累計當前值,1,1000,1.12,892.86,892.86,2,1000,1.25,800.00,1692.86,3,1000,1.40,714.29,2407.15,4,1000,1.57,636.94,3044.09,5,1000,1.76,568.18,3612.27,投資回收率 =( 3612.27-3000)/3000 = 20%,課件制作人：謝希仁,2.

32、技術(shù)可行性,根據(jù)客戶提出的系統(tǒng)功能、性能及實現(xiàn)系統(tǒng)的各項約束條件，從技術(shù)角度研究實現(xiàn)系統(tǒng)的可行性。 技術(shù)可行性研究往往是系統(tǒng)開發(fā)過程中難度最大的工作。,課件制作人：謝希仁,【任務(wù)】 根據(jù)客戶提出的系統(tǒng)功能、性能及實現(xiàn)系統(tǒng)的各約束條件，從技術(shù)角度研究實現(xiàn)系統(tǒng)的可行性。 【方法】 資源分析 管理人員和各類專業(yè)技術(shù)人員； 開發(fā)人員是否對術(shù)語、縮寫、開發(fā)模式有一致的理解； 人員是否進行了必要的培訓(xùn)； 是否具備必需的軟件、硬件資源和工作環(huán)境等。 技術(shù)分析 現(xiàn)有的技術(shù)能否實現(xiàn)這一新系統(tǒng)？ 有哪些技術(shù)難點？ 建議采用的技術(shù)先進程度怎樣？,課件制作人：謝希仁,3. 運行可行性,對目標系統(tǒng)所規(guī)定的運行方式能否達到。 例如