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

1、XX軟件項目開發(fā)流程修改歷史日期作者修改內(nèi)容2003-03-12新規(guī)制作2003-5-18人員職責(zé)的變更，內(nèi)容的變更2003-12-4針對2004年度制作最新工作內(nèi)容下的工作流程2004-1-14添加項目經(jīng)理管理被職員填寫卜周日程表的規(guī)則33344558888810錯誤 ! 未定義書簽。概述1.1 目的31.2 內(nèi)容概述32 開發(fā)部日常管理流程具體實(shí)施方案32.1 基本原則2.2 內(nèi)容概述2.3 內(nèi)容詳細(xì)描述3 開發(fā)部管理流程具體實(shí)施方案3.1 內(nèi)容概述3.2 開發(fā)部概要流程圖3.3 開發(fā)部管理人員工作流3.4 BUGSURVEY作流3.5 項目分析工作流3.6 BETA后質(zhì)量保證工作流3.7

2、 測試組BETAftT工作流3.8 項目組基本工作流3.9 測試部B版前流程4 績效考核實(shí)施方案4.1 總則：錯誤!未定義書簽。4.2 流程圖錯誤!未定義書簽。5 開發(fā)部激勵和過失管理流程錯誤!未定義書簽。5.1 激勵管理系統(tǒng)錯誤5.2 過失管理系統(tǒng)錯誤1 概述1.1 目的用標(biāo)準(zhǔn)化的流程來統(tǒng)一管理公司的運(yùn)作，避免混亂，提高管理的質(zhì)量。在實(shí)施過程中，所有管理者能夠根據(jù)此統(tǒng)一的流程，總結(jié)經(jīng)驗，提高認(rèn)識，加強(qiáng)技術(shù)水平和管理水平。提高公司級的技術(shù)分析能力，為公司儲備一支分析隊伍，側(cè)重在需求理解和需求分析、框架設(shè)計上的能力。對人員負(fù)責(zé)內(nèi)容上，明確化各自負(fù)責(zé)的內(nèi)容，提高工作效率。1.2 內(nèi)容概述開發(fā)部日常

3、工作流程開發(fā)部管理流程開發(fā)部績效考核流程開發(fā)部激勵和過失管理流程2 開發(fā)部日常管理流程具體實(shí)施方案2.1 基本原則公司開發(fā)部力求建立公平公正的評價體系，嚴(yán)謹(jǐn)?shù)墓ぷ髁鞒潭x和及時的記錄與反饋，規(guī)范職員活動，形成一個緊張有序的團(tuán)隊。沒有一個明晰的流程和高效的反饋體系，就不可能把工作做好。但是，這需要每個人按照規(guī)則把自己應(yīng)該負(fù)責(zé)的那一部分高效完成，只有這樣才能保證整個系統(tǒng)的順暢，同時，如果個人沒有完成自己的指責(zé)和按照規(guī)定填寫內(nèi)容，影響的不單單是自己的工作而是整個系統(tǒng)。2.2 內(nèi)容概述日報周報使用規(guī)則目的注意是為了提高開發(fā)部整體的計劃能力，反饋能力和管理者的控制能力。同時提高整體職員參與公司管理的渠道

4、。日?；顒拥姆椒ㄌ峁╅_發(fā)部工作流程外的突發(fā)事件的解決方法2.3 內(nèi)容詳細(xì)描述2.3.1 日報/周報使用規(guī)則(1) 日報/周報的使用加強(qiáng)全體人員的計劃能力，做到我每天要做什么？今天項目經(jīng)理給我的安排是什么？對應(yīng)項目經(jīng)理和部長要知道每個人在做什么？只有這樣，才能保證控制人員可以宏觀調(diào)控，而個人也不會不知所措。注意事項：1 .周報哪怕只有一天也需填寫；保持統(tǒng)一性2 開始時間必須為22:00結(jié)束時間為23:00,內(nèi)容負(fù)責(zé)人填寫要求監(jiān)督人違規(guī)處理周報項目組長技術(shù)分析負(fù)責(zé)人測試組組長項目進(jìn)展整體狀況：本周已完成工作量及不能解決的問題反饋，建議或提議；為每一個人員安排下周工作計戈L下周項目風(fēng)險的預(yù)估。必須填

