風險管理指南_第1頁
風險管理指南_第2頁
風險管理指南_第3頁
風險管理指南_第4頁
風險管理指南_第5頁
已閱讀5頁,還剩5頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

風險管理指南

TOC\o"1-2"\h\z\u1. 目的 22. 合用范疇 23. 術(shù)語 24. 項目風險管理描述 24.1. 風險分類 24.2. 風險識別 34.3. 風險分析 44.4. 風險解決和減緩活動 55. 風險監(jiān)控 66. 附錄 66.1. 項目風險分析列表 66.2. 參考資料 97. 修訂統(tǒng)計 9

目的描述項目進行過程中可能產(chǎn)生的風險的識別辦法,制訂防止風險的方法,及風險發(fā)生時的解決辦法,供項目策劃時根據(jù)具體項目的狀況選擇或裁剪使用。由此擬定項目采用科學的風險識別辦法,制訂具體的防止方法和解決辦法,以避免風險的發(fā)生,或者當風險發(fā)生時,將損失減小到最低程度。

合用范疇合用于公司的全部合同項目和產(chǎn)品項目,風險管理貫穿于項目的整個生命周期。

術(shù)語項目風險:指項目中不利事件發(fā)生的不擬定性。軟件風險:指軟件開發(fā)過程中及軟件產(chǎn)品本身可能造成的傷害或損失。風險管理:對項目風險進行識別、分析和解決的過程。

項目風險管理描述為了管理項目可能存在的風險,在進行項目策劃時,需要進行風險分析,并制訂風險管理計劃,該計劃可作為項目計劃的一部分。風險管理應(yīng)貫穿于項目工程的始終,它不是項目經(jīng)理一人的任務(wù),也不是一次性的任務(wù),而是一種迭代的過程,任一項目組員都有責任進行風險管理。制訂風險管理計劃涉及:風險識別、風險分析、風險解決、風險跟蹤。風險分類要進行風險管理,先明確項目風險怎么分類。按內(nèi)容分范疇風險:與范疇變更有關(guān)的風險;質(zhì)量風險:影響按照規(guī)定的技術(shù)性能和質(zhì)量水平完畢任務(wù);進度風險:影響在預(yù)算的時間范疇內(nèi)完畢任務(wù);成本風險:影響在預(yù)算的成本范疇內(nèi)完畢任務(wù);技術(shù)風險:技術(shù)變化;法律風險:許可權(quán)、專利、合同失效、訴訟、不可抗力;外部可預(yù)測風險:市場風險(原材料可運用性、需求)、日常運作(維修需求)、環(huán)境影響、社會影響、貨幣變動、通貨膨脹、稅收;外部不可預(yù)測風險:規(guī)章(不可預(yù)測的政府干預(yù))、自然災(zāi)害;內(nèi)部非技術(shù)風險:戰(zhàn)略風險(公司的經(jīng)營戰(zhàn)略發(fā)生了變化)、管理風險(公司管理人員與否成熟等)。按可擬定性分已知風險:如現(xiàn)在測試環(huán)境不能滿足顧客真實使用環(huán)境的模擬??深A(yù)知風險:如使用技術(shù)存在的缺點。不可預(yù)知風險:如外購進口設(shè)備運輸途中可能出現(xiàn)的不能如期達成或損壞的風險。

風險識別風險識別是管理風險的第一步,即識別整個項目過程中可能存在的風險。普通是根據(jù)項目的性質(zhì),從潛在的事件及其產(chǎn)生的后果和潛在的后果及其產(chǎn)生的因素來檢查風險。收集、整頓項目可能的風險并充足征求各方意見后形成項目的《風險和問題跟蹤列表》?!具^程管理平臺中,填寫和維護“風險列表”?!恳M行風險識別的階段在項目開始、每個階段一開始、重要范疇變更同意之前都要進行風險識別,事實上它在整個項目生命周期內(nèi)都是一種持續(xù)的過程。風險事件或風險來源要識別風險,就應(yīng)當理解在項目各個階段都有可能發(fā)生哪些風險。以軟件開發(fā)為例:

