在软件开发过程中，如果项目的规模和工作量大，项目具有较大的开发团

正确答案：(1)可以将XP和传统软件开发过程中的增量式开发过程相结合。 (2)将大规模项目划分为若干个具有共同目标的小规模项目用XP方法论组织小项目开发用传统软件过程方法论监控全局。 (3)在此基础上建立面向目标的项目管理。 要求说明XP与传统过程方法的结合方法也就是如何在同一个项目中运用。 第二步：根据问题要点仔细阅读正文找出相应段落 (1)在题目的第一段中包括项目的基本描述即某公司要在现场开发一个网站应用系统该系统的特点是规模不大；工期短；用户需求不明确；没有大的技术风险；系统中的一些模块可以外包给其他的公司开发。 在上面的描述中较重要的是现场开发、网站应用、规模不大、工期短、需求不明确、无大的技术风险、部分外包。 (2)在题目的第二段中阐明了采用XP的理由即XP方法简洁能减轻开发人员的负担、快速适应市场、缩短投资回收期。 (3)在题目的第三段中只说提出了一些XP存在的问题但并没有具体地说明不过给出了一个信息即建议考虑使用原型法。说明所指出的问题一定是可以用原型法来解决的。 (4)在第三个问题的描述中提出了“如果项目规模扩大XP将不再适用”这也是指明了结合XP与传统过程方法的重要原因说明回答应该围绕这个主题来进行。 第三步：分析试题的内容构思答案的要点
(1)可以将XP和传统软件开发过程中的增量式开发过程相结合。 (2)将大规模项目划分为若干个具有共同目标的小规模项目，用XP方法论组织小项目开发，用传统软件过程方法论监控全局。 (3)在此基础上，建立面向目标的项目管理。 要求说明XP与传统过程方法的结合方法，也就是如何在同一个项目中运用。 第二步：根据问题要点，仔细阅读正文，找出相应段落 (1)在题目的第一段中包括项目的基本描述，即某公司要在现场开发一个网站应用系统，该系统的特点是规模不大；工期短；用户需求不明确；没有大的技术风险；系统中的一些模块可以外包给其他的公司开发。 在上面的描述中，较重要的是现场开发、网站应用、规模不大、工期短、需求不明确、无大的技术风险、部分外包。 (2)在题目的第二段中，阐明了采用XP的理由，即XP方法简洁，能减轻开发人员的负担、快速适应市场、缩短投资回收期。 (3)在题目的第三段中，只说提出了一些XP存在的问题，但并没有具体地说明，不过，给出了一个信息，即建议考虑使用原型法。说明所指出的问题，一定是可以用原型法来解决的。 (4)在第三个问题的描述中，提出了“如果项目规模扩大，XP将不再适用”，这也是指明了结合XP与传统过程方法的重要原因，说明回答应该围绕这个主题来进行。 第三步：分析试题的内容，构思答案的要点 解析：[问题1]
当客户有一个合理的要求，但对细节则没有任何线索时，原型法开发是一个十分常用的方法。本题所涉及的项目就是属于需求不明确的，因此能够有效利用原型法进行解决。
原型法开发从需求收集开始，开发者和客户在一起定义软件的总体目标，标识出已知的需求，并规划出需要进一步定义的区域。然后就是“快速设计”，快速设计集中于软件中那些对用户或客户可见的部分的表示(如输入方式和输出格式)。快速设计导致原型的创建。原型由用户或客户评估并进一步细化待开发软件的需求。逐步调整原型使其满足客户的要求，同时也使开发者对将要做的事情有理好的理解，这个过程是迭代的。
理想情况下，原型可以作为标识软件需求的一种机制。如果建立了可运行原型，开发者就可以在其基础上试图利用已有的程序片断或使用工具(如报表生成器、窗口管理器)来尽快生成可运行的程序。
原型开发方法在实施时，存在的问题主要包括以下2个方面：
(1)客户似乎已经看到了软件的工作版本，却无法理解为了使原型很快能够工作，没有考虑软件的总体质量和长期的可维护性。
(2)开发者常常需要实施上的折中以使原型能够尽快工作。
因此，通常采用原型法，都会在客户和开发者之间达成协议：构建原型仅是为了定义需求，之后就被抛弃了(至少是部分抛弃)，实际的软件在充分考虑了质量和可维护性之后才被开发。这种原型开发方法也称作“抛弃型原型开发”。
当然，也可以采用逐渐演进的方式进行原型开发，即系统以逐步增加的方式进行开发，以便于随时根据客户或最终用户的反馈来修正系统。大多数渐进原型都是从一个用户界面原型开始逐步演化出整个系统的。不过采用原型开发可能出现的风险是：不切实际的进度和预算、项目可控性降低、缺乏最终用户或客户的反馈(因为容易让客户的目标陷入界面而忽略本质，反而造成问题)、产品性能不佳、不切实际的性能期望、设计不佳、可维护性差、目标偏移，而且还有一个最重要的就是原型开发阶段效率一般都较低效。
XP认为“客户确切地知道需求，而且当实现其需求后，他仍然认同”，这种现象几乎不存在。因此，在xP方法论中最重要的一件事情就是尽早、尽量频繁地发布。如果可能，第一次发布时间不应超过2个月，此后每2个月发布一次。要注意的是，XP中每次发布的内容不是演示版，而是实用版。也就是说，并不是仅仅将其演示给客户看，让其评论，最后放到一边，继续等待最后的开发结果；而是交付使用的子集，让客户每一天都在使用。
另外，为了保证开发出来的结果与客户的预想接近，XP方法论认为最重要的是需要将客户请到开发现场。在项目中有客户在现场明确用户需求，并做出相应的业务决策，这对于XP项目有着十分重要的意义。这时因为，仅靠简单的用户需求是不充分的，还需要大量地与客户沟通。在本题中所列举的项目是在现场开发，因此现场客户是有保证的。
[问题2]
XP的核心是其总结的沟通、简单、反馈、勇气4大价值观。它包括12种最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40h、现场客户以及编码标准。
从XP方法论本身来说，首先第一类潜在问题是精神和观念上的，即是否能够得到开发人员、管理者以及客户3方面的支持与理解。简单设计、测试先行、重构、集体代码所有制、编码标准、持续集成都从某种意义上违背了程序员的传统习惯；而小型发布、结对编程、每周工作40h，经常会让管理者不可理解，以致认为XP是黑客文化，是为开发人员谋福利而来的；而现场客户实践则经常无法得到客户的理解和满足，另外许多客户在接受每一次小规模发布时，也会提出异议。
另外，XP方法论属于轻量级，也就是文档量少，遵从“代码就是文档”的思想。因此虽然XP方法论中是有“当非要文档时才编写”的说法，但却容易使得团队忽视文档，从而降低系统的可维护性、易用性以及其他的一些问题。除了培训教育之外，通常还可以采用的解决方案是利用诸如“敏捷建模”策略，在2个极端中间取一个合理的阈值。
本题中还有一个十分重要的信息，那就是该项目将部分外包。由于XP方法论强调人的作用，团队之间通过集体代码制、结对编程等方式来提升交流与合作，从而提升生产率。但是如果项目有部分外包的话，将会破坏这种结构，甚至可能影响到发布计划。
应试者可从上面的叙述中提取所需的答案。
[问题3]
XP方法论的创始人Kent Beck在其《拥抱变化：解析极限编程》一书中明确指出：“XP是适合于中小型团队在需求不明确或者迅速变化的情况下进行软件开发的轻量级方法学”。它与传统的方法论最大的不同如下。
(1)拥有短周期内的早期、具体和持续的反馈。
(2)它递增地进行计划编制，也就是在项目的一开始就迅速提供一个总体计划，然后在项目的整个生命周其内不断地发展它。
(3)它针对不断变化的业务需求灵活地对功能的实现进行计划的能力。
(4)它依赖于由程序员或客户编写的自动测试来监控开发进度。
(5)它依赖于口头交流、测试和源代码来沟通系统的结构和意图。
(6)它依赖于整个系统存在期间一直持续的进化式设计过程。
(7)它依赖于技术水平一般的程序员之间的紧密协作。
(8)它依赖于能够同时满足程序员的短期本能和项目的长期利益的实践。
因此，它并不是与传统的方法论有着“不同戴天”的变化，而是存在很多的结合点，能够有效地在传统方法论中结合XP开发方法的。
集中式方法是传统的软件工程方法的共同特点。它的优点在于具有共同的、清晰确定的目标，而且是一个结构化的过程，领导团队贯穿各个软件开发阶段。它们最大的缺点是缺乏负责员工的参与，而且客户的反馈也很少，导致解决方案的接纳度降低。
XP开发方法则高度涉及员工和客户，可以保证较高的解决方案接纳度。不过当其运用到几个局部问题上往往不能产生与多个团队一起共享的改进，加上XP方法的无结构，因此一个必须包含几个人的复杂问题不能用它来产生一个全面的概念。
(1)层次化结合
基于这样的想法，可以提出层次化的管理。
①在上层，建立一种面向目标的项目管理，它通过产生一个大致概念把问题组织成一种高级结构。
②将目前有局部化问题的每个部分都通过定义一个自身的XP团队，用一种极限编程的方法来予以解决。
如图6-6所示，XP团队主要在独立的基础上发挥功能。同时，他们通过跟踪全局目标和衡量局部改进的顶层管理团队，以一种松散的方式被联系起来。

