问答题论文：论软件三层结构的设计 目前，三层结构或多层结构已经成为软件开发的主流，采用三层结构有很多好处，例如，能有效降低建设和维护成本，简化管理，适应大规模和复杂的应用需求，可适应不断的变化和新的业务需求等。在三层结构的开发中，中间件的设计占重要地位。 请围绕“软件三层结构的设计”论题，依次对以下3个方面进行论述。 （1）概要叙述你参与分析和开发的软件项目以及你所担任的主要工作。 （2）具体讨论你是如何设计三层结构的，详细描述其设计过程，遇到过的问题以及解决的办法。 （3）分析你采用三层结构所带来的效果

我所在的单位是国内主要的商业银行之一，作为单位的主要技术骨干，2010年1月，我主持了远期结售汇系统的开发，该系统是我行综合业务系统XX2010的一个子系统，由于银行系统对安全性、可靠性、可用性和响应速度要求很高，我选择了三层C/S结构作为该系统的软件架构，在详细地设计三层结构的过程中，我采用了字符终端为表示层，CICSTRANSATIONSERVER为中间层，DB2UDB8.2为数据库层，并采用了CICSSWITCH组并行批量的办法来解决设计中遇到的问题，保证了远期结售汇系统按计划完成并顺利投产，我设计的软件三层结构得到了同事和领导的一致认同和称赞。但是，我也看到在三层结构设计中存在一些不足之处，例如，中间层的负载均衡算法过于简单，容易造成系统负荷不均衡，并行批量设计不够严谨，容易造成资源冲突等。
正文：
我所在的单位是国内主要的商业银行之一。众所周知，银行的业务存在一个“二八定理”：即银行的百分之八十的利润是由百分之二十的客户所创造。为了更好地服务大客户，适应我国对外贸易的蓬勃发展态势，促进我国对外贸易的发展，2010年1月，我行开展了远期结售汇业务。
所谓的远期结售汇就是企业在取得中国外汇管理局的批准后，根据对外贸易的合同等凭证与银行制定合约，银行根据制定合约当天的外汇汇率，通过远期汇率公式，计算出交割当天的外汇汇率，并在那天以该汇率进行成交的外汇买卖业务。远期结售汇系统是我行综合业务系统XX2010的一个子系统，它主要包括了联机部分、批量部分、清算部分和通兑部分，具有协议管理、合约管理、报价管理、外汇敞口管理、账务管理、数据拆分管理、报表管理、业务缩微和事后监督等功能。
我作为单位的主要技术骨干之一，主持并参与了远期结售汇系统的项目计划，需求分析、设计、编码和测试阶段的工作。由于银行系统对安全性，可靠性，可用性和响应速度要求很高，我选择了三层C/S结构作为该系统的软件架构，下面，我将分层次详细介绍三层C/S软件架构的设计过程。
（1）表示层为字符终端。我行以前一直使用IBM的VisualGen2.0附带的图形用户终端来开发终端程序，但在使用的过程中，分行的业务人员反映响应速度比较漫，特别是业务量比较大的时候，速度更是难以忍受。为此，我行最近自行开发了一套字符终端CITE，它采用VisualBasic作为开发语言，具有响应速度快、交互能力强、易学、编码快和功能强大的特点，在权衡了两者的优点和缺点之后，我决定选择字符终端CITE作为表示层。
（2）中间层为CICSTransationServer（CTS）。首先，我行与IBM公司一直保持着良好的合作关系，而我行的大部分技术和设备都采用了IBM公司的产品，其中包括大型机，由于CICS在IBM的大型机上得到了广泛的应用，并在我行取得了很大的成功，为了保证与原来系统的兼容和互用性，我采用了IBM的CTS作为中间层，连接表示层和数据库层，简化系统的设计，使开发人员可以专注于表示逻辑和业务逻辑的开发工作，缩短了开发周期，减少开发费用和维护费用，提高了开发的成功率；其次，对于中间层的业务逻辑，我采用了我行一直使用的VisualAgeforJava作为开发平台，它具有简单易用的特点，特别适合开发业务逻辑，可以使开发人员快速而准确地开发出业务逻辑，确保了远期结售汇系统的顺利完成；最后，由于采用了CTS，确保了系统的开放性和互操作性，保证了与我行原来的联机系统和其他系统的兼容，保护了我行的原有投资。
（3）数据层为DB2UDB8.2由于DB2在大型事务处理系统中表现出色，我行一直使用DB2作为事务处理的数据库，并取得了很大的成功，在DB2数据库的使用方面积累了自己独到的经验和大量的人才，为了延续技术的连续性和保护原有投资，我选择了DB2UDB8.2作为数据层。
但是，在设计的过程中也遇到了一些困难，我们主要采取了以下的办法来解决：
（1）CICSSwitch组。众所周知，银行系统对于安全性，可靠性，可用性和响应速度要求很高，特别是我行最近进行了数据集中，全国只设两个数据中心，分别在XX和YY两个地方，这样对以上的要求就更高了，为了保障我行的安全生产，我采用了CTSSwitch组技术。为了简化系统的设计和缩短通信时间，我采用了简单的负载均衡算法，例如这次分配给N个CTS，下次则分配给第N+1个CTS，当到了最后一个，就从第一个开始；为了更好地实现容错，我采用了当第N个CTS失效的时候，把它正在处理的业务转到N+1个上面继续处理，这样大大增加了系统的可用性，可以为客户提供更好的服务；此外，我还采用了数据库连接池的技术，大大缩短了数据库处理速度，提高了系统运行速度。
（2）并行批量。银行系统每天都要处理大量的数据，为了确保白天的业务能顺利进行，有一部分的账务处理，例如一部分内部户账务处理，或者代理收费业务和总账与分户账核对等功能就要到晚上批量地去处理，但是，这部分数据在数据集中之后就显得更加庞大，我行以前采用串行提交批量作业的办法，远远不能适应数据中心亿万级的数据处理要求，在与其他技术骨干讨论之后，并经过充分的论证和试验，我决定采用了并行批量的技术，所谓的并行批量，就是在利用IBM的OPC（TivoliOperations，PlanningandControl）技术，把批量作业按时间和业务处理先后顺序由操作员统一提交的基础上，再利用DB2的Partition技术，把几个地区分到一个Partiton里面分别处理，大大提高了银行系统的数据处理速度，确保了远期结售汇系统三层结构的先进性。在并行批量的设计过程中，我考虑到批量作业有可能因为网络错误或者资源冲突等原因而中断，这样在编写批量程序和作业的时候必须支持断点重提，以确保生产的顺利进行。
由于软件三层结构设计得当，并采取了有效的措施去解决设计中遇到的问题，远期结售汇系统最后按照计划完成并顺利投产，不但保证了系统的开放性、可用性和互用性，取得了良好的社会效益和经济效益，而且我的软件三层结构设计得到了同事和领导的一致认同与称赞，为我行以后系统的开发打下了良好的基础。
在总结经验的同时，我也看到了我在软件三层结构设计中的不足之处。
首先，负载算法过于简单，容易造成系统的负荷不均衡：由于每个业务的处理时间不一样，有的可能差距很远，简单的顺序加一负载分配算法就容易造成负载不均衡，但是如果专门设置一个分配器，则增加了一次网络通信，使得系统的速度变慢，这样对响应速度要求很高的银行系统来说也是不可行的，于是我决定采用基于统计的分配算法，即在收到请求的时候，根据预先设定的权值，按概率直接分配给CTS。
其次，由于批量作业顺序设计得不过够严谨等各种原因，容易造成资源冲突：在远期结售汇系统运行了一段时间之后，数据中心的维护人员发现，系统有的时候会出现资源冲突现象。在经过仔细的分析之后，我发现，由于每天各个业务的业务量大小不一样，顺序的两个作业之间访问同一个表的时候便会产生资源冲突，另外，在OPC作业运行的过程中，操作员提交的其他作业与这个时间的OPC作业产生也有可能产生资源冲突。对于第一种情况，可以在不影响业务的情况下调整作业顺序或者对于查询作业运用DB2的共享锁的技术，而第二种情况则要制定规范，规定在某时间断内不允许提交某些作业来解决。为了更好地开展系统分析工作，我将在以后的工作实践中不断地学习，提高自身素质和能力，为我国的软件事业贡献自己的微薄力量。

