Ch可重复性管理PPT格式课件下载.ppt

上传人:wj 文档编号:4609134 上传时间:2023-05-03 格式:PPT 页数:79 大小:619KB
下载 相关 举报
Ch可重复性管理PPT格式课件下载.ppt_第1页
第1页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第2页
第2页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第3页
第3页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第4页
第4页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第5页
第5页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第6页
第6页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第7页
第7页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第8页
第8页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第9页
第9页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第10页
第10页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第11页
第11页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第12页
第12页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第13页
第13页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第14页
第14页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第15页
第15页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第16页
第16页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第17页
第17页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第18页
第18页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第19页
第19页 / 共79页
Ch可重复性管理PPT格式课件下载.ppt_第20页
第20页 / 共79页
亲,该文档总共79页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

Ch可重复性管理PPT格式课件下载.ppt

《Ch可重复性管理PPT格式课件下载.ppt》由会员分享,可在线阅读,更多相关《Ch可重复性管理PPT格式课件下载.ppt(79页珍藏版)》请在冰点文库上搜索。

Ch可重复性管理PPT格式课件下载.ppt

必须把系统的要求分配给软件需求、硬件需求、以及人(或其他)的操作需求:

这样的分配过程,在大系统研制过程中,往往不是有软件工程组决定的(例如,是由系统工程小组分配的)。

因此,许多情况下,软件工程组不能决定和控制这种分配。

在项目的约束条件下,软件工程组要采用适当的步骤,保证系统分配给软件的需求被表达、编写成正式文档、并控制其变更。

SystemRequirements系统需求,HardwareRequirements硬件需求(项),SoftwareRequirements软件需求(项),HumanRequirements操作人员需求(项),需求管理的目标,1)控制分配需求以建立软件工程和管理所使用的基线。

通常系统工程组会将模糊的需求,或者,只要硬件没法实现的,都交给软件实现。

高估软件的能力,并带来风险。

需求不清晰、以及今后的不断变更造成项目的失败。

建立基线,掌握“类似”的需求,从而达到“可重复”。

2)软件计划、工作产品和活动与分配需求相一致。

开发计划往往会偏离实际的软件需求,直接依据项目经理或客户要求,定义进度和工作产品。

需求与项目的可重复性,需求是项目的最基本输入,也是决定项目之间是否具有类似的基本依据。

当需求清晰后,我们就能对项目的规模、问题领域、大致的软件体系结构、人员所需、时间进度、软件质量要求(包括功能和非功能性)有一个大概的了解。

找出“类似”项目,达到可重复!

一旦需求是非常不稳定的(在开发过程中,不断变更),以前的项目经验就失去意义。

项目的“可重复性”就成为空话!

顺利到达目的地的最快、最安全的路线是你最熟悉的路线!

对功能性需求的理解,可以澄清许多问题,例如:

1)软件需求文档中的用例图(usecases)和部署图能让我们了解未来的系统如何使用和部署。

2)哪些需求的实现难度大、风险大?

通过对非功能性需求的理解,可以澄清许多问题,例如,1)对开发环境、运行环境的理解,能让项目组估计出软件的难度。

2)对行业标准等的理解,可以掌握足够的项目知识,建立与客户的共同理解。

3)对编程语言、数据库等要求的理解,可以清楚对人力资源的要求。

项目的类似性,通过对功能和非功能性需求的理解,我们能够知道所谓的“类似项目”类似在哪些方面,例如,编程语言、用户的行业背景、数据库、软件规模、人力资源、进度、软件缺陷率的要求等。

特别是非功能性的要求,对于确定项目之间是否具有可比性,起着决定性的作用。

例如,实验室使用的求解微分方程的软件与运载火箭上求解微分方程软件,在功能上是一样的。

但是软件质量和运行环境的差别,造就了后者比前者要付出几十倍的费用代价。

例:

针对非功能性需求的改进,EngineeringIngegneriaInformatticaSPA意大利的一家大型软件工厂,420员工,1994年营业额3500万ECU。

目的解决预算的准确性方法扩展开发理念,增强正式说明书中非功能需求(例如易用性、可靠性、可移植性)说明,使得这些因素对软件造成的影响可以在整个开发过程中被跟踪建立自我加强型的生命周期,了解这些因素的影响,从而更好地制定评估和项目计划。

