XX大學軟件開發管理制度

　　第一章 總則

　　第一條 為規范自有軟件研發以及外包軟件的管理工作，特制定本制度。本制度適用于XX大學的軟件研發與管理，分行參照執行。

　　第二條 本制度中軟件開發指新系統開發和現有系統重大改造。

　　第三條 本制度中自行開發是指主要依賴分行自身的管理、業務和技術力量進行系統設計、軟件開發、集成和相關的技術支持工作，一般僅向外購置有關的硬件設備和支撐軟件平臺;合作開發是XX大學信息化建設與管理處與專業IT合作商共同協作完成IT應用的項目實施和技術支持工作，一般形式是XX大學信息化建設與管理處負責提供業務框架，合作商提供技術框架，雙方組成開發團隊進行項目實施，IT系統的日常支持由XX大學信息化建設與管理處和合作商共同承擔，XX大學信息化建設與管理處負責內部(一級)支持，合作商負責外部(二級)支持;外包開發是指將IT應用項目的設計、開發、集成、培訓等任務承包給某家專業IT公司，由該IT公司(承包商)負責應用項目的實施。

　　第四條 軟件開發遵循項目管理和軟件工程的基本原則。項目管理涉及立項管理、項目計劃和監控、配置管理、合作開發管理和結項管理。軟件工程涉及需求管理、系統設計、系統實現、系統測試、用戶接受測試、試運行、系統驗收、系統上線和數據遷移。

　　第五條 除特別指定，本制度中項目組包括業務組(或需求提出組)、IT組(可能包括網絡管理員和合作開發商)。

　　第六條 本規定適用于XX大學信息化建設與管理處及其指定的信息系統運維單位。

　　第二章 立項管理

　　第七條 提出開發需求的信息技術部門參與分行層面立項，進行立項的技術可行性分析，編寫《立項分析報告》，開展前期籌備工作?！读㈨椃治鰣蟾妗窇鞔_項目的范圍和邊界。

　　第八條 應用系統主要使用部門將《立項分析報告》上交分行行長室進行立項審批，以保證系統項目與分行整體策略相一致。

　　第九條 《立項分析報告》得到批準后，成立項目組(如果是外包開發，則成立外包商項目組;如果是合作開發，則與外包商共同成立合作開發項目組，以下統稱“項目組”)，項目組應包括業務組(由相關業務部門組成)和IT組(自行開發為辦公室網絡管理員;外包開發為外包商成員;合作開發為網絡管理員和外包商成員)。分行委派一名員工負責監督項目的進度，進行項目管理工作，確保開發能及時完成并能滿足業務需要。項目組人員的選擇應滿足項目對業務及技術要求，項目組人員應有足夠的業務和IT技術方面的專業知識來勝任項目各方面的工作。

　　第三章 需求分析

　　第十條 立項后業務組對用戶需求進行匯總整理，出具《業務需求說明書》，并確?！稑I務需求說明書》中包含了所有的業務需求。經系統使用部門審批確認，作為業務需求基線。

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

　　第十二條 對于合作開發的項目，當業務需求發生變更時，業務組應提交《需求變更申請》，XX大學信息化建設與管理處審批后交給合作開發商實施。

　　第十三條 項目組應對需求變更影響到的文檔及時更新。

　　第四章 項目計劃和監控

　　第十四條 軟件開發采用項目形式進行管理。項目經理負責整個項目的計劃、組織、領導和控制。

　　第十五條 需求分析過程中，項目經理組織制定詳細的《項目計劃書》，包括具體任務描述和項目進度表等。

　　第十六條 在項目的各個階段，業務組組長和XX大學信息化建設與管理處需配合項目經理制定階段性項目計劃。業務組組長和XX大學信息化建設與管理處需配合項目經理對項目計劃執行情況進行監控，確保項目按計劃完成。

　　第十七條 項目計劃需要變更時，項目經理填寫《項目計劃變更說明》，并提交分行主管領導審批，通過審批后，交給業務組組長和XX大學信息化建設與管理處執行。

　　第五章 系統設計

　　第十八條 系統設計應分為概要設計和詳細設計，系統設計要遵循完備性、一致性、擴展性、可靠性、安全性、可維護性等原則。

　　第十九條 在系統設計階段中，用戶應充分參與，確保系統設計能滿足系統需求。

　　第二十條 項目組進行詳細設計，出具《設計說明書》和《單元測試用例》?！对O計說明書》中需要定義系統輸入輸出說明和接口設計說明。XX大學主管領導組織相關人員對概要設計進行評審，出具《設計評審報告》。業務組組長和XX大學信息化建設與管理處應參加此評審并對評審意見簽字確認。

