产品研发流程.docx

产品研发流程.docx

《产品研发流程.docx》由会员分享，可在线阅读，更多相关《产品研发流程.docx（6页珍藏版）》请在冰豆网上搜索。

产品研发流程

产品研发流程

程序文件产品研发流程2003年月日起生效文件号编制审核批准版次1.0日期日期日期共66页

第73页1目的及适用范围1.1为规范产品研发过程，提高产品研发的效率.质量，降低研发成本，特制定本程序；1.2本程序文件适用于侏罗纪公司产品研发；1.3本程序文件由侏罗纪公司制定，其解释权及修改权属于；1.4本程序文件从2003年月日起执行；2职责2.1产品部负责产品研发；2.2质量控制部负责对产品开发过程中的里程碑产生的相关成果和文档进行质量控制，并将符合规范的成果放入资源中心存档；2.3技术支持部和市场部负责宣传材料和用户手册的制作，以及和产品销售流程的衔接环节和动作；3产品研发流程3.1CEO从公司战略规划决案中形成产品规划，下发给产品中心；3.2产品中心（副）总监依据产品规划安排产品经理进行产品研发立项；3.3执委会对产品立项进行评审，若评审未通过，相关文档放入资源管理部备案；3.4若立项评审通过，质量控制部对立项进行质量检验，若质检未通过，产品经理修改立项报告；3.5若质检通过，产品经理开始制订项目计划，同时质量控制部将立项相关文档放入资源管理部归档；3.6产品经理将项目计划提交给产品（副）总监评审，若未通过，产品经理修改项目计划；3.7若评审通过，质量控制部对项目计划进行评审，若质检评审未通过，产品经理修改项目计划，若质检评审通过，产品总监安排研发项目资源；3.8产品经理获得研发项目资源后，进行需求分析，并将相关成果交技术委员会进行内容评审；3.9若内容评审未通过，产品经理修改需求分析；若内容评审通过，质量控制部对《需求分析说明》进行质量检验；3.10若质检未通过，产品经理修改《需求分析说明》，若质检通过，相关成果和文档放入资源管理部归档，同时产品经理带领研发相关人员进行总体设计；3.11产品经理和研发人员完成总体设计后将相关成果交技术委员会进行内容评审；3.12若内容评审未通过，产品经理修改《总体设计说明》；若内容评审通过，质量控制部对《总体设计说明》进行质量检验；3.13若质检未通过，产品经理修改《总体设计说明》，若质检通过，相关成果和文档放入资源管理部归档，同时产品经理和研发人员进行程序设计/测试；3.14完成程序设计/测试后，产品经理将相关成果交质量控制部进行功能测试，若测试未通过，产品经理修改相关成果，若测试通过，质量控制部对相关成果和文档进行质量检验；3.15若质检未通过，产品经理修改相关成果和文档；若质检通过，质量控制部将相关成果和文档放入资源管理部门归档；3.16同时产品研发组制作软件，技术支持部和市场部制作宣传材料，之后，技术支持部对销售人员进行内部培训，市场部申请并取得著作权；3.17市场部在取得著作权后制作用户/技术手册；3.18产品研发组完成软件制作后，质量控制部对制作的软件进行质量检验，若未通过质检，产品研发组重新制作软件；若通过质检，相关成果和文档放入资源管理部归档，同时产品经理进行产品研发总结；3.19质量控制部将产品研发总结等相关成果和文档放入资源管理部，同时市场部进行软件产品包装，销售部进行产品销售；4相关文件4.1《产品规划说明书》4.2《立项报告》4.3《综合评审记录》4.4《质量控制立项报告和可行性分析报告说明书》4.5《项目计划书》4.6《质量控制项目计划评审记录》4.7《资源调度单》4.8《需求分析说明书》4.9《质量控制需求分析说明书评审报告》4.10《资源中心验收单》4.11《评审规程》4.12《总体设计说明书》4.13《概要设计说明书》4.14《详细设计说明书》4.15《质量控制系统设计报告评审记录》4.16著作权相关文档（略）4.17《软件质量保证单》4.18《软件缺陷报告》《项目总结》产品规划说明书公司三年产品规划1.2.3.公司年度产品计划1.2.签发人：

时间合评审记录（公司）评审对象（项目名称及编号）评审项类（如合同.投标方案等）评审人时间业务板块（产品中心.项目中心.服务中心.营销中心）评审意见财务部评审意见质量控制部评审意见技术委员会评审意见专家委员会评审意见最终意见：

