减低开发过程中的变动依赖项目范围管理[4]

在同一时间开始出现了一些新工具如4GL，和新方法如快速应用开发(Rapid Application Development，RAD)，希望通过这些工具和方法让技术人员与用户能够一起组合出未来系统的功能并达成共识，为投资者建立有关的应用系统。希赛顾问团需求工程首席专家徐锋认为，这些工具和方法误导了这个行业的技术人员，让他们在项目启动的时候便把重心放在把握功能需求，而不是建立项目范围，直到今天，很多软件工匠在项目起动时便尽量希望能够把握项目的功能需求，一些学者更把如何把握需求当作教育重点来让我们不断培育软件工匠。让技术人员忘记了建立范围的重要性，让技术人员未能发挥本身的智慧，为客户建立所需的解决方案，让这些工匠不能够有效地考虑如何利用科技来提供客户期盼的价值，发挥本身的创作力和创思。智能让技术人员不断跟着客户后追寻那些不存在的项目需求。

　　软件工程在21 世纪的挑战

　　在20世纪90 年代中期，互联网与Windows开始进入个人及企业的空间。当时，笔者被任命为澳大利亚墨尔本市的一家百货公司建立一套网络销售系统。当时我对互联网的认识相当肤浅，如何完成这个任务对我及整个交付团队是一个考验。我花费大量精力及时间与客户沟通，希望理解他们建立这套系统的背后目的，在过程中我们共同建立了一套假设的业务流程，因为双方都不清楚顾客在网络的另一端在过程中会有些什么反应，所以我们依据不同的反应建立相当数量的流程。在这套业务流程被客户接受后，我们便能够建立系统的功能需求，能够对系统进行设计及最后完成系统的交付。

　　当然，这是一个例外的个案，基于互联网的启动，这个项目的投资者愿意投资本人的时间与我们这个开发团队共同建立一套能够为他们的业务带来价值的系统。但不是每一个项目投资者都愿意及能够花费大量的精力和时间来完成有关的流程建设的工作。而且市场的竞争让我们需要在更短的时间完成整个系统开发的生命周期，大部份项目只有短短数月的时间让我们从开始到完成项目交付。那么我们如何能够花费大量时间去建设未来的操作流程才开始进行软件开发呢?

　　客户是希望我们能够提供一套系统让他们能够有一套操作流程，但技术人员需要有一套流程才能够建立系统的功能需求，那么我们应该先建立流程，继而建立系统，还是应该先建立系统，继而建立流程呢?从那时开始，我们便开始思考如何能够有效建立这种项目范围的方法。初步建立了一套项目结构分解法(Project Breakdown Structure 或简称PBS)来建立项目的最终交付。从2006年开始，希赛顾问团组织有关软件工程和项目管理专家、学者分析和讨论了PBS的的应用，并对PBS方法进行了不断的改进，最后成为今天的项目组件分拆法(Project Component Decomposition Method，PCDM)。

　　从7月份开始，我们会在希赛网为读者深入介绍PCDM 的应用方法，及PCDM所带出的一种开发模型“四步软件开发”，希望通过希赛顾问团专家们的经验与近年研究的成果，让读者能够远离工匠的角色，尽快融入软件工程的专业中。

原文转自：http://www.ltesting.net