电脑设备及软件管理控制程序

电脑设备及软件管理控制程序
电脑设备及软件管理控制程序

风险管理控制程序文件

风险管理控制程序 1.目的 为建立风险和机遇的应对措施,明确包括风险应对措施风险规避、风险降低和风险接受在的操作要求,建立全面的风险和机遇管理措施和部控制的建设,增强抗风险能力,并为在质量和环境管理体系中纳入和应用这些措施及评价这些措施的有效性提供操作指导。 2.围 本程序适用于在公司质量和环境管理体系活动中应对风险和机遇的方法及要求的控制提供操作依据,这些活动包括: a. 业务开发、市场调查及客户满意度测评过程的风险和机遇管理; b. 供应商评审和采购控制过程的风险和机遇管理; c. 生产过程的风险和机遇管理; d. 过程检验和监视测量设备的管理过程的风险和机遇管理; e. 设备的维护和保养管理过程的风险和机遇管理; f. 不合格品的处置及纠正预防措施的执行和验证过程的风险和机遇管理; g. 持续改进过程的风险和机遇管理; h. 当适用时,也可适用于对公司管理过程中应对风险和机遇的控制提供操作指南。 3.职责 3.1总经理:负责风险管理所需资源的提供,包括人员资格、必要的培训、信息获取等。负责风险可接受准则方针的确定,并按制定的评审周期保持对风险和机遇管理的评审。 3.2安环部:负责建立风险和机遇应对控制程序,并进行维护。负责按本文件所要求的周期组织实施风险和机遇的评审,落实跟进风险和机遇评估中所采取措施的完成情况并跟进落实措施的有效性,并编写《风险和机遇评估分析报告》,负责本部门的风险评估及应对风险的策划和应对风险措施的执行和监督。 3.3各单位:负责本部门/科室的风险和机遇评估,并制定相应的措施以规避或者降低风险并落实执行。 3.4经营部:负责收集产品售后的风险信息及本部门的风险识别,负责制定相应的措施以规避或者降低风险并落实执行。

服装公司监视和测量装置管理工作程序

服装公司监视和测量装置管理工作程序-制度大全 服装公司监视和测量装置管理工作程序之相关制度和职责,1.目的为确保所使用的测量仪器的精准度,满足各阶段检验与测量结果的准确性,以保证产品的质呈:。2?适用范用本公司内用于产品质星判定的全部量规、仪器设备。3.职责3.1使用部门负责... 1.目的 为确保所使用的测量仪器的精准度,满足各阶段检验与测量结果的准确性,以保证产品的质量。 2.适用范围 本公司内用于产品质量判定的全部疑规、仪器设备。 3.职责 3.1使用部门负责疑规仪器设备之申购、使用。 3.2质管部负责量规仪器设备之汇总记录,定期内校或送检。 4.工作程序 4.1量规仪器申购 4.1.1 部门依工作需要,提岀量规仪器设备申请报设备部,制立设备购垃汁划,具体依《采 购控制程序》执行。 4.1.2新购量规仪器交货时,由设备部及质管部对量规仪器做验收,验收时应参考国家或国 际标准之校验仪器方法,或要求厂商交提供合法之校验证明。 4.1.3验收合格之量规仪器设备,由质管部记录在“量规仪器一览表”,确左检验周期后,即可交由使用部门正常使用。 4.2校验方式 4.2.1内部校验:由公司内部训练合格之校验人员执行校验,其检验系统应依据国家或国际计量标准。 4.2.2送外校验:由国家认可的校验单位或仪器设备的供应商执行校验,英校验系统应依据国家或国际标准。 4.3校验分类管理 校验技术员依据量规仪器设备之使用状况及精准度要求确左内部校验或送外校验,并记录于"量规仪器一览表"。 4.4内校流程 4.4.1校验技术员根据校验周期通知使用部门送校。 4.4.2软尺验证方法 将标准钢尺平放于平台上,被验证软尺测量点起始刻度与标准钢尺0刻度重合,软尺抹平即可,在软尺英寸和厘米两面总长度范围内取12"、24"、36"三个测量点,和30CM、60CM、90CM 三个测量点与标准钢尺读值比对数值差异,任何一个测量点相对数值偏差不超过±0.5%为合格。计算公式如下: (被测量点读数-标准钢尺读数片标准钢尺读数xlOO% 4.4.3直尺、木尺等验证方式与软尺相同。 4.4.4电子秤验证方法 将电子秤宜于水平台而上,秤盘内不可放苣物品,将电子秤读数校正为零,置50g.100g.500g

软件配置管理控制程序A0

程序文件 软件配置管理控制程序 文件编号 版木A0 贞数第1贞共6贞 編制部门研发部 生效日期2018年09月05日 修改页 文件编号修改条款修改内容修改人/日期生效日期全文首次发行 分发部门会签 编制审核批准□业务部□研发部□采购部□生产韶□质量部□行政部

