管理和控制–软件开发

        软件开发的管理和控制　　

　　软件开发是一项很复杂的工作，对于软件开发的管理和控制，现在有一门专门的学科：软件工程。在这方面有许多国家标准和国际标准。许多公司也有相    应的文档模版，及相关规定。现在不谈技术角度来规范软件开发的管理和控制，从管理和实践的角度来探讨软件开发的管理和控制应遵循的的一些原则。
　　对于软件开发项目中，经常出现两种极端情况，一种是创造了新的生产率和质量的纪录；一种则完全是一场灾难,不是被取消就是拖延很长时间。前者如在    很短的时间内，为了赶进度，在几乎不可能的时间内开发出一套软件产品，创造了软件开发的记录，满足了上级所要求的上机日期，由于开发时间太短，过于仓促，上机时，问题百出，试运行时间长达几个月或一年半载的，而且程序一改再改，维护工作量大。后者，如某套系统未弄清楚需求，或因设计问    题，开发失败。通过提炼这些成功和失败的例子,软件项目成功或失败的根本原因可能会更清晰一些。
　　在讨论这些原因之前,我们先来说明一下什么情况可以称为失败的软件项目。 
　　1. 由于费用超支或计划执行超时而终止。 
　　2. 完成计划的时间或费用超过了原计划的50%。 
　　3. 由于质量或性能上的原因引起和客户的纠纷。

　
　　错误1:没有软件项目开发的历史数据 
　　缺乏软件开发的历史数据是大多数软件项目失败的关键所在, 这样的结论也许使很多人感到吃惊,但事实就是如此。没有一个可靠的软件开发的历史数据会    使项目经理,程序员,客户对于软件开发的过程缺少清醒的认识。 
   假设现在你正在管理一个软件项目,而这个项目还没有一个公司在36个月内完成。作为一个负责的经理,你作了一个比较细致和保守的估计,然后告诉你的客        户和你的手下说你认为这个项目需要36-38个月完成。然而常常有这样的情况发生：你的客户和程序员要求把时间压缩到18个月。客户一方面希望软件尽    早投入使用而产生经济效益,一方面也想压缩项目时间作为一个讨价还价的筹码;而程序员一方面可能过于自信,一方面尽早结束项目也能使他们多赚点钱。而此时你的手头上也没有一个可靠的软件开发的历史数据,在他们的压力下你同意了18个月的计划,于是一场灾难开始了。 
　　在项目的开始阶段你发现计划被拖延了,于是开始向程序员们施加压力,要求他们加快进度,程序员为了追求进度而不得不把其它指标放在一边,这些问题不断    的积累下来而项目经理却蒙在鼓里。到了项目中后期这些质量问题会不断暴露出来,而且互相关联并且难以解决,甚至有些是系统设计的问题,这时才发现好    多模块要推倒重来,18个月完成计划变成了天方夜谭。虽然上面只是一个虚拟的例子,但在实际中这种情况比比皆是。问题的关键就在于软件开发的历史数    据是反映软件开发队伍的能力的标尺,没有了这个标尺,就无法对软件的开发过程有一个清醒的认识。 

　　错误2:不重视使用软件费用估值工具软件和计划工具软件
　　软件开发方法述评
　　60年代中期开始爆发了众所周知的软件危机。为了克服这一危机，在1968、1969年连续召开的两次著名的NATO会议上提出了软件工程这一术语，并在以    后不断发展、完善。与此同时，软件研究人员也在不断探索新的软件开发方法。至今已形成八类软件开发方法。

　
    　错误3：忽视用户的需求的变动 
　　尽管最初的用户需求在签定开发合同时已经包含在需求说明书中,但在整个开发周期中期望用户的需求一直保持不变是不大可能的,因为用户对于如何应用    计算机软件并没有一个成熟的经验。在项目进行中用户的需求会不断的增长,一般情况下用户的需求以每月1%的速率增加,如果一个项目在12个月内完成         最终将有超过10%的改动,如果项目要持续36个月,最后将增加1/3的功能。每月1%也只是一个经验数据,一个缺乏计算机应用经验的用户会更频繁的改变和     增加他的要求。因此在作项目的费用和时间估计时一定要考虑用户需求的变化。一种比较明智的方法是在签定开发合同时把用户需求的改动和经济利           挂钩,如果用户增加或改动了需求,那么软件的交付日期可以推迟,费用也应增加。 

　　结论: 
　　软件开发是一个带有一定风险的工作,为了把风险降到最低, 在项目的执行中项目经理必须严格的监督项目的进度,对程序员不愿复查的坏习惯要给予纠正。项目经理必须要从软件开发的历史数据和辅助工具包提供的数据中作出精确的估计,在作估计时他应该考虑为不断变化的用户需求留出富余量。