軟件工程題型復(fù)習(xí)資料

簡答題

代碼風(fēng)格規(guī)范

• 總原則 （簡明、易懂、無歧義）
  • 縮進：4個字符
  • 行寬：100個字符
  • 括號：恰當(dāng)運用（ ）
  • 斷行與空白的{ }行
  • 分行：一行一條語句
  • 命名：有義、適當(dāng)
  • 下劃線
  • 大小寫
  • 注釋
• Pascal（大駝峰命名法）：所有單詞的第一個字母都大寫
• Camel（小駝峰命名法）：第一個單詞全部小寫，隨后單詞隨Pascal形式
• 通用做法
  • 所有的類型/類/函數(shù)名都用Pascal形式
  • 所有的變量都用Camel形式
  • 類/類型/變量用名詞或組合名詞
  • 所有函數(shù)用動詞或動賓組合詞
• 關(guān)于注釋
  • 注釋是為了解釋程序做什么（What），為什么這樣做（Why）
  • 不要解釋程序是怎么工作的（How）
  • 注釋優(yōu)先原則
    • 編寫源代碼之前先寫好注釋
  • 內(nèi)容要全面
    • 對管理代碼有用的注釋
    • 對理解代碼有用的注釋
  • 采用ASCII字符集
    • 不使用中文，提高可移植性
  • 注釋的位置
    • 函數(shù)頭部的注釋
    • 函數(shù)體內(nèi)部的注釋
  • 注釋的更新
    • 一個誤導(dǎo)的注釋比沒有注釋更糟糕
  • 注釋格式的統(tǒng)一

軟件設(shè)計

• 模塊的概念
  • 構(gòu)成程序的基本單元
  • 具體形式：類、函數(shù)、構(gòu)件、服務(wù)
  • 由邊界元素限定的相鄰的程序元素的序列
• 什么是模塊化
  • 把程序劃分成模塊（獨立命名且可獨立訪問）
  • 劃分的程度：基于目標(biāo)、應(yīng)對復(fù)雜、考慮變化、折衷權(quán)衡
• 耦合（模塊之間的復(fù)雜程度的度量）
  • 數(shù)據(jù)耦合
    • 兩個模塊彼此間通過參數(shù)交換信息，而且交換的信息僅僅是數(shù)據(jù)
  • 控制耦合
    • 如果兩個模塊彼此間傳遞的信息中有控制信息
  • 特征耦合
    • 當(dāng)把整個數(shù)據(jù)結(jié)構(gòu)作為參數(shù)傳遞而被調(diào)用的模塊只需要使用其中一部分?jǐn)?shù)據(jù)元素
  • 公共環(huán)境耦合
    • 當(dāng)兩個或多個模塊通過一個公共數(shù)據(jù)環(huán)境相互作用
  • 內(nèi)容耦合
    • 兩個模塊的程序元素共用
• 內(nèi)聚
  • 模塊內(nèi)部的復(fù)雜程度的度量
• 信息隱藏
  • 變量的局部化
  • 類的封裝
• 分層
  • 設(shè)計策略的分離
  • 界面與實現(xiàn)的分離

軟件工程

• 軟件工程定義
  • 把系統(tǒng)的、有序的、可量化的方法應(yīng)用到軟件的開發(fā)、運營和維護上的過程
• 軟件工程的規(guī)律
  • 時間估計
    • 實際時間總是比預(yù)期要長
  • 增加人手
    • 向進度落后的項目中增加人員，會讓項目更加落后
• 軟件工程基本原理
  • 用分階段的生命周期計劃進行嚴(yán)格管理
  • 堅持進行階段評審
  • 實行現(xiàn)代程序設(shè)計技術(shù)
  • 結(jié)果應(yīng)能清楚的審查
  • 開發(fā)小組的人員應(yīng)該少而精
  • 承認(rèn)不斷改進軟件工程實踐的必要性
• 軟件生命周期和開發(fā)流程
  • 傳統(tǒng)劃分
    • 三個時期
      • 軟件定義
      • 軟件開發(fā)
      • 運行維護
    • 八個階段
      • 問題定義
      • 可行性研究
      • 需求分析
      • 概要設(shè)計
      • 詳細(xì)設(shè)計
      • 編碼和單元測試
      • 綜合測試
      • 軟件維護

團隊

• 團隊（Team）
  • 針對一項目工作，團隊成員彼此依賴
