最近拜读了软件工程的有关资料,感觉很有收获,遂写了这篇读书笔记。这篇读书笔记从“这个过程可以解决软件开发的哪些问题”,到“为什么出现这些问题”,然后“怎么解决这些问题”,最后是微软过程的解决方案。洋洋洒洒分了两大章,这是第一部分,在这里只写了我感觉对实际应用比较有益的东西。
第一部分,“软件危机”概念,具体有以下表现:
- 对开发成本和进度估计不准确
- 用户对“已完成的”软件系统不满意
- 软件质量不过关
- 软件不可维护
- 没有留下文档资料,后期维护艰难
第二部分,“软件危机”产生的原因
- 软件本身的特点。由于软件的代码缺乏可见性,所以质量难以评价。而且牵一发动全身,越到后期发现的问题,修改付出的代价越大。
- 软件开发与维护的方法不当。对用户要求没有完整准确的认识就匆忙着手编写程序,是一个很严重的问题。只有用户才真正了解他们自己的需要,但许多用户在开始时并不能准确具体的叙述他们的需要,码农需要做大量的调研,反复与用户进行交流,才能全面准确具体的了解用户的需求。
了解了问题为什么出现,下面我们就来谈一下,怎么去解决。
第三部分,“软件危机”解决方案
为了解决这些问题,既要技术措施(方法和工具),又要有必要的管理措施。一门新兴学科——软件工程,应运而生。从技术和管理两方面研究如何更好的开发和维护软件。
软件工程,采用工程的概念、原理、技术和方法来开发和维护软件,把经过时间考验而证明的正确的管理技术和当前的能够得到的最好的技术方法结合起来,以经济的开发出高质量的软件并有效的维护他。
作为一门学科,他有自己的本质特征,基本原理,方法学,定义了软件的生命周期,还有很多软件过程的模型(即获得高质量的软件的管理步骤),这里就不一一摘抄了,下面我们来说极限编程。
2001年17位专家起草了敏捷过程,由四个简单的价值观组成:
- 个体和交互胜过过程和工具
- 可以工作的软件胜过面面俱到的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
- 用户作为开发团队成员
- 使用用户素材
- 短交付周期
- 验收测试
- 结对编程
- 测试驱动开发
- 代码集体所有
- 持续集成
- 可持续的开发速度
- 开放的工作时间
- 及时调整计划
- 简单的设计
- 重构
- 使用隐喻
关于极限编程的开发过程和开发模式,以及微软过程的有关内容,会在后面的博客 ,软件工程学概述(二)中讲述。