正确答案：略
　　解答要点
　　（1）首先用400-500字的篇幅简要叙述作者参与分析和开发的信息系统项目的概要和所担任的工作。
　　（2）具体叙述你在参与开发的软件中选用软件开发模型的原则。例如适应需求的变化、灵活性等。
　　（3）具体是如何使用所选择的开发模型的，即根据选择模型进行开发的过程是怎样的。
　　（4）简要叙述软件开发模型的近期演变趋势与主要特征，你准备如何去适应这类演变。

正确答案：[写作要点] 一、简要介绍你所参与分析设计的多层分布式结构系统(说明该系统采用的是C/A/S还是B/A/S)以及你在系统中担任的主要工作。 二、说明多层分布式结构分类的依据。 从概念上说任何信息系统应用都可以映射到以下5层： .表现层 是实际的用户界面； .表现逻辑层 为了生成表现层而必须进行的处理； .应用逻辑层 包括支持实际业务应用和规则所需的所有逻辑和处理； .数据处理层 包括用来存储和访问往来于数据库的数据所需的所有命令和逻辑； .数据层：数据库中实际存储的数据。 C/A/S 结构是将数据层和数据处理层放置在各自的服务器上应用逻辑层放置在各自的服务器上表现逻辑层和表现层放置在客户端上这也称为三层或多层客户/服务器计算。 在B/A/S 结构中表现层和表现逻辑层在客户端Web 浏览器中使用从某个Web 服务器下载的内容实现表现逻辑层连接到运行在应用服务器上的应用逻辑层应用逻辑层最终连接到后台的数据库服务器。 三、多层分布式结构系统的主要特点。 .安全性：中间层隔离了客户对数据服务器的访问保护了数据库的安全。 .稳定性。 .易维护性：由于业务逻辑位于单独的一层当业务规则发生变化后客户端程序基本不作改动。 .快速响应：通过负载均衡以及中间层缓存数据能力可以提高对客户端的响应速度。 .系统扩展灵活：基于多层分布式结构当业务增大时可以在中间层部署更多的应用服务器提高对客户端的响应而所有变化对客户端透明。 四、多层分布式结构系统的开发主要考虑三方面的技术。 .开发环境：开发人员需要厂种创建新组件、并将已有组件加以集成的开发环境。 .应用程序的集成。 .应用程序的配置：分布式结构的开发需要配置平台的支持以便在用户剧增时能有效地扩展并保持系统的稳定。 .选择合适的中间件。
[写作要点] 一、简要介绍你所参与分析设计的多层分布式结构系统(说明该系统采用的是C/A/S还是B/A/S)以及你在系统中担任的主要工作。 二、说明多层分布式结构分类的依据。 从概念上说，任何信息系统应用都可以映射到以下5层： .表现层 是实际的用户界面； .表现逻辑层 为了生成表现层而必须进行的处理； .应用逻辑层 包括支持实际业务应用和规则所需的所有逻辑和处理； .数据处理层 包括用来存储和访问往来于数据库的数据所需的所有命令和逻辑； .数据层：数据库中实际存储的数据。 C/A/S 结构是将数据层和数据处理层放置在各自的服务器上，应用逻辑层放置在各自的服务器上，表现逻辑层和表现层放置在客户端上，这也称为三层或多层客户/服务器计算。 在B/A/S 结构中，表现层和表现逻辑层在客户端Web 浏览器中使用从某个Web 服务器下载的内容实现，表现逻辑层连接到运行在应用服务器上的应用逻辑层，应用逻辑层最终连接到后台的数据库服务器。 三、多层分布式结构系统的主要特点。 .安全性：中间层隔离了客户对数据服务器的访问，保护了数据库的安全。 .稳定性。 .易维护性：由于业务逻辑位于单独的一层，当业务规则发生变化后，客户端程序基本不作改动。 .快速响应：通过负载均衡以及中间层缓存数据能力，可以提高对客户端的响应速度。 .系统扩展灵活：基于多层分布式结构，当业务增大时，可以在中间层部署更多的应用服务器，提高对客户端的响应，而所有变化对客户端透明。 四、多层分布式结构系统的开发主要考虑三方面的技术。 .开发环境：开发人员需要厂种创建新组件、并将已有组件加以集成的开发环境。 .应用程序的集成。 .应用程序的配置：分布式结构的开发需要配置平台的支持，以便在用户剧增时能有效地扩展，并保持系统的稳定。 .选择合适的中间件。

