軟件工程入門經典

軟件工程入門經典 下載 mobi epub pdf 電子書 2024


簡體網頁||繁體網頁
[美] Rod Stephens 著,明道洋,曾慶紅 譯



點擊這裡下載
    


想要找書就要到 圖書大百科
立刻按 ctrl+D收藏本頁
你會得到大驚喜!!

發表於2024-05-08

類似圖書 點擊查看全場最低價

圖書介紹

齣版社: 清華大學齣版社
ISBN:9787302439264
版次:1
商品編碼:11995006
包裝:平裝
開本:16開
齣版時間:2016-07-01
用紙:膠版紙
頁數:376
字數:602000


相關圖書





圖書描述

産品特色

編輯推薦

  ◆詳述軟件工程概念

  ◆闡釋參與軟件工程項目的團隊成員的角色和職責

  ◆指齣軟件工程項目都必須經曆哪些重要階段纔能開發齣功能卓越的可靠應用程序

  ◆詳述主流軟件開發方法及其處理重要開發任務的不同方式

  ◆提供從每章主要知識點引申的習題

  ◆附有詳明的軟件工程術語錶


內容簡介

  全麵講解如何構建穩定可靠的軟件

  《軟件工程入門經典》揭秘專業開發人員為設計和構建穩定、可靠、高效軟件所運用的軟件工程技術和方法。本書通俗易懂,在大量案例的引導下,演示適用於任何編程語言的重要概念和技術;即使你目前不具有編程、開發和管理經驗,同樣可以閱讀和學習本書。每章末尾附有精選習題,以測試你對知識的理解程度,引導你悟透主要概念。本書全麵介紹瞭瀑布、生魚片、敏捷、RAD、Scrum、看闆和極限編程等各種開發方法所涉及的基本任務。

  主要內容

  ◆詳述軟件工程概念

  ◆闡釋參與軟件工程項目的團隊成員的角色和職責

  ◆指齣軟件工程項目都必須經曆哪些重要階段纔能開發齣功能卓越的可靠應用程序

  ◆詳述主流軟件開發方法及其處理重要開發任務的不同方式

  ◆提供從每章主要知識點引申的習題

  ◆附有詳明的軟件工程術語錶


作者簡介

  Rod Stephens兒時夢想成為數學傢,但當在麻省理工學院學習時,他發現編程非常有趣,從此便開始瞭專業的編程生涯。在其職業生涯中,他從事過很多不同領域的應用程序開發,如電話交換、計費、維修調度、稅務處理、汙水處理、演唱會門票銷售、製圖以及專業足球運動員培訓。

  十多年來,Rod 一直都是“微軟Visual Basic 有價值專傢(MVP)”,曾教授過一些編程的入門課程。他撰寫過30 多本書,並且這些書籍還都被翻譯成不同的語言。他撰寫過250 多篇雜誌文章,主要涉及Visual Basic、C#、Visual Basic for Applications、Delphi 以及Java。

  Rod 廣受歡迎的VB Helper 站點(www.vb-helper.com)包含有數韆個針對Visual Basic 程序開發人員的提示、技巧以及示例程序頁麵。他的C# Helper 站點(www.csharphelper.com)包含類似的一些C#開發資源。

  可以通過RodStephens@CSharpHelper.com 或RodStephens@vb-helper.com 和Rod 保持聯係。


目錄

第Ⅰ部分 進階

第1章 軟件工程概覽 3

1.1 需求收集 3

1.2 概要設計 4

1.3 詳細設計 5

1.4 開發 5

1.5 測試 6

1.6 部署 7

1.7 維護 8

1.8 總結和反思 8

1.9 一次性處理所有事項 8

1.10 本章小結 9

第2章 入手之前 13

2.1 文檔管理 13

2.2 曆史文檔 15

2.3 電子郵件 16

2.4 代碼 18

2.5 代碼文檔 18

2.6 應用程序文檔 21

2.7 本章小結 21

第3章 項目管理 25

3.1 管理支持 26

3.2 項目管理 27

3.2.1 PERT圖 28

3.2.2 關鍵路徑方法 33

3.2.3 甘特圖 35

3.2.4 軟件日程安排 36

3.2.5 估算時間 36

3.3 風險管理 41

3.4 本章小結 42

第4章 需求收集 45

4.1 需求定義 46

4.1.1 清晰 46

4.1.2 沒有歧義 46

4.1.3 一緻 47

4.1.4 優先級排序 47

4.1.5 可驗證 50

4.1.6 應避免使用的詞 51

4.2 需求分類 51

4.2.1 受眾導嚮的需求 51

4.2.2 FURPS 54

4.2.3 FURPS+ 54

4.2.4 通用需求 56

4.3 收集需求 57

4.3.1 傾聽客戶(和用戶)的需要 57

