实用软件工程第3版课后习题答案IT168文库.docx
《实用软件工程第3版课后习题答案IT168文库.docx》由会员分享，可在线阅读，更多相关《实用软件工程第3版课后习题答案IT168文库.docx（64页珍藏版）》请在冰点文库上搜索。
实用软件工程第3版课后习题答案IT168文库
《实用软件工程》第3版
习题参考答案
习题1
1.1开发文档都有哪些？
用图示表示它们之间的关系。
开发文档包括目标程序、源程序、详细设计说明书、概要设计说明书、需求规格说明书、用户需求报告、软件合同，它们之间的关系如下图所示。
1.2简述软件工程研究的内容。
软件工程研究的内容包括软件开发方法、软件开发模型、软件支持过程和软件管理过程。
其中软件开发方法的内容又涵盖市场调研、正式立项、需求分析、项目策划、概要设计、详细设计、编程、测试、试运行、产品发布、用户培训、产品复制、销售、实施、系统维护、版本升级。
常用的软件开发模型有瀑布模型、迭代模型、增量模型和原型模型。
软件支持过程由所支持的CASE工具组成，常用的CASE工具有PowerDesigner和RationalRose。
软件管理过程主要有CMMI、ISO9000、微软企业文化和敏捷文化现象。
1.3详细解释软件的定义、程序的定义及软件工程的定义。
软件的定义：
软件＝程序＋数据＋文档。
这里的程序是指程序系统。
这里的数据不仅包括初始化数据、测试数据，而且包括研发数据、运行数据、维护数据，也包括软件企业积累的项目工程数据和项目管理数据中的大量决策原始记录数据。
这里的文档指的是软件开发过程中的分析、设计、实现、测试、维护文档、管理文档。
现在有一种新提法正在引起关注，这种提法是：
软件＝知识＋程序＋数据＋文档。
程序是计算机为完成特定任务而执行的指令的有序集合。
从应用的角度可理解为：
面向过程的程序＝算法＋数据结构
面向对象的程序＝对象＋信息
面向构件的程序＝构件＋构架
软件工程是研究软件开发和软件管理的一门工程学科。
1.4软件工程的7+1条基本原理有什么现实意义？
软件工程的7条基本原理是在面向过程的程序设计时代（结构化时代）提出来的，但在面向数据和面向对象的程序设计的今天，它仍然有效。
并且在军事上的实时跟踪监控系统中有很好的应用，而且随着软件的开发和管理的进步，它将不断完善和充实。
请读者注意，作者在书中又新加入了第8条基本原理：
软件工程中的二八定律，这是对基本原理的补充与发展。
1.5读者认同“4种开发方法”的方法论和“五个面向”的实践论吗？
为什么？
“四种开发方法”是指“面向过程的方法、面向对象的方法、面向数据的方法、形式化方法”。
面向过程的方法来源于面向过程的程序设计；面向对象的方法来源于面向对象的程序设计；面向数据的方法就是面向元数据的方法，它来源于关系数据库程序设计；形式化方法来源于离散数学中的集合运算和逻辑运算。
四种方法各适用于不同的场合，各有优缺点，互相促进，构成开发方法论的多极化世界。
“五个面向理论”是指“面向流程分析、面向数据设计、面向对象实现、面向功能测试、面向过程管理”，它是在综合“四种开发方法”各自的优点之后提出的软件工程实施理论，是对前者的继承与发展。
总之，上述提法既精彩又实用。
1.6怎样理解软件工程的支持过程和管理过程？
软件工程的支持过程是由支持软件生存周期各个阶段的生产工具所组成的。
就是说将一个软件的生存周期划分为市场调研、立项、需求分析、策划、概要设计、详细设计、编程、单位测试、集成测试、运行、维护这几个过程。
在这些过程中，需要配套相应的工具来支持，比如需求分析工具、设计工具、实现工具、测试工具、维护工具、配置工具，开发环境等。
1.7CASE工具、软件开发环境SDE、软件工程环境SEE三者之间有何联系与区别？
CASE（ComputerAidedSoftwareEngineering）是一组工具和方法的集合，一般提供给个人使用，可以辅助软件开发生命周期各阶段进行软件开发。
它在软件开发/维护过程中提供计算机辅助支持和工程化方法，CASE技术分为两类，一类是支持软件开发过程本身的技术，另一类是支持软件开发过程管理的技术。
软件开发环境SDE（SoftwareDevelopmentEnvironment）指在基本硬件和宿主软件的基础上，为支持系统软件和应用软件的工程化开发和维护而使用的一组软件。
它由软件工具和环境集成机制构成，前者用以支持软件开发的相关过程、活动和任务，后者为工具集成和软件的开发、维护及管理提供统一的支持。
软件配置管理工具、面向行业领域开发的业务基础平台，都是软件开发环境的例子。
软件工程环境SEE（SoftwareEngineeringEnvironment）一般提供给团队使用，它是以软件工程为依据，支持典型软件生产的系统。
SEE具有以下特点：
（1）强调支持软件生产的全过程。
（2）强调大型软件的工业化生产。
（3）以集成和剪裁作为主要技术路径，实现软件工业化生产的目标。
（4）标准化。
软件生产走向工业化需要建立相应的工业标准。
软件工程环境的例子有北大青鸟系统，RationalRose等。
三者的相同点是：
都是软件过程的支持工具，其目的都是为了加快软件开发效率，提高软件开发质量。
三者的不同点是：
它们的功能强弱、使用范围、使用背景不尽相同。
1.8是否存在这样一种现象：
搞系统软件的公司不需要采用CMMI或ISO9001模式？
CMMI或ISO9001模式只适用于搞应用软件的企业？
如果是，是为什么？
如果不是，又是为什么？
不是。
因为CMMI和ISO9000模式规定了严格的管理制度、文档和评估软件能力与成熟度等级的一套标准，它们几乎包括了所有的IT的企业，只是一些优秀的企业自己内部形成特有的企业管理文化，但是它们并不排斥CMMI和ISO9000模式，甚至还充分肯定CMMI和ISO9000体系。
1.9敏捷文化现象是什么意思？
敏捷文化现象是指好的开发过程应该可以在保证质量的前提下，做到文档适度、度量适度和管理适度，并且根据敏捷文化能迅速做出自我调整，实现企业效益的最大化。
1.10“轻载过程改进模型”（敏捷文化现象）能代替或战胜“重载过程改进模型”CMMI吗？
不能。
因为轻载过程改进模型只适用于少于12人的项目，对个人的素质要求很高，成功的大型复杂案例并不多，它特别适合于中小型软件企业，以及中小型软件项目。
而重载过程改进模型CMM/CMMI在某种程度上包容了轻载过程改进模型，它对整体的素质要求很高，适合于所有的IT企业。
1.11什么叫软件危机？
通过本章的学习，你认为应该怎样克服软件危机？
所谓软件危机，就是在软件开发和维护过程中所遇到一系列难以控制的问题。
“软件危机”这个专业术语的首次出现，是1968年NATO（NorthAtlanticTreatyOrganization，北约）的计算机科学家，在联邦德国召开的国际学术会议上提出的。
为了克服软件危机，同样是在1968年，北约科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。
就在那次会议上，第一次提出了软件工程（SoftwareEngineering）这个专业术语。
当时人们的想法是：
若借用建筑工程或机器制造工程的思想、标准、规范、规程去开发软件与维护软件，也许能克服软件危机。
以后的实践证明：
用工程的方法开发软件与维护软件是个好主意，但是要完全克服软件危机，还有许多其他工作要做。
例如，将软件公司纳入CMMI的过程改进轨道，就能真正克服软件危机。
1.12试述信息系统的定义及信息系统的基本内容。
利用计算机网络技术、数字通信技术与数据库技术实现信息采集和处理的系统，称为信息系统。
由此不难发现：
凡是与数据库技术有关的应用系统，都可以看成信息系统。
因为数据库是组织与存储信息的最好方式，除此之外，目前还没有找到其他更好的方式。
信息系统由社会环境、网络环境、数据环境和程序环境四部分组成。
社会环境指企事业单位的管理规程、工作规范、信息标准、业务流程、业务规则和人员素质。
网络环境指互联网Internet、企业网Intranet或局域网的软/硬件设施。
数据环境指信息系统的数据模型及数据库服务器上的数据操作。
程序环境指客户端用户界面操作与应用服务器上的业务功能操作。
不管是网络环境、数据环境还是程序环境，都要进行系统集成。
这里特别强调社会环境，人们常说，信息系统建设不仅是一项计算机工程，而且是一项社会工程，就是这个道理。
1.13解释下列名词：
开发文档、管理文档、初始化数据、元数据、过程、过程改进。
开发文档主要由项目组书写，用于指导软件开发与维护；管理文档主要由软件工程管理部门书写，用于指导软件管理和决策。
初始化数据是为软件系统提供运行条件的必备数据。
元数据是关于数据的数据，组织数据的数据。
过程是指软件生命周期（LifeCycle）中的时间序列。
过程作为一个时间序列，自然有起始点和终止点。
例如，可将一个软件的生命周期划分为市场调研、立项、需求分析、策划、概要设计、详细设计、编程、单体测试、集成测试、运行、维护、退役几个过程，前一过程的终止点就是后一过程的起始点。
过程与阶段（Phase）有关，阶段与里程碑（Milestone）有关。
某些重要里程碑上的文档（通过评审和审计之后）又称为基线（Baseline）。
例如，《软件需求分析规格书》、《软件设计说明书》，它们都是基线。
过程改进是指利用过程改进模型CMMI，对软件组织内部的过程管理进行优化。
习题2
2.1软件生命周期是什么含义？
它与软件生命周期模型有何关系？
软件生命周期划分为市场调研、立项、需求分析、策划、概要设计、详细设计、编程、单体测试、集成测试、运行、维护、退役几个过程，前一过程的终止点就是后一过程的起始点。
软件生命周期与软件生命周期模型有关：
不同的生命周期模型，可能对应着不同的生存周期。
生存周期不同，该软件的开发阶段划分、评审次数、基线标准都有所不同，甚至维护方法都有所区别。
2.2为什么说“软件生命周期模型是指在整个软件生命周期中，软件开发过程应遵循的开发路线图。
或者说，软件生命周期模型是软件开发全部过程、活动和任务的结构框架”？
事实上，任何生命周期模型都是生命的路线图。
特别，软件生命周期模型是软件生命的路线图。
这里使用路线图，是为了将深奥的理论通俗化，实用化。
2.3为什么要选择软件开发模型？
软件开发模型与软件生命周期有什么关系？
因为软件开发模型是软件工程研究的5大内容之一，它虽然不是软件工程研究的重点，但是在宏观上特别重要。
软件公司的项目组在开发一个大项目或产品时，首先在技术上必须选择一个开发模型，使开发模型非常适合这个项目或产品的生存周期；随后通过对生存周期的裁减，给出适合于本项目或产品的软件生存周期定义。
2.4简述瀑布模型、增量模型、迭代模型、原型模型、XP等模型的优缺点。
软件开发模型比较表
序号
模型名称
优点
缺点
适用范围
1
瀑布模型
简单好学
逆转性差
面向过程开发
2
增量模型
可以分阶段提交
有时用户不同意
系统可拆卸和组装
3
迭代模型
需求可变
风险大
有高素质软件团队
4
原型模型
开发速度快
不利于创新
已有产品的原型
5
螺旋模型
需求可变
建设周期长
庞大、复杂、高风险项目
6
喷泉模型
提高开发效率
不利于项目的管理
面向对象开发
7
XP模型
提高开发效率
不适合大团队、大项目
小团队，小项目
2.5软件公司的CMMI过程改进模型与软件开发模型有关吗？
为什么？
无关。
因为CMMI管理体系是一种过程与质量管理模型，它是适应于任何软件开发模型的，或者说它与任何开发模型无关。
开发模型本身只是规定了软件生存周期中的若干步骤或阶段，便于开发人员去开发与维护，它并没有规定管理人员的过程管理方法与任务。
为此，CMMI管理体系规定采取阶段评审和不符合项的动态跟踪制度，只有前一阶段的不符合项全部改正后，才允许开发人员进入后一阶段的工作。
所谓不符合项，就是在评审中发现的问题项，它与Bug既有联系，又有区别。
对于这些不符合项，软件管理部门要列出表格，记录在案，确定责任人，限定改正时间，动态跟踪到底。
2.6请调查你周围的软件公司采用哪几种软件开发模型进行软件开发。
周围的软件公司采用的软件开发模型有瀑布模型、增量模型、迭代模型、原型模型。
其中瀑布模型和原型模型是这些软件公司最常用的，其次是增量模型，最后是迭代模型。
2.7软件开发模型对你今后的工作，到底具有什么指导意义？
当我们进入IT企业参与软件开发或管理时，若能掌握软件开发模型知识，就会很快了解当前的项目或产品应该采用什么开发模型，由此确定该软件的生存周期和当前项目组的开发状态与进度，从而很快知道项目组成员的工作，也能使自己很快融入该项目组，快速适应IT企业文化，并很快进入角色。
2.8你对“生命周期模型裁剪指南”有什么看法？
“生存周期模型裁剪指南”是IT企业或软件组织内部根据软件开发模型的普遍原则，结合本单位的开发经验和行业特点的具体实际定制出来的。
它有针对性地对选定的软件开发模型中定义的生存周期，进行恰当地裁剪。
所谓裁剪，就是对原模型中定义的内容进行增、改、删，去掉对本单位或者本项目不适合的部分，增加对本单位或者本项目适用的内容，同时进一步细化。
这样可以缩短开发时间，减少开发成本，具有非常现实的意义。
2.9“图书馆信息系统”的开发选用什么开发模型合适？
“图书馆信息系统”的开发选用瀑布模型比较合适。
因为瀑布模型开发阶段清晰，便于评审、审计、跟踪、管理和控制，而且“图书馆信息系统”在一定程度上符合瀑布模型的条件：
（1）它在开发时间内需求没有变化或很少变化。
（2）分析设计人员对应用领域很熟悉。
（3）低风险项目。
（4）用户使用环境比较稳定。
（5）用户除提出需求以外，很少参与开发工作。
2.10请详细说明瀑布模型与迭代模型之间的关系。
在宏观上，迭代模型是动态模型，瀑布模型是静态模型。
一方面，迭代模型需要经过多次反复迭代，才能形成最终产品。
另一方面，迭代模型的每一次迭代，实质上都是执行一次瀑布模型，都要经历初始、精化、构造、移交4个阶段，走完瀑布模型的全过程。
在微观上，迭代模型与瀑布模型都是动态模型。
迭代模型与瀑布模型在每一个开发阶段（初始、精化、构造、移交）的内部，都有一个小小的迭代过程，只有经历这一迭代过程，该阶段的开发工作才能做细做好。
瀑布模型与迭代模型之间的这种微妙关系，如下图所示。
图瀑布模型与迭代模型之间的关系
由图可见，在迭代和瀑布模型中，你中有我、我中有你。
瀑布模型与迭代模型之间的关系，反映了人们对客观事物的认识论：
要认识与掌握某一客观事物，必须经历由宏观到微观的多次反复的过程。
只有从宏观上反复迭代几次，才能看清全貌，掌握事物的宏观发展规律。
只有从微观上反复迭代几次，才能吃透每个细节，掌握事物的微观发展规律。
习题3
3.1为什么说立项（或签订合同）是一切项目的源头，也是软件项目的源头？
立项的过程就是软件企业决定是否去开发某个项目或产品的过程。
只有立项完成以后企业领导部门才会下达“任务书”，开发部门开始组成开发团队，成立项目组。
3.2立项的具体表现形式是什么？
企业的市场销售部门在市场调研的基础上，分析该产品是否有市场前景，以及企业是否有能力开发出该产品，并具体列出系统的功能、性能、接口和运行环境等方面的需求情况，当前客户群和潜在客户群情况，以及投入产出分析，然后写出立项建议书，召开立项论证会，决定是否立项。
3.3《立项建议书》的编制者为什么主要是软件公司的市场销售人员，而不是开发人员？
软件开发出来终归要推向市场的，软件能不能被市场接受是软件开发成功的标准。
市场销售人员长期和市场客户打交道，他们最了解客户和市场的需求，最知道什么样的产品具有巨大商机。
3.4为什么将项目的市场前景、功能、性能、接口、风险作为《立项建议书》的主要内容？
一切软件项目或软件产品，都是为了实现用户需求中的“功能、性能、接口”三项具体目标。
软件是否有市场前景，是软件开发是否成功的标志，有了市场软件才能带来利润。
风险分析是对开发此软件的政策风险、环境风险、技术风险、技能风险等进行分析，这对公司按时保质保量地完成软件开发，是必不可少的。
3.5什么叫风险分析？
技能风险与技术风险有何区别？
这里的风险分析是指软件立项过程中对产品开发、销售等可能出现的风险进行分析。
分析方法是将一个大风险化解为多个小风险，然后再一个个克服小风险。
技术风险是指采用新技术的风险程度。
技能风险是指项目组成员掌握新技术的风险程度。
两者的区别在于一个是说新技术（如新的开发工具，新的设计思想）本身的风险，一个是说人员要掌握这种新技术的风险。
3.6行业领域业务专家与产品经理有何异同？
行业领域业务专家是精通某行业领域业务的人，在讲标时能把投标书的内容准确、生动地表述出来，使客户心服口服。
而产品经理是某产品需求分析和概要设计的经理或专家，主要负责产品的立项、需求、设计和销售等业务。
两者的相同点是：
必须精通该产品的功能、性能和接口。
不同点是：
前者突出熟悉产品的应用业务领域，后者突出熟悉产品的需求与设计。
3.7《合同》、《任务书》、《立项建议书》三者有何异同？
有何关系？
合同是与固定客户签订的协议书，签订合同后软件公司启动该项目的开发，该软件被称为“订单软件”。
立项建议书是相对“非订单软件”而言的，是相关人员对立项过程的书面描述。
任务书是企业决定开发某个软件时，对此任务的具体部署情况，以书面的形式表达出来，包括正文和附件。
只有立项建议书或合同签订以后才能下达任务书，三者都是软件开发的源头。
3.8下达任务的时间和方法是什么？
满足以下三个条件中的任意一个，即可下达任务书：
（1）企业已签订了项目《合同》。
（2）《立项建议书》已通过了评审。
（3）作为特殊情况，软件组织的上级下达了某个项目的指令性软件开发计划。
例如，有跨组织、跨部门的某个大系统项目，软件的需求由它的系统总体设计组分配。
下达任务书的方法是：
（1）下达一份《任务书》的正文。
包括任务的下达对象、内容、要求完成的日期、决定投入的资源、必要时包括任命项目经理（技术经理和产品经理）、其他保证措施、奖惩措施等。
《任务书》的正文可长可短，若合同或立项建议书很详细，则正文可短。
若合同或立项建议书很粗略很短，则正文应该详细，当然也应该很长。
（2）下达一份《任务书》的附件。
一般情况下它就是软件《合同》或《立项建议书》，如果是指令性计划，它的格式和内容，也应与《合同》或《立项建议书》基本相同，即附件的内容应覆盖系统的功能点列表、性能点列表、接口列表、资源需求列表、开发进度列表、阶段评审列表等。
3.9请进行社会调查，收集材料，用事实说明“立项就是决策”的道理。
2003年初冬，山东某软件公司的老总在西安出差，发现西安市的大中型餐厅基本上都有电子点菜系统，客人一点菜，信息马上出现在厨房大师傅眼前，大师傅马上炒菜，服务员很快上菜，他感到很有意思。
后来一打听，这个“餐饮系统”是北京某软件公司开发的。
于是这位老总又飞到北京，拜访了“餐饮系统”的开发公司，了解到该公司经济效益不错，而且还到几家餐饮店去就餐，亲身体验“餐饮系统”的使用情况，收集用户意见。
返回山东后，老总拍着脑袋决定马上立项，快速开发本公司的“餐饮系统”。
不到三个月，“餐饮系统”开发完毕，但是在后来的两年中，该系统在山东某市总共只卖出两套，投入与产出比是5︰1。
这是为什么？
就是因为该城市是中等城市，不像北京、西安是大城市，“餐饮系统”的客户群，实在是少得可怜。
立项就是决策，IT企业的决策必须按照决策程序进行，没有决策程序就要先制定决策程序，不能一个人拍脑袋定决策。
3.10试述《商业MIS开发任务书》的优缺点及需要如何改进。
选作题，课外作业。
3.11请在老师的指导下，选定一个项目，写出一份《立项建议书》。
选作题，课外作业。
3.12对软件项目和产品的“功能、性能、接口”三项指标如何理解？
一切项目或产品都是为了解决自身的“功能、性能、接口”问题，软件项目或产品更是这样。
所以，从软件立项、需求、设计、编程、测试、维护，自始至终都要毫不动摇地坚持“功能、性能、接口”三项指标。
3.13请用PowerPoint工具制作一份“图书馆信息系统”的投标书，并进行试讲。
选作题，课外作业。
3.14按照老师建议的其他实践项目，2~3人一组，完成项目的《立项任务书》和《投标书》，并进行《投标书》讨论与试讲。
选作题，课外作业。
习题4
4.1为什么需求分析特别重要？
需求分析特别重要，是因为：
（1）许多大型应用系统的失败，最后均归结到需求分析：
要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。
（2）需求分析的输出文档是《用户需求报告》，它既是软件生存周期中的第一个里程碑，又是客户、软件开发人员和项目管理人员三者必须遵守的一根基线，是三者共同工作的基础，是项目Alpha测试和Beta测试的准则，是供方交付产品和需方验收产品的依据。
（3）需求分析要占用整个软件开发时间或工作量的30%左右。
（4）需求获取中的错误，属于软件开发中的早期错误，它会在后续的设计和实现中进行发散式的传播。
根据以上4个原因，IT企业的高层经理，对需求分析特别重视，常常派经验最丰富的人员去作项目需求。
正因为如此，“系统分析员”才是软件行业中的最高技术职称。
4.2需求分析的目的是什么？
需求分析的难点在哪里？
软件需求分析，其目的是用于说明软件产品或软件项目需要满足的条件和限制。
在软件工程项目中首先要获取用户的需求，通过对软件需要的提取、分析、文档化及验证，为进一步的设计和实现提供依据。
需求分析的难点是：
在系统的功能、性能和接口方面，开发者与客户达成完全一致的需求，让客户最终签字确认，并保证在项目验收前，需求相对稳定不变。
万一需求有一点变化，双方必须履行“需求变更管理程序”，而变更管理程序在签订合同时已经做了规定。
要知道，合同是具有法律效力的。
4.3需求分析的理论基础有哪些？
需求分析的理论基础有：
什么是软件需求；软件需求需要量化；需求是一个过程；需求过程中的角色；需求过程是一个迭代的过程；需求来源等6条理论基础。
4.4为什么说需求过程是一个迭代过程？
由于人们对客观事物的认识是不断深化的，所以需求过程是一个迭代过程，每次迭代提供更高质量和更详细内容的软件需求。
这种迭代会给项目带来一定的风险，上一次迭代的设计实现可能会因为需求不足而被推翻。
在很多情况下，对需求的理解会随着设计过程和实现过程的深入而不断深化，这也会导致在软件生命周期的后期，重新修订软件需求。
原因可能来自于错误的分析，客户环境和业务流程的改变，市场趋势的变化等。
无论是什么原因，软件分析师应认识到需求变化的必然性，并采取相应的措施，减少需求变更对软件系统的影响。
4.5为什么说需求分析是面向流程的？
系统的功能、性能、接口、界面都是在流程中动态实时的反映出来。
在所有的流程（物流、人流、资金流、信息流、单据流、报表流、数据流）中，数据流最重要，也最具有代表性。
因为在计算机网络系统内，一切流程都表现为数据流，或者说是数据流在不同方向的投影。
而流程是动态的、实时的。
所以说，需求分析是面向流程的。
4.6需求分析的基本思路是什么？
需求分析的思路，是从用户的功能需求（系统需要做什么）出发，由系统的业务流程和数据流程导出系统的业务模型和功能模型，识别出系统的元数据和中间数据，为今后设计数据模型做好充分准备。
同时，对系统的软、硬件环境配置，开发工具，开发工期，费用，开发进度，培训，系统风险
升级会员 