　　第二十一條 設計評審均以《業務需求說明書》和《系統需求規格說明書》為依據，確保系統設計滿足全部需求。

　　第二十二條 對已確認通過的系統設計進行修改需獲得管理部門、業務組組長和XX大學信息化建設與管理處的審批后方可進行。

　　第二十三條 對系統設計的修改的文檔須由文檔管理人員進行歸檔管理。

　　第六章 系統實現

　　第二十四條 項目組根據《設計說明書》制定系統實現計劃，并提交項目經理對計劃可行性進行審批。

　　第二十五條 系統實現包括程序編碼、單元測試和集成測試。

　　第二十六條 項目組保證開發、測試和生產環境獨立，為各環境建立訪問權限控制機制，并明確項目成員的職責分工。對開發環境、測試環境與生產環境在物理或邏輯方面應該做到隔離;如果環境的分隔是通過邏輯形式實現的，應定期檢查網絡設置。項目組對已授權訪問生產環境的人員進行詳細記錄，并對該記錄進行定期檢查，確保只有經授權的人員才能訪問到生產環境。

　　第二十七條 項目組進行單元測試和集成測試，測試人員簽字確認測試結果。

　　第七章 系統測試和用戶測試

　　第二十八條 項目組制定《系統/用戶測試計劃》，并提交項目經理對計劃可行性進行審批。

　　第二十九條 《系統/用戶測試計劃》必須定義測試標準，并明確各種測試的測試步驟和需要的系統設置要求。

　　第三十條 目組向數據擁有部門申請獲取測試用業務數據的使用權，對獲取的數據進行嚴格的訪問控制，確保只有相關項目人員才能訪問及使用。

　　第三十一條 項目組負責測試數據準備，測試用數據要足夠模擬生產環境中的實際數據。對已評定為敏感信息的數據進行敏感性處理和保護。

　　第三十二條 IT組或合作開發商建立測試環境進行系統測試。在系統測試中對新系統內部各模塊之間的接口和與其他系統的接口進行充分測試。出具《系統測試報告》，測試人員簽字確認測試結果。

　　第三十三條 統測試通過后，IT組配合業務組建立用戶測試環境，業務組根據用戶測試用例進行用戶測試，出具《用戶測試報告》，業務組組長和XX大學信息化建設與管理處應在用戶測試報告中簽字確認。

　　第三十四條 項目組完成系統幫助文檔(其中包括《用戶操作手冊》和《安裝維護手冊》)。凡涉及應用系統的變更，應對系統幫助文檔及時更新。

　　第八章 試運行

　　第三十五條 系統主要使用部門根據項目規模及影響決定試運行策略。

　　第三十六條 項目組制定《試運行計劃》，并制定試運行驗收指標，上報分行主管領導審批?！对囘\行計劃》中應包含問題應對機制，明確問題溝通渠道和職責分工。

　　第三十七條 項目組聯合試運行單位進行相關系統部署工作，準備培訓資料，對相關用戶和信息技術人員進行培訓。用戶培訓的完成度應為實施后評估的指標之一。

　　第三十八條 項目組根據《試運行計劃》進行系統轉換和數據遷移。系統轉換前，檢查系統環境，確保運行環境能滿足新應用系統的需要。系統轉換時必須詳細記錄原系統中的重要參數、設置等系統信息，并填寫試運行報告相關內容。系統參數、設置的轉換工作作為系統上線的驗收的評估指標之一。

　　第三十九條 數據遷移前，應制定詳細的《數據遷移計劃》，《數據遷移計劃》中應包含遷移方案、測試方案、數據定義，新舊數據對照表、遷移時間、回退計劃等信息。數據遷移計劃需經項目經理和主管領導簽字審批。

　　第四十條 數據遷移后，項目組對數據遷移的完整性和準確性做出檢查，出具《數據遷移報告》，其中包括數據來源、轉換前狀態、轉換后狀態，數據遷移負責人、對完整性檢查情況、對準確性檢查情況等內容。各相關部門驗收轉換結果后在該報告上簽字確認。

　　第四十一條 統轉換和數據遷移由試運行單位業務部門和分行主管領導共同監督并進行驗收。

　　第四十二條 系統轉換和數據遷移驗收通過后，正式啟動試運行。在試運行過程中，試運行單位辦公室把系統運行情況(系統資源使用，反應速度等)記錄到試運行報告中。必要時，項目組應根據系統運行情況對應用系統進行優化。

　　第四十三條 試運行達到試運行計劃規定的終止條件時，項目組編寫《試運行報告》。此報告應由項目組和試運行單位簽字確認，并提交分行主管領導審閱。分行主管領導審閱試運行結果，決定試運行結束或延期。

