软件工程课后习题答案中文翻译版第八版Word文档格式.docx
《软件工程课后习题答案中文翻译版第八版Word文档格式.docx》由会员分享，可在线阅读，更多相关《软件工程课后习题答案中文翻译版第八版Word文档格式.docx（28页珍藏版）》请在冰点文库上搜索。
1.应使用有管理和理解了的开发过程进行开发。
2.可依赖性和性能对所有类型的系统来说都很重要。
3.理解和管理系统描述和需求是很重要，你必须知道不同的客户和用户的期望是什么。
4.赢尽可能搞笑地使用档期存在资源。
软件工程也是从无数实践中提炼出来的一门科学，沟通、需求分析、设计建模、编程、测试和支持都是软件工程方法所依赖于一组的本原则。
这些思想和原则涵盖了软件工程所有技术，是软件开发不可缺少的一部分。
所以软件工程的基本思想适用于所有的软件系统。
7.解释Web的普遍使用是怎么改变软件系统的。
（1）软件复用已经成为构建基于Web的系统的主要技术。
当你在够着这样的系统是就需要考虑在学校恩怨从已有的软件组件和系统开始工作。
（2）基于Web的系统的开发和交付应逐步完成，提前制定这些系统的所以需求是不切实际的。
（3）用户界面搜到浏览器能力和实用性约束，基于Web的系统上的应用界面通常比专门为Pc系列产品专门设计的用户界面要差。
（通俗点讲就是：
实用是实用，就是有点丑。
）
8.职业人员是否应该和医生或律师一样要颁发资格证书？
讨论一下。
我认为：
可以给职业人员颁发某种软件技术方面的资格证书以便公司能够快速确认从业人员具备的技能和让社会大众对从业人员的技术资质有更简单直观的了解。
当然，这个证书不能成为他职业道德的证书，软件工程从业人员的职业道德和行为准则因由此方面协会和机构引导，从业人员自己严加自律。
9．对吐1-3的ACM/IEEE职业道德准则中的每一条款，举出一个恰当的例子加以说明。
（1）公众感：
软件工程从业人员应该始终与公众利益保持一致。
不应该通过软件给某些利益集团谋取私利从而损害广大人民群众的利益。
（2）客户和雇主:
不能只站在雇主这边为雇主最求利益最大化而不顾客户利益。
（3）产品：
不能做一个没有完成或某方面如安全性、稳定性未达标的产品给客户。
（4）判断力：
软件从业人员应具备达到判断力，知道自己做的产品不是刻意用来危害社会的。
（5）管理：
合理管理软件开发方法，不能官僚主义全听领导一句话。
（6）职业感：
大家都是从事正当行业的，要多想想怎么为社会谋取福利。
（7）同事：
黑社会都说以和为贵，团队成员都是奔着一个目标去的不要由于一些小小分歧就那个啥...周恩来说要求同存异。
（8）自己：
注意要有健康积极的职业和生活方式。
什么是四个重要的属性，所有的软件产品应该有？
建议四其他属性，有时可能是重要的。
可维护性,可靠性,有效性,可用性.Other可复用性,可分发性,可移植性,互用性
给你的答案基于系统正在开发的类型的原因，建议最适当的通用的软件过程模型，可以用来管理跟踪系统发展的基础：
1）防抱死制动系统2）的虚拟现实系统3）高校会计制度4）互动的时间表
（一）防抱死制动系统：
安全关键安全鉴定系统方法的基础上，正式的转换等价每段之间的等价证明。
（b）的虚拟现实系统：
系统的要求，事先无法预测预先地预知所以探索性编程模型是合适的。
（C）大学会计系统：
系统的要求应稳定是因为现有的系统因此瀑布模型是合适的。
（d）互动的时间表交互式时间表：
系统复杂的用户界面，但它必须是稳定的，可靠的。
应根据丢弃原型找到要求然后增量开发或瀑布模型。
为什么一个软件系统，用一个真实的世界环境必须改变或成为progressivelyless有用吗？
这种适应自然生成新的系统需求
系统的环境是动态的，不断产生新的要求，作为对业务变化的后果，业务目标和业务政策。
商务的目标以及政治相关除非系统适于反映这些要求，其设施将成为了所需要的设施支持业务和步骤，因此，它将变得不那么有用。
为什么一个好的程序员不一定是一个好的软件管理者？
管理活动包括提出书面建议，项目规划和进度，人员选择和评价，项目监督和评审，和其他队友的交流能力等。
程序设计者的任务就不是这些，他们不需要和人交流的能力，如果按照做好一个程序设计者的要求去做管理者的话，他肯定不是一个号的管理者。
为什么项目策划的过程是迭代的，为什么一个计划必须不断审查软件项目中。
软件项目地规划取决于有用地信息。
在项目进行期间不断产生新的信息，所以必须经常性的修改原有的计划。
原本有用的信息可能会不再有用，而原本一些不确定的信息反而会变得有用。
最初对象目本身的估算是实验性的，所以计划需要不断的修改。
表明他们可能会在一所大学的学生记录系统中的利益相关者。
在一个学生记录系统的利益相关者包括：
大学管理中心，包括报到，交纳学费，考试，作业和毕业等记录在这个系统中的学生
大学部门管理者，需要提供和使用这些信息
使用系统信息的学院成员
数据保护工作者
潜在的学生中的雇佣者
在学生记录系统中的参与者包括：
。
学校管理中心包括负责学生注册，缴费，考试，评估，毕业事宜的相关人员
那些被记录具体信息的学生
把学生信息录入到系统并使用系统信息的学校部门人员
使用这些信息的学术人员
数据安全人员（本地和国家的）
潜在的雇用学生的人（或许需要用到这个系统里面的信息）
7.3三在图书馆系统中发现的观点。
libysy，建议三的要求，可以通过与相关的利益相关者提出的观点。
你可以解决这个问题用头脑风暴的方法。
显然，有许多替代解决方案建议，这里。
注意印刷冲突是故意的。
观点：
图书馆管理
要求：
进入汇文系统应限于认可的图书馆用户。
在汇文系统必须提供一个报告的设施，允许使用报告（谁使用系统，多久，是什么库访问）来创建和打印。
在汇文系统的配置应使特定的库服务器允许打印文档。
用户
在汇文系统应可从任何位置，包括地点离大学校园。
应能保存汇文系统查询，回忆和修改后使用。
在汇文系统应允许文件被打印在用户的打印机。
系统管理员
重新启动时间的汇文系统失败后不得超过5分钟。
在汇文系统必须提供一个用户的个人工作空间的备份设备。
在汇文系统应提供一系列平台包括Windows2000，WindowsXP和MACOSX。
7.4汇文系统支持包括编目工作的新文件系统目录可以分布在多台机器。
可能是非功能需求与编目设施有关的最重要的类型？
重要的非功能属性的编目服务的可能：
•可用性（因为系统可以在任何需要的时间）
•安全（因为图书数据库不能损坏）
•效率（因为系统必须迅速作出反应，每个交易）
为浏览服务，这些服务的可用性也是非常重要的应该是易于使用，没有广泛的培训。
讨论了一个例子，一个类型的系统的社会和政治因素可能强烈地影响系统的要求。
解释为什么这些因素是重要的在你的例子。
社会和政治因素影响系统需求的一个例子是管理成本和公共卫生保健的系统。
政治家们对控制成本和确保提供最好的卫生保健系统都很关心。
在这样一个系统中这本来就是一对潜在的矛盾，系统管理人员关心的治疗成本而医生们关心的治疗效果。
此时系统需求可能要建立在特殊的包括一系列组织因素的政策上而不是技术需求。
11.1为什么它可能需要在规范设计系统的体系结构是写的吗？
体系结构设计过程输出了一个体系结构的设计文档，这样的设计文档包含了一系列图形化的系统模型描述和一些相关的描述文本。
该文当描述了系统如何有子系统构成以及每个子系统如何有模块构成。
11.4给你答案的原因，建议以下系统的一个合适的结构模型：
11.4.1一个在铁路站旁，供乘客使用的自动售票系统
答：
自动售票系统。
最合适的架构模型是有共享数据仓库和定价信息的集中式控制模型。
当使用这种模型时，所有机子能立即获取改变的信息。
由于没有局部处理的必要，所以使用客户/服务架构没有什么优势。
集中式控制系统允许全局信息和路径被收集和处理。
一个允许在同一时间段，视频，音频，计算机数据对很多参与者是可见的计算机控制视频会议系统答：
视频会议系统。
最合适的是使用客户/服务模型。
很多局部过程用来处理多媒体数据。
11.4.3一个清洁机器人，主要用来清理一些地方比如走廊。
该清洁机器人必须能感应墙和其他的障碍物。
清洁机器人。
最适合的模型是贮藏式模型。
这时所有的子系统把信息存放在其他子系统得贮藏室，以备后用。
以AI系统为例，一种特殊的贮藏室叫做“黑板”被使用
11.8就分布性讨论数据流模型和对象模型的优点和缺点。
假设应用程序的淡季和分布式版本都是必需的。
两种模型都能作为分布式，数据流程图中的每个转换都可以看作是个分离的过程，而每个对象也可以作为过程实现。
函数的分解需要共享状态，并表示为一个或多个过程。
在对象模型中分布对象是个问题，对象如果继承的话就如同它的创建一样会造成很多网络阻塞。
用例子，解释对象和对象类之间的不同。
对象类就是定义实体（或者说对象）的类型说明，包含可以被识别的相似的公共特征。
对象是真实世界或是在系统中的通过对象类对其属性进行赋值的特殊实例。
给对象的赋值操作可用于识别与其他所有对象的区别，尽管不需如此。
在现实世界中，我们只能看到对象和作为抽象实体的构造对象类。
在程序中，我们通常可以定义对象类和构造对象，它们的声明周期不超过程序的执行时间。
一个对象类的一个实例，是一本具有的属性（特征）如标题，作者，出版社，出版日期，等。
一个叫做“BOOK”的对象类的例子，属性有诸如……
一个关于这个对象类的对象的例子“specificbook”
作者：
伊恩萨默维尔标题：
软件工程版：
7出版商艾迪生卫斯理
如果我们想定义一个书的对象是不同于其他所有的对象，我们需要增加的另一个特点的对象类，如业主。
16.2
说明在什么情况下提供前后一致的用户界面是不明智的或是不可能的。
一致性的用户界面也许不可能提供给拥有大量选项的复杂系统。
在这样的系统中，经常使用的不同命令的使用程度有很大差异，因此我们希望用快捷方式。
除非所有的命令都有快捷方式，否则一致性的界面是不可能的。
此外在复杂的操作界面中有不同类型的操作实体,这些不同类型的操作实体拥有相同的操作是不可能的。
开放型操作系统就是这样一个系统的例子。
甚至是竭力做到尽可能一致性界面的苹果操作系统（MacOS）都会根据不同的用户喜好而由此产生矛盾。
再举个例子，用户要删除一个文件，只要把它拉到垃圾回收站，而删掉一个磁盘映像可不能这样，那要卸载那个磁盘。
在为“临街的”系统（如ATM机）涉及基于菜单的界面时，必须考虑哪些因素？
请对你所使用的ATM机的界面提出批评意见。
要考虑的因素在设计步行和使用的系统：
•系统的用户可能是虚弱的，或禁用，因此将无法快速响应的要求。
•用户可能无法讲母语的国家机器安装。
•系统的用户可以与技术完全陌生的，可以用机器做几乎任何类型的错误。
接口必须尽量减少可能出现的错误的数量必须是有弹性的任何可能的错误。
•一些系统的用户可能是由许多选项吓倒。
另一方面，当用户与系统增益的熟悉，他们可能会使用一系列的银行服务。
•不同的人可能会明白不同图标的含义。
•如果系统导航选项，用户几乎肯定是迷路了。
•大多数用户将要使用的系统很简单的功能（例如提取现金取款机）和将要这样做，尽快。
有许多不同的ATM接口，每个人都必须单独考虑。
我所发现的问题是：
当有可能取消交易吗？
当我这样做时会发生什么？
如果我重新启动事务必须重新输入什么？
通常是不存在任何的方式说给我的最大数额的钱我可以撤回今天。
有些机器只支持单一的交易是没有办法说我会做一些交易和相同的验证过程是适用于所有的人
16.5试述图形显示的优点，指出适合用图形显示数值而不适合用数字显示的四种应用。
优点是匆匆一眼就能获得数值暗示和相对数值暗示。
这里有四个适于图形显示信息,而不适用于数字显示信息的例子.
温度计
速度指示器
气候统计表
一些相关的比较表格.
你在什么情况下会建议不采用敏捷方法进行软件系统开发？
当几个软件开发团队不在同一个地方时不可用敏捷方法。
如果其中一个团队用了敏捷方法,就很难跟其它团队协调工作.敏捷方法也要避免用在关键系统,在规格错误的情况下如果用这个方法,会导致严重的后果.在开发系统之前规格就可以用的情况下,可以做详细的规格分析使用敏捷方法成为可能.然而,一些敏捷方法中的思想像测试优先开发（TestFirstDevelopment–TFD又称先行测试开发）当然是可以适用于关键系统的.
解释为什么测试优先开发能帮助程序员获得对系统需求的更好的理解。
测试优先的开发有什么潜在的困难。
测试优先开发帮助我们更好地理解需求，因为你要写一个测试程序，就需要分析需求，探究详细意图。
有时候，在需求不全的情况下,你会发现写一个测试是不可能的。
测试优先开发的问题就在于是一些测试很难写，因为在任何一个测试之前都要一个就绪的系统底层结构.
给出四个理由说明为什么结对编程和单个程序员编程的软件生产率基本上是一样的。
结对编程和同等数量的编程人员单独编程一样有效的原因:
1.结对编程会引发连续非正式地复查，这样会比单独编程更快地发现错误。
2.结对编程过程中，信息是共享的。
单独编程中，人们不得不花时间来共享信息。
3.结对编程鼓励重构（代码需要让其他人看懂），这样减少了后期开发和变动的成本。
4.结对编程可能花更少的时间在细节优化上，因为这对其他程序员来说没有好处。
（译者注：
没看懂）
假设一个软件管理者参与了一个开发某个软件设计支持系统的项目，此系统是要支持将软件需求翻译成形式化软件描述。
请评论下列开发策略的优点和缺点。
开发抛弃式原型，评估，然后审查系统需求。
用C语言开发此系统。
丢弃原型化方法:
快速的开发和快速的用户反馈.可以带来合理的需求.
需要多种开发语言.花费更高.
适用java从现存的需求开始开发系统，然后修改它使之适应任何变更的用户需求。
开发使用C和X-Windows培训较少的问题。
已知的管理策略。
需求可能的错误需要交付后的改性。
训练几乎没问题,已知的管理策略.需求可能的错误的,所以要交付修改.
适用增量式方法并让用户参与到开发团队来开发此系统。
进化的方法.快速的用户反馈.快速的系统交付.容易适应改变的需求.
很难管理,缺少可移植性的标准.无特定系统结构,将导致以后的维护困难.
18.2解释下为什么通过复用已有的软件所节省的成本并不简单地与所适用的组件规模成比例。
如果复用节约的成本和复用的代码成比例，那么复用2000行代码就相当于复用两次1000行代码了。
然而，复用2000行代码，那些代码必须要被理解，程序理解的费用不是线性的——越多的代码，就需要越多的努力去理解的。
而且，当需要更多的改动时，就需要更大量的代码复用，这也增加了成本。
18.3给出你认为不应该适用软件复用的4种情况。
一如果代码提供商的运作状况不确定，或者提供商歇业，不支持代码的复用。
二关键部分的代码不可用。
要测试这些代码以达到所需标准，可能非常困难。
三再利用所花的成本和再利用所节省下来的差不多的小型系统
四在一些关键需求在于性能的系统里，专门开发的代码通常更有效率。
18.4为什么模式是一种有效的设计复用形式？
这种复用方式的缺点是什么？
模式是一种有效的再利用设计,是因为它是很多人在应用中积累出来的智慧.这种方法有两种缺点:
知道哪一个模式被存档,找到这些模式所花的时间是必要的.
2.很多模式是一般化的,很多性能可能被限制.如果性能是主要要求的话,那么为某一个问题问题特别研究的方法总是更有效率的.
xxx确定了六个可能的风险时可能出现的系统被构造使用COTS。
公司可以采取什么步骤来降低这些风险呢？
风险时可能出现的系统被构造使用COTS包括：
卖主风险:
卖方无法提供必要的支持,卖方歇业或结束产品开发.
产品风险:
和其它系统不兼容,和其它系统组装时性能下降,在特定环境下,产品不可靠.
过程风险:
理解如何组装产品的时间超出预期.
可以通过使用第三方系统来解决.这样的话,可以通过深入的研究,投入使用前的产品兼容性的测试,和其它用户讨论等方法来保证源代码的可用,如果卖方歇业的话.
通常,COST是由卖方提供的,要减少风险是困难的.
19.1为什么它是重要的，所有组件的交互是通过定义的“需要”和“提供”接口？
它是通过定义所有的相互作用重要的需要提供接口，组件的使用是完全独立的，它的实现。
如果组件交互使用的一些知识的组成部分，是没有定义的要求/提供接口，然后组件之间的耦合增加，很难交换一个具有相同接口的等效组分的一个组成部分。
19.3之间的根本区别是什么组件和Web服务（seeChapter12）.
Web服务只有单一的一个标准，组件则有多个标准，因此服务的内部操作性会更好。
服务的付费是按使用权计算的（你要用时再付费，不用时，可以停止付费），这样用户就不用为一个偶尔使用的组件，支付昂贵的费用。
组件的交互可以作用比Web服务更有效的协议，因此组件更适用于高吞吐量/高性能要求的应用。
一旦一个组件被购买，它就属于用户所有。
而与此相反，Web服务总是被提供商拥有，这就意味着用户对于服务的更改永远没有控制权，如果服务变更（或消失），那么可能对用户很不利。
而组件不同，用户可以决定什么时候使用新版本。
19.6解释为什么它是很难不组件源代码验证的可重用的组件。
以什么样的方式将一个正式的组件规范简化验证的问题？
因为在没有源代码的情况下，我们无法知道该组件是如何处理异常的。
唯一的办法就是黑盒测试。
因为组件的详细规格说明书很少是完整的，黑盒测试也有很大的困难。
标准的详细规格说明书定义了组件的功能，尽管能提供一定的帮助，但是标准的说明书也很少说明全部的异常，它并不能帮助我们测试组件的性能，可靠性或其它的非功能性特征。
19.8使用的例子，说明需要支持顺序组成的适配器类型不同，分层的组合物和添加剂的组合物。
顺序组合的例子：
部件C是由部件A和部件B依次组合而成的。
附加组合的例子：
部件C是由部件A的界面和部件B的界面组成的。
层次组合的例子：
部件C是由部件B组成的，而部件B是由部件C组成的。
23.1解释为什么测试只能检测到错误的存在，而不是他们的缺席。
假定穷举测试的程序，在每一个可能的有效输入检查，是不可能的（适用于所有但平凡的程序）。
测试用例不显示故障在程序或显示一个程序故障。
如果他们发现一个程序故障则证明错误的存在。
如果他们不显示故障，然而，这只是意味着他们已执行的代码序列，–为输入–是不是错误的选择。
在相同的编码序列–不同输入–下测试可以揭示故障。
23.3回归测试是什么？
解释锄自动化测试的使用和测试框架，如单元简化回归测试。
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
如果设置了自动回归测试，在每次修改代码之后都会自动进行测试，简化了回归测试的工作。
一个自动化的测试包括成功的自身测试和其他测试。
这样成功的测试成本和回归测试成本较低。
23.6在一个分布式数据库系统，如LIBSYS开发性能测试的问题是什么？
在软件测试一个系统中碰到的主要问题是：
在实际中你不能重复测试一个系统，所以你必须用一个模拟器来模拟系统的使用。
然而，你没有系统实际工作的经验，用一个模拟器很难测试系统工作时的准确性。
2．LIBSYS系统不一定在专用的电脑上工作――该系统也可以同时在其他应用系统上工作。
其他应用系统也会影响整个分布式系统的工作。
在测试的时候，这些情况不会重复发生。
3．事实上数据的分布是未知的。
数据分布受到特定的服务器的影响，所以对于数据的最初的假设可能是错误的。
23.7解释为什么接口测试是必要的甚至在个别组件已被广泛验证通过组件测试和程序检查。
在单元测试后接口测试的重要性：
①单元的接口可能没有明确的说明。
确认这个单元的接口是以他的详细规格说明书为基础而不是以单元或者子系统在实践中的使用为基础的。
②假设了某些单元的操作，接口测试可以检测由这些单元组成的接口是否正确，有效。
③接口测试可以揭示在接口设计时的遗漏和错误。
当接口和其他的单元组合在一起的时候这些错误会被发现，那么这些遗漏和错误可以被加到这个接口中。
26.1在什么情况下会公司收费软件系统比建议的费用估计加正常利润更高的价格？
①客户要开发者自己承担大部分的项目风险。
②客户有一些苛刻的要求，比如开发的时间比较短，要快速开发。
③开发软件这个工作不是公司主要的业务，所以为了开发项目必须从其他的业务上调派人手过来，那么就需要补偿给这些人更多的钱。
④客户很自私，只考虑到自己不能承担太多的钱。
26.2描述两个已被用来衡量程序员生产率度量。
简要评述了各自的优点和缺点，这些度量。
已用于生产的测量指标：
•源代码行的每单位时间产生的
•目标代码指令的每单位时间
•页的每单位时间的文件其他的可能性是：
数据字典条目每单位时间•数（可能是有用的如果使用CASE工具）
数学定义的每单位时间产生的•数（规范）
书面的每单位时间的要求•数
设计图的每单位时间产生的•数
所有这些，当然，遭受同样的问题，其他指标，那就是，他们不考虑质量因素。
26.8解释如何成本估计算法可以由项目经理进行期权分析。
建议的情况
升级会员 