軟件工程實踐總結

軟工ByeBye~

請回望暑假時的第一次做業，你對於軟件工程課程的想象

對比開篇博客你對課程目標和期待，「但願經過實踐鍛鍊，加強計算機專業的能力和就業競爭力」，對比目前的所學所練所得，在哪些方面達到了你的期待和目標，哪些方面還存在哪些不足，爲何？

開篇博客的課程目標和期待（包含當時心裏想法可是沒寫出來的）：
開篇博客連接

1. 痛並快樂着。
2. 可以在結束後懂得如何作好一個完整的產品；
3. 學到儘可能多的開發知識。
4. 能夠提升團隊協做、交流能力。
5. 加強本身的文檔撰寫能力。

已達到期待和目標

1. 痛並快樂着 = 過程真的是很痛苦，可是團隊做業時總體常常性被掛觀光車仍是十分快樂的。
2. 懂得如何作好一個完整的產品 = 團隊做業完成了咱們的產品記憶罐頭，目前能夠提供用戶正常的使用，做爲pm我也更好的懂得了要如何作好一個完整的產品。
3. 學到更多開發知識 = 在完成團隊產品過程當中因爲種種緣由我也參與了開發，完成的是記憶罐頭主頁的備忘錄條目展現和備忘錄刪除界面的前端部分，用無數個熬夜甚至是通宵學習了不少的開發知識。
4. 加強團隊協做、交流能力 = 身爲pm在此次軟工實踐中這方面的能力的提升與否，我相信在屢次的做業和團隊總分中便已經很好的體現。

未達到期待和目標

1. 加強本身的文檔撰寫能力 = 由於團隊中的分工比較明確，美工和文檔都有專業人士負責，因此本來打算藉助此次機會提升一下本身的文檔撰寫能力，貌似沒有什麼見長。

意想不到的收穫

1. 最意想不到的收穫即是作了pm而且收穫了這麼一大波的優秀的隊友們！！！擁有一個這麼優秀的團隊。
2. 再者即是一直是做爲本組的PPT製做者和演講者，很好的鍛鍊了本身的答辯能力，演講能力提升了很多。

總結這門課程的實踐總結和給你帶來的提高。

統計一下，你在這門軟件工程實踐中，完成了多少行的代碼；

根據本身不徹底正確的統計，參照本身的學習進度條，大概完成了3113行代碼。（固然確定存在一些誤差，可是應該是會比這個更多不會更少吧）

軟工實踐的各次做業分別花了多少時間？（作一個列表）

做業	花費時間（分鐘）	博客連接
自我介紹	10	博客連接；
第一次做業-開篇展望（包括完成評論部分）	720（估計）	博客連接1 ；博客連接2 ；博客連接3；博客連接4 ；博客連接5 ；
我的項目	1550	博客連接；
結對項目1	1560	博客連接1 ；博客連接2；
團隊風采展	240	博客連接1；博客連接2；
結對做業2	1890	博客連接；
團隊選題報告	1200（估計）	博客連接；
團隊課堂UML設計	845	博客連接；
團隊需求分析報告	1355	博客連接；
Alpha版本衝刺	6 * 24 * 60（估計）=8640	博客連接1；博客連接2；博客連接3；博客連接4；博客連接5；博客連接6；博客連接7；博客連接8；博客連接9；博客連接10；博客連接11；
團隊現場編程	1410	博客連接；
團隊項目測評（福大助手）	180	博客連接；
Beta版本衝刺	1440（估計）	博客連接1；博客連接2；博客連接3；博客連接4；博客連接5；博客連接6；博客連接7；博客連接8；博客連接9；博客連接10；
最終版本展現	360	博客連接；

哪一次做業讓你印象最深入？爲何？

要說最讓我印象深入的實際上是團隊現場編程的那次，由於那次是我軟工實踐裏的第一次通宵：），因爲種種緣由咱們沒有及時完成現場編程的做業，因而我和卉卉小朋友兩我的在快12點重頭開始碼，也正是由於經歷了這一次的通宵讓我認識到通宵貌似並不難，因而埋下了後面通宵許屢次我還不覺得意的隱患：），通宵都經過了，熬夜就更不在話下了，因而整我的就比較身心俱疲。可是！！！最重要的是，咱們那次的通宵並非沒有意義哈哈哈哈哈哈吼吼吼吼吼吼吼吼，咱們圓滿的拿下了第一名！！！而後在這裏還要好好的感謝一下陪個人卉卉朋友（要是能@就行了）！！！

