第13章软件项目管理.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * 每个成本因素都根据它的重要程度和对工作量影响大小被赋予一定数值（称为工作量系数）。这些成本因素对任何一个项目的开发工作量都有影响，即使不使用COCOMO2模型估算工作量，也应该重视这些因素。Boehm把成本因素划分成产品因素、平台因素、人员因素和项目因素等4类。 表13.3（见书300页）列出了COCOMO2模型使用的成本因素及与之相联系的工作量系数。与原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述变化，这些变化反映了在过去十几年中软件行业取得的巨大进步。 * * * 不论从事哪种技术性项目，实际情况都是，在实现一个大目标之前往往必须完成数以百计的小任务（也称为作业）。这些任务中有一些是处于“关键路径”（见13.3.5节）之外的，其完成时间如果没有严重拖后，就不会影响整个项目的完成时间；其他任务则处于关键路径之中，如果这些“关键任务”的进度拖后，则整个项目的完成日期就会拖后，管理人员应该高度关注关键任务的进展情况。 软件项目的进度安排是这样一种活动，它通过把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工作量分布于计划好的项目持续期内。进度计划将随着时间的流逝而不断演化。在项目计划的早期，首先制定一个宏观的进度安排表，标识出主要的软件工程活动和这些活动影响到的产品功能。随着项目的进展，把宏观进度表中的每个条目都精化成一个详细进度表，从而标识出完成一个活动所必须实现的一组特定任务，并安排好了实现这些任务的进度。 * * * * * * * * * * * * * * * * * * * * 审查的正规性体现在： 仔细划分错误类型，并把这些信息运用在后续阶段的文档审查中以及未来产品的审查中。 * * * 1. 软件配置项 软件过程的输出信息可以分为3类： ①计算机程序（源代码和可执行程序）； ②计算机程序的文档（供技术人员或用户使用）； ③数据（程序内包含的或在程序外的）。 我们把它们统称为软件配置，而这些项就是软件配置项（ITEM=元素）。 13.6.1 软件配置 2. 基线(Baseline, 里程碑) IEEE把基线定义为： 已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。 软件工具也应置于配置管理之下：编辑器、编译器和其他CASE工具。 不同版本的工具产生的结果不同。 软件配置管理主要有5项任务： 标识、版本控制、变化控制、配置审计和报告。 1. 标识软件配置中的对象 命名每个配置项。两类对象： 基本和聚集对象。 基本对象是软件工程师在分析、设计、编码或测试过程中创建出来的“文本单元” 。 聚集对象是基本对象和其他聚集对象的集合。 每个对象都有一组能惟一地标识它的特征： 名字、描述、版本。 13.6.2 软件配置管理过程 2. 版本控制 版本控制管理软件配置对象的不同版本。 用户能够通过选择版本来指定软件的配置。 属性和软件的每个版本相关联。 描述一组所期望的属性来指定和构造所需要的配置。 “属性”，既可以是配置对象的版本号，也可以复杂到是一个布尔变量串。 3. 变化控制 变化控制过程在维护一章讲过。 批准的变化生成一个“工程变化命令” 描述将要实现的变化。 把要修改的对象从项目数据库中“提取（check out）”出来，进行修改。 把修改后的对象“提交（check in）”进数据库，并创建该软件的下一个版本。 变化控制的两个主要功能: 访问控制决定软件工程师有权访问和修改一个特定的配置对象 同步控制有助于保证由两名不同的软件工程师完成的并行修改不会相互覆盖。 4. 配置审计 两方面采取措施确保适当地实现了所需要的变化： ①正式的技术复审； ②软件配置审计。 正式的技术复审（见13.5.2节）关注被修改后的配置对象的技术正确性。 软件配置审计通过评估配置对象的那些通常不在复审过程中考虑的特征（例如，修改时是否遵循了软件工程标准，是否在该配置项中显著地标明了所做的修改，是否注明了修改日期和修改者，是否适当地更新了所有相关的软件配置项，是否遵循了标注变化、记录变化和报告变化的规程），而成为对正式技术复审的补充。 5. 状态报告 配置状态报告回答下述问题： ①发生了什么事？ ②谁做的这件事？③这件事是什么时候发生的？④它将影响哪些其他事物？ 配置状态改善所有相关人员之间的通信，消除冲突， 避免重复，提高效率。 美国卡内基梅隆大学软件工程研究所在美国国防部资助下于20世纪80年代末建立的能力成熟度模型（capability maturity model，CMM)，