第一篇：軟件開發(fā)項目風(fēng)險管理的幾點體會

參與過大型軟件項目的人都會認識到許多事情都可能出錯，一但出錯就可能給項目帶來危害、損失或其它不利影響。風(fēng)險是在項目中發(fā)生的一系列事件或不利結(jié)果的可能性。軟件開發(fā)是一項高風(fēng)險的活動，在項目開發(fā)過程的任何一個階段都可能存在風(fēng)險。采取積極的風(fēng)險管理方式，可以使項目進程更加平穩(wěn)，可以獲得很高的跟蹤和控制項目的能力，可以規(guī)避、轉(zhuǎn)移風(fēng)險，或緩解風(fēng)險帶來的不利影響。風(fēng)險管理是對項目風(fēng)險進行識別、分析、應(yīng)對和監(jiān)控的過程，是項目管理中很重要的管理活動，有效的實施軟件風(fēng)險管理是軟件項目開發(fā)工作順利完成的保證。

風(fēng)險管理的達成必須包括三個要素：首先，在項目開發(fā)計劃中必須制定風(fēng)險管理計劃；第二，在項目預(yù)算中必須包含解決風(fēng)險所需的經(jīng)費；第三，評估風(fēng)險時，風(fēng)險的影響也必須納入項目計劃中。

下面就軟件開發(fā)過程中經(jīng)常發(fā)生的風(fēng)險，談?wù)勎覀儾扇〉念A(yù)防措施。

2.需求不明確

需求不明確是軟件開發(fā)過程中經(jīng)?？赡苡龅降膯栴}，這類問題往往表現(xiàn)在需求范圍未界定、需求未細化、需求描述不清楚、需求遺漏、需求互相矛盾等多個方面。在軟件開發(fā)過程的生命周期各階段中，需求不明確所造成的浪費是最大的，必須盡早盡可能解決。確定用戶需求是件非常困難的事情，我們常常從以下幾個方面著手處理需求不明確問題：

(1)讓用戶參與開發(fā)

提供一個協(xié)作開發(fā)環(huán)境，讓用戶參與開發(fā)過程。如果條件不允許，至少應(yīng)該在每次迭代的需求分析和系統(tǒng)測試階段，讓客戶能夠參與開發(fā)。

在選擇參與開發(fā)過程的用戶時，一方面，要盡可能爭取精通業(yè)務(wù)或計算機技術(shù)的用戶參與。另一方面，如果開發(fā)的產(chǎn)品要在不同規(guī)模、不同類型的企業(yè)應(yīng)用，應(yīng)該選擇具有代表性的用戶參與。

僅僅讓用戶參與是不夠的，應(yīng)該采取一定的激勵措施，提高用戶參與的積極性。

(2)開發(fā)用戶界面原型

用戶通常不善于精確描述自己的業(yè)務(wù)需求，系統(tǒng)分析員需要借助白板、白紙等溝通方式，幫助用戶清楚表述需求。然后，開發(fā)一個用戶界面原型，以便用戶確認需求。用戶界面原型的作用僅僅是收集用戶需求，不應(yīng)該再作它用，也不要給用戶造成系統(tǒng)快要實現(xiàn)的錯覺。

(3)需求討論會議

對于用戶分布廣、用戶量大的項目，要全面收集用戶需求，往往很困難，通常采取需求

研計會議方式進行需求確認。通過在會議前幾周調(diào)查各地、各部門用戶需求意見，然后集中各地或各部門的用戶代表，舉辦一次需求研討會，通過會議方式收集需求。本方法適合于具有一定信息系統(tǒng)使用經(jīng)驗的用戶。

(4)強化需求分析與評審

首先，需求分析是項目成功的基礎(chǔ)，需要引起足夠的重視，并分配充足的時間和人力，要讓有經(jīng)驗的系統(tǒng)分析員負責(zé)，切忌讓項目新手或程序員負責(zé)。其次，要進行需求評審，盡可能讓用戶參與需求評審，不要讓需求評審流于行式。第三，也是最重要的一點，通過評審的需求規(guī)格說明書，要讓用戶方簽字，并作為項目合同的附件，對雙方都具有約束力。在公司內(nèi)部要將通過評審的需求規(guī)格說明書，納入配置管理。

3.項目缺少可見性

當(dāng)一個項目經(jīng)理或一名開發(fā)者說已經(jīng)完成了80%的任務(wù)，您必須保持審慎的態(tài)度。因為剩下的20%可能還需要80%的時間，甚至永遠都不能完成[1]。軟件開發(fā)項目，往往在項目進度和軟件質(zhì)量方面缺少可見性，項目越缺少可見性，項目就越難以控制，項目就越有可能失敗。我們可以通過迭代開發(fā)、技術(shù)評審、持續(xù)集成來增強項目的可見性。

(1)n 迭代開發(fā)

采用迭代的開發(fā)模型，將產(chǎn)品的交付過程分為多個階段，按照功能遞增式交付。以下是一些典型的迭代：

一次簡短的先期迭代，以建立規(guī)模和前景并確定商業(yè)理由；

一次精化迭代，其間將為穩(wěn)定的構(gòu)架劃定基線；

一次構(gòu)建迭代，其間將實現(xiàn)用例并充實構(gòu)架；

幾次產(chǎn)品化迭代，將產(chǎn)品轉(zhuǎn)移到用戶群。

每次迭代，都要充分接收用戶的評審意見，以便為自我糾正。漸近式的功能交付，有利于降低開發(fā)人員的壓力，增加用戶的滿意度，有利于增強項目的可見性，是最好的進展報告。

(2)技術(shù)評審

技術(shù)評審是確保軟件質(zhì)量的重要環(huán)節(jié)，技術(shù)評審包括代碼走查、會議評審和同行專家評審。代碼走審可以是開發(fā)人員之間的交叉審查，或者是高級開發(fā)人員對普通開發(fā)人員的審查；會議評審一般應(yīng)至少每兩周進行一次，每次評審時間不宜太長；同行專家評審包括技術(shù)和業(yè)務(wù)兩個方面的專家，經(jīng)常性地讓精通業(yè)務(wù)的用戶專家參與項目評審，是項目成功的重要保證。

另外，充分利用質(zhì)量審查的工具軟件，也有利于提高代碼質(zhì)量。例如：在Eclipse開發(fā)環(huán)境中，可以集成Findbug、Checkstyle、PMD插件檢查代碼編寫質(zhì)量。

(3)持續(xù)集成持續(xù)集成能夠把最終的一次大規(guī)模的集成調(diào)試過程分散到項目開發(fā)時間表的每一周、每一天、甚至每個小時。讓項目中的各個人員都能夠隨時掌握當(dāng)前的整體進度，并迅速發(fā)現(xiàn)集成過程中出現(xiàn)的問題并進行解決[1]。

開發(fā)小組應(yīng)制定持續(xù)集成的制度，一般情況下每日構(gòu)建一次，可以利用Ant等構(gòu)建工具進行Java應(yīng)用程序的構(gòu)建。小組成員應(yīng)在每個功能開發(fā)完成后，及時向版本控制系統(tǒng)（如CVS）提交代碼，而且不應(yīng)該向版本控制系統(tǒng)提交有問題（編譯通不過）的代碼。

每日構(gòu)建、持續(xù)集成，讓項目進度跟蹤工作更加容易。當(dāng)項目小組每天重新編譯系統(tǒng)時，已完成與未完成的功能清楚可見，小組成員能夠簡單地從軟件的表現(xiàn)知道距離整體完成還有多遠。

4.新技術(shù)引入

技術(shù)創(chuàng)新是一種具有探索性、創(chuàng)造性的技術(shù)經(jīng)濟活動。在開發(fā)過程中引入新技術(shù)，不可避免地要遇到各種風(fēng)險。通過T形軟件開發(fā)、充分論證、多階段評審、同行經(jīng)驗等措施可降低新技術(shù)風(fēng)險。

(1)T形軟件開發(fā)

在項目開發(fā)早期，開發(fā)小組應(yīng)該建立系統(tǒng)的架構(gòu)，解決關(guān)鍵技術(shù)難題、開發(fā)系統(tǒng)的基礎(chǔ)構(gòu)件，并對系統(tǒng)所需要應(yīng)用的技術(shù)做深度探索。例如：基于JavaEE5構(gòu)建全國聯(lián)網(wǎng)售票系統(tǒng)，涉及到分布式事務(wù)處理、海量數(shù)據(jù)存儲、異構(gòu)平臺互連等關(guān)鍵問題，應(yīng)該優(yōu)先處理這些問題；對開發(fā)所涉及到的EJB3、JSF、JBoss Seam、Eclipse RCP等技術(shù)，要做深度探索。圖1 在第一階段以“T”形開發(fā)系統(tǒng)骨架[2]

