政府短信平台项目可行性分析报告.docx

政府短信平台项目可行性分析报告.docx

《政府短信平台项目可行性分析报告.docx》由会员分享，可在线阅读，更多相关《政府短信平台项目可行性分析报告.docx（24页珍藏版）》请在冰豆网上搜索。

政府短信平台项目可行性分析报告

目录

1.引言5

1.1.文档目的5

1.2.读者对象5

1.3.参考文献5

1.4.术语与缩写解释5

2.项目概述5

2.1.项目名称5

2.2.项目背景5

2.3.项目的基本内容5

2.4.项目实施目标5

3.系统实现方案6

3.1.业务描述6

3.2.系统体系结构方案6

3.3.功能需求6

3.4.数据流图（可选）6

4.技术方案6

4.1.采用的关键技术6

4.2.接口处理方案（可选）6

4.3.对原有系统修改方案（可选）6

4.4.系统主要特点6

4.5.系统局限性7

4.6.技术条件可行性7

5.项目实施计划7

5.1.项目组织架构7

5.2.项目里程碑7

5.3.研发费用估算8

5.4.维护开发费用估算9

5.5.项目实施与客户服务费用估算9

5.5.1.项目实施费用估算9

5.5.2.客户服务费用估算10

6.产品市场分析（可选）11

6.1.市场背景11

6.2.客户需求11

6.3.目标客户11

6.4.竞争对手分析12

6.5.政策分析12

7.市场营销计划（可选）12

7.1.产品盈利模式和销售目标12

7.2.销售策略和价格分析12

7.3.销售方式和渠道12

8.风险分析12

9.成本效益分析12

9.1.成本费用估算表12

9.2.销售收入估算表13

9.3.现金流量表14

10.可行性分析结论14

1.

引言

1.1.文档目的

本文为宁波市江东区政府短信平台的可行性分析报告。

该报告的主要分析短信平台的设计思想、结构特点、数据处理等方面内容，描述本系统的设计细节。

本说明书与《需求规格说明书》、《概要设计说明书》、《数据库设计说明书》组成系统的设计与实现的主要技术文档。

本文档经各方仔细审查和认可后，将作为该项目的重要相关文件。

1.2.读者对象

　　江东区政府信息中心科长以及各科员。

1.3.参考文献

⏹《GB/T9385计算成本软件需求说明编制指南》

⏹《GB/T9704-1999国家行政机关公文格式》

⏹《政府采购竞争性谈判文件编号NBZFCG2007169T》

术语与缩写解释

术语

解释

参与者

是与系统、子系统或类发生交互作用的外部用户、进程其他系统的理想化概念。

MVC模式

模型／界面／控制器（Model／View／Controller，MVC编程技术。

2.项目概述

2.1.项目名称

软件系统名称：

宁波市江东区政府短信平台

缩写简称：

短信平台

开发单位：

宁波国研软件技术有限公司

2.2.项目背景

随着国民经济信息化进程的推动，电子政务的逐步普及，政府在实际的工作中对于电子政务的应用越来越深入，同时对于电子政务的需求也越来越多，原来的电子政务概念的内容已经不能满足现代政府的实际需求。

随着时代的进步，电子政务也已经有了新的发展。

在这种环境下，“移动政务”应运而生。

所谓移动政务——G2M（GovernmenttoMobile）是指对通过移动通讯网络进行数据传输并且利用移动终端（手机用户、具通讯功能的PDA用户等）开展各种政务管理活动的一种新型的电子政务模式。

短信作为移动政务的最基本、有效的实现方式，在电子政务中发挥越来越重要的角色。

各个政府职能部门对短信应用有着不同需求。

另外短信还可以应用到政府的整个的工作流之中，如进行工作流程的提醒、会议通知、紧急事务的通知等需要及时、准确地发布给大量人群的信息的公布。

短信的应用不仅可以帮助管理者节约时间、提高工作效率，而且节约了通讯成本，在针对大量人群进行信息的海量发布时其价格优势更加凸现出来。

短信平台作为宁波市移动政务的重要组成部分，包括相应的信息处理，短信应用挂接配置，实现对各个政府部门的应用系统开放短信通道，各政府部门的应用系统可以利用该平台，更好地对广大市民提供各类咨询服务，加强政府与市民之间的互动交流。

推进宁波市政府“服务型政府”的建设。

2.3.项目的基本内容

本产品实现对各个短信业务的配置维护，通过简单的配置实现与各个业务系统数据的对接，并可以通过配置发布相关短信应用业务。

