CMMI培训资料.ppt

上传人:laozhun 文档编号:2216866 上传时间:2023-02-01 格式:PPT 页数:183 大小:865.51KB
返回 下载 相关 举报
CMMI培训资料.ppt_第1页
第1页 / 共183页
CMMI培训资料.ppt_第2页
第2页 / 共183页
CMMI培训资料.ppt_第3页
第3页 / 共183页
CMMI培训资料.ppt_第4页
第4页 / 共183页
CMMI培训资料.ppt_第5页
第5页 / 共183页
点击查看更多>>
资源描述

《CMMI培训资料.ppt》由会员分享,可在线阅读,更多相关《CMMI培训资料.ppt(183页珍藏版)》请在三一办公上搜索。

1、CMMI介绍(一),CMMI Coordinator Team,June 14,2004,CMM/CMMI的来历,W.S.HumphreyDoD&CMU-SEI-CMM-CMMICapability Maturity Model Integration,CMMI的连续和阶段模型,阶段模型的组织,to Perform,Maturity Levels,Generic Practices,Generic Goals,Process Area 2,Common Features,Process Area 1,Process Area n,Ability,Implementation,Verifying

2、,to Perform,Commitment,Directing,Implementation,Specific Goals,Implementation,Specific Practices,to Perform,Maturity Levels,Generic Practices,Generic Goals,Process Area 2,Common Features,Process Area 1,Process Area n,Ability,Implementation,Verifying,to Perform,Commitment,Directing,Implementation,Spe

3、cific Goals,Implementation,Specific Practices,阶段模型的5个级别,1.初始级(Initial)2.已管理级(Managed)3.已定义级(Defined)4.量化管理级(Quantitatively M)5.优化级(Optimizing),CMMI L2的7个PA(Process Area),1.需求管理 REQM2.项目策划 PP3.项目监控 PMC4.供应商协议管理 SAM5.过程和产品质量保证 PPQA6.配置管理 CM7.度量和分析MA,REQM的主要任务,1.双向可跟踪性2.需求变更的控制3.需求状态4.需求关联,PP的主要任务,1.项目

4、估计2.生命周期的选择3.制定和维护项目计划,PMC的主要任务,1.监视项目状态2.及时调整项目开发,MA的主要任务,1.根据计划收集项目有关数据2.对收集到的数据进行适当的分析3.给出客观的分析报告,PPQA的主要任务,1.客观评估项目的产品和过程2.向有关人士提供SQA活动的结果3.发现并确保不合格项得到处理,CM的主要任务,1.配置标识2.变更控制3.配置状态4.配置审核,CMMI和开发过程的关系,1.CMMI是管理过程2.CMMI如何与开发过程融合,开发过程,CMMI和ISO9000的异同,同:1.管理体系2.部分要求相近3.关注过程,异:1.针对性不同(行业)2.覆盖范围不同(环境)

5、3.关注点不同(客户),谢谢大家,CMMI介绍(二),CMMI Coordinator Team,July 14,2004,CMMI跨级评审,CMMI可以进行跨级评审,但是必须满足被跨越级别的各PA;例如,要直接通过L3,除了满足L3的14个PA外,还要满足L2的7个PA,可剪裁的PA除外。,L3关注的焦点,更加关注技术和管理方面的问题:过程管理:3PA项目管理:4PA工程:5PA支持:2PA,L3的各PA,需求开发(RD),“需求开发”过程的目的是产生和分析顾客需求、产品需求和产品构件需求。上述三种需求可能彼此间发生一些递归互动作用,它们与在“技术解决”过程中开发的优选产品概念和候选解决方案

6、的定义也存在递归互动关系。,集成项目管理(IPM),“集成项目管理”的目的是按照集成的、已定义的过程来管理项目,并且使相关方介入项目。这种项目已定义过程是从本组织的标准过程集合(过程库)剪裁而来。,风险管理(RSKM),“风险管理”的目的是识别潜在的问题,以便策划处理风险的活动和在必要时在整个项目生存周期中实施这些活动,缓解不利的影响,实现目标。“风险管理”可以分成三个部分:风险管理策划;识别和分析风险;以及处理所识别的风险(包括在必要时实施风险缓解计划)。,技术解决(TS),“技术解决”过程的目的在于开发、设计和实现关于需求的解决方案。解决方案、设计和实现等都围绕产品、产品构件和与过程有关的

