研發(fā)部管理制度_第1頁
研發(fā)部管理制度_第2頁
研發(fā)部管理制度_第3頁
研發(fā)部管理制度_第4頁
研發(fā)部管理制度_第5頁
已閱讀5頁,還剩28頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、精選優(yōu)質文檔-傾情為你奉上版/次:V0.1研發(fā)部管理制度編 制:審 核:批 準:分發(fā)號:無錫xxxxxxxx科技有限公司2015年9月專心-專注-專業(yè)目 錄第一章 項目管理制度1、 目的:為規(guī)范項目研發(fā)、加強項目管理,公司根據(jù)企業(yè)實際情況和研發(fā)產品的特點,特制訂研發(fā)部管理制度,望研發(fā)部門遵照執(zhí)行。2、 范圍:適用于對本企業(yè)研發(fā)部項目研發(fā)以及產品研發(fā)的管理。3、 職責:3.1 研發(fā)部工程師負責對相應模塊進行設計開發(fā)。3.2 研發(fā)部小組負責人負責對各自小組承擔語言以及項目或產品模塊的設計開發(fā)以及過程把控。3.3 研發(fā)部經理負責對公司研發(fā)過程技術方向監(jiān)控與技術支持。4、 程序:4.1 項目流程概述項

2、目流程項目研發(fā)須經過立項、設計、實現(xiàn)和測試等幾個階段。 項目立項項目評審項目設計制作項目實現(xiàn)項目實際測試項目調整項目交付項目生成交付物歸檔管理4.2 立項1) 針對研發(fā)項目,首先要起草項目立項報告。2) 針對已經簽定銷售合同的項目發(fā)生的研發(fā),作為合同項目研發(fā),不再單獨立項。3) 項目只有立項后才允許進行進度研發(fā)。4) 項目立項后應獲得一個唯一的研發(fā)編號,費用報銷、研發(fā)領料領用等,都使用此編號作為物 流控制和財務核算的依據(jù)。5) 項目計劃報告必須具有項目名稱、立項目的、編制、審核、項目周期、預計達到參數(shù)指標以及該項目特設指標或者關鍵技術等相關內容。4.3 設計1) 立項后,項目進入設計階段。2)

3、 設計階段由設計承擔人完成技術設計報告和測試計劃報告,以作成項目計劃報告。3) 技術設計報告應說明項目名稱、研發(fā)系統(tǒng)或設備的需求、總體功能、模塊劃分等。4) 測試計劃報告應說明項目名稱、產品功能、測試項目、測試條件、測試方法、測試工期和時間計劃等內容。5) 項目負責人應邀請研發(fā)部門和公司其他部門相關人員,對設計報告和測試計劃報告進行評審。6) 針對沒有通過設計評審的項目,須進行重新設計,再組織有關評審。4.4 實現(xiàn)1) 設計評審通過后,進入項目實現(xiàn)階段。2) 研發(fā)人員必須在實現(xiàn)過程中書寫相關文檔,文檔必須有電子形式。軟件實現(xiàn)文檔應包括軟件功能性說明文檔和源代碼說明文檔。硬件實現(xiàn)文檔包括電器原理

4、圖及結構示意圖。3) 項目負責人有責任按照項目計劃報告,跟蹤監(jiān)督項目的進展情況,按時敦促驗收階段性成果。4) 研發(fā)產品由研發(fā)人員自行調試,調試過程中必須撰寫調試記錄。調試記錄應該說明項目名稱,編號,調試記錄版本號,調試時間,軟硬件版本號,調試中發(fā)現(xiàn)的主要問題,調試環(huán)境,解決方法等有關內容。5) 研發(fā)產品確認運行穩(wěn)定后,由項目負責人組織內部驗收。研發(fā)文檔應視為研發(fā)實現(xiàn)階段工作量的一部分,不具備研發(fā)文檔將視為工作沒有結束,不組織內部驗收。6) 軟件功能性說明文檔應說明項目名稱,編號,軟件名稱和編號,軟件功能,軟件功能模塊劃分,主要功能實現(xiàn)過程,軟件主要實現(xiàn)算法。7) 源代碼說明文檔項目編號,軟件名

5、稱,軟件功能等。源代碼說明文檔可以包含在源代碼文件中,以注釋形式存在。4.5 測試1) 研發(fā)產品經內部驗收后,進入測試階段。2) 測試階段開始后,研發(fā)實現(xiàn)人員將研發(fā)的產品,以及研發(fā)調試記錄移交給測試人員。測試人員按照產品的測試計劃報告、研發(fā)調試記錄,設計測試過程,填寫產品測試報告。3) 產品測試報告應該說明項目名稱,編號,測試報告版本號,需測試功能,指標,測試方法,測試環(huán)境,測試條目,測試結果,結論等。4) 如果研發(fā)產品不能通過測試,測試人員應把產品測試報告提交給產品實現(xiàn)人員。產品實現(xiàn)人員修改軟硬件后重新進行調試,相應更新研發(fā)調試記錄內容和版本號,確認產品合格后提交 測試人員再次檢測。如此反復

6、,直到產品通過測試為止。5) 測試人員確認產品達到要求,在產品測試報告的結論欄內簽字表示同意,交項目負責人。4.6 產品發(fā)布1) 項目負責人拿到產品測試通過的報告后,填寫或者委托他人填寫產品發(fā)布公告和產品發(fā)布計劃,交公司技術負責人或者授權產品發(fā)布人核準,簽字發(fā)布。項目負責人與簽字發(fā)布產品的不得為同一人。發(fā)布公告和產品發(fā)布計劃需送市場部、生產部和公司有關領導。2) 項目負責人必須在產品發(fā)布后一周內,將所有研發(fā)文檔整理存檔。3) 產品發(fā)布計劃應說明項目名稱、編號、產品名稱、型號、版本號、產品說明書的完成時間和計劃。產品說明書的完成時間一般應在產品完成后5個工作日內完成。4.7 生產1) 產品發(fā)布后

