当前位置：文档之家 › 软件工程：实践者的研究方法(第七版)_全部章节讲义

软件工程：实践者的研究方法(第七版)_全部章节讲义

  • 格式：pdf
  • 大小：2.01 MB
  • 文档页数：83

下载文档原格式

  / 83

合集下载

《软件工程-实践者的研究方法》chapter_12_cn_评审技术PPT课件

《软件工程-实践者的研究方法》chapter_12_cn_评审技术PPT课件


Associates, Inc., copyright © 1996, 2001, 2005
6
缺陷放大和消除
可以用“缺陷放大模型”来说明在软件工程过程的设计和 编码活动中错误的产生和检测。该模型如下图所示：
Errors from Previous step
Defects
Detection
Errors passed through Percent
Associates, Inc., copyright © 1996, 2001, 2005
5
软件缺陷对成本的影响
❖在软件过程的环境中，术语缺陷(defect)和故障 (fault)是同义词，两者都是指在软件发布给最终用 户(或软件过程内其他框架活动)后发现的质量问题。
❖术语错误(error)来描绘在在软件发布给最终用户 (或软件过程内其他框架活动)之前软件工程师(或 其他人)发现的质量问题。
❖正式技术评审的主要目标是在软件过程中发现错 误，以使它们不会在软件交付之后变成缺陷(fault) 正式技术评审最明显的优点就是可以早些发现错 误，以防止将错误传递到软件过程的后续阶段。
.Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &
Associates, Inc., copyright © 1996, 2001, 2005
2
什么是评审?
由技术人员领导，并面向技术人员的一个会议 在软件工程过程中，对一个工作产品的技术评估 一种软件质量保证机制 一个培训园地
.Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &
《软件工程-实践者的研究方法》chapter_17.ppt

《软件工程-实践者的研究方法》chapter_17.ppt


2
What Are These Changes?
changes in business requirements
changes in technical requirements
changes in user requirements
other documents
Project Plan
software models
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
Bersoff, et al, 1980
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
4
Baselines
The IEEE (IEEE Std. No. 610.12-1990) defines a baseline as:
• A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.
软件工程：实践者的研究方法(第七版)_讲义_第十一章 质量概念

软件工程：实践者的研究方法(第七版)_讲义_第十一章 质量概念


ISO 9126质量因素
功能性：软件满足已确定要求的程度，由以下子属性表 征：适合性、准确性、互操作性、依从性和安全保密性。 可靠性：软件可用的时间长度，由以下子属性表征：成 熟性、容错性和易恢复性。 易用性：软件容易使用的程度，由以下子属性表征：易 理解性、易学习性和易操作性。 效率：软件优化使用系统资源的程度，由以下子属性表 征：时间特性和资源利用特性。 维护性：软件易于修复的程度，由以下子属性表征：易 分析性、易改变性、稳定性和易测试性。 可移植性：软件可以从一个环境移植到另一个环境的容 易程度，由以下子属性表征：适应性、易安装性、符合 性和易替换性。

Garvin的质量维度
耐久性。是否能够对软件进行维护或改正，而 不会粗心大意地产生料想不到的副作用？随着时 间的推移，变更会使错误率或可靠性变得更糟吗？ 适用性。软件能在可接受的短时期内完成维护 和改正吗？技术支持人员能得到所需的所有信息 以进行变更和修正缺陷吗？ 审美。美的东西具有某种优雅、特有的流畅和 醒目的外在，这些都是很难量化的，但显然是不 可缺少的。美的软件具有这些特征。 感知。在某些情况下，一些偏见将影响人们对 质量的感知。
预防成本包括：(1)计划和协调所有质量控制和 质量保证所需管理活动的成本；(2)为开发完整 的需求模型和设计模型所增加的技术活动的成本； (3)测试计划的成本；(4)与这些活动有关的所 有培训成本。 评估成本包括为深入了解产品“第一次通过” 每个过程的条件而进行的活动。评估成本的例子 包括：


管理活动的影响
估算决策。在确定交付日期和制定总预算 之前，给软件团队提供项目估算数据是很 少见的。 进度安排决策。当建立了软件项目时间表 时，按照依赖性安排任务的先后顺序。 面向风险的决策。风险管理是成功软件项 目的关键特性之一。
《软件工程-实践者的研究方法》chapter_17_cn_软件配置管理PPT精品文档23页

《软件工程-实践者的研究方法》chapter_17_cn_软件配置管理PPT精品文档23页