提供统一的短信支撑平台实现短信收发；通过统一的短信服务代码对公众提供一个友好的易于交互的界面，实现与公众的交流；提供直观有效的监控手段，实现对平台，对各个短信应用有效性的监控；实现短信收发WebService接口。

2.4.项目实施目标

1.软件错误限制：

不存在引起系统不能继续运转的错误；

不存在业务流程错误

引起查询交易错误或不能运转的错误不超过5个；

在某种状态下交易不对但存在其它现成取代方案的错误小于10个；

功能限制：

满足《需求规格说明书》的要求

2.文档验收合格标准：

文档验收以抽样方式进行，抽样率为50%，在验收的文档中：

错误的总字数不超过该文档总字数的0.5%；

描述某一独立完成的功能/章节无错误。

3.系统实现方案

3.1.业务描述

系统主要运行的程序有：

应用服务器，JSP、JAVA程序和数据库。

程序之间的运行是基于MVC模式。

3.2.系统体系结构方案

宁波市江东区政府短信平台说明：

网络

基础

设备

机房环境设备

计算机硬件设备均存放在区政府信息中心资源共享服务器区，机房设备、网络交换机、防火墙均使用区政府现有设备

网络交换设备

安全防护设备

服务器

主机系统

应用系统服务器（

数据库服务器）

提供应用发布、提供后台数据、存储使用

系统支撑组件

操作系统

Windows2003操作系统

数据库

ORACLE数据库

中间件

AqulogicServiceBus

3.3.功能需求

短信平台，在业务设计上，将分开设计为三大工作模块：

1.中心支撑模块：

提供两类短信通道，一类是由原区政府的一期短信业务所提供的接口进行短信收发（这里可以保留一期短信平台，并依据一期短信通道进行收发）；一类是通过与“移动通信库”、“联通通信库”直连的模式进行短信收发（在此，将覆盖实现一期系统中的关于短信收发的接口，并完全覆盖一期系统所有功能，以此逐步替换一期的短信平台）。

当接收到查询短信时，系统将鉴别查询需求，组织给各个实际的短信业务进行信息查询。

2.监控模块：

在整套系统中扮演监控者角色，可以通过该系统进行各类限制参数的设置，并查阅系统的工作过程和状况。

3.短信应用模块：

分析查询要求，然后查询出结果进行短信组装，发送给相关用户。

“短信平台”的短信通道为配置模式，系统本身支持WebService接口式通道，信息库直连式通道两类（如，针对一期数据中心的短信业务的短信收发通道，则可以采用WebService接口式通道；同时，为了提高性能和通道短信流速，系统将额外配置信息库直连式通道，可以绕过旧的短信业务直接和“移动信息库”和“联通信息库”进行连接）。

4.技术方案

4.1.采用的关键技术

数据库选型

随着信息技术的飞速发展，数据处理不仅在数量上要求越来越大，而且在质量上也要求越来越高。

操作系统的稳定对数据库来说是十分紧要的，在数据库可操作平台上，Oracle可在所有主流平台上运行，Oracle数据库采用开放的策略目标，它使得客户可以选择一种最适合他们特定需要的解决方案。

通常管理者可以利用很多种第三方应用程序、工具。

对开发商来说是很大的支持。

而SQLServer却只能在Windows上运行了，这个就显得比较单调了，但SQLSever在Window平台上的表现，和Windows操作系统的整体结合程度，使用方便性，和Microsoft开发平台的整合性都比Oracle强的很多。

当然，Windows操作系统的稳定性及可靠性大家是有目共睹的，再说Microsoft公司的策略目标是将客户都锁定到Windows平台的环境当中，只有随着Windows性能的改善，SQLServer才能进一步提高。

从操作平台这点上Oracle是完全优胜于SQLServer的了。

从资料上可以看到，Oracle的安全认证获得最高认证级别的ISO标准认证，而SQLServer并没有获得什么安全认证。

这方面证明了Oracle的安全性是高于SQLServer的。

操作上SQLServer明显要比Orcale简单，在针对J2EE和.NET的开发平台，区别的基本就是Oracle和SQLServer不同，Oracle的界面基本是基于Java的，大部分的工具是Dos界面的，甚至SQLPlus也是，SQLServer是跟VB一样，全图形界面，很少见到DOS窗口。

SQLServer中的企业管理器给用户提供一个全图形界面的集成管理控制台来集中管理多个服务器。

Oracle也有自己的企业管理器，而且它的性能在某些方面甚至超过了SQLServer的企业管理器，但它安装较为困难。

Orcale数据库和SQLServer数据库那个更快?

