 软件的社会角色

第一讲 概述

第一讲 概述

主要内容 主要内容

 _{软件的社会角色}

 _{计算机和软件的历史观}

 _{什么是软件}

 _软件危机

 _{项目的概念}

 _{项目管理基本概念}



软件项目特征



软件项目面临的问题

1. 1. 软件的角色 软件的角色

 软件在社会上扮演了双重角色

 它本身是一种产品

 将计算机硬件的计算能力发挥出来

 同时，它也是一种传递产品的工具

 软件传递了我们这个时代最重要的产品：

信息

2. 2. 计算机和软件的历史观 计算机和软件的历史观

 70 年代和 80 年代

 “ 新的工业革命”

 “ 工业社会将转变为信息社会”

 ……

 _{90 年代}

 “ 知识的民主化将改变旧的权力结构”

 _{21 世纪初}

 “Y2K 定时炸弹”

 “ 无所不在的计算”

3. 3. 什么是软件 什么是软件

 指令：使计算机提供功能和性能

 数据结构：使程序能够操纵信息

 文档：记录程序的产生，功能与使用

软件特征（

软件特征（ 1 1 ） ）

 最根本的：软件是一种逻辑元素而不是物理元素

 软件是开发出来的，而不是用传统的方法制造出来的

 _{软件不会被用坏}

失败概率 一般产品的浴盆曲线

软件特征（

软件特征（ 2 2 ） ）

失败

概率 软件失败概率

实际曲线

软件失败概 率理想曲线

软件特征（

软件特征（ 3 3 ） ）

 工业界已经走向了标准化装配时代，然而绝大多 数软件还是定制出来的。

 科学计算函数库（ 60 年代）

 重用数据结构

 重用组件

软件分类 软件分类

 _系统软件

 _实时软件

 _商务软件

 _{工程和科学软件}

 _{嵌入式软件}

 _{个人计算机软件}

 _{基于 Web 的软件}

 _{人工智能软件}

4. 4. 软件危机 软件危机

 “ 软件危机” 是 1958 年在 NATO 会议上作为一个 正式的议题被提出来

 软件项目不成功的例子比比即是：

 1999 年 10 月，耗资 1.25 亿美元的 NASA 的火 星气象卫星失踪，据信这是由于简单的数据转换错误 所导致的。人们发现卫星软件中，有些数据使用英制

，它们应被转换成公制。这个卫星应当充当另一项任 务中的火星极地着陆项目的通信转发器，那个任务也 失败了，原因不明。

软件危机 软件危机

 美国 IBM 公司在 1963 年至 1966 年开发的 IBM360 机的操作系统。

这一项目花了 5000 人一年的工作量，最多时有 1000 人投入开发 工作，写出了近 100 万行源程序。 ... 据统计，这个操作系统每次 发行的新版本都是从前一版本中找出 1000 个程序错误而修正的结 果。 ...

这个项目的负责人 F. D. Brooks 事后总结了他在组织开发过程中的 沉痛教训时说：“ ... 正像一只逃亡的野兽落到泥潭中做垂死的挣扎

，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。 ... 程序设计 工作正像这样一个泥潭， ... 一批批程序员被迫在泥潭中拼命挣 扎， ... 谁也没有料到问题竟会陷入这样的困境 ...” 。 IBM360

软件危机 软件危机

 1999 年 8 月，在一个大型的商业高速数据网络里，软 件的缺陷影响了 70000 个商业用户，时间长达八天。

在受到影响的客户中，有美国最大的远期交易电子贸易 系统，该系统中断服务长达一周

 1998 年 4 月，美国的一个重要的数据通讯网络出现了 长达 24 小时的故障，使大部分美国的信用卡管理系统 交易受到影响。受到影响的还一些大银行、零售商、和 政府的数据系统。最后查出也是软件故障所致。

