牛莉梅 實驗四 軟體項目案例分析

項目	内容
課程班級部落格連結	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
這個作業要求連結	https://www.cnblogs.com/nwnu-daizh/p/12616341.html
我的課程學習目标	1、熟練部落格操作 2、掌握軟體項目個人開發流程 3、掌握Github的操作方法
這個作業在哪些方面幫助我實作學習目标	1、鍛煉了我的動手能力 2、讓我在找尋别人錯誤的同時發現自己的錯誤
結對方學号-姓名	<201771030120-王嫄>
結對方本次部落格作業連結	https://www.cnblogs.com/Jenna-wang/p/12631798.html

一、任務1：這裡我選取的是李婷華&王穎奇組

https://www.cnblogs.com/litinghua/p/12534838.html#4541150

https://www.cnblogs.com/1556889081wyq/p/12546166.html

實驗三優秀案例推薦：

在實驗三得分100分以上作業中，任選一份作為案例，對案例項目成果進行評價，具體要求如下：

（1）對案例博文作業進行閱讀并進行評論，評論要點包括：博文結構、博文内容、博文結構與PSP中“任務内容”列的關系，并将以上評論内容釋出到案例作業的部落格評論區。

（2）克隆案例項目源碼到本地機器，閱讀項目代碼規範文檔并運作代碼，總結代碼運作中存在的問題，體會案例博文是否有助于項目代碼了解。

（3）總結本組實驗三部落格作業及代碼設計存在問題與不足，列舉代碼中存在的bug，未實作的功能等等。

1、案例作業部落格連結：李婷華部落格連結

2、案例作業項目倉庫連結: 李婷華組倉庫連結

3、符合（1）要求的部落格評論

4、符合（2）要求的系統運作截圖、軟體功能總結；附加分要求：若測試發現案例代碼存在bug，截圖為證.

案例博文在軟體設計說明那一塊寫的非常詳細，包括資料庫的表結構，軟體功能以及主要的類代表的含義及功能等，這極大的友善了讀者去使用軟體，其中，案例博文的注釋等内容也十分詳細，使得代碼容易了解。

軟體功能總結：

• 軟體功能：
  • 師生可登入系統進行疫情資訊的填報；
  • 二級防疫部門人員可進行疫情資訊的填報；
  • 二級防疫部門負責人可對本部門人員的資訊進行增删改查，可根據姓名進行模糊查詢，根據學号、填報日期、感染情況進行準确查詢，可檢視感染情況的統計資料（用柱狀圖來表示），這裡的感染情況查詢是檢視具體的某一天。
  • 學校防控辦人員可以進行增删改查等功能，可以按照學号、時間、感染情況等進行準确查詢，按照姓名進行模糊查詢，可檢視感染情況和填報情況的統計資料，可以檢視學生和教職工統計資訊的彙總。
• 軟體功能圖:

  

系統運作截圖：

學生登陸系統

• 登陸：

  

• 填寫資訊：

  

二級防疫部門人員系統

• 

• 

二級防疫部門負責人系統

• 

bug1：二級部門負責人的增加别的學院的，也顯示加入成功，此處應該對學院一欄做一個限制。

• 增加：例如：輸入數統院，也顯示插入成功。

  

bug2：這裡的删除操作隻能進行一次，如果想繼續删除，則無法實作，需要重新運作程式。

• 删除：例如：删除劉鵬的資訊，雖然顯示删除成功，但資料還在。

  

• 删除後：

  

• 修改：修改前後對比圖如下

  

• 學号準确查詢：

  

• 姓名模糊查詢：

  

• 時間準确查詢：

  

• 感染情況查詢：

  

• 感染情況統計圖：

  bug3:這裡必須輸入日期才可以查詢到正确地結果，但是并未有明顯的提示，如果使用者按照其他條件查詢統計圖，就不會有正确的顯示

  

• 錯誤的顯示：

  

校防控辦負責人系統

• 

• 增加：

  

• 删除：

  

• 删除後：可以看到劉鵬的資訊還在上面，即使更新也沒有作用，這也就是前面說的bug2。

  

• 修改：

  

• 修改後：

  

• 

• 

• 

• 

• 

bug4：這裡隻實作了全校在某一天的感染情況資料統計，而作業要求的校級防控辦負責人檢視各個學院某一天的感染和未感染人數這個功能并未實作，比如在這裡如果輸入計工院，2020-04-01，感染人數應該為0個，而統計圖顯示感染人數有一個，顯然是不正确的。

• 查詢某人某天情況：

  

• 填報情況統計圖：這裡以計工院，2020-04-01日為例，設定總人數為10人

  

