信息系统建设计划.docx

资源描述

信息系统建设计划.docx

《信息系统建设计划.docx》由会员分享，可在线阅读，更多相关《信息系统建设计划.docx（18页珍藏版）》请在冰豆网上搜索。

信息系统建设计划.docx

信息系统建设计划

包括服务器,交换机,工作站,外围设备和连接线路等;...单元测试,组装测试和确认测试15网络施工和调试...配置管理计划,测试计划,培训计划,信息准备计划,系统...

信息系统建设计划

1信息系统建设计划的内容

信息系统建设计划是指组织关于信息系统建设的行动安排和纲领性文件，内容包括信息系统建设的工作范围、对人财物和信息等资源的需求、系统建设的成本估算、工作进度安排和相关的专题计划等。

1.1工作范围

信息系统建设计划的第一个任务就是确定信息系统建设的工作范围，即信息系统的用途和对系统的要求。

主要包括系统的功能、性能、接口和可靠性等四个方面。

计划人员必须使用管理人员和技术人员都理解的无二义性的语言描述工作范围。

系统的功能描述应尽可能具体化，提供更多的细节，因为这是系统的成本和进度估算的主要依据。

系统性能是指系统应到达的技术要求，比如信息存取响应速度、数据处理精度要求、信息涉及的范围、数据量的估计、关键设备的技术指标、系统的先进性等等。

一般来说，进行成本和进度估算，需要将功能和性能联合考虑。

接口（Interface）一般分为硬件、软件和人三种。

硬件指运行信息系统的网络硬件环境，包括服务器、交换机、工作站、外围设备和连接线路等；软件指信息系统运行和开发必须的系统软件和支持软件，如操作系统、数据库管理系统、开发工具等，此外软件还包括构成信息系统的一些成熟的商品化应用软件。

人指系统开发人员和系统使用人员，系统开发人员包括系统分析人员、系统设计人员、程序员、网络施工人员、设备安装人员、测试人员等；系统使用人员包括系统维护人员、操作员和利用系统获取信息及辅助决策的管理人员。

系统可靠性是系统的质量指标，包括硬件系统和软件系统的质量。

一方面是指系统对信息的存储、加工和分析处理的误差不影响管理人员决策，另一方面是指系统安全性高、故障率低或可恢复性强等。

1.2资源需求

工作范围确定以后，接下来就是确定所需要的资源。

信息系统建设对资源的需求由低级到高级可以用金字塔来描述，如图3-8所示。

在底层，是支持开发和运行软件系统的硬件环境（计算机网络）；在中间，是开发和运行应用软件的支撑环境（系统软件和支持软件）；在高层，是最重要的资源——人员。

无论哪种资源，都需要描述三个属性。

首先是关于人、软件和设备的描述，如需要哪种水平的人，什么样的硬件和软件；第二是开始时间；第三是持续时间。

后两个特征可以看作是时间窗口。

信息系统建设，尤其是大型信息系统建设，人员是最重要的资源。

在系统建设过程中，不同阶段，不同人员参与的程度不同，其分布如图3-9所示。

1.3费用预算

信息系统建设计划中的一项非常重要的内容就是建设费用预算，预算以成本估算为基础。

信息系统的建设成本主要包括网络环境建设成本、软件购置成本和应用软件开发成本。

网络环境建设成本和软件购置成本依据系统建设的技术方案和市场行情以及国家的工程施工费用计算标准，易于估算。

而软件开发的成本估算相对比较困难，国内外对此都有许多研究成果，但尚未形成一套完整的标准。

因为影响软件成本的因素太多，如人、技术、环境、时间、市场和政治因素等。

软件成本估算的关键是对软件开发工作量进行估算。

1.4进度安排

计划离不开进度安排，信息系统建设计划也不例外。

其关键在于对各环节所需时间的估计，网络系统施工、设备采购、软件采购等所需时间的估计只需考虑施工现场的环境、施工进度、采购的供应时间等，况且这些不构成系统建设的瓶颈，可以和信息系统软件开发并行。

而真正难以确定进度安排的和费用估算一样，仍然是软件开发。

对软件开发的时间进行估计，最终又转化为对软件开发工作量的估算。

现在我们来看一下如何对工作量进行分配和安排计划进度。

从信息系统的整个生命周期来看，如果把信息系统的生命期划分为建设期和使用维护期，信息系统建设约占总工作量的40%，信息系统使用维护占总工作量的60%。

而信息系统建设期的各阶段工作量分配从统计学角度来看如表3-1所示。

表3-1信息系统建设各阶段的工作量分配

