12.1 计 划 阶 段

该阶段的主要内容为可行性分析报告、项目开发计划和风险列表。

12.1.1 可行性分析报告

12．1．1．1 引言

1）编写目的

（1）通过对校园二手货品交易市场项目进行调研，初步拟定系统的可行性报告，对软件开发过程中面临的问题以及相对应的解决方法进行审核和合理的安排。通过对软件开发可能会带来的经济效益及风险的了解，明确本次系统的目标。

（2）将项目开发过程中涉及的人员、经费、系统资源等问题的安排用文档形式记录，从而方便软件开发人员和相关人员对本项目展开相应的检查工作。

（3）本报告经检审之后，将交由负责人审查。

2）背景

软件系统的名称：学校二手货交易市场。

项目任务提出者：曹健。

项目开发者：雷同学、徐同学、田同学、姚同学、苏同学。

项目面向用户：在校学生、老师等相关人员。

该软件系统同其他系统或其他机构的基本相互关系：系统相对独立，开发中可能会使用第三方软件服务或者其他框架。

3）定义

详见项目词汇表。

4）参考资料

（1）《可行性分析报告》（GB8567—88）。

（2）《面向对象软件工程——使用UML、模式与Java》（第3版），清华大学出版社，2011。

12．1．1．2 可行性研究的前提

12．1．1．2．1 要求

1）功能

本系统提供的功能包括：用户注册登录、商品信息检索、商品信息分类、商品信息发布、用户通信、系统管理等。用户登录后可以管理个人信息，查看自己已收藏或已发布的商品和订单；当用户要卖掉自己的二手商品时，可以发布商品和修改自己发布的商品的相关信息；当用户对某件商品感兴趣时，在进入该件商品的详情页后，用户可以收藏商品、联系卖家、购买商品、确认交易或取消交易，用户填写订单时需要提供姓名、联系方式、交易时间、交易地点，确认商品数量和价格等信息，该系统暂时不支持网上支付，只能通过卖家和买家确认交易时间和交易地点后线下交易，交易完成后由买家确认交易；用户可以浏览商品（全部浏览或分类浏览）、查看商品详情和搜索商品；当买方用户在交易结束后未确认交易，卖方用户可以联系管理员寻求帮助。

2）性能

（1）系统处理能力。本系统应支持最大并发用户500个，每秒事务处理数应大于1000笔。

（2）时间要求。在硬件和网络条件满足的前提下，所有日常性操作事务的平均响应时间应小于0．5s，最长响应时间应小于2s；对于查询性事务的平均响应时间应小于0．5s，最长响应时间应小于2s。

3）输入数据

（1）用户信息。

来源：用户注册；

类型：复杂数据类型；

数量：＜10000，＞5000；

组成：用户编号（integer），用户姓名（string），联系方式（string），邮箱（string）。

（2）商品信息。

来源：卖家用户发布；

类型、数量：同上；

组成：商品编号（integer），商品名称（string），商品类别（integer），商品描述（string），商品图片地址（string）。

（3）订单。

来源：卖家用户发布；

类型、数量：同上；

组成：订单编号（integer），价格（float），交易地点（string），交易时间（time）；

提供频度：视情况而定，波动较大。

（4）消息记录。

来源：卖家和买家用户；

类型、数量：同上；

组成：消息编号（integer），消息内容（string），时间（time），作者（用户编号）；

提供频度：高。

4）输出数据

（1）商品。

含义：二手商品交易的主要对象；

产生频度：较高；

接口：暂无。

（2）订单。

含义：二手交易系统买家用户的购物清单；

产生频度：视使用程度和使用时间而定，如毕业生毕业或开学期间订单数增多；

接口：暂无。

（3）消息。

含义：二手商品交易系统的交流媒介；

产生频度：视使用程度和使用时间而定，如毕业生毕业或开学期间订单数增多；

接口：暂无；

分发对象：尚未确定。

5）在安全与保密方面的要求

（1）用户只能访问用户表中属于自己的用户信息。

（2）用户密码加密方式待进一步讨论。

（3）付款方式的安全性需进一步讨论。

（4）同本系统相连接的其他系统（暂无）。

6）完成期限

截止时间：2016．5．28。

12．1．1．2．2 目标

目前，二手商品交易已经成为大学生生活中必不可少的一部分，虽然校内也有短暂举行的跳蚤市场，但是这种自发组织的二手交易往往面临着时间短、规模小的问题。因此，一个二手交易系统的出现非常必要。随着在校学生数量增多，大学生交易需求日益旺盛。一个专业并且标准的二手交易平台能够解决校园二手信息发布交流方式的弊端，让校园内二手商品信息得到有效整合，也有利于信息服务的改进。

12．1．1．2．3 条件、假定和限制

所建议系统的运行寿命的最小值：2年左右。

