<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet href='http://feeds.feedsky.com/styles/temp01.xsl' type='text/xsl' ?><!--这是一个由Feedsy提供技术支持的Feed，为了提高读者阅读的体验，以及满足用户美化自己Feed的需要，我们设计了多种精美的Feed模板，提供给大家选择，所有最终呈现出来的样式，皆由用户自愿选择使用，未经许可，任何团体和个人，请不要擅自修改样式或者盗用，这是对于用户选择权的尊重。--><rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:fs="http://www.feedsky.com/namespace/feed" xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0"><channel><atom:link href="http://feeds.feedsky.com/csdn.net/zhang1976" type="application/rss+xml" rel="self"></atom:link><fs:self_link href="http://feeds.feedsky.com/csdn.net/zhang1976" type="application/rss+xml"></fs:self_link><lastBuildDate>Thu, 05 Nov 2009 17:59:00 GMT</lastBuildDate><title>怎样做IT系统</title><description>系统分析及设计、项目管理</description><link>http://blog.csdn.net/blogrss.aspx?username=zhang1976</link><item><title>有效的系统分析员</title><link>http://blog.csdn.net/zhang1976/archive/2009/11/06/4775221.aspx</link><description>在繁忙的工作之余回想一下，你是如何从一个普通的开发人员变成一个需求分析员的？也许只是突然有一天，你的上司拍着你的肩膀，微笑着的对你说：“这个项目的需求就由你来做吧！”。欣喜之后，心里不禁有些发虚，“我能够成为一个有效的需求分析员吗？”。   有效的需求分析员为什么难以产生         不容置疑，需求分析的正确、完整直接影响着项目的成败，而需求分析员是需求分析正确与否的直接责任人。可是我们所受的教育，所处的工作环境制约了我们，让我们很难成为一个有效的需求分析员。    大学里，老师们讲课完毕后，就会留给学生几道习题，而这些习题几乎是不用经过思考就可以知道它的要求是什么，根本谈不上需求分析，更加不需要考虑如何去进行有效的需求分析。然而，同样是这些学生，毕业后却要面对错综复杂、频繁变化的需求，需要像专家一样发现需求、挖掘需求，但是这些没有经过良好训练的“士兵”仅仅靠天赋和勤奋就能打赢这场艰苦卓绝的“战役”吗？    大多数的需求分析人员都是从开发人员成长起来的。工作中，我们长时间一言不发，面对着冰冷的显示器，手指在键盘上翻飞，嘴角带着神秘的微笑，用一种奇怪的符号在写着什么。我们生活在一个&lt;img src=&quot;http://www1.feedsky.com/t1/292584082/zhang1976/csdn.net/s.gif?r=http://blog.csdn.net/zhang1976/archive/2009/11/06/4775221.aspx&quot; border=&quot;0&quot; height=&quot;0&quot; width=&quot;0&quot; style=&quot;position:absolute&quot; /&gt;&lt;p class=&quot;fswww1&quot;&gt;&lt;a href=&quot;http://www1.feedsky.com/r/l/csdn.net/zhang1976/292584082/art01.html&quot; target=&quot;_blank&quot;&gt;&lt;img border=&quot;0&quot; ismap=&quot;ismap&quot; src=&quot;http://www1.feedsky.com/r/i/csdn.net/zhang1976/292584082/art01.gif&quot; onerror=&quot;this.style.display='none'&quot; /&gt;&lt;/a&gt;&lt;/p&gt;</description><pubDate>Fri, 06 Nov 2009 01:59:00 +0800</pubDate><author>choucsl</author><guid isPermaLink="false">http://blog.csdn.net/zhang1976/archive/2009/11/06/4775221.aspx</guid><dc:creator>choucsl</dc:creator><fs:srclink>http://blog.csdn.net/zhang1976/archive/2009/11/06/4775221.aspx</fs:srclink><fs:srcfeed>http://blog.csdn.net/zhang1976/feed.aspx</fs:srcfeed><fs:itemid>csdn.net/zhang1976/~1201432/292584082/1201410</fs:itemid></item><item><title>身高和混凝土的关系-测量模式</title><link>http://blog.csdn.net/zhang1976/archive/2009/11/05/4772226.aspx</link><description>研究分析模式的好处是知道如何去构造系统应该保存的数据  --------------------------------------------------------------  测量身高和测量混凝土样本的压强有什么关系？  经过分析我们发现他们都符合如下描述：某样东西的某个属性是多少。测量身高的描述是：人的身高是170CM；测量混凝土压强的是：混凝土的压强是4000磅。  抽象这种描述形式为：对象-属性-数量，这样我们就能很明显的看出它们的共同点了。  我们可以用一个对象及它的属性来实现这个模型。但遇到有大量的属性需要描述的时候，这种实现方式就不好了。最直接的问题是导致接口异常复杂，解决之道就是将属性也变成对象，这样就将复杂的属性接口变为能灵活处理的对象关系。这种模型在《分析模型》中被称为测量，这种属性对象就被称作测量对象   改变后的模型为：对象-测量-数量  这个模型的问题在于虽然解决了接口的复杂性，但并没有说明每种测量之间的区别。比如身体检查这种测量和混凝土强度检查会有很大不同，他们需要的测量对象也会不同。如何说明这些差异呢？我们必须改进我们的模型。  改进后的模型为：&lt;img src=&quot;http://www1.feedsky.com/t1/292339345/zhang1976/csdn.net/s.gif?r=http://blog.csdn.net/zhang1976/archive/2009/11/05/4772226.aspx&quot; border=&quot;0&quot; height=&quot;0&quot; width=&quot;0&quot; style=&quot;position:absolute&quot; /&gt;&lt;p class=&quot;fswww1&quot;&gt;&lt;a href=&quot;http://www1.feedsky.com/r/l/csdn.net/zhang1976/292339345/art01.html&quot; target=&quot;_blank&quot;&gt;&lt;img border=&quot;0&quot; ismap=&quot;ismap&quot; src=&quot;http://www1.feedsky.com/r/i/csdn.net/zhang1976/292339345/art01.gif&quot; onerror=&quot;this.style.display='none'&quot; /&gt;&lt;/a&gt;&lt;/p&gt;</description><pubDate>Thu, 05 Nov 2009 16:09:00 +0800</pubDate><author>choucsl</author><guid isPermaLink="false">http://blog.csdn.net/zhang1976/archive/2009/11/05/4772226.aspx</guid><dc:creator>choucsl</dc:creator><fs:srclink>http://blog.csdn.net/zhang1976/archive/2009/11/05/4772226.aspx</fs:srclink><fs:srcfeed>http://blog.csdn.net/zhang1976/feed.aspx</fs:srcfeed><fs:itemid>csdn.net/zhang1976/~1201432/292339345/1201410</fs:itemid></item><item><title>抽象是如何发展的</title><link>http://blog.csdn.net/zhang1976/archive/2009/09/30/4620539.aspx</link><description>闲话不述，开门见山     这是一个组织结构图，公司的墙上一般都会挂一张。这里面有个规则，图上虽做表现却没有说明。比如部门只能与子公司发生关系，而不能直接与分公司发生关系。这是一个很重要的规则。决定了许多人的责权利，不做明确的说明，实在过意不去。于是修改为下图。     分公司，部门等被抽象为组织这个单元。它们之间的关系比较单纯，就是父节点和子节点的关系。这些关系都受到规则的制约。新的问题是，事实上组织机构绝对不会这么简单。例如很多部门都会与多个机构发生关系。比如产品售后服务即与服务部门有关系又与产品线有关系。这个模型还不足以支持双层级关系，于是我们修改如下。     这个不用多做解释，地球人都知道，两层还凑合，多层会死人。不过大叔到底是个高人，人家早就看出，其实关系也是可以分类。这个分类是职责模式中比较重要的概念，需要详加阐述。先举个很恰当的例子。在中国的某个省，高级官员往往就是那么几个人。但中国官僚体系却是很庞大和复杂的。其中省委和省政府是不同的组织机构，但要说各自办公室里却都还是那几个鸟人高高在上。这里面就存在一个分类。省委是一种类型的组织机构，省政府是另一个组织机构类型，这两种&lt;img src=&quot;http://www1.feedsky.com/t1/292339347/zhang1976/csdn.net/s.gif?r=http://blog.csdn.net/zhang1976/archive/2009/09/30/4620539.aspx&quot; border=&quot;0&quot; height=&quot;0&quot; width=&quot;0&quot; style=&quot;position:absolute&quot; /&gt;&lt;p class=&quot;fswww1&quot;&gt;&lt;a href=&quot;http://www1.feedsky.com/r/l/csdn.net/zhang1976/292339347/art01.html&quot; target=&quot;_blank&quot;&gt;&lt;img border=&quot;0&quot; ismap=&quot;ismap&quot; src=&quot;http://www1.feedsky.com/r/i/csdn.net/zhang1976/292339347/art01.gif&quot; onerror=&quot;this.style.display='none'&quot; /&gt;&lt;/a&gt;&lt;/p&gt;</description><pubDate>Wed, 30 Sep 2009 11:26:00 +0800</pubDate><author>choucsl</author><guid isPermaLink="false">http://blog.csdn.net/zhang1976/archive/2009/09/30/4620539.aspx</guid><dc:creator>choucsl</dc:creator><fs:srclink>http://blog.csdn.net/zhang1976/archive/2009/09/30/4620539.aspx</fs:srclink><fs:srcfeed>http://blog.csdn.net/zhang1976/feed.aspx</fs:srcfeed><fs:itemid>csdn.net/zhang1976/~1201432/292339347/1201410</fs:itemid></item><item><title>学会抽象</title><link>http://blog.csdn.net/zhang1976/archive/2009/09/30/4620162.aspx</link><description>读MF的《分析模式》需要“武功”，武功不到读起来就会很费力。就好比你会两下拳脚，却非要去研习《九阴真经》，最后的下场可能就是走火入魔。  这里的武功包括两方面内容：知识和能力。读这本书的起码知识是熟悉表达法。MF大叔在此书中用了odell5,这种表达法类似于UML，但之间还是有些差别。另一个则是抽象能力。分析的本质就是不断抽象的过程。如果你不具备这种能力，又能做什么样的分析呢？  能力是需要训练的，读大叔的《分析模式》是一个绝佳的训练过程。不过这不是练习太极拳（练太极拳的秘诀是“报个大西瓜回来，转转它，然后再推出去”），改变自己思维方式是个痛苦的过程，如果你不幸又是个发散性思维的人，那简直就像进了地狱（发散性思维在抽象过程中也是很重要的，但不是最重要的）。  如何抽象？大叔在第二章“责任模式”开头的例子就很好的做了示范。我们来看看大叔怎么抽象的。  (图一)  （图二）  看看上面两幅图，有啥差别吗？形状完全不一样。但这两幅图表达的却是同一个意思，那就是通讯录。这就是经过抽象后的结果。我们起码能看出一层意思来。抽象不是用来创造新事物的，他只是描述世界的一种手段。抽象是个手段，是个方法，&lt;img src=&quot;http://www1.feedsky.com/t1/292339348/zhang1976/csdn.net/s.gif?r=http://blog.csdn.net/zhang1976/archive/2009/09/30/4620162.aspx&quot; border=&quot;0&quot; height=&quot;0&quot; width=&quot;0&quot; style=&quot;position:absolute&quot; /&gt;&lt;p class=&quot;fswww1&quot;&gt;&lt;a href=&quot;http://www1.feedsky.com/r/l/csdn.net/zhang1976/292339348/art01.html&quot; target=&quot;_blank&quot;&gt;&lt;img border=&quot;0&quot; ismap=&quot;ismap&quot; src=&quot;http://www1.feedsky.com/r/i/csdn.net/zhang1976/292339348/art01.gif&quot; onerror=&quot;this.style.display='none'&quot; /&gt;&lt;/a&gt;&lt;/p&gt;</description><pubDate>Wed, 30 Sep 2009 02:09:00 +0800</pubDate><author>choucsl</author><guid isPermaLink="false">http://blog.csdn.net/zhang1976/archive/2009/09/30/4620162.aspx</guid><dc:creator>choucsl</dc:creator><fs:srclink>http://blog.csdn.net/zhang1976/archive/2009/09/30/4620162.aspx</fs:srclink><fs:srcfeed>http://blog.csdn.net/zhang1976/feed.aspx</fs:srcfeed><fs:itemid>csdn.net/zhang1976/~1201432/292339348/1201410</fs:itemid></item></channel></rss>