建设工程自学网站网站开发工程师适合女生吗
软件项目管理
- 1、软件项目管理概念
 - 1.1 软件项目管理内容
 - 1.2 软件项目管理的4P要素
 - 人员
 - 产品
 - 过程
 - 项目
 
- 2、软件项目度量
 - 2.1 软件项目度量定义及度量方法
 - 2.2 面对规模的度量
 - 2.3 面对功能的度量
 - UFC相关的五类组件
 - 14个复杂性调节因素 F i F_i Fi
 - 一个功能点开发代码行数
 
- 2.4 软件估算
 - 三点期望值法
 - 案例分析
 
- 基于过程分解的估算
 - 基于经验的软件估算
 - COCOMO经验估算模型
 
- 3、软件项目计划
 - 3.1 项目进度计划概念与可视化
 - 3.2 WBS分解与任务网络图
 - 编制项目进度计划的步骤
 - WBS工作分解结构
 - 关键路径计算
 
1、软件项目管理概念
·计划、协调、度量、监控、控制及报告等管理方法在软件开发和维护中的具体应用,以保证整个过程是系统的、有原则的、可量化的(IEEE610.12-90).
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。
1.1 软件项目管理内容

1.2 软件项目管理的4P要素

人员
- 客户:阐明软件需求的人员。
 - 项目管理者:计划、激励、组织和控制软件开发人员。
 - 高级管理者:负责定义业务问题。
 - 开发人员:拥有开发产品或应用程序所需技能的人员。
 - 最终用户:直接使用或者与软件产品交互的人。
 
- 团队类型 
- 封闭式:按照权利层次来组织团队,做过去类似项目有优势,难以承担创新性项目。
 - 随机式:松散。专家组合型团队。有创新优势,难以承担有次序执行的项目。
 - 开放式:封闭式+随机式。适合解决有次序又有创新的复杂项目,效率可能不是太高。
 - 同步式:根据项目分解进行分工,适合松散耦合子系统项目,项目集成可能会遇到问题。
 
 
产品

过程

项目

2、软件项目度量
2.1 软件项目度量定义及度量方法
当你能够度量你所说的事物,并能用数字表达它时,你就对它有了一定了解;反之,如果不能测量他,也不能用数字表达,就说明你对它的了解还不深入,不能令人满意。
软件项目管理的成熟化也需要度量与数字化,目的是持续改进软件过程,并用于项目估算、质量控制、生产率评估等。
-  
软件项目度量内容
- 生产率度量:项目工作量、项目周期、项目成本
 - 质量度量:产品发布之前发现的缺陷数;产品发布后用户报告的缺陷数;产品的运行速度
行业及组织的历史数据是软件项目度量的基础。 
 -  
软件项目度量的方法:面对规模的度量;面向功能点的度量;面向对象的度量;面向用例的度量
 
2.2 面对规模的度量
通过对质量和(或)生产率的测量进行规范化而得到的,这些测量是根据开发过的软件的规模得到的。
- 干行代码(KLOC):这些代码指的是源代码,通过源代码的行数来直观度量一个软件程序有多大规模。
 - 生产率(PM):PM=L/E,L表示代码总量(单位:KLOC),E表示软件工作量(单位:人月)
 - 每干行代码的平均成本(CKL):CKL=S/L,S为软件项目总开销,L表示代码总量(单位:KLOC)
 - 代码出错率(EQRI):EQRI=Ne/L,Ne表示代码出错的行数,L表示代码总量(单位:KLOC)
 - 文档与代码比(DI):DI=Pd/L,Pd表示文档页数,L表示代码总量(单位:KLOC)
 

- 优点:简单易行,自然直观
 - 缺点:依赖于程序设计语言的表达能力和功能;软件开发初期很难估算出最终软件的代码行数;对精巧的软件项目不合适。
 