累計花了多少個小時在軟工實踐上？平均每週花多少個小時？同時貼出開篇博客「你打算平均每週拿出多少個小時用在這門課上」的回答

累計花了...22400分鐘=373.333小時=15天(要我怎麼說：）)

貼出開篇博客回答（當時回答比較佛不明確但心裏打算了的）：工做日天天2-3小時，一週10-15個小時吧，四個月不停歇240個小時也沒我花的多啊！！！：）

在此由衷的感謝老師和助教，是大家，教會了我什麼叫作真香。

學習和使用的新軟件；

• 現場編程從新學習了Eclipce For JavaEE的使用
• 開發使用了Android Studio工具
• UML設計使用了StarUML工具和ProcessOn
• 結對做業使用了Python
• 固然還有咱們的產品：記憶罐頭！

學習和使用的新工具；

• 現場編程從新學習了Eclipce For JavaEE的使用
• 開發使用了Android Studio工具
• UML設計使用了StarUML工具和ProcessOn
• 結對做業使用了Python
• 我的項目中Visual Studio中的性能分析、代碼覆蓋率也學習使用了部分新工具的功能

學習和掌握的新語言、新平臺；

• 更加熟悉的使用java語言開發
• 對Python的基礎使用有必定的掌握
• 在web平臺上完成咱們的現場編程項目，對web端有更深的認識
• Android平臺開發有一個新的認識

學習和掌握的新方法；

• 在我的項目中知道了單元測試的意義和方法
• 在我的項目中學習了代碼覆蓋率的概念
• 在我的項目中對代碼進行性能分析對開發中優化代碼有一個比較新的認識
• 結對項目中學習了必定的Python爬蟲知識
• 現場編程中知道了web前端使用模板的魅力
• 在團隊開發中學習了Android開發知識
• 在團隊開發中掌握了Android中如何debug
• 在團隊開發中掌握瞭如何更好的答辯演講

其餘方面的提高。

• 首先在我的的答辯、演講、展現方面的能力在軟工實踐中算是獲得了一個很好的鍛鍊，十分感謝這樣可貴的機會
• 在團隊中充當pm角色，收穫了不少管理一個團隊的管理能力和推動一個項目的領導能力
• 本身能夠更好的處理衆多事情繁冗複雜的場景環境了，畢竟通過軟工實踐的打磨...
• 旁觀團隊的美工人員和文檔撰寫人員，多多少少這兩方面仍是有一些瞭解和長進的

寫下屬於本身的人月神話——我的或結對或團隊項目實踐中的經驗總結+實例/例證結合的分析

最深入的即是團隊項目實踐吧，做爲pm很慶幸擁有了一個最棒的團隊、最棒的隊友們。

經驗總結： 在任務安排的時候必定要遵循三個原則：具體、規範、deadline

三個原則含義：

• 任務具體到我的
• 任務完成的目標要給提早規範明確好
• 任務完成的截止時間要定好而且嚴格遵照

實例：
一次慘敗的教訓是現場編程吧，其餘的我都貌似遵照的比較好。那一次做業前一天晚上已經有準備，通知好你們是開發JavaWeb項目，使用Eclipce For JavaEE而且要安裝好須要的其餘工具配置好環境。而且要提早學習一下基礎使用，可是因爲沒有嚴格審查，我也沒有明確告訴隊友sevlet的坑儘可能避開等等。致使出現了後面全隊全部環境都配置好了的只有兩臺電腦，隊友敲了一下午卻由於陷入了sevlet的坑點沒有很大的進展，最終沒能按時完成做業，我和卉卉通宵作完...

分析：
分析天然就是要是我定好了每一個人作哪部分、必須配置好環境、提早學習基礎開發、提醒他們避開sevlet坑點......那麼，咱們就能夠完成的更快，效率更高，也不用通宵

更多的經驗吐槽能夠參見我以前的博客：Beta版本吐槽博客連接

對下一屆實踐的建議，或者對於開學初的你，對於大一的你，對於開學初的我，對於同期的TA們，對於後來的學弟學妹：

你有什麼想建議、告知和期許想要告訴他們呢？

建議：

• 第一個就是必定要選這麼課啊！！！會讓你跨入程序員的門...
• 第二個是必定不要在團隊中划水，認真完成本身部分的任務，這樣團隊才能持續發展而且保證本身學有所獲
• 第三個是好好保護本身的頭髮：）
• 最後即是期待看到大家真香的開篇博客

特別地，特別地，下一屆要不要中途換隊員（強制的、完全的從一隊換到另外一隊）？假設依舊是一個90+人數的大班