初始階段這個階段涉及立項和需求分析及《軟件需求規(guī)格闡明書》的設(shè)計(大部分業(yè)務(wù)建模和需求、少部分分析設(shè)計)。可能的風險事件有:項目目的不清;項目范疇不明確(范疇太大太小都不能夠);顧客參加少或和顧客溝通少;對業(yè)務(wù)理解不夠;對需求理解不夠等。

設(shè)計階段在這個階段進行總體設(shè)計和具體設(shè)計??赡艿娘L險事件有:項目隊伍缺少經(jīng)驗,如缺少有經(jīng)驗的系統(tǒng)分析員;沒有變更控制計劃,以至于變更沒有根據(jù),該變更的不變,不該變的也變,這樣得來的設(shè)計勢必會失敗或者偏離顧客需求;倉促計劃,可能帶來進度方面的風險;漏項,由于設(shè)計人員的疏忽某個功效沒有考慮進去等。

實施階段在這個階段進行大部分編碼和測試,可能有設(shè)計變更或補充設(shè)計。可能的風險事件有:開發(fā)環(huán)境沒有含有好;設(shè)計錯誤帶來的實施困難;程序員開發(fā)能力差,或程序員對開發(fā)工具不熟;項目范疇變化(忽然要增加或修改某些功效,需要重新考慮設(shè)計);項目進度變化(規(guī)定提前完畢任務(wù)等);人員離開,在一種項目內(nèi)軟件開發(fā)工作有一定的持續(xù)性,需要移交和交接,有時人員離開對項目的影響會很大;開發(fā)團體內(nèi)部溝通不夠,造成程序員對系統(tǒng)設(shè)計的理解上有偏差;沒有有效的備份方案;沒有切實可行的測試計劃;測試人員經(jīng)驗局限性;沒有進行可行性研究等。

收尾階段在這個階段進行安裝及維護(大部分布署)??赡艿娘L險事件有:質(zhì)量差;客戶不滿意;設(shè)備沒有準時到貨;資金不能回收;客戶返饋意見引發(fā)大的變更等。風險識別的辦法不同項目可能發(fā)生的風險事件不同,應(yīng)當對具體項目識別出真正有可能發(fā)生在該項目的風險事件。風險識別的有效辦法有諸多,如:

建立風險項目檢查表:能夠從下列幾方面來檢查,產(chǎn)品規(guī)模風險,業(yè)務(wù)影響風險,與客戶有關(guān)的風險,過程風險,技術(shù)風險,開發(fā)環(huán)境風險,與人員的模式和經(jīng)驗有關(guān)的風險。

建立因果分析圖。

征求意見:就項目可能存在的問題和不擬定因素,征求項目構(gòu)組員的意見。

參考以往項目的風險狀況。

提問的方式:針對所識別的潛在風險,采用提問的方式擬定與否應(yīng)認定為風險。擬定所識別的風險類型軟件項目普通有以下五類風險:規(guī)模風險:項目產(chǎn)品本身(大系統(tǒng)和小系統(tǒng))或由項目團體引發(fā)的風險;項目的風險是直接與產(chǎn)品的規(guī)模成正比的。風險因素有:預(yù)計產(chǎn)品的規(guī)模的辦法(代碼行,功效點,程序或文獻的數(shù)目),產(chǎn)品規(guī)模預(yù)計的信任度,產(chǎn)品規(guī)模與以前產(chǎn)品規(guī)模平均值的偏差,產(chǎn)品的顧客數(shù),復用的軟件有多少,產(chǎn)品的需求變化多少。需求風險:不擬定的客戶需求引發(fā)的風險。諸多項目在擬定需求時都面臨著某些不擬定性。當在項目早期的需求不擬定性在項目進展過程當中得不到解決時,就會對項目的成功造成很大威脅。與客戶有關(guān)的風險因素有:對產(chǎn)品缺少清晰的認識,對產(chǎn)品需求缺少認同,在做需求中客戶參加不夠,沒有優(yōu)先需求,由于不擬定的需要造成新的市場,不停變化需求,缺少有效的需求變化管理過程,對需求的變化缺少有關(guān)分析。有關(guān)性風險:項目的外部環(huán)境或因素的有關(guān)性產(chǎn)生的風險。我們經(jīng)常不能較好地控制外部的有關(guān)性,因此緩和方略應(yīng)當涉及可能性計劃,方便從第二資源或協(xié)同工作資源中獲得必要的構(gòu)成部分,并且察覺潛在的問題。與外部環(huán)境有關(guān)的因素有:客戶供應(yīng)條目或信息,內(nèi)部或外部轉(zhuǎn)包商的關(guān)系,交互組員或交互團體依賴性,經(jīng)驗豐富人員的可得性,項目的復用性;管理風險:組織本身的管理水平、能力成熟度引發(fā)的風險。應(yīng)定義項目追蹤過程并且明晰項目角色和責任,以能解決這些風險因素:計劃和任務(wù)定義不夠充足,實際項目狀態(tài),項目全部者和決策者分不清,不切實際的承諾,員工之間的沖突。技術(shù)風險:由人員的技術(shù)水平和經(jīng)驗、使用的工具和技術(shù)的成熟度等引發(fā)的風險。在早期,識別風險從而采用適宜的防止方法是解決風險領(lǐng)域問題的核心,例如:培訓、雇傭顧問以及為項目團體招聘適宜的人才等。重要有下面這些風險因素:缺少培訓,對辦法、工具和技術(shù)理解的不夠,應(yīng)用領(lǐng)域的經(jīng)驗不夠,新的技術(shù)和開發(fā)辦法,不能對的工作的辦法。