正确答案：第一部分 简要叙述所参与管理和开发的软件项目并明确指出在其中承担的主要任务和开展的主要工作。 第二部分 SAAM的分析和评估目的、评估参与者、评估活动或过程以及评估结果说明。 1．评估目的 SAAM(Scenario-based Architecture Analysis Method)目的是验证基本的体系结构假设和原则评估体系结构固有的风险。SAAM指导对体系结构的检查使其主要关注潜在的问题点如需求冲突。SAAM不仅能够评估体系结构对于特定系统需求的使用能力也能被用来比较不同的体系结构。 2．评估参与者 风险承担者、记录人员、软件体系结构设计师。 3．评估活动或过程 SAAM分析评估体系结构的过程包括6个步骤即形成场景、描述体系结构、场景的分类和优先级确定、间接场景的单个评估、场景相互作用的评估、总体评估如下图所示。 (1)形成场景 形成场景是通过集中讨论来实现。使风险承担者在一个友好的氛围中提出一些场景这些场景反映了他们的需求也体现了他们对体系结构将如何实现需求的认识。 (2)描述体系结构 体系结构设计师应该采用参加评估的所有人员都能够充分理解的形式对待评估的体系结构进行适当的描述。这种描述说明系统中的运算和数据构件以及他们之间的联系。除了要描述这些静态特性以外还要对系统在某段时间内的动态特征做出说明。 (3)场景的分类和优先级确定 场景分为直接场景和间接场景(或潜在场景)。直接场景是按照现有体系结构开发出来的系统能够直接实现的场景。与在设计时已经考虑过的需求相对应的直接场景能增进对体系结构的理解促进对诸如性能和可靠性等其他质量属性的研究。 间接场景就是需要对现有体系结构做某些修改才能支持的场景。间接场景对衡量体系结构对系统在演化过程中将出现的变更的适用情况十分关键。通过各种间接场景对体系结构的影响可以确定体系结构在相关系统的生命周期内对不断演化的使用的适应情况。直接场景类似于用例而间接场景有时也叫变更案例。 评估人员通过对场景设置优先级可以保证在评估的有限时间内考虑最重要的场景。这里的“重要”完全是由风险承担者及其所关心的问题确定的。风险承担者通过投票表达所关心的问题。 (4)对间接场景的单个评估 对于直接场景而言体系结构设计师要讲清所评估的体系结构将如何执行这些场景；对于间接场景而言应说明需要对体系结构做哪些修改才能适应间接场景的要求。 对每一个间接场景列出为支持该场景而需要对体系结构所做的改动并估计出这些变更的代价。对体系结构的更改意味着引入某个新构件或新联系或者需要对已有构件或联系的描述进行修改。 (5)评估场景的相互作用 场景的相互作用暴露了设计方案中的功能分配。场景相互作用的多少与结构复杂性、耦合度、内聚性有关。同时场景的相互作用能够暴露出体系结构设计文档未能充分说明的结构分解。 (6)形成总体评估 总体的权衡和评价反映该组织对表现在不同场景中的目标考虑优先级。根据对系统成功的相对重要性来为每个场景设置一个权值。 如果要比较多个体系结构或者针对同一体系结构提出多个不同的方案则可通过对权值的确定来得出总体评价。权值的设置具有很强的主观性所以应该让所有风险承担者共同参与但也应合理组织要允许对权值及其基本思想进行公开讨论。 4．评估结果 SAAM评估的主要有形输出包括以下内容： (1)把代表了未来可能做的更改的场景与构架对应起来显现出构架中未来可能会表现出较高复杂性的地方并对每个这样的更改的预期工作量做出评估。 (2)理解系统的功能对多个构架所支持的功能和数量进行比较。 如果所评估的是一个框架SAAM评估将指明框架中未能满足其修改性需求的地方有时还会指出一种效果更好的设计。SAAM评估也能对两个或者三个备选构架进行比较明确其中那一个能够较好地满足质量属性需求而且做的更改较少、不会在未来导致太多的复杂的问题。 ATAM的分析和评估目的、评估参与者、评估活动或过程以及评估结果说明如下。 (1)评估目的 ATAM(Architecture Tradeoff Analysis Method构架权衡分析方法)的评估目的是依据系统质量属性和商业需求评估设计决策的结果。ATAM希望揭示出构架满足特定质量目标的情况使我们更清楚地认识到质量目标之间的联系即如何权衡多个质量目标。 (2)评估参与者 ①评估小组。该小组是所评估构架项目外部的小组通常由3～5人组成。该小组的每个成员都要扮演大量的特定角色。他们可能是开发组织内部的也可能是外部的。 ②项目决策者对开发项目具有发言权并有权要求进行某些改变他们包括项目管理人员重要的客户代表构架设计师等。 ③构架涉众(stakeholders)。包括关键模块开发人员、测试人员、用户等。 (3)评估活动或过程 整个ATAM评估过程包括9个步骤按其编号顺序分别是描述ATAM方法、描述商业动机、描述体系结构、确定体系结构方法、生成质量属性效用树、分析体系结构方法、讨论和分级场景、描述评估结果如下图所示。 ①描述介绍ATAM方法。 评估小组负责人向参加会议的风险承担者介绍ATAM评估方法。在这一步中要解释每个人将要参与的过程并预留解答疑问的时间设置好其他活动的环境和预期结果。关键是要使每个人都知道要收集哪些信息如何描述这些信息将要向谁报告等。 ②描述商业动机。 项目决策者从商业的角度介绍系统的概况。该描述应该包括：系统最重要的功能；技术、管理、经济和政治方面的任何相关限制；与该项目相关的商业目标和上下文；主要的风险承担者；架构的驱动因素。 ③描述体系结构。 首席设计师或设计小组要对体系结构进行详略适当的介绍。在体系结构描述中至少应该包括：技术约束(例如操作系统、硬件、中间件等)；要与本系统交互的其他系统；用以满足质量属性要求的体系结构方法。 ④确定体系结构方法。 ATAM评估方法主要通过理解体系结构方法来分析体系结构在这一步由设计师确定体系结构方法由分析小组捕获但不进行分析。 ⑤生成质量属性效用树。 在这一步中评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标并对这些质量属性目标设置优先级和细化。即使是体系结构级的分析也不一定是全局的所以评估人员需要集中所有相关人员的精力注意体系结构的各个方面这通常是通过构建效用树的方式来实现的。 效用树的输出结果是对具体质量属性需求的优先级的确定这种优先级列表为 ATAM评估方法的后面几步提供了指导它告诉了评估小组应该把有限的时间花在哪里特别是应该到哪里去考察体系结构的方法与相应的风险、敏感点和权衡点。 ⑥分析体系结构方法。 一旦有了效用树的结果评估小组可以对实现重要质量属性的体系结构方法进行考察。这是通过文档化这些体系结构决策和确定它们的风险、敏感点和权衡点等来实现的。 在这一步中评估小组要对每一种体系结构方法都考察足够的信息完成与该方法有关的质量属性的初步分析。这一步的主要结果是一个体系结构方法或风格的列表与之相关的一些问题以及设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。 在这一步结束时评估小组应该对整个体系结构的绝大多数重要方面所做出的关键设计决策、风险列表、敏感点、权衡点有一个清楚的认识。 ⑦讨论和分级场景。 场景在驱动ATAM测试阶段起主导作用。风险承担者进行两项相关的活动：集体讨论用例场景和改变场景。用例场景是场景的一种在用例场景中风险承担者是一个终端用户使用系统执行的一些功能。 一旦收集了若干个场景后必须设置优先级。评估人员通过投票表决的方式来完成每个风险承担者分配相当于总场景数的30%的选择且此数值只入不舍。例如如果共有17今场景则每个风险承担者将拿到6张选票这6张选票的具体使用则取决于风险承担者他可以把这6张票全部投给一个场景或者每个场景2～3张票还可以一个场景一张票等。 ⑧分析体系结构方法。 在收集并分析了场景之后设计师就可把最高级别的场景映射到所描述的体系结构中并对相关的体系结构如何有助于该场景的实现做出解释。 ⑨描述评估结果。 最后要把ATAM分析中所得到的各种信息进行归纳并反馈给风险承担者。这种描述一般要采用幻灯片的形式但也可以在ATAM评估结束以后提交更完整的书面报告。在描述过程中评估负责人要介绍ATAM评估的各个步骤以及各个步骤中得到的各种信息包括商业环境、驱动需求、约束条件和体系结构等。 (4)评估结果 ATAM的评估结果包括以下内容： ①一个简洁的构架表述。 ②表述清楚的业务目标。 ③用场景集合捕获的质量属性。 ④所确定的敏感点和权衡点的集合。例如备份数据库对可靠性质量属性来讲是敏感点性质的设计决策但对性能和可靠性两个质量属性而言它是权衡点性质的设计决策。 ⑤有风险决策和无风险决策。 ⑥风险主题的集合包括： .敏感点(sensitivity points)——与某个质量属性相关的构架决策。 .权衡点(tradeoff points)——与多个质量属性相关的构架决策。 .有风险决策(risk set)——根据所陈述的质量属性需求可能导致不期望结果的构架决策。 .无风险决策(nonrisk set)——根据分析被认为是安全的构架决策。 第三部分 结合你参与的实际工作和项目的实际情况具体阐述你在进行体系结构设计和评估时采用的评估方法和具体实施的过程和步骤并对最终实际效果进行说明。 如果在实际项目实施的时候能利用ATAM方法进行软件体系结构评估并利用 CBAM方法作为ATAM的补充对软件体系结构成本效益等经济性进行评估则更完善。
第一部分 简要叙述所参与管理和开发的软件项目，并明确指出在其中承担的主要任务和开展的主要工作。 第二部分 SAAM的分析和评估目的、评估参与者、评估活动或过程以及评估结果说明。 1．评估目的 SAAM(Scenario-based Architecture Analysis Method)目的是验证基本的体系结构假设和原则，评估体系结构固有的风险。SAAM指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突。SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。 2．评估参与者 风险承担者、记录人员、软件体系结构设计师。 3．评估活动或过程 SAAM分析评估体系结构的过程包括6个步骤，即形成场景、描述体系结构、场景的分类和优先级确定、间接场景的单个评估、场景相互作用的评估、总体评估，如下图所示。 (1)形成场景 形成场景是通过集中讨论来实现。使风险承担者在一个友好的氛围中提出一些场景，这些场景反映了他们的需求，也体现了他们对体系结构将如何实现需求的认识。 (2)描述体系结构 体系结构设计师应该采用参加评估的所有人员都能够充分理解的形式，对待评估的体系结构进行适当的描述。这种描述说明系统中的运算和数据构件，以及他们之间的联系。除了要描述这些静态特性以外，还要对系统在某段时间内的动态特征做出说明。 (3)场景的分类和优先级确定 场景分为直接场景和间接场景(或潜在场景)。直接场景是按照现有体系结构开发出来的系统能够直接实现的场景。与在设计时已经考虑过的需求相对应的直接场景能增进对体系结构的理解，促进对诸如性能和可靠性等其他质量属性的研究。 间接场景就是需要对现有体系结构做某些修改才能支持的场景。间接场景对衡量体系结构对系统在演化过程中将出现的变更的适用情况十分关键。通过各种间接场景对体系结构的影响，可以确定体系结构在相关系统的生命周期内对不断演化的使用的适应情况。直接场景类似于用例，而间接场景有时也叫变更案例。 评估人员通过对场景设置优先级，可以保证在评估的有限时间内考虑最重要的场景。这里的“重要”完全是由风险承担者及其所关心的问题确定的。风险承担者通过投票表达所关心的问题。 (4)对间接场景的单个评估 对于直接场景而言，体系结构设计师要讲清所评估的体系结构将如何执行这些场景；对于间接场景而言，应说明需要对体系结构做哪些修改才能适应间接场景的要求。 对每一个间接场景，列出为支持该场景而需要对体系结构所做的改动，并估计出这些变更的代价。对体系结构的更改意味着引入某个新构件或新联系，或者需要对已有构件或联系的描述进行修改。 (5)评估场景的相互作用 场景的相互作用暴露了设计方案中的功能分配。场景相互作用的多少与结构复杂性、耦合度、内聚性有关。同时，场景的相互作用能够暴露出体系结构设计文档未能充分说明的结构分解。 (6)形成总体评估 总体的权衡和评价，反映该组织对表现在不同场景中的目标考虑优先级。根据对系统成功的相对重要性来为每个场景设置一个权值。 如果要比较多个体系结构，或者针对同一体系结构提出多个不同的方案，则可通过对权值的确定来得出总体评价。权值的设置具有很强的主观性，所以，应该让所有风险承担者共同参与，但也应合理组织，要允许对权值及其基本思想进行公开讨论。 4．评估结果 SAAM评估的主要有形输出包括以下内容： (1)把代表了未来可能做的更改的场景与构架对应起来，显现出构架中未来可能会表现出较高复杂性的地方，并对每个这样的更改的预期工作量做出评估。 (2)理解系统的功能，对多个构架所支持的功能和数量进行比较。 如果所评估的是一个框架，SAAM评估将指明框架中未能满足其修改性需求的地方，有时还会指出一种效果更好的设计。SAAM评估也能对两个或者三个备选构架进行比较，明确其中那一个能够较好地满足质量属性需求，而且做的更改较少、不会在未来导致太多的复杂的问题。 ATAM的分析和评估目的、评估参与者、评估活动或过程以及评估结果说明如下。 (1)评估目的 ATAM(Architecture Tradeoff Analysis Method，构架权衡分析方法)的评估目的是依据系统质量属性和商业需求评估设计决策的结果。ATAM希望揭示出构架满足特定质量目标的情况，使我们更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。 (2)评估参与者 ①评估小组。该小组是所评估构架项目外部的小组，通常由3～5人组成。该小组的每个成员都要扮演大量的特定角色。他们可能是开发组织内部的，也可能是外部的。 ②项目决策者，对开发项目具有发言权，并有权要求进行某些改变，他们包括项目管理人员，重要的客户代表，构架设计师等。 ③构架涉众(stakeholders)。包括关键模块开发人员、测试人员、用户等。 (3)评估活动或过程 整个ATAM评估过程包括9个步骤，按其编号顺序分别是描述ATAM方法、描述商业动机、描述体系结构、确定体系结构方法、生成质量属性效用树、分析体系结构方法、讨论和分级场景、描述评估结果，如下图所示。 ①描述介绍ATAM方法。 评估小组负责人向参加会议的风险承担者介绍ATAM评估方法。在这一步中，要解释每个人将要参与的过程，并预留解答疑问的时间，设置好其他活动的环境和预期结果。关键是要使每个人都知道要收集哪些信息，如何描述这些信息，将要向谁报告等。 ②描述商业动机。 项目决策者从商业的角度介绍系统的概况。该描述应该包括：系统最重要的功能；技术、管理、经济和政治方面的任何相关限制；与该项目相关的商业目标和上下文；主要的风险承担者；架构的驱动因素。 ③描述体系结构。 首席设计师或设计小组要对体系结构进行详略适当的介绍。在体系结构描述中，至少应该包括：技术约束(例如，操作系统、硬件、中间件等)；要与本系统交互的其他系统；用以满足质量属性要求的体系结构方法。 ④确定体系结构方法。 ATAM评估方法主要通过理解体系结构方法来分析体系结构，在这一步，由设计师确定体系结构方法，由分析小组捕获，但不进行分析。 ⑤生成质量属性效用树。 在这一步中，评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些质量属性目标设置优先级和细化。即使是体系结构级的分析，也不一定是全局的，所以，评估人员需要集中所有相关人员的精力，注意体系结构的各个方面，这通常是通过构建效用树的方式来实现的。 效用树的输出结果是对具体质量属性需求的优先级的确定，这种优先级列表为 ATAM评估方法的后面几步提供了指导，它告诉了评估小组应该把有限的时间花在哪里，特别是应该到哪里去考察体系结构的方法与相应的风险、敏感点和权衡点。 ⑥分析体系结构方法。 一旦有了效用树的结果，评估小组可以对实现重要质量属性的体系结构方法进行考察。这是通过文档化这些体系结构决策和确定它们的风险、敏感点和权衡点等来实现的。 在这一步中，评估小组要对每一种体系结构方法都考察足够的信息，完成与该方法有关的质量属性的初步分析。这一步的主要结果是一个体系结构方法或风格的列表，与之相关的一些问题，以及设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。 在这一步结束时，评估小组应该对整个体系结构的绝大多数重要方面所做出的关键设计决策、风险列表、敏感点、权衡点有一个清楚的认识。 ⑦讨论和分级场景。 场景在驱动ATAM测试阶段起主导作用。风险承担者进行两项相关的活动：集体讨论用例场景和改变场景。用例场景是场景的一种，在用例场景中，风险承担者是一个终端用户，使用系统执行的一些功能。 一旦收集了若干个场景后，必须设置优先级。评估人员通过投票表决的方式来完成，每个风险承担者分配相当于总场景数的30%的选择，且此数值只入不舍。例如，如果共有17今场景，则每个风险承担者将拿到6张选票，这6张选票的具体使用则取决于风险承担者，他可以把这6张票全部投给一个场景，或者每个场景2～3张票，还可以一个场景一张票等。 ⑧分析体系结构方法。 在收集并分析了场景之后，设计师就可把最高级别的场景映射到所描述的体系结构中，并对相关的体系结构如何有助于该场景的实现做出解释。 ⑨描述评估结果。 最后要把ATAM分析中所得到的各种信息进行归纳，并反馈给风险承担者。这种描述一般要采用幻灯片的形式，但也可以在ATAM评估结束以后，提交更完整的书面报告。在描述过程中，评估负责人要介绍ATAM评估的各个步骤，以及各个步骤中得到的各种信息，包括商业环境、驱动需求、约束条件和体系结构等。 (4)评估结果 ATAM的评估结果包括以下内容： ①一个简洁的构架表述。 ②表述清楚的业务目标。 ③用场景集合捕获的质量属性。 ④所确定的敏感点和权衡点的集合。例如，备份数据库，对可靠性质量属性来讲，是敏感点性质的设计决策，但对性能和可靠性两个质量属性而言，它是权衡点性质的设计决策。 ⑤有风险决策和无风险决策。 ⑥风险主题的集合，包括： .敏感点(sensitivity points)——与某个质量属性相关的构架决策。 .权衡点(tradeoff points)——与多个质量属性相关的构架决策。 .有风险决策(risk set)——根据所陈述的质量属性需求，可能导致不期望结果的构架决策。 .无风险决策(nonrisk set)——根据分析被认为是安全的构架决策。 第三部分 结合你参与的实际工作和项目的实际情况，具体阐述你在进行体系结构设计和评估时采用的评估方法和具体实施的过程和步骤，并对最终实际效果进行说明。 如果在实际项目实施的时候，能利用ATAM方法进行软件体系结构评估，并利用 CBAM方法作为ATAM的补充对软件体系结构成本效益等经济性进行评估，则更完善。

