1引言 4

1.1编写目的 4

1.2背景 4

1.3定义 5

1.4参考资料 5

2任务概述 6

2.1目标 6

2.2用户的特点 6

2.2.1办公室（新闻中心） 6

2.2.2各级领导 7

2.2.3专业部门 8

3系统总体设计 9

3.1系统平台总体框架 9

3.2系统业务总体设计 10

3.3 省公司侧业务流程设计 11

3.4 地市局侧业务流程设计 11

4需求规定 12

4.1对功能的规定 12

4.1.1舆情信息采集 13

4.1.2舆情通知、报告 14

4.1.3突发新闻信息管理 22

4.1.4应对策略管理 26

4.1.5模板管理 27

4.1.6通用功能 28

4.2对性能的规定 29

4.2.1精度 29

4.2.2时间特性要求 29

4.2.3灵活性 29

4.2.1精度 30

4.2.2时间特性要求 30

4.2.3灵活性 30

4.3 友好提示要求 30

4.3 操作规范要求 31

4.4其他专门要求 31

4.4.1系统安全需求 31

4.4.2可维护性需求 31

5运行环境规定 32

5.1设备 32

5.1.1应用服务器环境 32

5.1.2数据库应用服务器 33

软件需求说明书的编写提示

1引言

1.1编写目的

本文档描述了舆情管理系统业务情况，供各相关的系统开发人员或者其他相关人员来了解有关舆情信息采集、舆情处置通知单、舆情处置报告单、突发应急事件报送、应对策略管理、舆情信息发布、舆情处理过程监控等业务。同时，本文档也作为舆情管理系统研发设计工作的主要依据。

阅读者主要有公司信息部、办公室、新闻中心、专业部门负责突发事件联络人，系统开发项目组、平台架构组、数据库设计组、应用系统设计开发组、支持服务组等。

1.2背景

舆情是民众关于现实社会中各种现象、问题所表达的政治信念、态度、意见和情绪的总和，尤其是在信息技术高速发展的当今，信息传播的速度是越来越快，影响范围是越来越大。随着互联网的发展，特别是近两年微博的出现，当前已进入自媒体时代。互联网上一件小的事情经过微博的传播，意见领袖及传统媒体的跟进，就可能形成一起大的舆情事件。

在我国社会转型期间，各类突发事件呈上升趋势，其内容涉及社会各行各业，并在某种程度上成为影响社会安定的重要因素，特别是越来越高涨的公众主权意识和效果越来越明显的舆论监督，都推动着人们把更多的目光投向公用事业单位和企业。作为提供公共产品的企业，其国企自然垄断性、公用性、服务性的特点，决定其必然成为社会关注的焦点，较容易引发突发新闻事件，给企业造成负面影响，带来不稳定因素。如何建立预防、应对、处置机制，有效维护企业的声誉形象，确保企业和谐稳定发展，引起了企业领导上下的高度关注。

为了更好的贯彻并落实提出“以客户为中心”的价值观转变，真正做到“由内部管理转向外部服务”的工作重点，公司就有必要对下辖的19个机构已发生的突发新闻事件、安全事件、焦点信息、热点信息等的负面影响进行及时有效控制和引导，建立一套可快速响应、信息全面可靠的舆情管理系统平台，以更好的解决消除或降低负面影响，提高用户满意度，从而实现突发事件的可控、在控。

1.3定义

公司舆情管理系统就是要通过建立省公司、地市和区多级联动舆情监控机制，实现对媒体上出现的对公司或所属单位的工作和形象产生不良影响的媒体报道或言论，所引发的反应、言论、评论和后续报道等综合舆论情况的监测、控制和化解等具体措施。

公司对舆情的监控主要通过网络、新闻、电话等多种方式对舆情信息进行监测与记录，并将采集到的各类舆情信息进行汇总、分析、研判与分级，针对不同的级别采取不同的处置措施，并及时将处置措施和信息按照内部应急方式进行通知和报告。