其实是一个很难答的问题，因为存在许多不定因素，包括处理类型、数据分布以及硬件基础设施等。

最终，基于性能最终考虑使用Orcale数据库，版本选用Orcale10g企业版。

由于本项目在使用数据库的过程中，最集中使用的功能为存储及查询管理调用，故在数据库定向上，将基于“存储型数据库”进行优化，开辟较大的一块连续空间做为存储文件位置，并扩大信息索引的使用率，达到最优使用效果。

存储模型划分

为了明确资源管理，并梳理合理的资源存储模型，在存储设计上，将信息切割成四个存储模块（每个存储模块通常有一系列表和视图、存储过程、序列、数据库调用函数组合而成）：

配置库、业务库、接口库。

配置库：

核心库，主要用于存储管理和配置信息，这类信息的删改在设计上，需强制执行“镜像恢复数据预留”——即删改时候，将删改动作前后的数据做冗余镜像到“操作记录表”。

当删改的信息属于违规操作或者被管理员判定为无效行为时，系统可以通过恢复机制修复原来的配置项。

业务库：

通常又称信息资源库，主要用于存储所有业务相关或中间生成的数据，本类数据通常需记录信息的最后修改时间和执行人，不强制执行“镜像恢复数据预留”，如需恢复一段时间前的数据，通常需还原相应时间断的数据备份来实现。

这类库中，信息增长率较大或者信息量较大的表，需开辟对应的历史表，当数据产生时间已经属于较久（通常为三年）以前时，则将信息挪动到历史表，这样可以加速对这些信息的使用时效。

接口库：

这类库是被强制归类出的冗余表，主要是为了合理避开接口传递和业务使用之间的联系。

因为接口传递操作一般都是高频率的刷新行为，如果直接执行在业务库上，则可能会影像到相应功能的调用速率。

同时，接口在开发和调试过程中，极易出现不稳定的情况，容易造成数据的损坏、丢失或出现大量无效数据，这样的隔离设置，可以减小接口不稳定对平台核心库的影像。

4.2.接口处理方案（可选）

数据调用接口

通过在短信平台上进行一系列的设置，则可支持对多个不同数据库的数据的采集工作。

该接口设计，主要是为了适应不同时期各个部门数据接入方式的变化。

（1）支持多种数据交换方式

不论应用层，还是数据层，不论是传统的基于数据库层面的信息交换、数据文件的导入导出，还是利用先进消息中间件构建可靠、可扩展、高效数据传输平台，系统均需支持。

（2）支持多种数据传输方式

既可以支持一般情况下的网络协议传输，也可以支持点对点（P2P）传输，同样也可以通过存储介质实现数据文件的导入导出。

（3）传输可靠性

短信平台必须保证用户数据能够可靠的传输到目的节点。

即使出现宕机或网络故障等情况，数据也能在系统和网络恢复后得到可靠传输。

（4）高效的系统响应效率

短信平台要保证数据库系统对数据库操作的高效响应，对频繁调用的服务、不频繁调用的服务和定时响应的服务都能够对请求做出快速的响应。

（5）系统可用性

短信平台必须具备高的可用性，在某个节点出现问题的情况下，不影响到其他节点的正常工作就显得尤其重要。

（6）系统可扩展性

宁波市江东区政府短信平台是一个庞大和长期的项目，系统良好的可扩展性就非常重要。

在整个系统不停机的情况下，扩展系统提供的应用服务。

同时支持节点的动态增加和删除，使得系统规模能够实现动态扩展，保证整个应用系统24小时工作。

（7）数据传输的安全性

系统对数据传输安全性有着极高的要求，短信平台需确保系统传输数据的安全性。

功能类接口

本系统在设计时，单独开辟了各部门的数据入库功能（含各部门数据打包或导出成一定格式的文件后，对这些数据文件进行解读，系统则根据解析规则进行数据解析，将数据纳入到临时汇总库），各部门的相关短信业务，则可以在其权限范围内，调阅和处理这些数据，并形成各类应用性短信，当然，系统可以通过自定义查询配置，支持一定权限的的用户直接查询和调用这些数据。

WebService接口

本系统在设计时，是基于ALSB（Bea公司的AqulogicServiceBus中间件）进行研发的，该中间件是基于SOA架构的一款产品，可以向外发布和监控系统所持有的WebService，使“短信平台”的各个功能处于可整合调用的状态。

4.3.系统主要特点

系统韧性

容错能力

系统可定期对因操作失误或未知原因造成的异常数据，进行智能化清理；因接口传递异常产生的残缺数据，系统可做特殊展现或自动标识其废弃；若接口工作异常，系统可自主向管理责任人发送短信。

