軟件工程案例分析

1、軟件工程案例分析軟件工程案例分析陳天洲浙江大學(xué)計(jì)算機(jī)學(xué)院軟件特征（軟件特征（1）最根本的：軟件是一種邏輯元素而不是物理元素軟件是開發(fā)出的，而不是用傳統(tǒng)的方法制造出來(lái)的軟件不會(huì)被用壞時(shí)間失敗概率一般產(chǎn)品的浴盆曲線軟件特征（軟件特征（2）時(shí)間失敗概率軟件失敗概率實(shí)際曲線軟件失敗概率理想曲線軟件特征（軟件特征（3）工業(yè)界已經(jīng)走向了標(biāo)準(zhǔn)化裝配時(shí)代，然而絕大多數(shù)軟件還是定制出來(lái)的。 科學(xué)計(jì)算函數(shù)庫(kù)（60年代） 重用數(shù)據(jù)結(jié)構(gòu) 重用組件成本結(jié)構(gòu)發(fā)生了巨大的變化成本結(jié)構(gòu)發(fā)生了巨大的變化一次性的制造成本介質(zhì)成本的可忽略性邏輯產(chǎn)品不可回逆的投入維護(hù)成本的增加服務(wù)是質(zhì)量要素中的重點(diǎn)軟件危機(jī)軟件危機(jī)“軟件危機(jī)” 是1

2、958年在NATO會(huì)議上作為一個(gè)正式的議題被提出來(lái) 軟件項(xiàng)目不成功的例子比比即是： 1999 年 10 月，耗資 1.25 億美元的 NASA 的火星氣象衛(wèi)星失蹤（公英制轉(zhuǎn)換）軟件危機(jī)軟件危機(jī)一些數(shù)據(jù)： 大約70的軟件開發(fā)項(xiàng)目超出了估算的時(shí)間，大型項(xiàng)目平均超出計(jì)劃交付時(shí)間20到50，90以上的軟件項(xiàng)目開發(fā)費(fèi)用超出預(yù)算，并且項(xiàng)目越大，超出項(xiàng)目計(jì)劃的程度越高 美國(guó)政府審計(jì)局：只有不到2的合同定購(gòu)軟件在發(fā)布時(shí)具有可用性98以上的項(xiàng)目都失敗了軟件危機(jī)軟件危機(jī)一種看法 “兩難境地（Crunch Mode）”：處于兩難境地的項(xiàng)目面臨無(wú)法達(dá)到最初目標(biāo)的威脅（費(fèi)用、進(jìn)度表、功能性等），而項(xiàng)目團(tuán)隊(duì)努力想跨越困境

3、。 “我們正處于兩難境地，在半夜之前是不會(huì)回家” “死亡行軍（Death March）”：用來(lái)描述其進(jìn)度表幾乎不可能完成的項(xiàng)目。 “這是一個(gè)死亡行軍項(xiàng)目，我希望自己不要參與進(jìn)去”軟件危機(jī)軟件危機(jī)更準(zhǔn)確的說(shuō)法：慢性痛苦（chronic affliction) Suggested by Prof. Daniel Tiechrow, University of Michigan盡管忍受痛苦，但是軟件依然在我們這個(gè)世界起著越來(lái)越重要的作用，但是如果能夠醫(yī)治痛苦，那么軟件業(yè)將發(fā)展得更加健康。軟件危機(jī)的主要特征軟件危機(jī)的主要特征軟件開發(fā)周期大大超過(guò)規(guī)定日期;軟件開發(fā)成本嚴(yán)重超標(biāo);軟件質(zhì)量難于保證軟件成功的

4、標(biāo)準(zhǔn)軟件成功的標(biāo)準(zhǔn)s用戶在用s用戶可很容易做完要做的事失敗的根本原因：開發(fā)人員寫出的東西達(dá)不到用戶要求(人的問(wèn)題.技術(shù)問(wèn)題)規(guī)模復(fù)雜性生產(chǎn)率軟件技術(shù)面臨的問(wèn)題軟件技術(shù)面臨的問(wèn)題Exchange2000Windows20002000項(xiàng)目經(jīng)理項(xiàng)目經(jīng)理25人人約約250人人開發(fā)人員開發(fā)人員140人人約約1700人人測(cè)試人員測(cè)試人員350人人約約3200人人例例:Windows95有有1000萬(wàn)行代碼萬(wàn)行代碼 Windows2000有有5000萬(wàn)行代碼，萬(wàn)行代碼， 3000多個(gè)工程師，幾百個(gè)小團(tuán)隊(duì)。多個(gè)工程師，幾百個(gè)小團(tuán)隊(duì)。Exchange2000和和 Windows2000開發(fā)人員結(jié)構(gòu)開發(fā)人員結(jié)構(gòu)“

5、軟件工程案例分析”課程與其它軟件專業(yè)課的區(qū)別(1) 立足于系統(tǒng)的整體。(2) 系統(tǒng)分析、系統(tǒng)設(shè)計(jì)、 測(cè)試及維護(hù)的方法實(shí)踐。(3) 構(gòu)筑一個(gè)軟件系統(tǒng)，實(shí)踐 軟件開發(fā)全過(guò)程。用戶分析員程序員系統(tǒng)分析員的地位“一個(gè)好的工業(yè)，應(yīng)有一套良好的標(biāo)準(zhǔn)來(lái)配套”軟件工業(yè)化生產(chǎn)過(guò)程應(yīng)具備的特點(diǎn)明確的工作步驟詳細(xì)具體的規(guī)范化文檔明確的質(zhì)量評(píng)價(jià)標(biāo)準(zhǔn)軟件產(chǎn)品的標(biāo)準(zhǔn)化軟件開發(fā)過(guò)程的標(biāo)準(zhǔn)化軟件工程技術(shù)的兩個(gè)明顯特點(diǎn) 強(qiáng)調(diào)規(guī)范化 強(qiáng)調(diào)文檔化新世紀(jì)軟件產(chǎn)業(yè)的趨勢(shì)新世紀(jì)軟件產(chǎn)業(yè)的趨勢(shì)網(wǎng)絡(luò)化趨勢(shì)：計(jì)算機(jī)與通信的融合趨勢(shì) 萬(wàn)維網(wǎng)智能網(wǎng)絡(luò)服務(wù)化趨勢(shì)：“打包式”軟件 “服務(wù)式”軟件全球化趨勢(shì)中國(guó)軟件產(chǎn)業(yè)發(fā)展主要問(wèn)題中國(guó)軟件產(chǎn)業(yè)發(fā)展主要問(wèn)

6、題產(chǎn)業(yè)規(guī)模小、集中度低產(chǎn)業(yè)競(jìng)爭(zhēng)力弱，缺乏核心技術(shù)市場(chǎng)秩序較為混亂，盜版嚴(yán)重制約軟件產(chǎn)業(yè)發(fā)展的因素制約軟件產(chǎn)業(yè)發(fā)展的因素軟件開發(fā)規(guī)范與標(biāo)準(zhǔn)知識(shí)產(chǎn)權(quán)環(huán)境知識(shí)結(jié)構(gòu)公司體制項(xiàng)目與項(xiàng)目管理項(xiàng)目與項(xiàng)目管理項(xiàng)目是什么 沒(méi)有例行的任務(wù) 需要計(jì)劃 特定的目標(biāo)需要滿足或者特定的產(chǎn)品需要生成 項(xiàng)目有一個(gè)預(yù)定義的時(shí)間范圍 工作不僅僅是為自己，也是為他人 工作中有些特性 工作分為若干階段 項(xiàng)目完成需要資源 項(xiàng)目是大型的或者復(fù)雜的項(xiàng)目管理是什么 項(xiàng)目管理是在項(xiàng)目活動(dòng)中應(yīng)用知識(shí)，技能，工具和技術(shù)來(lái)滿足項(xiàng)目需求的過(guò)程，它通過(guò)初始化，計(jì)劃，執(zhí)行，控制和結(jié)束等活動(dòng)來(lái)完成。軟件項(xiàng)目與軟件項(xiàng)目與軟件項(xiàng)目管理軟件項(xiàng)目管理軟件項(xiàng)目的特征

7、 不可見(jiàn) 復(fù)雜性（以每一單位貨幣來(lái)看） 靈活性：軟件去適應(yīng)人或組織而不是相反一致性一致性軟件項(xiàng)目管理 為了使軟件項(xiàng)目能夠按照預(yù)定的成本、進(jìn)度、質(zhì)量順利完成，而對(duì)成本、人員、進(jìn)度、質(zhì)量、風(fēng)險(xiǎn)等進(jìn)行分析和管理的活動(dòng)。軟件項(xiàng)目的活動(dòng)軟件項(xiàng)目的活動(dòng)需求分析描述設(shè)計(jì)編碼校驗(yàn)安裝維護(hù)支持軟件項(xiàng)目分類軟件項(xiàng)目分類按軟件類別 信息系統(tǒng)：與組織接口 嵌入式系統(tǒng)：接口是機(jī)器 操作系統(tǒng)是一個(gè)信息系統(tǒng)還是嵌入式系統(tǒng)？ 有些項(xiàng)目是為了生成某一產(chǎn)品，而某些項(xiàng)目的進(jìn)行是為了達(dá)到某些目標(biāo)。許多軟件項(xiàng)目分為兩個(gè)階段，第一階段是目標(biāo)驅(qū)動(dòng)，第二階段再生成真正的軟件產(chǎn)品。從系統(tǒng)的角度看軟件項(xiàng)目從系統(tǒng)的角度看軟件項(xiàng)目一個(gè)項(xiàng)目關(guān)注于生成

