2023年信息系统管理开发过程

系统开发过程

□五个阶段

多种系统开发措施学在范围、复杂性、完善程度以及措施上有很

大的不一样。尽管有的措施学分三个阶段，有的分15个阶段，不过

每个措施学所描述内要完毕日勺活动基本上是相似的。本章要论述日勺最

重要H勺一点是：最佳的措施学是那些一直把顾客考虑进去的措施学。

过去H勺状况是，顾客管理人员与信息服务开发组合作来完毕系统的一

般功能阐明书，然后，由信息服务人员来进行系统开发。目前，系统

开发是各占50%的比例；因此，顾客管理人员应当非常熟悉系统开发

的大体过程，尤其应当熟悉他们单位自己使用的措施学。

系统开发过程可分为五个阶段来描述。这五个阶段是：

1.第I阶段-系统开始和可行性研究

2.第H阶段-系统分析和设计

3.第山阶段-程序设计

4.第IV阶段-转换和实现

5.第V阶段-实现后的评价

第I阶段-系统开始和可行性研究是在为开发一种提议的系统提

供人力和资源之前完毕的。第I阶段多数日勺工作和编写日勺资料是第II

阶段日勺输入。在第n阶段-系统分析和设计期间，系统分析员与顾客

一起工作以编写详细的功能和系统的阐明书。将这些阐明书交给程序

员,然后开始第in阶段--程序设计。在第VI阶段-转换和实现期间，

一旦软件开发出来，则建立数据文献，转换既有系统，并且实现新系

统。第v阶段-实现后口勺评价。在开始了系统寿命期中的生产阶段之

后，提出（常常被忽视的）实现后口勺评价规定。

□详细开发过程

下面将逐渐地描述系统开发过程。至于详细日勺细节、互相日勺影响、

措施、形式等，顾客管理人员应当与信息服务经理联络，与他们讨论

企业目前使用w、j措施学，同步再看看企业内部描述措施学的手册。

i.第I阶段-系统开始和可行性研究

在第I阶段的活动中很少有与其他四个阶段的活动相一致的。此

处所提供口勺措施包括对于受拒绝后的再次服务祈求的措施以及将技

术转移也许性的研究合并到诸过程中这些内容。第I阶段最终的产品

有两个部分。第一部分是实际日勺可行性研究汇报，它包括对提议日勺或

改善日勺系统的描述以及利润/成本分析。第二部分是系统的初步设计。

它对于估价成本和利润是必要的。该初步设计是第n阶段-系统分析

和设计日勺直接输入。

将系统的初步设计并入可行性研究日勺根据是，多数可行性研究是

以概念而不是以设计为基础的。假如在描述系统目的上花的时间太

少，那么成本估计，甚至利润估计将是错误日勺。用概念来指导可行性

研究注定会导致成本过高，并且顾客不满意。在系统初步设计上所花

费的时间是值得的，虽然拒绝可行性研究也是如此。由于所编写口勺资

料将必然会被证明其他项目中是有价值口勺。

下述编号的活动与表20.9.2的系统开发责任矩阵相对应。

（D提交服务祈求

图20.5.1阐明了包括对受拒绝的祈求再次祈求处理的一种措

施。所祈求W、J服务毕竟是顾客做W、J,因此，应当由顾客着手进行c我

们鼓励顾客管理人员祈求信息服务人员日勺协助，不过应当再一次强

调，业务领域的管理人员应当对多种大小的服务祈求都提供合适的资

料。（2）估价服务祈求

正如在责任矩阵中所注释的那样，信息服务管理人员只能承诺小

的项目（由企业的方•针所确定的小项目）。

（3）指定可行性研究组

信息服务经理和顾客经理共同来指定合适的J混合H勺人选以构成

可行性分析研究组,该组至少由一名系统分析员和一名顾客代表构

成。可行性研究组内大小取决于可行性研究的范围和时间限制。

顾客代表应当熟悉目前专业领域的所有工作，顾客经理、总经理

助理，或专业领域分析员是合理的候选者，顾客的系统分析员，具有

计算机信息处理基础知谡的状况已经越来越普遍了。

必须指定一种人担任可行性研究组mI组长，哪怕只是两个人口勺可

行性研究组也需要一种组长。直到1980年为止，多数的可行性研究

组和项目组是由一种高级系统分析员或一种项目负责人来领导日勺。在

信息服务部门中，这两种人是固定分工做这项工作日勺。目前越来越多

的企业采用这样一种政策，即由顾客担任项目组组长。这种将重要责

任下放给最终顾客内做法将深入鼓励顾客参与系统设计。在这种政策

上获得成功经验日勺那些企、也已经指派了某些具有杰出管理经验和具

有某些计算机和信息处理知识的顾客人员担任项目组组长。在任何状

况下，组长必须对该组的工作有一种总的安排。假如规定一种顾客代

表既作为可行性研究组或项目组日勺组长而同步又规定他继续履行业

务领域日勺职责，那么该项目是肯定要失败的。有好些企业已经采用了

一种政策，即自动地指派受系统影响最大日勺业务领域的经理作为可行

性研究组和项目组H勺领导后来该经理将从本来的工作职责中解脱出

来，而用他（她）的所有时间管理可行性研究（或项目）组。这种人事安

排已经成为当今日勺主流，其困难是顾客经理需要离开本来主管的业务

部门少则两个月多则三年后才能回他本来口勺工作岗位上。

（4）标列约束条件

在系统开发的过程一开始，可行性研究组与信息服务人员和顾客

经理亲密合作标列出设备、成本、进度、规程、软件以及操作上的约

束条件。它们也许限制提议H勺系统的定义和设计。

