第5章软件过程的项目管理

第五章软件过程的项目管理5.1软件配置管理开发人员在一种无法控制的状态下访问源代码修改过的错误再次出现产品升级和维护所必需的程序和文档非常混乱多项目、多版本的管理与开发同步和并行开发问题人员流动引起知识资产的流失项目开发状态不清楚软件生产达不到规模化集成过程拖延了产品投放市场的时间由于管理不善致使未经测试的软件加入到产品中5.1软件配置管理软件项目开发管理的新需求你在一家小公司做软件工程师，开始的时候，你只有一个人，配了2个助手。你们研究了一种算法（例如：图象压缩、数据加密等），编写了一个实现模块。有一天老板看到了你的演示，认为很有市场潜力，可以结合进公司正在给某行业用户正在准备开发的系统中，成为该系统的核心技术或一个别人没有的卖点。下一周，你的队伍增加到14，与你3个人的小组不同的是，公司从其他部门为你配备了系统分析师，还有文档编制员、测试员。你的核心模块已经被大量的用户功能所包装，成为一个行业应用系统，并开始给用户试用，这是你的系统的第一版。

3个月后，公司决定把系统升级到第二版，除增加了许多新的功能外，公司决定支持多平台，同时，为了提高系统的性能和效率，准备采用第三方厂家的中间件，取代自己做的接口。第一版的缺陷修改，也要反映到第二版中。软件项目开发管理的新需求第2版经过2个多月的开发，最终推向了市场。公司的这个产品不但被用户所欢迎，也被一家大公司所看中，你们的产品，正好可以填补这家大公司产品线的空缺，你所在的公司被这家公司买去了。公司为你的项目组派来了产品经理、项目经理。公司决定这个产品的测试，由公司总部独立的测试部门承担。同时，公司决定把项目组增加到50人，其中有20多人并不在你所在的城市。在新公司里，产品管理、项目管理、测试、质量等等，都与你过去的环境和做法不同，特别不同的是，公司准备开发的第3版系统与公司原有的产品要进行融合，使他们看上去是一家出来的不同的兄弟和姐妹。5.1软件配置管理没有配置管理有配置管理5.1软件配置管理5.1软件配置管理软件配置的定义软件配置是由在软件工程过程中产生的所有信息项构成的，它可以看作该软件的具体形态（软件配置项）在某一时刻的瞬间影像。软件配置管理中的基本概念配置配置是在技术文档中明确说明最终组成软件产品的功能或物理属性。配置项在软件生存周期内所产生的各种应纳入管理范围的系统构成成分。包括各种管理文档和技术文档，源程序与目标代码，以及运行所需的各种数据等（配置管理的资源对象）。基线基线是评审过的一个或多个软件配置项，每一个基线都是下一步开发的出发点和基础。软件配置管理中的基本概念版本表示一个配置项具有一组定义的功能的一种标识。随着功能的增加、修改或删除，配置项被赋予不同的版本号。一般在配置标识方案中给出版本标识方法。软件配置管理中的基本概念配置管理库配置管理库也称受控库，用于存储软件配置项以及相关配置管理信息。5.1软件配置管理软件配置管理（SoftwareConfigurationManagement，SCM）对软件开发组所建立的软件的修改进行标识、组织和控制的艺术，其目标是减少错误，提高生产力；能够系统地处理变更，从而使得软件系统可以随时保持其完整性，又可称为变更控制，可以用来评估提出的变更请求，跟踪变更，并保存系统在不同时间的状态；5.1软件配置管理“软件配置管理过程是在整个软件生存期中实施管理和技术规程的过程，它标识、定义系统中的软件项并指定基线；控制软件项的修改和发行；记录和报告软件项的状态和修改申请；保证软件项的完整性、协调性和正确性以及控制软件的存储、处理和交付。”------ISO/IEC12207软件配置管理的功能并行开发支持；修订版本管理；版本控制；产品发布管理；建立管理；过程控制；变更请求管理；代码共享。软件配置管理流程基线控制

计划基线需求基线设计基线

