軟件項目開發(fā)流程

1、某軟件工程開發(fā)流程修改歷史日期作者修改內(nèi)容2003-03-12張京宇新規(guī)制作2003-5-18張京宇人員職責的變更，內(nèi)容的變更2003-12-4張京宇針對2004年度制作最新工作內(nèi)容下的工作流程2004-1-14張京宇添加工程經(jīng)理管理被職員填寫下周日程表的規(guī)那么1概述1.1 目的 用標準化的流程來統(tǒng)一管理公司的運作，防止混亂，提高管理的質(zhì)量。在遠程開發(fā)上，結(jié)果XX軟件自身的特點，量身定做，解決遠程開發(fā)上的問題。在實施過程中，所有管理者能夠根據(jù)此統(tǒng)一的流程，總結(jié)經(jīng)驗，提高認識，加強技術水平和管理水平。提高公司級的技術分析能力，為公司儲藏一支分析隊伍，側(cè)重在需求理解和需求分析、框架設計上的能力。保

2、證在2004年能夠全盤進行中方市場的順利運作。對人員負責內(nèi)容上，明確化各自負責的內(nèi)容，提高工作效率。1.2 內(nèi)容概述 開發(fā)部日常工作流程開發(fā)部管理流程 開發(fā)部績效考核流程 開發(fā)部鼓勵和過失管理流程2開發(fā)部日常管理流程具體實施方案2.1 根本原那么公司開發(fā)部力求建立公平公正的評價體系，嚴謹?shù)墓ぷ髁鞒潭x和及時的記錄與反響，標準職員活動，形成一個緊張有序的團隊。沒有一個明晰的流程和高效的反響體系，就不可能把工作做好。但是，這需要每個人按照規(guī)那么把自己應該負責的那一局部高效完成，只有這樣才能保證整個系統(tǒng)的順暢，同時，如果個人沒有完成自己的指責和按照規(guī)定填寫內(nèi)容，影響的不單單是自己的工作而是整個系統(tǒng)。

3、2.2 內(nèi)容概述Esm使用規(guī)那么 目的注意是為了提高開發(fā)部整體的方案能力，反響能力和管理者的控制能力。 同時提 高整體職員參與公司管理的渠道，適應東京上市公司對信息管理的要求。日?；顒拥姆椒ㄌ峁╅_發(fā)部工作流程外的突發(fā)事件的解決方法2.3 內(nèi)容詳細描述2.3.1 Esm使用規(guī)那么(1) schedule的使用 加強全體人員的方案能力，做到我每天要做什么？今天工程經(jīng)理給我的安排是什么？ 對應工程經(jīng)理和部長要知道每個人在做什么？只有這樣，才能保證控制人員可以宏觀 調(diào)控，而個人也不會不知所措。本卷須知：1.必須使用長期類型(哪怕只有一天)保持統(tǒng)一性2開始時間必須為 22 : 00結(jié)束時間為23 : 0

4、0 ,為了區(qū)分其它人填寫的日程安排3填寫日程安排時，必須選擇對應的anken，否那么不能于系統(tǒng)內(nèi)的工程關聯(lián)，統(tǒng)計軟件失去作用。4日程安排的主題要修改，規(guī)那么為工程號中文版工程為北京內(nèi)部工程編號，暫時 沒有編號可以寫工程名稱。內(nèi)容負責人填寫要求監(jiān)督人違規(guī)處理下周工 作安排工程經(jīng)理技 術分析負責 人測試組經(jīng)理必須每周五16 :00前填寫完畢。同時類型統(tǒng) 用長期進行定義，為每一個人員安排下周工作計戈嘰填寫監(jiān)督：項 目總控助理 內(nèi)容監(jiān)督：部 長和工程總 控人員沒有按時提交的，管理者扣除MD 0.2日?；?動安排開發(fā)部全體人員建議大家把工作安排填寫，有利于提高自己的方案能力和規(guī)劃能力。同時能保證事情不會

5、忘記。無待辦事 項開發(fā)部全體人員建議填寫，管理者應該必須使用。 主要是把事務管理的井井有條。無制作下 周工作 安排表工程總控助理負責利用工具【導出下周工作表系統(tǒng)】制作開發(fā)部下周工作方案表。每周五下班前發(fā)送東京。東京工程負 責人2 Report的使用 作為上市公司的子公司要求公司正規(guī)化，第一步公司的日報系統(tǒng)的建立和審查，所以從本年度起必須建立此系統(tǒng)。同時，在管理上解決口頭匯報，不客觀而事后 而無據(jù)可查的弊端，為及時了解問題并解決問題，提供第一手的素材。同時工程總控助理，也要本著實事求是的原那么，根據(jù)大家的填寫內(nèi)容向東京證券市場提交?作業(yè)公務表?，所有填寫者一定要保證填寫日報的消耗工時和最后工資結(jié)