软件配置管理控制程序 软件配這皆理贯穿于软件整个生命周期,对规范软件版本、源代码、文件、工具、现成软件等控 制要求,确世配置标识、变更控制、配置状态记录等活动要求。使用配置管理工具保证软件质量使公 司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 适用于本公司所有的软件项目,并贯穿于软件生存周期全过程。 3.1项目经理 负责指过配置管理人员: 负责审批配置管理il ?划; 负责执行配置管理il 划。 3. 3质量部 > 负责跟踪配置管理il ?划的实施。 4.1术语泄义 软件配置管理:是标识和确定系统中配置项的过程,在系统整个生存周期内控制这些项的投放和变更, 记录并报告配置的状态和变更要求,验证配置项的完整性和正确性。 软件配置项:为配置管理的目的而作为一个单元来看待的硬件/软件成分。 基线:一组拥有唯一标识号的需求、设计、源代码文件以及柑应的可执行代码、构造文卷和用户文档 构成一条基线。基线一经放行,就可以作为从配置管理系统检索源代码文卷(配苣项〉和生成可执行 文卷的工具" 4.2配置管理讣划编制 所有项目在指;4^项目开发计划时,都应有项目经理指定配置管理人员,然后由配置管理人员编写 《配置管理计划》,也可以包含在《软件开发计划中》,配置管理讣划至少应包括的内容: ? 配置管理人员的组成及分工 2. 范围 3. 职责 3.2 配置管理人员 4. 工作程序

软件设计和开发控制程序

公司软件设计和开发控制程序 1目的 对软件设计和开发全过程进行控制,确保产品设计和开发能满足顾客和有关标准、法令、法规的要求。 2范围 适用于软件产品设计和开发的全过程,包括软件产品的升级。 3职责 3.1软件研发部负责组织编制《项目实施计划书》、《需求规格说明书》、《软件概要设计说明书》、《详细设计说明书》、设计和开发输出文件、测试报告、验收报告等,负责组织协调和实施软件产品的设计和开发工作。 3.2软件研发部产品组负责根据市场调研分析或合同提交《可行性研究报告》。 3.3软件研发部测试组负责软件产品的确认测试。 3.4 由各业务部负责将合格软件产品交付顾客使用。 3.5 公司总经理签署《项目经理任命书》,正式启动软件项目。 3.6公司技术总工或授权人负责设计和开发立项《项目实施计划书》、《需求规格说明书》、验收报告等的批准。 4工作程序 4.1 设计和开发策划 4.1.1立项的依据 软件研发部对要进行的开发项目进行立项申请,提交项目资料。由公司的有关人员对项目进行一系列的风险评估。通过风险评估的项目,由软件研发部进行详细进度计划安排,落实时间进度、资源(人员/设备、内部/外部)、技术、资金和费用等,相关资源和资金使用计划要详细列出。 最后所有的项目申请资料、风险评估报告及产品进度计划都要报给公司上级领导审批,进行立项评审。 立项通过的项目才能由软件研发部进入正式的开发工作。 4.1.2 软件研发部项目经理负责就以上立项依据组织《项目实施计划书》的编制。

4.1.3设计和开发人员资格要求可参照本公司相关岗位卡的条款进行. 4.1.4 接口管理 4.1.4.1 在设计和开发策划和输入阶段: a.各业务部将客户相关文件资料交与软件研发部,同软件研发部一起对《需求规格说明书》进行评审; b.软件研发部编制《项目实施计划书》,经公司技术总工或授权人批准后发往客户方。 c.软件研发部项目经理将《项目实施计划书》、《需求规格说明书》及相关背景资料,提供给各设计和开发人员,作为工作的依据。 4.1.4.2 在设计和开发输出阶段,软件研发部项目经理根据设计和开发进度,适时召开设计和开发例会,组织解决设计和开发中遇到的困难,协调相关的资源,以例会记录的形式明确相关要求。 4.1.4.3 在设计、编码、测试阶段: a.进行总体设计、详细设计的设计人员及进行编码的程序员须充分沟通.必要时,可由项目经理负责召开设计和开发专题会议,并以会议记录的形式明确与会人员达成的一致意见。 b.软件研发部设计和开发人员提供单元和综合测试的《测试计划》,交本部门的相关设计和开发人员进行集成并由测试人员进行单元、综合测试。 c.软件研发部提供确认测试的《测试计划》,交测试组进行系统安装、测试。 4.1.4.4设计和开发各阶段 a.软件研发部项目经理负责就技术方面在客户与程序员之间进行协调; b.软件研发部经理负责组织和协调各有关单位的工作; c.各业务部负责与客户的业务联系及相关信息传递; d.参与设计和开发的各部门将必要的信息形成文件,经部门经理评审签字后予以传递. 4.2设计和开发输入 4.2.1《项目经理任命书》经公司总经理批准后,由软件研发部经理组织编写《项目实施计划书》、《需求规格说明书》,其中《项目实施计划书》须由公司技术总工组织人员评审。 4.2.2软件研发部经理组织软件设计和开发人员、测试人员及各业务部等设计和开发提出部门(包括客户),对《需求规格说明书》进行评审,对其中不完善、含糊或矛盾的需求做出澄清和解决.4.2.3《需求规格说明书》在接受合同时可以不完全确定,在项目进行期间可继续制定。当《需求规格说明书》更改时,合同可以修订,对《需求规格说明书》的更改将按照《软件配置管理规程》程序加以控制。 4.3 设计和开发输出 4.3.1各设计和开发人员根据《项目实施计划书》及《需求规格说明书》的要求进行设计和开发活动,并形成相应的文档。 4.3.2设计和开发的输出应形成文件,但不限于以下文档: ——《软件概要设计说明书》;

量规仪器管理条例

量规仪器管理条例 一、目的: 为有效保障产品品质,维护量规仪器的使用寿命及精度,特作 以下管理规定。 二、范围: 针对各类仪器、衡器、卡尺、千分尺、螺纹栓(牙)规,等仪器设备。 三、权责: 各部门量具保管及使用人、部长及量具管理员、采购、仓库。 四、内容: 1.采购管理: 1.1各部门需请购量规仪器,由请购部门写请购单,注明精度、规格,请购部门确认知后会仪校,仪校作记录,核实数量 再转采购核准,办理采购事宜。 1.2新购量规仪器到货后,仓库应及时通知仪校检验,验收合格后将量具领出。 2.入库管理: 2.1采购量规仪器入库,仪校将验收合格之量具作好档案,打好编号后同入库单一起入库到工具仓,由工具仓统一管 理。 2.2员工自离、辞工等量具入库,凡有量具的员工辞工、自离、开除在办理离厂手续时量具必须退仪校,仪校校正合格 后入库到工具仓。 3.领用管理: 3.1各部门领量规仪器,须开具领料单(领料单须注明使用人),部门部长、经理确认后于工具仓处领取。一联给仪校, 以便建档责任人。

3.2各部门新进人员,技管员及以上人员、作业员未满一个月 不得领用量规仪器,如有需要,可借用本部门其他人之量 规仪器,个人领用、借用之量规仪器须妥善保管,若有损 坏或丢失,部门应及时提报,仪校会按公司相关制度处理。 3.3各部门员工自离、辞工等重新入库量具,原则上仍然发放原部门。 3.4贵重量具由部门部长以上人员保管。 4.报废管理: 4.1遗失及不正常报废:各单位遗失量具或不正常损坏报废者,由仪校开报废申请单(注明处罚方式及金额以备查验)、 罚款单经使用部门部长、经理确认签字后,再由仪校将 量规仪器报废单、罚款单影印到工具仓销帐,《量规仪器 报废单》由仪校存档,违者罚款50元/次。 4.2正常报废:各单位因正常使用,精度达不到使用要求需报废时,由仪校开报废申请单连同零件完整之报废量具, 并由总经理室核准后,由仪校统一向工具仓销帐,工具 仓以量规仪器报废单及零件完整之报废量具销帐,量规 仪器报废单由仪校存档。违者罚款50元/次。 5.使用管理: 5.1使用前: 5.1.1检查此量规仪器之校验标签是否已到校正期。 5.1.2检查此量规仪器之指示装置是否在正确位置,即零位是否相一致。 5.1.3检查量规仪器是否有仪校提供之修正参数,若有测量时应加修正值。 5.2使用中:

12.风险管理控制程序

1 目的 为避免或降低生产、办公设备及软件侵犯他人知识产权的风险,识别本公司生产经营活动中的知识产权,并对其进行识别、评测等级,以制定有效的控制措施。 2 范围 适用于本公司生产经营活动中的所有知识产权的风险管理。 3 职责 3.1 行政部负责组织各部门进行知识产权风险的识别,并形成《知识产权风险识别台 账》,并对风险源进行等级评测。 3.2 行政部负责定期监控产品可能涉及他人知识产权的状况,分析可能发生的纠纷及其 对企业的损害程度,并提出相应的防范预案。 4 程序 4.1 知识产权风险的识别 4.1.1 知识产权风险的识别范围包括生产经营、人力资源、信息资源、办公设备及软件中 的所有知识产权。 4.1.2 风险识别应包括: 4.1.2.1研发活动中的风险 研发活动是企业推出新产品获取市场竞争优势的基础环节,在研发项目的立项、 研发路线的确定、研究成果的保护等不同阶段都涉及到知识产权风险,包括以下 项目: a)在研发立项论证时未进行专利信息的详细检索,导致辛辛苦苦投入大量经费,自 主开发获得的研发成果却不能使用,否则就构成侵权; b)研发完成时,开发出的新技术或产品不进行有效保护,导致被限制使用的风险; c)产学研合作中企业的知识产权权属未能得到明确规范,导致自树竞争对手的风险。 4.1.2.2生产活动中的风险 a)企业在生产过程中涉及的知识产权包括:专利、商标、计算机软件、商业秘密, 如专有技术、加工工艺、生产设备改进方案、生产信息、采购 b)与加工合同、生产控制软件等。 c)企业在采购过程中,需要对供应商及所采购产品的知识产权状况进行评价与确定, 必须要求供应商提供涉及材料的知识产权权属证明。在外协生产的过程中,需对 采购过程中涉及的知识产权进行协商,明确代工过程的知识产权权责。 d)对新技术、新产品的使用,特别是企业独家定制的原材料和设备等,必须明确供

