面向对象分析和设计试题

1、一、 面向对象分析和设计.二、 数据库设计1. 根据关系模型数据库的数据模型，下列描述正确的一项是：（ ）A、能体现一对多、一对一的关系，但不能体现多对多的关系。B、以二维表格结构来保存数据，在关系表中不允许有重复行存在。C、只存在一对一的实体关系，以图形方式来表示。D、关系模型数据库是数据库发展的最初阶段。答案：B2. 在关系数据库中存在着三种类型的关系，下列的关系中不属于关系数据库类型的是（ ）A一对多B一对一C多对多D多对一答案:D3. 在数据库中，数据定义语言（DDL）允许用户创建、修改或者删除数据库、表和约束等。那么数据控制语言（DCL），用于控制对数据库的访问，最常用

2、的DCL命令是（ ）AGRANT，DENY，REVOKEBDENY，INSERT，UPDATECUPDATE，DENY，REVOKEDGRANT，INSERT，ALTER答案:A三、 日构建日构建是一项非常基础的软件开发实践，什么是软件开发的有效管理在一个全国性的银行中，是什么保证复杂的资金清算的正确性的呢？每天，各个地方的网点在结束营业之前，需要保证账目、资金、票据的平 衡；这些网点的数据不断的汇集，在每一个汇集点上都要保证账目余额的平衡，最终完成一个银行的一天的结算。天天如此，就像是一部设计精巧的机器一样运作不 息。不仅银行是这样，任何一个企业都是如此。一个小杂货铺的老板，也知道每天算算账

3、，看看今天是赚是赔。这些行为已经成为了工作的一部分，甚至成为了一种 习惯。软件开发也是一样的，必须找到一种方法，来衡量每天的工作，保证每天的工作能够有效的持续下去，最终把软件开发的过程变成一种内在的过程。这种方法就称为日构建或是持续集成。为什么需要日构建日构建和持续集成是类似的，对开放源码熟悉的人应该都知道Nightly Build。而持续集成这个词来自XP方法，它的频率可以比日构建更高，可以做到几分钟就进行一次集成，故而由此得名。在本文中，我们只讨论日构建，而要 将日构建转换为持续集成是非常容易的。事实上，并没有规定持续集成必须是以分钟为单位进行的，如果你愿意，以一周为单位进行持续集成也是可

4、行的。这样区分 的目的是为了更好的使用日构建或是持续集成技术：至少以天为单位，频率越高，效果则越好。那么，什么是日构建呢？我们传统开发软件的流程一般是这样，理解领域问题，然后分配任务，由不同的人负责不同的软件部件，在开发完成之后，再把各人的部件整合起来，形成完整的软件。这个思路看起来并没有什么问题，但是在实践中却问题多多。首先，这种方式适合开发人员之间工作彼此没有交集的情况，以前这种现象很常见，但是现在，随着软件规模的扩大、分工合作的加深，开发人员间的相互依赖程度越来越高，这种清晰的职责划分已经变得越来越难了。其次，在软件集成时，往往会出现各种各样的问题，可是却很难发现到底问题在哪里？公说公有

5、理，婆说婆有理。每个人的代码都没有问题，结合到一起就出现大量的问题。所以日构建就将平时难得一见的集成工作转换成频繁进行的一件工作，从而使得原先如同噩梦般的集成变成了一件简单的工作。这也是很容易理 解的，如果集成工作几个月才进行一次，谁能够记起几个月前的细节呢？但是如果集成以天，甚至以分钟为单位进行，排除bug就变成一件很容易的事情了。日构建范例现在的时间是下午的17:00，马上就到日构建的时间了。团队里四名程序员中的三位已经将自己的源代码和测试代码提交到了一台名为宙斯 的机器上，这台机器将负责对代码进行日构建。在他们提交代码之前，已经通过了本机上的构建，并完成了测试。剩下的一位程序员似乎碰到了

