散装汽油购销实名登记管理信息系统项目-技术方案

散装汽油购销实名登记管理信息系统项目

技术方案

1背景

近年来，国内相继发生公交车、医院等公众场所纵火案。该类案

件中，散装汽油成为犯罪分子实施暴力攻击和个人暴力犯罪的重要工

具。因此,加油站点散装汽油的销售平安管理工作刻不待时。

2014年3月公安部下发《关于快速实行超常措施建立完善严控

严查散装购、销汽油制度的通知，强调:对可以散装购买汽油的,加油

站和加油员要监督加油全过程，留意发觉、刚好报告可疑状况,并照实

登记散装购买汽油人员的姓名、身份证件号码和购买数量、用途等。

散装汽油体系包括单位、个人生产、生活须要。但近年来，利用

汽油实施暴恐攻击犯罪的威逼进一步凸显，但随意销售、对购买人信

息驾驭不全及汽油流向不明等问题却成为制约散装汽油销售管控工

作有效开展的瓶颈,为此，依据公安部的工作要求，为了实行了散装

汽油销售实名购买、实情登记、实时传输的“三实”举措，支配研发

“散装汽油销售治安信息管理系统”，构建“购买登记、信息采集、

传输比对、落地查人”的管控工作模式,实现对散装汽油购买人及流

向的实时、有效管理。

实名登记制度规定,对确因生产、科研、生活等须要购买散装汽

油的,一律实行实名登记制度。不能供应有效身份证件的,加油站一律

拒绝销售并说明说明；对其中的可疑人员，马上向辖区派出所报告，

由派出所进一步核查。

随着科技发展，越来越多的重要信息数据资源须要进行集中收集,

对于重要数据资源用于公安机关进行资源的综合开发利用，充分发挥

数据资源的效用。通过对可疑数据资源的挖掘及研判分析，提高公安

机关侦查破案的效率，更好地服务经济社会发展，所以开发和应用一

套治安管理信息系统平台势在必行。

2建设任务

建立散装汽油销售数据采集管理支撑系统：实现社会散装汽油销

售信息进行采集；建立对可疑人员的信息碰撞机制，扩大社会信息比

对范围。且实现实时监督管理，监控散装汽油销售公司进出货物，确

保全省治安良好和企业财产的平安保障。

建立散装汽油销售企业平安监测：实现对散装汽油销售企业的平

安监测。

建立散装汽油销售从一业人员的信息筛查，实现对散装汽油销售企

业从业人员的平安监测。

建立一键报警体系，实现重点单位平安体系的完善和补充。

建立内网数据应用支撑系统:实现对所归集散装汽油销售信息的

比对、预警、以及研判分析，并通过部门间共享平台供应应公安各业

务系统进行资源信息的综合查询。

系统硬件环境的搭建:依据本次系统运行环境设计，对项目整体

运行环境所需服务器、存储等硬件设备进行集成。

3建设技术要求

系统应采纳三层体系架构体系。采纳成熟的技术及产品实现数

据的采集、归集及比对分析。

主要业务办理界面不能下载非平安的控件，控件及数据库无干脆

交互操作。

必需保证系统具有开放的体系及接口，客户端支持跨平台运行,

支持Linux、Unix、Window等主流的操作系统及Android等

主流移动终端操作系统。

采纳牢靠的平安技术，平安保密体系必需达到国标、部标标准。

必需充分考虑目前我单位现有的软、硬件资源的可利用性，如:

充分利用现有服务器硬件、操作系统、数据库进行方案部署，实现及

现有的各治安信息管理系统共享用户审核、权限安排、日志记录及分

析等，保证数据的互联互通，高效利用和发挥现有资源的优势。

系统必需具备好用性、牢靠性、高扩展性、先进性、平安性、可

维护性和操作友好性。

4总体架构

故装油信息

公安端管理子系

统

加油站

内网数据库

加油点

警综平台/

大情报/

公安信息资源

共享服务平台/

其他

5项目建设内容

5.1互联网应用平台

5.L1互联网数据库建设

外网数据库是外网资源数据采集汇总的第一站，为了今后的各类

数据采集汇总，外网数据库建立需遵循以下标准：

（1）统一的数据标准

外网数据库建设需符合国际、国内、行业和公安部相关标准，包

括数据采集项、数据字典、数据接口规范等等。建立完成统一的信息

接入标准，为今后各类信息接入供应统一标准。

（2）关系型数据库

采纳现主流数据库系统如0racle、Sq1ServeMySql>

Sybase^DB2>DM>Kingbase、MaxDB、InfoMix^PostgreS

q1等。

供应及我单位原有信息的数据对接,避开重复建设、重复投入。

5.L2散装汽油销售信息采集

5.1.2.1门户管理

/兼容PC端、手机端、平板端操作。

/支持牢靠的认证管理登录。

/支持前台用户修改认证密码。

/供应用户登录日志展示及分析。

/供应用户登录日志全周期检索。

/支持相关信息发布管理

/供应统一身份认证管理平台，能将互联网应用各平台进行无缝单

点身份认证处理。

5.1.2.2通知通告管理

1）兼容PC端、手机端、平板端操作。

2）供应通知通告、协查通报等信息的发布、删除和修改。

3）供应企业和从业人员、警员对通知通告的阅读记录。

4）通知通告管理须支持可视化富文本编辑,能够便利的在线编辑通

知通告的样式、内容。

5）供应及我单位现有信息系统的接口，实现及现有信息系统的通知

通告的数据集成、共享、转发。

5.1.2.3从业企业信息管理

1）兼容PC端、手机端、平板端操作。

2）供应企业信息的增加、删除、修改查询功能。

3）支持平台管理员对从业企业信息管理和维护。

4）供应从业企业的活跃度监测，避开销售企业不按规定登记散装汽