8、一個(gè)系統(tǒng)和/或?qū)⒁粋€(gè)舊系統(tǒng)轉(zhuǎn)換為一個(gè)新系統(tǒng)系統(tǒng)，子系統(tǒng)和環(huán)境開放和封閉系統(tǒng) 項(xiàng)目失敗的一個(gè)原因是技術(shù)人員不能夠開放系統(tǒng)和立即接受外界的變化。部分優(yōu)化 例如：可能很高效，但是難于修改社會(huì)技術(shù)系統(tǒng) 軟件項(xiàng)目屬于此類軟件項(xiàng)目中的人員軟件項(xiàng)目中的人員項(xiàng)目影響者(stakeholders) 項(xiàng)目小組內(nèi)部： 項(xiàng)目小組外部，但是在同一組織內(nèi)： 項(xiàng)目小組和組織外部：如客戶不同的項(xiàng)目影響者有不同的目標(biāo)，因而項(xiàng)目領(lǐng)導(dǎo)者需要能夠協(xié)調(diào)這些目標(biāo)。Boehm和Ross提出軟件項(xiàng)目管理的“W理論”，該理論關(guān)注于所有各方都能從項(xiàng)目種獲益因而對(duì)項(xiàng)目的成功都有興趣。（W代表Everyone a Winner）軟件開發(fā)面臨的挑戰(zhàn)軟

9、件開發(fā)面臨的挑戰(zhàn)處理最終日期（deadlines）(85%)處理資源約束（83）與任務(wù)小組有效的溝通（80）從小組成員處得到承諾（74）建立可測(cè)量的milestone（90）處理變化（60）得到團(tuán)隊(duì)公認(rèn)的項(xiàng)目計(jì)劃（57）從管理層得到承諾（45）處理沖突（42）管理銷售商和子項(xiàng)目承包商（38）項(xiàng)目經(jīng)理面臨的挑戰(zhàn)項(xiàng)目經(jīng)理面臨的挑戰(zhàn)估計(jì)和計(jì)劃缺少質(zhì)量標(biāo)準(zhǔn)和度量缺少組織決策的指南缺少使進(jìn)度可視化的技術(shù)角色定義不正確的成功準(zhǔn)則缺少標(biāo)準(zhǔn)項(xiàng)目成員面臨的挑戰(zhàn)項(xiàng)目成員面臨的挑戰(zhàn)工作的不正確的描述IT的管理失誤缺少應(yīng)用領(lǐng)域的知識(shí)缺少及時(shí)的文檔前續(xù)任務(wù)沒(méi)有及時(shí)完成包括設(shè)備沒(méi)及時(shí)提供用戶與技術(shù)員之間缺乏交流缺少質(zhì)量控

10、制軟件環(huán)境的改變Deadline壓力軟件項(xiàng)目常見(jiàn)錯(cuò)誤軟件項(xiàng)目常見(jiàn)錯(cuò)誤選自快速軟件開發(fā)產(chǎn)品相關(guān)的錯(cuò)誤 需求鍍金：項(xiàng)目具有比實(shí)際需求多得多的性能 功能蔓延：項(xiàng)目平均會(huì)有25%的需求變更（Jones 1994） 開發(fā)人員的鍍金：開發(fā)人員著迷于新技術(shù) 又推又拉的交易：經(jīng)理在批準(zhǔn)項(xiàng)目進(jìn)度順延時(shí)又加入了新的功能 研究導(dǎo)向的開發(fā)軟件項(xiàng)目常見(jiàn)錯(cuò)誤（續(xù)）軟件項(xiàng)目常見(jiàn)錯(cuò)誤（續(xù)）過(guò)程中的錯(cuò)誤 缺乏計(jì)劃 過(guò)于樂(lè)觀的計(jì)劃 在壓力下放棄計(jì)劃 缺乏足夠的風(fēng)險(xiǎn)管理 承包人導(dǎo)致的失敗 在模糊的項(xiàng)目前期浪費(fèi)時(shí)間 前期活動(dòng)不合要求過(guò)程中的錯(cuò)誤 設(shè)計(jì)低劣 缺少質(zhì)量保證措施 缺少管理控制 太早和過(guò)于頻繁的集成 項(xiàng)目估算時(shí)遺漏必要的任務(wù)

11、 追趕計(jì)劃 魯莽編碼軟件項(xiàng)目常見(jiàn)錯(cuò)誤（續(xù)）軟件項(xiàng)目常見(jiàn)錯(cuò)誤（續(xù)）技術(shù)相關(guān)的錯(cuò)誤 銀彈綜合癥: 過(guò)于相信以前沒(méi)有采用過(guò)的技術(shù)的宣傳 過(guò)高估計(jì)了新技術(shù)或方法帶來(lái)的節(jié)省量 項(xiàng)目中間切換工具 缺少自動(dòng)的源代碼控制手段 軟件項(xiàng)目常見(jiàn)錯(cuò)誤（續(xù)）軟件項(xiàng)目常見(jiàn)錯(cuò)誤（續(xù)）人員相關(guān)的錯(cuò)誤 挫傷積極性 人員素質(zhì)低 對(duì)有問(wèn)題的員工失控 英雄主義 項(xiàng)目后期加入人員：“火上加油” 辦公環(huán)境差 開發(fā)人員與客戶之間發(fā)生摩擦 不現(xiàn)實(shí)的預(yù)期軟件項(xiàng)目常見(jiàn)錯(cuò)誤（續(xù)）軟件項(xiàng)目常見(jiàn)錯(cuò)誤（續(xù)） 缺乏有效的高層對(duì)項(xiàng)目的支持 缺乏各種角色的齊心協(xié)力 缺乏用戶介入 政治高于物質(zhì) 充滿想像：“項(xiàng)目組沒(méi)人真正相信他們能夠按給定的計(jì)劃進(jìn)度完成項(xiàng)目，但

12、他們認(rèn)為如果每個(gè)人能夠努力工作，并且不出現(xiàn)問(wèn)題，他們可能會(huì)很幸運(yùn)地按時(shí)完成任務(wù)。軟件項(xiàng)目常見(jiàn)的錯(cuò)誤軟件項(xiàng)目常見(jiàn)的錯(cuò)誤試分析以下故事中的項(xiàng)目所存在的錯(cuò)誤： 一天，一位年青人被選來(lái)“寫”一個(gè)用在自動(dòng)化制造設(shè)備上的程序。選擇他的理由很簡(jiǎn)單：他是技術(shù)小組中唯一參加過(guò)編程培訓(xùn)的人。他懂得匯編語(yǔ)言和Fortran語(yǔ)言，但是他不知道軟件工程，更不知道軟件計(jì)劃和跟蹤方面的知識(shí)。軟件開發(fā)過(guò)程模型選擇軟件開發(fā)過(guò)程模型選擇主要內(nèi)容主要內(nèi)容項(xiàng)目實(shí)施的方法選擇問(wèn)題識(shí)別項(xiàng)目中的高風(fēng)險(xiǎn)軟件開發(fā)過(guò)程模型的選擇 可選擇的模型 軟件開發(fā)項(xiàng)目過(guò)程的選擇軟件開發(fā)方法項(xiàng)目實(shí)施的方法選擇項(xiàng)目實(shí)施的方法選擇技術(shù)選擇 技術(shù)選擇將影響： 開發(fā)

13、人員的訓(xùn)練需要 人員招聘 開發(fā)環(huán)境硬件和軟件 系統(tǒng)維護(hù)安排方法選擇 方法選擇將影響： 開發(fā)人員組合 實(shí)施的進(jìn)度安排 開發(fā)策略選擇項(xiàng)目實(shí)施的方法選擇項(xiàng)目實(shí)施的方法選擇p步驟： 分析目標(biāo)驅(qū)動(dòng)還是產(chǎn)品驅(qū)動(dòng) 分析項(xiàng)目其他特征 面向數(shù)據(jù)還是面向控制 通用還是專用 是否需要專用工具支持的專門技術(shù) 是否有特殊的安全性要求 對(duì)軟硬件有何要求識(shí)別項(xiàng)目中的高風(fēng)險(xiǎn)識(shí)別項(xiàng)目中的高風(fēng)險(xiǎn)產(chǎn)品不確定性：系統(tǒng)需求理解的準(zhǔn)確性。用戶在開始時(shí)有可能對(duì)系統(tǒng)應(yīng)該什么樣都無(wú)法確定。在某些環(huán)境中，精確而有效的需求描述可能迅速變得過(guò)時(shí)。過(guò)程不確定性：在項(xiàng)目開始時(shí)需要選擇方法或過(guò)程模型，或者一種新的工具，任何對(duì)原先采用的開發(fā)方法的變化都將引

14、入不確定性資源不確定性：項(xiàng)目進(jìn)行中資源的數(shù)量可能發(fā)生變化軟件開發(fā)過(guò)程模型的選擇軟件開發(fā)過(guò)程模型的選擇開發(fā)一個(gè)軟件需要選擇開發(fā)策略（包括過(guò)程，方法和工具）以及通用階段，這些策略和階段被稱為過(guò)程模型“過(guò)程”：相關(guān)聯(lián)的活動(dòng)過(guò)程模型的選擇基于項(xiàng)目和應(yīng)用的特性，使用的工具和方法，所需要的控制方法和交付物。軟件生存周期 (Software Life Cycle) 軟件產(chǎn)品或軟件系統(tǒng)從設(shè)計(jì)、投入使用到被淘汰的全過(guò)程軟件生存期的階段劃分可行性研究與計(jì)劃需求分析總體設(shè)計(jì)詳細(xì)設(shè)計(jì)實(shí)現(xiàn)集成測(cè)試確認(rèn)測(cè)試使用和維護(hù)軟件生存周期軟件生存周期計(jì)算機(jī)軟件開發(fā)規(guī)范上游下游新的國(guó)際標(biāo)準(zhǔn)定義的軟件生存過(guò)程（1995 ISO/IEC