针对非功能性需求的改进,商业收益实验的6个项目,从最初的25%预算误差减少到8%(方法只用于不小于250000ECU的项目),将非功能性需求文档化,基于以前的经验计划合适的活动,精确费用预算和资源分配,培训客户关于软件质量的问题展示软件能力,项目管理和利润率改进,从需求到开发活动映射的相关知识,SoftwareProjectPlanning软件项目策划(SPP),项目策划,策划的目的和目标“项目策划”的目的在于建立并维护规定项目各项活动的计划。

“项目策划”包括制订项目计划、与共益者(stakeholders)进行适当交流并且就计划达成一致和维护计划。

“策划工作”是从那些规定产品和项目的需求开始,包括对工作产品和作业的属性及所需资源进行评价、协商各项承诺、拟订进度,以及识别和分析项目风险。

项目计划的开发过程,优化级-不断改进,项目策划中的问题,制定一个项目计划的关键是对产品规模、资源、时间进度的估计。

COCOMO最初发表于1981年巴里勃姆(BarryBoehm)软件工程经济学一书中,作为在软件项中估算工作量、成本以及时间进度表的模型。

巴里勃姆于1981年在该公司担任软件研究与技术总监。

COCOM是基于对TRW飞机制造公司的63个项目的研究。

这些项目所包含的代码量从2000行到10000行,包含的编程语言从汇编语言到PL/I。

这些项目采用瀑布模型进行软件开发,这种开发模式是在1981年时主流的软件开发模式。

1997年开始研发“COCOMOII”,并最终于2001年发表于软件成本估算:

COCOMO模型方法,项目开发中的交流方式,软件的工程管理,项目的组织结构,1972年,首次在IBM使用,矩阵式的组织结构,S,E,M1,M2,M3,M4,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,Requirements,Design,Coding,Integration/testing,Delivery,以瀑布模型为基础的项目计划网络图例,M:

评审点T:

工程任务,关键路径,时间进度,活动时间线,员工工作分配,4,/,7,1,1,/,7,1,8,/,7,2,5,/,1,/,8,8,/,8,1,5,/,8,2,2,/,8,2,9,/,8,5,/,9,1,2,/,9,1,9,/,9,T,4,T,8,T,1,1,T,1,2,T,1,T,3,T,9,T,2,T,6,T,1,0,T,7,T,5,张三,李四,Anne,Mary,Jim,风险管理,Boehm的十个顶级风险项(RiskItem)人员流失(Personnelshortfalls)不实际的进度和财政预算开发错误的软件功能开发错误的用户界面种金子不断的需求更改外部完成的任务的不满足外部提供部件的不满足实时性能不满足过分强调计算机科学的能力,计划的可重复性,简单的计算往往是不可行的。

简单公式:

所需人天=工作量/工作效率并假:

设员工随时可用实际上企业的管理者不希望员工没事做一个员工可能要同时做多个项目员工的风险是最大的风险可重复:

预计到一系列的风险考虑到各种资源等参考原先成功项目的经验吸取失败项目的教训,SoftwareProjectTrackingandOversight软件项目跟踪和监督(SPTO),项目跟踪与监督,软件项目跟踪和监督要达到的目标为:

1)依据软件项目计划跟踪实际结果和性能。

2)在实际结果和性能明显偏离软件计划时,采取纠正措施并加以管理,直到结束。

3)受影响的组和个人同意对软件承诺的更改。

按照(文档化的)估计、承诺和计划,跟踪和评审软件各阶段完成的情况和结果,并根据实际完成情况和结果调整这些计划。

“软件项目计划”是跟踪软件活动、通报状态和修订计划的依据。

项目管理者需要监控软件项目活动的状态。

特别是在项目计划规定的里程碑和基线处,一定要将实际完成的软件规模、工作量、成本和进度与计划进行比较,以准确判断实际进展情况。

跟踪的准确性,从软件的开发角度来看,大多数情况下,0%和99%的完成,其效果几乎是一样的。

提升软件开发过程可见性的方法是,在0%与100%之间设立合理的刻度(度量指标),用更精确的指标让管理者更清楚实际的进展情况。