bug5:導出excel，雖然有相應的彈出框，但并未看見有資料導出到excel，即使修改路徑也并未看到有資料導出此處還有待與原作者進一步探讨

• 檢視檔案源代碼位置，發現案例檔案路徑有誤

  

• 修改案例excel檔案路徑，還是未看到有資料導出

  

• 學生統計資訊彙總：

  

• 教職工統計資訊彙總：

  

5、總結本組實驗三部落格作業及代碼設計存在問題與不足，列舉代碼中存在的bug，未實作的功能等等，代碼運作存在的問題截圖為證。

• 總結本組實驗三部落格作業：我們小組總的來說在博文結構上沒有太大問題，主要就是界面不夠美觀，界面背景顔色搭配不太好看，相比于案例博文，實作的功能也沒有很全面。
• 代碼運作存在的bug：測試代碼過程中發現我們的項目在導出excel的時候還是有點小問題，有時候也存在excel不能導出的情況，暫時未找到原因，截圖如下：

錯誤情況：找不到檔案

正确情況：可以找到檔案

• 未實作的功能：并未完全實作鬧鐘提醒功能

二、任務2

與實驗三結對夥伴協作學習：閱讀《現代軟體工程—建構之法》第5-6章内容，了解并掌握軟體項目團隊的特點、了解軟體團隊的模式、結合理論課學習内容了解瀑布模型及其變形、漸進傳遞流程、靈活流程等典型軟體過程模型特點，了解并體會卡内基梅隆大學（CMU）軟體工程學院總結的TSP原則；

部落格作業中針對任務2的評分要點：提供兩人讨論任務2學習内容的微信或QQ截圖，要求截圖美觀。

1、軟體項目團隊的特點

• (1) 團隊有一緻的集體目标，團隊要一起完成這目标。一個團隊的成員不一定要同時工作，例如接力賽跑。
• (2) 團隊成員有各自的分工，互相依賴合作，共同完成任務。
• (3) 團隊具有融洽的交流環境
• (4) 團隊具有共同的工作規範和架構
• (5) 團隊采用合理的開發過程

2、軟體團隊的模式

軟體團隊有各種形式，适用于不同的人員和需求。基于直覺形成的團隊模式未必是最合适的。例如小朋友們剛開始踢足球的時候，大家都一窩蜂地去搶球，球在哪裡，一堆人就跟到哪裡,這樣的模式可以叫一窩蜂模式 ( Chaos Team)。随着團隊的成熟和環境的變化，團隊模式逐漸演變成了一下幾種:

• (1) 主治醫師模式 ( Chief Programmer Team, Surgical Team )
  • 就像在手術台上那樣,有一個主刀醫師,其他人(麻醉,護士,器械)各司其職,為主刀醫師服務。這樣的軟體團隊中，有首席程式員( Chief Programmer),他1她負責處理主要子產品的設計和編碼，其他成員從各種角度支援他1她的工作(後備程式員、系統管理者、工具開發、程式設計語言專家、業務專家)。
• (2) 明星模式( Super -star Model )
  • 主治醫師模式運用到極點，可以蛻化為明星模式，在這裡，明星的光芒蓋過了團隊其他人的總和，2004年到2012年的“翔之隊”就是一個例子。明星也是人，也會受傷，犯錯誤，如何讓團隊的利益最大化，而不是明星的利益最大化?如何讓團隊的價值在明星隕落之後仍然能夠保持?是這個模式要解決的問題。
• (3) 社群模式( Community Model )
  • 社群由很多志願者參與，每個人參與自己感興趣的項目，貢獻力量,大部分人不拿報酬。這種模式的好處是“衆人拾柴火焰高”，但是如果大家都隻來烤火，不去拾柴;或者撿到的柴火品質太差，最後火也就熄滅了。“社群” 并不意味着“随意”，一些成功的社群項目(例如開發和維護Linux作業系統的社群)，都有很嚴格的代碼複審和簽人的品質控制。
• (4) 業餘劇團模式( Amateur Theater Team )
  • 這樣的團隊在每個項目(劇目)中,不同的人會挑選不同的角色。在下一個劇目中，這些人也許會換個完全不同的角色類型。各人在團隊中聽從中央指揮(導演)的指導和安排。在學生實踐項目或教育訓練項目中，這樣的事情經常發生。
• (5) 秘密團隊 ( Skunk Work Team )
  • 一些軟體項目在秘密狀态下進行，别人不知道他們具體在做什麼。一個團隊的成員如果有很大的自由度，又有獨特的使命，這對于大家來說，是很大的驅動力。這樣的團隊往往能發揮超高的效率完成看似不可能的任務。
