下载文档原格式
《软件工程》各章课后习题答案软件工程是计算机科学与技术的一门重要学科，旨在研究和应用工程原则和方法来开发高质量的软件系统。
课程中的习题对于加深学生对软件工程理论和实践的理解至关重要。
下面是对《软件工程》各章课后习题的答案，希望能够帮助你更好地掌握软件工程的知识。
第一章：软件工程导论1. 软件工程的定义：答：软件工程是通过应用系统化、规范化和可量化的方法进行软件开发、运行和维护的学科。
2. 软件工程的目标：答：软件工程的目标是提高软件开发的质量、效率和可靠性，使得软件能够满足用户的需求和期望。
3. 软件生命周期模型：答：常见的软件生命周期模型包括瀑布模型、迭代模型、敏捷模型等。
每个模型都有其独特的特点和适用场景。
4. 软件过程模型：答：软件过程模型描述了软件开发过程中的一系列活动和阶段，常见的软件过程模型包括瀑布模型、迭代模型、敏捷模型等。
5. 软件工程的基本原则：答：常见的软件工程基本原则包括分阶段、逐步求精、持续集成、迭代开发、需求优先等。
第二章：软件项目管理1. 软件项目管理的定义：答：软件项目管理是指对软件开发过程中的资源、进度、质量等进行有效管理，以确保软件项目能够按时、按质地完成。
2. 软件项目管理的内容：答：软件项目管理包括项目计划、需求管理、项目进度管理、资源管理、风险管理等方面。
3. 软件项目管理的方法：答：常见的软件项目管理方法包括敏捷项目管理、水平项目管理、里程碑项目管理等。
4. 软件项目管理的工具：答：常用的软件项目管理工具包括甘特图、PERT/CPM网络图、项目管理软件等。
第三章：软件需求分析与规格说明1. 软件需求的定义：答：软件需求是指用户对软件系统的要求和期望，包括功能需求、性能需求、接口需求等方面。
2. 软件需求分析的方法：答：常用的软件需求分析方法包括面向对象分析法、数据流图法、用例分析法等。
3. 软件需求规格说明的格式：答：常见的软件需求规格说明的格式包括自然语言描述、结构化描述、图形描述等。
第一章一、什么是软件危机？它有哪些典型表现？为什么会出现软件危机？软件危机是指在计算机软件开发、使用与维护过程中遇到的一系列严重问题和难题。
它包括两方面：如何开发软件，已满足对软件日益增长的需求；如何维护数量不断增长的已有软件。
软件危机的典型表现：(1) 对软件开发成本和进度的估计常常很不准确。
常常出现实际成本比估算成本高出一个数量级、实际进度比计划进度拖延几个月甚至几年的现象。
而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量。
这些都降低了开发商的信誉，引起用户不满。
(2) 用户对已完成的软件不满意的现象时有发生。
(3) 软件产品的质量往往是靠不住的。
(4) 软件常常是不可维护的。
(5) 软件通常没有适当的文档资料。
文档资料不全或不合格，必将给软件开发和维护工作带来许多难以想象的困难和难以解决的问题。
(6) 软件成本、软件维护费在计算机系统总成本中所占比例逐年上升。
(7) 开发生产率提高的速度远跟不上计算机应用普及的需求。
软件危机出现的原因：(1) 来自软件自身的特点：是逻辑部件，缺乏可见性；规模庞大、复杂，修改、维护困难。
(2) 软件开发与维护的方法不当：忽视需求分析；认为软件开发等于程序编写；轻视软件维护。
(3) 供求矛盾将是一个永恒的主题：面对日益增长的软件需求，人们显得力不从心。
二、假设自己是一家软件公司的总工程师，当把图1.1给手下的软件工程师们观看，告诉他们及时发现并改正错误的重要性时，有人不同意这个观点，认为要求在错误进入软件之前就清楚它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢？”应该怎么反驳他？答：在软件开发的不同阶段进行修改付出的代价是很不相同的，在早期引入变动，涉及的面较少，因而代价也比较低；在开发的中期，软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”是在引入变动，当然付出的代价更高。
第一章1.1什么是计算机软件？软件的特点是什么？计算机软件是指计算机系统中的程序及其文档软件的特点：软件是一种逻辑实体，而不是有形的系统元件，其开发成本和进度难以准确地估算。
软件是被开发的或被设计的，没有明显的制造过程，一旦开发成功，只需复制即可，但其维护的工作量大。
软件的使用没有硬件那样的机械磨损和老化问题。
1.2简述软件的分类，并举例说明1.系统软件系统软件居于计算机系统中最接近硬件的一层，其他软件一般都通过系统软件发挥作用。
例如：编译软件、操作系统。
2.支撑软件支撑软件是支撑软件的开发和维护的软件。
例如：数据库管理系统、网络软件、软件工具、软件开发环境。
3.应用软件应用软件是特定应用领域专用的软件。
例如：工程/科学计算机软件、嵌入式软件、产品线软件、Web应用软件、人工智能软件。
1.3简述软件语言的分类，并举例说明。
1.需求定义语言是用于书写软件需求定义的语言。
例如：PSL/PSA。
2.功能性语言是用于书写软件功能规约的语言，通常又称为功能规约语言。
例如：广谱语言、Z语言。
3.设计性语言是用于书写软件设计规约的语言。
例如：PDL。
4.实现性语言也称为程序设计语言，是用于书写计算机程序的语言。
例如：C、java、PROLOG、FORTRAN、COBOL、Modula。
5.文档语言是用于书写软件文档的语言。
通常用自然语言或半形式化语言书写。
1.4什么是软件工程？软件工程是应用计算机科学、数学及管理科学等原理，开发软件的工程。
软件工程借鉴传统工程的原则、方法，以提高质量、降低成本为目的。
1.5简述软件工程的基本原则。
软件工程原则包括围绕工程设计、工程支持和工程管理所提出的以下4条基本原则。
1.选取适宜的开发模型必须认识需求定义的易变性，采用适宜的开发模型，保证软件产品满足用户的要求。
2.采用合适的设计方法合适的设计方法有助于这些特征的实现，以达到软件工程的目标。
3.提供高质量的工程支撑软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。
软件工程课后习题参考答案软件工程课后习题参考答案1. 第一章规约与软件工程概述1.1 规约的定义规约是软件开发过程中明确要求的描述，包含了对软件需求、设计、实现、测试、部署和维护等各个阶段的要求和约束。
1.2 软件工程的概述软件工程是一门涉及对软件的开发、运行和维护的学科。
它通过应用工程原则和方法，以系统化、规范化、可靠化、经济化和高质量的方式来开发和维护软件。
2. 第二章软件需求规约2.1 软件需求规约的作用软件需求规约是对软件系统所需功能和性能的具体描述和说明，是软件开发的基础和依据。
它指导着开发团队的工作，确保软件的功能和性能符合用户的需求。
2.2 软件需求规约的要素软件需求规约包括功能需求、非功能需求和约束条件。
功能需求描述了软件系统应该具备的功能，非功能需求描述了软件系统的性能要求和质量特性，约束条件描述了软件系统所受限制的条件。
3. 第三章软件设计规约3.1 软件设计规约的目标软件设计规约是对软件系统进行结构化和模块化设计的过程，其目标是确保软件系统具备可靠性、可维护性、可扩展性和可重用性。
3.2 软件设计规约的方法软件设计规约采用面向对象设计、结构化设计和模块化设计等方法。
面向对象设计强调将问题领域的概念和对象转化为软件系统的类和对象，结构化设计强调将系统分解为模块，模块化设计强调模块间的接口和通信。
4. 第四章软件实现规约4.1 软件实现规约的目的软件实现规约是指将软件设计阶段得到的设计规约转化为计算机可执行的程序代码，其目的是确保软件系统的正确性、可靠性、可维护性和可测试性。
4.2 软件实现规约的技术软件实现规约采用编程语言、软件开发工具和软件开发环境等技术。
编程语言提供了描述算法和数据结构的语法和语义，软件开发工具提供了代码编辑、编译、调试和测试等功能，软件开发环境提供了开发的整体支持。
5. 第五章软件测试规约5.1 软件测试规约的目的软件测试规约是对软件系统进行功能、性能和质量等方面的验证和检测，其目的是找出软件系统的错误和缺陷，并修复和改进。
软件工程课后习题答案1. 什么是软件工程？软件工程是一种应用工程原理和方法的学科，目的是开发高质量的软件。
软件工程包括以下几个方面：•需求分析：确定用户的需求，并将其转化为可执行的软件功能。
•设计：设计软件的架构和模块，并确定各个模块的功能和关系。
•编码：实现软件的设计，将设计的模块通过编程语言编写成可执行的代码。
•测试：通过不同的测试方法和技术对软件进行验证，确保软件的质量和可靠性。
•维护：对软件进行改进和修复，以适应用户需求的变化和修复软件中的错误。
2. 软件工程的目标是什么？软件工程的目标是开发高质量的软件，以满足用户的需求。
具体目标包括：•可靠性：软件应该能够正常运行并处理各种输入情况，不会崩溃或导致系统故障。
•可维护性：软件应该易于理解和修改，以适应用户需求的变化和修复软件中的错误。
•可扩展性：软件应该能够在不改变其基本架构的情况下，方便地添加新的功能模块。
•可重用性：软件应该能够被多个项目和团队复用，以提高开发效率。
•可测试性：软件应该易于测试，以确保其功能和性能符合预期。
3. 软件开发生命周期有哪几个阶段？软件开发生命周期通常包括以下几个阶段：1.需求分析和定义阶段：在这个阶段，软件工程师与用户沟通，了解用户的需求和期望。
然后，设计师将这些需求转化为软件规格说明。
2.软件设计阶段：在这个阶段，设计师根据需求规格说明书设计软件的架构和模块，并确定模块之间的关系和功能。
3.编码阶段：在这个阶段，开发人员根据设计文档编写代码，实现软件的功能。
4.测试阶段：在这个阶段，测试人员使用不同的测试方法和技术对软件进行验证，以确保软件的质量和可靠性。
5.部署和维护阶段：在这个阶段，软件工程师将软件部署到实际的运行环境中，并根据用户的反馈进行改进和修复。
4. 什么是软件需求？软件需求是对系统或软件功能和性能的描述，它描述了用户的需求和期望。
软件需求通常包括以下几个方面：•功能需求：描述软件应该具有的功能，以及这些功能如何满足用户的需求。
软件工程课后习题答案习题1 略。
习题2 略。
习题3 略。
习题42．在什么情况下应该使用形式化说明技术？使用形式化说明技术时应遵守哪些准那么？人们在理解用自然语言描述的规格说明时，容易产生二义性。
为了克制非形式化方法的缺点，人们把数学引入软件开发工程，创造了基于数学的形式化说明技术。
应用形式化方法的准那么：〔1〕应该选用释放的表示方法；〔2〕应该形式化，但不要过分形式化；〔3〕应该估算本钱；〔4〕应该有形式化方法参谋随时提供咨询；〔5〕不应该放弃传统的开发方法；〔6〕应该建立详尽的文档；〔7〕不应该放弃质量标准；〔8〕不应该盲目依赖形式化方法；〔9〕应该测试、测试再测试；〔10〕应该重用。
4．用有穷状态机说明自动化图书馆流通系统习题5 略。
习题6 略。
习题7 略。
习题8 略。
习题91．什么是面向对象方法学？它有哪些优点？面向对象方法学，是尽可能模拟人类习惯的思维方式，使开发软件的方法和过程尽可能接近人类认识世界解决问题的方法和过程，从而使得实现解法的解空间〔也称为求解域〕与描述问题的问题空间〔也称为问题域〕在构造上尽可能一致。
优点：1.与人类习惯的思维方法一致；2.稳定性好；3.可重用性好；4.较易开发大型软件产品；5.可维护性好10．建立订货系统的用例模型。
分析如下：从对这个订货系统的需求可以知道，仓库管理员通过放在仓库中的终端把零件入库/出库市事务报告给订货系统，系统承受到事务信息之后应该处理事务；采购员需要使用订货系统提供的产生报表功能，以获取订货报表。
综上所述，用例如下：习题101．用面向对象方法分析研究本书习题2第2题中描述的储蓄系统，试建立它的对象模型、动态模型和功能模型。
对象模型参考：以上还需将关联关系说明补全。
动态模型参考：（1）脚本正常情况脚本：●储户有存款要求，填写存款单，包含储户个人信息，存款金额和存款类型；●业务员查收存款，审核存款与存款单存款金额吻合；●存款单生效；●储户有取款要求，填写取款单，包含个人账号、密码〔待定〕和存款金额；●业务员审核存款，验证储户身份，确定储户存款金额 > = 取款金额；●审核通过，取款单生效；●系统打印利息清单，业务员把本金和利息返回储户。
第一章练习题一、填空题1、软件工程三要素是：方法、工具、过程。
2、软件开发方法是指软件开发过程中所应遵循的方法和步骤。
二、名词（术语）解释：1、可靠性---是指在给定的时间间隔内，程序成功运行的概率。
可靠性是衡量软件质量的一个重要目标。
2、可理解性---指系统具有清晰的结构，能直接反映问题的需求。
可理解性有助于控制软件系统的复杂性，并支持软件的维护、移植和重用。
三、问答题1、面向对象方法的优点是什么？答：（1）将现实世界问题向面向对象解空间直接映射，实现对现实世界的直接模拟。
（2）以数据为中心，而不是基于对功能的分解，使得软件结构相对稳定，软件的重用性、可靠性、可维护等特性都较好。
2、可视化开发方法的优点有哪些？答：（1）简化了图形用户界面的设计和编码工作，将开发的注意力主要集中在程序的执行逻辑和工作流程上。
（2）软件开发简单，易学、易上手。
（3）专业或非专业人员都能参与软件开发活动。
第二章练习题一、填空题：1、软件工程过程是：为获得软件产品，在软件工具支持下由软件人员完成的一系列软件工程活动。
2、一个软件从定义、开发、使用和维护，直到最终被废弃，所经历的生存过程经历的生存过程称为软件生存期或叫生命期。
3、软件生命周期的阶段划分为3个时期是：定义时期、开发时期、维护时期。
4、软件工程标准的5个层次是：国际标准、国家标准、行业标准、企业规范、项目规范。
二、简答题：1、瀑布模型的优点有哪些？答：1、强迫开发人员采用规范的技术方法；2、严格地规定了每个阶段必须提交的文档；3、每个阶段结束前必须正式进行严格的技术审查和管理复审。
2、瀑布模型的缺点是什么？答：1、在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件来说是极其困难的。
2、在需求分析阶段，当需求确定后，无法及时验证需求是否正确、完整。
3、作为整体开发的瀑布模型，由于不支持产品的演化，缺乏灵活性，对开发过程中很难发现的错误，只有在最终产品运行时才能暴露出来，从而使软件产品难以维护。
软件工程课后题答案大全(详细)软件工程课后题答案大全(详细)现代社会中，软件工程越来越重要，因为它在各个行业中扮演着关键的角色。
而在学习软件工程课程时，完成课后题是提高理解和掌握程度的重要途径。
本文将为您提供一份全面且详细的软件工程课后题答案大全，希望能够帮助您更好地学习与应用软件工程知识。
1. 什么是软件工程？软件工程是指应用系统化的、规范化的、可量化的方法来开发和维护软件的学科。
它涵盖了各种软件开发阶段，包括需求分析、设计、编码、测试和维护，并借鉴了工程学的原则和方法。
2. 软件工程的原则有哪些？软件工程遵循一系列原则来保证软件开发和维护的质量和效率，如下：- 需求管理原则：明确需求，确保项目目标的准确性和一致性。
- 分阶段原则：将软件开发过程划分为不同的阶段，有序进行。
- 风险管理原则：评估和管理项目中的风险，降低项目失败的可能性。
- 适应性原则：根据不同的项目需求和情况，选择合适的软件开发方法和工具。
- 团队合作原则：加强团队协作，促进良好的沟通和信息共享。
3. 软件生命周期有哪些阶段？软件生命周期包括需求分析、设计、编码、测试和维护等多个阶段。
- 需求分析：明确软件系统的功能和性能要求，了解用户需求。
- 设计：定义软件系统的整体结构和组件之间的关系，确定使用的技术和工具等。
- 编码：根据设计方案，将代码实现为可以执行的程序。
- 测试：验证软件系统的功能和性能是否满足需求，并进行错误修复。
- 维护：对软件进行修复和改进，确保系统的长期可用性。
4. 软件需求分析的方法有哪些？软件需求分析是保证软件项目成功的关键步骤，以下是几种常用的分析方法：- 面谈法：直接与用户沟通，了解他们的需求和期望。
- 文档分析法：研究和分析相关文档，如需求规格说明书、用户手册等。
- 原型法：创建一个初步的系统原型，供用户参观和测试，获取反馈。
- 视频录制法：录制用户正在进行的工作流程，以便更好地了解他们的需求。
5. 软件项目管理中的风险管理包括哪些步骤？风险管理是确保软件项目成功的重要环节，步骤如下：- 风险识别：识别和描述可能影响项目目标实现的风险。
软件⼯程实践者的研究⽅法第21章答案Problem:Some people say that “variation control is the heart of quality control.” Since every program that is created is different from every other program, what are the variations that we look for and how do we control them?Answer:4633-16-1P SA: 9420SR: 6376A program is equal to data structure plus algorithm. Generally, different programmers will design a program in a different way. Logic of one person varies from the other as per their own thinking. Coding of one programmer will be different from others in solving the same problem.So, we can expect variations in the design and coding of the data structure and the algorithm of a program by different individuals. Also the programming language chosen by each may vary. Hence we can look for the variations also in the syntax, logic, complexity, readability.We can control the variations by checking the types and levels of complexity that can be used in the design of the data structures and the algorithms of a program.Problem:Is it possible to assess the quality of software if the customer keeps changing what it is supposed to do?Answer:Yes, If we define quality as "conformance to requirements," and requirements are dynamic (keep changing), it is possible to assess the quality of software. The definition of quality will be dynamic and an assessment of quality will be difficultProblem:Quality and reliability are related concepts but are fundamentally different in a number of ways. Discuss the differences.Answer:4633-16-3P SA: 9420SA: 6376Quality and reliability both are related concepts. But fundamentally these both are different in some scenarios.1. Quality control is concerned with the performance of a product at one point in time.2. Quality focuses on the software's conformance to explicit and implicit requirements.3. Software quality assurance is the mapping of the managerial principles and design disciplines of quality assurance onto the applicable managerial and technological space of software engineering.Where as1. Reliability is concerned with the performance of a product over its entire life time.2. Reliability focuses on the ability of software to function correctly as a function of time or some other quantity.3. Software reliability models extend measurements, enabling collected defect data to be extrapolated into projected failure rates and reliability predictions.Problem:Can a program be correct and still not be reliable? Explain.Answer:Reliability:-Yes, it is possible for a program to conform all explicit functional and performance requirements at a given instant. Because, reliability uses statistical analysis to determine the software failure with likelihood occur.And, The probability of failure is free software operation for a specified period of time in a specified environment.Problem:Can a program be correct and still not exhibit good quality? Explain.Answer:Yes, it is possible for a program to conform to all explicit functional and performance requirements at a given instant, yet to not perform well during maintenance, integration on other systems, or might have hardware dependencies.Many programs have been patched together, so that they work yet these programs exhibit very low quality if measured by McCall's quality factors.Problem:Why is there often tension between a software engineering group and an independent software quality assurance group? Is this healthy? Answer:Software Quality Assurance group vs. Software Engineering group:Between these two groups, there is a common natural tension because, if the SQA group takes on the role of the "observing the bugs of software code," flagging quality problems and high-lighting shortcomings in the developed software, this is normal and this would not be embraced with open arms by the software engineering group.This software quality assurance group helps ensure that they fit the project’s needs and verifies that they will be usable for performing the necessary reviews and audits throughout the software life cycle.As long as the tension does not degenerate into hostility, there is no problem. It is important to note, however, that a software engineering organization should work to eliminate this tension by encouraging a team approach that has development and QA people working together toward common goal of high quality software.Problem:You have been given the responsibility for improving the quality of software across your organization. What is the first thing that you should do? What’s next?Answer:For improving the quality of software across the organization, First of all i evaluate the quality Based on the formal technical reviews, I checkout the total working process of that software. If it is working smoothly, then the number of SQA activities might be implemented. That isChange control and SCM;Comprehensive testing methodology;SQA audits of documentation and related software.In this process software metrics can help.Problem:Besides counting errors and defects, are there other countable characteristics of software that imply quality? What are they and can they be measured directly?Answer:Suppose maintainability measured by mean – time – to – change; portability as measured by an index that indicates conformance to language standard, portability complexity, availability , reliability.Portability as measured by an index that indicates conformance to language standard; complexity as measured by McCabe's metric, and so onHere reliability focuses on the ability of software to function correctly as a function of time or some other quantity.Safety considers the risks associated with failure of a computer based system that is controlled by software.Quality focuses on the software’s conformance to explicit and implicit requirements.In most of the cases an assessment of quality considers may factors that are qualitative in nature.Problem:The MTBF concept for software is open to criticism. Explain why.Answer:4633-16-9P SA: 9420SR: 6376MTBF (mean-time-between-failure) is a simple measure of reliability.MTBF = MTTF + MTTRWhere,MTTF stands for Mean-Time-To-Failure andMTTR for Mean-Time-To-RepairMTBF is related to the mean times. The concept of MTBF is open to criticism because of various reasons. Its measures are based on CPU time, not wall clock time. One of the reasons is it can be problematic for two reasons. They are1. It projects a time span between failures, but does not provide us with a projected failure rate, and2. MTBF can be misinterpreted to mean average life span even though this is not what it implies.Problem:Consider two safety-critical systems that are controlled by computer. List at least three hazards for each that can be directly linked to software failures.Answer:To build safety – critical systems, instead of simply trying to get software correct and assuming that will ensure. System safety, attention is focused on eliminating or controlling the software behaviors.1. The software requirements are complete and specify only safe behaviors.2. The entire software development and maintenance process eliminates (or) reduces the possibility of the unsafe behavior.Software hazard analysis is a form of subsystem hazard analysis used to identify safety – critical software behavior.The system safety design constrains and information from the system hazard analysis, is used to:1. Develop software safety for design constraints.2. Identify specific software safety requiems.3. Device software and system safety test plans and testing requirements.4. Trace safety related requirements5. Develop safety – related information for operations, maintenance.Problem:Acquire a copy of ISO 9001:2000 and ISO 9000-3. Prepare a presentation that discusses three ISO 9001 requirements and how they apply in a software context.Answer:ISO 9001: 2000 is the generic source of requirements for quality assurance in design, development, production; installation and servicing as well as the standard against which quality management systems for software are assessed.In ISO 9000:2000 quality management system – fundamentals and vocabulary.ISO 9004: 2000 quality management systems- Guidelines for performance imprisonmentISO 9000: 2000 explains the principles underlying the change’s ISO 9001 and defines vocabulary.ISO 9001:2000 is the quality assurance standard the applies software engineering. The standard contains 20 requirements that must be present for an effective quality assurance system.Because the ISO 9001: 2000 standard is applicable to all engineering disciplines, a special set of ISO 9000 -3 have been developed to help interpret standard for use in the software process.Solution: Chapter 21: SOFTWARE QUALITY ASSURANCE21.1 We look for variation in the traceability from requirements to design and design to code. We assess the variation in the form and content of work products. We look for variation in the process — repeatable process is a goal. We look for variation in expected and actual results derived from software testing.21.2 In reality, if we define quality as "conformance to requirements," and requirements are dynamic (keep changing), the definition of quality will be dynamic and an assessment of quality will be difficult21.3 Quality focuses on the software's conformance to explicit and implicit requirements. Reliability focuses on the ability of software to function correctly as a function of time or some other quantity. Safety considers the risks associated with failure of a computer-based system that is controlled by software. In most cases an assessment of quality considers many factors that are qualitative in nature. Assessment of reliability and to some extent safety is more quantitative, relying on statistical models of past events that are coupled with software characteristics in an attempt to predict future operation of a program.21.4 Yes. It is possible for a program to conform to all explicit functional and performance requirements at a given instant, yet have errors that cause degradation that ultimately causes the program to fail.21.5 Absolutely. Many programs have been patched together or otherwise "kludged up" so that they work yet these programs exhibit very low quality if measured by McCall’s quality factors.21.6 There is often a natural "tension" that exists between these two groups. The reason is simple: if the SQA group takes on the role of the "watch dog," flagging quality problems and high-lighting shortcomings in the developed software, it is only normal that this would not be embraced with open arms by the software engineering group. As long as the tension does not degenerate into hostility, there is no problem. It is important to note, however, that a software engineering organization should work to eliminate this tension by encouraging a team approach that has development and QA people working together toward a common goal—high quality software.21.7 Institute formal technical reviews. After these are working smoothly, any of a number of SQA activities might be implemented: change control and SCM; comprehensive testing methodology; SQA audits of documentation and related software. Also software metrics can help.21.8 Any countable measure that indicates the factors noted that are candidates. For example, maintainability as measured by mean-time-to-change; portability as measured by an index that indicates conformance to language standard; complexity as measured by McCabe's metric, and so on.21.9 For hardware the MTBF concept is based on statistical error data that occurs due to physical wear in a product. In general, whena failure does occur in hardware, the failed part is replaced with a spare. However, when an error occurs for software, a design changeis made to correct it. The change may create side effects that generate other errors. Therefore, the statistical validity of MTBF for software is suspect.21.10 Classic examples include aircraft avionics systems, control systems for nuclear power plants, software contained insophisticated medical instrumentation (e.g., CAT scanners or MRI devices) control systems for trains or subway systems; elevator control systems.21.11 See the SEPA Web site for links to ISO sites.。
软件工程实践者的研究方法中文版第七版课后习题答案文稿归稿存档编号：[KKUY-KKIO69-OTM243-OLUI129-G00I-FDQS58-作业答案。
2.1a.设计者对于用户要问的问题：项目的目标是什么做到什么程度就成功了谁会对项目的成功做最后的评判项目的使用者包括那些b. 用户对设计者应该问的问题：目前问题有哪些解决方案，项目完成有哪些难点，在时间范围内能否完成？c. 软件问题用户自问？还有其他解决方案吗哪些功能是必须的乙方资质和能力够吗d. 软件过程问题自问？用敏捷还是用瀑布质量检查点分别有哪些有几个MileStone2.2 为沟通活动设计一系列动作，选定其一并设计任务集。
（批作业的时候，以合理为目标，不一定要一样）需求获取、需求规范说明（建模）、需求协商、需求确认等。
例如，书上page 23。
2.7 详细描述三个适合用于瀑布模型的软件项目。
（要求学生不仅仅列出项目的名称，而要说明为什么适合）瀑布模型适合于项目开发而不是产品开发。
信息管理系统一般适合于用瀑布模型。
因为这类系统业务功能较为明确，架构比较单一，技术难点较少。
图书馆系统、销售管理系统都是。
3.11 重构：已经写好的正确的代码，不断修正，使得代码更加精简并易读。
结对编程：两个人同时编写一段代码，一般一个人负责实现，一个人负责检查代码质量。
3.16 利用FDD，为“Web浏览器”定义一系列特征集合与特征。
特征集合模板：<Action><ing> an <Object> 如：出售一件商品特征定义模板：<Action> the <result> <by|for|of|to> a(n) <object>特征集合：展示Web页面内容。
特征：１）本地解析HTML页面２）展示HTML页面３）从网络上下载页面相关图片４）在浏览器上展示图片附加：统一过程模型的图。
（要求有图有说明）5.9 为如下活动开发一个完整的规约注意按照书本59页格式，包括用例名称，参与者，场景，异常等等。
5．10 用例异常代表什么1）非正常输入。
2）环境状态不满足要求。
3）备选方案。
5.13 在需求工程活动的谈判情境中，“双赢”意味着什么？１）找到了双方赢的条件。
２）合适的折衷。
（在满足利益相关者要求的同时，反映软件团队所处真实世界的限制，如时间、人员，预算）３）后续开展软件活动的关键。
JUNIT,SVN, Maven,RedMine分别是什么工具，完成什么功能？这四个工具都是软件工程辅助工具。
JUNIT是单元测试工具、SVN是版本管理工具，Maven 是构建工具，Redmine是项目管理与变更管理工具。
1）JUnit是基于面向对象构建的java单元测试框架。
JUnit是开放源代码项目。
使用这个工具可以快速构建测试用例。
可以和Maven等构建工具集成，在持续集成过程中不断进行测试。
2）svn(subversion)是一个版本管理工具。
与GITHubGit这种分布式版本管理工具不同，这是集中式代码管理工具。
SVN的核心是服务器，所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突，提交。
所有的版本信息都放在服务器上。
SVN支持分支与合并，支持标签管理等。
3）Maven 是一个构建工具，可以通过撰写配置文件，自动构建一个项目。
构建过程包括从服务器上checkout出源代码，编译、运行单元测试、生成文档、打包和部署等工作，在maven的帮助下，这些工作可以自动进行。
另外，maven还有依赖管理、自动生成项目站点等特性。
４）redmine Redmine是用Ruby开发的基于web的项目管理软件。
这种 Web 形式的项目管理系统通过“项目（Project）”的形式把成员、任务（问题）、文档、讨论以及各种形式的资源组织在一起，大家参与更新任务、文档等内容来推动项目的进度，同时系统利用时间线索和各种动态的报表形式来自动给成员汇报项目进度。
另外，软件还提供wiki、新闻台等，也可以集成其他版本管理系统和BUG跟踪系统，例如SVN、CVS、TD等等。
6.6 PHTRS的用例图与类模型类包含：坑洼/上报人／工单/维护人员/维护设备/维护材料等等注意到这几个之间的关联，上报人和坑洼的关系，工单和其他所有类的关系。
等等。
6.8 与类图相关。
7.1 结构化分析与面向对象分析的本质区别。
答：结构化分析的核心是“处理”，而面向对象分析的核心是“对象／类”。
前者以“计算”为核心，而后者以“结构”为核心7.5 什么是控制规格说明？答：控制规格说明使用两种不同的方式表现系统的行为，１）一个状态图，是行为的序列说明。
２）程序激活表，即行为的组合说明，或者说是当有事件发生时，会引入流程模型的哪个处理。
7.6 PSPEC和用例是同一事物吗？如果不是，请解释区别。
答：不是。
处理规格说明用于描述出现在求精过程中最终层次的所有流程模型的处理，通常是在详细设计的时候用到，是系统某个功能的具体实现方法。
而用例描述了一个用户如何使用系统的，并不涉及到系统的内部的行为，通常在需求分析阶段用到。
7.8 如何从状态图区分顺序图它们有何相似之处答：状态图描述一个对象状态的变迁，而顺序图描述几个对象之间交互的顺序。
对象状态的变迁，通常是由事件激发的，这个事件和顺序图当中的消息有关。
可以由多个对象的状态图，组合成多个对象交互组成的序列图。
9.1 用一个房屋或建筑物的结构做比喻，与软件体系结构做对照分析。
经典建筑与软件体系结构的原则有什么相似之处？又有何区别？答：建筑物也是由各种部件通过不同方式搭建而成。
如不同的房子都有墙、顶、地基等等，搭建方法的不同构成了不同风格的房子。
软件体系结构也一样，不同的部件通过不同的方式的组装，形成了不同的软件系统。
不同点：1）一个比较实际，一个比较抽象。
2）房屋或建筑物可变化的空间比较小，软件体系结构变化跨度更大一点。
9.2 举出一两个例子，说明９.3.1节中提到的每一种体系结构的应用。
答：1）以数据为中心的体系结构以数据库为核心的企业信息系统2）层次体系结构 OSI, MVC3）调用/返回体系结构远程消息调用（RPC），科学计算。
4）数据流体系结构编译器9.3 9.3.1节中提到的一些体系结构风格具有层次性，而另外一些则没有。
列出每种类型。
没有层次的体系结构风格如何实现？答：很难绝对地说那些体系结构没有层次。
1）层析性体系结构肯定有层次。
2）调用/返回的话，有主程序，也有1层调用，2层调用。
层次不明显的：1）以数据为中心的体系结构，通过所有软件访问公共的数据库实现数据共享。
2）面向对象体系结构，通过将对象组装成模块，体现某种层次。
3）数据流体系结构，数据可以通过管道，流到更细的管道里去。
9.6 研究ATAM，并对9.5.1节提出的６个步骤进行详细讨论。
此题目暂时不批。
10.3 OCP原则的核心是容易扩充，但是不需要修改已有代码。
（对外延具有开放性，对修改具有封闭性）代码如：探测器类读取不同的Sensor，用interface 定义Sensor，然后HeatSensor实现之，如果想扩充一种Sensor，则直接实现Sensor接口，Detector不需要修改。
//Detector Sensorpublic class Detector {Sensor sensor;public Detector(Sensor sensor){this.sensor =sensor;}public void detectSensor(Sensor sensor){System.out.println(sensor.read());}}//Sensor 接口public interface Sensor {public String read();}／/HeatSensorpublic class HeatSensor implements Sensor{public String read(){return"heatSensor";}}//扩充一个Sensorpublic class SmokeSensor implements Sensor {public String read(){return"smoke";}}10.4 DIP含义是：1、上层不应该依赖于下层模块，二者都应该依赖于抽象。
2、抽象不应该依赖于细节,细节应该依赖于抽象。
如果如果以电灯为例子，开关可以打开电灯。
如果开关直接调用电灯，那么，当（和OCP的例子中有所不同，如果其他物体都继承电灯，也满足OCP原则，即可以扩充，无需修改代码，而DIP直接指出了依赖于抽象的意义）代码如下：public class Light {public String turnOn(){return"Turn on the light";}public String turnOff(){return"Turn off the light";}}public class Switch {public String Toggle(Light light){return light.turnOn();}}public class Test {public static void main(String argv[]){Switch sw =new Switch();Light light = new Light();System.out.println( sw.Toggle(light));}// 如果将TV作为子类，虽然从程序上可以，但理解不合理。
public class TV extends Light{public String turnOn(){return"Turn on the TV";}public String turnOff(){return"Turn off the TV";}}所以，增加一个接口，叫Switchable10.5 选择3个你最近开发的构件，评估每个构件的内聚类型。
此题目暂时不批。
10.6 选择3个…………………………….，评估每个构件的耦合类型。
此题目暂时不批。
10.7 问题领域构件不会存在外部耦合的说法有道理吗？如果你认为没有道理，那么哪种类型的构件存在着外部耦合没有道理。
例如：1）嵌入式软件应用中的构件，与操作系统耦合2）数据库应用中 POS构建，与数据库耦合。
3）文件传输构件，会和通信功能耦合。
10.8 完成（1）一个细化的设计类；（2）接口描述（3）该类中包含的某一操作的活动图。
