以下都是根據自己的真實感受，一字一字打上去的，並非抄襲搬弄。
1.這次課程改革在老師，助教以及我們學生的共同努力下，雖然也有一些瑕疵，但作為課程改革的第一槍，還是比較圓滿地落幕了。我想說的是，這次改革我收穫了很多，比以往的灌輸式純理論知識教學要好的很多。希望老師們堅持改革下去，讓更多的莘莘學子都能收到改革帶來的惠利。我的建議就是把軟體工程不要放在大三下學期（因為這是實習季，考研季，我們真的沒有那麼多時間去研究軟體），最好的是放在大三上學期，用一年的時間去認認真真，切實深入地做乙個專案，這樣的話就完美了。只有在時間充分的前提下，才會有高質量的程式。再乙個我認為作業的難度也應該按照梯度布置，逐漸加大難度，而不是一蹴而就，會打擊學生的信心。
2.課程改革，我們改變了以往的傳統教學方式，但是還是缺少一些類似於上機環節，讓老師和同學可以直接互動，這一點我們的老師沒有考慮到。但是整體還是不錯的，前幾次的作業都是老師布置的題目，我並沒有覺得這是限制我們的思維，因為畢竟我們是第一次做這種作業，需要老師們的引導；而最後一次作業，則是由我們自己選擇題目，在已經明白熟悉這種作業模式的前提下，發散思維，選擇自己感興趣的，我覺得老師的安排很合情合理。
3.首先一點，不管是個人作業，結對作業，還是團隊作業，我認為都應該有乙個與老師面對面溝通交流的環節，主要根據這個環節來評分。因為目前的作業都是網上提交，但部分都是文字，這就帶來了弊端，學生究竟是不是自己寫的呢，究竟會不會呢，我們無從得知，然後根據這個來評分，顯然也是不恰當的。而加了面對面的環節後，通過交流，你就可以立即發現端倪，那些濫竽充數的一下子就暴露無遺；真正有心去做的，即使做的不是很好，但老師也能感覺到你盡力了。這樣的話，評分才會有意義，才會更加切實實際。
4.在結對程式設計過程中，我首先感覺到的是智慧型的力量，乙個人始終是乙個人，但是兩個人共同努力做同一件事，當思想的火花產生碰撞，就不僅僅是兩個人那麼簡單了，各種問題都能解決。具體程式設計我們明確了分工，根據自己最感興趣最擅長的一部分去做，那大家都不熟悉的部分我們一起仔細討論來慢慢做。至於工作量，我覺得不是根據編碼的多少來衡量，而是根據對整個作業的貢獻來衡量，即使你只是想到乙個「點子」，並沒有寫出**，但是這對於整個作業是乙個突破性的地方，也是很好的。
5.首先我們的團隊專案成功了，如果重來一次的話，我覺得這在哪乙個團隊並不重要，只要這個團隊有責任心，即使大家都不是大神，那就不是重點。只要我們都盡心盡力，都會有過程中的收穫，就算沒有結果，我們都是進步了。還未踏入社會的我們真的不想以成敗論英雄，就像真正做學問的那些老人，他們一輩子都也許沒有什麼成果，但是他們卻花了一輩子的時間去做這件事，他們有所收穫，他們人生不空虛，如果沒有前人一點一點的積累，怎麼會有後人的重大成果。所以，只要是有責任心的團隊，無所謂哪個團隊。
6.因為我們的團隊分工明確，各司其職，只要在指定時間之前完成就行。加上部分是考研的，部分出去找工作，大家時間都不統一，具體的我也就不清楚了。但是每隔一定的時間，大家都會在一起彙總一下最近的工作進展。有什麼問題以及改進可以及時發現並予以糾正。
7.上面第乙個問題已經提到了，不贅述了。
個人附加作業
從貢獻度 完成度 完成質量 是否進步 比如因為專業知識掌握不多，第一次沒有做出來，但是通過學習，第二次能自己順利完成作業 等角度進行評分 在個人作業方面，增加個人進步這一注重點，在結對程式設計中，要考慮角色分配的比重與個人貢獻度 在團隊作業中，我希望能把alpha beta階段的團隊部落格拆分出來，...
個人附加作業
你認為每次專案的評分標準存在哪些問題，你認為的合理評分準則是怎樣的 個人 結對 團隊算三個 個人 對於評分來說，總體上還可以，每個具體的得分點列的比較清晰，圍繞整個專案展開，但是程式設計能力因人而異，有些同學相對薄弱，對於比較難的程式設計題目可能要比較長時間才能完成，然而假如老師的時間是一周之內，某...
個人附加作業
1 你認為每次專案的評分標準存在哪些問題，你認為的合理評分準則是怎樣的 個人 結對 團隊算三個 個人 在得知專案分的時候才看到具體的得分點，容易丟失細節分。合理評分標準 在發布作業時應該明細各個得分點，方便同學根據要求寫部落格。團隊 評分以部落格展示為主，未免有些不合理。這樣的評分標準對一些表達的相...