軟體工程(QLGY2015) 第三次作業點評（含成績）

相關博文目錄：

第一次作業點評

第二次作業點評

第三次作業點評

本頁點評團隊1-22，其他組見：http://www.cnblogs.com/xiaozhi_5638/p/4490764.html

團隊編号

部落格園團隊部落格

1

FOR THE DREAM

2

思甜雅

3

平常心

4

沉睡魔咒

5

藍色夢想

6

進擊的代碼

7

追夢人

8

One Piece

9

四傻大鬧齊工大

10

粉末

11

Dream high

12

軟體工程學習小組

13

蹿吧 妮兒

14

代碼海洋

15

KING

16

奔跑的蝸牛

17

狩獵的時間到了

18

非常4+1

19

20

天天向上

21

翺翔的飛鷹

22

團隊部落格206

團隊項目裡一下子要做的幾個都是比較抽象的東西：

協作與分工

立項（NABCD大法。。）

功能設計

用例圖、類圖、時序圖等

測試計劃

前兩次作業分别是PSP和結對程式設計，上述幾個内容都沒有得到充分的有效訓練，導緻同學們做這幾個環節整體流于形式。不能抓住重點。

簡單确定團隊成員之後，不應該直接就分工了。一般來說立項是第一位的，如果不能确定軟體要不要做，要做什麼，分工有個屁用。而立項，根據《建構之法》，我們知道NABCD是一種有效的模型，大家稱為<code>NABCD大法</code>。不過我的角度看來，大家還隻是在字面意義上去使用NABCD了，有NABCD和沒NABCD差別在哪？我認為以上的其他部分都可以圍繞NABCD的去做。

那好，我們就說用NABCD了:

N，我認為N一定要分析目标使用者群，搞清楚：誰是使用者，他們的需求是什麼，現有的軟體解決了他們的什麼問題，沒解決的問題是什麼，然後，我們的Team才決定去做一個軟體解決這些使用者的需求。使用者可以是自己，也可以是班上的同學，也可以是網絡上的其他人，但一定要有使用者。沒人用，你做的都是無用功。一般來說，能搞明白面向的使用者是誰、能解決的核心問題，就是最基本的。需求也不是自己拍腦袋想出來的，多半你還是需要去和你的使用者溝通，做使用者需求分析，否則你想象出來的需求根本不存在，在整個項目周期内，需要反複從使用者哪裡得到回報。

A，這個地方你大可以針對N裡的需求做分析、設計。分析的話可以做個基本需求分析、進階需求分析、擴充需求分析等。設計，才是你們需要用上用功能設計、用例圖、類圖、時序圖的地方。

B，好不容易做了分析、做了設計。總得說下如果要去實作的話，做好了這個軟體。使用者會不會被吸引去使用，怎樣才能被吸引？B要思考的就是我們的軟體經過A之後，會不會根本不夠吸引使用者去使用，如果是的話，那就要傳回去思考N和A是否有問題。如果有問題，就一定要回歸分析、設計了。如果連自己都說服不了，不值得寫代碼。

C、如今早就是滿世界都是軟體了，你做一個一模一樣，完全功能都一樣，甚至更全的軟體估計都沒什麼競争價值了。那麼問題來了，怎樣才有競争力，競争力意味着别人死活都比不過你。這個就要絞盡腦汁的。

D、請傳回看你的N，如何讓他們用上軟體，解決他們的問題，并讓它們得到B，你的軟體他們會用多久呢？

以上幾個點，并非一次了事的事情，會貫穿整個軟體生命周期，需要随時更新和調整。然後，就開始開工了，無論是瀑布模型還是靈活開發，盡早往github上送出代碼啊。寫了一堆東西，一行代碼都沒看到呢？第一天就可以初始化項目目錄，工程檔案，趕緊往github上送出呗。一個月時間不抓緊怎麼能做出高品質的軟體。在經驗不夠的多的情況下，能一個team在一起協作多寫代碼才更真實吧，那些抽象的名詞也沒辦法不寫代碼隻寫部落格就能了解。盡早做出有人用的軟體才是真正的目标。

7月8日更新，重要：

程式部分裡的代碼送出部分單獨拆出評分，請還沒送出或者送出不完整的團隊，補交完整項目代碼，截止日期2015年7月15号。Fixed!

