软件开发费用.docx
- 文档编号:6063365
- 上传时间:2023-01-03
- 格式:DOCX
- 页数:18
- 大小:79.45KB
软件开发费用.docx
《软件开发费用.docx》由会员分享,可在线阅读,更多相关《软件开发费用.docx(18页珍藏版)》请在冰豆网上搜索。
软件开发费用
`分发号
受控状态
北京四海华辰科技有限公司
SHHC-CX-7.3-01
设计和开发控制程序
(A/0)
2014-07-15发布2014-07-15实施
北京四海华辰科技有限公司发布
文档信息
*文件名称
设计和开发控制程序
*文件编号
SHHC-CX-7.3-01
*文件所有者
产品研发部
*文件密级
□秘密□机密
*颁发部门
□产品研发部_____份□供应链管理部_____份□质量管理部____份
□市场部_____份□销售部_____份□人力资源与行政部_____份
本版批复信息
意见
*签字
*日期
编制
审核
批准
文件版本记录
*生效日期
*作者
*版本
*变更说明
说明:
*项为必需项,不得缺失。
如果“审核意见”及“变更说明”写不下,可以附页说明
设计和开发控制程序
1目的
本程序规定了对本公司设计开发活动的控制要求,以使设计开发过程得到控制,并确保设计输出满足设计输入的要求,设计开发出满足顾客期望和要求的、符合相关法律法规要求的产品。
2适用范围
本程序适用于本公司新产品开发项目和变型设计开发项目的过程控制。
不适用于OEM\ODM项目、技术平台项目的设计开发过程控制。
3术语和定义
3.1项目分类
3.1.1变型设计开发项目
对于已定型并投入生产的产品进行局部设计修改并形成新型号的产品开发项目。
3.1.2新产品设计开发项目
针对新的用户需求进行的产品设计开发项目。
3.2阶段评审
对项目各阶段要实现的一组既定目标是否达到预期要求所作的评审,并做出是否进入下一阶段的决定。
3.3设计评审
设计评审是指对设计开发工作所作的正式的、综合性的和系统性的评审,以评价设计开发的结果是否满足要求,识别任何问题并提出必要的措施。
3.4技术评审
针对开发过程中的一项或几项开发任务,进行评审,检查可交付成果所采用的技术、方案是否能够达到所要求的功能和性能,是否存在缺陷,能否进行改进等。
3.5DMR(DeviceMasterRecord)
产品主文档,包括产品所需的用于支持生产、检验、使用、维护和描述接受准则的文件。
3.6DHF(DesignHistoryFile)
开发过程文件,包含用于描述开发过程而形成的所有文件和记录。
3.7DHR(DeviceHistoryRecord)
设备档案,是依据文件规定的规范和流程,即DMR,生产某一产品的记录,包含制造、装配、调试、检验记录,序列号记录,问题追踪及返工记录,批准放行记录等。
3.8项目组
在《综合开发计划》中确定的跨部门的设计开发所需的人力资源。
架构如图3-1所示:
图3-1
4职责权限
4.1总经理
参与P0、P3阶段评审和批准。
4.2研发总监
参与设计评审和阶段评审,批准并签署《综合开发计划》、《用户需求说明书》、《产品规格说明书》。
4.3项目经理
项目经理是项目组这个跨部门团队的领导,负责制定和实施《综合开发计划》,组织协调项目组内各项工作,控制项目质量、开发进度、开发费用及产品成本。
负责编制《立项申请报告》,批准《设计验证计划》、《设计验证报告》、《设计确认计划》、《设计确认报告》。
4.4市场部产品经理
负责编制《市场调研分析报告》,负责提供用户需求和预期用途等设计输入信息,编制《用户需求说明书》,并关注市场并及时反馈顾客需求的变更,主导需求变更评审。
4.5系统工程师
负责整合设计输入的信息并编制《产品规格说明书》,汇总设计输出并确保完整性。
审核《设计验证计划》、《设计验证报告》、《设计确认计划》、《设计确认报告》、潜在缺陷。
负责系统设计并主导设计工作。
4.6硬件工程师
负责产品的硬件设计开发工作、硬件模块集成调试。
4.7机械结构工程师
负责产品的机械结构、包装、标识设计开发工作、机械模块集成调试。
4.8软件工程师
负责产品的软件设计开发工作、软件模块集成调试。
4.9测试工程师
主导产品的设计验证与设计确认活动,制定《设计验证计划》、《设计确认计划》,编写验证方案,填写验证记录,完成《设计验证报告》、《设计确认报告》。
4.10安全法规工程师
负责提出安全法规要求,主导产品的风险管理活动,制定并更新《风险管理计划》,形成《风险管理报告》。
4.11新品转换工程师(工艺工程师)
负责提出产品可制造性的要求、样机的工艺性审核,参与样机装配,完成工艺文件,制定中试计划,并主导中试过程。
在中试过程中,保证设计输出正确地转换为工艺文件,使得批量生产的产品能够满足设计输出要求,建立和维护制造BOM清单,保证工艺文件的完整性。
负责与生产工程师沟通,以便供应链进行量产的准备。
4.12产品认证/注册工程师
负责提出相关注册和认证的法规要求、与第三方检测机构的联络,协助项目组完成产品注册和认证所需的技术资料,并按要求完成产品注册和认证。
4.13临床应用工程师
负责制定和实施临床评价方案、完成临床试验,协助项目组收集临床对比资料并完成临床评估报告。
协助市场部产品经理完成《用户需求说明书》。
4.14采购工程师
负责协助项目经理制定采购策略,采购样机所需的物料,保证物料的按时齐套,负责新供方的选择和评价。
4.15维修设计工程师
负责收集和研究维修信息,提出可维修性和安装性要求,并对可维修性和安装性进行验证。
负责《使用说明书》、《安装维护手册》、《预安装手册》的编写和维护。
4.16QA工程师
负责组织项目各项评审,监督项目执行,保证设计开发工作符合质量管理体系要求。
5程序
5.1设计开发控制流程
本程序所描述的设计开发控制流程如图5-1所示,它描述了设计开发控制程序中各接口的关系及活动的顺序。
图5-1
5.2开发项目立项
5.2.1市场部产品经理应及时收集和整理市场需求和用户需求,通过分析发现潜在的市场机遇,并结合公司产品线规划提出立项建议,编制《市场调研分析报告》,研发部可结合立项建议对于此项目的技术可行性进行初步判断,对于技术风险可控的项目可以编制《立项申请报告》,报告应包含以下内容:
a)产品概念:
—产品的预期用途;
—目标市场分析,如:
竞争对手分析、市场容量、注册认证法规要求等;
—产品的主要功能、性能及基本结构、产品配置等;
b)BusinessCase
—成本预估;
—市场前景预测;
—经济效益分析;
c)综合开发计划(初稿):
—预期的项目组织架构,职责,权限;
—项目控制和操作机制;
—预期开发时间表;
d)项目风险分析及规避计划;
5.2.2由项目经理提出申请并按照《设计开发评审管理规定》对立项申请进行评审。
立项评审得出通过或有条件通过的结论、《立项申请报告》得到批准标志着本项目启动,并意味着公司对于此项目所需资源的投入做出承诺。
5.3综合开发计划
5.3.1综合开发计划概述了完成项目开发所必需的活动和可交付成果。
每个项目都应建立并维护综合开发计划,并保证计划得到评审和批准。
5.3.2项目的实现依赖于综合开发计划。
项目经理负责建立和整合综合开发计划,核心项目组成员负责提供综合开发计划中所需信息。
综合开发计划至少应包含如下内容:
a)项目范围和项目目的;
b)项目质量目标;
c)项目开发方式;
d)项目组织架构及职责;
e)开发计划;
f)法规策略;
g)项目控制和操作机制;
h)样机和中试计划;
i)软件配置管理计划。
注:
立项评审时《综合开发计划》可以只包含上述d)、e)、g)的内容。
5.3.3项目范围和复杂程度决定着综合开发计划所包含的内容,当核心项目组判定上述内容中某些内容不需要时,应在综合开发计划中对此结论进行充分的说明。
5.3.4综合开发计划需要得到核心项目组成员的评审,并被研发总监批准。
5.3.5在设计开发过程中,需要更新综合开发计划,如实反映已完成的活动,更新后需得到评审和批准。
5.4设计输入
5.4.1设计输入应最大程度地描述与产品有关的所有要求,产品级需求是由用户需求和性能功能需求定义的。
5.4.2市场部产品经理应负责收集整理用户需求和预期用途等信息,并编制《用户需求说明书》,应体现的用户需求如下:
a)预期用途;
b)使用者和患者需求;
c)可用性要求(人机工学、产品易用性);
d)使用环境;
e)产品改进机会(可通过分析以往同类产品的客户抱怨、维修记录等);
f)手册与标识;
5.4.3系统工程师应整合《用户需求说明书》、风险分析结果、性能和功能需求并最终形成《产品规格说明书》。
采纳的设计输入信息应该是得到反复论证和评审后完整并可验证的。
同时应当识别并排除含糊不清、重复的和自相矛盾的要求。
5.4.4系统工程师编制《产品规格说明书》作为设计开发过程的输入,应体现以下内容:
a)产品配置、兼容性、平台;
b)与预期用途相关的功能、性能和安全要求;
c)预期销售的市场要求:
—语言要求
—法律法规要求
d)可生产性、可安装性及可维修性需求;
e)风险分析所得到的风险降低措施;
f)包装、标记和手册要求等。
5.4.5《用户需求说明书》及《产品规格说明书》应得到核心项目组的评审(FDR1),并由研发总监批准。
应保留设计评审的记录,评审记录是DHF的一部分。
5.5设计输出
5.5.1设计输出是一套用于生产、安装、检验、调试、包装、运输、维修和使用的表述产品特性的文件。
5.5.2设计输出应:
a)满足设计输入,即《产品规格说明书》中的要求;
b)给出采购、生产和服务的适当信息;
c)包含或引用产品接收准则;
d)规定对产品的安全和正常使用所必需的产品特性;
e)得到充分的验证或确认;
f)得到审核和批准。
5.5.3设计输出是DMR的一部分,应包含下列等文件:
a)产品及零部件图纸、BOM、CAD文件;
b)外购件规格说明书;
c)软件应用程序、嵌入式软件;
d)为保证产品功能及安全所需的技术要求;
e)包装设计文件;
f)使用说明书、安装维护手册、预安装手册;
g)标识文件。
5.5.4系统工程师对设计输出的完整性负责。
设计文件的完整性应符合《设计文件管理规定》的要求。
5.6设计验证
5.6.1设计验证是通过提供客观证据来证实设计输出满足设计输入的活动。
5.6.2测试工程师负责制定《设计验证计划》,设计验证计划应包含设计验证的策略和方
法,并得到系统工程师的审核和项目经理的批准。
《设计验证计划》是DHF的一部分。
5.6.3设计验证计划中需包含以下部分:
a)设计验证活动的目的、范围;
b)设计输入的要求,应标识《产品规格说明书》上的需求编号;
c)设计验证所需资源,包含所需样品规格等;
d)验证方案等。
5.6.4验证方案中应描述如何验证设计输出是否满足设计输入的要求,验证方案可独立形成文件并被设计验证计划引用。
5.6.5验证方案中需包含如下要素:
a)《产品规格说明书》中所有的要求;
b)使用的测试设备和设备的校准有效期;
c)验证步骤和方法;
d)每一测试项的通过条件。
5.6.6可采取的验证方式有:
a)测试和试验;
b)变换方法计算;
c)与已经证实的设计进行比较(应记录以往设计的完整数据和采取此方法的理由)。
5.6.7测试工程师依据验证方案进行验证并记录结果。
以下信息作为设计验证的客观证据需要记录:
a)用于验证的设计输出的识别方式,如序列号、文件号、版本等;
b)采取的验证方式;
c)验证方案;
d)测试人员签署;
e)测试设备,其中监视和测量仪器需记录校准有效期;
f)任何用于测试的软件及仿真工具,需要得到授权或确认;
g)验证结果;
h)结果判定(通过或不通过)。
设计验证过程中发现的任何与《产品规格说明书》不一致的验证结果,均需要记录、处理并通过缺陷管理进行关闭。
5.6.8在第三方检测前需要对检测样机进行自测,并保留相关验证记录和验证报告,作为DHF进行管理。
第三方检测结果可以作为设计验证的一部分。
5.6.9测试工程师将依据设计验证计划进行验证后得到的结果汇总成《设计验证报告》,并基于验证结果得出结论。
《设计验证报告》应由系统工程师审核并由项目经理批准,作为DHF进行保存。
5.6.10设计验证结束后,项目组应依据《设计评审管理规定》组织召开设计评审(FDR2),设计评审记录做为DHF的一部分进行保存。
5.7设计转换
5.7.1在设计开发与设计验证阶段,新品转化工程师应参与样机的生产,并在设计验证完成评审(FDR2)前主导完成:
a)DMR中除设计文件外的其余文件,包含:
─工艺流程图;
─作业指导书;
─配置单;
─检验作业指导书等。
b)中试计划,应包含以下信息:
─范围、策略、方式及时间表;
─职责权限;
─物料采购计划;
─验收准则;
─验证可制造性的计划及方案;
─验证可安装性的计划及方案;
─验证可维修性的计划及方案等;
其中维修设计工程师负责可安装性验证及可维修性验证部分的内容。
5.7.2在设计验证完成评审(FDR2)时需由核心项目组对DMR和中试计划进行评审,并由项目经理批准执行。
5.7.3设计验证完成评审(FDR2)通过后,由新品转化工程师依据中试计划进行中试的各项工作。
5.7.3.1新品转化工程师负责实施中试计划,并确保:
a)依据制造工艺可生产出满足要求的产品;
b)采购流程能够交付满足要求的零部件;
c)工装、卡具及测量设备适用于产品生产且产品满足要求;
d)每一台设备形成了DHR。
5.7.3.2维修设计工程师负责实施中试计划中安装与维修部分,并确保安装与服务过程:
a)可以依据《安装维护手册》的描述实现;
b)安装维修工具和设备适用于产品的安装和维修。
5.7.4中试完成的标志是:
a)中试阶段出现的缺陷已得到审核和分类;
b)出现的重大缺陷、主要缺陷已得到处理、验证和关闭;
c)DMR中发现的问题已进行修改和完善;
d)依据中试计划及DMR生产出首台满足要求的设备。
注:
安装流程可以在典型的室内模拟环境进行。
5.7.5设计转换完成后,项目组应依据《设计评审管理规定》组织召开设计评审(FDR3)。
设计评审的记录做为DHF的一部分进行保存。
5.8设计确认
5.8.1设计确认是通过提供客观证据证实产品满足用户需求及预期用途的活动。
5.8.2设计确认活动应在满足临床需求的样机上进行。
设计确认需要在其预期使用的真实环境或者模拟环境下进行,并应当证明:
a)该产品满足《用户需求说明书》中的要求;
b)《使用说明书》清晰明了。
5.8.3测试工程师负责编制设计确认计划,并在设计确认开始前得到系统工程师的审核和项目经理的批准。
设计确认计划中应包含:
a)设计确认活动的目的和范围;
b)产品的预期用途及用户需求,即《用户需求说明书》中的要求;
c)产品配置及附件,并记录不同配置的差异性;
d)完成设计确认活动所需资源;
e)设计确认方案等。
5.8.4设计确认方案应包含:
a)需要确认的用户需求或预期用途;
b)所需的试验设备和仪器;
c)确认步骤;
d)每个确认方案的接收准则。
5.8.5测试工程师依据《设计确认计划》进行设计确认并保留记录,以下信息需作为证实材料予以保留:
a)用于设计确认的产品或设备的鉴别码,如序列号、版本等;
b)实施设计确认的方法;
c)相关的设计确认方案;
d)确认人员签署;
e)所使用的试验设备、工具及软件;
f)客观结果;
g)结果判定:
通过或者不通过;
h)总结。
5.8.6当国家或其他国家和地区法规要求进行下列临床评价时,按相应的法规进行:
a)临床试验;
b)与所设计和开发的医疗器械相关的科学文献的分析;
c)能证明类似设计在临床上是安全的历史证据。
当需要进行临床评价时,设计确认计划中应包括临床评价计划,临床应用工程师负责临床评价计划的实施。
5.8.7测试工程师应当汇总设计确认的结果,形成《设计确认报告》,并得到系统工程师的审核及项目经理的批准,做为DHF进行保存。
5.8.8设计确认完成后,项目组应依据《设计评审管理规定》组织召开设计评审(FDR3)。
设计评审记录做为DHF的一部分进行保存。
5.9设计评审
5.9.1设计评审是设计开发过程中在定义的评审点通过对设计开发的可交付成果进行的系统评审,以便:
a)评价设计和开发的结果满足要求的能力;
b)识别任何问题并提出必要的措施。
5.9.2综合开发计划中设计评审点应设置如下:
a)完成设计输入及策划时(FDR1);
b)完成设计验证时(FDR2);
c)完成设计确认及设计转换时(FDR3)。
5.9.3设计输入及策划完成评审(FDR1)应评审以下内容:
a)设计输入是否充分和适宜;
b)综合开发计划是否合理可行;
c)关键供方及关键部件是否识别;
d)安全风险评估是否考虑充分。
5.9.4设计验证完成评审(FDR2)应评审以下内容:
a)DMR是否完整;
b)设计验证是否按验证计划进行;
c)验证结果是否能够证实产品满足设计输入要求;
d)中试计划与设计确认计划是否合理可行;
e)设计输入是否有变更并被评审和考虑;
f)综合开发计划是否更新;
g)发现的缺陷是否得到适当的处理和关闭,采取的措施是否适当;
h)风险降低措施是否有效等。
5.9.5设计确认及设计转换完成评审(FDR3)应评审以下内容:
a)设计转换是否按计划进行并完成;
b)设计确认是否按计划进行并完成;
c)设计确认的结果是否满足产品的预期用途;
d)综合开发计划是否更新;
e)发现的缺陷是否得到适当的处理和关闭,并更新DMR;
f)风险降低措施的有效性等。
5.9.6系统工程师可以依据情况增加需评审的内容。
5.9.7设计评审活动依据《设计开发评审管理规定》的要求进行,各评审点的可交付成
果依据《评审输入检查表》的要求进行准备,评审的记录应当做为DHF进行保存。
5.10阶段评审
5.10.1阶段评审是为了更好的控制项目开发过程以确保开发的产品符合市场预期,同时便于跨部门活动的协调。
阶段评审通过,标志着项目开发可以进入下一阶段,项目开发周期的三个阶段及各阶段评审点的设置如图5-1所示。
5.10.2立项评审(P0)的目的是:
a)确定市场需求和符合用户及市场需求的产品概念;
b)确定产品定位、优先级;
c)评估项目风险及收益;
d)评估项目所需资源。
5.10.3策划评审(P1)应评审以下内容:
a)设计输入是否定义明确并被评审;
b)已识别的主要风险是否被规避或已制定降低风险措施;
c)综合开发计划是否满足立项要求。
5.10.4设计验证完成评审(P2)应评审以下内容:
a)确认设计验证活动已完成,并证明设计输出满足设计输入;
b)确认DMR已经完成。
5.10.5临床启动评审(PE)应评审以下内容:
a)确认临床样机已经完成,并经过测试已符合临床要求;
b)临床所需材料已经完备;
5.10.6产品发布评审(P3)应评审以下内容:
a)确定设计确认活动已完成;
b)确定设计转换活动已完成;
c)确定市场发布前批量生产能力已具备。
5.10.7产品发布评审(P3)批准后,代表产品正式上市,可投入市场销售。
5.10.8阶段评审活动依据《设计开发评审管理规定》的要求进行,各评审点的可交付成
果依据《评审输入检查表》的要求进行准备。
评审的记录应当做为DHF进行保存。
5.11需求管理
5.11.1设计输入应在项目开发周期内保持完整性和一致性,并在设计输入及策划评审(P1)后得到控制。
5.11.2当设计输入需要变化时,应对提出的需求进行评估后确定是否导入新的需求,评估的方面可包含以下内容:
a)预期用途的变化;
b)产品规格的变化;
c)对已完成的开发阶段的输出的影响;
d)成本变化;
e)开发周期变化;
f)对后续活动的影响程度,等。
基于设计输入的变化,项目经理应组织项目组成员依据评估结果及时更新相关的开发过程文件(不得晚于下一个FDR前完成更新)并依据更新后的文件开展后续的项目工作。
5.11.3新增的设计输入如果影响到预期用途或用户需求应对相关变化重新进行设计确认,如果影响产品规格性能和功能应对相关变化重新进行设计验证,并依据《开发过程文件管理规定》的要求保留相关记录。
5.12设计更改
5.12.1产品设计开发过程中,需对已经评审和批准的文件进行修改时,应按该文件的评审和批准的要求对修改内容进行评审和批准。
5.12.2设计文件发布后的设计更改控制依据《设计更改控制程序》进行。
5.13风险管理
在产品寿命期内,按《风险管理控制程序》进行风险管理活动,形成的相关记录和文件作为DHF保存。
5.14开发过程文件(DHF)
5.14.1每个项目都应建立并保存开发过程文件,开发过程文档需包含以下内容:
a)综合开发计划及更新;
b)用户需求说明书及更新
c)产品规格说明书及更新;
d)开发过程中的技术文档;设计验证相关文件和记录;
e)中试计划及更新;
f)设计确认相关文件和记录;
g)设计评审记录;
h)风险管理相关文件和记录等。
5.14.2项目经理应在《综合开发计划》中制定开发过程文件的编制策略,需对省略、合并和引用的开发过程文档进行说明,并确保其按计划实施及完整性。
5.15缺陷管理
5.15.1缺陷管理适用于追溯在产品上市发布前的设计、测试、中试等过程中发现的设计缺陷。
一个设计缺陷是指一个存在不可接受临床风险或者是一项不满足设计输入的设计输出。
设计缺陷可能是不满足:
a)用户需求和预期用途;
b)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 费用
![提示](https://static.bdocx.com/images/bang_tan.gif)