【軟工】第 一 次做業 (閱讀做業)

前言

1.這個做業屬於哪一個課程?

2019春季計算機學院軟件工程html

2.這個做業的要求在哪裏?

第1次軟工做業要求linux

3.我在這個課程的目標是?

  • 瞭解並學習軟件工程的教學內容,完成課程任務,培養工程化設計和開發軟件的能力。
  • 提高在軟件開發中計劃、管理、測試和維護軟件的能力。
  • 理解團隊與我的編程之間的異同與優劣,培養團隊協做能力。

4.這個做業在哪一個具體方面幫助我實現目標?

閱讀《構建之法》,至關於完成對整個課程的第一遍預習數據庫

閱讀做業

問題一:"軟件人體工學"何解?(1.2 軟件工程是什麼)

「······軟件工程和下列的學科相關:計算機科學、計算機工程、管理學、數學、項目管理學、質量管理、軟件人體工學、系統工程、工業設計和用戶體驗設計。「編程

初次看到這段話的時候,我愣住了,」軟件「和」人體「有什麼關係?隨後我百度查找了「軟件人體工學」,但並無直接完整的解釋,百度所給出的相關檢索內容主要是關於「人體工學」的,例如,符合身體姿態的椅子,或者是能讓手握起來更加溫馨,有更多功能鍵的鼠標······其中,與軟件最相關的是軟件按鍵的位置,一個好的按鍵位置可使用戶使用起來更加溫馨和方便。但我仍是不太懂,個人困惑是,軟件人體工程就僅僅包含按鍵位置設計嗎?這是否與用戶體驗設計有重疊部分?學習

問題二:下劃線的存在乎義?(4.2.7 下劃線)

" 下劃線用來分割變量名字中的做用域標註和變量的語義,如:一個類型的成員變量一般用m_來表示,或者簡單地用一個下劃線」_「來作前綴。······」測試

結合我我的的編程經從來說,我不多使用到,甚至基本不使用下劃線。因此下劃線究竟被使用在哪些方面呢?它的使用是否僅是表明着一種規範呢?可不能夠不使用下劃線呢?插件

問題三:結對出默契的兩人爲什麼不能繼續在團隊中默契合做?(4.6 兩人合做的不一樣階段和技巧)

"······一些成文或不成文的規則逐步創建起來了······爲何這一節要講這麼多兩人合做的反饋問題?由於,若是軟件工程師連一對一的合做都作很差,不能有效地去影響同伴,讓合做雙方都能從中受益,提升水平,那你們就別扯什麼團隊合做這些事了。」設計

當我看完這一章以後,我意識到兩條比較重要的陳述:一,有效的結對編程能提高軟件開發效率和質量;二,從零到有默契的編程合做須要付出時間精力,運用編程技術能力之外的溝通技巧等,即完成這一過程須要必定的成本。課程規定結對編程者不得在同一團隊,同時課程規則也暗示但願原來不太熟悉的人能組成一個團隊進行軟件開發,因而我在思考,這樣的規定的好處是否在於能從無到有、完完整整地完成一次團隊開發,而它的壞處是否在於增長了在團隊建設和管理上的風險和成本投入,進而致使團隊成員在軟件開發的其餘方面上的學習精力和效率下降?因此在一個6人團隊中,獨立出一個PM是否能帶來團隊管理質量和我的工做效率的雙相提高?這種提高到底有多少?是否值得?code

問題四:團隊模式?(5.2 軟件團隊的模式)

看了那麼多團隊模式以後我在想,咱們團隊有6我的,能否採用「PM+測試+結對編程+結對編程」的模式?這樣的模式或許是你們所熟悉的,可以快速上手;PM與測試也可進行少許的工做;結對編程能提升成員的動力和效率。那麼這種模式的缺陷在何處呢?到底是否能採用這樣的結構?這是我正在思考的。htm

問題五:如何進行績效評定?(17.6 績效管理)

團隊規則中團隊貢獻分是團隊本身進行評定的,在看了多種績效考量的方法以後,我以爲應當採用以評比爲主,其餘考量爲輔的方法,這樣的評分方式是否合適?如何排除評比中來自非工做因素的主觀性判斷?是否應當在剛開始分工時就商量好?

「軟件」與「軟件工程」的詞源

「軟件」:1958年,John Turkey於「The Teaching of Concrete Mathematics」這篇文章中提出。
「軟件工程」:1968年, Margaret Hamilton於阿波羅計劃中提出。 (參考:https://linux.cn/article-4778-weibo.html

附加做業

冷知識:電腦病毒的設計初衷並不是是形成損害

史上第一款電腦病毒,居然是由防護技術專家Fred Cohen親手設計出來的。他創造電腦病毒的目的僅僅是爲了證實程序對電腦感染的可行性,從未但願藉此對電腦形成任何危害。但這款程序卻可以對電腦進行感染,而且能經過軟盤等移動介質在不一樣計算機之間進行傳播,於是命名爲病毒。後來,他又創造出一種主動式電腦病毒,主要目的是幫助電腦用戶找到未受感染可執行文件。

管理軟件優缺點

名稱 優勢 缺點
Git 速度快;功能全 熟練掌握有難度門檻
Mercurial 拓展性好;命令簡潔 支持功能不如Git
Trac 靈活,具備強擴展性 不支持多項目;須要安裝衆多插件
Bugzilla 檢索與數據庫功能強大 配置流程複雜

部分管理軟件流量排名

GitHub | 31,000,000
Bitbucket | 5,000,000
Launchpad | 3,965,288
SourceForge | 3,700,000
GitLab | 100,000

-- 參考

相關文章
相關標籤/搜索