搜索
说明注释1注释疑点1、对某些数据如QA检查单、测量数据，放在项目管理工具中是否属于受到管理和存储？需求跟踪矩阵是否纳入受控库管理？2、非项目开发产生的复用构件、工作环境是否可以不纳入项目受控库，只需要在软件产品提交用户前集成到交付产品中即可？3、文档的版本和代码的版本标识方法不一致，如何解决？配置管理（ConfigurationManagement）SG1：建立基线：建立已确定的工作产品的基线。(EstablishBaselines:Baselinesofidentifiedworkproductsareestablished.)SP1.1确定配置项：确定将纳入配置管理下的配置项、构件及相关的工作产品。(IdentifyConfigurationItems:Identifytheconfigurationitems,components,andrelatedworkproductsthatwillbeplacedunderconfigurationmanagement.）1、一组相关工作产品的一个例子是，产品组件和它的需求，设计，测试用例，验证程序和验证报告。2、当你开发计划时，记录那些重要的你需要控制的东西。计划的这部分在识别配置项时为项目团队提供指导。3、使用标准选择配置项，确保选择的一致性和全面性。4、如果你使用配置管理工具，它会为配置项指定唯一标识符。5、当一个配置项必须被纳入配置管理集时，为了控制项目工作产品，要明确指出项目成员间的期望和建立清晰的目标。疑点：不知道如何做的问题难点：知道如何做，但实际很难落实或无成效的问题创新点：结合本单位情况新的做法，需得到总装认可的问题1、因为这是一个支持过程域，它是由项目和组织决定哪些工作产品受控于配置管理系统和需要的控制级别。2、配置管理系统应收集足够的信息来标识和维护配置项当开发它的人离开后。3、其它可以包括维修手册和测试结果，它们可以为工作产品提供更多深入的了解。4、通常，在计划时确定粒度层次，根据技术和业务需求为配置管理选择要标识的配置项。5、在基线被纳入到（或提升）配置管理系统之前要审查和批准。6、任何重要东西足以确保其完整性的都可以使用配置管理实践。难点创新点LPLLPLLL26、配置管理计划中未对任务书要求提交的部分工作产品（如证明书、履历书、程序框图、评审证明书）进行标识；7、配置管理计划中配置项表中未标识产品基线中的“软件研制质量总结报告”配置管理项；8、配置管理计划中将归零报告作为配置管理项纳入管理，该配置管理项超出了本项目生命周期范围.1、配置管理计划没有对单元测试报告进行标识；2、配置管理计划没有对单元测试报告进行标识，没有对任务书中要求的软件运行数据进行标识并纳入产品基线；3、配置管理计划没有对单元测试报告、用户手册进行标识；5、识别的配置项未包含迭代完成的产品，且包含决策分析表等本项目无需产生的记录类配置项；4、未将开发环境识别为配置项；SP1.2建立配置管理系统：建立并维护配置管理和变更管理系统，来控制工作产品。(EstablishaConfigurationManagementSystem:Establishandmaintainaconfigurationmanagementandchangemanagementsystemforcontrollingworkproducts.)1、制定了《配置标识规范》规程，给出了项目配置管理活动中配置管理项的选择准则及配置管理项的标识方法。规程中定义的配置管理项类型全面，按照文档、程序及源码、数据、过程记录文档、采购的产品、工具等分类标识。2、由软件项目负责人负责建立软件配置项索引，在里面标注所有受控的软件工作产品的标识以及受控时机。在配置管理计划中进行引用，因为项目软件负责人应该是配置管理的第一责任人，便于一配置管理计划管理多个CSCI配置项。1、对配置项粒度的识别一直成为项目组所困扰的问题，尤其是工程类配置项中源代码的管理，不同规模的项目在项目策划时实施WBS拆分中的粒度不同，其配置项识别的粒度也不尽相同，作为EPG人员在对项目组指导时没有这方面指导的标准。由于软件的存在形式不同,配置项的定义难以统一,可定义为单一的.c文件,有的定义为.prj所链接的文件包,有的又定义为UML中一个Package组,是否可以给出一个参考标准?案例注释疑点难点创新点LL案例1、开发库、产品库未按配置管理计划要求建立，入库的部分配置管理项（如任务书）没有相关人标识；2、型号研制计划未按配置管理计划入受控库；1、配置库的物理结构是否需要统一要求？2、开发库、受控库、产品库是否需要物理隔离？还是可以逻辑隔离，但整个配置管理系统备份？3、公司级产品库中产品只是收集各部门产品库的部分内容，同时没有及时更新，存在的意义不大。4、配置管理系统的建立与组织资产库有何区别和联系？能否介绍一些关于组织资产库管理和项目配置管理方面的成功经验？1、大部分组织使用自动化工具进行配置管理。因为从多方面考虑，手工配置管理过程很难维护。2、许多监管系统可以帮助你做配置管理。在你购买之前，要确定你的需求，比较它们与系统的功能。3、不是所有的配置项要求同样级别的控制。有些可能需要更多的控制当他们随着项目的生命周期进展。4、一个正式的配置管理过程通常是根据变更请求，并广泛跟踪和审查所有的变更。5、你必须找到确保所有配置项存取都有的平衡，但存取需求要真实并确认。6、定期审查配置管理系统以确保它满足所服务项目的需要。1、制定了《配置库管理规程》，给出了配置库的建立与管理方法。配置管理系统分开发库、受控库和产品库分别管理。开发库由项目负责人建立并负责管理；受控库由项目CMG建立并负责管理；产品库由所级CMG建立并负责管理2、对于需要经过长期试验验证的软件产品，提出一级产品库和二级产品库的概念。一级产品库存放定型之后的软件产品，管理要求等同于传统意义的产品库。而二级产品库存放定型之前，用于试验验证阶段的软件产品，但受控级别高于受控库、低于一级产品库（主要体现在变更控制方面），由组织级的配置管理组负责管理。3、建立数据管理库，和配置管理三库一起称为四库，数据管理库没有版本控制和变更控制，只有数据分类和命名规则。用于存放过程数据。4、今年开发了基于Starteam的项目过程资产收集工具。5、出入库要有批准手续，在确保产品一致性的前提下，简化出入库手续。例如入库的产品直接发给项目组，不必再办出库手续。3注释1、基线的版本如何规定，包括基线更动后的版本定义2、实际操作时，如何合理设置基线建立时机或准则，以便以较低的变更成本实现有效的控制？3、设置几条基线与哪些因素相关，规模小、周期短的软件项目是否3条基线就够了？4、采用什么技术手段控制配置项及时入库、及时纳入基线。5、配置管理工作始于SCMP，SCMP之前的软件任务书的功能基线相关工作，配置管理员如何开展？6、由于产品研制周期长（经历F、C、S、D等阶段），并且为嵌入式软件，软件研发过程与硬件研制过程紧密结合，由于硬件按阶段管理，所以目前我单位软件管理是把每个研制阶段视为一个软件生存周期过程，同时根据单位实际，产品库定义为设计定型后交付最终用户的工作产品库。那么，F、C、S研制阶段能否只定义阶段性产品基线，并且阶段性产品基线下工作产品放在受控库进行管理（这样管理可能会存在评价时产品库中没有内容，因为可能选择的项目没有进入设计定型过程）？D阶段定义最终交付用户的产品基线，产品基线下工作产品进入产品库进行管理？7、软件产品基线包含哪些内容比较合适？产品库管理和控制的力度？产品基线在生命周期的什么阶段建立？产品基线设置在何时间点合理？8、如何采用有效的基线发布形式，方便快捷的使项目成员知道？能否采用邮件通知的形式，不采用基线发布清单是否合适？9、对外发布的每个不同产品是否都应单独设立一条产品基线？SP1.3建立或发布基线：建立或发布供内部使用和交付给客户的基线。(CreateorReleaseBaselines:Createorreleasebaselinesforinternaluseandfordeliverytothecustomer.)1、在某些方面，配置管理委员会的授权应该是正式的并做记录。2、如果基线发布或使用不是来自配置管理系统，该系统不为它的目的服务，那么丢失基线的完整性的风险会很高。3、为保证项目成员使用配置管理系统，要确保该系统易于使用。疑点创新点LPPP案例1、制定了《配置标识规范》规程，对基线的分类、标识、合并和裁剪给出了明确的准则。配置管理可根据软件开发计划设置基线，如将概要设计基线与详细设计基线合并为设计基线，将编码和单元测试基线与部件测试基线合并为实现基线，但至少应设置功能基线、分配基线和产品基线。2、建立了产品库Ⅰ和产品库Ⅱ两级产品库，产品库Ⅰ是产品完成研制后到设计定型阶段发布到产品档案库（产品库Ⅱ）之间的临时产品库，负责该阶段的软件管理。4、软件任务书指向的型号研制计划未纳入功能基线.1、小软件如何合理设置基线，以便以较低的变更成本实现有效控制？2、嵌入式软件的研制过程与系统和硬件的研制过程和阶段（如F、C、S、D等阶段）密切相关，嵌入式软件产品基线的设置如何与系统阶段结合？如何定义阶段性产品的基线和最终交付的产品基线？3、如何有效设置并管理小软件和嵌入式软件的受控库和产品库？1、项目研制过程中，经常出现上阶段工作产品评审和审签不能及时完成，导致上阶段基线迟迟不能形成，使下一阶段的入口条件不能满足，项目工作又不能等，如何解决这类问题？有什么好的建议2、用户的更改频繁、随意，基线的建立和发布作用不明显，意义不大1、小软件发布基线时是否一定要召开SCCB会议，是否可采用书面审签等简化的方式？2、如何有效定义嵌入式软件的软件生存周期过程，使之与系统和硬件的研制过程有效协调？难点疑点1、PDM中部分基线的建立时间与基线发布报告时间不一致；SG2：跟踪并控制变更：跟踪并控制已纳入配置管理下的工作产品的变更。(TrackandControlChanges:Changestotheworkproductsunderconfigurationmanagementaretrackedandcontrolled.)2、分配基线建立后，软件需求规格说明未放入PDM的基线文档；3、每次迭代后对基线的控制没有明确要求；注释4注释难点创新点LL1、嵌入式软件的变更申请如何与系统和硬件的变更申请统一？2、处于调试或试验阶段的嵌入式软件产品，经常需要与硬件一起进行联调，或根据试验要求对软件参数进行调整。严格按配置项来控制和管理这些变更，效率必然很低，试验现场也不具备相应的条件。如何有效解决此问题？1、变更请求是正式提交工作产品所需修改的说明。如果变更请求记录不完整，它们就很难分析和跟踪。2、变更请求系统通常用于初始基线建立之后。变更请求系统可以跟踪对工作产品做的每次变更。3、数据库为存储和跟踪变更请求提供了一个灵活的环境。4、组织你的变更请求使你能分析它们之间的关系以及这些请求实施的顺序。5、跟踪变更请求直至关闭以确保未解决变更请求不被丢失或忽视。疑点SP2.1跟踪变更请求：跟踪配置项的变更请求。(TrackChangeRequests:Trackchangerequestsfortheconfigurationitems.）这个目标的执行通常是通过建立一个变更请求系统和形成一个主要职责是审查和批准基线变更的配置管理委员会。1、是否必须要有出入库单？是否可用其他方式替代。1、软件出所后配置管理变得困难，往往现场的软件没能及时入库，变更过程也不规范。1、进行变更影响分析时，未按照《配置变更规程》全面分析变更影响，缺少需求影响分析、接口影响分析、进度影响分析等内容；且未见更改的验证证据；2、软件需求规格说明的变更影响分析中未说明对工作量、进度的影响；案例1、通过配置项的变更请求确定工作任务并进行估算和跟踪,在受控库实现小版本快速迭代。2、简化更动记录表单。《更动申请报告表》中明确了所有更动申请记录，包括更动理由和