2023年-信息系统开发过程概述.docx
![资源得分’ title=](/images/score_1.gif)
![资源得分’ title=](/images/score_1.gif)
![资源得分’ title=](/images/score_1.gif)
![资源得分’ title=](/images/score_1.gif)
![资源得分’ title=](/images/score_05.gif)
《2023年-信息系统开发过程概述.docx》由会员分享,可在线阅读,更多相关《2023年-信息系统开发过程概述.docx(19页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、系统开发过程口 五个阶段各种系统开发方法学在范围、复杂性、完善程度以及方法上有很大的不同。 尽管有的方法学分三个阶段,有的分15个阶段,但是每个方法学所描述的要完 成的活动基本上是相同的。本章要阐述的最重要的一点是:最好的方法学是那些 始终把用户考虑进去的方法学。过去的情况是,用户管理人员与信息服务开发组 合作来完成系统的一般功能说明书,然后,由信息服务人员来进行系统开发。现 在,系统开发是各占50%的比例;因此,用户管理人员应该非常熟悉系统开发的 大体过程,特别应该熟悉他们单位自己使用的方法学。系统开发过程可分为五个阶段来描述。这五个阶段是:1.第I阶段-系统开始和可行性研究2第n阶段-系统
2、分析和设计3 .第HI阶段-程序设计4 .第IV阶段-转换和实现5 第V阶段-实现后的评价第I阶段-系统开始和可行性研究是在为开发一个建议的系统提供人力和资 源之前完成的。第I阶段多数的工作和编写的资料是第n阶段的输入。在第n阶 段-系统分析和设计期间,系统分析员与用户一起工作以编写详细的功能和系统 的说明书。将这些说明书交给程序员,然后开始第ni阶段一程序设计。在第VI 阶段-转换和实现期间,一旦软件开发出来,则建立数据文件,转换现有系统, 并且实现新系统。第v阶段-实现后的评价。在开始了系统寿命期中的生产阶段 之后,提出(经常被忽略的)实现后的评价要求。具体开发过程下面将逐步地描述系统开发
3、过程。至于具体的细节、相互的影响、方法、形 式等,用户管理人员应该与信息服务经理联系,与他们讨论公司当前使用的方法 学,同时再看看公司内部描述方法学的手册。1.第I阶段-系统开始和可行性研究在第I阶段的活动中很少有与其他四个阶段的活动相一致的。此处所提供的 方法包括对于受拒绝后的再次服务请求的方法以及将技术转移可能性的研究合 并到诸过程中这些内容。第I阶段最终的产品有两个部分。第一部分是实际的可 行性研究报告,它包含对建议的或改进的系统的描述以及利润/成本分析。第二 部分是系统的初步设计。它对于估价成本和利润是必要的。该初步设计是第n阶 段-系统分析和设计的直接输入。将系统的初步设计并入可行性
4、研究的依据是,多数可行性研究是以概念而不 是以设计为基础的。如果在描述系统目标上花的时间太少,那么成本估计,甚至 利润估计将是错误的。用概念来指导可行性研究注定会导致成本过高,而且用户 不满意。在系统初步设计上所花费的时间是值得的,即使拒绝可行性研究也是如 此。因为所编写的资料将必然会被证实其他项目中是有价值的。下述编号的活动与表20. 9. 2的系统开发责任矩阵相对应。(1)提交服务请求图20. 5.1说明了包括对受拒绝的请求再次请求处理的一种方法。所请求的 服务毕竟是用户做的,因此,应该由用户着手进行。我们鼓励用户管理人员请求 数据和经验来估计中间和最后活动完成的日期。项目组组长必须与信息
5、服务人员 以及业务领域的管理人员密切合作以保证在系统开发过程中在各关键点有足够 的人员。系统开发过程本质上是线性的(一个活动接着一个活动),而且是不难用适当 的准则(方法学)和合理的估计来监视的。表说明了一个典型的信息系统 项目进度表。在活动点上加上三种标志之一以指出该活动的状态。如果情况表明 该活动是不必要的,则在活动号上加一个圆圈。如果一个特定的活动正在着手进 行,则在相应的活动号上划一个对角线。一旦活动完成则将对角线改成交叉线 “义:有时也用甘特表来给出项目进展的图形轮廊。在开始一组有阶段标识的活动之前,要准备一个更为详细的进度表,来单独 安排这些中间活动。对于要求多于两周时间的那些活动
6、将以两周为增量来安排进 度。表20. 9. 9说明了对具有阶段标志E的那些活动的一个详细的信息系统项目 进度表。表信息系统项目进度表+具有阶段标志完成的活动阶段标志活动估计的 开始时间 实际的 开始时间 提前或 推迟的 天数 估计的 完成日期 实际完 成的日期 提前或 推迟的 天数A 1 2 3 4 5 198W. 9. 1 198W. 9. 1 DS 198W .10. 1 198W. 10. 15 12BB678 910 198W. 10. 1198W. 10.20 14B 198W. 11. 1198X. 12. 122BC1112B1314 15 16 17 18 19 198X. 9
7、. 15 198Y. 9. 1 13A198X. 12. 25 198X. 12. 20 3AD B2021 22 23 198Y. 1. 15 198Y. 1. 15 DS 198Y. 2. 15E24252627 198Y. 3. 1 198Y. 6.30F2829198Y. 6. 1 198Y. 7. 15G303132198Y. 6.25 198Y. 9.10H33198Y. 10.1 198Y. 10.31I343536198Y. 11. 1 198Z. 2.1 1二已开始的活动X二已完成的活动0二不要求采取措施+对应于图20. 9. 3中的方法学*直到实现可行性研究之前,并不进行第
8、n阶段活动v的估计A二提前的工作天数 B二推迟的工作天数口5二正在进行表20. 9. 9信息系统项目进度表具有阶段标志E的活动阶段标志E-细节活 动 估计的开始 时间 实际的 开始时间 提前或 推迟 天数估计的完成日期实际的完成日期提前或推迟天数24 指定程度组长198y, 3. 1 198y, 3. 825安排顺序和分配 程序198y, 3. 5198y, 3. 1226安排程序准备 进度198y, 3. 15 198y, 3. 2527aKG*2编定、27b KG*2同上27c KG*2同上27d KG*2同上27eKG*2同上27f KG*2同上测试程序 并编与程序资料198y, 4.
9、1198y, 4. 11198y, 4. 15198y, 4. 30198y, 5. 1 198y, 5. 14198y, 5. 15198y, 5.31198y, 6.198y, 6. 14198y, 6. 15 198y, 6. 30*以阶段标志D的活动 A二提前的工作天数B二推迟的工作天数实际开始时间为准 os二正在进行下面的方法可以用来估计价格、人员以及相应的时间要求。这种循环使用的 方法使得一组人能意见一致,而且对于信息服务项目特别合适。我们假定参与估 计的那些人能够提出问题或具有任务方面的知识,而且能够提出支持自己意见的 重要的理由。参与建立信息系统项目进度表的人可以包括项目组长、
10、起作用的用 户经理以及其他有经验的信息服务人员(他们不一定与本项目有关)。我们通过以 下几个步骤来描述进行合理估价的方法。项目组长介绍任务(例如,确定项目进度表的阶段标志的日期)和相应的背 景信息。每一个参加者提交一个书面估计(成本、人员要求或时间)。项目组长(以线性比例)绘出该组每个成员的估计。计算上、下四分点和中点,并且标上迟度。要求其估计低于上、下四分点的那些参加者解释他们低或高估计的理由。项目组长就所标绘的估计召集一次公开的讨论会。重复步骤至,直到达到精确性要求不需要再循环为止。通过每一次循 环,将降低估计的误差。估计是取中间值或(在适合时)取平均值。估计的误差是包含危险的一种标 志。
11、(15)与用户人员交谈与用户交谈的过程从本活动开始。为了解决问题和确定系统要求,项目组成 员定期与有关用户见面。与用户交谈及反馈的过程贯穿于系统开发的全过程。对于详细设计的基本输入是:(A)初始设计(来自可行性研究),(B)对现有系 统及其成分的评价(也是来自可行性研究)以及(0输入、处理以及输出的要求(由 用户提供)。而目组与有关的用户人员检查在可行性研究的初始设计中所描述的输入/ 输出要求和频率,并根据需要及价值对每一种输入/输出进行评价。许多输出是 “有了更好”,但是却不值得去产生它们。还可以根据周期和时帧来估计输入/ 输出。通过估计频率/价值比的平衡来优化周期的输入和输出。例如,如果每
12、周 情况报告可以满足需要,那么就没有必要再产生每天的情况报告。在联机系统中, 检查响应时间要求以确定这种时间要求是否太紧迫,能否适当放宽要求而又致于 对运行效率产生较大的影响;或者确定这种响应时间的要求是否不能满足。目前系统的资料对设计提供了有价值的输入。现有的报告、表格、原始资 料等等,实际上能够追踪最终用户以便确定该资料是否合适,是否及时等。如果 是,还能做哪些工作来改进它们?项目组负责对现有的所有输入和输出进行修改。 通过合并类似的输入和(或)输出以及消除多余的信息尽可能地减少重复。初步交谈的一个直接结果是对所建议的系统所有的输出一般的描述(报 告,显示或事务)。根据周期、初始用户、输出
13、介质、内容以及分布来描述每一 种输出。(16)说明数据库要求数据库用来支持系统的处理,特别是支持系统的输出。在目前系统的资料中 包含了可继续使用的数据元。许多现有数据元的格式肯定是需要改变的,还需要 将支持系统功能要求所需要的其他数据元标列出来。项目组设计和编制数据字典,在一部数据字典中所列出的数据具有维持每个 数据元的基本信息,而它们与数据库或文件的组织形式无关。在表20. 9. 10给出 的数据字典的例子中,包括对每个数据元指定了一个各自的前后参照号、标题、 描述(如果必要的话)、是否被编码、程序设计标识、存储单元(字符)数、格式和 存储器大小(程序最初使用的)以及职责等。用户必须给出负责
14、的人或部门、存储 单元以及是否对数据元编码等事项。表20. 9. 10的数据字典形式,也可以用来交 叉引用在所有原始资料、报告、文件以及数据库中出现的每一个数据元。 在 标列出所有的数据元之后,项目组与数据库管理员合作来进行记录格式和文件的 设计,或者,在数据库环境下,他们设计数据库的模式。此活动的输出是数据字 典以及有关文件和(或)数据库模式的一份详细的技术描述。表数据字典报告标题数据字典日期系统标题标识编号标题描述编码否标记字符数字形/格式存储职责原始资料(S)、报告(R)、文件(F)、或数据库(D)工资支票(R)工资登记簿(R)工资主文件(F)会计文 件(F)工时卡(S)1社会保险号职工
15、否99999 P 人事X X X X2姓否LNAME 13 X (13) E 人事X X X X3名字职工否ENAME 10 X (10) E 人事 XXX4名字首字母职工否MI 1 X E 人事 XXX5部门职工亲属是DEPT 3 XXX E 人事X X X X6性别男或女是SEX 1 XE 人事 X7工资月工资否SAL 6 9999 P 人事 XXX(17)建立控制和后援的方法为了保证信息系统的正确性、可靠性和完整性,在设计时就要考虑加进控制 手段。项目组将说明在系统设计时要嵌入所有物理上的和行政管理上的控制。在 系统的输入、处理和输出阶段用以控制系统的技术的范围是广泛的。在处理之前 核对
16、输入,在处理期间使用诸如合理性检查以及数字位检查等技术以便最小化或 消除在计算或处理中的过失误差,记录计数和长度核对是用来保证输出正确性的 许多技术的代表。为了避免在系统故障期间造成破坏,需要确定后援(备份)和校验点/重新启 动的方法。这些方法描述了包含在系统中的克服故障的额外处理,在系统故障的 情况下,利用备份文件和(或)备份事务日记从上一个“校验点”来重新建立处理o 在上一个校验点“重新启动”系统,并重新开始正常的运行。在系统处理周期期 间,定期地建立校验点将会使系统及时地保留在该点的所有处理,而且不会被破 坏。(18)完成详细设计详细的系统设计是分析输入/输出、处理、控制和后援要求的结果
17、。系统初 步设计或系统一般设计只描绘了各主要处理活动之间的关系,而系统详细设计则 扩展到包括所有处理活动和有关的输入/输出。这是系统开发过程的基础活动。 正是这一步,将功能说明书与技术上和方法上的新设施结合一起以实现一个系 统。详细设计是前面所有工作的归宿。此外,它也是该项目今后所有活动的一张 蓝图。在活动5中提到了用图形说明系统设计所使用的若干技术(但没有详细讨 论)。这里我们简单地讨论其中三种技术一流程图。HIPO以及渥宁(Warnier)图。 用来形象地描述工作流程和总的系统设计的最流行的技术是流程图。流程图使用 刻画系统逻辑的一些专用符号并通过流线把这些符号相互连接起来以说明工作 流程
18、和数据流程。图20.9. 11给出了系统流程图符号的一个子集。在图20.9.12 中,用流程图描绘了一个已投入运行的工资系统的一部分。 流程图有一定的 缺点。不像前面所讨论的其他两种技术,流程图并不鼓励分析员使用系统设计的 自上而下或模块化的方法。因此,用流程图方法来设计系统,不仅难于设计,而 且设计出的系统也难于理解和维护。流程图之所以较为流行,主要是由于它是最 早出现的设计方法。层次式输入-处理-输出法(又称HIP0法)是在一层次体系中将系统设计按其 详细程度分层,依次地说明所有的输入、处理和输出的一种方法。图20. 9.13 说明了一个工资系统的HIPO卷内容表(VTOC)。VTOC是在
19、HIPO设计方法中所使 用的几种标准形式之一。整个系统被划分成由若干逻辑模块所组成的一个层次体 系,并用VT0C来描绘。此后,利用粗框图和细框图还可以将这些模块进一步划 分成更细小一层的输入-处理-输出的细目。通常由若干个VT0C将设计的层次体 系统推进到依次的细目层。从HIPO结构化方法所得到的好处往往被编写系统资 料所需要的大量繁琐的文书工作所抵消了。Warnier框图(在图中说明)可以用来设计整个系统、数据结构、报 表内容以及数据元的编码。使用Warnier框图的依据是:应该围绕着数据结构来 设计系统。Warnier框图的最大优点是对各种环境的适用性。图20. 9. 15中的例 子是一个
20、扩展项判定表,它是许多判定表中的一种,一个判定表有一个条件分叉 (在表的左上方)和活动分叉(在表的左下方),一个条件项(右上方)以及一个活动 项(右下方)。判定表并不是一个说明数据流和工作流的有效的工具,最好把它作 为其他设计方法的补充。判定表的主要好处是必须考虑到每一种可能的替换者、 选择、条件、变元等。与流程图,HIP0图以及其他设计方法不同使用Warnier 框图法,系统分析员不必考虑细节。图20. 9.11部分系统流程图符号图20. 9.12简化的工资支付系统流程图工资系统 系统开始 每月处理 月初 每周处理 提交时间卡片 数据录入 按工时处理职工记录工资支票工资联单更新工资文件月末按
21、月薪 处理职工记录 工资支票 工资联单 更新工资文件 系统结束图 20.9. 14 Warnier 框图图20.9. 13 HIP0:卷内容表上面讨论的分析工具代替了一大段解说词,而通常对解说词的理解容易产生 混淆。然而,精心设计的解说词可以而且应该用来支持图形设计技术。没有一种分析和设计的技术是最好的,最好的分析和设计技术是适合一个公 司具体情况的各种技术的组合。总之,模块化的自顶向下方法是当今必不可少的。 按自顶向下方法进行设计时,通过最高一级的管理者来建立基本的系统目标,然 后根据在公司每一级收集的输入数据,在设计中增加后继的细目层。由于作为一 个整体概念多数系统过于复杂,所以将系统分成
22、若干个更容易理解的模块。模块 化的主导思想是“各个击破”,而这是行之有效的。(19)指导用户或信息服务部门预演。表20.9.15 一张判定表支付类型 工资 按工时处理 佣金时帧周末月末周末月末周末月末打印工资支票X X X X X打印工资联单 X X X X结构预演是一种预测评价方法,它能有效地减少某些被忽略的或作错的事 情。它也给预测者提供一个机会来评价那些业已建议的事情(如系统设计),从而 有可能给出一些建设性的建议。预演的目的是给项目组提供有价值的反馈信息, 而不是对系统的质量下判决性的结论。项目组长应考虑何时开始结构预演。通常预演是在系统设计以及系统开发过程中其他一些关键点(如,测试计
23、划、程 序描述等)完成之后才进行。参与结构预演中的人有:若干项目组成员,一个协调员,参加者,一位秘书, 或许还包括一位不属双方的“中立的”经理。项目组的某个成员或所有成员扮演 “推荐者”的角色,并且解释他们所承担设计的系统的那一部分。协调员负责组 织预演和协调“推荐者”与“参加者”之间的相互配合。根据对所提出的课题的 知识和兴趣来选择“参加者:这些人应该是没有直接参与本项目的。秘书将对 一些要点作书面记录。通常邀请一个“中立的”经理参加第一次预演。中立经理 的出席将促使参与预演的每一个人专心于他的工作(这一点有时是预演的一个问 题)。结构预演的方法是简单的。在进行预演的前几天将需要审查的材料(
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 2023 信息系统 开发 过程 概述
![提示](https://www.deliwenku.com/images/bang_tan.gif)
限制150内