6 开发小组的人员应少而精
　　开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。
　　这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少的多； 当开发小组为N人时，可能的通讯信道为N(N-1)/2, 可见随着人数N的增大，通讯开销将急剧增大。

　　7 承认不断改进软件工程实践的必要性
　　遵从上述六条基本原理，就能够较好地实现软件的工程化生产。但是，它们只是对现有的经验的总结和归纳，并不能保证赶上技术不断前进发展的步伐。因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。根据这条原理，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据既可以用来评估新的 软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。

      面向方面的编程（Aspect Oriented Programming，简称AOP）被认为是近年来软件工程的另外一个重要发展。这里的方面指的是完成一个功能的对象和函数的集合。在这一方面相关的内容有泛型编程（Generic Programming）和模板。

参考
      胡崑山，《中国软件产业发展现状与人才需求》，2003年9月1日，            http://software.ccidnet.com/pub/article/c372_a62973_p1.html

三、软件工程的目标与常用模型

      软件工程的目标是提高软件的质量与生产率，最终实现软件的工业化生产。质量是软件需求方最关心的问题，用户即使不图物美价廉，也要求个货真价实。生产率是软件供应方最关心的问题，老板和员工都想用更少的时间挣更多的钱。质量与生产率之间有着内在的联系，高生产率必须以质量合格为前提。如果质量不合格，对供需双方都是坏事情。从短期效益看，追求高质量会延长软件开发时间并且增大费用，似乎降低了生产率。从长期效益看，高质量将保证软件开发的全过程更加规范流畅，大大降低了软件的维护代价，实质上是提高了生产率，同时可获得很好的信誉。质量与生产率之间不存在根本的对立，好的软件工程方法可以同时提高质量与生产率。

      软件供需双方的代表能在餐桌上谈笑风生，归功于第一线开发人员的辛勤工作。质量与生产率的提高就指望程序员与程序经理。对开发人员而言，如果非得在质量与生产率之间分个主次不可，那么应该是质量第一，生产率第二。这是因为：（1）质量直接体现在软件的每段程序中，高质量自然是开发人员的技术追求，也是职业道德的要求。（2）高质量对所有的用户都有价值，而高生产率只对开发方有意义。（3）如果一开始就追求高生产率，容易使人急功近利，留下隐患。宁可进度慢些，也要保证每个环节的质量，以图长远利益。

      软件的质量因素很多，如正确性，性能、可靠性、容错性、易用性、灵活性、可扩充性、可理解性、可维护性等等。有些因素相互重叠，有些则相抵触，真要提高质量可不容易啊！

      软件工程的主要环节有：人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试、维护等，如图1.1所示。

      软件工程模型建议用一定的流程将各个环节连接起来，并可用规范的方式操作全过程，如同工厂的生产线。常见的软件工程模型有：线性模型（图1.2），渐增式模型（图1.3），螺旋模型，快速原型模型，形式化描述模型等等 [Pressmam 1999, Sommerville 1992]。 

      最早出现的软件工程模型是线性模型（又称瀑布模型）。线性模型太理想化，太单纯，已不再适合现代的软件开发模式，几乎被业界抛弃。偶而被人提起，都属于被贬对象，未被留一丝惋惜。但我们应该认识到，“线性”是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的“非线性”问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如渐增式模型实质就是分段的线性模型，如图1.3所示。螺旋模型则是接连的弯曲了的线性模型。在其它模型中都能够找到线性模型的影子。

      套用固定的模型不是程序员的聪明之举。比如“程序设计”与“测试”之间的关系，习惯上总以为程序设计在先，测试在后，如图1.4（a）所示。而对于一些复杂的程序，将测试分为同步测试与总测试更有效，如图1.4（b）所示。

　　国外大的软件公司和机构一直在研究软件开发方法这个概念性的东西，而且也提出了很多实际的开发方法，比如：生命周期法、原型化方法、面向对象方法等等。下面介绍几种流行的开发方法：

　　1、结构化方法

　　结构化开发方法是由E.Yourdon 和 L.L.Constantine 提出的，即所谓的SASD 方 法， 也可称为面向功能的软件开发方法或面向数据流的软件开发方法。Yourdon方法是80年代 使用最广泛的软件开发方法。它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，最后是结构化编程（SP）。它给出了两类典型的软件结构（变换型和事务型）使软件开发的成功率大大提高。