Bus ines s Cont ent
u se -case s an aly sis m o d e l
sce n ario -b ase d d iag ram s f lo w -o rie n t e d d iag ram s class-b ase d d iag ram s b e h av io ral d iag ram s d e sig n m o d e l arch it e ct u ral d iag ram s in t e rf ace d iag ram s co m p o n e n t -le v e l d iag ram s t e ch n ical m e t rics
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s
Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001,
Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001,
2005
9
SCM 库
SCM中心库是一组机制和数据结构，使软件团队能够 用一种更有效地方法管理变更。
已经通过正式评审和批准的规格说明或产品，它可以作为 进一步开发的基础，并且只有通过正式的变更控制规程才 能修改它。
软件工程实践者的研究方法讲义.ppt

软件工程实践者的研究方法讲义.ppt

❖在开始估算之前，首先要对范围陈述中 描述的功能进行评估，在某些情况下，还 要进行细化，以提供更多的细节。由于成 本和进度的估算都是面向功能的，因此某 种程度上的功能分解常常是有用的。性能 方面的考虑包括处理时间和响应时间的需 求。约束条件则标识了外部硬件、可用存 储，或其他现有系统对软件的限制。
软件范围和可行性
对估算的观察
❖估算的风险取决于对资源、成本及进 度的定量估算中存在的不确定性。如 果对项目范围不太了解，或者项目需 求经常改变，不确定性和估算风险就 会非常高。计划人员，尤其是客户， 都应该认识到经常改变软件需求意味 着在成本和进度上的不稳定性。
项目策划过程
❖软件项目策划的目标是提供一个能使管理 人员对资源、成本及进度做出合理估算的 框架。此外，估算应该尝试定义“最好的 情况”和“最坏的情况”，使项目的结果 能够限制在一定范围内。项目计划是在计 划任务中创建的，尽管它具有与生俱来的 不确定性，软件团队还是要根据它着手开 发。因此，随着项目的进展，必须不断地 对计划进行调整和更新。
估算
❖ 如果有经验并遵循系统化的方法，使用 可靠的历史数据进行估算，利用至少两种 不同的方法创建估算数据点，制定现实的 进度表并随着项目的进展不断进行调整， 则可以确信已经为项目做了最好的估算。
估算
❖软件项目管理从一组统称为项目策划的活 动开始。在项目可以开始前，项目经理和 软件团队必须估算将要完成的工作、所需 的资源，以及从开始到完成所需要的时间。 这些活动一旦完成，软件团队就要制定项 目进度计划。在项目进度计划中，要定义 软件工程任务及里程碑，确定每一项任务 的负责人，详细指明对项目进展影响很大 的任务间的相互依赖关系。
估算
❖软件项目经理——利用从共利益者和软件工程 师那里获得的信息以及从以往项目收集的软件度 量数据。 ❖估算首先要描述产品的范围。然后，将问题分 解为一组较小的问题，再以历史数据和经验为指 南，对每个小问题进行估算。在进行最终的估算 之前，要考虑问题的复杂度和风险。 ❖工作产品是生成一个简单的表，描述要完成的 任务、要实现的功能，以及完成每一项所需的成 本、工作量和时间。
《软件工程-实践者的研究方法》chapter_07.ppt

《软件工程-实践者的研究方法》chapter_07.ppt

the design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.
the design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.
be ha v i or a l element s
state diagrams sequence diagrams
Com pone nt Le v e l De sign
Int e rfa c e De sign Arc hit e c t ura l De sign
D a t a / Cla ss D e sig n
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman.
Design Model
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman.
《软件工程-实践者的研究方法》chapter_09_cn_构件设计共15页

《软件工程-实践者的研究方法》chapter_09_cn_构件设计共15页


Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001,
2005
2
什么是构件？
在面向对象软件工程环境中，构件包括一组协作的类 （有时，一个构件只包含一个单独的类）。
2005
5
基本设计原则
开关原则/The Open-Closed Principle (OCP). “A module [component] should be open for extension but closed for modification.
什么是构件？
构件是计算机软件中的一个模块化的构造块。 OMG UML规范对构件的定义：系统中模块化的、可配
置的和可替换的部件，该部件封装了实现并暴露了一组 接口。 OMG Unified Modeling Language Specification [OMG01] defines a component as
com put ePageC ost ( ) com put ePaper C ost ( ) com put ePr odC ost ( ) c o m p u t e To t a lJ o b C o s t ( )
< < in t e r f a c e > > in it ia t e J o b
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s
Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001,
软件工程实践者的研究方法讲义第二十一章项目进度安排