正确答案：本题为模拟题原题，具体写作要求为：
一、首先用400-600字的篇幅简要叙述作者参与开发的软件系统的概要和所担任的工作。
二、设计模式的基本分类：
· 创建型模式。创建型模式抽象了实例化过程，它们帮助一个系统独立于创建、组合和表示它的那些对象。创建型模式包括工厂方法、抽象工厂、生成器、原型、单例模式等。
· 结构型模式。结构型模式涉及到如何组合类和对象以获得更大的结构。结构型模式包括适配器、桥接、组成、装饰、外观、享元、代理等。
· 行为模式。行为模式涉及到算法和对象间职责的分配。行为模式不仅描述对象或类的模式，还描述了它们之间的通信模式。常用的行为模式有观察者、策略等。
三、你在项目中运用了何种设计模式以及如何用此模式进行分析与设计。要紧密结合主题项目，选择1-2种设计模式进行讨论就可以了。

答案：

解析：

在本项目管理中，我主要采用了面向对象技术同传统技术相结合的原则，在估算项目的工作量这方面尤为突出，面向对象技术对传统技术有所改进，传统技术能弥补面向对象技术的不足。本文从合理的估算项目的工作量及技术难度、识别关键任务、随时了解项目进度，必要时调整进度表等方面，讨论了电力行业工作票、操作票系统项目管理的基本活动与方法，有效地控制开发进度，确保项目如期按质完成。本系统在电力系统已经运行，状况良好，受到一致好评。
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.结束语电力行业工作票、操作票系统目前已经开发完毕，运行状况良好，受到一致好评。在本系统开发的整个过程中采用了面向对象技术同传统技术相结合的原则，因为小组成员各有特长，面向对象技术不是每个小组成员都熟练掌握的，加之面向对象技术在我们公司还不是很成熟，必须有一个过渡，不能一下子转型，因此采用这种策略符合我们公司的现实情况。
由于项目进度管理得当，项目按期完成，我们小组赢得了公司的好评，其他小组也研究我们的管理方式。当然，项目管理方式多种多样，根据项目不同、人员不同，管理模式应做调整而不是一成不变。适合本项目的管理模式才是最好的模式，先进的管理方法在不同的项目组中取得的效果是不同的，这有待于我们去研究、探索、实践和总结。