（5）整顿既有系统日勺资料

整顿既有系统资料的重要理由是：假如可行性研究组不充足理解

既有系统，那么他们就不也许有效地完毕所提议的系统的初始设计。

已经建立起来的多数人工系统并没有通过真正的设计。在这些系统

中，必须从手稿整顿出资料。假如一种提议日勺系统是改善一种既有时

计算机信息系统，那么可行性研究组只需要保证既有资料口勺完整性和

保持最新版本就行了。

既有系统所形成的任何资料将给设计阶段提供有价值的输入（假

如同意开发该系统）。即便提议日勺系统遭到拒绝，也能对既有系统提

供基本日勺资料，并且也许透彻地理解理有系统。既有系统日勺资料由四

部分构成：①系统汇报和资料；②系统数据文献；③系统数据元以及

④阐明既有系统日勺数据、信息和工作流程的图表。前三部分（汇报、

文献和数据元）可分类如下：

①目前使用日勺，并且在提议的系统中以目前日勺形式保留下来；

②目前使用的，不过修改后才在提议的系统中使用；

③目前使用的，不过在提议口勺系统中将被删除而不再保留的。

例如，列出所有既有的汇报和原则的资料，并按上述分类给定一

种状态。在汇报上将标明相对周期（如，每天，每周）以及分发范围。

对于既有系统的所有数据文献都标明有关日勺存储介质（如，3X5

的卡片，磁带，马尼拉折纸机，磁盘等等）以及存储方式。例如，一

种名字一地址文献可以存储在许多张3X5的卡片上，并且按名字W、J

字母次序排列。一种人工系统所保留的文献数总是令人吃惊的，即便

对于业务领域管理人员也是如此。为了完善既有文献口勺资料，将每个

文献口勺记录的样式和简朴描述附在文献表中。

系统数据元（即，社会保险号，顾客名，货号等等）是直接列出日勺,

而不必关系有关日勺文献。数据元常常在几种文献中反复出现。除了状

态指示符之外，假如数据BU名字不能自我阐明，则必须对每个数据数

据元进行描述。有关数据元W、J其他信息还包括更新规定（如，每天,

每周，每月，或根据需要更新等等）、来源（如，代办处，资料，系统,

工作人员等等）以及职责（如,部门名和负责更新者日勺职务）。图20.9.3

阐明在整顿既有系统资料时数据元也许采用的一种经典格式。

图20.9.3整理现有系统的资料：系统数据元

我们通过将系统简化为输入、处理和输出等几种基本构成部分来

表达整顿既有系统资料的工作过程。然后用图形描绘出各部分之间的

逻辑关系。有多种图像表达技术来做这件事。最为流行日勺（尽管不一

定是最佳的）是流程图。其他日勺更为构造化”日勺技术尚有：IBM企业

的层次化输入-处理-输出图（HIP0）,汽泡图，数据流框图，南茜-斯

奈德曼（Nassi-Shneiderman）图，渥尼尔（Warner）框图以及鉴定表。

目前工作过程的图像描述提供了系统的数据、信息和工作流程的一种

概貌。它着重强调系统中控制工作流程的那些数据元。这些图应当刻

划人工和计算机日勺处理环节，并且以合适口勺次序安排每一处理环节。

i般以能最佳地显示出工作过程的方式来组织和提供这些图。它们可

以是由某些随机事件、功能或按小时和大的周期来驱动日勺子系统，也

可以是若干子系统；既可以是层次日勺，也可以是混合的。很少有儿种

系统是完全次序日勺，因此，在多数状况下可以应用模块措施。

(6)调查研究技术转移口勺也许性

为了更好地运用既有的技术，许多企业正在进行将有关技术转移

到他们口勺系统开发措施学中也许性的调查。鼓励调查技术转移时也许

性和(或)可行性日勺政策必将带来人力资源日勺大量节省。尤其对程序员

和分析员更是如此。合适的技术转移将使这些人的工作集中于还没有

现成软件的特定行业日勺应用领域。

技术转移也许性出J调查是从走访那些已经实现出J,并且与所提议

的系统有类似规模和工作的系统。可行性研究组还应当调查商品软件

目录，以便找到适合口勺可应用的软件。假如认为技术转移是可行口勺，

则可行性研究组阐明怎样使用这些技术以及为适应既有环境所规定

的修改范围。

假如使用原则内措施来进行技术转移潜力调查，那么提出规定日勺

企业应当采用与具有类似规定的其他企业合作的政策。

(7)完毕提议系统W、J初步设计

可行性研究组要走访专业人员以获得一般的系统规定，然后，将

这些规定转换成初步的系统设计。设计过程是交互的，顾客经理和可

行性研究组需要常常就设计思想和措施等互换意见，用生动的文字和

图形阐明来形成提议日勺系统初步设计时资料，这些生动日勺文字(用非

技术词汇)描述了所提议的系统的基本工作过程，并且常常同步附有

图形阐明。这些文字图表也将列举出那些大大违反既有工作方式而提

议的系统所期望H勺手续、手段和措施。这些文字图像也将描述提议日勺

系统与人工系统以及提议系统必须与之兼容的自动系统之间日勺关系。

图形阐明将提议日勺系统日勺过程简化为它们的构成部分，同步强调

各部分之间的逻辑关系。

(8)确定项目范围

可行性研究组与信息服务人员以及顾客管理人员合作估计初步

设计中所刻划的系统口勺复杂程度。并对开发项目此后的每一种阶段进

行人力资源规定口勺估计(顾客，信息服务人员及其他人员)。此外，还

注意到培训和计算机机时规定。

(9)准备利润/成本分析汇报

