軟體工程(QLGY2015)部落格點評總結

目錄

第一次作業(2015.5.9)

第二次作業(2015.5.21)

第三次作業（2015.6.11）

2015上半年軟工助教總結

 

第一次作業（2015.5.9）

存在主要問題

1）書寫這種練習部落格的步驟幾乎都不對，建議按照以下步驟：

•     題目介紹（簡單介紹題目內容、要求，或給出題目連結）
•     原始碼地址（github原始碼連結、或其他位置連結）
•     實現步驟
  •     需求分析（再簡單的系統也有需求、也要分析）
  •     功能設計（有哪些功能，每個功能怎樣實現，有圖更好）
  •     難點攻克（有沒有難點，有的話，怎樣攻克該難點）
  •     編碼實現（編碼實現不是指“貼程式碼”，每段程式碼前後需要進行詳細說明）
  •     測試（測試截圖，測試結果）
•     心得（做完此次練習後的體會，學到了哪些知識點？）

2）部落格正文中所有原始碼必須使用“程式碼樣式”，Java程式碼使用Java程式碼樣式，C程式碼使用C程式碼樣式（此次作業很少人用到程式碼樣式），看起來很不舒服；

3）命名要規範。無論類名、函式（方法）名、（成員）臨時變數名、原始檔名，統統使用規範命名方式，比如定義一個圓形類，請使用“Circle”，不要使用“Yuan”。負責計算的檔案使用Calculator.cpp，不要使用class1.cpp；

4）要有程式碼註釋。無論類、函式（方法）、成員變數都得要有註釋，關鍵程式碼也要有註釋；

5）截圖時請擷取區域性即可，不要全屏截圖，那樣看不到重點，而且一般顯示器顯示不全；

6）提交原始碼必須整個專案資料夾全部上傳，不要只上傳一個原始檔（比如test.c）。整個專案上傳後，別人下載下來編譯一下即可看到效果；

7）部落格排版問題非常大，各級標題要與正文區分開來，字型、粗細要有區分；

8）部分學生題目沒做完，只實現了一部分要求。

（其它具體小問題、在部落格點評中已說明）

學生成績

部落格中有些同學寫的實在是太簡單，內容太少了，所以沒有點評，直接給出分數。只要有內容的，我都給了分數，並沒有給0分。

學號	分數
1162	8
1032	8
1184	4
1164	6
1165	6
1166	6
1167	7
1168	7
1170	1
1171	9
1172	5
1173	5
1174	5
1175	4
1176	7
1177	2
1178	4
1179	6
1180	7
1181	6
1182	8
1183	7
1184	1
1185	6
1186	6
1187	6
1188	8
1189	8
1190	8
1191	9
1192	5
1193	2
1194	8
1195	8
1196	6
1197	5
1198	5
1199	7
1200	9
1201	6
1202	1
1203	8
1016	4
1026	7

建議

感覺教會學生排版、格式  是當務之急。

 

 

第二次作業（2015.5.21）

第二次作業模式是同學之間結對程式設計，我在部落格中只對同一組中第一名學生的部落格進行了點評。點評完後，發現存在主要的幾個問題：

存在主要問題

1）github提交原始碼幾乎沒有一個組正確，大部分都是隻提交一個原始碼檔案（比如.java、.c檔案），甚至有人將程式碼放在txt檔案中提交了。這個問題希望老師在上課的時候給同學演示一遍怎樣提交原始碼，讓學生有個直觀的感受，可能我們在部落格中說，學生沒有概念；

2）這次同學們的部落格質量明顯上升了一個檔次，無論是排版還是內容上，都比上次要好很多，進步很大。但是還有幾個建議：

• 大多數同學過分強調程式的執行結果，並沒有注重“實踐過程”的展示。這主要體現在：大部分學生貼程式的執行截圖，幾乎不寫他們是怎麼去實現的；
• 部落格中不提倡將全部程式碼全部貼進去，只需要將部分關鍵、重要的程式碼貼進去即可，並進行相應的說明和解釋。這樣讓別人更能理解你的思路，很多學生要麼一行程式碼沒有，要麼將全部程式碼往上一貼上，還不給註釋，這樣看不到重點；
• 貼在部落格中的程式碼必須要使用程式碼樣式，不能直接像文字一樣貼上進去；

3）命名規範還需要注意，不能隨便取a、a1\、bba這樣的名字；