下面的例子是对刻度的一些建议:

每个检查点必须是特定的和可测量的,例如:

50%的需求文档全部通过评审,而不是每个文档都完成50%。

50%模块设计完成、执行设计评审以及纠错工作。

25%模块通过编译,而没有错误。

15%的程序通过测试,执行没有错误。

用户手册的第一个草稿完成,并提交技术评审。

在项目计划中以及监督时,使用数字要有准确的百分比,否则就失去意义,例如:

50%的模块完成设计,应当规定为,共有100个模块,其中的50个模块100%完成,而不是所有的模块平均完成50%(可能意味着,一个模块也没完成)。

所有的测试用例都测过一遍,通过率达100%,而不是简单地说:

通过测试。

开发队伍的组织形式,层次组织形式矩阵形式主程序员形式SWAT形式Agile形式开源软件开发,开发队伍的组织形式,层次组织形式,开发队伍的组织形式,矩阵形式-移动网络,主程序员形式,开发队伍的组织形式,SWAT形式采用渐进式、迭代的过程SWAT(SkilledWithAdvancedTools)4-5人左右,一起办公信息交流快捷,无正式会议头脑风暴或白板画图增量式开发重用部件良好的工作流程管理高昂的工作激情,开发队伍的组织形式,Agile形式某些类似于SWAT更依赖于人,而不是队伍“计划驱动”在这里成为个人能力充分发挥,而不受到任何的约束项目的跟踪变得苦难!

避免项目风险要靠人,被动使用者,开发队伍的组织形式,开源软件开发“没有围墙的公司”没有合同开发进度没有计划,缺乏文档出现Bug,不知何时能定位和解决没法做到项目跟踪和监督,积极使用者,合作开发者,核心队伍,实际与计划差异,实际情况总是与计划具有差异的计划颗粒度越细,差异可能越大,越理想的计划,差异越大各种风险的发生,可能导致计划的很大程度上的改变记录这些差异(进度、工作量、费用等)估计和计算出员工生产能力的曲线今后项目的计划可能做的更准确,项目跟踪与监督颗粒度和工作量,计划跟踪的颗粒度越细,工作量越大作为项目经理,如果你跟踪到每行代码,你会抱怨“还不如自己开发”,你就又把工程做成了“艺术”。

记录这些偏差(进度、工作量、费用等)避免太频繁的干涉细小的偏差用经验,使其偏差在容忍的范围内如果一个项目的报告中讲,进度和质量(缺陷)没有任何的偏差,这篇报告极可能就是假的。

如果每天都开评审会议,额外工作量将引起员工的疲惫,导致代码或文档质量的下降,SoftwareQualityAssurance软件质量保证(SQA),软件质量保证,当“哥们式”的生产关系被打破后就需要建立一套制度,以便于:

1)寻找摆脱繁杂的管理工作的方法,使得经理们有更多的时间开展或监督员工的开发工作;

2)雇佣一些人做审计工作;

3)鼓励员工相互监督质量。

质量管理过程与开发过程的独立性,过程质量观点,对于制造类的产品,过程与产品质量具有直接的关联关系对于软件,问题要复杂的多,因为;

个人能力和经验的重要性外部因素,如,新的发明,进度加快等,都会导致质量问题.统计学的质量控制方法,对于软件是适用的,过程质量观点,定义过程,开发产品,评估产品质量,质量OK?

改进开发过程,标准过程,定义标准,如:

评审规则配置管理等监督开发过程,保证标准得到执行将质量报告给项目管理和软件购买者,实施过程中的质量,定义标准是进行有效质量管理的关键国际、国家、企业、项目标准项目管理者的重点是剪裁和定义出适合项目的标准产品标准(Productstandards)定义软件部件的特性,如编程风格。

过程标准(Processstandards)定义软件的开发过程,质量保证和标准,采纳最好的实践,避免错误的重复质量保证过程框架,检查标准的兼容性连续性新员工可以很好地理解组织的规定、项目的规定,标准的重要性,产品和过程标准例子,软件质量保证的目标,1)软件质量保证活动是有计划的。

2)软件产品及其活动遵循所用的标准、规程和需求的情况得到客观的验证。

