第11章:【系统架构设计师】项目管理

发布于:2025-07-08 ⋅ 阅读:(12) ⋅ 点赞:(0)

1.盈亏平衡分析

项目盈亏平衡分析是通过测算项目盈利与亏损的临界点(即盈亏平衡点),评估项目抗风险能力和盈利能力的一种财务分析方法。其核心是找到项目收入等于总成本时的业务量(如产量、销量、销售额等),此时项目利润为零。

关键要素:

  1. 固定成本:不随业务量变化的成本(如租金、设备折旧);
  2. 变动成本:随业务量正比例增加的成本(如原材料、直接人工);
  3. 单位售价:产品或服务的单价。

2.进度管理(★★★★)

进度管理就是采用科学的方法,确定进度目标编制进度计划资源供应计划,进行进度控制,在与质量、成本目标协调的基础上,实现工期目标

具体来说,包括以下过程:

  • 活动定义:确定完成项目各项可交付成果而需要开展的具体活动
  • 活动排序:识别和记录各项活动之间的先后关系和逻辑关系
  • 活动资源估算:估算完成各项活动所需要的资源类型和效益
  • 活动历时估算:估算完成各项活动所需要的具体时间
  • 进度计划编制:分析活动顺序、活动持续时间、资源要求和进度制约因素,制订项目进度计划。
  • 进度控制:根据进度计划开展项目活动,如果发现偏差,则分析原因或进行调整。

2.1图形描述方法

1.甘特图(Gantt chart)又称为横道图、条状图(Bar chart),通过条状图来显示项目、进度和其他时间相关的系统进展的内在关系随着时间进展的情况。以提出者亨利·劳伦斯·甘特(Henry Laurence Gantt)先生的名字命名。

优点:甘特图直观、简单、容易制作,便于理解,能很清晰地标识出每一项任务的起始时间与结束时间,一般适用比较简单的小型项目,可用于WBS的任何层次、进度控制、资源优化、编制资源和费用计划。
缺点:不能系统地表达一个项目所包含的各项工作之间的复杂关系,难以进行定量的计算和分析,以及计划的优化等。 

2.项目计划评审技术(Program Evaluation& Review Technique,PERT)反应任务之间的依赖关系。

PERT图是把工程项目当做一个系统,用网络图或表格或矩阵来表示各项具体工作的先后顺序和相互关系,以时间为中心,找出从开工到完工所需时间最长的关键线路,并围绕关键线路对系统进行统筹规划、合理安排,以及对各项工作的完成进度进行严密控制,以达到用最少的时间和资源消耗来完成系统预定目标的一种计划与控制方法。

简单地说,PERT是利用网络分析制定计划以及对计划予以评价的技术。它能协调整个计划的各道工序,合理安排人力、物力、时间、资金,加速计划的完成。在现代计划的编制和分析手段上,PERT被广泛的使用,是现代化管理的重要手段和方法。

PERT网络是一种类似流程图的箭线图。它描绘出项目包含的各种活动的先后次序,标明每项活动的时间或相关的成本。对于PERT网络,项目管理者必须考虑要做哪些工作,确定时间之间的依赖关系,辨认出潜在的可能出问题的环节,借助PERT还可以方便地比较不同行动方案在进度和成本方面的效果。

2.2关键路径

关键路径:是项目的最短工期但却是从开始到结束时间最长的路径。进度网络图中可能有多条关键路径,因为活动会变化,因此关键路径也在不断变化中关键活动:关键路径上的活动,最早开始时间=最晚开始时间。

总时差【即:松弛时间】∶在不延误总工期的前提下,该活动的机动时间。活动的总时差等于该活动最迟完成时间与最早完成时间之差,或该活动最迟开始时间与最早开始时间之差

通常,每个节点的活动会有如下几个时间

最早开始时间(ES:Earliest Start Time)某项活动能够开始最早时间

最早结束时间(EF:Earliest Finish time)某项活动能够完成的最早时间。EF=ES+工期

最迟结束时间(LF:Latest Finish time)为了使项目按时完成,某项活动必须完成的最迟时间。

最迟开始时间(LS:Late Start Time)为了使项目按时完成,某项活动必须开始的最迟时间。LS=LF-工期

这几个时间通常作为每个节点的组成部分,如图所示:

  • 顺推最早开始ES=所有前置活动最早完成EF的最大值(前面活动完成后才能开始);最早完成EF=最早开始ES+持续时间。

  • 逆推最晚完成LF=所有后续活动最晚开始L5的最小值(不耽误后面活动的完成);最晚开始LS=最晚完成LF-持续事件。

习题1:

