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

《消费类电子项目管理完整规范流程》由会员分享，可在线阅读，更多相关《消费类电子项目管理完整规范流程（15页珍藏版）》请在装配图网上搜索。

1、手机项目管理完整规范流程1 概述针对手机项目，其开发，流程控制和系统分析做出的相应项目管理规范。2 项目流程控制2.1 市场调研和项目定向2.1.1 采集用户需求（见用户需求采集分析部分）手机项目中由策划人员取代用户提出需求，交流相对方便但需求变更量相对增加。对于软件方面考虑用户日常工作中相对繁琐和需要重复操作的步骤，对可以实现的用户需求和易用性的研究进行整理和记录。2.1.2 指定项目负责人给项目指定一个总负责人来对项目开发、经费控制、人员管理、进度掌握、质量控制等负责。项目负责人需要具备能够预先发现问题和解决问题的能力、能够团结和发挥项目中每个人的能力、能够很好的规划和控制进度进行的能力和

2、能够对项目的质量进行严格控制和评估的能力。2.1.3 合理组建需要的各个部门并指定负责人手机项目对于部门划分相对要求较少，但是对于每个环节指定相应的负责人员是必要的。2.1.4 制定市场推广计划提前设计广告及宣传，做针对项目特色跟潜在用户的市场推广计划。可以采用大型活动，与其他相关企业合作举办活动，在网络论坛上组织活动和媒体宣传等多种形式。具体采用方式需要对投入，效果，活动规模等作出详细分析后决定。根据产品特色和优势制定相应的推广方案，根据用户特点制定相应推广形式。媒体宣传网络宣传与联通移动合作与SP合作与手机开发商合作与高校合作市场成本高低较高较低一般较低效果好一般好一般一般一般面向对象媒体

3、用户网络用户手机用户SP用户手机用户学生附加收获与媒体建立联系，知名度提升打开网络宣传通道与移动联通建立联系，知名度提高寄售游戏，合作双赢建立合作关系，提高知名度寻找，培养兴趣优秀毕业生待增加对于市场推广部分，由于曾经在中国移动经历了移动跟Nokia合作举办的手机程序大赛，对于其运作模式跟部门有一定了解，可以根据需要选择任何一方作为合作伙伴进行市场宣传。另外，大学校园是成本非常低的活动基地，同时可以寻找培养优秀人才加盟。举办适当新产品调研，游戏开发大赛和游戏大赛都是非常具有前景的。以上所有形式可以根据现有资金，市场需要进行搭配组合，可以同时启动以达到更好的市场宣传效果。另外对于开展形式和时机可

4、以根据项目需要进行相应调整。2.2 研究并确定技术方向，竞争对手资料收集2.2.1 确定使用的平台，语言和工具研究当前的新技术和开发语言、项目管理工具、版本质量控制工具，比较各种语言和工具的优缺点并整理记录到对比表中，根据项目特点、人员和要求选择适合的开发工具和管理工具。开发语言对比表KjavaUniJavaCC+待增加开发平台Moto OSCDMA 1x, 2xNokia OSSymbian OS开发代价一般一般较低一般面向对象Moto联通NokiaPalm运行效率一般一般一般快运行稳定性稳定稳定很稳定很稳定其它复杂度单项兼容计费接口MIDP应用单项兼容待增加采用的数据库比较（稳定性主要考虑

5、主流数据库应用）：手机数据库不同于一般数据库，其存储量不会很大，一般使用rms。项目管理和质量控制工具比较（可以组合使用）ProjectClearCaseBugzillaCVSClearQuest待增加项目规划有有没有没有没有项目进度把握有有没有有没有错误及修正记录没有有有有有及时反馈交流没有没有有有有人员工作统计有有有有有其它优点整体规划流程控制错误处理版本控制错误处理待增加代码和版本控制工具：目前使用CVS或者ClearCase，需要以较低成本构建详细项目体系时推荐使用CVS作为版本控制，加入Bugzilla作为测试控制工具。在资金允许的情况下，比较推荐使用IBM的ClearCase和Cl

