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

散装汽油购销实名登记管理信息系统工程技术方案背景近年来，国内相继发生公交车、医院等公众场所纵火案。该类案件中，散装汽油成为犯罪分子实施暴力袭击和个人暴力犯罪的重要工具。因此，加油站点散装汽油的销售平安管理工作刻不容缓。2014年3月公安部下发《关于迅速采取超常措施建立完善严控严查散装购、销汽油制度的通知，强调：对可以散装购置汽油的，加油站和加油员要监督加油全过程，注意发现、及时报告可疑情况，并如实登记散装购置汽油人员的姓名、身份证件号码和购置数量、用途等。散装汽油体系包括单位、个人生产、生活需要。但近年来，利用汽油实施暴恐袭击犯罪的威胁进一步凸显，但随意销售、对购置人信息掌握不全及汽油流向不明等问题却成为制约散装汽油销售管控工作有效开展的瓶颈。为此，按照公安部的工作要求，为了实行了散装汽油销售实名购置、实情登记、实时传输的“三实”举措，方案研发“散装汽油销售治安信息管理系统”，构建“购置登记、信息采集、传输比对、落地查人”的管控工作模式，实现对散装汽油购置人及流向的实时、有效管理。

实名登记制度规定，对确因生产、科研、生活等需要购置散装汽油的，一律实行实名登记制度。不能提供有效身份证件的，加油站一律拒绝销售并解释说明；对其中的可疑人员，立即向辖区派出所报告，由派出所进一步核查。随着科技开展，越来越多的重要信息数据资源需要进行集中收集，对于重要数据资源用于公安机关进行资源的综合开发利用，充分发挥数据资源的效用。通过对可疑数据资源的挖掘与研判分析，提高公安机关侦查破案的效率，更好地效劳经济社会开展，所以开发和应用一套治安管理信息系统平台势在必行。建设任务建立散装汽油销售数据采集管理支撑系统：实现社会散装汽油销售信息进行采集；建立对可疑人员的信息碰撞机制，扩大社会信息比对范围。且实现实时监督管理，监控散装汽油销售公司进出货物，确保全省治安良好和企业财产的平安保障。建立散装汽油销售企业平安监测：实现对散装汽油销售企业的平安监测。建立散装汽油销售从业人员的信息筛查，实现对散装汽油销售企业从业人员的平安监测。建立一键报警体系，实现重点单位平安体系的完善和补充。建立内网数据应用支撑系统：实现对所归集散装汽油销售信息的比对、预警、以及研判分析，并通过部门间共享平台提供应公安各业务系统进行资源信息的综合查询。系统硬件环境的搭建：根据本次系统运行环境设计，对工程整体运行环境所需效劳器、存储等硬件设备进行集成。建设技术要求系统应采用三层体系架构体系。采用成熟的技术及产品实现数据的采集、归集及比对分析。主要业务办理界面不能下载非平安的控件，控件与数据库无直接交互操作。必须保证系统具有开放的体系与接口，客户端支持跨平台运行，支持Linux、Unix、Window等主流的操作系统及Android等主流移动终端操作系统。采用可靠的平安技术，平安保密体系必须到达国标、部标标准。必须充分考虑目前我单位现有的软、硬件资源的可利用性，如：充分利用现有效劳器硬件、操作系统、数据库进行方案部署，实现与现有的各治安信息管理系统共享用户审核、权限分配、日志记录与分析等，保证数据的互联互通，高效利用和发挥现有资源的优势。系统必须具备实用性、可靠性、高扩展性、先进性、平安性、可维护性和操作友好性。总体架构工程建设内容互联网应用平台互联网数据库建设外网数据库是外网资源数据采集汇总的第一站，为了今后的各类数据采集汇总，外网数据库建立需遵循以下标准：统一的数据标准外网数据库建设需符合国际、国内、行业和公安部相关标准，包括数据采集项、数据字典、数据接口标准等等。建立完成统一的信息接入标准，为今后各类信息接入提供统一标准。关系型数据库采用现主流数据库系统如Oracle、SqlServer、MySql、Sybase、DB2、DM、Kingbase、MaxDB、InfoMix、PostgreSql等。提供与我单位原有信息的数据对接，防止重复建设、重复投入。散装汽油销售信息采集门户管理兼容PC端、端、平板端操作。支持可靠的认证管理登录。支持前台用户修改认证密码。提供用户登录日志展示与分析。提供用户登录日志全周期检索。支持相关信息发布管理提供统一身份认证管理平台，能将互联网应用各平台进行无缝单点身份认证处理。通知通告管理兼容PC端、端、平板端操作。提供通知通告、协查通报等信息的发布、删除和修改。提供企业和从业人员、警员对通知通告的阅读记录。通知通告管理须支持可视化富文本编辑，能够方便的在线编辑通知通告的样式、内容。提供与我单位现有信息系统的接口，实现与现有信息系统的通知通告的数据集成、共享、转发。从业企业信息管理兼容PC端、端、平板端操作。提供企业信息的增加、删除、修改查询功能。支持平台管理员对从业企业信息管理和维护。提供从业企业的活泼度监测，防止销售企业不按规定登记散装汽油销售。从业人员管理兼容PC端、端、平板端操作。提供企业从业人员管理功能，支持从业员人信息增、删、改等操作。支持数字采集设备的数据采集，例如二代身份证读取器，/平板电脑方便快速录入人员根本信息。能对人员在企业的入、离职等其他信息进行维护。一键报警兼容PC端、端、平板端操作。提供报警人信息管理，包括报警人姓名、联系方式、报警内容。与报警信息进行处理，任何报警信息都必须有对应的处理信息，提供报警信息管理功能散装汽油销售管理兼容PC端、端、平板端操作。提供购置人信息管理，包括购置人姓名、身份证号码、联系方式、购置时间购置油量、购置用途等信息的维护；与购置信息进行对应关系处理，任何购置信息都必须对应有购置信息。提供购置历史管理功能。各客户须支持智能读卡设备对二代身份证的读取功能，防止信息录入的荣誉复杂。散装汽油销售信息分析针对散装汽油销售信息采集的采集数据,提供配套的统计分析管理功能，以满足散装汽油销售处理日常的管理需要，提升企来对系统的使用兴趣。该子系统另外要包含公安内网应用平台的企业管理和平台管理功能。企业信息多维度分析。企业从业人员多维度分析。企业车辆多维度统计管理。购置信息多维度管理等统计分析功能。警情通知管理兼容PC端、端、平板端操作。支持警情的阅读操作。支持警情的转发操作。支持警情的批示操作。处警管理兼容PC端、端、平板端操作。提供处警功能，包括处警警员姓名、联系方式、出警时间、处理结果等信息的维护。与报警信息进行核对，任何出警记录都必须有相对应的信息记录提供出警信息管理功能。

