手機項目管理規(guī)范流程

1、手機工程治理完整標(biāo)準(zhǔn)流程目 錄概述3工程流程把握3市場調(diào)研和工程定向 3采集用戶需求見用戶需求采集分析局部 3指定工程負(fù)責(zé)人 3合理組建需要的各個部門并指定負(fù)責(zé)人 3制定市場推廣打算3爭辯并確定技術(shù)方向，競爭對手資料收集4確定使用的平臺，語言和工具 4整理可用的資源 5爭辯相應(yīng)標(biāo)準(zhǔn)和標(biāo)準(zhǔn) 5比較競爭對手資料5記錄工程資料5制定開發(fā)里程碑和安排開發(fā)人員6選擇開發(fā)模型6安排開發(fā)人員6組織工程進度跟蹤小組PTT6指定易用性用戶友好性爭辯員 6用戶需求采集和分析 6采集用戶需求6需求變更把握7生成規(guī)格說明書 7概要設(shè)計和原型設(shè)計 8數(shù)據(jù)構(gòu)造，存儲設(shè)計 8功能具體設(shè)計8功能實現(xiàn)和功能測試 8集成測試和系

2、統(tǒng)測試 8產(chǎn)品相關(guān)宣傳和產(chǎn)品交付 9回歸測試和工程總結(jié) 9技術(shù)培訓(xùn)跟溝通 9附錄六 考評規(guī)章跟獎懲制度9附錄七 需求變更把握 10附錄八 進度拖延處理跟風(fēng)險躲避10附錄九 工程核心把握小組PTT 10概述針對手機工程，其開發(fā)，流程把握和系統(tǒng)分析做出的相應(yīng)工程治理標(biāo)準(zhǔn)。工程流程把握市場調(diào)研和工程定向采集用戶需求見用戶需求采集分析局部手機工程中由籌劃人員取代用戶提出需求，溝通相對便利但需求變更量相對增加。對于軟件方面考慮用戶日常工作中相對繁瑣和需要重復(fù)操作的步驟和易用性的爭辯進展整理和記錄。指定工程負(fù)責(zé)人工程負(fù)責(zé)人需要具備能夠預(yù)先覺察問題和解決問題的力量 力。合理組建需要的各個部門并指定負(fù)責(zé)人手機

3、工程對于部門劃分相對要求較少，但是對于每個環(huán)節(jié)指定相應(yīng)的負(fù)責(zé)人員是必要的。制定市場推廣打算提前設(shè)計廣告及宣傳，做針對工程特色跟潛在用戶的市場推廣打算。種形式。具體承受方式需要對投入，效果，活動規(guī)模等作出具體分析后打算。待增加依據(jù)產(chǎn)品特色和優(yōu)勢制定相應(yīng)的推廣方案，依據(jù)用戶特點制定相應(yīng)推廣形式。待增加媒體宣傳網(wǎng)絡(luò)宣傳與聯(lián)通移動合作SP 合作與手機開發(fā)商合作與高校合作市場本錢高低較高較低一般較低效果好一般好一般一般一般面對對象媒體用戶網(wǎng)絡(luò)用戶手機用戶SP 用戶手機用戶學(xué)生附加收獲與媒體建立與移動聯(lián)通建立寄售玩耍，聯(lián)系，知名宣傳通道合作雙贏知名度趣優(yōu)秀畢業(yè)度提升生Nokia 其運作模式跟部門有肯定了解

4、，可以依據(jù)需要選擇任何一方作為合作伙伴進展市場宣傳。另調(diào)研，玩耍開發(fā)大賽和玩耍大賽都是格外具有前景的。宣傳效果。另外對于開展形式和時機可以依據(jù)工程需要進展相應(yīng)調(diào)整。爭辯并確定技術(shù)方向，競爭對手資料收集確定使用的平臺，語言和工具 優(yōu)缺點并整理記錄到比照表中開發(fā)語言比照表KjavaUniJavaCC+待增加開發(fā)平臺Moto OSCDMA 1x, 2xNokia OSSymbian OS開發(fā)代價一般一般較低一般面對對象Moto聯(lián)通NokiaPalm運行效率一般一般一般快穩(wěn)定穩(wěn)定很穩(wěn)定很穩(wěn)定性度單項兼容計費接口MIDP 應(yīng)用單項兼容待增加承受的數(shù)據(jù)庫比較穩(wěn)定性主要考慮主流數(shù)據(jù)庫應(yīng)用存儲量不會很大，一般

5、使用rms。工程治理和質(zhì)量把握工具比較可以組合使用ProjectClearCaseBugzillaCVSClearQuest待增加工程規(guī)劃有有沒有沒有沒有工程進度把握有有沒有有沒有錯誤及修正記錄沒有有有有有準(zhǔn)時反響溝通沒有沒有有有有人員工作統(tǒng)計有有有有有其它優(yōu)點整體規(guī)劃流程把握錯誤處理版本把握錯誤處理待增加CVS 或者ClearCase，需要以較低本錢構(gòu)建具體工程體系時CVS Bugzilla 作為測試把握工具。在資金允許的狀況下，比較推舉使用IBM 的ClearCase 和ClearQuest 分推舉使用Project 做前期進度設(shè)計。的健全開發(fā)體系并盡可能的削減由于變更帶來的問題。 支持藍

