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

1、 手機項目管理完整規(guī)范流程1       概述針對手機項目，其開發(fā)，流程控制和系統(tǒng)分析做出的相應項目管理規(guī)范。2       項目流程控制2.1    市場調研和項目定向   采集用戶需求（見用戶需求采集分析部分）手機項目中由策劃人員取代用戶提出需求，交流相對方便但需求變更量相對增加。對于軟件方面考慮用戶日常工作中相對繁瑣和需要重復操作的步驟，對可以實現(xiàn)的用戶需求和易用性的研究進行整理和記錄。  

2、 指定項目負責人給項目指定一個總負責人來對項目開發(fā)、經(jīng)費控制、人員管理、進度掌握、質量控制等負責。項目負責人需要具備能夠預先發(fā)現(xiàn)問題和解決問題的能力、能夠團結和發(fā)揮項目中每個人的能力、能夠很好的規(guī)劃和控制進度進行的能力和能夠對項目的質量進行嚴格控制和評估的能力。   合理組建需要的各個部門并指定負責人手機項目對于部門劃分相對要求較少，但是對于每個環(huán)節(jié)指定相應的負責人員是必要的。   制定市場推廣計劃提前設計廣告及宣傳，做針對項目特色跟潛在用戶的市場推廣計劃?？梢圆捎么笮突顒樱c其他相關企業(yè)合作舉辦活動，在網(wǎng)絡論壇上組織活動和媒體宣傳等多種形式。具體采用方

3、式需要對投入，效果，活動規(guī)模等作出詳細分析后決定。根據(jù)產(chǎn)品特色和優(yōu)勢制定相應的推廣方案，根據(jù)用戶特點制定相應推廣形式。 媒體宣傳網(wǎng)絡宣傳與聯(lián)通移動合作與SP合作與手機開發(fā)商合作與高校合作市場成本高低較高較低一般較低效果好一般好一般一般一般面向對象媒體用戶網(wǎng)絡用戶手機用戶SP用戶手機用戶學生附加收獲與媒體建立聯(lián)系，知名度提升打開網(wǎng)絡宣傳通道與移動聯(lián)通建立聯(lián)系，知名度提高寄售游戲，合作雙贏建立合作關系，提高知名度尋找，培養(yǎng)興趣優(yōu)秀畢業(yè)生待增加      對于市場推廣部分，由于曾經(jīng)在中國移動經(jīng)歷了移動跟Nokia合作舉辦的手機程序

4、大賽，對于其運作模式跟部門有一定了解，可以根據(jù)需要選擇任何一方作為合作伙伴進行市場宣傳。另外，大學校園是成本非常低的活動基地，同時可以尋找培養(yǎng)優(yōu)秀人才加盟。舉辦適當新產(chǎn)品調研，游戲開發(fā)大賽和游戲大賽都是非常具有前景的。以上所有形式可以根據(jù)現(xiàn)有資金，市場需要進行搭配組合，可以同時啟動以達到更好的市場宣傳效果。另外對于開展形式和時機可以根據(jù)項目需要進行相應調整。2.2    研究并確定技術方向，競爭對手資料收集   確定使用的平臺，語言和工具研究當前的新技術和開發(fā)語言、項目管理工具、版本質量控制工具，比較各種語言和工具的優(yōu)缺點并整理記錄到對比表中，

5、根據(jù)項目特點、人員和要求選擇適合的開發(fā)工具和管理工具。開發(fā)語言對比表 KjavaUniJavaCC+待增加開發(fā)平臺Moto OSCDMA 1x, 2xNokia OSSymbian OS 開發(fā)代價一般一般較低一般 面向對象Moto聯(lián)通NokiaPalm 運行效率一般一般一般快 運行穩(wěn)定性穩(wěn)定穩(wěn)定很穩(wěn)定很穩(wěn)定 其它復雜度單項兼容計費接口MIDP應用單項兼容 待增加     采用的數(shù)據(jù)庫比較（穩(wěn)定性主要考慮主流數(shù)據(jù)庫應用）：手機數(shù)據(jù)庫不同于一般數(shù)據(jù)庫，其存儲量不會很大，一般使用r

