软件开发模型
- 瀑布模型（SDLC）：适用于需求明确或二次开发的项目
理想化的开发模型，要求有明确的需求分析，而要达到这一点在现实开发中几乎不开能
结构化模型的代表，线性开发：软件计划→需求分析→软件设计→程序编程→软件测试→运行维护 - 原型模型：适用于需求不明确的项目
项目开发初期，构造一个软件原型，通过调整原型使其满足客户要求，一旦确定真正需求，原型将被丢弃 - 演化模型：适用于对需求缺乏准确认识的项目
从初始的原型逐步演化成最终软件产品 - 增量模型：适用于可以分批次地进行软件产品交付的项目
将待开发的软件系统模块化，先做实现基本需求的核心模块，交付用户使用后，根据用户需求不断增量，调整，直到完善 - 螺旋模型：适用于大型复杂的项目
结合了瀑布和演化的优点，加入了风险分析
沿着螺线进行若干次迭代（制定计划→风险分析→实施工程→客户评估），从概念项目开始第一个螺旋 - 喷泉模型：适用于面向对象的软件项目
面向对象的模型，以用户需求为动力，以对象为驱动的模型，使开发具有迭代性和无间隙性 - V模型：适用于传统信息系统应用的项目
强调了软件开发过程中若干个测试级别
在需求分析的时候，写验收测试和系统测试，可以提早发现问题；
在概要设计的时候，写集成测试的测试计划；
在详细设计的时候，写单元测试的测试计划 - 快速应用开发（RAD）：适用于系统模块化程度较高的项目，不适合技术风险很高的情况
业务建模→数据建模→过程建模→应用生成→测试与交付 - 迭代模型：适用于需求难以确定，不断变更的项目，采用迭代开发方法
- 构件组装模型（CBSD）：
基于构件的开发方法，提高了软件开发的复用性，可靠性强
需求分析和定义→软件架构设计→构件库的建立→应用软件构建→测试和发布 - 统一过程（UP）：适用于大型项目
用例驱动，以架构为中心，迭代和增量
初始→细化→构建→交付 - 敏捷开发方法：适用于小型项目，是一种以人为核心、迭代、循序渐进的开发方法
- 极限编程（XP）：一种轻量级的开发方法，激发开发人员创造性、使得管理负担最小的一组技术
- 4大价值观：沟通、简单、反馈、勇气
- 5大原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作
- 12个最佳实践：
- 计划游戏（快速制定计划、随着细节的不断变化而完善）
- 小型发布（系统的设计要能够尽可能早地交付）
- 隐喻（找到合适的比喻传达信息）
- 简单设计（只处理当前的需求，使设计保持简单）
- 测试现行（先写测试代码，然后再编写程序）
- 重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）
- 结队编程
- 集体代码所有制
- 持续集成（可以按日甚至按小时为客户提供可运行的版本）
- 每周工作40个小时
- 现场客户
- 编码标准
- 水晶法：强调经常交付，认为每—个不同的项目都需要一套不同的策略、约定和方法论
- 并列争球法：核心是迭代、增量交付，按照30天进行迭代开发交付可实际运行的软件
- 使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”， 并按需求的优先级来实现产品，多个自组织和自治的小组并行地递增实现产品
- 自适应软件开发：核心是三个非线性的，重迭的开发阶段：猜测、合作、学习
- 6个基本原则：
- 有一个使命作为指导；
- 特征被视为客户价值的关键点；
- 过程中的等待是很重要的，因为“重做”与“做”同样关键；
- 变化不被视为更改，而是被视为对软件开发实际情况的调整；
- 确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；
- 风险也包含其中
- 6个基本原则：
- 极限编程（XP）：一种轻量级的开发方法，激发开发人员创造性、使得管理负担最小的一组技术
软件开发方法
| 方法 | 特点 |
| 结构化开发方法 | 面向数据流的开发方法 总的指导思想是：自顶向下，逐层分解 基本原则是功能的分解与抽象 特别适合于数据处理领域的问题，但是不适合解决大规模的，特别复杂的项目，且难以适应需求的变化 |
| Jackson | 面向数据结构的开发方法 JSP以数据结构为驱动，适合于小规模的项目。但输入数据结构与输出数据结构没有对应关系时，这种方法难以胜任。 JSD以事实为驱动，是一种基于进程的开发方法，所以适应于时序特点较强的系统，包括数据处理系统和一些实时控制系统 |
| 原型方法 | 适用于需求不明确的开发 包括抛弃式原型和演示化原型 当系统规模不是很大也不是很复杂时，采用此方法比较合适 |
| 面向对象方法 | 更好的复用性 关键在与建立一个全面、合理、统一的模型 分析、设计、实现三个阶段，界限不明确 |
| 面向服务方法 | SO方法有三个主要的抽象级别：操作、服务、业务流程 SOAD分为三个层次：基础设计层(底层服务构件)、应用结构层(服务之间的接口和服务级协定)和业务组织层(业务流程建模和服务流程编排) 服务建模：分为服务发现、服务规约和服务实现三个阶段 |
软件测试
基础知识
测试目标：以尽可能少的时间和人力发现软件产品中尽可能多的错误
测试用例：由测试数据和预期结果构成
测试过程：制定测试计划→编制测试大纲→生成测试用例→实施测试→生成测试报告
黑盒测试
黑盒测试又称功能测试。它把软件看做一个不透明的黑盒子，完全不考虑（或不了解）软件的内部结构和处理算法，它只检查软件功能是否能按照软件需求说明书的要求正常使用，软件是否能适当地接收输入数据并产生正确的输出信息，软件运行过程中能否保持外部信息（例如文件和数据库）的完整性等。
常用的黑盒测试技术
- 等价类划分：将所有可能的输入数据，划分为若干子集，然后从每一个子集中选取少数具有代表性的数据作为测试用例
- 边界值分析：对等价类划分的一个补充，即选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据
- 错误猜测：列举出软件中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例
- 因果图：根据输入条件与输出结果之间的因果关系来设计测试用例
白盒测试
已知产品的内部工作过程，通过测试证明每种内部操作是否符合设计规格要求（将软件比做一个透明盒子，里面的一切我们都看的清楚，可以通过测内部结构来判断）
测试方法
基本路径测试
循环覆盖测试
逻辑覆盖测试（由低到高）
语句覆盖：冒泡排序只要一个用例就可以达到语句覆盖
判定覆盖
条件覆盖
判定-条件覆盖
条件组合覆盖
路径覆盖：设计足够的测试用例，覆盖软件中所有可能的路径
使用 McCabe 度量法计算路径复杂度：V(G)=m-n+2
其中V(G)是有向图G中的环路个数，m是边数，n是顶点数，一般用环路数V(G)来表示程序复杂性。
测试阶段
- 单元测试（模块测试）【白盒为主，黑盒为辅】
一般是在编程阶段完成，由程序员自行测试编写的模块，检查模块是否实现了详细设计说明书中规定的功能和算法
测试内容：模块接口、局部数据结构、重要的执行通路、错误处理、边界条件
驱动模块：相当于所测模块的主程序，它接收测试数据，把这些数据传送给所测模块，最后再输出实际结果
桩模块：用以代替所测模块调用的子模块 - 集成测试（组装测试）【黑盒测试】
在单元测试的基础上，将所有模块按照概要设计说明书的要求进行组装
测试目的：发现模块间的接口和通信问题，发现设计阶段产生的错误
一次性组装方式：一次性组装所有模块进行测试
增量式组装方式：将模块逐步组装成系统，有自顶向下（需要桩模块）、自底向上、混合式 - 确认测试【黑盒测试】
检查软件的功能、性能和其他特征是否与用户的需求一致
测试步骤：有效性测试→软件配置审查→验收测试
Alpha测试：公司内部人员模拟各类用户对即将面市的软件产品进行测试，试图发现错误并修正
Beta测试：由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者 - 系统测试【黑盒测试】
把软件放在实际的硬件和网络环境中进行测试，检查软件的非功能需求和质量属性是否得到满足
测试内容：恢复测试、安全性测试、强度测试、性能测试、可靠性测试、安装测试
回归测试：修改了旧代码后，重新测试，确认修改没有引入其他错误或导致原有代码错误
软件维护
可维护性
易分析性：为判定软件修改所需的努力
易改变性：进行修改，适应环境变化所需的努力
稳定性 ：与修改造成的风险后果相关
易测试性：与确认修改所需的努力
提高可维护性
软件开发各个阶段都充分考虑维护问题
使用面向对象方法
结构化设计中注意模块化、信息隐蔽、高内聚、低耦合等问题
编写软件开发文档以及形成良好的编程风格
维护类型
改正性维护：修复错误（25%）
适应性维护：适应环境（20%)
完善性维护：增加功能，提高性能（50%)
预防性维护：为以后增加功能准备(5%)
软件过程改进
CMM
描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准
初始级→可重复级→已定义级→已管理级→优化级
| 等级 | 管理方面 | 组织方面 | 工程方面 |
| 优化级 | 技术改进管理 过程改进管理 |
缺陷预防 | |
| 已管理级 | 定量管理过程 | 软件质量管理 | |
| 已定义级 | 集成软件管理 组间协调 |
组织过程焦点 组织过程定义 培训程序 |
软件产品工程 同级评审 |
| 可重复级 | 需求管理 软件项目计划 软件项目跟踪与监控 软件子合同管理 软件质量保证 软件配置管理 |
CMMI
继承并发扬了CMM的优良特性，借鉴了其他模型的优点，融入了新的理论和实际研究成果
阶段式→组织能力成熟度
| 成熟度等级 | 过程域 | |
| 已管理级 | 需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证 |
未完成的：过程域未执行或未得到CL1中定义的所有目标 已执行的：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标 已管理的：其共性目标集中于已管理的过程的制度化 |
| 已定义级 | 需求开发、技术解决方案、产品集成、验证、确认、组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境 |
其共性目标集中于已定义的过程制度化 |
| 定量管理级 | 组织级过程性能、定量项目管理 | 其共性目标集中于可定量管理的过程的制度化 |
| 优化级 | 组织级改革与实施、因果分析和解决方案 | 使用量化(统计学)手段改变和优化过程域，以满足客户要求的改变和持续改进计划中的过程域的功效 |
连续式→软件过程能力
| 连续式分组 | 过程域 |
| 过程管理 | 组织级过程焦点、组织级过程定义、组织级培训、组织级过程性能、组织级改革与实施 |
| 项目管理 | 项目计划、项目监督与控制、供应商合同管理、集成项目管理、风险管理、集成化的团队、定量项目管理 |
| 工程 | 需求管理、需求开发、技术解决方案、产品集成、验证、确认 |
| 支持 | 配置管理、度量和分析、过程和产品质量保证、决策分析和解决方案、组织级集成环境、因果分析和解决方案 |
项目管理
- 时间管理
- 风险管理
- 特性：不确定性、损失
- 风险的优先级通常是根据风险暴露设定（风险曝光度=发生的概率×造成的损失）
- 风险识别：通过建立风险条目检查表，试图系统化地确定对项目计划的威胁
- 风险预测（风险估算）：从两个方面评估一个风险：风险发生的可能性或概率；以及如果风险发生了所产生的后果
- 风险评估：定义风险参考水平值，预测影响参考水平值的风险组合
- 风险控制：辅助项目组建立处理风险的策略，有效的策略应考虑风险避免、风险监控、风险管理及意外事件计划
- 风险避免即放弃或不进行可能带来损失的活动或工作（主动）
- 风险监控是指在决策主体的运行过程中，对风险的发展与变化情况进行全程监督，并根据需要进行应对策略的调整
- 风险管理是指在一个肯定有风险的环境里把风险减至最低的管理过程
- Gant图（进度管理）
- 不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分
- 能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及任务之间的并行关系
- Pert图（活动）
- 不能清楚描述各任务之间的并行情况
- 能清晰的描述每个任务从何时开始，到何时结束，以及各任务之间的依赖关系
- 关键路径＝图中最长的路径
- 松弛时间＝最迟开始时间－最早开始时间
- A-B-C-D-E：CD松弛时间=最迟时间（AE(max)-ED-DC）－最早时间（AB+BC）
软件工具
开发工具
需求分析工具
设计工具
编码与排错工具
测试工具
维护工具
版本控制工具
文档分析工具
开发信息库工具
逆向工程工具
再工程工具：主要集中在代码重构，程序结构重构和数据结构重构等
软件调试
归纳法：是指从测试所暴露的问题出发，收集所有正确或不正确的数据，分析他们之间的关系，提出假想的错误原因，用这些数据来证明或反驳，从而查出错误所在。
试探法：调试人员分析错误的症状，猜测问题所在的位置，利用在程序中设置输出语句，分析寄存器，存储器的内容等手段获得错误的线索，一步步地试探和分析错误的所在。这种方法效率低，适合结构比较简单的程序。
回溯法：调试人员从发现错误的位置开始，人工沿着程序的控制流程往回跟踪代码，直到找出错误根源为止。这种方法适合于小型程序，对于大规模程序，由于其需要回溯的路径太多而不可操作。
对分查找法：这种方法主要用于缩小错误范围，如果已经知道程序中的变量在若干位置的正确取值，可以在这些位置上给这些变量以正确值，观察程序运行的输出结果，如果没有发现问题，则说明赋予变量一个正确值开始到输出结果之间程序没有错误，问题可能在除此之外的程序中，否则错误就在所观察的这部分程序中，对含有错误的程序段再使用这种方法，直接把故障范围缩小到比较容易诊断为止。
演绎法：根据测试结果，列出所有可能的错误；分析已有的数据，排除不可能和彼此矛盾的原因；对其余的原因，选择可能性最大的，利用已有的数据完善该假设，使假设更具体；用假设来解释所有的原始测试结果，如果能解释这一切，则假设得以证实，也就找出错误，否则，要么是假设不完备或不成立，要么有多个错误同时存在，需要重新分析，提出新的假设知道发现错误为止
内聚类型（由高到底）
功能内聚：完成一个单一功能，各个部分协同工作，缺一不可
顺序内聚：处理元素相关，而且必须顺序执行
通信内聚：所有处理元素集中在一个数据结构的区域上
过程内聚：与处理元素相关，而且必须按特定的次序执行
瞬时内聚（时间内聚）：所包含的任务必须在同一时间间隔内执行（如初始化模块）
逻辑内聚：完成逻辑上相关的一组任务
偶然内聚（巧合内聚）：完成一组没有关系或松散关系的任务
耦合类型（由高到底）
内容耦合：当一个模块直接修改或操作另一个模块的数据或者直接转入另一个模块
公共耦合：两个或多个模块，通过引用一个公共区的数据（数据结构和变量）而发生作用
控制耦合：通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能
标记耦合：两个模块都只和一个数据结构有关，通过参数表传递记录信息
数据耦合：通过参数传递简单数据
外部耦合：通过全局变量，不是通过参数表
非直接耦合：模块之间没有直接关系，完全是通过主模块的控制和调用来实现的，独立性最强，耦合度最低
模块划分原则
模块的大小要适中。
模块的扇入和扇出要合理。
深度和宽度适当。