参加IBM Rational高峰论坛的会议笔记

1.      制定项目开发流程（项目开发的第一步）

  1.1. 为什么制定项目开发流程？

       在我们印象中，每个公司的开发流程不经一致，其次在每个公司的内部，一个稳定的开发团队，其开发流程是也不是一致。

        我们碰到的每个项目，都有不同的开发背景，如行业背景，业务特点，公司的技术知识积累等。这些不同的开发背景导致了，我们的开发团队在实施每个项目将采取其不同的开发流程。

          所有在每个项目启动时，我们的第一步就是确定这个项目的开发流程。对于一个企业中的开发团队来讲，可以参考企业知识中已经的项目开发流程，还可以接受新的开发思想，创建并按照新的开发流程进行实施。

1.2. 项目流程的内容

          项目流程中组要组成部分 角色 ，开发规范 ，流程节点，可配置项。项目流程则是这四项有机的组成，每个流程阶段，什么角色按照固定的开发规范做特定的事情，并反馈可配置项。

         说道这里，好多人还是不太理解，其实在好多企业中呢，这样的项目流程管理就是一个大的文件夹中，包含了好几个阶段的子文件夹，在每个子文件夹中还包含了很多这个阶段的项目文档。

 

        这样的话好多人就会想，这样的规范可以制定出来，是否可以在开发的过程对项目开发流程中每个阶段的开发，用一种强制手段，来按照开发规范来限制，目前Rational Method Composer 还是不能做到这样，但IBM的人员说将来会支持。

1.3.           项目流程管理

        在具体项目执行的情况时，我们需要对项目流程的各个阶段进行实时的统计和分析，分析的内容包括各个阶段执行的时间，有效性，连续性。找出流程的坏点，进行改进，调整和提高。

2.      企业框架到项目框架（项目开发的第二步）

2.1. 为什么有企业框架？

         在说企业框架前，我先声明，在我的字典里面没有这样的字典。其次好多PPT信息来不及记录，我就把我能理解的内容和大家共同分享。

   在谈什么是企业框架之前，我们先说一下，在为好多企业客户开发系统时，碰到好多问题。比如

•      一套企业人事信息包含在好多系统中。
•     企业中包含了好多老系统，现在大部分的功能已经抛弃不再使用，仅仅是使用其中某个特定的功能。
•   在一个企业内好多同样的功能IT基础环境。比如说数据库有Oracle，SQL server 等等，资源的浪费。
•   企业中业务系统的IT技术不统一，且接口定义不能吻合。等等。

         这样，大家在实施的时候，往往感觉到很乱，关系很复杂，给项目实施带来原大可不必的负责度，这样的多余的负责度，带来是企业的IT成本上升。

 

          企业框架就是将企业IT的元素进行一定管控。这里的IT元素包含了企业的各个业务系统，企业的基础IT环境，硬件设备。这样的话，企业的业务项目的开发就是不是那么的无序，且尽量的避免那种不必要的浪费。

          就像一个企业的开发管理水平分三种档次，

          第一种 张三，你把什么事情干了，怎么干 你，你自己决定。

          第二种 张三，你把什么事情干了，但你必须按照一定的原则去做，具体的怎么做，你可以自己决定。

         第三中 张三，你吧什么事情干了，具体的怎么做，一步一步的，我来告诉你。

2.2. 企业框架考虑什么内容？

   在IBM研究所 对企业框架的定义 ：规程定义和维护体系结构模型、治理和过渡活动，以帮助有效协调半自主团队来实现共同业务和/或 IT 目标。”

                           

                   IBM定义的EA的体系结构图

 

                   

         EA的治理流程图

                   

                  

        EA框架图

 

2.3. 项目框架和企业框架的结合。

       在具体设计项目框架时，怎么和企业框架结合呢。

      分这么几个部分

• 在设计项目框架时，考虑企业IT框架，具体的来讲，有了Oracle数据库 就不要加上SQL server 数据库，运行的系统环境。
• 考虑企业中的业务框架，举例：在企业的业务系统中已经包含了一套人事信息接口，在具体项目设计框架时，对于人事信息这个部分，直接引用这样的接口。
• 符合公司的发展和战略。

 

3.      模式驱动开发

       在模式驱动开发模式，相信大家也很熟悉了，数据库建模，业务设计时，建UML对象图，时序图，状态图等。

        数据库建模 问题还不是太大，在业务建模时，业务模型和实际的编码不能相互转化，这样会导致这样的问题，在项目的一开始，模型图和实际的编码还是一致的，但随着项目的逐步的展开，模型和实际编码就开始不一致了，原因也是有道理的，在项目开发的中后期，业务内容发生变更后，不太愿意在花时间保证业务模型与实际代码之间的同步。

        在Rational 中，解决了建模和实际代码之间相互转化的问题，在Rational的概念中建模和实际代码是观察同一个问题的不同的角度。

4.      项目的质量管理

         项目的质量管理直接是联想到软件测试，在讲的过程中说明了软件测试格式划分，在这边也就不一一细说了，相信大家也相当熟悉了。

这边我就直接转述两个质量管理的观点。

4.1. 测试在各个阶段的成本的划分。

      在测试的四个阶段，单元测试 ，业务组件模块测试，集成测试，部署安装测试。

       对于同一个Bug的修改费用是成几何倍数增长。

       在单元测试一个Bug是几个美金，而在最后一个阶段修改同一个bug他的成本可以到上万美金，所有在单元测试阶段消灭Bug成本是最低廉的。

 

4.2. 好的软件是设计出来的，而不是测出来的。