读林锐的<软件工程与项目管理解析>

      前后花了两周的的时间,断断续续地读完了林锐的《软件工程与项目管理解析》。边读边思考，自己原来参与的各种大大小小的也可以称作软件项目的东西，以及目前所在的这个小组在软件工程方面的现状，有点感触。

      “商业目标决定一切”，包括软件实现，测试等等。是里面提到的比较多的一句话。反观我们曾经做过和正在做的一些大小软件，存在如下一些问题：

      首先就是需求调查和可行性分析的不是很充分，没有真正了解目标用户及其对产品的需求，仅凭自己有限的网络搜索，很少的文献和主要是主观臆断的想法，来开发一个产品。导致开发目标自始至终都是很盲目，当然也就不会有什么有用的产品产生。

      有编程的规范，却没有真正使用。大家都是半瓶子醋，不是真正的计算机科班出身。互相之间没有代码审查的问题，代码只要当时看懂就可以了。没有考虑代码继承和复用，及别人阅读和理解的问题。

      其次是开发过程的管理比较少，几乎完全是根据自己的感觉，天马行空，开发计划不知道到变更了多少次，导致过程完全失控。

      并且，和软件相关的过程文档出了很少注释之外几乎一无所有，一方面，后面的人无从理解，维护和升级当然也就更困难了。有些时候，真的还不如推倒重来。

       再次就是对可重用性考虑的很少，总是在制造同样的车轮子（P198）.年复一年，基础的工作在不断地重复，很多无用的东西都是从头做起，真正做创作性的工作被挤占了。很重要的一点，是大家对目前可重用的成熟部件，软件，控件,SDK等了解不够。“低水平的重复”，占了很大的工作量。

       没有软件项目的配置管理，软件和文档的版本控制几乎为零。老版本和新版本经常前后混乱，浪费了时间了精力。当然，也就无从谈起小组编程，合作开发。

       测试过程一直强调，却一直没有落实，主要原因是，开发人员不愿意做测试，思想上觉得能运行就可以，前期测试较少，缺陷越来积累的越多。导致互相之间的配合较差。

      

 

       需要和能够做的工作：

       1。使用软件配置工具，提倡小组编程

       2。强调编程规范和开发文档。

       3。总结可重用的成熟部件。

       4。组内成员互相测试，减少缺陷，增加互相理解。

       5。重新思考各自项目的需求和可行性。