5、寫必須每周五16:00前填寫完畢。項目經(jīng)理沒有按時提交的，負(fù)責(zé)人扣除相應(yīng)的績效日報開發(fā)部全體人員項目進(jìn)展?fàn)顩r：不能解決的問題反饋建議或提議；突發(fā)問題必須反饋；當(dāng)天已完成工作量，明天工作量安排建議大家把工作安排填寫，有利于提高自己的計劃能力和規(guī)劃能力。同時能保證事情小會忘記。項目組長(2) 目標(biāo)功能的使用為每一個程序員根據(jù)個人不同的能力和狀況設(shè)定目標(biāo)，對于圓滿完成目標(biāo)者進(jìn)行鼓勵。同時，保證公司的開發(fā)效果在可控制范圍內(nèi)。3 開發(fā)部管理流程具體實(shí)施方案3.1 內(nèi)容概述開發(fā)部從流程上主要分為以下幾方面：(1) 開發(fā)部管理人員工作流(2) BUGSurvey工作流(3) 項目分析工作流(4) Beta后

6、質(zhì)量保證工作流(5) 測試組beta前工作流(6) 項目組運(yùn)行基本工作流開發(fā)部從實(shí)施人員角色劃分如下：項目組長：統(tǒng)籌解決項目的全部事宜。進(jìn)行項目的整體計劃的制定和實(shí)施，保證項目的可持續(xù)發(fā)展和利潤率。項目經(jīng)理：對公司級的資源進(jìn)行調(diào)配，同時進(jìn)行開發(fā)部的整體計劃的制定和實(shí)施，保證開發(fā)部的可持續(xù)發(fā)展和利潤率。技術(shù)設(shè)計負(fù)責(zé)人：統(tǒng)一協(xié)調(diào)分析組的工作，在對日項目分析組中，進(jìn)行設(shè)計文檔的統(tǒng)一確認(rèn)，在對中方項目中，承擔(dān)需求的統(tǒng)一把關(guān)處理。同時負(fù)責(zé)分析組的日常工作安排的統(tǒng)籌。QA統(tǒng)一管理項目質(zhì)量保證，監(jiān)督項目組各項活動有序開展程序員：主要是負(fù)責(zé)項目按照分析文檔的實(shí)施，同時，在實(shí)施過程中優(yōu)化代碼結(jié)構(gòu)，提出合理化建議

7、，其中優(yōu)秀者可以作為TeamLeader負(fù)責(zé)具體組織工作和分析管理工作。測試員：負(fù)責(zé)公司測試流程的具體實(shí)施，要求掌握測試的技術(shù)，提出合理化建議，并保證整個軟件的可靠度。翻譯人員：負(fù)責(zé)中外文文檔的翻譯，要求工作嚴(yán)謹(jǐn)，保證質(zhì)量。在同客戶交流中，負(fù)責(zé)接待和溝通。同時，在個人的發(fā)展意向中可以兼顧其它公司內(nèi)的常務(wù)工作。3.2 開發(fā)部概要流程圖3.3開發(fā)部管理人員工作流3.3.1 軟件開發(fā)管理體系構(gòu)成參與人員：（技術(shù)設(shè)計負(fù)責(zé)人+測試負(fù)責(zé)人）+項目組長管理主線：管理人員去合適目前我們正在進(jìn)行的總量有多少，檢收而為付款的有多少，實(shí)施完畢而沒有檢收的有多少。管理人員去看我們下周能夠接受的項目有多少，以便在每周五

8、可以制定下周的工作計劃。項目經(jīng)理可以看自己負(fù)責(zé)項目的基本參數(shù)。Bug管理系統(tǒng)：作為質(zhì)量控制過程實(shí)際結(jié)果的監(jiān)控。以便總結(jié)質(zhì)量的問題，進(jìn)行反饋。Fileserver文檔：通過文檔管理和整理，保證全部職員能夠隨時的了解其他項目的信息和相信內(nèi)容。同時，統(tǒng)一化文檔管理，為以后的發(fā)展提供素材。所有的文檔主要包含如下幾種：HearingSheet：一個簡要的需求，重點(diǎn)在于強(qiáng)調(diào)這個需求的原因（前因后果）UI文件設(shè)計文檔：東京和北京共同進(jìn)行估算報價書問題收集表：所有的問題一定要集中在一個文檔內(nèi)功能點(diǎn)文檔：一定要融合問題收集表內(nèi)對應(yīng)答案的所有內(nèi)容計劃文檔：要包含甘特圖項目總結(jié)及績效分配方案：把項目總結(jié)作為重點(diǎn)進(jìn)行

