Visual Studio 2005中文版结合了项目管理、带入软件工程的概念、首度提供免费的Visual Studio Express版本，以及在.NET平台紧密整合SQL Server 2005数据库。这些变化为软件开发的市场版图以及企业开发软件的方式带来了新的思维和冲击，而以.NET为前提的应用，更包藏着平台争夺的企图。

让软件开发回归软件工程

微软在新一代的Visual Studio 2005，不但扮演着延续Visual Studio这个开发工具承先启后的生命，此次改版更注重团队开发与开发方法，不再执着于技术上提升。简单地说，让软件更容易管理比起更容易开发显得重要些，而且企业主管更在意前一点，他们也正是决定掏腰包的人，只有工程师会喜欢后者，只是更容易撰写程序并无法降低人力成本。VS2005重要改变是平台化与涵盖软件开发生命周期，接下来我们将会分析这些改变所带来的影响。

改善团队开发的人力负担与协调默契

VS2005采用软件开发生命周期，作为企业在选择信息系统发展方法论时的标准流程，其特征是将开发流程区分为几个连续阶段（3个~20个不等），标示着不同的系统发展成果，实作时则配合专门的技术角色（分析师、项目经理等），目的是容易管理、分层负责与确保软件质量。VS2005则在软件开发生命周期中定义出区分架构师、开发人员、测试人员与项目经理，并将软件依角色区分为3种版本：Team Architect、Team Developer、Team Tester等，项目经理的权责则包含在Excel或Project上，可与Team System整合。

微软Visual Studio 2005 是否会改变软件教育模式

VS2005改变软件开发方法论，希望由操作工具而熟悉软件工程，但最终还是让企业导入软件开发生命周期，这需要时间证明。此外，过程中也引导出以前不受重视的测试工程师角色，也让企业在拔擢人才上受到考验。

微软VS2005会改变企业软件开发流程吗？

软件工程将软件开发生命周期视为重要的起步，但软件工程属于信息教育基础之一。如果现今软件开发与维护所面对的问题，必须由微软等这类厂商在工具中内建模板，反客为主来教育企业中的开发人员，那么我们确实得思考长久以来，信息教育讲究速成的严重问题。企业主管面对软件质量不佳，软件项目高失败率等，却也不愿意投资成本以提升软件工程师的素质，那么VS2005只会是舒缓疼痛的止痛药，而非根治的良方。

Express版永久免费，力抗LAMP
．开放界对Visual Studio Express的看法
．Windows界对Visual Studio Express的看法

虽然微软释出了免费的善意，并希望藉此推广.NET技术。不过.NET使用者视Express版为免费「试用」及「体验」的好途径；而开放源码界却视其为「邪恶帝国的阴谋」。所以Express版除了平台及功能的限制之外，还是得面对「信仰」意识型态作祟的问题。

VS 2005 与SQL Server 2005整合优势在哪里？

站在程序开发者的立场，数据库与商业逻辑分开，数据库纯粹储存数据，程序开发交由应用程序处理比较单纯；但从DBA的角度出发，系统归系统，数据的处理由数据库负责比较好。虽然两者看法分岐，不过，Stored Procedure贴近数据库引擎，执行效能较佳，况且数据确实有预先处理的需求，透过程序远程处理不仅耗时，而且有网络断线造成执行失败的风险，因此，实务上Stored Procedure有存在的必要性。?

[此贴子已经被作者于2006-4-7 1:55:39编辑过]

整合式开发环境（Integrated Development Environment，IDE）以往仅扮演工具的角色，但近来面对软件在商业应用日趋复杂所带来的「突显特性（Emergent Property）」，这类性质难以在项目初期事前预测，却影响着上线后整体系统运作的稳定性与可靠度，而这也是客户非常在意的两个结案重点。

微软去年底发表Visual Studio 2005（后续文章中简称为VS2005）试图协助企业开发稳固可靠的软件，首次在单一工具内建开发方法（乐谱）与项目管理（指挥），让旗下原有的Visual Studio产品脱胎换骨，成为不折不扣的计算机辅助软件工程工具（Computer-Aided Software Engineering Tools，CASE Tools）。对同级解决方案供货商如IBM或Borland而言，或许不算是新鲜事，但微软的创新在于它仅用一个工具就办到了！

以软件工程为主的开发方法，目的是让企业能以合乎成本效益的方式，有效地控管软件开发与质量。然而，软件工程从70年代中期便提出，截至目前为止并未让本土的软件产业带来竞争力的变革，探究其成因是软件工程本身为抽象概念，难以落实在现实开发作业流程。微软突破从抽象到具体的实践管道，以VS2005结合软件工程与项目管理，包装成为软件开发生命周期（Software Development Life Cycle，SDLC）。虽然后续效益有待观察，但势必对现今开发现况带来冲击。这些冲击包括：

1.首当其冲的是否适合使用软件工程这类结构性的开发方法，在企业组织与成本上重新变革。

2.接下来是VS2005 Express免费版，在Eclipse开发平台或PHP、Java语言阵营投下震撼弹，让犹豫不决的初学者琵琶别抱。

3.最后是结合自家的SQL Server 2005，使得程序设计师或数据库管理员可以使用.NET语言撰写数据库查询语法，并改进以往数据库程序无法侦错的缺点，甚至可完成软件开发生命周期。

这都将是此篇文章中所要探讨的问题，但我们先简述目前企业面对软件开发的几个问题：

＂软件项目充斥漫无章法的管理制度与开发流程＂
如果软件项目主管比喻为乐团指挥，那么项目经理像是握着指挥棒却没有指挥权力的角色，缺乏协调的操舵手，乐团如何能弹出和谐的交响乐？简单地说，本土的软件项目常出现外行领导内行的窘境。企业主管常直觉上会选择擅长沟通的人负责管理软件项目，让拥有技术的资深工程师负责执行，却在无意中产生角色上的矛盾，前者不一定懂技术却得领导技术团队，而后者掌握关键的领域知识（Domain Know-How）却无法决策。此外，主管或项目经理与客户讨论软件功能变更时，资深工程师常被排除在外，通常是事后被迫接受客户天马行空的附加功能，最后只能概括承受，结果是宁愿敷衍了事、牺牲质量，也不愿冒险更动架构设计。主管总因为项目的高失败率与客户的抱怨而失眠，他们不禁思考：

