軟件項目實施過程控制

項目實施過程控制項目管理綜述科學且具有可操作性的項目管理方法，是歷史數(shù)據(jù)管理項目成功的重要砝碼。方法是對不同類型的項目所獲得的經(jīng)驗提煉和總結(jié)，明確定義了如何管理項目。總體而言，有三個主要領域:項目管理領域：為項目管理活動如何進行提供指導；項目管理工作模式：滿足項目管理目標或者應付特定項目管理情形的一系列步驟；項目管理工具模版：經(jīng)過驗證的輸出，用來進行項目管理，并與項目管理領域相結(jié)合。相應地，項目管理工作范圍包含以下主要活動,與我們的工作計劃相一致。在項目過程中要執(zhí)行的項目管理活動如下:?開發(fā)規(guī)范；?項目計劃和控制；?溝通管理；質(zhì)量控制；風險控制；項目實施管理；問題管理；?人員管理；?變更革管理。管理目標及優(yōu)先級基本管理原則：每位組成員既是積極的建言者，又是負責的合作者，同時也是決策的制定者。決策應在充分的討論基礎上由大家共同做出，一旦決策做出就必須被及時有效的執(zhí)行。禁止再有異議。1）按時按量完成項目的基本功能，按時發(fā)布產(chǎn)品及文檔，這是本團隊的最高目標。2）遵循規(guī)范化的項目運作標準，文檔嚴謹完整，代碼注釋充分，便于后續(xù)維護，這是第二目標。3）產(chǎn)品運行穩(wěn)定，界面友好，用戶易操作，盡量從用戶的角度去看問題，并提出解決問題的方案。4）注重團隊建設，成員分工合理，團隊成員合作默契，氣氛融洽。每周的討論會積極建言。在開發(fā)過程中積極協(xié)作。5）項目設計和開發(fā)上盡量有創(chuàng)新，有亮點。風險管理管理項目可能存在的風險，在進行項目計劃時需要進行風險分析并制訂風險管理計劃，該計劃作為項目計劃的一部分進行描述。風險管理應貫穿于項目工程的始終。風險管理不是項目經(jīng)理一人的任務，也不是一次性的任務。它是一個迭代的過程，各項目成員都有責任進行風險管理。建立一種有助于對潛在的風險及其發(fā)生的可能性和影響進行交流的環(huán)境對項目經(jīng)理來說是相當重要的。風險管理是項目管理者最重要的工作之一。風險管理是一個持續(xù)的過程,貫穿于整個項目過程中,風險管理包括風險識別、風險評估、風險解決以及風險管理策略。在項目的實施過程中需要不斷地識別和應對風險,并加以有效的控制,風險管理的好與壞直接影響項目的實施效果,從某種意義上講,項目實施對于項目管理者就是識別、分析、應對、控制風險的過程,使項目的約束性目標和質(zhì)量目標朝有利的方向發(fā)展。項目不同于日常任務,它有明確的起止時間和目標,要在明確的范圍、時間和成本約束下,達到相應的質(zhì)量標準,并取得用戶的滿意。影響項目成敗的因素涉及方方面面,并且風險伴隨著項目的始終,是客觀存在的,作為一個項目管理者,應該具備良好的風險控制意識,善于識別風險并分析風險的影響,從中發(fā)現(xiàn)影響目標的風險點,并施加影響或采取應對措施,把風險的負面影響降到最低,并且風險控制應該貫穿項目始終。風險引起的負面后果集中體現(xiàn)在進度延后、成本超支、質(zhì)量不達標等方面,導致這些問題的因素主要包括目標以及需求不明確、范圍蔓延以及需求變更、代碼質(zhì)量或返工風險、人員技能和資源的不足、缺乏良好的團隊協(xié)作等。在制定風險管理計劃時，主要包括如下活動：1、在項目規(guī)劃時，通常要對項目進行風險分析。風險分析通常是由項目經(jīng)理和項目組成員參照《組織風險選擇列表》以及曾經(jīng)開發(fā)過的項目所積累的經(jīng)驗來進行。2、項目經(jīng)理《組織風險選擇列表》以及曾經(jīng)開發(fā)過的項目所積累的經(jīng)驗識別風險，并將識別出的風險記錄到《風險管理》之項目風險計劃中。3、項目經(jīng)理將每類風險的可能性和影響程度記錄到《風險管理》之項目風險計劃中。4、計算風險值和風險等級。對每個風險計算風險值，風險值=可能值*影響值。然后對每個風險確定其等級。5、確定風險優(yōu)先級。由于每個項目的資源都是有限的，所以風險管理（處理、減緩、監(jiān)視和控制）必須把精力集中在這種最重要的風險子集上。6、對風險分類?？梢园扬L險進行分類，即相關(guān)的風險分組到一起：這些風險可能需要相似的風險處理或者可能會在同一領域發(fā)生反面影響。這種分組有助于理解風險的本質(zhì)，并且會導致更為有效的風險處理和減緩計劃。7、確定風險的復評估間隔，對于1級風險在項目周例會上要定期進行跟蹤并報告執(zhí)行情況；對于2級風險則在里程碑會議上對風險進行報告。8、項目經(jīng)理將風險等級、排出的風險優(yōu)先級以及對每個風險的分類，記錄到《風險管理》的項目風險計劃表中。下面將詳細描述一下這些問題以及出現(xiàn)這些問題時的應對方案:1、目標以及需求不明確為了市場競爭或內(nèi)部管理決策的需要,業(yè)務部門提出的需求往往要求的時間比較緊迫,需求的提出大多停留在幾張紙或口頭的傳達上,沒有形成正式的業(yè)務需求文檔,在沒有明確的需求范圍的情況下,有時為了迎合業(yè)務部門的口味匆匆開工,過程中用戶不斷地提出新的想法,技術(shù)人員開始疲于奔命和應付,很難保證項目的進度和質(zhì)量,也難以取得業(yè)務部門的認可。所以,在項目的前期一定要采取相應的手段或措施,與業(yè)務部門共同明確項目目標、需求范圍,充分考慮現(xiàn)有的時間和資源約束,將需求排定優(yōu)先級,對于關(guān)鍵的需求優(yōu)先實現(xiàn)，其他輔助性的根據(jù)過程中的具體情況進行滾動式計劃，并取得業(yè)務部門的書面確認。在此過程中要注重挖掘用戶的隱性需求，可以通過引導、系統(tǒng)原型等手段讓用戶在前期充分暴露自己的想法和需求。2、范圍蔓延以及需求變更在有了明確的目標和需求范圍的情況下，需求的變更還是不可避免的，業(yè)務部門在看到具體系統(tǒng)的真實雛形之后，源源不斷地要求、新想法隨之產(chǎn)生，如果不對此加以控制，新的需求的加入通常會影響已實現(xiàn)的需求，并且對項目進度和成本產(chǎn)生很大的影響。項目管理者針對這種情況一定要采取嚴格的變更控制流程，不能礙于面子，否則最終的結(jié)果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請，組織相關(guān)團隊成員進行分析及評估，作為是否實施的依據(jù)，變更控制負責人根據(jù)分析結(jié)果判斷是否批準，如果批準，那項目組可以安排實施，否則，正式拒絕用戶的請求，當然實際情況下可以采取一些軟措施緩解矛盾。需求變更風險：需求已經(jīng)打上了基線，但此后仍然有變更發(fā)生，對項目造成影響。如何減少此類風險的發(fā)生？前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項目中需求的決策者（通常會是產(chǎn)品經(jīng)理、相關(guān)職能主管、客戶，所有的需求要經(jīng)過他們的認可?？蛻粼陧椖窟^程中的全程參與有助于降低此類風險。需求討論、需求確認、UserCase確認、測試階段的客戶驗收等環(huán)節(jié)，都要要求客戶參與。在發(fā)生需求變更時，嚴格按照需求變更流程執(zhí)行。在分析設計階段的中的確認和評審也是降低此類風險的重要手段。3、代碼質(zhì)量或返工風險質(zhì)量風險主要指開發(fā)代碼的質(zhì)量。如何提高開發(fā)人員開發(fā)的質(zhì)量？在制定項目計劃時，對開發(fā)時間的評估要盡可能的合適。合理的開發(fā)時間對開發(fā)質(zhì)量的影響也很大。有時開發(fā)人員為了趕進度在比較緊張的時間需要完成指定的任務，可能就存在很大的開發(fā)質(zhì)量問題。開發(fā)要有一套嚴格可行的代碼規(guī)范，編碼時嚴格遵守，到現(xiàn)在為止，我們這個方面做的不是很規(guī)范，做的也很不足，大家編寫的代碼隨意性比較大，代碼編寫者的主觀意識性比較強。要建立一套大家認可并且規(guī)范可行的編碼規(guī)范和考核規(guī)范，codereview時嚴格考核。在編碼前，開發(fā)人員要對框架熟練掌握；一份好的系統(tǒng)設計文檔對指導開發(fā)非常重要。返工是項目組最不愿意看到的，既浪費人力、物力和財力，又影響團隊積極性。需求不明確或范圍沒有有效控制都可能造成返工，另外造成返工的原因是質(zhì)量沒有達到用戶要求。往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是100%完成，但一到最后系統(tǒng)交互測試或集成的時候就會發(fā)現(xiàn)一大堆問題，不得不花費很大精力回頭排查、修改程序，造成這種情況的主要原因是過程中質(zhì)量保證沒有做到位，把大部分問題留在了后面。這就需要在項目實施過程中采取有效的措施來規(guī)避返工的風險，通常的做法有同行評審，比如概要設計完成之后，邀請其他項目組的技術(shù)專家進行技術(shù)評審以發(fā)現(xiàn)架構(gòu)設計問題；管理評審，通過組織級的質(zhì)量審計看產(chǎn)品以及實施過程是否滿足質(zhì)量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規(guī)范或性能要求的代碼，走查通常能夠發(fā)現(xiàn)50%-70%的錯誤；每日構(gòu)建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠及時發(fā)現(xiàn)相應的錯誤，日構(gòu)建一般在項目的中后期開始，每天自動從版本服務器上獲取源代碼進行自動編譯和測試。4、人員技能和資源的不足項目實施過程中由于人員技能欠缺造成的進度延后和軟件質(zhì)量問題并不少見，一個熟練的技術(shù)人員完成同樣一個任務需要3天，但一個生手可能就需要7-10天。項目管理者應該在前期就分析清楚項目所要采用的技術(shù)以及相應的人員技能要求，針對不同的角色，及時采取相應的技能培訓，以保證項目的順利實施。如果對于項目中某些部分專業(yè)性特別強或新技術(shù)，短期內(nèi)又不能快速建立技能的情況，可以考慮將該塊任務外包，借鑒合作商的力量降低實施風險，當然要進行外購人力成本與自建人力成本的效益分析。開發(fā)過程中遇到技術(shù)難題，導致開發(fā)時間延遲或者需求不得不發(fā)生變更。如何減少此類風險的發(fā)生？在項目開始前的技術(shù)評估階段，明確技術(shù)難點，提前安排人員進行攻克。如果在可預期的時間內(nèi)無法解決，如果可以，將向需求提出方要求變更需求或?qū)ふ铱商娲桨浮＿@樣的風險應該在項目的前期階段就應該解決在萌芽狀態(tài)來避免這樣的風險在后期或中期出現(xiàn)。項目所需人力資源無法按時到位，導致資源風險。如何減少此類風險的發(fā)生？這個就需要在項目計劃制定的時候提前申請確認資源，并在項目過程中不斷溝通協(xié)調(diào)。5、缺乏良好的團隊協(xié)作軟件項目實施屬于知識型，要發(fā)揮團隊成員的創(chuàng)造力，不同于制造業(yè)計件生產(chǎn)，各模塊最終要集成在一起形成一個有機的整體，這就需要各小組之間的密切配合，界定清楚工作界面及接口關(guān)系，并在實施過程中持續(xù)地溝通交流和共享，首先團隊要融為一體，產(chǎn)出的軟件才能融為一體。這是一個團隊的軟實力，團隊之間的協(xié)作好壞也將是個潛在的風險問題，在項目啟動和團隊組建的時候就應該加以規(guī)避這樣的風險出現(xiàn)。項目風險管理的要點：1、上述我們所說的風險管理都是指可以預期將要發(fā)生的風險，那些不可預期將要發(fā)生的風險不屬于風險管理的范疇。這也將是考驗一個項目管理者的經(jīng)驗和知識對能否管理好風險至關(guān)重要的內(nèi)容。2、對不可預期的風險，項目管理者要有潛在的風險意識評估，做好一些可操作性的預案準備。3、詳細明確的項目計劃、以及項目執(zhí)行過程中每個要點的質(zhì)量保證是降低項目風險的必要條件。4、風險報告是項目團隊以及領導了解項目風險的一個有效手段。風險報告的格式：序號風險簡介對項目的影響解決方案或?qū)Σ摺?、團隊管理團隊就是一組個體為實現(xiàn)共同的目標而相互依賴、一起工作的共同體。團隊工作顧名思義就是團隊成員為實現(xiàn)這個共同的目標而付出的共同努力，項目團隊的工作是否有效直接關(guān)系到項目的成敗。團隊管理是個漸進的過程。世界上只有完美的團隊，沒有完美的個人。好的高效的團隊不是管理出來的，而是營造出來的。團隊成員需要有大家可認同的團隊文化，這需要大家共同的努力。營造良好的工作環(huán)境和氛圍。建設優(yōu)秀或鮮明的團隊文化。保持高效的溝通。6、項目會議組織會議是項目管理者日常工作中一項非常重要的工作任務，項目過程中很多重要的決定都是在會議中做出的，也有很多由于不成功的會議而對項目本身造成了不好的影響。首先看看不成功的會議常常表現(xiàn)為哪些形式：1）會議氛圍不好，參與者發(fā)言不踴躍；2）會議討論常常偏離主題；3）會議沒有取得預期的結(jié)果；4）會議時間常常一拖再拖。這些不成功的會議最終的結(jié)果就是：既浪費了大家的寶貴時間又沒有達到會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是深惡痛絕。以下是組織會議時應該注意的問題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必須要清楚：1）會議是否會取得成功很大程度上取決于會議的組織者。只有組織得有力，會議才有可能取得成功，這是會議成功的充分條件。2）會議的組織者和參與者的想法通常是不一致的，有時候甚至會大相徑庭。所以不要希望會議的參與者和你一樣，對會議有著如此的期待，對大多數(shù)參與者而言，在會議中他只是一個發(fā)表想法的人，他不用對會議的成功承擔責任。3）以下十一條最佳實踐是形式上的約定，具體的實施可以根據(jù)實際情況來做。組織會議的十一條最佳實踐：1）只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。2）提前發(fā)出會議議程，以便會議參與者知道他們來做什么。3）請對人很重要，不要把非必要的人召來開會，當然也不要漏掉那些關(guān)鍵人物。在確保必要人物都在的情況下一次會議參與者越少效果越好。4）提前預約參與者的時間，以確保他們能按時到場。5）會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾點要在開場時說：再一次強調(diào)會議的目標，我們來做什么。強調(diào)會議的主題與基調(diào)。比如：本次會議是一個需求確認會，而非需求討論會，主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討論如何做上面。說明一下會議的規(guī)則。如要發(fā)言，請舉手；不要有小圈子討論；不要打斷別人的講話，等別人說完你再說等等。6）會議過程中時刻注意引導和控制會議，以確保會議按照目標進行。一次會議的氛圍是否良好，討論是否充分，好的引導至關(guān)重要。比如多提一些開放式的問題。7）會議記錄很重要，把一些結(jié)論和有價值的內(nèi)容記錄下來，這些是本次會議的重要成果之一。8）會議要有結(jié)論。我們常在會議上聽到有人說："大家討論了這么半天，結(jié)論呢？"。沒有結(jié)論的會議是沒有意義的。9） 會議后別忘發(fā)會議紀要，以及一些Action,什么人什么時候做什么。10） 會議后的action執(zhí)行情況的反饋很重要。反饋是對會議參與者的尊重，同時也告知了會議的效果。否則會讓大家感覺到這是一個可無可無的會議，大家以后參與的積極性也會降低。很多會議往往都不注意這一點。11） 按時結(jié)束的會議會受到所有人的歡迎。7、版本控制版本控制也是項目管理者的一個重要工作內(nèi)容之一，一個項目或產(chǎn)品的完成不可能是一步到位的，在項目完成的后期可能會有多個不同的版本的發(fā)布（開發(fā)版本，測試版本，發(fā)布版本等）。需要做好版本的管理和控制。8、項目總結(jié)在項目完成后，總結(jié)整個完成項目的過程和經(jīng)歷，為下一次的項目啟動提供參考經(jīng)驗，完善不足，避免在類似的項目中出現(xiàn)可能存在的相同的錯誤發(fā)生。人員流失風險控制我公司將派出一支經(jīng)驗豐富的項目團隊來負責項目實施，這支團隊包括很多資深人員，并且都成功實施了多個SAS系統(tǒng)的項目，可以確保項目按計劃、高質(zhì)量的交付。我公司建立了一系列吸引人才的制度和管理辦法，確保技術(shù)人員的穩(wěn)定，降低因技術(shù)人員流失而給企業(yè)帶來的風險；公司采取社會聘用和每年招收一定量的高等院校畢業(yè)生的措施，及時補充，由于不斷發(fā)展而造成的技術(shù)、管理人才的需求。針對不同的需要，定期對公司員工進行各方面的培訓。采用重獎等方式，激發(fā)骨干力量的工作積極性。本企業(yè)在技術(shù)管理方面也建立了一整套保密制度，以確保本項目技術(shù)不流失、不擴散。我公司將進一步加強對人力資源的建設和管理，不斷完善人力資源體系，對公司團隊的穩(wěn)定發(fā)展起到積極的作用。為配合企業(yè)經(jīng)營戰(zhàn)略和業(yè)務發(fā)展要求，在人員管理策略上，秉承一貫的關(guān)注人才、注重核心團隊的建設與培養(yǎng)外，注重人員引進的質(zhì)量以及科學管理，包括引入人才測評體系、任職資格管理、人員信息查詢管理等方面。采取股權(quán)激勵政策，保證骨干力量的穩(wěn)定性，避免人才流失。進度控制控制進度是監(jiān)督項目狀態(tài)以更新項目進展、管理進度基準變更的過程。進度控制需要判斷項目進度的當前狀態(tài)；對引起進度變更的因素施加影響；確定項目進度是否已經(jīng)發(fā)生變更；在變更實際發(fā)生時對其進行管理?？刂七M度是實施整體變更控制過程的一個組成部分。項目設計認可里程碑是客戶和項目組就交付的內(nèi)容、構(gòu)建的優(yōu)先級和期望值達成一致意見的重要機會。它提供了重新評估風險和重新驗證早期對時間進度和資源使用估計的機會。項目組的每一種角色都提供一份計劃和時間進度文檔，用于描述如何構(gòu)建功能規(guī)定中的產(chǎn)品。項目計劃精煉了前景/范圍文檔中客戶和項目組達成一致意見的部分。所以一份好的項目設計和計劃是：?從整體目標、使用者分類和每類使用者期望執(zhí)行的活動中得到的。?將客戶的期望分類成一系列的邏輯服務：用戶服務、業(yè)務規(guī)則服務和數(shù)據(jù)服務。這些服務統(tǒng)稱系統(tǒng)的邏輯結(jié)構(gòu)。明確定義界面設計、功能接口、數(shù)據(jù)需求、幫助系統(tǒng)和培訓過渡活動等。定義外部接口、交互性目標、性能指標和其它應用到解決方案上的假設和限制。反映組隊角色所有成員一致的承諾。?控制內(nèi)部的時間進度和外部交流?；诶锍瘫姆椒ㄊ且环N重要的設計、評估和協(xié)調(diào)客戶與項目組之間關(guān)系的過程。外部可見性過程模型中的主要里程碑是整個項目組同步他們交付的內(nèi)容，滿足客戶期望的時間點。項目設計和交付的內(nèi)容可能會根據(jù)項目結(jié)果不同而不同。當項目開始時不可能了解所有的事情，是項目開發(fā)過程中不可避免的。里程碑是復查點，而不是凍結(jié)點過程模型中的五個里程碑允許客戶和項目組重新確認，或調(diào)整項目的范圍和使用者的期望。目標驅(qū)動的方法里程碑上交付的內(nèi)容包含了每一個階段的目標。明確的交流明確的交流是項目成功的潛在因素。進度變更管理辦法項目相關(guān)各方有權(quán)對需求、工作任務、進度要求、人員調(diào)動等提出項目變化請求，項目變化提出方或發(fā)現(xiàn)方需填寫項目變化報告，說明變化前的狀態(tài)、變化原因、變化的內(nèi)容，并提交對方的項目經(jīng)理，需求調(diào)研結(jié)束后的由客戶方提出的需求變更需得到我方的認可；如果項目變化被拒絕，項目經(jīng)理應該負責解釋原因，并填入項目變化報告；如果項目變化被接受，雙方的項目經(jīng)理重新制訂該項目變化引起的工作量、預算、時間計劃、人員安排等方面的影響，并將此內(nèi)容填入項目變化報告。如該變化涉及第三方或轉(zhuǎn)包方，雙方的項目經(jīng)理必須將有關(guān)分包方的項目變化，并要求分包方重新制訂相應的計劃；雙方的項目經(jīng)理在接到對方變更請求后2個工作日之內(nèi)，應給予變化提出方明確答復；參與項目合作的相關(guān)各方在項目變化報告單上簽字認可后，該項目變化生效，項目經(jīng)理執(zhí)行變化實施；項目經(jīng)理根據(jù)項目變化報告單中進度的變化情況，修改項目進度計劃，調(diào)整項目組人員組織結(jié)構(gòu)，以及項目組成員的工作安排，修改項目預算等；我方對于重大的項目變化，項目經(jīng)理應將項目變化報告提交客戶經(jīng)理，提請客戶經(jīng)理對于項目變化所引起的商務問題與客戶進行協(xié)商；將項目變化報告單以及該變化所引起的進度計劃、計劃預算、人員組織結(jié)構(gòu)、工作說明書等方面修改版本的提交項目相關(guān)各方；對于由于項目變化所產(chǎn)生的項目文檔、代碼等修改，遵照我方軟件項目管理規(guī)范之項目變化管理實施規(guī)范執(zhí)行；項目組成員以及項目相關(guān)人員有義務及時發(fā)現(xiàn)各種項目變化，并通報項目經(jīng)理；項目經(jīng)理有責任追蹤項目變化的各項工作過程，直至變化管理工作完成項目按新的項目計劃執(zhí)行。變更參照基準有變化就有參照，同樣，項目中的變更也有其參照系，參照系的原則是按照項目進程形成的各種有效文檔，具體如下：?項目合同?項目合同中的《系統(tǒng)功能說明》項目管理方案需求分析階段的《需求規(guī)格說明書》概要設計階段的《概要設計說明書》評審形成的結(jié)論重要會議紀要形成的有效決議已經(jīng)確認接受的需求變更項目變更表