正确答案：[写作要点] 1)结合自己参与分析和开发的应用项目或从事的实际工作说明设计模式对系统开发的作用。 2)能够较为详细地说明设计模式的基本分类能够结合项目实际工作说明在系统开发中所采用的设计模式以及选择这些设计模式的原因。 设计模式的核心在于提供了相关问题的解决方案。设计模式一般有四个要素：模式名称、问题、解决方案和效果。 设计模式的基本分类： (1)创建型模式。创建型模式抽象了实例化过程它们帮助一个系统独立于创建、组合和表示它的那些对象。创建型模式包括：Factory Method(工厂方法)、Abstract Factory (抽象工厂)、Builder(生成器)、Prototype(原型)、Singleton(单身模式)。 (2)结构型模式。结构型模式涉及到如何组合类和对象以获得更大的结构。包括： Adapter(适配器)、Bridge(桥接)、Composite(组成)、Decorator(装饰)、Facade(外观)、Flyweight(享元)、Proxy(代理)。 (3)行为模式。行为模式涉及到算法和对象间职责的分配。行为模式不仅描述对象或类的模式还描述了它们之间的通信模式。常用的行为模式有Observer(观察者) Strategy(策略)等。 3)结合项目实际工作举例说明在设计模式的使用效果能够针对设计模式对软件开发的影响展开分析与讨论。
[写作要点] 1)结合自己参与分析和开发的应用项目或从事的实际工作，说明设计模式对系统开发的作用。 2)能够较为详细地说明设计模式的基本分类，能够结合项目实际工作，说明在系统开发中所采用的设计模式，以及选择这些设计模式的原因。 设计模式的核心在于提供了相关问题的解决方案。设计模式一般有四个要素：模式名称、问题、解决方案和效果。 设计模式的基本分类： (1)创建型模式。创建型模式抽象了实例化过程，它们帮助一个系统独立于创建、组合和表示它的那些对象。创建型模式包括：Factory Method(工厂方法)、Abstract Factory (抽象工厂)、Builder(生成器)、Prototype(原型)、Singleton(单身模式)。 (2)结构型模式。结构型模式涉及到如何组合类和对象以获得更大的结构。包括： Adapter(适配器)、Bridge(桥接)、Composite(组成)、Decorator(装饰)、Facade(外观)、Flyweight(享元)、Proxy(代理)。 (3)行为模式。行为模式涉及到算法和对象间职责的分配。行为模式不仅描述对象或类的模式，还描述了它们之间的通信模式。常用的行为模式有Observer(观察者) Strategy(策略)等。 3)结合项目实际工作，举例说明在设计模式的使用效果，能够针对设计模式对软件开发的影响展开分析与讨论。

