软件工程概述

一、软件工程概述

1、软件是计算机系统中与硬件相互依存的另一部分。它包括程序、数据及其相关文档的完整集合。

（1）能够完成预定功能和性能的可执行指令（program）

（2）使得程序能够适当地操作信息的数据结构（data）

（3）描述程序的操作和使用的文档（document）

2、软件特点

• 软件是一种逻辑实体，而不是具体的物理实体。

• 软件的生产与硬件不同。

• 在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题，但它存在退化问题，开发人员必须维护软件。

• 大多数软件是自定的，而不是通过已有构件组装而成的。

• 软件成本相当昂贵。

• 软件本身是复杂的。

3、软件危机 ：软件在开发和维护过程中遇到的一系列严重问题。

软件危机包含两层含义：

如何开发软件。

如何维护数量不断膨胀的已有软件。

4、软件危机的表现：

（1）软件开发的进度难以控制，经常出现经费超预算、完成期限拖延的现象。

（2）软件需求在开发初期不明确，导致矛盾在后期集中暴露，从而对整个开发过程带来灾难性的后果。

（3）软件文档资料不完整、不合格。由于缺乏完整规范的资料，加之软件测试不充分，从而造成软件质量低下。

（4）软件的可维护性差，程序错误难以改正，程序不能适应硬件环境的改变。

（5）软件价格昂贵，软件成本在计算机系统总成本中所占的比例逐年上升。

5、软件危机的原因：

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

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

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

（4）缺乏有力的方法和工具方面的支持，过分地依靠程序人员在软件开发过

程中的技巧和创造性，加剧软件产品的个性化。

1、软件工程

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

1、“软件工程” —-Software Engineering是研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件，即把工程化应用到软件上。

•1968年，“软件工程”这个术语第一次使用，作为一个会议标题，该项目由北约（NATO）赞助；该会议确认了要用定义最佳实践的方式帮助改善软件开发；

软件工程学研究的目标 ：

• 软件开发成本较低；

• 软件功能能够满足用户的需求；

• 软件性能较好；

• 软件可靠性高；

• 软件易于使用、维护和移植；

• 能按时完成开发任务，并及时交付使用。

采用先进的软件工程方法，使质量、成本和生产率三者之间的关系，达到最优的平衡状态。

软件生存周期：

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

注意：

在实践中，软件开发并不总是按照计划、分析、设计、实现、测试、集成、交付、维护等顺序来执行的，即各个阶段是可以重叠交叉的。整个开发周期经常不是明显地划分为这些阶段，而是分析、设计、实现、再分析、再设计、再实现等迭代执行。

软件生存周期的各个阶段主要任务 ：

1.计划阶段

确定待开发系统的总体目标和范围。研究系统的可行性和可能的解决方案，对资源、成本及进度进行合理的估算。

2.分析阶段

分析、整理和提炼所收集到的用户需求，建立完整的分析模型，将其编写成软件需求规格说明和初步的用户手册。

3.设计阶段（总体设计和详细设计）

设计阶段的目标是决定软件怎么做。软件设计主要集中于软件体系结构、数据结构、用户界面和算法等方面。

4.实现阶段（编码）

实现阶段是将所设计的各个模块编写成计算机可接受的程序代码。

5.测试阶段

设计测试用例，对软件进行测试，发现错误，进行改正。

6.运行和维护阶段

应当在软件的设计和实现阶段充分考虑软件的可维护性。维护阶段需要测试是否正确地实现了所要求的修改，并保证在产品的修改过程中，没有做其他无关的改动。维护常常是软件生命周期中最具挑战性的一个阶段，其费用是相当昂贵的。

1.1、软件工程三要素

1.2、瀑布模型（Waterfall Model）

1.3、RUP统一软件过程

1.4、扩展ICONIX过程

愿景、业务建模、需求分析、健壮性分析、关键设计、最终设计、实现

1.5、Scrum敏捷过程

1.6、统一建模语言

二、ICONIX软件过程

CONIX是尽早进入编码阶段，缩短分析设计周期的[软件开发方法] 合理的简化统一过程(RUP)， 基于[极限编程]和 [敏捷软件开发]的思想· ICONIX过程与 UML和RUP相比，是轻量级的过程。

如果能帮助客户“开源、节流”，客户就愿意购买我们的软件

需求是软件成功的基础，需求十分重要，并且贯穿整个软件开发的整个过程，需要引起足够的重视