7、产品(可能是其中之一或它们的组合),适用于体系结构的任何层次,适用于产品、产品构件、生存周期过程以及服务。最终得到最优化的解决方案。,决策分析和决定(DAR),“决策分析和决定”的目的在于运用结构化方法对所确定的候选方案进行决策。通过以下步骤作出上佳决策:1)选择决策技术;2)确定作为决策基础的准则;3)确定候选方案;4)对照准则评价候选方案。结构化决策过程可以减少决策中的主观影响,能够以比较高的概率选择出能满足共利益者的多种需求的解决方案。,产品集成(PI),“产品集成”的目的在于把产品构件组装成产品,确保所集成的产品恰当地发挥作用,确保交付产品。“产品集成”的一个关键是产品和产品构件的内部

8、和外部接口管理,要确保接口之间的兼容性。在整个项目进程中都应注意接口管理。,验证(VER),“验证”的目的在于按照需求(包括顾客需求、产品需求和产品构件需求)对产品和中间产品进行验证。“验证”过程强调验证准备、验证执行和确定纠正措施。“验证”是一种渐进的过程,因为它要在产品和工作产品整个开发过程中执行,即从对需求进行验证开始,然后是对推进中的工作产品进行验证,最后是对完成的产品进行验证。,确认(VAL),“确认”的目的在于证明,产品或产品构件被置于其预定使用环境中时,适合于其预定用途。“验证”过程与“确认”过程看起来类似,但是它们处理的问题不同。“确认”是要证明所提供的(或将要提供的)产品适合

9、其预计的用途,而“验证”则是要查明工作产品是否恰当地反映了规定的要求。换句话说,验证保证“做得正确”,而确认则保证“做正确的东西”。,组织过程焦点(OPF),“组织过程焦点”的目的在于掌握并维护本组织的过程和过程资源,以及识别、策划和实施本组织的过程改进活动。组织的过程包括本组织的标准过程集合和派生于这个集合的已定义过程。组织的过程资源是那些与描述、实施和改进过程有关的制品(例如,方针、过程描述、支持环境以及过程实现的支持工具等)。,组织过程定义(OPD),“组织过程定义”的目的是建立并维护一批可用的组织过程资源。这些过程资源包括组织的标准过程集合和支持性资源。这些资源使整个组织的过程性能能够

10、取得一致,并且是本组织奠定不断累积的长远效益的基础。,组织培训(OT),“组织培训”的目的在于提高开发人员的技能和知识,以便他们能有效地履行职责。“组织培训”所包含的培训旨在支持组织的战略业务目标的需求;由单个项目和支持组提出的特殊培训是在项目和支持组一级处理,不在“组织培训”的范围之内。,集成团队(IT),“集成团队”的目的在于建立和维持一个进行产品开发的团队。与其他团队的区别:组员被授权可以进行决策并对授权方负责组员可能包含客户、供应商和其他组织之外的人员组员包括具有需求开发技能的人组员分享意见、期望和需求集成团队明确其在整个项目结构中的角色,集成供应商管理(ISM),“集成供应商管理”的

11、目的在于早期识别满足项目需求的外部产品资源,同时管理选定的供应商、维护供求双方的合作关系。ISM是建立在SAM之上的,更关注的是与供方的合作开发;SAM主要是采购方面。,组织集成环境(OEI),“组织集成环境”的目的在于提供一个产品和过程集成开发的组织构架,并且集成了人员管理。,L2、3各PA间的关系,开发:RD-IPM-PP+RSKM+SAM-TS-DAR-PI支持:REQM、CM、VER、VAL管理:PPQA、MA、PMC、ISM组织:OPF、OPD、OT、OEI、IT,谢谢大家,CMMI介绍(三),CMMI Coordinator Team,September 02,2004,PP&PM

