【自考复习】01336软件项目管理(一).docx
- 文档编号:11606087
- 上传时间:2023-03-22
- 格式:DOCX
- 页数:33
- 大小:155.11KB
【自考复习】01336软件项目管理(一).docx
《【自考复习】01336软件项目管理(一).docx》由会员分享,可在线阅读,更多相关《【自考复习】01336软件项目管理(一).docx(33页珍藏版)》请在冰豆网上搜索。
《软件项目管理》复习概要
第1章
1、 项目的基本特性:
独特性、一次性、组织性、生命期、目标冲突性、资源消耗性、后果的不确定性。
2、 IT软件项目管理和其他项目管理相比,具有的独特性:
生产无形的产品;过程没有明显的划分;大都是“一次性”的人力消耗型项目。
3、 软件项目开发的主要阶段:
需求分析、概要设计、详细设计、编码、测试、安装及维护。
4、 项目成功的三个主要因素:
范围、时间、成本。
第2章
1、 工作分解结构的两个重要特征:
“分解”和“图表表示”。
2、 廿特图是表示项目各阶段任务开始时间与结束时I'可的图。
用水平线段表示阶段任务;线段起点和终点分别对应于任务开始时间和结朿时间;线段的长度表示完成任务所需的时I'可。
3、 关键路径法(CPM)是TT软件项目管理中最常用的一种数学分析技术,即根据指定的网络顺序、逻辑关系和单一的历时估算,计算每一活动(任务)的单一、确定的最早开始和最迟结束时间。
其核心是计算浮动时间,确定哪些活动的进度安排灵活性小。
不考虑资源约束。
主要应用于以往在类似项目中已取得一定经验的项目。
4、 计划评审技术(PERT)可以估计整个项目在某个吋I'可内完成的概率。
多应用于研究与开发项目,更注重对各项工作安排的评价和审查。
第3章
1、 瀑布模型:
是目前应用最广泛的一种“面向交付”的项目生命周期划分模型,主要包括五个阶段:
需求分析与定义、系统设计与软件设计、系统实施与单元测试、系统集成与系统测试、系统运行与系统维护。
提倡在开发过程的早期阶段冻结需求定义,可能导致开发出来的系统与用户实际需求不同。
2、 原型法:
是当前软件项H开发的重要方法,借助先进的软件开发工具根据用户提出的软件需求定义,快速建立一个软件系统的“原型”,向用户展示待开发软件的全部或部分功能,在征求用户对原型软件的意见后,反复进行修改、完善、提高和确认,最终实现项目的目标。
3、 螺旋模型“基于风险”,是瀑布模型的替代方法,主要由四个部分组成:
需求定义、风险分析、实现和评审。
实际上,螺旋模型就是这四个部分组成的迭代模型。
软件开发的过程每迭代一次,螺旋线就增加一周,系统就产生一个新的版本。
4、 在IT软件项目生命周期中有三个与时间相关的重要概念:
(1) 检查点:
是指在规定的时间间隔内对项目进行的检查与复审工作,它是通过比较实际进度与计划进度之I'可的差异,并根据这个差异来进行调整的。
(2) 里程碑:
完成阶段性工作的标志,不同类型的项目里程碑不同。
里程碑往往是一些重要活动的完工,或重要文档的交付,或阶段评审的通过。
(3) 基线:
指一个(或一组)配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。
基线其实是一些重要的里程碑,但相关交付产品要通过正式评审并作为后续工作的基准和出发点。
5、 在1T项目的整个生命周期中,一般存在四个主里程碑:
目标里程碑、设计里程碑、开发里程碑、产品版本里程碑。
6、 项目管理川的风险管理要求不停地关注软件开发工作屮的所有相关活动。
定期状态评估就是一种有效的管理活动,按照规范的时间问隔进行相应的评估,定义工作的进度和质量指标,确保对项目进展情况的关注,使所有项目干系人之问可以在一种开放的氛围屮进行交流。
第4章
1、 IT项目可行性研究:
就是从技术、经汛社会和人员等方面的条件和情况进行调查研究,对可能的技术方案进行论证,以最终确定整个项目是否可行。
其内容包括:
(1) 技术可行性分析。
是指在当前的技术、产品条件的限制下,能否利用现在拥有的以及可能拥有的技术能力、产品功能、人力资源來实现项目的目标、功能、性能,能否在规定的时间期限内完成整个项目。
一般应考虑:
进行项目开发的风险、人力资源的有效性、技术能力的可能性、物资(产品)的可用性。
(2) 经济可行性分析。
主要是对整个项目的投资及所产生的经济效益进行分析,具体包括支出分析、收益分析、投资回报分析以及敏感性分析等。
(3) 运行环境可行性分析。
从用户单位(企业)的管理体制、管理方法、规章制度、工作习惯、人员素质(甚至包括人员的心理承受能力、接受新知识和技能的积极性等)、数据资源积累、硬件(包含系统软件)平台等多方而进行评估,以确定软件系统在交付以后,是否能够在用户单位顺利运行。
(4) 其他方面的可行性分析。
主要指法律可行性、社会可行性等方面的可行性分析。
2、 可行性研究分为三个基本阶段:
(1) 初步可行性研究。
一般是在对市场或客户情况进行调查后,对项FI进行的初步评估。
(2) 详细可行性研究。
是在项目决策前对项目有关的技术、经济、法律、社会环境等方面的条件和情况进行详尽的、系统的、全面的调查、研究、分析,对各种可能的技术方案进行详细的论证、比较,并对项目建设完成后所可能产生的经济、社会效益进行预测和评价,最终提交的可行性研究报告将成为进行项目评估和决策的依据。
(3) 编写可行性研究报告。
编写一份关于IT软件项H的可行性研究报告。
3、 效益的量化及计算方法主要有四种:
(1) 函数求解法。
直接建立软件项目与效益Z间的函数关系。
能建立函数关系的多为直接效益或显性效益。
(2) 相关关系法。
适用于软件项目与效益之间不能建立函数关系,但有明显的相关关系。
可按数理统计规律,应用最小二乘法找出最佳拟合曲线或直线,从而得到效益计算函数。
(3) 模糊数学法。
适用于软件项目与效益之间没有明显的相关关系,但隐约存在一些可意识到的模糊事项和模糊量值(未能准确判定定性和定量关系),可据此确定一些指标来评价项目,并授予权值进行打分,这样就把没有定性关系的问题,进行量化而变为可定量的问题予以评估计算。
(4) 专家意见法。
综合多个专家的意见进行评估。
在实际计算中,还有常见的、更简便实用的计算方法:
成本降低法、利润增加法。
4、 在做项目投资分析时,应当遵循一个基本原则:
当预计的回收期超出企业能接受的回收期时或者在规定的回收期内不能收回投资的项目时,此时预计的应当放弃;而只有回收期小于企业的预计时,才可以接受该项目。
5、 计算回收期的方法
(1) 静态投资回收期。
就是用项目各年的净收入来将全部投资回收所需要的年限。
这是最常使用的评价指标,具有直观、简单的特点,也能反映项目风险稈度,但没有考虑资金的时 I'可价值。
(2) 动态投资冋收期。
是一种考虑资金的时间价值基础上计算的投资冋收期。
一般按净现值来计算。
(3) 差额投资冋收期。
是利用差额分析法,考虑投资额不等的两种方案收益和投资差额的投资回收期,即用两种方案收益差额将投资差额回收成所用的年限。
第5章
1、1T软件项目计划管理,是指为1T项目的运作和IT项目活动的管理提供一个可靠的实施基础和可行的工作计划的过程。
其目的是为了更好地实施软件工程和管理软件项目制定合理可行的计划。
2、 IT软件项目计划管理主要通过一系列计划活动来体现,这些活动包括:
(1) 明确项目目标。
项目具有多目标的特性。
项目的三个最基本的目标:
时间、成本、技术性能。
确定项目目标的基本原则:
定量化原则、个人化原则、简单化原则、现实性原则。
——项目目标确定的结果一般是形成项目的目标文件,也可以用层次结构图表示。
(2) 确定项目范围。
项冃范围包括项目的最终产品或者服务,以及实现该产品或者服务所需要执行的全部工作。
项目范围管理的首要任务是界定项目所必须包含且只需要包含的全部工作。
(3) 进行项目工作结构分解。
(4) 活动定义及估算。
(5) 编制项目计划。
(6) 确定项目进度安排。
3、 从多目标中找出最合理的方案,常用方法有:
(1) 极线图法。
——在极线图中,对于每个指标,最希望得到的结果应该绘制在远离原点的方向上,最不希望出现的后果则绘制在原点。
——在极线图中,最优方案是包括面积最大的方案。
极线图法屮,得到的最优方案可能是一个不可行的方案。
(2) 决策树法。
第6章
1、 IT项目的成本构成:
(1) 硬件成本。
主要包括实施IT软件项目所需要的所有硬件设备、系统软件、数据资源的购置、运输、仓储、安装、测试等费用。
(2) 差旅及培训费用。
(3) 软件开发成本。
是最主要的成本。
(4) 项目管理费用。
2、 项目成本管理的内容:
资源计划编制、费用估算、费用预算、不可预见费用、费用控制。
费用预算不同于费用估算。
费用估算是对项目各项工作所需要的费用的一个近似估计,而费用预算则将整个项目估算的费用分配到各项活动和各部分工作屮,进而确定项目实际执行情况的费用基准,产生费用基准计划。
3、 IT项冃成本的常用估算方法:
成本建模技术、专家判定技术、类比评估技术、Parkson 法则、自顶向下估算法、自下向上估算法、赢利定价法。
在一个大型的IT项目屮,通常要同时采用几种估算方法,如果不同方法得到的结果大相径庭,就说明没有收集到足够的成本信息,应该继续设法获取更多的成本信息,直到几种方法得到的结果基本一致为止。
4、 进行成本控制的结果是修订成本估算,更新成本预算,采取纠正措施,对项目完工重新进行估算等。
5、 成本控制的核心是管理好四个关键指标:
(1) TBC。
总预算成本。
即总投资。
(2) CBC。
累计预算成本。
即某时间点上的“总预算”。
(3) CACo累计实际成本,即某时间点上的“总投入”。
(4) CEVo累计实现价值。
即某时间点上的“总产出”。
第7章
1、 全血质量管理(TQM):
运用质量管理的科学理论、技术、方法,建立起贯穿于产品质量形成全过程的质量保证体系,使企业全体职工树立质量观点,提高工作质量,经济地生产用户满意的产品。
2、 全而质量管理要求企业成员具有强烈的质量意识,牢牢树立“质虽第一”的思想,建立三个基本观点:
(1) 系统的观点
(2) 向用户服务的观点,用户满意是第一原则
(3) 预防为主的观点,事前主动进行质量管理
3、 全面质量管理常用方法的理论基础是概率论和数理统计。
常用的方法有排列法、因果图法、控制图法、分层法、相关图法、统讣分析图法、不合格品统计法、缺陷位置调查表、频数分布统计表等。
而基本方法是PDCA循环法。
PDCA循环体现了全面质量管理的基本思想,也是全面质量管理的基本工作步骤和程序。
它把质量管理过程划分为计划P、执行D、检查C、处理A四个阶段八个工作步骤,强调按此顺序不断循环,以此来进行所有的质量管理活动。
4、 软件质量保证SQA就是向用户及社会提供满意的高质量的软件产品。
是确保软件产品在从生产到消亡全生命期的所有阶段中,达到所需要的质量要求而进行的有计划的、有系统的管理活动。
其目的是为管理部门提供对软件项目所用的过程和正被开发的产品适当的监控。
5、 软件项FI质量计划就是要将与项冃有关的质量标准标识出来,提出如何达到这些质量标准和要求的设想。
制定软件项目质暈计划的目的主要是确保项目的质量标准能够在项目的过程中得到满意的执行,使项目能够按期完成。
6、 编制项目质量计划的主要依据:
质量方针、范围描述、产品描述、标准和准则。
7、 实施项忖质量控制的主要依据:
项li的阶段工作成果、项li质量管理计划、操作描述、
8、 在项目质量控制过程中,产生的工作成果:
项H质量改进的措施、可接受的决定、返工、过程调整、检查表。
9、 评审是一种质量保证机制,它是借助一组人员来检查软件系统或相关文档并发现错误的一个过程。
(1) 评审类型:
设计或程序检查、管理评审、质量评审。
(2) 软件质量评审是软件项目管理过程中的“过滤器”,评审被用于软件开发过程中的多个不同的点上,起到发现错误(进而纠正错谋)的作用。
评审起到的作用是“净化”分析、设计和编码过程中所产生的软件工作产品。
在软件开发的各个阶段都要进行评审。
(3) 质量评审是项目质量管理过程屮的最后一个阶段。
10、 质量体系的结构要素由职责和权限、组织结构、资源和人员、工作程序、技术状态管理等组成。
第8章
1、 配置管理CM
(1) 目的:
建立和维护在整个软件生命周期屮软件项目产品的完整性和一致性。
(2) 主要目标:
使修改部分更容易被适应,并减少变化中所花费的工作量。
(3) 在软件项目开发中,软件开发过程的输出信息可以分为三类:
计算机程序、描述计算 机程序的有关文档、数据。
这些内容统称为软件配置。
2、 软件配置管理SCM是开发和维护各个阶段管理软件演进过程的一种方法和规程。
包括标识在给定时I'可点上软件的配置,系统地控制对配置进行的修改,并维护在整个软件生命周期中配置的完整性、一致性和追踪性。
(1) 软件配置管理的活动可归纳为四个主要方面:
配置识别、变更控制、配置状态统计、配置审核。
(2) 软件配置管理的主要目的:
建立和维护在整个软件生命周期中软件项目产品的完整性,同时还包括实施软件配置管理功能的实践。
(3) 实施软件配置管理应该包括•以下活动:
制定配置管理计划;变更控制;确定配置标识;系统整合;版本管理。
3、 所有配置项的操作权限都应当严格管理,基本原则是:
基线配置项向软件开发人员开放读取权限;非基线配置项向项目经理、CCB (配置管理委员会)及相关人员开放。
4、 要有效地进行配置管理,需要开展以下活动确定配置标识:
(1) 建立一个配置管理库作为存放软件基线的仓库;
(2) 标识置于配置管理下的软件工作产品;
(3) 根据文档化的规程,提出、记录、审查、批准和跟踪所有配置项/配置单元的更改要求和问题报告;
(4) 根据文档化的规程记录配置项/配置单元的状态。
5、 版本管理是软件配置管理的核心功能。
6、 系统整合是把系统的不同部分进行集成,使其完成一组特定的功能。
7、 配置状态报告就是根据配置项操作数据库中的记录,来向管理者报告软件开发活动的进展情况。
报告应该是定期的,并尽量通过CASE工具自动生成。
应着重反映当前基线配置项的状态,以作为对开发进度报告的参照。
8、 配置审计的主要作用是作为变更控制的补充手段,来确保某一变更需求己被切实地执行和实现。
9、 项目经理是整个软件研发活动的负责人,在配置管理活动中,其主要工作是根据软件呪置控制委员会的建议,批准配置管理的各项活动并控制它们的进程。
其具体职责包括:
(1) 制定和修改项目的组织结构和配置管理策略;
(2) 批准、发布配置管理计划;
(3) 决定项目起始基线和开发里程碑;
(4) 接受并审阅配置控制委员会的报告。
10、 软件测试的方法和技术:
黑盒测试法(-•般称为功能测试或数据驱动测试,在测试过程中,把系统看成是一个黑盒子,不考虑程序的内在逻辑,而是只根据需求规格说明书的要求来检查程序的功能是否符合它的功能需求说明)、白盒测试法(又称为结构测试或逻辑驱动测试,在测试过程中,允许测试人员对程序的内部逻辑结构及有关信息来设计和选择测试用例,对程序的逻辑路径进行测试)。
11、 Alpha测试是由一个用户在开发人员的现场进行的,软件是在开发人员对用户的指导下进行测试的,开发人员负责记录错误和使用中出现的问题。
Beat测试是由软件的最终用户在一个或多个用户的场所进行的,开发人员通常不在现场,由用户记录测试中遇到的问题,并定期的把这些问题反馈给开发人员。
第9章
1、 IT软件项目维护主要包括以下工作:
(1) 完善性维护:
在不改变系统整体功能的前捉下,提高和改善某部分的功能。
(2) 适应性维护:
调整系统使之能适应一个已经发生变化的系统环境。
(3) 纠错性维护:
纠正以前未发现的系统错误。
2、 编码阶段的错误修改起来成本相对便宜,则设计阶段的错误则相对昂贵。
这是因为设计错误可能涉及到不同模块的重新设计与编码等工作;需求定义错误的维护成本则最大,因为这意味着要重新进行需求定义、系统设计及编码等。
3、 绝大多数维护过程的发生都是由于用户或者管理上需求的变化而触发的。
错误修复只是维护活动的一小部分工作。
4、 维护成本大的一个最主要原因:
系统发布后,用户需求和管理工作的变化,很可能导致整个系统都需要重新设计。
第10章
1、 在软件过程中产生的文档只有产品文档和过程文档两类。
(1) 产品文档包括用户文档和系统文档。
(2) 影响文档质量的因素:
文档标准、文档质量保证和有效的文档书写风格等。
(3) 软件项目文档对于项目开发的成功和项目的正常维护起着重要的保证和支持作用。
(4) 产品文档是描述正在开发的产品的资料。
可以分为从软件工程师开发和维护系统的角度描述产品的系统文档,以及主要以客户为对象描述产品的用户文档。
(5) 过程文档是指记录软件项目开发和维护过程的文档资料,项目的计划、进度、过程质量、组织及目标标准等都是过程文档。
2、 项目文档的结构一般要符合以下基本原则:
(1) 所有文档都应该有封面,用來标识该项冃文档的作者、制作时间、文档类型、配置管理、质量确保信息和文档的秘级、文档的摘要、关键字及版权信息等。
(2) 文档应分章节描述。
(3) 如杲文档包括许多细节性参考信息,就应该有附录。
(4) 文档应该有难点注释和详细说明。
3、 文档标准有三种类型:
过程标准、产品标准、交互标准。
4、 文档的准备分三个阶段:
文档制作、文档修改和文档产品发布。
5、 进行软件项目开发时,文档一般都应该包括、项目开发立项报告、项目分析报告(逻辑设计说明书)、项目开发设计报告(物理设计报告)、项目设计报告(程序设计说明书)、程序设计报告、项目测试报告(测试说明书)、项目使用及维护手册、项目开发总结报告等。
6、 项冃开发立项报告:
是在项H正式开发前,Ftl开发单位或委托开发单位提出要开发的新系统的目标、功能、费用、时间、对组织机构的影响等内容的屮请项目立项文档。
如果是本单位独立开发或联合开发,则称立项报告,用于向领导申请经费及支持等。
如果是委托开发,则以任务委托书或者开发协议(合同)的方式进行说明。
主要内容:
经费预测和经费来源、项目进度和完成期限、验收标准和方法、开始可行性研究的组织与预算。
7、 项IT设计报告:
在项目分析报告的基础上进行新系统的物理设计,并完成项目设计报告。
其主要内容:
系统总体结构、计算机系统配置方案、代码设计、文件/数据库设计、输入输出设计、汁算机处理过程设汁、接口及通信环境设计、安全保密设计、系统测试计划、培训计划。
8、 程序设计报告:
根据项目设计报告,进行程序设计工作。
程序设计调试通过后,再完成程序设计报告,以便为软件的调试和维护工作提供依据。
其主耍内容:
程序结构图、程序控制图、算法、程序流程图、源程序、程序注释及说明。
第11章
1、 风险的本质:
不确定性和损失。
2、 风险的不确定性范围包括:
发生与否不确定;发生的时间不确定;发生的状况不确定;发生的结果不确定。
3、 在进行IT项目风险分析时,重要的是要量化不确定性因素的不确定性程度,量化每个风险的损失程度。
4、 风险分析实际上就是贯穿在项目开发过程屮的一系列管理步骤,其中包括风险识别、风险估计、风险管理策略、风险解决和风险监控等。
5、 根据内容将风险分为:
技术风险、管理风险、组织风险、外部风险。
6、 风险的无形成本是指由于风险所具有的不确定性而使项目在风险发生前和发生后所付出的代价。
风险的有形成本包括风险发生吋造成的直接损失和间接损失。
直接损失是指人员、经费、设备等的直接流失;间接损失是指直接损失之外的人、财、物、知识等的损失。
7、 一般只有当风险的不利后果(损失)超过风险管理而付出的代价时,才进行风险管理。
8、 项目风险管理划分成风险分析和风险管理两个阶段。
风险分析阶段包括风险识别、风险估计、风险评价三部分;风险管理阶段主要包括风险规划、风险控制、风险监督三部分。
在项目实施中,只有根据风险管理计划対项目的风险实施监控,以确保项目的成功,这才是有效的风险管理。
9、 风险规划,主要是针对各种可能出现风险事件,制定各种风险应对计划和应对策略,并制定或选择一个风险规避的行动方案。
10、 风险控制,即实施风险规避的控制计划。
在控制过程屮,有时还需要修改项目计划,对项目经费、进度等进行调整。
处理方法主要有三种:
风险控制法、风险自留、风险转移。
11、 风险估计,又称风险预测,其冃的是估计风险发生的概率和对项目的影响力,识别项冃的重大风险并进行重点管理。
风险发生概率可以用数学模型、统计方法和人工估计进行分析。
从实际工作看,人工估计是比较实用的一种方法。
12、 应对风险的程序和方法主要有:
规避、转移、弱化、接受。
13、 常用的风险驾驭和监控方法:
风险审计、偏差分析、技术指标。
第12章
1、 项目人力资源管理就是根据项目的目标、项目活动进展情况和外部环境的变化,采用科学的方法,对项目团队成员的思想、心理和行为进行有效的管理。
2、 项目人力资源管理主要过程(阶段):
组织计划编制、人员获取、团队建设。
九项基本活动:
人力资源规划、招聘、解聘、筛选、定向、培训、绩效考核、职业发展、满意的劳资关系。
3、 优秀软件工程师应具备的能力:
压力的承受能力、适应能力、程序开发能力、学习能力。
4、 成功团队的共同特点:
(1)目标明确;
(2)组织结构和岗位明确;(3)工作流程和方法简明有效;(4)考核和评价标准明确公正;(5)组织纪律性强;(6)相互信任;(7)善于总结和学习。
5、 影响团队成员交流的主要因素:
团队规模;组织结构;成员地位和个性;工作环境。
6、 商业软件组织的基本构架:
(1) 软件工程过程机构SEPA帮助项目组建立项目过程并对项目过程进行周期性的评估,对过程的定义和维护负责。
(2) 项目评价机构PRA保证软件项目遵循所有的组织和商业个体的软件策略、惯例、标准,软件项目的经理有责任使软件项目满足合同盅求及其他的项目兼容性标准,并对SEPA负责。
(3) 软件工程机构SEEA负责自动化组织过程,维护组织的标准环境,训练项目使用环境,维护组织范围内的可重用资产。
(4) 基础设施机构提供人力资源支持。
第13章
1、 按项目的进展,项目收尾管理分为二种情况:
(1)项冃进展顺利到正常结束的时候,项目收尾工作包插项目移交验收和后评价两个阶段。
(2)项目由于某种原因提前完成或项目目标无法实现时,项目的收尾管理工作主要是进行项目终止。
2、 IT软件项目验收的大致流程:
调试/测试■由客户确认的初验证明■试运行■由客户确认的终验证明•项目后评价/维护。
3、 进行项FI的范围确认时,其依据主要有二个:
工作成果(即项目计划实施后的结果)、成果文档。
范围确认的方法主要是观测的方法。
4、 项目质量验收是依据质量计划屮的范围划分、指标要求以及协议中的质量条款,遵循相关的质量检验评定标准,对项目的质量进行质量认可评定和办理验收交接手续的过程。
质量验收的范围主要包括:
项目规划阶段的质量验收(主要检验设计文档的质量,同时项目的全部质量标准及验收依据也是在规划设计阶段完成的,因此,这个阶段的质量验收也是对质量验收评定标准与依据的合理性、完备性和可操作性的检验)、项目实施阶段的质量验收(主要是对项目质量产生的全部过程的监控。
要根据范围规划、工作分解和质量规划对每一个阶段和任务进行单个的评定和验收,然后根据各阶段和任务的质量验收结果进行汇总统计,最终形成全部项目的质量验收结果)。
5、 只有项目资料验收合格,才能开始项目软件产品的验收。
(1) 项目初始阶段应当移交的文档主要有:
项目初步可行性研究报告及相关附件、项目详细可行性研究报告及相关附件、项目方案及论证报告、项目评估与决策报告等。
(2) 项目计划阶段应验收移交的资料,大致应该有项目描述资料(范围
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 自考复习 自考 复习 01336 软件 项目 管理