产品合作流程程序文件.docx
- 文档编号:13726198
- 上传时间:2023-06-16
- 格式:DOCX
- 页数:25
- 大小:243.65KB
产品合作流程程序文件.docx
《产品合作流程程序文件.docx》由会员分享,可在线阅读,更多相关《产品合作流程程序文件.docx(25页珍藏版)》请在冰点文库上搜索。
产品合作流程程序文件
1目的及适用范围
1.1为充分整合公司外的资源,降低产品开发成本,增加市场占有率,特制定本程序;
1.1本程序文件适用于侏罗纪公司产品合作;
1.2本程序文件由侏罗纪公司制定,其解释权及修改权属于;
1.3本程序文件从2003年月日起执行;
2职责
2.1产品部负责产品合作论证、谈判和产品包装;
2.2专家委员会、CEO、决策委员会分别在自己权限内对关键节点进行控制;
2.3技术支持部和市场部负责产品合作和产品销售的衔接工作;
2.4质量控制部对相关成果和文档进行质量检验,并存入资源管理部;
3产品合作流程
3.1对外合作部经理从相关部门(所有可能产生市场和产品信息的部门,如:
市场部、销售部等)汇总产品信息;
3.2对外合作部经理在对汇总后的产品信息进行分析后准备论证方案,提交专家委员会(主要由石油行业专家和软件技术专家组成,市场和财务人员列席)论证;
3.3若论证未通过,对外合作部经理相关文档放入资源管理部存档;若论证通过,CEO对论证方案进行决议;
3.4若CEO决议未通过,相关文档存入资源管理部;若CEO决议通过,同时相关合作没有超过CEO权限,对外合作部经理和合作方进行商务谈判;
3.5若CEO决议通过,同时相关合作超过CEO权限,CEO将方案提交决策委员会决议,若决策委员会决议未通过,相关文档存入资源管理部存档;若决策委员会决议通过,产品合作部经理和合作方进行商务谈判;
3.6产品合作部经理将商务谈判形成的合同提交CEO评审,若合同评审未通过,产品合作部经理继续商务谈判,若CEO评审未通过且判断无法达成最后合作,产品合作部经理将相关文档放入资源管理部存档;
3.7若合同评审通过,对外合作部经理对合作产品进行判断,若合作产品属于产品体系,转交给产品部进行产品技术包装,若合作产品属于项目体系,转交给项目中心进行产品技术包装;
3.8质量控制部对产品包装成果进行质量检验,若未通过质检,产品部/项目中心对合作产品技术包装进行修改;若通过质检,相关成果和文档放入资源管理部存档;
3.9产品部/项目中心在完成合作产品技术包装后,将相关成果交给技术支持部;
3.10技术支持部开始制作产品资料,包括产品宣传WORD材料、PPT材料、用户手册等;
3.11技术支持部完成资料制作后,市场部对资料进行包装;
3.12同时技术支持部对销售人员进行产品培训,销售人员完成产品培训后,开始产品销售流程;
4相关文件
4.1《潜在合作产品信息说明》
4.2《潜在合作产品论证方案》
4.3《潜在合作产品商务谈判》
4.4《综合评审记录》
4.5《评审规程》
4.6《软件质量保证文档》
4.7《资源中心验收单》
4.8《软件缺陷报告》
潜在合作产品信息说明
合作产品类型(专业类、通用类、)
主要功能描述
应用范围和成功案例
合作方信息
姓名
职位
专业特长
其它特征
信息提供者情况
姓名部门
对外合作部签收者姓名
时间
潜在合作产品论证方案
产品类型
产品编号
产品功能描述
产品市场前景分析
•潜在客户需求(现状及未来预计)
•竞争状况
产品技术分析
•产品的技术成熟度
•产品先进性和后期拓展性
•产品的技术复杂度
•公司掌握该技术的可能性
与公司现有资源关联性分析
•与现有资源无关
•与现有资源互补
•与现有资源竞争
产品价值估计
合作建议
方案准备人
对外合作部经理意见
专家意见
CEO意见
决策委员会意见(超过50万)
时间
潜在合作产品商务谈判
产品名称
产品编号
关于合作条件(双方责任制、版权、资源)
我方态度
合作方态度
关于价格
我方态度
合作方态度
合作建议
CEO审批
时间
综合评审记录(公司)
评审对象(项目名称及编号)
评审项类(如合同、投标方案等)
评审人
时间
业务板块(产品中心、项目中心、服务中心、营销中心)评审意见
财务部评审意见
资源管理部和质量控制部评审意见
技术委员会评审意见
专家委员会评审意见
最终意见:
通过
修改
修改内容
时间
评审规程
状态:
草稿
标识号:
评审
当前版本:
1.0
初始版
前一版本:
修订版
发布日期:
摘要
本文详细描述了软件工作产品的评审规程。
将要执行评审的所有项目的软件工作产品都必须遵循该评审规程。
修改历史
日期
版本
作者
修改内容
评审号
更改请求号
1目的和范围
本文档主要描述了软件工作产品的评审过程,目的是能够及早和有效地发现并排除软件工作产品的缺陷。
2评审角色
在评审时有四种角色:
作者、评审组长、记录员及其他人员。
这些角色在评审会上要承担不同的职责。
角色的划分必须遵循下面的原则:
作者和评审组长是必须的角色,且不能为同一人
记录员可以是任何人员,也可由作者或评审组长兼任
其他人员在数量上没有限制,可以来自与项目相关的其它组织或部门
所有人员都必须具备相关的技术背景知识,对评审的软件工作产品有足够的了解,熟悉评审规程。
2.1作者
作者是指被评审的软件工作产品的作者,其主要职责如下:
准备相关的评审资料
完成评审后的修改工作
2.2评审组长
评审组长必须为该软件工作产品所属领域的高级技术人员,其主要职责如下:
指导作者组织并实施评审活动,对评审材料进行初审,确定参加评审的人员
按照评审规程主持评审会议
在评审会议上控制评审进度,提醒参加者不要在某一问题上花费过多时间
对评审中发现的问题进行分析判断,确定处理办法,建议为两类:
1.问题项:
当场确定为问题,需要解决
2.调查项:
无法确定是否为主要问题,需要进一步调查确认
决定评审结果(通过和再评审)
2.3记录员
记录员在评审会议中记录发现的问题及相关的数据,其主要职责如下:
填写评审记录表
作为评审员参与评审
2.4其他参与人员
其他人员评审软件工作产品,回答问题、参与讨论同时帮助解决问题。
所有的参与人员都必须严格遵循评审规程。
3评审过程
评审过程分为四个阶段,每一阶段都包含一定的任务描述,可以参考《评审活动检查表》执行评审。
《评审活动检查表》是帮助评审人员正确执行评审的工具,它与本章所描述的各阶段的具体活动是一致的。
评审过程的四个阶段为:
计划、准备、执行和整理。
每一阶段必须顺序地执行,才能保证评审成功。
下面将详细描述这四个步骤。
3.1计划阶段
这是评审的第一阶段,其每一步都有详细说明,只有计划阶段的任务完成后才能进入准备阶段。
3.1.1进入条件
软件工作产品满足规范要求
软件工作产品经过拼写检查
3.1.2目的
确保作者提供正确的评审材料
确保软件工作产品满足评审要求
确定评审员并明确其职责
3.1.3活动
作者准备评审所需的材料,包含被评审的软件工作产品、支持材料及评审表格等
技术委员会指定评审组长
评审组长检查进入标准是否满足
技术委员会确定参评人员。
也可由技术委员会委托评审组长确定需要参加评审的人员
评审组长确认作者准备好所需要的材料
评审组长与作者共同确定评审会议日程
3.2准备阶段
3.2.1进入条件
评审材料已准备好
参加者对被评审的软件工作产品具备必要的背景知识
评审组长确认评审材料符合要求
3.2.2目的
评审员明确自己的职责
所有评审员在评审之前得到评审材料
确保评审员在评审之前阅读评审材料,找出问题
3.2.3活动
作者发评审会议通知给所有评审员
作者将评审材料分发给所有评审员
评审组长标识软件工作产品的范围,强调重点,提取问题
评审组长熟悉议程,确保评审进度
评审员仔细阅读评审材料,在评审材料上做评注,找出问题
所有评审员记录自己准备所花费的时间
3.3执行阶段
执行评审必须召开评审会议,所有评审员进行面对面地讨论是必要的。
3.3.1进入条件
所有评审员得到评审材料
所有评审员根据自己的角色要求准备并且评审软件工作产品
所有评审员记录自己的准备时间。
本次评审的准备时间是所有评审员的准备时间之和
会议室和其它资源已经准备就绪
作者准备就绪,重要参加人员能够出席评审会议
3.3.2目的
找出、记录和分析所有问题
3.3.3活动
评审组长检查所有评审员是否已经做好评审的准备工作
记录员记录评审员的准备时间,开始评审
作者为软件工作产品逐项进行概要介绍
记录员在评审会议上记录发现的问题
所有评审员把重点放在讨论和提出问题上
评审员使用自己注释的评审材料对有问题的地方提出讨论
作者和评审员协助评审组长描述和分析问题,
发现一个问题后,评审组长确保该问题被正确记录
所有评审员提出对评审会议的改进建议,记录员在评审表上记录要点
评审组长确保评审完成
评审组长在评审组的协助下决定评审结果。
如果没有问题或发现的问题类型和数量容易改正和处理,其结果为“通过”,否则为“再评审”
如果需要“再评审”,可以只评审需要评审的部分。
评审组长记录需要再被评审的部分
3.4整理阶段
3.4.1进入条件
问题已被记录在评审表中
3.4.2目的
修正评审中发现的所有问题
确保所有需要进行调查的项目已经被分析,并且被排除
评审数据被记录
3.4.3活动
评审组长估计并跟踪修改问题所需时间
对于问题项,作者确保有问题记录
对于调查项,经研究后,如果是问题项,作者负责解决并记录在评审表中
作者修正所有问题项
评审组长协调所有评审员检查作者已修改过的内容。
如果没有问题,则评审结果定为“通过”,否则,评审组长应提出解决方案
所有评审员确认后,在评审表上签字
如果使用评审工具代替评审记录表,则作者在评审工具中生成一个新的评审记录表,填入相应内容并提交
4附录A评审活动检查表
阶段
作者
评审组长
其他评审员
计划
☐
☐接受评审组长角色并确定评审目标
☐准备评审材料
☐检查评审进入条件是否满足
☐同评审组长一起选择评审员
☐确定需要参加评审的人员
☐接受评审员角色
☐与评审组长共同
准备
☐确保评审材料准备好
☐核实进入条件
☐理解自己的职责
☐给所有评审员发评审会议通知
☐学习并且评注软件工作产品
☐学习并且评注软件工作产品
☐将被评审材料分发给所有评审员
☐熟悉评审议程
☐记录个人的准备时间
☐确保会议室和其它资源准备就绪
☐记录个人的准备时间
执行
☐介绍评审会议日程
☐控制评审进度
☐按时出席,提供准备时间
☐逐项概要介绍软件工作产品
☐分析问题
☐记录员记录所有评审员姓名及准备时间
☐决定评审结果
☐参加讨论并提出问题
☐记录员记录问题
☐所有评审员提出对评审会议的改进建议,记录员在评审表上记录要点
整理
☐改正评审所发现的问题
☐估计并跟踪需要修改问题所需时间
☐如果有评审工具,则生成一个新的评审记录表,填入相应内容并提交
☐检查修改内容的正确性
☐阅读并确认评审记录表内容的正确性
☐提交文档
☐签字
☐签字
注:
首先由技术委员会指定评审组长。
5附录B评审记录表
评审会日期:
_________________开始时间:
_________________结束时间:
_________________
评审会地点:
___________________________________________________________第_____次评审
评审主题:
__________________________________________________________________________
__________________________________________________________________________
软件工作产品名称:
________________________________软件工作产品大小:
_________SLOC/页
软件工作产品标识号:
____________________________版本号:
_______作者:
_______________
评审员及准备时间:
角色
姓名
准备时间(小时)
评审组长
作者
记录员
评审员
总和
问题记录:
序号
位置
描述
类型
状态
问题项
调查项
未解决
已解决
问题项
调查项
未解决
已解决
修改软件工作产品工作量(小时):
___________________
评审结果:
□通过□再评审
改进建议:
__________________________________________________________________________
__________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
签字:
角色
姓名
签字
评审组长
评审员
6附录C评审通知
主题:
第次评审
期望准备时间:
评审会日期:
开始时间:
持续时间:
评审会地点:
软件工作产品名称:
软件工作产品标识号:
版本号:
作者:
评审组长:
记录员:
其他评审员:
议程:
起止时间
主题
软件工作产品信息:
软件工作产品标识号:
版本:
软件工作产品大小(SLOC/页):
其它支持材料:
遵循标准:
其它:
软件质量保证文档
(项目名称)SQA计划
计划编号:
SQAL:
日期:
版本:
SQAM:
日期:
分册:
PM/SM:
日期:
1.质量目标
质量目标,尽可能用测试的条款表达。
2.SQA组织
2.1SQA组的组成
SQA的成员及资格说明(经验与培训)
2.2SQA职责和权力
2.3SQA组的资源需求
3.SQA任务
3.1规程与标准
明确项目标准和规程,作为SQA评审和审计的基础。
3.2明确质量活动的责任
如检查、审计和测试,配置管理和变更控制,测量和报告,缺陷控制和纠正措施。
3.3阶段划分与任务列表
为每个开发阶段定义入口和出口条件,划分SQA的工作阶段,确定评审与审计的类型,明确SQA作业,可依据项目特点对作业列表进行裁剪与增添。
3.4测试与评估
确定测试的类型,对于产品规范、计划要求、测试规范及采用的开发方法和工具的确认和验证活动;通过详细的测试和验证活动计划,对包括资源、进度和审批等方面进行评估。
3.5全程的偏差跟踪
根据任务列表进行全程偏差跟踪。
4.SQA报告
4.1文档化SQA组的活动结果
软件产品评价报告
软件工具评价报告
项目设备评价报告
过程审核报告
测量报告
4.2提供给软件工程组和其他相关组SQA活动反馈的方法和频率
周报、月报与重要报告等提交的方式与日程(可在计划表中体现)。
5.计划进度表与预算表
序号
任务
完成时间
提交结果
备注
1
2
3
4
5
预算:
软件产品/工具和设备/项目技术评价报告摸板
报告编号:
SQAL:
日期:
SQAM:
日期:
1.软件产品/工具和设备/项目技术评估:
2.评估方法或标准:
3.评估结果:
4.建议纠正措施:
5.实施纠正措施:
过程审计报告模板
报告编号:
主要审计人:
报告日期:
项目名称:
项目编号:
审计项:
审计日期:
审计过程/程序:
审计检查表(附件)
审计结果:
过程/程序可接受
过程/程序有条件的接受
条件说明:
过程/程序不可接受
条件说明:
措施项:
A1#标题责任人预计日期完成日期
纠正措施:
审批:
ë批准ë取消ë推迟
PM:
日期:
验证关闭:
SQAL:
日期:
SQA测量报告摸板
报告编号:
SQAL:
日期:
SQAM:
日期:
软件产品/软件工具/项目设备评估测量
软件产品
规模/形态
评估工作时
报告工作时
软件需求说明
OfPage20
3
1
过程/程序审计测量
软件开发过程
审计准备工作时
审计工作时
报告工作时
纠正措施过程
2
2
1
文档编号:
Test005
版本编号:
V1.00
密级:
中
北京侏罗纪软件开发有限公司
质量控制部文档
XX系统之
xx系统
缺陷报告
XXX系统之
XX系统
缺陷报告
版本1.0
修订历史记录
日期
版本
说明
作者
1.0
首次的缺陷报告
质量控制部
缺陷报告
一.简介
1.1目的
本文档作为《XXX系统》之
A、列出测试活动的主要内容。
B、列出测试活动的测试统计结果。
C、列出系统的主要缺陷。
D、对于缺陷提出的修改建议。
E、由于本系统的某些需求尚未最后确定,目前只能对系统进行部分的功能测试及完全的用户界面测试。
F、本报告为针对测试活动的首次缺陷报告,以后的测试活动还会提交迭代的缺陷报告。
G、本文档提交给项目组的管理者及开发人员审阅。
二.测试内容
下面的列表列出了本次测试活动的主要测试内容。
2.1数据库测试
核实系统是否能访问数据库。
2.2功能测试
核实..
2.3用户界面测试
浏览所有的用例,核实是否每个UI面板都易于理解。
核实界面操作是否简单易行,图形显示是否清晰。
三.测试统计结果及缺陷总结
3.1数据库测试
3.1.1核实系统是否能访问数据库。
3.2功能测试
3.2.1核实是否能够浏览数据库中保存的电子化文档;
3.2.2核实是否能够查找和检索资料;
3.2.3核实是否能够实现资料文件的管理;
3.2.4核实是否能够实现资料文件图片的导入;
3.2.5核实是否能够实现资料文件图片的导出;
3.2.6核实是否能够实现资料的打印输出;
3.2.7核实是否具有灵活的显示模式,如放大、缩小等。
3.3用户界面测试
3.3.1窗口
3.3.2下拉式菜单和鼠标操作
3.3.3数据项
四.针对缺陷提出的建议
4.1功能方面4.2用户界面方面
资源中心验收单(式样)一式三份
序号
编号
成果题名
完成日期
提交日期
页数
密级
保管期限
备注
1
NAVIKENVer2.1
1998-8-21
72
长期
MO盘
2
多媒体办公自动化系统MOAS
1998-12-30
42
长期
磁盘
填表人:
成果管理员:
成果提交人:
卷内成果目录(式样)一式三份
序号
文件编号
责任者
题 名
日期
页次
备注
1
AT97004DP01
李峰
FAX
1997-3-31
1
2
NA504100A
王琛
乐器练习软件功能说明书
1997-4-3
4
3
AT97004SD01
李峰
乐器练习软件概要书
1997-4-3
64
4
NR506100A
王琛
AMORRTVer1.0开发计划
1997-4-25
102
第页/共页
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 产品 合作 流程 程序 文件