4）既然是結對程式設計，每個人分工應該再寫詳細一點。比如加上兩個人在協作過程中遇見了哪些問題，最後怎樣解決的，這個幾乎每組都沒有。

總的來說，這次普遍質量要高於第一次，進步非常大。：）

具體點評內容，可以參見每個小組中第一個成員部落格後面的評論。

 

建議

讓學生儘快學會github上原始碼管理。

 

 

第三次作業（2015.6.11）

（持續更新）

第三次作業是一個團隊專案作業，要求3~7同學組成專案團隊，實現一個小型專案。具體要求見：http://www.cnblogs.com/qluZhao/p/4508794.html。我負責點評23-44號專案組的部落格，在每組的部落格中我大概都留了一些建議。

首先需要明確的是，無論從技術上還是工作任務量上看，本次作業確實要比前兩次複雜一些。下面是我總結的一些問題：

存在主要問題

1）上兩次作業的重點是編碼和測試，這兩個方面也是學生在課堂上接觸最多的，有直觀的印象。“可行性分析”、“需求分析”、“畫功能設計圖”、“畫用例圖、時序圖”這些相對來講，可能對於學生們更陌生，因為如果沒做過實際專案，他們是體會不到這些工作的實質性意義，所以做完提交的內容顯得非常不專業。需求分析、用例圖、類圖做得幾乎都不合格。

2）個人認為，本次作業提交方式更適合採用上傳附件的方式（部落格中簡要文字介紹一下即可）。本次作業中很多文件不是用一兩段文字、上傳幾張圖片就能完事兒的，而是要求分塊、分級去寫，這樣一來，格式顯得非常重要。可能很多同學不太擅長在部落格園發表部落格，所以上傳的文章很多沒法看。很多同學直接從Visio畫圖軟體中截完圖貼上來（圖片還處在編輯狀態），圖片解析度太小看不清，正文內容還不分級別（沒有標題）。我認為，軟體工程中很多文件應該在一些專業文件中完成，比如使用word/excel等，應該嚴格要求學生們的文件格式。一個計算機專業的學生連word/excel格式都不會調，真的說不過去。如果這種事情做不好，“軟體工程”構建大法學得再好，也只能是虛的。

3）目前同學們已經提交的部落格中，制定測試計劃、給出設計類圖這兩部分普遍都不合格。團隊組建及專案啟動做得還好。利用NABCD模型進行競爭性需求分析每個組也都認真去寫了（除了個別抄襲以外），但是寫得內容還存在很多問題，大多數只停留在字面意思上，有的甚至字面意思都沒理解到，比如NABCD中的"4.C競爭"，有的同學分析自己在完成了專案後，對自己Java能力有很大提升，他把這個當作系統的競爭優勢。在利用NABCD模型進行競爭性需求分析這塊有以下問題：

• 說實話，要讓學生想出一個非常具有創新性的專案出來，可能很難。他們能想到的大多數軟體系統市面上都已經有成熟產品，所以在寫“C競爭”這塊時，都很吃力，沒什麼優勢可寫。但是作為一個作業來講，哪怕自己做的系統沒有什麼競爭優勢，我覺得同學們也應該按照正確的方式列出1、2、3來，而不是寫一些模稜兩可的套話；
• 在寫“N需求”這塊，也是套話太多。並沒有類似“實地調研”的報告出來。

總之，在利用NABCD模型進行競爭性需求分析這塊，感覺同學還並沒有理解它實質性的用處，要知道，一個專案產品能否成功啟動、後期能否成功推廣產生利潤，這一環節起到很關鍵性的作用。

[2015.6.15更新]

4）6.14號大部分學生提交了“物件導向程式設計”這部分部落格。最大的問題有以下：

• 前面需求分析、競爭性分析包括設計都太理想化，到最終的程式碼實現特別簡單。完全是把課堂上的一個小程式拿過來應付一下，跟前面做的工作脫節了，沒有考慮前面已完成的工作；
• 經過之前兩次作業的訓練，學生到現在還沒有掌握github原始碼管理；
• 完成一個專案後，將實現過程（編碼實現）總結一下，寫到部落格中去。這樣的一個任務，感覺大部分學生還並沒有瞭解應該怎麼做。學生們需要學的東西還有很多。

[2015.6.22更新]

5）6.21絕大部分學生均提交了最後的“執行及總結”這部分部落格。有以下幾點問題：

