01.重构：敏捷方法，简化构建设计，重新组织
敏捷方法中，重构是一种重新组织技术，重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求，可以简化构件的设计而无需改变其功能或行为。
02.基于构建：合格性验证
基于构件的软件开发，主要强调在构建软件系统时复用已有的软件“构件”，在检索到可以使用的构件后，需要针对新系统的需求对构件进行合格性检验、适应性修改，然后集成到新系统中。
03.瀑布模型：软件需求明确
常见的软件生存周期模型有瀑布模型、演化模型、螺旋模型、喷泉模型等。瀑布模型是将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型，适合于软件需求很明确的软件项目。V模型是瀑布模型的一种演变模型，将测试和分析与设计关联进行，加强分析与设计的验证。原型模型是一种演化模型，通过快速构建可运行的原型系统，然后根据运行过程中获取的用户反馈进行改进。演化模型特别适用于对软件需求缺乏准确认识的情况。螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析。 本题中项目组具备了所开发系统的相关领域及类似规模系统的开发经验，即需求明确，瀑布模型最适合开发此项目。
04.确定模块以及调用关系：概要设计阶段
需求分析确定软件要完成的功能及非功能性要求；概要设计将需求转化为软件的模块划分，确定模块之间的调用关系；详细设计将模块进行细化，得到详细的数据结构和算法；编码根据详细设计进行代码的编写，得到可以运行的软件，并进行单元测试。
05.精化阶段：需求分析和架构演进
起始阶段专注于项目的初创活动。精化阶段理解了最初的领域范围之后，进行需求分析和架构演进。构建阶段关注系统的构建，产生实现模型。移交阶段关注于软件提交方面的工作，产生软件增量。产生阶段运行软件并监控软件的持续使用，提供运行环境的支持，提交并评估缺陷报告和变更请求。
06.软件工程基本要素：方法、工具、过程
软件工程是一种层次化的技术，从底向上分别为质量、过程、方法和工具。任何工程方法必须以有组织的质量承诺为基础。软件工程的基础是过程，过程是将技术结合在一起的凝聚力，使得计算机软件能够被合理地和及时地开发，过程定义了一组关键过程区域，构成了软件项目管理控制的基础；方法提供了建造软件在技术上需要“如何做”，它覆盖了一系列的任务。方法也依赖于一些基本原则，这些原则控制了每一个技术区域 而且包含建模活动和其他描述技术；工具对过程和方法提供了自动或半自动的支持，如：计算机辅助软件工程（CASE）。软件工程的基本要素包括方法、工具和过程。
07.原型化开发：需求基经常变更、规模不大
需求不清晰且规模不太大时采用原型化方法最合适，而数据处理领域的不太复杂的软件，适于用结构化方法进行开发。
08.RUP
角色：“谁做”
制品表：“做什么”
活动表：“怎么做”
工作流：“什么时候做”
09.软件项目计划进度图
Gantt：
不能清晰的描述任务之间的依赖关系
不能清晰的确定影响进度的关键任务
PERT：不能清晰的描述各个任务之间的并行关系
软件项目计划的一个重要内容是安排进度，常用的方法有Gantt图和PERT图。Gantt 图用水平条状图描述，它以日历为基准描述项目任务，可以清楚地表示任务的持续时间和任务之间的并行，但是不能清晰地描述各个任务之间的依赖关系。PERT图是一种网络模型，描述一个项目的各任务之间的关系。可以明确表达任务之间的依赖关系，即哪些任务完成后才能开始另一些任务，以及如期完成整个工程的关键路径，但是不能清晰地描述各个任务之间的并行关系。
10.概要设计阶段：系统分成若干子系统，建立体系
软件设计的任务是基于需求分析的结果建立各种设计模型，给出问题的解决方案。从工程管理的角度，可以将软件设计分为两个阶段：概要设计阶段和详细设计阶段。结构化设计方法中，概要设计阶段进行软件体系结构的设计、数据设计和接口设计；详细设计阶段进行数据结构和算法的设计。面向对象设计方法中，概要设计阶段进行体系结构设计、初步的类设计/数据设计、结构设计；详细设计阶段进行构件设计。 结构化设计和面向对象设计是两种不同的设计方法，结构化设计根据系统的数据流图进行设计，模块体现为函数、过程及子程序；面向对象设计基于面向对象的基本概念进行，模块体现为类、对象和构件等。
11.需求稳定，项目不大：结构化开发
需求不清晰且规模不太大时采用原型化方法最合适，而数据处理领域的不太复杂的软件，适于用结构化方法进行开发。
12.并列争球法：迭代方式并行递增实现产品
极限编程XP是激发开发人员创造性、使得管理负担最小的一组技术；水晶法Crystal认为每一个不同的项目都需要一套不同的策略、约定和方法论；并列争球法（Scrum）使用迭代的方法，其中把每30天一次的迭代成为一个冲刺，并按需求的优先级来实现产品。多个自组织和自治小组并行地递增实现产品，并通过简短的日常情况会议进行协调。
13.构建软件系统：无需考虑市场前景
在对软件开发资源进行规划时，为了确定构建软件系统所需的人数，需要考虑软件系统的规模、系统的技术复杂性、项目计划和开发人员的技术背景等方面，而与系统是否有市场前景无关。
14.风险：不一定发声
风险是一种具有负面后果的、人们不希望发生的事件。通常认为风险具有以下特点： 风险是可能发生的事件，其发生的可能性用风险概率来描述；风险是会给项目带来损失的事件；可能对风险进行干预，以期减少损失。针对每一种风险，应弄清可能减少造成损失或避免损失的程度。对风险加以控制，采取一些有效的措施来降低风险或是消除风险。
15.基本COCOMO：静态单变量模型、对整个软件系统进行估算
COCOMO用3个不同层次的模型来反映不同程度的复杂性，它们分别为：
基本模型（Basic Model）：是一个静态单变量模型，它用一个以已估算出来的源代码行数（LOC）为自变量的函数来计算软件开发工作量。
中级模型（Intermediate Model）：则在用LOC为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。
详细模型（Detailed Model）：包括中级COCOMO型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设计等各步骤的影响。
16.尽早交付：小型发布
敏捷开发方法XP是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法，其特性包含在12个最佳实践中。
1.计划游戏：快速制定计划、随着细节的不断变化而完善；
2.小型发布：系统的设计要能够尽可能早地交付；
3.隐喻：找到合适的比喻传达信息；
4.简单设计：只处理当前的需求使设计保持简单；
5.测试先行：先写测试代码再编写程序；
6.重构：重新审视需求和设计，重新明确地描述它们，以符合新的和现有的需求;
7.结队编程；
8.集体代码所有制；
9.持续集成：可以按日甚至按小时为客户提供可运行的版本；
10.每周工作40个小时；
11.现场客户；
12.编码标准。
17.专家判断方法、启发式方法、机器学习：总和可以得到精确的估算结果
项目估算是项目计划和管理的一个至关重要的方面。成本超出某个限度可能导致客户取消项目，而过低的成本估算可能会迫使开发小组投入大量的时间却没有相应的经济回报。目前常用的项目估算方法有专家判断方法，该方法受到专家经验和主观性等方面的影响；算法方法，根据某个计算模型来估算项目开发成本，如启发式方法COCOMO 模型，但这些模型中的参数难以确定；机器学习方法，如根据过去的项目开发数据，建立分类模型，预测新项目的开发成本，但这类方法难以定义训练数据的特征以及定义数据对象之间的相似性。即使结合多种方法，上述问题仍然存在，因此并不能得到精确地估算结果。
18.无主程序员：不适合大型项目
大规模项目最不适于采用无主程序员组的开发人员组织形式，因为大项目需要主程序员来整合各模块程序。
19.响应速度要求：非功能要求
软件需求是软件系统必须完成的事以及必须具备的品质。软件需求包括功能需求、非功能需求和设计约束三个方面的内容。功能需求是所开发的软件必须具备什么样的功能：非功能需求是指产品必须具备的属性或品质，如可靠性、性能、响应时间和扩展性等等;设计约束通常对解决方案的一些约束说明。“软件产品必须能够在3秒内对用户请求作出响应”主要表述软件的响应时间，属于非功能需求。
20.软件风险特征：不确定性、损失
软件风险一般包括不确定性和损失两个特性，其中不确定性是指风险可能发生，也可能不发生：损失是当风险确实发生时，会引起的不希望的后果和损失。救火和危机管理是对不适合但经常采用的软件风险管理策略。已知风险和未知风险是对软件风险进行分类的一种方式。员工和预算是在识别项目风险时需要识别的因素。
21.风险预测：风险发生可能性、发生后的结果
22.风险
风险分析实际上是4个不同的活动：风险识别、风险预测、风险评估和风险控制。
风险识别：是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。
风险预测：又称为风险估算，它从两个方面评估一个风险：风险发生的可能性或概率；以及如果风险发生时所产生的后果。
风险评估：根据风险及其发生的概率和产生的影响预测是否影响 参考水平值。
风险控制：的目的是辅助项目组建立处理风险的策略，有效的策略应考虑风 险避免、风险监控、风险管理及意外事件计划。
23.最好的风险控制策略：风险避免
风险避免即放弃或不进行可能带来损失的活动或工作。例如，为了避免洪水风险，可以把工厂建在地势较高、排水方便的地方，这是一种主动的风险控制方法。风险监控是指在决策主体的运行过程中，对风险的发展与变化情况进行全程监督，并根据需要进行应对策略的调整。风险管理是指在一个肯定有风险的环境里把风险减至最低的管理过程。对于风险我们可以转移，可以规避，但不能消除。
24.风险参照水准：风险估评类技术
定义风险参照水准是风险评估的一类技术，对于大多数软件项目来说成本、速度和性能是三种典型的风险参照水准。
25.风险优先级：根据风险暴露(Risk Exposure)设定
风险是一种具有负面后果的、人们不希望发生的事件。风险管理是软件项目管理的一项重要任务。在进行风险管理时，根据风险的优先级来确定风险控制策略，而优先级是根据风险暴露来确定的。风险暴露是一种量化风险影响的指标，等于风险影响乘以风险概率，风险影响是当风险发生时造成的损失。风险概率是风险发生的可能性。风险控制是风险管理的一个重要活动。
26.组织团队：要考虑人员的工作做风
人员管理是软件项目管理的一个重要部分，在组织开发团队时，应该考虑开发人员的工作能力、知识背景、工作风格、兴趣爱好等多方面的因素。每个成员的工作任务分配清楚，不应该参与所有阶段的工作。当项目进度滞后于项目计划时，增加开发人员不一定可以加快开发进度。
27.需求分析阶段：不包括软件体系结构图的输出
结构化分析模型包括数据流图、实体联系图、状态迁移图和数据字典，因此这些模型是需求分析阶段的输出。而确定软件体系结构是在软件设计阶段进行的。
28.COCOMO II：包含了三个阶段性的模型
存在多种软件项目管理的成本估算方法。其中专家估算方法主要依赖于专家的背景和经验，具有较大的主观性。Wolverton模型基于一个成本矩阵，定义不同的软件类型（如控制、输入/输出等）和难易（容易和困难）的成本，基于此计算软件开发的成本。COCOMO模型将规模视为成本的主要因素，考虑多个成本驱动因子。在后来的版本COCOMO II中，还考虑了软件开发的不同阶段，包含三个阶段性模型，即应用组装模型、早期设计阶段模型和体系结构阶段模型。
29.可预测的风险：不一定能避免发生
一般认为软件风险包含两个特性：不确定性和损失，不确定性即指风险可能发生也可能不发生。评估风险的影响，如果风险真的发生，有3个因素可能会影响风险所产生的后果，即风险的本质、范围和时间。如果风险可以预测，可以避免其发生，有些风险可以预测但无法避免。风险控制的目的是辅助项目组建立处理风险的策略。
30.COCOMO II：对象点、功能点、源代码行
COCOMOII模型也需要使用规模估算信息，在模型层次结构中有3种不同规模估算选择，即：对象点、功能点和代码行。
31.IO软件：隐藏实现细节、提供逻辑接口
I/O软件隐藏了I/O操作实现的细节。I/O软件向用户提供的是逻辑接口。I/O软件将硬件与较高层次的软件隔离开来，而最高层软件向应用提供一个友好的、清晰且统一的接口，方便用户使用。
32.重构(Refactoring)不属于：敏捷开发Scrum方法步骤
Product Backlog 产品待办事项清单；Refactoring 重构，不属于scrum的步骤；Sprint Backlog，Sprint待办事项清单；Sprint，冲刺迭代。
33.CMMI：1级是初级
CMM（Capability Maturity Model）是能力成熟度模型的缩写，CMM是国际公认的对软件公司进行成熟度等级认证的重要标准。CMM共分五级。在每一级中，定义了达到该级过程管理水平所应解决的关键问题和关键过程。每一较低级别是达到较高级别的基础。其中五级是最高级，即优化级，达到该级的软件公司过程可自发地不断改进，防止同类问题二次出现；四级称为已管理级，达到该级的软件公司已实现过程的定量化；三级为已定义级，即过程实现标准化；二级为可重复级，达到该级的软件公司过程已制度化，有纪律，可重复；一级为初始级，过程无序，进度、预算、功能和质量等方面不可预测。
34.易使用性子特征：不包括易分析性
易用性的自特性包括易理解性、易学性、易操作性，易分析性属于可维护性的子特性。
35.CMM第3级：使用标准开发过程构建系统
建立基本的项目管理和实践来跟踪项目费用、进度和功能特性为可重复级的核心；使用标准开发过程（或方法论）构建（或集成）系统为已定义级的核心；管理层寻求更主动地应对系统的开发问题为已管理级的核心；连续地监督和改进标准化的系统开发过程为优先级的核心。
36.CMM第4级：对软件过程和产品有定量理解和控制
在CMM的不同等级有不同的核心。在可重复级，建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性。在已定义级，所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。在已管理级，收集对软件过程和产品质量的详细度量，对软件过程和产品都有定量的理解与控制。在优化级，过程的量化反馈和先进的新思想、新技术促使过程不断改进。
37.信息库：不属于配置数据库
软件变更控制是变更管理的重要内容，要有效进行变更控制，需要借助配置数据库和基线的概念。配置数据库一般包括开发库、受控库和产品库。
38.有效捕获系统需求：原型模型
软件过程是软件生命周期中的一系列相关活动，即用于开发和维护软件及相关产品的一系列活动。软件过程模型可以帮助开发团队理解开发过程，形成对开发中的活动、资源和约束的共同理解，可以根据具体情况对一个过程进行裁剪等。瀑布模型从一种非常高层的角度描述了软件开发过程中进行的活动，并且提出了要求开发人员经过的事件序列。该模型适用于项目开始时需求已确定的情况。V模型是瀑布模型的变种，它说明测试活动是如何与分析和设计相联系的。原型模型允许开发人员快速地构造整个系统或系统的一部分以理解或澄清问题。原型的用途是获知用户的真正需求，因此原型模型可以有效地引发系统需求。螺旋模型把开发活动和风险管理结合起来，以将风险减到最小并控制风险。
39.喷泉模型：不存在明显边界
喷泉模型是典型的面向对象生命周期模型，是一种以用户需求为动力，以对象作为驱动的模型。该模型克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。“喷泉” 一词本身体现了迭代和无间隙特性。迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统；无间隙是指在开发活动之间不存在明显的边界。
40.增量模型：快速构建可运行产品
增量模型是一种非整体开发的模型，该模型具有较大的灵活性，适合于软件需求不明确的一种模型。使用该模型开发产品，一般是尽快构造出可运行的产品，然后在该产品的基础上再增加需要的新的构建，使产品更趋于完善。
41.了解相关领域：瀑布开发模型
项目规模大、开发小组对项目需求理解并了解相关领域，因此可以采用瀑布开发模型。演化模式适用于对软件需求缺乏准确认识的情况。螺旋模型在开发过程中加入风险分析。喷泉模型适合于面向对象的开发方法。
42.缺乏全面认识：最不适合瀑布模型
瀑布模型是一种经典的开发模型，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。瀑布模型的突出缺点是不适应用户需求的变化。
43.UP
UP （统一过程）模型是一种以用例和风险为驱动、以架构为中心、迭代并且增量的开发过程，由UML方法和工具支持。
UP过程定义了五个阶段，起始阶段、精化阶段、构建阶段、移交阶段和产生阶段。
开发过程中有多次迭代，每次迭代都包含计划、分析、 设计、构造、集成和测试，以及内部和外部发布。
每个迭代有五个核心工作流，捕获系统应该做什么的需求工作流、精化和结构化需求的分析工作流、在系统结构内实现需求的设计工作流、构造软件的实现工作流和验证是否如期望那样工作的测试工作流。
44.技术高、风险多、项目大：适合螺旋模型
瀑布模型将软件生存周期各个活动规定为线性顺序连接的若干阶段的模型，规定了由前至后，相互衔接的固定次序，如同瀑布流水，逐级下落。这种方法是一种理想的开发模式，缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。 原型模型从初始的原型逐步演化成最终软件产品，特别适用于对软件需求缺乏准确认识的情况。 增量开发是把软件产品作为一系列的增量构件来设计、编码、集成和测试，可以在增量开发过程中逐步理解需求。 螺旋将瀑布模型与快速原型模型结合起来，并且加入两种模型均忽略了的风险分析，适用于复杂的大型软件。
45.超大规模软件：最不适合原型模型
瀑布模型将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段的过程。 原型模型中，开发人员快速地构造整个系统或者系统的一部分以理解或澄清问题。螺旋模型将开发活动和风险管理结合起来，以减小风险。 喷泉模型开发过程模型以用户需求为动力，以对象为驱动，适合于面向对象的开发方法。 在这几种开发过程模型中，原型模型不适宜大规模软件的开发。
