文档库 最新最全的文档下载
当前位置:文档库 › (完整版)软件工程课后习题答案

(完整版)软件工程课后习题答案

(完整版)软件工程课后习题答案
(完整版)软件工程课后习题答案

第一章

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.提供高质量的工程支撑

软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。

4.重视软件工程的管理

仅当软件过程予以有效管理时,才能实现有效的软件工程。

1.6软件工程生存周期分哪几个阶段?分别简述各个阶段的任务。

1. 计算机系统工程

计算机系统工程的任务是确定待开发软件的总体要求和范围,以及该软件与其他计算机系统元素之间的关系,进行成本估算,作出进度安排,并进行可行性分析。

2. 需求分析

需求分析主要解决待开发软件要“做什么”的问题,确定软件的功能、性能、数据、界面等要求,生成软件需求规约(也称软件需求规格说明)。

3. 设计

系统设计的任务是设计软件系统的体系结构,详细设计的任务是设计各个组成成分的实现细节,包括局部数据结构和算法。

4. 编码

编码阶段的任务是用某种程序设计语言,将设计的结果转换为可执行的程序代码。

5.测试

测试阶段的任务是发现并纠正软件中的错误和缺陷。

1.7简述CMM的5个等级。

1. 初始级

2. 可重复级

3. 已定义级

4. 已管理级

5. 优化级

1.8简述CMMI的连续式模型和阶段式模型。

1.阶段式模型的结构类同于软件CMM,它关注组织的成熟度,CMMI-SE/SW/IPPD 1.1版中有5个成熟度等级:初始的、已管理的、已定义的、定量管理的、优化的。

2.连续式模型关注每个过程域的能力,CMMI中包括6个过程域能力等级:未完成的、已执行的、已管理的、已定义的、定量管理的、优化的。

1.9简述各类软件过程模型的特点。

1. 瀑布模型:上一阶段的活动完成并经过评审才能开始下一阶段的活动,接受上一阶

段活动的结果作为本阶段活动的输入,依据上一阶段活动的结果实施本阶段应完成的活动,对本阶段的活动进行评审。

2. 演化模型:从结构初始的原型出发,逐步将其演化成最终软件产品的过程。演化模

型特别适用于对软件需求缺乏准确认识的情况。

3. 增量模型:将软件的开发过程分为若干个日程时间交错的线性序列,融合了瀑布模

型的基本成分(重复地应用)和演化模型的迭代特征,特别适用于需求经常发生变化的软件开发。

4. 原型模型:开发人员和用户在“原型”上达成一致,缩短了开发周期,加快了工程进

度,降低成本。

5. 螺旋模型:将原型实现的迭代特征与瀑布模型中控制的和系统化的方面结合起来,

不仅体现了这两种模型的优点,而且增加了风险分析。

6. 喷泉模型:各个阶段没有明显的界限,开发人员可以同步进行开发,可以提高软件

项目开发效率,节省开发时间,适应于面向对象的软件开发过程。

7. 基于构件的开发模型:利用预先包装的构件来构造应用系统。

8. 形式化方法模型:易于发现需求的歧义性、不完整性和不一致性,易于对分析模型、

设计模型和程序进行验证。

1.10敏捷软件开发的特点是什么?

1. 个体和交互胜过过程和工具

2. 可以工作的软件胜过面面俱到的文档

3. 客户合作胜过合同谈判

4. 响应变化胜过遵循计划

1.11简述敏捷软件开发的价值观。

1.个人和交互高于过程和工具

2.可运行软件高于详尽的文档

3.与客户协作高于合同(契约)谈判

4.对变更及时作出反应高于遵循计划

1.12简述敏捷软件开发的原则。

1.最优先的是通过尽早地和不断地交有价值的软件来使客户满意。

2.即使到了开发的后期,也欢迎改变需求。

3.以几周到几个月为周期,尽快、不断地发布可运行软件。

4.在整个项目过程中,业务人员和开发人员必须天天一起工作。

5.以积极向上的员工为中心建立项目组,给予他们所需要的环境和支持,对他们的工作予以充分的信任。

