小组软件过程 ——产品实现.ppt

小组软件过程 ——产品实现 欧阳柳波 湖南大学软件学院 设计完成标准 完整、详细的设计是实现的基础 设计的层次：系统、子系统、产品、部件、模块（150LOC） 并行的实现：若开发小组较大，可在完成部件的外部接口设计后，立刻实现它，若开发周期较短，可采用此方式，风险较大 实现标准 承接设计标准，并在实现时小组达成一致。 标准的复核应注意实用性，不要期望第一次就产生一个完美的标准，人们很容易在讨论抽象的提议时浪费大量时间。 复核在设计阶段完成的命名、接口、信息标准，确保其仍合理、可用。 复核命名词汇表，确保每个人对同样的条款使用同样的名字，以及所有名字都被记录。 复核部件和模块名字，复核共用的变量、参数和文件名是否一致，接口和消息是否被定义。 实现标准 小组拥有一个共同的编码标准，可使代码检查更容易更有效。 一个被精心构造的编码标准还定义了注释约定，好的注释约定可加快代码复查，并在以后的开发周期中使升级更容易。 统一的编码标准使小组的代码共享更容易，有利于代码复用设计和实现。 实现标准 要有一个小组一致的产品大小标准。 需度量大小的产品元素：SRS、SDS、详细设计、屏幕和报告、数据库、信息、测试草案、测试材料。 需求可使用页数、段落数或“Shall”来计数，一个“shall”说明通常用于代表一个所期望的功能，如当某行代码被删除后，在程序中该行被删除的地方要用注释来保存被删除掉的那一行。 总体设计可用模板的页数、文本行、使用场景来度量，程序使用LOC度量。 实现标准 存在无穷多种方式来定义缺陷标准。 将缺陷归为一些类型的目的是帮助分析、改进开发过程。 缺陷类型标准只有当它们很少时才可用。 区分缺陷类型和缺陷原因。 实现标准 缺陷预防的主要措施： （1）教育：学习有关语言、环境和应用的更多知识 （2）交流：改进开发过程，使用更好的方法 （3）事务处理：使用更好的工具 （4）监督：确保开发过程规范 （5）选择出那些引起绝大多数麻烦的缺陷类型。 （6）确定产生缺陷的原因，并引起注意 实现策略 实现策略应与设计策略一致，主要为复核、复用、测试三点。 复核应采用自底至顶的方法，从细节入手，逐渐拓宽到全局。 建立复用库，列出复用清单和复用模块功能规范。 注重可测试性设计与实现，并与测试计划保持一致。 随机缺陷 按键错误将导致许多的随机缺陷。 若1.73个错误/千次按键，每LOC（C++）中大约按键16次，则导致28个错误/KLOC，这些错误与程序的逻辑无关。C++编辑器只能发现其中的9.4%。 随机缺陷的发现很困难，原因在于测试仅用于发现由专门测试环境碰到的缺陷。为保证找出所有随机缺陷，你必须要运用所有的程序逻辑路径和所有可能的数据和操作环境来测试。 随机缺陷 详尽测试是困难的。一个59-LOC的将整数转化为文本指针的程序，其详尽测试需要67种测试环境，368条逻辑路径，65536个数值。 用少量的测试发现一个随机缺陷的可能性是非常小的。 这是复核的重要性所在，也是复核比测试更有效的原因。 IMP脚本 开始条件：SRS、SDS、命名词汇表、编码标准及其它文档化的标准。 实现计划：小组任务分配、工程师个人计划 详细设计和设计复核 测试的开发：遵循测试计划，开发一些特殊的单元测试代码和设施。 详细设计检查：记录INS和LOGD表格 编码和代码复核：使用个人检查表复核后编译 IMP脚本 代码检查：与小组质量经理一起复查结果，使用质量标准，如： 用于设计的时间比编码时间长； 用于复核设计的时间比设计的时间长50% 用于复核代码的时间比编码的时间长50%以上； 复核代码发现的缺陷至少是编译的2倍； 每复核1小时，至少发现3个以上缺陷； 复核速率应小于200LOC/hour IMP脚本 单元测试：使用已开发好的测试环境，遵循测试计划 部件质量复核：记录SUMQ表格 部件通过：记入系统基准 结束标准：通过了的且被记入了配置管理系统的部件、INS、LOGD、LOGT、SUMP、SUMQ、SUMS表格、UT计划和环境、工程记事本 * * *