201771010131-王之泰實驗三結對項目—《西北師範大學疫情防控信息系統》項目報告

時間 2020-08-30

原文原文鏈接

項目	內容
課程班級博客連接	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
做業要求連接	http://www.javashuo.com/article/p-zkvgqdwq-mk.html
課程學習目標	體驗軟件項目開發中的兩人合做，練習結對編程、掌握Github協做開發程序的操做方法。
本做業在哪些方面幫助我實現學習目標	經過結對項目，進一步領會軟件工程的意義和流程，再次體會合做分工小團隊效率。
結對方學號-姓名	201771010108-韓臘梅
結對方本次博客做業連接	http://www.javashuo.com/article/p-rpvmwiux-ns.html
項目Github的倉庫連接地址	https://github.com/YHwzt/Query-system-web

一.對結對方《實驗二軟件工程我的項目》的項目成果進行評價

1.1 對項目博文做業進行閱讀並進行評論

（1）結對方博客連接

（2）評論截圖以下

1.2 克隆結對方項目源碼，閱讀並測試運行代碼，複審同伴項目代碼並記錄。

（1）結對方Github項目倉庫連接

（2）代碼覈查表以下。

概要部分
（1）代碼符合需求和規格說明麼？
答：部分符合需求與規格。
（2）代碼設計是否有周全考慮？
答：不太周全，修改了不少次。
（3）代碼可讀性如何？
答：簡單易懂。
（4）代碼容易維護麼？
答：較難。
（5）代碼的每一行都執行並檢查過了嗎？
答：是的，檢查過。
設計規範部分
（1）設計是否聽從已知的設計模式或項目中經常使用的模式？
答：否
（2）有沒有硬編碼或字符串/數字等存在？
答：有一部分。
（3）代碼有沒有依賴於某一平臺，是否會影響未來的移植（如Win32到Win64）
答：沒有依賴，不會影響。
（4）開發者新寫的代碼可否用已有的Library/SDK/Framework中的功能實現？在本項目中是否存在相似的功能能夠調用而不用所有從新實現？
答：能夠實現，不存在。
（5）有沒有無用的代碼能夠清除？（不少人想保留儘量多的代碼，由於之後可能會用上，這樣致使程序文件中有不少註釋掉的代碼，這些代碼均可以刪除，由於源代碼控制已經保存了原來的老代碼。）
答：有，已清除。
代碼規範部分
（1）修改的部分符合代碼標準和風格麼（詳細條文略）?
答：部分代碼符合，不符合的已修改。
具體代碼部分
（1）有沒有對錯誤進行處理？對於調用的外部函數，是否檢查了返回值或處理了異常？
答：查閱資料並討論之後處理完成，檢查並處理了。
（2）參數傳遞有無錯誤，字符串的長度是字節的長度仍是字符（多是單/雙字節）的長度，是以0開始計數仍是以1開始計數？
答：有錯誤已改正，字符串的長度是字節的長度，是以0開始計數。
（3）邊界條件是如何處理的？Switch語句的Default是如何處理的？循環有沒有可能出現死循環？
答：頁面設計的邊界較適宜，結對同伴只完成了頁面設計，因此未涉及循環，部分功能未實現。
（4）有沒有使用斷言（Assert）來保證咱們認爲不變的條件真的知足？
答：沒有使用。
（5）對資源的利用，是在哪裏申請，在哪裏釋放的？有沒有可能致使資源泄露（內存、文件、各類GUI資源、數據庫訪問的鏈接，等等）？有沒有可能優化？
答：是在網上找到的，不會致使資源泄漏。
（6）數據結構中是否有無用的元素？
答：檢查事後有些許，已經刪除或修改。
效能
（1）代碼的效能（Performance）如何？最壞的狀況是怎樣的？
答：代碼正確，程序運行正常。
（2）代碼中，特別是循環中是否有明顯可優化的部分（C++中反覆建立類，C#中 string 的操做是否能用StringBuilder 來優化）？
答：有可優化部分，但修改後效果無明顯提高，因此保持原樣。
（3）對於系統和網絡調用是否會超時？如何處理?
答：不會超時，已解決。
可讀性
代碼可讀性如何？有沒有足夠的註釋？
答：代碼不是很複雜，有些許註釋，以後又補充了些關鍵註釋。
可測試性
代碼是否須要更新或建立新的單元測試？還能夠有針對特定領域開發（如數據庫、網頁、多線程等）的核查表。
答：不須要。html

