




版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
海滨学院图书管理系统工程管理文档
目录
1.合同管理--------------------------------------------------------3
1.1合同------------------------------------------------------4
2.生存期----------------------------------------------------------5
3.需求管理--------------------------------------------------------6
3.1软件需求管理过程-----------------------------------------6
3.1.1需求规格----------------------------------------6
3.1.2需求变更管理------------------------------------7
4.任务分解--------------------------------------------------------7
4.1任务清单------------------------------------------------8
4.1.1功能分解清单-----------------------------------9
4.2WBS-------------------------------------------------------------------------10
5.规模估算------------------------------------------------------10
5.1直接本钱-------------------------------------------------10
5.2间接本钱-------------------------------------------------11
5.3估算的误差----------------------------------------------12
6.工程进度------------------------------------------------------12
6.1活动定义-------------------------------------------------13
6.2活动安料F---------------------------------------------------------------------14
6.3进度执行与优化------------------------------------------14
6.4工具使用--------------------------------------------------14
7.质量方案--------------------------------------------------------14
7.1软件工程质量方案-----------------------------------------15
7.2软件工程质量保证活动-------------------------------------14
7.3测试方案--------------------------------------------------15
7.4质量改善-------------------------------------------------15
8.风险方案-------------------------------------------------------15
8.1风险识别与评估--------------------------------------------15
8.2风险规划-------------------------------------------------16
8.3风险分析表------------------------------------------------16
8.4风险控制--------------------------------------------------16
9.团队管理--------------------------------------------------------17
9.1工程组织结构--------------------------------------------17
9.2团队沟通管理--------------------------------------------17
10.工程结束-----------------------------------------------------18
10.1工程终止-----------------------------------------------18
10.2结束方案-----------------------------------------------18
10.3收尾工作------------------------------------------------19
10.4工程总结------------------------------------------------20
第一局部合同管理
1.1合同
工程名称:海滨学院图书馆管理系统
•合同双方
甲方:海滨学院图书馆管理
乙方:IT工程团队
・协议形式
协议形式:技术合同
•供给的商品和效劳
供给的软件:乙方为甲方提供所需的“图书馆管理系统"应用程序
提供的效劳:乙方为甲方提供所需的口常维护和效劳器管理。同时对甲方用户提供使用指导。
提供的文档:乙方在交付软件时提供详细的软件规格说明书和使用文档。
安装效劳:乙方为甲方提供软件的安装。
公文处理:乙方负责将甲方提供的图书馆图书加载入系统并进行分类
维护协议:当甲方在使用该产品时,在正常操作的情况下出现BUG或系统错误,乙方免费为甲方
提供修复效劳以保障软件的正常使用。当由于甲方的错误使用等非软件原因导致出现
故障,乙方同样提供修复效劳。由于甲方拥有该软件的源代码所有权,因比甲方需要
承当局部维修和进一步开发的责任。当软件需要新的功能拓展或改版升级时,由双方
共同协商决定。
・软件所有权
该软件是由甲方向乙方定制,甲方拥有该软件的版权,乙方不能将该软件的任何版本卖个其他
客户。软件提交时,工程源代码的所有权自动移交到甲方,乙方不得擅自对源代码进行修改。
•环境
乙方在规定时间内完成任务。甲方要保证安装软件的硬件设备和合同初始规定一致,乙方只保
证软件和规定的硬件兼容。由任何一方的单方面原因导致的延期产生的费用,由该方面支付。
・客户承诺
乙方开发软件过程中,甲方通过人员协同乙方进行开发。该人员主要参与工程的规划设计和需
求分析、阶段性验收和总体测试。当工程出现需求变更时,对乙方进行详细的阐述说明C乙方不负
责这些人员提供食宿和联系设备.
•验收规程
2023年6月24日,乙方为甲方安装所需的软件。6月25日至6月31日甲方代表对产品进行
验收测试,并根据需求在6月30日前对产品提出更正请求。测试通过后,双方进行软件交付签字。
乙方对甲方进行软件使用讲解。
・标准
乙方在开发过程中必须遵守ISO12207关于软件生命周期和文档的标准。
・工程和质量管理
甲乙双方前三个月每月初进行一次进展会议,后三个月每两周周六进行进展会议。会议内容为
乙方向甲方提供最新进度的掩饰和下一阶段的工作安排和方案。甲方根据演示提出相应的整改意
见,并对下一步工作进行提出意见和建议。
•时间表
详细时间表见工程进度。此处略。
•价格和付款方式
软件总价为13W。合同签订后,甲方向乙方支付5万元定金。工程的第三个月,乙方按方案时
间表完成需求分析、系统分析、设计和完成系统的根本框架后,甲方向乙方支付8万元,该系统完
成后,甲方进行验收测试,在签字验收后完成后,甲方向乙方支付全款。
•其他法律要求及违约处理
当一方违约,一切责任由其本身承当。如果由任何一方的过失导致出现损失后的赔偿由双方协商决
定。
甲方法人代表:小王
乙方法人代表:小韩
签订地点:海滨学院院办公室
有效期限:2023年-2023年6月26号
第二局部工程生存期
工程的生命周期是描述工程从开始到结束所经历的各个阶段,最一般的划分是将工程分为“识别
需求、提出解决方案、执行工程、结束工程〃四个阶段,也就是通常所说的规划阶段、方案阶段、实施阶
段和完成阶段。本工程的需求明确,模块划分清晰,且要求软件具有较高的质量,因此本工程选择增量
模型来开发整个系统,这样可以循序渐进,防止一次投入太大的风险可以减少开发过程中用户需求的变
更有些增量可能需要重新开发。并采用V模型来保证每个增量的质量。
工程生存期模型如下:
图1.1
本工程中模型的应用
本工程共分为三个子系统,因此整个系统分为三个分量。其中,图书信息管
理系统是图书馆图书管理的根本,作为本工程开发的第一个增最:图书借还管理系统处理图书与读者之
间的关系,作为第二个增量;读者管理系统在该工程中比重最低,作为第三个增量。
一个工程50$以上的时间花在测试上,V模型表达了全过程的质量意识。本
工程中每一个增量的开发过程中都采用V模型来保证每个增量的质量。V模型大体可以划分为以下几个
不同的阶段步骤:需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收
测试。
V模型根本特点
简单易用
强调测试过程与开发过程的对应性和并行性
第三局部需求管理
3.1软件需求管理过程
海滨学院图书馆管理提出需求如下:
设计开发、安装调试并后期维护满足需求的“图书馆管理系统"应用程序。需要该程序为桌面应用
程序,进入程序后需要弹出图书主界面,该图书主界面需与计算机自身系统别离,不得覆盖,具有独立
窗口。
内部需有检索图书处理、图书信息管理、借书管理、还书管理、图书速览、读者信息管理6个主
要功能,每个功能需在主界面中有独立的快捷方式。每个功能的具体要求如下:
检索图书处理:1.当有人发起检索图书时•.作出应答
2.当检索出需求的的图书时,提示图书位置及信息
3.当没有检索检索出该图书时,提示该图书馆不存在该图书
图书信息管理:1.实现图书信息录入对图书信息进行入库
2.修改、删除等图书信息管理
3.对图书类别和出版社管理。
借书管理:1.图书编号及读者编号
2.借书日期
3.借书的期限
还书管理;1.图书编号及读者编号
2.还书日期,当还书日期超了借书的期限,系统自动给出提示。可以打印出应归还图
书的人名单。
3.超出期限的超一天该借书者扣一元
图书速览:可以通过该功能浏览本图书馆的新进图书和优秀推荐的图书。同时可以通过该功能阅览
图书信息等主流图书的信息
读者信息管理:1.借书的卡号及读者姓名
2.读者的身份及读者性别
3.读者借书情况。
3.1.1需求规格
•需求规格说明书
系统定义:“海滨学院图书管理系统〃应用程序
应用环境:Windowsxp;Windows7;Windows10;LINUX;
功能规格:检索图书处理(检索,显示图书信息,显示图书存放位置);图书信息管理
(录入图书,修改图书,删除图书,图书分类,图书的出版社);借书管理
(图书编号,读者编号,借书日期,借书期限);还书管理(图书编号,读
者编号,还书日期);图书速览(新进图书,优秀推荐图书阅览);读者信
息管理(借书卡号,读者姓名,读者性别,读者身份,读者借书情况)。
性能需求:保证海滨学校内部所有学生及老师同时登录效劳器时也不会因处理的信息
量过大而导致系统瘫痪。另必须保证系统的平安性,可以禁得住一般的黑
客袭击和内部作假。对账户有足够的保护措施以防账户被盗。操作简单明
了,提示明显,界面整洁大方。
实现约束:检索图书处理、图书信息管理、借书管理、还书管理、图书速览、读者信
息管理
质量描述:如需求所述的足够用户承载量;可靠的系统平安性;界面整洁大方。
系统目标:
根据以上的需求分析及用户的沟通,该系统要到达以下目标:
1)界面设计友好,美观。
2)数据存储平安,可靠。
3)信息分类清晰,准确。
4)强大的查询功能,保证数据查询的灵活性。
5)操作简单易用,界面清晰大方。
6)系统平安稳定。
本系统主要实现对图书馆信息的管理,主要可以分为两大块:图书信息的效劳系统和
图书的综合管理系统。图书的使用对象是借阅者,例如学生,教师;管理
者是海滨学院图书馆图书馆的管理员.因此根据这此信息,,木系统的主要
功能就是:实现图书馆图书信息的管理和维护,如用户信息管理,图书馆
规那么维护,新书入库,整理图书,修改图书信息和进行查询等;以及效
劳系统的图书信息查询,图书的借出和归还等功能图书管理系统为用户提
供充足的信息和快捷的查询手段.例如:检索迅速、查找方便、可靠性高、
存储量大、保密性好、寿命长、本钱低等。这些优点能够极大地提高图书
信息管理的效率,也是图书管理的科学化、数字化、正规化管理,与世界接
轨的重要条件。
签字认证:甲方(需方):海滨学院图书馆管理
乙方(供方):IT工程团队代表小韩
3.1.2需求变更管理
•需求变更
假设海滨学院图书馆管理向1T工程团队提出如下需求变更:
在显示主面做一个能显示访问当前系统在线的人员数量,方便管理员统计每天用书情
况。
•软件基线产品修改提交单
申请人:小李
申请日期:2023年6月16日
工程名称:“海滨学院图书管理系统”应用程序
修改内容:增加功能”显示在线访问人员数量〃,可之间与表中用户进行记录,不必
输入对方用户名
验证意见:同意变更
验证人:小张
验证日期:2023年6月17日
第四局部任务分解
4.1任务清单
4.1.1功能分解清单
1.“海滨学院图书管理系统〃应用程序
1.1检索图书处理
1.1.1检索图书,
1.1.2处理检索图书的信息,包括图书标题、关犍字等
1.1.3显示出图书具体信息,包括图书作者,出版社等
1.1.4显示图书陈列的位置
1.1.5界面
1.1.6单元测试
1.2图书信息管理
1.2.1录入图书
1.2.2修改图书信息
1.2.3删除图书
1.2.4对图书进行分类
1.2.5对图书出版社管理
1.2.6界面
1.2.7单元测试
1.3借书管理
1.3.1图书编号
1.3.2读者编号
1.3.3借书日期
借书期限
单元测试
1.4还书管理
1.4.1图书编号
还书日期
1.4.3单元测试
1.5图书速览
1.5.1新进图书展示
1.5.2优秀推荐图书展示
1.5.3界面
1.5.4单元测试
1.6读者信息管理
1.6.1借书卡号
1.6.2读者姓名
1.6.3读者性别
读者身份
1.6.6读者借书情况
1.6.7单元测试
1.7主界面
1.7.1界面
1.7.2后台数据传输
4.2WBS
海滨学院图书管理系统应用程序
•工程规划
1.合同签署
1.1需求分析报告&工程初步规划
1.2工程建议书
1.3合同草案
2.方案编制
2.1时间表
3.确认方案
•需求分析
1.需求开发
1.1需求探索
2.需求管理
2.1需求规格说明书
3.系统测试方案编制
•总体设计
1.策略确定
2.开发标准确定(具体分配方式见任务清单)
3.架构设计(具体分配方式见任务清单)
4.集成测试方案编制
•详细设计
1.接口设计(具体分配方式见任务清单)
2.模块设计(具体分配方式见任务清单)
3.单元测试方案编制
•实现
1.编码(具体分配方式见任务清单)
2.代码复核
3.单元测试
・测试
1.集成测试
2.系统测试
3.测试总额
4.缺陷跟踪
5.手册编写
第五局部规模估算
5.1直接本钱
本钱估算的方法有1.代码行、功能点、对象点。2.类比(自顶向下)估算法。3.自下而上估算法。4.
参数法估算法。5.专家估算法。
在这个工程中我们主要采取功能点估算法,同时融合进入其他的估算方法进行验证。用系统的功能
数量来测量其规模,与实现产品所使用的语言和技术没有关系的。
5.1.1根本公式
FP=UFC*TCF
UFC:未调整功能点计数
TCF:技术复杂度因子
TCF=O.56+0.01(suni(Fi)):Fi:0-5,TCF:O.56-1.35
本工程的功能点
UFC148+70+110=328
TCF-技术复杂度因子:
TCF=0.56+0.0.1*(5+4+3+2+1+5+3+2+2+3+5+4+3+3)
=0.56+0.01*45=LOU
功能点计算:
FP=UFC*TCFo
UFC=328o
TCF=1.01.
FP=328*1.01=331.28
人月数计算:
在本工程中,根据以往的经验使用经验导出本钱模型(面向FF驱动的)中的kemerer模型来计算人月
数。
Kemerer模型E=60.62X7.728X108FP\
带入本,1.程的实际数据E=60.62*7.728*10、331.28”170、32〔人月〕
直接本钱计算
直接本钱组成:开发本钱,管理本钱,质量本钱。
简易估算:
开发(工作量)规模:Scale(Dev)17().32(单位:人月)
管理、质量(工作量)规模:Scale(Mgn)=a*Scale(Dev)=170.32*20%=34
a:比例系数:例如:20%—25%
直接本钱=规模*人力本钱参数=204.32*0.15=30.6万元
人力本钱参数=1500/人月〔由于校内开发,本钱比拟低)
5.2间接本钱
间接本钱=规模*人力本钱参数*间接本钱系数(间接本钱系数=1.5—3)
本例中间接本钱=170.32*0.15*1.5=38.3万元。
估算本钱=直接本钱+间接本钱=30.6+38.3=68.9万元
5.3估算的误差
由于根底数据缺乏,缺乏经验的估算人员,签约前后不连贯,低劣的推测技术,估算对需求的敏感性等
一系列原因,可能会引起估算的误差。对此工程的人月数定义考虑误差如下
估算170个人月+40-25
+15人月:需求变更-15人月:IT工程小组的晚上时间的利用
+5人月:IT工程小组出差70人月:工程小组采取奖励措施
+20人月:IT工程小组回家
最正确情况:145人月。
方案情况:170人月。
最坏情况:180人月。
第六局部工程进度
工程进度管理是指在工程实施过程中,对各阶段的进展程度和工程最终完成的期限所进行的管理。
是在规定的时间内,拟定出合理且经济的进度方案(包括多级管理的子方案),在执行该方案的过程中,
经常要检查实际进度是否按方案要求进行,假设出现偏差,便要及时找出原因,采取必要的补救措施或
调整、修改原方案,直至工程完成。其目的是保证工程能在满足其时间约束条件的前提下实现其总体FI
标。
工程进度管理是根据工程工程的进度目标,编制经济合理的进度方案,并据以检查工程工程进度方
案的执行情况,假设发现实际执行情况与方案进度不一致,就及时分析原因,并采取必要的措施对原工
程进度方案进行调整或修正的过程。工程工程进度管理的目的就是为了实现最优工期,多快好省地完成
任务。
工程进度管理是工程管理的一个重要方面,它与工程投资管理、工程质量管理等同为工程管理的重
要组成局部。它是保证工程如期完成或合理安排资源供给,节约工程本钱的重要措施之一。
6.1活动定义
海滨学院图书管理系统应用程序
•工程规划
1.合同签署
1.1需求分析报告&工程初步规划
2.1工程建议书
3.1合同草案
2.方案编制
2.1时间表
3.确认方案
•需求分析
1.需求开发
1.1需求探索
2.需求管理
2.1需求规格说明书
3.系统测试方案编制
•总体设计
1.策略确定
2.开发标准确定(具体分配方式见任务清单)
3.架构设计]具体分配方式见任务清单)
3.集成测试方案编制
•详细设计
1.接口设计(具体分配方式见任务清单)
2.模块设计(具体分配方式见任务清单)
3.单元测试方案编制
•实现
1.编码1具体分配方式见任务清单)
2.代码复核
3.单元测试
•测试
1.集成测试
2.系统测试
3.测试总额
4.缺陷跟踪
5.手册编写
6.2活动排序
甘特图
关键路径是决定工程完成的最短时间,关键路径上的任何任务都是关键任务,关键路径上的任何活动延
迟,都会导致整个工程完成时间的延迟.
在这个工程中首先按照时间顺序计算最早开始时间和最早完成时间,然后按照逆时间顺序计算最晚开始
时间和最晚结束时间。
从而得出关键路径是:
开始-》需求分析一》详细设计-》编码-》测试。
6.3进度执行与优化
在工程的进行过程中可以通过1、分解关键任务2、给任务增加资源3、缩减关键任务的工期4、重叠或
延迟链接任务5、设置日历增加工作时间6、通过分配加班工时来缩短关键任务来到达缩减工程工期
的目的。
6.4工具使用
在整个工程中将使用Microsoft的工程管理软件产品microsoftproject2023和Visio2023来进行工
程的管理
第七局部质量方案
7.1软件工程的质量方案
7.1.1工程经理的职责
1.评审质量方案。
2.与质量保证人员一起协商不符合项问题的纠正措施,并安排资源实施纠正措施。
3.定期或事件驱动地评审质量保证活动和结果。
7.1.2质量保证人员的职责
1.负责工程实施过程中对工程实施情况进行监督,包括对工程实施过程和工作产品进行监督检查。
2.制定质量保证方案书。
3.按方案实施审计活动,依照质量保证方案执行评审/审计,并记录执行中发现的不符合项。
4.对不符合问题提交不符合项报告,跟踪并验证纠正措施的执行情况。
5.对工程内不能解决的不符合项问超:向高层管理提交报告。
6.向工程经理报告工程质量工作状况和质量度量结果。
7.定期向工程组报告质量活动的结果“
8.制定质量保证的过程改良方案,记录过程数据。
7.1.3质量目标
1)基于需求的测试覆盖率为100%。
2)软件功能测试用例通过率不低于95%。
3)每个阶段评审中发现的问题都己经解决或得到适当处理。
4)产品发布时不存在严重问题以及以上的缺陷。
5)严格满足合同的要求和规格
6)用户满意
7.1.4质量策略
为了保证提交给用户的产品是高质量的,实施过程中采取的质吊保证措施包括:1)将质量贯彻到日常的
工程进展过程中。
2)应该特别注意工程工作产品质量和早期评审工作,无论是质量保证还是质量控制,采取的策略都是
早期预防和早期排除缺陷。
7.2软件质量保证活动
7.2.1过程评审
工程严格按照组织定义的软件过程进行开发,过程评审的具体依据参照企业的过程标准,保证工程
中的所有过程活动都在实施范隹内。在每次评审之后,要对评审结果做出明确的决策并形成评审记录。
评审可采取文件传阅、评审会等形式进行展开。
质量保证人员负责对工程过程迸行监督,将发现的问题和解决情况在每天的晨会上通报,对没有解
决的问题迸行讨论,对不能解决的问题提交高级管理者处理。每个周末,进行一次配置管理审核,确认
配置管理工作是否正常进行。
问题报告
质量保证人员对「每次审计活动发现的不符合项,应该和工程经理协商不符合项的纠正措施并预定
完成日期,假设和工程经理存在意见分歧,质量保证人员可以_L报给高层管理者,由高层管理者决定最
后的措施。同时,不符合项在工程周例会中汇报。
质量保证人员有独立的汇报途径,日常的汇报途径如下:
1.将工程组内不能协调的问题汇报给高级管理者,由高级管理者协调解决。
2.将发现的问题通知工程经理,协调纠正措施。
3.将日常工作和过程数据汇报给质量经理,由其统一收集并进行统计。
7.3质量改善
为了到达更好的质量,现在制定质量改善要求:
1软件质量活动必须经过规划
2.软件质量活动规划必须明文规定
3.质量小组必须独立存在
5.必须有适当的经费
第八局部风险方案
图书管理系统工程风险管理是指通过风险识别、风险分析和风险评价去认识工程的风险,并以此为
根底合理地使用各种风险应对措施、管理方法技术和手段,对工程的风险实行有效的控制,妥善的处理
风险事件造成的不利后果,以最少的本钱保证工程总体目标实现的管埋工作。
8.1风险识别与评估
8.1.1风险识别是试图通过系统化地确定对工程方案的威胁,识别和可预测的风险。
8.1.2风险识别过程
输入-》标识风险-》按照一定标准对风险排序-》制定风险表
8.1.3根据“IT工程常常存在一些共同的风险源〃我刃根据以往经验制定了风险分析表。检查
表法是利用检查表作为风险识别的工具,是根据风险要素建立软件工程的风险条目列表,列表
中列出所有与风险因素有关的提问,可以使管理者集中识别常见的类型中的和可预测的风险。
8.2风险规划
目对风险分析的结果,为提高实现工程n标的时机,降低风脸的负面影响而制定风险应对策略和应对
措施的过程,即制定一定的行动和策略来对付、减少、以至于消灭风险事件。通常采取的措施有1"可避
风险。2.转移风险。3.损失控制。4.自留风险。
8.3风险分析表
通过对风险识别,风险评估,风险规划,我们制定了如下风险分析表。
风险分析表
排序输入风险事件可能性影响风险值风险应对措施
1最终用户图书管理60%60%50%1.尽力满足用户提
放弃该系员可能会由于出的需求。
统。操作该系统的2.界面尽可能的简
问题对整个系洁,明了。
统产生不好的3.应善于和客户交
情绪。流
2工程图书馆管20%6030%1.软件详细设计阶
期间,需求理如果增加功%段注意增加软件的
方增加功能将很大的增可重用性。提高复
能。加风险。用水平。
2.有效的沟通和协
调。
3客户需求不明60%40%36%1.采取加班的
的需求规确,增加需求,方法。
格说明。导致需求蔓延,2.修改方案去
由于本软件是掉一些任务。
不太了解计算3.当出现影响
机的领导使用,重大的变更需求时
变更需求可能与客户协调,增加
性很大。工程投入。
4合同进度要求紧,合35%55%25%可以进行少量
带来的限同金额有限。的加班,一来本钱
制。不高,二来可以加
快进度.。
5交付期限需方存在25%68%10%1.加班。
紧缩。紧缩交付期限2.邀请朋友帮助。
的可能。导致工3.调整工程的结
程交付不上。构。
6历史工程开发人员的流15%60%9%1.注意工程团队的
信息。动。沟通,及时了解开
发人员的动态。
2.控制好工程过程
中的文档。
3.从其他的工程组
借调人员。
7人员由于本工15%35%10%I.采取一带一帮,
缺乏经验。程中的一些员让有经验的程序员
工是大学实习带着相对经验少的
生,可能会缺乏程序员进行开发.
经验。2.开发工程之前适
当的岗前培训。
8用户由于学校20%20%20%1.防患于未然,数
数量超出可能增加招收据库上采用数据池
方案。学生,导致使用的技术在,增加并
人员激增。发访问量。
2.优化数据库
9工程可能有一10%10%10%1.我有开发经验的
技术达不些技术达不到工程经理请教。
到预期效预期的效果,不2.优秀的大学生请
果。能使需方满意。教当代新型技术。
如一些小的功
能不能实现等。
8.4风险控制
1.实施和跟踪风险管理方案,保证风险方案的执行,评估削减风险的有效性。
2.针对一个预测的风险事实上是否发生了,确保针对某个风险而制定的风险消除步骤正在合理
使用
3.监视剩余的风险和识别新的风险,
4.收集可用于将来的风险分析信息
第九局部团队管理
团队是一定有一定数量的个体成员和有志青年组织的集合,包括自己组织的人、供给商、分包商、
客户等为一个共同的目标工作,协调合作,最终开发出来高质量的产品。团队管理在整个工程的开发中
具有十分重要的作用
9.1工程组织结构
经过分析我们采用工程型的组织结构。结构图如下
此结构的优点:
1.工程监理对工程可以仝权负责。可以根
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
评论
0/150
提交评论