15、 12207）軟件生存期過(guò)程支持過(guò)程組織過(guò)程主要過(guò)程獲取過(guò)程供應(yīng)過(guò)程開發(fā)過(guò)程運(yùn)行過(guò)程維護(hù)過(guò)程文檔編制過(guò)程配置管理過(guò)程質(zhì)量保證過(guò)程驗(yàn)證過(guò)程確認(rèn)過(guò)程聯(lián)合評(píng)審過(guò)程審核過(guò)程問(wèn)題解決過(guò)程管理過(guò)程基礎(chǔ)設(shè)施過(guò)程改進(jìn)過(guò)程培訓(xùn)過(guò)程只考慮編寫程序 涉及整個(gè)軟件生存周期擴(kuò)展到軟件工作的范圍軟件開發(fā)全部過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架。直觀表達(dá)軟件開發(fā)全過(guò)程明確規(guī)定要完成的主要活動(dòng)、任務(wù)和開發(fā)策略也稱為：軟件過(guò)程模型軟件生存周期模型軟件工程范型軟件開發(fā)模型軟件開發(fā)模型問(wèn)題求解的一般過(guò)程問(wèn)題求解的一般過(guò)程問(wèn)題求解的一般過(guò)程 實(shí)際問(wèn)題并不能簡(jiǎn)單劃為四個(gè)階段，各個(gè)階段會(huì)在問(wèn)題的不同層次上同時(shí)并存 軟件開發(fā)實(shí)際上是一個(gè)“混沌”（c

16、haos）過(guò)程問(wèn)題定義方案集成技術(shù)開發(fā)現(xiàn)狀A(yù).編碼修正模型編碼修正模型Code and Fix Code like Hell(魯莽編碼)從一個(gè)大致的想法開始工作，然后經(jīng)過(guò)非正規(guī)的設(shè)計(jì)、編碼、調(diào)試和測(cè)試方法，最后完成工作可能有可能沒(méi)有的規(guī)范發(fā)布（可能）編碼修正模型編碼修正模型好處： 成本可能很低 只需要很少的專業(yè)知識(shí)，任何寫過(guò)程序的人都可以 對(duì)于一些非常小的、開發(fā)完后就會(huì)很快丟棄的軟件可以采用對(duì)于規(guī)模稍大的項(xiàng)目，采用這種模型是很危險(xiǎn)的B.瀑布模型（瀑布模型（Waterfall Model)所有過(guò)程模型的祖宗項(xiàng)目從開始到結(jié)束按照一定的順序執(zhí)行瀑布模型是文檔驅(qū)動(dòng)的，各個(gè)階段不連續(xù)也不交叉B.瀑布模型

17、 (Waterfall Model)可行性研究與計(jì)劃需求分析設(shè)計(jì)編碼運(yùn)行維護(hù)測(cè)試定義階段開發(fā)階段維護(hù)階段適應(yīng)場(chǎng)合？適應(yīng)場(chǎng)合？?jī)?yōu)缺點(diǎn)？?jī)?yōu)缺點(diǎn)？瀑布模型的適用場(chǎng)合瀑布模型的適用場(chǎng)合有一個(gè)穩(wěn)定產(chǎn)品定義穩(wěn)定產(chǎn)品定義和很容易被理解的技術(shù)解決容易被理解的技術(shù)解決方案方案時(shí)，純瀑布模型特別合適對(duì)一個(gè)定義得很好的版本進(jìn)行維護(hù)維護(hù)或?qū)⒁粋€(gè)產(chǎn)品移植平臺(tái)移植平臺(tái)，瀑布模型也特別合適。純瀑布模型能夠降低管理費(fèi)用降低管理費(fèi)用，因?yàn)槟憧梢灶A(yù)先完成所有計(jì)劃。對(duì)于那些容易理解但很復(fù)雜的項(xiàng)目，采用純瀑布模型比較合適，因?yàn)榭梢杂庙樞蚍椒ㄌ幚韱?wèn)題用順序方法處理問(wèn)題。在質(zhì)量需求高質(zhì)量需求高于成本需求和進(jìn)度需求的時(shí)候，它尤為出色。當(dāng)開

18、發(fā)隊(duì)伍的技術(shù)力量比較弱技術(shù)力量比較弱或者缺乏經(jīng)驗(yàn)時(shí)，瀑布模型更為適合。瀑布模型缺點(diǎn)瀑布模型缺點(diǎn)純瀑布模型在項(xiàng)目開始時(shí)，在設(shè)計(jì)工作完成前和代碼寫出來(lái)前，很難充分描述需求。瀑布模型最主要問(wèn)題是缺乏靈活性缺乏靈活性。必須在項(xiàng)目開始前說(shuō)明全部需求。但這恰恰是非常困難的。按照傳統(tǒng)瀑布模型開發(fā)軟件的特點(diǎn)階段間具有順序性和依賴性。推遲實(shí)現(xiàn)的觀點(diǎn)。每個(gè)階段必須完成規(guī)定的文檔;每個(gè)階段結(jié)束前完成文檔審查,及早改正錯(cuò)誤。C.瀑布模型變種：瀑布模型變種：V型模型型模型該方法是對(duì)瀑布模型的修正，強(qiáng)調(diào)了驗(yàn)證活動(dòng)可行性研究用戶需求系統(tǒng)設(shè)計(jì)程序設(shè)計(jì)編 碼程序測(cè)試系統(tǒng)測(cè)試用戶接受評(píng)價(jià)修正修正修正修正D. 瀑布模型變種：生魚片

19、模型瀑布模型變種：生魚片模型把階段重疊起來(lái)的瀑布模型起源于日本硬件開發(fā)模型（富士通施樂(lè)）軟件概念需求分析架構(gòu)設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼和調(diào)試系統(tǒng)測(cè)試生魚片模型的特點(diǎn)和缺點(diǎn)生魚片模型的特點(diǎn)和缺點(diǎn)傳統(tǒng)的瀑布模型強(qiáng)調(diào)階段之間最小重疊重疊，而生魚片模型強(qiáng)調(diào)大幅度重疊，即在需求分析完成之前就可以進(jìn)行架構(gòu)設(shè)計(jì)和部分詳細(xì)設(shè)計(jì)純瀑布模型強(qiáng)調(diào)在任意兩個(gè)階段交接時(shí)，文檔從一個(gè)團(tuán)隊(duì)交給另一個(gè)完全隔離的團(tuán)隊(duì)，但是如果一個(gè)團(tuán)隊(duì)完成各個(gè)階段任務(wù)時(shí)，可以沒(méi)有那么多文檔文檔。問(wèn)題：缺點(diǎn)是什么？生魚片模型因?yàn)殡A段重疊，因而里程碑不明確里程碑不明確，很難有效地進(jìn)行過(guò)程跟蹤和控制。E. 瀑布模型變種：具有子項(xiàng)目的瀑布瀑布模型變種：具有子項(xiàng)目

20、的瀑布模型模型純瀑布模型的問(wèn)題：必須完成全部架構(gòu)設(shè)計(jì)后才能進(jìn)行詳細(xì)設(shè)計(jì)，但是，整個(gè)系統(tǒng)中有些部分可能有些特殊性，可以有自己的步驟，即將這些部分劃分為子項(xiàng)目。問(wèn)題：該模型有何問(wèn)題？這種方法的主要風(fēng)險(xiǎn)是相關(guān)性相關(guān)性無(wú)法預(yù)料。F. 瀑布模型變種：能夠降低風(fēng)險(xiǎn)的瀑布瀑布模型變種：能夠降低風(fēng)險(xiǎn)的瀑布模型模型純瀑布模型：要求在開始架構(gòu)設(shè)計(jì)前，必須將用戶的所有需求都搞清楚，但是實(shí)際中是很困難的?？山档惋L(fēng)險(xiǎn)的瀑布模型是在頂端，即需求分析和架構(gòu)設(shè)計(jì)階段引入螺旋以便降低風(fēng)險(xiǎn)。螺旋中，先開發(fā)一個(gè)用戶界面原型，采用系統(tǒng)情節(jié)串聯(lián)圖版（system storyboarding）引導(dǎo)用戶提出需求，記錄用戶與系統(tǒng)的交互操作方

21、式，或者采用其它需求獲取方法。G.快速原型模型（Rapid Prototype Model）建造/修改 原型用戶測(cè)試運(yùn)行原型 聽取用 戶意見(jiàn)原型范型原型模型原型模型需求分析原型開發(fā)最終系統(tǒng)設(shè)計(jì)原型評(píng)價(jià)最終系統(tǒng)實(shí)現(xiàn)用戶反饋分析定義系統(tǒng)需求生成原型系統(tǒng)設(shè)計(jì)程序設(shè)計(jì)編碼測(cè)試運(yùn) 行和維護(hù)原型化含原型化的軟件生存期采用原型模型的軟件生存周期原型法的分類原型法的分類原型是項(xiàng)目系統(tǒng)中的一個(gè)方面或者多個(gè)方面的工作模型。 拋棄型原型：用于試驗(yàn)?zāi)承└拍睿囼?yàn)完系統(tǒng)將無(wú)用處 進(jìn)化型原型：原型系統(tǒng)不斷被開發(fā)和被修正，最終它變?yōu)橐粋€(gè)真正的系統(tǒng)。原型法的優(yōu)點(diǎn)原型法的優(yōu)點(diǎn)從實(shí)踐中學(xué)習(xí)(Learning by doing)改

