软件工程概论.doc

软件工程概论读后感软件工程方面的书目前是计算机科学图书的一个热点，这也是我国的计算机行业从手工作坊式的小规模开发转向工业化大生产方式进行软件产品生产的必然需要。从国外软件业30多年的发展来看，软件工程也是随着为国防、政府和企业开发大型软件系统而不断发展起来的。刚读完软件工程概论，感觉很多东西都曾经接触过，但在实际工作中有些理论要完全遵循可能还有些障碍，软件工程只是提供了理论上的一些结论，但对项目的具体可操作性的规范的制定方面却做的很少，所以现在很多同行都说：“我们都学过软件工程，但却不可能完全遵守它去做项目”，因为一个项目是否应该遵循软件工程还要根据项目的大小、规模、进度的要求有一定的关系。如果对于一个时间很紧的小项目，如果完全按照传统的瀑布模型一步一步的写各种文档，可能是很不现时的，很可能造成了那种“用1周写文档，用1个小时写代码，但期限是1天”的情况，当然这只是一个极端的例子，但软件工程发展了几十年，光是开发模型就达到了10多种，对不同的项目采用合适的开发模式，有些项目在不同的开发阶段可能还要转换开发模式，这对于我们这些做项目的人来说，是个不低的门槛。看来关于软件工程方面的著作，我认为可分为两类。一类是看重考察项目过程本身，一类是主要考察项目的参与者。一本好的作品应该是承认实际环境中的种种局限，并在实际局限的基础上考虑合适的策略。由于软件是抽象的、不可触及的、也不受物理定律或加工工程的制约，软件系统也就很容易随着自身的发展而变得复杂和难以理解。软件工程作为一门工程学科，其目的就是在于降低软件开发的风险，使软件系统向高性价比发展。软件工程虽然是一门比较年轻的学科，但软件工程从第一次“软件危机”（1968年）开始到现在已经有了长足的发展，许多新技术和新方法构成了软件工程的重要部分，软件工程已经找到了进行软件描述、设计和实现的有效方法，并极大地完善了我们对软件开发活动的认识，提高了软件开发的效率。 而且我作为一名现代IT从业人员，软件工程已经成为必须掌握的专业知识。没有软件工程知识，很难想象一名软件开发人员如何在大型开发团队中生存。然而令人担忧的是目前许多学校还在使用陈旧的软件工程教材，还在向学生灌输着已经淘汰的软件工程理论。使得软件工程的教学严重脱离了实际软件开发的需要。现在国内外都重视软件工程是因为，人们都认识到了如果能够适当合理的利用软件工程的理论可以减小开发成本和风险，风险降低了，成本就减少了，利润就提高了，所以有一种说法就是“软件工程就是提高软件项目利润的理论”。但人们也都意识到软件工程的确更接近于理论，它所提供的可操作性太差，于是就有了现在流行的win系列和*nix系列开发理论，这两种理论就是根据软件工程的理论经过大量的试验总结出的比较成功的开发模式，现在人们对RUP的诟病也开始心声怀疑，认为这种开发模式也是理论多于实践，管理过程比较繁琐，对于大项目还适合，对于小项目则不利于降低开发成本，所以现在国外提倡“敏捷开发”，而最受吹捧的就是“极限编程”（XP）。现在国内也有很多公司开始使用这种方法，这种方法与其他开发方法最大的不同是将测试提到了一个几乎是最重要的位置，先写测试用历，然后编码，而且在测试过程中提倡使用一些自动化的测试工具，如对Java测试的Junit和对Delphi测试的Dunit。 我个人认为软件工程很重要，但更重要的是要能够根据不同的项目在不同阶段选择合适的开发模式，规避风险，适应客户灵活多变的需求变更。所以对需求调研和需求分析提出了更高的要求。我看过了一些讨论软件工程的文章，几乎一致认为“客户直接参与的项目成功的可能性非常高”，传统的软件工程中提出的不论是“瀑布”还是“螺旋”模型都是进行阶段性的客户确认再开发，等开发完或者客户的需求变了，或者需求分析有错误，完全符合客户要求的几乎没有。所以我们是否考虑一下能否在条件允许的情况下，在以后的项目的开发中多征求客户意见，而不是在一阶段完成后再请客户看，这有利于我们降低开发大规模修改的风险。这也是“极限开发”模式中很重要的一点。当然这也不是绝对的，但这是经过证实的成功率比较高的一种方式。 在前期需求调研和需求分析都做好了之后，我们就可以做概要设计和详细设计了，我认为这部分很关键的一点是确定界面风格和关于代码复用的考虑。一个符合客户习惯的界面是最保险的方案，这里面包括客户的操作习惯和审美习惯。但对开发人员更需要注意的是代码复用，一个好的代码应该是注释详细、代码可读性强、代码复用率高的集合。而要做到代码的高复用率需要高度的抽象能力和对类的粒度的划分，对于粒度的划分应该遵循很多教材上多次提到的“高内聚，低耦合”，也就是说一个函数或方法的功能越单一越容易被组合起来复用，和其他的方法或函数或其他类的关联越少越好，这样在与之关联的对象或方法改变后不需要改动或很少改动就可以被复用。 另外“设计模式”也越来越被开发人员所重视，“设计模式”为开发人员提供了一系列其他人经过多次试验证实成功的可以放心使用的解决套路，能够按照“设计模式”的思路开发系统可以获得很好的扩展性和强壮性，这也是经过无数案例证明过的。举个简单的例子，如果将获得数据的部分和显示数据的代码混在一起，如果将来在改动显示部分或改动获得数据部分则要到混在一起的代码中去挑自己要改动的部分，这可能造成不该动的代码被改动了，或者因为一部分改动了，另一部分必须被改动，这样也带入了被迫改动代码的正确性的问题。对于这样的改动需要在测试时增大测试力度，才能保证代码是正确的，当然这是以增大测试成本为代价的。用另一种方式，使用设计模式，遵循MVC模式，将获得数据部分作为C由于现代软件开发的复杂性和风险性不断增加，软件过程的重点不再是代码的设计和编写，需求工程、质量管理、软件进化的重要性日益突出，作者以敏锐的眼光将这些主题作为本书的讨论重点。同时作者在全书贯穿面相对象的思想，对象模型全部采用UML来描述，其“面相对象的设计”、“分布式系统体系结构”等章节则体现了软件工程与开发实践的紧密结合，反映了软件行业的主流趋势。 全面且简练Ian Sommerville的软件工程涉及软件工程介绍、描述、设计、要求极高的系统开发、效验和有效性验证、管理和软件进化等各个方面，全面系统地介绍了当今主流的软件工程知识。作为教材，该书覆盖了ACM/IEEE2001规范中有关计算机科学中软件工程方面的全部内容。软件工程不仅向我们展现了软件工程的广阔视野，还着重阐述了在开发大型系统中一些广泛采用的技术，期间不乏大量的例子和图解。然而这又是一本精简的软件工程教材。作者将所有的话题控制在适度的篇幅，用简练到位的文字把最重要的内容呈现给读者，并提供进一步阅读资料，供有兴趣的读者深入学习。本来内容如此全面的软件工程教材应该巨厚，而作者竟然在第5版的基础上缩减了10的字数，增加和调整了不少章节，可见作者的良苦用心。 也没有对某些兜售的所谓灵丹妙药解决方案和工具的迷信。它的权威是建立在作者多年的研究和实践之上，认为“事实上，并不存在解决软件工程问题的灵丹妙药，我们需要的是广泛的技术和工具以解决软件工程问题。” 软件工程人员应当做出承诺，使软件的分析、描述、设计、开发、测试和维护等工作对社会有益且受人尊重。基于对公众健康、安全和福利的考虑，软件工程人员应当遵守以下八条原则：1. 公众感软件工程人员应始终与公众利益保持一致。2. 客户和雇主软件工程人员应当在与公众利益保持一致的前提下，满足客户和雇主的最大利益。3. 产品软件工程人员应当保证他们的产品及其相关附件达到尽可能高的行业标准。4. 判断力软件工程人员应当具有公正和独立的职业判断力。5. 管理软件工程管理者和领导者应当拥护并倡导合乎道德的有关软件开发和维护的管理方法。6. 职业感软件工程人员应当弘扬职业正义感和荣誉感，尊重社会公正利益。7. 同事软件工程人员应当公平地对待和协助每一位同事。8. 自己软件工程人员应当毕生学习专业知识，倡导合乎职业道德的职业活动方式。一是强调小组成员要保持高度积极的开放心态去适应变化。我觉得大前提没有错。但是长时间的激烈变化的确是耗散小组成员斗志的最佳方式。期限中说：压力之下人无法很好思考。激烈的变化的确是产生压力的好途径。我不能期望我的小组成员人人在6个月以上的开发过程中一直保持这种心态，我自己首先做不到。这是大多数项目组的现实。二是觉得客户的需求最终会是收敛的，因此总有苦尽甘来的日子。我也以为不妥。我相信很多人经历过客户需求的变化，很多不是很有理性的，甚至有很多是颠来倒去的。有很多修改在程序员看来（包括事后证明）是没有意义的，但是在客户业务人员当时看来是很重要的，小组只能屈从。这也是小组士气的杀手。三是关于企业转型，作者以为很简单，老总用纸笔一画就万事OK。我正惊异于如何做到，作者举了MS的例子。这就没话说了，MS有几个人是能够学的？sun，hp，dell等都学不来呢。作者接着提到了微软能这样做的理由，比如成熟的价值观和卓越的领导人。可见这和所谓的自适应方法关系不大。业界有句名言：问500磅重的猩猩在哪里睡觉？答案是：想在哪里就在哪里。行业领跑者想怎么干都是可以的。至于说到学习成功者是我们成功的捷径，这个题目就更大了，有兴趣的人另外讨论。四是强调用这种方法开发出的小规模产品能先投入使用，产生效益。这种方法有一定可行性，我做的数据分析项目也是类似做法。但是总体而言我基本不同意，特别是从我做过的大型业务系统而言，决不可行。问题不是开发组能不能做到，而是对于这样的用户，召集一次业务人员进行培训和推广都是很耗费人力物力的。新软件的推广毕竟不是买个台灯来用。业务软件的推广往往意味着业务的重新整合，风险非常大（连期限的作者也只敢举产品的例子），这个是不能很多次折腾的。五是有点忽略政治的作用。这个问题比较大，但是我觉得大项目的开发肯定是要考虑的。上面的第三和第四点也都和政治有一定的关系。期限中的贝洛克部长就是政治影响开发的代表，现实中这样的压力会来自自己的领导和客户的领导。小说中该人物被解决了，但是实际项目中就说不清了。期限的作者也说了：奇迹会出现的，但是不要抱太大希望（大意如此）。花了俩个晚上一口气读完了软件工艺，应该是即程序员修炼之道后再让我喝彩的非技术类计算机书籍了，虽然看得是囫囵吞枣，却也酣畅淋漓，解决了我心中的疑惑。软件工程强调的是软件开发的过程，软件工艺则强调软件开发中工匠的重要性，换句话来说，软件工程强调的是管理，软件工艺强调的是人。 软件工程将软件开发严格的划分需求、概要、详设、开发、终结几个阶段，各阶段有各自的负责人，通过详尽的文档传递用户需求，这样难免无法避免用户需求经过层层的传达而产生的流失；软件工艺则鼓励优秀的工匠贯穿软件开发过程的始终。软件工程认为，软件的开发过程要规划化、流程化、可控化，重管理，忽略开发过程中人的因素。软件工程认为，一个优良的软件工程，即使在人员变动频繁，开发人员技能参差的情况下也可以极小的减少其带给项目的损失；而软件工艺强调，一个优秀