| 這個作業屬於哪個課程 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1 |
|---|---|
| 這個作業要求在哪 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1/homework/10618 |
| 這個作業要求在哪 | 在學習軟件工程過程中發現並解決自己存在的問題 |
| 作業正文 | 下文 |
| 參考文獻 | CSDN、嗶哩嗶哩、學堂在線、名華在線、百度文庫······ |
第一章 初識軟件工程
Q:軟件開發的四個基本策略
A1:
- 軟件復用
- 分而治之
- 逐步推進
- 優化分析
Q: 使用Python語言對學習軟件工程的作用？
A1:
- 簡單易學，容易操作
- 學習在於培養自己勤思考、善於思考的能力。能力包括的方面有很多，有邏輯能力、思維能力、判斷能力、動手操作能力等。
Q: 目前有哪些開發模式是在實戰中獲得許多好評的？
A1:
- 迭代模型（stagewise model）、敏捷軟件開發 (Agile development) 、混合模型（hybrid model）又叫過程開發模型，或元模型（meta-model）,把幾種不同模型組合成一種混合模型，它允許一個項目能沿着最有效的路徑發展，這就是過程開發模型（或混合模型）。實際上，一些軟件開發單位都是使用幾種不同的開發方法組成他們自己的混合模型。
- 要開發一個商業價值高的軟件，符合用戶功能需求又控制成本，而且還要高效，那么肯定需要詳細的完善，怎么避免結構龐雜呢？
- 調整以“合”為主，架構最精簡。
Q: 軟件的生命周期可以分為哪些階段？
A1:
- 三個階段：軟件定義、軟件開發、運行維護。
其主要活動階段包括:可行性分析與計划制定、需求分析、軟件設計(概要設計和詳細設計)、軟件實現(編碼)、測試、維護等活動，其中軟件開發階段包括軟件設計、實現與測試。
Q: 軟件開發的基本策略中的分而治之還是有些不清楚？
A1:
- 分而治之是指把大而復雜的問題分解成若干個簡單的小問題，然后逐個解決。這種朴素的思想來源於人們生活與工作的經驗，也完全適合於技術領域。諸如軟件的體系結構設計、模塊化設計都是分而治之的具體表現。
第二章 編寫高質量代碼
Q: 學習Python的就業前景？
A1:
- 相關崗位多，人才就業率高
- Python由於其簡潔優美和極高的開發效率，得到了越來越多公司的青睞，公司選用Python進行網站Web、搜索引擎(Google)、雲計算(OpenStack)、大數據、人工智能、科學計算等方向的開發。Python或將成為繼C++和Java之后的第三個主流編程語言，因此，Python的人才就業率高
- 就業方向廣
- Python強大之處就是應用比較廣泛，廣泛應用於：Web應用開發、圖形界面開發、系統網絡運維、網絡編程、科學與數字計算、3D游戲開發等，其應用領域足以說明Python很牛，不得不讓人感到它的強大。從事Python開發，工作機會和工作崗位及工作內容可選擇的余地很多，未來發展的空間也很大。
- 人才需求量大
- 據統計，Python人才需求量每日高達5000+，但目前市場上專業Python程序員供不應求， 競爭小，很容易快速高薪就業。
Q: JAVA和Python有什么相同和區別 ?
A1:
- python虛擬機沒有java強，java虛擬機是java的核心，python的核心是可以很方便地使用c語言函數或c++庫。
- python是全動態性的，可以在運行時自己修改自己的代碼，java只能通過變通方法實現。python的變量是動態的，而java的變量是靜態的，需要事先聲明，所以java ide的代碼提示功能優於python ide。
- python的產生幾十年了，幾十年前面向過程是主流，所以用python有好多程序用的是面向過程設計方法，很多概念從c語言過來的，class在python中是后加入的，而java是為了實現沒有指針的c++（當年com組件用的引用記數，java用的虛擬機），主要采用面向對象的設計方法，很多概念是oop的概念。面向過程，相對簡潔直觀，但容易設計出面條程序，面向對象，相對抽象優雅，但容易過度抽象。
- 在實際使用的python入門簡單，但要學會用python干活，需要再學習python各種庫，pyhton的強大在於庫，為什么python的庫強大，原因是python的庫可以用python，c語言,c++等設計，再提供給python使用，所以無論gpu運行，神經網絡，智能算法，數據分析，圖像處理，科學計算，各式各樣的庫在等着你用。而java沒有python那么多的開源庫，很多庫是商業公司內部使用，或發布出來只是一個jar包，看不到原始代碼。python虛擬機因為編譯性沒有java的支持的好（或者說故意這么設計的），一般直接使用源碼（linux），或源碼簡單打個包（如pyexe）。
- python有很多虛擬機實現，如cython,Pyston,pypy,jython, IronPython等等，適合用於業務語言，或插件語言，或面向領域語言，而java因為虛擬機巨大，很少用於插件語言，發布也不方便。
- java主要用於商業邏輯強的領域，如商城系統，erp，oa,金融，保險等傳統數據庫事務領域，通過類似ssh框架事務代碼，對商業數據庫，如oralce,db2,sql server等支持較好，軟件工程理念較強，適合軟件工程式的多人開發模式。python主要用於web數據分析，科學計算，金融分析，信號分析，圖像算法，數學計算，統計分析，算法建模，服務器運維，自動化操作，快速開發理念強，適合快速開發團隊或個人敏捷模式。
java的商業化公司支持多，如sap,oracle,ibm等，有商業化的容器，中間件，企業框架ejb。python的開源組織支持多，如qt,linux,google,很多開源程序都支持python， 如pyqt,redis,spark等。- python用途最多的是腳本，java用途最多的是web，pyhotn是膠水，可以把各類不相關的東西粘在一起用，java是基佬，可以通過軟件工程組成幾百個人的團隊和你pk，商業化氣息重。不過我認為還是python強大，因為可以方便調用c或c++的庫，但軟件工程和商業化運作沒有java好，適合快捷開發。
Q: 代碼靜態優化具體有什么措施？
A1:
- 改進算法
- 在源程序級上等階變換
- 充分利用系統提供的程序庫
- 編譯時優化
第三章單元測試
Q:單元測試的定義是什么？
A1:
- 單元測試是對軟件中的最小單元進行測試和驗證，通俗來講就是代碼中的一個函數或一個類，單元測試一定是白盒測試。
重要性
- 單元測試是軟件測試的基礎，因此單元測試的效果會直接影響到軟件的后期測試，最終在很大程度上影響到產品的質量。領測國際提示從如下幾個方面就可以看出單元測試的重要性在何處。
- 時間方面：如果認真的做好了單元測試，在系統集成聯調時非常順利，因此會節約很多時間，反之那些由於因為時間原因不做單元測試或隨便做做的則在集成時總會遇到那些本應該在單元測試就能發現的問題，而這種問題在集成時遇到往往很難讓開發人員預料到，最后在苦苦尋覓中才發現這是個很低級的錯誤而在悔恨自己時已經浪費了很多時間，這種時間上的浪費一點都不值得，正所謂得不償失。
- 測試效果：根據以往的測試經驗來看，單元測試的效果是非常明顯的，首先它是測試階段的基礎，做好了單元測試，在做后期的集成測試和系統測試時就很順利。其次在單元測試過程中能發現一些很深層次的問題，同時還會發現一些很容易發現而在集成測試和系統測試很難發現的問題。再次單元測試關注的范圍也特殊，它不僅僅是證明這些代碼做了什么，最重要的是代碼是如何做的，是否做了它該做的事情而沒有做不該做的事情。
- 測試成本：在單元測試時某些問題就很容易發現，如果在后期的測試中發現問題所花的成本將成倍數上升。比如在單元測試時發現1個問題需要1個小時，則在集成測試時發現該問題需要2個小時，在系統測試時發現則需要3個小時，同理還有定位問題和解決問題的費用也是成倍數上升的，這就是我們要盡可能早的排除盡可能多的bug來減少后期成本的因素之一。
- 產品質量：單元測試的好與壞直接影響到產品的質量，可能就是由於代碼中的某一個小錯誤就導致了整個產品的質量降低一個指標，或者導致更嚴重的后果，如果我們做好了單元測試這種情況是可以完全避免的。
綜上所述，單元測試是構築產品質量的基石，我們不要因為節約單元測試的時間不做單元測試或隨便做而讓我們在后期浪費太多的不值得的時間，我們也不願意因為由於節約那些時間導致開發出來的整個產品失敗或重來!
Q: 單元測試中的輸入輸出有哪些呢？
A1:
- 輸入：被測試函數的輸入參數、被測試函數需要的全局變量、被測試函數的內部私有變量、函數內部調用子函數的數據、函數內部調用其他模塊的數據、函數內部調用外部服務的數據等。
- 輸出：被測函數的返回值、被測試函數的輸出參數、被測試函數修改的全局變量、被測試函數修改的內部變量、被測試函數增刪改的數據庫數據等、被測試函數進行的文件更新、被測試函數進行的消息隊列的更新等。
Q:在項目中如何進行單元測試？
A1:
- 並不是所有的項目都適合進行單元測試，即使進行單元測試，也應該是一些基礎底層模塊或者核心模塊進行單元測試；
選擇合適的單元測試框架，Java中的TestNG、JUnit，Python中的Unittest、Pytest，PHP中的PHPUnit；
將單元測試集成到CI流程當中。
Q:軟件單元測試和軟件測試有什么區別和聯系?
A1:
- 區別：軟件單元測試：是指對軟件中的最小可測試單元進行檢查和驗證。軟件測試：是指使用人工或手動的方法來運行軟件的過程
- 聯系：軟件測試包括了軟件單元測試。
Q:白盒測試和黑盒測試與靜態測試和動態測試之間是不是有着對應的關系?
A1:
- 靜態測試：不運行被測程序，僅通過檢查和閱讀等手段來發現程序中的錯誤。
- 動態測試：實際運行被測程序，通過檢查運行的結果來發現程序中的錯誤。
- 動態測試可能是黑盒測試，也可能是白盒測試。
Q: 測試用例的設計標准是什么？
A1:
- 需求點100%被覆蓋
- 被測功能點或控件100%被覆蓋
- 必須驗證正確性操作、正常數據和可能導致出錯的數據、操作
- 有數據值域的必須考慮數據值域覆蓋：邊界值、等價類
- 所有邊界值都必須覆蓋
- 等價類必須包含有效和無效等價類
- 等價類各子類不存在交錯以避免冗余
- 等價類的使用避開邊界值
- 所有等價類都必須覆蓋(等價類數量過多導致超過測試成本的，優先考慮有效等價類，然后根據數據使用頻率、幾率高低分優先級，高級優先覆蓋，同時考慮自動化測試)
- 用例可以直接執行或易於准確執行
- 用例中的數據或描述不存在二義性或多義性，不會因執行人不同而產生不同執行結果
- 用例有明確的預期結果能夠用於准確判斷是否符合要求
- 集成用例必須包含打開系統和退出系統的驗證
- 業務用例必須考慮不同模塊數據和業務的一致性
- 含數據庫部分必須包括數據庫的驗證
- 核心功能點必須被覆蓋多次
- 用例設計必須提供設計思路、策略以便於評審和將來復用(含用例設計方法思路、數據分類等)
第4章 軟件開發過程
Q: 軟件過程模型中各模型的適用類型？
A1:
瀑布模型
適用范圍：
用戶的需求非常清楚全面，且在開發過程中沒有或很少變化
開發人員對軟件的應用領域很熟悉
用戶的使用環境非常穩定
開發工作對用戶參與的要求很低
增量模型
適用范圍：
- 進行已有產品升級或新版本開發，增量模型是非常適合的
- 對完成期限嚴格要求的產品，可以使用增量模型
- 對所開發的領域比較熟悉而且已有原型系統，增量模型也是非常適合的
螺旋模型
適用范圍：對於新近開發，需求不明確的情況下，適合用螺旋模型進行開發，便於風險控制和需求變更，螺旋模型只適合於大規模的軟件項目ARD模型
適用范圍：
- 不適合技術風險很高的開發，不適合系統需求是高性能，並且需要通過調整構件接口的方式來提高性能的產品開發。
- 適用於工期緊張，又可細分功能，還要有合適的構件
迭代模型
適用范圍：
- 在項目開發早期需求可能有所變化
- 分析設計人員對應用領域很熟悉
- 高風險項目
- 用戶可不同程度地參與整個項目的開發過程
- 使用面向對象的語言或統一建模語言
- 使用CASE工具
- 具有高素質的項目管理者和軟件研發團隊
Q: 模塊化設計的優劣性？
A1:
優點
可維護性
1.靈活架構，焦點分離
2.方便模塊間組合、分解
3.方便單個模塊功能調試、升級
4.多人協作互不干擾
缺點
性能損耗
1.系統分層，調用鏈會很長
2.模塊間通信,模塊間發送消息會很耗性能
Q: 軟件過程模型中各模型的優點？
A1:
瀑布模型
- 它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該摸板下有一個共同的指導。
- 雖然有不少缺陷但比在軟件開發中隨意的狀態要好得多。
增量模型
- 采用增量模型的優點是人員分配靈活，剛開始不用投入大量人力資源
- 如果核心產品很受歡迎，則可增加人力實現下一個增量
- 可先發布部分功能給客戶，對客戶起到鎮靜劑的作用
螺旋模型
- 設計上的靈活性,可以在項目的各個階段進行變更
- 以小的分段來構建大型系統,使成本計算變得簡單容易
- 客戶始終參與每個階段的開發,保證了項目不偏離正確方向以及項目的可控性
- 隨着項目推進,客戶始終掌握項目的最新信息 , 從而他或她能夠和管理層有效地交互
- 客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品
RAD模型
- 開發速度快，質量有保證
- 對信息系統特別有效
迭代模型
- 降低了在一個增量上的開支風險。如果開發人員重復某個迭代，那么損失只是這一個開發有誤的迭代的花費
- 降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以盡早來解決而不至於在開發后期匆匆忙忙
- 加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率
- 由於用戶的需求並不能在一開始就作出完全的界定，它們通常是在后續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些
Q: 敏捷開發的特點？
A1:
- 精確要求，精准成果。
- 質量有保障。
- 客戶合作勝過合同談判。
- 投資回報率高。
- 較高的速度是敏捷開發最顯著的優點之一。
Q: 敏捷開發的要求？
A1:
我們最優先要做的是通過盡早的、持續的交付有價值的軟件來使客戶滿意。
即使到了開發的后期，也歡迎改變需求。
經常性地交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。
在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
圍繞被激勵起來的個人來構建項目。
在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面的交談。
工作的軟件是首要的進度度量標准。
敏捷過程提倡可持續的開發速度。
不斷地關注優秀的技能和好的設計會增強敏捷能力。
簡單使未完成的工作最大化。
最好的構架、需求和設計出自於自組織的團隊。
每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調整。
Q: 敏捷開發方法有哪些？
A1:
- 極限編程（eXtreme Programming，XP）
極限編程的思想源自 Kent Beck 和 Ward Cunningham 在軟件項目中的合作經歷。在這里，“eXtreme”的意思是希望將軟件開發過程中一些好的方法發揮到極致。XP 注重的核心在於“溝通、簡明、反饋和勇氣”，用一句話來概括 XP 的這 4 個核心價值觀就是：通過充分的交流和溝通，使產品的設計盡可能簡單明了；同時通過客戶經常性的反饋，生產出符合客戶要求的軟件產品，並且有勇氣迎接需求的改變。
- RUP（Rational Unify Process，Ratioanl 統一過程）
RUP 試圖總結現代軟件開發過程中所有好的實踐經驗，形成一種有很強適應性的軟件開發過程。它包括了軟件開發中的 6 大經驗，分別是：迭代式開發、管理需求、可視化建模、使用基於組件的軟件體系結構、驗證軟件質量、控制軟件變更。
- Lean（精益軟件開發方法）
精益生產的概念首先出現在制造業中，由日本的豐田公司提出。大規模制造理論認為，一定程度的浪費、一定程度的廢品是正常的和被允許的。而在軟件開發中，資源浪費、成本居高不下也同樣成為軟件開發的一大障礙。處於變革的十字路口的軟件開發行業，總是能不斷地從其他行業中尋找可借鑒的理論。這種借鑒來的思路就被稱為精益編程（Lean Programming）。
- Scrum
Scrum是一種靈活的敏捷軟件開發管理過程，這個名詞來源於英式橄欖球。Scrum 方法由 Ken Schwaber 和 Jeff Sutherland 提出，它將軟件開發團隊比作橄欖球隊，全隊有明確的最高目標——發布產品的重要性高於一切，團隊高度自治，成員們熟悉開發過程中涉及到的各種技術，緊密合作，確保每個迭代都朝着最高目標推進，而且每隔 2～4 周，每個團隊成員都能看到能實際工作的軟件，並且據此決定是發
布這個版本還是繼續開發以加強它的功能。
第5章 團隊開發管理
Q: 軟件項目估算的方法有哪些？
A1:
- 自頂向下的估算方法
- 自底向上的估算方法
- 差別估算法
- 根據實驗或歷史數據給出軟件項目工作量或成本的經驗估算公式。
Q: 怎樣才能減少溝通的復雜程度？
A1:
- 明確溝通目的
- 多聽、多看對方的反饋
- 溝通一定要閉環
- 傳達的觀點要明確、佐證要清晰
- 別讓情緒掩蓋了信息
第6章 敏捷開發與配置管理
Q: Scrum框架包括哪些內容？
A1:
- 3個角色
- 產品負責人（Product Owner）
- Scrum Master
- Scrum團隊
- 3個工件
- 產品Backlog（Product Backlog）
- SprintBacklog
- 燃盡圖（Burn-down Chart)
- 5個活動
- Sprint計划會議（Sprint Planning Meeting）
- 每日站會（Daily Scrum Meeting）
- Sprint評審會議（Sprint Review Meeting）
- Sprint回顧會議（Sprint Retrospective Meeting）
- 產品Backlog梳理會議（ Product Backlog Refinement）
- 5個價值
- 承諾 – 願意對目標做出承諾
- 專注– 把你的心思和能力都用到你承諾的工作上去
- 開放– Scrum 把項目中的一切開放給每個人看
- 尊重– 每個人都有他獨特的背景和經驗
- 勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重
第7章 需求獲取
Q: 需求的分類及其介紹？
A1:
- 業務需求 （Business requirement）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策划部門。業務需求描述了組織為什么要開發一個系統，即組織希望達到的目標。使用前景和范圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。
- 用戶需求 （user requirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件――響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什么。
- 功能需求 （functional requirement）規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求 （behavīoral requirement），因為習慣上總是用“應該”對其進行描述：“系統應該發送電子郵件來通知用戶已接受其預定”。功能需求描述是開發人員需要實現什么。注意：用戶需求不總是被轉變成功能需求。產品特性，所謂特性（feature），是指一組邏輯上相關的功能需求，它們為用戶提供某項功能，使業務目標得以滿足。對商業軟件而言，特性則是一組能被客戶識別，並幫助他決定是否購買的需求，也就是產品說明書中用着重號標明的部分。客戶希望得到的產品特性和用戶的任務相關的需求不完全是一回事。一項特性可以包括多個用例，每個用例又要求實現多項功能需求，以便用戶能夠執行某項任務。
- 系統需求 （system requirement）用於描述包含有多個子系統的產品（即系統）的頂級需求。系統可以只包含軟件系統，也可以既包含軟件又包含硬件子系統。人也可以是系統的一部分，因此某些系統功能可能要由人來承擔。
Q: 需求獲取技術有哪些？各有什么好處
A1:
- 用戶訪談：這是最基本的需求獲取方法，包括結構化與非結構化兩種。結構化就是指事先准備一些問題，有針對性地進行，而結構化只列出粗略的想法，根據訪談的情況進行發揮。事實上要結合兩者。
- 用戶調查：如果客戶面較廣，則不可能一一訪談。這就要借助於“用戶調查”了。通過事先精心准備的問題，發到有關人員手中。缺點是用戶可能不太重視，而且問題的設計不能面面具到，不夠靈活，獲得的信息不夠全面。缺乏面對面的交流。
- 現場觀摩：走到客戶的工作現場，一邊觀察，一邊聽用戶的講解。甚至可以安排人員跟隨客戶工作一段時間。這樣使得分析人員可以更直觀地理解需求。
- 文檔考古：對於一些數據流比較復雜，工作表單較多的項目，難以通過解說或者觀察來了解需求細節，這就可以借助於“文檔考古”的方法。
- 聯合討論會：這是相對成本較高的需求獲取方法。但也是十分有效的一種，它通過聯合各個關鍵客戶代表、分析人員、開發團隊代表，通過有組織的會議來討論需求。