7、,進入正式生產階段。2) 生產階段須具備總裝圖、電器原理圖和性能參數(shù)要求。3) 裝配圖應說明產品名稱、型號結構件的固定位置、裝配順序、電氣連接圖、走線固定位置等。4) 生產測試要求文檔需要說明針對的產品名稱,型號、測試環(huán)境和測試方法。4.8 項目調整1) 設計更改l 由于市場或技術原因,需要對項目重新進行設計時,更改人員需填寫設計更改申請單,按照立項程序進行審批。需經公司技術負責人簽字同意,報公司總經理批準生效。l 對已經發(fā)布的產品進行更改,被認為是一個新的研發(fā)項目,按照標準程序執(zhí)行。l 對尚未發(fā)布的產品進行更改,需要更新該項目所有此前產生過的技術文檔,已經進行過的評審必須重新進行。2) 項目

8、取消l 出于市場或其他方面的考慮,需要取消某個項目的研發(fā),必須由發(fā)起人或者委托人填寫項目取消申請表,申請表必須說明項目名稱,編號,取消原因。l 研發(fā)項目的取消需經公司技術負責人簽字同意,報公司總經理批準生效。l 項目取消后,研發(fā)助理負責將項目取消通知發(fā)送給公司領導層和研發(fā)、銷售、生產、財務等 相關部門。3) 項目暫停l 出于市場或資源飽和原因,需要暫停某個項目的研發(fā),必須由發(fā)起人或者委托人填寫項目暫停申請表。l 申請表必須說明項目名稱,編號,取消原因。研發(fā)項目的暫停需經公司技術負責人簽字同意,報公司總經理批準生效。l 項目暫停后,研發(fā)助理負責將項目暫停通知發(fā)送給公司領導層和研發(fā)、銷售、生產、財

9、務等相關部門。5、 質量記錄:第二章 研發(fā)部績效管理制度1、 目的:通過考核評定實行相應的績效處罰,并不斷的發(fā)現(xiàn)管理的工作不足之處,調整全公司的工作方向和管理目標。原則:以獎為主,以罰為輔,重獎輕罰,獎罰分明。2、 范圍:適用于對本企業(yè)研發(fā)部人員績效方面的管理。3、 職責:3.1 研發(fā)部行政主管負責制定研發(fā)部人員績效考核指標的修改和建立。3.2 研發(fā)部員工應遵循此制度條款配合公司績效考核工作。3.3 辦公室應配合研發(fā)部做好績效考核相應工作并對考核結果進行整理歸檔。4、 程序:4.1 宗旨考核制度貫徹于研發(fā)工作全過程中,利用績效和獎金相結合的報酬機制,鼓勵積極,鞭策落后,提高產品開發(fā)效率和合格率

10、,減少失誤,降低開發(fā)成本,增加公司產品的市場競爭力,同時調動每位研發(fā)人員的工作積極性,努力提高工作水平,統(tǒng)一員工的工作努力方向,推動公司的持續(xù)快速發(fā)展。4.2 基本原則1) 結果考核與行為考核相結合2) 考核者必須依據(jù)員工實際表現(xiàn)和工作事實進行評價。3) 公司成立技術開發(fā)評審小組,小組成員由總經理任命。4) 考核必須公開考核流程、公開考核指標,堅持公正、公平、公開的原則,考核結果由考核雙方共同簽字確認。5) 考核執(zhí)行人必須充公了解員工在考核期內的工作內容、工作過程和工作效果。在雙方平等溝通的基礎上展開考核工作。4.3 細則1) 按照各人負責的工作類別不同,考核類別分為“優(yōu)秀、良好、合格、不合格

11、”。2) 電路設計:視產品復雜性及任務的完成情況,以績效考核表為準。3) 結構設計:視產品復雜性及任務的完成情況,以績效考核表為準。4) 硬件設計:視產品復雜性及任務的完成情況,以績效考核表為準。5) 軟件設計:視產品復雜性及任務的完成情況,以績效考核表為準。6) 文秘及后勤:及時、準確、妥善的將設計師的文件歸檔、分發(fā)、收取,對需要打樣的產品落實追蹤到位,準時是考核的主要條件。4.4 考核對象1) 試用期及實習期員工不參與此項考核2) 已轉正的員工則根據(jù)工作情況,分為非技術類及技術類進行考核。3) 部門經理級人員(含部門副經理)不參加此項考核,由公司統(tǒng)一進行部門經理綜合考核評定。4.5 考核周

12、期與時間1) 實行半年度考核;每半年考核一次。其中每年的6月份考核上半年的業(yè)績,每年12月份考核下半年的業(yè)績。2) 考核正式開始前十日部門開始進行考核,兩個工作日提交辦公室匯總呈評審小組最后得分,三個工作日評審小組出具考核結果,由辦公室下達考核結果給部門經理,五個工作日內完成績效面談。4.6 實施1) 考核的依據(jù):設計計劃書中的進度規(guī)定和設計要求。2) 考核方法:綜合評分,按照公司績效考核表中內容進行考核。3) 評分標準:分為自評和上級領導評價,根據(jù)分值加權求得最終分數(shù)對應相應等級。4) 每次考核完成匯總員工評分并分出等級,并根據(jù)公司相應規(guī)定進行鼓勵與批評談話。5) 公司設置獨立員工工資體系外

13、的考核資金,每季度得分超過100%的員工,每增加1%獎勵基本工資的10%,最高不超過其基本工資的200%。有特殊貢獻的員工,公司予以獎勵,由董事會審批。6) 績效考核流程圖:考核前期準備7)制定考核計劃考核執(zhí)行考核考核評價考核反饋(申訴、面談、調查表)績效的更新和修改資料的歸檔整理4.7 考核體制考核對象初評匯總部門復評最終核定技術人員研發(fā)部門辦公室評審小組副總經理部門職員研發(fā)部門辦公室/副總經理1) 由員工填寫本季度主要工作項目及業(yè)績,給考核者相應參考數(shù)據(jù)。2) 部門評定:由員工直屬上級對員工個人本季度各考核項目做出綜合評分。3) 評審小組對其考核的結果做復評。4) 副總經理進行最終評定。4

