軟件工程-構建之法個人的附加作業 - chengxs－IT工程師數位筆記本

文章出處

一、前言

現在再增加一項個人的附加作業，每認真回答一個問題附加2分，10分為上限。附加作業回答以下幾個問題：
1. 你認為本門課程需要在哪里進行改進，具體措施有哪些，包括：時間進度安排，項目難度等均可；
2. 你認為助教／老師哪里做的不足，哪里限制太多等；
3. 你認為每次項目的評分標準存在哪些問題，你認為的合理評分準則是怎樣的（個人／結對／團隊算三個）
4. 在結對項目中你是否真正體會到了結對的好處，是否真正嚴格進行了結對編程，雙方的工作量是否相同；
5. 你的團隊項目是否成功，如果重來一次你是否還會選擇這個團隊，為什么成功／失敗；
6. 總結一下你們團隊在做項目時大家的時間安排情況，可以匿名寫。
7. 關于本門課程你還有其他任何好的建議／意見；

二、回答

1、改進方案：

1）在現有的基礎上，可以適當增加一下課時（個人覺得2個班可以增加4課時），2）在展示自己團隊的需求分析和軟件設計部分。3）最終的檢查成果可以放在下個學期的開始（因為現在都到了期末考試各種復習，沒有太多時間去做自己的團隊項目，大家精力分散，如果用一個長假期來緩沖具體開發階段，這樣在長假期時候可以完善自團隊的項目，包括我們做的不好的UI部分，以及服務器端部分布置，下一個學期的開始，課程不會太緊張，一般沒有什么事情分散精力）4）項目難度可以團隊展示需求分析和軟件設計部分，根據老師來確定幾顆星（最高5顆星），控制大部分團隊在3-4顆星，少數2顆星，有能力的學生可以挑戰一下5顆星（在之后的實施中，想更改星級，聯系老師，由老師決定是否在之前的基礎上有提高星級的可能）。

2、不足

1）助教不足：個人覺得在團隊開始之后的作業情況反饋上稍微懈怠（助教也是跟我們一樣是學生，精力分配也很正常，應該算不上不足，優點太多）

2）老師不足：可以考慮拿一個之前學生具體開發的案例來講，可以邀請他們在講臺上講講具體的軟件開發的過程和心得，可以方便學生與他們的聯系。

3、評分標準

1）個人的評分標準：我表示贊同，沒有問題

結對評分表標準：我也贊同，沒有問題

團隊項目評分標準：之后說到了百分比，表示贊同

2）個人覺得合理評分準則：（1）沒有人情分（2）針對個人：排版，敘述，實際成果三部分比重可以考慮一下2:3:5(其實有的同學做的還行，但是敘述和排版存在問題就成績好像有點低)（3）針對團隊/結對：可以說到百分比，這個百分比由兩個或者團隊商量給出。

4、結對編程的體會

1)真正體會到了結對編程的好處，嚴格了進行了結對編程，工作量并不是對等的。編程中有一個人在盯著看自己編寫的代碼，你總會發現自己比之前謹慎多了，自己平時寫代碼有在寫之前在代碼部分寫上接下來的編程思路和步驟，做上注解的習慣，一步步寫代碼，不斷的修改代碼和編程的思路與步驟。在之前我們討論過使用什么數據結構來寫，我想用STL中的map，她說用鏈表，然后我們討論，最終使用的是我的STL中的map，理由時間復雜度logn，使用map容器，大大縮減了代碼量，效率高。然后給隊友講一下STL中map原理和基本使用，然后我開始編程，她幫我找錯，然后她提醒我我寫錯的部分，然后她找出來測試用例，的確出現了bug，然后就換成她來解決我寫的bug，然后剩下我來繼續完善代碼部分。

5、團隊評價

1）我覺得我們的團隊是成功的，因為我們首先做出來了，不管這個平臺的難易，最可惜的是服務器端不能跑，服務器上跑有bug，備考期末中，之前的搶修告一段落。

2）如果從來，我會選擇這個團隊，因為這里有團結有民主，有頭腦風暴想設計時存在的問題，有可以在一起碰撞出編程的火花，可以很好的共事。

6、團隊時間安排

1）A和B和C一個寢室，B白天和晚上課程比較多，經常不在寢室，一般晚上下自習回去，B的時間是晚上和A討論，需求分析以及軟件設計部分，B負責需求分析的視頻制作和團隊博客的書寫，C負責每次討論的照相，A負責最終代碼實現部分，最終不斷的消除bug，最終成功了。D負責一次團隊博客的書寫，白天每次上軟件工程課的時候我們就提出團隊做什么，提出A和B的想法，大家都贊成，E和F負責了測試案例的制作。每次軟件工程課程時候，討論一下出bug地方，大家一起出主意，錯誤存在哪里，怎么嘗試修改。

7. 關于本門課程你還有其他任何好的建議／意見；（見第1條）

文章列表