一、软件过程模型
原型模型
适用场景：需求不明确
优势：可以帮助用户明确需求
阶段：
- 原型开发阶段
- 目标软件开发阶段
瀑布模型
定义：瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、运行与维护。【每个阶段因果关系紧密相连】
缺陷：
- 软件需求完整性、正确性难确定【需求多变】
- 严格串行化，很长时间才能看到结果【发生问题纠偏成本过高】
- 瀑布模型要求每个阶段一次性完全解决该阶段工作【不太现实】
增量模型
组成：瀑布模型 + 原型
特征：核心功能最先完成，每轮进行功能增量迭代【每一个增量均发布一个可操作的产品】
螺旋模型
组成：快速原型 + 瀑布模型【从最初概念项目开始第一个螺旋】
核心：引入风险分析
V模型
核心：测试贯穿项目始终
喷泉模型
核心：面向对象、迭代、无间隙
快速应用开发【RAD】
概念：瀑布模型的高速变种
核心：极短的开发周期
过程：业务建模 -> 数据建模 -> 过程建模 -> 应用生成 -> 测试与交付
适用性：只能用于管理信息系统的开发，不适合技术风险很高的情况
构件组装模型
优势：易扩展、易重用、降低成本、安排任务更灵活
缺陷：设计需合理，技术要求高，第三方构件质量难以控制
统一过程【UP / RUP】
特点：用例驱动、以架构为中心、选代和增量
对项目划分阶段：
1、构思阶段（初始阶段）：定义最终产品视图和业务模型、确定系统范围
2、细化阶段（精化阶段）：设计及确定系统架构、制定工作计划及资源要求。
3、构造阶段：开发及测试
4、移交阶段：确保软件对最终用户是可用的，制作产品，发布版本
核心工作流：
- 1、业务建模
- 2、需求
- 3、分析与设计
- 4、实现
- 5、测试
- 6、部署
- 7、配置与变更管理
- 8、项目管理
- 9、环境
敏捷开发
定义：一种以人为核心、迭代、循序渐进的开发方法
适用范围：小团队、小项目【PS：目前许多大项目也借鉴了敏捷开发的思想，将整体拆分为许许多多的小的里程碑进行敏捷开发】
核心思想：小兔快跑
极限编程【XP】
四大价值观：
- 1、沟通【加强面对面沟通】
- 2、简单【不过度设计】
- 3、反馈【及时反馈】
- 4、勇气【接受变更的勇气】
十二大最佳实践：
- 1、简单设计
- 2、测试驱动
- 3、代码重构
- 4、结对编程
- 5、持续集成
- 6、现场客户
- 7、发行版本小型化
- 8、系统隐喻
- 9、代码集体所有制
- 10、规划策略
- 11、规范代码
- 12、40小时工作机制
水晶方法
提倡“机动性”的方法，拥有对不同类型项目非常有效的敏捷过程。
开放式源码
程序开发人员在地域上分布很广【PS：其他方法强调集中办公】
SCRUM【并列争球】
明确定义了可重复的方法过程，一种迭代式增量软件开发过程。
二、基于构件的软件工程【CBSE】
特征：“购买”而不是“重新构造”
特性：
1、可组装性：所有外部交互必须通过公开定义的接口进行
2、可部署性：构件总是二进制形式的，能作为一个独立实体在平台上运行
3、文档化：用户根据文档来判断构件是否满足需求
4、独立性：可以在无其他特殊构件的情况下进行组装和部署
5、标准化：符合某种标准化的构件模型
组装方式：顺序、层次、叠加
三、逆向工程
含义：设计的恢复过程
分层：
- 实现级：包括程序的抽象语法树、符号表、过程的设计表示
- 结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构
- 功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型
- 领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如实体关系模型
四、净室软件工程
PS：净室即无尘室、洁净室。也就是一个受控污染级别的环境。【这里主要指的是软件领域参考净室的设计理念演化出来的模型】
核心：强调将正确性验证而不是测试，作为发现和消除错误的主要机制。
抽象层次：行为视图【黑盒】 -> 有限状态机视图【状态盒】 -> 过程视图【白盒】
缺陷：过于理论化、正确性验证的步骤比较困难且耗时；且开发小组不进行传统的模块测试，这是不现实的。
五、需求工程
软件需求：用户对系统在功能、行为、性能、设计约束等方面的期望
阶段划分：
- 1、需求获取
- 2、需求分析
- 3、形成需求规格【形成SRS】
- 4、需求确认与验证【形成需求基线（经过评审的SRS）】
- 5、需求管理【变更控制、版本控制、需求跟踪、需求状态跟踪】
需求获取
需求获取方法：用户面谈、联合需求计划（JRP，高度组织的群体会议，进行想法同步）、问卷调查、现场观察、原型化方法、头脑风暴法（发散思维，形成新观点）
需求分析
结构化需求分析【SA】
结构化分析工具：数据流图【DFD】
- 数据流【 ---> 】
- 加工【 ⚪ 】
- 数据存储（文件）【 --- 】
- 外部实体【⬜】
PS：图内数据平衡原则！（以下几种情况称为不平衡，即不合规）
- 黑洞：一个加工只有输入而无输出数据流
- 奇迹：一个加工只有输出而无输入数据流
- 灰洞：一个加工的输入数据流无法通过加工产生输出数据流
常见待补充元素：
1、补充实体：
- 人物角色：客户、管理员、主管、经理、老师、学生
- 组织机构：银行、供应商、募捐机构
- 外部系统：银行系统、工资系统、后台数据库
2、补充存储：
- ***文件
- ***表
- ***库
- ***清单
- ***档案
3、补充数据流：
- 顶层图与0层图：是否有顶层图有，但0层图无的数据流，或反之
- 加工：是否存在只有入没有出【黑洞】，或只有出没有入【奇迹】，或根据输入的数据无法产生对应的输出的情况【灰洞】
4、补充加工名：
- 加工：用于处理数据流，所以要补充加工名【动词+名词结构】
5、补充ER图：
- 找实体：名词，一种“事件”或者“物体”【矩形表示】
- 找联系：名词，用无向边分别与有关实体连接起来，同时在无向边旁标注上联系的类型(1：1、1：n、n：m)【菱形表示】
6、补充关系模式：
- 关系模式：关系的描述，如R（U，D，dom，F）
PS：R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，dom为属性向域的映象集合，F为属性间数据的依赖关系集合
7、判断主键和外键：
- 主键：关系中的某一属性或属性组的值能唯一地标识一个元组。
- 全码：选择一个候选码作为主键。
- 外键：关系模型的所有属性组是这个关系模式的候选码，称为全码。
面向对象需求分析【SA】
1、面向对象基本概念
对象定义：属性（数据） + 方法（操作） + 对象ID
类：实体类、控制类、边界类
继承与泛化：复用机制
封装：隐藏对象的属性和实现细节,仅对外公开接口
多态：不同对象收到同样的消息产生不同的结果
接口：一种特殊的类，它只有方法定义没有实现
重截：一个类可以有多个同名而参数类型不同的方法
消息和消息通信：消息是异步通信的
2、UML图概念
两组公共分类：【类与对象】、【接口与实现】
结构事物：模型中属于最静态的部分，代表概念上或物理上的元素。【类、接口、协作、用例、活动类、构件和节点】
行为事物：模型中的动态部分，代表时间和空间上的动作。【交互、状态机】
分组事物：模型中组织的部分，可以划分模型【包】
注释事物：模型中的解释部分【注释】
3、分类
静态图：
- 类图：类图描述一组类、接口、协作和它们之间的关系。
- 对象图：对象图描述一组对象及它们之间的关系，描述了在类图中所建立的事物实例的静态快照。
- 构件图：描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。
- 部署图：描述对运行时的处理节点及在其中生存的构件的配置。
- 制品图：系统的物理结构。
- 包图：由模型本身分解而成的组织单元，以及它们之间的依赖关系，基本思想是把共同工作的元素放到一个文件夹中。
- 组合结构图：指元素之间的相互连接，实例通过通信连接合作以实现某目的。
动态图：
- 用例图：系统与外部参与者的交互。
- 顺序图 ：强调对象之间消息发送的顺序，同时显示对象之间的交互。强调时间顺序。
- 通信图：一种交互图，强调收发消息的对象或参与者的结构组织。
- 定时图：强调实际时间。
- 交互概览图：来描绘控制流，可以包含交互图的节点。
- 状态图：描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。
- 活动图：将进程或其他计算结构展示为计算内部一步步的控制流和数据流。
4、关系
- 包含关系：提取出来的公共用例称为抽象用例；原始用例称为基本用例或基础用例。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。
- 扩展关系：一个用例根据不同情况能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。
- 泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。
- 依赖关系：一个事物发生变化影响另一个事物。
- 关联关系：描述了一组链，链是对象之间的连接。
- 聚合关系：整体与部分生命周期不同。
- 组合关系：整体与部分生命周期相同。
- 实现关系：接口与类之间的关系
4、“4+1”视图
UML采用4+1视图来描述软件和软件开发过程：
- 逻辑视图：以问题域的语汇组成的类和对象集合。
- 进程视图：可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例,描绘了所设计的并发与同步结构。
- 实现视图：对组成基于系统的物理代码的文件和组件进行建模。
- 部署视图：把构件部署到一组物理的、可计算的节点上，表示软件到硬件的映射及分布结构。
- 用例视图：最基本的需求分析模型。
5、需求定义
6、需求验证
需求管理
1、定义需求基线
2、需求跟踪
3、变更控制
六、系统建模过程
结构化建模方法
定义：一种以以过程为中心的技术，可用于分析一个现有的系统以及定义新系统的业务需求。
结构化建模方法所绘制的模型称为数据流图（DFD）。
PS：对于流程较为稳定的系统可考虑结构化建模方法。
信息工程建模方法【数据库建模方法】
定义：一种以数据为中心，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。
信息工程建模方法所创建的模型被称为实体-联系图 （ERD）。
PS：此方法主要用于数据建模。
面向对象建模方法
定义：将“数据”和“过程”集成到被称为“对象”的结构中，消除了数据和过程的人为分离现象。
面向对象的建模标准：UML（统一建模语言）。
七、系统设计
1、界面设计
定义：系统与用户之间架起一座交互桥梁。
主要内容：定义界面形式、定义基本的交互控制形成、定义图形和符号、定义通用的功能键和组合键的含义及其操作内容、定义帮助策略等。
黄金三法则：置于用户控制之下、减少用户的记忆负担、保持界面的一致性
2、结构化设计
概要设计【外部设计】
功能需求分配给软件模块，确认每个模块的功能和调用关系，形成模块结构图。
详细设计【内部设计】
为每个具体任务选择适当的技术手段和处理方法。
结构化设计原则
- 模块独立性原则（高内聚、低稠合）
- 保持模块的大小适中
- 多扇入，少扇出
- 深度和宽度均不宜过高
模块四要素
- 输入和输出：模块的输入来源和输出去向都是同一个调用者。【即一个模块从调用者那儿取得输入，进行加工后再把输出返回调用者。】
- 处理功能：指模块把输入转换成输出所做的工作。
- 内部数据：指仅供该模块本身引用的数据。
- 程序代码：指用来实现模块功能的程序。
模块独立性度量标准
1、聚合【衡量模块内部各元素结合的紧密程度】
2、耦合【度量不同模块间互相依赖的程度】
3、面向对象设计【重点！！！！！】
1、设计过程
2、设计原则【重点！！！！！】
- 单一职责原则：设计目的单一的类。
- 开放-封闭原则：对扩展开放，对修改封闭。
- 李氏（Liskov）替换原则：子类可以替换父类。
- 依赖倒置原则：要依赖于抽象，而不是具体实现，针对接口编程，不要针对实现编程。
- 接口隔离原则：使用多个专门的接口比使用单一的总接口要好。
- 组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。
- 迪米特（Demeter） 原则【最少知识法则】：一个对象应当对其他对象有尽可能少的了解。
3、类的分类
- 边界类：【显示屏、窗体、打印机接口、通信协议、对话框、菜单、购物车、报表】
- API接口（机器接口）
- 用户界面（人机交互）
- 控制类：【身份验证控制器、xxx控制器等】
- 应用逻辑
- 业务逻辑
- 数据访问逻辑
- 实体类：【学员类、课程类】
- 数据
八、软件测试【重点！！！！！】
动态测试与静态测试
- 控制流分析：是否存在没有使用的语句、无法达到的语句、调用并不存在的子程序。
- 数据流分析：引用未定义的变量、对以前未使用的变量再次赋值。
- 接口分析：模块之间接口的一致性、子程序和函数之间的接口一致性、函数形参与实参的数量、顺序、类型的一致性。
- 表达式分析：括号不配对、数组引用越界、除数为零。
黑盒测试与白盒测试
黑盒测试【功能测试】
应用阶段：主要用于集成测试、确认测试和系统测试阶段。
常见表现形式：
- 等价类划分：不同等价类，揭示不同问题，有效等价类/无效等价类。
- 边界值分析：如1 <= x <= 10 ，可取x的值为0、1、10和11作为测试数据。
- 错误推测：依靠测试人员的经验和直觉。
白盒测试
应用阶段：主要用于单元测试阶段。
常见表现形式：
- 控制流测试【逻辑覆盖测试】：即对业务流程中的多分支流程进行测试 （语句覆盖最弱，路径测试覆盖最强）
- 数据流测试：带入测试数据进行测试。
- 程序变异测试：即错误驱动测试。
- 判定表：描述在多个逻辑条件取值的组合所构成的复杂情况下，分别要执行哪些不同的动作。
- 因果图：根据输入条件与输出结果之间的因果关系来设计测试用例。
灰盒测试
应用阶段：主要用于集成测试阶段。
常见表现形式：介于白盒测试与黑盒测试之间的一种测试。
V模型
- 单元测试：依据【详细设计】，模块测试，模块功能、性能、接口等。
- 集成测试：依据【概要设计】，模块间的接口。
- 系统测试：依据【需求文档】，在真实环境下，验证完整的软件配置项能否和系统正确连接。
- 确认测试：依据【需求文档】，验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试、验收测试。
- 回归测试：测试软件变更之后，变更部分的正确性和对变更需求的符合程度。
集成测试策略
系统测试
九、系统运行与软件维护【重点！！！！！】
系统转换计划
遗留系统演化策略
淘汰策略：遗留系统的技术含量较低，且具有较低的业务价值。对遗留系统的完全淘汰是企业资源的根本浪费，系统分析师应该善于“变废为宝”通过对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的风险。
继承策略：遗留系统的技术含量较低，已经满足企业运作的功能或性能要求，且具有较高的商业价值，目前企业的业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。
改造策略：遗留系统具有较高的业务价值，基本上能够满足企业业务运作和决策支持的需要。改造包括系统功能的增强和数据模型的改造两个方面。
集成策略：遗留系统的技术含量较高，但其业务价值较低，可能只能完成某个部门的业务管理。这种系统在各自的局部领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛，对这种遗留系统的演化策略为集成。
系统维护
1、影响软件可维护性的因素
- 可理解性：指通过阅读源代码和相关文档，了解软件的功能和如何运行的容易程度。
- 可修改性：指修改软件的难易程度。
- 可测试性：指验证软件程序正确的难易程度。PS：可测试性好的软件，通常意味着软件设计简单，复杂性低。因为软件的复杂性越大，测试的难度也就越大。
- 可靠性：一个软件的可靠性越高，需要维护的概率就会越低。
- 可移植性：指将软件从一个环境移植到新的环境下正确运行的难易程度。PS：软件运行环境的变化是软件维护的一种常见情形，可移植性好的软件会降低维护的概率。
2、软件维护类型
- 正确性维护【修 BUG】：识别和纠正软件错误/缺陷，测试不可能发现所有错误。
- 适应性维护【应变】：指使应用软件适应环境变化（外部环境、数据环境）而进行的修改。
- 完善性维护【新需求】：扩充功能和改善性能而进行的修改。
- 预防性维护【针对未来】：为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使系统适应各类变化而不被淘汰。PS：经典实例：【专用】改【通用】、模块化、公共模块剥离等。