14、.8 績效溝通與改進1) 每考核完成一次部門經理至少需和員工進行一次績效面談,共同確定績效計劃,講解員工優(yōu)勢和需要改進的績效,共同分析與實際結果存在差距的原因,達到組織績效與個人績效目標一致。2) 各部門可根據(jù)工作需要增加面談次數(shù)。3) 面談方式為:以正式的、一對一、面對面的方式進行。4) 每次考核完成要進行績效考核情況調查,分發(fā)調查表進行無記名調查,針對提出的問題進行改進。4.9 考核申訴考核申訴是為了使考核制度完善化和在考核過程中真正做到公開、公正、合理而設定的特殊程序。1) 參加考核的任何員工對評估結果擁有申訴的權利,部屬與直接主管接到考核內容和結果后,如有異議,可先向直接主管提出申訴,

15、由直接主管進行協(xié)調;如直接主管協(xié)調后仍有異議,可向辦公室提出申訴,由辦公室進行調查協(xié)調。2) 考核申訴的追訴時限至考核當月結束為止。4.10 評估資料的保管1) 各部門部門經理指定專人對員工所有的評估資料進行集中保管,考核表必須以電子文檔形式及書面形式各保留一份,電子文檔由部門及辦公室各留存一份,書面文檔由辦公室作為人事檔案留存。2) 季度評估表作為員工的人事檔案由行政部統(tǒng)一保管。3) 除管理人員因工作需要可查看員工的評估資料外,其他員工不得隨意翻看、查閱。4) 任何接觸到考核資料的人員都有保密的義務,不得散布、傳播。4.11 附則1) 本制度由公司管理部門負責修訂而成,解釋權歸辦公室。2)

16、整體考核進程由辦公室負責推動,各相關部門協(xié)助完成。3) 本制度是公司績效考核的重要制度,每一位員工均可對其不完善之處向辦公室直接提出相關建議,被采納的建議將在制度中及時修訂。4) 本制度執(zhí)行后,與本制度有抵觸的規(guī)定或條款以本制度為準。5、 質量記錄:績效考核培訓資料、績效考核計劃、績效考核表、績效考核調查表第三章 SQA工作流程1、 目的:為加強項目監(jiān)控體質管理,監(jiān)督研發(fā)過程,對項目研發(fā)進度進行全程質量監(jiān)控。2、 范圍:適用于研發(fā)部項目過程的監(jiān)控管理。3、 職責:3.1 SQA項目小組成員按分工監(jiān)控項目過程并及時上報質量情況。3.2 項目組長成員應配合SQA的檢查和監(jiān)督。4、 程序:4.1 目

17、標:Ø 遵循軟件質量保證計劃進行軟件質量保證活動Ø 客觀地驗證軟件開發(fā)過程和軟件產品是否遵守可用的標準、規(guī)程和要求Ø 確保將軟件質量保證的活動和結果通知受影響的項目組和人員Ø 高層管理者關注在軟件項目中不能解決的偏差事件和不合格項4.2 SQA活動的策略當SQA剛切入項目組時,SQA首先就要掌握項目組的一些基本情況,主要包括項目經理的能力,項目的規(guī)模,項目工期,客戶對進度、質量的要求,項目組成員情況,項目組織架構情況。其中最關鍵的是要看項目經理的能力情況。)PM能力欠佳,則SQA的工作就是全程跟蹤項目,審計是重中之重。)項目經理的能力強,則SQA的主要工

18、作可以劃分為兩部分,一部分是對一些重點的過程和產品進行審計,另一部分是優(yōu)化我們的過程,流程,對我們的發(fā)現(xiàn)的一些問題或缺陷進行分析,改進我們的過程。4.3 具體活動:1) SQA參與制定計劃SQA參與制定計劃包括SDP和階段計劃,在SDP活動中,SQA主要是參與到軟件過程的剪裁、復審估算、參與評估風險等。然后,SQA參與復審SDP,其目的,除了熟悉項目的計劃外,還需要復審看是否SDP與納入項目的客戶的需求一致,計劃能否滿足客戶的需求的,在SDP修正中,涉及到上述內容的,也需要SQA參與。然后,SQA也會參與階段計劃的制定,主要是復審階段計劃是否滿足階段的目標。2) SQA參與復審納入項目的需求此

19、時SQA主要是作為復審者的角色,復審納入的需求描述是否清晰、一致、需求的可行性等。3) SQA制定SQA審計計劃在制定計劃的同時,SQA也需要制定SQA審計計劃,在制定SDP的時候,SQA制高層的審計計劃,主要是計劃有那些內容需要SQA審計的。然后,在制定階段計劃的時候,SQA需要制定具體的審計計劃,包括每次審計的時間,審計的對象等。4) SQA參與進度復審或里程碑復審活動SQA在參與進度復審或里程碑復審活動中,主要是一方面了解項目的進度,另一方面,復審項目在進度復審中采取的一些修正行動的時候,是否滿足客戶的需求,是否可行等,而在里程碑復審中,則復審項目當前的狀態(tài)是否滿足里程碑的標準(Crit

20、eria of Milestone),是否達到里程碑的目標。5) SQA審計另外,SQA的主要活動是按照制定的SQA審計計劃對項目進行審計,審計的內容包括過程審計和工作產品審計。過程審計主要是審計項目開展的軟件活動是否和計劃、與OSSP一致,工作產品審計主要是審計工作產品是否滿足標準和約束條件。6) SQA階段總結由于公司很多項目都是采用迭代模式的開發(fā),項目開發(fā)周期較長,所以有必要在項目某個階段結束的時候,對SQA在這個階段的活動進行一個總結,主要是對一些經驗教訓進行分析,找出這些問題背后的原因,提出一些可行性的解決方案,目的是為了提高質量保證的水平。7) 跟蹤問題處理SQA應跟蹤問題處理過程

21、,直到問題解決。跟蹤的問題包括日常發(fā)現(xiàn)的產品問題、過程問題、項目風險、評審發(fā)現(xiàn)的問題、測試發(fā)現(xiàn)的問題等。如果不能和項目組就解決方案達成一致,可向公司高層反映。8) 度量和報告SQA應善于根據(jù)過程規(guī)范和經驗發(fā)現(xiàn)項目運行中的問題,并做到緊急問題、重要問題隨時匯報,其它問題周期性匯報。SQA需要隨時收集數(shù)據(jù)并保障數(shù)據(jù)的有效性、真實性。定期匯總數(shù)據(jù)、統(tǒng)計分析并產生度量報告。SQA應協(xié)助項目組和SEPG針對不良趨勢和問題采取糾正或預防措施。9) 質量推進質量推進主要包括提高全員的質量意識和推進、解釋過程的執(zhí)行兩個方面。這項工作需要在日常工作中一點一點地、堅持不懈地實施,這樣做的目的是為了營造公司的一種質