越是技術(shù)復(fù)雜度高的項目，就越應(yīng)該早地處理技術(shù)難題。如果在項目開發(fā)的中期或后期才發(fā)現(xiàn)架構(gòu)有問題或是關(guān)鍵技術(shù)難題不能解決，則為時已晚。

(2)充分論證

新技術(shù)開發(fā)是探索性很強的工作，潛在著許多失敗的風(fēng)險。在可行性分析階段，要廣泛搜集相關(guān)信息，設(shè)計多種可行方案，進行充分論證。在制定決策時，情報的數(shù)量和質(zhì)量致關(guān)重要。掌握的信息越多、越準確，才能作出正確的的決策，項目失敗的風(fēng)險也就相對減少；反之，承擔(dān)的風(fēng)險就會增大。

(3)同行經(jīng)驗

針對新技術(shù)，由于沒有經(jīng)驗可借鑒，因此在探索過程中要充分利用互聯(lián)網(wǎng)，通過搜索同行經(jīng)驗，往往事半功倍。要充分利用世界日益平坦化的優(yōu)勢，對于不能盡快解決的問題，可

以先放一放，可能過不了幾天，網(wǎng)上就有相類似問題的解決方案了。

5.技術(shù)兼容性風(fēng)險

硬件產(chǎn)品之間、系統(tǒng)軟件（操作系統(tǒng)、中間件、數(shù)據(jù)庫管理系統(tǒng)）與主機設(shè)備之間、系統(tǒng)軟件之間、應(yīng)用軟件與系統(tǒng)軟件之間以及應(yīng)用軟件之間，都可能存在兼容性問題。往往系統(tǒng)集成的項目越復(fù)雜，兼容性問題就越有可能存在。

(1)設(shè)計先行

在做系統(tǒng)的總體設(shè)計方案時，務(wù)必把好相關(guān)產(chǎn)品的選型關(guān)，確保網(wǎng)絡(luò)、主機、系統(tǒng)軟件與應(yīng)用軟件之間不要存在較大的技術(shù)兼容性問題。在網(wǎng)絡(luò)平臺建設(shè)方案中，明確相關(guān)設(shè)備的技術(shù)參數(shù)和配置要求。

(2)售前產(chǎn)品測試

在做項目招投標工作時，要求投標方在售前提供產(chǎn)品兼容性測試，以避免在項目實施過程中才暴露技術(shù)兼容性問題。涉及應(yīng)用軟件開發(fā)的集成項目，要在開發(fā)工作的早期，做技術(shù)兼容性測試，以避免在項目開發(fā)后期才暴露技術(shù)兼容性問題。

例如，我們在開發(fā)深圳市汽車客運站售票及站務(wù)聯(lián)網(wǎng)調(diào)度系統(tǒng)時，為了確保技術(shù)兼容，在做硬件招標時要求小型機設(shè)備廠商提供售前技術(shù)兼容性測試工作，并將測試結(jié)果做為評標指標。在深圳市軟件測試中心對IBM、SUN、HP三家公司提供的小型機進行測試時，暴露了許多應(yīng)用軟件、應(yīng)用服務(wù)器、數(shù)據(jù)庫和操作系統(tǒng)之間的技術(shù)兼容性問題，如果這些問題在系統(tǒng)實施時才暴露或處理，勢必會拖延項目進度。

6.性能問題

由于先期設(shè)計不足，性能問題往往在系統(tǒng)切換或新系統(tǒng)使用一段時間后暴露。出現(xiàn)性能問題往往要進行大量的優(yōu)化工作，甚至局部的或全面的重新設(shè)計。無論是用戶還是開發(fā)者，誰都不希望出現(xiàn)性能問題。

(1)性能規(guī)劃

在系統(tǒng)設(shè)計時，應(yīng)做好前期做性能規(guī)劃，對可能出現(xiàn)性能問題的環(huán)節(jié)做到充足的估計。在做數(shù)據(jù)庫設(shè)計時，應(yīng)爭取DBA參與。

另外，在技術(shù)方法方面，盡可能采取一些性能優(yōu)化模式，如DTO、AJAX、延遲加載等，盡可能在開發(fā)過程中解決了性能問題。不至于到了項目后期才解決性能問題，既費錢又費時。

(2)性能測試

在開發(fā)過程中，要重視性能測試和壓力測試，盡可能模擬現(xiàn)實使用環(huán)境，搭建測試平臺。另外，由于開發(fā)環(huán)境的計算機往往比生產(chǎn)環(huán)境的計算機配置高，在做測試時應(yīng)盡量找一些配

置低的機器、較小的網(wǎng)絡(luò)帶寬進行測試。

(3)充足的調(diào)試時間

在項目開發(fā)計劃中，為后期性能優(yōu)化留有余地。在對系統(tǒng)進行性能優(yōu)化后，要進行性能測試和壓力測試，可能還要做幾次回歸測試。因此，應(yīng)該留有充足的時間和人力。

7.倉促上線

在項目實施過程中，系統(tǒng)切換上線環(huán)節(jié)最容易出紕漏。項目好不容易開發(fā)完成了，卻在最后最后時刻功潰一匱。如果項目小，影響面窄倒不怎么重要；如果是影響面大的項目，則千萬不可出現(xiàn)問題。在系統(tǒng)切換前，應(yīng)充分考慮各種可能出現(xiàn)的問題，做好風(fēng)險對策。

(1)應(yīng)急預(yù)案

面對各種不可預(yù)知的風(fēng)險，要做好應(yīng)急預(yù)案。正常運行的車站售票系統(tǒng)在春運、旅游黃金周，都會做好應(yīng)急預(yù)案。新系統(tǒng)切換時，更應(yīng)該做好應(yīng)急預(yù)案。應(yīng)急預(yù)案中應(yīng)做好最壞的打算，售票系統(tǒng)不能正常工作時，準備手工票就是最壞的打算。

(2)分步切換

為了減少風(fēng)險的影響，可以做系統(tǒng)分步切換的方案。例如：售票系統(tǒng)在切換時，往往用新系統(tǒng)售預(yù)售票，或者是用新系統(tǒng)售長途車站，用舊系統(tǒng)暫時售短程票。待新系統(tǒng)運行穩(wěn)定后，再全面切換到新系統(tǒng)。針對多個用戶單位的系統(tǒng)切換，也可分單位進行。

(3)交叉培訓(xùn)

新舊系統(tǒng)切換過程中，用戶都存在適應(yīng)過程。除了在切換前做好操作培訓(xùn)外，還要在新舊系統(tǒng)切換過程中做好交叉培訓(xùn)。讓用戶提前一些時間上班，讓早班的用戶在交班時培訓(xùn)中班的用戶，中班的用戶培訓(xùn)晚班的用戶。做好交叉培訓(xùn)能夠讓系統(tǒng)平衡過渡。

8.可用性問題

軟件的可用性包括軟件的使用是不是高效、是否容易學(xué)習(xí)、是否容易記憶、是否令人愉快、是否不易出錯等諸多因素。往往由于軟件的可用性差，導(dǎo)致用戶不滿意，甚至被市場淘汰。在項目開發(fā)中應(yīng)注意可用性問題，避免軟件出現(xiàn)可用性方面的風(fēng)險。

(1)了解用戶

到用戶工作現(xiàn)場，了解目標用戶使用軟件的真實目的，從用戶的角度、從用戶的立場出發(fā)，了解如何通過軟件系統(tǒng)替代用戶的業(yè)務(wù)處理流程中，最繁瑣、最容易出問題、或者是大量重復(fù)勞動的環(huán)節(jié)，讓軟件提高用戶的工作效能和效率。例如：售票系統(tǒng)中，使用頻度最高的界面是售票界面，售票員最關(guān)心的是錢不要出錯（多了沒收、少了要賠），因此，應(yīng)收款和找余字體的顯示應(yīng)該突出、醒目；同樣，票價和到達站也應(yīng)該較為突出顯示。通過快捷鍵、一鍵復(fù)位、數(shù)字小鍵盤等設(shè)計，盡量減少售票員敲擊鍵盤的次數(shù)。否則，在日發(fā)旅客流量達七、八萬人次的大型客運站，如果用戶界面設(shè)計得不好，售票員一天工作下來，手指都會敲麻木。

(2)參與型設(shè)計

與用戶協(xié)作，讓用戶參與用戶界面的設(shè)計、評審與測試，確保用戶能夠全面地、及早地發(fā)現(xiàn)可用性等方面的問題，并及時糾正。

讓客戶參與設(shè)計，而不要讓客戶設(shè)計，項目經(jīng)理或高級設(shè)計人員應(yīng)該主導(dǎo)設(shè)計。

(3)競爭性分析

