系统分析师考试历年试题分析与解答案例分析与论文篇.docx
《系统分析师考试历年试题分析与解答案例分析与论文篇.docx》由会员分享，可在线阅读，更多相关《系统分析师考试历年试题分析与解答案例分析与论文篇.docx（29页珍藏版）》请在冰豆网上搜索。
系统分析师考试历年试题分析与解答案例分析与论文篇
系统分析师考试历年试题分析与解答（案例分析与论文篇）
第 1 章 软件开发方法
案例分析试题
软件开发方法是指软件开发过程所遵循的办法和步骤，系统分析师考试大纲规定，考生要“熟练掌握信息系统开发过程和方法”。
也就是说，系统分析师要能够根据项目的实际情况，选择恰当的软件开发方法。
1.1 案例分析试题
在2004年至2013年的考试试题中，共有6道试题和软件开发方法有关，本节主要分析这6道试题。
在本节的试题中，其考查范围如表1-1所示。
表1-1 软件开发方法试题分布表
1.1.12004年上半年试题5
2004年上半年试题5
某公司要在现场开发一个网站应用系统，该系统的特点是：
规模不大；工期短；用户需求不明确；没有大的技术风险；系统中的一些模块可以外包给其他的公司开发。
在选择开发过程时，项目组内产生了分歧。
王工提出采用XP（eXtremeProgramming，极限编程），理由是XP方法简洁，能减轻开发人员的负担、快速适应市场、缩短投资回收期。
李工认为采用XP在项目开发中存在一些问题，建议考虑原型开发方法。
双方就上述的问题展开了激烈的争论。
项目组最后决定采用XP，但同时针对李工提出的XP中存在的问题采取了相应的措施。
【问题1】
小规模发布（smallrelease）是XP的基本元素之一。
请用200字以内文字分别阐明：
（1）原型系统和XP小规模发布的系统的主要差别？
（2）为什么该项目组没有采用原型开发方法？
【问题2】
请用200字以内文字，简要说明采用XP方法可能会存在哪些问题。
【问题3】
在项目组的后续讨论中，李工提出，如果项目规模扩大，XP将不再适用。
王工对此表示赞同，但同时提出可以将XP方法和传统软件开发过程相结合。
请用200字以内的文字简要地说明如何将XP方法和传统软件开发过程相结合。
一、试题分析
在我们面临“软件危机”所带来的挑战之时，曾经通过采用严格的规范、详尽的文档来约束开发过程，以保证开发的质量与效果，获得了突出的成就。
但是随着时代的进一步发展，业务周期越来越短、变化越来越快，甚至在软件开发的过程中，业务逻辑和需求已经悄然变化，这给本来还不成熟的软件产业带来了新的挑战。
正在这种情况下，敏捷方法论应运而生。
2001年这些方法论的创始人走到一起，成立了敏捷联盟，发表了颇具影响力的敏捷宣言：
个体和交互胜过过程和工具、可工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。
比较有影响力的敏捷方法论包括XP（极限编程）、FDD（特征驱动开发）、CrystalMethod（水晶方法）、DSDM（动态系统开发方法）、ASD（自适应开发）、Scrum等。
本题主要考查考生对软件开发过程的掌握情况，要求能够了解各种不同的过程方法论，跟踪其发展的趋势，并且根据实际的情况和需求来正确地选择合适的过程方法论。
近几年来，由于以XP为代表的敏捷方法论的讨论、实践越来越多，也取得了较好的成效，因此对于从事软件工程管理方面的考生来说，也成为一个重要的知识内容。
【问题1】
当客户有一个合理的要求，但对细节则没有任何线索时，原型法开发是一个十分常用的方法。
由于本题中所涉及的项目就是属于需求不明确的，因此能够有效利用原型法进行解决。
原型法开发将从需求收集开始，开发者和客户在一起定义软件的总体目标，标识出已知的需求，并规划出需要进一步定义的区域。
然后就是“快速设计”，快速设计集中于软件中那些对用户/客户可见的部分的表示（如输入方式和输出格式）。
可通过快速设计来创建原型。
原型由用户/客户评估并进一步精化待开发软件的需求。
逐步调整原型使其满足客户的要求，而同时也使开发者对将要做的事情有较好的理解，这个过程是迭代的。
理想情况下，原型可以作为标识软件需求的一种机制。
如果建立了可运行原型，开发者就可以在其基础上试图利用已有的程序片断或使用工具（如报表生成器、窗口管理器）来尽快生成可运行的程序。
原型开发方法在实施时，存在的问题主要包括以下两个方面：
（1）客户似乎已经看到了软件的工作版本，却无法理解，原因在于为了使原型能够很快使用，开发者没有考虑软件的总体质量和长期的可维护性。
（2）开发者常常需要实施上的折中使原型能够尽快工作。
因此，通常采用原型法都会在客户和开发者之间达成协议：
构建原型仅是为了定义需求，之后就被抛弃了（至少是部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。
这种原型开发方法也称为“抛弃型原型开发”。
当然，也可以采用逐渐演进的方式进行原型开发，即以逐步增加功能的方式进行开发，以便于随时根据客户或最终用户的反馈来修正系统。
大多数渐进原型都是从一个用户界面原型开始逐步演化出整个系统的。
不过采用原型开发可能出现的风险是：
不切实际的进度和预算、项目可控性降低、缺乏最终用户或客户的反馈（这是因为，容易让客户的目标陷入界面，而忽略本质，反而造成问题）、产品性能不佳、不切实际的性能期望、设计不佳、可维护性差、目标偏移，而且还有一个最重要的就是原型开发阶段效率一般都较低。
由于XP认为“客户确切地知道需求，而且当你实现其需求后，他仍然认同”这种现象几乎不存在。
因此，在XP方法论中最重要的一件事情就是尽早、尽量频繁地发布。
如果可能，第一次发布时间不应超过两个月，此后每两个月发布一次。
要注意的是，XP中每次发布的内容不是演示版，而是实用版。
也就是说，并不是仅仅将其演示给客户看，让其评论，最后放到一边，继续等待最后的开发结果，而是交付使用的子集，让客户每一天都在使用。
另外，为了保证开发出来的结果与客户的预想接近，XP方法论认为最重要的是需要将客户请到开发现场。
在项目中有客户在现场明确用户需求，并做出相应的业务决策对于XP项目而言有着十分重要的意义。
这时因为，仅靠简单的用户需求描述是不充分的，还需要大量地与客户沟通。
在本题中所列举的项目是在现场开发，因此现场客户是有保证的。
【问题2】
XP的核心是其总结的沟通、简单、反馈、勇气四大价值观。
它包括12种最佳实践：
计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户，以及编码标准。
从XP方法论本身来说，首先第一类潜在问题是精神和观念上的，即是否能够得到开发人员、管理者，以及客户三方面的支持与理解。
简单设计、测试先行、重构、集体代码所有制、编码标准、持续集成都从某种意义上违背了程序员的传统习惯；而小型发布、结对编程、每周工作40小时，经常会让管理者不可理解，以致认为XP是黑客文化，是为开发人员谋福利而来的；而现场客户实践则经常无法得到客户的理解和满足，另外许多客户在接受每一次小规模发布时，也会提出异议。
另外，由于XP方法论属于轻量级，也就是文档量少，遵从“代码就是文档”的思想。
因此虽然XP方法论中是有“当非要文档时才编写”的说法，但却容易使团队忽视文档，从而降低系统的可维护性、易用性，以及其他的一些问题。
除了培训教育之外，通常还可以采用的解决方案是利用诸如“敏捷建模”策略，在两个极端中间取一个合理的阈值。
结合本题，还有一个十分重要的信息，那就是该项目将部分外包。
由于XP方法论强调人的作用，团队之间通过集体代码制、结对编程等方式来提升交流与合作，从而提升生产率的。
但是如果项目有部分外包的话，将会破坏这种结构，甚至可能影响到发布计划。
【问题3】
XP方法论的创始人KentBeck在其《拥抱变化：
解析极限编程》一书中明确指出了：
“XP是适合于中小型团队在需求不明确或者迅速变化的情况下进行软件开发的轻量级方法学”。
它与传统的方法论最大的不同在于：
拥有短周期内的早期、具体和持续的反馈。
它递增地进行计划编制，也就是在项目的一开始迅速提供一个总体计划，然后在项目的整个生命周期内不断地发展它。
它针对不断变化的业务需求灵活地对功能的实现进行计划的能力。
它依赖于由程序员或客户编写的自动测试来监控开发进度。
它依赖于口头交流、测试和源代码来沟通系统的结构和意图。
它依赖于整个系统存在期间一直持续的进化式设计过程。
它依赖于技术水平一般的程序员之间的紧密协作。
它依赖于能够同时满足程序员的短期本能和项目的长期利益的实践。
因此，我们可以发现它并不是与传统的方法论有着“不共戴天”的变化，是存在很多的结合点，能够有效地在传统方法论中结合XP开发方法的。
集中式方法是传统的软件工程方法的共同特点，它的优点在于：
具有共同的、清晰确定的目标，而且是一个结构化的过程，领导团队贯穿各个软件开发阶段。
而它们最大的缺点是：
缺乏负责员工的参与，而且客户的反馈也很少，导致解决方案的接纳度降低。
XP方法与员工/客户联系十分紧密，可以保证较高的解决方案接纳度。
不过把其运用到几个局部问题上往往不能产生与多个团队一起共享的改进，加上XP方法无结构，因此一个必须包含几个人的复杂问题不能用它来产生一个全面的概念。
（1）层次化结合。
基于上述想法，可以提出层次化的管理，具体地说就是：
在上层，建立一种面向目标的项目管理，它通过产生一个大致概念来把问题组织成一种高级结构。
将目前有局部化问题的每个部分都通过定义一个自身的XP团队来用一种极限编程的方法予以解决。
XP团队主要在独立的基础上发挥功能。
同时，他们通过跟踪全局目标和衡量局部改进的顶层管理团队以一种松散的方式被联系起来。
（2）实践引入式结合。
另外一种结合的方式是仍然按照传统过程方法论进行过程的管理，引入XP的实践，实现优势互补。
其中比较典型的包括如下几点。
现场客户：
这个实践是对传统过程方法论缺乏客户参与的最好补充。
简单设计：
“只为今天设计，不过多地考虑明天的需要，因为现在的假设可以是错误的，也许明天还有更好的实现方式”，这是XP所提倡的简单原则，它也可以无缝地借用到用传统过程方法论进行管理的项目中。
小型发布：
每次迭代都实现一次小型的发布，提交一个能够让用户开始投入使用的小型版本，可以有效地加强反馈，缩短开发进程，提高软件质量。
其中还可结合每日构建进行持续集成，予以保障与支持。
测试先行、重构：
这是保持“小步快走”的关键实践，对于软件质量的提高有很大的帮助。
除此之外，XP方法论中的其他实践也能够有效地在传统的开发过程中发挥作用。
二、参考答案
【问题1】
（1）原型系统和XP小型发布的系统的主要差别是功能。
采用原型系统主要是让用户确认需求，或者用来测试关键的技术，但是它展示的功能并不是实际系统的功能，不能用来评价实际的系统；XP小型发布的系统考试时不包括足够的功能，但是每个功能和可发布的产品的定义是一样的。
在完整性上，它配备了一系列实用的功能集；在质量上，它可以健壮地运行。
（2）在该项目中，不需要开发原型系统。
由于项目没有大的技术风险，所以不需要用原型系统来测试关键技术。
网站系统的开发和原型系统的开发在工作量上是相当的，在时间要求短的情况下，直接开发系统可以节省时间。
对于用户需求经常发生变化的情况，可以采用XP开发方法的代码重构、持续集成和小型发布等技术。
【问题2】
（1）开发团队、管理层，以及客户的不理解，阻碍XP方法论实施。
（2）导致开发团队忽视文档，以XP为借口拒绝编写甚至是必须的文档。
（3）XP是针对单一团队设计的，外包方的参与将会为有效的组织带来很大的困难。
（4）缺乏客户的参与，导致用户故事编写、优先级确认等工作遇到困难。
（5）项目规模扩大后，XP方法论将不适应。
（6）对客户、开发人员和管理者的素质要求较高。
【问题3】
（1）可以将XP和传统软件开发过程中的增量式开发过程相结合。
（2）将大规模项目划分为若干个具有共同目标的小规模项目，用XP方法论组织小项目开发，用传统软件过程方法论监控全局。
（3）在此基础上，建立面向目标的项目管理。
1.1.22004年下半年试题5
2004年下半年试题5
希赛公司是一家中等规模的计算机企业，专业从事网络安全防护软件系统的开发。
从最初仅开发基于Windows的个人防火墙产品开始，现在，已经延伸到基于Linux、Windows系列、MAC操作系统的个人防火墙、企业防火墙、入侵检测系统、病毒扫描系统、安全扫描系统等多种产品。
公司原来的产品都是一个一个地开发，为每个软件对应地组织一个项目组。
为了适应快速变化的市场，降低开发成本，公司想引入产品线方法。
然而，由于软件产品线方法涉及了一个软件开发企业的多个产品，所以，公司的王总决定在弄清楚以下三个问题之后再做决定：
首先就是本公司的业务范围是否适合使用产品线方法，其次是如何在原有产品的基础上建立产品线，最后是成功实施产品线的主要因素是什么？
【问题1】
请用100字以内文字，说明希赛公司是否适合采用产品线方法，并说明理由。
【问题2】
请用400字以内文字，说明在原有产品的基础上建立软件产品线的方式，并作简要评价。
【问题3】
请用150字以内文字，说明成功实施产品线的主要因素。
一、试题分析
软件产品线（softwareproductline）是一个十分适合专业的软件开发组织的软件开发方法，能有效地提高软件生产率和质量、缩短开发时间、降低总开发成本；它也是一个新兴的、多学科交叉的研究领域，研究内容和范围都相当广泛。
卡耐基•梅隆大学软件工程研究所（CMU/SEI）对产品线和软件产品线的定义，比较能够体现软件产品线的特征：
“产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足选定的市场或任务领域的特定需求。
这些系统是遵循一个预描述的方式，在公共的核心资源（coreassets）基础上开发的。
”
软件产品线开发有四个基本技术特点：
过程驱动、特定领域、技术支持和架构为中心。
与其他软件开发方法相比，软件开发组织选择软件产品线的宏观上的原因有：
对产品线及其实现所需的专家知识领域的清楚界定，对产品线的长期远景进行了策略性规划。
【问题1】
产品线的起源可以追溯到1976年Parnas对程序族的研究。
软件产品线的实践早在20世纪80年代中期就出现了。
最著名的例子是瑞士CelsiusTech公司的舰艇防御系统的开发，该公司从1986年开始使用软件产品线开发方法，使得整个系统中软件和硬件在总成本中所占比例从使用软件产品线方法之前的65:
35下降到使用后的20:
80，系统开发时间从约需要9年下降到不到3年。
据HP公司1996年对HP、IBM、NEC、AT＆T等几个大型公司分析研究，他们在采用了软件产品线开发方法后，使产品的开发时间减少1.5~2倍，维护成本降低2~5倍，软件质量提升5~10倍，软件重用达50%~80%，开发成本降低12%~15%。
虽然软件工业界已经在大量使用软件产品线开发方法，但是正式的对软件产品线的理论研究到20世纪90年代中期才出现，并且早期的研究主要以实例分析为主。
到了20世纪90年代后期，软件产品线的研究已经成为软件工程领域最热门的研究领域。
得益于丰富的实践和软件工程、软件架构、软件重用技术等坚实的理论基础，软件产品线的研究发展十分迅速，目前软件产品线的发展已经趋向成熟。
很多大学已经锁定软件产品线，将其作为一个研究领域，并有大学已经开设软件产品线相关的课程。
一些的国际著名学术会议也设立了相应的产品线专题学术讨论会，第一次国际产品线会议于2000年8月在美国Denver召开等。
与软件架构的发展类似，软件产品线的发展也很大地得益于军方的支持。
如美国国防部支持的两个典型项目：
关于基于特定领域软件架构的软件开发方法的研究项目（DSSA），关于过程驱动、特定领域和基于重用的软件开发方法的研究项目（STARS）。
这两个项目在软件架构和软件重用两个方面极大地推动了软件产品线的研究和发展。
可以说软件产品线方法是软件工程领域中软件架构和软件重用技术发展的结果。
与软件架构一样，目前，软件产品线没有一个统一的定义，常见的定义有：
（1）将利用了产品间公共方面、预期考虑了可变性等设计的产品族称为产品线。
（2）产品线就是由在系统的组成元素和功能方面具有共性（commonality）和个性（variability）的相似的多个系统组成的一个系统族。
（3）软件产品线就是在一个公共的软件资源集合基础上建立起来的，共享同一个特性集合的系统集合。
（4）一个软件产品线由一个产品线架构、一个可重用构件集合和一个源自共享资源的产品集合组成，是组织一组相关软件产品开发的方式。
（5）产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足选定的市场或任务领域的特定需求。
这些系统遵循一个预描述的方式，是在公共的核心资源（coreassets）基础上开发的。
根据CMU/SEI的定义，软件产品线主要由两部分组成：
核心资源和产品集合。
核心资源是领域工程的所有结果的集合，是产品线中产品构造的基础。
也有组织将核心资源库称为“平台（Platform）”。
核心资源必定包含产品线中所有产品共享的产品线架构，新设计开发的或者通过对现有系统的再工程得到的、需要在整个产品线中系统化重用的软件构件。
与软件构件相关的测试计划、测试实例，以及所有设计文档，需求说明书和领域模型还有领域范围的定义也是核心资源，采用COTS的构件也属于核心资源。
产品线架构和构件是软件产品线中的核心资源中最重要的部分。
从上述的描述中，我们可以发现公司是否适于使用软件产品线开发方法，最主要的判断点在于是否能够抽取可以在所有产品集合中可系统化重用的软件构件，即核心资源。
而在本题中，由于希赛公司是专业从事网络安全防护软件系统的开发，其个人防火墙、企业防火墙、入侵检测系统、病毒扫描系统、安全扫描系统等产品都是属于同一个领域，具有很多共性的地方，因此可以通过领域模型来确定领域/产品线的共性和可变性，为产品线设计架构。
另外，由于对于各种系统而言，都需要处理不同操作系统平台，但实现的还是同一个领域概念。
因此该企业的情况是适合采用产品线开发方法的。
【问题2】
软件产品线的建立需要希望使用软件产品线方法的软件组织有意识地、明显地努力才有可能成功。
软件产品线的建立通常有四种方式。
引入产品线开发过程采用的方式基于两种考虑：
演化方式（evolutionary）、革命方式（revolutionary），是基于现有产品还是开发全新的产品线。
这四种方式基本特征如表1-2所示。
下面对这几种方式进行简要分析。
表1-2 建立软件产品线的几种方式
（1）将现有产品演化为产品线。
在基于现有产品架构设计的产品线架构的基础上，将特定产品的构件逐步地、越来越多地转化为产品线的共用构件，从基于产品的方法“慢慢地”转化为基于产品线的软件开发。
主要优点是通过对投资回报周期的分解、对现有系统演化的维持使产品线方法的实施风险降到最小，但完成产品线核心资源的总周期和总投资都比使用革命方式要大。
（2）用软件产品线替代现有产品集。
基本停止现有产品的开发，所有努力直接针对软件产品线的核心资源开发。
遗留系统只有在符合架构和构件需求的情况下，才可以和新的构件协作。
这种方法的目标是开发一个不受现有产品集存在问题限制的、全新的平台，总周期和总投资较演化方法要少，但因重要需求的变化导致的初始投资报废的风险加大。
另外，基于核心资源的第一个产品面世的时间将会推后。
现有产品集中软硬件结合的紧密程度，以及不同产品在硬件方面的需求的差异，也是产品线开发选择采用演化还是革命方式的决策依据。
对于软硬件结合密切且硬件需求差异大的现有产品集因无法满足产品线方法对软硬件同步的需求，只能采用革命方式替代现有产品集。
（3）全新软件产品线的演化。
当一个软件组织进入一个全新的领域要开发该领域的一系列产品时，同样也有演化和革命两种方式。
演化方式将每一个新产品的需求与产品线核心资源进行协调。
好处是先期投资少，风险较小，第一个产品面世时间早。
另外，因为是进入一个全新的领域，演化方法可以减少和简化因经验不足造成的初始阶段错误的修正代价。
缺点是已有的产品线核心资源会影响新产品的需求协调，使成本加大。
（4）全新软件产品线的开发。
架构设计师和工程师首先要得到产品线所有可能的需求，基于这个需求集来设计和开发产品线核心资源。
第一个产品将在产品线核心资源全部完成之后才开始构造。
优点是一旦产品线核心资源完成后，新产品的开发速度将非常快，总成本也将减少。
缺点是对新领域的需求很难做到全面和正确，使得核心资源不能像预期的那样支持新产品的开发。
【问题3】
从本质上看，产品线开发包括核心资源库的开发和使用核心资源的产品开发，这两者都需要技术和组织的管理。
核心资源的开发和产品开发可同时进行，也可交叉进行，例如，新产品的构建以核心资源库为基础，或者核心资源库可从已存在的系统中抽取。
有时，我们把核心资源库的开发也称为领域工程，把产品开发称为应用工程。
图1-1说明了产品线各基本活动之间的关系。
每个旋转环代表一个基本活动，三个环连接在一起，不停地运动着。
三个基本活动交错连接，可以以任何次序发生，且高度重叠。
旋转的箭头表示不但核心资源库被用来开发产品，而且已存在的核心资源的修订甚至新的核心资源常常可以来自产品开发的过程。
在核心资源和产品开发之间有一个强的反馈环，当新产品开发时，核心资源库就得到刷新。
对核心资源的使用反过来又会促进核心资源的开发活动。
另外，核心资源的价值通过使用它们的产品开发来得到体现。
产品线的开发包括资源开发、产品计划和产品开发几个步骤，正如图1-2所示，产品线分析是资源开发的一部分。
图1-1 产品线基本活动示意图
图1-2 产品线分析
产品线分析是把对业务机遇的初步确认细化为需求模型，对正在开发的产品线，捕获组织的业务目标和约束、包含在产品线中的产品、最终用户和其他项目干系人的需求、大粒度重用的机会。
分析能否为并行开发提供机会，对产品线开发来说是至关重要的。
资源开发需要固定投资，特别是及时的投资，但产品线的成功却往往取决于组织快速进入市场的能力。
减少产品线进入市场时间的唯一途径就是使资源开发并行进行。
对产品线分析而言，这意味着要尽可能快地发现重大设计信息。
因此，是否进行了充分的产品线分析，对于软件产品线的成功实施起着十分重要的作用。
另外，要想有效地发挥软件产品线的作用，还必须根据特定的情况选择合适的过程模型（诸如双生命周期模型、SEI模型、三生命周期模型），并根据其特点设立不同的部分和组织结构来分别负责领域工程和应用工程部分。
二、参考答案
【问题1】
是否适合采用产品线开发方法关键在于企业是否存在拥有共性领域模型的产品集合。
因为希赛公司的业务是在多平台下开发一系列相关网络安全防护软件，因此适合采用产品线方法。
【问题2】
在原有的产品的基础上建立软件产品线主要有两种方式。
（1）演化方式：
即将现有产品演化为产品线，也就是将特定产品的构件逐渐转化到产品线的共用构件。
该方式分解了投资回报周期，最大程度地减少了实施产品线方法的风险，但完成软件产品线核心资源的总周期和总投资都较大。
（2）革命方式：
即用软件产品线替代现有产品集。
这种方法将基本停止现有产品的开发，直接针对软件产品线的核心资源开发。
虽然该方法完成软件产品线核心资源的总周期和总投资都会减少，但风险大大加大了。
【问题3】
（1）对该领域具备长期和深厚的经验。
（2）一个用于构建产品的好的核心资源库。
（3）好的产品线体系结构。
（4）好的管理（软件资源、人员组织、过程）支持。
1.1.32005年上半年试题4
2005年上半年试题4
某软件公司多年来开发的项目大都采用结构化方法。
但系统开发的实践表明，尽管在许多情况下使用了严格定义或预先说明的方法，但当系统建成以后，用户仍然觉得建立的系统是不完全正确或不完备的，因此需要进行反复地修补。
针对上述情况，公司的李总工程师提出，应该引入原型法，以快速地确定用户需求，提高开发过程中的生产率和最终系统的质量。
【
升级会员 