油销售。

5.1.2.4从业人员管理

1）兼容PC端、手机端、平板端操作。

2）供应企业从业人员管理功能，支持从业员人信息增、删、改等操作。

3）支持数字采集设备的数据采集，例如二代身份证读取器,手机/平

板电脑便利快速录入人员基本信息。

4）能对人员在企业的入、离职等其他信息进行维护。

5.1.2.5一键报警

1）兼容PC端、手机端、平板端操作。

2）供应报警人信息管理，包括报警人姓名、联系方式、报警内容。

3）及报警信息进行处理，任何报警信息都必需有对应的处理信息，供

应报警信息管理功能

5.1.2.6散装汽油销售管理

1）兼容PC端、手机端、平板端操作。

2）供应购买人信息管理，包括购买人姓名、身份证号码、联系方式、

购买时间购买油量、购买用途等信息的维护；

3）及购买信息进行对应关系处理，任何购买信息都必需对应有购买

信息。供应购买历史管理功能。

4）各客户须支持智能读卡设备对二代身份证的读取功能,避开信息

录入的荣誉困难。

5.1.2.7散装汽油销售信息分析

针对散装汽油销售信息采集的采集数据，供应配套的统计分析管

理功能，以满足散装汽油销售处理日常的管理须要,提升企来对系统

的运用爱好。该子系统另外要包含公安内网应用平台的企业管理和平

台管理功能。

1）企业信息多维度分析。

2）企业从业人员多维度分析。

3）企业车辆多维度统计管理。

4）购买信息多维度管理等统计分析功能。

5.1.2.8警情通知管理

1）兼容PC端、手机端、平板端操作。

2）支持警情的阅读操作。

3）支持警情的转发操作。

4）支持警情的批示操作。

5.1.2.9处警管理

1）兼容PC端、手机端、平板端操作。

2）供应处警功能，包括处警警员姓名、联系方式、出警时间、处理

结果等信息的维护。

3）及报警信息进行核对，任何出警记录都必需有相对应的信息记录

4）供应出警信息管理功能。

5.1.2.10油区重点部位巡查

1）兼容PC端、手机端、平板端操作。

2）支持重点单位、部位的巡查功能，要求支持巡查地理信息、巡查结

果、巡查照片上传及其地理信息的标注。

3）支持重点单位、部位的自动巡查考核，对不合格的巡查记录自动

标注。

4）2.4.1.4.7油区重点部位地理信息采集子系统

5）兼容手机端、平板端操作。

6）支持对全省油IX重点部位的地理信息采集,要求采集的地理信息

精度误差不超过10米。

7）支持及重点部位巡查结果的数据比对，自动筛选出不合格的巡查

记录。

5.1.2.11分局信息管理

1）兼容PC端、手机端、平板端操作。

2）支持分局单位信息的增加、修改、删除、查询功能。

3）供应单位管理员对本单位信息的维护及维护记录。

4）供应单位的授权管理。

5）支持对现有信息平台的引用，尽可能的避开重复建设。

5.1.2.12警员管理

1）兼容PC端、手机端、平板端操作。

2）支持警员信息的增加、修改、删除、查询功能。

3）支持单位管理员对警员信息的维护功能。

4）供应警员对自身信息的维护管理功能。

5）供应单位管理员对单位警员的密码重置功能。

6）供应警员对自己密码的修改等功能。

7）供应统一身份认证管理平台，能将互联网应用各平台进行无缝单

点身份认证处理。

8）支持对现有信息平台的警员信息的引用，利用现有警员账号进行

登录。

5.1.2.13授权管理

1）兼容PC端、手机端、平板端操作。

2）支持牢靠的授权管理子系统。

3）支持精细的授权管理功能，下钻到每个用户在每个模块的每个功

能上的权限限制管理。

4）支持分时授权管理功能,针对特定的单位、用户进行分时授权管理。

5）支持授权例外管理功能，支持特定组、角色、单位的特定授权下

的多样化例外授权。例外授权可精细限制到角色、用户粒度。

6）支持现有平台的授权体系集成,结合我单位现有用户管理的授权

体系对本系统进行授权管理

5.2内网应用平台

散装汽油销售管理系统公安网部分主要功能体现在对互联网用

户采集过来的数据统计、分析、研判并结合公安内网的相关数据进行

二次研判、比对、分析等等功能。为充分利用散装汽油销售业信息对

公安的实战工作供应有效的支持。该平台的企业管理子系统和平台管

理子系统功能在互联网应用平台上部署可应用。

5.2.1公安网数据资源库

数据资源库是一个信息、数据收集、整合、分类、标引组织，完

成由数据上升为情报信息的过程，通过汇合整合公安内外部情报信息

资源，以结构化或非结构化数据形式建成情报信息综合数据库,为建

设情报综合平台和开展各种情报信息应用供应数据基础。综合数据库

主要体现为在现有的数据信息的基础上进行扩展，一方面保证一期的

建设成果，另一方面通过扩展,可以为后续的更多应用的开展供应更

好的数据支持。并且可对公安外网采集到的数据进行清洗、转换，

并依据规定的数据标准和格式进入内网进行重组和分类存储•。同时要

求在公安内网建立信息比对资源库，对所归集的资源信息及布控人员

进行比对，形成相应人员、物品比对库（比如在逃人员库、违法犯罪

嫌疑人员库、布控信息库）。

5.2.2智能分析

为提高数据质量、数据利用率以及最大限度的发挥已有数据的作

用，系统须要对平台内的全部资源进行多角度、多维度的综合智能分

析。让不同的用户从不同的角度全面了解现有散装散装汽油销售业采

集信息的状况，以及采集的数据所发挥的作用。通过不同的数据建模

发觉不同的治安内问题,例如当前最突出的二手脏物交易、两抢一盗

