2. 程式人生 > >tiG - 事後分析與專案審計

tiG - 事後分析與專案審計

阿新 • • 發佈：2018-11-14

施工中

事後諸葛亮分析

設想和目標

我們的軟體的預期目標？

　　我們的軟體主要是用來提供友好方便的Git版本控制功能，預期目標就是完成便捷提交和歷史顯示的功能。

 

我們達到目標了嗎？

　　達到了預期的目標，基本功能按時交付。

 

使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?

　　考慮到中間考試等因素，我們最初設定預期目標不高，並非以釋出為主要目的，所以最終並沒有上線。

 

計劃

是否有充足的時間來做計劃?

　　有。

 

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

　　大家意見基本很統一，有不同意見的在開會過程中都討論解決了。

 

你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

　　已完成。

 

有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

　　暫無。

 

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

　　是。

 

是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

　　整個專案大致按計劃進行，雖然中間有幾場考試，但是隊員們都在考試後積極參與開發，確保進度不受影響。

 

資源

我們有足夠的資源來完成各項任務麼？

    • 人力資源：團隊中一共有5個人
    • 開發資源：參考Libgit2和Qt的官方文件
    • 裝置資源：每個成員各自的膝上型電腦
    • 時間資源：較緊張    

 

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

　　預先根據開發計劃進行估算，並考慮到成員學習使用Libgit2和Qt的大致耗時。

　　精度基本和實際情況一致。

 

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

　　各類資源基本足夠，最缺乏的還是時間資源。

　　本次專案我們沒有引入美工設計/文案，設計到UI的部分是僅作了基礎的設計。

 

變更管理

每個相關的員工都及時知道了變更的訊息？

　　不一定。一般只有重大更新或修改才會通過群聊或開會的方式逐一告知。更多情況下，即使沒有及時瞭解變更訊息，成員們也能通過Git的合併操作很好地解決衝突。

　　基本的策略是“誰負責開發，誰處理衝突”。

 

我們採用了什麼辦法決定“推遲”和“必須實現”的功能？

　　從需求程度和實現難度來綜合考慮是否實現或推遲某項功能。例如，歷史提交樹的部分，考慮到後續考試較多以及這個功能並非剛需，故推遲了其bug的修復程序。

 

專案的出口條件(Exit Criteria - 什麼叫“做好了”) 有清晰的定義麼？

　　有定義。

　　定義如下：

    • 程式可穩定執行，具有優良的魯棒性。
    • 主體功能完善可用
    • 測試過程中發現的嚴重等級Bug均已修復

 

對於可能的變更是否能指定應急計劃？

　　可以。團隊對Bug的緊急響應和修復能力是不錯的。在遭遇一些突發事件（如考試），也能通過後續的敏捷進行補足。

 

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

　　可以。在開發流程中，對於指定介面需求的不同，會向對應的負責者提出不同的工作請求，隊員們對此的處理都十分高效。

 

設計/實現

設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？

　　設計工作安排在編寫規範文件的階段，由我來完成，主要是對程式主體架構的設計和示例程式碼的編寫。完成後再通過開會的方式向隊員介紹結構設計和分工方向。

　　設計工作安排在初期我覺得是最合適的。

 

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

　　有，比如，對於是否保留Add暫存區的功能，我們通過開會的方式討論解決，最終決定將Add與Commit合併為一個操作。

 

團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？

　　是。單元測試是貫穿整個開發流程的，只有通過測試和複審後的程式碼才會合併到主分支。

 

什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

　　提交歷史檢視產生的Bug最多，因為這部分涉及到繪圖的運算較為繁瑣。

　　在釋出後暫無發現什麼新的重要Bug。

 

程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

　　程式碼複審雖然有進行，但並不是很嚴格，許多時候是存在疏漏的。程式碼規範執行得不錯，但是提交規範沒有嚴格執行，存在一些無效提交或重複提交。

 

測試/釋出

團隊是否有一個測試計劃？為什麼沒有？

　　有。介面模組的單元測試由對應的負責人進行測試，GUI測試則受限於時間沒有安排計劃。

 

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

　　是。有在多個環境下進行驗收測試，也發現了一些Bug。

 

