PPTOK :您身边最贴心好用的PPT站!

您当前所在位置:首页 > PPT课件 > 学校ppt > 高校大学PPT → 软件工程-需求工程ppt

软件工程-需求工程ppt

  • 素材大小:2.23 MB
  • 素材授权:免费下载
  • 更新时间:2017-01-08
  • 素材类别:高校大学PPT
  • 素材格式:.ppt
  • 关键提要:工学
  • 素材版本:PowerPoint2003及以上版本(.ppt)
网友评分:
PPT介绍优秀PPT相关PPT精品PPT

这是一个关于软件工程-需求工程ppt,主要介绍连接设计和构造的桥梁、需求工程任务、启动需求工程过程。欢迎点击下载哦。

PPT预览

软件工程-需求工程ppt

PPT内容

理解问题的需求是软件工程师所面对的最困难的任务之一。
客户不知道需要什么;
客户既使知道需要什么,这些需求在项目实施过程中也可能会改变。
需求工程可以帮助我们解决这些问题。
需求工程和其他软件工程活动类似,必须适应过程、项目、产品和工作人员的要求。
从软件过程的角度来看,需求工程是一个软件工程动作,开始于沟通并持续到建模。
根据实际情况选择需求工程内容,有时简单,有时必须执行所有的需求工程任务。
需求工程通过执行7个不同的活动来完成:起始、导出、精化、协商、规格说明、确认、管理。
注意:需求工程所有的努力都是为了确定客户想要什么,所有的工作都是为设计和构建客户希望的软件奠定一个坚实的基础。陈明.快乐老家:我所有一切都只为找到它。
泛谈起始。项目的开始有各种各样的情况。
在该阶段进行一些初略分析。并不是一切需求都可以被开展下去。
目的:对问题、方案需求方、期望方案的本质、客户和开发人员之间初步的交流、合作效果达成基本一致。
一般来讲,客户对需求的具体内容并不明确,需要不断交谈,诱导出新的任务需求。
导出需求是一件困难的事情。表现为:
范围问题。
理解问题。
易变问题。
扩展和提炼前两步的成果。该阶段集中于开发一个精确的分析模型,用来说明软件的功能、特征和约束。
精化的成果:一个分析模型,模型定义了问题的信息域、功能域、行为域。
应该和各方共同商讨分析模型的可行性。
客户和用户提的目标要求过高;
不同客户和用户提出的需求相互矛盾。
协商方法:
让客户、用户和其他共利益者对需求排序,按优先级讨论冲突;
识别、分析与需求相关的风险;
粗略“估算”开发工作量;
采用迭代方法删除、组合或修改需求。
规格说明(specification)描述前面的成果,用文字或其它方式。
对大系统来说,文档最好用自然语言描述和图形化模型来编写;
对技术环境明确的较小产品或系统,使用场景可能就足够了。
规格说明是需求工程师完成的最终工作产品。描述了一个基于计算机系统的功能和性能,以及那些将影响系统开发的约束。
正式技术评审是最主要的需求确认机制。
需求确认工作是检查规格说明以保证:
所有的系统需求已被无歧义地说明;
不一致性、疏漏和错误已经被检测出并被纠正;
工作产品符合为过程、项目和产品建立的标准。
需求管理是用于帮助项目组在项目进展中标示、控制和跟踪需求以及变更需求的一组活动。
跟踪表有多种,如:
特征跟踪表、
来源跟踪表、
依赖跟踪表、
子系统跟踪表、
接口跟踪表。
Inception—ask a set of questions that establish …
basic understanding of the problem
the people who want a solution
the nature of the solution that is desired, and
the effectiveness of preliminary communication and collaboration between the customer and the developer
Elicitation—elicit requirements from all stakeholders
Elaboration—create an analysis model that identifies data, function and behavioral requirements
Negotiation—agree on a deliverable system that is realistic for developers and customers
Specification—can be any one (or more) of the following:
A written document
A set of models
A formal mathematical
A collection of user scenarios (use-cases)
A prototype
Validation—a review mechanism that looks for
errors in content or interpretation
areas where clarification may be required
missing information
inconsistencies (a major problem when large products or systems are engineered)
conflicting or unrealistic (unachievable) requirements.
Requirements management
理想状况:客户和软件工程师都在同一个小组中工作。
下面讨论启动需求工程所需的步骤 。
共利益者/涉众:直接或间接从正在开发的系统中获益的人或机构
在需求的导出过程中,要明白从谁的口中去“导出”,即确定与需求有关的人群---共利益者。
共利益者的范围很广泛,有别于常规的理解。(这一点至关重要)如:业务操作管理员、产品管理人员、市场营销人员、内部和外部客户、最终用户、顾问、产品工程师、软件工程师、支持和维护工程师以及其他人员
捕获更多的共利益者:你认为我还应该和谁交谈?
不同共利益者所处的角度不同,观点各异,要善于总结这些观点。去除或弱化一些观点。
通常地讲,客户或用户的观点最重要。
求同存异,江山一统
Identify stakeholders
“who else do you think I should talk to?”
Recognize multiple points of view
Work toward collaboration
The first questions
Who is behind the request for this work?
Who will use the solution?
What will be the economic benefit of a successful solution
Is there another source for the solution that you need?
上一节中的Q&A形式在捕获初始需求有效,但无法捕获详细需求。
协同需求收集的基本原则:
会议由软件工程师和客户(连同其他的共利益者)共同举办、参与。
建议拟定会议议程。鼓励思维的自由交流。
由一个主持人控制会议。
使用某种“定义机制”(可以是工作表、活动挂图、不干胶贴纸或BBS等方式)
目标:
识别问题;
提出解决方案的要素,
协商不同方法;
确定一套基本的解决方案需求。
协同需求收集的基本原则:
会议由软件工程师和客户(连同其他的共利益者)共同举办、参与。
建议拟定会议议程。鼓励思维的自由交流。
由一个主持人控制会议。
使用某种“定义机制”(可以是工作表、活动挂图、不干胶贴纸或BBS等方式)
目标:
识别问题;
提出解决方案的要素,
协商不同方法;
确定解决方案的基本需求问题。
meetings are conducted and attended by both software engineers and customers
rules for preparation and participation are established
an agenda is suggested
a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting
a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used
the goal is
to identify the problem
propose elements of the solution
negotiate different approaches, and
 specify a preliminary set of solution requirements