為保證項目的可管理性，需要對實施過程中的變更進行統(tǒng)一的管理，這樣有利于項目風險控制，以保障項目的順利實施。因此，我方設計了如下是項目需求變更的登記表，通過Excel表格集中管理項目變更。項目名稱項目編號變更申請人申請日期變更類型□新增需求口需求變更口內(nèi)部改進□產(chǎn)品缺陷□系統(tǒng)環(huán)境變更□其他變更描述［描述引起變更的原因］［描述變更的內(nèi)容］變更影響的配置項序號配置項影響描述當前版本1《用戶需求規(guī)格說明書》增加用戶需求說明，提交新版本V1.02《概要設計說明書》修改XX內(nèi)容V1.03變更評審方式□項目組裁決口召開評審會議口會簽評審口郵件評審評審意見［考慮的不利因素：對產(chǎn)品/系統(tǒng)的影響、對接口的影響、對項目進度的影響、對工作量的影響、…］［有利因素：產(chǎn)品/系統(tǒng)改進，適應性，可用性，安全性，性能，友好性…］變更對進度的影響變更對成本的影響，即人月的變化變更對質(zhì)量的影響評審結(jié)論□可以更改口拒絕變更用戶確認［同意/不同意評審結(jié)論］

項目經(jīng)理確認［同意/不同意該變更內(nèi)容］簽字日期簽字日期變更處理流程奎更管理過程竟更詢認、變更豎璉■記錄蠻更孌更提交A2.審股蓋更 1 .3勢配変更申溝申竟更詢認、變更豎璉■記錄蠻更孌更提交A2.審股蓋更 1 .3勢配変更申溝申篩戀更腔制査員會宀CC3E埶行変更申苗14亞更取目實確團從配K管理S變更控制委員會變更控制委員會采用分級控制的方法，要結(jié)合簡化辦事效率和保證風險可控的原則，對于簡單的需求變更由二級變更委員會評估，對于影響較大的變更由一級變更委員會來進行評估決策。變更控制委員會由貴公司和雙方共同組成，人員在第一次項目啟動會議中確定。項目質(zhì)量控制質(zhì)量管理在本項目的實施過程中，公司將對項目實施執(zhí)行嚴格的質(zhì)量管理，以確保：?整個系統(tǒng)的質(zhì)量?移交給貴公司各項交付內(nèi)容的質(zhì)量項目實施各階段工作的質(zhì)量客戶對本項目的實施滿意程度質(zhì)量管理內(nèi)容質(zhì)量控制必須在開發(fā)生命周期中的每一個階段都被重視，如需求分析、架構(gòu)設計、詳細設計、文檔和代碼等。質(zhì)量管理工作將指定專人負責，并按公司訂立的質(zhì)量審查、檢核、記錄、評估及更正的執(zhí)行程序，公司將在項目實施的各個階段對如下內(nèi)容予以質(zhì)量管理：需求規(guī)格說明書系統(tǒng)概要設計說明書系統(tǒng)詳細設計說明書系統(tǒng)測試方案系統(tǒng)測試報告系統(tǒng)安裝手冊系統(tǒng)用戶手冊系統(tǒng)維護手冊系統(tǒng)培訓報告系統(tǒng)試運行報告項目階段總結(jié)報告系統(tǒng)源代碼和執(zhí)行腳本文檔編寫的一致性資料定義及資料使用的一致性測試案例的完整性與可行性客戶配合程度的考慮與可行性?系統(tǒng)學習的易懂性?系統(tǒng)操作的方便性是否使用適當?shù)姆治?、設計及測試技術(shù)和工具質(zhì)量管理準則質(zhì)量管理工作將指定專人負責，并按公司訂立的質(zhì)量審查、檢核、記錄、評估及更正的執(zhí)行程序，依據(jù)以下準則進行：文檔編寫的一致性資料定義及資料使用的一致性測試案例的完整性與可行性客戶配合程度的考慮與可行性系統(tǒng)學習的易懂性系統(tǒng)操作的方便性是否使用適當?shù)姆治?、設計及測試技術(shù)和工具質(zhì)量審核方法審核方法分內(nèi)部審核以及正式審核：內(nèi)部審核：由項目組成員共同討論所開發(fā)系統(tǒng)的內(nèi)容，參與成員提出有關(guān)技術(shù)、方法及其它問題的意見。正式審核：由項目組書面通知貴公司召開審核會議，并進行審核工作，將審核結(jié)果及修正意見以書面方式通知項目組。項目業(yè)務功能設計質(zhì)量控制軟件產(chǎn)品的功能設計質(zhì)量控制責任主要是項目經(jīng)理和業(yè)務模塊負責人員，主要以項目組審計的方式進行質(zhì)量控制。如下:口項目階段：業(yè)務需求口項目文件：《需求說明書》《差異分析說明書》口項目評審內(nèi)容：需求評審口項目評審人員：項目總監(jiān)，項目經(jīng)理，質(zhì)量控制組組長，銀行業(yè)務小組，繁德業(yè)務負責人，產(chǎn)品經(jīng)理口項目質(zhì)量監(jiān)控評審內(nèi)容：?業(yè)務差異分析的完整性，并且是否符合業(yè)務主管部門的確認?新提的業(yè)務需求是否符合人行規(guī)定是否通過銀行內(nèi)部審核業(yè)務界面是否已完成業(yè)務代號和科目號是否有新增以及正確歸類會計記賬的分錄是否提供完整正確技術(shù)設計的質(zhì)量控制概要設計評審：軟件產(chǎn)品的功能設計質(zhì)量控制責任是項目經(jīng)理和模塊技術(shù)負責人員，主要以項目組聯(lián)合審計的方式進行技術(shù)質(zhì)量控制?？陧椖侩A段：概要設計口項目文件：《系統(tǒng)概要設計總體書》口項目評審內(nèi)容：系統(tǒng)概要設計總體審核口項目評審人員：項目總監(jiān)，項目經(jīng)理，質(zhì)量控制組組長，業(yè)務模塊負責人，技術(shù)模塊負責人，產(chǎn)品經(jīng)理口項目質(zhì)量監(jiān)控評審內(nèi)容：是否已經(jīng)全部實現(xiàn)新增的業(yè)務差異分析是否符合系統(tǒng)架構(gòu)的設計原則?數(shù)據(jù)字典公共字段已確認增加公共用的選擇列表已形成涉及記賬的模塊耦合是否良好產(chǎn)品經(jīng)理從產(chǎn)品的整體角度檢查設計是否合理質(zhì)量保證標準質(zhì)量保證標準使用軟件工程的方法，以軟件質(zhì)量控制為核心，抓住軟件生產(chǎn)方法、需求分析、軟件設計、軟件生產(chǎn)工具、測試、驗證與確認、評審和管理的原則進行檢查和評審，基本標準如下:1可申查性(auditability)。檢查軟件需求、規(guī)格說明、過程、代碼及合同是否一致的難易程序。2準確性(accuracy)。計算和控制的精度，是對無誤差程序的種定量估計。最好表示成相對誤差的函數(shù)。值越大表示精度越高。3通信通用性(communicationcommonality)。使用標準接口、協(xié)議的程序。4完全性(completeness)。5簡明性(conciseness)。程序源代碼的緊湊性。6一致性(consistency)。7數(shù)據(jù)通用性(datacommonality)。在程序中使用的標準和類型。8容錯性(error-tolerance)。系統(tǒng)在各種異常條件下提供繼續(xù)操作的能力。9執(zhí)行效率(executionEfficiency)。程序運行效率。10可擴充性(expandability)。能夠?qū)Y(jié)構(gòu)設計、數(shù)據(jù)設計和過程設計進行擴充的程度。11通用性(generality)。程序部件潛在的應用范圍的廣泛性。12硬件獨立性(hardwareindependence)。軟件同支持他運行的硬件系統(tǒng)不相關(guān)的程序。13檢測性(instrumentation)。監(jiān)視程序的運行，一旦發(fā)生錯誤時，標識錯誤的程序。14模塊化(modularity)。15可操作性(operability)。操作一個軟件的難易程度。16安全性(security)?？刂苹虮Ｗo程序和數(shù)據(jù)不受破壞的機制，以防止程序和數(shù)據(jù)受到意外的或畜意的存取、使用、修改、毀壞或泄密。17自文檔化(sdlf-documentation)。源代碼提供有意義文檔的程度。18簡單性(simplicity)。理解程序的難易程度。19軟件系統(tǒng)獨立性(softwaresystemindependence)。程序與非標準的程序設計語言特征、特征以及其他環(huán)境約束無關(guān)的程度。20可追蹤性(reacebility)。21易用性(training)。軟件支持新用戶使用該系統(tǒng)的能力。Bug修復流程：業(yè)務人員提交Bug描述單業(yè)務組長與技術(shù)組長共同分析，對描述的問題進行確認如確認是bug，技術(shù)組長安排技術(shù)人員解決技術(shù)人員解決后，進行自測，在Bug描述單里填寫問題解決方法技術(shù)組長對問題解決方法進行確認將升級程序通過版本提交工具提交到業(yè)務測試環(huán)境業(yè)務人員驗證性(功能性)測試。補丁升級程序：補丁有專門版本提交工具，通過其將Bug修復包提交到生產(chǎn)環(huán)境。需求變更管理需求變更管理也是項目管理中最重要的一個環(huán)節(jié),對需求變更管理的有效性將直接影響項目的成功與否。對待需求變更的態(tài)度:1、需求變更是不可避免的。2、需求變更要必須被管理。3、積極發(fā)現(xiàn)引起變更的因素,促使變更盡可能早的出現(xiàn),減低變更帶來的風險。需求變更管理的目標:1、相關(guān)的干系人必須清楚地了解發(fā)生的變更。2、變更處于有效的管理中。3、盡量降低變更帶來的風險。通過制定需求變更的流程,確保項目中的需求變更有效地進行,實現(xiàn)上述的目標。需求變更流程:1、確定需求的基準線。將以UserCase作為需求基準線,在UserCase確認之后的任何需求改變,都需要走需求變更流程,這一環(huán)節(jié)我們基本沒有,期間有時候使的工作很混亂,也就是因為沒有一個規(guī)范的變更流程而造成的;如果建立了這么一個流程規(guī)范和機制,需求變更沒有走這個流程的將不被認可。2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產(chǎn)品經(jīng)理、市場人員、開發(fā)人員、測試人員等。3、項目管理者評估該需求變更。針對接收到的需求變更的要求,召集相關(guān)人員討論該需求變更的合理性、可行性,實施的代價以及對項目的影響。包括可能影響的項目范圍、進度、費用、質(zhì)量等計劃。項目管理者作為項目的負責人,對項目的成功與否負有主要的責任。所以需求變更的決策者應該由項目管理者承擔4、需求變更確認后由專人將需求變更記錄下來,通知給項目中所有成員。其中以下人員對需求的變更是緊密相關(guān)的,他們必須知曉并認可此需求變更。包括（客戶方、需求分析人員、測試人員、相關(guān)開發(fā)人員。5、確定變更的負責人。承擔需求變更的具體工作,比如基線控制,對需求變更的記錄,并通知相關(guān)人員。6、相關(guān)人員接收到確認的需求變更后,做以下事情。需求分析人員修改需求說明書和UserCase的相關(guān)內(nèi)容。測試人員修改測試用例的相關(guān)內(nèi)容。開發(fā)人員修改代碼中的相關(guān)部分。7、按照變更后的計劃實施項目,并進行檢查,跟蹤,對變更后的實施反饋和可能出現(xiàn)的問題及時溝通和處理。8、需求凍結(jié)。項目越到后期,需求變更對項目的影響就越大,所以在一定時候要進入需求凍結(jié)階段,不再接收新需求或需求的變更。溝通管理為使項目干系人（包括項目相關(guān)人員、第三方廠商、項目主管、銷售代表、QA、項目組成員等）之間進行良好、有效的溝通，根據(jù)公司的項目管理規(guī)范，項目將采用如下溝通交流制度：專題會議為保證會議的有效性，在召開會議前必須明確會議目的、議題和進程。除緊急情況外，一般提前兩天通知與會人員、發(fā)布會議討論材料。會議中指定主持人和記錄人，會議進程按照通知中的議程逐項進行，討論后應形成明確意見和決定。對于不能按時得出結(jié)論的議題，主持人征求與會人員意見后可決定將該項議題留待其它專門時間進行會議討論，同時確定下次討論的時間、地點、人員、議程。會議結(jié)束后，記錄人最遲在下