6、earQuest建立整个项目控制管理体系。项目规划和进度划分推荐使用Project做前期进度设计。对于已经进行的项目或者发展中公司，针对现有资源，代码进行整合的时候应尽可能的减少改动，因地制宜的设定规范跟质量管理体系，使已经适应当前开发模式的人员可以尽快适应新的健全开发体系并尽可能的减少由于变更带来的问题。根据手机游戏开发的特点，需要确定该项目是支持网络功能还是单机游戏。对于网络又分为支持蓝牙功能还是WAP功能。对于单机游戏，需要在图像，操作和存储方面分层进行处理并整理可用资源。2.2.2 整理可用的资源利用所有可用的资源以提高开发的进度，整理现有可用的资源和代码，并且查找相关的共享源码和资源

7、。将所有现有资源整理并找出可用的部分加以利用，这样不但能够有效提高开发效率还能得到一些有益的经验。例如增加模块数据库管理现有引擎，复杂算法，封装好的模块以便随时去用，开发过程中尽可能使用现有模块降低成本减少错误的产生。2.2.3 研究相应规范和标准研究当前领域内的国际和国内可能使用到的规范和标准，整理并翻译相应规范。尽量使产品符合更多通用的规范，这样也有利于以后的产品宣传和产品升级。2.2.4 比较竞争对手资料收集领域内其它竞争对手的产品，总结出其优越性和特点。结合自身情况考虑实现代价取舍其中的功能点并增加自己的特色。需要专人负责整理所有比较数据记录进项目文档中，对于市场宣传，功能点设计和市场

8、推广都将起到参考作用。2.2.5 记录项目资料将根据上述资料讨论确定项目使用的主要技术、平台、开发工具和项目管理工具等整理记录，记录与竞争对手的比较资料和相关规范。2.3 制定开发里程碑和安排开发人员2.3.1 选择开发模型根据项目工期、经费和其它需要合理选择搭配开发模型。制定开发模块，功能点，实现周期。2.3.2 安排开发人员根据需要安排开发人员，记录项目需要的总人员、各个部门指定的针对项目的人员，估算每个人的工作量和时间安排。给每个人员进行相应的项目培训使所有参与项目的人员对项目有一定认识，并收集各个部门的员工对项目的建议和意见。2.3.3 组织项目进度跟踪小组PTT项目核心控制小组由项目

9、管理人员从开发部门，设计部门，测试部门，美术部门中指定技术过硬的人员担任。其中至少包括30的参与人员，项目管理人员还需要指定一名易用性研究员做项目各个阶段的用户友好性评估跟修订。参与核心小组的是项目中的核心程序员，核心设计人员跟核心测试，美术人员。项目核心控制小组的主要作用是随时监控项目进度，增强各个部门对于项目进度的把握，风险预测跟规避，项目拖延处理机制，项目里程碑控制，技术讨论培训管理跟项目中所有问题的协商处理。2.3.4 指定易用性（用户友好性）研究员指定一个易用性研究员，负责研究市场上同类产品的易用性优缺点，控制每个步骤的易用性检查工作并对产品提出相应的改进意见和建议，确保产品的易用性

10、。需要有一定积极性和创造性并熟悉用户需要从用户角度考虑问题的人员担任，可以是售前、产品设计或者开发部门的人员，该员工需要参加PTT小组。2.4 用户需求采集和分析2.4.1 采集用户需求采用SRS模板、指明需求的来源、为每项需求注上标号、记录业务规范、创建需求跟踪能力矩阵、审查需求文档、以需求为依据编写测试用例、编写用户手册、确定合格的标准。1. 绘制系统关联图，这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时也明确了通过接口的信息流。 2. 创建用户接口原型，当开发人员或用户不能确定需求时，开发一个用户接口原型。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题

11、。注意要找出需求文档与原型之间所有的冲突之处。3. 分析需求可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。 4. 确定需求的优先级别，应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，参看需求变更。 5. 为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态

12、变换图、对话框图、对象类及交互作用图。 6. 创建数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。 7. 使用质量功能调配，（QFD）是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。QFD将需求分为三类：期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备2.4.2 需求变更控制由于需求

13、变更是所有项目中最为常见也是代价最高的部分，所有CMM2级以上对需求变更做了详细规定。我们在处理需求变更时，对于必须变更的需求，经过项目核心小组讨论决定后与用户就详细变更要求，所需要付出的时间或者资金代价进行协商，达成一致后在详细规格说明书中由设计部门进行整体设计并考察其可能影响的模块变更。开发部门根据设计做相应的更改，对于任何变更需要进行从功能测试，集成测试到系统测试的全面测试。对于每一次需求变更在项目中需要有详细记录跟跟踪，最后项目总结部分需要进行变更统计。需求变更详细规格详见：需求变更控制规范。2.4.3 生成规格说明书最后生成一份项目中最完整的规格说明书，为设计、开发、测试提供参考并最

