個體軟件過程(PSP)(2009新版)-恨死高分下載

841個體軟件過程(PSP)北京航空航天高校軟件工程探討所羅燕京2009.5PersonalSoftwareProcess恨死高分下載！842個體軟件過程(PSP)課程內容PSP的基本學問個體軟件過程框架PSP五大核心技能時間管理制定支配缺陷管理軟件規(guī)模度量設計評審843基于支配和質量基本原理的PSP設計每一個工程師要追求最大效率，必需在個人的數(shù)據(jù)基礎上支配他們的工作,工程師要改善其表現(xiàn)，必需接受經過良好定義和度量的過程發(fā)覺并修復缺陷的時間越早其成本越低防止缺陷的產生比發(fā)覺他們更有效844軟件工程師對自已的要求一個軟件工程師的任務就是在預定的進度下交付高質量的軟件產品。軟件工程師常常關切個人技術技能，但往往不太留意個人技術技能的發(fā)揮效率以及方法。為了穩(wěn)定的生產高質量的產品，工程師必需支配、度量和跟蹤產品的質量，而且必需從工作的起先就關注產品的質量。最終必需分析自已每一個工作的結果用以改善其個人的過程。845軟件工程師對自已的要求為了了解自已的表現(xiàn)，必需度量自已每一個工作步驟的花費時間，產生和消退缺陷的數(shù)量以及他們所制造產品的規(guī)模。軟件工程師的最重要的個人資產，就是始終以高質量的產品滿足合同要求的實力。846應用PSP后的效果軟件產品總的缺陷削減58%測試階段發(fā)覺的缺陷削減71.9%生產效率提高20.8%847PSP簡介PSP的探討工作起先于1989年。1995年由美國卡內基梅隆高校的軟件工程探討所發(fā)展。PSP旨在供應一種由實力成熟度模型（CMM）描述的支持過程改進組織進程的個人規(guī)范。PSP是假使應用組織處于或接近CMM2級水平。848CMM、TSP、PSP之間的關系CMM的18個關鍵過程域中，有12個與PSP緊密相關，有16個TSP緊密相關。學習PSP和TSP不僅有助于工程師改善工作效率，而目也特殊有利于組織的改善過程。據(jù)統(tǒng)計，軟件項目開發(fā)成本的70%取決于軟件開發(fā)人員個人的技能、閱歷和工作習慣。因此，軟件開發(fā)人員如能接受PSP培訓，對該單位軟件實力成熟度的升級是一個有力的保證。849個體過程框架模型運用自底向上的方法來改進過程，向每個軟件工程師表明過程改進的原則，使他們能夠明白如何有效地生產出高質量的軟件。PSP是一個個體過程框架模型：PSP說明個體軟件過程的原則；幫助軟件工程師作出精確的支配；確定軟件工程師為改善產品質量要實行的步驟；建立度量個體軟件過程改善的基準；確定過程的變更對軟件工程師實力的影響。8410個體軟件過程框架(四級)PSP為個體的實力供應了一個階梯式的進化框架(共4個級別7個臺階)，以按部就班的方法改進個體軟件過程。每一級別都包含了更低一級別中的全部元素，并增加了新的元素。個體度量過程PSP0和PSP0.1(7個過程行為)個體規(guī)劃過程PSP1和PSP1.1(4個過程行為)個體質量過程PSP2和PSP2.1(3個過程行為)個體循環(huán)過程PSP38411個體軟件過程框架個體度量過程PSP0個體規(guī)劃過程PSP1個體質量管理PSP2個體循環(huán)過程PSP38412個體度量過程PSP0PSP0基線過程當前軟件過程工作時間記錄程序缺陷記錄缺陷類型標準PSP0.1度量過程編碼標準軟件規(guī)模度量過程改善建議個體規(guī)劃過程PSP1PSP1軟件規(guī)模估計測試報告PSP1.1任務規(guī)劃進度安排個體質量管理PSP2PSP2代碼評審設計評審PSP2.1設計模扳循環(huán)過程PSP3PSP3循環(huán)開發(fā)8413PSP過程流程PSP過程從需求狀態(tài)起先，PSP過程的第一步是支配。有一個支配腳本指導這項工作并且有一個支配匯總記錄相關的支配數(shù)據(jù)。當工程師依據(jù)腳本進行工作，他們將他們的時間和缺陷數(shù)據(jù)記錄到時間和缺陷日志。在工作的結束，即事后分析階段，他們依據(jù)日志匯總時間和缺陷數(shù)據(jù)，度量程序規(guī)模，并將這些數(shù)據(jù)記錄進支配匯總表單。當全部這些完成后，他們將完成的產品和完整的支配匯總表單一起交付。8414過程腳本項目支配與總結數(shù)據(jù)表格需求最終產品指南支配數(shù)據(jù)實際數(shù)據(jù)