6、算時當日工時保持嚴格一致。內(nèi)容對應esm的名稱填寫要求監(jiān)督人違規(guī)處理工程選擇工程直接選擇自己對應的工程，如果工 作對象不是工程本身那么需要選擇以下工程:顧客名稱為2004年過程 管理專用公司會議公司培訓公 司管理 其它 注意:只有部長以上才 填寫以上 工程公司培訓除外，部 長以下 全部選擇對應工程。見附圖 1XX扣除MD 0.1當日工工作內(nèi)容1.填寫當日的模塊名稱模塊填寫監(jiān)督：沒有填寫1次人作內(nèi)容和 進度與進度名稱參考2 .中的功能點表3 .細度要求功能點XX內(nèi)容監(jiān) 督：工程經(jīng)理民幣5元工作耗時工作耗時要求與工資計算工時想對應。esm中數(shù)據(jù)庫的數(shù)字和工時統(tǒng)計必須對應，此為東京證券的要 求數(shù)字核

7、對：XX數(shù)字不對者，按照一次扣除 0.1MD問題反響問題反響把當天所遇到的問題按照條目化羅列。必須包含內(nèi)容和狀態(tài)兩部分例如：1內(nèi)容：BS詳細頁面存在老bug, 狀態(tài)：已經(jīng)解決2內(nèi)容：文檔2.3出現(xiàn)問題，無法繼續(xù)。狀 態(tài)：等待解決內(nèi)容監(jiān)督： 工程經(jīng)理不付責任的亂填 或不填，一個日報 扣除0.1MD 女口果 在特殊情況下無 問題，也要寫無MD輸入訂貨預定金額必須在工程總結(jié)會議結(jié)束之后， 同 時要經(jīng)過工程經(jīng)理的審核。 輸入值 為實際值的10倍因為數(shù)值型目前 只能為整數(shù)職員的輸入 由工程經(jīng)理 負責工程經(jīng) 理的核對由 工程總控助 理進行職員如果不填寫 那么按照輸入值進 行績效考核。如果職員輸入的 MD與

8、分配時不符 合工程經(jīng)理扣除0.5MD附圖1:3 周報 Week Report 日報Daily Report 的使用主要是使用對象為管理者，主要是適用于向管理者匯報整體問題。在概念上，日報周報為概括說明，而report那么屬于細節(jié)描述。內(nèi)容負責人填寫要求監(jiān)督人違規(guī)處理日報工程經(jīng)理部長?部長工程進展狀況： 不能解 決的問題反響建議或提 議突發(fā)問題必須反響工程總控人員如果由于沒有匯報造成 問題，按一次扣除 0.5MD周報工程經(jīng)理?部長 部長?工程總控工程進展整體狀況： 不 能解決的問題反響建議 或提議必須填寫工程總控助理周報不寫，按次扣除0.2MD4目標功能的使用 由于分部內(nèi)有單獨的鼓勵費用，所以建

9、議分部內(nèi)建立目別考核體系為每一個程序員 根據(jù)個人不同的能力和狀況設定目標，對于圓滿完成目標者進行鼓勵。同時，保證公 司的開發(fā)效果在可控制范圍內(nèi)。5工程信息管理的使用。本管理系統(tǒng)在2003年開始實行，主要目前是記錄公司所有工程的里程碑信息。為以后工程的整理和后期處理提供真實的數(shù)據(jù)。同時，維護公司的工程信息數(shù)據(jù)庫。本卷須知：其中關于工程中所設計的文檔，統(tǒng)一放在fileserver上2004目錄中。關于文檔名稱和路徑的書寫方法如下，保證能夠盡快翻開文檔:/fileserver/project/2004/14258/ 測試用例 H4258_testcase.xls2004年1月1號起,東京新工程工程要

10、求對應負責人出錯處理方法備注工程名稱必填，同時應有對應 的工程號XX扣除MD 0.1北京工程編號必填XX扣除MD 0.1添加時一定要注意 唯性，與工程類型不能為空，目前類型有 Research NormalConfirm MergeOthersXX扣除MD 0.1目前的規(guī)那么為小于5md的均為RESEARC 項 H 目工程名稱必填XX扣除MD 0.1工程的名稱應包含 工程的ID,關于工程 ID的生成方法，參 考日方對應文檔客戶方負責人必填XX扣除MD 0.1分析負責人北京分析工程，為必 填工程東京設計，為 非必填部長但是必須制 定具體負責人扣除MD 0.1工程負責人必填工程部長扣除MD 0.1