油区重点部位巡查兼容PC端、端、平板端操作。支持重点单位、部位的巡查功能，要求支持巡查地理信息、巡查结果、巡查照片上传及其地理信息的标注。支持重点单位、部位的自动巡查考核，对不合格的巡查记录自动标注。2.4.1.4.7油区重点部位地理信息采集子系统兼容端、平板端操作。支持对全省油区重点部位的地理信息采集，要求采集的地理信息精度误差不超过10米。支持与重点部位巡查结果的数据比对，自动筛选出不合格的巡查记录。分局信息管理兼容PC端、端、平板端操作。支持分局单位信息的增加、修改、删除、查询功能。提供单位管理员对本单位信息的维护及维护记录。提供单位的授权管理。支持对现有信息平台的引用，尽可能的防止重复建设。警员管理兼容PC端、端、平板端操作。支持警员信息的增加、修改、删除、查询功能。支持单位管理员对警员信息的维护功能。提供警员对自身信息的维护管理功能。提供单位管理员对单位警员的密码重置功能。提供警员对自己密码的修改等功能。提供统一身份认证管理平台，能将互联网应用各平台进行无缝单点身份认证处理。支持对现有信息平台的警员信息的引用，利用现有警员账号进行登录。授权管理兼容PC端、端、平板端操作。支持可靠的授权管理子系统。支持精细的授权管理功能，下钻到每个用户在每个模块的每个功能上的权限控制管理。支持分时授权管理功能，针对特定的单位、用户进行分时授权管理。支持授权例外管理功能，支持特定组、角色、单位的特定授权下的多样化例外授权。例外授权可精细控制到角色、用户粒度。支持现有平台的授权体系集成，结合我单位现有用户管理的授权体系对本系统进行授权管理。内网应用平台散装汽油销售管理系统公安网局部主要功能表达在对互联网用户采集过来的数据统计、分析、研判并结合公安内网的相关数据进行二次研判、比对、分析等等功能。为充分利用散装汽油销售业信息对公安的实战工作提供有效的支持。该平台的企业管理子系统和平台管理子系统功能在互联网应用平台上部署可应用。公安网数据资源库数据资源库是一个信息、数据收集、整合、分类、标引组织，完成由数据上升为情报信息的过程，通过聚集整合公安内外部情报信息资源，以结构化或非结构化数据形式建成情报信息综合数据库，为建设情报综合平台和开展各种情报信息应用提供数据根底。综合数据库主要表达为在现有的数据信息的根底上进行扩展，一方面保证一期的建设成果，另一方面通过扩展，可以为后续的更多应用的开展提供更好的数据支持。并且可对公安外网采集到的数据进行清洗、转换，并按照规定的数据标准和格式进入内网进行重组和分类存储。同时要求在公安内网建立信息比对资源库，对所归集的资源信息与布控人员进行比对，形成相应人员、物品比对库〔比方在逃人员库、违法犯罪嫌疑人员库、布控信息库〕。智能分析为提高数据质量、数据利用率以及最大限度的发挥已有数据的作用，系统需要对平台内的全部资源进行多角度、多维度的综合智能分析。让不同的用户从不同的角度全面了解现有散装散装汽油销售业采集信息的情况，以及采集的数据所发挥的作用。通过不同的数据建模发现不同的治安内问题，例如当前最突出的二手脏物交易、两抢一盗案件高发地区。作案高危嫌疑人等。企业信息分析提供企业维度分析，按地域、按管辖单位、按法人、按企业名称等进行检索与统计。并支持下钻到明细。购置信息分析提供购置人姓名、身份证、散装汽油销售企业名称、身份证等相关信息查询与统计，并支持下钻到明细功能。布控信息分析提供按布控申请人、申请机构、布控状态、布控目标信息、布控结果等信息的查询统计功能，并支持下钻到明细。布控预警信息分析提供按预警对像、如身份证，串等，预警反应状态，预警地域、预警对像的多维度分析统计功能，并支持下钻到明细数据。布控管理民警用户可通过布控管理子系统发起在线申请、审批、发布等在线操作流程，同时支持多级审批，系统能支持审批条件预设置，在用户申请初期即完成局部审批预处理，提高后期审批通过率。支持人员、销售油量布控，人员布控时需与公安部请求效劳完成人口信息核实，并提醒申请人异常信息支持布控范围的设定，在设定范围要进行布控管理。布控申请支持预警模式设置。支持布控审批时的批量审批。支持布控到期自动撤控，布控到期前可进行人工撤控、续控等。预警管理基于散装汽油销售业信息采集子系统提供应公安内网的数据资源库，结合公安部提供的在逃人员库、全国违法法犯罪人员库以及布控管理子系统提供的相关信息，进进行预警处理，建立布控人员库，包括布控管理系统提供的人员信息，公安部相关布控人员信息，各专业警种布控人员信息。建立预警比对模型，给合布控人员库、布控物品库的相关信息以及根据布控子系统的布控需求，产生不同的预警信息。根据不同的设定模式对预警信息进行自动分发处理并且对不同的预警接收人提供不同的预警签收反应功能。预警信息的产生以及预警信息的反应均需要满足公安部的相关要求。能与公安部情报平台进行数据交换处理。基于预警发布、反应以及相关处理的流程之上，提供预警对像的相关信息展示，如活动轨迹。散装汽油销售轨迹等。并提供预警信息的多维度分析，给公安部门的防、管、控、打行动提供决策支持。基于全国七类重点人员的预警，提供与公安部重点人员档案系统的对接。企业管理该子系统主要是针对企业单位信息、企业从业人员信息、企业数据采集情况进行相关管理与分析。结合互联网上的散装汽油销售信息采集子系统提供的数据，完成对散装汽油销售业的物品分析管理。同时对散装汽油销售企业上传的数据进行多维度分析，产生对散装汽油销售企业的自动巡检提示，支持对散装汽油销售企业的处分工作。提供企业单位信息的维护；以及管理用户授权等；提供企业维度分析，按地域、按管辖单位、按法人、按企业名称等进行检索与统计。并支持下钻。平台管理通过完整、严密的用户角色体系设计，实现功能模块的权限控制。通过按岗位设计用户实现严格的数据访问范围控制。该模块可以统一身份证证提供统一身份认证平台，对其他子系统提供完整的单点认证接口，实现统一身份认证功能。分级授权提供分级授权管理、支持权限分级管理，多级授权。为减少最高级管理员授权工作。日志管理提供系统操作日志管理等功能。用户管理对访问系统的用户帐号进行管理，提供帐号的添加、删除、修改、查询功能，为帐号批量导入提供模板。角色管理提供立体多维角色权限管理，可以对功能权限、数据权限进行立体的管理，对组织、用户、角色、功能等各类资源进行统一、分级管理，统一管理可将各类资源进行集中式管理，分级管理可将权限下放到部门、子部门一级的管理员。授权方式与传统的对用户、对角色授权不同，是真正基于策略的灵活的授权方式，可对任何资源进行授权，授权时，可对主动资源〔授权资源〕与被动资源〔被授权资源〕进行级联和过滤。同时支持将角色进行列表的导出。权限管理提供对用户进行角色授权以及功能的添加、删除、修改、查询。实现4级权限管理。根底信息管理。提供企业单位信息、法人信息与设置等根底信息的添加、删除、修改、查询。用户登录模块提供用户登录、密码修改、注销、USB加密狗注册等功能。系统平安保障平安保障目标通过整体平安体系规划，综合运用各种平安技术和手段。要求到达的平安目标为：静态平安目标：包括整个系统的物理环境、系统软硬件结构和可用的信息资源，保证系统实体平台平安。动态平安目标：提升系统的平安软环境，包括平安管理、平安效劳、平安意识和人员的平安专业素质。平安体系设计根据系统平安保障的目标，投标人应从平安管理、应用系统平安设计〔包括权限认证、用户认证、日志审计等多个方面〕、数据平安与备份、网络平安、平台平安等多个方面来考虑，并进行相应的描述。要求对于不同的数据，采用不同的加密政策。对于敏感数据，为防止数据库管理员查看数据和其他的意外情况发生，所有保存到数据库的关键数据经过128位的RSA算法或者其他高级加密算法进行加密，保证数据在保存点的平安性。要求投标人对数据加密进行详细设计。内外网的数据交换平安，要求投标人结合现有平安边界平台，以及部门间信息共享平台的架构对此次散装汽油销售信息的归集与交换进行详细设计。数据库平安系统平安性策略(1)管理数据库用户数据库用户是访问数据库信息的途径，因此，应该很好地维护管理数据库用户的平安性。按照数据库系统的大小和管理数据库用户所需的工作量，数据库平安性管理者可能只是拥有create，alter，或drop数据库用户的一个特殊用户，或者是拥有这些权限的一组用户，应注意的是，只有那些值得信任的个人才应该有管理数据库用户的权限。(2)操作系统平安性A〕数据库管理员必须有create和delete文件的操作系统权限；B〕一般数据库用户不应该有create或delete与数据库相关文件的操作系统权限；C〕如果操作系统能为数据库用户分配角色，那么平安性管理者必须有修改操作系统帐户平安性区域的操作系统权限。用户的平安性策略(1)一般用户的平安性对于那些用户很多，应用程序和数据对象很丰富的数据库，应充分利用“角色”这个机制所带的方便性对权限进行有效管理。对于复杂的系统环境，“角色”能大大地简化权限的管理。(2)终端用户的平安性须针对终端用户制定平安性策略。例如，对于一个有很多用户的大规模数据库，平安性管理者可以决定用户组分类，为这些用户组创立用户角色，把所需的权限和应用程序角色授予每一个用户角色，以及为用户分配相应的用户角色。当处理特殊的应用要求时，平安性管理者也必须明确地把一些特定的权限要求授予给用户。可以使用“角色”对终端用户进行权限管理。应用平安应用审计应用系统日志审计功能参照公安部相关的应用系统审计标准，到达相关标准标准要求。权限管理通过完整、严密的用户角色体系设计，实现功能模块的权限控制。通过按岗位设计用户实现严格的数据访问范围控制。应用功能的权限。系统的应用功能的权限设定包括建立完整的业务功能描述体系，把信息系统应完成的功能进行明确的描述；建立应用功能权限描述体系，描述用户与具体业务功能的关系。业务数据的权限。与业务功能权限相似，系统应包括：完备的业务数据描述体系，描述系统的需要权限限定的数据。建立业务数据权限描述体系，描述用户与具体业务数据的权限关系。日志监控系统日志生成系统日志包括以下几方面内容：创立、删除用户为了防止通过临时创立的用户做违规操作，在操作日志中记录用户创立和删除的详细信息。操作日志记录每个用户的操作信息，供事后核查审计。登录退出为了事后追查平安问题的原因，登录退出在日志中保存了详细的信息。授权变更为了防止违规权限操作，授权变更在日志中保存了详细的信息。查询分析为了防止相关交易信息和个人隐私数据的外泄，对查询的数据进行日志记录，可以反跟踪相关数据查询记录内外网各功能模块可根据实际需求情况，调整内外网部署设计。工程实施工程团队组织团队组织架构图一个工程工程能够顺利地实施，成功地完成，依赖我方与用户很好的沟通和密切的合作。为保证本工程的顺利进行，实现优质高效的目标，在工程启动阶段将联合成立工程领导小组，全面负责系统建设中的各项任务。工程领导小组下设工程经理及由工程经理领导的软件开发组、质量管理组、测试组、应用实施组、商务及培训组、维护效劳组，其组织结构如下列图所示。岗位职责说明工程领导小组工程领导小组是工程整个生命周期的最高领导者，由双方工程主管领导组成，以定期例会的形式工作。工程领导小组的主要任务是：规划、组织、指挥整个工程的实施，协调各方的工作以及人员调配，协调和解决双方合作中出现的问题，控制整个工程进度，保证工程保质保量完成。贯彻上级主管部门对工程建设的指导意见，确定系统实施中重要业务标准和技术标准，组织评审系统总体设计方案，协调与工程实施有关的各方之间关系，对工程实施过程中出现的重大问题做出决策，对工程各阶段的工作做出评估，组织工程的考核、鉴定、验收等工作。工程经理采用工程经理负责制，由公司在公司工程经理队伍中指定一名具备应用系统开发经验、熟悉业务、具有工程经理资质的人担任此工程的工程经理。主要职责是：制定工程开发、应用实施、维护效劳等各阶段详细工作方案，负责资源调配，按方案执行工程；掌握、控制工程的每个实施过程，组织系统分析、系统设计、详细设计、系统测试、应用实施等各阶段的方案和方案的评审；负责用户现场的协调，具体解决工程实施中出现的各种情况和问题；负责工程的变化管理和风险管理，定期向工程领导小组汇报工程进展情况；工程交接管理等。软件开发组软件开发组成员以公司技术人员组成。主要职责是：根据甲方的实际需求进行需求分析，设计开发方案及编写开发文档，完成软件开发，满足甲方的实际需求。负责编写对用户的系统管理人员、操作人员进行相关的技术培训、应用系统操作培训的培训资料。质量管理组质量管理组成员由厂家1人和甲方人员组成。主要职责是：负责制定工程的质量监控管理标准及实施细那么，负责工程的配置管理，负责工程文档的管理工作，对工程实施进行全程监控，及时向工程领导小组、工程经理提交质量监控报告。测试组测试组成员由厂家2人和甲方人员组成。主要职责是：负责工程集成测试、系统测试、初步验收测试的测试方案、测试方案的制定、实施和测试分析报告的编制，及时向工程领导小组、工程经理提交测试分析报告报告。应用实施组应用实施组成员由厂家2人和甲方人员组成。主要职责是：负责应用系统的安装、调试；利用应用效劳工具，通过配置、部署等方式，完成数据库的建立，制定及实施数据维护〔ETL〕方案；利用应用效劳工具，通过配置、部署等方式，实现应用功能。负责系统管理和监控方案的制定及实施，负责应用系统的试运行、现场信息收集及反应等工作。现场安装、调试过程中，需要用户配合工作。商务及培训组由厂家商务人员、技术人员和甲方相关人员组成。其职责如下：完成工程组确定的各项商务活动，保证工程所需各项产品的按时到货、验收，协调双方关系,为系统顺利实施做好配合工作；组织对用户的系统管理人员、操作人员进行相关的技术培训、应用系统操作培训等。维护效劳组由厂家技术人员和甲方相关人员组成。维护效劳组的人员来自工程实施过程中的软件开发人员和应用实施人员。进度方案工程从开始到安装部署上线并通过初验为90个日历日，其后进入试运行期。任务名称起止时间工作人员预期工作成果一、整体规划以及需求调研工程现场调研及工程总体实施设计T＋5(T代表合同签订日期)需求分析员工程方案需求分析报告二、软件任务分解系统的概要设计〔T＋5〕＋10设计工程师概要设计系统的开发〔T＋5＋10〕＋50实施工程师系统功能模块系统安装部署调试数据采集、综合库建设〔T＋5＋10＋50〕＋20测试工程师提交系统三、系统测试、试运行、培训以及初验和终验工程初验测试〔T＋5＋10＋50＋20〕＋5测试工程师工程测试报告系统试运行〔系统测试、调整、修改、试运行以及应用软件培训〕甲方定试运行期工程经理工程培训记录工程验收工程初验后＋试运行期工程经理工程终验合格证书及相关验收文档开发测试管理开发管理Java是一种优秀的面向对象开发语言，所以本系统的开发采用面向对象的开发方法。面向对象技术是软件技术的一次革命，在软件开发史上具有里程碑的意义。随着OOP〔面向对象编程〕向OOD〔面向对象设计〕和OOA〔面向对象分析〕的开展，最终形成面向对象的软件开发方法OMT(ObjectModellingTechnique〕。这是一种自底向上和自顶向下相结合的方法，而且它以对象建模为根底，从而不仅考虑了输入、输出数据结构，实际上也包含了所有对象的数据结构。所以OMT彻底实现了PAM没有完全实现的目标。不仅如此，OO技术在需求分析、可维护性和可靠性这三个软件开发的关键环节和质量指标上有了实质性的突破，彻底地解决了在这些方面存在的严重问题，从而宣告了软件危机末日的来临。1、自底向上的归纳OMT的第一步是从问题的陈述入手，构造系统模型。从真实系统导出类的体系，即对象模型包括类的属性，与子类、父类的继承关系，以及类之间的关联。类是具有相似属性和行为的一组具体实例〔客观对象〕的抽象，父类是假设干子类的归纳。因此这是一种自底向上的归纳过程。在自底向上的归纳过程中，为使子类能更合理地继承父类的属性和行为，可能需要自顶向下的修改，从而使整个类体系更加合理。由于这种类体系的构造是从具体到抽象，再从抽象到具体，符合人类的思维规律，因此能更快、更方便地完成任务。这与自顶向下的Yourdon方法构成鲜明的对照。在Yourdon方法中构造系统模型是最困难的一步，因为自顶向下的“顶”是一个空中楼阁，缺乏坚实的根底，而且功能分解有相当大的任意性，因此需要开发人员有丰富的软件开发经验。而在OTM中这一工作可由一般开发人员较快地完成。在对象模型建立后，很容易在这一根底上再导出动态模型和功能模型。这三个模型一起构成要求解的系统模型。2、自顶向下的分解系统模型建立后的工作就是分解。与Yourdon方法按功能分解不同，在OMT中通常按效劳〔Service〕来分解。效劳是具有共同目标的相关功能的集合，如I/O处理、图形处理等。这一步的分解通常很明确，而这些子系统的进一步分解因有较具体的系统模型为依据，也相对容易。所以OMT也具有自顶向下方法的优点，即能有效地控制模块的复杂性，同时防止了Yourdon方法中功能分解的困难和不确定性。3、OMT的根底是对象模型每个对象类由数据结构〔属性〕和操作〔行为〕组成，有关的所有数据结构〔包括输入、输出数据结构〕都成了软件开发的依据。因此Jackson方法和PAM中输入、输出数据结构与整个系统之间的鸿沟在OMT中不再存在。OMT不仅具有Jackson方法和PAM的优点，而且可以应用于大型系统。更重要的是，在Jackson方法和PAM方法中，当它们的出发点--输入、输出数据结构〔即系统的边界〕发生变化时，整个软件必须推倒重来。但在OMT中系统边界的改变只是增加或减少一些对象而已，整个系统改动极小。4、需求分析彻底需求分析不彻底是软件失败的主要原因之一。即使在目前，这一危险依然存在。传统的软件开发方法不允许在开发过程中用户的需求发生变化，从而导致种种问题。正是由于这一原因，人们提出了原型化方法，推出探索原型、实验原型和进化原型，积极鼓励用户改良需求。在每次改良需求后又形成新的进化原型供用户试用，直到用户根本满意，大大提高了软件的成功率。但是它要求软件开发人员能迅速生成这些原型，这就要求有自动生成代码的工具的支持。OMT彻底解决了这一问题。因为需求分析过程已与系统模型的形成过程一致，开发人员与用户的讨论是从用户熟悉的具体实例〔实体〕开始的。开发人员必须搞清现实系统才能导出系统模型，这就使用户与开发人员之间有了共同的语言，防止了传统需求分析中可能产生的种种问题。5、可维护性大大改善在OMT之前的软件开发方法都是基于功能分解的。尽管软件工程学在可维护方面作出了极大的努力，使软件的可维护性有较大的改良。但从本质上讲，基于功能分解的软件是不易维护的。因为功能一旦有变化都会使开发的软件系统产生较大的变化，甚至推倒重来。更严重的是，在这种软件系统中，修改是困难的。由于种种原因，即使是微小的修改也可能引入新的错误。所以传统开发方法很可能会引起软件本钱增长失控、软件质量得不到保证等一系列严重问题。正是OMT才使软件的可维护性有了质的改善。OMT的根底是目标系统的对象模型，而不是功能的分解。功能是对象的使用，它依赖于应用的细节，并在开发过程中不断变化。由于对象是客观存在的，因此当需求变化时对象的性质要比对象的使用更为稳定，从而使建立在对象结构上的软件系统也更为稳定。更重要的是OMT彻底解决了软件的可维护性。在OO语言中，子类不仅可以继承父类的属性和行为，而且也可以重载父类的某个行为〔虚函数〕。利用这一特点，我们可以方便地进行功能修改：引入某类的一个子类，对要修改的一些行为〔即虚函数或虚方法〕进行重载，也就是对它们重新定义。由于不再在原来的程序模块中引入修改，所以彻底解决了软件的可修改性，从而也彻底解决了软件的可维护性。OO技术还提高了软件的可靠性和健壮性。开发环境在工程实施过程中，工程开发环境建议：个人开发电脑

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

开发人员在开发效劳器上进行单元测试，系统分析师在上面对代码进行走查。建构管理效劳器

该效劳器用来管理当前版本及版本发行。测试效劳器

该效劳器用来进行系统的集成测试和交付测试。主要开发工具使用Eclipse作为主要开发工具。Eclipse是著名的跨平台的自由集成开发环境〔IDE〕。最初主要用来Java语言开发，但是目前亦有人通过插件使其作为其他计算机语言比方C++和Python的开发工具。Eclipse的本身只是一个框架平台，但是众多插件的支持使得Eclipse拥有其他功能相对固定的IDE软件很难具有的灵活性。许多软件开发商以Eclipse为框架开发自己的IDE。Eclipse最初由OTI和IBM两家公司的IDE产品开发组创立，起始于1999年4月。IBM提供了最初的Eclipse代码根底，包括Platform、JDT和PDE。目前由IBM牵头，围绕着Eclipse工程已经开展成为了一个庞大的Eclipse联盟，有150多家软件公司参与到Eclipse工程中，其中包括Borland、RationalSoftware、RedHat及Sybase等。Eclipse是一个开发源码工程，它其实是VisualAgeforJava的替代品，其界面跟先前的VisualAgeforJava差不多，但由于其开放源码，任何人都可以免费得到，并可以在此根底上开发各自的插件，因此越来越受人们关注。近期还有包括Oracle在内的许多大公司也纷纷参加了该工程，并宣称Eclipse将来能成为可进行任何语言开发的IDE集大成者，使用者只需下载各种语言的插件即可。Eclipse是一个开放源代码的软件开发工程，专注于为高度集成的工具开发提供一个全功能的、具有商业品质的工业平台。它主要由Eclipse工程、Eclipse工具工程和Eclipse技术工程三个工程组成，具体包括四个局部组成——EclipsePlatform、JDT、CDT和PDE。JDT支持Java开发、CDT支持C开发、PDE用来支持插件开发，EclipsePlatform那么是一个开放的可扩展IDE，提供了一个通用的开发平台。它提供建造块和构造并运行集成软件开发工具的根底。EclipsePlatform允许工具建造者独立开发与他人工具无缝集成的工具从而无须分辨一个工具功能在哪里结束，而另一个工具功能在哪里开始。Eclipse的插件机制是轻型软件组件化架构。在客户机平台上，Eclipse使用插件来提供所有的附加功能，例如支持Java以外的其他语言。已有的别离的插件已经能够支持C/C++〔CDT〕、Perl、Ruby，Python、telnet和数据库开发。插件架构能够支持将任意的扩展参加到现有环境中，例如配置管理，而决不仅仅限于支持各种编程语言。Eclipse的设计思想是：一切皆插件。Eclipse核心很小，其它所有功能都以插件的形式附加于Eclipse核心之上。Eclipse根本内核包括：图形API(SWT/Jface)，Java开发环境插件(JDT)，插件开发环境(PDE)等。验证测试管理验证与确认流程验证的目的，是确保工作产品符合其指定的需求。确认的目的，是展示置于预期环境中的产品或产品组件，可满足其预期的使用需求。验证和确认流程如下：系统测试方案因应本系统质量及平安性要求，当系统开发完成之后需要从功能整合、系统效能、系统接口、数据转换、平安等方面进行测试。系统测试方案规划如下：具体测试的执行方式如下表所述：测试类别测试标的测试者测试环境说明UT(单元测试)PG开发完成的组件、功能或程序〔包括数据转换及系统接口模块〕程序开发者(PG)开发环境功能验收前方可进行功能整合测试功能整合测试已验收的功能整合成模块〔包括数据转换及系统接口模块〕；模块整合成子系统测试团队功能整合测试环境功能整合测试由测试团队制订测试方案来执行，建议可以采用持续集成的方式执行效能压力测试经过功能整合的模块或子系统测试团队模拟生产环境效能测试建议直接在为生产而准备的软硬件环境下执行交付测试经过功能整合的模块或子系统测试团队交付测试环境数据转换和系统接口测试需与交付测试相结合，即待测系统的数据来源是通过数据转换及系统接口而来，并且能与外部系统正常介接数据转换测试经过功能整合的模块或子系统测试团队交付测试环境系统接口测试经过功能整合的模块或子系统测试团队交付测试环境HA测试系统软硬件环境与应用的搭配客户IT人员模拟生产环境挑选某批交付的产品进行HA测试用户系统整合测试(SIT)通过交付测试的分批交付产品(LotX)客户IT人员用户SIT环境分批交付的验收动作用户系统验收测试(UAT)通过用户SIT的分批交付产品(LotX)客户用户代表用户UAT环境用户完整系统验收测试(UAT)针对于已通过分批验收的完整产品客户用户代表用户UAT环境最终系统的验收验证与确认标准下面是软件设计开发过程中分析、评审的重要量化指标：活动产品度量单位平均值密度缺陷率合格率RDReviewReq.Doc.Req.Doc.由DFPV提供ADReviewADDoc.2.00-HDReviewHDDoc.2.00-DDReviewDDDoc.UC-7.00-UTCODEKLOC758.00-WTVaKLOC-5.00-ITVbKLOC354.50-RTVcKLOC61.500.45简写说明RD需求开发AD架构设计HD概要设计DD详细设计UT/CODE单元测试〔源代码〕WT/Va程序走查〔版本(a)〕IT/Vb整合测试〔版本(b)〕RT/Vc交付测试〔版本(c)〕UC用例KLOC千行代码实施管理工程开发实施方案为了确保工程目标达成和工程顺利实施，工程规划和工程的监控是至关重要的环节，因而我公司在工程管理过程中，对工程实施进行如下维度的规划：工程基准方案：依据工程管理的九大构面对工程进行整体规划，其内容包括工程目标及范围定义、工程本钱和预算、工程整体时程规划和里程碑方案、工程质量方案、工程组织和沟通方案、工程资源规划、工程环境及建构管理方案、外包及采购方案、工程风险方案，工程基准方案被视为工程组对公司和客户的承诺，并且作为工程执行绩效的比拟基准。阶段详细方案：依据基准方案的整体安排，工程不同阶段均会制订详细的时程方案，通过WBS分解并落实到具体活动(Activity)，作为每个阶段及每个团队工作执行的指导，并作为进度检查的重要依据。个人工作方案：依据详细方案安排的工作事项，会作为个人的工作包分配给具体的执行人，由执行人对工作进行细化，个人工作方案实质为个人对工程组的承诺。依据以上方案的内容，工程实施过程中，会有不同频度和范围的检讨：每日个人对工作包执行状态进行回报。每周进行小组或工程组织的进度审查，并且对于进度偏差及工程执行过程中所遇到的问题进行讨论和解决。每月工程审查会议，由工程组与工程相关干系人〔如：公司管理者、客户〕依据工程基准方案进行检查，对工程执行过程中的重大问题进行讨论和解决。里程碑审查会议，针对于工程重大里程碑设定评审会议，决定工程Go/NoGo的判定。沟通管理有效沟通是确保工程成功的重要保障，在工程管理过程中通过工程会议和检查以及问题沟通处理机制来保持沟通的通畅。工程检讨我公司每周五提供工程周报，报告一周来的工作进展情况。每周一举行一次工程会议，对上一周的工作进行讨论和总结，双方的工程经理均需出席。会议主要内容如下：检查工程执行情况跟踪风险调整方案跟踪行动跟踪异常情况通告工程进展情况问题处理工程实施过程中会遇到不同类别的问题，我们一般将问题分为以下四类：工程问题(PPR,ProjectProblemReport)，指工程管理范筹中，影响工程进度、交付、质量、本钱、沟通、人员管理和合约等方面的问题。工程问题在每周周会进行检讨，并且对于需要协调解决的问题需要由我公司和客户工程经理一同组织专门的会议协调相关的工程干系人(Stakeholder)参加会议进行讨论并解决问题。变更请求(CRR,ChangeRequestReport)，指与工程范围及软件产品需求基准(Baseline)相比拟而产生的变更，有新需求〔NewRequirement〕、需求变更(ChangedRequirement)或需求取消〔CanceledRequirement〕，从而影响到工程的进度、质量要求、交付的时间或开发的本钱等。工程的变更请求，既可以由客户直接提出，也可以由我公司工程组识别出来后通知客户，由客户认定后再提出变更请求。并且当双方对于变更请求的处理方案、人力及本钱预估存在争议，无法由双方工程组达成共识时，建议由CCB(ChangeControlBoard)来协调讨论，并对争议做最后裁决。其中CCB的构成由双方高层管理者、双方工程经理以及相应的领域专家构成。软件问题(SPR,SoftwareProblemReport)，指软件产品测试或验证过程中所发现的问题(Issue)。软件问题(SPR)的处理可以采用测试管理的工具来进行管理，但双方一定均能访问，并可以更新相应的状态和说明字段。软件问题(SPR)的处理结果及进度，可以列入到每周例会的检讨内容。Q&A(QuestionAndAnswer)，工程实施过程中需要进行澄清的疑问。工程实施过程中针对于不同方面的Q&A双方应指定对应的窗口，如技术问题、不同领域的需求功能问题等都有各自对应的窗口，这样会让问题有统一的管理并提高解答的成效。对于问题的提出，先由我公司内部进行讨论及解答，只有内部无法解答的问题才会提交客户回复。风险管理工程风险是工程管理过程中潜在的问题。工程风险可能引起工程不能按时交付，或达不到预期的质量，或需要增加工程本钱。风险管理是一种对工程风险进行识别、分析、应对的系统过程。它包括鼓励对工程目标有正面影响的风险发生并加强其影响、减小对工程目标有负面影响的风险发生并减弱其影响。风险管理策略如下列图：风险管理规划

决定如何进行与规划工程的风险管理活动。风险识别

判断哪些风险会影响工程，并做正式记录。风险分析

风险定性分析：对风险及其条件进行定性分析，并依其对工程目标影响进行排序。

风险定量分析：量度风险的概率与后果，估计其对工程目标造成的影响。风险应对规划

制订为工程目标增加时机、减轻威胁的程序与技术。风险监测与追踪

在工程整个生命期间监测剩余风险、识别新风险，执行减轻风险方案，并对这些方案的有效性进行评估。风险识别与分析风险是由工程团队成员〔客户方或农商行〕进行识别和分析的。风险必须上升到工程级对待。按照危险程度，风险可分为不同等级，对于风险等级为6到9的危急风险必须制定详细的解决方案。以下各表分别是风险严重性、风险可能性、风险等级的分类说明。风险可能性可能性描述1–Weak此类事件发生几率很小。2–Average此类风险发生和不发生的可能性均等。3–Strong此类事件很有可能发生。风险严重性严重性描述1–Weak此类风险不影响工程预期目标，如本钱、进度、质量、技术内容。2–Average此类风险影响工程局部功能但不阻碍最终执行。3–Strong此类风险影响方案的执行。可能最终因起财务损失，甚至影响工程。风险等级风险处理流程质量管理质量管理，是指质量管理员〔QA〕通过对工程过程中的产品或效劳进行有效的稽核，以确保工程的品质不出现问题。工程启动阶段，品质保证员将根据工程的基线方案和详细开发方案制订品质稽核方案，列出稽核点和稽核时间。工程实施过程中，品质保证员将按照方案进行品质稽核工作，对发现的问题产生不合格报告，并对不合格报告进行追踪，以监督工程组对不合格问题进行改良。每周品质保证员将提交品质稽核周报，在工程周会上进行检讨。工程结案阶段，品质保证员将对整个工程实施过程中的品质情况进行分析和总结，提交工程品质分析报告。品质保证流程图：建构管理建构管理流程领域使用建构识别、建构控制、建构状态纪录，以及建构稽核，来建立与维护工作产品的完整性。并经由建立与维护工作产品的完整性，来支持所有的流程领域。开发环境在工程实施过程中，工程开发环境建议：个人开发电脑

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

开发人员在开发效劳器上进行单元测试，系统分析师在上面对代码进行走查。建构管理效劳器

该效劳器用来管理当前版本及版本发行。测试效劳器

该效劳器用来进行系统的集成测试和交付测试。建构管理对象纳入建构管理的工作产品包括：交付客户的产品、指定的内部工作产品、采购的产品、工具，以及用来产生与说明这些工作产品的其它工程。建构管理工作内容建构管理工作内容包括：识别建构项、规划基线、创立建构馆、变更管理、冻结版本、发行版本、例行工作管理。建构管理工具使用CSV/SVN作为系