软件配置管理控制程序

配置管理控制程序 版本号修订内容编制人审阅人日期

历史记录

目录

1.引言 1.1目的 本程序文件定义了本组织的配置管理的过程,目的是规范公司的软件配置管理活动,使公司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 1.2 使用范围 本文件适用于公司的所有软件项目。 1.3 名词和缩写 CM(Configuration Management) 配置管理 SCCB (Software Configuration Control Board) 软件配置管理控制委员会 CC (Configuration Controller) 配置管理员 工作产品(Work Products):项目技术开发和管理工作中产生的有价值的成果,例如源代码、数据和各种文档。 配置项(Configuration Item, CI):纳入到配置管理范畴作为单个实体对待的工作产品称为配置项[IEEE Std 610.12 - 1990 ];配置项包括:项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据,它们经评审和检查通过后进入软件配置管理。 基线(Baseline):一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。基线一经放行,就可以作为从配置管理系统检索源代码文卷(配置项)和生成可执行文卷的工具。

2角色与职责 2.1软件配置管理组(CM) CM组是项目里的一个小组,根据项目大小,可以由一个人,或者多人组成,小组的成员称为配置管理员(CC),通常由公司的质量保证组安排,加入到项目组,由项目经理领导。 CM组建立并管理配置管理库系统。 CM组负责组织相关部门和人员进行有关CM活动的培训。 项目组的CM组负责在该项目的整个生命周期中进行配置管理活动。 2.2软件配置管理控制委员会(SCCB) SCCB建立在项目级,通常由项目经理、该项目的技术经理、软件开发工程师、资深工程师、测试经理/测试工程师以及CC组成。SCCB在项目策划阶段由项目经理负责筹建。 配置管理控制委员会负责审批软件配置管理计划; 配置管理控制委员会负责审批软件基线的建立; 配置管理控制委员会负责审批对软件基线配置项的变更; 配置管理控制委员会负责审核和批准产品发布。 2.3 SCCB负责人 SCCB负责人通常由项目经理担任,代表SCCB在有关文件上签署意见。 2.4 项目经理 定期或事件驱动地评审或审核CM活动。 2.5 测试组 负责审核《配置管理计划》任务列表中与测试有关的内容 2.6 开发组 负责审核《配置管理计划》任务列表中与开发有关的内容 2.7 QA组 负责审核《配置管理计划》任务列表中与QA有关的内容