11、工程負責人應該是 直接負責人不是 最先指定的部長本公司負責人不能為空初始必填 的人員為工程總控 人員及助理、對應部 長、測試部經(jīng)理，公 司技術負責人馬 俊XX工程負責人扣除MD 0.1如果沒有工程負責 人，與XX聯(lián)系分析開始時間必填對應該工程的分析 員扣除MD 0.1公司技術負責人在 分析工程開始時應 把對應分析員加到 工程列表中概要設計完成時間必填對應該工程的分析 員扣除MD 0.1詳細設計完成時間必填對應該工程的分析 員扣除MD 0.1FP文檔完成時間必填對應該工程的分析員扣除MD 0.1分析完畢時間必填對應該工程的分析 員扣除MD 0.1工程接收時間必填XX扣除MD 0.1工程最終對應M

12、D原那么不為空，在特殊 情況下為空，在工程 備注重必須說明原 因。XX工程經(jīng)理 Mail通知扣除MD 0.1本MD伴隨著MD的 變更需要動態(tài)變化Md變更附件名稱不是必須，但是只要 有變更有內(nèi)容，此項 目必須要有XX工程經(jīng)理 Mail通 知扣除MD 0.1工程最終報價原那么不為空，在特殊 情況下為空，在工程 備注重必須說明原 因。XX扣除MD 0.1必須與對應MD*11000 根本一致。同時必須和MD變更紀錄致Schedule文檔名稱及路徑必填工程經(jīng)理扣除MD 0.2可以用excel或者是 visio , project 后兩 種要以HTML輸出 以便查閱?？蛻?方deadline要求如果提供必

13、填XX扣除MD 0.1Alfa版時間必填XX工程經(jīng)理 Mail通 知扣除MD 0.1Beta版時間必填XX工程經(jīng)理 Mail通 知扣除MD 0.1Alfa變更紀錄最后一次記錄變更 的時間必須和對應 的alfa版時間和beta 版時間致XX工程經(jīng)理 Mail通 知扣除MD 0.1工程開始時間必填XX工程經(jīng)理 Mail通知扣除MD 0.1CSV分支號必填工程經(jīng)理扣除MD 0.1此分支號為開發(fā)分支號功能點文檔文件名及文件路徑FileServer 效勞器必填工程經(jīng)理扣除MD 0.1此文檔為必須文檔， 各工程經(jīng)理必須嚴 格控制。單體測試用例文件 名稱及文件路徑必填工程經(jīng)理扣除MD 0.1此文檔為必須文檔

14、， 各工程經(jīng)理必須嚴 格控制工程總結(jié)與MD分必填工程經(jīng)理扣除MD 0.1此文檔為必須文配方案文檔及文件路徑檔，各工程經(jīng)理必須 嚴格控制。測試負責人必填XX扣除MD 0.1測試用例對應文件名稱及路徑必填XX扣除MD 0.1此文檔為必須文檔， 各工程經(jīng)理必須嚴 格控制。第一階段測試開 始時間：必填測試人員扣除MD 0.1第一階段測試完 成日期：必填測試人員扣除MD 0.1Alfa版本后的BUG :必填測試人員扣除MD 0.1回歸測試的開始日期：必填測試人員扣除MD 0.1回歸測試的結(jié)束日期：必填測試人員扣除MD 0.1Beta版后的BUG 數(shù)：必填XX扣除MD 0.1主要要參考beta后 bug的

15、整理表確認負責人不是必須，主要是與 是否進行確認有關， 如果確認其他有信 息，確認負責人必填XX扣除MD 0.1232系統(tǒng)的使用(1) 電子打卡系統(tǒng)的使用目的：主要是利用電子打卡，提高效率，能夠及時反映請假和遲到，并且所有的數(shù)據(jù)能夠直接被人事利用。要求：2004年2月開始啟用，2月為試用期，但是要求每人必須嚴格填寫，如果不填寫并結(jié)合打卡， 忘記填寫扣除過程管理MD 0.1計算。(2) 會議室、洽談室、經(jīng)理室的使用管理目的：主要是在人數(shù)多而會議室相對緊張的狀態(tài)下，解決矛盾的一種方法。同時審核各工程組是否及時安排公司規(guī)定的兩次會議。2004年2月啟動，沒有按照規(guī)定進行會議，經(jīng)審核后，扣除工程經(jīng)理過

