2011
需求分析之六大原则
需求分析的六个原则（一）永远不要显得比客户更聪明
1、需求分析第一个原则：永远不要显得比客户更聪明。
聪明反被聪明误，这样的事情太多了，我们产品经理都是有智慧的人，而不是耍小聪明的人。
2、原则第一点：了解需求，而不是去批评客户。
产品经理不是批评家，心理上要重视客户，行动上要尊重客户，平等对待每一个客户。
3、 原则第二点：客户比你更熟悉业务的环境。
产品经理熟悉的仅仅是产品本身，但是，产品经理要做的却不仅仅是产品本身。
4、原则第三点：真正的问题只有客户知 道，我们要做的就是让客户愿意说出来。
客户会给你反馈，但是这些反馈有些是真实的，有些是敷衍的，你希望真实还是敷衍，请参考原则第一点。
需求分析的六个原则（二）尊重用户的现实选择
1、需求分析第二个原则：尊重用户的现实 选择。
产品是客观的，用户是客观的，使用是客观的，需求也是客观的，一切都是现实的。
2、 原则第一点：客户永远是对的。
客户不是我们的敌人，客户不会害我们，客户提出的需求看似在为难我们，但本质上是为了让客户自己更好的使用产品，因此，客户不会为难自己。
3、 原则第二点：提供最合适的解决方案，而非最好或最贵的方案。
我们能够做的不一定是最好的，我们不想做的有时候往往是客户最需要的，找到最合适客户的，而不是最合适我们的。
4、 原则第三点：不要把客户当傻瓜。
这个世界上没有傻瓜，自以为对方是傻瓜的人才真的是傻瓜，不要忽悠客户，不要欺骗客户，如果非要在这个前面加上一个期限的话，我希望是“永远”。 Read more >>
2011
Zachman企业架构框架
早在1987年，John Zachman就提出： “为了避免企业分崩离析，信息系统架构已经不再是一个可有可无的选择，而是企业的必需”。 从那时起，Zachman的企业架构理论就开始逐渐发展起来， 它现已成为许多大公司用来理解、表述企业信息基础设施的一个直观模型， 为企业现在的以及未来的信息基础设施建设提供了蓝图和架构。
Zachman的企业架构是一个全新的模型，为企业信息基础设施提供一种可以理解的信息表述。 这个框架得到广泛的认同，Zachman 自然而然就成为 ZachmanFramework 之父。其大意是说，对同一个信息系统，不同的人看同一个问题，其结果是不同的。
Zachman没有把企业的流程简单视作一系列步骤，而是综合考虑不同角色的不同观点，提出了一个多视角、多维度的企业架构。
企业架构中的不同角色
·企业拥有者
·业务管理者
·系统分析者
·系统设计者
·系统建设者
·系统本身
下图的各行内容即反映了不同角色的不同关注点（角度）。
Zachman同时承认每个角色均关注相同的信息类别（维度），即下图各列内容：
企业架构的信息类别
数据（什么？）
功能（怎样？）
网络（哪里？）
时间（何时？）
角色（谁？）
动机（为何？）
企业架构理论术语
“企业”（Enterprise）是指由一整套可识别的、互为作用的业务功能构成的商业组织。 它有能力作为独立实体经营运作。 根据这一定义，就应该存在企业内的企业。 只要企业内部的事业部门能够独立运作，它或许就可以被当作一个企业。 在这里，这一企业概念也可以被看作为“扩展企业”（Extended Enterprise），它意味着企业架构框架也包括了企业与外部实体的相互关系。 例如： 供应商、商业伙伴和客户。
“架构”（Architecture）提供基础框架， 它定义和描述了企业实现经营目的和商业愿景的平台。 “架构”可以被具体定义为： 与企业经营战略、信息需求紧密相连的一整套原则、方针、政策、模型、标准以及流程，它结合企业未来发展方向，为企业各项解决方案的设计、选择和执行提供指导。
软件设计之：软件架构和框架的区别
人们对软件架构存在非常多的误解，其中一个最为普遍的误解就是：将架构（Architecture）和框架（Framework）混为一谈。
框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础。框架是半成品。典型地，框架是系统或子系统的半成品；框架中的服务可以被最终应用直接调用，而框架中的扩展点（插槽）是供应用开发人员定制的“可变化点”。
软件架构不是软件，而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；当然，引入软件框架之后，整个开发过程变成了“分两步走”，而架构决策往往会体现在框架之中。或许，人们常把架构和框架混为一谈的原因就在于此吧! Read more >>
2011
软件设计：软件框架-软件类库
框架和类库等概念的出现都是源于人们对复用的渴望。“不要重复发明轮子”，成了软件界的一句经典名言。从最初的单个函数源代码的复用，到面向对象中类的复用（通常以类库的形式体现），再到基于组件编程中二进制组件（.NET中是以IL程序集形式存在的）的复用，人们复用软件的抽象层次越来越高。现在，框架复用是抽象层次的又一提升，框架的复用不仅仅是功能的复用，更是设计的复用。 Read more >>
软件设计和开发模型：增量模型（Incremental Model）
什么是增量模型
增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如下图所示：
增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。 Read more >>
2011
细谈软件需求分析过程：提取、抽象、升华
软件的需求分析必须要有对原业务的一个深入了解、提取、抽象、升华的过程，治理软件需求分析尤其如此。
软件的需求分析是从用户的业务中提取出软件系统能够帮助用户解决的业务问题，通过对用户业务问题的分析，规划出我们的软件产品。这个步骤是对用户业务需求的一个升华，是一个把用户业务治理流程优化，转化为软件产品，从而提升治理而实现的质的飞跃，这一步是否成功，直接关系到开发出来的软件产品能否得到用户认可，顺利交付给客户，客户能否真正运用我们的产品帮助他解决业务或治理问题。
按照软件工程对软件开发过程的描述，需求阶段我们可以细分为需求调研和需求分析两个小阶段，需求调研需要充分细致的了解客户目标，用户业务内容、流程等，这是一个对需求的采集过程，是进行需求分析的基础预备。当我们已经了解、理解了用户的业务，于是可以开始分析需求了。软件系统的需求分析可以由产品工程师或系统分析员或两者分阶段合作完成全部的需求分析工作。 Read more >>
2011
项目需求分析：原型法
软件开发中最为困难的是要准确知道应该要开发些什么。因为一旦需求分析做错了，不但会给系统功能带来极大的损害，并且不断的修改也会浪费资源。有资料表明，现在的软件项目中返工开销几乎占了总开发的一半，而导致返工的主要原因就是需求分析不明确。
软件需求分析（Software Requirement Analysis）是一个项目的开端，也是项目最重要的关键点。它的定义是指研究用户想要得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，并建立可确认的、可验证的一个基本依据。曾有调查报告显示，软件产品存在不完整性、不正确性等问题，80%以上是由于需求分析错误所导致的，而且由于需求分析错误造成功能性问题尤为突出。所以，一个成功的需求分析是软件项目能否成功的关键一步。因此，在软件开发中产生了一个核心问题：如何在用户需求不明确的情况下进行系统开发？ Read more >>
![[图片]](http://ww1.sinaimg.cn/large/62a4f68ejw1dsm3wbzpg9j.jpg){kind=link}
![[图片]](http://ww1.sinaimg.cn/large/62a4f68ejw1dsbz742uo3j.jpg){kind=link}
![[图片]](http://ww3.sinaimg.cn/large/664ce1d1jw1dsbj5xyc4lj.jpg){kind=link}
![[图片]](http://ww2.sinaimg.cn/large/62a4f68ejw1dsaxke1ed5j.jpg){kind=link}
![[图片]](http://ww1.sinaimg.cn/large/62a4f68ejw1dra4k3k0xyj.jpg){kind=link}