二、 項目風險的估計
前面說到，小型軟件公司的項目經(jīng)理往往是老板本人，有很強的風險意識。但在這里還是要著重說說軟件工程的風險管理，因為項目經(jīng)理認識的風險大多局限在商業(yè)風險（銷售問題等）中，對風險的理解很片面。
軟件風險是指軟件開發(fā)過程中及軟件產(chǎn)品本身可能造成的傷害或損失。風險關注未來的事情，這意味著，風險涉及選擇及選擇本身包含的不確定性，在軟件開發(fā)過程及軟件產(chǎn)品都要面臨各種決策的選擇。風險是介于確定性和不確定性之間的狀態(tài)，是處于無知和完整知識之間的狀態(tài)。另一方面，風險將涉及思想、觀念、行為、地點等因素的改變。根據(jù)風險內(nèi)容，我們可以將風險分為項目風險（成本提高，時間延長等）、技術風險（技術不成熟等）、商業(yè)風險（銷售問題等）、戰(zhàn)略風險（公司的經(jīng)營戰(zhàn)略發(fā)生了變化）、管理風險（公司管理人員是否成熟等）、預算風險（預算是否準確等）等。
另外，我們還可以將風險分為已知風險（如員工離職等）、可預報風險（從以往經(jīng)驗得出可能有風險的）和不可預知風險。
例如，在一些訂單開發(fā)的軟件中，存在著很大的商業(yè)風險。林子大了，什么鳥都有�？蛻舳嗔�，需要不同，客戶相關的風險出現(xiàn)的概率不一樣。一些人只知道他們需要什么；而另一些人知道他們不需要什么。一些客戶希望進行詳細的討論，而另客戶則滿足于模糊的承諾�？蛻粲胁煌膫�性。一些人喜歡享受客戶的身份，而另一些人則根本不喜歡作為客戶。一些人會高興地接受幾乎任何交付的產(chǎn)品，并能充分利用一個不好的產(chǎn)品；而另一些人則會對質(zhì)量差的產(chǎn)品猛烈抨擊。一些人會對質(zhì)量好的產(chǎn)品表示贊賞；而另一些人則不管怎樣都抱怨不休�？蛻艉凸⿷讨g也有各種不同的通信方式。一些人非常熟悉產(chǎn)品及生產(chǎn)廠商；而另一些人則可能素未謀面，僅僅通過信件來往和電話與生產(chǎn)廠商溝通。一個“不好的”客戶可能會對一個軟件項目組能否在預算內(nèi)完成項目產(chǎn)生很大的影響。對于項目管理者而言，不好的客戶是對項目計劃的巨大威脅和實際的風險。
對于大多數(shù)軟件項目而言，風險因素——性能、成本、支持、進度，也代表了風險參考水平值。即，對于性能下降、成本超支、支持困難、或進度延遲，都有一個水平值的要求，超過它會導致項目被迫停止。如果風險的組合所產(chǎn)生的問題引起一個或多個參考水平值被超過，則工作將會停止。在軟件風險分析中，風險參考水平值存在一個點，稱為參考點或臨界點，在這個點上，決定繼續(xù)進行該項目或終止它（問題太多）都是可以接受的。下圖以圖形方式表示了這種情況。如果風險的組合產(chǎn)生問題導致成本超支及進度延遲，則會有一個水平值，即圖中的曲線，當超過它時會引起項目終止。
三、 項目進度成本效益的估計
其實，這也是項目風險有著緊密聯(lián)系，是項目風險發(fā)生的一大因素之一。為此，需要做到以下幾步：
1、在制定項目計劃時，必須進行項目的需求分析，明確項目的需求。
在的需求分析階段，往往存在著這樣的誤區(qū)：在項目的需求分析階段，開發(fā)方與客戶方在各種的問題的基本輪廓上達成一致即可，具體細節(jié)可以在以后填充。因為無論開始時有多么細致，以后對需求的修改幾乎是必然的。當然這樣做是有原因的：在具體實際中由于種種原因客戶方很難在需求分析階段全面而準確地描述所有問題。隨著開發(fā)進度的推進，往往會有一些需求的改變。但是這樣做，由于需求階段對問題的描述不夠細致，導致后來預算超出或者時間進度達不到要求。
正確的做法是：在項目需求分析階段，雙方必須全面地盡可能細致地討論項目的應用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準。并且，在需求分析結束以后，雙方還要建立可以直接聯(lián)系的渠道，以盡早地對需求變動問題進行溝通。并在項目需求分析完成后，和客戶明確項目的哪些部分可以在日后的進度中能修改，修改的限度，哪些不能修改。例如，應用背景、功能要求方面應該是在需求分析階段確定，日后不能做修改。而性能、界面及接口等可以在日后作有限度的修改。
2、制定項目計劃：
有人這樣說計劃的，“計劃，計劃，紙上畫畫，墻上掛掛，計劃不如變化！”。計劃很容易成為空話，特別是在軟件工程中，影響計劃的因素太多，計劃形同虛設了！但是，軟件進行項目管理的目的是綜合各種因素，制定合理的計劃，并通過計劃的實施，使其規(guī)范化，從而提高項目的效益，提高人員效率，降低項目的成本。
制定項目計劃首先對項目進行估算，粗算出項目的總體進度。然后進行精化：確定概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段等階段的具體要求、完成時間、投入人力物力，并確定幾個關鍵階段。這些關鍵階段的要求進度必須在指定日期之前完成。后做出項目進度表，列出在每個階段的難點要點，要注意的問題。，并將需要分析階段的內(nèi)容和項目計劃、進度表整理成文檔，分發(fā)到相關人員手上。
3、充分考慮影響項目計劃的因素，并做出相應的措施。
影響因素可以分為主觀因素和客觀因素。客觀因素有客戶相關風險，外部環(huán)境的影響，停電，機器損壞，不能上網(wǎng)等原因�？陀^因素在一定程度上可以轉(zhuǎn)變?yōu)橹饔^因素。主觀因素有：人的因素、技術因素，資源因素。人的因素，本項目是否有足夠的人手，投入本項目的每一個成員有沒有要兼顧其他事情、項目，人員的流動、休假甚至是離職，這些對本項目的計劃有多大的影響，并對此作處相應的不久措施。技術因素，本項目是否涉及到技術問題，所占比例是多少，以前是否有個類似的問題，新技術對本項目人員而言，新到什么程度，解決需要的技術問題。要注意，盲目追求新技術，也會影響項目的進度，甚至拖垮整個項目，成為技術先烈。還有一個技術問題是，本項目的人員，對要實施的軟件的行業(yè)背景的熟悉程度。根據(jù)這些因素決定是否對本項目的人員進行培訓��！資源因素，項目經(jīng)費是否充足，軟件配置，硬件配置是否及時充足�？偟膩碚f，可以把影響項目的計劃劃分為A—災難的 B－嚴重的 C－輕微的 D－可忽略的，對相應的等級作處相應的應變措施。
4 、根據(jù)計劃估算出成本。計劃一旦確定，可以通過人力資源成本、日常辦公費用、軟硬件的損耗等算出本項目的成本。
四、 項目的立項：
只要經(jīng)過管理方式的考慮，風險的評估，項目進度成本效益的衡量，再綜合其他方方面面的因素，做出決定，是否立項。
第三章 編碼的管理
在這里首先要聲明一點的是，雖然在這里并沒有著重強調(diào)系統(tǒng)設計，但系統(tǒng)設計是軟件工程管理的很重要的一部分。這里，項目確定計劃包含了系統(tǒng)設計。
在以前，甚至是在現(xiàn)在，也有相當大的一部分人是這樣認為的：軟件程序主要由代碼組成，因此編碼階段是整個軟件項目的重要的階段，應該給與大量的時間，并且集中主要的資源。
其實，與以前相比，由于軟件的規(guī)模和復雜度的增加，以及半自動化軟件代碼開發(fā)平臺的出現(xiàn)，現(xiàn)代軟件項目管理的中心發(fā)生了轉(zhuǎn)移--不是著重編碼階段，而是著重系統(tǒng)總體/詳細設計階段。一般說來，在現(xiàn)代軟件項目管理中各種資源的合理分配比例是：項目論證、風險評估階段3%，項目需求分析階段8%，系統(tǒng)總體/詳細設計階段45%，編碼階段10%，系統(tǒng)測試階段34%。
但是，如果軟件項目沒有實施好的話，頻繁地對軟件進行修改、甚至重做，編碼階段會耗費大量地時間，在整個軟件工程所占地時間比例也大大增加。很多軟件工程，不能按計劃完成是因為編碼階段的問題太多了。