进行系统方案选择比较的时间；试用期一个月左右。

经费、投资方面的来源和限制：组内成员。

硬件环境：服务器，浏览器。

可利用的信息和资源：网络资源、图书资料。

系统投入使用的最晚时间：2016年6月。

12．1．1．2．4 进行可行性研究的方法

通过对本校的学生进行询问及问卷形式得到用户对修改系统的想法和建议。通过建模分析，确定本系统的功能需求、效用成本等可行性研究分析。

12．1．1．2．5 评价尺度

主要从以下方面对系统进行评价：

（1）评价本系统的总成本。

（2）开发时间。

（3）使用的方便性。

12．1．1．3 对现有系统的分析

当前的二手商品交易系统是人工组织的，即由商贩或者店家通过较低的价格收购旧书或者生活用品，自行整理分类后运至学校门口进行小范围短时间的销售，价格并不统一，时间也不固定，规模小，效率低。

1）处理流程和数据流程

商家每年通过从毕业生或者高年级生那收购二手货物后，进行分类处理，再运至地摊进行摆售，学生在空闲时间去进行货物挑选。

2）工作负荷

（1）货物收购：商贩通过各种手段收购二手商品，时间与地点都不固定。

（2）容易受到天气的干扰。

（3）分类处理过程麻烦。

3）费用开支

收购费用、存储费用、交通费用、人力开销。

4）人员

二手商品商贩。

5）设备

计算器、三轮车、电子秤等。

6）局限性

（1）时间不固定、容易受到天气的干扰。

（2）价格需要现场协商，商品信息需要顾客自己判断，交易地点不固定，顾客难以知晓。

（3）效率过低。

12．1．1．4 所建议的系统

12．1．1．4．1 对所建议系统的说明

在校园二手交易系统上，用户既可当买家，通过浏览或搜索相关商品购买自己喜欢的商品；又可当卖家，发布二手商品信息，处理掉自己已经不需要的二手物品。

12．1．1．4．2 处理流程和数据流程

买方和卖方的处理流程如图12-1所示。

（1）注册登录：买家和卖家需要先注册登录才能使用平台上的交易功能。

（2）填写商品发布信息：卖家选择发布信息，依次填写商品类别、商品名称、商品描述、商品数量、新旧程度描述、原价、现价、卖家联系方式等上货信息。

（3）查询商品信息：在App首页，买家可以选择商品类别，输入商品名称进行检索。

（4）获得卖家联系方式：有意向的买家通过商品信息获得卖家联系方式。

（5）联系卖家：根据商品信息留下的联系方式联系卖家。

（6）协商：卖家和买家协商商品价格，确定交易时间和交易地点后当面交易。

（7）拍下商品：买家拍下商品，商品相应信息显示已有一人拍下此商品。

（8）交易：买家和卖家在指定交易时间到达指定交易地点当面交易。

（9）修改商品信息：交易后，卖家修改商品数量，或者直接将商品下架。

（10）相互评论：买家对卖家进行评价和信用度评定。

系统处理流程如图12-2所示。

12．1．1．4．3 改进之处

将校园二手交易平台从线下转自线上，更加方便商品的查找和交易。

12．1．1．4．4 影响

1）对设备的影响

系统将安装在学校网络信息中心的服务器上。网络信息中心需要提供相应的系统安装和运行空间。

2）对软件的影响

暂无。

3）对用户单位机构的影响

用户群体为在校师生，一般情况下均能够正常使用该二手交易平台，不需要额外培训说明。

4）对系统运行过程的影响

（1）用户的操作规程。用户注册时需提供真实姓名和班级学号等个人信息，且不能恶意注册多个账户刷信誉，用户发布商品需符合相关法律法规。

（2）运行中心的操作规程。管理员需及时审核并处理申请发布的商品信息，以免降低用户参与度；中心数据库需对用户数据加密，保障用户信息安全。

（3）运行中心与用户之间的关系。用户发布商品需经过管理员审核，交易中出现问题可由中心工作人员协调。

（4）源数据的处理。用户端软件发出的请求，经过加密后传到后台服务器，运行中心解析请求，根据内容对后台数据库进行操作，对请求做出适当的回应。

（5）数据进入系统的过程。用户首先在软件界面进行操作，由客户端软件将用户的操作转为消息，加密后经由网络发给服务器，服务器端进行解密并对消息进行解析。

（6）对数据保存的要求，对数据存储、恢复的处理。数据应当安全、妥善地保存。安全即意味着需要适当的权限才能读写，建议在存储时硬件采用raid冗余的方法存储，便于恢复，同时数据至少应当有一个部分镜像备份，备份间隔建议不超过1天。

（7）输出报告的处理过程、存储媒体和调度方法。在运行过程中定期打印log，向维护人员报告系统运行状态。维护人员应当定期查看输出报告，及时发现问题。报告应当存储在数据保存硬件以外的硬件上，对所有维护人员开放权限。

