軟件工程問題清單

這個做業屬於哪一個課程	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:

1. 相關崗位多，人才就業率高

• Python因爲其簡潔優美和極高的開發效率，獲得了愈來愈多公司的青睞，公司選用Python進行網站Web、搜索引擎(Google)、雲計算(OpenStack)、大數據、人工智能、科學計算等方向的開發。Python或將成爲繼C++和Java以後的第三個主流編程語言，所以，Python的人才就業率高

2. 就業方向廣

• Python強大之處就是應用比較普遍，普遍應用於：Web應用開發、圖形界面開發、系統網絡運維、網絡編程、科學與數字計算、3D遊戲開發等，其應用領域足以說明Python很牛，不得不讓人感到它的強大。從事Python開發，工做機會和工做崗位及工做內容可選擇的餘地不少，將來發展的空間也很大。

3. 人才需求量大

• 據統計，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:

瀑布模型

適用範圍：

1. 用戶的需求很是清楚全面，且在開發過程當中沒有或不多變化

2. 開發人員對軟件的應用領域很熟悉

3. 用戶的使用環境很是穩定

4. 開發工做對用戶參與的要求很低

增量模型

適用範圍：

1. 進行已有產品升級或新版本開發，增量模型是很是適合的
2. 對完成期限嚴格要求的產品，可使用增量模型
3. 對所開發的領域比較熟悉並且已有原型系統，增量模型也是很是適合的

螺旋模型

適用範圍：對於新近開發，需求不明確的狀況下，適合用螺旋模型進行開發，便於風險控制和需求變動，螺旋模型只適合於大規模的軟件項目

ARD模型

適用範圍：

1. 不適合技術風險很高的開發，不適合系統需求是高性能，而且須要經過調整構件接口的方式來提升性能的產品開發。
2. 適用於工期緊張，又可細分功能，還要有合適的構件

迭代模型

適用範圍：

1. 在項目開發早期需求可能有所變化
2. 分析設計人員對應用領域很熟悉
3. 高風險項目
4. 用戶可不一樣程度地參與整個項目的開發過程
5. 使用面向對象的語言或統一建模語言
6. 使用CASE工具
7. 具備高素質的項目管理者和軟件研發團隊

Q: 模塊化設計的優劣性？

A1:

優勢

可維護性

1.靈活架構，焦點分離

2.方便模塊間組合、分解

3.方便單個模塊功能調試、升級

4.多人協做互不干擾

缺點

性能損耗

1.系統分層，調用鏈會很長

2.模塊間通訊,模塊間發送消息會很耗性能

Q: 軟件過程模型中各模型的優勢？

A1:

瀑布模型

1. 它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法能夠在該摸板下有一個共同的指導。
2. 雖然有很多缺陷但比在軟件開發中隨意的狀態要好得多。

增量模型

1. 採用增量模型的優勢是人員分配靈活，剛開始不用投入大量人力資源
2. 若是核心產品很受歡迎，則可增長人力實現下一個增量
3. 可先發布部分功能給客戶，對客戶起到鎮靜劑的做用

螺旋模型

1. 設計上的靈活性,能夠在項目的各個階段進行變動
2. 以小的分段來構建大型系統,使成本計算變得簡單容易
3. 客戶始終參與每一個階段的開發,保證了項目不偏離正確方向以及項目的可控性
4. 隨着項目推動,客戶始終掌握項目的最新信息 , 從而他或她可以和管理層有效地交互
5. 客戶承認這種公司內部的開發方式帶來的良好的溝通和高質量的產品

RAD模型

1. 開發速度快，質量有保證
2. 對信息系統特別有效

迭代模型

1. 下降了在一個增量上的開支風險。若是開發人員重複某個迭代，那麼損失只是這一個開發有誤的迭代的花費
2. 下降了產品沒法按照既定進度進入市場的風險。經過在開發早期就肯定風險，能夠儘早來解決而不至於在開發後期匆匆忙忙

