工程管理软件 软件工程管理概述

工程管理软件

第十章 软件工程管理

10.1  软件工程管理概述

软件工程管理是对软件项目的开发管理,是对整个软件生存期的所有活动进行管理。任何工程的成败,都与管理的好坏密切相关,软件工程更不例外。尤其是软件产品的特殊性,软件工程的管理对于保证软件产品的质量具有极为重要的作用。

随着软件的规模和复杂度的不断增大,开发人员的增加以及开发时间的增长,这些都增加了软件工程管理的难度。\r\n        例如:Windows 2000的开发 是微软公司历史上最艰巨的任务,仅核心部门的的成员就有2500人,测试用的代码就有1000万行,测试中所用到的脚本程序就有6500种…。象规模如此之大的软件系统,如果没有科学的、规范的、有效的管理,是不可能成功的。因此软件工程管理成为软件工程的重要研究内容之一。

10.1 软件工程管理概述

任何技术先进的大型项目的开发如果没有一套科学的管理方法和严格的组织领导,是不可能取得成功的 。即使在管理技术较成熟的发达国家中尚且如此,在我国管理技术不高、资金比较紧缺的情况下,大型软件项目开发的管理方法及技术就显得尤为重要。\r\n软件工程管理的对象是软件工程项目,因此软件工程管理涉及的范围覆盖了整个软件工程过程。

软件工程管理的主要任务有:\r\n一、软件可行性分析与成本估算\r\n二、软件生产率及质量管理\r\n三、软件计划及人员管理

10.1.1 软件管理的任务与目标

10.1.1  软件管理的任务与目标

10.1.2  软件作用的范围

确定软件的作用范围是软件项目计划的第一项活动。是要对用户要求解决的问题进行确切定义,进一步分析软件开发的风险,以便制定软件计划。

10.1.2  软件作用的范围

从以下方面考虑软件的作用范围:\r\n  ? 软件的功能、性能\r\n  ? 接口(与硬件、软件工具、人、过程的一系列操作)\r\n  ? 软件的可靠性

关于软件范围的叙述都应给出定量的数据(例如,同时使用该软件的用户数目,发送表格的长短,最大允许响应时间等等),指明约束条件或限制(例如,产品成本限制了存储的容量)。此外还要叙述某些质量因素(例如,给出的算法是否容易理解、是否使用Ada语言等)。

10.1.3  资源要求

1、人力资源——在考虑各种软件开发资源时,人是最重要的资源。在安排开发活动时必须考虑人员的技术水平、专业、人数、以及在开发过程中各阶段对各种人员的需要(图10.2)。

2、硬件资源——主要包括宿主机Host Machine(软件开发时使用的计算机及外围设备)、目标机Target Machine(运行已开发成功的软件的计算机及外围设备)和其他硬件设备(专用软件开发时需要的特殊硬件资源)。

3、软件资源——即软件工具集,主要有业务系统计划工具集、项目管理工具集、支援工具、分析和设计工具、编程工具、组装和测试工具、原型化和模拟工具、维护工具、框架工具等。

4、软件复用性及软件部件库——为了促成软件的复用,以提高软件的生产率和软件产品的质量,应建立可复用的软件部件库。对于软件的复用,人们经常忽略,但这却是相当重要的一环。

10.1.3  资源要求

通常,软件开发所需的资源,可由“金字塔“型(图10.1).描述。\r\n人   — 人员的技术水平,专业和数量。\r\n工具 — 主要是软、硬件工具。\r\n根据统计结果,在软件开发过程中,不同阶段的人员需求情况如图 10.2,按照Putnam _ Norden 曲线所示。

问  题\r\n    分析在软件开发的不同阶段各类人员的需求情况,为什么?

图 10.1

10.1.3 资源要求

Putnam _ Norden 曲线

