Q：怎樣創(chuàng)造一個”足夠好“的軟件？

提問原因：預習第一章時，介紹了軟件和軟件工程，軟件工程的目標就是創(chuàng)造”足夠好“的軟件，就想到了該如何實現(xiàn)這個目標呢。
A：提高軟件的功能質量、結構質量、過程質量，軟件要不僅是”正確的“還要是”運行正確的“才是個”足夠好“的軟件。

Q：如何實現(xiàn)軟件質量？

提問原因：既然做一個好的軟件需要提高質量，那么如何實現(xiàn)。
A：實現(xiàn)軟件質量從三個方面出發(fā)。1.高質量設計2.規(guī)范的編碼3.有效測試，這是實現(xiàn)軟件質量的三個必要手段。

Q：如何區(qū)分軟件工程基本要素中的四個方法？

提問原因：四部不同的方面我不太理解。
A：四個方法分別是面向服務、面向構件、面向對象、面向過程。面向服務是在應用表現(xiàn)層次上將軟件結構化，即應用業(yè)務過程由服務組成，而服務由構件組裝而成。面向構件是尋求比類的粒度更大的且易于復用的構件，期望實現(xiàn)軟件的再工程。面向對象是以類為基本單元，對象是類的實例化，對象之間以信息傳遞為基本手段。面向過程是以算法作為基本構造單元，強調自項向下的功能分解，將功能和數(shù)據(jù)進行一定程度的分離。

Q：進行模塊化設計后，團隊開始分工編寫代碼，如何實現(xiàn)每個模塊穩(wěn)定的連接？

提問原因：一個項目由團隊協(xié)作完成，我想團隊中每個人編碼思維、習慣等可能不一樣，將所有的代碼穩(wěn)定的連接起來我有點無頭緒。
A：（這個問題目前我不知道回答，我想通過學習軟件工程這門課程的過程中學會解答這個題）

Q：在代碼性能優(yōu)化的過程中，分別要從哪幾個方面去對一段待優(yōu)化的代碼進行優(yōu)化原因分析？

提問原因：性能分析后給出的是一個客觀的數(shù)據(jù)，怎么從主觀的角度來選擇優(yōu)化，找出該代碼優(yōu)化的原因。
A：1.在滿足正確性、可靠性、健壯性、可讀性等質量因素的前提下，設法提高程序的效率。2.以提高程序的全局效率為主，提高局部效率為輔。3.在優(yōu)化程序效率時，找出限制效率的”瓶頸“。4.先優(yōu)化數(shù)據(jù)結構和算法，再優(yōu)化執(zhí)行代碼。5.時間效率和空間效率可能是對立的，應當分析哪個因素更重要，再做出適當?shù)恼壑小?/p>

Q：結對編程時應注意些什么，怎樣才能高效地互相學習與進步？

提問原因：在之前的學習過程中我也有與同學討論學習過，我一般是聽別人給我講解，而結對編程講究的是角色輪番互換，我想知道如何做才可以更高效地學習進步。
A：結對編程中有兩個角色，一個是駕駛員，負責用鍵盤編寫程序；一個是領航員，起到領航、提醒的作用。兩人輪流駕駛，角色互換。結對編程過程中要一直會話和討論，駕駛員要不停的解釋自己的想法和做法，如果發(fā)現(xiàn)伙伴不能及時融入就要及時的溝通，領航員需要時時提出自己的疑問和意見，指出可能存在的問題。結對開始之前也要協(xié)調溝通，彼此互相通告希望對方關注些什么，自己喜歡做什么。

Q：單元測試為什么要快速運行？

提問原因：快速運行是單元測試的原則之一，便想知道為什么需要快速的。
A：如果運行緩慢，會拖慢整個測試的進度，就不會頻繁運行它。

Q：100%覆蓋率是個值得追求的目標嗎？

提問原因：在單元測試質量這一知識點中，提到了測試要求100%的測試通過率，于是就想，100%是一定要追求的嗎
A：是的，每個人都應該達到這個目標 …… 但是一個項目就足夠了。意思是你需要做到極致去知道它的局限是什么。單元測試，尤其是測試先行方式，是非常好的實踐。但是我們需要學會哪些測試是有用的，哪些是適得其反的。沒有什么是免費的，沒有銀彈。所以察覺問題才是解決的開端，而一開始去追求100%就可以察覺更多的問題。

Q：黑盒測試和白盒測試的優(yōu)缺點？

