软件项目解决方案模板 (2).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 1 章章 关于本方案关于本方案 本文档的详细描述了修车养车网支付系统项目修车养车网支付系统项目的每个功能的设计方案。例如功能的需求来源， 与各功能模块之间的关系，功能操作流程示例，序列图，程序设计，外部接口，数据库设计等。 开发人员可通过阅读该文档快速的了解每一个功能的业务逻辑，便于日后在对系统进行修改时确 认修改内容是否正确。 同时本文档也是与终端用户(在本项目中大多数情况是技术支持人员)进行系统功能确认，业务 流程确定的唯一文档。 第第 2 2 章章 概述概述 2.12.1项目背景项目背景 由于公司多个系统都用到了支付模块，而且功能等方面都一致。 2.22.2建设目标建设目标 把支付模块单独整理出来，然而实现统一管理、维护方便、并且方便以后新系统 的开发。 2.32.3建设原则建设原则 保证支付的安全性，一致性，不影响原系统的支付，在原有系统上以最小的改动 方面来实现这个支付的分离。 第第 3 3 章章 需求描述及分析需求描述及分析 3.13.1概述概述 3.1.13.1.1 需求分析需求分析 原各系统的支付 . ;. 问题分析 从上图可以看出我们这个养车修车网有好修养、好淘气、等多个项目。然而他们 都需要用到支付宝、微信、银联这三个第三方支付。那么既然都是同一个平台的系统， 每个系统支付都重新写，或者以后又有新项目支付又要写支付。 得出以下结论：得出以下结论： 1. 代码重用性不高 2. 维护不方便 . ;. 3.23.2需求描述需求描述 3.2.13.2.1 业务需求业务需求 解决问题 为了解决上面存在的问题，将原来各系统的支付独立分离出来整合成一个支付系 统。现在就是由各个系统去和这个独立出来的支付系统交互，然后在由支付系统再去 调用第三方支付(微信、银联、支付宝)进行交互。这样即使有新的系统需要用到支付 也不要重新写支付的功能，然后也也方便以后的管理维护。 3.2.23.2.2 接口需求接口需求 3.2.2.13.2.2.1支付支付 各个系统调用支付系统，然后我们在根据出传入的支付途径的调用对应的第三方支付进行支付 （WEB）或者返回相应的属性（APP）,并且返回成功或失败。 3.2.2.23.2.2.2退款退款 各个系统调用支付系统，然后我们在根据出传入的支付途径的调用对应的第三方支付进行退款,并 且返回成功或失败。 . ;. 3.2.2.33.2.2.3支付回调支付回调 第三方通知我们的支付系统的回调地址，然后我们验证签名和参数解析，如果支付成功就修改付 款单支付状态为已支付，然后根据在通知付款单的系统 ID 将结果通知对应的系统，如果通知失败就隔 1 秒在失败就隔 2 秒依次加时间请求，超过 20 次就添加到系统日志里面。 3.2.2.43.2.2.4退款回调退款回调 第三方通知我们的支付系统的回调地址，然后我们验证签名和参数解析，如果支付成功就修改付 款单支付状态为已支付，然后根据在通知付款单的系统 ID 将结果通知对应的系统，如果通知失败就隔 1 秒在失败就隔 2 秒依次加时间请求，超过 20 次就添加到系统日志里面。 3.2.33.2.3 性能需求性能需求 这里描述系统的性能需求。 3.2.43.2.4 安全需求安全需求 这里描述系统的安全方面的需求。 3.2.53.2.5 其它需求其它需求 3.2.5.13.2.5.1对账单对账单 3.33.3需求分析需求分析 3.3.13.3.1 系统涉众分析系统涉众分析 这里描述和系统相关的用户，包括客户，最终用户细分，他们在系统中的职责， 以及他们如何使用系统。简单的说，就是本系统的所有干系人及职责描述，相当于用 例分析中的角色。 3.3.23.3.2 功能需求分析功能需求分析 这里描述系统的所有功能需求，可以使用用例图，如果功能需求比较多，可以 采用用例包。最好在开始时，给出系统用例图。 . ;. 3.3.33.3.3 对技术架构的要求对技术架构的要求 这里描述对架构设计有指导性的关键需求，会影响到后面的架构设计。 第第 4 4 章章 总体设计总体设计 4.14.1总体设计目标总体设计目标 这里描述系统的总体设计目标。 4.24.2总体设计原则总体设计原则 这里描述系统的总体设计原则。 4.34.3总体逻辑架构设计总体逻辑架构设计 这里以逻辑结构图（一般分层组织）的方式，描述我们提供的整个软件生态系 统，一般不涉及具体的技术。 4.44.4网络系统设计网络系统设计 这里用网络拓扑图的形式描述网络方面的设计。 4.54.5硬件系统设计硬件系统设计 这里描述硬件方面的设计，一般包括：数据库服务器、备份服务器、Web 服务器、 应用服务器、存储设备、防火墙等。 4.5.14.5.1 服务器服务器 这里描述硬件服务器的选型，依据内容多少，目录可自行添加。 . ;. 4.5.24.5.2 网络设备网络设备 这里描述网络设备的选型，依据内容多少，目录可自行添加。 4.5.34.5.3 存储系统存储系统 这里描述存储设备的选型，依据内容多少，目录可自行添加。 4.64.6平台选择平台选择 这里列出所有数据库，应用服务器，web 服务器，操作系统等软件平台的选型， 可以包含介绍和选择理由。 4.74.7标准规范设计标准规范设计（可选）（可选） 在有些大型系统中，需要做开创性的规范方面的设计，用来指导后面系统的开 发。一般就是数据方面的规范。这里可以分两个方面进行描述，一个是规范采用的技 术，一般是 xml；另一个就是规范初步设计。 第第 5 5 章章 详细设计详细设计 5.15.1技术架构设计技术架构设计 5.1.15.1.1 设计思路设计思路 描述整个技术架构的设计思路，一般是介绍架构设计的历史，引导出本系统实 际的符合先进行的架构思路。 5.1.25.1.2 设计原则设计原则 简要描述设计原则，一般都是都是固定的，可参考指南。 5.1.35.1.3 架构决策架构决策 列出所有架构决策的要点，并逐点解释其与架构需求的对应。 . ;. 5.1.45.1.4 技术架构技术架构 5.1.4.15.1.4.1平台技术架构（可选）平台技术架构（可选） 给出方案所选平台的技术架构，一般是采用厂商平台的技术架构，可以从厂商 网站或 ppt 中拷贝。 5.1.