案件高发地区。作案高危嫌疑人等。

1）企业信息分析

供应企业维度分析，按地域、按管辖单位、按法人、按企业名称

等进行检索及统计。并支持下钻到明细。

2）购买信息分析

供应购买人姓名、身份证、散装汽油销售企业名称、身份证等相

关信息查询及统计,并支持下钻到明细功能。

3）布控信息分析

供应按布控申请人、申请机构、布控状态、布控目标信息、布控结果

等信息的查询统计功能，并支持下钻到明细。

4）布控预警信息分析

供应按预警对像、如身份证,手机串等,预警反馈状态，预警地域、

预警对像的多维度分析统计功能，并支持下钻到明细数据。

5.2.3布控管理

民警用户可通过布控管理子系统发起在线申请、审批、发布等在

线操作流程，同时支持多级审批，系统能支持审批条件预设置，在用

户申请初期即完成部分审批预处理,提高后期审批通过率。

1）支持人员、销售油量布控,人员布控时需及公安部恳求服务完成人

口信息核实，并提示申请人异样信息

2）支持布控范围的设定，在设定范围要进行布控管理。

3）布控申请支持预警模式设置。

4）支持布控审批时的批量审批。

5）支持布控到期自动撤控，布控到期前可进行人工撤控、续控等。

5.2.4预警管理

基于散装汽油销售业信息采集子系统供应应公安内网的数据资源

库,结合公安部供应的在逃人员库、全国违法法犯罪人员库以及布控

管理子系统供应的相关信息,进进行预警处理”

1）建立布控人员库，包括布控管理系统供应的人员信息，公安部相关

布控人员信息，各专业警种布控人员信息。

2）建立预警比对模型,给合布控人员库、右控物品库的相关信息以及

依据布控子系统的布控需求，产生不同的预警信息。

3）依据不同的设定模式对预警信息进行自动分发处理

4）并且对不同的预警接收人供应不同的预警签收反馈功能。

5）预警信息的产生以及预警信息的反馈均须要满足公安部的相关要

求。能及公安部情报平台进行数据交换处理。

6）基于预警发布、反馈以及相关处理的流程之上，供应预警对像的相

关信息展示,如活动轨迹。散装汽油销售轨迹等。并供应预警信息

的多维度分析，给公安部门的防、管、控、打行动供应决策支持。

7）基于全国七类重点人员的预警，供应及公安部重点人员档案系统

的对接。

5.2.5企业管理

该子系统主要是针对企业单位信息、企业从业人员信息、企业数

据采集状况进行相关管理及分析。

1）结合互联网上的散装汽油销售信息采集子系统供应的数据,完成

对散装汽油销售业的物品分析管理。

2）同时对散装汽油销售企业上传的数据进行多维度分析，产生对散

装汽油销售企业的自动巡检提示，支持对散装汽油销售企业的惩

罚工作。

3）供应企业单位信息的维护；以及管理用户授权等;供应企业维度分

析,按地域、按管辖单位、按法人、按企业名称等进行检索及统计。

并支持下钻。

5.2.6平台管理

通过完整、严密的用户角色体系设计，实现功能模块的权限限制。

通过按岗位设计用户实现严格的数据访问范围限制。该模块可以

1）统一身份证证

供应统一身份认证平台，对其他子系统供应完整的单点认证接口,

实现统一身份认证功能。

2）分级授权

供应分级授权管理、支持权限分级管理，多级授权。为削减最高级

管理员授权工作。

3）日志管理

供应系统操作日志管理等功能。

4）用户管理

对访问系统的用户帐号进行管理，供应帐号的添加、删除、修改、

查询功能,为帐号批量导入供应模板。

5）角色管理

供应立体多维角色权限管理,可以对功能权限、数据权限进行立体

的管理，对组织、用户、角色、功能等各类资源进行统一、分级管理,

统一管理可将各类资源进行集中式管理,分级管理可将权限下放到部

门、子部门一级的管理员。授权方式及传统的对用户、对角色授权不

同，是真正基于策略的敏捷的授权方式,可对任何资源进行授权,授权

时，可对主动资源（授权资源）及被动资源（被授权资源）进行级联和

过滤。同时支持将角色进行列表的导出。

6）权限管理

供应对用户进行角色授权以及功能的添加、删除、修改、查询。

实现4级权限管理。

7）基础信息管理。

供应企业单位佶息、法人信息及设置等基础信息的添加、删除、

修改、查询。

8）用户登录模块

供应用户登录、密码修改、注销、USB加密狗注册等功能。

53系统平安保障

5.3・1平安保障目标

通过整体平安体系规划,综合运用各种平安技术和手段。要求达到

的平安目标为：

静态平安目标：包括整个系统的物理环境、系统软硬件结构和可用的

信息资源，保证系统实体平台平安。

动态平安目标：提升系统的平安软环境，包括平安管理、平安服务、

平安意识和人员的平安专业素养。

5.3.2平安体系设计

依据系统平安保障的目标，投标人应从平安管理、应用系统平安

设计(包括权限认证、用户认证、日志审计等多个方面)、数据平安及

备份、网络平安、平台平安等多个方面来考虑，并进行相应的描述。

要求对于不同的数据，采纳不同的加密政策。对于敏感数据，为防

止数据库管理员查看数据和其他的意外状况发生，全部保存到数据库

的关键数据经过128位的RSA算法或者其他高级加密算法进行加密，

保证数据在保存点的平安性。要求投标人对数据加密进行具体设计。

内外网的数据交换平安,要求投标人结合现有平安边界平台，以及

部门间信息共享平台的架构对此次散装汽油销售信息的归集及交换

进行具体设计。

5.3.3数据库平安

5.3.3.1系统平安性策略

(1)管理数据库用户

数据库用户是访问数据库信息的途径，囚此，应当很好地维护管理

