第二章软件开发的主要活动PPT课件

1、第二章 软件开发的主要活动,内容安排,需求分析与管理 设计 编码 软件测试 运行与维护 软件项目管理 软件配置管理 软件验证与确认 软件质量保证 软件文档管理,2.1 需求分析与管理,需求是任何软件开发项目的基础。软件需求表达了需要和置于软件产品上的约束，这些产品用来解决现实世界中的某个问题。,主要活动,需求描述、需求管理、需求跟踪,主要阶段,需求分析、满足需求的软件开发,依据上述观点，实际软件计划和项目的执行发生在需求分析之后。 因此在项目计划前，首先进行需求分析与说明，并作为项目启动的一部分。,需求分析与规范（续）,系统需求分析,因为软件总是大系统的一个部分，因此必须从建立整个系统所有元素

2、的需求工作开始，然后才能确定一些软件子系统的需求。 当软件必须与系统的其他元素（如硬件、人、数据库等）接口时，这种系统的考察显得非常重要。系统需求分析主要围绕系统级需求的聚集和少量顶层分析和设计展开。,系统需求分析 软件需求分析,软件需求的聚集过程是逐条确定的。为了弄清所编写程序的性质，软件人员必须了解软件的信息域及所要求的功能、性能和接口。 系统需求分析和软件需求分析都要文档化，还要与用户一起对它们进行评审。,需求分析与规范（续）,需求分析与规范（续）,需求分析成本一般占软件项目总成本的4%到10%，但却在很大程度上决定了其余80%到90%资金的开销。,需求变更管理,变更管理过程,需求变更请

3、求,登记变更请求,分析变更请求,估计工作量 重新估算交付的时间表 执行累计的成本影响分析,需求变更管理（续）,变更管理过程,需求变更请求,登记变更请求,分析变更请求,评估变更请求,获得用户认可,修改工作产品,变更的记录与跟踪,需求跟踪管理,分类,正向跟踪 反向跟踪,跟踪矩阵,矩阵的维护与使用,作用,减少需求遗留 方便复审 向客户演示产品和测试程度,需求跟踪管理（续）,矩阵的维护与使用,作用,遍历需求文档和矩阵 确信在最后的软件中，所有列出的需求都有相应的程序与之对应 一个人检查所有的功能需求都被实现，没有空列 对于每个性能需求，应该建立一些测试用例 集成和系统测试计划可在矩阵中交叉使用，以确信

4、系统测试计划中包含了需求中的所有情况。,维护,2.2 设计,软件设计的目标是构造解决方案， 设计过程是把对软件的需求描述转换为软件表示，这种表示能在编码开始以前对其质量做出评价。 软件设计的关键是对软件体系结构、数据结构、过程细节，以及接口性质这四种程序属性的确定。 对于大型系统，软件设计又分为高层设计和详细设计。 软件设计也要文档化，并作为软件配置管理的一部分。,2.3 编码,也称为软件构造，就是用某种编程语言编写源程序或以界面工具构造出应用界面。 设计构造了可以执行的解题逻辑，编码构造了机器代码。 其阶段目标是形成完整并经验证的程序组件集。 如果设计做得足够细致，编码可以机械地完成。 软件

5、一旦构造出来应及时纳入配置管理。,2.4 软件测试,测试是动态验证软件的过程。,测试一般包括:,单元测试 集成测试 系统测试 验收测试,制定测试计划 编写测试用例 准备测试环境 执行测试用例 测试结果分析,依据测试对象的不同， 测试可分为四个层次：,2.5 运行与维护,软件维护是指为在保留现有运行软件主要功能不变的同时对其进行修改的过程。软件维护通常包括的活动：,软件维护分类： 软件更新、 校正性维护、完善性维护和适应性维护,重新设计和开发已有软件产品的某一较小部分 设计并开发较小的接口软件包，它需要对现有软件产品进行重新设计 修改软件产品的代码、文档或数据库结果,运行与维护过程相伴而行，直至

