软件开发所必须做的事情的清单

  软件开发所必须做的事情的清单

虽然我并不是一个很有经验的软件开发管理者，但是在这几年的摸爬滚打中还是有一些自己的心得的，下面先记录下来免得忘掉。

 1．  要有代码归档库

代码归档库是在开发中必须有有的，现在我们一般使用vss、clearcase以及CVS（或者subversion）管理我们的代码与文档与我们的安装包。

从实际的使用上看VSS不能满足大规模使用的要去（同时使用的人越多VSS的速度就越慢，人们的耐性越少）clearcase太大也太贵了，我们现在的使用基本上把clearcase当成能切分支的VSS在用，不知道知道这样的用法，Relation公司的那帮人会不会晕倒：）

建议使用CVS，这个便宜，简单，并且我们所需要的任何功能都是可以提供的。

我个人建议文档与代码库应该是合一的，这样可以减少文档与代码不一致的可能性。

 

下面列一下我个人认为的一下重要的事情：

（a）       代码、文档等的修改一定要增加修订记录。要明确下面的信息

什么人、什么事、在什么地方、修改了什么。只有增加了修订记录这个归档库才真正的发挥了他的作用。

（b）       代码转测试，版本归档一定要打label。这样可以简单的去到一个以前的版本定位问题

（c）       代码/文档/发布包的权限需要控制，按照最小授权的原则进行授权。

（d）       配置库要定期备份，防止数据丢失的发生。配置库管理需要有专人负责。

 2．  要有自动归档工具

自动归档工具要保证可以从原始的代码直接生成我们的安装盘，并能记录中间产生的问题。发给项目组进行处理。

这里需要强调的就是从源代码开始的，而不是从其中的某一个状态。

代码归档要能在夜里自动进行也能手工触发。从我个人的感觉上看，使用GUN make工具与shell进行处理是一种比较好的方式，在windows还是有一些不舒服的地方的。一个项目组要保证有一组机器能专门的进行环境的搭建。

 3．  要有自动ST、UT测试工具

自动ST、UT工具是版本开发的一个关键的部分，只要能做到这两点我们就可以很容易的能聚焦于软件的质量。

UT、ST工具要在软件的设计时就要考虑，真正的软件是设计出来的。

自动ST、UT测试工具与自动归档工具构成一个统一的整体。每天晚上都要有下面的一个过程

（a）       从配置库上去最新的代码

（b）       在目标机器上编译（编译时自动执行UT）

（c）       部署到测试机器上

（d）       自动执行ST

（e）       将结果发送给项目组成员

实际上如果完成上面的部分我们需要的只不过是每天喝着咖啡看邮件了。

这个过程中发生的问题需要强制在当天能处理完毕，防止在第二天也出现类似的问题。

在实际的测试与实际运行中发现的问题要同步的更新我们的自动测试用例库

 

4．  要有BUG管理工具

BUG管理工具是一个比较高的要求。我们最核心的目的就是要保证问题的闭环，这里不只是一个BUG管理的问题，实际上我们所有的任务都是可以安装这个方法来管理的。

现在最好的工具就是notes的工作流，但是也有其不好的地方--太慢！我们不必强求形式

只要能达成闭环就可以了。下面说一下一个简单的BUG单处理流程

 

（a）       BUG被测试人员创建

（b）       测试经理审核

（c）       开发人员定位

（d）       项目经理审核

（e）       开发人员设计方案

（f）        SE/TL审核

（g）       授权修改

（h）       修改实施

（i）         SE/TL审核

（j）         授权归档

（k）       分配测试人员回归

（l）         回归测试

（m）     BUG单关闭

实际的流程包括单不限于上面的步骤

 

5．  要有需求管理工具

需求管理工具保证所有的需求被充分的实现而不被遗漏

需求管理包括：

原始需求（包需求）

分配需求

设计需求

我们要从原始的需求一致到最后的设计需求完整的管理，包括在后面需要增加相应的测试用力，并记录测试结果这样在最后交付的时候就可以清楚我们已经实现了什么东西，什么东西还没有实现。

 

6．  要有详细设计文档

要有详细的设计文档，从系统、子系统、模块、对象各个层面上都要有明确的分解。我不喜欢正式的设计规格、需求规格、概要设计与详细设计这样的流程。上面的这些文档实际上都是描述的同一件事情，只是关注点与层次上是不一样。

我认为要抓住核心，只要能提供一个能让一个完全不懂这个系统的人能在2天之内能写相应的代码就可以了。

 

7．  代码对比工具

代码比对工具是我认为最好的工具，有很多问题都是在这个工具下面被发现了，我感觉

BC是最好的。这里不强求使用哪种工具，但是这种工具是必须的。

 

8．  代码静态与动态检查工具

PClint、PURIFY这样的代码检查工具是必须的，这些工具的使用也应该做到在每天的自动构建中执行，并记录详细的结果。有问题必须修改，不过要强调的是在写代码的时候就要使用这些工具进行处理了。

按照严格的原则没有经过静态处理的代码是不能进行编译的。

 

9．  单独的测试

要有一个单独的测试来测试最后的版本，测试的入口应该是原始的需求。这样可以减少因为思维定势导致的问题。测试过程是一个降低总拥有成本的过程，是一个窗在价值的过程。

 

10．              经验与数据的收集

项目组中遇到的问题，生产率应该被自动记录下来，并在以后的过程中自动执行之。这里关注点我个人认为如下

l         经验文档的总结

l         代码生产率的度量

l         缺陷密度的度量

l         需求稳定度的度量

l         进度的跟踪

。。。

 上面是我在实际的项目中的一点经验，现在先写一些，实际上还有很多的事情需要确认，比如严格的同行评审等，以后再完善。