14、终从中抽取出用户使用说明书和其它终端文档。PTT小组评审、确定设计方案，文档记录。之后如果对设计文档进行任何修改都需要经过PTT小组的讨论确定并详细记录修改原因、修改日期、修改人员等信息。详细规格说明书应该包括所有确定需要实现的用户需求功能点，其分配人员，预定完成时间，工作量，风险评估，里程碑设定。针对每一个功能点需要有负责人，每周查看进度是否符合预定目标。功能需求是否有相应更改，详细见需求变更控制部分。2.5 概要设计和原型设计设计图标和用户界面。进行概要设计、制作产品原型（美工和设计部门参与，开发部门协助），提供给用户并收集用户反馈意见循环改进。2.6 数据结构，存储设计利用现有企业对数据

15、结构的详细规范要求进行设计。尽量精简数据结构，做到合理逻辑关联，减少复杂度。数据存储结构需要根据实际情况响应制定。2.7 功能详细设计由开发部门完成的详细设计包括了对功能点的详细理解，算法设计，数据结构设计跟功能详细流程图。所有部分应严格符合开发规范跟文档规范的要求。按照统一的文档规范编写详细设计文档，包含算法设计、流程设计和数据结构设计。质量控制部门对详细设计进行考核和修改，PTT小组对详细设计进行评审。确定之后详细设计文档记录，如果有任何改动需要经过PTT小组讨论决定。详细设计文档作为测试和质量控制考核程序质量的依据。2.8 功能实现和功能测试根据详细设计和代码编写规范完成代码编写工作，实

16、现各个需求中描述的功能点。对每个功能点进行测试。对所有代码做易用性、算法复杂度和规范检查。完成代码文档的编写。编写用户使用说明。项目改进小组对开发流程进行监督和不断改进。2.9 集成测试和系统测试由测试部门完成的集成跟系统测试需要在测试环境中进行。将相关功能点联调，测试并修改。将系统集成，对系统进行硬件、软件、压力测试，对客户端进行不同使用平台，不同软件版本的测试。利用错误控制工具记录和修改错误。模拟用户环境进行完整流程测试，邀请部分用户或者潜在用户参与beta版本的测试。对于所产生的错误进行等级划分跟记录，每周对于所有错误进行项目跟踪，如果优先级较高可以临时组织会议讨论处理。所有错误由项目管

17、理或者开发负责人制定专人负责并随时跟踪没有关闭的错误，保证代码出错率低于一定比率。对于出产产品出错率严格限制。2.10 产品相关宣传和产品交付根据产品特点和项目启动时所制定的计划进行产品宣传和产品说明。发布相关产品专利和印刷产品。将产品交付用户。2.11 回归测试和项目总结进行回归测试、迭代测试和相关产品升级。对项目进行总结，记录项目中所有可以重复利用的资源和经验，对一些对项目进度造成影响的事件和原因PTT小组进行分析和统计，记录并为以后项目提供经验。2.12 技术培训跟沟通项目进行过程中要做到各个部门各个模块的充分交流和沟通，最忌讳的就是消息封闭和闭门造车，缺乏交流对于一个健全项目而言无疑是

18、一种潜在的风险。项目负责人需要根据实际情况安排技术比较过硬的人员针对各个部门技术算法难点，流程设计，接口设计等进行技术培训，其他部门的人员根据实际情况参加培训提出疑问。项目刚开始进行的时候以总体流程为主要培训主题，随着项目的进行，逐渐引入美术设计，模块划分，数据结构设计，算法实现，质量控制等方面的主题，确保一个项目中每个部门都有人对于整个项目的进程和技术实现比较了解。对于培训人员进行业绩记录跟考评关联以提高大家的参与热情。对于培训起到重要作用的人员给予表扬。项目管理人员在项目进行中要起到桥梁的作用，随时跟各个部门的人员进行沟通，不但要掌握项目每天的进度，而且根据情况要预知风险并进行规避。附录六