故障恢复能力

系统数据每日完全备份一次，差异备份一次，作为故障紧急恢复用（除此外，硬件上，对数据库服务器进行双机热备，对应用服务器进行集群）。

系统柔软性

系统采用了功能组件化设计，使得系统在不同需求下，可以灵活屏蔽部分功能，并只需做简单的二次开发，即可产生新的功能。

系统强化了各类配置功能，使得配置后的系统业务逻辑更贴近各地的实际审批需求。

系统附属软件——对外通用联合接口，可以灵活支持各类不同数据要求的接口的变动。

4.4.技术条件可行性

技术风险:

本项目总体架构合理、数据配置通用易用、短信收发的并行处理能力快，在设计和研发过程中有效控制了技术风险。

人力风险:

本项目拥有熟悉短信收发机制和各种数据库管理系统的系统分析人员，熟悉计算机网络和系统运行环境的工程师，精通项目研发关键技术的软件人员以及熟悉软件项目管理的人员。

在项目实施过程中，人员保障充分

5.项目实施计划

5.1.项目组织架构

角色

职责

知识技能要求

建议人选、人数

工作时间

项目经理

实现项目目标的责任人，对项目预算、决算负责

1

200

项目技术经理

确定项目总体系统规划设计师，即项目技术的总体负责人；

1

100

项目成员

3

600

测试员

1

100

配置管理员/文档管理员

1

50

QA

1

250

其　　他

1

5.2.项目里程碑

项目计划采用的生命周期模型：

极限编程

项目分阶段实施，里程碑如下：

里程碑名称

工作内容

起止时间

里程碑输出成果

需求里程碑

调研用户需求

6月13日-7月4日

《用户需求说明书》

设计里程碑

产品详细设计

《详细设计说明书》

编码里程碑

开发编码

测试里程碑

测试用例

《系统测试报告》、《集成测试报告》

5.3.研发费用估算

备注：

1.如果开发阶段跨年份，请在年份中注明。

2.日人均成本包括工资、社保合福利费用,数据由人力资源部提供；

3．通讯费用包括：

固定电话和移动电话通信费用。

4．低值易耗品按人均500元/年，数据由财务部提供。

5.新增固定资产折旧：

新增资产总值按5年均摊

6.公共费用分摊：

包括公司办公场所租金、水电等；福州人均1.47w，上海人均4.65w，数据由财务部提供

7.内训和外训的培训直接费用；不包括培训期间的人力资源费用。

由人力资源部控制公司培训费用总量。

8.项目需要另外租借场地的费用

5.4.维护开发费用估算

项目预计维护周期：

　　　　年

该表可作为可行性分析报告的附件。

5.5.项目实施与客户服务费用估算

5.5.1.项目实施费用估算

该表可作为可行性分析报告的附件。

5.5.2.客户服务费用估算

该表可作为可行性分析报告的附件。

6.产品市场分析（可选）

目前市场上常见的短信平台解决方案主要用于短信群发，并提供短信类别管理、通讯录管理、用户权限管理、收发记录、收发接口等功能。

有基于“短信猫”和专用短信平台两种解决方案。

现有解决方案，无法满足多应用调用的需求。

不同的单位根据应用需求，分别组建各自的短信平台，效果参差不齐，资金重复投入。

6.1.市场背景

随着国民经济信息化进程的推动，电子政务的逐步普及，政府在实际的工作中对于电子政务的应用越来越深入，同时对于电子政务的需求也越来越多，原来的电子政务概念的内容已经不能满足现代政府的实际需求。

随着时代的进步，电子政务也已经有了新的发展。

在这种环境下，“移动政务”应运而生。

所谓移动政务——G2M（GovernmenttoMobile）是指对通过移动通讯网络进行数据传输并且利用移动终端（手机用户、具通讯功能的PDA用户等）开展各种政务管理活动的一种新型的电子政务模式。

短信作为移动政务的最基本、有效的实现方式，在电子政务中发挥越来越重要的角色。

各个政府职能部门对短信应用有着不同需求。

另外短信还可以应用到政府的整个的工作流之中，如进行工作流程的提醒、会议通知、紧急事务的通知等需要及时、准确地发布给大量人群的信息的公布。

短信的应用不仅可以帮助管理者节约时间、提高工作效率，而且节约了通讯成本，在针对大量人群进行信息的海量发布时其价格优势更加凸现出来。

短信平台作为宁波市移动政务的重要组成部分，包括相应的信息处理，短信应用挂接配置，实现对各个政府部门的应用系统开放短信通道，各政府部门的应用系统可以利用该平台，更好地对广大市民提供各类咨询服务，加强政府与市民之间的互动交流。

