剖析短迭代
敏捷教练Dave Nicolette提出：我们应该如何设定迭代长度？是要根据发布周期的时间么？使用短迭代又有哪些好处？
新闻
文章：用UML做好系统分析
作者 邱郁惠 发布于 2008年6月20日 上午1时54分
使用UML如何能让我们做好系统分析的工作呢？就让我们通过基金模拟项目，先睹为快，抢先体验一番。其中可以分为以下几个步骤：
- CIM-1：定义业务流程
- CIM-2：分析业务流程
- CIM-3：定义系统范围
- PIM-1：分析系统流程
- PIM-2：分析业务规则
- PIM-3：定义静态结构
- PIM-4：定义操作及方法
在系统分析员执行了前述的CIM与PIM步骤，并且获得高质量的生成之后，设计师会依据具体平台进一步生成PSM阶段的设计，并交由程序员按图编码，编写出适用于特定具体平台的代码。
详细内容，请阅读全文：用UML做好系统分析
本文节选自机械工业出版社新推出的《系统分析师UML实务手册》中的第2章《做好系统分析》。
《系统分析师UML实务手册》通过一个完整的仿真实例，介绍了从需求到生成UML的用例图及其叙述、活动图、类图、序列图和状态图等，一应俱全，过程细腻，步骤详细。主要内容包括：定义 业务流程、分析业务流程、定义系统范围、分析系统流程、分析业务规则、定义静态结构、定义操作及方法、基金模拟项目、语音备忘器等。
与此同时，机械工业出版社还授权InfoQ中文站独家为大家提供额外的样章进行试读：欢迎下载第10章《基金模拟项目》
这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
发表人
deshi xiao
发表于
2008年6月21日 上午9时58分
Re: 这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
发表人
Tobato King
发表于
2008年6月24日 下午8时56分
Re: 这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
发表人
deshi xiao
发表于
2008年6月25日 上午6时17分
Re: 这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
发表人
郁惠 邱
发表于
2008年6月25日 上午6时47分
赞成！这是一种很好的心态
发表人
Charlie Zhang（张恂）
发表于
2008年6月25日 上午8时43分
Re: 这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
发表人
qian anchuan
发表于
2008年7月3日 下午9时59分
UML 应用方法的创新
发表人
Charlie Zhang（张恂）
发表于
2008年6月25日 上午8时33分
能否介绍一下你的经验和思考？
发表人
Charlie Zhang（张恂）
发表于
2008年6月25日 上午9时0分
思考
发表人
Tobato King
发表于
2008年6月26日 下午9时30分
Re: 思考
发表人
Tobato King
发表于
2008年6月26日 下午9时32分
Re: 思考
发表人
Jacky Li
发表于
2008年6月29日 上午1时0分
Re: 思考
发表人
wonder qi
发表于
2008年7月11日 上午1时12分
使用uml工具来产生文档
发表人
jim han
发表于
2008年6月26日 下午8时24分
很好的分析过程与方法
发表人
hua gao
发表于
2008年6月25日 上午5时32分
-
我们知道，经济活动有审计，你这个系统分析如何审计。以上的例子适应领域应该是大型项目，但我担心如此复杂的业务模型是否能保证顺利执行。
-
deshi xiao 还有更好的方法么?我觉得文档成本比较高,在需求变化比较快的大型项目中,设计文档的维护是一个很头疼的问题.或者说有没有可能提供更好的工具可以降低文档的维护量?
-
通过上述分析过程与方法,可以使 经验/随意的 分析方法/过程 系统化/过程化、标准化/规范化、模式化/模型化，值得分析设计人员认真学习研究。
-
我是以我的技术经验来判断以上文章的，标准化，规范化肯定谁都希望，还有人希望过程自动化呢。可实现这样的系统，现在都在变化中，条件，需求，任务。像文中针对正式的业务系统这样分析，当然没得说，看上去很漂亮，但价值除了好看之外，他的通用性如何呢。所以就中国的软件开发业来说，UML的用处确实有用，但我们不能照搬别人的分析方式，应该用好UML这工具，但分析方式需要创新，并适合中国人的理解方式。
-
謝謝各位對這本書提出這麼多看法。
我想這本書的內容有它可取之處，也會有在實務上難以配合之處。在台灣，很多公司閱讀這本書，理解了之後，將書中的步驟修修改改，形成符合自己公司文化的程序，這是我最樂於見到的。
我從未希望各位完全按著這本書的方式進行，這絕對會有問題，因為每個公司、團隊的文化不同，不可能有一套統一的開發流程，我謹希望這本書可以有拋磚引玉之效，引出您們寶貴的開發流程。 -
deshi xiao：“他的通用性如何呢”
本书好像介绍的是<strong>一种</strong> MDA 的建模方式，我感觉国内外 MDA 还没有普及，即便是 MDA 应用也未必只有一种标准方式，所以我不觉得本书的方法具有广泛的通用性。
当然，我们未必要追求广泛的通用性，有专用性也不错。那么本书介绍的方法是否“专门”适合国内的应用环境呢？我感觉也未必。
但作为一种观点和方法，我觉得作者的思路值得借鉴和参考。
deshi xiao：“所以就中国的软件开发业来说，UML的用处确实有用，但我们不能照搬别人的分析方式，应该用好UML这工具，但分析方式需要创新，并适合中国人的理解方式。
”
赞同，西方再成熟的技术在中国也有一个落地的问题，方式、方法的创新很重要。能否介绍一下你在这方面的经验？
张恂提出的 UML 太极建模 也是出于这个目的，欢迎有兴趣的朋友一起研究。
OOAD*UML 教练 张恂
www.zhangxun.com -
作者说的很实在和诚恳，不错。
“我想這本書的內容有它可取之處，也會有在實務上難以配合之處。”
“很多公司閱讀這本書，理解了之後，將書中的步驟修修改改，形成符合自己公司文化的程序，這是我最樂於見到的。”
“我從未希望各位完全按著這本書的方式進行，這絕對會有問題，因為每個公司、團隊的文化不同，不可能有一套統一的開發流程，我謹希望這本書可以有拋磚引玉之效，引出您們寶貴的開發流程。”
OOAD*UML 教练 张恂
www.zhangxun.com -
2008年6月21日 上午9时58分 发表人 deshi xiao
这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
我们知道，经济活动有审计，你这个系统分析如何审计。以上的例子适应领域应该是大型项目，但我担心如此复杂的业务模型是否能保证顺利执行。
初看之下，本书的分析方法成本并不高，有些是必要的步骤，这样的业务模型还算简单，中小型项目估计也是可以尝试的。
缺点在于，只做到 PIM 就没下文了，好像没把 MDA 的完整流程走完。任何分析、设计模型，如果脱离实际代码，都可能带来风险。所以大家会有能否“顺利执行”的疑问。
你说的审计是不是 audit，自动审计还好，如果人工审计，往往也会增加成本。
估计你有很多话想说，能否介绍一下你的经验和思考，或者更好的、成本更低廉的让系统分析员可以保证质量的方法？
OOAD*UML 教练 张恂
www.zhangxun.com -
实际上项目的文档其实就是这些uml图，但用户估计看不懂uml，他们需要的是文字性的word文档，我的经验是当用户需要提交文档的时候，通过uml工具输出一份文档就行了，而且这些文档用完了就扔，不必专人维护，如果用户对文档的格式不习惯，可以考虑花点功夫定制一下uml工具的报表模板来规范输出的格式，然后辅以专人进行修订，一般说来没什么问题
-
这样自上而下，由外到内，由粗到细的分析方式本身是没有问题的,甚至从哲学的观点上来看都是很科学的.
我感觉出问题的地方是我们抱着"为了保证留下文档","今后有人能够看明白","别人能接手"等等很"自然"的想法,我们企图去[记录整个问题的分析过程],希望每一步都完美的被记录.
1.开发的整个过程可能包括业务用例定义->业务用例分析->系统用例定义->系统用例分析->分析类图->分析序列图...在这个过程中出现的是成[金字塔状态的成本消耗].
2.在现实开发中,企图一次就得到最终的答案是很难的.尽管定义的过程是线性的:CIM->PIM->PSM,事实上我们往往需要在几个过程之间进行反复,
分析->设计->Coding->修改分析->修改代码.由于抱着不肯抛弃过程产物,文档驱动等想法,我们甚至企图去记录整个反复的分析过程,这是需要花费大量成本的工作!
相当于把成本金字塔放大了N倍.到最后可能把自己陷入到一堆"过程垃圾"中.
因此,我认为:抛弃记录过程产物的想法,轻装上阵,以交流替代文档,用多种方式:图片\DV\文本等,只记录"必须的能帮助理解的资料",在迭代后期加入小的文档整理的过程(这个时候是效率最高的,屏蔽了很多分析中的杂质) 会是一个比较好的实践.
另:大型项目或行业项目中,以软件产品线为主导思想,在建立适当的库(规则库,业务流程库,组件库等)为基础上搭建特定领域的辅助分析设计工具,能在很大程度降低整个开发的成本. -
晕了, 段落贴没了
-
可以用两个br来分段:)
-
可工作的软件，胜过面面俱到的文档
-
tobato说的有道理，大多数时候模型的维护要比代码的维护代价大的多。
.gif)
14 条回复
回复