22、善的溝通改善的用戶參與使部分已知的需求清晰化展示描述的一致性和完整性可能可以減少文檔減少了維護(hù)成本特征約束（利用工具構(gòu)造原型可以將某些特性落到實(shí)處，而非在紙上寫的那樣容易失誤）試驗(yàn)是否能產(chǎn)生期待的結(jié)果原型法的缺點(diǎn)原型法的缺點(diǎn)用戶有時(shí)誤解了原型的角色，例如他們可能誤解原形應(yīng)該和真實(shí)系統(tǒng)一樣可靠缺少項(xiàng)目標(biāo)準(zhǔn)，進(jìn)化原型法有點(diǎn)像編碼修正缺少控制，由于用戶可能不斷提出新要求，因而原型迭代的周期很難控制額外的花費(fèi)：研究結(jié)果表明構(gòu)造一個(gè)原型可能需要10%額外花費(fèi)運(yùn)行效率可能會(huì)受影響原型法要求開發(fā)者與用戶密切接觸，有時(shí)這是不可能的。例如外包軟件。從另外的角度看待原型從另外的角度看待原型從中學(xué)到什么？ 學(xué)生經(jīng)常

23、會(huì)做一些軟件作業(yè)，這些作業(yè)被稱為原型， 問(wèn)題：這些原型和軟件系統(tǒng)原型是否相同？ 但是作為一個(gè)原型必須：描述他們希望從中學(xué)到的東西，規(guī)劃原型評(píng)價(jià)的方法，報(bào)告從原型中真正學(xué)到的內(nèi)容。 在不同的階段，原型具有不同的作用。原型起作用的程度 實(shí)物模型（Mock-ups） 仿真交互 部分模型：水平，垂直（某些特性構(gòu)造詳細(xì)原型）H.演化模型增量模型(Incremental Model)螺旋模型(Sprial Model)H.1 增量模型(遞增模型)先完成一個(gè)系統(tǒng)子集的開發(fā)，再按同樣的開發(fā)步驟增加功能 (系統(tǒng)子集),如此遞增下去直至滿足全部系統(tǒng)需求。系統(tǒng)的總體設(shè)計(jì)在初始子集設(shè)計(jì)階段就應(yīng)作出設(shè)想。分析 設(shè)計(jì) 編

24、碼測(cè)試 分析 設(shè)計(jì) 編碼測(cè)試 分析 設(shè)計(jì) 編碼測(cè)試 分析 設(shè)計(jì) 編碼測(cè)試 增量1增量2增量3增量n 增量1交付客戶 增量2交付客戶 增量3交付客戶 增量n交付客戶日歷時(shí)間.H.1 增量模型風(fēng)險(xiǎn)分析工程實(shí)施用戶通信用戶評(píng)估產(chǎn)品維護(hù)項(xiàng)目產(chǎn)品增強(qiáng)項(xiàng)目新產(chǎn)品開發(fā)項(xiàng)目概念開發(fā)項(xiàng)目計(jì)劃建造及發(fā)布H.2 螺旋模型螺旋模型的優(yōu)缺點(diǎn)優(yōu)勢(shì)：隨著迭代的增加（成本的增加），風(fēng)險(xiǎn)程度隨之降低缺陷：比較復(fù)雜，需要責(zé)任心，專注和管理方面的知識(shí)。H.3 WIN-WIN螺旋模型在螺旋模型中，通過(guò)與客戶的通信獲取客戶的需求，實(shí)際上，客戶的需求與最終確定的需求是不一致的，客戶與開發(fā)者之間需要進(jìn)行協(xié)商，最終達(dá)到雙贏的局面。Boehm

25、提出的WIN-WIN螺旋模型中，客戶與開發(fā)者之間需要 識(shí)別系統(tǒng)或子系統(tǒng)的關(guān)鍵stakeholders 確定涉及者的“win conditions” 對(duì)這些條件進(jìn)行協(xié)商獲得互贏條件WIN-WIN螺旋模型螺旋模型WIN-WIN螺旋模型還引入了三個(gè)過(guò)程的里程碑，被稱為定位點(diǎn)（Anchor points） 生命周期目標(biāo)（life cycle objectives）:定義每個(gè)主要活動(dòng)的目標(biāo) 生命周期體系結(jié)構(gòu)（life cycle architecture）:定義系統(tǒng)和軟件的體系結(jié)構(gòu)目標(biāo) 初步操作能力（initial operational capability）:定義軟件安裝，發(fā)布目標(biāo)。I. 并行開發(fā)模

26、型并行開發(fā)模型（concurrent development model）又被稱為并行工程（concurrent engineering）（By Davis and Sitaram）軟件開發(fā)中的所有活動(dòng)可能同時(shí)并存同時(shí)并存，但是都處于不同狀態(tài)中并行開發(fā)模型定義了活動(dòng)從一個(gè)狀態(tài)轉(zhuǎn)化為另一個(gè)狀態(tài)的事件并行開發(fā)模型并行開發(fā)模型NoneAwaiting changesUnder revisionUnder reviewBaselinedDoneUnder developmentAnalysis activity并行開發(fā)模型并行開發(fā)模型并行過(guò)程模型經(jīng)常被用于開發(fā)C/S系統(tǒng)。該系統(tǒng)的活動(dòng)可以被分為系統(tǒng)維和

27、部件維。 系統(tǒng)維:包含設(shè)計(jì)，裝配和使用三個(gè)活動(dòng) 部件維:包含設(shè)計(jì)和實(shí)現(xiàn)兩個(gè)活動(dòng) 并發(fā)性表現(xiàn)在兩個(gè)方面： 系統(tǒng)和部件的活動(dòng)同時(shí)發(fā)生 各個(gè)部件可以并行設(shè)計(jì)和開發(fā)“基于版本發(fā)布”的特點(diǎn)V1.01.0功功能能時(shí)間時(shí)間V2.02.0V1.11.1Trade-off Decision (折中決定) 可可 靠靠 性性 發(fā)布日期發(fā)布日期 功功 能能 最優(yōu)最優(yōu) 約束范圍約束范圍可接受可接受正確的正確的Trade-off 決定決定J. 面向?qū)ο竽Ｐ蛧娙Ｐ?Fountain Model)可重用部件組裝模型 (構(gòu)件集成模型 Component Integration Model)分析分析設(shè)計(jì)設(shè)計(jì)實(shí)現(xiàn)實(shí)現(xiàn)測(cè)試測(cè)試集成

28、集成演化演化J.1 噴泉模型噴泉模型特點(diǎn) 主要用于支持面向?qū)ο箝_發(fā)過(guò)程體現(xiàn)了軟件創(chuàng)建所固有的迭代和無(wú)間隙的特征J.2 可重用部件組裝模型(構(gòu)件集成模型)使用重用技術(shù)的軟件工程模型構(gòu)件(components)：可重用的軟件成份可復(fù)用性（Reusability）集成化軟件開發(fā)環(huán)境（ISEE）用戶通信計(jì)劃產(chǎn)品開發(fā)及發(fā)布用戶評(píng)估風(fēng)險(xiǎn)分析標(biāo)志候選構(gòu)件查找構(gòu)件若存在則提取構(gòu)件若不存在則構(gòu)造構(gòu)件進(jìn)行下一次迭代將新構(gòu)件存入庫(kù)中可重用部件組裝模型基于構(gòu)件的軟件工程(CBSE)過(guò)程模型 構(gòu) 件 開 發(fā)分析 設(shè)計(jì) 編程 測(cè)試領(lǐng)域分析系統(tǒng)測(cè)試構(gòu)件提交領(lǐng)域?qū)＜医?jīng)驗(yàn)現(xiàn)有系統(tǒng)資料領(lǐng)域構(gòu)件需求構(gòu)件/構(gòu)架庫(kù)領(lǐng)域構(gòu)架領(lǐng)域構(gòu)件系統(tǒng)

29、開發(fā)系統(tǒng)專用構(gòu)件應(yīng)用系統(tǒng)構(gòu)件生產(chǎn)線領(lǐng)域構(gòu)架領(lǐng)域構(gòu)件問(wèn)題域用戶需求系統(tǒng)生產(chǎn)線 系 統(tǒng) 組 裝 分析 設(shè)計(jì) 編程構(gòu)架細(xì)化專 用 構(gòu) 件 開 發(fā)分析 設(shè)計(jì) 編程 測(cè)試 軟件生產(chǎn)線應(yīng)用構(gòu)件提取車間構(gòu)件生產(chǎn)車間標(biāo)準(zhǔn)規(guī)范 與 質(zhì)量保證1基礎(chǔ)構(gòu)件，2功能構(gòu)件 3接口構(gòu)件，4用戶界面構(gòu)件 應(yīng)用構(gòu)件庫(kù) 構(gòu)件庫(kù)組裝車間領(lǐng)域 1領(lǐng)域 2應(yīng)用系統(tǒng) . .1 12 23 34 4 轉(zhuǎn)換模型(Transformational Model) 凈室模型(Cleanroom Model)K.形式化方法模型K.1 轉(zhuǎn)換模型形式化規(guī)格說(shuō)明與需求比較后修正形式化開發(fā)記錄變換n變換2變換1測(cè)試系統(tǒng)需求目標(biāo)系統(tǒng)形式化規(guī)格語(yǔ)言及其變換技術(shù)

30、基于模型的規(guī)格說(shuō)明及其變換技術(shù)基于代數(shù)結(jié)構(gòu)及其變換技術(shù)基于時(shí)序邏輯的規(guī)格說(shuō)明和驗(yàn)證技術(shù)基于可視形式化技術(shù)K.2 凈室模型(形式化的增量開發(fā)模型)基于思想： 力求在分析和設(shè)計(jì)階段就消除錯(cuò)誤，確保正確，然后在無(wú)缺陷或“潔凈”的狀態(tài)下實(shí)現(xiàn)軟件的制作。三個(gè)關(guān)鍵技術(shù) 置于統(tǒng)計(jì)過(guò)程控制之下的增量開發(fā) 基于函數(shù)的規(guī)范、設(shè)計(jì)、驗(yàn)證 統(tǒng)計(jì)測(cè)試和軟件認(rèn)證 凈室模型盒結(jié)構(gòu)盒結(jié)構(gòu)規(guī)約規(guī)約需求需求收集收集形式化形式化設(shè)計(jì)設(shè)計(jì)正確性正確性驗(yàn)證驗(yàn)證代碼代碼檢查檢查測(cè)試計(jì)劃測(cè)試計(jì)劃統(tǒng)計(jì)性統(tǒng)計(jì)性使用測(cè)使用測(cè)試試驗(yàn)證驗(yàn)證增量 #1盒結(jié)構(gòu)盒結(jié)構(gòu)規(guī)約規(guī)約需求需求收集收集形式化形式化設(shè)計(jì)設(shè)計(jì)正確性正確性驗(yàn)證驗(yàn)證代碼代碼檢查檢查測(cè)試計(jì)劃

