流程的两个理念和两个方法
在过去的几年中，软件社区中流程的方法发展成两个基本理念。两种方法都有相对的优点和缺点。另外，流程的两个独立方法在更大的业务环境内得到了发展，一个与软件行业无关，而另一个则试图创建以软件为中心的流程。
灵活流程模型
灵活流程模型是由一个名为 Agile Alliance 的软件专业人员团体创建的，他们拒绝接受流程比人重要的观念。灵活流程模型获得了成功，但这种方法遭受的主要非议是：它的成就可能更多地取决于相关个体的天赋，而不是该流程模型的效力。
正式流程模型
正式流程模型是在业务环境（大部分在软件开发文化之外）得到发展的。正式方法提供一个公认的框架，但是当应用于 SDLC 时，它会变得很麻烦、很糟糕，可能无法最终产生响应市场并及时交付的高质量软件。
两种方法：独立于软件，与软件相关联
除了上述两种流程模型之外，开发 SDLC 流程的两种方法也得到了发展。一种方法开发独立于软件行业需求的流程，并创立了“一种流程应对所有行业 (one process fits all industries)”的指导。这种流程与软件开发相分离，深深依赖于发布的文本和方法。许多软件专业人员的反应是，问道：“这怎么能适用于我和我的项目呢？”
对创建与软件开发相关的流程的尝试也已经步入到台前。虽然现有的打包流程解决了与 SDLC 相关的问题，但软件专业人员发现它常常提供太多的信息，以致很难为“实际”软件开发所理解并适应。
对于软件专业人员，流程指导最重要的元素是，能够在正确的时间即时提供与工具支持集成组合在一起的正确指导。流程指导的制定是 MSF 的焦点所在，它是 SDLC 中的日常活动密不可分的部分。
从传统方法得到的教训项目经理经常抱怨流程培训费用高昂，而且方法不好掌握。当前这种使用现有工具将流程指导合并到 SDLC 的方法，导致了指导经常与帮助和工具本身产生分离。另外，对于用户来说，映射整个内容的路线不明显。
铺天盖地的内容
现有解决方案中所提供的内容可能不合适、过时且又铺天盖地。目前，这样的内容采用的是“掩埋”法。对于所提供的数量巨大的内容，需由用户对其进行分类，并从中挑选出与特定项目有关的内容。虽然这种掩埋法试图让每个人满意，但最终却无人为之喝彩，原因在于它时而灵活，时而却很笨拙。另外，现有的打包流程指导不容易更新。这经常导致工具帮助、模板和指导之间不匹配。
自定义没有用或不直观
SDLC 流程自定义的尝试难以取得最佳效果。自定义需要首先使用指导，而为自定义提供的示例不够充分且实际使用价值不大。这经常导致指导一经自定义就无法识别。
在现有的打包流程指导中，用户没有自始至终感受到一致的整体体验。要使自定义的流程进入有用的系统，用户经常需要做大量的工作。其结果是，静态流程经常没有随着项目技术与环境的变化而变化。这种静态流程很快就会变得过时，因此也就没有用处。另外，这种自定义流程仅仅相当于一组 Web 页。与选定的工具集相集成采取的是一种特定页面形式，这种页面专门在流程的上下文中使用软件开发工具或部署环境。它很少考虑到流程和工具集之间的所有交互。人们使用这个工具时，必须切换到浏览器去寻找适当的主题。其结果是有断开连接的感觉。
相比之下，流程和工具的和谐统一注定 MSF 有一个高效且集成的方法。在 MSF 中，每个操作都会在流程上下文中捕获到。对某些衡量标准（例如，实际工作与计划工作、测试覆盖与错误修复、代码变动与代码稳定性）可以自动跟踪，无需进行任何额外的工作。数据会作为日常活动的一部分加以收集。流程需要的、在以前很难进行的任务，现在因 MSF 而变得很简单、不显眼、无需费力。
文章来源于领测软件测试网 https://www.ltesting.net/
