软件配置管理控制程序
软件专业英语对照表
常见专业术语:组织过程定义控制程序 process for organizational process definition 软件生命周期模型software life cycle model组织标准过程集合描述 description of organization's set of standard process.组织标准过程裁剪指南 tailoring guideline for organizational standard process过程数据库使用规范usage specification for process metrics library过程财富度量报告measurement report for process asserts项目生命周期模型选择工作单sheet for selecting project software lifecycle model组织过程焦点控制程序 process for organizational process focus EPG工作章程EPG charterEPG工作考核细则performance appraisal rules for EPG member 过程改进建议处理控制程序process for handling process improvement proposal过程定义文件配置管理规范configuration management specification for process definition document过程行动组(PAT)工作记录process action team (PAT) working record过程定义文件试验结果评定表evaluation form for pilot result of process definition document过程状态季度报告模板 process status quarterly report template过程行动计划process action plan过程推广计划process promotion plan过程试验计划process pilot plan公司年度过程评估计划 organizational process assessment annual plan 公司过程改进总体要求 General objectives for organizational process improvement会议记录meeting minutes过程改进建议和意见汇总表summary form of comments and suggestions of PI过程改进实践状态清单 status list for process improvement practice EPG工作度量epg metrics程序文件评审讨论问题记录表issue record of process document review过程改进总体计划General plan for process improvement过程改进工作度量报告 metrics report for process improvement过程豁免申请单 process exempt application过程改进任务列表 process improvement tasks list组织级培训过程控制程序organization- level training process兼职讲师管理规定part-time instructor management regulation 免修规程training waiver procedure培训课程开发规程training course development procedure外购培训管理规程outsourcing training management procedure培训效果评估规定training effectiveness evaluation procedure 培训效果跟踪表 training effectiveness tracking record员工培训计划申请表application for employee training plan员工外训学习申请表application for employee external training 免修培训申请表application for training waiver战略培训需求表demands form for strategic training需求管理控制程序requirement management process需求变更控制规程requirement change control procedure变更影响分析控制规程 Impact analysis procedure of change确定项目已定义过程规程procedure for establishing project's defined process项目协调与沟通规程project communication & negotiation procedure 风险管理控制程序risk management process风险管理指导书risk management guidebook风险管理计划risk management plan风险列表risk list商业现货软件产品选择控制程序COTS product selection process COTS软件产品评价准则COTS product evaluation criteriaCOTS软件产品评价报告COTS product evaluation report供应商合作通知单cooperation notification to supplier第三方产品评估表the 3rd party's product evaluation form商业现货采购控制程序 COTS product procurement process软件子合同管理控制程序software sub-contract management process子合同评审规程sub-contract review procedure子合同开发监管规程sub-contract development monitoring procedure子合同配置管理规程sub-contract Configuration Management procedure子合同配置监督计划模版sub-contract configuration monitoring plan template子合同QA审核规程sub-contract QA audit procedure软件子承包商评定标准 sub-contractor evaluation criteria直真软件开发子合同模板(商务) contract template (business) for ZZ's software sub-contract子合同开发过程监控报告sub-contract development monitoring report子合同开发过程监控计划sub-contract development monitoring plan子合同工作计划sub-contract working plan产品(项目)子合同申请单application form for product( project ) sub-contract候选子承包商评估报告 candidate sub-contractor evaluation report 软件子合同评审记录software sub-contract review record项目策划控制程序project planning process规模估计规程size estimation procedure工作量估计规程effort estimation procedure编制进度规程schedule generation procedure项目策划计划plan for project planningPDSP文档PDSP document项目环境列表project's environment list项目的任务WBS列表project's task WBS list产品规模估计表product size estimation form工作量估计表effort estimation form关键计算机资源表CCR list外来工作产品清单out-sourcing work product list主要工作产品清单main work product list交付工作产品清单deliverable work product list人力资源需求表HR demands form人力资源评估表HR evaluation form项目人员计划表project's HR plan项目预算工时表project's budget/ effort form项目需增加硬件、软件成本预算表Budget form for hardware & software added共利益者协调计划表stakeholder negotiation plan资料管理计划表materials management plan开发计划development plan项目培训计划project training plan项目进度表project schedule项目总体进度表abstract project schedule合同项目立项报告initiating report for contract project研发项目立项报告initiating report for R&D project项目跟踪监控程序SPTO process研发中心例会管理规定 Review meeting procedure for R&D center研发项目组例会管理规定Review meeting procedure for R&D project team项目关闭控制程序project closure process里程碑评审规程milestone review procedure软件开发计划变更规程 Software development plan revise procedure 对外承诺变更控制规程 External commitment change procedure测量与分析控制程序 measurement & analysis process度量项定义规程measurement item definition procedure测量目标选择表measurement goal selection list项目测量数据集合project's metrics set项目度量周报project's metrics weekly report测量规格说明书metrics specification度量报告metrics report项目度量计划project's measurement plan决策分析与解决方案控制程序discussion analysis and resolution processDAR运用指南DAR practice guideline决策方案评价准则desiccation resolution evaluation criteria 过程与产品质量保证控制程序process& product quality assurance process不符合问题处理规程non-compliance issue handle procedure项目过程活动评审规程 project's process activity review procedure 项目工作产品审核规程 project's work product audit procedure质量保证活动策划规程 SQA planning procedure不符合问题等级标准non-compliance issue grade standard评价工作产品任务集合 work product evaluation tasks set评价过程活动任务集合 process activity evaluation tasks set不符合问题报告表non-compliance issue report不符合问题跟踪记录表 non-compliance issue tracking record工作产品审核记录表work product audit record过程活动评审记录表process activity review record项目QA计划进度表project's QA planned schedule 外部专家审核报告external expert audit report跨项目QA报告QA report across projects项目QA报告project QA report项目QA计划project QA plan软件配置管理控制程序 software configuration management process配置管理标准configuration management standard测试阶段CI变更规程CI change procedure in testing phase产品出库规程product check-out procedure产品入库规程product check-in procedure产品发布管理规程product release management procedure产品日常备份规程product daily backup procedure配置变更分析规程configuration change impact analysis procedure配置变更管理子过程configuration change management sub-process 配置审核管理规程configuration audit management procedure产品库管理规程product library management procedure配置项状态报告CI status report功能配置审核报告模板 FCA report template物理配置审核报告模板 FCA report template基线配置审核报告模板 baseline configuration audit report template 软件送测单delivering software to testing form日常备份记录daily backup record配置项清单CI list产品发布通知product release notification产品发布报告product release report配置管理计划模版CM plan template配置管理任务列表CM tasks list配置审核问题跟踪记录表configuration audit issues tracking record文件归档申请单application form for document archiving项目SCM任务单project's SCM task list最终产品规模测量记录 final product size metrics record销售管理控制程序sales management control process售前支持控制程序pre-sales support control process售前技术支持计划pre-sales technical support plan售前技术申请pre-sales technical application产品定义过程控制程序 product definition process需求调研规程requirement investigation procedure软件需求分析控制程序 software requirement analysis process面向对象需求分析规程 O-O requirement analysis procedure需求分析方法工具指南 guideline for methods /tools of requirement analysis需求缺陷分类标准standard of requirement defect types需求规格说明Checklist checklist for requirement specification需求分析计划跟踪表requirement analysis plan and tracking record 需求不一致项跟踪记录表requirement defect tracking record 产品(产品构件)需求product ( product component) requirement产品(产品构件)需求规格说明书-By Object product ( product component) requirement specification template -by object产品(产品构件)需求规格说明书-By Feature product ( productcomponent) requirement specification template -by feature产品(产品构件)需求规格说明书-By User Class product( product component) requirement specification template -by user class产品(产品构件)需求规格说明书-By Fun Hierarchy product( product component) requirement specification template -by Fun Hierarchy软件概要设计控制程序 software preliminary design process软件详细设计控制程序 software detailed design process概要设计说明书模板一(面向对象) PD document template (OO)概要设计说明书模板PD document template软件开发计划模版SDP template数据库设计说明书模板 database design document template用户界面设计说明书user interface design document详细设计说明书模板DD document template产品实现控制程序-代码实现product realization process-coding设计问题跟踪记录表tracking record for design issuesC++编码规范C++ coding specificationJAVA编程规范JAVA coding specification产品构件实现清单product component realization list产品构件实现方法和计划product component realization method and plan产品实现控制程序-支持文档实现product realization process- supportive document realization产品集成控制程序product integration process接口管理规程interface management procedure集成产品评价规程integrated product evaluation procedure 《产品集成策略》模版 product integration strategy template《产品集成评价报告》模版product integration evaluation report template接口跟踪表interface tracking record接口不一致项列表interface non-compliance list部件测试控制程序component testing process产品集成测试控制程序 product integration testing process系统测试控制程序system testing processFIRST OFF测试控制程序FIRST OFF testing processBUG管理系统使用规范bug management system usage specification BUG确认规程Bug confirmation procedure正式评审规程formal review procedure同级评审指导书PR guidebook技术评审规程technical review procedure同级评审策划规程PR planning procedure正式评审申请表formal review application技术评审申请表technical review application评审工作分析报告review analysis report评审工作表review working form评审准备数据表review preparation metric form同级评审计划PR plan评审记录和缺陷跟踪表 review record and defect tracking record系统测试数据和测试环境设计system testing metrics and testing environment design部件测试数据和测试环境设计component testing metrics and testing environment design部件测试用例component testing use-case系统测试用例system testing use-case系统测试方案system testing scheme部件测试方案component testing scheme接受系统测试检查单 system testing checklist接受产品集成测试检查单 product integration testing checklist接受部件测试检查单 component testing checklist接受First off测试检查单 FIRST OFF testing checklistFirst off测试计划Fist Off testing plan测试计划testing plan产品集成测试计划product integration testing plan测试问题记录表testing issue record单个自由产品测试总结 independent product testing summary测试报告testing report测试总结testing summary产品集成测试报告product integration testing report代码走查规程code walk-through procedure单元测试规程unit testing procedure制定确认策划规程validation planning procedure确认规程validation procedure需求确认方法描述requirement validation methods description 产品确认方法描述product validation methods description确认计划书模板validation plan template产品验收控制程序product acceptance processFIRST OFF规程Fist off procedure产品发布规程product release procedure产品移交规程product delivery procedure系统集成控制程序system integration process系统集成项目测试验收规程acceptance procedure for system integration project testing系统集成项目维护规程 maintenance procedure for system integration project售后服务控制程序post-sales service control process客户服务请求处理表handle form for customer service application 客户服务请求解决情况统计表statistics for closure status of customer service application客户满意度调查表customer satisfaction questionnaire客户满意度统计分析报告statistics analysis report for customer satisfaction客户满意改进方案customer satisfaction improvement plan售后客户档案(原有文件) post-sales customer profile ( original documents)维护项目控制程序maintenance project control process一级维护任务单the 1st level maintenance tasks form维护项目立项报告initiating report for maintenance project 维护项目工作计划working plan for maintenance project现场服务记录on-site service record现场培训记录on-site training record维护项目总结报告summary report for maintenance project二级任务单the 2nd tasks form项目结束通知单project closure notification项目决算报告project settlement report软件维护控制程序software maintenance control process维护需求记录表maintenance demands record软件维护申请表software maintenance application软件维护记录单software maintenance formAcceptance Testing--可接受性测试一般由用户/客户进行的确认是否可以接受一个产品的验证性测试. actual outcome--实际结果被测对象在特定的条件下实际产生的结果.Ad Hoc Testing--随机测试测试人员通过随机的尝试系统的功能,试图使系统中断.algorithm--算法(1)一个定义好的有限规则集,用于在有限步骤内解决一个问题;(2)执行一个特定任务的任何操作序列.algorithm analysis--算法分析一个软件的验证确认任务,用于保证选择的算法是正确的、合适的和稳定的,并且满足所有精确性、规模和时间方面的要求.Alpha Testing--Alpha测试由选定的用户进行的产品早期性测试.这个测试一般在可控制的环境下进行的.analysis--分析(1)分解到一些原子部分或基本原则,以便确定整体的特性;(2)一个推理的过程,显示一个特定的结果是假设前提的结果;(3)一个问题的方法研究,并且问题被分解为一些小的相关单元作进一步详细研究.anomaly--异常在文档或软件操作中观察到的任何与期望违背的结果.application software--应用软件满足特定需要的软件.architecture--构架一个系统或组件的组织结构.ASQ--自动化软件质量(Automated Software Quality)使用软件工具来提高软件的质量.assertion--断言指定一个程序必须已经存在的状态的一个逻辑表达式,或者一组程序变量在程序执行期间的某个点上必须满足的条件.assertion checking--断言检查用户在程序中嵌入的断言的检查.audit--审计一个或一组工作产品的独立检查以评价与规格、标准、契约或其它准则的符合程度.audit trail--审计跟踪系统审计活动的一个时间记录.Automated Testing--自动化测试使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多.Backus-Naur Form--BNF范式一种分析语言,用于形式化描述语言的语法baseline--基线一个已经被正式评审和批准的规格或产品,它作为进一步开发的一个基础,并且必须通过正式的变更流程来变更.Basic Block--基本块一个或多个顺序的可执行语句块,不包含任何分支语句.basis test set--基本测试集根据代码逻辑引出来的一个测试用例集合,它保证能获得100%的分支覆盖.behavior--行为对于一个系统的一个函数的输入和预置条件组合以及需要的反应.一个函数的所有规格包含一个或多个行为.benchmark--标杆/指标/基准一个标准,根据该标准可以进行度量或比较.Beta Testing--Beta测试在客户场地,由客户进行的对产品预发布版本的测试.这个测试一般是不可控的.big-bang testing--大锤测试/一次性集成测试非渐增式集成测试的一种策略,测试的时候把所有系统的组件一次性组合成系统进行测试.Black Box Testing--黑盒测试根据软件的规格对软件进行的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子.bottom-up testing--由低向上测试渐增式集成测试的一种,其策略是先测试底层的组件,然后逐步加入较高层次的组件进行测试,直到系统所有组件都加入到系统.boundary value--边界值一个输入或输出值,它处在等价类的边界上.boundary value coverage--边界值覆盖通过测试用例,测试组件等价类的所有边界值.boundary value testing--边界值测试通过边界值分析方法来生成测试用例的一种测试策略.Boundary Value Analysis--边界值分析该分析一般与等价类一起使用.经验认为软件的错误经常在输入的边界上产生,因此边界值分析就是分析软件输入边界的一种方法.branch--分支在组件中,控制从任何语句到其它任何非直接后续语句的一个条件转换,或者是一个无条件转换.branch condition--分支条件branch condition combination coverage--分支条件组合覆盖在每个判定中所有分支条件结果组合被测试用例覆盖到的百分比. branch condition combination testing--分支条件组合测试通过执行分支条件结果组合来设计测试用例的一种方法.branch condition coverage--分支条件覆盖每个判定中分支条件结果被测试用例覆盖到的百分比.branch condition testing--分支条件测试通过执行分支条件结果来设计测试用例的一种方法.branch coverage--分支覆盖通过测试执行到的分支的百分比.branch outcome--分支结果见判定结果(decision outcome)branch point--分支点branch testing--分支测试通过执行分支结果来设计测试用例的一种方法.Breadth Testing--广度测试在测试中测试一个产品的所有功能,但是不测试更细节的特性.bug--缺陷capture/playback tool--捕获/回放工具参考capture/replay toolCapture/Replay Tool--捕获/回放工具一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程.这类工具一般在GUI测试中用的较多. CASE--计算机辅助软件工程(computer aided software engineering) 用于支持软件开发的一个自动化系统.CAST--计算机辅助测试在测试过程中使用计算机软件工具进行辅助的测试.cause-effect graph--因果图一个图形,用来表示输入(原因)与结果之间的关系,可以被用来设计测试用例.certification--证明一个过程,用于确定一个系统或组件与特定的需求相一致.change control--变更控制一个用于计算机系统或系统数据修改的过程,该过程是质量保证程序的一个关键子集,需要被明确的描述.code audit--代码审计由一个人、组或工具对源代码进行的一个独立的评审,以验证其与设计规格、程序标准的一致性.正确性和有效性也会被评价.Code Coverage--代码覆盖率一种分析方法,用于确定在一个测试套执行后,软件的哪些部分被执行到了,哪些部分没有被执行到.Code Inspection--代码检视一个正式的同行评审手段,在该评审中,作者的同行根据检查表对程序的逻辑进行提问,并检查其与编码规范的一致性.Code Walkthrough--代码走读一个非正式的同行评审手段,在该评审中,代码被使用一些简单的测试用例进行人工执行,程序变量的状态被手工分析,以分析程序的逻辑和假设. code-based testing--基于代码的测试根据从实现中引出的目标设计测试用例.coding standards--编程规范一些编程方面需要遵循的标准,包括命名方式、排版格式等内容. Compatibility Testing--兼容性测试测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等.complete path testing--完全路径测试completeness--完整性实体的所有必须部分必须被包含的属性.complexity--复杂性系统或组件难于理解或验证的程度.Component--组件一个最小的软件单元,有着独立的规格Component Testing--组件测试computation data use--计算数据使用一个不在条件中的数据使用. computer system security--计算机系统安全性计算机软件和硬件对偶然的或故意的访问、使用、修改或破坏的一种保护机制.condition--条件一个不包含布尔操作的布尔表达式,例如:Acondition coverage--条件覆盖通过测试执行到的条件的百分比.condition outcome--条件结果条件为真为假的评价.configuration control--配置控制配置管理的一个方面,包括评价、协调、批准、和实现配置项的变更. configuration management--配置管理一套技术和管理方面的原则用于确定和文档化一个配置项的功能和物理属性、控制对这些属性的变更、记录和报告变更处理和实现的状态、以及验证与指定需求的一致性.conformance criterion--一致性标准判断组件在一个特定输入值上的行为是否符合规格的一种方法. Conformance Testing--一致性测试测试一个系统的实现是否和其基于的规格相一致的测试.consistency--一致性在系统或组件的各组成部分和文档之间没有矛盾,一致的程度. consistency checker--一致性检查器一个软件工具,用于测试设计规格中需求的一致性和完整性.control flow--控制流程序执行中所有可能的事件顺序的一个抽象表示.control flow graph--控制流图通过一个组件的可能替换控制流路径的一个图形表示.conversion testing--转换测试用于测试已有系统的数据是否能够转换到替代系统上的一种测试. corrective maintenance--故障检修用于纠正硬件或软件中故障的维护.correctness--正确性软件遵从其规格的程度.correctness--正确性软件在其规格、设计和编码中没有故障的程度.软件、文档和其它项满足需求的程度.软件、文档和其它项满足用户明显的和隐含的需求的程度. coverage--覆盖率用于确定测试所执行到的覆盖项的百分比.coverage item--覆盖项作为测试基础的一个入口或属性:如语句、分支、条件等.crash--崩溃计算机系统或组件突然并完全的丧失功能.criticality--关键性需求、模块、错误、故障、失效或其它项对一个系统的操作或开发影响的程度.criticality analysis--关键性分析需求的一种分析,它根据需求的风险情况给每个需求项分配一个关键级别. cyclomatic complexity--循环复杂度一个程序中独立路径的数量.data corruption--数据污染违背数据一致性的情况.data definition--数据定义一个可执行语句,在该语句上一个变量被赋予了一个值.data definition C-use coverage--数据定义C-use覆盖在组件中被测试执行到的数据定义C-use使用对的百分比.data definition C-use pair--数据定义C-use使用对一个数据定义和一个计算数据使用,数据使用的值是数据定义的值.data definition P-use coverage--数据定义P-use覆盖在组件中被测试执行到的数据定义P-use使用对的百分比.data definition P-use pair--数据定义P-use使用对一个数据定义和一个条件数据使用,数据使用的值是数据定义的值.data definition-use coverage--数据定义使用覆盖在组件中被测试执行到的数据定义使用对的百分比.data definition-use pair--数据定义使用对一个数据定义和一个数据使用,数据使用的值是数据定义的值.data definition-use testing--数据定义使用测试以执行数据定义使用对为目标进行测试用例设计的一种技术.data dictionary--数据字典(1)一个软件系统中使用的所有数据项名称,以及这些项相关属性的集合.(2)数据流、数据元素、文件、数据基础、和相关处理的一个集合. data flow analysis--数据流分析一个软件验证和确认过程,用于保证输入和输出数据和它们的格式是被适当定义的,并且数据流是正确的.data flow coverage--数据流覆盖测试覆盖率的度量是根据变量在代码中的使用情况.data flow diagram--数据流图把数据源、数据接受、数据存储和数据处理作为节点描述的一个图形,数据之间的逻辑体现为节点之间的边.data flow testing--数据流测试根据代码中变量的使用情况进行的测试.data integrity--数据完整性一个数据集合完全、正确和一致的程度.data use--数据使用一个可执行的语句,在该语句中,变量的值被访问.data validation--数据确认用于确认数据不正确、不完整和不合理的过程.dead code--死代码在程序操作过程中永远不可能被执行到的代码.Debugging--调试发现和去除软件失效根源的过程.decision--判定一个程序控制点,在该控制点上,控制流有两个或多个可替换路由. Decision condition--判定条件判定内的一个条件.decision coverage--判定覆盖在组件中被测试执行到的判定结果的百分比.decision outcome--判定结果一个判定的结果,决定控制流走哪条路径.decision table--判定表一个表格,用于显示条件和条件导致动作的集合.Depth Testing--深度测试执行一个产品的一个特性的所有细节,但不测试所有特性.比较广度测试. design of experiments--实验设计一种计划实验的方法,这样适合分析的数据可以被收集.design-based testing--基于设计的测试根据软件的构架或详细设计引出测试用例的一种方法.desk checking--桌面检查通过手工模拟软件执行的方式进行测试的一种方式.diagnostic--诊断检测和隔离故障或失效的过程.dirty testing--肮脏测试参考负面测试(negative testing)disaster recovery--灾难恢复一个灾难的恢复和重建过程或能力.documentation testing--文档测试测试关注于文档的正确性.domain--域值被选择的一个集合.domain testing--域测试参考等价划分测试(equivalence partition testing)dynamic analysis--动态分析根据执行的行为评价一个系统或组件的过程.Dynamic Testing--动态测试通过执行软件的手段来测试软件.embedded software--嵌入式软件软件运行在特定硬件设备中,不能独立于硬件存在.这类系统一般要求实时性较高.emulator--仿真一个模仿另一个系统的系统或设备,它接受相同的输入并产生相同的输出. End-to-End testing--端到端测试在一个模拟现实使用的场景下测试一个完整的应用环境,例如和数据库交互,使用网络通信等.entity relationship diagram--实体关系图描述现实世界中实体及它们关系的图形.entry point--入口点一个组件的第一个可执行语句.Equivalence Class--等价类组件输入或输出域的一个部分,在该部分中,组件的行为从组件的规格上来看认为是相同的.equivalence partition coverage--等价划分覆盖在组件中被测试执行到的等价类的百分比.equivalence partition testing--等价划分测试根据等价类设计测试用例的一种技术.Equivalence Partitioning--等价划分组件的一个测试用例设计技术,该技术从组件的等价类中选取典型的点进行测试.error--错误IEEE的定义是:一个人为产生不正确结果的行为.error guessing--错误猜测根据测试人员以往的经验猜测可能出现问题的地方来进行用例设计的一种技术.error seeding--错误播种/错误插值故意插入一些已知故障(fault)到一个系统中去的过程,目的是为了根据错。
软件配置管理控制程序
配置管理控制程序历史记录目录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在项目策划阶段由项目经理负责筹建。
配置管理控制程序
配置管理控制程序配置管理控制程序是指为了管理软件系统的各种配置项,确保软件系统的正确配置和版本控制而设计的一套程序。
配置管理控制程序的主要任务是对软件系统配置项进行管理、记录、跟踪、审批和控制,以确保软件系统在不同环境下运行的稳定性和一致性。
配置管理控制程序主要包括以下几个方面的功能:1. 配置项管理:对软件系统中的各种配置项进行分类、管理和记录。
配置项可以是软件代码、库文件、配置文件、脚本等,也可以是硬件设备、网络配置等。
配置项管理需要记录配置项的属性、依赖关系、版本信息等,以便于后续的跟踪和控制。
2. 版本控制:对软件系统中的配置项进行版本控制,确保在不同的开发、测试和生产环境中使用的都是正确的版本。
版本控制可以通过使用版本控制系统来实现,例如使用Git、SVN等工具进行代码的版本管理。
版本控制可以记录每个配置项的版本号、变更历史以及相应的开发者信息,以方便日后的追溯和回滚。
3. 变更管理:当需要对软件系统的配置项进行变更时,需要经过严格的变更管理流程。
变更管理包括变更请求的提交、变更审批和变更执行等步骤,以确保变更的正确性和可控性。
变更管理还需要记录每个变更请求的详细信息、审批流程、变更影响等,以便于后续的分析和评估。
4. 配置项跟踪:配置项跟踪是指对每个配置项的状态进行实时跟踪,以了解其所处的状态和位置。
配置项跟踪可以帮助了解配置项的变更历史、当前状态以及相关的文档和测试结果等信息。
配置项跟踪可以通过配置管理数据库来实现,该数据库记录了每个配置项的详细信息、所处环境和状态,以便于对其进行管理和查找。
5. 发布管理:发布管理是指将经过测试和验证的软件配置项部署到生产环境中的过程。
发布管理需要确保发布的配置项与预期的一致,并记录发布时间、发布者、发布结果等信息。
发布管理还需要实施回滚计划,以应对发布中可能出现的问题。
配置管理控制程序的设计需要考虑以下几个方面的因素:1. 可扩展性:配置管理控制程序需要支持各种不同的配置项类型、配置项关系和配置项依赖关系。
软件工程中的软件配置管理工具
软件工程中的软件配置管理工具软件配置管理(Software Configuration Management,SCM)是软件工程中的重要环节,它涉及到对软件开发过程中的各种软件和文档进行版本控制、变更管理、发布管理等。
为了更高效地进行软件配置管理,各种软件配置管理工具应运而生。
本文将介绍几种常见的软件配置管理工具及其特点和应用场景。
一、版本控制工具版本控制是软件配置管理中非常重要的一环,能够追踪和管理软件开发过程中代码的变更。
以下是几种常用的版本控制工具:1. Git:Git 是目前最流行的分布式版本控制系统之一。
它具有分支管理、合并冲突解决、代码回滚等功能,非常适用于团队协作的软件开发项目。
2. SVN:SVN 是集中式版本控制系统,与 Git 不同,SVN 的主要特点是服务器上有一个中央仓库来保存版本信息,开发者需要从服务器获取最新代码才能进行开发。
3. Mercurial:Mercurial 也是一种分布式版本控制工具,它与 Git 类似,但在使用上更加简单,较适合小型项目和个人开发者使用。
二、构建工具构建工具能够自动化地将源代码编译、打包、部署等操作,提高软件交付的效率和质量。
以下是几种常用的构建工具:1. Maven:Maven 是 Java 程序的构建和依赖管理工具,它使用项目对象模型(Project Object Model,POM)来管理项目的依赖关系和构建配置,可以自动下载所需的库文件,大大简化了项目的构建过程。
2. Ant:Ant 是另一款 Java 构建工具,与 Maven 不同的是,Ant 是基于脚本的构建工具,使用 XML 文件来描述构建过程。
Ant 可以根据项目的需求编写自定义的构建脚本,灵活性较高。
3. Gradle:Gradle 是一个基于 Groovy 语言的构建工具,它融合了Maven 和 Ant 的优点,具有更强的灵活性和可扩展性,适用于复杂的构建任务。
三、自动化测试工具自动化测试工具可以自动执行测试用例,验证软件的功能和性能。
软件配置管理控制程序
配置管理控制程序北京XX科技发展有限公司YYMMDD历史版本文件审核单文件批准单目录1.引言 (1)1.1.编写目的 (1)1.2.适用范围 (1)1.3.预期读者 (1)1.4.名词解释 (1)1.5.角色和职责 (4)2.过程描述 (5)2.1.概述 (5)2.2.制定配置管理计划 (6)2.2.1.概述 (6)2.2.2.入口准则 (6)2.2.3.输入工作产品 (6)2.2.4.主要步骤 (6)2.2.5.出口准则 (7)2.2.6.输出工作产品及质量记录 (7)2.3.配置库管理 (7)2.3.1.概述 (7)2.3.2.入口准则 (7)2.3.3.输入工作产品 (7)2.3.4.主要步骤 (7)2.3.5.出口准则 (9)2.3.6.输出工作产品及质量记录 (9)2.4.版本构造 (9)2.4.1.概述 (9)2.4.2.入口准则 (9)2.4.3.输入工作产品 (9)2.4.4.主要步骤 (10)2.4.5.出口准则 (10)2.4.6.输出工作产品及质量记录 (11)2.5.版本发布 (11)2.5.1.概述 (11)2.5.2.入口准则 (11)2.5.3.输入工作产品 (11)2.5.4.主要步骤 (11)2.5.5.出口准则 (12)2.5.6.输出工作产品及质量记录 (12)2.6.变更控制 (12)2.6.1.概述 (12)2.6.2.入口准则 (13)2.6.3.输入工作产品 (13)2.6.4.主要步骤 (13)2.6.5.出口准则 (14)2.6.6.输出工作产品及质量记录 (14)2.7.配置审计 (14)2.7.1.概述 (14)2.7.2.入口准则 (15)2.7.3.输入工作产品 (15)2.7.4.主要步骤 (15)2.7.5.出口准则 (16)2.7.6.输出工作产品及质量记录 (16)3.度量要求 (16)4.评审要求 (16)5.裁剪指南 (17)6.附录 (17)6.1.相关程序、作业指导书和指南 (17)6.2.输出工作产品及质量记录 (17)7.参考资料 (18)1.引言1.1. 编写目的本文档描述了配置管理的目的及作用、参加配置管理活动的角色及其职责、配置管理的实施过程等内容,以指导公司的配置管理活动。
GJB9001C软件配置管理程序(含完整表单)
GJB9001C软件配置管理程序(含完整表
单)
简介
本文档旨在规范软件配置管理程序,并包含完整的表单。
软件配置管理是软件工程的重要环节,它涉及到软件的版本控制、变更管理、配置项管理等内容,以确保软件的稳定性和可靠性。
目标
本文档的目标是确保软件配置管理的有效性和正确性,为软件开发项目提供科学的管理方案。
程序
1. 配置项标识
- 确定并标识所有的配置项,包括软件、文档、硬件等。
- 对每个配置项进行唯一的标识,以便追踪和识别。
2. 版本控制
- 对所有软件和文档配置项进行版本控制。
3. 变更管理
- 对于软件和文档配置项的变更,按照变更管理流程进行处理。
- 变更流程包括变更申请、评审、批准、实施和验证等阶段。
4. 配置管理计划
- 制定配置管理计划,明确配置管理的责任和流程。
5. 配置项控制
- 对配置项进行控制,确保其安全性和可用性。
6. 配置项审计
- 对配置项进行定期的审计,以确保其符合相关标准和规范。
7. 表单
- 附带完整的表单,包括软件配置项登记表、变更申请表、变
更评审表等。
结论
本文档提供了一个完整的软件配置管理程序,并包含了相应的表单。
通过执行这个程序,可以更好地管理和控制软件开发项目中的配置项,提高软件的质量和可维护性。
配置管理程序
1 定义对构成软件产品的各配置项(包括软件项和技术文档)的标识、管理、更改、防护活动进行控制,防止非预期地使用软件产品配置,保证软件项目生成的产品在软件生命周期中的完整性和正确性。
2 时机在《开发计划》评审通过后。
3 资源a) 项目负责人制定《配置管理计划》报软件产品部经理批准,并负责计划的组织实施;b) 项目组成员执行《配置管理计划》的要求;c) 品质管理部负责配置项标识的分配;d) 公司网络管理员负责杀毒软件的更新。
4 输入a) 《可行性分析报告》、或《方案建议书》、或《投标书》,提供几种形式由《销售运作决策表》中确定;b) 合同书(除内部立项的项目外);c) 《开发计划》。
5 过程描述5.1 作业流程5.2 《配置项标识申请单》编制项目负责人填写《配置项标识申请单》,向品质管理部申请技术文档编号和项目编号。
在整个配置管理活动中都要以申请得到的编号进行标识。
同时品质管理部提供公司配置管理服务器和产品管理服务器上存放的文件夹。
编号规则见5.7软件配置项标识。
5.3 《配置管理计划》编制《配置管理计划》具体规定了在某一项目开发过程中应执行的配置管理的职责、活动和要求。
项目的《配置管理计划》由项目负责人在开发策划阶段编制,并由软件产品部(包括产品研发部、OA产品部、项目部,以下同)经理审批。
《配置管理计划》应包括以下内容:a) 项目负责人在配置管理活动中的职责。
一般而言项目负责人全面负责配置管理活动的要求。
项目负责人或其指定的项目组成员负责具体的配置管理活动的执行,如制定配置管理计划、指定配置管理员,在CVS中开设相应的目录或文件夹,整理有关的文档,督促大家及时形成有关的文档,并兼任产品版本生成工作;b) 定义角色(如:项目组人员、配置管理人员)的职责和所需的资源(如:人员的权限分配、工具、计算机设备);c) 配置项的管理要求。
可针对软件项及文档分别规定。
项目开始研制后,品质管理部必须在公司配置管理服务器上为该项目建立开发库文件夹、产品库文件夹、临时库文件夹。
第13章 软件配置管理
第27页
三、测试的层次与内容
1.软件测试的层次
软件测试工作包括两个层次:
测试工作的组织与管理,包括制定测试方法与规范、控 制测试进度、管理测试资源。 测试工作的实施,包括编制符合标准的测试文档、研制 测试环境、与开发组织协作实现各阶段的测试活动。
第28页
2.软件测试的内容 软件测试工作可以分为4个方面:
建立控制项; 重构任何修订版的某一项或者某一文件; 利用加锁技术防止覆盖; 当一个修订版时要求输入变更描述; 提供比较任意两个修订版的使用工具,采用增量存储方式; 提供对修订版历史和锁定状态的报告功能;
提供归并功能;
允许在任何时候、任何版本; 控制权限的设置;
渐进模型的建立;
提供各种控制报告。
第18页
实施软件配置管理,主要包括以下活动:
制定配置管理计划;
确定配置标识;
版本管理; 变更控制; 系统整合; 配置审核。
第11页
一、制定软件配置计划
制定配置管理计划的过程就是确定软件配置管理的解决方
案;
项目经理和软件配置管理委员会(SCCB)根据项目的开 发计划确定各个里程碑和开发策略;
一、软件配置管理概述
软件配置管理(SCM)是一组针对软件产品的追踪和控制
活动,它贯穿于项目生命周期的始终,并代表着软件产品接
受各项评审。 IEEE对SCM的论述如下:“软件配置管理由适用于所有 软件开发项目的最佳工程实践组成,无论是采用分阶段开发, 还是采用快速原型进行开发,甚至包括对现有软件产品进行
统,其测试工作涉及大量的人力和物力,有效的测试工作
管理是保证有效测试工作的必要前提。 3)测试环境的建立:设计环境、实施环境和管理环境 。
软件项目管理第12章 软件配置管理
第12章 软件配置管理
(2) 减少施工费用。利用配置管理工具,建立开发管理 规范,把版本管理档案链接到公司内部的Web服务器上,内 部人员可直接通过浏览器访问,工程人员通过远程进入内部 网,进而获取所需的最新版本。开发人员无须亲自到现场, 现场工程人员通过对方系统管理员收集反馈意见,书面提交 到公司内部开发组的项目经理,开发组内部讨论决定是否修 改,并做出书面答复。这样可以同时响应多个项目,防止开 发人员被分配到各个项目引起力量分散、人员紧缺等问题, 避免开发人员将大量的时间和精力浪费在旅途中,同时节约 大量的差旅费用。
第12章 软件配置管理
配置项类
数据库设计说明
配置项实例
数据库设计说明V1.1
数据库设计说明V1.2
数据库设计说明V2.0
图12.3 软件配置项类及实例(配置项和配置项的不同版本类似于面 向对象的类和实例)
第12章 软件配置管理
(3) 代码对象库的建立。软件代码是软件开发人员脑力 劳动的结晶,也是软件公司的宝贵财富,长期开发过程中形 成的各种代码对象就如同一个个已生产好的标准件一样,是 快速生成系统的组成部分。一个长期的事实是:一旦某个开 发人员离开工作岗位,其原来所做的代码便基本成为垃圾, 无人过问。究其原因,就是没有专门对各个开发人员的有用 代码对象进行管理,没有把使用范围扩大到公司一级,没有 进行规范化,没有加以说明和普及。配置管理对软件对象管 理提供了一个平台和仓库,有利于建立公司级的代码对象库。
第12章 软件配置管理
这4种状态相互之间的联系具有方向性,沿图中实线箭 头所指方向的状态变化是允许的,虚线表示为了验证或检测 某些功能或性能而重新执行相应的测试,一般不沿虚线变化。
2. 软件配置项的版本 软件配置项也有不同的版本,配置项和配置项的版本类 似于面向对象的类和实例。配置项可以看成是类,版本看成 是类的实例。例如,图l2.3表示了数据库设计说明的配置项。 数据库设计说明的不同版本对应于数据库设计说明的实例。 配置项的不同版本是从最原始的配置项(相当于配置项类)逐 渐演变而来的,尽管每个都不相同,但是具有相关性。
软件控制程序
软件控制程序1目的和范围按软件工程方法,设计和开发计算机软件,对生产和服务提供使用的计算机软件以及用于规定要求的监视和测量的计算机软件进行确认和管理,确保产品质量。
适用于本公司军工产品软件的开发、引进和运行维护,生产和服务提供使用的计算机软件以及用于规定要求的监视和测量的计算机软件的控制和管理。
2规范性引用文件下列文件中的条款通过引用而成为本标准的条款。
凡注日期或版次的引用文件,其后的任何修改单(不包含勘误的内容)或修订版均不适用于本标准,但提倡使用本标准的各方探讨使用其最新版本的可能性。
凡未注日期或版次的引用文件,其最新版本适用于本标准。
GB/T19000-2008质量管理体系基础和术语3术语和定义GB/T19000-200确立的术语和定义适用于本标准。
3.1软件软件是指计算机程序及其有关的数据和文档,也包括固化了的程序。
3.2重要软件重要软件是指它的故障会影响到人身安全,会导致重大经济损失或社会损失的软件。
3.3软件开发库软件开发库是指在软件生命周期的某一个阶段期间,存放与该阶段软件开发工作有关的计算机可读信息和人工可读信息的库。
3.4软件受控库软件受控库是指在软件生命周期的某一个阶段结束时,存放作为阶段产品而释放的,与软件开发工作有关的计算机可读信息和人工可读信息的库。
软件配置管理就是对软件受控库中的各个软件项进行管理,因此软件受控库也叫做软件配置管理库。
3.5软件产品库软件产品库是指在软件生命周期的组装与系统测试阶段结束后,存放最终产品而后交付给用户运行或在现场安装的软件的库。
3.6软件配置软件配置是指一个软件产品在软件生命周期各个阶段所产生的各种形式(机器可读或人工可读)和各种版本的文档、程序及其数据的集合。
该集合中的每一个元素称为该软件产品软件配置中的一个配置项。
4职责4.1技术中心软件所a)软件项目负责人对软件设计开发的技术质量负责;b)负责对用于规定要求的监视和测量的计算机软件进行确认;c)产品或项目负责人组织编写质量保证大纲/计划;d)负责软件设计开发策划、输入、输出、评审、验证、确认、更改、技术状态管理等的实施。
软件项目配置管理
系统规格说明 软件需求规格说明 软件设计说明 源代码 测试计划、过程、数据
可运行系统
()
配置控制委员会() 评估变更 批准变更申请 在生存期内规范变更申请流程 对变更进行反馈 与项目管理层沟通
本章要点
一、软件项目配置管理基本概念 二、软件项目配置管理过程 三、案例分析
基本活动
配置标识
变更控制
状态统计
认
库
证
变更控制系统-举例
4、基线审核
配置管理活动审核 基线审核
5、配置状态统计
检查配置管理系统以及内容, 检测配置项变更历史
标准828-1998规定 用于计算配置状态的最小数据集包括
被批准的配置项 配置项的所有请求的变化状态 配置项所有被批准的变更实现状态
评估一个配置系统状态
变更请求的数量 变更请求的历史报告 存储量的增长 配置管理系统以及在运作中发生异常的次
配置项的拆分例子
(某医疗网站)需求规格 辅助功能 性能 产品目录 医务管理 医疗专业区 首页
配置项的标识
配置项被唯一的标识
配置项的标识约定举例
QTD-School–RM–SRS-v1.0
公司:3个字符 项目:最长10个字符 类型:最长5个字符 编号:最长8位数字 版本号:V m.n
配置项的跟踪
案例
2、配置管理环境建立、建立配置管理库
软件配置管理库是用来存储所有基线配 置项及相关文件的等内容的系统,是在 软件产品的整个生存期中建立和维护软 件产品完整性的主要手段。
配置管理库实例
配置管理建库实例
受控操作
Check in 评审/验证
受控库
Check out
变更控制 流程
新版本
软件配置管理方法
软件配置管理方法软件配置管理是一种重要的软件开发流程,它控制软件配置项(Software Configuration Item,SCI)的变更和管理,以确保软件的质量、可靠性和稳定性。
软件配置管理方法包括制定配置管理计划、进行配置管理、变更管理、版本管理和发布管理等步骤。
一、配置管理计划配置管理计划是软件配置管理的基础,它包括了管理软件配置的整个过程。
配置管理计划需要定义以下内容:1.配置项:确定要进行配置管理的软件配置项,包括哪些文件以及它们在项目运行过程中的关系。
2.配置管理工具:选择需要使用的配置管理工具和软件,包括工具和软件的使用方式、培训方式以及使用时需要遵守的规程。
3.变更管理过程:确定变更管理的过程、变更申请表格的设计、变更控制流程的设计、变更控制标准的制定、变更评估的流程、变更授权的流程以及变更跟踪与审核的流程等。
4.版本管理:确定软件的版本管理策略,如何标识版本、如何控制版本、版本管理的权限等。
5.发布管理:定义软件发布的标准和程序,包括发布的流程和程序、发布的标准、发布的人员的职责和权限,以及发布后的跟踪管理和问题解决等。
二、配置管理配置管理是软件配置管理的核心内容。
它包括对软件配置项的标识、控制、追踪和报告等工作。
1.配置项标识:为每一个可被处理的软件配置项指定一个独特的标识,以便于软件配置管理人员对其进行识别、跟踪和处理。
2.配置项控制: 对软件配置项进行全面的控制,确保所有变更都得到授权和管理,并避免因为错误的变更导致的软件问题。
3.配置项追踪: 对软件配置项进行全面的追踪,包括变更历史、变更的原因、变更的影响和变更后的状态等。
4.配置项报告: 生成软件配置项的报告,包括汇总报告、版本报告和变更报告等。
这些报告可以帮助软件配置管理人员更好地控制和管理软件。
三、变更管理变更管理对于软件配置管理来说是非常重要的一部分。
它通过制定变更申请、变更评估、变更授权、变更实施以及变更审核等流程,确保任何对于软件配置项的变更都经过了严格的流程和授权,以避免对软件造成不必要的影响。
软件配置管理规范流程
1概述目的本文档主要目的在于规范项目配置管理活动,确保配置项正确地唯一标识并且易于存取,保证基线配置项的更改受控,明确基线状态,在整个软件生命周期中建立和维护项目产品的完整性和可追溯性;适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动,针对项目不同在流程上作适当的删减;配置管理可采用各种工具及手工办法,本文件以CVS并行版本系统配置管理工具为例,规定公司的配置管理办法,使用其他工具时也可对应本文件的要求参照执行;术语和缩略语软件配置管理Software Configuration Management,SCM软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程;是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施;配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置;配置项Configuration Item,CI凡是纳入配置管理范畴的工作成果统称为配置项,配置项逻辑上组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试的;每个配置项的主要属性有:名称、标签、文件状态、版本、作者、日期等;所有配置项都被保存在配置库里,确保不会混淆、丢失;配置项及其历史记录反映了软件的演化过程;基线Baseline在配置管理系统中,基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”;每一个基线都是其下一步开发的出发点和参考点;基线确定了元素配置项的一个版本,且只确定一个版本;一般情况下,基线一般在指定的里程碑处创建,并与项目中的里程碑保持同步;每个基线都将接受配置管理的严格控制,基线中的配置项被“冻结”了,不能再被任何人随意修改,对其修改要严格地按照变更控制的过程进行;在一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形成下一个基线;基线的主要属性有:名称、标签、版本、日期等;权限与职责研发总经理助理1 审核变更请求;项目经理Project Manager,PM1 审核批准配置管理计划;2 接收或拒绝小范围的变更申请;3 召集评估变更;4 提出配置管理的建议和要求;5 配合配置管理员的工作;配置管理员Configuration Management Officer,CMO1 编写配置管理计划;2 执行版本控制和变更控制方案;3 制定访问控制策略;4 负责项目的配置管理工作,包括搭建环境、权限分配、配置库的建立、配置项的控制等;5 配置管理工具的日常管理与维护;6 配置库的日常操作和维护;7 负责配置审核并提交报告;8 根据配置部署表单编译发布版本,并维护版本;9 对开发人员进行相关的培训;10 对配置审核中发现的不符合项,拟订纠正措施,要求相关责任人进行纠正;11 监督项目组成员规范的执行情况;开发人员Developer1 根据确定的配置管理计划和相关规定,提交配置项和基线;2 负责项目组内部测试;3 负责软件集成和版本生成;4 按照软件配置管理工具的使用模型来完成开发任务;2 实施细则配置项管理配置项的范围软件配置可包括以下几方面:开发文档,代码,第三方控件、插件,参考资料,测试文档,用户文档,项目管理文档,验收文档等;l 项目文档主要指:立项建议书、可行性分析报告、技术建议书、用户需求说明书、项目计划、项目进度计划、项目阶段性计划、产品需求规格说明书、概要设计报告、详细设计、数据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以及上述文档的评审记录;l 代码主要指:源代码等;l 工具主要指:脚本文件、插件、第三方控件等;配置项基线管理结合SPP和ISO9000的相关规定,配置管理员根据配置管理规范及配置管理计划,对配置项进行分阶段管理,每一阶段正式评审通过后纳入受控库,作为该项目的一个基线;l 项目启动:配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档,评审或审批通过后建立发布基线;l 需求阶段:系统调研后开发人员进行需求分析,并整理产品需求规格说明书;产品需求规格说明书经过客户的确认后,建立需求基线;如需升级版本则必须通过评审或审批并得到客户的确认;l 项目计划:需求分析完成后即可制定项目的开发计划,包括项目计划和主要下属计划;包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划;项目开发计划评审通过后,建立项目计划基线;l 设计:系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计;针对用户需求规格说明书进行系统设计,配置时应说明系统设计的版本与需求分析报告版本的对应关系;设计说明书评审或审批通过后,建立设计基线;l 编码设计实现:编码按功能模块分子项目,即每个模块记作一个配置项;代码在提交项目组系统测试时建立Beta版本,系统测试产品正式发布后建立Version版本;l 测试:单元测试和系统测试;单元测试通过提交单元测试报告,项目启动后应提交系统测试计划,系统测试完成后应提交系统测试报告;配置时应说明测试的版本与编码版本的对应关系;系统测试完成后建立测试基线;l 版本发布:项目组提交部署表单,CMO根据部署表单进行编译,发布测试服务器上,并对版本进行维护;同时将发布的版本上传到文档服务器上备份;l 交付与验收:在交付前配置审核完成后建立产品基线,产品基线包含程序以及有关文档配置项,包括交付文档、代码、工具等;l 产品部署:部署时应包括操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档;l 相关资料:相关资料也应作为配置项纳入配置管理,此部分包括:1 相关法律、法规;必须遵照或项目组约定的技术规范;2 与客户或项目组内部重要的交互信息记录,如会议记录、会谈记录、e-mail和MSN 记录等;版本控制文档的版本控制所有文档的管理纳入配置管理库,用版本控制工具进行统一管理;文档的版本控制主要通过文档的名称、文档控制页及版本控制工具的标签来实现,主要分为以下几类:版本变化型文档命名方式:文档名称+子系统名称可选适用文档:项目计划、配置管理计划、质量保证计划、项目进度计划、用户需求规格说明书、产品需求规格说明书、体系结构设计报告、数据库设计报告、详细设计报告、用户操作维护手册、测试用例等;示例:项目计划.doc详细设计_SP门户.doc标签结构:大版本+ 子系统简称+ 版本号+ 日期标签控制说明版本信息l 大版本:可选,表示同一项目为不同用户定制的版本;l 子系统简称:可选,当一个项目有多个子系统时,为区分不同子系统而设置;l 版本号:采用Vs_x_y的形式;l 日期:纳入基线管理的日期,用8位表示,如说明:a. 文档发布名称采用文档名+ Vs_x_y的形式,文档的版本号应该和版本控制工具中相应标签上的版本号一致;b. 对文档的修改需要从配置管理库中取到本地进行;c. 对于文档小的修改,如文字错误,格式调整,变更Vs_x_y中的y来区别如:V1_0_1;d. 文档内容没有大的增加和删节,意思表述没有发生重大的变化,版本标识通过版本工具中加上x标签来表示如:V1_1_0,以及在文档内部控制页标注变化来表示;e. 文档有重大增加和删节,意思表述有重大变化的,版本标识通过在相应文档加上s 标签来表示如:V2_0_0;f. 对于纳入基线库的文档的修改需要提交变更申请,经批准才能进行修改,并且修改的内容要经再次评审才能重新纳入基线库,作为后续阶段的参考文档;时间区别型文档命名方式:文档名称+撰写时间适用文档:文档名称有明确的含义,需要用时间标识的日常性文档;如周例会会议纪要,项目月计划,项目月总结,阶段性计划等等;示例:周例会会议纪要时间序号型文档命名方式:文档名称+人员姓名拼音+撰写时间+序列号适用文档:测试报告示例:单元测试报告其他文档:对于不能按照前四种类型进行命名的文档会议纪要:会议纪要YYYYMMDD示例:9月9日召开的项目启动会命名为:会议纪要项目启动.doc评审报告:评审报告YYYYMMDD同”会议纪要”要求一致;示例:10月9日召开的项目总体方案评审命名为:评审报告总体方案.doc发行版本表示发行版本采用标签说明,结构如下:大版本+ 版本类型+ 版本号+ 子系统简称拼音+日期+序号大版本:可选,表示同一项目为不同用户定制的版本;子系统简称:可选,当一个项目有多个子系统时,为区分不同子系统而设置;版本类型:分为3种Beta表示项目组内部测试,标签:Release系统测试,标签:Version正式发行版,标签:版本号对于Version正式发行版是必须要注明的,而其它可选;发行产品基线在版本号前加Version,如Version_1, Version_2, Version_3….表示分支;Version_1_0, Version_1_1, Version_1_2… 表示在分支Version_1上的标签;Version_0_0, Version_0_1, Version_0_2… 表示在主线上的标签;配置库管理配置库的分类配置库统一由配置管理员负责管理,服务器端使用,客户端主要使用乌龟CVS;配置库目录结构如下:配置库的建立所有项目应建立配置库,以便管理各配置项,配置管理员组织建立配置库;程序库主要通过设置版本的分支来实现对配置项权限管理:1开发库:开发人员相对比较自由的存储空间,开发人员可以在自己的权限范围内任意取出提交;2基线库:配置管理员有最高权限,其余相关人员均为读的权限,发生变更时变更人员须提交变更申请后方可修改基线库内的配置项;文档评审通过后,文档严格受控;由配置管理员将通过评审后的文档移植到基线库里同时将该配置项从开发库移除;代码一般在移交系统测试时纳入基线库受控,可根据项目的具体情况设置基线;3产品库:产品库的产品均出自于基线库,产品库存储的产品用于交付和存档;配置三库统一由配置管理员管理,根据各开发阶段的实际情况定制相应的版本选取规则,来保证开发活动的正常运作;在变更发生时,应及时做好基线的推进;分配权限项目开始后配置管理员编写配置库目录结构表明确项目组成员以及相关人员的权限;在wincvs里有三种权限,读r、写w、添加删除c权限;在开发库内,文档部分项目组成员有rcw权限,其他相关人员只r权限;代码部分项目组成员有rcw权限,其他相关人员没有任何权限;在基线库内,项目组成员仅有r权限,其他相关人的权限视情况而定;在产品库内,所有人没有任何权限;配置管理员在三库内均拥有最高权限;配置变更控制变更的分类软件及其相关文档的变更按照变更的影响范围进行分类:1A级:变更会影响系统级的需求、外部接口、产品价格或者交付期;这类变更必须经过配置管理委员会审核并有客户批准和确认;2B级:变更会影响配置项间的功能接口、内部功能的设计、组件;这类变更必须由项目经理或配置管理委员会的批准和认可;3 C级:变更只会影响配置项内部或对BUG问题的处理;这类变更可以由配置项的管理人员负责批准;系统测试前变更控制流程:系统测试完毕发布release版本后变更控制流程图2 变更控制流程变更请求的提出a.由技术支撑中心汇集顾客意见,影响到需求变更则填写配置项变更控制报告,并提交给配置管理员;b.配置管理员对申请表是否清晰、明确和完整性进行审查,若发现变更不明确或不完整,应返回申请者;对通过审查的变更申请分配变更ID,以便跟踪和记录变更信息;评估变更a.配置管理员将配置项变更控制报告发送给项目经理或者其他授权人员,由项目经理负责对变更进行评估;b.项目经理对变更进行分解,一般的BUG修正不需要审批直接由项目经理决定是否需要变更;新增功能或对整个项目影响重大的变更必须由研发总助审批通过后方可变更;变更评估文档在完成变更评估后发送给配置管理员;变更实施和确认a.变更被批准后,项目经理提交变更实施进度计划,开发人员开始实施变更,并详细记录变更的内容;质量部对变更的实施进行跟踪;b.对于代码变更,必须进行回归测试,以确保变更没有引入新的Bug;另外与变更相关的文档必须修订,以反映变更;当变更以及测试完成后,进行提交;c.通过测试后,质保人员需对变更进行审核,审核的范围一般涉及以下方面:测试记录;变更请求;配置项的检入及检出;文件的命名;版本的编号;a.审核后,由配置管理员更新到基线库中;配置状态报告目的记录和报告整个软件生命周期演化状态;记录内容配置状态报告记录的内容包括:1 软件和文档的标识;2 目前状态;3 基线演化状态;4 变更状态;5 版本交付信息等;生成报告配置管理报告自第一个基线创建时建立,由配置管理系统生成,及时反映当前配置状态;配置审核类别配置审核分为:1功能配置审核Functional Configuration Audit,FCA:审核软件功能是否与需求一致,并符合基线文档要求,通常要审查测试文档等;2 物理配置审核Physical Configuration Audit,PCA:审核要交付的组成项是否存在,是否包含所有必需的项目,如正确版本的源代码、资源、文档、安装说明等等;执行时机通常选择以下几种情况由质量保证人员负责实施配置审核:1软件产品交付或是软件产品正式发行前;2软件开发的阶段工作结束后;3在产品维护工作中,定期地进行;不符合项处理对配置审核中发现的不符合现象,配置管理员进行记录,并交由责任部门限期进行纠正,配置管理员负责纠正措施的验证;所有的不符合项报告均关闭后,才能发布新版本;发行管理通过配置审核后,经项目经理批准,由配置管理员负责生产新版本;交付管理这里“交付”是指从配置库中提取配置项,交付给客户或项目外的人员;交付出去的配置项必须有据可查,避免发生混乱;流程如下:1交付人向质量部申请;2质量部如果不同意交付,则拒绝交付配置项;如果同意交付,配置管理员应给出详细的交付清单;3交付人验收后签字;。
软件配置管理标准化流程全套
软件配置管理标准化流程配置管理(Configuration Management, CM)的目的是通过执行版本控制、变更控制等规程,以及使用配置管理软件,来保证所有配置项的完整性和可跟踪性。
配置管理是对工作成果的一种有效保护。
配置管理过程域是SPP模型的重要组成部分。
本规范阐述了配置管理过程域的四个主要规程:◆制定配置管理计划[SPP-PROC-CM-PLANNING]◆配置库管理[SPP-PROC-CM-LIB]◆配置项版本控制[SPP-PROC-CM-VERSION]◆配置项变更控制[SPP-PROC-CM-CHANGE]上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。
建议用户根据自身情况(如商业目标、研发实力等)适当地修改本规范,然后推广使用。
17.1 介绍项目研发和管理过程中会产生许许多多的工作成果,例如文档、程序和数据等,它们都应当被保存起来,以便查阅和修改。
如果把所有文件一股脑地塞进计算机里,那么使用起来肯定很麻烦。
毫无疑问,人们应当将文件分门别类、有条理地保存起来。
凡是纳入配置管理范畴的工作成果统称为配置项(Configuration Item, CI),配置项主要有两大类:(1)属于产品组成部分的工作成果,例如需求文档、设计文档、源代码、测试用例。
(2)项目管理和机构支撑过程域产生的文档。
这些文档虽然不是产品的组成部分,但是值得保存。
每个配置项的主要属性有:名称、标识符、文件状态、版本、作者、日期等。
所有配置项都被保存在配置库里,确保不会混淆、丢失。
配置项及其历史记录反映了软件的演化过程。
基线(Baseline)由一组配置项组成,这些配置项构成了一个相对稳定的逻辑实体。
基线中的配置项被“冻结”了,不能再被任何人随意修改(见变更控制规程)。
基线通常对应于开发过程中的里程碑(Milestone),一个产品可以有多个基线,也可以只有一个基线。
软件工程管理-(4)软件配置管理方案
试结果
系统测试数据、系统测试结果、操作手册、 安装手册
以上任何需要变更的软件配置项
2、软件配置
软件配置是一个软件产品在生存期各个阶段的不同形 式(记录特定信息的不同媒体)和不同版本的程序、 文档及相关数据的集合,或者说是配置项的集合。
时)
6. 源代码清单
7、测试规格说明 a.测试计划和步骤 b.测试用例和记录的结果
8、操作和安装手册 9、可执行程序
– 特别是在不同省市阶段试用和现场测试的时候,用户提出 要变更需求,软件项目组汇总用户的需求,并经过审批同 意了变更请求,为此,修改了软件需求规格说明书
– 项目组将更改后、新的软件需求规格说明书交给了软件设 计小组,设计小组为此更改了设计。更改后的软件设计涉 及诸多的软件模块和数据设计,为此导致许多的模块和源 程序代码和可执行代码发生了变化
– 由于某些编码的变化的是在当地开发,项目组很难清晰地 了解哪些作了变化、做了什么样的变化
软件产品进行配置管理(2/2)
– 由此带来的新的问题是,项目组未能及时将这些变化通知 给相关、受影响的小组和人员,从而出现软件产品之间的 不一致(设计与编码不一致),所开发的产品没有完全符合 和满足用户的需求
用户2: A、B、C、D、E和G、H
(二)软件配置管理
1、什么是软件配置管理
(1)ISO 9000-3 :1997
配置管理是一个管理学科,它对配置项(包括软件项)的开发和支持生 存期给与技术上的和管理上的指导。配置管理的应用取决于项目的规模、 复杂程度和风险大小。
(2) W.Babich 的解释
软件配置管理能协调软件开发,使混乱减少到最小。软件配置管理是一 种标识、组织和控制修改的技术,目的是最有效的提高生产率。
软件配置管理规范流程
软件配置管理规范流程随着软件开发和应用的日益广泛,软件配置管理变得越来越重要。
一个好的软件配置管理规范流程不仅可以提高软件的开发效率和质量,还可以方便软件的维护和升级。
下面介绍一下软件配置管理规范流程的几个方面。
一、版本控制版本控制是软件配置管理的核心,通过版本控制可以追踪软件的历史变更记录,防止不同版本之间的冲突和漏洞。
常见的版本控制工具有Git、SVN等。
在使用版本控制工具时需要注意以下几点:1.分支管理:在团队开发的过程中,不同的成员可能需要同时对同一个文件进行修改,并且还需要保证修改不会对其他的成员造成影响。
通过分支管理可以解决这个问题。
2.版本号规范:版本号的格式应该是“主版本号.次版本号.修订号”,不同版本号之间只能升级,不能降级。
在记录版本号的同时,还需要添加Change log,记录本次版本的变更内容。
二、构建管理构建管理是将软件源代码编译成可执行的程序的过程。
构建管理要求构建过程可以自动化和可重复,以避免人为因素对构建过程的影响。
在构建管理中,首先需要定义构建项目和构建脚本,以确保构建过程中所有的操作都可以自动化。
其次,需要使用构建工具来实现自动化编译、打包等操作。
常见的构建工具有Maven、Gradle 等。
三、发布管理发布管理是将软件部署到生产环境的过程,这个过程需要谨慎对待,因为一旦出现问题就会影响业务的正常运行。
在发布管理中,需要注意以下几点:1.生产环境和开发环境应该完全一致,以保证部署的代码在生产环境中能够正常运行。
2.发布前需要进行必要的测试,以确保代码的稳定性和安全性。
测试包括功能测试、性能测试、安全测试等。
3.需要进行灰度发布,将新功能逐步上线,以避免一次性上线造成系统崩溃。
四、文档管理文档管理是软件配置管理中不可或缺的一部分。
除了源代码和构建文件之外,还需要对软件的文档进行管理。
在文档管理中,需要注意以下几点:1.文档应该与代码一起托管在版本控制系统中,以方便追溯和管理。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
配置管理控制程序历史记录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开发组负责审核《配置管理计划》任务列表中与开发有关的内容2.7 QA 组负责审核《配置管理计划》任务列表中与QA有关的内容3.2过程说明软件配置管理是通过配置标识、配置控制、配置状态说明和配置审核等一系列活动, 整个软件生存周期建立和维护软件产品的完整性。
4过程活动4. 1活动一.制定配置管理计划 4.1.1进入准则已经指派了项目配置管理员3过程综述3.1流程图括动一.制定KSft 理片划活动二.配習项标识裕动三.变更控制活功典,配占状念圮实在项目的 活动五.配se 审薔弟匕编评渦[代也活功入产品口常备份《项目已定义标准过程》《软件开发计划》草稿4.1.3任务任务1:确定项目CM的要求配置管理员通过《项目已定义标准过程》、《软件开发计划》草稿等项目前期文档了解项目对配置管理的要求。
任务2:确定配置管理环境在创建配置库之前,配置管理员要确定本项目的配置管理工具,包括用于配置管理的计算机软、硬件资源。
明确配置管理权限,制定权限列表,详见《文档权限列表》。
确立配置库结构:根据项目实际情况和组织的《配置管理标准》,确立配置库的具体结构。
公司的开发库,受控库和产品库建立在公司的cvs服务器(192.168.1.154)上,如果项目经理要求(例如封闭开发需要),开发库可以建立在项目组自己的服务器上。
策划阶段,《配置管理计划》批准之前,开发库(等同于临时库)应建立起来,策划阶段文档纳入开发库;《配置管理计划》批准之后,配置库正式建立。
任务3:确定基线及配置项列表。
详见 6.2.4以及《配置管理标准》。
任务4:确定项目配置管理活动和任务配置管理员根据项目的大小,确定项目需要进行的配置管理活动和任务,估计配置管理的工作量。
任务5:建立项目定义的标准规程。
任务6:编写《配置管理计划》配置管理员根据项目的《项目已定义标准过程》和《软件开发计划》,按照公司的《配置管理计划》模板,编写《配置管理计划》。
任务7:审批《配置管理计划》配置管理计划必须先提供给相关工作组,如开发组,PPQA组,系统测试组进行协商,然后在项目策划阶段评审会上对其进行评审。
审批通过的《配置管理计划》由项目经理签字后,纳入配置管理,并由配置管理员通知所有受影响的组。
《配置管理计划》4.1.5退出准则《配置管理计划》已经通过评审并纳入受控库。
4.2活动二.配置项标识4.2.1进入准则开始制订《配置管理计划》已提交配置项《文件归档申请单》已提交4.2.2输入提交的配置项《文件归档申请单》4.2.3任务任务1:配置项标识配置管理员和项目经理在项目策划期间讨论项目将产生的配置项以及隶属的基线,文档类的配置项参见项目开发计划中的工作产品列表,可进行添加和删减;代码类配置项以策划阶段《项目估计书》中列出的模块为单位进行设定。
配置管理员和项目经理还需确定配置项(包括基线)的入库时间,相应的访问权限,并且根据配置项命名的规定(参见《配置管理标准》),对配置项进行唯一的标识,结果记录到《配置项清单》、《配置管理计划》中。
任务2:创建配置项在软件开发期间,开发人员依据《配置项清单》和配置项命名规则创建配置项,在配置项提交后,由配置管理员更新《配置项清单》。
任务3:建立/维护配置管理库配置管理员根据《配置管理计划》中确立的配置库结构创建配置管理库,同时根据《配置管理标准》分配访问权限。
任务4:配置项入库配置项入库指工作产品从开发库进入受控库,配置管理员在受控库中对配置项做同样的标识,详见《配置管理标准》。
任务5:建立基线在《配置管理计划》中预先明确的时间或阶段点上下表中的相应角色遵照下面五个步骤建立基对于计划外形成的基线,开发人员需提出申请,经SCCB审核批准后正式确立。
424输出项目基线《配置状态报告》项目配置库《配置项清单》425退出准则工作产品已经置入配置库的管理之下所有工作产品都有唯一的配置项标识4.3活动三.变更控制详见《配置变更子过程》。
4.4活动四.配置状态纪实4.4.1进入准则新的配置项要提交配置管理计划里规定的提交报告时间已到项目经理需要查询配置状态信息442输入《配置管理计划》配置库《文件归档申请单》《配置项变更申请单》4.4.3任务任务1建立配置状态记录A:配置管理员在《配置管理计划》批准后应初始化《配置变更跟踪表》、《配置状态报告》,检查项目的前期文档是否已经纳入项目的配置管理,并更新《配置状态报告》。
B:随着项目进展,CC根据按收到的《文件归档申请单》、《配置项变更申请单》和提交的工作产品更新《配置状态报告》、《配置项清单》和《配置变更跟踪表》。
任务2:配置项状态报告配置管理员按照《配置管理计划》定期(每两周一次)发布《配置状态报告》(参见模板)。
在SCCB会议后,配置管理员应发布《会议记录》。
产品对内发布或对外发布时配置管理员应提交《产品发布报告》。
完成配置审核后,配置管理员发布审核报告。
这些报告在提交给项目经理的同时,也要放到配置管理库里,能让所有开发人员以及SCCB、PPQA阅读这些状态报告。
如果项目经理要求,配置管理员可能还需要提供包含以下内容或部分内容的文档:未实施的变更列表;最近一个月提出的变更请求;目前在实施变更的人员统计;多少变更项没有审批;测试期间的一周变更次数;当前高等级变更数等。
4.4.4输出《配置状态报告》《配置变更跟踪表》《配置项清单》445退出准则报告都已经完成并提交4.5活动五.配置审核详见《配置审核管理规程》。
4.6活动六.编译源代码4.6.1.进入准则源代码提交送测462输入软件送测单463任务配置管理员对送测代码进行编译,如果编译不通过,返回送测人;如果编译通过,送测试部。
4.6.4输出软件送测单4.6.5退出准则编译通过4.7活动七.工作产品发布详见《配置项发布管理规程》。
4.8活动八.产品日常备份详细见《产品日常备份规程》。
5过程测量(1)配置管理员每月最后一天对该月配置管理活动进行测量,将测量数据存储在《配置管理活动测量记录表》中;(2)根据《过程度量规格说明书》中有关配置管理过程的度量要求,对测量数据进行分析,并将结果记录在《配置管理活动测量记录表》中,报告给度量专员和项目经理。
(3)EPG负责人通过度量报告,分析项目配置管理过程的性能,积累历史数据,改进配置管理过程。
6相关文件《配置管理标准》《配置变更子程序》《配置审核管理规程》《配置项发布管理规程》《产品日常备份规程》质量记录。