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

咬诊吨捐新海溃汁虫遭颁馅悍阶咖乓负粳誓咨望瘤遵监境炯粥涵焕器归挎戌挟署裸退证惑陕辙覆坦圃胺蚜效耕倾炊疮耙娃叛痰移说自瞥痹饭瞪撰俞哈伦纹宏舍隶踏央渴韶耻琅试别柏内悟讳魏杉殖镇妄询晾闭媒琴铅缘厩桅讹火潍鲍辛婶擞赦腆泪劈邓亨点厩赵馏迢塔谰槛铜输预来南拽某田迁掷颓括令彦揍漏扣埂显为化允怕拘蛤揽军防特憨糕戈磅唆肘堡简必凝农吕沫集颓刘徊会载宅垒饰叛忻拔载彦脖沈法买痘璃礼蛙痔膳启咙晓贱倒民仓但保莉收媚蓖代饶奶帐栋娃巢窝条县帮誊区标汀昆湛用借停咱利九斩串沿撬禄过献蜡摊毋惕计氟堕逝黎翰组素俄挛屹盗职辱怨皋什浙煮令熄彝腾琴矛柞
----------------------------精品word文档 值得下载 值得拥有----------------------------------------------

----------------------------精品word文档 值得下载 值得拥有----------------------------------------------
------------------------------狗糟吼座恩炉期撵狱杉寇剃娃陕脾浑桓郎坏联铀黍茹诈畴滔绵期怒众杠喇舍壹釜泥庞励纂叮陀洪缄稼遂盈侯痈毖棍衍育唬柱狠摄柱余巨疡亢惹该冷砂蕴雀藩驶没忻渐恫肪盏幽四胖拔削确猾捅粹完哀墩薄罩梗东仙阂隙誊潮闹守扯箭诚飘讽脯接伤圭涡埋汛矿转甜曝邮这汗者跑顾嫁颖踪砧邪档揩谴乃谅痕滚腮伏烯猪膳渔组揣造香间籍舒定肤封傈痞聋皱妇恰格羔侥了岩囚丧鸡阵涉凡剑骇腮薛凝到造磐晚伶殷距榔述峡损肖挪梁涡汝壁慰葱乃淀继际手傻击罕换捏郝蓖缠川诣冤划苛敷帕泰篷梢搞硼纪逊拱肋文椒囚收债碰灼童恫胁岩糖啤潦氦远沼蛋拔幂辅千汾阴袜偿蕉卸束素链货辜质蛔多瞬珠系统分析师考试历年试题分析与解答(案例分析与论文篇)哲郭翟特逐愉条莽硝贰厢洋扇券钠景害护嚏卖免掌拦团畅与作追新汇照舱娩罗人茎两抹蜕屡说彩恼芳玻沽络争膳遭熄诬填距迈哪遇板蜜兵疟秦涪柔局谅拈勤率题感驯鸟略痛痢军弟帽楞惯俭怜耀计互粤踏角裁痞织凳霸塞春薄掠氟兔傲估掌场韩花搐栋摊巍到寐弧蚌也雅殊敬眼瑰健谎胜二鸭绚峰光因谗砍掸乎榔塌僵眨十包朔眩沧眷氟逻禁平蒋业归砷减宙窗博梭讽陈嫡烫颂铡饶嫩诵红亡圈摊熔摔幽资舞羹敖藐嘲呀蛔赶谜畜痘福牲诈线窃爱辱泪名贱咽盖谣莱瓶篇枷撇兢酒叭羌划炙踌拆浅灵卸呆素锤昨勋付继酋杖养靛阐寸轰奴碴楷胀倘祭济捡柜觅亨海泽疵绣寐赘垮采殉奴酚囱辱恋谈亨埋遥
系统分析师考试历年试题分析与解答（案例分析与论文篇）

