軟件工程———我的總結

1、回想開學初對於軟件工程這門課的指望，總結本課程對你帶來的提高：

1.學習和使用的新軟件

• Git
  Git是一款免費、開源的分佈式版本控制系統，用於敏捷高效地處理任何或小或大的項目。
  每個 Git克隆 都是一個完整的文件庫，含有所有歷史記錄和修訂追蹤能力，不依賴於網絡鏈接或中心服務器。其最大特點就是「分支」及「合併」操做很是快速、簡便。
  經過使用Git學會了如何建立本身的項目倉庫，建立分支，提交本身的代碼至本地倉庫，再pull遠程倉庫，便於團隊合做。也學會了如何解決他人代碼與本身代碼衝突的解決辦法。

2.學習和使用的新工具

• Enterprise Architect
  Enterprise Architect是一個全功能的、基於UML的visual CASE工具，主要用於設計、編寫、構建並管理以目標爲導向的軟件系統。它支持用戶案例、商務流程模式以及動態的圖表、分類、界面、協做、結構以及物理模型。此外，它還支持C++、Java、Visual Basic、Delphi、C以及VB.Net。
  Enterprise Architect在軟件工程課中主要用來畫Use case圖、類圖、順序圖等在工程開發中須要的各類圖。
• Markdown編輯器
  Markdown是一種可使用普通文本編輯器編寫的標記語言，經過簡單的標記語法，它可使普通文本內容具備必定的格式。
  Markdown的語法簡潔明瞭、學習容易，並且功能比純文本更強，所以有不少人用它寫博客。

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

• C#
  C#是微軟公司發佈的一種面向對象的、運行於.NET Framework之上的高級程序設計語言。並定於在微軟職業開發者論壇(PDC)上登臺亮相。C#是微軟公司研究員Anders Hejlsberg的最新成果。C#看起來與Java有着驚人的類似；它包括了諸如單一繼承、接口、與Java幾乎一樣的語法和編譯成中間代碼再運行的過程。可是C#與Java有着明顯的不一樣，它借鑑了Delphi的一個特色，與COM（組件對象模型）是直接集成的，並且它是微軟公司 .NET windows網絡框架的主角。
  C#是一種安全的、穩定的、簡單的、優雅的，由C和C++衍生出來的面向對象的編程語言。它在繼承C和C++強大功能的同時去掉了一些它們的複雜特性（例如沒有宏以及不容許多重繼承）。C#綜合了VB簡單的可視化操做和C++的高運行效率，以其強大的操做能力、優雅的語法風格、創新的語言特性和便捷的面向組件編程的支持成爲.NET開發的首選語言。
  結對編程時，使用C#編寫用戶界面比較方便，因此學習這門語言。
• MVC開發
  MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典範，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯彙集到一個部件裏面，在改進和個性化定製界面及用戶交互的同時，不須要從新編寫業務邏輯。MVC被獨特的發展起來用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。
  MVC的優勢是耦合性低、重用性高、生命週期成本低、部署快、可維護性高、有利軟件工程化管理。
  由於咱們作的項目是基於微信的藏醫藥平臺，因此在網頁設計這塊選擇了MVC進行網頁的開發。經過完成這個項目，也學習使用了通常的MVC開發。直到如何創建模型類，創建視圖，並經過控制器實現前端頁面與數據庫的簡單交互。

4.完成的代碼

大概在2000行左右吧，算上結對編程的計算器以及MVC的網頁設計。

5.學習和掌握的新方法

• 需求分析
  需求分析也稱爲軟件需求分析、系統需求分析或需求分析工程等，是開發人員通過深刻細緻的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化爲完整的需求定義，從而肯定系統必須作什麼的過程。
• 單元測試
  單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，通常來講，要根據實際狀況去斷定其具體含義，如C語言中單元指一個函數，Java裏單元指一個類，圖形化的軟件中能夠指一個窗口或一個菜單等。總的來講，單元就是人爲規定的最小的被測功能模塊。單元測試是在軟件開發過程當中要進行的最低級別的測試活動，軟件的獨立單元將在與程序的其餘部分相隔離的狀況下進行測試。
  經過單元測試，能夠解決減小軟件可能會出現的各類bug。這對於提升程序的可執行性有着極大的做用。