软件配置管理控制程序

配置管理控制程序

历史记录

1.引言 1.1目的 本程序文件定义了本组织的配置管理的过程,目的是规范公司的软件配置管理活动,使公司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 1.2使用范围 本文件适用于公司的所有软件项目。 1.3名词和缩写 CM(Co nfiguration Ma nageme nt)配置管理 SCCB (Software Con figuration Con trol Board) 软件配置管理控制委员会 CC (Co nfiguratio n Con troller) 配置管理员 工作产品(Work Products):项目技术开发和管理工作中产生的有价值的成果,例如源代码、数据和各种文档。 配置项(Configuration Item, CI):纳入到配置管理范畴作为单个实体对待的工作产品称为配置项[IEEE Std 610.12 - 1990 ];配置项包括:项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据,它们经评审和检查通过后进入软件配置管理。 基线(Baseline): 一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。基线一经放行,就可以作为从配置管理系统检索源代码文卷(配置项)和生成可执行文卷的工具。

2角色与职责 2.1软件配置管理组(CM ) CM组是项目里的一个小组,根据项目大小,可以由一个人,或者多人组成,小组的成员称为 配置管理员(CC),通常由公司的质量保证组安排,加入到项目组,由项目经理领导。 CM组建立并管理配置管理库系统。 CM组负责组织相关部门和人员进行有关CM活动的培训。 项目组的CM组负责在该项目的整个生命周期中进行配置管理活动。 2.2软件配置管理控制委员会(SCCB) SCCB建立在项目级,通常由项目经理、该项目的技术经理、软件开发工程师、资深工程师、 测试经理/测试工程师以及CC组成。SCCB在项目策划阶段由项目经理负责筹建。 配置管理控制委员会负责审批软件配置管理计划; 配置管理控制委员会负责审批软件基线的建立; 配置管理控制委员会负责审批对软件基线配置项的变更; 配置管理控制委员会负责审核和批准产品发布。 2.3 SCCB负责人 SCCB负责人通常由项目经理担任,代表SCCB在有关文件上签署意见。 2.4项目经理 定期或事件驱动地评审或审核CM活动。 2.5测试组 负责审核《配置管理计划》任务列表中与测试有关的内容 2.6开发组 负责审核《配置管理计划》任务列表中与开发有关的内容

量规仪器管理规定

1.0 目的: 确立本公司之仪器校正程序以确保所有用作计量的仪器都在正确和良好的应用状态; 2.0 范围: 应用对于质量检查和测试仪器校正的仪器包括: A)量具(量度尺寸、重量等工具) ; B)检查或测试仪器; C)如有使用计算机软件用作检验、测量和试验也作为检验、测量和试验仪器统一处理. 3.0 职责: QC负责全力推行及维持这一程序。 4.0 定义: 4.1外校:因仪器基准件与能力因素而委托外界机构代为校验本公司之检测仪器 设备者; 4.2内校:由公司内部具有仪器校正资格的人员自行校验者; 4.3基准件:用作进行内部校正之基准仪器或设备,基准件须经制造商或外部之认可机构校 正。 5.0 相关文件 5.1【采购管理程序程序】 5.2【校正要求】 6.0 仪器校正与管理 6.1 仪器的选择与校正。 6.1.1 仪器校正责任人员根据公司产品精度要求,合理选择检查、校正和测试仪器。 由使用部门填写〖购物申购单〗并经总经理批准后方能采购。 6.1.2仪器校正责任人员按个别仪器之类别,对各种仪器配上独立编号,并建立全公司〖仪 器清单〗。 6.1.3仪器校正责任人员按属于仪器的要求,决定是否需要校正或注明为参考使用,所有 需校正的仪器要在〖仪器清单〗上注明,并记载校正日期及再校正日期。 6.1.4 需检定的仪器可按仪器校正责任人员编写之仪器【校正要求】进行校正 (包括校 正方法和环境要求),其检定要求考虑如下: A)客户要求; B)仪器特性; C)产品规格; D)国家标准; E)检定周期; 6.1.5QC按仪器【校正要求】进行校正,亦可聘用厂外计量所进行校正,但 亦应符合公司的仪器检定要求或认可国家标准:如没有认可标准存在, 其校正应根据客户的要求并结合公司的实际情况进行指定或其制造 商的标准进行校正; 6.1.6所有经校正的仪器需填写〖校正报告〗,经仪器管理负责人签署审核才 可使用; 6.1.7经仪器校正责任人员审核合格或经量计所校正合格的仪器应贴上[合格 标签] ; 参考使用之仪器也需贴上[参考使用] 标签,但不得直接使 用在产品性能方面的检验之中; 6.1.8 一经调校正确的仪器,仪器校正责任人员须确保仪器在正常条件下运

仪器内校管理控制程序