1.哪一种开发方法能兼顾技术与管理层面？

2.如何更有效地让项目经理与技术人员彼此间信息互通与共享？

3.软件开发方向与质量现况如何了？

4.是否工程师正处于高负荷量工作？是否有人偷鸡摸狗？

5.客户无预期地变更功能时，项目经理应如何控管？

6.人员异动或流程变更时，项目应如何接续？……诸如此类的问题
有趣的是，这原本不应该是开发工具会提问的问题！反而是管理的弊病，微软却反其道而行，企图说服企业导入制度化的开发工具，解决管理人员上（指挥）的问题。

接下来，微软更具野心要解决团队协同开发（乐谱）方法的困难。目前企业因商业竞争全球化导致产品供应炼错综复杂，顾客则因为市场供过于求使得选择多样化，却让企业难以了解客户的需求究竟是什么，造成商业应用软件高度复杂，超越小型组织单打独斗的开发能力，而不得不朝向大型团队合作的模式。这使得软件开发面临的全新的问题与挑战，起先从工具、再跨越到流程规范、并延伸到组织、最后必须采用企业化管理。然而，软件项目高失败率仍是企业主管挥之不去的梦魇，不断寻找严谨的开发流程方法论以有效控制软件变异性，而不是阻止软件改变功能。微软能够在VS2005中内建开发方法，并强调平台化的高度整合与弹性，让使用者在操作工具时，不知不觉便完成制度化流程与项目控管等。

软件项目缺少量身订作的管理工具
「巧妇难为无米之炊」，企业主管面对软件项目的多样性常苦无适切的工具，包括各种技术专精人才的沟通与信息共享、为解决组织管理而造成流程上迭床架屋的复杂性，以及软件项目的特殊性造成其产出物（artifacts）异于其它项目，这些创意的产出物都是软件工程师的艺术杰作，其商业价值隐藏在程序代码的字里行间，不仅难以量化管理，更难以衡量。就像生活外围看似平凡无奇的石头，却是现在计算机主要的组成材料：硅的重要来源，而软件工程师的价值，就在于他们有能力将商业逻辑转换为程序代码（将平凡的石头提炼成芯片）。当然，如果硅谷的软件工程师因为披头散发而视为艺术家（或者怪胎），那么不难想象项目经理如何有通天的本领来控管这群怪胎的产出物了。

目前业界的解决方法，既然管不了程序的运作结果，那么就管理程序代码。就像工地的工头一样，与其担心工人砌砖头的过程中将城堡盖成榻榻米，不如管好每一块砖头在堆砌时的去向，如果这样还会盖出榻榻米，就是项目经理的错误了。只是长久以来，项目管理工具（例如Project）一直着重在时程与成本等企业管理项目上，少有针对软件开发特殊领域的专属工具。相对地，软件项目管理工具虽然管理程序代码，却难以控管成本、资源、任务指派、进度追踪与绩效等，让软件开发与项目管理一直是两条并行线式的发展，缺少交集。

开发方法允许可控制的变动，而不是阻挠改变
开发方法的重要性最容易发生在团队开发上，对非技术背景的人而言，一个软件工程师在计算机屏幕上画出一只恐龙是很神奇的事，但对管理软件团队的项目经理而言，10个工程师可能画出10种长相、外型与行为都不同恐龙，如果缺少开发方法的规范，这些恐龙可能也无法凑成一部侏罗纪公园电影。开发方法像是电影剧本（或交响乐谱），但这个剧本不是用来限制艺术型式创作，而是让创意朝向特定走向，避免发散与失控，这个方向就是客户需求。此外，也不至于抹煞软件工程师的创意。项目经理就像好来坞优秀导演一样，要挑一本适合工程师演出，又深得客户感动的剧本。这在软件开发项目上越来越重要，传统常因为缺少适当的开发方法引导，软件项目便常出现脱稿演出，甚至偏离客户需求方向。此时，项目经理只好不断与客户沟通，甚至隐瞒失控的问题，说服客户达成共识让项目勉强结案。

整合式开发环境供货商着重技术层面的改版
整合式开发环境供货商长久以来，改版的动机都在跟上最新技术，例如微软推出.Net Framework 2.0或Sun制定J2SE 1.5与EJB 3.0时，厂商便急着将新功能纳入工具中，但这正与使用者需求背道而驰。

企业并不急着应用新功能，依新技术改版的工具不仅无法吸引他们，反而使人们更慌张，因为这反应着旧有应用程序升级的压力，以及人员培训的成本等（纵使这些应用软件原本很稳定地运作）。简单地说，软件升级与改版应由企业自行决定，但现实上都是供货商强迫下的结果，可是我们不禁问，供货商怎么会比使用者更了解何时应升级？以及为何要升级？

然而，企业所面对的是应用软件维护问题，特别是人员异动或职务调整，以及客户变更需求或增修功能时，如何更有效率地管理。不要忘了，软件维护过程中就算技术不变，技术人员的异动还是会提高维护的成本与困难度。让商业运作不停摆，如同交响乐团里，就算换了乐手或指挥，还是得向观众演奏出协调的乐曲。

＂注重团队开发而备受瞩目＂
微软在新一代的Visual Studio 2005，不但扮演着延续Visual Studio这个开发工具承先启后的生命，此次改版更注重团队开发与开发方法，不再执着于技术上提升。简单地说，让软件更容易管理比起更容易开发显得重要些，而且企业主管更在意前一点，他们也正是决定掏腰包的人，只有工程师会喜欢后者，只是更容易撰写程序并无法降低人力成本。VS2005重要改变是平台化与涵盖软件开发生命周期，接下来我们将会分析这些改变所带来的影响。

