Software Engineering

软件工程学,研究和应用工程的方法来设计、开发和维护软件。

在工程领域里,软件工程非常年轻,开始于20世纪40年代早期,但直到1968年才开始使用“软件工程”这个术语,截止到目前为止,对此术语仍有很大争议:软件工程到底意味着什么,这是最恰当的术语吗?其他术语,如软件开发和信息技术也被广泛用来指代软件工程。

1. 软件工程的历史与发展趋势

历史部分主要参考:http://en.wikipedia.org/wiki/History_of_software_engineering

1.1. 发展趋势

从发展历史看,早期的软件工程主要强调朝明确分工、精确控制,而到了20世纪80年代后开始加强了成本和效益的考量。

也就是说,不能只满足于正确的做,还要考虑怎样做是满足要求且成本最低;不能只考虑怎样实现功能,还需要考虑怎样卖掉功能、卖出更好的价钱。这无疑是又扩大了原有的软件工程领域范围,对业界人士提出了更大的挑战!

2. 软件工程知识体系

现代普遍接受的软件工程实践已经被编纂成软件工程指导知识体系( SWEBOK ),成为国际公认的标准(ISO / IEC TR 19759:2005)。

按照SWEBOK V3,把软件工程划分成15知识域 (Knowledge Areas) ,我简要描述一下:

看到这些,不知道大家是否觉得有点儿晕,觉得写个代码咋搞得这么复杂啊。要知道,软件虽然是跑在电脑上,但还是由人脑来开发、为人所用的;而人脑能力有限(大脑处理速度和容量的局限)、人肉系统的心理活动又难以捉摸、加上IO的表达和传输的模糊性,一个组织要具备按时按需交付可用软件的能力,必须把人管起来,可一旦涉及到人,就不可能是一件简单的事情!

但这个知识体系看起来也还是太复杂了啊,让我们从更加实用的角度进行一些裁剪吧:为了按时交付满足需求的软件,我们需要从过程角度来规范软件项目干系人的行为;从方法和技能角度来帮助开发人员应对过程中的复杂性;然后用工具来彻底贯彻这些过程和方法。所以,简化后的软工体系用金字塔结构来描述,分为以下三层:

PMT.png

2.1. 过程

开发一个软件项目,选一个过程框架参考,结合项目实际情况进行合理裁剪;项目管理者要搞明白项目的意义,理解自己所选过程的适用范围和优劣点

2.1.1. 容易混淆的概念

增量与迭代在软件开发过程中经常被大家挂在嘴边,增量经常和迭代连在一起说,不过两者是有区别的。增量是逐块建造的概念,迭代是反复求精的概念。二者不一定要绑在一起使用,但很明显,结合这两种方式是一种有效的做法。现在很多过程所说的迭代开发,默认的意思就是 增量 & 迭代。 增量:

迭代:

2.1.2. 实践过的一些过程框架

2.1.2.1. Agile

2001年发布了敏捷宣言,之后流派众多:

Agile.png

2.1.2.2. 过程评估和CMMI

过程评估和CMMI,很好的过程改进和实践模型;

2.1.2.3. Unified Process

2009年出现了UML、4+1视图模型和RUP RUP(Rational Unified Process)的中心思想是:用例驱动、架构为中心、迭代和增量。

后来大统一成为Unified Process:

UP_UML.png

2.1.3. 关键活动

2.2. 方法

2.2.1. 高内聚、低耦合

2.2.2. 实体/关系

2.2.3. 数据流

2.2.4. UML

2.2.5. 模式运动

2.3. 工具

2.3.1. 设计

2.3.2. 应用生命周期管理(ALM)

2.3.3. 自动运维

3. Reference

3.1. 软件工程历史和发展

3.2. 软件工程经济学

3.3. 软件工程师

3.4. 过程与实践


CategoryMethodolodge

MainWiki: Software_Engineering (last edited 2014-06-26 21:19:35 by twotwo)