22、量文化氛圍,理解和支持SQA的工作。10) 過程制定如果項目或組織需要制定過程規(guī)范,SQA應組織相關人員來完成過程制定工作。一般情況下,過程制定應由遵守和執(zhí)行該過程的人員負責。所有制定的過程都必須經過評審,并由SQA檢查執(zhí)行情況。11) 過程改進過程改進是一項長期的任務。SQA應注意隨時發(fā)現(xiàn)、聽取過程執(zhí)行中問題和改進工作的方法,并進行階段性的總結(比如質量報告等),以不斷改進過程,提高過程能力。12) 學習和研究SQA要不斷學習和研究,盡量保持與領域最新的知識、方法同步,找出提高產品質量和工作效率的方法與過程。學習的內容主要包括管理領域和開發(fā)領域。管理領域包括質量管理(TQM、ISO9000、

23、CMM、RUP、MSF、XP等)、軟件度量(PSM、GQM、SPC、SixSigma)、項目管理、配置管理等。開發(fā)領域包括需求工程、設計、編碼、測試等各階段的開發(fā)和管理方法。13) 質量培訓項目或組織需要時,SQA需要向相關人員進行質量管理方面的培訓或咨詢4.4 SQA審計工作指南:SQA工作的很重要一項就是審計,SQA審計工作的目標是驗證項目組實際執(zhí)行是否與項目計劃相符合,執(zhí)行的步驟是否與公司規(guī)定相符合,及時發(fā)現(xiàn)項目存在的問題,并提交問題報告,跟蹤直至問題得到解決。4.4.1 SQA審計工作的各個階段:可以將SQA審計劃分為各個階段:1) 審計任務計劃階段:審計任務的計劃是SQA計劃中的一部

24、分,應該根據(jù)每個項目的特點進行不同的考慮,以安排審計任務。主要的依據(jù)有幾點:根據(jù)項目的風險安排審計任務的重點,根據(jù)項目計劃的進度安排組織審計任務的時間,根據(jù)審計對象的不同考慮審計方法;2) 審計任務執(zhí)行階段:審計任務應該按照SQA計劃來執(zhí)行,并根據(jù)審計對象的不同采取對應的審計方法;因為實際的審計的執(zhí)行需要兼顧項目的實際情況(包括人員、進度),因此要做好SQA審計狀態(tài)的記錄,及時跟蹤審計任務的執(zhí)行情況,出現(xiàn)審計任務與SQA計劃的出入時,應該進行計劃變更;3) 審計問題的提出階段:在審計中發(fā)現(xiàn)問題時,應該首先與項目相關的工作人員溝通,明確問題,同時記錄SQA問題清單,并知會項目PM;問題應該得到項

25、目組的認同,問題說明應該清晰,當問題不能夠明確時(不能認同、確定),需要報請SEPG或者高層經理確認。發(fā)現(xiàn)的問題一般應該得到及時的處理,當問題不能及時解決時,應該提交SQA的問題報告,問題報告中需要明確問題的責任人,以及計劃解決時間;4) 審計問題跟蹤階段:對SQA提交的問題,需要對其狀態(tài)進行跟蹤,保證問題能夠得到解決,對于解決時間超出計劃時間的問題,應該在每周的報告中提交給高層經理。4.4.2 SQA審計方法:審計方法根據(jù)審計對象的不同,可以分為:項目活動審計,和項目產品審計。1) 項目活動審計是根據(jù)項目計劃,到達對應的項目活動執(zhí)行時,SQA人員切入到項目中,通過與項目組溝通,了解項目活動的

26、執(zhí)行情況。具體的了解方式可以有多種,如:與項目組直接的溝通、通過活動的記錄文檔了解活動的進展、直接參與項目組的活動等;方法的選擇取決于活動的類型以及項目的具體情況,采用什么方式以達到了解項目活動實際情況為目標。2) 項目產品審計,主要是對項目的工作產品進行審計,項目的工作產品是否合格包括兩個方面:1、滿足客戶以及公司對產品的要求,一般要求符合工作產品的模板、標準,其中客戶的要求一般都會明確在項目納入的需求和相關的計劃中;2、項目產品的合格也是由流程來保證的,產品的開發(fā)過程應該按照計劃得到了必要的復審和評審。審計產品的時機一般是在產品提交后進行,但是SQA也應該根據(jù)工作產品的特點,注意安排產品制

27、定、開發(fā)當中的審計,以期及早發(fā)現(xiàn)問題。4.5 報告機制1) 周報:把一周來SQA活動發(fā)現(xiàn)的問題進行匯總并加以簡要的分析,發(fā)送高層、項目組有關負責人、質量部負責人、SEPG2) 上報項目經理:對一些比較緊急的問題應立即報告給PM,如果能達到一致的情況下,要求落實問題的解決,3) 上報高層:如果發(fā)現(xiàn)了問題,不能與pm達到一致的話,上報高層4.6 參與的其它活動Ø 了解項目成員每天的工作情況Ø 促進項目關系人員之間的溝通Ø 參與風險的識別,跟蹤管理Ø 量化工作4.7 SQA工作流程圖參與項目制定項目計劃劃準備檢查表預約審計開展SQA活動編制審計報告是否有不符合

28、性問題是否月底SQA工作提交配置管理人員是否項目結束END通知單完成的工作追蹤不符合性問題編寫SQA月狀態(tài)報告制作修改SQA計劃YesYesYesYesNoNoNo5、 質量記錄:SQA計劃、審計報告、狀態(tài)報告第四章 項目評審制度1、 目的:主要是盡早發(fā)現(xiàn)潛在的問題,盡早糾正缺陷,控制項目整體進程。2、 范圍:適用于研發(fā)部項目評審工作。3、 職責:3.1 項目組長協(xié)助評審人員進行項目評審工作,并提交評審計劃。3.2 評審人員針對項目進行系統(tǒng)評審并撰寫評審報告。3.3 評審人員應對評審完成發(fā)現(xiàn)的問題進行后續(xù)跟蹤處理。4、 程序:4.1 評審角色構成因素評審人員的選擇是評審效果的關鍵,需要考慮以下

