关于项目前期策划

      当我们接手到一个项目的时候，首先是要写需求分析，一份明了，详细，合理的需求分析可以帮助团队在很大程度上提高编写速度。但我感觉写需求分析是最头疼的一件事，因为你必须要想到程序中的每一个细节，每一个功能该如何实现。

     因为我在我们小组担任组长，所以每次项目的需求分析都是我来写的。还记得第一次项目是做一个简单的JAVA控制台应用程序，学校只要求实现增删改查，而且所有的数据都只是保存在数组里面。因为是第一次做项目，谁都没有经验，就没有写需求分析，甚至根本不知道需求分析这个东西。第一天的时候我们就遇到了很多像什么命名不统一，类的调用相当混乱之类的问题。对当时的我来说，是一个极其大的困难。于是我们立即停止了编写代码，开讨论会，然后大家一起制定了一套命名规则，而且给每个人分发了一个相对独立的模块，以减少不同组员所写代码之间的调用。以至于到最后完成项目的时候我们项目的文件要比别的组大上一半。。。到我们项目答辩都完成了之后，老师才给我们说需求分析是怎么回事，是用来干嘛的，到底有什么好处。当时特想骂那老师，不过现在回头想想，如果他当时直接跟我们说让我们写需求分析，我们肯定不会认真写，会感觉这个东西只是给内部组员看的么，只要大家交流好一点就可以完全不用它的。事实上，在我现在看来，写好一份需求分析要比编写代码的工作量大得多。后来在每次做项目之前，我都会自己花上两天时间写需求分析，做起项目来也就顺利得多了。

    扯了这么多废话，该说正文了、、、（以一个简单的三层架构C/S项目为例）

    写需求分析究竟应该从哪里入手呢？

    首先是功能分析，只有你对你所要做的项目的功能完全了解之后才能去想那个功能具体该怎么实现。然后要对每一个具体要实现的功能点进行非常详细的构思（哪个模块里拥有哪些功能，实现该功能需要怎样做，以目前的技术能不能做到，做到要用到那些方法，编写这些要多少的编码量）。如果功能确定下来了，整体到细节全都构思好了，可以说，你的项目已经做好了三分之一了。（因为我是个思维比较慎密的人，所以我把每一个实现功能所用的方法，需要几个类都写在了纸上。。。这个做起来相当麻烦。。。）

    功能确定下来之后就是设计数据库了，只要你前面的分析到位了，数据库的设计就相对来说很轻松了。确定实体，表间关系，是否建立索引，确定视图，索引，自定义函数，约束，画ER图（这些我一般都是在草稿纸上做的，做好之后才往电脑上敲）。做个数据库字典，画个物理模型。

    数据库有了之后就是详细策划了，详细策划一般都写在功能分析里面，因为我懒得每次在前面去编辑，所以我就直接写在数据库的后面。功能分析里面只写一些简单的功能概括，然后再在后面写一个详细策划。首先写公共类，全部写在一个文件里面，当然，根据不同的功能分开写更好（本人比较懒）。然后再写每一个功能实现要定义的类，要写的方法，需要调用（或继承）的类。

    当前面所有的工作完成之后，我都会好好看上两遍，一个是查找下有没漏洞什么的，另一个么，嘿嘿，就是好好欣赏下自己的劳动成果咯。最后要做的就是分配任务了，把前台交给一个人，数据库交给一个人，中间业务逻辑层平均分配一下就好了。再剩下的就是技术问题了。

    本人的第一篇笔记，把自己在做项目中得到的一点点经验跟大家交流下，当然，因为我才学软件开发没多久，写得肯定不好，也希望大家能帮我指点指点。（新手上路，多多体谅，多多体谅）