（8）系统失效后的后果及恢复的处理方法。明显的后果是系统停止服务，用户暂时不能使用该系统；新的数据可能无法接收。系统失效后应当及时关闭服务器从客户端接收数据的接口，在设计软件时应当考虑到服务器失效后暂停工作。同时维护人员迅速排查问题，保存现场及各种数据。排除问题后根据备份数据进行恢复，保证数据至少为一天以内的状态。同时向用户说明错误发生的时间及后果，与之一同将系统失效的影响减到最小。

5）对开发的影响

用户需要进行意见反馈，提出改进意见或使用过程中产生的问题。

6）对经费开支的影响

系统依托学生团队进行开发，因此所需开发经费较少。系统开发费用：25000元。

对于维护费用，系统是要移交给网络信息中心，网络信息中心的工作人员在本职工作范围内进行系统维护，并不带来额外费用。而系统管理人员需要负责审核商品信息等工作，需要招聘学生参与此项工作，预计5000元／年。

按照两年时间计算：总费用：35000元。

12．1．1．4．5 局限性

（1）只能通过本地校园见面交易，不能通过在线支付和快递形式进行交易，限制了交易范围。

（2）参加人员较少，需一人承担数职，管理方面和任务安排方面可能存在不足。

12．1．1．4．6 技术条件方面的可行性

（1）在当前条件下，该系统的功能相互关联，除了留言功能外，其中一环无法实现都会导致交易无法进行，所以功能需要全部实现。

（2）利用现有的技术，开发人员需要着重掌握数据库原理和网络原理以做好服务器端和客户端的交互功能，这是整个系统的基础。

（3）开发人员应该在5人及以上，具有软件开发的基础知识和经验，掌握编程能力及该项目相关的技术。团队要分工明确，团结协作。

（4）经过初步估计，在规定的期限内，本系统的开发能完成。

12．1．1．5 可选择的其他系统方案

暂无。

12．1．1．6 投资及效益分析

1）支出

（1）基本建设投资。由于系统运行在学校网络信息中心的服务器上，因此并不需要另行投资。

（2）其他一次性支出。

系统开发费用：25000元；

共计：25000元。

（3）非一次性支出。由于系统运行在学校网络信息中心的服务器上，其他支出不再单独核算。但是需要招聘学生作为管理员，5000元／（人·年），按照两年计算，合计10000元。

2）收益

（1）一次性收益。本项目为公益性项目，暂无一次性收益。

（2）非一次性收益。此项目为学校公益类项目，因此可以作为学校的一项服务，采取免费方式。

如果不作为基本服务，由学生运营，可以考虑未来通过收取每笔交易5％的手续费及转卖二手物品所得。

假设一年的收益有：10万元，假设银行年利率5％，预计2年内逐年转卖物品经济收益与折现计算，共计：18．6万元（见表12-1）。

（3）不可定量的收益。该公益性项目能够增加学生对校园生活的满意度。

3）收益／投资比

收益共计：18．6万元；

投资总计：3．5万元；

整个系统生命期的收益／投资比值18．6／3．5＝5．31。

4）投资回收周期

如果收取交易费，投资回收周期为一个季度。该项目主要是公益类，初始投资不大，后续也可不收费，作为学校的基本服务。

5）敏感性分析

系统生命期长度：2年；

系统的工作负荷量：适中；

系统工作符合类型：数据处理。

12．1．1．7 社会因素方面的可行性

1）法律方面的可行性

由于本系统全权由本小组共同合作独立开发，因此并不存在合同责任方面的问题。

此次系统开发的技术来自开源社区或本团队开发成员，不存在侵犯版权、专利等问题。

通过本系统进行买卖的货品都经过当事人的确认和允许，并不存在债务和所有权问题。

2）使用方面的可行性

本系统的用户主要针对的是大学的师生及工作人员等，素质较高，大都熟悉移动App的操作和应用，能够使用该软件系统。

本系统交互友好，操作简单，附有使用说明，以App作为客户端，能够吸引用户。

12．1．1．8 结论

经过可行性分析，对需要解决的问题取得基本一致的看法，开发小组的方案能够立即执行。

12.1.2 项目开发计划

12．1．2．1 引言

1）编写目的

编写此项目开发计划的主要目的是以文件的形式对学校二手货交易市场系统的开发做规划和安排。文档中对整个项目开发过程中的工作内容流程、团队组织结构、开发进度、经费预算、内外条件需求、技术方法等做规划和说明，便于团队成员更好地了解项目情况、明确职责、合理开展各阶段各项任务、按时保质完成开发。项目开发计划是团队成员之间的共识与约定，也是项目生命周期内的所有项目活动的行动基础、项目团队开展和检查项目工作的依据。

