对软件项目管理的探讨 8500字

对软件项目管理的探讨8500字一、引言

随着信息技术的飞速开展，软件产品的规模也越来越庞大，个人单打独斗的作坊式开发方式已经越来越不适应开展的需要.各软件企业都在积极将软件工程管理引入开发活动中，对开发实行有效的管理.我公司是西安一家中型软件企业，在公司中已经实行了工程管理制度，软件工程管理是整个工程管理中的一个重要组成局部.

从概念上讲，软件工程管理是为了使软件工程能够按照预定的本钱、进度、质量顺利完成，而对本钱、人员、进度、质量、风险等进行分析和管理的活动.实际上，软件工程管理的意义不仅仅如此，进行软件工程管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，说明这个企业的软件生产越趋向于成熟，企业越能够稳定开展(即减小开发风险).

软件开发不同于其他产品的制造，软件的整个过程都是设计过程(没有制造过程);另外，软件开发不需要使用大量的物质资源，而主要是人力资源;并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果.基于上述特点，软件工程管理与其他工程管理相比，有很大的独特性.

二、软件工程管理的组织模式

软件工程可以是一个独自的开发工程，也可以与产品工程组成一个完整的软件产品工程.如果是订单开发，那么成立软件工程组即可;如果是产品开发，需成立软件工程组和产品工程(负责市场调研和销售)，组成软件产品工程组.

公司实行工程管理时，首先要成立工程管理委员会，工程管理委员会下设工程管理小组、工程评审小组和软件产品工程组.

1、工程管理委员会

工程管理委员会是公司工程管理的最高决策机构，一般由公司总经理、副总经理组成.主要职责如下：

(1)依照工程管理相关制度，管理工程;

(2)监督工程管理相关制度的执行;

(3)对工程立项、工程吊销进行决策;

(4)任命工程管理小组组长、工程评审委员会主任、工程组组长.

2、工程管理小组

工程管理小组对工程管理委员会负责，一般由公司管理人员组成.主要职责如下：

(1)草拟工程管理的各项制度;

(2)组织工程阶段评审;

(3)保留工程过程中的相关文件和数据;

(4)为优化工程管理提出倡议.

3、工程评审小组

工程评审小组对工程管理委员会负责，可下设开发评审小组和产品评审小组，一般由公司技术专家和市场专家组成.主要职责如下：

(1)对工程可行性报告进行评审;

(2)对市场方案和阶段报告进行评审;

(3)对开发方案和阶段报告进行评审;

(4)工程结束时，对工程总结报告进行评审.

4、软件产品工程组

软件产品工程组对工程管理委员会负责，可下设软件工程组和产品工程组.软件工程组和产品工程组分别设开发经理和产品经理.成员一般由公司技术人员和市场人员构成.主要职责是：根据工程管理委员会的安顿具体负责工程的软件开发和市场调研及销售工作.

三、软件工程管理的内容

从软件项目的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段.不管是作坊式开发，还是团队协作开发，这六个阶段都是不可短少的.

根据公司实际情况，公司在进行软件工程管理时，重点将软件配置管理、软件质量管理、软件风险管理及开发人员管理四方面内容导入软件开发的整个阶段.

在八十年代初，驰名软件项目专家B.W.Boehm总结出了软件开发时需遵循的七条根本原那么，同样，我们在进行软件工程管理时，也应该遵循这七条原那么.它们是：

(1)用分阶段的生命周期方案严格管理;

(2)坚持进行阶段评审;

(3)实行严格的产品控制;

(4)采用现代程序设计技术;

(5)结果应能够分明地审查;

(6)开发小组地人员应该少而精;

(7)成认不断改良软件项目实践地必要性.

四、编写?软件工程方案书》

工程组成立的第一件事是编写?软件工程方案书》，在方案书中描述开发日程安顿、资源需求、工程管理等各项情况的大体内容.方案书主要向公司各相关人员发放，使他们大体了解该软件工程的情况.对于方案书的每个内容，都应有相应具体实施手册，这些手册是供工程组相关成员使用的.

?软件工程方案书》一般应该包括下述内容：

1.引言

1.1方案的目的

1.2工程的范围和目标

1.2.1范围描述

1.2.2主要功能

1.2.3性能

1.2.4管理和技术约束

2.工程估算

2.1使用的历史数据

2.2使用的评估技术

2.3工作量、本钱、时间估算

3.风险管理战略

3.1风险辨认

3.2有关风险的讨论

3.3风险管理方案

3.3.1风险方案

3.3.2风险监视

3.3.3风险管理

4.日程

4.1工程工作分解结构

4.2时限图(甘特图)

4.3资源表

5.工程资源

5.1人员

5.2硬件和软件

5.3特别资源

6.人员组织

6.1组织结构

6.2管理报告

7.跟踪和控制机制

