再抛一砖：我的建模过程观
　

---

我的建模过程观

找到用例

用例=有价值的事件流
事件流分析
注意那些属于系统的边界以内，或者说与系统相关的内容
对重要细节和支流的遗漏可能是致命的
易见的错误
将事件当作用例
不明白用例的价值
与系统无关的事件
比如在库存管理中
入库检验与系统相关的东西只有
不合格品纪录
至于如何检验等都为系统边界以外的事，不要干扰思维

用例分析
用例分析：对实现这个用例的事件流进行分析
完成每个事件都要有那些动作。这些动作由谁发出，完成动作所需要的信息，信息由哪些对象持有
特别注意外部交互的边界和外部事件

概念类图（点）
信息
职责
关联
协作

使用分析模式改进

动态模型分析
活动图
将模型中的流程用活动进行分割（线）
交互图
用户可能的交互过程（用户指定了一项任务）（面）
模型对象如何配合满足用户的交互要求（协作图）。
对完成任务做出的计划安排(序列图）
必要的状态机

分析阶段完成

设计

对类图进行扩充改进

抽象（利用设计模式进行改进）

加入系统支撑部分

对动态图进行扩充改进

加进系统实现要求的部分
抽象（利用设计模式进行改进）
设计阶段完成

建模完成

用UML建模方法为UML建模过程本身建一个完整的模型。
这意味着结果可以用来指导开发一个类似ROSE的工具。
不知道在ROSE的开发过程成中有没有做这件工作，如果没有，正好我们可以开发一个比ROSE更强的东东或更适合我们自己的东东，我们可以就用ROSE来做，这可是做ROSE的人当初所没有的、他们为我们现在提供的、用来超过他们的有利条件啊，呵呵。
怎么样？要不要开个开设（开放设计）项目？
那位哥们出来张罗一下？

目标能否实现再说，至少大家能有所收获，既实战了建模过程，又研究了建模过程，多好啊。

 回复: 支持，欢迎更多高手加入
　

---

同意
能够支持建模过程的工具很好啊。
建模和编程为软件开发两项基本活动，对编程的支持工具很多了，建模则少的多
整个商业运作模式可以参考Poseidon 与argouml
一个开源社区的支持和一个开源版本
在此基础上的一个商业版本，或者靠基于工具的培训盈利
在那里找个Internet协作平台
sf.net还是三库四平台
我愿进自己的力量

　

 回复: 不妨继续一下我未做完的一个题目
　

---

我觉得所建的模实际上是建立可计算模型
不同人对可计算的理解层次不同，建模的细致程度也不同，如果认为模型可计算了，就可以编程了。
这几天对您离散化的加深理解，在分析阶段主要的手段为离散化
信息离散为数据
流程离散为对象动作
而设计过程更强调抽象，以为如何
好像片面了，是否也有些道理


　

我主要是用信号处理里面的A/D和D/A转换来映射类比分析和设计两个过程。
发现是行得通的。
也就是
离散化/抽象对应分析；
拟合/实现模型对应设计；
制造模型对应编码。

初学者，程序员，分析设计员，高手，大师
我们可以组成多个核心用户组。
我们可以从业务模型一直讨论到系统的分析模型，剩下的工作由有心者派生不同的设计模型和实现模型。

 回复: 我们需要对建模感兴趣的不同层层次的人士加入
　

---

我一直在做全程建模方面的实践，今年年底我的一本书将在电子工业出版社出版，书名是《软件工程之全程建模实现》。
希望能够和大家多多交流。

能否多点解释，这个课题要注重于什么，CASE软件设计，象rose? 过程标准化,象rup? 面向的市场是什么?

两则消息，
http://www.ccw.com.cn/erp/htm2003/20031008_1301V.asp
http://www.ccw.com.cn/applic/news/htm2003/20031013_13TKN.asp

企业应用软件的重新设计，机会?

学习和提高必须要有目标，我提议：目标可以定位为开发一个比ROSE更适应我们自己的建模工具。当然，这个工具可能已经有了或正在开发中，只是我们还不知道。这不影响我们的目的，最多影响我们的目标。

听北航的老师说，北航在建模工具上也造诣很深，已经编写出一个企业级的建模工具了，好像叫做SCPM吧。。。。
北航也有自己的UML的开发工具，好像叫做UML Bulider。。。

但是都不对外卖的。

 回复: 中国的大学很失望，正事干的少
　

---

我对中国的大学很失望，正事干的少。
工具的好坏关键在于能否支持工作，emacs的伟大在于什么
估计卖不出去吧

 建议，关注一些国外的进展
　

---

omg(www.omg.org)一直在做这方面的工作。
其MOF就是meta-model的标准，最新版的uml2.0也是用mof给出的。
这些都是给他的mda作基础的。http://www.omg.org/mda/
可惜网上的信息实在是太少，我看了mda explained，书里面说的东西比网站上多多了。
另外，还有一个executable uml也是有人在搞的，这个也是一个方向，都是在mda下面的。Stephen J. Mellor这个人比较倡导这个方向。他的书的网站：http://www.executableumlbook.com/，他的公司的网站:http://www.projtech.com/。已经有产品了。
eclipse里面有一个gmt项目组，在做mda相关的尝试，才开始，不过还用到了software product lines。http://www.eclipse.org/

个人意见，如果做工具，建议在eclipse基础上作，他确实是一个很好的开发工具平台。
这些是我最近关注的东西，希望大家能把眼光放宽广一些。
对了，cmu上的software product lines也很好的，去看看人家都干了些啥，呵呵http://www.sei.cmu.edu/
最近oopsla2003也要开了，看看人家都讨论些啥问题http://www.oopsla.org/
国内能找到的资料实在是太少了，sigh

老哥水平令小弟高山仰止，有几个问题请老兄指点：
1.在找到用例之前应该作些什么？
2.用例应该有谁来发现？
3.怎么发现用例？
4.用例的实质是什么？
5.怎么评审用例是否已经完整？
6.如何度量用例分析？
7.项目计划书完成之后，和设计相关的第一个动作是找到用例吗？

学习的心得，我不是高手，关键为引玉
我的认识
A1用例为一种需求分析技术，不能代替需求调查，而是对需求调查文本的分析结果，在此之前应该确认系统边界

A2国内情况，分析员发现，用户确认
A3发现用例的思考过程：
对着需求调查的文本去想，哪些为系统的角色（边界外），这些角色希望系统为他做什么
如果正确掌握了用例的概念，应该可以做出来。有一定的主观性，关键涵盖了用户的需求，不要遗漏
A4一个得到目标的过程
A5最好让用户参与讨论
6 ,7不太理解

国内的研究者不知都做些什么，反正我们这些实践的人得到甚少
可能他们研究的更加高深。不过希望面对中国的现实，把中国软件工业水平
搞上去才是根本
如果有研究者说的更明白，我也没必要这里现眼了，阿，哈、哈



　

 回复: 对国内研究者的期望
　

---

明白了，你以一个实践者身份看待自己。
那么问题就出现了，实践者实践的内容往往是产品化的。
产品化的东西的背后往往有理论基础的。
而对于这些产品的厂商来说，并不会教育实践者，它的基础是什么。
对于软件开发的实践者来说，那个背后指导工作的理论是无比重要的。
因此，作为实践者，应该自觉地去思考那些理论。

在软件开发领域，这些理论无非是出自于美国高校研究所大厂商的专家们（其他国家也会有，但比例偏低），而我国的现状就是跟着人家的屁股后面学，还学得都是旧的。

作为实践来说，这些产品其实并不是重要的，他们只是辅助手段而已，更重要的是那些理论基础了。

所以，我建议大家只要在软件开发领域混的，就应该去了解一下国外的最先进的理论。
下一步就是，知道人家的理论之后，还要想想人家的理论是怎么得出来的。理论背后有一些什么思想。

最后举一个例子，model，国内翻译作模型，是一个名词，这个概念是怎么来的呢？思考从现实社会到计算机内的可计算的0/1的映射关系，他们被分为了不同的抽象层次。最开始拨开关，然后是打纸带，后来是汇编语言，在后来是高级语言，在后来是面向对象，在后来是组件，然后想到要用可视化的模型来成为一个抽象层次。然后还有平台无关的模型，商业模型，平台相关的模型等问题了。每一个层次为什么要做这样的抽象？他们都隐藏了什么样的信息？这个时候再去想模型应该是什么样的？应该做什么样的工作？就比较清晰了，然后再指导实践就会变得游刃有余了。

By the way,不要把研究人员想的过于神化，其实他们和工业界也是密不可分的。尤其是软件领域。

 回复: 同意要关注理论，，但理论研究者和实践者还是应区分的
　

---

同意您说的要关注理论，但理论研究者和实践者还是应区分的，一个人精力终究有限，近来因特殊原因，才有时间考虑一些理论层面的问题，我有老婆孩子，老考虑理论没人给钱。国内理论研究者应该为实践者服务，但现在严重脱节了，我说的就是这个问题
看的出您对理论层面关注较多，希望在这方面多提具体的指导


　

老哥的确深刻，小弟佩服！

我认为用例和用例图是建立对C需求的理解上的（当然按照CMM或者XP可能有所不同），用例和用例图是对D需求的体现。所以问题就出来了：“需求从来没有变化，变化的是我们对需求的理解”，从C需求到D需求的转化不造成后续的灾难应该如何评估和审核需求？CMM没有讲，XP也回避这个问题。在Process中，每一个step的演进都需要审核和评估，这个时候请用户进入评估恐不太合适吧？

 回复: 用例，我的观点
　

---

对用例而言，我认为有一下观点就够了
1、从用户出发看待系统，主要和结构功能分解法相对
2、一个用例的语义由其事件流决定，而不是名字，因此用例的名字上也无需纠缠过多
3、用例图主要为找出可复用的事件流和角色关系，建立分层简化逻辑复杂性
4、不一定要一步到位，但要保证已定义的用例为逻辑无歧义的

　

你提供的信息很重要，我会仔细研究。
God2000说的也反映了一些实际情况。
国外先进理论和国内实践的距离在不断的拉大。
我们要把有限的力气投入到适当的层次，才能有所值。

基本上，我把事情这样分：

我们在做的事情。
我们能做到的事情；
我们想做的事情；
我们知道的事情；

这些事情应该形成一个金字塔。
你提供的信息能够加强这个金字塔的基础。
你可以看到，在正确地做事之前，有三个层次的工作是选择做正确的事。
我把这个金字塔模型称为“做事的模型”。

如果你是正在做课题的硕士或博士，将是我们特别欢迎的伙伴。
请多多参与，多多指导。

以上问题的步骤如果改变一下顺序来回答，理解起来就连惯了。
4.用例的实质是什么？
2.用例应该有谁来发现？
1.在找到用例之前应该作些什么？
7.项目计划书完成之后，和设计相关的第一个动作是找到用例吗？
3.怎么发现用例？
6.如何度量用例分析？
5.怎么评审用例是否已经完整？

用例的实质？
用例的实质是一个系统的内部和外部边界上的接口。
一个系统和外界进行信息交换的出入口。
就好比一座大厦的门窗。
理解这一点的关键不是信息交换的过程，而是信息交换的价值。
每个接口总是为某类人士开设的，每类人士总是希望找到自己最需要的接口。
接口的外面是客户，接口的里面是系统。
现在供应链管理不是讲求客户驱动的“拉式”供应链吗？
用例在本质上体现了“客户是上帝”的价值观，以前的价值观是“系统是上帝”。
如果这个“系统”是一个组织，那么，要找的就是“业务用例”（RUP）。
如果这个“系统”是一个软件，那么，要找的就是“用例”（RUP）。

用例应该由谁来发现？
如果你已经清楚理解了上面问题的回答，相信这个问题的答案是很好理解的：
当然是系统的开发者和系统的客户一起来发现的。
问题在于大家是否意识到客户参与用例开发的重要性和必要性？
如果我问：谁来发现一个饮食店应该制作什么样的早点？
如果答案是：应该根据附近居民的喜好和饮食店老板的手艺来决定。应该不会引起奇怪。发现饮食店用例的最直接的参与者莫过于居民和饮食店老板了。
然而，事实上每个开饮食店的老板最先想到的是自己拿手的手艺是什么，于是出现“试业/倒闭”的现象就比较严重。
这也没办法，住户喜欢吃什么早点？有时候住户自己也没个准认，于是需要专家来协助分析。住户的年龄结构怎样？职业怎样？老家什么地方？等等，要收集一些关于住户的信息，然后经过分析才会发现，什么早点才会受欢迎。
所以发现用例的角色多了一个：分析师。
如果这个“系统”是一个组织，那么，分析师就是“业务分析员”（RUP）。
如果这个“系统”是一个软件，那么，要找的就是“系统分析员”（RUP）。

在找用例之前应该做些什么？
不同的角色应该做不同的准备工作。
比如：在想新开饮食店应该提供哪些餐饮服务之前，应该想些什么？
我觉得这个问题不需要我展开说明了，留一点空间给您思考吧。

项目计划书完成之后，和设计相关的第一个动作是找到用例吗？
我还是转换一下问题，留给您思考：
在你完成“开一个餐饮店的创业计划书”之后，和设计一个餐饮店相关的第一个动作是找餐饮店的服务项目吗？
如果你觉得转换的问题有些问题，那原来的问题也就有些问题。
关键是怎么理解您的这个“设计”和“找”。

怎么发现用例？
如果您头脑里始终想着：“一定要提供有价值的服务”这句话，您无论从以下任何一个地方开始都会到达同一个目的地：
1.有什么样的客户？他(我)们是什么样的？他（我）们可能会有什么需求？真有吗？用“（我）”表示请来的客户代表应该这样思考。
2.服务者有什么样的本事？擅长提供哪些服务？
3.有人正在提供什么服务？这些服务的发展趋势怎样？
用例模型就是发现“谁需要什么可行的服务”的模型。以上的“谁”，“什么”和“可行（否）”，都是很好的思考起点，终点是得到整个问题的答案。

如何度量用例分析？
要看度量的目的是什么，
改进用例分析方法和过程？
保证用例分析的质量？
最基本的度量莫过于，花了多长时间多少人做出了什么样的用例模型。如果这个度量都没有做，就可以免谈度量用例分析的问题。我看，也许大家都只够免谈的水平。

怎么评审用例是否已经完整？
客户代表说：“就只需要这些服务项目就够了”，“真的，现阶段要这些服务项目就够了”的时候。如果用例是“为客户提供的可行的服务项目”的话，用例永远没有完整的时候，用例永远都是完整的。
最小的评审检查单如下：
1.有这些客户吗？
2.他们真需要这些服务吗？
3.这些服务现实吗？
如果，这三条都没有得到评审，也可以免谈用例评审的问题了。

 回复: 顶一下
　

---

我觉得您关于业务建模和用例问题已经有了很多材料，我觉得同一个用例概念可适用于软件内外部建模，所以成为uml语言的基本成分，您觉得它和面向对象的世界观有什么关联吗：用例也是一种事物?
关于用例和子系统的关系呢
　

这位真是高手，想来应该有丰富的实际开发经验或者广博的知识。
我打乱了几个问题的顺序，从而希望有知音能够帮助我系统关于用例的认识。在这里向作者表示感谢。
看了你的理解，确实精辟，虽然未必能够人人同意，但是UML本身就是思想而非工具，希望你能够继续下去，讨论一下在动态图之前如何对让用例落到实处，小弟等待兄台高论。

我的几点认识，希望兄台指教
1.用例：角色发起的有意义的动作序列－而非流程。
2.用例的发现：应该分成两个部分，第一部分是在项目计划书之前，由客户提供，这时项目组的参与很容易造成后续的麻烦。第二部分应该由组织的指南规定。
3.在进行C需求之前，完成的角色分析非常重要，关系的项目的成败，对角色的分析必须完整而准确,增量式的想法是绝对错误的。（我曾经接手一个项目，糟糕的角色分析让整个项目造成项目的实际失败。）
4.第一个动作:这个问题我现在没有具体的想法，组织在国内是“面向客户的开发”和“面向领导的开发”，但是在项目计划书完成之后，是否应该准备SRS报告以确认C需求？
5.怎么发现用例：我没有系统的看法，不过我感觉应该从角色出发（疑问中....）
6.用例度量始终是我经历项目的难点，曾和几位PM讨论，但是未有结果。
7.用例评审应该由：SCM，SQA和评审组的参与，同时Test的人参与，但是如何组织，协调？如何用例细化中发现和回避技术难点？(思考....)

同意第三点

我一般跟随RUP的中文翻译版，
把Actor叫做“主角”（主宰的角色，客户是上帝，所以，客户就是主角）。
把Worker叫做“角色”（干活的角色）
我觉得这个翻译不错。

你提的问题都很好，关于它们的讨论，我以前发了很多言了，请jmisp19用babituo这个名字查找一下发言内容。
欢迎用实际的问题引导我的回答。

对于过程，大多数人看到RUP庞大的形式就吓怕了，其实背后的思想和我们的常识没有多大区别。建议jmisp19用“理解RUP背后的想法”的心态把RUP读薄一点。

多谢作者的指点，在RUP方面，我将投入更多的关注。
对于RUP我始终是谨慎乐观的态度，正如XP。在跟踪RUP的3年中，我没有见到能够让人为之震惊的进步，其浩如烟海的名词对于后来者确实是个困难，不过现在Rational并入IBM，想来简化的可能性几乎为零了（AS/400和OS/390就是例证，虽然客户每年给IBM数以千计的简化建议，IBM始终能够以不变应万变）。
在这个方面我看好CMM指导路线，虽然两者异曲同工。对其进行适当的裁剪（抄袭了，抱歉）然后指导开发项目，业界成功案例却也有几宗，如果兄台有时间，希望能够共享。

我曾经发过讨论此话题的言论，
我始终觉得使用CMM和RUP之类的东西关键是理解形式背后的思想。
我曾经发表过“裁剪”可笑论，CMM本身是一个“常识工程”，我理解是影响软件从业人员的思想，再造他们的从业常识，而不是规定他们必须走那几条道路。你怎么能对一个完整的思想体系进行裁剪呢？
想用CMM/RUP？主动接受其思想的影响就足够了，你的道路自然会和以前不同？

现在，换个角度来谈裁剪问题：既然对思想无法裁剪，那就对形式进行裁剪喽。你就不怕裁剪了形式而把背后的思想剪得更加支离破碎吗？“剪”这个词实在让用思想工作的人望而生畏。

思想和形式都不能“剪”，前人的经验不是没法让我们利用？哦，原来“剪”的意思只是学习前人留下的知识，模仿前人的做法而已，为什么还有那么多人以为只有剪树枝一样把一棵大树剪成一棵小树才叫“裁剪”呢？前人种了一棵大树CMM/RUP,我们只要根据我们项目的特点，去掉一些枝节，添加一些枝节就可以得到我们的项目过程定义的“小树”了。这看起来是多么符合逻辑和完美。
看来还得操起剪刀剪，不过要看看剪刀是什么，被剪的是什么。如果真的要剪，
1.要准备好你的剪刀：对项目目标的理解。
2.要看清被剪的对象：CMM/RUP思想体系（所以你必须清楚CMM形式和思想的关系），也就是为什么需要每个过程、角色和工件？不要它会带来什么风险？
3.要看到裁剪的结果：服务于项目目标的CMM/RUP思想领域和剪断思想后带来的风险列表（你没有按CMM连惯的思想考虑项目过程，这会给项目带来什么风险）。
4.用风险应对措施把剪断的思想片断缝起来，这样穿在你的项目身上才会合身，相当于确定了衣服的尺寸/大小/款式。不会让你的项目过程“走光”，当然，你要有意适当暴露一些地方另当别论。
5.至于形式上的方法步骤，就像衣服表面的颜色和面料，完全可以根据喜好和经济实力进行选择，CMM/RUP的过程提供的只是一种可供参考的样板而已，也许他们只是“蓝色的毛料”。
原来，“裁剪”是可行的，是用目标来“裁剪”思想。

1。我一般不用概念模型这个词。一般用领域模型来反映业务的东西，与系统无关。对领域模型应用分析模式，实际上在分析业务时就可以开始了。这也是对领域模型的抽象。到分析阶段成果是一些分析类，这里已经有系统的东西在里面了。如MVC分析出来的分析类。

2。对于建模用什么图不重要。关键是目的。如何体现用例驱动，架构为中心。体现用例者就是用例实现由类图，序列图或活动图。分析阶段用分析类来实现用例实现，设计阶段用设计类来实现用例实现。架构为中心应该在分析阶段就可引进。一般用类图来反映高层分析包的依赖关系。如反映MVC包。在设计阶段需要引进多个系统支撑包（类）。这些包的关系可用类图体现。实际上，体现架构的是framework。一般是类图体现。最好有专门目录来表现，其中最好有表示进程的视图。

 回复: 架构设计与用例分析
　

---

架构设计和用例分析与实现构成了分析设计的主要内容，我同意您架构主要以FrameWork和各包依赖关系的说法，但若系统设计中架构问题和用例分析好像是并列的工作，用例分析时架构设计可能不需要非常的细化，在物理设计阶段架构设计才必须完整，这种看法对吗
另一问题：
我们好像没有自己的架构设计，而是将各种概念往一个已有的架构里装而已
做管理软件尤其如此，但的确可以发现一些结构与行为很相似的业务对象
如：合同和订单，我想对这些东西抽象，并重用，目前我以业务对象为中心考虑问题，您有什么建议
通用的商务框架ibm fransico之类的东西没见过。

这几日研读前辈旧贴，未敢费迟，深有体会，获益非浅。
前辈文采飞扬，常有画龙点睛之笔；然，旧日文章似乎亦有疏漏之处，想来是“智者千虑，必有一失”，亦或有好事者假借前辈名而为之。

在下对于PM始终持崇敬态度，先辈高人登高望远，指前路而易后者，驽钝之后辈如我者，殚精竭虑，萤囊映雪，亦不能解先辈思想之一二。旧人言“道可道，非常道；名可名，非常名”，想来也是此理。项目伊始，在下莫不战战兢兢，恐污圣手哲思。

对于项目管理，在下不知前辈批评的立足点为何，陈述一二，请斧正：

1.作为工程学之一分支，软件项目具有工程学之基本特征，然，由于产品在成本，质量两个方面度量困难，此分支亦有其鲜明特殊性，“而这两个方面又恰恰是现代企业生存的根本”（抄袭了）。

2.项目实施之主体乃完成项目之软件公司，对待项目的态度应基于公司之态度。然，对于特定之时间，空间这又未必是基础。

3.项目实施中，影响项目的重要因素是项目经理，此乃知识性企业的基本特点。项目经理在人格和技术水平等方面的些许缺陷均可导致项目之失败。被程序员所轻视是项目失败的开始（程序员：自尊和高傲）。想来任何事都是一样，若列宁能长久些，照相都要前移半步的斯大林又怎能把苏联搞得..。呵呵,言之无物了！

4.项目经理本身对公司和技术的态度，专注，执着。忠诚的项目经理对公司确实难得。此点可与3合而为一。

综上所述，在下以为诊视项目管理方面的技术应该尊重以上事实。

1.项目管理技术的之采用需立足现实，3，5人之小公司如要用CMM之标准，恐有不知深浅之嫌；XP便是上上之选。如长天，恒升，信雅达之列如不用CMM，海外之单亦是难取。

2.在时间上，公司成立，大多希望成百年老店，你我者不过过客，未早未晚而已。因之，PM之工作需思既往而念将来。积累现行项目之经验，乃PM工作之一。经验之重要，若非小马大鹏，所遇者皆知之。“秦人不暇自哀，而后人哀之。后人哀之，而不鉴之，亦使后人而复哀后人也”，此乃国内软件业最大之悲哀。

3.人，人乃知识型组织之根本。核心项目经理之背叛行为对公司可造成致命之伤，此类实例想来前辈当有所闻。“知识愈多越反动”，主席之言一语中的。虽各种缘由不一类同，然工作之压力首当其冲。02年PM大会，与会者各得一牌，上曰“PM are Person”。呵呵，哭笑不得，保留至今。

纪律乃公司，项目之根本，以思想指导、保证项目，在下未曾尝试。亦无“曲法申恩，吞舟是漏”之举。此点愿与前辈复议之。

两三妄言，未加思索，请前辈指教。

我最近对学习型文化有所思考，觉得CMM/RUP和学习型文化是密切相关的。也就是说，从管理的角度看，CMM用于软件项目的管理，层次应该高于项目管理，当然，这不是否定项目管理，比如CMM3是对CMM2的否定吗？当然不是。
国内使用CMM失败的例子应该不少，本人发起的一次长达2年的CMM之旅，我认为就失败了，虽然拿到了证书，但我依然认为是一个彻底的失败。原因就在企业文化不配套。
我这并不是失败之后对教训的检讨，这个失败在我发起这趟行程时就有预计。只是近期我对学习型文化有更深刻的理解。如果企业没有意识到培养学习型文化的重要性，或意识到了却没有做出哪怕最简单的行动，用CMM是注定会失败的。从某种意义上说，CMM反倒是培养学习型文化工程的一部份。
正如你所说，项目管理重视过程的严格，纪律性和计划性。这是非常重要而且必要的一方面。但远远未够充分。

管理分三个层次（我不认为是三个阶段，是同时，为了管理见效，也必须是同时进行的三个层次）：
1.人治，治情感。
2.机治，治行为。
3.智治，治心智。

项目管理处于上述第2层。您看到了CMM在上面第3个层次上的东西了吗？

 回复: 软件的项目管理和工程的项目管理
　

---

我的从业经历一直在网络工程和软件开发之间摇摆。自我评价对网络工程项目管理都是成功的，对软件开发的项目管理都是失败的。

我自己反思：网络工程项目管理存在的风险和软件开发存在的风险不同为本质原因，风险所在为项目管理的一个重要因素。

软件开发的风险所在主要有两点
1、交流
在交流中信息理解不一致
2、技艺风险
一个团队的人员在技艺上能够达到相互配合和一致，形成这样一个团队需要时间
目前基本处于单干状态，我不知还有没有机会领导一个软件团队。若有我希望能够成功

赞同，希望启动一个开放设计的项目，最好项目比较小，大家一起来分析、设计，讨论每一步分析、设计决策。

 回复: 老兄在商业对象模型的国外进展方面可有研究
　

---

商业模型就是模型的理论研究。要么就是某一个行业的模型研究。国外肯定有很多人在做这些事情。不过我并没有接触他们。
我也只是现在没什么事情做，就看这方面的书而已。我想关键是要多想。

笼统的说架构设计不够准确。这里面至少有软件技术架构（如mvc,dao等），分布架构（如b/s,c/s,三层等），业务架构（业务实体间关系）。如果说前二者是纵向，业务架构是横向，那么解决方案就是一个立体的东西。
1。前二者满足非功能需求，用例分析满足功能需求，实际上可以并行。而且是迭代的，没有说完全搞顶什么，再接着做什么。
2。业务架构实际上是领域分析的事情。做适当的抽象是有意义的。分析模式在这里比较有帮助。抽象还有一个代价问题。必须考虑抽象的层次既领域范围（context）问题。显然，领域范围越宽，可抽象的共性就越少。一个极端的例子：如果把所有的买卖关系都抽象为合同，那么这个合同的实用意义就不大了。