




版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)
文檔簡介
管理技術(shù)
(SoftwareManagement)經(jīng)理管什么?計劃預(yù)算組織進(jìn)度標(biāo)準(zhǔn)§1.估算軟件規(guī)模⑴靜態(tài):Effort=f(lengthofcode)
(2)標(biāo)準(zhǔn)值法(ExpertJudgment)
請多位專家估算程序的最小規(guī)模a
,最可能的規(guī)模
m,和最大規(guī)模b
。以三組平均值估算程序規(guī)模:代碼行技術(shù)LOC代碼行數(shù)KLOC千行代碼數(shù)功能點技術(shù)依據(jù)對軟件信息域特性和軟件復(fù)雜性的評估結(jié)果,估算軟件規(guī)模。這種方法用功能點(FP)為單位度量軟件規(guī)模1.信息域特性功能點技術(shù)定義了信息域的5個特性,分別是輸入項數(shù)(Inp)、輸出項數(shù)(Out)、查詢數(shù)(Inq)、主文件數(shù)(Maf)和外部接口數(shù)(Inf)。下面講述這5個特性的含義。
功能點技術(shù)(1)輸入項數(shù):用戶向軟件輸入的項數(shù),這些輸入給軟件提供面向應(yīng)用的數(shù)據(jù)。輸入不同于查詢,后者單獨計數(shù),不計入輸入項數(shù)中。(2)輸出項數(shù):軟件向用戶輸出的項數(shù),它們向用戶提供面向應(yīng)用的信息,例如,報表和出錯信息等。報表內(nèi)的數(shù)據(jù)項不單獨計數(shù)。(3)查詢數(shù):查詢即是一次聯(lián)機輸入,它導(dǎo)致軟件以聯(lián)機輸出方式產(chǎn)生某種即時響應(yīng)。(4)主文件數(shù):邏輯主文件(即數(shù)據(jù)的一個邏輯組合,它可能是大型數(shù)據(jù)庫的一部分或是一個獨立的文件)的數(shù)目。(5)外部接口數(shù):機器可讀的全部接口(例如,磁盤或磁帶上的數(shù)據(jù)文件)的數(shù)量,用這些接口把信息傳送給另一個系統(tǒng)。2.估算功能點的步驟用下述3個步驟,可估算出一個軟件的功能點數(shù)(即軟件規(guī)模)。(1)計算未調(diào)整的功能點數(shù)UFP首先,把產(chǎn)品信息域的每個特性(即Inp、Out、Inq、Maf和Inf)都分類為簡單級、平均級或復(fù)雜級,并根據(jù)其等級為每個特性分配一個功能點數(shù)。然后,計算未調(diào)整的功能點數(shù)UFP:UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf其中,ai(1≤i≤5)是信息域特性系數(shù),其值由相應(yīng)特性的復(fù)雜級別決定(見書297頁)。(2)計算技術(shù)復(fù)雜性因子TCF度量14種技術(shù)因素(297頁)對軟件規(guī)模的影響程度。根據(jù)軟件的特點,為每個因素分配一個從0(不存在或?qū)浖?guī)模無影響)到5(有很大影響)的值。然后,用下式計算技術(shù)因素對軟件規(guī)模的綜合影響程度DI:
DI=技術(shù)復(fù)雜性因子TCF由下式計算:TCF=0.65+0.01×DI因為DI的值在0-70之間,所以TCF的值在0.65-1.35之間。(3)計算功能點數(shù)FP用下式計算功能點數(shù)FP:FP=UFP×TCF功能點數(shù)與所用的編程語言無關(guān),看起來功能點技術(shù)比代碼行技術(shù)更合理一些。但是,在判斷信息域特性復(fù)雜級別和技術(shù)因素的影響程度時,存在著相當(dāng)大的主觀因素。軟件估算模型使用由經(jīng)驗導(dǎo)出的公式來預(yù)測軟件開發(fā)工作量,工作量是軟件規(guī)模(KLOC或FP)的函數(shù),工作量的單位通常是人月(pm)。支持大多數(shù)估算模型的經(jīng)驗數(shù)據(jù),都是從有限個項目的樣本集中總結(jié)出來的,因此,沒有一個估算模型可以適用于所有類型的軟件和開發(fā)環(huán)境?!?/p>
2工作量估算這類模型的總體結(jié)構(gòu)形式如下:E=A+B×(ev)C其中,A、B和C是由經(jīng)驗數(shù)據(jù)導(dǎo)出的常數(shù),E是以人月為單位的工作量,ev是估算變量(KLOC或FP)。下面給出幾個典型的靜態(tài)單變量模型。1.面向KLOC的估算模型(1)Walston_Felix模型E=5.2×(KLOC)0.91(2)Bailey_Basili模型E=5.5+0.73×(KLOC)1.16
靜態(tài)單變量模型(3)Boehm簡單模型E=3.2×(KLOC)1.05(4)Doty模型(在KLOC>9時適用)E=5.288×(KLOC)1.0472.面向FP的估算模型(1)Albrecht&Gaffney模型E=-13.39+0.0545FP(2)Maston,Barnett和Mellichamp模型E=585.7+15.12FP動態(tài)多變量模型也稱為軟件方程式。動態(tài)多變量估算模型的形式如下:E=(LOC×B0.333/P)3×(1/t)4 其中,E是以人月或人年為單位的工作量;t是以月或年為單位的項目持續(xù)時間;動態(tài)多變量模型B是特殊技術(shù)因子,它隨著對測試、質(zhì)量保證、文檔及管理技術(shù)的需求的增加而緩慢增加,對于較小的程序(KLOC=5-15),B=0.16,對于超過70KLOC的程序,B=0.39;P是生產(chǎn)率參數(shù),它反映了下述因素對工作量的影響:總體過程成熟度及管理水平;使用良好的軟件工程實踐的程度;使用的程序設(shè)計語言的級別;軟件環(huán)境的狀態(tài);軟件項目組的技術(shù)及經(jīng)驗;應(yīng)用系統(tǒng)的復(fù)雜程度。開發(fā)實時嵌入式軟件時,P的典型值為2000;開發(fā)電信系統(tǒng)和系統(tǒng)軟件時,P=10000;對于商業(yè)應(yīng)用系統(tǒng)來說,P=28000??梢詮臍v史數(shù)據(jù)導(dǎo)出適用于當(dāng)前項目的生產(chǎn)率參數(shù)值。從(13.2)式可以看出,開發(fā)同一個軟件(即LOC固定)的時候,如果把項目持續(xù)時間延長一些,則可降低完成項目所需的工作量。
COCOMO2(ConstructiveCostModel):Boehm(1981,1997)
MM=a?KLOCb?Man-MonthSize=kilo-codeCostdriverinfo
關(guān)于成本因素的詳細(xì)討論請看教材p.300-301§3.進(jìn)度計劃(SoftwarePlan)1、GanttCharttw12345678ABCD當(dāng)前進(jìn)度優(yōu)點:簡單,能動態(tài)地反映開發(fā)進(jìn)展。缺點:難以反映多個任務(wù)間的邏輯關(guān)系。012345678
codingA
testingA
debuggingABcoding
understandingC
modifyingC
testingB
testingC
debuggingB
debuggingC
testingABC012356789
codingA
testingA
debuggingA
understandingC
modifyingC
testingB
testingC
debuggingB
debuggingC
testingABC4
debuggingABcoding§2.進(jìn)度計劃
2、PERT(ProgramEvaluation&ReviewTechnique)和CPM(CriticalPathMethod)例:開發(fā)三個模塊A、B、C。
A為公用模塊,B、C的測試須等A的調(diào)試完成后進(jìn)行。A的編碼需6天,測試8天,調(diào)試6天。B的編碼需7天,測試8天,調(diào)試6天。C利用已有的模塊,須先理解原模塊8天,再修改8天,測試9天,調(diào)試7天。最后三模塊集成測試需5天完成。持續(xù)時間LastingTime機動時間SlackTime編號EarliestStartTimeLatestStartTime012345678941363029222014126006142082028293641(0)(0)(15)(4)(2)(4)(0)(2)(0)(2)(0)(0)686678886975(1)標(biāo)出LastingTime(LT)(2)標(biāo)出EST:=從起點始,所有進(jìn)入事件的EST+LT中最大的(3)標(biāo)出LST:=從終點(EST=LST)始,所有離開事件的LSTLT中最小的(4)標(biāo)出ST:=終點LST
起點EST
LT(5)標(biāo)出CriticalPath:即EST=LST的所有事件組成的路徑§2.進(jìn)度計劃§4.人員組織(Personnel)1、程序設(shè)計小組:2~8人的非正式組織優(yōu)點:規(guī)模小,交流方便。缺點:沒有明確的權(quán)威負(fù)責(zé)人,組員間缺乏必要的協(xié)調(diào)。ChiefProgrammerAssistantCPProgramManagerProgramManagerAdminis-trationLibrarianTestTeamSeniorProgrammerJuniorProgrammer
全面負(fù)責(zé)設(shè)計、編碼、測試和安裝主要負(fù)責(zé)測試,必要時替代CP.負(fù)責(zé)和項目有關(guān)的全部事務(wù)性工作行政、后勤管理文檔、工具管理
提出具體測試方案,編寫Driver和Stub,進(jìn)行測試.后備編程力量2、主程序員組(ChiefProgrammerTeam):BakerIBM,1972民主制程序員組的一個主要優(yōu)點,是小組成員都對發(fā)現(xiàn)程序錯誤持積極、主動的態(tài)度。但是,使用主程序員組的組織方式時,主程序員對每行代碼的質(zhì)量負(fù)責(zé),因此,他必須參與所有代碼審查工作。由于主程序員同時又是負(fù)責(zé)對小組成員進(jìn)行評價的管理員,他參與代碼審查工作就會把所發(fā)現(xiàn)的程序錯誤與小組成員的工作業(yè)績聯(lián)系起來,從而造成小組成員出現(xiàn)不愿意發(fā)現(xiàn)錯誤的心理。
現(xiàn)代程序員組現(xiàn)代程序員組的結(jié)構(gòu)現(xiàn)代程序員組大型項目的技術(shù)管理組織結(jié)構(gòu)包含分散決策的組織方式產(chǎn)品運行產(chǎn)品修改產(chǎn)品轉(zhuǎn)移可理解性可維護(hù)性靈活性可測試性可移植性可重用性互操作性正確性健壯性效率完整性可用性奉獻(xiàn)§5.質(zhì)量保證(QualityAssurance)1、軟件質(zhì)量的定義:McCall’squalitymodel(1977)軟件質(zhì)量保證(softwarequalityassurance,SQA)的措施主要有:基于非執(zhí)行的測試(也稱為復(fù)審或評審),基于執(zhí)行的測試(即以前講過的軟件測試)和程序正確性證明。復(fù)審主要用來保證在編碼之前各階段產(chǎn)生的文檔的質(zhì)量;基于執(zhí)行的測試需要在程序編寫出來之后進(jìn)行,它是保證軟件質(zhì)量的最后一道防線;程序正確性證明使用數(shù)學(xué)方法嚴(yán)格驗證程序是否與對它的說明完全一致。2.軟件質(zhì)量保證措施參加軟件質(zhì)量保證工作的人員,可以劃分成下述兩類:軟件工程師通過采用先進(jìn)的技術(shù)方法和度量,進(jìn)行正式的技術(shù)復(fù)審以及完成計劃周密的軟件測試來保證軟件質(zhì)量。SQA小組的職責(zé),是輔助軟件工程師以獲得高質(zhì)量的軟件產(chǎn)品。其從事的軟件質(zhì)量保證活動主要是:計劃,監(jiān)督,記錄,分析和報告。簡而言之,SQA小組的作用是,通過確保軟件過程的質(zhì)量來保證軟件產(chǎn)品的質(zhì)量。1.技術(shù)復(fù)審的必要性正式技術(shù)復(fù)審的顯著優(yōu)點是,能夠較早發(fā)現(xiàn)軟件錯誤,從而可防止錯誤被傳播到軟件過程的后續(xù)階段。走查(walkthrough)審查(inspection)等
2.走查走查組由4~6名成員組成。以走查規(guī)格說明的小組為例,成員至少包括一名負(fù)責(zé)起草規(guī)格說明的人,一名負(fù)責(zé)該規(guī)格說明的管理員,一位客戶代表,以及下階段開發(fā)組(在本例中是設(shè)計組)的一名代表和SQA小組的一名代表。其中SQA小組的代表應(yīng)該作為走查組的組長。走查主要有下述兩種方式:(1)參與者驅(qū)動法。參與者按照事先準(zhǔn)備好的列表,提出他們不理解的術(shù)語和認(rèn)為不正確的術(shù)語。文檔編寫組的代表必須回答每個質(zhì)疑,要么承認(rèn)確實有錯誤,要么對質(zhì)疑做出解釋。(2)文檔驅(qū)動法。文檔編寫者向走查組成員仔細(xì)解釋文檔。走查組成員在此過程中不時針對事先準(zhǔn)備好的問題或解釋過程中發(fā)現(xiàn)的問題提出質(zhì)疑。這種方法可能比第一種方法更有效,往往能檢測出更多錯誤。經(jīng)驗表明,使用文檔驅(qū)動法時許多錯誤是由文檔講解者自己發(fā)現(xiàn)的。3.審查5個基本步驟:(1)綜述。由負(fù)責(zé)編寫文檔的一名成員向?qū)彶榻M綜述該文檔。在綜述會結(jié)束時把文檔分發(fā)給每位與會者。(2)準(zhǔn)備。評審員仔細(xì)閱讀文檔。最好列出在審查中發(fā)現(xiàn)的錯誤的類型,并按發(fā)生頻率把錯誤類型分級,以輔助審查工作。這些列表有助于評審員們把注意力集中到最常發(fā)生錯誤的區(qū)域。(3)審查。評審組仔細(xì)走查整個文檔。(4)返工。文檔的作者負(fù)責(zé)解決在審查報告中列出的所有錯誤及問題。(5)跟蹤。組長必須確保所提出的每個問題都得到了圓滿的解決(要么修正了文檔,要么澄清了被誤認(rèn)為是錯誤的條目)。4.程序正確性證明測試只能證明程序中有錯誤,并不能證明程序中沒有錯誤。程序正確性證明只證明程序功能是正確的,并不能證明程序的動態(tài)特性是符合要求的,此外,正確性證明過程本身也可能發(fā)生錯誤。正確性證明的基本思想是證明程序能完成預(yù)定的功能。因此,應(yīng)該提供對程序功能的嚴(yán)格數(shù)學(xué)說明,然后根據(jù)程序代碼證明程序確實能實現(xiàn)它的功能說明。在20世紀(jì)60年代初期,人們已經(jīng)開始研究程序正確性證明的技術(shù),提出了許多不同的技術(shù)方法。雖然這些技術(shù)方法本身很復(fù)雜,但是它們的基本原理卻是相當(dāng)簡單的。如果在程序的若干個點上,設(shè)計者可以提出關(guān)于程序變量及它們的關(guān)系的斷言,那么在每一點上的斷言都應(yīng)該永遠(yuǎn)是真的。假設(shè)在程序的P1,P2,…,Pn等點上的斷言分別是a(1),a(2),…,a(n),其中a(1)必須是關(guān)于程序輸入的斷言,a(n)必須是關(guān)于程序輸出的斷言。為了證明在點Pi和Pi+1之間的程序語句是正確的,必須證明執(zhí)行這些語句之后將使斷言a(i)變成a(i+1)。如果對程序內(nèi)所有相鄰點都能完成上述證明過程,則證明了輸入斷言加上程序可以導(dǎo)出輸出斷言。如果輸入斷言和輸出斷言是正確的,而且程序確實是可以終止的(不包含死循環(huán)),則上述過程就證明了程序的正確性。人工證明程序正確性,對于評價小程序可能有些價值,但是在證明大型軟件的正確性時,不僅工作量太大,更主要的是在證明的過程中很容易包含錯誤,因此是不實用的。為了實用的目的,必須研究能證明程序正確性的自動系統(tǒng)。軟件配置管理是在軟件的整個生命期內(nèi)管理變化的一組活動:
①標(biāo)識變化;
②控制變化;
③確保適當(dāng)?shù)貙崿F(xiàn)了變化;
④向需要知道這類信息的人報告變化。配置管理是在軟件項目啟動時就開始,并且一直持續(xù)到軟件退役后才終止的一組跟蹤和控制活動。軟件配置管理的目標(biāo)是,使變化更正確且更容易被適應(yīng),在必須變化時減少所需花費的工作量。13.6軟件配置管理1.軟件配置項軟件過程的輸出信息可以分為3類:
①計算機程序(源代碼和可執(zhí)行程序);②描述計算機程序的文檔(供技術(shù)人員或用戶使用);③數(shù)據(jù)(程序內(nèi)包含的或在程序外的)。上述這些項組成了在軟件過程中產(chǎn)生的全部信息,我們把它們統(tǒng)稱為軟件配置,而這些項就是軟件配置項。
軟件配置2.基線基線是一個軟件配置管理概念。IEEE把基線定義為:已經(jīng)通過了正式復(fù)審的規(guī)格說明或中間產(chǎn)品,它可以作為進(jìn)一步開發(fā)的基礎(chǔ),并且只有通過正式的變化控制過程才能改變它。簡而言之,基線就是通過了正式復(fù)審的軟件配置項。軟件配置管理是軟件質(zhì)量保證的重要一環(huán),它的主要任務(wù)是控制變化,同時也負(fù)責(zé)各個軟件配置項和軟件各種版本的標(biāo)識、軟件配置審計以及對軟件配置發(fā)生的任何變化的報告。具體來說,軟件配置管理主要有5項任務(wù):標(biāo)識、版本控制、變化控制、配置審計和報告。軟件配置管理過程1.標(biāo)識軟件配置中的對象單獨命名每個配置項,然后用面向?qū)ο蠓椒ńM織它們。標(biāo)識兩類對象:基本對象和聚集對象(可以把聚集對象作為代表軟件配置完整版本的一種機制)。基本對象是軟件工程師在分析、設(shè)計、編碼或測試過程中創(chuàng)建出來的“文本單元”,例如,需求規(guī)格說明的一個段落、一個模塊的源程序清單或一組測試用例。聚集對象是基本對象和其他聚集對象的集合。每個對象都有一組能惟一地標(biāo)識它的特征:名字、描述、資源表和“實現(xiàn)”。對象名是無二義性地標(biāo)識該對象的一個字符串。在設(shè)計標(biāo)識軟件對象的模式時,對象在整個生命周期中一直都在演化,因此,所設(shè)計的標(biāo)識模式必須能無歧義地標(biāo)識每個對象的不同版本。2.版本控制版本控制聯(lián)合使用規(guī)程和工具,以管理在軟件工程過程中所創(chuàng)建的配置對象的不同版本。借助于版本控制技術(shù),用戶能夠通過選擇適當(dāng)?shù)陌姹緛碇付ㄜ浖到y(tǒng)的配置。3.變化控制變化控制把人的規(guī)程和自動工具結(jié)合起來,以提供一個控制變化的機制。典型的變化控制過程如下:接到變化請求,評估該變化在技術(shù)方面的得失、可能產(chǎn)生的副作用、對其他配置對象和系統(tǒng)功能的整體影響以及估算出的修改成本。評估的結(jié)果形成“變化報告”,該報告供“變化控制審批者”審閱。所謂變化控制審批者既可以是一個人也可以由一組人組成,其對變化的狀態(tài)和優(yōu)先級做最終決策。為被批準(zhǔn)的變化生成一個“工程變化命令”把要修改的對象從項目數(shù)據(jù)庫中“提取(checkout)”出來,進(jìn)行修改并應(yīng)用適當(dāng)?shù)腟QA活動。最后,把修改后的對象“提交(checkin)”進(jìn)數(shù)據(jù)庫,并用適當(dāng)?shù)陌姹究刂茩C制創(chuàng)建該軟件的下一個版本。“提交”和“提取”過程實現(xiàn)了變化控制的兩個主要功能——訪問控制和同步控制。訪問控制決定哪個軟件工程師有權(quán)訪問和修改一個特定的配置對象,同步控制有助于保證由兩名不同的軟件工程師完成的并行修改不會相互覆蓋。一旦對象經(jīng)過了正式技術(shù)復(fù)審并獲得批準(zhǔn),就創(chuàng)建了一個基線。一旦一個軟件配置項變成了基線,就開始實施項目級的變化控制。4.配置審計為了確保適當(dāng)?shù)貙崿F(xiàn)了所需要的變化,通常從下述兩方面采取措施:
①正式的技術(shù)復(fù)審;②軟件配置審計。正式的技術(shù)復(fù)審關(guān)注被修改后的配置對象的技術(shù)正確性。復(fù)審者審查該對象以確定它與其他軟件配置項的一致性,并檢查是否有遺漏或副作用。軟件配置審計評估配置對象的那些通常不在復(fù)審過程中考慮的特征例如,修改時是否遵循了軟件工程標(biāo)準(zhǔn),是否在該配置項中顯著地標(biāo)明了所做的修改,是否注明了修改日期和修改者,是否適當(dāng)?shù)馗铝怂邢嚓P(guān)的軟件配置項,是否遵循了標(biāo)注變化、記錄變化和報告變化的規(guī)程,而成為對正式技術(shù)復(fù)審的補充。美國卡內(nèi)基梅隆大學(xué)(CMU)軟件工程研究所于20世紀(jì)80年代末建立:能力成熟度模型(capabilitymaturitymodel,CMM),是用于評價軟件機構(gòu)的軟件過程能力成熟度的模型。13.7能力成熟度模型能力成熟度模型的基本思想是,由于問題是管理軟件過程的方法不當(dāng)引起的,所以新軟件技術(shù)的運用并不會自動提高軟件的生產(chǎn)率和質(zhì)量。能力成熟度模型有助于軟件開發(fā)機構(gòu)建立一個有規(guī)律的、成熟的軟件過程。改進(jìn)后的軟件過程將開發(fā)出質(zhì)量更好的軟件,使更多的軟件項目免受時間和費用超支之苦。軟件過程包括各種活動、技術(shù)和工具,因此,它實際上既包括了軟件開發(fā)的技術(shù)方面又包括了管理方面。CMM的策略是,力圖改進(jìn)對軟件過程的管理,而在技術(shù)方面的改進(jìn)是其必然的結(jié)果。CMM在改進(jìn)軟件過程中所起的作用主要是,指導(dǎo)軟件機構(gòu)通過確定當(dāng)前的過程成熟度并識別出對過程改進(jìn)起關(guān)鍵作用的問題,從而明確過程改進(jìn)的方向和策略。通過集中開展與過程改進(jìn)的方向和策略相一致的一組過程改進(jìn)活動,軟件機構(gòu)便能穩(wěn)步而有效地改進(jìn)其軟件過程,使其軟件過程能力得到循序漸進(jìn)的提高。CMM把軟件過程從無序到有序的進(jìn)化過程分成5個階段,形成5個逐層提高的等級。5個成熟度等級定義了一個有序的尺度,用以測量軟件機構(gòu)的軟件過程成熟度和評價其軟件過程能力,這些等級還能幫助軟件機構(gòu)把應(yīng)做的改進(jìn)工作排出優(yōu)先次序。成熟度等級是妥善定義的向成熟軟件機構(gòu)前進(jìn)途中的平臺,每個成熟度等級都為軟件過程的繼續(xù)改進(jìn)提供了一個臺階。CMM的每個成熟度級別中都包含一組過程改進(jìn)的目標(biāo),滿足這些目標(biāo)后一個機構(gòu)的軟件過程就從當(dāng)前級別進(jìn)化到下一個成熟度級別;每達(dá)到成熟度級別框架的下一個級別,該機構(gòu)的軟件過程都得到一定程度的完善和優(yōu)化,也使得過程能力得到提高;隨著成熟度級別的不斷提高,該機構(gòu)的過程改進(jìn)活動取得了更加顯著的成效,從而使軟件過程得到進(jìn)一步的完善和優(yōu)化。CMM就是以上述方式支持軟件機構(gòu)改進(jìn)其軟件過程的活動。能力成熟度的5個等級從低到高依次是:初始級(又稱為1級)可重復(fù)級(又稱為2
溫馨提示
- 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)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 委托銀行代繳稅款三方協(xié)議書
- 甲方指定分包合同范本
- 飯店臨時工勞務(wù)合同范本
- 門診經(jīng)營主任責(zé)任協(xié)議書
- 私人灑水車用水合同范本
- 合作伙伴合同協(xié)議書股權(quán)
- 背棄協(xié)議書范本
- 教育變革中的教師激勵與評價機制
- 農(nóng)村基地轉(zhuǎn)讓協(xié)議書
- 美國簽署越南協(xié)議書
- 【KAWO科握】2025年中國社交媒體平臺指南報告
- 云南2025年云南省社會科學(xué)院中國(昆明)南亞東南亞研究院招聘筆試歷年參考題庫附帶答案詳解
- 【語文】第23課《“蛟龍”探?!氛n件 2024-2025學(xué)年統(tǒng)編版語文七年級下冊
- iso220002024食品安全管理體系標(biāo)準(zhǔn)
- 2024年上海市中考數(shù)學(xué)真題試卷及答案解析
- 監(jiān)理人員考勤表
- 克麗緹娜直銷獎金制度
- 基本醫(yī)療保險參保人員丟失醫(yī)療費用票據(jù)補支申請
- 高血壓病人的護(hù)理(PPT)
- DB11-T 825-2021綠色建筑評價標(biāo)準(zhǔn)
- 4例先天性高胰島素血癥患兒的護(hù)理
評論
0/150
提交評論