6、ms。項目管理和質量控制工具比較（可以組合使用） ProjectClearCaseBugzillaCVSClearQuest待增加項目規(guī)劃有有沒有沒有沒有 項目進度把握有有沒有有沒有 錯誤及修正記錄沒有有有有有 及時反饋交流沒有沒有有有有 人員工作統(tǒng)計有有有有有 其它優(yōu)點整體規(guī)劃流程控制錯誤處理版本控制錯誤處理 待增加      代碼和版本控制工具：目前使用CVS或者ClearCase，需要以較低成本構建詳細項目體系時推薦使用CVS作為版本控制，加入Bugzilla

7、作為測試控制工具。在資金允許的情況下，比較推薦使用IBM的ClearCase和ClearQuest建立整個項目控制管理體系。項目規(guī)劃和進度劃分推薦使用Project做前期進度設計。對于已經(jīng)進行的項目或者發(fā)展中公司，針對現(xiàn)有資源，代碼進行整合的時候應盡可能的減少改動，因地制宜的設定規(guī)范跟質量管理體系，使已經(jīng)適應當前開發(fā)模式的人員可以盡快適應新的健全開發(fā)體系并盡可能的減少由于變更帶來的問題。根據(jù)手機游戲開發(fā)的特點，需要確定該項目是支持網(wǎng)絡功能還是單機游戲。對于網(wǎng)絡又分為支持藍牙功能還是WAP功能。對于單機游戲，需要在圖像，操作和存儲方面分層進行處理并整理可用資源。   整理可用

8、的資源利用所有可用的資源以提高開發(fā)的進度，整理現(xiàn)有可用的資源和代碼，并且查找相關的共享源碼和資源。將所有現(xiàn)有資源整理并找出可用的部分加以利用，這樣不但能夠有效提高開發(fā)效率還能得到一些有益的經(jīng)驗。例如增加模塊數(shù)據(jù)庫管理現(xiàn)有引擎，復雜算法，封裝好的模塊以便隨時去用，開發(fā)過程中盡可能使用現(xiàn)有模塊降低成本減少錯誤的產(chǎn)生。   研究相應規(guī)范和標準研究當前領域內的國際和國內可能使用到的規(guī)范和標準，整理并翻譯相應規(guī)范。盡量使產(chǎn)品符合更多通用的規(guī)范，這樣也有利于以后的產(chǎn)品宣傳和產(chǎn)品升級。   比較競爭對手資料收集領域內其它競爭對手的產(chǎn)品，總結出其優(yōu)越性和特點。結合自身情

9、況考慮實現(xiàn)代價取舍其中的功能點并增加自己的特色。需要專人負責整理所有比較數(shù)據(jù)記錄進項目文檔中，對于市場宣傳，功能點設計和市場推廣都將起到參考作用。   記錄項目資料將根據(jù)上述資料討論確定項目使用的主要技術、平臺、開發(fā)工具和項目管理工具等整理記錄，記錄與競爭對手的比較資料和相關規(guī)范。2.3    制定開發(fā)里程碑和安排開發(fā)人員   選擇開發(fā)模型根據(jù)項目工期、經(jīng)費和其它需要合理選擇搭配開發(fā)模型。制定開發(fā)模塊，功能點，實現(xiàn)周期。   安排開發(fā)人員根據(jù)需要安排開發(fā)人員，記錄項目需要的總人員、各個部門指定的針對項目的

