下载掌阅APP，畅读海量书库
立即打开
在2004年至2013年的考试试题中，共有6道试题和软件开发方法有关，本节主要分析这6道试题。在本节的试题中，其考查范围如表1-1所示。
表1-1软件开发方法试题分布表
某公司要在现场开发一个网站应用系统，该系统的特点是：规模不大；工期短；用户需求不明确；没有大的技术风险；系统中的一些模块可以外包给其他的公司开发。在选择开发过程时，项目组内产生了分歧。
王工提出采用XP（eXtreme Programming，极限编程），理由是XP方法简洁，能减轻开发人员的负担、快速适应市场、缩短投资回收期。
李工认为采用XP在项目开发中存在一些问题，建议考虑原型开发方法。
双方就上述的问题展开了激烈的争论。项目组最后决定采用XP，但同时针对李工提出的XP中存在的问题采取了相应的措施。
【问题1】
小规模发布（small release）是XP的基本元素之一。请用200字以内文字分别阐明：
（1）原型系统和XP小规模发布的系统的主要差别？
（2）为什么该项目组没有采用原型开发方法？
【问题2】
请用200字以内文字，简要说明采用XP方法可能会存在哪些问题。
【问题3】
在项目组的后续讨论中，李工提出，如果项目规模扩大，XP将不再适用。王工对此表示赞同，但同时提出可以将XP方法和传统软件开发过程相结合。请用200字以内的文字简要地说明如何将XP方法和传统软件开发过程相结合。
在我们面临“软件危机”所带来的挑战之时，曾经通过采用严格的规范、详尽的文档来约束开发过程，以保证开发的质量与效果，获得了突出的成就。但是随着时代的进一步发展，业务周期越来越短、变化越来越快，甚至在软件开发的过程中，业务逻辑和需求已经悄然变化，这给本来还不成熟的软件产业带来了新的挑战。正在这种情况下，敏捷方法论应运而生。
2001年这些方法论的创始人走到一起，成立了敏捷联盟，发表了颇具影响力的敏捷宣言：个体和交互胜过过程和工具、可工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。比较有影响力的敏捷方法论包括XP（极限编程）、FDD（特征驱动开发）、Crystal Method（水晶方法）、DSDM（动态系统开发方法）、ASD（自适应开发）、Scrum等。
本题主要考查考生对软件开发过程的掌握情况，要求能够了解各种不同的过程方法论，跟踪其发展的趋势，并且根据实际的情况和需求来正确地选择合适的过程方法论。近几年来，由于以XP为代表的敏捷方法论的讨论、实践越来越多，也取得了较好的成效，因此对于从事软件工程管理方面的考生来说，也成为一个重要的知识内容。
【问题1】
当客户有一个合理的要求，但对细节则没有任何线索时，原型法开发是一个十分常用的方法。由于本题中所涉及的项目就是属于需求不明确的，因此能够有效利用原型法进行解决。
原型法开发将从需求收集开始，开发者和客户在一起定义软件的总体目标，标识出已知的需求，并规划出需要进一步定义的区域。然后就是“快速设计”，快速设计集中于软件中那些对用户/客户可见的部分的表示（如输入方式和输出格式）。可通过快速设计来创建原型。原型由用户/客户评估并进一步精化待开发软件的需求。逐步调整原型使其满足客户的要求，而同时也使开发者对将要做的事情有较好的理解，这个过程是迭代的。
理想情况下，原型可以作为标识软件需求的一种机制。如果建立了可运行原型，开发者就可以在其基础上试图利用已有的程序片断或使用工具（如报表生成器、窗口管理器）来尽快生成可运行的程序。
原型开发方法在实施时，存在的问题主要包括以下两个方面：
（1）客户似乎已经看到了软件的工作版本，却无法理解，原因在于为了使原型能够很快使用，开发者没有考虑软件的总体质量和长期的可维护性。
（2）开发者常常需要实施上的折中使原型能够尽快工作。
因此，通常采用原型法都会在客户和开发者之间达成协议：构建原型仅是为了定义需求，之后就被抛弃了（至少是部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。这种原型开发方法也称为“抛弃型原型开发”。当然，也可以采用逐渐演进的方式进行原型开发，即以逐步增加功能的方式进行开发，以便于随时根据客户或最终用户的反馈来修正系统。大多数渐进原型都是从一个用户界面原型开始逐步演化出整个系统的。不过采用原型开发可能出现的风险是：不切实际的进度和预算、项目可控性降低、缺乏最终用户或客户的反馈（这是因为，容易让客户的目标陷入界面，而忽略本质，反而造成问题）、产品性能不佳、不切实际的性能期望、设计不佳、可维护性差、目标偏移，而且还有一个最重要的就是原型开发阶段效率一般都较低。
由于XP认为“客户确切地知道需求，而且当你实现其需求后，他仍然认同”这种现象几乎不存在。因此，在XP方法论中最重要的一件事情就是尽早、尽量频繁地发布。如果可能，第一次发布时间不应超过两个月，此后每两个月发布一次。要注意的是，XP中每次发布的内容不是演示版，而是实用版。也就是说，并不是仅仅将其演示给客户看，让其评论，最后放到一边，继续等待最后的开发结果，而是交付使用的子集，让客户每一天都在使用。
另外，为了保证开发出来的结果与客户的预想接近，XP方法论认为最重要的是需要将客户请到开发现场。在项目中有客户在现场明确用户需求，并做出相应的业务决策对于XP项目而言有着十分重要的意义。这时因为，仅靠简单的用户需求描述是不充分的，还需要大量地与客户沟通。在本题中所列举的项目是在现场开发，因此现场客户是有保证的。
【问题2】
XP的核心是其总结的沟通、简单、反馈、勇气四大价值观。它包括12种最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户，以及编码标准。
从XP方法论本身来说，首先第一类潜在问题是精神和观念上的，即是否能够得到开发人员、管理者，以及客户三方面的支持与理解。简单设计、测试先行、重构、集体代码所有制、编码标准、持续集成都从某种意义上违背了程序员的传统习惯；而小型发布、结对编程、每周工作40小时，经常会让管理者不可理解，以致认为XP是黑客文化，是为开发人员谋福利而来的；而现场客户实践则经常无法得到客户的理解和满足，另外许多客户在接受每一次小规模发布时，也会提出异议。
另外，由于XP方法论属于轻量级，也就是文档量少，遵从“代码就是文档”的思想。因此虽然XP方法论中是有“当非要文档时才编写”的说法，但却容易使团队忽视文档，从而降低系统的可维护性、易用性，以及其他的一些问题。除了培训教育之外，通常还可以采用的解决方案是利用诸如“敏捷建模”策略，在两个极端中间取一个合理的阈值。
结合本题，还有一个十分重要的信息，那就是该项目将部分外包。由于XP方法论强调人的作用，团队之间通过集体代码制、结对编程等方式来提升交流与合作，从而提升生产率的。但是如果项目有部分外包的话，将会破坏这种结构，甚至可能影响到发布计划。
【问题3】
XP方法论的创始人Kent Beck在其《拥抱变化：解析极限编程》一书中明确指出了：“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）在此基础上，建立面向目标的项目管理。
希赛公司是一家中等规模的计算机企业，专业从事网络安全防护软件系统的开发。从最初仅开发基于Windows的个人防火墙产品开始，现在，已经延伸到基于Linux、Windows系列、MAC操作系统的个人防火墙、企业防火墙、入侵检测系统、病毒扫描系统、安全扫描系统等多种产品。公司原来的产品都是一个一个地开发，为每个软件对应地组织一个项目组。
为了适应快速变化的市场，降低开发成本，公司想引入产品线方法。然而，由于软件产品线方法涉及了一个软件开发企业的多个产品，所以，公司的王总决定在弄清楚以下三个问题之后再做决定：首先就是本公司的业务范围是否适合使用产品线方法，其次是如何在原有产品的基础上建立产品线，最后是成功实施产品线的主要因素是什么？
【问题1】
请用100字以内文字，说明希赛公司是否适合采用产品线方法，并说明理由。
【问题2】
请用400字以内文字，说明在原有产品的基础上建立软件产品线的方式，并作简要评价。
【问题3】
请用150字以内文字，说明成功实施产品线的主要因素。
软件产品线（software product line）是一个十分适合专业的软件开发组织的软件开发方法，能有效地提高软件生产率和质量、缩短开发时间、降低总开发成本；它也是一个新兴的、多学科交叉的研究领域，研究内容和范围都相当广泛。
卡耐基·梅隆大学软件工程研究所（CMU/SEI）对产品线和软件产品线的定义，比较能够体现软件产品线的特征：“产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足选定的市场或任务领域的特定需求。这些系统是遵循一个预描述的方式，在公共的核心资源（core assets）基础上开发的。”
软件产品线开发有四个基本技术特点：过程驱动、特定领域、技术支持和架构为中心。与其他软件开发方法相比，软件开发组织选择软件产品线的宏观上的原因有：对产品线及其实现所需的专家知识领域的清楚界定，对产品线的长期远景进行了策略性规划。
【问题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）产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足选定的市场或任务领域的特定需求。这些系统遵循一个预描述的方式，是在公共的核心资源（core assets）基础上开发的。
根据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】
请用400字以内文字，分别论述原型法与严格定义法适用的场合。
【问题2】
原型生命周期提供了一种用原型法完成需求定义的完整方法。但对于一些特殊情况，如规模较小，完整性要求较弱的应用，可以采取灵活的做法以适应实际目标。请用300字以内文字，说明改变原型生命周期约束的方法。
【问题3】
引入原型法后，需要对项目管理的过程加以适当修正。请用300字以内文字，说明引入原型法后，项目管理的基本内容。
【问题1】
需求定义方法主要可以分为严格定义方法和原型化方法。
严格定义（预先定义）是目前采用较多的一种需求定义方法。在采用严格定义的传统的结构化开发方法中，各个工作阶段排列成一个理想的线性开发序列，在每一工作阶段中，都用上一阶段所提供的完整、严格的文档作为指导文件。在传统的结构化开发中，需求的严格定义建立在以下这些基本假设上：
（1）所有需求都能够被预先定义。
（2）开发人员与用户之间能够准确而清晰地交流。
（3）采用图形模型/文字可以充分体现最终系统。
（4）修改定义不完善的系统代价昂贵且实施困难。
（5）严格方法的生命周期的各阶段的划分都是正确的。
在使用严格定义需求的开发过程中，开发人员与用户之间交流、通信的主要工具是定义报告，包括叙述文字、图形、逻辑规则和数据字典等技术工具。它们的一个共同特点，都是静止的、被动的，不能实际表演，很难在用户头脑中形成一个具体的形象。因此，要用静止的图形/文字描述来体现一个动态的系统是比较困难的。
除了所论述的情况外，上述基本假设还将导致严格定义的结构化开发方法存在以下缺陷。
首先是文档量大，由于在结构化方法的每个阶段都必须写出规范、严密的各种文档，这些文档虽然有助于开发人员之间、用户与开发人员间的通信交流，有助于开发过程的规范化，但由于编写文档花费大量人力和时间，导致系统开发周期增长。
其次是开发过程可见性差，来自用户的反馈太迟。由于在需求定义、系统设计阶段都不能在用户终端显示新系统的实际效果，一直到系统实现阶段结束，用户才有机会通过对新系统的实际操作和体会，来提出他们对新系统的看法和意见，但此时整个开发已近尾声，若想修改前几段的工作或修改需求定义，都将付出较大的代价，有时这种修改甚至会导致整个系统的失败。
综上所述，需求的严格定义的基本假设在许多情况下并不成立，传统的结构化方法面临着一些难以跨越的障碍。为此，需要探求一种变通的方法。
原型化方法以一种与严格定义法截然不同的观点看待需求定义问题。原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许用户在开发过程中提出更好的要求，根据用户的要求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式。
需求定义的原型化方法基于以下假设：
（1）并非所有的需求都能在系统开发前都被准确地说明。
（2）项目参加者之间通常都存在交流上的困难，原型为克服该困难提供了一种手段。
（3）需要实际的、可供用户参与的系统模型。
（4）有合适的系统开发环境和快速的系统建造工具。这些工具主要包括集成的数据字典、高适应性的数据库管理系统、非过程的报告书写器、非过程查询语言、屏幕生成器、超高级语言、自动文档编排、原型人员工作台。
（5）反复是完全需要和值得提倡的，但需求一旦确定，就应遵从严格的方法。
【问题2】
原型生命周期由10个步骤组成，分别是合适的选择、识别基本需求、开发工作模型、模型验证修正和改进、判定原型完成、判别细部说明、严格说明细部、判定原型效果、整理原型和提供文档。
对于一些有特殊要求或特殊情况的应用，如规模较小，完整性要求较弱的应用，为了获得较高的效益，可以采取灵活的做法，以适应实际目标。
原型生命周期意味着对自身的以下若干约束：
（1）建立一个完整的模型。
（2）原型人员要建立初始模型。
（3）原型化要从定义阶段开始。
（4）实际系统将用自己的资源来建立。
改变原型生命周期约束的方法有：
（1）仅对屏幕的原型化。
（2）使用购买的应用系统作为初始模型。
（3）子系统原型化。
（4）原型与需求建议。
（5）最终用户进行原型化。
【问题3】
原型化并不会改变整个项目实施和项目管理的有效性和合理性，只是做一些适当的调整。所以，像所有开发方法一样，原型化方法一也需要项目管理，因而需要对项目管理的传统方式和过程加以适当的修正，使其既有灵活性又有可靠性。
项目管理包括估计过程、费用重新分配、变化控制以及活动停止。
（1）估计过程。这是估计原型的时间、成本和系统目标的方法。原型法的成本估计就是指由项目管理所要求的实际系统的建立和修改成本的估计。首先，用户为满足其要求而支付的时间和设备，这些成本是显而易见的，它取决于每次重复周期的进展状况。其次，在原型被接受后，立即可以做出一个静态的成本估计。
（2）费用重新分配。在开发模型中所带来的所有费用都要记在用户的账单上，原型的制作也带来了占用机器的费用。费用分配对控制重复周期是最有效的，因为重复会多花钱。
（3）变化控制。由谁来决定原型的改变是一个复杂的问题。探索这一问题的最佳解决方案是，对项目管理机制来说，做一个交互式的控制板，一个小型设计组根据目前掌握的资料做出变化或不变化的决定。在原型化项目管理的四项内容中，最为复杂的内容就是变化控制。
（4）活动停止。在传统的定义讨论中，用户的活动停止是以叙述／图解模型为基础的。在原型化环境中活动停止就相当于已允许原型作为理想的系统。
【问题1】
严格定义方法适用的场合如下。
（1）所有的需求都能够被预先定义。
（2）修改定义不完备的系统代价昂贵且实施困难。
（3）项目参加者之间能够清晰而准确地进行通信。
（4）静态描述或图形模型对应用系统的反映是充分的。
（5）严格方法的生命周期中各阶段划分都是正确的。
原型法适用的场合：
（1）并非所有的需求在系统开发以前都能准确地说明。
（2）有快速的系统建造工具。
（3）项目参与者之间经常存在通信上的障碍。
（4）需要实际的、可供用户参与的系统模型。
（5）需求一旦确定就可以遵从严格定义的方法。
（6）大量的反复是不可避免的、必要的，应该加以鼓励。
【问题2】
改变原型生命周期约束的方法如下。
（1）仅对屏幕的原型化。
（2）使用购买的应用系统作为初始模型。
（3）子系统原型化。
（4）原型与需求建议。
（5）最终用户进行原型化。
【问题3】
引入原型法后，项目管理的基本内容如下。
（1）估计过程。
（2）费用重新分配。
（3）变化控制。
（4）活动停止。
张工和李工分别是某公司信息系统项目组和系统开发组的负责人。下面是张工与李工讨论信息系统项目组承接的新项目时的对话。
张工：我们这次承接的新系统很具有挑战性，在开发过程中不仅要使用一种新的数据库管理系统，用户所给的开发时间也比较短。我担心使用传统的SDLC（软件开发生存周期）方法可能无法按期完成系统开发任务。
李工：这个项目有什么特点吗？
张工：我不知道用户是否确切地明白他们想要一个怎样的新系统。他们提出了许多要求，但是我不敢确定他们是否真正理解这个新系统的功能。而且，这个系统可能会相当复杂，因为它要与多个已有的系统进行交互。
李工：我希望我们有更多使用RAD（Rapid Application Development，快速应用开发）方法的经验。目前你所面临的状况可能比较适合使用这种方法。
张工：我同意。但是这个项目的时限不允许我们去学习运用RAD方法的工具，以及即将要使用的新的RDBMS（关系数据库管理系统）。
【问题1】
用100字以内文字，分析使张工放弃采用传统的SDLC方法的原因。
【问题2】
用200字以内文字，说明RAD方法的基本思想。
【问题3】
如果张工采用RAD方法开发该项目，应如何解决对RAD工具不熟悉，以及使用新数据库管理系统的问题？用150字以内文字说明。
快速应用开发（Rapid Application Development，RAD）是一种比传统生命周期法快得多的开发方法，它强调极短的开发周期。RAD 模型是瀑布模型的一个高速变种，通过使用基于构件的开发方法获得快速开发。如果需求理解得很好，且约束了项目范围，利用这种模型可以很快开发出功能完善的信息系统。
RAD的基本思想体现在以下四个方面。
（1）让用户更主动地参与到系统分析、设计和构造活动中来。
（2）项目开发期间将组织一系列重点突出的研讨会，研讨会要让项目投资方、用户、系统分析师、设计人员和开发人员一起参与。
（3）通过一种迭代的构造方法，加速需求分析和设计阶段。
（4）让用户提前看到一个可工作的系统。
RAD的流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试与交付。
（1）业务建模。确定驱动业务过程运作的信息、要生成的信息、如何生成、信息流的去向及其处理等，可以使用数据流图来帮助建立业务模型。
（2）数据建模。为支持业务过程的数据流查找数据对象集合、定义数据对象属性，并与其他数据对象的关系构成数据模型，可以使用E-R图来帮助建立数据模型。
（3）处理建模。将数据对象变换为要完成一个业务功能所需的信息流，创建处理以描述增加、修改、删除或获取某个数据对象，即细化数据流图中的加工。
（4）应用生成。利用第四代语言（4GL）写出处理程序，复用已有构件或创建新的可复用构件，利用环境提供的工具自动生成并构造出整个应用系统。
（5）测试与交付。因为RAD强调复用，许多构件已经是测试过的，这就减少了测试的时间。由于大量复用，所以一般只做总体测试，但新创建的构件还是要测试的。
RAD采用基于构件的开发方法，复用已有的程序结构（如果可能的话）或使用构件，或者创建可复用的构件（如果需要的话）。在所有情况下，均可以使用CASE工具辅助进行软件构建。如果一个业务能够被模块化使得其中每一个主要功能均可以在不到三个月的时间内完成，那么，它就是RAD的一个候选者。每个主要功能可由一个单独的RAD组来实现，最后再集成起来，形成一个整体。
所有RAD方法的主要目标是通过用户参与系统开发的每一个阶段来缩减开发时间和费用。由于RAD是一个连续的过程，因此随着设计的进行，RAD允许开发小组迅速地做出必要的修改。当公司预算紧张时，对于发生在一个已制定好的长时期的进度表中的变化所带来的花费进行限制尤为重要。
与传统的结构化分析方法相比，RAD的主要优点如下。
（1）强调用户参与，可以尽快明确需求，降低系统开发风险，缩短系统开发周期。
（2）通过大量使用可复用构件，加快了开发速度。
但是，RAD也具有以下局限性。
（1）RAD强调系统本身的结构，系统可能在短时间内工作很好，但是系统的整体和长期的目标可能得不到满足。
（2）加速开发周期可能会导致没有更多的时间提高项目质量、连贯性和设计的标准化。
（3）并非所有应用软件都适合于使用RAD。如果一个系统难以模块化，那么建造RAD所需构件就会有问题；如果需要高性能的指标，且该指标必须通过调整接口使其适应系统构件才能获得，使用RAD方法就有可能失败；RAD不适合技术风险很高的情况，当一个新应用要采用很多新技术或新软件要求与已有计算机程序有较高的可互操作性时，项目也可能会失败。
【问题1】
（1）开发时间成为制约软件开发的重要因素。
（2）不明确的用户需求。
（3）必须使用不熟悉的开发技术。
【问题2】
（1）让用户更主动地参与到项目分析、设计和构造活动中来。
（2）项目开发期间将组织一系列重点突出的研讨会，研讨会要让项目投资方、用户、分析员、设计人员和构造人员一同参与。
（3）通过一种迭代的构造方法加速需求分析和设计阶段。
（4）让用户提前看到一个可工作的系统。
【问题3】
（1）张工应尽可能在项目启动之前对项目组的部分成员进行RAD工具和相关技术，以及采用新的RDBMS的培训。
（2）可以聘请一个专业顾问来指导项目组使用RAD工具和相关技术。
当前企业中的业务都是在全球化、快速变化的环境中运营的，传统的软件开发过程无法适应由此产生的快速软件开发需求。20世纪90年代后期，一些软件开发人员在“AgileAllicance2001”中系统地阐述了敏捷开发的原则，试图强调灵活性在快速且有效地生产软件中所发挥的作用。目前，众多的软件生产企业已经在实际的软件开发过程中接纳并实践了敏捷开发方法中的基本原则。
【问题1】
敏捷开发有许多典型方法，包括极限编程（eXtreme Programming）、Scrum、Crystal、DSDM等。请问这些方法共同的基本原则是什么？
【问题2】
敏捷开发的支持者往往夸大该方法的优点，但是在实践中，敏捷方法的基本原则有时确实很难实施。请用200字以内的文字说明敏捷方法中哪些原则在实践中难以实施。
【问题3】
敏捷开发方法中最有名的是极限编程。请说明极限编程中的结对编程（PairProgramming）的概念。
【问题4】
敏捷开发方法在具体实践过程中，往往需要开发环境或工具的支持，一般称为快速应用开发技术和可视化开发技术。请用150字以内的文字说明快速应用开发技术所包含的工具有哪些，并简要说明可视化开发技术的基本概念和技术原理。
这是一道关于敏捷开发方法（主要是XP方法）的问答题，共4个问题。在系统分析师考试指定参考用书《系统分析师技术指南》（张友生、王勇主编，清华大学出版社）中，详细介绍了敏捷开发方法和XP方法。
【问题1】
注重个体与交互，重点关注可以工作的软件，提高客户参与度，以积极的心态响应变化是敏捷方法论的核心价值观。为了贯彻这四大价值观，敏捷联盟提出12条区别于重量级过程的原则。
（1）尽早、持续交付有价值的中间软件使客户满意。很多开发组织经常会在时间期限上进行没有原则地退让，其结果却是让客户一等再等，不仅没有按承诺兑现，甚至是时间超过一倍，但仍然不见软件的踪迹。这种不守信的状态，使得整个软件业走入了一个负螺旋发展。敏捷方法论提出了一种新的逻辑，将尽早、持续地交付可运行的中间成果，有价值的中间结果，使得客户能够尽早地、持续地了解到软件开发的进展，并且将需求的变化、系统的改进意见尽早地提出来，这会使得客户的满意度大大提高。
（2）即使到了开发后期，也欢迎需求变化，利用响应变化创造竞争优势。敏捷方法论鼓励团队拥抱变化，通过应用各种技术来提高软件结构的灵活性，本着简单的原则进行设计，以响应变化的能力作为团队的核心竞争力。
（3）经常交付可工作的软件，间隔时间可以是几周到几个月，间隔越短越好。由于敏捷方法论奉行“客户合作”、“客户参与”，而要让客户更加有效的参与，经常性、频繁地交付可工作的中间软件，将可以有效地加强开发人员与客户之间的沟通，从而将隐藏的需求变化及早触动。
（4）开发全过程，业务人员和开发人员必须天天都在一起工作。在开发中，不仅需要客户参与开发，还应该包括代表客户的业务人员。因此在开发人员、客户、业务人员等相关干系人之间建立频繁而且密切的交流与沟通，将是使项目保持高度灵活性的关键。
（5）为开发人员提供环境和支持，给予信任，以人为本地构建项目。敏捷方法论是崇尚“以人为本”精神的，认为项目成功的最关键因素是人，其意义超过过程和工具。建立一支优秀的团队，并在环境与精神上提供支持，给予信任，将是项目成功的关键。这也是与传统的“过程”为主的管理思想的最大不同。
（6）团队内部，最有效的沟通方式莫过于面对面的交谈。在重量级方法论中，人们尝试着通过编写规范、精美的文档进行交流。而在敏捷方法论中则更加重视的是开发团队成员之间的面对面交谈，大家坐在一起，用一块白板，或是一张纸，一边绘制草图，一边交谈，这是最有效的沟通方式。
（7）工作的软件是度量进度的最首要标准。要衡量工作进度，采用的基点不是文档的完成情况，不是已完成的代码行数，而是可以工作的软件完成了多少功能、实现了多少用例。这是敏捷方法论的共同点，因为只有可工作的软件才是有价值的。
（8）提倡可持续的开发速度，责任人、开发者和用户应保持一个长期的、恒定的开发速度。软件开发绝不是短跑，它更像一场挑战耐力的马拉松长跑。因此，过早的冲刺、在前期过度的工作，将不利于项目按照持续的开发速度进行下去。因此，敏捷方法论反对加班，因为这样的行为会使得团队的精力过早耗尽，过早地对项目失去兴趣和信心，从而得到事与愿违的结果。
（9）不断关注好的技能和设计会增加敏捷能力。保持软件高质量、简洁、健壮，是实现快速软件开发的重要途径。因此只有大家都致力于编写高质量的代码、不创造混乱，才能够提升敏捷能力。
（10）开发者本质是简单的——使未完成的工作最大化的艺术。不管明天的需求，只采用符合今天需求的简单设计。因为谁也不知道明天是怎么样的？变化太快了，今天的设计考虑太多明天的需求，就有可能做了过多的无用功。
（11）自组织的团队才能够做出最好的架构设计和需求分析。最优秀的团队不是被强权管理下的团队，而是形成了一个良好的协作，能够内部进行任务分解、协调的团队。
（12）团队应定期在如何更有效工作方面进行反省，然后对自己的行为做出改进。不断地回顾、总结，并从中找到团队未能最有效工作的瓶颈点和问题点，并且通过细致的分析与讨论，找到其要点，并做出相应的改进是十分重要的。
【问题2】
问题2问敏捷方法的原则中哪些原则在实践中难以实施，这与问题1是相关联的。只要理解了这些基本原则，这个问题就好解答。因为问的是在“实践中难以实施”，所以这个问题可以答得灵活些，只要说得有道理都可以得分。
【问题3】
问题3考查结对编程的概念，简单地说，结对编程就是2个人坐在一起写同一个程序。结对编程可以大大降低沟通成本，提高工作质量。
【问题4】
问题4是关于快速开发工具和可视化开发的。快速应用开发（RAD）目的是快速发布系统，RAD组合了5个方面的技术，分别是进化原型、CASE工具（可进行正向工程和反向工程）、拥有能使用先进工具的专门人员（一个RAD开发小组）、交互式JAD、时间表。例如，VB、Delphi、PB等都属于RAD工具。可视化开发就是在可视开发工具（例如，VB、Delphi、PB等）提供的图形用户界面上，通过操作界面元素（例如，菜单、按钮等），由可视开发工具自动生成应用软件。这类应用软件的工作方式是事件驱动的。对每个事件，由系统产生相应的消息，再传递给相应的消息响应函数。
【问题1】
（1）客户参与。
（2）增量式移交。
（3）开发团队的技术应该得到承认和发扬。团队成员应该保持他们自己的工作风格，不落俗套。
（4）接受变更。
（5）保持简单性。
【问题2】
（1）客户的参与度往往依赖于客户参与的意愿和客户自身的代表性。
（2）团队成员的性格可能不适合激烈的投入，可能无法做到与其他成员之间的良好沟通。
（3）对系统中的变更作出优先级排序可能是极端困难的。
（4）维护系统的简洁性往往需要额外的工作，但迫于移交时间表的压力，可能没有时间执行系统简化过程。
【问题3】
结对编程：开发人员成对工作，检查彼此的工作并提供支持，圆满完成任务。
【问题4】
快速应用开发中所包括的工具有数据库编程语言、界面生成器、与办公应用的连接、报告生成器。可视化开发是一种通过集成细粒度可复用构件来构造软件的快速应用开发方法，其主要思想是用图形工具和可重用部件来交互地编制程序。可视化开发一般基于事件驱动的原理。
某公司的主要业务是利用网络进行音像制品的管理和销售，以提高其物流配送的效率。随着业务范围的扩展和业务过程的改进，公司CIO发现现有信息系统业务过程过于僵化、维护困难，不能真正地为企业贡献价值，已经不能满足公司长久发展的战略。在CIO的建议下，该公司在三月初委托希赛公司为其开发出一套新的音像制品在线管理及销售系统AVMSS，要求新系统能够对其现有系统业务过程进行重新设计，以提高公司业务的执行效率并降低维护成本。
希赛公司成立了项目组来开发 AVMSS，在对开发任务进行了初步的了解之后，项目组认为该公司原有系统的数据架构稳定，没有必要对原有关系数据模式进行重新设计；新系统应着眼于对系统控制流的改造，通过系统业务流程再造以应对公司的发展需要。但在选择系统开发方法时出现了分歧，张工认为应该采用流行的面向对象开发方法，而李工则认为应该采用成熟的结构化开发方法，项目组经过讨论最终确定在AVMSS系统分析与设计过程中采用李工的建议。
【问题1】
请对张工和李工所提出的两种系统开发方法进行比较，结合AVMSS系统说明为什么项目组最终采用了李工的建议。
【问题2】
结构化分析主要包含初始研究、问题分析、需求分析、逻辑建模和方案分析五个阶段，请用300字以内的文字说明需求分析和逻辑建模两个阶段的目标及主要任务。
【问题3】
4月底，项目组完成初始研究阶段的任务，进入了问题分析阶段，以确立系统改进目标。刚参加工作的小赵仔细分析了初始研究阶段的相关文档和资料，在讨论会上提出了以下的系统改进目标。
（1）提高联机订单处理的用户满意程度。
（2）新的系统必须使用Oracle数据库管理系统存储数据。
（3）数据输入屏幕必须重新设计以使其更加友好。
（4）影音销售子系统中订单处理所需的时间减少50%。
这些是好的系统改进目标吗？请分别说明理由。
【问题4】
6月初，项目需求分析阶段遇到了大量的困难，并且比计划进度落后了两个星期，项目经理希望通过跳过或者省略逻辑建模阶段的一些任务来赶上进度。项目经理认为，现在大家对需求有了清晰的认识，而且项目组的设计人员和构造人员经验都很丰富，直接可以进行技术设计而并不真正需要逻辑建模。为了赶上进度，这是合理的方法吗？请用200字以内的文字说明理由。
本题主要考查考生对于结构化开发方法和面向对象开发方法的掌握情况。
结构化开发方法与面向对象开发方法是最重要的两种软件开发方法学。结构化方法是软件开发与维护的基础方法，其他现代软件方法学都是在结构化方法基础上发展和演绎而来，而且遵循基本的结构化思想；面向对象方法作为当前最为流行的软件方法学，逐渐被系统分析和设计人员所接受，并在系统开发中加以应用。当前很多企业处于业务转型期，信息化基础设施建设成为企业业务发展的必要组成部分。企业信息化改造中，不仅需要开发新系统，而且面临着如何对其现有业务系统改造的问题。因此，系统开发团队需要针对具体的应用需求选择适合的软件开发方法，以提升系统开发的效率和效果。作为一名系统分析和设计人员，对结构化开发方法和面向对象方法均应该有所了解。特别是要掌握在项目实际开发中对于不同开发方法选择的依据和标准。
结构化方法主要的关注点是系统功能，强调业务过程的数据流和控制流，采用模块化、自顶向下、逐步求精的设计过程。系统是实现模块功能的函数和过程的集合，开发过程划分为若干相对独立的阶段，结构清晰、可读性好，是提高软件开发质量的一种有效手段。结构化方法主要适合于规模较大、结构化程度较高的系统的开发。
面向对象关注于处理的数据，以对象为中心，对象能够将数据及其行为统一起来，对象之间通过消息交换引发对象的行为。对象模型极大提高了数据和功能的复用程度，简化了开发系统开发过程，系统的可维护性得到了改善。
【问题1】
（1）结构化开发方法强调系统业务过程的数据流和控制流，将系统看作一个过程的集合体，系统数据架构和控制流可以分开设计，强调系统的业务处理过程，适合于业务流程再造和对处理过程要求较高的系统；而面向对象方法则把系统看作一个相互影响的对象集，对象能够将数据及其行为统一起来，对象之间通过消息交换的方式引发对象的行为。
（2）希赛公司现有系统只是自动化了企业的业务过程，造成信息系统业务过程低效且维护成本高的一个重要因素是企业的业务过程本身过于僵化，不能真正地为企业贡献价值，信息系统只是将这些低效率的过程自动化。真正的解决办法是业务流程再造。在AVMSS系统的开发中，强调控制流的改进，因此比较适合于采用传统的结构化开发方法，采用李工的建议比较合理。
【问题2】
（1）需求分析阶段：定义系统的业务需求。具体任务包括定义需求、排列需求的优先次序、修改项目计划、交流需求陈述。
（2）逻辑建模阶段：使用系统模型进一步记录业务需求并对需求进行验证。具体任务包括结构化功能需求、建立功能需求的原型（可选）、验证功能需求、定义验收测试用例。
【问题3】
（1）不是。评价方式无量化指标。
（2）不是。是系统约束，不是系统目标。
（3）不是。是系统需求，不是系统目标。
（4）是。对系统性能量化明确、具体的陈述。
【问题4】
不合理的方法。项目执行过程具有天然的风险，系统分析不同阶段的每个任务都为后续任务打好坚实的基础，其每个阶段均不能跳过或被省略。系统逻辑设计阶段产生的图表和文档，是系统所有者和系统用户最后一次验证系统的功能需求，并对发现的错误进行修正和说明的关键。