教学课件PPT软件的项目管理 .ppt 75页

'第三章软件项目管理刘燕 软件项目管理概念：为了使软件项目能够按预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件产品与其他任何产业的产品不同，它是非物质性的产品，是知识密集型的逻辑思维产品。由于软件的这种独特性，使软件项目管理过程更加复杂和难以控制。 3.1软件项目管理概述3.1.1软件项目的特征____”复杂和易变“（1）软件产品的不可见性：抽象的、逻辑的。（2）项目的高度不确定性：复杂的、管理者难以预见所有的问题。（3）软件过程的多变化性：软件各工作环节是一个迭代和增量发展的动态过程。（4）软件人员的高流动性：项目核心人才流动性高。 软件项目管理的主要特点是：1、软件项目管理涉及的范围广，涉及到软件开发进度计划、人员配置与组织、项目跟踪与控制等。2、应用到多方面的综合知识，特别是要涉及到社会的因素、精神的因素、认知的因素，这比技术问题复杂得多。3、人员配备情况复杂多变，组织管理难度大。4、管理技术的基础是实践，为取得管理技术成果必须反复实践。 3.1.2软件项目管理的“4P”（1）人员：人员的素质和组织管理是保证项目成功的重要因素。涉及人员的选择、组织、分工与管理。（2）产品：软件的目标是在预定的时间和成本内开发出满足客户需求的产品，质量问题主要发生在需求阶段，对问题不确定、描述不准确。主要是需求分析和需求变更的管理。（3）过程：将软件开发和维护所用到的技术、方法、活动和工具有机地结合起来。（4）项目：在于规划和跟踪控制。①在启动和规划阶段：确定项目范围和需求，以此为基础进行项目规划、估算和资源分配、制定计划。②过程执行：关注项目进展和变更控制。 过程定义过程改进项目规划项目监控项目实施软件过程管理软件项目管理 3.1.3软件项目管理活动软件项目管理活动包括项目启动、项目规划、项目实施、项目收尾（1）项目启动①与客户一起确定项目范围②组建项目团队③建立项目环境 开发小组的组织有以下原则：1、软件开发小组的规模不宜太大，人数不能太多，一般3-5人左右为宜。2、切忌在开发过程中增加人员，这将因增加人员之间的联系而降低效率。例：设一开发小组有4个软件工程师（图a），开发效率为5000行/年，共有6条通信路径，每条路径降低生产率250行/年，则小组生产率为：5000×4－250×6＝18500（行/年）如为了加快进度，新增加2人（图b），每人效率为840行/年，通信路径增加到15条，此时的小组生产率为：20000＋840×2－250×15＝17930（行/年）即新增加人，并未提高生产率。图a图b （2）项目规划①确定项目活动②预算项目成本③指定进度计划 ▲▲▲软件测试▲▲▲编码▲▲详细设计▲▲▲总体设计▲▲▲需求分析123456789101112任务月份进度表 010203040506070一月二月三月四月五月六月进度表 （3）项目实施①监控项目执行：下图为任务之间的依赖关系120378456周任务5101520A1A2A3B1B2E1E2CD1D2D3网状时标图 ②管理项目风险：③控制项目变更：（4）项目收尾①客户验收项目：②安装培训软件：③总结项目经验： 3.2人员组织与管理1、最好的和最坏的程序员的比较：生产效率：10：1运行速度和空间：5：12、在软件的开发过程中，人员的选择、分配和组织直接影响着项目的效率、进度、过程管理和产品的质量。 软件项目组的三种常见管理模式3.2.1软件项目组织1、民主式组织结构：组长和成员完全平等。优点：有利于每个成员发挥创造力。缺点：领导缺乏权威，分歧不易同意，不适合大规模的软件开发。 2、主程序员式组织结构由一个人全面负责（主程序员），其他人员给予必要的支持，以便提高效率。主程序员：软件的体系结构、关键部分的详细设计、指导其他人员的工作。后备程序员：密切协助主程序员工作，并负责外事工作。秘书：完成事务性工作优点：1、专业化分工明确；2、降低了管理的复杂性秘书主程序员后备主程序员程序员程序员程序员 3、技术管理式组织结构是民主式和主程序员式两种方式的结合1、技术组长：负责小组的技术决策、代码审查；2、管理组长：负责非技术性事物的管理工作，对成员的业绩进行评价缺点：如果权限划分不清，会导致职责混乱技术组长管理组长程序员程序员程序员 开发大型软件的层次式结构项目管理组长组长组长程序员程序员程序员程序员程序员程序员 3.3项目沟通管理1、软件的组织涉及领域专家、用户、分析人员、设计人员、程序员、测试人员和管理人员等，各自承担不同的工作并协调完成整个任务。2、项目沟通是软件工程中最关键和最耗时的工作。大多数项目失败的主要原因在于项目内部或外部沟通不畅、误解和遗漏。 3.3.1项目沟通复杂性沟通太少和太多都会严重影响开发人员的工作效率3.3.2项目沟通方式1.直接交谈：基于时机的非正式沟通由，由事件驱动。节省时间；不能有太多的人参加，也没有记录。2.电话交谈：直接交谈的一种方式，不受地点限制，但受同一时间限制3.电子邮件：和电话相似，但不受时间限制，但是行文可能让人不能正确理解。 4.会议：受时间和地点的限制，并且有详细的准备工作，参与的人员可以是多位。常见的会议：项目启动会议阶段评审会议解决问题会议项目验收会议5.项目网站：保持组间交流，对外发布信息：项目文档的最新版本、进展动态、论坛6.书面报告：表达准确、完整适合复杂性高、逻辑性强的信息沟通。但花费时间长、缺乏信息反馈。 3.3.3.项目沟通活动项目管理者需要规划沟通的内容、方式、渠道及物质条件1.规划项目沟通：（1）项目组内部的信息交流活动状态检查：组内讨论：需求阐明：项目变更（2）项目组之间的信息交流活动客户评审、项目评审、版本发布、需求阐明、项目变更、问题讨论。2.建立基础设施：项目管理者建立的信息系统以网站为例可实现：项目公告、问题论坛、项目文档。 3.实施阶段性评审（1）客户参与的评审活动需求文档发布及系统验收交付（2）项目组进行的评审活动：贯穿软件过程4.每周组织小组会议主要解决各项任务与计划中突出的项目中未解决的和有偏差的问题。 3.4软件项目规划软件项目规划包括以下几个步骤：确定项目的范围，最终产品、开发时间、成本、质量标准。分解和定义项目的各项活动和任务。估算项目规模和所需资源制定合理的工作计划 3.4.1软件规模估算1代码行度量技术以LOC（LinesofCode,代码行）表示的软件规模是最基本的度量，它直接关系到软件的成本、开发工作量和完成时间。软件质量通常以每千行代码中存在的错误数来衡量。例：项目A01工作量：13（人月）代码规模（KLOC）：9成本（元/LOC）:12文档页数：240错误数：20人数：4 L=(a+4m+b)/6对于每一个项目，可以根据上面列出的基本数据进行一些简单的面向代码行的生产率和质量的度量。例：软件成本(元)=LOC（行）×每行代码的成本（元/行）开发工作量(人)=LOC(行)/每人月开发的代码行(行/人月)有些项目可计算出平均值：1、生产率=KLOC/PM（人月）2、单位成本(每行代码的平均成本）：C=S(总成本)/KLOC3、代码出错率：EQR=N(错误数)/KLOC面向代码行度量技术尽管为很多软件企业采用，但其也有明显缺点。 2功能点技术本方法针对程序的“功能性”，其依据在于，任何软件是由若干功能组成的，每种功能可划分为复杂程度不同的若干功能点，利用功能的一些计算度量和功能复杂性估计的经验关系式，得出功能点度量数据，以代替原来常用的LOC度量法。根据软件功能的类型和特征，可把功能划分为五种类型：用户输入，用户输出。用户查询，主文件数，外部处理。 1、外部出入：用户进行添加或修改数据的屏幕、表格，但不包括查询。2、外部输出：软件为用户产生的屏幕、表格，但不包括错误信息。3、外部查询：软件以联机的方式产生的独立查询。4、内部逻辑文件：软件修改或保存的逻辑记录集合，可以是关系数据库的表或独立数据文件。5、外部接口与其他系统进行信息交换或共享的文档。 五类功能点按其复杂程度可划分为简单、中等、复杂3种，表3-2给出的功能点加权计算表。表3-2功能点加权计算表软件功能点数加权计算方法如下：以类型“用户输入”为例，设功能点按等级分类计数分别为：简单为Inp1个，中等为Inp2个，复杂为Inp3个，则： 功能点计数Inp=Inp1+Inp2+Inp3分类加权计算合计数Inp_FP=Inp1×3+Inp2×4+Inp3×6软件加权功能点数量为：UFP=Inp_FP+Out_FP+Inq_FP+Fil_FP+Int_FP用TCF（技术复杂性因子）来修正、调节功能点的计算方法。FP（调节后）=UFP×TCF其中：TCF=0.65+0.01×∑Fi（I=1～14）Fi取值见表3-3。当由公式计算出FP修正值后，就可像LOC方式一样，计算出项目软件的其他属性，例：生产率功能点成本、质量等。 3.4.2软件成本估算软件成本（开发时间和工作量）估算的一般方法包括专家判断、类比估算、经验模型。方式：自上而下：由总体目标逐级划分到单元。自下而上：由单元逐级汇总到总体目标。 1、专家判断：一个或多个专家对项目成本作出估算。要求专家具有专门的知识和丰富的经验。Delphif方法的步骤：1）项目协调人向每个专家提供软件规模和估算表格；2）项目协调人召集专家小组会讨论与规模相关的因素；3）每个专家匿名填写成本估算表格；4）项目协调人整理出一个估算总结，并将其反馈给专家；5）项目协调人召集专家小组讨论较大的估算差异；6）专家复查估算总结，并在估算表上提交另一个匿名估算；7）重复4~6，直到个专家意见达成一致。 2、类比估算：类比估算是一种比较科学的传统估算方法，适合评估一些历史项目在应用领域、环节和复杂度上相似的项目，新项目与历史项目的比较得到规模估算。故其结果的准确度取决于历史项目数据的完整性和准确度。基本步骤为：1）整理出项目的功能列表和实现每个功能的代码行数；2）标识出每个功能的列表与历史项目的相同点和不同点，特别注意历史项目中不足；3）有步骤1和2得出各个功能的估算值；4）产生成本估算。 3、COCOMO模型结构型成本估算模型（ConstructiveCostModel）,简称COCOMO模型，由W_Boehm于1981年提出。基本COCOMO模型是一个静态单变量模型，它以一个已计算出来的代码行数（LOC）为自变量的函数公式，计算软件开发工作量、进度等数据。并依据开发环境、应用领域和技术复杂性程度等因素对软件开发项目进行分类。COCOMO模型可分为基本的、中间的和详细的三个层次。 软件项目分类（1）组织型（Organic）：各种应用类软件；（2）半独立型（Semidetached）：各类实用程序、编译程序；（3）嵌入型（Embedded）实时处理、控制程序、操作系统。 （1）基本COCOMO模型是一个静态单变量模型，它用估算出来的程序代码行数（LOC）为自变量，通过计算软件的工作量等，对软件成本作粗略估算。估算公式如下：开发所需工作量（人月）：E=aLb开发时间（月）：D=cEd 类型abcd组织型2.41.052.50.38半独立型3.01.122.50.35嵌入式3.61.22.50.32例：一个规模为10KSDI的微处理器上的嵌入型电信处理程序，使用基本COCOMO模型计算所需的工作量和开发时开发工作量E=3.6×101.2开发时间D=2.5×E0.32如果参入分析与设计人员的月平均工资为6000元，则开发该项目的工资支出成本为：6000×2.5×E0.32 （2）中间COCOMO模型在基本模型处理的基础上，再考虑影响软件产品、硬件设备、人员、项目等方面属性的因素（四大类15项，见表9-3），增加修正系数来调整工作量的估算。开发所需工作量（人月）：E=aLbFF= 类型ab组织型3.21.05半独立型3.01.12嵌入式2.81.2 例：一个规模为10KSDI的微处理器上的嵌入型电信处理程序，使用中间COCOMO模型计算所需的工作量和开发时间。调节因子F=0.97开发工作量:E=2.8×101.2×0.97开发时间:D=2.5×E0.32 3.4.3软件项目计划（SPMP)软件项目计划（SPMP)是用来协调其他计划，以指导项目实施和控制的文件。内容范围：计划的假设条件；方案选择；确定关键管理审查的内容、范围和时间；并为进度评测和项目控制提供一个基线。 3.5软件的风险管理项目的风险是一种不确定的事件或条件，一旦发生，就会对项目目标产生某种正面或负面的影响。软件的风险管理是主动而系统地对项目风险进行全过程的识别、分析、监控，最大限度地降低风险对软件开发的影响。 风险识别风险分析风险规划风险监控确定项目有哪些风险、分析产生的原因或影响因素，以确定风险事件及来源。方法：专家判断法、头脑风暴法等。比较风险大小、确定风险性质。对各种风险进行定性和定量分析，包括发生的概率、影响程度，对风险排序。按照风险的大小和性质，制定相应的措施去应对和响应风险。包括风险接受、风险规避、风险转移。监督、检查风险事件的发生情况及风险措施的落实情况，通过对风险事件及其来源的控制和对风险计划落实情况的监督，确保风险措施有效。 3.5.1风险识别风险识别是试图采用系统化的方法，识别特定项目已知的和可预测的风险。风险识别常用的方法：建立风险条目检查表，其中列出所有可能的与每个风险因素有关的提问，通过问答的方式帮助项目管理者了解项目和技术方面的一些风险。该方法的优点：使项目管理者可以集中识别常见的、已知的和可预测的风险。 项目风险的分类：软件规模风险商业影响风险客户相关风险软件过程风险开发技术风险开发环境风险开发人员风险 3.5.2风险分析风险分析的任务是对已识别的风险进行估计和评价，确定风险发生的概率与后果。风险的来源通常包括性能、支持、成本、进度。其影响等级划分为可忽略的、轻微的、严重的、灾难性的。风险分析的方法：头脑风暴法、建立风险评估表 举例：头脑风暴法举例：识别举办短期培训班项目的风险列出项目的工作分解结构；项目小组一起进行头脑风暴，对每一项任务进行讨论，识别所有可能的风险，防止遗漏重要的风险。 举例：头脑风暴法可能的风险确定培训项目题目选择不当，可能招不来学生，导致亏本。寻找培训讲师讲师可能生病或者临时有重要事情来不了。招生可能没有学员报名。授课投影仪可能出问题。结束课程学员不满意，大闹课堂问题：还有哪些可能的风险？ 举例：风险检查表 举例：风险检查表 风险类型常见的软件项目风险类型：软件规模风险与待开发或修改的软件系统估算相关的风险，包括系统规模、数据库大小、用户数量、可复用性、度量方法及其可信度等；如：软件规模估计不足；开发所需时间不足等。商业影响风险与软件产品的商业环境与要求相关的风险，包括产品对公司业务带来的利润影响、管理层的重视程度、交付期限的合理性、产品质量对于成本的影响、产品与其他系统的互操作性等；如：组织的结构发生了变化；组织财政问题导致项目预算消减等。 风险类型常见的软件项目风险类型：客户相关风险与客户的素质以及开发者和客户定期通信的能力相关的风险，包括需求的明确程度、客户的参与和支持程度、客户与开发人员的配合程度等；如：需求变更导致主要的设计和开发重做；客户无法理解需求变更带来的影响。软件过程风险如果软件过程定义得不清楚，分析、设计、测试是以无序的方式进行，且没有采取实际行动来保证软件的质量，则软件项目处于风险之中。包括过程问题、技术问题。如：没有定期对测试过程和测试情况进行复审；没有使用特定的方法进行软件分析。 风险类型常见的软件项目风险类型：开发技术风险与开发软件系统所使用的软件技术或硬件技术相关的风险，包括所用技术的成熟程度、开发方法的特殊要求和创新要求、功能实现的可行性等；如：数据库事务处理速度不够；拟采用的系统组件存在缺陷，而影响系统的功能。开发环境风险与所用软件工程环境相关的风险，包括软件项目管理工具、过程管理工具、分析与设计工具、编程工具、配置管理工具、测试工具等的可用程度和人员培训程度；如：CASE工具生成的代码效率低，CASE工具无法集成。 风险类型常见的软件项目风险类型：开发人员风险与项目团队成员相关的风险，包括人员的能力和经验、技术培训、人员稳定性等。如：招牌不到所需技能的人员；关键的人员在项目的关键时刻生病或不在；无法进行所需的人员培训等。 风险分析风险分析是对已识别的风险进行估计和评价，确定风险发生的概率与后果。定性分析评估已识别出的项目风险的影响和可能性，并按照可能产生的影响进行排序。定量分析量化分析每一风险的概率及其对项目目标造成的后果，并得出每种风险的大小和严重程度等。软件开发风险通常包括性能、成本、支持和进度等因素，这些因素对项目目标可能产生的影响可以划分为可忽略的、轻微的、严重的、灾难性的等四个级别。P62 举例：软件项目风险分析风险评估表是随着软件项目的进展发生变化的，项目管理者需要定期复查和更新风险评估表。 风险规划在识别和分析项目风险之后，项目管理者应该关注那些影响较大的风险，并制定出具体的风险应对策略。常用的风险应对策略包括风险规避、风险缓解、风险转移、风险接受等。风险规避是设法降低风险出现的可能性风险缓解是设法减少风险产生的影响风险转移是将风险转移给第三方风险接受是采取应急方案应对风险的发生 举例：风险应对策略 风险监控风险监控是跟踪和监视项目的执行状态，洞察由于人员、技术、环境等方面的变化而给项目目标实现产生的影响。监控风险发生的情况，及早发现风险事件的征兆和苗头监控风险管理计划的落实情况，确保该计划的有效实施风险监控可能产生的结果随机应变措施纠正行动变更请求修改风险应对计划 举例：风险监控 3.6软件配置管理软件配置管理是一种标识、组织和控制修改的技术。软件在变化过程中产生新的版本适应不同的硬件环境或操作系统提供不同的功能针对特殊的用户需求进行裁剪软件配置管理在软件生命周期中建立和修改的各种不同元素（例如：源代码和文档）协调和整理所开发的产品管理软件的构建和测试环境管理发布和安装工具管理软件的改错和功能增加目的使错误达到最小并最有效地提高生产率。 软件配置项软件配置项是为了配置管理而作为单独实体处理的一个工作产品或软件。具体形式与合同、过程、计划和产品有关的文档和数据。源代码、目标代码、可执行程序相关产品，包括软件工具、库内可复用软件、外购软件及用户提供的软件。 基线基线是已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变。基线标志着软件开发过程的各个里程碑基线是指软件配置项通过正式复审而进入正式受控的一种状态。 版本版本是确定在明确定义的时间点上某个配置项的状态。版本记录了软件配置项的演化过程，是系统的具体实例。软件在变化过程中产生新的版本针对不同的硬件环境或OS而设置具有不同的功能和性能能够适用特殊用户的需求 软件配置库作用：用于记录整个软件生命周期内与配置有关的所有信息，来帮助评估系统变更带来的影响，提供有关配置管理过程的管理信息。软件配置库应满足几个要求：软件配置库的内容不允许被任意修改和删除，只有合法用户才能进行存取访问；需要保证所有配置项在各个阶段的基线是完整的；软件配置库可以方便地进行备份和恢复，正常情况下需要每日或每周进行备份，当出现异常时可以方便地恢复配置信息。软件配置就是对软件配置库中的所有信息进行控制和管理。 配置管理活动软件配置管理贯穿整个软件开发过程，其主要活动包括软件配置项标识、版本管理、系统建立、变更控制、配置审计和配置状态报告。配置项标识版本管理系统建立变更控制 配置项标识为了便于配置项的控制和管理，需要将配置项采用合适的方式进行命名、组织。通常，采用分层命名的方式，对相关的配置项进行组织，下图给出了项目PCL－TOOLS的配置层次结构。 版本管理版本管理是对系统不同的版本进行标识和跟踪的过程，从而保证软件技术状态的一致性。版本的演变 版本管理版本管理是对版本的各种操作进行控制，包括检出控制、分支与合并、版本历史记录和版本发布等版本的存取和控制流程 系统的构建系统构建是把软件组件编译和连接成在一个特定目标配置上的可运行程序的过程。系统构建过程配置管理工具被用于自动化系统构建过程 变更控制变更控制是建立一套组织结构和控制规程，有意识地控制软件的变更过程。变更控制过程 软件配置管理工具RationalClearCase版本控制、工作空间管理支持并行开发统一变更管理与Microsoft和IBM的开发工具相集成MicrosoftSourceSafe版本控制与Microsoft的开发工具相集成CVS并发版本控制开放源码的软件开发适宜中小型软件企业适用 例题对开发人员的频繁流动这一风险的驾驭与控制。社人员的频繁流动给项目带来的风险为R1,基于以往项目的经验和直觉，该风险发生概率的估算值P1为70%，而该风险的出现给项目带来的影响的估算值X1，使项目开发时间延长15%，总成本增加20%，为了对这一风险进行驾驭和监控，应该采取哪些风险驾驭措施。'