《對不隊》團隊項目用戶驗收評審

任務1：團隊作業Beta沖刺

• Beta沖刺第一天：https://www.cnblogs.com/bingoF6/p/9221744.html
• Beta沖刺第二天：https://www.cnblogs.com/bingoF6/p/9226305.html
• Beta沖刺第三天：https://www.cnblogs.com/bingoF6/p/9230815.html
• Beta沖刺第四天：https://www.cnblogs.com/bingoF6/p/9235917.html

?

任務2：源代碼管理的10 個問題

?1.你的團隊的源代碼控制在哪里？用的是什么系統？如何處理文件的鎖定問題？

團隊項目在Github上托管，采用git的方式進行版本控制，這個是我們在開發伊始就達成的共識，針對這種多人多任務的開發模式，我們認為git是再好不過的選擇，于是我們從開發到現在一直采用這種方式；團隊的在處理文件的鎖定問題上是不加鎖的，也就是說我們的成員可以自由遷入遷出。由于現階段的開發規模比較小，于是為了最大化效率，我們沒有對文件遷入遷出進行過多的限制。將文件在遷入遷出時加鎖，顯然可以保證源代碼修改的同步性，減少不必要的沖突和錯誤，但是這樣的缺點是顯而易見的，由于缺乏了并行性，項目開發的效率就被極大地降低了，極端情況下很有可能因為一個人的失誤，導致全隊項目的擱淺。反之，我們采用自由遷入遷出（用鄒欣老師的話來講，就是“寬松的政策”）的方式，則與前者的優缺點互反了

2.如何看到這個文件和之前版本的差異？ 如何看到代碼修改和工作項 （work item），缺陷修復 （bug fix) 的關系。

git pull進行更新后，可以看到本地的版本和最新的版本之間的不同之處

同時，在本地上傳自己的文件到分支之后也可以查看自己或者是別人上傳的文件在以前的版本的基礎上，修改了哪些地方

我們在上面圖片里面可以看到的是"+"標注的是在原文件的基礎上增加的代碼的記錄，"-"標注的是在原文件的基礎上刪掉的代碼的部分，顏色顯示也不同。其實我們團隊是以任務為單位和模塊進行的開發，這種開發模式在任務分配之處就已經給該任務提供了描述

3. 如果某個文件在你簽出之后已經被別人修改，并且簽入了，那么你在簽入你的修改的時候， 如何合并不同的修改（merge)? 你用了什么工具來幫助你？

在git中執行合并即可自動合并Git修改的部分。但是，也存在無法自動合并的情況。如果在遠程數據庫和本地數據庫的同一個地方都發生了修改的情況下，因為無法自動判斷要選用哪一個修改，所以就會發生沖突。

git會顯示本地數據庫和遠程數據庫同一個地方的不同修改，這時候就需要我們手動解決沖突，暫時沒有想到什么好的工具可以解決不借助人力自動解決這個問題，只能依據規定和協商解決這一問題。

4. 你有20個文件都是關于同一個功能的修改，你要如何保證這些文件都同時簽入成功（修改的原子性），或者同時簽入不成功？

?git作為一個成熟的源代碼版本管理系統本身就可以保證在簽入時的原子性，所以在我們的項目開發流程中沒有遇到部分修改可以上傳而某些部分的修改不能上傳的混亂狀態。

5. 你的PC 上有關于三個功能的修改， 但是都沒有完成，有很多文件處于半完工的狀態，這時你要緊急修改一個新的 bug，如何把本地修改放一邊，保證在干凈的環境中修改這個 bug, 并成功地簽入你的修改 --- changelist management。

這個時候我們只要在本地新建一個分支，然后在新的分支上進行bug的修復就好。當前分支的內容就被保存在原地。這樣我們就可以在“干凈”的環境中進行bug的修復工作了。

6. 規范操作和自動化

你的團隊規定開發者簽入的時候要做這些事情：

????- 運行單元測試，相關的代碼質量測試。

????- 代碼復審 （要有別的員工的名字）

????- 和這次簽入相關的issue 編號， 任務/task， 缺陷/bug 編號，等等， 以備查詢。

????請問你的團隊有這樣的自動化工具讓開發者方便地一次性填入所有信息然后提交么？ ?（高級功能， 代碼提交之后， 相關bug 的狀態會改動為 ?“fixed”， 并且有鏈接指向這次簽入。）

答：我們團隊沒有使用這樣的工具，我們在開發之前對編碼做了規范，進行完單元測試后，將沒有bug的代碼提交Github。

?7. 如何給你的源代碼建立分支？

? ?上傳一個與MASTER相關的分支（該分支是從MASTER中git clone 得到，相關信息在 .git 文件中）

????修改后源碼后，在進行如下操作

1、git add .

2、git commit -m "test" ?（”test“為分支名）

3、git branch test（創建分支）

4、git checkout ?test （切換分支）

5、git push origin test:test

