整合式开发环境（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种性质：
| 特性 |
说明 |
| 可维护性（Maintainability） |
完成后的软件必须能够对顾客的需求改变进行软件的演进与维护，这是一项非常重要的特性，因为在变动的商业环境中，软件的改变是无法避免的结果。 |
| 可保护性（Dependability） |
软件的可保护性包括可靠性、防护性与安全性。系统发生故障时，可信任的软件不应该会造成实体或经济上的损失。 |
| 效率（Efficiency） |
软件不应该浪费系统资源，例如处理器与内存。因此，效率包含了响应能力、处理时间、内存使用率等。 |
| 可用性（Usability） |
软件必须能够让设计的对象容易使用，不用花太多功夫，这表示它必须有适当的使用接口与说明文件。 |
查看本文来源
京公网安备 11010802021500号