6、牙功能還是 WAP 功能。對于單機玩耍，需要在圖像，操作和存儲方面分層進展處理并整理可用資源。整理可用的資源效率還能得到一些有益的閱歷?？赡苁褂矛F(xiàn)有模塊降低本錢削減錯誤的產(chǎn)生。爭辯相應(yīng)標(biāo)準(zhǔn)和標(biāo)準(zhǔn)符合更多通用的標(biāo)準(zhǔn)，這樣也有利于以后的產(chǎn)品宣傳和產(chǎn)品升級。比較競爭對手資料市場宣傳，功能點設(shè)計和市場推廣都將起到參考作用。記錄工程資料將依據(jù)上述資料爭辯確定工程使用的主要技術(shù) 記錄與競爭對手的比較資料和相關(guān)標(biāo)準(zhǔn)。制定開發(fā)里程碑和安排開發(fā)人員選擇開發(fā)模型依據(jù)工程工期、經(jīng)費和其它需要合理選擇搭配開發(fā)模型。制定開發(fā)模塊，功能點，實現(xiàn)周期。安排開發(fā)人員 肯定生疏，并收集各個部門的員工對工程的建議和意見。組織工程

7、進度跟蹤小組PTT過硬的人員擔(dān)當(dāng)。其中至少包括 30的參與人員，工程治理人員還需要指定一名易用性爭辯心設(shè)計人員跟核心測試，美術(shù)人員。的協(xié)商處理。指定易用性用戶友好性爭辯員的人員，該員工需要參與PTT 小組。用戶需求采集和分析采集用戶需求承受 SRS 模板、指明需求的來源、為每項需求注上標(biāo)號、記錄業(yè)務(wù)標(biāo)準(zhǔn)、創(chuàng)立需求跟蹤力量矩陣、審查需求文檔、以需求為依據(jù)編寫測試用例、編寫用戶手冊、確定合格的標(biāo)準(zhǔn)。模型。同時也明確了通過接口的信息流。創(chuàng)立用戶接口原型，當(dāng)開發(fā)人員或用戶不能確定需求時，開發(fā)一個用戶接口原型。用戶 通過評價原型將使工程參與者能更好地相互理解所要解決的問題型之間全部的沖突之處。分析需求可

8、行性，在允許的本錢、性能要求下，分析每項需求實施的可行性，明確與每項需求實現(xiàn)相聯(lián)系的風(fēng)險，包括與其它需求的沖突，對外界因素的依靠和技術(shù)障礙。確定需求的優(yōu)先級別，應(yīng)用分析方法來確定使用實例、產(chǎn)品特性或單項需求實現(xiàn)的優(yōu)先定的版本中參加每一項變更，參看需求變更。為需求建立模型，需求的圖形分析模型是軟件需求規(guī)格說明極好的補充說明。它們能供給包括數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。創(chuàng)立數(shù)據(jù)字典，數(shù)據(jù)字典是對系統(tǒng)用到的全部數(shù)據(jù)項和構(gòu)造的定義，以確保開發(fā)人員使 使用全都的定義和術(shù)語。分析和設(shè)計工具通常包括數(shù)據(jù)字典組件。使用質(zhì)量功能調(diào)配QF是一種高級系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對

9、客戶的重要性聯(lián)系起來。該技術(shù)供給了一種分析方法以明確那些是客戶最為關(guān)注的特性。QFD 將需求分為三類：期望需求，即客戶或許并未提及，但如假設(shè)缺少會讓他們感到不滿足；一般需求； 興奮需求，即實現(xiàn)了會給客戶帶去驚喜，但假設(shè)未實現(xiàn)也不會受到責(zé)備需求變更把握由于需求變更是全部工程中最為常見也是代價最高的局部，全部CMM2 級以上對需求變更做了具體規(guī)定。任何變更需要進展從功能測試，集成測試到系統(tǒng)測試的全面測試。對于每一次需求變更在工程中需要有具體記錄跟跟蹤，最終工程總結(jié)局部需要進展變更統(tǒng)計。需求變更具體規(guī)格詳見：需求變更把握標(biāo)準(zhǔn)。生成規(guī)格說明書 PTT 小組評審、確定設(shè)計方案，文檔記錄。之后假設(shè)對設(shè)計文

10、檔進展任何修改都需要經(jīng)過 PTT 小組的爭辯確定并具體記錄修改緣由、修改日期、修改人員等信息。具體規(guī)格說明書應(yīng)當(dāng)包括全部確定需要實現(xiàn)的用戶需求功能點 預(yù)定目標(biāo)。功能需求是否有相應(yīng)更改，具體見需求變更把握局部。概要設(shè)計和原型設(shè)計設(shè)計圖標(biāo)和用戶界面。進展概要設(shè)計、制作產(chǎn)品原型美工和設(shè)計部門參與，開發(fā)部門幫助用戶反響意見循環(huán)改進。數(shù)據(jù)構(gòu)造，存儲設(shè)計利用現(xiàn)有企業(yè)對數(shù)據(jù)構(gòu)造的具體標(biāo)準(zhǔn)要求進展設(shè)計 削減簡單度。數(shù)據(jù)存儲構(gòu)造需要依據(jù)實際狀況響應(yīng)制定。功能具體設(shè)計設(shè)計文檔，包含算法設(shè)計、流程設(shè)計和數(shù)據(jù)構(gòu)造設(shè)計。質(zhì)量把握部門對具體設(shè)計進展考核和修改，PTT 計文檔記錄，假設(shè)有任何改動需要經(jīng)過 PTT 小組爭辯打