10.2 可行性研究

  可行性研究又称为可行性分析,目的是避免盲目投资,减少不必要的损失。即以最小的代价在最短的时间内确定该项目是否可能开发、是否值得。 \r\n  任何软件的开发,都会受到开发时间、经费及开发环境及技术的限制。及早对软件项目的可行性做出细致而谨慎的评估是十分必要的。若在定义阶段及早发现将来开发工作中可能出现的问题,及早地作出决定,可将项目开发的风险降到最低。\r\n  可行性研究的主要内容有:

技术上可行

经济上可行

社会上可行

可行性报告

可行性报告

可行性报告

可行性报告

可行性分析的结果


现有技术、资源及限制能否支持和实现系统的功能、性能。主要是技术风险问题。

进行成本估算及效益评估,确定项目是否值得开发。

主要指系统开发后能否运行,是否存在合同、责任、侵权、用户组织管理等方面的问题。

一、可行性分析的任务

进行可行性分析时,通常用系统流程图来描述所要开发的系统。用于描述项目的处理流程、范围、功能等。

1、系统流程图的基本符号

一、系统流程图

10.2.2 可行性分析的描述手段

10.2.2 可行性分析的描述手段

2、系统流程图举例 — 库存管理系统\r\n功能:\r\n库存零件的种类和数量存放在库存清单主文件中。 ? 随时更新库存文件。 ?当某零件少于库存临界值时,产生订货报告,通知采购部门。

10.2.2 可行性分析的描述手段

二、数据流图\r\n  也可以用DFD图来对系统进行描述。

图10.3

可行性研究报告(参考格式)\r\n一、引言  \r\n   系统名称、目标、功能、开发组织单位,服务对象等。\r\n二、系统开发的背景,必要性和意义\r\n  1、现行系统的调查研究\r\n    组织机构、业务流程、工作负荷、费用、人员、设备、计算机应用情况、存在问题等。\r\n  2、需求调查和分析\r\n    用户提出的需求及考虑经济改革和发展需要进行预测结果。\r\n三、新系统的几种方案介绍\r\n  1、拟建系统目标\r\n  2、系统规模及初步方案(粗略的逻辑模型)\r\n  3、系统的实施方案(计划安排)\r\n  4、投资方案\r\n  5、人员培训及补充方案\r\n  6、其它可供选择的方案

10.2.3 可行性研究报告

10.2.3 可行性研究报告

10.2.2  可行性研究报告(续)

可行性研究报告(参考格式)

可行性研究报告(参考格式)

10.3 成本估算技术

10.3  成本估算技术

成本估算是可行性分析的重要依据,也是软件管理的重要内容,直接影响到软件开发的风险。\r\n软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价,即主要是人的劳动的消耗。因此,软件产品开发成本的计算方法不同于其它物理产品的成本的计算。\r\n软件产品不存在重复制造过程,它的开发成本是以一次性开发过程所花费的代价来计算的。因此软件成本估算,应以软件计划、需求分析、设计、编码到测试的软件开发全过程所花费的代价为依据。\r\n另外,必须注意,对于一个大型项目,由于其项目的复杂度,成本估算并不是一件简单的事,必须建立相应的估算模型,按照一定的方法、技术来进行估算。

10.3.1  影响成本估算的因素

 为了正确进行成本估算,首先要了解影响成本估算的主要因素:\r\n 1、软件人员的业务水平 软件人员的素质、经验、掌握知识的不同,在工作中表现出很大的差异。\r\n 2、软件产品的规模及复杂度\r\n  规模:按YOURDON分类法将软件产品的规模分为超小型,小型,中型,                   大型,超大型,极大型。\r\n  复杂性:应用程序, 实用程序,系统程序分别由低到高排列。\r\n 3、开发所需时间\r\n  显然,开发时间越长成本越高。对确定规模、复杂度的软件存在一个“最佳开发时间”,即是完成项目的最短时间,选取最佳开发时间来计划开发过程,可以取得最佳经济效益。\r\n 4、软件开发技术水平\r\n  指开发方法、工具、语言等,技术水平越高,效率越高。\r\n 5、软件可靠性要求\r\n  一般可靠性要求愈高,成本愈高。

