软件工程-实践者的研究方法第八版(不全)

本文转载：软件工程 实践者的研究方法 中文题答案_/1的博客-CSDN博客 + 新添加的的几个答案

Solutions: CHAPTER 5: AGILE DEVELOPMENT
5.1) One situation in which one or more of the four “values“ could get a software team into trouble
would be Responding to change over following a plan. In many situations, wc no longer arc able to
define requirements fully before the project begins. Software engineers must be agile enough to
respond to a fluid business environment or else they might land up in trouble.

5.2) Agility can be apDlied to any software process. However, to accomplish this, it is
essential that〔he process be designed in a way that allow导 the project team lo adapi
tasks and to streamline them, conduct Dlanning in a way ihat understands the fluidity of
an agile development apinoach, eliminate all but the most essential work products and
keep them lean, and enyhasize an incremenlal delivery strategy ihat gets working
software 1。the customer as raDidly as feasible for the product type and uperaticnal
environment.

5.5) One more ''agility principle** that would help a software engineering team become even more
maneuverable would be, “A team should know whose skills suit a particular project, and get these
people on their project, for soHwarc development to become more effective", and ''Communication
is the key, the consumer and developer should constantly be communicating even if they arc
geographically sq)aratc(L they can web talk*'.

5.8) Most agile process models recommend fece-to-face communication. Yet today, members of a
software team and their customers may be geographically separated from one another in that case
Communication is the key, the consumer and developer should constantly be communicating even
if they arc geographically separated, they can wcbtalk or talk over the phone every now and then or
write emails, use chatting as the, means or a medium of conference call communication where 2
and more people can talk lo each other at the same time.

解决方案：第5章：敏捷发展

5.1）四个“值”中的一个或多个可能使软件团队陷入困境的情况将是根据计划应对变化。在许多情况下，我们不再能够在项目开始之前充分定义需求。软件工程师必须足够敏捷应对多变的商业环境，否则他们可能会陷入困境。

5.2）敏捷性可应用于任何软件过程。然而，为了实现这一点，至关重要的是，设计过程的方式应允许项目团队调整任务并使其合理化，以理解敏捷开发流程的流动性的方式进行规划，消除除最基本的工作产品之外的所有工作产品，并保持其精益求精，并制定一个增加交付策略，即在产品类型和上层环境下，尽可能快速地向客户提供工作软件。

5.5）还有一个“能力原则”可以帮助软件工程团队变得更具可操作性，那就是“团队应该知道谁的技能适合特定项目，并让这些人参与他们的项目，以便软件开发变得更有效”，以及“沟通”关键是，消费者和开发者应该不断沟通，即使他们是他们可以在网上聊天。

5.8）大多数敏捷流程模型都建议面对面交流。然而，如今，软件团队的成员和他们的客户可能在地理上彼此分离，在这种情况下，沟通是关键，消费者和开发人员应该不断地沟通，即使他们在地理上是分离的，他们可以时不时地通电话或打电话，或者写电子邮件，电话会议通信的手段或媒介，其中2人或更多人可以同时彼此交谈。

6.6) There can be more than one right answer for each scenario, depending on how the students
perceive the products that are being built in each environment.

6.7) Agile teams are self-organizing and may change its organizational structure during diflerent
phases of the project iifetime.

6.10) The cloud has the potential to make evolving software work products and artifacts available
to team members and stakeholders instantly. This can help make version control and acceptance
testing activities more eHicient.

6.12) Distance can make it harder to get in touch with team members (c.g. there may be 12 or
more hour diflerence in time of day). Team members living in difterent countries have diflerent
experiences, diflerent cultural expectations, and may speak difierent languages. Coordination
efforts become paramount in importance to the success of the project. Effective communication
requires a message to be sent, to be received, and to be responded to. Any one of this points of
future can prevent cflective exchange of information among team members and stakeholders.

6.6）根据学生的方式，每个场景可以有多个正确答案感知每个环境中正在构建的产品。

6.7）敏捷团队是自组织的，可能会在变化期间改变其组织结构项目的各个阶段。

6.10）云具有使不断发展的软件工作产品和工件可用的潜力立即发送给团队成员和利益相关者。这有助于进行版本控制和接受测试活动更加高效。

6.12）距离会使与团队成员联系更困难（例如，可能有12人或一天中的时间差更大）。生活在不同国家的团队成员不同的文化期望，可能会说不同的语言。协作努力对项目的成功至关重要。有效沟通需要发送、接收和响应消息未来可能会阻碍团队成员和利益相关者之间的选择性信息交流。

第一章 

1.1举出至少5个例子来说明“意外效应法则”在计算机软件方面的应用。 答:典型的例子包括使用“数字汽车仪表板”的软件，赋予高科技，高品质的图像的软件;如广泛的消费类电子产品的软件;个人电脑，工业仪器仪表和机器的软件。软件分化出的在电子商务方面的应用。 

1.2举例说明软件对社会的影响(包括正面影响和负面影响)。 

答:这是一个很好的课堂讨论问题(如果时间允许)，而不是专注于老生常谈的(但很重要)隐私问题，生活质量等问题。您可能想要讨论关于”技术恐惧“方面的问题，软件也许会使它恶化但也可能减少”技术恐惧“。另一个有趣的方面是使用诺依曼的“风险”列在SEN中做重点讨论。你也可以考虑基于软件的“现金”经济，新模式的互动娱乐，虚拟现实，电子商务等方面来思考软件对社会的影响。 

1.3针对1.1节提出的5个问题，请给出你的答案，并与同学讨论。 答:软件需要如此长的开发时间: 

a)设施不上线 

b)开发工具并不如预期般运作 

c)客户提出的新要求，需要重新设计和返工 

d)产品依赖于政府的规定，被意外更改。 

e)严格的要求，与现有系统的兼容性需要超过预期更多的测试，设计和实现。 f)多个操作系统下运行的任务需求比预期需要更长的时间。 

g)软件项目风险管理比预期需要更多的时间。 

h)依赖的技术仍处于开发阶段，从而延长日程安排。 

开发成本高: 

a)比当时预期低得令人无法接受的质量，需要进行更多的测试，设计和实施工作。 

b)制定了错误的软件功能需要重新设计和实施。 

c)开发错误的用户界面，而导致重新设计和实施。 

d)开发了不需要的额外的软件功能而延长了开发日程安排。 

在将软件交付顾客使用之前，我们无法找到所有错误: 

a)产品依赖于政府监管，意外而改变。 

b)产品技术标准草案，会意外更改。 

c)有时会在项目后期添加新的开发人员。 

d)因为团队内的冲突有时会导致沟通不畅，而产生糟糕的设计。 

e)破坏高效调度产生的项目管理成果和无效的规划 

f)有时装备部件质量差，导致额外的测试，设计和集成工作和管理额外的客户关系。 