時間和缺陷數(shù)據(jù)支配和實際的項目過程數(shù)據(jù)計劃設計編碼編繹測試后置處理

PSP過程流程8415PSP0個體基線過程PSP0的目的是建立基線過程。衡量過程改進的基準如下：通過運用PSP的各種表格采集過程的有關數(shù)據(jù)。包括支配、開發(fā)、后置處理三個階段。對軟件開發(fā)時間、缺陷類型標準、引入和解除的缺陷個數(shù)進行必要的測量。8416PSP0.1個體度量過程1.編碼標準良好的編碼標準將有效地避開開發(fā)有潛在緊急的代碼，有助于預防缺陷。編碼標準還能有效地統(tǒng)一和規(guī)范整體開發(fā)活動。當其他開發(fā)人員加入到項目中來時，他們能夠很好地適應這一切。代碼也將變得更規(guī)范更易維護。8417PSP0.1個體度量過程2.程序規(guī)模度量程序大小的度量(往往分解為不同類元素個數(shù)的多少：例如功能點、用例、類、操作)3.過程改善建議表格用于隨時記錄過程中存在的問題、解決問題的措施以及改進過程的方法，以提高軟件開發(fā)人員的質量意識和過程意識)8418個體支配過程PSP1PSP1的主要過程是軟件規(guī)模估計。軟件規(guī)模估計的前提是要清晰所需完成的任務，并對任務做確定的分解,并且要分解到可估算以及盡量接近估算精確的程度,軟件規(guī)模估計是支配的前提。任務分解與開發(fā)方法和實現(xiàn)技術有較大的關系。問題：說明這種關系8419個體支配過程PSP1.1PSP1.1的主要過程是任務和進度的規(guī)劃。支配的主要內容包括完成什么任務,完成任務的估計時間和進度表。起先時登記你的支配進度和努力作為個人任務和實際結果的評估。比較兩組數(shù)據(jù)然后找出差距，這將有助于你提高自己的評估實力。8420PSP1的基本流程8421個體質量管理過程PSP2PSP的一個基本原理是：“假如你在測試以前不高質量的產品，那么在測試以后你也得不到高質量的產品”。在起先實現(xiàn)項目之前查看全部需求和設計,按需求和設計完成工作。當你不確定一個需求時，確定要問清晰,并就文檔模型達成共識。8422質量管理過程的第一步為了滿足質量的基本要求,要學習軟件建模方法和技術,模型是溝通的基礎。通過模型理解軟件的基本結構。任何模型都是通過靜態(tài)模型部分來表達軟件的數(shù)據(jù)結構，通過動態(tài)模型表達驅動數(shù)據(jù)的過程，通過過程的實現(xiàn)完成軟件所要求的功能。8423缺陷管理個體質量管理的內容主要是缺陷管理。缺陷是指程序中存在的錯誤，例如語法錯誤、標點符號錯誤或者是一個不正確的程序語句，是任何影響程序完整而有效的滿足用戶要求的東西，是可以表示、描述和統(tǒng)計的客觀事物。絕大多數(shù)軟件缺陷都源于程序員的疏忽大意。8424缺陷管理為了減小缺陷，就必需進行缺陷管理，探討已經引入的缺陷，確定引起這些缺陷的緣由，并學會在將來如何避開重復同樣的錯誤。缺陷管理的主要內容包括缺陷分類、統(tǒng)計缺陷個數(shù)、缺陷查找技術、缺陷預料。缺陷管理是通過PSP2的代碼評審和設計評審兩個過程完成的。8425個體質量管理過程PSP2.1論述設計過程和設計模板技術，介紹設計方法，并供應了設計模板PSP并不強調選用什么設計方法，而強調設計完備性準則和設計驗證技術。開發(fā)人員必需駕馭設計評審技術和代碼評審技術。8426個體循環(huán)過程PSP3PSP3的目標是把個體開發(fā)小程序所能達到的生產效率和生產質量，延長到大型程序；其方法是接受螺旋式上升過程，即迭代增量式開發(fā)方法;首先把大型程序分解成小的模塊，然后對每個模塊按PSP2.1所描述的過程進行開發(fā)，最終把這些模塊逐步集成為完整的軟件產品。8427個體循環(huán)過程PSP3應用PSP3開發(fā)大型軟件系統(tǒng)，必需接受增量式開發(fā)方法，并要求每一個增量都具有很高的質量。在這樣的前提下，在新一輪開發(fā)循環(huán)中，可以接受回來測試的方法，集中力氣考察新增加的這些增量是否符合要求。因此，要求在PSP2中進行嚴格的設計復查和代碼復查，并在PSP2.1中努力遵循設計結束準則。8428個體循環(huán)過程PSP38429PSP五大核心技能時間管理制定支配缺陷管理軟件規(guī)模度量設計評審84301.時間管理8431時間管理記錄時間數(shù)據(jù)追蹤時間運用時間記錄日志處理時間中斷8432時間管理的邏輯原理為了管理好時間，首先制定時間支配支配，然后按支配去做。為了制定切實可行的支配，必需對所用的時間進行跟蹤為了檢查時間估計和支配的精確性，必需把它們寫成文檔并在今后與實際狀況進行比較為制定出更精確的支配，要了解以前的支配存在哪些錯誤，哪些地方可以改進8433了解時間的運用狀況將主要活動分類記錄每項主要活動所花費的時間用標準的方法記錄時間以分鐘為測量單位。

