2007-7-1010:58:13losthold 考虑愿景时，如果有多个老大怎么办？比如我们做项目，涉及了政府和出租车企业，老大就有政府科技处的处长，我们公司的总经理，他们都具有决定性权利。而且有些愿景可能是不能摆到台面上的 
潘：要分出主次。只有一个老大，如果有多个老大，他们都不是，应该在他们之上找更高的老大。你可以这样想：如果某个需求，对公司总经理的目标有利，却损害政府（科技处处长可能官太小了？未必是老大）的目标，这个需求通过的概率有多大？ 
2007-7-1011:03:43losthold 事实上确实存在这样一个老大，也确实提出了愿景，不过相对于项目来讲，似乎范围太大了 
潘：具体说。你把你现在揣摩的愿景写出来我看看 
2007-7-1011:06:53losthold 最大的老大现在是交通部主任，他提出的愿景是GZ 市交通信息化，通过信息化工作实现他的政绩，对他来说，衡量标准就是建了多少个能看得见的，可以拿出来演示的系统，而我负责的是其中一个项目 
潘：好，那么现在讨论的是你这个项目的愿景，不是GZ 市交通信息化的愿景，是吧？ 
2007-7-1011:08:27losthold 对，所以我觉得这个老大离我太远。具体到项目来说，就会涉及到运政部门和公司高层，是出租车gps 项目。运政部门希望用这个系统来简化他们的工作，公司希望减少付出的成本，盈利是另外的事情 
潘：那么你就要去揣摩对于出租车GPS 这方面，运政部门的度量指标哪些？ 
2007-7-1011:12:42losthold 嗯，现在我就是觉得运政和公司是平级的，所以难以分出老大来 
潘：你先不要找老大，你先找度量指标，列出来运政和公司各自在乎哪一些？ 
简化他们的工作－－这是不合格的，另外，这和"通过信息化工作实现他的政绩，对他来说，衡量标准就是建了多少个能看得见的，可以拿出来演示的系统"也是有抵触的 
运政和公司各自都会有一些指标，很可能指标之间是有冲突的，希望在这些指标之间找到平衡点，你需要先把这些揣摩清楚。 
2007-7-1011:18:06losthold 我是这样想的，上面的领导想建这么几个系统，而下面的具体负责单位当然是要把这些系统建起来，但是为他们自己考虑，他们也希望这些系统能同时给他们带来好处，这个好处，目前来说有几个指标，车载终端装车的数量，故障率等等..另外还有投诉的单数、稽查处理时间等
潘：但这些好处要花时间花钱的，而且很可能会损害他们自己的利益，你要做的事情就是找到中间的平衡是什么
2007-7-1011:24:08losthold 另外，因为有些愿景可能是不能摆到台面说的，但是又需要列出来，至少在项目团队内部取得共识，所以我把愿景分成了两部分，对外和对内的，这样您看合适吗？ 
潘：这是迭代的，你不分析怎么知道谁是老大？就像家里谁做主一样，你不看看细节，就知道老公老婆是不行的 
另外，因为有些愿景可能是不能摆到台面说的，但是又需要列出来，至少在项目团队内部取得共识，所以我把愿景分成了两部分，对外和对内的，这样您看合适吗？－－可以，大家要知道对内的才是真正的愿景 
2007-7-1011:29:30losthold 嗯，那我明白了 
2007-7-1017:25:44losthold 潘老师，您好，我这里还有个问题想请教一下，课上讲到在定义类的时候，一般从用例的步骤中寻找，但是如果系统中某些部分是用例没有覆盖到的，应该怎么办？例如，在我们的系统中，有用例车辆定位，定位的数据来由车载终端定时上传，并保存在服务器内存和数据库中，车辆定位只是从服务器内存或数据库中查找数据，因为后面这些实现部分都是我们设计的，用户也并不关心我们如何实现，他们只要能够定位，那么对于这些服务端的应用，需不需要画用例图，写用例文档？ 
2007-7-10 17:29:30 losthold 或者我这样描述，用户要的是在电子地图上对车辆进行定位，为了实现这个目的，我们在车上安装了车载终端，车载终端定时上传定位信息，这些定位信息保存在服务器内存和数据库，用户请求定位时，我们从服务器内存或数据库读取数据 
潘：类要从需求来是肯定的。不一定是从步骤找，还有字段列表、业务规则 
定位信息－－包括什么？ 
用户请求定位－－请求里包括哪些信息？ 
返回给用户什么信息？ 
这些就是类的来源 
2007-7-1017:31:00losthold 现在我从用户那里，其实只能得到车辆定位的用例，但是对于车载终端定时上传定
位信息，通信服务器接收这些信息，通信服务器保存这些信息等等这些应用，都是我们想出来的