　　第九章 系統驗收

　　第四十四條 系統主要使用部門及信息技術部門聯合組成獨立系統驗收小 ，也可授權原項目組作為驗收小組。驗收小組從功能需求及技術需求層面對系統進行綜合評估。

　　第四十五條 驗收小組應根據驗收情況整理形成《系統驗收報告》提交系統主要使用部門和信息技術部門審閱。

　　第四十六條 系統主要使用部門和信息技術部門負責人根據系統測試、試運行情況簽署驗收意見。

　　第十章 系統上線

　　第四十七條 系統上線應遵循穩妥、可控、安全的原則。

　　第四十八條 通常情況下，系統上線包含數據遷移工作。

　　第四十九條 項目組制定《系統上線計劃》，上報分行主管領導審批。在上線計劃得到批準后才能開始部署上線工作。

　　第五十條 《系統上線計劃》內容應包括但不限于：

　　1、部署方式和資源分配(包括人力資源及服務器資源);

　　2、上線工作時間表;

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

　　4、項目階段性里程碑和成果匯報(項目執行狀態的審閱、進度安排等);

　　5、數據遷移的需求和實施計劃;

　　6、完整可行的應急預案和“回退”計劃;

　　7、用戶培訓計劃(包括：培訓計劃、培訓手冊、培訓考核等)

　　8、總行下發的系統標準參數配置。

　　第五十一條 上線單位在上線初期需加強日常運行狀態監控，出現問題時應及時處理，對重大問題應啟動緊急預案。

　　第五十二條 在完成上線后要填寫《系統驗收評估報告》，上報總行項目組匯總整理?！断到y驗收評估報告》內容包括：數據準確性、系統性能及穩定性、接口問題、權限問題、業務操作影響度、問題處理情況、備份、批處理等。

　　第五十三條 上線單位管理層要對《系統驗收評估報告》進行審批簽字。

　　第五十四條 分行主管領導批準結項后，業務組和IT組將整理的文檔提交各自部門統一管理。

　　第十一章 合作開發管理

　　第五十五條 合作開發商的選擇應遵循分行相關規定，合作商資質認定參見第三方管理制度。

　　第五十六條 合作開發商必須遵循分行《軟件開發管理制度》。

　　第五十七條 項目經理同合作開發商明確規定項目變更的范圍和處理方式，重點關注需求和設計變更。

　　第五十八條 項目經理負責監控合作開發商的項目管理及軟件開發活動。合作開發商應按計劃定期向項目經理報告進展狀態，并提交階段性成果文檔。發生重大問題時，合作開發商需及時向項目經理匯報。

　　第五十九條 XX大學信息化建設與管理處派專人監控合作開發商的質量保證過程。

　　第六十條 項目組同合作開發商商定驗收的標準和方法。

　　第六十一條 以上各要求需要在開發合同中明確。

篇2：軟件開發流程項目經理所必需具備素質

　　軟件開發流程的項目經理所必需具備的素質

　　許多人都以為項目經理總是與“理想與光榮”相伴的，其實作為一個有志于改進中國軟件開發流程的項目經理來說，他們承擔的更多的是“艱辛與痛苦”。

　　在這里，我通過我擔任項目經理期間所遇到的種種現象，來總結項目經理所必需具備的素質，當這些素質您不具備的話，就需要花費多年的努力來培養他，如果無法培養成功，那么請您轉換崗位，因為項目經理不適合您，您難以在這個方面獲的成功。

　　一、執著

　　可以這么說，在中國如果不執著是做不成任何事情的，因為在軟件開發流程中推行各種規范和管理制度的時候，你可能遇到各種各樣的阻力和障礙，如果沒有應付挫折的思想和準備，你是很難推行成功的。要知道這樣一個基本事實，項目管理成敗的關鍵是：如果你不堅持，誰也不會堅持下去的。指望領導的扶持和群眾的自覺是不可能的。只有堅定信念，努力打動別人，才能成功。

　　堅持到成功為止。只要決定上管理流程了，就不要后悔，唯有堅持，因為你拼命努力而實現了99%,你卻不知，最后當你決定放棄的時候也許就是你要成功之時。要知道你準備放棄的時候可能正是對方也準備放棄之時，唯有堅持，你才能成功。

　　二、親和力

　　親和力是指你和團隊相互依賴，相互信任能力的大小。親和力是你領導團隊走向成功的基礎，如果一個團隊的向心力不夠，各自為政，那么失敗就會在身邊陪伴你。要團隊的每個成員都信任你，你必須要做到關心下屬，主動與下屬溝通，為下屬爭取合法權利等。關心下屬就是在日常工作中對下屬的工作狀況，發展方向進行指導，避免其走彎路；在生活中也對其身體狀況進行關心，促進身體和心理健康的恢復。

