1、精選優質文檔-傾情為你奉上軟件項目風險分析報告(說明：本文為word格式，下載后可自由編輯)本文主要針對軟件開發涉及到的風險，包括在軟件開發周期過程中可能出現的風險以及軟件實施過程中外部環境的變化可能引起的風險等進行評估。在文中對所提到的風險都一一做了詳細的分析，并提出了相應的風險回避措施。由于風險是在項目開始之后才開始對項目的開發起負面的影響，所以風險分析的不足，或是風險回避措施不得力，都很有可能造成軟件開發的失敗。風險分析是在事前的一種估計，憑借一定的技術手段和豐富的經驗，基本能夠對項目的風險做出比較準確的估計，經過慎重的考慮提出可行的風險回避措施，是避免損失的重要環節。1 主要風險綜述任

2、何軟件的開發，其主要風險均來自于兩個方面，一是軟件管理，二是軟件體系結構。軟件產品的開發是工程技術與個人創作的有機結合。軟件開發是人的集體智慧按照工程化的思想進行發揮的過程。軟件管理是保證軟件開發工程化的手段。軟件體系結構的合理程度是取決于集體智慧發揮的程度和經驗的運用。1.1 軟件管理將影響到軟件的下列因素：軟件是否能夠按工期的要求完成：軟件的工期常常是制約軟件質量的主要因素。很多情況下，軟件開發商在工期的壓力下，放棄文檔的書寫，組織，結果在工程的晚期，大量需要文檔進行協調的工作時，致使軟件進度越來越慢。軟件的開發不同于其他的工程，在不同的工程階段，需要的人員不同，需要配合的方面也不同，所有

3、這些都需要行之有效的軟件管理的保證。軟件需求的調研是否深入透徹：軟件的需求是確保軟件正確反映用戶的對軟件使用的重要的文檔，探討軟件需求是軟件開發的起始點，但軟件的需求卻會貫穿整個軟件的開發過程，軟件管理需要對軟件需求的變化進行控制和管理，一方面保證軟件需求的變化不至于造成軟件工程的一改再改而無法按期完成；同時又要保證開發的軟件能夠為用戶所接受。軟件管理需要控制軟件的每個階段進行的成度，不能過細造成時間的浪費，也不能過粗，造成軟件缺陷。軟件的實現技術手段是否能夠同時滿足性能要求：軟件的構造需要對軟件構造過程中的使用的各種技術進行評估。軟件構造技術通常是這樣：最成熟的技術，往往不能體現最好的軟件性

4、能；先進的技術，往往人員對其熟悉程度不夠，對其中隱含的缺陷不夠明了。軟件管理在制定軟件開發計劃和定義里程碑時必須考慮這些因素，并做出合理的權衡決策。軟件質量體系是否能夠被有效地保證：任何軟件管理忽略軟件質量監督環節都將對軟件的生產構成巨大的風險。而制定卓有成效的軟件質量監督體系，是任何軟件開發組織必不可少的。軟件質量保證體系是軟件開發成為可控制過程的基礎，也是開發商和用戶進行交流的基礎和依據。1.2 軟件體系結構影響到軟件的如下質量因素：軟件的可伸縮性：是指軟件在不進行修改的情況下適應不同的工作環境的能力。由于硬件的飛速發展和軟件開發周期較長的矛盾，軟件升級的需要顯得非常迫切。如果軟件的升級和

5、移植非常困難，軟件的生命期必定很短，使得化費巨大人力物力開發出的軟件系統只能在低性能的硬件或網絡上運行，甚至被廢棄不用，造成巨大的浪費。軟件的可維護性：軟件的維護也是必然的事情，為了保證軟件的較長使用壽命，軟件就必須適應不斷的業務需求變化，根據業務需求的變化對軟件進行修改。修改的成本和周期都直接和軟件的體系結構相關。一個好的軟件體系結構可以盡可能地將系統的變化放在系統的配置上，即軟件代碼無需修改，僅僅是在系統提供的配置文件中進行適當的修改，然后軟件重新加載進入運行狀態，就完成了系統部分功能和性能要求的變化。對于重大改動，需要打開源代碼進行修改的，也僅僅是先繼承原先的代碼，然后用新的功能接替原先

