题我在后面也会提到。
需求分析阶段出现的问题，解决的可操作性不是很大，更多的是从思想或经验上解决，而后面几个阶段出现的问题都相对具体一些。
2、设计阶段
设计阶段的问题相对比较明显――结构设计不合理，或者说还不够。一个传统的C/S结构的系统，基本结构我们采用了经典的三层模型来划分系统。由于是在旧有系统上的改进，我们在尽量不改变原有系统的基础上添加新的功能。
主要的问题可能就是体现在没有对旧系统进行改进。旧系统本身有一些复杂的功能，逻辑关系也比较复杂，耦合度非常高。
所以，在新需求来临的时候，我们的第一反应就是尽量不去动原来的设计与代码，保证原有系统功能不会发生变化。这一点就暴露出了我们没有去拥抱变化的决心与胆量。虽然旧系统很复杂，但是我们不能去故意回避它。对于旧系统中设计的不合理的地方，应该主动大胆的去进行重构。
其实重构的作用就是对不合理结构的进行改进，设计模式更是在设计结构的变化改进中才能体现它的价值。而这些东西，在我们的项目中都没有应用.这可能跟我们的保守心理有关：只要不出问题，我们就不去动它，哪怕结构是多么的错综复杂。这种消极的观念在当今的充满变化的世界中是不太有前途的。项目经理要有足够的决心去做，同时，也不要担心去变化。
当然，可能有人会说，时间紧怎么办，其实这种付出对于项目的整体是只有好处没有坏处的，因为结构合理会让开发人员会更少的时间去理解代码，减少代码开发的复杂度，提高代码编写的质量。唯一需要考虑的就是如果改动的话，如何来保证这种变化对原有系统的功能不产生影响。这就需要有更多的测试，最好是单元测试来保证，这就是下面会谈到的问题。
3、编码阶段
编码主要还是受了设计的限制，我们的主要工作就只是在原有的结构上添加一些类与方法，以及对原有的代码进行修改。前面也提到了，我们采用了比较保守的作法，没有对代码进行重构，放任这种高耦合的代码存在，导致我们在编码过程中花费了不少精力和时间去理解它们，并在其中加上一两条更加加深耦合度的代码。
其实到了编码阶段，很多问题都纠缠到了一起，已经分不清因果了。比较说单元测试，首先我需要承认的一点就是没有足够的决心去做充分的单元测试，思想上也没有做好充分的准备。除去主观的因素之外，还有一点就是设计的结构不合理，很多的逻辑被处理在表示层中，数据处理则被加到了逻辑层中。
没有划分出更多的接口供单元测试来验证。但反过来说，没有单元测试用例的支持，也降低了我们想要进行重构的决心。除了上述的问题之外，还有一些细节的地方，如硬编码，命名规则等都在一定程度上对代码的质量产生了影响。
改进的办法，一是从主观上接受变化的现实，主动的对代码进行改动。单元测试一定要进行，最好结合统计覆盖率的工具一并进行，这样对于每个接口，都保证有充分多的测试用例来跑完尽可能多的路径。在项目的质量管理上面，要求还需要更加严格一些，一定要按照规范来进行编码。
4、测试阶段
代码完成之后，测试的工作也随之展开。但是由于成本的原因，我们并没有再加入专业的测试人员来进行，而只是用开发人员自己来进行系统测试，让开发人员互相测试别人实现的功能。由于开发人员与测试人员所需的专注点不同，造成了开发人员很多问题在测试中没有被发现，缺乏测试的经验。
从另一个方面说，是开发人员不能够及时的转换自己的角色，而是还把自己定位在开发人员上面，更加关注的问题出在什么地方并立刻去解决它,而不是设法去发现隐藏的Bug。当然，还有一些细节的地方，比如说测试都应该是开发人员发布一个安装包，然后单独进行测试，但有的时候为了图省事，有的功能在调试状态下发现通过了，在安装包中就没有再验证，有时也会出现意想不到的情况发生。
这些问题都是在项目管理中暴露出来的，可以说是由于项目经理对于质量的要求还不高，有的时候为了片面追求成本与时间而忽视了质量，从而造成了质量的下降。
软件的质量可能就是被这一步步的失误，错误，粗心等等影响了。算是个总结和教训吧，也希望大家能够说出你的想法与意见，多多交流，共同进步。