由开发工具到开发与管理平台
VS2005在开发工具部份强化原始程序代码管控与自动化建构的功能，再纳入工作项目追踪、项目入口网站与报表等管理功能，整合成软件开发团队协同运作所设计之共通平台。

由程序撰写到软件开发生命周期
微软本身为开发工具供货商，在整合式开发环境发展历史中也创下许多革新，包括可视化设计、主从式架构与分布式架构，虽然也为微软培育出百万名以上的.NET程序设计师，但这些阶段的演进都离不开程序撰写的范畴，转入VS2005后迈向另一个转折点：软件开发生命周期，让单一产品实作抽象的软件工程方法论。

＂何谓好的软件？＂
Ian Sommerville在「软件工程（Sofware Engineering）」一书中提到，所谓的好软件必须具备以下4种性质：

VS2005为落实软件开发生命周期与流程管理，而明确区分角色（但同一人可担任多种角色）与权责，让企业重新调整组织结构，却可能带来额外的人力负担，以及信息共享的困难。

角色与分责所增加的人力负荷
VS2005采用软件开发生命周期，作为企业在选择信息系统发展方法论（System Development Methodology）时的标准流程，其特征是将开发流程区分为几个连续阶段（3个~20个不等），标示着不同的系统发展成果，实作时则配合专门的技术角色（分析师、架构师、开发人员、测试人员与项目经理等），目的是容易管理、分层负责与确保软件质量。VS2005则在软件开发生命周期中定义出区分架构师（Architect）、开发人员（Developer）、测试人员（Tester）与项目经理（Project Manager），并将软件依角色区分为3种版本：Team Architect、Team Developer、Team Tester等，项目经理的权责则包含在Excel或Project上，可与Team System整合。

以工具区分角色的做法对大型开发团队而言，终于有对应的专属工具，但对中小企业而言，通常由一人扮演多种角色，而不同角色下工具却能强迫兼职的人不至于混淆工作，以致于难以追踪工作进度（这是造成中小企业软件项目常「重工（Re-work）」的原因）。

另一点附带的优点是应用软件生命周期对中小企业主管而言，仍是艰涩的观念，但微软却可以透过功能与版本的区分，再加上整合，使初学者跟着工具所规范的功能，即可以完成软件开发生命周期。

角色与分责是软件工程化的精神之一，我们可以用半导体制程的方法来比拟，生产线将晶圆的制作手续上区分为黄光制程、薄膜制程等，各制程紧守着本身的生产责任，达到整体流程标准化（SOP），而制程整合工程师负责排除制程缺陷问题，并确保高良率等。但角色与分责使得企业的开发团队中常一人分饰多种角色的问题，以及人力精简的目标又重回原点。为了角色与分责势必增加人力，但这对企业而言，原本因为信息单位只是消耗预算的单位而精简人力，若为了软件质量而朝向工程化，形成两难的局面。即使敏捷式开发方法能解决人力问题，但企业中开发角色的赋予，并非如工程师所愿。他们常因为主管的临危受命下担任救火队的角色，使得角色混淆问题严重，VS2005虽立意良善，但企业势必在现实与工具间取得平衡点，而且还要取得所有成员的共识，否则万用的瑞士刀只是用主刀来切水果，不免大材小用，而且这样的状况下，VS.NET 2003已能应付需求，不需要升级到VS2005。

团队协同作业难以沟通与培养默契
如果VS 2005只是区分版本，那么过于小看此次改版。软件开发生命周期注重反复式的过程，以逐步提升软件质量，而在反复改进过程扮演开发方向控管的操舵手：项目经理，不再置身事外。VS2005此次也针对项目经理开辟专属的工具：Team System，让项目经理与开发人员因为使用共通的工具而使用共同的语言沟通，不再像是局外人。

Team System也让开发工具转为开发与管理平台，让开发人员可以分享资源，更重要的是让项目经理可以从集中式平台监督软件项目。以往开发工具为单机版时，各成员的工作成果均保留在个人计算机，项目经理仅能透过威胁利诱的方式，才能汇整各成员的成果成为项目进度，但此时项目经理不但被架空，而且形同虚设。

为了管理创意成果供货商莫不绞尽脑汁，像Borland便在StarTeam产品中内建Repository（中央储存库），这是一种中央控管的数据库，用于有系统与结构化地储存软件开发过程的各式数据、图表与程序代码等。微软则在Team System连结SQL Server 2005达到相同的功能，而且N-Tier架构强迫软件工程师在开发过程便进入项目控管，而不是写完程序后才决定要不要归建到项目档中。这让开发更有效率，也让软件工程师专注在程序开发上，而不是与管理有关的琐碎、例行事务上。

VS2005触及开发团队合作的痛处，这牵涉到开发人员技术本位与文人相轻的老问题。「软件黑手（俗称Hard Coding的工程师）」与规画架构的架构师不平等的工作任务与负担，以及最后把关的测试工程师所背负的压力，都会在团队中形成各自为政的问题。最常见的是测试工程师与开发工程师难以取得协调，以及资历高于项目经理的资深工程师，对流程与管理的抗拒，特别是这些人掌握旧式语言（如corba语言）或旧型主机（Legacy System）的维护等，使得项目经理的权威受到挑战，以及对团队向心力都形成威胁。单从工具的角度无法面对这些问题，然而，以工具要求团队合作只是让问题浮上台面，但企业可能没有心理准备面对这个积弊。

项目进度控管与信息共享矛盾
VS2005实作软件项目管理，并不同于一般我们所谓的项目管理，目前技术上能实践的部份，仅只于与软件工程所要求的软件质量相关的绩核项目，例如原始程序代码或臭虫数量等。

