软件项目解决方案模板
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
解
决
方
案
XXXX科技有限公司
XXXX年XX月
目录
第1章关于本方案 (4)
2.1 项目背景 (4)
2.2 建设目标 (4)
2.3 建设原则 (4)
第3章需求描述及分析 (4)
3.1 概述 (4)
3.1.1 需求分析目标和任务(可选) (4)
3.1.2 需求分析组织方式 (4)
3.2 需求描述 (5)
3.2.1 业务需求 (5)
3.2.2 接口需求 (5)
3.2.3 性能需求 (5)
3.2.4 安全需求 (5)
3.2.5 其它需求 (5)
3.3 需求分析 (5)
3.3.1 系统涉众分析 (5)
3.3.2 功能需求分析 (6)
3.3.3 对技术架构的要求 (6)
第4章总体设计 (6)
4.1 总体设计目标 (6)
4.2 总体设计原则 (6)
4.3 总体逻辑架构设计 (6)
4.4 网络系统设计 (6)
4.5 硬件系统设计 (6)
4.5.1 服务器 (7)
4.5.2 网络设备 (7)
4.5.3 存储系统 (7)
4.6 平台选择 (7)
4.7 标准规范设计(可选) (7)
第5章详细设计 (7)
5.1 技术架构设计 (7)
5.1.1 设计思路 (7)
5.1.2 设计原则 (7)
5.1.3 架构决策 (8)
5.1.4 技术架构 (8)
5.2 功能设计 (8)
5.4 用户界面设计(可选) (8)
5.4.1 界面设计原则 (9)
5.4.2 易用性设计 (9)
5.4.3 界面原型设计 (9)
第6章项目实施方案 (9)
6.1 项目实施策略与运行管理机制 (9)
6.1.1 项目实施策略 (9)
6.1.2 项目运行管理机制 (9)
6.2 项目实施和管理 (9)
6.2.1 项目组织结构 (9)
6.2.2 项目管理 (9)
6.2.3 项目计划 (9)
6.2.4 项目组人员配置 (9)
6.2.5 项目测试方案 (10)
6.2.6 软件开发过程(可选) (10)
第7章技术支持和服务 (10)
第8章项目预算 (10)
第9章公司简介 (10)
第10章附录一 XXX平台简介 (11)
第11章附录二 XXX技术,标准及规范简介 (11)
第1章关于本方案
本文档的详细描述了修车养车网支付系统项目的每个功能的设计方案。例如功能的需求来源,与各功能模块之间的关系,功能操作流程示例,序列图,程序设计,外部接口,数据库设计等。开发人员可通过阅读该文档快速的了解每一个功能的业务逻辑,便于日后在对系统进行修改时确认修改内容是否正确。
同时本文档也是与终端用户(在本项目中大多数情况是技术支持人员)进行系统功能确认,业务流程确定的唯一文档。
第2章概述
2.1项目背景
由于公司多个系统都用到了支付模块,而且功能等方面都一致。
2.2建设目标
把支付模块单独整理出来,然而实现统一管理、维护方便、并且方便以后新系统的开发。
2.3建设原则
保证支付的安全性,一致性,不影响原系统的支付,在原有系统上以最小的改动方面来实现这个支付的分离。
第3章需求描述及分析
3.1概述
3.1.1需求分析
➢原各系统的支付
➢问题分析
从上图可以看出我们这个养车修车网有好修养、好淘气、等多个项目。然而他们都需要用到支付宝、微信、银联这三个第三方支付。那么既然都是同一个平台的系统,每个系统支付都重新写,或者以后又有新项目支付又要写支付。
得出以下结论:
1.代码重用性不高
2.维护不方便
3.2需求描述
3.2.1业务需求
➢解决问题
为了解决上面存在的问题,将原来各系统的支付独立分离出来整合成一个支付系统。现在就是由各个系统去和这个独立出来的支付系统交互,然后在由支付系统再去调用第三方支付(微信、银联、支付宝)进行交互。这样即使有新的系统需要用到支付也不要重新写支付的功能,然后也也方便以后的管理维护。
3.2.2接口需求
3.2.2.1支付
各个系统调用支付系统,然后我们在根据出传入的支付途径的调用对应的第三方支付进行支付(WEB)或者返回相应的属性(APP),并且返回成功或失败。
3.2.2.2退款
各个系统调用支付系统,然后我们在根据出传入的支付途径的调用对应的第三方支付进行退款,并且返回成功或失败。
3.2.2.3支付回调
第三方通知我们的支付系统的回调地址,然后我们验证签名和参数解析,如果支付成功就修改付款单支付状态为已支付,然后根据在通知付款单的系统ID将结果通知对应的系统,如果通知失败就隔1秒在失败就隔2秒依次加时间请求,超过20次就添加到系统日志里面。
3.2.2.4退款回调
第三方通知我们的支付系统的回调地址,然后我们验证签名和参数解析,如果支付成功就修改付款单支付状态为已支付,然后根据在通知付款单的系统ID将结果通知对应的系统,如果通知失败就隔1秒在失败就隔2秒依次加时间请求,超过20次就添加到系统日志里面。
3.2.3性能需求
[这里描述系统的性能需求。]
3.2.4安全需求
[这里描述系统的安全方面的需求。]