12、C,参数估计,拟定项目计划,获得承诺,参数估计,参数估计,确定项目范围,参数估计,确定生命周期,估计工作量,估计的方法(一),1.Delphi方法,估计的方法(二),2.Pert方法 得出产品预期规模的Pert统计估计E和标准偏差SD。例如:a最低可能规模,如 b预期规模,如 c最高可能规模,如Pert方程式估计预期规模、和标准偏差,则:(a+4b+c)/6;S(c-a)/6,软件生命周期,拟定项目计划,拟定项目计划,进度计划,策划项目资源,识别知识技能,人员调配安排,风险策划,项目测量安排,获得承诺,获得承诺,取得承诺,调整承诺,开发组内,各组间,评审项目计划,评审从属计划,谢谢大家,风险管

13、理,风险管理的目的是识别潜在的问题,以便策划处理风险的活动和在必要时在整个项目生存周期中实施这些活动,缓解不利的影响,实现目标。风险管理是一个连续的前瞻性的过程,它是业务和技术管理过程的重要组成部分。风险管理需要处理可能危及关键目标的问题。,风险管理组成,风险管理可以分成三个部分:风险管理策划;识别和分析风险;以及处理所识别的风险(包括在必要时实施风险缓解计划)。,风险管理策划,风险管理策划是指建立企业通用的风险来源分类;风险级别划分规则;风险优先级规则和风险管理资源安排等活动。(由SEPG组织完成),风险识别,风险的来源:项目特点(交付时间,特殊应用等)开发和商业环境 人员技能 技术 资源

14、数据迁移,风险分析和RV,RV(Risk Value)=P x Imp,风险排序,根据RV值的大小将所识别出的风险进行排序,针对前一两个风险制订相应的风险处理计划。当RV值相同,但是P和Imp值不同的两个风险应如何排序?RV=P x Imp 为风险设定阀值、优先顺序等(填写Risk log),风险处理计划,Risk avoidance:Reject item/process that would allow the risk to arise while still meeting the standard/requirement Risk Transfer:Transferring the

15、risk to the corresponding party who should own&mitigate the risk.Risk acceptance:Willing to accept the consequences should the risk occur.This method recognizes that not all identified program risks warrant special handling as such,it is most suited for those situations that have been classified as

16、low risk.,风险监控,风险监控,已识别风险的状态,更新风险记录,识别新风险,调整风险排序,比较风险处理成本,更新/实施处理计划,CMMI介绍(四),CMMI Coordinator Team,October 06,2004,PM Training,培训内容,Client Engagement Project Planning Monitoring and Control Risk Management,Client Engagement,Entry Criteria,Receipt of a written or verbal trigger to start a project.An

17、 amendment to a contract from US team or real customer,Client Engagement,Inputs,Contract/Order/Tender Inquiry/Final Proposal and all other communications from US team or real customer(if any),Client Engagement,Activities,1 GM or VP appoints the PM to lead contract reviewing or engaging with US produ

18、ct management team to initiate the project;2 For PLM projects,development team works with product management team to acquire customer requirement,refine and finalize the requirements;,To be Continued,Client Engagement,Activities,3 For non-PLM project,a contract review team(CRT)will work with develop

19、ment team to acquire customer needs,refine requirement and finalize the contract.,Client Engagement,Outputs,MRD,UC,UI,System RequirementSite MapChange RequestReview ReportPI Note(maybe Email)Requirement MatrixDraft Project Plan,Client Engagement,Exit Criteria,Notification from Product management tea

20、m stating development work can starts for PLM projects Contract Review report with an acceptance or rejection decision for non-PLM contract.,Project Planning,Entry Criteria,PM or DM is trained in the area of software project management and software estimating.Contract review completed and project in