6.项目组内效率最高、最有效的信息传递方式是面对面的交谈。

7.测量项目进展的首要依据是可运行的软件。

8.敏捷过程提倡可持续的开发,项目发起者、开发者和用户应能长期保持恒定的速度。

9.应时刻关注技术上的精益求精和好的设计,以增强敏捷性。

10.简单化是必不可少的,这是尽可能减少不必要工作的艺术。

11.最好的构架、需求和设计出自于自我组织的团队。

12.团队要定期反思怎样才能更有效,并据此调整自己的行为。

1.13通过本章学习,请对敏捷软件开发作简要评价。

(略)

1.14简述CASE工具和环境的重要性。

CASE已被证明可以加快开发速度,提高应用软件生产率并保证应用软件的可靠品

质。计算机专业人员利用计算机使他们的企业提高了效率,企业的各个部门通过使用计算机提高了生产率和效率,增强了企业的竞争力并使之带来了更多的利润。

第二章

2.1简述系统工程的任务

1.识别用户的要求

识别用户对基于计算机的系统的总体要求,标识系统的功能和性能范围,确定系统的功能、性能、约束和接口。

2.系统建模和模拟

一个基于计算机的系统通常可考虑建立以下模型:硬件系统模型、软件系统模型、人机接口模型、数据模型。

3.成本估算及进度安排

开发一个基于计算机的系统需要一定的资金投入和时间约束(交互日期),需进行成本估算,并作出进度安排。

4.可行性分析

主要从经济、技术、法律等方面分析所给出的解决方案是否可行。

5.生成系统规格说明

作为以后开发基于计算机的系统的依据。

2.2基于计算机的系统由哪些元素组成?

1.软件

2.硬件

3.人员

4.数据库

5.文档

6.规程

2.3简述可行性分析的任务

1.经济可行性

a)成本

b)效益

c)货币的时间价值

d)投资的回收期

e)纯收入

2.技术可行性

a)风险分析

b)资源分析

c)技术分析

3.法律可行性

4.方法的选择和折衷

第三章

3.1需求工程的重要性是什么?

可以确定客户需求帮助分析人员理解问题评估可行性协商合理的解决方法无歧义的规约方案、确认规约以及将规约转换到可运行的系统时的管理要求。

3.2需求工程具体包括哪些步骤?每个步骤的具体任务是什么?

1.需求获取:系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析。

2.需求分析与协商:分析每个需求与其他需求的关系以检查需求的一致性、重叠和遗

漏的情况,并根据用户的需求对需求进行排序。

3.系统建模:通过合适的工具和符号系统地描述需求。

4.需求规约:给出对目标软件的各种需求。

5.需求验证:对功能的正确性、完整性和清晰性以及其他需求给予评价。

6.需求管理:对需求工程所有相关活动的规约和控制。

3.3一个系统分析员应该具备哪些思想素质和基本知识?请说明理由。

1.能够熟练地掌握计算机硬、软件的专业知识,具有一定的系统开发经验。

2.善于进行抽象的思维和创造性的思维,善于把握抽象的概念,并把它们重新整理成

为各种逻辑成分,并给出简明、清晰的描述。

3.善于从相互冲突或混淆的原始资料中抽出恰当的条目来。

4.善于进行调查研究,能够很快学习用户的专业领域知识,理解用户的环境条件。

5.能够倾听他人的意见,注意发挥其它人员的作用。

6.具有良好的书面和口头交流表达能力。

3.4列出在制定需求获取策略时的3种主要考虑因素。

1.功能需求。考虑系统要做什么,在何时做,在何时及如何修改或升级。

2.性能需求。考虑软件开发的技术性指标。

3.用户或人对因素。考虑用户的类型。

3.5(略)

3.6举例说明一个系统的3个不同类型的非功能需求

答:非功能性需求是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。例如在银行管理系统中,由于银行数据量的庞大以及对银行账户的管理需求,用户对系统的性能、可靠性、可维护性要求很高。安全性是对银行用户个人信息保密的基本要求;在使用系统时,由于用户庞大,要求能快速安全的执行要求,这就对系统的性能有高需求;银行的用户的变动比较大,需求高要求的系统维护。