• 團隊的特點
  • 團隊有一致的集體目標(biāo)，要一起完成這目標(biāo)
  • 一個團隊的成員不一定要同時工作
  • 團隊成員有各自的分工，互相依賴合作，共同完成任務(wù)
• 團隊的形成
  • 謹(jǐn)記：成熟的團隊不是一天就形成的
  • 形成初期：一窩蜂模式（Chaos Team）
• 軟件團隊的模式
  • 主治醫(yī)師模式
  • 明星模式
  • 社區(qū)模式
  • 業(yè)余劇團模式
  • 交響樂團模式
  • 爵士樂模式
  • 功能團隊模式
  • 官僚模式
  • 秘密團隊模式
  • 特工團隊模式
• 為什么要選擇團隊模式
  • 一個合適的團隊結(jié)構(gòu)，能更大地改進交流的效率，讓團隊更能把注意力集中在最主要的目標(biāo)——解決用戶需求
• 如何選擇團隊模式
  • 獨裁
  • 顧問
  • 民主
  • 一致

開發(fā)流程

• 寫了再改模式
• 瀑布模型
• 生魚片模型
• 子瀑布模型
• 快速原型模型
• 螺旋模型
• 老板驅(qū)動的流程
• 漸進交付的流程

結(jié)對編程

• 結(jié)對編程 (Pair Programming)
  • 結(jié)對編程就是一種卓有成效的開發(fā)方法，每時每刻都處在代碼復(fù)審的狀態(tài)
• 如何結(jié)對編程 （駕駛員/領(lǐng)航員，兩人共享一個鍵盤，電腦，屏幕）
  • 駕駛員：寫設(shè)計文檔，進行編碼和單元測試等
  • 領(lǐng)航員：審閱駕駛員的文檔；監(jiān)督駕駛員對編碼等開發(fā)流程的執(zhí)行等
  • 駕駛員和領(lǐng)航員不斷輪換角色，不要連續(xù)工作超過一小時，每工作一小時休息15分鐘
  • 主動參與：任何一個任務(wù)都是兩個人的責(zé)任
  • 設(shè)置好結(jié)對編程的環(huán)境：座位、顯示器、桌面等
• 結(jié)對編程的好處
  • 提高設(shè)計質(zhì)量
  • 降低成本
  • 提高解決問題的信心
  • 提高士氣
  • 減輕風(fēng)險
  • 提高效率
• 結(jié)對編程不合適的場景
  • 需要深入研究的項目
  • 驗證測試需要運行很長時間
  • 團隊的人員要在多個項目中工作
• 結(jié)對編程中不好的習(xí)慣
  • 不拘小節(jié)
  • 發(fā)號施令
  • 拼寫糾錯
  • 深藏不露
  • 跳躍很大

需求分析

• 獲取和引導(dǎo)需求
  • 需求來自用戶
  • 需求來自管理機構(gòu)
  • 需求來自企業(yè)內(nèi)部
  • 需求來自技術(shù)團隊
  • 需求來自要“更好地了解用戶的行為和需求”
• 需求的分類
  • 對產(chǎn)品功能的需求
  • 服務(wù)質(zhì)量需求
  • 對產(chǎn)品開發(fā)過程的需求
• 軟件需求
  • 獲取和引導(dǎo)需求
  • 分析和定義需求
  • 驗證需求
  • 管理需求
• 獲取需求方法
  • 用戶調(diào)研
    • 焦點小組
    • 卡片分類
    • 用戶調(diào)查問卷

應(yīng)用分析題

• 流程圖或活動圖

  
  
  image

• 類圖

  
  
  image

構(gòu)建模型題

• 典型用戶的模板

  • 名字（越自然越好）
  • 年齡和收入（不同年齡和收入的用戶有不同的需求）
  • 代表的用戶在市場上的比例和重要性
  • 使用這個軟件的典型場景
  • 使用本產(chǎn)品的環(huán)境（在辦公室/ 家里/ 沙發(fā)/ 床上/ 公共汽車/ 地鐵……）
  • 生活/工作情況
  • 知識層次和能力（教育程度，對電腦、互聯(lián)網(wǎng)的熟悉程度）
  • 用戶的動機、目的和困難（困難 = 需要解決的問題）
  • 用戶的偏好

• 示例

  
  
  image
  
  
  image