2.1 开发模型

瀑布模型

• 严格区分阶段，每个阶段因果关系紧密相连
• 只适合需求明确的项目
• 

原型模型

• 适合需求不明确的项目
• 原型模型两个阶段：原型开发阶段和目标软件开发阶段
  

V模型

• 需求分析->验收测试与系统测试；概要设计对应集成测试，详细设计对应单
  元测试。

迭代与增量模型

注意这里是两个模型

螺旋模型

螺旋模型是一种将瀑布模型和快速原型模型结合起来，综合了两者优点的软件开发模型，以下是其详细介绍：

基本原理

螺旋模型将软件开发过程视为一个螺旋式的迭代过程，每个迭代周期都包含制定计划、风险分析、实施工程和客户评估四个阶段，沿着螺旋线逐步推进项目，每迭代一次，软件项目就会前进一个层次，系统就会更加完善。

开发过程

1. 制定计划：确定软件项目的目标，选定实施方案，明确项目开发的限制条件，制定详细的项目计划，包括进度安排、资源分配、成本预算等。
2. 风险分析：对项目可能面临的风险进行识别、评估和分析，判断风险的概率和影响程度，制定相应的风险应对策略。例如，如果技术风险较高，可能需要进行技术预研或采用更成熟的技术方案；如果市场需求变化风险较大，可能需要增加需求变更管理的措施。
3. 实施工程：根据选定的方案和应对风险的措施，进行软件项目的开发工作，包括需求分析、设计、编码、测试等活动，产生一个可运行的版本。
4. 客户评估：将可运行版本提交给客户，由客户对项目的进展和成果进行评估，提出反馈意见和新的需求。开发团队根据客户的评估结果，对项目计划和方案进行调整，为下一次迭代做准备。

特点

• 风险驱动：将风险分析作为模型的核心，强调在项目的每个阶段都要进行风险评估，并根据风险的大小来决定采取何种措施。这种方式有助于在项目早期发现和解决潜在的问题，降低项目失败的风险。
• 逐步深化：通过多次迭代，逐步深化对软件项目的理解和认识，不断完善软件产品的功能和质量。每一次迭代都会在前一次的基础上增加新的功能或改进现有功能，使软件系统越来越接近最终目标。
• 结合多种方法：融合了瀑布模型的系统性和顺序性以及快速原型模型的迭代特征，既有比较明确的阶段划分和严格的评审过程，又允许在每个阶段进行局部的调整和改进，兼具两者的优点。
• 强调客户参与：客户在每个迭代周期的评估阶段都有重要作用，能够及时对项目成果提出意见和建议，使软件产品更好地满足客户需求，提高客户满意度。

适用场景

螺旋模型适用于规模较大、风险较高、需求不太明确的软件开发项目，特别是那些对安全性、可靠性要求较高的软件系统，如航空航天软件、金融核心系统等。

螺旋模型在软件开发中提供了一种较为全面和灵活的方法，能够有效地应对项目中的各种风险和需求变化，但也需要开发团队具备较强的风险管理能力和技术实力，同时项目的成本和时间管理相对复杂，需要更加精细的规划和控制。

基于构件的开发模型（CBSD）

基于构件的软件工程（CBSE）

快速应用开发（RAD）

基本概念

RAD 是一种以快速交付为核心目标的软件开发方法，它打破了传统软件开发方法中严格的阶段划分，采用快速迭代、增量式开发等方式，强调用户在整个开发过程中的高度参与，力求在短时间内开发出满足用户需求的高质量软件应用。

统一过程（UP/RUP）

基本概念

统一过程（Unified Process，UP），也称为统一软件开发过程或统一流程框架，是一个通用的、基于构件的软件开发过程框架，其中 Rational 统一过程（Rational Unified Process，RUP）是 UP 的商业化版本，也是最为著名和广泛应用的实例。
统一过程（Unified Process，UP），也称为统一软件开发过程或统一流程框架，是一个通用的、基于构件的软件开发过程框架，其中Rational统一过程（Rational Unified Process，RUP）是UP的商业化版本，也是最为著名和广泛应用的实例。以下是关于UP/RUP的详细介绍：

