第9章软件工程 软件工程是系统分析师考试的重点，所涉及的每个知识 ...

第9章软件工程 软件工程是系统分析师考试的重点，所涉及的每个知识 ... 第9章软件工程 软件工程是系统分析师考试的重点，所涉及的每个知识点都要求掌握。 瀑布模型是最常用的传统软件开发模型。它的特点之一是 (1) 。根据国家标准GB 8566-88《计算机软件开发规范》的规定，软件开发流程分为8个阶段，即可行性研究和、需求分析、概要设计、详细设计、实现、组装测试、确认测试、使用和维护。实现阶段要完成的工作之一是单元测试，这种测试要根据在 (2) 阶段中的规格说明进行;组装测试计划是在 (3) 阶段制定的;确认测试计划是在 (4) 阶段制定的。测试的目的是为了 (5) 。 (1) A(文档是阶段完成的里程碑 B(具有从软件规格说明转换成可执行代码的自动程序设计的新风范 C(利用软件速成原型法加强软件人员与用户的联系 D(支持人工智能、面向对象等新软件技术的集成 (2) A. 可行性研究和计划 B. 需求分析 C. 概要设计 D. 详细设计 (3) A. 可行性研究和计划 B. 需求分析 C. 概要设计 D. 详细设计 (4) A. 可行性研究和计划 B. 需求分析 C. 概要设计 D. 详细设计 (5) A. 证明软件符合设计要求 B. 发现软件中的错误和缺陷 C. 改善软件的功能和性能 D. 发掘软件的潜在能力 答案 1. A 2(D 3. C 4(B 5(B [分析] 用软件工程的方法来并发大型软件项目，常用的方法有生命周期法、原型法:快速原型法等。瀑布模型是生命周期法中最常用的开发模型，它把软件开发流程分为可行性分析、需求分析、软件设计、编码实现、测试和维护6个阶段，如图9-1所示。 各阶段的相应文档是阶段完成的里程碑。上述6个阶段中，前5个阶段合起来又称为软件开发阶段。在软件开发阶段中，测试是保证软件质量的重要手段。随着软件项目规模的增大，加之人类思维有局限性，在编码完成后就得到一个无错的软件越来越难，因而测试就成为必不可少的项目。测试的目的就是为了发现所编软件中的错误和缺陷。软件测试分成单元测试、组装测试(集成测试)、系统测试和确认测试(验收测试)四部分。按国家标准GB 8566-88《计算机软件开发规范》的规定，单元测试在实现阶段完成，它是根据详细设计阶段中所给出的规格说明进行的。组装测试的计划是在概要设计阶段制定的，确认测试计划则是在需求分析阶段制定的。软件测试的各个阶段与软件开发阶段的对应关系呈“V”字形，如图9-2所示。 软件开发模型是指软件开发的全部过程、活动和任务的结构框架。主要的开发模型有瀑布模型、演化模型、螺旋模型、喷泉模型和智能模型。螺旋模型将瀑布模型和演化模型相结合，并增加了 (6) ，它建立在 (7) 的基础上，沿着螺线自内向外每旋转一圈，就可得到 (7) 的一个新版本。 喷泉模型描述了 (8) 的开发模型，它体现了这种开发方法创建软件的过程所固有的 (9) 和 (10) 的特征。 (6) A. 系统工程 B. 风险分析 C. 设计评审 D. 进度控制 (7)A. 模块划分 B. 子程序分解 C. 设计 D. 原型 (8) A. 面向对象 B. 面向数据流 C. 面向数据结构 D. 面向事件驱动 (9) A. 归纳 B. 推理 C. 迭代 D. 递归 (10) A. 开发各阶段之间无“间隙” B. 开发各阶段分界明显 C. 部分开发阶段分界明显 D. 开发过程不分段 答案 6(B 7(D 8. A 9(C 10(A [分析] 瀑布模型给出了软件生命周期各阶段的固定顺序，上一阶段完成后才能进入下一阶段。演化模型是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。螺旋模型将瀑布模型和演化模型相结合，它综合了两者的优点，并增加了风险分析。它以原型为基础，沿着螺线自内向外旋转，每旋转一圈都要经过制定计划、风险分析、实施工程、客户评价等活动，并开发原型的一个新版本。经过若干次螺旋上升的过程，得到最终的软件，如图9-3所示。 喷泉模型对软件复用和生存周期中多项开发活动的集成提供了支持，主要支持面向对象的开发方法。“喷泉”一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动中，即分析、设计和编码之间不存在明显的边界，如图9-4所示。 智能模型是基于知识的软件开发模型，它综合了上述若干模型，并把专家系统结合在一起。该模型应用基于规则的系统，采用归约和推理机制，帮助软件人员完成开发工作，并使维护在系统规格说明一级进行。 (11)系统开发过程的流程如图9-5所示， (11) 阶段拟定了系统的目标、范围和要求。 A(? B(? C. ? D(? 答案 (11)A [分析] 软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题。在系统需求分析阶段，就要拟定系统的目标、范围和要求 (需求)，明确项目视图和范围。 结构化分析方法是一种面向 (12) 的需求分析方法，该方法最常用的图形工具是 (13) ，与其配合使用的是 (14) 。 (15) 中有名字及方向的成分是 (13) ，不能由计算机处理的成分是 (16) 。 (12) A. 对象 B. 数据结构 C. 数据流 D. 控制流 (13) A(程序流程图 B(实体联系网 C(数据流图 D(网络图 (14) A(程序流程图 B(实体联系网 C(数据流图 D(数据词典 (15)A(控制流 B(信息流 C(数据流 D(信号流 (16) A(控制流 B(信息流 C(数据流 D(数据源/终点 答案 12(C 13(C 14(D 15(C 16(D [分析] 结构化分析(Structured Analysis，简称为SA)方法最初由Douglas Ross提出，DeMarco推广，Ward和Mellor以及后来的Hatley和Pirbhai扩充，形成了今天的结构化分析方法的框架，在20世纪90年代得到了广泛的应用。 SA是一种面向数据流的软件分析方法，适合于开发数据处理类型软件的需求分析。数据流图是需求分析阶段使用的一种主要工具，它以图形的方式表达数据处理系统中信息的变换和传递过程。与数据流图配合使用的是数据词典，它对数据流图中出现的所有数据元素给出逻辑定义。数据词典使数据流图上的数据流、加工和文件得到了确切的解释。 通常在数据流图中，可能出现下面4种基本符号:数据流、加工、数据存储和外部实体(数据源及数据终点)。数据流是具有名字和流向的数据，在数据流图中用标有名字的箭头表示;加工是对数据流的变换，一般用圆圈表示;数据存储是可访问的存储信息，一般用直线段表示;外部实体位于被建模的系统之外的信息生产者或消费者，是不能由计算机处理的成分，它们分别表明数据处理过程的数据来源及数据去向，用标有名字的方框表示。图9-6是一个典型的数据流图示例。 为了表达数据处理过程的数据加工情况，用一个数据流图是不够的。稍微复杂的实际问题，在数据流图上常常出现十几个甚至几十个加工，这样的数据流图看起来很不清楚。层次结构的数据流图能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和理解整个系统。 图9-7给出分层数据流图的示例。数据处理S包括三个子系统1、2、3。顶层下面的第一层数据流图为DFD/L1。第二层数据流图DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说，我们称它的上层图为父图，它下一层的图则称为子图。 画数据流图的基本步骤概括地说，就是“自顶向下逐层分解”。检查和修改的原则为: ?数据流图上所有图形符号只限于前述4种基本图形元素; ?顶层数据流图必须包括前述4种基本元素，缺一不可; ?顶层数据流图上的数据流必须封闭在外部实体之间; ?每个加工至少有一个输入数据流和一个输出数据流; ?在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系; ?规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致，即父图与子图的平衡; ?可以在数据流图中加入物质流，帮助用户理解数据流图; ?图上每个元素都必须有名字; ?数据流图中不可夹带控制流。 软件需求分析的任务不应包括 (17) 。进行需求分析可使用多种工具，但 (18) 是不适用的。在需求分析中，开发人员要从用户那里解决的最重要的问题是 (19) 。需求规格说明书的内容不应包括 (20) ，该文档在软件开发中具有重要作用，但其作用不应包括 (21) 。 17. A(问题分解 B(可靠性与安全性要求 C(结构化程序设计 D(确定逻辑模型 18. A(数据流图(DFD) B(判定表 C(PAD图 D(数据词典 19. A(要让软件做什么 B(要给该软件提供哪些信息 C(要求软件工作效率怎样 D(要让软件具有何种结构 20. A(对重要功能的描述 B(对算法的详细过程描述 C(对数据的要求 D(软件的性能 21. A(软件设计的依据 B(用户和开发人员对软件要做什么的共同理解 C(软件验收的依据 D(软件可行性分析的依据 答案 17(C 18(C 19(A 20(B 21(D [分析] 软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口，定义软件的其他有效性需求。也就是说，软件需求分析的任务是要解决“软件做什么”的问题，而不是解决“如何做”的问题，因此不包括程序设计。在需求分析中，可使用的工具主要有数据流图 (DFD)、数据词典(DD)、结构化语言、判定表及判定树等。PAD图(问题分析图)主要用在软件设计过程中。 软件需求规格说明(SRS)是需求分析阶段的主要输出结果，代表用户和开发人员对软件系统的共同理解，是软件项目后期开发和维护的基础。SRS需要把用户对软件的功能需求和非功能需求进行详细记录和准确描述，但不包括耐算法的详细过程描述。 结构化分析方法(SA)是一种预先严格定义需求的方法，强调分析对象的 (22) ，其指导思想是 (23) 。 过程P分解为P1，P2，P3三个子过程，图9-8的数据流图中存在两处错误，其中错误1是 (24) ，错误2是 (25) 。 (22)A(程序流 B(指令流 C. 控制流 D(数据流 (23)A(自顶向下逐层分解 B(自底向上逐层分解 C(面向对象 D(面向过程 (24)A(1层S B(1层S2 C(0层S D(0层S1 (25)A(1层S B(1层S2 C(0层S D(0层S1 答案 (22)D (23)A (24)B (25)B [分析] 结构化分析是面向数据流进行需求分析的方法，适合于数据处理类型软件的需求分析。具体来说，结构化分析就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直至找到满足功能要求的所有可实现的软件为止。 数据流图从数据和数据所经过的加工这两个相互补充的方面来表达一个数据处理系统。数据流图从数据的角度描述了它们作为输入(广义的)，经过某个或若干个加工，或者合并，或者分解，或者存储，最后成为输出(广义的)的整个过程。虽然不同的应用要解决的问题不同，其数据流图的结构也不一样。但在形成数据流图时，仍然可以确定一些基本的原则和步骤。 在本题中，0层数据流图符合要求，其输入为S，输出为S1。按照数据流图的规则，1层数据流图应该要与0层数据流图平衡，既其输入要为S，输出要为S1，但在图9-8中，1层数据流图没有输出，且多了输入S2。因此，正确的应该是去掉S2及其连带的输入数据，而在P3处添加输出S1。 在业务领域分析过程中，通过建立实体关系图，把与业务相关的数据模型化:通过建立 (26) 来表示业务活动的分解过程;两个业务过程之间的相互依赖关系应记录在过程依赖图中;通过建立 (27) 来详细说明整个业务过程的逻辑。 (26)A(数据流图(DFD) B(过程层次图(PHD) C. 过程活动图(PAD) D(过程关系图(PRD) (27)A(数据流图(DFD) B(过程层次图(PHD) C(过程活动图(PAD) D(甘特图(Gaotte) 答案 (26)B (27)C [分析] 在业务领域分析过程中，通过建立实体关系图，把与业务相关的数据模型化;通过建立过程层次图来表示业务活动的分解过程;两个业务过程之间的相互依赖关系应记录在过程依赖图中;通过建立过程活动图来详细说明整个业务过程的逻辑。 软件测试是保证软件可靠性的主要手段之一。测试阶段的根本任务是 (28) ，设计测试用例的基本目标是 (29) 。测试大型软件系统时通常由模块测试、集成测试、系统测试、 (30) 和并行运行等步骤所组成。系统测试通常采 用黑盒法，常用的黑盒测试法有边值分析、等价类划分、错误推测和 (31) 。系统测试的工作应该由 (32) 来承担。 28(A(证明经测试后的程序是正确的 B(确认编码阶段的结束 C(发现并改正软件中的错误 D(利用计算机调试程序和改进程序 29(A(尽可能用测试用例覆盖可能的路径 B(选用少量的高效测试用例尽可能多地发现软件中的问题 C(采用各种有效测试策略，使所得的程序准确无误 D(评估与选用不同测试方法，尽可能完成测试进度计划 30(A(接口测试 B(组装测试 C(性能测试 D(验收测试 31(A(路径覆盖 B(因果图 C(判定树 D(PERT图 32(A(开发该系统的部门以外的人员 B(该系统的系统分析师 C(该系统的设计人员 D(该系统的编程者 答案 29(C 29(B 30(D 31(B 32(A [分析] 软件测试的根本任务就是要发现并改正软件中的错误。测试的过程是:设计测试用数据(称之为测试用例);执行程序;分析结果，找出错误并改正。这个过程可能会有反复。测试用例的设计是测试的重要环节，设计测试用例的目标是选用少量高效的数据(测试用例)尽可能多地发现软件中的问题。 软件测试的工作量约占软件开发总工作量的40%以上，其目的是尽可能多地发现软件产品(主要是指程序)中的错误和缺陷。 测试的关键是测试用例的设计，设计方法可分成两类:白盒测试和黑盒测试。 (1)白盒测试 把程序看成是装在一只透明的盒子里，测试者完全了解程序的结构和处理过程。白盒测试根据程序的内部逻辑来设计测试用例，检查程序中的逻辑通路是否都按预定的要求正确地工作，白盒测试的具体方法主要是逻辑覆盖，由于覆盖的详尽程度不同，逻辑覆盖由弱到强又分为语句覆盖、判定覆盖、条件覆盖、条件组合覆盖和路径覆盖等。 (2)黑盒测试 把程序看成是装在一只不透明的盒子里，测试者完全不了解(或不考虑)程序的结构和处理过程。黑盒测试根据规格说明书规定的功能未设计测试用例，检查程序的功能是否符合规格说明的要求。黑盒测试方法具体有等价类划分、边界值分析、错误推测和因果图等。 软件测试的主要步骤有单元测试(模块测试)、集成测试(组装测试)、系统测试和确认测试(验收测试)。 (1)单元测试 通常在编码阶段进行，主要用来发现编码和详细设计中产生的错误，一般采用白盒测试。 (2)集成测试 集成测试是对由各模块组装而成的模块进行测试，主要检查模块间的接口和通信。集成测试主要用来发现设计阶段产生的错误，通常采用黑盒测试。 (3)系统测试 系统测试的任务是把软件放在实际的硬件和网络环境中进行测试，主要测试软件的非功能需求和质量属性是否得到满足。系统测试通常采用黑盒测试。 (4)确认测试 确认测试的任务是检查软件的功能、性能和其他特征是否与用户的需求一致，它是以需求规格说明书作为依据的测试，通常采用黑盒测试。 在确认测试时，如果一个软件是为某个客户定制的，那么由客户实施验收测试，以便确认该软件是他所需要的。但是，对于那些作为产品被众多客户使用的软件，就不可能为每个客户做验收测试。大多数软件生产商使用一种a测试和β测试的过程。 (1)a测试 在开发者的现场由客户来实施的，被测试的软件是在开发者从用户的角度进行常规设置的环境下运行的。 (2)β测试 在一个或多个客户的现场由该软件的最终用户实施的。与a测试不同的是，进行β测试时开发者通常是不在场的。 从使用的工具来看，软件测试的方法又可分为静态测试和动态测试。 (1)静态测试 指人工评审软件文档或程序，借以发现其中的错误，由于评审的文档或程序不必运行，所以称为静态测试。人工评审的手续虽然比较简单，但事实证明这是一个相当有效的检验手段。由于评审人员的能力有限，静态测试显然不可能发现所有的错误。 (2)动态测试 指通常的上机测试，这种方法是使程序有控制地运行，并从多种角度观察程序的行为，以发现其中的错误。 在软件维护阶段，当修改软件后，除了对修改部分的软件进行常规的测试外，还应对软件的其他部分进行回归测试，回归测试是指全部或部分地重复已做过的测试，它主要检查软件的修改是否在软件的未修改部分引入了新的错误。 模块测试、集成测试一般以软件系统开发人员为主来测试。系统测试和验收测试一般不能以开发人员为主来测试。这是因为系统测试是整体性的测试，而测试的根本任务是做“否定性”工作，为减少或避免开发人员的主观影响，使系统测试具有更强的客观性，一般应由开发该系统的部门以外的人员来承担。 测试大型软件通常由 (33) 、集成测试、系统测试和确认测试组成。确认测试主要寻找与软件 (34) 说明不一致的错误。语句覆盖、判定覆盖、条件覆盖和路径覆盖都是白盒测试法设计测试用例的覆盖准则，在这些覆盖准则中最弱的准则是 (35) ，最强的准则是 (36) 。此外，还有多种黑盒测试的设计测试用例方法，如 (37) 。 33(A(组装测试 B(性能测试 C(接口测试 D(单元测试 34(A(需求规格 B(概要设计 C(详细设计 D(界面设计 35(A(语句覆盖 B(条件覆盖 C(路径覆盖 D(判定覆盖 36(A(语句覆盖 B(条件覆盖 C(路径覆盖 D(判定覆盖 37(A(E-R图 B(因果图 C(DFD图 D(IPO图 答案 33(D 34(A 35. A 36(C 37(B [分析] 语句覆盖就是设计若干个测试用例，运行被测程序，使得每条可执行语句至少执行一次。 判定覆盖(分支覆盖)就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。 条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。 条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。 路径覆盖就是设计足够的测试用例，覆盖程序中所有可能的路径。 根据上面的叙述和试题8的分析，本题的结果是显然的。有关各种测试和软件开发阶段的对应关系，请阅读试题1的分析。 在下面所列举的逻辑测试覆盖中，测试覆盖最强的是 (38) ，最弱的是 (39) 。 软件测试工具有多种，其中 (40) 对源程序的数据流和控制流进行分析，发现语义错误: (41) 通过对程序的执行流进行探测，检查有关变量的逻辑值。 在下面的个人所得税程序中满足语句覆盖测试用例的是 (42) ，满足判定覆盖测试的用例是 (43) 。 if (income,800) taxrate=0; else if (income,,1500) taxrate,0.05; else if (income,2000) taxrate,0.08: else taxrate,0.1; 38(A(条件覆盖 B(条件组合覆盖 C(语句覆盖 D(条件及判定覆盖 39(A(条件覆盖 B(条件组合覆盖 C(语句覆盖 D(条件及判定覆盖 40(A(动态分析工具 B(静态分析工具 C(模拟工具 D(测试管理工具 41(A(动态分析工具 B(静态分析工具 C(模拟工具 D(测试管理工具 42(A(income=(800，1500，2000，2001) B(Income=(800，801，1999，2000) C(income=(799，1499，2000，2001) D(income=(799，1500，1999，2000) 43(A(income=(799，1500，1999，2001) B(income=(799，1501，2000，2001) C(income=(800，1500，2000，2001) D(income=(800，1499，2000，2001) 答案 38(B 39(C 40(B 41(A 42(D 43(A [分析] 语句测试是运行所测程序和测试用例，使得每一条可执行语句至少执行一次。判定覆盖是运行所测程序和测试用例，使得程序中每个判断的取“真”和取“假”分支至少经历一次。判定覆盖又称为分支覆 盖。为了方便设计测试用例，一般需要画出程序流程图，本题的流程图如图9-9所示。 根据图9-9，该程序有4个可执行语句(用矩形表示)，使用语句覆盖的测试用例，必须要使这4个可执行语句各执行一次，显然，在(14)的4个选项中，只有D满足这个要求，因为A、B使语句taxrate=0得不到执行;C使语句 taxrate=0.08得不到执行。 同样，根据图9-9，该程序有3个判定(用菱形表示)，6个分支。在试题 (15)给出的4个选项中，B、C、D都包含用例(2000、2001)，这两个用例在本程序中的作用是完全一样的，所以，可以排除B、C、D。因此，只有A满足条件。 软件测试通常可分为单元测试、集成测试、确认测试和系统测试，其中确认测试主要用于发现 (44) 阶段的错误。在集成测试时，通常可采用自顶向下增殖式集成和自底向上增殖式集成。在自底向上增殖式集成时，对每个被集成的模块 (45) 。对那些为众多用户开发的软件(如操作系统、编译程序)，通常还要进行α测试和β测试，以发现可能只有最终用户才能发现的错误。其中，α测试是指晕终用户在 (46) 的情况下所进行的测试，β测试是指最终用户在 (47) 的情况下所进行的测试。在软件维护阶段，当修改软件后，除了进行常规的测试外，还应进行 (48) 测试。 44(A(需求分析 B(概要设计 C(详细设计 D(编码 45(A(不必设计驱动模块和桩(stub)模块 B(不必设计驱动模块，但要设计桩模块 C(要设计驱动模块，但不必设计桩模块 D(要设计驱动模块和桩模块 46(A(开发环境下，开发人员不在场 B(开发环境下，开发人员在场 C(用户的实际使用环境下，开发人员不在场 D(用户的实际使用环境下，开发人员在场 47(A(开发环境下，开发人员不在场 B(开发环境下，开发人员在场 C(用户的实际使用环境下，开发人员不在场 D(用户的实际使用环境下，开发人员在场 48(A(恢复 B(强度 C(安装 D(回归 答案 44(A 45(C 46(B 47(C 48(D [分析] 在集成测试中，需要把各个模块组装起来进行测试，通常，把模块组装成为系统的方式有一次性组装方式和增殖式组装方式两种。其中后者又可分为自顶向下的增殖方式和自底向上的增殖方式。 模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其他模块。这些辅助模块分为两种: (1)驱动模块 相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实 测结果。 (2)桩模块 用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。 各种模块之间的关系如图9-10所示。 在自底向上增殖式集成时，因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块(包括子模块的所有下属模块)已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。 一般来说，在软件维护过程中，大部分工作是由 (49) 引起的。在软件维护的实施过程中，为了正确、有效地修改程序，需要经历以下三个步骤:分析和理解程序、修改程序和 (50) 。 (51) 的修改不归结为软件的维护工作。 49(A(适应新的软件环境 B(适应新的硬件环境 C(用户的需求改变 D(程序的可靠性 50(A(重新验证程序 B(验收程序 C(书写维护文档 D(建立目标程序 51(A(文档 B(数据 C(需求分析 D(代码 答案 (49)C (50)A (51)C [分析] 软件经过测试，交付给用户后，在使用和运行过程中可能在软件运行/维护阶段对软件产品进行的修改就是所谓的维护。软件维护占整个软件生命周期的 60%-80%，维护的类型主要有三种。 (1)改正性维护 为了识别和纠正软件错误，改正软件性能上的缺陷，排除实施中的错误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。 (2)适应性维护 在使用过程中，外部环境(新的硬、软件配置)、数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质)可能发生变化。为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。 (3)完善性维护 在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能，增强软件性能，改进加工效率，提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。 除了以上三类维护之外，还有一类维护活动，叫做预防性维护。这是为了提高软件的可维护性、可靠性等特性，为以后进一步改进软件打下良好基础。通常，预防性维护定义为:“把今天的方法学用于昨天的系统，以满足明天的需要”。也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分(重新)进行设计、编制和测试。 以上各种维护过程占整个软件维护工作量的比例如图9-11所示。 影响维护工作量的因素主要有系统大小、程序设计语言、系统年龄、数据库技术的应用、先进的软件开发技术五个方面。 程序修改的步骤为分析和理解程序、修改程序和重新验证程序。 经过分析，全面、准确、迅速地理解程序是决定维护成败和质量好坏的关键。为了容易地理解程序，要求自顶向下地理解现有源程序的程序结构和数据结构，为此可采用如下方法:分析程序结构图、数据跟踪、控制跟踪、分析现有文档的合理性等。 对程序的修改，必须事先做出计划，有预谋地、周密有效地实施修改。在修改时，要防止修改程序的副作用(修改代码的副作用、修改数据的副作用、修改文档的副作用)。 在将修改后的程序提交用户之前，需要用以下的方法进行充分的确认和测试，以保证整个修改后的程序的正确性。这种验证可分为静态确认、计算机确认和维护后的验收。 软件维护是软件生存期的最后一个阶段，而与软件维护有关的绝大多数问题的根源在于计划阶段和开发阶段的工作有缺陷，这就经常涉及软件中的代码、数据和文档的维护工作，而需求分析并不是软件的维护工作。 评价软件的质量通常可以从产品运行、产品修改和产品转移三个不同角度来进行。除了软件应满足产品规格说明的正确性和保证运行效率以外， (52) 和 (53) 也是产品运行期间影响软件质量的两个质量因素，其中 (52) 是指在遇到意外时系统能做出适应反应的程度。可维护性是影响产品修改的一个质量因素，它主要包括可理解性、可修改性和 (54) 。一般认为， (55) 是影响产品转移的一个质量因素。为了保证软件质量，在开发过程的各阶段进行 (56) 是一个重要的手段。 (52) A(灵活性 B(可重用性 C(适应性 D(健壮性 (53)A(灵活性 B(可重用性 C(适应性 D(可用性 (54)A(可测试性 B(可移植性 C(适应性 D(健壮性 (55)A(灵活性 B(可重用性 C(完整性 D(安全性 (56)A(验收测试 B(用户培训 C(软件评审 D(文件修改 答案 (52)D (53)D (54)A (55)B (56)C [分析] 软件质量保证是指为保证软件系统或软件产品最大限度地满足用户要求而进行的有计划、有组织的活动，其目的是生产高质量的软件。有多种软件质量模型来描述软件质量特性，著名的有ISO/IEC 9126软件质量模型和McCall软件质量模型。 软件系统主要的软件质量属性有: (1)性能(performance) 系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量的表示。性能测试经常要使用基准测试程序。 (2)可靠性(reliability) 软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统功 能特性的基本能力。可靠性通常用平均失效等待时间MTTF(Mean Time To Failure)和平均失效间隔时间MTBF(Mean Time Between Failure)来衡量。 可靠性可以分为两个方面:容错性(fault-tolerant)和健壮性(robustness)。其中: 容错性是在错误发生时确保系统正确的行为，并进行内部“修复”。例如，在一个分布式软件系统中失去了一个与远程构件的连接，接下来恢复了连接。在修复这样的错误之后，软件系统可以重新或重复执行进程间的操作直到错误再次发生。 健壮性是指保护应用程序不受错误使用和错误输入的影响，在遇到意外错误事件时确保应用系统处于已经定义好的状态。和容错性相比，健壮性并不是说在错误发生时软件可以继续运行，它只能保证软件按照某种已经定义好的方式终止执行。 (3)有效性(availability) 系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。 (4)安全性(security) 指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性是根据系统可能受到安全威胁的类型来分类的。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。其中: 机密性 保证信息不泄露给未授权的用户、实体或过程; 完整性 保证信息的完整和准确，防止信息被非法修改; 可控性 保证对信息的传播及内容具有控制的能力，防止为非法者所用。 (5)可修改性(modifiability) 指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。可修改性包含4个方面:可维护性、可扩展性、结构重组、可移植性。其中 可维护性(maintainability) 表明在软件中纠正一个缺陷或做一次更改的难易程度。主要体现在问题的修复上:在错误发生后“修复”软件系统。 可扩展性(extendibility) 关注的是使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。为了实现可扩展性，软件系统需要松散耦合的构件。其目标是实现一种体系结构，它能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的体系结构中也是必要的。 结构重组(reassemble) 重新组织软件系统的构件及构件间的关系。例如，通过将构件移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计构件之间的关系。理想情况下，它们允许开发人员在不影响实现主体部分的情况下灵活地配置构件。 可移植性(portability) 把软件系统从一个系统平台移到另一个平台的难易程度。 (6)功能性(functionality) 系统完成所期望工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。 (7)互操作性(interoperability) 指系统能与其他系统协作的程度。 软件质量保证环节包括的主要功能有:制定和展开质量方针;制定质量保证方针和质量保证标准;建立和管理质量保证体系;明确各阶段的质量保证业务;坚持各阶段的质量评审;确保设计质量;提出与分析重要的质量问题;总结实现阶段的质量保证活动;整理面向用户的文档、说明书等;鉴定产品质量，鉴定质量保证体系:收集、分析和整理质量信息。 根据ISO/IEC 9126，软件质量由三个层次组成，第一层是质量特性，第二层是质量子特性，第三层是度量指标。 质量属性分为功能性、可靠性、可维护性、效率、易使用性和可移植性6个，21个质量子特性如下。 (1)功能性 包括适合性、准确性、互用性、依从性、安全性: (2)可靠性 包括成熟性、容错性、易恢复性; (3)易使用性 包括易理解性、易学性、易操作性; (4)效率 包括时间特性、资源特性; (5)可维护性 包括易分析性、易改变性、稳定性、易测试性。 (6)可移植性 包括适应性、易安装性、一致性、易替换性。 软件质量特性度量有两类:预测度量和验收度量。预测度量是利用定量或定性的方法，估算软件质量的评价值，以得到软件质量比较精确的估算值。验收度量是在软件开发各阶段的检查点，对开发过程中的预测进行评价得到软件的要求和质量进行确认性检查的具体评价值。 预测度量有两种，第一种叫做尺度度量，这是一种定量度量。它适用于一些能够直接度量的特性，例如，出错率定义为:错误数/KLOC/单位时间。第二种叫做二元度量，这是一种定性度量。它适用于一些只能间接度量的特性，例如，可使用性、灵活性等。 评价软件的质量通常可以从产品运行、产品修改和产品转移三个不同角度来进行。如图9-12所示。 软件的可维护性通常包括可理解性、可修改性和可测试性。为了保证软件质量，在开发过程的各阶段进行软件评审是一个重要的手段。 如何评价软件的质量一直是软件技术人员所关心的问题，目前已有多种软件质量模型来描述软件的质量特性。ISO/IEC 9126是国际标准化组织在1991年提出的软件质量标准。它由三个层次组成，第一层是质量特性，第二层是质量子特性，第三层是度量指标。6个质量特性是:功能性、可靠性、易使用性、效率、可维护性和 (57) 。其中功能性包括质量子特性 (58) ;可靠性包括质量子特性 (59) ;易使用性包括质量子特性 (60) ;可维护性包括质量子特性 (61) 。 (57)A(易理解性 B(容错性 C(可移植性 D(安全性 (58)A(互用性 B(易恢复性 C(易安装性 D(易替换性 (59)A(依从性 B(易恢复性 C(资源特性 D(一致性 (60)A(易理解性 B(容错性 C(易分析性 D(安全性 (61)A(准确性 B(容错性 C(易操作性 D(易测试性 答案 (57)C (58)A (59)B (60)A (61)D [分析] 请参考试题13的分析。 McCall软件质量模型把软件的质量特性分为三个重要的方面，属于软件产品运行方面的特性有 (62) ，属于软件产品修改方面的特性有 (63) 。 (62)A(可移植性 B(可维护性 C(可使用性 D(灵活性 (63)A(互操作性 B(可测试性 C(可重用性 D(完整性 答案 (62)C (63)B [分析] 评价软件的质量通常可以从产品运行、产品修改和产品转移三个不同角度来进行。如图9-12所示(见试题13的分析)。 (64)可测试性是指对测试一个软件所需要的工作量的度量。可测试性与软件的许多度量属性有关，与可测试性有关的6个度量属性是 (64) 。 A(可操作性，可跟踪性，自检视性，易培训性，完备性，模块性 B(可操作性，可容错性，可检视性，可理解性，复杂性，准确性 C(可审计性，执行效率，自检视性，易培训性，安全性，准确性 D(可审计性，自描述性，自检视性，可理解性，简洁性，模块性 答案 (64)D [分析] 可测试性是指对测试一个软件所需要的工作量的度量。根据McCall定义的软件质量模型，与可测试性有关的软件度量属性有简单性、简明性、模块独立性、自描述性、可修改性和自检性。 另外，还有4个重要的属性需要掌握:可靠性、可维护性、可移植性和复用性。 与可靠性有关的度量属性有一致性、完全性、容错性、准确性、简单性、简明性和模块独立性。 与可维护性相关的度量属性有一致性、简单性、简明性、模块独立性、自描述性、结构性和文档完备性。 与可移植性有关的度量属性有简明性、模块独立性、通用性、可扩充性、机器独立性和软件系统独立性。 与复用性有关的度量属性有自描述性、通用性、可修改性、机器独立性和软件系统独立性。 (65)关于可靠性，以下叙述中正确的是 (65) 。 A(延长MTBF以及缩短MTTR，对于提高设备的有效使用率是有 效的 B(缩短MTYR对于延长MTBF是有效的 C(设备的MTBF是在设备出厂时决定的。此后，MTBF保持不变，用户为了提高可靠性，只能努力缩短MTTR D(如果设备各个部分的故障率都是α，则该设备的故障率就是。 答案 (65)A [分析] 有效性是指系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。有效性的计算公式如下。 有效性,MTTF/(MTTF+MTTR)×100% 其中MTTF指平均失效等待时间，MTTR指失效平均修复时间。试题中 MTBF指平均失效间隔时间MTBF，在这三者之间，有如下公式成立。 MTBF=MTTF+MTTR 因此，如果缩短MTTR，也就缩短了MTBF。而延长MTBF和缩短MTYR，都可延长MTYF，再根据有效性的计算公式，这样可以提高有效性。 随着系统零部件的老化，其MTBF将越来越短，因此答案C是错误的。同时，根据零部件的组合方式不一样(串联或并联)，设备的故障率不一定等于各部件的故障率。 软件复用是使用已有的软件产品(如设计、代码、文档等)来开发新的软件系统的过程。软件复用的形式大体可分为垂直式复用和水平式复用。垂直式复用是指 (66) 中的复用，水平式复用是指 (67) 中的复用。为了提高构件的复用率，通常要求构件具有较好的 (68) 。为了将不同软件生产商在不同软硬件平台上开发的构件组装成一个系统，必须解决异构平台的各构件间的互操作问题。目前国际上已出现了一些支持互操作的构件标准，典型的有国际对象管理组织OMG推荐的 (69) 和Microsoft公司推出的 (70) 。 (66)A(同一软件系统 B(不同软件系统 C(同一应用领域 D(不同应用领域 (67)A(同一软件系统 B(不同软件系统 C(同一应用领域 D(不同应用领域 (68)A(专用性和不变性 B(专用性和可变性 C(通用性和不变性 D(通用性和可变性 (69)A(CORBA B(DCOM C(JavaBeans D(Delphi (70)A(CORBA B(DCOM C(JavaBeans D(Delphi 答案 (66)C (67)D (68)D (69)A (70)B [分析] 软件复用是使用已有的软件产品(如设计、代码、文档等)来开发新的软件系统的过程。软件复用的形式大体可分为垂直式复用和水平式复用。水平式复用是复用不同应用领域中的软件元素，例如数据结构、排序算法、人机界面构件等。标准函数库是一种典型的原始的水平式复用机制。垂直式复用是在一类具有较多公共性的应用领域之间复用软件构件。由于在两个截然不同的应用领域之间进行软件复用潜力不大，所以垂直式复用受到广泛关注。 垂直式复用活动的主要关键点在于领域分析:根据应用领域的特征和相似性，预测软件构件的可复用性。一旦根据领域分析确认了软件构件的可复用价值，即可进行软件构件的开发，并对具有可复用价值的软件构件做一般化处理，使它们能够适应新的类似的应用领域。然后将软件构件和它们的文档存入可复用构件库，成为可供未来开发项目使用的可复用资源。 软件复用的范围不仅涉及源程序代码，Caper Jones定义了10种可能复用的软件要素，分别是项目计划、成本估计、体系结构、需求模型和规格说明、设计、源程序代码、用户文档和技术文档、用户界面、数据结构和测试用例。 可复用构件库的组织方式有枚举分类、关键词分类、多面分类、超文本组织法和可复用构件的3C模型。其中，3C指概念(concept)、内容(content)和语境(context)。 软件构件的复用的步骤可分为检索与提取构件、理解与评价构件、修改构件和构件的合成。其中构件的合成又分为基于功能的合成技术和基于数据的合成技术。 软件复用形式大体上可分为垂直式复用和水平式复用，垂直式复用是指在同一应用领域中的复用;水平式复用是指在不同的应用领域中复用通用的部件。 目前流行的构件技术能有效地支持软件复用。为了提高构件的复用率，通常要求构件具有较好的通用性和可变性。通用性越好，其被复用的面越广。可变性越好，构件就越易于调整，以便适用于应用的具体环境。 为了将不同软件生产商在不同软硬件平台上开发的构件组装成一个应用系统，必须解决异构平台的各构件间的互操作问题，目前已出现了一些支持互操作的构件标准，三个主要流派为OMG的CORBA、Microsoft的COM/DCOM和Sun的EJB/J2EE。 (71) (71) 方面的内容应写入信息系统的操作手册。 A(信息系统的功能说明和输入数据的处理过程 B(信息系统的软件配置以及各部分的内部结构 C(按屏幕变迁过程解释处理过程 D(在厂商发布系统升级时，说明提供的服务过程 答案(71)C [分析] 操作手册为操作人员提供软件各种运行情况的相关知识，特别是操作方法细节。显然，数据的处理过程、软件各部分的内部结构以及提供的服务过程等不适合写在操作手册中。 对于管理信息系统，为提高MIS开发效益和质量，可以有以下技术和方法来支持:采用 (72) ，可改进用户和开发者之间由于需要变化而引起修改和定义不准确等问题;采用 (73) ，可根据基本实体的构造来建立合理的系统结构;采用 (74) ，可使系统的开发变为定义和描述过程，而不是详细的编程过程;采用 (75) ，可为开发者提供各种有效操作手段和工具;采用 (76) ，有利于防止系统开发各阶段的错误扩展。 (72) A(软件评审 B(结构程序设计 C(快速原型方法 D(软件测试 (73) A(软件评审 B(结构程序设计 C(快速原型方法 D(面向对象设计 (74) A(软件评审 B(结构程序设计 C(第四代语言 D(PERT图方法 (75) A(软件评审 B(结构程序设计 C(快速原型方法 D(人机交互友好接口 (76)A(软件评审 B(结构程序设计 C(快速原型方法 D(软件测试 答案 (72)C (73)D (74)C (75)D (76)A [分析] 开发管理系统MIS，有许多技术和方法可用来提高效益和质量，这些技术包括快速原型方法，可改进用户和开发者之间由于需求变化而引起不准确的问题;面向对象设计，可根据基本实体的构成来建立系统结构;使用第四代语言 4GL，可将详细的编程过程转变成定义和描述过程;使用人机交互良好接口，可以提供给开发者各种有效的操作手段和工具;而软件评审方法，有利于防止系统在开发各个阶段上的错误扩散，保证系统开发的正确性和可靠性。 软件项目的进度管理有许多方法，但 (77) 不是常用的进度控制图示方法。在几种进度控制方法中， (78) 难以表达多个子任务之间的逻辑关系，使用 (79) 不仅能表达子任务间依赖关系，还可找出关键子任务。在 (79) 中，箭号表示 (80) ，圆圈结点表示 (81) 。 (77)A(甘特图 B(IPO C(PERT D(时标网状图 (78) A(甘特图 B(IPO C(PERT D(时标网状图 (79) A(甘特图 B(IPO C(PERT D(时标网状图 (80)A(数据流 B(控制流 C(事件 D(处理 (81) A(数据流 B(控制流 C(事件D(起点或终点 答案 (77)B (78)A (79)C (80)C (81)D [分析] 软件项目的组织工作是复杂的，工作的计划进度与实际进度需要用有效的方式加以表达，以利于进度的控制。甘特图(Gantte Chart)、PERT图(Plan Evaluation and Review Technique)和时标网状图(Time Scalar Net work)是几种常用的进度控制图示方法。而IPO是指结构化设计中变换型结构的输入 (Input)、加工(Processing)、输出(Output)。 图9-13是一个甘特图，甘特图以水平线段表示子任务的下作阶段，线段的起点和终点分别对应着子任务的开工时间和完成时间，线段的长度表达了完成任务所需的时间。 从甘特图上可以看出各子任务在时间上的对比关系。但甘特图难以表达多个任务之间的逻辑关系。在 甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而足以必须交付应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。 PERT图不仅可以表达子任务的计划安排，还可在任务计划执行过程中估计任务完成的形势，分析某些子任务完成情况对全局的影响，找出影响全局的区域和关键子任务，以便及早采取措施，确保整个任务的完成。 图9-14是一个PERT图的例子。在PERT图中，用箭号表示事件，即要完成的任务。箭头旁给出子任务的名称和完成该子任务所需要的时间。用圆圈结点表示事件的起点和终点。 时标网状图克服了甘特图的缺点，用带有时标的网状图表示各子任务的进度情况，以反映各子任务在进度上的依赖关系。 风险分析和管理是软件开发的一项重要活动。在软件工程领域考虑风险时，主要基于以下三个概念: (82) 以及必须抓住选择机会。实践中存在许多种软件风险，如“潜在的设计、实现、维护等方面的问题”属于 (83) 风险;“开发了一个没有人真正需要的优秀产品”属于 (84) 风险;“开发的产品不再符合公司的整体商业策略”属于 (85) 风险。通常在软件项目开发过程中，我们希望首先实现 (86) 的用例。 (82)A(关心当前，关心变化 B(关心当前，关心不变性 C(关心未来，关心变化 D(关心未来，关心不变性 (83) A(技术 B(过程 C(项目 D(商业 (84) A(技术 B(过程 C(项目 D(商业 (85) A(技术 B(过程 C(项目 D(商业 (86) A(风险最小 B(风险最大C(风险中等 D(任意风险 答案 (82)C (83)A (84)D (85)D (86)B [分析] 风险是指可能给项目的成功带来威胁或损失的情况，而风险管理是指在风险给项目带来损失之前，就指明、评估并对风险加以控制，使用工具和方法把项目风险限制在一个可接受的范围内。风险分析实际上就是一系列风险管理步骤，其中包括风险识别、风险估计、风险优化、风险管理策略、风险解决和风险监督。这些步骤贯穿在软件工程过程中。 用各种不同的方法对风险进行分类是可能的。从宏观上来看，可将风险分为项目风险、技术风险和商业风险。 项目风险是指潜在的预算、进度、个人(包括人员和组织)、资源、用户和需求方面的问题，以及它们对软件项目的影响。项目复杂性、规模和结构的不确定性也构成项目的(估算)风险因素。 技术风险是指潜在的设计、实现、接口、检验和维护方面的问题。此外，规格说明的多义性、技术上 的不确定性、技术陈旧、最新技术(不成熟)也是风险因素。 商业风险威胁到待开发软件的生存能力。5种主要的商业风险是:开发的软件虽然很优秀但不是市场真正所想要的(市场风险);开发的软件不再符合公司的整个软件产品战略(策略风险);开发了销售部门不清楚如何推销的软件;由于重点转移或人员变动而失去上级管理部门的支持(管理风险);没有得到预算或人员的保证(预算风险)。 特别要注意，有时对某些风险不能简单地归类，而且某些风险事先是无法预测的。 风险估计从两个方面估价每一种风险。一是估计一个风险发生的可能性。一是估价与风险相关的问题出现后将会产生的结果。通常，项目计划人员与管理人员、技术人员一起，进行4种风险估计活动:建立一个尺度来表明风险发生的可能性;描述风险的后果;估计风险对项目和产品的影响:指明风险估计的正确性以便消除误解。 风险估计的具体方式是建立风险表进行风险评价，在进行风险评价时，可建立一系列三元组[R，P，iiS。其中，R是风险，P是风险出现的可能性(概率)，而S是风险产生的影响。在做风险评价时，应进一iiii 步审查在风险估计时所得到的估计的准确性，尝试对已发现的风险设置优先级，按优先级排队。 风险缓解是一种问题回避活动。风险监控是一种项目追踪活动，它有三个主要目标:判断一个预测的风险事实上是否发生了;确保针对某个风险而制定的风险消除步骤正在合理地使用;收集可用于将来的风险分析的信息。 软件项目的开始经常采用迭代的增量式开发，在安排增量式开发计划时，通常采用高风险优先的原则，即让高风险的用例尽早实现，不要把风险留到最后。 (87)系统开发过程通常被分为若干个阶段，每个阶段的开始和结束都有明确的规定。人们常将开发过程中完成某项关键工作的时刻称为里程碑。完成 (87) 时最适于称为里程碑。 A(需求调查 B(总体设计稿 C.一套实体关系图 D(50%的编码 答案 (87)B [分析] 里程碑(又称为基线)是软件生存周期中各开发阶段末尾的特定点。由正式的技术评审而得到的软件配置项和软件配置的正式文本才能成为里程碑。里程碑的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，以便于检验和肯定阶段成果。 软件开发进程中可以设置许多里程碑，里程碑为管理人员提供了指示项目进度的可靠依据。当一个软件工程任务成功地通过了评审并产生了文档之后，一个里程碑就完成了。因此，一般来说，文档编制与评审是软件开发进度的里程碑。 (88)项目管理工具能对项目的任务调度、成本估算、资源分配、预算跟踪、人时统计、配置控制等活动给予帮助，它具有很多特征，但 (88) 不是其特征。 A(覆盖整个软件生存周期 B(指导软件设计人员按软件生存周期各个阶段的适用技术进行设计工作 C(确定关键路径、松弛时间、超前时间和滞后时间 D(生成固定格式的报表和裁剪项目报告 答案 (88)B [分析] 项目管理工具能对项目的任务调度、成本估算、资源分配、预算跟踪、人时统计、配置控制等活动给予帮助，它能覆盖整个软件生存周期。因为要对进度进行管理，所以项目管理工具必须能确定关键路径、松弛时间、超前时间和滞后时间等基本信息。同时，项目管理工具还需要生成一定格式的报表和报告，但项目管理工具不能指导软件设计人员按软件生存周期各个阶段的适用技术进行设计工作。 多个软件工程师合作开发一个项目，各开发者之间需要两两互相通信。假设每一条通信路径的开销为200LOC/年(LOC为代码行数)。设有4名软件工程师，如果单独工作，每个人的生产率是6000 LOC/年，那么由这4名软件工程师组成的项目组的生产率为 (89) 。在这一年期限的最后两个月，又增加了两名工程师，新增成员的个人生产率为3000 LOC/年，那么这6人组成的项目组全年完成的开发工作量为 (90) 。 (89)A(28000LOC/年 B(24000LOC/年 C(22800LOC/年 D(21500LOC/年 (90)A(21000LOC B(23000LOC C(23500LOC D(24500LOC 答案 (89)C (90)C [分析] 在4名软件工程师之间建立通信路径如图9-15所示。 也就是说，这4名软件工程师之间需要建立4×(4-1)/2,6条通信路径，因假设每一条通信路径的开销为2001 LOC/年，所以共计花费200×6,1200 LOC/年。已知每个人的生产率是6000 LOC/年，则共计生产率为4×6000-1200,22800 LOC/年。 如果从第11月开始，增加2个人，则通信路径增加6×(6-1)/2-6=9条。增加通信开销为200/12×2×9,300 LOC。而这2个人的开发工作量为3000/12×2×2,1000 LOC，所以，总计工作量为22800+1000-300=23500 LOC。 净室软件工程(Cleanroom)是软件开发的一种形式化方法，可以开发较高质量的软件。它使用 (91) 进行分析和建模，并且将 (92) 作为发现和排除错误的主要机制。使用 (93) 测试来获取认证软件可靠性所需要的信息。 (91)A(产生式归约 B(移进归约 C(盒结构归约D(规范归约 (92)A(正确性验证 B(黑白盒测试 C(集成测试 D(基本路径测试 (93)A(边界值 B(统计 C(代数 D(精确 答案 (91)C (92)A (93)B [分析] 净室软件工程是软件开发的一种形式方法，它可以生成质量非常高的软件。它使用盒结构规约(或形式化方法)进行分析和设计建模，并且强调将正确性验证，而不是测试，作为发现和消除错误的主要机制。使用统计的测试来获取认证被交付软件的可靠性所必需的出错率信息。 净室方法从使用盒结构表示的分析和设计模型入手，一个“盒”在某特定的抽象层次上封装系统(或系统的某些方面)。黑盒用于表达系统的对外可观测行为，状态盒封装状态数据和操作，清晰盒用于对某状态盒中的数据和操作所蕴涵的过程设计进行建模。 一旦完成了盒结构设计，则运用正确性验证。软件构件的过程设计被划分为一系列子函数，为了证明每个子函数的正确性，要为每个函数定义出口条件并实施一组子证明。如果每个出口条件均被满足，则设计一定是正确的。 一旦完成了正确性验证，便开始统计的使用测试。和传统测试不同，净室软件工程并不强调单元或集成测试，而是通过定义一组使用场景、确定对每个场景的使用概率及定义符合概率的随机测试来进行软件测试。将产生的错误记录和取样、构件和认证模型相结合使得可以数学地计算软件构件的可靠性。 净室哲学是一种严格的软件工程方法，它是一种强调正确性的数学验证和软件可靠性认证的软件过程模型，其目标和结果是非常低的出错率，这是使用非形式化方法难以或不可能达到的。 通常，软件开发环境可由环境机制和工具集构成。按功能划分，环境机制又可分为 (94) ;工具集也可分为贯穿整个开发过程的工具和解决软件生命周期中某一阶段问题的工具，分别属于上述两类工具的是 (95) 。软件开发环境的核心是 (96) 。软件开发环境具有集成性、开放性、 (97) 、数据格式一致性、风格统一的用户界面等特性，因而能大幅度提高软件生产率。其中开放性是指 (98) 。 (94)A(环境操作系统、环境信息库、用户界面规范 B(环境信息库、过程控制和消息服务、用户界面规范 C(环境操作系统、环境规格描述语言、过程控制和消息服务 D(环境规格描述语言、过程控制和消息服务、数据集成 (95)A(DFD、PDL B(HIPO图、OOA C(文档管理工具、PAD图 D(软件项目管理工具、软件价格模型及估算工具 (96)A(环境操作系统 B(环境信息库 C(环境规格描述语言 D(用户界面规范 (97)A(可裁减性 B(完整性 C(封闭性 D(独立性 (98)A(允许使用不同的硬件平台 B(允许使用不同的操作系统 C(允许使用不同的网络系统 D(允许其他的软件工具加入到软件开发环境之中 答案 (94)B (95)D (96)B (97)A (98)D [分析] 软件开发环境应该包括工具集成、界面集成和方法集成。通常，软件开发环境可由环境机制和工具集构成。按功能划分，环境机制又可分为环境信息库、过程控制和消息服务、用户界面规范。其中环境信息库存储软件工程项目在生存周期中的全部信息，是软件开发环境的核心。 工具集包括事务系统规划工具、项目管理工具、支撑工具、分析设计工具、程序设计工具、测试工具、原型建造工具、维护工具和框架工具等，所有这些工具可分为贯穿整个开发过程的工具(例如软件项目管理工具)和解决软件生命周期中某一阶段问题的工具(例如软件价格模型及估算工具)。 软件开发环境具有集成性、开放性、可裁减性、数据格式一致性、风格统一的用户界面等特性，因而能大幅度提高软件生产率。其中开放性是指允许其他的软件工具加入到软件开发环境之中。 软件方法学是以软件方法为研究对象的学科。从开发风范上看，可分为 (99) 。从性质上看，可分为 (100) 。从适应范围来看，可分为 (101) 。 形式方法的目的是把软件作为数学来重新发现。形式方法被用来避免系统中的 (102) 、不一致性。 软件自动化方法是指利用计算机使软件的设计实现自动化的方法和相关的技术。软件自动化的实现途径有四种:过程途径、归纳途径、 (103) 。 (99)A(面向对象开发方法与自底向上的开发方法 B(自顶向下的开发方法与结构化开发方法 C(面向对象开发方法与结构化开发方法 D(自顶向下的开发方法与自底向上的开发方法 (100)A(面向对象开发方法与形式方法 B(面向对象开发方法与结构化开发方法 C(形式方法与非形式方法 D(面向对象开发方法与非形式方法 (101)A(整体性方法与局部性方法 B(面向对象开发方法与结构化开发方法 C(面向对象开发方法与非形式方法 D(形式方法与非形式方法 (102)A(歧义性、不完全性 B(歧义性、不安全性 C(歧义性、不适应性 D(歧义性、不可靠性 (103)A(演绎途径、编译途径 B(转换途径、编译途径 C(编译途径、解释途径 D(演绎途径、转换途径 答案 (99)D (100)C (101)A (102)A (103)D [分析] 软件方法学是以软件方法为研究对象的学科。从开发方法上看，可分为自顶向下开发方法和自底向上开发方法。自顶向下开发方法强调开发过程是由问题到解答、由总体到局部、由一般到具体;自底向上开发方法从系统实现的最基础部分着手，由简单到复杂，逐层向上构造，直至得到所需的软件。 从性质上看，软件方法学可分为形式方法与非形式方法，形式方法是建立在严格数学基础上的软件开发方法。在软件开发的各个阶段中，凡是采用严格的数学语言，具有精确的数学语义的方法，称为形式方法。采用形式方法可避免系统中的歧义性、不完全性和不一致性。而非形式方法则不把严格作为其主要着眼点。 从适用范围上看，软件方法学可分为整体性方法和局部性方法。整体性方祛适用于软件开发的全过程，如自顶向下方法、自底向上方法、软件自动化方法;局部性方法适用于软件开发过程的某个具体阶段，如各种需求分析方法、设计方法等。 软件自动化方法是尽可能借助计算机系统实现软件开发的方法。也可狭义地理解为从形式的软件功能规约到可执行的程序代码这一过程的自动化，其实现途径主要有过程途径(过程实现)、演绎途径(演绎综合)、转换途径(程序转换)、归纳途径(归纳综合)等。 随着软件开发工具的积累与自动化工具的增多，软件开发环境进入了第三代 ICASE (integrated Computer-Aided Software Engineering)阶段。ICASE信息库 (repository)不仅定义了面向对象的数据库管理系统，提供了 (104) 机制，还建立了可以被环境中所有工具访问的数据模型，提供了 (105) 机制，实现了配置管理功能。 (104)A(平台集成 B(控制集成 C(数据—工具集成 D(数据—数据集成 (105)A(平台集成 B(控制集成 C(数据—工具集成 D(数据—数据集成 答案 (104)D (105)C [分析] 随着软件开发工具的积累与自动化工具的增多，软件开发环境进入了第三代ICASE (Integrated Computer-Aided Software Engineering)。系统集成方式经历了从数据交换(早期CASE采用的集成方式:点到点的数据转换)到公共用户界面(第二代CASE:在一致的界面下调用众多不同的工具)，再到目前的信息中心库方式。这是ICASE的主要集成方式。它不仅提供数据集成(1991年 IEEE为工具互联提出了标准P1175)和控制集成(实现工具间的调用)，还提供了一组用户界面管理设施和一大批工具，如垂直工具集(支持软件生存期各阶段，保证生成信息的完备性和一致性)、水平工具集(用于不同的软件开发方法)以及开放工具槽。 ICASE信息库是一组实现“数据-工具”以及“数据-数据”集成的机制和数据结构，它提供了明显的数据库管理系统的功能。此外，中心库还可完成下面功能。 (1)数据完整性 包括确认中心库的数据项，保证相关对象间的一致性，以及当对一个对象的修改需要对其相关对象进行某些修改时，自动完成层叠式修改等功能。 (2)信息共享提供在多个开发者和多个开发工具间共享信息的机制，管理和控制对数据及加锁解锁对象的多用户访问，使得修改不会被相互间不经意地覆盖。 (3)数据—工具集成 建立可以被环境中所有工具访问的数据模型，控制对数据的访问，实现配置管理 功能。 (4)数据—数据集成 数据库管理系统建立数据对象间的关系，使得可以完成其他功能。 (5)方法学实施 存储在中心库中的数据的E-R模型可能蕴涵了特定的软件工程范型——至少，关系和对象定义了一系列为了建立中心库的内容而必须进行的步骤。 (6)文档标准化 在数据库中对象的定义直接导致了创建软件工程文档的标准方法。 ICASE的最终目标是实现应用软件的全自动开发，即开发人员只要写好软件的需求规格说明书，软件开发环境就自动完成从需求分析开始的所有的软件开发工作，自动生成供用户直接使用的软件及有关文档。 原型化方法是用户和设计者之间执行的一种交互过程，适用于 (106) 系统。它从用户界面设计开始，首先形成 (107) ，用户 (108) 并就 (109) 提出意见。它是一种 (110) 型的设计过程。 (106)A(需求不确定性高的 B(需求确定的 C(管理信息 D(决策支持 (107)A(用户界面使用手册 B(界面需求分析说明书 C(系统界面原型 D(完善的用户界面 (108)A(改进界面的设计 B(阅读文档资料 C(模拟界面的运行 D(运行界面原型 (109)A(同意什么和不同意什么 B(使用和不使用哪种编程语言 C(程序的结构 D(执行速度是否满足要求 (110)A(自外向内 B(自顶向下 C(自内向外 D(自底向上 答案 (106)A (107)C (108)D (109)A (110)A [分析] 原型化方法的定义见试题4的分析。 设计者可以建立一个纸上的模型，也可用一些已有的类似系统作原型，也可建立一个可执行的模型。在可执行的模型中，先建立界面原型是一种很重要的方法。系统设计者先进行界面设计，形成一个系统的界面原型，并在机器上运行该界面原型，让用户就同意什么和不同意什么提出意见。等用户认可了经过反复修改的界面以后，设计者再据此进行进一步的内容功能设计。这种设计是一种自外向内型的设计。 某软件开发从详细设计到集成测试各阶段所需工作量估计(按软件工程师人月数估计)如表9-1所示，这几个阶段分配的软件工程师和程序员人数如表 9-2所示。假设编码与单元测试阶段，软件工程师的生产率是程序员的2倍。若在该项目的这几个阶段都增加一名软件工程师，则这几个阶段可以缩短 (111) 个月完成任务(假定各个开发阶段串行工作)。 表9-1 所需工作量估计 开发阶段 估计所需人月数 6 详细设计 12 编码与单元测试 12 集成测试 30 合计 表9-2 分配的软件工程师和程序员人数 分组人数 开发阶段 软件工程师 程序员 2 0 详细设计 2 2 编码与单元测试 2 0 集成测试 A(1 B(2 C(3 D(4 答案 (110)D [分析] 因为试题已经假定各开发阶段串行工作，所以只要根据表9-1和表9-2，逐阶段计算就可以了。 (1)详细设计需要6软件工程师人月，但只分配2名软件工程师，所以需要3个月。 (2)编码与单元测试需要12软件工程师人月，但只分配2名软件工程师和2名程序员。因为在编码与单元测试阶段，软件工程师的生产率是程序员的 2倍，即2名程序员相当于1名软件工程师，因此共需4个月。 (3)集成测试需要12软件工程师人月，但只分配2名软件工程师，所以需要6个月。 以上三个阶段合计13个月。若在该项目的这几个阶段都增加一名软件工程师，则 (1)详细设计需要6软件工程师人月，分配3名软件工程师，所以需要2个月。 (2)编码与单元测试需要12软件工程师人月，分配3名软件工程师和2名程序员。因为在编码与单元测试阶段，软件工程师的生产率是程序员的2倍，即2名程序员相当于1名软件工程师，因此共需3个月。 (3)集成测试需要12软件工程师人月，分配3名软件工程师，所以需要4个月。 以上合计9个月，即这几个阶段可以缩短4个月完成任务。 在各种不同的软件需求中， (112) 描述了用户使用产品必须要完成的任务，可以在用例模型中予以说明。软件需求说明书是需求分析阶段的成果， (113) 不是其应包含的内容。 (112)A(业务需求 B(非功能需求 C(用户需求 D(功能需求 (113)A(数据描述 B(功能描述 C(系统结构描述 D(性能描述 答案 (112)C (113)C [分析] 开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细的技术需求，这包括所有面向用户、面向机器和其他软件系统的接口。同时，这也是一旦出错，将最终会给系统带来极大困难的部分，并且以后再对它进行修改也极为困难。 软件需求可以分为几个层次，分别如下。 (1)业务需求(business requirements) 反映组织结构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 (2)用户需求(user requirements) 描述用户使用产品必须完成的任务，在用例文档或方案场景(scenario)说明中予以说明。 (3)功能需求(functional requirements) 定义开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。 (4)非功能需求(none-functional requirements) 描述系统展现给用户的行为和执行的操作等。包括， ?产品必须遵循的标准、规范和合约; ?外部界面的具体细节; ?性能要求; ?设计或实现的约束条件; ?质量属性。 软件需求说明书(SRS)是需求分析阶段的成果，不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。可以使用以下三种方法编写软件需求规格说明。 (1)用好的结构化和自然语言编写文本型文档。 (2)建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。 (3)编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。 由于形式化规格说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少数软件开发人员才熟悉，更不用说客户了。虽然结构化的自然语言具有许多缺点，但在大多数软件工程中，它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图，增强了软件需求规格说明。 软件测试是为了发现错误而执行程序的过程。检验软件是否满足用户需求的测试称为 (114) 。 (115) 是维护中常用的方法，其目的是检验修改所引起的副作用。黑盒测试法主要根据 (116) 来设计测试用例。 (114)A(确认测试 B(有效性测试 C(系统测试 D(集成测试 (115)A(回归测试 B(模块测试 C(功能测试 D(结构测试 (116)A(程序数据结构 B(程序流程图 C(程序内部逻辑 D(程序外部功能 答案 (114)A (115)A (116)D [分析] 软件测试是软件质量保证的主要手段之一，也是在将软件交付给客户之前所必须完成的步骤。软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品(主要是指程序)中的错误和缺陷。 从测试阶段划分，可分为单元测试、集成测试、确认测试。 (1)单元测试 也称模块测试，通常可放在编程阶段，由程序员对自己编写的模块自行测试，检查模块是否实现了详细设计说明书中规定的功能和算法。单元测试主要发现编程和详细设计中产生的错误，单元测试计划应该在详细设计阶段制定。单元测试期间着重从以下几个方面对模块进行测试:模块接口;局部数据结构;重要的执行通路;出错处理通路;边界条件等。 (2)集成测试 也称组装测试，它是对由各模块组装而成的程序进行测试，主要目标是发现模块间的接口和通信问题。集成测试主要发现设计阶段产生的错误，集成测试计划应该在概要设计阶段制定。集成的方式可分为非渐增式和渐增式，渐增式集成又可分为自顶向下集成和自底向上集成。 (3)确认测试 主要依据软件需求说明书检查软件的功能、性能及其他特征是否与用户的需求一致。确认测试计划应该在需求分析阶段制定。 软件配置复查是确认测试的另一项重要内容。复查的目的是保证软件配置的所有成分都已齐全，质量符合要求，文档与程序完全一致，具有完成软件维护所必需的细节。 如果一个软件是为某个客户定制的，最后还要由该客户来实施验收测试，以便确认其所有需求是否都已得到满足。由于软件系统的复杂性，在实际工作中，验收测试可能会持续到用户实际使用该软件之后的相当长的一段时间。 如果一个软件是作为产品被许多客户使用的，不可能也没必要由每个客户进行验收测试。绝大多数软件开发商都使用被称为。测试和D测试的过程，来发现那些看起来只有最终用户才能发现的错误。 α测试由用户在开发者的场所进行，并且在开发者的指导下进行测试。开发者负责记录发现的错误和使用中遇到的问题。也就是说，α测试是在“受控的”环境中进行的。 β测试是在一个或多个用户的现场由该软件的最终用户实施的，开发者通常不在现场，用户负责记录发现的错误和使用中遇到的问题并把这些问题报告给开发者。 经过确认测试之后的软件通常就可以交付使用了。 从测试方法划分，可分为白盒测试、黑盒测试。 (1)白盒测试 又称结构测试，(主要用于单元测试阶段。它的前提是可以把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。这种方法按照程序内部逻辑设计测试用例，程序中的主要执行通路是否都能按预定要求正确工作。 白盒测试常用的技术是逻辑覆盖，即考察用测试数据运行被测程序时对程序逻辑的覆盖程度。主要的覆盖标准有6种:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合条件覆盖和路径覆盖。 (2)黑盒测试 又称功能测试，主要用于集成测试和确认测试阶段。它把软件看作一个不透明的黑盒子， 完全不考虑(或不了解)软件的内部结构和处理算法，它只检查软件功能是否能按照软件需求说明书的要求正常使用，软件是否能适当地接收输入数据并产生正确的输出信息，软件运行过程中能否保持外部信息(例如文件和数据库)的完整性等。 常用的黑盒测试技术包括等价类划分、边值分析、错误推测和因果图等。 在实际应用中，一旦纠正了程序中的错误后，还应选择部分或全部原先已测试过的测试用例，对修改后的程序重新测试，这种测试称为回归测试。 (117)软件项目管理中可以使用各种图形工具，在以下关于各种图形工具的论述中正确的是 (117) 。 A(流程图直观地描述了工作过程的具体步骤，以及这些步骤之间的时序关系，可以用于控制工作过程的完成时间。 B(PERT图画出了项目中各个活动之间的时序关系，可用于计算工程项目的关键路径，以便控制项目的进度。 C(因果分析图能表现出软件过程中各种原因和效果之间的关系，并且表现了它们随时间出现的顺序和重要程度，这些数据可用于改进软件过程的性能。 D(Gantte图为整个项目建立了一个时间表，反映了项目中的所有任务之间的依赖关系以及各个任务的起止日期，这些信息可用于项目的任务调度。 答案 (117)B [分析] 软件项目管理中可以使用各种图形工具，例如流程图，PERT图、Gantte图、因果分析图等。 流程图可以直观地描述工作过程的具体步骤，以及这些步骤之间的关系，帮助我们预测在何处可能发生何种质量问题，并由此帮助开发处理他们的办法。但流程图不能用于控制工作过程的完成时间。 PERT技术(计划评审技术)是安排开发进度，制定软件开发计划的最常用的方法。PERT图采用网络图来描述一个项目的任务网络，也就是从一个项目的开始到结束，把应当完成的任务用图或表的形式表示出来。通常用两张表来定义网络图。一张表给出与—特定软件项目有关的所有任务(也称为任务分解结构)，另一张表给出应当按照什么样的次序来完成这些任务(也称为限制表)， 在项目的早期阶段，PERT图对于组织任务、建立时间框架，反映项目中的所有任务之间的依赖关系十分有用。PERT技术为项目计划人员提供了一些定量的工具。 (1)确定关键路径，即决定项目开发时间的任务链。 (2)应用统计模型，对每一个单独的任务确定最可能的开发持续时间的估算值。 (3)计算边界时间，以便为具体的任务定义时间窗口。边界时间的计算对于软件项目的计划调度是非常有用的。 因果分析图又称特性要因图，因其形状像树枝或鱼骨，故又称鱼骨图、鱼刺图、树枝图，是分析质量问题产生原因的有效工具。因果分析图描述相关的各种原因和子原因如何产生潜在问题或影响，但不能表现它们随时间出现的顺序和重要程度。因果图的做法是将要分析的问题放在图形的右侧，用一条带箭头的主干指向要解决的质量问题，一般从人、设备、材料、方法、环境五个方面进行分析。对具体问题来讲，这五个方面的原因不一定同时存在，要找到解决问题的方法，还需要对上述五个方面进一步分解。它们之间的关系也用带箭头的箭线表示。 Gantte图(甘特图)用水平线段表示任务的工作阶段:线段的起点和终点分别对应着任务的开工时间和完成时间;线段的长度表示完成任务所需的时间。随着项目的进展，Gantte图可以指明已完成的任务(纵线扫过的)和有待完成的任务(纵线尚未扫过的)。从Gantte图上可以很清楚地看出各子任务在时间上的对比关系。在Gantte图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是必须交付应交付的文档与通过评审为标准。因此在 Gantte图中，文档编制与评审是软件开发进度的里程碑。Gantte图的优点是标明了各任务的计划进度和当前进度，能动态地反映软件开发进展情况。缺点是难以反映多个任务之间存在的复杂的逻辑关系。 对软件开发的看法可有多种观点，敏捷软件开发方法是一种 (118) ，代表性是极限编程XP，它的核心思想为 (119) 。 (118)A(数学观 B(建模观 C(工程观 D(协作游戏 (119)A(强调文档和以敏捷性应对变化 B(强调建模和以敏捷性应对变化 C(强调设计和以敏捷性应对变化 D(强调人和人之间的合作的因素和以敏捷性应对变化 答案 (118)D (119)D [分析] 在我们面临“软件危机”所带来的挑战之时，曾经通过采用严格的规范、详尽的文档来约束开发过程，以保证开发的质量与效果，获得了突出的成就。但是随着时代的进一步发展，商业周期越来越短，变化越来越快，甚至在软件开发的过程中，商业逻辑和需求已经悄然变化，这给本来还不成熟的软件产业带来了新的挑战。正在这种情况下，敏捷方法论应运而生。 2001年这些方法论的创始人走到一起，成立了敏捷联盟，发表了颇具影响力的敏捷宣言:个体和交互胜过过程和工具，可工作的软件胜过面面俱到的文档，客户合作胜过谈判，响应变化胜过遵循计划。比较有影响力的敏捷方法论包括XP(极限编程)、FDD(特征驱动开发)、Crystal Method(水晶方法)、 DSDM(动态系统开发方法)、ASD(自适应开发)、Scrum等。 XP的核心是其总结的沟通、简单、反馈、勇气四大价值观。它包括12种最佳实践:计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户以及编码标准。 ?至?是风险管理中的4个活动，其恰当的顺序是 (120) 。风险识别的一个方法是 (121) 。 ?选择风险管理工具 ?研究风险处理方法 ?评估风险处理结果 ?风险识别、确认和度量 (120)A(??????? B(??????? C(??????? D(??????? (121)A(定义风险参照水准 B(预测风险组合 C(建立风险条目检查表 D(制定风险尺度 答案 (120)D (121)C [分析] 项目风险管理实际上就是贯穿在项目开发过程中的一系列管理步骤，其中包括风险识别、风险估计、风险管理策略、风险解决和风险监控。它能让风险管理者主动“攻击”风险，进行有效的风险管理。 在项目管理中，建立风险管理策略和在项目的生命周期中不断控制风险是非常重要的，风险管理包括四个相关阶段。 (1)风险识别 风险管理的第一步是识别和评估潜在的风险领域，这是风险管理中最重要的步骤。风险识别包括列出所有与项目相关的过程、客户及存在的问题;确定风险的来源、产生条件。风险识别不是一次就可以完成的事，应自始至终定期进行。识别风险的一种最好的方法就是利用一组提问来帮助项目计划人员了解在项目和技术方面有哪些风险。因此，Boehm建议使用一个“风险项目检查表”，列出所有可能的与每一个风险因素有关的提问，从产品规模、商业影响、客户特性、过程定义、开发环境、建造技术、人员数量及经验等几个方面识别已知的或可预测的风险。常用的风险识别方法有问询法(头脑风暴法、面谈法等)、财务报表法(各种财务报表和记录)、流程图法(网络图或 WBS法)、现场观察、历史资料(索赔记录及其他风险信息)、环境分析法(相关方和社会环境变化趋势，可能变更的法律法规)等。 (2)风险评估 对已识别的风险要进行估计和评价，风险估计的主要任务是确定风险发生的概率与后果，风险评价则是确定该风险的经济意义及处理的费/效分析。常用的风险评估方法有概率分布(专家预测)、外推法(使用历史数据)、定性评估、矩阵图分析、风险发展趋势评价方法、项目假设前提评价及数据准确度评估。 (3)风险量化和处理 依据风险管理计划、风险及风险条件排序表、历史资料、专家判断及其他计划结果，利用面谈、灵敏度分析、决策分析和模拟的方法和技术，得出量化序列表，项目确认研究，以及所需应急资源等量化结果。风险量化后，要进行风险评价，常用方法有项目风险费用分析、项目风险评价准则、 风险评价的策略分析法、风险评价的层次分析。一般而言，风险处理有三种方法:?风险控制法，即主动采取措施避免风险，消灭风险，中和风险或采用紧急方案降低风险。?风险自留，当风险量不大时可以余留风险。?风险转移。 (4)风险监控 风险监控就是要跟踪识别的风险，识别剩余风险和出现的风险，修改风险管理计划，保证风险计划的实施，并评估消减风险的效果，包括对风险发生的监督和对风险管理的监督，前者是对已识别的风险源进行监视和控制，后者是在项目实施过程中监督人们认真执行风险管理的组织和技术措施; 按照试题给出的4个活动，其对应的顺序应该首先识别风险，然后研究风险处理方法，选择风险管理工具，最后再评估风险处理结果。 (122)逆向工程可用于维护已有的软件，逆向工程能够 (122) 。 A(分析源程序，决定需要修改的部分及其影响的程度 B(能够使用数学方法证明各软件功能的正确性 C(分析源程序，从源程序导出程序结构 D(将源程序改写成易于理解的、结构清晰的程序 答案 (122)C [分析] 我们首先看两个概念。 逆向工程(Reverse Engineering，反向工程)的概念来自硬件。硬件厂商总想弄到竞争对手产品的设计和制造的“奥秘”，但是又得不到现成的档案，只好拆卸对手的产品并进行分析，导出该产品的一个或多个设计与制造的规格说明。软件的逆向工程是完全类似的，由于受到法律的约束，进行逆向工程的程序常常不是竞争对手的，而是自己开发的程序，有些是多年以前开发出来的。这些程序没有规格说明，对它们的了解很模糊。因此，软件的逆向工程是分析程序，力图在比源代码更高的抽象层次上建立程序表示的过程。逆向工程是一个设计恢复的过程，其工具可以从已有的程序中抽取数据结构、体系结构和程序设计信息。 再工程(Re-engineering)不仅能从已有的程序中重新获得设计信息，而且还能使用这些信息改建或重构现有的系统，以改进它的综合质量。一般软件人员利用再工程重新实现已存在的程序，同时加进新的功能或改善它的性能。 每一个软件开发机构都会有上百万行的老代码，它们都是逆向工程和再工程的可能对象，但是由于某些程序并不频繁使用而且不需要改变，逆向工程和再工程的工具还处于摇篮时代，仅能对有限种类的应用程序执行逆向工程和再工程，代价又十分昂贵，因此对其库中的每一个程序都进行逆向工程和再工程是不现实的。 软件再工程旨在对现存的大量软件系统进行挖掘、整理以得到有用的软件构件，或对已有软件构件进行维护以延长其生存期。它是一个工程过程，能够将逆向工程、重构和正向工程组合起来，将现存系统重新构造为新的形式。 再工程的基础是系统理解，包括对运行系统、源代码、设计、分析和文档等的全面理解，但在很多情况下，由于各类文档的丢失，只能对源代码进行理解，即程序理解。 为了执行预防性维护，软件开发组织必须选择在最近的将来可能变更的程序，做好变更它们的准备，逆向工程和再工程可用于执行这种维护任务。逆向工程可以从源程序抽取出设计信息，但是，抽象的层次、文档的完整性、工具和分析员一起工作的程度以及过程的方向性却是高度可变的。 逆向工程过程及用于实现该过程的工具的抽象层次是指可从源代码中抽取出来的设计信息的精密程度。理想地，抽象层次应该尽可能高，即逆向工程过程应该能够导出过程的设计表示(一种低层的抽象);程序和数据结构信息 (稍高一点层次的抽象);数据和控制流模型(一种相对高层的抽象);以及实体—关系模型(一种高层抽象)。随着抽象层次增高，软件工程师将获得更有助于理解程序的信息。 逆向工程过程的完整性是指在某抽象层次提供的细节程度。在大多数情况下，随着抽象层次增高，完整性就降低。例如，给定源代码列表，得到一个完整的过程设计表示是相对容易的，简单的数据流表示也可被导出，但是，要得到数据流图或状态—变迁图的完整集合却困难得多。 (123)通常软件项目管理活动包括项目的计划、调度、通信、费用估算、资源分配以及质量控制等，软件 生产是智力密集型的活动，其产品无物理外形，生产状态也“不可见”，因而难以检查和驾驭。软件项目管理工具就是要使这种生产过程成为可见、可控的过程。因此，软件项目管理工具应具备 (123) 。 A(软件生产周期内各活动的识别和分配 B(对的安排、评审和检查 C(对软件设计计划、技术和文档内容进行管理 D(与软件开发工具匹配 答案 (123)B [分析] 软件项目管理工具能对项目的任务调度、成本估算、资源分配、预算跟踪、人时统计、配置控制等活动给予帮助，它能覆盖整个软件生存周期。因为要对进度进行管理，所以项目管理工具必须能确定关键路径、松弛时间、超前时间和滞后时间等基本信息。同时，项目管理工具还需要生成一定格式的报表和报告，但项目管理工具不能指导软件设计人员按软件生存周期各个阶段的适用技术进行设计工作，不必与软件开发工具匹配。 (124)使用自动项目管理工具与使用手工方法管理相比有许多优点，但是 (124) 不属于自动项目管理工具的优点。 A(能对大型项目进行精确跟踪，使项目经理能及时掌握实际工作进展和资源的实际消耗情况 B(能指导设计人员采用软件生存周期各阶段的适用技术，进行设计和控制工程进度 C(能辅助开发PERT、CPM(关键路径方法)和WBS(工作分解结构)，自动更新活动网络图和Gantte图 D(能自动计算、自动积累数据、自动生成图形和报表来取代人工计算、调度、统计和文档工作，提高管理工作效率。 答案 (124)B [分析] 请参考试题43的分析。 (125)若要重构一个功能上和性能上更为完善的改进的软件，可以使用 (125) 。 A(逆向工程工具 B(程序切片工具 C(程序理解工具 D(再工程工具 答案 (125)D [分析] 请参考试题42的分析。 下列要素中，不属于DFD的是 (126) 。当使用DFD对一个工资系统进行建模时， (127) 可以被认定为外部实体。 (126)A(加工 B(数据流 C(数据存储 D(联系 (127)A(接收工资单的银行 B(工资系统源代码程序 C(工资单 D(工资数据库的维护 答案 (126)D (127)A [分析] 请参考试题4的分析。 软件的维护并不只是修正错误。为了满足用户提出的增加新功能、修改现有功能以及一般性的改进要求和建议，需要进行 (128) ，它是软件维护工作的主要部分;软件测试不可能揭露旧系统中所有潜在的错误，所以这些程序在使用过程中还可能发生错误，诊断和更正这些错误的过程称为 (129) ;为了改进软件未来的可维护性或可靠性，或者为了给未来的改进提供更好的基础而对软件进行修改，这类活动称为 (130) 。 (128)A(完善性维护 B(适应性维护 C(预防性维护 D(改正性维护 (129)A(完善性维护 B(适应性维护 C(预防性维护 D(改正性维护 (130)A(完善性维护 B(适应性维护 C(预防性维护 D(改正性维护 答案 (128)A (129)D (130)C [分析] 本题直接考查4种维护的概念，请参考试题12的分析。 (131)质量控制非常重要，但是进行质量控制也需要一定的成本。 (131) 可以降低质量控制的成本。 A(使用抽样统计 B(进行过程分析 C(对全程进行监督 D(进行质量审计 答案 (131)A [分析] 根据PMBOK 2004版，正确的答案是A。由于是抽样统计，节省了大量的质量控制成本。 (132)(2005年下半年试题19)新项目与过去成功开发过的一个项目类似，但规模更大，这时应该使用 (132) 进行项目开发设计。 A(原型法 B(变换模型 C(瀑布模型 D(螺旋模型 答案 (132)C [分析] 新项目与过去成功开发过的一个项目类似，因为已经有了以前开发的经验和积累的软件模块，这些都可以应用到新项目中，因此，应该使用瀑布模型进行项目开发。 根据McCabe环路复杂性度量，程序图9-17的复杂度是 (133) ，对这个程序进行路径覆盖测试，可得到的基本路径是 (134) 。 (133)A(2 B(3 C(4 D(5 (134)A(A-B-C-H-I-K;A-B-C-H-J-K; A-B-C-D-E-F-G B(A-B-C-H-I-K;A-B-C-H-J-K;A-B-C-D-E-F-G-C-H-I-K;A-B-C-D-E-G-C-H-I-K C(A-B-C-H-I-K;A-B-C-H-J-K;A-B-C-D-E-F-G-C-H-I-K;A-B-D-E-G-C-H-J-K D(A-B-C-H-I-K;A-B-C-H-J-K;A-B，C-D-E-F-G-C-H-I-K;A-B-C-D-E-F-G-C，H-J-K;A-B-C-D-E-G-C-H-I-K 答案 (133)C (134)B [分析] 程序图的环路数是源代码程度复杂的度量。根据McCabe度量法，环路数 N,e-n+2，这里e表示有向图的边数，n表示结点数。在图9-17中，e,13，n,11，得到N,4。 另外一种方法是计算有向图把平面划分成的区域数，这里有3个闭合区域，外加1个开放区域，共4个区域。所以，程序图的复杂度是4。 路径测试的关键是要找出程序图中所有可能的路径。对这个程序进行路径覆盖测试，可得到4条基本 路径。 (1)A-B-C-H-I-K。 (2)A-B-C-H-J-K。 (3)A-B-C-D-E-F-G-C-H-I-K。 (4)A-B-C-D-E-G-C-H-I-K。 所有基本路径都是从程序起点到终点，并且包含了至少一条独立的边。 (135)下列关于软件需求管理与需求开发的论述，正确的是 (135) 。 A(所谓需求管理是指对需求开发的管理 B(需求管理包括:需求获取、需求分析、需求定义和需求验证 C(需求开发是将用户需求转化为应用系统成果的过程 D(在需求管理中，要求维持对原有需求和所有产品构件需求的双向跟踪 答案 (135)D [分析] 所有与需求直接相关的活动通称为需求工程。需求工程的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求开发的目的是通过调查与分析，获取用户需求并定义产品需求，需求开发的过程有4个;需求获取、需求分析、需求定义和需求验证。需求管理的目的是确保各方对需求的一致理解，管理和控制需求的变更，从需求到最终产品的双向跟踪。 在需求管理中，要收集需求的变更和变更的理由，并且维持对原有需求和产品，以及构件需求的双向跟踪。 (136)为了使构件系统更切合实际、更有效地被复用，构件应当具备 (136) ，以提高其通用性。 A(可继承性 B(可变性 C(可封装性 D(可伸缩性 答案 (136)B [分析] 请参考试题18的分析。 (137)在关于逆向工程(reverse engineering)的描述中，正确的是 (137) 。 A(从已经安装的软件中提取设计规范，用以进行软件开发 B(按照“输出—,处理—,输入”的顺序设计软件 C(用硬件来实现软件的功能 D(根据软件处理的对象来选择开发语言和开发工具 答案 (137)A [分析] 请参考试题42的分析。 (138)COCOMO模型能够依据待开发软件的规模来估计软件开发的工期。若 COCOMO模型公式为: MM=3.0×(KDSI) 其中，KDSI为预计应交付的源程序千行数，MM为开发该软件所需的人月数。设软件开发的生产率为每个人月能编写的最终能交付的源程序千行数 (KDSI/MM)，则根据上述COCOMO模型可以看出，软件开发的生产率随软件开发规模而变化的趋势如图 (138) 所示。 答案 (138)D [分析] 这是一个简单的计算题。根据试题中给出的公式，可以得到: 0.12 KDM/MM,1/(3.0×(KDSI)) 由上述公式可以看出，开发规模(由KDSI反映)越大，软件开发生产率越低。因此，正确答案需要在C和D中选择。显然，上述函数是一个下凸函数，因此，第(23)空的正确答案为D。 说明，如果考生不知道上/下凸函数的定义，则可随机选取几个点，画出上述函数的图形，也可判别。 (139)在选择开发方法时，不适合使用原型法的情况是 (139) 。 A(用户需求模糊不清 B(系统难以确定 C(系统使用范围变化很大 D(用户的数据资源缺乏组织和管理 答案 (139)D [分析] 快速原型法的基本思想是在系统开发的初期，在对用户需求初步调查的基础上，以快速的方法先构造一个可以工作的系统雏形(原型)。将这个原型提供给用户使用，听取他们的意见。然后修正原型，补充新的数据、数据结构和应用模型，形成新的原型。经过几次迭代以后，可以达到用户与开发者之间的完全沟通，消除各种误解，形成明确的系统定义及用户界面要求。至此，或者以最后的原型为基础，修改完善成为实际生产运行的系统;或者舍弃原型重新开发新的系统。 快速原型法的特点如下。 (1)快速原型法最显著的特点是引入了迭代的概念。 (2)快速原型法自始至终强调用户的参与。 (3)快速原型法在用户需求分析、系统功能描述及系统实现方法等方面允许有较大的灵活性。用户需求可以不十分明确，系统功能描述也可以不完整，对于界面的要求也可以逐步完善。 (4)快速原型法可以用来评价几种不同的设计方案。 (5)快速原型法可以用来建立系统的某个部分。 (6)快速原型法不排斥传统生命周期法中采用的大量行之有效的方法和工具，它是与传统方法互为补充的方法。 由于原型法开发需要适当的快速开发工具，需要用户密切配合，所以下列情况不适合使用原型法。 (1)缺乏适用的原型开发工具。 (2)用户不参与、不积极配合开发过程。 (3)用户的数据资源缺乏组织和管理。 (4)用户的软件资源缺乏组织和管理 (140)基线是软件生存期各个开发阶段的工作成果，测试阶段的基线是 (140) 。 A(可提交的软件 B(被测试的程序 C(提交报告 D(测试报告 答案 (140)D [分析] 有关基线的概念，请参考试题24的分析。一般来说，软件开发各阶段的配置基线如下。 (1)计划阶段:开发计划。 (2)需求分析阶段:需求规格说明、用户手册。 (3)设计阶段;设计规格说明。 (4)编码阶段;程序清单。 (5)测试阶段:测试报告。 (141)集成测试有各种方法，以下关于集成测试的描述中，不正确的是 (141) 。 A(增量式集成测试容易定位错误，排除错误 B(非增量式集成测试不能充分利用人力，会拖延工程进度 C(增量式集成测试的强度大，测试更彻底 D(即使各个模块都通过了测试，但系统集成以后仍可能出现错误 答案 (141)B [分析] 集成测试也称组装测试，它是对由各模块组装而成的程序进行测试，主要目标是发现模块间的接口和通信问题。集成测试主要发现设计阶段产生的错误，集成测试计划应该在概要设计阶段制定。集成的方式可分为非增量式和增量式。 非增量式集成测试也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，然后把所有模块组装在一起进行测试，最终得到要求的软件系统。由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。 增量式集成测试又称渐增式集成方式。首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。 (1)自顶向下的增殖方式:将模块按系统程序结构，沿控制层次自顶向下进行集成。由于这种增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序结构中，判断常出现在较高的层次，较早就能遇到。如果主要控制有问题，尽早发现它能够减少以后的返工。 (2)自底向上的增殖方式:从程序结构的最底层模块开始组装和测试。因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块(包括子模块的所有下属模块)已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中，需要从子模块得到的信息可以直接运行子模块得到。 (3)混合增殖式测试:自顶向下增殖的方式和自底向上增殖的方式各有优缺点。自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能将是十分困难的。同时涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现在主要控制方面的问题。自底向上增殖方式的缺点是“程序一直未能做为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。但这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外，自底向上增殖的方式可以实施多个模块的并行测试。 鉴于此，通常是把以上两种方式结合起来进行组装和测试。 (4)衍变的自顶向下的增殖测试:它的基本思想是强化对输入/输出模块和引入新算法模块的测试，并 自底向上组装成为功能相当完整且相对独立的子系统，然后由主模块开始自顶向下进行增殖测试。 (5)自底向上—自顶向下的增殖测试:它首先对含读操作的子系统自底向上直至根结点模块进行组装和测试，然后对含写操作的子系统做自顶向下的组装与测试。 (6)回归测试:这种方式采取自顶向下的方式测试被修改的模块及其子模块，然后将这一部分视为子系统，再自底向上测试，以检查该子系统与其上级模块的接口是否适配。 增量式与非增量式测试的优点和缺点比较如表9-3所示。 表9-3 增量式与非增量式测试的优点和缺点比较 错误定位 容量定位错误，排除故障 不容易定位错误 先加入的模块经过多次测试， 测试强度 测试强度小 测试强度大，测试更彻底 测试的工作量 测试的工作量大 测试的工作量小 对各个模块可以并行测试， 测试的进度 测试的过程长，进度慢 加快测试进度 自顶向下的增量需要编写桩模块; 每个中间模块的测试都需要编 测试辅助程序 自底向下的增量需要编写驱动模块 写驱动模块和桩模块 (142)有两种需求定义的方法——严格定义和原型定义，在关于这两种方法的描述中，不正确的是 (142) 。 A(严格定义方法假定所有的需求都可以预先定义 B(严格定义方法假定软件开发人员与用户之间的沟通存在障碍 C(原型定义方法认为需求分析中不可避免地要出现很多反复 D(原型定义方法强调用户在软件开发过程中的参与和决策 答案 (142)B [分析] 严格定义(预先定义)是目前采用较多的一种需求定义方法。在采用严格定义的传统的结构化开发方法中，各个工作阶段排列成一个理想的线性开发序列，在每一工作阶段中，都用上一阶段所提供的完整、严格的文档作为指导文件，因此它本质上是一种顺序型的开发方法。 在传统的结构化开发中，需求的严格定义建立在以下的基本假设上。 (1)所有需求都能够被预先定义 假设意味着，在没有实际系统运行经验的情况下，全部的系统需求均可通过逻辑推断得到。这对某些规模较小、功能简单的系统是可能的，但对那些功能庞大、复杂且较大的系统显然是困难的。即使事先做了深入细致的调查和分析，当用户见到新系统的实际效果时，也往往会改变原先的看法，会提出修改或更进一步增加系统功能的要求，所以再好的预先定义技术也会经常反复。这是因为人们对新事物的认识与理解将随着直观、实践的过程进一步加深，这是与人类认识世界的客观规律相一致的。所以，能够预先定义出所有需求的假设在许多场合是不能成立的。 (2)开发人员与用户之间能够准确而清晰地交流 假设认为，用户与开发人员之间，虽然每人都有自己的专业、观点、行话，但在系统开发过程中可以使用图形/文档等通信工具进行交流，进行清晰、有效的沟通，这种沟通是必不可少的。可是，在实际开发中，往往对一些共同的约定，每个人可能都会产生自己的理解和解释。即使采用结构化语言、判定树、判定表等工具，仍然存在精确的、技术上的不严密感。这将导致人们有意无意地带有个人的不同理解而各行其事，所以在多学科、多行业人员之间进行有效的通信交流是有一定困难的。 (3)采用图形/文字可以充分体现最终系统 在使用严格定义需求的开发过程中，开发人员与用户之间交流、通信的主要工具是定义报告，包括叙述文字、图形、逻辑规则和数据字典等技术工具。它们都是静止的、被动的，不能实际表演，很难在用户头脑中形成一个具体的形象。因此，要用静止的图形/文字描述来体现一个动态的系统是比较困难的。 除了所论述的情况外，上述基本假设还将导致严格定义的结构化开发方法存在以下缺陷。 首先是文档量大，由于在结构化方法的每个阶段都必须写出规范、严密的各种文档，这些文档虽然有 助于开发人员之间、用户与开发人员间的通信交流，有助于开发过程的规范化，但由于编写文档花费大量人力和时间，导致系统开发周期增大。其次是开发过程可见性差，来自用户的反馈太迟。由于在需求定义、系统设计阶段都不能在用户终端显示新系统的实际效果，一直到系统实现阶段结束，用户才有机会通过对新系统的实际操作和体会来提出他们对新系统的看法和意见，但此时整个开发已近尾声，若想修改前几段的工作或修改需求定义，都将付出较大的代价，有时这种修改甚至会导致整个系统的失败。 综上所述，需求的严格定义的基本假设在许多情况下并不成立，传统的结构化方法面临着一些难以跨越的障碍。为此，需要探求一种变通的方法。 原型方法以一种与严格定义法截然不同的观点看待需求定义问题。原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许用户在开发过程中提出更好的要求，根据用户的要求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式。 采用原型方法时需要注意的几个问题。 (1)并非所有的需求都能在系统开发前被准确地说明。事实上，要想严密、准确地定义任何事情都是有一定难度的，更不用说是定义一个庞大系统的全部需求。用户虽然可以叙述他们所需最终系统的目标及大致功能，但是对某些细节问题却往往不可能十分清楚。一个系统的开发过程，无论对于开发人员还是用户来说，都是一个学习和实践的过程，为了帮助他们在这个过程中提出更完善的需求，最好的方法就是提供现实世界的实例——原型，对原型进行研究、实践，并进行评价。 (2)项目参加者之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。用户和开发人员通过屏幕、键盘进行对话和讨论、交流，从他们自身的理解出发来测试原型，一个具体的原型系统，由于直观性、动态性而使得项目参加者之间的交流上的困难得到较好的克服。 (3)需要实际的、可供用户参与的系统模型。虽然图形和文字描述是一种较好的通信交流工具，但是，其最大缺陷是缺乏直观的、感性的特征，因而不易理解对象的全部含义。交互式的系统原型能够提供生动的规格说明，用户见到的是一个“活”的、实际运行着的系统。实际使用在计算机上运行的系统，显然比理解纸面上的系统要深刻得多。 (4)有合适的系统开发环境。随着计算机硬件，软件技术和软件工具的迅速发展，软件的设计与实现工作越来越方便，对系统进行局部性修改甚至重新开发的代价大大降低。所以，对大系统的原型化已经成为可能。 (5)反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。对系统改进的建议来自经验的发展，应该鼓励用户改进他们的系统，只有做必要的改变后，才能使用户和系统间获得更加良好的匹配，所以，从某种意义上说，严格定义需求的方法实际上抑制了用户在需求定义以后再改进的要求，这对提高最终系统的质量是有害的。另一方面，原型方法的使用并不排除严格定义方法的运用，当通过原型并在演示中得到明确的需求定义后，应采用行之有效的结构化方法来完成最终系统的开发。 (143)软件的分层式体系结构把软件系统划分为4层，这4层结构自顶向下分别是 (143) 。 A(应用软件 业务构件 中间件 系统软件 B(业务构件 应用软件 中间件 系统软件 C(应用软件 中间件 系统软件 业务构件 D(业务构件 中间件 应用软件 系统软件 答案 (143)A [分析] 软件的分层式体系结构把软件系统划分为4层，这4层结构自顶向下分别是应用软件、业务构件、中间件和系统软件。 (144)基于构件的开发(CBD)模型，融合了 (144) 模型的许多特征。该模型本质是演化的，采用迭代方法开发软件。 A(瀑布 B(快速应用开发(RAD) C(螺旋 D(形式化方法 答案 (144)C [分析] 基于构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。 基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。基于构件的开发模型由软件的需求分析和定义、架构设计、构件库建立、应用软件构建，以及测试和发布5个阶段组成。 (145)风险的成本估算完成后，可以针对风险表中的每个风险计算其风险曝光度。某软件小组计划项日中采用50个可复用的构件，每个构件平均是100LOC，本地每个LOC的成本是13元人民币。下面是该小组定义的一个项目风险: 1(风险识别:预定要复用的软件构件中只有50%将被集成到应用中，剩余功能必须定制开发; 2(风险概率:60%; 3(该项目风险的风险曝光度是 (145) 。 A(32500 B(65000 C(1500 D(19500 答案 (145)D [分析] 风险曝光度(riskexposure)的计算公式如下。 风险曝光度;错误出现率(风险出现率)×错误造成损失(风险损失) 在本题中，风险概率为60%，风险损失为所有构件价格的50%，因此，其风险曝光度为: 50×100×13×50%×60%,19500 (146)结构模板能够帮助分析员建立一个逐层细化的层次结构。结构环境图 (Architecture Context Diagram，ACD)则位于层次结构的顶层。在从ACD导出的 (146) 中给出了各个专门子系统和重要(数据与控制)信息流。 A(系统语境图(SCD) B(结构互连图(AID) C(结构流程图(AFD) D(结构图的规格说明(ADS) 答案 (146)C [分析] 结构模板能帮助系统分析员建立一个细节的层次结构。结构环境图ACD则位于层次结构的顶层，建立了待实现系统与系统运行环境之间的信息边界。 ACD定义了: (1)系统使用的所有信息的外部产生者: (2)由系统建立的所有信息的外部使用者: (3)通过接口进行通信或实施维护与自测试的所有实体。 专门子系统定义在从ACD导出的结构流程图AFD(Architecture Flow Diagram)中。信息流穿越ACD的各个区域，可用于引导系统工程师开发AFD。 AFD给出了各个专门子系统和重要的(数据与控制)信息流。 结构模板把子系统处理划分成5个处理区域。每个子系统可以包含一个或多个系统元素(如硬件、软件、人)，它们是系统工程师分配给子系统的。 (147)需求分析的任务是借助于当前系统的物理模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题。 (147) 并不是需求分析的实现步骤之一。 A(获得当前系统的物理模型 B(抽象出当前系统的逻辑模型 C(建立目标系统的逻辑模型 D(确定目标实现的具体技术路线 答案 (147)D [分析] 通常，软件开发项目是要实现目标系统的物理模型，即确定待开发软件系统的系统元素，并将功能和数据结构分配到这些系统元素中，它是软件实现的基础。但是，目标系统的具体物理模型是由它的逻辑模型经实例化(即具体到某个业务领域)得到的。与物理模型不同，逻辑模型忽视实现机制与细节，只描述系统要完成的功能和要处理的数据。作为目标系统的参考，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题。 结合现有系统(当前)分析，进行新系统设计的过程如图9-18所示。 (1)获得当前系统的物理模型。当前系统可能是需要改进的某个已在计算机运行的数据处理系统，也可能是一个人工的数据处理过程。在这一步首先分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，并用一个具体模型来反映自己对当前系统的理解。这一模型应客观地反映现实世界的实际情况。 (2)抽象出当前系统的逻辑模型。在理解当前系统“怎样做”的基础上，抽取其“做什么”的本质，从而从当前系统的物理模型抽象出当前系统的逻辑模型。 在物理模型中有许多物理因素，随着分析工作的深入，有些非本质的物理因素就成为不必要的负担，因而需要对物理模型进行分析，区分出本质的和非本质的因素，去掉那些非本质的因素即可获得反映系统本质的逻辑模型。 (3)建立目标系统的逻辑模型。分析目标系统与当前系统逻辑上的差别，明确目标系统到底要“做什么”，从当前系统的逻辑模型导出目标系统的逻辑模型。 (4)建立目标系统的物理模型。根据新系统的逻辑模型构建出相应的物理模型。 值得注意的是，原有系统可以是一个正在运行的软件系统，也可以是一个纯手工运作的流程。 为了直观地分析系统的动作，从特定的视点出发推述系统的行为，需要采用动态分析的方法。其中 (148) 本来是表达异步系统的控制规则的图形表示方法，现在已经广泛地应用于硬件与软件系统的开发中，它适用于描述与分析相互独立、协同操作的处理系统，也就是并发执行的处理系统。 (149) 是描述系统的状态如何响应外部的信号进行推移的一种图形表示。 (148)A(状态迁移图 B(时序图 C(Petri网 D(数据流图 (149)A(状态迁移图 B(时序图 C(Petri网 D(数据流图 答案 (148)C (149)A [分析] 常用的动态需求分析方法有状态迁移图、时序图和Petri网等。 Petri网是一种使用图形方式对系统进行需求规格说明的技术，用来定义多进程、多任务系统的数学模型，易于描述系统的并发、竞争、同步等特征，并可用于评价和改进系统。如今，Petri网已经大量应用于各种系统的模型化，Petri网不仅能描述同步模型，更适合于相互独立、协同操作的并行处理系统。 Petri网的组成成分包括: (1)一个有限的库所(place)集合，表示系统的状态。 (2)一个有限的变迁(transition)集合，表示系统中的事件。 (3)一个有限的连接库所到变迁或者反向的有向箭头的集合，又分输入和输出。 状态迁移图是描述系统的状态如何响应外部的信号进行推移的一种图形表示。在状态迁移图中，用圆圈表示可得到的系统状态，用箭头表示从一种状态向另一种状态的迁移。在箭头上要写上导致迁移的信号或事件的名字。 状态迁移图表示的关系还可用表格的形式表达，这样的表格成为状态迁移表。如果系统复杂，可以把系统状态迁移图分层表示，这种分层的状态迁移图不仅对系统的状态及其状态之间的转变进行清晰的描述，还可对某些状态进行进一步的细化。 状态迁移图的优点是状态之间的关系能够直观地捕捉到，由于状态迁移图的单纯性，很容易建立相应的分析工具。 在系统分析中，用时序图来对比在系统中处理事件的时序和相应的处理时间，采用扩充时序图可表示进程间的通信流，用于分析几个事件的交错现象。 (150)黑盒测试法是根据软件产品的功能设计规格说明书，通过运行程序进行测试，证实每个已经实现的功能是否符合设计要求。如果某产品的文本编辑框允许输入1,255个字符，采用 (150) 测试方法，其测试数据为:0个字符、1个字符、255个字符和256个字符。 A(等价类划分 B(边界值分析 C(比较测试 D(正交数组测试 答案 (150)B [分析] 请参考试题38的分析。