一旦完毕初步设计并且确定了项目日勺范围，则可以开始利润/成

本分析。不幸的是，由于顾客和信息服务管理人员都但愿加紧可行性

研究阶段，因此，某些关键日勺环节被省略了，因此导致在利润、成本

估计上日勺错误。仅仅根据一种概念是不也许精确的反应出利润和成本

的。设计中的某些环节是必不可少的。

另一种在形成企业决策过程中所隐含日勺错误将不可防止地把那

些难以确定的利润也算成资金收入。当今许多复杂的，综合口勺系统为

企业欧I利益做出了重大的奉献，而做到这样程度是由于它们经历了漫

长的、不可捉摸和难以预见的道路。评价信息服务项目的好处和价值

是一种主观的过程，它规定具有成本和利润方面的实际日勺知识。此外，

决策者对于正日勺和负日勺不确定的利润要有透彻的理解。使用美元作为

所有成本和利润日勺统一的计量原则大大地简化了评价工作。那种把不

确定的利润引入盈利图表（为了“建立更好H勺顾客关系”或“提高威

信”）日勺作法会导致在“底线”中复合日勺错误。底线常常被盲目地接

受作为一种信条。实际上，在那种状况下，估价是取最佳的状况（理

想的）和最坏口勺（荒唐的）状况之间。然而，假如将不确定的利润化成

美元，那么决策者将以更好的判断替代那种不精确日勺估计。

估价提议的信息系统的最佳途径是针对系统净值（收入减去成本）

估计正日勺和负日勺不确定利润。为了便于理解不确定利润（例如，增长

服务，减少发票上H勺错误，加紧周转期等），应当产生一种成本和收

入的一览报表。

表20.9.4阐明怎样使用至少日勺成本类别来表达一次性时和反复

使用日勺成本。这些成本可由预算中心提出，并且把企业作为一种整体

来考虑。成本类别有：劳力，材料和设备，旅差以及其他多种成本。

对于每一类，在第一列指出一次性成本估计（开发），而在系统寿命期

的水平线上指出可反复使用的成本估计（生产）。企业项目在净值可以

从估计收入中扣除成本计算出来，并且根据企业政策对流动现金打折

扣。

表20.9.4成本一览表

预算中心项目标题和编号

一次性成本每年重复使用的成本

成本项

年第1年第2年第3年第4年第5年第6年第7年第8年

劳

力

材料和材料

设备设备

旅每日开销

差

交通费

其

他

开

支

总成本

（10）根据可行性研究做出决策

完毕可行性研究后，除了技术补充之外所有汇报和资料所有交给

信息处理政策委员会以便实行。技术补充包括准备可行性研究所规定

的背景信息。它还包括一般的系统设计和开始第II阶段（系统分析和

设计）日勺一种框架。信息服务政策委员会感爱好日勺重要是初始服务祈

求、范围、图讲解明和利润/成本分析。

信息服务政策委员会能对可行性研究施加影响。信息服务政策委

员会可以：

①拒绝提议。

②同意提议并对该提议日勺开发和实现指定一种最高优先数。

③同意系统并给它指定一种比最高优先数小的优先数，同步将祈

求放在所有提议H勺系统队列的合适位置（定期检查队列，当所祈求的

资源可用时，委员会给当时是最高优先数日勺项目发出通行命令）。

2.第n阶段-系统分析和设计

很少有几种项目能在同意可行性研究后立即实现。在得到同意和

项目开始之间的估计时间也许是两年或两年以上。一旦项目获如通行

命令，则开始第n阶段-系统分析和设计。在第n阶段，将描述所有

输入/输出的格式和内容，并且完毕详细日勺系统设计。第II阶段的最

终一步活动是准备程序阐明，其中包括多种程序模块H勺阐明书。重要

时是牢记在第I阶段和第II阶段不编制程序。一种普遍轻易犯的错误

（常常与系统日勺质量和运行维护的水平亲密有关）是压缩第II阶段，使

它提前完毕以便开始第in阶段-程序设计。粗糙的系统设计必将成倍、

甚至三倍地增长项目所规定的程序设计量。

di）指定项目组

与可行性研究组同样，项目组也应当有一种或多种系统分析员和

一至多种来自所提议口勺系统范围内各业务方面的顾客代表。假如也许

的话，还要给项目组指派一名信息服务审计员，他不作为专职人员，

而作为安全和控制方面的顾问。由于在第H阶段结束之前途序员实际

上并不参与进来，因此可以将指定程序员一事推迟到第H阶段结束时

再进行。可行性研究组的组员不一定都是项目组组员。在第I阶段结

束到第n阶段开始之间日勺这一段时间里，一般委派他们到其他项目

去。然而我们提议，只要也许则尽量将原有可行性研究组口勺人员指派

到项目组。项目组内组长可以是信息服务人员，也可以是顾客。

某些单位有按业务领域组织的固定日勺项目组。例如，某个项目组

专门负责人力资源开发方面日勺老的系统日勺维护和新系统的开发，而另

一项目组则负责会计和财务方面等等。另一种措施是项目组必须由信

息服务人员和顾客专业人员共同构成，并且是以项目为基础来指定项

目组。究竟怎样构成项目组为好，显然要进行权衡。按专业构成日勺项

目组很难预料在任务过多时或任务局限性时由于人员局限性或过剩

所带来日勺损失。然而，这种项目组织使得项目组组员有更多的机会积

累开发专业领域应用日勺经验。信息服务项目组组织的最佳方式或许是

既按专业领域组织而同步又保持一定欧J灵活性，使得项目组组员能在

各项目组织之间流动，以便到达饱满欧I工作负荷。