10、人員，估算每個人的工作量和時間安排。給每個人員進行相應的項目培訓使所有參與項目的人員對項目有一定認識，并收集各個部門的員工對項目的建議和意見。   組織項目進度跟蹤小組PTT項目核心控制小組由項目管理人員從開發(fā)部門，設計部門，測試部門，美術部門中指定技術過硬的人員擔任。其中至少包括30的參與人員，項目管理人員還需要指定一名易用性研究員做項目各個階段的用戶友好性評估跟修訂。參與核心小組的是項目中的核心程序員，核心設計人員跟核心測試，美術人員。項目核心控制小組的主要作用是隨時監(jiān)控項目進度，增強各個部門對于項目進度的把握，風險預測跟規(guī)避，項目拖延處理機制，項目里程碑控制，技術討論

11、培訓管理跟項目中所有問題的協(xié)商處理。   指定易用性（用戶友好性）研究員指定一個易用性研究員，負責研究市場上同類產(chǎn)品的易用性優(yōu)缺點，控制每個步驟的易用性檢查工作并對產(chǎn)品提出相應的改進意見和建議，確保產(chǎn)品的易用性。需要有一定積極性和創(chuàng)造性并熟悉用戶需要從用戶角度考慮問題的人員擔任，可以是售前、產(chǎn)品設計或者開發(fā)部門的人員，該員工需要參加PTT小組。2.4    用戶需求采集和分析   采集用戶需求采用SRS模板、指明需求的來源、為每項需求注上標號、記錄業(yè)務規(guī)范、創(chuàng)建需求跟蹤能力矩陣、審查需求文檔、以需求為依據(jù)編寫測試用例、編寫用

12、戶手冊、確定合格的標準。1. 繪制系統(tǒng)關聯(lián)圖，這種關聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的簡單模型。同時也明確了通過接口的信息流。 2. 創(chuàng)建用戶接口原型，當開發(fā)人員或用戶不能確定需求時，開發(fā)一個用戶接口原型。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間所有的沖突之處。3. 分析需求可行性，在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現(xiàn)相聯(lián)系的風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。 4. 確定需求的優(yōu)先級別，應用分析方法來確定使用實例、產(chǎn)品特性或單項需求實現(xiàn)的優(yōu)先級別。以優(yōu)先級為基礎確定產(chǎn)品版本將

13、包括哪些特性或哪類需求。當允許需求變更時，在特定的版本中加入每一項變更，參看需求變更。 5. 為需求建立模型，需求的圖形分析模型是軟件需求規(guī)格說明極好的補充說明。它們能提供不同的信息與關系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實體關系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。 6. 創(chuàng)建數(shù)據(jù)字典，數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結構的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應定義客戶數(shù)據(jù)項以確保客戶與開發(fā)小組是使用一致的定義和術語。分析和設計工具通常包括數(shù)據(jù)字典組件。 7. 使用質量功能調配，（QFD）是一種高級系統(tǒng)技術，它將

14、產(chǎn)品特性、屬性與對客戶的重要性聯(lián)系起來。該技術提供了一種分析方法以明確那些是客戶最為關注的特性。QFD將需求分為三類：期望需求，即客戶或許并未提及，但如若缺少會讓他們感到不滿意；普通需求；興奮需求，即實現(xiàn)了會給客戶帶去驚喜，但若未實現(xiàn)也不會受到責備   需求變更控制由于需求變更是所有項目中最為常見也是代價最高的部分，所有CMM2級以上對需求變更做了詳細規(guī)定。我們在處理需求變更時，對于必須變更的需求，經(jīng)過項目核心小組討論決定后與用戶就詳細變更要求，所需要付出的時間或者資金代價進行協(xié)商，達成一致后在詳細規(guī)格說明書中由設計部門進行整體設計并考察其可能影響的模塊變更。開發(fā)部門根據(jù)設