2.3 面对功能的度量
用软件的功能表示软件规模,应用最广泛的是功能点(Function Pointment,FP)法。
 项目开发初期就可估算出。功能点计算目前主要基于经验公式。
 
UFC相关的五类组件
- ·内部逻辑文件(ILF,Internal Logical Files ) 
- 一个用户可识别的逻辑相关的数据组,它在应用程序边界内,由用户输入来维护。
 - 它可能是某个大型数据库的一部分或是一个独立的文件。
 
 - 外部接口文件(EIF,External Interface Files) 
- ·一个用户可识别的逻辑相关的数据组但只能被引用,且数据完全存于软件外部,由另一个应用程序进行维护
 - 是机器可读的全部接口(如磁盘或磁带上的数据文件)
 - 是另一个应用程序的内部逻辑文件
 
 - 外部输入(El,ExternalInput) 
- 来自于软件外部的数据输入
 - 控制信息(不更新ILF)/业务逻辑信息(更新ILF)
 - 可来自于一个数据输入屏幕或其他应用程序。
 
 - 外部输出(EO,External Output) 
- 经过处理的数据,由程序内部输出到外部
 - 从ILF、EIF中取出数据经过一定的组合、计算后得出的输出数据,如生成报表,派生数据,可能更新ILF
 
 - 用户查询(EQ.External Query) 
- 一个输入输出的组合过程,从一个或多个ILF、EIF中取出数据输出到程序外部
 - 输入过程不更新ILF,输出过程不进行任何数据处理
 
 

- UFC计算


 
14个复杂性调节因素 F i F_i Fi

- 优点:与程序设计语言无关,在开发前就可以估算出软件项目的规模
 - 不足:没有直接涉及算法的复杂度,不适合算法比较复杂的软件系统;功能点计算主要靠经验公式,主观因素比较多。
 
一个功能点开发代码行数

2.4 软件估算
概念:项目启动之前,软件团队应该估算将要做的工作、所需要的资源、成本、从开始到完成的时间,也即是对这些内容进行预测。
策略:项目度量方法为项目估算提供了依据与有效输入;尽量把估算推迟到项目的后期进行;根据已经完成的项目进行估算
- 项目估算方法 
- 基于分解技术的项目估算方法:基于问题分解的估算(基于LOC、基于功能点FP);基于过程分解的估算
 - 基于经验的项目估算方法:基于回归分析的经验估算模型(基于LOC、基于功能点FP);COCOMO模型
 
 
三点期望值法
在基于问题的分解估算方法中,通过估计最大值,最小值,最可能值的加权平均值作为期望值来估算。
  估计期望值 = ( 最大值 + 4 × 最可能值 + 最小值 ) / 6 估计期望值=(最大值+4\times最可能值+最小值)/6 估计期望值=(最大值+4×最可能值+最小值)/6
例如:如果估计系统X规模的最大值为100KLOC,最小值为50KLOC,最可能值为60KLOC,则其估计期望规模为 ( 100 + 4 x 60 + 50 ) / 6 = 65 K L O C (100+4x60+50)/6=65KLOC (100+4x60+50)/6=65KLOC
案例分析

- 基于LOC的估算

 - 基于功能点的估算



 
基于过程分解的估算

基于经验的软件估算
基于回归分析的经验估算模型
 
 
COCOMO经验估算模型
-  
COCOMO模型?
COCOMO是指COnstructive COst MOdel,构造性成本模型。Boehm于1981年提出,用于对软件开发项目的规模、成本、进度等方面进行估算。COCOMO模型是一个综合经验模型,模型中的参数取值来自于经验值,并且综合了诸多的因素、比较全面的估算模型。在欧盟国家应用较为广泛。 -  
COCOMO模型的层次:支持不同的阶段
-  
基本COCOMO摸型:系统开发的初期,估算整个系统的工作量(包括维护)和软件开发和维护所需的时间


 -  
中间COCOMO模型:估算各个子系统的工作量和开发时间

