按照软件工程学的介绍，软件危机（Software Crisis）是软件发展第二阶段末期，由于硬件快速发展，引发作为“人件”的软件不能满足需求所导致的，作为副产品它催生了软件工程学的快速发展。但在很多企业已经把软件作为其业务神经的今天，通用的商业软件和开源软件已经相对过剩，但软件行业的危机不仅没有缓解，而是更加严峻。“适应性”成了新软件危机的主因。
软件危机的主要表现如下：
费用支出大大超出预算
用户不认可其功能
可靠性和维护性差
时间进度失控
40多年前我们总结其主因如下：
软件规模膨胀，逻辑趋于复杂
开发技术落后
开发方式落后
工具落后
但40年之后，除了第一条主因之外，其他方面都已经大大改善，尤其是伴随着C++、.NET、Java等一大批开源框架、开源工具、开源产品出现后，实际项目中我们需要自己编码的比例越来越小，常常是“技术等人”，而非“人等技术”。
但现实如何呢？我们不难发现危机的表现不仅没有减轻，反而愈盛。这说明主因发生了变化，在“唯一不变是变化本身”概念下“适应性”越来越突出。为什么工具、手段、方法学已经大大改善的今天还要一遍遍出现这个问题呢？技术和业务，尤其是后者。
十年前，传真还算很迅捷的通信手段，20年前电报和长途电话的地位更加突出，但现在信息往往是基于预定的邮件、短信和“WIFI Touch”
地球被互联网拉平，对外贸、制造业、投资、能源等类型的企业，很多时候商机的出现不再是年、月，而是几天甚至几个小时，IT如何快速解决这些问题，甚至是让用户凭借既有的IT系统自己解决，一直是软件行业奋斗但似乎还很遥远的目标
企业内部的竖井、企业间的信息壁垒因为资金和人员协作被逐个打破，防火墙（更确切地说应该叫“防火筛子”）只是在维持着技术上的安全区域，业务伙伴间信息协同的需要更加迫切，但在此之前还要跨越频频出现的软件平台之争、技术标准之争
语义网络（Semantic Web）、BPEL、面向对象语言/脚本语言、战术性BI、XML数据库系统集成虽然都可以从某个方面“更快”地解决业务逻辑、技术环境、数据实体方面的变化，不过相对于市场而言，尤其是那些不期而至同时很可能转瞬即逝的市场商机而言，还是适应得不够快
但如果要满足这些要求，对于软件产品的提供者似乎也太过苛刻，毕竟“众口难调”，既然不好调和就不妨交给用户自选，更加人性化、易用的Mashup也许会成为解决新软件危机的一个突破口。
网友评论