剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 邱郁惠 发布于 2008年6月20日 上午1时54分
使用UML如何能让我们做好系统分析的工作呢?就让我们通过基金模拟项目,先睹为快,抢先体验一番。其中可以分为以下几个步骤:
在系统分析员执行了前述的CIM与PIM步骤,并且获得高质量的生成之后,设计师会依据具体平台进一步生成PSM阶段的设计,并交由程序员按图编码,编写出适用于特定具体平台的代码。
详细内容,请阅读全文:用UML做好系统分析
本文节选自机械工业出版社新推出的《系统分析师UML实务手册》中的第2章《做好系统分析》。
《系统分析师UML实务手册》通过一个完整的仿真实例,介绍了从需求到生成UML的用例图及其叙述、活动图、类图、序列图和状态图等,一应俱全,过程细腻,步骤详细。主要内容包括:定义 业务流程、分析业务流程、定义系统范围、分析系统流程、分析业务规则、定义静态结构、定义操作及方法、基金模拟项目、语音备忘器等。
与此同时,机械工业出版社还授权InfoQ中文站独家为大家提供额外的样章进行试读:欢迎下载第10章《基金模拟项目》
我们知道,经济活动有审计,你这个系统分析如何审计。以上的例子适应领域应该是大型项目,但我担心如此复杂的业务模型是否能保证顺利执行。
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说的有道理,大多数时候模型的维护要比代码的维护代价大的多。
本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目,怎样配置一个JSF应用去使用JBoss Portlet Bridge,以及JBoss Portlet Bridge所具备的功能。
在这篇文章里,Bryon Jacob和Chris Berry将和我们继续探讨AtomServer,它是基于Apache Abdera的完整Atom存储实现。作者还创建了几个Atompub规范扩展,其中包括自动标记、批处理和Feeds聚合。
InfoQ中文站的电子杂志《架构师》试刊第二期出版了!相比于上期,我们在内容的选择安排和版式上都根据读者的意见重新做了修正。“细节决定成败”,我们希望基于InfoQ中文站的专业内容,《架构师》能逐渐成为大家喜欢的电子刊物!
在本文中,Steven Haines探讨了Web应用性能调优问题。该领域过去更像是一门艺术而不是一门科学。他提出了一种称为基于等待调优的方法,使整个调优过程更加可度量,也因此更具科学性。
通常来说,改变技术路线时最艰难的部分是辨别语言语法之间的不同。这篇文章就为Java开发者提供了一份如何转向Flex基础语言ActionScript的指南。
本视频主要以财帮子为例,介绍了如何创建一个PV为百万级的Rails应用。其中包括:Rails应用的服务器架构、Rails Cache的优化、负载均衡的处理、Web服务器的调试、分布式解决方案、Open API的设计等等。
InfoQ首席架构师Alexandru Popescu在采访中谈论了InfoQ架构、Webwork与DWR、Hibernate与JCR、Hibernate可扩展性、最新的InfoQ视频流系统和InfoQ的未来规划。
14 条回复
回复