软件开发和维护的过程仍旧难以度量: 

a)有时该项目的目的是不明确。 

b)有大量的业务所涉及的风险。 

c)如果产品内置没有装好。 

d)我们需要不断检讨我们的工作。 

e)进行维护检查的时间。 

f)在整个软件开发过程中要彻底组织项目团队。 

1.4在交付最终用户之前，或者首个版本投入使用之后，许多应用程序都会有频繁的变更。为防止变更引起软件退化，请提出一些有效的解决措施。 答:许多现代应用程序在他们呈现给最终用户之前和第一个版本别使用后经常改变，以下几个方面来阻止软件恶化: 

a)收集所需的信息。 

b)设计师和客户定义软件的总体目标。 

c)识别已知的需求。 

d)使用现有的程序片段后，有助于建立原型的开发人员的工作计划快速完成。 e)只有通过合格的培训或经验和充分揭露相关的不足，才能保持和提高我们的技术能力和让 

f)其他人承担技术任务 

g)文件应该被及时制定出来，在文件中应该有标准定义和机制建立。 h)完成某一特定阶段的审查工作。 

i)每一个关键团队成员应该配有一个后备人员 

j)检查规避风险的步骤是否应用正确 

k)对未来的风险分析中检查是否有必要收集必要的信息。 

1.5思考1.1.2节中提到的7个软件分类。请问能否采用一个软件工程方法，应用于所有的软件分类,并就你的答案加以解释。 

答:七个软件分类可应用于同样的方法。在这不确定的今天这些“新的挑战”，无疑有很大的影响(对于商务人士，软件工程师和最终用户来说)然而，软件工程师可以准备通过实例化一个过程，使其有足够的灵活性和适应性，以适应剧烈变化的技术，这技术一定要在未来的很长一段时间被商业规则所接受。 

1.6图1-3中，将软件工程三个层次放在了“质量关注点”这层之上。这意味着在整个开发组织内采用质量管理活动，如“全面质量管理”。仔细研究，并列出全面质量管理活动中关键原则的大纲。 

答:你也许建议同学阅读第十六章的知识来解决问题。 

1.7随着软件的普及，由于程序错误所带来的公众风险已经成为一个愈加重要的问题。设想一个真实场景，由于软件错误而引起“世界末日”般重大危害(危害社会经济或是人类生命财产安全)。 

答:确实有很多现实生活中的情况来选择，例如，软件错误，造成了重大的电话网络失败。 

如在航空电子设备故障导致飞机坠毁。计算机病毒(如米开朗基罗)的攻击给主要的电子商务网站造成了重大的经济损失。 

1.8用自己的话描述过程框架。当我们谈到框架活动适用于所有的项目时，是否意味着对于不同规模和复杂度的项目，可应用相同的工作任务,请解释。 答:过程框架适用于所有的项目，在相同的工作任务，适用于所有项目，无论其规模大小或复杂性。一个过程框架涉及大量的与客户沟通来收集需求;这个活动建立了一个软件工程工作计划。它涉及到创建模型，这将有助于开发人员

了解顾客的要求从而进行设计。从而涉及构建(代码生成和错误测试)。最后，它提供了基于评价的反馈。 

1.9普适性活动存在于整个软件过程中，你认为他们均匀分布于软件过程中，还是会集中在某个或者某些框架活动中, 

答:伞活动在整个软件过程中发生，它们被均匀地应用在整个过程中，分析还包含一系列的工作任务(例如需求收集，制定，协商规范和验证)，一个过程框架有一组伞被应用在整个软件过程活动中。这些活动包括:软件项目跟踪和控制，风险管理，软件质量保证，和正式的技术审查，测量，软件配置管理，可重用性管理和工作产品的制作和生产。 

1.10在1.5节所列举的神话中，增加两种软件神话，同时指出与其相对应的真实情况。 

答:没有标准答案(例如测试可以解决所有的程序错误)。 

第二章 

2.1在本章的介绍中，Baetjer说过:“软件过程为用户和设计者之间、用户和开发工具之间以及设计者和开发工具之间提供交互的途径[技术]”。对于要构建的软件产品，在以下方面设计五个问题:(a)设计者应该问用户的问题;(b)用户应该问设计者的问题;(c)用户对将要构建的软件自问的问题;(d)设计者对于软件产品和建造该产品采取的软件过程自问的问题。 

答:a)设计人员询问用户: 

产品满意吗或者它需要重新设计或返工吗, 

征求用户输入来避免产品不满意和要求返工。 

有新要求的需要吗, 

该产品比估计的大吗, 

与预期的相比模块需要更多的测试，设计和实行工作来纠正吗, 

b) 用户询问设计者的问题: 

范围明确吗, 

我们是否有开发工具和人员开发软件所需的技能, 

定义的需求是正确的吗,还有没有额外的需要, 

特定领域的软件产品比平时的花费更多的时间吗, 

该模块是否需要更多的设计测试, 

c)用户对将要构建的软件自问的问题: 

软件产品的范围和目的是什么?

该产品比估计的大吗, 

有优秀的人可用吗, 

工作人员可靠吗有没有具备所需要的技能, 

能保持工作人员的离职率足够低吗, 

d)设计者对于软件产品和建造该产品采取的软件过程自问的问题: 范围和目的文件是什么, 

要使用什么样的工具, 

有什么目标和规避风险的优先事项, 

对风险分析，识别，估计，评价和管理会有什么样的步骤, 

2.2为沟通活动设计一些列的动作，选定一个动作作为其设计一个任务集。 答:任务交流活动设置:任务组将定义实际的工作需要，以完成一个软件工程的行动。这些都是对于通信的活动: 

a)利益相关者对项目做一个列表。 

b)邀请所有利益相关者的非正式会议。 

c)要求他们作出特性和功能列表。 

d)讨论需求并建立一个最终的的列表。 

e)他不确定的优先级的要求和要注意的地方。 

这些任务可能是一个复杂的软件项目，然后，他们可能包括: 

a)要进行一系列的规范会议，基于利益相关者的输入，建立了初步的功能和特性列表。 

b)要建立一个股权持有人要求的修订清单。 

c)使用质量功能展开技术来满足需求。 

d)注意在系统上的约束和限制。 

e)讨论验证系统的方法。 

2.3在沟通过程中，遇到两位对软件如何做有着不同想法的利益相关者是很常见的问题。也就是说你得到了相互冲突的需求。设计一种过程模式(可以是步骤模式)，利用2.13节中针对此类问题的模板，给出一种行之有效的解决方法。 答: 

模式名:利益相关者的需求冲突。 

意图:此模式描述的方式是解决利益相关者之间在通信框架活动中的冲突。 类型:阶段模式。 