通過對市場上同類競爭性產(chǎn)品進行分析，或者對這些產(chǎn)品進行實驗性測試，了解這些產(chǎn)品的用戶界面問題，從而對新系統(tǒng)的開發(fā)提供啟發(fā)。競爭性分析并不意味著可以剽竊別人的設(shè)計，而是通過分析競爭產(chǎn)品的優(yōu)勢和弱點，能夠比以前的設(shè)計做得更好[5]。

(4)一致性

如果用戶知道同樣的命令或同樣的操作總會產(chǎn)生同樣的效果，那么他們在使用系統(tǒng)時就會更加自信，同時也鼓勵他們進行探索性學(xué)習(xí)，因為他們已經(jīng)具備了使用系統(tǒng)新部分的基礎(chǔ)知識[Lewis er al.1989]。

開發(fā)團隊?wèi)?yīng)遵循公司或小組制定的用戶界面標準，就可以在很多方面保持一致性，切忌不要一個系統(tǒng)存在多種不同的界面風(fēng)格。

9.結(jié)論

在信息系統(tǒng)集成項目中，風(fēng)險是多種多樣的，是無處不在的。在項目管理活動中，要積極面對風(fēng)險，要培養(yǎng)。越早識別風(fēng)險、越早管理風(fēng)險，就越有可能規(guī)避風(fēng)險，或者在風(fēng)險發(fā)生時能夠降低風(fēng)險帶來的影響。特別是在項目參與方多、涉及面廣、影響面大、技術(shù)含量高的復(fù)雜項目，應(yīng)加強風(fēng)險管理。如果不主動駕馭風(fēng)險，就會面臨風(fēng)險。

第二篇：水利工程項目風(fēng)險管理論文

【摘要】水利工程是一個關(guān)系到社會和經(jīng)濟的重要內(nèi)容，然而由于競爭、環(huán)境等因素的影響，水利行業(yè)的發(fā)展面臨著許多不確定的風(fēng)險因素，其中包括工程項目質(zhì)量、經(jīng)濟效益等等，因此風(fēng)險管理已經(jīng)成為水利工程項目發(fā)展的一個突出課題。本文通過對水利工程建設(shè)中存在風(fēng)險進行的分析，知道了現(xiàn)代水利工程建設(shè)中風(fēng)險管理重要性，并對在整個生命周期內(nèi)影響水利工程項目的風(fēng)險因素進行識別，最后介紹了常用的風(fēng)險策略，以減少風(fēng)險的發(fā)生，促進項目效益的提高。

【關(guān)鍵詞】風(fēng)險管理 水利工程 風(fēng)險分析 應(yīng)對策略

Abstract:This paper analyzes the risk in thewater project,to prove the importance of the riskmanagement of water projects,and then identi-fies the risk factors in the life circle of water pro-jects,and finally describes the common riskstrategies,to reduce the occurrence of risk,andpromote the improvement of project benefits.Key words:Risk Management Strategies,water project,risk analysis,measures引言隨著社會經(jīng)濟的不斷發(fā)展，人類面臨的各種風(fēng)險也在不斷的發(fā)展、變化，人類的風(fēng)險意識不斷提高，為了能規(guī)避風(fēng)險，將風(fēng)險降到最低，人們所想出的辦法日益增多，技術(shù)也日趨先進。到20世紀中期，風(fēng)險管理已經(jīng)作為一門系統(tǒng)的管理科學(xué)被提出。水利工程項目的建設(shè)與開發(fā)是一個復(fù)雜的、充滿不確定性的過程，而它具有工程規(guī)模龐大、建設(shè)工期長、自然條件和技術(shù)條件復(fù)雜、資源投入數(shù)量大、影響因素多等特點，因此它是一個復(fù)雜的系統(tǒng)。由于在建設(shè)過程中，系統(tǒng)的不確定性因素眾多，影響方面眾多、關(guān)系復(fù)雜，由于不同原因造成的不同后果可能完全不同，這就導(dǎo)致了項目預(yù)期效果具有很大的不確定性。因此，在工程建設(shè)時對投資控制、風(fēng)險分析等是現(xiàn)代水利工程項目的重要內(nèi)容。通過科學(xué)系統(tǒng)的方法對風(fēng)險進行評估和控制，根據(jù)工程實際特點，減少或避免水利工程項目實施過程中的不確定性，降低項目實施過程中所存在的危險，抓住有利機會，降低損失，提高經(jīng)濟和社會效益，這就是水利工程項目風(fēng)險管理的目的，因此，開展水利工程項目風(fēng)險評估和風(fēng)險分析對確保工程建設(shè)有序進行具有積極的意義。

1.常規(guī)風(fēng)險分類

在水利工程中，風(fēng)險是指潛在災(zāi)害發(fā)生的概率及其對社會后果的度量。風(fēng)險包含客觀、普遍、動態(tài)和規(guī)律等特點。

風(fēng)險的分類多種多樣，按照風(fēng)險來源來分，項目風(fēng)險主要包含政策與環(huán)境風(fēng)險、財務(wù)風(fēng)險、管理風(fēng)險、技術(shù)風(fēng)險和項目進度風(fēng)險等。

政策和環(huán)境風(fēng)險是客觀存在的，存在很大的不可預(yù)料性、突發(fā)性，雖然發(fā)生的可能性比較小，但是這些風(fēng)險的發(fā)生往往是不可控制的，一旦發(fā)生就會產(chǎn)生很大的危害，為了減少突發(fā)風(fēng)險帶來的危害，在項目前期，根據(jù)項目所在位置的環(huán)境特點制定一定的相應(yīng)對策，盡量降低風(fēng)險發(fā)生時的損失。而管理風(fēng)險則主要是主觀性的人為風(fēng)險，由于管理人員缺乏相應(yīng)的經(jīng)驗和能力，就很有可能導(dǎo)致管理層決策失誤，從而會引起項目施工過程中一系列的問題發(fā)生，對工程造成不必要的損失。

各種風(fēng)險之間相互影響，隨著項目的進展而發(fā)生變化，并可能相互轉(zhuǎn)換的同時增加新的風(fēng)險，例如，項目進度風(fēng)險是因為工程施工進度的延誤而導(dǎo)致的，隨著工程時間的拖長其施工成本也就相應(yīng)的增加，實際施工的使用資金與工程前期的預(yù)算相差較多時，就會使得資金的融通、調(diào)度、周轉(zhuǎn)、利息等各方面發(fā)生變化，從而產(chǎn)生財務(wù)風(fēng)險，影響著項目的預(yù)期收益;

項目財務(wù)發(fā)生風(fēng)險時就可能會影響新設(shè)備的引進、新技術(shù)的研發(fā)等，從而導(dǎo)致技術(shù)風(fēng)險，影響到整個項目的成功。

因此，要做好風(fēng)險管理的系統(tǒng)規(guī)劃，就需要對整個項目中各階段的風(fēng)險進行全面分析和考慮，根據(jù)實際情況靈活的制定應(yīng)對措施，減少風(fēng)險發(fā)生的可能性，降低發(fā)生風(fēng)險時的損失，確保工程項目實際結(jié)果與預(yù)期結(jié)果偏離程度小。

2.常規(guī)風(fēng)險應(yīng)對策略

工程項目風(fēng)險在一定程度上是可以評估的，目前一般估算失事概率的風(fēng)險評估方法主要有：貝葉斯估計法、歷史性態(tài)法(重現(xiàn)期法)、蒙特--卡羅法等。借助評估結(jié)果，對不同的風(fēng)險制定相應(yīng)的風(fēng)險應(yīng)對策略，降低風(fēng)險發(fā)生的概率，提高項目工程的可行性，確保工程順利進行。

在風(fēng)險分析、評價的基礎(chǔ)上，利用科學(xué)的手段優(yōu)化方案，在眾多的方案中選優(yōu)汰劣，作出最佳決策，這就是風(fēng)險策略，它也是整個風(fēng)險管理的核心。常用的風(fēng)險策略主要包括風(fēng)險控制、風(fēng)險回避、風(fēng)險轉(zhuǎn)移和風(fēng)險自留。

2.1風(fēng)險控制

針對可控性風(fēng)險而言，風(fēng)險控制是采取一定的方法，在風(fēng)險未發(fā)生之前就防止其發(fā)生、減少損失，它是絕大部分項目應(yīng)用的主要風(fēng)險防范措施。風(fēng)險控制措施必須根據(jù)項目的實際情況，針對項目的具體問題提出，主要分為向內(nèi)和向外兩種。通過對項目內(nèi)部采取一定的管理措施、工程措施和技術(shù)措施等方式來進行風(fēng)險控制;同時也可以采取向外分散的方式來減少項目承擔(dān)的風(fēng)險，自然災(zāi)害是水利工程建設(shè)中所存在的最大風(fēng)險之一，洪水就是其中的一種，然而對于不同等級或類型的洪水，可以分析出它的流速、水位以及淹沒范圍等，從中就可以在一定程度上估計洪水所造成的損失結(jié)果，并可以采取必要的措施，如泄洪、轉(zhuǎn)移下游的財產(chǎn)等方法，把損失降到最低，從而達到被人們管理和控制的目的。