31、測(cè)試計(jì)劃統(tǒng)計(jì)性統(tǒng)計(jì)性使用測(cè)使用測(cè)試試驗(yàn)證驗(yàn)證增量 #2盒結(jié)構(gòu)盒結(jié)構(gòu)規(guī)約規(guī)約需求需求收集收集形式化形式化設(shè)計(jì)設(shè)計(jì)正確性正確性驗(yàn)證驗(yàn)證代碼代碼檢查檢查測(cè)試計(jì)劃測(cè)試計(jì)劃統(tǒng)計(jì)性統(tǒng)計(jì)性使用測(cè)使用測(cè)試試驗(yàn)證驗(yàn)證增量 #1. . . . . . . . . . . . .L. 階段交付階段交付階段交付持續(xù)地在確定的階段向用戶展示軟件。和漸進(jìn)原型不同，在階段交付的時(shí)候，你明確地知道下一步要完成什么工作。階段交付的特點(diǎn)是不會(huì)在項(xiàng)目結(jié)束的時(shí)候一下交付全部軟件，而是在項(xiàng)目整個(gè)開發(fā)過(guò)程中持續(xù)不斷地交付階段性成果。階段交付階段交付軟件概念需求分析構(gòu)架設(shè)計(jì)階段1：詳細(xì)設(shè)計(jì)，編碼，調(diào)試，階段2：詳細(xì)設(shè)計(jì)，編碼，調(diào)試，階段交

32、付的優(yōu)缺點(diǎn)階段交付的優(yōu)缺點(diǎn)優(yōu)點(diǎn)：項(xiàng)目結(jié)束交付全部成果前，分階段將有用的功能交付給用戶。缺點(diǎn)：如果管理層面和技術(shù)層面上缺乏仔細(xì)規(guī)劃，工作就無(wú)法進(jìn)行。使用階段交付的注意點(diǎn)： 必須確定每一階段的交付是對(duì)用戶有用的 必須確?？紤]了不同產(chǎn)品組成部分的技術(shù)依賴關(guān)系M. 面向進(jìn)度的設(shè)計(jì)面向進(jìn)度的設(shè)計(jì)類似于階段交付，但是面向進(jìn)度的設(shè)計(jì)生命周期模型在開始的時(shí)候不必知道究竟能達(dá)到何目標(biāo)，但是要確保最后的期限期限。該模型的關(guān)鍵是要按優(yōu)先級(jí)別劃分系統(tǒng)特按優(yōu)先級(jí)別劃分系統(tǒng)特性并規(guī)劃開發(fā)階段性并規(guī)劃開發(fā)階段，保證前面的階段具有高優(yōu)先級(jí)的特性，低特性具有低優(yōu)先級(jí)別。是否采用這種方法決定于你是否對(duì)系統(tǒng)目標(biāo)具有足夠的信心，如果

33、有信心，則沒(méi)必要采用這種方法。N.漸進(jìn)交付漸進(jìn)交付漸進(jìn)交付是一種跨越了漸進(jìn)原型和階段交付兩種模型的過(guò)程模型?；具^(guò)程：開發(fā)一個(gè)產(chǎn)品的版本，展示給用戶，根據(jù)反饋改善產(chǎn)品。如果計(jì)劃滿足用戶的絕大部分需求，漸進(jìn)交付與漸進(jìn)原型差不多，如果計(jì)劃滿足少量的需求，漸進(jìn)交付就和階段交付差不多。漸進(jìn)原型，強(qiáng)調(diào)的是系統(tǒng)看得見(jiàn)的樣子，再回來(lái)堵漏洞，漸進(jìn)交付中，最初的重點(diǎn)是系統(tǒng)核心和底層系統(tǒng)功能。漸進(jìn)交付漸進(jìn)交付軟件概念需求分析構(gòu)架和內(nèi)核設(shè)計(jì)開發(fā)一個(gè)版本并入用戶反饋交付該版本開發(fā)一個(gè)版本交付最終版本確定漸進(jìn)交付目標(biāo)的一種方法確定漸進(jìn)交付目標(biāo)的一種方法價(jià)值成本比軟件開發(fā)方法 軟件開發(fā)過(guò)程遵循的方法和步驟 幾種典型的開發(fā)

34、方法： 模塊化方法（modular method） 結(jié)構(gòu)化方法 面向數(shù)據(jù)結(jié)構(gòu)方法 面向?qū)ο蠓椒ㄜ浖_發(fā)需要項(xiàng)目管理軟件開發(fā)需要項(xiàng)目管理軟件開發(fā)是個(gè)系統(tǒng)工程需要資源的協(xié)調(diào)軟件開發(fā)過(guò)程的選擇與項(xiàng)目的協(xié)調(diào)緊密相關(guān)項(xiàng)目管理、工具、技術(shù)、流程項(xiàng)目管理、工具、技術(shù)、流程與組織與組織主要內(nèi)容主要內(nèi)容回顧 軟件項(xiàng)目實(shí)施的方法選擇 軟件開發(fā)過(guò)程模型的選擇 軟件開發(fā)方法項(xiàng)目管理 項(xiàng)目管理基本概念 實(shí)施項(xiàng)目管理的工具與技術(shù) 項(xiàng)目管理的流程 項(xiàng)目管理的流程特征（產(chǎn)品項(xiàng)目軟件項(xiàng)目） 項(xiàng)目管理組織結(jié)構(gòu) 軟件項(xiàng)目管理的流程為什么項(xiàng)目會(huì)失敗為什么項(xiàng)目會(huì)失敗?People 項(xiàng)目成功的最重要因素Product 建立的軟件Proc

35、ess 框架活動(dòng)集合和得到工作的軟件工程任務(wù)Project 實(shí)現(xiàn)產(chǎn)品所需要的所有工作The 4 Ps軟件梯隊(duì)軟件梯隊(duì)被解決問(wèn)題的難易程度代碼和功能點(diǎn)形成的結(jié)果程序的規(guī)模梯隊(duì)的生存周期問(wèn)題被模塊化的程度被建立系統(tǒng)所需要的質(zhì)量和可靠性發(fā)布日期的嚴(yán)格性項(xiàng)目的社會(huì)化程度（溝通程度）選擇軟件項(xiàng)目梯隊(duì)結(jié)構(gòu)所要考慮的因素選擇軟件項(xiàng)目梯隊(duì)結(jié)構(gòu)所要考慮的因素 .建立范圍陳述性描述，約束問(wèn)題表達(dá)分解建立功能性分割問(wèn)題定義問(wèn)題定義發(fā)現(xiàn)項(xiàng)目的關(guān)鍵發(fā)現(xiàn)項(xiàng)目的關(guān)鍵系統(tǒng)為什么被開發(fā)?做什么? 什么時(shí)候?誰(shuí)對(duì)某一功能負(fù)責(zé)?他們組織定位在哪里?從技術(shù)和管理上工作怎樣被做?多少資源需要 (e.g., 人, 軟件, 工具, 數(shù)據(jù)庫(kù)

36、)?Barry Boehm形式的風(fēng)險(xiǎn)分析經(jīng)驗(yàn)成本和進(jìn)度估算基于度量的項(xiàng)目管理價(jià)值跟蹤（Earned value tracking）質(zhì)量目標(biāo)下的跟蹤人要意識(shí)到項(xiàng)目管理關(guān)鍵實(shí)踐關(guān)鍵實(shí)踐什么是項(xiàng)目什么是項(xiàng)目項(xiàng)目是什么 沒(méi)有例行的任務(wù) 需要計(jì)劃 特定的目標(biāo)需要滿足或者特定的產(chǎn)品需要生成 項(xiàng)目有一個(gè)預(yù)定義的時(shí)間范圍 工作不僅僅是為自己，也是為他人 工作中有些特性 工作分為若干階段 項(xiàng)目完成需要資源 項(xiàng)目是大型的或者復(fù)雜的什么是項(xiàng)目管理什么是項(xiàng)目管理項(xiàng)目管理是在項(xiàng)目活動(dòng)中應(yīng)用知識(shí)，技能，工具和技術(shù)來(lái)滿足項(xiàng)目需求的過(guò)程，它通過(guò)初始化，計(jì)劃，執(zhí)行，控制和結(jié)束等活動(dòng)來(lái)完成。 項(xiàng)目生命周期項(xiàng)目生命周期項(xiàng)目生命周期

37、定義一個(gè)項(xiàng)目的開始與結(jié)束。項(xiàng)目生命周期定義的階段順序通常包括某些技術(shù)轉(zhuǎn)移或“握手”(hand off)，如從需求到設(shè)計(jì)，從構(gòu)造到運(yùn)行，但是在風(fēng)險(xiǎn)允許下，也可以下一階段提前進(jìn)行，這種重疊的階段被稱為快速跟蹤(fast tracking)。項(xiàng)目生命周期通常定義： 各個(gè)階段需要完成的技術(shù)工作； 每個(gè)階段需要涉及的人。項(xiàng)目生命周期項(xiàng)目生命周期絕大多數(shù)項(xiàng)目生命周期有一些共同的特點(diǎn)，如成本和人員消耗的變化曲線。項(xiàng)目生命周期與產(chǎn)品生命周期是不同的。項(xiàng)目中的人員項(xiàng)目中的人員項(xiàng)目影響者(stakeholders) 項(xiàng)目小組內(nèi)部： 項(xiàng)目小組外部，但是在同一組織內(nèi)： 項(xiàng)目小組和組織外部：如客戶不同的項(xiàng)目影響者有不同