• 從最後的執行結果可以看到，和預料的一樣，幾乎沒有可以拿去實際使用的專案系統。但是我認為，作為一個大作業，歷時一個多月，凡是自己認真動手、動腦子去做了，哪怕最後用不了，還是值得鼓勵的。我自己本科畢業4年，還是知道一點點情況的，學生做出來的東西幾乎都用不了。這種情況避免不了，我們要做的就是多練習，日後能夠短時間內適應真實的專案。
• 做完一個專案後，將自己在專案過程中遇到的一些問題以及怎樣去解決的記錄下來，這一點很少有人寫到。總結這塊還是跟前面一樣，套話太多。
• 整個專案基本結束了，就我個人而言，有幾個組還是做得比較好的。其中我認為最好的應該是這組http://www.cnblogs.com/bbker/（23~44組中選出來的）。可以看到，這組每篇部落格均是用心去寫的，沒有官腔套話，這組編碼能力也還行，最後做出來的東西雖然也可能用不上，但是我能感覺到這組成員確實是自己動腦子、認真對待了這次作業。

各組成績

（有疑問的同學可以聯絡我）逾期未繳作業的重新補交沒用。

 

序號	團隊部落格名稱	NABCD[3*10]	程式程式碼[4*10] （注意這部分包含提交部落格和提交到github的原始碼）	執行及總結[3*10]	逾期未繳作業[-1*10]	總分	說明
23	小小狗們	15	30	25		70	主要問題：  1）NABCD各項理解均有誤，套話太多，沒有自己的話。並缺少D項內容。 2）程式碼解釋很詳細，但要注意排版。github程式碼提交不正確。
24	24	10	10	20		40	主要問題： 1）需求分析並沒有按照NABCD格式來。 2）沒有原始碼，只有介面截圖。
25	在路上	25	25	25		75	主要問題： 1）NABCD基本理解正確，但是C項（競爭）還是不太具體。 2）程式碼沒有上傳至github，部落格中只有截圖，沒有關鍵程式碼解釋。
26	Duang~	25	32	28		85	主要問題： 1）NABCD理解基本正確。C項（競爭）還是沒有說服力，作為一次作業，整體上還是比較好。以後這種文件用語請使用書面用語，不要口語化。 2）原始碼解釋非常詳細。github提交原始碼還是有問題，具體方法參見之前助教@沉默的程式碼 的一篇部落格。 3）大檔案傳輸怎麼解決
27	lemon tree	0	15	0	-10	5	主要問題： 1）NABCD部分有抄襲行為。 2）原始碼提交正確，但部落格中並沒有給出關鍵程式碼說明。 3）執行總結部落格沒有提交。提交後請聯絡我。
28	Braveheart	20	25	25		70	主要問題： 1）NABCD雖然每項給出的內容說服力不足，但是理解基本到位。 2）原始碼沒有提交。
29	29	0	0	0		0	沒有正常提交部落格 最後的執行總結涉嫌抄襲
30	自強不息	10	20	20		50	主要問題： 1）NABCD理解錯誤。 2）部落格中程式碼沒有說明，全部複製貼上。也沒有提交到github。
31	Fighting	15	15	20	-10	40	主要問題： 1）部落格排版格式很好，但對NABCD的理解不太準確。 2）設計部分詳細，但是我看不到原始碼在哪裡？原始碼提交後請聯絡我。 3）看不見執行截圖
32	狼圖騰	12	25	15		52	主要問題： 1）需求分析沒有按照NABCD格式。寫得比較詳細。 2）沒有提交原始碼。 3）總結部分涉嫌抄襲
33	飛躍隊	5	15	25		45	主要問題： 1）NABCD理解錯誤，而且還不完整。 2）部落格中原始碼沒有註釋，全部賦值貼上，也沒有提交。
34	Melanoma	5	0	10	-10	5	主要問題： 1）NABCD理解錯誤，還沒寫完整。 2）部落格沒有按時提交。提交部落格後請聯絡我。 3）沒有執行截圖。
35	日光微瀾	10	25	25		60	主要問題： 1）需求分析沒有按照NABCD格式。 2）原始碼沒有提交。 3）總結中應該列出遇到的一些問題，怎麼解決的
36	團成團	15	15	25		55	主要問題： 1）NABCD理解有偏差，沒有D項。 2）原始碼提交不正確，部落格中也沒有對關鍵程式碼進行說明解釋。
37	瘋狂的程式碼	10	25	20		55	主要問題： 1）需求沒有按照NABCD格式，套話太多。 2）不應該使用控制檯輸出結果
38	Run Up	25	30	15	-10	60	主要問題： 1）部落格中貼進去的程式碼最好給出詳細說明。 2）將總結補上。聯絡我。
39	翻滾吧程式碼	10	20	5		35	主要問題： 1）NABCD理解有錯誤。 2）程式碼沒有上傳。 3）總結部分涉嫌抄襲。
40	齊工合夥人	20	20	10		50	主要問題： 1）程式碼沒提交，設計和實現不一致
41	憤怒的5只小鳥	5	25	25		55	主要問題： 1）NABCD理解錯誤，缺少D項。 2）程式碼沒上傳。
42	42	20	15	5		40	主要問題： 1）NABCD理解基本正確，缺少C項。 2）程式碼沒上傳。 3）最後做的跟前面需求分析不一致
43	遇見	15	15	5		35	主要問題： 1）NABCD部分內容跟前面團隊有重複 2）程式碼沒上傳。
44	毛毛蟲	20	28	20		68	主要問題： 1）NABCD理解基本正確，缺少D項 2）程式碼提交還是有問題。

 