初始背景:(1)利益相关者已确定(2)利益相关者和软件工程师已经建立了协作通信(3) 软件要解决的主要问题由软件开发团队已建立。(4)对已开发的项目范围，基本的业务需求和项目的限制有了初步的了解。 

问题:对正在开发的软件，利益相关者的需求出现了相互的矛盾。 解决办法:所有的利益相关者被要求区分需求的优先级，暂时保住利益相关者的优先级最高或投票的最多的需求从而解决这一问题。 

结果:由利益相关方的确定的需求优先顺序列表来指导软件开发团队构件软件初始模型。 

相关模式:定义指导和协作方针，范围隔离，需求收集，约束描述和混合需求。 已知用途/范例:必要的沟通是贯通整个软件工程中。 

2.4阅读[Nog001]，然后写一篇2-3页的论文，讨论混乱对软件工程的影响。 答案略。 

2.5详细描述三个适用于采用瀑布模型的软件项目。 
答:适合瀑布模型的项目例如数据结构，软件架构，程序的细节和接口表征的对象。 

2.6详细描述三个适用于采用原型模型的软件项目。 
答:相对容易的原型模型几乎总是涉及人机交互和/或复杂计算机图形软件应用程序，有时适合原型模型是某些类别的数学算法，命令驱动系统和其他应用在没有实时交互时结果可以很容易地检查。难以用原型模型的应用程序，包括控制和过程控制功能许多种类的实时应用程序和嵌入式软件。 

2.7如果将原型变成一个可发布的系统或产品，应该如何调整过程。 
答:如果将原型变成一个可发布的系统或产品，软件工程师和客户需要满足和定义软件的总体目标，识别已知的任何要求，对整体轮廓进一步的强制定义。原型作为一种机制，用于识别软件需求。如果一个工作原型被建立了，开发商会试图利用现有的程序片段或应用工具(例如，报表生成器，窗口管理等)使工作方案，可以快速生成。 

2.8详细描述三个适于采用增量模型的软件项目。 
答: 每一个线性序列产生的“增量”交付的软件，例如字处理软件开发使用增量范式可能会提供基本的文件管理，编辑和文件制作功能在第一增量，更复杂的编辑和文件制作能力在第二增量;拼写和语法检查在第三增量，先进的页面布局能力在第四增量。任何增量的处理流程 可以纳入原型范式。增量发展是特别有用当人员无法在经营期限为一个已成立的项目做完美的实施。 

2.9当沿着螺旋过程流发展的时候，你对正在开发或者维护的软件的看法是什么, 
答:随着工作的螺旋向外移动，产品走向一个更完整的状态，执行工作的抽象层次减少了。 

2.10可以合用几种过程模型吗,如果可以，举例说明。 
答:过程模型可以合用，每个模型都有个有点不同的处理流程，但都执行相同的通用框架活动集:沟通，规划，建模，施工和交付/反馈。例如线性顺序模型可以作为一个有用的过程模型，在被固定的情况下，要求工作以线性的方式继续进行，直至完成。在这情况下，开发者可能无法确定一种算法的效率，一个操作系统的适应性或应采取的人机交互的形式。在这之中，以及许多其他场合原型模型可以提供最好的办法。在其他情况下，以渐进的方式可能是有意义的和螺旋模型的流动可能是有效率，特殊过程模型具有许多的一个或多个传统的特性。 

2.11协同过程模型定义了一套“状态”，用你自己的话描述一下这些状态表示什么，并指出他们在协同过程模型中的作用。 
答:简而言之，并发进程模型假定不同的部分项目会有所不同阶段的完整性，因此，不同的软件工程活动都被同时执行。目前的挑战是管理的并发，并能够评估该项目的状态。 

2.12开发质量“足够好”的软件，其优点和缺点是什么,也就是说，当我们追求开发速度胜过产品质量的时候，会产生什么后果, 
答:开发质量“足够好”的软件可能会碰到死亡线(截止时间)，但质量会是比较好的。当追求开发速度超过了产品的质量，这可能会导致许多缺陷，该软件可能需要更多的测试，设计和实施工作。需求定以的不是很清楚，可能需要不断地改变。半调子和速度过快开发都可能导致无法检测到重大的项目风险。质量太差可能导致过多的质量问题和频繁的返工。 

2.13详细描述三个适于采用基于构件模型的软件项目。 
答:我会建议推迟这个问题直到“软件过程改进”这一章。 

2.14我们可以证明一个软件构件甚至整个程序的正确性，可是为什么并不是每个人都这样做, 
答:这是可能的用数学技术来证明软件组件，甚至整个程序的正确性。然而，对于复杂的程序，这是一个非常耗时的过程。用详尽的测试是不可能证明任何不平凡的程序的正确性， 

2.15统一过程和UML是同一概念吗,解释你的答案。 
答:UML提供了必要的技术支持和面向对象的软件工程实践。但它并不提供流程框架来指导项目团队，在他们的技术应用中。在近几年中，雅各布森， Rumbaugh和Booch制定的统一过程中框架使用UML的面向对象的软件工程。今天，统一的流程和UML被广泛应用于各种面向对象的项目。 

第777777章 

4.1需求不断的改变，理解需求问题是软件工程师面临的最困难的工作之一，因此他们更少注意需求。在某些情况下，工程师们会化繁为简。其他情况下，工程师们必须严格地执行具体定义的需求。需求分析是设计和施工的桥梁,不能跳过。 

4.2你可以尝试使用方法比如QFD(质量功能部署)通过客户访谈和观察、调查以及检查历史数据(如问题报告)为需求收集活动获取原始数据。然后把这些数据翻译成需求表——称为客户意见表，并由客户和利益相关者评审。接下来使用各种图表、矩阵和评估方法抽取期望的需求并尽可能导出令人兴奋的需求。 

4.3事实上,客户和开发人员会有一个协商的过程，开发人员会要求客户权衡产品的性能与产品成本、上市时间之间的关系。这个协商的目的是开发一个项目计划，这个计划在满足客户需求的同时又能准确反映了软件开发过程中约束(如时间、人员、预算)。不幸的是,这样的项目计划很难达成,每个客户都有自己的观点。这些观点并不对其他客户都适用，此外时间是另一个重要的约束,客户可能没有时间与开发人员讨论需求，这使得问题更加复杂。 

4.4需求模型的目的在于描述所需的信息、功能和计算机系统的工作领域。随着软件工程师对系统了解的深入以及利益相关者越来越了解他们真正的需求，这种需求模型是不断变化的。因此，分析模型在任何时候都是用户需求的简介 

4.5最好的协商是争取“双赢”,这会使你成为是一位谈判大师。这些初期步骤的成功实施可以达到一个双赢的结果，这是继续开展后续的软件工程活动的关键。 

4.6第一组上下文无关问题集主要关注的是客户、总体目标和利益。例如，需求工程师可能会问: 