9、。單體測試用例；按照模板進(jìn)行測試組測試用例:要保證最后的測試結(jié)果確認(rèn)測試用例：客戶確認(rèn)beta版后障害書：項目確認(rèn)者發(fā)送，按照同一格式進(jìn)行書寫和填寫。beta后障害list表，其中包含bug的簡單描述、bug的類型確定和各部門關(guān)于bug的總結(jié)。（2）過程管理類一個項目兩次會議：項目啟動會議和項目總結(jié)會議項目啟動會議主要是講述項目的功能點(diǎn)，并據(jù)具體問題，進(jìn)行嚴(yán)格的定義，說明本項目所必須遵守的特殊規(guī)則，子功能間的前后順序，統(tǒng)一的接口定義，和每個人在項目實(shí)施中應(yīng)該注意的問題。項目總結(jié)會議和M防配方案的確定。主要是根據(jù)項目實(shí)施的結(jié)果，進(jìn)行集中的討論和諧而公平的團(tuán)隊：公司其他方面的管理，就是為了加強(qiáng)管理

10、，提倡量化。做到各司其職，多勞多得，公平評價，提供機(jī)會給相應(yīng)的人。3.3.2 管理人員注意事項其中反饋機(jī)制的建立最關(guān)鍵。其中管理必須遵守以下規(guī)則：對象流程編R工作內(nèi)容上流方下方7備注項目經(jīng)理分配項目客戶負(fù)責(zé)人項目組長解決人力矛盾項目組長測試負(fù)責(zé)人技術(shù)設(shè)計負(fù)責(zé)人項目組長測試負(fù)責(zé)人技術(shù)設(shè)計負(fù)責(zé)人下流方人員負(fù)責(zé)把結(jié)果反饋給東京擔(dān)當(dāng)者開發(fā)部經(jīng)理公司管理問題項目經(jīng)理各級負(fù)責(zé)人職員全體職員一定要給問題提出者答復(fù)，成為制度后頒布組長分配項目項目經(jīng)理各個成員項目人力調(diào)節(jié)無項目經(jīng)理如果出現(xiàn)空閑同時反饋。分部管理問題無開發(fā)部經(jīng)理項目經(jīng)理項目分析和問題確認(rèn)無客戶結(jié)果物概要需求文檔和問題與回復(fù)整理文檔項目里程碑信息反

11、饋項目開始時間，alfa,beta版本時間和原因，估算變更及原因無項目經(jīng)理組織團(tuán)隊進(jìn)行技術(shù)文檔的書寫和維護(hù)無測試部經(jīng)理team所有成員文檔列表如下：功能點(diǎn)文檔問題收集計劃書單體測試用例QA監(jiān)督svn的執(zhí)行情況程序員項目經(jīng)理組長監(jiān)督過程管理參數(shù)組長項目經(jīng)理整理所有項目文檔組長項目經(jīng)理對日匯報表組長項目經(jīng)理績效考核提供過程情況匯總組長項目經(jīng)理月度過程管理處理表測試部經(jīng)理組織書寫測試用例項目經(jīng)理（功能點(diǎn)文檔）東京整理匯總beta版后bug分析表項目經(jīng)理（提供的完整的B后障害書）所有管理者其中的技術(shù)分析和管理分析及對東京的建議應(yīng)由項目負(fù)責(zé)人進(jìn)行填寫控制測試的結(jié)果3.4 Bugsurvey工作流參見bu

12、gSurvey工作規(guī)約。3.5 項目分析工作流參見項目分析工作規(guī)約3.6 Beta后質(zhì)量保證工作流參見beta后規(guī)作規(guī)約3.7 測試組beta前工作流3.8 項目組基本工作流3.8.1 概述在項目進(jìn)行過程中，要求能夠及時反饋。做好計劃安排，并調(diào)整這個人力的配比，以達(dá)到最好的效果。3.8.2 對程序員的要求尤其在分析組成立前期，對分析組的設(shè)計書，盡可能提出建設(shè)性意見和設(shè)計的問題，有利于提高項目分析能力在功能實(shí)現(xiàn)上，主要和項目經(jīng)理的溝通，把類結(jié)構(gòu)設(shè)計和代碼向理想情況努力，同時用公司內(nèi)的代碼規(guī)范作為自己的行動準(zhǔn)則在日?；顒又?，加強(qiáng)團(tuán)體意識，加強(qiáng)責(zé)任感。3.8.3 對項目經(jīng)理的要求主要職責(zé)為：類設(shè)計的

