由工具、流程，再回到理论
微软很擅长说服人们使用工具简化抽象作业的方法，这一点在VS2005发挥地淋漓尽致。以往人们对软件工程敬而远之，就是因为它很抽象，许多厂商与教育训练中心的教学方法更是雾里看花。以Rational为例，通常是先教理论、再说明开发流程，最后才学工具操作，也就是先抽象再具体，使得学员最后分不清楚到底开发方法对软件有何益处，遑论结合实务（这一点我们也在对象导向的发展过程中发现）。其实这种教学方法本身并无错误，在大学物理学教授量子力学时，就是采用类似的方法，但大学有4年的时间让物理系学生熟悉量子力学解题的技巧，可是在信息界讲求速成与步骤化（Step-by-Step）的胃口下，很难说服企业花大量时间作教育训练。

软件质量保证人兼无名英雄：谁来担任测试工程师
在微软过去的开发工具缺乏测试部份，测试工具直到现在才内建在Visual Studio中，并整合到软件开发生命周期，使得以往测试流程与开发流程分开所造成的质量管理复杂度降低。

VS2005扶正测试人员这个角色，更让开发过程中常因为时程控管不当，而挤压测试步骤，甚至省略的问题被重视。但测试工程师的公正权威与专业，以及与开发人员的默契，尚需要很长的磨合期，工具扮演着中立的角色，却很可能造成现实中两种角色的矛盾心结。

开发者最担心程序因测试而错误百出（俊美的父母不想见到丑小孩），而测试工程师必须尽力测试软件设计的问题（测试工程师在于证伪，而非证真），作好把关的责任，两者原本就有冲突点。以往由开发人员兼任测试工作，常会造成测试的盲点，也就是开发者常以设计的逻辑验证自己的程序，而不是以使用者的角度测试程序（如果设计汽车的人也必须验证汽车时，会觉得4个轮子的汽车是天经地义的事，而无法了解3个轮子时，汽车是否仍能正常行走）。

企业主管将面对的是，是否要新增这个职位？以及谁适合担任测试工程师？现有的资深工程师提升，但他是否能保有公正的立场，勇于指出以往亲密战友设计上的错误？高薪外聘或外包，却会让项目成本更难以掌控。

软件工程方法论中建议，测试人员应与开发人达到1：1的理想比值，确保软件质量，这对企业而言并不务实，特别是与项目经理的任务有冲突，主管们偏好以最少的人力、物力达到最佳的质量，典型的又要马儿好、又要马儿不吃草。文⊙张瑞隆
?
VS2005仍在努力的事

项目管理仍薄弱
对微软的VS2005注重软件项目管理，虽是初试蹄声，但也打开整合式开发环境的改版新趋势，从目前的开发平台来看，项目管理的部份仅触及软件项目专属的属性上，仍无法涵盖一般性的项目，而达到全面性的掌控，对项目经理而言，尚有一段漫漫长路。

非原生的64位开发工具
目前的VS2005仍是32位版，而非原生的64位应用软件，即使能安装在Windows XP Professional或Windows Server 2003等×64位版操作系统，仍仰赖WoW（Windows on Windows）的执行模式。此外，虽然.NET Framework 2.0已发布64位版，但VS2005在32位应用程序的受限下，造成工程师必需将开发完成的软件部署到64位系统上，并采用远程除错的方式，而无法直接在64位系统上除错。?