我们是否需要软件工程_软件工程

　　∮幸坏愦蠹铱梢源锍晒彩兜木褪牵绻桓鱿骔indows这样的操作系统，不进行全面的规划，不采用软件工程的思想和方法，是绝对搞不出来的。

　　Windows的成功不在于它在进程治理和调度，文件系统、内存治理、界面设计等方面有多少成功的创新，它的成功最大的一点就是把所有的技术能够合理的整合起来，并集中到一个Window操作系统特有的框架结构中去。

　　更为重要的是，Windows的每一项技术创新都能够有效的整合到Windows框架中去，比如COM、XML等技术，通过ActiveX、DCOM等技术使Windows从桌面操作系统发展成为一个基于网络的操作系统。

　　OLE2技术把整个Office中相关的软件进行了有效的整合，显然，这里我们可以把Office的设计和WPS的设计进行比较，客观的讲，WPS对中国用户来说实在也是一个很好的产品。但是从整个系统设计概念上来讲，Office显然要比WPS高一个层次，它能够把Word，Excel，Powerpoint，Access有效的整合在一起，使我们所有办公相关的文档、图表、数据库、演示变成了一个一体化的东西。而且通过宏调用，用户可以自己定制用户界面并编制适当的模板，单是这个二次开发功能就不是WPS现在所能及项背的，当然限于当前用户的水平还很少有人使用二次开发的功能。

　　从微软产品系列可以看到软件工程的作用，微软的所有产品都有一个整体的框架结构，比如Office软件，通过OLE技术进行有效的通讯和联系。比如Visual系列开发工具，提供了相似的开发界面使用户学会一种开发工具以后能够很轻易的学习其他的开发工具。比如SQL SERVER和ACCESS，尽管它们适用的范围不同，但是它们表现给用户的界面，非凡是在查询和分析上表现了高度的一致性。

　　更值得一提的是，因为设计结构的合理性，因为在开发前期作了很多分析和调研，考虑了扩展性和伸缩性，微软的系列产品能够很快的利用新的技术并采用统一的结构形式表现出来。比如当网络成为计算机发展的主流的时候，几乎微软所有的工具都能够快速的支持基于网络的开发和应用。
　　相比之下，我们国内很多公司的产品很少具有连续性，往往是新的一个产品完全重起炉灶，和老的产品没有半点关系。这就是我们在设计产品的时候，没有很好的进行抽象和概念、逻辑设计，造成的结果是从旧的产品中提取不出一些有用的、共性的东西为后来的产品所使用。

　　当然，很多开发人员从心里也承认一个大的系统确实需要软件工程的依托? 是一个小的工程项目是否就可以仓促上马呢？答案是否定的。所谓麻雀碎小，五脏俱全。无论是大项目、还是小项目。它们作为一个项目，都需要有一个需求分析、系统结构建立、设计、编码、测试等阶段。这是任何一个项目都不可缺少的。

　　往往可以看到很多大公司的IT部门的人员都在不停的作各种各样的报表，当各个部门提出一种新类型的报表的时候，就从数据库中提取相应的数据并画出业务人员所需要的样式结构，很少是提供了一个通用的模板，当然提供高层API接口进行这种操作的就更少了。这样不可避免的使开发人员陷入一些琐碎的报表编制工作。而造成这个局面的很重要的一个原因就是没有在系统开发的前期进行很好的调研、需求分析和系统体系结构的设计。

　　这里就我们开发过的一些小型软件项目来谈一些开发的总结和体会，一般来说，小型软件项目功能比较单一，而且模块与模块之间的衔接不是很多，同时对开发周期要求比较短。