13、嚴(yán)格控制。保證整個軟件包的可維護(hù)性項目過程管理。能夠緊密的控制整個項目的進(jìn)程，發(fā)現(xiàn)項目中的各種風(fēng)險因素，盡早地把風(fēng)險在項目中消除。硬性要求如下：(1) 每個項目(大于10MD正常項目)必須提供的文檔為功能點(diǎn)文檔，需求收集，單體測試用例，項目總結(jié)及MDM終分配方案文檔(2) 每個項目(大于10MDE常項目)必須召開兩次會議：項目啟動會議主要為了統(tǒng)一項目的內(nèi)容規(guī)則和要求，同時把整體邏輯和框架做簡要說明。項目總結(jié)會議：主要是評價每個成員的表現(xiàn)和項目完整的狀況和質(zhì)量，總結(jié)失敗的經(jīng)驗教訓(xùn)。同時根據(jù)評論的結(jié)果進(jìn)行最后的MD的分配。整個團(tuán)隊的建設(shè)和公司的管理工作。在項目管理中發(fā)現(xiàn)問題，把反映給公司。以備在公

14、司級別對整個流程和各個環(huán)節(jié)進(jìn)行調(diào)整。3.8.4 流程圖接收來自項目經(jīng)理的項目通知1、功能點(diǎn)文檔42、問卷.，功能點(diǎn)及問卷文檔名確認(rèn)及svn路徑3.8.5項目組文檔管理號郵件通知測試經(jīng)理，QA收到來自分析組概要設(shè)計第一版的通知對概要設(shè)計做初步；審核確定alfa 和beta版本郵件通知項目，經(jīng)理及測試負(fù)G責(zé)人：項目開始時間，alfa時間beta時間上傳項目開始時.間，alfa時間beta,時間計劃安排文檔接收來自分析組詳細(xì)設(shè)計第一版.結(jié)合項目情況進(jìn)行.計劃調(diào)整制作項目安排計劃表郵件給文檔作者，并通知項目組長和項目經(jīng)理項目中出現(xiàn)新問題開發(fā)組內(nèi)代碼檢查提交項目經(jīng)理書寫單元測試用例制作單元測試文檔單元測

15、試提交alfa版本/郵件通知測試.組長發(fā)送測試組計劃表上傳SVN上彳專SVN,路徑,名文檔名格式紿果反映到單元測4試用例文檔中并上.傳SVN原則:所有文檔必須都放在SVN上，進(jìn)行統(tǒng)一管理。同時，負(fù)責(zé)人在本地應(yīng)保留一份同樣的備份。細(xì)節(jié)描述（各路徑存放什么文件）項目內(nèi)容備注Spec設(shè)計說明書QuestionSheet設(shè)計說明書的補(bǔ)充說明設(shè)計說明書的各個版本設(shè)計說明書一覽表設(shè)計說明書一覽表要記錄所有文檔變更的情況，并指明最后項目實(shí)施與文檔之間的關(guān)系Testcase項目組書寫的單體測試用例測試組書寫的測試用例東京發(fā)送的confirm測試用例Schedule針對項目實(shí)施的日程安排對東京進(jìn)行進(jìn)度匯報的每個

16、報表FunctionPoints功能點(diǎn)文檔AllBugSpecBeta后障害書針對此項目的beta后bug類型確定和經(jīng)驗匯總。完畢后，應(yīng)及時發(fā)送測試組項目經(jīng)理。UIHtmlDemoHearingSheet聯(lián)系分析組，如果有應(yīng)該直接copyFPSpecFPsheet不同版本FPchange表FP說明，記錄所有FP變更歷史，以備后期確認(rèn)的方便。3.9 測試部3版前流程3.9.1 相關(guān)人員測試部經(jīng)理：XX測試組成員：3.9.2 測試人員的要求一定要注意配合。因為，在此環(huán)節(jié)，一種好的描述方式和溝通方式將會直接影響工作效率和工作質(zhì)量。所以，首先大家要注意bug管理系統(tǒng)的使用方法和規(guī)則，同時，盡量采用統(tǒng)一的屬于進(jìn)行描述，如果需要圖形輔助，也可以進(jìn)行貼圖。加強(qiáng)需求理解能力。能夠盡快的理解文檔和功能測試用例。在工作中細(xì)致、耐心、有條理。同時對應(yīng)esm系統(tǒng)需要測試部填寫的過程參數(shù)必須嚴(yán)格按照規(guī)定填寫。3.9.3 工作流程圖轉(zhuǎn)測條件通過后第一階段測試測試依據(jù)，規(guī)格說詈;明書，測試方案和 .'測試用例 /Bug單全部錄入即jira第一階段測試結(jié)束回歸測試1、檢查測試結(jié) 果是否錄入； 2、數(shù)據(jù)庫及 Resource 改動提交beta版本