软件工程实践者的研究方法讲义第二十一章项目进度安排

软件工程实践者的研究方法讲义第二 十一章项目进度安排
工作量分配
❖因为在软件设计时投入了相当的工作量， 随后的编码工作就变得相对简单。总体工 作量的15%-20%就可以完成这一工作。 测试和随之而来的调试工作将占用30%40%的软件开发工作量。软件的重要性 决定了所需测试工作的分量，如果软件系 统是人命相关的，就应该考虑分配更高的 测试工作量比例。
软件工程实践者的研究方法讲义第二 十一章项目进度安排
人员与工作量之间的关系
❖除去学习系统所需的时间之外，新加入人员将 会增加人员之间交流的路径数量和整个项目中交 流的复杂度。虽然交流对于一个成功的软件开发 项目而言绝对是必不可少的，但是每增加一条新 的交流路径就会增加额外的工作量，从而需要更 多的时间。 ❖多年以来的经验数据和理论分析都表明项目进 度是具有弹性的。即在一定程度上可以缩短项目 交付日期，也可以拖延项目交付日期。
软件工程实践者的研究方法讲义第二 十一章项目进度安排
实例
❖假定一个软件工程团队受命开发一个实时 控制器软件，将在9个月内推向市场，在 进行了仔细的估算和风险分析之后，软件 项目管理者得到的结论是：在现有人员条 件下，需要14个月的时间才能完成这一软 件。这位项目管理者下一步该怎么办呢？
软件工程实践者的研究方法讲义第二 十一章项目进度安排
软件工程实践者的研究方法讲义第二 十一章项目进度安排
项目进度安排
❖技术性项目的现实情况是，在实现一个大 目标之前必须完成数以百计的小任务。这 些任务中有些是处于主流之外的，其进度 不会影响到整个项目的完成时间。而有些 任务则是位于“关键路径”之上的，如果 这些“关键”任务的进度拖后，则整个项 目的完成日期就会受到威胁。
软件工程实践者的研究方法讲义第二 十一章项目进度安排
软件工程实践者的研究方法讲义(PPT29张)

软件工程实践者的研究方法讲义(PPT29张)


软件风险

一般认为软件风险包含两个特性：

不确定性——风险可能发生也可能不发生； 损失——如果风险发生，就会产生恶性后果或损失。
进行风险分析时，重要的是量化每个风险的不 确定程度和损失程度。为了实现这点，必须考虑 不同类型的风险。 项目风险威胁到项目计划。如果项目风险发生， 就有可能会拖延项目的进度和增加项目的成本。 项目风险是指预算、进度、人员、资源、利益相 关方、需求等方面的潜在问题以及它们对软件项 目的影响。
风险管理
工作产品是风险缓解、监测和管理计划或 一且风险信息表单。 所要分析和管理的风险，应该通过彻底研 究人员、产品、过程和项目来确定。 RMMM计划应该随着项目的进展而修订， 以保证所考虑的风险是近期可能发生的。 风险管理的应急计划应该是符合实际的。

风险管理

首先，风险涉及的是未来将要发生的事情。 今天和昨天的事情已不再关心。问题是： 我们是否能够通过改变今天的行为，而为 一个不同的、充满希望的、更美好的明天 创造机会。其次，风险涉及改变。如思想、 观念、行为、地点的改变……第三，风险 涉及选择，而选择本身就具有不确定性。 [CHA89]
1.高层的软件管理者和客户管理者已经正式承诺支持该项目了吗？ 2.最终用户对项目和待开发的系统/产品热心支持吗？ 3.软件工程团队及其客户充分理解需求了吗？ 4.客户已经完全地参与到需求定义中了吗？ 5.最终用户的期望现实吗？ 6.项目范围稳定吗？ 7.软件工程团队的技能搭配合理吗？ 8.项目需求稳定吗？ 9.项目团队对将实现的技术有经验吗？ 10.项目团队的人员数满足项目需要吗? 11.所有的客户/用户对项目的重要性和待开发的系统/产品的需求有共识 吗？
风险管理