编码基线测试基线版本控制1.版本的访问和同步控制Check-in和Check-out软件配置项通过检入(Check-in)，进入配置库，开始“冻结”；由于各种原因需要变更，从配置库中检出（Check-out）配置项；checkin和checkout通过加锁协调多用户操作；每次checkin时，在配置库上都会生成新的版本。版本控制2.版本的分支版本控制3.版本的合并将需要保护的分支锁定，打上Release标签。在以Release标签为基线的分支上开发1.1版本。版本合并：1.1版本开发完成，希望合并到基线版本中作为以后开发新版本的基础。变更控制微软的每日编译每日编译每天都对所有的源代码进行一次完整的编译，生成一份可执行的产品程序；每日编译的目的展示最新进展测试的基础产生新版本号检查并发布编译结果生成编译报告5.2软件风险管理软件开发的风险用户要求是否能确切地被理解？在项目最后结束之前要求实现的功能能否建立？是否存在目前仍未发现的技术难题？在项目出现严重误期时是否发生一些变更？糟糕的计划与估算人员流动……软件风险的类型项目风险：威胁到项目计划进度、人力、资源、客户及需求等问题技术风险：威胁到软件的质量及交付时间设计、实现、接口、验证和维护等问题商业风险：威胁到软件的生存能力市场风险策略风险销售风险管理风险预算风险5.2软件风险管理软件风险管理对影响软件项目、过程或产品的风险进行评估和控制的实践过程。软件风险管理是管理和开发软件系统必不可少的要素软件风险是工作与生俱来的；软件风险随着系统复杂程度的增加而增加；软件风险阻碍人们实现目标。风险事件图高低生命周期风险发生的概率处理风险事件的成本风险管理成熟度模型问题阶段缓和阶段防范阶段预知阶段机会阶段我疲于救火！我想知道哪里会出错！我想采取行动不留遗憾！我想知道成功的机会有多大！我想超过期望！常用的风险识别方法检查单文件审核头脑风暴德尔菲法访谈SWOT分析图表分析No.软件风险相应对策1人员不足录用优秀人才；人员应适应岗位需要；全面考虑团队建设；骨干人员工作要协调；实施培训；预先安排关键人员的使用计划2进度计划和预算不准确详细评估多种资源成本和进度；依成本进行设计；采用渐增式开发；软件复用；纯净需求3开发了错误的软件功能进行组织分析；实施任务分析；进行用户调查；开发原型；及早编制用户手册4开发了不适用的用户接口开发原型；制作脚本；作业分析；弄清了用户特征(功能性、风格、工作负荷)5只追求表面效果，需求中含有一些不必要的功能（镀金）纯净需求；开发原型；成本－效益分析；依成本进行设计6需求不断变更重大变更设限；信息隐蔽；渐进式开发7外供部件不足制定基准点；检验；参考基准检查；兼容性分析8外包任务问题参考基准检查；发包前审核；未发包合同；竞标设计或开发原型；建立团队9实时性能达不到要求模拟；制定基准；建模；开发原型；安装测量装置；调准10误解计算机科学能力技术分析；成本－效益分析；开发原型；参考基准检查10种常见的软件风险定量的风险分析量化的风险分析通常需要对事实进行更详细的分析，较之主观的风险分析往往更为可靠。主要的量化分析方法有：

比率/范围分析概率分析敏感性分析定量的风险分析可能性定义为百分数、一个词组或一个相对数字定量的风险分析影响度从性能、成本、进度和支持四个风险因素分析影响度。5.3项目计划管理什么：工作的具体内容，一定时期的工作重点怎样：如何完成这些工作和任务谁：确定具体人员或部门何时：各项工作需要多少时间多少：每项工作需要多少经费哪里：各项工作进行的环境常见错误过于乐观的计划在压力下放弃计划在项目过程中不细化计划、不及时更新计划，不监控计划的执行缺乏足够的风险管理缺乏质量计划项目估算时遗漏必要的任务前期活动不合要求项目计划的重要性体现了对客户需求的理解为项目管理和运作提供可行的计划是有条不紊地开展软件项目活动的基础跟踪、监督和评审计划执行情况的依据是项目相关个人和组织的明确承诺项目计划工作分解结构表（WBS）工作分解结构（WBS，WorkBreakdownStructure）以工作为导向对项目要素进行的分组，它定义了项目的整个工作范围，每细分一层表示对项目工件更详细的描述。工件（Artifact）指软件开发过程的中间或最后工作产品，包括文档、模型和程序。WBS-工作分解结构1项目范围规划

