江大-《工程造价案例》.doc

江大-《工程造价案例》————————————————————————————————作者:————————————————————————————————日期: 一、建设项目总投资的内容包含哪些?答:建设项目总投资的内容(1)固定资产投资,固定资产投资包括:建筑工程费、设备购置费、安装工程费、其它费用。(2)流动资产投资,包括货币资金、短期投资、应收票据、应收账款和存货等。建设项目总投资是指投资主体为获取预期收益,在选定的建设项目上所需投入的全部资金,建设项目按用途可分为生产性建设项目和非生产性建设项目。建设项目总投资生产性建设项目总投资包括固定资产投资和流动资产投资两部分。而非生产性建设项目总投资只有固定资产投资,不包括流动资产投资。建设项目总造价是指项目总投资中固定资产投资总额。(也即建设项目总投资中的固定资产投资与建设项目的工程造价在量上相等)二、设计方案的优劣如何评判?答:是否从需求出发这里的需求是指用户真正要做的事情,要解决的问题。但好多时候用户的需求并不明确,除非他看见真实的产品。让需求方去抽象的描述,或者画设计图,也未必能够搞清楚他真正想要的是什么。所以,快速的发布产品,积极收集用户反馈并进行调整。要尽量避免一种情况,那就是一伙人花了两周或更多时间,做了一个包含了各种先进技术,支持各种炫酷功能的产品,但当交付给用户时他们却不知所措,想做的事情不知如何下手。用户不关心你的系统分了几层,实现了哪些模式,用了HBase还是Cassandra锁;他们也不懂什么是Ajax,什么是SOAP,什么是JSON;用户要的是什么?帮助他们搞清楚真正要做什么,并提供合理的解决方案。是否简单除了排在第一位的需求,我认为完全可以抛开所谓的优雅、可扩展性、性能等复杂的指标;”简单”应该是放在这些之上的重要标准。大多数事情,由简单到复杂很简单,但由复杂变简单就可能是不可能的,或者要对方案近似于推翻的修改。有时候我们要在”扩展性”与简单粗暴间取舍,而灵活性、扩展性与简单很可能是相悖的。每当出现此种情况时,基于上述原因,我个人倾向于选择简单。应当避免过度设计,你设计了一个能够适用多种情况的方案,但好多情况可能根本就不会发生,有些需求就是被这样设计出来的。其实,只要保持简单,后续再添加新的功能不会太难。避免过早优化只在需要优化的时候才优化,初始方案中最好不要有程序级别性能优化的部分。一般来说优化会使原本简单易懂的逻辑变复杂。比如语言的编译或者解析过程,其实都是把程序从易读的格式(源码),转换为了效率更高但人类很难看懂的格式(机器码或字节码)在可以接受的情况下,可以用性能换取程序的可读性和可维护性。是否经受的住讨论推敲每个人的思维方式都不通,讨论可以弥补个人思维的局限。争吵还可以促使人进一步思考,甚至会找到更好的方案。如果你非常在意别人对你自己的方案指手画脚,或者不擅长在讨论时运用急智的话,那就要讨论之前自己预演多次。多问自己,我要解决什么问题,为什么要选择这种方案?不能因为之前做这类事情的时候用的这个方法,就认为这次用相同的方法也是正确的,也不能凭主观感觉。其实要说明原因很简单,搞清楚为什么要这么做,如果不这么做的话有什么问题即可。控制未知性我不能想到将来可能发生的全部情况,但我们要评估出方案可能造成的最坏后果。同时,除了考虑方案的优点,要更多的考虑缺点。因为人都是趋利