需求收集会议流程:
共利益者写“产品需求”,在开会之前分发给与会者。
每个与会者开会之前做以下工作:
列出系统周边对象、系统产生的对象、系统用来完成功能的对象
列出服务操作或与对象交互的服务(过程或功能)列表
列出开发约束表(如成本、规模大小、业务规则)和性能指标(如速度、精确度)。
每个与会者提出自己的讨论列表。列表可以写在大纸上,或BBS上。(禁止批评、争论)
主持人开会协调、组合列表。
编写小规格说明,讨论细化小规格说明。
编写完整的规格说明草案。
需求收集会议流程例子:
第2步
需求收集会议流程例子:
第2步
需求收集会议流程例子:
第5步
QFD(Quality Function Deployment)是一种将客户要求转化成软件技术需求的技术。
顾客需求的KANO模型。卡诺博士(NORITAKI KANO)的质量模型有助于我们理解顾客需求。KANO模型定义了三种类型的顾客需求:基本型、期望型和兴奋型。
QFD(Quality Function Deployment)是一种将客户要求转化成软件技术需求的技术。
顾客需求的KANO模型。卡诺博士(NORITAKI KANO)的质量模型有助于我们理解顾客需求。KANO模型定义了三种类型的顾客需求:基本型、期望型和兴奋型。
基本型需求。基本需求是顾客认为在产品中应该有的需求或功能。在一般情况下顾客是不会在调查中提到基本需求的,除非顾客近期刚好遇到产品失效事件。按价值工程的术语来说,这些基本需求就是产品应有的功能。如果产品没有满足这些基本需求,顾客就很不满意;相反,当产品完全满足基本需求时,顾客也不会表现出特别满意。因为他们认为这是产品应有的基本功能。例如:汽车发动机发动时正常运行就属于基本需求。一般顾客不会注意到这种需求,因为他们认为这是理所当然的。然而,如果汽车不能发动或经常熄火,顾客就会对其汽车非常不满。
期望型需求。在市场调查中顾客所谈论的通常是期望型需求。期望型需求在产品中实一的越多,顾客就越满意;当没有满足这些需求时顾客就不满意。这就迫使企业不断地调查和了解顾客需求,并通过合适的方法在产品中体现这些要求。以汽车为例,驾驶舒适和耗油经济就属于期望型需求。
兴奋型需求。兴奋型需求是指令顾客意想不到的产品特征。如果产品没有提供这类需求,顾客不会不满意,因为他们通常没有想到这些需求;相反,当产品提供了这类需求时,顾客对产品就非常满意。兴奋型需求通常是在观察顾客如何使用你的产品时发现的。
应该认识到,随着时间的推移,兴奋型需求会向期望型需求和基本型需求转变。因此,为了使企业在激烈的市场竞争中立于不败之地,应该不断地了解顾客需求(包括潜在顾客需求),并在产品设计中体现这些需求。
在收集需求时,系统功能和特点的整体愿景变得具体起来。
但是,如果软件团队不清楚不同类型的最终用户如何使用这些功能和特征的话,很难进行更技术化的软件工程活动。
场景通常称为用例,描述系统将如何被使用。
系统规模不同时,需求导出后产生的工作产品不尽相同。对大多数系统而言,工作产品有:
必要性和可行性陈述;
系统或产品范围的界限说明;
参与需求导出的客户、用户和其他共利益者的列表;
系统技术环境说明;
需求列表(建议按照功能加以组织)以及每个需求适用的领域限制;
一系列使用场景。有助于深入了解系统或产品的未来使用情况。
任何能够更好定义需求的原型。
a statement of need and feasibility.
a bounded statement of scope for the system or product.
a list of customers, users, and other stakeholders who participated in requirements elicitation
a description of the system’s technical environment.
a list of requirements (preferably organized by function) and the domain constraints that apply to each.
a set of usage scenarios that provide insight into the use of the system or product under different operating conditions.
any prototypes developed to better define requirements.
Alistair Cockburn:一个用例捕获一个约定……即说明当对某个共利益者的请求响应时,在各种条件下系统的行为。
用例(Use-Case):A collection of user scenarios that describe the thread of usage of a system。描述系统使用情况的用户场景集合。
参与者(Actor):在系统之外与系统交互的某人或某事物。参与者只能位于系统边界之外,边界之内的所有人和事物都不是参与者。
定义:用例是一组动作序列的描述,系统执行该动作序列来为参与者产生一个可观察的结果值。
A use case in software engineering and systems engineering is a description of steps or actions between a user (or "actor") and a software system which lead the user towards something useful.[1] The user or actor might be a person or something more abstract, such as an external software system or manual process.
思考下面两个问题有助于找到参与者:
谁对系统有着明确的目标和要求并且主动发出动作。
系统是为谁服务的。
参与者可以是事物:
参与者也可能是事物,例如一个每天自动统计网站访问量报表的系统,这个参与者就是一个时间触发器。
参与者肯定是一个需求的启动者,如果找不到启动者,说明这不是一个功能性需求。
发现参与者
 参与者的一个重要来源是涉众(也称为干系人/共利益者,是与要建设的系统有利益关系的一切人和事,涉众不一定是参与者,但因为利益关系会对系统有影响)
