软件工程概念总结-期末重点-(简单中文+英文关键词)-第一部分软件过程（第1-6章）-罗杰S普莱斯曼

原书：《Software Engineering: A Prationer’s Approach 》—— Roger S. Pressman & Bruce R. Maxim
翻译版：《软件工程》，大黑书

一、软件的本质

1.1 软件的本质

1 - 软件即是产品，也是交付产品的载体。

2 - 硬件磨损——浴缸曲线（早期和末期磨损率高）；软件退化——初期有未知的缺陷，变更时又会突然提高

3 - 软件应用领域：系统软件、应用软件、工程科学软件、嵌入式软件、产品线软件、Web/移动APP、人工智能软件

二、软件工程

2.1 定义

1 - 软件工程定义：将系统化的、规范化的、可量化的方法应用于软件的开发、运行和维护，也就是将工程化方法应用于软件。
（systematic、disciplined、quantifiable）

2 - 软件工程层次：工具、方法、过程、质量关注点
（quality focus -> process -> method -> tool）

2.2 软件过程

1. 定义

1 - 软件过程 = 活动 + 动作 + 任务（activity + action + task）

2 - 过程框架 = 若干个框架活动 + 普适性活动
process framework = process activity + unbrella activity

过程框架：

• 沟通：和客户 Communication
• 策划：技术任务、风险、资源需求、工作产品、进度计划Planning
• 建模：体系结构 Modeling
• 构建：编码和测试 Construction
• 部署：软件交付并反馈 Deployment
• 迭代：以上过程重复-》软件增量 software increment

普适性活动：

• 软件项目跟踪和控制：根据计划来评估项目进度 software project tracking and control
• 风险管理：评估可能影响产品结果的风险 risk management
• 软件质量保证：确定和执行保证质量的活动
• 技术评审：评估产品，发现并清除错误 formal technical reviews
• 评价指标测量：以满足利益相关者的需求 Measurement
• 软件配置管理：管理软件更新带来的影响 software configuration management
• 可复用管理：定义工作产品复用的标准 reusability management
• 工作产品的准备和生产：生成产品所需的活动（如建模、文档、日志、表格、列表等）
  

2. 通用原则

general principles

7个关注软件工程整体实践的原则：

• 能为用户提供价值 the reason it all exists
• 保持简洁：尽可能简洁而不失简化 KISS Keet It Simple, Stupid!
• 保持愿景：保持概念的一致性 Maintain the vision
• 关注使用者：让别人理解软件怎么用 What You Produce, Others Will Consume
• 面向未来：考虑到“如果发生了。。该怎么办” Be Open to the Future
• 提前计划复用 Plan Ahead for Reuse
• 认真思考：清晰定位 Think!

三、软件过程结构

software process structure

3.1 通用过程模型

过程流：

• 线性过程流 linear process flow
• 迭代过程流 iterative process flow
• 演化过程流 evolutionary process flow
• 并行过程流 parallel process flow

3.2 定义框架结构

（详见第七章）
起始 、需求获取、需求虚化、协商、规格说明和确认

3.3 明确任务集

每个软件工程动作都由若干个任务集（task set）组成

3.4 过程模式

process pattern

过程模式的描述模版：

• 模式名称 Pattern Name ：模式名称应能清除地表述该模式在软件过程中的含义（如技术评审）
• 驱动力 Forces：模式的使用环境及主要问题。
• 类型 Type：定义类型模式
  （1）步骤模式 stage pattern：定义了与过程的框架活动相关的问题。（如建立沟通、收集需求）
  （2）任务模式 task pattern：定义了与软件工程动作或是任务相关、关系软件工程实践成败的问题（如需求收集是一个任务模式）
  （3）阶段模式 phase pattern：定义活动序列（螺旋模型Spiral Model和原型Prototyping开发是两种阶段模式）
