CMMI3级过程改进案例分析报告
- 格式:ppt
- 大小:673.50 KB
- 文档页数:22
基于CMMI 模型的过程改进收稿日期:2018-03-14基金项目:本文受到北京市委组织部优秀人才项目(项目号:2012D005017000004)和北京建筑大学校教研项目(基于案例驱动的软件工程教学方法研究)的资助作者简介:赵海龙(1976-),男(汉族),河北邯郸人,讲师,博士,研究方向:软件工程、模式识别与图像处理。
一、引言众所周知,一个企业或项目的成功离不开过程、人员和技术,过程作为粘合剂把人员和技术紧密地联系在一起,产品的质量在很大程度上取决于用以开发和维护该产品的过程的质量。
本文第二部分介绍了过程改进的基本概念和实施过程改进常用的几种方法;第三部分对能力成熟度集成模型(Capability Maturity Model Integration ,CMMI )做了说明;第四部分对CMMI 中的一些概念和术语进行较详细的解释。
二、过程改进的概念及方法按照IEEE 的定义,过程是指为了达到给定目标而执行的一系列步骤。
过程改进是指过程的拥有者为了使组织达到新的目标而采取的一系列的活动,这些活动包括对组织内部的现存过程进行标识、分析和改进。
组织进行过程改进的目标通常是提高质量、提高生产率以及降低生产/开发成本等。
常见的过程改进方法有以下几类。
1.业务流程重组。
业务流程重组(Business Process Reengineering ,简称BPR )强调以业务流程为改造对象和中心、以关心客户的需求和满意度为目标、对现有的业务流程进行根本的再思考和彻底的再设计,利用先进的制造技术、信息技术以及现代的管理手段,最大限度地实现技术上的功能集成和管理上的职能集成,以打破传统的职能型组织结构,建立全新的过程型组织结构,从而实现企业经营在成本、质量、服务和速度等方面的巨大改善。
2.基准化分析法。
基准化分析法(Benchmarking ),也称标杆分析法,就是将本企业各项活动与从事该项活动最佳者进行比较,从而提出行动方法,以弥补自身的不足。
一个虚构的CMM改进实例某系统集成企业(简称A公司),在电信计费/业务支撑行业小有名气,业务开展得相当成功,但是在进一步发展的过程中,遇到了以下几个问题:1.公司目前在独立开发和维护多个功能大体相似,却又有相当差别的系统版本,这些版本之间的关系“剪不断,理还乱”,公司试图引用一些业界标准的系统架构,比如J2EE,试图实现部分软件重用。
但是却发现情况并不能够得到多少改善。
2.公司常年有大批的开发人员被派驻到客户方,导致了高昂的人力资源成本。
这些开发人员难以管理,对公司的认同感差。
3.公司制定了一定的项目管理规范,但是在推行过程中却不尽如人意。
项目不断延期,事故不断。
4.公司没有正规的培训体系,软件技术人员在需求,分析,设计和测试的技能不足。
鉴于现在行业软件的严峻形势,A公司要求改变这一现状,加强管理,提高效率,减少派驻在客户方的人数。
A 公司和小有名气的C咨询公司签订了合同,要求C帮助A 公司完成这项变革。
C公司的张顾问具体负责这个项目。
根据自身丰富的经验,张顾问立刻意识到:1.这是一个管理和技术相互缠绕的问题,必须结合两方面的手段,综合进行解决。
2.A公司意识到这个问题其实不是一天两天了,以前也曾经想了很多解决方案,但是为什么这些方案会失败?查找以前这些努力的历史,将有助于问题的解决。
3.任何一项变革,必须获得公司高层的明确和实质性的支持否则难以成功。
根据自身的经验,张顾问拟定了一个工作规划:1.推动客户方成立一个“行动小组”并获得高层的明确授权。
2.在“行动小组”的主持下,了解客户方曾经进行这方面版本规范化的努力的历史以及失败的原因。
3.和客户方共同分析A公司的电信业务系统的架构。
4.在客户方展开访谈,了解项目管理和质量管理的现状。
5.在了解现状的基础上,对客户的现状进行诊断,对用户高层和C公司进行报告。
“联合行动小组”很快成立起来了,小组由精干的人员组成,在张顾问的特别要求下,小组的成员不仅仅来自于管理部门,也增加了来自于项目管理部,技术开发部,和特地从现场工程部门抽调出来的人员。
CMMI3级过程改进案例分析CMMI(Capability Maturity Model Integration)是一个美国软件工程协会(SEI)开发的过程改进模型,旨在帮助组织提高其软件和系统工程能力。
CMMI模型以五个不同的成熟度级别来评估组织的过程改进成熟度,从级别1(初始级)到级别5(优化级)。
本文将分析一个CMMI级别3的过程改进案例,该案例涉及一个虚拟软件开发公司的项目管理流程。
该软件开发公司在过去的几年里迅速扩张,面临着越来越多的项目和客户需求。
然而,由于流程不规范和管理混乱,公司经常面临项目延期、质量问题和客户不满的情况。
因此,公司决定进行CMMI级别3的过程改进,以确保项目按时交付、质量得以保证并提高客户满意度。
在开始过程改进之前,公司进行了一次自我评估,识别了以下问题:1.项目管理流程不规范:项目经理在不同项目之间使用不同的流程和模板,导致难以复用经验和最佳实践。
2.文档管理混乱:公司缺乏一套标准的项目文档模板和版本控制机制,导致难以跟踪和管理项目文档。
3.报告和沟通不及时:在项目中,上级经理和客户之间的沟通和报告不及时,导致无法及时响应变更请求或解决问题。
为解决以上问题,公司采取了以下步骤:1.确立项目管理过程框架:公司制定了一套标准的项目管理过程框架,包括项目启动、规划、执行、监控和收尾等不同阶段的流程和活动。
这一框架通过模板和指南的形式被推广给所有项目经理和团队成员。
2.建立文档管理系统:为了解决文档管理混乱的问题,公司引入了一套文档管理系统,用于统一管理项目文档和版本控制。
所有项目相关的文档都必须通过该系统进行创建、审批和存储,以确保文档的完整性和一致性。
3.实施定期报告和沟通机制:为了加强项目监控和沟通,公司建立了定期报告和沟通机制。
项目经理需要定期向上级经理和客户提交进展报告,并参加定期的项目评审会议,以及时解决问题和调整项目计划。
经过一段时间的过程改进实施后,公司取得了以下成果:1.项目交付时间得到了明显的改善:通过建立标准的项目管理过程框架,项目经理能够更好地规划项目,并及时解决问题,从而大大减少了项目延期的可能性。
内容提要软件过程改进是目前IT 企业研发管理的重点与难点。
为了提高软件过程能力,企业首先要研制软件过程规范,这是有一定难度并且费时费力的工作。
本文论述的是一套通用的CMMI 3级软件过程改进方法与规范,称为“精简并行过程”(SPP)。
SPP 2.0共有19个关键过程域,分为项目管理过程、技术开发过程和支撑过程三大类:✧项目管理过程有7个关键过程域,分别为立项管理、结项管理、项目计划、项目跟踪、风险管理、外包管理和需求管理。
✧技术开发过程有8个关键过程域,分别为需求开发、技术预研、系统设计、实现与测试、系统测试、用户验收、产品维护和技术评审。
✧支撑过程有4个关键过程域,分别为配置管理、质量保证、采购管理和培训管理。
SPP 2.0文档总数约500余页,包含了众多的过程规范和模板。
采用SPP,用户可以在最短的时间内建立适合于本企业的软件过程规范,大大降低用户研制规范的代价和风险。
一、背景介绍在国内,绝大多数大中型IT企业几乎都面临着“研发管理混乱”的难题。
“研发管理混乱”必将导致“产品质量低下”、“进度延误”、“费用超支”等问题。
IT企业谋求发展,研发管理必须规范化,这是大中型IT企业的迫切需求。
软件过程改进(Software Process Improvement, SPI)是目前国内大中型IT企业研发管理的重点与难点。
CMM(Capability Maturity Model)是用于衡量软件过程能力的事实上的标准,同时也是目前软件过程改进最好的参考标准。
CMM是由美国卡内基-梅隆大学(Carnegie-Mellon)软件工程研究所(Software Engineering Institute, SEI)研制的,其发展简史如下:✧CMM 1.0于1991年制定。
✧CMM 1.1于1993发布,该版本应用最广泛。
✧CMM 2.0草案于1997年制定(未广泛应用)。
✧到2000年,CMM演化成为CMMI(Capability Maturity Model Integration),CMM2.0成为CMMI 1.0的主要组成部分。
CMMI3过程改进分析报告第一篇:CMMI3 过程改进分析报告过程改进分析报告XXXXX是一家以软件研发和解决方案销售的信息技术有限公司,公司以互联网技术和基于组件的软件开发技术为核心,为客户提供定制软件开发及维护服务。
公司组建了EPG过程改进小组、品质保证组,并正式启动了基于CMMI的软件过程改进进程。
EPG过程改进小组对公司软件开发过程与公司运营过程的分析和探讨,制定了一套适合于公司实际的组织标准过程定义。
组织标准过程定义选定项目中进行了样本试验,在包括研创中心内推广,取得了一定的成效。
公司按照CMMI3的标准对过程改进管理、并与外部咨询机构签订咨询合同聘请资深咨询顾问通过深入了解公司的过程改进目标及现状,帮助EPG过程改进小组制定相应的实施计划,跟进实施计划及现状提供相应的培训,并在定义或改进过程时提供有力的支持。
在CMMI过程改进之前需求频繁变更没有得到及时的记录,也缺乏对需求变更的分析和管理,导致项目的返工率增加,以至延误项目的进度并造成成本的增加,测试人员不能得到最新的完整的需求,因而造成测试的遗漏,最终引起提交给客户的产品品质低下测试缺陷不是总得到记录(特别是单体测试时的缺陷),导致缺陷遗漏和缺陷数据不准确。
功能方面的测试点覆盖不全面,造成测试遗漏,提交给客户后被发现,质量低下客户投诉高、返工率高无法提高生产率,从而导致项目成本不断上升。
公司成立EPG过程改进小组,通过收集外部咨询机构人员、内部评审人员、QA和项目组成员的建议,制定了需求管理、品质管理、项目管理等改进计划:1、需求管理EPG过程改进小组制定了需求变更管理过程,在过程中要求使用表格来管理所有的需求变更,包括变更的内容、时间、原因、提出者、状态。
使用Q&A来记录与客户的交互信息,这些Q&A都得到了统一的保存。
负责需求的人员在每次变更时要召集所有项目的相关人员,对其进行分析以确定其影响程度和范围,对于超过组织定义的阈值的大变更只有在评审通过后,才可以被纳入系统,对于小变更也要得到记录,整个过程得到QA人员的监察和审核以确保过程得到严格的实施。
浅析CMMI-DEV,V1.3在二、三级过程域的变化摘要:本文介绍了CMMI-DEV,V1.3模型总体的变化并重点比较了V1.3与V1.2两个版本模型在二、三级过程域上的变化,为希望了解CMMI-DEV模型变化或者正在根据CMMI-DEV,V1.2进行过程改进的人士提供参考。
关键词:CMMI-DEV V1.3,过程域变化1 前言自从1994年SEI正式发布软件CMM以来,相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。
2000年,为了解决组织因为同时采用多种模型带来混乱等情况,SEI发布了CMMI模型。
之后模型不断的改进发展,大量组织从2006年开始使用CMMI-DEV V1.2模型进行过程改进,而在使用该模型时,使用者也发现模型存在着高成熟度描述不明确、某些细节不符合组织需要等问题。
SEI从2008年开始策划编写CMMI-DEV V1.3,经过三年的时间,在2010年11月发布了最新的模型。
模型的更新中除了明确了高成熟度要求外,还包含了二、三级过程域的修改,为CMMI模型的使用者提供了更清晰、更新的指导。
本文的目的是介绍二、三级过程域的变化,为熟悉CMMI模型、基于CMMI-DEV V1.2模型制定组织开发过程的人员提供参考。
2 模型变化综述CMMI-DEV V1.2版之前,各过程域能能力等级分为0至5共六级,通过评价是否满足通用目标4(GG4)及通用目标5(GG5)判断各过程域是否到达高成熟度。
在本次V1.3版本更新中,SEI将GG4及GG5从模型中去除,通过判断各过程域是否达到能力等级三(Capability Level3)以确定组织成熟度等级是否达到成熟度四级或五级(Maturity Level 4 and 5)。
除此以外,模型对GP2.6和GP3.2进行了修改。
GP2.6从原来的“管理配置项”变为“控制工作产品”,以免模型使用者误以为该实践要求使用配置管理工具管理所有选定的工作产品,关于模型对于“配置项”的描述变化,请见后文的配置管理过程域。
密级:组织过程改进过程目录1.目的/方针 (1)2.范围 (1)3.术语 (1)4.角色与职责 (1)5.入口准则 (1)6.输入 (1)7.流程图 (2)8.主要活动 (3)8.1.识别过程改进 (3)8.2.过程改进策划 (4)8.3.过程改进实施 (5)8.4.评估组织过程 (5)9.出口准则 (6)10.引用文档 (6)11.使用模板 (6)1.目的/方针组织过程改进((Organization Process Focus, OPF)的目的在于掌握组织的过程状态,识别过程改进机会,策划和实施本组织的过程改进活动。
EPG应遵循本过程识别整个组织的过程改进机会,以及策划和实施过程改进活动。
2.范围适用于组织的过程改进。
3.术语4.角色与职责5.入口准则●无6.输入●过程改进信息本过程包括2个规程:1、EPG章程2、管理评审规程8.主要活动组织根据《EPG章程》组建EPG并实施EPG的管理。
EPG负责组织的过程改进工作,包括识别过程改进、过程改进策划、过程改进实施、评估组织过程等活动。
8.1.识别过程改进●EPG通过各种渠道和方式收集改进信息,收集的渠道和方式有:✧营造一个激励持续改进的氛围与环境,收集和分析来自员工等相关方的合理化建议,识别改进机会;✧组织过程的改进目标;✧过程评估的结果;✧通过常规性内部审核、管理评审和各种持续的差距分析活动,不断发现组织过程的薄弱环节;✧通过测量和分析,找出顾客的不满意、产品未满足要求、过程不稳定等事项,分析识别改进机会;✧从监控组织和项目的过程活动的中得出的经验教训中分析识别改进机会;✧通过QA工程师,在日常工作中发现不符合或潜在不符合的事实,分析识别改进机会;✧其它渠道收集的改进信息。
收集的改进信息记录在《改进信息跟踪表》。
●EPG每月对收集的信息进行综合分析,识别组织过程的薄弱环节,确定改进的时机和改进的方式。
过程改进活动有两种方式:日常改进活动和周期性的过程改进活动。
竭诚为您提供优质文档/双击可除cmmi,3级软件过程改进方法与规范篇一:cmmi过程改进的两种方法1、2、cmmi过程改进的两种方法阶段表示为过程改进提供了一个预定义的路线图,即从成熟等级1到成熟度等级5逐渐增加,要达到一成熟度等级,必须满足该等级(及其以下等级)上所有的过程域的目标连续表示支持单个过程域的改进,可理解为一个过程域接着一个过程域实施改进。
在每个过程域上能力等级0到能力等级5逐级增加3、cmmi的全称,软件能力成熟度模型。
4、过程的作用过程是决定产品成本、进度和质量的主要因素5、过程改进的生命周期模型-ideal模型5、cmmi过程改进流程6、过程改进的目的7、过程改进的好处8、过程改进的原则篇二:cmmi3级软件过程第18章质量保证第18章质量保证质量保证(qualityassurance,qa)的目的是提供一种有效的人员组织形式和管理方法,通过客观地检查和监控“过程质量”与“产品质量”,从而实现持续地改进质量。
质量保证是一种有计划的、贯穿于整个产品生命周期的质量管理方法。
质量保证过程域是spp模型的重要组成部分。
本规范阐述了质量保证过程域的3各主要规程:☆制定质量保证计划[spp-pRoc-qa-planning]。
☆过程与产品质量检查[spp-pRoc-qa-ppqc]。
☆问题跟踪与质量改进[spp-pRoc-qa-tRacking]。
上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内it企业的软件研发项目。
建议用户根据自身情况(如商业目标、研发实力等)适当地修改本规范,然后推广使用。
18.1介绍过程质量与产品质量存在某种程度的因果关系,通常“好的过程”产生“好的产品”,而“差的过程”将产生“差的产品”。
人们销售的是产品而不是过程,用户关心的是最终产品的质量,而开发者(团队)既要关心过程质量又要关心“产品质量”。
软件过程改进实践与案例在软件开发领域,软件过程改进是一个持续不断的过程。
它旨在提高软件开发过程的质量和效率,减少项目失败率,实现可持续发展。
本文将通过实例,介绍软件过程改进的实践方法,以期能够为软件开发人员提供一些有用的经验和思路。
一、软件过程改进的重要性过去,软件开发是一个相对较为薄弱的环节。
开发人员按照自己的经验和想法编写代码,缺乏持续和完整的开发流程管理。
导致软件项目常常出现字母代码、功能不完整、进度滞后等问题,直至项目终止。
随着时间的推移,越来越多的企业和团队开始重视软件开发质量,提高软件开发整体流程。
软件过程改进是一个持续不断的过程,通过该过程,可以有效提高软件开发的流程,减少出错率和工作时间。
简单地说,软件过程改进就是将软件开发流程标准化和细致化,这样可以准确地实现项目计划,提高软件开发质量和效率,减少错误率。
二、软件过程改进实践方法为了实现软件过程改进,我们需要根据软件开发流程的特点,采取相应的实践方法。
2.1、定制化实践方法不同软件开发过程有不同的特点和需求,因此需要根据实际情况进行定制化。
软件开发团队需要了解项目的特点和需求,科学地制定出软件过程改进计划。
该计划应包括:1)定位:明确软件过程改进的目标和计划,建立团队合作意识,为后续的具体实践铺平道路。
2)分析:了解团队的优势和不足,把握软件开发过程中出现的问题,建立软件过程改进的具体方案。
3)实施:根据制定的计划,开展软件过程改进实践工作,持续不断地推进团队的软件开发水平。
4)检测:通过实践方法对软件开发过程进行检测,并反思,为提高软件开发流程提供数据支持。
2.2、流程改进方法流程改进方法是一种系统化的方法,为软件过程改进提供支持。
它以“产品需求、开发、测试、维护”等流程为基础,重点考虑以下问题:1)流程编排:完善流程,科学地选择环节顺序和安排,合理分配任务,加强沟通和协作。
2)流程设计:实际开发中,我们应该把流程设计过程中的每个细节都考虑到,如需求分析、设计、开发、测试等方面。
过程改进计划更改控制页目录1总论 (1)1.1概述 (1)1.2参考 (1)1.3定义和缩写 (1)2实施概要 (2)2.1发起人 (2)2.2改进范围 (2)2.2.1组织范围 (2)2.2.2模型范围 (2)2.3改进组织 (3)2.3.1管理指导组 (4)2.3.1.1角色 (4)2.3.1.2工作职责 (4)2.3.1.3成员构成 (4)2.3.1.4活动 (4)2.3.2质量管理部 (5)2.3.2.1角色与职责 (5)2.3.2.2活动 (5)2.3.3工程过程组 (5)2.3.3.1角色 (5)2.3.3.2工作职责 (5)2.3.3.3成员构成 (6)2.3.3.4活动 (6)2.3.4SPI推进组 (7)2.3.4.1职责 (7)2.3.4.2成员构成 (7)2.3.4.3活动 (7)2.3.5技术管理委员会 (7)2.3.5.1职责 (7)2.3.5.2成员构成 (8)2.3.6变更控制委员会 (8)2.3.6.1职责 (8)2.3.6.2成员构成 (8)2.3.7咨询公司 (8)2.3.7.1角色与职责 (8)2.3.7.2活动 (9)3诊断概述 (10)4SPI生命周期 (10)4.1准备和差距分析 (10)4.2CMMI L4过程域培训和专题培训 (12)4.3过程规范制订咨询指导 (13)4.4过程试运行咨询指导 (14)4.5CMMI L4SCAMPI预评估 (16)4.6CMMI L4SCAMPI正式评估 (19)5过程改进规划 (20)6假设和风险 (21)6.1假设 (21)6.2发起人地位和承诺 (22)6.3沟通 (22)6.4风险 (22)7过程文档化标准 (23)7.1制定过程手册 (23)7.2过程描述 (24)8过程改进的资源 (24)9过程改进状态和监管 (25)9.1MSG定期会议 (25)9.2EPG定期会议 (25)9.3度量 (26)1总论1.1概述本文描述了XXX科技有限公司,过程改进活动所采取的战略和战术的作业计划。
武汉中地数码科技有限公司过程改进计划Version x.x文档名称:ZD-CMMI-Templates-过程改进计划-YYYYMMDD.doc武汉中地数码科技有限公司版权所有不得复制过程改进计划修订历史记录序号日期版本号修改说明修改人评审人批准人1.2014-4-15 0.1 初次撰写李叶繁王洪涛2.2014-4-30 1.0 CMMI3级改进计划定稿王洪涛EPG 周顺平3.2014-7-2 2.0 按公司实际情况,参考咨询师过程改进实施计划调整结束日期至2015年3月王洪涛EPG 周顺平4. 5. 6. 7. 8. 9.目录1. 引言 (1)1.1 文档目的 (1)1.2 改进背景与总体目标 (1)1.3 工作原则 (1)1.4 术语及定义 (2)1.5 参考文献 (2)2. 改进目标 (2)2.1 现状及问题分析 (2)2.2 商业目标 (3)2.3 近期目标 (3)2.4 中长期目标 (4)3 改进机构与职责 (5)3.1 组织机构及范围 (5)3.2 高层管理指导委员会(MSG) (5)3.2.1 最高管理者 (5)3.2.2 管理者代表 (6)3.2.3 高层委员会 (6)3.3 工程过程组(EPG) (6)3.3.1 EPG Leader(EPG组长) (6)3.3.2 EPG成员 (7)3.4 过程改进顾问 (7)3.4.1 外部顾问 (7)3.4.2 内部顾问 (7)3.5 过程改进项目QA (7)3.6 工作组(Working Group) (8)3.6.1 试点项目项目经理 (8)3.6.2 配置管理员(CMO) (8)3.6.3 培训专员(OT) (9)3.7 沟通协调组 (9)4 进度计划 (9)5 成功标准及资源需求 (9)5.1 成功标准 (9)5.2 资源需求 (10)6 沟通计划 (10)6.1 工作例会 (10)6.2 工作报告 (10)6.3 工作审计 (10)7 假设与风险管理 (11)7.1 取得成功的条件假设 (11)7.2 阻碍项目成员的风险因素 (11)8 附录 (11)过程改进计划1. 引言1.1 文档目的【阐明编写计划的目的】本计划介绍了为提高武汉中地数码科技有限公司(以下简称“中地公司”)过程能力,而发起的过程改进活动,描述了管理该计划的基本架构,并定义了中地公司过程改进的方法、活动,是中地公司过程改进的指导蓝图。
基于CMMI的中小型软件企业过程改进问题研究摘要:对中小软件企业进行了界定,指出CMMI模型应用于中小软件企业的局限性。
基于瀑布模型,采用SPP方法对CMMI 3模型进行了精简,对模型中过程域的流程进行了说明,精简后的模型适合于中小型软件企业。
关键词:中小软件企业;CMMI;过程改进本文采用的是CMMI-DEV1.2版本,共分为4类过程域:过程管理、项目管理、工程类和支持类。
每类过程域又分为基本过程域和高级过程域。
实施CMMI的好处很多,如规范软件开发过程,改进软件开发过程,有效控制项目进度、成本,减少软件缺陷等。
但对中小型软件企业来说,CMMI在实施过程中也有其局限性:①中小软件企业成员往往身兼多职,很难有专人进行质量保证(QA)工作;人员流动快,很难形成专职的过程改进团队;②资源缺乏,难以实现CMMI规定的那么多关键过程域,且没有实施指南;③CMMI主要考虑实施过程的完整性,而中小企业则主要关注快速反应能力和沟通能力,关注重点有所不同。
2构建中小型软件企业的过程改进模型2.1采用的基本理论基于瀑布模型,采用精简并行过程(SPP,Simplified Parallel Process),对CMMI 2级和3级的过程域进行“精简”,提出适合于中小企业的过程改进模型。
2.1.1瀑布模型瀑布模型是一种线性的开发模型,其基本思想是按工序将问题简化,将软件生命周期划分为制定计划、需求分析、软件设计、编程、测试和运行维护6个基本活动。
本文选择用瀑布模型进行研究,一方面是因为瀑布模型是目前软件行业最熟悉且熟练运用的周期模型,很多其他模型也是在此基础上发展起来的。
其次,大多数软件项目采用线性开发方法,中小企业尤其如此。
另一方面,项目管理过程与研发过程均可以按照瀑布模型划分阶段。
2.1.2CMMI 2和CMMI 3的关键过程域对于国内中小软件企业来说,能够达到2级或3级已经比较困难,故无需讨论更高级别的过程域。
某某区电子政务系统集成测试分析报告第一章简述1.1 测试内容某某区电子政务系统分外部门户网站、办公业务门户和办公OA系统三大组成部分。
对该三大组成部分分别作如下测试。
极限测试:由每个模块使用大致对应数目的虚拟用户逐渐按比例加压,记录能正常工作的情况下的最大用户。
响应时间测试:测试实时页面和含有控件的页面响应时间。
实时页面的响应时间不超过3秒,有控件加载的页面的响应时间不超过7秒。
运行环境测试:测试该系统在需求规格说明书所明确的软硬件环境下能否正常运行。
1.2 测试环境●服务器一台:曙光天阔S240-Xp4Cpu 2.0g hz X 4内存 2.0g硬盘80g操作系统:应用服务器:数据库服务器:JA V A环境JRE1.5_04或以上版本●客户端4-5台:兼容机Cpu 1.8g hz内存512M硬盘40g操作系统WINDOWS2000网页浏览器 IE6.0或以上版本●测试模拟和测试监控测序loadrunner 8.01.3 测试进度安排测试环境的搭建●测试环境的搭建:半天,选择一台服务器,4-5台客户端,如果操作系统不一致的必须从新安装,服务器上安装某某区电子政务系统,所有客户端安装LoadRunner8,安装类型选择Standalone Installation,安装方式选择Custom Installation。
以服务器系统能访问,客户端LoadRunner能运行为标准判断该阶段是否完成。
●外部门户网站模块的测试:2天,进行脚本录制,及修改测试脚本。
提取部分打开实时页面和含有控件页面的步骤包含入事务,实时页面事务标注为index_rlt_ 序号,含有控件页面事务标注为index_ctrl_序号, 所有脚本一起进行极限测试。
●内网站模块的测试:2天,进行脚本录制,及修改测试脚本。
提取部分打开实时页面和含有控件页面的步骤包含入事务,实时页面事务标注为index_rlt_ 序号,含有控件页面事务标注为index_ctrl_序号。