数据库用户的平安性。依据数据库系统的大小和管理数据库用户所需

的工作量,数据库平安性管理者可能只是拥有create,alter,或

drop数据库用户的一个特别用户，或者是拥有这些权限的一组用户,

应留意的是，只有那些值得信任的个人才应当有管理数据库用户的权

限。

（2）操作系统平安性

A）数据库管理员必需有create和delete文件的操作系统权限；

B）一般数据库用户不应当有create或delete及数据库相关文件

的操作系统权限；

C）假如操作系统能为数据库用户安排角色，那么平安性管理者必需有

修改操作系统帐户平安性区域的操作系统权限。

5.33.2用户的平安性策略

（1）一般用户的平安性

对于那些用户很多，应用程序和数据对象很丰富的数据库，应充

分利用“角色”这个机制所带的便利性对权限进行有效管理。对于困

难的系统环境，“角色”能大大地简化权限的管理。

（2）终端用户的平安性

须针对终端用户制定平安性策略。例如，对于一个有很多用户的

大规模数据库，平安性管理者可以确定用户组分类，为这些用户组创

建用户角色，把所需的权限和应用程序角色授予每一个用户角色，以

及为用户安排相应的用户角色。当处理特别的应用要求时，平安性管

理者也必需明确地把一些特定的权限要求爱予给用户。可以运用“角

色”对终端用户进行权限管理。

5.3.4应用平安

5.3.4.1应用审计

应用系统日志审计功能参照公安部相关的应用系统审计标准，达

到相关标准规范要求。

53.4.2权限管理

通过完整、严密的用户角色体系设计，实现功能模块的权限限制。

通过按岗位设计用户实现严格的数据访问范围限制。

应用功能的权限。系统的应用功能的权限设定包括建立完整的业

务功能描述体系，把信息系统应完成的功能进行明确的描述；建立应

用功能权限描述体系，描述用户及具体业务功能的关系。

业务数据的权限。及业务功能权限相像，系统应包括：完备的业

务数据描述体系,描述系统的须要权限限定的数据。建立业务数据权

限描述体系，描述用户及具体业务数据的权限关系。

53.4.3日志监控

1）系统日志

生成系统口志包括以下几方面内容:

2）创建、删除用户

为了防止通过临时创建的用户做违规操作，在操作日志中记录用

户创建和删除的具体信息。

3）操作日志

记录每个用户的操作信息，供事后核查审计。

4）登录退出

为了事后追查平安问题的缘由，登录退出在日志中保存了具体的

信息。

5）授权变更

为了避开违规权限操作，授权变更在日志中保存了具体的信息。

6）查询分析

为了避开相关交易信息和个人隐私数据的外泄，对查询的数据进

行日志记录,可以反跟踪相关数据查询记录内外网各功能模块可依据

实际需求状况,调整内外网部署设计。

6项目实施

6.1项目团队组织

6.L1团队组织架构图

一个工程项目能够顺当地实施，胜利地完成，依靠我方及用户很

好的沟通和亲密的合作。为保证本项目的顺当进行，实现优质高效的

目标，在项目启动阶段将联合成立项目领导小组，全面负责系统建设

中的各项任务。

项目领导小组下设项目经理及由项目经理领导的软件开发组、质

量管理组、测试组、应用实施组、商务及培训组、维护服务组，其组

织结构如下图所示。

6.1.2岗位职责说明

(1)、项目领导小组

项目领导小组是项目整个生命周期的最高领导者:由双方项目主

管领导组成，以定期例会的形式工作。

项目领导小组的主要任务是：

规划、组织、指挥整个项目的实施，协调各方的工作以及人员调

配，协调和解决双方合作中出现的问题，限制整个工程进度，保证项

目保质保量完成。

贯彻上级主管部门对工程建设的指导看法，确定系统实施中重要

业务规范和技术标准，组织评审系统总体设计方案，协调及工程实施

有关的各方之间关系，对工程实施过程中出现的重大问题做出决策,

对工程各阶段的工作做出评估，组织工程的考核、鉴定、验收等工作。

(2)、项目经理

采纳项目经理负责制，由公司在公司项目经理队伍中指定一名具

备应用系统开发阅历、熟识业务、具有项目经理资质的人担当此工程

的项目经理。主要原责是：

制定项目开发、应用实施、维护服务等各阶段具体工作支配，负

责资源调配，按支配执行项目；

驾驭、限制项目的每个实施过程，组织系统分析、系统设计、具

体设计、系统测试、应用实施等各阶段的支配和方案的评审；

负责用户现场的协调，具体解决项目实施中出现的各种状况和问

题;

负责项目的变更管理和风险管理，定期向项目领导小组汇报项目

进展状况；

项目交接管理等。

(3)、软件开发组

软件开发组成员以公司技术人员组成。主要职责是：

依据甲方的实际需求进行需求分析，设计开发方案及编写开发文

档，完成软件开发，满足甲方的实际需求。

负责编写对用户的系统管理人员、操作人员进行相关的技术培训I、

应用系统操作培训的培训资料。

(4)、质量管理组

质量管理组成员由厂家1人和甲方人员组成。主要职责是：

侦责制定项目的质量监控管理规范及实旃细则，负责项目的配置

管理，负责项目文档的管理工作，对项目实施进行全程监控，刚好向

项目领导小组、项目经理提交质量监控报告。

(5)、测试组

测试组成员由厂家2人和甲方人员组成。主要职责是：

负责项目集成测试、系统测试、初步验收测试的测试方案、测试

支配的制定、实施和测试分析报告的编制，刚好向项目领导小组、项

目经理提交测试分析报告报告。

(6)、应用实施组

应用实施组成员由厂家2人和甲方人员组成。主要职责是：

负责应用系统的安装、调试；

