没有合适的资源?快使用搜索试试~ 我知道了~
信息系统开发过程概述.docx
0 下载量 161 浏览量
2022-10-24
14:57:43
上传
评论
收藏 185KB DOCX 举报
温馨提示
试读
27页
信息系统开发过程概述
资源详情
资源评论
资源推荐
系统开发过程
□ 五个阶段
各种系统开发方法学在范围、复杂性、完善程度以及方法上有很大的不同。
尽管有的方法学分三个阶段,有的分 15 个阶段,但是每个方法学所描述的要完
成的活动基本上是相同的。本章要阐述的最重要的一点是:最好的方法学是那些
始终把用户考虑进去的方法学。过去的情况是,用户管理人员与信息服务开发组
合作来完成系统的一般功能说明书,然后,由信息服务人员来进行系统开发。现
在,系统开发是各占 50%的比例;因此,用户管理人员应该非常熟悉系统开发的
大体过程,特别应该熟悉他们单位自己使用的方法学。�
系统开发过程可分为五个阶段来描述。这五个阶段是:�
1.第Ⅰ阶段—系统开始和可行性研究�
2.第Ⅱ阶段—系统分析和设计�
3.第Ⅲ阶段—程序设计�
4.第Ⅳ阶段—转换和实现�
5.第Ⅴ阶段—实现后的评价�
第Ⅰ阶段—系统开始和可行性研究是在为开发一个建议的系统提供人力和资
源之前完成的。第Ⅰ阶段多数的工作和编写的资料是第Ⅱ阶段的输入。在第Ⅱ阶
段—系统分析和设计期间,系统分析员与用户一起工作以编写详细的功能和系统
的说明书。将这些说明书交给程序员,然后开始第Ⅲ阶段——程序设计。在第Ⅵ
阶段—转换和实现期间,一旦软件开发出来,则建立数据文件,转换现有系统,
并且实现新系统。第Ⅴ阶段—实现后的评价。在开始了系统寿命期中的生产阶段
之后,提出(经常被忽略的)实现后的评价要求。�
□ 具体开发过程
下面将逐步地描述系统开发过程。至于具体的细节、相互的影响、方法、形
式等,用户管理人员应该与信息服务经理联系,与他们讨论公司当前使用的方法
学,同时再看看公司内部描述方法学的手册。�
1.第Ⅰ阶段—系统开始和可行性研究�
在第Ⅰ阶段的活动中很少有与其他四个阶段的活动相一致的。此处所提供的
方法包括对于受拒绝后的再次服务请求的方法以及将技术转移可能性的研究合
并到诸过程中这些内容。第Ⅰ阶段最终的产品有两个部分。第一部分是实际的可
行性研究报告,它包含对建议的或改进的系统的描述以及利润/成本分析。第二
部分是系统的初步设计。它对于估价成本和利润是必要的。该初步设计是第Ⅱ阶
段—系统分析和设计的直接输入。�
将系统的初步设计并入可行性研究的依据是,多数可行性研究是以概念而不
是以设计为基础的。如果在描述系统目标上花的时间太少,那么成本估计,甚至
利润估计将是错误的。用概念来指导可行性研究注定会导致成本过高,而且用户
不满意。在系统初步设计上所花费的时间是值得的,即使拒绝可行性研究也是如
此。因为所编写的资料将必然会被证实其他项目中是有价值的。�
下述编号的活动与表 20.9.2 的系统开发责任矩阵相对应。�
(1)提交服务请求�
图 20.5.1 说明了包括对受拒绝的请求再次请求处理的一种方法。所请求的
服务毕竟是用户做的,因此,应该由用户着手进行。我们鼓励用户管理人员请求
信息服务人员的帮助,但是应该再一次强调,业务领域的管理人员应该对各种大
小的服务请求都提供合适的资料。� (2)估价服务请求�
正如在责任矩阵中所注释的那样,信息服务管理人员只能承诺小的项目(由
公司的方针所确定的小项目)。�
(3)指定可行性研究组�
信息服务经理和用户经理共同来指定适当的混合的人选以组成可行性分析研
究组。该组至少由一名系统分析员和一名用户代表组成。可行性研究组的大小取
决于可行性研究的范围和时间限制。�
用户代表应该熟悉当前专业领域的所有工作,用户经理、总经理助理,或专
业领域分析员是合理的候选者,用户的系统分析员,具有计算机信息处理基础知
识的情况已经越来越普遍了。�
必须指定一个人担任可行性研究组的组长,哪怕只是两个人的可行性研究组
也需要一个组长。直到 1980 年为止,多数的可行性研究组和项目组是由一个高
级系统分析员或一个项目负责人来领导的。在信息服务部门中,这两种人是固定
分工做这项工作的。目前越来越多的公司采取这样一种政策,即由用户担任项目
组组长。这种将主要责任下放给最终用户的做法将进一步鼓励用户参与系统设计。
在这种政策上取得成功经验的那些公司已经指派了一些具有杰出管理经验和具
有某些计算机和信息处理知识的用户人员担任项目组组长。在任何情况下,组长
必须对该组的工作有一个总的安排。如果要求一个用户代表既作为可行性研究组
或项目组的组长而同时又要求他继续履行业务领域的职责,那么该项目是肯定要
失败的。有好些公司已经采用了一种政策,即自动地指派受系统影响最大的业务
领域的经理作为可行性研究组和项目组的领导以后该经理将从原来的工作职责
中解脱出来,而用他(她)的全部时间管理可行性研究(或项目)组。这种人事安排
已经成为当今的主流,其困难是用户经理需要离开原来主管的业务部门少则两个
月多则三年后才能回他原来的工作岗位上。�
(4)标列约束条件�
在系统开发的过程一开始,可行性研究组与信息服务人员和用户经理密切合
作标列出设备、成本、进度、规程、软件以及操作上的约束条件。它们可能限制
建议的系统的定义和设计。�
(5)整理现有系统的资料�
整理现有系统资料的主要理由是:如果可行性研究组不充分了解现有系统,
那么他们就不可能有效地完成所建议的系统的初始设计。已经建立起来的多数人
工系统并没有经过真正的设计。在这些系统中,必须从手稿整理出资料。如果一
个建议的系统是改进一个现有的计算机信息系统,那么可行性研究组只需要保证
现有资料的完整性和保持最新版本就行了。
现有系统所形成的任何资料将给设计阶段提供有价值的输入(如果批准开发
该系统)。即便建议的系统遭到拒绝,也能对现有系统提供基本的资料,并且可
能透彻地理解理有系统。现有系统的资料由四部分组成:①系统报告和资料;②
系统数据文件;③系统数据元以及④说明现有系统的数据、信息和工作流程的图
表。前三部分(报告、文件和数据元)可分类如下:
①当前使用的,而且在建议的系统中以目前的形式保留下来;�
②当前使用的,但是修改后才在建议的系统中使用;�
③当前使用的,但是在建议的系统中将被删除而不再保留的。�
例如,列出所有现有的报告和标准的资料,并按上述分类给定一种状态。在
报告上将标明相对周期(如,每天,每周)以及分发范围。�
对于现有系统的所有数据文件都标明有关的存储介质(如,3×5 的卡片,磁
带,马尼拉折纸机,磁盘等等)以及存储方式。例如,一个名字一地址文件可以
存储在许多张 3×5 的卡片上,并且按名字的字母顺序排列。一个人工系统所保
存的文件数总是令人吃惊的,即便对于业务领域管理人员也是如此。为了完善现
有文件的资料,将每个文件的记录的样式和简单描述附在文件表中。�
系统数据元(即,社会保险号,顾客名,货号等等)是直接列出的,而不必关
系有关的文件。数据元经常在几个文件中重复出现。除了状态指示符之外,如果
数据的名字不能自我说明,则必须对每个数据数据元进行描述。有关数据元的其
他信息还包括更新要求(如,每天,每周,每月,或根据需要更新等等)、来源(如,
代办处,资料,系统,工作人员等等)以及职责(如,部门名和负责更新者的职
务)。图 20.9.3 说明在整理现有系统资料时数据元可能采用的一种典型格式。�
我们通过将系统简化为输入、处理和输出等几个基本组成部分来表示整理现
有系统资料的工作过程。然后用图形描绘出各部分之间的逻辑关系。有多种图像
表示技术来做这件事。最为流行的(尽管不一定是最好的)是流程图。其他的更为
结构化”的技术还有:IBM 公司的层次化输入—处理—输出图(HIPO),汽泡图,数
据流框图,南茜—斯奈德曼(Nassi-Shneiderman)图,渥尼尔(Warner)框图以及判
定表。当前工作过程的图像描述提供了系统的数据、信息和工作流程的一个概貌。
它着重强调系统中控制工作流程的那些数据元。这些图应该刻划人工和计算机的
处理步骤,并且以适当的顺序安排每一处理步骤。通常以能最好地显示出工作过
程的方式来组织和提供这些图。它们可以是由一些随机事件、功能或按小的和大
的周期来驱动的子系统,也可以是若干子系统;既可以是层次的,也可以是混合
的。很少有几个系统是完全顺序的,因此,在多数情况下可以应用模块方法。�
(6)调查研究技术转移的可能性�
为了更好地利用现有的技术,许多公司正在进行将有关技术转移到他们的系
统开发方法学中可能性的调查。鼓励调查技术转移的可能性和(或)可行性的政策
必将带来人力资源的大量节省。特别对程序员和分析员更是如此。合适的技术转
移将使这些人的工作集中于还没有现成软件的特定行业的应用领域。�
技术转移可能性的调查是从走访那些已经实现的,而且与所建议的系统有类
似规模和工作的系统。可行性研究组还应该调查商品软件目录,以便找到适合的
可应用的软件。如果认为技术转移是可行的,则可行性研究组说明怎样使用这些
技术以及为适应现有环境所要求的修改范围。�
如果使用标准的方法来进行技术转移潜力调查,那么提出要求的公司应该采
取与具有类似要求的其他公司合作的政策。�
(7)完成建议系统的初步设计�
可行性研究组要走访专业人员以获得一般的系统要求,然后,将这些要求转
换成初步的系统设计。设计过程是交互的,用户经理和可行性研究组需要经常就
设计思想和方法等交换意见,用生动的文字和图形说明来形成建议的系统初步设
计的资料,这些生动的文字(用非技术词汇)描述了所建议的系统的基本工作过程,
而且常常同时附有图形说明。这些文字图表也将列举出那些大大违背现有工作方
式而建议的系统所期望的手续、手段和方法。这些文字图像也将描述建议的系统
与人工系统以及建议系统必须与之兼容的自动系统之间的关系。
图形说明将建议的系统的过程简化为它们的组成部分,同时强调各部分之间
的逻辑关系。�
(8)确定项目范围�
可行性研究组与信息服务人员以及用户管理人员合作估计初步设计中所刻划
的系统的复杂程度。并对开发项目今后的每一个阶段进行人力资源要求的估计
(用户,信息服务人员及其他人员)。此外,还注意到培训和计算机机时要求。�
(9)准备利润/成本分析报告�
一旦完成初步设计并且确定了项目的范围,则可以开始利润/成本分析。不
幸的是,由于用户和信息服务管理人员都希望加快可行性研究阶段,所以,一些
关键的步骤被省略了,因此造成在利润、成本估计上的错误。仅仅根据一种概念
是不可能精确的反映出利润和成本的。设计中的某些步骤是必不可少的。�
另一种在形成公司决策过程中所隐含的错误将不可避免地把那些难以确定的
利润也算成资金收入。当今许多复杂的,综合的系统为公司的利益做出了重大的
贡献,而做到这样程度是因为它们经历了漫长的、不可捉摸和难以预见的道路。
评价信息服务项目的好处和价值是一个主观的过程,它要求具有成本和利润方面
的实际的知识。此外,决策者对于正的和负的不确定的利润要有透彻的理解。使
用美元作为所有成本和利润的统一的计量标准大大地简化了评价工作。那种把不
确定的利润引入盈利图表(为了“建立更好的顾客关系”或“提高威信”)的作法
会造成在“底线”中复合的错误。底线经常被盲目地接受作为一种信条。事实上,
在那种情况下,估价是取最好的情况(理想的)和最坏的(荒谬的)情况之间。然而,
如果将不确定的利润化成美元,那么决策者将以更好的判断代替那种不准确的估
计。�
估价建议的信息系统的最好途径是针对系统净值(收入减去成本)估量正的和
负的不确定利润。为了便于理解不确定利润(例如,增加服务,减少发票上的错
误,加快周转期等),应该产生一个成本和收入的一览报表。�
表 20.9.4 说明如何使用最少的成本类别来表示一次性的和重复使用的成本。
这些成本可由预算中心提出,并且把公司作为一个整体来考虑。成本类别有:劳
力,材料和设备,旅差以及其他各种成本。对于每一类,在第一列指出一次性成
本估计(开发),而在系统寿命期的水平线上指出可重复使用的成本估计(生产)。
公司项目在净值可以从估计收入中扣除成本计算出来,并且根据公司政策对流动
现金打折扣。�
(10)根据可行性研究做出决策�
完成可行性研究后,除了技术补充之外所有报告和资料全部交给信息处理政
策委员会以便实施。技术补充包括准备可行性研究所要求的背景信息。它还包括
一般的系统设计和开始第Ⅱ阶段(系统分析和设计)的一个框架。信息服务政策委
员会感兴趣的主要是初始服务请求、范围、图解说明和利润/成本分析。�
信息服务政策委员会能对可行性研究施加影响。信息服务政策委员会能够:�
①拒绝建议。�
②批准建议并对该建议的开发和实现指定一个最高优先数。�
③批准系统并给它指定一个比最高优先数小的优先数,同时将请求放在所有
建议的系统队列的适当位置(定期检查队列,当所请求的资源可用时,委员会给
当时是最高优先数的项目发出通行命令)。�
2.第Ⅱ阶段—系统分析和设计�
很少有几个项目能在批准可行性研究后立即实现。在得到批准和项目开始之
间的估计时间可能是两年或两年以上。一旦项目获如通行命令,则开始第Ⅱ阶段—
系统分析和设计。在第Ⅱ阶段,将描述所有输入/输出的格式和内容,并且完成
详细的系统设计。第Ⅱ阶段的最后一步活动是准备程序说明,其中包括各种程序
模块的说明书。重要的是牢记在第Ⅰ阶段和第Ⅱ阶段不编制程序。一个普遍容易
犯的错误(经常与系统的质量和运行维护的水平密切相关)是压缩第Ⅱ阶段,使它
提前完成以便开始第Ⅲ阶段—程序设计。粗糙的系统设计必将成倍、甚至三倍地
增长项目所要求的程序设计量。�
(11)指定项目组�
与可行性研究组一样,项目组也应该有一个或多个系统分析员和一至多个来
剩余26页未读,继续阅读
猫一样的女子245
- 粉丝: 95
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0