4.3.2 使用5W(和一個H) 57

4.3.3 研究用戶 59

4.4 細化需求 60

4.4.1 復製現有係統 60

4.4.2 未蔔先知 61

4.4.3 頭腦風暴 62

4.5 記錄需求 64

4.5.1 UML 64

4.5.2 用戶故事 65

4.5.3 用例 65

4.5.4 原型 66

4.5.5 需求說明 67

4.6 確認和驗證 67

4.7 更改需求 67

4.8 本章小結 68

第5章 概要設計 71

5.1 縱覽全局 72

5.2 指定的事項 73

5.2.1 安全性 73

5.2.2 硬件 74

5.2.3 用戶接口 75

5.2.4 內部接口 76

5.2.5 外部接口 76

5.2.6 架構 77

5.2.7 報錶 83

5.2.8 其他輸齣 83

5.2.9 數據庫 84

5.2.10 配置數據 86

5.2.11 數據流及狀態 86

5.2.12 培訓 87

5.3 UML 87

5.3.1 結構圖 88

5.3.2 行為圖 90

5.3.3 交互圖 93

5.4 本章小結 95

第6章 詳細設計 97

6.1 麵嚮對象設計 98

6.1.1 識彆類 99

6.1.2 創建繼承體係 99

6.1.3 對象組閤 103

6.2 數據庫設計 104

6.2.1 關係數據庫 104

6.2.2 第一範式 106

6.2.3 第二範式 109

6.2.4 第三範式 111

6.2.5 更高級的規範化 112

6.3 本章小結 113

第7章 開發 117

7.1 使用正確的工具 118

7.1.1 硬件 118

7.1.2 網絡 119

7.1.3 開發環境 119

7.1.4 源代碼控製 120

7.1.5 分析器 120

7.1.6 靜態分析工具 120

7.1.7 測試工具 121

7.1.8 源代碼格式器 121

7.1.9 重構工具 121

7.1.10 培訓 121

7.2 選擇算法 121

7.2.1 有效果 122

7.2.2 有效率 122

7.2.3 可預測 124

7.2.4 簡潔 124

7.2.5 預包裝 125

7.3 自上而下的設計 125

7.4 編程提示和技巧 127

7.4.1 保持清醒 127

7.4.2 為人編寫代碼,並非計算機 127

7.4.3 注釋優先 128

7.4.4 編寫自文檔化的代碼 130

7.4.5 保持小巧 131

7.4.6 保持專注 132

7.4.7 避免副作用 132

7.4.8 驗證結果 133

7.4.9 實踐“進攻式”編程 135

7.4.10 使用異常 136

7.4.11 首先編寫異常處理程序 136

7.4.12 切勿重復代碼 137

7.4.13 推遲優化 137

7.5 本章小結 138

第8章 測試 141

8.1 測試的目的 142

8.2 永不消亡的bug 143

8.2.1 收益遞減 143

8.2.2 最後期限 143

8.2.3 影響 143

8.2.4 為時尚早 143

8.2.5 有用性 144

8.2.6 過時 144

8.2.7 這並非一個bug 144

8.2.8 沒有盡頭 145

8.2.9 有總比沒有好 145

8.2.10 修復 bug很危險 145

8.2.11 修復哪些bug 146

8.3 測試級彆 146

8.3.1 單元測試 146

8.3.2 集成測試 148

8.3.3 自動化測試 148

8.3.4 組件接口測試 149

8.3.5 係統測試 150

8.3.6 驗收性測試 150

8.3.7 其他測試類型 151

8.4 測試技術 152

8.4.1 窮舉測試 152

8.4.2 黑盒測試 153

8.4.3 白盒測試 153

8.4.4 灰盒測試 153

8.5 測試習慣 154

8.5.1 清醒時再進行測試和調試 154

8.5.2 測試自己的代碼 154

8.5.3 讓其他人測試你的代碼 155

8.5.4 修復自己的bug 156

8.5.5 修改前請“三思” 157

8.5.6 不要相信魔法 157

8.5.7 查看改變之處 157

8.5.8 修復bug,並非癥狀 158

8.5.9 對測試用例進行測試 158

8.6 如何修復bug 158

8.7 估算bug的數量 159

8.7.1 跟蹤發現的bug 159

8.7.2 播種 160

8.7.3 林肯指數 161

8.8 本章小結 162

第9章 部署 165

9.1 範圍 166

9.2 計劃 166

9.3 切換 167

9.3.1 階段性部署 167

9.3.2 逐步切換 168

9.3.3 增量部署 169

9.3.4 並行測試 170

9.4 部署任務 170

9.5 部署錯誤 171

9.6 本章小結 172

第10章 度量 175

10.1 慶祝會 176

10.2 缺陷分析 176