團隊是否有測試工具來幫助測試？

　　受限於時間沒有采用自動化測試。

 

團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？

　　當前的關注點並不在軟體效能上，過早優化可能不是一個較好的選擇，因此我們更傾向於關注軟體的功能完善，在開發過程中注意效能損耗，但不會刻意跟蹤效能。

 

Alpha版本完整演示

　　

 

總結

你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?

　　達到了CMMI二級——管理級的程度。我們團隊遵守了既定的計劃和流程，有資源準備，權責到人。但是還沒有一套完整的管理措施，沒有制度化。

 

你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?

　　我認為到了規範階段。我們團隊成員們的職責分工明確，交流也充分及時。

 

心得總結

　　通過這次專案，深刻體會到了團隊合作的優越性，也學習到了許多與軟體工程相關的知識。較為遺憾的地方在於因為其他事務安排較多，時間緊張，無法騰出充足的時間在軟工團隊作業上，所以最開始的預期目標就沒有定的很高，主要定位不在於最終釋出程式，而是開發過程中與團隊成員的協作、學習和交流。

 

貢獻統計

名字

角色

團隊貢獻分

可驗證的貢獻

鄒卓輝

開發

  

Git Diff介面、Git Commit介面、單元測試

盧明凱

開發

  

Git Push介面、Git Clone介面、工作區檢視

張凱亮

測試

  

單元測試、回溯測試

劉海港

 測試    回溯測試、部落格編寫 

澤瑞坤

 開發/產品   Git Show介面、Git Log介面、提交歷史檢視、介面設計與互動邏輯、部落格編寫、單元測試

 

Alpha階段專案複審

由團隊成員共同編寫，但受限於我們的水平，難以各個技術棧都有了解認識，僅能提供淺顯的複審建議，僅供參考

 

小組的名字和連結

優點

缺點，bug報告
（至少140字）

最終名次
（無並列）

 

小谷圍駐廣東某工業719電競大隊

 

http://www.cnblogs.com/TaoTaoLV1/p/9934585.html

頁面選項做得很詳細，功能完善，畫面較為美觀

修復的bug：

前端：websocket協議通訊時遇到版本號問題，與後臺對接時傳參形式和格式出現錯誤

後臺：重點解決spring-security和spring-websocket之間的bug

沒有演示具體的交易流程，所以具體體驗如何不清楚，主要問題應該是支付的解決

 

 

夕陽紅

 

https://www.cnblogs.com/hhg52516/p/9935999.html

 

介面簡潔，一目瞭然，上手容易

修復的bug：

設定了登陸攔截器，中斷程式的執行，但是沒法重定向到login頁面，只能重啟

只能通過iphone執行，安卓不可以，這導致沒有iphone就無法使用，沒有提到具體交易的實施

 

 

EmbarassedBirds

 

http://www.cnblogs.com/HappyCodeingkc/p/9937152.html

頁面開起來簡潔大方，設計好

可惜暫不能上線，此專案初衷是根據每個使用者的需求，自己建立問題，然後通過答題的方式來篩選哪些人是使用者想找到的，從而幫助使用者讓他們認識交流

 

 

拉登是我罩的

 

http://www.cnblogs.com/kiewillis/p/9937345.html

 

雖然只有文字描述，而且我對偏硬體的開發並不瞭解，不過看起來是很有趣的工程

 

沒有看見具體的遊戲效果和程式碼，且水平有限，不做評價

 

 

C++輪子隊

 

http://www.cnblogs.com/coothen/p/9937470.html

完成度高，在傳統的基礎上對遊戲做了修改，增加了障礙，也出現了獎勵方塊

總共發現了7個Bug，修復的bug有7個

遊戲圖片中，4位數字出現數字分兩行顯示的情況，對使用者有點不大友好

 

 

假如我們的坦克繼續前進隊

http://www.cnblogs.com/5164a/p/9937642.html

對比經典坦克大戰，除去了需要守家的顧慮，遊戲難度降低

修復的bug：

敵方坦克陣亡時血條不消失的

執行程式jar無法執行