通过修改修改内容时间立项报告评审记录记录编号：

时间：

年月日可行性分析报告编号：

可行性分析报告名称：

编制部门：

编制人：

参加人员:

评审内容:

（评审中审议通过的内容在“□”中划“√”否则划“×”）：

1）软件产品功能要点及产品化程度书□2）量化的市场前景.效益分析和竞争对手分析□3）开发优势□4）技术路线□5）成本估算□6）进度估算□7）可用的现行技术.重用软件和开发平台□评审意见:

评审结论：

填表审批

1.本页不足记述评审意见时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。

第页/共页风险评估与控制（可行性分析报告评审附页）立项建议报告名称：

评估人/日期：

评审部门序号风险描述风险发生可能性风险级别风险现值风险控制措施1市场调研不充分2市场预测不准确（如目标市场.产品定位等）3编写人员缺乏足够的行业知识和专业知识4时间紧5多部门配合6技术可行性（如技术平参采用.接口的描述等）7缺乏足够的资源8投资预算不合理9缺乏对技术复用的分析10缺乏对本公司的产品形态.技术路线.战略方针.发展趋势的全面了解11缺乏对市场环境.竞争对手的了解

1.评估中风险不限于表中列出的，应依据评审的具体情况增加风险项。

并将各项填写完整。

2.风险描述：

描述当前过程中可能发生的风险。

风险发生可能性：

风险发生的概率，以百分数表示，其中10级为最高级。

风险现值：

风险发生可能性级别的乘积。

风险控制措施：

预防风险发生的措施程序文件产品研发流程2003年月日起生效文件号编制审核批准版次1.0日期日期日期共66页

第73页项目计划书项目名称项目编号项目经理项目任务描述项目总时间及关键里程碑设置项目资源（人力.技术.设备）项目费用预计审批人意见：

总监：

副总监：

执委会：

备注：

抄送财务部.人力资源部时间项目启动计划评审记录记录编号：

时间：

年月日项目编号：

项目名称：

项目启动计划编号：

开发部门：

PM：

评审地点：

参加评审人员:

评审内容（评审中审议通过的内容在“□”中划“√”否则划“×”）：

1）项目的目的是否明确？

□2）对项目的规模是否进行估算？

□3）是否进行项目启动的预算？

□4）阶段输出结果是否明确？

□5）其它方面评审意见：

评审结论：

填表：

审批：

1.项目启动计划评审由项目管理部门组织评审。

2.评审完成后由开发体系决策层SMG批准。

3.本页不足记述结果时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。

第页/共页开发计划评审记录记录编号：

时间：

年月日项目编号：

项目名称：

项目计划编号：

开发部门：

PSM：

评审地点：

参加评审人员:

评审内容：

评审意见：

评审结论：

填表：

审批：

1.开发计划评审由项目管理部门组织评审。

2.评审完成后由开发体系决策层SMG批准。

3.本页不足记述结果时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。

第页/共页开发计划检查表（开发计划评审附页）项目名称：

项目编号：

检查项目检查内容检查结果得分

一.质量目标1.是否符合质量体系的要求？

2.如果不符合技量体系的要求，是否按要求编制《质量计划》？

二.阶段划分1.是否明确划分各阶段？

2.各阶段的输入.输出标准是否明确？

3.是否明确各阶段提交物？

4.是否明确各阶段质量目标？

5.是否明确提出各阶段检查点？

三.产品清单1.是否明确提交给客户的产品清单（产品名称.提交时间.客户接受方式.责任人.验收标准）？

2.是否明确提交给项目监按钮部门的产品清单（产品名称.提交时间.提交方式.责任人）？

四.技术管理1.是否明确开发环境（软件.硬件环境）？

2.是否明确开发工具？

3.是否明确开发方法？

4.是否采用新技术？

5.是否考虑软件复用？

五.组织结构1.是否确定项目小组成员，并将其划分成多个Team?

2.是否明确各个小组成员的职责？

六.风险管理1.是否预测了与项目有关的主要风险？

2.是否采取跟踪.监测措施以减小风险或避免风险的产生？

七.相关性1.是否考虑了项目的外部相关活动？

2.是否考虑了项目的内部相关活动？

八.资源预算1.是否画了有关资源的直方图？