29、因素: Ø 項目重要性:項目重要性是決定角色構成的最重要的因素,先要根據(jù)項目的重要性而定。這與需要投入的成本有關,對于重要的項目一般會更多地投入資源,提高評審級別。 Ø 項目復雜度:項目的復雜度也是決定角色構成的因素之一,根據(jù)溫伯格的公式,項目管理的復雜度相當于功能規(guī)模的平方數(shù)。筆者認為還應該考慮技術復雜度、技術新鮮度和文檔復雜度等因素。項目組成員的能力成分和水平。Ø 項目組成員的能力成分和水平:評審角色構成還應當根據(jù)項目團隊成員本身的各項技術水平,特別是分析和設計的技術水平如何,行業(yè)領域知識是否豐富來進行搭配。除了團隊內部自己進行評審之外,評審團隊最好是一些獨立

30、于項目團隊之外的成員構成。 應當注意的原則是人數(shù)要少而精,一個人可以兼多個角色,但要覆蓋各項人員需求。需要說明的是,不具備評審能力的不應參加,可以通過旁聽來提高水平。 4.2 基本角色職責Ø 評審組長:制定評審計劃、確定或制定各項評審準則、必要時組織評審人員進行培訓、組織必要的資源、進行評審分工、確保正式評審準備充分、分發(fā)待評審文檔、必要時召開并主持評審會議、向有關領導報告評審結果,并且跟蹤評審錯誤的改正。 Ø 評審人員:必要時參加與評審有關的培訓、按評審計劃閱讀待評審材料、保證對待評審材料的理解、與待評審材料作者討論,并且指出和記錄問題。 Ø 文檔作者:按評審計

31、劃準備并按時提交待評審材料、必要時對材料進行解釋、必要時參加評審會議,并且在確定需要改進時按時完成修改。 Ø 記錄人員:評審會議中記錄評審人員提出的問題及相關討論。 Ø 項目經理:制定保證評審和改正的項目進度計劃,還要確保評審準備時間、評審會議時間及錯誤的改正時間。而且評審安排及結果與所有項目成員溝通,必要時參加評審會議、閱讀評審報告、分析缺陷原因,并且改進項目質量。 4.3 文檔評審的層次Ø 過程規(guī)范:是否符合過程規(guī)范、是否按照計劃提交、是否按時經過評審、是否準時發(fā)布(注意提交時間與發(fā)布時間的區(qū)別),以及評審的流程是否規(guī)范。適合的評審人員:QA。 Ø

32、文檔規(guī)范:文檔成果符合企業(yè)或業(yè)界已經制定的文檔模板規(guī)范。企業(yè),甚至行業(yè)應當制定統(tǒng)一的文檔規(guī)范,形成一個文檔約定和規(guī)則,以統(tǒng)一文檔內容與風格。適合的評審人員:QA。 Ø 文檔語法:文檔成果正確使用通用的方法與術語并符合軟件工程相關的技術標準,這里所說的語法包括自然語言的語法和建模語言的語法。適合的評審人員要求:精通軟件工程、分析與設計方法、建模工具和相關標準。 Ø 文檔語義:文檔成果表達清晰、無歧義,可以反映系統(tǒng)目標。所有質量合格的文檔 (包括模型)都代表它期望代表的語義,而且應該在代表這些語義時具有一致性。文字與圖表應當互相補充說明,以更加清晰。讓別人看得懂,看完后知道下一

33、步該 怎么做。 適合的評審人員:行業(yè)業(yè)務專家、高級程序員和測試工程師。 Ø 文檔邏輯:主要體現(xiàn)需求與設計正確性、一致性,無遺漏、多余或錯誤。前后左右 考慮周全,不同文檔之間、文檔與行業(yè)標準之間、同一文檔各成分之間不互相矛盾,清晰說明相關部分之間的關系,特別是要符合相關行業(yè)的業(yè)務標準規(guī)范。 適合的評審人員:行業(yè)業(yè)務專家、產品經理和測試工程師。 Ø 文檔美學:文檔成果能否表述得更好一些,文字、圖表是否能更加均衡和完整。 需要追求平衡的美,每個組成部分應該大小適中,可解讀并可變更。平衡有多個方 面,如排版次序更加合理、文字、圖形更加精煉并更易理解等。適合的評審人員:系統(tǒng)分析與設計

34、專家,以及建模工具專家。 Ø 結果優(yōu)化:通過檢查判斷文檔成果(如項目計劃、需求規(guī)格及設計方案)是否還有改進的空間,以便更加方便地進行項目管理、降低成本、加快進度、提高質量并減少風險,盡可能達到最佳方案。任何一項設計都可以有許多不同的方案,通過“方案優(yōu)化”選定一種最好的方案。 適合的評審人員:系統(tǒng)分析與設計專家、項目經理和產品經理。 4.4 文檔評審流程 4.4.1 評審流程概覽和流程圖確定評審組長。 制定并發(fā)布評審計劃。準備評審。 舉行評審會議。 改正、跟蹤和回歸評審。 分析、總結和報告。 歸檔。 4.4.2 確定評審組長由品質保證人員與項目經理、部門經理論協(xié)商,確定項目的評審級別及

35、評審人員角色構成要求,初步確定評審組長人選。品質保證人員與評審組長溝通,最終確定評審組長。評審組長充分了解項目相關情況,為制定評審計劃做好準備。 4.4.3 評審計劃 評審組長制定評審計劃(根據(jù)項目計劃和質量計劃) 。 評審組長確定評審對象和評審時間。 評審組長確定評審級別和策略(形式的組合)。 評審組長確定評審流程裁減和提交物。 評審組長確定入口條件并通過準則。 評審組長確定回歸評審準則。 評審組長制定評審檢查表(CheckList)。 評審組長確定評審角色構成。 評審組長根據(jù)評審角色構成確定評審人員并成立評審小組。 相關人員(評審人員和項目團隊雙方)確認評審計劃。評審組長發(fā)布評審計劃。 4

