软件研发控制程序完整优秀版.docx
《软件研发控制程序完整优秀版.docx》由会员分享，可在线阅读，更多相关《软件研发控制程序完整优秀版.docx（20页珍藏版）》请在冰豆网上搜索。
软件研发控制程序完整优秀版
类型：
程序文件
编号：
CFD/QP-15
名称：
软件研发控制程序
性质：
受控
版本：
1.0
状态：
待批
文档校对：
所有者：
成都福地科技股份
日期：
2002-4-22
版本
作者
日期
改动描述
1.0
2002-4-22
创建
1目的
为保证软件产品及其文档可维护，软件开发过程得到有效控制，使公司能够根据市场需求或客户要求，以合理的成本尽快地生产出高质量的产品或提供高质量的服务，特制定本程序。
2适用范围
本程序文件适用于公司所有软件项目的开发过程的控制活动。
3定义
在本程序中部分定义如下：
UML：
即统一建模语言，它是一种对软件密集型系统的制品进行可视化、详述、构造和文档化的语言。
用例：
是能够向用户提供有价值结果的系统中的一种功能。
构架：
对以下一系列重要问题的决策的总和：
软件系统的组织；对组成系统的结构元素、接口以及这些元素在协作中的行为的选择；由这些结构和行为元素组合成更大的子系统的方式；用来指导将这些元素、接口、它们之间的协作以及组合等组织起来的构架风格。
迭代：
按照专门的（迭代）计划和评估标准产生一个（内部或外部）发布版本所进行的一组明确的活动。
增量：
系统中一个较小、可管理的部分，通常指两次相邻的构造之间的差异。
工件：
是流程的工作产品，角色使用工件执行活动，并在执行活动的过程中生成工件，分为输入工件和输出工件。
里程碑：
项目阶段结束的标志，在该标志处，满足了一组明确定义的目标，并生产出了相应的制品，并可作为管理层做出决策的依据。
4职责
项目经理：
负责制订《项目计划》，分配资源，确定优先级，协调项目内外各方的关系，控制项目进度，确保项目工件的完整性和质量，并保证项目计划的实施和完成。
配置经理：
负责为产品开发团队提供全面的配置管理（CM）基础设施和环境。
CM的作用是支持产品开发行为，使开发人员和集成员有适当工作区来构建和测试其工件，并且使所有工件均可根据需要包含在部署单元中。
配置经理还必须确保CM环境有利于进行产品复审、更改和缺陷跟踪等活动。
配置经理还负责撰写《配置计划》并汇报基于“变更请求”的进度统计信息。
系统分析员：
通过概括系统的功能和界定系统来领导和协调需求获取及用例建模，并负责构造《用例模型》。
用例描述人员：
通过描述一个或几个用例的需求状况以及其他支持软件的需求，详细说明系统功能某一部分的规约。
用户界面设计员：
分析对用户界面的需求，构建用户界面原型，制订项目《用户界面指南》,邀请用户界面的其他涉众（如最终用户）参与可用性复审和使用测试会议，对用户界面的最终实施方案（由设计员和实施员等其他开发人员创建）进行复审并提供相应的反馈。
构架设计师：
负责在整个项目中对技术活动和工件进行领导和协调，并制订《编程制南》和《设计指南》
设计员：
负责定义一个或几个类的职责、操作、属性及关系，并确定应如何根据实施环境对它们加以调整。
实施员：
负责按照项目所采用的标准来进行构件开发与测试，以便将构件集成到更大的子系统中。
集成员：
负责制订《集成计划》，并负责在集成工作区将构件组合起来，生成一个工作版本。
测试设计员：
负责制订《测试计划》和构造《测试模型》，执行测试过程，评估测试范围和测试结果，以及测试的有效性，并生成《测试评估摘要》。
测试员：
负责执行测试，评估测试执行过程并修改错误。
文档编写员：
负责制作最终用户支持材料，包括《用户指南》、《帮助文本》、《发布说明》。
必须对项目相关人员进行资格鉴定，鉴定时按《人力资源控制程序》执行。
5工作程序
本程序规定的过程分为先启、精化、构建和产品化四个阶段。
每个阶段又细分为多次迭代过程。
每次迭代过程都包括业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理和环境九个核心工作流程。
如下图所示：
5．1先启阶段
5．1．1进入条件
项目已经立项，并得到公司相关领导和部门的评审通过。
软件项目的提出可以由客户直接提出，IT及软件事业部以《市场分析报告》提出，也可以由相关部门以《内部工作申请表》提出。
不管以何种方式提出的需求，都必须由IT及软件事业部为主，协调相关部门进行评审：
●充分性：
市场占有情况预测；
●必要性：
成本分析；
●广度：
盈利程度预测；
●深度：
可行性分析
5．1．2目标
●建立项目的软件规模和边界条件。
●识别系统的关键用例。
5．1．3核心活动
●明确地说明项目规模。
这涉及了解环境以及最重要的需求和约束，以便于可以得出最终产品的验收标准。
●计划和准备商业理由。
评估风险管理、人员配备、项目计划和成本/进度/收益率折衷的备选方案。
●综合考虑备选构架，评估设计和自制/外购/复用方面的折衷，从而估算出成本、进度和资源。
此处的目标在于通过对一些概念的证实来证明可行性。
该证明可采用可模拟需求的模型形式或用于探索被认为高风险区域的初始原型。
先启阶段的原型设计工作应该限制在确信解决方案可行就可以了-该解决方案在精化和构建阶段实现。
●准备项目的环境，评估项目和组织，选择工具，工具的选择和控制参照《软件开发工具控制程序》。
5．1．4里程碑
里程碑：
生命周期目标。
核心工件
里程碑状态
前景
已经对核心项目的需求、关键功能和主要约束进行了记录。
商业理由
已经确定并得到了批准。
风险列表
已经确定了最初的项目风险。
软件开发计划
已经确定了最初阶段及其持续时间和目标。
软件开发计划中的资源估算（特别是时间、人员和开发环境成本）必须与商业理由一致。
资源估算可以涵盖整个项目直到交付所需的资源，也可以只包括进行精化阶段所需的资源。
此时，整个项目所需的资源估算应该看作是大致的“粗略估计”。
该估算在每个阶段和每次迭代中都会更新，并且随着每次迭代变得更加准确。
根据项目的需要，可能在某种条件下完成了一个或多个附带的“计划”工件。
此外，附带的“指南”工件通常也至少完成了“草稿”。
迭代计划
第一个精化迭代的迭代计划已经完成并经过了复审。
产品验收计划
完成复审并确定了基线；随着其他需求的发现，将对其在随后的迭代中进行改进。
用例建模指南
确定了基线。
词汇表
已经定义了重要的术语；完成了词汇表的复审。
用例模型（主角，用例）
已经确定了重要的主角和用例，只为最关键的用例简要说明了事件流。
5．1．5评估标准
生命周期目标里程碑评估项目的基本可行性。
●对是否已经获得正确的需求集达成一致意见，并且对这些需求的理解是共同的。
●对成本／进度估算、优先级、风险和开发流程是否合适达成一致意见。
●已经确定所有风险并且有针对每个风险的减轻风险策略。
5．2精化阶段
5．2．1进入条件
项目经评审，已经达到先启阶段的生命周期目标里程碑，并经项目经理批准进入精化阶段。
5．2．2目标
●确保构架、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定完成开发所需的成本和进度。
●处理在构架方面具有重要意义的所有项目风险
●建立一个已确定基线的构架，它是通过处理构架方面重要的场景得到的，这些场景通常可以显示项目的最大技术风险。
●证明已建立基线的构架将在适当时间、以合理的成本支持系统需求。
●建立支持环境。
5．2．3核心活动
●快速确定构架、确认构架并为构架建立基线。
●根据此阶段获得的新信息改进前景，对推动构架和计划决策的最关键用例建立可靠的了解。
●为构建阶段创建详细的迭代计划并为其建立基线。
●定位开发环境，包括支持构建团队所需的工具和自动化支持。
●改进构架并选择构件。
评估潜在构件，充分了解自制/外购/复用决策，以便有把握地确定构建阶段的成本和进度。
集成了所选构架构件，并按主要场景进行了评估。
5．2．4里程碑
里程碑：
生命周期构架
核心工件
里程碑状态
原型
已经创建了一个或多个可执行构架原型，以探索关键功能和构架上的重要场景。
风险列表
已经进行了更新和复审。
新的风险可能是构架方面的，主要与处理非功能性需求有关。
软件构架文档
编写完成并确定了基线，如果系统是分布式的或必须处理并行问题，则包括构架上重要用例的详细说明（用例视图）、关键机制和设计元素的标识（逻辑视图），以及（部署模型的）进程视图和部署视图的定义。
设计模型（和所有组成工件）
制作完成并确定了基线。
已经定义了构架方面重要场景的用例实现，并将所需行为分配给了适当的设计元素。
已经确定了构件并充分理解了自制/外购/复用决策，以便有把握地确定构建阶段的成本和进度。
集成了所选构架构件，并按主要场景进行了评估。
通过这些活动得到的经验有可能导致重新设计构架、考虑替代设计或重新考虑需求。
数据模型
制作完成并确定了基线。
已经确定并复审了主要的数据模型元素（例如重要实体、关系和表）。
实施模型（以及所有组成工件，包括构件）
已经创建了最初结构，确定了主要构件并设计了原型。
前景
已经根据此阶段获得的新信息进行了改进，对推动构架和计划决策的最关键用例建立了可靠的了解。
软件开发计划
已经进行了更新和扩展，以便涵盖构建阶段和产品化阶段。
指南，如设计指南和编程指南。
使用指南对工作进行了支持。
迭代计划
已经完成并复审了构建阶段的迭代计划。
用例模型（主角，用例）
用例模型（大约完成80%）-已经在用例模型调查中确定了所有用例、确定了所有主角并编写了大部分用例说明（需求分析）。
补充规约
已经对包括非功能性需求在内的补充需求进行了记录和复审。
5．2．5评估标准
生命周期构架里程碑为系统构架建立管理基线，并使项目团队能够在构建阶段调整规模。
●产品前景和需求是稳定的。
●构架是稳定的。
●可执行原型表明已经找到了主要的风险元素，并且得到妥善解决。
●构建阶段的迭代计划足够详细和真实，可以保证工作继续进行。
●构建阶段的迭代计划由可靠的估算支持。
●所有涉众一致认为，如果在当前构架环境中执行当前计划来开发完整的系统，则当前的前景可以实现。
●实际的资源耗费与计划的耗费相比是可以接受的。
5．3构建阶段
5．3．1进入条件
项目经评审，已经达到精化阶段的生命周期构架里程碑，并经项目经理批准进入构建阶段。
5．3．2目标
●通过优化资源和避免不必要的报废和返工，使开发成本降到最低。
●快速达到足够好的质量
●快速完成有用的版本（Alpha版、Beta版和其他测试发布版）
●完成所有所需功能的分析、开发和测试。
●迭代式、递增式地开发随时可以发布到用户群的完整产品。
这意味着描述剩余的用例和其他需求，充实设计，完成实施，并测试软件。
●确定软件、场地和用户是否已经为部署应用程序作好准备。
●开发团队的工作实现某种程度的并行。
5．3．3核心活动
●资源管理，控制和流程优化
●完成构件开发并根据已定义的评估标准进行测试
●根据前景的验收标准对产品发布版进行评估。
5．3．4里程碑
里程碑：
最初操作性能
核心工件
里程碑状态
“系统”
可执行系统本身随时可以进行“Beta”测试。
部署计划
已开发最初版本、进行了复审并建立了基线。
实施模型（以及所有组成工件，包括构件）
对在精化阶段创建的模型进行了扩展；构建阶段末期完成所有构件的创建。
测试模型（和所有组成工件）
为验证构建阶段所创建的可执行发布版而设计并开发的测试。
迭代计划
已经完成并复审了产品化阶段的迭代计划。
设计模型（和所有组成工件）
已经用新设计元素进行了更新，这些设计元素是在完成所有需求期间确定的。
数据模型
已经用支持持续实施所需的所有元素（例如，表、索引、对象关系型映射等）进行了更新
补充规约
已经用构建阶段发现的新需求（如果有）进行了更新。
用例模型（主角，用例）
已经用构建阶段发现的新用例（如果有）进行了更新。
5．3．5评估标准
最初操作性能里程碑确定产品是否已经可以部署到Beta测试环境。
●该产品发布版已足够稳定和成熟，可部署在用户群中。
●所有涉众已准备好将产品发布到用户群。
●实际的资源耗费与计划的相比可以接受。
汽车基地
●
5．4产品化阶段
5．4．1进入条件
项目经评审，已经达到构建阶段的最初操作性能里程碑，并经项目经理批准进入产品化阶段。
5．4．2目标
●进行Beta测试，按用户的期望确认新系统
●市场营销、进行分发和向销售人员进行新产品介绍
●与部署相关的工程
●调整活动，如进行调试、性能或可用性的增强
●根据产品的完整前景和验收标准，对部署基线进行的评估
●在涉众之间达成共识，即部署基线已完成
●在涉众之间达成共识，即部署基线与前景的评估标准一致
5．4．3核心活动
●执行部署计划
●对最终用户支持材料定稿
●在开发现场测试可交付产品
●制作产品发布版
●获得用户反馈
●基于反馈调整产品
●使最终用户可以使用产品
5．4．4里程碑
里程碑：
产品发布
核心工件
里程碑状态
产品工作版本
已按照产品需求完成。
客户应该可以使用最终产品。
帮助文件
完成。
安装工件
完成。
用户手册
完成。
项目评估报告
完成。
5．4．5评估标准
●用户是否满意
●实际的资源耗费与计划的耗费相比是否可以接受
5．5配置与变更管理
参见《软件配置控制程序》
5．6质量管理
参见《软件质量控制程序》
6相关文件
《人力资源控制程序》
《软件开发工具控制程序》
《软件配置管理程序》
《软件质量管理程序》
7记录
《前景》
《商业理由》
《风险列表》
《软件需求规约》
《软件开发计划》
《迭代计划》
《产品验收计划》
《测试计划》
《项目进度报告》
《构架描述》
《用例模型》
《分析模型》
《设计模型》
《实现模型》
《用户手册》
《阶段评审报告》
《项目评审报告》
场所安全控制程序
1、目的：
为加强公司内部的场所安全控制，防止未经许可的人员、货物进入,特制订本控制程序。
2、适用范围
适用于公司内部的一切物理、财产、人员安全控制活动。
3、职责
企发部、人力行政部共同主导公司内部一切场所安全控制活动的策划及维护.
4、工作程序
4.1建筑结构
4．1.1厂房周围应建筑安装混凝土、红砖或钢筋结构的围墙或围栏,围栏和围墙的顶部装设尖锐的铁刺或玻璃片，以防止外来人员非法侵入。
4。
１．2厂房围墙适当位置应配置有保安室,派驻保安人员2４小时驻守或巡逻,车辆、人员进出的大门应设置保安室。
4。
１．3所有建筑物都应当保证建筑结构的牢固,能够抵抗非法的进入和外界的侵扰，即不允许使用临时替用物料。
4．1.4所有门窗、大门和围栏都必须牢固,且需要关闭或上锁，除非需要打开进行接收和付运作业。
4。
1.5企发部应每半月安排专人对建筑物、门窗、围栏、灯具、锁具等进行检查，确保其完好有效.如有破损、失效的，应及时安排人员进行维修或修缮,并作好维修记录。
４．2安全维护
４。
2．1公司沿厂房围墙设置３个出入口及保安室.其中厂区大门为车辆、人员日常进出通道；其余两个出入口为临时性（备用）通道。
4.2.２厂区大门使用电动伸缩门，平时保持关闭。
保安室由保安人员2４小时值班驻守，以检查和监控进出的车辆、人员，防止非法侵入和流出.
4.2。
3其余两个大门平时上锁,仅在厂区大门故障、维修或有特殊需要时作为车辆、人员进出口通道使用.保安室不派驻长期保安,由保安人员定时巡逻签到,以保证安全。
４.２.４公司应配备充足的保安人员，对厂区内所有区域进行２4小时驻守或定时巡逻,以保障厂区内部安全。
公司应对保安人员巡逻进行工作规划，制订厂区保安巡逻路线图,由保安人员按巡逻路线图进行定时巡逻，并签到记录巡逻情况.
4．2.6保安人员巡逻过程中,发现有异常情况的，应及时向保安队长汇报;如有必要的,保安队长应及时向部门主管汇报;情况紧急的,应即时采取措施进行处置。
4.2。
7巡逻过程中，如发现有可疑人员或车辆闯入的，应现场进行人员身份、车辆证件盘查，并检查携带物品。
如情况严重的,应扣留当事人或车辆,并报警处理。
４.3灯光照明
４．3.１办公、生产、生活区域需安装充足的照明灯光和应急灯具，尤其是办公室、生产车间、仓库、宿舍楼、楼梯间、主要通道等区域,以保障正常工作和生活需要,及确保在发生紧急情况时，便于人员紧急撤离和逃生。
4.３.2围墙周边、停车场、货物装卸区、视频监控区及其他重要区域,应安装充足的照明灯光，以保证夜间的充足照明及视频监控需要。
４．3。
3夜班保安人员应视各区域的照明需要,及时开关各区域的夜间照明灯光。
灯具异常、灯光不足的,应及时报告保安队长联络人员处理.
4．4视频监控系统
４．4。
1厂区出入口、货物装卸区、货车停放区、成品仓库、财务部、围墙周边和停车场需安装视频监控系统，实现区域全覆盖，防止未经许可的人员、车辆进入或接近。
４。
４.2系统需配套有稳定可靠的不间断电源，保证24小时正常使用，并连续不间断地进行全天候监控和摄录.
4.4。
3系统控制设备需存放在专用设备控制室,指定专业人员负责日常维护和管理,非授权人员不得进入和操作。
4。
4．4系统的监控记录资料至少保存一个月，由专业人员负责保管；未经许可,不得删除、复制和外泄。
４。
４。
5如发生未经许可的人员、车辆异常进入等安全事故需调取监控记录资料的,须由人力行政部主管指定专人负责复制和查阅。
4.4．6系统需定期由专业人员进行测试维护，以确保正常使用。
系统使用过程中发生异常的，保安人员应及时向负责系统管理的专业人员反馈，以便及时维修保养。
4.５区域隔离
４．5。
1货物装卸区、货车停放区、公司小车停放区、外来车辆停放区应分开划设,并设置有明显标识,以防止车辆停放混乱.
4。
5．２公司内部各类车辆、外来车辆均应按规划分类分区有序停放；外来车辆进入厂区时，保安人员应提醒或引导停放。
货物临时存放区、进出口货物通道、成品仓库等区域应配套隔离设施，并设置明显标识和警示标语,以防止、提醒未经许可的人员进入。
４。
5.4隔离设施应用牢固的砖墙、铁网、围栏等建筑、制作,门窗可上锁,以防止未经许可的人员、货物进出;区域负责人员离开时，应关闭门窗或上锁。
4．５.５货物装卸过程中,装卸区域内不准未经许可的人员及车辆进入.
4。
5。
6仓库等区域应由专人负责管理,除仓运课、关务课人员外未经许可不得随意进入；如因工作需要进入仓库的,必须在仓库进行登记并在仓库管理人员的陪同下方可进入。
4．５.7物流部、财务部办公区域，除本部门人员、其他部门主管以上人员外，未经许可不得随意进入。
４．6锁闭装置及钥匙保管
4.6．1所有内外窗户、大门、重要文件柜等必须安装锁具，以防止未经许可的人员进入和偷盗。
4．６。
2各部门内部区域公共钥匙由部门主管分发给相关负责人员,并进行详细的分发记录;其余钥匙交由部门主管妥善保管；如有必要的,应分发一套钥匙给行政课备用.
４．6.3公共区域钥匙由行政课分发给区域负责人或保安队长,并进行详细的分发记录；其余钥匙交由行政课主管妥善保管.
4.6．４钥匙领用人员应尽职尽责，按规定时间开关门，上、下班前应对负责区域内的情况进行检查；如有异常的应及时向部门主管或行政课主管报告。
4.6。
5钥匙领用人、保管人不得私自配备钥匙或交由他人保管或使用；如有遗失的，应及时向部门主管报告，视情况另行分发钥匙或换锁。
4。
6．6人员正常离职、办理离职手续时，部门主管应收回钥匙并记录;如未办理离职手续离开或有其他异常情况的,应及时换锁并记录。
4.６．７如锁具为密码锁的，人员离职后,均应即时更换密码。
4.6。
8锁具如属自然损坏的，相关人员应及时向部门主管或行政课反映,以便及时更换。
４.6.9锁具如属人为破坏的，相关人员应立即向部门主管或行政课报告,由行政课组织人员进行调查.
文件编号
知识管理控制程序
版次
A/0
页次
1/3
生效日期
2021—09-01
1.目的：
通过知识管理的策划，促进经验向知识的转化，知识向流程或内部标准的转化，知识、流程向能力的转化。
确保过程运行、产品实现所需的知识得到保持和运用，公司所保持的知识能满足不断变化的需求和发展形势,为更好的实现公司目标作出贡献.
2.适用范围：
本流程适用与莱芜汇金金属制品股份知识的管理.
3.职责：
3.1.总经理提供知识管理所需的资源及相关的授权.
3.2.管理者代表负责知识的管理的策划及相关管理工作。
3.3.各相关部门负责落实知识管理各项要求。
4.程序：
4.1.定义
4.1.1.组织的知识:
是组织特有的知识，通常从其经验中获得，是为实现组织目标所使用或共享的信息。
4.2.组织所需知识的确定
4.2.1.人力行政部根据过程运行、产品实现所需的知识，确定组织必要的知识，并公司必要的知识实施管理，确保在岗位任职资格和岗位职责中的到策划。
4.3.组织知识的来源
4.3.1.组织知识按来源划分:
内部来源和外部来源
4.3.2.内部来源：
知识产权（目前不涉及）、从经验获得的知识、从失败或成功项目汲取的经验和教训，获取和分享未成文的知识和经验，以及过程、产品和服务改进结果。
4.3.3.外部来源:
法律法规、顾客要求、标准、先进管理模式或技术的学习资料、专业会议、从外部供方收集的知识.
4.4.经验教训
4.4.1.经验教训主要来源于质量问题解决、审核发现问题的解决、项目管理问题的总结、生产管理问题的解决、设备故障的解决、工作经验或技巧的总结、自主改进成果。
4.4.2.质量部建立内部质量问题跟踪表、外部质量问题跟踪表、供应商质量问题跟踪表、内外部审核发现问题跟踪表，对措施的落实情况进行汇总和跟踪。
详细操作要求参见《改进控制程序》。
4.4.3.项目经理负责组织收集类似项目中的开发经验、项目开发所需的知识，并对本次项目开发遇到的问题及解决方案进行记录和总结，详细操作要求参见《先期质量策划控制程序》.
4.4.4.生产主管负责记录生产管理中遇到的问题、解决方案及经验总结,以优化生产管理流程。
4.4.5.设备主管负责新设备操作维护等知识的收集与整理，记录设备故障排除中的问题、解决方案及经验总结，以优化设备管理流程或保养规程。
详细操作要求参见《设备和设施控制程序》
4.4.6.公司应通过员工激励相关制度鼓励员工自主改进、经验总结与交流,并对合理案例进行适当的奖励。
4.4.7.管理者代表定期评审各部门的问题解决过程中的经验与教训的文件化落实情况或流程化转化情况.
4.5.外部来源知识的管理
4.5.1.法律法规收集、转化、更新等要求参见《合规性控制程序》
4.5.2.顾客要求的收集、评审、转化等要求参见《顾客要求控制程序》
4.5.3.公司相关责任部门应收集并保持相关的标准的电子版或纸张版，管理体系类标准应安排专人组织文件化或流程化的转化工作。
4.5.4.供应链部或SQE通过定期的供应商审核走访、资料、供方相关问题的解决的收集掌握供应商的相关知识，优化供应商的管理。
详细操作要求参见《采购与供应商管理程序》
4.6.其它知识的管理
4.6.1.通过书籍、学习交流会、专业会议等形式学习了解先进的管理技术或管理模式。
4.6.2.人力行政部负责组织建立图书角，采购组织所需知识对应的书籍供员工自主
升级会员 