這個做業屬於那個課程 | <課程連接> |
這個做業要求在哪 | <做業要求> |
團隊名稱 | 軟件夢之隊 |
這個做業目標 | 總結每位團隊成員在本課程的得失 |
學號 | 姓名 |
201731041215html |
王陽git |
201731062302程序員 |
鮮雨珂github |
201731062128算法 |
鄧捷編程 |
201731062305網絡 |
周蓉svn |
201731062131函數 |
龍繼平工具 |
201731062304 |
楊夢欣 |
201731035120 |
張欣 |
201731062301 |
梅晨 |
王陽 201731041215:
閱讀做業博客連接: 博客連接
博客要求內容:
1.Goto語句在大量使用時會使程序結構化設計被破壞甚至極大的影響程序的可讀性,可理解性,爲什麼這裏又提倡使用呢,爲什麼不能專門寫一個異常出口函數來進行呢?
答:並不是每種狀況都適合goto語句,可是當有多種選擇時,如有goto,那麼goto是最好的選擇,由於他很簡便,同時在某種程度上少去了if—else跳轉的程序多層嵌套狀況,而只須要幾個goto,那麼能夠大大提升程序易讀性。
2.那若是對於動態語言/腳本語言(例如 Python等),又該如何呢,編譯是自動完成同時採用動態步進,像這種語言編寫的模塊是直接嵌入而後進行測試仍是隻進行單步調試過程呢?
答:對於大型的項目,每一個模塊都必須有相應的單元測試,同時每一個模塊都必須進行調試以及單元測試,纔會進行集成測試。
3.這個基準線到底該如何肯定,對於一個大型軟件包含上百模塊時,採用迴歸測試,這個基準線該如何去評定呢,而回歸測試大多采用自動化方式,不可避免這個測試模塊自己也會出現問題,這時候又該如何去處理呢?
答:每一個項目的基準線並非一開始就固定的,而是對於整個項目進程進行動態變化的,而對於測試模塊自己的問題,通常項目開發測試與開發是由不一樣的人進行的,根據採起的測試方法不一樣,而採用不一樣標準,而且測試並非僅僅進行一次,它是會貫穿整個項目,因此儘管測試代碼也會有問題,可是對項目測試並不會有太大影響。
4.在需求不斷變化的同時如何準確地對客戶需求進行分析呢?保持簡明的同時如何讓整個軟件開發流程條理清晰呢?簡明的同時應對不斷變化的需求,對於文檔的改動是否過大呢?採用敏捷流程開發又該如何去適配開發流程呢?
答:敏捷開發就是專門針對與需求不斷變化的開發方式,敏捷流程採起每日任務的方式,與需求方一塊兒工做,對於不斷更改的需求每日都會有解決方案,敏捷流程並非一種固定的開發方式,正如其名,它也是不斷變化的。
通過這學期的學習,你掌握到了哪些之前沒有的技能,你是如何掌握的:
通過一學期的學習,學習到了不少軟件工程的理論知識,同時對一些理論進行了實踐、驗證。在這過程當中學習了許多工具的使用,如:原型開發工具Axzure,專業畫圖工具Visio,對源代碼管理工具GitHub加深了了解。
有什麼深入的體會,對本身一學期學習過程的總結:
最大的收穫是明白了軟件工程不只僅是寫代碼,甚至能夠說寫代碼只是其中一個很小的環節,重要的是對於整個系統的需求分析,設計,以及小組合做。
鮮雨珂 201731062302
楊夢欣 201731062304
閱讀做業博客連接:博客連接
博客要求內容:
代碼複審 4.4
文中提到代碼複審有三種形式:自我複審、同伴複審和團隊複審。
個人疑問:最好是有經驗、熟悉代碼的人來複審,而代碼做者必定是最熟悉本身代碼的,但他本身複審,會有思惟的侷限性;若是同伴複審,就不存在思惟的侷限性,那麼是選擇一個同伴複審,仍是兩個同伴複審,甚至更多呢?若是是團隊複審,最大的侷限是效率不高。那麼三種方式該如何抉擇?
答:通過我的項目、結對編程和團隊項目的實踐,本人認爲主要根據項目的大小來選擇代碼複審的形式。像我的項目就是自我複審;結對編程就是同伴複審;而團隊項目,通常來講,同伴複審就足夠了,如果項目比較大,又是特別核心的部分建議團隊複審。
結對編程 4.52
書中舉有例子:越野賽車和駕駛飛機,二者共同特色是在高速度中完成任務,任務有較高的技術要求,任務失敗的代價很高。
個人疑問是,開發程序時,什麼樣的狀況是相似於文中舉的例子,須要進行結對編程?是否有公司實行過結對編程?效果如何?對於合做的兩人,是兩人水平至關,仍是一高一低?有什麼特別的具體的要求嗎?合做兩人的適應期通常是多長時間呢?
答:看了書本,我想應該是時間緊張的狀況下須要結對編程。確實有公司進行過結對編程,如Microsoft(Bill Gates, Paul Allen),Apple(Steve Jobs, Steve Wozniak),Yahoo(Jerry Yang, David Filo),Google(Sergei Brin, Lawrence Page),效果都不錯。對於兩人的水平沒有什麼要求。他們的適應期須要經歷四個階段:萌芽——磨合——規範——創造。最重要的是如何磨合:向同伴提供容易接受的反饋意見時,採用三明治法。
與顧客合做 7.2.9
文中提到MSF強調產品團隊與顧客的交流合做,由於「我以爲」和「用戶以爲」是兩碼事。
個人疑問:那麼遇到哪一種類型的問題須要與顧客交流?大概多久進行一次呢?如果交流時遇到「對牛彈琴」的狀況該如何處理、如何交流?
答:本人認爲遇到業務領域的問題,須要與顧客屢次且深度交流。交流頻率主要視實際狀況而定。若交流有障礙,能夠進行一些調查方法:跟班做業、開調查會、請專人介紹、詢問、設計調查表請用戶填寫等,再設計出原型圖與顧客溝通交流。
目標、估計和決心 8.6.1
文中提到若是咱們混淆了目標估計和決心,那就會犯錯。其中軟件時間的估計是多個估計值的乘除法(估計的需求、估計的複雜度等等)。
個人疑問:那麼,究竟每一項估計該怎麼估計才比較準確呢?
答:上課時老師有提到項目作多了,天然而然就估計偏差就越小。每一項的估計仍是得看經驗吧。
參考文章:http://www.javashuo.com/article/p-yzfbuaqp-kv.html
PM作開發測試外的全部事情 9.3
文中提到微軟公司有好幾類PM,以及一名優秀的PM應有的能力。
個人疑問:不管是哪一類PM,是都必需要擁有文中所列舉的那些能力嗎?仍是說負責內容不一樣,有不同的要求?
答:書本中提到三類PM,分別是:Product Manager(產品經理),Project Manager(項目經理),Program Manager(微軟的職位名稱)。成爲 一個合格的PM必需要擁有如下能力觀察、理解和快速學習能力;分析管理能力;必定的專業能力。所以對於負責內容不一樣的PM,他們需必備的專業能力是不一樣的。
總結:
通過本次課程的學習及項目實踐,瞭解了軟件工程的原理,確確實實體驗了一次軟件開發。最大的收穫不是在課堂上學習的,也不是最終答辯所展示的,而在於整個軟件開發過程所經歷的,學習到的知識。
鄧捷 201731062128
閱讀做業博客連接: 博客連接
博客要求內容:
一、第七章第二節:其中提到的MSF基本原則中有一條是「充分受權和信任」,但咱們如何保證在給予了充分受權和信任的狀況下,團隊成員可以按時按質的完成本身的任務,不敷衍了事?
團隊項目是團隊成員的共同責任,不只須要隊員的自覺性,隊友在項目完成過程當中也應該相互監督相互提醒。
二、第十四章第二節:講到測試人員,假如開發人員每一個人都對本身的代碼進行了初步的測試,而且有些公司的人後期也會使用本公司的產品,使用過程當中也會逐步發現一些BUG,那麼在這些狀況下測試人員的做用會不會逐步的下降甚至變得無關緊要?
不會,測試是軟件編碼過程當中的重要一環,也是軟件質量的重要保障,測試人員系統的測試更能發現一些開發人員自身沒有發現的問題,對軟件的完善有很大的推進做用
三、第八章第三節:說到對用戶需求的獲取,提到了調查問卷的方法,但現實是大部分的調查問卷都並無獲得用戶足夠的重視,或者有些用戶即便認真回答了也不必定可以獲得調查人員的正確理解,或是提出的意見並無足夠的價值,在這種狀況下怎樣保證瞭解到的需求是有意義的?
除了最開始對用戶調研,開發人員在軟件開發過程當中也應該常常與用戶溝通,在軟件每完成一部分的時候
四、第八章第六節:提到軟件工程師對實際花費時間的預估公式,但如何保證本身對事件的估計時間在合理範圍內,若是低估了時間又該怎樣彌補?
這個主要應該靠開發人員本身的經驗積累,低估了時間就只能想辦法拉快進度
五、第十三章:怎樣識別軟件的故障是內部問題仍是外部問題?
通常是先軟後硬的原則。從新分區,低格全部分區後用標準系統安裝盤重裝系統,若是故障依舊,那基本是硬件問題了。
我的收穫:
認識到在項目完成中文檔與類圖,用例圖,時序圖的重要性,軟件項目不是一我的的事情,更多的是團隊的交流協做。
周蓉 201731062305
閱讀做業博客連接: 博客連接
博客要求內容:
對於問題一:當初覺得程序正確,若是加上正確後面的程序,是不會出錯的。在團隊合做中,本人體會到隊長在合成咱們的各個模塊的時候,後面新建的模塊若是出了問題一樣會影響前面的功能,邏輯,物理結構,特別是傳參數的時候,一但新構建的模塊出了問題,它的輸出,停止都會影響後續的模塊,之前模塊功能的正常使用。迴歸測試能夠找出退化的軟件(有了新模塊,可能功能崩了)的錯誤,改進軟件。這也是
軟件測試的目的是爲了發現錯誤而執行程序的過程;測試是爲了證實程序有錯,而不是證實程序無錯(發現錯誤不是惟一的目的)
對於問題二:這個問題,本人想結合下在面向對象課程中一些體會,線下調查已有軟件知足了用戶什麼需求,用戶體驗或者說別人想讓軟件工程師實現什麼。而在需求分析中,咱們構建的任何想法,其實都是創建在人類須要,既有需求的目的去開展的。
做爲製做軟件的成員,在最初就用該對使用用戶有個定位,事實上咱們對它應該完成了可行性分析,那麼在調查問卷問題設置上就是有方向的,經過定位人羣去找到有效反饋。
需求獲取主要方法:文檔「考古」法,用戶表明訪談法,問卷調查法,運營數據分析法,同類方案研究法,虛擬用戶構想法
對於問題三:得知,產品經理就是經過了解用戶需求去設計原型給軟件工程師實現,那麼正確的獲取需求,我想在之後工做中才能獲得解答(若是有機會的話,考慮的前進方向中了)。
對於問題四:創新,本人對於它的理解有了新的體會,用戶體驗其實也是「新」的東西,同類型的軟件,勝出的地方就在它給用戶帶來的感受,just like QQ and TIM,後者就更爲簡潔,這也是創新呀。技術的創新,在原有的技術上實現算法,或者結構上的改變,使得更爲簡單。
對於問題五:在團隊項目中,本人是貢獻最少的吧,隊長分配「網絡編程」模塊給我,可是我最終也沒完成,回首過來,我纔是「抱大腿的人」。我想團隊合做中,團隊意識最重要吧,有榮與焉,你們都在學新東西,菜雞也是要有團隊榮譽感的,固然也有關隊長的分配了。
總結:
解答完本身的問題,回到「無力」,「愧疚」,「羨慕」這三個詞語,是我在本課程的體會。在結對編程中,我是參與其中,本人十分感謝隊友在他的博客中給我留足了面子,在我在爲某個版塊費勁頭腦的時候,隊友已經完成功能,而最終我完成的模塊,卻成爲敗筆,多餘的,我是很受打擊的。在項目中,我忘不掉,我跑去圖書館一層,打着手機燈在書庫裏面找網絡編程書的過程,當時我內心的愧疚已經打敗我害怕黑的感覺了。連續幾周都在看網絡編程,連作夢都是。哭過,由於「無力」。在項目展現中,我"羨慕"那些優秀的同窗,由於我一無可取。
很惋惜的是,臨了了,我仍舊沒有找到本身的專業方向,可我真的很想在互聯網專業從事一些工做啊。本人邏輯思惟真的不好,編程對於我來講,或許準確的來講算法,日常人一兩遍就能弄好,我可能要十遍,寫上不少頁紙才能弄懂。
掌握的技能:自學,專一,需求分析能力。新的問題:如何在團隊中起到做用?
最後很感謝在團隊合做中隊友們對個人幫助和鼓勵。
龍繼平 201731062131
閱讀做業博客連接: 博客連接
博客要求內容:
問題一:在瀑布模型中十分強調文檔的做用,那麼在其餘開發的過程當中是否也須要嚴格編寫文檔?還有文檔的做用是否過於誇大,我也據說過,過於詳細的文檔不如沒有,那麼文檔要多仔細爲好?怎麼樣把握度量?
個人理解:我在這門課程的過程當中開始理解文檔的重要性。老師不斷給咱們強調文檔的重要性。一個好的項目80%的時間是在設計文檔。20%的時間用於把文檔實現爲代碼。在大型項目時,文檔是必須的,文檔也是越詳細越有條理符合規範爲好。在我的小項目時,能夠省略部分文檔,只寫重要的設計部分文檔。
問題二:在這一節提到「咱們要在競爭性的環境中實踐軟件工程,那就要作實用求創新的項目」,那麼在需求分析的時候,是以創新爲主仍是穩定爲主?如何處理需求與創新之間的矛盾?如何可以使需求合理化,符合軟件設計要求?
個人理解:需求分析時以穩定爲主,咱們的目標是設計符合客戶要求的軟件,因此第一要素是知足客戶需求,其次再是創新。需求設計要實事求是,不要天馬行空。
問題三:在開發過程當中不一樣程序員的進度不一,若是程序員更新錯了代碼會不會致使程序崩潰?那麼在管理源代碼過程當中會不會出現版本衝突吶?在版本衝突的時候如何回退前一個版本?回退事後開發進度會不會跟不上任務要求?
個人理解:源代碼的管理通常是由svn的版本管理工具管理的。使用十分方即可以實現代碼的對比,而後在上傳,也可以實現版本回退。
問題四:在進行效能測試時,每每都會測試不過全面,有時候也不可以達到測試的條件,在這種狀況下如何測試?怎樣才能使效能測試更加全面,高效?
個人理解:效能測試要涉及測試代碼的每個方面,儘可能的作到測試全面,測試也應該覆蓋每個條件的分支,並獲得想要的結果,才能測試全面。
問題五:這裏介紹了軟件的各個版本,beta也就是咱們常說的嚐鮮版,一般嚐鮮版會有各類bug這個版本的發佈會不會影響用戶體驗?其次各個版本之間如何有效的辨別?
個人理解:beta版本基本能夠正常使用,beta版本測試是爲了提升測試的效果,可以有更多的額人員參與軟件的使用,從而發現問題修改問題。其次beta版本也是通過了必定的測試階段,基本不影響正常使用,有的只是微小的bug,也多是爲了軟件開發的新功能,來獲取用戶的反饋,從而更好的開發軟件。
總結:
我學會了UML繪製類圖,用例圖,時序圖。在團隊項目的開發過程當中,我開始認識到文檔和溝通的重要性,我在這門課最大的收穫就是開始正視文檔,明白了軟件工程這個專業不只僅是技術,而咱們更多的是學會去寫文檔,而後實現爲相應的軟件。
張欣 201731035120
閱讀做業博客連接: 博客連接
博客要求內容:
問題一:
在教材中第二章我的技術和流程中,所講到的單元測試,是對軟件項目中的每個小的模塊進行test,是對後面工做的正確性的保證,同時也是以後的單元測試的基礎,其中提到的代碼的「覆蓋率」,當時學C語言時有頭文件,當寫一個函數時,須要到頭文件的那個文件夾中區尋找相同的功能代碼,覆蓋並運行,不知道我這種理解是否是正確。
答:所謂實踐出真知,真正的去實踐事後,才能更加深刻的去理解本身的疑問,通過課程的各次實踐,本身明白了覆蓋率究竟是怎麼回事情,可是就像我知道了1+1=2同樣,可是依然不知道爲哦什麼1+1爲何就是等於2同樣,不知道在究竟是怎麼樣編譯器能夠知道已經對代碼路徑實行了覆蓋。
問題二:
在學軟件工程的課程的同時,咱們也在學數學建模的課程,在數學建模的課程上,老師講了一個尋找臨界點的問題,當時大多數同窗都回答,找幾個臨界點的值,進行帶入計算測試,而老師說,這個就是咱們在接受軟件工程教育是固有的思惟模式,我在想這種思惟模式是通過多年的思惟習慣以後造成,會不會被困於這種思惟模式跳不出了。
答:每一個人都有本身在通過多年的事和物的磨練以後所造成的固有的思惟模式,在通常狀況下,倒是是沒法跳出本身的這種思惟模式,可是在之後能經歷更多的事以後,每一個人的能力以及想法也都會發生變化,可否跳出來,也算是本身的一種能力。
問題三:
1.在壓力測試中,沿着時間軸延長,通常模擬48小時的高負載才能認爲系統經過測試,在如何模擬,是對其中的數據進行調用模擬仍是,尋找真正的用戶進行模擬;如若沒有經過測試,系統崩潰以後,咱們應該採起什麼樣的措施來補救?
答:在這個問題中。因爲在項目的開發中本身並無負責這一部分,因此也沒有更深刻的去針對這個問題進行求證,本身將在之後的學習生活當中,對這個問題進行實踐而且求證。
2.一樣也是test的問題,是在教材中第十三章軟件測試中所講的A/BTest,其中用了奧巴馬競選的例子來講明,A/BTest是同時爲用戶提供多種服務,仍是隨機測試,或者在給用戶提供服務以前,讓用戶進行選擇,本身想要的服務。儘可能在測試的時候講損失降到最低。
答:不管是作事仍是作人都要勇於去作出嘗試,纔能有更好的發展,而作軟件應該也不會例外.
問題四:
在課上講的是在能夠在開發代碼完成以前,先寫好測試代碼,而在教材中的第十三章中講到,開發時有開發說明書,測試同時也是有測試設計說明書的,其中要是有些功能尚未作好,不知道功能的具體狀況,而時間有很緊急,這時候要如何去作開發代碼的測試?
答:這個問題因爲學姐的解答,以及本身在以後做業中的本身的理解摸索,代碼測試的狀況主要仍是是項目的狀況來肯定,並非必定要按照先代碼後測試的順序,而在現階段,我只經歷過先代碼,後寫代碼測試的模式,但願之後能嘗試進行先寫測試代碼的開發模式。
問題五:
在第三章軟件工程師的成長中,在對項目完成估計的時間上,有些多是比較常寫的代碼,但老是會用到不經常使用,或者是要去新學的知識,如何能更準確的去估計本身完成時間?
答:通常來講邊學邊作項目相對來講是否是很理想的,可是因爲我的自身的限制只能用這種方式,會大大的拖慢團隊的開發速度,因此必定你要在平時多積累知識,必要時候必定會用得上的。
問題六:
如何確保本身已經完成的代碼在簽入時和別人的代碼可以很好的對接起來,因爲對團隊開發流程的不瞭解,在這一部分上,仍是有不少的不明白。
答:這個問題依舊沒有明白.
總結:
有出現一些問題,可是在項目過程當中,通過同窗朋友的指點,已經解決.
通過這學期的學習,我的能力有了必定的提升,可是很不滿意,沒有很努力的去學習接納更多更好的知識;上學期只是簡單的運用VS編寫簡單的程序,這學期對VS有了更加深刻的瞭解;接觸並瞭解了代碼的測試方面的知識;高爾基說書籍是人類進步的階梯是很對的,從書籍中,我得到了許多之前不知道的知識.
相對於上一學期,我對這學期的表現更加滿意,可是仍然有很大的進步空間,但願本身能更加努力,越努力的人真的會更加美麗.
梅晨 201731062301
閱讀做業博客連接: 博客連接
博客要求內容:
一、過早優化的問題在於:過早關注不重要的部分,而忽略行動和目標自己。讓正確的程序更快比讓快速的程序正確要容易不少,因此,首先應該把注意力放在使代碼儘量性的清楚和可讀上,什麼時候進行優化應該根據軟件開發過程當中的實際狀況來決定。
二、結對編程是兩個程序員用一臺電腦,一塊兒工做。兩我的一我的是駕駛員的身份,另外一我的是領航員的身份,對兩我的並無什麼特別的要求,可是在結對的過程當中仍是須要相互磨合達到比較理想的效果,我以爲結對編程須要思考是如何將領航員的職能發揮到最大。兩人合做是一種合做關係,相互幫助。
三、軟件團隊的模式選擇我以爲跟軟件項目自己和軟件團隊能力有着不可分的關係,能夠結合項目自己和團隊自己狀況來選擇一種合適的團隊模式,合適的團隊模式在整個軟件開發的活動過程當中會比較容易解決問題,按時完成項目。
四、思惟侷限我以爲是可能會出現的吧,確定須要有專門的測試人員對整個軟件進行測試,這時候其實也包含了對代碼的檢測,使得軟件的出錯率更少。
五、https://blog.csdn.net/wang_lichun/article/details/7267948
總結:
通過一學期的學習以及相關書籍的閱讀,對於開始不懂的問題有了一些解答,在課程做業的完成過程當中,體會到告終對編程的好處,在編寫代碼有錯誤出現時,會有人及時提醒,在設計代碼的時候,能夠一塊兒討論,融合兩人不一樣的看法和觀點,得出更加好的設計思路,會避免一我的深陷BUG之中。在整個的團隊項目當中,也學習到了一些新的知識,同時深深感受到本身編程能力的欠缺,可是也有很多收穫,更加了解了軟件開發過程,學會了一些軟件開發過程當中必要的技能。
團隊項目Github地址:<連接>