　　小项目虽然看起来比较简单，所以很多开发人员轻易犯一些错误，记得我们在开发一个基于Internet的有偿服务系统的时候，有三个开发人员：一个负责前端界面的编写，一个负责数据通讯协议和实现（基于TCP基础上的应用协议），一个负责对数据库数据的查询、整理和提取。我们在开发的时候没有认真地进行项目实际前途和工作量的估计。没有认真地估计项目难度，比如对于通讯中多用户并发访问时的多线程问题和缓存处理问题，用户批量请求处理的实现复杂度问题等等。三个人之间的接口也是在开发中休息的时候，口头定义一下。结果发现有不严密的地方(比如在通讯服务器端是用VC编写的，开发人员是通过stream来传送数据的，客户端是用Delphi编写，在接收数据的时候发现数据不准确，后来研究发现VC利用CSocket在传送数据流的时候对数据进行了自己定义的格式化，结果服务器端数据发送模块只好重写)，而且其中关于一个接口双方的理解不同，然后又返工重新修改。最后到系统基本完成的时候没有一份较正式的文档。然后因为有人毕业离开这个项目，然后他编写的模块需要升级，新的接收的人不得不花很多时间去阅读他的源代码。
　　所以在开发小项目的时候也必须要建立合理的模式：而所谓合理的模式就是软件工程告诉我们的在开发一个项目的时候所需要的五步曲：获取需求、需求分析、设计、编码、测试。

　　1．理解用户真正的需求。在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。

　　我们软件项目可以大致分为专用软件和通用软件两大类。对于专用软件，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。

　　但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子，这里最好就采用原型化的方法作出一个简单的框架给用户看。

　　对于通用软件，在开发之前必须做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场有多大，一方面是从技术的角度，了解清楚潜在用户对软件的各种技术上的要求，另一方面是确定我们软件的定位，即我们软件具体是为哪一些用户群体服务的。然后对该群体用户现有硬件配置，软件配置，网络使用情况，数据库使用情况，计算机熟悉程度做一定的调研，根据调查的统计结果决定即将开发的软件的一些技术指标。
　　
　　2．需求分析。需求分析需要做的事情有：高层构思、确立系统目标、划分业务领域、现行业务分析、建立业务模型(Enterprise Model)、信息需求分析、用户视图规范化、数据元素标准化与一致性控制。

　　在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，一般我们可以面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。

　　为了讨论软件运行的流程，可以采用UML的Use Case图。在系统分析的时候需要明确应用域（application domain）的范围，然后明确我们系统需要做什么。同时我们需要决定用什么方法来完成需求的获取，这在很大程度上影响了需求分析的做法。
　　例如可以采用Use Case来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。另外分析需要与设计过程相衔接。

分析过程的内容是用对象和对象之间的关系来表示整个系统和系统的流程的，并不设计具体实现，如采用什么编程语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。

　　面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。现在很多CASE工具并不区分分析和设计的阶段。但是，这并不意味着开发就可以对分析和设计不加区分，如何用好辅助设计(case)工具还是开发人员的事情。

　　3．设计过程。设计阶段的工作包括对分析模型进行必要的修改，同时可能需要对某些类结构做一些修改，确定用户表示层(也就是通俗所说的界面定义)、用户服务层、业务逻辑层、数据库服务层和具体数据库所需要做的工作。同时需要确定使用的体系结构（比如B/S还是C/S）和开发工具（如VB，VC，VI，C++ Builder，DELPHI，PowerBuiler等等）

　　4．编码。进入编码工作之后，依然可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。同时在编码前规定编码的风格并在开发过程中保持一致的风格。

　　5．测试。测试是系统投入使用前最要害的一个步骤。即使是小项目也应该严格地进行测试。就实际上就是一个把错误留给自己还是留给客户的问题。

　　最后，我们知道软件项目主要是由开发人员完成的，所以对人员的合理安排和配置也很重要，一般在开发过程中，需要有一位项目负责人，负责分析、设计和协调的工作。另外需要几个程序员完成不同层的代码（比如用户服务层、业务逻辑层、数据库服务层等等）。

　　同时需要有一个文档整理人员随时整理系统开发过程中相关的文档。假如条件可能的话，要配置一个测试工程师，专门进行代码的测试工作，当然假如条件不答应的话，也可以由开发人员交叉测试。这里需要注重的是，对于项目负责人而言，协调几个人的工作比自己完成一段编码更重要。

　　由于协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。同时必须给每个开发人员明确的任务书。具体开发时每个开发人员必须非常明确自己的任务，这些任务应该采用明确的文档来表示。每个开发人员需要清楚自己所做的工作在整个系统中处于什么地位，这样就有可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。