一封给领导的MAIL

前些天在中关村图书大厦偶然买到了一本书《UML用例驱动的对象建模——范例教程》。也很偶然的仔细阅读了一下，居然发现这是一本我找了很久的书。
于是又买了它的前一版《UML用例驱动对象建模——一种实践方法》来阅读。
下面是我读了书之后给老板写的一封MAIL：
====================================
关于ICONIX开发过程与SparxEA开发系统的推荐

推荐ICONIX开发过程的理由：
1.XP过程：XP过程虽然一度比较时髦，但是经过研究，早已被我们所认定为是不实用的开发过程。
2.RUP过程：我们公司从来就没有真正的完全实施过RUP开发过程，主要原因如下：
－ UML的图例很多，也比较复杂，但是实际上最常用到的20%的图例可以覆盖80%的需求。
－ RUP的开发过程过于繁琐，对我公司这样规模的项目并不适用。例如多次迭代的方式很难真正的实施。实际上我们已经对RUP进行了适合我们自己特点的裁剪。
－ 文档格式过于复杂，例如标准的用例格式。实际上如果完全遵守将导致成本过高，而且也没有必要。实际上，我们已经确定了自己的用例格式。
－ 我们自己来讲，已经确认了用例图/顺序图/类图为UML设计的核心图形，但是RUP中并没有指导这三类图形是如何在设计过程中被贯穿发展并最终统一的。

当我看到ICONIX过程时，发现有很多关键点与我公司的开发过程是十分匹配的。
1.在开发过程中有明确的评审点。
2.只选用了UML图例中最常用的几种图例用来对系统进行分析。
3.才用了比较简化的开发流程与文档格式。例如用例的格式就与我们现在的格式十分类似。
4.明确了设计过程中由用例图到类图之间的顺序图的生成过程，过度比较平滑。
所以我推荐使用ICONIX开发过程，来将我们的开发过程优化并实施理论依据。

推荐SparxEA设计工具的理由：
1.我们一直在找可以统一需求分析与设计过程的平台，但是Rose & Requisite Pro过于庞大而不太适合我们的设计方法。
2.Rose/XDE设计工具过于庞大，而且不能完全满足设计文档需求。而且自动生成代码的功能我们在短时间内还使用不到。
3.需求和设计过程之后需要专门的生成文档的时间，繁琐且工作量大，COPY工作过多。而且也不利于文档的后期维护与更新。
4.对于设计过程，无法进行系统一级的版本控制，而只能进行文件方式的版本控制。

使用SparxEA我们的获益：
1.可以将CODING之前的所有过程放在统一的系统中进行管理，其中包括需求、设计、计划等等，甚至还包括了TEST CASE和维护记录。
2.可以进行系统一级的版本控制，可以支持基于SCC协议的版本控制软件，如VSS, STARTEAM等。另外可支持CVS。
3.可以自动的生成文档，可要节省大量的文档写作时间。
4.支持ICONIX开发过程与RUP/XP开发过程。
5.新版本对中文支持没有问题。
======================================

但是我现在正在犹豫是否将这封MAIL发给老板。
1.新的部门结构调整之后，我已不再负责开发部门的部门经理，现在成为了AMS部门的经理。所以这样的工作已经不是我的本值工作了。所以上报了这样的建议也无非是给自己找一些额外的工作来做。现在的本值工作能让老板满意已经不容易了。
2.老板现在的注意力并不在开发方法的改进上，而在于扩大生意机会上。所以这样的建议很难提起老板的兴趣。

另外，最近听说Motorola业务部门的Brain离职了之后，白晓梅接替了他的位置。嗯，白晓梅和Anna Zheng是我在Motorola接触的客户中正经很有工作能力的几个客户之一。思路、处理问题的方式、沟通方式都正经象老板的样子。