　　多找下屬溝通是消除誤會的潤滑劑，同時也是了解下屬內心真實想法唯一捷徑。做項目經理的人，在某些事情上的處理的確會與人不同，也難以令人理解。這個時候只有多與下屬溝通，逐步達成共識，爭取大家的理解和支持。記住，沒有下屬的理解和支持，你永遠無法實現項目管理的規范化。這個環節很重要，我在這個方面曾經用時太少，走了許多彎路。另外就是了解下屬的真實想法，經常了解一下下屬的真實想法有利于我們不斷改進和調整流程，使生產流程更加符合本團隊的實際。切記一點，做領導的一定要多尊重下屬的想法，并且與之溝通，若一味等下屬找自己，那么是一般下屬與之水火不容要攤牌時，才會與你溝通，這樣悔之晚矣。

　　為下屬爭取合法權利是項目經理的一項重要職責。敢負責任是項目經理基本素質，如果你不經常研究工作數據保障下屬的合法權益時，你就很難讓你的團隊保持高效率。曾經有一次，我們測試工程師的工作業績突然下降了一半，我與之溝通后發現公司不講效率只講工作時間，他有一天特殊沒上班，結果公司扣了一天的工資；但是他其實超額完成了月計劃的120％。了解情況后，我與公司協調，順利補回工資，生產效率就大幅上揚。

　　三、品德高尚

　　“一撇一捺是個人，世世代代學做人?！痹谶@個世界上最難做的就是做個品德高尚的人。試想一個思想猥褻的人很難取得成功，即使靠鉆營取得也只是暫時的，他不可能取得長久的成功。只有品德高尚的人才能感染周圍的人，使團隊具有向心力，從成功走向成功。

　　人有三種，一種是仗勢欺人，一種是持才壓人，最后一種是以德服人。仗勢欺人的人自持地位高而指三道四，自然是不可能團結人，更不可能獲得成功；持才壓人的人自持學識高而盛氣凌人，或咄咄逼人。殊不知“聞到有先后，術業有專攻”，“尺有所長，寸有所短”，難以學到更高的知識，也就難以取得更大的成功。只有以德服人的人以自己的修養和品德感染人，勇于吃虧，樂于助人，以德報怨，只有這樣才能使你對立面德人都不忍心傷害你，團結到一切可以團結到的人，擁有這樣的環境，你怎么可能不成功。

　　勇于吃虧，首先要放下私心，如果一個人始終 圍著自己轉的人是不可能做到的?！叭瞬粸榧?，天誅地滅”是八十年代后出生的人心靈普遍反應；但是要記住人首先是社會中的人，如果脫離了社會，人恐怕已不會成其為人了。因此只有當你拋棄私心，主動為人，別人才會反過來支持你，幫助你。

　　樂于助人，是人類的一個良好品質，就象一首歌中所唱的“人字的結構就是相互支撐”。管理流程是不可能靠項目經理一個人維持的，必須要大家支持你。但是這卻需要你多幫助別人，別人才會幫助你。不管團隊成員發生什么事情，你要盡你所能去幫助他，這樣團隊才可能繼續前進。

　　以德報怨，可能是人最難做到的。中國人就強調“人若犯我，我必犯人”，其實在這回中不會有真正的仇敵，大家明爭暗斗的結果如果過20年后再去看的時候，保準一大半的人都會覺得不值得，許多人賭得就是一口氣，將自己成功的希望給湮滅了。當你能用寬容喝善良對待你對立面的人的時候，還有什么東西能阻擋你成功？

　　“得道多助，失道寡助；多助之至，天下順之，失道之至，親戚叛之；以天下之所順，攻親戚之所叛；故君子有不戰，戰必勝矣?！?/P>

　　四、口才

　　良好的口才是項目經理打動項目成員的必備武器，當你擁有良好的口才將會使你無往不利。當年希特勒就是用他那天才般的口才征服了德國，使他的《我的奮斗》貫徹到每一個德國人的心中，從而成立了第三帝國。

　　要使自己的項目管理思想貫徹到每一個項目成員心中，就必須要做到以下的演講原則：

　　1.根據項目成員的共同目標象他們制定演講內容，只有讓他們信服你才有意義；

　　2.調動聽眾的這種感官，訴之觸覺、視覺、聽覺，用黑板、姿勢來輔助你的內容。

　　3.不斷的總結效果，改進自己演講宣傳的接受度，如果效果不理想，嘗試換一個方式來表達和描述。

　　4.讓聽眾學以至用，只有他們積極反饋，才能更深入的聽你的思想。