3)受影响的组和个人接到软件质量保证活动和结果的通知。

4)高层管理者处理软件项目内部无法解决的不符合问题。

对SQA的误解,1)把SQA的工作简单地等同于软件测试工作。

当软件质量问题比较大时,认为是测试人员测试不够所引起的。

这种观点忘记了“测试只能表明程序的错误,而不能证明程序正确”的论断。

2)把SQA作为一种摆设,只是对外部客户的宣称,让新来的员工担任就行。

这种观点,削弱了SQA应当承担的过程可视性的作用。

3)认为SQA人员要解决一切质量问题。

SQA人员要做所有的评审、测试等工作。

这种观点,将SQA人员的工作过度理想化。

4)除非开发经理要求SQA帮助做些工作,否则SQA就不管开发的事。

这种观点,将使得SQA不能发挥作用,长此以往,软件开发队伍将逐步退化为黑箱式的开发状态(回到CMM一级所描述的混乱状态)。

SQA责任,建立SQA制度和小组,并要确保SQA能够:

1)评审所有(或抽检)的开发计划和质量计划是否完整2)作为审查的协调人,参加设计和代码的审查;

3)评审所有的测试计划,是否遵循标准;

4)对重要的测试结果进行评审,确定是否符合计划要求;

5)定期对SCM的工作和性能进行评审,确定是否符合标准;

6)定期参加所有项目的阶段评审,确认标准和规程是否得到合理的满足。

SQA人员培养,SQA的重要性是由承担SQA工作人员所担负的。

SQA人员的挑选和培养对于企业是十分重要的。

这就像国家的审计人员一样,需要从“德”和“技”两个方面挑选和培养SQA人员。

一种可能的解决方案是,让那些准备提升的项目经理,在上任前担当一段SQA工作;

或者,让项目经理与SQA人员进行互换。

这种方法可以确保开发队伍和SQA人员的相互理解,增强共同合作的精神。

SoftwareConfigurationManagement软件配置管理(SCM),配置管理(ConfigurationManagement)更准确的应当称为:

配置项管理,也就是对生产过程中能够单独存在、功能独立的项进行有效的管理。

例如,可独立配置的软件项、部件、单元、数据文件及其操作等。

配置管理并不是软件行业的发明。

在现代工业生产中,最成熟配置管理也许是机械行业。

那里的配置项是:

一个部件、一台发动机、一个螺钉等)例如,在汽车行业的研发、生产、使用和维护。

特别是为汽车使用安全所建立的缺陷招回制度,是对配置管理成功的应用。

建立SCM的需要,在软件的开发和使用,同样存在配置管理问题。

随着企业规模的扩大,所承担的项目越来越多。

如果每个项目都从第一行代码编起,也许这家公司永远也没法获得利润。

有效的方法是建立可以重复使用的软件库。

事实上,我们在程序开发中基本上都在使用其他人已经做好的软件库,进行软件的开发。

例如,我们使用C语言编程时,一旦需要使用数学库,我们只需要在程序中写上#include,就意味着,我们使用编译产品厂家提供的数学库。

因此,我们不用再编写sin(x)、log(x)等的程序。

在C语言的编程中,可能最普遍使用的是#include。

stdio(标准输入输出)库提供了最基本的输入输出,例如,printf等。

建立SCM的需要,要做到项目的可重复,最基本的做法也是尽可能地重复使用其他人做好的或先前项目使用过的代码。

即,建立可重用库,从项目上做到对代码的重用。

重用库的代码可以是二进制目标码的形式,也可以是源代码的形式。

可重用的运行库,既可以是静态库,也可以是动态库。

静态库中提供的函数功能,在进行连接(link)时,被加入到可执行程序中。

而动态库在连接(link)时,只是说明了库函数加载的地址,只有在运行时才加载。

必须建立新的软件版本,随着下面因素的变化:

不用的硬件和OS;

提供不同的功能;

针对客户需求的定制和剪裁。

配置管理涉及到对软件进化的管理系统更改时一个团队活动;

CM的目的之一是控制软件更改中所产生的费用和工作量,软件版本变更,建立SCM的需要,1)软件的需求是不断变化,从而导致主要功能一样的软件可具有多个版本;

2)软件中的错误,导致软件版本的不断升级;