21、itiation note raised,Project Planning,Inputs,MRD,System Requirement,and part of UC,UI etc.SOW(if any)Estimation Results,Project Planning,Activities,1 PM or appoints DM prepares a draft project plan,as per defined template,based on SOW/contract review record/contract/MRD and other information availab

22、le;2 Depending on project needs and technical features,PM and DM define the software life cycle;,To be Continued,Project Planning,Activities,3 Based on SOW and MRD,System Requirement,UC,etc,PM establishes WBS(MS Project);4 PM estimates the size,complexity,effort and schedule of the tasks that identi

23、fied in WBS with help from project team;,To be Continued,Project Planning,Activities,5 PM identifies risks and develops risk management plan in his project plan;6 PM identifies training needs for his team member in his plan;,To be Continued,Project Planning,Activities,7 PM identifies H/W,S/W and oth

24、er resource requirements in his project plan;8Tailoring guideline will be used to tailor the project,if required;9PM defines methods of project monitoring and control in project plan;,To be Continued,Project Planning,Activities,10 PM should communicate with affected teams(such as SQA)to finalize the

25、 affected plans.(Like PPQA plan and CM Plan);11PM organizes a internal review meeting and invites SQA,HR,IT support etc.to attend this meeting.In this meeting,PM negotiates commitment from all stakeholders;,To be Continued,Project Planning,Activities,12PM updates project plan based on the output of

26、project review meeting;13Project plan is approved by MRC or US PM(if any);14After approval from MRC or US PM,project plan should be baselined.,Project Planning,Outputs,Project Plan is Baselined,Project Planning,Exit Criteria,Project closured,Monitoring and Control,Entry Criteria,Project is on going,

27、Monitoring and Control,Inputs,Project plan;Affected plans;Project tracking sheet.,Monitoring and Control,Activities,1 PM holds a meeting with project team to find out the current status of project.PM updates the Project Tracking Sheet to report the project status;2 PM send Project Tracking Sheet to

28、US PM weekly;3 PM updates project plan as need when project status is changed.The updated plan should be approved by MRC or US PM;,To be Continued,Monitoring and Control,Activities,4 PM adjust development work based on new plan;5 PM reviews the project status with other projects PM once in 15 days.I

29、n the review meeting,every PM should introduce the status of his project.Other PMs will give some advices and comments on it;6 For unresolved issues,PM should report to GM for help;,Monitoring and Control,Outputs,Project Tracking SheetUpdated Project Plan,Monitoring and Control,Exit Criteria,Project

30、 closured.,Risk Management,Entry Criteria,When PM or DM identifies risks,anytime such as:Contract review Develop a Project plan Or develop other affected plans,Risk Management,Inputs,Contract Proposal Tender Draft Project Plan,Risk Management,Activities,1 Risk Planning Risk planning is the detailed

31、formulation of a program of action for the management of risk;2 Risk Assessment Risk identification Risk Analysis,Rating and Prioritization,To be Continued,Risk Management,Activities,3 Risk Handling Mitigation Contingency 4 Risk Monitoring Risks identified,tracked,controlled Occurrence of unidentifi

32、ed risks Comparison of estimated risk mitigation,Risk Management,Outputs,Risk Management Plan(part of PP)Risk Log(part of PP)Mitigation/Contingency Plan Modified Project Plan,Risk Management,Exit Criteria,Baselined RMP/PP Baselined Mitigation/Contingency Plan,CMMI介绍(五),CMMI Coordinator Team,October

33、07,2004,PM Training(part 2),培训内容,SW development lifecycle SDLC Tailoring Product release DAR,SW development lifecycle,Waterfall,System feasibility Validation,Software Plans&Requirements Validation,Product Design Verification,Detailed Design Verification,Code Unit Test,Integration Product Verificatio

34、n,Implementation System Test,Operations&Maintenance Revalidation,This model is best suited when a set of high quality,stable user requirements exists.Its limitations stem from the fact that it requires complete knowledge of all requirements at early stages of the life cycle,commitment of all financi