提問原因：單元測試中提到這兩種測試方法，而這兩種方法分別適用于那種情況，由此就想知道兩種測試方法的優(yōu)缺點。
A：
黑盒測試的優(yōu)點：
1.對于子系統(tǒng)甚至系統(tǒng)效率要比白盒測試高2.測試人員不需要了解實現(xiàn)的細節(jié)（特定編程語言）3.測試人員和編程人員彼此獨立 4.從用戶的角度進行測試很容易理解和接受5.有助于暴露規(guī)格的不一致或有歧義的問題 6.測試用例可以在規(guī)格完成后馬上進行。
黑盒測試的缺點： 
1.只有一小部分輸入被測試到，要測試每個可能的輸入幾乎不可能。2.沒有清晰、簡明的規(guī)格，測試用例很難設計。3.如果測試人員不被告知開發(fā)人員已經(jīng)執(zhí)行過的用例，在測試數(shù)據(jù)上會存在不必要的重復。4.有很多程序路徑?jīng)]有被測試到。5.不能直接針對特定程序段測試，而這些程序段可能很復雜，有可能隱藏更多的問題。6.大部分和研究相關的測試都是直接針對白盒測試的。
白盒測試的優(yōu)點：
1.能仔細考慮軟件的實現(xiàn)2.可檢測代碼中的每條分支和路徑 3.揭示隱藏在代碼中的錯誤4.對代碼的測試比較徹底。
白盒測試的缺點：
1.昂貴2.無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤3.不驗證規(guī)格的正確性。

Q：瀑布模型的優(yōu)缺點？

A：優(yōu)點：在軟件開發(fā)中，由于技術人員沒有深入分析項目需求，而匆忙開發(fā)，很容易導致最后的結果不符合需求。在瀑布模型中，前期強調文檔與邏輯的實現(xiàn)，沒有關于軟件的物理實現(xiàn)，很大程度上提高了最后成型的效率并降低成本。
缺點：瀑布模型太過于注重文檔,有一種說法是瀑布模型是由文檔驅動的，它的傳遞過程都是從紙上靜態(tài)的傳遞項目的信息，很難動態(tài)的了解跟進項目的進程，容易導致開發(fā)出的項目不符合要求。

Q：增量模型的優(yōu)缺點？

A：優(yōu)點：逐漸增加項目的模塊，讓客戶有一個學習與使用軟件的過程。
 缺點：軟件系統(tǒng)必須是開放的。

Q：瀑布模型適用于什么方面？

A：適合于結構化方法，也就是面向過程的軟件開發(fā)方法。
軟件項目或產(chǎn)品選擇瀑布模型必須滿足下列條件：
１.在開發(fā)時間內需求沒有或很少變化；
２.分析設計人員應對應用領域很熟悉；
３.低風險項目；
４.用戶使用環(huán)境很穩(wěn)定；
５.用戶除提出需求以外，很少參與開發(fā)工作

Q：敏捷開發(fā)的特點？

A：1.敏捷開發(fā)包括很多方法，例如XP和FDD，同重量級的文檔驅動的開發(fā)過程相比較，敏捷方法在靈活性等方面更有吸引力。這個方法的創(chuàng)始人強調了在軟件實踐過程中的變更而不是孤立的進行一些實踐。
2.很多方法很難獨立的使用。如：測試驅動的開發(fā)，結對開發(fā)，計劃調整周期以及持續(xù)改進，不過后來的結果證實，這些方法都取得了成功。
3.使用這些方法并不能保證一定成功。開發(fā)者的經(jīng)驗和技術仍舊是影響開發(fā)結果的最主要因素。對于合適的人，基于敏捷原則的開發(fā)方法可以產(chǎn)生更好的結果，同時形成一個愉快地、有激情的工作環(huán)境。

Q：Scrum是什么？

A：Scrum是一個框架，人們可以在其中解決復雜的自適應問題，同時有效且創(chuàng)造性地提供具有較高價值的產(chǎn)品。它用于管理軟件項目和產(chǎn)品或應用程序開發(fā)。它的重點是適應性產(chǎn)品開發(fā)戰(zhàn)略，其中跨職能團隊作為一個單元在2-4周內達成共同目標。它由一系列價值、文物、角色、儀式、規(guī)則和交加實踐組成。

Q：BBS是什么？

A：網(wǎng)絡論壇是一個和網(wǎng)絡技術有關的網(wǎng)上交流場所。一般就是大家口中常提的BBS。 BBS的英文全稱是Bulletin Board System，翻譯為中文就是“電子公告板”。BBS最早是用來公布股市價格等類信息的，當時BBS連文件傳輸?shù)墓δ芏紱]有，而且只能在蘋果計算機上運行。因為現(xiàn)在的網(wǎng)絡知識流行太快，每個行業(yè)都有一個自己在網(wǎng)絡中進行交流的一塊區(qū)域。論壇是最好的地方?！獊碜园俣?/p>

Q：主程序員式結構適用于什么情況？

