《论《软件工程》》由会员分享，可在线阅读，更多相关《论《软件工程》（6页珍藏版）》请在金锄头文库上搜索。
1、 论软件工程 读完软件工程和一些有关资料后，感觉一些东西都曾经接触过，但在实际工作中有些理论要完全遵循可能还有些障碍，软件工程只是提供了理论上的一些结论，但对项目的具体可操作性的规范的制定方面却做的很少，软件工程发展了几十年，光是开发模型就达到了10多种，对不同的项目采用合适的开发模式，有些项目在不同的开发阶段可能还要转换开发模式，把它们灵活的应用到实际中还是很困难的。现在国内外都重视软件工程是因为，人们都认识到了如果能够适当合理的利用软件工程的理论可以减小开发成本和风险，风险降低了，成本就减少了，利润就提高了，所以有一种说法就是“软件工程就是提高软件项目利润的理论”。但人们也都意识到软件工程
2、的确更接近于理论，它所提供的可操作性太差，于是就有了现在流行的RUP和XP开发理论，这两种理论就是根据软件工程的理论经过大量的试验总结出的比较成功的开发模式，但RUP对于大项目还适合，对于小项目则不利于降低开发成本，所以现在国外最受欢迎的是XP。现在国内也开始使用这种方法，这种方法与其他开发方法最大的不同是将测试提到了一个几乎是最重要的位置，先写测试用例，然后编码，而且在测试过程中提倡使用一些自动化的测试工具，如对Java测试的Junit和对Delphi测试的Dunit。如今的软件工程已经改变了很多，提倡能够快速适应客户需求变化并能够根据变化快速转变开发方向的开发方法，国内外充斥着大量的讨论能
3、够提高开发速度、减少需求变更的开发模式的书籍，如一些认证，如ISO9000，CMM，CMMI等，还有开发模式，如敏捷开发，RUP，XP，PSP，TSPi等。在一定情况下，XP是很出众的，XP对国情是否适合可能尚难以下结论，但XP对于测试的重视和对使用自动化测试工具的推崇则是我们可以借鉴的。无论是在上个世纪还是在现在，软件开发所涉及的工作基本上都没有变化，它们都起始于一个实际需要或某个灵感，然后就是分析，设计，编码，调试，维护。这些任务以某种方式动态地结合起来就构成了软件开发的整个过程，这就是所谓的“软件开发周期”。但对于这些工作，具体怎样做，什么时候做，每个人都有自己的一套方式，甚至有的人有几
4、套方式。这样，当几个人合在一起干活的时候，最终的结果就只能是一片混乱。所以就需要一套规则，大家都按规则来办事，问题就会少得多。好的规则就叫做规范，规范都是由一些有经验的前辈根据经验总结的，又经过长时间的历练，不断地被补充修正，可以说都是精华，按照规范来干活，对于提高软件质量和工作效率自然大有帮助。而软件工程，用通俗的话讲就是，一套用于软件的团队开发，以提高软件质量和程序员工作效率为目的的规范。其核心就是，对于软件开发的5个重要组成部分：需求分析，设计，编码，调试，维护，如何组织这5个部分的工作，以及如何完成每一个工作。简单来说，就是对于总体的组织和对于局部的实现。规范只是提供一个好的例子，以描
5、述一种思想，具体到每一个环节怎样实现，对于不同的公司或团体则是各有千秋，因为根本就不可能存在一套放之天下皆可行的标准。就像C+，也只是提供了一套标准，不同的编译器都有各自的实现，对标准的支持程度也互不相同。所以，在不同的公司或团体中，尽管核心思想都是大同小异，但具体到每一个步骤，往往都是不相同的。我个人认为软件工程很重要，但更重要的是要能够根据不同的项目在不同阶段选择合适的开发模式，规避风险，适应客户灵活多变的需求变更。所以对需求调研和需求分析提出了更高的要求。我看过了一些讨论软件工程的文章，几乎一致认为“客户直接参与的项目成功的可能性非常高”，传统的软件工程中提出的不论是“瀑布”还是“螺旋”
6、模型都是进行阶段性的客户确认再开发，等开发完或者客户的需求变了，或者需求分析有错误，完全符合客户要求的几乎没有。所以我们是否考虑一下能否在条件允许的情况下，在以后的项目的开发中多征求客户意见，而不是在一阶段完成后再请客户看，这有利于我们降低开发大规模修改的风险。这也是“极限开发”模式中很重要的一点。当然这也不是绝对的，但这是经过证实的成功率比较高的一种方式。在前期需求调研和需求分析都做好了之后，就可以做概要设计和详细设计了，我认为这部分很关键的一点是确定界面风格和关于代码复用的考虑。一个符合客户习惯的界面是最保险的方案，这里面包括客户的操作习惯和审美习惯。但对开发人员更需要注意的是代码复用，一
7、个好的代码应该是注释详细、代码可读性强、代码复用率高的集合。而要做到代码的高复用率需要高度的抽象能力和对类的粒度的划分，对于粒度的划分应该遵循很多教材上多次提到的“高内聚，低耦合”，也就是说一个函数或方法的功能越单一越容易被组合起来复用，和其他的方法或函数或其他类的关联越少越好，这样在与之关联的对象或方法改变后不需要改动或很少改动就可以被复用。另外“设计模式”也是很重要的，“设计模式”为开发人员提供了一系列其他人经过多次试验证实成功的可以放心使用的解决套路，能够按照“设计模式”的思路开发系统可以获得很好的扩展性和强壮性，这也是经过无数案例证明过的。举个简单的例子，如果将获得数据的部分和显示数据
8、的代码混在一起，如果将来在改动显示部分或改动获得数据部分则要到混在一起的代码中去挑自己要改动的部分，这可能造成不该动的代码被改动了，或者因为一部分改动了，另一部分必须被改动，这样也带入了被迫改动代码的正确性的问题。对于这样的改动需要在测试时增大测试力度，才能保证代码是正确的，当然这是以增大测试成本为代价的。用另一种方式，使用设计模式，遵循MVC模式，将获得数据部分作为C（控制部分）封装在一个函数里，将显示部分作为V（视图）封装在另一个部分，他们之间的数据传递用函数的参数或其他数据结构（如记录、集合等），这样就可以保证改动一部分不会影响另一部分的正确性，测试时只要针对改动的部分测试就可以了，不会
9、因为不知道是那部分出现的错误而做更多的测试用例来确定错误来源。软件维护也是个重要的阶段，软件在运行一阶段后，可能会发现一些测试时没测出的错误，也可能客户觉得有些地方改变一下会为他们的工作提供更多的方便，这是就需要软件维护。这时需要的开发人员不会很多，但这时维护人员可能不是原来的开发人员，这是就设计到了代码的可读性和可维护性。良好的代码应该有详尽的注释，当然最好还要有简单明了的文档。维护后应该有维护记录，要说明维护原因，变更部分的说明。如果在维护阶段不知道原来的代码的意义，则维护工作根本无处着手。我在维护南昌市民卡项目过程中遇到这样一件事，因为南昌方面急着要操作员卡，而这边制卡程序需要改动，但这
10、边什么文档都没有，程序没有业务方面的注释，根本看不出什么意思，只好重做。如果当时有一份良好的注释，可能重新开工的可能就机会没有了。另外功能齐全的公用单元有利于减少开发重新编写的代码量，可以节省开发时间，增强代码的复用性。这在多个项目中可以看到好处，能够非常迅速的就搭建起了系统框架，对于一些功能需要的技术实现已经在公用单元提供了，所以可以拿过来直接使用。如何组织软件开发过程中的每一个步骤，就是软件开发周期模型要解决的问题。我认为开发软件，其实就像是解决一个逻辑问题。想想自己平时是怎样写程序的。首先是要有一个想法，即我写的这个程序是要干什么的；然后就是对要实现的核心功能大概构思一种或多种实现方法，
11、并从中选出一种自认为是较好的；接下来就是将涉及的各种主要或次要功能分成各个模块；最后就是分模块来编码和差错。在我看来，除了第一步外，其余的步骤应该是一个循环的过程。在编码的过程中，你总是需要不断地回过头来修改原先的模块设计，甚至最初选定的实现算法。除非你是先知，否则，对于一个具有一定规模和复杂度的软件来说，在“设计编码”这个过程中，实在有太多的不可预知性和变化性，你根本不可能全盘地把握住每一个细节。那么，对其每一个步骤的组织，即周期模型，就必须包容它的这种性质。现在来看一下瀑布模型。瀑布模型是一种线性模型，其最大的特点就是简单直观。它将软件开发过程规划为“分析设计编码测试维护”的线性过程，也就
12、是说，你必须首先把你的软件要干的每一件工作都分析得彻彻底底，再对每一个模块，每一个接口，事无巨细，都设计得非常完美，然后才开始编码的工作，并且在编码的时候就像在对着图纸砌模型，根本不用再回头作任何修改，当然，是在把所有的代码都写完以后才开始测试的。软件开发过程的实现具体到每一步的工作要怎样完成，我前面已提到过，是非常灵活的，只要把握住大体的方向就行。在进行分析，设计，编码，调试，维护这几部分的工作的时候，最核心的就是文档的编写。文档的作用在于以下3个方面：一是可以帮助整理思路。把要完成的目标，系统的结构，每一个模块的功能等整理一下，然后分门别类地写下来，这样在开发的过程中，就有据可依，在需要回
13、过头来修改设计的时候，也有证可考。二是便于交流。在脑子里的东西一多，就会散而且乱，用语言表达的时候，很容易会丢三落四，别人也很难把握住你的思想。但经过整理写在纸上以后，则会清晰得多，无论是别人还是自己，看起来都可以一目了然。三是可以作为以后维护时的参考资料。有一句名言：“笔和纸永远都比大脑可靠”，意思就是说，放在大脑里的东西说不准哪天就忘了，但写在纸上的东西，只要不发生什么意外，一般是丢不了的。当过了一段时间，你需要再回过头来修改你的程序的时候，你就会发现，你以前写下的文档实在太有价值了。别指望你的源代码，对于复杂一点的程序来说，单纯的源代码几乎会扼杀掉你所有的时间。可行性分析就是关于当前项目
14、能不能干的分析结果。主要考虑的方面包括：是否能把这个项目开发出来；假如可以的话，预计需要多少时间，能否满足客人的时间要求；需要多少人力和资金的投入；最重要的是，这个项目能否赚钱，能赚多少。还要对可能存在的风险进行评估。项目描述这是在决定立项以后，对当前项目的一份扼要说明。必须包括以下几个方面：（1）项目的名称或编号；（2）对客户方的描述；（3）对开发人员的描述；（4）工程任务的描述；（5）工程的输入和输出；（6）开发环境；（7）其他的附加条件。通过对实用软件工程和一些资料的学习，受益匪浅，对软件开发有了一个系统的了解，对一些概念有了一定了解，虽都这些是些理论，可能在实际工作中很少用到，理论知识用于指导实践，亲身体验才能领悟软件工程的妙用。我感觉到学习这门课需花费大量的时间思考，从而换取了宝贵的经验。学习软件工程的过程是枯燥的，但我认为若把这些枯燥的理论学好，在将来的学习和工作中一定会有益。