6、软件系统被废弃。 维护费用通常占软件产品生存周期费用的40%-70%,2.6 软件项目管理,2.7 软件配置管理,配置项和基线 配置库 配置管理流程 配置项标识 版本控制 配置控制 状态薄记 配置审计,配置项和基线,软件开发中的主要配置项,操作概念 需求规格说明 设计文档 源代码 目标代码 测试计划,测试用例、测试配置和测试结果 维护和开发工具 用户手册 维护手册 接口控制文档,配置项和基线,基线的作用,把各阶段的工作划分得更加明确，使本来连续的工作在这些点上断开，以便于验证和确认开发成果。,再生能力 是指能够“返回”到原先的某一时间重新制造软件系统 的特定版本或再现曾经存在的开发环境。 可追

7、踪能力 将需求、项目计划、测试用例以及各种软件工件关联在 一起。为了实现可追踪能力，不仅需要对系统中的各种 工件进行基线化，而且要对项目管理工件进行基线化。 报告能力 使我们能够查询任一基线中的内容以及对比不同基线的内容。 基线的比较结果可以支持排错以及辅助生成新版发布说明。,基线可为软件制品提供三种能力：,软件开发过程中包括的典型基线,配置库,作用,记录与配置相关的所有信息，利用库中的信息可评价变更的后果，可利用库中的信息查询,动态库/开发库， 新建或刚被修改的SCI在它们被控制库接受之前的保存地点。 静态库/产品库，用来存储为了一般性使用而已经发布的基线。该库维护正式发布的、可以运行的软件

8、项的主拷贝。 受控库 用来维护基线，并控制对这些基线的变更。,一般的数据库或文件库，配置数据库通常的三种形式：,物理形式,开发过程决定了配置管理的对象 配置管理控制开发过程的节奏,开发过程与配置管理过程的关系,生效的配置项相关信息,更新版,配置项相关信息 将要发布的软件产品,软件开发过程,软件工作产品,授权变更,评审和批准,执行变更,变更内容,配置审计,原版本,配置通知,配置管理流程,变更请求,配置项标识,在标识配置项时，必须执行两个相关的任务：,选择SCI；组合分组，并放入基线中。,配置项标识,标识配置项的一些常用准则；,项的适当规模和复杂性。 项可以插入的基线。 在目的基线中，项的预期变更

9、频率。 在目的基线中，对项实现变更的成本。 项的预期复用。 项的标识是否为开发带来高的风险。 标识的项是否作为安全要素。 标识的项是否作为性能要素。 项对工具集的依赖是否具有不同于其他SCI。,项在系统或子系统体系结构中的作用。 项被独立编译的能力。 项自身安装的能力。 项独立执行的能力。 项自身执行一个有用功能的能力。 评估在维护期间对配置项所进行的实际的、单个的修改。,版本控制,版本管理是对系统不同的版本进行标识和跟踪的过程，它可以保证软件技术状态的一致性。随着软件开发的进展，配置项的版本也在不断地演变，由此形成了该配置项的版本空间。在实际应用中，版本的演变可以是串行的，也可以是并行的。,

10、配置控制,配置控制主要任务,配置项的状态转移管理,配置项的状态转移管理 必须实现的变更请求管理,当配置项状态改变时，将一个配置项从一个目录移到另一个目录 当实施变更时创建版本-版本控制 确信每个配置项经历了它们的生存周期到达了基线,配置控制（续）,变更请求、变更评估、变更批准/拒绝、变更实现等活动都属于配置控制活动。,目的,状态薄记的最小数据集,及时、准确的给出软件配置项的当前状况，供相关人员了解，以加强配置管理工作,被批准的一个SCI的最初版本。 对于该SCI，所有请求的变化状态。 对于该SCI，所有被批准的变更的实现状态。,状态薄记,任务,任务：定期检测SCM系统、 配置项的内容及其变更历

11、史的过程,状态薄记（续）,除了以上数据之外，在评估一个SCM系统的状态以及评估系统所支持的产品状态时，经常需要以下信息：,变更请求的数量，按SCI的分类，以及对项目有意义的其他一些信 息。把这些变更按某一模式进行分类，例如，文档变更、代码变更 等，这是非常有用的。 变更请求的“成长”报告，表示为一个变更请求，从复审、批准、实 现、测试一直到最后的接受，每一活动所花费的时间。 对于所有的变化请求，在系统中“徘徊”和“漂浮”的时间往往大于预先确定的时间。 存储量的增长，即SCM系统占用的磁盘空间。 在SCM系统本身的运行以及在CCB的运作中，发生多少次异常。,状态薄记（续）,在规划一个项目的配置状