参与者的另一个来源是客户的岗位设置。
要注意的是,参与者一定是直接并且主动地向系统发出动作并获得反馈的,否则就不是参与者。
参与者与涉众的关系。参与者是涉众的代表,涉众是系统的获利者,他可能不是参与者,但由于利益的因素影响着系统。
参与者与用户的关系。用户是指系统的使用者,通俗点说就是系统的操作员。并非所有的参与者都是用户。如,一个科室的主人负责行政审批,但他可能把工作交给他的秘书去做,但他是参与者而不是用户,他的秘书是这个系统的用户,一个用户可以代理多个参与者。
参与者与角色的关系。角色是参与者的职责,是一个抽象的概念,从众多单于着的职责中抽象出相同的恶意部分,将其命名形成一个角色。如,一个正处长和局长都可以审批文件,这时就可以抽象出审批者这个角色,他为系统带来很好的灵活性。一个用户可以代理多个参与者,因此一个用户可以拥有多个职责,也就是可以被指定多个角色。
总结:
参与者是涉众的代表,它代表涉众对系统的利益要求,并向系统提出建设要求;
参与者通过代理给其他用户或将自身实例化成用户来使用系统;
参与者的职责可以用角色来归纳,用户被指定扮演某个或某些角色,因此获得参与者的职责。
确认参与者后,就可以开发用例了。用例应该回答以下问题(Jacobson建议):
谁是主要参与者、次要参与者?
参与者的目标是什么?
故事开始前有什么前提条件?
参与者完成的主要工作或功能是什么?
按照故事所描述的还可能需要考虑什么异常?
参与者的交互中有什么可能的变化?
参与者将获得、产生或者改变哪些系统信息?
参与者必须通知系统外部环境的改变吗?
参与者系统从系统获取什么信息?
参与者希望得知意外之外的变更吗?
A collection of user scenarios that describe the thread of usage of a system
Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way
Each scenario answers the following questions:
Who is the primary actor, the secondary actor (s)?
What are the actor’s goals?
What preconditions should exist before the story begins?
What main tasks or functions are performed by the actor?
What extensions might be considered as the story is described?
What variations in the actor’s interaction are possible?
What system information will the actor acquire, produce, or change?
Will the actor have to inform the system about changes in the external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?
基本用例从较高层次给出参与者和系统之间交互的故事。
细化的用例可以为交互提供更详细的说明。如Cockburn建议使用如下模板详细说明用例:
7.5 开发用例 用例的层次
 7.5 开发用例 概要目标层