　　五、循序漸進

　　循序漸進，不急于求成是項目經理

在項目管理中必需具備的品質，在中國CMM過程改進的熱潮中，真正實現CMM管理的企業屈指可數，而以CMM改進過程實質性為企業帶來質量提升和效益改進的公司更是寥落晨星。

　　為什么會出現這種情況？難道CMM真的不適應中國過情嗎？不是，絕對不是。是這些企業的項目經理太心急，連CMM2還不知道怎么回事就直奔CMM3，他們忽視了事務發展的客觀規律，凡事必須循序漸進。如果有一個企業在2年內通過了CMM4，我有十足的信心說，那是花錢買征；如果樂觀一點，一個中小企業從CMM1走到CMM2大約要2年時間，大型企業只會更長，不會更短，因為他們需要在培訓和溝通上付出更大的代價。

　　就以我所在公司來說，技術部原來只有10任，后來培訓CVS版本管理到精通花費了1年，然后才上CVSTrac變更和過程管理，花費了3個多月，然后再實施Finabuild管理花費了3個月，最后改進CVSTrac成CVSProduce管理開發過程并統計花費了半年，其間成立了QA管理部門，并增加了項目專職管理人員，部門人數已經增加到16人，還在不斷擴充中。我們的感覺管理越科學化、流程化，所需的分工就越細，人員也就越多。同事培訓和做通這些人的思想工作的成本就越大。開發管理軟件的成本也會隨之上升。當所有人都能接受流程管理并持續改進時，大約2年光陰也就過去了。

　　“循序漸進，循序漸進，再循序漸進?！边@句巴斯德德經典名言同樣適用于我們項目管理領域，他將逐步把我們帶向成功。

　　六、持久求學

　　“書到用時方恨少，學至成時始知卑?！睂W無止境，我在生產實踐中發現，整個項目管理過程改進就是“學習－培訓－實施－發現問題－再學習”的循環過程，項目經理如果不學習將不能解決現實工作中出現的新問題，更不可能站在一個戰略的角度來解決問題。

　　事實上，求學也不能沒有目標，否則學到的知識太龐雜，而不能融會貫通，這樣的知識對實際工作指導甚少，真正的知識是一個目標體系，嚴格按照流程來一步步的掌握我們所需要的知識。

　　最后，我總結一下中國項目經理所必需掌握的知識：

　　1.專業知識：數據結構、關系數據庫、操作系統、軟件工程、編譯原理。（外國的項目經理可能不需要掌握）

　　2.管理知識：項目計劃、項目配置管理、成本核算、風險預估、績效考核。這是項目經理必須掌握的內容。

　　3.網絡知識：服務器的架構、各種服務的配置。因為管理的大廈是基于軟件的管理，沒有一個服務管理的網絡配合是不可以想象的。

　　4.“越過高峰，另一峰卻又現”，這是中國項目經理在持續求學中會不停的挑戰自我，向更高的山峰邁進。

　　七、敢負責任

　　一個人因為有責任才有生存的意義。一個人隨著年齡的增長，責任感也會愈來愈重。成年時，法律也會賦予一些年少時沒有的責任。同時地位逐漸提高，責任也會相對加重。

　　一個人惟有負責，才能產生做人的價值。所負責任愈大，價值就愈高。換句話說，有責任，生命才有意義。如果沒有感受到自己該負的責任，即使年齡超過20歲，也不算是一個成年人。

　　因此，經理就是要負責任，如果不負責任就可以不要經理了！項目經理關系到一個項目的成??；對于公司他必須要承擔及時匯報項目進度、成本核算和質量系數的責任，同時也必須保證項目組成員績效考核，政策落實，預留人才儲備等責任，是整個項目中責任最大的人，如果沒有良好的心理素質和應對能力是無法擔負責任的。

　　實際工作中項目經理主要要負責項目組的人員安排調度、工作分配、工作審核、工作跟蹤、項目計劃、項目匯報總結、成本核算、利潤分配等職責。

　　八、以身作則

　　項目管理的一個重要工作就是定義各種規范和制定，但是這些規范和制度的執行除了靠項目經理的執著推行，口才宣傳，力主培訓、懲戒得當之外，關鍵還是在于項目經理的以身作則。如果項目經理自己都違反自己定義的條款的話，那么就別指望團隊會自覺遵守這些規定。

　　作為一個管理者以身作則是最基本的素質，千萬不要為自己違反規范和制度找各種借口，例如我我是公司只屬考核，我因為某某更重要的事情而不得不違反?！爸辉S周宮放火，不許百姓點燈”的話，是無法將規范和制度推入人心的。項目經理如果違反了規范，只有當眾加重處罰，別無他法。