核心特点

• 用例驱动：强调以用例来捕获系统的功能需求，用例是从用户角度描述系统提供的功能以及用户与系统之间的交互，贯穿于软件开发的整个生命周期，驱动着分析、设计、实现和测试等各个阶段的工作。
• 以架构为中心：将软件架构的设计和演进作为软件开发的核心，在整个开发过程中，不断地对软件架构进行细化、验证和改进，确保系统具有良好的可扩展性、可维护性和可靠性。
• 迭代和增量式开发：把软件开发过程划分为多个迭代周期，每个迭代都产生一个可运行的版本，通过不断迭代逐步增加系统的功能和完善系统的质量，降低项目风险，提高软件的可适应性。

开发阶段

• 初始阶段：主要目标是确定项目的范围、边界和业务案例，识别主要的参与者和用例，进行项目的可行性分析和风险评估，制定项目的初步计划，确定项目的关键里程碑。
• 细化阶段：进一步细化需求，对系统的架构进行设计和分析，识别系统的关键技术风险并进行原型开发，建立系统的基础架构，为后续的开发工作奠定基础，重点是确保架构的稳定性和可行性。
• 构建阶段：基于细化阶段确定的架构和设计，进行系统的详细设计和编码实现，完成各个模块的开发和集成工作，通过不断的测试和迭代，逐步完善系统的功能和性能，使系统达到可交付的状态。
• 移交阶段：将开发完成的系统移交给用户，进行系统的部署和用户培训，收集用户的反馈，对系统进行最后的调整和完善，确保系统能够满足用户的实际需求，顺利投入使用。
  

核心工作流

• 业务建模：对目标组织的业务流程和业务规则进行建模，描述业务的结构和动态行为，为软件系统的需求分析提供业务背景和依据，帮助开发团队更好地理解业务需求，确保软件系统与业务流程相匹配。
• 需求：捕获和分析系统的功能和非功能需求，将用户的需求转化为软件系统的需求规格说明，通过用例模型、需求文档等形式对需求进行详细描述，并对需求进行管理和跟踪，确保需求的完整性和一致性。
• 分析与设计：基于需求模型，进行系统的分析和设计工作，包括建立系统的概念模型、设计软件架构、确定模块的划分和接口定义等，将需求转化为可实现的软件设计方案，为编码实现提供指导。
• 实现：将设计模型转化为实际的代码，进行代码的编写、单元测试和集成测试等工作，实现系统的各个功能模块，并将它们集成在一起，形成可运行的软件系统。
• 测试：对软件系统进行各种测试，包括单元测试、集成测试、系统测试和验收测试等，确保软件系统的质量和功能符合需求规格说明，发现并修复软件中的缺陷和问题，提高软件的可靠性和稳定性。
• 部署：将软件系统部署到实际的运行环境中，包括安装、配置和启动系统等工作，确保系统能够在目标环境中正常运行，并为用户提供相应的技术支持和维护服务。
• 配置与变更管理：对软件开发过程中的各种配置项进行管理，包括代码、文档、模型等，跟踪和控制配置项的变更，确保软件系统的一致性和可追溯性，避免因变更导致的问题和风险。
• 项目管理：对软件开发项目进行全面的管理，包括制定项目计划、安排项目资源、跟踪项目进度、管理项目风险等，确保项目能够按照计划顺利进行，按时交付高质量的软件产品。
• 环境：为软件开发提供必要的开发环境和工具支持，包括选择合适的开发工具、建立开发流程和规范等，确保开发团队能够高效地进行软件开发工作。

RUP为软件开发提供了一个全面、系统的过程框架，帮助开发团队更好地管理软件开发过程，提高软件质量，降低项目风险，但在实际应用中，需要根据具体项目的特点和需求进行适当的裁剪和调整。