(2)实践引入式结合
另外一种结合的方式是仍然按照传统过程方法论进行过程的管理，引入XP的实践，实现优势互补。其中比较典型的包括如下内容。
①现场客户：这个实践是对传统过程方法论缺乏客户参与的最好补充。
②简单设计：只为今天设计，不过多地考虑明天的需要，因为现在的假设可以是错误的，也许明天还有更好的实现方式——这是XP提倡的简单原则，它也可以无缝地借用到用传统过程方法论进行管理的项目中。
③小型发布：每次迭代都实现一次小型的发布，提交一个能够让用户开始投入使用的小型版本，可以有效地加强反馈，缩短开发进程，提高软件质量。其中也可结合每日构建进行持续集成，予以保障与支持。
④测试先行、重构：这是保持“小步快走”的关键实践，对于软件质量的提高有很大的帮助。
除此之外，XP方法论中的其他实践也能够有效地在传统的开发过程中发挥作用。

正确答案：略
略

在本项目管理中，我主要采用了面向对象技术同传统技术相结合的原则，在估算项目的工作量这方面尤为突出，面向对象技术对传统技术有所改进，传统技术能弥补面向对象技术的不足。本文从合理的估算项目的工作量及技术难度、识别关键任务、随时了解项目进度，必要时调整进度表等方面，讨论了电力行业工作票、操作票系统项目管理的基本活动与方法，有效地控制开发进度，确保项目如期按质完成。本系统在电力系统已经运行，状况良好，受到一致好评。
2003年2月，我参加了电力行业工作票、操作票系统的开发，担任项目管理工作。电力系统有关部门在对电力设施进行检测、维修、试验等一系列活动时应按照我国电力行业相关标准进行工作，电力行业工作票、操作票系统就是按照国家有关标准及电力行业操作规程设计的仿真系统。工作人员在施工前按照工作流程在此仿真系统上进行操作，严格遵守电力设施的逻辑闭锁关系，顺序执行。有效地防止不规范操作，确保电力设施及现场工作人员的安全，提高安全意识。
本系统由系统图编辑平台和工作票、操作票签发系统两大部分组成，其中系统图编辑平台主要是编辑变电站、用电系统及变电站控制系统图，每一个电力设施对应一个对象，在系统图上都有相对应的部分，系统图真实地反映电力设施的布局及相互关系，生动形象又合乎技术标准，同时为第二部分提供操作对象。工作票、操作票签发系统主要是在系统图的基础上进行点击操作，每次点击对应一个对象即一个电力设施，根据电力设施的逻辑闭锁关系自动生成相应的工作票或操作票或提示操作不规范。
在本系统的开发过程中，我通过合理的估算项目工作量及技术难度、识别关键任务、随时了解项目进度，必要时调整进度表等方面对项目进行管理，确保本系统如期按质完成。1.合理的估算项目工作量及技术难度本系统采用了面向对象的分析、设计等一系列面向对象技术，在本系统工作量的估算上根据功能点进行估算。将每个功能模块逐步分解，直至基本模块为止。我们将系统分为系统图编辑与工作票、操作票签发两个大的功能分别进行估算。系统图编辑部分主要是一个图形编辑系统。一种电力设施对应一个类，电力设施的技术参数及其操作对应相应类的属性和方法，电力设施图是由线段、圆、曲线、折线、多边形等基本图形组成，这些基本图形分别对应一个类，这些类又继承一个最基本的类。系统图编辑部分的工作量也就是这些类的实现，工作票、操作票签发部分用到了编辑平台的系统图，因此由大量的功能可以复用，这部分的功能划分同系统图编辑部分一样也是采用类作为基本结构，这样就比较准确的进行工作量的估算。
同时，我们开发的这个系统是基于C/S结构的，由于C/S结构的系统我们公司有不少成功的案例，因此有不少的项目供我们参考。对于本系统的第二部分，我们就是借鉴以前做过的基于C/S结构的系统，基于C/S结构的系统框架基本上是一致的，数据库的设计、前台操作（例如，对数据库进行添加、删除、修改、查询等一系列活动）大体相同。正因如此，有大量的东西可供我们复用，如权限控制模块我们就是复用以前的案例，仅作少量修改，在工作量的估算上也有很好的借鉴作用。这对工作量的估算也是一个重要的参考，为工作进度安排提供了依据。
在技术上，我们重点考虑本系统与其他C/S结构的系统的不同之处，相同或相似之处。我们认为没有技术难点。系统编辑平台主要是绘图，我们知道MFC的绘图功能确实强大，但是过于繁琐，功能封装不是十分完美，于是，我们采用了Form++这个MFC扩展类库，该类库对图形操作封装得很好，大大降低了系统图编辑部分的难度，在界面设计上我们采用了BCG这个扩展类库，使得VC应用程序界面设计得如同Delphi等工具一样完美。同时减少了工作量，在工作安排上，对于技术难度相对大一点的部分，我们安排经验丰富的程序员，同时也与其他工作组的成员商讨技术细节问题，与他们进行技术探讨。这样不至于因为某一技术细节而影响整个工程进度。
根据上述分析，我们制定一个详细的进度表并定义了相应的里程碑。2.识别关键任务系统图编辑部分是整个系统的基础，因为工作票、操作票签发部分是建立在该部分的基础之上，系统图编辑部分直接影响到整个项目。因此该部分是整个系统的关键部分，在这部分中每种电力设施所对应的类及其父类的定义是关键，因为所定义的类必须完整、准确地反映该电力设施的技术参数和操作。
工作票、操作票签发部分是用户明确提出的要求实现的功能，直接面对用户，这部分的成功与否直接影响到该系统的质量，因此也是不容忽视的。
如果上述两部分任务的进度受到影响，则整个项目的完成将受到威胁。因此是本项目的关键任务。在进度控制时我们将其作为重点对象进行控制。3.随时了解项目进度，必要时调整进度表
在确定项目开发计划时，我们制定了详细的进度表。我们在确定每一项任务时都确定该任务的工作量、开始时间、持续时间、结束时间。同时让每个小组成员知道自己所承担任务的时间表，小组成员根据自己的任务制定自己的详细工作计划。
工作日志是了解每个小组成员工作情况的很好的方式，我们要求每个小组成员对自己的工作都要做工作曰志，对自己每天的工作做详细记录。每周对自己的工作进展做出结论，向项目组汇报。在做结论时，不得使用“差不多”、“大概”、“完成了90%”等模糊字眼，而是采用某任务“已经全部完成”、“90%的工作全部完成”或者“再过1天全部完成”等方式。每个小组成员对自己做出的结论负责，这样可以做到随时了解项目进度，为调整项目计划提供客观基础。
同时，我们在项目进度计划中根据项目设计和定义了相关的里程碑，在每个里程碑处，我们都采取小组会议形式对本阶段的工作进行确认和总结，对本阶段的进展情况做出结论，并决定是否调整下一阶段的进度计划。<br>在系统图编辑部分，我们认为各电力设施所对应的类（包括其父类）定义完成为一个里程碑，每个类是否具备了相对应的电力设施的技术参数及操作是该里程碑的标准，这些类（包括其父类）的实现完成又为一个里程碑，……，整个系统图编辑部分的完成也是一个里程碑。每个里程碑的标准在系统设计时已经定义好。4.结束语电力行业工作票、操作票系统目前已经开发完毕，运行状况良好，受到一致好评。在本系统开发的整个过程中采用了面向对象技术同传统技术相结合的原则，因为小组成员各有特长，面向对象技术不是每个小组成员都熟练掌握的，加之面向对象技术在我们公司还不是很成熟，必须有一个过渡，不能一下子转型，因此采用这种策略符合我们公司的现实情况。
由于项目进度管理得当，项目按期完成，我们小组赢得了公司的好评，其他小组也研究我们的管理方式。当然，项目管理方式多种多样，根据项目不同、人员不同，管理模式应做调整而不是一成不变。适合本项目的管理模式才是最好的模式，先进的管理方法在不同的项目组中取得的效果是不同的，这有待于我们去研究、探索、实践和总结。