風險分析風險分析是對識別出來的風險事件做風險影響分析,擬定避免或減輕風險的方略及方法以達成減少風險,確保項目順利進行的目的。對擬定的風險事件還要進行描述,如:可能性、可能后果范疇、預(yù)計發(fā)生時間、發(fā)生頻率等。和風險有關(guān)的因素和風險有關(guān)的重要四個因素:風險事件,破壞或影響項目的事件風險概率(%),事件發(fā)生的可能性風險得失量(金額),闡明可能造成的損失風險影響(周),等于風險概率×風險得失量周。風險分析環(huán)節(jié)風險分析要擬定每個風險對項目的影響大小,普通是對已經(jīng)識別出來的項目風險進行量化預(yù)計。通過對風險及風險的互相作用的估算來評價項目可能成果的范疇,從成本、進度及性能三個方面對風險進行評價。評價風險影響:指一旦風險發(fā)生可能對項目造成的影響大小。如果損失的大小不容易直接預(yù)計,能夠?qū)p失分解為更小部分再評定它們。風險影響可用相對數(shù)值表達,建議將損失大小折算成對計劃影響的時間表達。預(yù)計風險概率:它是風險發(fā)生可能性的比例表達,是一種主觀判斷。計算風險值和和風險等級:它是評定風險的重要參數(shù)?!帮L險值”=“風險概率”ד風險影響”。如:某一風險概率是25%,一旦發(fā)生會造成項目計劃延長4周,因而,風險值=25%×4周=1周。風險等級(分為1級、2級、3級)。擬定風險優(yōu)先級。哪些風險事件或來源能夠避免,哪些能夠無視不考慮(涉及能夠承受),哪些要采用應(yīng)對方法。

風險分析辦法擬定型風險的分析辦法:盈虧平衡分析(計算和分析產(chǎn)量、成本和盈利這三者之間的關(guān)系);敏感性分析(考察與軟件項目有關(guān)的一種或多個重要因素發(fā)生變化時對該項目投資價值指標的影響程度);概率分析(運用概率論及數(shù)理統(tǒng)計辦法,來預(yù)測和研究多個不擬定因素對軟件項目投資價值指標影響的一種定量分析)。不擬定型風險的分析辦法:有小中取大原則、大中取小原則、遺憾原則、最大數(shù)學盼望原則、最大可能原則。隨機型風險的分析辦法:最大可能原則、最大數(shù)學盼望原則、最大效用數(shù)學盼望原則、貝葉斯后驗概率法等。建立風險跟蹤列表當風險分析完畢后,將風險名稱、風險的分類、風險值、風險等級和排出的風險優(yōu)先級統(tǒng)計到《風險和問題跟蹤列表》中的“風險跟蹤列表”部分?!驹谶^程管理平臺中,填寫和維護“風險列表”。】一旦完畢了《風險和問題跟蹤列表》,就能夠根據(jù)概率及影響來進行綜合考慮,風險影響和出現(xiàn)概率從風險管理的角度來看,它們各自起著不同的作用。一種含有高影響但低概率的風險因素不應(yīng)當占用太多的風險管理時間,但含有中到高概率、高影響的風險和含有高概率及低影響的風險,就應(yīng)當進行風險解決。

