浅谈软件开发过程及项目管理

做软件也有几年了，将学到别人的经验，项目中自己的体验，参加培训的收获一起总结一下。

需求阶段：
首先要明确软件项目开发完后是为了解决什么问题？对于要解决的核心问题必须要明确，以后可以重点设计作为软件的亮点。明确软件的最终用户是谁？有几种类型的用户？在进行用户访谈的时候就会目标明确，这也是项目干系人的来源之一。

访谈计划:格式举例

 

用户访谈计划（示例）

一、  访谈内容概述

1. 业务事件：涉税业务受理

2. 了解涉税业务受理的整个过程，用户的特点，输入、输出与处理要点，数据量等

3. 了解该业务事件的上游（纳税人）、处理者（窗口人员）、下游（涉税业务审核人员）的主要利益点。

二、访谈对象

1. 职位：涉税窗口工作人员

2. 姓名：            （访问时填写）

3. 联系方式：            （访问时填写）

4. 其他相关信息：

三、访谈计划问题

1. 基本情况

（1）每个窗口有多少工作人员，电脑配置如何？

（2）请简述一下你们的工作过程。（场景）

2. 用户环境

（1）你以前使用过什么系统？哪些系统你感觉比较易于使用，哪些感觉不好用？

（2）以前使用过的系统中，哪个提供的用户帮助比较有效？

3. 流程类问题

（1）你们的主要职责是什么？--处理哪些涉税业务，有哪些类型？

（2）你们处理完后，下一环节将传给谁，传递什么内容，以什么形式？

（3）如何确认是否受理？依据是什么？

（4）怎么判断是否能够“即办”，即办的处理方法是什么样的？

4. 数据类问题

（1）每种业务要提交什么材料？

（2）受理时将完成哪些表单？

5. 非功能性问题

（1）你一般一天要办理多少笔涉税业务受理？最多的时候是什么时候，会达到多少？

（2）现在你处理一笔业务需要多长时间，感觉主要费时在什么地方？

6. 其他问题

（1）现在工作中最大的困难是什么？

 

 

现场需求调研的方法技巧： 随时记录关键点，对业务流程尽量当场手绘出来，并向相关用户确认理解无误。对调研所得的第一手资料需要进行加工，明确功能需求，约束，及其他非功能需求，如系统反应时间等;不要忽视非功能需求，这可能对系统软硬件的整个架构产生影响，比如，这个软件的最终用户有多少？潜在用户有多少？并发量有多少？知道这些才考虑用什么样的系统架构来满足这种性能需求，是否要单独设计缓存模块？建议客户购买什么样的硬件设备等等。对功能性需求要能甄别出业务可能变化的地方，进而考虑系统实现时是否需要使用设计模式，或是设计成可配置的来应对这种变化。正式启动项目之前需要根据用例文档对应的功能checklist请客户签字作为合同附件，上线之后避免无休止的需求变更和客户对软件功能完整性的质疑，均需依赖于此checklist文档。

设计阶段：概要设计可以由项目经理或技术总监这种角色的人来做，
          但是详细设计，对于小一点的项目，可以让开发成员全员参与，对于比较大的项目可以将开发人员分成几个小组，每组里面选出一个组长，以小组分工的形式参与详细设计。每个人或每个组提交自己的设计成果，并且定期开会，在项目经理指导下相互之间对设计成果做检查和纠错，项目经理对设计上有争议的地方进行统一(对于几百人，上千人的超大项目这么做不适合)。比如，会议上可以重点对设计成果提出这么几个问题：1.设计文档是否严格遵循格式要求?2.设计是否具有功能上的完备性，即反映了所有的用例?3.对用户输入是否进行了有效校验?4.类及数据库设计是否合理?这样做的好处是，增加项目人员的参与感，帮助开发人员不但从全局上而且从细节上更好的理解需求，促进项目成员的经验交流，促进项目成员的成熟度，还有就是降低人员变动的风险；并且在制定开发阶段的WBS时，由设计成员及开发人员自身估算工作量及完成时间并提交给项目经理，这种自下而上的方式有更大的准确度。在对需求了解到一定程度时，比如一个模块已经基本确认，可以进行UI的设计，这个在和客户确认及细化需求时非常有帮助，也使用户对以后使用的软件界面有一个直观的了解，到正式开发时也可以大大缩短程序员前端开发的时间。

 

开发阶段：严格按照WBS的进度计划进行开发，每天下班需要checkin代码，保证每天代码库的代码都是可以运行的。根据MS-Project找到项目关键路径，予以重点关注。如果是多层架构的，在每层上配备一名人员(可以由经验丰富的程序员兼任)，每天负责review这个层面的代码，保证代码的规范统一，力求好像代码是同一个人写出来的。根据前期已经设计好的UI,开发阶段可以大大减少开发人员的工作量，开发人员只要套用就可以了。如果有可能，定期请客户过来观摩开发成果，对项目是一种督促，也能保证不出大的偏差。

 

测试及上线维护：开发人员日常开发中的单元测试必不可少，每天应该进行完当天开发完功能的单元测试，然后提交一个可运行的版本到代码服务器。为保证质量，集成测试一定要有专人来做，所有的测试都要严格依赖于用例文档所形成的测试用例。集成测试一定要针对一个稳定的版本来测，和开发人员提交代码的版本分开，不能一边对这个版本在测试，一边开发人员还在checkout，checkin同一个版本的代码。测试时最好使用一套缺陷管理系统，如bugzilla等。