度量信息系統(tǒng)交付質(zhì)量

內(nèi)容概要

　　隨著計算機技術(shù)的飛速發(fā)展和在軍事領(lǐng)域中的廣泛應(yīng)用，軍用軟件已成為多種武器裝備的重要組成部分。在某種程度上，武器裝備體系中軟件的含量與水平已成為其信息化程度的主要標志。本書針對軟件分析、設(shè)計、開發(fā)、測試、維護等各個階段，研究提高軟件可信性的理論和方法，研究如何對軟件可信性進行評估和度量。

作者簡介

作者:(美)Duggan

書籍目錄

第一部分 質(zhì)量概念引論和概述
　第1章 信息系統(tǒng)質(zhì)量概述
　　1.1 緒論
　　1.2 信息系統(tǒng)交付困難的本質(zhì)
　　1.2.1 技術(shù)上面臨的挑戰(zhàn)
　　1.2.2 信息系統(tǒng)交付生命周期中的挑戰(zhàn)
　　1.3 信息系統(tǒng)質(zhì)量模型
　　1.4 信息系統(tǒng)質(zhì)量的人員維度
　　1.5 信息系統(tǒng)質(zhì)量的過程管理維度
　　1.5.1 cmm和cmmi
　　1.5.2 建立信息系統(tǒng)開發(fā)過程
　　1.5.3 軟件生產(chǎn)方法
　　1.6 信息系統(tǒng)產(chǎn)品質(zhì)量和成功的系統(tǒng)
　　1.6.1 產(chǎn)品質(zhì)量屬性
　　1.6.2 信息系統(tǒng)質(zhì)量與信息系統(tǒng)成功
　　1.7 總結(jié)與結(jié)論
　　參考文獻
　第2章 軟件質(zhì)量概念和管理問題概述
　　2.1 引言
　　2.2 軟件質(zhì)量基礎(chǔ)
　　2.2.1 軟件工程文化與倫理
　　2.2.2 質(zhì)量的價值和成本
　　2.2.3 模型和質(zhì)量特征
　　2.3 軟件質(zhì)量管理過程
　　2.3.1 軟件質(zhì)量保證過程
　　2.3.2 軟件產(chǎn)品質(zhì)量
　　2.4 實踐考慮
　　2.4.1 軟件質(zhì)量需求
　　2.4.2 軟件質(zhì)量測量
　　2.4.3 軟件質(zhì)量的改進
　　2.5 未來趨勢和小結(jié)
　　參考文獻
　第3章 軟件質(zhì)量觀
　　3.1 引言
　　3.2 背景
　　3.3 質(zhì)量的含義
　　3.3.1 各種質(zhì)量觀
　　3.3.2 軟件質(zhì)量觀
　　3.3.3 模型評論
　　3.3.4 更多關(guān)于產(chǎn)品模型的研究
　　3.4 用于測度軟件質(zhì)量的軟件評價框架
　　3.5 總結(jié)
　　參考文獻
第二部分 信息系統(tǒng)交付早期的質(zhì)量
　第4章 一種需求缺陷問題的解決方法
　　4.1 簡介
　　4.2 行為樹
　　4.3 演化設(shè)計
　　4.3.1 前置條件公理
　　4.3.2 交互公理
　　4.4 需求翻譯
　　4.4.1 實例翻譯
　　4.5 需求集成
　　4.5.1 集成實例
　　4.5.2 集成缺陷檢測
　　4.5.3 缺失條件和事件
　　4.5.4 逆轉(zhuǎn)缺陷的缺失
　　4.5.5 死鎖、活鎖及安全性檢查
　　4.5.6 逆轉(zhuǎn)矛盾缺陷的發(fā)現(xiàn)
　　4.6 與其他方法的比較
　　4.7 結(jié)論
　　參考文獻
　第5章 用戶參與需求規(guī)約質(zhì)量保證
　　5.1 簡介
　　5.2 用戶參與改進需求規(guī)約質(zhì)量
　　5.3 用于規(guī)約的模型概述
　　5.3.1 流程圖
　　5.3.2 實體關(guān)系圖（erd）
　　5.3.3 決策表
　　5.4 統(tǒng)一建模語言(uml)用例
　　5.4.1 petri網(wǎng)
　　5.5 動畫系統(tǒng)工程（ase）
　　5.5.1 ase有效性指標
　　5.6 總結(jié)和結(jié)論
　　參考文獻
　第6章 學(xué)術(shù)故事
　　6.1 引言
　　6.1.1 背景
　　6.2 論點和問題
　　6.2.1 確認
　　6.2.2 場景關(guān)注點
　　6.3 解決方法和建議
　　6.3.1 確認
　　6.3.2 場景方法學(xué)
　　6.3.3 場景范例
　　6.3.4 設(shè)備：農(nóng)夫助手
　　6.3.5 性能
　　6.4 情景
　　6.4.1 加油：一次昂貴的測試
　　6.4.2 收割作物
　　6.5 結(jié)論
　　參考文獻
　　致謝
第三部分 過程對信息系統(tǒng)質(zhì)量的貢獻
　第7章 過程中心論對信息系統(tǒng)質(zhì)量的貢獻
　　7.1 引言
　　7.2 背景：過程管理的有效性
　　7.2.1 能力成熟度模型
　　7.2.2 成熟度等級
　　7.3 信息系統(tǒng)過程管理：原則和實踐
　　7.3.1 開發(fā)人員
　　7.3.2 技術(shù)
　　7.3.3 方法
　　7.4 對過程中心論的展望
　　7.4.1 公認的優(yōu)勢
　　7.4.2 報告的問題
　　7.4.3 折中觀點
　　7.5 啟示與結(jié)論
　　參考文獻
　　尾注
　第8章 開發(fā)者驅(qū)動的信息系統(tǒng)質(zhì)量——軟件過程改進的指導(dǎo)方針
　　8.1 引言
　　8.1.1 研究目的
　　8.1.2 研究問題
　　8.2 背景和研究基礎(chǔ)
　　8.2.1 在組織中定義成功的spi推廣
　　8.2.2 影響spi滿意度的因素：個人控制
　　8.2.3 影響spi使用的因素：質(zhì)量、生產(chǎn)力、對有效性的認知
　　8.3 研究方法
　　8.3.1 將個人軟件過程（pspsm 1）作為軟件過程改進實例
　　8.3.2 數(shù)據(jù)收集
　　8.4 討論
　　8.4.1 開發(fā)者個人控制
　　8.4.2 對質(zhì)量和生產(chǎn)力的體會
　　8.4.3 有效性認知的其他因素
　　8.5 選擇和執(zhí)行spi的管理指導(dǎo)方針
　　8.5.1 選擇spi的指導(dǎo)方針
　　8.5.2 spi培訓(xùn)的指導(dǎo)方針
　　8.5.3 選擇執(zhí)行環(huán)境的指導(dǎo)方針
　　8.6 未來的研究方向
　　參考文獻
　　尾注
　第9章 系統(tǒng)開發(fā)中使用敏捷方法提高質(zhì)量
　　9.1 引言
　　9.2 質(zhì)量定義
　　9.3 系統(tǒng)開發(fā)的其他方法
　　9.3.1 原型和快速應(yīng)用開發(fā)
　　9.3.2 其他方法與sdlc的不同之處
　　9.4 敏捷方法
　　9.4.1 敏捷方法的原則和價值
　　9.4.2 敏捷方法可視為一種哲學(xué)思想
　　9.4.3 敏捷核心實踐
　　9.5 結(jié)對編程：敏捷方法實踐的實例
　　9.5.1 程序設(shè)計的團隊方法
　　9.5.2 結(jié)對編程的優(yōu)點
　　9.5.3 結(jié)對編程的缺點
　　9.5.4 敏捷方法的價值觀
　　9.5.5 價值觀如何塑造項目開發(fā)
　　9.5.6 接受改變很重要
　　9.5.7 資源權(quán)衡是可能的
　　9.5.8 保證質(zhì)量是關(guān)鍵
　　9.5.9 使用敏捷方法需要注意的問題
　　9.6 未來的研究問題
　　9.7 結(jié)論和建議
　　參考文獻
　第10章 質(zhì)量度量和貝葉斯分析——極限編程案例
　　10.1 引言
　　10.2 背景
　　10.2.1 xp相關(guān)研究文獻
　　10.2.2 研究假設(shè)
　　10.3 實驗內(nèi)容和設(shè)計
　　10.3.1 項目參與者和過程
　　10.3.2 實驗設(shè)計
　　10.3.3 變量和測度
　　10.3.4 分析過程
　　10.4 分析結(jié)果
　　10.5 討論
　　10.6 總結(jié)
　　參考文獻
第四部分 軟件過程改進計劃和方法學(xué)的風(fēng)險管理
　第11章 信息系統(tǒng)風(fēng)險管理方法
　　11.1 引言
　　11.2 風(fēng)險管理文獻分析
　　11.2.1 風(fēng)險列表
　　11.2.2 風(fēng)險-行動列表
　　11.2.3 風(fēng)險-策略模型
　　11.2.4 風(fēng)險-策略分析
　　11.3 行動研究
　　11.4 案例：spi中的風(fēng)險管理方法
　　11.4.1 企業(yè)案例
　　11.4.2 行動研究計劃
　　11.4.3 管理軟件過程改進風(fēng)險
　　11.5 結(jié)論
　　參考文獻
　第12章檢查信息系統(tǒng)開發(fā)方法學(xué)中評價框架和元建模范型的質(zhì)量
　　12.1 介紹
　　12.2 元模型、評價框架和元信息管理
　　12.2.1 基本概念
　　12.2.2 元模型和評價框架使用的基本原理
　　12.3 方法評價框架和方法工程元模型的檢驗和粗略分類
　　12.3.1 歐洲方法
　　12.3.2 一種通用評估框架
　　12.3.3 desmet
　　12.3.4 tudor及其框架
　　12.3.5 社會控制論框架
　　12.3.6 nimsad
　　12.3.7 metaphor
　　12.3.8 case?shells
　　12.3.9 metaview系統(tǒng)
　　12.3.10 case數(shù)據(jù)交換格式（case data inferchange format,cdif）
　　12.3.11 cdm?filters
　　12.4 其他方法元建模和方法集成項目
　　12.5 評價框架和元模型總結(jié)
　　12.6 已知框架和元模型剖析
　　12.7 結(jié)論
　　參考文獻
第五部分 新興領(lǐng)域中的信息系統(tǒng)質(zhì)量問題
　第13章 軟件質(zhì)量和開源過程
　　13.1 介紹
　　13.2 背景
　　13.2.1 軟件質(zhì)量
　　13.2.2 開源過程
　　13.2.3 專利軟件與開源軟件
　　13.3 開源機制
　　13.3.1 軟件的生產(chǎn)者
　　13.3.2 軟件使用者
　　13.3.3 同行評審過程
　　13.3.4 調(diào)試和反饋
　　13.3.5 演化式生存
　　13.4 質(zhì)量和開源過程
　　13.4.1 用戶是共同開發(fā)者
　　13.4.2 早發(fā)布、常發(fā)布
　　13.4.3 給予足夠關(guān)注
　　13.5 軟件方法學(xué)比較
　　13.6 未來趨勢
　　13.7 結(jié)論
　　參考文獻
　　尾注
　第14章 創(chuàng)建政府部門信息系統(tǒng)質(zhì)量
　　14.1 引言
　　14.2 背景：公共信息系統(tǒng)的不同之處
　　14.3 多變的政府質(zhì)量需求
　　14.3.1 政府系統(tǒng)質(zhì)量需求因設(shè)計而不同
　　14.3.2 高質(zhì)量系統(tǒng)經(jīng)久耐用；合格的質(zhì)量系統(tǒng)是埋頭苦干的老黃牛
　　14.3.3 政府信息系統(tǒng)不同質(zhì)量的案例
　　14.4 未來趨勢：沒有銀彈
　　14.5 結(jié)論
　　參考文獻
　第15章 企業(yè)資源規(guī)劃（erp）質(zhì)量
　　15.1 介紹
　　15.2 erp進入高等教育
　　15.3 erp文獻
　　15.3.1 大學(xué)部門
　　15.4 質(zhì)量相關(guān)的文獻
　　15.4.1 質(zhì)量的用戶視角
　　15.5 研究方法
　　15.5.1 框架
　　15.5.2 方法
　　15.6 案例研究
　　15.6.1 需求質(zhì)量
　　15.6.2 接口質(zhì)量
　　15.7 討論
　　15.8 結(jié)論
序曲
參考文獻
關(guān)于作者
術(shù)語表