阶段

工作量的百分比（%）

系统分析

概要设计

详细设计

编码

单元测试、组装测试和确认测试

网络施工和调试

系统测试

系统安装

表３-1所列数据只是一种统计结果，对于某个具体系统可能会有所变动，不能生搬硬套，但可依此为指导，具体情况具体分析。

另外，R.S.Pressman关于软件开发工作量分配提出了40-20-40的原则，即前期工作（计划、分析、设计）占40%，编码占20%，后期工作（测试、调试）占40%。

虽然对于信息系统软件开发来说，有些出入，但仍然对信息系统建设的各阶段工作量分配有借鉴意义。

该原则强调应重视前期和后期工作。

前期工作容易被忽视，主要原因是管理人员往往认为编码才是工作的开始，他们不了解前期工作的重要性，技术人员常常也急于编码，认为写出代码就算完成任务了。

后期工作也容易被忽视，大部分人认为编码出来就算完事了，对测试工作要占这么大的工作量没有思想准备。

所以要制定好进度计划，要求管理人员按计划控制技术人员按计划完成任务。

进度安排是信息系统建设计划工作中一项最困难的任务，计划人员要把可用资源与项目工作量协调好，要考虑各项任务之间的相互依赖关系，尽可能并行安排某些工作，预见可能出现问题和项目的瓶颈，并提出处理意见。

最后制定出计划进度表，其格式如表3-2所示，其中完成任务所需时间是根据工作量来估计的。

表3-2×××计划进度表

时间

任务

···

任务1

任务2

任务3

任务n

工作量总计

···

1.5网络图

采用网络计划技术编制网络图，确定关键路径，其方法如3.4.3小节所述。

1.6专题计划

信息系统建设过程中为保证某些细节工作能够顺利完成，并保证工作质量，常制定一些专项或专题计划。

这些专题计划包括质量保证计划、配置管理计划、测试计划、培训计划、信息准备计划、系统切换计划等。

2关键技术

2.1软件开发工作量和时间估算方法

软件开发的总时间和总工作量的估算策略有两种。

一种是自顶向下，即首先对整个项目的总开发时间和总工作量进行估算，然后分解到各阶段、步骤和工作单元。

另一种是自底向上，即首先估计各工作单元所需的时间和工作量，然后相加，得到各步骤和阶段直至整个项目的总工作量和总时间。

无论采取哪种思路，都必须使用一定的方法，常用的有以下三种：

（1）专家估算法

专家估算法依靠一个或多个专家，对要求的项目做出估计，其准确程度取决于专家对估算项目的定性参数的了解和经验。

该方法适宜于自顶向下的策略。

（2）类推估算法

对于自顶向下策略，类推估算法是将要估算的项目的总体参数与类似项目进行直接比较从而获得结果。

对于自底向上策略，类推估算法是将具有相似条件的工作单元进行比较获得估算结果。

（3）算式估算法

经验表明，软件开发的人力投入M与软件项目的指令数L存在如下关系：

（3-10）

其中P为常数，单位为指令数/人-日。

使用该公式，必须用专家估算法和类推估算法估算指令数L和P值。

而且其中L是源指令数还是目标指令数、是否包含未交付的试验指令、P值如何选择、是否包括系统分析、是否包括质量保证和项目管理等，难以界定。

因此式（3-10）实际使用存在许多困难。

大量的研究发现，对式（3-10）稍作修改，得

（3-11）

式（3-11）却与实际统计数据惊人一致，该式也被称为幂定律算法。

其中E为到交付使用为止的总的开发工作量，单位为人-月；S为源指令数，不包括注释，但包括数据说明、公式或类似的语句；常数r和c为校正因子，若S的单位为

条，E的单位为人-月，则r一般在1到5内取值，c的取值在0.9到1.5之间。

2.2软件开发工作量和时间估算模型

（1）IBM模型

1977年Walston和Felix对IBM联合分部负责的60个项目进行统计分析，用最小二乘法拟合，达到下列估算公式：

（3-12）

其中：

E为工作量，单位为人-月；D为项目持续时间，单位为月；P为工作人员数，单位为人；DOC为文档页数；S为源代码行数，单位为千条。

（2）SLIM模型

1979年附近，Putman对50各较大规模的软件系统成本进行估算研究，提出SLIM估算公式：

（3-13）

其中：

S和

分别表示可交付的源指令数（单位为千条）和开发时间（单位为年）；K是整个软件生存期内的总工作量，E为总开发工作量，单位为人-年；

是根据经验数据确定的常数，表示开发技术的先进性级别。