谁是这项工作的最初请求者, 

谁将使用该解决方案, 

成功的解决方案将带来什么样的经济收益, 

对于这个解决方案你还需要其他资源吗, 

4.7-4.9答案略。 

4.10用例图描述了参与者所能观察到模型图。用例图鼓励系统的功能视图应该转换为面向对象的视图。在许多情况下，为了提供更多的相互作用，用例图需要做更详细的阐述。 

4.11任何有一些软件项目需求工程经验的人都开始注意到，在特定的应用领域内某些事情在所有的项目中重复发生。这些分析模式在特定应用领域内提供了一些解决方案(如类、功能、行为)，在为许多应用项目建模时可以重复使用。 

4.13最好的协商是争取“双赢”的结果，即利益相关者的“赢”在于获得满足客户大多数需要的系统或产品，而作为软件团队一员的“赢”在于按照实际情况、在可实现的预算和时间期限内完成工作。 

4.14当需求确认解释了一个错误时，每个需求有一个问题清单。之后会有评审小组寻找它。确认需求的评审小组包括软件工程师、客户、用户、和其他利益相关者，他们在检查系统规格说明，查找内容或解释上的错误，以及可能需要进一步解释澄清的地方、丢失的信息、不一致性(这是建造大型产品或系统时遇到的主要问题)、冲突的需求或是不可实现的(不能达到的)需求。 

第五章 

5.1有没有可能在分析建模创建后立即开始编码,解释你的答案，然后说服反方。 答:分析模型作为领域对象的设计和结构的基础服务。在定义了对象和属性后，就可以开始进行编码，也就知道了对象之间的关系。 

5.2 一个单凭经验的分析原则是:模型“应该关注在问题域或业务域中可见的需求”。在这些域中哪些类型的需求是不可见的,提供一些例子。 

答:正如我们所知道的，在开始阶段很可能没有完整的需求规范。客户可能不是非常精确地确定他们的所有需求。开发者也没有把握使用一个具体的方法来正常的完成系统的功能和性能。为了需求分析和建模，不倾向使用迭代的方法。分析师所将认识到的东西进行建模，并使用此模型作为软件增量的设计的基础。软件增量作为流程迭代的一部分被制作出来。在这些领域中，需求的类型是不可见的，可能因为一些功能必须在系统中实现，系统展示的行为是什么，属性定义的接口有哪些，应用的约束有哪些, 

5.3 域分析的目的是什么,如何将域分析与需求模式概念相联系, 答:域分析是持续的软件工程活动，不与任何的软件项目相关联。它与需求模式的概念相联系。域分析是通过一系列活动进行表征的过程。这些活动从识别域开始，以描述域中对象和类的规范为结束。 

5.4 有没有可能不完成如图6-3所示的4种元素就开发出一个有效的分析模型,解释一下。 

答:如果没有图6.3所示的4大元素，是不可能开发出一个有效的分析模型。分析模型作为域对象的设计和建造的基础。 

5.5 构建如下系统中的一个: 

a你所在大学基于网络的课程注册系统。 

b一个计算机商店的基于Web的订单处理系统。 

c一个小企业的简单发票系统。 

d内置于电磁灶或微波炉的互联网食谱。 

选择你感兴趣的系统开发一套试题关系图并说明数据对象、关系和属性。 答:需要强调的是，所有的数据对象和关系一定客户可见的。为了确认属性正确地反映出系统的需求，属性应该被检查。(无固定答案) 

5.6-5.9答案略。 

5.10 什么是分析包,如何使用分析包, 

答:将分析模型的各种元素以包组的方式进行分类，成为分析包。为了说明分析包的作用，请思考一下视频游戏。作为视频游戏的分析模型，道出了大量的类。 

第六章 

6.1 对于需求分析，结构分析与面向对象策略有何本质区别, 

答:结构分析，考虑把数据作为分离实体的变形的数据和过程。数据目标是被使用它们已被定义的属性和关系建模的。过程操作数据目标是被使用它们在系统中的数据流向建模的。面向对象分析，集中于类的定义和它们合作对用户需求所带来的效果的方式。 

6.2 在数据流图中，一个箭头表示控制流还是其他, 

答:DFD数据目标是用有标签的箭头所表示的。 

6.3 什么是“信息流连续性”,当重新定义一个数据流时，如何应用它, 答:数据流动连续性意味着在同一等级中的输入和输出必须和它们的精确等级相同。 

6.4 在生成DFD图时，如何使用图形化解析, 

答:在第一次需求整合会议中，应用工程描述中分离所有名词和动词的第一步被导出。再文法解析中，动词时处理和可以被如DFD中的Bubbles描述的。名词是DFD中的外部实体(盒子)，数据或控制目标(箭头)，或数据存储(双实线)。 

6.5 什么是控制规格说明, 

答:控制规格(CSPEC)以两种不同的方式描述了系统的行为(在被提到的基准线上)，CSPEC包括一系列行为的规格的状态图。它也包括程序行为表——组合的行为规格。 

6.6 PSPEC和用例是同一事物吗,如果不是，请解释区别。 

答:不是。过程规格被用于去描述所有现在最终精炼等级的流程模型过程(算法观点)。一个有用的情况描述一系列行为包括演员和系统(更着重于用户可见行为而非算法)。 

6.7 表示行为建模时有两种不同“状态”类型，它们是什么, 

答:被动状态展现出目标属性的正确情况。主动状态指明了目标在转化或执行过程中的正确情况。 

6.8 如何从状态图区分顺序图,它们有何相似之处, 

答:状态图描述了系统的状态并且展现了事件如何影响系统状态。 

顺序图指明了事件如何引起目标的迁移。 

6.9——6.10答案略。 

第七章 

7.1是的，但是设计是隐式进行的——通常以随意的方式进行的。在设计过程中，我们研究程序的表现形式，而非程序本身。 

7.2软件设计的目的是运用一系列的原则、概念和实践导致高质量体系或产品的发展。设计的目标是创建一个可以正确地实现所有客户需求并有好的用户体验的软件模型。

7.3通过开展一系列的正式技术评审来评估质量。正式技术评审是由软件团队成员召开的会议。通常，根据将要评审的设计信息的范围，选择2人、3人或4人参与。每个人扮演一个角色:评判组长策划会议、拟定议程并主持会议;记录员记录笔记以保证没有遗漏;制作人是指其工作产品(例如某个软件构件的设计)被评审的人。在技术评审会议结束后，软件团队决定未来的行动以来完成最终的产品。

7.4为了开发一个完整的设计模型，软件团队反复地开发每个模块的元素。每次迭代提供额外的细节并且细化。此外，设计任务应用于一个项目可能不同于他们应用其他项目。团队必须适应一个通用的任务集去满足产品，人和项目的需

