团队做业3需求改进与系统设计

需求改进与系统设计

1、需求与原型改进

1.1改进的原型

 

一、改进说明

 

对于这次二期原型制做

咱们添加了整套的后台管理系统

后台管理系统共分为审核管理，用户管理，权限管理，遗失管理，招领管理五大模块

与前台信息进行一一对接

保证管理人员能在后台界面实时高效的对网站信息完成管理更替和审核

 

二、高保真原型

 

 

 

 

 

三、高保真原型下载地址

 

https://git.coding.net/ma744191948/team.work.git

 

---

1.2改进的原型需求规格说明书

 

一、改进说明

项目背景进行修改。

开发目标进行了修改补充。

用户角色分析表进行了补充。学生方面增长了安全性。

网站界面标准添加了四个新的标准，使网站界面更加标准美化。

网站设计验收标准添加了建设方面的标准，使网站设计更为规范。

 

二、需求规格说明书下载地址

 

https://git.coding.net/ma744191948/need.git

 

 

---

---

---

2、系统设计

2.1系统架构设计

 

开发级需求分析

在开发过程当中，团队自己在开发的起始阶段肯定了基本的开发级需求分析：

通过上一次的结对做业，咱们对于合做开发这件事已经加深了一层理解，也更加清楚合做开发和我的开发的不一样。所以咱们会在开始开发前就制定好代码规范，在实行过程当中，按照构建之法书中的要求来进行代码的实现，修改，测试，维护等等。

通过讨论咱们决定使用已经学习过的代码语言来实现页面（例如：java，js，servlet，jsp等等），对于这几种语言咱们团队都有一些开发经验，再次开发时会提升一些开发效率，并且这几种语言已经能够解决咱们项目开发中的大部分问题。对于解决不了的问题，咱们会进行学习，好在团队学习积极性较高，学习能力较强，因为网页功能较为复杂，咱们团队将尽量的使用成熟的框架技术，实现对开发效率和开发质量的需求。

 

需求回顾：

咱们想要作一个关于失物招领的平台，如今天天东师有大量的学生丢失物品，而咱们开发这样一个网站，是方便捡到的人能够将物品信息发布在网上，而后丢失东西的人能够在咱们的网站上进行搜索查询，方便东师学生生活，这样一个专门的网站，能够减小用户丢失重要物品而找不到的状况，极大的帮助了这些遗失物品的人。

 

---

 架构设计

 

1.设计摘要说明

首先从架构的层次上，对自己的设计进行最简短的概述：

前端页面

直接与用户打交道，发出提供用户增长，减小，修改，查询遗失物品功能的请求

后端系统

负责处理用户的请求，并衔接搜索系统，使用户对数据进行操做

搜索系统

负责搜集、整合数据，并响应网站后端的搜索请求，提供搜索结果

 所以不妨设计东师拾遗的概念架构图以下图所示：

 

2.前端页面设计

前端开发将依据UI设计的交互进行开发，主要用到的语言有：html、css、jquery、js。开发过程会用到Bootstrap框架，以完成响应式布局。开发工具将用到sublime tex，后期与后端调试时将用到IDE。前端开发会积极作好与UI设计人员和后台开发人员的沟通，力求界面美观大方，交互符合用户需求。

 

3.后端系统设计

为了达到咱们的开发级需求，咱们选择使用java语言进行后端开发，并使用SpringMVC框架。

比较赞成一种说法，Java最大的优点不是它的跨平台性而是它庞大而完善的生态系统。它的流行最主要缘由仍是由其生态系统决定的。

Java语言各方面比较均衡，拥有最值得信赖的GC，避免不少码农的低级错误。而且天生的面向对象设计，更容易模块化开发。再加上Java强类型静态语言，只要框架已搭好，即使开发人员能力不足，也基本能保证代码质量，这在大项目的协做开发、维护方面颇有优点。开源，拥有大量的第三方库，而且大部分质量有保证，能够拿来就用，对软件生产效率的提高所带来的巨大价值。正如一句话所说：“咱们不生产代码，咱们只是Github的搬运工。”而且Java拥有不少杀手级应用，如Spring，Apache、Android，Hadoop，Spark等。