如果软件开发环境较差，没有采用一定的开发方法，缺少文档和评审管理，则取

；如果软件开发环境一般，采用适当的开发方法，有文档和评审管理，则取

；如果软件开发环境很好，采用自动生成工具和技术，文档管理自动化，评审程序化，则取

。

（3）COCOMO模型

1981年Boehm公布了他的结构性成本模型COCOMO（ConstructiveCostModel）。

基本计算公式为

（3-14）

其中E为总开发工作量，T为总开发时间，S为源指令数。

r、c、a和b为常数，取决于软件的类型。

Boehm定义了三种形式的COCOMO模型，分别为基本COCOMO模型、中间COCOMO模型和详细COCOMO模型。

表3-3、3-4分别列出了基本和中间模型的常数。

它们应用自顶向下的策略确定工作量。

表3-3软件成本估算的基本COCOMO模型常数

软件类型

结构型

2.4

1.05

2.5

0.38

半独立型

3.0

1.12

2.5

0.35

嵌入型

3.6

1.20

2.5

0.32

表3-4软件成本估算的中间COCOMO模型常数

软件类型

结构型

3.2

1.05

2.5

0.38

半独立型

3.0

1.12

2.5

0.35

嵌入型

2.8

1.20

2.5

0.32

详细的COCOMO模型采用自底向上的策略，首先把系统分为子系统、模块等层次，然后估算底层模块的工作量，逐层向上求和，最后获得整个系统的工作量。

COCOMO模型被广泛用于实际，信息系统应用软件大部分属于结构型，少数是半独立型。

2.3功能模块工作量的成本估算方法

在信息系统应用软件开发过程中，最常用的办法是将系统分解成子系统，子系统分解成模块，然后估算每个功能模块的在软件开发各阶段的工作量。

工作量的单位一般用人-月，也有少数用人-年和人-日。

考虑软件开发各阶段的工作性质和对人力技术要求的不同，确定各阶段单位工作量成本，从而估算出软件开发成本。

总成本计算公式为：

（3-15）

其中：

C为总成本，N为模块数，

为i阶段成本，

为i阶段工作量，

为i阶段单位工作量成本。

下面，通过某汽车配件销售信息系统开发的成本估算，说明该方法的估算步骤，估算过程和结果如表3-5所示。

【例】假设有一家汽车配件公司向顾客供应汽车配件，顾客是汽车用户或是汽车修配厂，配件公司的货源来自各种不同的配件制造工厂或批发商。

顾客可以当时购买，也可以预先订货，公司负责托运。

该公司拥有顾客7000多户，经营的汽车配件有8000多种，每一品种有若干种规格，总计约有2万种规格，如果考虑到同品种，同规格，但是不同厂家制造的零配件，则有6万多种。

这家汽车配件公司年销售额1.5亿元，职工600余人。

公司主要业务是根据顾客的订货要求，收款，开发票，配送汽车配件，配件不足从供应商处批发进货。

（1）确定软件开发方法，划分开发阶段。

本例将软件开发分解为系统分析、系统设计、代码编写、测试四个工作阶段。

其中分析和设计阶段包括项目工作计划和测试计划的制定过程。

（2）划分功能模块或子系统。

大型信息系统可先分解系统成子系统，再将子系统分解成模块，模块再分成子模块，然后自底向上，分层估算。

本例直接将系统分解成采购管理、销售管理和会计账务三个模块。

（3）确定每个功能模块的工作量。

对每个功能模块分阶段估算其工作量，即完成该任务所需要的人-月数。

表3-5某汽车配件销售信息系统开发成本估算表

功能模块

系统分析

系统设计

代码编写

测试

总计

采购管理

4.5

4.0

3.0

3.5

销售管理

7.0

4.5

5.5

4.5

库存管理

8.5

6.0

7.0

10.0

会计账务

4.0

3.5

2.5

2.0

工作量汇总（人-月）

24.0

18.0

20.0

80.0

单位工作量成本

（元/人-月）

8000

6000

3000

2000

成本（元）

192000

108000

54000

40000

（4）确定各阶段单位工作量成本。

根据各阶段的工作性质、所需人员的技术等级、国家和地区的薪酬标准、合理利润率和市场供给关系等，估算单位工作量成本。

本例假定开发单位位于合肥市。

（5）统计各阶段的工作量和成本，计算总工作量和总成本。

2.4开发进度估算办法

前面介绍的内容，重点是对软件工作量的估算，有些未对开发时间作出估计。

这里着重讨论开发时间与工作量之间的关系，进而安排工作进度。

