1. 程式人生 > >實驗十二

實驗十二

站立會議 你們 height 開發者 做出 般的 情況 錯誤 周報

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

1. 你的團隊的源代碼控制在哪裏?用的是什麽系統?如何處理文件的鎖定問題?
答:我們團隊的源代碼在GitHub裏,所用的系統是win7,我們團隊的文件沒有鎖定。 2.如何看到這個文件和之前版本的差異?如何看到代碼修改和工作項(work item),缺陷修復(bug fix)的關系 回答:點開項目的commit的記錄,點擊相應的SHA版本哈希值之後可以進入到如下的頁面 技術分享圖片 3. 如果某個文件在你簽出之後已經被別人修改,並且簽入了,那麽你在簽入你的修改的時候, 如何合並不同的修該(merge)? 你用了什麽工具來幫助你? 答:這種情況我們一般的處理方式是備份本地自己開發的一份代碼,先把別人簽入的代碼更新到本地,然後在本地手動合並修改,用的工具是
BeyondCompar 4. 你有20個文件都是關於同一個功能的修改,你要如何保證這些文件都同時簽入成功(修改的原子性),或者同時簽入不成功? 答: 直接對工程文件進行整個的簽入掛起的更改 5. 你的PC 上有關於三個功能的修改, 但是都沒有完成,有很多文件處於半完工的狀態,這時你要緊急修改一個新的 bug,如何把本地修改放一邊,保證在幹凈的環境中修改這個 bug, 並成功地簽入你的修改 --- changelist management 答:自己將這些文件或者是功能塊註釋,之後再修改bug 6. 規範操作和自動化 你的團隊規定開發者簽入的時候要做這些事情: - 運行單元測試,相關的代碼質量測試。
- 代碼復審 (要有別的員工的名字) - 和這次簽入相關的issue 編號, 任務/task, 缺陷/bug 編號,等等, 以備查詢。 請問你的團隊有這樣的自動化工具讓開發者方便地一次性填入所有信息然後提交麽? (高級功能, 代碼提交之後, 相關bug 的狀態會改動為 “fixed”, 並且有鏈接指向這次簽入。) 答:沒有 7. 如何給你的源代碼建立分支?

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

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

答:每一次操作都是顯示在時間軸上的,也可以自己來查看標記。

9. 如何給一個系統的所有源文件都打上標簽,這樣別人可以同步所有有這個標簽的文件版本? 答:之前代碼在本質是一步步完善過程中的,基本上每一次代碼提交都會添加一小部分功能模塊。在穩定性上來說沒有什麽太大的體會,並沒有出現很不穩定這種的版本。就算出現了這種版本,一般也是代碼處理上的錯誤,通常是不會選擇提交,而是會改進後提交的。 10. 你的項目的源代碼和測試這些代碼的單元測試,以及其他測試腳本都是放在一起的麽? 修改源代碼會確保相應的測試也更新麽?你的團隊是否能部署自動構建的任務? 答:源代碼和測試這些代碼的單元測試,以及其他測試腳本沒有放在一起的,因為這樣更方面進行處理。 至於測試的更新方面,會放到之後再進行更新,優先度來說沒有那麽高。 提交之前會進行簡單的測試,不會將每部分功能每個方法都充分測試。

二、文檔準備

驗收之前,本項目組已準備好以下幾類文檔:

1.開發總結文檔

2. 需求文檔:包括需求規格說明書,需求變更文檔等

3.設計文檔:包括概要設計,詳細設計,數據庫設計等

4. 測試文檔:包括測試方案,內部測試報告,第三方測試報告等

5.實施文檔:包括實施,部署方案,用戶手冊,維護手冊等

6. 過程文檔:包括項目周報,會議紀要等

github上傳記錄:https://github.com/FBGfbg/xuqiu

技術分享圖片

三、項目驗收過程

1.項目匯報

  由乙方的負責人來主持會議,由乙方項目組長進行PPT講解,匯報本項目的需求分析,開發背景、開發過程、功能簡介、總結,並對本系統進行演示,由甲方對本項目進行提問,乙方團隊成員進行解答,在此同時,甲方根據項目講解情況、項目完成度,以及答疑情況對本項目進行評分。

