软件工程课后习题答案
软件工程课后题答案
第一章1 简述软件的发展过程。
共经历了四个阶段；第一阶段：（20世纪50年代初期到60年代初期的十余年）计算机系统开发的初期。
第二阶段：（20世纪60年代中期到70年代中期的十余年）软件产品和“软件作坊”的概念开始出现。
软件开发人员不再像早期阶段那样只因个人工作需要而开发，而是为了用户更好地使用计算机。
第三阶段：（20世纪70年代中期到80年代末期）分布式系统嵌入“智能”；硬件价格下降，软件价格急剧上升，导致了软件危机的加剧。
第四阶段：（20世纪80年代末期开始）强大的桌面系统和计算机网络迅速发展。
2 简述软件的定义和特点。
定义：软件是计算机程序、规程以及运行计算机系统可能需要的相关文档和数据。
特点：(1)是一种逻辑实体，具有抽象性；(2)软件的生产不存在明显的制造过程；(3)在软件的运行和使用的过程中，不会存在像硬件那样的机械磨损及老化问题；(4)由于对计算机系统的依赖性，对软件的通用性造成了一定的影响；(5)软件的开发方式还没有完全脱离手工开发方式，还不能完全采用组装的方式进行软件开发；(6)作为提高工作效率的逻辑产品，本身具有复杂性；(7)成本相当昂贵；(8)相当多的软件工作设计社会因素。
3 软件有哪些种类1. 按功能特征进行划分(1)系统软件。
(2)支撑软件。
(3)应用软件2. 按规模大小进行划分微型、小型、中型、大型、甚大型、、极大型4 什么是软件危机?答：是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
5 什么是软件工程?有哪些本质特性？怎样用软件工程消除软件危机？答：是指导计算机软件开发和维护的一门工程学科。
特性略。
技术措施和管理措施消除软件危机。
6 软件工程的三要素；方法、工具和过程。
7. 结合自己的亲身经历，谈谈软件工具在软件开发过程中的作用。
使软件开发更加模式化，工程化，从而提高软件开发的效率和封装性。
8. CASE 的研究和CASE 产品的开发是近年来软件工程领域的特点之一。
软件工程课后习题参考答案
软件工程课后习题参考答案软件工程课后习题参考答案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、喷泉模型是一种以需求分析为动力，以对象为驱动的模型。
4、需求分析阶段，分析人员要确定对问题的综合需求，其中最主要的是功能需求。
5、可行性研究需要从以下三个方面分析研究每种解决方法的可行性：技术可行性、经济可行性、社会可行性。
6、可行性研究的目的不是去开发一个软件项目，而是研究这个软件项目是否值得开发，其中的问题能否解决。
7、判定树较判定表直观易读，判定表进行逻辑验证较严格，能把所有的可能性全部都考虑到。
可将两种工具结合起来，先用判定表做底稿，在此基础上产生判定树。
8、软件工具的发展特点是软件工具有单一工具向多个工具集成化方向发展。
重视用户界面的设计，不断的采用新理论和新技术。
软件工具的商品化推动了软件产业的发展，而软件产业的发展，又增加了对软件工具的需求，促进了软件工具的商品化进程。
9、环境集成主要有数据集成、界面集成、控制集成、平台集成、过程集成。
10、可行性研究实质上是进行一项简化、压缩了的需求分析、设计过程。
11、结构化方法有结构化分析、结构化设计、结构化程序设计构成，它是一种面向数据流的开发方法。
12、投资回收期就是累计的经济效益等于最初的项目投资所需的时间。
13、详细描述处理过程常用三种描述工具：图形、表格和语言。
14、数据流图中，每个加工至少有一个输入流和一个输出流。
15、结构化设计以数据流为基础映射成软件结构。
16、当数据流图中某个加工的一组动作存在着多个条件复杂组合的判断时，使用判定表或判定树较好。
17、由于运用原型的目的和方式不同，在使用原型时也采取不同的策略，有抛弃策略和附加策略。
18、有两类维护技术：在开发阶段是用来减少错误、提高软件可维护性面向维护的技术，在维护阶段用来提高维护的效率和质量的维护支援技术。
软件工程课后习题答案
软件⼯程课后习题答案习题答案习题⼀答案⼀、选择题1. 软件的主要特性是(A B C)。
A) ⽆形 B) ⾼成本C) 包括程序和⽂档D) 可独⽴构成计算机系统2. 软件⼯程三要素是(C D)。
A) 技术、⽅法和⼯具B) ⽅法、⼯具和过程C) ⽅法、对象和类D) 过程、模型、⽅法3. 包含风险分析的软件⼯程模型是(A)。
A) 螺旋模型 B) 瀑布模型C) 增量模型 D) 喷泉模型4. 软件⼯程的主要⽬标是(C)。
A) 软件需求B) 软件设计C) 风险分析D) 软件实现5. 下列属于⾯向对象开发⽅法的是(A B C D)。
A) Booch B) UML C) Coad D) OMT6. 软件危机的主要表现是(B D)。
A) 软件成本太⾼B) 软件产品的质量低劣C) 软件开发⼈员明显不⾜D) 软件⽣产率低下7. 软件开发⽅法的主要⼯作模型有(A B C)A) 螺旋模型B) 循环模型C) 瀑布模型D) 专家模型8. 软件⼯程的⽬标有(A B C)。
A) 易于维护B) 低的开发成本C) ⾼性能D) 短的开发期9. 软件⼯程学的⽬的和意义是( )。
A) 应⽤科学的⽅法和⼯程化的规范管理来指导软件开发B) 克服软件危机C) 作好软件开发的培训⼯作D) 以较低的成本开发出⾼质量的软件⼆、判断题1. 软件就是程序，编写软件就是编写程序。
(×)2. 瀑布模型的最⼤优点是将软件开发的各个阶段划分得⼗分清晰。
(×)3. 结构化⽅法的⼯作模型是使⽤螺旋模型进⾏开发。
(×)4. 结构化⽅法和JSP⽅法都不适合于⼤型软件的开发。
(√)5. 原型化开发⽅法包括⽣成原型和实现原型两个步骤。
(×)6. ⾯向对象的开发⽅法包括⾯向对象的分析、⾯向对象的设计和⾯向对象的程序设计。
( √)7. 软件危机的主要表现是软件的需求量迅速增加，软件价格上升。
(×)8. 软件⼯具的作⽤是为了延长软件产品的寿命。
软件工程课后习题(含答案)
第一章练习题一、填空题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-1 什么是软件危机?它有哪些典型表现?为什么会出现软件危机?答:软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
概括地说，软件危机包含下述两方面的问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。
软件危机典型表现：对软件开发成本和进度的估计常常很不准确。
用户对“已完成的”软件系统不满意的现象经常发生。
软件产品的质量往往靠不住。
软件常常是不可维护的。
软件通常没有适当的文档资料。
软件成本在计算机系统总成本中所占的比例逐年上升。
软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
产生软件危机的原因：一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。
软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。
管理和控制软件开发过程相当困难。
软件是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
目前相当多的软件专业人员对软件开发和维护还有不省糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这是使软件问题发展成软件危机的主要原因。
1-2 假设你是一家软件公司的总工程师，当你把图1.1给手下的软件工程师们观看，告诉他们及早发现并改正错误的重要性时，有人不同意你的观点，认为要求在错误进入软件之前就清除它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢?”你怎么反驳他?1-3 什么是软件工程?它有哪些本质特性?怎样用软件工程消除软件危机?答:软件工程是指导计算机软件开发和维护的一门工程学科。
采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它。
软件工程本质特性：1、软件工程关注于大型程序的构造；2、软件工程的中心课题是控制复杂性；3、软件经常变化；4、开发软件的效率非常重要；5、和谐地合作是开发软件的关键；6、软件必须有效地支持它的用户；7、在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品。
软件工程课后习题参考答案
软件工程课后习题参考答案软件工程课后习题参考答案1.简答题1.1 什么是软件工程？软件工程是一门研究和应用如何以系统化、规范化、可量化的方式开发和维护软件的学科，涉及到软件的设计、构建、测试、部署和维护等全生命周期的过程。
1.2 软件工程的目标是什么？软件工程的目标是提高软件开发过程的效率和质量，确保软件项目按时、按需求交付，并且能够满足用户的期望。
1.3 软件生命周期有哪些阶段？常见的软件生命周期包括需求分析、系统设计、详细设计、编码、测试、部署和维护等阶段。
1.4 什么是软件需求？软件需求是指对于软件系统所需满足的问题或需求的描述，包括功能需求、性能需求、接口需求等。
1.5 软件开发过程有哪些模型？常见的软件开发过程模型包括瀑布模型、迭代模型、螺旋模型、敏捷开发等。
2.客观题2.1 软件测试的目的是什么？a) 发现软件中的错误和缺陷b) 验证软件是否符合需求和规格c) 提高软件的可靠性和质量d) 以上皆是答案：d) 以上皆是2.2 瀑布模型的特点是什么？a) 瀑布模型是一种线性顺序的软件开发过程模型b) 各个开发阶段是相互独立的c) 开发过程按照需求分析、设计、编码、测试等顺序进行d) 以上皆是答案：d) 以上皆是2.3 敏捷开发的原则是什么？a) 个体和交互胜过流程和工具b) 可工作的软件胜过详尽的文档c) 客户合作胜过合同谈判d) 响应变化胜过遵循计划e) 以上皆是答案：e) 以上皆是3.计算题3.1 请计算以下代码的覆盖率：（假设代码行数为100行，已执行代码行数为80行）覆盖率 = 已执行代码行数 / 代码行数 100% = 80 / 100 100% = 80%3.2 请计算以下缺陷密度的值：（假设代码行数为1000行，代码中的缺陷数为10个）缺陷密度 = 缺陷数 / 代码行数 1000 = 10 / 1000 1000 = 103.3 请计算以下代码的复杂度：（假设代码中包含的判断语句有20个，循环语句有5个）复杂度 = 判断语句数 2 + 循环语句数 3 = 20 2 + 5 3 = 40 + 15 = 554.附件本文档涉及附件：无5.法律名词及注释本文涉及的法律名词及注释：无。
软件工程课后题答案大全(详细)
软件工程习题解答第一章概述1.软件产品的特性是什么？a.软件产品是一种逻辑产品。
b.软件产品的生产主是研制，软件产品的成本主要体现在软件的开发和研制上，软件开发完成后，复制就产生了大量软件产品。
c.软件产品不会用坏，不存在磨损、消耗问题。
d.软件产品的生产主要是脑力劳动，还未完全摆脱手工开发方式，而且碰分是"定做"的。
e.软件费用不断增加，成本相当昂贵。
2.软件产品有几个阶段？各有何特征？阶段 A.程序设计时代(1946-1956) B.程序系统时代（1956-1968） C.软件工程时代（1968-今）生产方式个体手工劳动作坊式小集团合作生产工程化的生产工具机器语言、汇编高级语言数据库、开发工具、开发环境、网络、分布式、面向对象技术开发方法追求编和技巧，追求程序运行效率个人技巧，开始提出结构化方法硬件特征价格贵、存储容量小、运行可靠性差速度、容量、工作可靠性有明显提高，价格降低，销售有爆炸性增长向超高速、大容量、微型化以及网络化方软件特征只有程序、程序设计概念，不重视程序设计方法程序员数量猛增，已意识到软件开发的重要性，开发技术没有新的突破，大量软件开发的需求已提出，开发人员的素质和工程兵的开发技术不适应规模大、结构复杂的软件开发，产生了尖锐矛盾，导致软件危机的产生开发技术有很大进步，但未能获得突破性进展，软件价格不断上升，没有完全摆脱软件危机3.什么是软件危机？其产生的原因是什么？软件危机：软件发展第二阶段的末期，由于计算机硬件技术的进步。
一些复杂的、大型的软件开发项目提出来了，但，软件开发技术的进步一直未能满足发展的要求。
在软件开发中遇到的问题找不到解决的办法，使问题积累起来，形成了尖锐的矛盾，因而导致了软件危机。
主要表现在以下几个方面：a.经费预算经常突破，完成时间一再拖延。
b.开发的软件不通满足用户要求。
c.开发的软件可维护性差。
d. 开发的软件可靠性差。
软件危机产生的原因是由于软件产品本身的特点以及开发软件的方式、方法、技术和人员引起的：a.软件的规模越来越大，结构越来越复杂。
软件工程课后题答案
软件工程课后题答案1. 简答题1.1 软件过程模型软件过程模型是一种描述软件开发过程中活动、任务和工作产品之间关系的抽象模型。
常见的软件过程模型包括瀑布模型、迭代模型、增量模型和敏捷开发模型等。
每种模型都有其适用的场景和特点。
1.2 软件需求软件需求是指用户对软件系统的功能、性能等方面的要求和约束。
需求分析是软件开发过程中非常重要的一步，它包括需求获取、需求分析、需求规格说明等活动。
需求分析的目标是理解用户需求，为软件开发提供指导。
1.3 需求规格说明需求规格说明是对软件需求进行详细描述和说明的文档。
它包括功能需求、性能需求、界面需求以及其他约束条件等。
需求规格说明的编写要求准确、清晰、可验证，并且要与用户和开发人员达成一致。
1.4 软件设计原则软件设计原则是指在软件设计过程中应该遵循的一些基本原则，以提高软件系统的可维护性、可扩展性和可重用性。
常见的软件设计原则包括单一职责原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则和迪米特法则等。
2.1 敏捷开发方法敏捷开发是一种迭代、逐步开发软件的方法。
它强调快速响应用户需求的变化，通过频繁发布可用的软件版本来获得反馈，并根据反馈进行调整。
敏捷开发方法更加灵活，适用于需求变化频繁的项目。
2.2 结构化程序设计结构化程序设计是一种通过模块化和流程控制来组织程序的方法。
它强调程序应该具有清晰的结构，模块之间的耦合度应该尽量低。
结构化程序设计可以提高程序的可读性和可维护性，减少错误引入的可能性。
2.3 UML建模UML是一种用于面向对象系统开发的建模语言。
它提供了一套丰富的图形符号和建模工具，用于描述系统的结构、行为和交互。
UML建模可以帮助开发人员清晰地表达设计意图，提高沟通效率，并且可以生成可执行代码。
2.4 软件测试技术软件测试是评估软件质量的过程，旨在发现软件中的缺陷和错误。
常见的软件测试技术包括黑盒测试和白盒测试。
黑盒测试关注软件功能是否符合需求，白盒测试则关注程序内部的逻辑结构和代码覆盖率。
软件工程习题及课后答案
第8章面向对象设计（习题与参考答案）［选择题］1. （）面向对象设计是在分析模型的基础上，运用面向对象技术生成软件实现环境下的设计模型。
A. 真B. 假2. （）系统设计的主要任务是细化分析模型，最终形成系统的设计模型。
A. 真B. 假3. （）关系数据库可以完全支持面向对象的概念，面向对象设计中的类可以直接对应到关系数据库中的表。
A. 真B. 假4. （）用户界面设计对于一个系统的成功是至关重要的，一个设计得很差的用户界面可能导致用户拒绝使用该系统。
A. 真B. 假5. 内聚表示一个模块（）的程度，耦合表示一个模块（）的程度。
A. 可以被更加细化B. 仅关注在一件事情上C. 能够适时地完成其功能D. 联接其他模块和外部世界6. 良好设计的特征是（）。
A. 模块之间呈现高耦合B. 实现分析模型中的所有需求C. 包括所有组件的测试用例D. 提供软件的完整描述E. 选项B和DF. 选项B、C和D7. （）是选择合适的解决方案策略，并将系统划分成若干子系统，从而建立整个系统的体系结构；（ ）细化原有的分析对象，确定一些新的对象、对每一个子系统接口和类进行准确详细的说明。
A. 系统设计B. 对象设计C. 数据库设计D.用户界面设计8.下面的（ ）界面设计原则不允许用户保持对计算机交互的控制。
A. 允许交互中断B. 允许交互操作取消C. 对临时用户隐藏技术内部信息D.只提供一种规定的方法完成任务［练习题］1. 面向对象设计与面向对象分析的区别是什么？设计包括哪些活动？ 答案要点：面向对象分析是重点考虑系统“做什么”的问题，即运用面向对象方法对问题域进行分析和理解，建立系统的分析模型；面向对象设计重点考虑系统“怎样做”的问题，即在分析模型的基础上形成实现环境下的设计模型。
面向对象设计主要涉及系统设计、对象设计（或详细设计）、数据库设计和用户界面设计等活动。
2. 3. 课程在类设计中，为什么建议使用set 方法和get 方法进行属性设置和读取？ 答案要点：目的在于降低类之间的耦合度。
软件工程课后练习答案
第一章软件工程概述软件工程的基本原则是什么？1，抽象：采用分层次抽象，自顶向下逐层细化的办法控制软件开发过程的复杂性。
2，模块化：模块化有助于信息隐蔽和抽象，有助于表示复杂的系统。
3，信息隐蔽：将模块化设计成“黑箱”，实现的细节隐蔽在模块内部，不让模块的使用直接访问，这就是信息封装。
4，局部化：保证模块之间具有松散的耦合，模块内部具有较强的内聚，这有助于控制模块的复杂性5，一致性：整个软件系统使用一致的概念符号和术语。
6，完整性：软件系统不丢失任何重要成分，可以完全实现系统所要求功能的程度。
7，不可验证性：易于检查、测试、评审，确保系统的正确性。
第二章可行性研究选择题1，研究开发所需要的成本和资源属于可行性研究中(经济可行性)研究的一方面。
2，可行性分析研究的目的是(项目值得开发与否)。
3，软件分析的第一步要做的工作在于(分析系统开发的可行性)。
4，可行性研究目的主要在于(用最小的代价确定问题定义阶段所确定的目标和规模是否可实现，可解决)。
5，软件可行性分析是着重确定系统的目标和规模。
对功能，性能及约束条件的分析应属于下列(技术可行性分析)。
简答题简述可行性研究的步骤？1，复查系统规模和目标2，研究目前正在使用的系统3，导出新系统的高层逻辑模型4，重新定义问题5，导出和评价供选择方案6，推荐一个方案并说明理由7，推荐行动方针8，书写计划任务书9，提交审查应用题设计一个软件的开发成本为5万元，寿命为3年。
未来3年的每年收益预计为22000元，24000元，26620元，银行年利率为10%。
试对此项目进行成本效益分析，以决定其经济可行性。
答：设银行的年利率是10%，则下列出每年的收益第一年：22000/1.1=20000第二年：24000/1.21=19834.71第三年：26620/1.331=20000因此：现有值收益为20000+19834.71+20000=59834.71投资回收期2+10165/20000=2.51纯收入59835-50000=9834.71第三章需求分析需求分析的原则有哪些？1.需求分析方法应该容易被用户理解。
软件工程课后习题参考答案
软件工程课后习题参考答案软件工程课后习题参考答案1·软件工程概述1·1 软件工程的定义和特点软件工程是一门研究和应用如何以系统化、规范化、可量化的方法开发和维护软件的学科。
其特点包括软件开发的目标性、可度量性、可管理性和可预测性。
1·2 软件生命周期模型常见的软件生命周期模型包括瀑布模型、迭代模型、螺旋模型和敏捷模型等。
每个生命周期模型都有其适用的场景和优缺点。
2·软件需求工程2·1 软件需求获取软件需求获取方法包括面谈、问卷调查、用户场景模拟等。
需求获取的目的是明确软件系统的功能、性能和约束条件。
2·2 软件需求分析与规格说明软件需求分析的目标是识别和定义系统的需求，包括功能需求、非功能需求和约束条件。
规格说明是将需求转化为精确、清晰和易于验证的文档。
3·软件设计3·1 结构化设计结构化设计将系统分解为模块，确定模块之间的接口和关系，实现模块化、高内聚、低耦合的设计原则。
3·2 面向对象设计面向对象设计将系统抽象为对象，定义对象的属性和方法，并确定对象之间的关系。
常用的面向对象设计方法有UML（统一建模语言）。
4·软件测试4·1 测试基本概念软件测试是通过运行软件来发现错误和缺陷的过程。
测试的基本概念包括测试用例、测试套件、测试目标和测试覆盖度等。
4·2 测试方法和技术常见的软件测试方法和技术有黑盒测试、白盒测试、灰盒测试、单元测试、集成测试和系统测试等。
每种方法和技术都有其适用的场景和优缺点。
5·软件维护与配置管理5·1 软件维护软件维护是指对已有的软件进行修改、优化、修复错误和适应环境变化的过程。
维护活动包括需求分析、设计、实现、测试和文档更新等。
5·2 软件配置管理软件配置管理是指在软件开发和维护过程中，对软件配置项进行识别、控制、追踪和审查，确保软件可以按需发布、升级和回溯。
软件工程答案（共五则范文）
软件工程答案（共五则范文）第一篇：软件工程答案软件工程课后习题答案殷锋主编·天津科学技术出版社注：有些可能错误，读者自己注意第一章一、填空题：1、软件是计算机系统中与硬件相互依存的另一部分，是包括、、及相关文档的的完整集合2、软件工程包括三要素：方法、工具和过程。
3、软件开发的基本方法包括和二、选择题：1、C2、B3、C第二章一、填空题：1、软件生存周期的各个过程可以分成三类，及主要生存周期过程、支持生存周期过程和组织的生存周期过程。
2、软件生存周期包括计划、需求分析、设计、程序编码、软件测试和运行维护6个阶段。
3、软件过程改进（SPI）帮助软件企业对其软件过程的改变进行计划，制定以及实施。
二、填空题1、A2、B三、判断题1、√2、X第三章三、填空题：1、可行性研究的目的是用最小的代价，在尽可能短的时间内，确定够解决2、可行性研究在进行简要需求分析和设计时，要在高层次上以进行3、需求分析阶段产生的最重要的文档是。
4、为解决一个复杂的问题，往往采取的策略是5、SA方法中使用半形式化的描述方式表达需求，采用的主要描述工具是流图和E-R图。
6、数据流图中有四种负号元素，它们是点7、数据字典中有四类条目，分别是8、在IDEF0图中，表示系统功能的图形成为图。
9、在画分层的DFD时，父图与子图的输入/输出的数据流要10、用于描述基本加工的小说明的三种描述工具是定表。
二、选择题1、A2、C3、B4、B5、D6、D7、D8、A9、D10、A11、C12、B第四章一、填空题1、变换型系统由3部分组成：。
2、模块的分解的基本原则是。
3、在软件开发的过程中必须遵循的软件工程原则有：和模块独立性。
二、选择题1、D2、A3、A4、A5、B三、判断题1、√2、X3、X4、√5、X第五章二、填空题1、软件测试是为了而执行程序的过程。
2、运行被测程序的方法称为测试。
3、动态测试中，主要测试软件功能的方法称为法4、选择测试用例，使得被测程序中每个判定的每个分支至少执行一次，这种逻辑覆盖标准为判定/覆盖法。
软件工程课后习题参考答案
软件工程课后习题参考答案1.简述软件开发的本质答: 软件开发的本质就是实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射。
P192.简述实施软件开发的基本途径。
答: 实施软件开发的基本途径是系统建模。
所谓系统建模，是指运用所掌握的知识，通过抽象，给出该系统的一个结构——系统模型。
P193.简述何谓模型以及软件开发中所涉及的模型。
答: 模型是一个抽象。
该抽象是在意图所确定的角度和抽象层次对物理系统的一个描述，描述其中的成分和成分之间所具有的特定语义的关系，还包括对该系统边界的描述。
软件开发中所涉及的模型可分为两大类，一类称为概念模型，描述了系统是什么；另一类统称为软件模型，描述了实现概念模型的软件解决方案。
4.简述软件开发所涉及的两大类技术。
答: 软件开发所涉及的两大类技术为: 一是求解软件的开发逻辑，二是求解软件的开发手段。
5、简述需求与需求规约的基本性质。
答:需求的基本性质:1) 必要的，该需求是用户所要求的。
2) 无歧义的，该需求只能用一种方式解释。
3) 可测的，该需求是可进行测试的。
4) 可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段。
5) 可测量的，该需求是可测量的。
需求规约的基本性质:1) 重要性和稳定性程度: 按需求的重要性和稳定性，对需求进行分级。
2) 可修改的: 在不过多地影响其他需求的前提下，可以容易地修改一个单一需求。
3）完整的:没有被遗漏的需求。
4）一致的:不存在互斥的需求。
6、简述软件需求的分类答:软件需求可以分为两大类:一类是功能需求，一类是非公能需求，而非公能需求可分为性能需求，外部接口需求、功能需求7、举例说明功能需求和非功能需求之间的基本关系。
答:非功能需求可作用于一个或多个功能需求，例如非功能需求可作用于一个或多个功能需求其中，非功能需求1作用于功能需求1和功能需求3等；非功能需求2作用于功能需求2等。
P248、有哪几种常用的初始需求发现技术?答:有5种常用的需求发现技术：自悟、交谈、观察、小组会和提炼。
软件工程课后习题答案
软件工程课后习题答案Chapter11.1)The definition for software presented in Section 1.2 applies to the Web sites. There are, however, subtledifferences between a Web site and conventional software. Among the most important are that the content that a Web site presents is considered to be part of the Web Application while that data processed by conventional software is often considered to be separate from the processing functions delivered.1.4)Who would have thought that software would lead to: (1) a change in the dating habits of many youngpeople (Internet dating); (2) the way people municate (cell phones); (3) methods of warfare (cyberweapons); (4) the diagnosis of diseases (MRIs and related puter-based diagnostic devices), and (5) the manner in which people acquire and enjoy media (music, DVDs, etc.).1.6)The Law of Conservation of Familiarity: As the system evolves the users engineers, developers all thoseassociated must have the plete knowledge of the content and behavior to achieve satisfactory results.Increase in growth may diminish that knowledge (mastery); hence the average increase in growth remains invariant as the system evolves.1.7)Many modern applications change frequently before they are presented to the end user and then after thefirst versions have been used. A few ways to build software to stop deterioration due to change would be: •Make sure that software is designed so that changes in one part of a program do not create side-effects in another part of the program.•Make sure that software is designed so that it does not depend on external devices or systems that are likely to change with time.•Make sure test cases and results are archived and available so that the software can be retested when changes are made.•Make sure you spend time understanding what the customer wants.1.8)The two broadest categories enpass risks associated with economic loss and risks to the well being ofpeople. It might be a good idea to select five risks (culled from the sources noted) and present them to the class. Look for humorous as well as serious risks.1.9)The same approach to software engineering can be applied for each of the six categories, but it must beadapted to acmodate the special requirements of each category.1.10)There are literally dozens of real life circumstances to choose from. For example, software errors thathave caused major telephone networks to fail, failures in avionics that have contributed to plane crashes, puter viruses (e.g., Michelangelo) that have caused significant economic losses and attacks on major e-merce sites.1.11)The Law of Declining Quality: The quality of systems will decline unless they are maintained by variousprocedures to adapt to the environmental changes. This concept is similar to the “deterioration”discussed in Problem 1-5.1.12)The Law of Conservation of Organizational Stability: The average effective global activity rate isinvariant over the lifetime of a product.Chapter 22.1)2.2) Process assessment examines the software process used by an organization to determine whether it iseffective in achieving software engineering goals. The assessment characterizes the current practicewithin an organizational unit in terms of the capability of the selected processes. The SPICE(ISO/IEC15504) standard defines a set of requirements for software process assessment. To acplish theassessment, SPICE specifies a “reference model” that examines the purpose and measurable objectivesof the process (the “process dimension”) and the set of process att ributes that should be present (the“capability dimension”).2.4) Task Set for munication Activity: A task set would define the actual work to be done to acplish theobjectives of a software engineering action. For the munication activity these are:1.Make a list of stakeholders for the project2.Invite all the stakeholders to an informal meeting3.Ask them to make a list of features and functions4.Discuss requirements and build a final list5.Prioritize requirements and note the areas that stakeholders are uncertain ofThese tasks may be expanded for a plex software project, they may then consider the following: •To conduct a series of specification meetings, build a preliminary list of functions and features based on stakeholder input.•To build a revised list of stake holder requirements use quality function deployment techniques to priotize the requirements.•Note constraints and restrictions on the system.•Discuss methods for validating system.2.5) The CMMI represents a process metamodel in 2 different ways—the continuous and the staged model.The pros of the CMMI: prehensive, addressing virtually every aspect of process; well-organized; adopted widely. The cons: voluminous; overkill for many types of projects; agility is questionable. Although the spirit of the CMMI should always be adopted, each process must be adapted to meet the needs of the project team and to achieve high quality in the end product. The requirements of the CMMI should be applied to all process models, but failure to meet a specific criterion should not necessarily mean that the process is “bad.” It may be that the CMMI is right in situations in which an organizational culture is amendable to the standard process models and management is mitted to making it a success. However it may be too much for an organization to successfully assimilate. This means that CMMI which is right for one pany culture may not be right for another.2.6) Process framework is applicable to all the projects; hence the same framework activities are applied forall projects, regardless of the project’s size or plexity. A process framework involves heavy munication with the customer to gather requirements; this activity establishes a plan for the software engineering work that follows. It involves creation of models that will assist the developer and the customer to understand the requirements and design them; it thereby involves construction (code generation and error testing). It finally provides feedback based on the evaluation.2.7) Umbrella activities occur throughout the software process but they are not necessarily applied evenlyacross the process. For example, there is a heavy concentration on risk analysis during project planning, and risk analysis is then revisited during later framework activities, but it is not applied evenly during these activities. On theother hand, SQA is applied fairly evenly for all process activities.2.8) The support phase is applied differently for embedded software. In most cases, embedded software isdefined and developed, but once it is placed in its host environment, it is not likely to change until a new release of the product occurs.2.9)a)Designers should ask users:•What do you want this product to acplish?•What key outputs are produced by the software?•What functions and features are you looking for?•What outputs, functions and features are likely to change over the next 6 months, 1 year.•Are there any questions that I should have asks that I didn’t?•How will you determine if what we built is what you wanted?b)Users should ask as designers:•Have I made my needs clear to you?•Do we have the tools and people with skills required for the development?•Are the requirements properly defined, are additional requirements needed.•Are the product features and functions achievable in the allotted time?•Have you talked to other classes of users?c)Users should ask themselves about the software product that is to be built:•Have I asked for more than I’ll really need?•Have I set deadlines that are unrealistic?•Am I unsure of certain functions and features?•Would a prototype be helpful for certain functions and features?•Am I mitted to work with the software designers over the long haul?d)Designers should ask themselves about software product that is to be built and the process that will usedto build it:•Do I understand the scope and purpose of the software?•Do I understand the design issues and constraints?•What tools are to be used?•Do I understand the technology and business area that the software is to address?•Have we established quality criteria that can be used to judge our work?2.11) Scripts define specific process activities (i.e., project launch, design, implementation, integration andsystem testing, postmortem) and other more detailed work functions (e.g., development planning, requirements development, software configuration management, and unit test) that are part of the team process. Scripts maybe beneficial when a team need guidance in planning and tracking its work, establishing goals, and defining effective task sets for technical activities. For experienced teams, however, the script may preclude “on-the-fly” adaptation that is often necessary in agile environments. 2.12) The Personal Software Process (PSP) emphasizes personal measurement of both the work product thatis produced and the resultant quality of the work product. The PSP process model defines fiveframework activities: planning, high-level design, high-level design review, development, andpostmortem. In addition PSP makes the practitioner responsible for project planning (e.g.,estimating and scheduling) and empowers the practitioner to control the quality of all software workproducts that are developed.Chapter 33.1) Any software project that has significant functionality that must be delivered in a very tight (too tight)time frame is a candidate for the incremental approach. The idea is to deliver functionality in increments.Example: a sophisticated software product that can be released to the marketplace with only partial functionality—new and improved versions to follow! For example, word-processing software developed using the incremental paradigm might deliver basic file management, editing and document production functions in the first increment; more sophisticated editing and document production capabilities in the second increment; spelling and grammar checking in the third increment, and advanced page layout capability in the fourth increment. The process flow for any increment may incorporate the prototyping paradigm. Incremental development is particularly useful when staffing is unavailable for a plete implementation by the business deadline that has been established for the project.3.2) The waterfall model is appropriate for projects with the following characteristics: (1) the problem is wellunderstood (requirements are well-defined); (2) the delivery date is realistic; (3) it’s unlikely that majorchanges in requirements will be requested as the project proceeds. Specific examples might be: (1) a well understood modification to an existing program; (2) a straightforward implementation of a numericalcalculation or business rule, even if it’s plex; (3) a constrained enhancement to an existing program.3.3) If the plan is to have a prototype evolve into a delivered application, more rigorous design rules andSQA procedures must be applied from the beginning. In addition, the prototype must be designed withextensibility in mind and must be implemented using a programming environment that is amenable toproduction system development. Initially, the prototype serves as a mechanism for identifying softwarerequirements. Once a working prototype is built, it bees the skeleton (framework) for extensions that will cause it to evolve into a production system.3.4) RAD assumes that a project can be modularized in a manner that allows major functionality to bedelivered within a 60 – 90 day time frame. Although this is often the case, there are situations in whichtimelines are longer. In addition, RAD assumes that sufficient human resources will be available todevelop the increments in parallel. This may not be the case.3.5) Software applications that are relatively easy to prototype almost always involve human-machineinteraction and/or heavy puter graphics. Other applications that are sometimes amenable to prototypingare certain classes of mathematical algorithms, subset of mand driven systems and other applicationswhere results can be easily examined without real-time interaction. Applications that are more difficultto prototype include control and process control functions, many classes of real-time applications andembedded software.3.6) The real question that a paper should address is: How do we develop a process that can acmodate manyof the chaotic attributes of modern software development? The authors suggest processes that are“focused on flexibility and extensibility rather than on high quality” and admit that this approach is“scary.” No doubt! In fact, I believe it is a recipe for disaster. With the exception of certain widely usedPC operating systems (that will remain nameless) quality does appear to be a reasonable harbinger ofsuccessful software. A program that is “flexible and extensible” will not succeed if it fails regularly andbehaves unpredictably. It should be noted that muc h has been written about “good enough” software.That’s OK as long as the word “good” is emphasized.3.7) Process models can be bined. Each model suggests a somewhat different process flow, but allperform the same set of generic framework activities: munication, planning, modeling, construction,and deployment.For example the linear sequential model can serve as a useful process model in situations whererequirements are fixed and work is to proceed to pletion in a linear manner. In cases, where thedeveloper may be unsure of the efficiency of an algorithm, the adaptability of an operating system,or the form that human-machine interaction should take. In these, and many other situations, aprototyping model may offer the best approach. In other cases, an incremental approach may makesense and the flow of Spiral model may be efficient. Special process models take on many of thecharacteristics of one or more of the tradition.3.8) A software engineering workflow is distributed across all UP phases. In the context of UP, a workflow isanalogous to a task set. That is, a workflow identifies the tasks required to acplish an important software engineering action and the work products that are produced as a consequence of successfully pleting the tasks. UP workflow is conducted for every software project, whereas the five UP phases do notnecessarily occur in a sequence, but rather with staggered concurrency. It is likely in the UP that at thesame time the construction, transition, and production phases are being conducted, work may havealready begun on the next software increment.3.9) Stated simply, the concurrent process model assumes that different parts of a project will be differentstages of pleteness, and therefore, different software engineering activities are all being performed concurrently. The challenge is to manage the concurrency and be able to assess the status of the project.3.10) The advantages of developing a software in which quality is” good enough” is that the product orsoftware will meet the deadline, it may however lead to delivery of software that is low in quality and requires time to improve the quality. When speed is emphasized over the product quality, the process may lead to many flaws—the software may require more testing, design and implementation rework. 3.11) It is possible to use mathematical techniques to prove the correctness of software ponents and evenentire programs (see Chapter 28). However, for plex programs this is a very time consumingprocess. It is not possible to prove the correctness of any non-trivial program using exhaustivetesting.3.13) Customer required properties or areas of technical interest often span the entire software architecture.When these properties, referred as “concerns,” cut across mu ltiple system functions, features, andinformation, they are often referred to as “crosscutting concerns.” Aspect-oriented softwaredevelopment, often referred to as aspect-oriented programming (AOP), is a relatively new softwareengineering paradigm that provides a process and methodological approach for defining, specifying,designing, and constructing aspects—“mechanisms beyond subroutines and inheritance forlocalizing the expression of a crosscutting concern.” a3.14) UML provides the necessary technology to support object-oriented (and conventional) softwareengineering practice, but it does not provide the process framework to guide project teams in theirapplication of the technology. The Unified Process is a framework for software engineering usingUML. Today, the Unified Process and UML are used on projects of all kinds. However, they are notthe same thing. UML is a modeling notation and language. UP is a process framework in whichUML may be applied as part of software engineering activities.3.15) As work moves outward on the spiral, the product moves toward a more plete state and the level ofabstraction at which work is performed is reduced (i.e., implementation specific work accelerates as we move further from the origin).Chapter 66.2) You might suggest the following systems: an airport, your university, an on-line bank, a retail store,an e-merce site. As an example consider a university:UniversityAcademic programsDegree granting programs-undergraduateDegree granting programs-undergraduateProfessional educationContinuing educationAdministrative DepartmentsRegistrar ….CoursesFacultyInfrastructure Maintenance …6.4) The data architecture refers to corporate data, its organization, and the relationships betweenindividual corporate data elements. For example, a telephone billing system might draw on elementsthat include customer information, rate tables, calling logs and so forth. Application architecturedefines the functional hierarchy that is required to realize the goals and objectives of a largeinformation system. Technology infrastructure identify the hardware and software backbone (e.g.,client/server, operating system type) that enable the system to function.6.5) There is less likelihood of mismunication when the developer is the system engineer, but there is highlikelihood of "creeping enhancements" and the possibility of building a system that doesn’t meetcustomer’s needs because perceptions of need are incorrect. When the customer is the systemengineer, the likelihood is that technical issues may be omitted, but it is likely that customer need willbe more accurately reflected. When an outside third party is the system engineer, municationbandwidth between developer and customer must be very high. It’s likely that things will fall into thecracks. However, the third party may be an expert, hence better overall quality of the system model.The ideal system engineer is technically expert in system engineering, has full understanding of thecustomer business/product domain, and understands the development environment (and leaps tallbuildings in a single bound!).6.6) Consider the CLSS described in this chapter. Additional questions:•What has been done to acplish this task previously?•Couldn’t sorting occ ur as the boxes were packed?•Is the number of different parts (and boxes) likely to increase or decrease?•Are all boxes the same size and weight?•What is the environment in which this system will sit (e.g., corrosive, high temperature, dusty, etc.)? Allocations: (4) Bar code reader and PC. PC prints destination on screen and a human operator does the placement into the bin; (5) Human reads box and speaks destination into voice recognition systemthat controls and automated shunt.6.7) The assumptions, simplifications, limitations, constraints, and preferences are, of course, dependenton the system that is chosen. In general, assumptions should be kept to a minimum, the higher thenumber of assumptions, the higher the project risk; simplification are worthwhile, but only if they do not change the nature of system functions and features or the data that the system manipulates;limitations are determined as part of requirements gathering and help to bound the system; constraints dictate the design approach, and preferences help to guide design alternatives that are chosen.6.9) Use a large dictionary or thesaurus. mon synonyms: scheme, organization, classification, structure,organism, None are really on the mark.6.10) There are many cases where plete specification is impossible early in a project. In some of these, itis necessary to prototype before a formal specification can be developed. Examples are:•Sophisticated analytical models that must be researched and developed—delay until requirements specification or even design!•Sometimes, specific hardware/software interfaces—delay until requirements, but no later!•Certain performance constraints—delay until requirements, but no later!6.11) The SCD represents how information flows from external sources (entities) into the system itselfand then outward to external sinks (entities). Entities within each of the five functional areasrepresented as part of the SCD (Figure 6.4) should be represented.6.12) In many instances a puter-based system is actually a "software only" system. That is, an existingstandard puter, operating system and I/O environment are to be used. In such cases, the SystemSpecification can be eliminated in lieu of a Software Requirements Specification. There are alsosituations in which a system prototype (either real or paper) is much more effective than aspecification.Chapter 77.2) In reality, the customer and the developer enter into a process of negotiation, where the customermay be asked to balance functionality, performance, and other product or system characteristicsagainst cost and time to market. The intent of this negotiation is to develop a project plan that meetsthe needs of the customer while at the same time reflecting the real-world constraints (e.g., time,people, budget) that have been placed on the software team, Unfortunately, each customer has hisown priorities and views. These views are not necessarily consistent.7.3) Feasibility analysis within the context of the inception function is to identify a working descriptionof the project’s scope and then assess whether the scope can be achieved within the context ofmanagement and technical constraints. In essence, feasibility analysis (during inception) defines abusiness case for an idea and identifies the breadth and depth of the market that the product is toaddress.7.4) You might try using an approach like QFD that makes use customer interviews and observation,surveys, and examination of historical data (e.g., problem reports) as raw data for the requirementsgathering activity. These data are then translated into a table of requirements—called the customervoice table—that is reviewed with the customers later. A variety of diagrams, matrices, andevaluation methods are then used to extract expected requirements.However, if the customer refuses to work with you, it’s time to get both your management and the customer’s management involved. If they don’t have the time to help define the software, they probably won’thave the inclination to use it.7.5) Software engineers want to begin building something, so they sometimes give requirementsanalysis short shrift. In addition, understanding the requirements of a problem is among the mostdifficult tasks that a software engineer face since requirements change, are sometime contradictoryand are often difficult to enunciate clearly. Hence, software engineers want to get through therequirements engineering activity and get on with the “real engineering work.” A mistake!In situations in which the problem is relatively small and reasonably well understood, an abbreviated approach may be chosen. For more plex problems with many requirements, every task defined forprehensive requirements engineering should be performed rigorously. Requirements engineeringbuilds a bridge to design and construction and cannot be skipped.7.6) Guidelines should be consistent with information presented in Section 7.4 and should stressestablish a collaborative atmosphere. To summarize:•meetings are conducted and attended by both software engineers and customers.•rules for preparation and participation are established.•an agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas.• a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting.• a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used.•the goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements in an atmosphere that is conducive to the acplishment of the goal.7.7) The first set of context-free questions focuses on the customer and other stakeholders, the overall goals,and the benefits. For example, the requirement engineer might also ask:•Who is paying for this work?•What is the name of a contact person in each customer group?•Do you know of any other business that has solved this problem successfully?7.8) The best negotiations strive for a “win-win” result, therefore, if the customer feels he has won,that does make you a master negotiator. If the customer feel duped or forced into agreement, it’sunlikely that a collaborative atmosphere will be established. The project will suffer as a result.7.10) The customer for information systems is often another department in the same pany—often referredto as the "user department." The customer for puter-based products is typically the marketingdepartment! The customer for puter-based systems may be an internal department, marketing or anoutside entity (e.g., a government agency, another pany, an end-user).7.11) The intent of the analysis model is to provide a description of the required information, functional,and behavioral domains for a puter-based system. The model changes dynamically as softwareengineers learn more about the system to be built, and stakeholders understand more about whatthey really require. For that reason, the analysis model is a snapshot of requirements at any giventime.7.12) First, the nature of the error is determined. If it is an omission, additional information must be added.If the error is due to ambiguity, the customer and developer must work to clarify matters. If theerror is due to inconsistency, a more consistent presentation is developed; if the error is due to a badinterpretation of customer need, further discussion with the customer are warranted.7.14) Anyone who has done requirements engineering on more than a few software projects begins tonotice that certain things reoccur across all projects within a specific application domain. Thesecan be called “analysis patterns” and represent something (e.g., a class, a function, a behavior)within the application domain that can be reused when modeling many applications.7.15) Extensions provide an indication of how the scenario reacts when things go awry (e.g., bad data areinput) or when a specific action (not described in the body of the use-case) is taken.7.16) A “Win-Win situation is one in which the customer wins by getting the system or product thatsatisfies the majority of the customer’s needs and the software team wins by working to realisticand achievable budgets and deadlines.7.17) The specific elements of the analysis model are dictated by the analysis modeling method that is tobe used; however the four elements of an analysis model are:•Scenario-based elements. The system is described from the user’s point of view using a scenario-based approach.•Class-based elements. Each usage scenario implies a set of “objects” that are manipulated as an actor interacts with the system. These objects are categorized into classes—a collection of thingsthat have similar attributes and mon behaviors.•Behavioral elements. The behavior of a puter-based system can have a profound effect on the design that is chosen and the implementation approach that is applied. Therefore, the analysismodel must provide modeling elements that depict behavior.•Flow-oriented elements. Information is transformed as it flows through a puter-based system. The system accepts input in a variety of forms; applies functions to transform it; and produces output ina variety of forms.Chapter 88.1) Structured analysis begins with a consideration of the data objects that the system must manipulate.In structured analysis the data objects are described with a data dictionary and the entity relationdiagram (ERD) depicts relationships between data objects. The flow and transformation of data。
(完整版)软件工程课后习题答案
第一章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>忽视软件开发先期的需求剖析。
<2>开发过程缺少一致的、规范化的方法论的指导。
<3>文档资料不齐全或不正确。
<4>忽视与用户之间、开发构成员之间的交流 <5>忽视测试的重要性。
<6>不重视保护或因为上诉原由造成保护工作的困难。
<7>从事软件开发的专业人员对这个家产认识不充分，缺少经验。
<8>没有圆满的质量保证系统。
2请简述软件工程的三因素三因素是指过程、方法和工具软件工程的基础是过程层，它定义了一组要点过程地域的框架，使软件能过被合理和及时的开发；软件工程的方法供应了建筑在在技术上需要“做什么”，它覆盖了一系列的任务，包括需求剖析、设计编程、测试和支持等；软件工程的工具对过程和方法供应了自动的或半自动的支持。
3请比较瀑布模型、快速模型、增量模型和螺旋模型。
瀑布模型的长处是：过程模型简单，履行简单；弊端是没法适应更正。
快速模型的长处是：软件产品的开发基本上是按线性序次进行的（它所达成的功能常常是最后产品能达成的功能的一个子集）增量模型的最大特色是将待开发的软件系统模块化和组件化，长处是：将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时认识项目的进展；以组件为单位进行开发降低了软件开发的风险；开发序次灵巧。
它的弊端是要求待开发的软件系统可以被模块化螺旋模型的长处是对可选方案和拘束条件的重申有益于已有的软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试（浪费资本）或测试不足（产品故障多）所带来的风险；更重的是，在螺旋模型中保护但是模型的另一个周期，在保护和开发之间并没有实质的差别，它的主要优势在于风险驱动但是这也可能是他的一个弊端。
4什么是软件过程？他与软件工程方法学有何不一样样？软件过程：是指一个为获取高质量软件所需达成的任务的框架，它规定了软件产品开发时达成各项任务的一系列工作步骤，包含中间产品、资源、角色及过程中采纳的方法、工具等范围。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件工程课后习题答案第一章一、什么是软件危机？它有哪些典型表现？为什么会出现软件危机？软件危机是指在计算机软件开发、使用与维护过程中遇到的一系列严重问题和难题。
它包括两方面：如何开发软件，已满足对软件日益增长的需求；如何维护数量不断增长的已有软件。
软件危机的典型表现：(1) 对软件开发成本和进度的估计常常很不准确。
常常出现实际成本比估算成本高出一个数量级、实际进度比计划进度拖延几个月甚至几年的现象。
而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量。
这些都降低了开发商的信誉，引起用户不满。
(2) 用户对已完成的软件不满意的现象时有发生。
(3) 软件产品的质量往往是靠不住的。
(4) 软件常常是不可维护的。
(5) 软件通常没有适当的文档资料。
文档资料不全或不合格，必将给软件开发和维护工作带来许多难以想象的困难和难以解决的问题。
(6) 软件成本、软件维护费在计算机系统总成本中所占比例逐年上升。
(7) 开发生产率提高的速度远跟不上计算机应用普及的需求。
软件危机出现的原因：(1) 来自软件自身的特点：是逻辑部件，缺乏可见性；规模庞大、复杂，修改、维护困难。
(2) 软件开发与维护的方法不当：忽视需求分析；认为软件开发等于程序编写；轻视软件维护。
(3) 供求矛盾将是一个永恒的主题：面对日益增长的软件需求，人们显得力不从心。
二、假设自己是一家软件公司的总工程师，当把图1.1给手下的软件工程师们观看，告诉他们及时发现并改正错误的重要性时，有人不同意这个观点，认为要求在错误进入软件之前就清楚它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢？”应该怎么反驳他？答：在软件开发的不同阶段进行修改付出的代价是很不相同的，在早期引入变动，涉及的面较少，因而代价也比较低；在开发的中期，软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”是在引入变动，当然付出的代价更高。
一个故障是代码错误造成的，有时这种错误是不可避免的，但要修改的成本是很小的，因为这不是整体构架的错误。
三、什么是软件工程？它有哪些本质特征？怎样用软件工程消除软件危机？1993年IEEE的定义：软件工程是：① 把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；② 研究①中提到的途径。
软件工程的本质特征：(1) 软件工程关注于大型程序(软件系统)的构造 (2) 软件工程的中心课题是分解问题，控制复杂性 (3) 软件是经常变化的，开发过程中必须考虑软件将来可能的变化(4) 开发软件的效率非常重要，因此，软件工程的一个重要课题就是，寻求开发与维护软件的更好更有效的方法和工具(5) 和谐地合作是开发软件的关键 (6) 软件必须有效地支持它的用户(7) 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人(完成一些工作)消除软件危机的途径：(1) 对计算机软件有一个正确的认识(软件≠程序）(2) 必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目(3) 推广使用在实践中总结出来的开发软件的成功技术和方法 (4) 开发和使用更好的软件工具四、简述结构化范型和面向对象范型的要点，并分析他们的优缺点。
1. 传统方法学：也称为生命周期方法学或结构化范型。
优点：把软件生命周期划分成基干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发过程的困难程度。
缺点：当软件规模庞大时，或者对软件的需求是模糊的或会承受时间而变化的时候，开发出的软件往往不成功；而且维护起来仍然很困难。
2. 面向对象方法学：优点：降低了软件产品的复杂性；提高了软件的可理解性；简化了软件的开发和维护工作；促进了软件重用。
五、1-5 根据历史数据可以做出如下的假设：对计算机存储容量的需求大致按下面公式描述的趋势逐年增加：M=4080e0.28(Y-1960) 存储器的价格按下面公式描述的趋势逐年下降：P1=0.3×0.72Y-1974(美分/位)如果计算机字长为16位，则存储器价格下降的趋势为：P2=0.048×0.72Y-1974(美元/字) 在上列公式中Y代表年份，M是存储容量(字数)，P1和P2代表价格。
基于上述假设可以比较计算机硬件和软件成本的变化趋势。
要求计算：(1) 在1985年对计算机存储容量的需求估计是多少?如果字长为16位，这个存储器的价格是多少? 存储容量需求M=4080e0.28（1985-1960）=4474263（字）存储器价格P=0.048*0.72（1985-1974）*4474263=5789美元(2) 假设在1985年一名程序员每天可开发出10条指令，程序员的平均工资是每月4000美元。
如果一条指令为一个字长，计算使存储器装满程序所需用的成本。
需要工作量4474263/200=22371（人/月）指令成本22371*4000=89484000美元(3) 假设在1995年存储器字长为32位，一名程序员每天可开发出30条指令，程序员的月平均工资为6000美元，重复(1)、(2)题。
需求估计M=4080e0.28（1995-1960）=73577679字存储器价格0.003*32*0.72（1995-1974）*73577679=7127美元工作量73577679/600=122629(人/月）成本122629*6000=735776790美元六、什么是软件过程?它与软件工程方法学有何关系?软件过程是为了开发出高质量的软件产品所需完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
软件工程方法学：通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称范型。
软件过程是软件工程方法学的3个重要组成部分之一。
七、什么是软件生命周期模型？试比较瀑布模型、快速原型模型、增量模型和螺旋模型的优缺点，说明每种模型的使用范围。
软件生命周期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。
瀑布模型优点：它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
虽然有不少缺陷但比在软件开发中随意的状态要好得多。
缺点：(1) 实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。
(2) 经常情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不欢迎具有二义性问题存在的。
(3) 客户要等到开发周期的晚期才能看到程序运行的测试版本，而在这时发现大的错误时，可能引起客户的惊慌，而后果也可能是灾难性的。
快速原型模型优点：使用户能够感受到实际的系统，使开发者能够快速地构造出系统的框架。
缺点：产品的先天性不足，因为开发者常常需要做实现上的折中，可能采用不合适的操作系统或程序设计语言，以使原型能够尽快工作。
增量模型优点：(1) 人员分配灵活，刚开始不用投入大量人力资源，当核心产品很受欢迎时，可增加人力实现下一个增量。
(2) 当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到镇静剂的作用。
缺点：(1) 至始至终开发者和客户纠缠在一起，直到完全版本出来。
(2) 适合于软件需求不明确、设计方案有一定风险的软件项目。
该模型具有一定的市场。
螺旋模型优点：对于大型系统及软件的开发，这种模型是一个很好的方法。
开发者和客户能够较好地对待和理解每一个演化级别上的风险。
缺点：(1) 需要相当的风险分析评估的专门技术，且成功依赖于这种技术。
(2) 很明显一个大的没有被发现的风险问题，将会导致问题的发生，可能导致演化的方法失去控制。
(3) 这种模型相对比较新，应用不广泛，其功效需要进一步的验证。
该模型适合于大型软件的开发八、为什么说喷泉模型较好的体现了面向对象软件开发过程无缝和迭代的特性？因为使用面向对象方法学开发软件时，各个阶段都使用统一的概念和表示符号，因此，整个开发过程都是吻合一致的，或者说是无缝连接的，这自然就很容易实现各个开发步骤的反复多次迭代，达到认识的逐步深化，而喷泉模型则很好的体现了面向对象软件开发过程迭代和无缝的特性。
九、试讨论Rational统一过程的优缺点。
优点:提高了团队生产力，在迭代的开发过程、需求管理、基于组建的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面、针对所有关键的开发活动为每个开发成员提供了必要的准则、模版和工具指导，并确保全体成员共享相同的知识基础。
它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。
缺点：RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容，此外，他没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。
十．Rational统一过程主要适用于何种项目？大型的需求不断变化的复杂软件系统项目十一.说明敏捷过程的适用范围适用于商业竞争环境下对小型项目提出的有限资源和有限开发时间的约束十二.说明微软过程的适用范围适用于商业环境下具有有限资源和有限开发时间约束的项目的软件过程模式第二章1.在软件开发的早期阶段为什么要进行可行性研究?应该从哪些方面研究目标系统的可行性？答：（1）开发一个软件时，需要判断原定的系统模型和目标是否现实，系统完成后所能带来的效益是否大到值得投资开发这个系统的程度，如果做不到这些，那么花费在这些工程上的任何时间、人力、软硬件资源和经费，都是无谓的浪费。
可行性研究的实质是要进行一次大大压缩简化了的系统分析和设计过程，就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。
可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。
（2）一般说来，至少应该从以下三个方面研究每种解法的可行性：a.技术可行性。
对要开发项目的功能、性能和限制条件进行分析，确定在现有的资源条件下，技术风险有多大，项目是否能实现，这些即为技术可行性研究的内容。
这里的资源包括已有的或可以搞到的硬件、软件资源，现有技术人员的技术水平和已有的工作基础。
b.经济可行性。
进行开发成本的估算以及了解取得效益的评估，确定要开发的项目是否值得投资开发，这些即为经济可行性研究的内容对于大多数系统，一般衡量经济上是否合算，应考虑一个“底线”，经济可行性研究范围较广，包括成本—效益分析，长期公司经营策略，开发所需的成本和资源，潜在的市场前景。