推进宁波市政府“服务型政府”的建设。

6.2.客户需求

　　目前手机短信的应用已经非常普及，在政府、企业中，只要建设了计算机网络软件系统，一般结合有手机短信的应用，例如利用手机短信发送待办事宜、各类通知等。

目前市场上常见的短信平台解决方案主要用于短信群发，并提供短信类别管理、通讯录管理、用户权限管理、收发记录、收发接口等功能，一般有基于“短信猫”和专用短信平台两种解决方案。

这些方案能够满足一般单位日常的短信收发需求，并通过收发接口为其它应用系统调用，从而使应用系统经过二次开发能够与手机短信相结合做到一定程度的交互。

但在遇到需要为很多应用系统提供通用、方便、灵活的调用，且并行处理要求极高的需求时，则往往无能为力。

6.3.目标客户

企业、政府、个人、组织等。

6.4.政策分析

通用短信支撑平台的应用涉及广大人民群众和政府相关部门，不排除由于国家或地方的政策法律调整导致平台无法推广的风险，另外也存在在系统应用中由于软件本身的问题以及其它方面引起的系统运行不正常，导致用户投诉甚至法律诉讼的风险。

7.市场营销计划（可选）

产品类项目必须填写。

7.1.产品盈利模式和销售目标

7.2.销售策略和价格分析

　　描述产品进行市场推广与销售的模式，并从客户的支付能力、同类产品的价格以及竞争角度分析产品价格走势。

7.3.销售方式和渠道

8.风险分析

技术风险

本项目总体架构合理、数据配置通用易用、短信收发的并行处理能力快，在设计和研发过程中有效控制了技术风险。

人力风险

本项目拥有熟悉短信收发机制和各种数据库管理系统的系统分析人员，熟悉计算机网络和系统运行环境的工程师，精通项目研发关键技术的软件人员以及熟悉软件项目管理的人员。

在项目实施过程中，人员保障充分

9.成本效益分析

9.1.成本费用估算表

该表可作为可行性分析报告的附件。

注：

1.研发费用主要是开发期研发人员工资、差旅费、培训费、通讯费用和公摊费用等，见5.3研发费用估算。

2.维护开发费用主要是维护开发期的人员工资、差旅费、培训费、通讯费用和公摊费用等，见5.4维护开发费用估算。

3.项目实施/客户服务费用主要是系统安装、实施、培训用户费用和售后服务费用，见5.5项目实施与客户服务费用估算的单个工程点费用*实施工程点数量。

4.销售费用：

销售人员的人力资源费用（工资、社保、福利）和产品宣称推广费用（广告费、产品发布会费用、招待费用、销售业务费、通讯费用等），由销售管理部提供。

9.2.销售收入估算表

该表可作为可行性分析报告的附件。

9.3.现金流量表

该表可作为可行性分析报告的附件。

10.可行性分析结论

综合各方面的评估结论，得出研究结论。

●可以立即开始进行

●目录

●1.引言5

●1.1.文档目的5

●1.2.读者对象5

●1.3.参考文献5

●1.4.术语与缩写解释5

●2.项目概述5

●2.1.项目名称5

●2.2.项目背景5

●2.3.项目的基本内容5

●2.4.项目实施目标5

●3.系统实现方案6

●3.1.业务描述6

●3.2.系统体系结构方案6

●3.3.功能需求6

●3.4.数据流图（可选）6

●4.技术方案6

●4.1.采用的关键技术6

●4.2.接口处理方案（可选）6

●4.3.对原有系统修改方案（可选）6

●4.4.系统主要特点6

●4.5.系统局限性7

●4.6.技术条件可行性7

●5.项目实施计划7

●5.1.项目组织架构7

●5.2.项目里程碑7

●5.3.研发费用估算8

●5.4.维护开发费用估算9

●5.5.项目实施与客户服务费用估算9

●5.5.1.项目实施费用估算9

●5.5.2.客户服务费用估算10

●6.产品市场分析（可选）11

●6.1.市场背景11

●6.2.客户需求11

●6.3.目标客户11

●6.4.竞争对手分析12

●6.5.政策分析12

●7.市场营销计划（可选）12

●7.1.产品盈利模式和销售目标12

●7.2.销售策略和价格分析12

●7.3.销售方式和渠道12

●8.风险分析12

●9.成本效益分析12

●9.1.成本费用估算表12

●9.2.销售收入估算表13

●9.3.现金流量表14

●10.可行性分析结论14

●