36、.4.4 評審準備 正式評審前準備:文檔作者向相關人員發(fā)布文檔。 評審人員閱讀了解文檔,爭取發(fā)現(xiàn)大部分問題。 文檔作者解決大部分發(fā)現(xiàn)的問題。 評審組長確定會議地點、環(huán)境、設備和所有材料。 評審組長確定人員職責和會議議程。 評審組長確定評審開始條件成熟。 評審組長通知相關人員到會。 4.4.5 評審會議 主持人(評審組長)宣布會議議程、人員職責和會場紀律。 文檔作者介紹工作成果,對評審人員的疑問進行必要的解釋。 評審人員對不解之處提出疑問,指出問題或缺陷并說明根據(jù)。 文檔作者與評審人員討論缺陷的真實性,分清缺陷性問題和建議性問題,討論確定是否需要按照評審人員的要求進行改進。一般不涉及為節(jié)省時間改

37、進方案或錯誤的糾正方案。 4.4.6 評審記錄 正式評審應當記錄有共識的問題或缺陷,也要記錄有爭議待解決的問題。使評審工 作文檔化,便于跟蹤最終解決。 總體記錄:包括項目名稱、系統(tǒng)名稱版本號、 日期時間、 主文檔名稱、附文檔名稱、 文檔版本號、作者、評審類型(首次、回歸、部分和階段) 、評審人員和評審結論。 缺陷記錄:包括缺陷編號、提出者、章節(jié)頁碼、缺陷描述、缺陷類型(嚴重、一 般和建議)和承諾改正時間。 驗證記錄:全部打勾的 CheckList,說明 CheckList 所列的工作都已經做完,所列的內容都已經評審完,確保工作的完整性。 4.4.7 評審結論評審結論包括如下內容: 是否需要修改

38、?這是就成果的整體而言,結論可以是無需、少量、較大或是一個量化的數(shù)字。 項目組確定是否接受修改要求?這是針對具體的一條意見或建議。有些問題可能是 誤會,消除了就不是問題;有些建議性的問題,項目組考慮進度可不接受修改要求。 如不接受修改要求,項目組給出不修改的理由。 如何處理?是否需要進行回歸評審? 總體結論:合格或不合格。 確定的修改責任人和跟蹤責任人。 確定的回歸評審時間。 是否都認同評審結論?如果需要做得更正式一些,可以要求相關人員簽字表示同意評審結論,簽字 。4.4.8 跟蹤與總結評審中發(fā)現(xiàn)的問題的后續(xù)跟蹤是改正錯誤并消除缺陷的有效措施, 應當有專門的負責人進行后續(xù)跟蹤確認錯誤都已改正,

39、根據(jù)結論必要時回歸評審。 評審組長分析評審數(shù)據(jù)并總結經驗。 評審組長發(fā)布評審記錄與數(shù)據(jù)分析報告。 管理人員應當防止評審數(shù)據(jù)被不恰當?shù)厥褂?,如果使用評審數(shù)據(jù)來對個人進行績效 評價,將會給以后的評審工作造成障礙,使評審各方不能放開進行評審。 評審組長進行工作總結,工作總結很有必要,有利于對項目或過程的改進。 評審組長提交各類評審報告,有關領導批準發(fā)布通過的文檔。 4.4.9 材料歸檔評審材料歸檔是項目配置管理工作的一部分。新建項目,記載配置管理工具中為此項目 建立一個目錄,并建立下列子目錄。 待評閱態(tài):文件放入此目錄后會自動通過郵件通知需要評閱的人員,全體評閱人員評閱完畢,也會自動通過郵件把意見通

40、知文檔作者并實現(xiàn)到期自動提醒功能。 待評審態(tài):文件放入此目錄后會自動通過郵件通知需要評審的人員,全體評閱人員評審完畢,也會自動通過郵件把批準或拒絕的意見通知文檔作者并實現(xiàn)到期自動提醒功能。 受控態(tài):評審批準后自動轉入受控態(tài)并發(fā)布自動郵件。 簽出態(tài):為了修改而版本升級,當文件簽出時放入簽出態(tài)。修改后的文檔可能簽入到待評閱態(tài)、待評審態(tài)或直接到受控態(tài),但文檔版本已經升級。 產品態(tài):項目結束后受控態(tài)的文檔自動歸到產品態(tài)。5、 質量記錄:評審計劃、評審報告第五章 項目交付物管理制度1、 目的:為規(guī)范本公司研發(fā)部技術文件的管理,確保文件編制的正確性、完整性,特制訂本制度。2、 范圍:適用于公司研發(fā)部門項目

41、完成后的交付物的管理。3、 職責:3.1 項目組長及成員應對所研發(fā)項目的交付物列清單逐一交付。3.2 辦公室為研發(fā)部技術文件設立檔案保管,借閱情況統(tǒng)一進行統(tǒng)計。4、 程序:4.1 技術文件的編制、審核、批準 1) 技術文件包括:a) 產品設計圖紙;b) 作業(yè)指導書;c) 設計相關書籍、光盤等;d) 技術檔案和技術資料;e) 未打印出圖的尚在計算機里的圖紙資料;f) 發(fā)放到各部門的技術文件;g) 實物樣品等研發(fā)部相關文件。2) 技術文件的技術要求和數(shù)據(jù)等必須符合國家相關標準和規(guī)定要求。3) 技術文件由技術開發(fā)部等相對應部門編制,研發(fā)部應對技術文件的準確性、合理性負責。4) 研發(fā)部部長負責技術文件

42、的審核。5) 總經理負責技術文件的批準。6) 技術文件的編制必須嚴格保密。7) 技術文件應保證標題欄中的編號、名稱、日期、審核、批準等欄中簽署齊全,簽署不齊全的技術文件無效。4.2 技術文件的管理與應用1) 技術文件的發(fā)放:a. 技術文件在發(fā)放至生產車間之前,必須加蓋“受控文件”章,到研發(fā)部處登記,填寫【技術文件領返記錄表】,簽字領出。b. 技術文件的發(fā)放按生產計劃進行,定期發(fā)放的生產用文件由研發(fā)部統(tǒng)一下發(fā)和更換。研發(fā)部門必須保證下發(fā)的工藝的完整性和有效性,同時保證下發(fā)到車間主任、生產指導、檢驗等部門的工藝應一致。2) 技術文件的保管和使用:a. 研發(fā)部的技術文件應長期并分類保存,管理要科學系