敏捷方法

敏捷方法—XP

敏捷方法—SCRUM

其他方法

逆袭工程

净室软件工程

2.2: 需求工程

概述

在需求工程中，SRS 是 Software Requirements Specification 的缩写，即软件需求规格说明书。它是需求工程中的关键文档

需求开发

需求获取

• 需求分类
• 
  

需求分析

结构化需求分析

面向对象分析OOA

UML

UML 4+1 视图

需求定义

需求验证

需求跟踪

需求管理

变更控制

2.3 软件设计

软件系统建模

结构化设计

内聚

耦合

模块四要素

面向对象设计

基本过程

类的分类

设计原则

界面设置

2.4 测试

测试类型

测试方法

静态分析方法

黑盒和白盒测试

测试阶段

集成测试

性能测试

2.5 维护

遗留系统处置

遗留系统演化策略

维护类型

影响可维护性的因素

维护类型

其他知识

构件组装模型

构件组装模型通过重用提升软件可靠性与易维护性，修改程序时副作用少、易维护。其开发过程为设计构件组装、建立构件库、构建应用软件、测试与发布。优点有构件自包容利于系统扩展；设计良好的构件易重用，降低开发成本；构件粒度小，开发任务安排灵活，可分组并行独立开发构件。

需求工程

需求工程含需求开发和需求管理两类活动。需求开发有需求获取、分析、定义、验证等主要活动；需求管理包括变更控制、版本控制、需求跟踪和需求状态跟踪活动。

类的设计

1. 实体类：映射需求中的实体，保存需永久存储信息，具永久性，属性和关系长期需要，一般为名词，可从SRS中对应名词找，一定有属性但不一定有操作。
2. 控制类：控制用例工作，多由动宾结构短语转化而来，封装用例特有行为，控制对象行为具协调性，执行完用例常消亡，一般无属性但有方法。
3. 边界类：封装用例内外流动信息或数据流，位于系统与外界交接处，包括硬件接口与其他系统接口等，可从用例模型找，用于对系统与外界交互建模，报表等可作边界类处理。

统一过程语言

统一过程把一个项目分为四个不同的阶段：
构思阶段（初始/初启阶段）：定义最终产品视图和业务模型、确定系统范围。
细化阶段（精化阶段）：设计及确定系统架构、制定工作计划及资源要求。
构造阶段：开发剩余构件和应用程序功能，把这些构件集成为产品，并进行详细测试。
移交阶段：确保软件对最终用户是可用的，进行β测试，制作产品发布版本。
6个核心过程工作流：业务建模、需求、分析与设计、实现、测试、部署。
3个核心支持工作流：配置与变更管理、项目管理、环境。

确认测试

确认测试也称合格性测试，用于验证软件与用户需求一致性，包括内部确认测试、Alpha测试、Beta测试等。Alpha和Beta测试一般针对产品型软件，前者在开发环境下由用户/内部用户模拟操作受控测试，后者在实际环境下进行。验收测试确保软件就绪可被最终用户使用，回归测试针对软件变更后，验证其正确性和未对原有功能等造成损害。

UML视图

总计

UML2.0 共定义 14 种图，分为结构图（静态图）和行为图（动态图）两类。结构图含类图、对象图、构件图、部署图、制品图、包图、组合结构图；行为图含用例图、顺序图、通信图（协作图）、定时图、交互概览图、活动图、状态图。同时提到 PAD 是问题分析图，用于结构化设计。

扩展