　　說個真實的事例。我從事項目經理工作之前經常遲到，結果不久全技術部人隔三岔五的遲到。我當項目經理后執行晨會制度，早上到公司頭半個小時總結一下昨天工作，探討一下今天的工作，但是因為習慣，有人總是遲到。而我開始從不遲到，有一點為了趕時間我長跑去買早餐以在晨會規定時間之前到公司，被許多團隊成員看見。以后就再沒人遲到，直至項目結束。

　　因此，鑒于規范制度的權威性主要還是靠項目經理自己，只有堅持以身作則，才能將自己優秀的管理思想貫穿下去，取得開發過程改進的成功。

　　九、要有威信

　　一個項目經理說話有沒有人聽，必須要靠威信，這種威信是靠自身的素質，而不是狐假虎威?？扛邔宇I導的支持來強迫團隊執行項目制度過程的話，是注定會失敗的。因為團隊成員不信任你，表面服從，實際消極怠工，就足以讓流程實質癱瘓。

　　做事要有信用，說一不二，不能因為朋友關心就講情面。公是公，私是私。平時可以稀稀拉拉，關鍵問題決不手軟，不因為朋友關系妥協，這樣才能樹立威信，便于工作。

　　威信除了必要的威信之外，最主要的還是信用，項目經理在做事沒有絕對把握的時候千萬不要承諾，一旦承諾就無論如何一定要實現。否則，當實現不成功而丟失信用之后，再想讓團隊相信你，信任你就是非常困難的事情了。

　　十、善于總結

　　項目經理要善于總結，只有不斷的總結才能不停的完善自己，成功的事情總結經驗，失敗的事情要總結教訓，總結的過程就是不斷改進的過程，這也是CMM規范所必需的素質。

　　總結的過程要多吸取別人的意見，不要武斷自己的結論。博人所長，綜合起來才算趨于完美。這個原因有二：其一，項目經理不是孤立的一個人，而是必須融于團隊之中，一個流程合不合理，不是由項目經理說了算，而是要由團隊的成員說了算，注意傾聽團隊成員的真實感受，不斷改進流程才能成功。中國的許多CMM改進失敗，并不是項目經理知識能力不夠，而是他們沒有一起與團隊總結，經多年經驗，我們發現大多數規范，必須要有一套合理的軟件支持才能成功，否則無論你的理想多先進，想靠程序員工作來提高過程質量的改進是不現實的。其二，“聞道有先后，術業有專攻”，項目經理不可能是全才，什么都懂。因此要和哪些與專攻方向不同的人一起總結。比如項目經理可能精通軟件開發流程的改進，但是卻不知道測試流程、網絡管理流程、品質保

證流程的改進，而這些流程又直接作用于軟件開發流程。這個時候必須與測試人員、網管人員、質量保證人員共同探討，找出一條切實可行的改進方案。

　　項目經理除了必須具備以上素質外，還必須要有珍惜時間、要有勇氣、善于傾聽等基本素質，我就不一一描述了，只有寄希望于大家在做項目經理的時候不斷的培養完善自己，讓軟件開發流程不斷獲得改進。

篇3：軟件項目開發管理制度

　　軟件項目開發管理制度

　　第一節 總則

　　第一條 為規范自有軟件研發以及外包軟件的管理工作，特制定本制度。本制度適用于股份公司軟件研發與管理，分公司參照執行。

　　第二條 本制度中軟件開發指新系統開發和現有系統重大改造。

　　第三條 本制度中自行開發是指主要依賴公司自身的管理、業務和技術力量進行系統設計、軟件開發、集成和相關的技術支持工作，一般僅向外購置有關的硬件設備和支撐軟件平臺;合作開發是公司與專業IT公司(合作商)共同協作完成IT應用的項目實施和技術支持工作，一般形式是公司負責提供業務框架，合作商提供技術框架，雙方組成開發團隊進行項目實施，IT系統的日常支持由信息中心和合作商共同承擔，信息中心負責內部(一級)支持，合作商負責外部(二級)支持;外包開發是指將IT應用項目的設計、開發、集成、培訓等任務承包給某家專業公司(可以是專業的IT公司或咨詢公司等)，由該公司(承包商)負責應用項目的實施。

　　第四條 軟件開發遵循項目管理和軟件工程的基本原則。項目管理涉及立項管理、項目計劃和監控、配置管理、合作開發管理和結項管理。軟件工程涉及需求管理、系統設計、系統實現、系統測試、用戶接受測試、試運行、系統驗收、系統上線和數據遷移。

　　第五條 除特別指定，本制度中項目組包括業務組(或需求提出組)、IT組(可能包括網絡管理員和合作開發商)。