1、需求工程：愿景

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

获取愿景的三步曲

• 第一步：找到软件项目的“老大”； ：老大就是要改善的组织中最有权力的干系人

• 第二步：得到“老大”对项目的期望（愿景）； 愿景不是功能

• 第三步：描述出愿景的度量指标；：描述愿景必须指出度量指标。愿景描述不是记录具体做了什么事，而是描述改善组织的哪些指标。

2、业务建模

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

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

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

1. 明确我们为谁服务（选定愿景要改进的组织）。
2. 要改进的组织是什么现状（业务用例图、现状业务序列图）。
3. 我们如何改进（改进业务序列图）。

最佳的研究范围就是愿景涉及的、需要改进的组织

2.1、业务用例图

2.2、业务序列图（现状）

• 业务序列图帮助我们从细节上了解组织的业务流程。

作用：

1. 识别业务对象：业务执行者、业务工人、业务实体；
2. 确定业务对象间的职责、协作及交互顺序；
3. 通过序列图来了解现状，为业务的优化提供依据；

业务工人[Business worker]

➢ 位于组织内部，负责业务流程中某些工作的人员。例如银行工作人员，医院医生。

2.3、改进业务序列图

改进点：信息自动流转 、封装复杂业务逻辑、职责的转移 、访问和操作业务对象

步骤：

1. 将“新系统”作为一个业务实体进行整体设计；
2. 将“新系统”引入组织现有业务流程；
3. 查看其可以改进的流程；
4. 评估改进结果；

2.4、小总结：

现状业务序列图和改进业务序列图的作用：

• 业务序列图展现企业内现有业务流程，暴露问题，为优化提供直观依据。

• 通过改进业务序列，可以提前模拟出新系统的出现，将对组织现行的业务流程造成哪些影响，可以提前评估新系统的可行性或提前进行相应的准备工作，实现安全平稳的组织改进。

3、需求分析，用例分析法

主流分析方法 ：

原型法是指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到用户满意为止的一种方法。

用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员实现这些元素。用例图最常用来描述系统及子系统。

3.1、域建模

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

• 域建模[Domain Modeling]

Ø域建模比普通的项目术语表优良的地方体现在：以图的方式清晰地显示出不同术语间的关系（减少理解偏差）。 

Ø描述业务中涉及到的实体及其相互之间的关系，是帮助系统分析人员、用户认识现实业务的工具。 

Ø域模型图将通过不断修正完善逐步演化为最终的静态类图。

3.2、系统用例分析

系统用例图：

3.3、系统用例建模：

步骤：

1. 绘制系统用例图

   1. 确定系统边界

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

   3. 识别系统用例

   4. 确定用例间的关系

      注意：
      用‘时间’执行者来标示预定的事件。用例命名：

2. 编写系统用例描述

基本路径注意点：

•客户最想看到的、最关心的路径。——核心的核心

• 把基本路径单独分离，凸显用例的核心价值。

• 与扩展路径相比，更为有序。

• 以主动语态、“名词-动词-名词”格式来书写。

• 如：银行客户-输入-密码；银行自助系统-弹出-储蓄卡

• 主语只能是执行者或系统。

1. 更新域模型

3.3、小专题：业务用例VS系统用例

3.4、功能性需求和非功能性需求

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

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

3、性 能：系统实现预期功能的能力的特性。

4、可支持性：系统在故障解决和系统升级方面的能力。

4、健壮性分析

需求与设计的桥梁：健壮性分析：健壮性分析帮助完善和确认需求分析的成果。

1、健壮性分析步骤：

更新域模型：

2、健壮性分析说明

• 在用例驱动的开发模式中，用例的准确完整性是关键；

• 健壮性分析技术两个主要的价值：其一帮助完善用例分析结果；其二完善域模型，作为需求分析走向系统设计的过度技术；

• 不要花费太多的精力和时间在本阶段，本阶段的成果也仅起到过度作用，不纳入最终文档；

5、关键设计

1、关键设计的意义和方法

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

基于用例图、用例描述和健壮性图，采用序列图来描述参与者、边界、实体之间的交互.

2、关键设计的步骤（最终：序列图和类图）

• 高内聚、低耦合。是判断设计好坏的标准。

• 高内聚是指一个软件模块(类)是由相关性很强的代码组成，只负责一项任务，

