软件配置管理控制程序
配置管理控制程序
历史记录
目录
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有关的内容
3过程综述
3.1流程图
3.2 过程说明
软件配置管理是通过配置标识、配置控制、配置状态说明和配置审核等一系列活动，在项目的整个软件生存周期建立和维护软件产品的完整性。
4过程活动
4.1活动一. 制定配置管理计划
4.1.1进入准则
已经指派了项目配置管理员
4.1.2 输入
《项目已定义标准过程》
《软件开发计划》草稿
4.1.3 任务
任务1: 确定项目CM的要求
配置管理员通过《项目已定义标准过程》、《软件开发计划》草稿等项目前期文档了解项目对配置管理的要求。
任务2: 确定配置管理环境
在创建配置库之前，配置管理员要确定本项目的配置管理工具，包括用于配置管理的计算机软、硬件资源。
明确配置管理权限,制定权限列表,详见《文档权限列表》。
确立配置库结构：根据项目实际情况和组织的《配置管理标准》，确立配置库的具体结构。公司的开发库，受控库和产品库建立在公司的cvs服务器（192.168.1.154）上，如果项目经理要求（例如封闭开发需要），开发库可以建立在项目组自己的服务器上。
策划阶段，《配置管理计划》批准之前，开发库（等同于临时库）应建立起来，策划阶段文档纳入开发库；《配置管理计划》批准之后，配置库正式建立。
任务3：确定基线及配置项列表。详见6.2.4以及《配置管理标准》。
任务4: 确定项目配置管理活动和任务
配置管理员根据项目的大小，确定项目需要进行的配置管理活动和任务，估计配置管理的工作量。
任务5：建立项目定义的标准规程。
任务6: 编写《配置管理计划》
配置管理员根据项目的《项目已定义标准过程》和《软件开发计划》，按照公司的《配置管理计划》模板，编写《配置管理计划》。
任务7: 审批《配置管理计划》
配置管理计划必须先提供给相关工作组，如开发组，PPQA组，系统测试组进行协商，然后在项目策划阶段评审会上对其进行评审。审批通过的《配置管理计划》由项目经理签字后，纳入配置管理，并由配置管理员通知所有受影响的组。
4.1.4 输出
《配置管理计划》
4.1.5 退出准则
《配置管理计划》已经通过评审并纳入受控库。
4.2活动二. 配置项标识
4.2.1进入准则
开始制订《配置管理计划》
已提交配置项
《文件归档申请单》已提交
4.2.2输入
提交的配置项
《文件归档申请单》
4.2.3任务
任务1：配置项标识
配置管理员和项目经理在项目策划期间讨论项目将产生的配置项以及隶属的基线，文档类的配置项参见项目开发计划中的工作产品列表，可进行添加和删减；代码类配置项以策划阶段《项目估计书》中列出的模块为单位进行设定。配置管理员和项目经理还需确定配置项（包括基线）的入库时间，相应的访问权限，并且根据配置项命名的规定（参见《配置管理标准》），对配置项进行唯一的标识，结果记录到《配置项清单》、《配置管理计划》中。
任务2：创建配置项
在软件开发期间，开发人员依据《配置项清单》和配置项命名规则创建配置项，在配置项提交后，由配置管理员更新《配置项清单》。
任务3：建立/维护配置管理库
配置管理员根据《配置管理计划》中确立的配置库结构创建配置管理库，同时根据《配置管理标准》分配访问权限。
任务4：配置项入库
配置项入库指工作产品从开发库进入受控库，配置管理员在受控库中对配置项做同样的标识，详见《配置管理标准》。
任务5：建立基线
在《配置管理计划》中预先明确的时间或阶段点上下表中的相应角色遵照下面五个步骤建立基线:
对于计划外形成的基线，开发人员需提出申请，经SCCB审核批准后正式确立。
4.2.4输出
项目基线
《配置状态报告》
项目配置库
《配置项清单》
4.2.5退出准则
工作产品已经置入配置库的管理之下
所有工作产品都有唯一的配置项标识
4.3活动三. 变更控制
详见《配置变更子过程》。
4.4活动四. 配置状态纪实
4.4.1进入准则
新的配置项要提交
配置管理计划里规定的提交报告时间已到
项目经理需要查询配置状态信息
4.4.2输入
《配置管理计划》
配置库
《文件归档申请单》
《配置项变更申请单》
4.4.3任务
任务1：建立配置状态记录
A:配置管理员在《配置管理计划》批准后应初始化《配置变更跟踪表》、《配置状态报告》，检查项目的前期文档是否已经纳入项目的配置管理，并更新《配置状态报告》。
B:随着项目进展，CC根据按收到的《文件归档申请单》、《配置项变更申请单》和提交的工作产品更新《配置状态报告》、《配置项清单》和《配置变更跟踪表》。
任务2：配置项状态报告
配置管理员按照《配置管理计划》定期（每两周一次）发布《配置状态报告》（参见模板）。
在SCCB会议后，配置管理员应发布《会议记录》。
产品对内发布或对外发布时配置管理员应提交《产品发布报告》。
完成配置审核后，配置管理员发布审核报告。
这些报告在提交给项目经理的同时，也要放到配置管理库里，能让所有开发人员以及SCCB、PPQA阅读这些状态报告。
如果项目经理要求，配置管理员可能还需要提供包含以下内容或部分内容的文档:
未实施的变更列表；
最近一个月提出的变更请求；
目前在实施变更的人员统计；
多少变更项没有审批;
测试期间的一周变更次数；
当前高等级变更数等。
4.4.4输出
《配置状态报告》
《配置变更跟踪表》
《配置项清单》
4.4.5退出准则
报告都已经完成并提交
4.5 活动五. 配置审核
详见《配置审核管理规程》。
4.6 活动六. 编译源代码
4.6.1.进入准则
源代码提交送测
4.6.2输入
软件送测单
4.6.3任务
配置管理员对送测代码进行编译，如果编译不通过，返回送测人；如果编译通过，送测试部。
4.6.4输出
软件送测单
4.6.5退出准则
编译通过
4.7活动七. 工作产品发布
详见《配置项发布管理规程》。
4.8活动八. 产品日常备份
详细见《产品日常备份规程》。
5过程测量
（1）配置管理员每月最后一天对该月配置管理活动进行测量，将测量数据存储在《配置管理活动测量记录表》中；
（2）根据《过程度量规格说明书》中有关配置管理过程的度量要求，对测量数据进行分析，并将结果记录在《配置管理活动测量记录表》中，报告给度量专员和项目经理。
（3）EPG负责人通过度量报告,分析项目配置管理过程的性能，积累历史数据，改进配置管理过程。
6相关文件
《配置管理标准》
《配置变更子程序》
《配置审核管理规程》
《配置项发布管理规程》
《产品日常备份规程》
质量记录
软件设计和开发控制程序
公司软件设计和开发控制程序 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.目的 对质量体系有关的文件，进行控制管理，确保有关场所使用的文件，均为有效版本。 2.范围 适用于本公司与质量体系有关文件的控制管理，包括电子媒体的文件。 3.相关文件 无 4.职责 4.1总经理负责质量手册的批准和发布。 4.2管理者代表负责除质量方针目标、质量手册以外的批准及发布。 4.3各部门主管负责本部门编制和提供的文件的审核。 4.4各部门经办人员负责各类文件的编制、收集（包括外来）文件和统计。并指定兼职资料员，负责保管好本部门收到的文件，做好文件清单的记录。 4.5行政办公室负责文件的文档登记、保管、借用、更改、回收和销毁（包括外来文件）等管理工作。 5.工作程序 5.1行政办公室负责制订文件控制管理程序，相关部门程序要求实施。 5.2文件控制的流程。
动应遵循的途径和方法。 5.3.3其他管理性和技术性文件（第三层次文件）---如管理性的有：规章制度、管理办理、各种管理标准、工作计划、记录和报告的表示等；技术性的有：产品图纸、产品标准、工艺文件和标准、检验和检测规范、作业指导书、操作法规等。 5.3.4外来文件等---国标、国家和行业的标准、国家和地方的法律法规、适用法规和标准，顾客提供的工程规范等，被本公司收集引用的文件。 5.4文件的编写导则 5.4.1本公司的各类文件都必须有：标题、编号、拟（编）写人、审核人、批准人的签名方为有效。文件必须要有版本、修改码和目录及最新状态清单。外来文件被采用必须要有提供部门领导的认可签名。 4-1-1 文件控制管理程序版本：A 第3页共14页 5.4.2质量手册和程序文件由管理者代表组织编写，质量手册由管理者代表审核，总经理批准。程序文件由相关部门经理审核、管理者代表批准。 5.4.3研发部门负责编写技术文件，包括产品标准、技术
计算机软件设计开发控制程序
计算机软件设计开发控制程序 1.目的 为使软件设计开发全过程得到有效的实施和控制，保证软件产品在开发过程中各个阶段的质量以及最终软件的功能、性能指标符合规定要求及适用于产品的法律、法规的要求,以增强顾客满意，特制定本程序。 2.范围 本程序涉及软件设计开发过程中的全过程的控制。 3.流程 3.1. 可行性研究 在与客户签订合同之前，均应对将签项目进行资源、技术、市场的可行性分析，可行性分析通过后、签订合同前由公司组织相关人员对合同条款进行评审，评审通过后，公司组织进行立项工作。 3.2. 立项 可行性分析评审通过后，有开发部门经理下达立项任务，制定相关人员填写立项申请报告报批，报批通过后，由部门经理和技术负责人协商下达开发任务书，经技术负责人审核通过后报公司批准。批准立项后，项目进度应以立项申请报告中的阶段进度为准，如果进度需要调整，需要填写进度调整申请报告报批。 3.3. 需求分析 公司根据客户提出的技术要求和相应的软件任务书以及其他有关件，与客户协商确定详细的软件需求。 3.4. 开发策划 根据项目要求和软件需求，由配置人员配合项目经理编写本项目的质量保证计划、配置管理计划和项目综合计划。在配置管理计划中应列明本项目需提交的各阶段文档的
名称，在项目完成后项目组需列表说明需要移交的文档。在制定计划时，应为计划、设计、测试、修正、再测试、变更以及编制文档留出足够的时间。 3.5. 设计 ●概要设计 根据软件需求说明建立软件总体结构和模块间的关系，确定各模块功能，定义各功能模块的接口，设计全局数据库和数据结构。 ●详细设计 在概要设计的基础上，开发者需要进行软件系统的详细设计。在详细设 计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结 构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或 子程序)的设计考虑，以便进行编码和测试。应当保证软件的需求完全分 配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编 码。 3.6. 编码实现 在软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。 3.7. 测试 ●软件单元测试 按详细设计的结构，根据软件单元测试计划，对软件进行测试。 ●组装测试 根据软件需求说明书中定义的全部功能和性能要求及组装测试计划，对 软件进行组装测试，以确定整个软件是否满足软件需求，是否可以提交 总装测试。 3.8. 验收交付 在软件测试证明软件达到要求后，软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、
公司文件控制管理程序范本
俊杰 1.目的 对与公司质量管理体系有关的文件进行控制，确保各相关场所使用文件的有效版本。 2.范围 适用于与所有质量管理体系有关文件的控制。 3.职责 3.1行政部负责公司质量管理体系文件编制、收发、更改的控制和管理； 3.2生产部负责公司技术、工艺文件及新产品研发过程中文件的编制、收发、更改的控制和管理; 3.3其他部门负责本部门文件的管理和正确使用。 4.程序 4.1文件分类4.1.1质量管理体系文件包括：
4.3.1质量手册由行政部负责编写，由管理者代表审核，总经理批准发布； 4.3.2程序文件、作业指导书由部门负责编写，由部门负责人审核，管理者代表批准； 4.3.3文件批准发布时，审批人应确保文件是适宜的； 4.3.4质量手册、程序文件由管理者代表确定发放范围，经管理者代表批准后发放到相应的使用部门，行政部填写《文件发放回收登记表》，领用人签名领取。 4.3.5其它质量文件由各部门确定发放范围，分管领导批准后发放至有关人员，并填写《文件发放回 收登记表》，领用人签名领取。 4.4文件的受控、作废 文件分为“受控”和“非受控”两大类，凡与公司质量管理体系运行的各使用场所紧密相关的文件应为受控文件。所有受控文件须在该文件封面加盖“受控”印章，并注明分发号。凡提交顾客等可用“非受控”文件。 4.5文件的更改 4.5.1质量管理体系文件的更改由行政部负责公司实施，申请更改部门填写《文件更改申请单》，经 原审核者审核，原文件批准者批准后更改。如果指定其他部门审批时，该部门应获得审批所需依据的有关背景资料；文件的所有更改，均须体现在《文件更改申请单》中并集中保留。 体系文件的初始版本/版次为1.0/0，第一次换版为2.0版，以后依次类推为3.0版、4.0版……，文件第一次换页修改版次为1，以后修改依次为2、3、……修改5次以后换版。 4.6文件的领用 4.7文件的保存、作废与销毁 4.7.1文件的保存 a.各部门负责保管本部门与质量管理体系相关的文件，文件保存场所应适宜。 b.对受控文件，各部门应及时填写《受控文件清单》进行管理。 c.任何人不得在受控文件上乱涂乱画，不准私自外借，确保文件的清晰、易于识别和检索。 4.7.2文件的作废 a.当文件作废时，文件的发放部门负责按《文件发放回收记录表》及时从相应的使用部门撤回失效或作废的文件。 b.作废文件加盖“作废”印章，需作资料保留的作废文件则由文件发放部门加盖“仅供参考”印章方可留用。
软件配置管理流程
配置管理流程规定 (Ver1.0) 拟制：___________________ 审核：___________________ 签发：___________________
目录 1.配置管理流程 (3) 1.1概述 (3) 1.2总体流程图 (3) 1.3软件需求分析阶段 (4) 1.4软件设计阶段 (4) 1.5制定配置管理计划 (4) 1.6配置库管理 (4) 1.6.1相关人员分配权限 (4) 1.6.2配置项 (5) 1.7版本控制 (6) 1.8变更控制 (6) 1.9配置审计 (8) 1.9.1配置审核的类别 (8) 1.9.2配置审核执行的时机 (8) 1.9.3不符合项的处理 (8) 2.0.0配置状态报告 (8) 2.0.1配置状态报告的目的 (8) 2.0.2配置状态报告记录的内容 (8) 2.0.3配置状态报告的生成 (9) 2.1.0发行管理 (9) 2.1.1交付管理 (9) 2.软件基线化规范 (10) 2.1正常开发期 (10) 2.2版本发布期 (11) 2.3项目发布期 (13) 3.Jira配置管理 (14)
1.配置管理流程 1.1概述 规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2总体流程图
1.3软件需求分析阶段 参加需求分析会议，配置管理负责人记录，有关文档提交归档。如《需求分析》。 1.4软件设计阶段 参加设计阶段，为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 1.5制定配置管理计划 配置管理员制定配置管理计划，主要内容包括配置管理软硬件资源、配置项计划、备份计划等，审批该计划。 1.6配置库管理 配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 1.6.1相关人员分配权限 项目经理： 1)与(有关负责人员)协商确定项目起始基线 2)接受配置管理计划，并按相关规定贯彻执行； 3)接受配置控制委员会的报告。 4)提出配置管理计划的修改要求； 5)提出管理管理的建议和要求。 配置管理员 1)编制配置管理计划； 2)执行配置项管理； 3)执行版本控制和变更控制方案； 4)编制配置状态报告； 5)配置库的建立和权限分配； 6)配置管理工具的日常管理与维护； 7)配置库的日常操作和维护 开发人员
软件配置管理控制程序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目的与适用围 (3) 1.1 目的 (3) 1.2 适用围 (3) 2 引用文件 (3) 3职责 (3) 4程序 (4) 4.1需求分析程序 (4) 4.1.1获取、分析需求 (4) 4.1.2需求规格说明书的评审 (4) 4.1.3需求确认 (4) 4.1.4存档 (4) 4.1.5需求变更 (4) 4.2 软件设计程序 (5) 4.2.1软件设计 (5) 4.2.2设计评审 (5) 4.2.3设计文档的备案 (5) 4.2.4设计更改控制 (5) 4.3 编码开发程序 (5) 4.3.1编码 (5) 4.3.2代码集成 (6) 4.3.3程序验收 (6) 4.3.4配置管理 (6) 4.3.5测试流程 (6) 4.3.5.1 测试用例的编写、审核与备案 (6) 4.3.5.2 系统测试 (6) 4.3.5.3 用户手册的编写与审核 (7) 4.3.5.4存档 (7) 5流程图 (8) 6相关文件 (9)
1目的与适用围 1.1 目的 规需求分析、设计、开发等作业过程，确保对软件实现阶段实行有效的管理控制，力求减少编码出错，准确实现软件设计的要求。以合理的时间和人力找出软件中潜在的各种错误和缺陷，证明软件的功能和性能与需求说明相符，从而使交付给客户的产品的质量得到保证。 1.2 适用围 适用于软件类项目和混合类项目的软件部分的需求分析、设计、编码和测试阶段。 2 引用文件 GBT 11457-2006 信息技术软件工程术语 GBT 16260.4-2006 软件工程产品质量 3职责 ?项目经理：负责整个开发过程的整体控制，每周向公司和客户提交项目周报。 ?需求分析员：进行需求调研，编写《需求规格说明书》、《调研日志》、需求的补充文档等，必要时进行需求变更。 ?技术负责人：负责设计工作的安排和技术指导，评审特殊项目的设计。 ?设计人员：软件界面设计。 ?开发人员：负责软件系统设计，编写设计文档。根据设计说明书编写程序，修改软件代码。 ?测试员：编写《测试用例》，搭建测试环境、执行单元测试、集成测试，提出《测试报告》。 ?行政人事部：负责开发过程中文件及代码的存档管理。 ?项目组成员：每日填写工作日志。 ?部门负责人：对项目人员工作日志进行统计。
文件管理控制程序69106
1、目的 通过对质量管理体系文件的控制管理，确保本公司质量管理体系符合ISO9001:2015& ISO 13485:2016、GMP、QS标准及符合中国法规、美国、欧盟国家、加拿大和其它产品输出目的国要求，确保质量管理体系文件的分类编号﹑编制﹑审批﹑发放管理﹑有效性控制﹑保管和更改等活动在受控状态下进行；并保证各文件使用场所的受控文件为最新有效版本； 2、范围 适用于公司所有质量管理体系文件的管理与控制。 3、定义 受控文件：供公司内外部使用的，受更改、标识、版本、版序、格式、字体等控制的文件； DCC: Document Controlling Center 文件控制中心； 外来文件：指从外部获取并由本公司直接引用的文件，如国家﹑行业﹑地方标准﹑法律法规和客户提供的文件﹑资料及供货商提供的产品标准/检验报告等； 外发文件：提供给供方、顾客、检测机构、第三方审核机构、中国各级监管机构（食品药品监督管理局、质量技术监督局、工商局、知识产权局等）、其它国家监管机构等的质量管理体系文件或企业资质证书等文件；认证证书：企业资质证书、产品证书、人员培训类证书（外训）等； DMR:是指包括医疗器械成品的程序和规范的完整记录； 每个产品的DMR应包括以下信息或指明所在位置; 器械规范包括相应的图纸、组成、配方、组件规范和软件规范； 生产加工规范包括相应的设备规范、生产方法、生产程序、生产环境规范； 品质保证程序和规范，包括接收标准和使用的质量保证设备； 包装和标记规范，包括使用和处理方法，以及安装、维护和服务的程序及方法; 4、职责 文控中心负责公司质量管理体系文件的管理与控制，并对文件的编号、公布、发行及有效性负责。 各部门负责对其使用的受控文件进行控制； 文控中心负责质量管理体系文的回收、保存和销毁的归口管理； 文控中心负责外发文件的回收（必要时）、登记、发放进行控制； 管理者代表（后简称管代）或其转授权人负责外发文件的审批； 5、程序
配置管理流程
配置管理流程 Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT
简介 业务目的： 为解决、控制过程及部分服务交付过程提供需要的配置项及其属性信息。 IT 目的： 1)建立一个完整的配置项管理框架，降低了无控制环境变更的危险性； 2)CMDB提高支援及各类服务活动的效率和品质，确保服务交付流程如连续性、容量等良好运作。 适用范围 此流程适用IT管理手册中定义的服务范围。 相关流程 IT服务管理手册 (QM-ITSM-2011) 服务规划及管理流程(OP-ITSM-004) 服务报告管理流程 (OP-ITSM-006) 事件和服务请求管理流程 (OP-ITSM-007) 问题管理流程 (OP-ITSM-008) 变更管理流程 (OP-ITSM-010) 发布管理流程 (OP-ITSM-011) 连续性管理流程 (OP-ITSM-012) 容量与可用性管理流程 (OP-ITSM-014) 信息安全管理流程 (OP-ITSM-015) 供应商管理流程 (OP-ITSM-017) 服务策划管理流程(OP-ITSM-019) 定义 术语表： 无 角色定义表
仪器种类代号
编号格式 主要设备按以下方式进行编号登记： XX9999YY XX = 仪器种类代号 9999 = 4至5位数字 YY = 地域代号内的缩写式代号 内容 流程解释 配置管理流程从配置规划、日常运维、配置审计、配置管理检讨的PDCA循环保障CI的完整性和有效性，其中配置规划包括配置管理应用的各类规则。 配置规划 (P) 5.2.1配置管理范围工具、用途说明：
(完整word版)文件管理控制程序
文件名称文件管理控制程序页次: 1 / 8 生效日期:2018-08-22 1、目的 通过对质量管理体系文件的控制管理，确保本公司质量管理体系符合ISO9001:2015& ISO 13485:2016、GMP、QS标准及符合中国法规、美国、欧盟国家、加拿大和其它产品输出目的国要求，确保质量管理体系文件的分类编号﹑编制﹑审批﹑发放管理﹑有效性控制﹑保管和更改等活动在受控状态下进行；并保证各文件使用场所的受控文件为最新有效版本； 2、范围 适用于公司所有质量管理体系文件的管理与控制。 3、定义 3.1 受控文件：供公司内外部使用的，受更改、标识、版本、版序、格式、字体等控制的文件； 3.2 DCC: Document Controlling Center 文件控制中心； 3.3 外来文件：指从外部获取并由本公司直接引用的文件，如国家﹑行业﹑地方标准﹑法律法规和客户提供的文件﹑资料及供货商提供的产品标准/检验报告等； 3.4 外发文件：提供给供方、顾客、检测机构、第三方审核机构、中国各级监管机构（食品药品监督管理局、质量技术监督局、工商局、知识产权局等）、其它国家监管机构等的质量管理体系文件或企业资质证书等文件； 3.5 认证证书：企业资质证书、产品证书、人员培训类证书（外训）等； 3.6 DMR:是指包括医疗器械成品的程序和规范的完整记录； 3.6.1每个产品的DMR应包括以下信息或指明所在位置; 器械规范包括相应的图纸、组成、配方、组件规范和软件规范； 生产加工规范包括相应的设备规范、生产方法、生产程序、生产环境规范； 品质保证程序和规范，包括接收标准和使用的质量保证设备； 包装和标记规范，包括使用和处理方法，以及安装、维护和服务的程序及方法; 4、职责 4.1 文控中心负责公司质量管理体系文件的管理与控制，并对文件的编号、公布、发行及有效性负责。 4.2 各部门负责对其使用的受控文件进行控制；
ISO20000-20配置管理程序
密级：敏感 文档编号：HTPC-ITSM-B-20配置管理程序 版本号：V1.0 配置管理程序 ************信息技术有限公司 ---------------------------------------------------------------------------- ************信息技术有限公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
修订履历
目录 1 目的 (4) 2 范围 (4) 3 职责 (4) 3.1 配置管理负责人 (4) 3.2 配置管理员 (5) 3.3 一线支持人员 (5) 4 相关文件 (5) 5 程序 (5) 5.1 配置计划 (5) 5.2 配置定义和标识 (5) 5.3 建立配置管理数据库 (5) 5.4 CMDB的控制和维护 (6) 5.5 配置审计和验证 (6) 5.6 生成配置报告 (6) 6 记录 (6)
1 目的 配置管理流程的总体目的是提供一个统一的、一致的流程来管理售后服务环境中的所有组成部分，以确保： 1)所有配置项（CI）被识别和记录下来； 2)配置项当前和历史状态得到汇报； 3)配置项记录的完整性得到维护和确认； 4)客户服务环境的稳定性； 5)实现资产管理的目的。 2 范围 配置管理的范围是公司开发的管理信息系统的运行和服务环境下所包含的配置项（CI），包括系统运行环境的部署环境设备、系统软件等，及服务环境中涉及的客户信息配置。具体活动包括识别、控制、汇报和审核等行为。 包括： 1)客户信息：企业客户信息； 2)软件信息：客户运行环境中传输线路综合管理系统、车辆管理系统及其运行环 境，安装软件的拷贝信息； 3)服务器端配置：主机设备、终端设备； 4)备件信息：手持终端设备、车载设备等； 5)服务文档：服务项目文档、服务记录、用户手册等； 6)供应商：供应商信息。 不包括： 1)处于开发或测试环境的业务系统。 3 职责 3.1 配置管理负责人 1)定义并维护配置管理流程文件及所需要的记录模板； 2)管理配置管理流程的实施； 3)确保配置管理流程目标的实现；
软件配置管理控制程序
配置管理控制程序 版本号修订内容编制人审阅人日期
历史记录
目录
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有关的内容
最新版ISO9001_2015体系文件控制程序文件
文件名称：文件控制管理程序
1.0 目的 对公司环境、质量管理体系以及管理标准、工作标准中的各类文件进行管理，确保各部门使用文件的适宜性及充分性, 防止误用作废文件。 2.0 范围 适用于本公司所有环境、质量管理体系文件以及管理标准、工作标准的（电子档）的编制、审核、批准、发放、评审和变更。 3.0 职责 3.2 文控中心 对公司环境、质量管理系统中各阶文件的合理管控以及文件的分类、编号、保管、发放、回收、销毁及审查等工作。 3.3 相关单位 3.3.1 各部门须遵守本程序，并配合文控中心一同做好文件的更新及维护；其部门主管 需对文件资料进行审签，对所发行的文件负责保管与执行之责。 3.3.2 各部门需负责文件的使用和保管，确保文件的整洁、完整，不得在受控的文件上 随意书写涂改，也不得丢失。版本更新时，配合文控中心及旧版资料及时回收作 业，防止误用。 4.0 定义 4.1 文件与资料 公司环境和质量文件所包含有：手册、程序、作业规范/指导书、表单；技术类文件、测试检验数据报告、各种变更文件以及公司各类经营管理标准、工作标准等。 4.2 第一阶文件－—手册
环境管理手册：环境管理系统最高指导原则，规定其核心内容的整体方向、结构和相互作用。 质量管理手册：质量管理系统最高指导原则，规定其核心内容的整体方向、结构和相互作用。 4.3 二阶文件－—程序 4.3.1 环境、质量管理程序：环境、质量作业运作过程的整体流程。 4.4 三阶文件－—作业规范、指导书、管理标准及工作标准。 4.4.1作业指导书: 指不涉及具体型号产品技术细节的作业指导书。如技术文件编号方 法、作业指导书，设备操作维护规程等。 4.4.2 技术性作业指导书:指涉及具体型号产品技术细节的作业指导书, 如技术图纸 /BOM、工艺文件、产品检验文件等。 4.4.3管理标准：指各类管理规定、管理制度、管理办法等用于规范管理及人员行为的 法规性文件。 4.4.4工作标准：指各类岗位职责及职务说明书等文件。 4.5 四阶文件－—表单 使用固定格式的单据，有表单编号及版本管控，用以质量、环境及环境的数据收集、传递资讯，控制作业流程或证明作业已符合要求的资料记录。 4.6 外来文件与资料。 各单位因业务需求所使用的各类法律法规、国家标准、行业标准、地方标准及行业各类技术资料等。 4.7 文件标准用纸 各单位送至文控中心所有需要发行的文件标准型一般为A4纸张，禁止用“二手纸”。 5.0 工作程序 5.1 文件的编制 5.1.1 书写规定 5.1.1.1 二、三阶文件需依照（1）目的（2）范围（3）权责（4）定义[无定义时填 写“无”]（5）工作程序（6）相关文件（7）相关表单（8）附录（必要 时）。 注：二阶文件需另制作封面，由相关人员签核，三阶文件不需要封面，相关人员签核栏在页尾处。 5.1.1.2 文件页次格式：第*页，共*页代表，以此类推。 5.1.1.3 各标题内的小标题顺序如下格式： 1→1.1→1.1.1→1.1.1.1 以此类推。 2→2.1→2.1.1→2.1.1.1 以此类推。 5.1.2 文件经3.1权责主管核准后方可制订，以确保文件的充分、完整并适用。
软件配置管理控制程序
配置管理控制程序
历史记录
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开发组 负责审核《配置管理计划》任务列表中与开发有关的内容
QP423文件控制管理程序(总3页)
Q P423文件控制管理程序(总 3页) -CAL-FENGHAI.-(YICAI)-Company One1 -CAL-本页仅作为文档封面，使用请直接删除
1.目的 对与公司质量管理体系有关的文件进行控制，确保各相关场所使用文件的有效版本。 2.范围 适用于与所有质量管理体系有关文件的控制。 3.职责 行政部负责公司质量管理体系文件编制、收发、更改的控制和管理； 生产部负责公司技术、工艺文件及新产品研发过程中文件的编制、收发、更改的控制和管理； 其他部门负责本部门文件的管理和正确使用。 4.程序 文件分类 质量管理体系文件包括： a.质量管理手册、程序文件、管理制度等； b.质量管理体系运行过程中所涉及的质量记录表格。 技术文件包括： a.产品技术标准（国家标准、行业标准、企业标准）； b.产品图样、工艺文件、操作规程（作业指导书）、检验规范等； c.设备操作指导书等。 质量管理体系文件的编号 a.质量管理手册 手册代号—01，手册中各章以章节号区分； 如：QMS—01，表示公司质量管理手册编号。 b.程序文件 程序文件代号/标准条款号—加序号； 如：QP423—01，表示ISO9001标准条款的第一个程序文件。 c.支持文件 支持文件代号WI+部门名称代号+流水号； a）技术图样编号：产品代号+序号或按相应规范
b）各类作业文件（包括管理标准、工作标准、技术标准等）编号：支持文件代号WI+编制部门代号+文件序号（两码 部门代号为：行政部XZ；质检部ZJ；生产部SC；业务部YW；资材部ZC；工程部GC；……。 如质检部编制文件为：WIZL01（02/03……）…… d.质量记录 公司名称代号/质量记录代号—质量记录流水号； 如：LC/QR-01，表示第一个质量记录。 文件的编写、审核、批准、发放 4.3.1质量手册由行政部负责编写，由管理者代表审核，总经理批准发布；4.3.2程序文件、作业指导书由部门负责编写，由部门负责人审核，管理者代表批准； 4.3.3文件批准发布时，审批人应确保文件是适宜的； 4.3.4质量手册、程序文件由管理者代表确定发放范围，经管理者代表批准后发放到相应的使用部门，行政部填写《文件发放回收登记表》，领用人签名领取。 4.3.5其它质量文件由各部门确定发放范围，分管领导批准后发放至有关人员，并填写《文件发放回收登记表》，领用人签名领取。 文件的受控、作废 文件分为“受控”和“非受控”两大类，凡与公司质量管理体系运行的各使用场所紧密相关的文件应为受控文件。所有受控文件须在该文件封面加盖“受控”印章，并注明分发号。凡提交顾客等可用“非受控”文件。 文件的更改 质量管理体系文件的更改由行政部负责公司实施，申请更改部门填写《文件更改申请单》,经原审核者审核，原文件批准者批准后更改。如果指定其他部门审批时，该部门应获得审批所需依据的有关背景资料；文件的所有更改，均须体现在《文件更改申请单》中并集中保留。 文件版本/版次的管理 体系文件的初始版本/版次为0，第一次换版为版，以后依次类推为版、版……，文件第一次换页修改版次为1，以后修改依次为2、3、……修改5次以后换版。
软件配置管理流程
软件配置管理流程
目录 1.配置管理流程 (3) 1.1 概述 (3) 1.2 总体流程图 (3) 1.3 软件需求分析阶段 (4) 1.4 软件设计阶段 (4) 1.5 制定配置管理计划 (4) 1.6 配置库管理 (4) 1.6.1 相关人员分配权限 (4) 1.6.2 配置项 (5) 1.7 版本控制 (6) 1.8 变更控制 (6) 1.9 配置审计 (7) 1.9.1 配置审核的类别 (7) 1.9.2 配置审核执行的时机 (7) 1.9.3 不符合项的处理 (7) 2.0.0 配置状态报告 (7) 2.0.1 配置状态报告的目的 (7) 2.0.2 配置状态报告记录的内容 (7) 2.0.3 配置状态报告的生成 (7) 2.1.0 发行管理 (8) 2.1.1 交付管理 (8) 2.1.1 软件配置管理员的处理规范 (8) 2.1.1.1 现阶段使用的版本配置服务器 (8) 2.1.1.2 主要操作流程 (8) 2.1.1.3 版本规范化处理 (8) 2.1.1.4 客户反馈问题处理 (8) 2.软件基线化规范 (9) 2.1 正常开发期 (9) 2.2 版本发布期 (9) 2.3 项目发布期 (9) 2.4 项目维护期 (9)
1.配置管理流程 概述 规范配置管理活动,明确配置项正确的唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 总体流程图
软件需求分析阶段 参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。 软件设计阶段 参加涉及阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本于需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 制定配置管理计划 配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。 配置库管理 配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 相关人员分配权限 项目经理： 1）与（有关负责人员）协商确定项目起始基线； 2）接受配置管理计划，并按相关规定贯彻执行； 3）接受配置控制委员会的报告； 4）提出配置管理计划的修改要求； 5）提出管理的建议和要求。 配置管理员 1）编制配置管理计划； 2）执行配置项管理； 3）执行版本控制和变更控制方案； 4）编制配置状态报告； 5）配置库的建立和权限分配； 6）配置管理工具的日常管理与维护； 7）配置库的日常操作和维护； 开发人员 1）根据确定的配置管理计划和相关规定，提交配置项
软件开发管理程序(精)
软件开发管理程序 1. 目的 为了提高软件开发的质量, 保证软件开发项目按预定的时间和费用顺利完成,提高软件过程的成熟度。 2. 适用范围 本程序适用于本公司所有软件项目开发过程的管理 , 可根据项目的大小及实际情况进行适当的删减。 3. 定义 可行性分析:对系统的技术可行性、经济可行性和社会可行性进行研究。 需求分析:真正搞清楚所要设计的软件应该具有哪些功能和特性 (即要让它做什么事。 数据字典:对数据流程图中出现的所有数据元素给出逻辑定义。概要设计:根据软件需求说明书的要求,建立目标系统的总体结构和模块间的关系,设计全局数据库/数据结构,定义各功能模块的接口、控制接口等。 详细设计:对概要设计中产生的功能模块进行过程描述,设计功能模块的内部细节,为编写源代码提供必要的说明。 测试计划:为做好集成测试和验收测试,需为如何组织测试制定实施计划。计划包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 编码与单元测试 : 将详细设计说明书转化为相应的程序设计语言或 数据库语言书写的程序,对该程序的所有模块进行测试。
4. 职责 4.1项目经理:在可行性分析阶段,组织可行性分析小组,项目通过可行性评审后编写《项目开发计划书》。在需求分析阶段,组织需求分析小组, 保证需求分析进度。在程序设计阶段, 组织概要设计小组, 组织详细设计小组,进行编码分工,监管编码规范。在项目进行的整个过程中要填写《项目进度月报》。 4.2可行性分析小组:对项目进行可行性分析并形成《可行性分析报告》。 4.3可行性评审小组:对可行性分析小组提交的《可行性分析报告》进行评审,形成《评审表》。 4.4需求分析小组:对业务需求进行分析,编写《软件需求说明书》和《数据要求说明书》。 4.5需求分析评审小组:根据软件正式技术复审规范对需求分析小组提交的《需求分析报告》 ,进行评审,形成《评审表》。 4.6概要设计小组:根据《软件需求说明书》和《数据要求说明书》进行概要设计, 编写《概要设计说明书》、《数据库设计说明书》和《数据字典》。 4.7概要设计评审小组:对《概要设计说明书》、《数据字典》和《数据库设计说明书》进行评审,出《评审表》。 4.8详细设计小组:根据《概要设计说明书》、《数据字典》和《数据库设计说明书》进行详细设。
软件开发控制程序文件
软件开发控制程序文件 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. 对于小组之间重要的软件开发信息沟通，软件开发人员填