项目入口网站（Project Portal Website）主要是突显出项目管理并非项目经理本身的事，而是所有关系人（Stakeholders）都应了解，随时随地都可看到最新进展。此外，软件开发项目的特性是集合各种技术专精的人员，入口网站有助于分享信息，这在台湾中小企业的信息项目正面临这个严重问题，也就是成员将技术信息藏私，以展现他在团队的地位。James Lewis提出两个建议，能让项目运作更有效率：

1.重要成员拥有较充足的信息时，许多的决定就可以自行处理，不必事事求教于项目经理。

2.信息具有自我组织的特性，当所有团队成员都能一同分享项目经理的信息，并加以使用时，对整个团队的帮助最大。

简单地说，无论是项目经理或工程师，对任何成员蒙蔽信息都会造成不满，并延烧到其它成员而瓦解向心力。微软也注意到信息分享在软件项目上的重要，当VS2005每次新增一个专案，便会对应在内建的WSS（Windows Sharepoint Services）上对应开启一个WSS网站，不仅用于项目现状与臭虫数量回报等。此入口网站也支持Excel与Project（VSTS可取代Project Server），项目经理在指派任务后，将任务分配上传到WSS网站或整合所有信息。现实中，信息部门常因为紧凑的接案与结案等过程，少有喘息空间，遑论有空分享信息与文章，而且入口网站的绩效报告是工作上的无形压力，多数人不会主动面对。

开发流程与创意、弹性的冲突
微软在VS2005工具中用于描绘软件开发生命周期的方法论（Methodology）称为：Microsoft Solutions Framework（MSF），涵盖软件开发与基础环境部署等完整流程的中介模型（Meta-Model）。VS2005内建两种主流的流程模板，分别是MSF for Agile Software Development与MSF for CMMI Process Improvement。顾名思义，前者适用于小型团队所使用的敏捷式开发流程，讲求测试与原型（Prototype）、较短的开发循环与持续整合等；后者则适用于大型开发团队，注重严谨的开发流程，并符合CMMI（Capability Maturity Model Integration）Level 3的要求。

开发工程师的毛病是技术本位，缺乏管理的思维，当然也缺少被流程制约的性格。另一个问题是他们常被项目挤压时间，而这些项目都是主管为了利润而接回来的，此时，他们会为结案而牺牲各阶段性流程上所需的报告、文件等成果，并视为末枝小节造成流程混乱。人们都知道工具是死的，但遵守制度考验着成员间的默契。

微软因Visual Studio曾培养大量的.NET开发工程师，但每次改版都让开发人员再三踌躇，这样的市场响应会不会重现在VS2005上，也等待市场发酵，毕竟，只有微软知道下一版的VS2005所有外貌。此外，此次改版已让软件开发回归信息教育的基础课程，也就是信息管理与软件工程，但微软本质是商业公司，由它来教育企业用户，不禁让我们思考信息教育的问题。

供货商本身利基市场的冲击
不可否认地，微软发表VS2005与SQL Server 2005确实为市场带来创新的改变与价格上重新洗牌的效应，甚至对同级产品供货商带来营运上的危机。

微软本身为软件产品供货商，本身研发产品获利最大的，应是与它本质相近的厂商，以及系统整合厂商。从供货商所提供的工具角度来看，微软将开发工具转为平台化，最主要是后续能整合更多自家的产品（例如Project产品），搭配销售以使得产品销售量再创新高，加上一些营销手法包装即可。但我们不禁要思考一下，有时候产品整合确实有加值或加乘的效益，以VS2005而言，将开发工具导向团队开发与开发方法论，的确是良好的方向。只是，软件开发并非单靠工具即可解决，否则软件工程在信息科学教育这么多年以来，以及大专院校每年近8万名的毕业生，也未替企业解决太多信息架构上的问题。

此外，软件开发本质上还是创意重于标准的领域（操作系统的演进正是例子），也因此软件项目与开发本身都必须因时与因地而制宜，这也不禁让我们想到，到底软件开发是否可工程化？别忘了，本地的企业并非纯然地是软件厂商，应用软件都只是辅助商业的工具，而非核心。简单地说，在这些企业内还有许多复杂与非信息的问题影响着软件项目，而且决策的主管也非信息技术出身的人，以致于软件开发方法论究竟能为他们解决多少问题，尚不得而知。这一点，我们也可以从近来Web Services这个技术叫好不叫座的现况看出一点端倪。

企业对开发工具的导入看法，总是抱持着「内行者看门道，外行者看热闹」的心态，我们相信VS2005带来的便利对使用工具本身的软件工程师感受最深，但他们通常没有决策权，充其量只是重要意见参考的幕僚，但有决策权的主管究竟对软件工程的概念了解多少，影响着VS2005的销售成绩。而且，软件项目开发是团队整体协同且和谐地合作才能导致成功，从主管到基层工程师都必须有共识，而软件工程只是扮演纪律上的规范而已。只是本地的主管必须同时被教育软件工程与软件项目管理的重要性，则VS2005才能发挥综效，这是微软本身受到自家产品创新后的冲击。

许多软件产品都是由规模不大的软件团队所开发的，所以极仰赖成熟的技术，对最新的技术保持保守的心态，不敢冒然引入。此外，这些企业也没有足够的人力、物力作尝鲜的风险。许多技术人员常抱怨软件项目主管在关键时刻作出错误的决策，而导致软件步向失控的危机，这也是人月神话一书中，焦油坑问题持续存在的原因。举例来说，主管常与客户在茶余饭后的应酬中便决定软件功能甚至架构上的变动，通常这时候软件项目的负责人（资深工程师兼任）不会在这种场合出现，只能事后被赋予更改的任务，当变更无法获得开发工程师认同而抗拒时，软件项目便失控了，这些问题并无法从工具中内建变更管理就可解决的问题。

微软的VS2005创新的功能确实为软件开发带来新思维，但当这个工具抛入市场后，使用者的看法与应用效应，也将对微软带来冲击后的思维，也就是 本地的软件开发是否适合以被教育的方式，还是供货商本身应在工具发展上具备更因时与因地制宜的弹性，也许开放源码下Eclipse与PHP的成功，也说明着开放下弹性重于创新的技术。