19、 考评规则跟奖惩制度一、程序人员考评规则程序员根据其代码数量，质量，错误率，效率，业绩，特别算法，沟通等进行每月考评，年度考评根据技术水平跟业绩表现做整体考评。详情参见开发人员考评指标。二、测试人员考评规则测试人员根据其发现的错误数量，级别，业绩，沟通交流跟业务水平进行每月考评，年度考评那个根据技术水平跟业绩表现做整体考评。详情参见测试人员考评指标。三、其他相关人员考评规则销售人员有销售部门制定详细业绩考核标准进行考评，美术部门根据其工作量跟质量，工作反应及时度进行考评。项目整体考评根据项目进度，阶段进度，完成质量，用户反映等做出综合评价，详细考评指标参看项目文档规范。附录七 需求变更控制由于

20、需求变更是所有项目中最为常见也是代价最高的部分，所有CMM2级以上对需求变更做了详细规定。我们在处理需求变更时，对于必须变更的需求，经过项目核心小组讨论决定后与用户就详细变更要求，所需要付出的时间或者资金代价进行协商，达成一致后在详细规格说明书中由设计部门进行整体设计并考察其可能影响的模块变更。开发部门根据设计做相应的更改，对于任何变更需要进行从功能测试，集成测试到系统测试的全面测试。对于每一次需求变更在项目中需要有详细记录跟跟踪，最后项目总结部分需要进行变更统计。需求变更详细规格见需求变更控制文档。附录八 进度拖延处理跟风险规避由于需求变更，技术实现，个人原因导致项目进度拖延的情况存在于每个

21、项目之中。作为项目负责人，需要能够提前预知可能产生拖延的原因进行风险规避。在已经产生拖延的情况下，需要预先设立解决方案及时启动后备方案来解决当前的拖延问题。1 项目设计过程中对于时间安排要根据实际情况（开发人员，测试人员，设计人员根据经验对功能实现预期的实现时间）增加30的富余时间量作为紧急处理时间。对于无法按照规定实现的项目应该减少可能的功能，决不能削减测试时间来达到完成期限。2 对于需求变更详见需求变更控制部分。尽可能不改动需求，对于任何改动所需要增加的代价必须有完备的评估。3 技术实现拖延，由于技术问题所产生的拖延可以考虑用其他技术取代比较难实现的技术细节或者根据实际情况用其他手段代替技

22、术实现，实在无法代替的情况宁可削减功能，不能在一个技术难题上使用太多的时间跟精力。4 个人原因导致的进度拖延尽可能由项目管理人员协调解决，帮助和鼓励其按时完成，赶上进度。尽量避免在项目进行中更换或者安排接替人员，交接培训上手的时间会大大增加拖延导致项目不能按时完成。人员的增加会导致项目复杂度以几何级数增长。附录九 项目核心控制小组PTT项目核心控制小组由项目管理人员从开发部门，设计部门，测试部门，美术部门中指定技术过硬的人员担任。其中至少包括30的参与人员，项目管理人员还需要指定一名易用性研究员做项目各个阶段的用户友好性评估跟修订。参与核心小组的是项目中的核心程序员，核心设计人员跟核心测试，美

23、术人员。项目核心控制小组的主要作用是随时监控项目进度，增强各个部门对于项目进度的把握，风险预测跟规避，项目拖延处理机制，项目里程碑控制，技术讨论培训管理跟项目中所有问题的协商处理。阶段流程图文档项目立项阶段项目建议书可行性分析市场信息反馈任命项目经理成立项目团队小组签发项目任务书可行性分析报告项目任务书项目总体规划各部需求分析需求分析评审系统分析产品定义确定里程碑编制质量控制计划编制项目计划书风险控制计划需求分析报告需求分析评审报告产品定义产品技术规范项目开发计划风险控制计划质量控制计划系统分析文档设计阶段系统分析评审工艺设计流程结构设计及制作流程图硬件设计流程软件设计流程PCB/PCBA或P