16、程管理 MD0.2,忘記登錄的按照統(tǒng)一標準處理。公司內(nèi)部論壇的使用主要是要有利于公司內(nèi)部開辟一塊公司可以自由發(fā)表言論的地方。同時，在技術討論上，希望能夠把知識點做一個累計，以便新員工能夠進行參考和積 極發(fā)表意見。3開發(fā)部管理流程具體實施方案(1)開發(fā)部管理人員工作流3.1 內(nèi)容概述 開發(fā)部從流程上主要分為以下幾方面:(2)(3)(4)(5)(6)BUG Survey工作流工程分析工作流Beta后質(zhì)量保證工作 流測試組beta前工作流工程組運行根本工作 開發(fā)部從實施人員角色劃分如下：開發(fā)部經(jīng)理： ( DM01 ) 統(tǒng)籌解決公司開發(fā)部的全部事宜。進行開發(fā)部的整體方案的制定和實施，保證開發(fā) 部的可持

17、續(xù)開展和利潤率。工程總控人員： (DM02) 對公司級的資源進行調(diào)配，同時，直接了解日方的戰(zhàn)略安排，為北京方的戰(zhàn)略安排 提供的第一手的資料。同時，在工程分配上保證三個分部間工程的均衡 (一個季度內(nèi) ) 開發(fā)部部長： (DM10) 在公司統(tǒng)一的規(guī)那么范圍內(nèi)，負責分部的建設。協(xié)調(diào)各開發(fā)組的問題，處理解決分部內(nèi)發(fā)生 的問題。做好所 有公司要求的標準流程內(nèi)的內(nèi)容。同時，在許可范圍內(nèi)，可以進行單獨的 管理方法的嘗試和分部內(nèi)鼓勵的 分配。技術設計負責人： (DM11) 統(tǒng)一協(xié)調(diào)分析組的工作，在對日工程分析組中，進行設計文檔的統(tǒng)一確認，在對 中方工程 中，承擔需求的統(tǒng)一把關處理。同時負責分析組的日常工作安排

18、的統(tǒng)籌。BUG Survey 總負責人 (DM12) ：統(tǒng)一管理 package 和已經(jīng)提交工程的統(tǒng)籌管理。組織形式上，傾向于單獨的組織模式。在 目前的情況下， 以靈活為主，臨時性的進行 bugSurvey 組的組織和 bugSurvey 組內(nèi) team leader 的指定和管理。在間隙階段， 直接進入分析組進行工程分析工作。工程總控助理：xx (DM13)輔助開發(fā)部的工程管理工作，主要負責中日雙方的信息的反響紀錄整理，以及 esm 和 taskschedule 信息的維護工作。負責公司級工程文檔，過程參數(shù)的監(jiān)督，同時向日本總部匯報各種參數(shù)和報表。常務工程經(jīng)理： (DM20) 目前 11 名

19、各分部內(nèi)程序員的日常管理，整個開發(fā)過程中的控制和日方負責人的信息交互，負責組內(nèi)程序員的績效考核和問題解決。測試部經(jīng)理和翻譯部經(jīng)理包含在內(nèi)。技術分析員：(DM21)對日方的需求進行概要分析和設計，并書寫設計書，F(xiàn)P。對中方的工程中，負責需求的整理和各種設計文檔的實施，同時，負責和工程經(jīng)理和測試部經(jīng)理的溝通。臨時工程經(jīng)理： (DM22) 此角色主要是在接受日方外包工程或整體公司產(chǎn)品設計中，需要臨時成立工程組， 而從分析組中或者常務工程經(jīng)理中抽調(diào)。臨時工程經(jīng)理需要全權(quán)負責此工程的實施，同時需要和公司簽訂工程負責保證書，以保證工程的進行和最后單獨工程鼓勵的兌現(xiàn)。程序員：主要是負責工程按照分析文檔的實施

20、，同時，在實施過程中優(yōu)化代碼結(jié)構(gòu)，提出合理化建議，其中優(yōu)秀者可以作為 TeamLeader 負責具體組織工作和分析管理工作。測試員：負責公司測試流程的具體實施，要求掌握測試的技術，提出合理化建議，并保證整個軟件的可靠度。翻譯人員： 負責中日方文檔的翻譯，要求工作嚴謹，保證質(zhì)量。在同日方交流中，負責接待和溝通。同時，在個人的開展意向中可以兼顧其它公司內(nèi)的常務工作。3.2 開發(fā)部概要流程圖3.3 開發(fā)部管理人員工作流3.3.1 軟件開發(fā)管理體系構(gòu)成參與人員 ：工程總控人員(工程總控助理)+部長 +(技術設計負責人 +BugSurvey 負責人)+各級工程經(jīng)理管理主線：(1)工具類 tasksche