假设开发工作量估算值为E，如果在规定的T时间内完成，则和需要投入的人力M之间应满足

。

但是，软件项目的工作量和开发时间往往不能相互独立，Brooks定律指出这种现象的最极端情况是：

为计划不合理的项目增加人员只会越增越乱，甚至会使进度更慢。

一些研究人员发现，开发时间和开发工作量之间满足：

（3-16）

其中a和b为经验常数，习惯上E的单位为人-月，T的单位为月，

。

由式（3-16）可以看出，软件开发时间和软件开发工作量的0.25到0.4次幂成正比，就是说要花很高的代价才能使开发时间稍有缩短，其下限是

，此时正好与Putnam的SLIM模型相吻合，表明无论增加多少人员，也不能提高开发进度。

因为增加的这一部分工作人员的工作量都消耗在保持项目人员之间通信的开销上了。

信息系统应用软件开发各阶段的进度安排可参照表3-6。

表3-6信息系统应用软件开发各阶段的进度分配

阶段

占总开发进度的百分比

系统分析

20～40

系统设计

15～25

代码编写

15～40

测试

20～25

3信息系统建设计划任务书格式

1.引言

1.1计划的目的

1.2范围和目标

1.2.1范围描述

1.2.2主要功能

1.2.3性能

1.2.4管理和技术约束

2.估算

2.1使用的历史数据

2.2使用的评估技术

2.3工作量、成本、时间估算

3.日程

3.1工作分解

3.2进度表（甘特图）

3.3资源表

4.资源

4.1人员

4.2硬件和软件

4.3特别资源

5.人员组织

5.1组织结构

5.2管理报告

6.跟踪和控制机制

6.1质量保证和控制

6.2变化管理和控制

7.专题计划计划要点

4专题计划

4.1软件质量保证计划

在进行软件开发前，应制定《软件质量保证计划》。

目前较常用的是ANSI/IEEESTOL730--1984，983--1986标准，包括以下内容：

1计划目的

2参考文献

3管理

3.1组织

3.2任务

3.3责任

4文档

4.1目的

4.2要求的软件工程文档

4.3其它文档

5标准和约定

5.1目的

5.2约定

6评审和审计

6.1目的

6.2评审要求

6.2.1软件需求的评审

6.2.2设计评审

6.2.3软件验证和确认评审

6.2.4功能评审

6.2.5物理评审

6.2.6内部过程评审

6.2.7管理评审

7测试

8问题报告和改正活动

9工具、技术和方法

10媒体控制

11供应者控制

12记录、收集、维护和保密

13培训

14风险管理

4.2配置管理计划

软件配置管理，简称SCM（SoftwareConfigurationManagement的缩写），是在项目开发中，标识、控制和管理软件变更的一种管理。

配置管理的使用取决于项目规模和复杂性以及风险水平。

软件的规模越大，配置管理就显得越重要。

本计划可用于对信息系统项目进行软件配置管理，提高软件质量，降低软件开发成本。

参照ISO9000程序，其主要内容如下：

1引言

1.1目的

1.2术语定义

1.3参考资料

2.软件配置

2.1软件配置环境

2.1.1服务器软件环境

2.1.2硬件环境

2.1.3配置管理客户端

2.2软件配置项

2.3配置管理员

3软件配置管理计划

3.1建立示例配置库

3.2配置标识管理

3.3配置库控制

3.4配置的检查和评审

3.5配置库的备份

3.6配置管理计划的修订

3.7配置管理计划附属文档

4.阶段任务完成标志表

4.3测试计划

这里所说的测试，主要是指整个信息系统应用软件的组装测试和确认测试。

本文件包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整理方法及评价准则。

具体的内容要求如下：

1引言

1.1编写目的

1.2背景

1.3定义

1.4参考资料

2计划

2.1软件说明

2.2测试内容

2.3测试1（标识符）

2.3.1进度安排

2.3.2条件

2.3.3测试资料

2.3.4测试培训

2.4测试2（标识符）

3测试设计说明

3.1测试l（标识符）

3.1.1控制

3.1.2输入

3.1.3输出

3.1.4过程

3.2测试2（标识符）

4评价准则

4.1范围

4.2数据整理

4.3评价尺度

4.4其它计划

除上面介绍的三个主要计划外，还有一些专题计划，如

网络施工计划、培训计划、信息准备计划和系统切换计

划等。

这些计划比较简单，主要是围绕人力、财力和物

力资源的调配、工作进度安排、评价标准制定等，这里不在一一介绍。

展开阅读全文