软件工程期末复习（超详细！！！）

软件工程

一：软件工程概述

软件工程学的存在价值：促进软件项目成功。

软件的概念：
软件（software）：软件是计算机系统中与硬件相互依存的另一部分。它包括程序、数据及其相关文档的完整集合。
（1）能够完成预定功能和性能的可执行指令（program）
（2）使得程序能够适当地操作信息的数据结构（data）
（3）描述程序的操作和使用的文档（document）
软件危机：
软件危机定义：软件在开发和维护过程中遇到的一系列严重问题。
软件危机包含两层含义：
如何开发软件。
如何维护数量不断膨胀的已有软件。
软件工程（Software Engineering）:
是研究和应用功能如何以系统化的、规范的、可度量的方法去开发、运行和维护软件，即把工程化应用到软件上。
软件生存周期：
是指软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程。一般包括计划、分析、设计、实现、测试、集成、交付、维护等阶段。

计划阶段
确定待开发系统的总体目标和范围。
研究系统的可行性和可能的解决方案，对资源、成本及进度进行合理的估算。
分析阶段
分析、整理和提炼所收集到的用户需求，建立完整的分析模型，将其编写成软件需求规格说明和初步的用户手册。
设计阶段（总体设计和详细设计）
设计阶段的目标是决定软件怎么做。
软件设计主要集中于软件体系结构、数据结构、用户界面和算法等方面。
实现阶段（编码）
实现阶段是将所设计的各个模块编写成计算机可接受的程序代码。
测试阶段
设计测试用例，对软件进行测试，发现错误，进行改正。
运行和维护阶段
应当在软件的设计和实现阶段充分考虑软件的可维护性。
维护阶段需要测试是否正确实现了所要求的修改，并保证在产品的修改过程中，没有做其他无关的改动。
维护常常是软件生命周期中最具挑战性的一个阶段，其费用是相当昂贵的。
软件工程三要素：工具、方法、开发过程
瀑布模型：
问题定义、可行性研究、需求分析、概要设计、详细设计、编码、测试、运行与维护。
特点：
1.自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
2.上一阶段的变换结果是下一阶段变换的输入，相邻两个阶段具有因果关系。
问题：
1.各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2.开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，增加了风险。
3.早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
RUP统一软件过程（Rational Unified Process）
RUP的中心思想是：用例驱动、架构为中心、迭代和增量。
Scrum敏捷过程：

产品负责人建立条目话的产品待开发项，并进行优先级排序。
在迭代计划会上，产品负责人讲解本迭代要开发的条目，团队进行估算并放入下一个迭代。
团队在迭代内完成所列需求，每天都开每日“立”会以沟通进度和问题。
在迭代终点的迭代评审会上，团队向产品负责人展示开发成果。

二.踏上ICONIX软件工程之路

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

ICONIX过程：
扩展的ICONIX过程可分为：愿景、业务建模、需求分析、健壮性分析、关键设计、最终设计、实现。
两个大的部分：需求阶段和系统的设计和实现阶段。
四个阶段：需求分析阶段、初步设计阶段、详细设计阶段、部署阶段。
定义愿景（三部曲）:

找到软件项目的“老大”.
得到“老大”对项目的期望（愿景）;
描述出愿景的度量指标。

三:业务建模，精准了解你的客户

业务建模的意义和注意事项

业务建模要求我们把视角从软件系统转向客户组织，站在客户角度看问题，以达到清晰准确地“诊断”，对症“开方”。

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

业务建模的步骤
业务建模是从组织的角度来定位系统应该提供的价值。
1 . 明确我们为谁服务（选定愿景要改进的组织）。
2 .要改进的组织是什么现状（业务用例图、现状业务序列图）。
从外部看：组织是价值的集合，用业务用例图来建模。
从内部看：组织是系统的集合（人是一种智能系统），用业务序列图来建模。
5. 我们如何改进（改进业务序列图）。

业务用例图
组成：业务执行者、业务组织、业务用例
业务执行者： 在组织之外和组织交互的人群或组织。
业务用例： 组织为业务执行者提供的价值。
业务序列图： 业务序列图详细描述业务执行者、业务工人、业务实体之间如何交互、以完成某个业务用例的实现流程。
业务工人： 位于组织内部，负责业务流程中某些工作的人员。例如银行工作人员，医院医生。
业务实体： 在业务用例的实现流程中，业务工人所使用的“系统”。例如银行的取款机、点钞机、学校的校园卡系统。
业务序列图的作用：
1.识别业务对象：业务执行者、业务工人、业务实体；
2.确定业务对象间的职责、协作及交互顺序；
3.通过序列图来了解现状，为业务的优化提供依据。
如何采用改进业务序列图来改进现有业务流程？
1 . 将“新系统”作为一个业务实体进行整体设计；
2 . 将“新系统”引入组织现有业务流程；
3 . 查看可以改进的流程；
4 . 评估改进结果；

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

域建模：
为项目创建一个属于表。确保项目中的每个人都能以清晰一致的术语来理解和交流问题领域。
域建模比普通的项目术语表优良的地方体现在：以图的方式清晰地显示出不同术语间的关系（减少理解偏差）.
描述业务中涉及到的实体及其相互之间的关系，是帮助系统分析人员、用户认识现实业务的工具。
域模型图将通过不断修正完善逐步演化为最终的静态类图。
域建模的步骤：

