出版時間:2012-1 出版社:機械工業(yè)出版社 作者:沙赫 頁數(shù):380
Tag標簽:無
內(nèi)容概要
本書是軟件工程領(lǐng)域的經(jīng)典著作,被加州大學(xué)伯克利分校等180多所美國高校選作教材。本書第8版繼續(xù)保持了前七版的特色,采用傳統(tǒng)方法與面向?qū)ο蠓椒ú⒅氐姆绞剑嫦到y(tǒng)地介紹軟件工程的理論與實踐,并新增了第10章(第一部分的關(guān)鍵內(nèi)容)和第18章(新興技術(shù))兩章內(nèi)容。全書分為兩大部分,第一部分介紹軟件工程概念,第二部分著重軟件工程技術(shù),教師可根據(jù)不同教學(xué)目的從任一部分開始講授課程。
本書是高等院校軟件工程課程的理想教材,同時也是專業(yè)軟件開發(fā)人員和管理者的理想?yún)⒖紩?/pre>作者簡介
作者:(美國)沙赫 (Stephen R.Schach) 譯者:鄧迎春 韓松 等書籍目錄
出版者的話
譯者序
前言
第1章軟件工程的范疇
1.1歷史方面
1.2經(jīng)濟方面
1.3維護性方面
1.3.1維護的傳統(tǒng)和現(xiàn)代觀點
1.3.2交付后維護的重要性
1.4需求、分析和設(shè)計方面
1.5小組編程方面
1.6為什么沒有計劃階段
1.7為什么沒有測試階段
1.8為什么沒有文檔階段
1.9面向?qū)ο蠓缎?br />1.10正確看待面向?qū)ο蠓缎?br />1.11術(shù)語
1.12道德問題
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第一部分軟件工程概念
第2章軟件生命周期模型
2.1理論上的軟件開發(fā)
2.2winburg小型實例研究
2.3winburg小型實例研究心得
2.4野鴨拖拉機公司小型實例研究
2.5迭代和遞增
2.6修訂的winburg小型實例研究
2.7迭代和遞增的風(fēng)險和其他方面
2.8迭代和遞增的控制
2.9其他生命周期模型
2.9.1編碼-修補生命周期模型
2.9.2瀑布生命周期模型
2.9.3快速原型開發(fā)生命周期模型
2.9.4開源生命周期模型
2.9.5敏捷過程
2.9.6同步-穩(wěn)定生命周期模型
2.9.7螺旋生命周期模型
2.10生命周期模型的比較
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第3章軟件過程
3.1統(tǒng)一過程
3.2面向?qū)ο蠓缎蛢?nèi)的迭代和遞增
3.3需求流
3.4分析流
3.5設(shè)計流
3.6實現(xiàn)流
3.7測試流
3.7.1需求制品
3.7.2分析制品
3.7.3設(shè)計制品
3.7.4實現(xiàn)制品
3.8交付后維護
3.9退役
3.10統(tǒng)一過程的各階段
3.10.1開始階段
3.10.2細化階段
3.10.3構(gòu)建階段
3.10.4轉(zhuǎn)換階段
3.11一維與二維生命周期模型
3.12改進軟件過程
3.13能力成熟度模型
3.14軟件過程改進方面的其他努力
3.15軟件過程改進的代價和收益
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第4章軟件小組
4.1小組組織
4.2民主小組方法
4.3傳統(tǒng)的主程序員小組方法
4.3.1《紐約時報》項目
4.3.2傳統(tǒng)的主程序員小組方法的不實用性
4.4主程序員小組和民主小組之外的編程小組
4.5同步-穩(wěn)定小組
4.6敏捷過程小組
4.7開源編程小組
4.8人員能力成熟度模型
4.9選擇合適的小組組織
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第5章軟件工程工具
5.1逐步求精法
5.2成本-效益分析法
5.3分治
5.4關(guān)注分離
5.5軟件度量
5.6case
5.7case的分類
5.8case的范圍
5.9軟件版本
5.9.1修訂版
5.9.2變種版
5.10配置控制
5.10.1交付后維護期間的配置控制
5.10.2基準
5.10.3產(chǎn)品開發(fā)過程中的配置控制
5.11建造工具
5.12使用case技術(shù)提高生產(chǎn)力
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第6章測試
6.1質(zhì)量問題
6.1.1軟件質(zhì)量保證
6.1.2管理獨立
6.2非執(zhí)行測試
6.2.1走查
6.2.2管理走查
6.2.3審查
6.2.4審查與走查的對比
6.2.5評審的優(yōu)缺點
6.2.6審查的度量
6.3執(zhí)行測試
6.4應(yīng)該測試什么
6.4.1實用性
6.4.2可靠性
6.4.3健壯性
6.4.4性能
6.4.5正確性
6.5測試與正確性證明
6.5.1正確性證明的例子
6.5.2正確性證明小型實例研究
6.5.3正確性證明和軟件工程
6.6誰應(yīng)當(dāng)完成執(zhí)行測試
6.7測試什么時候停止
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第7章從模塊到對象
7.1什么是模塊
7.2內(nèi)聚
7.2.1偶然性內(nèi)聚
7.2.2邏輯性內(nèi)聚
7.2.3時間性內(nèi)聚
7.2.4過程性內(nèi)聚
7.2.5通信性內(nèi)聚
7.2.6功能性內(nèi)聚
7.2.7信息性內(nèi)聚
7.2.8內(nèi)聚示例
7.3耦合
7.3.1內(nèi)容耦合
7.3.2共用耦合
7.3.3控制耦合
7.3.4印記耦合
7.3.5數(shù)據(jù)耦合
7.3.6耦合示例
7.3.7耦合的重要性
7.4數(shù)據(jù)封裝
7.4.1數(shù)據(jù)封裝和產(chǎn)品開發(fā)
7.4.2數(shù)據(jù)封裝和產(chǎn)品維護
7.5抽象數(shù)據(jù)類型
7.6信息隱藏
7.7對象
7.8繼承、多態(tài)和動態(tài)綁定
7.9面向?qū)ο蠓缎?br />本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第8章可重用性和可移植性
8.1重用的概念
8.2重用的障礙
8.3重用實例研究
8.3.1raytheon導(dǎo)彈系統(tǒng)部
8.3.2歐洲航天局
8.4對象和重用
8.5設(shè)計和實現(xiàn)期間的重用
8.5.1設(shè)計重用
8.5.2應(yīng)用框架
8.5.3設(shè)計模式
8.5.4軟件體系結(jié)構(gòu)
8.5.5基于組件的軟件工程
8.6其他設(shè)計模式
8.6.1flic小型實例研究
8.6.2適配器設(shè)計模式
8.6.3橋設(shè)計模式
8.6.4迭代器設(shè)計模式
8.6.5抽象工廠設(shè)計模式
8.7設(shè)計模式的種類
8.8設(shè)計模式的優(yōu)缺點
8.9重用及互聯(lián)網(wǎng)
8.10重用和交付后維護
8.11可移植性
8.11.1硬件的不兼容性
8.11.2操作系統(tǒng)的不兼容性
8.11.3數(shù)值計算軟件的不兼容性
8.11.4編譯器的不兼容性
8.12為什么需要可移植性
8.13實現(xiàn)可移植性的技術(shù)
8.13.1可移植的系統(tǒng)軟件
8.13.2可移植的應(yīng)用軟件
8.13.3可移植的數(shù)據(jù)
8.13.4模型驅(qū)動結(jié)構(gòu)
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第9章計劃和估算
9.1計劃和軟件過程
9.2周期和成本估算
9.2.1產(chǎn)品規(guī)模的度量
9.2.2成本估算技術(shù)
9.2.3中間cocomo
9.2.4cocomo ii
9.2.5跟蹤周期和成本估算
9.3軟件項目管理計劃的組成
9.4軟件項目管理計劃框架
9.5ieee 軟件項目管理計劃
9.6計劃測試
9.7計劃面向?qū)ο蟮捻椖?br />9.8培訓(xùn)需求
9.9文檔標準
9.10用于計劃和估算的case工具
9.11測試軟件項目管理計劃
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第二部分軟件生命周期的工作流
第10章第一部分的關(guān)鍵內(nèi)容
10.1軟件開發(fā):理論與實踐
10.2迭代和遞增
10.3統(tǒng)一過程
10.4工作流概述
10.5軟件小組
10.6成本-效益分析法
10.7度量
10.8case
10.9版本和配置
10.10測試術(shù)語
10.11執(zhí)行測試和非執(zhí)行測試
10.12模塊性
10.13重用
10.14軟件項目管理計劃
本章回顧
習(xí)題
第11章需求
11.1確定客戶需要什么
11.2需求流概述
11.3理解應(yīng)用域
11.4業(yè)務(wù)模型
11.4.1訪談
11.4.2其他技術(shù)
11.4.3用例
11.5初始需求
11.6對應(yīng)用域的初始理解:msg基金實例研究
11.7初始業(yè)務(wù)模型:msg基金實例研究
11.8初始需求:msg基金實例研究
11.9繼續(xù)需求流:msg基金實例研究
11.10修訂需求:msg基金實例研究
11.11測試流:msg基金實例研究
11.12傳統(tǒng)的需求階段
11.13快速原型開發(fā)
11.14人的因素
11.15重用快速原型
11.16需求流的case工具
11.17需求流的度量
11.18需求流面臨的挑戰(zhàn)
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第12章傳統(tǒng)的分析
12.1規(guī)格說明文檔
12.2非形式化規(guī)格說明
12.3結(jié)構(gòu)化系統(tǒng)分析
12.4結(jié)構(gòu)化系統(tǒng)分析:msg基金實例研究
12.5其他半形式化技術(shù)
12.6建造實體-關(guān)系模型
12.7有窮狀態(tài)機
12.8petri網(wǎng)
12.9z
12.9.1z:電梯問題實例研究
12.9.2z的分析
12.10其他的形式化技術(shù)
12.11傳統(tǒng)分析技術(shù)的比較
12.12在傳統(tǒng)分析階段測試
12.13傳統(tǒng)分析階段的case工具
12.14傳統(tǒng)分析階段的度量
12.15軟件項目管理計劃:msg基金實例研究
12.16傳統(tǒng)分析階段面臨的挑戰(zhàn)
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第13章面向?qū)ο蠓治?br />13.1分析流
13.2抽取實體類
13.3面向?qū)ο蠓治觯弘娞輪栴}實例研究
13.4功能建模:電梯問題實例研究
13.5實體類建模:電梯問題實例研究
13.5.1名詞抽取
13.5.2crc卡片
13.6動態(tài)建模:電梯問題實例研究
13.7測試流:面向?qū)ο蠓治?br />13.8抽取邊界類和控制類
13.9初始功能模型:msg基金實例研究
13.10初始類圖:msg基金實例研究
13.11初始動態(tài)模型:msg基金實例研究
13.12修訂實體類:msg基金實例研究
13.13抽取邊界類:msg基金實例研究
13.14抽取控制類:msg基金實例研究
13.15用例實現(xiàn):msg基金實例研究
13.15.1estimate funds available for week用例
13.15.2manage an asset用例
13.15.3update estimated annual operating expenses用例
13.15.4produce a report用例
13.16類圖遞增:msg基金實例研究
13.17測試流:msg基金實例研究
13.18統(tǒng)一過程中的規(guī)格說明文檔
13.19關(guān)于參與者和用例更詳細的內(nèi)容
13.20面向?qū)ο蠓治隽鞯腸ase工具
13.21面向?qū)ο蠓治隽鞯亩攘?br />13.22面向?qū)ο蠓治隽髅媾R的挑戰(zhàn)
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第14章設(shè)計
14.1設(shè)計和抽象
14.2面向操作設(shè)計
14.3數(shù)據(jù)流分析
14.3.1小型實例研究:字數(shù)統(tǒng)計
14.3.2數(shù)據(jù)流分析擴展
14.4事務(wù)分析
14.5面向數(shù)據(jù)設(shè)計
14.6面向?qū)ο笤O(shè)計
14.7面向?qū)ο笤O(shè)計:電梯問題實例研究
14.8面向?qū)ο笤O(shè)計:msg基金實例研究
14.9設(shè)計流
14.10測試流:設(shè)計
14.11測試流:msg基金實例研究
14.12詳細設(shè)計的形式化技術(shù)
14.13實時設(shè)計技術(shù)
14.14設(shè)計的case工具
14.15設(shè)計的度量
14.16設(shè)計流面臨的挑戰(zhàn)
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第15章實現(xiàn)
15.1編程語言的選擇
15.2第四代語言
15.3良好的編程實踐
15.3.1使用一致和有意義的變量名
15.3.2自文檔代碼的問題
15.3.3使用參數(shù)
15.3.4為增加可讀性的代碼編排
15.3.5嵌套的if語句
15.4編碼標準
15.5代碼重用
15.6集成
15.6.1自頂向下的集成
15.6.2自底向上的集成
15.6.3三明治集成
15.6.4面向?qū)ο螽a(chǎn)品的集成
15.6.5集成的管理
15.7實現(xiàn)流
15.8實現(xiàn)流:msg基金實例研究
15.9測試流:實現(xiàn)
15.10測試用例選擇
15.10.1規(guī)格說明測試與代碼測試
15.10.2規(guī)格說明測試的可行性
15.10.3代碼測試的可行性
15.11黑盒單元測試技術(shù)
15.11.1等價測試和邊界值分析
15.11.2功能測試
15.12黑盒測試用例:msg基金實例研究
15.13玻璃盒單元測試技術(shù)
15.13.1結(jié)構(gòu)測試:語句、分支和路徑覆蓋
15.13.2復(fù)雜性度量
15.14代碼走查和審查
15.15單元測試技術(shù)的比較
15.16凈室
15.17測試對象時潛在的問題
15.18單元測試的管理方面
15.19何時該重實現(xiàn)而不是調(diào)試代碼制品
15.20集成測試
15.21產(chǎn)品測試
15.22驗收測試
15.23測試流:msg基金實例研究
15.24實現(xiàn)的case工具
15.24.1軟件開發(fā)全過程的case工具
15.24.2集成化開發(fā)環(huán)境
15.24.3商業(yè)應(yīng)用環(huán)境
15.24.4公共工具基礎(chǔ)結(jié)構(gòu)
15.24.5環(huán)境的潛在問題
15.25測試流的case工具
15.26實現(xiàn)流的度量
15.27實現(xiàn)流面臨的挑戰(zhàn)
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第16章交付后維護
16.1開發(fā)與維護
16.2為什么交付后維護是必要的
16.3對交付后維護程序員的要求是什么
16.4交付后維護小型實例研究
16.5交付后維護的管理
16.5.1缺陷報告
16.5.2批準對產(chǎn)品的修改
16.5.3確保可維護性
16.5.4迭代維護造成的問題
16.6面向?qū)ο筌浖木S護
16.7交付后維護技能與開發(fā)技能
16.8逆向工程
16.9交付后維護期間的測試
16.10交付后維護的case工具
16.11交付后維護的度量
16.12交付后維護:msg基金實例研究
16.13交付后維護面臨的挑戰(zhàn)
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第17章uml的進一步討論
17.1uml不是一種方法
17.2類圖
17.2.1聚合
17.2.2多重性
17.2.3組合
17.2.4泛化
17.2.5關(guān)聯(lián)
17.3注解
17.4用例圖
17.5構(gòu)造型
17.6交互圖
17.7狀態(tài)圖
17.8活動圖
17.9包
17.10組件圖
17.11部署圖
17.12uml圖回顧
17.13uml和迭代
本章回顧
進一步閱讀指導(dǎo)
習(xí)題
第18章新興技術(shù)
18.1面向?qū)用婕夹g(shù)
18.2模型驅(qū)動技術(shù)
18.3基于組件技術(shù)
18.4面向服務(wù)技術(shù)
18.5面向服務(wù)技術(shù)和基于組件技術(shù)的比較
18.6社交計算
18.7web工程
18.8云技術(shù)
18.9web 3.0
18.10計算機安全
18.11模型檢查
18.12目前和未來
本章回顧
進一步閱讀指導(dǎo)
附錄
附錄a學(xué)期項目:巧克力愛好者匿名
附錄b軟件工程資源
附錄c需求流:msg基金實例研究
附錄d結(jié)構(gòu)化系統(tǒng)分析:msg基金實例研究
附錄e分析流:msg基金實例研究
附錄f軟件項目管理計劃:msg基金實例研究
附錄g設(shè)計流:msg基金實例研究
附錄h實現(xiàn)流:msg基金實例研究(c++版)
附錄i實現(xiàn)流:msg基金實例研究(java版)
附錄j測試流:msg基金實例研究章節(jié)摘錄
版權(quán)頁:插圖:2.4 野鴨拖拉機公司小型實例研究野鴨拖拉機公司在全美國的大部分地區(qū)銷售拖拉機。該公司曾經(jīng)要求它的軟件部門開發(fā)一個新的軟件產(chǎn)品,能夠處理它的業(yè)務(wù)的各個方面。例如,該產(chǎn)品必須能夠處理銷售、庫存以及向銷售人員支付傭金,還能提供所有必需的財會功能。當(dāng)這個軟件產(chǎn)品正在實現(xiàn)的時候,野鴨拖拉機公司買下了加拿大的一家拖拉機公司。野鴨拖拉機公司的管理層決定,為了省錢,把加拿大的業(yè)務(wù)并到美國的業(yè)務(wù)中去。這意味著該軟件完成前要進行修改:1)必須修改它來處理增加的銷售地區(qū)。2)必須擴展它來處理那些在加拿大有所不同的業(yè)務(wù)方面,如稅費。3)它必須擴展以處理兩種不同的貨幣,美元和加元。野鴨拖拉機公司是一個快速增長的公司,它具有良好的業(yè)務(wù)前景。接管加拿大拖拉機公司是一個積極的進展,這很可能帶來未來幾年更大的效益。但是,從軟件部門的觀點來看,購買這家加拿大的拖拉機公司可能是一場災(zāi)難。要不是進行需求、分析和設(shè)計的時候考慮到加入未來可能的擴展,加入加拿大銷售地區(qū)的工作量可能非常大,可能拋棄迄今做的每件事而從零做起會更高效。原因是改變這個階段的產(chǎn)品與在該產(chǎn)品的生命周期的后期(見圖1-5)修改它是相似的。擴展軟件處理與加拿大市場有關(guān)的方面以及加拿大貨幣可能同樣困難。即使軟件是經(jīng)過深思熟慮的,并且最初的設(shè)計確實是可擴展的,設(shè)計出的拼補在一起的產(chǎn)品不可能如最初就設(shè)計成滿足美國和加拿大業(yè)務(wù)那樣結(jié)合得好。這會給將來的維護帶來嚴重的隱患。野鴨拖拉機公司軟件部是移動目標問題的犧牲品。就是說,在軟件正在開發(fā)的時候,需求改變了。它與改變的原因非常值得無關(guān)。事實是,接管加拿大公司對于正在開發(fā)的軟件質(zhì)量是非常有害的。在某些情況下,移動目標的原因不太良好。有時一個組織內(nèi)有權(quán)利的高層管理人會不斷地改變關(guān)于正在開發(fā)的軟件產(chǎn)品的功能的想法。在另一種情形下,是特性的蔓延,即連續(xù)地向需求中加入小的甚至是瑣碎的特性。但是,不管是什么原因,頻繁的改變,不管看起來多么微不足道,對于一個軟件產(chǎn)品的健康狀況都是有害的。重要的是一個軟件產(chǎn)品設(shè)計成一套盡可能獨立的組件,以使對于該軟件某個部分的改變不在代碼明顯無關(guān)的部分引入差錯,稱為退化(性)差錯(regression fault)。當(dāng)做大量改變的時候,結(jié)果是在代碼內(nèi)部引起聯(lián)動。最后,存在許多的聯(lián)動實際上都會引入一個或多個退化差錯。在這種時候,唯一能做的就是重新設(shè)計整個軟件產(chǎn)品并重新實現(xiàn)它。遺憾的是,對移動目標問題目前還沒有解決辦法。對需求的積極性改變而言,業(yè)務(wù)不斷增長的公司總是要改變的,這些改變必須反映在公司的重要任務(wù)軟件產(chǎn)品中。對于消極性改變,如果個人要求做這些改變的決定有較大可能,便無法阻止對正在進行的實現(xiàn)做修改,也無法阻止對該軟件產(chǎn)品將來的維護性的損害。編輯推薦
《軟件工程:面向?qū)ο蠛蛡鹘y(tǒng)的方法(原書第8版)》是計算機科學(xué)叢書之一!圖書封面
圖書標簽Tags
無評論、評分、閱讀與下載