软件生命周期管理研讨会有感

主办方：省软件协会

地点：武汉光谷软件园C6栋1楼报告大厅

与会者：多数为武汉软件公司，宜昌除我公司外未见公司参加

会议时间：2011-12-8 14：00 – 17：00

讲师：微软中国 开发工具技术服务部 

 

研讨命题

1、 如何使用VisualStudio2010来管理软件开发的生命周期

2、 如何运用VisualStudio2010来实现各种项目管理方法论

3、 云计算下如何使用VisualStudio实现项目服务及测试、计算托管

 

感想

1、本企业如何应用

微软的软件开发产品架构完善，且有很多实际利用这套工具的开发案例。但相应的，要熟练运用这套工具不仅需要熟练的开发人员，项目经理、配置管理人员、文档管理、测试人员的素质都要跟上，而且按微软的工具应用教程，如果完全应用到公司的某些开发项目上（譬如XX人力资源或是传真项目），所要使用的人员起码还要再加一倍，而且必须是素质相对比较高的人员。而且，微软的案例也大多是高端软件企业，譬如上海石化盈科等等

由此，我感觉微软的这套产品无疑是完善的，但要使用到中小型开发企业和需求多变的项目中还需要根据实际情况加以裁剪和应用。具体如何裁剪，需通过以下几个生命周期来予以考虑：

1） 立项

在这套开发工具中，立项这个环节可以通过与TFS集成的SharePoint来完成立项相关文档的发布和版本管理。而且完全可以公司的制度建立相应的文档发布模板。

好处：可以根据生命周期模型建立相对固定的立项时的流程和文档

难点：

Ø 立项的文档及相关模板是在不断改进的，作为公司来讲进度、质量的压力很大，这部分工作很难及时定期改进，目前公司的《项目章程》的版本已经有近一年半没有改进了。

Ø 要有相应的架构师研究TFS的模板功能，这个需要理解项目管理的人员和一定的开发能力

2） 需求分析

（1）原型工具

微软对需求分析这块倒没有什么出彩的工具，个人感觉我们公司现在使用的原型工具Axure还是很先进的，在目前实践过程中的问题是：部分客户理解不了Axure生成的原型（原因很多：想象力低、接触B/S项目少等，譬如B项目），而且原型的保真度有高有低，遇到低保真度的原型时，可能开发出来的迭代版本与客户根据原型想象的版本之间还有差距。但高保真的原型（譬如A项目）是相当耗费成本的，不是高额项目根本承担不了这一成本。但低保真原型是目前短周期、低投入项目唯一适应性较高的做法，至于理解差距只有通过版本的加快发布来弥补。个人感觉，项目型的软件开发在需求分析上是最难的，因为客户的素质参差不齐，譬如某厂的车间系统，客户方使用负责人XX可以说每个版本的发布都参与了，发布的时候也通过了他的认可，但实际应用时，又提出车间员工操作不方便，提出了改进需求，通常这些改进就要耽误其它项目的开发进度，而且员工一般不愿意维护老项目，一方面是精力不够，另一方面老项目的确是个费力不讨好的工作。

（2）需求分析文档的弃舍

对需求分析说明书（文档）目前团队内有两种倾向，一种是觉得不必写文字的需求分析说明书，晦涉难懂，直接用原型表达即可。且有的客户根本不看这个（譬如XX集团）；另外一种倾向是测试部门需要需求分析文档，但应该说测试部门需要的需求分析主要是围绕项目中各模块的测试要求（譬如压力指标、输入输出范围、客户描述等）。

因此，目前各个项目除非客户特别要求，基本停止了需求分析说明书的编写，而改为原型说明，部分要求高的项目还加上了业务流程图的说明。而对测试这边，加入了数据字典，对测试用例加强了输入输出范围的要求，在测试计划中补充客户描述和测试背景等资料。

3） 系统架构

