1.2 软件工程在线视频

大家好

我是北京理工大学计算机学院

车海莺

今天我们来分享

关于软件工程这个主题

首先

在讨论软件工程之前

我们来看几个事实

在确定软件的方案之前

需要我们共同的努力来理解这个问题

然后才有可能设计出软件来解决这个问题

第二

设计已经成为

软件工程当中的一个非常关键的活动

因为软件是一个很复杂的东西

我们一定要需要一个

详细

周密

谨慎的设计

才有可能把这个复杂的问题

给解决

第三个

我们设计开发的软件

应该具有很高的质量

因为如果

软件的质量不高

会导致软件的使用性能非常差

或者是在有意外情况发生

会导致软件系统的

瘫痪等等一系列的问题

还有我们的软件应该是要具备一些可维护性

因为当有一些变化

或者是有一些问题没有考虑到

我们可以

需要对软件进行一些维护性的修改

所以我们的软件必须要具备可维护性

那么到底什么是软件工程呢

IEEE给出了一个软件工程的定义

他说

软件工程首先

第一点是将系统化的

规范化的

可量化的方法

应用在软件的开发

运行

和维护上

即我们要将工程化的方法

应用在软件这件事情上

这是第一点

那么第二点

第二点就是说

我们在把工程化的方法

应用在软件这件事情上的时候

所做的相关的方法的研究

也属于软件工程的范畴

软件工程是一个层次化的技术

我们可以看一下这张图

这张图上显示的软件工程包括四个层次

最下面最重要的就是

支持软件工程的根基

在于质量关注点

也就是说

我们在设计开发一个软件的时候

我们首先要搞清楚

我们最关注的

重点

最关注的特点

在什么地方

然后我们会根据关注的特点

和关注的功能点等等

来设计我们的软件的过程模型

软件过程是将各个技术层次结合在一起

使得能够合理及时的

开发计算机软件成为可能的

一个模型

过程定义了一个框架

构建该框架

是有效的实施软件工程技术

必不可少的一个环节

那么在搞清楚了质量关注点之后

我们定义了一个过程模型

根据质量关注点定义出来的过程模型当中的

相应的

活动

相应的

任务

当我们得知了这样的活动和任务之后

我们才会针对我们需要做的活动和任务

去选择合适的方法

在选择好了方法之后

我们就会知道

我们要用什么样的工具

来去支撑我们的方法

所以我们说

软件工程是从质量关注点为基础

定义出来过程模型

和过程模型中的活动和任务

根据过程模型的活动和任务再向上

来选择

做这些活动和任务需要的方法

在方法之后

我们再使用工具

来实现我们的方法

这样的一个四层次的一个模型

那么我们看一下过程框架

我们说在刚才的层次化技术当中

找到了质量关注点之后

我们就要定义过程了

那么定义过程的时候

我们就要需要有一个过程框架

什么是过程框架呢

过程框架里面要定义一些过程的活动

这些过程的活动

包括沟通

策划

建模

建模在软件里面我们有需求分析建模

和设计建模

在建模完成之后

就要进行构建

构建包括我们的编码实现

和我们对程序进行测试

在构建结束之后得到了正确的软件以后

我们就要对软件进行部署

这个五个活动

就是我们的过程框架活动

除了过程框架活动

我们还有一些普适性的活动

普适性的活动

是要贯穿在整个软件工程所有过程当中的

比如我们有一些调整性的活动等等

那么在每个活动中都会存在很多的动作

在每个动作当中又会存在很多个任务

然后对于每个任务

我们可能都需要有工作任务的描述

这个任务的工作产品

这个任务的里程碑

和可交付的成果

以及这个任务的质量检查点

QA检查点

那么普适性的活动有哪些呢

比如

我们有软件项目的跟踪和控制

这样的项目跟踪和控制

需要在软件工程的开始

一直到最后

都会存在

还有我们的风险管理

在软件开始沟通之后

我们还有测试

开发等等这一切环节里面

都需要有风险管理

还有第三个普适性活动

是软件质量保证

对于每一个活动当中

比如沟通活动

我们产生需求规格说明书

那么这个说明书的质量

我们需要保证

在设计环节

我们会产生一些

设计结果

设计成果或者是设计文档

那么设计文档我们也需要进行质量保证

所以软件质量保证

也是一个普适性的活动

它是贯穿到框架活动当中的所有活动当中

另外我们还有技术评审

那么在质量保证的过程当中

可能需要技术评审这样一个活动