为了提升咱们的开发效率，咱们决定使用SpringMVC框架若是没有MVC设计模式。程序间的各层之间依赖很是强，耦合度高。严重违背了高内聚低耦合的设计原则。而WebMVC将控制逻辑和功能处理，模型和视图进行了分离。下降耦合。

后端系统主要有两部分功能，一部分是与用户系统相关的功能，如用户的登录、管理、发布还有完成等等，另外一部分则是与搜索引擎的衔接。同时还有一个模块负责整个站点的衔接、整合等。

 

ps：数据库架构

信息架构的方面，咱们认为数据库的设计也相当重要。

创建用户实体类，物品实体类，用户实体类中声明全部须要用到的属性。用户和物品在关系上呈现一对多的关系。二者之间经过用户的id实现关联。

因为拾遗物品是通过分类的，对于这些物品不一样分类设置不一样键值，相似于Map存储方式。

对于开发过程：首先实现用户模块，再增长主站模块实现与数据库信息之间各类不一样的操做。最后经过数据库查询实现搜索模块，搜索过程当中支持关键字模糊查询。

 

---

 平台架构设计

 

1.tomcat服务器

Tomcat是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目，由Apache、Sun 和其余一些公司及我的共同开发而成。因为有了Sun 的参与和支持，最新的Servlet 和JSP 规范老是能在Tomcat 中获得体现，Tomcat 5支持最新的Servlet 2.4 和JSP 2.0 规范。由于Tomcat 技术先进、性能稳定，并且免费，于是深受Java 爱好者的喜好并获得了部分软件开发商的承认，成为目前比较流行的Web 应用服务器。

 

2.搜索系统

数据库查询是数据库的最主要功能之一。为了增长数据库的查询效率，咱们准备使用索引数据结构。

使用索引结构的缘由以下：

咱们都但愿查询数据的速度能尽量的快，所以数据库系统的设计者会从查询算法的角度进行优化。最基本的查询算法固然是顺序查找（linear search），这种复杂度为O(n)的算法在数据量很大时显然是糟糕的，好在计算机科学的发展提供了不少更优秀的查找算法，例如二分查找（binary search）、二叉树查找（binary tree search）等。若是稍微分析一下会发现，每种查找算法都只能应用于特定的数据结构之上，例如二分查找要求被检索数据有序，而二叉树查找只能应用于二叉查找树上，可是数据自己的组织结构不可能彻底知足各类数据结构（例如，理论上不可能同时将两列都按顺序进行组织），因此，在数据以外，数据库系统还维护着知足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就能够在这些数据结构上实现高级查找算法。这种数据结构，就是索引。

 

咱们准备使用上图的索引方式：

左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址（注意逻辑上相邻的记录在磁盘上也并非必定物理相邻的）。为了加快Col2的查找，能够维护一个右边所示的二叉查找树，每一个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就能够运用二叉查找在O(log2n)O(log2n)的复杂度内获取到相应数据。

 

---

需求分析的过程

 

 

---

概念结构设计

 

一、说明

实体集：拾到物品的人、失主、被拾到的物品、丢失的物品

属性集：

l  拾到物品的人（姓名，校区，邮箱，电话）

l  拾到（拾主联系方式，拾到的物品编号，拾到时间，拾到地点）

l  拾到的物品（编号，类别，具体描述）

l  失主（姓名，校区，邮箱，电话）

l  丢失（失主联系方式，丢失的物品编号，丢失时间，丢失地点）

l  丢失的物品（编号，类别，具体描述）

l  归还（物品编号，失主联系方式，拾主联系方式）

 联系集：

l  拾到东西的人和拾到的物品：每一个人能够拾到多个物品，存在“拾到”的关系：1：N

l  失主和丢失的物品：一我的能够丢失多个物品，存在“丢失”的关系：1：N

