在美国学习和工作期间，我注意比较了中美两国软件公司在软件开发管理和技术方面的不同之处。下面以我在硅谷一家从事企业语音识别平台软件开发的公司工作的经历为例， 介绍我的一些观点。第一，软件工程师年龄和经验的反差。我工作过的是一家NASDAQ上市公司，公司 只有5年时间，但是近一半的软件工程师、软件项目经理和软件设计师都不算很年轻，并有着5年以上的软件开发经验(不包括在校期间的经验)

     微软的软件开发管理一直是实用主义至上，检验一个项目管理人员水平高低或者软件开发方法优劣的唯一标准就是看团队是否能够在规定的时间内开发出高质量的软件产品。  在微软，对项目管理的要求非常细致，也积累了很多的经验，看得出微软十分重视经验的累积，成功的经验往往能够得到非常多的重复使用，所以很多时候对某些做法他们也讲不出一个所以然来，只是说这是通过实践经验得到的。比如office开发团队的朱

  在微软，测试人员可以说是团队前进的最大动力，可以说是测试人员在不断推动着整个团队朝着既定目标前进。  在微软，测试人员和开发人员在一个团队中的比率差不多，而且开发人员和测试人员的联系非常紧密，有点儿部分彼此的感觉。测试人员随时可以访问团队的代码库，开发人员也可以运行一些测试脚本来验证自己的开发，而且开发中的许多问题也都是双方共同努力解决的。  在微软，软件测试的自动化水平非常高，许多测

测试的过程应该严格遵循一定的过程与计划，这样的过程体现于测试案例中，测试者可以只按照测试案例便可以找出该软件的问题所在，而不需要对软件的需求有深入的了解，恰恰这个测试案例的编写人却需要很深入了解软件需求设计架构，可是能够编写好的测试案例的是一个测试员的基本素质。总结几年风雨兼程的测试历程,有以下的一些肤浅体会，与大家一起交流： 编写原则：FVT(功能测试)-- 涵盖需求，细到API()， 综合业务

前半句话我认同，国内的确有这种情况；但我觉得具体跟国内大多公司软件水平还比较低有关系，他们对软件工程的理解还是浮于表面，没有真正理解软件工程实质。而且我觉得国内对软件开发的理解还是停留在上世纪八十年代九十年代初的时候。尤其是软件观念上的落后。很多人即使读过软件工程，读过中文英文版的，但若没有正规经历过大型项目，对软件工程还是理解很浅的。软件开发是实践性的，不是教出来的，不是看书看出来的，而是动手做

系统分析员思想全局观念是系统分析员必须具备的观念。如果系统分析员设计时太注重细节，往往会陷入在某个问题上纠缠不清的泥潭。（93年，我论文指导老师的一席话影响了我随后几年对软件开发的理解——今后计算机会越来越快，多写几行代码少写代码无关紧要，最重要的是整体；一开始就错了，某个部份编得再好，也是没有用的）　　系统分析员要有面向用户的思想。系统分析员应当有能力将自己扮演成用户，来了解要交付的项目看起来想

GB、CMM、RUP、XP一、 GB二、 CMM三、 RUP(rational unified process)------软件3.1 RUP项目生命周期的四个阶段 初始 细化 构造 提交3.2 RUP的九个核心工作流程1) 业务建模2) 需求3) 分析设计4) 实现5) 测试6) 部署 7) 配置管理8) 项目管理

几个概念1 项目与产品项目只是一次性验收，不投入实际的使用，不必过多考虑质量问题产品要投入市场，质量是其生命，一切必须以质量为首要因素开发项目跟开发产品是不同的。开发项目，就是要在最少的资源之下，提供给客户一个可以接受的烂货。可以花100万就让客户愿意结案，绝对不要花101万，让客户拥有一个比较好用的系统。越好用的东西越难做，出槌的机率也越高，为什么要这样做呢？一、 软

1.简介    在过去的十五年里，人们编写计算机程序的方法发生了根本的转变。这种转变是从c或c++等系统程序设计语言到Perl或Tcl等脚本语言的过渡。虽然很多人参与了转变，却很少有人意识到它的发生，更不用说知道为什么会发生。这篇文章是我关于为什么在下个世纪脚本语言可以比系统程序设计语言更好的处理许多编程工作的一点看法。   与系统程序设计语言相

1: Know your objective2: Test Automation requires a manual test process3: The earlier the involvement in the Software Development Life Cycle (SDLC) the greater the benefits4: Test Automation is