根据项目的复杂程度和波及范围的大小，每个项目组均有不一样

的最佳人数。项目组长日勺能力是一种重要内原因。有些地方，一种经

理能有效地管理20个以上日勺人员，而另某些经理却连管理3个人均

有困难。项目组的I大小以及相对进度这些是顾客、信息服务人员以及

企业H勺经理感爱好的问题。许多企业W、J经理人员有一种错误W、J概念，

即假如将项目组人员增长一倍，那么完毕项目日勺时间就应当减少二分

之一。实际状况并非如此。一种可以直接提成若干个相似大小模块的

简朴项目，用两倍的人力，可以在原定的二分之一时间里实现。然而,

绝大多数的项目是复杂的，有日勺甚至是极为复杂的，这就规定在所有

项目组组员间进行内部协调。

图20.9.5阐明增大项目组R勺规模时，将会发生的状况。在某确

定的数目之前，每增长一种指派到项目组的人员都增大了对项目H勺奉

献。在这之后，每增长一种人实际上减少了项目组每个人对项目工作

的I奉献。图上有一点是增人员日勺反射界线，超过那一点，再增长人对

于项目日勺目的来说反而起相反作用。由于项目组员之间日勺关系复杂，

因而使得生产效率减少。在为了满足项目限期而采用紧急措施的状况

下，有时经理人员规定将所有资源转移到紧急的项目上，图20.9.5

形象欧I阐明了当一种项目组人员太多时，将会出现的状况。这时将不

也许进行内部协调。当头都不懂得尾在做什么的时候，虽然每一种组

员都忙于从事某种与项目有关的工作，项目的进度还是要停止下来。

对于每一种确定日勺项目组均有最佳规模。与项目有关日勺所有经理

和企业行政人员都应当很好地掌握这样一种格言：与其过度地扩大项

目组织规模，导致欲速则不达日勺局面，还不如推迟项目日勺实现时间。

(PU2)

图20.9.5项目组的规模

（12）估计人员规定并进行人员委托

一种项目的成功与否在很大程度上依赖于顾客与企业经理、其他

专业领域人员以及某些范围内信息服务人员（如，数据库管理员，联

络顾客的人员等等）。由于某人（或某部门）忘掉或不承认此前的口头

上的委托，会使得许多紧急项目被延误。因此有必要签订一种书面的

人员委托书。应当造表列出在系统开发过程中所直接参与到的项目组

的人员和其他人员（如访问顾客人员、搜集数据人员等），并同步列出

在每一阶段对他们H勺相对日勺时间规定（见表20.9.6）o项目的人力规

定来自于可行性研究汇报。

报告标题:估计人员要求日期：12月8B

系统标题:市场分析系统标识：MARS

时间百分比

部门业务头衔

第n阶段第U1阶段第N阶段

管理信息部系统协圜员603080

官理信息部局戮系统分桁员1001080

管理信息部高级系统分析员6000

管理信息部高级程序员08020

管理信息部程序员0100100

市场部经理102030

市场部经理助理102030

市场部文职人员101040

市场部文职人员101040

图20.9.6估计人员规定

没有书面人员委托而进行的项目肯定会产生不必要时延误，甚至

也许失败。本书把项目开发的重要性放到一种恰当的I位置。在项目中

所波及到的许多人并不在项目组内。由于这些日勺多数都理解他们向例

行活动比项目所波及口勺任何外部事物更为重要，因此一种书面委托是

必不可少的。不幸的是，项目委托有时超过了他们按常规分派的工作

负荷。在这种状况下，需要经理直接参与、定期督促和采用干预措施。

图20.9.7对于在各个阶段人员委托的相对规定上给读者一种感

性的I认识。图20.9.7日勺底部描绘了在系统开发日勺每一阶段占总的项

目工作量W、J比例，对每一阶段提供了项目工作量比例H勺一种范围。企

业的政策以及系统开发措施学将影响到相对比例。例如，一种强调

设计阶段（IH）的措施学将必然有更为清晰定义的程序功能阐明书。因

此减少了程序设计工作所规定的时间。作为一种规则（到目前为止）,

花在第II阶段（系统分析和设计）上的工作量是与花在第ni阶段（程序

设计）上日勺工作量成反比的。在一种设计良好的系统中，第n阶段将

具有比第m阶段更大的工作量。

D:\HFZDCPCHF4907.PS24/9/199713:20:19

A1OO

9O

王

O

东O

7O

ilsnO

可行性研究组

疆5O

依4O项目组

皿3O用户管理人员和

费O

石2不在项目组的人员

O

1*

45

:n40

a35

版30

225

皿20

格15

珀10

、

发5-I只对实现

早-［后的咐1

阶

段

IIIIVV

可行性系统分析程序转换实现后

价

计

设

计

实

评

究

与

设

和

研

(Pl14)

图20.9.7相对的项目工作量

图20.9.7的上端阐明了由项目组（顾客和信息服务人员）和非项

目组组员的顾客对项目工作奉献的相对比例。注意，在第H阶段期间,

30%的工作量是由不在项目组的顾客做的。在第II阶段（系统分析和设

计）期间，项目组必须不停地在每一级与顾客进行通信。在程序设计

期间，仅仅在外围才波及到顾客。在第IV阶段（实现和转换），在培训、

测试、数据转换和并行操作中都波及到顾客。在第IV阶段中项目组和

顾客肩并肩工作，直到实现系统。在第V阶段，将系统转交给顾客。

（13）人员培训

为了在系统开发过程中进行有效的交流，也许规定对于在设计数

据库时所波及W、J顾客以及在生产调度中所波及由J信息服务人员进行