15、計做相應的更改，對于任何變更需要進行從功能測試，集成測試到系統(tǒng)測試的全面測試。對于每一次需求變更在項目中需要有詳細記錄跟跟蹤，最后項目總結部分需要進行變更統(tǒng)計。需求變更詳細規(guī)格詳見：需求變更控制規(guī)范。   生成規(guī)格說明書最后生成一份項目中最完整的規(guī)格說明書，為設計、開發(fā)、測試提供參考并最終從中抽取出用戶使用說明書和其它終端文檔。PTT小組評審、確定設計方案，文檔記錄。之后如果對設計文檔進行任何修改都需要經(jīng)過PTT小組的討論確定并詳細記錄修改原因、修改日期、修改人員等信息。詳細規(guī)格說明書應該包括所有確定需要實現(xiàn)的用戶需求功能點，其分配人員，預定完成時間，工作量，風險評估，里程

16、碑設定。針對每一個功能點需要有負責人，每周查看進度是否符合預定目標。功能需求是否有相應更改，詳細見需求變更控制部分。2.5    概要設計和原型設計設計圖標和用戶界面。進行概要設計、制作產(chǎn)品原型（美工和設計部門參與，開發(fā)部門協(xié)助），提供給用戶并收集用戶反饋意見循環(huán)改進。2.6    數(shù)據(jù)結構，存儲設計利用現(xiàn)有企業(yè)對數(shù)據(jù)結構的詳細規(guī)范要求進行設計。盡量精簡數(shù)據(jù)結構，做到合理邏輯關聯(lián)，減少復雜度。數(shù)據(jù)存儲結構需要根據(jù)實際情況響應制定。2.7    功能詳細設計由開發(fā)部門完成的詳細設計包括了對功能點的詳細理解，

17、算法設計，數(shù)據(jù)結構設計跟功能詳細流程圖。所有部分應嚴格符合開發(fā)規(guī)范跟文檔規(guī)范的要求。按照統(tǒng)一的文檔規(guī)范編寫詳細設計文檔，包含算法設計、流程設計和數(shù)據(jù)結構設計。質量控制部門對詳細設計進行考核和修改，PTT小組對詳細設計進行評審。確定之后詳細設計文檔記錄，如果有任何改動需要經(jīng)過PTT小組討論決定。詳細設計文檔作為測試和質量控制考核程序質量的依據(jù)。2.8    功能實現(xiàn)和功能測試根據(jù)詳細設計和代碼編寫規(guī)范完成代碼編寫工作，實現(xiàn)各個需求中描述的功能點。對每個功能點進行測試。對所有代碼做易用性、算法復雜度和規(guī)范檢查。完成代碼文檔的編寫。編寫用戶使用說明。項目改進小組對開發(fā)流

18、程進行監(jiān)督和不斷改進。2.9    集成測試和系統(tǒng)測試由測試部門完成的集成跟系統(tǒng)測試需要在測試環(huán)境中進行。將相關功能點聯(lián)調，測試并修改。將系統(tǒng)集成，對系統(tǒng)進行硬件、軟件、壓力測試，對客戶端進行不同使用平臺，不同軟件版本的測試。利用錯誤控制工具記錄和修改錯誤。模擬用戶環(huán)境進行完整流程測試，邀請部分用戶或者潛在用戶參與beta版本的測試。對于所產(chǎn)生的錯誤進行等級劃分跟記錄，每周對于所有錯誤進行項目跟蹤，如果優(yōu)先級較高可以臨時組織會議討論處理。所有錯誤由項目管理或者開發(fā)負責人制定專人負責并隨時跟蹤沒有關閉的錯誤，保證代碼出錯率低于一定比率。對于出產(chǎn)產(chǎn)品出錯率嚴格限制。2

19、.10       產(chǎn)品相關宣傳和產(chǎn)品交付根據(jù)產(chǎn)品特點和項目啟動時所制定的計劃進行產(chǎn)品宣傳和產(chǎn)品說明。發(fā)布相關產(chǎn)品專利和印刷產(chǎn)品。將產(chǎn)品交付用戶。2.11       回歸測試和項目總結進行回歸測試、迭代測試和相關產(chǎn)品升級。對項目進行總結，記錄項目中所有可以重復利用的資源和經(jīng)驗，對一些對項目進度造成影響的事件和原因PTT小組進行分析和統(tǒng)計，記錄并為以后項目提供經(jīng)驗。2.12       技術培訓跟溝通項目進行過程中要

