系统分析师考试历年试题分析与解答(案例分析与论文篇)

系统分析师系统分析师考试历年试题分析与解答（案例分析与论文篇）第1章软件开发方法案例分析试题软件开发方法是指软件开发过程所遵循的办法和步骤，系统分析师考试大纲规定，考生要“熟练掌握信息系统开发过程和方法”。也就是说，系统分析师要能够根据项目的实际情况，选择恰当的软件开发方法。1.1案例分析试题在2004年至2013年的考试试题中，共有6道试题和软件开发方法有关，本节主要分析这6道试题。在本节的试题中，其考查范围如表1-1所示。表1-1软件开发方法试题分布表1.1.12004年上半年试题52004年上半年试题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）对客户、开发人员