这些新功能的重要改变，在于项目管理与软件工程的改变，受益最大的是软件项目经理，他们终于有量身订作的工具，但这些主管也常是技术人员抱怨的对象，无论是客户或受委托的厂商都是，VS2005导入后，等于把强大的工具交给外行人。

VS2005唤醒软件基础教育的问题
软件工程将软件开发生命周期视为重要的起步，但软件工程属于信息教育基础之一。如果现今软件开发与维护所面对的问题，必须由微软等这类厂商在工具中内建模板，反客为主来教育企业中的开发人员，那么我们确实得思考长久以来，信息教育讲究速成的严重问题。企业主管面对软件质量不佳，软件项目高失败率等，却也不愿意投资成本以提升软件工程师的素质，那么VS2005只会是舒缓疼痛的止痛药，而非根治的良方。当然，身为与微软同样是工具供货商势必受到市场冲击，而工具更注重团队合作与项目管理层面，势必挤压传统撰写程序代码为生的「工匠」，但微软引发的效应成为各厂商效法的对象，而逐渐成为业界标准时，在不久的将来软件工程师将更仰赖工具，更少创意。窗口环境搭配鼠标使办公室作业人员几乎无法独力解决窗口环境下的错误讯息，不正是最好的例子，操作便利性为企业带来更高的工作效率，却在日常维护上面对人力、物力增加的隐形成本，而VS2005会不会在此波冲击下带来更多隐忧？

VS2005改变软件开发方法论，希望由操作工具而熟悉软件工程，但最终还是让企业导入软件开发生命周期，这需要时间证明。此外，过程中也引导出以前不受重视的测试工程师角色，也让企业在拔擢人才上受到考验。

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

VS2005的方式是反转整个过程，由工具、流程，再回归理论，企业只要依工具的功能按图索骥，就可以达到部份的软件工程的目标，满足速成教育的现状。而且VS2005更重要的作法是在一种工具，不同于其它解决方案，必须依各工程搭配各种工具，还有整合上的问题。这也使得软件工程有更快的实践管道，至于会不会让软件工程风起云涌，还有待观察，其效益也有待发酵（长期以来，可能因为基础教育不足，造成人们质疑软件工程的效益）。

软件质量保证人兼无名英雄：谁来担任测试工程师
在微软过去的开发工具缺乏测试部份，测试工具直到现在才内建在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位系统上除错。

微软希望藉由Visual Studio 2005 Team System，建构完整的软件工程及软件生命周期管理架构，也推出精简的Visual Studio Express版，企图以商业软件的质量，挑战免费软件市场。

Visual Studio Express版包括Visual Web Developer 2005 Express、Visual Basic 2005 Express、Visual C# 2005 Express、Visual C++ 2005 Express及Visual J# 2005 Express五个版本。

微软在Express版初次曝光的时候，宣布在2006年11月6日以前，这一段有限的时间内，提供免费的下载服务。但是从2004年6月提供第一个Beta版本以来，无论是产品下载或注册的数量，都大大超过微软的预期。

尤其最近三个月，平均每月都超过250万人次下载。因此微软开发工具暨平台推广处产品营销经理胡德民表示：「微软决定将在2006年4月22日，正式宣布Visual Studio 2005 Express版永久免费。」这对学生及初阶工程师绝对是「利多」的消息，可以由完全合法的管道，取得Visual Studio学习与熟悉.NET程序开发。

企图反扑LAMP热火
ASP.NET和VB.NET是目前.NET使用者最多的族群，因此，Visual Web Developer 2005 Express版和Visual Basic 2005 Express版，是微软Express版主打的产品，J#因为开发族群偏少，所以并没有推出Express中文版。

在Express版安装的过程中，会自动「顺便」下载安装了SQL Server 2005 Express版，微软藉由搭配Windows操作系统、IIS、SQL Server 2005 Express版与Visual Web Developer 2005 Express版的组合，希望可以力抗LAMP（Linux/Apache/MySQL/PHP）热火。

令人好奇的是，微软所谓每月250万的下载人次是什么「成份」？Visual Studio Express版只能安装在Windows平台，即便免费，对于非Windows平台的使用者，Express版仍然没有诱因。

访问多位开放源码界的使用者，发现他们对于Express版完全免费的消息，几乎都是「有听没有到」。反倒是资策会针对有意愿使用Viusal Studio 2005的人，推出两天的体验营，课后赠送Express版光盘反应不差。可见，微软与LAMP族群显然是「两个世界的人」，Express版俨然成为.NET使用者的「体验」光盘。

开放源码族群：「免费」不是重点
当开放源码族群被告知微软推出Visual Studio Express版，且即将宣布完永久免费的消息，多数人的第一个反应是：「Linux、Apache、MySQL不都是免费的吗？」朱仲杰直言：「免费不是重点，如果工具不错，花钱买也是值得。」

目前采用WAMP（Windows/Apache/MySQL/PHP）解决方案的佳音英语信息部副理胡一夫表示：「会采用AMP的第一考虑是『稳定』。」早期使用IIS当机率比较高，佳音英语全国拥有两百多间分校，目前透过Apache HTTP服务器，每天登录约两千笔的订单或活动报名表都相当稳定，现在主机几乎只有每月例行维护的时候才会重开机。

由此看来，微软试图以ASP.NET搭配好用又「免费」的工具，吸引PHP的族群，但结果似乎不太奏效。Visual Web Developer 2005 Express版只是工具，而PHP是程序语言，比较的基准，应该是ASP.NET与PHP。事实上，PHP也有许多免费或付费的工具，例如Zend Studio，不过，「好用的工具」对LAMP族群似乎不具致命吸引力。

更简单地说，如果使用者选择了Linux平台，就不可能搭配ASP.NET。开放源码族群不可能因为一套免费的工具，就改弦易辙使用Windows平台，所以此举并不容易撼动平台的版图。