7.1质量保证和控制

7.2变化管理和控制

8.附录

五、软件配置管理

是否进行配置管理与软件的规模有关，软件的规模越大，配置管理就显得越重要.软件配置管理简称SCM(SoftwareConfigurationManagement的缩写)，是在团队开发中，标识、控制和管理软件变更的一种管理.配置管理的使用取决于工程规模和复杂性以及风险水平.

1、目前软件开发中面临的问题

.在有限的时间、资金内，要满足不断增长的软件产品质量要求;

.开发的环境日益复杂，代码共享日益困难，需跨越的平台增多;

.程序的规模越来越大;

.软件的重用性需要提高;

.软件的维护越来越困难.

2、软件配置管理应提供的功能

在ISO9000.3中，对配置管理系统的功能作了如下描述：

.唯一地标识每个软件项的版本;

.标识共同构成一完整产品的特定版本的每一软件项的版本;

.控制由两个或多个独立工作的人员同时对一给定软件项的更新;

.控制由两个或多个独立工作的人员同时对一给定软件项的更新;

.按要求在一个或多个位置对复杂产品的更新进行协调;

.标识并跟踪所有的措施和更改;这些措施和更改是在从开始直到放行期间，由于更改请求或问题引起的.

3、版本管理

软件配置管理分为版本管理、问题跟踪和建立管理三个局部，其中版本管理是根底.版本管理应完成下列主要任务：

.建立工程;

.重构任何修订版的某一项或某一文件;

.利用加锁技术避免覆盖;

.当增加一个修订版时要求输入变更描述;

.提供比拟任意两个修订版的使用工具;

.采用增量存储方式;

.提供对修订版历史和锁定状态的报告功能;

.提供归并功能;

.允许在任何时候重构任何版本;

.权限的设置;

.晋升模型的建立;

.提供各种报告.

4、配置管理软件PVCS6.0

PVCS6.0是一套非常优秀的配置管理软件，它能够实现配置管理中的各项要求，并且能和多种流行开发平台集成，为配置管理提供了很大的方便.

六、软件质量管理

随着软件开发的规模越来越大，软件的质量问题显得越来越突出.软件质量的控制不单单是一个软件测试问题，在软件开发的所有阶段都应该引入质量管理.我公司除加强了国家规范"信息技术软件生存期过程"(GB/T8566--1995)的标准管理外，还积极为通过ISO9000.3做准备.

1、软件质量保证方案

在进行软件开发前，需要有一个?软件质量保证方案》.目前较常用的是ANSI/IEEESTOL

730--1984，983--1986规范，包括下列内容：

1.方案目的

2.参考文献

3.管理

3.1.组织

3.2.任务

3.3.责任

4.文档

4.1.目的

4.2.要求的软件项目文档

4.3.其他文档

5.规范和约定

5.1.目的

5.2.约定

6.评审和审计

6.1.目的

6.2.评审要求

6.2.1.软件需求的评审

6.2.2.设计评审

6.2.3.软件验证和确认评审

6.2.4.功能评审

6.2.5.物理评审

6.2.6.内部过程评审

6.2.7.管理评审

7.测试

8.问题报告和改过活动

9.工具、技术和办法

10.媒体控制

11.供给者控制

12.记录、收集、维护和保密

13.培训

14.风险管理

2、质量管理的根本原那么

.控制所有过程的质量;

.过程控制的出发点是预防不合格;

.质量管理的中心任务是建立并实施文件化的质量体系;

.持续的质量改良;

.有效的质量体系应满足顾客和组织内部双方的需要和利益;

.定期评价质量体系;

.搞好质量管理关键在于领导.

3、软件质量因素

正确性：系统满足规格表明和用户目标的程度，即，在预定环境下能正确地完成预期功能的程度.

健壮性：在硬件发生故障、输入的数据无效或操作错误等意外环

境下，系统能做出适当响应的程度.

效率：为了完成预定的功能，系统需要的计算资源的多少.

完整性(平安性)：对未经授权的人使用软件或数据的企图，系统能过控制(禁止)的程度.

可用性：系统在完成预定应该完成的功能时另人称心的程度.

风险：按预定的本钱和进度把系统开发出来，并且为用户所称心的概率.

可理解性：理解和使用该系统的容易程度.

可维修性：诊断和改过在运行现场发现的错误所需要的工作量的大小.

灵活性(适应性)：修改或改良正在运行的系统需要的工作量的多少.

可测试性：软件容易测试的程度.

可移植性：把程序从一种硬件配置和(或)软件系统环境转移到另一种配置和环境时，需要的工作量多少.有一种定量度量的办法是：用原来程序设计和调试的本钱除移植时需用的费用.

可再用性：再其他应用中该程序可以被再次使用的程度(或范围).

互运行性：把该系统和另一个系统结合起来需要的工作量的多少.