21、dule 表：主要目的是增加遠程開發(fā)的方案和規(guī)劃性。 管理人員去適宜目前我們正在進行的總量有多少，檢收而為付款的有多少，實施完畢而沒有檢收的有多少。管理人員去看我們下周能夠接受的工程有多少，以便在每周五可以制定下周的工作方案。工程經(jīng)理可以看自己負責工程的根本參數(shù)。夠提高Esm 系統(tǒng) ： 通過 esm 系統(tǒng)詳細的記錄開發(fā)過程中的每個里程碑參數(shù)，保證在管理上能 管理細度，以便于及時發(fā)現(xiàn)并改正問題和錯誤。Bug 管理系統(tǒng)： 作為質(zhì)量控制過程實際結(jié)果的監(jiān)控。 以便總結(jié)質(zhì)量的問題， 進行反響。 Fileserver 文檔 ：通過文檔管理和整理， 保證全部職員能夠隨時的了解其他工程的信 息和相信內(nèi)容。 同

22、時， 統(tǒng)一化文檔管理，為以后的開展提供素材。所有的文檔主要包 含如下幾種：HearingSheet ：一個簡要的需求，重點在于強調(diào)這個需求的原因前因后果 UI 文件 設計 文檔： 東京和北京共同進行FP 報價書QuestionSheet ：所有的問題一定要集中在一個文檔內(nèi) 功能點文檔：一定要融合questionSheet 內(nèi)對應答案的所有內(nèi)容 schedule 文檔：要包含甘特圖工程總結(jié)及 MD 分配方案： 把工程總結(jié)作為重點進行。 單體測試用例；條數(shù)最少為 MD*2, 按 照模板進行 測試組測試用例 : 要保證最后的測試結(jié)果 確認測試用例： 一般為東京發(fā)送 beta 版后障害書：工程確認者發(fā)

23、送，按照同一格式進行書寫和填寫。beta 后障害 list 表，其中包含 bug 的簡單描述、 bug 的類型確定和各部門關于 bug 的總結(jié)。 2過程管理類 一個工程兩次會議：工程啟動會議和工程總結(jié)會議 工程啟動會議主要是講述 工程的功能點，并據(jù)具體問題，進行嚴格的定義，說明本項 目所必須遵守的特殊規(guī)那么，子功能間 的前后順序，統(tǒng)一的接口定義，和每個人在工程 實施中應該注意的問題。 工程總結(jié)會議和 MD 分配方案確實定。主要是根據(jù)工程實施的結(jié)果，進行集中的討論 和諧而公 平的團隊 ：公司其他方面的管理，就是為了加強管理，提倡量化。做到各司 其職，多勞多得， 公平評價，提供時機給相應的人。33

24、2管理示意圖333管理人員本卷須知其中反響機制的建立最關鍵。其中管理必須遵守以下規(guī)那么:對象流程編口，號工作內(nèi)容上流方下流方備注工程總控人員分配工程東京工程發(fā)包人員紀秀玲部長工程總控助理解決人力矛盾部長BugSurvey 負責人技術設計負責人部長 BugSurvey負責人技術設計負責人下流方人員負責把結(jié)果 反響給東京擔當者開發(fā)部經(jīng)理公司管理問題部長工程經(jīng)理各級負責人職員全體職員一定要給問題提出者答復，成為制度后公布部長分配工程工程總控人員工程總控助理對應分部工程經(jīng)理工程總控助理Esm工程負責人參加，修 改負責人為此工程經(jīng)理工程人力調(diào)節(jié)無工程總控人員如果出現(xiàn)空閑同時反響。分部管理問題無開發(fā)部經(jīng)理

25、工程經(jīng)理工程分析和問題確認無東京負責人結(jié)果物概要需求文檔和問題與回復整理文檔工程里程碑信息反響 工程 開始時間，alfa,beta版本時 間和原因，fp變更及原因無工程總控人員 工程總控助理 測試部經(jīng)理組織團隊進行技術文檔的書寫和維護無測試部經(jīng)理team所有成員文檔列表如下：功能點文檔 questionSheet Schedule單體測試用例BugSurvey負責人Bugsurvey的調(diào)查修改 merge工程總控人員各級的bug survey leader Bug survey 實施 人員所有的規(guī)那么按照bugsurve流程的規(guī)定。工程總控助理監(jiān)督esm的執(zhí)行情況程序員工程經(jīng)理部長工程總控監(jiān)督

