了这个行业的技术人员,让他们在项目起动的时候便把重心放在把握功能需求,而不是建立项目范围,直到今天,很多软件工匠在项目起动时便尽量希望能够把握项目的功能需求,一些学者更把如何把握需求当作教育重点来让我们不断培育软件工匠。让技术人员忘记了建立范围的重要性,让技术人员未能发挥本身的智慧,为客户建立所需的解决方案,让这些工匠不能够有效地考虑如何利用科技来提供客户期盼的价值,发挥本身的创作力和创思。智能让技术人员不断跟着客户后追寻那些不存在的项目需求。
软件工程在21世纪的挑战
在90年代中期,互联网跟随视窗95的普及开始进入个人及企业的空间。当时我被任命为澳大利亚墨尔本市的一家百货公司建立一套网络销售系统。当时我对互联网的认识相当肤浅,如何完成这个任务对我及整个交付团队是一个考验。
我花费大量精力及时间与客户沟通,希望理解他们建立这套系统的背后目的,在过程中我们共同建立了一套假设的业务流程,因为双方都不清楚顾客在网络的另一端在过程中会有些什么反应,所以我们依据不同的反应建立相当数量的流程。在这套业务流程被客户接受后,我们便能够建立系统的功能需求,能够对系统进行设计及最后完成系统的交付。
当然,这是一个例外的个案,基于互联网的起动,这个项目的投资者愿意投资本人的时间与我们这个开发团队共同建立一套能够为他们的业务带来价值的系统。但不是每一个项目投资者都愿意及能够花费大量的精力和时间来完成有关的流程建设的工作。而且市场的竞争让我们需要在更短的时间完成整个系统开发的生命周期,大部份项目只有短短数月的时间让我们从开始到完成项目交付。那么我们如何能够花费大量时间去建设未来的操作流程才开始进行软件开发呢?
客户是希望我们能够提供一套系统让他们能够有一套操作流程,但技术人员需要有一套流程才能够建立系统的功能需求,那么我们应该先建立流程,继而建立系统,还是应该先建立系统,继而建立流程呢?
从那时开始,我便开始思考如何能够有效建立这种项目范围的方法。初步建立了一套项目结构分解法(Project Breakdown Structure或简称PBS)来建立项目的最终交付。直到2000年,我被任命为加拿大一家银行集团建立零售业务的客户关系管理系统时,开始深入探讨PBS的实际应有方法,最后成为今天的“项目组件分拆法(Project Component Decomposition Method),或简称PCDM。
从七月份开始,我会深入为各位介绍PCDM的应有方法,及PCDM这套方法所带出的一种开发模型“四步软件开发”,希望透过过去的经验与近年研究的成果,让我们能够远离工匠的角色,尽快融入软件工程的专业中。 上一页 [1] [2] [3] [4]
|