1.目的 对测量、检测、试验等仪器进行有效管理,以确保其测量精度满足使用要求,确保测量、检测、试验等仪器处于良好的运行状态。 2.范围 适用于本公司所有影响产品品质的测量仪器、量具和试验设备。 3.定义: 3.1免校:不直接影响产品品质或仅供参考时用。 3.2外校:使用部门将需外校的仪器交品质部汇总后送国家认可的实验室校准。 3.3内校:公司测量室检定出尺寸报告,检验周期根据使用频率而定。 4. 职责 4.1 仪器管理员:负责校验、修理、请购、验收。 4.2 仪器清洁保养:使用部门。 5.工作程序 5.1.请购、验收之管理 5.1.1.相关部门根据需求,所需仪器设备提出申请。 5.1.2.新购仪器设备需由校准人校验并纳入校验系统,经审查合格后,统一列管。 5.2. 仪器编号 品管部编写厂内统一编号并记录制造商,型号机身编号使用单位建立《测量仪器清单》并调校合格后,再交给使用部门。 5.3 仪器管理 5.3.1各部门应保持本部门所用仪器完好及不超出校正周期。应依仪器使用说明书或规定使用并做适当保养。 5.3.2仪器设备应列台帐,内容包括:仪器名称、仪器编号、规格型号,校正方式,校正周期及保管部门等。 5.3.3仪器设备故障,在修理或更换后,必须经过校准人确认精确度,方可使用。 5.3.4如有丢失、损坏、失准应及时报告品管部。 5.3.5仪器设备停止使用或报废 5.3.5.1.使用者在使用过程中,如发现仪器设备误差范围超过要求范围,应及时通知校准人并停止使用。 5.3.5.2.校准人对仪器设备进行修复、校验,如无法修复应通知使用部门做报废处理。 5.3.5.3.停止使用和报废仪器设备应注明报废原因及日期,并贴上暂停使用标签和报废标签。 5.3.5.4.报废仪器设备应及时填写报废单并重新申购。报废品应当隔离,以不误用为原则。 5.4 仪器校验 5.4.1 校准人负责保管厂内仪器并定期送往国家认可之校验单位校验,追溯国家标准;并以此工作标准件依年度计

风险和机遇的应对控制程序

风险和机遇的应对控制程序 Q/- CX-15-2017 1 目的 为建立风险和机遇的应对措施,明确包括风险应对措施风险规避、风险降低和风险接受在内的操作要求,建立全面的风险和机遇管理措施和内部控制的建设,增强抗风险能力,并为在质量环境安全管理体系中纳入和应用这些措施及评价这些措施的有效性提供操作指导。 2 范围 本程序适用于在公司质量环境安全管理体系活动中应对风险和机遇的方法及要求的控制。 3 职责 3.1管理者代表:负责风险管理所需资源的提供,包括人员资格、必要的培训、信息获取等。负责风险可接受准则方针的确定,并按制定的评审周期保持对风险和机遇管理的评审。 3.2综合部:负责建立风险和机遇应对控制程序,并进行维护。负责按本文件所要求的周期组织实施风险和机遇的评审,落实跟进风险和机遇评估中所采取措施的完成情况并跟进落实措施的有效性。 3.3各部门:负责本部门的质量环境安全的风险和机遇评估,并制定相应的措施以规避或者降低风险并落实执行。 4 工作程序 4.1风险和机遇管理策划 为全面识别和应对各部门在生产和管理活动中存在的风险和机遇,各部门应建立识别和应对的方法,确认本部门存在的风险,并将评估的结果记录在《风险和机遇评估分析表》。 在风险和机遇的识别和应对过程中,责任部门应对可能存在风险的车间、生产过程和人员存在的风险进行逐一的筛选识别。 4.2建立风险/机遇 风险识别活动的开展应是一次团体的活动,各部门在进行风险识别和评估过程中应通过集思广益和有效的分析判断下进行的。各部门的职责: a.实施风险和机遇分析和评估;

b. 制定风险和机遇应对措施并落实执行; 综合部组织实施风险应对措施的实施效果验证。 管理者代表对风险和机遇分析和评估审核,审核措施的实施效果验证情况。 4.3风险评估 对已识别的风险的严重度和发生频度进行评价,其评价的要求应依据本程序所规定的评价准则进行评价确认,风险的严重度和发生频度的确认用以确定风险系数,之后根据风险系数确定对风险应采取的措施。 4.3.1风险的严重程度评价准则 风险严重度用于评价潜在风险可能造成的损害程度,根据对潜在风险的评估量化,若潜在风险发生后,其会导致的各方面的影响以及危害程度。 在对风险进行严重程度判定时,推荐扩大分析风险所带来的危害层面,以便于更有效的对潜在的风险采取措施,以达到减少或部分消除风险乃至完全消除的目的。 为便于识别风险所带来的危害程度,对风险的严重程度进行区分,风险严重度分为以下五类: a. 非常严重 b.严重 c.较严重 d. 一般 e. 轻微 下表为依据定义的风险影响和影响程度的多少进行量化,在对风险的 严重度判定过程中,当多个因素的判定其严重程度不一致时,应遵循从严原则进行判定,即当多个因素中仅其中一个或部分因素其严重度级别更高时,依据严重级别高的因素作为风险严重度进行判定。根据上表内容确定风险的严重度后,将严重等级数字填入《风险和机遇评估分析表》中。 4.3.2风险的发生频率评价准则 风险的发生频率是指潜在风险出现的频率,为便于识别和定义,将风

软件开发管理程序(精)