26、過程管理參數(shù)部長工程經(jīng)理工程總控整理所有工程文檔工程經(jīng)理工程總控對日匯報表系統(tǒng)數(shù)據(jù)工程總控績效考核提供過程情況 匯總系統(tǒng)數(shù)據(jù)工程總控月度過程管理處理表測試部經(jīng)理組織書寫測試用例工程經(jīng)理功能點 文檔東京整理匯總beta版后bug分析表工程經(jīng)理提供的 完整的B后障害 書所有管理者其中的技術分析和官理 分 析及對東京的建議應由項 目負責人進行填寫控制測試的結(jié)果3.4Bugsurvey工作流參見?bugSurvey工作規(guī)約?。3.5工程分析工作流 參見?工程分析工作規(guī)約?3.6Beta后質(zhì)量保證工作流參見?beta后規(guī)作規(guī)約?3.7測試組beta前工作流3.8工程組根本工作流概述在工程進行過程中，要求

27、能夠及時反響。做好方案安排，并調(diào)整這個人力的配比， 以到達最好的效果。382對程序員的要求 尤其在分析組成立前期，對分析組的設計書，盡可能提出建設性意見 和設計的問 題，有利于提高工程分析能力在功能實現(xiàn)上，主要和工程經(jīng)理的溝通，把類結(jié)構(gòu)設計和代碼向理想情況努力，同時用公司內(nèi)的代碼標準作為自己的行動準那么在日?；顒又校訌妶F體意識，加強責任感。對工程經(jīng)理的要求 主要職責為：類設計的嚴格控制。保證整個軟件包的可維護性工程過程管理。能夠緊密的控制整個工程的進程，發(fā)現(xiàn)工程中的各種風險因素，盡早地把風險在工程中消除。硬性要求如下：1每個工程大于 10MD正常工程必須提供的文檔為功能點文檔， questi

28、onSheet，單體測試用例，工程總結(jié)及MD最終分配方案文檔2 每個工程大于 10MD正常工程必須召開兩次會議：3 工程啟動會議主要為了統(tǒng)一工程的內(nèi)容規(guī)那么和要求，同時把整體邏輯和框架做簡要 說明。4 工程總結(jié)會議：主要是評價每個成員的表現(xiàn)和工程完整的狀況和質(zhì)量，總結(jié)失敗的經(jīng)驗教訓。同時根據(jù)評論的結(jié)果進行最后的MD的分配。5 在esm必須登陸必要的過程參數(shù)，以便團隊成員和公司的管理者能夠及時的把我目前工程狀態(tài)。整個團隊的建設和公司的管理工作。在工程管理中發(fā)現(xiàn)問題，把反映給公司。以備在公司級別對整個流程和各個環(huán)節(jié)進行調(diào)整。流程圖385工程組文檔管理原那么：所有文檔必須都放在 fileserver

29、上，進行統(tǒng)一管理。同時，負責人在本地應保存一份同樣的備份。All Buginu2004年開始接收到的工程必須放在2004中，針對每個工程必須按照以下圖進行文檔管理。細節(jié)描述工程內(nèi)容備注Spec設計說明書QuestionSheet設計說明書的補充說明 設計說明書的各個版本 設計說明書一覽表設計說明書一覽表要記錄所有文檔 變更的情況，并指明最后工程實施 與 文檔之間的關系Test case工程組書寫的單體測試用例測試組書寫的測試用例東京發(fā)送的confirm測試用例Schedule針對工程實施的日程安排 對東京進行進度匯報的每個報表Fun cti onPoi nts功能點文檔All Bug Spec

30、Beta后障害書 針對此工程的beta后bug類型確疋和 經(jīng)驗匯總。完 畢后，應及時發(fā)送測試組工程經(jīng)理。UIHtml DemoHeari ngSheet聯(lián)系分析組，如果有應該直接copyFP SpecFP sheet不同版本FP change 表FP說明，記錄所有FP變更歷史，以備后期確認的方便。工程spec的中文版需要打印，此工作由工程總控助理執(zhí)行。同時，對文檔進行歸檔和密封。3.9 測試部B版前流程相關人員測試部經(jīng)理：XX測試組成員：3.9.2 測試人員的要求 一定要注意配合。因為，在此環(huán)節(jié)，一種好的描述方式和溝通方式 將會直接影響 工作效率和工作質(zhì)量。所以，首先大家要注意 bug 管理系

