软件工程期末总结

目录

第一章：软件工程概述

一，软件工程概览

1，软件的基本概念

2，软件危机的原因，途径

3，软件工程

二，IT行业人才格局及成长路线

三，软件过程-软件工程的核心组成部分

第二章：ICONIX

第三章：业务建模

业务建模的意义

业务建模步骤

业务用例图（组织现状，从外部看）

业务序列图（组织现状，从内部看）

改进业务序列图

第四章：需求分析，用例分析法

域建模

域建模步骤

域建模之间的关系

系统用例图

系统用例建模步骤

系统用例图绘制步骤

用例间关系

用例描述

更新域模型

功能性需求和非功能性需求

第五章：健壮性分析

健壮性分析三要素：

三要素交互规则：

健壮性分析步骤

第六章：关键设计

高内聚

低耦合

第七章：详细设计

第八章：敏捷开发

敏捷宣言

敏捷理念

敏捷优秀实践

第九，十章：Scrum敏捷过程

迭代式开发

迭代式开发的好处

Scrum敏捷开发过程

敏捷团队

敏捷工作件

[敏捷工作件：Product Backlog](#敏捷工作件：Product Backlog)

[敏捷工作件：Sprint Backlog](#敏捷工作件：Sprint Backlog)

敏捷工作件：完成标准

敏捷工作件：任务看板

敏捷工作件：燃尽图

敏捷管理实践

迭代计划会议

迭代backlog规划

每日站立会议

Scrum组成

第十一章：敏捷工程实践

用户故事

用户故事大小级别

用户故事INVEST标准

敏捷工程实践

结对编程

测试驱动开发TDD

持续集成

[Code Review](#Code Review)

---

第一章：软件工程概述

一，软件工程概览

1，软件的基本概念

程序，数据，及其相关文档的完整集合

2，软件危机的原因，途径

1. 客户对软件需求的描述不准确，可能有遗漏，有二义性，有错误，在软件开发过程中，客户提出修改软件功能，界面，支撑环境等方面的要求

2. 软件开发人员对用户需求的理解与用户的本来愿望有差异。不能有效地，独立自主地处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误

3. 管理人员，软件开发人员等各类人员的信息交流不及时，不准确，有时还会产生误解

4. 缺乏有力的方法和工具方面的支持，过分依赖程序人员在软件开发过程中的技巧和创造性，加剧软件的个性化

3，软件工程

软件工程：是研究和应用如何以系统化的，规范的，可度量的方法去开发，运行和维护软件，即把工程化应用到软件上

软件工程研究目标：

1. 软件开发成本较低

2. 软件功能可以较好地满足用户需求

3. 软件性能较好

4. 软件可靠性高

5. 软件易于使用，维护和移植

6. 能够按时完成开发任务，并及时交付使用

软件工程生命周期：是指软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程。一般包括计划，分析，设计，实现，测试，集成，交付，维护等阶段

生命周期各阶段任务：

1. 计划阶段：总体目标和范围，研究可行性和解决方案，合理的估算

2. 分析阶段：用户需求，分析模型，软件需求规格说明和初步的用户手册

3. 设计阶段：（总体设计和详细设计）软件体系结构，数据结构，用户界面和算法等方面

4. 实现阶段：（编码）将所设计的各个模块编写成计算机可接受的程序代码

5. 测试阶段：设计测试用例，对软件进行测试，发现错误，进行改正

6. 运行和维护阶段：测试是否正确地实现了所要求的修改，具有挑战性，费用昂贵

二，IT行业人才格局及成长路线

...

三，软件过程-软件工程的核心组成部分

RUP（统一软件过程）的中心思想是：用例驱动，架构为中心，迭代和增量

软件工程三要素：工具（系统），方法（技能），开发过程（框架）

第二章：ICONIX

需求工程：通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持

需求开发：通过调查与分析，获取用户需求并定义产品需求（需求调查，分析，定义）

需求管理：在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更

IconIx需求实现过程：使用四张UML图：

1. 用例图

2. 序列图

3. 类图

4. 健壮性图

如何定义愿景：

1. 找到软件项目的"老大"

2. 得到"老大"对项目的期望（愿景）

3. 描述出愿景的度量指标

扩展ICONIX过程：

1. 愿景

2. 业务建模

3. 需求分析

4. 健壮性分析

5. 关键设计

6. 最终设计和实现

第三章：业务建模

业务建模的意义

视角在客户组织，站在客户角度看问题，找准客户及其愿景，切记不是在为自己做系统；要改进的组织是什么现状--有什么痛处和不足；如何改进--新系统的价值就是解决客户痛处、改良客户不足，这才是客户愿意掏腰包的动力；在业务建模和需求分析阶段，忘掉自己技术专家的身份

业务建模步骤

业务建模是从组织的角度来定位系统应该提供的价值

1. 明确我们为谁服务（选定愿景要改进的组织）

2. 要改进的组织是什么现状（业务用例图，现状业务序列图）：从外部看：组织是价值的集合，用业务用例图来建模；从内部看：组织是系统的集合，用业务序列图来建模

3. 我们如何改进（改进业务序列图）

业务用例图（组织现状，从外部看）

三部分构成：

1. 业务执行者：在组织之外和组织交互的人群或组织

2. 业务组织：...

3. 业务用例：组织为业务执行者提供的价值

4. 

业务序列图（组织现状，从内部看）

业务序列图详细描述业务执行者 ，业务工人 ，业务实体之间如何交互，以完成某个业务用例的实现流程

1. 业务工人：位于组织内部，负责业务流程中某些工作的人员

2. 业务实体：业务工人所使用的"系统"

改进业务序列图

第四章：需求分析，用例分析法

域建模

为项目创建一个术语表，确保项目中的每个人都能以清晰一致的术语来理解和交流问题领域

域建模步骤

1. 仔细阅读需求文档，提取出名词和名词短语

2. 排除列表中重复，相似的术语

3. 排除超出系统范围的术语和系统本身

4. 画出第一版域模型图

5. 整理第一版域模型

域建模之间的关系

• 泛化：一般元素与特殊元素之间的关系

• 关联：两个类之间存在某种语义上的联系

系统用例图

系统用例图：系统用例是对新系统为系统执行者提供的价值的建模

系统用例图包括：

• 系统边界

• 系统用例

• 用例关系

• 系统主执行者

• 系统辅执行者

系统用例建模步骤

1. 绘制系统用例图

2. 编写系统用例描述

3. 更新域建模

系统用例图绘制步骤

1. 确定系统边界：系统边界，即系统包含功能与不包含功能之间的界限。系统内，需要建设，系统外，考虑接口

2. 识别系统执行者：系统之外，透过系统边界，与系统进行有意义交互的任何事物

3. 识别系统用例：系统执行的一系列动作，执行者通过系统可以达到的某个目标

4. 确定用例间的关系：泛化，包含，扩展

用例间关系

1. 泛化：一个用例的多种表现形式

2. 包含：封装一组跨越多个用例的相似动作（多个用例有相似的动作）

3. 扩展：将基用例中一段相对独立并且可选的动作，用扩展用例加以封装，再让它从基用例中声明的扩展点上进行扩展，从而使基用例行为更简练和目标更集中。（可选路径，不一定触发）

用例描述

用例描述的基本组成：

• 干系人利益

• 基本路径

• 扩展路径

• 业务规则

更新域模型

功能性需求和非功能性需求

功能性需求：系统可以做什么

非功能需求：系统可以把某项功能做到什么程度，

典型非功能性需求：

• 可靠性：系统在一定时间内，在一定条件下无故障地执行指定功能的能力

• 可用性：一个产品可以被特定的用户在特定的上下文中，有效，高效并且满意得达成特定目标的程度

• 性能：系统实现预期功能的能力的特性

• 可支持性：系统在故障解除和系统升级方面的能力

第五章：健壮性分析

健壮性分析三要素：

• 边界类：与用户交互的对象，系统和外部世界的界面，如窗口，对话框等

• 实体类：是现实世界存在的实体对象，域模型中的类，它常对应于数据库表和文件。有些实体对象是"临时"对象（如搜索结果），当用例结束后将消失

• 控制器类：边界和实体类间的"粘合剂"，将边界对象和实体对象关联起来，包含大部分应用逻辑，在用户和对象之间架起一座桥梁。控制对象中包含经常修改的业务规则和策略

三要素交互规则：

• 执行者只可以和边界对象通话

• 边界对象和控制器可以互相对话

• 控制器可以和另一个控制器通话

• 控制器和实体类对象可以互相通话

健壮性分析步骤

1. 创建一个空的健壮性图

2. 将用例描述关联到健壮性图上

3. 从基本路径的第一句话开始画健壮性图

4. 贯穿整个用例基本路径，一次一个句子，画执行者，适当的边界对象和实体对象以及控制器，和各元素之间的连线

5. 将每一个扩展路径画在健壮性图上，并以红色标识出

第六章：关键设计

关键设计的步骤

1. 将现有的域模型直接作为第一版静态类模型

2. 基于用例描述和健壮性分析结果，画出每个用例的序列图

3. 整理静态类图和序列图

4. 关键设计复核，迭代更新用例图，类图和序列图

高内聚

高内聚：是指一个软件模块（类）是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则

低耦合

低耦合：是指一个软件模块与模块之间的接口，尽量的少而简单，如果某两个模块间的关系比较复杂的话，最好首先考虑进一步的模块划分，降低相互的依赖。这样有利于修改和组合。

第七章：详细设计

第八章：敏捷开发

敏捷宣言

• 个体和交互胜过过程和工具

• 可以工作的软件胜过面面俱到的文档

• 客户合作胜过合同谈判

• 响应变化胜过遵循计划

敏捷 = 理念 + 优秀实践 + 具体应用

敏捷理念

• 聚焦客户价值，消除浪费

• 激发团队潜能，加强协作

• 不断调整以适应变化

敏捷优秀实践

Scrum，XP

第九，十章：Scrum敏捷过程

Scrum是一个增量的，迭代的敏捷开发过程

迭代式开发

• 迭代开发将整个软件生命周期分成多个小的迭代（一般2-6周）

• 每一次迭代都有需求分析，设计，实现，测试，和集成在内的多个活动组成

• 每一次迭代都可以生成一个稳定和被验证过的软件版本

迭代式开发的好处

• 通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险

• 通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使最终产品更加符合客户的需要

• 通过小批量减少排队，提供更灵活，快速的交付能力

• 平滑人力资源的使用，避免出现瓶颈

Scrum敏捷开发过程

• 项目整个开发周期包括若干个小的迭代周期，每个迭代周期称为一个Sprint（2-6周）

• 使用产品Backlog来管理项目的需求，产品Backlog是一个按照商业价值排序的需求列表，体现形式通常为用户故事

• 团队从产品Backlog中挑选最有商业价值的需求，经过Sprint计划会议上的分析，讨论和估算得到任务列表，称为Sprint Backlog

• 在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量

敏捷团队

三个核心角色：

1. PO（产品负责人）

2. Scrum Master（Scrum教练）

3. Team（开发团队）

4. PO：代表利益相关人（如用户，Marketing，管理者等），对产品投资回报负责，确定产品发布计划，定义产品需求并确定优先级，验收迭代结果，并根据验收结果和需求变化刷新需求清单和优先级

5. 教练：辅导团队正确地应用敏捷实践，引导团队建立并遵守规则，保护团队不受打扰，推动解决团队遇到的障碍，激励团队

6. 开发团队：负责估计工作量并根据自身能力找出最佳方案去完成任务且保证交付质量，向PO和利益相关人演示工作成果（可运行的软件），团队自我管理，持续改进

敏捷工作件

• 产品Backlog

• 迭代Backlog

• 完成标准

• 任务看板

• 燃尽图

敏捷工作件：Product Backlog

产品Backlog：经过优先级排序的动态刷新的产品需求清单，用来制定发布计划和迭代计划

product backlog item：按优先级排序的预期产品功能集，通常组成包括：

• 特性

• 缺陷

• 技术工作

• 知识获取

产品功能列表DEEP特征：

• 详略得当

• 涌现的

• 做过估算

• 排列了优先级

敏捷工作件：Sprint Backlog

迭代Backlog：团队在一轮迭代中的"任务"清单，是团队的详细迭代开发计划

敏捷工作件：完成标准

完成标准：基于"随时可向用户发布"的目标制定衡量团队工作是否已完成的标准，由团队和PO形成共识

敏捷工作件：任务看板

任务看板：显示了在本次迭代中要完成的所有任务的当前状态

敏捷工作件：燃尽图

敏捷管理实践

迭代计划会议

内容：

1. 澄清需求，对"完成标准"达成一致

2. 工作量估计，根据团队能力确定本轮迭代交付内容

3. 细化，分配迭代任务和初始工作计划

迭代backlog规划

步骤：

1. 确定团队生产能力

2. 选择PBI

3. 细化冲刺目标

4. 获得信心

5. 敲定承诺

每日站立会议

聚焦三个主题：

• 我昨天为本项目做了什么

• 我计划今天为本项目做什么

• 我需要什么帮助以更高效的工作

Scrum组成

• 三个角色：PO（产品负责人），SM（敏捷教练），Team（团队）

• 四个会议：迭代计划会议，每日站会，迭代评审会议，迭代回顾会议

• 三个产物：Product Backlog， Sprint Backlog， 燃尽图

第十一章：敏捷工程实践

用户故事

用户故事：一个用来确认用户和用户需求的简短描述

典型描述句式为：作为一个XXX客用，我需要XXX功能，能够带来XXX好处

用户故事便于团队站在用户角度分解细化需求并指定验收标准

用户故事大小级别

• 史诗故事（1-2月）

• 特性故事（1-2周）

• 冲刺故事（1-2天）

• 任务（几小时）：可分工执行

用户故事INVEST标准

• 独立性

• 可协商

• 有价值

• 可估算

• 短小

• 可测试

敏捷工程实践

结对编程

两位程序员在一台电脑前工作，一个负责编码，另一个负责检试每一行代码，

负责编码的称为"驾驶员"，负责实时审查的称为"领航员"

测试驱动开发TDD

TDD以测试作为编程的中心，要求在编写任何代码之前，首先编写定义代码功能的测试用例

编写的代码要通过用例，并不断进行重构优化

TDD要求测试可以完全自动化运行

持续集成

指团队成员经常集成他们的工作，通常每人每天至少集成一次

每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证

Code Review

代码审查也称代码复查，是指通过阅读代码来检查源代码