1、1,第一章软件的定义,软件是：(1)指令的集合(计算机程序)，通过执行这些指令来满足预期的特征、功能和性能需求； (2)数据结构，使得程序可以合理的利用信息；(3)文档描述，用来描述程序操作和使用。,2,软件的特性,软件是设计开发的，而不是传统意义上生产制造的。-硬件可能会引入质量问题，但软件不会（或易于纠正）-人员和工作成果之间的对应关系完全不同-构建方法不同，软件产品成本主要在于开发设计,软件的特性(续1）,软件不会“磨损”。-硬件的失效率称为“浴缸曲线”。早期具有相对较高的失效率（来自设计或生产缺陷），缺陷被逐个纠正后，失效率随之降低并在一段时间内保持平稳，因灰尘、震动、不当使用、温度超
2、限等问题所造成的硬件组件损耗累积的效果而再次升高。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,3,软件的特性(续3）,虽然整个工业向着基于构件的构造模式发展，然而大多数软件仍是根据实际的顾客需求定制的。-交互式用户界面使用可复用构件构造图形窗口、下拉菜单和各种交互机制。,These slides are designed to acco
3、mpany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,4,5,遗留软件,软件必须进行适应性调整，以满足新的计算环境和技术的需求。 软件必须升级以实现新的商业需求。 软件必须扩展使之具有与更多现代系统和数据库的互操作能力。 软件必须进行改建使之能适应多样化的网络环境。,为什么一定要变更?,6,软件工程,若干事实: 在制定解决方案之前要理解问题 设计是一项关键的软件工程活动 软件必须保证高质量 软件需具备可维护性 种
4、子定义（Fritz Bauer)： （软件工程是）建立和使用一套合理的工程原则，以便经济地获得可靠的、可以在实际机器上高效运行的软件。-未提及软件质量，直接谈到用户满意度或按时交付产品的要求、忽略了测量和度量的重要性和有效的软件过程的重要性。,7,软件工程,IEEE 定义： 软件工程是：（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。（2）在(1)中所述方法的研究。 -需要规范，也需要可适应性和灵活性,8,一种过程框架,过程框架（process framework) 框架活动 工作任务(task) 工作产品 里程碑和可交付成果 QA 检查点 普适性
5、活动(umbrella activity),9,框架包含的活动,沟通 策划 建模 需求分析 设计 构建 代码生成 测试 部署,10,普适性活动,软件项目跟踪和控制 风险管理 软件质量保证 技术评审 测量 软件配置管理 可复用管理 工作产品的准备和生产,11,实践的精髓,Polya 的建议： 1.理解问题（沟通和分析）。 2.计划解决方案（建模和软件设计）。 3.实施计划 （代码生成）。 4.检查结果的准确性（测试和质量保证）。,12,Hooker的一般原则,1: 存在价值 2: 保持简洁 3: 保持愿景 4:关注使用者 5: 面向未来 6: 计划复用 7: 认真思考,13,第二章 通用过程模型
6、,软件过程,过程框架,普适性活动,软件工程活动#1.1,框架活动#1,工作任务 工作产品 质量保证点 项目里程碑,工作任务 工作产品 质量保证点 项目里程碑,框架活动#n,软件工程活动#n.1,软件工程动作#n.m,任务集,任务集,任务集,任务集,软降工程动作#1.k,工作任务 工作产品 质量保证点 项目里程碑,工作任务 工作产品 质量保证点 项目里程碑,14,过程流,沟通,策划,建模,(a)线性过程流,构建,部署,部署,构建,建模,策划,沟通,(b)迭代过程流,建模,构建,(c)演化过程流,部署,策划,沟通,增量交付,沟通,策划,建模,时间,构建,部署,(c)并行过程流,小型项目的获取需求任
7、务集,1.制定项目的利益相关者列表 2.邀请所有的利益相关者参加一个非正式会议。 3.征询每一个人对于软件特征和功能的需求。 4.讨论需求，并确定最终的需求列表。 5.划定需求优先级。 6.标出不确定领域。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.,15,大型项目的获取需求任务集,1.制定项目的利益相关者列表 2.和利益相关者的每一个
8、成员分别单独讨论，获取所有的要求。 3.基于任务集2中的调查，建立初步的功能和特征列表。 4.安排一系列促进需求获取的会议。 5.组织会议。 6.在每次会议上建立非正式的用户场景。 7.根据利益相关者的反馈，进一步细化用户场景。 8.建立一个修正的需求列表。 9.使用质量功能部署技术，划分需求优先级。 10.将需求打包以便软件可以增量交付。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright
9、 2009 by Roger Pressman.,16,大型项目的获取需求任务集（续）,11.标注系统的约束和限制。 12.讨论系统验证方法。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.,17,18,过程模式类型,步骤模式定义了与过程的框架活动相关的问题。例如“建立沟通”，它可能包括需求获取等任务模式 任务模式定义了与软件工程动作或是工
10、作任务相关、关系软件工程实践成败的问题。例如“需求获取” 阶段模式定义在过程中发生的框架活动序列，即使这些活动流本质上是迭代的。例如“螺旋模型”和“原型开发”,19,瀑布模型,沟通 项目启动 需求获取,策划 项目估算 进度计划 项目跟踪,建模 分析 设计,构建 编码 测试,部署 交付 支持 反馈,20,V模型,需求建模,体系结构设计,构件设计,代码生成,单元测试,集成测试,系统测试,验收测试,可执行软件,使用中遇到的问题,实际的项目很少遵守瀑布模型提出的顺序。 客户通常难以清楚地描述所有的需求。 客户必须要有耐心。,These slides are designed to accompany
11、Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.,21,适用情形,当需求确定、工作采用线性方式完成时。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.,22,23,
12、增量模型,第1个增量,第2个增量,第n个增量,交付第2个增量,交付第3个增量,交付第1个增量,软件功能和特征,项目时间,沟通,策划,建模 分析 设计,构件 编码 测试,部署 交付 反馈,沟通,沟通,策划,策划,建模 分析 设计,建模 分析 设计,构件 编码 测试,构件 编码 测试,部署 交付 反馈,部署 交付 反馈,适用情形,初始的软件需求明确，但是整个开发过程却不宜单纯运用线性模型。同时，可能迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再进行细化和扩展功能。例如第一个增量往往是核心产品，附加功能进入下个增量计划。,These slides are designed to a
13、ccompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.,24,特点,综合了线性过程流和并行过程流的特征。 每个增量都提交一个可以运行的产品。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009
14、by Roger Pressman.,25,26,演化模型:原型开发,Construction of prototype,沟通,快速策划,快速建模设计,构建原型,部署交付及反馈,适用情形,客户提出了一些基本功能，但没有详细定义功能和特性需求 开发人员可能对算法的效率、操作系统的兼容性和人机交互的形式等情况并不确定,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger
15、 Pressman.,27,特点,很少是好用的，可能太慢太大，难以使用。 一般作为被丢弃的系统。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.,28,29,演化模型：螺旋,策划 项目估算 制定进度计划 风险分析,建模 分析 设计,构建 编码 测试,部署 交付 反馈,沟通,开始,特点,采用循环的方式逐步加深系统定义和实现的深度，同时降低风险
16、。 确定一系列里程碑，确保利益相关者都支持可行的和令人满意的系统解决方案。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.,30,31,演化模型：协同,建模活动,非活动状态,表示阮籍工程活动 或任务的某一状态,完成状态,已建立基线,正在评审状态,正在开发状态,等待变更请求,正在修改状态,特点(以建模活动为例）,在某一特定时间，建模活动可能处
17、于图中所示的任何一种状态中。其他活动、动作或任务，可以用类似的方式表示。 所有的软件工程活动同时存在并处于不同的状态。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.,32,33,其他过程模型,基于构件的开发这个过程模型能够使软件复用，是一个发展目标 形式化方法强调需求的数学规范说明一个变型是净室（ cleanroom)软件工程。 面向方面
18、的软件开发（AOSD）为定义、说明、设计和构建方面提供过程和方法如果某个关注点涉及系统多个方面的功能、特性和信息，可称为横切关注点，由方面性需求来定义。 统一过程一种“用例驱动，以架构为核心，迭代并且增量”的软件过程与统一建模语言的紧密结合,34,统一过程(UP),起始,细化,策划,沟通,部署,转换,构建,构建,建模,生产,发布,软件增量,35,UP 阶段,UP阶段,需求,工作流,分析,设计,实现,测试,支持,迭代,起始,细化,构建,转换,生产,36,UP工作产品,起始阶段,愿景文档 初始用例模型 初始项目术语 初始商业案例 初始风险评估 项目计划， 阶段和迭代。 商业模型，如果必要 一个或更
19、多的原型开发,细化阶段,构建阶段,转换阶段,用例模型 包括非功能性的补充需求 分析模型 软件体系结构描述 可执行体系结构原型 初步设计模型 修订风险列表 包含迭代计划的项目策划 调整工作流里程碑 技术工作产品 初步用户手册,设计模型 软件构件 集成软件 增量 测试计划和步骤 测试用例 支持文档 用户手册 安装手册 当前增量说明,交付软件增量 Beta测试报告 一般用户反馈,37,第四章 质量功能部署（QFD),(Quality Function Deployment, QFD)-将客户要求转化成软件技术需求的质量管理技术 3类需求：正常需求、期望需求和令人兴奋的需求 功能部署决定系统所需的每一
20、个功能的“价值”（由客户感知） 信息部署确定数据对象和事件 任务部署检查系统行为 价值分析决定需求的相对优先权 用户场景识别将要构建系统的使用线索 产生需求表,38,第七章 设计,Mitch Kapor，Lotus 1-2-3的创始人,在 Dr. Dobbs杂志上发表了“软件设计宣言”，他说： 良好的软件设计应该展示： 坚固：程序应该不含任何妨碍其功能的缺陷。 适用：程序应该符合开发的目标。 愉悦：使用程序的体验应是愉快的。,实现设计目标的途径,先实现多样化（获取所有方案和设计的原始资料，包括目录、教科书和头脑中的构件、构件方案和知识），然后再进行聚合。 汇聚信息后，挑选合适的元素，考虑取舍候
21、选方案，然后聚合，使之成为“构件的某种特定的配置，从而创建最终的产品。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman.,39,40,设计模型,数据设计 信息模型 软件数据结构 体系结构设计 定义软件部件间的关系 接口设计 软件内部、外部及与人之间的通信 构件级（过程）设计 软件组件的过程性描述,41,分析模型- 设计模型,基于场景的元素 用例
22、文本 用例图 活动图 泳道图,基于类的元素 类图 分析包 CRC模型 协作图,行为元素 状态图 顺序图,面向流的元素 数据流图 控制流图 处理叙述,设计模型,数据/类设计,体系结构设计,接口设计,构件级设计,分析模型,42,质量指导原则,设计应展示出这样一种结构：（a）已经使用可识别的体系结构风格或模式创建；（b）由展示出良好设计特征的构件构成；（c）能够以演化的方式实现，从而便于实现和测试。 对于更小的系统，设计有时可以线性开发。 设计应该模块化；也就是说，应将软件逻辑地划分为元素或子系统。 设计应该包含数据、体系结构、接口和构件的清晰表示。 设计应导出数据结构，这些数据结构适用于要实现的类
23、，并从可识别的数据模式提取。 设计应导出显示独立功能特征的构件。 设计应导出接口，这些接口降低了构件之间以及与外部环境连接的复杂性。 设计的导出应根据软件需求分析过程中获取的信息采用可重复的方法进行。 应使用能够有效传达其意义的表示法来表达设计。,43,设计原则,设计过程中不要有“井蛙之见”。 设计应起源于分析模型。 设计不要白费力气做重复工作。 在软件和真实世界的问题之间，设计应能“最小化知识距离” DAV95 。 设计应表现出一致性和集成性。 设计结构应适应变化。 即使遇到数据、事件或操作条件异常时，设计结构应能温和处理。 设计不是编码，编码不是设计。 创建设计时就应对其质量进行评估，而不
24、是创建之后。 评审设计以最小化概念上的（语义的）错误。,来自 Davis DAV95,44,为什么要信息隐藏？,减少“负效应”的可能性 限制全局影响局部的设计决策 强调通过控制接口通信 不提倡使用全局数据 导致封装高质量设计的属性 导致高质量软件,45,功能独立,通过开发具有“专一”功能和“避免”与其他模块过多的交互的模块，可以实现功能独立。 模块的独立性有两条定性标准进行评估： 内聚性显示了某个模块相关功能的强度。 一个内聚的模块执行一个独立的任务，与程序的其他部分构件只需要很少的交互。简单地说，一个内聚的模块应该（理想情况下）只完成一件事情。 耦合性显示了模块间的相互依赖性。 耦合性依赖于
25、模块之间的接口复杂性、引用或进入模块所在的点以及什么数据通过接口进行传递。 模块的独立性高 块内联系强 块间联系弱,46,七种内聚,偶然内聚模块内各元素间无实质性联系，功能无关；如：“读A”和“写B”等操作，就是被整合在一 个模块中，供其他模块调用。 逻辑内聚模块内各元素在逻辑上相似功能；如：两个逻辑上相似的两个功能放在同一个 模块中，可以省去其中重复的部分。 时间内聚模块内各元素在同一时间段内执行；如：变量初始化等，在同一时间内执行,47,七种内聚,过程内聚模块内元素必须以特定次序执行； 通信内聚模块内所有元素使用同一输入，产生同一输出； 顺序内聚模块内元素必须以特定次序执行，前者输出为后者
26、输入； 功能内聚模块内元素组成不可分的整体，完成特定功能。,48,七种耦合,非直接耦合两模块间没有直接联系 数据耦合通过数据参数访问另一模块 特征耦合通过数据结构传递记录信息 控制耦合通过控制参数或开关量来访问另一模块 外部耦合一组模块访问同一全局简单变量 公共耦合一组模块访问同一公共数据结构 内容耦合一个模块直接转入另一模块内,49,第八章 体系结构风格,每种风格描述一种系统类别，包括： （1）完成系统需要的某种功能的一组构件（例如，数据库、计算模块）； （2）能使构件间实现“通信、合作和协调”的一组连接件； （3）定义构件如何集成为系统的约束； （4）语义模型，能使设计者通过分析系统组成成
27、分的已知属性来理解系统的整体性质 。,50,体系结构风格,以数据为中心的体系结构 数据流体系结构 调用和返回体系结构 面向对象体系结构 层次体系结构,51,第九章 基本设计原则,开闭原则(OCP)。“模块构件应该对外延具有开放性，对修改具有封闭性”。 Liskov 替换原则(LSP)。“子类可以替换它们的基类”。 依赖倒置原则(DIP)。“依赖于抽象，而非具体实现”。 接口分离原则(ISP)。“多个客户专用接口比一个通用接口要好”。 发布复用等价性原则(REP)。“复用的粒度就是发布的粒度”。 共同封装原则(CCP)。“一同变更的类应该合在一起”。 共同复用原则(CRP).。“不能一起复用的类
28、不能被分到一组”。,来源: Martin, R., “设计原则和设计模式”下载：http:, 2000.,52,第十章 黄金规则,用户操纵控制 减少用户的记忆负担 保持界面一致,53,用户操作控制,以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式。 提供灵活的交互。 允许用户交互被中断和撤销。 当技能级别增长时可以使交互流线化并允许定制交互。 使用户与内部技术细节隔离开来。 设计应允许用户与出现在屏幕上的对象直接交互。,54,减轻用户记忆负担,减少对短期记忆的要求。 建立有意义的缺省。 定义直观的快捷方式。 界面的视觉布局应该基于真实世界的象征。 以不断进展的方式揭示信息。,55,保
29、持界面一致,允许用户将当前任务放入有意义的环境中。 在应用系统家族内保持一致性。 如果过去的交互模型已经建立起了用户期望，除非有不得已的理由，否则不要改变它。,第十四章 软件质量保证,延伸前述的质量定义，软件质量保证就是为了保证软件高质量而必需的“有计划、系统化的行动模式”。软件质量保证（质量管理）是适用于整个软件过程的一种普适性活动，而不仅仅是在编码完成之后才开始进行。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). S
30、lides copyright 2009 by Roger Pressman.,56,软件质量保证,软件质量保证是由两个不同人群相联系的多种任务组成分别是做技术工作的软件工程师和负有质量策划、监督、记录、分析和报告责任的软件质量保证组。 其中，软件工程师通过采用可靠的技术方法和措施，进行技术评审，并进行周密计划的软件测试来获得质量。 可见，软件测试是软件质量保证活动中的一部分。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009)
31、. Slides copyright 2009 by Roger Pressman.,57,58,软件测试,测试是在交付产品给最终用户之前，带着特定的目的在运行程序的过程中发现错误。,测试的目的是为了发现测试对象的问题，而不是证明测试对象没有问题。,59,验证与确认 书为主,软件测试是通常所讲的更为广泛的主题验证与确认的一部分。 验证是指确保软件正确地实现某一特定功能的一系列活动。 确认指的是确保开发的软件可追溯到客户需求的另外一系列活动。Boehm Boe81 用另一种方式说明了这两者的区别： 验证：我们在正确地构造产品吗？ 确认：我们在构造正确的产品吗？,单元测试,单元测试是对软件的基本组
32、成单元进行测试。 单元可以是：函数、子过程类或类的方法独立的过程和函数一个菜单或显示界面,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,60,单元测试的主要任务,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
33、 (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,61,增量式测试,增量式测试的集成是逐步实现的：逐次将未曾集成测试的模块和已经集成测试的模块（或子系统）结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。 按照不同的实施次序，增量式集成测试又可以分为三种不同的方法：（1）自顶向下增量式测试（2）自底向上增量式测试（3）三明治测试混合增量测试,These slides are designed to accompany Software Engineering: A Prac
34、titioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,62,自顶向下增量式测试,自顶向下增量式测试表示逐步集成和逐步测试是按照结构图自上而下进行的，即模块集成的顺序是首先集成主控模块（主程序），然后依照控制层次结构向下进行集成。从属于主控模块的按深度优先方式（纵向）或者广度优先方式（横向）集成到结构中去。 深度优先方式的集成：首先集成在结构中的一个主控路径下的所有模块，主控路径的选择是任意的。 广度优先方式的集成：首先沿着水平方向，把每一层中所有直接隶属于上一层的模块集成起来，直
35、到底层。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,63,64,自顶向下集成,带桩的顶层模块测试,一次替换一个桩模块，“深度优先”,当集成新的模块时，重新运行某些测试子集,A,B,C,D,E,F,G,top module is tested with,stubs,stubs are replaced one at,a time, “de
36、pth first“,as new modules are integrated,some subset of tests is re-run,自底向上增量式测试,自底向上增量式测试表示逐步集成和逐步测试的工作是按结构图自下而上进行的，即从程序模块结构的最底层模块开始集成和测试。 由于是从最底层开始集成，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经集成并测试完成，所以不再需要使用桩模块进行辅助测试。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。,These slides are designed to accompany Software Enginee
37、ring: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,65,66,自底向上集成,一次替换一个驱动模块，“深度优先”,集成工作模块并将其分组为簇,A,B,C,D,E,F,G,簇,drivers are replaced one at a,time, “depth first“,worker modules are grouped into,builds and integrated,cluster,67,三明治测试,带桩测试顶层模块,A,B,C,D,E,F,
38、G,簇,集成工作模块并将其分组为簇,Top modules are tested with stubs,Worker modules are grouped into,builds and integrated,cluster,混合增量式测试是把自顶向下测试和自底向上测试这两种方式结合起来进行集成和测试。这样可以兼具两者的优点，而摒弃其缺点。,68,回归测试,回归测试重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用。 无论什么时候修正软件，软件配置的某些方面（程序、文档或支持数据）也发生变更。 回归测试有助于保证变更（由于测试或其他原因）不引入无意识行为或额外的错误。 回归测试可以
39、手工进行，方法是重新执行所有测试用例的子集，或者利用捕捉/回放工具自动进行。,69,冒烟测试,为生产软件创建“每日构建”的一种常见方法 冒烟测试步骤： 将已经转换为代码的软件构件集成到“构建”中去。 一个构建包括所有的数据文件、库、可复用的模块以及实现一个或多个产品功能所需的工程化构件。 设计一系列测试以暴露影响构建正确地完成其功能的错误。 其目的是为了发现极有可能造成项目延迟的“业务阻塞”错误。 每天将该构建与其他构建及整个软件产品（以其当前的形式）集成起来进行冒烟测试。 这种集成方法可以是自顶向下，也可以自底向上。,70,测试CRC模型,检查CRC模型和对象-关系模型。 检查每一张CRC索
40、引片的描述以确定委托责任是定义协作者的一部分。 反转连接，确保每个提供服务的协作者都从合理的地方收到请求。 使用步骤3中反转后的结果，确定是否真正需要其他类，或者责任在类之间的组织是否合适。 确定是否可以将广泛请求的多个责任组合为一个责任。 将步骤1到步骤5反复应用到每个类及分析模型的每一次评估中。,71,高阶测试,确认测试 关注点是软件需求 确认测试也称为合格性测试，是检验所开发的软件是否能按用户提出的要求进行。软件确认要通过一系列证明软件功能和要求一致的黑盒测试来完成，传统软件、面向对象软件及WebApp之间的差别已经消失。 系统测试 关注点是系统集成 由于软件只是计算机系统中的一个组成部
41、分，软件开发完成之后，最终还要和系统中的硬件系统、某些支持软件、数据信息等其他部分配套运行。这些测试已经超出软件过程范围，而且不仅仅由软件工程师执行。 /测试 关注点是客户使用 测试是由有代表性的最终用户在开发者的现场进行的，开发者在后面观看，并记录错误和使用问题。 测试是在一个或者多个最终用户场所进行。开发者通常不在场。,高阶测试,恢复测试 通过各种方式强制地使软件发生故障，并验证其能适当恢复。 安全测试 验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵。 压力测试以非正常的数量、频率或容量的方式执行系统。测试是想要破坏程序。 举例： 如果正常的中断频率为每秒5次，强度测试设计为每
42、秒50次中断。 把输入数据的量提高一个数量级来测试输入功能会如何响应。 若某系统正常运行可支持200个终端并行工作，强度测试则检验1000个终端并行工作的情况。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,72,高阶测试,性能测试 用来测试软件在集成环境中的运行性能，特别是针对实时系统和嵌入式系统，仅提供符合功能需求但不符合性能需求的软件
43、是不能被接受的。 性能测试可以在测试过程的任意阶段进行，但只有当整个系统的所有成分都集成在一起后，才能检查一个系统的真正性能。 性能测试常常和强度（压力）测试结合起来进行，而且常常需要硬件和软件测试设备，这就是说，常常有必要在一种苛刻的环境中衡量资源的使用（比如，处理器周期）。,These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.,73,74,第十
44、五章 可测试性,软件工程师在设计与实现基于计算机的系统或产品时，应该想着可测试性。 软件的可测试性是能够被测试的容易程度。可测试的软件应该具有下述特征： 可操作性有效地操作 可观察性每个测试用例的结果都是易观察的 可控制性测试能被自动化执行和优化的程度 可分解性有针对的测试 简单性减少复杂的体系结构和逻辑以简化测试 稳定性测试过程需求变更不经常发生 易理解性对设计的较好理解,75,什么是“好”的测试,好的测试有较高的发现错误的可能性 好的测试是不冗余的 好的测试应该是“最佳品种” 好的测试应该既不简单也不太复杂,76,第十八章 有效的软件项目管理-4个P,人员 一个成功项目最重要的元素 产品
45、建立的软件 过程 框架活动集和完成工作的软件工程任务 项目 所有需要做的工作，以使一个产品变成现实,人员-people-CMM的关键实践域,人员配备 沟通与协调 工作环境 业绩管理 培训 报酬 能力素质分析与开发 个人事业发展 工作组发展 团队精神或企业文化培养,77,78,团队负责人,MOI 模型（Motivation, Organization, Ideas or Innovation) 激励。(通过 “推” 或 “拉”) 鼓励技术人员发挥其最大才能的一种能力。 组织。形成能够将最初概念转换成最终产品的现有过程 (或创造新的过程) 的能力。 思想或创新。 即使必须在特定软件产品或应用系统的
46、约束下工作，也能鼓励人们去创造并让人感到有创造性的一种能力。,79,软件团队,待解决问题的难度 开发程序的规模 ，以代码行或者功能点来度量 团队成员需要共同工作的时间 (团队生存期) 能够对问题做模块化划分的程度 待开发系统的质量要求和可靠性要求 交付日期的严格程度 项目所需要的友好交流的程度,选择软件项目团队结构时应该考虑以下7个因素：,80,封闭式范型 按照传统的权利层次来组织团队1个高级工程师（主程序员），2-5个技术人员，1个后备工程师 随机式范型 松散地组织团队，团队工作依赖于团队成员个人的主动性 开放式范型 试图以一种既具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织团
47、队 同步式范型依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没有什么主动的交流,组织范型,Constantine Con93提出,81,“团队毒性”,狂乱的工作氛围；使团队成员浪费精力，同时也使他们在工作中表现出毫无目的性。 引起团队成员间产生摩擦的重大挫折由个人、商业和技术因素引起的重大挫折导致团队成员间产生摩擦。 “碎片式的或协调很差”的软件过程缺乏定义的或选择不合适的过程模型都会成为成功路上的路障。 在软件团队中没有清晰的角色定义不清晰的角色定义导致缺乏责任，并相互指责。 “接连不断地重蹈覆辙” 使团队成员失去信心并降低斗志。,避免“团队毒性”,项目经理应确保团队可获取
48、完成工作所需的所有信息；主要目标一旦确定（除非绝对必要），就不应该修改 给予软件团队尽可能多的决策权。 理解将要开发的产品和完成工作的人员，以及允许团队选择过程模型。 团队本身应该建立自己的责任机制（技术评审），并规定一系列当团队未能完成任务时的纠正方法。 建立基于团队的信息反馈方法和解决问题的技术。,82,83,项目,项目正处于危险状态的信号 ，当 软件人员不了解客户的需求。 产品范围定义得很糟糕。 没有很好地管理变更。 所选的技术发生了变化。 业务需求发生了变化 或未能很好地定义。 截止日期是不切实际的。 客户抵制。 失去赞助 或从来没有真正得到过赞助。 项目团队缺乏具有合适技能的人员。
49、管理者 和开发人员 没有很好地利用已学到的最佳实践和经验。,84,W5HH原则,为什么（Why) 要开发这个系统?商业目的是否有效？为达到此目的是否值得花费这些人力、时间和金钱？ 将要做什么(What)? 定义项目所需的任务集 什么时候(When)做?制定项目进度，标识出何时开展项目任务以及何时到达里程碑。 某功能由谁(Who)负责?规定软件团队每个成员的角色和责任。,W5HH原则（续）,他们的机构组织位于何处(Where)?并非所有角色和责任均属于软件团队，客户、用户和其他利益相关者也有责任。 如何(How)完成技术工作和管理工作?一旦确定了产品范围，就必须定义项目的管理策略和技术策略。 每种资源需要多少(how much) (例如，人、软件、工具、数据库)? 通过估算。Barry Boehm Boe96,85,