3.7(略)

3.8软件需求分析的操作性原则和需求工程的指导性原则是什么?

需求分析的操作性原则:

必须能够表示和理解问题的信息域。

●必须能够定义软件将完成的功能。

●必须能够表示软件的行为(作为外部事件的结果)。

●必须划分描述数据、功能和行为的模型,从而可以分层次地揭示细节。

●分析过程应该从要素信息转移向细节信息

需求工程的指导性原则:

●在开始建立分析模型之前应当先理解问题。如果问题没有很好理解就急于求成,常

常会产生一个解决错误问题的完美的软件。

●强力推荐使用原型。这样做可以使用户了解将如何与计算机交互,而人们对软件质

量的认识常常是基于对界面“友好性”的切身体会。

●记录每一个需求的起源和原因。这是建立对用户要求的可追溯性的第一步。

●使用多个视图,建立系统的数据、功能和行为模型。这样做可帮助分析员从多方面

分析和理解问题,减少遗漏,识别可能的不一致之处。

●给需求赋予优先级。因为过短的时限会减少实现所有软件需求的可能性。因此,对

需求排定一个优先次序,标识哪些需求先实现,哪些需求后实现。

●注意消除歧义性。因为大多数需求都是以自然语言描述,存在叙述的歧义性问题

造成遗漏和误解。采用正式的技术评审是发现和消除歧义性的好方法。

3.9软件需求规约主要包括哪些内容?

1.引言

2.信息描述

3.功能描述

4.行为描述

5.检验标准

6.参考书目

7.附录

3.10需求验证应该有哪些人参加?

分析人员、用户、开发部门的管理者、软件设计、实现、测试的人员。

分析人员

需求分析用户获取系统系统

信息需求用户要求

折衷方案

系统信息

开发部门管理者系统需求软件设计、实现、测试人员

第四章

4.1简述软件设计阶段的基本任务。

1.数据/类设计:将分析类模型变换成类的实现和软件实现所需要的数据结构。

2.体系结构设计:定义了软件的整体结构,由软件部件、外部可见的属性和他们之间

的关系组成。

3.接口设计:描述了软件内部、软件和协作系统之间以及软件同人之间的通信方式。

4.部件级设计:将软件体系结构的结构性元素变换为对软件部件的过过程性描述。

4.2软件设计与软件质量的关系是怎么样的?

设计是在软件开发中形成质量的阶段,设计提供了可以用于质量评估的软件表示,是将用户需求准确地转化为完整的软件产品或系统的主要途径。

4.3(略)

4.4简述模块、模块化及模块化设计的概念。

模块是数据说明、可执行语句等程序对象的集合,是单独命名的,并且可以通过名字来访问的。

模块化是指把软件按照规定原则,划分为一个个较小的,相互独立的但又相互关联的部件。

模块化设计就是程序的编写不是开始就逐条录入计算机语句和指令,而是首先用主程序、子程序、子过程等框架把软件的主要结构和流程描述出来,并定义和调试好各个框架之间的输入、输出链接关系。

4.5举例说明每种类型的模块耦合度和每种类型的模块内聚度。

a)内容耦合:当一个模块直接修改或操作另一个模块的数据,或者直接转入另一个模

块时就发生了内容耦合。此时,被修改的模块完全依赖于修改它的模块。如果发生

下列情形,两个模块之间就发生了内容耦合:

i.一个模块直接访问另一个模块的内部数据

ii.一个模块不通过正常入口转到另一模块内部

iii.两个模块有一部分程序代码重叠(只可能出现在汇编语言中)

iv.一个模块有多个入口。

b)公共耦合:若一组模块都访问同一个公共数据环境,则它们之间的耦合就称为公共

耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。

c)外部耦合:一组模块都访问同一全局简单变量而不是同一全局数据结构,而且不是

通过参数表传递该全局变量的信息,则称之为外部耦合。

