1、作業概述

作業gitee鏈接

2、成員信息

3、擬作的團隊項目描述：基于知識圖譜的醫療問答機器人

4、事后諸葛亮分析報告

一、設想和目標
1、我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？

解決不同用戶人群對醫療問題的咨詢。定義清楚。對典型用戶和典型場景的清晰描述如下：

面向學齡兒童，由于人口老齡化趨勢導致年輕人的壓力增大，越來越多的年輕人選擇外出打拼，將孩子交給祖輩看護，但是祖輩的科學知識并不充裕，存在很多封建土方，比如孩子發燒通過厚被悶汗出熱治病，但是這其實沒有任何正效應，甚至可能導致加重發燒，需要一個準確的醫療診斷機器人，避免因誤判或過晚發現身體上的異常，容易造成不可估量的無法挽回后果

面向青年群體，青年身體有異常習慣通過挺兩天嘗試自愈，但是并非每種情況都可以靠身體自愈，而且為了方便，通常選擇網絡查病，但例如百度，經常隨便一問都是癌癥征兆或者晚期，不僅沒實際效果，而且會導致心理焦慮，需要一個即時的醫療咨詢機器人，及時保障自身健康

面對中老年群體，他們的記憶力下降，容易忘記藥物的服用時間和劑量頻率，需要一個便捷的醫療問答機器人，防止影響治療效果

2、我們達到目標了么（原計劃的功能做到了幾個？按照原計劃交付時間交付了么？原計劃達到的用戶數量達到了么？）

達到目標了。原計劃的功能有實體識別、關系抽取、數據導入、實體規范化、意圖識別、對話機器人、多輪對話，均實現了。按原計劃交付時間交付了。為了進一步提高用戶的使用體驗，我們推出的是微信端，即通過添加我們的機器人微信號，直接聊天咨詢，因為推廣效果不佳，僅達到預期的第一階段用戶數量（25）

3、和上一個階段相比，團隊軟件工程的質量提高了么？在什么地方有提高，具體提高了多少，如何衡量的？

提高了，我們進一步優化了模型代碼，找了更多的數據集進行訓練，讓機器人識別用戶的輸入識別得更加精準，提高了大約12%，衡量方法為觀察優化前后同樣輸入識別正確的頻率。

4、用戶量，用戶對重要功能的接受程度和我們事先的預想一致么？我們離目標更近了么？

用戶對功能的接受程度與我們事先的預想存在較小的差別，主要在于不同人群用戶使用我們項目的目的與我們的預期不同，呈現混合情況，即不同人群詢問內容差別不大。因為得出了真實的使用情況，所以我們得到了優化進步的機會，離目標更近了

5、有什么經驗教訓？如果歷史重來一遍，我們會做什么改進？

如果重來一遍，提前加設一次調研，充分調查用戶如果使用我們的項目，會是什么目的，確保主要思路不偏

二、計劃
1、是否有充足的時間來做計劃？

有，每周制定計劃的時間均為周一早晨，早晨時間充足，且思考較為理性

2、團隊在計劃階段是如何解決同事們對于計劃的不同意見的？

通過投票表決，少數服從多數，但可以提出強烈建議，讓計劃進行重新討論

3、你原計劃的工作是否最后都做完了？如果有沒做完的，為什么？

原計劃的工作絕大部分都已實現，實現了機器人的version1本地端和version2微信端，但還有version3網頁端正在進行最后的調試，因為涉及到項目過大，需要服務器具有更多的運行內存，正常租借的阿里云服務器只有2G運行內容，這是不夠用的

4、有沒有發現你做了一些事后看來沒必要或沒多大價值的事？

有，比如我會因為強迫癥，反復修改自己編寫的代碼，包括代碼里面的warning，但這些warning并不會對程序產生任何影響

5、是否每一項任務都有清楚定義和衡量的交付件？

有，項目的任務細分為每個模塊和每個version，模塊從選擇、數據集、訓練、優化、測試多個方面，都有具體的計劃和分配，所以每次交付都是確保質量的交付

6、是否項目的整個過程都按照計劃進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到？

項目的絕大部分過程都是按照計劃進行，出現的意外為項目過大，服務器運行內存不夠用，容易導致出現服務器卡死的風險，這個風險就是沒有估計到的，因為上傳服務器之前，運行測試都是在我的筆記本上進行的，而我買的是游戲本，所以配置完全足夠運行項目，因此忽略了服務器的承受能力