要。质量的评估在有被修改的错误的组件级的设计任务集。任务集在章节中给出。 

7.5略 

7.6软件体系结构是程序组件(模块)的结构或组织，这些组件相互作用的方式和数据结构被这些组件所使用。然而在更广泛的意义上讲，部件可以推广到代表主要的系统元件以及它们之间的交互。 

7.7略 

7.8分离关注点涉及通过将其分成单独解决的子问题解决一个复杂的问题，一个问题的不同部分是相互结合的方式，给与不同的考虑，而不是合并考虑更复杂的情况。高度耦合的问题表现出这一特征。然而，问题的部分继续组合，因为信息量超过了解一个人的能力不能无限期地进行下去，因此，当问题非真，模块化可以修改，但不能消除。 

7.9在某些时间关键应用程序下,可能需要单块集成软件。然而,如果软件是模块化实现，设计可以而且应该实现的。“模块”是内联编码。 

7.10信息隐藏与耦合和内聚概念有关，通过限制信息的可用性，只限于那些绝对需要的模块，模块之间的耦合在本质上是降低了。在一般情况下，信息隔离谓词有隔离功能，因此，各模块凝聚力也可以改善 

7.11外部环境、编译器和操作系统耦合将对软件可移植性造成不利影响。例如,考虑一个程序,这个程序被设计用来充分利用智能终端的特殊图形的特征。如果没有终端的软件被搬到一个系统,主要设计和代码可能需要修改。

7.12我们创建一个功能体系由此来提炼问题。例如，考虑到检查写入，我们可能这样写: 

Refinement 1:

Write dollar amount in words

Refinement 2:

Procedure write amount;

Validate amount is within bounds; Parse to determine each dollar unit; Generate alpha representation;

end write_amount

Refinement 3:

procedure write_amount;

do while checks remain to be printed if dollar amount > upper amount bound

then print "amount too large error

message;

else set process flag true;

End if;

determine maximum significant digit; do while (process flag true and

significant digits remain)

set for corresponded alpha phrase; divide to determine whole number value;

concatenate partial alpha string; reduce significant digit count by one; End do

print alpha string;

End do

end write_amount

细化1:

写出大写金额总数。

细化2:

写出大写金额数的程序:

验证金额数是否在允许范围内;

通过解析来确定美元单位;

,用α来表示金额数，写出来;

结束写出大写金额数程序

细化3:

写出大写金额数的程序:

检查是否还有未打印的支票，如有进入下面的循环

判断支票金额数是否大于上面指定的金额数

如果大于打印“金额数太大”的错误信息

否则确定过程标志符为1。

结束判断。

当过程标志符为1和有效数字存在的话，进入下面的循环:

确定最高有效位;

设置对应阿尔法短语;

划分来确定整数值;

连接部分α字符串;

7.13略 

7.14不，重构是一种不改变代码的外部行为和其功能而改善软件产品的内部质量的过程。他可能是提高了一个函数的处理速度或者在另一个系统中起到简化组件的作用。 

7.15四个要素的设计模型: 

设计模型的四个元素: 

数据/类设计——建立由分析转化的基于类内元素的类模型和按数据结构要求实现的软件。 

结构设计——定义大体软件元素结构件的关系。 

接口设计——描述软件元素,硬件元素和用户终端通信。 

组件等级设计——建立由软件组件的程序描述中的软件结构所定义的元素结构变形。 

第八章 

8.1用一个房屋或建筑结构作比喻，与软件体系结构作对照分析。经典建筑与软件体系结构的原则有什么相似之处,又有何区别, 

答:建筑与软件在风格与模式的概念存在于宏观与微观层面。例如所有的方子都有总体风格(墙、顶、地基)。这些代表了房子的宏观风格。微观上的模式(房子)可以在木材的类别、壁炉的设计以及窗户上体现出来。软件体系结构也一样，不同部件通过不同方法的组装，形成了不同的系统。不同点:一个比较实际，另外一个比较抽象;房屋或建筑物可变化的空间比较小，软件体系结构变化跨度更大一点 

8.2举出2到3个例子，说明8.3.1节中提到的每一种体系结构风格的应用。 答:数据中心体系结构:航空订票系统;图书馆目录系统;宾馆订阅系统。 数据流结构:任何工程或科学中主要功能是计算的应用程序。 

调用和返回结构:任何I-P-O申请。 

面对对象的体系结构:基于GUI的应用程序;任何面向对象的应用程序 。 分层体系结构:应用功能必须从底层操作系统或网络详细信息分离的应用程序。客户端服务器软件通常是分层的。 

8.3 8.3.1节中提到的一些体系结构风格具有层次性，而另一些则没有。列出每种类型。没有层次的体系风格如何实现, 

答:

层次:数据流，调用返回层。 

非层次:数据中心，面向对象。 

非分层体系结构可能是应用面对对象和驱动编程技术的最好实现。 

8.4 在软件体系结构讨论中，经常会遇到体系结构风格、体系结构模式及框架(本书中没有讨论)等术语。研究并描述这些术语之间的不同。 

答:许多人把建筑模式和建筑风格等价定义(把通用系统模型作为程序设计的起始点)，尽管模式往往不太广泛。一个框架可能会被一些人定义为一组提供了一个通用的解决问题方案的类，被解决的问题可以被细化到创建一个应用程序。 

8.5 选择一个你熟悉的应用，回答8.3.3节中对于控制与数据提出的每一个问题。 答:答案不固定。 

8.6 研究ATAM([Kaz98])并对8.5.1节提出的6个步骤进行详细讨论。 答:答案不固定。 

8.7 如果还没有完成习题5.6，请先完成它。使用本章描述的设计方法开发PHTRS的软件体系结构。 

答:答案不固定。 

8.8 使用数据流图和过程说明，描述一个有清楚变换流特征的计算机系统。定义流边界并使用8.6.1节描述的技术将DFD映射到软件体系结构中 

答:答案不固定。 

第九章 

9.1构件级设计定义了数据结构、算法，界面特性以及分配给每个软件构件的通信机制。在面向对象语言中(JAVA或Smalltalk)构件为类或对象。在传统语言(C或Fortran)中构件式函数或操作过程。在混合语言中(如C++)构件可能是函数或类。 

9.2像面向对象的构件一样，传统软件构件是由分析模型所导出的。然而在这种情况下，导出构件是以分析模型中面向数据流元素作为基础。数据流图的最低层的每个变换都被映射为某一层上的模块。控制构件(模块)位于层次结构(体系结构)顶层附近，而问题域构件则倾向位于层次结构的底层。为了获得有效的模块化，在构建细化的过程中采用了功能独立性的设计概念。 

9.3OCP原则模块(构件)应该对外延具有开放性，对修改具有封闭性。设计者应该采用一种无需对结构自身内部(代码或内部逻辑)做修改就可以进行的扩展(在构建所确定的功能域内)的方式来说明构件。设计者进行抽象，在那些需要扩展的功能与设计类本身之间起到缓冲区作用。 