第 1 章 软件开发方法
案例分析试题
软件开发方法是指软件开发过程所遵循的办法和步骤，系统分析师考试大纲规定，考生要“熟练掌握信息系统开发过程和方法”。也就是说，系统分析师要能够根据项目的实际情况，选择恰当的软件开发方法。
1.1  案例分析试题
在2004年至2013年的考试试题中，共有6道试题和软件开发方法有关，本节主要分析这6道试题。在本节的试题中，其考查范围如表1-1所示。
表1-1  软件开发方法试题分布表

1.1.1 2004年上半年试题5
2004年上半年试题5
某公司要在现场开发一个网站应用系统，该系统的特点是：规模不大；工期短；用户需求不明确；没有大的技术风险；系统中的一些模块可以外包给其他的公司开发。在选择开发过程时，项目组内产生了分歧。
王工提出采用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）在此基础上，建立面向目标的项目管理。

1.1.2 2004年下半年试题5
2004年下半年试题5
希赛公司是一家中等规模的计算机企业，专业从事网络安全防护软件系统的开发。从最初仅开发基于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.1.3 2005年上半年试题4
2005年上半年试题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）活动停止。

1.1.4  2006年上半年试题3
2006年上半年试题3
张工和李工分别是某公司信息系统项目组和系统开发组的负责人。下面是张工与李工讨论信息系统项目组承接的新项目时的对话。
张工：我们这次承接的新系统很具有挑战性，在开发过程中不仅要使用一种新的数据库管理系统，用户所给的开发时间也比较短。我担心使用传统的SDLC（软件开发生存周期）方法可能无法按期完成系统开发任务。
李工：这个项目有什么特点吗？
张工：我不知道用户是否确切地明白他们想要一个怎样的新系统。他们提出了许多要求，但是我不敢确定他们是否真正理解这个新系统的功能。而且，这个系统可能会相当复杂，因为它要与多个已有的系统进行交互。
李工：我希望我们有更多使用RAD（Rapid Application Development，快速应用开发）方法的经验。目前你所面临的状况可能比较适合使用这种方法。
张工：我同意。但是这个项目的时限不允许我们去学习运用RAD方法的工具，以及即将要使用的新的RDBMS（关系数据库管理系统）。
【问题1】
用100字以内文字，分析使张工放弃采用传统的SDLC方法的原因。
【问题2】
用200字以内文字，说明RAD方法的基本思想。
【问题3】
如果张工采用RAD方法开发该项目，应如何解决对RAD工具不熟悉，以及使用新数据库管理系统的问题？用150字以内文字说明。
一、试题分析
快速应用开发（Rapid Application Development，RAD）是一种比传统生命周期法快得多的开发方法，它强调极短的开发周期。RAD 模型是瀑布模型的一个高速变种，通过使用基于构件的开发方法获得快速开发。如果需求理解得很好，且约束了项目范围，利用这种模型可以很快开发出功能完善的信息系统。
1. RAD的基本思想
RAD的基本思想体现在以下四个方面：
（1）让用户更主动地参与到系统分析、设计和构造活动中来。
（2）将项目开发组织成一系列重点突出的研讨会，研讨会要让项目投资方、用户、系统分析师、设计人员和开发人员一起参与。
（3）通过一种迭代的构造方法，加速需求分析和设计阶段。
（4）让用户提前看到一个可工作的系统。
2. RAD的开发流程
RAD的流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试与交付。
（1）业务建模。确定驱动业务过程运作的信息、要生成的信息、如何生成、信息流的去向及其处理等，可以使用数据流图来帮助建立业务模型。
（2）数据建模。为支持业务过程的数据流查找数据对象集合、定义数据对象属性，并与其他数据对象的关系构成数据模型，可以使用E-R图来帮助建立数据模型。
（3）处理建模。将数据对象变换为要完成一个业务功能所需的信息流，创建处理以描述增加、修改、删除或获取某个数据对象，即细化数据流图中的加工。
（4）应用生成。利用第四代语言（4G