§10.3.1  影响成本估算的因素

微型   可不作严格的系统分析和设计,在开发过程中应用软件工程的方法。\r\n小型 如数值计算或数据处理问题,程序往往是独立的,与其它程序无接口,应按标准化技术开发。\r\n中型 如应用程序及系统程序,存在软件人员之间,软件人员与用户之间的密切联系、协调配合。应严格按照软件工程方法开发。\r\n大型 编译程序、小型分时系统、应用软件包、实时控制系统等。必须采统一标准,严格复审,但由于软件规模庞大,开发过程可能出现不可预知的问题。\r\n甚大型 如远程通信系统、多任务系统、大型操作系统、大型数据库管理系统、军事指挥系统等。子项目间有复杂的接口,若无软件工程方法支持,开发工作不可想象。\r\n极大型 如大型军事指挥系统、弹道防御系统等,这类系统极少见,更加复杂。

规模

表10.1

10.3.2  成本估算模型

二、成本估算模型\r\n  软件成本估算模型可分为两大类:理论模型和统计模型,具体介绍以下模型:\r\n  1、Halstead 理论模型\r\n  2、统计估算模型\r\n  3、构造性成本模型

10.3.2  成本估算模型

一、软件成本估算量\r\n  软件成本估算通常是对以下量进行估算:

源代码行(LOC) \r\n  是指机器指令行/非机器语言的执行步\r\n开发工作量  \r\n  常用的单位是:人-月(PM)  人-年(PY)  人-日(PD) \r\n软件生产率  \r\n  单位劳动量所能完成的软件数量:\r\n  LOC/PM   ¥/LOC   ¥/PM\r\n软件开发时间

10.3.3 Halstead 理论模型\r\n理论模型来源于软件度量学的研究,根据四个原始量进行估算:\r\n  n1:不同运算符个数   n2:不同运算对象个数\r\n  N1:运算符总数       N2:运算对象总数\r\n估算模型:\r\n程序长度      N= n1log2 n1+n2 log2 n2\r\n程序量          V=Nlog2(n1+n2)\r\n程序级别的度量   L=V*/V   (V?V*)\r\n 其中V*为无暇程序的程序量,对特定程序V*为常数。程序级别愈低,程序量愈大。\r\n 由于V*不易计算,可按照以下公式计算:\r\n所花费精力     E=V/L\r\n程序开发时间    T=E/S

10.3.3 Halstead 理论模型

理论模型1

该模型经过实际检验,估算结果是准确的,但由于四个原始量在可行性分析阶段根本无法获得,因此Halstead 理论模型往往并不用于实际成本估算,而是用于验证其它估算模型的准确性。

10.3.3 Halstead 理论模型

ai — 估计的最小行数   \r\nbi — 估计的最大行数 \r\nmi — 最可能的行数

10.3.4 专家估算模型\r\n  即源代码行估算模型(Deiphi技术)\r\n   由Rand公式提出的Deiphi技术,又称为专家估算模型,是由n位专家进行成本估算。每位专家根据系统规格说明书,反复讨论给出ai、 bi及 mi的值,并按照下式反复估算源代码的期望值Li ,期望中值L。

将估算的源代码行数,乘以根据经验推算的每行源代码所需成本,即为该软件的成本。

10.3.4 专家估算模型

10.3.4  专家估算模型

10.3.5 IBM估算模型

10.3.5 IBM 估算模型(静态、单变量模型)\r\n   1977年由Waiston 和 Felix 总结了IBM联合系统分部(FSD)负责的60个项目的数据,利用最小二乘法拟合,得到如下估算公式:\r\n    工 作 量:      E=5.2*L      (PM)\r\n    项目持续时间:  D=4.1*L      (月)\r\n    人员需要量:    S=0.54*E     (人)\r\n    文 档 数:      DOC=49*L     (页)\r\n   其中:L _ 源代码行,以千行计。

