在项目实施过程中，系统分析员会对库存管理全过程进行调查或调研，采用访谈或观察等方法，记录上述范围中的整个工序的过程，每一个数据的更新，参考记录数据的报告格式和任何有关的工作单据。这些工序，数据更新时间和地点，报告打印等工作最后便成为系统的功能需求。这些需求能够让最终用户明确开发人员已经把握了整个工作流程，明确每一个工作的内容，保证完成的系统能够提供库存管理的功能。

　　这段时间软件工程的焦点是在范围确认后的信息搜集(Facts Finding)和需求分析(Requirement Analysis)中。依据PMBOK的论述，我们在20世纪70年代，的确可以从范围的建立带出明确的功能需求，减少开发过程中的修改，降低项目延误的风险。这个模式在我国软件产业发展初期采用，大概是20世纪80年代后期至90年代中期的时间进行自动化过程。

　　80年代的项目范围与需求

　　到上世纪80年代中后期，国外企业的自动化过程已经接近尾声，企业开始整合部门的计算机系统，加上个人电脑开始取代终端，项目多数包括跨部门或跨地区的系统集成、综合数据库应用、远程计算(Remote Access)、网络连接等为项目主体。在这种情况下，传统的ToR已经不能够明确说明项目属于哪个部门，从哪里开始，如何才是项目完结。ToR已经不能够有效地界定项目的范围，所以，我们利用多个工作描述来说明，成为我们知道的工作说明“Statement of Works (SOW)”，其中包括项目开发过程中需要处理(inclusive)的工作说明和开发过程中不需要(NOT-inclusive)处理的工作说明，整合这些SOWs 后成为我们今天所认识的项目范围，利用工作说明以明确的语句来说明项目中包含的每一个工作内容。例如，在一个项目范围中包括的工作说明可能是:“连接A市及B市两地办公室的主机，通过A市数据中心的中央货品库存数据库，为A市工场和B市销售中心提供即时货品存量查询及货品预订功能”。

　　这些工作说明便成为这个工程需要提交的最终成果。利用项目范围中的SOW替代ToR，一个项目可以容许多个SOW来描述系统建设的内容，所有的SOW描述的建设内容都包含在这个项目的范围中。但实际上每一个SOW的结果如何实现，还是需要技术人员透过调查和进行分析后才能够清楚具体的操作该如何实现。每一个SOW的具体操作过程都成为这个SOW的功能需求。整合全部SOW的个别操作过程，才是项目的最终功能需求。

　　简明的说，每一个SOW都是一个小范围，它本身也不是一个需求。我们还是需要通过理解SOW的内容才能够把握这个SOW的需求。每一个SOW可以成为一个独立的项目，“子项目”的名称也是在这个时候诞生。

　　从上述的历程中可以看到，用户或客户告诉我们的永远都不是需求，是客户或用户希望在最后交付物中看到的部分成果，永远不会完整，只是客户或用户的部分期盼、愿景和目标。如果把这些期盼、愿景和目标当作了需求，那么我们永远不能在项目初期建立满足用户对交付物的期盼。需求从来不是用户或客户提供，需求是技术人员依据范围中需要实施的工作过程进行分析后寻找出来可以提交项目最终交付物的结果，然后才能够把这些需求转变成一个软件工程，在项目指定的范围中利用科技达到用户的最终目的。

　　系统集成项目在PMBOK论述的范围管理仍然有效，但在软件工程中能否包含全部SOW是影响范围变动的主要因素，遗漏了一个SOW便会带来范围变动，所以当时的软件工程多以SOW为主，需要客户方确认，只要客户确认SOW后，任何不包括在SOW中的功能便成为范围变动，也是PMBOK中范围变动管理的主要意义。改变范围便需要改变项目基线，增加工作量和项目成本，延长项目工期。我国的软件产业发展从2O世纪90年代中期到本世纪初期才开始进行系统集成的过程。

上一页  [1] [2] [3] [4] 下一页