对于软件工程领域中的风险，以上三条概念定义 是显而易见的。未来是我们所关心的——什么样的 风险会导致软件项目彻底失败？改变也是我们所关 心的——客户需求、开发技术、目标环境以及所有 其他与项目相关因素的改变将会对进度安排和总体 成功产生什么影响？最后，我们必须抓住选择机 会——应该采用什么方法及工具？需要多少人员参 与？对质量的要求要达到什么程度才是“足够的”？ 当没有办法消除风险，甚至连试图降低该风险也 存在疑问时，这个风险就是真正的风险了。“在弄 清楚软件项目中的”真正风险“之前，识别出所有 对管理者及开发者而言显而易见的风险是很重要的。
软件工程-实践者的研究方法-知识点

软件工程-实践者的研究方法-知识点

For personal use only in study and research; not for commercial use软件工程复习总结第1章软件工程介绍1．软件的定义软件是包括程序、数据及其相关文档的完整集合。

其中，程序是按照事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操作信息的数据结构；文档是与程序开发、维护和使用有关的图文材料。

For personal use only in study and research; not for commercial use软件的定义：1、指令的集合，通过执行这些指令可以满足预期的特征、功能和性能需求2、数据结构，它使得程序可以充分利用信息3描述程序操作和使用的文档2．软件的特征a) 软件是设计开发的，而不是传统意义上的生产制造的b) 软件不会磨损c) 虽然整个工业向着基于构件的构造模式发展，然而大多数软件仍是根据实际的顾客需求定制的3．软件与硬件的区别a) 软件是一种逻辑实体，而不是具体的物理实体b) 软件的生产与硬件不同，软件开发过程中没有明显的制造过程c) 软件在运行、使用期间没有磨损、老化问题d) 软件的开发、运行受到计算机系统的限制，不同程度地依赖于硬件和环境，导致了软件升级和移植地问题e) 软件复杂性越来越高f) 软件开发成本相当昂贵g) 大多数软件是新开发的，而不是通过已有的构件组装而来的h) 软件工程涉及诸多的社会因素4．遗留软件与软件的演化系统演化的原因:a) 系统需要修改其适应性，从而满足新的计算环境或者技术的需求b) 软件必须根据新的业务需求进行升级c) 软件必须扩展以具有与更多现代系统和数据库的协作能力d) 软件架构必须进行改建以适应多样化的网络环境30年来软件发展的规律：1、持续变化规律，2、复杂性增长规律，3、自我调控规律，4、组织稳定性守恒规律，5、保证通晓性规律，6、持续增长规律，质量衰减规律，7、反馈系统规律。

《软件工程-实践者的研究方法》chapter_17

《软件工程-实践者的研究方法》chapter_17


8
Repository Content
business rules business funct ions org anizat ion st ruct ure inform at ion arch it ect ure
Business Cont ent
u se-cases analy sis m odel
Provides the ability to track all the design and construction components and deliverables that result from a specific requirement specification
5
Baselines
modified SCIs
Softw are engineering
tasks
Formal
approved
SCIs
technical
SCIs
review s
Project database
stored SCIs
SCM controls
ex tr acted SCIs
BASELINES : System Specification Softw are Requirements Design Specification Source Code Test Plans/Procedures/Data Operational System
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

分析模型的元素
图5-3 分析模型的元素
基于场景建模

如果软件工程师了解最终用户（和其他参 与者）希望如何与系统交互，软件团队将 能够更好地、更准确地刻画系统特征，完 成更有针对性的分析和设计模型。使用 UML分析建模，将从开发用例、活动图和 泳道图形式的场景开始。
编写用例
用例捕获信息的产生者、使用者和系统本 身之间发生的交互。 用例从某个特定参与者的角度用简单易懂 的语言说明一个特定的使用场景。但是我 们应该知道：(1)编写什么？(2)写多少？ (3)编写说明应该多详细？(4)如何组织说 明？
分析模型

必须评审分析建模工作产品的正确性、 完整性和一致性，必须反映所有共利益者 的要求并建立一个可以从中导出设计的基 础。
分析模型

在技术层面上，软件工程开始于一系列的 建模工作，最终生成待开发软件的需求规 格说明和全面的设计表示。需求模型实际 上是一组模型，是系统的第一个技术表示。
分析阶段的目标[DEM79]
需求分析
需求建模动作产生为以下一种或多种模型类型： 场景建模：出自各种系统“参与者”观点的需 求。 数据模型：描述问题信息域的模型。 面向类的模型：表示面向对象类的模型，其方 式为通过类的协作获得系统需求。 面向流程的模型：表示系统的功能元素并且描 述当功能元素在系统中运行时怎样进行数据变换 的模型。 行为模型：描述如何将软件行为看做是外部 “事件”后续的模型。


起动：房主在远离家的时候决定查看房屋 内部。
SafeHome实例[16]续