風險解決和減緩活動當完畢了風險分析后,就已經(jīng)擬定了項目中存在的風險以及它們發(fā)生的可能性和對項目的風險沖擊,并可排出風險的優(yōu)先級。就能夠根據(jù)風險性質(zhì)和項目對風險的承受能力制訂對應(yīng)的防止方法和解決辦法的計劃,即風險解決和減緩。對每個高優(yōu)先級風險,項目組都要制訂出解決和減緩風險的活動計劃。風險規(guī)避的方略一旦監(jiān)視到風險,就應(yīng)采用合理方法進行風險規(guī)避,能夠從變化風險性質(zhì)、變化風險發(fā)生的概率、變化風險的影響大小等多方面著手。風險規(guī)避的方略普通有:避免:通過分析找出來發(fā)生風險事件的因素,消除這些因素來避免某些特定的風險事件發(fā)生。如避免客戶不滿意,可采用這些方法,客戶參加業(yè)務(wù)建模階段,需求階段要多和客戶溝通,理解客戶真正的需求,目的系統(tǒng)的模型或DEMO系統(tǒng)要向客戶演示,并得到反饋意見,如果反饋的意見和DEMO系統(tǒng)出入比較大時,一定要將修改后的DEMO系統(tǒng)在次向客戶演示,直到雙方都達成共識為止,要有雙方承認的驗收方案和驗收原則,做好變更控制和配備管理。減緩:通過減少風險事件發(fā)生的概率或得失量來減輕對項目的影響。如通過風險識別發(fā)現(xiàn),項目組的程序員對所需開發(fā)技術(shù)不熟。能夠采用熟悉的技術(shù)來減緩項目在成本或進度方面的影響。也能夠事先進行培訓來減緩對項目的影響接受:接受風險造成的后果。如自然災(zāi)害造成的風險,在一種大的軟件項目中,為了避免自然災(zāi)害造成的后果,考慮異地備份中心。轉(zhuǎn)移:使用合作伙伴、項目外包、保險與擔保等手段來轉(zhuǎn)移風險的辦法,以減輕風險對項目帶來的影響?;乇埽寒旐椖匡L險潛在威脅的可能性極大,并會帶來嚴重的后果,無法轉(zhuǎn)移又不能承受時,通過變化項目來規(guī)避風險。普通會通過修改項目目的、項目范疇、項目構(gòu)造等方式來回避風險的威脅。后備方法:重要體現(xiàn)在后備費用、預(yù)留進度時間、后備技術(shù)力量三個方面,這些后備方法在項目計劃中就應(yīng)預(yù)留,確保在項目實施過程中,能充足調(diào)用后備力量解決問題。制訂風險規(guī)避計劃針對需要采用規(guī)避方略的風險事件,要制訂規(guī)避計劃,一旦發(fā)生風險事件,就實施規(guī)避計劃。例如:在一種軟件開發(fā)項目中,某開發(fā)人員有可能離職,離職后會對項目造成一定的影響,則應(yīng)當對這個風險事件開發(fā)應(yīng)對計劃,過程能夠參考以下:進行調(diào)研,擬定流動因素。在項目開始前,把緩和這些流動因素的工作列入風險管理計劃。項目開始時,做好計劃一旦人員離開時便可執(zhí)行,以確保人員離開后項目仍能繼續(xù)進行。制訂文檔原則,并建立一種機制,確保文檔及時產(chǎn)生。對全部工作進行細微詳審,使更多人能夠按計劃進度完畢自己的工作。對每個核心性技術(shù)人員培養(yǎng)后備人員。在考慮風險成本之后,決定與否采用上述方略。風險管理報告無論項目進展的狀況如何,都必須將風險管理的計劃、行動、成果統(tǒng)計到《風險和問題跟蹤列表》,在過程管理平臺中填寫和維護“風險列表”。風險管理的持續(xù)性規(guī)定《風險和問題跟蹤列表》的連貫性和不間斷性,因此,該報表為項目的實施、控制、管理、決策提供信息基礎(chǔ)。對于項目采用的特殊的風險管理問題和方法,可在項目/開發(fā)計劃的風險管理部分闡明,參見《項目/開發(fā)策劃書》,也能夠形成單獨的風險管理計劃文檔。