6、的調用接口，這樣將把軟件改動量減小到最低。軟件易用性：軟件的易用性是影響軟件是否被用戶接受的關鍵之關鍵因素。在軟件產品中，設計復雜，功能強大而完備，但因為操作繁復而被擱置者屢見不鮮。造成的主要原因在于缺乏軟件開發中軟件體系結構的宏觀把握能力。另一方面，缺乏有效的手段進行軟件需求的確定和對潛在需求的挖掘。2 項目管理的風險軟件項目管理的風險來自于軟件項目自身的特點：軟件產品不可見：開發的進展以及軟件的質量是否符合要求難于度量，從而使軟件的管理難于把握。軟件的生產過程不存在絕對正確的過程形式：可以肯定的是不同的軟件開發項目應當采用不同的或者說是有針對性的軟件開發過程，而真正合適的軟件開發過程是在軟

7、件項目的開發完成才能明了的。因此項目開發之初只能根據項目的特點和開發經驗進行選擇，并在開發過程中不斷的調整。大型軟件項目往往是一次性的。以往的經驗可以被借鑒的地方不多。回避和控制軟件管理風險的唯一辦法就是設立監督制度，項目開發中任何較大的決定都必須有主要技術環節甚至是由用戶參與進行的。在該項目中項目監督由項目開發中的質量監督組來實施。一般參與軟件開發的人員（包括管理者和技術人員）和其責任進行分析如下：參與者項目經理1人主要職責：進行全局把握，側重于項目的商務方面，充當項目組同客戶正式交流的接口環節。項目負責人1人主要職責：制定項目開發計劃和開發策略，參與項目核心系統的分析設計，同時努力保證開發

8、計劃的按時完成和開發策略的真正貫徹落實。領域專家1或2人主要職責：在軟件分析階段幫助分析人員界定系統實現邊界和實現的功能，對特定檢測點進行算法審核，同時對測試策略和軟件操作界面提出參考意見。質量監督組1或2人主要職責：編制軟件質量控制計劃，并負責落實；控制必要文檔的生產，通過文檔，監督項目實施過程中軟件的質量，并產生軟件質量報告，提請項目經理和項目負責人審閱；對于項目中出現的質量問題，主持召開質量復審會議。系統分析員1或2人主要職責：協同項目負責人進行軟件系統的分析和設計工作，書寫軟件需求分析和系統設計相關文檔。在軟件實現階段進行測試策略的編制和對性能測試的指導。程序員2或3人主要職責：協助分

9、析人員進行詳細設計，和軟件系統的代碼實現，并進行適當的白盒測試。測試員2或3人主要職責：已經實現的軟件組件、構件或系統進行正確性驗證測試，整合后的系統的性能測試等。書寫測試報告和測試統計報告提請質量監督組復審。技術支持2或3人主要職責：協同系統分析人員聽取用戶需求，對需求分析進行參考性復審。協同測試人員進行測試，書寫操作手冊和在線幫助，在項目交付用戶之后進行跟蹤服務。文檔組1或2人主要職責：對各部門產生的文檔進行格式規范、版本編號和控制、存檔文件的檢索；協助質量監督組進行軟件質量監督。通過適當的人員配備和職責劃分，能有效的降低軟件開發在后期的失控的可能性，和軟件對關鍵人員的依賴性。軟件技術風險

