软件工程概念的提出以解决出现的“软件危机”。
软件工程的定义：软件工程是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户需求的软件产品的工程，或以此为研究对象的学科。
软件工程的发展分为两个时期：
20世纪60年代末到80年代初，围绕软件项目开展了有关开发模型、开发方法和支持工具的研究。（瀑布模型、过程式语言、结构化方法、调试工具、测试工具）
20世纪80年代以来，开展大量软件工程实践，围绕对软件工程过程的支持，开展了一系列有关软件的生产技术，特别是软件复用技术和软件生产管理的研究和实践。（《软件生存周期过程》）
计算机软件是计算机系统中程序及其文档。
软件开发的目标：将问题域中的概念映射为运行平台上的概念
软件开发的本质：实现问题空间的概念与处理逻辑到解空间的概念与处理逻辑之间的映射。
实现这一映射的基本途径，即系统建模。
系统建模：运用所掌握的知识，通过抽象，给出系统的一个结构——系统模型。
系统模型分为两大类：概念模型（描述了系统是什么），软件模型（描述了实现概念模型的软件解决方案）
软件模型又可以分为设计模型、实现模型、部署模型
需求是有关一个“要予构造”的陈述，描述了待开发产品/系统功能上的能力、性能参数或其他性质。
5个基本性质：
必要的
无歧义的
可测的
可跟踪的
可测量的
功能需求：
非功能需求：
1.性能需求
2.外部接口需求
用户接口硬件接口软件接口通信接口内存约束运行地点需求3.设计约束
法规政策硬件限制与其它应用的接口并发操作审计能力控制功能高级语言要求握手协议应用的关键程度安全和保密4.质量属性需求
可靠性存活性可维护性用户友好性1.自悟：需求分析人员把自己作为系统的最终用户
存在风险：无法验证发现的需求是否满足用户的需求，无法验证发现的需求是不是正确的。
2.交谈：需求人员通过提出问题/用户回答，直接询问客户需要一个怎样的系统
存在风险：交谈期间所获得的需求可能不断增长，导致超出项目成本和进度的限制。
3.观察：观察用户执行其现行的任务和过程
存在风险：客户可能抵触这一观察，打扰了他们的正常业务。
4.小组会：客户与开发人员的联合会议
存在风险：会议组织不到位。
5.提炼：复审技术文档，提取相关信息
存在风险：与自悟一致。
需求规约是一个软件产品/系统所有陈述的正式文档，表达了一个软件产品/系统的概念模型。
4个基本性质：
重要性和稳定性程度可修改的完整的一致的主要问题是容易产生歧义、矛盾和不可测的问题。
半形式化的需求规约：以半形式化符号体系来表达需求规约形式化的需求规约：以一种基于数学概念的符号化体系来表达需求规约结构化方法作为一种“思想“工具，可用于定义需求，建立待系统的功能模型；可用于定义满足需求的结构，给出一种特定的软件解决方案。
在进行软件系统/产品的需求工作中，面临三大挑战：
（1）问题空间理解
（2）人与人之间的通信
（3）需求的变化性
为了应对以上三大挑战，一种好的需求技术应具有以下基本特征：
（1）提供方便通信的机制
（2）鼓励需求分析人员使用问题空间的术语思考问题，编写文档
（3）提供定义系统边界的方法
（4）提供支持抽象的多种机制
（5）为需求分析人员提供多种可供选择的方案
（6）提供特定的技术，适应需求的变化
软件开发方法：结构化方法、面向数据结构的软件开发方法以及面向对象方法
结构化方法（系统必须做什么）是一种系统化的软件开发方法，包括结构化分析方法、结构化设计方法、结构化程序设计方法
实现结构化分析方法需用到的基本术语、表达系统模型的工具、建模过程
基本术语：数据流、加工、数据存储、数据源和数据潭；
表达系统功能模型的工具：数据流图（DFD图） 需求分析的首要任务是建立系统功能模型
建模过程： （1）建立系统的功能模型——使用工具为数据流图DFD 首先，建立系统环境图（顶层数据流图），确定系统边界；继之，自顶向下，逐步求精，建立系统的层次结构图
（2）建立数据字典——使用工具为结构符：定义=、顺序+、选择|、循环{ } 、子界m..n
数据流条目：给出DFD图中所有数据流的结构定义数据存储：给出DFD图中所有数据存储的结构定义数据项：给出DFD图中所有数据项的类型定义（3）描述加工——使用工具为判定表、判定树 集中描述一个加工“做什么”，即加工逻辑，也包括其他一些与加工有关的信息，如执行条件、执行频率、出错处理等。
结构化自然语言：如果一个输入数据和输出数据之间的逻辑关系比较简单，可以使用结构化自然语言予以描述。判定表：如果一个输入数据和输出数据之间的逻辑关系比较复杂，可以采用的一种工具。判定树应用中注意的问题：
（1）模型平衡问题
系统DFD中每个数据流和数据存储都要在数据字典中予以定义，并且数据名一致。系统DFD中最底层的加工必须在小说明中予以描述，并且与加工名一致。父图中某加工的输入／输出（数据流）和分解这个加工的子图的输入／输出（数据流）保持一致。在加工小说明中，所使用的数据流必须是在数据字典中定义的。（２）信息复杂性控制问题
上层数据流可以打包下层模块的个数控制在７±２以内每个加工的数据流不能太多分析数据内容，确定是否所有的输入信息都用于产生输出信息
发现错误是保障软件过程质量和软件产品质量的基础。
软件评估可分为静态评估（评审、走查、形式化证明）和动态评估（软件测试）；
软件测试技术分为基于程序路径的“白盒”测试技术，和基于规约的“黑盒”测试技术。
软件=程序+文档
软件测试的首要目标是预防错误，这一目标几乎不可能实现的；因此，软件测试的第二目标是发现错误。
软件测试的定义：按照特定的规程发现软件错误的过程。测试只能尽可能多的发现错误，不可能发现所有错误。
软件测试与软件调试的区别：
测试从一个侧面证明程序员的失败；调试是为了证明程序员的成功。测试从已知条件开始；测试是以不可知的内部条件开始。测试是有计划的；调试是不受时间约束的。测试是一个发现错误、改正错误、重新测试的过程；调试是一个推理过程。测试的执行是有规程的；调试要求程序员进行必要的推理。测试是由独立的测试组在不了解软件设计的条件下完成的；调试必须由了解详细设计的程序员完成。大多数测试的执行和设计可由工具支持；调试利用的工具只有调试器。测试对象：各个阶段所产生的源程序和文档
测试用例：为了发现程序中的故障而专门设计的一组数据或脚本。
软件测试的过程：测试设计、测试执行、测试结果比较
环境模型：对系统运行环境的抽象
被测对象模型：从测试的角度对程序进行抽象
错误模型：对程序中的错误及其分类进行抽象
在建立环境模型、被测对象模型、错误模型的基础上，才能设计测试用例，执行测试，并进行测试结果比较。
白盒测试技术（又称结构测试技术）：典型的是路径测试技术，依据的是程序的逻辑结构。
黑盒测试技术（又称功能测试技术）：包括事务流测试技术、等价类划分、边界值分析、因果图；依据的是软件行为的描述。
路径测试技术依据的是程序的逻辑结构，基本要点是：
采用控制流程图来表达被测程序模型，揭示程序中的控制结构。合理的选择一组穿过程序的路径，以达到某种测试度量。控制流程图：包括基本元素是过程块、节点、判定。
控制流程图与程序流程图之间的差异是，在控制流程图中不显示过程块的细节，而在程序流程图中着重于过程属性的描述。
测试策略★
（1）路径覆盖（PX）：执行所有可能穿过程序控制流程的路径。如果遵循这一规定，则达到了100%的路径覆盖，该度量是最强的，一般是不可实现的。
（2）语句覆盖（P1）：至少执行程序中所有语句一次。如果遵循这一规定，则达到了100%的语句覆盖（C1表示）。
（3）分支覆盖（P2）：至少将程序中每一个分支执行一次。如果遵循这一规定，则达到了100%的分支覆盖（C2表示）。
（4）条件覆盖：每个判定中所有可能的条件取值至少执行一次。如果遵循这一规定，则达到了100%的条件覆盖。
（5）条件组合覆盖：每个判定中所有可能的条件组合取值至少执行一次。如果遵循这一规定，则达到了100%的条件覆盖。只要满足了条件组合覆盖就一定满足分支覆盖。
几种测试覆盖的基本关系：语句覆盖≤分支覆盖≤条件组合覆盖≤......≤路径覆盖
路径选取与用例设计
最小的强制性测试需求是语句覆盖率。
路径选取的一般原则：
选择最简单的、具有一定功能含义的入口/出口路径 在已选取的基础上，选择无循环的路径，选取短路径、简单路径 选取没有明显功能含义的路径，要研究该路径为什么存在事务流的测试技术是一种功能测试技术，简称事务流测试技术。
黑盒测试将软件看成黑盒子，只通过外部的输入和输出来发现软件的错误，因此黑盒测试是一种基于软件规约的测试。
事务与事务流程图
事务流程图作为表达被测软件模型的工具，有操作（类似过程块）、分支、节点、链
事务分支：事务处理将选取一个分支进行
事务并生：事务处理产生一个新事务
事务分裂：事务处理产生两个新事务
事务汇集：事务的不同活动可以汇集一处
事务吸收：一个事务可以被另一个事务“吸食”
事务结合：两个事务结合后形成一个新事务
事务流测试技术的应用
采用事务流测试技术进行软件测试的步骤：
获得事务流程图
浏览、复审
用例设计
测试执行
等价类划分★
等价类划分方法是把软件所有可能的输入数据域划分为若干部分，形成一些等价类；从每个划分块中抽取代表性的数据进行测试等价于该划分块中任何数据的测试。
（1）划分等价类：有效等价类、无效等价类
确定等价类的参考原则：
输入条件规定了输入数据的取值范围，则可以确定一个有效等价类和两个无效等价类。
输入条件规定了输入数据的个数，则可以确定一个有效等价类和两个无效等价类。
输入条件规定了输入数据的可能取值，则可以确定一个有效等价类和一个无效等价类。
输入条件是一个布尔值，则可以确定一个有效等价类和一个无效等价类。
输入条件规定了必须符合的条件，则可以确定一个有效等价类和一个无效等价类。
若在以划分的某一等价类中各元素在程序中的处理方式不同，则将此等价类划分为更小的等价类。
（2）测试用例设计
为每一个等价类规定唯一的编号。
设计一个新的测试用例，使其尽可能多的覆盖未被覆盖的有效等价类；重复这一步，直到所有的有效等价类都被覆盖。
设计一个新的测试用例，使其仅覆盖一个未被覆盖的无效等价类；重复这一步，直到所有的无效等价类都被覆盖。
某些程序对输入错误的检查往往会屏蔽其他输入错误的检查。
边界值分析
边界值分析是一种常用的黑盒测试技术。测试工作表明，大量的错误经常发生在输入或输出范围的边界上；因此，使用等于 、小于或大于边界值的数据对程序进行测试，发现错误的概率更大。在设计测试用例时应选择一些边界值，这就是边界值分析测试技术的基本思想。
设计测试用例的原则：
如果某个输入条件规定了输入值的范围，则应选择正好等于边界值的数据，以及刚刚超过边界值的数据作为测试数据。
如果某个输入条件规定了值的个数，则可用最大个数、最小个数、比最大个数多1、比最小个数小1的数据作为测试数据。
根据规格说明的每个输出条件，使用第一个原则。
根据规格说明的每个输出条件，使用第二个原则。
如果程序的规格说明中，输入域或输出域是有序集合，经常选取集合中的第一个元素和最后一个元素作为测试用例。
如果程序中使用了内部数据结构，则应当选取这个数据结构边界上的值作为测试用例。
边界值分析与等价类划分的区别：边界值分析着重于边界的测试，应选取等于、刚刚大于或刚刚小于边界的值作测试数据；等价类划分应选取等价类中的典型值或者任意值作为测试数据。
因果图法
是通过从用自然语言书写的功能说明表中找出因—输入条件和果—输出结果，通过因果图将功能说明转换成一张判定表，然后为每种输出条件的组合设计测试用例。
单元测试主要检验软件设计的最小单元——模块，该测试以详细设计文档为指导，测试模块内的重要路径。采用白盒测试技术。
单元测试考虑模块的4个特征：
模块接口局部数据结构重要的执行路径错误的执行路径单元测试中，模块不是一个独立的单元，要为每个模块开发驱动模块和承接模块。
驱动模块：调用被测模块的模块
承接模块：被测模块调用的模块
集成测试的目标是发现与接口有关的错误，将经过单元测试的模块构成一个满足设计要求的软件结构。
集成测试可由“自顶向下”地进行，称为自顶向下的集成测试；也可以“自底向上”地进行，称为自底向上的集成测试。
有效性测试是发现软件的功能与需求规格说明书不一致的错误。采用黑盒测试技术。
总结：
测试步骤测试对象测试方法测试内容特点单元测试模块白盒模块的接口、局部数据结构、重要的执行路径、错误的执行路径
驱动模块、承接模块集成测试模块的组装、模块的接口黑盒模块的接口 有效性测试是否符合用户可见的文档黑盒软件的功能与需求规格说明书的一致性 系统测试软硬件的协作、系统的性能黑盒过程图解：
软件生存周期是软件产品或系统的一系列相关活动的全周期。从形成概念开始，历经开发、交付使用、在使用中不断修订和演化，直到最后被淘汰，让位于新的软件产品。
国际标准化组织于1995年发布《ISO/IEC软件生存周期过程12207-1995》，该标准针对“什么需要去做”这一需要，描述了软件过程及活动和任务，回答了软件开发需要做哪些基本“映射”。
该标准按过程主题把软件生存周期过程分为3类：
基本过程：与软件生存直接相关的活动集
获取过程
供应过程
开发过程
运行过程
维护过程
支持过程：有关各方按它们的目标所从事的一系列相关支持活动集
文档过程配置管理过程质量保障过程验证过程确认过程联合评审过程审计过程问题解决过程组织过程：与软件生产组织相关的活动集
管理过程基础设施过程培训过程改进过程软件生存周期过程是软件生存周期中的一系列相关过程。
为了表述软件开发需要做什么活（映射）引入过程、活动、任务3个术语。
过程是软件生存周期中活动的一个集合，活动是任务的一个集合，而任务是将输入变换为输出的操作。
过程类→过程→活动→任务
在《ISO/IEC系统与软件工程——软件生存周期过程12207-2008》标准中把软件生存周期过程分为7个过程组。
供应过程
活动1：机遇标识
活动2：供应方投标
任务1：需求评审
任务2：做出有关投标或接受合同的决定
任务3：准备一份提案
活动3：合同协商
任务1：与获取方就提供的软件产品或服务，协商合同条文
任务2：请求对合同的修改，作为变更控制机制的一个成分。
活动4：合同执行
任务1：进行获取需求评审
任务2：定义或选择一个适合项目范围、粒度和复杂性的生存周期模型。
任务3：
……
软件实现过程
活动：软件实现策略
任务1：开发人员选择合适的生存周期模型
任务2：实施人员
任务3：实施人员选择合适的标准、方法、工具和编程语言
任务4：开发进行该过程活动的计划
任务5：对不用交付的软件项的处理。
软件需求分析过程
软件确认过程
软件验证过程
软件体系结构设计
是对标准《ISO/IEC系统与软件工程-软件生存周期过程12207-2008》的应用说明。
系统和软件
软件是整个系统的组成部分。
区分系统需求分析和软件需求分析。
与《ISO/IEC系统生存周期15288》的关系
当系统中包括非常重要的非软件因素时，要应用《ISO/IEC系统生存周期15288》。
组织层和项目层
项目可能由组织执行
过程之间的时序关系
没有明确过程、活动、任务之间的时间依赖的序列。
支持活动之间的迭代和再现。
过程分解
把过程划分为一些小的“片段”
生存周期模型和阶段
剪裁
软件生存周期模型是一个包括软件产品开发、运行和维护中有关过程活动和任务的框架，覆盖了从该系统的需求定义到系统的使用终止。
自上而下具有相互衔接的固定顺序。
每一阶段的输入，即工作对象以及本阶段的工作成果，作为输出传送到下一阶段。
瀑布模型的贡献（优点）：
在决定系统怎样做之前存在一个需求阶段，它鼓励对系统做什么有一个规约。在系统构造之前有一个设计阶段，它鼓励规划系统结构每一阶段都有评审，允许获取方和用户的参与前一步作为下一步被认可的、文档化的基线，并允许基线和配置早期接受控制。瀑布模型存在的问题：
要求客户能够完整、正确和清晰地表达他们的需求，并要求开发人员一开始就理解这一应用。由于需求的不确定性，使设计、编码和测试阶段都可能发生延期，并且当项目接近结束时，出现了大量的集成和测试工作。在开始的阶段中，很难评估真正的进度状态，并且直到项目结束之前都不能演示系统的功能。在一个项目的早期阶段，过分地强调了基线和里程碑处的文档，并可能需要花费更多的时间用于建立一些用处不大的文档。瀑布模型适用情况：
需求已被很好的理解和定义过程设计人员也很清楚：开发组织非常熟悉为实现这一模型所需要的过程。在给出整个系统需求的体系结构的基础上，首先完整地开发系统的一个初始子集，如包含需求子集{1，2，5，9}的版本，发布并于运行；然后，根据这一子集建造一个更加精细的版本，如包含需求子集{{1，2，5，9}，{3，6，4，10，7，11}}的版本，如此不断地进行系统的增量开发。
增量模型适用于“技术驱动”的软件产品开发。
增量模型的优点：
第一个可交付版本所需要的成本和时间是较少的，从而可减少开发由增量表示的小系统所承担的风险。由于很快发布第一个版本，因此可以减少用户需求的变更。允许增量投资，即在项目开始时可以仅对一个或两个增量投资。增量模型的缺点：
如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定。如果需求不想早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布。由于进度和配置的复杂性，可能会增大管理成本，超出组织的能力。增量模型的适用情况：
在开始开发时，需求很明确，且产品还可被适当分解为一些独立的，可交付的软件。在开发中，期望尽快提交其中的一些增量产品。演化模型主要针对事先不能完整定义需求的软件开发。
用户提出待开发系统的核心需求，软件开发人员首先开发一个核心系统并投入运行；用户提出反馈（精化系统、增强系统能力的需求）；接着，软件开发人员根据用户反馈实施开发的迭代过程；每一迭代过程由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集；如果在一次迭代中有的需求不能满足用户，可在下一次迭代中修正。
该模型可以表示为：
第一次迭代(需求->设计->实现->测试->集成)->反馈->第二次迭代(需求->设计->实现->测试->集成)->反馈->……
实际上，这个模型可看作是重复执行的多个“瀑布模型”。 一旦理解需求，就可以像实现瀑布模型那样开始设计和编码。
演化模型的不足：
即使很好的理解需求或设计，也很容易弱化需求分析阶段的工作。
螺旋模型是在瀑布模型和演化模型的基础上，加入两者所忽略的风险分析所建立的一种软件开发模型。
4个方面的活动：
制定计划——确定软件目标，选定实施方案，弄清软件开发的限制条件风险分析——分析所选方案——考虑如何识别和消除风险实施工程——实施软件开发客户评估——评价开发工作，提出修正意见沿螺旋线自内向外每转一圈便开发出一个更为完善的、新的软件版本；每一圈螺旋线的风险分析后，作出是否继续下去的判断。如果风险太大，开发者和用户无法承受，项目就可能会终止。多数情况下沿螺旋线的活动会继续下去，自内向外逐步延申，最终得到所期望的系统。
如果对所开发的项目的需求已有了较好的理解或较大的把握，便可以采用普通的瀑布模型，就只需要经历单圈螺旋线；如果对所开发的项目需求理解较差，就要经历多圈螺旋线。
与演化模型和增量模型相比，同样使用了瀑布模型作为一个嵌入的过程，即分析、设计、编码、实现、维护的过程，并在框架和全局体系结构方面是等同的。
螺旋模型的适用场景：项目的开发风险很大或客户不能确定系统的需求。
以用户需求为动力，以对象为驱动的模型，主要用于采用面向对象技术的软件开发项目，体现了软件创建所固有的迭代和无间隙的特征。
过程规划与管理是软件项目管理的一项重要工作。把过程管理称为软件生存周期管理过程，包括过程建立、过程评估、过程改进，强调了过程规划（P）、过程检测（C）、过程执行（D）、过程调整（A）。
上一章主要内容是如何管理一个项目的生存周期过程，包括过程建立与监控。对于软件开发组织而言，更关心整个组织过程改善的问题。
CMMI的目的：帮助软件企业对软件工程进行管理和改进，增强开发与改进功能，从而能按时，不超预算地开发出高质量的软件。
该模型基于过程途径思想，通过过程把软件质量的3个支撑点——受训的人员、规程和方法、工具和设备进行集成，以开发所期望的系统/产品。
软件CMM、产品集成开发CMM、系统工程CMM
CMMI是一种过程改善框架。
是指人为设计的一个活动程序，其目的是改进组织的过程性能和成熟度，并改进这一程序的结果。
一个业务域中一束相关的实践，当它们一起得以实现时，就满足被认为对该过程域的改善具有重要作用的一组条件。
CMMI有22个过程域，分为四类。
过程域类名
包括的过程域
项目管理类
规划、监控、定量项目管理、集成项目管理、风险管理、提供方协议管理
工程类
需求开发、需求管理、技术解决方案、产品集成、确认、验证
支持类
配置管理、过程和产品质量保证、测量与分析、原因分析与解决、决策分析与解决
过程管理类
组织过程定义、组织过程性能、组织过程培训、组织过程关注、组织创新与部署
CMMI引入两种类型的“等级”：能力等级、成熟度等级，描述了两种过程改善的演化路径。
能力等级是一种过程改善路径，该路径可使组织针对单一过程域不断改善该过程域。
0级： 未完成级
1级：已执行级
2级： 已管理级
3级： 已定义级
4级： 已定量管理级
5级： 持续优化级
成熟度等级也是一种过程改善路径，该路径可使组织通过关注一组过程域不断改善一组相关的过程域。
CMMI的阶段式表示模型定义了5个成熟度等级，在持续的过程改进上，每一等级都是构成下一阶段基础的一个层次，这些等级用从1到5的数字表示。
1级：初始级
2级： 已管理级
3级： 已定义级
4级： 已定量管理级
5级： 持续优化级
为了达到成熟度2级，2级中所包含的所有过程域必须达到能力等级2级或更高级。
为了达到成熟度3级，2级、3级中所有过程域必须达到能力等级3级或更高级。
为了达到成熟度4级，2级、3级、4级中所有过程域必须达到能力等级4级或更高级。
为了达到成熟度5级，所有过程域必须达到能力等级5级或更高级。
两个过程域：项目规划过程域（2级）和需求开发过程域（3级）。