不过，对照网华科技总经理曾守民的说法：「ASP开发者到ASP.NET是有学习门坎的，反而PHP比较容易上手。」所以，诱使目前仍停留在COM与ASP的使用者，藉由Express版的免费体验，升级到.NET平台可能会有不错的效果。

Express版的限制
虽然.NET族群对Express版抱持颇正面的看法，不过，汇集开放源码族对Express的想法，可以看出Express版对既有LAMP族群的反扑，显然是扑了个空；然而，对初学者及尚未对平台作出选择的工程师，有可能发挥牵引的作用，因此，值得观察长远的影响。

此外，两阵营不约而同的都很关心与好奇：「Express版能做到什么程度？有哪些限制？会不会绑手绑脚？」针对这个问题，微软也提出功能比较表释疑。详细解读Express版与付费版本的差别之后，我们列出Express版的「十不一没有」，由前3个「不」即可发现微软锁定Express版在初学者及非商业用途。

除了功能的限制，微软也阻断协力厂商加值Express版的机会。Express版确实呼应了众人的疑虑－存在许多绑手绑脚之处。在重重限制的情况下，企业除了利用Express版来「练兵」，还是可以试图从限制中摸索出足堪应付之企业级应用。

＂十不一没有，洞悉Express锁定非商业用途＂
1.不能远程除错：限制本机开发与除错。

2.不能远程访问数据库（Visual Web Developer 2005 Express版可）：主从架构的应用，限制只能存取本机数据库；Visual Web Developer 2005 Exress版是针对Web开发，内建的Web Development Server是开发与测试的网页服务器，也是只能存取本机的数据，不过部署到IIS以后，想当然尔是可以远程访问数据库，否则就「Web」不起来了。

3.数据库设计工具不能提供远程「数据连接」节点：存取数据库都限定本机，数据库的设计当然也限本机。

4.不能支持Office开发：关于企业最常见的Office整合应用－汇出/汇入数据至Excel，再进一步制作成报表，Express版只能谢谢再联络。

5.不能远程部署：Standard以上版本开发的主从架构应用程序，提供ClickOnce机制，让使用者可以延用Windows Update的操作模式，由系统自动比对及下载更新程序，减少版本更新的困难度。Express版有劳手动「复制/贴上」！

6.不能开发行动装置解决方案：无法开发PDA、智能型手机应用程序。

7.不能整合SQL Server 2005：无法使用Express版撰写Stored Procedure（预存程序），也没有相对应的测试和版本控管功能。

8.不支持64位编译：Visual Studio Team System才有的功能。

9.不能协同开发：连远程除错与数据库联机都不行，当然不能协同开发。

10.不能软件开发生命周期管理：请购买Visual Studio 2005 Team System。

11.没有Windows XP Style控件：没有可设定主题、颜色及渐层等外观的使用者控件（这只关乎系统的美丑，应该算是影响最小的）。

＂Express版关闭加值界面＂
看了「十不一没有」，不难发现Express版可应用的范围缩小很多，其实还有更重要的一重限制－Express版关闭了加值接口（Add-In API），这才是影响最大的关键。这点在.NET阵营的使用者现身说法中，江姓工程师也提到：「在Express版中虽然可以外加第三方合作伙伴控件，但不支持附加组件，企业仍必须购买Standard以上版本。」

「关闭加值接口」就是协力厂商无法加值Express版的整合开发环境，例如单元测试、重构、程序代码控制及负载平衡等管理机制，都可算是整合开发环境的加值功能。若不能直接在Express版内额外加值各种多样化的功能，那么就无法创造类似Eclipse背后庞大的加值社群，这也是Express版不能打入「开放源码」社群，只能算是「Freeware」的原因。

应用程序的管理机制，对于企业级应用是很重要的功能，缺乏管理机制的影响，是不管主从架构或Web应用程序，从设计、开发、测试、上线到后续的维运，都无法有效掌控，所以就绝对不适合庞大、复杂且关键任务性的系统。

虽然透过外部独立工具管理也是一种解法，但不能整合在开发环境中，相对就增加了管理的复杂性，并降低工作效率。盘算起来，倒不如购买Visual Studio 2005的付费版本，这就是微软将Express版定位在「学习」用途的真意。

＂可应付有限的企业级需求＂
Web－非关键任务性网站：
ASP.NET是目前最大的.NET应用，而ASP.NET 2.0是.NET Framework 2.0强打的特色之一，Visual Studio 2005针对ASP.NET 2.0增加许多关于数据处理及网站设计的使用者控件，透过鼠标拖拉点放，就可以设计网页的基本架构、主题、色调，甚至完成具新增、删除、修改、浏览甚至排序功能的数据表，大幅提升网站设计的效率。

Visual Web Developer 2005 Express版对于中小企业、社团或个人工作室，用以快速建立应用单纯的网站，还算是合用。

主从架构－单机版的作业：Visual Basic、C#或C++的Express版，因为不能远程访问数据库的限制，适合单机版的应用。以中小企业为主，对许多微型企业而言，「All in One」是很常见的情况。

再者，大型系统运用Express版作为小规格功能的独立开发与测试，仍然可以节省开发工具的成本，只不过后续程序整合后的除错与管理会比较麻烦。不过，实情是很多企业是使用盗版的Visual Studio，所以本来就没有所谓开发工具的成本，这也是微软不明说，而你我都心知肚明，Express版不会冲击Visual Studio营收的真正原因。

利用在线论坛，可享免费客服
免费工具最令使用者担心的是，未来使用上的问题找谁解决？或者，是否暗藏庞大的服务成本？

胡德民说：「微软要求50位以上的技术人员进驻『微软在线论坛』协助客户克服问题。」其实不只是Visual Studio，只要是微软相关的产品与技术，都分门别类有专属的讨论区，微软使用者可以善加利用这个免费的客户服务管道。