12、态薄记活动过程中，应该考虑以下主要问题：,配置状态薄记的目的是什么？ 项目、产品和过程所关注的问题有什么不同？与开发（动态库）具有密切关系的报告是什么？什么与已发布的产品有着密切关系？ 对每一个状态报告，它的读者是谁？SCM系统的操作员期望使用它吗？质量保证呢？项目经理呢？客户呢？ 每个报告的产生频率？ 谁应接收它？这个变更是否过时了？保留状态记录的政策是什么？ 状态薄记活动是否与项目生存周期模型以及开发工作保持一致？,配置审计,什么是配置审计,配置审计工作主要集中在两个方面，即：,功能配置审计验证配置项的实际功效与其软件需求的一致性，软件验证和确认活动的输出就是这种审计的关键输入 物理配置审

13、计确定配置项符合预期的物理特性，即特定的媒体形式,成功地完成审计是建立产品基线的先决条件,配置审计（续）,确保软件配置管理的有效性，不允许出现任何混乱现象。 如：,为什么要实施配置审计,防止出现向用户提交了错误的产品，如交付了用户手册不适当的版本 发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更 找出各配置项间不匹配或不相容的现象 确认配置项已在所要求质量控制审查之后作为基线入库保存 确认记录和文档保持着可追溯性,配置审计（续）,实施配置审计的时机,如何实施配置审计,软件产品交付或是软件产品正式发行前 软件开发的阶段工作结束之后 在维护工作中，定期的进行,配置审计（续）,审计

14、步骤,如何实施配置审计,由项目经理决定何时进行配置审核工作 质量保证组或软件组的配置管理组指定该项目的配置审计人员 项目经理和配置审计员决定审核范围 配置审计员准备配置审计检查单 配置审计员安排时间审核文档和记录 配置审计员在审计中发现不符合现象，并作记录 由项目经理负责消除不符合现象 配置审计员验证所有发现的不符合现象确已得到解决,何时做,具体时间安排,谁做,做什么（范围）,准备（检查单）,记录问题,解决问题,验证问题解决情况,配置审计（续）,审计活动可能涉及到范围,如何实施配置审计,评审记录 配置项的变更历史 测试记录 文件的命名 变更请求 版本的编号,人们对配置审计最大的误解是“对配置库

15、中的每个配置项都检查一遍”！,V&V过程提供了软件产品和经历软件生存周期过程的一个客观评价。评价标准证明了软件需求和系统需求的正确性、完整性、准确性、一致性和可测试性。执行V&V活动，同时实现了如下目标：,2.8 验证与确认,尽早发现和改正软件错误。 增强过程与产品风险的洞察力。 支持软件生存周期过程，确保程序性能、进度、支出的需要。 V&V过程对软件和与其相关的产品提供证明： 软件生存周期中的获取、供应、开发、维护、运行过程中的所有活动都与需求一致，即达到了需求的正确性、完整性、一致性和准确性。 满足软件生存周期中规定的标准、实践规则、管理。 建立一个评价每个生存周期活动的一个基础，并作为启

16、动下一个生存周期活动的基础。,V&V过程在绝大多数情况下与开发过程并行，否则，其目标难以实现。因为验证活动与确认活动间的关联性和互补性，所以验证与确认过程通常一起讨论。在有些环境下，验证过程与确认过程被看成两个独立的过程。,2.8 验证与确认（续）,2.8 验证与确认（续）,有效的软件V&V应该在项目生存周期早期启动，并贯穿其生存周期，对一些应用，甚至包括运行和维护阶段。 软件V&V工作在关键系统的开发中的成本可能占有很大的比例。因此，必须精心计划、细致管理。 软件V&V工作所需的成本、进度和人员安排必须在项目规划中给出。IEEE标准为此提供了一个框架，其中包括软件V&V计划的内容和格式。,软件V&V工作的强度、范围和深度应该依据产品的关键性进行调整。,2.9 软件质量保证,SQA的作用 SQA启动程序 SQA计划 SQA需要考虑的问题,软件质量保证（Software Quality Assuranc