處理中斷時間。

將時間數(shù)據(jù)保存在合適的地方周活動總結表。

記錄時間的提示。

8434時間跟蹤要想改進工作質量，首先要清晰你當前要做的事情估計出每項任務要花費的時間必需對時間做出測量8435時間記錄日志日期開始時間結束時間中斷時間凈時間活動用例狀態(tài)備注2005.3.98:3010:3020100分析出庫完成10:3012:003060評審出庫完成13:0017:3040230分析入庫完成2005.3.10備注：當活動變換時需另起一行，以便對單個活動進行時間統(tǒng)計。8436運用標準的時間記錄日志日期：進行某個活動的日期起先時間：起先這個活動的時間結束時間：結束這個活動的時間中斷時間：由于中斷所占用的時間(好方法是運用秒表)凈時間：以分鐘為單位計算活動從起先到結束用的時間活動：活動名稱或活動ID狀態(tài):活動狀態(tài)備注：更加完整的注釋8437

統(tǒng)計規(guī)定工作時間實際工作時間中斷累計時間有效時間利用率日統(tǒng)計4805109082.4%周統(tǒng)計月統(tǒng)計時間記錄日志的統(tǒng)計日期開始時間結束時間中斷時間凈時間活動用例狀態(tài)備注2005.3.98:3010:3020100分析出庫完成10:3012:003060評審出庫完成13:0018:0040260分析入庫完成8438活動總結表

活動名稱用例計劃時間實際時間活動狀態(tài)誤差百分比原因分析分析出庫80100完成-25%評審出庫6060完成0備注：可以周或階段為單位8439管理好時間時間管理的要素活動分類收集活動的時間數(shù)據(jù)時間支配的評價作出時間支配找出更多的時間制定基本規(guī)則設定時間支配優(yōu)先級時間管理目標8440時間管理模型

84412.制定支配8442支配內容階段支配產品支配缺陷估計支配8443階段支配階段支配就是將一個大的任務分為若干小階段以分段執(zhí)行。分段執(zhí)行的優(yōu)點是便于支配、實施、跟蹤、檢查和改進。8444產品支配制定產品支配的活動收集歷史項目數(shù)據(jù)估算程序和文檔規(guī)模制定程序和文檔規(guī)范、標準產品支配包含產品規(guī)模、工作時間和進度三方面的估計。通過收集以前不同任務所用時間的數(shù)據(jù)，就能夠估計將來類似的任務或許所須要的時間。8445任務分解與估算