仔细阅读需求文档，提取出名词和名词短语。
排除列表中重复、相似的术语
排除超出系统范围的术语
画出第一版域模型图
整理第一版域模型

域模型之间的关系：
泛化：一般元素和特殊元素的关系。
关联：两个类之间存在着某种语义上的联系。
系统用例建模的意义：

系统需求分析的目的是把视角从业务组织转向新系统，站在最终用户及其它干系人的角度看问题。
系统用例是对系统为系统执行者提供的价值的建模。

系统用例建模步骤：
6. 绘制系统用例图
7. 编写系统用例描述
8. 更新域模型
用例之间的关系：

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。
包含关系：使用包含用例来封装一组跨越多个用例的相似动作（行为片段），以便多个基用例复用
扩展关系：将基用例中一段相对独立并且可选的动作，用扩展用例加以封装，再让它从基用例中声明的扩展点上进行扩展，从而使基用例行为更简练和目标更集中。

用例描述的基本组成：
干系人利益
基本路径
扩展路径
业务规则

软件产品的典型非功能性需求：

可靠性
可用性
性能
可支持性

五：需求与设计的桥梁：健壮性分析

健壮性分析中的三种元素：

边界类：与用户交互的对象，系统和外部世界的界面，如窗口，对话框等等。
实体类：是现实世界存在的实体对象，域模型中的类，它常对应于数据库表和文件。
控制器类：边界和实体间的“粘合剂”，将边界对象和实体对象关联起来，它包含了大部分应用逻辑，在用户和对象之间架起一座桥梁。控制对象中包含经常修改的业务规则和策略。

健壮性分析中三种元素的交互规则：
执行者只可以和边界对象通话；
边界对象和控制器可以互相通话；
控制器可以和另一个控制器通话；
控制器和实体对象可以互相通话；

六：关键设计

关键设计主要意义：
就是要通过寻找对象之间的交互关系，进而进行方法（操作或行为）分配。

七：详细设计

技术架构及相关考虑：

选择开发语言
网络拓扑及安全
体系结构
硬件支持环境
软件支持环境

八：敏捷开发

敏捷软件开发模式：

敏捷开发的核心思想是以用户的需求进化为核心，采用迭代、循序渐进的方法进行的软件开发。
由传统迭代式软件开发模式发展而来，强调产品价值、团队协作、客户参与、先期验证、简化流程、拥抱变化。
总结吸收成功软件项目研发的最佳实践；与现代管理思想相辅相成。
敏捷=理念+优秀实践+具体应用

理念（敏捷核心思想）
优秀实践（敏捷的经验积累）
具体应用（能够结合自身灵活应用才是真正敏捷）

九：Scrum敏捷过程

scrum是一个增量的、迭代的敏捷开发过程。
Scrum敏捷开发过程：
项目整个开发周期包括若干个小的迭代周期，每个迭代周期成为一个Sprint,每个Sprint的建议长度2到6周。
使用产品Backlog来管理项目的需求，产品Backlog是一个按照商业价值排序的需求列表，体现形式通常为用户故事（UserStory）。
团队从产品Backlog中挑选最有商业价值的需求，经过Sprint计划会议上的分析、讨论和估算得到任务列表，成为Sprint Backlog。
在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。
敏捷团队
敏捷团队包括3个核心角色：
PO（Product Owner 产品负责人）、
Scrum Master（Scrum教练）、
Team（开发团队）
scrum组成：
三个角色：产品负责人、敏捷教练、团队
四个会议：迭代计划会议、每日站会、迭代评审会议、迭代回顾会议
三个产物：Product Backlog 、Sprint Backlog、
燃尽图
scrum特点：
适于在不确定性高的环境中开发复杂产品。
简洁但有效
项目信息对所有干系人高度透明
便于快速发现问题，促使团队和组织持续改进。

十一：敏捷工程实践

用户故事：
用户故事是一个用来确认用户和用户需求的简短描述。包含三个要素：角色、功能、价值
例：作为一个xxx客用，我需要xxx功能，能够带来xxx好处。
用户故事INVEST标准：

独立性（independent）：故事之间松耦合，具有独立性。不应该依赖于其他的用户故事。
可协商（Negotiable）：开始仅用于占位符，逐步细化。
有价值（Valuable）：用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写。
可估算（Estimatable）：设计、开发、测试团队可复算工作量和成本。（不可估算的原因：太大需要分解，或信息不全需要进一步探索）
短小（Small）：故事应该尽量的短小（如两周冲刺，故事一般是两天以内的）
可测试（Test）：有相应测试验收标准。
结对编程：
两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码；
操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”；
领航员检视的同时还必须负责考虑下一步的工作方向，比如可能出现的问题以及改进等。
测试驱动开发（Test-Driven Development）：
TDD以测试作为编程的中心，它要求在编写任何代码之前，首先编写定义代码功能的测试用例，编写的代码要通过用例，并不断进行重构优化；
持续集成（Continuous Integration）：
持续集成（CI）是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成公国自动化构建完成。
代码复查（Code Review）