软件项目解决方案模板.docxVIP

下载本文档

3
0
约3.26千字
约 10页
2021-12-09 发布于辽宁
举报
版权申诉

软件项目解决方案模板.docx

1、原创力文档（book118）网站文档一经付费（服务费），不意味着购买了该文档的版权，仅供个人/单位学习、研究之用，不得用于商业用途，未经授权，严禁复制、发行、汇编、翻译或者网络传播等，侵权必究。。
2、本站所有内容均由合作方或网友上传，本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺！文档内容仅供研究参考，付费前请自行鉴别。如您付费，意味着您自己接受本站规则且自行承担风险，本站不退款、不进行额外附加服务；查看《如何避免下载的几个坑》。如果您已付费下载过本站文档，您可以点击这里二次下载。
3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等，请点击“版权申诉”（推荐），也可以打举报电话：400-050-0827(电话支持时间：9:00-18:30)。
4、该文档为VIP文档，如果想要下载，成为VIP会员后，下载免费。
5、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。
6、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
7、VIP文档为合作方或网友上传，每下载1次，网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档

解决方案 XXXX 科技有限公司 XXXX 年 XX 月目录 TOC \o 1-5 \h \z 第 1 章关于本方案 4 第 2 章概述 4 项目背景 4 建设目标 4 建设原则 4 第 3 章需求描述及分析 4 概述 4 需求分析目标和任务（可选） 4 需求分析组织方式错误！未定义书签。需求描述 6 业务需求 6 接口需求 6 性能需求 7 安全需求 7 其它需求 7 3.3 需求分析 7 系统涉众分析 7 功能需求分析 7 对技术架构的要求 8 第 4 章总体设计 8 总体设计目标 8 总体设计原则 8 总体逻辑架构设计 8 网络系统设计 8 硬件系统设计 8 服务器 8 网络设备 9 存储系统 9 平台选择 9 标准规范设计（可选） 9 第 5 章详细设计 9 技术架构设计 9 设计思路 9 设计原则 9 架构决策 9 技术架构 10 功能设计 10 安全设计 10 用户界面设计（可选）错误！未定义书签。界面设计原则错误！未定义书签。易用性设计错误！未定义书签。界面原型设计错误！未定义书签。第 6 章项目实施方案错误！未定义书签。项目实施策略与运行管理机制错误！未定义书签。项目实施策略错误！未定义书签。项目运行管理机制错误！未定义书签项目实施和管理错误！未定义书签项目组织结构错误！未定义书签项目管理错误！未定义书签项目计划错误！未定义书签项目组人员配置错误！未定义书签项目测试方案错误！未定义书签软件开发过程（可选）错误！未定义书签第 7 章技术支持和服务错误！未定义书签第 8 章项目预算错误！未定义书签第 9 章公司简介错误！未定义书签第 10 章附录一 XXX 平台简介错误！未定义书签第 11 章附录二 XXX 技术，标准及规范简介错误！未定义书签第1章关于本方案本文档的详细描述了修车养车网支付系统项目的每个功能的设计方案。例如功能的需求来源，与各功能模块之间的关系，功能操作流程示例，序列图，程序设计，外部接口，数据库设计等。开发人员可通过阅读该文档快速的了解每一个功能的业务逻辑，便于日后在对系统进行修改时确认修改内容是否正确。同时本文档也是与终端用户（在本项目中大多数情况是技术支持人员）进行系统功能确认，业务流程确定的唯一文档。第2章概述项目背景由于公司多个系统都用到了支付模块，而且功能等方面都一致。建设目标把支付模块单独整理出来，然而实现统一管理、维护方便、并且方便以后新系统的开发。建设原则保证支付的安全性，一致性，不影响原系统的支付，在原有系统上以最小的改动方面来实现这个支付的分离。第3章需求描述及分析概述需求分析原各系统的支付支付宝支付宝微信支忖宝-银联」微信厂支忖宝0-银联L 微信支忖宝 -银联」微信厂支忖宝 0 -银联 L银联 -微信问题分析从上图可以看出我们这个养车修车网有好修养、好淘气、等多个项目。然而他们都需要用到支付宝、微信、银联这三个第三方支付。那么既然都是同一个平台的系统, 每个系统支付都重新写，或者以后又有新项目支付又要写支付。得出以下结论：代码重用性不高维护不方便 3.2需求描述 321 业务需求好洵气项目N+ 好洵气项目N+ 解决问题为了解决上面存在的问题，将原来各系统的支付独立分离出来整合成一个支付系统。现在就是由各个系统去和这个独立出来的支付系统交互，然后在由支付系统再去调用第三方支付（微信、银联、支付宝）进行交互。这样即使有新的系统需要用到支付也不要重新写支付的功能，然后也也方便以后的管理维护。接口需求支付各个系统调用支付系统，然后我们在根据岀传入的支付途径的调用对应的第三方支付进行支付（WEB ）或者返回相应的属性（ APP ），并且返回成功或失败。退款各个系统调用支付系统，然后我们在根据岀传入的支付途径的调用对应的第三方支付进行退款且返回成功或失败。支付回调第三方通知我们的支付系统的回调地址，然后我们验证签名和参数解析，如果支付成功就修改付款单支付状态为已支付，然后根据在通知付款单的系统 ID 将结果通知对应的系统，如果通知失败就隔 1 秒在失败就隔 2 秒依次加时间请求，超过 20 次就添加到系统日志里面。退款回调第三方通知我们的支付系统的回调地址，然后我们验证签名和参数解析，