10.2.1 bug的種類 176

10.2.2 石川圖 178

10.3 軟件度量 181

10.3.1 好的屬性和度量指標的一些特徵 182

10.3.2 度量的用途 182

10.3.3 需要度量的對象 184

10.3.4 規模標準化 186

10.3.5 功能點標準化 188

10.4 本章小結 192

第11章 維護 195

11.1 維護成本 196

11.2 任務分類 197

11.2.1 完成性任務 197

11.2.2 適應性任務 200

11.2.3 糾正性任務 201

11.2.4 預防性任務 203

11.2.5 個彆bug 207

11.2.6 “非我發明” 207

11.3 任務執行 208

11.4 本章小結 208

第Ⅱ部分 模型

第12章 預測模型 215

12.1 模型 215

12.2 預備知識 216

12.3 預測和自適應 216

12.3.1 成功和失敗的標誌 217

12.3.2 利與弊 218

12.4 瀑布 219

12.5 帶有反饋的瀑布 220

12.6 生魚片 221

12.7 增量瀑布 222

12.8 V模型 224

12.9 係統開發生命周期 224

12.10 本章小結 227

第13章 迭代模型 229

13.1 迭代與預測 230

13.2 迭代與增量 231

13.3 原型 232

13.3.1 原型的類型 233

13.3.2 優缺點 234

13.4 螺鏇模型 235

13.4.1 澄清 237

13.4.2 優勢和不足 238

13.5 統一過程 239

13.5.1 優勢和不足 240

13.5.2 RUP 241

13.6 潔淨室模型 241

13.7 本章小結 242

第14章 RAD 245

14.1 RAD的主要原則 246

14.2 James Martin RAD 249

14.3 敏捷開發 249

14.3.1 自組織團隊 252

14.3.2 敏捷方法 253

14.4 XP 256

14.4.1 XP的角色 257

14.4.2 XP的價值觀 257

14.4.3 XP實踐 258

14.5 Scrum 264

14.5.1 Scrum角色 264

14.5.2 Scrum衝刺 265

14.5.3 計劃撲剋 266

14.5.4 燃盡圖 267

14.5.5 速率 268

14.6 精益軟件開發 268

14.7 水晶方法 269

14.7.1 透明水晶 271

14.7.2 黃色水晶 272

14.7.3 橙色水晶 272

14.8 功能驅動開發 274

14.8.1 FDD角色 274

14.8.2 FDD階段 275

14.8.3 FDD迭代裏程碑 277

14.9 敏捷統一過程 278

14.10 規範敏捷交付 280

14.10.1 DAD原則 280

14.10.2 DAD角色 280

14.10.3 DAD階段 281

14.11 動態係統開發方法 282

14.11.1 DSDM階段 282

14.11.2 DSDM原則 283

14.11.3 DSDM角色 284

14.12 看闆軟件開發方法 285

14.12.1 看闆的一些原則 285

14.12.2 和看闆有關的一些實踐 286

14.12.3 看闆圖 286

14.13 本章小結 287

附錄A 習題答案 293

術語錶 337