我以爲沒有必要的，由於在中途其實咱們有嘗試過交換pm的一次現場uml設計，我的感受這樣根本不能達到模擬職場中跳槽等等這種效果，而且有些團隊確實開發很不同啊，從新換過去8，90%是將會擔任划水的角色，不管從從新學習時間的角度或者是融入新的團隊配合方面，我的感受交換的話打不到效果，還不如不交換。

身在一個格外大的班級，競爭強勁，你認爲一個組的人數應當在多少比較合適？

我的感受一個組在9我的左右是比較合適的，pm+美工+文檔+三個前端+三個後端

我的/結對/團隊做業應該控制在怎樣的規模？

我的和結對做業按照以前的規模算比較正常，可是團隊做業中要是能夠不要再夾雜一些其餘的比較好，這樣顯得比較繁雜，對學生的精力活力會消磨的比較嚴重，專一於團隊項目的開發就挺好了。其餘的還要佔用過多時間感受有點不妥，好比現場編程那次。（我的見解）

這學期下來，你最感謝的人是誰？有什麼話想要對TA說呢？

最感謝的是青元同窗，其實全部隊友都很想感謝hhh，可是理性思考仍是青元同窗最想感謝，身爲前端小組長十分盡職，而且幾乎也全身心的投入到項目中，在我焦頭爛額的時候幫我分擔了不少。

對青元同窗說的話：
你雨露均沾的能力真厲害呀，每天能看到你和不一樣的女孩子自習耶（偷笑）

分析一下本身所處的團隊。軟件工程實踐是大學裏少有的認真的團隊協做經驗。《構建之法》上說團隊的發展有幾個階段，你的團隊都經歷過麼，最後到達了「創造」階段了麼？（參考《構建執法》第17章 人、績效和職業道德）

《構建之法》團隊發展階段

• 萌芽階段：就像小苗破圖而出，柔弱但充滿但願。團隊成員剛剛接觸到團隊的宗旨，同時頗有可能剛剛互相認識。團隊的目標沒有真正達成一致，而成員則很是依賴於團隊領導的指導。
• 磨合階段：就像一我的的青少年時期，充滿了對我的、同伴和團隊的疑惑和衝突。團隊不管大小都要客服困難，交付結果，你們不得不認真的面對問題，開展討論了。這些衝突不必定都是技術問題也許是關於角色、職責、相互關係。甚至是各自性格、文化的衝突。很多人都想成爲某個領域的「擁有者」（在軟件項目中，誰負責哪一個方面，每一個方面要怎麼作，等等）。同時也有一些人會以不一樣的方式進行挑戰。
• 規範階段：從磨合階段畢業進入到規範階段的團隊成員們就角色、職責定義和流程都取得了比較一致的意見。這一時期團隊具備如下特色。
  1. 團隊的工做流程和工做的方式獲得你們的承認。成員之間互相更加了解，欣賞各自能力和經驗，工做中相互支持。
  2. 領導主要扮演促成者和鼓勵者的角色，有能力的成員也分擔了必定的領導職責，並天然的得到你們的尊重。
  3. 隨着項目的開展，一些成文的或不成文的規則逐步創建起來了。
  4. 做爲一個總體，團隊要作什麼、不作什麼，都更加明確。團隊的信心更足，和其餘團隊打交道更有底氣。
• 創造階段：經歷以上三階段後團隊能夠創造一些有意義的東西，並非所喲偶團隊都能到達這一階段。擁有如下特色：
  1. 團隊知道爲什麼而戰，並將注意力幾種到如何創造、實現目標上。
  2. 高度自治，再也不須要領導的時時教誨與介入。不一樣意見仍會出現，但成員都以一種積極的心態和方式解決。互相支持，互相依賴，並保持各自的靈活性。

• 萌芽階段： 這個階段顯然是經歷過的，在最初始定下項目選題的時候咱們即是在萌芽階段，你們對於咱們的產品的目標完成的主要功能主要是經過我描述和討論好屢次以後才陸續肯定下來的。應該算是在alpha衝刺開發前團隊一直處於這一階段向下一階段邁進。
• 磨合階段： 這個階段的對我的和團隊中的疑惑感受咱們團隊倒比較少出現，由於團隊一直以來的答辯得分和成績都在前列，因此主要是出現成員之間的角色、職責、相互關係、各自性格、文化衝突。團隊其實在Alpha完成後Beta階段也出現了這種苗頭，由於配合不夠到位、存在一些誤會等等一些緣由，可是最終仍是算比較正常的解決和度過了這種現狀況。（我感受團隊無論在任何階段都在不斷的磨合配合的更好，因此不表明咱們在後面階段就再也不須要磨合）