38、的目標(biāo)，因而項(xiàng)目領(lǐng)導(dǎo)者需要能夠協(xié)調(diào)這些目標(biāo)。Boehm和Ross提出軟件項(xiàng)目管理的“W理論”，該理論關(guān)注于所有各方都能從項(xiàng)目種獲益因而對(duì)項(xiàng)目的成功都有興趣。（W代表Everyone a Winner）軟件項(xiàng)目管理定義軟件項(xiàng)目管理定義軟件項(xiàng)目管理是為了使軟件項(xiàng)目能夠按照預(yù)定的成本、進(jìn)度、質(zhì)量順利完成，而對(duì)成本、人員、進(jìn)度、質(zhì)量、風(fēng)險(xiǎn)等進(jìn)行分析和管理的活動(dòng)。軟件項(xiàng)目包含的活動(dòng)軟件項(xiàng)目包含的活動(dòng)需求分析描述設(shè)計(jì)編碼校驗(yàn)安裝維護(hù)支持應(yīng)用項(xiàng)目管理方法開展軟件開發(fā)應(yīng)用項(xiàng)目管理方法開展軟件開發(fā)項(xiàng)目的可行性分析需求開發(fā)與需求管理軟件項(xiàng)目工作量估算軟件項(xiàng)目計(jì)劃與資源分配軟件項(xiàng)目監(jiān)控風(fēng)險(xiǎn)管理軟件質(zhì)量管理與軟件開發(fā)

39、規(guī)范軟件項(xiàng)目中的人員管理軟件配置管理項(xiàng)目可行性分析與評(píng)估項(xiàng)目可行性分析與評(píng)估內(nèi)容安排內(nèi)容安排可行性分析的內(nèi)容項(xiàng)目范圍管理技術(shù)評(píng)估經(jīng)濟(jì)評(píng)估風(fēng)險(xiǎn)評(píng)估可行性報(bào)告項(xiàng)目建議書需求建議書可行性分析可行性分析目的 GPS監(jiān)控系統(tǒng)的投資失誤 做什么？近期目標(biāo)？ 人員配備，怎樣整合 需求調(diào)研問(wèn)題 開發(fā)費(fèi)用問(wèn)題 風(fēng)險(xiǎn)規(guī)避 頂新國(guó)際集團(tuán)：在投資新產(chǎn)品時(shí) 1400萬(wàn)：全國(guó)28個(gè)城鎮(zhèn)居民消費(fèi)習(xí)慣調(diào)查 700 萬(wàn)：委托28個(gè)城鎮(zhèn)社會(huì)科學(xué)院進(jìn)行全國(guó)七大區(qū)域總體經(jīng)濟(jì)投資環(huán)境的分析“什么都不做”永遠(yuǎn)是一個(gè)可考慮的方案可行性分析的內(nèi)容可行性分析的內(nèi)容項(xiàng)目范圍策略評(píng)估技術(shù)評(píng)估經(jīng)濟(jì)評(píng)估風(fēng)險(xiǎn)評(píng)估項(xiàng)目范圍管理內(nèi)容項(xiàng)目范圍管理內(nèi)容保證項(xiàng)目

40、包括并且僅僅包括需要包括的內(nèi)容。它由以下步驟組成： 初始化：對(duì)項(xiàng)目或階段授權(quán) 范圍計(jì)劃：開發(fā)一個(gè)作為將來(lái)項(xiàng)目決策基礎(chǔ)的書面的范圍聲明 范圍定義：將項(xiàng)目交付物細(xì)分為更小的，更易管理的元件 范圍校驗(yàn)：形式化項(xiàng)目范圍的接受條件 范圍變更控制：控制項(xiàng)目范圍的變更范圍的含義范圍的含義“范圍”包含產(chǎn)品范圍和項(xiàng)目范圍 產(chǎn)品范圍：產(chǎn)品或服務(wù)的特點(diǎn)和功能 項(xiàng)目范圍：為了生產(chǎn)具有特定特點(diǎn)和功能的產(chǎn)品所需要的工作軟件范圍軟件范圍軟件項(xiàng)目計(jì)劃的第一項(xiàng)任務(wù)就是確定軟件的工作范圍，即軟件的用途及對(duì)軟件的要求。因此，應(yīng)從管理角度和技術(shù)角度出發(fā)，確定明確的可理解的軟件項(xiàng)目范圍。軟件范圍的敘述軟件范圍的敘述明確給出定量的數(shù)據(jù)（

41、例如，同時(shí)使用該軟件的用戶數(shù)目，發(fā)送表格的長(zhǎng)短，最大允許響應(yīng)時(shí)間等）指明約束條件和/或限制（例如，產(chǎn)品成本限制了存儲(chǔ)的容量）敘述某些質(zhì)量因素（例如，給出的算法是否容易理解、是否使用Ada語(yǔ)言等）軟件范圍的估計(jì)軟件范圍的估計(jì)軟件范圍包括功能、性能、限制、接口和可靠性。 功能： 軟件功能評(píng)價(jià)，并進(jìn)行適當(dāng)細(xì)化 功能分解，滿足未來(lái)成本和進(jìn)度估算要求 性能 包括處理和響應(yīng)時(shí)間的需求。 約束條件： 外部硬件、可用存儲(chǔ)或其他現(xiàn)有系統(tǒng)對(duì)軟件限制。 功能、性能和約束必須在一起進(jìn)行評(píng)價(jià)。 當(dāng)性能限制不同時(shí)，為實(shí)現(xiàn)同樣的功能，開發(fā)工作量可能相差一個(gè)數(shù)量級(jí)。 如果功能保持相同而性能可變，則開發(fā)軟件所需的工作量和成本將

42、有顯著的差異。價(jià)值驅(qū)動(dòng)的電子商務(wù)分析方法價(jià)值驅(qū)動(dòng)的電子商務(wù)分析方法業(yè)務(wù)流程模型業(yè)務(wù)概念模型策略規(guī)劃級(jí)結(jié)構(gòu)級(jí)實(shí)施級(jí)電子商務(wù)技術(shù)層 業(yè)務(wù)策略的概念結(jié)構(gòu)概念建模協(xié)商建模價(jià)值驅(qū)動(dòng)流程建模資源價(jià)值配置伙伴網(wǎng)絡(luò)價(jià)值鏈構(gòu)架信息策略發(fā)布渠道客戶信任客戶關(guān)系企業(yè)能力價(jià)值建議目標(biāo)客戶產(chǎn)品與服務(wù)創(chuàng)新Revenue Model價(jià)值結(jié)構(gòu)收入模型收益/損失資產(chǎn)、財(cái)務(wù)電子商務(wù)概念模型電子商務(wù)概念模型初始化初始化初始化(Initiation) 正式授權(quán)一個(gè)新項(xiàng)目或者決定一個(gè)已有項(xiàng)目繼續(xù)進(jìn)行下一階段項(xiàng)目是由于下面一些原因產(chǎn)生的： 市場(chǎng)需要（新性能汽車） 業(yè)務(wù)需要（培訓(xùn)中心新課程設(shè)計(jì)） 客戶需要（客戶定制產(chǎn)品） 技術(shù)進(jìn)步（如計(jì)算

43、機(jī)技術(shù)進(jìn)步） 法規(guī)需要（污染處理） 社會(huì)需要（政府水處理系統(tǒng)）初始化初始化輸入： 產(chǎn)品描述 策略計(jì)劃：企業(yè)的戰(zhàn)略計(jì)劃 項(xiàng)目選擇準(zhǔn)則（經(jīng)濟(jì)回報(bào)，市場(chǎng)回報(bào)，公共形象） 歷史信息：以前項(xiàng)目的結(jié)果和性能工具和技術(shù) 項(xiàng)目選擇方法 專家判斷輸出： 項(xiàng)目章程（授權(quán)項(xiàng)目的正式文檔，包括業(yè)務(wù)需求，產(chǎn)品描述） 項(xiàng)目經(jīng)理指派 約束 假設(shè)范圍計(jì)劃范圍計(jì)劃范圍計(jì)劃是將生成產(chǎn)品的項(xiàng)目工作（項(xiàng)目范圍）逐步細(xì)化的過(guò)程。輸入： 產(chǎn)品描述 項(xiàng)目章程 約束 假設(shè)工具和技術(shù) 產(chǎn)品分析 利益成本分析(Benefit/Cost Analysis) 備選方案（brainstorming or lateral thinking) 專家判斷范

