1.23k likes | 1.4k Views
软件工程. 第十章 软件项目管理. 第十章软件项目管理. 13 . 1 估算软件规模 13 . 2 工作量估算 13 . 3 进度计划 13 . 4 人员组织 13 . 5 质量保证 13 . 6 软件配置管理 13 . 7 能力成熟度模型. 什么是软件项目管理?. 为了使软件项目能够按照 预定 的成本、进度、质量顺利完成,通过合理地组织和利用一切可以利用的资源,按照计划的成本和进度,完成计划的目标。 它包括对成本、人员、进度、质量、风险等进行分析和管理的活动。 软件项目管理先于任何技术活动之前开始,并且贯穿于软件的整个生命周期之中。.
E N D
软件工程 第十章 软件项目管理
第十章软件项目管理 • 13 . 1 估算软件规模 • 13 . 2 工作量估算 • 13 . 3 进度计划 • 13 . 4 人员组织 • 13 . 5 质量保证 • 13 . 6 软件配置管理 • 13 . 7 能力成熟度模型
什么是软件项目管理? • 为了使软件项目能够按照预定的成本、进度、质量顺利完成,通过合理地组织和利用一切可以利用的资源,按照计划的成本和进度,完成计划的目标。 • 它包括对成本、人员、进度、质量、风险等进行分析和管理的活动。 • 软件项目管理先于任何技术活动之前开始,并且贯穿于软件的整个生命周期之中。
项目管理过程(1) • ① 启动软件项目。确定项目的目标和范围。 • ② 度量。帮助开发人员了解开发技术、过程和产品。 • ③ 估算。对软件开发中的人力、项目持续时间、成本作出估算。 • 规模估算:代码行技术、功能点技术 • 工作量估算:静态单变量模型、动态多变量模型、 COCOMO 模型 • 开发时间估算:进度估算: Gantt 图、工程网络
项目管理过程( 2 ) • ④ 风险分析。由风险识别、风险估计、风险评价和风险驾驭四个活动组成。 • ⑤ 进度安排。包括识别项目任务,建立任务间的联系,估算各任务的工作量,分配人力和其他资源,制定进度时序。 • ⑥ 追踪和控制。项目管理人员负责追踪在进度安排中标明的每一个任务,还可以对资源重新定向,对任务重新安排或者可以修改交付日期以调整已经暴露的问题。
13.1 估算软件规模 • 小王:软件项目负责人 • 老王:公司技术老总 • 1. 项目案例 • 案例角色和人物
项目管理需要定量描述(1/3) • 在项目策划阶段的碰头会上 • 公司技术总监询问小王项目开发估计需要多少时间,需要多少成本? • 小王回答说“时间估计不会太长,成本也在一个可接受的范围之内”,老王显然对这种回答不满意,他希望能够得到一个较为准确定量性的描述 • 经过一番考虑后,小王确认回答说“时间7-8个月,成本需40-45万”,老王显然对这种回答也不满意,况且用户要求在6个月内完成项目。于是他进一步问道“你是如何得到这组数据”,小王显然没有准备,也没有充分的依据,于是他哑口无言
项目管理需要定量描述(2/3) • 在制定软件项目计划时 • 小王不知如何预测项目可能所需的工作量? • 小王不知如何预测项目可能所需的成本? • 小王不知所制定的计划是否可行和科学? • 因此,小王尽管制定了软件开发计划,但对于该计划能否得到有效的实施、实施能否遵循计划执行没有足够的信心
项目管理需要定量描述(3/3) • 项目已进展了2个月,各个方面进展尚可,在某周的碰头会上,老王继续向小王发问 • “目前软件质量如何?”,小王回答道“不错” • 老王对这种回答不满意,他希望能够得到一个较为准确定量性的描述,但是小王又没有办法给他一个更加确切的答复,实际上连他自己也没有办法说清楚目前软件产品的质量情况,因为他只有直观的、定性了解。
定量分析是重要的 • 工程化的软件开发需要定量、科学的描述(实施前、实施过程中、实施完成后) • 定量、科学的描述有助于获取软件项目以及所开发的软件的某种可视性,促进软件项目的管理 • 定量的信息描述必须在软件项目开发过程中采集
软件项目管理问题 • 在软件项目实施过程中,需要哪些方面的定量描述以促进软件项目的有效开发和管理? • 如何获取这些方面的科学定量描述? • 如何在软件项目开发过程中集成度量? • 如何将这些定量描述用于指导软件项目的管理?
为什么需要软件度量(1/2) • 任何工程化的工作都需要度量,软件工程也不例外 • 准确了解工程的实施情况 • 项目实施之前 • 辅助制定软件项目的计划 • 估算成本和工作量,以便制定计划
为什么需要软件度量(2/2) • 项目实施过程中 • 提供软件开发的可视性 • 跟踪和控制软件项目的开发 • 评估软件开发质量,进行质量控制 • 加强风险管理 • 项目实施之后 • 对项目的实施情况进行评估 • 为后续项目的积累经验数据
软件度量的内容 产品 过程 资源 • 三个方面 • 产品:各种文档和程序 • 过程:各种软件开发活动 • 资源:各种资源如人员、费用等
软件度量的方法 • 面向规模的度量(代码行技术) • 面向功能的度量(功能点技术) • 工作量估算 • 项目成本估算(教材没有) • 软件质量度量(教材没有)
1.面向规模的度量(1/3) • 用软件代码行数目来表示软件项目规模 • 生产率: PM = L / E, L表示代码总量(单位:KLOC),E表示软件工作量(单位:人月) • 每千行代码的平均成本:CKL = S / L,S为软件项目总开销 • 文档与代码比: Dl = Pd / L,Pd表示文档页数 • 代码出错率: EQRl = Ne / L,Ne表示代码出错的数目
1.面向规模的度量(3/3) • 优点 • 简单易行,自然直观 • 缺点 • 依赖于程序设计语言的表达能力和功能 • 软件开发初期很难估算出最终软件的代码行数 • 对精巧的软件项目不合适 • 只适合于过程式程序设计语言
2.面向功能的度量(1/7) • 用软件的功能表示软件的规模 • “功能”不能直接度量,需要依靠其他度量结果导出 • 功能点度量涉及多种因素 • 项目开发初期就可估算出 • 功能点计算目前主要基于经验公式
2 面向功能的度量(2/7) • 功能点计算方法 • FP = (0.65 + 0.01×Fi)×CT • CT : 5个信息量的“加权和” • Fi: 14个因素的“复杂性调节值” (i =1..14) • 0.65, 0.01都是经验常数
2 面向功能的度量(3/7) • CT的计算方法 • 用户输入数×加权因子(简单=3,平均=4,复杂=5) • 用户输出数×加权因子(简单=3,平均=4,复杂=5) • 用户查询数×加权因子(简单=3,平均=4,复杂=5) • 文件数×加权因子 (简单=3,平均=4,复杂=5) • 外部界面数×加权因子(简单=3,平均=4,复杂=5) • CT = 上述计算值的总和
2 面向功能的度量(4/7) • Fi的取值(0,1,2,3,4,5):0-没有影响,1-偶有影响,2-轻微影响,3-平均影响,4-较大影响,5-严重影响 • 系统需要可靠的备份和复原码? • 系统需要数据通信吗? • 系统有分布处理功能吗? • 性能是临界状态吗? • 系统是否在一个实用的操作系统下运行? • 系统需要联机数据项吗? • 联机数据项是否在多屏幕或多操作之间进行切换?
2面向功能的度量(5/7) • 需要联机更新主文件吗? • 输入、输出、查询和文件很复杂吗? • 内部处理复杂吗? • 代码需要被设计成可重用吗? • 设计中需要包括转换和安装吗? • 系统的设计支持不同组织的多次安装吗? • 应用的设计方便用户修改和使用吗?
2面向功能的度量(6/7) • 优点 • 与程序设计语言无关, 在开发前就可以估算出软件项目的规模(事前) • 不足 • 没有直接涉及算法的复杂度,不适合算法比较复杂的软件系统; • 功能点计算主要靠经验公式,主观因素比较多 • 数据不好采集
2面向功能的度量(7/7) • 代码行度量和功能点度量间的关系
3成本和工作量估算(1/2) • 软件项目成本和工作量估算极为重要 • 计算机系统中软件成本占总成本的比例很大 • 用户和项目管理人员对软件成本和工作量估算都很重视 • 软件项目成本估算比较困难 • 软件是逻辑产品,软件开发是一个逻辑思维的过程 • 涉及多方面因素
3成本和工作量估算(2/2) • 软件项目成本和工作量估算常用方法 • 参照和依据已完成项目的历史数据 • 将大项目分解为小项目 • 将项目按照软件生命周期分解 • 根据经验估算公式 • 上述方法可以同时、单独或者组合使用
13.1 估算软件规模 • 软件项目规模影响软件项目成本和工作量 • 软件项目代码行和功能点估算是成本和工作量的基础. • 估算出FP或者LOC期望值e = (a + 4m + b)/6 其中: a=乐观值; b=悲观值;m=一般值
案例: 代码行和功能点估算 (1/8) • 软件描述(CAD软件) • CAD图形软件可接受来自用户的二维和三维几何数据,用户通过界面与CAD软件进行交互,并控制它,该软件具有良好的人机界面设计的特征。所有的几何数据及其支持信息存放在数据库中。开发设计分析模块,以产生所需的输出,这些输出将显示在各种不同的图形化设备上。软件在设计中要考虑与外设进行交互并控制它们,包括鼠标、数字化仪、打印机等等。
案例: 代码行和功能点估算 (2/8) • 软件子系统划分 • 图形用户界面及其控制机制 • 二维几何分析 • 三维几何分析 • 数据库管理 • 图形显示 • 外设控制(与打印机、数字化仪、扫描仪的接口) • 设计分析子系统
案例: 代码行和功能点估算 (3/8) • 估算出各个子系统的代码行,例如三维几何分析功能的代码行估算范围为: • 乐观值:4 600 • 可能值:6 900 • 悲观值:8 600 • 估算值: e = (a + 4m + b)/6 = 6 800
案例: 代码行和功能点估算 (5/8) • 历史数据 • 平均生产率Pf: 620 LOC/PM(620行代码/人月) • 每个人月的成本 C = 8000¥ • 估算项目成本和工作量 • 估算工作量 = 总代码行/PM= 33200/620=54人月 • 估算成本 = 估算工作量 ×每个人月的成本 = 54人月× 8000 = 43 2000¥
案例: 代码行和功能点估算 (6/8) • 基于功能点估算: Step1: 计算CT值
案例: 代码行和功能点估算 (7/8) • Step2: 计算复杂度调整因子
案例: 代码行和功能点估算 (8/8) • 计算出FP的估算值 • FP = (0.65 + 0.01×Fi)×CT = 372 • 历史数据 • 平均生产率 6.5 FP/PM • 每个人月的成本 C = 8000¥(平均月薪) • 估算成本和工作量 • 工作量 58人月 • 成本 457000¥
13. 2 工作量估算 • 经验估算模型: CoCoMo模型? • COCoMo是指Constructive Cost Model,构造性成本模型,Boehm于1981年提出,用于对软件开发项目的规模、成本、进度等方面进行估算 • CoCoMo模型是一个综合经验模型,模型中的参数取值来至于经验值,并且综合了诸多的因素、比较全面的估算模型 • 比较实用、可操作,在欧盟国家应用较为广泛
经验估算模型(2/7) • CoCoMo模型的层次 - 支持不同的阶段 • 基本COCoMo模型(应用系统组成模型) • 系统开发的初期,估算整个系统的工作量(包括维护)和软件开发和维护所需的时间 • 中间COCoMo模型(早期设计模型) • 估算各个子系统的工作量和开发时间 • 详细COCoMo模型(后体系结构模型) • 估算独立的软构件,如各个子系统的各个模块的工作量和开发时间
经验估算模型(3/7) • 基本CoCoMo模型 • E = a (kLOC)b ;E是工作量(人月) ,a和b是经验常数 • D = c Ed ;D是开发时间(月) ,c和d是经验常数 • 其中,a,b,c,d为经验常数,其取值见下表
经验估算模型(4/7) • 中间CoCoMo模型 • E = a (kLOC)b EAF • 其中,E表示工作量(人月),EAF表示工作量调节因子,a,b为经验常数,其取值见下表
经验估算模型(5/7) • EAF的取值(考虑15个因素) • 软件产品属性(3):软件可靠性,软件复杂性,数据库的规模 • 计算机属性(4):程序执行时间,程序占用内存大小,软件开发环境的变化,软件开发环境的响应速度 • 人员属性(5):分析员能力,程序员能力,领域经验,开发环境的经验,程序设计语言的经验 • 项目属性(3):软件开发方法的能力,软件工具的数量和质量,软件开发的进度要求
经验估算模型(6/7) • EAF的取值(范围) • 很低、低、正常、高、很高、极高 • Boehm建议取值范围[0.70-1.66] • EAF的计算=Fi ( i=1..15) • 调节因子及其取值由统计结果和经验决定,不同的软件开发组织在不同的时期可能会有不同的取值
经验估算模型(7/7) • 案例分析:用基本CoCoMo模型估算项目的工作量、开发时间和参加项目开发的人数 • CAD软件:目标代码行33.2kLOC,属于中等规模,半独立型,因而a = 3.0, b = 1.12, c = 2.5, d = 0.35 • E = 3.0*(33.2)1.12 =152 PM • D = 2.5*(152)0.35 = 14.5 (月) • 参加项目人数N = E/D = 152/14.5 = 11(人)
13. 3 进度计划 • 包括估算开发时间和估算工程进度级
项目案例 小王:软件项目负责人 老王:公司技术老总 开发小组:小李,老赵,小田,小谢 • 案例角色和人物
软件项目的实施需要计划(1/3) • 项目开始实施之时,老王就提醒小王,为了更好地管理和控制软件开发项目,他应该马上着手制定软件项目的实施计划,该计划的制定对于整个项目的组织、管理和开展是至关重要的 • 由于认识到软件项目计划的重要性,小王花了1周时间制定了一个详细的软件项目计划,包括了详细的工作安排、明确的人员分工和具体的进度要求,计划看起来似乎是科学和合理的 • 项目计划最后交给项目组的所有成员进行讨论,并交付给公司的领导审阅,通过并批准,开始被付诸实施
软件项目的实施需要计划(2/3) • 软件项目计划分发到了项目组的各个成员,每个成员根据计划准确地了解了各自的任务和工作,也了解了这些工作的实施进度要求 • 根据软件项目计划开始阶段似乎一切顺利,各项工作已经按照计划的要求有序开展 • 然而,随着项目实施的进展,小王发现实际的工作很难按照计划中所计划的那样开展进行。在计划制定时,低估了软件项目的规模,高估了开发人员的素质和能力,整个计划过于乐观,软件项目计划不得不多次进行调整,项目进展一拖再拖。
软件项目的实施需要计划(3/3) • 后来小王发现,低估项目规模的一个主要原因是由于在制定计划时缺乏对项目规模的详细、准确的了解。 • 尽管小王对用户做了无数次的解释保证按期交付产品,用户对项目的按期交付表示怀疑,并要求加快项目的实施进度 • 公司高层开始表示关注,为了弥补时间和进度,不得不要求员工牺牲休息日进行加班,项目组部分成员开始抱怨。 • 幸运的是,软件项目计划在经过多达10次的更改,在项目组成员的积极努力和用户的配合下,项目最终在拖延了6个月之后顺利完工了
案例提示我们 • 软件项目计划的制定是极为重要的 • 软件项目计划应该在项目实施的初期制定 • 软件项目计划的制定必须科学、准确,这样才能真正促进软件项目的管理 • ……