再出色的女人，如果身边空空，就使人觉得凄凉。比如张爱玲，她的感情生活就像李碧华所说，是一口古井，任由后人来淘出的都是一地清冷月光。
夫唱妇随，才能交相辉映，。
  同样再出色的人（这次不分男女了哈），如果孤军奋战的话，也会使人觉得凄凉。不过我们就不一样了，我们是一个小家庭，不论是感情生活还是技术
生活都是一片汪洋，随你怎么淘，淘出的都是金色的阳光。
  呵呵，漂起来了。。。。。。
  提交作品了，心里的石头也放下了一块，回头看看这一个多月的时间，真的是成长了许多，无论是技术上的，还是团队合作和管理上的。技术上，
虽然写的文章总被人批评，不过至少有人对我的文章有兴趣，也算是另一种安慰啦。团队合作上，平时不觉得，真到了在一起做项目的时候，才发现每个人都和以前
不太一样啊。也是通过这次大赛，让我发现了每个人的另一面。团队管理上，呵呵，说来惭愧啊，没为大家做什么事，而且虽然只有3个人，不过这个队伍也不好带啊。虽然有争执，虽然有困难，可是我们还是坚持下来了，不是吗？
  怎么说呢，在这段日子里，虽然有一些事让我生气，但是，也有很多事情令我感动。是大家的坚持，我们才会走到今天，才会完成作品。
  所以，无论我是要哭泣着，还是微笑着与你道别
  人生本就是一场难分悲喜的演出，
  而当灯光照过来，
  我就要必须唱出那最最艰难的一幕，
  曲终人散后，
  无论我是要哭泣着，
  还是微笑着与你们道别，
  我都会庆幸曾与你们同台。

搞笑啊，因为每次都是默认的用户名，结果，前几天把用户名给忘了，怎么也上不来了，把我急的啊~~~
看着那么多批评我文章的话，我有话没地方说，更急~~~~
结果牙也肿了，眼睛还长东西，~~~~~~
现在好啦，事基本都忙得差不多啦，晚上提交附件，而且也把用户名给想起来啦，上来喊两声，嘿嘿，兄弟们，我又回来啦

共同工作：
查找相关资料
分析题目
讨论需求
业务流程分析
技术学习
个人分工
姓名 工作 备注
dubb CRM相关资料及接口分析
1.  
crazycy  
liuli 1.ERP 
1.2.2 整体分工：
姓名 工作 备注
dubb 协调工作
会议的组织
进度的安排
相关技术的学习 会议的纪要由每个人轮流整理
每次会议有一个主要的发言人
crazycy 相关团队消息的跟踪
相关网站的跟踪
相关技术的学习 相关技术的学习，liuli相对来说多一些
liuli 相关工具的掌握
相关会议的跟踪
相关技术的学习 
1.2.3 文档设计阶段
时间 任务 负责人 备注
2006.6.10至2006.6.18 业务模型的分析设计 liuli 这是个迭代的过程，与服务建模交互
2006.6.13至2006.6.20 服务模型分析设计 dubb ,liuli帮助修改了文档
2006.6.18至2006.6.23 系统架构设计 liuli，crazycy 用例模型分析和数据模型分析由liuli完成
2006.6.23至2006.6.27 组件设计 crazycy 以上过程均是迭代的过程
2006.6.23 项目综述 dubb 
2006.6.25 设计实施计划 dubb 
2006.6.27至
2006.6.28 整体文档的检查 全体成员 每个文档都是经过了数次迭代与修改，在所有文档完成后，大家由一起将所有的文档进行了检查，包括：
格式，内容，标点符号，图形等。
SOA相关资料查找分析
TurboCRM分析完毕
用友ERP分析完毕
题目要求的业务流程分析完毕
需求分析完毕
业务流程图分析讨论完毕
需要工具安装完毕
业务建模完毕   听说周六有IBM的技术讲座，哪能错过，赶紧注册。。。。 
  周六早上起了个大早，和liuli一起到体育馆门口等IBM的车，到了体育馆才发现，已经有n多xdjm在等了。看来同志们对soa还是很感兴趣的啊。不过，让人ft的是等了好久都不见车来，已经9点钟了，人群开始散去，这时候，我和liuli立刻做出了一个决定，不能再等了，自己做车去。于是我们俩跑到了知春路去做公交车。
   好不容易到了，会议已经开始40多分钟了，门口的IBM工作人员问了我们班车的情况，我们宣泄了一下不满，因为有好多人因为车没来就放弃参加了，如果不是之前IBM发信说有班车来接的话，然后早上等了一个多小时车没来，他们肯定会来的。
  听了一天，就IBM的产品来说总体感觉就是比较人性化，我指的是提供了图形界面的工具已经自动的代码生成工具。因为，在下午有个环节是拿微软和IBM比较，比较的内容是将已有的功能包装成服务并发布，两位博士一个负责用IBM的产品，另一个用的是微软的产品，同时进行。在大屏幕上可以清晰的看见IBM的执行过程全部是图形界面，其间并没有涉及到具体的代码；而微软的产品并没有图形界面，所有的操作看来就是一个程序员在写程序一样，结果可想而之，速度当然比不上IBM而且其复杂程度也对程序员有很高的要求，即必须知道底层代码及所有的环节才行。
  不过，我在想，如果微软也把同一套流程做成了图形界面，同时添加了代码自动生成的功能，那么那时候，两者再比较，结果会是什么样呢？
  ps：liuli在用WBI的时候，发现了不少的bug。

  经过以前的数次讨论，方案终于定了下来，在接下来的日子里，每个人负责不同的部分，开始进入各种文档的实现阶段。
  我负责写总体的需求文档，虽然以前写过类似的什么需求分析啊，概要设计啊，相信设计等等，但是，这次的需求文档还是花了我很多的心思。
在写之前特别又看了一遍《需求分析黄金法则》那20条，写了一个晚上，一气呵成，不过不知道是因为文笔退步还是别的原因，写出的文档，大家不是很满意，
咳，严重郁闷中。
        ·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

        ·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

        ·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

        ·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
这几项都有包括啊，回头问问差在哪里了。
  虽然大赛并没有要求提供需求分析文档，但是需求在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用，所以，就像软件工程的流程一样，一切从需求开始，一切文档化。
         接着修改。。。。。。。

评价成熟度后，建设SOA模型的2个方法学：
1.CBM业务组件建模，从企业整体，metrics结构
2.业务（组件）划分，核心价值链，组件如何对不同组件，不同业务目标进行划分
三.服务缄默，架构企业价值链业务流程------〉服务模型
1.服务发现（找到可能成为服务的几个候选者），包括三个方法：
  （1）顶级流程分解（粗粒度）
  （2）业务目标的建模（目标-----〉服务）
  （3）分析现有系统，划分，类比 （接口，形式。。。）
以上可以引出服务目录的概念。
服务目录：就是潜在的服务的集合
2.服务的规约
  从服务目录入手，分解属性，跟现有哪些业务关连在一起，决定哪些成为服务-----〉模型，书面specification
3.服务的实现决策
  哪些需要包装，哪些需要新方法
  与传统架构结合（用例等）
4.如何从服务模型映射到参考架构
  要与企业架构隔离开
  业务功能-----〉服务
  服务中介-----〉ESB
  非功能------〉服务监管
  可参考流程引擎
5.*服务监管
SOA灵活性{
          服务模型
          复杂性-----〉ESB
          }
监管方法：{
           服务模型
           参考架构
          }
方法学：{
         角色
         职责
         }
柔性架构快速适应变化
服务注册库------企业IT的生命周期管理