-- 覈查表模板引用自《構建之法-現代軟件工程》git

1.3 依據複審結果利用github的Fork、Clone等操做對同伴我的項目源碼合做修改。

（1）結對方的項目倉庫本來Fork、Clone、Push、Pull request、Merge pull request日誌數據以下。github

（2）使用git命令clone結對方倉庫到本地便於查看修改。web

（3）使用fork功能將結對方倉庫分流到個人我的倉庫中。數據庫

（4）使用Pull request請求原做者檢查合併編程

（5）原做者使用Merge pull request合併了我提交的代碼。windows

（6）原做者合併以後的日誌數據。設計模式

二.西北師範大學疫情防控信息統計系統開發

2.1 需求分析陳述。

要求設計開發一款符合我校疫情防控工做需求的信息系統，使之具備如下功能：微信

（1）可採集全校各種師生員工疫情信息；網絡
（2）各二級部門疫情防控工做負責人可查看本部門人員疫情彙總，並提供高級查詢功能進行多屬性組合查詢和可視化統計功能；
（3）學校防控辦指定負責人登陸《西北師範大學疫情防控信息統計》子系統，可瀏覽全部人員填報彙總數據清單，利用【高級查詢】可進行數據組合篩選，系統以圖形化方式展現各學院已填報和未填報學生統計狀況和關鍵疫情數據統計狀況，可【導出】查詢列表的EXCEL文件；
（4）人機交互界面要求GUI界面（WEB頁面、APP頁面均可）；
（5）附加功能：定時填報提醒。

就咱們團隊的理解來看，需求分析就是剖析客戶棱模兩可的需求，將其細緻化，可實行化。據整體需求來看，咱們發現該項目要求有三類人，第一類人只具備填報功能，第二類人可以進行各自範圍的查看彙總，而第三類人則至關因而一個「全能」的人。因此在數據庫中咱們將各種角色設計爲一張表，將疫情信息設計爲一張表，也就是兩張表。

就第一個功能，要求能採集全校學生/教職工的疫情信息。咱們將其抽象爲第一類人，具體應該爲設計能填寫包含一些我的疫情相關信息的表單並將其提交給後臺。除此以外應該不具備查看修改（除了本身填寫的以外）等功能。

就第二個功能，要求各二級部門疫情防控工做負責人可查看本部門人員疫情彙總，並可以進行多屬性組合查詢和可視化統計功能。這個需求的角色也就是咱們抽象化的第二類人，該類角色不可以進行增刪改等功能，即，只能查看彙總和數據可視化，就現實生活來看該類角色至關於一個彙總人員，考慮到包庇等現象，該角色沒有刪除增長的權限。

就第三個功能，要求學校負責人登陸子系統，可瀏覽全部人員填報彙總數據清單，可進行數據組合篩選查詢，以圖形化方式展現各學院已填報和未填報學生統計狀況和關鍵疫情數據統計狀況，可【導出】查詢列表的EXCEL文件。這個角色也就是第三個角色，該角色除了可以進行增刪查改等功能外，還能導出表格和數據可視化。

就第四個功能，人機交互界面要求採用GUI，這個不難實現，可採用app和web等多種多樣的頁面實現。

就附加功能，這個功能，我和同伴討論了好些時間，由於形式多種多樣，我以爲這個功能沒有必要，從個人角度看來，若是足夠重視某件事的話，忘記的可能性實際上是很小的，並且基本每一個人都有手機，手機上最基礎的一個功能就是鬧鈴，本身設置個鬧鐘，方便了開發者也提醒了本身。而個人隊友則是認爲人無完人，仍是選擇一種形式提醒一下填報人員。因此咱們構思了不少種方法，例如，微信已經成爲一個大衆通信軟件，用微信公衆號作天天定時提醒填報等等。最後咱們選擇的是採用郵件提醒的方式，定時給用戶發送一個填報提醒。

2.2 軟件設計說明。

2.2.1 軟件背景

