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