7.5 开发用例 用户目标层
用户目标层次
可以根据项目的实际情况开发用例模板。
详细说明用例的另外两个模板:
详细说明用例的另一个模板:
用例标识:用例的编号。
用例名称:根据用例表达的功能而取的简短明了的名称。用例命名其实是有讲究的,即必须是一个动词短语或句子,而不是一个名词短语,通常建议为一个动宾短语(如:提取存款),一个被动句(如:发票填报),或者一个主谓句(如:用户提款)。用例的命名表现了用例的特点,即它代表的是参与者的操作,是一个动作。尽量不要取 “××管理”或“维护××”,因为这个动作应当是一个非常明确的动作,而“××管理”代表的是插入、修改、删除等一系列动作,变得不明确了。
应用范围:就是要设计的系统。
用例类型:“用户目标”还是“子功能”,即是用户需要操作的目标功能,还是从“用户目标”中提取出来的“子功能”。“用户目标”应当至少有一个参与者,来驱动它完成相关操作,而“子功能”通常没有,因为它往往是被系统所驱动。
用例描述:对该用例的功能定义、要实现的业务需求,以及谁(参与者)如何进行使用进行描述。同时,这部分还可以整体概述实现业务需求的主要流程,以及与其它用例、其它外部系统的关系。
参与者:列出与该用例相关的参与者,包括进行操作的人(角色)和相关的外部系统。
 涉众利益:关注该用例的人对该用例的要求,它往往是非功能需求,或者是功能需求中的一些常常为我们所忽视的细节。如客户要求在填写一些表单的时候能够快速进行查找,而另一些系统管理员希望提高可维护性(虽然他们可能不是该用例的参与者)。编写涉众利益应当按照如下格式:使用数字编写序号,而每个涉众利益应当书写为“谁期望怎么样”。
 前置条件:在触发该用例相关操作前必须达到的条件。
事件流:是用例说明中最重要的部分,它详细描述了该用例可能出现的所有流程。
基本流程:又称为“主流程”或“主成功场景”,它描述的是该用例以最正常的方式流转,并且最终获得成功的流程。基本流程在编写时,应当通过数字,对流程中的每一步进行编号。
 扩展流程:又称为“替代流程”、“分支流程”或“交替场景”,它描述的是基本流程在流转过程中可能出现的所有分支。扩展流程在编写时,通常使用“数字+小写字母”对扩展流程进行编号。数字代表该扩展流程是在基本流程的哪一步发生分支的。如果是任意流程中满足某条件就会发生分支,则使用“*”代替。小写字母代表该扩展流程是本用例中的第几个扩展流程。扩展流程编号的后面应当描述进入该扩展流程的条件。最后,和基本流程一样,通过数字编号,详细描述该扩展流程的整个流程。如果在扩展流程中还会出现分支,则如上递归地描述该扩展流程的扩展流程。扩展流程和基本流程都是正常的流程,参与者期望或能预测的流程;如登机中有、无行李都是正常的情况(Think in UML P99),打印时取消或不取消打印都是参与者期望的流程。
 
  异常流程:故名思意,它是对该用例的所有基本流程和扩展流程可能出现的所有异常情况及其处理流程的描述。与扩展流程一样,异常流程首先通过“数字+小写字母”进行编号,描述出现异常的条件。如果是任意流程中都可能满足异常条件,则使用“*”代替数字。随后,编写出处理该异常的整个流程。按照以上步骤,罗列出所有可能出现的异常情况。异常流程是非正常的流程,不是参与者期望或能预测的流程;如登机中身份核对时错误,打印时缺纸或夹纸都可以看做异常流程。
 