场景： 1.房主登录SafeHome产品网站。 2.房主输入用户身份证号。 3.房主输入两个密码（每个都至少有8个字符的长度）。 4.系统显示所有的主要功能按钮。 5.房主从主要功能按钮中选择“监视”。 6.房主选择“选取摄像头”。 7.系统显示房屋的平面设计图。 8.房主从房屋的平面设计图中选择某个摄像头的图标。 9.房主选择“视图”按钮。 10.系统显示一个由摄像头编号确定的视图窗口。 11.系统在视图窗口中以每秒一帧显示视频输出。

域分析

分析模型通常在特定业务领域内的很多应 用中重复发生。如果用一种方式对这些模 式加以定义和分类，让软件工程师或分析 师识别并复用这些模式，将促进分析模型 的创建。更重要的是，应用可复用的设计 模式和可执行的软件构件的可能性将显著 增加。
域分析
软件域分析是识别、分析和详细说明来自 某个特定应用领域的公共需求，特别是那 些在该应用领域内被多个项目重复使用 的……“面向对象的域分析”是在某个特 定应用领域内，根据通用的对象、类、部 件和框架、识别、分析和详细说明公共的、 可复用的能力。 域分析的目标很简单，就是：查找或创建 那些分析类和（或）能够广泛应用的、共 有的功能和特点，这样就可以复用。
开发活动图

UML活动图通过提供特定场景内交互流的 图形化表示来补充用例。活动图使用圆角 矩形表示一个特定的系统功能，箭头表示 通过系统的流，判定菱形表示判定分支， 水平线意味着并行发生的活动。ACS-DCV 功能的活动图如课本图5-5所示。
SafeHome系统ACS-DCV功能的活动图
图5-5 ACS-DCV功能的活动图

这些问题的答案导致创建一组次场景，次场景属 于原始用例的一部分，但是表现了可供选择的行 为。
SafeHome实例[15]
编写用例

除了前面部分提到的三个常规问题外，还 应该研究下面的问题：



在这个用例中是否有某些具有“有效功能”的用例 出现？包括引用确认功能，可能出现的出错条件。 在这个用例中是否有支持功能（或参与者）的应答 失败？ 性能差的系统是否会导致无法预期或不正确的用户 活动？

域分析的输入和输出
课本图5-2 域分析的输入和输 出
需求建模的方法
一种考虑数据和处理的需求建模方法被称 作结构化分析，其中数据作为独立实体转 换。数据对象建模定义了对象的属性和关 系，操作数据对象的处理建模应表明当数 据对象在系统内流动时处理如何转换数据。 分析建模的第二种方法称作面向对象的分 析，这种方法关注于定义类和影响客户需 求的类之间的协作方式。UML和统一过程 主要是面向对象的。

编写用例
两个首要的需求工程工作——起始和导 出——提供了开始编写用例所需要的信息。 运用需求收集会议、QFD和其他需求工程 机制确定共利益者，定义问题的范围，说 明整体的操作目标，概述所有已知的功能 需求，描述系统将处理的信息（对象）。 要开始开发用例，应列出特定参与者执行 的功能或活动。这些可以从所需系统功能 的列表中获得，或通过与客户或最终用户 交流获得，或通过评估活动图获得。
编写用例

在很多情况下，不需要创建使用场景的图 形化表示。但是图形化表示可以促进理解， 尤其是当场景比较复杂时。UML为用例提 供了图形化表现的能力。课本图5-4为 SafeHome系统的初步用例图。
SafeHome系统的初步用例图
图5-4 SafeHome系统的初步用例图
编写用例

每种建模方法都有其局限性，用例方法也 无例外，如果描述不清晰，用例可能会误 导或有歧义。一个用例关注功能和行为需 求，一般不适用于非功能需求。对于必须 特别详细和精准的需求建模情景，用例方 法就不够用了。
SafeHome实例[16]
监视的用例模板 用例：通过互联网访问摄像头监视 ——显示摄像 头视图（ACS-DCV）。 迭代：2，最新更新记录：V.Raman1月14日。 主要参与者：房主。 情境目标：从任何远程地点通过互联网查看遍布 房间的摄像头输出。 前提条件：必须完整配置系统；必须获得正确的 用户身份证号和密码。

编写用例

随着和共利益者更多地交谈，需求收集团 队为每个标记的功能开发用例。通常，用 例首先用非正式的描述性风格编写。如果 需要更正式一些，可以使用类似前一章中 提出的某个结构化的形式重新编写同样的 用例。
SafeHome实例[13]
编写用例