用例任務活動操作復雜度時間估算備份時間25%小計實際數(shù)據(jù)用例任務1活動1操作1中15050200活動2操作2高300100400操作3低12040160操作4中24080320活動3操作5中15050200小計359603201280任務2注：以編碼階段為例數(shù)字單位：分鐘8446任務進度支配任務活動3.14(480)3.15(960)3.16(1440)3.17(1920)任務1活動1活動1活動18447缺陷估計支配項目開發(fā)支配也包括缺陷估計。利用工程師以前的工作閱歷,他們能精確規(guī)劃他們每階段將引入和消退的項目缺陷、缺陷類型、缺陷的或許分布、復查，編譯，和測試時發(fā)覺和修復缺陷所需的或許時間。有了這些閱歷數(shù)據(jù)，工程師可以制定一個檢查表，這可以幫助他們在過程的初期就發(fā)覺缺陷。他們同樣可以改善他們的過程設計，這樣就能防止缺陷的引入。84483.缺陷管理8449什么是缺陷缺陷是指程序中存在的錯誤缺陷是任何影響到程序完整而不能有效滿足用戶須要的東西。缺陷是客觀的事物，是可以標識、描述和統(tǒng)計的。缺陷可能出現(xiàn)在程序中和設計中，甚至在需求、規(guī)格說明或其它文檔中。8450什么是缺陷缺陷是程序員引入的。(平均7-10行源程序就會引入一個缺陷)所以引入缺陷是有緣由的。發(fā)覺和修復缺陷須要大量的時間和費用。(一般的軟件組織須要50%的精力、時間、經費來查找和修復缺陷)所以削減缺陷對每個工程師是很重要的。8451缺陷管理的級別缺陷的級別：查找和標識缺陷解除缺陷削減缺陷預防缺陷8452缺陷管理軟件人員似乎認為測試能找到產品全部或者大多數(shù)缺陷。然而有確鑿證據(jù)表明：即使是運行得很好的單元測試，在查找缺陷方面也只有不超過70%的有效率。集成測試和系統(tǒng)測試為45%，而功能測試一般只有8%。正確的做法是，在測試前集中精力發(fā)覺或者防止缺陷。8453發(fā)覺和修復缺陷的費用探討證明，開發(fā)過程每前進一步，發(fā)覺和修復缺陷的平均代價要增長10倍。盡管缺陷的修復時間變更很大，但平均時間總是遵循這樣的規(guī)律，而與缺陷的類型無關。8454缺陷分類通過缺陷分類，可以快速找出哪一類缺陷的問題最大，然后集中精力預防和解除這一類缺陷，這就是缺陷管理的關鍵。把精力集中到最簡潔引起問題的幾類缺陷上，一旦這幾類缺陷得到限制，在進一步找到新的簡潔引起問題的幾類缺陷上。8455類型編號類型名稱

描述10文檔注釋，信息20語法拼寫，標點符號，打字，指令格式30聯(lián)編打包變更管理，庫，版本控制40賦值說明，重名，作用域，限制50接口過程調用和引用，輸入輸出，用戶格式60檢查出錯信息，不合適的檢查70數(shù)據(jù)結構，內容80函數(shù)邏輯，指針，循環(huán)，遞歸，計算，函數(shù)缺陷90系統(tǒng)配置，記時，內存100環(huán)境設計，編譯，測試，其他支持系統(tǒng)問題缺陷分類8456統(tǒng)計缺陷個數(shù)接受缺陷記錄日志，記錄那些當你完成初始設計或編碼后照舊留在產品中的缺陷。人們很簡潔對缺陷辯解，但是要管理好缺陷，就必需收集有關缺陷的精確數(shù)據(jù)。缺陷記錄日志日期編號類型引入階段排除階段更改時間修復缺陷

