消费类电子项目管理完整规范流程

手机项目管理完整规范流程
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 技术培训跟沟通
项目进行过程中要做到各个部门各个模块的充分交流和沟通，最忌讳的就是消息封闭和闭门造车，缺乏交流对于一个健全项目而言无疑是一种潜在的风险。

项目负责人需要根据实际情况安排技术比较过硬的人员针对各个部门技术算法难点，流程设计，接口设计等进行技术培训，其他部门的人员根据实际情况参加培训提出疑问。

项目刚开始进行的时候以总体流程为主要培训主题，随着项目的进行，逐渐引入美术设计，模块划分，数据结构设计，算法实现，质量控制等方面的主题，确保一个项目中每个部门都有人对于整个项目的进程和技术实现比较了解。

对于培训人员进行业绩记录跟考评关联以提高大家的参与热情。

对于培训起到重要作用的人员给予表扬。

项目管理人员在项目进行中要起到桥梁的作用，随时跟各个部门的人员进行沟通，不但要掌握项目每天的进度，而且根据情况要预知风险并进行规避。

附录六考评规则跟奖惩制度
一、程序人员考评规则
程序员根据其代码数量，质量，错误率，效率，业绩，特别算法，沟通等进行每月考评，年度考评根据技术水平跟业绩表现做整体考评。

详情参见开发人员考评指标。

二、测试人员考评规则
测试人员根据其发现的错误数量，级别，业绩，沟通交流跟业务水平进行每月考评，年度考评那个根据技术水平跟业绩表现做整体考评。

详情参见测试人员考评指标。

三、其他相关人员考评规则
销售人员有销售部门制定详细业绩考核标准进行考评，美术部门根据其工作量跟质量，工作反应及时度进行考评。

协商处理。

说明：T1、T2设计验证阶段可根据项目实际情况简化流程，如：只保留一个试产流程，以加快项目进度。