提問回顧與個人總結

專案

內容這個作業屬於哪個課程

2020春季計算機學院軟體工程(羅傑任健)

這個作業的要求在**

提問回顧與個人總結

第一次作業鏈結

第一次個人部落格作業

1.為什麼可以得出"顯然，從學生到職業程式設計師，並不是更加沒完沒了地寫程式—花在寫**上的時間反而少了許多"的結論

對於乙個軟體工程師來說,不管是**能力還測試能力都比學生高出不少,尤其是乙個軟體工程師所積累的程式設計的經驗往往是乙個普通學生所不能比擬的。多以同樣的面對乙個專案,軟體工程師可能很快就想到了實現的方案,這是最基本的要求。在基本的要求沒有壓力的情況下,軟體工程師會更多的去考慮**之外的問題,包括如何更加復合需求,如何進行完整的測試以保持軟體的穩定性,或者是如何盡可能的體高效能和魯棒性等等。那麼,對於乙個學生來說呢,由於**能力和程式設計經驗的不足,首先擺在其面前的一座大山就是如何實現基本功能,他往往是無力,或者說是有心無力去考慮更多的測試等問題的,因為要保證基本功能的完好,他是沒有餘力分配給測試太多的時間和精力的,否則一昧的考慮測試,反而會導致不良的後果。

2.是否只要有助於程式邏輯的清晰體現，什麼方法都可以使用?

我覺得,這裡指的是我們要學會變通,並不是真的為了程式邏輯的清晰表現就可以不擇手段了,它的意思應該是講,在一些時候,我們用一些"不一般"的方法可能會有利於程式邏輯的體現,這裡的不一般可能僅僅指的是不太常用,我們不能總是在所有地方都只用一套方法,而是什麼有助於程式的邏輯表現,我們用什麼,但是要杜絕使用一些極其危險的方法,這些方法可能會導致程式崩潰等一系列問題。

3.關於敏捷開發原則,面對面的交流始終是最有效的溝通方式嗎?

我之前以為,面對面交流可能反而有可能會阻礙彼此之間交流,但是經過一學期的軟體工程實踐之後,我才切身體會到面對面交流的好處。在這個學期中,我們幾乎兩三天,任務緊的時候甚至每天都開,在會議中可以隨時交流,並且相對於打字要來的更加便捷,表達也更為清晰,也可以隨時指導另一位成員寫**,可以幾個人一起討論,可以進行頭腦風暴......等等。所以,目前看來,根據實踐是檢驗真理的唯一標準的原則,關於敏捷開發,面對面交流的確是最有效的溝通方式。

4.是否所有的專案都必須基於其商業價值?

大多數的專案是都必須要基於其商業價值的,因為如果沒有了商業價值,就沒有資本流入,沒有資本流入,就缺少管理人員,開發人員等專案開發不可缺少的角色。同時,失去了商業價值,專案就缺少了外在的開發動力和目標,缺少了前進方向和迭代更新的動力,早晚會走向毀滅。但是,同時有一些專案的確是不以商業為出發點的,例如大名鼎鼎的linux系統最初就不是企業開發的商業級軟體,同時我們這個學期開發的專案也都大多不是商業性質的,同時還有一些公益性的軟體等等。所以,綜合來講,大部分專案是基於商業價值的,但是專案不是絕對必須基於商業價值的。

5.c在rasci模型中具體承擔的工作

c就是指的顧問,也就是負責為各個相關的角色提供諮詢服務。在軟體開發的過程中顧問是非常重要的角色,不管是面對技術問題,團隊會議還是專案的重大決策都需要顧問參與其中,在專案過程和決策環節提供意見,在專案開展前提出建議等。

1.在本學期理論課上雖然學習了相當多的敏捷開發知識,但是不知道如何應用,如果直接用又太過生硬,只是為了用而用,偏離了敏捷本身的意義.

2.在個人專案和結隊專案中,題目的難度是否過大,而且更像是乙個演算法問題,這樣會不會偏離了初衷使得學生疲於改進演算法,實現更能而不去關心如何在事件中應用敏捷開發的相關知識。在需求階段學習並使用了nabcd需求分析法,通過實踐切身體會到乙個道理,那就是開發者所想的需求和使用者的實際需求往往是有較大區別的。

提問回顧與個人總結

提問回顧與個人總結

提問回顧與個人總結

提問回顧與個人總結

相關推薦