d)控制耦合:如果一个模块通过传送开关、标志、名字等控制信息,明显地控制选择

另一模块的功能,就是控制耦合。

e)标记耦合:一组模块通过参数表传递记录信息,就是标记耦合。这个记录是某一数

据结构的子结构,而不是简单变量。其实传递的是这个数据结构的地址。

f)数据耦合:一个模块访问另一个模块时,彼此之间是通过简单数据参数(不是控制

参数、公共数据结构或外部变量) 来交换输入、输出信息的。

g)非直接耦合:两个模块之间没有直接关系,它们之间的联系完全是通过主模块的控

制和调用来实现的

1.巧合内聚:讲几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立

的模块称巧合内聚模块。

2.逻辑内聚:逻辑内聚是指完成一组逻辑相关任务的模块,调用该模块时,由传送给

模块的控制性参数来确定该模块应执行哪一种功能。

3.时间内聚:时间内聚是指一个模块中的所有任务必须在同一时间段内执行。

4.过程内聚:过程内聚是指一个模块完成多个任务,这些任务必须指定的过程执行。

5.通信内聚:通信内聚是指一个模块内所有处理元素都集中在某个数据结构的一块区

域中。

6.顺序内聚:顺序内聚是指一个模块完成多个功能,这些功能又必须顺序执行

7.功能内聚:功能内聚是指一个模块中各个部分都是为完成一项具体功能而协同工

作,紧密联系不可分割。

4.6耦合和软件可移植性的概念有何关系?

耦合性是2个或多个模块相关的程度,可移植性是指软件从一个平台/环境转移到另一个平台/环境的难易程度。

4.7描述信息隐蔽概念,并讨论信息隐蔽与模块独立两概念之间的关系。

1.信息隐蔽指在设计和确定模块时,使得一个模块内包含信息(过程或数据),对于不

需要这些信息的其他模块来说,是不能访问的。在面向对象方法中,信息隐蔽是通

过对象的封装性来实现的。

2.信息隐蔽的概念与模块的独立性直接相关

4.8什么是模块的独立性?设计中为什么模块要独立?如何度量独立性?模块功能独立有何优点?

1.模块独立性:

A.模块独立性指每个模块只完成系统要求的独立的子功能,并且与其他模块的联

系最少且接口简单

B.模块独立性是指模块内部各部分及模块间的关系的一种衡量标准,由内聚和耦

合来度量。

2. A.具有独立的模块的软件比较容易开发出来。这是由于能够分割功能而且接口可以

简化,当许多人分工合作开发同一个软件时,这个优点尤其重要。

B.独立的模块比较容易测试和维护。这是因为相对说来修改设计和程序需要的工

作量比较小,错误传播范围小,需要扩充功能时能够"插入"模块。总之,模块独立

是优秀设计的关键,而设计又是决定软件质量的关键环节。

3.模块的独立程度可以由两个定性标准度量:内聚和耦合。

4. A.具有独立的模块的软件比较容易开发出来。这是由于能够分割功能而且接口可以

简化,当许多人分工合作开发同一个软件时,这个优点尤其重要。

B.独立的模块比较容易测试和维护。

4.9软件设计规约主要包括哪些内容?

1.工作范围

A.系统目标

B.运行环境

C.主要软件需求

D.设计约束/限制

2.体系结构设计

A.数据流与控制流复审

B.导出的程序结构

C.功能与程序交叉索引

3.数据设计

A.数据对象与形成的数据结构

B.文件和数据库结构:i.文件的逻辑结构;ii.文件逻辑记录描述;iii.访问方式

C.全局数据

D.文件/数据与程序交叉索引

4.接口设计

A.人机界面规格说明

B.人机界面设计规则

C.外部接口设计:i.外部数据接口;ii.外部系统或设备接口

D.内部接口设计规则

5.各部件的过程设计

A.处理与算法描述

B.接口描述

C.设计语言(或其他)描述

D.使用的部件

E.内部程序逻辑描述

F.注释/约束/限制

6.运行设计

A.运行部件组合

B.运行控制

C.运行时间