• 结构图（静态图）
  • 类图：展现类、接口、协作及它们之间的关系，描述系统的静态结构，是面向对象系统建模中最常见的图，可用于对系统的词汇建模、对简单协作建模、对逻辑数据库模式建模等。
  • 对象图：是类图的实例，展示系统在某一时刻的对象及其关系，用于理解数据结构或验证类图的正确性。
  • 构件图：描述系统中构件、接口、依赖关系等，展示系统的物理组成部分，用于对系统的静态实现视图建模，可帮助人们理解系统的物理架构。
  • 部署图：描述处理器、设备和软件构件运行时的体系结构，展示系统硬件拓扑结构以及软件如何部署到硬件上，对于分布式系统的建模非常重要。
  • 制品图：对系统的物理制品建模，如可执行文件、库文件、脚本等，强调制品之间的依赖关系。
  • 包图：将模型元素分组，用于管理大型复杂系统的模型结构，提供一种高层面的组织机制，方便对模型元素进行分类和管理。
  • 组合结构图：描述结构化类的内部结构，展示部件之间的交互关系，有助于理解复杂类的内部组成和行为。
• 行为图（动态图）
  • 用例图：从用户角度描述系统的功能以及系统与外部参与者之间的交互，主要用于需求获取和建模，帮助确定系统的功能边界和用户需求。
  • 顺序图：强调对象之间消息的时间顺序，展示对象之间的动态交互，突出对象之间消息的发送和接收顺序以及对象的激活和失活状态。
  • 通信图（协作图）：也是描述对象之间的交互，但它更侧重于对象之间的链接关系，强调对象之间的协作关系，与顺序图可以相互转换。
  • 定时图：描述对象状态随时间的变化情况，主要用于对实时系统建模，展示对象状态的时间约束和状态转换。
  • 交互概览图：是活动图和顺序图的混合，将多个顺序图组合在一起，展示系统中多个交互之间的关系和流程，用于描述系统的整体行为流程。
  • 活动图：描述系统的动态行为，展示从活动到活动的控制流和数据流，类似于流程图，但更侧重于并行和并发活动，可用于对工作流建模、对业务流程建模等。
  • 状态图：描述对象的状态机，展示对象的状态以及状态之间的转换，用于对单个对象的行为建模，有助于理解对象在其生命周期内的行为变化。
• PAD（问题分析图）
  它是一种用于结构化设计的图形工具，用二维树形结构的图来表示程序的控制流，将程序的逻辑结构清晰地展现出来，易于理解和修改，在软件设计的详细设计阶段有着重要应用。

自动化测试

自动化测试工具用脚本技术生成测试用例，可用于功能、性能、负载测试。脚本类型有：线性脚本，录制人工操作可回放；结构化脚本，有逻辑结构和函数调用功能；共享脚本，可被多测试用例使用且能跨主机系统共享；数据驱动脚本，测试输入存于独立数据文件；关键字驱动脚本，是数据驱动脚本逻辑扩展，用关键字指定任务。

测试类型

• AB测试：多版本同时使用，收集各版本用户反馈评估最优版本，是网页优化方法。
• Web测试：系统测试与其他系统测试内容基本相同，只是测试重点不同，包括功能测试、链接测试等多方面。
• 链接测试：测试链接是否正确指向页面、有无孤立链接、能否正确保存数据。
• 表单测试：测试提交数据后，变更部分的正确性和对变更需求的符合性。

维护类型

软件维护有四种类型：

• 改正性维护：软件交付后，运行中特定环境下隐藏错误暴露，对其诊断和改正的过程。
• 适应性维护：因计算机发展，外部或数据环境变化，为使软件适应变化而修改的过程。
• 完善性维护：软件使用中用户提新功能与性能要求，为满足需求对软件修改或再开发，扩充功能、增强性能等。
• 预防性维护：为提高软件可维护性、可靠性等，将现有软件部分重新设计、编制和测试，以满足未来需求。

设计模式

常见设计模式分为三类：
创建型模式含工厂方法、抽象工厂、单例、构建器、原型模式；
结构型模式有适配器、组合、装饰、代理、享元、外观、桥接模式；
行为型模式包括策略、模板方法、迭代器、责任链、命令、备忘录、状态、访问者、解释器、中介者、观察者模式。