31、統(tǒng)的使用方法和 規(guī)那么， 同時，盡量采用統(tǒng)一的屬于進行描述，如果需要圖形輔助，也可以進行貼圖。 加 強需求理解能力。能夠盡快的理解文檔和功能測試用例。 在工作中細致、耐心、有條理。 同時對應 esm 系統(tǒng)需要測試部填寫的過程參數(shù)必須嚴格按照規(guī)定填寫。3.9.3 工作流程圖3.9.4 本卷須知Bug 管理系統(tǒng)中的狀態(tài)一定要維護，并通過此系統(tǒng)來保證alfa bug 修改的進行情況， 即在提交 beta 版前，所有的 alfa bug 的狀態(tài)都應該在 DO 上。如果沒有在此狀態(tài)中， 應該積極和 工程組聯(lián)系，測試組有權(quán)監(jiān)督其完成。測試組要驗證工程組提交的 script 和 resoruce 文件，如果

32、有問題，測試組有權(quán)通知項 目立即 修改，同時可以作為 alfa bug 登錄在 bug 管理系統(tǒng)中。測試組要保證測試用例的質(zhì)量， 盡一切可能減少 beta 后 bug 的數(shù)量。并嚴格的按照 beta 后 bug 處理規(guī)約進行。4 績效考核實施方案4.1 總那么： 所有職員的所有工作都應該以量化計算， 如果不能，那么當事者可以提出異議， 而對績 效考核方法進行改進。例如所有北京工程必須有 MD ，翻譯組翻譯工作量可以通過翻譯的字數(shù)進行調(diào)整，測試組同樣對工作內(nèi)容進行分類核算MD 。量化管理主要包含幾個主題方向：工作時間： 是人事部門公布的每個月的工時統(tǒng)計的結(jié)果。 實際上， 它代表了自己的實 際消

33、耗時間。東京 MD ： 是實際為公司所創(chuàng)造的價值。北京 MD： 主要包含正規(guī)作的北京內(nèi)部工程或者實際工作而作的的補充MD 。已到達考核的公平合理。質(zhì)量扣除 MD: 是指由于代碼的 bug 而造成的損失，因為實際的奉獻是要扣除損失的。 對于 測試部就是東京對北京確認產(chǎn)生的 beta 后故障的扣除。過程管理扣除 MD ：除了實際的工作量，就是為個建立一個穩(wěn)固高效的團隊而每個人 應該承 擔的過程管理義務，如果沒有做好，實際上不僅僅是你自己績效不高，而是你 影響了整個團 隊的利益。而這局部的值反映了你對團隊的影響。過程管理獎勵 MD :在工程實施過程中，個人在突發(fā)事件上的處理或者對工程整體乃至公司的利

34、益上作出突出奉獻，可以作為績效獎勵。在整個分類上，根本上是劃分為管理者， 程序員，分析員，翻譯人員，測試人員幾個 子系統(tǒng)。 但是所有系統(tǒng)的價值標準統(tǒng)一。在時間上，每個月的第五個工作日公布績效考核結(jié)果?？冃Э己说慕Y(jié)果直接反映在近期和長<開發(fā)部激期的鼓勵系統(tǒng)中。具體內(nèi)容可以參見 勵和過失管理流程 >4.2 流程圖翻譯組MD核算流程測試組MD核算流程測試組接收功書寫測試用例接到東京通 知后，填寫beta后Alfa 通驗證測試用測試實施按用晌力aet皈能點文檔通知工程組MD核算流程按照MD10 %分析組MD核算流程月度績效報表，根據(jù)beta后bug進行質(zhì)事項內(nèi)容、/、*. ' J&

35、gt; A 汪意負責人備注測試組績效主要根據(jù)測試的工作量 和工作結(jié)果來進行MD的度量強調(diào)質(zhì)量，會加大 質(zhì)量影響的力度。測試部經(jīng)理要按工程進行分配，多退 少補。測試組質(zhì)量考核主要是根據(jù)beta后bug進 行，如果出現(xiàn)beta后bug同 時被確認為實施bug，對應 測試人員應該承擔質(zhì)量責 任，按個實施bug扣除0.1MD計算要注意參看beta 后 bug 匯總表。測試組最關鍵的問題是根 據(jù)B后的bug情況做分析 總結(jié)，可向公司申請bug 分析內(nèi)部文檔， 通過后可 按北京工程補充MD測試組工作量百分比目前是測試工作本身工程 MD X 10 %測試用例的書寫 是工程MD X 10 %目前的測試用例 由