l  拾到东西的人和失主：失主经过平台查询本身所丢之物，在系统中找到所丢之物对应的拾到东西的人的联系方式，寻回物品。

 

---

二、E-R图

失主与丢失的物品

 

拾到物品的人与拾到的物品

 

拾到物品的人与失主

 

 

---

逻辑结构设计

 

一、数据模型的规范化（根据函数依赖，使全部关系模式达到3NF）

（1）拾到东西的人模式（假设无同姓名的人）：

 姓名（主键）  校区、邮箱、电话

（2）失主模式：

姓名（主键）  校区、邮箱、电话

（3）拾到模式

 物品编号（主键）  拾到地点、拾到时间、拾主联系方式

（4）丢失模式

物品编号（主键）  丢失地点、丢失时间、失主联系方式

（5）物品模式

物品编号（主键）   类别、描述

 

---

 

二、 在数据库中的具体实现

Finder（拾到物品的人的表）：

字段名	数据类型（精度范围）	空/非空	约束条件	说明
Fname	Varchar(10)	Not null	Primary key	姓名
Fzone	Char(10)	Not null		校区
Femail	Char(10)	Not null		邮箱
Fphone	Varchar(10)	Not null		电话

 

 Loser（失主的表）：

字段名	数据类型（精度范围）	空/非空	约束条件	说明
Lname	Varchar(10)	Not null	Primary key	姓名
Lzone	Char(10)	Not null		校区
Lemail	Char(10)	Not null		邮箱
Lphone	Varchar(10)	Not null		电话

 

Find（拾到模式）

字段名	数据类型（精度范围）	空/非空	约束条件	说明
Fdid	Varchar(10)	Not null	Primary key	物品编号
Fdplace	Char(20)	Not null		拾到地点
Fdtime	Char(10)	Not null		拾到时间
Fdphone	Varchar(10)	Not null		拾主联系方式

 

 Lose（丢失模式）

字段名	数据类型（精度范围）	空/非空	约束条件	说明
Lsid	Varchar(10)	Not null	Primary key	物品编号
Lsplace	Char(20)	Not null		丢失地点
Lstime	Char(10)	Not null		丢失时间
Lsphone	Varchar(10)	Not null		失主联系方式

 

 Thing（物品模式）

字段名	数据类型（精度范围）	空/非空	约束条件	说明
Tgid	Varchar(10)	Not null	Primary key	物品编号
Tgname	Char(10)	Not null		类别
Tgdiscrib	Varchar(30)	Not null		具体描述

 

---

 

物理结构设计

 

一、数据库系统选择

操做系统选择Windows10，数据库管理系统选择SQL Server 2008，前台开发工具选择sublime text3，后台开发工具选择myeclipse与IDE。

 

二、设置索引

（1）对于Finder表，将姓名做为惟一索引。

（2）对于Loser表，将姓名做为惟一索引。

（3）对于Find表，将Fdid（物品编号）做为惟一索引，将类别做为聚簇索引。

（4）对于Lose表，将Lsid（物品编号）做为惟一索引，将类别做为聚簇索引。

（5）对于Thing表，将Tgid（物品编号）做为惟一索引，将类别做为聚簇索引。

 

三、用户权限设计

用户权限	查询物品信息	发布物品信息	修改物品信息	删除物品信息
管理员	能够	能够	能够	能够
已注册用户	能够	能够	能够（仅本身）	能够（仅本身）
未注册用户	能够	不能够	不能够	不能够

 

---

2.2任务分解WBS

 

 

 

 

---

---

---

 3、测试计划

 

3.1测试计划

目录

一、引言

项目背景

参考资料

测试术语（新增）

 

二、任务概述

测试范围

测试目标

 

三、测试策略

测试人员需求、分工（新增）

测试方法

测试工具

测试阶段预估及日程计划

测试变量矩阵量

 

四、测试资源

 

五、风险评估

 

六、其余内容

 

---

引言

 

项目背景