4、软件评审

软件评审并不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审.因为在软件开发的各个阶段都可能产生错误，如果这些错误不及时发现并纠正，会不断地扩大，最后可能导致开

发的失败.下面这组数据可以分明的看出前期的错误对后期的影响.

软件评审是相当重要的工作，也是目前国内开发最不重视的工作.

(1)评审目标

.发现任何形式表现的软件功能、逻辑或实现方面的错误;

.通过评审验证软件的需求;

.保证软件按预先定义的规范表示;

.已获得的软件是以统一的方式开发的;

.使工程更容易管理.

(2)评审过程

A、召开评审会议：一般应有3至5人加入，会前每个加入者做好准备，评审会每次一般不超过2小时.

B、会议结束使必须做出下列决策之一：接受该产品，不需做修改;由于错误严重，拒绝接受;暂时接受该产品.

C、评审报告与记录;所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审简要报告.

(3)评审准那么

.评审产品，而不是评审设计者(不能使设计者有任何压力);

.会场要有良好的氛围;

.建立议事日程并维持它(会议不能脱离主题);

.限制争论与反驳(评审会不是为了解决问题，而是为了发现问题;

.指明问题范围，而不是解决提到的问题;

.展示记录(最好有黑板，将问题随时写在黑板上);

.限制会议人数和坚持会前准备工作;

.对每个被评审的产品要尽力评审清单(帮忙评审人员思考);

.对每个正式技术评审分配资源和时间进度表;

.对全部评审人员进行必要的培训;

.及早地对自己地评审做评审(对评审准那么的评审).

5、ISO9000.3软件质量认证体系

ISO9000.3是ISO9000质量体系认证中关于计算机软件质量管理和质量保证规范局部.它从管理职责、质量体系、合同评审、设计控制、文件和资料控制、采购、顾客提供产品的控制、产品标识和可追溯性、过程控制、检验和试验、检验/测量和试验设备的控制、检验和试验状态、不合格品的控制、纠正和预防措施、搬运/贮存/包装/防护和交付、质量记录的控制、内部质量审核、培训、效劳、统计系统等二个方面对软件质量进行了要求.

6、测试

软件测试是软件开发的一个重要环节，同时也是软件质量保证的一个重要环节.所谓测试就是用已知的输入在已知环境中动态地执行系统(或系统的部件).测试一般包括单元测试、模块测试、集成测试和系统测试.如果测试结果与预期结果不一致，那么很可能是发现了系统中的错误，测试过程中将产生下述根本文档：

(1)测试方案：确定测试范围、办法、和需要的资源等.

(2)测试过程：详细描述和每个测试计划有关的测试步骤和数据(包括测试数据及预期的结果).

(3)测试结果：把每次测试运行的结果归入文档，如果运行出错，那么应产生问题报告，并且必须经过调试解决所发现的问题.测试结果：把每次测试运行的结果归入文档，如果运行出错，那么应产生问题报告，并且必须经过调试解决所发现的问题.

七、软件风险管理

软件工程管理存在着风险，如果我们提前重视风险，并且有所防备，就可以最大限度减少风险的发生.进行风险管理是有效的伎俩.

1、风险的分类

根据风险内容，我们可以将风险分为工程风险(本钱提高，时间延长等)、技术风险(技术不成熟等)、商业风险(销售问题等)、战略风险(公司的经营战略发生了变化)、管理风险(公司管理人员是否成熟等)、预算风险(预算是否准确等)等.

另外，我们还可以将风险分为已知风险(如员工离职等)、可预报风险(从以往经验得出可能有风险的)和不可预知风险.

2、风险的辨认

风险辨认的有效办法是建立风险工程检查表.主要波及下列几方面检查：

.产品规模风险检查

.业务影响风险检查

.与客户相关的风险检查

.过程风险检查

.技术风险检查

.开发环境风险检查

.与人员的模式和经验有关的风险检查

3、风险评估

风险评估主要从下面七个方面进行：

.发生的可能性

.发生的结果(影响)

.建立一个尺度表示风险可能性(如，极罕见、罕见、普通、可能、极可能)

.描述风险带来的后果

.估计对产品和工程的影响

.确定风险评估的正确性

.根据影响排定有限队列

另外，要对每个风险的表现、范围、时间做出尽量准确的判断.

4、风险的评价

对风险的评价主要依据三个因素：风险描述、风险概率和风险影响.从本钱、进度及性能三个方面对风险进行评价.确定工程的中止点，在中止点出再一次进行风险评价.

5、风险的驾驭和监控

风险的驾驭与监控主要要靠管理者的经验来实施.如，某开发人员的离职概率是0.7，离职后会对工程造成一定的影响，那么该风险驾驭和监控的策略如下：

.与在职人员协商，确定流动原因.

.在工程开始前，把环节这些流动原因的