　　2、面向数据结构的软件开发方法

　　Jackson方法是最典型的面向数据结构的软件开发方法，Jackson方法把问题分解为可由三种基本结构形式表示的各部分的层次结构。三种基本的结构形式就是顺序、选择和重复。三种数据结构可以进行组合，形成复杂的结构体系。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。

　　3、 面向问题的分析法

　　PAM（Problem Analysis Method）是80年代末由日立公司提出的一种软件开发方法。 它的基本思想是考虑到输入、输出数据结构，指导系统的分解，在系统分析指导下逐步综 合。这一方法的具体步骤是：从输入、输出数据结构导出基本处理框；分析这些处理框之间的先后关系；按先后关系逐步综合处理框，直到画出整个系统的PAD图。这一方法本质上是综合的自底向上的方法，但在逐步综合之前已进行了有目的的分解，这个目的就是充分考虑系统的输入、输出数据结构。PAM方法的另一个优点是使用PAD图。这是一种二维树形结构图，是到目前为止最好的详细设计表示方法之一。当然由于在输入、输出数据结构与整个系统之间同样存在着鸿沟，这一方法仍只适用于中小型问题。

　　4、原型化方法

　　产生原型化方法的原因很多，主要随着我们系统开发经验的增多，我们也发现并非所有的需求都能够预先定义而且反复修改是不可避免的。当然能够采用原型化方法是因为开发工具的快速发展，比如用VB，DELPHI等工具我们可以迅速的开发出一个可以让用户看的见、摸的着的系统框架，这样，对于计算机不是很熟悉的用户就可以根据这个样板提出自己的需求。

　　开发原型化系统一般由以下几个阶段：
（1） 确定用户需求
（2） 开发原始模型
（3） 征求用户对初始原型的改进意见
（4） 修改原型。

　　原型化开发比较适合于用户需求不清、业务理论不确定、需求经常变化的情况。当系统规模不是很大也不太复杂时采用该方法是比较好的。

　5、面向对象的软件开发方法

　　当前计算机业界最流行的几个单词就是分布式、并行和面向对象这几个术语。由此可以看到面向对象这个概念在当前计算机业界的地位。比如当前流行的两大面向对象技术DCOM和CORBA就是例子。当然我们实际用到的还是面向对象的编程语言，比如C++。不可否认，面向对象技术是软件技术的一次革命，在软件开发史上具有里程碑的意义。

