軟件開發管理制度
**
為加強對定制軟件開發工作管理,縮短開發周期,提高軟件開發質量,降低開發成本,提高定開發效率和效益,特制定軟件開發流程管理制度。
一、總則
為保證日常工作正常有序的進行,讓開發中各個環境更緊湊,更可控,需要盡可能實現項目管理的正規化,工作過程的流程化,以便提高軟件質量,按期交付。
1、軟件開發總體遵循項目管理和軟件工程的基本原則。
2、項目管理涉及項目立項、項目計劃和監控、配置管理。
3、軟件工程涉及需求分析、系統設計、軟件實現、系統測試、用戶測試、試運行、系統驗收、系統上線和數據遷移、產品維護。
二、階段成果
根據軟件工程的過程,制定以下工作流程,并規定了各個重要環節需要提交的交付物。各階段需提交的文檔:
1、立項:項目申請表,軟件需求報告或設計方案。
2、需求分析:項目研發主計劃、需求規格說明書
3、總體設計:概要設計說明書或功能模塊描述
4、詳細設計:詳細設計說明書,包括軟件接口說明、單元測試計劃。
5、軟件實現:軟件功能說明、源代碼說明或者注釋
6、產品測試:測試報告
7、產品發布:產品說明書、使用手冊
8、產品維護:問題反饋記錄
9、項目總結:提交客戶方的項目總結和公司項目匯報的PPT。
軟件過程成果表:
階段
形成文檔
職責及文檔成果描述
負責人
涉及范圍
備注
需求階段
項目立項報告(Word)
明確甲乙雙方責任及義務,需雙方簽字確認
項目經理
驗收報告
大部分業務建模和需求,少部分分析設計
業務需求說明書(Word)
需求定義,闡述業務范圍及內容,開發組負責制定最優技術設計方案
項目經理/分析員
驗收報告
項目開發計劃(Project)
用戶、領導、項目組都了解項目進度
項目經理
驗收報告
設計階段
業務流程總體設計書、詳細設計說明書(Word/Visio)
項目組成員分配任務,并召開討論會議,討論項目的技術架構和可能存在的技術難點,梳理業務流程,統一開發規則和風格等
項目經理/分析員
驗收報告
大部分分析設計,部分實施編程及測試,開始考慮部署
數據庫關系設計圖、流程圖(PowerDesigner)
便于項目開發
分析員
驗收報告
任務分配文檔(Word)
明確每個組員的開發任務及職責
項目經理
過程報告
問題說明報告(Word)
讓用戶、領導及組員及時了解和發現問題
項目經理
過程報告
業務變更文檔(Word)
記錄開發過程中用戶提出的業務需求變更情況
分析員
過程報告
測試階段
項目測試方案及報告(Word)
記錄項目測試的方法,驗證系統功能與性能的記錄
測試員
驗收報告
反復測試直至系統穩定
用戶使用手冊(Word)
方便用戶使用軟件而提供的使用說明書
測試員
驗收報告
上線及運行
系統切換報告
系統部署后的操作記錄
項目經理
過程報告
部署及維護
用戶培訓報告
用戶培訓文檔
項目經理
過程報告
項目驗收報告(Word)
記錄甲乙雙方簽訂項目驗收報告
項目經理
驗收報告
項目總結性報告
項目組通過此項目總結經驗及不足
項目經理
總結報告
三、崗位設置
根據公司目前的開發過程主要分為分析、開發、測試三個階段。分析階段完成用戶需求文檔的編寫,系統總體設計的編寫;開發階段完成設計文檔的編寫,代碼的編寫、代碼的維護。測試階段完成系統的測試,測試文檔及其他材料。通過逐漸的調整崗位,明確工作職責,逐步實現項目經理,軟件設計師,程序員,測試工程師的崗位設置。
崗位
工作內容
責任
項目經理
1、選定項目組成員,成立項目組,安排任務分工
2、與客戶進行溝通和協調(業務需求或非業務需求方面),以及需求調研工作。
3、制定開發主計劃,包括需求,設計,編碼,測試這幾個階段的計劃。
4、估計項目開發費用
5、制定小組開發進度表,對組內人員工作進度監控。
6、和客戶進行溝通,進行需求調研,匯總需求分析文檔,并編寫系統總體設計方案
7、對文檔的質量進行檢查、把關
8、對組內成員的工作進行指導
1、對客戶的溝通協調工作負責;
2、對軟件的開發效率、質量、費用負責
3、對用戶的需求分析的質量負責;
4、對系統總體設計、詳細設計文檔質量負責
軟件設計師
1、負責系統的模塊設計,詳細設計文檔
2、繪制界面原型demo等,設計功能使用的具體描述、行為者、前置條件、后置條件、UI描述、業務流程/子流程/分支流程,界面說明等,完成大部分的前端設計,小部分的后端設計。
3、負責技術難度大的模塊的代碼或者公用模塊代碼的編寫、維護
4、對自己負責模塊的詳細設計、代碼編寫。
5、對小組內人員進行技術指導
1、對組內人員的開發效率負責;
2、對產品整體風格負責
3、對項目整體設計流程負責;
4、對自己模塊的開發效率和質量負責。
程序員
1、與項目經理溝通和確認某個模塊的需求和實現方法
2、負責某個模塊的代碼編寫、維護
3、對其他模塊的代碼的維護
4、負責與測試人員的交互,處理測試人員的問題
1、對自己模塊的開發效率和質量負責。
測試工程師
1、根據用戶需求分析和系統總體設計,編寫測試文檔和測試用例。
2、對系統的功能、性能、異常進行測試。
3、編寫測試文檔和操作指導手冊。
1、對測試的質量負責
2、對測試文檔和操作手冊的質量負責。
四、項目立項
1、分析人員進行應用調查與分析,確認軟件的應用需求。
2、成立項目評審會,開發總監、部門經理和指定人員必須參加。對項目進行可行性研究,編寫項目建議書,評估項目的難度和工作量,形成可行性研究報告。
3、根據項目配置的優劣成立項目開發組,制定軟件開發計劃,確定項目經理,由部門和項目經理共同來確定具體項目配置,知識技能要求,團隊成員及團隊的角色。
五、項目計劃與監控
1、以項目為單位,項目經理負責整個項目的計劃、組織和控制。
2、在整個項目過程中,項目經理定期檢查項目進度和完成情況,調整人員分工和安排。
3、項目計劃需要變更時,需要明確變更內容并及時匯報。項目經理需要說明客戶變更原因并將變更說明提交公司領導審核,以便根據變更內容及時調整計劃。
六、需求分析
1、對用戶提出的需求進行分析匯總,梳理用戶的業務流程和詳細的功能定義。
2、做出簡單的界面原型,與客戶進行有效的溝通,
編寫需求詳細說明書。
3、根據現有條件進行估計,制定項目進度,制定詳細的軟件開發計劃。
七、總體設計
1、在該階段確定總體結構和軟件開發架構,文件命名規范,編碼規范??砂窜浖枨髣澐殖勺酉到y,也可直接定義目標系統的功能模塊及各個功能模塊的關系。
3、確定軟件模塊結構,給出每個功能模塊的功能描述、數據接口描述,并完成系統概要設計說明書。
4、完成數據庫的設計,并編寫數據庫設計說明書。
5、完成的文檔需提交公司進行歸檔管理。
八、詳細設計
1、調整前一步設計的不足,確認各模塊之間的詳細接口信息。
2、設計功能使用的具體描述、行為者、前置條件、后置條件、UI描述、業務流程/子流程/分支流程,界面說明等。
3、確定模塊內的數據流或控制流,對每個程序模塊必須確定所有輸入、輸出和處理功能。
4、匯總并提交所有相關文檔,審核確認質量和進度。
九、軟件實現
1、項目組根據概要設計說明書、詳細設計說明書制定系統實現計劃
2、有條件的情況下保證開發、測試和生產環境獨立。選擇軟件工具,明確項目成員的職責分工,按照編碼規范和詳細設計實現軟件功能。
3、代碼應滿足結構良好,清晰易讀,且與設計一致,符合編碼規范。
4、開發人員需要軟件實現過程中編寫軟件功能說明,源代碼說明。軟件功能說明文檔應說明項目名稱、編號、軟件名稱和版本號,軟件功能、主要功能實現過程。源代碼說明應說明項目編號、軟件名稱、功能,全局變量、數據庫字典、函數功能、接口。該文檔包含在源代碼文件中,以注釋形式存在。
5、項目組進行單元測試和集成測試。開發人員處理測試人員反饋的測試問題,并以書面形式反饋主要問題及解決辦法,直至系統運行穩定。
6、匯總并提交所有相關文檔,提交公司備案。
十、軟件測試
1、根據單據測試和集成測試兩個過程,制定測試計劃。按階段設計測試實例,并將測試結果記錄,未通過的的反饋給開發人員調整。
2、完成測試文檔、操作手冊、安裝維護手冊的編寫。
十一、用戶培訓
1、準備用戶培訓計劃、培訓手冊
2、確定培訓時間、培訓地點,向用戶進行系統使用培訓、操作指導及提供軟件操作手冊。
3、保留培訓簽到表,用戶意見等存檔。
十二、系統上線
1、
制定上線計劃,確定上線工作時間表,部署的環境。
2、上線操作步驟以及問題處理步驟;
3、根據軟件特點、客戶需求進行軟件部署,并記錄軟件部署和運行結果;
4、項目組根據系統運行請款對系統進行優化,記錄系統的運行情況、系統問題和處理后的版本。
十三、系統驗收
1、驗收工作準備,按要求整理項目成果物,打印裝訂成冊,并提交客戶方。
2、系統主要使用部門及信息技術部門聯合成立項目驗收小組,從需求功能及技術需求層面對系統進行綜合評估和項目成果物的審核,根據驗收情況形成系統驗收報告
3、應用部門及信息技術部門負責人根據系統試運行情況簽署驗收意見。
十四、產品維護
1、調出項目主要開發人員,按照合同要求安排維護人員對系統進行技術支持。
2、系統需求變更或調整,記錄變更原因和軟件及源代碼的版本控制,按照軟件變更要求對系統進行維護。
十五、源碼和文檔
1、源代碼/文檔管理采用版本控制軟件SVN。
2、按項目的階段性完成源代碼、文檔的上傳。項目負責人每天對代碼進行檢查,開發總監或部門經理定期進行抽查。
3、文檔分為項目文檔和個人文檔,文檔上傳前進行歸類和匯總。
十六、質量檢查
1、項目負責人每天要檢查成員的工作完成情況,特別是新員工的工作進展;
2、工作抽查制度:不定期的進行抽檢,并將檢查對象、檢查時間、檢查內容、檢查結果反饋給被抽檢人。
3、內部審核制度:針對業務需求、概要設計(功能界面、數據庫)或疑難問題組織評審會,提出意見或解決方案。
十七、文檔規范
1、需按照軟件實施的階段落實成果物,參照《軟件過程提交成果表》。
2、如果客戶有特殊要求,請按照客戶要求的規范完成。并將最終的問題提交公司歸檔備份。
十八、軟件變更
為規范軟件變更與維護管理,特制定本制度。本制度適用于應用系統開發完畢并正式上線,移交給客戶方之后的運行支持及系統變更工作。
1、系統變更工作可分為功能完善維護、系統缺陷修改、統計報表生成。
2、需求部門提出系統變更需求,開發部技術支持人員根據重要性和緊迫性做判斷,確定其優先級和影響程度,并進行相應處理,同時將變更需求整理成系統變更申請表。
3、系統變更實現過程按照軟件開發過程規定進行,遵循軟件開發過程統一的編碼標準和版本控制,并經過測試通過才能完成部署和上線。
4、在系統變更完成后,開發人員需將系統變更表的執行結果找業務部門負責人簽字后,提交至公司進行歸檔管理。
8
篇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組組長派專人監控合作開發商的質量保證過程。
第五十九條 項目組同合作開發商商定驗收的標準和方法。
第六十條 以上各要求需要在開發合同中明確。