通过舆情管理系统实现对内部、外部舆论信息的分类整理、危机处理、内外部信息发布、舆情跟踪，确保将舆情事件发生后产生的不良影响控制在有效范围内，提高客户的服务质量。

1.4参考资料

《公司新闻宣传工作管理办法》

《公司突发危机事件新闻发布管理办法》

《公司新闻宣传工作管理制度》

《公司新闻危机处置应急预案》

《公司舆情监测与处置业务指导书》

2任务概述

2.1目标

公司传统的舆情处置流程为基础，结合建设的 “营配信息集成系统”、“营销系统”和“大范围管理系统”等为主要基础数据信息来源，实现对舆情发生过程进行实时处理、跟踪和结果反馈，并在不同阶段采用不同的模板以短信、发文、大屏输出等多种展现方式呈现给不同用户（领导、各级管理单位、新闻媒体等其它介质）可视化的界面，确保舆情事件在整个过程中以统一的口径告知相关单位并对外发布信息。

2.2用户的特点

2.2.1办公室（新闻中心）

2.2.1.1  省公司办公室（新闻中心）

1. 对全省各单位舆情的监测。根据舆情状况进行舆情分析、分级。及时向有关部门及单位通报舆情信息。按照网公司办公厅的要求进行舆情处置情况报告。及时对处置后的舆情进行跟踪。
2. 协助业务部门处理省公司层面的负面舆情事件。与省级或以上的新闻媒体的沟通协调工作。开展初期引导工作或其他相关工作。
3. 指导直属单位的舆情处置工作。必要时根据舆情分析情况发布新闻宣传工作指引。
4. 建立舆情登记台账，记录舆情信息来源、主要内容。节假日期间，由舆情值班人员进行监测并初步处置。

2.2.1.2  市局办公室（新闻中心）

1. 对市局各专业领域部门和各区局办公室上报的舆情信息进行统一分类整理筛选、汇总、初审，再汇报领导审批后，按需上报给省办公室或处置；
2. 人工的按照符合条件的舆情信息进行录取；
3. 自动的按获取原有业务系统（如：营销系统等）提供相关信息或其它事件类信息；
4. 发布处理省办公室通知或者省市领导审批通过的舆情信息，分级情况较低的可以自行处理、发布、跟进。
5. 根据舆情状况进行舆情分析、分级。及时向有关部门及单位通报舆情信息。按照网、省公司办公厅的要求进行舆情处置情况报告。及时对处置后的舆情进行跟踪。开展初期引导工作或其他相关工作。

2.2.1.3  区局办公室

1. 对区局各专业领域部门上报的舆情信息进行汇总；
2. 人工的按照符合条件的舆情信息进行录取；
3. 自动的按获取原有业务系统（如：营销系统等）提供相关信息或其它事件类信息；
4. 把获取的舆情信息提交到市办公室。

2.2.2各级领导

各级各部门领导为相关的舆情汇报告知、审批人员，分管、直管或者协管舆情的处置进展；

2.2.3专业部门

2.2.3.1  市场部（客服）

实时跟进舆情的处理情况，并及时的反馈给客户，对舆情处置做专业领域的支持；

2.2.3.2  生产

实时跟进舆情的处理情况，及时处理好舆情事件，并及时的反馈现场处理情况，对舆情处置做专业领域的支持；

2.2.3.3  基建部

实时跟进舆情的处理情况，及时处理好舆情事件，对舆情处置做专业领域的支持；

2.2.3.4  调度中心

实时跟进舆情的处理情况，及时处理好舆情事件，对舆情处置做专业领域的支持；

2.2.3.5  信息部

1. 开发、维护舆情管理系统平台，通过技术手段实现舆情信息的及时获取传递等。
2. 组织平台推广工作，保证平台稳定运行。

3系统总体设计

3.1系统平台总体框架

针对现有的舆情处理各环节、各过程进行分析整理后，舆情整个过程可框架如下图所示：

     按照系统平台要求和需求，系统定位采用于省公司统一平台部署，省级和地市局都定义为不同角色，系统网络拓扑如下：

3.2系统业务总体设计