培训。根据经验，信息服务人员负责信息系统方面口勺培训，而顾客则

负责专业领域区I培训。

这个活动的产品是一张表，表中列出规定某种培训的人员的名字

和头衔。每行表中都注明那种培训的简朴描述，包括地点、负责人以

及计划日勺时间等。有些培训将规定立即进行，而另某些培训1（例如数

据录入）将推迟到项目靠近实现时进行。

（14）建立详细进度表

通过使用一种原则的系统开发措施，管理人员可以建立阶段标志

（见表20.9.2的活动5,10,19,23,27,29,32,33,和36）,然

后，运用历史记录数据和经验来估计中间和最终活动完毕的日期。项

目组组长必须与信息服务人员以及业务领域的管理人员亲密合作以

保证在系统开发过程中在各要点有足够日勺人员。

系统开发过程本质上是线性的（一种活动接着一种活动），并且是

不难用合适的J准则（措施学）和合理出J估计来监视W、J。表20.9.8阐明

了一种经典的信息系统项目进度表。在活动点上加上三种标志之一以

指出该活动的状态。假如状况表明该活动是不必要日勺，则在活动号上

加一种圆圈。假如一种特定的活动正在着手进行，则在对应的活动号

上划一种对角线。一旦活动完毕则将对角线改成交叉线“X”。有时

也用甘特表来给出项目进展的图形轮廊。

在开始一组有阶段标识的活动之前，要准备一种更为详细的进度

表，来单独安排这些中间活动。对于规定多于两周时间的那些活动将

以两周为增量来安排进度。表20.9.9阐明了对具有阶段标志E的那

些活动日勺一种详细内信息系统项目进度表。

表20.9.8信息系统项目进度表

阶段

+具有阶段标志完毕的活动

阶段标志活动

估计的开始时间实际的开始时间提前或推迟的天数

估计的

完毕日期实际完成的日期提前或推迟的天数

A12345198W.9.1198W.9.1DS198W

.10.1198W.10.1512B

B678910198W.10.1198W.10.2014B198W.11.1

198X.12.122B

C1112B13141516171819198X.9.15198

Y.9.113A198X.12.25198X.12.203A

DB20212223198Y.1.15198Y.1.15DS198Y.2.15

E24252627198Y.3.1198Y.6.30

F2829198Y.6.1198Y.7.15

G303132198Y.6.25198Y.9.10

II33198Y.10.1198Y.10.31

I343536198Y.11.1198Z.2.1

1=已开始区I活动

X二已完毕的活动

0二不规定采用措施

+对应于图20.9.3中日勺措施学

*直到实现可行性研究之前，并不进行第n阶段活动v的估计

A二提前的工作天数B二推迟的工作天数

DS二正在进行

表20.9.9信息系统项目进度表具有阶段标志E的）活动

阶段标志E-细节

活动估计的开始时间实际日勺开始时间提前或推迟

天数

估计日勺完成日期实际的完成日期毙前或推迟天数

24指定程度组长198y,3.1198y,3.8

25安排次序和分派程序198y,3.5198y,3.12

26安排程序准备进度198y,3.15198y,3.25

27a[KG*2]编定、测试程序并编写程序资料198y,4.1

198y,4.11

27b[KG*2]同上198y,4.15198y,4.30

27c[KG*2]同上198y,5.1198y,5.14

27d[KG*2]同上198y,5.15198y,5.31

27e[KG*2]同上198y,6.198y,6.14

27f[KG*2]同上198y,6.15198y,6.30

*以阶段标志D口勺活动A二提前的工作天数

B二推迟口勺工作天数

实际开始时间为准OS二正在进行

下面的措施可以用来估计价格、人员以及对应的时间规定。这种

循环使用的措施使得一组人能意见一致，并且对于信息服务项目尤其

合适。我们假定参与估计的那些人可以提出问题或具有任务方面的知

识，并且可以提出支持自己意见口勺重要的I理由。参与建立信息系统项

目进度表的人可以包括项目组长、起作用的顾客经理以及其他有经验

的信息服务人员（他们不一定与本项目有关）。我们通过如下几种环节

来描述进行合理估价的措施。

①项目组长简介任务（例如，确定项目进度表日勺阶段标志日勺日期）

和对应日勺背景信息。

②每一种参与者提交一种书面估计（成本、人员规定或时间）。

③项目组长（以线性比例）绘出该组每个组员的估计。

④计算上、下四分点和中点，并且标上迟度。

⑤规定其估计低于上、下四分点口勺那些参与者解释他们低或高估

计的理由。

⑥项目组长就所标绘的估计召集一次公开的讨论会。

⑦反复环节②至⑥，直抵到达精确性规定不需要再循环为止。通

过每一次循环，将减少估计出J误差。

⑧估计是取中间值或（在适合时）取平均值。估计的误差是包括危

险的I一种标志。

（15）与顾客人员交谈

与顾客交谈日勺过程从本活动开始。为了处理问题和确定系统规

定，项目组组员定期与有关顾客会面。与顾客交谈及反馈口勺过程贯穿

于系统开发的全过程。

对于详细设计的基本输入是：（A）初始设计（来自可行性研究）,

（B）对既有系统及其成分日勺评价（也是来自可行性研究）以及（C）输入、

处理以及输出日勺规定（由顾客提供）。

①项目组与有关的顾客人员检查在可行性研究的初始设计中所

描述H勺输入/输出规定和频率，并根据需要及价值对每一种输入/输出

进行评价。许多输出是“有了更好”，不过却不值得去产生它们。还

可以根据周期和时帧来估计输入/输出。通过估计频率/价值比口勺平衡