6、麻烦，他的代码出现 了一些问题，他现在需要编写更多的测试来完善测试网。看来时间来不及了，他只能够在明天再做提交了。由于他的代码没有和其他人产生依赖，所以迟些提交也没 有关系，不过他在下个工作日的时候必须仔细的将最新的源代码检出到本地，在版本控制工具的帮助下，这项工作是很简单的。17:10，终于开始了构建的过程。他从代码源中检出最新代码，然后开始编译，构建，并执行了所有的测试，从控制台界面上，日构建 的负责人（其中的一位程序员）似乎看到了有部分的测试没有通过，他对剩下的人说，似乎有麻烦了。测试完成之后，将会从代码中生成所有的API文档，并进行 代码分析和测试覆盖率分析，最新测试报告和各种其它的报

7、告都将会发布到Web上。最后。完成构建的软件和相关的资料已经成功的发布了，时钟指向17:18。现在只是项目的早期，到了中后期，至少还需要20分钟的时 间，老鸟程序员告诉没有经验的程序员，并让大家去看看测试结果。一个程序员边嘟囔，边看log日志，我在本机都已经测试过了呀，怎么会有错呢。检查 结果发现是环境问题，配置文件被人改动了。看来，集成过程中仍然少不了冲突的问题，只不过，这些问题可以被很快的发现，并很快的得以解决。以上是一个典型的日构建过程，日构建的过程是完全自动化的，通过预先定义好的指令，机器将按照指令顺序执行完所有的构建步骤。日构建中涉及的步骤是可选的。日构建的价值可能有些人认为日构建过

8、于浪费时间，但是实际上，比起最后除错的成本来说，日构建成本是微不足道的。当然，在企业中建立日构建制度确实需要花费不少的时间，但从长远来看，这绝对是值得的。从表面上看，日构建能够减少最终的排错成本，但这仅仅是日构建最基本的价值。实际上，日构建更为关键的作用是能够引入日构建的制度。这 是什么意思呢？日构建的思路将会为软件企业的开发流程带来变化：开发人员将会在日构建的制度下更加频繁的协作，开发进度一目了然，软件的质量也会更加的稳 定。软件开发本身就是一项强调沟通和协作的活动。但是在日常的活动中，常常出现阻碍沟通的情况，例如需要沟通的双方不在同一个地理位置、噪 声、沟通双方的意愿等等。因此在软件管理中

9、需要提供一种方法，来鼓励人们进行沟通。日构建就是其中的一种方法（但它并不是唯一的方法）。每一次的构建将会 涉及到团队中的所有成员，因此沟通是少不了的，在日构建实践的驱动下，每位开发人员都朝着最终的目的成功的构建努力。在Alistair Cockburn的敏捷软件开发的第三章中，详细的阐述了团队沟通和协作中的相关问题。例如沟通的实质，影响沟通的各种因素，以及如何克服他们。最后，他还论述了如何促进团队的沟通，来打造一支成功的团队。在日构建的驱动下，项目的进度将会变得非常的明显。每一天的构建结果将会通过某个渠道发布出来，团队和团队的老板可以看到软件现在的样 子，项目的完成情况，出现的问题等等。这些信

10、息构成了软件开发的基本信息。不但可以清晰地描述出项目进度，也为管理人员安排计划提供了基础数据的支持。有 了基本的量化数据，软件开发才不是靠拍脑袋出成果的。日构建的最后一个价值是提供了整合性。目前软件开发中并没有一种统一的管理软件，未来似乎也很难做到，因为不同的软件组织差异很大。在 开发过程中，一些有价值的实践被加入、集成到日构建的过程中，在日构建的推动下，这些优秀实践很容易成为开发过程的一部分。在文章倡导的另一个优秀实践 测试驱动开发实践，就很容易集成到日构建中来。事实上，软件测试是非常重要的，它已经成为日构建成功的判别因素。选择日构建还是持续集成虽然日构建和持续集成的本质是相同的，但是他们在

11、集成的频率方面的差异也导致了一些管理上的差异：首先，日构建树立了一个明确的以工作日为单位的小目标，团队的目的就是为了使代码能够通过每天的构建。开发人员在明确的目标的指导下， 往往能够发挥出很高的效率。持续集成则将这个频率变得更小，只要你的代码提交到代码库中，立刻就会检验你的成果，如果有问题，你必须立刻排除，否则，要么 集成的过程无法继续，要么出错的开发人员的信箱被集成过程中的警告信息所填满。这种做法对团队的要求要更高一些。对于刚刚开始接触日构建的团队来说，可能 会手忙脚乱。其次，日构建有一条非常明确的分界线，开发工作要么是完成，要么是没有完成，不存在第三种状态。日构建的基础实践日构建的基础包括