在進行風騷的走位時會將操縱的坦克卡進牆內，好像沒有設計每一關的場景，這會使場景比較混亂，影響遊戲體驗

 

 

宇宙最帥叉叉

 

http://www.cnblogs.com/hzquestion/p/9937677.html

有查詢物件功能，以及關注功能

修復的bug：7個

下版本修復的bug：2個

沒有許可權的設定，無法拉黑別人，別人想關注就關注你，貌似無法拒絕別人和你聊天

 

 

你吼辣麼大聲幹什麼嘛

 

http://www.cnblogs.com/traehowo/p/9937584.html

可以兩個人一起玩

快速或同時按左下右三個鍵會讓蛇死亡

兩條蛇的頭部側面穿過不會死

豆（綠色方塊）會在蛇身刷新出來

遊戲中的屍體僅為顏色，不夠精緻

 

 

大馬猴隊

 

http://www.cnblogs.com/busizzzz/p/9937805.html

可以不需要客戶端，直接使用網頁，模仿微信，介面還原度較高

已修復的bug：7個

還有些功能尚未實現，不夠完備，沒有實現朋友圈，以及好友新增許可權等

 

 

月裙抓瓦98分隊

 

http://www.cnblogs.com/happyeven/p/9937879.html

遊戲玩法多樣，可玩性比較高，修復了很多bug

還有很多已知bug未修復

一個RPG沒有NPC，還未達到可以遊玩的地步，沒有介面提示，選單欄等，不利於上手，RPG遊戲有音樂的話會更好

 

 

無言以隊

 

http://www.cnblogs.com/chaojiruozhi/p/9938262.html

介面比較簡潔清新，可以兩個人一起玩，

分數和計步還沒有顯示

遊戲結束條件判斷不足，若一人存在反殺的可能時，會被直接終結

 

 

企業管理系統

 

http://www.cnblogs.com/zero010/p/9938479.html

實現了對員工資料的管理，介面比較簡潔

發現的bug：3個

好像沒有檢視所有員工資訊的功能，只能對一個員工的資訊做修改刪除，發現的bug不知道解決了沒有，介面看起來過於簡潔

 

 

微信小遊戲五子棋

 

http://www.cnblogs.com/macrae/p/9940387.html

介面設計簡潔易懂

程式有很多bug為解決，出現了許多與其外的錯誤，卻沒有解決這些問題

開始介面只有一個開始遊戲，較為簡單，人機沒有難度的選擇

 

 

甜美女孩

 

http://www.cnblogs.com/serendipity-zeng/p/9937832.html

介面比較簡潔清新，有兩種模式可以選擇，有趣

Bug：（不知道是否已經修復）

由選單點進去基礎2048無法玩

基礎2048有時會無法移動

紙牌2048的牌移走一個後下一張牌無法移到原來第一張牌的位置

對需求的取捨：先做好基礎和紙牌，捨棄自定義模式；考慮遊戲性，暫時拋棄遊戲成績的顯示和成績的記錄

基本實現了專案的目標

 

 

菜雞互啄隊

 

http://www.cnblogs.com/tworld/p/9942563.html

架構足夠清晰，分工細緻，從提交歷史中可以看出隊員們的開發熱情

已修復的bug：

使用commit命令出現的數字長度溢位問題

在Windows端的編碼問題

架構足夠清晰，分工細緻，但是git與github互動需要賬號密碼以及金鑰，可以的話最好在部落格和readme中說明

 

 

ACT小遊戲

 

http://www.cnblogs.com/xonoc/p/9940978.html

畫面簡潔，玩法易懂

Bug：（不知道是否已經修復）

迴圈場景時敵人並不會持續生成

主角目前是無敵的，碰撞敵人也不會死亡

迴圈場景時還會超出背景邊界

部落格太過簡單，沒有說明具體操作，以及遊戲的場景，敵人的攻擊方式是什麼，部落格中只有一張圖片具體很難判斷

 

 

菜雞互坑隊

 

http://www.cnblogs.com/hhx3116005133/p/9943689.html

畫面清晰利落

Bug：

