第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开发工作完毕……软件开发[0][dur=95.75days]分析/软件需求[2][dur=14days]开发[4][dur=21.75days]设计[3][dur=14.5days]项目范围规划[1][dur=3.5days]定义预备资源[1.3][dur=1day]确定项目范围[1.1][dur=0.5days]获得核心资源[1.4][dur=1day]获得项目所需资金[1.2][dur=1day]项目范围规划完成[1.5][dur=0days]制定初步预算[2.3][dur=2days]行为需求分析[2.1][dur=5days]起草初步的软件规范[2.2][dur=3days]工作组共同审阅软件规范/预算[2.4][dur=.5days]制定功能规范[3.2][dur=5days]审阅初步的软件规范[3.1][dur=2days]审阅功能规范[3.4][dur=2days]根据功能规范开发原型[3.3][dur=4days]根据反馈修改功能规范[3.5][dur=1day]分派任务给开发人员[4.3][dur=1day]审阅功能规范[4.1][dur=1day]确定模块化/分层设计参数[4.2][dur=1day]编写代码[4.4][dur=15days]软件过程与项目管理创建WBS的基本法则每个工作工作单元在WBS只能出现一次概要任务是对其下所有任务的总结每个WBS的条目都有单独的人员负责与实际要做的工作情形保持一致建立WBS时应让项目组员参予每个WBS条目都应备案WBS既要灵活又要不失控制软件过程与项目管理任务安排建立网络图，确定关键路径。根据每个活动的工期估算值设置时间窗口前向路径(forwardpass)计算各个活动的最早结束时间反向路径(backwardpass)计算各个活动的最晚开始时间节假日等非工作日除外考虑时间缓冲，按工期