系统需求分析
2.1 整体需求概述
根据某XXXXXXXX管理公司实际业务调研分析，可将其系统需求划分为7个部分：基础信息维护、网上报修、权限管理、动力消耗、物料管理、收费管理、报表分析。
2.1.1 基础信息维护
基础信息维护包括对以下业务基础数据的采集和维护：
- 楼房：关于社区楼宇信息的维护，包括区域划分，楼宇分布以及其他相关基本信息。
- 库房：关于XXXXXXXX管理中心库房信息的维护，包括库房预警参数，库房调拨策略等信息。
- 住户：关于社区住户或业主的基本信息维护，包括住户家庭基本状况，家庭成员构成，姓名，职业特征，年龄段及联系方式等。
- 物品：关于库房物品及日常消耗品基本信息的维护，包括物品类别，物品名称，物品供应商，物品规格，计量单位，型号，库品类别，物品使用期限等。
- 收费项目：对于XXXXXXXX诸多收费项目信息的定义和维护，如水电煤气费用，XXX管理费，社区照明费，社区热水费及其他收费项目。
- 字典信息：字典信息主要是初始化系统时设定的系统控制参数和逻辑开关参数，如加价策略，出入库策略，调拨策略等。
2.1.2 网上报修
网上报修业务是XXXXXXXX服务的一个重要组成单元，通过提供一整套事件响应、处理和跟踪，直到事件结束的全过程管理服务。整个业务流程由以下6个环节组成：
- 网上报修申请：业务用户可以通过网络进行报修申请，并可以通过网络对XXX服务进行意见反馈和投诉。也可以通过网络查询维修历史记录和处理结果。
- 内部报修申请：包括对传统的电话报修和内部检测故障申请报修事务的处理。由报修中心统一处理和汇总。
- 报修单据确认：报修中心对报修申请单进行审核，并按照系统执行策略选择人工或自动分派任务到各维修站，分派策略包括：最优路径，专业维修，维修饱和度均衡等。
- 维修处理跟踪：对于维修任务的响应，物料申领，现场处理，用户确认，用户反馈/投诉，维修结束，返还物料流程的全程跟踪。
- 回访记录：维修中心及各维修站负责人定期对近期维修事务的随机回访，已了解和确认维修结果，具体考察：响应速度，服务态度，服务质量，维修完成情况，物料使用情况，整体满意度等指标。
- 综合查询：对于XXX管理历史业务数据的综合查询，实现全过程全节点查询。
2.1.3 权限管理
权限管理的主要需求是提供用户身份认证、部门权限控制、功能权限控制等操作控制机制和安全防护策略。
根据用户角色可进一步划分为：
- 系统管理员：对系统进行统一的维护管理，保证系统正常运行；
- 部门主管：对系统进行统一的设置管理，保证业务正常运行。根据具体业务部门可进行初始设定，如XXX报修业务主管、XXX中心库房主管、动力消耗主管、业务收费处主管、财务主管等；
- 业务及工作人员：执行具体业务操作和执行具体工作任务。根据业务部门的具体工作岗位进行界定，如XXX维修工，水煤电气工，库管员，出纳，XXX收费员等；
- 普通用户：可查询信息。
权限管理包括用户管理，机构部门管理，角色管理，菜单管理，资源管理，菜单资源维护，角色菜单维护，部门授权等功能。
2.1.4 动力消耗管理
动力消耗管理主要处理XXXXXXXX所管辖区域内的各类动力设备的日常维护和记录消耗数据并据此进行能耗分析。此业务单元主要包括：
- 设备管理：设备类别及基本信息维护，如设备使用状态维护，当前位置，最近使用人等信息。
- 设备维修：设备因故或定期检修，首先提交维修申请，更改设备状态定为停用，设定维修周期，跟踪维修状态，统计历史维修次数和维修记录，记录本次维修详细信息，修复后交付，恢复设备状态重新启用。
- 电梯运维：社区内所有电梯设备的日常维护记录，包括电梯故障记录，定期检修记录，电梯工排班等。
- 空调供暖管理：社区内所有空调及供暖装置的维护记录，包括空调供暖设备故障的记录，定期检修记录，打印供暖收费清单。
- 水电煤气管理：社区内所有水电煤气设备的维护记录，包括计费和打印应收费用清单。
2.1.5 物料管理
物料管理是对XXXXXXXX公司各部门对物品、材料及设备的采购、调用和消耗过程的控制和管理。主要包括以下5个业务单元：
- 采购管理：有采购部门下发采购订单，经过审核后进行采购并生成送货单；跟踪并验收供应商所送物资，生成验收单。
- 库房管理：XXX中心库房根据验收单入库，同时生成入库单；库房可随时进行入库单查询及库存查询；当库房接到出库申请如调拨出库单或维修领料申请单时，经过审核后填写出库单并作物资出库操作；需要处理维修部门的退还物料请求，登记退货入库单，并作入库操作；物料退换记录，目前可在备注中记录，需进行原物料、等数量退换。
- 领料管理：维修站维修工填写维修领料申请单，申领维修物料，库房审核通过后，领取相应物料。
- 库房查询：库管及采购中心及XXX中心领导均可随时查看库房出入库记录，及当前库存状况，包括当前库存量，物资库存上限、下限预警提醒等。
- 出入库统计：统计任意时间段内所产生的出入库台账。
2.1.6 收费管理
收费管理主要针对XXXXXXXX公司经营的各项有偿服务项目的收支记录及统计报表分析。主要包括：应缴费用管理，费用冲销处理，费用调整处理，银行代扣处理，收款管理，退款管理，欠费查询等。需要提供第三方财务接口。
2.1.7 报表管理
报表管理主要针对XXXXXXXX公司各业务部门提供的数据进行汇总分析。主要包括以下8类报表：
- 报修历史分析：报修历史分析提供的是对一定时期的报修事件的综合分析报表，可以按照报修类别，时间段，区域，规模大小进行汇总分析，从多个维度分析和评价XXX整体的服务水平和响应能力，甚至可以协助管理者预先找到服务短板和问题集中点，以采取预防措施。
- 动力消耗分析：动力消耗分析提供XXXXXXXX动力部门的业务汇总数据，如某一段时间内水煤电气消耗数据，动力消耗的区域分布图分析，并辅助管理者从数据报表中找出动力消耗的动态变化规律。
- 库存报表分析：库存报表反应的是与库存相关的数量，价格及金额的变化情况。如物资出入库汇总表，库房盘点表，库房物资预警分析。
- 设备故障分析：设备故障分析主要是对社区内公共设施设备故障率及故障维修状况的统计分析。
- 设备使用分析：设备使用效率及利用率分析，有效的调配设备，及调整设备资源的分配和部署。
- 费用收支汇总：费用收支汇总表详细的统计一个时间段内的XXXXXXXX各项XXX收入及费用支出汇总数据。
- 收缴率分析：对各项XXX管理服务费收缴情况的查询和统计分析，便于追缴和分析拖欠率及原因，为制定收缴策略提供决策依据。
- 满意度分析：对用户一段时期内的投诉进行汇总分析，以分析用户满意度。
2.2 功能需求分析
2.2.1 基础信息维护需求分析
基础信息其实就是XXXXXXXX管理中所涉及到的对象的基本信息，它是开展各项业务的前提条件和准备条件。
基础信息维护的用例分析如下图：
此XXXXXXXX管理中所涉及的基础信息用例描述如下表：
| 基础信息项 | 所包括对象 | 用例说明 |
| 楼房信息 | 楼房类别 | 楼房寓所类别信息的定义。 |
| 楼房基本信息 | 关于楼房寓所属性的定义。 | |
| 库房信息 | 库房基本信息 | 对XXXXXXXX库房属性的定义。 |
| 库房类别 | 关于库房类别信息的定义。 | |
| 出入库策略 | 对库房出入库方式信息的定义。 | |
| 库房预警参数 | 对库房所存物品的保质期和库存量进行预警参数设置。 | |
| 住户信息 | 业主基本信息 | 对社区住户属性的定义。 |
| 物品信息 | 物品类别信息 | 对物品类别的编号和定义。 |
| 物品基本信息 | 对物品基本属性的定义。 | |
| 收费项目 | 收费类别信息 | 对收费类别的编号和定义。 |
| 收费项目信息 | 对具体收费信息的定义。 | |
| 字典信息 | 国别信息 | 对于国家信息项的维护。 |
| 省市地区信息 | 对于省市信息项的维护。 | |
| 计量单位信息 | 对于物品物料计量单位的定义。 | |
| 货币种类信息 | 对于经营中所涉及货币种类信息的定义。 | |
| 单据类型信息 | 对于经营中所涉及的单据种类信息的定义。 | |
| 供应商信息 | 对供应商属性信息的定义。 |
对于基础信息需求的补充说明：
- 可扩展
基础信息模块随着后期功能需求的增加或变更，其所包括的基本信息内容可进行扩展和更改。
- 需前置设置
在开展日常管理工作或处理具体业务流程时，这些信息需提前设置好。
- 不可更改和替换
对于已开展的工作和业务所涉及到的基础信息项，其字典信息原则上不允许任意更改，替换和删除，这样以保证数据的一致性。如必需处理，则可进行数据的级联更新或删除处理。
2.2.2 网上报修需求分析
2.2.2.1优化前报修业务流程图
通过对该社区原有XXX报修业务流程的分析研究，可以全面的了解和把握当前业务流程的运作情况，为接下来的流程整合和优化工作打下基础。
此XXXXXXXX报修业务流程是本项目重点优化和实现的一个单元，因为在这个业务流程中涉及到XXXXXXXX管理多部门多角色。同时，它又和多个业务单元相互联系，如物料管理，财务管理（不包括在本系统中，仅提供接口），出入库管理（包含在物料管理内）等。具体业务流程如下图所示。
2.2.2.2报修业务实体分析
XXX报修业务的处理工作主要涉及的实体包括：业主/申请单位，XXX报修中心，维修站，XXX管理中心库房。
- 业主/申请单位：即业务发起环节。报修申请人及申请单位，也是此项业务的发起人。也是报修任务的最终验收人，并根据实际维修结果对其服务进行评价或投诉。
- XXX报修中心：即业务控制调度环节。受理报修申请，并下发检修单，分派到各分中心进行处理；对历史报修工作进行监督，检查，定期评测；接收来自业主的投诉及意见反馈。
- 维修站：及业务执行环节。接到报修控制中心下发的维修任务，快速响应，根据维修单上的报修项目申领维修用物料，并提交申领单；维修人领取物料后进行现场检修，对检修过程进行记录，再由报修申请方确认维修记录单，维修人员携带维修确认单返回维修站，进行维修登记，由班组长统一审核记录。当前对于剩余的物料和物料使用情况未进行有效处理。
- XXX管理中心库房：对维修站提交的物料申请进行审核，并根据物料申领需求进行物料调拨出库操作；库房定期进行盘点和结算，但此部分工作并未和报修中心对接。物料采购，物料返还及库房调拨等业务尚待整合和优化。
2.2.2.3报修业务流程优化
通过对实际现有业务流程的分析，在此基础上对XXX管理中心的报修业务流程进行系统改造和优化，整合相关业务；优化流程次序，从而实现整体流程高效而完善。
- 整合业务流程
- 通过分析当前各业务流程，找出冗余和重复的业务项，分析具体操作的差异性；
- 分析业务流程中的核心环节，各项工作都将围绕这些核心环节展开：开放的报修渠道、高效的响应机制、物料申领、维修反馈；
- 与业务人员和部门负责人沟通，确定主要业务操作的详细需求，并尽可能的将需求进行量化。经过上述步骤，去除重复业务操作，把性质相同、需求近似的业务作为重点整合对象。整合后的基本业务流程包括以下操作：报修申请—>维修确认—>分派维修任务—>申领物料—>维修记录—>维修结果确认及反馈—>结算。
- 对业务流程进行优化
- 借助管理信息系统简化业务处理流程。报修申请下发后，在维修中心接到报修申请之后，可直接分发任务通知到相应维修站，而不用再通过转发给分中心，再由分中心进行派发或转发，以加快报修响应速度，提升用户满意度。
- 实现物料申请到返还的全面审核跟踪机制。通过对维修站申领物料，经过负责人审批后到库房领料，再到库房据此进行物料出库或调拨，并对维修后结余物料进行返还、归库等操作的控制和管理，能够规范XXX管理中心的管理，进行有效的成本控制，以提高效益。
- 通过信息化手段来实现系统化控制和管理。作为旨在建设具有现代服务型社区的XXX管理企业，需要敏锐洞察市场以理解用户需求，并快速响应和执行决策。这就需要对XXXXXXXX整体业务进行系统化控制和集中管理。
通过对原有业务流程的整合和优化，从XXXXXXXX管理全局出发，通过规范业务流程和完善企业管理制度来提升工作效率和服务质量，最终实现提升业主满意度和降低XXX管理成本的目标。
经过上述分析，整合和优化后的业务流程如下图所示。
2.2.2.4网上报修需求分析
网上报修需求分析表如下：
| 岗位 | 案例标题 | 需求说明 |
| 业主/申请单位 | 网上报修申请 | 业务用户可以通过网络进行报修申请，并可以通过网络对XXX服务进行意见反馈和投诉。也可以通过网络查询维修历史记录和处理结果。 |
| 申请单位 | 内部报修申请 | 包括对传统的电话报修和内部检测故障申请报修事务的处理。由报修中心统一处理和汇总。 |
| 维修中心 | 报修单据确认 | 报修中心对报修申请单进行审核，并按照系统执行策略选择人工或自动分派任务到各维修站，分派策略包括：最优路径，专业维修，维修饱和度均衡等。 |
| 维修站 | 领取物料 | 维修站人员根据派工单维修事项申请领用相关物料及设备。 |
| 库房 | 物料出入库管理 | 库房根据接收采购入库接口，生成入库单做入库操作，库存增加； 库房根据物料申领填写物料出库单，并做出库操作，库存减少。 |
| 库房 | 库房结算 | 月末库房进行盘点并结算。 |
| 维修站 | 维修处理跟踪 | 对于维修任务的响应，物料申领，现场处理，用户确认，用户反馈/投诉，维修结束，返还物料流程的全程跟踪。 |
| 维修中心 | 回访记录 | 维修中心及各维修站负责人定期对近期维修事务的随机回访，已了解和确认维修结果，具体考察：响应速度，服务态度，服务质量，维修完成情况，物料使用情况，整体满意度等指标。 |
| 维修中心领导 | 综合查询 | 对于XXX管理历史业务数据的综合查询，实现全过程全节点查询。 |
其余特殊要求：
- 单据归档处理
对于报修确认结束后的报修确认单要进行回笼归档处理。由各维修站负责人评价审核后报维修中心存档，以备历史查询和汇总分析。
- 报修评价
对于每次确认结束的报修任务，各维修站负责人都将对该次维修结果予以评价和跟踪考核，对于客户的投诉也将纳入到评价中。评价的结果对于中心领导对该维修站、维修主管和技工的工作和服务质量起到辅助监督作用。
- 客户投诉及查看
客户投诉功能实现对报请维修事件的跟踪和反馈处理。客户可以通过投诉机制反馈他们对此次维修服务的处理情况、响应时间及用料情况进行记录和反馈，这些反馈将作为评价资料保存，在控制成本和规避风险的同时，增进了与客户的沟通，提高了客户服务水平。
2.2.2.5网上报修用例分析
网上报修需求部分用例分析如下：
用例文本详细描述如下表。
| 用例名称 | 提交报修申请表 |
| 参与执行者 | 客户/报修单位提请人 |
| 入口条件 | 报修申请内容已存在 |
| 基本事件流 |  |
| 出口条件 | 信息填写完备，如提交人联系方式，报修地点，时间，报修类别等。 |
| 特殊需求 | 对联系电话进行位数识别，固定电话: 15> N >6,手机: 12> N >11 |
| 用例名称 | 下发维修任务 |
| 参与执行者 | 维修中心主管 |
| 入口条件 | 维修申请已提交，客服中心已受理 |
| 基本事件流 | |
| 出口条件 | 故障属实，任务明确，任务可落实到维修工 |
| 特殊需求 | 无 |
| 用例名称 | 生成派工单 |
| 参与执行者 | 维修主管 |
| 入口条件 | 有新维修任务，有可派维修工，有可用物料，维修时间有效 |
| 基本事件流 |  |
| 出口条件 | 指定派工人员存在，分配物料存在 |
| 特殊需求 | 对维修响应日期和时间进行有效性判断：是否 >= 当前时间+30分钟 |
2.2.3 权限管理需求分析
本XXXXXXXX管理公司对权限管理的需求可分为四个实体对象和三个逻辑关系如图：
图5 权限管理对象实体及逻辑关系结构图
2.2.3.1实体描述
- 组织机构或各业务部门
公司的组织机构由集团统管，在各区分设XXX管理公司，公司由各级业务部门构成。其中主要包括XXX报修中心，客服中心，动力消耗部门，财务部，人力资源部，库房，结算中心等部分。
- 岗位及角色
从集团到各级业务部门所涉及到的岗位/角色主要包括：楼管，维修部水煤电气工，维修中心主管，客服工作人员，客服部经理，动力技工，动力中心主任，财务主管，人事经理，库管员，XXX费收缴员，结算中心主任，XXX中心经理等。
- 用户
用户分为3级，分别为系统管理员、数据管理员和普通用户。
| 用户分类 | 需求说明 |
| 系统管理员 | 部门管理，角色管理，用户管理，部门角色，角色权限管理。 |
| 数据管理员 | 基础设置、数据维护、数据查询、数据统计。 |
| 普通用户 | 在权限内对业务中的数据进行查询、统计及处理。（包括集团总经理、分公司经理、部门负责人、库管员、业务人员、社区居民等。） |
- 资源即职责及功能权限
对应可操作的权限范围和边界的定义。
2.2.3.2逻辑关系
- 用户-部门关系
用户与部门之间在实际中存在多对多关系，即一个人可以在多个部门下挂职，一个部门有着多个员工。在需求分析模型中，我们最终将此关系抽象为多对一之关系，即一个用户只对应一个部门，而一个部门可以对应有多个用户。
- 部门-角色关系
一个部门具有多个岗位职责，通过角色来进行定义，部门与角色之间也是一对多关系，即一个部门拥有多个岗位职责（角色），而一个角色只能从属于一个部门。
- 角色-权限关系
最终通过对角色授权，建立角色与功能权限的关系。此处角色与权限之间可以是多对多关系，即一个角色对应多个权限，而一个权限也可以分给多个角色。
通过在各实体对象之间建立有效的逻辑关系，实现了权限的继承和传递。用户最终通过自己所在的部门获得该部门所拥有的角色权限。
2.2.4 动力消耗管理需求分析
动力消耗管理主要处理XXXXXXXX所管辖区域内的各类动力设备的日常维护和记录消耗数据并据此进行能耗分析。
- 设备管理：设备类别及基本信息维护，如设备使用状态维护，当前位置，最近使用人等信息。
- 设备维修：设备因故障或定期检修，首先提交维修申请，更改设备状态定为停用，设定维修周期，跟踪维修状态，统计历史维修次数和维修记录，记录本次维修详细信息，修复后交付，恢复设备状态重新启用。
- 电梯运维：社区内所有电梯设备的日常维护记录，包括电梯故障记录，定期检修记录，电梯工排班等。
- 空调供暖管理：社区内所有空调及供暖装置的维护记录，包括空调供暖设备故障的记录，定期检修记录，打印供暖收费清单。
- 水电煤气管理：社区内所有水电煤气设备的维护记录，包括计费和打印应收费用清单。
2.2.5 物料管理需求分析
物料管理是对XXXXXXXX公司各部门对物品、材料及设备的采购、调用和消耗过程的控制和管理。主要包括以下5个业务单元：
- 采购管理：有采购部门下发采购订单，经过审核后进行采购并生成送货单；跟踪并验收供应商所送物资，生成验收单。需要提供第三方接口。
- 库房管理：XXX中心库房根据验收单入库，同时生成入库单；库房可随时进行入库单查询及库存查询；当库房接到出库申请如调拨出库单或维修领料申请单时，经过审核后填写出库单并作物资出库操作；需要处理维修部门的退还物料请求，登记退货入库单，并作入库操作。需要支持物料退换记录，需进行原物料、等数量退换。
- 领料管理：维修站维修工填写维修领料申请单，申领维修物料，库房审核通过后，领取相应物料。
- 库房查询：库管及采购中心及XXX中心领导均可随时查看库房出入库记录，及当前库存状况，包括当前库存量，物资库存上限、下限预警提醒等。
- 出入库统计：统计任意时间段内所产生的出入库台账。
2.2.6 收费管理需求分析
收费管理主要针对XXXXXXXX公司经营的各项有偿服务项目的收支记录及统计报表分析。主要包括：应缴费用管理，费用冲销处理，费用调整处理，银行代扣处理，收款管理，退款管理，欠费查询等。需要提供第三方财务接口。
2.2.7 报表分析模块需求分析
报表管理主要针对XXXXXXXX公司各业务部门提供的数据进行汇总分析。主要包括以下8类报表：
- 报修历史分析：报修历史分析提供的是对一定时期的报修事件的综合分析报表，可以按照报修类别，时间段，区域，规模大小进行汇总分析，从多个维度分析和评价XXX整体的服务水平和响应能力，甚至可以协助管理者预先找到服务短板和问题集中点，以采取预防措施。
- 动力消耗分析：动力消耗分析提供XXXXXXXX动力部门的业务汇总数据，如某期间内水煤电气消耗数据，动力消耗的区域分布图分析，并辅助管理者从数据报表中找出动力消耗的动态变化规律。
- 库存报表分析：库存报表反应的是与库存相关的数量，价格及金额的变化情况。如物资出入库汇总表，库房盘点表，库房物资预警分析。
- 设备故障分析：设备故障分析主要是对社区内公共设施设备故障率及故障修复
状况的统计分析。
- 设备使用分析：设备使用效率及利用率分析，有效的调配设备，及调整设备资源的分配和部署。
- 费用收支汇总：费用收支汇总表详细的统计一个时间段内的XXXXXXXX各项XXX收入及费用支出汇总数据。
- 收缴率分析：对各项XXX费收缴情况的查询和统计分析，便于追缴和分析拖欠率及原因，为制定收缴策略提供决策依据。
- 满意度分析：对用户一段时期内的投诉进行汇总分析，以分析用户满意度。
2.3 非功能需求
2.3.1 可扩展性
随着XXX管理提供的服务项目日益增多，原有的业务流程不断更新，信息化必须适应这一形势的需要，提供简单的方法完成新业务的扩充。当新业务产生时，只要它有明确的单据格式、计算方法、业务流程要求，就可以很快地在系统中加入该模块，提供给业务人员使用。
需具有较强的集成能力。与XXX服务相关的其他系统进行集成，通过标准的数据接口，将财务数据、原始单据、银行接口集成到核心业务系统中来协同完成任务。
根据XXXXXXXX管理行业的业务功能和处理模式较为独立的特点，将应用进行封装，通过组件化管理保持其独立应用能力；针对XXX管理中各主要组织单元制定相应的业务流程，完成功能组件对流程的装配，保证满足业务要求的灵活性，能够保证系统能够最大程度的适应业务需求，保持良好的扩展适应能力。
2.3.2 安全性
项目在安全性建设方面主要注重如下表所示的安全措施和指标。
| 编号 | 安全指标名称 | 安全标准 |
| 1 | 网络安全 | 防止黑客或非法侵入，进行网络监控，对已知的潜在威胁进行有效的防范，保障网络的正常工作。 |
| 2 | 设备安全 | 确保不受自然灾害或物理损坏的影响。 |
| 3 | 业务系统安全 | 防止因系统内在缺陷或漏洞对系统安全造成的损害。 |
| 4 | 数据存储安全 | 采用同步数据备份机制，确保数据信息的安全。 |
| 5 | 系统访问安全 | 通过权限机制控制用户对业务系统的操作的约束。 |
| 6 | 身份认证及权限控制 | 对登录用户的身份进行有效性认证。 |
| 7 | 安全制度 | 制定必要的安全管理制度和措施，如机房出入管理制度、系统维护制度、数据定期备份制度、各种紧急情况的应急措施等。 |
| 8 | 病毒防范 | 在系统中安装防病毒软件；对防病毒软件及时升级；对计算机使用人员进行防病毒教育和必要培训，提高对病毒的防范意识，防止计算机病毒对系统造成破坏。 |
2.3.3 性能需求
性能需求主要体现在以下几个方面：
- 时间特性，即对事务的响应时间。定义为：
在带宽为100k/s的网速条件下，系统平均响应时间：2秒之内；
在带宽为100k/s的网速条件下，系统最长响应时间：10秒以内；
在峰值负载期，与所规定的响应时间的允许偏离范围：±5秒。
- 负载量
要求负载量为1000人，最大并发数为100人，在最大并发数的情况下系统反应时间不超过20秒。
下表分列出了具体的性能参数指标：
| 编号 | 指标名称 | 性能指标值 |
| 1 | 系统寿命 | ≥5年 |
| 2 | 支持终端数 | ≥1000 |
| 3 | 无故障不间断运行时间 | ≥720小时 |
| 4 | 数据浏览响应时间 | ≤3s |
| 5 | 数据处理响应时间 | ≤1s |
| 6 | 数据查询响应时间 | ≤5s |
| 7 | 服务器CPU负载率 | ≤40% |
| 8 | 可支持并发访问数 | ≥50 |
| 9 | 处理能力扩展性 | 支持自动扩展 |
| 10 | 网络平台性能 | 数据传输安全稳定 |
| 11 | 系统平台性能 | Win 2003/2008 Server & Sql Server2005 |
| 12 | 应用支撑平台性能 | 具有良好的可扩展性和可配置性 |
| 13 | 应用系统性能 | 稳定，可靠，实用，人机交互友好，查询快捷，操作简捷。 |
2.4 本章小结
本章概要的描述了某XXXXXXXX管理公司XXX管理的业务现状，并对其各主要业务单元进行了详细的需求分析，阐明了此XXXXXXXX管理需求的特殊性，归纳出本课题需要重点解决的问题。
第三章 系统技术方案
当前，面向对象的设计开发是系统研发的主流方法，而在众多的面向对象的设计开发平台中，被广泛应用并逐渐形成成熟框架和技术规范的主要就是.Net技术架构和J2EE技术架构。
上个世纪90年代，面向对象的编程(OOP)引发了诸多的软件开发标准。首当其冲的是Microsoft的组件对象模型(COM)，这是一个模块(组件)化的技术开发架构，它源自于微软早期的对象链接与嵌入技术(OLE)。今天互联网应用中最常见的ActiveX技术就是构建在COM框架之上。2002年微软全面的用.NET从逻辑层上置换了COM，作为新的软件开发框架(COM仍然被支持)。.NET技术的全面推进，统一了微软的不同技术理念和平台。.NET为Web Service提供了原生的解决方案，并且成为提升不同应用和系统之间互操作性的标准。
Sun公司于1995年推出了Java平台。Java平台由一套应用开发语言(Java)、API和Java虚拟机(JVM)构成，JVM允许用Java编写的程序运行在不同的操作系统上。事实上，Sun引入Java使得程序员能够开发可移植的应用程序，而不用关心硬件和操作系统。在1999年末，Sun提出了Java平台企业版(J2EE，Java to Enterprise Edition)，该规范被应用在主要的IT提供商以构建稳健的应用系统框架。2003年Sun公司发布了J2EE 1.4版，除了增强更加稳固的企业级应用之外，还增加了Web Services支持。
在过去的发展中，.NET和J2EE平台在全球范围里都未能保持着对对方的绝对优势，他们各自有着自己的特色。影响.NET和J2EE选型的最大因素取决于研发机构内部的可用资源和所研发项目的特点。
相比而言，.Net技术拥有很多适合本项目研发的特性，如：它具有先进的理念，远离系统底层，高效敏捷的开发路线，多语言环境，友好方便的界面开发环境，功能丰富的组件集成开发平台等。所以本课题项目采用.Net技术架构进行系统研发。
以下内容是以.Net技术架构为背景作系统技术概述。
3.1 基于.Net的技术框架
3.1.1 .Net的构成
- .NET平台
这一平台建立在XML和因特网标准协议的基础上，包含了.NET的基础结构和基础工具，为开发新型的互动协作软件提供了一个先进的体系结构模型。
- NET系列产品和服务
如MSN.NET、OFFICE.NET、Visual Studio.NET等。
- Partner的.NET服务
建立在.NET平台和产品上的面向不同应用领域的具体服务。
3.1.2 .Net的技术特征
.NET技术主要有4个重要特点，一是软件变服务，二是基于XML的共同语言，三是融合多种设备和平台，四是新一代的人机界面。这四个特点基本上覆盖了.NET的技术特征。由于篇幅所限，此处不再对这些技术特征展开详细论述。
3.1.3 .Net技术架构
.Net整体架构可分为界面显示层、业务逻辑层及数据访问层三层，对于三层间的通信，可直接基于接口来进行调用，也可以通过被调用层所暴露的Service来进行通信，应根据不同的情况来灵活确定（如下图所示）。比如，对于界面显示层与业务逻辑层的通信，如果系统是C/S架构，用户的客户端只是做简单的数据显示，所有的业务逻辑全部放在服务器端的业务逻辑层来进行，则客户端的界面显示层通过访问业务逻辑层所暴露出的Service来进行通信；对于B/S架构来说，如果系统的业务复杂，数据访问量很大，考虑到负载均衡、备份等因素，可能将三层分别部署在不同的服务器上，同时各层也有不同的集群策略，此时，界面显示层与业务逻辑层间的通信，也是通过Service来进行。相反，如果系统的业务规模较小，三层均部署在同一台服务器上，则界面显示层与业务逻辑层之间直接通过接口进行调用。同样，对于业务逻辑层与数据访问层的之间的通信也是如此。
对于界面显示层，不包含任何业务逻辑，仅仅负责界面显示，因此，不论是基于Windows Presentation Foundation、WinForm，还是基于ASP.NET来实现，在业务逻辑层上都有统一的访问接口。界面显示层包含了界面显示的元素及简单的显示逻辑，如图所示。
-
-
-
- 界面显示层的设计需要满足以下目标
-
-
- 根据项目的需要可以选择B/S、C/S或SmartClient的实现；
- 能够对界面风格进行统一管理；
- 界面能够支持国际化与本地化。
-
-
- 界面显示层可选组件
- Microsoft Composite UI Application Block，用于SmartClient界面的开发；
- Microsoft User Interaction Process Application Block，可支持WinForm、SmartClient、ASP.NET程序的开发，用于将界面与显示逻辑、用户交互、界面流向等分离；
- DotNetNuke，开源的Web应用程序开发框架；
- WPF，微软新一代界面显示技术，B/S与C/S的融合。
-
-
本系统采用ASP.net 程序开发。
- 业务逻辑层
对于业务逻辑层，封装了系统的业务逻辑，并提供了供外部访问的接口，包括API形式的调用接口（用于同一进程中的local调用），以及基于WCF暴露给外部的Service（用于分布式的remote调用）。
对于暴露给外部的Service，有的只提供给界面显示层，有的只提供给外部系统；另外还有一些Service可以同时提供给界面显示层及外部系统，但提供的方式和策略是不同的，比如，考虑到网络环境及安全性要求等因素，对于不同的访问请求需要有不同的策略，对于界面显示层的请求，可以以二进制的SOAP格式通过TCP协议进行通信，而对于外部系统的请求，则以SOAP通过HTTPS进行通信。这种策略的定义，在WCF中是很容易配置的。
对于业务逻辑层所需要的数据，来源于两方面，一是来源于数据访问层，二是来源于外部系统。
- 数据访问层
对于数据访问层，封装了对各种数据源的访问操作，提供了对底层的数据源，如多种关系型数据库以及CVS、Excel、其他各种文件等的统一访问接口，屏蔽不同数据源之间的差异，并且提供O/R-Mapping层，根据不同项目、不同模块的需要，返回给业务逻辑层的数据，可以是业务对象形式（在O/R-Mapping层进行转换），也可以是基于表结构的DataReader、DataSet等对象。
数据访问层对外提供的访问接口，也包括API形式的调用接口，用于同一进程中的local调用，即业务逻辑层与数据访问层部署在同一台服务器上，被业务逻辑层直接调用，以及基于WCF暴露给外部的Service，用于分布式的remote调用，即业务逻辑层与数据访问层部署在不同的服务器上，供业务逻辑层调用。
数据访问层可以再细分为两个层面，一层是用来进行O/R-Mapping，另一层是用来屏蔽数据源，如多种关系型数据库以及CVS、Excel、及其他各种文件等之间的差异，如架构设计图中的数据访问层的设计所示。
目前现有的一些数据访问层组件，在实现上将上述提到的两层结合在一起进行了实现，如微软的Data Access Application Block，提供了数据访问的统一接口，屏蔽了数据库的差异性，但并未实现O/R-Mapping。
数据访问层可选择组件：
·Microsoft Data Access Application Block；
·ADO.net。
- 基础组件
.Net 技术架构图的左侧是一些基础性的组件，这些组件可能跨越了不同的层，分别从不同的方面提供了相应的功能。
3.2 基于MVC的设计模式
MVC（Model-View-Controller）设计模式被广泛应用于企业级WEB应用的开发中。MVC设计模式强制我们将应用分解成三个部分：模型（Model）负责业务数据的存储及管理，视图（View）负责呈现数据，并为用户提供与系统交互的界面接口，而控制器（Controller）则负责将用户动作转换成相应的业务数据集合传递给模型，或者将业务数据转换成相应的方式传递给视图，如图3所示
.NET MVC框架所具有的特性包括以下几点：
- NET MVC框架深度整合许多用户熟悉的平台特性，如身份验证、安全性、缓存和配置特性等。
- 整个架构是基于标准组件的，所以开发人员可以根据自己的需要分解或替换每个组件。
- .NET MVC框架使用用户熟悉的ASPX和ASCX文件进行开发，然后在运行时生成HTML的方式。
- 在这个框架中，URL将不再映射到ASPX文件，而是映射到一些控制类。所谓控制类，是一些不包含UI组件的标准类。
- NET MVC框架实现了System.Web.IHttpRequest和IHttpResponse接口，这使得单元测试能力得到了增强。
- 在进行测试时，不必再通过Web请求，单元测试可以撇开控制器而直接进行。
- 可以在没有ASP.NET运行环境的机器上进行单元测试。
使用MVC设计模式的一个最大的好处就是它简化了WEB应用开发中的Test - Driven Development(以下简称TDD)测试驱动开发方法过程，因为它使我们避免了与复杂的图形用户界面（GUIs）交互。TDD需要开发者创建小粒度的单元测试用例，检测出执行失败的用例，编写代码以通过用例检测，最后要重构代码以应对需求变更。
其他的定制服务 下方联系卡片↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ 或者私信作者