Visual Studio本身是有一套UML建模工具，但在本公司的实践中这个工具是没有用到的，一方面是在项目建制上架构师资源是很缺乏的，根本没有相应的架构人员来专职负责架构，另外一个问题是，需求一直在变化，架构的改变也会变得频繁，偶尔的变动就会导致架构的部分重构，架构人员在进度压力下，就无法及时更新架构模型，只能以完成兼任的开发任务为优先，改动的架构就以口头沟通也能达到相应效果。而且公司目前也有比较成熟的三层架构模型，基本所有开发人员都能理解和明白这个架构，因此，建模架构在目前看来并不是特别的需要。除非有相当大的项目，拆分为2个或以上的项目小组并行开发，或者采用较新的架构模型，我觉得才有必要配置专职的架构师人员维护各个版本的架构模型。

从公司明年的规划看，架构也会由XX的小组来专职负责审校和推出标准架构，这样一方面规范了一套可积累的基础架构，也避免了架构师必须对各个项目需求深入了解的时间不足的问题。

4） 代码实现

这一环节，是工作量最大的，其实也是细节最多的。微软在这方面做了很多人性化的改进，对开发者来说，确实方便了很多的。更重要的，这套工具将代码实现与项目管理进行了有机的结合，譬如说任务管理、进度跟踪、代码出入库等，但还是前面那句话，大公司有大公司的用法，小公司有小公司的用法，目前我们的实际中，任务管理和进度跟踪基本上还是利用Excel来完成的，实际过程中，利用的最好的还是代码的出入库管理，也就是说只用到了基本功能。这并不是我们不会用，而是要实现上述所说的任务管理、进度跟踪、需求变更等需要比较专职的项目经理，或者专业的配置管理员，目前看来，用Excel来管理进度和任务，用word来管理需求变更也足够了，将这些嵌入到Visual Studio中诚然更好，但只有相应的主动使用的情况才会有效，否则就流于形式。另一方面，将任务、进度、变更集成到Visual Studio中去管理，其实也是对比较上规模的开发企业有效，因为可以根据各个项目分析各种项目指标，目前对我们来说还没有必要，一方面项目组成员经常变化，比较缺乏说服力基础；另一方面，项目经理身兼数职，难以做到专业化。

5） 测试环节

个人觉得Visual Studio的测试是最好的一个模块。很多先进的测试概念（单元测试、测试驱动、自动化测试、测试用例、版本发布管理、自动化构建）等都有体现，但具体应用时，感觉测试部门基本能掌握这些工具，但在使用时明显感觉精力不足，基本上这些测试工具还停留在未使用的状态。

单元测试因为需要一对一的写代码，这需要大量的时间与一对一的专职测试，目前测试人员的代码和时间都比较欠缺。

测试驱动也比较耽误进度，这与测试人员关系不大

自动化测试是我极力想推进的，但测试部门使用的过程中反映因为需求变化较快，界面和功能变化后，当测试任务较多时，自动化测试很难及时更进维护。但我还是想在合适的项目中试行一下自动化测试。

版本发布管理目前是手工操作的，目前问题主要是内部的版本发布较频繁，基本上是在测试人员电脑上即时生成，并没在相应的测试环境上发布，只是在发布到客户环境上发布到测试环境上。目前看来还是能满足要求的，可以维持现状不变。

自动化构建目前是需要推广的，但要重新搭建一个新的TFS服务器场，目前需要重新研究一下TFS中自动构建的多服务器构建再行推广，因为项目较多，不同项目的构建环境不同。今天会场上也咨询了微软许Sir，应该是可行的。

6） 实施

实施的问题，主要是现场与后方的沟通误差的问题，这个主要靠项目经理的经验弥补，另外客户在现场施加的压力也是很大的，容易造成过程管理的失控。除非是系统上线期间，一般建议不要在现场开发。

7） 维护

维护的成本越来越大，项目的差异性越大，带来的维护成本与维护问题也越来越多。目前组建专职的维护部门是不可能的，只能靠完善的代码和项目文档资料来弥补。

其它

      个人感觉，湖北的软件公司对新技术的热情并不高，很多使用Visual Studio开发的公司连Hyper-V都未听说过，对各种VS的先进工具在会场上也有较多人提问，而且所问的问题基本上我都可以回答，在项目管理上也未见有精彩提问，也许感觉比较偏颇，但确实感觉在场提问的公司在项目管理和新知识的掌握程度上与沿海差距较远，可能其它未提问的公司有能力较出众的也不一定。

 

         以上为本次会议本人的一些感想，希望能引导大家积极思考，起到抛砖引玉的作用。