7.出错处理设计

A.出错处理信息

B.出错处理对策:i.设置后备;ii.性能降级;iii.恢复和再启动

8.安全保密设计

9.需求/设计交叉索引

10.测试部分

A.测试方针

B.集成策略

C.特殊考虑

11.特殊注解

12.附录

第五章

5.1简述数据流图的主要思想,概述使用数据流图进行需求分析的过程。

数据流图描述输入数据流到输出数据流的变换(即加工),用于对系统的功能建模。

1.画出系统的输入和输出

A.确定源和宿

B.确定加工

C.确定数据流

D.顶层图通常没有文件

2.画出系统内部

A.确定加工

B.确定数据流

C.确定文件

D.确定源和宿

3.画出加工内部

4.重复第3步,直至每个尚未分解的加工都足够简单(即不必再分解)

5.2分别采用数据流方法中的哪些技术来完成用户需求的精确化、一致化和完全化任务?

1.父图和子图平衡

2.数据守恒

3.局部文件

4.一个加工的输入数据流不能与该加工的输入数据流同名

5.每个加工至少有一个输入数据流和一个输出数据流

6.在整套分层数据流中,每个文件应至少有一个加工读该文件,有另一个加工写该文

件。

7.分层数据流图中得每个数据流和文件都必须命名(除了流入或流出文件的数据流),

并且与数据字典一致。

8.分层DFD中的每个基本加工(即不再分解子图的加工)都应有一个加工规约。5.3(略)

5.4在数据流图中,可否将两个加工用一个数据流相连?可否将两个源用一个数据流相连?为什么?

两个加工可以直接用数据流相连,两个源不能直接用数据流相连。因为数据流由一组固定成分的数据组成。在DFD中,数据流的流向可以有以下几种:从一个加工刘向另一个加工,从加工流向文件(写文件),从文件流向加工(读文件),从源流向加工,从加工流向宿。

5.5(略)

5.6(略)

5.7采用结构化分析方法写出书店管理系统的需求文档,包括数据流图及数据字典。

2、数据字典

存书数据字典:

出版社数据字典:

销售数据字典:

会员信息数据字典:

5.8(略)

5.9(略)

5.10

第六章

6.1 简述面向数据结构方法的特点

答:特点如下:

1 以信息对象及其操作作为核心进行需求分析;

2 认为复合信息对象具有层次结构,并且可按顺序,选择,重复3种结构分解为成员对象信息;

3 提供由层次信息结构映射为程序结构的机制,从而为软件设计奠定良好的基础。

6.2 采用Jackson图表示下面的文件结构:

第七章(略)

第八章

8.1什么是构件?

答:

根据pressman书中的定义

构件是某系统中有价值的、几乎独立的并可替换的一个部分,它在良好定义的体系结构语境内满足某种清晰的功能。

根据brown的定义

构件是一个独立发布的功能部分,可以通过其接口访问它的服务。

根据《计算机科学技术百科全书(第二版)》中的定义

软件构件是软件系统中具有相对独立功能,可以明确标识,接口由规约指定,与语境有明显依赖关系,可独立部署,且多由第三方提供的可组装软件实体。

软件构件须承载有用的功能,并遵循某种构件模型。可复用构件是指具有可复用价值的构件。在基于构件的软件开发中经常会使用到的商用成品构件,是指由第三方开发的满足一定构件标准并且可组装的软件构件。

8.2 简述基于构件的软件开发过程。

基于构件的软件开发过程:

领域工程的步骤:

1 领域分析

2 建立领域特定的基准体系结构模型

3 标识候选构件

4 泛化和可变性分析

5 构件重构

6 构件的测试

7 构件的包装

8 构件入库

应用系统工程的步骤:

1 建立应用系统的体系结构模型;

2 寻找候选构件;

3 评价和选择合适的构件;

4 构件的修改和特化;

5 开发未被复用的不分;

6 构件的组装;

7 集成测试;

8 评价被复用的构件,并推荐可能的新构件。

第九章(略)

第十章(略)

第十一章

11.1软件测试的目的是什么?