软件开发管理程序 1. 目的 为了提高软件开发的质量, 保证软件开发项目按预定的时间和费用顺利完成,提高软件过程的成熟度。 2. 适用范围 本程序适用于本公司所有软件项目开发过程的管理 , 可根据项目的大小及实际情况进行适当的删减。 3. 定义 可行性分析:对系统的技术可行性、经济可行性和社会可行性进行研究。 需求分析:真正搞清楚所要设计的软件应该具有哪些功能和特性 (即要让它做什么事。 数据字典:对数据流程图中出现的所有数据元素给出逻辑定义。概要设计:根据软件需求说明书的要求,建立目标系统的总体结构和模块间的关系,设计全局数据库/数据结构,定义各功能模块的接口、控制接口等。 详细设计:对概要设计中产生的功能模块进行过程描述,设计功能模块的内部细节,为编写源代码提供必要的说明。 测试计划:为做好集成测试和验收测试,需为如何组织测试制定实施计划。计划包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 编码与单元测试 : 将详细设计说明书转化为相应的程序设计语言或 数据库语言书写的程序,对该程序的所有模块进行测试。

4. 职责 4.1项目经理:在可行性分析阶段,组织可行性分析小组,项目通过可行性评审后编写《项目开发计划书》。在需求分析阶段,组织需求分析小组, 保证需求分析进度。在程序设计阶段, 组织概要设计小组, 组织详细设计小组,进行编码分工,监管编码规范。在项目进行的整个过程中要填写《项目进度月报》。 4.2可行性分析小组:对项目进行可行性分析并形成《可行性分析报告》。 4.3可行性评审小组:对可行性分析小组提交的《可行性分析报告》进行评审,形成《评审表》。 4.4需求分析小组:对业务需求进行分析,编写《软件需求说明书》和《数据要求说明书》。 4.5需求分析评审小组:根据软件正式技术复审规范对需求分析小组提交的《需求分析报告》 ,进行评审,形成《评审表》。 4.6概要设计小组:根据《软件需求说明书》和《数据要求说明书》进行概要设计, 编写《概要设计说明书》、《数据库设计说明书》和《数据字典》。 4.7概要设计评审小组:对《概要设计说明书》、《数据字典》和《数据库设计说明书》进行评审,出《评审表》。 4.8详细设计小组:根据《概要设计说明书》、《数据字典》和《数据库设计说明书》进行详细设。

质量风险管理控制程序完整版

质量风险管理控制程序 Document serial number【NL89WT-NY98YT-NC8CB-NNUUT-NUT108】

质量风险管理控制程序 1 目的 对可能影响到最终产品和服务质量的风险和机遇进行确定和评估,制定行之有效的应对措施,为公司在运营和决策中有效应对各类突发事件和风险提供支持和保障,更好地实现公司质量方针和目标。 2 范围 本程序适用于公司质量管理体系的风险和机遇的确定、评估和应对的管理。 3 定义 风险:在一定环境下和一定限期内客观存在的、影响企业目标实现的各种不确定性事件。 机遇:对企业有正面影响的条件和事件,包括某些突发事件等。 风险评估:在风险事件发生之前或之后(但还没有结束),该事件给各个方面造成的影响和损失的可能性进行量化评估的工作。即风险评估就是量化测评某一事件或事物带来的影响或损失的可能程度。 风险规避:风险规避是风险应对的一种方法,是指通过有计划的变更来消除风险或风险发生的条件,保护目标免受风险的影响。 风险降低:通过采取措施以达到降低风险的效果。一般情况下,若采取的措施能够有效的降低所遭受的风险,应将采取措施的记录进行保留或者写入文件进行归档,以便后期重复发生时作为改善的依据。 风险接受:是指企业承担风险造成的损失。风险接受一般适用于那些造成损失较小、重复性较高的风险、最适合于自留的风险事件。 内部风险:企业内部形成的风险,例如战略决策风险、环境风险、财务风险、管理风险、经营风险等。 外部风险:由外部影响因素导致的风险,例如政策风险、市场需求风险和业务风险等。 风险严重度:风险发生后其所产生的影响的严重程度。 风险发生频度:风险出现的频率或者概率。 风险系数:风险系数用于评定是否对已识别的风险采取措施,风险系数=风险严重度×风险发生频度。 4 职责

软件开发控制程序文件

软件开发控制程序文件 1 目的 1.1 对软件开发的全过程进行控制,确保产品能满足用户需求和期望及 有关法律、法规要求。 2 范围 2.1适用于本公司软件新产品开发全过程的控制。 3 职责 3.1技术部负责软件开发全过程的组织、协调、实施工作,包括进行开发 的策划、确定开发的组织和技术的接口、输入、输出、验证、评 审,设计开发的更改和确认等。 3.2技术部经理负责审核软件开始输出文件和成果。 3.3技术部经理负责审核项目可行性研究报告、项目开发方案,下达开发 任务书,负责批准项目开发计划、开发输入、开发输出、开发评 审、开发验证、确认和软件更改等。 3.4总经理负责批准项目可行性研究报告、项目开发方案。 3.5采购部负责所需物料的采购。 3.6技术部负责根据合同要求,负责提交用户使用新产品后的《验收报 告》。 3.7技术部负责控制新产品的质量保证能力。 4 程序 4.1软件开始的策划 根据“软件生存周期”的阶段划分,这属于“可行性研究与计划阶段”。

4.1.1软件开发项目的来源: a. 根据市场部与用户签定的新产品合同或技术协议,总经理批 准的相应的《项目可行性研究报告》、《产品要求评审 表》、技术部经理下达《软件开发任务书》,并将与新产品 有关的技术资料转交软件开发人员。 b. 市场部根据市场调研或分析提出《项目可行性研究报告》, 报技术部经理审核、总经理批准后,技术部经理下达《软件 开发任务书》,并将相关背景资料转交软件开发人员。 c. 技术部综合各方面信息,提交《项目可行性研究报告》,报 技术部经理审核、总经理批准后,技术部经理下达《软件开 发任务书》,交软件开发人员实施。 d. 技术部经理制定的科技发展规划:包括新产品计划和已有产 品的重大升组级计划(如平台更换、重大技术改造等)。 4.1.2项目负责人根据上述项目来源,确定项目负责人,根据《软件开发 任务书》将软件开发策划的输出转化为《项目开发计划》,报技 术部经理审核、批准。计划书内容包括: a.开发输入、输出、评审、验证、确认等务阶段的划分和主要工作内容; b.各阶段人员职责和权限、进度要求和配合单位; c.产品及成果、验收标准; d.资源配置需求,如人员、设备、资金保证及支持务件等及其他相关内容等。 4.1.3软件开发策划的输出文件将随着设计开发的进展,在适当进予以修 改,应执行《文件控制程序》关于文件更改的有关规定。 4.1.4软件开发不同小组之间的接口管理 a. 软件开发的不同小组可能涉及到公司不同职能或不同层 次,也可能涉及到公司外部。 b. 对于小组之间重要的软件开发信息沟通,软件开发人员填

公司风险管理控制程序文件

风险管理控制程序 1.0 目的 通过对公司所有设计和生产的医疗器械在其寿命期内的各个阶段的风险因素及水平进行分析,采用适宜的管理方法控制和降低风险水平。 2.0范围 适用于本公司设计和生产的医疗器械在其寿命期内的各个阶段的风险管理。 3.0 职责 3.1 技术部: a..负责编制《风险管理计划》,并按计划和《风险管理控制程序》规定的内容和要求对风险实施管理和控制。 b. 负责根据产品在设计开发阶段组建风险管理小组,建立产品风险管理档案。 C. 风险管理小组成员负责编制风险管理过程中的文件和记录,项目负责人负责审核风险管理过程中的文件和记录。 D. 技术部经理负责批准风险管理过程中的文件和记录,并向总经理报告风险管理和评价的结果。 3.2 办公室(质量体系管理部门): a.负责各部门之间与风险管理有关的资料和信息的传递。 b.负责风险管理过程控制的监督、检查和评审。 3.3 各部门: 参与评价风险水平,实施与本部门有关的风险管理各项方案,监控实施的有效性。3.4 销售部: 负责收集产品销售后的风险信息,并及时反馈或传递至办公室。 3.5总经理 a.负责风险管理所需资源的提供,包括人员资格、必要的培训、信息获取、研究试验所需经费等。 b.负责风险可接受准则方针的确定。 C.按计划的间隔保持对风险管理的评审。 4.0工作程序 4.1人员资格: 所有从事风险管理工作的执行者应具有和赋予他们的任务相适应医疗器械及其应用的

知识和经验,以及具有风险管理技术知识。必要时应培训。 4.2风险管理过程的基本流程(见图一): 图一用于产品风险管理活动的框图 4.3 风险管理计划 4.3.1 对于一个医疗器械项目,技术部负责按照风险管理过程编制《风险管理计划》,该项

某软件公司维护管理控制程序

维护管理 文件编号: NP510100 生效日期: 2000.3.20 受控编号: 密级:秘密版次:Ver2.1 修改状态:总页数8 正文 5 附录 3 编制:刘栋臣审核:孟莉、王宇批准:孟莉 沈阳东大阿尔派软件股份有限公司 (版权所有,翻版必究)

文件修改控制 目录 1. 目的 2. 适用范围 3. 职责 3.1项目管理部门 3.2技术支撑部门 3.3 开发部门 4. 术语和缩略语 5. 工作程序 5.1基本要求 5.2维护类型 5.3 维护计划 5.4 维护实施 5.5 维护记录 6. 引用文件

7. 质量记录 7.1 NR510100A“维护服务需求说明” 7.2 NR510100B“维护计划” 7.3 NR510100C“维护记录”

1.目的 对交付后的维护管理进行有效控制,确保维护服务顺利、有效实施。 2.适用范围 适用于本公司所提供的软件和/或系统集成项目交付后的维护服务。 3.职责 3.1项目管理部门:负责受理交付后的维护申请,组织协调有关部门实施维护。 3.2技术支撑部门:负责组织实施软件产品和/或系统集成项目交付后的维护。 3.3开发部门:负责软件项目或软件产品的开发性维护。 4.术语及缩略语 本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。 5.工作程序 5.1 基本要求 维护范围和维护期限必须在合同中明确规定,维护服务应严格按合同执行。 5.2 维护类型 1)纠错性维护:解决软件运行过程中出现的故障; 2)适应性维护:由于运行环境的改变而调整软件的接口; 3)完善性维护:根据客户的要求对现有软件产品进行功能扩充或性能改进。 4)硬件产品的维护。 其中,前三种维护又称开发性维护。 5.3 维护需求 5.3.1 根据客户的要求或合同中对维护服务的规定,客户提出维护需求说明,并由客户 和维护部门进行确认。 5.3.2 根据确认的维护需求,可与客户约定维护的实施办法,共同制定维护计划。维护 计划应包含以下内容: 1)维护范围:指合同中规定的维护项或公司确认的由客户提出的特殊维护要求。 一般情况下维护范围包括计算机程序、文档及相应的硬件系统等。 2)产品初始状态标识:是指系统安装完成后,由双方共同确认的系统初始状态,