后置条件:又称为“成功保证”,就是执行基本流程获得成功以后所达到的状态(条件)。后置条件往往体现的是执行该用例的最终目的。
 非功能需求:我们可以把它们简称为“URPS+”,即可用性(Usability)、可靠性(Reliability)、性能(Performance)、可支持性(Supportability)以及其它(+)。
 补充规格说明书:该用例对应的补充规格说明书。
 除此之外,用例说明还可以包括其它内容。比如,该用例是用于查询数据或展现一个表格,则应当画出数据的格式或表格的样式,并详细标注数据间的运算关系;如果客户对该用例有其它硬件或技术要求,可增加“技术与数据变元”项。
 
 在编写这部分说明的时候,还有一个非常关键的地方值得注意。当我们在编写事件流时,如果发现多个用例都出现相同或相似的流程,并且功能相对独立时,应当考虑将它提取出来单独形成一个用例。如果是这样,在原用例的这个地方只需说明在执行某个步骤时进入哪个用例就可以了,不用再描述这部分流程。如果原用例在基本流程中调用这个用例,则原用例包含这个用例;如果原用例在扩展流程中调用这个用例,则这个用例是对原用例的扩展。
 另外,异常流程也是一个非常重要的内容。过去我们在分析阶段没有考虑异常处理的情况,以致在开发阶段不知道怎样处理才能让客户满意。但值得提醒的是,这里的异常是站在业务层面的异常,如:“用户不能提供单据号”,或“用户未领取通知单”。而那些技术层面的异常不应当出现在这里,如“数据库连接失败”等。
编写用例说明的建议
按照过去RUP的设计思路,填写用例说明的时候,所有的项目都必须填写清楚完整,这是一个繁琐而令人沮丧的工作。然后,敏捷开发的思想出来了,我们都解脱了。敏捷开发的一个重要思想就是:我们只做我们需要做的事情,千万不要去做不需要做的事情(这也就是它称之为的“过度设计”)。用例说明只有几个项目是必填的:用例名称、用例描述、参与者、基本流程,其它都是可选项。
另一个重要的思想就是迭代,需求分析是一个逐渐推进的过程,因此千万不要想到把用例说明写得一步到位。在这个问题上,大师给我们了建议。Craig Larman在他的《UML和模式应用》中这样描述,他说用例的编写有三种常用形式:摘要、非正式和详述。
摘要,简洁的一段式概要,通常用于主成功场景,在早期需求分析中为快速了解主题和范围而使用,范例:
 处理销售:顾客携带所购商品到达收银台。收银员使用POS系统记录每件商品。系统连续显示累计金额,并逐行显示明细。顾客输入支付信息,系统对支付信息进行验证和记录。系统最终显示交易成功。
 非正式的,就是以一种非正式的段落格式,描述各个场景。它用于在需求分析逐渐深入的过程中使用。范例:
 处理退货
主成功场景:
顾客携带商品到收银台退货。收银员使用POS系统记录每件商品……
 交替场景:
如果客户之前使用信用卡付款,而其信用卡账户退还交易被拒,则告知顾客并使用现金退货;
如果在系统中未查找到该商品的标识码,则提示收银员并建议手工输入标识码。
……
 