12、三个实践：自动构建、统一代码源和集成测试。自动构建自动构建的思路是通过脚本语言，而不是通过在IDE环境中点击构建按钮来完成项目的构建过程。日构建需要不断的进行集成的工作，如果手 工来完成这项工作，既费时，效果又不好。所以更聪明的做法是把这件工作给自动化。在早期的Unix环境中，都是采用Make编写相应的脚本来完成构建的过 程。随着先进的IDE环境的发展，慢慢的人们就不愿意再编写Make脚本了。可是现在，为了自动构建的目标，我们需要回归到手工编写Make脚本的历史上 去。应该说，IDE环境中的构建方式侧重于个人开发，而自动构建则侧重于团队开发自动构建目标就是通过一个简单的命令就能够全部的构建过程

13、。统一代码源其次，保证一个开发团队共享统一的代码源。这时候我们需要使用版本控制工具。共享的代码库同样也是XP的一个基本实践。虽然XP还要求 开发人员可以修改他人的代码，但我们并不提倡这种做法，这要求团队成员之间有非常高的默契程度。统一的代码源能够保证所有人的代码都归总到一起，这是日构 建的基础。如果没有这一点的保证，每一次的构建我们都不得不把所有人的代码集中起来，这无疑会使构建过程变成灾难。统一代码源能够保证任何一位团队成员获得所有的代码，并以此为基础进行开发。集成测试只是把代码编译通过并不能够证明软件可以正常工作，评价软件的标准应该是测试。在日构建中必须要执行集成测试，来保证软件确实是能够工

14、作的。集成测试也是一个同义词相当多的名词，有人把它称为验证测试（BVTBuild Verification Tests），因为他们认为这种测试主要的目的是为了验证构建的正确性。有些人把它称为冒烟测试（Smoke Test），因为他们觉得这个测试的目的是运行软件，看它是否会冒烟。测试应该全部执行完毕，而不是遇到未被满足的错误就放弃测试过程。测试将形成结果，成功的测试，失败的测试，失败测试的细节。最后的结果将通过某种方式通知给相应的人员，要求他们修改设计或测试（如果是测试本身的问题的话）。集成测试是证明构建成功的关键因素。和构建一样，集成测试也应该是自动化的。日构建的基本工具日构建的工具有很多，但

15、是最基础、最广泛的工具是Ant（）。Ant类似于Make，但是加入了跨平台的特性。日构建的代价虽然日构建有诸多的好处，但是要使用日构建并不是一帆风顺的。最大的问题是如何引入日构建的三项基本实践。前两项相对简单，最难的是建立自动化测试。关于这部分的说明请参考测试驱动开发的相关部分。日构建扩展任务日构建的核心任务是编译、构建、执行测试和发布。除了这些任务之外，还可以微日构建添加扩展任务。生成文档。生成文档有很多的方法，其中最关键的是生成API文档。JavaDoc的概念减弱了传统软件开发中文档的重要性，而把大量的 文档嵌入到了代码层面中。除了标准的JavaDo

16、c文档之外，还可以利用第三方的工具生成自定义的文档，例如to-do列表文档。XDoclet就是其中 的一个工具。预编译。不少的应用引入了预编译。典型的如AspectJ，作为一个AOP工具，AspectJ的作用是使用特定的代码生成器生成AOP的Java代码，然后再进行编译。将预编译的工作纳入到构建过程，可以简化开发的工作量。典型的还包括一些ORM工具。代码分析。代码分析是软件度量的重要工作。代码分析可以为管理人员提供一个判断代码质量依据（不要把它作为唯一的标准）。代码分析是形式化的，因此可以制作成软件，集成到构建过程中来。例如，判断代码是否符合编码规范，文档和代码的比率，包和类涉及的合理性。测试

17、覆盖分析。测试覆盖分析作为辅助测试的手段是非常重要的。测试代码的复审，最关键的评价测试是否足够（相对），单靠人工完成这项工作太勉强了。所以应该令其自动化，并成为构建过程的一部分。问题跟踪。测试过程中出现的问题应该被纳入到一个问题跟踪系统中，可以通过和问题跟踪系统接口来设计自动化的任务。归档和备份。这是很基本，但也是很重要的功能。每天产生的工件应当进行妥当的归档、备份。1. 一个每日构造包括以下哪些步骤？（ ）A. 开发：完成内部发布里程碑对应进度表中所规定的功能B. 测试：按照测试计划进行测试C. 验证：按照质量标准进行评估D. 文档：将每天的工作记录下来进行评估答案：ABC2. 以下哪些属于

