IT 专业人员通常使用软件开发方法论，如 IBM® Rational® Unified Process (RUP®)。在各种软件开发规程和垂直行业中可以应用此类方法。软件开发方法（如 RUP 和 IBM RUP 面向服务的建模和体系结构 (SOMA)）可提供发布为 HTML 的静态流程指导。IBM Rational Method Composer 是一种流程工程师用来自定义流程的工具；不过，您可以将新的流程发布为只读网页。
要获得真正有用的方法，需要使用特定于上下文的资产进行扩充。这些资产通常是内容、工具和人员资产。内容资产包括各种资源，如文档、演示文稿、模型、社会书签和其他资源。例如，如果在电话公司 (telco) 的垂直帐户中应用此方法帮助业务建模，则该方法应提供关于可利用的特定工具和内容的指导。
因为发布后，方法内容是被冻结的，所以它不可扩展。因此，您可以通过 Web 2.0 技术使用补充的 wiki 页扩充静态内容，以启用协作编辑和动态 Web Feeds。在接下来的部分中，将这些页称为扩展点。
那么为什么缺乏方法可扩展性会成为问题？因为方法内容：
- 过期；例如，指导构件（如模板、资产或工具使用指导信息）已过时。
- 在不进行自定义的情况下，缺乏特定的上下文详细信息。例如，由于现成的方法内容的不具体性，所以它需要适用于所应用的情形，如组织、行业领域、角色、活动、资产和工具。
- 自定义需要重新发布。
- 缺乏用户或专业人员扩充的能力，因此，无法利用用户对社区内容开发和增强的贡献。因此，通常缺少用户社区的反馈和协作的机会。
- 缺乏利用富媒体内容（如视频、Podcast 和 Flash 演示文稿）的能力，因为它们通常很快会过时。
- 趋向于缺乏详细的商业工具指导。
- 缺乏对组织资产或工具的现成指导。
另一个问题是流程工程部门没有足够的资源产生领域所需的所有方法内容。例如，他们通常不能为同一工具的不同版本提供内容。因此，方法内容始终保持不变，组织无法得到聚集起来的知识和基于实际领域知识来修改内容的专业人员的见解。
注意：其中某些内容通常对组织具有很高的优先级；例如 Insurance Application Architecture (IAA) 模型，它是由 IBM 公司所专有的。
已使用其他技术解决同一问题。请考虑以下事项：管理员或流程工程师可以定期重新发布静态方法（例如，每月、每周和每天）。不过，需要建立流程，将专业人员的反馈或贡献合并到方法。另外，下面的事实会加剧此问题：方法随工具（如 IBM Rational Software Architect）一起发布，并且在更新 Rational Software Architect 之前不能更新方法。专业人员使用最新的信息构建自己的页面，但是这些页面是分散的，不能与方法和流程内容集成。
  |
|
您希望使用扩展来更新软件开发流程和方法，这些扩展是以协作方式构建的，并且可以在专业人员使用方法时以动态方式进行填充。图 1 显示了与此类似的内容。
本文转自IBM Developerworks中国