2019年12月末，中國武漢發生新型冠狀病毒（2019-nCoV) 感染的肺炎疫情，爲遏制疫情蔓延，有效切斷病毒傳播途徑，在中央政府指導下，各級政府部分採起了一系列防控措施： 2020年1 月23 日10時起對武漢「封城」，全國 31個省市也相繼實施了嚴格的防控措施；全國各省市向武漢和湖北派遣醫療隊參與救治工做；在全國範圍內調配口罩、防禦服、藥品等急需的醫療資源支援武漢；指導和督促全國範圍內擁有醫療物資生產資質的企業儘快恢復生產能力；定向撥付專項財政資金用於疾病防控；從其餘省份調集物資保障武漢市民平常生活。

值得一提的是，中國互聯網企業在這次疫情防控中發揮了社會治理方面的重要做用。以騰訊爲例，圍繞應對疫情管控需求開發了十一款產品。其中疫情在線問診功能，對於減小發熱病人之間的相互交叉感染具備重要的做用，患者在家經過互聯網向在線醫生問診，減小了病毒傳播或感染的風險；謠言粉碎對於公衆採起理性態度看待疫情的發展具備重要意義。滴滴出行還在武漢專門組建車隊，服務於醫護人員的通勤，這在實施交通管制的武漢具備重要做用。此外，還有新型肺炎確診患者同行程查詢工具，用戶只須要輸入本身所乘坐交通工具的時間和班次，就能夠確認是否與被確診感染者同行，提早作好自我隔離和就診工做。在疫情防控中，中國互聯網企業不只發展壯大，在承擔社會責任方面也愈來愈成熟。

爲有效配合防控機構有關疫情信息的採集、統計與排查，我校開發了教職工/學生疫情上報系統，該系統由教職工疫情每日上報、學生疫情每日上報、二級部門疫情每日彙總表、疫情防控填報統計四個子系統組成。實現對我校各種人員基本狀況、所在區域及活動軌跡及健康情況的信息收集。師生經過我校企業微信服務大廳訪問該系統進行遠程信息填報。

2.2.2 軟件整體結構設計

（1）設計三級註冊登陸功能，並對每一個級別用戶作出功能使用的限制。

（2）系統主要有註冊模塊，登陸模塊，填報模塊，查詢模塊，導出模塊，提醒模塊六大塊構成。

（3）接口設計
1）外部接口
用戶界面：在界面設計上，採用簡單明瞭，易於操做的原則，突出的顯示重要信息。
軟件與硬件接口：本系統設有GUI界面，考慮到操做簡單，易於管理方面，主要硬件接口設備爲 PC，鼠標，鍵盤。而軟件接口主要以 windows 平臺爲基本平臺。
2）內部各模塊之間相互獨立又彼此關聯，主要經過方法調用實現各部分的鏈接。

（4）數據結構設計

設計兩張結構表：用戶信息表和疫情信息表。

2.2.3 軟件功能描述

（1）可採集疫情信息；
（2）各二級角色可查看本部門人員疫情彙總，並提供高級查詢功能進行多屬性組合查詢和可視化統計功能；
（3）三級角色，可瀏覽全部人員填報彙總數據清單，利用【高級查詢】可進行數據組合篩選，系統以圖形化方式展現各學院已填報和未填報學生統計狀況和關鍵疫情數據統計狀況，可【導出】查詢列表的EXCEL文件；
（4）人機交互界面要求GUI界面（WEB頁面、APP頁面均可）；
（5）定時填報提醒功能。

2.3 軟件實現

　　定義用戶類(User)，聲明私有變量private的序號（id），姓名(username)，密碼（Password），用戶類型（type），和封裝各自屬性的方法:set(),get()，由於屬性私有，不可直接訪問，例如id在外邊不可直接設置，可經過setId方法來設置id的值，getId獲取id的值。

　　定義信息類(virus)，聲明私有變量學院（college），班級（myclass），填報日期（startdate），姓名（username），聯繫電話（tel），省（province），市（city），區（areas），留學生（ischinesestudent），武漢學生（iswuhanstudent），湖北學生（ishubeistudent），14天接觸（is14contact），在武漢（isinwuhan），在湖北（isinhubei），今天返校（istodayformother），疑似（islikevirus），確診（isconfirmvirus）。