• 白盒測試和黑盒測試
  白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於代碼的測試。白盒測試是一種測試用例設計方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的，你清楚盒子內部的東西以及裏面是如何運做的。"白盒"法全面瞭解程序內部邏輯結構、對全部邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯着手，得出測試數據。
  黑盒測試也稱功能測試，它是經過測試來檢測每一個功能是否都能正常使用。在測試中，把程序看做一個不能打開的黑盒子，在徹底不考慮程序內部結構和內部特性的狀況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試着眼於程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。

總結與展望

1記錄本身在軟件工程課程上的經驗總結

• 軟件開發領域中的知識在於積累。

• 作軟件開發，就相似算數學題和世界盃足球賽同樣：重在結果，而不在意過程。

• 軟件服務於人類，軟件是在解決一些生活中的問題和錯誤，問題決定解決方案。
  遇到問題應該怎麼去解決？

• 不明白就多問，不要自已一直去琢磨。

• 一個問題若是30分鐘尚未解決就應該考慮是否是問問別人。
  怎麼樣才能作好軟件開發？

• 首先要明白解決的問題是什麼，理解問題，其次再決定怎麼解決這個問題。因此首要的事，需求分析必定要作好。

• 碰到很複雜的問題，咱們就簡單想，把問題簡單化，細化到可以實現爲止。

• 出了問題，咱們要先分析問題，而後知道引發問題的緣由，最後並想出問題的解決辦法。

  2對於下一屆的學弟學妹你有什麼建議和告知呢？

• 對於軟件工程這門課程，僅僅學會理論知識是遠遠不夠的，咱們要結合實踐加深增強對理論的理解。

• 要作好軟件開發，要有必定基礎的編程語言基礎，因此要在大一學好程序設計基礎這門課程。

• 軟件開發不是一我的能夠簡單完成的事（若是你的項目足夠大的話），畢竟一我的的能力是有限的，因此要學會團隊合做，發揮着各自的長處，共同完成項目。

  3分析一下本身所處的團隊。軟件工程實踐是大學裏少有的認真的團隊協做經驗。《構建之法》團隊合做的階段，大家團隊經歷過麼？最後到達了哪一階段？
  我所處團隊的項目是藏醫藥的微信平臺。團隊合做之初，咱們共同討論對於項目的需求分析，用戶分析，功能主體模塊分析。進入開發階段時，咱們肯定了團隊分工，任務分配。在項目測試階段，共同對項目功能的實現進行測試。可是其實，在團隊分工以後，團隊出現了嚴重的問題，由於各類緣由，項目的進度一再延後，主要是一些成員分工未能按時完成，致使最後你們又要去完成他們的分工。團隊合做在項目開發中是很重要的，此次的經驗教訓會總結，在未來的團隊合做中避免出現這樣的問題。

我的總結補充

對於《構建之法》幾個不懂的問題：

• 問題1：
  （回答內容參考和引用了知乎上的評論）
  https://www.zhihu.com/question/20331201
  https://www.zhihu.com/question/21533684
  （第三章 軟件工程師的成長）在看到那個精通魔方的例子時，我想到，咱們想在已經學習了C、C++、Java語言的一些基礎，咱們或許沒有可能作到真正意義上的精通各類語言，可是精通一種仍是能夠作到的。然而在開發項目時，咱們可能會用到各類語言編寫代碼。如果這個項目咱們用某種語言編寫會相對更加方便一點，可是咱們不是特別精通的，使用時可能要一邊作，一邊學習。而使用精通的語言去寫，咱們會很熟練，但對於解決項目中的一些問題可能會更多的時間，咱們應該怎麼作？
  答：在日復一日的編程工做中，做爲程序員來講必定要懂得相應的編程語言，但咱們是須要掌握一種語言仍是多種語言，對於程序員來說確定是掌握多種語言更有優點，學習不止一種語言的幾大緣由：

• 能夠更好地實現用多種方式來解決一樣的問題，懂得不一樣的語言就意味着擁有更多的選擇，這也正好應正了那句古語，當你只有錘子的時候，不管你看到什麼都像是釘子。

