本文檔的范圍和目的
本文主要針對軟件開(kāi)發(fā)涉及到的風(fēng)險，包括在軟件開(kāi)發(fā)周期過(guò)程中可能出現的風(fēng)險以及軟件實(shí)
施過(guò)程中外部環(huán)境的變化可能引起的風(fēng)險等進(jìn)行評估。在文中對所提到的風(fēng)險都一一做了詳細的分
析，并提出了相應的風(fēng)險回避措施。
由于風(fēng)險是在項目開(kāi)始之后才開(kāi)始對項目的開(kāi)發(fā)起負面的影響，所以風(fēng)險分析的不足，或是風(fēng)
險回避措施不得力，都很有可能造成軟件開(kāi)發(fā)的失敗。風(fēng)險分析是在事前的一種估計，憑借一定的
技術(shù)手段和豐富的經(jīng)驗，基本能夠對項目的風(fēng)險做出比較準確的估計，經(jīng)過(guò)慎重的考慮提出可行的
風(fēng)險回避措施，是避免損失的重要環(huán)節。
主要風(fēng)險綜述
任何軟件的開(kāi)發(fā)，其主要風(fēng)險均來(lái)自于兩個(gè)方面，一是軟件管理，二是軟件體系結構。軟件產(chǎn)
品的開(kāi)發(fā)是工程技術(shù)與個(gè)人創(chuàng )作的有機結合。軟件開(kāi)發(fā)是人的集體智慧按照工程化的思想進(jìn)行發(fā)揮
的過(guò)程。軟件管理是保證軟件開(kāi)發(fā)工程化的手段。軟件體系結構的合理程度是取決于集體智慧發(fā)揮
的程度和經(jīng)驗的運用。
軟件管理將影響到軟件的下列因素：
軟件是否能夠按工期的要求完成：軟件的工期常常是制約軟件質(zhì)量的主要因素。很多情況下，
軟件開(kāi)發(fā)商在工期的壓力下，放棄文檔的書(shū)寫(xiě)，組織，結果在工程的晚期，大量需要文檔進(jìn)行協(xié)調
的工作時(shí)，致使軟件進(jìn)度越來(lái)越慢。軟件的開(kāi)發(fā)不同于其他的工程，在不同的工程階段，需要的人
員不同，需要配合的方面也不同，所有這些都需要行之有效的軟件管理的保證。
軟件需求的調研是否深入透徹：軟件的需求是確保軟件正確反映用戶(hù)的對軟件使用的重要的文
檔，探討軟件需求是軟件開(kāi)發(fā)的起始點(diǎn)，但軟件的需求卻會(huì )貫穿整個(gè)軟件的開(kāi)發(fā)過(guò)程，軟件管理需
要對軟件需求的變化進(jìn)行控制和管理，一方面保證軟件需求的變化不至于造成軟件工程的一改再改
而無(wú)法按期完成；同時(shí)又要保證開(kāi)發(fā)的軟件能夠為用戶(hù)所接受。軟件管理需要控制軟件的每個(gè)階段
進(jìn)行的成度，不能過(guò)細造成時(shí)間的浪費，也不能過(guò)粗，造成軟件缺陷。
軟件的實(shí)現技術(shù)手段是否能夠同時(shí)滿(mǎn)足性能要求：軟件的構造需要對軟件構造過(guò)程中的使用的
各種技術(shù)進(jìn)行評估。軟件構造技術(shù)通常是這樣：最成熟的技術(shù)，往往不能體現最好的軟件性能；先
進(jìn)的技術(shù)，往往人員對其熟悉程度不夠，對其中隱含的缺陷不夠明了。軟件管理在制定軟件開(kāi)發(fā)計
劃和定義里程碑時(shí)必須考慮這些因素，并做出合理的權衡決策。
軟件質(zhì)量體系是否能夠被有效地保證：任何軟件管理忽略軟件質(zhì)量監督環(huán)節都將對軟件的生產(chǎn)
構成巨大的風(fēng)險。而制定卓有成效的軟件質(zhì)量監督體系，是任何軟件開(kāi)發(fā)組織必不可少的。軟件質(zhì)
量保證體系是軟件開(kāi)發(fā)成為可控制過(guò)程的基礎，也是開(kāi)發(fā)商和用戶(hù)進(jìn)行交流的基礎和依據。
軟件體系結構影響到軟件的如下質(zhì)量因素：
軟件的可伸縮性：是指軟件在不進(jìn)行修改的情況下適應不同的工作環(huán)境的能力。由于硬件的飛
速發(fā)展和軟件開(kāi)發(fā)周期較長(cháng)的矛盾，軟件升級的需要顯得非常迫切。如果軟件的升級和移植非常困
難，軟件的生命期必定很短，使得化費巨大人力物力開(kāi)發(fā)出的軟件系統只能在低性能的硬件或網(wǎng)絡(luò )
上運行，甚至被廢棄不用，造成巨大的浪費。
軟件的可維護性：軟件的維護也是必然的事情，為了保證軟件的較長(cháng)使用壽命，軟件就必須
適應不斷的業(yè)務(wù)需求變化，根據業(yè)務(wù)需求的變化對軟件進(jìn)行修改。修改的成本和周期都直接和軟件
的體系結構相關(guān)。一個(gè)好的軟件體系結構可以盡可能地將系統的變化放在系統的配置上，即軟件代
碼無(wú)需修改，僅僅是在系統提供的配置文件中進(jìn)行適當的修改，然后軟件重新加載進(jìn)入運行狀態(tài)，
就完成了系統部分功能和性能要求的變化。對于重大改動(dòng)，需要打開(kāi)源代碼進(jìn)行修改的，也僅僅是
先繼承原先的代碼，然后用新的功能接替原先的調用接口，這樣將把軟件改動(dòng)量減小到最低。
軟件易用性：軟件的易用性是影響軟件是否被用戶(hù)接受的關(guān)鍵之關(guān)鍵因素。在軟件產(chǎn)品中，設
計復雜，功能強大而完備，但因為操作繁復而被擱置者屢見(jiàn)不鮮。造成的主要原因在于缺乏軟件開(kāi)
發(fā)中軟件體系結構的宏觀(guān)把握能力。另一方面，缺乏有效的手段進(jìn)行軟件需求的確定和對潛在需求
的挖掘。
項目管理的風(fēng)險
軟件項目管理的風(fēng)險來(lái)自于軟件項目自身的特點(diǎn)：
軟件產(chǎn)品不可見(jiàn)：開(kāi)發(fā)的進(jìn)展以及軟件的質(zhì)量是否符合要求難于度量，從而使軟件的管理難于
把握。
軟件的生產(chǎn)過(guò)程不存在絕對正確的過(guò)程形式：可以肯定的是不同的軟件開(kāi)發(fā)項目應當采用不
同的或者說(shuō)是有針對性的軟件開(kāi)發(fā)過(guò)程，而真正合適的軟件開(kāi)發(fā)過(guò)程是在軟件項目的開(kāi)發(fā)完成才能
明了的。因此項目開(kāi)發(fā)之初只能根據項目的特點(diǎn)和開(kāi)發(fā)經(jīng)驗進(jìn)行選擇，并在開(kāi)發(fā)過(guò)程中不斷的調整
。
大型軟件項目往往是"一次性"的。以往的經(jīng)驗可以被借鑒的地方不多?；乇芎涂刂栖浖芾?
風(fēng)險的唯一辦法就是設立監督制度，項目開(kāi)發(fā)中任何較大的決定都必須有主要技術(shù)環(huán)節甚至是由用
戶(hù)參與進(jìn)行的。在該項目中項目監督由項目開(kāi)發(fā)中的質(zhì)量監督組來(lái)實(shí)施。
一般參與軟件開(kāi)發(fā)的人員（包括管理者和技術(shù)人員）和其責任進(jìn)行分析如下：
參與者
項目經(jīng)理1人
主要職責：進(jìn)行全局把握，側重于項目的商務(wù)方面，充當項目組同客戶(hù)正式交流的接口環(huán)節。
項目負責人1人
主要職責：制定項目開(kāi)發(fā)計劃和開(kāi)發(fā)策略，參與項目核心系統的分析設計，同時(shí)努力保證開(kāi)發(fā)
計劃的按時(shí)完成和開(kāi)發(fā)策略的真正貫徹落實(shí)。
領(lǐng)域專(zhuān)家1或2人
主要職責：在軟件分析階段幫助分析人員界定系統實(shí)現邊界和實(shí)現的功能，對特定檢測點(diǎn)進(jìn)行
算法審核，同時(shí)對測試策略和軟件操作界面提出參考意見(jiàn)。
質(zhì)量監督組1或2人
主要職責：編制軟件質(zhì)量控制計劃，并負責落實(shí)；控制必要文檔的生產(chǎn)，通過(guò)文檔，監督項目
實(shí)施過(guò)程中軟件的質(zhì)量，并產(chǎn)生軟件質(zhì)量報告，提請項目經(jīng)理和項目負責人審閱；對于項目中出現
的質(zhì)量問(wèn)題，主持召開(kāi)質(zhì)量復審會(huì )議。
系統分析員1或2人
主要職責：協(xié)同項目負責人進(jìn)行軟件系統的分析和設計工作，書(shū)寫(xiě)軟件需求分析和系統設計相
關(guān)文檔。在軟件實(shí)現階段進(jìn)行測試策略的編制和對性能測試的指導。
程序員2或3人
主要職責：協(xié)助分析人員進(jìn)行詳細設計，和軟件系統的代碼實(shí)現，并進(jìn)行適當的白盒測試。
測試員2或3人
主要職責：已經(jīng)實(shí)現的軟件組件、構件或系統進(jìn)行正確性驗證測試，整合后的系統的性能測
試等。書(shū)寫(xiě)測試報告和測試統計報告提請質(zhì)量監督組復審。
技術(shù)支持2或3人
主要職責：協(xié)同系統分析人員聽(tīng)取用戶(hù)需求，對需求分析進(jìn)行參考性復審。協(xié)同測試人員進(jìn)行
測試，書(shū)寫(xiě)操作手冊和在線(xiàn)幫助，在項目交付用戶(hù)之后進(jìn)行跟蹤服務(wù)。
文檔組1或2人
主要職責：對各部門(mén)產(chǎn)生的文檔進(jìn)行格式規范、版本編號和控制、存檔文件的檢索；協(xié)助質(zhì)量
監督組進(jìn)行軟件質(zhì)量監督。 通過(guò)適當的人員配備和職責劃分，能有效的降低軟件開(kāi)發(fā)在后期的失
控的可能性，和軟件對關(guān)鍵人員的依賴(lài)性。
軟件技術(shù)風(fēng)險
本系統擬訂采用的兩個(gè)重大的軟件技術(shù)是面向對象的構件和基于微軟的COM組件技術(shù)。組件和
構件技術(shù)都是為了提高軟件的可靠性和軟件的可擴展性而采用的技術(shù)手段。從技術(shù)成熟度上說(shuō)不存
在風(fēng)險，但為了實(shí)現良好的軟件構架和穩定的組件，與傳統開(kāi)發(fā)方法比較，有相當的多的額外工作
需要做，這會(huì )給項目工期帶來(lái)較大的風(fēng)險。
回避和控制這部分風(fēng)險的辦法是在項目進(jìn)行的過(guò)程不斷的對該階段進(jìn)行風(fēng)險估計和指定有效的
里程碑。同時(shí)采用"范例"方式提高開(kāi)發(fā)人員的構件組件的分析識別能力，適時(shí)調整構件組件的數量
和粒度。
軟件過(guò)程風(fēng)險
軟件需求階段的風(fēng)險
軟件的開(kāi)發(fā)是以用戶(hù)的需求開(kāi)始，在大多數情況下，用戶(hù)需求要靠軟件開(kāi)發(fā)方誘導才能保證需
求的完整，再以書(shū)面的形式形成《用戶(hù)需求》這一重要的文檔。需求分析更多的是開(kāi)發(fā)方確認需求
的可行性和一致性的過(guò)程，在此階段需要和用戶(hù)進(jìn)行廣泛的交流和確認。需求和需求分析的任何疏
漏造成的損失會(huì )在軟件系統的后續階段被一級一級地放大，因此本階段的風(fēng)險最大。
設計階段的風(fēng)險
設計的主要目的在于軟件的功能正確的反映了需求?？梢?jiàn)需求的不完整和對需求分析的不完整
和錯誤，在設計階段被成倍地放大。設計階段的主要任務(wù)是完成系統體系結構的定義，使之能夠完
成需求階段的即定目標；另一方面也是檢驗需求的一致性和需求分析的完整性和正確性。
設計本身的風(fēng)險主要來(lái)自于系統分析人員。分析人員在設計系統結構時(shí)過(guò)于定制，系統的可擴
展性較弱，會(huì )給后期維護帶來(lái)巨大的負擔，和維護成本的激增。對用戶(hù)來(lái)說(shuō)系統的使用比例會(huì )有明
顯的折扣，甚至造成軟件壽命過(guò)短。反之，軟件結構的過(guò)于靈活和通用，必然引起軟件實(shí)現的難度
增加，系統的復雜度會(huì )上升，這又會(huì )在實(shí)現和測試階段帶來(lái)風(fēng)險，系統的穩定性也會(huì )受到影響。從
另一個(gè)角度上看，業(yè)務(wù)規則的變化，或說(shuō)用戶(hù)需求和將來(lái)軟件運行環(huán)境的變化都是必然的情況，目
前軟件設計的所謂"通用性"是否就能很好的適應將來(lái)需求和運行環(huán)境的的變化，是需要認真折衷的
。這種折中也蘊涵著(zhù)很大的風(fēng)險。
設計階段蘊涵的另一種風(fēng)險來(lái)自于設計文檔。文檔的不健全不僅會(huì )造成實(shí)現階段的困難，更會(huì )
在后期的測試和維護造成災難性的后果，例如根本無(wú)法對軟件系統進(jìn)行版本升級，甚至是發(fā)現的簡(jiǎn)
單錯誤都無(wú)從更正。
實(shí)現階段引入的風(fēng)險
軟件的實(shí)現從某種意義上講是軟件代碼的生產(chǎn)。原代碼本身也是文檔的一部分，同時(shí)它又是將
來(lái)運行于計算機系統之上的實(shí)體。源代碼書(shū)寫(xiě)的規范性，可讀性是該階段的主要風(fēng)險來(lái)源。規范的
代碼生產(chǎn)會(huì )把屬于程序員自身個(gè)性風(fēng)格的成分引入代碼的比例降到最低限度，從而減小了系統整合
的風(fēng)險。
維護階段的風(fēng)險
軟件維護包含兩個(gè)主要的維護階段，一個(gè)是軟件生產(chǎn)完畢到軟件試運行階段的維護，這個(gè)階段
是一種實(shí)環(huán)境的測試性維護，其主要目的是發(fā)現在測試環(huán)境中不能或未發(fā)現的問(wèn)題；另一個(gè)階段是
當軟件的運行不再能適應用戶(hù)業(yè)務(wù)需求或是用戶(hù)的運行環(huán)境（包括硬件平臺，軟件環(huán)境等）時(shí)進(jìn)行
的軟件維護，具體可能是軟件的版本升級或軟件移植等。
從軟件工程的角度看，軟件維護費用約占總費用的55%~70%，系統越大，該費用越高。對系統
可維護性的輕視是大型軟件系統的最大風(fēng)險。在軟件漫長(cháng)的運營(yíng)期內，業(yè)務(wù)規則肯定會(huì )不斷發(fā)展，
科學(xué)的解決此問(wèn)題的做法是不斷對軟件系統進(jìn)行版本升級，在確?？删S護性的前提下逐步擴展系統
。
在軟件系統運營(yíng)期間，主要的風(fēng)險源自于技術(shù)支持體系的無(wú)效運轉?？茖W(xué)的方法是有一支客戶(hù)
支持隊伍不斷收集運行中發(fā)現的問(wèn)題，并將解決問(wèn)題的方法傳授給軟件系統的所有使用者。
項目風(fēng)險表
風(fēng)險評估表中所提到的風(fēng)險是一般項目在開(kāi)發(fā)過(guò)程中都客觀(guān)存在的，表中所列出的風(fēng)險系數是
指在不對風(fēng)險進(jìn)行深入的分析和有效的規避的情況下，該風(fēng)險項發(fā)生的概率。比如軟件產(chǎn)品的設計
目標是運行十年，體系結構不合理的風(fēng)險是40%的含義是，如果不對系統進(jìn)行深入的分析，未采用
最合理的軟件技術(shù)進(jìn)行設計，則生產(chǎn)出一個(gè)不具備可擴展性的軟件系統的概率是40%。由于客戶(hù)公
司是仍將不斷發(fā)展的，在十年內，該軟件系統都能滿(mǎn)足公司運營(yíng)要求的可能性極低。由此而可能產(chǎn)
生的災難性后果是公司在業(yè)務(wù)發(fā)展的時(shí)候，必須重新開(kāi)發(fā)新系統。
向客戶(hù)提供風(fēng)險評估，是按照國際慣例進(jìn)行的例行操作，一方面讓客戶(hù)對潛在的風(fēng)險有更充分
的了解，表明公司誠信 為本的態(tài)度，另一方面也用以鞭策和激勵全體開(kāi)發(fā)人員嚴格執行開(kāi)發(fā)標準
，共同監督項目開(kāi)發(fā)過(guò)程，努力避免風(fēng)險的發(fā)生。
--------------------------------------------------
風(fēng)險 概率 影響
--------------------------------------------------
規模估計過(guò)低 60% 嚴重的
交付期限太緊張 50% 嚴重的
用戶(hù)需求變化頻繁 75% 嚴重的
技術(shù)達不到預期效果 30% 輕微的
質(zhì)量保證體系的措施實(shí)施不利 60% 嚴重的
軟件體系結構設計不合理 40% 災難性的
人員流動(dòng) 30% 嚴重的
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
