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

解

决

方

案

XXXX科技有限公司

XXXX年XX月

目录

第1章 关于本方案 4
第2章 概述 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.3 安全设计 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 安全需求
[这里描述系统的安全方面的需求。]
3.2.5 其它需求
3.2.5.1 对账单
3.3 需求分析
3.3.1 系统涉众分析
[这里描述和系统相关的用户，包括客户，最终用户细分，他们在系统中的职责，以及他们如何使用系统。简单的说，就是本系统的所有干系人及职责描述，相当于用例分析中的角色。]
3.3.2 功能需求分析
[这里描述系统的所有功能需求，可以使用用例图，如果功能需求比较多，可以采用用例包。最好在开始时，给出系统用例图。]
3.3.3 对技术架构的要求
[这里描述对架构设计有指导性的关键需求，会影响到后面的架构设计。]
第4章 总体设计
4.1 总体设计目标
[这里描述系统的总体设计目标。]
4.2 总体设计原则
[这里描述系统的总体设计原则。]
4.3 总体逻辑架构设计
[这里以逻辑结构图（一般分层组织）的方式，描述我们提供的整个软件生态系统，一般不涉及具体的技术。]

4.4 网络系统设计
[这里用网络拓扑图的形式描述网络方面的设计。]
4.5 硬件系统设计
[这里描述硬件方面的设计，一般包括：数据库服务器、备份服务器、Web服务器、应用服务器、存储设备、防火墙等。]

4.5.1 服务器
[这里描述硬件服务器的选型，依据内容多少，目录可自行添加。]
4.5.2 网络设备
[这里描述网络设备的选型，依据内容多少，目录可自行添加。]
4.5.3 存储系统
[这里描述存储设备的选型，依据内容多少，目录可自行添加。]
4.6 平台选择
[这里列出所有数据库，应用服务器，web服务器，操作系统等软件平台的选型，可以包含介绍和选择理由。]
4.7 标准规范设计（可选）
[在有些大型系统中，需要做开创性的规范方面的设计，用来指导后面系统的开发。一般就是数据方面的规范。这里可以分两个方面进行描述，一个是规范采用的技术，一般是xml；另一个就是规范初步设计。]
第5章 详细设计
5.1 技术架构设计
5.1.1 设计思路
[描述整个技术架构的设计思路，一般是介绍架构设计的历史，引导出本系统实际的符合先进行的架构思路。]

5.1.2 设计原则
[简要描述设计原则，一般都是都是固定的，可参考指南。]

5.1.3 架构决策
[列出所有架构决策的要点，并逐点解释其与架构需求的对应。]
5.1.4 技术架构
5.1.4.1 平台技术架构（可选）
[给出方案所选平台的技术架构，一般是采用厂商平台的技术架构，可以从厂商网站或ppt中拷贝。]
5.1.4.2 总体技术架构图
[在平台架构的基础上，给出具体针对本项目的技术架构。 ]
5.1.4.3 技术架构说明
[对上面的技术架构进行说明]
5.2 功能设计
[按子系统或模块进行组织，可以使用树形图表示。]
5.3 安全设计
[视客户具体要求，可独立章节，写方案时应考虑招标方的具体安全需求，并给出具体的建议措施。]