18、每日构造的益处？（ ）A. 易于暴露未预料的设计缺陷 B. 较早地诊断缺陷C. 减少项目投资的比例D. 同步小组成员的工作E. 减少集成的风险答案：ABDE3. 李先生在公司项目组中担任程序经理的角色，该项目组的项目正处于开发阶段，李先生对项目的每日构造制定指导文档，以下哪些对于每日构造的指导原则是合理的？（ ）A. 开发组的成员每天每人必须完成一个模块B. 测试和开发需要始终结合C. 针对每日构造，无需天天测试，只需要集成D. 发现缺陷后，必须当天修改，不能把有问题的程序带入第二天答案：BD4. 关于内部发布的优点，以下哪些说法是正确的？（ ）A. 内部发布缩小了出错的潜在范围B. 内部发布

19、有利于实施按风险优先级管理，使风险顺序地通过发布C. 内部发布有利于资金的合理安排D. 内部发布有利于鼓舞士气答案：ABD5. 关于开发阶段的目的，以下哪些说法是正确的？（ ）A. 构造代码、组件、基础架构（软件、硬件、网络、设施）B. 构造与用户及运营相关的文档等交付物C. 创建关于项目的目标、限定条件和解决方案的概要视图D. 开发市场渠道和销售帮助答案：ABD四、 代码审核代码审查（Code Review)是软件开发中常用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还可以帮助团队成员提高编程技能，统一编程风格等。1. 代码审查要求团队有良好的文化团队需要认识到代

20、码审查是为了提高整个团队的能力，而不是针对个体设置的检查“关卡”。“A的代码有个bug被B发现，所以A能力不行，B能力更好”，这一类的陷阱很容易被扩散从而影响团队内部的协作，因此需要避免。另外，代码审查本身可以提高开发者的能力，让其从自身犯过的错误中学习，从他人的思路中学习。如果开发者对这个流程有抵触或者反感，这个目的就达不到。2. 谨慎的使用审查中问题的发现率作为考评标准在代码审查中如果发现问题，对于问题的发现者来说这是好事，应该予以鼓励。但对于被发现者，我们不主张使用这个方式予以惩罚。软件开发中bug在所难免， 过度苛求本身有悖常理。更糟的是，如果造成参与者怕承担责任，不愿意在审查中指出问

21、题，代码审查就没有任何的价值和意义。3. 控制每次审查的代码数量据smartbear在思科所作的调查，每次审查200行-400行的代码效果最好。每次试图审查的代码过多，发现问题的能力就会下降，具体的比例关系如下图所示：我们在实践中发现，随着开发平台和开发语言的不同，最优的代码审查量有所不同。但是限制每次审查的数量确实非常必要，因为这个过程是高强度的脑力密集型活动。时间一长，代码在审查者眼里只是字母，无任何逻辑联系，自然不会有太多的产出。4. 带着问题去进行审查我们在每次代码审查中，要求审查者利用自身的经验先思考可能会碰到的问题，然后通过审查工作验证这些问题是否已经解决。一个窍门是，从用户可见的

22、功能出发，假设一个比较复杂的使用场景，在代码阅读中验证这个使用场景是否能够正确工作。使用这个技巧，可以让审查者有代入感，真正的沉浸入代码中，提高效率。大家都知道看武侠小说不容易瞌睡，而看专业书容易瞌睡，原因就是武侠小说更容易产生代入感。有的研究建议每次树立目标，控制单位时间内审核的代码数量。这个方法在我们的实践中显得很机械和流程化，不如上面的方法效果好。5. 所有的问题和修改，必须由原作者进行确认如果在审查中发现问题，务必由原作者进行确认。这样做有两个目的：(1)确认问题确实存在，保证问题被解决(2)让原作者了解问题和不足，帮助其成长有些时候为了追求效率，有经验的审查者更倾向于直接修改代码乃至