　　beans類爲Javabean類，config配置類，mapper爲dao類，service服務類，每類只負責一項職責，每一個方法完成一個計算，程序邏輯簡單，對類有較高的可讀性。設計接口時，給每個接口按必定比例設計分配方法，減小代碼冗餘。且高層模塊不依賴低層模塊。

2.4 核心功能代碼展現

/** * 將數據寫入到excel中 */
    public static void makeExcel(List<List<String>> result,String[] tittle) {
        try {
            // 建立一個workbook對應一個excel文件
            HSSFWorkbook workbook = new HSSFWorkbook();
            // 在workbook中建立一個sheet對應excel中的sheet
            HSSFSheet sheet = workbook.createSheet("病例日期表");
            // 在sheet表中添加表頭第0行，舊版本poi對sheet的行列有限制
            HSSFRow row = sheet.createRow(0);
            // 建立單元格，設置表頭
            HSSFCell cell = null;
            for (int i = 0; i < tittle.length; i++) {
                cell = row.createCell(i);
                cell.setCellValue(tittle[i]);
            }
            // 寫入數據
            for (int i = 0; i < result.size(); i++) {
                List<String> oneData = result.get(i);
                HSSFRow row1 = sheet.createRow(i + 1);
                //建立單元格設值
                for (int j = 0; j < oneData.size(); j++) {
                    row1.createCell(j).setCellValue(oneData.get(j));
                }
            }
            //將文件保存到指定的位置
            FileOutputStream fos = new FileOutputStream("D:\\result.xls");
            workbook.write(fos);
            System.out.println("寫入成功");
            fos.close();
        } catch (Exception e) {
            e.printStackTrace();
        }

    }

2.5 程序運行功能界面截圖。

基本功能

角色註冊

三級角色登錄

學生/教職工填報功能

各二級部門疫情防控工做負責人可查看本部門人員疫情彙總，高級查詢功能進行多屬性組合查詢和可視化統計功能；

學校負責人登陸子系統，可瀏覽全部人員填報彙總數據清單，利用【高級查詢】可進行數據組合篩選，

刪除功能

添加功能

系統以圖形化方式展現各學院已填報和未填報學生統計狀況和關鍵疫情數據統計狀況，

可【導出】查詢列表的EXCEL文件；

（4）人機交互界面要求GUI界面

WEB頁面

附加功能

定時填報提醒

就是有時候會被識別成垃圾郵件，就很難受

2.6 描述結對過程，QQ截圖

本次經過合做項目，和隊友進行了一段很好的合做時期，分工明確，有條不紊，雖然中途出了些爭執，但最後仍是很好的達成一致。

2.7 結對做業PSP。

PSP2.1	內容	計劃完成須要的時間(min)	實際完成須要的時間(min)
Planning	計劃	30	40
Estimate	估計這個任務須要多少時間，並規劃大體工做步驟	30	40
Development	開發	1100	1330
Analysis	需求分析 (包括學習新技術)	60	180
Design Spec	生成設計文檔	30	30
Design Review	設計複審 (和同事審覈設計文檔)	60	50
Coding Standard	代碼規範 (爲目前的開發制定合適的規範)	30	40
Design	具體設計	240	200
Coding	具體編碼	500	600
Code Review	代碼複審	60	50
Test	測試（自我測試，修改代碼，提交修改）	120	180
Reporting	報告	120	180
Test Report	測試報告	40	60
Size Measurement	計算工做量	40	30
Postmortem & Process Improvement Plan	過後總結 ,並提出過程改進計劃	40	90

2.8 小結感覺

兩人合做真的可以帶來1+1>2的效果嗎？對於這個問題經過本次合做我以爲兩我的合做作出的同一件事，比起分別單獨作那效果確定是要好得多的。經過這次結對，我以爲仍是利大於弊的，有個隊友的存在，至關於多了一雙眼睛和一個不一樣的思惟，解決問題的角度和方法就能夠多樣化，多角度化，好比我和隊友之間對於附加功能的設計方面就有一些爭執和討論。對於本身的不足之處也有個很好的對比體現，方便本身在之後提高補足。並且開發出來的項目也應該是比一我的作要嚴謹的，有些工做還能夠分工合做，極大的減小了我的負擔。而弊端就是意見的不統一，和行事的風格化，時間的分配不一致等等。