24、CBA或 V1.0工艺说明T1T1软件V1.0评审，过程文件归档产品技术总体设计方案（包括工艺）系统分析评审报告软件V1.0PCB V1.0BOM V1.0T0设计文档工艺说明分单元测试报告 方案公司 ID&MD外协公司 设计验证阶段T0整机测试及评估软硬件及工艺调整版本升级修模例试报告及分析装机报告少量装机装机准备T1设计文档BOM V2.0装机报告例试分析报告整机测试评估报告软件FTA版本硬件FTA版本T1修模软硬件及工艺调整版本升级CTA材料下单例试、整机测试及评估试产准备小批量试产T1设计文档BOM V3.0试产报告例试分析报告整机测试评估报告软件CTA版本硬件CTA版本T2CTA软硬

25、件结构及工艺调整版本升级量产版本确定例试、整机测试评估试产准备CTA准备第二次试产CTAT2设计文档BOM V4.0试产报告例试分析报告整机测试评估报告量产准备阶段生产工艺准备全套文件归档手工下单封样全套DVT报告工艺文件量产转移量产转移说明：T1、T2设计验证阶段可根据项目实际情况简化流程，如：只保留一个试产流程，以加快项目进度。附录1. 结构设计及制作流程图：阶段流程图表单3D模型修改结构制定结构设计进度计划表可行评估3D模型可行性评估3D模型评估报告结构设计进度表详细结构设计结构详细设计结构设计进展汇报结构设计修改结构设计内部评审结构设计进度表结构设计验证评审制作working samp

26、leworking sample验证结构设计外部评审模具制作检讨发结构报价图相关资料准备签订商务合同开模结构设计修改结构设计内部评审记录workingsample配色表workingsample验收报告结构BOM结构设计外部评审记录模具制作检讨记录表模具制作申请表模具备品清单模具制作注意事项表工装夹具制作清单物料进度按排需求表配色方案表模具制作进度表参考文件：附录2. 软件设计流程图：阶段流程图表单软件需求分析软件需求分析（包括技术风险评估）软件开发计划和配置管理计划进度计划表软件测试计划软件需求规格书软件开发计划软件开发风险控制计划软件测试计划软件详细设计详细软件设计内部设计评审软件详细设计

27、说明书软件接口设计说明书软件设计内部评审记录软件实现测试编码调试编写测试用例单元测试软件集成/调试评审后发布并归档软件修订软件系统测试发布系统测试版本单元源代码单元调试报告单元测试用例单元测试分析报告集成后的软件及源代码软件集成调试报告软件操作手册系统测试软件系统测试用软件文档软件系统测试分析报告发布版本参考文件：附录3. 硬件设计流程图：阶段流程图表单硬件需求评估硬件需求分析（包括技术风险评估）硬件开发计划和配置管理计划进度计划表硬件测试计划硬件需求分析报告硬件开发计划硬件测试计划硬件详细设计详细硬件设计LCD认证流程关键器件采购PCB毛坯图设计内部设计评审硬件详细设计说明书硬件电路原理图硬

28、件BOM硬件设计内部评审记录硬件实现测试PCB布板流程软件投板前审查打样、试产硬件调试PCB贴片硬件内部评审整机测试评审后发布并归档硬件修改PCB数据器件规格书硬件子系统软件装配图硬件单元测试分析报告电装总结报告硬件系统测试版本硬件系统测试分析报告硬件评审验证报告发布版本参考文件：1、 PCB布板流程图2、 LCD认证流程图PCB布板流程图：阶段硬件结构其他各部表单布板需求设计硬件电路原理图PCB布板设计结构尺寸要求项目需求/产品定义PCB确认投板前审查PCB GERBERPCB投板PCB投板参考文件：LCD认证流程图：阶段硬件结构其他各部表单样品提供样品需求SPECLCD供应商数据收集和选择

29、供应商提供样品尺寸各部确认各部确认？供应商供样与供应商沟通SPEC各部提出修改要求电性能SPEC尺寸确认软件确认装机是否通过？ 否 是装机验证封样参考文件：效 果 图 内 部 评 审内部评审手板外部评审效果图外部评审造型所内部评审内部评审新品B新品A开模其他后续工作(配色、油漆、物料等)试产配合结构设计工作新流程的循环组3结构手板评审结构设计组n组2设计输入内部立项设计输入内部立项手板评审方案1组1外观手板设计与制作组3组1组1方案1效果图评审方案3效果图/模型/渲染组n组2组内遴选草图阶段小组划分分配设计任务/组内分工自主开发项目B自主开发项目A流程第一轮草图CAID精细草图组3方案1N方案1N方案1N方案1N