利用应用服务工具，通过配置、部署等方式，完成数据库的建立，

制定及实施数据维护(ETL)方案；

利用应用服务工具,通过配置、部署等方式,实现应用功能。

负责系统管理和监控方案的制定及实施，负责应用系统的试运行、

现场信息收集及反馈等工作。

现场安装、调试过程中，须要用户协作工作。

(7)、商务及培训组

由厂家商务人员、技术人员和甲方相关人员组成。其职责如下：

完成项目组确定的各项商务活动，保证工程所需各项产品的按时

到货、验收，协调双方关系，为系统顺当实施做好协作工作；

组织对用户的系统管理人员、操作人员进行相关的技术培训、应

用系统操作培训等。

(8)、维护服务组

由厂家技术人员和甲方相关人员组成。维护服务组的人员来自项

目实施过程中的软件开发人员和应用实施人员o

6.2进度支配

项目从起先到安装部署上线并通过初验为90个日历日，其后进

入试运行期。

预期工作成

任务名称起止时间工作人员

果

一、整体规划以及需求调研

项目现场调研及项目支配

T+5（T代表合同签订日

项目总体实施设需求分析员需求分析报

期）

计告

二、软件任务分解

系统的概要设计(T+5)+10设计工程师概要设计

系统功能模

系统的开发(T+5+10)+50实施工程师

块

系统安装部署调

试

数据采集、综合库

(T+5+10+50)+20测试工程师提交系统

建设

三、系统测试、试运行、培训以及初验和终验

项目测试报

项目初验测试(T+5+10+50+20)+5测试工程师

告

田古史帝沃疔甘日雨曰怒钾

测试、调整、修改、项目培训记

试运行以及应用录

软件培训）

项目终验合

项目验收项目初验后+试运行期项目经理格证书及相

关验收文档

6.3开发测试管理

6.3.1开发管理

Java是一种优秀的面对对象开发语言，所以本系统的开发采纳

面对对象的开发方法。

面对对象技术是软件技术的一次革命,在软件开发史上具有里程

碑的意义。

随着00P（面对对象编程）向OOD（面对对象设计）和00A（面

对对象分析）的发展，最终形成面对对象的软件开发方法OMT（Obj

ectModellingTechnique）o这是一种自底向上和自顶向下相结

合的方法，而且它以对象建模为基础，从而不仅考虑了输入、输出数

据结构，事实上也包含了全部对象的数据结构。所以0MT彻底实现了

PAM没有完全实现的目标。不仅如此，00技术在需求分析、可维护性

和牢靠性这三个软件开发的关键环节和质量指标上有了实质性的突

破，彻底地解决了在这些方面存在的严峻问题，从而宣告了软件危机

末日的来临。

1、自底向上的归纳

OMT的第一步是从问题的陈述入手,构造系统模型。从真实系统

导出类的体系，即对象模型包括类的属性，及子类、父类的继承关系，

以及类之间的关联°类是具有相像属性和行为的一组具体实例(客观

对象)的抽象,父类是若干子类的归纳。因此这是一种自底向上的归纳

过程。在自底向上的归纳过程中，为使子类能更合理地继承父类的属

性和行为，可能须要自顶向下的修改，从而使整个类体系更加合理。

由于这种类体系的构造是从具体到抽象，再从抽象到具体，符合人类

的思维规律，因此能更快、更便利地完成任务。这及自顶向下的You

rdon方法构成显明的比照。在Yourdor.方法中构造系统模型是最

困难的一步，因为自顶向下的“顶”是一个空中楼阁，缺乏坚实的基

础，而且功能分解芍相当大的随意性，因比须要开发人员有丰富的软

件开发阅历。而在0TM中这一工作可由一般开发人员较快地完成。

在对象模型建立后，很简单在这一基础上再导出动态模型和功能模型。

这三个模型一起构成要求解的系统模型。

2、自顶向下的分解

系统模型建立后的工作就是分解。及Yourdon方法按功能分解

不同，在0MT中通常按服务(Service)来分解。服务是具有共同

目标的相关功能的集合，如I/O处理、图形处理等。这一步的分解通

常很明确，而这些子系统的进一步分解因有较具体的系统模型为依据,

也相对简单。所以0MT也具有自顶向下方法的优点，即能有效地限制

模块的困难性，同时避开了Yourdon方法中功能分解的困难和不确

定性。

3、0MT的基础是对象模型

每个对象类由数据结构（属性）和操作（行为）组成，有关的全部

数据结构（包括输入、输出数据结构）都成了软件开发的依据。因此

Jackson方法和PAM中输入、输出数据结构及整个系统之间的鸿沟

在0MT中不再存在。0MT不仅具有Jackson方法和PAM的优点，而

且可以应用于大型系统。更重要的是，在Jackson方法和PAM方法中，

当它们的动身点一输入、输出数据结构（即系统的边界）发生变更时,

整个软件必需推倒重来。但在0MT中系统边界的变更只是增加或削

减一些对象而已整个系统改动微小。

4、需求分析彻底

需求分析不彻底是软件失败的主要缘由之一。即使在目前,这一

危急依旧存在。传统的软件开发方法不允许在开发过程中用户的需求

发生变更，从而导致种种问题。正是由于这一缘由，人们提出了原型

化方法，推出探究原型、试验原型和进化原型，主动激励用户改进需

求。在每次改进需求后又形成新的进化原型供用户试用，直到用户基

木满足，大大提高了软件的胜利率但是它要求软件开发人员能快速

生成这些原型,这就要求有自动生成代码的工具的支持。

0MT彻底解决了这一问题。因为需求分析过程已及系统模型的形

成过程一样,开发人员及用户的探讨是从用户熟识的具体实例（实体）

起先的。开发人员必需搞清现实系统才能导出系统模型，这就运用户

