IT软件项目管理ch08

第8章IT软件项目配置管理（2次、4课时）第8章IT软件项目配置管理8.1软件配置管理概念8.2软件配置管理基本活动8.3软件配置管理组织8.4软件测试8.5配置管理工具8.6思考题8.1软件配置管理概念8.1.1软件配置及软件配置项8.1.2软件配置管理8.1.1软件配置及软件配置项配置管理(ConfigurationManagement，CM)的目的是建立和维护在整个软件生命周期中软件项目产品的完整性和一致性。CM的主要目标是使修改部分更容易被适应，并减少变化中所花费的工作量。配置管理在一个IT软件项目中是必须的，特别是对那种规模大且周期较长的项目。软件配置管理是始终贯穿整个软件过程的保护性活动。软件配置管理的一系列活动被设计成为：标识变化、控制变化和保证变化被适当地实现，以及向其他可能的人员报告变化的一个有力和有效工具。随着软件过程的进展，软件配置项(SoftwareConfigurationItems，SCI)迅速增长。一般，系统的软件规格说明了产生软件项目计划和软件需求说明以及与硬件相关的文档资料，然后在这些文档基础上又产生了其他的一些文档，从而形成了一个信息层次。8.1.2软件配置管理软件配置管理(SoftwareConfigurationManagement，SCM)是软件过程的关键要素，是开发和维护各个阶段管理软件演进过程的一种方法和规程。软件配置管理使得整个软件产品的演进过程处于一种可视的状态。软件配置管理作为CMM第2级上的一个关键域(KeyPracticeArea，KPA)，在整个软件的开发活动中占有很重要的位置。及多少识别和修改，多少错误仍然未被发现等；也可以用于对费用和进度参数的预测。软件配置管理活动：8.1.2软件配置管理软件配置管理功能：软件配置管理配置标识变更控制配置状态统计配置审核图8.1软件配置管理功能8.2软件配置管理概念8.2.1制定软件配置计划8.2.2确定配置标识8.2.3版本管理8.2.4变更控制8.2.5系统整合8.2.6状态报告8.2.7配置审计8.2.1制定软件配置计划项目经理和配置管理委员会(CCB)根据项目的开发计划确定各个里程碑和开发策略。根据CCB的规划，制定详细的配置管理计划，交CCB审核。CCB通过配置管理计划后交项目经理批准，发布实施。软件配置管理的主要流程如下：8.2.1制定软件配置计划文档命名约定。正式文档的关系(项目计划书、需求定义、设计报告、测试报告都是正式文档)。确定负责验证正式文档的人员。确定负责提交配置管理计划的人员。在已建立了要管理的文档后，配置管理计划必须定义以下问题：8.2.1制定软件配置计划根据已文档化的规程为每个软件项目制定软件配置管理计划。这个规程一般规定：在整个项目计划的初期制订软件配置管理计划，并与整个项目计划并行；由相关小组审查软件配置管理计划，管理和控制软件配置管理计划。将已文档化且经批准的软件配置管理计划作为执行配置管理活动的基础。该计划应该包括：需要被执行的配置管理活动、活动的日程、指派的责任和需要的资源(包括人员、工具、计算机设施等)；配置管理的需求和由软件开发小组和其他相关小组执行的配置管理活动一样。制定配置管理计划中，必须定义以下问题：8.2.2确定配置标识有效地配置管理，需要确定配置标识：(1)建立一个配置管理库作为存放软件基线的仓库。基线是指已经通过正式评审和认可的标准，作为以后进一步开发的基础，并且只有通过正式的更改控制规程才能进行更改的规程说明或者产品。当软件基线生成时，就纳入软件基线库中。存取软件基线内容的工具和规程就是配置管理库系统。(2)标识置于配置管理下的软件工作产品。置于配置管理之下的软件工作产品，主要包括可交付给客户的软件产品(如软件需求文档和代码等)，以及与这些软件产品等同的产品项或者生成这些软件产品所需要的产品项(如编译程序、运行平台等)。所谓配置标识就是为系统选择配置项，并在技术文档中记录其功能特征和物理特性。(3)根据文档化的规程，提出、记录、审查、批准和跟踪所有配置项/配置单元的更改要求和问题报告。(4)根据文档化的规程记录配置项/配置单元的状态。该规程一般规定：详细地记录配置管理行动，让每个成员都知道每个配置项/配置单元的内容和状态，并且能够恢复以前的版本；保存每个配置项/配置单元的历史，并维护其当前状态。8.2.3版本管理版本变迁演化：Obj1.0Obj1.1Obj1.2Obj1.4Obj2.0Obj2.1Obj1.1.1Obj1.1.2Obj1.3图8.2版本变迁演化12345变体8.2.4变更控制变更的预期效益如何？变更的成本如何？项目变更进程后，对项目成本的影响如何？变更对软件质量的影响如何？变更对项目资源分配的影响如何？变更可能会影响到项目后续的哪些阶段？变更会不会导致出现不稳定的风险？一般需要考虑以下因素:8.2.4变更控制项目名称变更提案请求者，提案日期变更内容变更分析者，分析日期被变更影响的部分与变更相关的其他部分对变更的评估变更的优先级变更的实现变更的预测成本变更提交给配置管理委员会(CCB)的日期配置管理委员会决定，做出决定的日期变更实现者，变更实现日期提交给质量控制小组(QA)的日期质量控制小组的决定提交给项目经理的日期项目经理的评价变更提案所包括内容:8.2.5系统整合是否所有组成系统的成分都包括在整合说明书中？是否所有组成系统的成分都有合适的版本？是否所有的数据文件都是可以获得的？在组成系统的所有成分中，是否有数据文件命名相同的？是否有合适版本的编辑器和其他工具？必须要考虑的问题有:8.2.5系统整合可执行文件系统整合者UNIX/NT/OS2逻辑结构到物理结构的映射整合工具文件1文件2……文件N系统逻辑描述图8.4系统整合逻辑过程8.2.6状态报告配置库结构和相关说明。开发起始基线的构成。当前基线位置及状态。各基线配置项集成、分布的情况。各私有开发分支类型的分布情况。关键元素的版本演进记录。其他应予报告的事项。主要内容:8.2.7配置审计配置审计的主要作用:是作为变更控制的补充手段，来确保某一变更需求已被切实地执行和实现。在某些情况下，配置审计被作为正式的技术审核的一部分，但当软件配置管理是一个正式的活动时，配置审计活动就应该由软件质量管理人员单独执行。8.3软件配置管理组织8.3.1软件配置管理组织构成8.3.2软件配置管理组织方针8.3.1软件配置管理组织构成制定和修改项目的组织结构和配置管理策略。批准、发布配置管理计划。决定项目起始基线和开发里程碑。接受并审阅配置控制委员会的报告。项目经理职责主要包括如下几项:8.3.1软件配置管理组织构成授权建立软件基线和标识配置项/配置单元。代表项目经理和受到软件基线影响的所有小组的利益。在IT项目管理中，受影响的组包括：质量保证组、配置管理组、工程组(包括硬件工程组、软件工程组)、系统测试组、合同管理组、文档支持组等。审查和审定对软件基线的更改。审定由软件基线数据库中生产的产品和报告。软件配置控制委员会SCCB主要负责以下工作:8.3.1软件配置管理组织构成创建和管理项目的软件基线库。制定、维护和发布SCM计划、标准和规程。标识置于配置管理下的软件工作产品集合。管理软件基线的库的使用。更新软件基线。生成基于软件基线的产品。记录SCM活动。生成和发布SCM报告。软件配置管理小组SCM负责协调和完成以下的工作:8.3.2软件配置管理组织方针明确地分配每个项目的SCM责任。在项目的在整个生命周期中实施SCM。SCM为外部交付的软件产品、内部软件产品指定用于项目内部的支持工具，如编译器、调试器等，以便实施配置管理。软件项目中，需要建立和使用一个仓库(如数据库)用于存放配置项/配置单元和相关的SCM记录。这个仓库的内容将成为软件基线库。使用该仓库的工具和规程就是配置管理库系统。置于配置管理之下的、并作为单独实体的工作产品就成为配置项。通常，配置项分为若干配置组件，配置组件分为若干配置单元。在一个硬/软件系统中，可能把全部软件视为一个单独的配置项，也可能把软件部分分为多个配置项。实际上，配置项/配置单元就是指置于配置管理之下的元素。定期审核软件基线和SCM活动。方针主要包括如下内容:8.4软件测试8.4.1软件测试的概念8.4.2软件测试原则与策略8.4.3软件测试完成的标准8.4.4软件测试步骤8.4.5软件测试工作流程8.4.6软件测试的自动化8.4.1软件测试的概念黑盒测试法一般称为功能测试或数据驱动测试，在测试过程中，把系统看成是一个黑盒子，不考虑程序的内在逻辑，而是只根据需求规格说明书的要求来检查程序的功能是否符合它的功能需求说明。白盒测试法又称为结构测试或逻辑驱动测试，在测试过程中，允许测试人员对程序的内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。软件测试的方法和技术是多种多样的。从测试是否针对系统的内部结构和具体实现算法的角度看，通常可分为两类：白盒测试法(结构测试)和黑盒测试法(功能测试)。8.4.2软件测试原则与策略应当把“尽早和不断地测试”作为开发人员的一个座右铭。程序员和程序设计机构原则上不应该测试自己设计的程序。制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。在测试过程中，不仅要有确定的输入数据，而且也要确定预计的输出数据。在测试过程中，不仅要有合理的输入数据，而且也要有不合理的输入数据。在测试过程中，除了检查程序是否完成了预定的功能外，还要测试程序是否还有不应该存在的功能和“后门”。测试完成后，妥善保存一切测试过程文档和全部的测试用例(数据)，并作为软件和文档的一个组成部分，测试的重现性往往要靠测试文档。程序中存在错误的概率与该程序中已经发现的错误数一般是成正比的。重复测试一定要引起充分的重视，由于修改一个错误而引起更多错误出现的现象并不少见。测试原则:8.4.2软件测试原则与策略测试策略:CU软件项目SRDIVST需求分析系统设计编码单元测试集成测试确认测试系统测试图8.5软件测试的策略8.4.3软件测试完成的标准搞清楚完成的标准,以及软件故障模型:测试时间t预期的错误密度，l(t)在测试过程中收集的实测数据图8.6错误密度与测试时间的函数关系每小时错误数l0f(t)=(1/p)㏑(l0pt+1)8.4.4软件测试步骤1.单元测试2.集成测试3.确认测试4.系统测试5.Alpha和Beta测试开发是自顶向下的,测试是自底向上的,测试内容有:8.4.5软件测试工作流程总过程：立项阶段需求分析阶段设计阶段编码阶段单元测试阶段集成测试阶段系统测试阶段验收测试阶段结项阶段图8.8软件测试总的过程8.4.5软件测试工作流程需求阶段的测试工作流程:需求阶段工作培训编写用户需求需求评审需求变更进入下一阶段变更需求图8.9需求阶段的测试工作流程需求说明书需求变更记录系统测试方案总体测试方案8.4.5软件测试工作流程设计编码阶段的测试工作流程:图8.10设计、编码阶段的测试工作流程概要设计集成测试计划设计方案评审详细设计单元测试方案系统测试验证标准单元测试报告进入下阶段变更设计需求相关文档详细设计方案评审变更设计编码单元测试修改8.4.5软件测试工作流程集成测试、系统验收测试阶段工作流程:图8.11集成测试、系统测试阶段工作流程集成测试集成测试计划测试评估系统测试产品化工作报告系统测试方案系统测试报告测试工作结束产品化工作验收测试上一阶段质量合格证书8.4.6软件测试的自动化测试个案的生成，包括测试输入、标准输出、测试操作指令等。测试的执行写控制，包括单机与网络分布运行、夜间及假日运行、测试个案调用控制、测试对象、范围、版本控制等。测试结果与标准输出的对比。不吻合的测试结果的分析、记录、分类和