23、重构所有代码，但这样不利于提高团队效率，并且会增加因为重构引入新bug的几率，通常情况下我们不予鼓励。6.利用代码审查激活个体“能动性即使项目进度比较紧张，无法完全的进行代码审查，至少也要进行部分代码的审查，此时随即抽取一些关键部分是个不错的办法。 背后的逻辑是，软件开发是非常有创造性的工作，开发者都有强烈的自我驱动性和自我实现的要求。让开发者知道他写的任何代码都可能被其他人阅读和审察，可 以促使开发者集中注意力，尤其是避免将质量糟糕，乃至有低级错误的代码提交给同伴审查。开源软件也很好的利用了这种心态来提高代码质量。7.在非正式，轻松的环境下进行代码审查如前所述，代码审查是一个脑力密集型的工作

24、。参与者需要在比较轻松的环境下进行该工作。因此，我们认为像某些实践中建议的那样，以会议的形式进行代码审查效果并不好，不仅因为长时间的会议容易让效率低下，更因为会议上可能出现的争议和思考不利于进行如此复杂的工作。8.提交代码前自我审查，添加对代码的说明所有团队成员在提交代码给其他成员审查前，必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外，还可以完成如下的工作：(1)对代码添加注释，说明本次修改背后的原因，方便其他人进行审查。(2)修正编码风格，尤其是一些关键数据结构和方法的命名，提高代码的可读性。(3)从全局审视设计，是否完整的考虑了所有情景。在实现之前做的设计如果存在考虑不

25、周的情况，这个阶段可以很好的进行补救。我们在实践中发现，即使只有原作者进行代码审查，仍然可以很好的提高代码质量。9.实现中记录笔记可以很好的提高问题发现率成员在编码的时候应做随手记录，包括在代码中用注释的方式表示，或者记录简单的个人文档，这样做有几个好处：(1)避免遗漏。在编码时将考虑到的任何问题都记录下来，在审查阶段再次检查这些问题都确认解决。(2)根据研究，每个人都习惯犯一些重复性的错误。这类问题在编码是记录下来，可以在审查的时候用作检查的依据。(3)在反复记录笔记并在审查中发现类似的问题后，该类问题出现率会显著下降10. 使用好的工具进行轻量级的代码审查“工欲善其事，必先利其器”。我们使

26、用的是bitbucket提供的代码托管服务。每个团队成员独立开发功能，然后利用Pull Request的形式将代码提交给审查者。复审者可以很方便在网页上阅读代码，添加评论等，然后原作者会自动收到邮件提醒，对审阅的意见进行讨论。即使团队成员分布在天南海北，利用bitbucket提供的工具也能很好的进行代码审查。1. 关于代码审核的优点，以下哪些说法是正确的？（ ）A. 代码审核有助于提高代码的质量B. 为了降低更改费用，代码审核一定在到达开发阶段里程碑时才能进行，而不能在中间里程碑时进行C. 审核之中可由一个专门编程标准与风险审查，有利于编出更规范的代码D. 代码审核可以节约大量测试和维护时间，

27、代码审核实际是一次内部交流，有利于疑难、悬而未决的问题早解决，减少不必要的延误答案：ACD2. 李先生作为MSF实施顾问，为NorthWind公司的项目组指导代码审核的方法，以下哪些代码审核的说法是正确的？（ ）A. 全面正式审核，全组人员必须参加，可外请审核专家和相关人员B. 不定时的，同事间审核，促使开发人员间相互了解；资源开发者传授经验C. 独立的第三方审核，请非本项目参与者参与审核，由本组干系人报告、演示，第三方人员审核D. 全面正式审核，不定时、同事间审核以及独立第三方审核，这三者结合起来可用于代替上机测试答案：ABC五、 集成测试1. 以下哪些是缺陷（Bug）的严格定义的？（ ）A

28、. 产品规范中说要做某件事，软件没做B. 产品规范中说不做某件事，软件做了C. 产品规范提供没有提的事，软件却做了D. 产品规范该提却没有提的事，软件没做E. 最终用户感觉不好用，测试者承认是难于理解，难于使用和低效的答案：ABCDE2. 关于缺陷的分类，以下哪些说法是错误的？（ ）A. 按严重性分类，缺陷可分为：系统崩溃、重大的、一般的、轻微的B. 按处理优先级可分为：最高优先级、高优先级、中优先级、低优先级C. 重大的，导致崩溃的最重缺陷优先级必然高D. 高优先级的缺陷必然是严重性最高的答案：ABC六、 代码重构代码重构（英语：Code refactoring）指对软件代码做任何更动以增加

