新 品开发流程模型 1.docx
《新 品开发流程模型 1.docx》由会员分享,可在线阅读,更多相关《新 品开发流程模型 1.docx(16页珍藏版)》请在冰豆网上搜索。
新品开发流程模型1
表1项目依赖关系
Sl.No
依赖于(通常指接口等)
责任人
状态OPEN(正在进行)/CLOSE(已经关闭)
最早提供日期
验收条件(如果有)
1
2
3
5.3项目关键成功因素
关键成功因素
影响
高/中/低
依赖关系
行动计划
5.3技术方法和工具
在本节中,描述对产品项目进行需求分析、设计、实现、测试、文档写作、发布、修改、或维护过程中采用的开发方法、组织结构和其他标记、工具、技术和方法。
此外,对使用的技术标准、方针和流程也要用直接描述或参考到其它文档的方式进行说明。
参考下例,对于产品项目所需要的硬件、软件和其他工具设备用下表描述:
表2技术方法和工具
分类
名称
型号
数量
开始使用日期
结束使用日期
仪表
专用仪表
开发工具
1交付件
在本节中,应描述需要交付给下游部门的工作产品及其需求。
这些交付工作产品应包括各种设计文件、图纸、文档等。
交付工作产品应分解成可管理的大小粒度。
(这部分内容如在配置管理计划或文档计划中给出,则可以指出相关文档名称或者给予链接即可。
)可以采用列表方式。
举例如下:
3
硬件组
4
软件组
结构组
测试组
▪也可采用下表格式:
<罗列项目需要的人力资源及技能要求>
Sl.No.
资源名称
人数
起始日期
结束日期
技能要求
说明
1
2
3
4
2项目所需其它资源
9.1关键物料需求计划
详细描述在不同阶段对关键物料的需求计划。
可单独形成《关键物料需求计划》。
或可单独形成《供应商※物料选择计划》
也可采用下表:
:
表6关键物料需求计划
关键物料描述
计划采购到货时间
预期最长采购周期
计划采购数量
概念、计划阶段物料
XXX器件
开发阶段物料
XXX器件
验证与发布阶段物料
XXX器件
注:
项目组应充分估计各物料的采购周期,在各关键点应提前下达采购需求给采购部门。
增加提前采购,供应商选择
参见提前采购计划表模板:
《新物料提前采购清单》,部分物料可以从该表COPY过来
项目组应该计划好首次量产前(包括工程样机、中试样机、首次量产)的所有物料,并根据后续量产的数量、时间结合市场的计划等给出建议。
9.2实验设备和环境资源计划
详细描述在不同阶段对不同的环境的需求计划。
如特殊的硬件平台、测试设备、软件工具等。
标准的办公硬件不必在这里列。
举例如下:
表6实验设备和环境资源计划
阶段
描述
数量
计划使用时间区段
说明
概念分析
计划阶段
开发阶段
验证阶段
3资料开发计划
表7资料开发计划
资料类别
资料名称
责任人
计划完成时间
验收准则
1.用户类资料
用户手册
客户产品布XXX
评审
2.营销类资料
市场部YYY
评审
3技术支持类资料
开发/测试
评审
4应用开发资料
开发/测试
4对外合作计划
参照总体设计文档“外包外购的相应规格”列出需要对外合作的部分。
包括合作内容,进度要求等
5外包任务
<本部分仅当项目中有外包时适用>
10.1子承包商资料
子承包商名
联系人
通讯地址
<其它>
10.2外包任务的范围
<指明项目外包给子承担商的工作内容,可以采用特性、需求、模块等来说明>
10.3里程碑、交付件
<指明协商后确定的子承包商的里程碑、交付件>
里程碑
分配给子承包商的工作产品
计划开始日期
计划完成日期
给公司的交付件
6预算/分配(可选)
估计产品的预算及分配
讨论主要的未解决问题,包括资金投入的及时性及性质。
将实际日期的项目资源、成本和时间进度与估计的整个项目的资源、成本和时间进度进行比较。
7验收标准(可去掉)
客户的验收标准就是产品应满足在需求规格文档中描述的需求。
系统测试和验收测试将证实产品与需求规格保持了一致。
<请在这里注明客户特殊的验收标准。
验收标准是基于客户的需要,所以应由客户来制定,在需要的时候由项目组协助。
交付件的属性如:
质量目标,测试标准,验收结束后发现故障的处理方式,文档等。
>
8质量计划(也可单独成文档)
12.1项目过程定义
1)选择开发模型
开发类,增强类,维护类
2)并可在此基础上进一步流程裁剪:
提供与标准开发流程的偏差,并说明裁剪原因。
12.2质量目标
可以定性或定量描述,为提高可控制性,尽量采用定量质量指标描述。
若能定量描述,请参考下表:
参考或直接引用项目度量表中质量目标部分的数据。
表9项目质量目标
NO.
项目质量目标
目标
基线
(暂不填)
上限
(暂不填)
下限
(暂不填)
说明
1
进度偏差率
80%
2
需求稳定性
90
3
硬件第一次样机制作完成前缺陷发现数目
<=3
4
样机投板次数
20%
5
软件发布前缺陷发现密度
6
编码缺陷发现密度
7
硬件/软件总体设计缺陷发现数目
8
硬件/软件详细设计缺陷发现数目
9
需求更改/设计更改/工程更改数
10
文档齐套性
11
返修率
......
12.3通过技术手段保证质量
通过哪些技术手段可以保证质量目标和关键性能指标的达成。
例如:
通过静态代码分析工具和自动化软件测试工具可以有效提高软件质量。
12.4质量控制活动
罗列执行的质量控制活动。
12.4.1技术评审活动
产品开发过程中需要哪些技术评审活动,哪些技术评审点可以合并?
各技术评审点的评审要素的裁剪说明t
♦技术评审1和技术评审2合并
TR1与TR2的评审要素合并,并裁剪,评审要素重点放。
。
。
,而。
。
。
方面要素可免去。
♦技术评审3
TR3的评审要素需裁剪,评审要素重点放。
。
。
,而。
。
。
方面要素可免去。
♦技术评审4
TR4的评审要素需不裁剪;
♦技术评审5
TR4的评审要素需不裁剪;
♦技术评审6
TR4的评审要素需不裁剪;
12.4.2正规检视活动(同行评审)
产品开发过程中需要设置对哪些输出的正规检视活动?
♦软件模块测试计划
♦软件概要设计
♦软件代码
♦软件测试报告
♦硬件总体设计
♦硬件电路原理图和PCB图
♦硬件测试报告
12.4.3测试
对测试策略和测试活动进行说明:
也可合入文档《产品测试与验证计划》
●测试活动合并裁剪
例如:
增强类项目,集成测试和系统测试可以合并。
●单元测试
测试质量目标
测试依赖关系分析
测试停止准则
●集成测试
测试质量目标
测试依赖关系分析
测试重点
回归测试策略
测试停止准则
●系统测试
测试质量目标
测试依赖关系分析
测试重点
回归测试策略
12.5质量保证活动
罗列应该执行的质量保证活动。
举例如下:
12.5.1内部审计
每个项目在开发生命周期中至少进行一次内部审计。
12.5.2交付件审计(按阶段)
♦技术评审1之后
♦技术评审2之后
♦技术评审3之后
♦技术评审4之后
♦技术评审5之后
♦技术评审6之后
12.5.3基线审计
规划在哪些阶段点需要进行基线审计。
♦技术评审1之后
♦技术评审2之后
♦技术评审3之后
♦技术评审4之后
♦技术评审5之后
♦技术评审6之后
9项目沟通计划
14.1项目组会议
列举项目跟踪、监控的会议类型、频率以及参加人员,可以采用列表形式。
参考下例:
表7项目组会议
No
会议
频度
参加人
跟踪机制
1.
阶段结束会议
2.
项目总结会议
3.
14.2项目报告机制
列举项目跟踪、监控过程中需要出示的报告类型、频率、报告人、汇报人信息。
参考下例:
表8项目报告机制
No.
报告
准备人
频度
向谁汇报
1.
项目状态报告
2.
项目阶段结束报告
3.
项目总结报告
4.
10项目的重用计划
需要对公司其他产品在本产品中实现重用进行分析以及本产品可以共享给公司的其他产品以供重用,可以直接链接相应的文档或者在此加以说明。
15.1现有重用构件
Sl.No
构件/文档名
采用阶段
(Ifapplicable)
重用构件的资产ID
1
2
15.2新增重用构件
序号
构件/文档名
需求/文档id
说明
1
2
注:
资产库中已有的重用构件
2项目产生的新的重用构件
11配置管理计划
项目的配置管理活动应该按照配置管理计划来执行。
参见《XXX项目配置管理计划》。
12问题
<描述与当前版本有关的问题或从前一版本继承而来的问题>
列出项目初期任何其他已经发现的问题,包括组间协调、实验环境、工作场所等问题。
Sl.No
问题
责任人
状态(打开/关闭)
最早关闭日期
1
2
13风险管理计划
按照风险管理规程来管理项目的风险。
祥见《XXX项目风险管理计划》。
在此详细说明项目的风险项、风险描述、风险级别、规避措施、应急计划、触发条件。
具体操作办法请参考风险评估和管理相关文档。
存在哪些技术、市场和财务风险?
已确认的风险和假设是否已解决?
有无遗留问题?
有无新的风险和假设?
提供简洁的风险管理计划。
为了减少风险,在各阶段必需做些什么?
如果在计划的时间范围内,这些风险不能解决,有没有准备其它的计划?
如果没有这些风险,对项目会有哪些影响?
与产品包相关的各方面的风险包括:
市场/客户风险;
技术风险;
财务风险;
制造风险;
采购风险;
技术支持风险;
项目风险
14客户的参与
Sl.No序号
在哪些方面(阶段、工作产品等)参与
期望客户承担的职责
最大响应时间
说明
1
2
3
4
15培训计划
在本节中,明确说明相应人员现有的水平、需要的技能、培训方式和培训效果评估方式信息。
举例如下:
表10培训计划
No
培训领域
需要的技能水平
项目组成员
已具备的技能水平
培训方式
培训效果评估方式
1
2
3
导师计划也应包含在本培训计划中,该类计划在“培训方法”一栏需标识“导师培训”。
16计划更新策略
在本节中,应描述项目计划的更新策略,明确说明项目计划更新的发布方法。
还要说明对项目计划进行变更控制和管理的机制以及其载体。
以下文字仅供参考:
在发生如下事件时,PM修订项目计划和参考文档:
到达某里程碑,在每个阶段结束后如果必要的话修订项目计划。
项目的范围发生变化
当风险成为现实时采取了相应的行动
当进度、工作量超出控制的范围并需要采取纠正行动时。
当与上阶段规模变化超过+/-15%。
内部或外部审计导致的纠正活动
对修订后的项目计划按照项目管理规程来批准和签发。
项目计划的更新,存在阶段驱动性更新和事件驱动性更新两种类型。
阶段驱动性更新是指在每一阶段结束时,如果计划或者工作量估计的变动超过10%,就需要对项目计划进行更新;事件驱动性更新是指在计划执行过程中遇到项目突然变动或者其他影响项目正常运行的事件发生,需要对项目的计划进行更新。
项目计划更新需要对计划文档更新和项目里程碑计划的更新。
不论是阶段驱动性更新还是时间驱动性更新都需要对项目的更新计划进行评审,评审需要PDT经理、PQA以及功能领域代表参加。