软件工程课后习题答案

软件工程课后习题答案
第一章
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被广泛应用于各种面向对象的项目。

第四章
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通过开展一系列的正式技术评审来评估质量。

正式技术评审是由软件团队成员召开的会议。

通常，根据将要评审的设计信息的范围，。