團隊成績展現

團隊現場編程

UML現場設計

團隊展現

項目評測

需求分析報告

項目選題報告

• 規範階段：
  • 團隊已經有一些成文規則（開會作會議紀要、每隔2-3天進行反饋...）和不成文規則（開會地點：34#3 or 青卜 or 35#3）
  • 在Beta版本和最終版本階段我即是主要扮演一個促成者和鼓勵者的角色，把任務分配下去看結果的流程，apk通過13次迭代，其中有一些是我要求迭代修復bug，還有一些是隊員主動更新迭代，修復bug併發布打包新的apk
  • 團隊的信息更足，和其餘團隊打交道更有底氣這是必定的！從團隊每次做業團隊總分、答辯分數、文檔分數都高居榜首便能知曉。

團隊還沒有達到創造階段，可是咱們的記憶罐頭就是咱們創造出來的有意義的東西！！！

怎樣證實你學會了軟件工程？

研發出符合用戶需求的軟件

1. 咱們的產品在開發前作過一次市場調研問卷調查（樣本容量：線上93+線下110=203份），並完成了咱們的記憶罐頭商業企劃書。其中包括用戶對咱們產品功能的反饋餅狀圖，咱們產品功能十分符合用戶需求。

需求展現

1. 在完成產品後咱們邀請了86位用戶進行內測試用咱們的記憶罐頭,而且收集了用戶反饋問卷。

體驗指數展現

期待指數展現

經過一系列工具，流程，團隊合做，可以在預計的時間內發佈 「足夠好」 的軟件

咱們團隊在軟件工程實踐課程的機會之下，經過團隊合做完成了產品記憶罐頭！分別在Alpha版本階段完成產品的初始版本，Beta版本完善產品進行必定的bug修復，最終版本已經迭代13次完成產品的1.1.3版本，產品下載連接。

而且經過數據展示軟件是能夠維護和繼續發展的。

現軟件的可維護性和是否可繼續發展經過上面的用戶反饋問卷截圖便能看出。

體驗指數展現

期待指數展現

用戶需求期待指數超過4分的比例在70%以上，證實咱們的產品是可維護和可持續發展的。而且產品具備十分可觀的盈利方式和前景，對不一樣手機（三星、華爲、Oppo）應用市場的在線付費壁紙作了一個簡單的調研：

三星付費壁紙

華爲付費壁紙

Oppo付費壁紙

盈利點

能夠看出，咱們的核心創新點鎖屏壁紙展現若是可以達到美觀、友好的前提下，還能展現出用戶的備忘內容，那麼便徹底能夠藉助於付費壁紙已經廣爲人知的免推廣的自然優點！！！在每種壁紙單價較爲廉價的模式下，提升用戶購買慾，相信能夠很快的搶佔付費壁紙的一塊市場，這樣也爲後續的開發提供了條件和盈利但願。固然，這一切都須要在可以解決生成美觀壁紙展現備忘的這一難點的前提下。也正所謂難點即賣點！

記憶罐頭

產品宣傳視頻&&宣傳海報

記憶罐頭宣傳視頻連接

記憶罐頭宣傳海報

對着這個檢查表：http://xinz.cnblogs.com/p/3852177.html 檢查一下，本身若是去企業面試，這些常見的問題是否都能回答，並在此總結。

第零部分---基本數據結構和算法問題

這部分連接中的博客文章中沒有詳細的介紹。因此不能詳細的進行回答總結。可是根據我的對本身的實力的總結來講，在基本數據結構和算法問題上面比較薄弱，以前算法課程和一些專業課程的上機代碼實踐都不是很強，因此這方面還須要好好提升。

第一部分---硬的問題