　　随着OOP（面向对象编程）向OOD（面向对象设计）和OOA（面向对象分析）的发展，最终形成面向对象的软件开发方法OMT (Object Modeling Technique）。这是一种自底向上和自顶向下相结合的方法，而且它以对象建模为基础，从而不仅考虑了输入、输出数据结构，实际上也包含了所有对象的数据结构。所以OMT彻底实现了PAM没有完全实现的目标。不仅如此，OO技术在需求分析、可维护性和可靠性这三个软件开发的关键环节和质量指标上有了实质性的突破，基本地解决了在这些方面存在的严重问题。

　　综上所述，面向对象系统采用了自底向上的归纳、自顶向下的分解的方法，它通过对对象模型的建立，能够真正建立基于用户的需求，而且系统的可维护性大大改善。当前业界关于面向对象建模的标准是UML（Unified Modeling Language）。

　　这里我们需要谈一下微软的MSF（Microsoft Solutions Framework）的框架，它简单的把系统设计分成三个阶段：概念设计、逻辑设计和物理设计。概念设计阶段就是从用户的角度出发可以得到多少个对象，并且以对象为主体，画出业务框架。逻辑设计阶段就是对概念设计阶段的对象进行再分析、细分、整合、删除。并建立各个对象的方法属性以及对象之间的关系。而物理设计实际上就是要确定我们实际需要的组件、服务和采用的框架结构、具体的编程语言等。MCF整个结构比较清楚是基于对象开发的一个比较好的可操作的框架系统。

　　6、可视化开发方法

　　其实可视化开发并不能单独的作为一种开发方法，更加贴切的说可以认为它是一种辅助工具，比如用过SYBASE的S-Design的人都知道，用这个工具可以进行显示的图形化的数据库模式的建立，并可以导入到不同的数据库中去。当然用过S-Design的人不一定很多，但用过VB，DELPHI，C++ Builder等开发工具的人一定不少，实际上你就是在使用可视化开发工具。

　　当然，不可否认的是，你只是在编程这个环节上用了可视化，而不是在系统分析和系统设计这个高层次上用了可视化的方法。实际上，建立系统分析和系统设计的可视化工具是一个很好的卖点，国外有很多工具都致力于这方面产品的设计。比如Business Object就是一个非常好的数据库可视化分析工具。

　　可视化开发使我们把注意力集中在业务逻辑和业务流程上，用户界面可以用可视化工具方便的构成。通过操作界面元素，诸如菜单、按钮、对话框、编辑框、单选框、复选框、 列表框和滚动条等，由可视开发工具自动生成应用软件。

六、怎样培养软件工程的思维与方法

　　作为软件开发人员的一个通病是在项目初期的时候，就喜欢谈论实现的细节，并且乐此不疲。我们更喜欢讨论如何用灵活而简短的代码来实现一个特定的功能，而忽略了对整个系统架构的考虑。所以作为一个开发人员，尤其是一个有经验的开发人员，应该把自己从代码中解脱出来，更多的时候在我们的脑子里甚至暂时要放弃去考虑如何实现的问题，而从项目或产品的总体去考虑一个软件产品。

　　以下是我个人的一些经验：

　　1．考虑整个项目或者产品的市场前景。作为一个真正的系统分析人员，不仅要从技术的角度来考虑问题，而且还要从市场的角度去考虑问题。也就是说我们同时需要考虑我们产品的用户群是谁，当我们产品投放到市场上的时候，是否具有生命力。比如即使我们采用最好的技术实现了一个单进程的操作系统，其市场前景也一定是不容乐观的。

　　2．从用户的角度来考虑问题。比如一些操作对于开发人员来讲是非常显而易见的问题。但是对于一般的用户来说可能就非常难于掌握，也就是说，有时候，我们不得不在灵活性和易用性方面进行折中。另外，在功能实现上，我们也需要进行综合考虑，尽管一些功能十分强大，但是如果用户几乎不怎么使用它的话，就不一定在产品的第一版的时候就推出。从用户的角度考虑，也就是说用户认可的才是好的，并不是开发人员觉的好才好。

　　3．从技术的角度考虑问题。虽然技术绝对不是唯一重要的，但是技术一定是非常重要的，是成功的必要环节。在产品设计的时候，必须考虑采用先进的技术和先进的体系结构。比如，如果可以采用多线程进行程序中各个部分并行处理的话，就最好采用多线程处理。在Windows下开发的时候，能够把功能封装成一个单独的COM构件就不作成一个简单的DLL或者是以源代码存在的函数库或者是对象。比如能够在B/S结构下运行并且不影响系统功能的话就不一定要在C/S下实现。

4．合理进行模块的分割。从多层模型角度来讲，一般系统可以分成用户层、业务层和数据库层三部分。当然每以部分都还可以进行细分。所以在系统实现设计的时候，尽量进行各个部分的分割并建立各个部分之间进行交互的标准。并且在实际开发的时候，确实有需要的话再进行重新调整。这样就可以保证各个部分齐头并进，开发人员也可以各施其职。

　　5．人员的组织和调度。这里很重要的一点是到考虑人员的特长，有的人喜欢做界面，有的人喜欢做核心。如果有可能要根据人员的具体的情况进行具体的配置。同时要保证每一个开发人员在开发的时候首先完成需要和其他人员进行交互的部分，并且对自己的项目进度以及其他开发人员的进度有一个清晰的了解，保证不同部分的开发人员能够经常进行交流。

　　6．开发过程中文档的编写。在开发过程中会碰到各种各样的问题和困难，当然还有各种各样的创意和新的思路。应该把这些东西都记录下来并进行及时整理，对于困难和问题，如果不能短时间解决的，可以考虑采用其他的技术替代，并在事后做专门的研究。对于各种创意，可以根据进度计划安排考虑是在本版本中实现还是在下一版本中实现。

　　7．充分考虑实施时可能遇到的问题。开发是一回事情，用户真正能够使用好它又是另外一回事情。比如在MIS系统开发中，最简单的一个问题就是用户如果数据输入错误的时候，如何进行操作。在以流程方式工作的时候，如何让用户理解自己在流程中的位置和作用，如何让用户真正利用计算机进行协作也是成败的关键。

　　以上是我个人的一点体会，实际上，作为一个软件开发人员，我也喜欢看到问题就坐在计算机前面直接编码，但是我确实认为软件工程对于我们系统开发的指导作用是巨大的。作为软件工程的拥戴者，下面我简单结合自己的开发经历介绍基于软件工程的开发方法、编程规范和工具使用等方面的问题。

七、软件开发的发展变化

　　国外很多项目的开发都是基于一些图形化的东西来做的，他们的目的是尽量少写代码甚至不写代码。代码能够通过图形化的方式自动生成，这样的一个好处就是如果用户的需求变化或者业务逻辑发生变化，我们需要做的就是对图形表示的调整，然后重新自动生成代码，这也就是国外开发很注重对项目的概念和逻辑分析的原因。

　　他们的重点是把业务规则和需求用图形化的方式表现出来，然后通过CASE工具自动生成代码。所以当国人还在不停的开发一个又一个的MIS工具的时候，国外已经把很多精力放到了CASE工具的制作上。

　　我们很多公司人员忙着写具体业务过程的相关代码，而国外很多都把精力放到对不同应用，不同行业的模型的建立和共性的提取上。所以，他们做出来的东西就相对具有很强的灵活性和扩展性，而我们是用户的需求稍微有一点变化，就要忙着改代码，甚至改体系结构。

　　另外，因为他们注重模型的建立，所以在建立其他应用的时候，能够借鉴原先的模型，在高层次上做调整和优化，同时能够有效的提取原有系统中可以被使用的部分。所以我们应该从以代码为核心的软件开发模式转化到以模型为中心的、基于CASE的开发上来。

　　关于协作与个人英雄主义

　　社会进步的一个很明显的现象就是社会分工越来越细，软件的开发也不例外。为什么在软件开发的今天已经不能出现象裘伯君这样的软件英雄的原因也在这里，单凭个人之力，我们也许穷尽有生之年也开发不出象Windows这样的操作系统。
因为，当前软件行业的壁垒无非就是两个，一个就是以技术创新取胜，你模仿的了其中的界面，但是你没有办法实现其中的核心功能。结果是你只能购买其技术核心，而你作一些边角工作。不举别的例子，比如VB这样的开发工具，其核心部分是它和第三方提供的COM控件或者是DLL函数库，你所做的就是一个整合的工作。

　　第二个就是以细致取胜，也就是说功能很多而且做的很精致，即使技术本身不是很复杂，你真要想做出一个这样的东西来没有一两年的工夫是不可能的。而真等你做出来了，它的新版本也早已经推出。真正能够在市面上叫得想、经得起考验得产品都是具有这两方面的特点。

　　这两方面的特点决定了你一个人绝对是不可能胜任的，也许你可以独立的完成技术创新，但是你绝对不可能一个人实现所有这些纷繁复杂的功能。所以，这个时代需要创新的英雄，也更需要人与人之间的协作。
当今的软件发展已经不是一个人可以包打天下的年代。软件开发的管理、系统体系结构的设计、模块之间的衔接、核心算法的实现、灵活界面的制定、软件再开发接口的实现都需要专门的人来做。而把这些有效的集成显然就需要有效的利用软件工程的思想和方法。所以，真正的软件英雄绝对不再是写着别人看不懂代码的程序员，而是整个体系结构的分析、设计、标准制定、协调人员。

八、我们是否需要软件工程

　　有一点大家可以达成共识的就是，如果一个象Windows这样的操作系统，不进行全面的规划，不采用软件工程的思想和方法，是绝对搞不出来的。

　　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．测试。测试是系统投入使用前最关键的一个步骤。即使是小项目也应该严格地进行测试。就实际上就是一个把错误留给自己还是留给客户的问题。

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

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

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

九、我国软件工程发展的现状

      很多国内搞计算机的专家都认为：国内的软件研发过程，个人色彩比较浓。过分地依靠个人无法形成产业规模，而没有规模就谈不上产业化了。

　　不管怎么样，我们大家还是先要来看一看国内软件厂商到底提供给我们多少有震撼力的软件产品，从技术和利润的角度讲，软件系统最核心的部分还是操作系统、编译系统然后就是开发平台之类的东西，接下来就是一些应用系统，比如图形开发、游戏开发、企业应用、网站建设、杀毒、网络工具等等。

　　操作系统以中科院为中心，做了一个COSIX，这个本质上是一个UNIX系统，UNIX最初的源代码是公开的，尽管COSIX是一个被称为中国的操作系统并是UNIX系列的（IX就代表UNIX系列），但是其中到底有多少独创的技术成分我们暂时还不知道，但有一点可以肯定，它现在的市场覆盖率绝对不大，而且能否在上面运行各种各样的编译系统、数据库、群件和应用系统可能还需要进一步测试。然后就是对硬件平台的支持也需要进一步完善。

　　然后就是轰轰烈烈的Linux系统，Linux是遵守GNU标准的操作系统，中国有很多家公司推出了自己的Linux并且还有汉化的Linux，这就有比较疑惑的一点，为什么不在Linux上构架一个类似UNICODE这样的东西，而只做汉化这么本地化的产品呢？不知道是眼光还是市场的问题了。
MIS系统、财务软件是中国软件行业的重头戏，它们彻底的暴露了中国软件开发无序和重复低效劳动的一面。教育软件在某一种层面上看就是电子题库，当然也有优点，比如加入了多媒体教学（可视化程度不错）和所谓寓教于乐的特点，但是从本质上说还是题库。杀毒软件据说是中国软件的骄傲，由中国权威机构评测是达到了世界领先水平，但是好象还没有得到国际权威机构的认可。游戏软件就不用提了，国内业界能够流行的游戏软件成功的秘诀众所周知，不是技术和创意，实在是归功于我们悠久的历史。字处理软件和排版软件客观的说国内的也做的不错，但是从系统的扩展性和体系结构上说和MS和Adobe相比，差距也放在那里。其实这种现状的原因很简单，一个是我们缺少创新的能力，另一个就是我们欠缺软件工程的概念，系统开发前期的需求分析、设计没有做好或者做的不够好。

　　当然，我们很少怀疑自己的技术能力，我们很多时候认为这是地理环境和经济环境的原因造成了中国软件业现在的局面。当然中国软件开发人员绝对可以算是优秀的，但是想想我们软件行业龙头企业到底有多少有技术创新和专利技术呢？姑且不论这个，实际上把一个操作系统分解开来，比如文件系统、进程管理和调度、IO调度等等，也许我们可以实现其中某一块的内容，但是如何把它们合理的整合起来绝对是一个涉及到软件工程的问题。

　　作为一个开发人员，我们已经习惯了自己那一套编程模式，而且我们的这种习惯也不自觉的影响着新的开发人员。所以在头脑中建立一个软件工程的作用，从某种角度上讲，要比会几种开发语言、几个编程技巧实在是重要的多。

　　举一个例子来说，我们也许可以写MFC中的几个类或者是用自己的类扩展MFC，但是我们又有几个人真正去认真分析和考虑MFC架构的设计和原理呢？扪心自问，我们又有多少人能够设计出MFC这样的框架系统呢？下面就我们的题目谈一些相关的话题。

十、我有一个梦

　　毋庸质疑的是，计算机的发展和人类的历史相比甚至和其他很多科技产品相比都是非常短的，从第一台计算机的研制成功到现在也没有百年的历史，但是计算机及其相关技术的发展却绝对可以说是最快的。抛开硬件的发展（硬件的发展基本上是按照摩尔定律来的，每18个月，机器的速度性能都要提高一倍），单从软件的发展来说，从体系结构来讲，我们经历了从主机结构到文件服务器结构，从客户服务器系统到基于Internet的服务器浏览器结构的体系结构的变化。从编码的角度来讲，我们经历了从最开始的机器代码到汇编代码，从高级程序语言到人工智能语言，从专用的程序设计语言到通用的程序设计语言。从开发工具来讲，我们经历了从分离的开发工具（有代码编辑器，中间代码生成器和连接器）到集成的开发系统，从最简单的单行命令式调试器到方便灵活的多功能的调试器。

　　但是，今天所有的软件厂商和软件开发人员依然会想起当年的黑人人权运动领袖马丁？路德？金曾经说过的一句名言我有一个梦想。是的，所有的开发人员依然怀着梦想，希望能够有一个万能的系统开发的框架和方法，只要我们沿着这个框架，我们将能开发出适合所有领域的应用系统，于是，我们在念书的时候把这个希望投到了一门课上，这么课就是软件工程。但是当我们在学完这门课的时候，我们依然没有找到这么一个框架甚至连接近这么一个框架的东西也没有碰到。

　　不管我们认为软件工程可能是多么的虚无，但是所有学工科并且有逻辑头脑的人都坚信理论对实践的指导意义，因为有了爱因斯坦及其许多伟大的科学家关于能量和质量方面的理论以后，我们才造出了原子弹。但是，遗憾的是软件工程并不是一个具体的理论，它更象一门抽象的科学。软件工程是一种方法论，而不是一种具体的摸的着，看的见的产品。它告诉我们在设计一个系统的时候，我们需要进行可行性研究、计划制订、需求分析、系统设计、编码、测试、维护等等。并且对这些过程中应该做什么提出了一个指导性的东西。但是没有任何专家和标准委员会保证只要按照这些标准，我们的系统肯定会顺利完成。而且事实上，软件开发针对的领域是如此之多并不没有一种对所有领域适用的万能框架。
　　不管认为软件工程已经到了非常成熟的阶段还是认为软件工程依然是一个搞不懂的黑箱子，软件工程确实已经经历了三个不同的阶段。第一个阶段是软件结构化生产阶段，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。从80年代中期，软件生产开始进入以过程为中心的第二阶段，以提出过程成熟模型CMM、个体软件过程PSP和群组软件过程TSP为标志。第三个阶段就是以软件过程、面向对象和构件重用三把斧头出现的软件工业化生产阶段。

　　言归正传，我们还是回到我们的文章标题上来，我们在开发的时候是兵马未动、粮草先行还是摸着石子过河。兵马未动、粮草先行当然意味着我们在开发的时候先不忙着编写代码做程序，我们先要制订一个关于开发的方法。这点就象元数据（metadata）的概念，元数据并不定义数据，它是对数据的说明，也就是通常所说的关于数据的数据。我们设计的时候也是这样，定义开发的标准，如何进行开发、怎样开发。摸着石子过河就意味着我们先不管什么理论，方法，科学的问题，我们先动手做起来，如果做的也算成功的话，那就可以按照这种模式来，实际上，在任何事情的最初，我们都是这样。从辨证唯物主义者的观点来说，就是从实践中来，然后升华到理论，再用理论来指导实践。记得一个笑话说：外国人搞软件工程是在一个黑屋子里面抓黑猫，不过到现在还是没有抓住，而中国人是在一个黑屋子里面，而里面连猫都没有，然后有人说，我已经抓到猫了。这个笑话一方面是说明直到现在，软件工程还是一个在继续探索、发展的过程，另一个侧面也说明中国搞软件工程摸不着边的局面。

　　实际上，不管有没有软件工程，不管是否存在一个万能的框架系统，我们的应用系统还是要做，各种各样的软件还是要开发。说到底，软件系统是因为有需求才存在的。有了应用域才有了软件存在的意义。很多时候，我们可以看到国外有各种各样的软件和创新，而我们没有，我们更多的是模仿和一些重复的功能相近的软件的原因就是因为我们没有这方面的需求，这也正解释了为什么ERP系统能在国外开展的很好，而在国内失败多于成功的原因。一方面当然是因为我们的企业按照市场经济发展的时间还不长，另一方面是我们的企业确实也没有这方面的需求。

      “敏捷开发”（Agile Development）被认为是软件工程的一个重要的发展。它强调软件开发应当是能够对未来可能出现的变化和不确定性作出全面反应的。

      敏捷开发被认为是一种“轻量级”的方法。在轻量级方法中最负盛名的应该是“极限编程”（Extreme Programming，简称为XP）。而与轻量级方法相对应的是“重量级方法”的存在。重量级方法强调以开发过程为中心，而不是以人为中心。重量级方法的例子比如CMM/PSP/TSP。