建議

[2015.6.22更新]

經過3次作業訓練，原始碼提交、部落格排版等這些基本簡單技能同學們幾乎都沒有完全掌握。我覺得這兩個是今後網上教學的最基本前提，如果學生連這兩個技能都沒學會，網上教學很難推進。

任何一次作業，凡是自己動手、動腦子去做的，均可以得不低的分數，都值得鼓勵。那種抄襲、自己不動手去做的均給零分或者低分。我建議老師們鼓勵學生多自己動手，哪怕做得不好，也不要抄。

 

2015上半年軟工助教總結（2015.7.6）

[1]各位同學請抓緊時間下載軟體工程自我評測表，填寫後提交至 zhouzhi@syxysoft.com。這裡是模版。

[2]本次最優團隊部落格(23~44組)是：http://www.cnblogs.com/bbker/

我是4月底受周筠老師邀請做軟工助教的，抱著共同學習共同進步的心態，我很欣然地同意了。但我本科畢業才四年，我很清楚記得我讀書時周圍學生的學習態度是怎樣的（雖然這可能跟學校有點關係），所以當時覺得助教在網上輔導這件事推進會很困難，但後來兩個月裡我發現在大家的共同努力下，推進效果還是很明顯的。

剛開始輔導的是貴師大的學生，發現他們基礎還可以，後來由於某些不可抗力因素，換到了齊魯工大的學生。點評第一次作業的時候，說實在話，我覺得跟貴師大的差別還是蠻大的，基礎普遍不太好，無論是從部落格排版還是程式碼格式上，均不太理想。記得當時我還跟周筠老師反饋過，她讓我耐心一些。後來點評第二次作業的時候，發現大部分學生的進步非常明顯，可能趙老師在第一次作業結束後在班上總結了幾位助教的建議，學生們有所收穫。總之，第二次作業讓我看到了希望。再後來就是團隊作業，我在前面點評總結中也說過了，可能這次作業難度較大，跨越時間較長，涉及的知識廣，所以最後完成的效果並沒有達到我的預期。當然這不是重點，重點的是很多學生涉嫌抄襲，應付了事。學生們這種行為不僅會讓教軟工這門課的老師失望，也更會讓我們這些助教失去激情。（當然涉嫌抄襲的學生是少數，大部分學生雖然完成質量有待提高，但是都是自己動手去做的）

還有一個我搞不太明白的是：為什麼三次作業過去了，部落格排版、github程式碼管理等這些簡單技能，作為軟工學生大部分人硬是沒有掌握呢。我不認為這些有技術難度，因為凡是上心想去做好的學生這兩件事肯定可以做好。一開啟部落格，格式錯亂，幾乎不忍直視，原始碼提交還用txt... 

總地來講，我很享受這學期的網上助教點評，雖說小部分學生的表現不是很積極，但是大部分學生還是做得不錯，很多私信我諮詢問題，值得鼓勵。有做技術的前輩指導，對於在校學生來講，我覺得是一件來之不易的事情，希望童鞋們好好珍惜，我那時候讀書很少碰到這樣的機會，很多問題上論壇問，最後也石沉大海了 ：）  同時，感謝趙老師、周筠老師、鄒欣老師、飛龍大哥助教、曾助教，一起共事很快樂，再接再厲額！ ：）