版权声明：本文为博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。 本文链接：https://blog.csdn.net/iteye_7744/article/details/82397813

引言

软件开发者的困扰：设定具体目标，预测达成这些目标所需的资源，管理客户的期望。(More often than not, the moon was promised, a诀 lunar rover built and a pair of square wheels delivered.)

 

工程师经常面对定义糟糕的问题和片面的解决方案， 并且不得不依赖经验得来的方法去评估解决方案。

 

生词：

desolate: 荒凉的，孤单寂寞的

lunar rover: 月球车

off-the-shelf: 现成的，成品

empirical: 经验的

难题到底是什么？

Complexity and change

 

1.1  历史上的软件工程灾难

• Year 1900 bug
• Leap Year bug
• Interface misuse
• Security
• Late and over budget
• On-time delivery
• Unnecessary complexity

这些灾难都可归结于软件相关的难题：

1. 开发者没有预料到极少发生的情况(seldom-occurring situation)

2. 开发者没有预料到用户会错误的使用系统。

3. 来源于管理失误的系统错误。

 

软件工程的复杂性：

1.  它执行许多功能，达成去多不同的，但经常冲突的目标。

2. 它由许多部件组成，部件本身就是定制的复杂的。

3. 参与者有不同的背景和习惯。

4. 软件的开发过程和生命周期经常跨越许多年。

5. 复杂的系统很难有一个人去理解。

 

Vaporware: 雾件（一种已经发布或交易但未生产的新软件）

 

软件开发服从于持续的变化。 因为需求是复杂的，所以当发现错误和当开发者对应用有更好的理解时， 需求是要更新的。

技术变化之间的时间经常短于项目的时间。

 

1.2 什么是软件工程？

• 软件工程是一个建模活动 。
• 软件工程是一个解决难题的活动 。
• 软件工程是一个获取知识的活动 。
• 软件工程一个基本理论驱动（rationale-driven）的活动 。

建模活动

通过一次只关注相关的细节而忽略其他，软件工程师通过这样的建模来处理复杂性。

 

解决难题的活动

通过实验寻求可接受的解决方案。软件工程人员受制于预算和期限，常因缺乏基础理论而不得不依赖实验的方法衡量不同可选方案。

 

获取知识的活动

知识的获取不是线性的，因为一个新得到的数据可能是整个模型无效。

 

基本理论驱动（rationale-driven）的活动

软件工程师需要捕获上下文及其蕴含的基本原理，才能做决策。

1.2.1 建模

三种主要的系统：

1. 自然系统
2. 社会系统
3. 人工系统

一个模型是一个系统的抽象表示，它使我们能回答关于系统的问题。通过模型我们就能见到并理解不再存在的或者仅仅是宣称存在的系统。

 

一个系统可以分为两种实体：

1. 真实世界系统 以一组组现象表示
2. 应用领域模型 以一组组相互独立的概念来表达

软件工程师面对同样的问题：

1. 理解系统所在的环境，建立应用领域模型 (model application domain)
2. 理解所建的系统，评估不同方案进行取舍，建立解决方案领域模型 (model solution domain)
3. 面向对象方法 将这两种建模活动统一起来 (object-oriented method )

1.2.2 解决问题

五个步骤：

1. 系统描述问题
2. 分析问题
3. 寻找解决方案
4. 决定合适的方案
5. 明确方案

软件工程需要试验，重用已有模式，逐步向客户可接受的方案演进。

 

面向对象软件开发通常包括六个开发活动：

需求提取，需求分析，系统设计，对象设计，实现和测试。

需求提取和分析产出应用领域模型。

系统和对象设计得到解决方案领域模型。

 

软件工程不同于其他科学的方面在于应用和解决方案不时变化。

 

1.2.3 获取知识

A common mistake that software engineers and managers is to assume that the acquisition of knowlege needed to develop a system is linear.

 

Risk-based development attempts to anticipate surprise late in a project by identifying the high-risk components.

