系统开发过程

2025-06-01 0 0 193.5KB 16 页 10玖币
侵权投诉
系统开发过程
□ 五个阶段
各种系统开发方法学在范围、复杂性、完善程度以及方法上有很大的不同。尽管有的方
法学分三个阶段，有的分 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)根据可行性研究做出决策
完成可行性研究后，除了技术补充之外所有报告和资料全部交给信息处理政策委员会
以便实施。技术补充包括准备可行性研究所要求的背景信息。它还包括一般的系统设计和开
始第Ⅱ阶段(系统分析和设计)的一个框架。信息服务政策委员会感兴趣的主要是初始服务
请求、范围、图解说明和利润/成本分析。
信息服务政策委员会能对可行性研究施加影响。信息服务政策委员会能够：
①拒绝建议。
② 批准建议并对该建议的开发和实现指定一个最高优先数。
③ 批准系统并给它指定一个比最高优先数小的优先数，同时将请求放在所有建议的系
统队列的适当位置(定期检查队列，当所请求的资源可用时，委员会给当时是最高优先数的
项目发出通行命令)。
摘要：

系统开发过程□五个阶段各种系统开发方法学在范围、复杂性、完善程度以及方法上有很大的不同。尽管有的方法学分三个阶段，有的分15个阶段，但是每个方法学所描述的要完成的活动基本上是相同的。本章要阐述的最重要的一点是：最好的方法学是那些始终把用户考虑进去的方法学。过去的情况是，用户管理人员与信息服务开发组合作来完成系统的一般功能说明书，然后，由信息服务人员来进行系统开发。现在，系统开发是各占50%的比例；因此，用户管理人员应该非常熟悉系统开发的大体过程，特别应该熟悉他们单位自己使用的方法学。系统开发过程可分为五个阶段来描述。这五个阶段是：1.第Ⅰ阶段—系统开始和可行性研究2.第Ⅱ阶段—系统分析和...

展开>> 收起<<
系统开发过程.doc

共16页,预览4页

还剩页未读， 继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

相关推荐

更多
立即下载
分类：人力资源/企业管理 价格：10玖币 属性：16 页 大小：193.5KB 格式：DOC 时间：2025-06-01

开通VIP享超值会员特权

  • 多端同步记录
  • 高速下载文档
  • 免费文档工具
  • 分享文档赚钱
  • 每日登录抽奖
  • 优质衍生服务

作者详情

Ta的主页

相关内容

更多

热门标签

人际关系 配电装置 动力学连接体 力的合成 高考理综 全宋诗作者索引 公务员考试
/ 16
评分 收藏
分享
立即下载
客服
关注