2.2風(fēng)險回避

在一些項目中，風(fēng)險發(fā)生可能性大、危險性高的，并且風(fēng)險控制的難度較大時，主動放棄該項目，從而達到回避該項目所帶來的一切風(fēng)險和損失的一種處置風(fēng)險的方式，這就是風(fēng)險回避。風(fēng)險回避雖然徹底消除了實施該項目可能帶來的風(fēng)險，但同時也失去了實施該項目可能帶來的收益，它既是一種最徹底的風(fēng)險處置技術(shù)，也是一種消極的風(fēng)險處置方式。風(fēng)險回避有幾種常用的處理方式：一是通過嚴格的招標投標程序，選擇合適的承包商，降低技術(shù)風(fēng)險;二是嚴格控制工程分包，防止將工程分包給劣質(zhì)承包商;三是根據(jù)實際情況進行現(xiàn)場規(guī)劃和拆遷，在滿足工程設(shè)計要求的條件下，盡可能回避施工地質(zhì)條件復(fù)雜、拆遷困難的地域。

2.3風(fēng)險轉(zhuǎn)移

將項目的風(fēng)險有意識地轉(zhuǎn)給與其有相互經(jīng)濟利益關(guān)系的另一方來承擔(dān)的風(fēng)險的處置方法就是風(fēng)險轉(zhuǎn)移。水利工程建設(shè)中經(jīng)常采用的風(fēng)險轉(zhuǎn)移方式主要有：為工程合同的履行提供履約擔(dān)保;設(shè)置保護性條款;投保建筑工程的一切險。

2.4風(fēng)險自留

當(dāng)采用其他風(fēng)險規(guī)避方法的費用超過風(fēng)險事件造成損失數(shù)額時，通?？梢圆捎蔑L(fēng)險自留。風(fēng)險自留又稱為風(fēng)險承擔(dān)，是指項目班子自己承擔(dān)由風(fēng)險事故所造成的損失。其包括主動和被動兩種，主動的風(fēng)險自留是指項目管理者在識別和衡量風(fēng)險的基礎(chǔ)上，對各種風(fēng)險作比較，權(quán)衡利弊，從而間接將風(fēng)險留置內(nèi)部，主要的措施有將損失計算進入經(jīng)營成本，并建立損失基金。被動的風(fēng)險自留是指項目管理者認為主觀或客觀原因，對風(fēng)險的存在性和風(fēng)險的嚴重性認識不足，沒有對風(fēng)險進行處理，而最終由項目班子自己承擔(dān)風(fēng)險損失。

在水利工程項目實施前，管理人員都應(yīng)對項目存在的風(fēng)險進行評估，并對此作出相應(yīng)的決策，在制定決策時常常將幾種應(yīng)對策略組合使用，發(fā)揮更大的功效，以達到最好的效果和目的。

結(jié)語

風(fēng)險的復(fù)雜多樣性、客觀存在性使得水利工程建設(shè)中存在很多的風(fēng)險，而風(fēng)險會對工程產(chǎn)生巨大的損失，因此在現(xiàn)代水利工程建設(shè)中風(fēng)險分析和管理十分重要。目前，風(fēng)險管理是水利工程項目管理的主要內(nèi)容之一，對于作為水利工程項目建設(shè)的實施主體、處于整個工程建設(shè)管理的核心和主導(dǎo)地位的項目管理者而言，不會管理風(fēng)險就不能成功地管理項目，因此提高項目風(fēng)險管理意識，掌握風(fēng)險識別技術(shù)，開展風(fēng)險評估與分析，及時防范和化解風(fēng)險，這對于提高我國的建設(shè)管理水平和投資效益，都具有特別重要的意義。

在水利工程建設(shè)中存在著許多不確定因素，通過人們對風(fēng)險的重視，加強管理，充分發(fā)揮水利設(shè)施的社會效益和經(jīng)濟效益，這就可以確保工程項目的效率同時造福于人類，真正做到水利工程服務(wù)于人民的目的。

參考文獻：

[1]鄧鐵軍,仇一顆,工程風(fēng)險管理.北京：人民交通出版社.2004,72-85.[2]王卓甫.工程項目風(fēng)險管理.北京：中國水利水電出版社,2003,153-175.

第三篇：軟件開發(fā)管理規(guī)定

軟件開發(fā)管理規(guī)定

第一條 第二條 第三條 為規(guī)范自有軟件研發(fā)以及外包軟件的管理工作，特制定本制度。本制度中軟件開發(fā)指新系統(tǒng)開發(fā)和現(xiàn)有系統(tǒng)重大改造。

本制度中自行開發(fā)是指主要依賴公司自身的管理、業(yè)務(wù)和技術(shù)力量進行系統(tǒng)設(shè)計、軟件開發(fā)、集成和相關(guān)的技術(shù)支持工作，一般僅向外購置有關(guān)的硬件設(shè)備和支撐軟件平臺；合作開發(fā)是公司與專業(yè)IT公司（合作商）共同協(xié)作完成IT應(yīng)用的項目實施和技術(shù)支持工作，一般形式是公司負責(zé)提供業(yè)務(wù)框架，合作商提供技術(shù)框架，雙方組成開發(fā)團隊進行項目實施，IT系統(tǒng)的日常支持由IT管理小組和合作商共同承擔(dān)，IT管理小組負責(zé)內(nèi)部（一級）支持，合作商負責(zé)外部（二級）支持；外包開發(fā)是指將IT應(yīng)用項目的設(shè)計、開發(fā)、集成、培訓(xùn)等任務(wù)承包給某家專業(yè)公司（可以是專業(yè)的IT公司或咨詢公司等），由該公司（承包商）負責(zé)應(yīng)用項目的實施。

第四條 軟件開發(fā)遵循項目管理和軟件工程的基本原則。項目管理涉及立項管理、項目計劃和監(jiān)控、配置管理、合作開發(fā)管理和結(jié)項管理。軟件工程涉及需求管理、系統(tǒng)設(shè)計、系統(tǒng)實現(xiàn)、系統(tǒng)測試、用戶接受測試、試運行、系統(tǒng)驗收、系統(tǒng)上線和數(shù)據(jù)遷移。

第五條 除特別指定，本制度中項目組包括業(yè)務(wù)組（或需求提出組）、IT組（可能包括網(wǎng)絡(luò)管理員和合作開發(fā)商）。

第二節(jié) 立項管理

第六條 提出開發(fā)需求的信息技術(shù)部門參與公司層面立項，進行立項的技術(shù)可行性分析，編寫《立項分析報告》，開展前期籌備工作?！读㈨椃治鰣蟾妗窇?yīng)明確項目的范圍和邊界。

第七條 第八條 應(yīng)用系統(tǒng)主要使用部門將《立項分析報告》上交公司進行立項審批。《立項分析報告》得到批準后，成立項目組（如果是外包開發(fā)，則成立外包商項目組；如果是合作開發(fā)，則與外包商共同成立合作開發(fā)項目組，以下統(tǒng)稱“項目組”），項目組應(yīng)包括業(yè)務(wù)組（由公司相關(guān)業(yè)務(wù)部門組成）和IT組（自行開發(fā)為辦公室網(wǎng)絡(luò)管理員；外包開發(fā)為外包商成員；合作開發(fā)為網(wǎng)絡(luò)管理員和外包商成員）。公司委派一名員工負責(zé)監(jiān)督項目的進度，進

第九條

第十條

第十一條第十二條第十三條第十四條第十五條第十六條第十七條行項目管理工作，確保開發(fā)能及時完成并能滿足業(yè)務(wù)需要。項目組人員的選擇應(yīng)滿足項目對業(yè)務(wù)及技術(shù)要求，項目組人員應(yīng)有足夠的業(yè)務(wù)和IT技術(shù)方面的專業(yè)知識來勝任項目各方面的工作。

第三節(jié) 需求分析

立項后業(yè)務(wù)組對用戶需求進行匯總整理，出具《業(yè)務(wù)需求說明書》，并確保《業(yè)務(wù)需求說明書》中包含了所有的業(yè)務(wù)需求。經(jīng)系統(tǒng)使用部門審批確認，作為業(yè)務(wù)需求基線。

