第九章 信息系统开发系统开发方法学信息系统开发系统开发方法学
□ 系统开发方法学的目标
开发一个计算机信息系统，不管它是联机航空公司订票系统。还是库存控制系统，其过程基本上是相同的。每一过程都由一些基本的活动组成。这些活动是每一个信息服务人员都应掌握的。但是由于各人对该过程的解释不同，所以很多公司采用了标准的系统开发方法。这些方法(与软件一样)可以在市场上买到或者内部设计。
系统开发方法学指出了要进行的活动、这些活动之间的关系和顺序在及关键的评价和判定的阶段标志。提交可行性研究报告和完成功能说明书是典型方法学中的两个重要的阶段标志。
□ 系统开发方法学的好处
1.资料
长期以来，在信息系统的开发和维护中，资料总是一个问题。信息系统开发方法学(以下简称方法学)鼓励项目组成员将资料作为设计的副产品产生出来。因此，在信息系统实现时，资料总是最新的，而且是完整的。在方法学中包含了变换控制机构以保证资料总是最新的版本。不采用方法学的计算中心依靠各人的自觉性来更新他们职责范围内的资料和程序。这种工作方式会导致失败及不必要的人力浪费。当某个人离开，而留下没有资料的系统和程序时，必须花费大量的人时来弄清楚已经做了些什么。
2.项目管理
由于对开发任务(活动)进行了判别和排出了先后顺序，所以可以形成实现一个项目管理系统所必要的输入。如果没有标准的系统开发方法学，在信息服务环境中要实现项目的计划和控制几乎是不可能的。
3.资金上的节省
方法学具有节省相当大的财力和人力的潜力。最大的节省可以说是由于取消了进三步退两步的系统开发方法学而得到的。方法学对于系统开发不可忽略的重要方面提供了方向和保证。例如，一个好的方法学将要求在进行系统设计之前标列出成本、进度、安排、软件、操作以及设备等约束条件。有关的用户和信息服务经理将就这些书面的约束条件签定协议。如果没有这些指导准则，项目组经常是在一个方向推进(进三步)后，结果却发现由于违反了设计要求，有许多工作必须重做(退两步)。
当项目组遵循一个描述清楚的系统开发方法学的指导准则时，开发一个满足用户要求的高质量的系统的概率是非常高的。图20.9.1强调了在第一次就正确地做好这件事在经济
有时用户和信息服务管理人员仅仅看到开发成本，但是估计系统的成本时应该包括整个系统的寿命期(包括生产年限)。图20.9.1说明尽管利用方法学开发一个系统在前期要求较多的人力，但是最终的设计将是高质量的，从而将减少对系统的修改要求。而且由于有完善的资料，这种修改也更容易实现。另一方面，根据个人所好而没有借助于系统开发方法学所设计的系统将不可避免地导致质量低和相当可观的维护成本。一个设计很差的系统的整个设计组被指派去以全部时间维护系统的情况并不少见。
二、系统开发的责任矩阵
表20.9.2的系统开发责任矩阵指出，在系统开发的过程中何时涉及到个人、小组和部门以及涉及到的程度，并针对每一种活动提出了所涉及的人员和机构。其中：
沿左手一边是按照方法学五个阶段的每一阶段列出的主要活动。责任矩阵是讨论系统开发过程的基础。这些活动是以实现它们的顺序列出来的。为了便于前后参照，在矩阵中以及在讨论时对这些活动都编了号。在责任矩阵中某些活动左边的菱形用来指出系统开发过程中的一些重要阶段标志(以下简称标志)。这些标志在一些活动完成时才出现。它们可用来表示进度或者作为预先指定的项目进展的估价点。通常，一个公司对每一个开发项目将使用同样的标志。对于那些有较大失败危险的非结构化的项目，则需要设置更多的阶段标志。
下面描述表20.9.2顶端所列出的那些人员和机构的含义。
1.可行性研究组。这个组由指定来完成可行性研究(第1阶段的活动)的用户和信息服务人员组成。
2.项目组。由指定来开发和实现计算机信息系统或对现有系统作重要改进的用户和信息服务人员组成。
3.信息服务管理部门。该机构涉及到信息服务管理组，而不一定指某个具体人。在一个小单位中，它可能局限于信息服务的一些高级负责人(高级经理)。在一个大单位中，经理最适合于承担该机构所涉及的特定的任务。
4.未指派的程序员和分析员。包括未指派到所讨论的可行性研究组和项目组的他的信息服务专职人员。
5.业务领域(用户)管理人员。所有影响到建议开发项目的或者受该项目影响的业务领域(用户)的管理人员都包括在本责任机构中。
6.未指派的专业人员。包括将影响到建议的开发项目或受该项目的影响的那些专业人员(经理除外)，但他们并未被指派到可行性研究组或项目组。
7.信息系统政策委员会。信息系统政策委员会(ISPC)是对公司所有的信息服务的一个高级指导委员会。
8.信息系统审计组。信息服务审计组的一个重要职能是保证在开发过程中对计算机信息系统建立适当的控制。
三、系统开发过程
□ 五个阶段
各种系统开发方法学在范围、复杂性、完善程度以及方法上有很大的不同。尽管有的方法学分三个阶段，有的分15个阶段，但是每个方法学所描述的要完成的活动基本上是相同的。本章要阐述的最重要的一点是：最好的方法学是那些始终把用户考虑进去的方法学。过去的情况是，用户管理人员与信息服务开发组合作来完成系统的一般功能说明书，然后，由信息服务人员来进行系统开发。现在，系统开发是各占50%的比例；因此，用户管理人员应该非常熟悉系统开发的大体过程，特别应该熟悉他们单位自己使用的方法学。?
系统开发过程可分为五个阶段来描述。这五个阶段是：?
1.第Ⅰ阶段-系统开始和可行性研究?
2.第Ⅱ阶段-系统分析和设计?
3.第Ⅲ阶段-程序设计?
4.第Ⅳ阶段-转换和实现?
5.第Ⅴ阶段-实现后的评价?
第Ⅰ阶段-系统开始和可行性研究是在为开发一个建议的系统提供人力和资源之前完成的。第Ⅰ阶段多数的工作和编写的资料是第Ⅱ阶段的输入。在第Ⅱ阶段-系统分析和设计期间，系统分析员与用户一起工作以编写详细的功能和系统的说明书。将这些说明书交给程序员，然后开始第Ⅲ阶段--程序设计。在第Ⅵ阶段-转换和实现期间，一旦软件开发出来，则建立数据文件，转换现有系统，并且实现新系统。第Ⅴ阶段-实现后的评价。在开始了系统寿命期中的生产阶段之后，提出(经常被忽略的)实现后的评价要求。?
□ 具体开发过程
下面将逐步地描述系统开发过程。至于具体的细节、相互的影响、方法、形式等，用户管理人员应该与信息服务经理联系，与他们讨论公司当前使用的方法学，同时再看看公司内部描述方法学的手册。?
1.第Ⅰ阶段-系统开始和可行性研究?
在第Ⅰ阶段的活动中很少有与其他四个阶段的活动相一致的。此处所提供的方法包括对于受拒绝后的再次服务请求的方法以及将技术转移可能性的研究合并到诸过程中这些内容。第Ⅰ阶段最终的产品有两个部分。第一部分是实际的可行性研究报告，它包含对建议的或改进的系统的描述以及利润/成本分析。第二部分是系统的初步设计。它对于估价成本和利润是必要的。该初步设计是第Ⅱ阶段-系统分析和设计的直接输入。?
将系统的初步设计并入可行性研究的依据是，多数可行性研究是以概念而不是以设计为基础的。如果在描述系统目标上花的时间太少，那么成本估计，甚至利润估计将是错误的。用概念来指导可行性研究注定会导致成本过高，而且用户不满意。在系统初步设计上所花费的时间是值得的，即使拒绝可行性研究也是如此。因为所编写的资料将必然会被证实其他项目中是有价值的。?
下述编号的活动与表20.9.2的系统开发责任矩阵相对应。?
(1)提交服务请求?
图20.5.1说明了包括对受拒绝的请求再次请求处理的一种方法。所请求的服务毕竟是用户做的，因此，应该由用户着手进行。我们鼓励用户管理人员请求信息服务人员的帮助，但是应该再一次强调，业务领域的管理人员应该对各种大小的服务请求都提供合适的资料。? (2)估价服务请求?
正如在责任矩阵中所注释的那样，信息服务管理人员只能承诺小的项目(由公司的方针所确定的小项目)。?
(3)指定可行性研究组?
信息服务经理和用户经理共同来指定适当的混合的人选以组成可行性分析研究组。该组至少由一名系统分析员和一名用户代表组成。可行性研究组的大小取决于可行性研究的范围和时间限制。?
用户代表应该熟悉当前专业领域的所有工作，用户经理、总经理助理，或专业领域分析员是合理的候选者，用户的系统分析员，具有计算机信息处理基础知识的情况已经越来越普遍了。?
必须指定一个人担任可行性研究组的组长，哪怕只是两个人的可行性研究组也需要一个组长。直到1980年为止，多数的可行性研究组和项目组是由一个高级系统分析员或一个项目负责人来领导的。在信息服务部门中，这两种人是固定分工做这项工作的。目前越来越多的公司采取这样一种政策，即由用户担任项目组组长。这种将主要责任下放给最终用户的做法将进一步鼓励用户参与系统设计。在这种政策上取得成功经验的那些公司已经指派了一些具有杰出管理经验和具有某些计算机和信息处理知识的用户人员担任项目组组长。在任何情况下，组长必须对该组的工作有一个总的安排。如果要求一个用户代表既作为可行性研究组或项目组的组长而同时又要求他继续履行业务领域的职责，那么该项目是肯定要失败的。有好些公司已经采用了一种政策，即自动地指派受系统影响最大的业务领域的经理作为可行性研究组和项目组的领导以后该经理将从原来的工作职责中解脱出来，而用他(她)的全部时间管理可行性研究(或项目)组。这种人事安排已经成为当今的主流，其困难是用户经理需要离开原来主管的业务部门少则两个月多则三年后才能回他原来的工作岗位上。?
(4)标列约束条件?
在系统开发的过程一开始，可行性研究组与信息服务人员和用户经理密切合作标列出设备、成本、进度、规程、软件以及操作上的约束条件。它们可能限制建议的系统的定义和设计。?
(5)整理现有系统的资料?
整理现有系统资料的主要理由是：如果可行性研究组不充分了解现有系统，那么他们就不可能有效地完成所建议的系统的初始设计。已经建立起来的多数人工系统并没有经过真正的设计。在这些系统中，必须从手稿整理出资料。如果一个建议的系统是改进一个现有的计算机信息系统，那么可行性研究组只需要保证现有资料的完整性和保持最新版本就行了。
现有系统所形成的任何资料将给设计阶段提供有价值的输入(如果批准开发该系统)。即便建议的系统遭到拒绝，也能对现有系统提供基本的资料，并且可能透彻地理解理有系统。现有系统的资料由四部分组成：①系统报告和资料；②系统数据文件；③系统数据元以及④说明现有系统的数据、信息和工作流程的图表。前三部分(报告、文件和数据元)可分类如下：
①当前使用的，而且在建议的系统中以目前的形式保留下来；?
②当前使用的，但是修改后才在建议的系统中使用；?
③当前使用的，但是在建议的系统中将被删除而不再保留的。?
例如，列出所有现有的报告和标准的资料，并按上述分类给定一种状态。在报告上将标明相对周期(如，每天，每周)以及分发范围。?
对于现有系统的所有数据文件都标明有关的存储介质(如，3