2）背景

（1）待开发的软件系统的名称：学校二手货交易市场。

（2）本项目的任务提出者、开发者及用户。

任务提出者：曹健；

开发者：雷同学，徐同学，田同学，姚同学，苏同学；

用户：在校师生。

（3）同其他系统或其他机构的基本相互关系：系统相对独立，开发中可能会使用第三方服务或框架。

3）定义

无。

4）参考资料

《面向对象软件工程》（第3版），清华大学出版社，2011。

12．1．2．2 项目概述

12．1．2．2．1 项目目标与工作内容

本项目的目标是开发一个在线的学校二手货交易市场，给校园内的师生创造一个自由发布、浏览、查找、购买二手商品的平台。该系统分为前台和后台两个部分。前台向用户提供与二手商品交易相关的各种服务，后台面向管理员进行各项信息的管理。

工作内容包括以下几个部分：

（1）项目可行性分析。

（2）项目需求分析。

（3）项目体系结构设计。

（4）项目编程实现。

（5）项目测试与发布。

（6）项目后期管理与维护。

12．1．2．2．2 团队组织结构

团队组织结构如图12-3所示，团队成员情况如表12-2所示。

12．1．2．2．3 产品

1）程序

程序名称：校园二手商品交易平台；

编程语言：Java；

存储程序的媒体形式：Android App。

2）文件

（1）可行性研究报告。

（2）项目开发计划。

（3）风险列表。

（4）软件需求规约。

（5）词汇表。

（6）软件架构文档。

（7）软件设计模型。

（8）模块开发卷宗。

（9）软件测试计划。

（10）软件测试总结报告。

（11）用户手册。

（12）软件验收报告。

（13）交付清单。

（14）软件项目总结报告。

（15）源代码。

3）服务

（1）培训安装、使用，期限：投入使用一年内。

（2）维护和运行支持，期限：投入使用一年内。

4）非移交的产品

无。

12．1．2．2．4 验收标准

系统运行正常，程序实现预期功能。

12．1．2．2．5 项目的计划完成时间和最迟期限

计划完成时间：2016．5．21。

最迟期限：2016．5．28。

12．1．2．3 实施计划

1）工作任务的分解与人员分工

项目工作分解如图12-4所示，任务分配情况在表12-3中列出。

2）阶段计划

项目各阶段工作的安排如表12-4所示。

项目各阶段工作任务时间分配情况的甘特图如图12-5所示。

各任务依赖关系及关键路径网络图如图12-6所示。

3）预算

（1）参与开发的人员数量：5人。

（2）预计所需时间：约2个月。

（3）经费预算：

系统依托学生团队进行开发，因此所需开发经费较少：

系统开发费用：25000元。

对于维护费用，系统将要移交给网络信息中心，网络信息中心的工作人员在本职工作范围内进行系统维护，并不带来额外费用。而系统管理人员需要负责审核商品信息等工作，需要招聘学生参与此项工作，预计5000元／年。

按照两年时间计算：

总费用：35000元。

4）关键问题

（1）用户信息的保存和安全性问题。影响：如果用户信息丢失或者被窃取，会造成巨大的经济损失和隐私泄露。

（2）数据库的容量和稳定性问题。影响：数据库不稳定会导致系统瘫痪、软件无法正常使用。

（3）信息的实时性问题。影响：信息传输延时会使用户之间交流不顺畅。

（4）用户界面的人性化、操作的便捷性问题。影响：良好的用户界面和简单的操作能提高软件的实用价值。

（5）开发过程中的计划、沟通和技术限制等。影响：耽误开发进度，延长开发时间，无法达到预期目标。

12．1．2．4 技术流程计划

12．1．2．4．1 方法、工具和技巧

本项目程序采用Java语言开发，所使用IDE为intellij IDEA＋Eclipse。

本系统数据库部分使用My SQL开发。

项目开发过程采用结构化开发的方式，将系统分为多个模块分别编写。

本项目开发的生命周期采用瀑布模型。

12．1．2．4．2 技术标准

项目遵循的技术标准如下：

1）业务建模指南

业务建模指南。

2）用户界面指南

Google Material design（https：／／www．google．com／design／spec／material-design）。

3）用例建模指南

用例建模指南。

4）设计指南

Google Material design（https：／／www．google．com／design／spec／material-design）。

5）编程指南

编程及代码风格指南。

6）测试指南

GBT15532—2008计算机软件测试规范。

7）代码风格指南

编程及代码风格指南。

12．1．2．5 外部支持条件

1）需由用户承担的工作

用户需在使用过程中对本系统发生的错误提出反馈，并与开发人员沟通确定合理的需求。

2）由外单位提供的条件

本系统为独立开发，暂无须外单位提供条件。

12.1.3 风险列表

风险列表如表12-5所示。