軟件項目管理[001].ppt_第1頁
軟件項目管理[001].ppt_第2頁
軟件項目管理[001].ppt_第3頁
軟件項目管理[001].ppt_第4頁
軟件項目管理[001].ppt_第5頁
已閱讀5頁,還剩36頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

2020 2 8 1 授課教師 羅洪Email luozhonghong QQ 56778838 軟件項目管理 2020 2 8 2 1 1軟件工程概述 1 3軟件工程模型 第一節(jié) 軟件工程知識回顧 1 2軟件工程框架 問題 2020 2 8 3 1 1軟件工程概述 要點 美國與我國的軟件產(chǎn)業(yè)的發(fā)展軟件危機(jī)軟件工程定義軟件工程的七條基本原理 2020 2 8 4 美國軟件產(chǎn)業(yè)發(fā)展三個階段 美國軟件產(chǎn)業(yè)三個不同的發(fā)展階段 1 70年代中期至90年代中期的軟件結(jié)構(gòu)化生產(chǎn)階段 以結(jié)構(gòu)化分析與設(shè)計 結(jié)構(gòu)化評審 結(jié)構(gòu)化程序設(shè)計以及結(jié)構(gòu)化測試為特征 2 從80年代中期開始 軟件生產(chǎn)開始進(jìn)入以過程為中心的第二階段 以提出過程成熟度模型CMM 個體軟件過程PSP和群組軟件過程TSP為標(biāo)志 從1995年開始 正在逐步進(jìn)入以軟件過程 面向?qū)ο蠛蜆?gòu)件重用等三項技術(shù)為基礎(chǔ)的軟件工業(yè)化生產(chǎn)時代 2020 2 8 5 美國1999年軟件項目的統(tǒng)計 2020 2 8 6 我國軟件產(chǎn)業(yè)的發(fā)展階段及必由之路 我國軟件技術(shù)人員在數(shù)十年來的研究和開發(fā)工作實踐中 一直在尋找適合我國特點的發(fā)展軟件產(chǎn)業(yè)的技術(shù)途徑 積累了一些經(jīng)驗 也有不少教訓(xùn) 為了適應(yīng)21世紀(jì)對信息技術(shù)的要求 軟件產(chǎn)業(yè)必須走軟件工業(yè)化生產(chǎn)的道路具體地說 一方面需要營造軟件工程文化 培養(yǎng)大量既懂信息技術(shù)又懂企業(yè)管理的高級人才 建立必要的信息產(chǎn)業(yè)通用基礎(chǔ)設(shè)施 另一方面還需要建立以過程工程 系統(tǒng)工程 面向?qū)ο蠹夹g(shù) 軟件過程以及軟件質(zhì)量工程等五個支持環(huán)境為主要特征的軟件產(chǎn)業(yè)基礎(chǔ)設(shè)施 以全面支持和促進(jìn)軟件產(chǎn)業(yè)的建立和發(fā)展 2020 2 8 7 1 1軟件工程概述 要點 美國與我國的軟件產(chǎn)業(yè)的發(fā)展軟件危機(jī)軟件工程定義軟件工程的七條基本原理 2020 2 8 8 軟件危機(jī) 軟件危機(jī)是指在計算機(jī)軟件的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題 2020 2 8 9 軟件危機(jī)產(chǎn)生 個體化軟件環(huán)境早期 程序通常針對又為一個特定硬件和目的而編制 軟件的通用性很有限的 多數(shù)使用該軟件的個人或機(jī)構(gòu)研制 規(guī)模小 個體化的軟件環(huán)境 使得軟件開發(fā)沒有什么系統(tǒng)的方法可以遵循 軟件設(shè)計是在某個人的頭腦中完成的一個隱藏的過程 除了源代碼往往沒有軟件說明書等文檔 案例 我國早期小軟件公司的核心人員的決定公司的命運 中國龍 軟件作坊60年代中期到70年代中期 出現(xiàn)了 軟件作坊 專職應(yīng)別人的需求寫軟件 2020 2 8 10 軟件危機(jī)產(chǎn)生 急劇膨脹隨著計算機(jī)應(yīng)用的日益普及 軟件的數(shù)量急劇膨脹 軟件需求日趨復(fù)雜 用戶有了新的需求是必須相應(yīng)地修改程序 硬件或操作系統(tǒng)更新時 通常需要修改程序以適應(yīng)新的環(huán)境 上述種種維護(hù)工作以令人吃驚的比例耗費資源 更嚴(yán)重的是許多程序的個體化特性使得他們維護(hù)的難度越來越大 最終成為不可維護(hù)的 軟件的規(guī)模越來越龐大復(fù)雜度越來越高交付時間相對短開發(fā)成本令人吃驚地高失敗的軟件開發(fā)項目卻屢見不鮮 軟件危機(jī) 開始了 2020 2 8 11 美國IBM公司在1963年至1966年開發(fā)的IBM360機(jī)的操作系統(tǒng) 這一項目花了5000人一年的工作量 最多時有1000人投入開發(fā)工作 寫出了近100萬行源程序 據(jù)統(tǒng)計 這個操作系統(tǒng)每次發(fā)行的新版本都是從前一版本中找出1000個程序錯誤而修正的結(jié)果 這個項目的負(fù)責(zé)人F D Brooks事后總結(jié)了他在組織開發(fā)過程中的沉痛教訓(xùn)時說 正像一只逃亡的野獸落到泥潭中做垂死的掙扎 越是掙扎 陷得越深 最后無法逃脫滅頂?shù)臑?zāi)難 程序設(shè)計工作正像這樣一個泥潭 一批批程序員被迫在泥潭中拼命掙扎 誰也沒有料到問題竟會陷入這樣的困境 IBM360操作系統(tǒng)的歷史教訓(xùn)成為軟件開發(fā)項目的典型事例為人們所記取 軟件危機(jī)典型案例 2020 2 8 12 軟件危機(jī)表現(xiàn) 軟件成本日益增長開發(fā)進(jìn)度難以控制軟件質(zhì)量差軟件維護(hù)困難 2020 2 8 13 軟件危機(jī)表現(xiàn) 軟件成本日益增長 20世紀(jì)50年代 軟件成本在整個計算機(jī)系統(tǒng)成本中所占的比例為10 20 到20世紀(jì)60年代中期 軟件成本在計算機(jī)系統(tǒng)中所占的比例已經(jīng)增長到50 左右 而且 該數(shù)字還在不斷的遞增 下面是一組來自美國空軍計算機(jī)系統(tǒng)的數(shù)據(jù) 1955年 軟件費用約占總費用的18 1970年達(dá)到60 1975年達(dá)到72 1980年達(dá)到80 1985年達(dá)到85 左右 2020 2 8 14 軟件危機(jī)表現(xiàn) 開發(fā)進(jìn)度難以控制在軟件開發(fā)過程中 用戶需求變化等各種意想不到的情況層出不窮 令軟件開發(fā)過程很難保證按預(yù)定的計劃實現(xiàn) 給項目計劃和論證工作帶來了很大的困難 盲目增加軟件開發(fā)人員并不能成比例的提高軟件開發(fā)能力 相反 隨著人員數(shù)量的增加 人員的組織 協(xié)調(diào) 通信 培訓(xùn)和管理等方面的問題將更為嚴(yán)重 2020 2 8 15 軟件危機(jī)表現(xiàn) 軟件質(zhì)量差由于缺乏工程化思想的指導(dǎo) 程序員幾乎總是習(xí)慣性的以自己的想法去代替用戶對軟件的需求 軟件設(shè)計帶有隨意性 很多功能只是程序員的一廂情愿而已 這是造成軟件令人不滿意的重要因素 2020 2 8 16 軟件危機(jī)表現(xiàn) 軟件維護(hù)困難由于在軟件設(shè)計和開發(fā)過程中 沒有嚴(yán)格遵循軟件開發(fā)標(biāo)準(zhǔn) 各種隨意性很大 沒有完整的真實反映系統(tǒng)狀況的記錄文檔 給軟件維護(hù)造成了巨大的困難 特別是在軟件使用過程中 原來的開發(fā)人員可能因各種原因已經(jīng)離開原來的開發(fā)組織 使得軟件幾乎不可維護(hù) 有資料表明 工業(yè)界為維護(hù)軟件支付的費用占全部硬件和軟件費用的40 75 2020 2 8 17 軟件生產(chǎn)存在的常見問題 軟件生產(chǎn)存在的常見問題有 1 需求搞不清楚2 開發(fā)周期長3 成本高4 質(zhì)量低 不能滿足用戶需要在過去應(yīng)用系統(tǒng)開發(fā)中 得到的常見的體會 一直到采統(tǒng)交付 才明白用戶的需求是什么 甚至系統(tǒng)運行半年之后 才會發(fā)現(xiàn)真正的需求問題 即企業(yè)所運行的軟件系統(tǒng)伴隨社會的不斷適應(yīng)展 軟件需求就會不斷變更 2020 2 8 18 以上的這些問題能夠解決嗎 問題討論 如何克服危機(jī) 2020 2 8 19 1 1軟件工程概述 要點 美國與我國的軟件產(chǎn)業(yè)的發(fā)展軟件危機(jī)軟件工程定義軟件工程的七條基本原理 2020 2 8 20 軟件工程 一詞是來自于1968年北大西洋公約組織 NATO 在聯(lián)邦德國召開的一次會議上首次提出來的 它的主要思想是 把軟件當(dāng)成一種產(chǎn)品 并要求采用工程化的原理與方法對軟件進(jìn)行計劃 開發(fā)和維護(hù) 軟件工程的目標(biāo)是實現(xiàn)生產(chǎn)高質(zhì)量的軟件產(chǎn)品 軟件工程定義 2020 2 8 21 軟件工程的七條基本原理 自從1968年提出 軟件工程 這一術(shù)語以來 研究軟件工程的專家學(xué)者們陸續(xù)提出了100多條關(guān)于軟件工程的準(zhǔn)則和信條 美國著名的軟件工程專家Boehm綜合這些專家的意見 并總結(jié)了TRW公司多年的軟件開發(fā)經(jīng)驗 于1983年提出了軟件工程的七條基本原理 2020 2 8 22 1 用分階段的生命周期計劃嚴(yán)格管理統(tǒng)計表明 50 以上的失敗項目是由于計劃不周而造成的 這條原理意味著 應(yīng)該把軟件生命周期分成若干階段 并相應(yīng)制定出切實可行的計劃 然后嚴(yán)格按照計劃對軟件的開發(fā)和維護(hù)進(jìn)行管理 Boehm認(rèn)為 在整個軟件生命周期中應(yīng)指定并嚴(yán)格執(zhí)行6類計劃 項目概要計劃里程碑計劃項目控制計劃產(chǎn)品控制計劃驗證計劃運行維護(hù)計劃 軟件工程的七條基本原理 2020 2 8 23 軟件工程的七條基本原理 2 堅持進(jìn)行階段評審統(tǒng)計結(jié)果顯示 大部分錯誤是在編碼之前造成的 大約占63 錯誤發(fā)現(xiàn)的越晚 改正它的代價就越大 3 實行嚴(yán)格的產(chǎn)品控制開發(fā)人員最痛恨的事情之一就是需求變動 但是實踐告訴我們 需求的改動往往是不可避免的 這就要求采用變更控制 又叫基準(zhǔn)配置管理 當(dāng)需求變動時 其它各個階段的文檔或代碼隨之相應(yīng)改變 以保證軟件的一致性 2020 2 8 24 軟件工程的七條基本原理 4 采納現(xiàn)代程序設(shè)計技術(shù)采用先進(jìn)的軟件開發(fā)方法 采用先進(jìn)的技術(shù)即可以提高軟件開發(fā)的效率 又可以減少軟件維護(hù)的成本 5 結(jié)果應(yīng)能清楚地審查應(yīng)根據(jù)軟件開發(fā)的總目標(biāo)及完成期限 盡量明確地規(guī)定開發(fā)小組的責(zé)任和產(chǎn)品標(biāo)準(zhǔn) 使所得到的標(biāo)準(zhǔn)能清楚地審查 2020 2 8 25 軟件工程的七條基本原理 6 開發(fā)小組的人員應(yīng)少而精開發(fā)人員的素質(zhì)和數(shù)量是影響軟件質(zhì)量和開發(fā)效率的重要因素 應(yīng)該少而精 這一條基于兩點原因 高素質(zhì)開發(fā)人員的效率比低素質(zhì)開發(fā)人員的效率要高幾倍到幾十倍 開發(fā)工作中犯的錯誤也要少的多 當(dāng)開發(fā)小組為N人時 最大的交流通道數(shù)為N N 1 2 可見隨著人數(shù)N的增大 交流通道數(shù)將急劇增大 2020 2 8 26 軟件工程的七條基本原理 7 承認(rèn)不斷改進(jìn)軟件工程實踐的必要性遵從上述六條基本原理 并不能保證趕上技術(shù)不斷前進(jìn)發(fā)展的步伐 因此 Boehm提出應(yīng)把承認(rèn)不斷改進(jìn)軟件工程實踐的必要性作為軟件工程的第七條原理 根據(jù)這條原理 不僅要積極采納新的軟件開發(fā)技術(shù) 還要注意不斷總結(jié)經(jīng)驗 收集進(jìn)度和消耗等歷史數(shù)據(jù) 進(jìn)行出錯類型和問題報告統(tǒng)計 這些歷史數(shù)據(jù)既可以用來評估新的軟件技術(shù)的效果 也可以用來指明必須著重注意的問題和應(yīng)該優(yōu)先進(jìn)行研究的工具和技術(shù) 2020 2 8 27 軟件工程知識體系 SWEBOK 了解SoftWareEngineeringBodyofKnowledge 2020 2 8 28 2020 2 8 29 1 2軟件工程框架 實現(xiàn)生產(chǎn)高質(zhì)量的軟件產(chǎn)品 選取適宜的開發(fā)模型采用合適的設(shè)計方法提供高質(zhì)量的工程支持重視開發(fā)過程管理 2020 2 8 30 軟件工程活動 1 問題定義主要是系統(tǒng)分析員和用戶參與明確要解決的問題 形成經(jīng)雙方充分討論通過的確認(rèn)文檔 問題定義 可行性研究 需求分析 設(shè)計和實現(xiàn) 支持 確認(rèn) 2 可行性研究研究問題定義階段的問題是否有解決辦法 但不具體的解決問題 并進(jìn)行成本和效益分析 結(jié)果是工程是否繼續(xù)進(jìn)行的重要依據(jù) 2020 2 8 31 軟件工程活動 3 需求分析分析為了要解決問題 目標(biāo)系統(tǒng)必需具備的功能 系統(tǒng)分析員和用戶充分交流討論后形成用戶確認(rèn)的系統(tǒng)邏輯模型 數(shù)據(jù)流圖 數(shù)據(jù)字典算法等 注意教材 p3第一段關(guān)于程序員和用戶在需求分析中階段確認(rèn)的重要性 問題定義 可行性研究 需求分析 設(shè)計和實現(xiàn) 支持 確認(rèn) 2020 2 8 32 軟件工程活動 問題定義 可行性研究 需求分析 設(shè)計和實現(xiàn) 支持 確認(rèn) 4 設(shè)計總體設(shè)計 從概括的層面探討如何解決問題 抽象概括的提出目標(biāo)系統(tǒng)的解決方案 詳細(xì)設(shè)計 把解決方案具體化 設(shè)計出詳細(xì)需求規(guī)格說明書 5 實現(xiàn)根據(jù)需求規(guī)格說明書編寫程序解決具體的問題 2020 2 8 33 軟件工程活動 問題定義 可行性研究 需求分析 設(shè)計和實現(xiàn) 支持 確認(rèn) 6 確認(rèn)測試目標(biāo)系統(tǒng)是否達(dá)到預(yù)定的要求 單元測試集成測試驗收測試 7 支持軟件的維護(hù) 改正性維護(hù) 適應(yīng)性維護(hù) 完善性維護(hù) 預(yù)防性維護(hù) 2020 2 8 34 軟件工程原則 選取適宜的開發(fā)模型采用合適的設(shè)計方法提供高質(zhì)量工程支持重視開發(fā)過程管理 2020 2 8 35 1 3軟件工程模型 軟件工程的演化過程 對軟件工程活動中的各個活動都必需進(jìn)行管理 軟件項目管理貫穿于軟件工程的演化過程 2020 2 8 36 1 3軟件工程模型 線性模型 瀑布模型 特點 1 階段間具有順序性和依賴性2 推遲實現(xiàn)的觀點3 質(zhì)量保證的觀點 缺點 1 假設(shè)了錯誤都發(fā)生在編碼階段 錯誤修復(fù)只能在測試階段完成 思考 需求錯誤會造成怎樣的后果 2 假設(shè)了系統(tǒng)一次性的被構(gòu)建 體會 需求總是會變的 2020 2 8 37 1 3軟件工程模型 軟件工程的螺旋模型 連接的線性模型 2020 2 8 38 1 3軟件工程模型 軟件工程的漸增式模型 分段的線形模型 每個階段都有個可運行的系統(tǒng) 首先構(gòu)建系統(tǒng)的基本輪循模塊 寫出每個功能的空子函數(shù) 保證運行 接著多次多階段的逐個精華或重寫模塊 增量開發(fā)系統(tǒng) 思考 面對提不出需求的用戶 需求分析能否借鑒 先做只有界面的系統(tǒng) 2020 2 8 39 1 3軟件工程模型演化模型 由于在項目開發(fā)的初始階段人們對軟件的需求認(rèn)識常常不夠清晰 因而使得開發(fā)項目難于做到一次開發(fā)成功 出現(xiàn)返工再開發(fā)在所難免 做兩次第一次只是試驗開發(fā) 其目標(biāo)只是在于探索可行性 弄清軟件需求第二次則在此基礎(chǔ)上獲得較為滿意的軟件產(chǎn)品 正式開發(fā) 原形的不斷迭代的過程 2020 2 8 40 GB8567 88計算機(jī)軟件產(chǎn)品開發(fā)文件編制指南 可行性研究報告 GB8567 88 doc開發(fā)進(jìn)度月報 GB8567 88 doc操作手冊 GB8567 88 doc數(shù)據(jù)庫設(shè)計說明書 GB8567 88 doc數(shù)據(jù)要求說明書 GB856T 88 doc文件給制實施規(guī)定的實例 GB8567 88 doc概要設(shè)計說明書

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論