软件工程理论与实践 课件 第14章 软件工程管理-1_第1页
软件工程理论与实践 课件 第14章 软件工程管理-1_第2页
软件工程理论与实践 课件 第14章 软件工程管理-1_第3页
软件工程理论与实践 课件 第14章 软件工程管理-1_第4页
软件工程理论与实践 课件 第14章 软件工程管理-1_第5页
已阅读5页,还剩58页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

第14章

软件工程管理本章介绍软件估算软件开发进度计划、软件开发人员组织、软件开发风险管理、软件质量保证、软件配置管理。软件工程标准与软件文档、软件过程能力成熟度模型和软件项目管理等相关概念。本章概述20%30%40%50%本章目标了解软件估算的概念、方法、原则与技巧。掌握制订软件开发进度计划的方法。了解软件开发人员组织的形式。了解软件开发风险管理的概念。了解软件质量保证的措施。了解软件配置管理的相关概念。熟悉软件工程标准与软件文档的概念。熟悉软件过程能力成熟度模型。了解软件项目管理的相关内容目录414.4软件质量保证14.5软件配置管理14.6软件工程标准与软件文档14.7软件过程能力成熟度模型14.8软件项目管理14.1软件估算14.1软件开发进度计划14.2软件开发人员组织14.3软件开发风险管理14.1

软件估算14.1.1软件估算的概念14.1.2软件估算的方法14.1.3软件估算的原则与技巧14.1.1软件估算的概念软件估算是指以准确的调查资料和项目信息(如人员和设备信息)为依据,从估算对象的历史、现状及其规律性出发,运用科学的方法,对估算对象的规模、所需工作量和成本进行的测定。614.1.1软件估算的概念软件估算的内容包括软件规模、工作量和进度。对于估算来说,有些可以做的很仔细,而大多数只是凭主观经验判断。所以多数估算难以做到10%以内的精确度,有的甚至误差达几倍,尤其是估算人员经验不足或估算项目没有可参考凭借之时。不同的软件开发阶段,估算的对象和使用的方法都会有所不同,估算的精确度也不一样。一般来说,随着项目进展,对项目内容了解愈多,估算也会越来越精确。7软件估算的内容包括软件规模、工作量和进度。对于估算来说,有些可以做的很仔细,而大多数只是凭主观经验判断。所以多数估算难以做到10%以内的精确度,有的甚至误差达几倍,尤其是估算人员经验不足或估算项目没有可参考凭借之时。14.1.1软件估算的概念不同的软件开发阶段,估算的对象和使用的方法都会有所不同,估算的精确度也不一样。一般来说,随着项目进展,对项目内容了解愈多,估算也会越来越精确。80%40%80%60%40%90%软件估算的方法有功能点估算法、代码行(LOC)估算法、COCOMO估算法、软件方程式估算法、类比估算法、WBS估算法、Delphi估算法、PERT估算法、综合估算法等。14.1.2软件估算的方法2143TEXTHERE(1)估算时间越早,误差越大。但有估算总比没估算好。(2)估算能够用来辅助决策。良好的估算有利于项目负责人做出符合实际的决策。(3)在项目计划中预留估算时间,并做好估算计划。(4)避免无准备估算,估算前能收集到越多数据,越利于提高估算结果的准确度。(5)估算尽量实现文档化,以便于将估算经验应用于以后的估算中。(6)尽量结合以前的项目估算的数据和经验,有利于提高当前估算的准确度。14.1.3软件估算的原则与技巧2143TEXTHERE14.1.3软件估算的原则与技巧(7)估算工作单元最好有一个合适粒度,而且各单元之间最好相互独立。(8)尽量考虑到各类因素,如假期、会议、验收检查等影响估算结果的因素。(9)尽量让专业人士做估算员,如涉及代码量的,最好让负责实现该任务的程序员来估算。(10)使用估算工具,提高估算精度和速度。(11)结合多种估算方法,从不同角度进行估算。(12)不隐藏不确定的成本,应在估算中考虑潜在风险。(13)不为满足预算和预期目标而改变估算结果,不能对估算结果进行随意的删改。14.2软件开发进度计划14.2.1Gantt图14.2.2PERT图项目管理者的目标是定义全部项目任务,识别出关键任务,规定完成各项任务的起、止日期,跟踪关键任务的进展状况,以保证能及时发现拖延进度的情况。为了做到这一点,管理者必须制订一个足够详细的进度表,以便监督项目进度,并控制整个项目。14.2软件开发进度计划14.2.1Gantt图Gantt图(甘特图)是一种能有效显示行动时间规划的方法,也叫横道图或条形图。甘特图把计划和进度安排两种职能结合在一起,纵向列出项目活动,横向列出时间跨度。每项活动计划或实际的完成情况用横道线表示。横道线还显示了每项活动的开始时间和终止时间。某项目进度计划的甘特图如图所示。1414.2.2PERT图PERT图也称“计划评审技术”,它采用网络图来描述一个项目的任务网络。不仅可以表达子任务的计划安排,还可以在任务计划执行过程中估计任务完成的情况,分析某些子任务完成情况对全局的影响,找出影响全局的区域和关键子任务。以便及时采取措施,确保整个项目的完成。1514.2.2PERT图PERT图是一个有向图,图中的有向弧表示任务,它可以标上完成该任务所需的时间;图中的结点表示流入结点的任务的结束,并开始流出结点的任务,这里把结点称为事件。只有当流入该结点的所有任务都结束时,结点所表示的事件才出现,流出结点的任务才可以开始。事件本身不消耗时间和资源,它仅表示某个时间点。每个事件有一个事件号和出现该事件的最早时刻和最迟时刻。每个任务还有一个松弛时间,表示在不影响整个工期的前提下,完成该任务有多少机动余地。松弛时间为0的任务构成了完成整个工程的关键路径。1617PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间,还给出了任务之间的关系,即哪些任务完成后才能开始另外一些任务,以及如期完成整个工程的关键路径。