　　第二節 立項管理

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

　　第七條 應用系統主要使用部門將《立項分析報告》上交公司總裁室進行立項審批，以保證系統項目與公司整體策略相一致。

　　第八條 《立項分析報告》得到批準后，成立項目組(如果是外包開發，則成立外包商項目組;如果是合作開發，則與外包商共同成立合作開發項目組，以下統稱“項目組”)，項目組應包括業務組(由公司相關業務部門組成)和IT組(自行開發為信息中心研發人員;外包開發為外包商成員;合作開發為信息中心研發人員和外包商成員)。項目組人員的選擇應滿足項目對業務及技術要求，項目組人員應有足夠的業務和IT技術方面的專業知識來勝任項目各方面的工作。

　　第三節 需求分析

　　第九條 立項后業務組對用戶需求進行匯總整理，出具《業務需求說明書》，并確?！稑I務需求說明書》中包含了所有的業務需求。經系統使用部門審批確認，作為業務需求基線。

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

　　第十一條 對于合作開發的項目，當業務需求發生變更時，業務組應提交《需求變更申請》，IT組組長審批后交給合作開發商實施。

　　第十二條 項目組應對需求變更影響到的文檔及時更新。

　　第四節 項目計劃和監控

　　第十三條 軟件開發采用項目形式進行管理。項目經理負責整個項目的計劃、組織、領導和控制。

　　第十四條 需求分析過程中，項目經理組織制定詳細的《項目計劃書》，包括具體任務描述和項目進度表等。

　　第十五條 在項目的各個階段，業務組組長和IT組組長需配合項目經理制定階段性項目計劃。業務組組長和IT組組長需配合項目經理對項目計劃執行情況進行監控，確保項目按計劃完成。

　　第十六條 項目計劃需要變更時，項目經理填寫《項目計劃變更說明》，并提交公司主管領導審批，通過審批后，交給業務組組長和IT組組長執行。

　　第五節 系統設計

　　第十七條 系統設計應分為概要設計和詳細設計，系統設計要遵循完備性、一致性、擴展性、可靠性、安全性、可維護性等原則。

　　第十八條 在系統設計階段中，用戶應充分參與，確保系統設計能滿足系統需求。

　　第十九條 項目組進行詳細設計，出具《設計說明書》和《單元測試用例》。

　　《設計說明書》中需要定義系統輸入輸出說明和接口設計說明。公司主管領導組織相關人員對概要設計進行評審，出具《設計評審報告》。業務組組長和IT組組長應參加此評審并對評審意見簽字確認。

　　第二十條 設計評審均以《業務需求說明書》和《系統需求規格說明書》為依據，確保系統設計滿足全部需求。

　　第二十一條 對已確認通過的系統設計進行修改需獲得管理部門、業務組組長和IT組組長的審批后方可進行。

　　第二十二條 對系統設計的修改的文檔須由文檔管理人員進行歸檔管理。

　　第六節 系統實現

　　第二十三條 項目組根據《設計說明書》制定系統實現計劃，并提交項目經理對計劃可行性進行審批。

　　第二十四條 系統實現包括程序編碼、單元測試和集成測試。

　　第二十五條 項目組保證開發、測試和生產環境獨立，為各環境建立訪問權限控制機制，并明確項目成員的職責分工。對開發環境、測試環境與生產環境在物理或邏輯方面應該做到隔離;如果環境的分隔是通過邏輯形式實現的，應定期檢查網絡設置。項目組對已授權訪問生產環境的人員進行詳細記錄，并對該記錄進行定期檢查，確保只有經授權的人員才能訪問到生產環境。

　　第二十六條 項目組進行單元測試和集成測試，測試人員簽字確認測試結果。

　　第七節 系統測試和用戶測試

　　第二十七條 項目組制定《系統/用戶測試計劃》，并提交項目經理對計劃可行性進行審批。

　　第二十八條 《系統/用戶測試計劃》必須定義測試標準，并明確各種測試的測試步驟和需要的系統設置要求。

　　第二十九條 項目組向數據擁有部門申請獲取測試用業務數據的使用權，對獲取的數據進行嚴格的訪問控制，確保只有相關項目人員才能訪問及使用。

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

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

　　第三十二條 系統測試通過后，IT組配合業務組建立用戶測試環境，業務組根據用戶測試用例進行用戶測試，出具《用戶測試報告》，業務組組長和IT組組長應在用戶測試報告中簽字確認。

　　第三十三條 項目組完成系統幫助文檔(其中包括《用戶操作手冊》和《安裝維護手冊》)。凡涉及應用系統的變更，應對系統幫助文檔及時更新。