3. 加快了整個開發工做的進度。由於開發人員清楚問題的焦點所在，他們的工做會更有效率

4. 因爲用戶的需求並不能在一開始就做出徹底的界定，它們一般是在後續階段中不斷細化的。所以，迭代過程這種模式使適應需求的變化會更容易些

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個角色

1. 產品負責人（Product Owner）
2. Scrum Master
3. Scrum團隊

• 3個工件

1. 產品Backlog（Product Backlog）
2. SprintBacklog
3. 燃盡圖（Burn-down Chart)

• 5個活動

1. Sprint計劃會議（Sprint Planning Meeting）
2. 每日站會（Daily Scrum Meeting）
3. Sprint評審會議（Sprint Review Meeting）
4. Sprint回顧會議（Sprint Retrospective Meeting）
5. 產品Backlog梳理會議（ Product Backlog Refinement）

• 5個價值

1. 承諾 – 願意對目標作出承諾
2. 專一– 把你的心思和能力都用到你承諾的工做上去
3. 開放– Scrum 把項目中的一切開放給每一個人看
4. 尊重– 每一個人都有他獨特的背景和經驗
5. 勇氣– 有勇氣作出承諾，履行承諾，接受別人的尊重

第7章 需求獲取

Q: 需求的分類及其介紹？

A1:

• 業務需求 （Business requirement）表示組織或客戶高層次的目標。業務需求一般來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織爲何要開發一個系統，即組織但願達到的目標。使用前景和範圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱做項目輪廓圖或市場需求（project charter 或 market requirement）文檔。
• 用戶需求 （user requirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件――響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來作些什麼。
• 功能需求 （functional requirement）規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，知足業務需求。功能需求有時也被稱做行爲需求 （behavīoral requirement），由於習慣上老是用「應該」對其進行描述：「系統應該發送電子郵件來通知用戶已接受其預約」。功能需求描述是開發人員須要實現什麼。注意：用戶需求不老是被轉變成功能需求。產品特性，所謂特性（feature），是指一組邏輯上相關的功能需求，它們爲用戶提供某項功能，使業務目標得以知足。對商業軟件而言，特性則是一組能被客戶識別，並幫助他決定是否購買的需求，也就是產品說明書中用着重號標明的部分。客戶但願獲得的產品特性和用戶的任務相關的需求不徹底是一回事。一項特性能夠包括多個用例，每一個用例又要求實現多項功能需求，以便用戶可以執行某項任務。
• 系統需求 （system requirement）用於描述包含有多個子系統的產品（即系統）的頂級需求。系統能夠只包含軟件系統，也能夠既包含軟件又包含硬件子系統。人也能夠是系統的一部分，所以某些系統功能可能要由人來承擔。

Q: 需求獲取技術有哪些？各有什麼好處

A1:

• 用戶訪談：這是最基本的需求獲取方法，包括結構化與非結構化兩種。結構化就是指事先準備一些問題，有針對性地進行，而結構化只列出粗略的想法，根據訪談的狀況進行發揮。事實上要結合二者。
• 用戶調查：若是客戶面較廣，則不可能一一訪談。這就要藉助於「用戶調查」了。經過事先精心準備的問題，發到有關人員手中。缺點是用戶可能不過重視，並且問題的設計不能面面具到，不夠靈活，得到的信息不夠全面。缺少面對面的交流。
• 現場觀摩：走到客戶的工做現場，一邊觀察，一邊聽用戶的講解。甚至能夠安排人員跟隨客戶工做一段時間。這樣使得分析人員能夠更直觀地理解需求。
• 文檔考古：對於一些數據流比較複雜，工做表單較多的項目，難以經過解說或者觀察來了解需求細節，這就能夠藉助於「文檔考古」的方法。
• 聯合討論會：這是相對成本較高的需求獲取方法。但也是十分有效的一種，它經過聯合各個關鍵客戶表明、分析人員、開發團隊表明，經過有組織的會議來討論需求。