正确答案：软件开发成本估算是一个十分容易被忽视但却又是十分重要的内容。其重要的原因是没有成本估算项目计划就会失去基础；容易被忽视的原因却是由于大部分软件开发组织未能够有效掌握它。 软件估算包括规模估算、工作量估算、进度估算和成本估算。整个估算的过程是：首先根据软件需求进行规模估算也就是估计软件的规模通常以代码行数、功能点数为单位；然后在估计的规模的基础上根据项目的特定因素(例如技术能力、使用的语言和平台、团队稳定性、项目复杂度等)、开发生产率经验数字来估算开发的工作量这通常以人天、人月、人年为单位；最后根据客户提出的进度需求进行进度估算根据人员及其他成本 (如设备、房租、差旅等)对总的开发成本进行估算。软件估算的基础是经验数字和经验模型。 从上面的描述中可以看出规模估算是软件开发成本估算的基础(数据来源)而工作量估算则是软件开发成本估算的关键(决定了开发成本)。 规模估算最常用的方法包括LOC(代码行)估算法和FP(功能点)估算法。LOC估算法主要根据历史项目记录以经验数据进行推测；FP估算法则通过一个较严谨的经验模型计算公式来进行估算。FP估算法是一种比较通行的软件规模估算方法。 工作量估算可以采用的模型、方法和技术就比较多了大致可以分为算法方法、类比法和自底向上法3种。 (1)算法方法估算是自顶向下的方式实现使用数学方式表达出估算所含的各种参数之间的关系如规模、工作量、进度、复杂度之间的关系。这个模型可以是静态的也可是动态的。最常见的算法方法估算模型包括MarkⅡ估算、COCOM0 81、COCOMOII、 COCOMO组、Putnam估算模型等。 ①MarkⅡFP估算：它不是一个严格的算法模型是基于各种因素和它们的影响的主观评价之间关系的一些理解。 ②COCOMO：它是根据软件产品规模和几个特征计算工作量和日历时间的估算算法模型。它是由Barry Boehm博士开发的发布于1981年即COCOMO 81而 COCOMOII则是其新版本不过由于它们各有特色因此还共同存在于估算实践中。这是一个较严格并经受了大量实践考验的一个经典估算模型。 ③COCOMO组：包括重点应用于COTS组件项目的COCOTS模型；用来预测每 KLOC或FP中残留错误的COQUALMO模型；着重于开发软件的成本在开发活动上的分布的COSSEMO模型；着重在预测新技术、提高生产率的发明方面最有效的成本分配的COPROMO模型。 ④Putnam估算模型：它是一个工作量动态的、多变量的估算模型它对交付时间十分敏感。 ⑤静态模型：除了以上动态模型之外还有一些常用的静态模型其中最常用的是 Watson和Felix模型。其计算公式是不变的：工作量；5.2×(KLCC)0.91持续时间(月)： 4.1×(KLOC)0.36。可以用来生成较粗略的估算值。 算法方法估算法虽然定义严谨但是由于这些算法只是源于几十个项目的数据总结因此其结果并不是精确的但其仍然还是具有较高的参考价值。并且随着开发团队数据的积累和经验的堆积产生的估算也会越来越精确。 (2)类比估算法则是自顶向下的查看系统它借助经验丰富的人员的“本能感受”去识别待估项目和已完成的项目之间的相似与差异之处并评估这些差别对评估的影响。这种方法的主观意识较强估算结果的精确度与估算人员的经验有很大的关系。 (3)自底向上估算是将项目分解成为较小的活动和任务对每个较低层的任务做估算然后将所有的较低层的任务估算值加在一起就可以得到项目总的工作量估算值由于这种估算通常是由程序员来进行小任务块的估算因此容易让程序员产生责任感进度更有保障。 有了工作量估算后就可以计算出工作人员成本但在进行开发成本估算时还应该考虑硬件、软件、通信、差旅、培训以及其他成本。 可以从上面的描述中总结出撰写关于软件开发成本估算的论文主要应该注意以下几个方面的要点： (1)由于许多软件开发成本估算模型都需要一些参数依据因此应该对于项目的复杂度、涉及的关键技术、团队情况等因素进行阐述以便能够连贯地说明估算的过程。 (2)由于工作量估算是成本估算的关键其估算的结果决定了成本估算而成本估算则是在工作量的基础上做一些简单的财务计算因此可以理解为工作量估算的方法和模型。 (3)文章中应该列举算法方法估算法、类比估算法以及自底向上估算法3种模型并且应该抓住它们各自鲜明特点进行深入的阐述。 (4)在前面描述的基础上针对本项目的特色进行分析引出最合适的模型然后再结合实例详细地说明应用的具体方案。编写时一定要注意突出其真实性。 (5)文章应该花一定篇幅来说明估算的效果也就是估算的误差值是多少并且可以简要地分析这些误差值会来源于何处。
软件开发成本估算是一个十分容易被忽视，但却又是十分重要的内容。其重要的原因是没有成本估算，项目计划就会失去基础；容易被忽视的原因却是由于大部分软件开发组织未能够有效掌握它。 软件估算包括规模估算、工作量估算、进度估算和成本估算。整个估算的过程是：首先根据软件需求进行规模估算，也就是估计软件的规模，通常以代码行数、功能点数为单位；然后在估计的规模的基础上，根据项目的特定因素(例如，技术能力、使用的语言和平台、团队稳定性、项目复杂度等)、开发生产率经验数字来估算开发的工作量，这通常以人天、人月、人年为单位；最后根据客户提出的进度需求进行进度估算，根据人员及其他成本 (如设备、房租、差旅等)对总的开发成本进行估算。软件估算的基础是经验数字和经验模型。 从上面的描述中，可以看出规模估算是软件开发成本估算的基础(数据来源)，而工作量估算则是软件开发成本估算的关键(决定了开发成本)。 规模估算最常用的方法包括LOC(代码行)估算法和FP(功能点)估算法。LOC估算法主要根据历史项目记录，以经验数据进行推测；FP估算法则通过一个较严谨的经验模型计算公式来进行估算。FP估算法是一种比较通行的软件规模估算方法。 工作量估算可以采用的模型、方法和技术就比较多了，大致可以分为算法方法、类比法和自底向上法3种。 (1)算法方法估算是自顶向下的方式实现，使用数学方式表达出估算所含的各种参数之间的关系，如规模、工作量、进度、复杂度之间的关系。这个模型可以是静态的，也可是动态的。最常见的算法方法估算模型包括MarkⅡ估算、COCOM0 81、COCOMOII、 COCOMO组、Putnam估算模型等。 ①MarkⅡFP估算：它不是一个严格的算法模型，是基于各种因素和它们的影响的主观评价之间关系的一些理解。 ②COCOMO：它是根据软件产品规模和几个特征计算工作量和日历时间的估算算法模型。它是由Barry Boehm博士开发的，发布于1981年，即COCOMO 81，而 COCOMOII则是其新版本，不过由于它们各有特色，因此还共同存在于估算实践中。这是一个较严格，并经受了大量实践考验的一个经典估算模型。 ③COCOMO组：包括重点应用于COTS组件项目的COCOTS模型；用来预测每 KLOC或FP中残留错误的COQUALMO模型；着重于开发软件的成本在开发活动上的分布的COSSEMO模型；着重在预测新技术、提高生产率的发明方面最有效的成本分配的COPROMO模型。 ④Putnam估算模型：它是一个工作量动态的、多变量的估算模型，它对交付时间十分敏感。 ⑤静态模型：除了以上动态模型之外，还有一些常用的静态模型，其中最常用的是 Watson和Felix模型。其计算公式是不变的：工作量；5.2×(KLCC)0.91持续时间(月)： 4.1×(KLOC)0.36。可以用来生成较粗略的估算值。 算法方法估算法虽然定义严谨，但是由于这些算法只是源于几十个项目的数据总结，因此其结果并不是精确的，但其仍然还是具有较高的参考价值。并且随着开发团队数据的积累和经验的堆积，产生的估算也会越来越精确。 (2)类比估算法则是自顶向下的查看系统，它借助经验丰富的人员的“本能感受”去识别待估项目和已完成的项目之间的相似与差异之处，并评估这些差别对评估的影响。这种方法的主观意识较强，估算结果的精确度与估算人员的经验有很大的关系。 (3)自底向上估算是将项目分解成为较小的活动和任务，对每个较低层的任务做估算，然后将所有的较低层的任务估算值加在一起，就可以得到项目总的工作量估算值，由于这种估算通常是由程序员来进行小任务块的估算，因此容易让程序员产生责任感，进度更有保障。 有了工作量估算后，就可以计算出工作人员成本，但在进行开发成本估算时还应该考虑硬件、软件、通信、差旅、培训以及其他成本。 可以从上面的描述中总结出撰写关于软件开发成本估算的论文，主要应该注意以下几个方面的要点： (1)由于许多软件开发成本估算模型都需要一些参数依据，因此应该对于项目的复杂度、涉及的关键技术、团队情况等因素进行阐述，以便能够连贯地说明估算的过程。 (2)由于工作量估算是成本估算的关键，其估算的结果决定了成本估算，而成本估算则是在工作量的基础上做一些简单的财务计算，因此可以理解为工作量估算的方法和模型。 (3)文章中应该列举算法方法估算法、类比估算法以及自底向上估算法3种模型，并且应该抓住它们各自鲜明特点进行深入的阐述。 (4)在前面描述的基础上，针对本项目的特色进行分析，引出最合适的模型，然后再结合实例，详细地说明应用的具体方案。编写时一定要注意突出其真实性。 (5)文章应该花一定篇幅来说明估算的效果，也就是估算的误差值是多少，并且可以简要地分析这些误差值会来源于何处。

