團隊做業3需求改進與系統設計

時間 2019-11-11

標籤團隊需求改進系統設計欄目快樂工作简体版

原文原文鏈接

需求改進與系統設計css

1、需求與原型改進html

1.1改進的原型前端

一、改進說明java

對於這次二期原型製做

咱們添加了整套的後臺管理系統

後臺管理系統共分爲審覈管理，用戶管理，權限管理，遺失管理，招領管理五大模塊

與前臺信息進行一一對接

保證管理人員能在後臺界面實時高效的對網站信息完成管理更替和審覈

二、高保真原型

三、高保真原型下載地址

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

1.2改進的原型需求規格說明書jquery

一、改進說明git

項目背景進行修改。程序員

開發目標進行了修改補充。算法

用戶角色分析表進行了補充。學生方面增長了安全性。chrome

網站界面標準添加了四個新的標準，使網站界面更加標準美化。數據庫

網站設計驗收標準添加了建設方面的標準，使網站設計更爲規範。

二、需求規格說明書下載地址

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	局域網