7、在計劃中有沒有留下緩沖區，緩沖區有作用么？

計劃中的緩沖區均設置在周末，因為周一至周五需要上課，項目推進受到一定的影響，所以緩沖區可以用來緩和成員的壓力，確保項目開發有條不紊的進行

8、將來的計劃會做什么修改？（例如：緩沖區的定義，加班）

將來的計劃會在任務的時間設定上做修改，因為已經進入了考試月，所以需要設置更多的換沖區，但是如果越過緩沖區還是沒完成任務，就需要在深夜進行加班

9、我們學到了什么？如果歷史重來一遍，我們會做什么改進？

如果重來一遍，應該拋開個人不良習慣，杜絕強迫癥，還因重新討論前端界面的開發，因為團隊中只有一名前端開發成員，團隊應該再多招一位前端開發人員

三、資源
1、我們有足夠的資源來完成各項任務么？

有，雖然過程中單個2G服務器不夠使用，但我們后面再加了另外一個2G的服務器，最終項目可以上線

2、各項任務所需的時間和其他資源是如何估計的，精度如何？

所需時間的估計都是根據任務的具體難度設定的，且參照當天課內作業的數量做微調。其他資源主要為硬件資源和數據資源，硬件資源充足，數據資源靠各搜索引擎獲取，精度均達一定程度，時間上確保了在原計劃時間完成，其他資源上確保了項目的可信度和響應速度

3、測試的時間，人力和軟件/硬件資源是否足夠？對于那些不需要編程的資源（美工設計/文案）是否低估難度？

人力資源足夠，因為我們團隊有5位成員，測試的時候都是一起測試，而測試所用軟件/硬件資源都是成員及成員周圍人的電子設備，因為做客戶端使用，所以資源充足。

對于那些不需要編程的資源確實有點低估難度，美工設計方面因為都是學習網絡上的優秀范例，沒有什么大問題，主要是文案（即博客撰寫），為了做到盡最大程度描述清楚本團隊的工作，所以都是投入了大量精力

4、你有沒有感到你做的事情可以讓別人來做（更有效率）？

其實還是有的，比如模塊的測試，我本身主要是開發人員，所以測試的時候容易思想偏向于我編程時的想法，測試效果往往不佳，影響團隊的測試進度，這可以讓其他成員來做

5、有什么經驗教訓？如果歷史重來一遍，我們會做什么改進？

如果重來一遍，租用更大運行內存的服務器，確保項目部署的硬件需求得到滿足，并進一步提高回復的響應速度

四、變更管理
1、每個相關的員工都及時知道了變更的消息？

是的，每次變更管理都會在gitee上發布issue，并在微信群復述，確保每個相關成員都及時知道

2、我們采用了什么辦法決定“推遲”和“必須實現”的功能？

在需要變更的時候，臨時讓所有人做出決定，票決是否進行計劃變更

3、項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么？

有，我們定義，當項目通過設定的16個不同配置的設備（6臺筆記本+10臺手機）的測試，實現在0.5s內回復本地端咨詢，在1s內回復微信端咨詢，就認為該項目已經足夠好，可以發布

4、對于可能的變更是否能制定應急計劃？

能，因為前面所提，變更都是根據票決得出的，所以在等待票決結果的時間段就可以利用起來制定應急計劃

5、員工是否能夠有效地處理意料之外的工作請求？

大致上可以有效地處理，主要是掛在服務器上運行時，因為項目比較大，在運行程序的時候，因為運行內存不夠的時候，會自動關掉neo4j，這個時候只需要再跟服務器建立一個連接，再次開啟neo4j數據庫，程序就可以正常運行

6、我們學到了什么？如果重來一遍，我們會做什么改進？

任務和更改的及時通知是非常重要的，如果重來一遍，會提前確保任務不需要修改，避免臨時的加改對項目開發進度的拖延

五、設計/實現
1、設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？

設計工作在確認選題后的一周內就完成，參與人員為全團隊成員，之后的開發任務都是按照設計內容進行，后續沒有出現較大的矛盾，所以是合適的時間，合適的人

2、設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？

有，比如設計界面的時候，因為選擇困難癥，難以做出決定，我們會選擇票決和投骰子，因為團隊總共五名成員，所以每次都可以得出決策結果