来优化周期的输入和输出。例如，假如每周状况汇报可以满足需要，

那么就没有必要再产生每天日勺状况汇报。在联机系统中，检查响应时

间规定以确定这种时间规定与否太紧迫，能否合适放宽规定而又致于

对运行效率产生较大的影响；或者确定这种响应时间的规定与否不能

满足。

②目前系统日勺资料对设计提供了有价值的输入。既有的汇报、表

格、原始资料等等，实际上可以追踪最终顾客以便确定该资料与否合

适，与否及时等。假如是，还能做哪些工作来改善它们？项目组负责

对既有日勺所有输入和输出进行修改。通过合并类似的输入和（或）输出

以及消除多出的I信息尽量地减少反复。

③初步交谈口勺一种直接成果是对所提议的系统所有的输出一般

的描述（汇报，显示或事务）。根据周期、初始顾客、输出介质、内容

以及分布来描述每一种输出。

（16）阐明数据库规定

数据库用来支持系统的处理，尤其是支持系统的I输出。在目前系

统W、J资料中包括了可继续使用出J数据元。许多既有数据元出J格式肯定

是需要变化的，还需要将支持系统功能规定所需要的其他数据元标列

出来。

项目组设计和编制数据字典，在一部数据字典中所列出的数据具

有维持每个数据元内基本信息，而它们与数据库或文献日勺组织形式无

关。在表20.9.10给出的数据字典的例子中，包括对每个数据元指定

了一种各自的前后参照号、标题、描述（假如必要日勺话）、与否被编码、

程序设计标识、存储单元（字符）数、格式和存储器大小（程序最初使

用的)以及职责等。顾客必须给出负责日勺人或部门、存储单元以及与

否对数据元编码等事项。表20.9.10的数据字典形式，也可以用来交

叉引用在所有原始资料、汇报、文献以及数据库中出现的每一种数据

元。在标列出所有的数据元之后，项目组与数据库管理员合作来

进行记录格式和文献(1勺设计，或者，在数据库环境下，他们设计数据

库的模式。此活动的输出是数据字典以及有关文献和(或)数据库模式

区I一份详细的技术描述。

表20.9.10数据字典

汇报标题数据字典日期

系统标题标识

编号

标题描述编码否标识字符数字形/格式存储职责

原始资料(S)、汇报(R)、文献(F)、或数据库(D)

工资支票(R)工资登记簿(R)工资主文献(F)会计文

件(F)工时卡(S)

1社会保险号职工否

99999P人事

XXXX

2姓否

LNAME13X(13)E人事

XXXX

3名字职工否

ENAME10X(10)E人事

XXX

4名字首字母职工否

MI1XE人事

XXX

5部门职工亲属是

DEPT3XXXE人事

XXXX

6性别男或女是

SEX1XE人事

X

7工资月工资否

SAL69999P人事

XXX

(17)建立控制和后援的措施

为了保证信息系统的对日勺性、可靠性和完整性，在设计时就要考

虑加进控制手段。项目组将阐明在系统设计时要嵌入所有物理上的和

行政管理上的控制。在系统的输入、处理和输出阶段用以控制系统的

技术的范围是广泛的。在处理之前查对输入，在处理期间使用诸如合

理性检查以及数字位检查等技术以便最小化或消除在计算或处理中

的过错误差，记录计数和长度查对是用来保证输出对的性的许多技术

的代表。

为了防止在系统故障期间导致破坏，需要确定后援(备份)和校验

点/重新启动的措施。这些措施描述了包括在系统中的克服故障的额

外处理，在系统故障日勺状况下，运用备份文献和(或)备份事务日志从

上一种“校验点”来重新建立处理。在上一种校验点“重新启动”系

统，并重新开始正常的运行。在系统处理周期期间，定期地建立校验

点将会使系统及时地保留在该点的所有处理，并且不会被破坏。

(18)完毕详细设计

详细日勺系统设计是分析输入/输出、处理、控制和后援规定日勺成

果。系统初步设计或系统一般设计只描绘了各重要处理活动之间日勺关

系，而系统详细设计则扩展到包括所有处理活动和有关日勺输入/输出。

这是系统开发过程内基础活动。正是这一步，将功能阐明书与技术上

和措施上的新设施结合一起以实现一种系统。详细设计是前面所有工

作的归宿。此外，它也是该项目此后所有活动的一张蓝图。

在活动5中提到了用图形阐明系统设计所使用日勺若干技术（但没

有详细讨论）。这里我们简朴地讨论其中三种技术--流程图。HIPO以

及渥宁（Warnier）图。用来形象地描述工作流程和总的系统设计口勺最

流行H勺技术是流程图。流程图使用刻画系统逻辑的某些专用符号并通

过流线把这些符号互相连接起来以阐明工作流程和数据流程。图

20.9.11给出了系统流程图符号的（一种子集。在图20.9.12中，用流

程图描绘了一种已投入运行日勺工资系统日勺一部分。流程图有一定

W、J缺陷。不像前面所讨论的其他两种技术，流程图并不鼓励分析员使

用系统设计的自上而下或模块化的措施。因此，用流程图措施来设计

系统，不仅难于设计，并且设计出的系统也难于理解和维护。流程图

之因此较为流行，重要是由于它是最早出现的设计措施。

层次式输入-处理-输出法（又称HIP0法）是在一层次体系中将系

统设计按其详细程度分层，依次地阐明所有日勺输入、处理和输出的一

种措施。图20.9.13阐明了一种工资系统日勺H1P0卷内容表（VTOC）。

VTOC是在HIPO设计措施中所使用的J几种原则形式之一。整个系统被

划提成由若干逻辑模块所构成的一种层次体系，并用VTOC来描绘。

此后，运用粗框图和细框图还可以将这些模块深入划提成更细小一层

的输入-处理-输出时细目。一般由若干个VTOC将设计的层次体系统

推进到依次的细目层。从HTPO构造化措施所得到时好处往往被编写

系统资料所需要口勺大量繁琐区I文书工作所抵消了。

Warnier框图（在图20.9.14中阐明）可以用来设计整个系统、数

据构造、报表内容以及数据元的编码。使用Warnier框图的根据是：

应当围绕着数据构造来设计系统。Warnier框图日勺最大长处是对多种

环境日勺合用性。图20.9.15中日勺例子是一•种扩展项鉴定表，它是许多

鉴定表中的一种，一种鉴定表有一种条件分叉（在表日勺左上方）和活动

分叉（在表的左下方）,一种条件项（右上方）以及一种活动项（右下

方）。鉴定表并不是一种阐明数据流和工作流日勺有效的工具，最佳把

它作为其他设计措施口勺补充。鉴定表的重要好处是必须考虑到每一种

也许的替代者、选择、条件、变元等。与流程图，HIP0图以及其他

设计措施不一样使用Warnier框图法，系统分析员不必考虑细节。

图20.9.11部分系统流程图符号

图20.9.12简化的工资支付系统流程图

工资系统系统开始每月处理月初每周处理提交时间去片

数据录入按工时处理职工记录工资支票工资联单更新工

资文献月末按月薪处理职工记录工资支票工资联单更新

工资文献系统结束

图20.9.14Warnier框图

图20.9.13HIP0：卷内容表

上面讨论的分析工具替代了一大段讲解词，而一般对讲解词的理

解轻易产生混淆。然而，精心设计口勺讲解词可以并且应当用来支持图

形设计技术。

没有一种分析和设计的技术是最佳日勺，最佳的分析和设计技术是

适合一种企业详细状况的多种技术的组合。总之，模块化H勺自顶向下

措施是当今必不可少的。按自顶向下措施进行设计时，通过最高一级

的管理者来建立基本日勺系统目日勺，然后根据在企业每一级搜集的输入

数据，在设计中增长后继的细目层。由于作为一种整体概念多数系统

过于复杂，因此将系统提成若干个更轻易理解的模块。模块化的主导

思想是“各个击破”，而这是行之有效的。

(19)指导顾客或信息服务部门预演。

表20.9.15一张鉴定表

支付类型工资按工时处理佣金

时帧周末月末周末月末周末月末

打印工资支票XXXXX

打印工资联单XXXX

构造预演是一种预测评价措施，它能有效地减少某些被忽视的或

作错的事情。它也给预测者提供一种机会来评价那些业已提议的事情

（如系统设计），从而有也许给出某些建设性口勺提议。预演的目的是给

项目组提供有价值的反馈信息，而不是对系统口勺质量下判决性的结

论。项目组长应考虑何时开始构造预演。一般预演是在系统设计

以及系统开发过程中其他某些要点（如，测试计划、程序描述等）完毕

之后才进行。

参与构造预演中出J人有：若干项目组组员，一种协调员，参与者,

一位秘书，或许还包括一位不属双方的“中立的”经理。项目组的某

个组员或所有组员饰演“推荐者”的角色，并且解释他们所承担设计

的系统口勺那一部分。协调员负责组织预演和协调“推荐者”与“参与

者”之间的互相配合。根据对所提出日勺课题的知识和爱好来选择“参

与者:这些人应当是没有直接参与本项目的。秘书将对某些要点作

书面记录。一般邀请一种“中立时”经理参与第一次预演。中立经理

的出席将促使参与预演H勺每一种人专心于他的工作（这一点有时是预

演的一种问题)。