29、可读性或者简化结构而不影响输出结果。软件重构需要借助工具完成，重构工具能够修改代码同时修改所有引用该代码的地方。在极限编程的方法学中，重构需要单元测试来支持。在软件工程学里，重构代码一词通常是指在不改变代码的外部行为情况下而修改源代码，有时非正式地称为“清理干净”。在极限编程或其他敏捷方法学中，重构常常是软件开发循环的一部分: 开发者轮流增加新的测试和功能，并重构代码来增进内部的清晰性和一致性。自动化的单元测试保证了重构不至于让代码停止工作。重构既不修正错误，又不增加新的功能性。反而它是用于提高代码的可读性或者改变代码内部结构与设计，并且移除死代码， 使其在将来更容易被维护。重构代码可以是结构

30、层面抑或是语意层面，不同的重构手段施行时，可能是结构的调整或是语意的转换，但前提是不影响代码在转换前后 的行为。特别是，在现有的程序的结构下，给一个程序增加一个新的行为可能会非常困难，因此开发人员可能先重构这部分代码，使加入新的行为变得容易。一个重构的小范例是修改一个变量的名称使其具有更明确的含义，例如从单个字母的“ i ”重构为“ interestRate ”（利率）（图一）。较复杂的重构是把一段 if 区块中的代码变为一个子程序（图二）。更复杂一点的重构是用多态性来替换 if 条件式。 “清理”代码已经发生了几十年，重构中最关键的认知是有意地“清理”代码，透过从已知的纪录里一些常用的重构方

31、法清理代码，把它从增加新功能分开，然后个 别的对代码进行测试 (任何的行为改变都可能带来错误)。新的实现切合实际需要以改善现有设计，并且不改变原软件的意图或行为。重构面对业界调适接受方面的挑战。首先，对重构长远的影响需要更深入研究追踪。又，重构存于资料库轮廓（database schema） 的商业逻辑层几乎是不可能或者非常困难的。最后，对接口造成影响的重构可能造成程序开发上的困境，除非程序员有对所有用户界面的访问权。例如，程序员若改变某实体中的方法名称，他要么必须对整个专案里头所有连结到旧名的参考都加以编辑，要么屈服于继续维护使用旧名的残株残瓦接口。而该旧名的接口于内部调用该方法的新名。1.

32、 一些常见的重构任务包括：()A. 改变方法的签名B. 重命名变量C. 基于现有代码创建接口D. 把一段代码转变成一个独立的方法答案：ABCD2. 在你创建完一个类后才发现你还有其它一些类具有类似结构但是仅具有不同的实现。你会选用下列哪种重构方法。（）A. 重命名B. 提取方法C. 封装字段D. 提取接口答案：D3. 在你编写一个方法的时候，发现方法里的一个局部变量的值需要由方法被调用的时候传递，你会选用下列哪种重构方法。（）A. 把局部变量提升为参数B. 提取方法C. 封装字段D. 提取接口答案：A七、 软件工程1. 以下哪些选项属于软件质量控制的标准？（ ）A. ISO 3297B. CM

33、MC. ISO 9000系列D. IEEE答案：BC能力成熟度模型（Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM） 什么是能力成熟度模型 (Capability Maturity Model)？CMM是指“能力成熟度模型”，是对于软件组织在定义、实施、度量、控制和改善其软件过程的 实践中各个发展阶段的描述。它是在美国国防部的指导下，由软件开发团体和软件工程学院（SEI）及Carnegie Mellon大学共同开发的。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化

34、、使 企业能够更好地实现商业目标。 CMM是一种用于评价软件承包能力并帮助其改善软件质量的 方法，侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优 化级。 从当今整个软件公司现状来看，最多的成熟度为1级，多数成熟度为2级，少数成熟度为3级，极少数成熟度为4级，成熟度为5级的更是凤毛麟角。 其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件生产中的困难。CMM它是目前国际上最流行、最实用的一种软件生产过程标准，已经得到了众多国家以及国际软