風險監(jiān)控制訂了風險防備計劃后,風險并非不存在,在項目推動過程中還可能會增大或者衰退。因此,在項目執(zhí)行過程中,需要時刻監(jiān)督風險的發(fā)展與變化狀況,并擬定隨著某些風險的消失而帶來的新的風險。

風險監(jiān)控涉及兩個層面的工作:其一是跟蹤已識別風險的發(fā)展變化狀況,涉及在整個項目周期內(nèi),風險產(chǎn)生的條件和造成的后果變化,衡量風險減緩計劃需求。其二是根據(jù)風險的變化狀況及時調(diào)節(jié)風險應(yīng)對計劃,并對已發(fā)生的風險及其產(chǎn)生的遺留風險和新增風險及時識別、分析,并采用適宜的應(yīng)對方法。對于已發(fā)生過和已解決的風險也應(yīng)及時在《風險和問題跟蹤列表》進行統(tǒng)計,在過程管理平臺中填寫和維護“風險列表”。

風險貫穿于項目的整個生命周期中,因而風險管理是個持續(xù)的過程,建立良好的風險管理機制以及基于風險的決策機制是項目成功的重要確保。風險管理是項目管理流程與規(guī)范中的重要構(gòu)成部分,制訂風險管理規(guī)則、明確風險管理崗位與職責是做好風險管理的基本保障。

