在用户及管理层认同上述的ToR 后，这个项目的负责人便需要估计需要对多少人进行访谈，需要多久时间进行访谈，需要多少时间对访谈结果进行分析，多少时间建立项目需求，编写需求说明书，需要多久进行系统设计，多少程序员及多少时间进行程序编写，如何进行测试，编写系统文档，编写用户手册，什么时候在仓库安装终端，如何连接主机，什么时候进行用户培训，如何让系统取代目前的人工作业等等有关工作计划及时间表。
在系统分析员完成访谈后，便需要依据访谈结果进行分析，理解什么时候知道有货品进入仓库，什么时候更新有关数据，如何更新，采用哪些表单，仓库人员如何决定货品应该存放在哪里，如何记录有关信息，如何知道需要检货，什么时候进行数据更新，如何分别哪些货品要去生产部门或者直接送到客户指定地点等等信息。这些信息便成为系统在不同过程中所需的功能需求。
从上述的开发过程说明中可以体现功能需求并不是客户或用户提供，是系统分析员在理解目前的人工作业后分析出来的结果。
在系统移交到仓库中运行前，仓库中的工作人员需要对系统的操作进行学习及测试。要知道当时仓库的工作人员并不是针对系统的功能进行测试，是对系统能否满足他们的工作过程进行测试。基于这批工作人员对人于工作业的过程十分理解，如果系统未能提供一些他们操作过程中的日常工作，他们会要求技术人员对系统进行修改。这个过程让我们误会用户是对功能需求进行测试，这个误会一直到今天让我们把系统开发的焦点错误地放在功能上，而不是系统的最终交付上。而系统的最终交付是否能够满足ToR 的要求是当时项目成败的主要指标。
系统集成的范围及需求
20世纪70 年代的项目多以部门单独运营为主，自动化的目的是提升部门本身的运营效率进行系统建设。到80 年代，企业高层开始体会企业中的数据分散在不同的部门或子公司的部门中。哪些数据是最新的?哪些是最准确的?应该采用哪个部门的数据做决定呢?如何整合这些数据，如何获得即时的数据，如何利用当时的区际网络(AreaNetwork)，客户/服务端(Client/Server)，遥程存取(Remote‐Access)数据库(Data Base)等科技来更有效提升企业的运营效率呢?这些问题提供软件开发项目进行系统集成及数据分享的工作，最终的目的还是环绕原来自动化提升企业(不单是70 年代提升部门)的整体运营效率为主要目标。
这个时候，简单的ToR 已经不能够说明项目的范围，但可以采用多个ToR 来加以说明。工作说明(Statement of Work)在这个时候诞生，开始取代ToR 成为项目范围的主要工具。一个项目可能有多个Statement of Work(SOW)才能够有效说明项目包含的范围。例如要建立一个 “订单管理系统(Order Processing System)”的时候，这个系统可能包括销售部门，库存管理部门，会计部门，运输部门，生产部门等，这些部门也可能分布在不同的地区。
此文章共有6页 上一页 1 2 3 4 5 6 下一页
文章来源：希赛网
|
Leadge.com首页 > 知识库 