金融应用项目的过程改进

我们都知道软件工程、规范管理的好处，但我们往往会因为其他一些因素，如进度的压力，项目生存的压力，而使我们走‘捷径’，实际上，我们在为此付出更大的代价。一些逐渐暴露出来的问题在细水长流似的消耗我们的时间、精力、信心，而且还没有要结束的样子。

继续看下去的前提：我们都觉得要改变这种状况

改变现状主要有两种方式：1.引进CMM或ISO 2.过程改进（SPI：Software Process Improvement）

我们知道，软件过程管理不是靠直接引进就能适用的，SPI更适合我们。SPI的思路是分析现状，总结出经验并找出需要改进的地方，然后按优先级排列，对最需要改进、最适合改进的部分考虑改进。然后制定改进计划，实施，阶段总结...通过这样不断的反复来改进我们的流程，探索出最适合我们的方式。改进时，CMM、ISO以及XP开发方法中都有可取之处，如CMM中的一些KPA可以作为我们的改进目标，当然，最重要的是裁减那些方法与流程，我们只要最适合我们的部分。

按照这种思路，我个人认为我们在这些方面需要改进：
1.配置管理
随着项目文档的增加以及人员的加入，通过手工的版本控制越来越不适合。经常有人问："最新版本在哪里?",
"你给我的是不是最新版本","你改了那些地方"等，而且不可避免的会出现版本混乱的局面。
2.项目文档
项目文档不全、不完整。开发思路都保存在开发人员的脑子里，没有文档化。如果有人员变动，对项目就是一个灾难。还有，一些问题总是被人无数遍的重复：如"Oracle怎么配","BDE怎么配"，"如何开发一个新业务"... 这样，我们总是很忙，但效率不高。如果有一篇文档告诉大家怎么做不就省事多了。否则，有新的人员加入，我们还要回答同样的问题。
3.质量保证
因为需求不清以及设计考虑不周，我们已经吃了太多的苦头。一些质量保证手段比如：评审，会降低后期更改的风险

我也对优先级以及改进的时机进行考虑，认为可以把配置管理当作突破口，首先进行改进。以下是配置管理计划。

配置管理计划

概念说明

1． 配置项：项目中需要管理、控制的部分，包括文档、源代码、规范等

2． 配置基线：(BaseLine) 是配置库中每个配置项版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。基线的建立便于检验和确认阶段开发成果，也使跨越基线的变更受到严格控制，如“需求冻结”。

3． 开发库：供开发人员专用的配置库，其中的信息可能做频繁的变更，控制相对宽松

4． 受控库：存放阶段产品的配置库

5． 产品库：软件经过系统测试后，作为最终产品存入产品库，等待交付用户或现场安装。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有