第一章問題：
1.2.1 軟體有哪些形式？
第二章問題：
2.1 什麼是單元測試？其建立函式主要步驟？
答：單元測試（unit testing），是指對軟體中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，一般來說，要根據實際情況去判定其具體含義，如c語言中單元指乙個函式，j**a裡單元指乙個類，圖形化的軟體中可以指乙個視窗或乙個選單等。總的來說，單元就是人為規定的最小的被測功能模組。單元測試是在軟體開發過程中要進行的最低級別的測試活動，軟體的獨立單元將在與程式的其他部分相隔離的情況下進行測試。
①設定資料；②使用被測試型別的功能；③比較實際結果和預期的結果。
第三章問題：
3.1 什麼是軟體工程，它包括哪些？
答：軟體工程是應用電腦科學、數學及管理科學等原理，開發軟體的工程。軟體工程借鑑傳統工程的原則、方法，以提高質量、降低成本。其中，電腦科學、數學用於構建模型與演算法，工程科學用於制定規範、設計范型(paradigm)、評估成本及確定權衡，管理科學用於計畫、資源、質量、成本等管理。
目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文件為使用者可用的程度。開銷合宜是指軟體開發、執行的整個開銷滿足使用者要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
軟體工程的主要課程：
外語、高等數學、線性代數、高等代數、電子技術基儲離散數學、計算機引論(c語言)、資料結構、c++程式設計、組合語言程式設計、演算法設計與分析、計算機組成原理與體系結構、資料庫系統、計算機網路、軟體工程、軟體測試技術、軟體需求與專案管理、軟體設計例項分析、cmm/iso9000等。
第四章問題：
4.3 **設計規範有哪些？
答：1提高編碼質量，**可讀性和可維護性。
2**編寫規範
2.1 刪除所有無用**
2.2 必須給**新增注釋，乙個類的注釋字數不得小於**的百分之20%
2.3 建議遵循30秒原則。如果另乙個程式設計師無法在三十秒內無法知道你的函式在做什麼，如何做以及為什麼要這樣做，那麼說明你的**是難於維護的，需要得到提高。
2.4 乙個函式的**長度不允許超過100行，超過一百行的函式建議在不破壞原子性的基礎上進行拆分。
2.5 變數都應在方法或者類的頭部集中定義
2.6 保證一行**只做一件事
2.7 使用括號來控制操作符的運算順序，以免使用j**a預設的操作符優先順序順序。
2.8 **格式化：對**進行格式化，再進行提交。
2.9 介面不允許沒有方法或者變數的宣告
3. 命名規範
3.1 各種識別符號的命名要使用有實際意義的英文單詞或者英文單詞縮寫，縮寫詞及英文單詞要收錄在專案的簡寫詞彙表中。切忌使用阿拉伯數字和拼音進行命名。
3.2 類名：首字母大寫，每個單詞首字母都需要大寫。
3.3 方法名：首字母小寫，其餘單詞首字母都需大寫。
3.4 全域性變數，和常量名稱要求全部字母大寫。
3.5 引數名稱與區域性變數基本相同，區別在於引數名稱需要加上冠詞a ，an 或者在單詞結尾以s結束。
4. 注釋規範
4.1 注釋需要注意的事項：
★注釋應該用中文清晰表達意思，應該是程式看起來更清晰，更容易理解
★注釋要盡量簡明，避免裝飾性的注釋。
★注釋不但要說明做什麼，還應當說明為什麼要這樣做。最好先寫注釋表明要做什麼，再進行編碼。
4.2 類的注釋
★類的用途，目的。包括其他人感興趣的介紹。
★已知bug,當然最好是修改好所有的錯誤，但有時可能暫時沒有辦法修改，或者沒有時間修改。
★開發和維護該類的歷史列表，記錄每一次修改的作者，日期，修改的內容。
★列舉類的各種穩定狀態，說明呼叫成員函式使類的狀態產生的變遷(可選)。
★同步問題（可選）
★對主要的演算法必須加以說明，主要流程必須給予引導性說明
標準格式：
如果對已經版本話的類進行了修改，需要按照如下格式為每一次修改附加修改歷史記錄：
// 修改人 + 修改日期
// 修改說明 範例：
// 李四 2010/07/02
// 新增錯誤資料修改後繼續批量儲存的處理函式 s**ebatch(
@bind(key = "itemparams", defaultvalue = "") string itemparams,
@bind(key = "pid", defaultvalue = "") string pid)。
// 王小二 2010/07/02
4.3 介面注釋：
★介面的注釋風格基本與類的注釋風格相同；
★在別人使用介面之前，必須了解介面所包含的概念。檢驗乙個介面是否應該定義的簡單方法是：你是否能★夠容易的描述介面的用途；
★介面如何應當和不應當被使用。開發者需要知道該介面如何被使用，也希望知道該介面不能被怎樣使用。
4.4 函式的注釋
★函式頭注釋必須包括：函式執行了什麼功能，為什麼要這樣處理；函式處理過程中對物件的哪些屬性
★可能進行更改；函式執行前後，物件的狀態；
★比較、迴圈等控制結構加注釋（可選）；
★在**的功能並非一目了然的情況下，應當說明為什麼要這樣做；
★區域性變數必須加注釋；
★複雜難寫的**必須加注釋；
4.5類屬性的注釋:
★描述域的用途。使別人知道如何去使用它；
★對於有著複雜事物規則的域，可以加入範例來說明。有時候乙個簡單的小例子，抵的上千言萬語.
第五章問題：
5.2 軟體團隊的模式有哪些？
答：①主治醫師模式；②明星模式；③社群模式；④業餘劇團模式；⑤秘密團隊；⑥**團隊；⑦交響樂團模式；⑧爵士樂模式；⑨功能團隊模式；⑩官僚模式。
第六章問題：
5.1 什麼是敏捷流程？及其原則？
答：敏捷開發是針對傳統的瀑布開發模式的弊端而產生的一種新的開發模式，目標是提高開發效率和響應能力。除了原則和實踐，模式也是很重要的，多研究模式及其應用可以使你更深層次的理解敏捷開發。
原則是：①最重要的是通過盡早和不斷交付有價值的軟體滿足客戶需要。
②我們歡迎需求的變化，即使在開發後期。敏捷過程能夠駕馭變化，保持客戶的競爭優勢。
③經常交付可以工作的軟體，從幾星期到幾個月，時間尺度越短越好。
④業務人員和開發者應該在整個專案過程中始終朝夕在一起工作。
⑤圍繞鬥志高昂的人進行軟體開發，給開發者提供適宜的環境，滿足他們的需要，並相信他們能夠完成任務。
⑥在開發小組中最有效率也最有效果的資訊傳達方式是面對面的交談。
⑦可以工作的軟體是進度的主要度量標準。
⑧敏捷過程提倡可持續開發。出資人、開發人員和使用者應該總是維持不變的節奏。
⑨對卓越技術與良好設計的不斷追求將有助於提高敏捷性。
⑩簡單——盡可能減少工作量的藝術至關重要。
⑪最好的架構、需求和設計都源自自我組織的團隊。
⑫每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。
軟體工程附加題
1.你認為本門課程需要在 進行改進，具體措施有哪些，包括 時間進度安排，專案難度等均可 對於軟體使用，希望在學期初確定所適用軟體，統一進行培訓，使後期進度統一。對於任務方面，希望增加個人和結對任務的權重，在評價時候同樣增加其權重。2.你認為助教 老師 做的不足，限制太多等 說實話，老師助教盡心盡力，...
軟體工程 pair work 附加題
首先,在分組之前,我和室友周敏軒已經詳細閱讀了往屆學長的部落格,認為電梯排程這個專案應該先做ui會比較好一點,於是動手展開了ui的編寫 但分組結果並沒有如我們所願,但我們依然共同進行了ui的編寫,希望在第二次結對程式設計中能夠再一起對ui介面進行更新和完善.ui編寫人員 周敏軒 192 薛亞傑 19...
軟體工程課程總結附加題
1.你認為本門課程需要在 進行改進，具體措施有哪些，包括 時間進度安排，專案難度等均可 答 額 上課有點索然無味0.0 希望在課上能夠多學到一點知識，我想是應該我自己沒適應好吧，還以為這節課是教技術的課程。不過，張老師在課上講到自己的做專案啊之類的經驗的時候，我感覺到受益匪淺，畢竟是過來人的經驗很不...