还有普适性活动包括

测量

软件配置管理

和可复用管理

还有从工作产品的准备

到工作产品的生产等等

所以我们说

普适性的活动是贯穿整个软件过程中的

主要关注项目的管理

跟踪和控制

还有

我们的过程

在任何时候可能都需要做一些适应性的调整

比如我们的活动

动作

还有任务的总体流程

以及之间的相互依赖关系

可能随着软件工程的进行

需要进行一些适应性的调整

还有在哪个框架活动中

动作和任务的细化的程度

也需要根据实际情况来进行调整

比如说

如果大家对某个动作或者是某个任务

了解的比较清晰

我们就可以不用把它细化的那么详细

如果大家对某个动作

或某个任务的活动

没有达成共识

我们只需要把它描述的详细一些

另外一个适应性调整的工作就是

我们对工作产品的定义

和要求的程度

当我们对工作产品把握的比较好的时候

我们的定义就可以粗粒度一些

如果工作产品定义把握的不好的时候

我们就需要把它定义的详细一些

还有质量保证活动的应用方式

也是需要根据实际情况来进行调整的

另外

项目的跟踪和控制活动的应用方式

过程描述的详细程度和严谨程度

客户和利益相关者对项目的参与程度

软件团队所赋予的自主权

队伍组织和角色的明确程度

这些都是需要做适应性的调整的

因为

比如

我们软件团队所赋予的自主权

可能根据每个个体的自主性不同

可能赋予的自主权程度也不同

这些都是一些灵活的

主观的

需要根据实际情况

做适应性调整的一些个活动

而不是能够严格的去把它规定下来

那么既然有刚才我说的那么些适应性的调整

那一些专家

在软件工程实践当中给出了一些建议

比如我们的Polya

给出的建议是

我们的实践当中

应该注重理解问题

也就是沟通和分析

对问题的理解的时候

需要与客户进行充分的沟通

然后

沟通之后

对客户提出的问题要进行详细深入的分析

这就是我们要进行理解问题这样一个活动

在理解问题之后呢

我们就需要计划解决方案

计划解决方案在软件这个

在软件这个领域当中

它应该包括我们的建模

和软件设计

第三个比较重要的活动就是要实施计划

我们在找到了解决方案之后

我们要把计划进行实施

让它实际的产生效果

那么对于我们的软件领域呢

实施计划就是进行代码的生成

最后检查结果的正确性

检查结果的正确性呢

我们对于软件来讲

就是要进行软件的测试

和软件的质量保证

这里面给出的四项建议是在软件产生之前

就已经存在的

重要的建议

理解问题

计划解决方案

实施计划

检查结果的正确性

但是这四项建议对于我们的软件领域

也是同样适用的

那么对应到软件里面就是我们刚才提到的

沟通和分析软件

建模和软件设计代码生成

以及测试和质量保证

那我们分别看下刚才说的这四个关键的问题

首先理解问题

在理解问题的时候

可能我们要考虑以下几点

谁将从问题的解决当中获益

也就是说我们要先分析出来

谁是利益相关者

大家直觉想到的就是

用户是利益相关者

那么用户会包括哪几类人群

有哪几类角色的用户

这些都是我们在理解问题的时候

需要想清楚的

第二个是

有哪些是未知的

哪些数据功能和特征

是解决问题所必须的

我们要解决一个问题的时候

一定要把这个问题的背景

把这个问题的前提条件都搞清楚

那么在我们要去做一个软件的时候

那么哪些问题是我们还不了解的

那我们要到哪里去收集数据

如何处理这些数据

要产生什么样的一些输出

这些都是在理解问题的时候需要想清楚的

我们在理解问题的时候还需要考虑的就是

问题是否可以划分

我们知道有一个观众点分离的原则

就是当我们要解决一个大的

复杂的问题的时候

如果可以把它拆解成几个小的

更容易理解的问题

那么我们解决问题就会变得简单一些

容易一些

所以当一个大的问题可以进行划分的时候

我们就把它划分成更小的

更容易理解的问题

第四个在理解问题的时候需要考虑的是

这个问题是否可以用图形化来描述呢

如果它可以建立分析模型

进行图形化描述

这样就可以有助于我们

共同的一起理解这个问题

把这个问题理解的更加深入

我们说图形会胜过于文字

对于我们软件工程人员进行理解和分析问题的时候

图形要比文字会清楚

那么第二个重点就是要计划出解决方案

在计划解决方案的时候

我们要考虑