及开发人员之间有了共同的语言，避开了传统需求分析中可能产生的

种种问题。

5、可维护性大大改善

在OMT之前的软件开发方法都是基于功能分解的。尽管软件工程

学在可维护方面作出了极大的努力，使软件的可维护性有较大的改进。

但从本质上讲,基于功能分解的软件是不易维护的。因为功能一旦有

变更都会使开发的软件系统产生较大的变更,甚至推倒重来。更严峻

的是，在这种软件系统中，修改是困难的。由于种种缘由，即使是微小

的修改也可能引入新的错误。所以传统开发方法很可能会引起软件成

本增长失控、软件质量得不到保证等一系列严峻问题。正是OMT才使

软件的可维护性有了质的改善。

OMT的基础是目标系统的对象模型，而不是功能的分解。功能

是对象的运用，它依靠于应用的细微环节，并在开发过程中不断变更。

由于对象是客观存在的，因此当需求变更时对象的性质要比对象的运

用更为稳定,从而使建立在对象结构上的软件系统也更为稳定。

更重要的是OMT彻底解决了软件的可维护性。在00语言中，子

类不仅可以继承父类的属性和行为，而且也可以重载父类的某个行为

（虚函数）。利用这一特点，我们可以便利地进行功能修改：引入某类

的一个子类，对要修改的一些行为（即虚函数或虚方法）进行重载，

也就是对它们重新定义。由于不再在原来的程序模块中引入修改，所

以彻底解决了软件的可修改性，从而也彻底解决了软件的可维护性。

00技术还提高了软件的牢靠性和健壮性。

1.1.1.1开发环境

在项目实施过程中，项目开发环境建叹：

个人开发电脑

开发人员在各自的电脑上进行程序开发。

开发服务器

开发人员在开发服务器上进行单元测试，系统分析师在上面对

代码进行走查。

建构管理服务器

该服务器用来管理当前版本及版本发行。

测试服务器A该服务器用来进行系统的集成测试和交付测试。

1.1.1.2主要开发工具

运用Eclipse作为主要开发工具。

Ec1ipse是闻名的跨平台的自由集成开发环境（IDE）。最初

主要用来Java语言开发，但是目前亦有人通过插件使其作为其他计

算机语言比如C++和Pvthon的开发工具。Ec1ipse的本身只是一

个框架平台，但是众多插件的支持使得Eclipse拥有其他功能相对

固定的IDE软件很难具有的敏捷性。很多软件开发商以Eelips

e为框架开发自己的IDE。

EcIipse最初由0TI和IBM两家公司的IDE产品开发组创

建,起始于1999年4月。IBM供应了最初的Eclipse代码基础，包

括P1atform.JDT和PDEO目前由IBM牵头，围围着Eelips

e项目已经发展成为了一个浩大的Eclipse联盟,有150多家软件

公司参及到Eclipse项目中，其中包括Borland>Rationa1Sof

tware>RedHat及Sybase等。Eclipse是一个开发源码项目，

它其实是VisualAgeforJava的替代品，其界面跟从前的Vi

sualAgeforJava差不多，但由于其开放源码，任何人都可以

免费得到，并可以在此基础上开发各自的插件，因此越来越受人们关

注。近期还有包括Orac1e在内的很多大公司也纷纷加入了该项目，

并宣称Ec1ipse将来能成为可进行任何语言开发的IDE集大成

者,运用者只需下载各种语言的插件即可。

Eclipse是一个开放源代码的软件开发项目，专注于为高度集

成的工具开发供应一个全功能的、具有商业品质的工业平台。它主要

由Eclipse项目、Ec1ipse工具项目和Ec1ipse技术项目三

个项目组成，具体包括四个部分组成EclipseP1atform、J

DT、CDT和PDE。JDT支持Java开发、CDT支持C开发、PDE用

来支持插件开发,EclipseP1atform则是一个开放的可扩展ID

E,供应了一个通用的开发平台。它供应建立块和构造并运行集成软

件开发工具的基础。Ec1ipseP1atform允许工具建立者独立开

发及他人工具无缝集成的工具从而无须辨别一个工具功能在哪里结

束，而另一个工具功能在哪里起先。

Eelipse的插件机制是轻型软件组件化架构。在客户机平台上,

Ec1ipse运用插件来供应全部的附加功能，例如支持Java以外的

其他语言。己有的分别的插件己经能够支持C/C++(CDT)、Pe

rl、Ruby,Python、te1net和数据库开发。插件架构能够支

持将随意的扩展加入到现有环境中，例如配置管理，而决不仅仅限于

支持各种编程语言。

Ec1ipse的设计思想是:一切皆插件。Ec1ipse核心很小,其

它全部功能都以插件的形式附加于Eclipse核心之上。Eclipse基

本内核包括：图形API(SWT/Jface),Java开发环境插件(JD

T),插件开发环境(PDE)等。

6.3.2验证测试管理

6.3.2.1验证及确认流程

验证的目的，是确保工作产品符合其指定的需求。

确认的目的，是展示置于预期环境中的产品或产品组件，可满足

其预期的运用需求。

验证和确认流程如下：

63.2.2系统测试方案

因应本系统质量及平安性要求，当系统开发完成之后须要从功能

整合、系统效能、系统接口、数据转换、平安等方面进行测试。系统

测试方案规划如下：

具体测试的执行方式如下表所述:

测试标的测试者测试环

测试类别说明

境

PG开发完成的程序开开发环功能验收后方可

组件、功能或发者境进行功能整合测

UT（单元测

程序（包括数（PG）试

试）

据转换及系统

接口模块）

测试标的测试者测试环

测试类别说明

境

已验收的功能测试团功能整功能整合测试由

整合成模块队合测试测试团队制订测

功能整合测（包括数据转环境试支配来执行,建

