软件项目管理与案例分析 (7)

*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,THE SCHOOL OF SOFTWARE ENGINEERING OF HUST,第,3,章 软件开发过程管理,本章内容提要,CMM,和,ISO9000,传统软件开发生命周期模型,扩展软件开发生命周期模型,3.1,质量计划,3.4,案例分析,3.5,本章小结,3.6,复习思考题,3.7,3.2,3.3,软件过程,是指人们用于开发和维护软件及其相关产品的一系列活动、方法、实践和革新。,软件开发过程管理,是指在软件开发过程中，除了先进技术和开发方法外，还有一整套的管理技术。,软件过程改进,是针对软件生产过程中会对产品质量产生影响的问题而进行的，它的直接结果是软件过程能力的提高。,现在常见的软件过程改进方法：,ISO 9000,，,SW-CMM,和由多种能力模型演变而来的,CMMI,。,3.1,CMM,和,ISO9000,3.1.1 SW-CMM,和,CMMI,SW-CMM,简介,为了保证软件产品的质量，,1991,年美国卡内基,梅隆大学软件工程研究所（,CMU/SEI,）将软件过程成熟度框架进化为软件能力成熟度模型（,Capability Maturity Model For Software,，简称,SW-CMM,），并发布了最早的,SW-CMM 1.0,版。,SW-CMM,为软件企业的过程能力提供了一个阶梯式的进化框架，阶梯共有五级。,3.1.1 SW-CMM,和,CMMI,1,初始级,2,可重复级,3,已定义级,4,已管理级,5,优化级,无序、混乱的软件过程。依赖个别人的努力和机遇。,建立基本的项目管理过程。相似项目，重复以往成果。,文档化、标准化和标准的软件软件过程。,软件过程和产品质量有详细的度量标准。,持续的对过程进行改进。,图,CMM,分级标准,3.1.1 SW-CMM,和,CMMI,KPA,及,KP,除第一级外，,SW-CMM,的每一级都是按完全相同的结构组成的。每一级包含了实现这一级目标的若干关键过程域（,KPA,），每个,KPA,进一步包含若干关键实施活动（,KP,），无论哪个,KPA,，它们的实施活动都统一按六个公共属性进行组织，即每一个,KPA,都包含六类,KP,：,1.,目标,2.,实施保证,3.,实施能力,4.,执行活动,5.,度量分析,6.,实施验证,3.1.1 SW-CMM,和,CMMI,CMMI,简介,由于不同领域能力成熟度模型存在不同的过程改进，重复的培训、评估和改进活动以及活动不协调等一些问题。于是由美国国防部出面，美国卡内基,梅隆大学软件工程研究所（,CMU/SEI,）于,2001,年,12,月发布的,CMMI 1.1,版本包括四个领域：软件工程（,SW,）、系统工程（,SE,）、集成的产品和过程开发（,IPPD,）、采购（,SS,）。,3.1.1 SW-CMM,和,CMMI,CMMI,有两种不同的实施方法,连续式主要是衡量一个企业的项目能力,阶段式主要是衡量一个企业的成熟度,CMMI,的五个台阶,完成级,管理级,定义级,量化管理级,优化级,每一个台阶都是上面一阶台阶的基石。要上高层台阶必须首先踏上较低一层台阶,。,3.1.2,ISO9000,质量标准,ISO9000,所谓“,ISO9000”,不是指一般意义上的一个质量保证标准，而是一族系列标准的统称。,作用,强化品质管理，提高企业效益；增强客户信心，扩大市场份额；,获得了国际贸易“通行证”，消除了国际贸易壁垒；,节省了第二方审核的精力和费用；,在产品品质竞争中永远立于不败之地；,有效地避免产品责任；,有利于国际间的经济合作和技术交流。,3.1.3,三者之间的比较,选择,SW-CMM,还是,CMMI,的考虑,实施企业的业务特点。,实施企业对过程改进的熟悉程度。,实施企业对过程改进项目的预算。,实施企业是否可以使用阶段式的演进路线。,实施,CMM,与,CMMI,可以平滑的转换。,ISO9001,与,CMM,的关系,ISO9001,和,CMM,既有区别又相互联系，两者不可简单地互相替 代。,取得,ISO9001,认证并不意味着完全满足,CMM,某个等级的要求。,取得,CMM,第,2,级,(,或第,3,级,),不能笼统地认为可以满足,ISO9001,的要求。,本章内容提要,CMM,和,ISO9000,传统软件开发生命周期模型,扩展软件开发生命周期模型,3.1,质量计划,3.4,案例分析,3.5,本章小结,3.6,复习思考题,3.7,3.2,3.3,软件生命周期,软件从需求确定、设计、开发、测试直至投入使用，并在使用中不断地修改、增补和完善，直至被新的系统所替代而停止该软件的使用的全过程。,可划分为以下子阶段,1.,可行性研究,2.,需求分析和定义,3.,总体设计,4.,详细设计,5.,编码（实现）,6.,软件测试、运行,/,维护,据此相继产生了瀑布模型、螺旋模型、进化模型、原型模型、增量模型等。,本节分别对这几种传统的软件开发生命周期模型予以介绍。,3.2,传统软件开发生命周期模型,3.2.1,瀑布模型,系统需求,软件需求,分析,设计,编码,测试,运行,瀑布模型总结,文档驱动的模型,阶段间具有顺序性和依赖性,项目开发周期较长,实际项目很少按照该模型给出的顺序进行,3.2.2,原型模型,3.2.2,原型模型,Prototyping model,特点,在需求定义之前，需要快速构建一个系统,根据构建系统的优缺点，用户给开发人员提出反馈意见,根据反馈意见修改软件需求规格，以便系统可以更正确地反映用户的需求,减少各种假设以及风险,3.2.3,增量模型,增量,1,增量,2,增量,3,增量,4,第一个增量发布,第二个增量发布,第三个增量发布,第四个增量发布,开发进度,3.2.3,增量模型,增量模型总结,融合了瀑布模型和原型的迭代特征。,每一个增量均发布一个可操作产品。,3.2.4,进化模型,建造,/,修改,原型,听取用户,意见,用户测试,运行原型,这个模型可看作是重复执行的多个瀑布模型。,3.2.5,螺旋模型,原型,1,原型,2,原型,3,可运行,原型,需求计划,生存期,计划,开,发,计,划,集,成,与,测,试,软件,需求,需求,确认,设计确认,与验证,软件,产品,设计,详细设计,风,险,分,析,风,险,分,析,风,险,分,析,验收,测试,实现,集成,与,测试,单元,测试,编码,开发、验证,下一产品,实施工程,提交线,评审,累计,成本,风险分析,评价方案，识别,风险、消除风险,制订计划,决定目标,方案和限制,客户评估,3.2.5,螺旋模型,螺旋模型总结,基于风险驱动的开发模型,使用原型法或其它方法来尽量降低风险。,适用于需求不明确的大规模软件项目,本章内容提要,CMM,和,ISO9000,传统软件开发生命周期模型,扩展软件开发生命周期模型,3.1,质量计划,3.4,案例分析,3.5,本章小结,3.6,复习思考题,3.7,3.2,3.3,3.3.1,极限模型,极限模型简介,2001,年，为了避免许多公司的软件团队陷入不断增长的过程泥潭，一批业界专家一起概括出了一些敏捷开发过程的方法：,SCRUM,，,Crystal,，特征驱动软件开发（,Feature Driven Development,，简称,FDD,），自适应软件开发（,Adaptive Software Development,，简称,ASD,），以及最重要的极限编程（,eXtreme,Programming,简称,XP,）。,3.3.1,极限模型,极限编程将开发阶段的,4,个活动（分析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、反馈修正和反复测试。,3.3.1,极限模型,XP,开发模型核心思想：,交流（,Communication,）,简单（,Simplicity,）,反馈（,Feedback,）,进取（,Aggressiveness,）,3.3.1,极限模型,优点,采用简单计划策略，不需要长期计划和复杂模型，开发周期短；,在全过程采用迭代增量开发、反馈修正和反复测试的方法，能够适应用户经常变化的需求。,缺点,目前主要在小规模项目上应用并取得成功，但是否适用于中等规模或大规模软件产品，需慎重考虑；,由于这个模型较新产品交付后维护成本是否降低，不能确定；,对编码人员的经验要求高,3.3.2,Rational,统一过程（,RUP,）,3.3.2,Rational,统一过程（,RUP,）,用例驱动,Concise,simple,and understandable,以体系结构为中心,Effective basis for large-scale reuse,增量和迭代开发,基于风险前驱的原则，渐进地展开分析、设计及其相关活动，每个迭代都会提供一次验证和调整模型机会，推动软件质量的提升。,3.3.3,微软产品开发周期模型,微软产品周期模型,产品规划阶段,测试阶段,产品开发阶段,发布阶段,M1,Mn,CC,ZBB,RTM/W,RC1,RCn,Alpha,Golden Masters,Beta,Product Vision,Function Spec,QFEs,RTM/W,QA,本章内容提要,CMM,和,ISO9000,传统软件开发生命周期模型,扩展软件开发生命周期模型,3.1,质量计划,3.4,案例分析,3.5,本章小结,3.6,复习思考题,3.7,3.2,3.3,3.4.1,质量与质量规划,软件质量,是“所有描述计算机软件优秀程度的特性的组合”。,软件质量度量模型由三层组成,第一层为质量特性,第二层为质量子特性,第三层称为度量,3.4.1,质量与质量规划,ISO,IEC9126 1991,（,GB,T16260 1996,）标准标准定义的,6,个质量特性,功能性,可靠性,易使用性,高效性,可维护性,可移植性,质量规划,指识别哪些质量标准适用于软件项目，并确定如何满足这些标准的要求,3.4.2,质量体系、质量手册和质量计划,质量体系,指为保证产品、过程或服务质量，满足规定（或潜在）的要求，由组织机构、职责、程序、活动、能力和资源等构成的有机整体。,质量手册,是描述企业,质量体系,的,文件,。,质量计划,是质量管理（质量计划编制、质量保证和质量控制）的第一过程域。,3.4.2,质量体系、质量手册和质量计划,质量体系、质量手册和质量计划之间的关系,质量体系好比一个国家的法制机构，质量手册就如同宪法，是质量体系的文档化的体现。而为每个项目制定的质量计划类似地方法规，它在符合质量手册的前提下，根据自身的要求与特殊性，通过适当的裁减修正而来。,关系图,3.4.3,项目质量计划的内容,项目实施总体目标,质量,时间,成本,三者是一个相互制约、相互影响的统一体，其中任一项目标变化，都会引起另两个目标变化，并受其制约。,项目分类,质量倾斜型体系,工期倾斜型体系,成本倾斜型体系,3.4.3,项目质量计划的内容,编写软件质量计划涉及的范围相当广，不论是项目选型、软件开发各阶段，还是配置管理、岗位职责与团队组织，又或是其他如项目制度的制定等等方面，都应该是包含在项目质量计划中的内容。,3.4.4,质量目标,软件生命周期三大阶段（以传统的瀑布模型为例）,软件定义,软件开发,软件使用与维护,阶段,需要监控的关键元素,问题定义,关于规模和目标的报告书,可行性研究,系统的高层逻辑模型：数据流图,，,成本,/,效益分析,需求分析,系统的逻辑模型：数据流图（,MSC,图），数据字典（类清单、对象间关系）,，,算法描述,总体设计,可能的解法：系统流程图,，,成本,/,效益分析,推荐的系统结构：层次图，结构图,详细设计,编码规格说明,综合测试,综合测试方案和结果,完整性一致的软件配置,维护,完整准确的维护记录,3.4.4,质量目标,各阶段的关键元素,3.4.5,项目质量计划的编写,质量计划,应说明项目管理小组如何具体执行它的质量策略。,目的,规划出哪些是需要被跟踪的质量工作，并建立文档，此文档可以作为软件质量工作指南，帮助项目