• 1. 邸书灵 信息科学与技术学院 2013-3-13软件工程概论 Introduction to Software Engineering
  • 2. 知识回顾软件项目管理 3.1 软件项目管理概述 3.2 人员组织与管理 3.3 项目沟通管理 3.4 软件项目规划软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目管理的“4P”。软件项目的生命周期:项目启动、项目规划、项目实施和项目收尾4个阶段。 软件人员组织:3种结构。沟通的复杂性、沟通方式软件规模常用估算方法包括代码行技术、功能点技术2
  • 3. 代码行技术 代码行技术是一种简单而直观的软件规模估算方法,它从过去开发类似产品的经验和历史数据出发,估算出所开发软件的代码行数。 需要给出软件的范围,并进行尽可能的分解。估算每一个子功能代码行数进行累加。 代码行数估算: L=(a+4m+b)/6 a:最佳的行数 m:可能的行数 b:悲观的行数 之后可进一步估算软件开发的生产率、每行代码的成本、每千行代码的错误个数等。 3.4.1 软件规模估算3
  • 4. 功能点技术功能点技术是依据软件信息域的基本特征和对软件复杂性的估计,估算出软件规模。 这种方法适合于在软件开发初期进行估算。 3.4.1 软件规模估算4
  • 5. 软件信息域的5个基本特征 外部输入:用户进行添加或修改的表格。 外部输出:产生的报表输出和屏幕输出。 外部查询:独立查询。 内部逻辑文件:软件修改或保存的逻辑纪录集合。 外部接口:与其他系统进行信息交换或共享的 文件。 3.4.1 软件规模估算5
  • 6. 每个特征都划分为简单、中等和复杂3个等级,不同等级有不同加权因子。可据下表计算未调整的功能点数UFP。信息域特征估算值简单加权因子 中等复杂单项总和 外部输入 外部输出 外部查询 内部逻辑文件 外部接口× × × × ×3 4 3 7 5 4 5 4 10 7 6 7 6 15 10= = = = = 未调整功能点总计 UFP 3.4.1 软件规模估算6
  • 7. 由于软件规模可能受可用性、可靠性等因素影响,因此需要视实际情况对以上功能点数进行调整。 FP = UFP ×[0.65+0.01×∑Fi] Fi:复杂度调整值,i=1,..,14。 Fi的取值(0,1,2,3,4,5)表示影响程度:0-没有影响,1-偶有影响,2-轻微影响,3-平均影响,4-较大影响,5-严重影响。 F1:系统需要可靠的备份和恢复吗? F2:系统需要数据通信吗? F3:系统有分布处理功能吗? F4:性能是临界状态吗?3.4.1 软件规模估算7
  • 8. F5:系统是否在一个实用的操作系统下运行? F6:系统需要联机数据项吗? F7:联机数据项是否在多屏幕或多操作之间进行切换? F8:需要联机更新主文件吗? F9:输入、输出、查询和文件很复杂吗? F10:内部处理复杂吗? F11:代码需要被设计成可重用吗? F12:设计中需要包括转换和安装吗? F13:系统的设计支持不同组织的多次安装吗? F14:应用的设计方便用户修改和使用吗?3.4.1 软件规模估算8
  • 9. P52:例题。 完成后,可直接用功能点表示规模,也可以将其转换成与具体开发语言对应的代码行数。3.4.1 软件规模估算9
  • 10. 各种语言的LOC/FP(平均值)程序设计语言 LOC/FP(平均值) 汇编语言 320 COBOL 91 FORTRAN 105 Pascal 91 C 128 c++ 53 VB 24 Dephi5 18 Java 4810
  • 11. 功能点技术优点 ①与程序设计语言无关,它不仅适用于过程式语言,也适用于非过程式的语言。 ②软件项目开发初期就能基本上确定系统的输入、输出等参数,能用于软件项目的开发初期。 功能点技术缺点 ①涉及的主观因素比较多,如各种权函数的取值。 ②信息领域中的某些数据有时不容易采集。 ③FP的值没有直观的物理意义。 3.4.1 软件规模估算11
  • 12. 方法: (1)自上而下:对整个项目的总开发时间和总工作量做出估算,然后把它们按阶段、步骤和工作单元进行分解。 (2)自下而上:分别估算各工作单元所需的开发时间,然后汇总得出总的工作量和开发时间。3.4.2 软件成本估算12
  • 13. (1)专家判断 专家判断是依靠一个或多个专家对项目成本作出估计,是一种近似的猜测,要求专家具有专门知识和丰富的经验。 Delphi 方法是最流行的专家评估技术,它鼓励参与者就问题相互讨论,互相说服对方,最终达成共识。 具体步骤:p54。3.4.2 软件成本估算成本估算技术:13
  • 14. 3.4.2 软件成本估算(2)类比估算 类比估算是一种比较科学的传统估算方法,它适合评估一些与历史项目在应用领域、环境和复杂度上相似的项目,通过新项目与历史项目的比较得到规模估算。 类比估算的精确度取决于历史项目数据的完整性和准确度。 具体步骤:p54。 14
  • 15. 3.4.2 软件成本估算(2)类比估算 S1整理出项目的功能列表和实现每个功能的代码行数; S2标识出每个功能列表与历史项目的相同点和不同点,特别注意历史项目中不足的地方; S3通过步骤S1和S2得出各个功能的估算值; S4产生成本估计。 15
  • 16. 3.4.2 软件成本估算(3)COCOMO模型 COCOMO是指COnstructive COst MOdel,结构性成本模型,Boehm于1981年提出,用于对软件开发项目的规模、成本、进度等方面进行估算。 COCOMO模型是一个综合经验模型,模型中的参数取值来自经验值,并且综合了诸多的因素、比较全面的估算模型。 比较实用、可操作,在欧盟国家应用较为广泛16
  • 17. CoCoMo模型的3个层次 - 支持不同的阶段 基本COCoMo模型 --系统开发的初期,估算整个系统的工作量(包括维护)和软件开发和维护所需的时间 中间COCoMo模型 --估算各个子系统的工作量和开发时间 详细COCoMo模型 --估算独立的软构件,如各个子系统的各个模块的工作量和开发时间3.4.2 软件成本估算17
  • 18. 基本CoCoMo模型 静态单变量模型,以估算出的源代码行数LOC为自变量来估算软件开发工作量。 E = a  (kLOC)b ;E是工作量(人月) ,a和b是经验常数 D = c  Ed ;D是开发时间(月) ,c和d是经验常数 其中,a,b,c,d取值见下表3.4.2 软件成本估算18
  • 19. 中间CoCoMo模型 以基本COCOMO模型为基础,通过调节因子,再对工作量估算公式进行修正。 E = a  (kLOC)b  F 其中,E表示工作量(人月),F表示工作量调节因子,a,b为经验常数,其取值见下表3.4.2 软件成本估算19
  • 20. 3.4.2 软件成本估算组织型(organic): 相对较小、较简单的软件项目。开发人员对开发目标理解比较充分,与软件系统相关的工作经验丰富,对软件的使用环境很熟悉,受硬件的约束较小,程序的规模不是很大(<50000行)。 嵌入型(embedded): 要求在紧密联系的硬件、软件和操作的限制条件下运行,通常与某种复杂的硬件设备紧密结合在一起。对接口、数据结构、算法的要求高。软件规模任意。如大而复杂的事务处理系统,大型/超大型操作系统、航天用控制系统、大型指挥系统等。 半独立型(semidetached):介于上述两种软件之间。规模和复杂度都属于中等或更高。最大可达30万行。 20
  • 21. F是调节因子,与软件产品、计算机环境、人员和项目等因素有关。 F的取值 软件产品属性:软件可靠性,产品复杂性,数据库的规模、可重用性、要求文档量。 计算机属性:执行时间限制,存储限制,平台变动 人员属性:分析员能力,程序员能力,领域经验,语言和工具经验,人员连续性 项目属性:软件工具的使用,多地点开发,软件开发的进度要求3.4.2 软件成本估算21
  • 22. F的取值(范围) 很低、低、正常、高、很高、极高 Boehm建议取值范围[0.70-1.66] F的计算=Fi ( i=1..17) //相乘 调节因子及其取值由统计结果和经验决定,不同的软件开发组织在不同的时期可能会有不同的取值3.4.2 软件成本估算22
  • 23. 23
  • 24. 案例分析:用基本CoCoMo模型估算项目的工作量、开发时间和参加项目开发的人数 CAD软件:目标代码行33.2kLOC,属于中等规模,半独立型,因而a = 3.0, b = 1.12, c = 2.5, d = 0.35 E = 3.0*(33.2)1.12 =152 人月 D = 2.5*(152)0.35 = 14.5 (月) 参加项目人数N = E/D = 152/14.5 = 11(人)3.4.2 软件成本估算24
  • 25. Homework查资料完成:其他软件成本估算方法(至少一个)。 要求:书面完成 3.4.2 软件成本估算25
  • 26. 软件项目计划是对软件项目实施所涉及的活动、人员的安排、任务的划分、开发进度、资源的分配和使用等方面作出的预先规划。或者说是一个用来协调所有其他计划、以指导项目实施和控制的文件。 应当记录计划的假设条件、方案选择,确定关键审查的内容、范围和时间,并为进度评测和项目控制提供一个基线。 IEEE软件项目计划: P56~57。3.4.3 软件项目计划26
  • 27. 第三章 软件项目管理3.5 软件风险管理 3.5.1 风险识别 3.5.2 风险分析 3.5.3 风险规划 3.5.4 风险监控27
  • 28. 3.5 软件风险管理 什么是软件风险? 使软件项目的实施受到影响和损失、甚至导致失败的、可能会发生的事件。 例如:人员的临时流失,计划过于乐观,设计的低劣。 软件风险的特点 事先难以确定。 一旦发生将带来损失,影响项目实施,甚至会导致项目失败。28
  • 29. 什么是软件风险管理?通过主动而系统地对项目风险进行全过程的识别、分析和监控,最大限度地降低风险对软件开发的影响。 识别风险(会有哪些风险?) 预防和消除风险(最好别让风险发生) 制定风险发生后的处理措施(万一发生该怎么办?)29
  • 30. 软件风险管理过程30
  • 31. 3.5.1 风险识别风险识别是试图采用系统化的方法,识别特定项目已知的和可预测的风险。 风险识别的常用方法是建立风险条目检查表,即利用一组提问来帮助项目管理者了解在项目和技术方面的一些风险。 在风险条目检查表列出所有可能的与每一个风险因素有关的提问,使项目管理者可以集中识别常见、已知的和可预测的风险,诸如软件规模、商业影响、客户特性、软件过程、开发技术、开发环境、开发人员等方面的风险。31
  • 32. 3.5.1 风险识别你认为可能存在哪些风险? 32
  • 33. 3.5.1 风险识别风险的类别(p58~62) 1软件规模 2商业影响 3客户特性 4软件过程 5开发技术 6开发环境 7开发人员 33
  • 34. 举例:风险检查表34
  • 35. 举例:风险检查表35
  • 36. 3.5.2 风险分析风险分析是对已识别的风险进行估计和评价,确定风险发生的概率与后果。 定性分析 --评估已识别出的项目风险的影响和可能性,并按照可能产生的影响进行排序。 定量分析 --量化分析每一风险的概率及其对项目目标造成的后果,并得出每种风险的大小和严重程度等。 36
  • 37. 软件开发风险通常包括性能、成本、支持和进度等因素,这些因素对项目目标可能产生的影响可以划分为可忽略的、轻微的、严重的、灾难性的等四个级别。 软件项目的风险级别(P62)3.5.2 风险分析37
  • 38. 软件项目风险评估表示例在风险分析过程中,风险评估表是一种常用的分析工具。38
  • 39. 3.5.3 风险规划在识别和分析项目风险之后,项目管理者应关 注影响较大的风险,并制定出具体的风险应对 策略。 风险应对策略 (1)风险规避:设法降低风险出现的可能性 (2)风险缓解:设法减少风险产生的影响。 (3)风险转移:将风险转移给第三方。 (4)风险接受:采取应急方案应对风险的发生。39
  • 40. 风险管理计划(1/2)针对每一个重要的风险,制定一个处理该风险的计划 风险由谁引起 表现形式是什么 可能什么时候发生 为什么发生 如何避免或者消除它的发生 发生后的处理措施40
  • 41. 风险管理计划(2/2)例,小谢将在项目实施过程中离开公司 项目组成员小谢由于出国离开公司 小谢可能会在6月1日前后出国 为了进一步学习和深造 和小谢协商能否在项目结束之后(大约7月中旬)离开 如果离开,计划让小王接替他的工作,同时让小刘分担小王的一部分工作41
  • 42. 风险应对(1/2)风险应对方式 风险规避:推迟小谢的离开时间 风险转移:让客户来做 风险接受:接受并提供处理计划,安排小王接替小谢的工作 记录风险:为将来项目风险管理提供历史数据42
  • 43. 风险应对(2/2)43
  • 44. 风险监控是跟踪和监视项目的执行状态,洞察由于人员、技术、环境等方面的变化而给项目目标实现产生的影响。 监控风险发生的情况,及早发现风险事件的征兆和苗头 监控风险管理计划的落实情况,确保该计划的有效实施 3.5.4 风险监控44
  • 45. 3.5.4 风险监控 风险监控的方式 监控和跟踪重要的(前10个)风险,记录风险危险度的变化以及风险化解的进展 中间审查,在每个里程碑后进行小规模的走查 任命风险官员(适合于大项目),警告项目风险,防止项目经理和开发人员忽略计划中的风险管理45
  • 46. 3.5.4 风险监控 风险管理者应该监控某些影响因素。“对人员流动频繁”风险,应该监控: 项目成员对项目压力的一般态度 项目组的凝聚力 项目组成员彼此间的关系 与报酬和利益相关的潜在问题 在公司内和公司外工作的可能性46
  • 47. 第三章 软件项目管理3.6 软件配置管理 3.6.1 基本概念 3.6.2 配置管理活动 3.6.3 配置管理工具 47
  • 48. 项目案例案例角色和人物小王:软件项目负责人老王:公司技术总监开发小组:小李,老赵,小田,小谢48
  • 49. 要软件产品进行配置管理(1/2)软件项目已经成功实施了8个月,项目组已经进入编码阶段,在此过程中产生了许多的软件产品。 近百个软件产品(包括技术文档、管理文档、程序模块等),项目组在管理这些产品方面感到繁琐和困难。 此时,用户提出要变更需求,软件项目组同意用户的需求变更请求,为此,修改了软件需求规格说明书。 项目组将更改后、新的软件需求规格说明书交给了软件设计小组,设计小组为此更改了设计。更改后的软件设计涉及诸多的软件模块和数据设计,为此导致许多的模块和源程序代码和可执行代码发生了变化。 由于变化的范围太大,项目组很难清晰地了解哪些作了变化、做了什么样的变化。49
  • 50. 要软件产品进行配置管理(2/2)由此带来的新的问题:项目组未能及时将这些变化通知给相关、受影响的小组和人员,从而出现软件产品之间的不一致(设计与编码不一致),所开发的产品没有完全符合和满足用户的需求。 对于某些模块更为糟糕,因为这些模块已经经过了多达6-7次的修改,而且每次修改都有意义,从而产生了不同版本的软件模块设计,由于没有相关的有效管理措施,开发人员已经很难清晰、有效识别、区分这些软件模块,出现许多开发人员都有该模块的诸多版本。 与此相对应的是,该模块的源代码也有许多版本。 在实际组装软件时,项目组不能有效提取出所需的软件产品,共同构成可运行的软件系统。50
  • 51. 案例提示我们软件开发过程中会产生大量软件产品(包括文档、 源代码和数据等),且这些产品之间存在关联关系。 同一软件产品,也会发生变更从而产生许多版本。 软件开发小组必须清晰的知道会有哪些产品、这些产品会有哪些不同的形式和版本。 开发小组必须清晰的知道如何将产品的变更通知给受影响的小组。 如果不能有效的了解软件产品及其变更,开发小组很难组装这些软件产品,进而也得不到所需的软件产品。51
  • 52. 软件配置管理什么是软件配置管理? 软件配置需要关心哪些方面的问题? 如何进行软件配置? 如何撰写软件配置管理计划? 有哪些软件工具支持软件配置活动?52
  • 53. 3.6.1 基本概念软件配置项 SCI: Software Configuration Item 基线 Baseline 版本 Version 软件配置库 SCB:Software Configuration Base 软件配置管理 SCM:Software Configuration Management53
  • 54. 软件配置项 IEEE:软件配置项是为了配置管理而作为单独实体处理的一个工作产品或软件。 软件配置项SCI的形式 与合同、过程、计划和产品有关的文档和数据 源代码、目标代码和可执行代码 相关产品:软件工具、库内可复用软件、外购软件和用户提供的软件等 54
  • 55. 基线IEEE:已经通过了正式复审的软件规格说明或中间产品,它可以作为进一步开发的基础,并且只能通过正式的变化控制过程才能改变。 简单说,基线是指软件配置项通过正式复审而进入正式受控的一种状态。55
  • 56. 基线为什么需要基线? 变化不可避免 软件产品的变化不利于软件开发 需要控制变化、软件产品保持一定程度的稳定 --以此作为软件开发的基础 --不允许随便、非正式更改 --因此相对稳定 --要改,须经评估和认可,要进行控制 基线标志着软件开发过程的各个里程碑。56
  • 57. 版本IEEE: 版本是确定在明确定义的时间点上某个配置项的状态。 版本是一个系统的具体实例。 软件的新版本可能有不同的功能和性能,或者修改了软件错误,也可能功能性能都没变化,但这对不同的软硬件环境而设置。57
  • 58. 软件配置库用于记录整个软件生命周期内与配置有关的所有信息。 应该满足以下条件: 内容不允许修改,只有有权限者才可访问。 所有配置项在各个阶段的基线是完整的。 应该可以方便地备份和恢复。58
  • 59. 软件配置管理什么是软件配置管理 在软件的整个生命周期中,对SCI进行以下工作 --系统地控制软件配置项SCI的标识、存储、更动和发放 --记录、报告其状态 --验证软件配置项SCI的正确性和一致性 --对上述工作的审计软件配置管理是一种标识、组织和控制修改的技术。59
  • 60. 软件配置管理(2/5)为什么需要软件配置管理SCM 软件产品的易改性与可控性 修改很可能引入新的错误, 使结构变坏 牵一发动全身(影响域) 团队开发时,多人并发存取需加控制(存取控制) 多应用开发时,同一软件的不同版本可能对应于不同应用,对此需加控制(版本控制) 应对软件更动状态予以追踪,并及时向有关人员通报状态情况 如果软件产品不能自始至终地保持清晰、互相一致,造成混乱、丢失,那么该软件系统会因无法使用而不得不报废60
  • 61. 软件配置管理(3/5)软件配置管理SCM要解决的问题 如何标识软件配置项SCI和管理SCI的诸多版本,以使得变化可以高效地进行 如何在软件发布给用户之前和之后控制变化 谁负责批准变化,并确定其优先级 如何保证变化被恰当地进行 采用什么机制告知有关人员已经实行了变化61
  • 62. 软件配置管理(4/5)软件配置管理的任务 软件配置项SCI的标识 --软件配置项SCI的识别:有哪些SCI? --软件配置项SCI的描述:分别是什么SCI? 版本控制 --每个软件配置项SCI有哪些版本 --控制版本的演化 变化控制 --如何应对软件配置项SCI的变化 配置审计 状态报告62
  • 63. 软件配置管理(5/5)软件配置管理SCM的目标 必须使每个软件配置项SCI保持与相关SCI的可追踪性(正确性)和完备性 使相关的软件配置项SCI之间满足文实相符,文文一致以确保软件配置项 SCI的有效性 以清晰、明了、易管理的方式标识每个软件配置项 SCI,使其满足 :可视性 、唯一标识性 使最终软件产品的正确地生成、改进和维护成为可能,保证最终软件产品的正确性63
  • 64. 3.6.2 配置管理活动软件配置项SCI标识 版本控制 系统构建 变更控制 64
  • 65. 1软件配置项SCI标识任务 识别有哪些软件配置项SCI 详细描述每个软件配置项SCI 识别软件配置项SCI的要求 完整,不要有遗漏 系统,包括所有的技术文档、必须的管理文档、所有的程序(源码和可执行)、所有的数据65
  • 66. 1软件配置项SCI标识软件配置项SCI描述的要求 唯一和直观命名,在本项目中是唯一标识的,直觉意思明确,便于望文生义,有利于对该软件配置项SCI的状态控制,便于增删、修改; 描述属性,便于进一步详细了解软件配置项SCI,如 --类型、创建者、时间、修改者,…… 描述与其他软件配置项SCI的关系,便于追踪和管理其影响66
  • 67. 2 版本管理软件配置项SCI会有不同的版本 软件因纠错/改进/完善/扩充会导致同一软件配置项SCI有多个版本 此外,在同时从事多项目开发时,同一软件配置项SCI的不同版本可能应用于不同的项目 软件配置管理SCM应有一种手段使开发者能以正确的、一致的和可重复的方式恢复和构造任一最终的软件产品版本。这就是所谓的“版本控制”。67
  • 68. 3 系统构建系统构建是把软件组件编译和连接成在一个特定目标配置上的运行程序的过程,它应该考虑以下问题: 所有组件是否都包含在构建指令中 每个组件的合适版本是否都包含在构建指令中 所有必需的数据文件是否都已齐备 内部引用的数据文件名是否一致 编译程序和其他所需工具的版本是否合适68
  • 69. 4 变更控制变化不可避免,无控制的变化将导致混乱 无论何人、何时欲修改配置库中的软件配置项SCI均应履行正规更动手续 提出书面申请 更动控制组审核和评估(必要性/可行性/影响域/资源) 同意,则授权执行指定修改;结论也可能是不同意或暂缓69
  • 70. •• Rational ClearCase – 版本控制、工作空间管理 – 支持并行开发 – 统一变更管理 – 与 Microsoft 和 IBM 的开发工具相集成 Microsoft SourceSafe – 版本控制 – 与 Microsoft 的开发工具相集成•CVS – 并发版本控制 – 开放源码的软件开发3.6.3 软件配置管理工具70
  • 71. 小结软件项目管理 3.4 软件项目规划 3.5 软件风险管理 3.6 软件配置管理 软件成本估算技术: 1专家判断 2类比估算 3COCOMO模型风险识别(7大类)。风险级别、风险评估、风险规划、风险监控配置项标识、版本控制、系统构建、变更控制,配置工具71
  • 72. 作业你认为各种风险中哪3个最应该重视?为什么? 认真了解一种版本控制工具。加以介绍。 3.5,3.6。