软件项目配置管理ch08

《软件项目配置管理ch08》由会员分享，可在线阅读，更多相关《软件项目配置管理ch08（39页珍藏版）》请在金锄头文库上搜索。

1、第 8 章IT软件项目配置管理 （2次、4课时）第8章 IT软件项目配置管理n8.1 软件配置管理概念n8.2 软件配置管理基本活动 n8.3 软件配置管理组织 n8.4 软件测试 n8.5 配置管理工具 n8.6 思考题 8.1 软件配置管理概念 n8.1.1 软件配置及软件配置项n8.1.2 软件配置管理 8.1.1 软件配置及软件配置项n配置管理(Configuration Management，CM)的目的是建立和 维护在整个软件生命周期中软件项目产品的完整性和一致性。nCM的主要目标是使修改部分更容易被适应，并减少变化中所 花费的工作量。n配置管理在一个IT软件项目中是必须的，特别是

2、对那种规模大 且周期较长的项目。软件配置管理是始终贯穿整个软件过程的 保护性活动。n软件配置管理的一系列活动被设计成为：标识变化、控制变化 和保证变化被适当地实现，以及向其他可能的人员报告变化的 一个有力和有效工具。 n随着软件过程的进展，软件配置项(Software Configuration Items，SCI)迅速增长。一般，系统的软件规格说明了产生软件 项目计划和软件需求说明以及与硬件相关的文档资料，然后在 这些文档基础上又产生了其他的一些文档，从而形成了一个信 息层次。 8.1.2 软件配置管理 n软件配置管理(Software Configuration Management， S

3、CM)是软件过程的关键要素，是开发和维护各个阶段管理 软件演进过程的一种方法和规程。 n软件配置管理使得整个软件产品的演进过程处于一种可视 的状态。 n软件配置管理作为CMM第2级上的一个关键域(Key Practice Area，KPA)，在整个软件的开发活动中占有很重 要的位置。 n及多少识别和修改，多少错误仍然未被发现等；也可以用 于对费用和进度参数的预测。软件配置管理活动：8.1.2 软件配置管理 软件配置管理功能：软件配置管理配置标识变更控制配置状态统计配置审核图8.1 软件配置管理功能8.2 软件配置管理概念 n8.2.1 制定软件配置计划n8.2.2 确定配置标识n8.2.3 版

4、本管理n8.2.4 变更控制 n8.2.5 系统整合n8.2.6 状态报告n8.2.7 配置审计 8.2.1 制定软件配置计划n项目经理和配置管理委员会(CCB)根据项目的开 发计划确定各个里程碑和开发 策略。n根据CCB的规划，制定详细的配置管理计划，交 CCB审核。nCCB通过配置管理计划后交项目经理批准，发布 实施。软件配置管理的主要流程如下：8.2.1 制定软件配置计划n文档命名约定。n正式文档的关系(项目计划书、需求定义、设计 报告、测试报告都是正式文档)。n确定负责验证正式文档的人员。n确定负责提交配置管理计划的人员。在已建立了要管理的文档后，配置管理计划必须定 义以下问题： 8.

5、2.1 制定软件配置计划n根据已文档化的规程为每个软件项目制定软件配置管理 计划。这个规程一般规定： 在整个项目计划的初期制订软 件配置管理计划，并与整个项目计划并行；由相关小组审 查软件配置管理计划，管理和控制软件配置管理计划。n将已文档化且经批准的软件配置管理计划作为执行配置 管理活动的基础。该计划应该包括：需要被执行的配置管 理活动、活动的日程、指派的责任和需要的资源(包括人员 、工具、计算机设施等)；配置管理的需求和由软件开发小 组和其他相关小组执行的配置管理活动一样。制定配置管理计划中，必须定义以下问题： 8.2.2 确定配置标识 有效地配置管理，需要确定配置标识： (1) 建立一个