正确答案：C

正确答案：

正确答案：A

参考答案：B

正确答案：1、用400-600字叙述作者参与开发与管理的软件项目，包括但不仅限于，项目时间，规模，周期，背景，系统的主要功能，所采用的相关技术等。
2、开发模型多种多样，常见的包括：
瀑布模型：严格遵循软件生命周期各阶段的固定顺序，一个阶段完成再进入另一个阶段。其优点是可以使过程比较规范化，有利于评审；缺点在于过于理想，缺乏灵活性，容易产生需求偏差。
快速原型模型：对于许多需求不够明确的项目，比较适合采用该模型。它采用了一种动态定义需求的方法，通过快速地建立一个能够反映用户主要需求的软件原型，让用户在计算机上使用它，了解其概要，再根据反馈的结果进行修改，因此能够充分体现用户的参与和决策。
演化模型：也是一种原型化开发，但与快速原型不同的是，快速原型模型在获得真实需求时，就将抛弃原型。而演化模型则不然，它将从初始的模型中逐渐演化为最终软件产品，是一种“渐进式”原型法。
增量模型：它采用的是一种“递增式”模型，它将软件产品划分成为一系列的增量构件，分别进行设计、编码、集成和测试。
螺旋模型：结合了瀑布模型和演化模型的优点，最主要的特点在于加入了风险分析。它是由制定计划、风险分析、实施工程、客户评估这一循环组成的，它最初从概念项目开始第一个螺旋。
喷泉模型：主要用于描述面向对象的开发过程，最核心的特点是迭代。所有的开发活动没有明显的边界，允许各种开发活动交叉进行。
统一过程（UP）：统一过程是一个通用过程框架，可以用于种类广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。UP是基于构件的，在为软件系统建模时，UP使用的是UML。与其他软件过程相比，UP具有三个显著的特点，即用例驱动、以架构为中心、迭代和增量。
敏捷方法：敏捷方法是一种以人为核心、迭代、循序渐进的开发方法。在敏捷方法中，软件项目的构建被切分成多个子项目，各个子项目成果都经过测试，具备集成和可运行的特征。在敏捷方法中，从开发者的角度来看，主要的关注点有短平快的会议、小版本发布、较少的文档、合作为重、 客户直接参与、自动化测试、适应性计划调整和结对编程；从管理者的角度来看，主要的关注点有测试驱动开发、持续集成和重构。
3、结合项目实践说明作者在项目中所采用的开发模型，并阐述实施效果。

正确答案：A