43、統(tǒng),能有效控制,確保各相關部門都能得到有效的版本,防止作廢的技術文件誤用。作廢的技術文件必須經常研發(fā)部部門鑒定且研發(fā)部部長批準后銷毀。b. 本公司的技術文件,由研發(fā)部管理。確保所保管的技術文件不受潮、不霉爛、不受損、不丟失。c. 紙質技術文件或光盤技術文件等收存到資料柜內保管,資料柜鑰匙由研發(fā)部部長負責保管。本單位有關人員可以查、借閱。借閱技術文件應憑技術開發(fā)部部長批準的【借閱申請單】向研發(fā)部借閱。用完及時歸還,并保證文件的完整性。d. 技術文件是公司進行生產和各項管理工作共同的技術依據(jù),必須加強管理,各種技術文件的登記、保管、復制、收發(fā)、注銷、歸檔和保密工作,保證技術文件的完整,準確清晰、統(tǒng)

44、一等。e. 簽字領出技術文件人應負責將領出的文件收回,交研發(fā)部部長存檔。f. 每種技術文件,研發(fā)部應完成技術資料整理,并做備份、存檔。g. 本廠所使用的研發(fā)部技術文件一律由研發(fā)部統(tǒng)一保管,統(tǒng)一建檔并逐一登記。3) 技術文件的更改a. 產品投入生產時,技術科應及時提供相應的工藝作業(yè)指導書并確保無誤。生產部如發(fā)現(xiàn)操作時,有不妥當?shù)姆矫婕皶r與技術科主管溝通解決。b. 下發(fā)后的技術文件如需更改,研發(fā)部需要下發(fā)文件更改申請單,各相關部門必須據(jù)通知單要求做相應更改。涉及安全性能的圖紙更改后,須由研發(fā)部組織重新審核并備案。更換的技術文件要有標記,并要有記錄。c. 技術文件修改前,負責修改部門要提出修改理由及

45、具體內容,交研發(fā)部部長審批。d. 修改后的技術文件必須重新履行會審、會簽及批準手續(xù),填發(fā)文件更改申請單。4) 技術文件的保密a、 任何部門、個人不得擅自打印、復制公司技術文件,不得以電子文檔等形式在網(wǎng)上傳遞或者用移動硬盤、U盤、軟盤等拷貝出。因工作需要必須打印或復制時,經辦人提出書面申請書,開發(fā)部部長簽字批準后方可通過打印、復制、拷貝。b、 為了保證技術資料的保密性,除按正常程序辦理外,任何人不得私自向外人轉讓和借出技術資料,一經發(fā)現(xiàn)要按公司所簽署的保密協(xié)議給予嚴肅處理。c、 員工用于工作的計算機未經主管批準不得隨意拆開,計算機硬盤中的資料屬公司機密,硬盤不準任何人私自帶出公司。若計算機出現(xiàn)故

46、障,需研發(fā)部部長指定專業(yè)人送修,并保證硬盤中資料保密性。d、 技術科及其他使用、保管技術資料的部門或個人,應注意保密,嚴禁將技術資料帶出公司,或提供給其他公司。5) 技術文件的銷毀a、 由于新技術的日新月異,越積越多的技術文件會占據(jù)不必要的資源,故有的技術文件需要銷毀和清除,對回收的技術文件由技術部門統(tǒng)一管理。b、 需要銷毀的研發(fā)部技術文件,研發(fā)部部長會同有關技術人員一起仔細校對核實,然后將銷毀理由與銷毀文件清單上報研發(fā)部部長,由研發(fā)部部長簽署“同意”后,方可銷毀。c、 普通技術文件須保存3年以上,重要技術文件須保存5年以上,以方便以后的產品技術改造。因各種原因,導致某種產品不再生產,或產品改

47、型,使原有技術資料報廢,由研發(fā)部收回,加蓋“報廢”章,并專項保管。5、 質量記錄:交付物清單第六章 項目驗收流程1、 目的:為規(guī)范公司項目驗收工作流程。2、 范圍:適用于公司驗收項目管理。3、 職責:3.1 驗收小組成員嚴格按照此規(guī)范對項目進行驗收。3.2 項目組長及成員應配合驗收小組成員做好項目驗收工作。3.3 辦公室應對驗收情況和結果進行存檔處理。4、 程序:4.1 驗收流程圖:由于IT項目驗收一般均比較復雜,因此,一般將IT項目的驗收劃分為四個階段:驗收準備、初步驗收、最終驗收、報告總結。(見劃分請參見:IT項目驗收流程圖)4.2 驗收準備驗收準備階段主要是根據(jù)項目的情況組建驗收組織,并

48、確定驗收方式、驗收內容、標準以及驗收條件等。1) 成立驗收小組。驗收小組的主要組成為使用部門、信息技術部、招標部門、財務等部門,該項工作需要領導的參與和批準,另外,對于金額比較大的項目,有條件也可以請股東代表參與。2) 確定驗收策略。驗收小組根據(jù)項目的特點確定項目驗收的方式,即是否需要分階段驗收,完成驗收階段的劃分,并制定相關的驗收計劃,一般對于比較復雜的項目均需要劃分階段進行初步驗收,而且階段的劃分也需要與供應商進行溝通和確認。3) 確定驗收內容和標準。根據(jù)前面確定的驗收策略明確各階段驗收的條件、需要驗收的內容、驗收通過的標準,以及需要提交的資料清單等,其中值得一提的是驗收內容包括時間進度的

49、驗收項目。4) 領導審批。由領導審批驗收小組確定的驗收階段和驗收內容以及標準等是否合理。4.3 初步驗收初步驗收主要是完成軟硬件系統(tǒng)的初步運行情況,IT項目可能涉及硬件設備的驗收,也可能涉及軟件系統(tǒng)的驗收,也可能同時涉及軟件和硬件的驗收,由于對于機房裝修這樣復雜的項目,涉及到幾個硬件子系統(tǒng)和軟件子系統(tǒng)的驗收;對于硬件系統(tǒng)的驗收,存在兩個驗收步驟,在設備到貨后需要驗收設備到貨情況,在調試完成后需要進行設備試車驗收(試運行),一般付款條件為試車驗收通過,不是到貨驗收通過。1) 驗收申請。當供應商認為符合驗收條件后會提請進行驗收。2) 檢驗驗收條件是否合格。驗收小組接到供應商的驗收申請后,審查是否符