以前曾经见过类似的问题吗

如果有潜在的解决方案了

那我们是否可以识别出来一些模式

然后把这些模式进行

套用

复用

是否已经有软件实现了所需要的数据

功能和特征呢

如果有

我们是否可以把已经实现了的软件

拿过来借鉴呢

这是在计划解决方案的时候考虑的第一个问题

在计划解决方案考虑的第二个问题是

类似的问题是否解决过

如果已经解决过

那么他的解决方案中

是否可以包含

我们可以复用的一些元素

第三个就是

可以定义子问题吗

这个解决方案

如果可以拆解成小的子问题

那么可能某个子问题是有解决方案的

比如我们要设计一个web网站

可能这个网站的格局是新的

但是这个网站里面包括的下拉框

输入框

或者是

按钮

可能其中的某个部分

就是已经解决的

可以拿来复用的

第四个在计划解决方案的时候

我们可以想

我们是否可以用一种可以快速实现的方式

来描述这个解决方案呢

也就是

快速实现的方式

通常是构建出来它的

设计模型

或者是一些原型

如果我们可以有一个快速的实践方案

来描述这个解决方案

那我们可以

更直观

更快速的来验证解决方案是否有效

第三个

我们在找到了解决方案之后

我们就要进行实施计划了

实施计划的时候

我们要考虑

解决方案和我们的计划一致吗

也就是

我们的代码实现的功能

是否与我们的设计模型

和需求分析模型里边的功能点保持了一致呢

第二个

我们的解决方案呢

每个组成部分

是否是可以证明是正确的呢

我们的设计和代码是否经过了评审

或者其他的更好的方式

来验证它的正确性

我们的算法

是否已经

经过了正确性的证明呢

那我们在实施的时候

一定要保证我们实施的结果

实施的这个成果的正确性

那么为了保证正确性

我们的第四个步骤就是要

检查结果

我们能够测试解决方案的每一个部分吗

我们是否实现了合理的测试策略

解决方案是否产生了与所需求的

数据

功能

和特征一致的结果

也就是

我们是否按照了项目的利益相关者

所提出的需求

而进行了确认

那么再直接一点的解释就是

我们生成的代码和功能

是否给了我们的客户

或者其他利益相关人

进行确认

我们的功能的确满足了他最开始

要开发这个软件

预期的一些需求呢

这个就是我们要检查结果的

正确性

需要做的工作

那么我们有一些

在软件开发和软件工程当中

需要考虑的一些概括性的原则

第一是存在价值

我们软件一定要能够提供客户需要的功能

这个软件

才有它的存在价值

第二个我们是要保持软件的简洁

我们设计软件不需要把它设计的复杂

设计的多么高深

只要能够实现客户预期的功能

我们让它越简洁越好

这就是我们的

Keep It Simple & Stupid

保持简洁的原则

第三个

我们要保持愿景

在项目初期

我们共同与客户商量了该项目的愿景

我们应该随着项目的进展和软件的开发

要保持我们最开始的初衷

而不要偏离

第四个我们要关注使用者

也就是说

我们要时时刻刻站在用户的角度

来考虑我们的软件的设计

和软件功能的实现

是否是真正解决了客户的问题

是否是方便客户来使用

第五呢 我们要面向未来

我们知道

我们的软件技术的发展是非常迅速的

我们的硬件环境

和软件技术架构等等

都会有新的变更

那我们的软件设计应该具有一定的

拓展性和扩展性

使得在一定的变更的范围内

我们的软件仍然可以适用

第六个原则就是要

考虑到复用

在软件设计之初

我们是否就可以考虑到

有些功能是可以被复用的

把它的单独

独立出来

进行设计和实现

所以我们要对复用进行有效的计划

最后一点原则就是要认真思考

当我们已经要考虑好

要实现一个功能

或者是一个程序的时候

我们是需要反复的考虑这样的实现方法

是否是合理的

有没有更好的实现方法

也就是我们要实现软件的时候

要进行三思

我们的每个软件工程的项目

都是来自于业务需求的

这个业务需求可能是对

现有的应用程序的缺陷的修正

也可能是改变遗留系统

来适应新的业务环境

也有可能是扩展现有的应用程序的功能和特性

或者是需要我们开发出某种新的产品

服务

或者是系统

所有这些都是来自于业务需求的

那我们的软件工程一切

都是应该以业务需求为出发点

以上就是我们对软件工程的一个理解

今天我们的讨论就到这里

谢谢大家