面試問題	如今的回答	畢業時回答
最拿手的計算機語言之一，代碼量多少？	語言: C語言；代碼量: 10000+	暫無
最拿手的計算機語言之二，代碼量多少？	語言: C++；代碼量: 3000+	暫無
有沒有在別人代碼的基礎上改進代碼？	有的，軟工實踐就有這種機會。1. 結對項目 中和隊友配合完成做業；2. 團隊項目 中配合時須要在隊友基礎上改進。	暫無
你是怎麼讀懂別人的代碼的？	主要經過註釋函數接口的註釋來實現調用配合，須要內部修改時根據模塊劃分，看懂要修改部分的算法/功能註釋。	暫無
採起了什麼辦法來保證你的新功能不會影響原來的功能？	通常不會修改別人的代碼內部組織結構，主要經過調用，增長模塊來實現改進。	暫無
開發中碰到最複雜的bug是什麼？如何解決？	Bug: 安卓開發中自定義適配器裏的複選框內容緩存複用問題。解決方案： 未解決；採起每次使用都從新讀取，不復用方式暫行。	暫無
這個bug出現的緣由是什麼，在未來應該怎麼去避免bug再出現？	緣由: 對安卓前端開發不夠熟練。避免再出現: 若是經歷過這個bug，那麼在再次使用相似的控件寫相似的代碼便會更注意考慮這個問題。	暫無
如何測試本身寫的代碼？	經過單元測試。	暫無
如何測試別人的代碼？	經過單元測試。	暫無
掌握了多少種測試工具和方法？	只在軟工才知道單元測試這種東西，都只有一種吧。	暫無
寫過測試工具嗎？	沒有	暫無
如何對一個網站進行壓力測試和效能測試？	不會。好像隊友有會的，有機會能夠一波。	暫無
如何測試一個軟件的人機界面？	暫時還不會。	暫無
寫過的最複雜的代碼是什麼？如何測量和改進它的效能的，用了什麼工具，如何分析的？	結對做業熱詞提醒和爬蟲（兩人做業）。經過Visual Studio自帶的性能分析器和代碼覆蓋率測試的插件進行效能測試。對覆蓋率低的部分進行代碼。	暫無
你作過多少個有實際用戶的項目，用戶最多有多少？你的項目有什麼創新的地方？	有實際用戶的項目沒有作過，記憶罐頭有內測用戶，創新點以前的全部做業博客都很明瞭。	暫無
行業洞察力	暫時沒法回答	暫無
參與過項目管理麼？如何決定項目中各類任務的優先次序，有何理論支持？忽然發現項目不能按時完成，做爲項目領導有何辦法？	參與過。按照基礎和附加，核心和輔助來決定優先次序。若是忽然發現項目不能及時完成，首先是本身預估沒有留有足夠的緩衝時間，只有一個辦法就是將損失降到最小，儘可能提交一部分功能的項目。	暫無
你作過架構設計，模塊化設計，接口設計嗎？有何辦法？	沒有作過，只有在軟工課上才第一次接觸這接口設計這方面的知識，而在團隊開發中我也是是屬於前端。
你是怎麼作代碼複審的？你加入咱們的團隊以後，能幫咱們提升代碼質量麼？	沒有正式的作過代碼複審。沒法回答	暫無
你在各類開發平臺都使用過什麼樣的工具？Github上有分享代碼嗎？	使用過Visual Studio，Android Studio開發安卓，Eclipse For JavaEE 開發JavaWeb，有經過Github進行團隊協做並上傳代碼，技術博客如今也還在堅持，最高閱讀量爲5000+ 的博客。博客連接；	暫無
請描述你在項目中如何說服同伴採用你提出的更好的解決方案，如何說服懶惰的同伴加緊工做，實現團隊的目標？	若是是更好的解決方案，在我的說服不行的時候，我會採起團隊投票的方式來進行決策，這時候是最公平合理的，若是你們都不同意的時候，通常就要考慮方案時候真的是更好，固然存在少數例外。對於懶惰隊友，只有經過嚴格的紀律和懲罰機制 纔是最好的鞭策手段。	暫無
你上過什麼數學？計算機或其餘理論課？	上過高等數學，含有深奧的微積分知識，還有線性代數和矩陣分析，抽象的現實世界和計算機世界一個工具橋樑，還有離散數學，數理邏輯的推理推斷，機率論。專業方面有操做系統、計算機組成原理、算法與數據結構、數字與邏輯等等	暫無
整年級你專業排名多少？	這裏仍是不方便透露吧hhh，太丟人了.jpg	暫無

第二部分---軟的部分，在成長路上學到了什麼？

學到了不少hhh，這裏不知道要怎麼回答哎。

第三部分---團隊管理源代碼的水平

團隊對於管理源代碼的水平還比較弱。

閱讀軟件工程中關於代碼質量的的經典論文，從下列文獻中選擇一篇或若干篇，結合本身的實際作一個閱讀筆記（例如，本身寫的代碼質量如何，是否是一個大泥球，如何衡量本身代碼的質量）？從如下參考論文中選擇一篇或若干篇：

參考論文文獻：

[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.

[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605

[3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87

個性發揮，包括圖文、照片和創意等

Welcome to 404 Note Found. You can see nothing here.