软件文档写作第7讲管理文档完整ppt课件.ppt

1 第七讲软件管理文档 2 7 1管理文档概述工程化的软件生产方式是软件业界始终在不懈追求的目标 软件项目管理方法适用与否 对软件项目的成败有着举足轻重的作用 而软件项目管理方法改进的途径之一 就是建立行之有效 可操作性强的软件管理文档 管理文档的组成 管理文档有以下几个方面的作用 3 管理文档的作用主要体现在三个方面是软件开发各阶段工作成果的体现把软件开发过程中的一些 不可见 的事物转换成 可见 的文字资料提供了管理人员 开发人员 操作人员和用户之间相互沟通 协调的窗口 4 7 2项目开发计划项目开发计划又称软件定义文档 是和软件本身一样重要的知识资产 是项目启动后第一件最重要的工作 项目开发计划一般包括资源需求 工作分解 工作目标 开发团队及人员安排 进度安排 内外接口约定 风险分析以及软件质量控制机制等 1 项目开发计划书项目开发计划书的具体内容随着项目和开发机构类型的不同而不同 一般都会包括以下几个部分 项目目标 简述项目目标 并列出影响管理的约束条件 如预算 时间 开发团队及人员安排 阐述团队组织方式 人员构成及分工 软硬件资源需求 分析和列出所需资源 注明估算的资源需要时间及价格 工作分解 分解项目为一系列活动 确定项目里程碑及可交付文档 项目进度 描述项目各活动之间的依赖关系 到达里程碑的时间等 风险分析 分析项目可能存在的风险 发生的可能性及应对风险的策略 监控机制 制定详细 可操作的项目监控机制 明确管理报告的递交时间 开发估算 包括规模 工作量 成本等的估算 要求依据并积累历史数据 5 制定项目开发计划的过程被称为项目策划 由于计划所具有的在时间上的提前性 项目开发计划通常会经常性的修正 有些部分甚至会频繁的改变 而部分内容的变化 会影响开发计划的正确性和符合性 使其越来越偏离项目实际 最后变得没有价值 如随着项目需求的逐渐明确引起的项目计划细化 项目可提供资源变化引起的项目计划的变化等 所以 在实际工作中 需要有明确的责任人和操作原则 来对项目计划实施维护 并对项目计划的变更实施必要的控制 另一个重要的方面是 在组织文档时 就要考虑到这种频繁变更的需要 使得当变更发生时 文档的相应部分能够容易替换 6 2 工作分解结构工作分解结构 workbreakdownstructure WBS 是对整个项目工作的分级描述 是项目计划开发的第一步 分解示意如下图所示 工作分解结构设计一般可以采用2种方法 自上而下的方法 从项目的目标开始 逐步分解 直到具体任务 自下而上的方法 也称集思广益法 即从底层开始 逐层集成 最后汇合后完成目标 7 工作分解结构主要有4个用途 思路工具 可以描述项目的整体思路 是一个计划和设计的工具 结构设计工具 是项目工作的结构图 可以清晰表达项目各项工作间的相互关系 计划工具 能够展示项目全貌 说明为完成项目所需完成的各项活动 项目状态报告工具 可以作为项目状态报告的框架 随着低一级项目活动的完成 项目由下而上不断整合 某一项工作的完成将成为里程碑 所以 工作分解结构就定义了里程碑事件 8 3 项目里程碑与阶段性文档由于软件产品是无形的 因此 管理者需要通过文档的形式获得信息 了解软件的开发状况 以作出管理的决定 里程碑的建立 可以描述软件开发活动一个过程的终结 在每个里程碑 都有一个正式的可以提交给管理层的阶段性结果 比如 一份报告 里程碑报告的内容不拘 以能清楚说明阶段性结果为标准 应能代表项目中一个特定逻辑意义上的阶段的终结 要建立里程碑 软件过程就一定要分解成一系列相关的基本活动 而每个基本活动都要有相应的输出结果 如下图 是一个需求描述中的活动 其中每个活动都有主要输出 9 4 项目进度项目管理者要求估算完成各项活动所需的时间和资源 并将它们严密的组织起来 以安排项目进度 不同的项目 具有不同的项目开发进度 初始的项目进度安排往往是不精确的 但随着项目进展信息的不断增多 进度安排也会越来越接近项目实际进度 因此 必须不断更新项目进度 项目进度包括将一个项目分解为若干独立的活动 以及判断完成这些活动所需的时间 通常 有些活动是可以并行的 项目管理者应组织并协调这些并行的工作 项目进度过程见下图 10 在进度估算时 管理者需要有一定的余量 如项目难度大 则花费的时间也会较多 又如 项目个别开发人员可能发生的变动 硬件环境的变化等 都是在估算项目进度时必须考虑的因素 除了时间和人员 环境的变化 资源和预算也需要考虑适当的余量 恰当的估算方法是采用 理想 实际 方式 即先估算理想值 然后逐步加入预计出现的状况 偶然因素致成的状况 项目开发人员的素质和经验 作为经验数据 一般在最初估算的基础上增加30 作为实际可能发生的状况值 再预留20 的估算值给所谓不可预见的其它问题 则进度估算的结果会较符合实际 11 5 运用图和表描述项目进度项目进度可以采用图表工具更直观的表示任务分解 活动依赖关系和人员分配情况等 下表是一个 任务的持续时间及其依赖关系 的例子 12 甘特图法 GanttChart 的例子 优点 简单 能动态地反映开发进程 缺点 难以反映多个任务间的逻辑关系 条形图和活动网络图是表示项目进度的两种图形表示法 1 条形图 又称甘特图法 GanttChart 可以表示面向活动的负责人是谁 以及活动的开始和结束时间 如下图所示的例子 13 例 开发三个模块A B C A为公用模块 B C的测试须等A的调试完成后进行 A的编码需6天 测试8天 调试6天 B的编码需7天 测试8天 调试6天 C利用已有的模块 须先理解原模块8天 再修改8天 测试9天 调试7天 最后三模块集成测试需5天完成 2 活动网络图 又称网络计划法表示构成一个项目的不同活动之间的依赖关系 是用网状图表安排与控制各项活动的方法 最适合反映多个工作之间的逻辑关系 14 1 标出LastingTime 2 标出EST 从起点始 所有进入事件的EST LT中最大的 3 标出LST 从终点 EST LST 始 所有离开事件的LST LT中最小的 4 标出ST 终点LST 起点EST LT 5 标出KeyPath 即EST LST的所有事件组成的路径 通常 甘特图适合按开发阶段安排 以作项目总体进度控制 网络计划法便于在细节上安排人力 适合按开发阶段或子项目的工作步骤安排 15 6 风险管理由于绝大多数软件项目都存在不确定性 因此 风险管理对软件项目而言就尤为重要 根据产生的影响不同 一般将风险分为三类 项目风险 产品风险和业务风险 下表给出了一些典型风险 16 下图是风险管理过程示意图 1 风险识别风险识别是风险管理的第一阶段 其目的是发现可能的风险 右表给出了可能的风险及风险类型的实例 这些风险将可能影响到软件产品 过程或业务 17 2 风险分析风险分析就是对每一个已经识别的风险 对其出现的可能性和影响的严重性作出判断 风险出现可能性的评估大致可以有 非常小 75 风险影响大小的评估 可能的结果有 灾难性的 严重的 可以容忍的和可以忽略的 右表是对上表已识别风险分析后得出的结果作成的表格 这个表格的内容应随着项目的进展而更新 经过风险分析和排序 就可以判断哪些风险是最重要需要优先关注的 以有利于项目的顺利开展 18 3 风险规划风险规划过程就是对已识别的每一个重大风险 确定相应的处理策略 制定风险管理计划同样需要项目管理者的判断和经验 下表给出了处理上表中严重和灾难性风险的可能的策略 风险规划的策略有三类 规避策略 采用这些策略会降低风险出现的概率 如 有缺陷的组件 最低风险策略 采用这些策略会减少风险影响 如 职员生病风险 应急计划 用以应对最严重的情形出现 以防万一 如 机构财务问题 19 4 风险监控风险监控就是要对每一个识别的风险及其策略执行情况进行定期评估 从而确定风险出现可能性的变化趋势以及风险影响的后果是否有所改变 通常 这类信息是不可能直接观察到的 需要综合其它因素 应该指出的是 风险监控应该是一个持续不断的过程 在每一次对风险管理进行评估时 每一个重大的风险都应该进行单独的讨论和评估 下表列举了一些典型因素的例子 可能会对评这些估风险类型有帮助 20 7 3软件测试计划和测试报告软件测试是软件开发完成 投入运行前 对软件需求 设计规格说明和编码的最终复审 软件质量保证的关键步骤 在软件开发的整个过程中 占有极为重要的位置 软件测试文档主要包括 测试规划 测试策略 测试手段和测试结果 由于测试工作的重要性 而人工测试又特别困难 因此 测试过程自动化会是测试技术发展的方向 1 软件测试 软件检查和调试我们已经知道软件测试的目的是尽可能多的发现系统存在的错误 所以 软件测试包括软件检查与软件测试 软件检查 对系统的各种表达形式 如文档 设计图和程序源代码等进行分析 检查 这一工作应贯穿整个开发过程 软件测试 使用测试数据对软件的实现进行运行检查 查看系统的输出及运行行为是否符合设计要求 21 下图表示了软件检查和软件测试在软件过程中的位置 从图中可以看出 软件检查贯穿整个软件过程 而软件测试仅对原型或软件程序 软件调试是一个对缺陷定位和修改的过程 同时也是一项技巧性很强的工作 软件调试 从软件测试的结果开始 如图所示 22 2 软件测试的成本由于测试不可能穷尽 因此 就有了软件测试的一个致命缺陷 即测试的不完全 不彻底性 因此 对于任何程序只能进行少量的测试 当发现错误 可以说明程序有问题 而未发现错误 却不能声称程序没有错误 根据软件工程的基本原理 当测试标准越高 则将要投入的人力 财力也越高 左图反映了测试成本的变化规律 为在软件质量和投入之间取得需求平衡 可以采用著名的 进度 成本 质量 三角公式 如下右图 即只要确定了其中两项 就可以确定第三项 因此 在编制软件测试计划时 必须考虑三者之间的关系 23 3 软件测试的原则测试时 如果成功地实施了测试计划和方案 就能够发现系统中尽量多的错误 测试的一个附带收获是 能够证明软件的功能和性能是与需求说明相符的 要达成上述要求 就需要遵守以下原则 1 测试规划应包含测试工作的全部内容 即不仅是程序测试 还包括文档 2 测试应贯穿软件开发的整个过程 即坚持各个阶段的评审 杜绝隐患 3 测试用例应包括输入和预期输出 4 设计测试用例时 输入应包括合理的和不合理的数据 5 功能测试应由独立第三方完成 但调试仍应由开发者自己完成 6 充分注意并利用测试中的群集现象 7 严格执行测试计划 排除测试随意性 计划应明确规定 不随意解释 8 应当对每一个测试结果做全面检查 仔细分析测试结果 防止错误遗漏 9 妥善保存测试计划 测试用例 出错统计和最终分析报告等测试文档 24 4 软件测试过程从程序测试的角度看 测试分为两个阶段 如图 程序测试过程的目的是尽可能多的发现并改正错误 提高软件质量 测试过程的每一个阶段也都会对前一阶段有反馈信息 因此 测试过程是一个不断修正和进化的过程 其阶段划分如下图所示 测试过程需要下面三个基础数据和资料的支持 软件配置 软件正常运行的环境配置 测试配置 软件测试运行的环境配置 是软件配置的子集 测试工具 为提高测试效率 降低测试劳动强度 保证测试质量使用的工具 25 5 测试计划的导出与结构测试计划应该从系统描述和设计中导出 下图是测试计划从系统描述和设计中导出示意图 测试计划的主要组成部分如右表所示 26 6 几种常见的测试用图表工具 1 检查表检查表是一张标明了所要检查项目和内容的表格 可以用来突出重点和总结整个过程的关键点 优点是简洁 清晰 典型的检查表如需求检查表 系统结构检查表 代码结构检查表 共性缺陷检查表等 检查表因其重要性 目前已实现了自动化和智能化 如IBMRochester软件开发中的PTF programtemporaryfix 程序临时修补 检查表 2 Pareto图一个按下降次序排列的频率竖条图 通常 X轴表示缺陷产生的原因 Y轴表示缺陷数 下图就是一个软件产品缺陷原因的Pareto图 27 3 直方图是一种样本或总体的频率计数的图形表示 X轴自左至右按上升序列出某一个参数的单位间隔 Y轴为频率计数 直方图常用来表示某一参数的分布特性 如下图是一个软件产品按不同严重程度的缺陷频率和缺陷报告提交的天数直方图 28 7 设计软件测试 1 缺陷测试设计下图是缺陷测试的一般模型 其中 需要设计测试用例 给出测试预期结果 测试用例是对测试需要的输入和当前测试内容的描述 运行结果需要和测试预期结果比较 以获得测试是否通过的结论 理想的测试是使每个可能的程序运行顺序都能无遗漏的得到测试 然而这是不可能的 因此 测试需要基于一个可能的测试用例子集 制定和设计一个测试子集的选择策略 29 黑盒测试黑盒测试是将系统作为一个黑盒子 只通过系统输入 观察其相应的输出 来确定系统功能是否符合需求规格说明书的定义 因此 黑盒测试又称功能测试或数据驱动测试 黑盒测试的系统模型如下图 黑盒测试方法即适合功能构成的系统 也适合对象构成的系统 测试的关键是要设计出有极大可能落在导致系统反常的输入数据集合中的那些输入 使用下表可以组织黑盒测试方法的输入和输出 30 等价划分黑盒测试的一种方法 等价划分的测试方法就是把程序的输入域划分成若干不同性质得到的集合 在这些集合中 程序有基本一致的行为表现 然后从每个集合中选取少量有代表性的数据作为测试用例 下图就是等价划分测试的模型 等价划分方法测试用例的设计要经历划分等价类和选取测试用例两步 等价类的划分可以使用等价类表描述 确定测试用例则需要根据等价类表 按以下3个步骤进行 为每个等价类规定唯一编号 设计一个测试用例 使其尽可能多的覆盖尚未覆盖的有效等价类 重复该步 设计测试用例 逐一覆盖所有无效等价类 31 结构化测试结构化测试是一种根据软件结构知识和实现知识所进行的测试方法 结构化测试也成为白盒测试 结构化测试的过程如下图所示 结构化测试除了用于单元测试外 一般适合用于相对较小的程序 如一个子程序或对象的一个操作等 结构化测试是通过代码分析来估计需要多少测试用例 以保证测试过程中 程序或组件中所有语句都至少遍历一遍 路径测试是结构化测试的一种策略 即在程序控制流程图的基础上 通过分析控制构造的环路复杂性 导出基本可执行路径集合 从而设计测试用例 而设计出的测试用例要保证在测试中程序的每一个可执行语句都能至少执行一次 在面向对象的程序开发过程中 路径测试在测试对象中的方法时 常会用到 程序中的路径数量通常与程序的长度成正比 32 2 集成测试设计集成测试开始于系统组件 子系统或完整系统的组装完成时 其目的是发现组件交互中的问题 集成测试的主要困难是在测试过程中对发现的错误的定位 一个好的方法是采用所谓的增量法 即先从一个集成度最小的系统配置开始测试 完成后一个增量一个增量的增加配置 然后逐步完成系统完整配置的测试 下图就是增量化集成测试的例子 33 自顶向下的和自底向上的测试是两种不同的测试策略在自顶向下的集成测试中 系统的高层组件在系统设计和实现完成之前进行集成和测试 如下图所示 在自底向上的集成测试中 低层组件在高层组件开发出来之前进行集成和测试 如下图所示 34 接口测试当模块或子系统被集成时 就有一个事先定义的接口供其它组件调用 接口测试的目的就是检测因接口错误或对接口进行的无效假设而造成的系统缺陷 下图就是对接口测试的示意图 图中 指向方块边界的箭头表示测试用例不是只针对单个组件的 而是对组件构成的整个子系统的 接口错误是对象之间交互的结果 而不是出于单个对象的行为 因此 接口错误是不可能通过对单个对象的测试发现的 这种测试形式非常适合面向对象的系统 强度测试系统被完全集成后 就可以进行总体性能测试了 为性能测试所设计的测试用例要保证能够测试到系统的正常负荷 通常 要设计出一系列的测试 使得系统的测试负荷能稳步上升 直到系统达到性能极限 然后 强度测试继续使用测试用例测试 直到系统失败 这类测试有两个作用 检查系统的柔性 可能模拟到正常情况下的不寻常组合 以暴露系统正常情况下不会暴露的缺陷 35 3 面向对象的测试尽管前面介绍的测试方法能够用于面向对象程序的测试 但是面向对象的测试还具有自己的另外一些特点 面向对象的单元测试以往单元测试的方法可继续沿用 实际测试类成员函数 对象的完全覆盖测试应包括 对象中所有操作被单独隔离的测试 对象中所有属性的设置和访问的测试 对象中所有可能状态的测试如果使用了继承 则对类的测试应延伸到所有子类所继承的操作 36 面向对象的集成测试由于面向对象程序中 类相互依赖极其紧密 根本无法在编译不完全的程序上对类进行测试 所以 面向对象的集成测试通常需要在整个程序编译完成后进行 此外 面向对象程序具有动态特性 程序的控制流往往无法确定 因此也只能对整个编译后的程序做基于黑盒的集成测试 面向对象的集成测试能够发现相对独立的单元测试无法检出的那些类相互作用时才会产生的错误 具体设计测试用例 可参考以下步骤 选定检测的类 列出类的状态 行为 传递的消息 及输入 输出的界定等 利用结构关系图确定待测类的所有关联 确定覆盖标准 根据程序中类的对象构造测试用例 确认输入 服务和期望产生的行为等 37 8 软件测试计划文档测试计划起到测试工作过程框架结构的功能 是好的测试工作的基础 一个测试计划的基本内容包括 基本情况分析 测试需求说明 测试策略和记录 测试资源配置 问题跟踪报告 测试计划的评审等 基本情况分析 包括系统运行平台 应用领域 特点和主要功能模块等 分析要点有 测试目的和侧重点 系统适合于测试的内容 操作划分 测试的潜在风险 系统与测试相关的资料说明 测试需求说明 列出测试功能项 规定应该测试的具体内容 测试策略和记录 描述如何开展测试 规定测试记录的内容 必要时 应给出测试记录文档