构造预演的措施是简朴日勺。在进行预演日勺前几天将需要审查日勺材

料(即系统设计)分发给参与者，协调员负责跟参与预演日勺所有人联络

和通信。在实际日勺预演期间，推荐者解释系统设计以及有关的资料。

这是通过一步一步地预演系统来进行的，有时也许还借助于某种设计

工具。参与者提供出讨论的提议，而秘书则记录下来以形成资料C一

般一次预演持续H勺时间不应超过一种半小时。假如超过了这个时间限

制，那么一次预演会议将变得没有实际效果。假如必要，可以安排几

次会议来完毕预演。

项目组评价所有日勺提议，并且把所有价值日勺提议并入到系统设计

中。预演是有价值的，它使得设计者在系统实现之前获得重要W、J反馈

信息。

(20)选择硬件

假如正在开发内系统规定额外的硬件支持，则需要选择合适n勺硬

件并进行订货。获得硬件的过程一般是信息服务经理的责任。

(21)准备输出格式

在系统开发过程中，到目前这一阶段为止，我们已经提及了输出

并描述了其有关出J内容，不过程序员需要懂得详细H勺输出形式(即应

当怎样在输出设备上出现)O这种详细日勺输出阐明称之为输出格式。

项目组产生出显示屏(VDU)格式，这种格式规定了诸如题目、标题、

输出形式等项，有时还应包括输入形式。

某些硬拷贝汇报和资料规定事先打印好的表格纸，项目组与表格

纸厂商的I代表合作设计这种事先打印好的表格纸(例如，工资支票和

短线)。

项目组还负责设计和满足在系统范围内所有人工产生的汇报和

资料•，同步与受有影响日勺顾客经理相配合进行修改、增长或删除,

(22)描述数据项日勺阐明书

数据项的I阐明书详细规定了什么数据将输入到系统以及它们怎

样被输入到系统中。

(23)准备程序描述