前言/序言

  前 言

  如今的編程是“程序員正努力創建一個更大更傻的程序”和“世界在嘗試創造更多更傻的人”之間的一種角逐。到目前為止,後者是贏傢。

  ——Rick Cook

  藉助一些現代開發工具,不需要事先設計和計劃,坐在鍵盤旁就可以敲打齣一個可以工作的程序。某些情況下,這還是可行的。我的VB Helper(www.vb-helper.com)和C# Helper(www. csharphelper.com)站點就包含瞭數以韆計的Visual Basic和C#示例程序——這些程序正是通過這樣的方法進行創建的。每當我有一個想法(或是彆人嚮我提齣一個問題時),我都會敲擊齣一個簡單示例程序。

  如果隻有你自己使用而且隻是短期使用這些程序,那麼還好。如果隻用於實驗,演示一些編程技巧,那麼也還好。

  如果是將這種草率粗糙的程序用於生産,其結果將是災難性的。即便作最樂觀的估計,使用這些程序的非編程員也將很快束手無策。最糟的情況下,它們可以破壞計算機,甚至嚴重影響你和朋友、同事之間的關係。

  即使經驗最豐富的開發人員有時也會被這種不靠譜的程序弄得焦頭爛額。我知道有人(我不想指名道姓,但我絕不會乾這種事情)編寫一些簡單的遞歸腳本來刪除某個目錄層次中的文件。遺憾的是,這樣的腳本將以遞歸方式爬行到目錄樹頂部,然後幸災樂禍地刪除係統中的每個文件。這種腳本在停止前僅運行大約5秒鍾,但它已經破壞瞭足夠多的文件,從而導緻必須重新安裝操作係統(實際上,一些開發人員認為每隔一年左右重裝一次操作係統是在鍛煉意誌力。如果認同這樣的看法,不妨嘗試一下)。

  我還認識一位經驗豐富的開發人員。她在測試Windows係統設置時,曾設法把每種係統顔色都設置為黑色,結果卻導緻黑色光標懸停在黑色的桌麵上,顯示的是帶有黑色邊框、菜單以及文本的黑色窗口。此人(不是我)最終通過重啓的方式,通過另一颱色彩正常的計算機,僅通過鍵盤快捷鍵修復瞭顔色設置。這確實是明智的勝利,但我懷疑她寜願沒有發生這件事,也不情願白白浪費兩天的時間。

  對於那些代碼量比較大或者是麵嚮可信賴終端用戶的程序而言,這種自由散漫的開發方式並不適用。為編寫齣安全、有效、可靠的應用程序,不能隻坐下來敲敲鍵盤。你需要“軟件工程”。

  本書主要介紹軟件工程。它將嚮我們闡釋軟件工程是什麼以及如何藉助它創建高效、靈活、健壯的應用程序。

  本書不能使你成為專傢級的係統分析師、軟件架構師、項目經理或程序員,卻嚮我們闡釋瞭這些人做什麼,以及對於高質量的軟件開發而言,他們為什麼是不可或缺的。本書介紹瞭一些入門級工具。你不用一個人去“戰鬥”,或是帶領1000人給FAA開發一個航空交通管製係統,但它的確有助於在不同規模的開發項目中高效工作(當你的老闆意味深長地說“是啊,我們主要使用的是深度結閤瞭XP技術的敏捷開發”時,它也有助於你悟透這句話中的“玄機”)。

  軟件工程的概念

  軟件工程的比較正式的一個概念可能為:“設計、開發、使用、維護軟件的結構化分析方法。”

  更直觀地講,軟件工程是成功的軟件開發所需要的一切,它包含將可能模糊不清、不成熟的想法轉變成為一個強大、直觀的應用程序需要的所有步驟,從而能夠更好地滿足用戶未來日益變化的需求。

  當設計應用程序時,可能僅把軟件工程視為上述過程的開始部分。畢竟,一個航空工程師隻是設計飛機但不建造 軟件工程入門經典 下載 mobi epub pdf txt 電子書 格式


軟件工程入門經典 mobi 下載 pdf 下載 pub 下載 txt 電子書 下載 2024

軟件工程入門經典 下載 mobi pdf epub txt 電子書 格式 2024

軟件工程入門經典 下載 mobi epub pdf 電子書
想要找書就要到 圖書大百科
立刻按 ctrl+D收藏本頁
你會得到大驚喜!!

用戶評價

評分

好書,講的很詳細

評分

不錯的書籍,很有用

評分

時下,吾已浪跡京東數年,但覺世風日下,深知各店之貓膩甚多,不乏其聞。然,唯此寶物與眾皆不同,為齣淤泥之清蓮。使吾為之動容,心馳神往。乃至飯不能食,寢則不安,輾轉反側無法忘懷。於是乎緊衣縮食,湊齊銀兩,傾吾所能而買。客服之熱心與小二之殷切讓人感染,感激憐涕。打開包裹之時,頓時金光四射,屋內升起七彩祥雲,處處都是祥和之氣。吾驚訝之餘便是欣喜若狂,嗚呼哀哉!此寶乃是天上物的,人間又得幾迴求!遂沐浴更衣,焚香告後與傢人共賞此寶。夫則贊嘆不已,不僅贊嘆此寶物款型及做工,超高性價比!且贊吾獨具慧眼與時尚品位,更予唇相贈。京東果然句句實言,毫無誇大欺瞞之嫌。此屬大傢風範,忠義之商賈,更無愧於皇冠之銜。吾不敢獨享此寶,唯恐天譴。便有感而齣此文,句句真言,字字肺腑。嗟!望京東江湖所需此寶之英雄誌士無需貨比三傢,謹記唯此寶為首選也 !

評分

一直在京東商城網購圖書,速度快,快遞員態度不錯

評分

可以可以可以可以可以可以可以可以可以可以可以可以

評分

評分

快遞超級給力 商品不錯

評分

不錯

評分

一次買瞭很多工具書,這些書都還不錯。

類似圖書 點擊查看全場最低價

軟件工程入門經典 mobi epub pdf txt 電子書 格式下載 2024


分享鏈接




相關圖書


本站所有內容均為互聯網搜索引擎提供的公開搜索信息,本站不存儲任何數據與內容,任何內容與數據均與本站無關,如有需要請聯繫相關搜索引擎包括但不限於百度google,bing,sogou

友情鏈接

© 2024 book.qciss.net All Rights Reserved. 圖書大百科 版權所有