software12软件工程项目管理

软件工程第十二章软件工程项目管理软件项目管理常见的管理技术及工具简介软件过程成熟度模型利用CMM对软件机构进行成熟度评估项目管理认证体系IPMP与PMP12.1软件项目管理软件项目管理的特点软件项目管理的主要职能软件项目管理的概念O/S360操作系统的负责人Brooks生动地描述了研制过程中的困难和混乱：“……象巨兽在泥潭中作垂死挣扎，挣扎得越猛，泥浆就沾得越多，最后没有一个野兽能逃脱淹没在泥潭中的命运……程序设计就象这样一个泥潭……一批批程序员在泥潭中挣扎……没有人料到问题竟会这样棘手……”从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目管理的特点软件产品没有物理特性,难以理解和驾驭软件产品把思想,概念,算法,流程,组织,效率,优化等融合在一起了.用户需求的不确定性文档的编制和修改软件开发的技术性和实际经验的要求软件项目管理的主要职能制定计划建立组织配备人员指导检验12.2常见的管理技术及工具简介软件项目管理的主要内容常见工具介绍项目管理计划包括的内容常见工具简介软件项目管理的主要内容项目计划管理软件项目计划包括的内容(p/282)范围资源进度安排成本估算培训计划软件项目管理的主要内容软件质量控制主要措施有:计划:在软件定义阶段就要根据项目的要求确定质量保证体系.评审:指针对软件开发的需求分析,系统设计各个阶段完成的文档进行审查测试:主要针对系统的实现,.通过测试的手段来验证软件复审:确认软件开发各阶段完成状况的过程软件项目管理的主要内容人员组织管理（10：4：1）文档管理目的作为开发人员在一定阶段工作重的结束标记向管理人员提供开发过程的进展状态详细记录开发过程的技术信息,为以后的测试,调试,维护等工作提供依据提供软件运行,维护,培训的信息,便于管理人员,开发人员和用户之间的信息沟通文档分类:文档主要分成用户文档,技术文档,维护文档三种软件配置管理（扩充）1.什么是软件配置管理2.为什么需要配置管理3.人的问题4.软件配置管理规范：概念与流程5.软件配置管理规范：配置管理计划6.软件配置管理规范：版本控制规则7.软件配置管理规范：变更控制规则8.软件配置管理规范：配置库操作9.软件配置管理规范：配置审计10.常用配置管理工具参考书：《软件工程与项目管理解析》，林锐著，电子工业出版社，20031.什么是软件配置管理1.1忏悔录曾经有一个很好的配置管理工具在我面前，我没有理睬，直到版本混乱的时候才后悔莫及，工作中最大的痛苦莫过于此，如果上天再给我一次机会的话，我向对它说三个字：我要你。如果非得加一个期限的话，我希望是一辈子。1.2概念不要和“计算机零配件组装”搞混淆。软件配置管理（SoftwareConfigurationManagement,SCM）是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。配置管理与任何一位项目成员都有关系，因为每个人都会产生工作成果。配置管理是否有成效取决于三个要素：人、规范、工具1.什么是软件配置管理1.3配置管理的商业理念企业的商业需求决定了配置管理的力度，我们不必追求完美无缺的配置管理，而是让开发团队恰好够用就行，并将为配置管理所付出的代价控制在预算之内。富有成效的配置管理的特征：任何项目成员都要对其工作成果进行配置管理，应当养成良好的习惯。不必付出过多的精力，最低要求是保证重要工作成果不发生混乱。配置管理规范应当清晰明了，便于执行，不必在细节方面要求太多，不给项目人员添加过多的负担，不使人厌烦。选择配置管理工具应当综合考虑价格、易用性和功能因素，而不是购买最先进的工具。令人满意的工具通常是价格低廉、简便易用、功能恰好够用。1.什么是软件配置管理CMM/CMMI对配置管理过程域论述得十分清楚详细，假设完全按照CMM/CMMI的要求执行的话，你可以得到100分（满分）的配置管理成绩。出于商业利益考虑，我不向往100分的成绩，因为代价太高了。我更愿意付出前者的30％左右代价获取60－70分（及格）的成绩，这样最划算。70－100分的配置管理成绩对于大部分商业软件而言没有多少意义，那属于锦上添花，如果我们没有足够的精力的话，那么就以最低的代价达到及格分数就行了。2.为什么需要软件配置管理2.1没有软件配置管理，将有什么坏处？最大的麻烦是工作成果被覆盖。如果不采用配置管理软件来保存工作成果的历史版本的话，人们在同一个文件上修改内容，保存之后，那么新的内容覆盖了老的内容。多数情况下新的内容比老的内容好，覆盖了也没关系。但是总有不少意外，例如程序员修改了老程序员之后，突然发现新程序是错误的，而老程序却是对的，可是老程序被新程序覆盖了，再也无法恢复。为了避免成果被覆盖，很多人采用最原始的手工管理版本的方式，例如给文件加后缀“-01”、“-02”以表示版本。天长日久，工作目录下就会有一堆带数字后缀的文件，而且你自己也忘记了数字后缀代表什么内容，管理起来非常麻烦。我在读大学的时候，我自己以及周围的人都不知道软件配置管理，所以大家都有上述经历。幸好在学校里的人时间不值钱，工作成果也不值钱，可以穷折腾。但是在企业里工作，我们可不能不懂软件配置管理，否则就贻误工作浪费金钱了。2.为什么需要软件配置管理2.2使用软件配置管理，将有什么好处？最直接的好处是工作成果的所有版本都被保留着，不会丢失也不会被覆盖。间接的好处是，项目的所有工作成果被完整地保留下来，这是企业的知识财富，可以被人们很好地分享利用。而且减少了人员辞职造成的损失，企业老板可以放心很多了。因为如果没有配置管理的话，人走了，即使他把成果刻录成光盘交给接收者，别人也搞不清楚那些成果的演化过程。我在事业部推广CMM的时候，有一天事业部总经理郑重其事地找我商谈，说某个产品线的经理要“跳楼N次”，请大家帮忙“解救”。因为他把更新北京客户的软件安装到天津客户那里，却把更新天津客户的软件安装到其他客户那里，现在他自己也搞不清除发生了多少错乱！如果跳楼一次能够消除一个错乱的话，那么他要跳楼N次。这是典型的版本错乱问题，只有良好的配置管理才可以解救这位产品经理。3.人的问题3.1事在人为配置管理的方法是成熟的，而且相应的软件工具也是成熟的，妨碍配置管理的主要问题是人们“嫌麻烦”（还有侥幸心理）。在没有出乱子的情况下，执行版本控制看起来有些麻烦。每次修改工作成果的时候，总是先checkout，然后再修改，最后还要checkin，多了前后两步。其实checkout和checkin两步操作只需花费几秒钟，而且不费脑子，凭良心说根本没有添加麻烦，仅仅是个人感觉不爽快而已。然而不执行版本控制的话，万一发生工作成果被覆盖或丢失等问题，那么麻烦就大了。侥幸心理导致人们麻痹大意。我也有这个毛病，我非常清楚版本控制的重要性，也能熟练使用配置管理软件，可是我常常把一个文件checkout出来后，修改了一两周后才checkin进去。我只敢对个人文件的配置管理存在侥幸心理，我从来不敢轻视软件产品的配置管理。因为前者出乱子的代价比较小，我承受得起，后者出乱子我可承受不起。（例如Future软件的配置管理）。4.软件配置管理规范：概念与流程4.1配置项软件研发和管理过程中会产生许许多多的工作成果，人们应当将文件分门别类、有条理地保存起来。凡是纳入配置管理范畴的工作成果统称为配置项（ConfigurationItem，CI）。配置项主要有两大类：属于产品组成部分的工作成果，例如源代码、需求文档、设计文档、测试用例等等。在管理过程中产生的文档例如各种计划、监控报告等等，这些文档虽然不是产品的组成部分，但是值得保存。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。4.软件配置管理规范：概念与流程4.2基线基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。4.软件配置管理规范：概念与流程4.3角色为了提高配置管理的效率和安全性，项目应当设有配置管理员这个角色。配置管理员的主要工作是为项目制定配置管理计划，创建和维护配置库等。对于大型的项目，鉴于配置管理的重要性和复杂性，机构应当设立配置控制委员会（ConfigurationControlBoard，CCB）。CCB是个虚拟小组，对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。对于配置管理而言，CCB是决策者，而配置管理员是执行者。对于普通的小型软件项目而言，CCB这个概念难以落实，我们就不要玩虚的了，让项目经理或者配置管理员做决定就行了。4.4流程5.软件配置管理规范：配置管理计划配置管理员根据本项目的特征，起草配置管理计划，由CCB负责人（通常是项目经理）审批。配置管理计划的主要内容：1.人员与职责2.软件硬件资源3.配置项计划4.基线计划5.配置库备份计划6.版本控制规则7.变更控制规则8.审批6.软件配置管理规范：版本控制规则6.1概念版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。所有项目成员都必须遵照版本控制规程操作配置库。配置项的状态有三种：“草稿”（Draft）、“正式发布”（Released）和“正在修改”（Changing）。配置项状态变迁：配置项刚建立时其状态为“草稿”。配置项通过评审（或审批）后，其状态变为“正式发布”。此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。6.软件配置管理规范：版本控制规则6.2版本号（1）处于“草稿”状态的配置项的版本号格式为：0.YZYZ数字范围为01-99。随着草稿的不断完善，“YZ”的取值应递增。“YZ”的初值和增幅由用户自己把握。（2）处于“正式发布”状态的配置项的版本号格式为：X.YX为主版本号，取值范围为1-9。Y为次版本号，取值范围为1-9。配置项第一次“正式发布”时，版本号为1.0。如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值。（3）处于“正在修改”状态的配置项的版本号格式为：X.YZ配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。参见规则（2）。7.软件配置管理规范：变更控制变更控制的目的是防止配置项被随意修改而导致混乱。为了提高效率，对于处于“草稿状态”的配置项，不必进行变更控制，因为它们本来就是草稿，本来就是要被不断地修改的。当配置项状态为“正式发布”，或者该配置项已经成为某个基线的一部分（即被“冻结”）时，如果要修改配置项的话，那么按照变更控制规则执行。7.软件配置管理规范：变更控制步骤：第一步变更申请。变更申请人向CCB提交变更申请，重点说明“变更内容”和“变更原因”。第二步审批变更申请。CCB负责人（或项目经理）审批该申请，分析此变更对项目造成的影响。如果同意变更的话，则转向第三步，否则终止。第三步安排变更任务。CCB指定变更执行人，安排他