Issue-based development attempts to remove the linearity altogether.

The difficulty with nonsequential development models, however, is that they are difficult to manage.

 

1.2.4 基本原则 （rationale）

背景知识上下文对软件工程至关重要。

 

1.3 软件工程学概念

一个工程由多个活动组成；每个活动有一些任务组成。一个任务消耗资源，产生工件。一个工件可以是一个系统，一个模型或者一份文档。资源可能包括参与者，时间和设备。

 

1.3.1 参与者和角色

客户、开发者、项目经理都是参与者。

职责的集合称为角色。

一个角色和一组任务相关联并被分配给一个参与者。一个参与者可以分饰多个角色。

 

1.3.2 系统和模型

相互关联的部分的集合称为系统。

建模是一种通过忽略不相关细节来处理复杂性的一种方法。模型是系统的任一抽象。

 

1.3.2 工件

工件是开发过程中生产出来的一个人工制品。

如果这个工件仅是工程的内部需要，我们称之为内部工件。

交付给客户的工件称为交付物(deliverable)。

 

1.3.4 活动，任务和资源

活动是一组为达成特定目的的任务的集合。

活动也可由其他活动构成。

 

任务表示可以管理的最小工作单元。它消耗资源，产出工件。

 

1.3.5 功能与非功能需求

功能需求是系统必须支持的功能说明。非功能需求是对系统操作的限制。

 

1.3.6 符号表示，方法和方法学

符号是为表示模型所定义的一组图形的或者文本的规则。

方法是可重复的技术，这种技术明确了为解决一个特定问题的步骤。

方法学是解决一类问题的方法的集合，说明了方法何时如何使用。

 

软件开发方法学将过程分解为活动。

OMT给三类活动提供了方法：

1. 分析 将系统需求规范为对象模型
2. 系统设计 关注策略性决策
3. 对象设计 将分析模型转换为可以实现的对象模型。

1.4 软件工程开发活动

开发活动通过构建和验证应用领域模型或系统来处理复杂性。开发活动包括：

• 需求提取
• 分析
• 系统设计
• 对象设计
• 实现
• 测试

 

1.4.1 需求提取

客户和开发者共同定义系统的目的。

此活动产生用参与者和用例描述的系统。

 

1.4.2 分析

在分析阶段,开发者致力于建立一个正确的，完整的，一致的，清晰的系统模型。

 

1.4.3 系统设计

在系统设计阶段，开发者定义工程的设计目的并将系统分解为可由小组实现的多个子系统。

分析和系统设计都产生构建中系统模型，分析仅处理客户能理解的实体。而系统设计处理更加细化的模型，这个模型包括许多超越客户理解和关心的客体。

 

1.4.4  对象设计

开发者定义解决方案领域对象，在分析模型和系统设计中定义的软硬件平台之间架起桥梁。

这包括了精确描述对象和子系统接口，选择现成的组件，重构对象模型以完成诸如可扩展性或可理解性之类的设计目标。

 

1.4.5 实现

开发者将解决方案模型翻译成代码。

 

1.4.6 测试

开发者通过使用采样数据执行系统来找出系统与模型之间的差距。

 

1.5 管理软件开发

1.5.1 沟通

未处理沟通问题，工程参与者有许多可用的工具。最有效的是惯例：如果参与者能在用这些方面达成一致，他们就能清除掉那些误解的因素：用哪些符号表示信息，用哪些工具操作信息和用哪些过程提出和解决问题。

1.5.2 基本原理管理

基本原理是做决定的立足点。这个立足点包括：要解决的问题，开发者考虑过的可选方案，开发者用来评估可选方案的标准，开发者为达成一致而进行的辩论，以及决策。

1.5.3 软件配置管理

监事和控制工件中变化的过程。（Change pervades弥漫software development.)

配置管理是开发者能跟踪变化，也能控制变化。

1.5.4 工程管理

工程管理是一系列监管活动保证在一定预算内及时交付高质量的系统。

1.5.5 软件生命周期