流程管理手机项目管理完整规范流程.docx
《流程管理手机项目管理完整规范流程.docx》由会员分享，可在线阅读，更多相关《流程管理手机项目管理完整规范流程.docx（12页珍藏版）》请在冰点文库上搜索。
流程管理手机项目管理完整规范流程
（流程管理）手机项目管理完整规范流程
手机项目管理完整规范流程
1概述
针对手机项目，其开发，流程控制和系统分析做出的相应项目管理规范。
2项目流程控制
2.1市场调研和项目定向
2.1.1采集用户需求（见用户需求采集分析部分）
手机项目中由策划人员取代用户提出需求，交流相对方便但需求变更量相对增加。
对于软件方面考虑用户日常工作中相对繁琐和需要重复操作的步骤，对能够实现的用户需求和易用性的研究进行整理和记录。
2.1.2指定项目负责人
给项目指定壹个总负责人来对项目开发、经费控制、人员管理、进度掌握、质量控制等负责。
项目负责人需要具备能够预先发现问题和解决问题的能力、能够团结和发挥项目中每个人的能力、能够很好的规划和控制进度进行的能力和能够对项目的质量进行严格控制和评估的能力。
2.1.3合理组建需要的各个部门且指定负责人
手机项目对于部门划分相对要求较少，可是对于每个环节指定相应的负责人员是必要的。
2.1.4制定市场推广计划
提前设计广告及宣传，做针对项目特色跟潜于用户的市场推广计划。
能够采用大型活动，和其他关联企业合作举办活动，于网络论坛上组织活动和媒体宣传等多种形式。
具体采用方式需要对投入，效果，活动规模等作出详细分析后决定。
根据产品特色和优势制定相应的推广方案，根据用户特点制定相应推广形式。
媒体宣传
网络宣传
和联通移动合作
和SP合作
和手机开发商合作
和高校合作
市场成本
高
低
较高
较低
壹般
较低
效果
好
壹般
好
壹般
壹般
壹般
面向对象
媒体用户
网络用户
手机用户
SP用户
手机用户
学生
附加收获
和媒体建立联系，知名度提升
打开网络宣传通道
和移动联通建立联系，知名度提高
寄售游戏，合作双赢
建立合作关系，提高知名度
寻找，培养兴趣优秀毕业生
待增加
对于市场推广部分，由于曾经于中国移动经历了移动跟Nokia合作举办的手机程序大赛，对于其运作模式跟部门有壹定了解，能够根据需要选择任何壹方作为合作伙伴进行市场宣传。
另外，大学校园是成本非常低的活动基地，同时能够寻找培养优秀人才加盟。
举办适当新产品调研，游戏开发大赛和游戏大赛均是非常具有前景的。
之上所有形式能够根据现有资金，市场需要进行搭配组合，能够同时启动以达到更好的市场宣传效果。
另外对于开展形式和时机能够根据项目需要进行相应调整。
2.2研究且确定技术方向，竞争对手资料收集
2.2.1确定使用的平台，语言和工具
研究当前的新技术和开发语言、项目管理工具、版本质量控制工具，比较各种语言和工具的优缺点且整理记录到对比表中，根据项目特点、人员和要求选择适合的开发工具和管理工具。
开发语言对比表
Kjava
Uni
Java
C\C++
待增加
开发平台
MotoOS
CDMA1x,2x
NokiaOS
SymbianOS
开发代价
壹般
壹般
较低
壹般
面向对象
Moto
联通
Nokia
Palm
运行效率
壹般
壹般
壹般
快
运行稳定性
稳定
稳定
很稳定
很稳定
其它复杂度
单项兼容
计费接口
MIDP应用
单项兼容
待增加
采用的数据库比较（稳定性主要考虑主流数据库应用）：
手机数据库不同于壹般数据库，其存储量不会很大，壹般使用rms。
项目管理和质量控制工具比较（能够组合使用）
Project
ClearCase
Bugzilla
CVS
ClearQuest
待增加
项目规划
有
有
没有
没有
没有
项目进度把握
有
有
没有
有
没有
错误及修正记录
没有
有
有
有
有
及时反馈交流
没有
没有
有
有
有
人员工作统计
有
有
有
有
有
其它优点
整体规划
流程控制
错误处理
版本控制
错误处理
待增加
代码和版本控制工具：
目前使用CVS或者ClearCase，需要以较低成本构建详细项目体系时推荐使用CVS作为版本控制，加入Bugzilla作为测试控制工具。
于资金允许的情况下，比较推荐使用IBM的ClearCase和ClearQuest建立整个项目控制管理体系。
项目规划和进度划分推荐使用Project做前期进度设计。
对于已经进行的项目或者发展中公司，针对现有资源，代码进行整合的时候应尽可能的减少改动，因地制宜的设定规范跟质量管理体系，使已经适应当前开发模式的人员能够尽快适应新的健全开发体系且尽可能的减少由于变更带来的问题。
根据手机游戏开发的特点，需要确定该项目是支持网络功能仍是单机游戏。
对于网络又分为支持蓝牙功能仍是WAP功能。
对于单机游戏，需要于图像，操作和存储方面分层进行处理且整理可用资源。
2.2.2整理可用的资源
利用所有可用的资源以提高开发的进度，整理现有可用的资源和代码，且且查找关联的共享源码和资源。
将所有现有资源整理且找出可用的部分加以利用，这样不但能够有效提高开发效率仍能得到壹些有益的经验。
例如增加模块数据库管理现有引擎，复杂算法，封装好的模块以便随时去用，开发过程中尽可能使用现有模块降低成本减少错误的产生。
2.2.3研究相应规范和标准
研究当前领域内的国际和国内可能使用到的规范和标准，整理且翻译相应规范。
尽量使产品符合更多通用的规范，这样也有利于以后的产品宣传和产品升级。
2.2.4比较竞争对手资料
收集领域内其它竞争对手的产品，总结出其优越性和特点。
结合自身情况考虑实现代价取舍其中的功能点且增加自己的特色。
需要专人负责整理所有比较数据记录进项目文档中，对于市场宣传，功能点设计和市场推广均将起到参考作用。
2.2.5记录项目资料
将根据上述资料讨论确定项目使用的主要技术、平台、开发工具和项目管理工具等整理记录，记录和竞争对手的比较资料和关联规范。
2.3制定开发里程碑和安排开发人员
2.3.1选择开发模型
根据项目工期、经费和其它需要合理选择搭配开发模型。
制定开发模块，功能点，实现周期。
2.3.2安排开发人员
根据需要安排开发人员，记录项目需要的总人员、各个部门指定的针对项目的人员，估算每个人的工作量和时间安排。
给每个人员进行相应的项目培训使所有参和项目的人员对项目有壹定认识，且收集各个部门的员工对项目的建议和意见。
2.3.3组织项目进度跟踪小组PTT
项目核心控制小组由项目管理人员从开发部门，设计部门，测试部门，美术部门中指定技术过硬的人员担任。
其中至少包括30％的参和人员，项目管理人员仍需要指定壹名易用性研究员做项目各个阶段的用户友好性评估跟修订。
参和核心小组的是项目中的核心程序员，核心设计人员跟核心测试，美术人员。
项目核心控制小组的主要作用是随时监控项目进度，增强各个部门对于项目进度的把握，风险预测跟规避，项目拖延处理机制，项目里程碑控制，技术讨论培训管理跟项目中所有问题的协商处理。
2.3.4指定易用性（用户友好性）研究员
指定壹个易用性研究员，负责研究市场上同类产品的易用性优缺点，控制每个步骤的易用性检查工作且对产品提出相应的改进意见和建议，确保产品的易用性。
需要有壹定积极性和创造性且熟悉用户需要从用户角度考虑问题的人员担任，能够是售前、产品设计或者开发部门的人员，该员工需要参加PTT小组。
2.4用户需求采集和分析
2.4.1采集用户需求
采用SRS模板、指明需求的来源、为每项需求注上标号、记录业务规范、创建需求跟踪能力矩阵、审查需求文档、以需求为依据编写测试用例、编写用户手册、确定合格的标准。
1.绘制系统关联图，这种关联图是用于定义系统和系统外部实体间的界限和接口的简单模型。
同时也明确了通过接口的信息流。
2.创建用户接口原型，当开发人员或用户不能确定需求时，开发壹个用户接口原型。
用户通过评价原型将使项目参和者能更好地相互理解所要解决的问题。
注意要找出需求文档和原型之间所有的冲突之处。
3.分析需求可行性，于允许的成本、性能要求下，分析每项需求实施的可行性，明确和每项需求实现相联系的风险，包括和其它需求的冲突，对外界因素的依赖和技术障碍。
4.确定需求的优先级别，应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。
以优先级为基础确定产品版本将包括哪些特性或哪类需求。
当允许需求变更时，于特定的版本中加入每壹项变更，参见需求变更。
5.为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。
它们能提供不同的信息和关系以有助于找到不正确的、不壹致的、遗漏的和冗余的需求。
这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
6.创建数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统壹的数据定义。
于需求阶段，数据字典至少应定义客户数据项以确保客户和开发小组是使用壹致的定义和术语。
分析和设计工具通常包括数据字典组件。
7.使用质量功能调配，（QFD）是壹种高级系统技术，它将产品特性、属性和对客户的重要性联系起来。
该技术提供了壹种分析方法以明确那些是客户最为关注的特性。
QFD将需求分为三类：
期望需求，即客户或许且未提及，但如若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备
2.4.2需求变更控制
由于需求变更是所有项目中最为常见也是代价最高的部分，所有CMM2级之上对需求变更做了详细规定。
我们于处理需求变更时，对于必须变更的需求，经过项目核心小组讨论决定后和用户就详细变更要求，所需要付出的时间或者资金代价进行协商，达成壹致后于详细规格说明书中由设计部门进行整体设计且考察其可能影响的模块变更。
开发部门根据设计做相应的更改，对于任何变更需要进行从功能测试，集成测试到系统测试的全面测试。
对于每壹次需求变更于项目中需要有详细记录跟跟踪，最后项目总结部分需要进行变更统计。
需求变更详细规格详见：
需求变更控制规范。
2.4.3生成规格说明书
最后生成壹份项目中最完整的规格说明书，为设计、开发、测试提供参考且最终从中抽取出用户使用说明书和其它终端文档。
PTT小组评审、确定设计方案，文档记录。
之后如果对设计文档进行任何修改均需要经过PTT小组的讨论确定且详细记录修改原因、修改日期、修改人员等信息。
详细规格说明书应该包括所有确定需要实现的用户需求功能点，其分配人员，预定完成时间，工作量，风险评估，里程碑设定。
针对每壹个功能点需要有负责人，每周查见进度是否符合预定目标。
功能需求是否有相应更改，详细见需求变更控制部分。
2.5概要设计和原型设计
设计图标和用户界面。
进行概要设计、制作产品原型（美工和设计部门参和，开发部门协助），提供给用户且收集用户反馈意见循环改进。
2.6数据结构，存储设计
利用现有企业对数据结构的详细规范要求进行设计。
尽量精简数据结构，做到合理逻辑关联，减少复杂度。
数据存储结构需要根据实际情况响应制定。
2.7功能详细设计
由开发部门完成的详细设计包括了对功能点的详细理解，算法设计，数据结构设计跟功能详细流程图。
所有部分应严格符合开发规范跟文档规范的要求。
按照统壹的文档规范编写详细设计文档，包含算法设计、流程设计和数据结构设计。
质量控制部门对详细设计进行考核和修改，PTT小组对详细设计进行评审。
确定之后详细设计文档记录，如果有任何改动需要经过PTT小组讨论决定。
详细设计文档作为测试和质量控制考核程序质量的依据。
2.8功能实现和功能测试
根据详细设计和代码编写规范完成代码编写工作，实现各个需求中描述的功能点。
对每个功能点进行测试。
对所有代码做易用性、算法复杂度和规范检查。
完成代码文档的编写。
编写用户使用说明。
项目改进小组对开发流程进行监督和不断改进。
2.9集成测试和系统测试
由测试部门完成的集成跟系统测试需要于测试环境中进行。
将关联功能点联调，测试且修改。
将系统集成，对系统进行硬件、软件、压力测试，对客户端进行不同使用平台，不同软件版本的测试。
利用错误控制工具记录和修改错误。
模拟用户环境进行完整流程测试，邀请部分用户或者潜于用户参和beta版本的测试。
对于所产生的错误进行等级划分跟记录，每周对于所有错误进行项目跟踪，如果优先级较高能够临时组织会议讨论处理。
所有错误由项目管理或者开发负责人制定专人负责且随时跟踪没有关闭的错误，保证代码出错率低于壹定比率。
对于出产产品出错率严格限制。
2.10产品关联宣传和产品交付
根据产品特点和项目启动时所制定的计划进行产品宣传和产品说明。
发布关联产品专利和印刷产品。
将产品交付用户。
2.11回归测试和项目总结
进行回归测试、迭代测试和关联产品升级。
对项目进行总结，记录项目中所有能够重复利用的资源和经验，对壹些对项目进度造成影响的事件和原因PTT小组进行分析和统计，记录且为以后项目提供经验。
2.12技术培训跟沟通
项目进行过程中要做到各个部门各个模块的充分交流和沟通，最忌讳的就是消息封闭和闭门造车，缺乏交流对于壹个健全项目而言无疑是壹种潜于的风险。
项目负责人需要根据实际情况安排技术比较过硬的人员针对各个部门技术算法难点，流程设计，接口设计等进行技术培训，其他部门的人员根据实际情况参加培训提出疑问。
项目刚开始进行的时候以总体流程为主要培训主题，随着项目的进行，逐渐引入美术设计，模块划分，数据结构设计，算法实现，质量控制等方面的主题，确保壹个项目中每个部门均有人对于整个项目的进程和技术实现比较了解。
对于培训人员进行业绩记录跟考评关联以提高大家的参和热情。
对于培训起到重要作用的人员给予表扬。
项目管理人员于项目进行中要起到桥梁的作用，随时跟各个部门的人员进行沟通，不但要掌握项目每天的进度，而且根据情况要预知风险且进行规避。
附录六考评规则跟奖惩制度
壹、程序人员考评规则
程序员根据其代码数量，质量，错误率，效率，业绩，特别算法，沟通等进行每月考评，年度考评根据技术水平跟业绩表现做整体考评。
详情参见开发人员考评指标。
二、测试人员考评规则
测试人员根据其发现的错误数量，级别，业绩，沟通交流跟业务水平进行每月考评，年度考评那个根据技术水平跟业绩表现做整体考评。
详情参见测试人员考评指标。
三、其他关联人员考评规则
销售人员有销售部门制定详细业绩考核标准进行考评，美术部门根据其工作量跟质量，工作反应及时度进行考评。
项目整体考评根据项目进度，阶段进度，完成质量，用户反映等做出综合评价，详细考评指标参见项目文档规范。
附录七需求变更控制
由于需求变更是所有项目中最为常见也是代价最高的部分，所有CMM2级之上对需求变更做了详细规定。
我们于处理需求变更时，对于必须变更的需求，经过项目核心小组讨论决定后和用户就详细变更要求，所需要付出的时间或者资金代价进行协商，达成壹致后于详细规格说明书中由设计部门进行整体设计且考察其可能影响的模块变更。
开发部门根据设计做相应的更改，对于任何变更需要进行从功能测试，集成测试到系统测试的全面测试。
对于每壹次需求变更于项目中需要有详细记录跟跟踪，最后项目总结部分需要进行变更统计。
需求变更详细规格见需求变更控制文档。
附录八进度拖延处理跟风险规避
由于需求变更，技术实现，个人原因导致项目进度拖延的情况存于于每个项目之中。
作为项目负责人，需要能够提前预知可能产生拖延的原因进行风险规避。
于已经产生拖延的情况下，需要预先设立解决方案及时启动后备方案来解决当前的拖延问题。
1．项目设计过程中对于时间安排要根据实际情况（开发人员，测试人员，设计人员根据经验对功能实现预期的实现时间）增加30％的富余时间量作为紧急处理时间。
对于无法按照规定实现的项目应该减少可能的功能，决不能削减测试时间来达到完成期限。
2．对于需求变更详见需求变更控制部分。
尽可能不改动需求，对于任何改动所需要增加的代价必须有完备的评估。
3．技术实现拖延，由于技术问题所产生的拖延能够考虑用其他技术取代比较难实现的技术细节或者根据实际情况用其他手段代替技术实现，实于无法代替的情况宁可削减功能，不能于壹个技术难题上使用太多的时间跟精力。
4．个人原因导致的进度拖延尽可能由项目管理人员协调解决，帮助和鼓励其按时完成，赶上进度。
尽量避免于项目进行中更换或者安排接替人员，交接培训上手的时间会大大增加拖延导致项目不能按时完成。
人员的增加会导致项目复杂度以几何级数增长。
附录九项目核心控制小组PTT
项目核心控制小组由项目管理人员从开发部门，设计部门，测试部门，美术部门中指定技术过硬的人员担任。
其中至少包括30％的参和人员，项目管理人员仍需要指定壹名易用性研究员做项目各个阶段的用户友好性评估跟修订。
参和核心小组的是项目中的核心程序员，核心设计人员跟核心测试，美术人员。
项目核心控制小组的主要作用是随时监控项目进度，增强各个部门对于项目进度的把握，风险预测跟规避，项目拖延处理机制，项目里程碑控制，技术讨论培训管理跟项目中所有问题的协商处理。
升级会员 