20、做到各個部門各個模塊的充分交流和溝通，最忌諱的就是消息封閉和閉門造車，缺乏交流對于一個健全項目而言無疑是一種潛在的風險。項目負責人需要根據(jù)實際情況安排技術比較過硬的人員針對各個部門技術算法難點，流程設計，接口設計等進行技術培訓，其他部門的人員根據(jù)實際情況參加培訓提出疑問。項目剛開始進行的時候以總體流程為主要培訓主題，隨著項目的進行，逐漸引入美術設計，模塊劃分，數(shù)據(jù)結構設計，算法實現(xiàn)，質量控制等方面的主題，確保一個項目中每個部門都有人對于整個項目的進程和技術實現(xiàn)比較了解。對于培訓人員進行業(yè)績記錄跟考評關聯(lián)以提高大家的參與熱情。對于培訓起到重要作用的人員給予表揚。項目管理人員在項目進行中要起到橋梁

21、的作用，隨時跟各個部門的人員進行溝通，不但要掌握項目每天的進度，而且根據(jù)情況要預知風險并進行規(guī)避。 附錄六 考評規(guī)則跟獎懲制度一、程序人員考評規(guī)則程序員根據(jù)其代碼數(shù)量，質量，錯誤率，效率，業(yè)績，特別算法，溝通等進行每月考評，年度考評根據(jù)技術水平跟業(yè)績表現(xiàn)做整體考評。詳情參見開發(fā)人員考評指標。二、測試人員考評規(guī)則測試人員根據(jù)其發(fā)現(xiàn)的錯誤數(shù)量，級別，業(yè)績，溝通交流跟業(yè)務水平進行每月考評，年度考評那個根據(jù)技術水平跟業(yè)績表現(xiàn)做整體考評。詳情參見測試人員考評指標。三、其他相關人員考評規(guī)則銷售人員有銷售部門制定詳細業(yè)績考核標準進行考評，美術部門根據(jù)其工作量跟質量，工作反應及時度進行考評。項目整體

22、考評根據(jù)項目進度，階段進度，完成質量，用戶反映等做出綜合評價，詳細考評指標參看項目文檔規(guī)范。附錄七 需求變更控制由于需求變更是所有項目中最為常見也是代價最高的部分，所有CMM2級以上對需求變更做了詳細規(guī)定。我們在處理需求變更時，對于必須變更的需求，經(jīng)過項目核心小組討論決定后與用戶就詳細變更要求，所需要付出的時間或者資金代價進行協(xié)商，達成一致后在詳細規(guī)格說明書中由設計部門進行整體設計并考察其可能影響的模塊變更。開發(fā)部門根據(jù)設計做相應的更改，對于任何變更需要進行從功能測試，集成測試到系統(tǒng)測試的全面測試。對于每一次需求變更在項目中需要有詳細記錄跟跟蹤，最后項目總結部分需要進行變更統(tǒng)計。需求變更詳細規(guī)格見需求變更控制文檔。附錄八 進度拖延處理跟風險規(guī)避由于需求變更，技術實現(xiàn)，個人原因導致項目進度拖延的情況存在于每個項目之中。作為項目負責人，需要能夠提前預知可能產(chǎn)生拖延的原因進行風險規(guī)避。在已經(jīng)產(chǎn)生拖延的情況下，需要預先設立解決方案及時啟動后備方案來解決當前的拖延問題。1            項目設計過程中對于時間安排要根據(jù)實際情況（開發(fā)人員，測試人員，設計人員根據(jù)經(jīng)驗對功能實現(xiàn)預期的