文章目录
一、软件开发模型
1.1 瀑布模型（SDLC）
瀑布模型渐渐淡出人们视线，已经基本淘汰。因为有重大缺陷，足以导致项目失败。
瀑布模型强调文档化、标准化，是一个结构化方法的模型，把结构化方法的特点表现的淋漓尽致。
瀑布模型还加了回溯通道，这个阶段遇到问题可以回到上一个阶段把问题解决再往下进行：
其缺陷的根本原因在于其需求分析阶段，因为需求在项目初期就完全明确是几乎不可能的，当整个项目走到最后阶段，可能此时用户需求变化，就会导致推翻了之前全部的工作。此时要回到需求分析阶段重新开始。这使得瀑布模型难以完成项目。
瀑布模型适用于需求明确或者是二次开发。（强调必须完全明确需求的项目）
1.2 其他经典模型（原型模型、增量模型、演化模型）
瀑布模型问世以后，引起大家对模型的追逐，产生了其他模型，为了比年重蹈瀑布模型的覆辙，其他模型试图避免了瀑布模型的缺陷。
原型和瀑布模型是一对相当互补的模型，瀑布模型败在无法对需求变化灵活的应对，而原型就是定位于需求不明确的情况。原型强调在项目开始初期，建立一个简易系统（比如一个界面，按钮设计等，或者是初步的系统），从而可以用建议模型拿来给用户做演示，按照用户需求对系统进行调整。但是原型往往只应用于开发需求分析的阶段，如果将原型通过演化，最终成为软件产品，则这种模型就是演化模型。
螺旋模型也是从原型发展来的，还有瀑布模型和演化模型的特征。
增量模型结合了瀑布模型和原型的思想，作系统的时候先把用户的核心需求做出来，将做好的系统拿给用户使用，修正用户提出的问题，然后把修正好的模型加上核心模块外的若干模块后，再给用户使用，再改进，这就是增量模型。强调的是一个模块一个模块的做下去，并且每一次核心模块都会被用户体验并给出修正意见，风险较小。
1.3 螺旋模型
螺旋模型是右侧的模型，结合了多个模型的特征，比如原型，瀑布模型，演化模型等。
如果有一个需求不明确的项目，选择开发模型，那么选择原型，而不是螺旋模型，即使它包括了原型的特征，但是原型是专门针对不确定需求产生的，要选择最匹配的选项。如果没有原型选项，可以选择螺旋模型。
螺旋模型的特点除了融合了多种模型外，是引入了风险分析。
1.4 V模型
从需求到单元测试这部分来看，和瀑布模型比较接近，但是在这个模型中，测试细化到了单元、继集成、系统、验收。V模型中，需求和相应的验收测试有着一些对应关系。在需求分析阶段，就会写验收测试和系统测试的测试计划了，这是为了提早发现问题，不像瀑布模型一样发现问题时已经来不及了。
概要设计阶段，写集成测试的测试计划，集成测试就是测试各模块之间的衔接。
详细设计阶段写单元测试的测试计划
由此可见V模型是强调测试的模型，提前写测试计划，提早发现问题。
1.5 喷泉模型与RAD
喷泉模型最大的特点是面向对象的。
因为老一辈模型都是结构化方法下的，正因为喷泉模型是面向对象的，所以它具有迭代和无间隙的特点。
RAD是快速开发模型，由喷泉模型（SDLC）和构件组装模型（CBSD）组合而成的模型。用可视化工具做开发，就已经是RAD模型了。最大的特点是可以快速构建应用系统。
1.6 构件组装模型（CBSD）
该模型得到了越来越广泛的认可与应用。考虑把每个模块做成标准的构件，进行组装后得到软件。极大的提高了软件开发的复用性，可以是软件的开发时间缩短，降低开发成本，提高软件可靠性（每个构件都已经经过长时间的考验）。
1.7 敏捷开发方法
敏捷开发方法包含了一系列模型，目的是为了给开发人员减负。会议短平快，小型版本发布。
敏捷开发方法适用于做小型项目，中型大型项目不适用。适用于小步快跑的方式完成项目。、
实践包括结对编程，集体代码所有制，测试先行等等，这些开放性思路在国外应用的还不错，但是在国内社会是不太认可的。
二、信息系统开发方法
信息系统开发方法主要有四种
结构化方法在以前很普遍。被面向对象方法渐渐取代的原因是：一旦开发完成，流程是固化的，不灵活的。比如开发了财务系统，公司壮大后决定任命一个财务总监，于是公司星期五开会说财务部门进行调整并且任命了财务总监，财务流程也进行一些调整，周一正式施行。在会议中和财务部门中，这些流程的改变对于每个人都很容易。会议结束，开发部门对开发人员开会，会议提到的新财务流程大家清楚了，我们要让系统支持上，周末加班把系统改好。到此为止一切都很简单。开发团队主管会很头疼，系统涉及的面很多，和其他功能的衔接不能随意改动，一旦改动，需求就变了，需求变了设计要变，设计变了编码要变，编码变了还要做测试。这就是结构化方法最大的弊端。
原型法主要用在开发的需求阶段。适用于需求不明确的开发，补的是结构化方法的缺陷。
面向对象方法目前十分普遍。可以把项目中涉及的人和物等抽象为对象。这样开发的系统有更好的复用性。其分析，设计，实现三个阶段界限是不明显的。
面向服务方法：整个体系还不是很成熟，在发展中。
三、需求工程
兴奋需求要谨慎去做，可能徒增成本。
四、系统设计
4.1 结构化设计
结构化设计就是结构化方法中的软件设计，主要分概要设计和详细设计。要求信息隐蔽。模块独立性越强系统越灵活。
调用的深度越深，出错可能性越大。
扇入多说明其他模块调用这个模块的数目多，价值高。扇出多，说明这个模块的职能太多，是不好的现象。
内聚就是模块内部各个部件连接的紧密程度，越高越好。
耦合是模块与模块之间紧密程度，越低越好。
上表为内聚和耦合排序表，内聚是从高到低排序，耦合是从低到高排序。
掌握图b，模块分为传入型，变换型，传出型，变换型是双向箭头。
五、软件测试
5.1 测试原则与类型
5.2 测试用例设计
黑盒测试，不知道内部结构，只知道输入和输出。
白盒测试，时可以看到结构的。
白盒测试往往比黑盒测试要更全面。黑盒为了让测试更全面，有如图的几种方法。
黑盒的等价类划分：考虑模块处理的功能相关的数据，哪些数据可以归为一类。比如模块是计算成绩的，那么我们可以把测试用例在优良及格和不及格的大致分数（比如95，88，63，8）作为用例。
边界值分析：测试边界值，比如等价类划分中判定优是90分以上，良90分以下，则90分就发生了问题。所以要进行边界值分析。应用的时候，一般是等价类划分和边界值分析结合起来使用。边界值分析需要注意的是边界值的选取，比如一个程序要求对人的年龄的值的范围要求是0到150，那么边界值分析选取的是-1，0，150，151，而1和149不需要选取。
错误推测：强调的是一种经验。按照经验进行测试。
因果图：由果分析因。
白盒的基本路径测试，循环覆盖测试和逻辑覆盖测试，主要了解逻辑覆盖测试。
逻辑覆盖包括语句覆盖，判定覆盖等。语句覆盖是层次最低的，即所有语句都覆盖。判定覆盖是把所有的分支都覆盖。条件覆盖判定的条件各情况被覆盖。*别是路径覆盖，即所有路径都被测试。
5.3 测试阶段
确认测试和系统测试顺序不确定。但是确认测试往往是最后一步，包含了验收。
单元测试：关注的是模块。
集成测试：模块的接口的衔接。组装包括一次性或增量式，增量式工作量大但是稳妥。
确认测试：测试的是需求。Alpha测试和Beta测试是针对产品，Alpha是在实验室环境测试，Beta测试是用户测试。
系统测试：偏重压力和性能测试（负载，强度，容量）。
5.4 McCabe复杂度
此知识点几乎每次都考。
环路复杂度公式如上，m是边，n是点。
注意：分叉处可以抽象为结点，也可以把分叉处”解开“，比如2，3，4，都可以画出三条不相交的先线连到7处。两种情况复杂度计算结果是一样的。
六、系统运行与维护
维护阶段是项目周期中占时间最长的，要确保系统能够正常运行。
可分析性：代码容易看懂。
可改变性：代码修改起来的容易程度，涉及代码的模块间耦合性。
可测试性：测试是否方便。
改正性维护（正确性维护）：软件中总会有一些bug，到用户手里被发现，改正该bug为改正性维护。
适应性维护：例如应用程序由于系统环境的升级而导致的一些小问题，需要适应性维护。数据环境发生变化，也需要适应性维护。
完善性维护：系统运行过程中，很多东西发生改变，需要扩充功能并提升性能，这是完善性维护。
预防性维护：做预防工作。例如千年虫问题，在2000到来之前紧急维护，就属于预防性维护。
七、软件能力成熟度模型的集成（CMMI）
CMMI是CMM（软件能力成熟度模型）发展来的，主要用来衡量软件开发承包商改善软件质量的能力。
阶段式分级：1是混乱级，没有通过CMMI评级都是一级。上图给出二三四五级。
八、项目管理基础知识
主要考察时间管理和风险管理的概念
甘特图不能表达各任务之间的依赖关系。
pert图的最长路径就是这个项目的最短周期。
本题应该正推把所有最早开始时间推出来，再反推最晚时间。
风险关心未来的变化和选择。