《软件工程导论（第六版）》第二章 可行性分析与研究
目錄
2.1可行性研究相關(guān)概念
2.1.1可行性研究的目的
2.1.2可行性研究的內(nèi)容
2.1.3可行性研究的過程
2.2軟件風(fēng)險(xiǎn)分析
軟件風(fēng)險(xiǎn)分析一般過程:
2.2.1風(fēng)險(xiǎn)識別
2.2.2風(fēng)險(xiǎn)預(yù)測（風(fēng)險(xiǎn)估計(jì)）
2.2.3風(fēng)險(xiǎn)的駕馭和監(jiān)控
2.3系統(tǒng)流程圖
?2.4數(shù)據(jù)流圖（結(jié)構(gòu)化分析方法）
2.1可行性研究相關(guān)概念
2.1.1可行性研究的目的
花最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定問題是否能夠解決。（參考算法設(shè)計(jì)）
弄清待開發(fā)的項(xiàng)目是不是可能實(shí)現(xiàn)和值得進(jìn)行，通常由系統(tǒng)分析員完成。如果可行，即可制定項(xiàng)目實(shí)施計(jì)劃，同時(shí)開始軟件開發(fā)；如果不太可行，則應(yīng)當(dāng)提出終止該項(xiàng)目的建議。
總之，可行性研究的目的不是解決問題，而是確定問題是否值得去解決。
2.1.2可行性研究的內(nèi)容
可行性研究分析的大概過程：
首先，進(jìn)一步分析和澄清問題定義，初步確定問題規(guī)模和目標(biāo)
然后，分析員應(yīng)該導(dǎo)出系統(tǒng)的邏輯模型
再，探索若干種可供選擇的主要解法
最后，對每種解法研究其可行性
建議：
1.經(jīng)濟(jì)可行性---實(shí)現(xiàn)這個(gè)系統(tǒng)有沒有經(jīng)濟(jì)效益？多長時(shí)間能收回成本？
2.技術(shù)可行性----現(xiàn)有的技術(shù)能否實(shí)這一新系統(tǒng)？有什么技術(shù)難點(diǎn)？建議采用技術(shù)的先進(jìn)程度怎么樣？
3.運(yùn)行可行性（操作可行性）-----為新系統(tǒng)規(guī)定的運(yùn)行方式是否可行？
4.法律可行性----新系統(tǒng)的開發(fā)會不會在社會上或政治上引起侵權(quán)、破壞或其它責(zé)任問題？
其它，社會效益可行性等等。
2.1.3可行性研究的過程
典型的可行性研究的過程：
1.理清問題定義。
1.對當(dāng)前系統(tǒng)進(jìn)行調(diào)查和研究。（不是抄）
2.導(dǎo)出新系統(tǒng)的解決方案。（一般多種）
3.提出推薦方案。
4.編寫可行性論證報(bào)告。（系統(tǒng)概述+可行性分析+結(jié)論意見）
張海藩教材上的過程：
1.復(fù)查系統(tǒng)規(guī)模和目標(biāo)
? ?分析員訪問關(guān)鍵人員，仔細(xì)閱讀和分析有關(guān)的材料，以便對問題定義階段書寫的關(guān)于規(guī)模和目標(biāo)的報(bào)告書進(jìn)一步復(fù)查確認(rèn)，改正含糊或不確切的敘述，清晰地描述對目標(biāo)系統(tǒng)的一切限制和約束。這個(gè)步驟的工作，實(shí)質(zhì)上是為了確保分析員正在解決的問題確實(shí)是要求他解決的問題。
2.研究目前正在使用的系統(tǒng)
? ?現(xiàn)有的系統(tǒng)是信息的重要來源。顯然，如果目前有一個(gè)系統(tǒng)正被人使用，那么這個(gè)系統(tǒng)必定能完成某些有用的工作，因此，新的目標(biāo)系統(tǒng)必須也能完成它的基本功能；另一方面，如果現(xiàn)有的系統(tǒng)是完美無缺的，用戶自然不會提出開發(fā)新系統(tǒng)的要求，因此，現(xiàn)有的系統(tǒng)必然有某些缺點(diǎn)，新系統(tǒng)必須能解決舊系統(tǒng)中存在的問題。 應(yīng)該仔細(xì)閱讀分析現(xiàn)有系統(tǒng)的文檔資料和使用手冊，也要實(shí)地考察現(xiàn)有的系統(tǒng)。 常見的錯(cuò)誤做法是花費(fèi)過多時(shí)間去分析現(xiàn)有的系統(tǒng)。 沒有一個(gè)系統(tǒng)是在“真空”中運(yùn)行的，絕大多數(shù)系統(tǒng)都和其他系統(tǒng)有聯(lián)系。
3.導(dǎo)出新系統(tǒng)的高層邏輯模型
? ?優(yōu)秀的設(shè)計(jì)過程通常是從現(xiàn)有的物理系統(tǒng)出發(fā)，導(dǎo)出現(xiàn)有系統(tǒng)的邏輯模型，再參考現(xiàn)有系統(tǒng)的邏輯模型，設(shè)想目標(biāo)系統(tǒng)的邏輯模型，最后根據(jù)目標(biāo)系統(tǒng)的邏輯模型建造新的物理系統(tǒng)。
4.進(jìn)一步定義問題
? ?可行性研究的前4個(gè)步驟實(shí)質(zhì)上構(gòu)成一個(gè)循環(huán)。分析員定義問題，分析這個(gè)問題，導(dǎo)出一個(gè)試探性的解；在此基礎(chǔ)上再次定義問題，再一次分析這個(gè)問題，修改這個(gè)解；繼續(xù)這個(gè)循環(huán)過程，直到提出的邏輯模型完全符合系統(tǒng)目標(biāo)。
5.導(dǎo)出和評價(jià)供選擇的解法
? 分析員應(yīng)該從他建議的系統(tǒng)邏輯模型出發(fā)，導(dǎo)出若干個(gè)較高層次的物理解法供比較和選擇。 其次可以考慮操作方面的可行性。分析員應(yīng)該根據(jù)使用部門處理事務(wù)的原則和習(xí)慣檢查技術(shù)上可行的那些方案，去掉其中從操作方式或操作過程的角度看用戶不能接受的方案。 接下來應(yīng)該考慮經(jīng)濟(jì)方面的可行性。分析員應(yīng)該估計(jì)余下的每個(gè)可能的系統(tǒng)的開發(fā)成本和運(yùn)行費(fèi)用，并且估計(jì)相對于現(xiàn)有的系統(tǒng)而言這個(gè)系統(tǒng)可以節(jié)省的開支或可以增加的收入。 最后為每個(gè)在技術(shù)、操作和經(jīng)濟(jì)等方面都可行的系統(tǒng)制定實(shí)現(xiàn)進(jìn)度表，這個(gè)進(jìn)度表不需要制定得很詳細(xì)，通常只需要估計(jì)生命周期每個(gè)階段的工作量。
??根據(jù)可行性研究結(jié)果應(yīng)該決定的一個(gè)關(guān)鍵性問題是： 是否繼續(xù)進(jìn)行這項(xiàng)開發(fā)工程？分析員必須清楚地表明他對這個(gè)關(guān)鍵性決定的建議。如果分析員認(rèn)為值得繼續(xù)進(jìn)行這項(xiàng)開發(fā)工程，那么他應(yīng)該選擇一種最好的解法，并且說明選擇這個(gè)解決方案的理由。通?？蛻糁饕鶕?jù)經(jīng)濟(jì)上是否劃算決定是否投資于一項(xiàng)開發(fā)工程，因此分析員對于所推薦的系統(tǒng)必須進(jìn)行比較仔細(xì)的成本/效益分析。
6.草擬開發(fā)計(jì)劃
? ? 分析員應(yīng)該為所推薦的方案草擬一份開發(fā)計(jì)劃，除了制定工程進(jìn)度表之外還應(yīng)該估計(jì)對各類開發(fā)人員和各種資源的需要情況，應(yīng)該指明什么時(shí)候使用以及使用多長時(shí)間。此外還應(yīng)該估計(jì)系統(tǒng)生命周期每個(gè)階段的成本。最后應(yīng)該給出下一個(gè)階段(需求分析)的詳細(xì)進(jìn)度表和成本估計(jì)。
7.書寫文檔提交審查
? 應(yīng)該把上述可行性研究各個(gè)步驟的工作結(jié)果寫成清晰的文檔，請用戶、客戶組織的負(fù)責(zé)人及評審組審查，以決定是否繼續(xù)這項(xiàng)工程及是否接受分析員推薦的方案。
2.2軟件風(fēng)險(xiǎn)分析
軟件風(fēng)險(xiǎn)分析一般過程:
風(fēng)險(xiǎn)識別+風(fēng)險(xiǎn)預(yù)測+風(fēng)險(xiǎn)的駕馭與操控
2.2.1風(fēng)險(xiǎn)識別
下表展示了一些常見的風(fēng)險(xiǎn)：
| 常見風(fēng)險(xiǎn) | 內(nèi)容 |
| 產(chǎn)品規(guī)模風(fēng)險(xiǎn) | 與軟件總體規(guī)模相關(guān) |
| 商業(yè)影響風(fēng)險(xiǎn) | 與管理與市場約束相關(guān) |
| 與客戶相關(guān)風(fēng)險(xiǎn) | 與客戶素質(zhì)及通信能力相關(guān) |
| 過程風(fēng)險(xiǎn) | 與軟件定義和開發(fā)相關(guān) |
| 技術(shù)風(fēng)險(xiǎn) | 與軟件復(fù)雜性及系統(tǒng)所包含的技術(shù)成熟度相關(guān)，一般設(shè)計(jì)、實(shí)現(xiàn)、接口和維護(hù)等方面的問題。后果：例如：降低軟件開發(fā)質(zhì)量，延長交付時(shí)間等 |
| 開發(fā)環(huán)境風(fēng)險(xiǎn) | 開發(fā)工具的可用性與質(zhì)量 |
| 人員結(jié)構(gòu)和經(jīng)驗(yàn)風(fēng)險(xiǎn) | 參與開發(fā)人員總體技術(shù)水平及項(xiàng)目經(jīng)驗(yàn) |
| 項(xiàng)目風(fēng)險(xiǎn) | 在預(yù)算、進(jìn)度、人力、資源、客戶及需求等方面潛在的問題。后果：例如：項(xiàng)目成本提高，時(shí)間延長等 |
| 商業(yè)風(fēng)險(xiǎn) | 包括市場、商業(yè)策略、推銷策略等方面的風(fēng)險(xiǎn)，直接影響軟件的生存能力。 |
| 銷售風(fēng)險(xiǎn) | 銷售部門是否知道如何推銷這種軟件？ |
| 預(yù)算風(fēng)險(xiǎn) | 項(xiàng)目預(yù)算或參加人員有無保證？ |
| 管理風(fēng)險(xiǎn) | 有沒有因?yàn)檎n題內(nèi)容或人員的變動，是該項(xiàng)目失去管理層的支持？ |
| 策略風(fēng)險(xiǎn) | 建立的軟件是否符合公司的整體商業(yè)策略？ |
| 市場風(fēng)險(xiǎn) | 建立的軟件是否符合市場需求？ |
2.2.2風(fēng)險(xiǎn)預(yù)測（風(fēng)險(xiǎn)估計(jì)）
風(fēng)險(xiǎn)發(fā)生的可能性+風(fēng)險(xiǎn)可能產(chǎn)生的后果
該做什么?
1.建立風(fēng)險(xiǎn)可能性尺度
2.估計(jì)對產(chǎn)品和項(xiàng)目的影響
2.2.3風(fēng)險(xiǎn)的駕馭和監(jiān)控
2.3系統(tǒng)流程圖
定義：
系統(tǒng)流程圖是概括地描繪物理系統(tǒng)的傳統(tǒng)工具。
基本思想：
用圖形符號以黑盒子形式描繪組成系統(tǒng)的每個(gè)部件(程序、文檔、數(shù)據(jù)庫、人工過程等)。
系統(tǒng)流程圖表達(dá)的是數(shù)據(jù)在系統(tǒng)各部件之間流動的情況，而不是對數(shù)據(jù)進(jìn)行加工處理的控制過程，因此盡管系統(tǒng)流程圖的某些符號和程序流程圖的符號形式相同，但是它卻是物理數(shù)據(jù)流圖而不是程序流程圖。
符號：
1.基本符號
以概括的方式抽象地描繪一個(gè)實(shí)際系統(tǒng)時(shí)，僅僅使用下圖中列出的基本符號就足夠了：
2.系統(tǒng)符號
更具體地描述一個(gè)物理系統(tǒng)。利用系統(tǒng)符號可以把一個(gè)廣義的輸入輸出操作具體化為讀寫存儲在特殊設(shè)備上的文件（或數(shù)據(jù)庫），把抽象處理具體化為特定的程序或手工操作等。
?復(fù)雜系統(tǒng)，可分層描述。 分層步驟如下：? ? ??
1.首先用一張高層次的系統(tǒng)流程圖描繪系統(tǒng)總體概貌，表明系統(tǒng)的關(guān)鍵功能。
2.然后分別把每個(gè)關(guān)鍵功能擴(kuò)展到適當(dāng)?shù)脑敿?xì)程度，畫在單獨(dú)的一頁紙上。
一道例題：
該裝配廠使用一臺小型計(jì)算機(jī)處理更新庫存清單主文件和產(chǎn)生訂貨報(bào)告的任務(wù)。零件庫存量的每一次變化稱為一個(gè)事務(wù)，由放在倉庫中的CRT終端輸入到計(jì)算機(jī)中；系統(tǒng)中的庫存清單程序?qū)κ聞?wù)進(jìn)行處理，更新存儲在磁盤上的庫存清單主文件，并且把必要的訂貨信息寫在磁帶上。最后，每天由報(bào)告生成程序讀一次磁帶，并且打印出訂貨報(bào)告。
解：
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?2.4數(shù)據(jù)流圖（結(jié)構(gòu)化分析方法）
概念：
數(shù)據(jù)流圖(DFD)是一種圖形化技術(shù)，它描繪信息流和數(shù)據(jù)從輸入移動到輸出的過程中所經(jīng)受的變換。
數(shù)據(jù)流四中基本符號：
?數(shù)據(jù)流圖中的附加符號：
?數(shù)據(jù)流圖中的注意事項(xiàng)：
1.通常在數(shù)據(jù)流圖中忽略出錯(cuò)處理。
總結(jié)
以上是生活随笔為你收集整理的《软件工程导论（第六版）》第二章 可行性分析与研究的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： PyTorch实现 | 车牌OCR识别，
- 下一篇： 动态代理demo