山东大学软件项目管理

什么是项目--项目是为完成某一独特的产品或服务所做的临时性的努力

  项目与日常运作的区别--项目是一次性的，日常运作是重复进行的

项目是以目标为导向的，日常运作是通过效率和有效性体现的

项目是通过与项目经理及其团队工作完成的，而日常运作是职能式的线性管理

项目存在大量的变更管理，而日常运作基本保持持续的连贯性的

  三约束--成本+范围+时间

  四因素--项目范围，成本，进度计划，客户满意度

  项目管理--指在项目活动中运用专门的知识、技能、工具和方法，使项目能够实现或超过项目干系人(stakeholder)的需要和期望

            一定主体，为实现其目标，利用各种有效的手段，对执行中的项目周期的各阶段工作进行计划，组织，协调，指挥，控制，以取得良好经济效益的各项活动总和

  软件项目管理定义--为使软件项目能按预定成本，进度，质量要求顺利完成，而对成本，人员，进度，质量，风险等进行分析和管理的活动

  项目管理知识体系(Project Management Body Of Knowledge， PMBOK)--项目管理的知识框架9个知识领域，5个标准化过程组及39个模块

 

 

 

 

 

  2-4 18

  项目章程--确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等。

  项目立项--明确项目的目标、时间表、项目使用的资源和经费，而且得到执行该项目的项                             目经理和项目发起人的认可 .

 

 

3-5 11 14 18 22 26 33

软件项目生存期模型定义--描述了开发的主要阶段

定义每一个阶段要完成的主要过程和活动

确定每一个阶段的输入和输出

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CMM（Capability Maturity Model）是用于衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。

 

 

 

需求定义：需求是指用户对软件的功能和性能的要求。需求是指用户对软件的功能和性能的要求。

需求类型

功能需求：系统必须执行的功能

非功能需求：对实际使用环境所做的要求，如性能要求，可靠性，安全性

非功能需求比功能需求要求更严格，更不易满足

 

需求开发：(1) 需求获取了解客户的所有用户类型以及潜在的类型，根据他们的要求来确定

系统的整体目标和系统的工作范围

(2) 需求分析也称需求建模，为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述

(3) 需求规格目的：使用户和软件开发者双方对软件的初始规定有一个共同理解，使之成为整个开发工作的基础

(4) 需求验证

 

 

任务分解定义：将项目分解为更多的工作细目和子项目，使项目更小，更易管理，易操作

目的：提高估算成本，时间和资源的准确性

是对需求的进一步细化，是最后确定项目所有任务范围的过程

结果是任务分解结构(Work breakdown structure, WBS)

 

WBS(Work Breakdown Structure)是将一个项目分解成易于管理的几个部分或几个细目，以便确保找出完成项目工作范围所需的所有工作要素

 

 

树状图：优点：直观结构清晰      缺点：不易修改    不适用：大型项目

气泡图：优点：添加修改比较容易  缺点：不直观      不适用：大型项目

列表法：最常用，项目管理软件中常使用，适用于大项目。

 

能够对工作包进行进度安排，成本估算，监视和控制

要求-逻辑上不可再分，<80h，易于估算，明确责任人

一个人两周能干完的工作或将一个人80小时能干完的工作称为一个工作包。

WBS的最低层次的可交付成果

工作包应当由唯一主体负责

 