• 启动条件 Initial Context：模式应用的前提条件-开发前做了什么？过程的开始的状态是什么？已有什么工程信息？（如策划模式需要1. 客户和工程师已沟通过；2. 任务模式已确定 3. 业务需求和项目限制已确定）
• 问题 Problem：要解决的具体问题
• 解决方案 Solution：如何成功实现模式
• 结果 Resulting Context：1. 团队还需要做什么？ 2. 结束状态是什么？ 3. 现有工程如何了？
• 相关模式 Related Pattern：以层次化或其他图的方式列举与该模式相关的其他过程模式，例如步骤模式沟通包括了一组任务模式（项目团队，合作原则，任务分解，需求收集、约束描述，场景模式创建Project Team, Collaborative Guidelines, Scope Isolation, Requirements Gathering, Constraint Description and Scenario Creation）
• 已知应用和实例 Known Uses and Examples：该模式可应用的实例。例如沟通在每一个项目开始时都是必须的。

四、过程模型

4.1 常用的过程模型

Prescriptive Process Model

4.1.1 瀑布模型和V模型

waterfall model

瀑布模型（waterfall model) 又称为经典生命周期（ classic life cycle)，它提出了一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供完整的软件支持。

瀑布模型变体-V模型(V-Model)，本质与瀑布模型没有区别，只是提供了一种边开发边测试的方法。

4.1.2 增量过程模型

Incremental Process Model

增量模型结合了线形过程流和并行过程流的特征，在每个阶段都以线性序列的的形式进行，每个线性序列都产出软件的 “可交付增量” （每次都多写完一点功能，通常第一个增量是核心产品的基本需求）。

4.1.3 演化过程模型

Evolutionary Process Models

演化模型是迭代的，主要分为原型开发和螺旋模型两种。

原型开发 Prototyping

• 场景：客户只给了基本任务没定义详细功能；开发者对算法效率、操作系统适用性和交互没有把握。
• 过程：沟通->快速策划->建模并快速设计-> 构建原型-> 部署交付及反馈
  

螺旋模型 Spiral Model
螺旋模型是一种演进式模型，结合了原型的迭代性质和瀑布模型的可控性、系统性。
显著特点：

1. 使用循环方式逐步加深系统定义和实现的深度，同时降低风险。
2. 确定一系列里程碑作为支撑点，确保利益相关者认可。

一般而言，第一圈确定产品需求 product specification ，然后建立原型，再接着进一步完善更复杂的版本。

和其他过程模型不同之处：其他模型以交付为终点，而螺旋式模型是会对产品不断进行改进的。（product enhancement）

缺点：需要风险评估专家。

4.1.4 并发模型

Concurrent Model

(concurrent development model/concurrent engineering)

并发模型指的是开发团队可以处于策划、建模、构建和部署等任何状态中，不用遵循强制的流程。

4.2 专用过程模型

Specialized Process Models

专用过程模型具有其他模型的某些特点，但只能应用于特定领域方法。

4.2.1 基于构件的开发

Component-Based Development

基于构件开发本质上是演化模型，具有许多螺旋模型的特点，以迭代方式构建软件，采用预先打包好的构件来开发应用。
优点：容易复用

4.2.2 形式化方法模型

Formal Methods Model

形式化方法模型让开发这可以用严格的数学符号来定义、开发和验证（specify, develop and verify）系统。

该方法的一个变形是净室软件工程（cleanroom software engineering）。

这个模型对开发者的要求很高，一般只用于安全性要求很高、不能出错的软件（如飞行器、医疗设施）。

4.2.3 面向切面开发

Aspect-Oriented Software Development

Aspect-Oriented Programming, AOP; Aspect-Oriented Component Engineering, AOCE
可以理解为在一个功能的流程中切开，在中间插入一部分其他功能的流程。AOP是Java Spring框架的核心思想之一。

如果一个东西（功能、特性、信息）在很多地方都出现的话，这个点就叫做横切点（crosscutting concerns）。

4.3 统一过程

United Process

统一过程强调与客户沟通、以用户角度描述系统（用例 use case），从而使得工程师能更好地专注于核心目标（如可理解性、变更的灵活性、复用性 understandability, reliance to future change and reuse）

4.3.1 统一过程简史

统一建模语言UML unified modeling language，包含大量面向对象的建模符号。

4.3.2 统一过程的各个阶段