描述：8457沒有方法不引入缺陷，但是在開發(fā)過程中盡早發(fā)覺和修復缺陷還是可能的。有多種發(fā)覺程序中的缺陷的方法，基本上都包括以下步驟：表示缺陷征兆；從征兆中推斷出缺陷的位置；確定程序中的錯誤；確定如何修復缺陷；修復缺陷；驗證這個修復是否已經解決了這個問題。發(fā)覺和修復缺陷的方法8458編譯測試用戶反饋最有效的發(fā)覺和修復缺陷的方法是個人復查源程序清單。這種方法很難徹底清除程序中的缺陷，但事實證明，這是最快而且最有效的方法。發(fā)覺缺陷的方法8459缺陷率有閱歷的工程師缺陷引入率是每千行代碼50-250個缺陷，引入缺陷是正?，F(xiàn)象。缺陷率與寫程序的年數(shù)關系并不大缺陷數(shù)量多少主要由每個人的編程規(guī)范確定引入PSP比多年的閱歷有效，可削減50%的缺陷精確估計缺陷個數(shù)對改善過程很重要工程師個人承諾開發(fā)無缺陷的程序是最重要的8460缺陷率一個程序在測試時所發(fā)覺的缺陷的多少與產品投入測試中的數(shù)量成正比。待測試的產品越多，能發(fā)覺的缺陷就越多。產品測試后照舊存在的缺陷與投入測試的產品數(shù)量成比例。8461缺陷密度(Dd)：Defects/KLOC每千行代碼的缺陷個數(shù)計算步驟：累計開發(fā)過程中每個階段發(fā)覺的缺陷總數(shù)(D)統(tǒng)計程序中新開發(fā)的和修改的代碼行數(shù)(N)計算每千行的缺陷數(shù)：Dd=1000*D/N例如：一個96行的源程序總共有14個缺陷，則缺陷密度是:Dd=1000*14/96=145.83/KLOC缺陷密度8462以前開發(fā)程序的千行代碼缺陷數(shù)：Ddplan=1000*(D1+…Di)/(N1+…Ni)設新程序具有相同的缺陷數(shù)：Dplan=Nplan*Ddplan/1000缺陷預料和估計8463缺陷解除效率(DRE)缺陷解除效率(DRE)是軟件質量度量的指標之一。當把一個項目作為一個整體來考慮時，DRE按如下方式定義：DRE=E/(E+D)其中E=軟件交付給最終用戶之前所發(fā)覺的錯誤數(shù),D=軟件交付之后所發(fā)覺的缺陷數(shù)最志向的DRE值是1，即軟件中沒有發(fā)覺缺陷。但現(xiàn)實中，D會大于0，如何把錯誤發(fā)覺的階段盡量限制在軟件交付運用前？PSP能改善這一點。84644.軟件規(guī)模度量8465軟件項目估算對問題進行分解，把其分解成一組較小的接近于最終解決的可控的子問題，再定義它們的特性。規(guī)模測量的方法很多，應當依據(jù)不同的對象運用不同的估計方法。沒有任何方法可以保證估計的結果確定精確，作出好的規(guī)模估計的關鍵是要有大量的歷史數(shù)據(jù)和閱歷，要進行多次規(guī)模估計，并且要定期的將實際結果與估計值進行比較。8466估算程序規(guī)模方法代碼行測量方法功能點方法用例方法利用歷史數(shù)據(jù)或憑實際閱歷，對每個功能分別按樂觀的、可能的、悲觀的三種狀況給出FP估計值。8467FP估算FP估算表包括：每個測量參數(shù)的估算FP計數(shù)=估算值*加權因子項目估算FP=各參數(shù)FP計數(shù)之和*困難度調整因子估算生產率由閱歷獲得估算工作量=項目估算FP/估算生產率估算總成本=日薪*估算工作量單個FP估算成本=估算總成本/估算FP8468用例分析技術為基礎的估算將用例分析技術的結構與實現(xiàn)技術的結構結合相互映射到可估算的粒度。基于用例分析技術的項目分解。基于用例分析結構元素的估算。8469用例分析技術的分解結構8470用例分析技術的執(zhí)行結構8471用例任務活動操作界面事件流動作序列動作JSPAction會話Bean實體Bean

代碼行估算

經驗估算將用例分析技術的結構與實現(xiàn)技術的結構結合相互映射到可估算的粒度。8472項目報告

對比分析與項目有關的數(shù)據(jù)，使軟件人員對估算、實際數(shù)據(jù)相識更深，提高以后的預料率?？梢詫γ恳粋€項目清晰地比較其估算工作量、支配工作量與實際工作量的值，它們的比值越接近1，說明估算、支配越精確。還可以對LOC、FP的估算實際生產率做比較。同時報告還應供應項目中出現(xiàn)的錯誤數(shù)、出錯最多的錯誤名稱及錯誤類型等。84735.設計評審8474設計評審評審對需求的理解。評審設計是否合理。評審文檔表達是否規(guī)范、明確、符合標準。在小組內或個體之間進行。8475代碼復查

代碼復查就是探討源代碼，并從中發(fā)覺錯誤。代碼復查更有效的緣由是：在復查時看到的是問題本身而不是征兆。從頭到尾復查代碼時，考慮的是程序應當做什么。因此，當看到某些地方不正確時，就可以看到可能的問題是什么，并立刻去驗證代碼。復查的缺點是：特殊耗時，而且很難恰當?shù)倪M行；8476代碼復查代碼復查的第一步