一、能力成熟的模型(CMM)
二、能力成熟的模型集成(CMMI)
CMMI 提供了两种表示方式：阶段式模型和连续式模型。
1、阶段式模型（考得少）
2、连续式模型（考得多）
三、软件过程模型
软件过程模型也称软件开发模型；典型的软件过程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、
喷泉模型、基于构件的开发模型和形式化方法模型等。
1、瀑布模型
瀑布模型为软件的开发和维护提供了一种有效的管理模式，根据这一模式制定开发计划，进行成本预算，组织开发力量，
以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，所以它是以文档作为驱动、适合于软件需求很明
确的软件项目的模型或者具有相关领域及类似规模的开发经验。瀑布模型假设，一个待开发的系统需求是完
整的、简明的、一致的，而且可以先于设计和实现完成之前产生。
瀑布模型的优点是：容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。不足之处是，客户必须能够完整、
正确和清晰地表达他们的需要:在开始的两个或 3个阶段中，很难评估真正的进度状态;当接近项目结束时，出现了大量的集成和测试工
作;直到项目结束之前，都不能演示系统的能力。在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目
风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。
2、增量模型
增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为系列增量产品，每一增量可以分别开发。
该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”，如图 5-4 所示。当使用增量
模型时，第1个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个
增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点。此外，它还有以下优点：第一个可交付版本所需要的成本和
时间很少；开发由增量表示的小系统所承担的风险不大;由于很快发布了第一个版本，因此可以减少用户需求的变更: 运行增量投资，
即在项目开始时，可以仅对一个或两个增量投资。增量模型有以下不足之处：如果没有对用户的变更要求进行规划，那么产生的
初始增量可能会造成后来增量的不稳定:如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布；
管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
3、演化模型
软件类似于其他复杂的系统，会随着时间的推移而演化。在开发过程中，常常会面临以下情形:商业和产品需求经常发生变化，
直接导致最终产品难以实现: 严格的交付时间使得开发团队不可能圆满地完成软件产品，但是必须交付功能有限的版本以应对竞争
或商业压力; 很好地理解了核心产品和系统需求，但是产品或系统扩展的细节问题却没有定义。在上述情况和类似情况下，软件开
发人员需要一种专门应对不断演变的软件产品的过程模型。演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整
的软件版本。演化模型特别适用于对软件需求缺乏准确认识的情况。典型的演化模型有原型模型和螺旋模型等。
① 原型模型
有效的捕获系统需求，不适宜开发超大规模软件系统，系统功能在使用过程中可以不断改善
并非所有的需求都能够预先定义，大量的实践表明，在开发初期很难得到一个完整的、准确的需求规格说明。这主要是由于
客户往往不能准确地表达对未来系统的全面要求，开发者对要解决的应用问题模糊不清，以至于形成的需求规格说明常常是不完
整的、不准确的，有时甚至是有歧义的。此外，在整个开发过程中，用户可能会产生新的要求，导致需求的变更。而瀑布模型难
以适应这种需求的不确定性和变化，于是出现了快速原型 (Rapid Prototype) 这种新的开发方法。原型方法比较适合于用户需求不
清、需求经常变化的情况。当系统规模不是很大也不太复杂时，采用该方法比较好。
原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能
快速、低成本地构建原型。当然，能够采用原型方法是因为开发工具的快速发展，使得能够迅速地开发出一个让用户看得见、摸得
着的系统框架。这样，对于计算机不是很熟悉的用户就可以根据这个框架提出自己的需求。开发原型系统首先确定用户需求，开发
初始原型，然后征求用户对初始原型的改进意见，并根据意见修改原型。原型模型开始于沟通，其目的是定义软件的总体目标，标
识需求，然后快速制订原型开发的计划，确定原型的目标和范围，采用快速射击的方式对其进行建模，并构建原型。被开发的原型
应交付给客户使用，并收集客户的反馈意见，这些反馈意见可在下一轮中对原型进行改进。在前一个原型需要改进，或者需要扩展
其范围的时候，进入下一轮原型的迭代开发。
② 螺旋模型（加了风险分析）
适用于庞大、复杂且具有高风险的系统
螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。螺旋模型将开发过程分
为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，每个螺旋周期分为如下 4 个工作步骤。
(1)制订计划。确定软件的目标，选定实施方案，明确项目开发的限制条件.
(2)风险分析。分析所选的方案，识别风险，消除风险。
(3)实施工程。实施软件开发，验证阶段性产品。
(4)用户评估。评价开发工作，提出修正建议，建立下一个周期的开发计划。
与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高软件的适应能力，
并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险。在使用螺旋模型进行软件开发时，需要开发人员具有相
当丰富的风险评估经验和专门知识。另外，过多的迭代次数会增加开发成本，延迟提交时间。
4、喷泉模型
喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开
发活动集成的局限性。
喷泉模型使开发过程具有迭代性和无间隙性，迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统。
无间隙是指在开发活动(如分析、设计、编码) 之间不存在明显的边界，也就是说，它不像瀑布模型那样，在需求分析活动结束后才开始设
计活动,在设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。喷泉模型的各个阶段没有明显的界线，开
发人员可以同步进行。其优点是可以提高软件项目的开发效率，节省开发时间。由于喷泉模型在各个开发阶段是重叠的,在开发过程中需要
大量的开发人员，不利于项目的管理。此外，这种模型要求严格管理文档，使得审核的难度加大。
5、统一过程模型
统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由UML 方法和工具支持。迭代的意思是将整个
软件开发项目划分为许多个小的“袖珍项目”，每个“袖珍项目”都包含正常软件项目的所有元素:计划、分析和设计、构造、集成和测试，以及
内部和外部发布。
统一过程定义了 4 个技术阶段及其制品。
① 起始阶段(Inception Phase)
初启阶段结束时产生一个构想文档、一个有关用例模型的调查、一个初始的业务用例、一个早期的风险评估和一个可以显示阶段和迭代的项目计划等制品
②精化阶段(Elaboration Phase)
精化阶段结束时产生一个补充需求分析、一个软件架构描述和一个可执行的架构原型等制品:
③ 构建阶段(Construction Phase)
构建阶段结束时的成果是一个准备交到最终用户手中的产品，包括具有最初运作能力的在适当的平台上集成的软件产品、用户手册和对当前版本的描述
④移交阶段(Transition Phase)
移交阶段关注于软件提交方面的工作，产生软件增量，移交阶段结束时产生移交给用户产品发布版本。
4 个技术阶段：
初始阶段:生命周期目标。
精化阶段: 生命周期架构。
构建阶段:初始运作功能。
移交阶段:产品发布。
统一过程的典型代表是 RUP (Rational Unified Process)。RUP 是 UP 的商业扩展，完全兼容UP，但比 UP 更完整、更详细。
RUP 应用了角色、活动、制品和工作流 4种重要的模型元素，其中角色表述“谁做”，制品表述“做什么”，活动表述“怎么做”，工作流表述“什么时候做”。
四、敏捷方法
敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在软件开发过程中加入灵活性，敏捷方法
使用户能够在开发周期的后期增加或改变需求。
敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念(敏捷宣言)。
1、极限编程(XP)
XP 是一种轻量级(敏捷)、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为 4 个部分组成，
彼此相互依赖、关联，并通过行为贯穿于整个生存周期。
① 4 大价值观:沟通、简单性、反馈和勇气。
② 5 个原则:快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
③ 12 个最佳实践：计划游戏(快速制定计划、随着细节的不断变化而完善)、小型发布(系统的设计要能够尽可能早地交付)、隐喻(找到合适的比喻传达信息)、
简单设计(只处理当前的需求，使设计保持简单)、测试先行(先写测试代码，然后再编写程序)、重构(重新审视需求和设计，重新明确地描述它们以符合新的
和现有的需求)、结对编程(一个人看一个人写，效率低)、集体代码所有制、持续集成(可以按日甚至按小时为客户提供可运行的版本)、每周工作 40 个小时、
现场客户和编码标准。
2.水晶法(Crystal)
水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论，认为人对软件质量有重要的影响，因此随着项目质量和开发人员素质的提高，项
目和过程的质量也随之提高。通过更好地交流和经常性的交付，软件生产力得到提高。
3.并列争求法(Scrum）
并列争求法使用迭代的方法，其中，把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现
产品。协调是通过简短的日常情况会议来进行，就像橄榄球中的“并列争球”。
4.自适应软件开发(ASD）
ASD 有 6 个基本的原则:有一个使命作为指导:特征被视为客户价值的关键点:过程中的等待是很重要的，因此“重做”与“做”同样关键:变化不被视为改正，
而是被视为对软件开发实际情况的调整;确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求;风险也包含其中。
5.敏捷统一过程(AUP)
敏捷统一过程 (Agile Unified Process，AUP)采用“在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。采用经典的 UP 阶段性活动(初始、精化、
构建和转换)，提供了一系列活动，能够使团队为软件项目构想出一个全面的过程流。在每个活动里，一个团队迭代使用敏捷，并将有意义的软件增量尽可能
快地交付给最终用户。
每个 AUP 迭代执行以下活动:
① 建模。建立对商业和问题域的模型表述，这些模型“足够好”即可，以便团队继续前进
② 实现。将模型翻译成源代码。
③ 测试。像 XP 一样，团队设计和执行一系列的测试来发现错误以保证源代码满足需求。
④ 部署。对软件增量的交付以及获取最终用户的反馈。配置及项目管理。着眼于变更管理、风险管理以及对团队的任一制品的控制。项目管理追踪和控制开发
团队的工作进展并协调团队活动。
⑤ 环境管理。协调标准、工具以及适用于开发团队的支持技术等过程基础设施。
五、软件需求
(1) 功能需求。考虑系统要做什么，在何时做，在何时以及如何修改或升级。
(2) 性能需求。考虑软件开发的技术性指标。例如，存储容量限制、执行速度、响应时间及吞吐量。
(3) 用户或人的因素。考虑用户的类型。例如，各种用户对使用计算机的熟练程度，需要接受的训练，用户理解、使用系统的难度，用户错误操作系统的可能性等。
(4) 环境需求。考虑未来软件应用的环境，包括硬件和软件。对硬件设备的需求包括机型.外设、接口、地点、分布、湿度、磁场干扰等;对软件的需求包括操作系统、网络、数据库等
(5) 界面需求。考虑来自其他系统的输入，到其他系统的输出，对数据格式的特殊规定：对数据存储介质的规定。
(6) 文档需求。考虑需要哪些文档，文档针对哪些读者。
(7) 数据需求。考虑输入、输出数据的格式，接收、发送数据的频率，数据的准确性和精度，数据流量，数据需保持的时间。
(8) 资源使用需求。考虑软件运行时所需要的数据、其他软件、内存空间等资源: 软件开发、维护所需的人力、支撑软件、开发设备等。
六、系统设计
1、概要设计
（1)设计软件系统总体结构
其基本任务是采用某种设计方法，将一个复杂的系统按功能划分成模块; 确定每个模块的功能;确定模块之间的调用关系;确定模块之间的接口，即模块之间传递的信息:评价模块结构的质量。
软件系统总体结构的设计是概要设计关键的一步，直接影响到下一个阶段详细设计与编码的工作。软件系统的质量及一些整体特性都在软件系统总体结构的设计中决定
（2)数据结构及数据库设计
① 数据结构的设计。
② 数据库的设计。
概念设计。逻辑设计。物理设计。
（3)编写概要设计文档
文档主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划
（4）评审
2、详细设计
(1) 对每个模块进行详细的算法设计，用某种图形、表格和语言等工具将每个模块处理过程的详细算法描述出来。
(2) 对模块内的数据结构进行设
(3) 对数据库进行物理设计，即确定数据库的物理结构。
(4) 其他设计。根据软件系统的类型，还可能要进行以下设计。
① 代码设计
② 输入/输出格式设计
③ 用户界面设计
(5) 编写详细设计说明书
(6) 评审。
七、系统测试
1、系统测试的意义、目的及原则
① 系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。
② 测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。用户应根据开发各阶段的需求、设计等文档或程序的内部结构精心设计
测试实例，并利用这些实例来运行程序以便发现错误的过程。
③ 信息系统测试应包括软件测试、硬件测试和网络测试。硬件测试、网络测试可以根据具体的性能指标进行，此处所说的测试更多的是指软件测试。
④ 系统测试是保证系统质量和可靠性的关键步骤，是对系统开发过程中的系统分析、系统设计和实施的最后复查。根据测试的概念和目的，在进行
信息系统测试时应遵循以下基本原则。
(1) 应尽早并不断地进行测试。测试不是在应用系统开发完之后才进行的。由于原始问题的复杂性、开发各阶段的多样性以及参加人员之间的协调等因素，
使得在开发的各个阶段都有可能出现错误。因此，测试应贯穿在开发的各个阶段，应尽早纠正错误，消除隐患。
(2) 测试工作应该避免由原开发软件的人或小组承担，一方面，开发人员往往不愿否认自己的工作，总认为自己开发的软件没有错误:另一方面，开发人员
的错误很难由本人测试出来，很容易根据自己编程的思路来制定测试思路，具有局限性。测试工作应由专门人员来进行，这样会更客观、更有效。
(3) 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果。将实际输出结果与预期结果相比较就能发现测试对象是否正确。
(4) 在设计测试用例时，不仅要设计有效、合理的输入条件，也要包含不合理、失效的输入条件。在测试的时候，人们往往习惯按照合理的、正常的情况进
行测试，而忽略了对异常、不合理、意想不到的情况进行测试，而这可能就是隐患。
(5)在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事。多余的工作会带来副作用，影响程序的效率，有时会带来潜在的危害或错误。
(6) 严格按照测试计划来进行，避免测试的随意性。测试计划应包括测试内容、进度安排、人员安排、测试环境、测试工具和测试资料等。严格地按照测试
计划可以保证进度，使各方面都得以协调进行。
(7)妥善保存测试计划、测试用例，作为软件文档的组成部分，为维护提供方便。
(8)测试例子都是精心设计出来的，可以为重新测试或追加测试提供方便。当纠正错误、系统功能扩充后，都需要重新开始测试，而这些工作的重复性很高，可以
利用以前的测试用例,或在其基础上修改，然后进行测试。
(9) 系统测试阶段的测试目标来自于需求分析阶段
2、传统软件测试策略
有效的软件测试实际上分为 4 步进行，即单元测试、集成测试、确认测试和系统测试。
（1）单元测试
单元测试也称为模块测试，在模块编写完成且无编译错误后就可以进行。单元测试侧重于模块中的内部处理逻辑和数据结构。如果选用机器测试，一般用白盒测
试法。这类测试可以对多个模块同时进行。
1）单元测试的测试内容：
单元测试主要检查模块的以下 5 个特征。
① 模块接口。模块的接口保证了测试模块的数据流可以正确地流入、流出。在测试中应检查以下要点:
1、测试模块的输入参数和形式参数在个数、属性、单位上是否一致。
2、调用其他模块时，所给出的实际参数和被调用模块的形式参数在个数、属性、单位上是否一致。
3、 调用标准函数时，所用的参数在属性、数目和顺序上是否正确。4
4、全局变量在各模块中的定义和用法是否一致。
5、输入是否仅改变了形式参数。
6、开/关的语句是否正确。
7、规定的 I/O 格式是否与输入/输出语句一致。
8、在使用文件之前是否已经打开文件或使用文件之后是否已经关闭文件。
② 局部数据结构
1、变量的说明是否合适。
2、是否使用了尚未赋值或尚未初始化的变量
3、变量的初始值或默认值是否正确。
4、变量名是否有错(例如拼写错)。
③ 重要执行路径
1、计算方面出错
2、比较和控制流的错误
④ 出错处理
⑤ 边界条件
边界条件的测试是单元测试最后的工作，也是非常重要的工作。软件容易在边界出错
2）单元测试过程
由于模块不是独立运行的程序，各模块之间存在调用与被调用的关系。在对每个模块进行测试时，需要开发两种模块。
① 驱动模块：相当于一个主程序，接收测试例子的数据，将这些数据送到测试模块，输出测试结果。
② 桩模块：桩模块用来代替测试模块中所调用的子模块，其内部可进行少量的数据处理，目的是为了检验入口，输出调用和返回的信息。
提高模块的内聚度可以简化单元测试。如果每个模块只完成一种功能，对于具体模块来讲,所需的测试方案数据会显著减少，而且更容易发现和预测模块中的错误。
(2)集成测试
1）自顶向下集成测试
2）自底向上集成测试：不需要写桩模块，需要写驱动模块
3）回归测试：为修正错误而进行变更，但错误被修正后引起以前正确运行的代码出错
4）冒烟测试
(3)测试方法
1）静态测试
2）动态测试：指通过运行程序发现错误；黑盒测试和白盒测试
1、黑盒测试
黑盒测试也称为功能测试，在完全不考虑软件的内部结构和特性的情况下，测试软件的外部特性
常用的黑盒测试技术有等价类划分、边界值分析、错误推测和因果图等。
2、白盒测试
白盒测试也称为结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。
白盒测试常用的技术是逻辑覆盖、循环覆盖和基本路径测试。
(1) 逻辑覆盖。
① 语句覆盖。使被测试程序中的每条语句至少执行次。语句覆盖对程序执行逻辑的覆盖很低，因此一般认为它是很弱的逻辑覆盖。
② 判定覆盖。使得被测程序中的每个判定表达式至少获得一次“真”值和“假”值，或者说是程序中的每一个取“真”分支和取“假”分支至少都通过一次，因此判定覆盖也称为分支覆盖。判定覆盖要比语句覆盖更强一些。
③ 条件覆盖。条件覆盖是指构造一组测试用例，使得每一判定语句中每个逻辑条件的各种可能的值至少满足一次。
④ 判定/条件覆盖。使得判定中每个条件的所有可能取值(真/假) 至少出现一次，并使每个判定本身的判定结果(真/假) 也至少出现一次。
⑤ 条件组合覆盖。使得每个判定中条件的各种可能值的组合都至少出现一次。满足条件组合覆盖的测试用例是一定满足判定覆盖、条件覆盖和判定/条件覆盖的。
⑥路径覆盖。路径覆盖是指覆盖被测试程序中所有可能的路径。
(2)循环覆盖。执行足够的测试用例，使得循环中的每个条件都得到验证。
(3)基本路径测试。
3、McCabe度量法
V (G) = m - n +2 或者 V (G) = 闭合回路 + 1
m是弧度数；n是节点数
八、软件维护
1、系统可维护性概念
软件维护是软件生命周期中的最后一个阶段，处于系统投入生产性运行以后的时期中，因此不属于系统开发过程。
1）系统可维护性评价指标
① 可理解性
② 可测试性
③ 可修改性
2、维护和软件文档
文档是软件可维护性的决定性因素；编写高质量文档可以提高软件开发的质量；文档也是软件产品的一部分，没有文档的软件就不能称之为软件。
软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量高质量文档对于软件产品的效益有着重要的意义总的来说，软件文档只好不坏，选
项中说软件文档不好的就是不正确的。
3、系统维护的内容及类型
系统维护主要包括硬件维护、软件维护、数据维护
软件维护的内容一般有以下几分方面：
① 正确性维护：指改正系统开发阶段已发生而系统阶段尚未发现的错误
② 适用性维护：使应用软件适应信息技术（外部环境）变化和管理需求变化而进行修改
③ 完善性维护：为扩充功能和改善功能进行修改
④ 预防性维护：为了改进应用软件的可靠性和可维护性，为了适应未来的软/硬件环境的变化，应主动增加预防性的新功能
软件的质量属性
沟通路径数 = n (n - 1) / 2
4、软件项目估算
（1）COCOMO
① 基本 COCOMO 模型 ：静态单变量模型
② 中级 COCOMO 模型 ：静态多变量模型
③ 详细 COCOMO 模型
（2）COCOMOII
需要使用规模估算信息，在模型层次结构中有3种不同的规模估算选择：对象点、功能点、代码行。
应用组装模型使用的是对象点；早期设计阶段模型使用的是功能点，功能点可以转换成代码行
① 应用组装模型
② 早期设计阶段模型
③ 体系结构阶段模型
5、进度安排
（3）项目活动图
考点：① 求关键路径：路径最长的
A-->C-->F-->G-->I
② 求关键路径的长度：路径最长的长度
17(A-->C-->F-->G-->I)
③ 某个点或者某个活动是否在关键路径上：
A、C、F、G、I在关键路径上
④ 某个点或者某个活动的松弛时间 ： 用关键路径长度减去过该活动的路径的最大值，也可以得出该活动的松弛时间
⑤ 某个活动最多可以晚几天
