软件工程课后习题答案

《软件工程课后习题答案》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

第一章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.6PSPEC和用例是同一事物吗？如果不是，请解释区别。答：不是。过程规格被用于去描述所有现在最终精炼等级的流程模型过程（算法观点）。一个有用的情况描述一系列行为包括演员和系统（更着重于用户可见行为而非算法）。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我们创建一个功能体系由此来提炼问题。例如，考虑到检查写入，我们可能这样写：Refinement1:WritedollaramountinwordsRefinement2: Procedurewriteamount;Validateamountiswithinbounds;Parsetodetermineeachdollarunit;Generatealpharepresentation;endwrite_amountRefinement3:procedurewrite_amount;dowhilechecksremaintobeprintedifdollaramount>upperamountboundthenprint"amounttoolargeerrormessage;elsesetprocessflagtrue;Endif;determinemaximumsignificantdigit;dowhile(processflagtrueandsignificantdigitsremain)setforcorrespondedalphaphrase;dividetodeterminewholenumbervalue;concatenatepartialalphastring;reducesignificantdigitcountbyone;Enddoprintalphastring;Enddo endwrite_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.38.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.10WebAPP构件定义为以下两点之一：定义良好的聚合功能，为最终用户处理内容，或提供计算或数据处理内容和功能的聚合包，提供最终用户所需的功能。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.1Myers[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.2SEI的人员能力成熟度模型定义了培养优秀软件人员的“关键实践域”。你的老师将为你指派一个关键实践域，请你对它进行分析和总结。答：略。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的发展正在远离3gls19.7根据下面的信息域特性，计算项目的功能点值：用户人数：32用户输出数：60用户查询数：24文件数：8外部接口数：2假定所有的复杂度校正值都取“中等”值。使用第十三章描述的算法。答：总计：32*4+60*5+24*4+8*10+2*7=618FP=618*[0.65+0.01*3*14]=66119.8利用19.2.3节中给出的表格，基于每行代码具有的功能性，提出一个反对使用汇编语言的论据。再参考该表，讨论为什么C++比C更好？答：用汇编语言实现一个功能点需要的行数在91到694之间平均337行，这几项在表中都是最大的，一些行业分析师称：每天无论使用任何语言的程序员都交出相同数量的调试代码，如果开发一个项目真用了汇编语言那将比用其它语言花费更多的时间，以上比较方法可以用到C与C++得比较。19.9用于控制影印机的软件需要32000行C语言代码和4200行Smalltalk语言代码。估算该影印机软件的功能点数。答：用C语言=162LOC/FP用Smalltalk=26LOC/FP所以32,000/162+4,200/26=197.53+161.54=359FP(近似值)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(近似值) 第二十章20.1假设你是一家开发家用机器人软件公司的项目经理，你已经承接了为草坪割草机器人开发软件的项目。写一个范围陈述来描述该软件，确定你的范围陈述是“界定的”。如果你对机器人不熟悉，在你开始写作之前先做一些调研工作。还要说明你对所需硬件的设想。或者，你也可以选择其他感兴趣的问题，而不做草坪割草机器人。答：略20.2在20.1节简要讨论了软件项目的复杂性。列出影响项目复杂性的软件特性（例如，并发操作、图形输出），按其对项目的影响程度顺次排列。答：有时，复杂性来源于客户和软件开发人员之间建立的一个糟糕的接口，以此，以下性能应该被考虑实时属性；多处理要求(并发)；算法的本质；递归的需求；输入的本质；确定性的输入；输出的本质；语言特点；知识/经验人员的使用。20.3在计划过程中，性能是一个重要的考虑因素。针对不同的软件应用领域，分别讨论如何以不同的方式来解释性能。答：实时操作--处理原始数据的CPU时间和可能产生中断服务的效率工程/科学的应用--数值精度和大型系统,CPU时间。商业的应用--I/O效率交互式的应用--用户“等待时间”微处理器的应用--cpu时间和内存需要。20.4对你在习题20.1中描述的机器人软件进行功能分解。估算每个功能的规模（用LOC）。假定你所在组织的平均生产率是450LOC/pm，劳动力价格是每人月7000美元，使用本章所讲的基于LOC的估算技术来估算构造该软件所需的工作量及成本。答：用户交互(2400)传感器监测(1100)信息显示(850)系统配置(1200)系统控制(激活/失活)(900)括号中指出了对每一项的LOC估计，通过估计一共是6450LOC把数据用与这个问题6450LOC/450LOC/pm=14.3pm花费:14.3pm*$7,000/pm=$100,000(估计值)20.5使用COCOMOⅡ 模型来估算构造一个简单的ATM软件所需的工作量，它产生12个屏幕、10个报表、将需要大约80个软件构件。假定该软件具有平均复杂度和平均开发者/环境成熟度。要求使用基于对象点的应用组装模型。答：objectpoint=12*2+10*5+80*10=874我们假设80%reuseNOP=(objectpoints)*[(100-%reuse)/100]=(874)*[(100–80)/100]=874*0.2=174.8参考p362的图可知：PROD=13工作量=NOP/PROD=174.8/13=13.4520.6使用“软件方程”来估算草坪割草机器人软件。假设采用方程（20-4），p=8000。答：假设B=0.16andP=8,000t.min=8.14*(LOC/P)0.43==8.14*(6450/8000)0.43t=t.min/12months/yearE=180*B*t320.7比较习题20.4和习题20.6中所得到的工作量估算值，求出标准偏差，它如何影响你对估算的确信程度？答案和题目不一样。20.8使用习题20.7中得到的结果，确定能否期望该软件在6个月内完成，以及完成该工作需要多少人员？答：软件方程预测“不”但我们可能超出其边界，使用原始的COCOMO模型。D=2.5E^0.35=2.5*16.92^0.35=6.7人月看来，6月是积极的，但有可能给出（相当于3人工作项目）COCOMO的结果和项目的规模/复杂性。20.9建立一个电子表格模型，实现本章所述的一种或多种估算技术。或者从基于Web的资源获取一个或多在线估算模型。答：略。20.10组建一个项目团队，开发软件工具来实现本章所介绍的每种估算技术。答：略。20.11有一点似乎很奇怪：成本和进度估算是在软件项目计划期间完成的——在详细的软件需求分析或设计之前进行。你认为为什么会这样？是否存在不需要这样做的情况？答：很早对成本和进度的估计是因为管理层希望尽可能早的得到这些数据，如果这个项目有 非常复杂的高级技术风险，所以一个固定价格的提议提交需要，项目的成本核算应该(如果可能)被推迟到需求分析之后，注意:只有需求的成本是可以尽早估计。