團隊項目用戶驗收評審

一.關於源代碼管理的10 個問題：

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

我們的項目都在github上面，用的win10系統，並且我們的文件沒有鎖定。

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

git pull進行更新後，可以看到本地的版本和最新的版本之間的不同之處。同時，在本地上傳自己的文件到分支之後也可以查看自己或者是別人上傳的文件在以前的版本的基礎上，修改了哪些地方。

點開項目的commit的記錄，點擊相應的SHA版本哈希值之後可以進入到如下的頁面

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

Git可以方便地對有簡單不同的修改進行合並，但對於有邏輯沖突的部分將會給出conflict的提示，這時需要手工修改針對文件的不同狀態（modified、untrack、conflict等）給出不同的顏色提示。

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

在Git中，所有在本地倉庫中修改的文件都要統一經過commit為新的本地版本後，再push至遠程分支。這保障了本地修改提交的原子性，同時git服務器遠程提供的修改操作也具有原子性。這樣就保障了整體修改的原子性。

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

沒有遇到過。但是分支應該是解決這一問題的有效方法。在對文件修改之前建立分支並在這個分支上進行功能的修改，如果遇到BUG，則在主分支上再建立一個新的分支，最後當這兩個分支都完成之後把它們合並到主分支當中去 。

6.規範操作和自動化你的團隊規定開發者簽入的時候要做這些事情：

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

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

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

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

沒有

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

在master上建立分支，每一段修改都進行交付。將不需要的修改的地方刪除。在master上建立分支，找歷史交付版本，將其下載到本地，需要哪個版本都可以進行安裝，繼而重現用戶報告的問題。

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

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

之前代碼在本質是一步步完善過程中的，基本上每一次代碼提交都會添加一小部分功能模塊。在穩定性上來說沒有什麽太大的體會，並沒有出現很不穩定這種的版本。就算出現了這種版本，一般也是代碼處理上的錯誤，通常是不會選擇提交，而是會改進後提交的。

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

源代碼和測試這些代碼的單元測試，以及其他測試腳本沒有放在一起的，因為這樣更方面進行處理。 至於測試的更新方面，會放到之後再進行更新，優先度來說沒有那麽高。 提交之前會進行簡單的測試，不會將每部分功能每個方法都充分測試。

二.項目文檔

1) 開發總結文檔

2) 需求文檔

3) 設計文檔

4) 測試文檔

5) 實施文檔

6) 過程文檔

已上傳至GitHub倉庫，github地址：https://github.com/yhy618/A

三.項目驗收過程:

1.項目匯報

　　由老師擔任主持人，組長上臺進行PPT講解，匯報本項目的項目背景、開發過程、功能簡介、工作總結，並對本系統進行演示，在此同時，老師根據項目講解情況、項目完成度對本項目進行評分。

2.項目驗收

　　在此之間，我們已整理好開發總結文檔、需求文檔、設計文檔、系統測試文檔、實施文檔、會議記錄、項目總結文檔等重要文檔，完成項目軟件系統演示前準備工作，並準備好項目驗收意見表、驗收會議名單及驗收會議議程。

　　本次項目驗收會議成員為《F4+2》團隊和本團隊的全體成員，先有我們團隊做工作匯報和總結，接著，本團隊主要技術人員進行系統實現過程簡述和系統演示，接著由《F4+2》團隊進行提問，本項目成員解答，最後由《F4+2》團隊的組長填寫項目驗收意見表，驗收項主要包括系統安裝和運行、系統功能以及系統開發文檔。

3.團隊照片

四.音樂播放器視頻展示

網址鏈接：https://v.youku.com/v_show/id_XMzY5NzU2OTQ3Ng==.html?spm=a2h3j.8428770.3416059.1

五.成員分工

六.成員心得與總結

楊環宇：在本學期軟件工程團隊項目任務中，我主要負責團隊項目後臺程序編碼部分，並且在前期的任務中也承擔了撰寫文檔，整理博客的任務，在這一階段鍛煉了自己的文檔撰寫能力，熟練使用了大學期間學到的知識，學會了各種工具的使用比如Visio、process on、墨刀、石墨文檔等工具，方便了今後的學習。而且在編程中我也提高了我的開發能力，每一階段的任務都讓我有提高，團隊合作也提高了我們小組的每一位成員。忙碌了一學期，同時我也收獲挺多。