9.4依赖性倒置原则(DIP)，依赖于抽象。不依赖于具体实现。构件依赖的其他具体构件(不是依赖抽象类，如接口)越多，扩展起来越困难。 

9.5构件级设计中面向对象系统的上下文中，内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或者类自身有密切关系的属性和操作。高内聚的构件会与其他构件提供的服务“绝缘”，从而使其实施与维护更加容易。

9.6耦合是类之间彼此联系程度的一种定性度量。随着类(构件)相互依赖越来越多，类之间的耦合程度亦会增加。低耦合的好处是构件可以被修改但不会影响其他构件。

9.7外部耦合发生在组件通信或与基础设施组件(如。、操作系统功能、数据库功能、通信功能)。虽然这种类型的耦合是必要的,它应该是局限于一小部分系统组件或类。软件必须在内部和外部沟通。因此,耦合是一个不争的事实。然而,设计师应尽可能减少耦合和理解高耦合的影响不可避免。 

9.8略 

9.9 重构是系统决策集散控制的过程，目的是让顶层模块执行控制功能，而底层模块处理所有输入，执行和输出工作。逐步求精是通过连续精化过程细节层次来实现程序的开发。在传统软件开发中两者是很相似的。 

9.10

WebAPP构件定义为以下两点之一: 

定义良好的聚合功能，为最终用户处理内容，或提供计算或数据处理 内容和功能的聚合包，提供最终用户所需的功能。 

9.11略 

9.12略 

9.13略 

9.14 人可以短暂记忆一小部分东西，分块可以使评审者将相关概念组合成大的碎片或更大的分块。那些具有分块功能的构件(如果构件具有高内聚低耦合特性)可以使评审者在设计审查时更简单的追踪几个构件的相互作用而不是大量的单各类或方法。 

第十章 

10.1这道题应该不难～许多早期交互式系统都有糟糕的界面。在现代环境下，让你的学生们注重基于web的应用程序界面。许多web应用程序为了Flash牺牲易用性。 

10.2例子如下: 

在它们引起“可撤销的”损害之前抓住潜在的交互错误。 

允许用户自定义屏幕布局以及命令。 

利用分离菜单，以便通用功能。 

10.3例子如下: 

如果用户有需求，在屏幕上一直显示快捷键命令序列。 

当一个web应用程序需要密码输入的时候，提供“密码提示”机制。 

10.4例子如下: 

使用一致的颜色，例如，红色用作警示信息，蓝色用作通知信息; 提供关键字驱动的在线帮助。 

10.5答案略。 

10.6如果你的学生在任务分析上出了问题，老的备用I-P-O将会有效。 问:使用者输入什么,它是怎么处理的,处理过程是如何通过界面表现出来的,产生的输出是什么, 

10.7-10.11答案略。 

10.12当响应时间无法预测的时候，使用者会很不耐烦并且重复尝试请求的命令或者尝试另一个命令。在某些情况下，这会产生(命令的)排队问题，并且在极端的情况下，会引起数据的丢失或者甚至是一个系统故障。研究表明，用户可以容忍他们熟悉的应用程序的响应率50%的变化。对于那些不熟悉的应用程序，使用者在15到30秒意外的延迟(也就是他们短期记忆的半衰期)后会很焦虑。 

10.13答案略。 

10.14如果你想要给你的学生一些工作项目表的范例，互联网是一个很好的可用性调查表的来源(大部分都应该有超过20道的问题，所以你的学生应该需要优先考虑他们的选择) 

第十四章 

14.1用自己的话描述验证与确认的区别。两者都要用测试用例的设计方法和测试策略吗, 

答:“验证”是通过尝试在功能或性能上发现错误来保证程序的正确性，“确认”是保证软件与需求相一致——这也是质量的基本特征。 

14.2列出一些可能与独立测试组(ITG)的创建相关的问题。IGT与SQA小组由相同的人员组成吗, 

答:组建ITG(独立测试组)最常见的问题是获得并留住人才，除此之外，如果ITG与软件工程小组的交流组织地不恰当的话，两组之间可能会产生敌意。最后，ITG有可能太晚接手项目，导致没有时间完成一个周密测试的计划和执行。ITG和SQA(软件质量保证)小组不必是同一组人。ITG只关注测试，SQA小组则需要考虑到质量保证相关的所有方面。 

14.3使用14.1.3节中描述的测试步骤来建立测试软件的策略总是可行的嘛,对于嵌入式系统，出现哪些可能的复杂情况, 

答:它并不总是能够进行单元测试的测试环境，完成单元测试的复杂性(如复杂的驱动和存根)可能无法证明效益。集成测试是复杂的通过单元测试的模块合并计划的有效性(特别是当这些模块滞后的时候)。在很多情况下(尤其是嵌入式系统)软件不能充分进行验证测试硬件配置外的目标。因此，验证和系统测试要相结合。 

14.4为什么对具有较高耦合度的模块进行单元测试, 

答:一个高度耦合的模块要与其他模块的数据和其他系统元素进行交互。因此，其功能往往是依赖于这些耦合元件的操作。为了彻底的单元测试这样一个模块，耦合因素的功能必须以某种方式模拟。这将会是困难和费时的。 

14.5“防错法”的概念是一个非常有效的方法。当发现错误时，他提供了内置调试帮助: 

a.为防错发开发一组知道原则。 

b.讨论利用这种技术的优点。 

c.讨论利用这种技术的缺点。 

答:一个单一的规则涵盖了多种情况:所有数据在软件接口(外部和内部)应当经过验证(如果可能的话)。 

优点:错误不会―滚雪球‖——越滚越大 

缺点:需要额外的处理时间和内存(那通常只是一个很小的代价)。 

14.6项目的进度安排是如何影响集成测试的, 

答:完成模块的可用性的影响顺序和战略整合。项目状态必须是已知的，可以成功地实现整合规划。 

14.7在所有的情况下，单元测试都是可能的或是值得做的吗,提供实例来说明你的理由。 

答:如果一个模块有3或4个下属供应数据模块的一个有意义的评价是至关重要的，没有―聚类‖所有的模块作为一个单元，它可能无法进行单元测试。 

14.8谁应该完成确认测试——是软件开发人员还是软件的使用者，说明你的理由。 

答:开发商，如果客户验收测试计划。开发人员和客户(用户)如果没有进一步的测试计划。一个独立的测试组可能是这里最好的选择，但这不是一个选择。 

14.9为本书讨论的safehouse系统开发一个完整的测试策略，并以测试规格说明的方式形成文档。 

答:略 

