适应性——新软件危机的主因

作者 王翔 （Vision Wang） 发布于 2008年6月17日 上午9时6分

社区

Architecture,

SOA

主题

交付价值,

方法论,

客户及需求

标签

历史,

趋势

按照软件工程学的介绍，软件危机（Software Crisis）是软件发展第二阶段末期，由于硬件快速发展，引发作为“人件”的软件不能满足需求所导致的，作为副产品它催生了软件工程学的快速发展。但在很多企业已经把软件作为其业务神经的今天，通用的商业软件和开源软件已经相对过剩，但软件行业的危机不仅没有缓解，而是更加严峻。“适应性”成了新软件危机的主因。

软件危机的主要表现如下：

• 费用支出大大超出预算
• 用户不认可其功能
• 可靠性和维护性差
• 时间进度失控

40多年前我们总结其主因如下：

• 软件规模膨胀，逻辑趋于复杂
• 开发技术落后
• 开发方式落后
• 工具落后

但40年之后，除了第一条主因之外，其他方面都已经大大改善，尤其是伴随着C++、.NET、Java等一大批开源框架、开源工具、开源产品出现后，实际项目中我们需要自己编码的比例越来越小，常常是“技术等人”，而非“人等技术”。

但现实如何呢？我们不难发现危机的表现不仅没有减轻，反而愈盛。这说明主因发生了变化，在“唯一不变是变化本身”概念下“适应性”越来越突出。为什么工具、手段、方法学已经大大改善的今天还要一遍遍出现这个问题呢？技术和业务，尤其是后者。

• 十年前，传真还算很迅捷的通信手段，20年前电报和长途电话的地位更加突出，但现在信息往往是基于预定的邮件、短信和“WIFI Touch”
• 地球被互联网拉平，对外贸、制造业、投资、能源等类型的企业，很多时候商机的出现不再是年、月，而是几天甚至几个小时，IT如何快速解决这些问题，甚至是让用户凭借既有的IT系统自己解决，一直是软件行业奋斗但似乎还很遥远的目标
• 企业内部的竖井、企业间的信息壁垒因为资金和人员协作被逐个打破，防火墙（更确切地说应该叫“防火筛子”）只是在维持着技术上的安全区域，业务伙伴间信息协同的需要更加迫切，但在此之前还要跨越频频出现的软件平台之争、技术标准之争
• 语义网络（Semantic Web）、BPEL、面向对象语言/脚本语言、战术性BI、XML数据库系统集成虽然都可以从某个方面“更快”地解决业务逻辑、技术环境、数据实体方面的变化，不过相对于市场而言，尤其是那些不期而至同时很可能转瞬即逝的市场商机而言，还是适应得不够快

但如果要满足这些要求，对于软件产品的提供者似乎也太过苛刻，毕竟“众口难调”，既然不好调和就不妨交给用户自选，更加人性化、易用的Mashup也许会成为解决新软件危机的一个突破口。

1. 返回顶部

   能否提供reference?

   2008年6月18日 上午4时8分 发表人 Mo Li

   按照软件工程学的介绍，软件危机（Software Crisis）是软件发展第二阶段末期 今天，通用的商业软件和开源软件已经相对过剩，但软件行业的危机不仅没有缓解，而是更加严峻 请问引用数据的出处是哪里？

   回复

2. 返回顶部

   hehe

   2008年6月18日 上午5时7分 发表人 Richard Zhang

   难道是楼主看了我的文章有了感想？ http://www.cnblogs.com/pootow/archive/2007/10/29/941753.html

   回复

3. 返回顶部

   ref

   2008年6月19日 上午12时58分 发表人 hello hello

   IBM Redbooks 1、Managing Information Access to an Enterprise Information System Using J2EE and Services Oriented Architecture 2、Patterns: Service-Oriented Architecture and Web Services Microsoft Architect Journal: A Study of Architect Roles by IASA Sweden

   回复

4. 返回顶部

   ref

   2008年6月19日 上午2时18分 发表人 hello hello

   SOA：原理•方法•实践，第 1 部分: SOA 的基本概念 1.4 软件工程的演变和面向服务体系结构 http://www.ibm.com/developerworks/cn/webservices/0708_xinsheng/index1.html?S_TACT=105AGX52&S_CMP=techcsdn IBM Redbooks 《Managing Information Access to an Enterprise Information System Using J2EE and Services Oriented Architecture》 2.2.3 Components and SOA http://www.redbooks.ibm.com/abstracts/sg246371.html?Open Separation of Concerns in Middleware http://www.research.ibm.com/AEM/mdsoc.html IBM Redbooks 《Patterns: Service-Oriented Architecture and Web Services》 2.1.2 Service-oriented architecture as a solution http://www.redbooks.ibm.com/abstracts/SG246303.html?Open

   回复

5. 返回顶部

   Re: ref

   2008年6月19日 上午2时26分 发表人 hello hello

   SOA：原理•方法•实践，第 1 部分:
   SOA 的基本概念 1.4 软件工程的演变和面向服务体系结构
   http://www.ibm.com/developerworks/cn/webservices/0708_xinsheng/index1.html?S_TACT=105AGX52&S_CMP=techcsdn
   
   IBM Redbooks
   Managing Information Access to an Enterprise Information System Using J2EE and Services Oriented Architecture》
   2.2.3 Components and SOA
   http://www.redbooks.ibm.com/abstracts/sg246371.html?Open
   
   IBM Redbooks
   Separation of Concerns in Middleware
   http://www.research.ibm.com/AEM/mdsoc.html
   
   IBM Redbooks
   Patterns: Service-Oriented Architecture and Web Services》
   2.1.2 Service-oriented architecture as a solution
   http://www.redbooks.ibm.com/abstracts/SG246303.html?Open
   
   Microsoft Architect Journal:
   A Study of Architect Roles by IASA Sweden
   
   

   回复

6. 返回顶部

   太专业，看不懂

   2008年6月19日 上午5时52分 发表人 sun baoming

   看后后面突然感觉思路断了，不知所云。

   回复

7. 返回顶部

   这本是常态

   2008年6月22日 上午2时38分 发表人 jayden guan

   软件开发在解决问题方面做得越是成功，就会出现更大、更复杂的问题等着去解决。 如此循环，形成一个正反馈，直到被认为陷入所谓的软件危机。 还是去读读 老文《没有银弹》吧。

   回复

• 更早的 >