软件测试的目的是发现软件中的错误和缺陷,并加以纠正。

11.2什么是白盒测试?什么是黑盒测试?

白盒测试又称结构测试,这种方法把测试对象看做一个透明的盒子,测试人员根据程序内部的逻辑结构及有关信息设计测试用例,检查程序中所有逻辑路径是否都按预定的要求正确地工作。白盒测试主要用于对程序模块的测试。包括:

●程序模块中的所有独立路径至少执行一次。

●对所有逻辑判定的取值(“真”与“假”)都至少测试一次。

●在上下边界及可操作范围内运行所有循环

●测试内部数据结构的有效性等

黑盒测试又称行为测试,这种方法吧测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符和它的功能需求。黑盒测试可用于各种测试,它试图发现以下类型的错误:

●不正确或遗漏的功能

●接口错误,如输入输出参数的个数、类型等

●数据结构错误或外部信息(如外部数据库)访问错误

●性能错误

●初始化和终止错误

11.3

解:判定覆盖:(1)X=85,Y=85

(2)X=70,Y=95

(3)X=30,Y=95

条件覆盖:(1)X=85,X=85

(2)X=70,Y=75

(3)X=95,Y=50

(4)X=50,Y=95

(5)X=40,Y=40

判定条件覆盖:(1)X=85,X=85

(2)X=70,Y=75

(3)X=95,Y=50

(4)X=50,Y=95

(5)X=40,Y=40

(6)X=20,Y=95

(7)X=95,Y=20

条件组合覆盖:(1)X=85,X=85

(2)X=65,Y=85

(3)X=85,Y=65

(4)X=70,Y=75

(5)X=95,Y=50

(6)X=50,Y=95

(7)X=40,Y=40

路径覆盖:(1)X=85,Y=85

(2)X=70,Y=95

(3)X=30,Y=70

11.4(略)

11.5分别简述单元测试、集成测试、确认测试和系统测试的任务。

1.单元测试:又称模块测试,着重对软件设计的最小单元——软件构件或模块进行验

证。单元测试根据设计描述,对重要的控制路径进行测试,已发现构建或模块内部

的错误,通常采用白盒测试,并且多个构件或模块可以并行测试。单元测试的主要

内容:接口、局部数据结构、边界条件、独立路径和错误处理路径。

2.集成测试:也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照要求

(如根据结构图)组装成为子系统或系统,进行集成测试。使用黑盒测试方法测试

集成的功能,并且对以前的集成进行回归测试。

3.确认测试:经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,

接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是确认测

试的任务,即软件的功能和性能如同用户所合理期待的那样。

4.系统测试:将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起,

进行信息系统的各种组装测试和确认测试,系统测试是针对整个产品系统进行的测

试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不符或与之矛盾

的地方,从而提高更加完善的方案。

11.6什么是α测试?什么是β测试?

1.α测试时由一个用户在开发者的场所进行的测试,软件在开发者对用户的“指导下”

进行测试。经过α测试后的软件成为β版软件。

2.β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本,并

要求用户报告异常情况、提出批评意见,然后软件开发公司再对β版本进行改错和

完善。

11.7什么是回归测试?

回归测试就是对已经进行过的测试的子集的重新执行,以确保对程序的改变和修改,没有传播非故意的副作用。

11.8简述边界值分析方法的作用。

长期的测试工作经验告诉我们,大量的错误时发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。

第十二章(略)

第十三章

13.1请讨论时软件维护成本居高不下的因素。如何尽可能降低这些因素的影响?

1.

a)软件的维护周期长;

b)需要维护的软件往往没有文档、或文档资料严重不足、或软件的变化未在相应

的文档中反映出来;

c)维护活动占用了其它软件开发可用的资源,使资源的利用率降低;

d)一些修复或修改请求得不到及时安排,使得客户满意率下降;

e)维护的结果把一些新的潜在的错误引入软件,降低了软件质量;

f)将软件人员抽调到维护工作中,使得其他软件开发过程受到干扰。

2.

a)确定质量管理目标和优先级;