馬軍：這次這個項目讓我懂得了很多,之前學的一些東西，在這次項目中應用到了，發現基礎知識很欠缺，平時做的練習也比較少。但重要的是這次學習到了團隊精神,在做這次項目我們組齊心協力,分工明確,這才真正讓我們了解到團隊的真正意義。當然我們的能力畢竟是有限的,當我們遇到瓶頸的時候老師的悉心教導給了我們做下去的動力。他還叫我們基礎知識,讓我們看到了基礎知識的重要性，使我收益很多，對我以後得開發會帶來很多幫助！

龔繼恒：在這次的項目開發的過程中，我們小組合作完成了項目。在實驗的過程中，我們分工明確，能夠井然有序的完成各自的任務。在項目開始前，我們先對此進行了可行性分析以及需求調研，使得項目開發的目標更加明確，有助於我們後期各部分功能的完善。通過這次項目開發，我認識到要完成一個好的項目，良好的團隊合作是非常重要的，遇到問題時解決問題的思路和時間會很大幅度的減少，經過六個人的討論會對問題理解的更透徹，效率更高，當遇到困難時，大家齊心協力，各顯神通，一起解決困難，這不僅節約了很多時間，也可以找到更好的解決方案。所以說團隊合作還是很有必要的。一個成功的項目後面往往有一個優秀的團隊。

龍正圓：本次軟件工程，通過完成一個音樂播放器的實現，第一次系統的完整按照軟件開發流程去做，其中收獲了很多，同時這也是第一次與其他小夥伴一起共同完成項目，有時候進步是在不知不覺中做東西來提高的，音樂播放器看似簡單，其實還是有難度的，比較考驗人的思維邏輯能力，我在這次實驗中學到了很多知識，收益非淺．通過幾個月的實驗，基本掌握了Android應用程序開發的一般流程。對常用控件基本掌握其用法，對其事件的監聽方法也基本掌握。學習Android不僅是對前沿開發技術的了解，也是對編程知識的一次提升。

紀亞星：轉眼間就到了期末，回想這學期參加軟件項目的過程, 從開始的組隊尋找課題到撰寫項目開題報告,到設置問卷調查確定項目用戶需求, 確定實驗項目、實施方案與尋找創新點; 並制定詳細的研究方案和步驟;對項目進行相關調查和研究;到最後確定項目的可行性，一步步走來，其中的經驗與成長也只有經歷過的人才會分享和擁有。這是一次難得經歷，一次讓我得到鍛煉得到成長的經歷。在這幾個月中，組員間相互學習，這對於我們每一個來說無疑是最值得珍藏的，這種為同一目標共同奮鬥的團結氛圍特別讓人有歸宿感。也特別感謝老師和助教長期以來的指導和幫助！

侯燕：通過這次項目開發，使我深刻體會到了軟件工程的巨大作用，從最初的軟件設想到現在的項目實現經過了很長的時間，我們小組精誠合作完成了項目，每個過程我們都對所做的部分進行了詳細的分析，從最初的軟件設想到現在的編碼實現經歷了漫長的過程，這其中我們花了很長的時間來做設計和建模，這個過程看似不重要，但確為軟件最終的成功奠定了基礎，沒有前期的工作後面編碼將出現很大的問題。還有古人雲，磨刀不誤砍柴工。前期的知識儲備、文獻儲備、材料準備、方法準備能夠避免手忙腳亂，充分的預實驗可以使我們充滿信心。一步一個腳印，在最後的綜合實驗中，我更是受益匪淺。完整的做出了一個基於安卓開發的音樂播放器，雖然功能不是太完善。但是這是整個團隊一起努力的結晶。

總結：

一學期結束了，此次項目開發的過程，我們嚴格按照老師的要求，從開始的時候根據小組自身的能力確定項目的開發方向，項目需求的調查與分析，還有之後的項目軟件設計方案的設定與書寫，以及之後不斷地去完善項目設計方案書，不斷的叠代完善，雖然這期間花費大量的時間，但這也是軟件工程的特點，它完美的將軟件研發規範化，它為我們的開發提供了保障，在充分的項目方案設計的完善過程中，可以避免平時一邊想一邊做所出現的弊端，也可在一定程度上減少研發的時間。這樣使得團隊開發的效率提高了好多。團隊之間分工明確，減少了不必要的問題，效率大大提高了。團隊合作完成一個實驗開發項目的作用是很大的。

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