为确保公司舆情多级管控流程的固化和落实，需要建立一套完整，规范的舆情管理系统平台是有必要的。通过舆情管理系统平台实现对舆情的全程了解、采取相应措施来有效控制、引导以及处理。

舆情管理系统涉及到网公司、省公司、地市局、区局四级管理机构，内部信息收集机制完成各地市局的现场信息收集，在省公司内部完成信息汇总、分析，最后按照预定的处理机制和分发规则对外及时发布信息。

地市局是按照省公司发布的舆情信息内容，或者在省公司分发舆情信息前，就可将管辖范围内存在的潜在舆论事件相关信息主动发送回省公司侧，提前做好舆情事件应急措施，将不良事件影响范围控制在最小范围内。

舆情监控平台系统业务架构设计如下图所示：

3.3 省公司侧业务流程设计

3.4 地市局侧业务流程设计

4需求规定 

4.1对功能的规定

舆情管理系统总体框架如下图所示，包括省公司和地市两侧的功能，可概括为舆情信息采集、舆情通知管理、舆情处置管理、突发新闻信息管理、舆情对策管理、模板管理、通用功能等。系统整体结构灵活多变，采取模块化设计。

4.1.1舆情信息采集

4.1.1.1、业务目标:

主要是通过手动和自动2种方式，手动具体可参考属于人工的按照符合条件的信息进行录取并可进行下一步的应用和操作；自动是指系统通过接口的方式从营配信息、营销等系统获取数据信息来源。

将本地采集的舆情信息录入到舆情管理系统，通过及时上报给相关的主管领导，在得到主管领导的审核批示后，再上传至省公司。省公司将对上传的舆情信息进行汇总后做进一步的分析。

4.1.1.2、业务用例

暂无

4.1.1.3、功能分析

    该页面上可以通过舆情信息的标题、数据的来源方式、舆情信息的媒介方式来点击查询按钮查询符合条件的舆情工单信息，通过新增按钮可以进入舆情信息新增页面，并且能对每一条舆情信息编辑操作。

分页显示数据：来自省公司下发、营销系统、配网系统、其他手动录入的舆情信息。

4.1.1.4、界面设计

4.1.2舆情通知、报告

4.1.2.1、业务目标

按照危机应对策略中的要求实时将舆情涉及的现场情况填写、上传到舆情管理系统平台，通过系统将舆情信息进行审核后，采用统一的机制定期对外发布最新信息。

4.1.2.2、业务用例

暂无

4.1.2.3、功能分析

根据拟办部门、舆情类型、舆情标题等条件对舆情信息进行查询并以列表的方式分页显示，可以对单条舆情信息进行处理。舆情处置中包括以下的功能步骤：

    4.1.2.3.1、舆情通知单签收

          4.1.2.3.1.1、业务目标

          当发生舆情事件时，事发单位或专业部门上报舆情情况。办公室接受到舆情通知单后，对舆情通知单进行签收操作。

4.1.2.3.1.2、业务用例

暂无

4.1.2.3.1.3、功能分析

 签收页面显示舆情事件发生的事发单位、工单编号、拟办部门、抄送部门、舆情事件的基本情况、分析、处理意见等信息，页面上可以通过查看流程图的按钮进行流程查看，通过签收按钮进行舆情信息工单的签收，返回按钮可以返回到舆情信息显示页面。签收页面上还显示出舆情信息工单的流程状态列表，对工单的处理进行跟踪。

4.1.2.3.1.4、界面设计

    4.1.2.3.2、舆情信息分级

4.1.2.3.2.1、业务目标

系统具备对舆情事件所涉及的报道媒体、报道机构、重要领导人关注、指示、重要意见领袖参与程度等内容制定出舆情分发规则，确定舆情所涉及的管辖区域、影响范围、危机等级等不同的维度。

签收到相关的舆情信息后，可通过人工或者自动按照设定的分发规则将舆情信息进行汇总分析，  根据舆情事件发生后的影响情况，是否死人，传播范围的程度对舆情事件进行分级。

4.1.2.3.2.2、业务用例

暂无