6、配置管理库作为存放软件基线的仓库。 基线是指已经通过正式评审和认可的标准，作为以后进一步开发的基础， 并且只有通过正式的更改控制规程才能进行更改的规程说明或者产品。当 软件基线生成时，就纳入软件基线库中。存取软件基线内容的工具和规程 就是配置管理库系统。n (2) 标识置于配置管理下的软件工作产品。 置于配置管理之下的软件工作产品，主要包括可交付给客户的软件产品(如 软件需求文档和代码等)，以及与这些软件产品等同的产品项或者生成这些 软件产品所需要的产品项(如编译程序、运行平台等)。所谓配置标识就是 为系统选择配置项，并在技术文档中记录其功能特征和物理特性。n (3)根据文档化的规程，提出、记

7、录、审查、批准和跟踪所有配置项/ 配置单元的更改要求和问题报告。n (4)根据文档化的规程记录配置项/配置单元的状态。该规程一般规定 ：详细地记录配置管理行动，让每个成员都知道每个配置项/配置单元的内 容和状态，并且能够恢复以前的版本；保存每个配置项/配置单元的历史， 并维护其当前状态。 8.2.3 版本管理 版本变迁演化 ：Obj 1.0Obj 1.1Obj 1.2Obj 1.4Obj 2.0Obj 2.1Obj 1.1.1Obj 1.1.2Obj 1.3图8.2 版本变迁演化12345变体8.2.4 变更控制 n变更的预期效益如何？n变更的成本如何？n项目变更进程后，对项目成本的影响如何？

8、n变更对软件质量的影响如何？n变更对项目资源分配的影响如何？n变更可能会影响到项目后续的哪些阶段？n变更会不会导致出现不稳定的风险？一般需要考虑以下因素 :8.2.4 变更控制 n项目名称n变更提案请求者，提案日期n变更内容n变更分析者，分析日期n被变更影响的部分n与变更相关的其他部分n对变更的评估n变更的优先级n变更的实现n变更的预测成本n变更提交给配置管理委员会(CCB)的日期n配置管理委员会决定，做出决定的日期n变更实现者，变更实现日期n提交给质量控制小组(QA)的日期n质量控制小组的决定n提交给项目经理的日期n项目经理的评价变更提案所包括内容 :8.2.5 系统整合 n是否所有组成系统

9、的成分都包括在整合说明书 中？n是否所有组成系统的成分都有合适的版本？n是否所有的数据文件都是可以获得的？n在组成系统的所有成分中，是否有数据文件命 名相同的？n是否有合适版本的编辑器和其他工具？必须要考虑的问题有 :8.2.5 系统整合 可执行文件系统整合者UNIX/NT/OS2逻辑结构到物理 结构的映射整合工具文件1文件2文件N系统逻辑描述图8.4 系统整合逻辑过程8.2.6 状态报告 n配置库结构和相关说明。n开发起始基线的构成。n当前基线位置及状态。n各基线配置项集成、分布的情况。n各私有开发分支类型的分布情况。n关键元素的版本演进记录。n其他应予报告的事项。主要内容 :8.2.7 配

10、置审计 n配置审计的主要作用: 是作为变更控制的补充 手段，来确保某一变更需求已被切实地执行和实 现。n在某些情况下，配置审计被作为正式的技术审 核的一部分，但当软件配置管理是一个正式的活 动时，配置审计活动就应该由软件质量管理人员 单独执行。 8.3 软件配置管理组织 n8.3.1 软件配置管理组织构成n8.3.2 软件配置管理组织方针 8.3.1 软件配置管理组织构成 n制定和修改项目的组织结构和配置管理策略。n批准、发布配置管理计划。n决定项目起始基线和开发里程碑。n接受并审阅配置控制委员会的报告。项目经理职责主要包括如下几项 :8.3.1 软件配置管理组织构成 n授权建立软件基线和标识

11、配置项/配置单元。n代表项目经理和受到软件基线影响的所有小组 的利益。在IT项目管理中，受影响的组包括：质 量保证组、配置管理组、工程组(包括硬件工程 组、软件工程组)、系统测试组、合同管理组、 文档支持组等。n审查和审定对软件基线的更改。n审定由软件基线数据库中生产的产品和报告。软件配置控制委员会SCCB主要负责以下工作 :8.3.1 软件配置管理组织构成 n创建和管理项目的软件基线库。n制定、维护和发布SCM计划、标准和规程。n标识置于配置管理下的软件工作产品集合。n管理软件基线的库的使用。n更新软件基线。n生成基于软件基线的产品。n记录SCM活动。n生成和发布SCM报告。软件配置管理小组

