西安石油大学：《软件工程 Software Engineering》课程教学资源（PPT课件）第十三章 软件项目管理 Software Management

软件生命周期 件生存周期 可行性研究 软件定义 需求分析 概要设计 详细设计 软件开发 编码 集成测试 确认测试 软件使用 使用与维护 与维护 退役

1 软件生存周期 可行性研究 需求分析 概要设计 详细设计 编 码 集成测试 确认测试 使用与维护 退役 软件定义 软件开发 软件使用 与维护 软件生命周期

软件工程 软件项目管理

2 软件项目管理

软件项目管理 (Software Management) 经理管什么? 预算 划 组织 标准 进度

软件项目管理 (Software Management) 经理管什么？ 计 划 预 算 组 织 进 度 标 准

§1.成本估计( Cost estimation) 1)静态: Effort=f( length of code) (2)动态: Effort=f(time)也与程序长度有关 Putnam model: K =3 C3 effort length tech level time 2500~12500 (3)标准值法( Expert Judgment) 请多位专家估算程序的最小规模a,最可能 的规模m,和最大规模b。以三组平均值估算程 序规模: a+4m + b L 6

4 §1. 成本估计(Cost Estimation) ⑴ 静态：Effort = f (length of code) ⑵ 动态：Effort = f (time) 也与程序长度有关 Putnam model : K = L3 Ck -3 td -4 effort length tech. level 2500~12500 time ⑶ 标准值法(Expert Judgment) 请多位专家估算程序的最小规模 a ，最可能 的规模 m，和最大规模 b 。以三组平均值估算程 序规模： 6 a 4m b L   

§1.成本估计 然后根据标准生产率( standard productivity), 即每人每日可开发程序长度,来估算工作量: L E=C SP 这里C为修正系数,反映其它因素对开发工作 量的影响:C=1+0.1×n (4)COCOMO(Constructive Cost Model): Boehm(V2.0, 1995) MM=C·KL0Ca v2.0中已改为m0 Man-Month Size Cost driver kilo-code InIo 关于成本因素的详细讨论请看教材p.225-2295

5 §1. 成本估计 然后根据标准生产率(standard productivity)， 即每人每日可开发程序长度，来估算工作量： SP L E  C  这里C为修正系数，反映其它因素对开发工作 量的影响： C = 1 + 0.1  n ⑷ COCOMO (Constructive Cost Model): Boehm (V2.0, 1995)  15 i 1 i MM = C • K L O C f a • Man-Month Size = kilo-code Cost driver info V2.0中已改为 m(f) 关于成本因素的详细讨论请看教材 p. 225 - 229

§2.进度计划( Software plan) 、 Gantt chart 优点:简单,能动态 地反映开发进展。 ABCD 缺点:难以反映多个 任务间的逻辑关系。 当前进度一

6 §2. 进度计划 (Software Plan) 1、Gantt Chart t w 1 2 3 4 5 6 7 8 A B C D 当前进度 优点：简单，能动态 地反映开发进展。 缺点：难以反映多个 任务间的逻辑关系

§2.进度计划 2 PERT(Program Evaluation& Review Technique )FACPM(Critical Path Method) 例:开发三个模块A、B、C。 A为公用模块,B、C的测试须等A的调试完成后进行 A的编码需6天,测试8天,调试6天。B的编码需7天 测试8天,调试6天。C利用已有的模块,须先理解原 模块8天,再修改8天,测试9天,调试7天。最后三模 块集成测试需5天完成 B coding (3, B testing coding ABC coding testing debugging 8 testing ( 4 modifying testing

7 0 1 2 3 4 5 6 7 8 coding A testing A debugging A B coding understanding C modifying C testinB g testing C debug ing B debug in C g testing ABC 0 1 2 3 5 6 7 8 9 coding A testing A debug ing A understanding C modifying C testing B testing C debug ing B debug in C g testing ABC 4 debug ing A B coding §2. 进度计划 2、PERT (Program Evaluation & Review Technique )和CPM (Critical Path Method) 例：开发三个模块A、B、C。 A为公用模块，B、C的测试须等A的调试完成后进行。 A的编码需6天，测试8天，调试6天。B的编码需7天， 测试8天，调试6天。C利用已有的模块，须先理解原 模块8天，再修改8天，测试9天，调试7天。最后三模 块集成测试需5天完成

Earliest §2.进度计划 持续时间 Start Time Lasting time 机动时间号 (3)标出LST:=从终点(EST=LST) Slack Time Latest Start Time 始,所有离开事件的LST-LT 中最小的 (1)标出 Lasting Time (4)标出ST:=终点LST-起点EST LT (2)标出ES:=从起点始,所有进5标出 cal Pat:即EST=LsT EST+LT 中最大的 的所有事件组成的路径 7 3 208 6 8 6 8

8 持续时间 Lasting Time 机动时间 Slack Time 编 号 Earliest Start Time Latest Start Time 0 1 2 3 5 4 6 7 8 9 36 41 30 29 22 20 14 12 0 6 0 6 14 20 8 20 28 29 36 41 (0) (0) (15) (4) (2) (4) (0) (2) (0) (2) (0) (0) 6 8 6 6 7 8 8 8 6 9 7 5 (1) 标出 Lasting Time (2) 标出 EST: = 从起点始，所有进 入事件的 EST+LT 中最大的 (3) 标出 LST: = 从终点(EST = LST) 始，所有离开事件的 LSTLT 中最小的 (4) 标出 ST: = 终点LST  起点EST  LT (5) 标出Critical Path: 即EST = LST 的所有事件组成的路径 §2. 进度计划

§3.人员组织( Personnel) 1、程序设计小组:2~8人的非正式组织 优点:规模小,交流方便 缺点:没有明确的权威负责人,组员间缺乏 必要的协调

9 §3. 人员组织 (Personnel) 1、程序设计小组：2 ~ 8人的非正式组织 优点：规模小，交流方便。 缺点：没有明确的权威负责人，组员间缺乏 必要的协调

2、主程序员组 Chief Programmer Team): Baker Ibm,1972 全面负责设计 编码、测试和安装 Chief Programmer主要负责 测试,必要时 Program Manager 替代CP Assistant CP 负责和 x。0行或的方第 性编 理量和Stu 王作 进测试 Program Manager

10 Chief Programmer Assistant CP Program Manager Program Manager Adminis￾tration Librarian Test Team Senior Programmer Junior Programmer 全面负责设计、 编码、测试和安装 主要负责 测试，必要时 替代 CP. 负责和 项目有关 的全部 事务性 工作 行政、后勤 管理 文档、工具 管理 提出具体测试方案， 编写Driver 和 Stub, 进行测试. 后备编程 力量 2、主程序员组(Chief Programmer Team)：Baker IBM , 1972