2.是否预算了项目的工作量并划分给小组成员？

九.配置管理1.是否制定了配置管理计划表？

检查人/日期：

批准人/日期：

程序文件产品研发流程2003年月日起生效文件号编制审核批准版次1.0日期日期日期共66页

第12页风险评估与控制（开发计划评审附页）

1.评估中风险不限于表中列出的，应依据评审的具体情况增加风险项。

并将各项填写完整。

2.风险描述：

描述当前过程中可能发生的风险。

风险发生可能性：

风险发生的概率，以百分数表示，其中10级为最高级。

风险现值：

风险发生可能性级别的乘积。

风险控制措施：

预防风险发生的措施立项建议报告名称：

评估人/日期：

评审部门序号风险描述风险发生可能性风险级别风险现值风险控制措施1客户需求不明确2客户需求不明确3开发人员缺乏足够的行业知识和专业知识4源码.文档的控制5工作阶段划分不明确.人员分工不合理6多部门配合7开发队伍不稳定或缺乏人力资源8预算超支9缺乏对技术复用的考虑10时间紧11存在技术难点.采用新技术12检查点设立不合理13缺乏对突发事件的考虑程序文件产品研发流程2003年月日起生效文件号编制审核批准版次1.0日期日期日期共66页

第73页软件问题报告记录编号：

时间：

年月日项目编号：

项目名称：

项目软件经理PSM：

需求分析报告编制人：

参加评审人员：

评审内容：

（评审中审议通过的内容在“□”中划“√”，否则划“×”）

1.无岐义性□2.完整性□3.可验证性□4.一致性□5.可使用性□6.符合《需求分析报告编写规范》的要求□评审意见：

风险评估总结：

评审结论：

（评审中审议通过的内容在“□”中划“√”，否则划“×”）

1.通过评审，可以进入下一阶段□2.未通过评审，修改后重新评审□填表：

审批：

1.本页不足记录结果时，可以有附页，附页格式自定。

总页数包括本页与所有附页。

第页/共页风险评估与控制（需求分析报告评审附页）立项建议报告名称：

评估人/日期：

评审部门序号风险描述风险发生可能性风险级别风险现值风险控制措施1客户需求变化2开发人员缺乏足够的行业知识和专业知识3需求未被顾客完全认可4需求不明确5时间紧6存在技术问题.采用新技术7多部门配合8没有顾客系统接口原形9缺乏顾客自然情况的了解10顾客配合程度不够11

1.评估中风险不限于表中列出的，应依据评审的具体情况增加风险项。

并将各项填写完整。

2.风险描述：

描述当前过程中可能发生的风险。

风险发生可能性：

风险发生的概率，以百分数表示，其中10级为最高级。

风险现值：

风险发生可能性级别的乘积。

风险控制措施：

预防风险发生的措施评审规程状态：

草稿标识号：

评审当前版本：

1.0初始版前一版本：

修订版发布日期：

摘要本文详细描述了软件工作产品的评审规程。

将要执行评审的所有项目的软件工作产品都必须遵循该评审规程。

修改历史日期版本作者修改内容评审号更改请求号目录1目的和范围272评审角色272.1作者272.2评审组长272.3记录员272.4其他参与人员283评审过程283.1计划阶段283.1.1进入条件283.1.2目的283.1.3活动283.2准备阶段283.2.1进入条件293.2.2目的293.2.3活动293.3执行阶段293.3.1进入条件293.3.2目的293.3.3活动293.4整理阶段303.4.1进入条件303.4.2目的303.4.3活动304附录A评审活动检查表315附录B评审记录表326附录C评审通知331目的和范围本文档主要描述了软件工作产品的评审过程，目的是能够及早和有效地发现并排除软件工作产品的缺陷。

2评审角色在评审时有四种角色：

作者.评审组长.记录员及其他人员。

这些角色在评审会上要承担不同的职责。

角色的划分必须遵循下面的原则：

作者和评审组长是必须的角色，且不能为同一人记录员可以是任何人员，也可由作者或评审组长兼任其他人员在数量上没有限制，可以来自与项目相关的其它组织或部门所有人员都必须具备相关的技术背景知识，对评审的软件工作产品有足够的了解，熟悉评审规程。

2.1作者作者是指被评审的软件工作产品的作者，其主要职责如下：

准备相关的评审资料完成评审后的修改工作2.2