8. 一個源文件，如何知道它的每一行都是什么時候簽入的，為了什么目的簽入的 （解決了哪個任務，或者哪個bug）？

對于我們團隊來講每一次任務都有明確的分工，也就是提前打上標簽，每個成員在commit的記錄保留，github上面有每一次的每一個人的提交的記錄。

?

9. 如何給一個系統的所有源文件都打上標簽，這樣別人可以同步所有有這個標簽的文件版本？

代碼每天都在變， 有時質量變好，有時變差，我們需要一個 Last Known Good （最后穩定的好版本） 版本， 這樣新員工就可以同步這個版本， 我們如果需要發布，也是從這個版本開始。 ?那么如何標記這個 Last Known Good 版本呢？

?答：我們對沒一次的系統文件都有相應的注釋，即在這個版本中，我們新添加的內容，和對之前的內容修改地方，我們在GitHub提交的時候都做了詳細的說明。我們可以根據這些說明來確定各個版本。

10. 你的項目的源代碼和測試這些代碼的單元測試，以及其他測試腳本都是放在一起的么？ 修改源代碼會確保相應的測試也更新么？你的團隊是否能部署自動構建的任務？

???答：這些文件是放在一起的，項目的單元測試完成后，對與測試腳本都會提交到GitHub上，并有詳細說明，修改源程序后相應的測試文件也會及時更新。

?

任務3：驗收準備文檔

項目驗收準備內容?

1.文檔準備：

1) ?開發總結文檔

2) ? 需求文檔：包括需求規格說明書，需求變更文檔等

3) ? 設計文檔：包括概要設計，詳細設計，數據庫設計等

4) ? 測試文檔：包括測試方案，內部測試報告，第三方測試報告等

5) ? 實施文檔：包括實施，部署方案，用戶手冊，維護手冊等

6) ? 過程文檔：包括項目周報，會議紀要等

2.項目概況ppt準備

項目概況ppt包括以下幾個部分：?

1) 項目背景和簡介

2) 合同執行情況匯報

3)開發過程：記錄項目開發過程中的一些重要事件

4) 系統功能簡介

5)項目應用成果展望

文檔Github倉庫鏈接：https://github.com/RNTF6/web

?代碼Github倉庫鏈接：https://github.com/RNTF6/meeting-web

團隊代碼貢獻：

?

?任務4：項目驗收過程

第一階段：老師擔任主持人，項目組長或主要技術人員進行PPT回報演示，匯報本項目的項目背景、開發過程、功能簡介、工作總結，并對本系統進行演示，由老師和其他同學對本項目進行提問，該團隊成員進行解答，在此同時，老師根據項目講解情況、項目完成度以及答疑情況對本項目進行評分。

第二階段：確定結對項目組是Blue Flke，由項目組長擔任主持人，結對項目組成員項目甲方，對本項目的成果進行驗收，首先項目組主要技術人員對所開發的系統進行演示，并就主要的功能進行講解，由Blue Flke成員進行提問和驗收，最終由Blue Flke團隊組長填寫項目驗收意見表。

?

?任務5：

• 團隊成員的具體分工、占整個實驗任務的工作量比例及完成各自任務的實際時間

?人員	具體任務	工作量比例	完成時間?
王 爽	?Beta沖刺二、文檔的整理與完善、團隊項目用戶驗收評審博文的撰寫	?18%	?6h
馮 曉	撰寫系統用戶手冊、制作PPT、系統演示	?17%	?5h
彭 輝	Beta沖刺三、項目軟件系統演示前準備工作	?17%	?6h
吳 瓊	?Beta沖刺一 、撰寫測試文檔	?16%	?5h
郝延婷	系統測試報告的撰寫、文檔整理	?16%	?5h
馬思遠	Beta沖刺三、編制項目驗收意見表	?16%	?4h

• 本次實驗的場景照片

? ? ? ? ? ?

?

