危机还是差距?下这个词的起源,软件:我变难了

危机还是差距?

我们先说一下这个词的由来。众所周知,“软件危机”一词最早出现在第一届北约软件工程会议(1968 年,德国)上。不过这个词也有争议,当时还有另一个竞争对手,“软件鸿沟”。这个时间点也是一个很重要的背景,后面会提到。

硬件:我变强了,软件:我变硬了。

那么这场危机到底是怎么回事?著名的图灵奖获得者 Edsger Wybe Dijkstra(没错,就是教你计算最短路径的那个)说:

更强大的机器变得可用,不仅更强大一个数量级,甚至更强大几个数量级。但是,我们没有发现自己处于解决所有编程问题的永恒幸福状态,而是发现自己陷入了软件危机!

出现了更强大的机器,不仅强大了一个数量级,甚至更强大了几个数量级。然而,我们没有发现自己处于解决所有编程问题的永恒幸福状态,而是发现自己陷入了软件危机!

当时(1968)计算机硬件发展很快,已经发展到第三代(集成电路),计算能力和稳定性都有很大的提升。硬件能力的快速提升使得对软件应用更感兴趣的人对游戏的期待也有了很大的提升,比喻只有核显的时候可以玩lol,但是有了RTX3090,难道不想体验4K60帧的吗?飞行模拟。因此,软件的复杂性也迅速增加,但是当时的软件开发方式并不能在预期的时间范围内及时交付满足质量要求的软件。简单地说,钱花光了,时间耽误了软件危机是指,最后交付不符合要求,质量很差,后期很难维护(好像是2077),这就是软件危机,源于硬件开发与软件开发的差距,体现在用户期望与实际交付之间的差距。

进化,软件开发过程!

回到解决方案,其实实用标题中的“解决”并不是很准确,应该是“尝试解决”。在我看来,软件危机从来没有真正解决过,下一次应用需求和开发能力错位的时候可能还会出现(比如量子计算机的软件开发),但是软件工程会因为不断的改进和优化软件而延迟发展过程。这场危机。

开发过程一般用模型来描述。比较经典的模型包括:

瀑布:顺序定义了软件开发的各个阶段,每个阶段都必须交付清晰的文档(需求规范、总体设计、详细设计等),因为不鼓励流程回到上一阶段,有是一定程度的不灵活批评。迭代:将项目分解成更小的部分,执行一系列迷你瀑布,完成后继续进行下一个迭代。这允许对需求和设计进行更灵活的调整,从而降低项目风险。螺旋:结合瀑布和迭代,强调迭代风险分析,每次围绕螺旋的行程都要经过四个基本象限:确定迭代的目标、备选方案和约束;评估替代方案,识别和解决风险;在迭代中开发和验证可交付成果;计划下一次迭代。敏捷:基于迭代开发,但与传统方法相比,提倡更轻松、更以人为本的视角(更少的文档,更多的人话)。

模型当然有很多,比如快速原型制作、极限编程、测试驱动开发等等。这些都是在特定环境中诞生的软件开发过程,每个过程都有自己的优点和局限性。虽然敏捷已经成为目前的主流模式,但不可否认很多传统模式也有自己的成长土壤软件危机是指,选对了就是最好的。

软件开发过程的不断演进是解决软件危机的最佳途径。辩证地讲,每一次软件危机都会促进软件开发过程的演进。

参考

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论