A：1. 行業(yè)新產(chǎn)品研發(fā)，找不到合適的人的。2. 高度機密產(chǎn)品，比如博主做過的數(shù)字電視加密系統(tǒng)。3. 創(chuàng)意產(chǎn)品，比如某些游戲，直接編程的程序員很少。4. 公司快速發(fā)展的。不超過10個人，5個人居多。

Q：軟件開發(fā)團隊至少需要哪幾個角色？

A：項目經(jīng)理,需求分析,系統(tǒng)設計,業(yè)務開發(fā),前端開發(fā),測試,培訓,界面設計,主程。

Q：除了tower，還有什么好用的團隊協(xié)作工具？

A：worktile

Q：敏捷估算要注意什么？

A：估算大小，而不是估算時間周期，使用相對估算，而不是絕對估算。

Q：軟件管理配置的目標？

A：標志變更，控制變更，確保變更正確實現(xiàn)，向受變更影響的組織和個人報告變更。

Q：需求分析的過程？

需求分析是對軟件系統(tǒng)的后期分析，需要進行一系列的活動，包括：分析用戶需求、建立 需求原型、分析系統(tǒng)需求和進行需求驗證等

Q：系統(tǒng)模型有幾種？

A：用于描述系統(tǒng)功能組織結構的層次模型，用于描述系統(tǒng)中數(shù)據(jù)加工流程的數(shù)據(jù)流模型，用于描述數(shù)據(jù)實體及其 關系的數(shù)據(jù)關系模型，用于描述系統(tǒng)行為過程的系統(tǒng)狀態(tài)模型等。

Q：需求獲取的渠道有哪些？

A：外部渠道：
1）市場
需求和產(chǎn)品常常會受到行業(yè)政策調整的影響。如“凈網(wǎng)行動”、“打車軟件專車服務屬非法營運”等。
2）用戶
產(chǎn)品設計的初衷就是為了滿足用戶需求。
3）競品
所謂的競品，主要可分為兩種。一種是用同樣的產(chǎn)品功能滿足同樣用戶需求的產(chǎn)品，另一種是用不同的產(chǎn)品功能滿足同樣用戶需求的產(chǎn)品。競品對用戶需求的滿足程度、滿足方式既會對我們產(chǎn)生影響，也可以為我們的產(chǎn)品設計帶來一定的啟發(fā)。
4）合作伙伴
合作伙伴在商業(yè)模式當中扮演著重要的角色，因此他們的需求亦不容忽視。
內部渠道：
1）產(chǎn)品
用戶在使用產(chǎn)品時會產(chǎn)生行為數(shù)據(jù)，這些客觀的數(shù)據(jù)一定程度上會反映出用戶的需求。
2）老板
企業(yè)運轉的根本目的在于盈利。產(chǎn)品在滿足用戶需求的同時必須兼顧公司的戰(zhàn)略需求。而這方面需求通常是由老板或公司的高層來把握。
3）同事
一款產(chǎn)品從誕生到投入市場，主要需要以下角色參與：產(chǎn)品、研發(fā)、設計、運營、市場、銷售、客服。其中，運營、市場、銷售（解決合作伙伴對產(chǎn)品價值的質疑）、客服（解決用戶遇到的問題）是距離用戶最近的人，往往最能理解用戶抱怨的點也最能提出產(chǎn)品建設性的意見。
4）自己
產(chǎn)品經(jīng)理應該成為自己產(chǎn)品的用戶，而且是產(chǎn)品的目標用戶，在使用產(chǎn)品的過程去發(fā)現(xiàn)用戶需求，如此一來才能更好地幫助用戶解決問題。

Q：用例規(guī)約包括什么內容？

A：簡要說明、事件流、特殊需求、前置條件和后置條件

Q：用例建模的目的？

A：構建用例模型是通過開發(fā)者與客戶，或最終使用者共同協(xié)商完成的。經(jīng)過反復討論需求的規(guī)格說明，達成共識，明確系統(tǒng)的基本功能，為后階段的工作打下基礎。確定系統(tǒng)應具備哪些功能、為系統(tǒng)的功能提供清晰一致的描述、為系統(tǒng)驗證工作打下基礎、提供跟蹤進入系統(tǒng)中具體實現(xiàn)的類和方法，檢查其是否正確的能力。

Q：用例建模的優(yōu)點？

A：用例方法完全是站在用戶的角度上（從系統(tǒng)的外部）來描述系統(tǒng)的功能的。在用例方法中，我們把被定義系統(tǒng)看作是一個黑箱，我們并不關心系統(tǒng)內部是如何完成它所提供的功能的。用例方法首先描述了被定義系統(tǒng)有哪些外部使用者（Actor），這些使用者與被定義系統(tǒng)發(fā)生交互；針對每一參與者，用例方法又描述了系統(tǒng)為這些參與者提供了什么樣的服務（Use Case），或者說系統(tǒng)是如何被這些參與者使用的。所以從用例圖中，我們可以得到對于被定義系統(tǒng)的一個總體印象。

