《走进软件工程--软件工程存在问题,发展趋势》由会员分享，可在线阅读，更多相关《走进软件工程--软件工程存在问题,发展趋势（10页珍藏版）》请在金锄头文库上搜索。
1、走进软件工程软件工程(Software Engineering 简称为 SE)是针对软件这一具有特殊性质的产品的工程化方法。软件工程涵盖了软件生存周期的所有阶段，并提供了一整套工程化的方法，来指导软件人员的工作。一、软件工程的研究现状及存在问题在网站上看到很多网友的高论，很有启发。而且目前市面上也涌现出一批面向不同方面的软件过程的书籍，可是在这里，我一直没找到真正对实践有指导意义的，可操作的应用方法。我个人的理解，软件工程就是按照工程学的管理方式，有组织、有计划的，在一定的质量基础、时间限度和成本范围内，实现功能明确的软件系统。而且，软件工程在企业范围内运行，一定需要企业资源的支持，要与企业的
2、经营、决策、管理体系联系在一起，才能够被踏踏实实的落实下来。 软件业作为一个服务业，要想得到发展，首先必须形成一个对软件服务有迫切需要的市场。其次，这个市场中的消费者必须具备足够的购买力。软件的消费群体简单一点，可以分为个体消费和企业消费。中国的企业群体，数量庞大，但是质量不高。上规模的企业不多，因此，中国的企业对大型软件的消费肯定是有限的，软件的个人消费，占了目前市场的主要一部分。因此，国内目前能够形成比较大规模的独立市场的，肯定是小规模的软件系统。 此外，质量的好与坏也不能绝对而论。比如说，你花 500 元，买双皮鞋，只穿了一个月就坏了，肯定是劣质产品。可是如果你只花了 5 元买这双鞋，还
3、是穿了一个月就坏了，他就是个优质产品了。软件也是一样。 还有一个，就是软件生命周期问题。在国外，很多中、大型企业里，软件系统已经作为企业的命脉在运行，这些企业当然需要长期、稳定的软件服务、开发体系作为保障，因此相对来说，对于软件的功能需求就比较明确，而国内的中小企业在运营方面本来就把灵活多变作为生存武器，当然不可能有比较长期的经营计划，更不可能运用软件系统进行全面企业管理。这就导致对软件系统需求的短期行为，因此，他们更加希望一次性购买功能有限的软件系统，而不是长期连续的软件服务。 话又说回来，在中国，有多年以上软件开发背景的人，又有几个？而且他们在过去的数年经验，更多的是较小的项目，而不是大项
4、目的管理与系统分析。而一个好的系统分析师，需要的是实践、实践、再实践。假如说我们的商业环境 中根本没有大型的软件项目，怎么可能有优异的系统分析师呢? 所以，我想，目前我们还有的问题，就是工程师的技术水平、知识面与管理意识、管理方法同样重要，在这样的前提下，我们是不是要探索一下真正适合我们的软件工程方法呢？1。我的意思不是喊出一句口号，举起民族软件工程大旗。这也不是我这个学生做的事情。而是说，我们要如何在国外先进的理论基础上进行实践。我所列举的种种事实，在国内是客观存在的，比如说浮躁、急功近利、市场特殊性、人员素质等等。在国外，他们搞软件工程，应该比国内有好得多社会条件。因此，他们的实践方法的起
5、点和目的与国内截然不同。我不否认，国内也有些公司具备了相当好的软环境，可以实施 CMM、RUP 等等。可是普遍来说，绝大多数企业并不具备这样的实力。难道这些企业就简单的坐以待毙么？ 2。我认为，在企业内实施任何长期计划，都必须与企业的战略、战术高度吻合，必须能够为企业带来利润，才是有可能的。现在我们的企业面对的就是这么一个不规范的市场，急功近利的客户，从经营者的角度出发，不管你是什么 MM，赚不道钱的全都没用。说一个简单的例子，就说是做金山词霸这样的软件，你实施了 RUP 就能把他卖到 1000 元一个？就能卖到 Office 的价钱么？既然它只能卖 28 元，你就只能按照这么一个市场规模进行
6、投入，他根本养不起一个完整地做 RUP 的团队，那么，对于这种有现实利益，有效益的市场和软件，我们是不是应该有一套比较科学的管理方法呢？ 3.实施软件工程不可能离开企业经营管理。这么说吧，如果你的老板每天都答应你明天涨工资，就是不兑现，你还有没有心思去 RUP?，如果你每月只拿1000 元，然后让你去老老实实的干 SA，你是不是第一想法就是炒更？第二主意就是跳槽？那时候让你做些破解盗版谋生恐怕你都去。企业没钱，怎么说都没用。 4.要面对国内市场的特殊性。一个企业要发展，首先就要学会生存，我们的企业要在不成熟的市场上，用大量不成熟的工程师做事情，这是老外不会遇到的情况。在这种环境下，我们要实现好
7、的管理，好的经营，是不是有很多特殊的地方呢？ 二、软件工程的发展状况和趋势软件工程的研究热点是随着软件技术的发展而不断变化的。即便在软件工程的领域内，研究热点也在不断转移。以往软件工程一直不能像其他产品一样，做到标准化，但是，随着技术条件的不断成熟，相应标准的出台，软件人员已经开始重视这方面的工作。实际上可以将许多软件工作分成许多部件去构造。很有可能今后的软件队伍会分为两个部分，一部分专门从事评估，另一部分专门从事集成，集成的对象是软构件。软构件的开发与运用刚刚开始。在一些公共领域，例如软件的用户界面，通用软构件的使用已经屡见不鲜。然而，对于各行各业的专业领域来说，领域构件的开发和使用还是基本
8、处于空白状态。这一工作的进行，一方面意味着各行各业对本专业领域内的知识形态加以归纳整理，然后以最新的软件形式表达出来。如果全面铺开，就是一件规模浩大的社会工程，需要各行各业的领域专家和软件专家通力合作才能完成。如果软件生产的“构件-集成”格局的趋势成为现实，各种应用领域里的构件的设计与生产将开辟出一个十分广阔的新天地，产生出巨大的市场需求，而且软构件的使用可以渗透到符合软构件标准规范的所有系统中，在软件开发过程中人们开始研制和使用软件工具，用以辅助进行软件项目管理与技术生产，人们还将软件生命周期各阶段使用的软件工具有机地集合成为一个整体，形成能够连续支持软件开发与维护全过程的集成化软件支援环境
9、，以期从管理和技术两方面解决软件危机问题。此外，人工智能与软件工程的结合成为 80 年代末期活跃的研究领域。基于程序变换、自动生成和可重用软件等软件新技术研究也已取得一定的进展，把程序设计自动化的进程向前推进一步。在软件工程理论的指导下，发达国家已经建立起较为完备的软件工业化生产体系，形成了强大的软件生产能力 。软件标准化与可重用性得到了工业界的高度重视，在避免重用劳动，缓解软件危机方面起到了重要作用。讨论软件工程的未来发展趋势，必须知道软件工程的发展不可能是孤立的，所以我们首先需要思考一下计算模型和软件开发本身的变化和趋势，再由此推测软件工程的发展趋势。从计算模型而言，应该来讲，传统的冯诺依
10、曼仍然被沿用；但从计算能力上来讲，我们注意到了三个变化：1.CPU 的运算能力按摩尔定律快速提升；但提升单颗 CPU 的计算能力已经越来越困难；2.并行运算技术以及多核多线程技术使服务器的处理能力飞速提升；服务器的处理能力不再是瓶颈，从而造成计算能力大量向服务器端迁移，C/S 结构被无情抛弃，B/S 结构成为大势所趋；3.互联网的快速普及使得互联计算成为可能，通过互联网相连的服务器集群在服务器端提供了更强大的计算能力；基于上述计算能力的变化，从软件开发模式而言，我们注意到以下六个相关的趋势：（1）由于计算能力向服务器端的快速集中，提供高并行计算能力和可用性的中间件技术被广泛采用，甚至已经成为构
11、建大型软件系统的必选项；（2）因为采用了中间件技术，软件开发团队可以更集中关注于业务逻辑，而可以将许多细节交给中间件来管理，从而大大减少了需要编写的代码行数，也直接导致了软件开发团队的规模变得越来越小，但角色变得越来越专业化（如了解行业的需求分析员，了解中间件技术和领域构架的架构师等） ；（3）计算能力的增强，使软件越来越易用，从而使软件变得无处不在，需要的软件开发人员数量急剧增长(组织形态是大量的小规模开发团队)；在这一因素以及降低成本的压力下，开发外包变得非常普及；（4）为了使分布在互联网上系统能够互相协作，SOA 成为一个热点；（5）互联网的普及，将原来分散开发人员聚合在一起，只要有一个
12、合适的基础和好的框架，他们就可以开发出产品级的工具软件（以Eclipse，JBoss，MySQL，Subversion 为例） ，从而开源成为了一种趋势；（6）B/S 结构的系统非常容易升级，这使得软件交付和升级的速度大大加快了（从以年月为单位，到以周天为单位） ；回到正题，那么在这些大的趋势的作用下，软件工程会如何发展呢？我觉得在未来几年我们会看到如下的趋势：1.需求工程，渐成热点：专业化的角色，日益复杂的业务创新，全球分布的团队以及互联网级的交付速度，这些都对需求获取的正确性和有效性提出了更高的要求；我预计需求工程的研究和实施会成为近期的热点，其中 Use Case技术会被更广泛而正确的应
13、用，而相关工具的研发也会成为热点（如 IBM Rational Requirements Composer,，Ravenflow 等） 。用例的优势在于它天生是黑盒的，它用自然语言抽象了用户和目标系统的交互，避免了混入分析、设计和实现细节，以保证用例可以被不懂具体技术的业务及测试人员所真正理解。同时，需求分析员又可以方便地通过用例分析（use case analysis） （即用分析类来试图在理想方式下实现用例） ，将需求体系精华成分析模型。在这一过程中，需求分析员可以更进一步地完善基于用例的需求体系，而不必担心分析模型会污染需求，从而实现需求与分析的分离及有效互动。2.DSSA 和 MDD，
14、老树新花（基于领域的构架（DSSA）与模型驱动的开发（MDD） ）：随着软件应用的日益普及，软件已经超出了将手动流程自动化的范畴，而开始成为业务创新的主要推动力。因此，引入捕获特定领域内最先进需求及其实现架构的 DSSA 成为行业客户的热点之一。而且，DSSA 的引入将 MDD门槛大大降低了，也使基于 DSSA 的 MDD 支撑工具成为可能，从而可以极大地提高开发效率并保证软件质量（例如，Telelogic 的 Rhapsody 就是一个成功的基于实时嵌入式系统构架的 MDD 工具） 。3.迭代/敏捷，渐成标准：随着软件交付周期的日益加快，迭代化开发已经成为大多数软件开发团队的必选项。但是迭代
15、对整个团队的需求、架构、协同及测试能力都提出了更高的要求，现在许多开发团队都在试图导入迭代化开发的过程中，敏捷可是被看成迭代化开发的一种导入方式，这不过敏捷的范围其实比迭代化开发更大一些。敏捷的三个要素是迭代开发、坦诚合作和自适应性。坦诚合作其实才是敏捷的精髓，如 Ivar 所说，敏捷其实是有关 Social Engineering 的。敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。4.持续集成，蓄势待发：持续集成是保证迭代化开发质量的主要方式，通过持续集成可以利用自动化的方式来尽量自动地、尽早保证代码质量。随着迭代和敏捷的流行
16、，持续集成相关的工具成为现在市场上的新热点（如持续集成框架 IBM Rational BuildForge, 开源软件 CruiseControl，代码静态分析工具 Klocwork Insight，IBM Rational Software Analyzer 等） 。持续集成是一个复杂的系统工程，组织需要首先将现有的配置管理/变更管理工具与 Build 环境紧密集成并完成自动化 Build 过程，在根据企业/项目/产品的现状，定义如何自动化地检测软件质量（代码静态分析、单元测试或冒烟测试） ，并定义需要自动化生成的管理报表。5.基于实践的过程框架，方兴未艾：开发角色的专业化的和分布的全球化都要求软件开发过程更加规范，而敏捷又要求过程必须紧密贴合项目的实际需要，因此传统的大一统的过程无法符合这一需求。新一代的过程将是以实践为核心的，项目可以通过组装所需的不同实践来获得贴近项目要求的过程。IJI（Ivar Jacobson International）的 EssWork 和 IBM Rational 的 RMC 都是新一代的基