50、合驗收條件。3) 供應商進行整改。如果驗收小組認為不符合驗收條件,將要求供應商進行整改,供應商根據(jù)驗收小組提出的整改意見進行相關的整改,整改完成后再次提請驗收。4) 驗收類型的判斷。驗收小組會根據(jù)項目的性質,分別按照軟硬件系統(tǒng)進行初步驗收。5) 硬件設備到貨驗收。當硬件設備到貨后,供應商會提請進行到貨驗收,驗收小組將根據(jù)合同和驗收內容進行設備的品牌和規(guī)格的檢驗,查看設備是否完整無缺,并記錄設備到貨時間是否符合要求。6) 報關單、保修卡和說明書等校驗。驗收小組檢驗設備的保修卡和說明書等資料是否準確無誤,另外,對于進口設備需要檢查設備的報關單是否正確和有效。7) 集成調試。到貨驗收合格后,供應商進

51、行設備的集成調試工作。8) 試運行驗收。俗稱試車驗收,在供應商完成設備的集成調試后將提請進行試運行驗收,驗收小組需要根據(jù)驗收內容逐項進行相關驗收。9) 軟件系統(tǒng)功能驗證。軟件使用部門根據(jù)需求或驗收內容和標準,對軟件系統(tǒng)功能進行詳細驗證測試,驗收小組監(jiān)督和匯總測試情況。10) 軟件系統(tǒng)性能驗證。信息技術部從技術的角度,對系統(tǒng)進行性能等技術測試,驗收小組監(jiān)督和匯總測試情況。11) 資料驗收。驗收小組根據(jù)驗收準備階段的要求逐項核對資料的提交情況,資料包括合同中要求的程序源代碼、操作手冊、培訓資料、測試報告、過程數(shù)據(jù)等。12) 綜合評議。驗收小組匯總該項目本階段各種驗收資料,對項目的驗收情況進行集體評

52、議。13) 檢驗驗收情況。驗收小組將根據(jù)綜合評議情況,判斷是否驗收合格,對于不合格的部分提出整改意見。14) 進行整改。如果本次驗收沒有通過,則供應商需要根據(jù)驗收小組的要求進行相關整改。15) 復驗。當供應商完成整改后,驗收小組將組織復驗。16) 檢驗初步驗收是否通過。如果本次驗收通過,驗收小組將檢驗初步驗收涉及的各階段驗收是否完成,如果初步驗收完成,將進入正式運行階段;如果還存在后續(xù)驗收階段,將重復5至19的步驟,直至所有子系統(tǒng)驗收合格。對于一些國家或監(jiān)管部門有相應法規(guī)約束的特殊項目,是否通過相關外部驗收將是項目初驗合格的基礎,如機房工程需要通過消防局、電力等部門的驗收,網(wǎng)絡系統(tǒng)需要通過保監(jiān)

53、會的驗收等。4.4 最終驗收IT項目通過初步驗收后,將投入生產運行,由于有些問題可能需要在生產環(huán)境運行一段時間后才能暴露,最終驗收就是需要解決這些問題。一般在最終驗收通過后在進行質保金的支付。1) 正式運行系統(tǒng)。IT項目通過初步驗收后,將投入生產運行。2) 最終驗收。當系統(tǒng)運行一段時間(一般在合同中明確)后,驗收小組將匯總各使用部門的驗證情況或驗收小組組織全面的驗收。3) 檢驗最終驗收是否合格。驗收小組將根據(jù)驗收情況出具驗收結論。4) 進行整改。如果驗收不合格,供應商將根據(jù)驗收小組的整改意見進行整改。5) 復驗。供應商完成整改后,驗收小組將根據(jù)項目的實際情況進行復驗。4.5 報告總結IT項目通

54、過最終驗收后,驗收小組將根據(jù)驗收情況撰寫驗收報告,同時將總結驗收工作的得與失,以便未來更好的運作其他項目。1) 撰寫驗收報告。如果最終驗收通過,驗收小組將根據(jù)驗收情況撰寫驗收報告,驗收報告不僅需要包括本次項目驗收的情況總結,也需要總結本次驗收工作的得與失。2) 領導審批。驗收小組撰寫的驗收報告,將交分管領導審批,如果不合格將打回驗收小組修改。3) 歸檔處理。驗收報告通過領導審批后,將交辦公室進行歸檔處理,同時將相關資料交還原部門,如硬件設備保修卡交還信息技術部,操作手冊交還業(yè)務部門。5、 質量記錄:驗收報告第七章 研發(fā)部培訓管理制度1、 目的:為了規(guī)范和促進技術研發(fā)部的員工培訓工作,提升技術研

55、發(fā)人員的職業(yè)技能和素質,提高公司的技術研發(fā)水平,從而提高公司的實力,特制定本制度。2、 范圍:本制度適用于公司技術研發(fā)部的所有員工。3、 職責3.1 人力資源部是技術研發(fā)人員培訓工作的歸口管理部門,負責培訓活動的計劃制訂、實施和控制。3.2 技術研發(fā)部、生產部等相關部門負責協(xié)助人力資源部進行培訓的實施與反饋評價工作,負責組織部門內部的培訓活動。4、 程序:4.1 培訓類別與內容技術研發(fā)部的培訓類別包括新員工培訓、崗位技能培訓、轉崗培訓等,具體如下表所示。技術研發(fā)人員培訓分類與內容一覽表培訓類別培訓對象培訓目的培訓內容培訓方式新員工培訓新員工為幫助新員工盡快了解和熟悉公司,盡快融入公司環(huán)境和進入工作角色1公司概況、企業(yè)文化組織結構、管理層人員2公司發(fā)展戰(zhàn)略、方針3公司各項規(guī)章制度4所任職位業(yè)務知識與技巧授課、參觀、操作指導崗位技能培訓在崗員工為增強員工技能,提高工作質量和效率,減少工作失誤1崗位技能2相關知識技能拓展授課、操作指導轉崗培訓崗位調動人員為工作輪換、橫向調整和晉升作準備1新崗位基本情況2新

溫馨提示

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

最新文檔

評論

0/150

提交評論