软件工程方面的书目前是计算机科学图书的一个热点，这也是我国的计算机行业从手工作坊式的小规模开发转向工业化大生产方式进行软件产品生产的必然需要。从国外软件业30多年的发展来看，软件工程也是随着为国防、政府和企业开发大型软件系统而不断发展起来的。
刚读完《软件工程概论》，感觉很多东西都曾经接触过，但在实际工作中有些理论要完全遵循可能还有些障碍，软件工程只是提供了理论上的一些结论，但对项目的具体可操作性的规范的制定方面却做的很少，所以现在很多同行都说：“我们都学过《软件工程》，但却不可能完全遵守它去做项目”，因为一个项目是否应该遵循《软件工程》还要根据项目的大小、规模、进度的要求有一定的关系。如果对于一个时间很紧的小项目，如果完全按照传统的瀑布模型一步一步的写各种文档，可能是很不现时的，很可能造成了那种“用1周写文档，用1个小时写代码，但期限是1天”的情况，当然这只是一个极端的例子，但《软件工程》发展了几十年，光是开发模型就达到了10多种，对不同的项目采用合适的开发模式，有些项目在不同的开发阶段可能还要转换开发模式，这对于我们这些做项目的人来说，是个不低的门槛。
看来关于软件工程方面的著作，我认为可分为两类。一类是看重考察项目过程本身，一类是主要考察项目的参与者。一本好的作品应该是承认实际环境中的种种局限，并在实际局限的基础上考虑合适的策略。
由于软件是抽象的、不可触及的、也不受物理定律或加工工程的制约，软件系统也就很容易随着自身的发展而变得复杂和难以理解。软件工程作为一门工程学科，其目的就是在于降低软件开发的风险，使软件系统向高性价比发展。软件工程虽然是一门比较年轻的学科，但软件工程从第一次“软件危机”（1968年）开始到现在已经有了长足的发展，许多新技术和新方法构成了软件工程的重要部分，软件工程已经找到了进行软件描述、设计和实现的有效方法，并极大地完善了我们对软件开发活动的认识，提高了软件开发的效率。
而且我作为一名现代IT从业人员，软件工程已经成为必须掌握的专业知识。没有软件工程知识，很难想象一名软件开发人员如何在大型开发团队中生存。然而令人担忧的是目前许多学校还在使用陈旧的软件工程教材，还在向学生灌输着已经淘汰的软件工程理论。使得软件工程的教学严重脱离了实际软件开发的需要。
现在国内外都重视《软件工程》是因为，人们都认识到了如果能够适当合理的利用软件工程的理论可以减小开发成本和风险，风险降低了，成本就减少了，利润就提高了，所以有一种说法就是“软件工程就是提高软件项目利润的理论”。但人们也都意识到《软件工程》的确更接近于理论，它所提供的可操作性太差，于是就有了现在流行的win系列和*nix系列开发理论，这两种理论就是根据《软件工程》的理论经过大量的试验总结出的比较成功的开发模式，
现在人们对RUP的诟病也开始心声怀疑，认为这种开发模式也是理论多于实践，管理过程比较繁琐，对于大项目还适合，对于小项目则不利于降低开发成本，所以现在国外提倡“敏捷开发”，而最受吹捧的就是“极限编程”（XP）。现在国内也有很多公司开始使用这种方法，
这种方法与其他开发方法最大的不同是将测试提到了一个几乎是最重要的位置，先写测试用历，然后编码，而且在测试过程中提倡使用一些自动化的测试工具，如对Java测试的Junit和对Delphi测试的Dunit。
我个人认为软件工程很重要，但更重要的是要能够根据不同的项目在不同阶段选择合适的开发模式，规避风险，适应客户灵活多变的需求变更。所以对需求调研和需求分析提出了更高的要求。我看过了一些讨论软件工程的文章，几乎一致认为“客户直接参与的项目成功的可能性非常高”，传统的软件工程中提出的不论是“瀑布”还是“螺旋”模型都是进行阶段性的客户确认再开发，等开发完或者客户的需求变了，或者需求分析有错误，完全符合客户要求的几乎没有。所以我们是否考虑一下能否在条件允许的情况下，在以后的项目的开发中多征求客户意见，而不是在一阶段完成后再请客户看，这有利于我们降低开发大规模修改的风险。这也是“极限开发”模式中很重要的一点。当然这也不是绝对的，但这是经过证实的成功率比较高的一种方式。
在前期需求调研和需求分析都做好了之后，我们就可以做概要设计和详细设计了，我认为这部分很关键的一点是确定界面风格和关于代码复用的考虑。一个符合客户习惯的界面是最保险的方案，这里面包括客户的操作习惯和审美习惯。但对开发人员更需要注意的是代码复用，一个好的代码应该是注释详细、代码可读性强、代码复用率高的集合。而要做到代码的高复用率需要高度的抽象能力和对类的粒度的划分，对于粒度的划分应该遵循很多教材上多次提到的“高内聚，低耦合”，也就是说一个函数或方法的功能越单一越容易被组合起来复用，和其他的方法或函数或其他类的关联越少越好，这样在与之关联的对象或方法改变后不需要改动或很少改动就可以被复用。
另外“设计模式”也越来越被开发人员所重视，“设计模式”为开发人员提供了一系列其他人经过多次试验证实成功的可以放心使用的解决套路，能够按照“设计模式”的思路开发系统可以获得很好的扩展性和强壮性，这也是经过无数案例证明过的。举个简单的例子，如果将获得数据的部分和显示数据的代码混在一起，如果将来在改动显示部分或改动获得数据部分则要到混在一起的代码中去挑自己要改动的部分，这可能造成不该动的代码被改动了，或者因为一部分改动了，另一部分必须被改动，这样也带入了被迫改动代码的正确性的问题。对于这样的改动需要在测试时增大测试力度，才能保证代码是正确的，当然这是以增大测试成本为代价的。用另一种方式，使用设计模式，遵循MVC模式，将获得数据部分作为C
由于现代软件开发的复杂性和风险性不断增加，软件过程的重点不再是代码的设计和编写，需求工程、质量管理、软件进化的重要性日益突出，作者以敏锐的眼光将这些主题作为本书的讨论重点。同时作者在全书贯穿面相对象的思想，对象模型全部采用UML来描述，其“面相对象的设计”、“分布式系统体系结构”等章节则体现了软件工程与开发实践的紧密结合，反映了软件行业的主流趋势。
哈哈！你中南的吧？
内容全部来源于网络收集，如有侵权，请联系网站删除：QQ：24596024