详述,就是前面详述的完整格式,它主要用于需求分析后期以及最终需求确认的时候。即使采用详述的方式,也没有必要每个用例都写出每个项目。需要写的时候才写,不需要就不要写。即使需要写的内容,也是在需求分析逐渐深入过程中逐渐完成的。
系统用例 - ATM取款
分析模型从三方面表达客户的需求:信息域、功能域、行为域。
有多种分析模式。有人认为应选择一个模式(如用例)而排斥所有其他模式;有专家认为应使用多种模式描述分析模型,不同的表现模式迫使团队从不同角度分析需求——一种方法有可能造成需求遗漏、不一致和歧义。
将学习以下分析模型元素:基于场景的元素、基于类的元素、行为元素、面向信息流的元素。
Elements of the analysis model
Scenario-based elements
Functional—processing narratives for software functions
Use-case—descriptions of the interaction between an “actor” and the system
Class-based elements
Implied by scenarios
Behavioral elements
State diagram
Flow-oriented elements
Data flow diagram
基于场景的元素。从用户的视角描述系统,可以作为创建其他分析模型元素的输入。
用例:描述参与者与系统之间的交互。(7.5节已讲)
功能的:软件功能的处理描述。类似其他分析元素,功能(活动)可以在很多不同的抽象层次上描述。如下图,为导出需求描绘了一个UML活动图,显示了三个抽象层次的内容。
基于类的元素。
用例场景里隐含着一组“对象”,这些对象被分成类。
除了类图,其他分析建模元素描绘了类相互之间的协作、关联、交互。
行为元素。
基于计算机的系统行为能够对所选择的设计和所采用的实现方法产生深远的影响。
行为:对象的交互、状态和活动统称对象的行为可用行为模型表示。􀂋
行为模型:即动态模型,包括交互模型和状态模型。交互模型侧重刻画多对象间的交互关系。状态模型侧重刻画单个对象在其生命周期内的状态转移过程。
状态图是一种表现系统行为的方法。该方法描绘系统状态以及导致系统改变状态的事件。状态是任何可以观察的行为模式。另外,状态图还指明了在某个特殊事件后采取什么动作。
行为元素。
世界上的万事万物在任何特定时刻总处于某一特定状态。一个电梯可以处于上升、下降、停止状态。一辆汽车可以处于前行、后退、停止状态。一台电视机可以处于开机、播放、待机或关机状态。
面向信息流的元素。
我们可以为任何基于计算机的系统创建信息流模型。

争取“双赢”
Is each requirement consistent with the overall objective for the system/product?
Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?
Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?
Is each requirement bounded and unambiguous?
Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?
Do any requirements conflict with other requirements?
Is each requirement achievable in the technical environment that will house the system or product?
Is each requirement testable, once implemented?
Does the requirements model properly reflect the information, function and behavior of the system to be built.
Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system.
Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements?
作业

相关PPT

通信工程防护基本课程之设备环境防护案例ppt课件:这是一个关于通信工程防护基本课程之设备环境防护案例ppt课件,主要介绍通信设备防护的大致分类、了解通信设备运行环境的基本要求、掌握基本的防护原理、掌握常见问题的分析及处理方法。欢迎点击下载哦。
《通信工程概预算》课件ppt:这是一个关于《通信工程概预算》课件ppt,主要介绍通信工程概述 、通信建设工程与定额、通信建设工程费用定额、通信建设工程工程量计算、通信工程概预算的编制。欢迎点击下载哦。
《材料物理化学课件介绍》ppt:这是一个关于《材料物理化学课件介绍》ppt,主要介绍相与相平衡、相图、相变、晶体的成核和生长机理。欢迎点击下载哦。
《软件工程-需求工程ppt》是由用户似蜜餹于2017-01-08上传,属于高校大学PPT。

标签:

优秀PPT

缩略图

  • 软件工程-需求工程ppt

下载地址

  • 软件工程-需求工程ppt

相关PPT

推荐

颜色分类黑色PPT模板橙色PPT模板紫色PPT模板蓝色PPT模板黄色PPT模板红色PPT模板绿色PPT模板彩色PPT模板黑白PPT模板

行业分类科技PPT模板医学PPT模板教育PPT模板工业PPT模板金融PPT模板音乐PPT模板汽车房地产互联网培训手机

实用必备个人简历自我介绍年终总结职业规划述职报告工作汇报工作总结岗位竞聘公司简介发布会年会论文答辩

PPT推荐语文课件数学课件英语课件美术课件物理课件科学课件化学课件地理课件生物课件主题班会家长会绘本故事

节日PPT新年元旦节农历春节情人节元宵节三八妇女节愚人节清明节五一劳动节母亲节六一儿童节端午节

节日PPT 父亲节七夕情人节教师节中秋节国庆节重阳节万圣节光棍节感恩节平安夜圣诞节纪念日