1.1 开发背景
《itbt4.0》主要功能是,为广大用户提供一个线上投融资平台；随着互联网技术的快速发展和普及，p2p小额借贷逐渐由单一的线下模式，转变为线下线上并行，随之产生的就是P2P网贷平台。这使更多人群享受到了p2p小额信贷服务。p2p网络借贷平台发展的另一个重要目的，就是通过这种借贷方式来缓解人们因为在不同年龄时收入不均匀而导致的消费力不平衡问题。
在推广策划作用下网站知名度越来越高被大多数投友所孰知的情况下，投资者对网站用户体验要求越来越高，最主要是用户和数据积累导致网站负载国过高！大大的降低投友在网站用户体验度,同时直接的影响了公司利益！为解决这一重大难题!改变当下这种现状特开发出p2p平台《itbt4.0》!
1.2 开发目标
前台：
后台：
1.3 参考资料
【discuz】
【大型网站技术架构：核心原理与案例分析】作者：李智慧
【UML统一建模基础教程】作者：刘小松
1.4 设计原则
【设计该系统遵守的原则：性能、可用性、扩展性、伸缩性、安全性】
1.****5****架构模式
2 需求分析
系统按功能模块进行划分可分为三大模块：网站前台交易平台，用户个人账户中心，业务后台支撑系统。根据分析可以得到图所示的分析用例图
根据上图所示A区域即为网站前台交易平台，主要包括的操作有网站新闻及服务信息查看，会员注册，借款浏览等。B区域即为用户个人账户中心，包括各种会员认证，VIP申请，资料上传，额度申请，借款的发布及查看，投资管理，偿还借款，充值，提现等功能。C区域即为业务后台支撑系统，包括贷款管理，资金管理，资金记录，会员管理，报表分析，奖励与费用，系统维护等功能。
2.1 需求陈述
【用平常语言描述该系统的全部功能和细节】
功能性需求
外部接口需求
短信接口、第三方充值接口、网贷数据统计分析接口（数金网、网贷点评网、零壹财经）、实名认证
3.1. 用户界面
描述系统的操作界面要求。
3.2. 软件接口
此节说明软件系统中与其他构件之间的软件接口。这些构件可以是购入的构件、取自其他应用程序重新利用的构件，是应用程序必须与之交互的构件。
3.3. 通信接口
说明与其他系统或设备（如局域网、远程串行设备等）的所有通信接口。
- 非功能性需求
4.1. 错误及异常事件
从用户视角定义系统安装、运行过程中可能遇到的错误、异常事件的分类、描述、处理方法。如果事件列表较长或较复杂，可另用文档或附页来描述。
4.2. 系统性能需求
(1) 数据精度
(2) 时间特性
描述对本软件的时间特性要求，包括：响应时间、处理时间、数据转换时间、数据传输时间、系统初始化时间、批处理时间。
(3) 灵活性
描述当需求发生某些变化时，本软件产品对这些变化的适应能力，包括：操作方式的变化、运行环境的变化、同其他应用系统的接口的变化、精度的变化、计划的变化。
4.3. 系统安全性需求
指明本软件应具有的安全及保密功能，包括防止非授权用户登录等。如果需要特别指定的加密或者安全结构也在此指明。
4.4. 可靠性需求
列明系统要求的具体指标，根据具体项目或者产品的要求决定。
4.5. 可用性需求
系统可用性要求，如系统能支持的同时使用用户数等。
4.6. 升级与兼容性需求
指明与其它版本或相关产品的兼容性；指明旧版本升级的方式和要求、相关配置文件更新、兼容的情况。
4.7. 数据存储需求
2.2 操作用例
【描述具体的操作例子，比如登录后进行何种操作】
2.3 功能分析划分
【分析功能并划分功能块】
系统按功能模块进行划分可分为三大模块：网站前台交易平台，用户个人账户中心，业务后台支撑系统。对这三大模块进行功能的细分：
2.3.1 网站前台交易平台
可以细分为四个模块，分别是贷款标浏览，贷款标详情，会员注册和网站信息查阅。具体功能模块图如图所示：
2.3.1 用户个人账户中心：
可以细分为五个功能模块，分别为基本设置，资金管理，借款管理，投资管理和好友管理。具体功能模块图如图所示：
2.3.1 业务后台支撑系统：
可以细分为七个功能模块，分别是贷款管理，资金管理，资金记录，会员管理，报表分析，奖励与费用和系统维护。具体功能模块图如图所示：
3 总体设计
3.1 系统建模
3.1.1 层次方框图
【从顶部开始，按照层次分类进行细化】
3.1.2 ER图（实体-联系图）
【分析各个对象之间的联系，画图ER图】
接口设计
3.1.3 类图设计
【使用UML画出各个类的属性、继承和方法】
3.2 接口设计
【各个子系统之间的接口和用户接口】
3.2.1 内部接口设计
【各个部件是通过何种方式进行连接，比如通过远程数据库，http等】
3.2.2 登录界面设计
3.2.3 用户管理界面设计
详情：
svn://192.168.0.175/itbt_project/Document/ITBT-PC/开发/开发接口文档.doc
3.3 数据库结构设计
【主要是描述】
3.3.1 数据库E-R图
1、权限管理
以下是本系统的垂直权限管理模块的物理模型设计：
管理员与角色之间是多对多的关系，这样可以实现为一个管理员分配多个角色进行管理，而角色与权限之间也是多对多的关系，权限是根据功能模块进行划分的，使得角色可以进行细粒度的权限分配。
2、借款投标
主要实体为借款，投标记录，应收明细，还款明细，奖励记录，回款记录，续投奖励记录等。
会员发起借款，提交确认借款信息后，借款信息将被存储在“借款”表中，系统管理员通过网站后台对借款进行发标初审和设定借款发布时间，审核结果存储在“借款”表的“状态”字段中，借款发布时间存储在“借款”表的“计划发布时间”字段中，待发标初审通过并到达发布时间，借款将自动发布，“借款”表的“状态”字段自动更新为“发布中”。
投资人浏览借款信息，投资符合条件的借款标，投资记录将被存储在“投标记录”表中，相应的在“借款”表中更新相应的“已投总额”，待“已投总额”= = “借款总额”，该借款将自动提交，系统管理员进行满标复审。复审通过后，将会计算相应的还款明细，收款明细，奖励（投标奖励），费用（网站风险补偿金）和续投奖励等分别存储在表“还款明细”，“应收明细”，“奖励记录”，“手续费(风险费)”和“续投奖励记录”中。整个借款投标过程中涉及到的资金明细记录都存储在“资金记录”表中。满标复审通过后，进入还款阶段，还款的物理模型分析将在后面具体展开。
3、还款
“借款”表中的“还款方式”字段存储了借款人提交借款信息时选择的还款方式，借款依照“还款方式”按期进行还款，到期正常还款或提前还款后，系统将更新“应收明细”和“还款明细”表中的“状态”为“已还”。系统相应的收取会员的利息管理费存储于“手续费”表中。若会员逾期未还，则系统会按相应的规则自动计算逾期罚款，存储于“逾期罚款”表中。
3.3.2 数据库逻辑设计
2.5 出错处理
【描述如果出错的处理方法】
分析错误原因，这次程序上线所涉及逻辑是否有问题，对应数据表操作是否有问题，过代码，查程序日志，查错误日志。
2.6 安全保密设计
【描述采用何种方法保证安全性】
采用HTTPS和防火墙技术，增强网上传输中的信息保密性；利用数据库系统本身的数据管理功能，通过对每个数据库基表进行各用户的"读写授权定义"，保证数据库基表级的安全保密性；系统通过建立"网络-用户／指标代码关系矩阵"对数据库中每个数据记录（即：每个指标代码对应的数据记录）的读写权限进行集中统一的严格管理，由应用软件内部的逻辑判别，保证数据库基表内记录级安全保密性和字段级设计系统的运行维护管理模块，进行系统数据库的备份与恢复，使系统数据库不会因意外事故（如突然停电）而造成破坏，从而确保数据库内容的安全可靠性；通过对数据库的存放设计，使数据库各基表的生成源与修改源统一规划，确保数据的一致性。
4 详细设计
4.1 程序流程图
【具体来说就是把经过总体设计得到的各个模块详细的加以描述。】
4.1.1贷款流程
用户注册并通过短信验证码验证成功后成为本系统的会员，有相应的会员中心。会员登录中心后首先需要填写基本资料，有个人资料，联系资料，单位资料，财务资料，房产资料，联保资料等。成功填写完资料后需要经过一系列的认证，包括邮箱认证，手机认证，实名认证，现场认证，视频认证，资料认证等。待管理员审核成功后可以申请VIP会员，管理员审核成功后用户即可进行正常贷款。
会员首先选择自己需要发起的标种，分别有企业标，创业标，股东标，信用标，秒还标，净值标。
选择标种后填写相应的贷款信息，核查无误后贷款提交，管理员进行发标审核，审核通过后，就进行资金的募集，在规定时间内成功募集到资金，则自动提交管理员进行满标复审，复审通过后则进入还款阶段，按照提交贷款所选择的还款方式进行还款，若出现逾期，则按相应的规则进行处罚。若未成功募集满资金，则本次借款自动流标。整个流程图如图所示：
4.1.2投标流程
用户注册并通过短信验证码验证成功后成为本系统的会员，进行身份验证，验证审核通过后进行账户的充值，充值成功后对正在筹资的标进行投资，满标通过后即投标成功，收取相应的本金和利息，之后可以选择继续投资其他标或进行提现。整个流程图如图所示：
4.2 伪代码编写
【使用中文或者英文进行伪代码编写，以后这些伪代码将会成为代码的注释】
5 实现
5.1 编码
5.1.1 代码约定
svn://192.168.0.175/itbt_project/Document/ITBT-PC/开发/ PHP开发规范 2.doc
svn://192.168.0.175/itbt_project/Document/ITBT-PC/开发/ java编码规范 .doc
5.1.2 代码编写原则
并非讨论类似哪个语言效率最高等无聊的编程语言之争，也不像《effective c》等讲述某个语言的优化问题，本文只是讨论编程习惯对程序性能的影响。
如果你是一个农夫，那么给你倚天剑你也只会用来锄地，而且会抱怨效果还没锄头好，如果你是一个高手，即使是摘叶飞花，也可伤敌。所以说什么语言不重要，关键还是看人。
这里先介绍一个心得，叫做低代价优先返回原则。
低代价优先返回原则
对于一段代码，应该优先处理低代价的逻辑，低代价的逻辑包括：
1.纯CPU计算，不需要访问网络、io、数据库的逻辑。
纯CPU计算部分是最快的，应该最优先判断，不通过就直接返回，不再计算后面的网络、io、数据库逻辑。如果纯CPU计算部分的判断不通过，则后续需要用到网络、io、数据库的逻辑部分就可以免除了，这样可以大大减少各种io等待。
2.失败几率最高的逻辑。
假如一段代码中，有A->B->C->D->OK, 四个判断阶段，其中D阶段的淘汰率最高,C次之，A、B再次之，那么处理顺序应该改为D->C->A->B->OK,这样在第一个判断阶段就过滤了大量的数据流入第二阶段，减少了非常多无谓的A、B阶段的处理。
这里举一个例子：
估计很多人都很乐意写这样的代码，感觉上就是逻辑清晰，计算数据，筛选数据，两个步骤很明晰。特别是在某些框架中，提供的接口还强制约束着必须这样按部就班地实现。
这个程序在执行某一个大数据量的数据逻辑处理，需要花费3天时间
将代码改为：5.2 测试要点
5.2.1 功能测试
1、链接测试
2、表单测试
3、Cookies测试：Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies形式存储在客户端计算机上，可用来创建动态和自定义页面或存储登陆等信息。如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作而且对这些信息已经加密。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
4、设计语言测试：Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
5、数据库测试：在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
6、搜索测试
7、输入域测试
8、分页测试
9、UI测试
5.2.****2****业务流程测试****要点
页面加载时间不超过2s
竞标大厅：投标效率、服务端交互频率与用户体验平衡、收益计算、标排序、数据完整性（剪切保留两位小数、高并发情况下）、浏览器兼容
5.2.****3、安全性测试****要点
（1）SQL注入（比如登陆页面）
（2）XSS跨网站脚本攻击：程序或数据库没有对一些特殊字符进行过滤或处理，导致用户所输入的一些破坏性的脚本语句能够直接写进数据库中，浏览器会直接执行这些脚本语句，破坏网站的正常显示，或网站用户的信息被盗,构造脚本语句时，要保证脚本的完整性。
document.write("abc")
（3）URL地址后面随便输入一些符号，并尽量是动态参数靠后
（4）验证码更新问题
（5）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（6）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（7）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（8）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（9）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
5.2.****4、性能测试****要点
1连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
3压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
5.3 测试结果和总结
6 维护
6.1 维护方法
1)SQL注入。检测Web网站是否存在SQL注入漏洞，如果存在该漏洞，攻击者通过SQL注入攻击可轻易获得网站的后台管理权限，甚至网站服务器的管理权限。
2)XSS跨站。检测Web网站是否存在XSS跨站脚本漏洞，如果存在该漏洞，攻击者可进行Cookie欺骗、网页挂马等攻击。
3)网页挂马。检测Web网站是否被黑客或恶意攻击者非法植入了木马程序。
4)上传漏洞。检测Web网站的上传功能是否存在上传漏洞，如果存在此漏洞，攻击者可直接利用该漏洞上传木马获得Webshell。
5)源代码泄露。检测Web网络是否存在源代码泄露漏洞，如果存在此漏洞，攻击者可直接下载网站的源代码。
6)隐藏目录泄露。检测Web网站的某些隐藏目录是否存在泄露漏洞，如果存在此漏洞，攻击者可了解网站的全部结构。
7)数据库泄露。检测Web网站是否在数据库泄露的漏洞，如果存在此漏洞，攻击者通过暴库等方式，可以非法下载网站数据库。
8)管理地址泄露。检测Web网站是否存在管理地址泄露功能，如果存在此漏洞，攻击者可轻易获得网站的后台管理地址。
9)弱口令。检测Web网站的后台管理用户，以及前台用户，是否存在使用弱口令的情况。
10)网站绝对路径泄露。通过该漏洞，攻击者可以知道网站在服务器上的物理位置，如“E:\web\www\”。
6.2 维护文档
svn://192.168.0.175/itbt_project/Document/ITBT-PC/开发/itbt系统维护手册.doc
svn://192.168.0.175/itbt_project/Document/ITBT-PC/开发/日常工作文档.docx
6.3 功能拓展方法