某工程包括A、B、C、D四个作业,其衔接关系、正常进度下所需天数和所需直接费用、赶工进度下所需的最少天数和每天需要增加的直接费用见下表。该工程的间接费用为每天5万元。据此,可以估算出完成该工程最少需要费用(请选择)万元,以此最低费用完成该工程需要(请选择)天。

A 106    B 108    C 109    D 115
A 7        B 9        C 10      D 12
做题知识点准备:

直接费用:直接在项目组上花掉的钱,如人工、材料等具体项目支出。

间接费用:公司统一花掉的钱分摊到各个项目组,如房租、水电等公共开支,按天计算(本题中每天5万元)。

赶工进度:通过增加资源(如加班或加人)来缩短工期的方式,但会增加直接费用。

正常进度:按常规工作节奏进行的项目进度安排。

步骤一:找出关键路径:A     C     D

步骤二:初始费用计算

直接费用总和:15+18+15+7=55万元

间接费用:5×12=60万元

总费用:55+60=115万元

步骤三:分析优先压缩关键路径的天数,并且优先压缩D的工期(因为费用最低)

压缩原则:只压缩关键路径活动才能缩短总工期;优先选择"性价比高"的活动(每天增加直接费用低的);避免改变关键路径使问题复杂化。

压缩D活动2天(不能改变关键路径,因此先压缩2天)

增加直接费用:2×2=4万元

减少间接费用:2×5=10万元

压缩A活动2天

增加直接费用:2×4=8万元

减少间接费用:2×5=10万元

同时压缩B和D各1天

增加直接费用:2+2=4万元

减少间接费用:1×5=5万元

步骤四:最终结果

总压缩:5天(12→7天)

费用变化:直接费用+16万,间接费用-25万

最低总费用:

115+(16−25)=106万元

最优工期:7天

3.软件配置管理

配置管理是为了系统地控制配置变更,在系统的整个生命周期中维持配置的完整性和可跟踪性,而标识系统在不同时间点上配置的学科。

在GB/T11457-2006中将“配置管理”正式定义为:“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征,控制这些特征的变更,记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”

配置管理包括6个主要活动制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付

3.1配置项

配置项(配置管理的对象):GB/T11457-2006对配置项的定义为:“为配置管理设计的硬件、软件(文档、代码)或二者的集合,在配置管理过程中作为一个单个实体来对待”。

以下内容都可以作为配置项进行管理:

  • 外部交付的软件产品和数据

  • 指定的内部软件工作产品和数据

  • 指定的用于创建或支持软件产品的支持工具

  • 供方/供应商提供的软件和客户提供的设备/软件

典型配置项包括项目计划书需求文档设计文档源代码可执行代码测试用例运行软件所需的各种数据,它们经评审和检查通过后进入配置管理。

每个配置项的主要属性有:名称标识符文件状态版本作者日期等。

配置项可以分为基线配置项和非基线配置项两类,例如,

  • 基线配置项(很重要,不能随便更改)可能包括所有的设计文档和源程序等

  • 非基线配置项可能包括项目的各类计划和报告等

所有配置项的操作权限应由CMO(配置管理员)严格管理基本原则是:

  • 基线配置项向开发人员开放读取的权限;

  • 非基线配置项向PM(项目经理)、CCB及相关人员开放。

配置项的状态可分为“草稿”“正式”和“修改”三种。

  • 配置项刚建立时其状态为“草稿”。

  • 配置项通过评审后,其状态变为“正式”。

  • 此后若更改配置项,则其状态变为“修改”。

  • 当配置项修改完毕并重新通过评审时,其状态又变为“正式”。

3.2配置项版本号

3.3配置项版本管理

在项目开发过程中,绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”,所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本避免发生版本丢失或混淆等现象,并且可以快速准确地查找到配置项的任何版本

3.4配置基线

配置基线(常简称为基线)由一组配置项组成,这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结"了,不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序

基线通常对应于开发过程中的里程碑一个产品可以有多个基线也可以只有一个基线。交付给外部顾客的基线一般称为发行基线(Release)内部开发使用的基线一般称为构造基线(Build)

4.质量管理

质量是软件产品特性的综合,表示软件产品满足明确(基本需求)或隐含(期望需求)要求的能力。质量管理是指确定质量方针、目标和职责,并通过质量体系中的质量计划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动。

主要包括以下过程

  1. 质量规划:识别项目及其产品的质量要求和标准,并书面描述项目将如何达到这些要求和标准的过程。

  2. 质量保证:一般是每隔一定时间(例如,每个阶段末)进行的,主要通过系统的质量审计(软件评审)和过程分析来保证项目的质量。

  3. 质量控制实时监控项目的具体结果,以判断它们是否符合相关质量标准,制订有效方案,以消除产生质量问题的原因。