44、圍計(jì)劃范圍計(jì)劃輸出 范圍聲明（Scope Statement)，包括 項(xiàng)目理由：Project Justification(Business need) 項(xiàng)目產(chǎn)品:概述 項(xiàng)目交付物：project deliverables 項(xiàng)目目標(biāo): 判斷項(xiàng)目是否成功的定量準(zhǔn)則 支持細(xì)節(jié)（包括假設(shè)和約束） 范圍管理計(jì)劃范圍定義范圍定義范圍定義涉及到將主要的項(xiàng)目交付物細(xì)分以： 提高成本，周期和資源估計(jì)的準(zhǔn)確性 定義性能度量和控制的基線 便于清晰定義責(zé)任分配 范圍定義正確與否將影響項(xiàng)目的節(jié)奏，進(jìn)度，生產(chǎn)率和項(xiàng)目人員的士氣。范圍定義范圍定義輸入 范圍聲明 約束 假設(shè) 其它計(jì)劃輸出 歷史信息工具和技術(shù) WBS(Wor

45、k breakdown structure)模板 分解技術(shù)策略評(píng)估中的模塊管理策略評(píng)估中的模塊管理模塊管理（Programm management)“模塊是一組協(xié)調(diào)管理的項(xiàng)目，通過(guò)將項(xiàng)目組成模塊，將獲得比單個(gè)管理項(xiàng)目更大的效益?！盌. C. Ferns有效的模塊管理需要有一個(gè)模塊目標(biāo)，項(xiàng)目必須根據(jù)模塊目標(biāo)來(lái)選擇在大的組織中，將可能有模塊管理的機(jī)構(gòu)，例如模塊主管或者模塊經(jīng)理即使沒(méi)有專門的組織來(lái)管理模塊，項(xiàng)目的選擇也需要根據(jù)組織的整個(gè)業(yè)務(wù)目標(biāo)來(lái)評(píng)價(jià)策略評(píng)估的內(nèi)容策略評(píng)估的內(nèi)容目標(biāo)：提出的系統(tǒng)對(duì)組織目標(biāo)具有怎樣的貢獻(xiàn)？例如它是否能夠增加市場(chǎng)份額？IS計(jì)劃：提出的系統(tǒng)如何與IS計(jì)劃相適應(yīng)？它將替換或者

46、與那些系統(tǒng)接口？它與將來(lái)開發(fā)的系統(tǒng)有何交互關(guān)系？組織結(jié)構(gòu)：新系統(tǒng)對(duì)目前的部門和組織結(jié)構(gòu)有何影響？例如一個(gè)新的訂單處理系統(tǒng)是否與目前的銷售與庫(kù)存控制的功能相重疊？MIS:系統(tǒng)將在組織的何層次上提供何種信息？它將以何種方式對(duì)現(xiàn)存管理信息系統(tǒng)進(jìn)行補(bǔ)充何提高？人員：系統(tǒng)將以何種方式影響人力水平何現(xiàn)存雇員的技術(shù)？它對(duì)組織整個(gè)人員開發(fā)策略有何影響？情形：系統(tǒng)將使客戶對(duì)組織的態(tài)度有何變化？是否采用一個(gè)自動(dòng)化的系統(tǒng)將與提供友好的服務(wù)相沖突？策略評(píng)估中的業(yè)務(wù)管理策略評(píng)估中的業(yè)務(wù)管理業(yè)務(wù)管理 選定的項(xiàng)目將成為業(yè)務(wù)的一部分，項(xiàng)目將對(duì)資源產(chǎn)生競(jìng)爭(zhēng) 競(jìng)爭(zhēng)中對(duì)業(yè)務(wù)的調(diào)整是必要的技術(shù)評(píng)估技術(shù)評(píng)估技術(shù)的成熟程度實(shí)驗(yàn)室技術(shù)經(jīng)過(guò)

47、中試的技術(shù)已經(jīng)工業(yè)化應(yīng)用的技術(shù)市場(chǎng)需求 顯在 潛在：轉(zhuǎn)化為顯在的條件 競(jìng)爭(zhēng)態(tài)勢(shì)：與競(jìng)爭(zhēng)技術(shù)相比，所采用技術(shù)的優(yōu)勢(shì)及缺陷技術(shù)轉(zhuǎn)換成本支撐體系與條件：原料、銷售網(wǎng)絡(luò)、用戶體系、政策技術(shù)發(fā)展趨勢(shì)及所采用技術(shù)的發(fā)展前景技術(shù)方案選擇技術(shù)方案選擇要考慮的制約條件 需求制約：現(xiàn)存的需求結(jié)構(gòu)及需求結(jié)構(gòu)可能的變化 資源制約：資金、人力資源、自然資源、其它要素 環(huán)境制約：經(jīng)濟(jì)技術(shù)環(huán)境、社會(huì)文化環(huán)境、自然環(huán)境選擇原則 經(jīng)濟(jì)性原則：以最小的投入取得最好的效果 發(fā)展原則：發(fā)展的前景及適應(yīng)發(fā)展的能力 兼容性原則：與原有經(jīng)濟(jì)、技術(shù)、環(huán)境、社會(huì)的兼容性 相關(guān)效果原則：相關(guān)的經(jīng)濟(jì)、技術(shù)、環(huán)境、社會(huì)效果選擇視角 技術(shù)先進(jìn)性 技術(shù)

48、適用性經(jīng)濟(jì)分析經(jīng)濟(jì)分析開發(fā)所需要的成本和系統(tǒng)運(yùn)行所需要的成本與得到的效益的比較 識(shí)別出項(xiàng)目進(jìn)行中所需要的所有成本和效益并對(duì)其進(jìn)行聚集 將成本和效益用單元來(lái)表達(dá)成本分為 開發(fā)成本 安裝成本 運(yùn)行成本經(jīng)濟(jì)分析經(jīng)濟(jì)分析效益 直接效益 可見(jiàn)的間接效益 不可見(jiàn)的效益經(jīng)濟(jì)分析經(jīng)濟(jì)分析凈收益（Net Profit):項(xiàng)目的凈收益是在項(xiàng)目生命周期內(nèi)總的收入與總的成本的差。 沒(méi)有考慮時(shí)間因素回收期限（Payback Period）：將初始投資收回的期限 忽略了整個(gè)項(xiàng)目的盈利空間經(jīng)濟(jì)分析經(jīng)濟(jì)分析投資回報(bào)(Return on investment):也被稱為回報(bào)率(accounting rate of return

49、)(ARR) ROI=（平均年收益/總投資）100 例如項(xiàng)目1：ROI=10,000/100,000*100=10%缺點(diǎn)： 沒(méi)有考慮時(shí)間因素 該回報(bào)率易與銀行利率混淆經(jīng)濟(jì)分析經(jīng)濟(jì)分析凈現(xiàn)率(Net Present Value) 考慮了時(shí)間因素 對(duì)將來(lái)的收益打一個(gè)折扣 “拿在手里的錢才是真正的錢” 如果假定年折扣率為10，那么明年的100元等于現(xiàn)在手中的91元，后年的100元等于現(xiàn)在的83元 目前值t年的值/(1+r)t1.系統(tǒng)開發(fā)費(fèi)用（一次）人員：.2名系統(tǒng)分析員(450小時(shí)/名,45美元/小時(shí)) $40,500.5名系統(tǒng)開發(fā)人員(275小時(shí)/名,36美元/小時(shí)) $49,500.1名數(shù)據(jù)通訊

50、專家(60小時(shí)/名,42美元/小時(shí)) $2,400.1名數(shù)據(jù)庫(kù)管理員(30小時(shí)/名,42美元/小時(shí)) $1,260.2名技術(shù)寫作者(120小時(shí)/名,25美元/小時(shí)) $6,000.1名秘書(160小時(shí)/名,15美元/小時(shí)) $2,400.2名在轉(zhuǎn)換期間數(shù)據(jù)輸入人員 $49,500 (40小時(shí)/名,12美元/小時(shí))培訓(xùn)：l三天的開發(fā)人員內(nèi)部培訓(xùn)課程 $7,000l30個(gè)用戶，三天的內(nèi)部培訓(xùn)課程 $10,000物資：l復(fù)印 $500l磁盤、紙張等消耗品 $650購(gòu)買硬件、軟件：l20臺(tái)工作站W(wǎng)indows軟件 $1,000l20臺(tái)工作站內(nèi)存升級(jí) $8,000l網(wǎng)絡(luò)軟件 $17,500l20臺(tái)工作站

51、辦公軟件產(chǎn)品 $20,000系統(tǒng)開發(fā)總費(fèi)用 $161,670l維護(hù)程序員/分析員(250小時(shí)/年,42美元/小時(shí)) $10,500l網(wǎng)絡(luò)管理員(300小時(shí)/年,50美元/小時(shí)) $15,000購(gòu)買硬件、軟件升級(jí)：l硬件 $5,000l軟件 $6,000物資和雜項(xiàng) $3,500每年總運(yùn)行費(fèi)用 $40,000可行性研究的步驟(1)復(fù)查確認(rèn)系統(tǒng)目標(biāo)、規(guī)模 (2)研究正使用系統(tǒng)工作流程 (3)導(dǎo)出新系統(tǒng)高層邏輯模型 (4)重新定義問(wèn)題 (5)導(dǎo)出和評(píng)價(jià)供選擇的方案 (6)推薦可行的方案 (7)草擬開發(fā)計(jì)劃 (8)編寫可行性研究報(bào)告，送審可行性分析可行性分析可行性分析報(bào)告的格式可行性研究報(bào)告的編寫提示G

52、B 8567-88 計(jì)算機(jī)軟件產(chǎn)品開發(fā)文件編制指南 1 引言 1.1 編寫目的 1.2 背景 1.3 定義 1.4 參考資料可行性研究報(bào)告的編寫提示2 可行性研究的前提 2.1 要求 2.2 目標(biāo) 2.3 條件、假定和限制 2.4 進(jìn)行可行性研究的方法 2.5 評(píng)價(jià)尺度3 對(duì)現(xiàn)有系統(tǒng)的分析 3.1 數(shù)據(jù)流程和處理流程 3.2 工作負(fù)荷 3.3 費(fèi)用開支 3.4 人員 3.5 設(shè)備 3.6 局限性4 所建議的系統(tǒng) 4.1 對(duì)所建議系統(tǒng)的說(shuō)明 4.2 數(shù)據(jù)流程和處理流程 4.3 改進(jìn)之處 4.4 影響 4.5 局限性 4.6 技術(shù)條件方面的可行性可行性研究報(bào)告的編寫提示5 可選擇的其它系統(tǒng)方案 5