软件危机 软件危机

 据报道， 1997 年 8 月，美国一家最主要的消费信用 卡报告公司的新网站刚开启两天，就因为软件问题而关 闭了。这个新站点允许浏览者直接访问，只收取很少的 费用就可以查询自己的信用卡使用情况。但是，最初的 用户所看到的是别人的账单，而不是他们自己的。发怒 的顾客使这件事流传全国。最后问题被归结为：“ … 未 曾预料到的大量的客户需求，再加上导致把文件送到错 误的计算机的软件毛病。”

 美国航空公司失败的机票预订系统 CONFIRM

 美国机动车协会新泽西分部的 4GL 灾难；



软件危机 软件危机

 _{一些数据：}

 大约 70 ％的软件开发项目超出了估算的时间，大型 项目平均超出计划交付时间 20 ％到 50 ％， 90 ％以 上的软件项目开发费用超出预算，并且项目越大，超 出项目计划的程度越高

 美国政府审计局：只有不到 2 ％的合同定购软件在发 布时具有可用性—— 98 ％以上的项目都失败了

软件危机 软件危机

 _相关术语

 “ 两难境地（ Crunch Mode ）”：处于两难境地的项目 面临着无法达到最初目标的威胁（费用、进度表、功 能性等等），而项目团队在努力想要跨越该困境。

 “ 我们正处于两难境地，在半夜之前是不会回家的”

 “ 死亡行军（ Death March ）”：用来描述其进度表几 乎不可能完成的项目。

软件危机 软件危机

 _{软件危机的另一种看法}

 “ 人类只能够在第二级追求中获得成功，比如说，成 为百万富翁或者总理，赢得战争，飞跃同温层或者登 陆月球。第一级追求，不可避免地要涉及到努力去理 解生命的意义以及努力去转化这种理解，这就不可避 免地会导致失败感的产生。拿破仑、邱吉尔、罗斯福 式的人物可以感受自己的成功感，但苏格拉底式的人 物永远不会有这种感觉。对生命意义的理解永远是遥 不可及的事情。”——美国播音员 Malcolm Muggeridg e

软件危机 软件危机

 软件项目超出费用和进度表目标普遍存在的原因 是：目标本身完全是错误的。

 为什么有那么多人喊着软件危机呢？因为有利可 图：

 某些经销商叫喊危机是为了卖出他们声称能够提供对 策的产品或者服务；某些研究者叫喊危机是为了获得 他们声称同样将提供对策的研究项目的经费；某些学 术界人士叫喊危机是为了促使人们接受并阅读他们提 出对策的专业论文。——《 software runaways 》

软件危机 软件危机

 更准确的说法：慢性痛苦（ chronic affliction)

 尽管忍受痛苦，但是软件依然在我们这个世界起 着越来越重要的作用，但是如果能够医治痛苦，

那么软件业将发展得更加健康。

 如何医治这种软件业的慢性痛苦？

5. 5. 什么是项目 什么是项目

 _{项目是什么}

 没有例行的任务

 需要计划

 特定的目标需要满足或者特定的产品需要生成

 项目有一个预定义的时间范围

 工作不仅仅是为自己，也是为他人

 工作中有些特性

 工作分为若干阶段

练习 练习

 考虑下面事情哪些更像一个项目

 出版一份报纸

 结婚

 为金融部门的计算机系统处理 2000 年问题

 对什么是好的人机接口形式的研究

 对用户使用计算机系统出现问题的调查

 为一个新计算机写一个操作系统

 为一个机构安装新的 Word 版本

 造一个跨海隧道

什么是项目管理 什么是项目管理

 项目管理是在项目活动中应用知识，技能，工具 和技术来满足项目需求的过程，它通过初始化，

计划，执行，控制和结束等活动来完成。

项目管理的发展 项目管理的发展

 _{项目管理的发展}

 50 年代后期发展起来的一种计划管理方法，它主要 从开始生产大型、高费用、进度要求严的复杂系统的 需要中发展起来的

 在 60 年代只有航空、航天、国防和建筑工业才愿意 采用项目管理

 70 年代项目管理在新产品开发领域中扩展到了复杂 性略低、变化迅速、环境比较稳定的中型企业中

 80 年代开始，项目管理已经被公认为是一种有生命 力并能实现复杂的企业目标的良好方法