微软面对的终究是「信仰」问题
虽然微软释出了免费的善意，并希望藉此推广.NET技术。不过.NET使用者视Express版为免费「试用」及「体验」的好途径；而开放源码界却视其为「邪恶帝国的阴谋」。所以Express版除了平台及功能的限制之外，还是得面对「信仰」意识型态作祟的问题。

相信未来两派人马的过招，必定像一出精彩的肥皂剧，在各说各话、各唱各调的情况持续纠葛下去。虽然各界对Express版的结论还是「天下没有白吃的午餐」，不过这毕竟是微软「开放」策略的第一步，即使非Windows平台无法享受到免费的好处，至少Windows使用者多了一个免费的选项。至于后续是否引发平台转移的效应，拭目以待。

「免费」不是重点
如果只是为了免费而用，过两天又有另一套免费更好用的呢？如果工具真的适合，就算花点钱也会买。Visual Studio Express版是工具，但Java和PHP不是工具。若是选择Windows平台，那么搭配微软的解决方案是明智的抉择，因为跟Windows的整合度比较好，其它的工具在整合度一定没有它来的好，但可能的风险是你也许将无法再习惯使用别的工具，因为它已经把你给宠坏了。
微软推Express版，对Windows平台的使用者来说是好的；但Linux使用者不可能因为一套免费的工具，就跳到Windows平台。

?
关乎信仰问题
微软免费的举动，应该会吸引到一些学生，以及准备初学微软解决方案的工程师，不过却很难吸引到已经采用LAMP解决方案的族群。或许是一种习惯，也是一种信仰，纵使是免费提供，毕竟仍不是属于真正「自由」的开放原始码。
另外，以现有的状况来说，使用Linux的族群，就不会想使用.NET解决方案，纵使.NET可以在Linux上面执行。现有的PHP套件与系统在开放源码的领域，到处可以找到相关的解决方案。更何况，无论Apache vs IIS、MySQL vs SQL Server等比较，往往让大家感慨：微软不过是把操作接口设计得更友善和简单罢了。但是，使用者是否会因为微软的开发工具是免费的，而转向到微软阵营，我想短期之内不会。
?
　 　
开放源码项目.NET不吃香
如果可以大幅缩短开发时程，会想试用看看。不过，从技术成熟度及稳定性各方面来看，目前AMP还是占优势，不太可能立即移转到.NET平台，不过，未来新的应用可以尝试。

从另一个角度分析，在Sourceforge.net和Hotscripts.com网站上，有很多开放源码项目，其中以PHP最多，提供非常多强大的函式库(如:ADOdb、JpGraph、Ming等)，即使经验不足的程序设计师，搭配这些函式库之后，也能快速的呼叫各种数据库、画出专业的图表、直接产出flash动画档案或PDF格式的档案等，并可视实际需求再修改函式库，相较之下.NET的分享就很少。从这方面来分析，选择.NET建构项目，不见得比较吃香。
?
　 　
免费的吸引力不大
以往的Visual Studio在安装时实在太费时费工，不知Express版如何？免费的SQL Server与IIS也没有用，因为这两者都太不安全，加上大部分的厂商是以Oracle为主要数据库，服务器也不会用IIS。Java社群拥有许多开放源码的好用工具，既免费又可以依照需求客制化，微软想用「免费」当噱头，吸引力似乎并不大。
免费的背后，可能是更为庞大的售后服务。　

没时间学新的语言
项目从形成、规画、开发到维护，是很长一段的时间，要摧毁Linux项目并不容易。况且已经上手的开发技术，没时间也没必要再学一套新的。虽说微软强调拖拉点选就可以完成许多事，但实际上都需要微调，而且工具产生的程序代码像怪兽，反而不易修改。

有助于.NET技术的推广
采用PHP的中小企业为数众多，所以微软推出Visual Web Development 2005 Express版应该有助于.NET技术的推广。
我认为微软更大的野心，是为后续的.NET平台铺路。因为未来的Vista与Longhorn操作系统，将以.NET为核心，而现阶段仍在使用COM与ASP技术的企业，势必要在.NET、LAMP或Java之间抉择，再者，ASP到ASP.NET 是有学习门坎的，因为加入对象导向的观念。相形之下， PHP反而容易上手，所以Express也是企图留住既有Windows使用者。

　 　
功能限制显得诚意不足
在微软推出免费IDE前，Java 阵营因为Open Source IDE，如 NetBean或Eclipse的开放架构，有不少第三方合作伙伴，加入开发不同控制组件及附加组件，让开发的内容越来越丰富。而在Express版中虽然可以外加第三方合作伙伴控件，但不支持附加组件，企业仍必须购买Standard以上版本。所以Express版本功能上的限制，相较于真正「Freeware」的精神，诚意仍显不足。
若谈对.NET阵营本身的冲击，事实上，很多.NET开发者是使用盗版，所以应该没什么影响。不过，对企业的信息单位而言，Express也许是不错的消息，因为企业比较重视版权问题，可以先下载来「Try」一下新技术。

　 　
　
可降低成本，增加学习机会
Visual Studio Express版永久免费的策略，将让微软在IDE市场从 Freeware（Visual Studio Express）到团队整合开发工具（Visual Studio Team System）都有齐备的方案。Express版让企业可以大量减少开发工具的采购成本，一般应用软件开发者用Express版，只需采购少数Professional或Team System等进阶版本即可。
此外，Express版本对于学生团体或个人工作室来说相当方便 ，足够应付学习和个人设计。学校也会因成本的降低，而大幅增加使用及教学的机会。再者，Express提供使用者试用的机会，软件包也可以内附，客户就不用额外购买.NET开发工具。

　 　
多了试用的管道
Visual Studio 2005与Visual Studio 2003相差很多，程序设计的新手如果未使用过Visual Studio 2003，就要直接使用Visual Studio 2005，在刚开始接触时，可能是一大负担。
Express版是属于轻量级，相较于Visual Studio 2005更易使用。我觉得微软是想针对网站的热衷人士、业余人士、学生、初学者，及一些站在.NET与Java之间，正考虑该使用哪一种环境的中立派人士，所特别开发的产品，透过「试用」的机制，进一步了解Visual Studio 2005的功能，增加选择.NET的机会。　