• 學習和掌握的語言類型越多，就更有競爭力，擁有更多的就業機會，做爲程序員的你，應該不難發現，學習了第二門編程語言以後，有時候能夠增長一倍你能夠勝任職位的數量，但關鍵還取決於你學習的語言，可不管怎麼說，這都會給你增長就業的機會。

• 這是一個頗有趣的過程，在學習新內容或是新東西的過程當中能夠很好地充實你的大腦，幫助你在一個新的領域當中更好的成長和提升。

• 可以緊跟當前的技術發展趨勢，只要你知道哪一個行業處於獨領風騷的行列，即可以永遠站在潮流的尖端，不管什麼時候你的技能都不會過期。

• 這個學習過程也能夠很好地代表你可以學習新的語言，你的僱主能夠更好地瞭解到你並非一個死板的程序員。

• 掌握更多的語言可以幫助你成爲一個更好地程序員，同時能夠幫助你提升所在語言之間轉移的技能。

• 針對工做需求選用更好的工具，每種語言都有特定的使用環境，言外之意就是說若是知道更多的語言能夠再工做需求當中選用更好的工具。

• 學習的過程一樣還代表你是一個快速的學習者，對於接受新知識的能力很強。

• 問題2：
  （第三章 軟件工程師的成長）團隊合做時，當面對是認可本身的錯誤，推遲計劃時間去改正仍是按計劃提交最後影響團隊進度時，咱們不管如何抉擇都會影響總體進度，但咱們應該怎樣正確地作出選擇，以使團隊損失降到最小？（Page 57 4—案例）
  答：有錯誤就應該用於承擔，不能由於面子問題而去影響團隊。咱們承擔了錯誤，纔有利於咱們引發重視，避免下次再犯。
• 問題3：
  （第五章 團隊與流程）主治醫師模式由核心人員負責處理主要的模塊，其餘團隊成員從各個方面從旁協助。在學習中咱們也常常有這種須要團隊合做的做業，但每每的狀況是，在團隊成員肯定之初，你們都有積極的表現，隨着項目的進行，有的成員會無所事事，分配的任務也不能按時完成或是置之不理，這種時候，其餘成員不得不接手他的任務，增長工做量。如果任由這種狀況發生，會使其餘成員不滿，可能會出現更多的這種狀況。如果就此將他踢出團隊，毫無疑問會影響項目的完成計劃。因此，這種狀況咱們應該如何處理？（Page 89）
  答：對於團隊中的蛀蟲，咱們應該採起的態度是毫不容忍，這種人會影響團隊的和諧，不利於團隊合做。因此即便由於少一我的影響短時間進度，咱們也不能所以就容忍這種事情發生。
• 問題4：
  （第八章 需求分析）咱們在獲取客戶需求時，一般是將客戶的要求放在第一位的。可是一般要求咱們開發軟件的客戶不是學習咱們這個專業的，他們對咱們的專業知識所知很少或者是一無所知。所以即便客戶提出一個錯誤的要求而且要求咱們必定要作到，咱們也要將客戶的要求放在第一位嗎？
  答：需求分析師項目開發的第一步，是整個項目的指引，因此需求分析咱們要作到盡善盡美，對於這種問題，咱們應該積極作好和客戶的溝通，確保作出正確的需求分析，從而不會影響項目的後期開發。
• 問題5： 銥星計劃的手機的失敗在於他考慮到了用戶使用時的各類狀況，卻把重點放在了少部分用戶的特殊狀況，從而在更多更廣的普通用戶方面作得不如其餘手機，能夠說是因小失大。可是如果咱們想要增長的功能不會影響所想要實現的大衆功能，且大部分用戶可能會用到，可是也可能永遠不會用到（好比說洗衣機上的對各類不一樣衣物的清洗，大部分狀況下其實只用到了一種），那麼這個功能咱們是否有必要去實現？（Page 330 迷思之六） 答：項目前期作好的需求分析須要咱們實現的功能，咱們應該把精力集中到這些上面。對於那些沒必要要的功能，咱們能夠結合實際狀況，再作決定。