软件生存周期
- 可行性分析，可行性分析报告和项目开发计划
- 需求分析，软件需求说明书，确定软件的综合要求：系统界面，系统功能，系统性能，安全性，保密性和可靠性方面的要求，系统的运行要求、异常处理、将来的扩充和修改等；分析软件系统的数据要求，基本数据元素，数据元素之间的逻辑关系，数据量，峰值等；导出系统的逻辑模型，修正开发计划
- 概要设计，输出概要设计文档，把各个确定的各向功能需求转换成需要的体系结构，每个成分都是意义明确的模块，每个模块和需求相对应。因此概要设计就是设计软件的结构，明确软件由哪些模块组成，这些模块的层次结构是怎么样的，这些模块的调用关系，每个模块的功能；还要设计总体数据结构和数据库结构，数据之间的关系
- 详细设计，对每个模块完成的功能进行具体描述，要把功能描述转换成精确的结构化的过程描述，并用响工具把这些结构表示出来
- 编码，把每个模块的控制结构转换成计算机可接受的程序代码，即写成某种特定程序设计语言表示的程序清单
- 测试，测试计划，测试用例和测试报告
- 维护，生命周期中最长的，负责软件的安装，维护，需要对软件修改，适配，扩充和增强还有就是为了未来的维护活动预先准备。
软件的性能
- 可测试性，表示测试及验证软件的难易度
- 可理解性，软件能够被软件维护人员阅读并理解的方便程度
- 可靠性，软件按规定的条件，在规定的时间内运行而不发生故障的能力
- 可移植性，软件从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度
- 可用性，产品在特定使用环境下为特定用户用于特定用途时所具有的有效性，效率和用户主观满意度，其中有效性指用户完成特定任务和达到特定目标是所具有的正确和完成程度；效率指用户完成任务的正确和完整程度与所用资源之间的比，满意度指用户在使用产品过程中所感受到的主观满意和接受程度
- 兼容性，软件可以从某一环境转移到另一环境的能力有关的一组属性，包括：与软件无须采用为软件准备和活动或手段就可以使用不同的规定环境有关的软件属性；使软件遵循与可移植性有关的标准或约定的软件属性；与软件在该软件环境中用来替代指定的其他软件的机会和努力有关的属性
- 修改性：软件能够被维护人员修改的方便程度
- 一致性：软件服从与可移植性有关的标准或约定的程度
结构化分析方法
- 结构化分析方法是一种面向数据流的软件分析方法，适合于开发数据处理类型软件的需求分析。数据流图数需求分析阶段使用的一种主要工具，他以图形的方式表达数据处理系统中信心变化和传递过程。与数据流图配合的是数据词典，它对数据流图中出现的所有数据元素给出逻辑定义。有了数据词典，使得数据流图上的数据流，加工和文件得到解释。数据流图上可能出现四种符号，数据流，加工，数据存储，外部实体（数据源以及数据终点）。
- 数据流是具有名字和流向的数据，用标有名字的带箭头表示
- 加工是对数据的加工，用圆圈表示
- 数据存储是可访问的存储信息，用直线段表示
- 外部实体位于被建模系统之外的信息产生者或消费者，用方框表示
内聚与耦合
- 高内聚低耦合是软件合计的一个原则，内聚指模块内部各个元素之间的紧密程度也就是代码的集中程度，耦合指模块之间的相互联系的紧密程度
内聚
- 内聚度从高到低排序
- 功能内聚，完成一个单一功能，各个部门协同工作，缺一不可
- 顺序内聚，处理元素相关，而且必须顺序执行
- 通信内聚，所有处理元素集中在一个数据结构的区域上
- 过程内聚，处理元素相关，而且必须按特定的次序执行
- 瞬时内聚，所包含的任务必须在同一时间间隔内执行
- 逻辑内聚，完成逻辑上相关的一组任务
- 偶然内聚，完成一组没有关系或松散关系的任务
耦合
- 耦合程度从低到高
- 非直接耦合，没有直接联系，互相不依赖对方
- 数据耦合，借助参数表传递简单的数据
- 标记耦合，一个数据结构的一部分借助于模块结构被传递
- 控制耦合，模块间传递的信息中包括用于控制模块内部逻辑的信息
- 外部耦合，与软件以外的环境有关
- 公共耦合，多个模块引用同一个全局数据区
- 内容耦合，一个模块访问领一个模块的内部数据，一个模块不通过正常入口转到领一个模块内部，两个模块有一部分程序代码重叠，一个模块有多个入口
能力成熟度模型CMM
- 初始级，过程无秩序，有时甚至是混乱的，项目的成功往往依赖于个人的努力和机遇
- 可重复级，已经建立了基本的项目管理过程，可用于对成本，进度和功能特征进行跟踪，对于类似的项目，有章可循并且可以重复以往所取得的成功，焦点集中在软件管理过程上，。从管理的角度看是一个按计划执行的，阶段可控的软件开发过程。
- 已定义级，用于管理和工程的软件均已文档化，标准化，并形成整个软件组织的标准软件过程，全部项目均采用与实际情况温和的，适当修改后的标准软件过程。所有开发的项目需要根据这个标准过程，裁剪出项目适宜的过程，并执行这些过程。过程的裁剪不是随意的，需要经过企业相关人员的批准。
- 已管理级，软件过程和产品质量有详细的度量标准，软件过程和产品质量得到了定量的认识和控制
- 优化级，通过对来自过程，新概念和新技术等方面的各种有用信息的定量分析，能够不断地持续的进行过程改进
能力成熟度模型集成（CMMI）
阶段式模型
- 初始的
- 已管理的
- 已定义的
- 定量管理的
- 优化的
连续式模型
- CL0(未完成的)，过程中未执行或未达到CL1中的定义的所有目标
- CL1（已执行的），其共性目标是过程可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标
- CL2（已管理的），其共性目标集中于已管理的过程的制度化，，根据组织和政策规定过程的运作将使用哪个过程，项目遵循已文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有的工作任务和工作产品都被监控，控制和评审
- CL3（已定义的），其共性目标集中于已定义的过程的制度化，过程是按照组织的剪裁指南从组织的标准过程几种剪裁得到的，还必须手机过程资产和过程的度量，并用于将来对过程的改进
- CL4（定量管理的），其共性目标集中于可定量管理的过程的制度化。
- CL5（优化的），使用量化手段改变和优化过程域，以满足客户要求的改变和持续改进计划中的过程域的功效。
ISO/IEC9126的软件质量模型
- 六个质量特性和21个质量子特性
功能性
- 软件所具有的各项功能及其规定性质有关的一组属性
- 适合性，与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性
- 准确性，能否得到正确的或相符的结果或效果
- 互用性（互操作性），与其他系统进行指定交互的能力
- 依从性，遵循有关标准，约定，法规及类似规定的软件属性
- 安全性，防止对程序及数据的非授权的故意或意外访问的能力
可靠性
- 在规定运行条件下和规定时间周期内，与软件维护其性能级别的能力有关
- 成熟性，与有故障引起失效的频度有关
- 容错性，在故障或违反指定接口的情况下，维持规定的性能水平的能力有关
- 可恢复性，在失效后，重建其性能水平并恢复只接受影响数据的能力有关
可用性
- 根据指定用户或隐含用户所作出的与使用软件所使用的努力程度有关
- 可理解性，用户未认识逻辑概念及应用范围所花的努力
- 易学性，用户为学习软件应用（运行控制，输入输出）有关的努力
- 可操作性，用户为操作和运行控制的努力有关
- 效率，在规定条件下，与软件性能级别和所有资源总量之间的关系有关
可维护性
- 对软件进行修改的难易程度有关
- 可分析性，为诊断缺陷或失效原因及为判定待修改的部分所需的努力
- 可改变性，与进行修改，排除错误，或适应环境变化所需的努力
- 稳定性，与修改所造成的未预料结果的风险有关
- 可测试性，与确认软件已修改所需的努力
可移植性
- 从一个环境到令一个环境运行的能力有关
- 适应性，与软件无需采用为该软件准备的活动或手段就可能适应不同的规定环境有关
- 可安装性，在指定环境下安装软件所需的努力有关
- 遵循性，使软件遵循与可移植性有关的标准或约定的属性
- 可替换性，与软件在该软件环境中替换指定的其他软件的机会和努力有关的软件属性
软件过程模型
- 瀑布模型，严格遵循软件生命周期各个阶段的固定顺序，计划，分析，设计，编程，测试和维护，上一阶段完成后才能进入下一阶段；优点是强迫开发人员采用规范的方法，规定了每个阶段必须要提交的文档；要求每个阶段后必须要进行评审；但是过于理想化，无法在开发中明确用户难以确定的需求，需要付出巨大的代价返工；适用于需求明确，二次开发等
- 喷泉模型，用于描述面向独享的开发过程，喷泉一次体现了面向对象开发的迭代和无间隙特征。迭代意味着模型中的开发活动会很多次，每次重复都会增加或明确一些目标系统的性质，但是不是对先前工作结果的本质性改动，无间隙指开发活动不存在明显的边界，而是允许各开发活动交叉迭代进行
- 快速原型，对于需求不明确的项目，比较适合，它采用了一种动态定义需求的方法，通过快速的建立一个反应用户主要需求的软件原型，一旦确定需求，就会被抛弃。
- 演化模型，也是一种原型话的开发方法，但与快速原型不同的是，在快速原型中，原型的目的是为了获得用户的真正需求，一旦需求确定了，原型被抛弃，而演化模型的开发过程，则从初始模型逐步演化成最终产品的渐进过程。是渐进式的原型化方法
- 螺旋模型，结合了瀑布和演化的有点，加入了风险分析，它是由制定计划，风险分析，实事工程，客户评估这一循环组成，他最初从概念项目开始第一个螺旋，这种开发模型将风险分析作为一个单独的阶段来做，适合大中型的软件开发项目
统一过程（UP）
- 基本特征是以用例驱动，以架构为中心的和受控的迭代增量开发，一个UP可以分为若干个周期，每个周期的开发过程分为四个阶段
- 初始阶段，确定项目的范围和边界，识别系统的关键用例，展示系统的候选架构，评估费用和时间，评估项目风险。其意图是建立范围和版本，确定实现的可能性和稳定性，提交结果包括原始的项目需求和业务用例。
- 精化阶段，分析问题领域，建立软件架构基础，滔天最高风险元素。意图是对问题域进行分析，建立系统的需求和架构，确定技术实现的可行性和系统架构的稳定性，提交包括系统架构文档，领域模型，修改后的业务用例和整个项目的开发计划
- 构建阶段，资源管理。控制和流程优化，开发剩余的构件，然后组装和测试，意图是开发一个可交付用户的软件产品
- 提交阶段，进行β测试，制作发布版本，用户文档定稿，确认新系统，获取用户反馈，培训调整产品使最终用户可以使用的产品。主要意图的交付用户。
系统转换
- 直接转换，确认新系统无误，立刻启用新系统，适合过程不太复杂，数据不很重要的系统中
- 并行转换，新老系统并行一段时间，安全可靠，但是费用和工作量都很大
- 分段转换，在新系统全部正式运行前，一部分一部分的代替老系统，要求子系统有一定的独立性，即可靠，费用不会太大
软件测试
- 尽早不断测试，贯穿于开发过程中
- 所有测试应该追溯到用户需求，从用户的角度看，最严重的错误的导致软件不能满足用户需求的错误
- 从小规模到大规模的测试
- 远在测试之前就定出测试计划
- Paret原则，80%的错误在20%的程序模块，对于发现较多错误的程序，进行深入的测试
- 由独立的第三方进行测试
- 非法和非预期的输入数据要想合法，符合预期的数据一样测试
- 检查软件做了该做的和不该做的事情
- 规划测试时不要设想程序中不会查出错误
- 测试只能证明有错误，不能证明没有错误
- 单元测试，模块测试，通常在编码阶段，检查模块是否实现了详细设计说明书中的规定的功能和算法，测试模块接口，局部数据结构，重要额执行通路，出错梳理通路，边界条件等
- 集成测试，组装测试，测试各模块组装而成的程序测试，发现模块间的接口和通信问题，验证模块间是否按照规定的方式正确工作。分为一次性组装和分块组装
- 确认测试，根据软件需求说明书检查软件的额功能，性能以及其他特征是否与用户需求一致，在需求分析阶段指定计划
- 系统测试，测试的是完整的集成的计算机系统，测试的目的是在真是系统工作环境下，验证完整的软件配置项能否和系统正确连接并满足系统设计文档和软件开发合同规定的要求。
- 白盒测试，结构测试，单元测试阶段，测试者完全知道程序的结构和处理算法
- 黑盒测试，功能测试，集成测试和确认测试阶段，完全不了解内部的结构和算法，只检查程序的功能是否能按软件需求说明书的要求正常使用，是否正确输入输出，是否保持外部数据的完整性。常用的方法等价类分析，边值分析，错误推测，因果图等
- α测试，用户在开发者的场地由开发者指导完成的测试，开发者负责记录发现的错误和使用中遇到的问题，在受控的环境中进行的
- β测试，在一个或多个用户的现场由软件的最终用户实施的，开发者不在场，用户记录问题报告给开发者，在非受控环境下进行的
- 回归测试，测试软件变更后，变更部分的正确性和变更需求的符合性，以及原有的，正确的功能，性能和其他规定的要求不损害性。只要软件发生变化，都应该进行相应回归测试。
- 黑测试中的等价类划分：等价类划分分为有效等价类和无效无效等价类，一个测试用例中只能有一个无效等价类
- 语句覆盖，每个语句至少执行一次
- 判定覆盖，分支覆盖，每个判定的每种可能得结果都要执行一次
- 条件覆盖，判定表达式中的每个条件都取到可能得结果，
- 判定/条件覆盖，判定覆盖和条件覆盖结合
- 条件组合覆盖，每个判定表达式中条件结果的所有可能组合至少出现一次，，满足这个的一定满足判定/条件覆盖
- 路径覆盖，每条可能执行到的路径都走一遍
敏捷发开方法
- 极限编程（XP）,四大价值观：沟通，简单，反馈，勇气；五大原则：快速反馈，简单性假设，逐步修改，提倡更改，优质工作；12个最佳实践：计划游戏，小型发布，隐喻，简单设计，测试先行，重构，集体代码所有制，结对编程，每周工作40小时，持续集成，编码标准和现场客户
- 水晶法（Crystal），每一个不同的项目都需要一套不同的策略、约定和方法论，认为人对软件质量有重要的影响，随着项目质量和开发人员素质的提高，项目和过程的质量也提高。通过更好的交流和经常性的交付，软件生成力得到提高
- 并列争求法（Scrum）使用迭代方法，把每30天一次的迭代称为一个冲刺，并按照需求的优先级来实现产品。多个组织和自治的小组并列的递增实现产品。协调是通过简短的日常情况会议进行
- 自适应软件开发（ASD），6个基本原则：有一个使命作为指导；特征被视为客户价值的关键点；过程中的等待是很重要的，因此重做和做同样关键；变化不被视为改正，而被根据实际情况的调整；确定的交付时间迫使开发人员认真考虑每一个版本的关键需求；风险也包含其中
- 敏捷统一过程（AUP），采用经典的UP阶段性活动，使用敏捷，尽快交付增量的版本。建模，实现。测试，部署，配置及项目管理，环境管理。
文档
- 开发文档，功能要求，投标方案，需求分析，技术分析，系统分析，数据库文档，功能函数文档，界面文档，编译手册，QA文档，项目总结
- 管理文档，产品简介，产品演示，疑问解答，功能介绍，技术白皮书，评测报告
- 用户文档，安装手册，使用手册，维护手册，用户报告，销售培训等
错误总数预估
- 计算发现错误的效率，然后用发现的错误除以效率就是总数。
软件维护
- 正确性(改正性)维护，修改交付后发现的错误
- 适应性维护，为了外部环境（硬件，软件配置），或数据环境（数据库，数据格式，输入输出方式，存储介质）或应用环境可能发生的变化，为了软件适应这种变化的改变
- 完善性维护，用户提出新的需求和性能要求，增加需求和优化性能
- 预防性维护，为了提高软件的可维护性，可靠性等而提出的一种维护类型
软件复杂度
- 环路复杂度，McCabe度量法，V = 边数 - 顶点数 + 2
风险管理
- 风险是一种不确定的事件，只要发生就会给项目带来影响。
- 风险识别，建立风险条目检查表，试图系统化的确定对项目计划的威胁，检查表可用于识别风险，并集中识别一些常见，已知的及可预测的风险
- 风险预测，又称风险估算，风险发生的概率，风险发生了所产生的后果，建立一个尺度或标准，以反映风险发生的可能性；描述风险产生的后果；估算风险对项目和产品的影响；标注风险预测的整体精准度，以免产生误解
- 风险评估，定义风险参考水平，预测影响参考水平值的风险组合
- 风险控制，风险避免，风险监控，风险管理及意外计划
软件危机
- 指在软件开发和维护中所遇到的一些列严重问题
- 造成原因有：软件本身特点，缺乏好的开发方法和手段，开发效率低
- 表现在：需求得不到满足，成本高，价格贵，进度无法控制，需求定义不准确，质量不保证，可维护性差
项目活动图
- 关键路径，从起点到终点时间最长的路径
- 松弛时间，最晚开始时间减去最早开始时间，如果在关键路径上，松弛时间是0，否则找到一条最长的路径，与关键路径的时间差就是松弛时间