14.10作为一个班级项目，为你的安装开发调试指南。这个指南应该提供面向语言和面向系统的建议。这些建议是通过总结学校学习过程中所遇到的挫折得到的。从一个经过全班和老师评审过的大纲开始，并在你局部范围内将这个指南发布给其他人。 

答:略 

第十五章 

15.1 Myers[mye79]用以下程序作为测试能力的自我评估:某程序读入三个整数值表示三角形的三条边。改程序打印信息表明三角形是不规则的，等腰的或等边的。开发一组测试用例测试改程序。 

答:参考Myers[mye79]对此问题提出的极其详细的―解决方案‖。 

15.2设计并实现15.1描述的程序(适当使用错误处理)。从该程序中导出流图并用基本路径测试方法设计测试，以保证程序中的所有语句都被测试到。执行测试用例并显示结果。 

答:你可以选择发布程序源代码给您的学生(故意地嵌入一些错误)。 

15.3你能够想出15.1.1节中没有讨论的其他测试目标吗, 

答:除了那些目标之外还有: 

a) 一个成功的测试显示功能和性能要求; 

b) 一个成功的测试发现文件错误; 

c) 一个成功的测试发现接口问题; 

d) 一个成功的测试验证了程序结构，了解数据结构，界面设计和程序设计; e) 一个成功的测试，建立了一个进入一个测试案例数据库，以后可以用于回归测试。 

15.4选择一个你最近设计和实现的构建。设计一组测试用例，保证利用基本路径测试执行所有语句。 

答:略 

15.5-15.8

答:进行一些拓展，这些问题可以被指定为一个长期的项目。 

15.9至少给出三个例子，在这些例子中，黑盒测试能给人“一切正常”的印象，而白盒测试可能发现错误。再至少给出三个例子，在这些例子中白盒测试能给人“一切正常”的印象，而黑盒测试可能发现错误。 

答:对于特定的输入，一个内部发生的错误导致: 

1) 不恰当的数据被设在一个全局数据域里; 

2) 不恰当的标记将在随后进行的一系列测试中被测试; 

3) 不恰当硬件控制，只可能在系统测试时被发现;但是却产生了正确的输出。 

15.10不，即使穷举测试(如果可能的话)也不能发现软件说明书中的性能问题和错误。在这种情况下需要同时考虑输入和输出的等价类。对每一个类来说，学生应当根据数值范围，集合的元素，系统命令等划定边界。这可以作为笔试以及一些著名应用GUI的测试用例的素材 

15.11生成一系列用例来帮助测试用户的文件材料是一个好办法。 

第十六章 

16.1用自己的话，描述为什么在面向对象系统中，类是最小的合理测试单元。 答:类封装了数据以及处理数据的操作。由于数据和操作被打包成一个整体，一个一个地测试方法没有作用，不能发现与消息传送，职责和协作相关的错误。 

16.2若现有类已进行了彻底的测试，为什么我们必须对从现有类 实例化的子类进行重新测试,我们可以使用为现有类设计的测试用例么, 

答:由于每一个子类都继承了父类的私有属性和操作(事实上这些私有属性和操作会增加复杂度)，这些子类必须在他们的操作环境中重新测试。测试用例可以重复使用，但需要针对子类的私有属性和操作进行扩充。 

16.3为什么―测试‖应该从面向对象分析和设计开始, 

答:在之后的开发过程中，面向对象分析和设计模型提供了大量与系统结构和行为相关的信息，因此，在生成代码之前，这些模型必须经过严格的审查。所有面向对象的模型应当在模型的语法，语义以及语用论的上下中经过正确性，

完整性，一致性的测试(包括技术评审)。这些评审有可能省去很多不必要的工作和修改(错误越早发现，维护的成本越低)。 

16.4为SafeHome导出一组CRC索引卡片，按照16.2.2节讲述的步骤确定是否存在不一致性。 

答:答案会有不同 

16.5基于线程和基于使用的集成测试策略有什么不同,簇测试如何适应, 答:基于线程的测试用来集成一系列需要对单独一个程序输入或事件响应的类。基于使用的测试属于集成测试的一种，通过测试那些很少使用服务器类的类(称为独立类)开始系统的构造。测试完独立类之后，测试使用独立类的下一层类(称为依赖类)，按照这样的顺序逐层测试依赖类直到整个系统构造完成。 

16.6将随机测试和划分方法运用到设计SafeHome系统时定义的3个类。产生展示操作调用序列的测试用例。 

答:答案会有不同 

16.7运用多类测试及从SafeHome设计的行为模型中生成的测试。 

答:答案会有不同 

16.8运用随机测试、划分方法、多类测试及16.5节和16.6节所描述的银行应用的行为模型导出的测试，再生成另外生成4个测试。 

答:答案会有不同 

第十八章 

18.1基于本章给出的信息和自己的经验，列举出能够增强软件工程师能力的“十条戒律”。即，列出10条指导原则，使得软件人员能够在工作中发挥其全部潜力。 

答: 

(1)你要变得更聪明。 

(2)你要注重质量。 

(3)你要倾听客户。 

(4)你要了解问题 

(5)你要对一个工作过程不断的重复。 

(6)你不可同意荒唐的时间表。 

(7)你要测量产品，过程和你自己。 

(8)你要制定最有效的工作方法。 

(9)你要记住，别人也会软件工作。 

(10)你要不断地提高。 

18.2 SEI的人员能力成熟度模型定义了培养优秀软件人员的“关键实践域”。你的老师将为你指派一个关键实践域，请你对它进行分析和总结。 

答:略。 

18.3描述3种现实生活中的实际情况，其中客户和最终用户是相同的人。也描述3种他们是不同人的情况。 

答:相同的人:(1)一个工程师必须开发一个供个人使用的程序。(2)一个商人创建供个人使用的电子表格模型。(3)一个拥有迷人的手机客户端这一新概念的企业家。 

不同的人:(1)一个通信部门的一些业务功能的服务。(2)一个软件开发团队服务营销的需求。(3)承包商建立的客户的规格。 

18.4高级管理者所做的决策会对软件工程团队的效率产生重大影响。也描述3种他们是不同人的情况。 

答:在今天的环境，裁员和外包有最直接的、重大的影响。此外，“减少开支的措施”，导致较低的产品质量;不切实际的项目最后期限;对用户的需求了解失败;或者，反过来说，对软件工程师的工作提出警告。 

18.5温习Weiberg的书[Wei86]，并写出一份2-3页的总结，说明在使用MOI模型时应该考虑的问题。 

答案:略。 

18.6在一个信息系统组织中，你被指派为项目经理。你的工作是开发一个应用程序，该程序类似于你的团队已经做过的项目，只是规模更大而且更复杂。需求已经由用户改写成文档。你会选择哪种团队结构,为什么,你会选择哪(些)种软件过程模型,为什么, 