正确答案：1．需求管理需要“建立并维护在软件工程中同客户达成的契约”。这种契约都包含在编写的需求规格说明与模型中。客户的接受仅是需求成功的一半开发人员也必须能够接受他们并真正把需求应用到产品中。 2．在需求管理中所规划和建立的细节层次结构可通过需求跟踪表来反应。需要确定需求识别、变更管理过程、跟踪策略、CASE工具等内容。 3．通常的需求管理活动包括以下几个方面。 (1)定义需求基线(迅速制订需求文档的主体)。 (2)评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。 (3)以一种可控制的方式将需求变更融入到项目中。 (4)使当前的项目计划与需求一致。 (5)估计变更需求所产生的影响并在此基础上协商新的承诺(约定)。 (6)让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。 (7)在整个项目过程中跟踪需求状态及其变更情况。 一个需求变更管理过程包含问题分析和变更描述、变更分析和成本计算、变更实现这3个基本阶段。 简要说明你参与分析和开发的软件项目的用户需求。列举出在开发该软件项目时所发生的需求变更的具体情况并重点说明解决这些变更问题所采用的管理技术和方法。最后简要讨论几点你对“有效的需求变更管理”的实践体会。
1．需求管理需要“建立并维护在软件工程中同客户达成的契约”。这种契约都包含在编写的需求规格说明与模型中。客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中。 2．在需求管理中所规划和建立的细节层次结构，可通过需求跟踪表来反应。需要确定需求识别、变更管理过程、跟踪策略、CASE工具等内容。 3．通常的需求管理活动包括以下几个方面。 (1)定义需求基线(迅速制订需求文档的主体)。 (2)评审提出的需求变更、评估每项变更的可能影响，从而决定是否实施它。 (3)以一种可控制的方式将需求变更融入到项目中。 (4)使当前的项目计划与需求一致。 (5)估计变更需求所产生的影响，并在此基础上协商新的承诺(约定)。 (6)让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。 (7)在整个项目过程中跟踪需求状态及其变更情况。 一个需求变更管理过程包含问题分析和变更描述、变更分析和成本计算、变更实现这3个基本阶段。 简要说明你参与分析和开发的软件项目的用户需求。列举出在开发该软件项目时所发生的需求变更的具体情况，并重点说明解决这些变更问题所采用的管理技术和方法。最后，简要讨论几点你对“有效的需求变更管理”的实践体会。

