第5章项目质量管理案例.docx
- 文档编号:29557795
- 上传时间:2023-07-24
- 格式:DOCX
- 页数:25
- 大小:42.33KB
第5章项目质量管理案例.docx
《第5章项目质量管理案例.docx》由会员分享,可在线阅读,更多相关《第5章项目质量管理案例.docx(25页珍藏版)》请在冰豆网上搜索。
第5章项目质量管理案例
第5章项目质量管理案例质量是“使实体具备满足明确或隐含需求能力的各项特征之总和”,明确或隐含的需求是指按项目需求制定的基础性文件。
在信息系统项目中,一般把《系统需求规格说明书》作为项目需求的基础性文件。
质量管理作为项目管理的一部分,具有非常重要的地位。
质量管理的目的是通过执行项目质量管理过程,使用一些基本项目管理工具和技术来保证信息系统的质量。
时间、成本、质量是项目管理的三大目标,如果质量不能满足要求,即使进度再快,成本再节省,项目也没有意义。
5.1案例一:
计划及跟踪阅读以下关于信息系统项目管理过程中质量管理方面问题的叙述,回答问题1至问题3。
5.1.1案例场景某银行信息系统工程项目,包含省级广域网工程、储蓄所终端安装工程、主机系统工程、存储系统工程、备份系统工程、银行业务软件开发工程等若干子项目。
此工程项目通过公开招标方式确定承建单位,希赛信息技术有限公司(CSAI)经过激烈竞标争夺,赢得工程合同。
合同约定,工程项目的开发周期预算为36周。
由于银行对于应用软件质量要求很高,CSAI也非常重视工程质量,安排有资深资历的高级工程师张工全面负责项目实施。
在工程正式开工之前,张工对工程项目进行了分解,根据工程分析,张工认为此工程项目质量、进度的关键在于银行业务定制应用软件的开发。
除工程整体的开发计划外,张工还针对应用软件开发制定了详细的开发计划,定制应用软件的开发周期为36周。
网络工程、终端安装工程、主机系统工程、存储系统工程、备份系统工程等与应用软件开发并行实施。
张工对工程项目在需求分析、概要设计、详细设计、编码、单元测试、集成测试等各个环节要求均非常严格。
根据张工安排,需求分析、概要设计均安排有多年工作经验的高级软件工程师担任,各个阶段的阶段成果均组织了严格的评审,以保证各个阶段成果的质量。
在软件编码及单元测试工作完成之后,张工安排软件测试组的工程师编制了详细软件测试计划、测试用例,包括集成测试、功能测试、性能测试、安全性测试,等等。
张工在安排软件测试任务的时候,在动员软件开发小组时宣讲:
软件测试环节是软件系统质量形成的主要环节,各开发小组,特别是测试小组,应重视软件系统测试工作”。
因此,张工安排给测试组进行测试的时间非常充足,测试周期占整个软件系统开发周期的40%,约14.5周。
在软件系统测试的过程中,张工安排了详细的测试跟踪计划,统计每周所发现软件系统故障数量,以及所解决的软件故障。
根据每周测试的结果分析,软件系统故障随时间的推移呈明显的下降趋势,第1周发现约100个故障,第2周发现约90个故障,第3周发现50个故障,„„,第10周发现2个故障,第11周发现1个故障,第12周发现I个故障。
于是张总工断言软件系统可以在完成第14周测试之后顺利交付给用户,并进行项目验收。
【问题1】请以300字内回答,张工的软件开发计划中是否存在问题?
为什么?
【问题2】请以200字内回答,张工根据对定制软件系统测试的跟踪统计分析结论,得出项目可于计划的测试期限结束后达到验收交付的要求,你认为可行吗,为什么?
【问题3】请以300字内回答,若你是本项目的总工,你将怎样改进工作,以提高软件系统开发的质量,保证工程项目按期验收?
5.1.2案例分析过去,很多IT集成公司所承建的定制软件工程项目,当进入到验收阶段的时候,用户常常拖延,或找这样那样的借口不给承建单位验收,这是什么原因呢?
针对这个问题,建设单位、承建单位都有一定责任。
对于建设单位来讲,由于建设单位对信息系统建设认识上的局限性,对软件系统质量鉴定的困难性,建设单位存在着对定制软件系统的质量的担心,因此,很难果断地做出验收项目的决定。
而对于承建单位来讲,承建单位在项目质量管理方面常常做得很不到位,比如:
该提交工程实施计划、工程实施计划进度跟踪记录、工程概要设计书、详细设计书、应用系统配置文件、用户手册、培训资料等若干文档的时候没有提交,而很多承建单位在项目验收时,根本看不到这些文档,或即使有文档,但也极其不规范,文档质量很低。
再比如:
曾有个信息系统工程项目在提交用户验收的时候,有一台防火墙散乱地摆放在机柜外面,再看机柜上面所布放的通信线缆,显得杂乱无章,承建单位也没有意识到这个问题,用户虽看在眼里却不提醒承建单位,那请问,用户会给这样的项目进行验收吗?
通过硬件所表现出来的表面质量是很容易发现的,但对于软件系统的质量的衡量却是非常困难的,特别是对于那些对软件系统认识不够深入的IT系统建设单位,他们面对IT项目的验收,常常显得很谨慎也是可以理解的。
信息应用系统项目的质量保证与承建单位的质量保证体系是密切相关的,但并不等于承建单位有质量保证体系,如通过了ISO9000认证,或通过了CMM3,CMM4等认证,就一定能够保证IT项目的质量。
承建单位的质量保证体系是一个大纲性质的,但实施项目的是项目小组,项目小组不能很好融合到承建单位的质量保证体系中是比较常见的现象,因此,为有效保证项目的质量,项目小组应当向建设单位或监理单位提交项目的质量保证计划。
质量保证计划是在承建单位质量保证体系下编制的,是针对项目特点的,涉及保证项目质量的具体措施,更易于操作。
当然,一个项目的质量保证计划如果照搬到另外一个项目,却不一定适用。
而建设单位、监理单位可以通过对承建单位质量保证计划的执行情况来判断其软件开发过程的质量,从而协助对定制软件产品质量的鉴定。
【问题1】软件测试是保证软件质量的重要工作内容之一,但软件测试环节却不是软件质量的形成环节,测试只能检查软件中所存在的缺陷,发现问题。
软件质量是在需求分析、设计、编码、测试、文档编制等软件生产的全过程中形成的。
因此,我们要了解定制软件系统的质量,就必须了解承建单位开发软件系统的全部过程的质量。
测试计划和测试用例应当在软件的设计阶段制定。
越晚进行的测试,其测试计划的编制时间就越早。
如集成测试计划在概要设计阶段编制,功能确认测试计划在需求定义阶段就应当制定,整体测试计划也应当在需求分析阶段制定。
虽然我们在实践中有很多这样的情况,很多软件开发团队并不是在软件设计阶段同步制定软件测试计划和测试用例,甚至有很多软件开发中根本就没有制定规范的测试计划和测试用例。
但这些并不是正统、规范的做法,这样的软件工程过程对于保证定制软件系统的质量来说是会打折扣的。
若测试计划的编制时机不能按照规范进行,那说明软件企业的过程能力成熟度还不够,还是在采用手工作坊方式生产软件,想到哪里做到哪里,没有计划或计划不科学,不能有效地控制软件生产的质量。
【问题2】软件系统的质量,仅仅根据测试的结论来进行断言是不够的。
我们在进行项目开发计
划安排的时候,应当将系统的试运行也安排在计划之内。
系统的试运行牵涉到工程项目的建设方和承建方,除了技术方面的因素外,还涉及组织方面的因素,人文方面的因素等。
承建方要安排足够的时间与建设方协商系统的试运行问题,在双方的配合下开展系统试运行工作,系统在试运行中,通常还会发现大量的故障,承建单位也必须配合解决这些系统故障。
只有通过试运行的考验,才能够基本断定系统的质量是否符合要求;通过了试运行的考验,再向用户提出工程项目的验收,一般来说,用户的接受程度会比较高。
软件系统的试运行为什么如此重要呢?
这是根据不同的工程项目的特点,如公路建设就不需试运行,住宅建设也不需试入住,通过质检方式就可确定工程项目的质量。
而另外一些工程项目则是必须要进行试运行的,比如铁路系统建设、水电站建设、化工厂建设等,这些类型的工程项目,不通过试运行,就不可能鉴定其质量,信息应用系统的建设也是一样。
【问题3】另外,在向用户提出项目验收前,还得整理并提交完整的工程技术文档、系统维护文档、软件配置清单,给用户举办系统操作培训、维护培训,全面审核合同执行情况,编制项目竣工报告,等等。
如果项目小组不注意这些工作,用户大多也不会来提醒你,用户只卡住验收关不让通过就可以了,当然也有部分用户可能会提醒项目小组离验收还差什么。
毕竟项目的实施任务是属于承建单位的工作,承建单位理应完善自身的项目管理水平,不可能让用户来督促你、提示你,那不是用户的职责,更何况,很多用户自身也不知道IT项目该怎样管理,有哪些工作需要完成,但承建单位很多不规范的做法、存在的问题,让用户对质量不放心,用户却是能够觉察到的。
特别要注意的是,项目经理在计划项目验收时,应当与用户的主要领导充分沟通,让客户领导了解项目的建设过程,了解项目的质量实施情况,让领导对项目的验收充满信心。
但请仔细分析本题,案例场景中通篇并没有提到关于工程文档、配置清单、培训等话题,这些内容并不是本题的关键,未提及的内容,张工可能没做到,但也可能做到,不好断言。
我们只要能够抓住场景所描述的张工的主要缺陷,一是制定测试计划的时机不对,二是根据测试断定软件系统的质量不对,只要能抓住这两点就够了。
其他的内容,也可以反映在答案中,但要注意语言要简练,虽不会导致扣分,但也不是得分的要点。
5.1.3参考答案【问题1】张工安排测试计划的编制时机不对。
测试计划和测试用例的编制应当与软件系统的概要设计、详细设计同步进行。
测试计划不够全面,还应当包含系统整体测试、运行测试。
运行测试是对应用软件系统整体功能的全面检验,也是最能够说明软件系统质量的测试环节。
系统测试计划、确认测试计划应当在需求分析阶段制定,测试用例、测试说明应当在概要设计阶段制定。
集成测试计划应当在概要设计阶段制定,测试用例、测试说明应当在详细设计阶段制定。
单元测试计划应当在详细设计阶段制定,测试用例、测试说明应当在编码阶段制定。
【问题2】在定制软件开发项目中,根据测试结果判定软件系统的质量是不够的,因为软件系统中的缺陷可能由于多种原因而未在测试中被发现,如测试环境与运行环境的区别、测试人员的能力问题、测试计划和测试用例的局限及缺陷。
由于软件系统质量、功能、性能具有很强隐蔽性的特点,用户往往不大可能根据项目开发小组的测试结论来进行项目的验收。
最好让用户组织对项目进行试运行,以试运行的结论来作为验收的依据之一是比较有说服力的。
【问题3】
(1)在进行需求分析的时候,同步制定功能确认测试计划和测试用例,同步制定系统整体测试计划和测试用例。
(2)在进行软件系统概要设计的时候,制定集成测试计划和测试用例。
(3)在进行软件系统详细设计的时候,制定单元测试计划和测试用例。
(4)在项目计划验收日期前,提前与用户协商系统试运行计划,并给用户进行充分的培训,包括领导和一般操作人员,让系统接受实际运行的考验,在试运行过程中暴露出来的问题,及时进行解决。
以软件系统实际运行所表现出来的功能、性能来说服用户对项目进行验收,这通常是更可行的方法。
5.2案例二:
团队协作阅读以下关于信息系统项目管理过程中质量管理方面问题的叙述,回答问题1至问题3。
5.2.1案例场景重庆市某行业关键应用IT系统(A系统)的建设工程由希赛信息技术有限公司(CSAI)中标,CSAI是国内一家大型IT系统集成商,企业通过了ISO9000质量体系认证和CMM3级认证,对信息系统工程建设有着比较成熟丰富的经验。
CSAI总部设在长沙,有软件研发中心。
CSAI为A系统建设所组建的项目小组由两个部分组成:
一是总部长沙负责进行软件开发工作;二是重庆现场负责进行信息系统的本地化实施,本地化实施的内容包括网络系统建设、主机系统安装调试、应用软件的运行环境建设、现场测试、客户需求跟踪、客户关系协调等。
其中,应用软件开发的管理工作由长沙软件中心负责,A系统的配置管理工作由现场负责。
CSAI对A系统应用软件开发的控制非常严格,可是,由于A系统在实施的过程中,用户不断地提出新的需求,催促要CSAI满足,而且,A单位的领导对进度非常关心,经常突袭检查,要求CSAI演示所建设的应用系统的功能。
CSAI现场项目经理李工也试图通过与用户进行沟通,以求解决需求的频繁变更问题,解决用户对进度的要求等。
CSAI对现场项目经理有关于维护良好客户关系的绩效考核指标,因此,李工不敢怠慢客户所提出的要求,但为了达到A用户所提出的需求变更、进度变更,李工想方设法让长沙研究所满足客户的需求变更,这样,长沙研究所的软件开发工作量就大大增加,而且,常常赶不上客户对项目进度的要求。
在寄托于总部无望的情况下,李工为了在工程进度方面满足用户的愿望,于是决定将部分应用软件系统代码在现场进行开发。
现场开发的目的主要是加快了软件开发的进度,李工的决定也确实很奏效,大大加快了应用软件开发的进度。
但是,当应用软件系统投入运行后,系统故障的发生频率却非常高,经过对故障的分析,李工发现,这些故障当中,由现场所开发的软件与长沙总部所开发的软件在协同工作中所暴露的问题尤为普遍,比如,现场所修改的软件代码,在长沙总部下发统一版本软件的时候常常被替换而丢失功能,A应用系统的本地化功能太多太偏而很难与统一版本融合。
另外,由于现场抽调人员参与应用软件开发,现场本应做的配置管理工作也被耽搁了,如网络系统的配置(设备访问权限、路由、IP规划等)、主机访问权限规划、应用系统访问权限规划、应用环境参数规划等,这些现场运行环境参数,按照B公司的管理制度,是应当编制文件存档的,但李工却没有安排人员来做这些工作。
由于网络系统庞大,中心机房设备繁多,参与工程建设的人员按照各自的习惯进行系统的配置,这样,在工程投入运行后,由于各部分配置的不规范,常常引起局部配置的变更
给系统运行带来严重事故。
曾经在一次配置变更过程中,由于应用系统密码的修改,导致系统停止业务半天,给用户造成了严重的损失和不良影响。
【问题1】请以300字内回答,李工对所遇到的问题的处理方法是否恰当。
李工所做出的决定的主要缺陷是什么?
造成问题的原因主要是什么?
【问题2】请以300字内回答,团队协同工作时,在软件版本方面会造成哪些问题,应当采取什么措施以避免问题的出现?
【问题3】请以300字内回答,在IT应用软件开发工程中,怎样进行项目现场与总部软件开发团队的有效配合?
5.2.2案例分析CSAI虽然通过了CMM3级认证、ISO9000认证,但CSAI的管理工作未必就能按照规范来开展,有不少公司只是将这些认证作为投标竞争时的砝码而已。
因此,我们在建设工程项目的时候,不但要看IT系统集成商具不具备这些认证,还应采取有效的手段考核IT系统集成商的质量保证计划。
对IT系统集成商进行考核,简便可行的方法就是让集成商在项目开工前提交质量保证计划,并对质量保证计划进行评审,通过后要求集成商严格执行。
通常,过程能力成熟度高(指实际)的IT企业,在实际工程与质量保证计划之间的一致性会完成得较好,而过程能力成熟度低的企业(指实际),实际工程与质量保证计划之间的一致性会完成得相对较差。
【问题1】我们都知道,信息应用系统的变更尤其频繁,而频繁的变更必然影响到信息工程项目的三大目标。
通常与客户接触最多的是现场项目经理,引导客户需求对项目经理就非常关键,项目经理引导得好,项目的开发就会非常顺利,反之,就会使项目组疲于奔命。
优秀的项目经理是既能够让项目组成员“睡大觉”,又能保持良好的客户满意度。
CSAI项目经理李工与用户的沟通存在问题。
善于沟通的人,一言明百理;不善于沟通的人,百言不明一理。
项目经理与客户的沟通,不是指项目经理善于说话,善于高谈阔论就能够解决问题,更为关键的是项目经理要具备足够的引导项目建设的能力。
作为现场项目经理,不是只做一个传话筒,客户说什么就是什么,而是应当与客户进行深入交流,深入分析客户所提出的问题,合理引导客户的需求,要有主见。
李工在CSAI进行客户满意度考核,客户又有大量需求的前提下,显得无所适从,手忙脚乱,而做出了不合适的决定。
一是客户的需求,只要我们能够合理引导客户,客户的需求变更不可能有那么频繁,有很多需求变更是可以让用户暂时放弃的,或有的需求变更可以让用户在另外的工程项目中去实现,比如建议用户建设=期工程。
我曾经见到一位项目经理在一个工程项目中,客户提出了一个需求,项目经理安排组员加班三天三夜完成了,告诉客户方主任,客户主任大吃一惊,说:
“我并没有要求你们实现这个需求啊,我只不过向你们咨询一下而已”。
客户与我们的项目经理交谈,并不是都谈需求,有很多时候,客户可能是谈到自己的想法、心得体会、建议等。
客户方面也往往有很多员工,一位员工有一种思想,十位员工就有十种思想,要统一这十种思想,项目经理就得付出更多的努力,要与用户方面的主管人员达成一致,而且,很多时候是必须要用户的主管人员去统一他们的意见。
否则,应用系统的开发就存在很大制约因素。
很多项目经理面对公司客户满意度的考核,面对客户无休止的需求,常常不能采取正确的应对方法,该说的不敢说了,该讲的不敢讲了。
应用软件工程在建设阶段,优秀的项目经理应当是能够引导用户思路的项目经理,而不是让用户领导项目经理的项目建设思路。
项目经理应当知道,任何一个客户都更注重项目建设的结果,在项目建设的过程中,项目小组与建设单位之间可能存在着很多次交流,甚至争论,但只要我们能确保项目建设的结果让用户满意,用户是终会给予好评的。
【问题2】二是对CSAI资源的利用不当,李工把本不属于现场的工作内容,让现场工程师来完成是严重的失误,现场工程师仓促上阵,没有纳入CSAI统一的软件开发质量管理体系。
虽然能够临时快速解决问题,但也会埋下故障隐患,而故障隐患的爆发却是在工程建设的后期。
这种做法只能让员工疲于奔命。
在项目管理中,如果项目组成员总是处于应急、救火的状态,是不可能高质量地完成工作任务的。
作为项目经理,不但要关心项目的进展,还应当关心自己的成员,要让项目小组成员在高效率、高质量的状态下工作。
三是忽略了现场应该做的重要工作,应用系统的配置管理工作对现场来说是很重要的。
混乱的配置管理,也会导致系统运行中发生严重的质量问题。
即使李工非要在现场进行开发不可,那也应当自觉地将现场所开发的软件,与公司总部所开发的应用软件进行统一的管理。
特别是要注意,现场开发的缺点是对需求的把握太随意,由于开发人员与用户直接接触,用户的想法可能有很多偏激的成分,也容易被现场开发人员设计到应用软件系统中,从而导致现场版本与统一版本难以融合,特别是对有些需求的满足,可能涉及到软件系统体系架构的变更,这样就更难处理了。
而现场临时决定的软件开发,管理工作怎样和总部的管理工作融合到一起,项目经理是应当考虑的,要么是由总部来控制,要么是现场自觉与总部配合。
【问题3】我们在工程现场实施的时候,对于所遇到的系统问题,有的是能够迅速解决的,也有暂时无法解决的。
对于暂时无法解决的问题,我们常常采取迂回的方式绕过去,以保证工程项目的进度。
但是对于应用软件系统的开发来说,现场不能只是绕过去而已,还应当及时向总部报告,应当建立一个系统故障管理平台,记录所有发现的软件故障,逐一报告研发中心进行解决,并跟踪解决情况。
为有效解决现场与总部的配合问题,可以建设一个基于Internet的开发管理平台,现场所遇到的问题,及时汇报到管理平台,由总部管理人员分配解决。
现场也可通过管理平台主动与总部沟通软件开发问题,协调一致,避免总部统一版本更新时丢失现场所开发的功能。
配置管理也是涉及到工程质量的。
我们做企业级的应用系统,都应当考虑到系统割接的平滑性,配置变更的平滑性,在进行配置规划的时候就应当考虑配置的变更怎样才能实现平滑过渡,否则,就很可能使运行的系统在进行配置变更的时候进入瘫痪状态。
而良好的配置管理,又是实现配置变更平滑过渡的有力支持。
5.2.3参考答案【问题1】现场用户的需求是不可能有尽头的,但作为项目经理要能够把握住用户的需求,特别是要合理引导用户需求,切不可让用户怎么说就怎么做。
积极响应客户需求要从多个方面着手考虑,不要只从技术上考虑问题,技术引导、合同变更、人力资源等各个方面都应当考虑。
临时的现场开发工作,大多数都不可能与公司总部的软件开发融为一体,而且管理工作常常是自上而下的,李工忽略了这点,顾此失彼,导致项目问题的发生。
造成项目问题的原因有以下几点:
李工对需求把握随意;控制不严;李工与客户沟通不到位;李工没有向客户提交合理的进度计划,或没有按时提交进度报告;项目实施无计划,或计划不能得到客户认可,客户不满意。
【问题2】团队协同开发软件时,很容易出现软件版本管理不善带来的软件系统故障。
同一软件系统代码不能同时由多人进行修改。
项目现场为应急而擅自更改软件代码,而常常没有将更改纳入统一的版本管理,很容
易造成总部发行新版本软件时,替换软件而丢失了现场所进行更新的代码,从而造成系统故障反复出现。
李工如果一定要进行现场开发,应当委托现场合适的人员,或亲自督促现场所进行的开发工作与总部所进行的开发工作在软件版本方面保持一致,处理本地过于偏激的需求要与总部协商一致的情况采取合理措施控制统一版本。
【问题3】项目现场应明确自己的工作职责范围,要自觉与总部门形成密切的配合。
现场所做的开发,应与总部所做的开发纳入同一个软件版本管理。
当现场发现软件故障时,应当及时向总部报告。
建立故障管理表,记录并跟踪软件系统故障解决情况。
建设一个软件开发交流平台,如基于Internet的管理平台,管理工程现场所提出的问题,调度、跟踪解决工程现场问题。
现场工程人员与总部人员应多交流,通过各种方式,如及时通信软件、电话、电子邮件等,必要时,可组织研发部给现场工程人员进行培训。
5.3案例三:
质量与成本阅读以下关于信息系统项目管理过程中工程质量问题方面的叙述,回答问题1至问题3。
5.3.1案例场景某行业省公司(A单位)信息应用系统工程项目(A项目)通过招标方式选择承建单位,希赛信息技术有限公司(CSAI以1800万元的标底获得A项目工程合同。
A项目包含1000万元设备采购安装和800万元软件开发费用。
其中设备采购安装预计有150万元利润,CSAI渴望通过A项目的建设能够获得600万元纯利润。
为了能够最大限度地获取利润空间,CSAI在组建项目小组,制定工程费用预算的时候,尽力压缩工程费用预算。
CSAI安排刘工担任A项目的项目经理,刘工在对项目进行工作分解的基础上,制订了工程实施资源计划,编制了项目实施预算经费。
根据刘工的预算,项目实施经费预算(人员工资、差旅费、会议费、行政管理费等)为220万元,其中人员工资占了很大比例,为150万元,CSAI领导在审核经费预算的时候,认为人员工资所占份额太大,CSAI要求刘工将人员工资预算减少为120万元,.并列入对刘工的绩效考核指标。
由于人员工资预算的减少,刘工面临两种选择,要么将招聘软件工程师的能力等级降低,要么减少项目组成员数量。
李工在权衡利弊后认为,项目组员工工资高,容易引起公司其他部门的忌妒,工作不好开展,于是,刘工只能采取降低项目组成员工资的方法。
为此李工所组建的项目小组有8人没有达到李工预期的技术资质等级。
A项目经过18个月(延期3个月)的建设周期,项目建设完成并交付用户使用。
CSAI也如愿以偿地获得了预期的利润,项目实施经费190万元,预提项目维护经费60万元(两年免费维护),商务费用50万元,超期3月赔偿A单位15万元,CSAI认为实现的利润635万元,已经达到了计划的目标。
项目验收交付使用后,CSAI为项目维护配备2位工程师,每位工程师工资加管理成本共计10万元/人年,其他辅助设备购置10万元/年。
但是,A项目的运行维护并不像CSAI想像的那样好,由于A项目定制软件的质量存在很多隐患、缺陷,如软件代码质量差,导致系统运行效率低;技术文件缺乏或文件与实际情况不相符,或技术文件纵向及横向对相应内容的描述不一致;这些问题使得A项
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 质量管理 案例