項目管理流程圖

風險評估軟件項目風險是指在整個項目周期中所波及的成本預算、開發(fā)進度、技術難度、經(jīng)濟可行性、安全管理等各方面的問題，以及由這些問題而對項目所產(chǎn)生的影響。項目的風險與其可行性成反比，其可行性越高，風險越低。軟件項目的可行性分為經(jīng)濟可行性、業(yè)務可行性、技術可行性、法律可行性等四個方面。而軟件項目風險則分為產(chǎn)品規(guī)模風險、需求風險、有關性風險、管理風險、安全風險等六個方面：產(chǎn)品規(guī)模風險項目的風險是與產(chǎn)品的規(guī)模成正比的，一般產(chǎn)品規(guī)模越大，問題就越突出。尤其是估算產(chǎn)品規(guī)模的措施，復用軟件的多少，需求變更的多少等原因與產(chǎn)品風險息息有關：估算產(chǎn)品規(guī)模的措施產(chǎn)品規(guī)模估算的信任度產(chǎn)品規(guī)模與此前產(chǎn)品規(guī)模平均值的偏差產(chǎn)品的顧客數(shù)復用軟件的多少產(chǎn)品需求變更的多少需求風險諸多項目在確定需求時都面臨著某些不確定性。當在項目初期容忍了這些不確定性，并且在項目進展過程當中得不到處理，這些問題就會對項目的成功導致很大威脅。假如不控制與需求有關的風險原因，那么就很有也許產(chǎn)生錯誤的產(chǎn)品或者拙劣地建造預期的產(chǎn)品。每一種狀況對產(chǎn)品來講都也許致命的，這些的風險原因有:對產(chǎn)品缺乏清晰的認識對產(chǎn)品需求缺乏認同在做需求分析過程中客戶參與不夠沒有優(yōu)先需求由于不確定的需求導致新的市場不停變化需求缺乏有效的需求變化管理過程對需求的變化缺乏有關分析等有關性風險許多風險都是由于項目的外部環(huán)境或原因的有關性產(chǎn)生的?？刂仆獠康挠嘘P性風險，能緩和方略應當包括也許性計劃，以便從第二資源或協(xié)同工作資源中獲得必要的構成部分，并察覺潛在的問題,與外部環(huán)境有關的原因有：客戶供應條目或信息交互組員或交互團體依賴性部或外部轉(zhuǎn)包商的關系經(jīng)驗豐富人員的可得性項目的復用性技術風險軟件技術的飛速發(fā)展和經(jīng)驗豐富員工的缺乏，意味著項目團體也許會由于技巧的原因影響項目的成功。在初期，識別風險從而采用合適的防止措施是處理風險領域問題的關鍵，例如：培訓、聘任顧問以及為項目團體招聘合適的人才等。有關技術重要有下面這些風險原因：缺乏培訓對措施、工具和技術理解的不夠應用領域的經(jīng)驗局限性對新的技術和開發(fā)措施應用不熟悉管理風險盡管管理問題制約了諸多項目的成功，不過不要由于風險管理計劃中沒有包括所有管理活動而感到驚奇。在大部分項目里，項目經(jīng)理常常是寫項目風險管理計劃的人，他們有先天性的局限性——不能檢查到自己的錯誤。因而，使項目的成功變得愈加困難。假如不正視這些棘手的問題，它們就很有也許在項目進行的某個階段影響項目自身。當我們定義了項目追蹤過程并且明晰項目角色和責任，就能處理這些風險原因：計劃和任務定義不夠充足對實際項目狀態(tài)不理解項目所有者和決策者分不清不切實際的承諾不能與員工之間的進行充足地溝通安全風險軟件產(chǎn)品自身是屬于發(fā)明性的產(chǎn)品，產(chǎn)品自身的關鍵技術非常重要。但一直以來，我們在軟件這方面的安全意識比較淡薄，對軟件產(chǎn)品的開發(fā)重要重視技術自身，而忽視了專利的保護。軟件行業(yè)的技術人員流動是很普遍的現(xiàn)象，伴隨技術人員的流失、變更，很能會導致產(chǎn)品和新技術的泄密，致使我們的軟件產(chǎn)品被它企業(yè)竊取，導致項目失敗。并且在軟件方面有關知識產(chǎn)權的認定目前還沒有明確的一種行業(yè)規(guī)，這也是我們軟件項目潛在的風險?；乇茱L險的方式以開發(fā)方誘導能保證需求的完整，使需求與客戶的真實期望高度一致。再以書面以便形成《顧客需求》這一重要的文檔，防止疏漏導致的損失在軟件系統(tǒng)的后續(xù)階段被逐漸地放大。設置監(jiān)督制度，項目開發(fā)中任何較大的決定都必須有客戶參與進行的，在該項目中項目監(jiān)督由項目開發(fā)中的質(zhì)量監(jiān)督組來實行。需求變更需要通過統(tǒng)一的負責人提出,并且要顧客需求的審核領導承認,需求變更應當是定期而不是隨時的提出,并且開發(fā)方應當做好詳細的記錄,讓客戶理解需求變更的實際狀況。控制系統(tǒng)的復雜程度，過于簡樸的系統(tǒng)構造，對顧客來使用比例會有明顯的折扣，甚至導致軟件壽命過短。反之，軟件構造的過于靈活和通用，必然引起軟件實現(xiàn)的難度增長，系統(tǒng)的復雜度會上升，這又會在實現(xiàn)和測試階段帶來風險。合適控制系統(tǒng)的復雜程度有助于減少開發(fā)的風險。從軟件工程的角度看，軟件維護費用約占總費用的55%~70%，系統(tǒng)越大，該費用越高。對系統(tǒng)可維護性的輕視是大型軟件系統(tǒng)的最大風險。在軟件漫長的運行期，業(yè)務規(guī)則肯定會不停發(fā)展，科學的處理此問題的做法是不停對軟件系統(tǒng)進行版本升級，在保證可維護性的前提下逐漸擴展系統(tǒng)。設定應急計劃，每個開發(fā)計劃都至少應當設定一種應急預案去應對出現(xiàn)突發(fā)狀況和不可遇知的風險。成本預算成本預算方式自上而下的預算措施自上而下的預措施重要是根據(jù)上層、中層項目管理人員的管理經(jīng)驗進行判斷，對構成項目整體成本的子項目成本進行估計，并把這些判斷估計的成果傳遞給低一層的管理人員，在此基礎上由這一層的管理人員對構成項目的子任務和子項目的成本進行估計，然后繼續(xù)向下一層傳遞他們的成本估計，直到傳遞到最低一層。使用此預算方式，在上層的管理人員根據(jù)他們的經(jīng)驗進行的費用估計分解到下層時，也許會出現(xiàn)下層人員認為上層的估計局限性以完畢對應任務的狀況。這時，下層人員不一定會體現(xiàn)出自己的真實觀點，不一定會和上層管理人員進行理智地討論，從而得出更為合理的預算分派方案。在實際中，他們往往只能沉默地等待上層管理者自行發(fā)現(xiàn)問題并予以糾正，這樣往往會給項目帶來諸多問題。自上而下更合用于項目啟動的前期，與真實費用相差在30%~70%之間。Scrum使用自上而下的成本預算方式，它不會立即精確地確定成本，而是以最大程度容納客戶對未來產(chǎn)品規(guī)定所產(chǎn)生的變更。自下而上的預算措施自下而上措施規(guī)定運用WBS（WorkBreakdownStructure，工作分解構造）對項目的所有工作任務的時間和預算進行仔細考察。最初，預算是針對資源（團體組員的工作時間、硬件的配置）進行的，項目經(jīng)理在此之上再加上合適的間接費用（如培訓費用、管理費用、不可預見費等）以及項目要到達的利潤目的就形成了項目的總預算。自下而上的預算措施規(guī)定全面考慮所有波及到的工作任務，更合用于項目的初期與中期，它能準備地評估項目的成本，與真實費用相差在5%~10%之間。注解：WBSWBS是面向提交成果對項目的分解，從提交成果的列表可以確定每個提交成果需要執(zhí)行的活動。Scrum會對WBS深入細化，把每個迭代分解為更細小的工作包。確定項目支出總體成本預算就是結合下列多種成本預算方式，構成開發(fā)的總體成本：零基數(shù)預算在成本預算的初期應當使用零基數(shù)的計算原則，而不可以使用類似于：以上一年總體費用加上20%這樣粗略的方式計算項目成本。軟硬件成本、物品成本物品成本是指類似于：服務器（RAM硬盤CPUNIC卡RAID簇）成本、維護成本、機房租金、光纖通訊成本、軟件成本等的成本。計算成本時需要考慮組裝硬盤需時的長短，技術人員需要具有的質(zhì)素，產(chǎn)品供應商能否提供保證質(zhì)量，管理時與否需要額外的管理人員這些多方原因。軟件許可證成本外包成本當使用類似：視頻、短信、移動電信類服務、門戶等子項目時可以考慮以外包形式完畢，以減少開發(fā)成本。人力資源成本計算人力資源成本時應當使用以最高和最低的工作效率估算平均效率的方式，計算出人力資源的平均成本。維修保養(yǎng)成本客戶溝通的過程從客戶溝通的方向出發(fā)來看，軟件項目可分為：需求識別、方案定制、項目實行、項目結束等4個不一樣的階段，各個階段都具有不一樣的溝通重點。需求識別階段文本溝通在需求識別的前期，應當通過問卷、原型展示、界面展示、邏輯處理展示、準化文檔模板等方式進行全方位多角度的分析，隨時將不明確之處反饋給客戶,以期待客戶解答。并以文本記錄的方式建立需要分析書，并規(guī)定客戶審核需求分析書，以到達需要分析與客戶的真實期望高度一致的成果。業(yè)務邏輯溝通在進行業(yè)務溝通時，應當理解客戶的行業(yè)語言，以增進業(yè)務分析的過程，越過應用需求和開發(fā)之間的鴻溝。溝通過程倡導以草圖或者可視信息化的方式進行,針對不一樣層面的企業(yè)顧客提供最適合的操作界面。以多角度的方式思索問題，要抓住需求重點,尤其是客戶方領導所關注的創(chuàng)新類和實用類需求。需求變更的規(guī)化管理需求變更在軟件開發(fā)類項目中是可以理解的,但必須對需求變更做好規(guī)化的管理，以防止出現(xiàn)需求無止境變更的風險。需求變更必須由統(tǒng)一的負責人提出,并且由顧客需求的審核領導者承認。需求變更的提出應當是定期而不是隨時的，開發(fā)方應當做好詳細的文本記錄,讓客戶理解需求變更的實際狀況和開發(fā)方為之所付出的成本代價。方案定制階段該階段項目的重要任務是與客戶共同制定一種此前期明確的需求、雙方的資源、項目開始的階段、實行的時間約定、項目費用限制等為基礎的具有可操作性的項目計劃,從本階段開始爭取客戶全面參與項目的管理，并以雙方的共同利益考慮項目實行的詳細計劃與風險規(guī)避。項目實行階段在該階段,軟件項目團體應當與客戶共同領導項目的實行。同步,項目團體應實時評估客戶滿意度,并通過持續(xù)改善的方式提高客戶滿意度,還應規(guī)定客戶參與必要的培訓,以及在必要時檢查項目產(chǎn)品。在出現(xiàn)客戶的需求變更前,應積極與客戶溝通交流,使客戶充足理解項目的每個環(huán)節(jié),以及變更帶來的影響,減少需求變更。假如出現(xiàn)客戶需求變更,應與客戶一起共同處理由變更引起的成本、進度、質(zhì)量變化。結束階段該階段重要進行項目成果的移交，并把系統(tǒng)交付給維護人員，協(xié)助客戶實現(xiàn)商務目的，結清多種款項。完畢這些工作后應當進行項目評估，審核此項目的成果并總結項目經(jīng)驗。售前人員注意事項在產(chǎn)品型項目作為開發(fā)成果時，有關銷售人員應當注意：對產(chǎn)品的推銷不應當過度承諾。假如過度承諾,會給后續(xù)的項目實行帶來困難;一旦承諾沒有兌現(xiàn),也會減少客戶滿意度,影響此后合作。假如有附加承諾,一定要以文本形式記錄，讓實行項目經(jīng)理知曉并傳達給項目組組員。注解：在軟件項目中,需要明確如下四種客戶角色要明確最終使用部門和顧客,要去理解他們既有的工作方式,要讓他們懂得項目的目的框架,懂得項目要處理他們的哪些困難,但絕對不是所有困難,這樣可以很好的控制項目圍。要明確需求的提出者,他或者他們要可以代表最終客戶群體。提出產(chǎn)品需求的此類客戶要具有一定的技術、業(yè)務能力和權威,可以真正代表最終客戶團體的意愿和想法,最佳有IT基礎,可以用IT語言描述問題和需求,以利于雙方的溝通、協(xié)作,防止產(chǎn)生歧義。要明確做需求確認的中層領導,他要把握方向。軟件開發(fā)項目是處理實際生產(chǎn)或者管理問題,同步也是領導系統(tǒng)建設的詳細實現(xiàn),做需求確認的客戶領導,既要理解高層領導的系統(tǒng)建設要點和方向,又要諳熟詳細業(yè)務和生產(chǎn)管理實際。假如是這樣的客戶領導來把握和決策,對企業(yè)軟件開發(fā)項目的順利進展作用不凡。要明確誰來對成品提意見,誰來驗收。項目驗收環(huán)節(jié),是項目的收尾環(huán)節(jié),假如驗收的人對項目初期的需求目的不理解,會從態(tài)度和產(chǎn)品實際使用效果上對驗收產(chǎn)生負面的影響,對提供產(chǎn)品的企業(yè)關閉項目非常不利。根據(jù)實踐總結,由需求提出人和確認人來做項目的驗收工作,可以增進項目的順利完畢,防止延期。需求分析需求分析的過程需求過程包括需求開發(fā)和需求管理2個部分：需求開發(fā)就是對開發(fā)前期的管理，與客房的溝通過程，可以分為4個階段：需求獲取、需求分析、編寫需求和需求驗證。需求管理：就是軟件項目開發(fā)過程中控制和維持需求約定的活動。包括：變更控制、版本控制、需求跟蹤、需求狀態(tài)跟蹤。需求的層次需求的層次包括：業(yè)務需求、顧客需求、功能需求、非功能需求等4個方面。需求開發(fā)階段的重點提取業(yè)務對象業(yè)務對象是指系統(tǒng)使用的真實對象，例如一種供應鏈管理(SupplyChainManagement,簡稱SCM)業(yè)務對象重要包括：生產(chǎn)批發(fā)商、零售商、送貨商、顧客多種層次。提取業(yè)務流程在理解業(yè)務邏輯的過程中，應當列舉出所開發(fā)軟件模塊的各自職能，并細化每個工作流程，深入分析業(yè)務邏輯。性能需求在分析的前期應當注意客戶對所開發(fā)軟件的技術性能指標，如存儲容量限制、運行時間限制、安全性等。環(huán)境需求環(huán)境需指軟件平臺運行時所處環(huán)境的規(guī)定，如硬件方面：機型、外部設備、數(shù)據(jù)通信接口;軟件方面：系統(tǒng)軟件，包括操作系統(tǒng)、網(wǎng)絡軟件、數(shù)據(jù)庫管理系統(tǒng)方面;使用方面：使用部門在制度上，操作人員上的技術水平上應具有怎樣的條件?？煽啃孕枨髮λ_發(fā)軟件在投入運行后發(fā)生故障的概率，應當按實際的運行環(huán)境提出規(guī)定。對于重要的軟件，或是運行失效會導致嚴重后果的軟件，應提出較高的可靠性規(guī)定。安全規(guī)定在需要分析時應當在這方面恰當?shù)刈龀鲆?guī)定，對所開發(fā)的軟件予以特殊的設計，使其在運行中，其安全面的性能得到必要的保證。顧客界面需求為顧客界面細致地規(guī)定抵達的規(guī)定。資源使用需求開發(fā)的軟件在運行時和開發(fā)時所需要的多種資源。軟件成本消耗與開發(fā)進度需求在軟件項目立項后，根據(jù)協(xié)議規(guī)定，對軟件開發(fā)的進度和各環(huán)節(jié)的費用提出規(guī)定，作為開發(fā)管理的根據(jù)。開發(fā)目的需求預先估計后來系統(tǒng)也許到達的目的，這樣可以比較輕易對系統(tǒng)進行必要的補充和修改。需求分析的任務需求分析的重要任務是借助于目前系統(tǒng)的邏輯模型導出目的系統(tǒng)的邏輯模型，其流程如下：確定對系統(tǒng)的綜合需求（功能、性能、運行、擴充需求）制作產(chǎn)品需求文檔(PRD)分析系統(tǒng)的數(shù)據(jù)需求（概念模型、數(shù)據(jù)字典、規(guī)化）導出目的系統(tǒng)的詳細的邏輯模型（數(shù)據(jù)流圖、數(shù)據(jù)字典、重要功能描述）開發(fā)原形系統(tǒng)從PRD提取編制軟件需求規(guī)格闡明書（SRS）備注：SRS格式1.引言2系統(tǒng)概述（項目背景、系統(tǒng)目的、關鍵業(yè)務流程）3.術語闡明4.系統(tǒng)構造（架構圖、功能圖）5.主體功能與業(yè)務邏輯（重點）6.接口需求（部、外部接口、）7.網(wǎng)絡總體設計（拓撲網(wǎng)絡、主機、組網(wǎng)）8.運行環(huán)境（Linux、Windows、IIS、WebLogic、Tomcat、OLAP、OLTP、JDK8.0、.NETFramework4.0等）面向?qū)ο蟪绦蛟O計（略）設計原則SRP單一職責鏈每個類都應當只負責做一件事。OCP閉合原則軟件的實體（類、模塊、函數(shù)等）應當是可以擴展的，不過不可修改的。LSP替代原則子類必須能替代他們的基類型。DIP依賴倒置原則高層模塊不應當依賴于低層模塊，兩者都應當依賴于接口與抽象類。抽象不應當依賴于細節(jié)，細節(jié)應依賴于對象。ISP接口隔離原則不應當強迫客戶依賴于并未使用的接口，而應當把胖接口分離。實現(xiàn)UML建模業(yè)務對象的提取根據(jù)SRS、CRC等實現(xiàn)用況建模實現(xiàn)業(yè)務次序圖建立類圖，根據(jù)用況圖建立對象之間的關聯(lián)繪制活動圖、實現(xiàn)協(xié)作圖、狀態(tài)圖開發(fā)管理建立項目計劃設計總體架構針對系統(tǒng)的實行需要，采用合適的且成熟的框架構造?？刂瓶蓴U展度擴展度過大，將提高系統(tǒng)的復雜程度，延長開發(fā)時間；擴展度過低，會直接影響系統(tǒng)的二次開發(fā)與維護?？刂葡到y(tǒng)的可擴展性，能提高開發(fā)效率，減少系統(tǒng)維護的難度。建立基礎設施合理分派軟、硬件等基礎設施的布署所需要的時間與成本（例如：服務器的訂購安裝、光纖接入、軟件平臺訂購）。劃分開發(fā)任務運用WBS（WorkBreakdownStructure，工作分解構造）對可交付成果進行分類與劃分。每個項目都能劃分為多種不一樣階段，每個階段又可以分為多種工作包（WorkPackage），工作包是WBS里最小的可交付成果，最終從工作包中分解出多種開發(fā)任務列表。布署開發(fā)進度一種項目應當按進度劃分為多種開發(fā)階段，每個階段的開發(fā)周期一般在30~60個工作日以。在此階段應當與客戶舉行協(xié)商會議，制定產(chǎn)品路線圖，在開發(fā)過程中邀請客戶積極參與并提出反饋意見。然后把該時段的開發(fā)任務按照開發(fā)難度，依賴性，重要性等多方條件劃分為多種迭代周期。在Scrum敏捷軟件開發(fā)原則中，應當把每個迭代任務深入細分為多種開發(fā)任務列表，開發(fā)任務的開發(fā)時間應當控制在15個工作小時以，假如開發(fā)時間超過15個工作小時，應當考慮把開發(fā)任務再度細化。開發(fā)任務提議應當由組員自主選擇，而不要使用強制分派的方式。測試項目成果每個工作包都應當同步布署測試工作，提高項目的質(zhì)量。對出錯BUG的工作包應當由測試人員以文本方式記錄，向開發(fā)人員展示錯誤所在，讓開發(fā)人員及時進行修改。管理開發(fā)團體組建團體按照工作任務與項目時間的前提條件建立團體，按團體職責分派人員，一般團體人數(shù)應當控制在8~12人之間。當團體人數(shù)超過15人時，應當考慮把團體分解成2個獨立團體，負責不一樣的開發(fā)任務。分派開發(fā)任務在每個迭代周期（一般是15~30個工作日），應當把每個工作包深入細分為多種開發(fā)任務，開發(fā)任務的開發(fā)時間應當控制在15個工作小時以，假如開發(fā)任務的開發(fā)時間超過15個工作小時，應當考慮把任務再度細化。而開發(fā)任務應當以自由選擇的方式分派給每個組員。監(jiān)督開發(fā)進度在迭代的前期舉行一次會議，讓組員理解開發(fā)的進展及流程，并以自主選擇的方式分派開發(fā)任務。期間可使用MicrosoftProject等工具記錄開發(fā)流程的進展，在每個工作包完畢開發(fā)后應當進行性功能的測試，并以文本方式記錄測試成果。每天舉行一次15分鐘的站立會議，讓組員交待昨天已完畢的開發(fā)任務，當日將要做的任務，與開發(fā)過程中所碰到的問題。并在每周末舉行一次例行會議，交待總體進程。在迭代末期舉行一次沖刺會議，總結項目的進展，交行已完畢的任務，回憶該迭代周期所碰到的問題，為下一種迭代做好準備。系統(tǒng)測試對每個已完畢的工作包進行適時的測試，保證系統(tǒng)質(zhì)量與性能。對測試成果進行文本的記錄，并把測試成果與績效工資收入掛鉤，并以真實數(shù)據(jù)計算組員的績效收入。處理開發(fā)中所碰到的問題對開發(fā)人員進行前期培訓，可合適按工作能力分派任務，指導組員的開發(fā)。當碰到問題時應當在當日的站立會議時即時提出，并在15個工作小時處理所碰到的問題以防止問題深入擴大。監(jiān)管產(chǎn)品質(zhì)量質(zhì)量需要的是計劃、設計而并非審查的。在產(chǎn)品建立的初級，必須與“質(zhì)量保證”（QA）的部門進行協(xié)商，以正式文檔的方式，決定恰當?shù)馁|(zhì)量方略和原則。在開發(fā)過程中使用TDD（測試驅(qū)動開發(fā)）的模式，提高開發(fā)質(zhì)量。測試人員應當以文本方式記錄bug，并與開發(fā)人員共同工作的，把突出的缺陷演示給開發(fā)人員，以提高修改的效率。在每個迭代的結束時進行一次產(chǎn)品效果的演示，從客戶、使