松弛时间则反映了完成某些任务是可以推迟其开始时间或延长其所需的完成时间。但是PERT图不能反映任务之间的并行关系。某项目的PERT图如左图所示关键路径如图中粗黑线可见该项目最短完成时间为70。14.2.2PERT图14.3软件开发人员组织14.3.1民主制程序员组14.3.2主程序员组14.3.3现代程序员组为了成功地完成软件开发工作,项目组成员必须以一种有意义且有效的方式彼此交互和通信。如何组织项目组是一个管理问题,管理者必须合理地组织项目组,使项目组有较高生产率,能够按预定的进度计划完成所承担的工作。40%50%经验表明,项目组组织得越好,其生产率越高,而且产品质量也越高。组织软件开发人员的方法,取决于所承担的项目的特点、以往的组织经验以及软件开发公司负责人的看法和喜好。14.3软件开发人员组织优点:对发现错误抱着积极的态度,这种积极态度有助于更快速地发现错误,从而导致高质量的代码;小组有高度凝聚力,组内学术空气浓厚,有利于攻克技术难关。因此,小组成员间的通信是平行的,即如果一个小组有n个成员,则可能的通信信道有n(n−1)/2条。缺点:小组人多的话,通信量会非常大;如果组内多数成员技术水平不高,或是缺乏经验的新手,很有可能不能完成项目。民主制程序员组的一个重要特点是,小组成员完全平等,享有充分民主,通过协商做出技术决策。14.3.1民主制程序员组为了使少数经验丰富、技术高超的程序员在软件开发过程中能够发挥更大作用,程序设计小组也可以采用主程序员组的组织方式。使用“主程序员组”的组织方式,可提高生产率,减少总的人/年(或人/月)数。传统的主程序员需要拥有过硬技术,同时具备管理能力。主程序员处理所有接口问题(程序员之间不需要沟通信道),为所有代码负责。后备程序员协助主程序员,主要负责程序测试的有关工作。编程秘书则完成全部事务性工作,如文档维护,编译程序,测试用例等等。这种方式对团队成员尤其是主程序员的要求很高,已经有一些过时。14.3.2主程序员组实际的“主程序员”应该由两个人来担任:

一个是技术负责人,负责小组的技术活动;一个是行政负责人,负责所有非技术的管理决策。14.3.3现代程序员组由于程序员组的成员人数不宜过多,当软件项目规模较大时,应该把程序员分成若干个小组(每组2-8人)。结合民主制程序员组和主程序员组的优点,根据项目实际情况,在合适的地方采用分散决定的方式,有利于形成畅通的通信渠道,充分发挥每个程序员的积极性与主动性。14.4软件开发风险管理14.4.1软件开发风险14.4.2软件开发风险管理软件开发风险是一种不确定的事件或条件,一旦发生,会对项目目标产生某种正面或负面的影响。风险有其成因,同时,如果风险发生,也导致某种后果。风险大多数随着项目的进展而变化,不确定性会随之逐渐减少。14.4.1软件开发风险可变性随机性相对性风险总是相对项目活动主体而言,同样的风险对于不同的主体有不同的影响风险事件是否发生、何时发生、后果怎样?许多事件发生都遵循一定统计规律,这种性质叫随机性辩证唯物主义认为,任何事情和矛盾都可以在一定条件下向自己的反面转化,这里的条件指活动涉及的一切风险因素,当这些条件发生变化时,必然会引起风险的变化。14.4.1软件开发风险14.4.1软件开发风险26按照不同的分类标准,风险可以分为不同的类别。14.4.2软件开发风险管理风险管理就是预测在项目中可能出现的最严重的问题(伤害或损失),以及采取必要的措施来处理。27确定风险关注点估计损失大小评估损失概率计算风险暴露量实施整个项目的延期实施整个项目的缓冲风险分析制定风险管理计划风险监控风险化解风险优先级收集资料估计项目风险形势判定风险风险判定14.4.2软件开发风险管理风险识别三步骤2914.4.2软件开发风险管理制定风险管理计划风险监控风险化解风险控制风险识别三步骤14.5

软件质量保证14.5.1软件质量的基本概念14.5.2软件质量保证的措施质量是产品的生命线,保证软件产品的质量是软件产品生产过程的关键。软件产品包含一系列的特征或特性,这些特征或特性可以对产品在性能、功能、开发标准化等各方面的绩效进行度量。软件产品的质量越高,其相关特征或特性就越能满足用户的需求。通俗地说,软件质量是指软件系统满足用户需要或期望的程度。高质量的软件产品意味着较高的用户满意度及较低的缺陷等级,它较好地满足了用户需求,具有高水平的可维护性和可靠性。软件的质量是由多种因素决定的,它等价于软件产品的一系列的质量特性。14.5.1软件质量的基本概念ANSI/IEEE729-183软件质量定义:与软件产品满足规定的和隐含的需要的能力有关的特征或特性的组合。ISOStandard9126软件质量的特性包括功能性、可靠性、可用性、效率、可维护性和可移植性。14.5.1软件质量的基本概念McCall软件质量特性模型14.5.2软件质量保证的措施在软件开发实践中,可以采取多种方法保证软件产品的质量,常用的方法包括:33

1.基于非执行的测试

2.基于执行的测试

3.程序的正确性证明IDEAREALIZATIONPLANNING1.基于非执行的测试3.程序的正确性证明2.基于执行的测试14.5.2软件质量保证的措施在软件开发实践中,可以采取多种方法保证软件产品的质量,常用的方法包括:非执行的测试是指不具体执行程序的测试工作,也称为软件评审。非执行的测试需要贯穿于整个软件开发过程。在项目开发前期,软件开发人员需要制定详细的开发计划以及评审计划,标识各阶段的检查重点以及阶段工作的预期输出,为以后的阶段评审做准备。在项目的阶段评审工作中,要保证评审工作的严格性和规范性。首先,评审人员要具备相应的资格和能力,评审团队的规模及任务分配要合理。每次评审都需要做详细的评审记录,并做出明确的评审结果。对于不合规范的工作成果还要给出修改意见。基于非执行的测试14.5.2软件质量保证的措施软件评审的具体实施手段包括设计评审、审查、走查、个人评审等。14.5.2软件质量保证的措施基于执行的测试是指通过具体地执行程序,观察实际输出和预期输出的差异,来发现软件产品错误的方法。软件开发人员通常使用一种或几种自动测试工具对系统进行测试。但是,由于手工测试灵活性高的特点,手工测试也是必需的。测试人员可以使用黑盒测试或白盒测试的方法设计测试用例进行测试。软件测试有利于及早揭示软件缺陷(见12章)。36基于执行的测试软件测试有一条重要原则是:测试可以发现程序中的错误,但是不能证明程序中没有错误。可见,软件测试并不能完全证明程序的正确性和可靠性。如果能采用某种方法对软件系统运行的正确性进行证明,那么软件产品的质量将更有保证。目前,人们已经研究出证明Pascal和LISP程序正确性的软件系统,正在对其进行完善和功能扩充。但是,这些系统还只适用于小型的软件系统,并不适合大规模的软件系统。14.5.2软件质量保证的措施程序的正确性证明14.6