12、SCM负责协调和完成以下的工作:8.3.2 软件配置管理组织方针 n明确地分配每个项目的SCM责任。n在项目的在整个生命周期中实施SCM。nSCM为外部交付的软件产品、内部软件产品指定用于项目 内部的支持工具，如编译器、调试器等，以便实施配置管 理。n软件项目中，需要建立和使用一个仓库(如数据库)用于存 放配置项/配置单元和相关的SCM记录。这个仓库的内容将 成为软件基线库。使用该仓库的工具和规程就是配置管理 库系统。置于配置管理之下的、并作为单独实体的工作产 品就成为配置项。通常，配置项分为若干配置组件，配置 组件分为若干配置单元。在一个硬/软件系统中，可能把全 部软件视为一个单独的配置项，

13、也可能把软件部分分为多 个配置项。实际上，配置项/配置单元就是指置于配置管理 之下的元素。n定期审核软件基线和SCM活动。方针主要包括如下内容 :8.4 软 件 测 试 n8.4.1 软件测试的概念n8.4.2 软件测试原则与策略n8.4.3 软件测试完成的标准n8.4.4 软件测试步骤n8.4.5 软件测试工作流程n8.4.6 软件测试的自动化 8.4.1 软件测试的概念 n黑盒测试法一般称为功能测试或数据驱动测试，在测试 过程中，把系统看成是一个黑盒子，不考虑程序的内在逻 辑，而是只根据需求规格说明书的要求来检查程序的功能 是否符合它的功能需求说明。n白盒测试法又称为结构测试或逻辑驱动测试

14、，在测试过 程中，允许测试人员对程序的内部逻辑结构及有关信息来 设计和选择测试用例，对程序的逻辑路径进行测试。软件测试的方法和技术是多种多样的。从测试是否针对系统 的内部结构和具体实现算法的角度看，通常可分为两类：白 盒测试法(结构测试)和黑盒测试法(功能测试)。 8.4.2 软件测试原则与策略 n应当把“尽早和不断地测试”作为开发人员的一个座右铭。n程序员和程序设计机构原则上不应该测试自己设计的程序。n制定严格的测试计划，并把测试时间安排得尽量宽松，不要希 望在极短的时间内完成一个高水平的测试。n在测试过程中，不仅要有确定的输入数据，而且也要确定预计 的输出数据。n在测试过程中，不仅要有合理

15、的输入数据，而且也要有不合理 的输入数据。n在测试过程中，除了检查程序是否完成了预定的功能外，还要 测试程序是否还有不应该存在的功能和“后门”。n测试完成后，妥善保存一切测试过程文档和全部的测试用例(数 据)，并作为软件和文档的一个组成部分，测试的重现性往往要 靠测试文档。n程序中存在错误的概率与该程序中已经发现的错误数一般是成 正比的。n重复测试一定要引起充分的重视，由于修改一个错误而引起更 多错误出现的现象并不少见。测试原则 :8.4.2 软件测试原则与策略 测试策略 :C U软件项目SR DIVST需求分析系统设计编码单元测试集成测试确认测试系统测试图8.5 软件测试的策略8.4.3 软

16、件测试完成的标准 搞清楚完成的标准,以及软件故障模型:测试时间 t预期的错误密度，l(t)在测试过程中收集的实测数据图8.6 错误密度与测试时间的函数关系每小时错误数l0f(t)=(1/p)(l0pt+1) 8.4.4 软件测试步骤 n1. 单元测试n2. 集成测试 n3. 确认测试 n4. 系统测试 n5. Alpha和Beta测试 开发是自顶向下的,测试是自底向上的,测试内容有:8.4.5 软件测试工作流程 总过程：立项阶段需求分析阶段设计阶段编码阶段单元测试阶段集成测试阶段系统测试阶段验收测试阶段结项阶段图8.8 软件测试总的过程8.4.5 软件测试工作流程 需求阶段的测试工作流程 :需求阶段工作培训编写用户需求需求评审需求变更进入下一阶段变更需求图8.9 需求阶段的测试工作流程需求说明书需求变更记录系统测试方案总体测试方案8.4.5 软件测试工作流程 设计编码阶段的测试工作流程 :图8.10 设计、