35、件产业界的认可，成为当今企业从事规模软件生产不可缺少的一项内容。 CMM为软件企业的 过程能力提供了一个阶梯式的改进框架，它基于过去所有软件工程过程改进的成果，吸取了以往软件工程的经验教训，提供了一个基于过程改进的框架；它指明了一 个软件组织在软件开发方面需要管理哪些主要工作、这些工作之间的关系、以及以怎样的先后次序，一步一步的做好这些工作而使软件组织走向成熟。成熟度等级1：初始级(Initial)。处于这个最低级的组织，基本上没有健全的软件工程管理制度。每件事情都以特殊的方法来做。如果一个特定的工程碰巧由一个有能力的管理员和 一个优秀的软件开发组来做，则这个工程可能是成功的。然而通常的情况是

36、，由于缺乏健全的总体管理和详细计划，时间和费用经常超支。结果，大多数的行动只是 应付危机，而非事先计划好的任务。处于成熟度等级1的组织，由于软件过程完全取决于当前的人员配备，所以具有不可预测性，人员变化了，过程也跟着变化。结 果，要精确地预测产品的开发时间和费用之类重要的项目，是不可能的。 成熟度等级2：可重复级(Repeatable)。在这一级，有些基本的软件项目的管理行为、 设计和管理技术是基于相似产品中的经验，故称为“可重复”。在这一级采取了一定措施，这些措施是实现一个完备过程所必不可缺少的第一步。典型的措施包括仔 细地跟踪费用和进度。不像在第一级那样，在危机状态下方行动，管理人员在问题

37、出现时便可发现，并立即采取修正行动，以防它们变成危机。关键的一点是，如没 有这些措施，要在问题变得无法收拾前发现它们是不可能的。在一个项目中采取的措施也可用来为未来的项目拟定实现的期限和费用计划。 成熟度等级3：已定义级(Defined)。在第3级，已为软件生产的过程编制了完整的文档。 软件过程的管理方面和技术方面都明确地做了定义，并按需要不断地改进过程，而且采用评审的办法来保证软件的质量。在这一级，可引用CASE环境来进一步提 高质量和产生率。而在第级过程中，“高技术”只会使这一危机驱动的过程更混乱。 成熟度等级4：已管理级(Managed)。一个处于第4级的公司对每个项目都设定质量和生产目

38、标。这两个量将被不断地测量，当偏离目标太多时，就采取行动来修正。利用统计质量控制，管理部门能区分出随机偏离和有深刻含义的质量或生产目标的偏离(统计质量控制措施的一个简单例子是每千行代码的错误率。相应的目标就是随时间推移减少这个量)。 成熟度等级5：优化级(Optimizing)。个第5级组织的目标是连续地改进软件过程。这样的组织使用统计质量和过程控制技术作为指导。从各个方面中获得的知识将被运用在以后的项目中，从而使软件过程融入了正反馈循环，使生产率和质量得到稳步的改进。2. CMM把企业控制软件过程的能力分为五级，分别是（ ）。A. 初始级、可重复级、可定义级、可管理级和可优化级B. 初始级、

39、可配置级、可定义级、可管理级和可优化级C. 初始级、可配置级、可定义级、可监控级和可优化级D. 初始级、可重复级、可定义级、可监控级和可优化级答案: A八、 项目管理基线(Baseline)，基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础.所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线了的版本.这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布. 基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，

40、以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。 参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。随着工作的进展，基线将合并自从上次建立基线以来开发人员已经交付的工作。变更一旦并入基线，开发人员就采用新的基线，以与项目中的变更保持同步。调整基线将把集成工作区中的文件并入开发工作区。 建立基线的原因建立基线的三大原因是：重现性、可追踪性和报告。 重现性是指及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。可追踪性建立项目工件之间的前后继承关系。其目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。报告来源于一个基线内容同另一个基线内容的比较。基线比较有助于调试并生成发布说明。 建立基线后，需要标注所有组成构件和基线，以便能够对其进行识别和重新建立。 建立基线的优点建立基线有以下几个优点： 基线为开发工件提供了一个定点和快照。 新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。 各开发人员可以将建有基线的构件作为他在隔离的私有工作区中进行更新的基础。 当认为更新不稳定或不可信时，基线为团队提供一