4.1.2.3.2.3、功能分析

页面显示舆情事件发生的事发单位、工单编号、拟办部门、抄送部门、舆情事件的基本情况、分析、处理意见等信息，页面上可以通过查看流程图的按钮进行流程查看，在研判时可以点击历史工单查看能得到相关的借鉴。研判完后可以选择下拉框对舆情事件进行分级，然后点击选择人员按钮以便送到办公室主任那进行审批，点击提交则送审到下一个流程。

4.1.2.3.2.4、界面设计

    4.1.2.3.3、办公室主任审批

4.1.2.3.3.1、业务目标

   舆情分级后送审到办公室主任处进行审批，办公室主任根据舆情事件的真实情况以及历史舆情事件的对比分析，对办公室的舆情事件分级进行审核。

4.1.2.3.3.2、业务用例

暂无

4.1.2.3.3.3、功能分析

审核舆情工单的页面显示舆情事件发生的事发单位、工单编号、拟办部门、抄送部门、舆情事件的基本情况、分析、处理意见等信息，页面上可以通过查看流程图的按钮进行流程查看。办公室主任根据舆情事件的真实情况对舆情分级进行审核，如果审核不通过，则点击拒绝按钮系统自动把舆情分级的工单退回到办公室相关负责人。如果审核通过并填写完办公室主任的意见，点击选择人员按钮对局领导进行选择后，则点击通过按钮。系统会根据选择的局领导人员自动提醒局领导进行审核。

4.1.2.3.3.4、界面设计

    4.1.2.3.4、局领导审批

4.1.2.3.4.1、业务目标

根据舆情事件处理流程的“舆情由下往上报，由上往下发，步步需审核” 的原则，对舆情分级后送审到办公室主任处进行审批，再由办公室主任处送审到局领导处进行审批，局领导根据舆情事件的真实情况以及办公室主任的处理意见，对舆情事件分级进行审核,批示。

4.1.2.3.4.2、业务用例

暂无

4.1.2.3.4.3、功能分析

局领导审批页面显示舆情事件发生的事发单位、工单编号、拟办部门、抄送部门、舆情事件的基本情况、分析、处理意见、办公室主任的审核处理意见等信息，页面上可以通过查看流程图的按钮进行流程查看。局领导根据舆情事件的真实情况对舆情分级以及办公室主任的处理审核意见进行审核，如果审核不通过，则点击拒绝按钮系统自动把舆情分级的工单退回到办公室主任。如果审核通过并填写完局领导的审批意见，则点击通过按钮。系统会进入到舆情处理阶段。

4.1.2.3.4.4、界面设计

    4.1.2.3.5、有关部门协助、督办（专业领域）

4.1.2.3.5.1、业务目标

   当舆情事件分级并经过层层审批后，办公室根据舆情事件的真实情况是否涉及有关部门，是否需要有关部门（事发单位或专业单位）进行督办，协助处理。

4.1.2.3.5.2、业务用例

暂无

4.1.2.3.5.3、功能分析

舆情工单督办协助页面显示舆情事件发生的事发单位、工单编号、拟办部门、抄送部门、舆情事件的基本情况、分析、处理意见、局领导的审核处理意见等信息，页面上可以通过查看流程图的按钮进行流程查看。办公室根据需要通过下拉框的选择督办部门，然后点击通过按钮后，系统会自动提醒督办，协助单位进行对舆情事件的具体处理。

4.1.2.3.5.4、界面设计

    4.1.2.3.6、舆情处置报告单

4.1.2.3.6.1、业务目标

办公室根据督办协助单位或事发单位或专业部门对舆情事件的处理措施和结果的汇报进行处置报告单的回填。

4.1.2.3.6.2、业务用例

暂无

4.1.2.3.6.3、功能分析

  舆情处置报告单的页面显示了填报单位、填报时间、填报人、联系电话、舆情事件发生时间、舆情信息通知编号、抄送部门、舆情信息内容、舆情处理措施和结果以及后续的措施的填写。办公室人员点击选择部门按钮后再点击上报按钮提交到上级进行审核。

