ch9软件工程管理.pptx
《ch9软件工程管理.pptx》由会员分享,可在线阅读,更多相关《ch9软件工程管理.pptx(89页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、第9章软件工程管理l软件工程管理概述l软件规模估算l进度计划l人员组织l软件配置管理l软件质量保证l软件工程标准与软件文档软件工程管理概述l1. 软件产品的特点软件是逻辑产品,具有高度的抽象性同一功能的软件可以有多样性软件生产过程复杂,具有易错性软件开发与维护主要是根据用户需求“定制”的,其过程具有复杂性和易变性软件的开发和运行经常受到计算机系统环境的限制,因而软件有安全性和可移植性等问题软件生产有许多新技术需要软件工程师进一步研究和实践l2.软件工程管理的重要性分阶段管理策略涉及多学科软件规模不断增大,管理难度增加,管理不善的后果严重l3.软件工程管理的内容 包括对软件开发成本、控制、开发人
2、员、组织机构、用户、软件开发文档、软件质量等方面的管理。软件规模和开发工作量估算面向规模的度量(代码行技术)面向功能的度量(功能点技术)CoCoMo模型软件项目估算l估算涉及到人、技术、环境、政策等多种因素,很难精确地估算出项目的开销。l常用四种估算方法参照已有类似项目估计待开发项目成本和工作量将大的项目分解成若干子项目,分别估算出子项目成本和工作量,再估算整个项目按软件的生命期分别估算各阶段的工作量和成本,再汇总,从而估算出整个项目根据实验或历史数据给出软件项目工作量或成本的经验公式软件项目代码行和功能点估算是成本和工作量估算的基础。(规模)LOC或FP的期望值:e=(a+4m+b)/6l代
3、码行技术用软件项目的代码行(LOC)数表示软件项目的规模生产率P=L/E,E是软件项目的工作量,用人月(PM)度量,L用千行代码kLOC度量每行代码的平均成本C=S/L,S是软件项目总的开销文档与代码比D=Pd/L,Pd是软件项目的文档页数代码出错率EQR=Ne/L,Ne是软件项目的代码错误数l例:下表提供了一个国外典型的软件项目记录l利用这些数据,可以求出:lP=12.1kLOC/24PM=504LOC/PMlC=168000美元/12.1kLOC=13.88美元/LOClD=365Pd/12.1kLOC=30.16Pd/kLOClEQR=29个/12.1kLOC=2.4个/kLOCl用代码
4、行数估计软件规模简单易行l缺点:代码行数的估算依赖于程序设计语言的功能和表达能力;采用代码行估算方法会对设计精巧的软件项目产生不利影响;在软件项目开发前或开发初期估算它的代码行数十分困难;代码行估算只适用于过程式程序设计语言,对非过程式的程序设计语言不太适用等l功能点技术依据对软件信息域特性和软件复杂性的评估结果,估算软件规模5个信息域特性为:用户输入数:各个用户输入是面向不同应用的输入数据(参数,不含查询数)个数。用户输出数:各个用户输出是面向应用的输出信息个数,包括报告,屏幕信息,错误信息等。用户查询数:查询是一种联机的交互操作,统计查询/响应的总计数。 文件数:每一个逻辑主文件都应计数。
5、逻辑主文件是指逻辑上的一组数据,可以是一个大数据库的一部分,可以是一个单独的文件。外部接口数:与系统中其他设备通过外部接口读写信息次数均应计数。功能点 FP (Function Point)。 FP UFP( 0.65 0.01SUM ( Fi ) ) 估算功能点的步骤1.计算未调整的功能点数UFP UFP=a1Inp+a2Out+ a3Inq+a4Maf+a5Inf 其中,ai(1i5)是信息域特性系数,值由相应特性的复杂级别决定。l2.计算技术复杂因子TCF14种技术因素:技术因素、数据通信、分布式数据处理、性能标准、高负荷的硬件、高处理率、联机数据输入、终端用户效率、联机更新、复杂的计算
6、、可重用性、安装方便、操作方便、可移植性、可维护性。 l计算技术因子对软件规模的综合影响程度DI:l技术复杂性因子TCP由下式计算: TCP = 0.65 + 0.01 DI l计算功能点数FP FP = UFP TCP 代码行度量与功能点度量的比较代码行度量(依赖开发语言)与功能点度量(不依赖开发语言)的比较 LOC/FP(平均):汇编语言=300FORTRAN=100pascal=90Ada=70面向对象语言=30 四代语言4GL=20 代码生成器=15一行Ada语言代码的“功能”平均是一行FORTRAN语言代码“功能”的1.4倍,一行四代语言代码的“功能”平均是一行传统程序设计语言代码“
7、功能”的35倍CoCoMo 模型l1981年Boehm提出“构造性成本模型”(Constructive Cost Model)l该成本估算模型是一种精确、易于使用的成本估算方法lCOCOMO模型的分类(按其详细程度,分三级)基本模型、 中间模型、 详细模型基本模型是静态单变量模型,用源代码行数(LOC) 为自变量的经验函数计算软件开发工作量。中间模型在用LOC为自变量的函数计算软件开发工作量(称为名义工作量)的基础上,用涉及产品、硬件、人员、项目等方面的影响因素调整工作量估算。详细COCOMO模型包括中间模型的所有特性,但用上述各种影响因素调整工作量估算时,还要考虑对软件工程过程中每一步骤(分
8、析、设计等)的影响。基本的CoCoMo模型l公式l其中: E 表示工作量(人月PM) D 表示开发时间(月) L 是项目的代码行估计值(千行代码)bLaE)(dcED 基本的CoCoMo模型参数la,b,c,d 常数取值软件类型abcd适用范围组织型2.41.052.50.38各类应用程序半独立型3.01.122.50.35各类实用程序、编译程序等嵌入型3.61.202.50.32实时处理、控制程序、操作系统中间的CoCoMo模型以基本的CoCoMo模型为基础,工作量估计公式中乘以调节因子EAF E 表示工作量(人月PM) L 是项目的代码行估进一步考虑15种影响软件工作量的因素EAFLaEb
9、)(iiFEAF151软件类型ab组织型3.21.05半独立型3.01.12嵌入型2.81.20l产品因素: 软件可靠性、数据库规模、产品复杂性;l硬件因素: 执行时间限制、存储限制、虚拟机易变性、环境周转时间;l人的因素: 分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验;l项目因素: 现代程序设计技术、软件工具的使用、开发进度限制。例 一个规模为10KLOC的商用微机远程通信的嵌入型软件,使用中间COCOMO模型进行成本估算。名义工作量E1 2.8 (10)1.20 44.38实际工作量E 44.381.17 51.9中间CoCoMo模型与各种开发方案对工作量的影
10、响l建议参加项目的人数N 为人数,D 为开发时间(月), E 为工作量(人月)l一般来说,由N个程序员组成的小组,实现相同的规模的程序,相互通信数 , 设每次通信和交换意见的平均的工作量 ,则增加的通信开销为DEN/2/ ) 1(2NNCN2/ ) 1(NNEcl一般情况下,由N 个程序员组成的小组共同开发一个程序的工作量 ,满足:l程序员小组的生产率:l单个程序员与程序员小组生产率的比为l事实:盲目增加程序员人数会推迟软件完成的日期 rEcrEEE)/(cGEELOCP)/(cpEEERCoCoMo2模型1997年Boehm对CoCoMo模型进行了扩充,称为CoCoMo2. COCOMO2模
11、型分成三个层次l应用系统组成模型:用于估算构建原型的工作量,这种模型考虑到大量使用已有构件的情况l早期设计模型:用于软件结构设计阶段l后期设计模型:用于软件开发阶段 COCOMO2模型把软件开发工作量表示成代码行(KLOC)的非线性函数:其中,是模型系数,典型值为3.0,b是模型指数,fi是成本因素。COCOMO2模型使用了5个分级因素Wi(1i5),分别是:项目先例性、开发灵活性、风险排除度、项目组凝聚力和过程成熟度。 其中每个成本因素划分为6个级别,每个级别的分级因素Wi取值如下:甚低Wi=5,低 Wi=4, 正常Wi=3,高Wi=2,甚高Wi=1,特高Wi=0。b的值:171*biEkL
12、OCfi进度计划l可以把用于一般开发项目的进度安排的技术和工具应用于软件项目。l为监控软件项目的进度计划和工作的实际进展情况,为表现各项任务之间进度的相互依赖关系,需要采用图示的方法。l在图示方法中,必须明确标明:l 各个任务的计划开始时间,完成时间;l 各个任务完成标志(即文档编写和评审);l 各个任务与参与工作的人数,各个任务与工作量之间的衔接情况;l 完成各个任务所需的物理资源和数据资源甘特图Gantt Chartl在甘特图中,每一任务完成的标准,不是以能否继续下一阶段任务为标准,而是以必须交付应交付的文档与通过评审为标准。因此在甘特图中,文档编制与评审是软件开发进度的里程碑。工程网络技
13、术l工程网络技术PERT技术 (Program Evaluation and Review Technique)叫做程序评估与审查技术,CPM方法叫做关键路径法,它们都是安排开发进度,制定软件开发计划的最常用的方法。l它们都采用网络图来描述一个项目的任务网络,也就是从一个项目的开始到结束,把应当完成的任务用图或表的形式表示出来。1. 计算最早时刻2. 计算最迟时刻3. 关键路径4. 机动时间 上述示例工程中各项任务的进度安排,可用Gantt图画出:(先安排关键路径上的任务) 路径优化人员组织1. 开发人员2. 组织机构l三种组织结构模式按课题划分的模式(Project Format)按职能划分
14、的模式(Functional Format)矩阵形模式(Matrix Format)l程序设计小组的组织形式有3种: 主程序员组、民主制程序员组及层次式小组3. 用户用户的阻力和干扰:不积极配合、求全求快、功能的变化 软件配置管理l软件配置(Software Configuration)是软件产品在软件开发或运行过程中产生的全部信息。l软件配置管理(Software Configuration Management)简称SCM,是在软件的整个生存周期内管理变更的一组活动。l软件配置管理(Software Configuration Management,简称SCM)的四项任务:l()标识变更l
15、()控制变更l()配置审计l()配置状态报告 l软件开发过程的最终结果包括三类信息:计算机程序(源程序和目标程序);描述程序的文档(面向技术人员和面向用户);数据结构(包括程序内部和外部定义两部分)。l组成上述信息的所有项目构成一个软件配置,其中每一项称为一个软件配置项(Software Configuration Item,简称SCI),它是配置管理的基本单位。一个SC中最早的SCI是系统规格说明书。lSCM要解决的主要问题就是保证软件的质量。 l基线(baseline)的原意是棒球场的边线,在软件开发过程中,为了有效地控制变动,软件配置管理引入基线的概念。lIEEE组织对于基线的定义“已经
16、通过正式复审和批准的某规约或产品,它因此可以作为进一步开发的基础,并且只能遵循正式的变化控制过程得到改变”。l根据这个定义,基线标志软件开发过程的各个里程碑,任一SCI,一旦形成文档并复审通过,即成为一个基线,它标志开发过程中一个阶段的结束。对于已成为基线的SCI,虽然可以修改,但必须按照一个特殊的、正式的过程进行评估,确认每一处修改。相反,对于未成为基线的SCI,可以进行非正式修改。 l某个SCI一旦成为基线,随即被放入项目数据库(project database)。此后,若开发小组中某位成员希望改动SCI,首先要将它拷贝到私有工作区并在项目数据库中锁住,不允许他人使用。在私有工作区中完成修
17、改控制过程并复审通过之后,再把修改后的SCI推出并回送到项目数据库,同时解锁。 l一般软件配置需包括下列SCI:l1系统规格说明书l2软件项目规划l3需求分析结果l 1)软件需求规格说明书l 2)可执行的或“纸样”原型l4初步用户手册 l5设计规格说明书l 1)数据设计描述l 2)总体结构设计描述l 3)模块设计描述l 4)界面设计描述l 5)对象描述(若采用面向对象技术) l6 6源代码清单l7测试规格说明书l 1)测试计划和过程l 2)测试用例和实验结果 l8操作和安装手册l9可执行程序l 1)每个模块的可执行代码l 2)连接到一起的代码l10数据库描述l 1)数据模型和文件结构l 2)初
18、始化映象l11联机用户手册l12维护文档l 1)软件问题报告单l 2)维护申请单l 3)预计变动的顺序l13软件工程的标准和过程 l软件配置管理主要任务是控制软件的修改,主要包括:标识软件配置中各种对象;管理软件的各种版本;控制对软件的修改; 审计配置;报告配置情况。 l所有SCI都应按面向对象的方式命名并组织起来。对象命名是为了能够根据名称提取对象;而通过组织对象并描述其间的关系则着眼于在对象变更时能够清楚地了解变更的影响范围。l基本对象在分析、设计、编码或测试阶段由开发人员创建的某个“文本单元”(unit of text)。例如,需求说明书中某一节,某个模块的源代码,或按等价分类法制定的一
19、套测试用例l复合对象由若干基本对象和复合对象组合而成的对象,是一个递归的概念。例如,“设计规格说明书”是复合对象,它由“数据模块”和“模块N”等基本对象组合而成。 l每个配置对象都拥有名字、描述、资源列表和实际存在体四个部分:1. 对象名一般为无二义字符串;2. 对象描述包括若干数据项,它们指明对象的类型(例如,文档、程序还是数据)、所属工程项目的标志及变动和版本的有关信息;3. 资源列表给出该对象要求、引用、处理和提供的所有实体,如数据类型、特殊函数等,有时变量也被看作资源;4. 只有基本对象才有实际存在体,它是指向该对象“单元正文描述”的一个指针;对于复合对象,此项取null值。 l除了标
20、识配置对象外,还必须指明对象之间的关系,一个对象可标识为另一个复合对象的一部分,即此两对象之间存在一个关系。若干关系可定义出对象之间的分层结构。例如:l“E R图”“数据模型”l“数据模型”“设计规格说明书”l因一个配置对象可能与其他多个对象有关系,所以SCI的分层结构不一定是简单的树状结构,而是更一般的网状结构。 l为了适应不同环境特点和满足不同用户的个性需求,往往一个项目保存多个版本。l配置管理的版本控制主要解决下列问题: 1)根据不同用户的需要配置不同的系统; 2)保存系统老版本,为以后调查问题使用; 3)建立一个系统新版本,使它包含某些决策而抛弃另一些; 4)支持两位以上工程师同时在一
21、个项目中工作; 5)高效存储项目的多个版本。 l版本控制系统都为配置对象的每个版本设置一组属性,这组属性既可以是简单的版本号,也可以是一串复杂的布尔变量(即开关值),用以说明该版本功能上的变化。l进化图可用于描述一个软件系统的不同版本。l图中每个结点都是软件的一个完整版本,它由所有协调一致的软件配置项组成(源代码,文档和数据)。此外,一个版本还允许有多种变形(Variant)。例如,一个程序的某个版本由A、B、C、D、E五个部件组成,部件D仅在系统配有彩色显示器时使用,部件E则适用于单显,那么该版本就有两种变形,一种由A、B、C、D四个部件组成,另一种由A、B、C、E四个部件组成。 l在大型软
22、件开发过程中,无控制地修改会迅速导致混乱。所谓修改控制,即把人的努力与自动工具结合起来,建立一套机制,有意识地控制软件修改。 l当一个“修改申请”提出后,开发者依据技术指标和潜在的副作用,对其他配置对象和系统功能可能造成的影响以及项目成本等诸多因素进行评估。评估的结果将形成一个“修改报告单”,提交给修改控制机构(CCA)决策。lCCA一旦同意修改,应立即提供一个“工程变动命令”ECO(Engineering Change Order)。它指明修改任务、需遵守的限制和复审标准。然后从项目数据库中“提出”待修改对象,经修改后再“推出”更新版本。l这一对动作是项目数据库访问控制和同步控制要求的。访问
23、控制决定哪些人员有权访问或修改某个配置对象;而同步控制则保证并行修改时不因互相重写而造成丢失修改。 l软件开发人员根据ECO从项目数据库中提出待修改对象,访问控制机构,核实该开发人员是否有此特权,而同步控制机构则及时锁住待修改对象,不允许其他开发人员再做修改,直至该对象的新版本推出。加锁期间,其他工程人员仍可提取该对象的副本(称为提取版本)使用。l上图所示的修改控制用于已交给用户的软件产品,称为正式修改控制。若欲修改的SCI虽已为基线版本,但尚未交付用户,此时修改控制称为工程级的修改控制,它除了不涉及用户外,其他步骤与正式的修改控制大致相同。若SCI并未成为基线版本,只需进行非正式的修改控制,
24、则在不影响系统需求的前提下,该SCI的开发者可随意改动 变更控制过程来自用户的CR工作量评估递交CR表格CCA审查评估CR被否决同意CR,给人员分配任务SCM检出配置项更 改审计并检入更改内容建立基线测试,执行QA和测试活动提交改变到下一个Release通知用户构造适当的版本并审计所有配置项新版本中引入变化,并发布该版本 l对于变更工作,必须通过正式的技术复审和软件配置审计工作来验证被核准进行变更的对象是否进行了必要的、正确的变更,并得到了重新的配置。l正式的技术复审着重考虑所修改对象在技术上的正确性,复审人员应对该对象是否与其他SCI协调以及在修改中可能产生的疏忽和副作用进行全面的评估。l软
25、件配置审计作为正式复审的一种补充措施,主要考虑下列在正式技术复审中未被考虑的因素:工程变动命令中指定的修改是否都已完成?有无进行未经指定的其他附加变更?是否做过正式技术复审?是否严格遵守软件工程标准?是否对修改过的SCI进行了强调说明?修改的日期和执行修改的人员是否已经注明?该SCI的属性是否能够反映本次修改的结果?是否遵循了标注变更、记录变更和报告变更的SCM工作规程?所有相关的SCI是否已一并修改? 配置状况报告配置状况报告 l建立并发布配置状况报告(Configuration Status Reporting,简称CSR)是软件配置管理的一项任务.lCSR主要概述下列问题:发生了什么事情
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ch9 软件工程 管理
限制150内