IT組在獲得《業(yè)務(wù)需求說明書》后，提出技術(shù)需求和解決方案，并對系統(tǒng)進行定義，出具《系統(tǒng)需求規(guī)格說明書》?！断到y(tǒng)需求規(guī)格說明書》需詳細列出業(yè)務(wù)對系統(tǒng)的要求（界面、輸入、輸出、管理功能、安全需求、運作模式、關(guān)鍵指標(KPI)等）?！断到y(tǒng)需求規(guī)格說明書》需要由業(yè)務(wù)組提交給相關(guān)業(yè)務(wù)流程負責(zé)人確認。

對于合作開發(fā)的項目，當(dāng)業(yè)務(wù)需求發(fā)生變更時，業(yè)務(wù)組應(yīng)提交《需求變更申請》，IT組組長審批后交給合作開發(fā)商實施。

項目組應(yīng)對需求變更影響到的文檔及時更新。

第四節(jié) 項目計劃和監(jiān)控

軟件開發(fā)采用項目形式進行管理。項目經(jīng)理負責(zé)整個項目的計劃、組織、領(lǐng)導(dǎo)和控制。

需求分析過程中，項目經(jīng)理組織制定詳細的《項目計劃書》，包括具體任務(wù)描述和項目進度表等。

在項目的各個階段，業(yè)務(wù)組組長和IT組組長需配合項目經(jīng)理制定階段性項目計劃。業(yè)務(wù)組組長和IT組組長需配合項目經(jīng)理對項目計劃執(zhí)行情況進行監(jiān)控，確保項目按計劃完成。

項目計劃需要變更時，項目經(jīng)理填寫《項目計劃變更說明》，并提交公司主管領(lǐng)導(dǎo)審批，通過審批后，交給業(yè)務(wù)組組長和IT組組長執(zhí)行。

第五節(jié) 系統(tǒng)設(shè)計

系統(tǒng)設(shè)計應(yīng)分為概要設(shè)計和詳細設(shè)計，系統(tǒng)設(shè)計要遵循完備性、一致性、第十八條 第十九條

第二十條

第二十一條第二十二條第二十三條第二十四條第二十五條第二十六條第二十七條第二十八條第二十九條擴展性、可靠性、安全性、可維護性等原則。

在系統(tǒng)設(shè)計階段中，用戶應(yīng)充分參與，確保系統(tǒng)設(shè)計能滿足系統(tǒng)需求。項目組進行詳細設(shè)計，出具《設(shè)計說明書》和《單元測試用例》?！对O(shè)計說明書》中需要定義系統(tǒng)輸入輸出說明和接口設(shè)計說明。公司主管領(lǐng)導(dǎo)組織相關(guān)人員對概要設(shè)計進行評審，出具《設(shè)計評審報告》。業(yè)務(wù)組組長和IT組組長應(yīng)參加此評審并對評審意見簽字確認。

設(shè)計評審均以《業(yè)務(wù)需求說明書》和《系統(tǒng)需求規(guī)格說明書》為依據(jù)，確保系統(tǒng)設(shè)計滿足全部需求。

對已確認通過的系統(tǒng)設(shè)計進行修改需獲得管理部門、業(yè)務(wù)組組長和IT組組長的審批后方可進行。

對系統(tǒng)設(shè)計的修改的文檔須由文檔管理人員進行歸檔管理。

第六節(jié) 系統(tǒng)實現(xiàn)

項目組根據(jù)《設(shè)計說明書》制定系統(tǒng)實現(xiàn)計劃，并提交項目經(jīng)理對計劃可行性進行審批。

系統(tǒng)實現(xiàn)包括程序編碼、單元測試和集成測試。

項目組保證開發(fā)、測試和生產(chǎn)環(huán)境獨立，為各環(huán)境建立訪問權(quán)限控制機制，并明確項目成員的職責(zé)分工。對開發(fā)環(huán)境、測試環(huán)境與生產(chǎn)環(huán)境在物理或邏輯方面應(yīng)該做到隔離；如果環(huán)境的分隔是通過邏輯形式實現(xiàn)的，應(yīng)定期檢查網(wǎng)絡(luò)設(shè)置。項目組對已授權(quán)訪問生產(chǎn)環(huán)境的人員進行詳細記錄，并對該記錄進行定期檢查，確保只有經(jīng)授權(quán)的人員才能訪問到生產(chǎn)環(huán)境。

項目組進行單元測試和集成測試，測試人員簽字確認測試結(jié)果。

第七節(jié) 系統(tǒng)測試和用戶測試

項目組制定《系統(tǒng)/用戶測試計劃》，并提交項目經(jīng)理對計劃可行性進行審批。

《系統(tǒng)/用戶測試計劃》必須定義測試標準，并明確各種測試的測試步驟和需要的系統(tǒng)設(shè)置要求。

項目組向數(shù)據(jù)擁有部門申請獲取測試用業(yè)務(wù)數(shù)據(jù)的使用權(quán)，對獲取的數(shù)據(jù)進行嚴格的訪問控制，確保只有相關(guān)項目人員才能訪問及使用。

第三十條 項目組負責(zé)測試數(shù)據(jù)準備，測試用數(shù)據(jù)要足夠模擬生產(chǎn)環(huán)境中的實際數(shù)據(jù)。對已評定為敏感信息的數(shù)據(jù)進行敏感性處理和保護。

第三十一條 IT組或合作開發(fā)商建立測試環(huán)境進行系統(tǒng)測試。在系統(tǒng)測試中對新系統(tǒng)內(nèi)部各模塊之間的接口和與其他系統(tǒng)的接口進行充分測試。出具《系統(tǒng)測試報告》，測試人員簽字確認測試結(jié)果。

第三十二條 系統(tǒng)測試通過后，IT組配合業(yè)務(wù)組建立用戶測試環(huán)境，業(yè)務(wù)組根據(jù)用戶測第三十三條

第三十四條 第三十五條 第三十六條 第三十七條 第三十八條 第三十九條 第四十條 試用例進行用戶測試，出具《用戶測試報告》，業(yè)務(wù)組組長和IT組組長應(yīng)在用戶測試報告中簽字確認。

項目組完成系統(tǒng)幫助文檔（其中包括《用戶操作手冊》和《安裝維護手冊》）。凡涉及應(yīng)用系統(tǒng)的變更，應(yīng)對系統(tǒng)幫助文檔及時更新。

第八節(jié) 試運行

系統(tǒng)主要使用部門根據(jù)項目規(guī)模及影響決定試運行策略。

項目組制定《試運行計劃》，并制定試運行驗收指標，上報公司主管領(lǐng)導(dǎo)審批。《試運行計劃》中應(yīng)包含問題應(yīng)對機制，明確問題溝通渠道和職責(zé)分工。

項目組聯(lián)合試運行單位進行相關(guān)系統(tǒng)部署工作，準備培訓(xùn)資料，對相關(guān)用戶和信息技術(shù)人員進行培訓(xùn)。用戶培訓(xùn)的完成度應(yīng)為實施后評估的指標之一。

項目組根據(jù)《試運行計劃》進行系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移。系統(tǒng)轉(zhuǎn)換前，檢查系統(tǒng)環(huán)境，確保運行環(huán)境能滿足新應(yīng)用系統(tǒng)的需要。系統(tǒng)轉(zhuǎn)換時必須詳細記錄原系統(tǒng)中的重要參數(shù)、設(shè)置等系統(tǒng)信息，并填寫試運行報告相關(guān)內(nèi)容。系統(tǒng)參數(shù)、設(shè)置的轉(zhuǎn)換工作作為系統(tǒng)上線的驗收的評估指標之一。

數(shù)據(jù)遷移前，應(yīng)制定詳細的《數(shù)據(jù)遷移計劃》，《數(shù)據(jù)遷移計劃》中應(yīng)包含遷移方案、測試方案、數(shù)據(jù)定義，新舊數(shù)據(jù)對照表、遷移時間、回退計劃等信息。數(shù)據(jù)遷移計劃需經(jīng)項目經(jīng)理和主管領(lǐng)導(dǎo)簽字審批。

數(shù)據(jù)遷移后，項目組對數(shù)據(jù)遷移的完整性和準確性作出檢查，出具《數(shù)據(jù)遷移報告》，其中包括數(shù)據(jù)來源、轉(zhuǎn)換前狀態(tài)、轉(zhuǎn)換后狀態(tài)，數(shù)據(jù)遷移負責(zé)人、對完整性檢查情況、對準確性檢查情況等內(nèi)容。各相關(guān)部門驗收轉(zhuǎn)換結(jié)果后在該報告上簽字確認。

系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移由試運行單位業(yè)務(wù)部門和公司主管領(lǐng)導(dǎo)共同監(jiān)督并進行驗收。