4.1.2.3.6.4、界面设计

4.1.2.3.7、舆情工单完结

   4.1.2.3.7.1、业务目标

  当舆情工单经过相关部门的处理后提交舆情处置报告单到上级审批，上级根据舆情事件的真实情况以及处理的措施和结果，后续的影响等对舆情事件的处置是否合格，如果审核通过，进行对外发布且事件平息，则可以完结舆情工单。

4.1.2.3.7.2、业务用例

暂无

4.1.2.3.7.3、功能分析

舆情工单的完结页面显示了填报单位、填报时间、填报人、联系电话、舆情事件发生时间、舆情信息通知编号、抄送部门、舆情信息内容、舆情处理措施和结果以及后续的措施，舆情工单信息。在舆情信息中可以点击查看操作对舆情的详细信息进行查看。办公室相关负责人根据上级对舆情处置报告的审核状态对舆情工单进行完结。如果舆情处置报告未通过审核，则点击退回按钮系统会把舆情工单的再次处理信息退回到相关处理部门（事发单位或专业部门），如果舆情处置报告审核通过了，则点击完结按钮对舆情工单进行完结。

4.1.2.3.7.4、界面设计

4.1.2.4、界面设计

4.1.3突发新闻信息管理

4.1.3.1、编辑快速新闻报告单

       4.1.3.1.1、业务目标

当突发事件发生后，事发单位或者专业部门第一时间以电话的形式通知办公室，直到生成快速新闻报告单，在突发事件发生的30分钟内，需要事发单位或者是专业部门根据事件的真实变化情况对快速新闻报告单的信息进行修改。快速新闻报告单是可能产生舆情事件信息变化的一种体现。

4.1.3.1.2、业务用例

 暂无

       4.1.3.1.3、功能分析

快速新闻报告单页面显示了新闻工单编号，应急工单编号、填报单位、部门负责人、填报人、事发单位、直接上级、事件简题、事发时间以及事件的影响情况，事件的处理措施与进度，事件产生原因、预计处理完成的时间的信息，新闻通稿，温馨提示模板。页面正下方显示应急工单信息。可以点击查看流程图按钮对突发应急新闻报送的流程进行查看，当填写完这些相关的必填（带红色*）信息后点击保存按钮对信息进行保存，然后在点击上报按钮把突发应急事件的变化情况反馈给办公室。

       4.1.3.1.4、界面设计

4.1.3.2、审核快速新闻报告单

4.1.3.2.1、业务目标

办公室收到事发单位或专业部门上报的快速新闻报告单后进行汇总，然后送到上级进行审核处理。

4.1.3.2.2、业务用例

暂无

       4.1.3.2.3、功能分析

       快速新闻报告单审核页面显示了新闻工单编号、填报单位、部门负责人、填报人、事发单位、直接上级、事件简题、事发时间以及事件的影响情况，事件的处理措施与进度，事件产生原因、预计处理完成的时间的信息，新闻通稿，温馨提示模板。页面正下方显示工单信息。可以点击查看流程图按钮对突发新闻报送的流程进行查看。上级根据办公室对事件的报道并结合事件的真实情况对快速新闻报告单中的信息的虚实进行审核，如果报道属实，则通过下拉框下拉选择发布人员（以便提醒下一步骤中相关人员的处理）并点击通过按钮进行完成审核。如果报道与事件的真实情况有出入，则点击拒绝按钮把快速新闻报告单退回到办公室负责人。

       4.1.3.2.4、界面设计

4.1.3.3、突发新闻后续跟踪

4.1.3.3.1、业务目标

突发事件发生后，事发单位新闻人员同时了解动态，并按需填写舆情处置报告单。在应急新闻信息发布后，应当根据新闻发布内容，重点跟踪了解事件发展方向和后续新闻媒体报道并根据事件发展，事发单位新闻工作人员应动态提供舆论关注信息，提出针对性的处置建议。

4.1.3.3.2、业务用例

暂无

       4.1.3.3.3、功能分析