10、本系統擬訂采用的兩個重大的軟件技術是面向對象的構件和基于微軟的COM組件技術。組件和構件技術都是為了提高軟件的可靠性和軟件的可擴展性而采用的技術手段。從技術成熟度上說不存在風險，但為了實現良好的軟件構架和穩定的組件，與傳統開發方法比較，有相當的多的額外工作需要做，這會給項目工期帶來較大的風險。回避和控制這部分風險的辦法是在項目進行的過程不斷的對該階段進行風險估計和指定有效的里程碑。同時采用范例方式提高開發人員的構件組件的分析識別能力，適時調整構件組件的數量和粒度。軟件過程風險軟件需求階段的風險軟件的開發是以用戶的需求開始，在大多數情況下，用戶需求要靠軟件開發方誘導才能保證需求的完整，再以書面的

11、形式形成用戶需求這一重要的文檔。需求分析更多的是開發方確認需求的可行性和一致性的過程，在此階段需要和用戶進行廣泛的交流和確認。需求和需求分析的任何疏漏造成的損失會在軟件系統的后續階段被一級一級地放大，因此本階段的風險最大。設計階段的風險設計的主要目的在于軟件的功能正確的反映了需求。可見需求的不完整和對需求分析的不完整和錯誤，在設計階段被成倍地放大。設計階段的主要任務是完成系統體系結構的定義，使之能夠完成需求階段的即定目標；另一方面也是檢驗需求的一致性和需求分析的完整性和正確性。設計本身的風險主要來自于系統分析人員。分析人員在設計系統結構時過于定制，系統的可擴展性較弱，會給后期維護帶來巨大的負擔

12、，和維護成本的激增。對用戶來說系統的使用比例會有明顯的折扣，甚至造成軟件壽命過短。反之，軟件結構的過于靈活和通用，必然引起軟件實現的難度增加，系統的復雜度會上升，這又會在實現和測試階段帶來風險，系統的穩定性也會受到影響。從另一個角度上看，業務規則的變化，或說用戶需求和將來軟件運行環境的變化都是必然的情況，目前軟件設計的所謂通用性是否就能很好的適應將來需求和運行環境的的變化，是需要認真折衷的。這種折中也蘊涵著很大的風險。設計階段蘊涵的另一種風險來自于設計文檔。文檔的不健全不僅會造成實現階段的困難，更會在后期的測試和維護造成災難性的后果，例如根本無法對軟件系統進行版本升級，甚至是發現的簡單錯誤都無

13、從更正。實現階段引入的風險軟件的實現從某種意義上講是軟件代碼的生產。原代碼本身也是文檔的一部分，同時它又是將來運行于計算機系統之上的實體。源代碼書寫的規范性，可讀性是該階段的主要風險來源。規范的代碼生產會把屬于程序員自身個性風格的成分引入代碼的比例降到最低限度，從而減小了系統整合的風險。維護階段的風險軟件維護包含兩個主要的維護階段，一個是軟件生產完畢到軟件試運行階段的維護，這個階段是一種實環境的測試性維護，其主要目的是發現在測試環境中不能或未發現的問題；另一個階段是當軟件的運行不再能適應用戶業務需求或是用戶的運行環境（包括硬件平臺，軟件環境等）時進行的軟件維護，具體可能是軟件的版本升級或軟件移

14、植等。從軟件工程的角度看，軟件維護費用約占總費用的55%70%，系統越大，該費用越高。對系統可維護性的輕視是大型軟件系統的最大風險。在軟件漫長的運營期內，業務規則肯定會不斷發展，科學的解決此問題的做法是不斷對軟件系統進行版本升級，在確保可維護性的前提下逐步擴展系統。在軟件系統運營期間，主要的風險源自于技術支持體系的無效運轉。科學的方法是有一支客戶支持隊伍不斷收集運行中發現的問題，并將解決問題的方法傳授給軟件系統的所有使用者。項目風險表風險評估表中所提到的風險是一般項目在開發過程中都客觀存在的，表中所列出的風險系數是指在不對風險進行深入的分析和有效的規避的情況下，該風險項發生的概率。比如軟件產品的設計目標是運行十年，體系結構不合理的風險是40%的含義是，如果不對系統進行深入的分析，未采用最合理的軟件