• 起始阶段inception phase：与客户沟通、策划功能（业务需求 -> 用例设计 -> 架构 -> 根据架构拓展，描述不同视图 -> 评估风险 -> 开发进度计划 ）。
• 细化阶段eleboration phase：沟通、通用模型建模。将架构拓展为五种视图：用例、需求、设计、实现、部署（use case, analysis, design, implementation, deployment model）。有时候，细化阶段会建立一个“可执行的架构底线”(executable architectural baseline)，这是建立可执行系统的第一步。
• 构建阶段 construction phase：基于架构模型进行开发，过程中再完善需求模型和设计模型，完成构件后进行单元测试。
• 交付阶段 transition phase：开发后期和部署（交付和反馈）阶段。软件交给测试人员进行Beta测试。还要准备相关的支持信息（用户手册、问题解决指南、安装步骤）。
• 生产阶段 production phase：和交付阶段同时进行，软件使用时进行监控monitor，并开始下一步软件增量的开发。

各个阶段不一定是顺序进行的，是并发进行的。

4.4 个人与团队合作过程

Personal and Team Process Models

中文译版的没有这一部分

4.4.1 个人过程

Personal Software Process, PSP

充分放权，由个人来决定某个板块的开发安排。
主要包括几个部分：

• 安排 Planning：时间、资源等
• 设计 high-level design：动态设计原型
• 设计评审 high-level design review：发现错误
• 开发 Development：开发并生成测试代码
• 检验 Postmortem：测试系统有效性

4.4.2 团队过程

Team Software Process, TSP

TSP使用各种各样的脚本、表单和标准来指导团队成员的工作。“脚本”定义了特定的过程活动（即项目启动、设计、实施、集成和系统测试、后期）和其他更详细的工作功能（例如开发计划、需求开发、软件配置管理、单元测试）。

五、敏捷开发

Agile Development

5.1 什么是敏捷

敏捷方法又称为轻量级方法light methods或精简方法lean methods。

强调软件的快速交付，没做好的地方就再快速迭代。

5.2 敏捷及变更成本

传统方法变更成本高，敏捷开发的成本显著降低。

5.3 什么是敏捷过程

为什么要敏捷？

大多数软件项目：

1. 难以预测什么需求是稳定的，什么需求是经常迭代的。
2. 软件的设计和开发通常是交错进行的。
3. 制定分析、设计、开发、测试的计划没那么容易。

5.3.1 敏捷原则

1. 快、持续交付、开发后期也可以变更需求
2. 产品经理和开发者在一起工作，面对面交谈
3. 给有积极性的个人充分放权，给予资源并信任他们能完成工作
4. 可运行的软件是进度的首要衡量标准

5.4 极限编程

eXtreme Programming, XP

• 策划：写故事卡片描述将要开发的软件所需要的输出、特性以及功能。
• 设计：遵循 KIS (Keep It Simple，保持简洁）原则，不要过分关注未来可能需要的功能。鼓励使用CRC卡（类-职责-协作者，class-responsibility-collaborator）
• 开发：鼓励两人一起开发，只完成相关“故事”的代码，由团队或自己把代码合并到主工程里，建立能及早发现错误的冒烟环境 smoke test。
• 测试：单元测试。

XP验收测试：客户测试。

5.4.2 工业极限编程

• 准备评估 Readiness assessment：成员是否准备就绪、环境是否OK。
• 项目社区 Project Community：项目相关成员是否已具备相关技能。
• 项目特许 Project Chartering：是否存在对项目的合适的商业调整。
• 测试驱动管理 Test-driven Management：建立一系列可测量的目标，及时反馈。
• 回顾 Restrospectives：复盘问题和经验教训。
• 持续学习 Continuous Learning：鼓励成员学习新技能。

5.5 其他敏捷过程模型

5.5.1 Scrum

• 产品待定项 product backlog：项目需求的优先级列表。
• 冲刺 sprint：一段时间内（timebox，一般是30天）必须完成的工作任务。
• Scrum例会：每天开15分钟例会。
• 演示 Demos：向客户交付软件增量、展示功能。

5.5.2 动态系统开发方法

Dynamic System Development Method, DSDM

DSDM 使用迭代软件过程，每一个迭代都遵循 80% 原则，即每个增量只完成能够保证顺利进人下一增量的工作，剩余的细节则可以在知道更多业务需求或者提出并同意变更之后
完成。

DSDM三个不同的迭代周期：

• 功能模型迭代
• 设计与开发迭代
• 实现

5.5.3 敏捷的统一过程

Agile Unified Process, AUP

大方向上一致，小方面迭代。

六、人员