正确答案：

1.简要叙述所参与管理和开发的软件项目，并明确指出在其中承担的主要任务和开展的主要工作。

2.需求管理的主要活动有变更控制，版本控制，需求跟踪和需求状态跟踪。

（1）需求变更管理过程包括：

2. 问题分析和变更描述，需要识别和分析需求问题，形成明确的变更协议，以检查它的有效性，从而产生一个更明确的需求变更提议。

4. 变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改，系统修改的设计和实现的成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。

6. 变更实现。这要求需求文档和系统设计以及实现都要同时修改。

   （2）版本控制：主要包括确定需求文档版本。

   （3）需求跟踪：包括定义对其他需求的链接；定义对其他系统元素的链接；使用的工具即需求跟踪矩阵。

   （4）需求状态跟踪：定义需求状态；跟踪需求的每一个状态。

   3.考生需结合自身参与项目的实际状况，指出其参与管理和开发的项目中所进行的需求管理活动，说明该活动的具体实施过程，使用的方法和工具，并对实际应用效果进行分析。

正确答案：软件开发成本估算是一个十分容易被忽视但却又是十分重要的内容。其重要的原因是没有成本估算项目计划就会失去基础；容易被忽视的原因却是由于大部分软件开发组织未能够有效掌握它。 软件估算包括规模估算、工作量估算、进度估算和成本估算。整个估算的过程是：首先根据软件需求进行规模估算也就是估计软件的规模通常以代码行数、功能点数为单位；然后在估计的规模的基础上根据项目的特定因素(例如技术能力、使用的语言和平台、团队稳定性、项目复杂度等)、开发生产率经验数字来估算开发的工作量这通常以人天、人月、人年为单位；最后根据客户提出的进度需求进行进度估算根据人员及其他成本 (如设备、房租、差旅等)对总的开发成本进行估算。软件估算的基础是经验数字和经验模型。 从上面的描述中可以看出规模估算是软件开发成本估算的基础(数据来源)而工作量估算则是软件开发成本估算的关键(决定了开发成本)。 规模估算最常用的方法包括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)文章应该花一定篇幅来说明估算的效果，也就是估算的误差值是多少，并且可以简要地分析这些误差值会来源于何处。

答案：

解析：