3)一段代码是多个程序员共同完成的,某个人对自己那块代码的修改,可能引起整个或其他人的代码的错误。

4)代码被大家共享,一旦修改,而没有通知到其他使用者,版本的管理就会出错;

5)企业的许多客户已经在使用我们的软件,而每个客户可能使用的版本都不一样。

企业需要保留和维护每个客户的版本,从而造成人力资源(越来越多的维护工程师)的极大浪费。

SCM的步骤,1)确定被管理的对象(级别等)2)管理(入库、修改等)的权限3)给被管理对象唯一的一个编号(标识号)4)控制对被管理对象的修改5)跟踪和记录其修改,实现SCM的关键,首先,要搞清被管理的项。

依据管理的精细度,一个被管理项可以划分为一个软件系统或子系统、一个计算机软件配置项(CSCI)、一个计算机软件部件(SC)、一个计算软件单元(CSU),甚至是一段关键的核心代码。

除此之外,被管理项还应当包括相关的软件开发、使用和维护性的文档,以及开发环境、运行环境等。

一旦确定或定义了被管理项,就要给其一个唯一的标识号(ID)。

这个ID应当在其生命周期里是始终有效的,且是唯一的。

唯一性能够让用此软件项进行项目开发的开发人员、使用人员和维护人员,能够依据ID正确识别被管理的项。

这就像社会管理部门要分发给每个人一个身份证号一样。

实现SCM的关键,其次,对被管理项建立了唯一标识号后,接下来的问题是如何控制对被管理项的状态和修改。

例如,在交通管理中,汽车作为被管理项。

交通部门给每辆汽车一个牌号,并对汽车的发动机编号、车架的编号也进行登记备案。

其目的是防止对汽车在其生命周期内轻易地更改,以便于控制对于被管理的软件项,同样要控制其更改。

与汽车中的配置项更改不同的是,软件的更改不仅是本软件开发者的事情,还会涉及所有使用此软件项的软件系统、使用者、相关的程序员。

另一方面,软件代码的修改可见性(例如,比汽车牌号等修改的可见性)差。

人们很难发现被修改的代码,以及无法估计所修改的代码会产生多大的影响(包括正面和负面的)。

因此在企业中,最好的方法是建立一个更改控制委员会(CCB),站在企业的高度审视和评审各种修改,把修改所带来的负面影响降到最低。

再者,人们的记忆能力是有限的。

解决的方法是对任何软件项的修改、委员会决定是否修改的意见、以及与修改相关的各种情况进行记录与存档。

以便,人们能够对修改过程进行评审和回顾。

综合上述,我们看到,实现配置管理里的关键是:

标识(被管理的项)、控制(其修改)、记录(其状态)。

SCM的流程,标识(被管理的项)、控制(其修改)、记录(其状态),更改库,则要存放确认的更改,包括:

1)每个模块的修改层次。

2)所使用的汇编器、编译器、连接器、装载程序以及可执行程序和测试。

3)测试用例和修改层次。

4)测试数据。

5)所使用的文件。

6)组成系统的软件、硬件、外围设备以及硬件的更改层次。

7)操作和使用过程。

8)如果有非单独的测试,还要给出执行的(批命令)流程。

配置管理的颗粒度,颗粒度的定义要考虑下列几个主要因素:

1)代码的重要性。

2)模块的大小。

3)企业的人力资源状况。

4)产品的研发周期等。

颗粒度可以简单地划分为:

重用库级的、部件级的、单元级的。

配置管理级别和工作量,CSCI,CSC,CSC,CSU,CSC,CSU,CSC,CSC,CSC,CSU,CSU,库,非开发软件,System,CSCI,CSCI,单元/语句级别,部件/库级别,配置项级别,系统级别,管理工作量,小,大,版本的标识,版本标识的规程,确保所标识的部件版本没有二义性是那种基本方法:

版本编号(Versionnumbering);

属性标识(Attribute-basedidentification);

面向更改的标识(Change-orientedidentification).,标识的编号,版本标识的规程,确保所标识的部件版本没有二义性是那种基本方法:

面向更改的标识(Change-orientedidentification).,初始版

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

当前位置:首页 > PPT模板 > 商务科技

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2