這個作業屬於哪個課程
軟體工程
這個作業要求在**
2020軟體工程作業——團隊07
團隊名稱
豬豬公寓
這個作業目標
事後諸葛亮
作業正文
本文章其他文獻參考
專案管理之事後諸葛亮會議
1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我們的軟體是個小遊戲，定義比較清楚。描述不太清晰。
2. 我們達到目標了麼（原計畫的功能做到了幾個？ 按照原計畫交付時間交付了麼？ 原計畫達到的使用者數量達到了麼?
達到百分之九十的目標了，戰鬥系統（包括攻擊、受擊、攻擊演算法、死亡判斷、公升級演算法等）都完成了。原計畫中只有**功能沒有完成。 最終版本是在原計畫時間內交付的。使用者數量沒有達到。
3. 和上乙個階段相比，團隊軟體工程的質量提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
軟體工程的質量有略微提高，後續的階段將很多冗餘的**設定為了介面，減少了**的重複，簡潔了**量。
4. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
根據組員的意見來說，組員們覺得這個和當初的預設值很相近了，所以我們離目標更近一步了。
一定要寫文件、注釋。重來一遍的話，時間不急的情況下要先考慮**的排序，團隊強制規定每個變數和方法的命名，命名這一塊當時寫的時候就是想到**寫到**。
1. 是否有充足的時間來做計畫?
有充足的時間，但是只做了部分計畫，很多的計畫不知道如何進行設計。
2. 團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
沒有很多的相斥意見，基本都是將各方意見提出來，然後看看能不能融合在一起，不能的意見再通過團隊會議進行是否執行。
3. 你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
暫時來說沒有發現，基本上做的都是和目標相關的事情。
5. 是否每一項任務都有清楚定義和衡量的交付件?
有些有，有些沒有
6. 是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
是按照計畫來執行，做專案的有段時間中間是考試（這個確實沒有考慮到），所以專案在衝刺期間沒有好好的完成。
7. 在計畫中有沒有留下緩衝區，緩衝區有作用麼?
有緩衝區，起到作用了，因為每個人的進度不一樣。
8. 將來的計畫會做什麼修改？
以後的計畫將會更加明確，可能會增加緊急情況下對程式的修改的時間，然後對緩衝區更加清晰的定義。
1. 我們有足夠的資源來完成各項任務麼?
有足夠的資源把，不過對組員的平台軟體進行的配置費了很多時間。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
這個時間是實話沒有進行很詳細的估計，時間很緊，基本上一直在寫**，有什麼問題提出來然後進行更改。
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
測試很簡陋，就是測試這些方法有沒有報錯有沒有輸出意外的值，還算比較足夠。美工確實低估了難度，一直在換美化背景。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
每個視窗的排版，這個真的需要別人先設計好，後台再進行排版，每次都是在設計的時候一點點除錯，極大的延誤了每天的時間量。
1. 每個相關的員工都及時知道了變更的訊息?
因為我們有相關的團隊群，對於變更的訊息知道得還是很及時的。
2. 我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
我們是先能讓整個程式執行起來的情況下來決定的。
3. 專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
做好了的定義，就是這個程式擁有了計畫中所有對於rpg角色所擁有的功能（簡化版）。
4. 對於可能的變更是否能制定應急計畫?
沒有做相對應的應急計畫，出了什麼變更就讓團隊的部分人員進行檢視和實現變更。
5. 員工是否能夠有效地處理意料之外的工作請求？
程式中意料之外的處理的話都寫到了乙個文件裡面，然後屆時提交給後台的人員進行更改。
1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
設計工作當時考慮的是使用html進行設計，由ui設計的人員進行完成的。但是html的**在一次意外中丟失了，後來就參考的設計進行視窗的排版。我們覺得設計時間挺合適，但是在開發階段，設計人員也需要和開發人員一起進行工作。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
沒有遇到模稜兩可的情況。
3. 團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？ 比較專案開始的 uml 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 uml 文件？
運用了單元測試，只測試了方法有沒有錯誤輸出和輸入以及數值的傳遞是否正確。junit工具有效
4. 什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
還是戰鬥部分的bug比較多，還是因為對角色屬性的數值命名不太規整，有很多地方傳遞了錯誤的值。發布之後的話就是也沒的重新整理這一塊有bug，再開發的時候想到了這方面，但是有些視窗沒有進行重新整理處理。
5. **複審（code review）是如何進行的，是否嚴格執行了**規範？
這個複審其實就是正在編寫的時候進行的，編寫邊審，沒有完全執行的**規範。
1. 團隊是否有乙個測試計畫？為什麼沒有？
有乙個測試計畫，就是按照驗收標準來進行測試的，對程式的有效性也進行了測試。
2. 是否進行了正式的驗收測試？
進行了。
3. 團隊是否有測試工具來幫助測試？
有，junit。
4. 團隊是如何測量並跟蹤軟體的效能（performance）的？壓力測試（stress test）呢？ 從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
效能測試還是很有用的，寫完**以後，進行測試，哇，執行時間是真的長，因為時間關係，對有些部分的**進行優化以後，那個執行時間真的降了好多。（其實也就是0.00幾秒）
測試工作從實際執行結構來看是有用的，但是對測試工具的運用不太熟練，需要加強。
5. 在發布的過程中發現了哪些意外問題？
無法在其他未配置資料庫環境的電腦上執行。
1. 團隊的每個角色是如何確定的，是不是人盡其才？
根據每個人熟悉的模組和他們想從事的方面進行確定的，算得上是人盡其才吧。
2. 團隊成員之間有互相幫助麼？
幫助很多啊，你不懂的問題別人正好懂，這就形成了幫助。
3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
這個就是提出來進行記錄，然後團隊成員進行歸總然後進行討論，可行的保留。
每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的部落格裡）：
成員部落格鏈結
謝河洲總結隨筆
朱瑞總結隨筆
劉瑤總結隨筆
羅軻總結隨筆
謝雨奇總結隨筆
陳款總結隨筆
蔣賽總結隨筆
彭佳總結隨筆
何霞瑛總結隨筆
朱**總結隨筆
因為離校了所以沒有線下**
事後諸葛亮
我們的軟體是為了提高實驗室協作管理的效率，讓實驗室事務安排變得有秩序，解決實驗室專案監管的視覺化以及學生經常遺忘專案安排的問題。定義較清楚，對典型使用者和典型場景也給出相應的描述。我們原計畫的功能做到了3個，完成部分的模組為日程管理，尚待完成的模組為協作管理，總體而言完成了alpha階段的計畫內容，...
事後諸葛亮
目錄 一 會議 二 設想和目標 2.我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?3.使用者量,使用者對重要功能的接受程度和我們事先的預想一致麼?我們離目標更近了麼?4.有什麼經驗教訓?如果歷史重來一遍,我們會做什麼改進?三 計畫 2.團隊在計...
事後諸葛亮
這個作業屬於哪個課程 這個作業要求在 homework 10863 團隊名稱 鴿子開發組 這個作業的目標 總結軟體開發過程的經驗和教訓 作業正文 如下其他參考文獻 無問題1 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？回答 軟體定義清楚，需解決的問題定義清楚。...