IBM估算模型是一种静态单变量模型,它利用已估算的结果,如源代码行,来估算各种资源的需求量.\r\n但IBM 估算模型不是一种通用模型,因此应用中应根据具体实际情况调整模型中的参数.

10.3.5 IBM 估算模型

10.3.6 Putnam 估算模型(动态、多变量模型)

L= Ck K  td

Putnam 估算模型是一种动态多变量模型,是根据一些大型项目中工作量的分布情况(图10.4)而推导出来的.

10.3.6 Putnam 估算模型

其中: L - 源代码行, K - 所需人力(PY), td - 开发时间 ,\r\n      CK -技术水平常数, CK值与开发环境有关。(差:2500-2000,\r\n          正常:10000-8000,好:12500-11000)

10.3.2  成本估算模型

图10.4 大型项目的工作量分布情况

10.3.7 COCOMO模型

10.3.7 COCOMO模型\r\n  COCOMO模型(Constructive Cost Model)由TRW公司开发,是由Boehm提出的结构型成本估算模型,其特点是精确、易用。\r\n 是一种层次模型,按照其祥细程度分为三级:即基本的COCOMO模型、中间的COCOMO模型和详细的COCOMO模型。

该模型主要对工作量MM(单位:PM)和进度TDEP(单位:月)进行估算。模型中考虑到估算量与开发环境有关,将开发项目分为三类:

组织型(Organic)\r\n  规模不大(<5万),较简单,开发人员对产品目标理解充分,经验丰富,对软件开发环境熟悉。大多数应用软件及老的操作系统、编译系统属此类。< p="">

嵌入型(Embadded)\r\n  软件、硬件的关系紧密,操作有限制条件,对接口、数据结构,算法要求较高。如大型复杂的事务处理系统,大型、超大型的操作系统,军事指挥系统,航天控制系统等。

半独立型(Semidetached)\r\n  对项目要求界于上述两者之间,规模复杂度中等。如新操作系统,大型数据库,生产控制等软件属此类。

10.3.7 COCOMO模型

MM=

① 基本的COCOMO模型(静态单变量模型)

其中: MM — 工作量(PM),KLOC — 估计的源代码行\r\n       Cl —模型系数,? —模型指数\r\n       Cl、 ? 取决于开发项目的模式为组织型、半独立型或嵌入型。

10.3.7 COCOMO模型

① 基本的COCOMO模型

  下表是根据63个项目的数据统计结果,按照基本的COCOMO模型估算的工作量和进度。

表10.2

其中: fi — 成本因素包括:\r\n生产因素(可靠性,数据库规模,软件复杂度)\r\n计算机因素(时间约束,存储约束,环境变更率,计算机换向时间)\r\n人员因素(系统分析员能力、经验,程序员能力,开发人员环境知识,程序时间语言知识)\r\n项目工程因素(设计技术,软件工具,进度限制约束)

③ 详细的COCOMO模型\r\n  在考虑成本因素fi时,按照开发阶段分别给出更加详细的值。

MM=

② 中间的COCOMO模型\r\n  进一步考虑了15种影响软件工作量的因素,更加合理的估算软件工作量和进度。

② 中间的COCOMO模型

10.3.7 COCOMO模型

10.3.8  成本估算方法

1、自顶向下的估算方法\r\n 从项目的整体出发,进行类推。即据以前完成的同类项目的总成本,推算当前项目的总成本,再将其分配到各开发任务中。\r\n 特点:简便、估算工作量小、误差大。\r\n2、自底向上的估计法\r\n 把待开发的软件细分,直到每一子任务都已经明确所需要的开发工作量,然后把它们累加起来。\r\n 特点:精确度高、但缺少子任务(模块)间的联系。\r\n3、差别估计法\r\n 综合上述两种方法而得,将项目与已经完成的项目进行类比,相同部分按照已经完成的项目估算,不同部分另行估算。\r\n 特点:估算较精确、但区分类比较困难。