4.1影响软件的3要素

4.2质量控制和质量保证

4.3能力成熟度模型

能力等级 特点 关键过程区域

初始级

Initia

软件过程的特点是杂乱无章,有时甚至很混乱,几乎没有明确定义的步骤,项目的成功完全依赖个人的努力和英雄式核心人物的作用
可重复级Repeatable 建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性,有必要的过程准则来重复以前在同类项目中的成功。 软件配置管理、软件质量保证、软件子合同管理、软件项目跟踪与监督、软件项目策划、软件需求管理(6 个)

已定义级

Defined

管理和工程两方面的软件过程已经文档化、标准化,并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来发和维护软件 同行评审、组间协调、软件产品工程、集成软件管理、培训大纲组织过程定义、组织过程集点
已管理级Managed 制定了软件过程和产品质量的详细度量标准。对软件过程和产品质量有定量的理解和控制。 软件质量管理和定量过程管理
优化级Optimized 加强了定量分析,通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进 过程更改管理、技术改革管理和缺陷预防

4.4能力成熟度模型集成

若干过程模型的综合和改进,不仅仅软件,而是支持多个工程学科和领域的系统的、一致的过程改进框架,能适应现代工程的特点和需要,能提高过程的质量和工作效率。

CMMI两种表示方法

1.阶段式模型:类似于CMM,它关注组织的成熟度,五个成熟度模型如下:

能力等级 特点 关键过程区域
初始级 过程不可预测且缺乏控制
已管理级 过程为项目服务 需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证
已定义级 过程为组织服务 需求开发、技术解决方案、产品集成、验证、确认组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境
定量管理 过程已度量和控制 组织过程性能、定量项目管理
优化级 集中于过程改进和优化 组织级改革与实施、因果分析和解决方案

2.连续式模型:关注每个过程域的能力,一个组织对不同的过程域可以达到不同的过程域能力等级。 

4.5数据管理能力成熟度模型

5.风险管理

风险管理就是要对项目风险进行认真的分析和科学的管理,这样,是能够避开不利条件、少受损失、取得预期的结果并实现项目目标的,能够争取避免风险的发生或尽量减小风险发生后的影响。但是,完全避开或消除风险,或者只享受权益而不承担风险是不可能的

风险管理过程

  • 风险管理计划编制:如何安排与实施项目的风险管理,制定下列各步的计划。
  • 风险识别:识别出项目中已知和可预测的风险,确定风险的来源、产生的条件、描述风险的特征以及哪些项目可以产生风险,形成一个风险列表
  • 风险定性分析:对已经识别的风险进行排序,确定风险可能性与影响、确定风险优先级、确定风险类型
  • 风险定量分析:进一步了解风险发生的可能性具体由多大,后果具体由多严重。包括灵敏度分析,期望货币价值分析、决策树分析、蒙特卡罗模拟。
  • 风险应对计划编制:对每一个识别出来的风险来分别制定应对措施,这些措施组成的文档称为风险应对计划。包括消极风险(避免策略、转移策略(买保险)、减轻策略);积极风险(开拓、分享、强大)。
  • 风险监控:监控风险计划的执行,检测残余风险,识别新的风险,保证风险计划的执行,并评价这些计划对减少风险的有效性。

信息系统项目中,从宏观上来看,风险可以分为项目风险、技术风险和商业风险

  • 项目风险是指潜在的预算、进度、个人(包括人员和组织)、资源、用户和需求方面的问题,以及它们对项目的影响。项目复杂性、规和结构的不确定性也构成项目的(估算)风险因素。项目风险威胁到项目计划,一旦项目风险成为现实,可能会拖延项目进度,增加项目的成本。

  • 技术风险是指潜在的设计、实现、接口、测试和维护方面的问题。此外,规格说明的多义性、技术上的不确定性、技术陈旧、最新技术(不成熟)也是风险因素。技术风险威胁到待开发系统的质量和预定的交付时间。如果技术风险成为现实,开发工作可能会变得很困难或根本不可能。

  • 商业风险(卖不出去)威胁到待开发系统的生存能力,主要有以下5种不同的商业风险

    • 市场风险。开发的系统虽然很优秀但不是市场真正所想要的。

    • 策略风险。开发的系统不再符合企业的信息系统战略。

    • 销售风险。开发了销售部门不清楚如何推销的系统。

    • 管理风险。由于重点转移或人员变动而失去上级管理部门的支持。

    • 预算风险。开发过程没有得到预算或人员的保证。