试换及系统接口议可以采纳持续

模块）；模块整集成的方式执行

合成子系统

经过功能整合测试团模拟生效能测试建议干

效能压力测的模块或子系队产环境脆在为生产而打

试统算的软硬件环境

下执行

经过功能整合测试团交付测数据转换和系统

交付测试的模块或子系队试环境接口测试需及交

统付测试相结合，即

经过功能整合测试团交付测待测系统的数据

数据转换测

的模块或子系队试环境来源是通过数据

试

统转换及系统接口

经过功能整合测试团交付测而来，并且能及外

系统接口测

的模块或子系队试环境部系统正常介接

试

统

测试标的测试者测试环

测试类别说明

境

系统软硬件环客户I模拟生选择某批交付的

11A测试境及应用的搭T人员产环境产品进行HA测试

配

用户系统整通过交付测试客户I用户SIT分批交付的验收

合测试的分批交付产T人员环境动作

(SIT)品(LotX)

用户系统验通过用户SIT客户用用户UA

收测试(u的分批交付产户代表T环境

AT)品(LotX)

用户完整系针对于已通过客户用用户UA最终系统的验收

统验收测试分批验收的完户代表T环境

(UAT)整产品

63.2.3验证及确认标准

F面是软件设计开发过程中分析、评审的重要量化指标:

度量单平均值

活动产品

位密度缺陷率合格率

RDReviewReq.Do

Req.Doc.由DFPV供应

c.

ADRevADD

Page—2.00—

iewoc.

HDRevie

HDDoc.Page—2.00—

w

DDRevie

DDDoc.UC—7.00—

w

UTCODEKLOC758.00一

WTVaKLOC—5.00—

ITVbKLOC354.50—

RTVcKLOC61.500.45

镐百*R日

pn美士在哈

An加珈福■件

IID树里沿井

nn目状会在

iiT/rnnr

WT/Va用岸主杏3后木，口

TT/Vk敕训;才r痂木rkn

PTNc办AH神1*3丽木

nr田柘H

kTnr上行在前

6.4实施管理

项目开发实施支配为了确保项目目标达成和项目顺当实施，项目

规划和项目的监控是至关重要的环节，因而我公司在项目管理过程中,

对项目实施进行如下维度的规划:

项目基准支配:依据项目管理的九大构面对项目进行整体规划，

其内容包括项目目标及范围定义、项目成本和预算、项目整体时程规

划和里程碑支配、项目质量支配、项目组织和沟通支配、项目资源规

划、项目环境及建构管理支配、外包及选购支配、项目风险支配，

项目基准支配被视为项目组对公司和客户的承诺，并且作为项目执行

绩效的比较基准。

阶段具体支配:依据基准支配的整体支配，项目不同阶段均会制

订具体的时程支配,通过WBS分解并落实到具体活动(Activity),

作为每个阶段及每个团队工作执行的指导，并作为进度检查的重要依

据。

个人工作支配:依据具体支配支配的工作事项，会作为个人的工

作包安排给具体的执行人，由执行人对工作进行细化，个人工作支配

实质为个人对项目组的承诺。

依据以上支配的内容，项目实施过程中，会有不同频度和范围的

检讨：

每日个人对工作包执行状态进行回报。

每周进行小组或项目组织的进度审查，并且对于进度偏差及项目

执行过程中所遇到的问题进行探讨和解决。

每月项目审查会议，由项目组及项目相关干系人(如：公司管理

者、客户)依据项目基准支配进行检查，对项目执行过程中的重大问

题进行探讨和解决。

里程碑审查会议，针对于项目重大里程碑设定评审会议，确定项

目Go/NoG。的判定。

6.5沟通管理

有效沟通是确保项目胜利的重要保障，在项目管理过程中通过项

目会议和检查以及问题沟通处理机制来保持沟通的通畅。

651项目检讨

我公司每周五供应项目周报，报告一周来的工作进展状况。

每周一实行一次项目会议，对上一周的工作进行探讨和总结，双

方的项目经理均需出席。会议主要内容如下：

检查项目执行状况

跟踪风险

调整支配

跟踪行动

跟踪异样状况

通告项目进展状况

6.5.2问题处理

项目实施过程中会遇到不同类别的问题，我们一般将问题分为以

下四类：

项目问题(PPR,ProjectProblemReport),指项目管理范筹

中，影响项目进度、交付、质量、成本、沟通、人员管理和合约等方

面的问题。项目问题在每周周会进行检讨，并且对于须要协调解决的

问题须要由我公司和客户项目经理一同组织特地的会议协调相关的

项目干系人(Stakeho1der)参与会议迸行探讨并解决问题。

变更恳求(CRR,ChangeRequestReport),指及项目范围及

软件产品需求基准(Base1ine)相比较而产生的变更，有新需求(Ne

wRequirement)>需求变更(ChangedRequirement)

或需求取消(Cance1edRequirement),从而影响到项目的进度、

质量要求、交付的时间或开发的成本等。项目的变更恳求，既可以由

客户干脆提出，也可以由我公司项目组识别出来后通知客户，由客户

认定后再提出变更恳求。并且当双方对于变更恳求的处理方案、人力

及成本预估存在争议，无法由双方项目组达成共识时，建议由CCB

(ChangeContro1Board)来协调探讨，并对争议做最终裁

决。其中CCB的构成由双方高层管理者、双方项目经理以及相应的

领域专家构成。

软件问题(SPR,SoftwareProblemReport),指软件产品测试

或验证过程中所发觉的问题(Issue)。软件问题(SPR)的处理可以

采纳测试管理的工具来进行管理，但双方肯定均能访问，并可以更新

相应的状态和说明字段。软件问题(SPR)的处理结果及进度，可以

列入到每周例会的检讨内容。