1.1 确定项目范围

1.2 获得项目所需资金

1.3 定义预备资源

1.4 获得核心资源

1.5 项目范围规划完成2分析/软件需求

2.1 行为需求分析

2.2 起草初步的软件规范

2.3 制定初步预算

2.4 工作组共同审阅软件规范/预算

2.5 根据反馈修改软件规范

2.6 确定交付期限

2.7 获得开展后续工作的批准(概念、期限和预算)2.8 获得所需资源

2.9 分析工作完成3设计

3.1 审阅初步的软件规范

3.2 制定功能规范

3.3 根据功能规范开发原型

3.4 审阅功能规范

3.5 根据反馈修改功能规范

3.6 获得开展后续工作的批准

3.7 设计工作完成4开发

4.1 审阅功能规范

4.2 确定模块化/分层设计参数

4.3 分派任务给开发人员

4.4 编写代码

4.5 开发人员测试(初步调试)4.6 开发工作完毕……创建WBS的基本法则每个工作工作单元在WBS只能出现一次概要任务是对其下所有任务的总结每个WBS的条目都有单独的人员负责与实际要做的工作情形保持一致建立WBS时应让项目组员参予每个WBS条目都应备案WBS既要灵活又要不失控制任务安排建立网络图，确定关键路径。根据每个活动的工期估算值设置时间窗口前向路径(forwardpass)计算各个活动的最早结束时间反向路径(backwardpass)计算各个活动的最晚开始时间节假日等非工作日除外考虑时间缓冲，按工期的百分比或固定时间。对活动时序关系设定Lead和Lag。示例示例：前向路径计算示例：后向路径计算关键路径识别Slack为0的事件为关键事件，将关键事件连接起来的最长路径为关键路径活动的浮动时间具有slack事件的活动具有浮动时间。总浮动是活动的最早结束时间和最迟结束时间的差。项目网络图PERT计划评审技术、CPM关键路径法，采用网络图来描述项目的进度安排。023456718起点A编码A调试B编码A测试C理解Ｂ测试C修改C调试C测试6687887968BC组装测试5Ｂ调试任务网络图练习以嵌入式USB主机为例，建立工作分解结构，利用网络图技术分析项目的关键路径，合理分配嵌入式USB主机项目的设计开发时间，控制进度。1.创建工作分解结构WBS；2.制定项目活动表；3.绘制前导图；4.前向路径计算；5.后向路径计算；6.确定关键活动及路径。创建WBS制定项目活动表活动活动内容持续时间（周）先行活动A项目需求分析2\B系统总体设计2AC系统硬件设计3BD初始化及用户交互界面软件设计3CE单片机与接口芯片通信软件设计3DFUSB主机系统软件设计5EGMS设备类协议软件设计3DHFAT文件系统软件设计3CI系统联调测试2F、G、HJ项目结题报告1I时间安排-甘特图甘特图：用水平线段表示任务的工作阶段；线段的起点和终点分别表示任务的开始和完成时间，线段的长度表示完成任务所需的时间。1234567891011

任务ABCDE当前进度○△○△○△○△○△完成计划完成○文档编写

△评审图例项目计划案例：建造地牢说明：你是路易10世的俘虏。他要给自己的城堡增加三个新地牢，让你做一个规划。干得好就释放，干不好就终生监禁。小地牢很难设计，要12周，但容易建成，1周即可；中地牢设计要5周，施工要6周；大地牢设计只要1周，但建造要用9周。你有一个设计师和一个建筑师，设计师不会建造而建筑师不会设计。要建好这三个地牢，你规划的工期是几周？不同的思路设计建造地牢设计建造小地牢中地牢大地牢小地牢中地牢大地牢设计建造地牢设计建