3、團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML，或者其他工具來幫助設計和實現？這些工具有效么？比較項目開始的UML文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新UML文檔？

運用了單元測試，在每個模塊開發完成之后，是用pycharm和VS studio進行單元測試，其他工具因為開發時間緊湊就沒有使用。UML文檔在一開始的設計工作就完成制定，因為設計工作前后持續了一周，且結合了全團隊成員的想法，所以在后期開發過程中沒有產生區別，沒有更新UML文檔

4、什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug？為什么我們在設計/開發的時候沒有想到這些情況？

多輪對話功能產生的Bug最多，因為多輪對話需要調用多個模塊，實體識別，意圖識別，對話緩存，特別是在對話緩存模塊，因為是使用json文件進行緩存信息，且意圖識別模塊使用所需，存放緩存時還得確保是指定模板形式

在發布之后沒有發現重要的bug

5、代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？

代碼復審是團隊成員交換審核其他人寫的代碼，確保代碼的可讀性和易讀性，同時執行代碼規范

6、我們學到了什么？如果重來一遍，我們會做什么改進？

如果重來一遍，應該多督促成員線下一起編程，這樣討論問題的效率可以得到大幅提升，歧義想法也可以及時探討

六、測試/發布
1、團隊是否有一個測試計劃？為什么沒有？

有，每項測試，測試數據均為100條，30%為測試人員結合自身生活生成，40%為網絡收集，30%為交叉測試人員生成，例如實體識別模塊，測試數據為“我昨天晚上腸胃炎犯了，而且頭痛”，實體識別模塊識別出“腸胃炎”疾病實體和“頭痛”癥狀實體，意圖識別模塊測試數據“你是機器人嗎”，模塊識別出這句話的意圖是閑聊意圖范圍中的isrobot，多輪對話模塊測試數據“心臟病是什么”->“那怎么治療呢”，模塊識別出“那怎么治療呢”的意圖是醫療咨詢范圍中的詢問治療方法，但對應槽位并沒有填充信息，于是繼承上一句對話的槽位信息，即做到了多輪對話

2、是否進行了正式的驗收測試？

團隊決定將項目上線后用戶的使用記錄作為驗收測試，確保我們的項目確實達到我們的目標，且測試結果更具客觀性

3、團隊是否有測試工具來幫助測試？很多團隊用大量低效率的手動測試，請提出改進計劃：至少一個方面的測試要用自動化的測試工具，自動化的測試結果報告，比較測試結果的差異，等等。

團隊的測試并沒有使用測試工具，因為每個模塊都是單獨的程序文件，所以我們測試時候是將數據集存入csv文件，編寫python腳本讀取數據集文件，然后輸入到模塊程序文件，來獲得測試結果，這其實也算半自動化的測試工具

4、團隊是如何測量并跟蹤軟件的效能（Performance）的？壓力測試（Stress Test）呢？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？

軟件的效能，主要從識別的準確度，回復的準確度以及回復的速度跟蹤測量。壓力測試使用jmeter進行測試，模擬大量用戶從終端同時登錄和同時與服務器發送消息，測試系統正常運行的極限。從結果看，這些測試工作的作用并不明顯，因為目前使用我們軟件的用戶量遠不及壓力測試的數量，應從實際出發，測試并加快響應速度，而不是一味的折磨服務器

5、在發布的過程中發現了哪些意外問題？

發布的過程中發現的問題主要在于原本的標識方法失效，該怎么標識用戶，最后查看服務器收到的請求，找出唯一標識，如微信端使用NickName進行標識

6、我們學到了什么？如果重來一遍，我們會做什么改進？

如果重來一遍，應該使用自動化的測試工具，而不是僅僅依靠測試腳本，因為測試腳本的編寫也是需要花費一定的時間，使用現成的測試工具可以更快的推進項目開發

七、團隊的角色，管理，合作
1、團隊的每個角色是如何確定的，是不是人盡其才？

團隊的角色初步由成員自身推薦，然后在開發的過程中，逐步細化項目所需的角色定位，最后票決產生，因為票決都是根據所有人的想法而來，而想法來自于開發過程中的觀察體會，所以做出的決定都是人盡其才

2、團隊成員之間有互相幫助么？

有，主要體現在模塊測試和模塊訓練的負責成員之間，以及前后端開發成員之間，出現問題時會在群里發問，然后成員之間幫助解答