系统开发进展到目前这一步，我们已经对既有的系统作了详尽的

分析。它的功能已经并入提议的系统的设计中，我们已经完毕了提议

的系统及其支持日勺数据库的设计，并且还准备了所有输入/输出详细

的阐明书。目前项目组可以着手标列和确定所有的程序，而这些程序

是使得提议的信息系统运转所规定的。系统日勺图形表达(流程图、H1P0

图和其他)是标列所规定W、J程序的初始输入。对每一种程序，项目组

编辑下述的资料:

①程序语言日勺种类（例如，COBOL、BASIC.FORTRAN）

②程序讲解词E勺描述-描述要执行的任务。

③由程序所产生日勺多种输出时描述和珞式

④处理频率（例如，每天、每周、联机等）

⑤界线和限制（例如，输入数据的次序，容量口勺限制，响应时间,

最大值，最小值等）

⑥详细阐明书（例如，排序，编辑的原则，特殊的计算和逻辑操

作，多种表格等）。

3.第in阶段-程序设计

项目组目前可以着手开始与计算机通信了。这种通信（或与计算

机的接口）是采用指令形式来进行日勺，而这些指令被编进计算机程序

中。这些计算机程序包括系统运转所必需的软件。在第in阶段-程序

设计阶段将开发支持信息系统所规定的所有软件。

顾客日勺介入集中在系统开发的过程前段（第II阶段）和后段（第IV

和v阶段）。假如对时地完毕了第n阶段并且顾客与项目组的协作是

有“成效”的，那么顾客将很少介入程序设计阶段，甚至完全不用介

入。顾客介入最多的状况将反复出目前系统设计需要澄清的时候，有

时也出现为第IV阶段（转换与实现），作某些初始计划的时候。

不幸的是，有时顾客管理人员也较深地卷进了程序设计阶段。这

是第n阶段进行得很糟糕，并且当开始程序设计时还没完毕的一种标

志。这种状况是常常发生日勺，尤其是在时间紧迫时，项目组常常收到

某些强制性的命令规定产生尚未完毕的产品。由于系统开发过程的最

终产品是软件，因此有时过早地开始程序设计。这种系统开发方式必

然导致产生质量低劣口勺系统。这种系统并不能满足顾客口勺规定，并且

维护日勺代价很高。这种系统整个寿命期的成本也许是一种高质量的系

统日勺两到三倍。

（24）指定程序员组长

一般项目组长是一种系统分析员或是一种顾客，他并不直接参与

程序设计工作。管理程序设计工作日勺人应当是程序设计工作实际日勺参

与者，因此，对于规定两个人以上的程序设计工作，将由信息服务经

理指定一种程序员组长。当然，项目组长仍然对整个项目负有责任。

程序员组长有时也称作为主程序员。他（或她）也许只花10%的时

间在产品的程序设计上。假如只需要管理一种下属程序员，那么主程

序员也许花80%的时间在产品日勺程序设计上。（25）安排次序和分

派程序

i种信息系统内软件包，也许规定几百个程序。并不需要按照这

些程序最终执行日勺次序来编写它们，在建立程序开发进度表时，必须

考虑到许多变化日勺原因。在安排程序编制次序时，主程序员应考虑如

下问题：

①建立和维护测试文献的I需要

②程序口勺依赖性(此处一种程序依赖于另一种程序的部分或所有

的输出)

③程序的长度和复杂性

根据程序员专业知识的水平、工作效率以及对系统熟悉的程序分

派程序。由于常常将程序员分派到其他项目组，从而对专业知识和经

验的规定非常广泛，因此使程序员与程序相匹配并非易事。

(26)安排准备程序的进度

主程序员可以运用程序进度表(表20.9.17)来安排和监督下属程

序员口勺活动以及任一给定程序的状态。由于程序开发有一种基本的模

式，因此一种类似于用来监督项目进度日勺技术(表20.9.8和4.9.9)

可以用来监督完毕一种特定程序的进度。表20.9.16绘出日勺甘特表是

程序进度表(表20.9.17)日勺一种图形表达，并且它是在公告板上可以

看到H勺一种通用H勺管理工具。几乎所有的J主程序员和项目组长都常常

使用这种公告板。

（27）编制、测试程序和编写程序资料。

一般一种程序员在一给定时时间里将同步编制2〜5个程序。开

发任一给定的程序内一般W、J措施本质上是相似於J。它们是：

图20.9.16程序日勺甘特进度表

①准备一般的程序逻辑框图

②准备详细的程序逻辑框图

③编写程序（写程序语句）

④测试和调试程序

⑤编写程序日勺资料

4.第IV阶段--转换和实现

第iv阶段的目内（转换和实现）是把在第I、n和in阶段日勺工作结

合成一种整体，并将信息系统实现到业务领域。项目组和受影响的顾

客部门大量地介入第IV阶段的全过程中（见图20.9.17）o

表20.9.17程序进度表

汇报标题程序进度表日期

系统标题材料规定标识MK

程序标题标识程序号时间百分比

i般逻辑详细逻辑编写程序测试和调试

形成资料估计的开始时间实际日勺开始时间提前

或推迟天数

估计时完成时间实际0tl完成时间提前或推迟

的天数

每日更新程序007MRLoisJames50XXXXX

9.159.205B10.3011.3021B

管理程序006MRPhilMorrison100XXXXX

9.159.150T11.1511.110A

调度程序008MRJohnSpeer8010.11.1

库存状态程序042MRMary1ouCummings40XX

10.1510.204B11.1

材料清单程序102MRLoisJames20XX11.

311.1510B1.15

日审计程序001MRJimJones10012.13

周审计程序002MRJohnSpeer201