软件开发过程一般是要尽早完成需求分析，停止需求的变动，将这些需求作为设计的基础，然后开始构筑系统，这是瀑布方法————基于计划的生命周期。这种方法是通过大量的前期工作来减少变化。一旦前期工作完成，当需求变化时，这样的方法就会有很大的问题。
另外一个重要原因是，许多单位的管理模式都处在探索阶段，可能引起变动的因素很多，因此根据现行的管理模式设计出的信息系统将面临使用单位管理模式的变化的考验，包括许多的工作流程的细节处理方式式否合乎工作人员的习惯等问题。
系统在设计时要充分考虑这些不确定因素，才能适应这些变化。特别是数据结构要以系统灵活性为主，其次才是考虑系统性能的提高。
在软件开发出现工期或bug等问题时，开发人员常抱怨是由于需求的变化造成的，对于软件的修改存在抵触情绪。实际上在商业软件开发领域，需求变化是很正常的，问题是我们该怎样对待它。为了适应需求的变化，必须采取不同的设计态度。这里介绍敏捷方法的几点思想，对如何应对需求的变化很有教益。
主张简单、递增的变化、拥抱变化是敏捷建模方法的核心原则之中的三个。
敏捷建模主张当从事开发工作时，最简单的解决方案就是最好的解决方案，尽可能的保持模型的简单。
对无法在项目一开始就固化的需求进行演进型的设计。你现在不必要对这个系统进行过分的建模，只要基于现有的需求进行建模，随着项目的进行，项目环境和需求发生变化时，再来完善和重构这个系统。
递增的变化是指你不用在模型中包容所有的细节，你只要开发一个小的模型或是概要模型，打下一个基础，然后慢慢的改进模型。
敏捷建模采取不同的设计态度来“拥抱变化”。它认为需求时刻在变，人们对于需求的理解也时刻在变。随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。对于用户的反馈，要勇于对自己的代码进行修改，丢掉坏的代码。
对于易变的需求，敏捷方法使用了一系列实践。其核心则是迭代式开发，寻求快速的反馈，用户经历过一次或几次的迭代之后，对软件开发和业务需求如何实现已经有了形象的认识，用户提出的需求基本上可以代表他们的真实需求。这时，就可以将需求进行冻结。后面如果还有修改，将是细节的调整，不会对软件的架构产生重大的影响。
此文章共有4页 上一页 1 2 3 4 下一页
文章来源：互联网
|
Leadge.com首页 > 知识库 