也就是常说的单一责任原则。

• 低耦合是指一个软件模块与模块之间的接口，尽量的少而简单。如果某两个

模块间的关系比较复杂的话，最好首先考虑进一步的模块划分，降低相互的

依赖。这样有利于修改和组合。

• 目的：使得模块的“可重用性”、“移植性”大大增强

6、详细设计

1、技术架构及相关考虑

• 选择开发语言

• 客观条件需要
• 客户要求
• 开发团队习惯

• 网络拓扑及安全

• 体系结构

三层体系结构：

多层体系结构：

• 硬件支持环境 ：

• 软件支持环境：数据存储设计 、交互设计等

2、详细设计范例

• 结合体系结构、编程语言、数据模型和设计模式等来细化类图；

• 调整序列图（为了清晰易读，可以考虑去掉执行者和界面层的部分，因为这部分没有复杂的逻辑）

3、详细设计之后：

• 编码 • 测试 • 部署 • 维护 • 升级

三、敏捷开发

1、认识敏捷开发

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

• 敏捷软件开发模式

Ø 敏捷开发的核心思想是以用户的需求进化为核心，采用迭代、循序渐进的方法进行的软件开发。

Ø 由传统迭代式软件开发模式发展而来，强调产品价值、团队协作、客户参与、先期验证、简化流程、拥抱变化。

Ø 总结吸收成功软件项目研发的最佳实践；与现代管理思想相辅相成。

1.1、敏捷宣言

软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品

软件开发顺应时代变化，从重型过程转向轻量型敏捷

2、敏捷误解

3、敏捷理念（层次）

核心理念：价值、团队、适应

1、聚焦客户价值，消除浪费

产品商业成功为目标，聚焦客户价值、围绕价值流消除浪费

2、激发团队潜能，加强协作

• 团队是价值的真正创造者，应加强团队协作、激发团队潜能• 软件开发是一种团队活动，首先应做到提升沟通效率降低交流成本

3、不断调整以适应变化

不断的根据经验调整，最终交付达到业务目标的产品

4、优秀实践（层次）

5、具体应用（层次）

四、Scrum 敏捷过程

1、过程概述

迭代式开发的好处：

2、涵盖内容

2.1、3 个角色（敏捷团队）

Product Owner

Scrum Master

Development Team

敏捷方式下对管理者最大的挑战是学会放松”控制” 、从被动到主动的心态转变是团队成员适应敏捷开发的关键

2.2、3 个工件

Product Backlog

Sprint Backlog

Product Increment

5 个价值观

勇气 专注 承诺 尊重 开放

5 个事件

Sprint、Sprint Planning、Daily Scrum、Sprint Review、Spring Retrospective

2.3、燃尽图

3、Scrum特点

4、Scrum会议及过程实践

4.1、迭代计划会议

4.2、每日站立会议

4.3、迭代评审会议

4.4、迭代回顾会议

5、敏捷工程实践

5.1、用户故事

用户故事特征：

• 体现客户（用户）价值，轻量级的占位符

• 遵循3C原则

Ø 卡片（Card）：作为XX，我希望XXX，这样可以XXX

Ø 对话（Conversation）：不描述到细节，由团队通过持续对话细化，激发大家的深度理解

Ø 确认（Confirmation）：有明确的验收标准

用户故事INVEST标准

• 独立性（Independent）：故事之间松耦合，具有独立性，不应该依赖于其他的用户故事。

• 可协商（Negotiable）：开始仅用于做占位符，逐步细化。

• 有价值（Valuable）：用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写。

• 可估算（Estimatable）：设计、开发、测试团队可估算工作量和成本。（不可估算的原因：太大需要分解，或信息不全需要进一步探索）

• 短小（Small）：故事应该尽量的短小（如两周冲刺，故事一般是2天以内的）

• 可测试（Test）：有相应测试验收标准。

5.2、结对编程

5.3、git

5.4、CodeView

5.5、测试驱动开发（TDD）

5.6、持续集成(CI)

五、极限编程（XP）

1、极限编程价值观：

沟通、反馈、勇气、尊重、简单

2、极限编程优点：

3、极限编程缺点：

4、极限编程说明：

5、极限编程开发过程：

6、XP与Scrum的异同 ：

不同点：

7、重构：

代码质量主要有正确性，可读性，可维护性，可扩展性、稳定性等

重构可以提升代码质量