目前市场上有许多相似的失物招领网站，可是大多数都没有针对性。大多数高校失物招领仍是依靠校内实体站点或者公众号的方式进行失物招领，具备即时性，可是并不方便，范围不够广。基于在校大学生的特性，咱们但愿基于网站，创建一款针对在校大学生的半实名制可搜索的失物招领网站。

 

参考资料

测试需求分析总结

http://www.javashuo.com/article/p-hjuotkth-bo.html

网站测试流程、要求及测试报告                                                                 

http://lib.csdn.net/article/softwaretest/24298?knId=1307

测试需求分析

https://wenku.baidu.com/view/63d77034336c1eb91b375d1f.html

《东师拾遗》需求规格说明书

https://git.coding.net/ma744191948/need.git

 

测试术语

测试术语	名词解释
轮播	轮播为网站首页中的流动播放的图片，主要为较为紧急的老师或学生丢失的最新的物品信息
权限管理	对于管理员的权限及学生老师用户权限的管理区域
种类	用于用户搜索物品关键词时网页提供的一些热搜词及分类
用户管理	对于用户的增删改查管理

 

 

---

 任务概述

 

测试范围

针对于网页进行的各项实用性能测试（包括用户界面及管理员界面）

制做者测试：美工页面测试、程序员页面测试

全面测试：页面框架结构问题、错别字、常识问题

发布测试：环境不一样致使的问题

 

测试目标

连接测试能经过

表单测试能经过

Cookies测试能经过

数据库测试能经过

性能测试能基本经过，尽可能提升性能

可用性测试能经过

兼容性测试能经过firefox，chrome，360

 

---

 测试策略

 

测试人员需求、分工

分析、缺陷、矫正测试：马越、李可欣、刘士齐

产品完成验证：马越、翁梦蕾、杨帆

 

测试方法

手动测试：每一个连接、文字都由人工编辑测试

测试为交互验证方式，互相督促，互相验证

压力测试：使用http_upload压力测试

 

测试工具

Junit单元测试工具

http_upload压力测试工具

WebPagetest 前端性能测试工具

 

测试阶段预估及日程计划

 

测试阶段	测试任务	工做量估计	人员分配	时间安排
第一阶段 功能测试	登录 注册 管理员登录 首页搜索 管理员增删改查 用户增删改查	复杂	全体人员	开发阶段
第二阶段 系统测试	1.完成全部模块的组合测试 2.肯定全部业务流向和数据都是正确的。	中等	前端开发人员、后端开发人员	Alpha阶段结束后2天
第三阶段 性能测试	在多用户访问，交替进行负荷压迫测试	复杂	全体人员、邀请部分用户参与	Beta阶段结束后2天
第四阶段 兼容测试	软件在各个软件平台上的运行状况	中等	全体人员	Beta阶段结束后4天

 

测试变量矩阵量

	用户类型	屏幕分辨率	操做系统	默认语言	浏览器	网络速度	组合总数
变量数目	3	2	3	2	3	3	324
	管理员	800*600（像素）	Windows10	简体中文	360	拨号
	已注册用户	1024*768（像素）	Windows7	英文	Firefox	ADSL
	未注册用户		mac		Google	局域网

 

---

测试资源

 

人力资源：所有开发人员及邀请用户测试人员

物力资源：

Windows10操做系统

Windows7 操做系统

Mac操做系统

google浏览器、firefox浏览器

 

---

风险评估

 

网站进度风险：时间较短，开发人员较少，人员配比不平均，可能致使网站按时交付时出现部分问题

网站需求风险：需求分析文档可能会有不足，形成后期的问题

技术开发风险：技术不成熟，可能致使网站性能较差

网站设计风险：并非由专业人员设计，交互性可能略微落后

人员流失风险：人员流失致使网站进度拖慢

竞争风险：同期可能有较多网站与之进行竞争

 

---

 其余内容

 

测试计划制定者：翁梦蕾、李可欣

日期：2018年5月30日

修改记录：暂无

评审人员：马越

开发负责人：李可欣、翁梦蕾、杨帆、刘士齐

测试负责人：马越