风险管理控制程序

1、目的 对产品的风险管理做出规定,通过此规定识别与产品有关的危险(源),估计和评价风险,控制这些风险,并监控控制的有效性,从而确保公司生产的产品按预期用途使用时,对病人和使用者的风险降低到可接受水平。 2、适用范围 适用于公司开发和生产的产品在医疗器械寿命周期的所有阶段的风险管理。 3、术语、缩略语 本程序采用质量手册以及YY/T 0316-2016、ENISO14971:2012/AC:2012中的术语、缩略语。 4、职责和权限 4.1企业负责人 1)提供充分的资源及授权有资格人员参与风险管理,任命风险管理小组组长以及成员; 2)规定一个确定风险可接受性准则的方针并形成文件,此方针应确保准则是基于适用的国家或地区法规和相关的标准,并考虑可用的信息; 3)按照计划的时间间隔评审风险管理过程的适宜性,以确保风险管理过程的持续有效性,并且将任何决定和采取的活动形成文件; 4)批准风险管理报告。 4.2风险管理小组组长 1)负责进行风险管理全过程的实施; 2)规定风险管理小组中各成员的职责和权限; 3)在适当的场合对产品进行风险分析,风险评价和风险控制,提出风险降低措施和对措施实施情况进行验证,并形成风险管理报告,报企业负责人审批; 4)同时对生产后的信息进行定期或不定期的评审,判断再次进行风险分析、评价和控制的必要性,必要时应组织产品的临床应用人员参加;