36、于是初步書寫。 所以僅限于第一 月工程總控人員第一月后根據(jù)測試用例書 寫的實際工時和狀況重新審核此百分比工程分析工作量工程分析指拿到文檔后， 進行的需求詳細分析，提 出問題，完畢questionSheet 文檔和功能電文檔原那么上工程經(jīng)理 直接進行，同時也 可以委托組內(nèi)具 有分析能力的程 序員進行，但工程經(jīng)理MD分配時誰分析誰拿走 對應的10%的MD是必須是工程經(jīng)理負責制工程組質(zhì)量考核嚴格按照alfa版后的bug 進行，一個bug扣除0.1MDAlfa版的bug登 錄在bug管理系 統(tǒng)中，工程經(jīng)理要 維護此系統(tǒng)的Plan欄目，程序 員要負責其中的 DO欄目。如果不 填寫直接作為過 程管理扣除M

37、D 進行，一次0.1MD測試部經(jīng)理工程經(jīng)理Alfa版質(zhì)量扣除MD的匯 總表測試部經(jīng)理負責。Alfa版過程管理扣除MD 匯總表由測試部經(jīng)理負 責。工程總控助理負責審核測 試部經(jīng)理的工作，如果出 現(xiàn)紕漏，按過程管理扣除MD計算，一次0.1md工程組單體測試用例工作量核算單體測試用例的條數(shù)必 須 大于MD X 2,核算工程經(jīng) 理直接指定此工作包含在實 施70 %的范圍 內(nèi)。工程經(jīng)理工程經(jīng)理和全體管 理者自身績效評定全體team 包含自身在 內(nèi)的平均值所以工程經(jīng)理要 提高整個團隊的 績效為目標工程經(jīng)理由工程總控助理進行監(jiān) 控。出現(xiàn)問題按過失進行 處理。年底績效評定標準直接利用MD進行評價其中包含東京M

38、D和北京MD工程總控人員年底績效加權(quán)系數(shù)確定工程經(jīng)理加權(quán)1.25分析組加權(quán)1.1翻譯組加權(quán)8500字/MD進行折算工程總控人員伴隨業(yè)務和過程的改 變， 如果系數(shù)有疋的偏差， 由工程總控人員 對此系數(shù) 進行調(diào)整，反映在文檔改 版中，并通知全體人員5開發(fā)部鼓勵和過失管理流程5.1 鼓勵管理系統(tǒng)5.1.1鼓勵的定義和類別 定義：鼓勵指職員對公司作出奉獻的對應回報。旨在表達公司公平的原那么，客觀的對個人的能力和價值進行認可。類別與處理方法：類別名稱描述實施方式適用范圍備注特別MD獎勵在工程中作為突出奉獻，對公司的利益 產(chǎn) 生重大影響?？捎刹块L提出申請，項 目總 控人員進行批示。特別獎勵單全體員工特別獎

39、金獎勵在工程中作為突出奉獻，對公司的利益 產(chǎn) 生重大影響?？捎晒芾碚咧苯犹嶙h， 部長 會議進行討論決定。特別獎勵單全體員工部門內(nèi)工程獎 金部長負責制，按季度抽取工程的鼓勵獎 金。內(nèi)容是骨干人員，突出奉獻者和分財務撥款通知單開發(fā)部內(nèi)全 體員工部內(nèi)的個別活動。同時， 適用測試部和分析組金額為：2 X 東京MD 質(zhì)量扣除 MD工程獎金分 配明細表公司資助培訓管理者提議，部長會議審議。針對公司的要求和個人情況，提議確定人選和額度。培訓通知書突出奉獻者 或特別岡位升職參考績效表，考察個人能力，并征求個 人 意見后，進行職位調(diào)整。以給有技術 或管 理能力的人充分的空間。升職通知書管理者考察 通過人員加薪參考績效表，考祭個人能力技術等級 表， 于每年8月和1月啟動調(diào)整薪金調(diào)查程 序，對應該薪金的人進行處理薪金調(diào)整單管理者考察通過人員年終獎金年終獎金額度由東京董事會根據(jù)北京利益情況進行直接確定獎金分配采用同一職能 部門公開化，計算方法，嚴格按照個人 MD 奉獻MD 扣除MD 的百分比進行直 接計算。年終獎金分配表全體員工5.2過失管理系統(tǒng)521定義： 過失泛指由于本人的失誤和錯誤，對公司的利益或潛在利益造成比較大的影