• 各成員心得體會?
• 郝延婷：本次實驗我的任務分工是進行系統測試，覺得對一個完成的系統進行測試這一步驟是非常有必要的，會及時的發現系統中存在的漏洞或不足，在交付給用戶前可以加以改進，提高系統性能；還有就是要對每一次的測試過程做詳細的記錄，以便于總結經驗；最后是測試用例的選擇問題也是非常重要的，要全面，精準的發現更多的系統運行過程中邏輯問題。?
• 彭輝：轉眼間，一學期的軟件工程的課程接近了尾聲，回想起這一學期關于軟件工程的學習，感覺收獲頗多。從最開始對軟件工程一無所知到現在深深的喜歡上了這門課的學習，老師的翻轉課堂的教學模式，讓我們不但在理論上掌握軟件工程，而且還有很多的實例實驗，讓理論和實踐很好的結合，在我看來，軟件工程與其說是一門課程，不如說是一種思想，是一個如何去分析和處理問題的過程。在老師的和助教老師的孜孜不倦的幫助下，我能夠及時的改正自己的錯誤與不足。在完成我們團隊項目“會議管理系統”中，從最開始的問卷調查，用戶需求的分析，到《軟件需求規格說明書》，到基于墨刀的原型系統的實現再到項目的系統改進，最后到系統的實現，這一路走來，每一步都走的不容易，期間也遇到了很多的問題，例如最開始的時候，用戶需求分析團隊成員的意見出現了分歧，為此我們再次調查了更多的用戶后，小組經過認真討論后達成一致，正是我們在前期的充分調研，才使的我們在后面的具體實現工程中游刃有余，在預期的時間內完成我們的項目。這也是我更加深刻的理解到軟件工程的想。在代碼實現的過程中，我主要負責的是會議內容管理部分的實現。當然，實現工程也不是一帆風順，在會議欄目編輯富文本框實現的時候，就遇到了麻煩，之前沒有接觸到，所以不知道如何去實現，在我不知所措的時候，我們的團隊成員馮曉同學，挺身而出，在他的幫助下，我順利的完成了我的任務。團隊項目的實現除了學習更多的新知識外，我覺得更重要的是團隊成員的相互合作，相互配合。這接下來的時間，我們會更加完善我們的項目。
• 馬思遠：一個學期的軟件工程課即將接近尾聲，在這一學期的軟件工程課里面，我深切體會到了團隊合作的重要性，怎么磨合團隊，怎么分工等等，都是我們在別的課程里面沒有學到的。軟件工程這門課大大的規范了我們的編碼。同時也告訴我們軟件是工程，工程意味著一個人是完成不了的，大家要通力合作才能完成任務。因為自身的編程能力不是很強，所以有些時候分配給我的任務都不能按時完成，但是大家都沒有催我反而是給我講解要怎么弄該怎么改，有時候遇到問題問團隊成員他們也非常愿意解答。感謝小伙伴的悉心幫助。
• 馮曉：持續一個學期的軟件工程課程告上了一個段落，在學期的結尾，回望這學期的課程，想起那些和團隊一起奮斗的日日夜夜，收獲和感想太多，想說的也很多。一開始我以為軟件工程就是編寫代碼做出一款軟件，直到這門課的開設，我才真正了解到軟件工程是一項工程，工程就意味著要有團隊合作，要有效率體現，要有人員分配，要有人員管理，要有維護維修，要有安全監測，要有推銷。它涉及的是很多流程和環節，面臨的是用戶的體驗和需求，投向的是市場。這些都是從這門課的學習中所體會到的。軟件工程課很新穎，因為課程的學習中摻雜了不少從課本上學習不到的知識，我覺得更多的是素養和習慣。我曾思考老師為什么沒有簡單教我們如何編程，如何做框架，如何解決編程語言以及語法的一些問題，而卻是讓首先讓我們去做，然后再去講一些軟件工程流程，軟件工程開發的注意事項意見軟件工程開發的方法。現在也明白了其中的一些道理，如果我們只去學習開發，提高的只是編程能力，提高不了大腦的思考能力以及開發水平和更高的素養。這門課程老師還引入了《構建之法》這本書，結合本書和課本的學習使我們對傳統軟件工程和現代軟件工程的學習進一步結合起來。課程還采用了項目推進學習的實踐活動，通過工程實踐和博客文檔的書寫進一步加強實戰性，提升我們軟件開發的綜合實力。最后感謝代老師和鄒欣老師及助教老師對這門課程的辛勤付出，感謝我們團隊其他成員對我的幫助。這學期下來收獲滿滿，謝謝大家。
• 吳瓊：
  這個學期的軟件工程課告了一個段落，從個人博客到結對編程再到團隊任務，一步一個腳印走過來，感覺收獲頗多。這么課程學習地很艱辛，因為任務繁多，但自己也從一個小白逐漸對一個項目的完成過程有所了解，對于Java編程，也不像以前那樣一有任務就聞風喪膽，自己在這個過程中也知道了團隊協作的重要性，學會了在項目完成的過程中如何拒絕團隊之間的矛盾和問題。最后，謝謝代老師以及助教們的辛勤付出。
• 項目組長總結
• 曾經以為程序就是軟件，軟件就是程序。學習這門課程第一個收獲是，知道了二者的不同之處。經過老師的講解，理解了軟件工程，就是一套用于軟件的團隊開發，以提高軟件質量和程序員工作效率為目的的規范。其核心就是，對于軟件開發的重要組成部分：需求分析，設計，編碼，調試，維護，如何組織這5個部分的工作，以及如何完成每一個工作。吾生也有涯，而知也無涯，學習永無止境。起初，對軟件工程處于一知半解的狀態，分工比較混亂。在劃分模塊后明確了各自分工，漸漸形成良性循環。在學習過程中，知道了團隊合作十分重要，爭議固然存在，但通過討論、協商，能夠達成一致與默契。團隊成員每個人都很努力與認真，正是大家的相互合作，才使得我們的項目更加完善，還有老師們的幫助與指導，讓我們及時發現問題，解決問題。