设为首页 | 加入收藏夹

八文网 - 汇聚八方文档 - 做最优秀的免费文档下载网站

软件过程

文档类型：

Microsoft PowerPoint PPT 演示文稿文档大小：349.5KB

软件过程,管理和质量李宣东南京大学计算机科学与技术系概要软件过程软件质量保证软件配置管理软件项目管理概念软件过程是近十年来人们关注的焦点.软件过程是为开发高质量软件所需要完成的任务的框架.软件工程是有创造力、有知识的人在定义好的,成熟的软件过程框架中进行的.
软件工程层次图质量焦点过程方法工具软件工程是一种层次化的技术任何工程方法(包括软件工程)必须以有组织的质量保证为基础.全面的质量管理和类似的理念刺激了不断的过程改进、正是这种改进导致了更加成熟的软件工程方法的不断出现.支持软件工程的根基就在于对质量的关注.
软件工程的基层是过程层软件工程过程是将技术层结合在一起的凝聚力、使得软件能够被合理地和及时地开发出来.过程定义了一组关键过程区域的框架,这对于软件工程技术的有效应用是必须的.关键过程区域构成了软件项目管理控制的基础、并且确定了上下各区域之间的关系,规定了技术方法的采用,工程产品(模型,文档,数据,报告,表格等)的产生,里程碑的建立,质量的保证及变化的适当管理.
软件工程的方法层提供了为开发软件在技术上需要如何做.方法涵盖了一系列的任务:需求分析,设计,编程,测试和维护.软件工程方法依赖于一组原则,这些原则控制了每一个技术区域,且包含建模活动和其他描述技术.
软件工程的工具层对过程和方法提供了自动的或半自动的支持.当这些工具被集成起来使得一个工具产生的信息可以被另外一个工具使用时,一个支持软件开发的系统就建立了,称为计算机辅助软件工程(CASE).CASE集成了软件,硬件和一个软件工程数据库(包含了关于分析,设计,编程和测试的重要信息),从而形成了一个软件工程环境.
过程:为实现一个给定目标而进行的一系列运作步骤.
过程具有一系列的性质:时间性,并发性,嵌套性和度量性等.
软件过程:开发和维护软件及其相关产品所设及的一系列活动.过程是活动的集合;活动是任务的集合;任务是把输入转换为输出的操作.
软件过程提供了一个框架,在该框架下可以建立一个软件开发的综合计划:若干框架活动适用于所有软件项目,而不在乎其规模和复杂性.若干不同任务的集合-每一个集合都由任务,里程碑,交付物以及质量保证点组成-使得框架活动适应于不同软件项目的特征和项目组的需求.
若干保护性活动-如软件质量保证、软件配置管理,测试与度量-它们贯穿于整个过程模型之中.保护性活动独立于任何一个框架活动,且贯穿于整个过程之中.
里程碑,交付物SQA点公共过程框架框架活动保护性活动任务集合工作任务
软件过程可分为三大类:
基本过程类:是构成软件生存周期主要部分的那些过程,包括获取,供应、开发,操作,维护等过程.
支持过程类:可穿插到基本过程中提供支持的一系列过程,包括文档开发,配置管理,质量保证、验证、确认,联合评审,审计,问题解决等过程.
组织过程类:一个组织用来建立,实施一种基础结构,并不断改进该基础结构的过程,包括管理,基础、改进、培训等过程.
软件过程模型软件过程模型是软件开发的指导思想和全局性框架,软件过程模型的提出和发展反映了人们对软件过程的某种认识观,体现了人们对软件过程认识的提高和飞跃.
瀑布模型强调阶段的划分及其顺序性,各阶段工作及其文档的完备性,是一种严格线性的,按阶段顺序的,逐步细化的开发模式.定义分析设计编码测试维护
瀑布模型的特点:
结构简单明了;历史较长,应用面广泛、为广大软件工作者所熟悉;已有与之配套的一组十分成熟的开发方法和丰富的支撑工具.
确定了需求分析的绝对重要性,但是在实践中要想获得完善的需求说明是非常困难的;反馈信息慢.
原型模型听取用户意见建造修改原型用户测试运行原型
原型模型的特点:原型作为标识软件需求的一种机制,原型被建造仅是为了定义需求,之后就该被抛弃(或至少部分抛弃);
实际的软件在充分考虑了质量和可维护性之后才被开发.演化软件过程模型人们已经越来越认识到软件就象所有复杂系统一样要经过一段时间的演化.业务和产品需求随着开发的发展常常发生改变,想找到最终产品的一条直线路径是不可能的.
紧迫的市场期限使得难以完成一个完善的软件产品、但可以先提交一个有限的版本以对付竞争或商业的压力;只要核心产品或系统需求能够很好地理解,而产品或系统的细节部分可以进一步定义.
演化模型是利用一种迭代的思想方法,它的特征是使软件工程师渐进地开发逐步完善的软件版本.
增量模型螺旋模型增量1增量2增量3
增量模型的特点:以功能递增的方式进行软件开发能较快地产生可操作的系统;在每一步递增中、都可以把用户开发者的经验结合到不断求精的产品中;
可改善测试效果和降低软件开发总成本.需求定义评审风险分析工程实现
螺旋模型的特点:
把软件开过程组成为一个逐步细化的定义周期(螺旋周期)序列,每经历一个周期,系统就得到进一步的细化和完善;
本质上,具有上述特征的螺旋是一直运转的直到软件退役.有时这个过程处于睡眠状态、但任何时候出现了改变,过程都会从合适的入口点开始;
紧密围绕开发中的风险问题,用风险分析推动软件设计向深一层扩展,求精;
强调持续地判断、确定和修改用户任务目标,并按成本,效益来分析候选的软件产品性质对任务目标的贡献;
可结合采用多种软件开发方法,但究竟结合哪一种方法仍由风险分析来决定.
形式化方法模型形式化方法的主要目的是要把软件开发过程建立在严密可行的数学基础之上,从而提高软件质量和软件生产率.
事后的或并行的一种辅助手段,用以对系统的性质进行严格的验证;集成到软件开发过程中、希望在严格的形式系统的基础上,实现从需求规约到程序代码的转换和过渡.
软件过程管理改进软件过程研究软件过程本质上是为了突出关键过程以改善软件的质量.人们已经得到共识,要提高软件质量必须改进软件过程.
软件机构形成一套完整而成熟的软件过程不是一蹴而就的,它需要一个从无序到有序,从特殊到一般,从定性到定量,最后再从静态到动态的历程,或者说软件机构在形成成熟的软件过程之前必须经历一系列的成熟阶段.
因此有必要建立一个软件过程成熟度模型来对过程作出一个客观,公正的评价,以促进软件开发组织改进软件过程.
软件过程成熟度指一个特定的软件过程被显式定义、管理,度量,控制和能行的程度.成熟度可以用于指示企业加强其软件过程能力的潜力. 当一个企业达到了一定的软件过程成熟级别后,它将通过制定策略,建立标准和确立机构结构使它的软件过程制度化.而制度化又促使企业通过建立基础设施和公司文化来支持相关的方法,实践和过程.从而使之可以持续并维持一个良性循环.
不成熟企业的标志:缺乏确定的软件过程和相应的管理和控制;即使给出了软件过程,也不严格的遵循和强制执行;管理是完全被动的,管理者采用的策略是救火式的,即出了事才去解决,解决的时候也难以纵观全局、往往只顾眼前;
由于缺乏有依据的估算,制订软件预算和生产计划时往往跟着感觉走,实际生产时则常常超标;
如果强制在预定期限内完成,那么软件的功能和质量肯定是得不到保证;
缺乏评价软件产品质量和解决产品缺陷和过程问题的客观基础.
成熟企业的标志:具有在企业范围内管理,控制软件开发和维护过程的能力;现有人员和新进人员均了解所遵循的软件过程,且工作活动均按照事先的计划完成;
在定义好的软件过程中、所有项目和机构中的角色和责任分明;制定的计划是有效的且与实际的工作进展一致;软件过程在必要时可按照一定规则和程序加以修改;
软件产品和过程具有一定的可控性:
1.管理者能够监督软件产品的质量和生产过程;
2.具有客观的和定量化的措施来判断产品质量并分析产品与生产过程中的问题;
3.计划和预算有章可循,它是基于历史数据的,从而是实际可行的;
4.预算的结果,包括成本,时间表,产品功能和质量等、通常能够达到;
5.有关的参与者完全理解遵循软件过程的价值并认真地遵循之;
6.具有支撑软件过程的基础设施,如标准过程库,历史数据库等. 软件能力成熟度模型( Capability Maturity Model,CMM)
软件能力成熟度模型提美国大学Carnegie Mellon University软件工程研究所出的一套系统,规范的对软件生产过程进行管理的模型,其有效性已为大量实践所证实,并已成为对一个软件企业的生产能力和产品质量进行衡量的事实标准.
软件能力成熟度模型(CMM)CMM被用来确定一个机构的软件过程的成熟程度以及指明如何提高该成熟度的参考模型.
CMM描述了软件过程从无序到有序,从特殊到一般,从定性管理到定量管理,最终到达可动态优化的成熟过程,给出了该过程中五个成熟阶段的基本特征和应遵循的原则, 采取的行动,以帮助软件机构改进其软件过程.
CMM的主要作用CMM可以指导软件机构如何控制软件产品的开发和维护过程,以及如何向成熟的软件工程体系演化,并形成一套良性循环的管理文化.具体说来,一个企业要想改进其生产过程,应该采取如下策略和步骤:确定软件企业当前所处的过程成熟级别;了解对改进软件生产质量和加强生产过程控制起关键作用的因素;将工作重点集中在有限几个关键目标上,有效达到改进机构软件生产过程的效果,进而可持续地改进其软件生产能力.
CMM的基本前提软件质量在很大程度上取决于产生软件的软件过程的质量和能力;软件过程是一个可管理,可度量并不断改进的过程;软件过程的质量受到用以支撑它的技术和设施的影响;企业在软件过程中所采用的技术层次应适应于软件过程的成熟度.CMM的基本原理CMM强调连续的软件过程改进.该连续的改进基于多个演化步骤.CMM将这些演化步骤划分成五个级别.这种分级结构的理论依据是软件质量原理.
每一级别都包括若干目标.当满足某一目标后,软件过程的相应部分便确定下来.
五级成熟度定义了一个标准,用以度量机构的软件过程成熟度和评价其软件过程能力.
CMM的基本内容
机构和资源的管理:涉及机构本身的责任,人员和其它资源设施.
软件工程过程及其管理:涉及软件工程过程,即软件过程的深度,范围和完整性以及如何度量,管理和改进这样的过程.
工具和技术:软件工程过程中使用的开发工具和技术.CMM的五个成熟度级别初始级
可重复级:有规章的过程
定义级:标准化,一致的过程
管理级:可预测过程
优化级:可持续改进的过程CMM的初始级(第一级)成功来源于个人英雄主义而非机构行为、因此它不可重复、更换人员后成功便难以维持.
CMM的可重复级(第二级)针对特定软件项目建立管理该项目的策略和实现这些策略的过程.新项目的计划和管理基于类似项目的经验.软件过程能力主要通过管理单个项目的软件生产过程来得到提高和增强.
不同的项目可有不同的软件过程,机构应当建立一定的方针和策略以针对具体的项目选择合适的软件生产过程并进行管理.
可重复级的主要特点在于确定了基本的软件生产管理和控制,具体来讲有:结合已有项目的经验和新项目的特点来确定本项目的责任和承诺;软件生产成本,时间表和实现的功能被有效跟踪;识别实现承诺所需解决的关键问题;定义软件项目过程标准,机构要确保其被遵守.概括来说,第二级的主要特点是项目计划和跟踪是确定且有效的,项目的软件过程是可控的,以及已有的成功经验是可重复的.
CMM的定义级(第三级)
有一个机构范围内标准的软件过程,软件工程活动和管理活动被集成为一个有机的整体.标准化的目的是使高层管理者和软件技术人员能够有效合作.
有一个组例如软件工程组(SEPG)专门负责订立机构的标准软件过程,并且在机构中制定培训计划来确保相关人员和管理者有足够的知识和技能完成标准过程所赋予的角色.
标准的软件过程结合具体项目的特点经过裁剪即形成项目定义软件过程,它是一组集成的完善定义的软件工程和管理过程.
一个完善定义的软件过程应包括就绪准则,输入,工作过程,验证机制,输出和完成准则.
对于已建立的产品生产线,其成本,时间表和实现功能均可跟踪和控制,软件产品的质量可以得到保证.
软件过程能力的实现主要基于在机构范围内对一个定义软件过程的活动,角色和责任的共同理解.
概括来说,第三级的主要特征在于软件过程已被提升成标准化过程,从而更加具有稳定性,重复性和可控性.
CMM的管理级(第四级)
软件的过程和产品有定量的质量指标:重要的软件过程活动均配有生产率和质量方面的度量指标;应用数据库来收集和分析定义软件过程中涉及的各种数据;对项目软件过程和软件质量的评价有定量的基准.软件项目的产品和生产过程的控制具有可预测性:将软件过程效能可能出现的偏差控制在可接受的量化界限内;具体区分影响过程效能发生偏差的有效因素和偶然因素;向新领域拓展的风险是可预知的并被仔细管理和权衡.概括来说,第四级的主要特征是定量化,可预测,异常控制和高质量.
CMM的优化级(第五级)
机构集中于持续的过程改进:具有标识过程缺陷和增强过程能力的有效手段.利用试验数据分析使用新技术所需的代价和带来的效益,然后再有选择地采用.
当出现偏差时,软件项目人员能够分析出错原因并采取有效手段防止其再次出现.
防止不必要的浪费是第五级的重点.改进的途径有两个,一个是对已有过程的渐进式改进;另一个则是有选择地使用新技术和新方法所带来的革新.
概括来说,第五级的主要特征是新技术的采用和软件过程的改进被作为日常的业务活动来加以计划和管理.
如何看待CMM:梯子镜子牌子补药软件质量软件质量定义明确声明的功能和性能需求,明确文档化过的开发标准,以及专业人员开发的软件所应具有的所有隐含特征都得到满足.
软件需求是进行质量度量的基础.与需求不符就是质量不高.指定的标准定义了一组指导软件开发的准则.如果不能遵守这些准则,就极有可能导致质量不高.
通常有一组隐含需求是不被提及的(如对维护性的需求).如果软件符合了明确的需求却没有满足隐含需求,软件质量仍然值得怀疑.
质量要素衡量标准度量McCall模型中的软件质量要素产品修改变迁运行易维护性灵活性易测试性易移植性易复用性互用性正确性可靠性高效率完整性易使用性软件质量保证(SQA)是一种应用于整个软件过程的保护性活动.SQA包括:一种质量管理方法有效的软件工程技术(方法和工具)在整个软件过程中采用的正式技术复审一种多层次的测试策略对软件文档及其修改的控制保证遵从软件开发标准的规程度量和报告机制SQA小组在一个组织中有多个机构负有保证软件质量的责任,包括软件工程师,项目管理者、客户,销售人员和SQA小组成员.
SQA小组负责质量保证的计划,监督,记录,分析及报告工作.SQA小组充当客户在公司内部的代表.这就是说,SQA小组的成员必须以客户的观点看待软件.
SQA计划SQA计划为建立软件质量保证提供一张行路图,其由SQA小组和项目组共同制定,充当软件项目中SQA活动的模板.
需要进行的评价;需要进行的审计和复审;项目可采用的标准;错误报告和跟踪过程;由SQA小组产生的文挡;为软件项目组提供的反馈数量.SQA活动为项目准备SQA计划;参与开发该项目的软件过程描述;复审各项软件工程活动,对其是否符合定义好的软件过程进行核实;审计指定的软件工作产品、对其是否符合定义好的软件过程中的相应部分进行核实;
确保软件工作及工作产品产品中的偏差已被记录在案,并根据预定规程进行处理;
记录所有不符合的部分,并报告给高级管理者;协调变化的控制和管理,并帮助收集和分析软件度量信息.当开发软件系统的过程中、变化是不可避免的.这些变化使得在同一个项目中工作的软件开发人员之间的彼此不理解程度更加增大.当变化进行前没有经过分析,变化实现前没有被记录,没有向那些需要知道的人报告变化,或变化没有以可以改善质量及减少错误的方式被控制时,大量的不理解问题将会产生.
协调软件开发以减少由变化带来的不理解性到最小程度的技术称为配置管理.软件配置管理(SCM)是贯穿于整个软件过程中的保护性活动.
SCM活动内容:标识变化控制变化保证变化被适当地实现向其他可能感兴趣的人报告变化.明确地区分软件维护和软件配置管理是很重要的:维护是发生在软件已经被交付给客户,并且投入运行后的一系列软件工程活动.
软件配置管理则是当软件项目开始时就开始,并且仅仅当软件退出运行后才终止的一组跟踪和控制活动.
软件配置软件过程的输出信息可以分为三个主要的类别:计算机程序(源代码和可执行程序)描述计算机程序的文档(针对技术开发者和用户)数据(包含在程序内部和程序外部).它们包含了所有在软件过程中产生的信息,总称为软件配置.变化的起源
有四种基本的变化源:新的商业或市场条件,引起产品需求和业务规则的变化.新的客户需要、要求修改信息系统产生的数据,产品提供的功能,或基于计算机的系统提供的服务.
改组和或企业规模减小,导致项目优先级或软件工程队伍结构的变化.
预算或进度的限制,导致系统或产品的重定义.软件配置项软件配置项(Software Configuration Items, SCI)定义为部分软件工程过程中创建的信息,在极端情况下,一个SCI可被考虑为某个大的规约中的某个单独段落,或在某个大的测试用例集中的某种测试用例,更实际地,一个SCI是一个文档,一个全套的测试用例,或一个已命名的程序构件(例如,C函数或Ada95软件包).
基线基线是一个软件配置管理的概念,它帮助我们在不严重阻碍合理变化的情况下来控制变化.
IEEE(IEEE Std定义基线如下:已经通过正式复审审核批准的某规约或产品、它因此可以作为进一步开发的基础、并且只能通过正式的变化控制过程而改变.
在软件配置项变成基线前、变化可以迅速而非正式地进行、然而、一旦基线已经建立,我们就得象通过一个单向开的门那样,变化可以进行、但是,必须应用特定的,正式的规程来评估和验证每个变化.
在软件工程的范围内、基线是软件开发中的里程碑,其标志是有一个或多个软件配置项的交付,且这些SCI已经经过正式技术复审而获得认可.
常见的软件基线系统工程软件设计发布系统规约软件需求规约设计规约源代码测试计划过程数据可操作的系统产生基线的流程SCIs正式技术复审SCM控制软件工程任务认可提取存储项目数据库成为基线的SCIs软件项目计划图形分析模型;处理规约;原型;数学规约初步的用户手册数据设计描述;体系结构设计描述;模块设计描述;界面设计描述;对象描述(如果使用面向对象技术)源代码清单测试规约测试计划和过程;测试用例和结果记录操作和安装手册可执行程序模块的可执行代码;链接的模块数据库描述模式和文件结构;初始内容联机用户手册维护文档软件问题报告;维护请求;工程变化命令软件工程的标准和规约除了上面列出的SCI,很多软件工程组织也将软件工具列入配置管理之下,即,特定版本的编辑器,编译器和其他CASE工具被固定作为软件配置的一部分.因为这些工具被用于生成文档.源代码和数据,所以当对软件配置进行改变时,必然要用到它们.虽然问题并不多见、但有可能某工具的新版本(如,编译器)可能产生和原版本不同的结果.为此,工具就象它们辅助生产的软件一样,可以被基线化,并做为综合的配置管理过程的一部分.
SCM过程软件配置管理是软件质量保证的重要一环,其主要责任是控制变化.然而、SCM也负责个体SCI和软件的各种版本的标识,软件配置的审计(以保证它已被适当地开发),以及配置中所有变化的报告.
任何关于SCM的讨论均涉及一系列复杂问题:一个组织如何标识和管理程序(及其文档)的很多现存版本,以使得变化可以高效地进行一个组织如何在软件被发布给客户之前和之后控制变化谁负责批准变化,并给变化确定优先级我们如何保证变化已经被恰当地进行采用什么机制去告知其他人员已经实行的变化
SCM五大任务:标识版本控制变化控制配置审计报告.SCM中对象的标识为了控制和管理软件配置项、每个配置项必须被独立命名、然后用面向对象的方法组织.
有两种类型的对象可以被标识:基本对象和聚集对象.基本对象是软件工程师在分析,设计,编码或测试中创建的文本单元(unit of text) ,例如,一个基本对象可能是需求规约的一个段落,模块的源程序清单或一组用于测试代码的测试用例.
一个聚集对象是基本对象和其他聚集对象的集合.每个对象均具有一组唯一地标识它的,独特的特征:名字,描述,资源表,以及现实.
对象名是无二义性地标识对象的一个字符串;对象描述是一个数据项的列表,它们标识:该对象所表示的SCI类型(如,文档,程序,数据);项目标识符;以及变化和或版本信息;资源是由对象提供、处理,引用或需要的实体,例如,数据类型,特定函数,或甚至变量名也可以作为对象资源;
现实是一个指针,对基本对象而言指向文本单元、对聚集对象而言则指向null.
配置对象的标识也必须考虑存在于命名对象之间的关系,一个对象可被标识为某聚集对象的,关系定义了一个对象层次.
对于软件对象的标识模式必须认可对象在整个软件过程中的演化,在一个对象被确定为基线前、它可能会变化很多次,甚至在基线已经建立后,变化也可能经常发生.有可能为任意对象创建一个演化图,演化图描速了对象的变化历史.
objObj对象演化图SCM中的版本控制版本控制结合了规程和工具以管理在软件工程中所创建的配置对象的不同版本.
SCM中的版本控制可以描述如下:配置管理使得用户能够通过对适当版本的选择来指定可选的软件系统的配置,这一点的实现是通过将属性关联到每个软件版本上,然后通过描述一组所期望的属性来指定(和构造)配置的.
SCM中的变化控制对于大型的软件开发项目,无控制的变化将迅速导致混乱,SCM变化控制结合人的规程和自动化工具以提供一个变化控制的机制.
一个变化请求被提交和评估,以评价技术指标,潜在副作用,对其他配置对象和系统功能的整体影响、以及对于变化的成本预测.
评估的结果以变化报告的形式给出、该报告被变化控制审核者(change control authority, CCA)-对变化的状态及优先级作最终决策的人或小组-使用.对每个被批准的变化生成一个过程变化命令(engineering change order, ECO),ECO描述了将要进行的变化,必须注意的约束,以及复审和审计的标准.
将被修改的对象从项目数据库提取(check out)出来,进行修改、并应用于合适的SQA活动,然后,将对象提交(check in)进数据库,并使用合适的版本控制机制去建立软件的下一个版本.
提交和提取过程实现了两个主要的变化控制要素-访问控制和同步控制:访问控制管理哪个软件工程师有权限去访问和修改某特定的配置对象.
同步控制帮助保证由两个不同人员完成的并行修改不会互相覆盖.基于一个被批准的变化请求和ECO,软件工程师提取出配置对象,访问控制功能保证该软件工程师有权限提取该对象,而同步控制对项目数据库中的该对象加锁、使得当前提取出的版本在被放回以前不能对它作任何其他修改.注意,可以提取出其他的备份,但是,不能进行其他修改.
非正式变化控制:
在SCI变成基线以前、只需要进行非正式的变化控制.配置对象(SCI)的开发者可以进行任何被管理和技术需求证明是合适的修改(只要修改不会影响到在开发者工作范围之外的更广的系统需求),一旦对象已经经过正式的技术复审并已被认可,则创建了一个基线.
项目级变化控制:
一旦SCI变成基线,则项目级的变化控制就开始实施了.这时,为了进行修改、开发者必须获得项目管理者的批准(如果变化是局部的),或CCA的批准(如果该变化影响到其他SCI).在某些情况下,变化需求,变化报告和ECO的正式生成可以省略,然而、需要管理对每个变化的评价,并对所有变化进行跟踪和复审.
正式的变化控制:当软件产品发布给客户时,正式的变化控制就开始实施了变化控制审核者(CCA)在第二和第三层控制上扮演了活跃的角色,依赖于软件项目的规模和性质,CCA可能包含一个人-项目管理者-或一组人(如,来自软件,硬件,数据库工程,支持、市场等五方面的代表).CCA的角色是从全局的观点来评估变化对SCI之外的事务的影响:变化将如何影响硬件变化将如何影响性能变化将如何改变客户对产品的感觉变化将如何影响产品的质量和可靠性这些和很多其他的问题需被CCA处理.SCM中的配置审计标识,版本控制和变化控制帮助软件开发者维持秩序,否则情况可能将是混乱和不固定的.然而、即使最成功的控制机制也只能在ECO产生后才可以跟踪变化.我们如何帮助变化被合适的实现呢回答是两方面的:
(1)正式的技术复审;
(2)软件配置审计.正式的技术复审关注已经被修改的配置对象的技术正确性,复审者评估SCI以确定它与其他SCI的一致性,遗漏,及潜在的副作用,正式的复审应该对所有的变化进行、除了那些最琐碎的变化之外.
软件配置审计通过评估配置对象的通常不在复审中考虑的特征、而形成正式复审的补充.审计询问并回答如下问题:在ECO中说明的变化已经完成了吗加入了任意附加的修改吗是否已经进行了正式的技术复审,以评估技术的正确性是否适当地遵循了软件工程标准变化在SCI中被显著地强调(highlighted)了吗是否指出了变化的日期和变化的作者配置对象的属性反应了变化吗是否遵循了标注变化,记录变化并报告变化的SCM规程所有相关的SCI被适当修改了吗在某些情况下,审计问题被作为正式的技术复审的一部分而询问,然而、当SCM是一个正式的活动时,SCM审计由质量保证组单独进行.
SCM中的状态报告配置状态报告(Configuration status reporting, 有时称为status accounting)是一个SCM任务,它回答下列问题:发生了什么事谁做的此事此事是什么时候发生的将影响别的什么吗
配置状态报告(CSR)的信息流如下:每次当一个SCI被赋上新的和修改后的标识时,则一个CSR条目被创建;
每次当一个变化被CCA批准时(即,一个ECO产生),一个CSR条目被创建;
每次当配置审计进行时,其结果作为CSR任务的一部分被报告.CSR的输出可以放置到一个联机数据库中、使得软件开发者或维护者可以通过关键词分类访问变化信息.此外,CSR报告被定期生成,并允许管理者和开发者评估重要的变化.
配置状况报告在大型软件开发项目的成功中扮演了重要角色,当涉及到很多人员时,有可能会发生左手不知道右手在做什么的综合症:两个开发者可能试图以不同的或冲突的意图去修改同一个SCI;软件工程队伍可能花费几个月的工作量针对过时的硬件规约建造软件;
能认识到被建议的修改有严重副作用的人并不知道该修改已经进行.CSR通过改善所有相关人员之间的通信,帮助排除这些问题.SCM标准在过去20年中、已经提出了一系列的软件配置管理标准.很多早期的SCM标准,如和MIL-STD1521A,主要用于为军事用途而开发的软件.然而、最近的ANSIIEEE标准,如ANSIIEEE Std. NoNo和Std. No可应用于商业软件,并被向大型的和小型的软件工程组织推荐.
软件项目管理项目管理的基本概念软件项目估算风险管理项目进度安排及跟踪软件项目管理是软件工程的保护性活动,它先于任何技术活动之前开始,并且持续贯穿于整个计算机软件的定义、开发和维护之中.
项目管理的范围
有效的项目管理集中于三个P上:人员(people)问题(problem)过程(process)
其顺序不是任意的.任何管理者如果忘记了软件工程是人的智力密集的劳动,他就永远不可能在项目管理上取得成功;任何管理者如果在项目开发早期没有支持有效的用户通信,他有可能为错误的问题构造一个不错的解决方案.最后,对过程不在意的管理者可能冒把有效的技术和工具插入到真空中的危险.
项目管理的人员项目参与者项目负责人软件项目组
高级管理者:负责确定商业问题,这些问题往往对项目产生很大影响.
项目(技术)管理者:必须计划,激励,组织和控制软件开发人员.
开发人员:负责开发一个产品或应用软件所需的专门技术人员.
客户:负责说明待开发软件的需求的人员.
最终用户:一旦软件发布成为产品、最终用户是直接与软件进行交互的人.
解决问题:一个有效的软件项目负责人应该能够准确地诊断出技术的和管理的问题;系统地计划解决方案;适当地激励其他开发人员实现解决方案;把从以前的项目中学到的经验应用到新的环境下;如果最初的解决方案没有结果,能够灵活地改变方向.
管理能力:一个好的项目负责人必须掌管整个项目,他在必要时必须有信心进行控制,必须保证让优秀的技术人员能够按照他们的本性行事.
激励能力:为了提高项目组的生产率,项目负责人必须奖励具有主动性和作出成绩的人.并通过自己的行为表明约束下的冒险不会受到惩罚.
理解和控制能力:一个有效的项目负责人必须能够读懂人;他必须能够理解语言的和非语言的信号,并对发出这些信号的人的要求做出反应.项目负责人必须在高压力环境下保持良好的控制能力.
项目分配人力资源的若干可选方案,设该项目需要n个人工作k年:
n个人被分配来完成m个不同的功能任务,相对而言几乎没有合作的情况发生;协调是软件管理者的责任,而他可能同时还有六个其他项目要管.
n个人被分配来完成m个不同的功能任务(m

ppt文档的标签：过程软件

更多推荐标签：二外法语试卷王占玉联盟运营论文裁判离婚网络危害婚庆策划书食品市场精益术语汇编日本花道电工学第三版关于问题统计调查降级考核通信巡检制度公关活动模式制度结构楼盘市调查表手机保修手册生活补助申请声力电话原理 ·éèè 代码下载网吧安全预案总理媒体联盟自查自咎矢量控制毕业实习体会不安全放行小猪唏哩呼噜