35、al and other resources up front(with a low visibility until the product is ready)and lack of flexibility to accept change to requirements.The Waterfall Model is inappropriate for development situations where these factors may pose problem,SW development lifecycle,RADRapid Application Development,If

36、a application can be modularized in a way that enables each major function to be completed in say,less than 3 months,it is a candidate for RAD.Each major function can be addressed by a separate RAD team and then integrated to form a whole application.If a system cannot be properly modularized,or if

37、the technical risks are high,RAD is not suitable as a life cycle model.,Business Modeling,Data Modeling,Process Modeling,Application Generation,Testing&Delivery,Business Modeling,Data Modeling,Process Modeling,Application Generation,Testing&Delivery,Team1,Team2,SW development lifecycle,Incremental,T

38、he first increment is often a core product where the basic requirements are addressed,but many supplementary features remain undelivered.The core product is reviewed in detail by the customer and may be even used.As a result of the detailed review and/or use of the core product a plan is developed f

39、or the next increment.This is the best choice for projects that has high technical risks,and objective is achieved by breaking down the project organization and systems construction into manageable sub-projects.,Increment 1,Delivery of 1st Increment,Analysis,Design,Code,Test,Increment 2,Delivery of

40、2nd Increment,Analysis,Design,Code,Test,Increment 3,Delivery of 3rd Increment,Analysis,Design,Code,Test,SW development lifecycle,Prototyping,The analysts discuss with the customer the overall system objectives,identify whatever requirements are known,and outline areas where further definition is nee

41、ded.On basis of the Gross Design a prototype is built which serve to obtain user feedback and refine the requirements of the software to be produced.Iteration occurs as the prototype is tuned to satisfy the needs of the customer and thus facilitate a better understanding of the customer requirements

42、 and thereby,modification and refinement of the system requirements.,Design,Coding,Testing,Installation,Maintenance,ProjectInitiated,Requirements gathering&refinements,Grossdesign,Building Prototype,Customerevaluation,Refineprototype,Engineerproduct,Design of remaining portion of the System Construc

43、tion of the whole software,or Construction the balance portion in case the Phase prototype is a functional prototype,Requirement Specifications(Requirement Analysis+Prototype Design+Prototype Construction+Customer Feedback+Refining Defining alternatives),SW development lifecycle,Spiral,This couples

44、the iterative nature of the Prototyping Model with the controlled and systematic approach of the Waterfall Model.This model does not necessitate either a full knowledge of user requirements,or a full commitment of funds for the entire development work at the beginning of the project.Like the Waterfa

45、ll Model,the Spiral Model starts with a set of objectives that specify quality and costs associated with the reaching of goals.,SW development lifecycle,JAD(Joint Application Development)is a technique that allows the development team,customer management and user groups to work together to build a p

46、roduct.This is more of a project management strategy and approach than a software process model,though the life cycle activities may differ in some cases while the JAD technique is adopted.Thus a project using JAD technique may use any of the life cycle models described above with the necessary tail

47、oring of the life cycle model.,SW development lifecycle,Software Maintenance Lifecycle The lifecycle for any support project will normally involve understanding the system that is to be supported system study,and then providing support as when any issues are reported by the user(issues could include

48、 bugs,exceptions or minor changes)issue handling.,SDLC Tailoring,Entry Criteria,Requirements are clear;Draft project plan will be developed.,SDLC Tailoring,Inputs,MRD,System Requirement,and part of UC,UI etc.FB SDLC guideline FB Tailoring guideline,SDLC Tailoring,Activities,1 Depending on the requir

49、ements,the PM or DM will select the appropriate life cycle;2 If it is seen that the project cannot be carried out with any specified model in the Software development Process,then the appropriate life cycle procedure will be described in the relevant section of the Project Plan.The new life cycle is

50、 also to be sent to SEPG for its final approval;,To be Continued,SDLC Tailoring,Activities,3 If the new Life cycle is not approved by SEPG,then the PM or any authorized person will make the changes as required and get approval from SEPG;4 For an existing life cycle model,the PM may pick up the not a

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 建筑/施工/环境 > 项目建议


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号