53、.1 可選擇的其它系統(tǒng)1 5.2 可選擇的其它系統(tǒng)2 .6 投資及收益分析 6.1 支出 6.2 收益 6.3 收益/投資比 6.4 投資回收周期 6.5 敏感性分析可行性研究報(bào)告的編寫提示項(xiàng)目建議書項(xiàng)目建議書起源：組織內(nèi)部認(rèn)識(shí)到需要利用信息技術(shù) 改進(jìn)目前的業(yè)務(wù)運(yùn)行 改進(jìn)目前的信息系統(tǒng) 開發(fā)新的產(chǎn)品目的： 使管理層能夠作出項(xiàng)目決策準(zhǔn)備招標(biāo)書準(zhǔn)備招標(biāo)書目的： 從客戶的角度全面地、詳細(xì)的論述，為了達(dá)成確定的需求應(yīng)需要作何準(zhǔn)備一份招標(biāo)書應(yīng)當(dāng)是全面的，能提供足夠詳細(xì)的信息，以使承約商或項(xiàng)目團(tuán)隊(duì)能針對(duì)顧客的需要相應(yīng)地準(zhǔn)備一份最優(yōu)的招標(biāo)書招標(biāo)書招標(biāo)書招標(biāo)書中需要提供工作表述招標(biāo)書中必須包括客戶要求，此要求

54、中規(guī)定了規(guī)格和特征招標(biāo)書應(yīng)當(dāng)說(shuō)明客戶期望承約商或項(xiàng)目團(tuán)隊(duì)提供什么樣的交付物招標(biāo)書中應(yīng)當(dāng)列舉客戶供應(yīng)條款招標(biāo)書中可以表述出客戶對(duì)需要的確認(rèn)招標(biāo)書中可以提到客戶想要用的合同類型招標(biāo)書招標(biāo)書表述出客戶想用的付款方式表述出項(xiàng)目完成所需的進(jìn)度計(jì)劃提供有關(guān)承約商申請(qǐng)書的格式和內(nèi)容安排支持客戶希望潛在承約商提交申請(qǐng)書的最后期限可能包括評(píng)價(jià)標(biāo)準(zhǔn)可能會(huì)指出客戶所擁有的可用于此項(xiàng)目的資金量。案例分析案例分析寧波市第五次全國(guó)人口普查辦公室的寧波市人口地理信息系統(tǒng) 地理空間分析、人口統(tǒng)計(jì)與分析一體化 寧波人口普查、日常管理、統(tǒng)計(jì)與分析的數(shù)字化、可視化 人口信息存儲(chǔ)、管理與分析，建立規(guī)范化的空間地理信息與人口信息統(tǒng)一管

55、理、分析、統(tǒng)計(jì)、發(fā)布、錄入、更新與維護(hù) 對(duì)空間數(shù)據(jù)和人口數(shù)據(jù)的快速采集、建庫(kù)、維護(hù)、查詢、管理、顯示、輸出、統(tǒng)計(jì)分析、共享與發(fā)布功能案例分析案例分析性能要求 滿足寧波全部市縣人口的數(shù)據(jù)存儲(chǔ) 不同縣區(qū)都可以調(diào)用數(shù)據(jù)，操作數(shù)據(jù) 保證調(diào)查高峰操作響應(yīng)的人機(jī)交互 保證數(shù)據(jù)統(tǒng)計(jì)的響應(yīng)時(shí)間案例分析案例分析限制要求 Windows平臺(tái)客戶端 服務(wù)器選用Intel服務(wù)器 存儲(chǔ)RAID，保證存儲(chǔ)安全 與DOMINO辦公系統(tǒng)可以實(shí)現(xiàn)接口，可以抽取數(shù)據(jù)報(bào)表需求開發(fā)與需求管理需求開發(fā)與需求管理主要內(nèi)容主要內(nèi)容從一個(gè)故事看軟件開發(fā)的實(shí)際問(wèn)題需求管理的困難性管理需求的目的軟件需求特性需求工程如何獲取需求需求規(guī)格說(shuō)明需求管

56、理工具軟件開發(fā)面臨的實(shí)際問(wèn)題軟件開發(fā)面臨的實(shí)際問(wèn)題軟件開發(fā)面臨的實(shí)際問(wèn)題軟件開發(fā)面臨的實(shí)際問(wèn)題軟件開發(fā)面臨的實(shí)際問(wèn)題軟件開發(fā)面臨的實(shí)際問(wèn)題為什么？為什么？需求？什么是需求什么是需求需求為用戶解決問(wèn)題或達(dá)到目標(biāo)所需的條件或權(quán)能系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范和其它正式規(guī)定文檔所需具有的條件或權(quán)能一種反映上述條件或權(quán)能的文檔說(shuō)明舉例舉例系統(tǒng)必須提供基于PPPoE協(xié)議的用戶接入模式產(chǎn)品應(yīng)當(dāng)提供機(jī)架式安裝，并提供兩個(gè)千兆以太網(wǎng)端口系統(tǒng)使用的用戶是信息中心和網(wǎng)絡(luò)管理員系統(tǒng)在運(yùn)行時(shí)必須提供自動(dòng)數(shù)據(jù)備份功能簡(jiǎn)要的解釋簡(jiǎn)要的解釋需求來(lái)源于用戶的一些“需要”，這些“需要”被分析、確認(rèn)后形成完整文檔，該文檔詳

57、細(xì)地說(shuō)明了產(chǎn)品“必須或應(yīng)當(dāng)”做什么。 如果只有一些零碎的對(duì)話、資料或郵件，你就以為自己已經(jīng)掌握了需求，那是自欺欺人。需求管理的困難性需求管理的困難性需求不總是顯而易見(jiàn)的，而且它可來(lái)自各個(gè)方面。 需求并不總是能容易用文字明白無(wú)誤地表達(dá)。 存在不同種類的需求，其詳細(xì)程度各不相同。 如果不加以控制，需求的數(shù)量將難以管理。 需求之間相互關(guān)聯(lián)，而且需求也和軟件工程流程中的其他可交付工件有關(guān)。 需求有唯一的特征或特征值。例如，它們的重要性和容易滿足的程度都各不相同。 需求涉及眾多相關(guān)方面，這意味著需求要由功能交叉的各組人員管理。 需求會(huì)變更。為什么要管理需求為什么要管理需求？ 避免失敗就是一個(gè)很充分的理由

58、。 提高項(xiàng)目的成功率 需求管理帶來(lái)其他好處 Standish Group 的 CHAOS 報(bào)告進(jìn)一步證實(shí)了與成功項(xiàng)目關(guān)系最大的因素是良好的需求管理。什么是軟件需求什么是軟件需求從軟件開發(fā)過(guò)程看軟件需求開發(fā)從軟件發(fā)展周期看軟件開發(fā)過(guò)程從軟件發(fā)展周期看軟件開發(fā)過(guò)程時(shí)期年代階段涉及注重主要使用語(yǔ)言標(biāo)準(zhǔn)模型初期50-60程序設(shè)計(jì)點(diǎn)編程技巧ALGOLFORTRANCOBOLBASIC 中期70-80軟件開發(fā)線結(jié)構(gòu)化模塊化PASCALGB8566軟件開發(fā)規(guī)范瀑布原型現(xiàn)代90-軟件過(guò)程面過(guò)程能力C,C+JAVAVB、VCISO/IEC12207軟件生存期過(guò)程ISO9000螺旋CMM計(jì)算機(jī)系統(tǒng) 人員硬件軟件數(shù)

59、據(jù)傳輸機(jī)構(gòu)執(zhí)行機(jī)構(gòu)（劇作家、導(dǎo)演）（舞臺(tái)劇本演員道具）軟件開發(fā)全過(guò)程軟件開發(fā)全過(guò)程活動(dòng)任務(wù) 系統(tǒng)需求分析系統(tǒng)結(jié)構(gòu)設(shè)計(jì) 軟件需求分析建立軟件需求評(píng)價(jià)軟件需求聯(lián)合評(píng)審軟件結(jié)構(gòu)設(shè)計(jì)軟件詳細(xì)設(shè)計(jì)軟件編碼和測(cè)試 軟件集成 軟件鑒定測(cè)試系統(tǒng)集成系統(tǒng)鑒定測(cè)試軟件安裝軟件驗(yàn)收支持 軟件開發(fā)過(guò)程軟件開發(fā)過(guò)程 定義（IEEE-STD-610） 用戶為解決某個(gè)問(wèn)題、或?yàn)閷?shí)現(xiàn)某一目標(biāo)， 要求軟件必須滿足的條件或能力。 軟件需求的三個(gè)層次 業(yè)務(wù)需求 用戶需求 功能需求和非功能需求 軟件需求的層次性軟件需求的層次性軟件系統(tǒng)需求(1)系統(tǒng)需求分配軟件工程組硬件系統(tǒng)需求(2)其它成分系統(tǒng)需求(n)軟件需求客戶最終用戶系統(tǒng)工程

60、組系統(tǒng)需求分配系統(tǒng)需求分配業(yè)務(wù)需求業(yè)務(wù)說(shuō)明使用實(shí)例用戶需求功能需求約束條件非功能需求軟 件 需 求 規(guī) 格 說(shuō) 明軟件需求的層次軟件需求的層次需求的層次性需求的層次性業(yè)務(wù)需求項(xiàng)目視圖與范圍文檔用戶需求質(zhì)量屬性系統(tǒng)需求功能需求約束條件其它非功能需求Use Case文檔軟件需求規(guī)格說(shuō)明非功能需求 過(guò)程需求：交付需求，實(shí)現(xiàn)需求，遵循的標(biāo)準(zhǔn)性能需求：速度，容量，可靠性外部需求：互操作性，倫理性， 機(jī)密性，安全性，使用要求 非功能非功能軟件需求軟件需求系 統(tǒng) 需 求ACCS應(yīng)能使汽車保持在預(yù)期車速的2KMH范圍內(nèi)行駛分配給硬件的需求硬件應(yīng)能使車速在規(guī)定的精確度1.5KMH范圍內(nèi)分配給軟件的需求軟件應(yīng)能在