附錄項目風險分析列表風險分類潛在風險因素規(guī)避方法建議商業(yè)風險合同類型風險合同的約束風險合同中與第三方的合作風險主承包商風險子承包商風險有關(guān)承包商風險協(xié)作管理方風險賣方因素風險政治因素風險目的、范疇不明確,不知項目何時終止規(guī)范銷售、采用原則合同、工作任務(wù)書模板。訂立補充合同、闡明、備忘錄客戶方風險客戶的技術(shù)素養(yǎng)局限性客戶的承諾風險客戶內(nèi)部對需求理解不一致客戶的需求不明確對客戶需求變化缺少控制機制客戶需求頻繁變更客戶需求發(fā)生重大變化無法與客戶就交付形式、交付時間和交付內(nèi)容達成共識客戶對軟件產(chǎn)品不承認,不在交付清單和試運行報告上簽字客戶不驗收或遲延驗收客戶盼望與產(chǎn)品功效差距太大,客戶反映強烈高級工程師介入售前,提供業(yè)務(wù)咨詢、實施方略、方案設(shè)計等支持,盡量不開空頭支票。變通解決、說服客戶、減少客戶需求??蛻魧嵤┤藛T、最后應(yīng)用效果不滿意、發(fā)生投訴的狀況。實施工程師認證上崗制度,提高實施工程師的素質(zhì)和工作能力;對項目實施質(zhì)量管理,由高級工程師對方案進行審核;及時更換實施工程師、由高級工程師對方案進行優(yōu)化調(diào)節(jié)人力資源風險人員時間和精力不能滿足人員的質(zhì)量意識不強人員的協(xié)作意識不強人員的溝通意識不強人員的主動性不夠人員沒有接受過必要的培訓人員不穩(wěn)定,發(fā)生變動在項目構(gòu)成立時規(guī)定全部項目構(gòu)組員保持固定;健全項目構(gòu)組員的激勵方法。發(fā)生人員變動前及早安排其它人員接替工作,離開時辦理工作交接。人員數(shù)量緊張軟硬件資源和環(huán)境風險缺少必要的軟件硬件設(shè)備不含有測試所需的資源規(guī)定和安排不能滿足測試環(huán)境準備不充足核心計算機資源(指對計算機內(nèi)存和硬盤空間這些資源可能超出現(xiàn)在可能提供的數(shù)量這種風險)進度風險項目時間緊張來自項目進度監(jiān)控的風險軟件產(chǎn)品生命周期各個階段發(fā)生進度延遲項目計劃任務(wù)不明確,進度安排和資源配備不合理計劃沒有得到切實執(zhí)行,實施進度延期,不能如期完畢階段工作制訂計劃時盡量考慮全方面,留有余地;獲得客戶高層的支持和推動,克服障礙;及時調(diào)節(jié)下步計劃,并將計劃調(diào)節(jié)因素形成備忘錄,提交客戶確認。如涉及到工作量的增加,考慮與否追加實施費用。成本風險項目費用與否超出預(yù)算與否有足夠的資金可用技術(shù)風險系統(tǒng)所采用的軟件技術(shù)風險系統(tǒng)所采用新技術(shù)系統(tǒng)所采用的技術(shù)與否成熟項目經(jīng)理、項目人員技術(shù)能力局限性專利風險軟件需求階段過程風險需求的范疇界定需求的穩(wěn)定性(能否獲得客戶對需求文檔的承諾,以確??蛻舨浑S便變更需求)需求的完整性需求的清晰性(需求與否含糊不清)需求的合理性需求的可行性需求的可描述性(文檔能否對的、完備地體現(xiàn)顧客需求)需求開發(fā)人員對項目所涉及的具體業(yè)務(wù)以及對顧客需求的理解沒有對的理解客戶需求沒有適宜的需求分析辦法和建模工具需求的變更實施范疇在工作任務(wù)書中明擬定義;需求調(diào)研成果進行確認;需求、實施范疇的調(diào)節(jié)必須執(zhí)行項目變動控制程序、考慮與否追加實施費用、訂立補充合同軟件設(shè)計階段過程風險設(shè)計的功效性設(shè)計的難度設(shè)計的接口設(shè)計的性能設(shè)計的易測性設(shè)計的硬件約束設(shè)計的可實現(xiàn)性編碼及單元測試的可行性設(shè)計方案與否能滿足客戶需求設(shè)計的變更軟件的易用性軟件的可擴展性軟件編碼階段過程風險源代碼書寫的規(guī)范性源代碼的可讀性單元測試覆蓋率代碼管理風險軟件測試階段過程風險集成測試的環(huán)境風險測試范疇不合理,無法明擬定義測試項測試用例的選擇缺少代表性、不完備測試人員的培訓不充足測試所需的資源規(guī)定和安排不能滿足軟件維護過程風險工程特性的可維護性工程特性的可靠性工程特性的保險方法工程特性的安全性質(zhì)量風險軟件產(chǎn)品出現(xiàn)功效性錯誤軟件產(chǎn)品出現(xiàn)性能問題單元測試問題報告數(shù)量過多各單元模塊集成后,整個系統(tǒng)出現(xiàn)重大問題系統(tǒng)的某些性能指標不能達成客戶需求明擬定義的驗收指標軟件產(chǎn)品復制過程中發(fā)生質(zhì)量問題系統(tǒng)出錯甚至數(shù)據(jù)丟失完善產(chǎn)品、上線前的測試、建立規(guī)范操作、數(shù)據(jù)備份等系統(tǒng)運行制度。其它風險公司高級管理層對本項目不夠重視人員管理風險配備管理風險無法對的標記本項目的風險不能對的評價項目風險選擇的風險對策不能有效地化解或減輕風險無法發(fā)現(xiàn)風險管理計劃中風險識別、風險評價、風險方略的問題項目失敗造成的市場風險提供適宜的、穩(wěn)定的產(chǎn)品;按實施辦法論規(guī)范實施;合同、工作任務(wù)書的定義和約束:目的、范疇、客戶方的責任。宣傳成功案例,抵消項目失敗的負面影響;總結(jié)教訓參考資料《風險管理——軟件系統(tǒng)開發(fā)辦法》,ElaineM.Hall著,王海鵬周靖譯,清華大學出版社,9月《項目風險管理》,盧有杰等著,清華大學出版社,1998年7月《CMMImplementationGuide:ChoreographingSoftwareProcessImprovement》K

溫馨提示

  • 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)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論