软件工程的介绍

谁践踏了优雅 2022-05-23 12:28 271阅读 0赞

### 什么是软件工程 ###

###         **大概总结一下：就是一个研究如何让软件开发的过程变得更加规范，可控，流程化，工厂化的研究体系。** ###

**      如果你有耐心且想深刻了解，可以继续往下看：**

学了这么长时间的软件工程，相信有很多人对这门学科会产生很多的疑问，我在这里谈谈我个人对软件工程的理解和感受，希望对各位有所帮助和借鉴。如果大家有更好的想法也希望能够提出来一起交流。

首先谈谈什么是软件工程。相信大家肯定都听说过桥梁工程、道路工程等等这些名词，我们得理解工程这个词的定义，工程说简单点就是各个行业的工程师或者应用人员通过总结规律或者方法，以最短的时间和人力、物力来做出高效可靠的东西。**因此，我们也就能理解桥梁工程，其实就是人们通过经验的总结和各种研究得出来的、用来修建桥梁时所采用的高效的方法，当然这种方法是可套用的。那么我们将这个思想应用到软件上，于是就产生了一门新的学科—软件工程。**

以往，人们做软件基本上是没有章法可循，不知道该怎么去设计一个软件，很多时候只能凭一些在软件行业摸爬滚打了很多年的资深人士做出经验上的判断，这样得出来的软件不仅耗费人力物力，而且质量还得不到保证，同时维护起来也是困难重重。**于是为了能够实现软件的流水线式生产，在设计和构建软件时能够有一种规范和工程化的方法，人们便提出了软件工程这个概念。**

需要强调的是，目前有关软件工程方法真实本质的争论一直都在持续进行着，要真正将软件工程变成一个全成熟的学科，还有大量的工作要做。

**                                                                                       软件工程的内容**

目前，一个通用的软件工程过程框架通常包括5个活动：沟通-策划-建模-构建-部署。根据不同的过程模型(后文再介绍)这5个框架活动的顺序是不一定的。下面我们来一一介绍这5个框架活动的内容。

**    沟通**：一个软件在设计之前一定要充分了解客户的需求，不然得到的结果很有可能会南辕北辙，有很多软件系统都是在已经实现之后却发现跟客户的需求有很大差异，或者没有达到客户的期望，最后弄得双方都十分尴尬。这种案例就是前期的沟通没有做好，一方面客户的需求可能非常理想化，他们对软件的实现完全不了解，他们想达到的功能很有可能是目前技术还无法实现的，我们在沟通时一定要在他心中建立一个正确的观念。另一方面，客户可能自己都不知道要做一个具有哪些功能的软件，他们只是有一个初步的想法，这个时候就需要开发人员去引导，最好的方式就是提出各种版本方案让客户选择，最后再择优处理。很多人肯定都觉得软件开发大部分时间都花在编码，其实恰恰相反，一个软件的开发周期，其中一大半都是花在需求分析，也就是我们的沟通阶段。有一个例子就使我印象特别深刻。

我的大学数据库老师曾经接了一个医院数据库开发项目，然后他们团队负责需求分析的几个人就集体搬到了医院一个小房间住下来，然后天天"缠在"各个部门的负责人身边，问东问西，做各种数据的分析，例如医院的职位分配是怎么样的制度，每个部门有多少分职，药库是怎样管理的…等等等等。然而，就算是天天住在那里，都面临着各种阻碍。首先是对方不愿意也没有时间来做各种需求的统计(像医院这种地方，每个人都很忙)，其次他们自己也不太清楚自己的需求。甚至到了最后居然出现了某个部门的负责人常常不来办公室(躲着他们)的情况。可想而知，项目最后的结果也不太理想。所以，很多时候我们做软件开发的应该多多学习怎么样跟利益相关者打交道，引导他们做出准确的需求分析。说了这么多，足以见得前期的沟通有多么重要。

**   策划**：策划阶段就是要做出我们整个软件系统的“设计地图”，有了地图我们才能将旅程变得简单而且易于掌握。这个地图就是我们的软件项目计划，它包括需要执行的技术任务、可能存在的风险、需要用到的资源、整个项目的工作进度等等。

**建模**：顾名思义，建模就是建立我们软件设计的模型，最初的草图包括整个项目的体系结构、不同的组件模块之间怎么连接，以及其他的一些特性。最后经过不断的讨论与设计，对草图进行精化，得到每一个功能模块的具体类与接口，这样即使团队中有人离职，不得已让新人进来取代的时候，也能根据设计模型以及各种UML图游刃有余的进行编码，这也就是为什么要有一个图纸的原因之一。  
    **构建**：建模完了以后，我们就可以进行编码了，有了设计图纸，编码当然也就不再困难。但是要注意的是编码的时候要不断的进行冒烟测试(频率非常高的一种测试模式)，如果离项目的验收期限非常近了，还可以进行敏捷开发(一种团队集中在一起进行高强度、高效率的开发方式)。  
    **部署**：软件开发完成后，就可以交付给用户了，将我们的软件部署在用户端系统上，用户对它进行评测并给出反馈意见。

到此为止，我们软件工程的五大过程框架就简单的给大家介绍了一遍，其实研究的最多的也就是这几大活动，但是这几个过程的执行顺序在现实应用中都不会是线性的一步接一步，往往在编码的时候还有可能在做需求分析，也有可能会先开发出系统的主要功能，然后再慢慢往上加其他的拓展功能。这就不得不提软件工程的过程模型。

### 过程模型 ###

最早提出过程模型就是为了改变软件开发的混乱状况，使软件开发更加有序。这里我就介绍几种常见的过程模型。

**瀑布模型**：这是一种经典的模型，顾名思义，瀑布就是顺流而下的，瀑布模型也是一种线性的、顺序的软件开发方法，从最开始的沟通，到最后的部署，一步紧接一步线性执行到最后。因此我们也能想象，实际的项目是很少遵守瀑布模型提出的顺序的。因为瀑布模型要求客户具有十分明确的需求，这在现实中是基本不存在的。

![20180608184001727][]

**增量过程模型**:即前面所提到的先开发出系统的核心功能,然后再依据重要性评估交付新添的增量,直到最终产品的产生。

![20180608184027893][]

**螺旋模型**:螺旋模型在瀑布模型的基础上加了风险分析,同时迭代式的开发一系列的演进版本。螺旋最中间的就是项目的起点,螺旋式的进行着五个框架活动,一直进行到螺旋最外圈。螺旋模型是开发大型系统和软件的很实际的方法,像大型的军工软件系统都是使用的螺旋模型进行开发的,而且像这种系统的螺旋终点是没有的,因为军工产品需要不停地进行更新迭代,不然很快就会被时代淘汰。

![2018060818360422][]

螺旋模型

相信大家看到现在应该对软件工程已经有了一个大体的了解。

[20180608184001727]: /images/20220523/01cb3b0d6dc34fa0986dfd9d397ee486.png
[20180608184027893]: /images/20220523/daf2eda9eb54473fbf75548ea6c3de5c.png
[2018060818360422]: /images/20220523/6ad4c2da44aa4a55a595476fe7f82634.png