第四十一條 系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移驗收通過后，正式啟動試運行。在試運行過程中，試運行單位辦公室把系統(tǒng)運行情況（系統(tǒng)資源使用，反應(yīng)速度等）記錄到試運行報告中。必要時，項目組應(yīng)根據(jù)系統(tǒng)運行情況對應(yīng)用系統(tǒng)進行優(yōu)化。

第四十二條 試運行達到試運行計劃規(guī)定的終止條件時，項目組編寫《試運行報告》。此

第四十三條 第四十四條 第四十五條 第四十六條 第四十七條 第四十八條 第四十九條 報告應(yīng)由項目組和試運行單位簽字確認，并提交公司主管領(lǐng)導(dǎo)審閱。公司主管領(lǐng)導(dǎo)審閱試運行結(jié)果，決定試運行結(jié)束或延期。

第九節(jié) 系統(tǒng)驗收

系統(tǒng)主要使用部門及信息技術(shù)部門聯(lián)合組成獨立系統(tǒng)驗收小組，也可授權(quán)原項目組作為驗收小組。驗收小組從功能需求及技術(shù)需求層面對系統(tǒng)進行綜合評估。

驗收小組應(yīng)根據(jù)驗收情況整理形成《系統(tǒng)驗收報告》提交系統(tǒng)主要使用部門和信息技術(shù)部門審閱。

系統(tǒng)主要使用部門和信息技術(shù)部門負責(zé)人根據(jù)系統(tǒng)測試、試運行情況簽署驗收意見。

第十節(jié) 系統(tǒng)上線

系統(tǒng)上線應(yīng)遵循穩(wěn)妥、可控、安全的原則。通常情況下，系統(tǒng)上線包含數(shù)據(jù)遷移工作。

項目組制定《系統(tǒng)上線計劃》，上報公司主管領(lǐng)導(dǎo)審批。在上線計劃得到批準后才能開始部署上線工作。

《系統(tǒng)上線計劃》內(nèi)容應(yīng)包括但不限于：

1、部署方式和資源分配（包括人力資源及服務(wù)器資源）；

2、上線工作時間表；

3、上線操作步驟以及問題處理步驟；

4、項目階段性里程碑和成果匯報（項目執(zhí)行狀態(tài)的審閱、進度安排等）；

5、數(shù)據(jù)遷移的需求和實施計劃；

6、完整可行的應(yīng)急預(yù)案和“回退”計劃；

7、用戶培訓(xùn)計劃（包括：培訓(xùn)計劃、培訓(xùn)手冊、培訓(xùn)考核等）；

8、公司下發(fā)的系統(tǒng)標準參數(shù)配置。

第五十條 上線單位在上線初期需加強日常運行狀態(tài)監(jiān)控，出現(xiàn)問題時應(yīng)及時處理，對重大問題應(yīng)啟動緊急預(yù)案。

第五十一條 在完成上線后要填寫《系統(tǒng)驗收評估報告》，上報公司項目組匯總整理。第五十二條 第五十三條

第五十四條 第五十五條 第五十六條 第五十七條 第五十八條 第五十九條 第六十條

第六十一條 第六十二條 第六十三條 第六十四條 《系統(tǒng)驗收評估報告》內(nèi)容包括：數(shù)據(jù)準確性、系統(tǒng)性能及穩(wěn)定性、接口問題、權(quán)限問題、業(yè)務(wù)操作影響度、問題處理情況、備份、批處理等。

上線單位管理層要對《系統(tǒng)驗收評估報告》進行審批簽字。

公司主管領(lǐng)導(dǎo)批準結(jié)項后，業(yè)務(wù)組和IT組將整理的文檔提交各自部門統(tǒng)一管理。

第十一節(jié) 合作開發(fā)管理

合作開發(fā)商的選擇應(yīng)遵循公司相關(guān)規(guī)定，合作商資質(zhì)認定參見第三方管理制度。

合作開發(fā)商必須遵循公司《軟件開發(fā)管理制度》。

項目經(jīng)理同合作開發(fā)商明確規(guī)定項目變更的范圍和處理方式，重點關(guān)注需求和設(shè)計變更。

項目經(jīng)理負責(zé)監(jiān)控合作開發(fā)商的項目管理及軟件開發(fā)活動。合作開發(fā)商應(yīng)按計劃定期向項目經(jīng)理報告進展狀態(tài)，并提交階段性成果文檔。發(fā)生重大問題時，合作開發(fā)商需及時向項目經(jīng)理匯報。

IT組組長派專人監(jiān)控合作開發(fā)商的質(zhì)量保證過程。項目組同合作開發(fā)商商定驗收的標準和方法。以上各要求需要在開發(fā)合同中明確。

第十二節(jié) 外包開發(fā)管理

立項申請得到公司主管領(lǐng)導(dǎo)的審批后，選定開發(fā)商，簽訂外包開發(fā)合同。項目經(jīng)理負責(zé)監(jiān)控外包開發(fā)商的項目管理及軟件開發(fā)活動。外包開發(fā)商應(yīng)按計劃定期向項目經(jīng)理報告進展狀態(tài)，并提交階段性成果文檔。發(fā)生重大問題時，外包開發(fā)商需及時向項目經(jīng)理匯報。

項目經(jīng)理監(jiān)控外包開發(fā)商的質(zhì)量保證過程。項目組同外包開發(fā)商商定驗收的標準和方法。第六十五條 以上各要求需要在開發(fā)合同中明確。

第四篇：軟件開發(fā)管理規(guī)范

軟件開發(fā)過程管理規(guī)范

濟南明湖建筑節(jié)能技術(shù)開發(fā)有限公司 軟件開發(fā)過程管理規(guī)范

一、總則.................................................................................................................................1 1.軟件開發(fā)項目管理的目的.........................................................................................1 2.軟件開發(fā)項目管理規(guī)范適用對象.............................................................................1 3.軟件項目開發(fā)組織管理.............................................................................................1

二、軟件項目立項階段.........................................................................................................1

三、軟件項目實施階段.........................................................................................................2

四、項目需求分析過程.........................................................................................................2

五、項目系統(tǒng)設(shè)計過程.........................................................................................................3

六、項目開發(fā)編碼過程.........................................................................................................3

七、測試提交過程.................................................................................................................4

八、項目驗收總結(jié)階段.........................................................................................................4

軟件開發(fā)過程管理規(guī)范

一、總則

1.軟件開發(fā)項目管理的目的

為保障按時、保質(zhì)、保量完成預(yù)期交付的任務(wù)，讓整個組織能清楚了解項目實施的目的、影響、進度，做到項目組所有成員都理解項目實施的原因、意義及客戶的要求。通過制度化管理來合理組織安排項目組成員的工作職責(zé)和角色轉(zhuǎn)換。2.軟件開發(fā)項目管理規(guī)范適用對象

為了達到軟件開發(fā)項目管理的根本目的，要求公司全體員工必須嚴格按照本規(guī)范執(zhí)行，同時要求公司業(yè)務(wù)人員引導(dǎo)合作單位和客戶接受并適應(yīng)公司本《軟件項目開發(fā)管理規(guī)范》。3.軟件項目開發(fā)組織管理

根據(jù)軟件開發(fā)的標準流程，結(jié)合公司的實際情況對軟件項目分三個主要階段進行組織管理，分別為項目立項階段、項目實施階段和項目驗收總結(jié)階段。

二、軟件項目立項階段

1.成立公司項目評估委員會負責(zé)公司的項目立項審批。

2.公司項目評估委員會由公司總經(jīng)理或指定負責(zé)人召集，成員為公司管理層人員、商務(wù)負責(zé)人、市場負責(zé)人、技術(shù)總監(jiān)、技術(shù)研發(fā)經(jīng)理、財務(wù)負責(zé)人組成。

3.公司業(yè)務(wù)部門按照公司發(fā)展要求或外部需求形成《軟件項目需求說明書》，確定項目需求管理人或項目申請人。

4.項目申請人填寫《軟件項目立項申請書》向項目評估委員會提出項目立項申請，主要說明項目的背景、目的、效益、成本、需求等方面，并由技術(shù)部門提供支持和技術(shù)說明。5.項目評估委員會收到《項目立項申請書》后三個工作日內(nèi)，召開評估會議。給出評估結(jié)果。如果批準立項交公司技術(shù)總監(jiān)組織開發(fā)。如果不批準，給出理由后項目中止。中止后的項目可根據(jù)情況重新申請。

6.評估結(jié)果必須包括：建議項目啟動日期，期望項目完成日期，項目等級系數(shù)，項目優(yōu)先級（高中低），資源沖突程度(1~9)。對于資源沖突程度大于5的項目技術(shù)總監(jiān)有權(quán)拒絕

軟件開發(fā)過程管理規(guī)范

接受。

三、軟件項目實施階段

1.公司批準立項的項目交由公司技術(shù)總監(jiān)組織實施。