软件配置管理14.6.1软件配置管理概述14.6.2配置管理的过程14.6.3软件配置管理的角色划分在人员方面,随着软件规模越来越大,很多项目有成千的开发人员,而且可能分布于世界各地,有不同的文化和社会背景。如何有效地组织和管理这些内容,对于项目的成败和效率影响非常重大。软件的开发过程中,常常产生大量的文档和程序版本,比如立项报告、需求规格说明书、概要设计文档、详细设计文档、编码设计说明、源代码、可执行程序、用户手册、测试计划、测试用例、测试结果、在线文档等,此外还可能有合同、会议记录、报告、审核等管理文档。在软件开发中,还常常存在对这些文档的大量变更。软件配置管理概述项目委托单位为产品开发提供资金的单位或个人,通常也确定产品需求项目承办单位为项目委托单位开发、购置或选用软件产品的单位或个人。软件程序及有关文档,IEEE定义:计算机程序、方法、规则、文档资料及运行时必须的数据用户实际用软件完成某项任务的单位或个人,也叫最终使用者。软件开发单位直接或间接受项目单位委托,直接负责软件开发的单位或个人。14.6.1软件配置管理术语配置在配置管理中,软硬件具有的功能或物理特性软件生命周期软件系统从提出需求开始,经过开发,产生满足需求的软件系统,投入运行,直至推出使用的整个过程。配置项为配置管理设计的硬件、软件或二者的集合,在配置管理中被作为单个实体来对待。软件开发库软件生命周期某一阶段中,存放与该阶段开发相关的信息库。软件对象项目进展中产生的,可有软件配置管理加以控制的任何实体。软件对象拥有唯一的标识符,一个包含实体信息的对象实体,以及与其他对象进行关系操作与消息传递的机制14.6.1软件配置管理术语配置标识由系统所选的配置项及记录它们功能和物理特性的技术文档组成。经核准的配置项的技术文档由说明书、图、表等组成。为了方便对配置项进行控制和管理,需要对它们进行唯一的命名。配置管理指对配置管理过程中的各个对象进行监视和管理。如对配置项的功能特性和物理特性进行标识并写成文档。对这些特性的更改进行控制。对更改处理过程和实施状态进行记录和报告。以及对是否符合规定需求进行验证等。版本控制版本控制就是管理在整个软件生命周期中建立起来的某一配置项的不同版本。基线指一个配置项在其生命周期的某一特定时间,被正式标明、固定并经正式批准的版本。也可以说,基线是软件生命期中各开发阶段末尾的特定点,也常称为里程碑。所有成为基线的软件配置项协议和软件配置的正式文本必须经过正式的技术审核。版本是某一配置项的已标识的实例。或者定义为,不可变的源对象经质量检验合格后所形成的新的相对稳定的状态(配置)称为软件版本。14.6.1软件配置管理术语14.6.2

软件配置管理的过程工作范围1.标识配置项2.进行配置控制3.记录配置状态4.执行配置审计配置管理的工作范围一般包括4个方面:431.标识配置项所谓配置项是配置管理中的基本单元,每个配置项应该包含相应的基本配置管理的信息。标识配置项就是要给配置项取一个合适的名字。所有的软件产品都要进行配置项的标识,该标识符应该具有唯一性,并且要遵循特定的版本命名规律,以便于管理和追踪。比如,V2015.0.1,V2016.1.2。Loremipsumdolorsitamet,consectetueradipiscingelit.Maecenasporttitorconguemassa.90%70%40%38%20%14.6.2软件配置管理的过程14.6.2