2.項目驗收

  (1) 整理好需求分析說明書、系統設計方案說明書、系統測試文檔、實施文檔、會議記錄、總結文檔等,完成項目軟件系統演示前準備工作。並準備好項目驗收意見表、驗收會議名單及驗收會議議程。

  (2) 本次項目驗收會議成Dare_To_Dream團隊和本團隊的全體成員,先有本團隊做工作匯報和總結,接著,由本團隊技術人員進行系統演示,這一系類的工作結束以後,由Dare_To_Dream團隊對本系統進行提問,本團隊的成員解答,最後由Dare_To_Dream團隊的組長填寫項目驗收意見表。

四、站立會議場景

技術分享圖片

技術分享圖片

五、任務分工

具體任務 工作量 花費的時間
馬玉婷

1.撰寫開發總結文檔

2.撰寫設計文檔

3.Beta沖刺二

4.Beta沖刺三

5.系統演示前的準備

35% 9小時
馬美玲

1.PPT的制作

2.撰寫需求文檔

3.撰寫過程文檔

4.Beta沖刺一

5.Beta沖刺四

35% 9小時
益西卓嘎

1.撰寫測試文檔

2.撰寫最後的博文

3.項目驗收意見表

4.撰寫實施文檔

30% 6小時

六、實驗心得

馬玉婷:這次作業任務總分比較高,任務難度也比較大,個人感覺難度主要來源是代碼部分,雖然這個不能占軟件工程這門課的一大部分,但是由於自己以前沒有學好編程,導致在這一塊很吃力,再加上我們只有三個人,也使得我們的難度增加了許多,但是我們團隊還是經過努力完成了任務,只是有一點感覺可惜的是我們原定最有特色的一步由於時間關系沒有做出來,但是我會繼續把這個項目做下去的。

馬美玲:本次實驗從剛開始的項目選定到之後的需求分析、概要設計、詳細設計再到最後的項目的實施及驗收,我清楚的掌握了軟件工程實施的基本過程。這次項目中我學到了很多東西,把之前學過的JAVA又熟悉了一遍,也學會了沒有接觸過的Android的相關知識,學會了軟件工程設計中使用的一些工具,使我收獲很大。此外,深深感受到團隊合作的重要性,有計劃、有效率的溝通會使團隊少走很多彎路,也會使項目進展的更順利。

益西卓嘎:一個學期眨眼就過去了,通過這一個學期的學習,我已經基本了解了軟件設計的基本流程。團隊明確的詳細的對任務進行分析和分工,在一次次的實驗中也越發的感受到了團隊合作的重要性,整個過程中深切的體會到軟件設計中一個軟件從最初的構想到最後實現所需要的步驟。在這一學期的正規的軟件工程項目設計開發裏面我們遇到並解決了很多的困難,也學到了許多的東西。作為一個團隊的一分子,積極主動和同組成員溝通意見,共同進步,一起合作雙贏,快速的找準自己在團隊的定位並找到自己的工作;作為一個軟件工程人員,更是學會了如何正確和快速的構建一個合格的軟件工程。感謝所有的助教老師和團隊成員們,給了我不盡的動力能堅持下去。

組長總結:這是這門課程這個項目最後的一次作業,作為小組組長,回顧這一路的歷程,真的收獲了很多,從不知道安卓到淺談安卓操作,從各種各樣的數據庫環境中選擇出MySQL,從每個人手忙腳亂到跌跌撞撞的找到自己的路,我們經歷過爭吵,看過蘭州12點以後的月亮,也曾認真的和陌生人交談,很感謝每一位我的組員,也很感激大家能夠這麽努力的去完成了這件事,這個過程,我們這個團隊變得更加堅強,雖然這句話說了很多次,但還是想說,很感謝每一位老師給我們的幫助和點評,不過是博客下面的評論還是班級微信群裏老師們精挑細選過的博文,每一次分享,都讓我有所收獲,感謝你們,我的組員和我的老師們!

實驗十二