软件设计技术评价ppt课件

设计技术评价 集团财务管理系统研发中心 项目概况 项目最终目标使公司的产品从现在的企业级支持升级到集团级支持与其他项目的关系是FMIS2 0的升级产品宏观的目标期限2006 11 30 说明 实现财务数据大集中适应扁平化管理实现财务系统与业务系统的集成财务基础信息规范化先进性与实用性的统一加强财务分析与决策支持 详细内容 技术架构分析 浏览器 应用服务器 数据库服务器 B A S 客户端 应用服务器 数据库服务器 C A S B A S 本质上是一种以浏览器表现的客户机技术 B A S模式是一种以Web技术为基础平台模式 把传统C S模式中的服务器部分分解为一个数据服务器与一个或多个应用服务器 Web服务器 从而构成一个三层结构的客户服务器体系 第一层客户机是用户与整个系统的接口 客户的应用程序精简到一个通用的浏览器软件 如微软的IE等 浏览器将HTML代码转化成图文并茂的网页 网页还具备一定的交互功能 允许用户在网页提供的申请表上输入信息提交给后台 并提出处理请求 这个后台就是第二层的Web服务器 第二层Web服务器将启动相应的进程来响应这一请求 并动态生成一串HTML代码 其中嵌入处理的结果 返回给客户机的浏览器 如果客户机提交的请求包括数据的存取 Web服务器还需与数据库服务器协同完成这一处理工作 第三层数据库服务器的任务类似于C A S模式 负责协调不同的Web服务器发出的SQL请求 管理数据库 B A S 优点具有广泛的信息发布能力 客户端只需要普通的浏览器即可 特别适合简单的应用流程和Internet应用 由于其简单 轻量 易于维护 无须为每一个客户应用程序升级 而只需对Web服务器上的服务处理程序进行修订 缺点客户端只完成浏览 查询 数据输入等简单功能 而绝大部分工作 数据及界面 由服务器承担 因此应用服务器的负担重 对其性能的要求比较高 由于复杂的操作需要大量的与服务器的交互处理 客户端响应速度慢 不适合复杂的交互式应用 另外对复杂的交互程序实现工作量大 要求开发人员素质比较高 C A S 优点很好地支持交互式应用 客户端响应速度快 技术成熟 稳定 对复杂应用适应性好 能够给服务器减轻压力 而且有更高的安全性和稳定性 程序容易开发 有很多成熟的技术资源和人力资源可以利用 缺点用户界面风格不一 使用繁杂 培训工作量大 客户端需要安装专用的客户端软件 首先涉及到安装的工作量 其次任何一台电脑出问题 如病毒 硬件损坏 都需要进行安装或维护 系统软件升级时 每一台客户机需要重新安装 其维护和升级成本非常高 新技术不能轻易应用 因为一个软件平台及开发工具一旦选定 不可能轻易更改 技术架构建议一 建议根据子功能的要求选择合适的架构 将B A S与C A S混合使用 首先 根据一定的原则 将系统的所有子功能分类 决定哪些子功能适合采用C A S 哪些适合采用B A S 适合采用C A S的子功能应具备以下特点 安全性要求高 要求具有较强的交互性 使用范围小 地点固定 要求处理大量数据 例如 业务管理中的业务处理 财务系统中的凭证输入功能等等 而适合采用B A S的子功能应具备以下特点 使用范围广 地点灵活 功能变动频繁 安全性 交互性要求不同 例如 公司财务分析表的查询功能 决策支持系统中的查询功能等等 技术架构建议二 相对于单独采用C A S或B A S 这种方案的优点在于 充分利用公司的现有技术资源 提高系统开发的成功率 采用了一定的新的软件技术手段 使产品有一定的技术先进性 既保证了复杂功能的交互性 又保证了一般功能的易用与统一 利于在客户中推广使用 系统维护简便 布局合理 系统性能合理 技术架构建议三 实现的过程描述 在概要设计阶段 根据一定的选择原则 来决定各个子功能采用哪一种模式并在系统设计说明书上分别注明 在编码设计阶段 系统开发者需要针对采用不同模式的子功能 选用不同的编码方式 然后编译生成不同的客户应用及Web服务程序 在安装调试阶段 特定的客户应用程序将被安装在特定的使用者的客户端上 Web服务程序需要被安装在Web服务器上 而每个客户端上都将被安装上浏览器 同时 客户应用的使用者必须接受一定的培训 在软件维护阶段 针对不同模式的子功能应采取不同维护方式 BEA集成平台架构 应用架构 团体 资源 需求组 功能需求 数据转换需求 技术组架构 组件组 3人9人月 设计开发组 3 0开发与数据转换资源比为3 1 数据库人员 3人15人月 概要设计 6人其中界面设计2人12人月 详细设计 12人其中界面设计3人24人月 代码设计 16人其中界面设计3人48人月 质量测试组 6人30人月 实施组 日程 过程与方法 本项目的特殊之处使用的方法现实的目标精细的任务严格的标准周密的计划实时的监控及时的评估合理地调整 详细内容 当前状态 正处在需求分析阶段问题人力资源的配备问题项目知识背景的培训 风险说明 技术架构系统功能系统性能软件开发数据转换操作习惯 技术架构风险 问题根据现有用户的交互操作习惯 不同的技术架构对系统开发产生的工作量有着很大的差别 主要体现在用户交互的开发和熟悉平台技术人员的缺乏 措施以J2EE架构下WEB应用为主 对于用JAVA开发工作量大的交互操作以传统开发开发工具 delphi 开发独立功能控件来实现 对于一些难以实现的交互操作改变操作方式 系统功能风险 问题需求不能清晰地表达 容易产生歧义需求不能在开发的前期相对固定可以操作的需求不能在规定的时间产生需求需要考虑企业的不同管理层次的需要措施细化需求编写规范 需求中数据 操作 逻辑颗粒要细需求工作需要定期的评估 及时发现需求中的问题加强需求工作的人力资源的投入 保持一定的资源持续的时间的工作 系统性能风险 问题全省大集中数据量大 并发性高存在先开发 后优化的认识误区存在怕麻烦的认识误区措施对于门户性能和数据库性能成立专题论证将性能问题贯穿与设计的全过程 软件开发风险 问题技术人员投入到项目的角色需要一个时间和技能过程技术人员执行规范的检查 考核不到位参与开发的技术人员经常变动人力资源的缺少和专业技能的缺乏设计与需求 代码不匹配 走形式主义管理 监控 评估严重不到位措施尽快落实人力资源计划对于项目参与人员根据其角色进行技能培训和管理规范培训加强对设计工作的认识和管理配备专门的管理 监控 评估的人员 数据转换风险 问题对数据转换的工作量估计不足对数据转换的难度估计不足数据转换的工作的开展时间较迟措施数据转换的设计应从需求开始数据转换的应配备一定的资源数据转换的测试应在FMIS3 0整体测试之前 操作习惯风险 问