Q：傳統(tǒng)結構化方法與面向對象方法比較有何區(qū)別？

A：與傳統(tǒng)的結構化方法相比，面向對象方法在描述和理解問題域時采用截然不同的方法。其基本思想是，對問題域進行自然分割，以更接近人類思維方式建立問題域模型，從而使設計出的軟件盡可能直觀地描述現(xiàn)實世界，具有更好的可維護性，能適應用戶需求的變化。
首先，用面向對象技術開發(fā)的系統(tǒng)比較穩(wěn)定，較小的需求變化不會導致大的系統(tǒng)結構的改變。
　　其次，用面向對象技術開發(fā)的系統(tǒng)易于理解。結構化方法和面向對象方法對現(xiàn)實世界采用了不同的映射方法。在結構化方法中，現(xiàn)實世界被映射為功能的集合；在面向對象方法中，現(xiàn)實世界中的實體及其相互關系被映射為對象及對象間的關系，實體之間的相互作用被映射為對象間的消息發(fā)送，以及其他類似的各種映射關系。
　　第三，采用面向對象技術開發(fā)的系統(tǒng)具有更好的適應性，能更好地適應用戶需求的變化，有助于改造大型軟件系統(tǒng)。
　　第四，用面向對象技術開發(fā)的系統(tǒng)具有更高的可靠性，有助于軟件的維護與復用。
　　第五，面向對象技術有助于提高軟件的質量和生產(chǎn)率。

Q：聚合與組合關系有何區(qū)別？

A：聚合關系是整體與部分的關系，且部分可以離開整體而單獨存在。組合關系是整體與部分的關系，但部分不能離開整體而單獨存在。

Q：類圖建模中各種關系的強弱順序？

A：泛化 = 實現(xiàn) > 組合 > 聚合 > 關聯(lián) > 依賴

Q：什么是順序圖？

A：順序圖是交互圖的一種形式，它顯示對象沿生命線發(fā)展，對象之間隨時間的交互表示為從源生命線指向目標生命線的消息。順序圖能很好地顯示那些對象與其它那些對象通信，什么消息觸發(fā)了這些通信，順序圖不能很好顯示復雜過程的邏輯。

Q：迷路消息和拾取消息含義？

A：迷路消息是那些發(fā)送了卻沒有到達指定接收者，或者到達的接收者不再當前圖中。拾取消息是收到來自那些未知的發(fā)送者，或者來自沒有顯示在當前圖的發(fā)送者的消息。它們都表明是去往或來自一個終點元素。

Q：行為建模的步驟？

A：建立模型，分析特征，敏感度分析，可行性/優(yōu)化性分析，多目標設計研究，找到答案，改變模型參數(shù)。

Q：面向對象的體系結構風格優(yōu)缺點？

優(yōu)點：
1.強調設計，全面的系統(tǒng)考慮，和現(xiàn)實世界的對應關系
2.對象對客戶隱藏了實現(xiàn)的細節(jié)，可以在不影響客戶的情況下改變對象的實現(xiàn)(低耦合，高重用，可維護)，方便系統(tǒng)升級
3.內部表達的保護(封裝數(shù)據(jù)/狀態(tài)的完整)
缺點：
1.對象交互時需要知道彼此的標識
2.多個對象對同一資源的訪問(A和B同時需要使用C)
3.采用面向對象，分解出的是小粒度的基本類或對象。從系統(tǒng)總體結構到構件的設計，缺乏有效的描述和設計方法。

Q：管道-過濾器風格優(yōu)缺點？

優(yōu)點：

1. 使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點，系統(tǒng)中已有的過濾器很容易用于新的待設計系統(tǒng)。
2. 允許設計者將整個系統(tǒng)的輸入/輸出行為看成是多個過濾器的行為的簡單合成
3. 支持軟件重用。
4. 具有較強的可維護性和可擴展性。
5. 支持并行執(zhí)行。
6. 為系統(tǒng)的性能分析提供了方便。
   缺點：
7. 通常導致進程成為批處理的結構。
8. 全局變量的共享很困難，通信、交互性不強
9. 當數(shù)據(jù)傳輸量很大而又有很多小的過濾器時代價較大
10. 并行效果并不理想
11. 出現(xiàn)錯誤時如何做處理比較困難

Q：中小型購物網(wǎng)站適合用哪個數(shù)據(jù)庫？

mysql
? 開源的關系型數(shù)據(jù)庫，至今最流行的開源關系型數(shù)據(jù)庫
? 簡單易用，擁有大量的第三方插件，社區(qū)活躍，文檔豐富。
? 關系型數(shù)據(jù)庫支持快速的復雜查詢操作。
? 支持完整的事務操作和較高的安全性。