先说这个完整的项目吧，从需求分析到后期的架构设计、编码、测试全程参与负责，所以感触最深。

　　首先需求分析是一个软件工程中古老而又往往具有决定性意义的一个话题。需求分析是对业务建模，从客户零碎、片面、口语化的描述中捕获用户最感兴趣的内容，然后通过各种方式(文档、PPT、Use Case等)将这些内容可视化，进行重现，有条件的话，最好能够模拟用户场景。业务建模又包括业务流程建模和业务数据建模。它们之间具有非常紧密的关系，当然如何从需求中捕获这些流程以及核心业务数据，需要一定的方法论和工具指导，对于我而言，这个地方需要继续学习和加强。另外需求分析的输出是需求规格说明书，然而这个文档最终怎么样转换为设计、开发阶段的输入，并可被追踪、检查其实现情况，这又是一个问题。

　　需求分析整理完后，至少保证开发人员对需求的理解全面、准确，没有二义性。然而，从我们实际项目执行的情况来看，只有需求还是不够的，毕竟需求只是定义了what，对于how还需要重新定义，这也标志着项目整体而言已经进入设计和实现阶段。

　　系统的实现设计上是一个分析问题、解决问题的过程，需求明确定义了问题是什么，所以分析问题的过程就变成如何将问题分解，自上而下的将问题逐一进行分解，针对每一个子问题提出其解决方案，最终再由一个自底向上的过程，将每个子问题的解决方案进行合并、归类等整理，最终成为一个完整的解决方案。

　　系统的分析设计具体而言，包括了系统的架构设计，架构其实就是非功能性需求的解决方案，例如系统的分层、子模块的划分，模块之间的交互、层与层之间的交互。

　　编码阶段印象最深刻的就是一定要坚持codereview与unit test，不要以时间忙和没经验作为借口，最终你会发现，花一定的时间做这些事情，可能会花更多的时间来完成这个项目(实际上也未必)，然而最终产品的质量、系统的可维护性要远远高于不做这些事情所产出的结果。经验也是可以积累，去学习的，最终还是看你是否想去做这些事情。

　　测试工作的重要性没有人怀疑，然而如何做才能最有效，对于我们team而言，我们还只是局限于根据需求写出test case，然后按照test case去跑。至于test case的质量、覆盖率还没有一个客观的评估标准，另外如何提高test的自动化率也是值得思考的一个问题

　　本文出自 “智慧网管” 博客，请务必保留此出http://wisenms.blog.51cto.com/813376/435275