3、當出現項目管理、合作方面的問題時，團隊成員如何解決問題？

當出現矛盾時，如前文所說，通過投票表決，少數服從多數，但可以提出強烈建議，讓計劃進行重新討論，確保最終得出的解決方法都是客觀最佳的

八、總結
1、你覺得團隊目前的狀態屬于CMM/CMMI中的哪個檔次？

處于CMMI中的等級四，定量管理級，因為團隊軟件開發過程可預測，開發過程得到測量和控制

2、你覺得團隊目前處于 萌芽/磨合/規范/創造 階段的哪一個階段？

團隊處于規范和創造之間，因為我們的項目創意已經確定和大致實現，成員之間關系也已經熟絡，之間相互幫助團結合作，共同推動項目開發，且各方面的想法均已統一，達到規范，正在向創造更多的內容而努力

3、你覺得團隊在這個里程碑相比前一個里程碑有什么改進？

我們比起前一個里程碑，實現了機器人version2微信端，讓我們的項目可以被開發成員外的人使用，且可以開始進行推廣，使用微信號作為項目的使用入口，受益于微信的受眾情程度，我們的項目推廣也更加方便，機器人version3網頁端目前正在進行最后的優化調整

4、你覺得目前最需要改進的一個方面是什么？

最需要改進的一個方面應該是，意圖識別的精確度，因為醫療咨詢能拿到的開源數據集實在是太少了，下一步應該與醫院達成合作，獲得醫院的數據集

5、對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例

整個開發過程保持每1-2天線下開會一次，確保信息互換及時

成員之間有問題會相互探討，因為宿舍離得比較近，必要的時候會直接串宿舍

6、代碼管理的質量具體應該如何提高？ 代碼復審和代碼規范的質量應該如何提高？

代碼編寫的規范要求每位成員都遵守，且保留一定的注釋，確保不同任務的成員之間不同任務的代碼可以看懂，增強代碼的易讀性

7、整個程序的架構如何具體提高？ 如何通過重構等方法提高質量，如何衡量質量的提高？

架構需要對整個項目都有比較深入的理解，從算法模型，到前后端框架

每次完成issue和每日任務的時候，將新模塊加入到程序中，就重構一次，確保一日一重構

質量的提高可以從程序運行的代碼覆蓋率，以及用戶的使用體驗衡量

8、其它軟件工具的應用，應該如何提高？

先通過搜索網絡上別人關于軟件工具的使用指導，學會基本操作之后，自己上手進行實操

9、項目管理有哪些具體的提高？

通過發布issue和群通知，每天制定一定的任務目標，周末作為緩沖區，確保每一小階段的目標都可以完成，同時也確保開發過程中遇到的問題，可以及時得到解決

10、項目跟蹤用戶數據方面，計劃要提高什么地方？例如你們是如何知道每日/周活躍用戶等數據的？

由于項目需要記錄用戶的對話緩存信息，用于多輪對話進行槽位繼承，所以我們本身就需要跟蹤用戶數據，我們會將用戶的對話信息以json文件進行記錄，并在本地創建備份。通過將緩存文件夾中的文件進行最后修改時間排序，對應時間就是每日/周活躍用戶

11、項目文檔的質量如何提高？

用組長進行編寫，對應任務的負責成員輔助編寫，確保文檔的正確性

12、對于人的領導和管理， 有什么具體可以改進的地方？

還需要多招一個前端開發成員來分擔一定的開發任務，這樣也能推進項目更快的開發

5、會議照片

6、貢獻分

7、改進建議總結

用戶調研：在未來的項目中，確保提前進行充分的用戶調研，以便更好地理解用戶需求和期望。這將有助于確保項目滿足用戶的實際需求。
自動化測試工具：考慮使用更多的自動化測試工具，以提高測試效率和準確性。這將有助于在不斷變化的項目中更快地發現潛在問題。
服務器資源規劃：為了避免服務器資源不足的問題，建議在項目開始時就考慮到服務器的容量需求，并在必要時增加服務器資源。這將確保項目在部署時不會受到硬件限制。
團隊協作和溝通： 你的團隊已經做得很好，繼續確保團隊成員之間的有效溝通和協作，以及任務的合理分配和追蹤。
前端開發人員：鑒于前端開發的重要性，確保團隊中有足夠的前端開發人員，以確保項目的前端開發進展順利。