徐雷@优快云

        业务需求的两下两上：       对项目的业务需求的分析是一个项目的入口和最重要的事情，但是很多人员并不知道怎么考虑项目的业务需求。反而受项目范围管理的束缚走进了教条主义。自己认为，用户给多少钱就干多少事这句话本身没有问题，但是如果是基于这句话来管理范围、分析业务需求就容易走进了“只见树木不见森林”的陷阱。导致最后的返工、重做，用户的不满意、系统的不灵活，甚至修改一个小功能

function StorePage(){d=document;t=d.selection?(d.selection.type!=None?d.selection.createRange().text:):(d.getSelection?d.getSelection():);void(keyit=window.open(http://www.365key.com/storeit.as

今天搜索“思维导图“发现了一个非常好的BLOG：人月神话的BLOG欢迎大家积极访问，下面的这篇文章正是从该BLOG发现的，原来自己也想做这件事，不过看了该作者的总结，不敢再班门弄斧了。这个BLOG上还有很多非常好的文章，大家可以自己去发掘。原文出处：http://blog.sina.com.cn/u/493a845501000387－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

UML & Visio 学习 （1） 1．软件系统开发的4个典型活动：需求分析 －＞ 领域分析 －＞ 设计－＞ 实现Ø         需求分析：弄清用户的要求Ø         领域分析：细化软件要解决的问题，在不用软件下人工是怎么解决该问题的Ø         设计：将对问题的分析转化为解决方案，考虑如何用软件解决现实问题Ø         实现：即编码对应的V

 本人经历过CMM2、CMM3、CMMI4和5，随着对CMM的理解的深入，越发产生了深层次的思考。CMM对我个人影响也很大，的确有很多好的实践和理念供我们学习和借鉴。本文不是全面否定CMM，而是从批判的角度审视我们对CMM的认识。大家可以共同探讨。 中国人实际是一个很特殊的人群，中国人的思维方式、价值观和处世方式与西方国家的区别很大，这与中国历史几千年漫长的中国文化和集权管理有直接的关系。

管理者必读的八个定律c     这第一条路是万万走不得的，因为那样会丧失许多权力；第二条路也不能走，因为那个能干的人会成为自己的对手；看来只有第三条路最适宜。于是，两个平庸的助手分担了他的工作，他自己则高高在上发号施令。两个助手既无能，也就上行下效，再为自己找两个无能的助手。如此类推，就形成了一个机构臃肿、人浮于事、相互扯皮、效率低下的领导体系。苛希纳定律 　　西方管理学中有一条著

    一项计算机软件的筹划、研制及实现，构成一个软件开发项目。一个软件开发项目的进行，一般需要在人力和自动化资源等方面作重大的投资。为了保证项目开发的成功，最经济地花费这些投资，并且便于运行和维护，在开发工作的每一阶段，都需要编制二定的文件。这些文件连同计算机程序及数据一起，构成为计算机软件。文件是计算机软件中不可缺少的组成部分，它的作用是：    a．作为开发人员在一定阶段内的工作成果和结束标