• (6) 特工團隊( SWAT )
  • 就像電影電視中的特工組“加裡森敢死隊”等一樣，軟體行業的一些團隊由一些有特殊技能的專業人士組成，負責解決一些棘手而有緊迫性的問題。例如2000年之前，很多公司都需要專業人士去解決Y2K問題s。這些團隊成員必須了解傳統語言和老式系統，才能勝任這樣的任務。現在還有一些專門做網站安全性服務的團隊，也屬于這一類型。
• (7) 交響樂團模式 ( Orchestra )
  • 家夥多, 門類齊全。
  • 各司其職， 各自有專門場地，演奏期間沒有聊天.走動等現象。
  • 演奏都靠譜， 同時看指揮的。
  • 演奏的都是練習過多次的曲目,重在執行。
• (8) 爵士樂模式( Jazz Band )
  • 不靠譜。他們演奏時都沒有譜子。
  • 沒有現場指揮，平時有編曲者協調和指導樂隊，
  • 也有模式
  • 人數較少。
• (9) 功能團隊模式 ( Feature Team )
  • 很多軟體公司的團隊最後都演變成功能團隊，簡而言之，就是具備不同能力的同僚們平等協作，共同完成溝通&協作一個功能。在這個功能完成之後，這些人又重新組織，和别的角色一起去完成下- -個功能。他們之間沒有管理和被管理的關系。大型軟體公司裡的不少團隊都是采用這種模式。這些功能小組也稱為Feature Crew.
• (10) 官僚模式( Bureaucratic Model)
  • 還有一個團隊模式可以叫作官僚模式。這種模式脫胎于大機構的組織架構，幾個人報告給一個小頭目，幾個小頭目報告給中頭目，依次而上。這種模式在軟體開發中會出問題。因為成員之間不光有技術方面的合作和上司,同時還混進了組織上的上司和被上司關系。

3、結合理論課學習内容了解瀑布模型及其變形、漸進傳遞流程、靈活流程等典型軟體過程模型特點

• 瀑布模型由溫斯頓.羅伊斯首先提出，其優點是容易管理，缺點是開發過程逆轉代價大、脫離實際、現代客戶難以明确需求，該模型對需求大依賴、效果後期才可現、回報少、測試集中在後期、需求不明确時難以進行。适用範圍為：需求明确的項目、低風險項目、面向過程。
• 瀑布模型的各種變形有：生魚片模型、大瀑布帶着小瀑布模型,如下所示：

• 漸進傳遞流程：由史蒂夫.邁克康爾在1996年提出，主要形式如下：

• 靈活流程：靈活開發以使用者的需求進化為核心，采用疊代、循序漸進的方法進行軟體開發。其特點是：
  • 快速疊代
  • 讓測試人員和開發者參與需求讨論。
  • 可以工作的軟體勝過面面俱到的文檔
  • 客戶合作勝過合同談判
  • 響應變化勝過遵循計劃

4、了解并體會卡内基梅隆大學（CMU）軟體工程學院總結的TSP原則

Team Software Process (TSP )的原則主要有以下7個:

• (1) 使用妥善定義的流程，流程中的每一步都是可以重複、可以衡量結果的。
• (2) 團隊的各個成員對團隊的目标、角色、産品都有統一的了解。
• (3) 盡量使用成熟的技術和做法。
• (4) 盡量多地收集資料(也包括對團隊不利的資料),并用資料來幫助團隊做出理性的決定。
• (5) 制定切合實際的計劃和承諾，團隊計劃要由負責具體執行的的角色來制定(而不是從
• (6) 增加團隊的自我管理能力。
• (7) 專注于提高品質，争取在軟體生命周期的早期發現問題。最有效提高品質的辦法是做全面而細緻的設計工作(而不是在後期匆忙修複問題)

截圖：

三、任務3：

在班級部落格園，有很多高校的軟體工程課程要求同學們完成團隊項目，請與實驗三結對夥伴協商，在以下三個班級中選擇一個高品質的團隊項目案例進行協作學習，要求追蹤該團隊項目釋出所有部落格作業，下載下傳項目軟體代碼。

1. 2016級計算機科學與工程學院軟體工程 (西北師範大學)
2. 2019秋福大軟體工程實踐Z班 (福州大學)
3. 2019春季計算機學院軟體工程 (北京航空航天大學)

1、團隊項目作業釋出賬号連結: 點這裡

2、團隊項目倉庫github連結:點這裡(可以在各個分支下面檢視)

3、陳述你選擇該團隊項目進行分析的理由；

• 我們小組選擇的是2019春季計算機學院軟體工程 (北京航空航天大學)水哥小組，選擇原因是它主要開發的是小程式，而小程式最大的優勢就是用微信掃描就可以檢視和使用，比一般的系統好用。
• 這一款小程式對我們大學生很有用，很多大學生都想參加比賽，但是找不到合适的隊友，想找實習工作，但是也是無處下手，浪費了很多寶貴的時間，而此款小程式，提供分類浏覽和關鍵搜尋功能，支援上傳圖檔，随時可以修該履歷，可以說使用十分友善，尤其是對大學生來說很有價值。
• 最後一點原因就是，我們想體驗一下我們和其他學校學生之間的差距有多大。

4、結合項目系列部落格文檔，總結項目團隊成員的分工合作情況

• Beta階段分工如下：

  

• Gamma階段分工和貢獻如下：

  

5、結合項目系列部落格文檔，評價項目的軟體項目過程特點（TSP）

通過閱讀項目系列部落格文檔，發現利用使用者回報進行改正是提升品質的最快最好方法；在長時間固定每位成員的職責後，能一定程度促進成員自覺，甚至提前完成任務；

将設計與實作工作分離是提升效率及工作完成品質的重要步驟；功能越多、越友善接入使用者的平台，往往審查條件越嚴格，留出足夠的緩沖時間以防萬一非常重要。

• 針對TSP原則的第二點：“團隊的各個成員對團隊的目标、角色、産品都有統一的了解”，該團隊做的很好，而且召開多次會議，明确産品需求，由這篇部落格可以看出來；
• 針對TSP原則的第四點：“盡量多地收集資料(也包括對團隊不利的資料),并用資料來幫助團隊做出理性的決定”，該團隊進行了很多資料測試，比如軟體的抗壓能力，各種手機運作的不同狀況，由這篇部落格可以看出來；
• 針對TSP原則的第六點：“增強團隊的自我管理能力”，該團隊也做的很好，他們明确分工，各司其職，這極大的提高了團隊效率。

6、觀察該團隊項目github倉庫的源代碼檔案結構，是否包含代碼規範文檔？

主要結構如下：具體代碼部分，在相應的分支front_end,back_end裡面，從下面截圖可以看出，對資料庫部分有相關的規範，具體代碼部分似乎沒有相應的代碼規範。

7、下載下傳團隊項目代碼，嘗試部署項目運作環境并使用軟體，描述最簡單直覺的使用體驗，找出至少兩個比較嚴重的功能性bug，在部落格中展示截圖；

具體環境部署如下：

• 安裝python3和pip3：

  apt update

  apt install python3

  apt install python3-pip

  

• 安裝Django：用pip3 install django指令安裝
• 下載下傳代碼

  

使用體驗：由于是小程式，使用起來很友善，微信掃碼就可以登陸并使用，界面也良好，在小程式底下有菜單欄，友善導航，而且有搜尋功能，但是也有很多的問題，比如有時候會連接配接不到伺服器，導緻小程式的部分功能無法使用，

• 首頁

  

• 競賽組隊：

  

BUG列舉：

bug1：在個人中心沒有消息提醒功能，假如使用者收到邀請，可能無法及時檢視

bug2：該小程式的使用還不是友善，如果伺服器沒有打開，在手機上就不能正常使用，例如要修改個人資料，點選确定修改，沒有反應

• 修改前：

  

• 修改後：點選确定按鈕，沒有反應

  

8、評價該團隊項目是否值得繼續開發，并陳述理由？

該團隊項目值得繼續開發，原因有：

• (1)首先，該團隊項目立意很好，貼合大學生的實際需要，如果開發好，将造福一批大學生。
• (2)其次，采用的技術也是很先進的python程式設計，python語言近幾年比較火爆。
• (3)相比于傳統的APP，小程式更讨喜一些，它不用占用很大的記憶體空間，而且使用友善。
• (4)此外，大學生是一個龐大的群體，如果投入使用，一定會有一個很好的下載下傳量。
• (5)該項目可以進一步延申為網站等等。

四、任務4

1、記錄完成《實驗四 軟體項目案例分析》各項任務實際花費的時間；

任務	預計花費時間(h)	實際花費時間(h)
總計	35.2	42.2
任務1	16	18
任務2	4
任務3	15	20
任務4	0.2

2、請談談完成本次作業的感受和體會。

做完本次作業，體會良多，首先，在運作别人的代碼的時候，很容易出現問題，起初，以為是别人的問題，後面和合作夥伴讨論發現，是自己的問題，比如别人資料庫用的是Sql server，而我們用的是Mysql，于是自己建立了資料庫，運作時候要修改有關資料庫連接配接的部分，才能正常運作程式，之後，如何任務三也是困難重重，首先是環境的搭建，要下載下傳虛拟機，下載下傳linux系統，下載下傳python運作環境等等，雖然過程艱辛，但是也學到了很多。感覺各個大學高手如雲啊，大家都很優秀，我們還是得繼續努力。