附加題1---我想搞懂的軟體工程問題

標籤：

第一章問題：

1.2.1 軟體有哪些形式？

答：①系統軟體：作業系統、裝置驅動程式、工具軟體等；②應用軟體：使用者使用它們來完成工作，從管理核電廠到寫文章，或者是通訊、遊戲、瀏覽網頁、播放視頻等；③惡意軟體：軟體病毒等。

 

第二章問題：

2.1 什麼是單元測試？其建立函數主要步驟？

答：單元測試（unit testing），是指對軟體中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，一般來說，要根據實際情況去判定其具體含義，如C語言中單元指一個函數，Java裡單元指一個類，圖形化的軟體中可以指一個視窗或一個菜單等。總的來說，單元就是人為規定的最小的被測功能模組。單元測試是在軟體開發過程中要進行的最低層級的測試活動，軟體的獨立單元將在與程式的其他部分相隔離的情況下進行測試。

①設定資料；②使用被測試類型的功能；③比較實際結果和預期的結果。

 

第三章問題：

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 使用括弧來控制操作符的運算順序，以免使用java預設的操作符優先順序順序。
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
// 添加錯誤資料修改後繼續批量儲存的處理函數 saveBatch(
@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---我想搞懂的軟體工程問題