描述性用例的一种变形是通过用户活动的 顺序序列表现交互，每个活动由声明性的 语句表示。
软件工程
第5章 需求建模：场景、信息与类分析
主要内容
需求分析 基于场景建模 补充用例的UML模型 数据建模概念 基于类的建模 小结

分析模型
文字记录是极好的交流工具，但并不必然 是表达计算机软件需求的最好方式。分析 建模使用文字和图表的综合形式，以相对 容易理解的方式描绘需求的数据、功能和 行为，更重要的是，可以更直接地评审它 们的正确性、完整性和一致性。 软件工程师使用从客户那里提取的需求构 建模型。
SafeHome实例[16]续

异常： 1.身份证号或密码不正确或无法确认。——参 看用例：“确认身份证号和密码”。 2.没有为该系统配置监视功能——系统显示恰 当的错误消息；参看用例：“配置监视功能”。 3.房主选择“查看所有摄像头的缩略视图快 照”——参看用例：“查看所有摄像头的缩略视 图快照”。 4.平面设计图不可用或未配置——显示恰当的 错误消息，参看用例：“配置平面设计图”。 5.遇到报警条件——参看用例：“遇到报警条 件”。

分析模型

可以使用很多不同格式的图表为信息、功 能和行为需求建模。基于场景的建模从用 户的角度表现系统；面向流的建模在说明 数据对象如何通过处理函数进行转换方面 提供了指示；基于类的建模定义了对象、 属性和关系；行为建模描述了系统状态、 类和事件在这些类上的影响。一旦创建了 模型的雏形，就将不断改进，并分析评估 其清晰性、完整性和一致性。最终的分析 模型将由所有的共利益者确认。

分析建模的方法
软件团队往往选择一种方法并排斥另一种方法 中的所有表示手段。问题不是哪一种方法最好， 而是怎么组合这些表示手段才能够为共利益者提 供最好的软件需求模型和过渡到软件设计的最有 效方法。 分析模型将生成如课本图5-3所示的每个建模 元素的派生类。然而，不同项目之间，每个元素 的特定内容可能因项目而异。软件团队必须想办 法保持模型的简单性。只有那些为模型增加价值 的建模元素才能使用。
分析模型在系统级描述和软件设计的差距之间 建立桥梁。 重要的是要注意到在系统描述中给出分析模型 的某些元素，并且需求工程的工作实际上是作为 系统工程的一部分开始的。此外，分析模型的所 有元素都可以直接跟踪到设计模型。通常难以区 分这两个重要的建模活动之间的设计和分析工作， 有些设计总是作为分析的一部分进行，而有些分 析将在设计中进行。
分析的结果必须是高度可维护的，尤其是 要将此结果应用于目标文档。 必须使用一种有效的分割方法解决规模问 题。 尽可能使用图形符号。 考虑问题必须区分逻辑的和物理的。

需求分析

需求分析产生软件操作特征的规格说明， 指明软件和其他系统元素的接口，建立软 件必须满足的约束。需求分析让软件工程 师细化在前期需求工程的起始、导出、谈 判任务中建立的基础需求。
SafeHome实例[16]续
优先级：必须在基础功能之后实现，中等优先级。 何时可用：第三个增量。 使用频率：中等频度。 使用方式：通过基于个人计算机的浏览器和互联 网连接到SafeHome网站。 次要参与者：系统管理员，摄像头。 次要参与者的使用方式： 1.系统管理员：基于个人计算机的系统。 2.摄像头：无线连接。
SafeHome实例[14]
编写用例
这个连续的陈述没有考虑其他可能的交互。这种 类型的用例有时被称作主场景。 要完整地理解所描述的功能，必需说明可能的交 互。主场景中的每个步骤将通过如下提问得到评 估：


在这一点，参与者能进行一些其他活动吗？ 在这一点，参与者有没有可能遇到一些错误的情况？ 在这一点，参与者有没有可能遇到一些其他的行为？ 如果有，是什么？

SafeHome实例[16]续

未解决的问题： 1.有什么机制保护SafeHome产品的雇员 在未授权的情况下能使用该功能？ 2.足够安全吗？黑客入侵该功能将使最主 要的个人隐私受侵。 3.在给定摄像机视图所要求的带宽下，可 以接受通过互联网的系统响应吗？ 4.当可以使用高带宽的连接时，能开发出 比每秒一帧更快的视频速度吗？