10.3.8 成本估算方法

对于大型软件项目来说,由于项目的复杂型,成本估算并不单纯是一个计算过程,还需要进行一系列的估算处理,处理手段主要是分解和类比。一般有以下方式:

注意:在对实际项目进行估算时,通常使用综合方法。

10.3.9  成本/效益分析

成本/效益分析的第一步是估算成本和运行费用(系统的操作费用和维护费用),系统的经济效益则等于因使用新系统而增加的收入,加上使用新系统可以节省的运行费用。\r\n  1、货币的时间价值\r\n  通常以利率形式表示。假设,年利率为i,P元钱在n年后的价值F为:\r\n\r\n 2、投资回收期\r\n  投资回收期即工程累计经济效益等于最初投资所需要的时间。  \r\n  3、纯收入\r\n  在整个生存周期内新系统的累计经济效益与投资之差称为纯收入。\r\n  4、投资回收率\r\n  用于衡量投资效益的大小,并且可以用它和年利率比较,。设现在的投资额为P: \r\n       P=F1 /(1 j)+F2 /(1 j)2 +…+Fn /(1 j)n\r\n其中:Fi是第i年年底的效益(i=1,2,3,…n); \r\n   n是系统的使用寿命;j是投资回收率。

10.3.9 成本/效益分析

10.4 软件项目的组织与计划

10.4 软件项目的组织与计划

  软件项目的组织管理,需要多方面的综合知识,涉及到系统工程、统计学、心理学、社会学、经济学、乃至法律等方面的问题。尤其涉及到社会因素、精神因素、人的因素,比技术问题要复杂得多。\r\n  软件项目的管理,也不能完全照搬外国的经验,还必须结合我国的实际情况,结合我们的工作条件、人员和社会环境等多种因素考虑。\r\n  此外,实践是取得管理经验的重要途径。很显然,管理能够取得效率,能够赢得时间,是软件能够开发成功的关键。  

10.4.1 软件项目管理的特点

软件产品与其他任何产业的产品不同,它是非物质性的产品,是知识密集型的逻辑思维产品。由于软件的这种独特性,使软件项目管理过程更加复杂和难以控制。\r\n  软件项目管理的主要特点是:\r\n   1、软件项目管理涉及的范围广,涉及到软件开发进度计划、人员配置与组织、项目跟踪与控制等。  \r\n   2、应用到多方面的综合知识,特别是要涉及到社会的因素、精神的因素、认知的因素,这比技术问题复杂得多。\r\n   3、人员配备情况复杂多变,组织管理难度大。\r\n   4、管理技术的基础是实践,为取得管理技术成果必须反复实践。

10.4.1  软件项目管理的特点

10.4.2  软件开发进度计划

10.4.2 软件开发进度计划

  软件开发进度计划安排是一件困难的任务,既要考虑各个子任务之间的相互联系,尽可能并行地安排任务,又要预见潜在的问题,提供意外事件的处理意见。

描述计划进度的主要工具有:一般的表格工具、甘特图、PERT技术与CPM方法。

1、一般的表格工具\r\n    例如:进度表


2、甘特图(Gantt Chart)\r\n   用水平线段表示任务的工作阶段;线段的起点和终点分别表示任务的开始和完成时间,线段的长度表示完成任务所需的时间。图10.6给出了具有五个任务的甘特图。


优点:标明了各任务的计划进度和当前进度。能够动态反映软件开发的进展情况。\r\n缺点:不能够反映多个任务之间的复杂逻辑关系。

3、时标网状图(timescalar network)\r\n   也称为改进的Gantt图,增加了各子任务之间的逻辑依赖关系。如图10.7所示;表示A、B、C、D、E5个任务之间在进度上的依赖关系。例如E2的开始取决于A3的完成。虚箭头表示虚任务。