　　第八節 試運行

　　第三十四條 系統主要使用部門根據項目規模及影響決定試運行策略。

　　第三十五條 項目組制定《試運行計劃》，并制定試運行驗收指標，上報公司主管領導審批?！对囘\行計劃》中應包含問題應對機制，明確問題溝通渠道和職責分工。

　　第三十六條 項目組聯合試運行單位進行相關系統部署工作，準備培訓資料，對相關用戶和信息技術人員進行培訓。用戶培訓的完成度應為實施后評估的指標之一。

　　第三十七條 項目組根據《試運行計劃》進行系統轉換和數據遷移。系統轉換前，檢查系統環境，確保運行環境能滿足新應用系統的需要。系統轉換時必須詳細記錄原系統中的重要參數、設置等系統信息，并填寫試運行報告相關內容。系統參數、設置的轉換工作作為系統上線的驗收的評估指標之一。

　　第三十八條 數據遷移前，應制定詳細的《數據遷移計劃》，《數據遷移計劃》中應包含遷移方案、測試方案、數據定義，新舊數據對照表、遷移時間、回退計劃等信息。數據遷移計劃需經項目經理和主管領導簽字審批。

　　第三十九條 數據遷移后，項目組對數據遷移的完整性和準確性作出檢查，出具《數據遷移報告》，其中包括數據來源、轉換前狀態、轉換后狀態，數據遷移負責人、對完整性檢查情況、對準確性檢查情況等內容。各相關部門驗收轉換結果后在該報告上簽字確認。

　　第四十條 系統轉換和數據遷移由試運行單位業務部門和公司主管領導共同監督并進行驗收。

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

　　第四十二條 試運行達到試運行計劃規定的終止條 時，項目組編寫《試運行報告》。此報告應由項目組和試運行單位簽字確認，并提交公司主管領導審閱。公司主管領導審閱試運行結果，決定試運行結束或延期。

　　第九節 系統驗收

　　第四十三條 系統主要使用部門及信息技術部門聯合組成獨立系統驗收小組，也可授權原項目組作為驗收小組。驗收小組從功能需求及技術需求層面對系統進行綜合評估。

　　第四十四條 驗收小組應根據驗收情況整理形成《系統驗收報告》提交系統主要使用部門和信息技術部門審閱。

　　第四十五條 系統主要使用部門和信息技術部門負責人根據系統測試、試運行情況簽署驗收意見。

　　第十節 系統上線

　　第四十六條 系統上線應遵循穩妥、可控、安全的原則。

　　第四十七條 通常情況下，系統上線包含數據遷移工作。

　　第四十八條 項目組制定《系統上線計劃》，上報公司主管領導審批。在上線計劃得到批準后才能開始部署上線工作。

　　第四十九條 《系統上線計劃》內容應包括但不限于：

　　1、部署方式和資源分配(包括人力資源及服務器資源);

　　2、上線工作時間表;

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

　　4、項目階段性里程碑和成果匯報(項目執行狀態的審閱、進度安排等);

　　5、數據遷移的需求和實施計劃;

　　6、完整可行的應急預案和“回退”計劃;

　　7、用戶培訓計劃(包括：培訓計劃、培訓手冊、培訓考核等);

　　第五十條 上線單位在上線初期需加強日常運行狀態監控，出現問題時應及時處理，對重大問題應啟動緊急預案。

　　第五十一條 在完成上線后要填寫《系統驗收評估報告》，上報總公司項目組匯總整理?！断到y驗收評估報告》內容包括：數據準確性、系統性能及穩定性、接口問題、權限問題、業務操作影響度、問題處理情況、備份、批處理等。

　　第五十二條 上線單位管理層要對《系統驗收評估報告》進行審批簽字。

　　第五十三條 公司主管領導批準結項后，業務組和IT組將整理的文檔提交各自部門統一管理。

　　第十一節 合作開發管理

　　第五十四條 合作開發商的選擇應遵循公司相關規定，合作商資質認定參見第三方管理制度。

　　第五十五條 合作開發商必須遵循公司《軟件開發管理制度》。

　　第五十六條 項目經理同合作開發商明確規定項目變更的范圍和處理方式，重點關注需求和設計變更。

　　第五十七條 項目經理負責監控合作開發商的項目管理及軟件開發活動。合作開發商應按計劃定期向項目經理報告進展狀態，并提交階段性成果文檔。發生重大問題時，合作開發商需及時向項目經理匯報。

　　第五十八條 IT組組長派專人監控合作開發商的質量保證過程。

　　第五十九條 項目組同合作開發商商定驗收的標準和方法。

　　第六十條 以上各要求需要在開發合同中明確。