责任矩阵(Reponsibility matrix，缩写RM）

是以表格的形式表示完成工作分析结构中工作细目的组织或个人责任的方法。

使用RM，明确框架内的权利、责任。

 

 

软件项目规模：从软件项目范围中抽出软件功能，然后确定每个软件功能所必须执行的一系列软件工程任务

直接成本

与具体项目相关的成本。例如：参与项目的人员成本

间接成本

可以分摊到各个具体项目中的成本，例如：培训、房租水电、员工福利、市场费用、管理费

 

估算过程：估算（输入、处理、输出）

常用估算方法：  类比估算  自下而上  参数估算  专家估算

 

 

 

 

 

 

进度安排有两种前提:

1 交付日期确定后安排计划

2 使用资源确定后安排计划

 

 

 

 

甘特图：可显示任务的基本信息,工期,开始,结束时间以及资源信息

棒状图:表示任务的起止时间

三角形:三角向上表示开始;向下表示结束

里程碑图：

显示项目进展中的重大工作完成

不同于活动:活动需要消耗资源且需要时间完成；里程碑表示事件的标志，不消耗资源和时间

对里程碑阶段点的设置必须符合实际，具有挑战性和可达性

进度管理与控制其实就是确保项目里程碑的达到

 

项目进度估算：常用估算方法：

基于规模的进度估算

工程评价技术

关键路径法

 

           定额估算法：T=Q/(R*S)

T:活动历时

Q:任务工作量

R:人力数量

S:工作效率（贡献率）

 

 

          经验导出模型：D=a*Eb：

D:进度(以月单位)

E：工作量(以人月单位)

a:2—4之间

b:1/3左右:依赖于项目的自然属性

 

         Walston-Felix模型： D=2.4*E 0.35

         基本COCOMO: D=2.5*Eb

 

总标准差σ＝(∑σ¡²) ½

 

浮动时间(Float): 一个活动在不影响项目完成的情况下可以延迟的时间

自由浮动（Free Float）:是在不影响后置任务最早开始时间的情况下本任务可以推迟的时间

总浮动（Total Float）:是在不影响项目最早完成时间的情况下本任务可以推迟的时间。

关键路径：浮动为0且是网络图中的最长路径，其上的任何活动延迟都会导致整个项目的延迟；是完成项目的最短时间量

 

正推法计算最早开始时间和最早完成时间

首先确定项目的开始时间

项目的开始时间是网络图中第一个任务的最早开始时间

从左到右，从上到下进行任务编排

当一个任务有多个前置任务时，选择其中最大的最早完成日期作为其后置任务的最早开始日期

公式：

ES+Duration=EF

EF+Lag=ESs(其中： Ess是后置任务的最早开始时间）

 

逆推法按照逆时间顺序计算各个任务的最晚开始时间和最晚完成时间

首先确定项目的完成时间

项目的完成时间是网络图中最后一个任务的最晚完成时间

从右到左、从上到下进行计算

当一个前置任务有多个后置任务时，选择其中最小的最晚开始日期作为其前置任务的最晚完成日期

公式：

LF-Duration=LS

LS-Lag=LFp(其中：是前置任务的最晚完成时间)

活动总时差=LS – ES

           =最晚开始时间-最早开始时间

       单时差 =LF – ES - 工期估计

           =最晚完成时间-最早开始时间

在一个网络图中，总时差为零的活动，称为关键活动，时差为零的节点称为关键节点。

 

 

质量保证（QA）：验证开发过程中是否遵循了合适的过程和标准

贯穿于整个项目的始终

质量保证活动的要点

项对项目进行评价

推测能否达到质量指标

建立对项目的信心

质量保证的主要活动

项目产品审计:根据质量保证计划对项目过程中的工作产品进行质量审计

项目执行过程审计:对执行过程进行检查, 目的是确定所得到的经验教训, 从而提高组织对这个项目或其他项目的执行水平

 

质量控制（QC）的要点

检查工作结果

按照标准跟踪检查

确定措施消灭质量问题

 

QA:Is to focus the process.

QC: Is to control the quality before delivery

 

基线（Baseline）

已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程来改变

 

基线提供了软件生存期中各个开发阶段的一个特定点

一个(些)配置项形成并通过审核，即形成基线

基线标志开发过程一个阶段的结束和里程碑

基线修改需要按照正式的程序执行

 

 

 

 

 

可以充分发挥职能部门的资源集中优势

部门的专家可以同时为部门内不同项目使用

便于相互交流 , 相互支援

可以随时增派人员

可以将项目和本部门的职能工作融为一体

 

项目和部门利益发生冲突，职能部门更重视本部门的目标,会忽视项目目标

资源平衡会出现问题

权利分割不利于各个职能部门的交流和团结协作

行政隶属关系使得项目经理没有充分的权利

 

项目经理对项目可以负全责

项目目标单一，可以以项目为中心,有利于项目顺利进行

避免多重领导

组织结构简单，交流简单,快速

 

资源不能共享

各个独立的项目处于相对封闭状态,不利于公司政策的贯彻

对项目组织的成员缺少一种事业上的连续性和安全感

项目组织之间处于分割状态,缺少信息交流

 

专职的项目经理负责整个项目 , 以项目为中心,

公司的多个项目可以共享各个职能部门的资源

即利于项目目标的实现,又利于公司目标方针的贯彻

项目成员的顾虑减少了

 

容易引起职能经理和项目经理权力的冲突

资源共享也能引起项目之间的冲突

 

风险概念

软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失

 

风险管理

是指在项目进行过程中不断对风险进行识别、评估，制定策略，监控风险的过程。合理地使用各种风险应对措施、管理方法、技术和手段对项目的风险进行有效的控制，妥善处理风险事件造成的不利后果，以最小的成本保证项目总体目标的实现

 

风险识别   或称风险辨识，是试图通过系统化地确定对项目计划的威胁，识别已知和可预测的风险。

风险识别的输入与输出   输入可能是项目的WBS、工作的陈述（Statement Of Work，SOW）、项目相关信息、项目计划假设、历史项目数据，其他项目经验文件、评审报告、公司目标等。风险识别的输出是风险列表。

 

风险分析/评估

对识别出的风险做进一步分析，对风险发生的概率进行估计和评价，对风险后果的严重程度进行估计和评价，对风险影响范围进行估计和评价，以及对于风险发生时间进行估计和评价。

 

风险规划：针对风险分析的结果，为提高实现项目目标的机会，降低风险的负面影响而制定风险应对策略和应对措施的过程，即制定一定的行动和策略来对付、减少、以至于消灭风险事件造成的影响

 

风险控制过程

对触发事件做出反应

执行风险行动计划

对照计划报告进展

修正与计划的偏差