项目总结

       项目已经开始了小半年了，延期快2个月，不大的项目原计划2011年4月中旬开始，2011年8月中旬完全关闭该项目，包括内测和交由测试人员进行模拟用户测试。现在项目基本结束，

总 结：

       存在的问题，项目开发没有项目计划书，没有完整的软件uml图，依然是遇到问题解决问题的作坊式生产模式，说是一个新的项目，既然是新的项目就该从用户需求到研发规划，一系列的文档以备后用，不过照现在的形式看来，之前说的需求文档，uml图等一些列先期条件会到产品研发出来之后在补齐这样的敷衍形式也不会补齐了。

        项目实施初期因为项目并未勾画uml图并进行一些系列的软件架构设计，导致分配给各程序员手中的是一个个独立模块，且未说明各个模块间的相互调用接口和各自模块在新项目构建中所处位置，尽管有该项目上一个版本作为参考依据，但是新项目总不能遇到问题就是一句”参考老版本的代码“这样就能够完成的，项目中的交流实在是太少，各个程序员都知道自己在干什么，但是都不太清楚自己应该怎么跟别人的模块匹配上。

        我只是一个小小的程序员，但是在公司从该项目立项到现在的基本结束全程参与，中间交与测试测出bug后修改无数次，很多原因都是先前未能进行前期设计引起的，这个在之后的应该改正，对于这么小的一个软件项目中居然存在这么多的问题实在不是我一个人能够解决的，但是设身处地的考虑一下还是很有必要的。如果我是当前项目的项目经理，我会怎样：

公司比较小，所以我们研发部参与此项目的一共7人，水平各有高低。

         1、进行前期软件立项之后的软件架构的规划，在4到5个月的开发周期中，前期规划的重要性会影响到之后任务分配，编写代码，和测试时的bug归属问题，在这样一个在上一个版本基础上进行重新开发的项目来说，了解原有项目的存在的结构问题是一方面，而另一个重要的方面就是在原有的基础上进行重新的设计，如何避免原有的错误和引入新的错误，并且增加软件的新的功能，在如此充裕的时间框架内，提取一个月的时间进行软件的项目规划和设计，和产品、销售部门进行交流讨论，形成需求文档，此文档不一定需要多正式，但需要体现出新软件所能够提供的功能。这点在公司内部完全可以实现，现在完成的项目中就存在软件已经基本结束但是产品和销售却没有见过新软件什么燕子、具体有什么功能等问题，这个实在是太。。。。。

       2、形成需求文档之后，开始规划新软件的结构，将此需求文档交项目经理助理形成一份相对正式的文档保存。uml什么的择需而用，设计软件架构图不过一个工具，方便参与此项目的人相互交流，方便以后新增参与人员的理解，所以可以择需而用。共同开会交流讨论，设计出架构，类，用例等图，开会使大家都熟悉并了解软件的各个层次和功能架构，为下一步分配模块和调用接口做准备，并尽量考虑到尽可能多的结构设计不合理，环境变化等带来的可能错误、这样会在后面避免很多因为此带来的重复劳动（本人深有体会，某个结构自己规划设计，跟其他人配合时发现这样那样的不合理，不得已又进行子模块的重新设计，编写代码等等），形成各类图，交由助理细化。

       3、分配各个模块确定各模块间调用接口，其实接口是最重要的，模块间相互调用出现问题大多都是此，分西瓜，跟据个人能力分西瓜，这个其实是最不好搞的，即想让一般的有所提高又不能分配超出个人能力的模块。确实不好搞。这样前期分析设计规划基本完成，一个月够不，够了。下个月各干各的，写代码，写各自的模块，遇到问题是肯定的，多交流很重要（我们研发部经常一天都没有人说一句话，这样的死气沉沉的研发部就本人经验来看确实效率低下），

       4、软件合成，合成是对各个写好模块进行集成和平台适应性的调整，负责合成的人需要对程序的总体架构有更好的了解，需要准确的知道自己负责集成的模块的进度，相互之间的调用情况等等，集成完成之后可以在内部测试跑跑，没有什么结构，逻辑性的错误之后可以交给测试人员进行测试了，测试的测试文档需要在程序员编码的时候同期编写。

        5、测试的时间是2个月之内，从界面的不规范和功能的不完善都是测试人员检测，并研发修改，然后回归测试。测试检测出来的问题有的是显性的，有的是隐形的，就是说有的测试说的只是问题的表象，问题的实质往往并非如此，这样就需要负责集成的人分拣软件模块，检出是谁出现的问题，递交问题并修改。按周为单位进行版本更行递增。测试末期基本上就不会有太大的改变，也是在此同期，研发做项目总结，助理完成本项目关于研发部分的文档，待项目真正结束之后将测试部分的文档添加到项目文档中。研发经理做出总结。

        项目架构的设计很重要，不能再这样草草了事了！！！