b)使用提高软件质量的技术和工具;

c)选择可维护性高的程序设计语言;

d)完善程序文档;

e)进行质量保证审查

13.2(略)

13.3软件维护过程是如何进行的?为什么要进行软件可维护性分析?

1.软件维护过程包括:建立维护组织;确定维护过程;保管维护记录;进行维护评价

等四个阶段。

2.可维护性是指理解、改正、调整和改进软件的难易程度。进行可维护性分析有利于

做出正确的决定,进而采取相应的方法应对客户的需求,对确实不能或者没有进行

维护的价值的软件坚决不进行维护,对于可以维护的软件来说,可维护性分析有助

于我们了解软件情况,从而做出相应的维护措施

13.4(略)

13.5(略)

13.6(略)

13.7在重构和正向工程之间存在的细微不同是什么?

重构是指在统一抽象级别上转换系统的描述形式;正向工程过程应用软件工程的原理、概念、技术和方法来重新开发某个现有的应用系统。从概念可以看出,重构是从一个系统环境转换到另一个系统环境,而正向工程则是重新开发,从零开始,没有一定基础的。

13.8(略)

第十四章

14.1何谓软件项目管理?软件项目管理与传统项目管理的不同点与相同点?

软件项目管理的对象是软件工程项目。它所涉及的范围覆盖了整个软件工程过程。

为使软件项目开发获得成功,关键问题是必须对软件项目的工作范围、可能风险、需要资源(人、硬件/软件)、要实现的任务、经历的里程碑、花费工作量(成本)、进度安排等做到心中有数。

项目管理的思想是共同的,不过,碰到不同的行业会有不同的管理方式。软件的项目管理是个特例,更倾向与对人工的管理,人工成本是构成软件项目成本的主要因素。

传统行业项目管理中,人、材、机都是构成项目成本的重要因素。

14.2(略)

14.3(略)

14.4何谓软件项目管理过程?其目的是什么?

软件项目管理过程从项目计划活动开始,而第一项计划活动就是估算:需要多长时间、需要多少工作量、以及需要多少人员。此外,我们还必须估算所需要的资源(硬件及软件)和可能涉及到的风险。

加强软件项目管理,就是以软件工程的各个环节为管理主线,将动态项目管理贯穿其中,通过对软件开发的项目范围、项目进度、项目质量、项目沟通、人力资源、项目成本六大核心要素的集成管理,实现软件开发管理效能的最大化,从而大大提高软件的开发质量。

14.5(略)

14.6如何理解任务分解及复杂性控制。

将一个项目分解为更多的工作细目或者子项目,使项目变得更小、更易管理、更易操作,此过程称为任务分解。

14.7软件项目启动前应完成哪些活动?

在软件项目启动前,必须对该项目进行可行性分析,明确项目的目标和范围,并在

此基础上选择候选的解决方案及可采用的软件过程模型,估算新系统可能的开发和运行成本及其效益,同时给出该项目在技术和管理上的要求。

14.8(略)

14.9(略)

14.10(略)

14.11(略)

14.12(略)

14.13(略)

14.14(略)

14.15什么是间接测量?为什么在软件度量工作中经常用到这类测量?

测量与被测量有确定函数关系的量,由函数关系表达式运算,得到所需的被测量。产品的间接测量包括功能、质量、复杂性、有效性、可靠性、可维护性等。构造软件所需的成本和工作量、生产的代码行数、以及其他直接测量是相对容易收集到的,然而,软件的质量和功能或其功效或可维护性是更难于评估的,只能间接测量。

14.16(略)

14.17(略)

14.18描述“已知风险”和“可预测风险”之间的差别。

已知风险,是通过仔细评估项目计划、开发项目的商业及技术环境、以及其它可靠的信息来源(如:不现实的交付时间,没有需求或软件范围的文档、恶劣的开发环境)之后可以发现的那些风险。

可预测风险,能够从过去项目的经验中推测出来(如:人员调整,与客户之间无法沟通,由于需要进行维护而使开发人员精力分散)。

14.19(略)

相关文档