2.技術(shù)總監(jiān)根據(jù)資源情況和項目需求組織相關(guān)技術(shù)人員進行初步需求討論會，確定項目的等級系數(shù)（如分大、中、小對應(yīng)3、2、1）、指定項目開發(fā)負責(zé)人。在立項后五個工作日內(nèi)技術(shù)總監(jiān)和項目開發(fā)負責(zé)人共同制定《軟件項目開發(fā)計劃》，確定項目啟動日并提交項目評估委員會做反饋確認。如果項目評估委員會二位成員以上對計劃有異議，項目評估委員會應(yīng)該召開項目計劃協(xié)調(diào)會，協(xié)調(diào)《軟件項目開發(fā)計劃》的修改和通過。如果無異議授權(quán)技術(shù)總監(jiān)按照《軟件項目開發(fā)計劃》執(zhí)行。

3.項目啟動日后，項目開發(fā)負責(zé)人根據(jù)《軟件項目開發(fā)計劃》的進度每周進行一次分析匯報，形成《項目分析周報》確定項目的狀態(tài)、分析風(fēng)險和對策，交技術(shù)總監(jiān)管控。4.《軟件項目開發(fā)計劃》必須按照軟件項目實施過程分解為需求分析、系統(tǒng)設(shè)計、開發(fā)編碼和測試提交幾個控制過程。

四、項目需求分析過程

1.項目需求分析團隊由技術(shù)總監(jiān)負責(zé)，組成人員包括技術(shù)研發(fā)經(jīng)理、項目開發(fā)負責(zé)人、部分高級軟件開發(fā)工程師和需求提供人。

2.需求分析第一次會議將在《軟件項目開發(fā)計劃》通過后，在項目啟動日2個工作日內(nèi)召開，提出需求的不足之處交需求提供人完善。

3.分析團隊分工完成提交《軟件項目需求功能列表》及《項目關(guān)鍵業(yè)務(wù)流程》文擋。4.需求分析應(yīng)該在需求分析第一次會議后的開始，并在（3個工作日*項目等級系數(shù)）日內(nèi)完成。

5.需求分析過程完成后，如果需求變更提供人必須書面提出《項目需求變更通知書》，項目需求分析團隊在2個工作日內(nèi)完成分析反饋，確定項目變更系數(shù)；項目負責(zé)人變更對應(yīng)《軟件項目開發(fā)計劃》版本。

6.需求分析階段完成的標志為技術(shù)總監(jiān)召開文擋審查和階段總結(jié)會，時間為1個工作日。

軟件開發(fā)過程管理規(guī)范

五、項目系統(tǒng)設(shè)計過程

1.項目設(shè)計團隊由技術(shù)總監(jiān)負責(zé)，組成人員包括技術(shù)研發(fā)經(jīng)理、項目開發(fā)負責(zé)人、部分高級軟件開發(fā)工程師。

2.項目分析設(shè)計團隊在收到需求階段文檔后2個工作日內(nèi)召開設(shè)計工作啟動協(xié)調(diào)會，審查反饋需求階段文檔。

3.協(xié)調(diào)會明確分工、按計劃完成《項目系統(tǒng)接口說明》、《項目系統(tǒng)數(shù)據(jù)設(shè)計文檔》和《主要操作界面說明》文檔。

4.項目設(shè)計應(yīng)該在啟動協(xié)調(diào)會后開始，并在（5個工作日*項目等級系數(shù)）日內(nèi)完成。5.項目負責(zé)人接到《項目需求變更通知書》后，按照1個工作日*項目變更系數(shù)調(diào)整對應(yīng)設(shè)計和計劃。

6.項目設(shè)計階段完成的標志為技術(shù)總監(jiān)召開設(shè)計文擋審查和階段總結(jié)會，時間為1個工作日。

六、項目開發(fā)編碼過程

1.項目開發(fā)編碼團隊由技術(shù)研發(fā)經(jīng)理負責(zé)，組成人員包括項目開發(fā)負責(zé)人和軟件開發(fā)工程師。

2.項目開發(fā)編碼團隊在收到需求和設(shè)計階段文檔后2個工作日內(nèi)召開編碼工作啟動協(xié)調(diào)會，學(xué)習(xí)理解并反饋需求和設(shè)計階段文檔。

3.技術(shù)研發(fā)經(jīng)理按照項目《軟件項目開發(fā)計劃》中開發(fā)編碼過程的細分階段進行控制。

4.項目開發(fā)負責(zé)人需負責(zé)項目聯(lián)調(diào)測試，保證《項目關(guān)鍵業(yè)務(wù)流程》和《主要操作界面說明》文檔的實現(xiàn)。

5.技術(shù)研發(fā)經(jīng)理要組織項目開發(fā)編碼團隊對（項目等級系數(shù)）關(guān)鍵代碼進行集中解讀，保證編碼的質(zhì)量和規(guī)范。

6.根據(jù)項目的情況，要求開發(fā)編碼人員對《項目系統(tǒng)接口說明》中接口進行性能測試，并產(chǎn)生接口測試報告。

7.技術(shù)研發(fā)經(jīng)理負責(zé)做好開發(fā)編碼的版本管理工作。

8.開發(fā)編碼應(yīng)該在編碼工作啟動協(xié)調(diào)會后開始，并在（10個工作日*項目等級系數(shù)）內(nèi)完成。

軟件開發(fā)過程管理規(guī)范

9.開發(fā)編碼階段完成的標志為測試人員接受測試版本后，技術(shù)研發(fā)經(jīng)理召開提交和階段總結(jié)會，開發(fā)人員的所有代碼轉(zhuǎn)交給項目負責(zé)人管理。時間為1個工作日。

七、測試提交過程

1.項目測試團隊由技術(shù)研發(fā)經(jīng)理、項目負責(zé)人和測試工程師組成。

2.測試工程師首先檢查開發(fā)編碼團隊《項目關(guān)鍵業(yè)務(wù)流程》、《主要操作界面說明》和《項目系統(tǒng)接口說明》的測試結(jié)果。如果通過才接受，否則將退回。

3.測試工程師在開發(fā)編碼階段的同時應(yīng)該編制好《項目軟件使用說明書》，接受測試版本后按照《項目軟件使用說明書》進行測試。

4.測試工程師重新測試一次《項目關(guān)鍵業(yè)務(wù)流程》、《主要操作界面說明》和《項目系統(tǒng)接口說明》。

5.測試工程師完成對應(yīng)版本的《項目測試報告》，發(fā)現(xiàn)的問題交項目負責(zé)人負責(zé)組織開發(fā)人員修改完善。

6.測試工程師提交完成版本的《項目測試報告》后，由技術(shù)研發(fā)經(jīng)理確認并簽字。將對應(yīng)版本定義為發(fā)布版本。

7.測試工作應(yīng)該在接受測試版本后進行，并在（5個工作日*項目等級系數(shù)）內(nèi)完成。

八、項目驗收總結(jié)階段

1.發(fā)布版本后，項目負責(zé)人打印收集好所有項目過程文擋，并有對應(yīng)責(zé)任人簽字。

2.項目負責(zé)人回顧總結(jié)《軟件項目開發(fā)計劃》，分析總結(jié)實際和計劃差異，形成《項目計劃執(zhí)行情況報告》。

3.技術(shù)研發(fā)經(jīng)理總結(jié)項目設(shè)計、開發(fā)、測試過程的質(zhì)量控制和開發(fā)人員開發(fā)效率情況，總結(jié)經(jīng)驗教訓(xùn)并提出項目開發(fā)改進措施。

4.技術(shù)總監(jiān)總結(jié)分析成本控制、對全部項目人員進行考核，形成《項目總結(jié)報告》。并完善本規(guī)范流程。

5.上述工作完成后，提交項目評估委員會總結(jié)會審批后公布。

第五篇：軟件開發(fā)管理流程

軟件開發(fā)管理流程

根據(jù)我公司目前工作現(xiàn)狀，開發(fā)管理流程涉及到三個方向的工作管理；一是全新項目開發(fā)整體流程；二是二期項目開發(fā)管理流程（項目已部分上線，二期進行其它公司或模塊上線）；三是維護工作管理流程；

一、升級項目流程

針對我公司現(xiàn)有的BSP項目，存在有些省份的BSP項目存在部分上線而對于后期需要繼續(xù)上線其他部分的情況，提出以下工作流程。

總體流程

計劃階段－》需求分析階段－》軟件開發(fā)階段－》測試階段－》部署上線—》驗收完成（一）計劃階段

制定整體開發(fā)計劃，計劃體現(xiàn)整個開發(fā)周期，包括需求、編碼、測試周期以及資源要求；

（二）需求分析階段

修訂需求版本，提供需求說明書，并提出需求評審申請。