Q&A(QuestionAndAnswer)，项目实施过程中须要进行澄清

的疑问。项目实施过程中针对于不同方面的Q&A双方应指定对应的

窗口，如技术问题、不同领域的需求功能问题等都有各自对应的窗口，

这样会让问题有统一的管理并提高解答的成效。对于问题的提出，先

由我公司内部进行探讨及解答，只有内部无法解答的问题才会提交客

户回复。

6.6风险管理

项目风险是项目管理过程中潜在的问题。项目风险可能引起项目

不能按时交付，或达不到预期的质量,或须要增加项目成本。

风险管理是一种对项目风险进行识别、分析、应对的系统过程。

它包括激励对项目目标有正面影响的风险发生并加强其影响、减小对

项目目标有负面影响的风险发生并减弱其影响。

风险管理策略如下图：

风险管理规划

确定如何进行及规划项目的风险管理活动。

风险识别A推断哪些风险会影响项目，并做正式记录。

风险分析

风险定性分析：对风险及其条件进行定性分析,并依其对项目目标影

响进行排序。

风险定量分析：量度风险的概率及后果，估计其对项R目标造成的影

响。

风险应对规划A制订为项目目标增加机会、减轻威逼的程序及技

术。

风险监测及追踪

在项目整个生命期间监测残余风险、识别新风险，执行减轻风险支配,

并对这些支配的有效性进行评估。

6.6.1风险识别及分析

风险是由项目团队成员（客户方或农商行）进行识别和分析

的。风险必需上升到项目级对待。依据危急程度，风险可分为不同等

级，对于风险等级为6到9的紧急风险必需制定具体的解决支配。以

下各表分别是风险严峻性、风险可能性、风险等级的分类说明。

风险可能性

可能性描述

1-We此类事务发生几率很小。

ak

2-此类风险发生和不发生的可能性均等。

Avera

ge

3-此类事务很有可能发生。

Strong

风险严峻性

严峻性描述

1-We此类风险不影响项目预期目标，如成本、进度、质

ak量、技术内容。

2-此类风险影响项目部分功能但不阻碍最终执行。

Average

3-S此类风险影响方案的执行。可能最终因起财务损

trong失，甚至影响项目。

风险等级

Probability

6.6.2风险处理流程

6.7质量管理

质量管理,是指质量管理员（QA）通过对项目过程中的产品或服务

进行有效的稽核，以确保项目的品质不出现问题。

项目启动阶段，品质保证员将依据项目的基线支配和具体开发支

配制订品质稽核支配，列出稽核点和稽核忖问。

项目实施过程中，品质保证员将依据支配进行品质稽核工作，对

发觉的问题产生不合格报告，并对不合格报告进行追踪，以监督项目

组对不合格问题进行改进。

每周品质保证员将提交品质稽核周报，在项目周会上进行检讨。

项目结案阶段,品质保证员将对整个项目实施过程中的品质状况

进行分析和总结,提交项目品质分析报告。

品质保证流程图：

6.8建构管理

建构管理流程领域运用建构识别、建构限制、建构状态纪录，以

及建构稽核，来建立及维护工作产品的完整性。并经由建立及维护工

作产品的完整性，来支持全部的流程领域。

6.8.1开发环境

在项目实施过程中，项目开发环境建议：

个人开发电脑a开发人员在各自的电脑上进行程序开发。

开发服务器

开发人员在开发服务器上进行单元测试,系统分析师在上面对代码进

行走查。

建构管理服务器

该服务器用来管理当前版本及版本发行。

测试服务器

该服务器用来进行系统的集成测试和交付测试。

6.8.2建构管理对象

纳入建构管理的工作产品包括:交付客户的产品、指定的内部工

作产品、选购的产品、工具，以及用来产生及说明这些工作产品的

其它项目。

6.8.3建构管理工作内容

建构管理工作内容包括：识别建构项、规划基线、创建建构馆、

变更管理、冻结版本、发行版本、例行工作管理。

6.8.4建构管理工具

运用CSV/SVN作为系统开发和维护的版本限制工具。

6.8.5建构管理流程

结合项目开发环境和建构管理的工作内容,在项目实施过程中的

建构管理流程如下：

6.9验收管理

系统测试内容包括:功能测试、性能测试、集成测试、压力测试、

配置测试、平安性测试等。本系统验收前，由甲乙双方共同组织，聘

请具有专业资质的权威检测机构进行系统测试。

6.10系统验收

验收是通过科学的方法对系统建设进行全面的检查和总结，是系

统开发建设中有组织的主动性行为，它是对系统建设高度负责的体现,

可以验证系统建设质量是否达到设计的要求，是系统建设胜利的重要

保证。

验收的依据是系统建设任务书、签订的合同、技术协议以及建设

过程中经双方同意增加的约定文件（如补充协议）等。

验收分为阶段性验收和系统终验。阶段性验收贯穿于系统实施的

过程中，阶段性验收内容主要包括对系统软件、应用软件及相关的配

套设施进行验收，由于以上各验收内容在实际建设中是分步进行的，

既有独立性，又是系统建设的有机组成部分，因此，应当分项对这些内

容进行分阶段验收。在每个实施阶段完成后都要对本阶段的工作进行

阶段性验收，我公司将为每个阶段性的工作供应阶段性工作总结报告

和相关的技术文档。

6.10.1范围及权责

以下表格是甲方和建设厂家双方在项目执行的不同阶段当中的

权责分工说明：

（◎表示负责方，△表示帮助方）

阶段工作内容甲方厂家

客户需求◎

软件实现

需求分析△◎

系统架构设计◎

数据库设计◎

UI设计△◎

系统功能设计◎

系统接口设计△©

编码及单元测试◎

系统接口实现◎

程序走查◎

整合测试◎

交付测试◎

提交产品及文件◎