突发新闻信息的后续跟踪，是对存在有可能产生舆情的一个要素，是按需、按实际情况而定，启动舆情处置报告单，并上报至上级至省公司。

舆情处置报告单的页面显示了填报单位、填报时间、填报人、联系电话、舆情事件发生时间、舆情信息通知编号、抄送部门、舆情信息内容、舆情处理措施和结果以及后续的措施的填写。办公室人员点击选择部门按钮后再点击上报按钮提交到上级进行审核

       4.1.3.3.4、界面设计

4.1.3.5、突发新闻信息显示

4.1.3.5.1、业务目标

        显示最近发生的一系列的突发应急事件新闻信息。

4.1.3.5.2、业务用例

暂无

       4.1.3.5.3、功能分析

       突发新闻显示页面可以根据工单编号，新闻快速单的状态进行查询。也可以对单条新闻信息进行编辑。

       4.1.3.5.4、界面设计

4.1.4应对策略管理

4.1.4.1、业务目标

主要是针对企业的危机事件进行管理。通过它来提高企业的危机意识，即时的发现潜在的和已发生的危机事件；可以根据事件的危机等级，启动不同的危机公关处理方案。从而快速的控制事件的发展方向。最后对已发生的危机事件进行归档，为以后的危机事件的处理提供可靠的数据依据和处理经验。

4.1.4.2、业务用例

  暂无

4.1.4.3、功能分析

舆情应对策略页面可以根据舆情事件类型、舆情事件等级对舆情事件进行点击查询按钮查询。也可以进行删除操作（删除时勾选到对应的舆情事件，点击删除按钮操作即可）、新增操作时点击新增按钮直接进入舆情应对策略新增页面，对舆情标题、危机等级、舆情类型、舆情等级、对应处理经验的填写后点击保存按钮对应对策略进行保存。

在新增舆情工单页面，可以对舆情工单与应对策略进行关联，点击添加对应策略，系统会弹出一个历史或已保存的应对策略的信息列表，点击添加后舆情工单页面后自动补充应对策略部分，作为舆情工单处置的一个参考模板和案例。

4.1.4.4、界面设计

4.1.5模板管理

4.1.5.1、业务目标

根据舆情事件的情况阐述制定的模板，为突发事件新闻信息报道提供新闻通稿模板以及对突发事件新闻情况的温馨提示信息制定模板以供发布使用。

4.1.5.2、业务用例

暂无

4.1.5.3、功能分析

模板编辑页面可以根据对模板简称、模板类型、模板内容进行填写，然后点击保存按钮。

4.1.5.4、界面设计

4.1.6通用功能

4.1.6.1功能分析

主要包括：

首页：地图、柱状图展示舆情、突发应急事件；

事项管理：根据系统业务流程节点，对角色待办事项和经办事项的罗列；

统计分析：根据事件类别形成统计分析页面；

系统管理：用户基本信息管理、系统权限管理、系统角色管理、流程管理、菜单管理、参数管理、业务规则管理等。

4.2对性能的规定

4.2.1精度

系统设计保证在数据的处理和传输过程中不出现数据的失真和数据精度的变化导致数据丢失和不一致的情况。

数据查询时保证查全率，所有满足查询条件的记录都能被查询出来。

4.2.2时间特性要求

项目	性能要求	备注
启动功能响应时间	2s～5s
数据保存响应时间	1s～5s
任务提交响应时间	1s～5s
记录查询响应时间	1s～5s

4.2.3灵活性

4.2.3.1应用灵活性

系统对功能的菜单，权限的管理，部门人员的管理等可由管理员自行配置等。

4.2.3.2扩展灵活性

系统框架应采用流行的技术框架，要有明确的分层管理，便于应用的扩展和维护。

4.2.1精度

说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。

4.2.2时间特性要求

说明对于该软件的时间特性要求，如对：

1. 响应时间；
2. 更新处理时间；
3. 数据的转换和传送时间；
4. 解题时间；等的要求。

4.2.3灵活性

说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：

1. 操作方式上的变化；
2. 运行环境的变化；
3. 同其他软件的接口的变化；
4. 精度和有效时限的变化；
5. 计划的变化或改进。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