章節(jié)摘錄

版權(quán)頁：   插圖：   前面的兩種缺陷同時發(fā)生。解決這類型的問題有時需要領(lǐng)域知識。 在某些情況下，當(dāng)我們試圖集成一個RBT時，我們發(fā)現(xiàn)并不是只有葉子節(jié)點會與其他RBT或局部DBT產(chǎn)生交迭。在這些情況下，這種冗余可以在集成時被排除。 雖然從原理上講，構(gòu)造一個算法使得集成步驟“自動化”是可能的，雖然，現(xiàn)在已有支撐工具可以用來識別滿足集成匹配準則的節(jié)點。但是集成問題是我們在實際系統(tǒng)中經(jīng)常碰到的問題，因此如果能有人參與控制整個集成過程效果會更好。我們在大型工業(yè)系統(tǒng)中進行集成的經(jīng)驗是，這種方法能夠及早發(fā)現(xiàn)用傳統(tǒng)形式化審查方法發(fā)現(xiàn)不了的一些問題。我們獲得經(jīng)驗是，需求集成是一種關(guān)鍵的完整性檢查，所以對用于構(gòu)建設(shè)計基礎(chǔ)的需求集進行完整性檢查是明智的。 審查及自動化檢測缺陷 一旦我們擁有一組被表示為集成設(shè)計行為樹的功能需求，我們就有了實施缺陷檢測步驟的有利條件。設(shè)計行為樹證明是一種十分有效的表示法，它能反映出一系列在初始需求描述中常見的、不完全的及不一致的缺陷。微波爐系統(tǒng)案例研究中提到了不完整性及其他缺陷。 DBT可以進行人工書面形式化審查，但由于行為樹擁有形式化語義（Winter，2004），因此我們也可以使用工具（Smith等，2004）進行自動化的形式分析。這些工具的組合為發(fā)現(xiàn)缺陷提供了一個強有力的武器。對簡單的實例來說，如微波爐系統(tǒng)，我們很容易進行書面審查并識別大量的缺陷。對較大的系統(tǒng)，即擁有大量狀態(tài)及復(fù)雜的控制結(jié)構(gòu)的系統(tǒng)，自動化工具對系統(tǒng)的、基于邏輯、可重復(fù)的缺陷發(fā)現(xiàn)十分重要。我們現(xiàn)在認識到很多有條不紊的人工和自動缺陷檢查能夠基于DBT開展。 4.5.3缺失條件和事件 一個常見問題是關(guān)于初始需求描述方面的。初始需求描述了可能應(yīng)用在系統(tǒng)行為中的某一點的一組條件，其中通常會遺漏促使行為完整的情況。這種最簡單的情況是：在需求中的某個位置說明了如果運用某一條件應(yīng)該會發(fā)生什么，但其中并沒有記載如果沒有運用這個條件會發(fā)生什么。在系統(tǒng)行為的某一點中也可能會存在缺失的事件。

編輯推薦

《度量信息系統(tǒng)交付質(zhì)量》可作為從事軍事信息系統(tǒng)建設(shè)的技術(shù)人員及管理人員學(xué)習(xí)的參考書。

圖書封面

評論、評分、閱讀與下載

---

    度量信息系統(tǒng)交付質(zhì)量 PDF格式下載

---