5)保管风险管理文档。 4.3风险管理小组 风险管理小组应由各部门熟悉产品原理、功能、制造以及相关法律法规的成员组成,具有有关的技术或风险管理技术与赋予任务相适应的知识和经验,负责相关产品信息的提供和风险降低措施的实施。 5、工作程序 5.1风险管理的应用场合 风险管理即对产品的开发、生产、销售、使用等各个环节中出现的影响产品安全性和有效性的风险进行风险分析和风险评价,提出风险降低措施并予实施、验证从而将风险降低到可接受水平的一系列管理活动。其主要适用于以下场合: 5.1.1新产品和有重大变更型号规格变更品的设计开发过程中可分为三个部分:设计风险的风险管理、过程风险的风险管理、使用风险的风险管理。 1)设计风险是指在设计输入时应考虑的产品设计中的可能存在的风险; 2)过程风险是指在设计输出时应考虑的产品试制或生产过程中可能存在的风险; 3)使用风险是指在设计确认时应考虑的产品被患者使用时的可能存在的风险。 5.1.2对产品生产后的信息进行定期或不定期地评审,从而实施的风险管理活动,包括: 1)通过市场监督、市场调查及顾客投诉等发现了新的风险; 2)产品认证或体系认证等场合所必需进行的产品回顾性风险分析; 3)应国家法律法规的变化及新技术、新材料应用要求的过程中发现了新的风险; 4)定期评审(一般每年1次)中发现了新的风险。 以上风险管理活动由技术部和/或有临床背景的专家等相关人员根据情况及时进行。 5.2管理职责 企业负责人应在下列方面对风险管理过程的承诺提供证据: 1)确保提供充分的资源; 2)确保给风险管理分配有资格的人员; 3)规定一个确定风险可接受性准则的方针并形成文件,此方针应确保准则是基于适用的国家或地区法规和相应的标准,并考虑可用的信息。 注:公司在制定质量方针时应考虑风险可接受性准则,并将其融入质量方针中。 4)按照计划的时间间隔评审风险管理过程的适宜性,以确保风险管理过程的持续有效性,并且将任何决定和采取的活动形成文件。

某某软件公司文件管理控制程序

文件管理 文件编号: NP602100 生效日期: 2000.3.20 受控编号: 密级:秘密版次:Ver2.1 修改状态:总页数9 正文 6 附录 3 编制:李民审核:孟莉批准:孟莉 沈阳东大阿尔派软件股份有限公司 (x,翻版必究)

文件修改控制

目录 1. 目的 2. 适用范围 3. 职责 4. 术语和缩略语 5. 工作程序 5.1 文件控制范围 5.2 文件的编号 5.3 质量体系文件的控制 5.4 其它文件的控制 5.5 文件的保管 5.6 文件的网上发布 6. 引用文件 6.1 NP602200《信息管理》 6.2 NW602101《文件编写导则》 6.3 NW602102《文件编号规定》 7. 质量记录 7.1 NR602100A“文件发行审批表” 7.2 NR602100B“文件修改申请与记录单” 7.3 NR602100C“文件发行控制表”

1.目的 通过规定文档的编制、审查、发布、更改和收回废除必须遵守的过程,确保相关部门得到有效的文件。 2.适用范围 本程序适用于质量体系文件,以及软件开发产品和/或服务的过程中产生的文档管理。 注:质量体系文件、软件开发产品和/或服务过程中产生的文档,以下统称文件。 3.职责 3.1 质量保证部门:负责组织质量体系文件的编制、发放和更改控制。 3.2项目管理部门:负责技术文档发行及更改控制。 3.3相关部门:负责各自部门的专用文档及资料的编写、更改。 4.术语和缩略语 本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。 5.工作程序 5.1 文件控制范围 5.1.1质量体系文件,其分类为: 1)质量手册 2)程序文件 3)支持性文件:包括作业指导文件、技术规范及有关资料。其中:作业指导文件指在执行程序文件时参考的具体作业文件;技术规范指在软件产品开发过 程中应遵守的技术准则及规定。 5.1.2所有本公司质量活动的计划和进展及与客户相互配合的计划性文档。 5.1.3描述一个具体软件产品或软件项目的技术文档和用户文档,包括 ——开发阶段输入/输出; ——验证和确认的计划和结果; ——提供给客户的文档; ——维护文档。

相关文档
最新文档