确定文档的有效性（Validity ）顺便要提的一句是关于文档，需求文档是相当重要的，可是目前存在一种奇怪的现象，本来说必须要有文档，而且是按照某种特定的格式，当然这没有错，但接下来，却没有人关心文档的真正内容是否正确，格式是否真的合理，是否实用（而且很多情况下是在几天时间里赶出来或补上去的），例如我遇到一个例子，需要在原来的需求基础上进行后续开发，文档找到了，完全符合格式的要求，但是我在里面找到的线索是有限的，结果是自己花几天的时间查找数据表结构、甚至查看数据表的内容，询问当时的开发人员，才分析到所要的关系，这种情况在设计文档里也存在，所以同时提一提，希望我们的开发人员、PM 以及各级领导可以注意文档的有效性和有用性问题，甚至对文档的格式进行一下合理性检查。建立代价估算（Cost Estimate ）概念这一点对开发方和客户同样重要，因为如果出现需求变更，不可避免将带来成本的增加、开发时间延长等不良后果，这样的影响是双方的。这时候需要区分需求变更的原因，是客户方必要/不必要的要求，还是由于开发方的工作失误，还是双方都有原因，然后对现实情况进行分析，得出双方实现变更需求的需要的成本，包括时间，人力，资源等等方面，再与客户商讨是否必要进行变更和如何在最小代价下实现变更。当客户看到实际的代价估算，他们也会再一次慎重地考虑需求变更问题，也会更容易理解系统建设中的进行状况，自然开发方也不用负担所有的需求变更成本，
所以进行成本分摊还是有其积极意义的。当然还有建立需求变更版本控制等等专业的需求管理，在这里不做专门论述。从软件分析和设计着手前面说了面对需求变更的几种策略，那么从软件系统分析和设计的角度来看，通过采用合理的分析设计方法，进行可扩展性设计可以有效地降低需求变更引起的风险和维护代价。
采用OO 技术
采用OO 技术可以建立易于改变和加强可重用性的软件系统。
对于OO 技术，我想现在已经不是什么陌生的概念：
1 封装（Encapsulation ）可以把问题影响的范围缩小，外部的变化要求对系统的影响可以限定到某个类层次或某些类层次中，从而改变系统的一部分相对简单；
2 继承（Inheritance ）可以使改变基于原有技术基础，很大程度上减少重复开发工作；
3 多态（Polymorphism ）的应用可以使开发和设计人员在相对统一的接口下更改系统的实现细节，从而改变系统的行为；
4 而且由于对OO 的类体系结构业界有非常清楚明晰的描述方式，就是目前规范的描述语言-UML ，非常易于被开发组的理解并达成共识，促进开发组成员之间的合作以及加强软件开发工作的可延续性；可见本身即是一种增强软件可维护性、健壮性以及保持设计稳定性的一种分析和设计方法，本身可以在一定程度上快速对需求变更进行反应，并可相对减少需求变更需要的成本。（OO 的意义在于分析和设计软件系统的思考方式，以及建立对象库以后的软件重用将给软件系统的开发带来质的改变，但是在建立OO 开发体系之前的过程，一定会是一段荆棘遍布的路，需要付出加倍的努力以及达成思想的转变。这里还有一个误区需要澄清的是很多人以为用了C++，PB ，VB ，DELPHI 就是面向对象的开发了，其实只是用了一些面向对象的工具，骨子里仍然是结构化的分析和设计方法，套上一层OOP 的外壳而已。）可扩展性设计（Extensible-Design ）
此文章共有3页 上一页 1 2 3 下一页
文章来源：中国项目管理资源网
 软件开发项目管理培训课程方案
|
Leadge.com首页 > 知识库 