软件配置管理的过程访问控制访问控制通过配置管理中的“软件开发库”、“软件基线库”、“软件产品库”来实现,每个库对应着不同级别的操作权限,为团队成员授予不同的访问权利。版本控制版本控制是指用户能够对适当的版本进行选择从而获得需要的系统配置,它往往使用自动的版本控制工具来实现,比如Git。变更控制变更控制是应对软件开发过程中各种变化的机制,可以通过建立控制点和报告与审查制度来实现。产品发布控制产品发布控制面向最终发布版本的软件产品,旨在保证提交给用户的软件产品版本是完整、正确和一致的。452.进行配置控制2013201420152016

3.记录配置状态记录配置状态的目的是使配置管理的过程具有可追踪性。配置状态报告记录了软件开发过程中每一次配置变更的详细信息,包括改动的配置项、改动内容、改动时间和改动人等。配置状态报告是开发人员之间进行交流的重要工具,对项目的成功非常重要。14.6.2软件配置管理的过程ADCB14.6.2软件配置管理的过程4.执行配置审计配置审计是为了保证软件工作产品的一致性和完整性,从而保证最终软件版本产品发布的正确性。软件的配置管理贯穿于整个软件开发过程,可以建立和维护在整个软件生命周期内软件产品的完整性。目前市场上流行的配置管理工具有很多,比如微软公司的VisualSourceSafe(VSS)、Rational公司的ClearCase以及Github的Git等。14.7软件工程标准与软件文档14.7.1软件工程标准14.7.2软件文档软件工程标准化的定义在软件工程项目中,为了便于项目内部不同人员之间交流信息,要制定相应的标准来规范软件开发过程和产品。随着软件工程学的发展,软件开发工作的范围从只是使用程序设计语言编写程序,扩展到整个软件生命期,包括软件需求分析、设计、实现、测试、运行和维护,直到软件退役。软件工程还有一些管理工作,如过程管理、产品质量管理和开发风险管理等。所有这些工作都应当逐步建立其标准或规范。由于计算机技术发展迅速,在未形成标准之前,计算机行业中先使用一些约定,然后逐渐形成标准。软件工程标准化就是对软件生命期内的所有开发、维护和管理工作都逐步建立起标准。14.7.1软件工程标准(1)提高软件的可靠性、可维护性和可移植性,因而可提高软件产品的质量软件工程标准化给软件开发工作带来的好处主要有以下几点:(2)提高软件生产力(3)提高软件开发人员的技术水平(4)改善软件开发人员之间的通信效率,减少差错(5)有利于软件工程的管理(6)有利于降低软件成本和缩短软件开发周期14.7.1软件工程标准14.7.2软件文档在软件工程中,文档记录了从需求分析到产品设计再到产品实现及测试的过程,甚至到产品交付以及交付后的使用情况等各个阶段的相关信息。文档一方面充当了各个开发阶段之间的桥梁,作为前一阶段的工作成果及结束标志,它使分析有条不紊地过渡到设计,再使设计的成果物化为软件。另一方面,文档在团队的开发中起到了重要的协调作用。此外,还有一些与用户打交道的文档成为用户使用软件产品时最得力的助手。合格的软件工程文档应该具备以下几个特性。51(1)及时性软件文档特性(2)完整性(3)实用性(4)规范性(5)结构化(6)简洁性14.7.2软件文档14.7.2软件文档53软件文档的分类14.8

软件过程能力成熟度模型软件过程能力成熟度模型认为,软件质量难以保证的问题在很大程度上是由管理上的缺陷造成的,而不是由技术方面的问题造成的。因此,软件过程能力成熟度模型从管理学的角度出发,通过控制软件的开发和维护过程来保证软件产品的质量。它的核心是对软件开发和维护的全过程进行监控和研究,使其科学化、标准化,能够合理地实现预定目标。软件过程能力成熟度模型(CapabilityMaturityModel,CMM)是用于评估软件能力与成熟度的一套标准,它由美国卡内基—梅隆大学软件工程研究所推出,侧重于软件开发过程的管理及工程能力的提高与评估,是国际软件业的质量管理标准。14.8软件过程能力成熟度模型5614.8软件过程能力成熟度模型

软件过程能力成熟度模型图软件过程能力成熟度模型的成熟度等级14.9软件项目管理14.9.1软件项目管理概述14.9.2软件项目管理与软件工程

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论