4.3 友好提示要求

鉴于在操作过程中，会有很多要求及时处理的舆情流程，系统会适当得增加一些声音，弹出框提示，一些比较紧急重要的信息会同时通过发短信进行通知。

同时减少不必要的提醒，避免影响用户操作。

4.3 操作规范要求

在操作中，减少有歧义的按钮，避免对用户产生影响。

风格和按钮都应统一放置，可以加快对系统的认知和联想。

可以默认的尽量不要选，可以选的尽量不要写。

4.4其他专门要求

4.4.1系统安全需求

系统安全性主要包括数据库安全性、信息安全性和系统平台的安全性等方面。数据库安全性可以先通过视图机制，不同用户只能访问系统授权的视图，这样可提供系统数据一定程度上的安全性，再通过分配权限、设置权限级别来区别对待不同操作者对数据库的操作来提供数据库的安全性；信息安全性通过对中要数据先加密再解密的方式传输，保证数据在输入、传输和接收过程中不被外界复制。系统平台的安全性体现在操作系统的安全性、计算机系统的安全性和网络体系的安全性等方面，通过选择安全性较高的机器和操作系统，尽量避免此类安全问题。

4.4.2可维护性需求

维护就是在系统交互使用后可以继续修改，但是修改之前需要理解待修改的对象，修改后应该对其进行必要的测试，以保证修改的是正确的。如果是改正性维护，还必须预先进行调试以确定错误的具体位置。因此，决定系统可维护性的因素主要有以下5个：

可理解性：系统的可理解性表现为用户对系统的结构、功能、接口和内部处理过程的难易程度。模块化（模块结构良好，高内聚，松耦合）、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言等等，都对提高系统的可理解性有重要贡献。

可测试性：诊断和测试的容易程度取决于系统容易理解的程度。良好的文档对诊断和测试是至关重要的，此外，软件结构、可用的测试工具和调试工具，以及以前设计的测试过程也都是非常重要的。维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试。在设计阶段应该尽力把系统设计成容易测试和容易诊断的。

可修改性：系统容易修改的程度与设计原理和启发规则直接有关。耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等等，都影响系统的可修改性。

可移植性：系统可移植性指的是，把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。把与硬件、操作系统以及其他外部设备有关的程序代码集中放到特定的程序模块中，可以把因环境变化而必须修改的程序局限在少数程序模块中，从而降低修改的难度。

可重用性：所谓重用是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。大量使用可重用的构件来开发系统，可以从下述两个方面提高系统的可维护性：

（1）通常可重用的构件在开发时经过很严格的测试，可靠性比较高，且在每次重用过程中都会发现并清除一些错误，随着时间推移，这样的构件将变成实质上无错误的。因此，系统中使用的可重用构件越多，系统的可靠性越高，改正性维护需求越少。

（2） 很容易修改可重用的构件使之再次应用在新环境中，因此，系统中使用的可重用构件越多，适应性和完善性维护也就越容易。

5运行环境规定

5.1设备

本系统部署运行需要以下软硬件产品：

1. 应用服务器 1台
2. 数据库服务器1台

5.1.1应用服务器环境

应用服务器-硬件配置
IP地址
硬件类型	IBM System x3690 M3以上
内存	PC2-5300 DDR2 ECC　32G
CPU	Xeon EM64T Dual core 4 3.2GHz 或者Intel Xeon X56506 6核2.6G (或更高)
硬盘	250G
操作系统	MS Windows Sever 2003 32Bit
备注	舆情管理系统应用服务器
机器存放位置

5.1.2数据库应用服务器

数据库服务器-硬件配置
IP地址
硬件类型	IBM System x3690 M3以上
内存	PC2-5300 DDR2 ECC　24G
CPU	Xeon EM64T Dual core 4 3.2GHz 或者Intel Xeon X5650 6核2.6G (或更高)
硬盘	500G
操作系统	MS Windows Sever 2003 64Bit
备注	数据库服务器
机器存放位置