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

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

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

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

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

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

过程模型

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

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