答:一个封闭范型方法的团队结构是一种选择。由于需求明确，这可能会要求和配置多个分区小组。规模大的项目缓和了利于CD团队的方面。由于没有讨论日程，我们假设的交货日期是合理的。因此，有可能使用一个线性的顺序过程模型。然而，迭代模型(例如，螺旋)也是一个很好的可能性。 

18.7你被指派为一个小型软件产品公司的项目经理。你的工作是开发一个有突破性的产品，该产品结合了虚拟现实的硬件和高超的软件。因为家庭娱乐市场的竞争非常激烈，完成这项工作的压力很大。你会选择哪种团队结构,为什么,你会选择哪种过程模型,为什么, 

答:随机式范型的团队结构可能是唯一可行的选择，给出了模糊的要求和工作性质的实验。应该使用原型开发方法或者一个曾量的过程模型。 

18.8你被指派为一个大型软件产品公司的项目经理。你的工作是管理该公司已被广泛使用的字处理软件的新版本的开发。由于竞争激烈，已经规定了紧迫的最后期限，并对外公布。你会选择哪种团队结构,为什么,你会选择哪些软件过程模型,为什么, 

答:一个开放式范型团队结构可能是最好的，给定的时间压力和熟悉的工作(然而，封闭的方法范式团队可能也很好)。一个曾量过程模型被推动这项工作性质的最后期限所指明。 

18.9在一个为基因工程领域服务的公司中，你被指派为软件项目经理。你的工作是管理一个软件新产品的开发，该产品能够加速基因分类的速度。这项工作是面向研究及开发的，但其目标是在下一年度内生产出产品。你会选择哪种团队结构,为什么,你会选择哪些软件过程模型,为什么, 

答:一个随机式范型可能是最好的，是因为这项工作是实验性的，且有一个企业的最后期限。另一种可能性是使用一个开放式范型的团队结构。一个曾量过程模型和进化过程模型可以用于推动给予限期的这项工作。 

18.10要求开发一个小型应用软件，它的作用是分析一所大学开设的每一门课程，并输出课程的平均成绩(针对某个学期)。写出该问题的范围陈述。 答: 

分数分析应用程序将获得所有本科和研究生的学分课程的成绩和在某一学期课程注册数据库。分数分析应用程序会读每一门课程的所有等级和计算平均成绩，使用的数值范围在A = 4和其他等级分配值来作为等级值存到uc29-1文档。本程序会打印一个报告显示每门课的教师和平均成绩。这个报告可能会按平均成绩或者教师等其他类似的特征排序。本程序可能会运行在WindowsVista操作系统下。 

18.11给出18.3.2节中讨论的页面布局功能的第一级功能分解。 

答: 

一个简单的分解: 

页面布局 

定义页面参数 

分配文本区域 

分配图形区域 

强调定义(线，着色等) 

输入/导入文本 

输入/导入 

编辑文本 

编辑图形 

出页/导出页面 

最终页面布局 

第十九章 

19.1用自己的话描述过程度量和项目度量之间的区别。 
答:过程度量是用来对设计和建造计算机软件的活动进行评估(为了在后续项目提高这些活动)。 
项目度量是用来评估软件项目的状态。 

19.2为什么有些软件度量是“私有的”,给出3个私有度量的例子，并给出3个公有度量的例子。 
答:当待评估的特征无法被直接测量时一种间接的的测量方法将被使用，例如,“质量”不能被直接测量所以只能测量软件其他的特征，软件的很多度量工作都间接的，因为软件不是一个有形的可以用直接测量的实体。例子 
能直接度量的物体 
纸的数量 
人的数量 
不同文件的数量 
不能直接度量的物体 
可读性(利用模糊指数) 
完整性(计算你收到的‖服务台‖问题的数量) 
可维护性 (定时改变文档)

19.3什么是间接测量,为什么在软件度量工作中经常用到这类测量, 
答:没找到答案。 

19.4Grady提出了一组软件度量规则，你能在19.1.1节所列的规则中在增加3个规则吗, 
答:软件度量的额外规则: 
不找完美的指标……它不存在。 
保证测量的一致性，避免比较不同的事物。 
注重质量，这是最重要的。 

19.5产品交付之前，团队A在软件工程过程中发现了342个错误，团队B发现了184个错误。对于项目A和B，还需要做什么额外的测量，才能确定哪个团队能够更有效地排除错误,你建议采用什么度量能有助于做出判定,那些历史数据可能有用, 
答:两个团队应该事先决定好要开发的软件的大小和功能，例如，errors/FP可以提供一个规范化的评估方法。此外，在两个团队的软件开发过程中一个度量标准例如DRE可以提供一个对SQA的效率指标。 

19.6给出反对将代码行作为软件生产率度量的论据。当考虑几十个或几百个项目时，你说的情况还成立吗, 
答:LOC的作用不大是因为它的奖励―verbose‖计划，同时他也很难用在可视化编程中，4GLs，代码生成器，或其他的代码生成器4gts的发展正在远离3gls

19.7根据下面的信息域特性，计算项目的功能点值: 
用户人数:32
用户输出数:60
用户查询数:24
文件数:8
外部接口数:2
假定所有的复杂度校正值都取“中等”值。使用第十三章描述的算法。 
答: 
总计:32*4+60*5+24*4+8*10+2*7=618 FP=618*[0.65+0.01*3*14]=661

19.8利用19.2.3节中给出的表格，基于每行代码具有的功能性，提出一个反对使用汇编语言的论据。再参考该表，讨论为什么C++比C更好, 
答:用汇编语言实现一个功能点需要的行数在91到694之间平均337行，这几项在表中都是最大的，一些行业分析师称:每天无论使用任何语言的程序员都交出相同数量的调试代码，如果开发一个项目真用了汇编语言那将比用其它语言花费更多的时间，以上比较方法可以用到C与C++得比较。 

19.9用于控制影印机的软件需要32000行C语言代码和4200行Smalltalk语言代码。估算该影印机软件的功能点数。 
答: 
用C语言 = 162 LOC/FP
用Smalltalk = 26 LOC/FP
所以 32,000/162 + 4,200/26 = 197.53 + 161.54 = 359 FP (近似值)

19.10在一个项目结束时，确定在建模活动中发现了30个错误，在构造活动中发现了12个可以追溯到建模活动中没有发现的错误。那么，建模活动的DRE是多少, 
答:DRE = E / (E + D) = 30 / (30 + 12) = 30 / 42 = 0.71.(近似值)

19.11软件团队将软件增量交付给最终用户。在第一个月的使用中，用户发现了8个缺陷。在交付之前，软件团队在正式技术评审和所有测试任务中发现了242个错误。那么在使用一个月之后，项目总的缺陷排除效率(DRE)是多少, 
答:DRE = E / (E + D) = 242 / (242 + 8) = 242 / 250 = 0.97(近似值)