同時按下和蛇前進方向相反的鍵和垂直方向的任意一個鍵貪吃蛇會死亡（比如貪吃蛇向右行走，同時按左上或左下都會死亡）

重新整理的蘋果會在蛇身上出現

程式執行介面給的太少，很難做出正確的判斷

 

 

莪的拽、像省田各號①樣沒盡頭隊

 

https://www.cnblogs.com/m870100/p/9859127.html

選題新穎

Bug：

角色繪製計時器跟過場繪製計時器發生衝突，導致過場動畫無法載入

介面CSS定位有問題，左右沒對齊，還沒來得及寫自適應

成長系統還沒設計完全，角色也只有一個

作為機械寵物應該有更多的互動功能，影象需要有反饋，讓人感覺到有真實感一點，這樣才更像一隻寵物

 

 

 

 

 

相關推薦

tiG - 事後分析與專案審計

施工中 事後諸葛亮分析 設想和目標 我們的軟體的預期目標？ 　　我們的軟體主要是用來提供友好方便的Git版本控制功能，預期目標就是完成便捷提交和歷史顯示的功能。   我們達到目標了嗎？ 　　達到了預期的目標，基本功能按時交付。   使用者量, 使

團隊作業10--項目復審與事後分析

get 作業1 分析 log com ont size beta -s 1、團隊作業10---Beta階段項目復審 2、團隊作業10---事後分析（Beta版） 團隊作業10--項目復審與事後分析

項目復審與事後分析

照片 應該 ref 諸葛 order 網絡資源 很大的 一個人 滿足 Beta階段復審 小組名字和鏈接 優點 缺點和bug報告 最終排名 RunningGuys http://www.cnblogs.com/RunningGuys/p/6944521.ht

系統分析與設計團隊專案第二次

團隊專案介紹 1.團隊名稱     MC卓越 2.專案名稱    閱晒客(recycle) 3.專案簡介：        閱晒客是一個共享的書籍使用平臺，它藉助於移動App實現。我們的專案結合了當代

系統分析與設計課程專案 WordCount 結對程式設計

系統分析與設計課程專案 WordCount 結對程式設計 作業說明 合作者： 201631084230（只有我一個人，“合作者”這個標題有些不合適了） 程式碼地址： https://gitee.com/mxhkkk/Wc/tree/complete/ 本次作業的連結地址： https://edu

系統分析與設計結對專案——WordCount

結對專案完成WordCount 合作者：201631062507  201631062526（學號） 程式碼地址：https://gitee.com/WordCountMC/WordCountTeam 本次作業連結：https://edu.cnblogs.com/campus/xnsy/201

關於開發一款課程實驗軟體的專案需求分析與建議（NABCD）

　　N（Need 需求）：　　　　目前有些大學生在做課堂實驗時因為沒有完全理解老師的意思，對實驗具體的步驟不清楚，導致真正做實驗時無從下手，無法完成實驗要求，無法達到真正的效果；或者學校無法提供足夠的實驗資源讓學生充分完成實驗，學生無法有足夠的時間去完成整個實驗。 　　A（Approach 做法）：

專案需求分析與建議

N(Need)我們這款程式解決了測量人員在用進行四等方向觀測法測量水平角時記錄員需要邊記錄便計算是否超限差比較費時和後續成果計算於驗核的問題。A（Approach）在這個學期，我們剛剛學習了VS中的c#來進行測量程式設計，所以我們團隊決定運用所學的的c#利用vs來編寫一個小程式來解決這個問題，該程式包含資料的

第六周復審與事後分析

簡潔 碰撞 計時器 加載 完成 很多 顯示 對齊 沖突 比好 Alpha階段項目復審 小組的名字和鏈接 優點 缺點，bug報告（至少140字） 最終名次（無並列） 莪的拽、像省田各號①樣沒盡頭隊 https://www.cnblo

軟體工程：專案需求分析與建議-NABCD模型的個人認知

N：（need 需求）   我們在自己的手機上或電腦上查詢檔案時，往往因為檔案數量的眾多，型別的繁瑣從而使我們的尋找非常的困難，因此一款簡單便捷的查詢格式型別的軟體（尤其是在電腦上）變得尤為重要。 A：（Approach 做法）   為了解決部分人群的需求，我們有獨有的方法，更加有效