評審：發(fā)起需求評審的同時提交評審資料至項目管理部—》項目管理部給相關(guān)

人員發(fā)放資料并通知評審安排--》記錄評審結(jié)果（需整改時整改之后可再次評審）--》確定需求版本。

（三）軟件開發(fā)階段

編碼開發(fā)前：開發(fā)環(huán)境搭建，其中包括遷出代碼最新版本，從線上復(fù)制出數(shù)據(jù)庫（或者導(dǎo)出基礎(chǔ)數(shù)據(jù)庫表數(shù)據(jù)）；其目的為開發(fā)環(huán)境與正式環(huán)境保持一致，為上線前的部署做好準備。

編碼開發(fā)中：開發(fā)組長對整個開發(fā)過程做好監(jiān)控，保證質(zhì)量的同時保證進度；并且要求開發(fā)人員做好工作記錄；加強團隊的協(xié)作與溝通。

編碼開發(fā)完：提交相關(guān)資料（操作手冊、部署文檔：sql腳本、代碼文件路徑記錄、流程文件路徑記錄），組長整理部署文檔并且提交測試申請；部署文檔要求寫明部署步驟及部署內(nèi)容及相應(yīng)注釋；

（四）測試階段

測試組長根據(jù)測試申請中的測試內(nèi)容安排測試。測試環(huán)境模擬線上測試環(huán)境，根據(jù)部署文檔進行部署，并且記錄所有補丁包。測試過程中開發(fā)人員在修改bug的同時需要維護部署文檔。

（五）部署

部署人員根據(jù)部署文檔中描述的步驟部署系統(tǒng)。完成之后實施人員安排驗收。

二、全新項目開發(fā)管理流程

總體流程

計劃階段－》需求分析階段－》軟件開發(fā)階段－》測試階段－》部署上線—》驗收完成(一)計劃階段

項目計劃草案和風(fēng)險管理計劃作為第一步，確定、分析項目風(fēng)險并確定其優(yōu)先級，還要制定風(fēng)險解決方案。本階段的目的是確立產(chǎn)品開發(fā)的經(jīng)濟理由。當(dāng)確定開發(fā)之后則制定軟件開發(fā)計劃、人員組織結(jié)構(gòu)定義及配備、過程控制計劃。

? 項目計劃草案

項目計劃草案應(yīng)包括產(chǎn)品簡介、產(chǎn)品目標及功能說明、開發(fā)所需的資源、開發(fā)時間和里程碑。

? 風(fēng)險管理計劃

就是把有可能出錯或現(xiàn)在還不能確定的東西列出來，并制定出相應(yīng)的解決方案。風(fēng)險發(fā)現(xiàn)得越早對項目越有利。

? 軟件開發(fā)計劃

軟件開發(fā)計劃的目的是收集控制項目時所需的所有信息，項目經(jīng)理

根據(jù)項目計劃來安排資源需求并根據(jù)時間表跟蹤項目進度。項目團隊

成員根據(jù)項目計劃以了解他們的工作任務(wù)、工作時間以及他們所依賴的其他活動。

項目管理培訓(xùn)

可將計劃分成總體計劃和詳細計劃，總體計劃中每個任務(wù)為一個里

程碑，詳細計劃中必須將任務(wù)落實到個人。

軟件開發(fā)計劃還應(yīng)包括產(chǎn)品的應(yīng)收標準及應(yīng)收任務(wù)（包括確定需要

制訂的測試用例）。

? 人員組織結(jié)構(gòu)定義及配備

常見的人員組織結(jié)構(gòu)有垂直方案、水平方案、混合方案。垂直方案

中每個成員充當(dāng)多重角色。水平方案中每個成員充當(dāng)一到兩個角色。

混合方案則包括了經(jīng)驗豐富的人員與新手相互融合。具體選擇根據(jù)人

員實際技能情況進行選擇。

? 過程控制計劃

過程控制計劃的目的是收集項目計劃正常執(zhí)行所需的所有信息，用來

指導(dǎo)項目進度的監(jiān)控、計劃的調(diào)整，確保項目按時完成。

(二)需求分析階段

需求分析階段的目的是在系統(tǒng)工作方面與用戶達成一致。

（1）軟件需求規(guī)約

詳細說明系統(tǒng)將要實現(xiàn)的所有功能。

（2）用戶界面原型

可以有三種表示方法：圖紙（在紙上）、位圖（繪圖工具）、可執(zhí)行文件（交互式）。

（三）軟件開發(fā)階段

本階段從物理上實現(xiàn)目標系統(tǒng)。采用了面向?qū)ο蠓椒ā?/p>

（1）軟件架構(gòu)

說明軟件的組織結(jié)構(gòu)、部署結(jié)構(gòu)及運行環(huán)境。

（2）功能設(shè)計

定義功能點之間的關(guān)聯(lián)。

（3）數(shù)據(jù)庫設(shè)計

定義數(shù)據(jù)庫表之間的關(guān)聯(lián)和各個表的字段。

（4）編碼和單元測試

按照設(shè)計文檔進行編碼，每完成一個模塊應(yīng)進行單元測試。

（5）集成系統(tǒng)

按軟件組織結(jié)構(gòu)的要求將各個子模塊組合起來。

（四）測試階段

測試的目的是在發(fā)布之前找出程序的錯誤。包括：核實每個模塊是否正常運行（參考設(shè)計文檔）、核實需求是否被正確實施（參考需求文檔）。

（1）測試計劃

收集和組織測試信息，為測試工作提供指導(dǎo)。

（2）測試數(shù)據(jù)

盡量使用真實數(shù)據(jù)。

（3）測試報告

記錄測試結(jié)果，詳細描述問題，提出解決辦法。

（4）用戶操作手冊

（五）管理軟件開發(fā)過程

有以下幾方面地工作：

（1）組織會議

討論會議、總結(jié)會議等。

（2）評審程序

對各個階段的工作結(jié)果進行審核等。

（3）協(xié)調(diào)人員

（4）監(jiān)控進度

軟件項目開發(fā)流程

第一個步驟是市場調(diào)研，技術(shù)和市場要結(jié)合才能體現(xiàn)最大價值。

第二個步驟是需求分析，需求人員出需求分析說明書。發(fā)起需求評審申請，項目管理部組織開發(fā)團隊進行評審；

評審：發(fā)起需求評審的同時提交評審資料至項目管理部—》項目管理部給相關(guān)人員發(fā)放資料并通知評審安排--》記錄評審結(jié)果（需整改時整改之后可再次評審）--》確定需求版本。

第三個步驟是概要設(shè)計，將系統(tǒng)功能模塊初步劃分，并給出合理的研發(fā)流程和資源要求。按照公司現(xiàn)狀，使用快速原型設(shè)計方法完成概要設(shè)計就可以進入編碼階段了，通常采用這種方法是因為涉及的研發(fā)任務(wù)屬于新領(lǐng)域，技術(shù)主管人員一上來無法給出明確的詳細設(shè)計說明書，但是并不是說詳細設(shè)計說明書不重要，事實上快速原型法在完成原型代碼后，根據(jù)評測結(jié)果和經(jīng)驗教訓(xùn)的總結(jié)，還要重新進行詳細設(shè)計的步驟

第四個步驟是詳細設(shè)計，這是考驗技術(shù)專家設(shè)計思維的重要關(guān)卡，詳細設(shè)計說明書應(yīng)當(dāng)把具體的模塊以最‘干凈’的方式提供給編碼者，使得系統(tǒng)整體模塊化達到最大；一份好的詳細設(shè)計說明書，可以使編碼的復(fù)雜性減低到最低。

第五個步驟是編碼，開發(fā)人員需嚴格按照編碼規(guī)范及需求文檔編碼，編碼時不同模塊之間的進度協(xié)調(diào)和協(xié)作是最需要小心的，也許一個小模塊的問題就可能影響了整體進度，讓很多程序員因此被迫停下工作等待，這種問題在以前的開發(fā)過程中都出現(xiàn)過。編碼時的相互溝通和應(yīng)急的解決手段都是相當(dāng)重要的。項目組長需提高對開發(fā)過程中問題的管控能力。盡量避免重大問題，提高工作效率。

第六個步驟是測試，測試有很多種：按照測試執(zhí)行方，可以分為內(nèi)部測試和外部測試；按照測試范圍，可以分為模塊測試和整體聯(lián)調(diào)；按照測試條件，可以分為正常操作情況測試和異常情況測試；按照測試的輸入范圍，可以分為全覆蓋測試和抽樣測試?？傊?，測試同樣是項目研發(fā)中一個相當(dāng)重要的步驟。

第七個步驟是部署，搭建部署環(huán)境，按照部署方案進行部署，完成后驗收測試；