- EAF的取值(考虑15个因素): 
- 软件产品属性(3):软件可靠性,软件复杂性,数据库的规模
 - 计算机属性(4):程序执行时间,程序占用内存大小,软件开发环境的变化,软件开发环境的响应速度
 - 人员属性(5):分析员能力,程序员能力,领域经验,开发环境的经验,程序设计语言的经验
 - 项目属性(3):软件开发方法的能力,软件工具的数量和质量,软件开发的进度要求
 
 - EAF的取值(范围):很低、低、正常、高、很高、极高;Boehm建议取值范围[0.70-1.66];·EAF的计算=ПF:(i=1…15)
 - 调节因子及其取值由统计结果和经验决定,不同的软件开发组织在不同的时期可能会有不同的取值
 
 - EAF的取值(考虑15个因素): 
 -  
详细COCOMO摸型:估算独立的软构件,如各个子系统的各个模块的工作量和开发时间
 
 -  
 
3、软件项目计划
3.1 项目进度计划概念与可视化
对项目进行任务划分,定义任务之间的依赖关系,并进行时间估算和资源分配,确保以最佳的时间与成本输出满足质量要求的产品。
编制项目计划本质是一个优化问题。
 
-  
表示软件项目工作量(成本)与开发时间之间的PNR曲线

 -  
项目进度计划的价值
- 有序、可控制地对软件项目进行管理;
 - 确保员工保持高生产率;
 - 及时交付软件产品;
 - 降低软件开发成本;
 - 提高客户满意度;
 - 及时发布产品新版本。
 
 -  
项目进度计划的可视化
- 甘特图

工具:微软的Project软件,可以显示进度条模式

 
 - 甘特图
 -  
里程碑
里程碑显示项目进展中重大工作完成。里程碑不同于活动,活动是需要消耗资源的,里程碑仅仅表示事件的标记。

 
3.2 WBS分解与任务网络图
编制项目进度计划的步骤

WBS工作分解结构
工作分解结构(Work Breakdown Structure)是将项目按照功能或过程进行逐层分解,直到划分为若干内容单一、便于组织管理的单项工作,最终形成的树型结构示意图。
-  
作用:
- 相关成员可直观了解软件项目中的各项任务(活动);
 - 将项目分解为可管理的任务(活动);
 - 作为项目计划与跟踪的基础。
 
 -  
分解模式

 -  
WBS构建应该注意的原则
- 一个任务只应该在WVBS中的一个地方出现
 - WVBS中某项任务的内容是其下所有VVBS项的总和
 - 一个WBS项只能由一个人责任,其他人只能是参与者
 - WBS必须与实际工作中的执行方式一致
 - 应让项目团队成员积极参与创建VVBS,以确保WVBS的一致性
 - 每个WVBS项都必须文档化,以确保准确理解已包括和未包括的工作范围
 - WBS可以根据需求进行必要变更维护
 
 -  
任务网络图

 
关键路径计算
在任务网络图中,从项目开始到项目完成有许多条路径,路径上所有弧权重之和最大的路径(路径最长)叫关键路径。
在整个任务网络图中非最长的路径都叫非关键路径。
 
 关键路径的意义:关键路径上任何任务(活动)的延长都会导致整个项目周期的延长;如果缩短项目周期,就必须缩短关键路径的长度;项目经理应该随时关注关键路径上任务(活动)的完成情况以及关键路径是否发生了变化;对WBA中任务的串行和并行安排方式有指导意义。
- 可用资源对项目计划与关键路径的影响
实例:
有一个停车管理软件需要开发,包含三个功能:停车位管理、停车收费管理、人员管理
每个功能都需要经过三个活动:需求分析、系统设计、系统开发,假定这三个功能在这三个活动上花费的时间分别为(5天、4天、3天),(5天、4天、4天),(4天、5天、5天)。
有三个工程师:一个需求分析员、一个软件设计师、一个程序员。如何安排此项目活动比较好? 

 