嵌入式小專案練習-光電設計競賽-尋跡小車-03-尋跡演算法分析與原始碼

這裡我用了三個光敏電阻的感測器來進行尋跡：這裡用X1,X2,X3(檢測到了為0)來表示： 演算法思路： 將三個感測器放置如圖：         |          |   

訂單中心專案分析與總結

需求背景：隨著業務的發展，公司逐步上線了多種產品和業務線，每個業務線除了一些基礎的服務(比如支付，資產交割等)使用公共服務外，剩餘的部分都是業務線自行處理，這樣就形成了各個業務線自己的訂單。在業務發展的初期，這樣的方式是很方便快捷的，可以使得產品快速上線，但同時也埋下了一些問

大資料綜合專案DocCloud之需求分析與功能實現詳細（續更）

DocCloud專案需求 專案背景： 在一些大型企事業單位，工作中存在各種各樣的工作文件，技術文件，規範等等。這些文件以word,xls,ppt,wps,pdf,txt存在。在此專案之前，文件的分享主要靠單位內部人員的互相傳送。沒有一個統一的平臺對企業現存的各種文件進行統

演算法設計與分析期末專案

演算法設計與分析期末專案 1. 題目 固定容量設施分配問題 1.1 題目描述 ​假設有\(n\)個設施和\(m\)位客戶，希望從中選擇： 在\(n\)個設施中選擇開啟哪些設施 將客戶分配給開啟的設施 要求開啟設施的總費用和客戶分配到設施的總費用之和最小，且設施的容量不能超過設施

敏捷開發與專案管理實戰之敏捷需求分析

敏捷開發中，全體成員都會參與需求分析。但是，通常多數的開發人員和測試人員他們的能力和經驗不足以勝任需求分析工作。這意味著全體成員參與的需求分析活動需要一個扮演導師角色的人帶領大家去進行有效的需求分析。本文以作者黃文海帶領

qps20w背後的設計：秒殺\搶券專案——深度分析與總結

之前參與一個峰值qps達到20w多的電商促銷專案，現在做一些總結與思考，可能存在紕漏，歡迎交流探討。本人長期專注於服務層，文中對前端以及運維的理解可能不夠深入。 歡迎各位有理有據的交流探討。 架構隔離 在開始具體細節時，先說說架構隔離。 對於這個促銷

【A】python資料分析與機器學習實戰 專案開始前，怎麼根據實際專案選擇合適的機器學習模型

選擇合適的機器學習演算法： 最好的演算法的唯一路徑可能就是去嚐遍所有的演算法。但是這種方法非常 “蠢”。 機器學習型別 這部分我們會介紹一些最流行的機器學習模型型別。如果你對這些類別比較熟悉，那麼對你以後去選擇機器學習模型是非常有利的。 監督學習

《QUML：量化需求分析與建模》節選之三：一個量化管理專案的一生（2）

本書由本人編寫，於2014-09-09在百度閱讀首發，部落格將轉載試讀部分的20%內容，以及非試讀章節的某些片斷。第一個月從用例到使用者故事，從使用者故事到程式碼在敏捷計劃會上——是的，他們採用敏捷開發，確切說是Scrum——產品經理正在給開發人員講解需求。他並不是空手來的，

軟體專案開發中需求分析與設計時間和開發時間的比例分配的問題

          從畢業到現在做開發已經有近7年了，大大小小的專案也經歷了幾十個了。在專案開發的過程中很少有專案在設計階段投入很多時間的， 有很多情況下，甚至都沒有怎麼做設計就直接開始編碼了，處於一種邊開發邊設計到狀態，還有些時候，設計就是完成一些文件來應付下，很 少有認

python資料分析與挖掘專案實戰記錄

 python資料探勘專案實戰記錄 取自《Python資料分析與挖掘實戰》一書，整理各個專案中用到的資料處理方法： 資料預處理方法 建立模型方法 繪製圖形 對於分類問題：用模型分類；混淆矩陣及其繪圖；觀測其ROC曲線； 對於聚類問題：劃分類目數；獲取