项目管理框架 项目管理框架

Scope Mgt.

Time Mgt.

Cost Mgt.

Quality Mgt.

HR Mgt. Comm Mgt.

Risk Mgt.

Procure Mgt.

Success Stakeholders’

needs and expectations

Tools and techniques 9 Knowledge Areas

Core Functions

Project Integration Management

Facilitating Functions

项目管理涉及的知识

项目管理涉及的知识

项目阶段 项目阶段

 _项目阶段

 每一个项目阶段的标记是一个或几个可交付的物件

（ deliverable ）。 Deliverable 是一个具体的可验证 的工作产品，如可行性研究，详细设计或者一个工作 原型。

 项目阶段的结束是由关键交付物或者项目性能作标记 的，以确定项目是否能够继续进行下一阶段或者检测 和修正错误。阶段结束的检查经常被称为 phase exits, stage gates, kill points.

项目生命周期 项目生命周期

 项目生命周期定义了一个项目的开始与结束。

 项目生命周期定义的阶段顺序通常包括某些技术 转移或“握手” (hand off) ，如从需求到设计，从 构造到运行，但是在风险允许下，也可以下一阶 段提前进行，这种重叠的阶段被称为快速跟踪 (f

。

 项目生命周期通常定义：

 各个阶段需要完成的技术工作；

项目生命周期 项目生命周期

 绝大多数项目生命周期有一些共同的特点，如成 本和人员消耗的变化曲线。

 项目生命周期与产品生命周期是不同的。

项目生命周期

项目生命周期

软件项目 软件项目

 _特征：



不可见



复杂性（以每一单位货币来看）



灵活性：软件去适应人或组织而不是相反

IT IT 软件项目管理技术的发展 软件项目管理技术的发展

 _{软件项目管理的发展}

 软件项目管理最早源于 70 年代中期。当时美国国防部曾立题专 门研究软件项目做不好的原因，发现 70% 的项目是由于管理不 善引起的，而并不是因为技术实力不够，进而得出一个结论，即 管理是影响软件研发项目全局的因素，而技术只影响局部。

 到了 90 年代中期，软件项目管理不善的问题仍然存在。据美国 软件工程实施现状的调查，软件研发的情况仍然很难预测，大约 只有 10% 的项目能够在预定的费用和进度下交付。

 目前，软件项目管理许多技术还很不成熟。但一些大型软件公司 多采用一定的标准规范如 CMM 和 ISO 9000 ，以及一些软件项 目管理辅助工具进行软件项目管理，并取得了较好的效果。

软件项目包含的活动 软件项目包含的活动

 _需求分析

 _描述

 _设计

 _编码

 _校验

 _安装

 _维护

 _支持

练习 练习

 某一学院原来属于政府管辖，现在独立办学，但 是工资单仍然由政府的计算机中心生成，而政府 对这一服务进行收费。因而学校考虑是否自行采 用一个现成的系统来管理这些数据。该项目包含 哪些阶段？

 项目评估，计划，需求描述，设计 / 编码，验证

软件项目分类 软件项目分类

 _{按软件类别}

 信息系统：与组织接口

 嵌入式系统：接口是机器

 操作系统是一个信息系统还是嵌入式系统？ 嵌入式系统

 有些项目是为了生成某一产品，而某些项目的进 行是为了达到某些目标。许多软件项目分为两个 阶段，第一阶段是目标驱动，第二阶段再生成真 正的软件产品。

 学院所需要的独立的工资系统是一个目标驱动的项目 还是一个产品驱动的项目？

从系统的角度看软件项目 从系统的角度看软件项目

 一个项目关注于生成一个系统和 / 或将一个旧系 统转换为一个新系统

 _{系统，子系统和环境}

 确定学院工资系统的子系统，工资系统的环境中的重 要实体是什么？

工资系统 工资系统

 _{环境中主要实体}

 税务部门

 养老金

 通过 EDI 支付的银行

 工会

 软件供应商

 硬件供应商

 其它办公设备供应商

 外部审计

 学院管理人员

 站点管理人员

从系统的角度看软件项目 从系统的角度看软件项目

 _{开放和封闭系统}

 项目失败的一个原因是技术人员不能够开放系统和立 即接受外界的变化。

 _部分优化

 例如：可能很高效，但是难于修改

 _{社会技术系统}

 软件项目属于此类

软件项目目标 软件项目目标

 _{目标：项目的目标必须}清晰定义，以确定成功的关键。

每一个项目必须有一个项目权威（ authority ） , 该权威 经常被称为项目指导委员会 (steering committee), 项目 的目标必须由指导委员会确定。

 效率的测量：有效的目标必须易于测量，从而更能够衡 量是否成功。如“减少客户抱怨 50 ％”将比“改善客户关 系”更容易测量。

 _子目标：

 识别工资系统的目标和子目标，检验成功的标准是什么？

在 4 月 1 日前实施工资处理系统，实现系统所需要的功能，在一定的成

项目中的人员 项目中的人员

 项目影响者 (stakeholders)

 项目小组内部：

 项目小组外部，但是在同一组织内：

 项目小组和组织外部：如客户

 不同的项目影响者有不同的目标，因而项目领导 者需要能够协调这些目标。 Boehm 和 Ross 提出 软件项目管理的“ W 理论”，该理论关注于所有各 方都能从项目种获益因而对项目的成功都有兴趣。

（ W 代表 Everyone a Winner ）

 练习：识别工资系统的项目影响者

 _{主要的项目涉及者如下}

 财务部门

 人力部门：提供绝大多数雇员细节

 部门经理：提供兼职人员的工作时间细节

 职员：他们关系工资是否正确

 办公室管理：办公室可能需要调整

 软件和硬件供应商

 可能遗忘的人员是：当地政府相关人员，因为如

果得到他们的帮助可能有助于新系统的开发，甚

组织内的信息与控制 组织内的信息与控制

 递阶信息与控制系统

 小的项目中，项目领导将与小组成员紧密合作，甚至可能承担一 些非管理的事务，因而他可以对项目的情况非常了解，当项目规 模变大后，总领导就不可能对工作的所有方面有直接的接触了。

 _{决策与信息的层次}

 策略层：确定目标，例如在工资系统项目中，决定使用自行管理 的系统就是策略层。

 战术层：保证项目目标的实现。

 操作层：确定每天的任务 (day-to-day work)

 _{信息的不同类别}

 _度量：

 性能度量：对实际系统的度量

 预测度量：对还未开发出来的系统的度量

递阶组织结构

递阶组织结构

项目经理面临的挑战 项目经理面临的挑战

 _{从项目经理的观点看：}

 估计和计划

 缺少质量标准和度量

 缺少组织决策的指南

 缺少使进度可视化的技术

 角色定义

 不正确的成功准则

 缺少标准

项目成员面临的挑战 项目成员面临的挑战

 _{从项目成员观点看：}

 工作的不正确的描述

 IT 的管理失误

 缺少应用领域的知识

 缺少及时的文档

 前续任务没有及时完成——包括设备没有及时提供

 用户与技术员之间缺乏交流

 缺少质量控制

 软件环境的改变

软件项目常见错误 软件项目常见错误

 _{选自《快速软件开发》}

 _{产品相关的错误}

 需求镀金：项目具有比实际需求多得多的性能

 功能蔓延：项目平均会有 25% 的需求变更（ Jones 1 994 ）

 开发人员的镀金：开发人员着迷于新技术

 又推又拉的交易：经理在批准项目进度顺延时又加入 了新的功能

 研究导向的开发

软件项目常见错误 软件项目常见错误

 _过程

 缺乏计划

 过于乐观的计划

 在压力下放弃计划

 缺乏足够的风险管理

 承包人导致的失败

 在模糊的项目前期（ fuzzy frond end ）浪费时间

 前期活动不合要求

软件项目常见错误 软件项目常见错误

 设计低劣

 缺少质量保证措施

 缺少管理控制

 太早和过于频繁的集成

 项目估算时遗漏必要的任务

 追赶计划

 鲁莽编码

软件项目常见错误 软件项目常见错误

 _{技术相关的错误}

 银弹综合症 : 过于相信以前没有采用过的技术的宣传

 过高估计了新技术或方法带来的节省量

 项目中间切换工具

 缺少自动的源代码控制手段

软件项目常见错误 软件项目常见错误

 _{人员相关的错误}

 挫伤积极性

 人员素质低

 对有问题的员工失控

 英雄主义

 项目后期加入人员：“火上加油”

 办公环境差

 开发人员与客户之间发生摩擦

 不现实的预期

软件项目常见错误 软件项目常见错误

 缺乏有效的高层对项目的支持

 缺乏各种角色的齐心协力

 缺乏用户介入

 政治高于物质

 充满想像：“项目组没人真正相信他们能够按给定的计 划进度完成项目，但他们认为如果每个人能够努力工 作，并且不出现问题，他们可能会很幸运地按时完成 任务。

软件项目常见的错误 软件项目常见的错误



一天，一位年青人被选来“写”一个用在自动化 制造设备上的程序。选择他的理由很简单：他是 技术小组中唯一参加过编程培训的人。他懂得汇 编语言和 Fortran 语言，但是他不知道软件工程

，更不知道软件计划和跟踪方面的知识。

软件项目常见的错误 软件项目常见的错误

他的老板给了他一些手册和对系统功能的口头描述。他 被告知系统必须在两个月内开发完成。

他读了手册，考虑了他的方法，然后开始编程，两个星 期后，老板把他叫到了办公室并问他事情干得怎么样？

“ 很好”， 雄心勃勃的年青的工程师说，“比我想像的要简 单的多。我已经接近完成 75 ％了。”

老板笑了，“真不可思议”， 然后他告诉这个年青人继续 好好干，在下个星期他将再次会见他。

软件项目常见的错误 软件项目常见的错误

一个星期后，老板把年青人叫到了办公室，问“我们的进 展如何？”

“ 很顺利”，年青人说“但是我遇到了一些小难题，我将解 决它们并且很快就能保持进度”

“ 那么，最终日期能保证吗？”老板问。

“ 没问题 ,” 工程师说，“我已经快完成 90 ％了。”

如果你在软件界工作了几年，你可以完成这个故事。毫 不惊奇，年青人在项目的 90 ％处停滞不前，直到在别人 的帮助下在一个月后完成了项目。

项目管理 项目管理 16 16 条至理名言 条至理名言

项目管理 项目管理 16 16 条至理名言 条至理名言

 接受项目管理理论，并持续地运用它。

 采用促使公司向着成熟的项目管理发展的管理哲学，并 将其传达给每一个人。

 在每一个项目开始时，制定有效的计划。

 在付诸实施时，尽可能小地变动范围。

 要认识到成本和进度管理是紧密相连的。

 选择合适的人做项目经理。

 向高层管理者提供项目发起人的信息，而不是项目管理 的信息。

 加强直线管理层的参与和支持。

 关注可交付成果而不是资源。

 培育有效的沟通、合作及相互信任，以实现项目管理的 快速成熟。

 与全部的项目团队成员和直线管理层分享项目的成功。

 消除非生产性会议。

 应尽可能早而快地且以有效的成本识别并解决问题。

 定期测评项目进展。

 将项目管理软件作为一种工具，而不是一种计划或人际 关系技巧的替代品来使用。

项目管理 项目管理 16 16 条至理名言 条至理名言

（续） （续）