VS 2003到2005的跳板
Visual Studio Express 版进入门坎较低，诸如初学者、学生及SOHO族，都可以藉此快速适应与学习，且能与Visual Studio 2003相容并存。因此对于熟悉2003版的开发人员，可以在既有的开发环境中开发产品，亦可在Express版学习及适应新的工具。熟习Express版后，未来就能快速地转换使用支持高阶功能的Visual Studio 2005。因此，以.NET平台为主的企业，在不影响既有的开发环境下，利用微软所提供的试用机制，选择适当时机升级到Visual Studio 2005，是可考虑的方法。

微软整合SQL Server 2005与Visual Studio 2005倒不是顶新鲜的创举，Oracle早在2004年年底即率先针对Visual Studio 2003，推出Oracle Developer Tools for Visual Studio .NET，用意在提供.NET平台的Oracle用户，整合于Visual Studio的数据库设计与管理工具，甚至可利用.NET开发Stored Procedure（预存程序）。相信Oracle在不久的将来，也会针对.NET Framework 2.0推出更新的开发版本。

Stored Procedure效率佳，但与厂商紧密捆绑
站在程序开发者的立场，数据库与商业逻辑分开，数据库纯粹储存数据，程序开发交由应用程序处理比较单纯；但从DBA的角度出发，系统归系统，数据的处理由数据库负责比较好。虽然两者看法分岐，不过，Stored Procedure贴近数据库引擎，执行效能较佳，况且数据确实有预先处理的需求，透过程序远程处理不仅耗时，而且有网络断线造成执行失败的风险，因此，实务上Stored Procedure有存在的必要性。

Stored Procedure有以下的好处：
1.模块化的程序撰写：只需建立一次Stored Procedure，储存在数据库中，就可以让不同的程序呼叫。

2.执行效率佳：如果需要大量或反复执行的数据处理，Stored Procedure的执行速度会比T-SQL程序代码的批处理快。因为 Stored Procedure 是在建立的时候进行剖析和最佳化，所以执行一次以后存在内存中。而程序代码则是每次执行时都要反复地从客户端传到服务器。

3.减少网络流量：即使是好几百行T-SQL程序代码的作业，也只要透过一个指令就可以执行Stored Procedure中的程序代码，而不必在网络上传送几百行程序代码。

虽然微软的T-SQL或Oracle的PL/SQL，都兼容于ANSI-SQL，但毕竟不是标准，两者都是厂商专属的数据库程序语言，所以，只要选择撰写Stored Procedure，就是紧密捆绑的开始。不过，除非有不堪使用的重大理由，否则企业选定应用程序搭配的数据库，少有更换的情况，所以效能与捆绑的衡量，是视应用而定。

以T-SQL或.NET开发Stored Procedure各有利弊
单就SQL Server而言，Visual Studio 2005与SQL Server 2005整合，明显的好处在于开发数据库程序，例如Stored Procedure或Trigger可以纳管。过去，Stored Procedure必须部署到数据库「执行看看」，才知道有没有问题，而且Stored Procedure就像一般程序，档案可能被别人修改或不小心被覆盖，因此有管理的需要。透过Visual Studio的控管，对于SQL Server的管理确有正面的效果。

如果企业采用T-SQL撰写Stored Procedure，SQL Server 2005已附赠一套精简版的Visual Studio，DBA不再需要使用阳春的文字编辑器撰写Stored Procedure，可享有开发、测试及版本管理的好处。

若搭配Visual Studio 2005，可使用C#和Visual Basic撰写Stored Procedure。事实上，利用通用性程序语言撰写Stored Procedure，微软不是原创，Java的SQLJ也是对等的设计。

SQL Server 2005的核心已由.NET Framework 2.0改写，因此，以Visual Basic或C#开发的Stored Procedure好处包括：
1.编译成为DLL（.NET Managed code Assembly）的Stored Procedure档案，执行在原生的.NET Framework 2.0平台，预估效能会比T-SQL好，尤其是大量循环和字符串处理的应用。

2.由于T-SQL是特定用途的程序语言，无法表达复杂的逻辑，所以即使是简单的字符串处理或数字计算，可能就要写数十行的程序表达；改由通用性用途的C#或Visual Basic可以大幅缩短程序的长度，也就增加程序的可维护性。

3.相较于T-SQL是SQL Server专属语言，.NET是ISO标准。
缺点一言以蔽之，却很关键：企业可能必须有长期保存Visual Studio各种版本的心理准备。

长远看来，数据库与开发工具的生命周期大不相同，数据库首重稳定与安全，升级的频率不像开发工具那么赶流行，未来可能.NET Framework和Visual Studio都更新了好几个版本，企业的SQL Server还在2005版，而Visual Studio不像JBuilder一样有切换JDK版本的功能。因此，DBA的计算机不管改朝换代了几次，都必须装有Visual Studio 2005，甚至随数据库版本的多元化，必须装有Visual Studio不同版本，而且光盘也不能丢掉。那么情况可能就像现在计算机必须安装着VB 6甚至VB 3一样诡异。至于选T-SQL或.NET的权衡，可能又需视Stored Procedure的应用层面来决定。

升级SQL Server 2005才能享有整合的好处
数据库的工具整合于开发环境，除了便利性，更重要的是数据库的程序开发，终于有了管理工具。过去Stored Procedure「丢上去Try看看」的作法，现在有了测试和版本控管的机制，由此看来，两者确实有相互「抬轿」、彼此「绑桩」的效果。

不过，Stored Procedure到底是延用T-SQL，还是改采功能强大、可以处理复杂逻辑的Visual Basic和C#撰写，就有很多层面的考虑。况且，企业既有的SQL Server是否升级到2005版又有很多影响因素，又将陷入一段长考。