11、算。具體設(shè)計文檔作為測試和質(zhì)量把握考核程序質(zhì)量的依據(jù)。功能實現(xiàn)和功能測試依據(jù)具體設(shè)計和代碼編寫標(biāo)準(zhǔn)完成代碼編寫工作，實現(xiàn)各個需求中描述的功能點。對每個功能點進展測試。對全部代碼做易用性、算法簡單度和標(biāo)準(zhǔn)檢查。完成代碼文檔的編寫。編寫用戶使用說明。工程改進小組對開發(fā)流程進展監(jiān)視和不斷改進。集成測試和系統(tǒng)測試由測試部門完成的集成跟系統(tǒng)測試需要在測試環(huán)境中進展將系統(tǒng)集成，對系統(tǒng)進展硬件、軟件、壓力測試，對客戶端進展不同使用平臺，不同軟件版本的測試。利用錯誤把握工具記錄和修改錯誤。模擬用戶環(huán)境進展完整流程測試，邀請局部用戶或者潛在用戶參與beta 版本的測試。 沒有關(guān)閉的錯誤，保證代碼出錯率低于肯定比

12、率。對于出產(chǎn)產(chǎn)品出錯率嚴(yán)格限制。產(chǎn)品相關(guān)宣傳和產(chǎn)品交付依據(jù)產(chǎn)品特點和工程啟動時所制定的打算進展產(chǎn)品宣傳和產(chǎn)品說明。公布相關(guān)產(chǎn)品專利和印刷產(chǎn)品。將產(chǎn)品交付用戶。回歸測試和工程總結(jié)進展回歸測試、迭代測試和相關(guān)產(chǎn)品升級。的大事和緣由PTT 小組進展分析和統(tǒng)計，記錄并為以后工程供給閱歷。技術(shù)培訓(xùn)跟溝通工程進展過程中要做到各個部門各個模塊的充分溝通和溝通造車，缺乏溝通對于一個健全工程而言無疑是一種潛在的風(fēng)險。工程負(fù)責(zé)人需要依據(jù)實際狀況安排技術(shù)比較過硬的人員針對各個部門技術(shù)算法難點 個工程的進程和技術(shù)實現(xiàn)比較了解。對于培訓(xùn)人員進展業(yè)績記錄跟考評關(guān)聯(lián)以提高大家的參與熱忱員賜予表揚。工程每天的進度，而且依據(jù)狀

13、況要預(yù)知風(fēng)險并進展躲避。附錄六 考評規(guī)章跟獎懲制度一、 程序人員考評規(guī)章程序員依據(jù)其代碼數(shù)量，質(zhì)量，錯誤率，效率，業(yè)績，特別算法，溝通等進展每月考評，年度考評依據(jù)技術(shù)水平跟業(yè)績表現(xiàn)做整體考評。詳情參見開發(fā)人員考評指標(biāo)。二、 測試人員考評規(guī)章評那個依據(jù)技術(shù)水平跟業(yè)績表現(xiàn)做整體考評。詳情參見測試人員考評指標(biāo)。三、 其他相關(guān)人員考評規(guī)章反響準(zhǔn)時度進展考評。標(biāo)參看工程文檔標(biāo)準(zhǔn)。附錄七 需求變更把握由于需求變更是全部工程中最為常見也是代價最高的局部，全部CMM2 級以上對需求變更做了具體規(guī)定。任何變更需要進展從功能測試，集成測試到系統(tǒng)測試的全面測試。對于每一次需求變更在工程中需要有具體記錄跟跟蹤，最終工程總結(jié)局部需要進展變更統(tǒng)計。需求變更具體規(guī)格見需求變更把握文檔。附錄八 進度拖延處理跟風(fēng)險躲避 需要預(yù)先設(shè)立解決方案準(zhǔn)時啟動后備方案來解決當(dāng)前的拖延問題。工程設(shè)計過程中對于時間安排要依據(jù)實際狀況開發(fā)人員，測試人員，設(shè)計人員依據(jù)閱歷對功能實現(xiàn)預(yù)期的實現(xiàn)時間增加 30的充裕時間量作為緊急處理時間。對于無法依據(jù)規(guī)定實現(xiàn)的工程應(yīng)當(dāng)削減可能的功能，決不能削減測試時間來到達完成期限。對于需求變更詳見需求變更把握局部。盡可能不改動需求，對于任何改動所需要增加的代價必需有完備的評估。技術(shù)實現(xiàn)拖延，由于技術(shù)問題所產(chǎn)生的拖延可以考慮用其他技術(shù)取