部落格作業逾期（超過一周）未提及的，會直接倒扣分數。

NABCD(10)

程式(10)

運作與總結（10）

代碼送出(10)

github

備注

總分（3:2:3:2）

截止時間

5月24

6月14

6月21

完整

80

71

68

7.5

完整（7月10号更新送出）

67

送出了單個檔案，無字尾名

請送出完整項目工程

65

送出了一個txt檔案

62

送出了一個Md檔案

59

無，部落格有代碼

57

項目不完整

56

54

51

48

有未實作代碼

46

送出了單個檔案，無字尾名（7月15号更新送出）

指令行版變成GUI版？請送出完整項目工程；7月15更新：重寫了指令行版的總結。

45

41

40

36

指令行版變成GUI版？,請送出完整項目工程

35

-5

送出了單個檔案，無字尾名（7月10号更新送出）

指令行版變成GUI版？,請送出完整項目工程,面向對象程式設計超過一周未送出

優：

總體上每個團隊還是堅持到了最後，完成了大部分必要的環節

一部分同學至少學會了完整送出github，如果能整個開發周期都在github上協作就更好了

項目的立項和分析，NABCD環節，總體上有了個初步的接觸，想必以後做其他項目的時候大家會想到這個大法

無論自己寫的還是基于已有代碼做的，都至少做了一些

劣：

老師布置的環節有的團隊沒做完整，比如面向對象程式設計，運作和總結

隻要少數幾個團隊認真送出了github，一部分送出了單檔案，另一部分沒送出，還有的沒看到代碼，也說明了團隊的程式開發并沒有全程使用github的版本化功能

有很多部落格内容摘抄的痕迹明顯，其實如果是引用别人的文章，至少要加引用說明，可以引用，但是一定要有結合自己項目了解并認真寫的部分，列個參考資料也比直接抄強

整個團隊項目過程中，可能是由于期末同學們忙于各種考試的原因，展現出工程方法的比較少

團隊的部落格裡應該說明團隊裡每個成員的實際做的事情，以及協作解決問題的過程中如何使用工程方法解決的，但很多團隊部落格隻寫了部落客自己幹了什麼

團隊項目代碼做的品質并不如結對程式設計的代碼品質，可能是由于期末的原因吧，多人協作的項目至少要有足夠的代碼數量吧，很多太簡單了，還不如結對項目

如果是基于已有項目的代碼，至少應該說明下，本項目基于之前誰誰誰的哪個版本的代碼上開始做，自己做的部分主要添加了哪些東西，最重要的是，自己做的部分是什麼

第一周個人項目的時候，一定要嚴格考核每個同學的Git使用能力。比如可以設定隻有通過Git考核的才能進入下一個環節（結對程式設計）項目，而不進入下一個環節就不能得下一個環節的分數，這樣甯缺毋濫的要求下，必然不會出現到了團隊項目還不會正确使用Git以及在Github上協同開發。單元測試也要嚴格通過。

結對程式設計的時候，一定要嚴格考核每個小組的編碼規範能力，以及兩人協同開發的能力。如果一個班級都采用一種語言開發，比如Java，那麼此時可以要求在教師指定的編碼規範裡挑選一種并且嚴格執行。協同開發，在Github上必須有兩人協作開發的fork-pull-request記錄。

團隊項目的時候，必須一開始就說明團隊部落格位址+團隊項目的Github倉庫位址。必須為團隊項目在第一天就建立團隊項目的Github倉庫，并且每個階段都必須有所有團隊成員的fork-pull-request送出記錄。

選題要說明是重新開發的項目還是在已有項目上開發，如果是在已有項目上開發，應該在NABCD裡重點說明已有項目的背景，及其需要改進的點，或者哪些新需求，這樣才能有的放矢，在後續的環節裡明确說明團隊改進和新增部分的内容，而不能用已有項目本身的代碼充數。

對于學生來說，還是應該圍繞可運作的項目代碼為核心，任何一個環節都應該保證Github上送出的代碼是目前可執行的。

可以的情況下，應該要求必須回報助教或者老師的建議，不回報者直接扣分，否則給出的建議都沒有跟進。