下一页
计算机软件基础
The software basic of computer
主讲：刘志强
第 15单元
软件工程概论
下一页
上一页
停止放映
第 2页
教学目标
? 了解软件工程的基本概念
? 掌握软件工程的基本理论, 技术和
方法, 运用于软件的开发和生产
下一页
上一页
停止放映
第 3页
教学内容
? 了解软件, 软件工程的基本概念
– 软件的特征
– 软件危机, 软件工程
– 瀑布模型, 原型模型
– 软件生存周期中各个阶段的任务,
实施方法及步骤
下一页
上一页
停止放映
第 4页
本单元涉及内容
? 概述
– 软件的基本概念
– 软件的发展和软件危机
? 第 9章 软件工程
– 9.1 软件工程
– 9.2 软件生存周期
– 9.3 软件工程管理
下一页
上一页
停止放映
第 5页
一、基本概念
? 软件 计算机系统中所有程序, 数据结构
及有关文档资料的总称 。 软件是计算机
技术和人类智慧高度结合的产物, 软件
开发不是简单, 机械地重复生产, 而是
创造性的脑力劳动 。
? 软件的作用 软件是今后信息产业发展的
推动力 。 美国最近在 24项高科技领域中
调查结果表明, 其中 18项与软件有关 。
下一页
上一页
停止放映
第 6页
软件工程学的体系结构
软件工程学
软件开发技术
软件开发方法学
软件工具
软件工程环境
软件工程管理 软件管理学软件经济学
下一页
上一页
停止放映
第 7页
问题的由来
? 软件内在规律 。任何事物有它自己的客观规律
和发展轨迹。只有认识了它，才能驾驭它。
? 软件地位及作用 。软件是计算机系统中重要的
组成部分。但在早期它并没有引起业界的重视。
随着计算机技术的发展，随着, 软件危机, 的出
现，以及软件危机对社会危害的增大，软件的地
位和作用也越来越重要。
? 软件工程学 。业界人士不得不设置专门的学
科 ——软件工程学来研究软件开发、生产的内在
规律，用于指导现代工程化的软件生产。
下一页
上一页
停止放映
第 8页
软件的特征（ 与硬件产品比较 ）
? 软件是逻辑产品
? 软件产品质量的体现方式不同
? 软件产品的失败曲线不同
? 软件产品的成本构成不同
? 软件产品不存在同类零件替换
? 软件产品的静态和动态属性
下一页
上一页
停止放映
第 9页
软件是逻辑产品
? 软件产品具有产值、价格、质量
和功能的特性，但看不见,是逻辑
的、无形的，是脑力劳动的结晶。
下一页
上一页
停止放映
第 10页
软件产品质量体现方式不同
? 质量体现方式不同：
– 实用、可靠、可操作性；
– 可维护性强
– 方便用户
– 不会折旧、损坏、老化
下一页
上一页
停止放映
第 11页
软、硬件失败曲线
下一页
上一页
停止放映
第 12页
成本构成不同
12%
需求
率
4%
生产率
开发人员
成本构成不同,主要投资在研制；软件研制是一种人力、资金密集
的产业，而软件生产只是简单的复制、安装和培训。
下一页
上一页
停止放映
第 13页
软件产品不存在同类零件替换
? 硬件可更换零部件 。 当硬件产品中某个部
件损坏后, 可以用相同的备用部件更换,
使硬件系统恢复正常工作 。
? 软件不能更换零部件 。 而软件产品却没有
相同的备用部件可言, 因为软件出现的每
一个故障, 要么是由于设计考虑不周造成
的, 要么是编程错误造成的 。 由于软件无
备用部件可供更换, 因而软件维护比硬件
维护要复杂得多,成本也高得多 。
下一页
上一页
停止放映
第 14页
软件产品的静态和动态属性
? 软件是由程序和相关文档资料组成的 。
? 程序是具有双重属性的：
– 交流 。 它是求解客观问题的逻辑描述, 是供阅读和交流
的, 它的表示是静态的；
– 执行 。 程序最终是通过运行去执行特定的操作和数据处
理, 它又具有极其复杂和丰富内涵的动态属性 。
? 程序是否正确的有双重标准：
– 静态的程序正确与否是检查它的语法和句法是否符合规
则要求；
– 动态的程序正确与否则要动态的测试程序的所有逻辑流
结构和数据结构是否正确 。
– 而后一种测试的难度和代价较之前一种要大得多 。
下一页
上一页
停止放映
第 15页
硬件生产率大幅提高
? 如今, 计算机的发展已进入一个新的历史
阶段；
? 硬件产品已系列化, 标准化,, 即插即
用, 。
? 硬件产品的生产可以采用最高精尖的现代
化工具和手段, 自动成批生产 。 生产效率
几百万倍的提高 。
? 生产能力过剩 。
返 回
下一页
上一页
停止放映
第 16页
软件生产率很低
? 伴随计算机的普及，整个社会对计
算机应用的需求越来越大。
? 但软件的生产却还沿用, 手工作坊,
的生产方式，人工编程生产。生产
效率仅提高了几倍。
? 生产能力极其低下。
返 回
下一页
上一页
停止放映
第 17页
硬、软件供需失衡
? 社会大量需求, 生产成本高, 生
产过程控制复杂, 生产效率低等
等因素构成软件生产的恶性循环 。
? 由此产生, 软件危机, 。
返 回
下一页
上一页
停止放映
第 18页
矛盾引发“软件危机”
? 软件危机是指在计算机软件的开发和
维护过程中所遇到的一系列严重问题。
? 为了研究、解决软件危机，诞生了一
门新兴学科 ——软件工程学。它把软
件作为工程对象，从技术措施和组织
管理两个方面来研究、解决软件危机。
下一页
上一页
停止放映
第 19页
软件危机的具体体现
（ 1） 软件开发进度难以预测
（ 2） 软件开发成本难以控制
（ 3） 用户对软件功能难以满足
（ 4） 软件产品质量无法保证
（ 5） 软件产品难以维护
（ 6） 软件缺少文档资料
下一页
上一页
停止放映
第 20页
（ 1）软件开发进度难以预测
? 拖延工期几个月甚至几年的现象并不罕见，这种
现象降低了软件开发组织的信誉。
? 以丹佛新国际机场为例 。 该机场规模是曼哈顿机
场的两倍, 宽为希思机场的 10倍, 可以全天侯同
时起降三架喷气式客机；投资 1.93亿美元建立了
一个地下行李传送系统, 总长 21英里, 有 4,000
台遥控车, 可按不同线路在 20家不同的航空公司
柜台, 登机门和行李领取处之间发送和传递行李；
支持该系统的是 5,000个电子眼, 400台无线电接
受机, 56台条形码扫描仪和 100台计算机 。 按原定
计划要在 1993年万圣节前启用, 但一直到 1994年 6
月, 机场的计划者还无法预测行李系统何时能达
到可使机场开放的稳定程度 。
下一页
上一页
停止放映
第 21页
（ 2）软件开发成本难以控制
? 投资一再追加, 令人难于置信 。 往往是
实际成本比预算成本高出一个数量级 。
? 而为了赶进度和节约成本所采取的一些
权宜之计又往往损害了软件产品的质量,
从而不可避免地会引起用户的不满 。
下一页
上一页
停止放映
第 22页
（ 3）用户对产品功能难以满足
? 开发人员和用户之间很难沟通, 矛盾很
难统一 。 往往是软件开发人员不能真正
了解用户的需求, 而用户又不了解计算
机求解问题的模式和能力, 双方无法用
共同熟悉的语言进行交流和描述 。
? 在双方互不充分了解的情况下, 就仓促
上阵设计系统, 匆忙着手编写程序, 这
种, 闭门造车, 的开发方式必然导致最
终的产品不符合用户的实际需要 。
下一页
上一页
停止放映
第 23页
（ 4）软件产品质量无法保证
? 系统中的错误难以消除 。 软件是逻辑产品,
质量问题很难以统一的标准度量, 因而造
成质量控制困难 。
? 软件产品并不是没有错误, 而是盲目检测
很难发现错误, 而隐藏下来的错误往往是
造成重大事故的隐患 。
下一页
上一页
停止放映
第 24页
（ 5）软件产品难以维护
? 软件产品本质上是开发人员的代码化的
逻辑思维活动, 他人难以替代 。 除非是
开发者本人, 否则很难及时检测, 排除
系统故障 。
? 为使系统适应新的硬件环境, 或根据用
户的需要在原系统中增加一些新的功能,
又有可能增加系统中的错误 。
下一页
上一页
停止放映
第 25页
（ 6）软件缺少适当的文档资料
? 文档资料是软件必不可少的重要组成部分 。
? 实际上, 软件的文档资料是开发组织和用
户的之间权利和义务的 合同书, 是系统管
理者, 总体设计者向开发人员下达的 任务
书, 是系统维护人员的 技术指导手册, 是
用户的 操作说明书 。
? 缺乏必要的文档资料或者文档资料不合格,
将给软件开发和维护带来许多严重的困难
和问题 。
下一页
上一页
停止放映
第 26页
软件生产随规模增大而复杂度增大
? 以美国宇航局的软件系统为例：
– 1963年 水星计划系统 200万条指令
– 1967年 双子星座计划系统 400万条指令
– 1973年 阿波罗计划系统 1000万条指令
– 1979年 哥伦比亚航天飞机系统 4000万条指令
? 假设 1个人一年生产一万条有效指令, 那么是否 4000
人生产一年, 或 400人生产 10年就能完成任务吗？ 答
案是否定的 。 一万条指令的复杂度决不仅仅是 100条
指令复杂度的 100倍 。
下一页
上一页
停止放映
第 27页
典型失败系统的例子
? IBM公司开发 OS/360系统, 共有 4000多
个模块, 约 100万条指令, 投入 5000人
年, 耗资数亿美元, 结果还是延期交付 。
在交付使用后的系统中仍发现大量
（ 2000个以上 ） 的错误 。
下一页
上一页
停止放映
第 28页
软件危机产生的原因
? 产生软件危机有两个方面的原因：
– 内部因素 。 与软件本身的特点有关 。
内在因素是客观的存在, 只能因势利
导加以解决 。
– 外部因素 。 与软件开发和维护的技术
方法有关 。 外部因素是可以完善, 提
高的 。
下一页
上一页
停止放映
第 29页
软件特点的因素
? 软件 是逻辑产品, 是代码化了的人的思维
活动 。 在总体构思时, 别人无法管理和干
预 。 在写出程序, 并在机器上运行之前,
进展情况难以掌握, 开发质量也无法评估 。
这些都给管理和控制带来不便 。
? 软件 是特定问题在计算机上的运行描述 。
实际问题的复杂性决定了一个实用软件系
统规模往往十分庞大 。 程序规模越大, 控
制, 管理难度也就越大 。
下一页
上一页
停止放映
第 30页
软件开发维护技术方法的因素
? 开发人员和用户之间的矛盾 。 许多软件系统开发失
败的主要原因是开发人员在没有准确, 完整地了解
了用户的需求后就急于编程；用户对需求也往往不
能准确, 完整地提出 。
? 软件产品有其生命周期 。 在周期的各个阶段有其具
体的任务, 如何完成任务, 各个阶段有不同的技术
方法和操作步骤 。 只有科学的按生命周期各阶段的
任务去组织实施, 才能保证质量, 降低成本；急于
求成, 不按科学规律, 方法实施, 只能, 事倍功
半,, 事与愿违 。
? 软件产品的使用寿命很长 。 在这期间因功能的增加,
硬件的更新换代, 都要对软件进行必要的修改 。 据
统计数据表明, 软件维护的费用占总费用的 55%~70%。
软件工程的一个重要目标就是提高软件的可维护性,
减少软件维护的代价 。
下一页
上一页
停止放映
第 31页
解决软件危机的途径
? 为了解决软件危机就要从 技术措施 和 组织
管理 两个方面去研究，不断总结经验教训，
提高软件产品的生产效率，降低软件开发和
维护的成本。
? 开发软件选用最好的开发工具是至关重要的，
即选择、设置良好的软件工程支撑环境。工
具选用的好，它可以, 放大, 人的智力，大
大加快软件开发速度，提高软件质量。
下一页
上一页
停止放映
第 32页
软件开发的演变过程
? 程序设计阶段
? 软件设计阶段
? 软件工程阶段
下一页
上一页
停止放映
第 33页
程序设计阶段 （ 1946年 ~1955年）
? 特点：
– 尚无软件的概念, 程序设计主要围绕硬件
进行开发, 规模很小, 工具简单, 无明确
分工 （ 开发者和用户 ）, 程序设计追求节
省空间和编程技巧, 无文档资料 。 主要是
用于科学计算 。
下一页
上一页
停止放映
第 34页
软件设计阶段 （ 1956年 ~1970年）
? 特点：
– 硬件环境相对稳定, 出现, 软件作坊, 的开发组
织形式 。 开始使用产品软件 （ 可购买 ）, 从而建
立了软件的概念 。 系统规模越来越庞大, 高级编
程语言层出不穷, 应用领域不断拓宽, 开发者和
用户有了明确分工, 社会对软件的需求量剧增 。
但是软件开发技术没有重大突破, 生产效率低下,
从而导致, 软件危机, 产生 。
下一页
上一页
停止放映
第 35页
软件工程阶段 （ 1970年 ~至今）
? 由于软件危机的产生, 迫使人们不得不研究, 改变
软件开发的技术手段和管理方法 。 从此软件生产进
入软件工程时代 。
? 特点：
– 硬件已向, 四化, （ 巨型, 微型, 网络, 智能 ）
发展, 数据库技术已成熟并广泛应用, 第三, 四
代语言出现 。
– 第一代软件技术 ——结构化程序设计在数值计算
领域取得优异成绩；
– 第二代软件技术 ——软件测试技术, 方法, 原理
用于软件生产过程；
– 第三代软件技术 ——处理需求定义技术, 用于软
件需求分析和描述 。
下一页
上一页
停止放映
第 36页
二、软件工程
? ―软件工程, 一词是 1968年北大西洋公约组
织的计算机科学家在当时联邦德国召开的
专门讨论解决, 软件危机, 的国际会议上
正式提出并使用的, 并由此诞生了一门新
兴学科 ——软件工程学 。
?, 软件工程学, 是一门交叉学科, 它涉及
计算机科学, 管理科学, 工程学和数学 。
? 计算机科学培养的是计算机科学家, 而 软
件工程 则是培养软件工程师 。
下一页
上一页
停止放映
第 37页
软件工程的目标
? 软件工程的基本目标是：
?开发尽可能多的软件产品；
?提高软件的生产效率；
?满足应用的功能需要；
?降低软件开发成本 。
下一页
上一页
停止放映
第 38页
软件工程的指导思想
? 为解决软件危机, 把, 软件, 这种特殊商
品的生产, 管理过程纳入传统工程管理的
轨道；
– 用计算机科学中的最新成果应用于软件
工程中
– 用管理学的原理和方法进行软件生产管
理
– 用工程学的观点进行核算, 制定工程进
度和实施方案
– 用数学方法建立软件的可靠模型和各种
有效算法
下一页
上一页
停止放映
第 39页
软件工程基本原理
? 自 1968年提出, 软件工程, 的概念以来，
专家学者又陆续突出了 100多条关于软件
工程的准则。
? 著名软件工程专家 B.W.Boehm于 1983年发
表的一篇论文中提出了软件工程的七条基
本原理。他认为这七条原理是确保软件产
品质量和开发效率的最小准则集合。
下一页
上一页
停止放映
第 40页
软件工程七条基本原理
– 用分阶段的生命周期计划严格管理
– 坚持进行阶段评审
– 实行严格的产品控制
– 采用现代程序设计技术
– 结果应能清楚地审查
– 开发小组人员少而精
– 承认不断改进软件工程实践的必要性
下一页
上一页
停止放映
第 41页
用分阶段生命周期计划严格管理
? 在软件的整个生命周期中应该制定并
严格执行六类计划：项目概要, 项目
进度表, 项目控制, 产品控制, 验证
及运行维护计划 。
? 不同层次的管理人员必须严格按照计
划各尽其职地去管理软件开发与维护
工作, 绝不能受客户或上级的影响而
擅自背离预定计划 。
下一页
上一页
停止放映
第 42页
坚持进行阶段评审
? 软件的质量保证工作不能等到编码阶段结束
之后再进行 。 这是因为：
– 大部分错误是在编码之前造成的 （ 根据
Boehm统计, 设计错误占软件错误的 63%，
编码错误占 37%） 。
– 错误发现与改正得越晚, 所付出的代价也
越高 。
因此, 在每个阶段进行严格的评审, 尽早发现
并修正各个阶段中所犯的错误是一条必须遵
循的重要原则 。
下一页
上一页
停止放映
第 43页
示意图关于阶段评审作用
下一页
上一页
停止放映
第 44页
实行严格的产品控制
? 在软件开发过程中不应随意改变需求 （ 改变
一项需求往往要付出很高的代价 ）, 但不能
禁止更改需求 。 当必须修改时, 为了保持软
件各配置成分的一致性, 必须实行严格的产
品控制 （ 主要是实行基准配置管理 ） 。
? 一切有关修改软件的建议 （ 特别是涉及到对
基准配置的修改建议 ） 都必须按照严格的规
程进行评审, 获准后才能实施修改 ） 。
? 绝对不能谁想修改就随意进行修改的行为 。
下一页
上一页
停止放映
第 45页
采用现代程序设计技术
? 以前的结构化程序设计技术, 如今的面
向对象程序设计技术都被实践证明是各
个不同历史阶段的优秀程序设计技术和
方法 。
? 采用先进的技术既可以提高软件开发的
效率, 又可以提高软件维护的效率 。
下一页
上一页
停止放映
第 46页
结果应能清楚地审查
? 软件产品是看不见, 摸不着的逻辑产品,
软件开发人员的工作进展情况可见性差 。
为了提高开发过程的可见性, 应根据软
件开发项目中的目标完成期限, 规定开
发组织的责任和产品标准, 使得到的结
果能够清楚的审查 。
下一页
上一页
停止放映
第 47页
开发小组人员少而精
? 开发小组成员的素质应该高，人员不宜
过多。人员素质和数量是影响产品质量
和开发效率的重要因素。
? 素质高的人开发效率比低的人高几倍甚
至几十倍，而错误则明显得少；
? 人数增加，管理难度也增加。
下一页
上一页
停止放映
第 48页
承认不断改进软件工程实践的必要性
? 要积极主动地采纳新的软件技术,
要不断总结经验；不能自以为是,
固步自封, 唯我独好 。
? 大千世界, 错综复杂, 只有不断学
习, 才能不断进取, 不断进步 。
下一页
上一页
停止放映
第 49页
软件工程应用范围
? 个人程序、中小型或一般程序同
开发人员之间的关联较小，应用
SE方法收效甚微。
? 大型程序要由若干个程序员小组
承担开发，相互关系极其复杂，
因此，必须自始至终坚持 SE方法。
下一页
上一页
停止放映
第 50页
应用程序分类
分类 程序规模 模块数 开发时间 开发人数
极小 500行以下 10~20 1~4周 1人
小 1K~2K行 25~50 1~6月 1人
中 5K~50K行 250~1000 1~2年 2~5人
大 50K~100K行 1000以上 2~3年 5~20人
甚大 1M行 4~5年 100~1000人
极大 1M~10M行 5~10年 2000~5000
下一页
上一页
停止放映
第 51页
传统软件工程模式
? 70年代, 计算机技术水平不高, 开发工具少而且性
能差 。 对于大型复杂问题的求解方法有很大的局限
性影响 。
? 软件工程采用的方法：把软件生存周期划分成若干
个阶段, 每个阶段的任务相对独立, 而且比较简单,
便于不同人员分工协作, 从而降低整个软件开发工
程的困难程度 。
? 在实现每个阶段的任务时, 采用的是系统化的技术
方法 ——结构化分析和结构化设计技术 。
? 传统软件工程模式的缺点,强调 了分阶段实施模块
化, 结构化程序设计技术和方法, 而 忽视 了人在软
件开发过程中的地位和作用 。
下一页
上一页
停止放映
第 52页
现代软件工程模式
? 现代软件工程是在传统软件工程模式的基础上, 为
了强调人在系统开发中的作用, 同时为了适应软件
新技术的发展趋势而提出的 。 其基本要点是：
1,以人为主, 充分利用软件开发方法及软件开发工具；
2,开发人员的组织管理对软件开发成功与否至关重要 ；
3,基于软件组件的软件开发技术 。 各种功能的可重用
软件组件不断问世 。 这使得在软件开发过程中编程
工作量日趋减少, 取而代之的是在设计好系统体系
结构后, 利用软件组件构造或重构软件系统 。
4,由于软件组件是 标准化设计, 成品化生产 的, 极易
构造使用, 从而大大简化了设计, 编程, 测试各个
环节的工作量, 提高了工作效率和生产效率 。
? 由于在软件开发过程中最大限度地采用软件组件,
使得软件开发过程变为系统分析, 系统构造, 系统
测试的集成过程 。
下一页
上一页
停止放映
第 53页
阶段的划分及主要任务
1) 系统分析
2) 系统设计
3) 系统测试
4) 软件组件
5) 系统开发人员的组织管理
下一页
上一页
停止放映
第 54页
系统分析
? 系统分析 从系统需求入手, 从用户观点出发建立系
统用户模型 。 用户模型从概念上全方位表达系统需
求及系统与用户的相互关系 。 系统分析在用户模型
的基础上, 建立适应性强的独立于系统实现环境的
逻辑结构 。
? 分析阶段 独立于系统实现环境, 可以保证建立起来
的系统结构具有相对的稳定性, 便于系统维护, 移
植或扩充 。
? 在 系统分析阶段, 系统的逻辑结构应从以下三方面
全面反映系统的功能与性能：
（ 1） 信息 。 完整描述系统中所处理的全部信息；
（ 2） 行为 。 完全描述系统状态变化所需处理或功能；
（ 3） 表示 。 详细描述系统的对外接口与界面 。
下一页
上一页
停止放映
第 55页
系统设计
? 在系统设计阶段, 首先考虑具体的实现环境 。 在设
计时, 可能会对系统结构作一些调整, 但为了保持系
统结构的稳定性, 应尽可能避免由于实现环境的特定
要求而改变系统结构 。
? 设计, 构造系统的软件组件 。 设计软件组件的主要
内容是定义组件的结构, 功能和外部接口, 以及组件
之间的相互关系和通信方式 。 对于复杂的大系统, 还
可以根据组件之间关联的紧密程度, 将关联密切的多
个组件形成一个子系统, 子系统之间具有松散的耦合 。
? 在系统实现阶段, 对于需要开发的软件组件, 选择
采用某种合适的程序设计语言编写相应的源代码程序,
完成系统实现工作 。
下一页
上一页
停止放映
第 56页
系统测试
? 系统测试包括单元测试, 集成测试和
系统测试 。 就功能而言与传统软件工
程模式中系统测试的功能相同 。
下一页
上一页
停止放映
第 57页
软件组件
? 在现代软件工程的开发过程中, 软件组件只是一
个辅助或支撑系统构造的一个过程 。
? 软件组件开发主要是开发与维护系统构造过程中
用到的组件 。 将软件组件作为一个单独的过程,
目的是将组件作为构造软件的, 零部件, 。
? 随着软件技术的不断发展及软件工程的不断完善,
软件组件将会作为一种独立的软件产品出现在市
场上, 供应用开发人员在构造应用系统时选用 。
下一页
上一页
停止放映
第 58页
系统开发人员的组织管理
? 现代软件工程不仅包括软件开发方法, 工具和过
程, 更强调人在开发过程中的作用 。 一个复杂的
系统开发过程, 涉及到众多的以人为主的各种开
发活动, 通过这些活动的有机配合与协调才能保
证系统开发的成功 。 因此, 系统开发人员的组织
管理是现代软件工程中的重要方面 。
? 组织管理方法有以下几个要点：
① 明确系统开发人员与用户之间的责任与义务；
② 明确各类开发人员的主要工作及责任；
③ 制定或选择工程开发规范 。
下一页
上一页
停止放映
第 59页
三、软件生命周期
? 软件生存周期 指从软件的需求分
析、设计、编程、测试、交付用
户使用到版本升级、或被被自然
淘汰的过程。
? 软件工程的应用模式也称为软件
生存周期模式。通常也称其为
“瀑布模型”（ B.W.Bohem提出
的该模型 )。
下一页
上一页
停止放映
第 60页
⒈ 软件生命周期各个阶段任务
? 需求分析、定义
? 系统总体设计
? 系统编程
? 系统测试
? 系统维护
下一页
上一页
停止放映
第 61页
⑴ 需求分析、定义
? 任务是,收集、分析、理解、确定用户的要求；
然后把用户的要求精确、完整地描述表达出来。
? 目的,要回答“要解决什么问题？”，
既系统” 做什么？“。
? 分两步骤：
– 可行性研究, 制定软件开发计划
– 进行需求分析
? 阶段结果,产生出：
– 可行性报告、软件计划、需求说明书
下一页
上一页
停止放映
第 62页
⑵ 系统总体设计
? 任务是,
– 设计软件系统的模块层次结构
– 模块间逻辑关系、参数
– 每个模块的功能
? 目的：要回答,如何解决该问题？”，
既系统” 怎样做？“。
? 分两步骤：
– 概要设计：解决系统的模块划分、模块的层次
结构及数据库设计。
– 详细设计,解决每个摸块内部算法和数据结构。
? 阶段结果； 产生出：
– 系统设计说明书和模块功能说明书。
下一页
上一页
停止放映
第 63页
⑶ 系统编程
? 任务是,
根据设计说明书中每个模块
的控制流程编出相应的程序。
? 阶段结果,
软件系统的源程序。
下一页
上一页
停止放映
第 64页
⑷ 系统测试
? 任务是：检查、发现程序中的错误，提高软件的可靠
性。回答：,该系统是否能实现规定的操作？”。
? 分三个阶段：
– 模块测试 测试每个模块的程序是否有错；
– 组装测试 测试模块之间的接口是否正确；
– 确认测试 测试整个软件系统是否满足用户功能、性能要求。
? 测试三大基本技术：
– 逻辑覆盖 （白盒法）
– 边值分析 （黑盒法）
– 等价类划分 （黑盒法）
? 阶段结果：测试报告；说明测试数据的选择，测试对
象、测试结果是否符合预期结果等。
下一页
上一页
停止放映
第 65页
⑸ 系统维护
? 任务是：改正软件系统在使用过程中
发现的隐含错误，扩充在使用过程中
的新的功能要求；
? 目的：维护软件系统的正常运行；
? 阶段结果：软件系统的问题报告和软
件修改报告（记录发现软件错误的情
况以及修改软件的过程）。
下一页
上一页
停止放映
第 66页
⒉ 瀑布模型
需求分析 7%
系统设计 6%
软件编程 7%
软件测试 13%
软件维护 67%
用户要求
分析报告
系统设计报告
源程序
测试报告
更改要求
U
A
M A
T
M
M
P
U
T
P U
A
M
P
A 系统分析员
M 项目管理员
P 程序员
T 高级程序员
U 用户
下一页
上一页
停止放映
第 67页
瀑布模型的特点
? 瀑布模型具有 顺序性 和 依赖性,即后一阶
段的工作必须在前一阶段的工作完成后才
能开始。
? 把逻辑设计与物理设计清楚地划分开，是
瀑布模型的重要指导思想。
? 瀑布模型强调的是优质，即每一步都循序
渐进，及早消除隐患，从而保证软件质量。
? 它的 致命缺点 在于只有做出精确的需求分
析，才能取得预期的结果。由于各种客观、
主观的原因，需求分析往往不很精确，常
常给日后的开发带来隐患。
下一页
上一页
停止放映
第 68页
⒊ 原型模型 —— 样品模型
? 原型模型的主要思想：
先借用已有系统作为原型模型，通过,样品,不断改进，
使得最后的产品就是用户所需要的。
? 原形模型的特点：
(1） 开发人员和用户在, 原型, 上达成一致 。 这样一来,
可以减少设计中的错误和开发中的风险, 也减少了对
用户培训的时间, 而提高了系统的实用, 正确性以及
用户的满意程度 。
（ 2） 缩短了开发周期, 加快了工程进度 。
（ 3） 降低成本 。
? 原型模型的缺点：
当告诉用户, 还必须重新生产该产品时, 用户是很难接
受的 。 这往往给工程继续开展带来不利因素 。
下一页
上一页
停止放映
第 69页
快速原型模型
分析原型
样品
模型 设计
编程
测试
使用
修改
与
改进
在系统分析与
设计中，采用
交互式，反复
修改与不断改
进的方式进行。
还有的把原型模式嵌套在瀑布模型中运用。
下一页
上一页
停止放映
第 70页
⒋ 螺旋模型
? 螺旋模型将工程划分为 4个主要活动：制定计划,
风险分析, 实现工程和用户评价 。 4个活动螺旋
式地重复执行, 直到最终得到用户认可的产品 。
① 制定计划,确定软件目标,选定实施方案,弄清项
目开发限制条件 。
② 风险分析,分析可选方案,分析识别风险,研究解决
化解风险的办法 。
② 实现工程,实施软件产品的开发 。
③ 用户评价,对当前工作结果进行评价, 提出改进
产品的建议 。
螺旋模型的缺点,很难让用户确信这种演化方法的结
果是可以控制的,
下一页
上一页
停止放映
第 71页
⒌ 其他模型
? 智能模型 也称基于知识的软件开发模型，它与专
家系统结合在一起。该模型应用基于规则的系统，
采用归纳和推理机制，帮助软件人员完成开发工
作，并使维护在系统规格说明一级进行。
? 该模型在实施过程中要建立知识库，将模型本身、
软件工程知识与特定领域的知识分别存人数据库。
以软件工程知识为基础的生成规则构成的专家系
统与含应用领域知识规则的其他专家系统相结合，
构成这一应用领域软件的开发系统。
? 面向对象生存周期模型 其 主导思想是：在整
个软件开发过程中将面向对象技术贯穿于整个生
存周期。当然，还要结合传统开发模式中好的、
已被无数成功开发活动证明是可行的经验和技术 。
下一页
上一页
停止放映
第 72页
四、软件工程管理
1,软件工程项目管理的任务
2,软件人员组织与管理
3,软件配置管理
4,软件知识产权保护
下一页
上一页
停止放映
第 73页
⒈ 软件工程项目管理的任务
? 软件工程项目管理所涉及的范围覆盖了整个软件
工程过程 。 它管理的任务是：根据项目合同书的
要求, 制定项目计划和工程进度安排, 监督和检
查项目实施过程, 保证工程满足要求的质量标准,
分析确定并排除风险, 在规定的期限和预算成本
内完成项目 。 包括：
项目计划和进度安排
项目追踪和质量保证
成本估算
风险分析
下一页
上一页
停止放映
第 74页
① 项目计划和进度安排
? 项目计划要列出软件开发要做的主要工作和任务
清单, 要回答, 软件工程项目做什么, 。
? 在工作和任务清单中要清楚地描述出：
– 项目划分的各个实施阶段
– 每个阶段的工作重点和任务是什么
– 完成本阶段工作和任务的人力, 资源需求,
时间期限
– 阶段工作和任务的成果形式
– 项目实施过程中对风险, 疑难, 其他不可预
见因素等的处理机制
– 各任务组及开发人员之间的组织, 协调关系
等 。
下一页
上一页
停止放映
第 75页
进度安排
? 在制定项目进度安排时，主要依据是合同书
和项目计划。通常的做法是把复杂的整体项
目分解成许多可以准确描述、度量、可独立
操作的相对简单的任务，然后安排这些任务
的执行顺序，确定每个任务的完成期限、开
始时间和结束时间。
? 开始需要考虑的主要问题是：
– 项目可以支配的人力及资源
– 项目的关键路径
– 生存周期各个阶段工作量的划分
– 工程进展如何度量
– 各个阶段任务完成标志
– 如何自然过渡到下一阶段的任务等。
下一页
上一页
停止放映
第 76页
② 项目追踪和质量保证
? 项目追踪实施由项目管理人员负责 。 他们必须按
进度安排表追踪检查每一个任务 。 如果任务实际
完成日期滞后于进度安排, 则管理人员可以行使
职权范围内的权力 采取各种补救措施以减少进度
误期所造成的影响 。 包括对资源重新定向, 对任
务重新安排, 甚至可以修改交付日期以调整已经
暴露的问题 。
? 质量保证在软件生存周期中是至关重要的 。 人们
在管理项目时往往只强调必须按期完成任务, 必
须遵循进度计划, 必须把成本控制在预算范围内,
却忽视了在生存周期各个阶段工作和任务应满足
规定的质量标准 。
下一页
上一页
停止放映
第 77页
软件质量主要因素包括
正确性 在预定的系统环境下能正确地完成预期的功能；
健壮性 在预定意外环境下系统能适当地给予预期的响应；
完整性 对未经授权的操作, 系统能够进行控制；
可用性 系统在完成预定任务的功能时能够圆满地实现；
灵活性 系统应能满足硬件环境升级和部分功能扩充需求；
可理解性 用户和维护人员应非常容易的理解和使用系统；
可维护性 用户按文档资料应能排除常见系统故障, 保持
系统正常运行；
可移植性 在厂家协助下, 系统可以移植到其他硬件环境
且费用可以接受；
可重用性 系统全部或部分代码可以在其他应用系统中被
使用；
可测试性 系统容易测试 。
下一页
上一页
停止放映
第 78页
保证软件质量的措施
? 为了保证软件质量，在软件开发过
程中应采取下列措施：
（ 1） 审查
（ 2） 复查和管理复查
（ 3） 测试
下一页
上一页
停止放映
第 79页
审查
? 在软件生存期各个阶段结束之前，都要对该阶段产
生的结果和软件配置文档进行严格技术审查。
? 审查过程包括：
① 计划：组织审查组、分发材料等；
② 概况介绍：对大的项目，让主程序员介绍概况；
③ 准备：评审员阅读材料，取得项目有关知识；
④ 评审会：目的是发现和记录错误；
⑤ 返工：开发者修改已经发现的问题；
⑥ 复查：检查返工是否真正解决了问题。
下一页
上一页
停止放映
第 80页
复查和管理复查
? 复查是检查已有的材料, 以断定本阶段
的工作是否能够开始或继续 。 每个阶段
开始时的复查是为了肯定前一个阶段结
束时确实进行了认真的复查, 已经具备
了开始当前阶段工作所必须的材料 。
? 管理复查是指：向开发组织或使用部门
的管理人员提供有关项目的总体状况以
及进度等方面的情况, 以便他们从管理
的角度对开发工作进行审查 。
下一页
上一页
停止放映
第 81页
测试
? 测试是用测试用例执行系统, 以检查测试结
果是否和预期结果一致 。
? 在测试过程中将产生以下文档,
① 测试计划,确定测试范围, 方法, 测试用例
和所需资源等；
② 测试过程,详细描述与每个测试方案有关的
测试步骤和数据 （ 包括测试预期结果 ） ;
③ 测试结果,把每次测试运行的结果归入文档,
如果运行出错, 则应产生问题报告, 并且要
通过调试解决所发现的问题 。
下一页
上一页
停止放映
第 82页
③ 成本估算
? 成本估算和成本管理是软件项目管理的核心任务
之一 。 在制定项目计划时, 就必须对项目需要的
人力及其他资源, 项目持续时间和项目成本做出
估算 。 如果新项目和以往的项目类似, 估算可以
参考以前的成本费用 。
? 现在已有一些用于软件成本估算的技术可供借鉴 。
这些估算技术各有其优缺点, 但以下几方面是共
同的：
– 事先建立软件的工作范围；
– 以软件度量 （ 经验度量, 相似工程类比的度
量 ） 为基础做出估算
– 把项目分解为可单独进行估算的小块
下一页
上一页
停止放映
第 83页
成本估算方法
? 就方法论而言, 有两种基本的成本估算方法：自
顶向下和自底向上 。
? 自顶向下法是对整个工程项目的总开发时间和总
工作量做出估算, 然后将它们按阶段, 步骤和任
务进行分配 。
? 自底向上法则正好相反, 先分别估算各个任务所
需要的工作量和开发时间, 再相加, 从而得到总
的工作量和总的开发时间 。 这两种方法都要求采
用某种方法做出估算 。
? 有许多估算方法可以利用, 大致划分为三类：专
家估算法, 类推估算法, 算式估算法 。
下一页
上一页
停止放映
第 84页
成本估算方法简介
? 专家估算法 依靠一个或多个专家对项目做出估算,
其精度主要取决于专家对估算项目的定性参数的了
解和他们的经验 。
? 类推估算法 在自顶向下法中, 类推估算法将估算
项目的总体参数与类似项目进行直接比较得到结果；
在自底向上法中, 类推是在两个具有相似条件的工
作单元之间进行 。
? 算式估算法 前两种估算法的缺点在于：它们依靠
的是带有主观猜测和盲目性的估算方法 。 算式估算
法则是企图避免主观因素影响的一种方法 。 算式估
算法有两种基本类型：由理论导出的算法和由经验
得出的算法 。
下一页
上一页
停止放映
第 85页
④ 风险分析
? 在开发新的软件系统过程中, 由于存
在许多不确定因素, 软件开发失败的
风险是客观存在的 。 因此, 风险分析
对于软件项目管理是决定性的 。 风险
分析实际上就是贯穿在软件工程过程
中的一系列风险管理步骤, 其中包括：
风险识别, 风险估计, 风险管理策略,
风险解决和风险监督等 。
下一页
上一页
停止放映
第 86页
主要风险因素
① 产品大小 。实践经验表明项目风险和产品的大小
成正比。公认产品大小度量单位是以代码行或功能
点计。
② 技术相关。 未曾使用过的新技术都存在风险。包
括未使用过的新型硬件、支持软件，缺乏标准与规
范的非传统的开发方法等。技术过时也是风险。技
术风险一般难于改正。
③ 开发环境 。适用的开发工具不足、不可靠、使用
不方便等因素，都会降低开发效率。
④ 组织规模和人员经验 。
⑤ 客户因素 。表现在客户需求经常矛盾，不了解客
户的特殊需要，客户不了解项目中采用的新技术，
且双方又难于沟通等。
下一页
上一页
停止放映
第 87页
⒉ 软件人员组织与管理
? 人员是软件工程项目最重要, 也是
最为活跃的资源因素 。 如何组织得
更加合理, 如何管理得更加有效,
从而最大限度地发挥这一重要的资
源潜力, 对于成功地完成软件工程
项目至关重要 。
1) 项目组的组织结构
2) 程序设计小组的组织形式
3) 软件项目的管理
下一页
上一页
停止放映
第 88页
⑴ 项目组的组织结构
? 开发组织采用什么形式, 要针对软件项目的特
点来决定, 同时也与参加人员的素质有关 。
? 建立项目组织时要考虑这样一些原则：
① 项目责任制度 。 项目必须实行项目负责人责
任制 。 项目责任人对项目的完成负全部责任 。
② 人员少而精 。 项目组成员之间的交流和协作
是项目成败的关键 。 人员少, 具有便于组织
管理, 合理分工, 减少通信等优点；人员精,
有利于互相激励, 发挥各自的特长优势, 提
高工作效率 。
下一页
上一页
停止放映
第 89页
选择组织结构的模式
（ 1） 按课题划分 按课题划分小组 。 小组成员自始至终参加
所承担课题的各项任务 。
（ 2） 按职能划分 按任务的工作阶段划分成若干个专业小组 。
例如, 分别建立计划组, 需求分析组, 设计组, 实现组,
测试组, 质量保证组, 维护组等 。 要开发的软件产品在每
个专业小组完成阶段加工后, 沿工序流水线向下传递 。 这
种流水线模式便于小组人员熟悉本组的工作, 进而变成这
方面的专家 。 但也有小组之间的通信接口增多, 通信路径
延长等问题 。
（ 3） 矩阵形模式 这种模式实际上是以上两种模式的结合 。
既设立项目经理负责项目的管理, 又成立一些专门组, 每
个成员参加其中一个组的实际工作 。 矩阵形结构组织的优
点是：参加专门组的成员可在组内交流其在各项目中取得
的经验, 这更有利于发挥专业人员的作用 。 而且各个项目
有专人负责, 有利于项目的完成 。
下一页
上一页
停止放映
第 90页
⑵ 程序设计小组的组织形式
? 一般情况下, 程序设计人员是在一定
程度上独立自主地完成各自的任务 。
但这并不意味着互相之间没有联系 。
事实上, 人员之间联系得多少和联系
方式与生产效率直接相关 。
? 程序设计小组内人数少, 如 2～ 3人,
则人员之间的联系比较简单 。 但随着
人数的增加, 相互之间的联系是按非
线性关系变得复杂起来 。 因此, 小组
内部人员的组织形式对生产率也有很
大的影响 。
下一页
上一页
停止放映
第 91页
① 主程序员组
? 组由主程序员, 程序员和后援工程师为核心组成 。
? 主程序员 是经验丰富能力强的高级程序员, 负责小组全部
技术活动的计划, 协调与审查工作, 还负责设计和实现项
目中的关键部分 。
? 后援工程师 协助和支持主程序员的工作, 为主程序员提供
咨询, 也做部分分析, 设计和实现的工作, 并在必要时代
替主程序员工作, 以便使项目能继续进行 。
? 程序员 负责项目的具体分析与开发, 以及文档资料的编写
工作 。 根据系统规模大小及难易程度, 小组还可以聘请一
些专家, 辅助人员, 软件资料员协助工作 。
? 主程序员组这种集中领导的组织形式突出了主程序员的领
导作用, 简化了人际通信 。 这种组织形式能否取得好的效
果, 很大程度上取决于主程序员的技术水平和管理才能 。
美国的软件产业中大多采用主程序员组的组织形式 。
下一页
上一页
停止放映
第 92页
② 民主小组
? 小组由经验丰富的技术人员组成 。 项目有关的所
有重大决策都由全体成员集体讨论, 确定解决 。
这种组织形式强调发挥每个成员的积极性, 要求
每个成员充分发挥主动精神和协作精神 。 通过充
分讨论, 也是在互相学习, 因而在组内形成一个
良好合作的工作气氛 。 但有时也会因此削弱个人
的责任心和必要的权威作用 。 有人认为这种组织
形式适合于研制时间长, 开发难度大的项目 。
? 日本软件产业中大多采用这种组织形式, 取得较
好的效果 。 这种组织形式在强调发挥每个成员的
积极性的同时, 也创造了一个尊重每个成员的良
好工作环境 。 由于小组成员在工作上能够很好地
配合, 因而做到了较长时间稳定的人员合作关系 。
这样的小组形式避免了美国因软件人员频繁流动
对工作造成的严重干扰 。
下一页
上一页
停止放映
第 93页
③ 层次小组
? 小组内人员分为 3级：组长, 高级程序员
和程序员 。
? 组长 负责全组工作, 包括任务分配, 技
术评审和复查, 掌握工作量和参加技术
活动 。 组长直接领导 2至 3名高级程序员 。
? 高级程序员 通过基层小组, 管理若干个
程序员 。 这种组织结构只允许必要的人
际通信 。 它比较适合项目本身就是层次
结构状的课题以及大型软件项目的开发 。
下一页
上一页
停止放映
第 94页
⑶ 软件项目的管理
? 软件项目管理包括项目指导和项目检验 。
? 指导的目的是在软件项目的实施过程中, 动
员和促进工作人员积极完成所分配的任务 。
? 检验是软件管理的最后一个方面 。 它是对照
计划检查执行情况的过程, 同时也是对照软
件工程标准检查实施情况的过程 。 在发现项
目的实施与计划或标准有较大的偏离时, 应
采取措施加以解决 。
? 管理内容包括：
指导工作的要点
检验管理的要点
检验管理的工作范围
下一页
上一页
停止放映
第 95页
指导工作的要点
① 鼓励 。 恰当而且及时地鼓励是非常重要的 。 要
建立健全竞争和激励机制, 它可使人们充满信心,
勇于继续克服困难, 愿意努力进一步提高工作效
率, 迎接新任务的挑战 。
② 引导 。 通常, 人们愿意追随那些能够体谅个人
要求或实际困难的领导 。 高明的领导人应能体察
到这些, 并能巧妙地把个人的要求和目标与项目
工作的整体目标结合起来, 至少应能做到在一定
程度上的协调, 或在一个工作周期内一致 。 要制
定相对优惠的, 留人, 政策, 稳定骨干队伍 。 从
风险分析中可知, 大幅度的人员调整是非常有害
的, 即使是人员的临时观念也会使项目付出无形
的代价, 因而蒙受无谓的损失 。
下一页
上一页
停止放映
第 96页
检验管理的要点
① 重大偏离 。 在软件项目实施过程中, 必须注
意：工作与计划之间, 任务与标准之间的重
大偏离 。 遇到有这种情况时应及时向管理部
门报告并采取相应的措施给予适当的处置 。
② 选定标准 。 检验管理需要事先确定应当遵循
的标准, 使得软件项目的工作进展可以用某
些客观, 精确且有实际意义的标准加以衡量 。
③ 特殊情况 。 管理人员必须注意软件项目实施
的一些特殊情况, 认真分析其中的一些特殊
问题, 加以解决 。
下一页
上一页
停止放映
第 97页
检验管理的工作范围
? 检验管理可能涉及到以下几个方面：
① 质量管理 。 包括明确度量软件质量的因素
和准则, 决定质量管理的方法和工具, 以
及实施质量管理的组织形式 。
② 进度管理 。 检验进度计划执行的情况 。
③ 成本管理 。 度量并控制软件项目的开销 。
④ 文档管理 。 检验文档编写是否符合要求 。
⑤ 配置管理 。 检验, 控制软件配置项的变更 。
下一页
上一页
停止放映
第 98页
⒊ 软件配置管理
? 软件配置管理是人们在软件工程实
践过程中总结出的一套管理办法和
原则 。 软件配置管理将伴随整个软
件生存周期 。
1) 软件配置管理和基线
2) 配置管理的任务
下一页
上一页
停止放映
第 99页
⑴ 软件配置管理和基线
? 什么是软件配置项？ 一般认为：软件生存周
期各个阶段活动的产物经审批后即可称之为
软件配置项 。
? 软件配置项包括：
① 与合同, 过程, 计划和产品有关的文档和
资料；
② 源代码, 目标代码和可执行代码；
③ 相关产品, 包括软件工具, 库内的可重用
软件, 外购软件及顾客提供的软件等 。
下一页
上一页
停止放映
第 100页
基线
? 什么是基线？ 第一次提出的软件配置项就构成基线配置
项 。 基线分类列表如下：
– 系统功能说明 。 系统模型, 项目计划, 进度安排；
– 软件需求规格说明 。 包括：图形分析模型, 过程, 原型, 数学
规格说明；
– 设计规格说明 。 包括：数据设计, 体系结构设计, 界面设计,
对象的描述等；验收规格说明；
– 测试规格说明 。 包括：测试计划, 测试用例, 测试预期结果,
测试记录等；
– 数据库描述 。 包括：数据模式, 记录结构, 数据项描述；
– 模块规格说明 。 包括：模块功能, 模块算法, 模块接口等描述；
– 运行系统 。 包括：模块代码, 链接模块, 数据库, 支持及工具
程序等；
– 用户文档 。 包括：安装说明, 操作说明, 用户手册等；培训计
划；维护文档, 包括：故障报告, 维护要求, 更改记录等；
– 项目采用的有关标准和规程 。
下一页
上一页
停止放映
第 101页
⑵ 配置管理的任务
① 标识软件配置项
② 版本控制
③ 变更管理
④ 审计
下一页
上一页
停止放映
第 102页
① 标识软件配置项
? 大型软件工程项目开发过程中可能会产生许多技
术文档 。 随着软件系统的变更, 有关文档也将发
生变化 。 因此, 对软件配置项的管理是一个动态
管理的过程 。 为了便于管理, 首先要便于检索 。
而要检索就必须对所有的配置项进行标识, 命名 。
标识软件配置项是配置项管理的重要基础工作 。
? 所有的软件配置项均可以当作对象来标识 。 例如,
基本对象可以是一段需求规格说明, 一个模块的
源代码清单, 一组测试用例等 。 将这些正文单元
命名后作为基本对象, 再将基本对象按内部逻辑
进行组合, 就形成复合对象 。 复合对象表示的是
一本设计规格说明书, 一个完整的源程序清单 。
下一页
上一页
停止放映
第 103页
② 版本控制
? 版本更新是软件生存期中的自然现象 。 软件系统每
做一次修改, 就应该变更一次版本 。 不同版本反映
的是不同时期, 不同硬件环境, 不同用户需求的该
软件系统的特定功能 。 为了保持该软件系统一脉相
承的完整性, 每一个软件配置项修改后的以前版本
都要保留 。
? 版本更新就好像一棵生长的树 。 所有版本均按版本
模型 （ 树形结构 ） 存放于仓储库中 。 为节省仓储库
的存储空间, 版本存放采用增量法, 即只存放新版
本与旧版本不同部分的内容 。
下一页
上一页
停止放映
第 104页
③ 变更管理
? 有变更的需求就要有变更的控制和
管理 。 它的主要任务包括：
1,分析变更的必要性和合理性, 确
定是否实施变更；
2,记录变更信息, 填写变更控制单；
3,做出更改, 并交上级审批；
4,修改相应的软件配置项 （ 基线 ）,
确立新的版本；
5,评审后发布新版本 。
下一页
上一页
停止放映
第 105页
④ 审计
? 软件配置项的更改反映了用户提高, 扩充软件系
统功能和性能的要求以及软件开发人员对软件需
求定义的认识的提高 。
? 如何保证变更需求和变更实施结果的一致性？ 如
何保证任何一个变更能顺利正确地完成？ 这正是
审计的作用 。 为保证软件配置项变更的合理性和
严肃性, 必须实行严格的审计控制 。
? 一般采用两种方法进行审计：
– 正式技术评审 着重检查对软件配置项的变更
的技术正确性 。 综合考虑此软件配置项的变更
对其它配置项乃至整个软件系统的潜在影响和
作用 。
– 软件配置审核 是审核变更的落实情况；变更
修改是否完成？ 变更手续是否完备？ 变更修改
有无违反标准？
下一页
上一页
停止放映
第 106页
⒋ 软件知识产权保护
? 计算机软件是人类知识, 智慧和创造性劳动的结晶, 软件
产业是知识和资金密集型的新兴产业 。 由于它具有开发工
作量大, 周期长, 而生产 （ 复制 ） 容易, 费用低等特点,
因此, 长期以来, 软件的知识产权得不到尊重, 软件的真
正价值得不到承认, 靠非法窃取他人软件而牟取商业利益
成了信息产业中投机者的一条捷径 。 因此, 软件产权保护
已成为急待解决的一个社会问题, 是我国软件产业健康发
展的前提 。
? 1967年在瑞典斯得哥而摩成立了世界知识产权组织 。 1980
年我国正式加入该组织 。 1990年 9月我国颁布了, 著作权
法,, 确定计算机软件为保护的对象 。 1991年 6月由国务
院正式颁布了我国, 计算机软件保护条例, 。
? 应该学习并掌握必要的软件保护法律知识 。 一方面要尊重
别人的智力劳动成果, 不应任意侵犯他人的软件版权；另
一方面要采取切实的保护措施保护自己以及本单位开发的
软件成果 。
下一页
上一页
停止放映
第 107页
⑴ 软件知识产权的法律保护
? 知识产权 又称为智力成果产权和智慧财产权, 是指对智力
活动所创造的精神财富所享有的权利 。
? 知识产权分为：工业产权和版权；前者主要包括专利权, 商标
专有权和制止不正当竞争权；后者专指计算机软件 。
? 知识产权的主要特点是：
① 无形性 。 是指其保护对象是无形的 。 知识产权的权利人只
有当其主张自己权利的时候, 才能确认为权利人 。
② 专有性 。 指未经知识产权人的同意, 除法律有规定的情况
外, 他人不得占有或使用该项智力成果 。
③ 地域性 。 指法律保护知识产权的有效地区范围 。 任何国家
法律所确认的知识产权, 只在其本国领域内有效, 除非该
国与他国签订有双边协定或该国参加了有关知识产权保护
的国际公约 。
④ 时间性 。 指法律保护知识产权的有效期限, 期限届满即丧
失效力 。 这是为限制权利人不致因自己对其智力成果的垄
断期过长而阻碍社会经济, 文化和科学事业的发展 。
下一页
上一页
停止放映
第 108页
⑵ 计算机软件是著作权保护的客体
① 软件著作权保护的基本条件 对计算机软件来说, 著作权法并
不要求软件达到某个较高的技术水平, 只要是开发者独立地自
行开发的软件, 即可享有著作权 。 一个仅处于作者构思过程中,
未表现出来的软件, 不享有著作权 。 一个软件必须在其创作出
来, 并固定在某种有形物体 （ 如纸, 磁带, 磁盘 ） 上面, 能为
他人感知, 传播, 复制的情况下, 才能享有著作权保护 。
② 软件著作权的特征 计算机软件的体现形式是程序和文件 。 文
件是受著作权法保护的 （ 包括：人无法识别的目标代码 ） 形式
的程序, 固化在只读存储器 （ ROM） 中的程序等 ） 。
③ 软件著作权的保护范围 著作权法的基本原则是：只保护作品
的表现, 而不保护作品中所体现的思想, 概念 。 因此, 在软件
中哪些是思想, 概念？ 哪些是表现？ 要确定著作权保护客体的
范围是比较困难的 。 目前人们比较一致的认为：软件的功能目
标应用属于思想, 概念, 不受著作权法的保护；而软件的程序
代码则是表现, 应属于著作权保护的客体之内 。
下一页
上一页
停止放映
第 109页
⑶ 软件著作权人享有的专有权力
? 根据我国著作权法的规定, 作品著作人 （ 或
称版权人 ） 享有５项专有权力：
① 发表权 。 决定作品是否公布于众的权力 。
② 署名权 。 表明作者身份, 在作品上有署名权 。
③ 修改权 。 修改或授权他人修改作品的权力 。
④ 保护作品完整权 。 保护作品不受篡改的权力 。
⑤ 使用权和获得报酬权 。 以复制, 表演, 播放,
展览, 发行, 摄制电影, 电视, 录像或改编,
翻译, 注释, 编辑等方式使用作品的权力,
以及许可他人以上述方式作为作品, 并由此
获得报酬的权力 。
下一页
上一页
停止放映
第 110页
⑷ 软件著作权的登记
?, 计算机软件保护条例, 中对办理软件著作权登记
有以下基本要求：
① 凡完成开发一年之内的软件均可向软件登记机
构办理登记申请 。
② 凡已在软件登记机构办理登记的软件, 在其专
有权力发生转让活动时, 受让方应在转让合同
正式签订后的两个月之内向软件登记机构备案 。
③ 当国籍或定居地为中国的著作权人或其受让者,
在中国境内开发的计算机软件的专有权力要向
境外许可或转让时, 许可方或转让方应首先报
请国务院有关主管部门批准, 并向软件登记机
构备案 。
下一页
上一页
停止放映
第 111页
⑸ 办理软件著作权登记的基本要求：
① 办理软件著作权和软件著作转让或许可的登记, 备案手续, 应
当到法定的或国家指定的软件登记机构办理 。
② 办理上述登记手续应当是软件专有权人 （ 包括公民, 法人或非
法人组织 ） 或者是软件专有权人委托的代理人 。 但代理人须向
软件登记管理机构出示写明委托权限的委托书 。
③ 通常一个独立的软件, 只能办理一次著作权的登记 。 若软件是
由多个独立的软件组成的, 也可以分别办理软件著作权的登记
手续 。
④ 办理软件著作权登记均应以书面的形式进行 。 在软件申请书
（ 登记表 ） 上应有申请者或代理人的签章 。
⑤ 办理软件著作权登记时, 申请者应提交该软件具有独创性事实
和转让, 许可证明等有关鉴别材料 。
⑥ 对于软件登记申请中出现的有关问题和遗漏, 软件申请者应积
极配合软件登记机构予以纠正 。
⑦ 所办理的软件登记手续, 均应在法定的期限内完成, 否则将失
去机会 。
⑧ 办理登记手续时, 应交纳法定的手续费 。
下一页
上一页
停止放映
第 112页
思考题
第 9章习题：
1~24
下一页
上一页
停止放映
第 113页
第 10周上机安排
班级 日期 时间 机房
电气 93 星期一 14～ 18,00 302
电气 92 星期一 14～ 18,00 302
电气 91 星期一 18～ 22,00 302
电气 94 星期四 18～ 22,00 302
电气 95 星期五 18～ 22,00 302
应化 01 星期四 18～ 22,00 302
应物 91 星期五 18～ 22,00 302
下一页
上一页
停止放映
第 114页
结束语
? 欢迎参加到中心网站, 软件基础, 课程的学习讨
论中来。
? 中心网址：
http,//ctec.xjtu.edu.cn
? 课件下载地址,
ftp,//ctec.xjtu.edu.cn
? 我的 E-mail地址,
LZQ_2668634@263.net
谢谢！
计算机软件基础
The software basic of computer
主讲：刘志强
第 15单元
软件工程概论
下一页
上一页
停止放映
第 2页
教学目标
? 了解软件工程的基本概念
? 掌握软件工程的基本理论, 技术和
方法, 运用于软件的开发和生产
下一页
上一页
停止放映
第 3页
教学内容
? 了解软件, 软件工程的基本概念
– 软件的特征
– 软件危机, 软件工程
– 瀑布模型, 原型模型
– 软件生存周期中各个阶段的任务,
实施方法及步骤
下一页
上一页
停止放映
第 4页
本单元涉及内容
? 概述
– 软件的基本概念
– 软件的发展和软件危机
? 第 9章 软件工程
– 9.1 软件工程
– 9.2 软件生存周期
– 9.3 软件工程管理
下一页
上一页
停止放映
第 5页
一、基本概念
? 软件 计算机系统中所有程序, 数据结构
及有关文档资料的总称 。 软件是计算机
技术和人类智慧高度结合的产物, 软件
开发不是简单, 机械地重复生产, 而是
创造性的脑力劳动 。
? 软件的作用 软件是今后信息产业发展的
推动力 。 美国最近在 24项高科技领域中
调查结果表明, 其中 18项与软件有关 。
下一页
上一页
停止放映
第 6页
软件工程学的体系结构
软件工程学
软件开发技术
软件开发方法学
软件工具
软件工程环境
软件工程管理 软件管理学软件经济学
下一页
上一页
停止放映
第 7页
问题的由来
? 软件内在规律 。任何事物有它自己的客观规律
和发展轨迹。只有认识了它，才能驾驭它。
? 软件地位及作用 。软件是计算机系统中重要的
组成部分。但在早期它并没有引起业界的重视。
随着计算机技术的发展，随着, 软件危机, 的出
现，以及软件危机对社会危害的增大，软件的地
位和作用也越来越重要。
? 软件工程学 。业界人士不得不设置专门的学
科 ——软件工程学来研究软件开发、生产的内在
规律，用于指导现代工程化的软件生产。
下一页
上一页
停止放映
第 8页
软件的特征（ 与硬件产品比较 ）
? 软件是逻辑产品
? 软件产品质量的体现方式不同
? 软件产品的失败曲线不同
? 软件产品的成本构成不同
? 软件产品不存在同类零件替换
? 软件产品的静态和动态属性
下一页
上一页
停止放映
第 9页
软件是逻辑产品
? 软件产品具有产值、价格、质量
和功能的特性，但看不见,是逻辑
的、无形的，是脑力劳动的结晶。
下一页
上一页
停止放映
第 10页
软件产品质量体现方式不同
? 质量体现方式不同：
– 实用、可靠、可操作性；
– 可维护性强
– 方便用户
– 不会折旧、损坏、老化
下一页
上一页
停止放映
第 11页
软、硬件失败曲线
下一页
上一页
停止放映
第 12页
成本构成不同
12%
需求
率
4%
生产率
开发人员
成本构成不同,主要投资在研制；软件研制是一种人力、资金密集
的产业，而软件生产只是简单的复制、安装和培训。
下一页
上一页
停止放映
第 13页
软件产品不存在同类零件替换
? 硬件可更换零部件 。 当硬件产品中某个部
件损坏后, 可以用相同的备用部件更换,
使硬件系统恢复正常工作 。
? 软件不能更换零部件 。 而软件产品却没有
相同的备用部件可言, 因为软件出现的每
一个故障, 要么是由于设计考虑不周造成
的, 要么是编程错误造成的 。 由于软件无
备用部件可供更换, 因而软件维护比硬件
维护要复杂得多,成本也高得多 。
下一页
上一页
停止放映
第 14页
软件产品的静态和动态属性
? 软件是由程序和相关文档资料组成的 。
? 程序是具有双重属性的：
– 交流 。 它是求解客观问题的逻辑描述, 是供阅读和交流
的, 它的表示是静态的；
– 执行 。 程序最终是通过运行去执行特定的操作和数据处
理, 它又具有极其复杂和丰富内涵的动态属性 。
? 程序是否正确的有双重标准：
– 静态的程序正确与否是检查它的语法和句法是否符合规
则要求；
– 动态的程序正确与否则要动态的测试程序的所有逻辑流
结构和数据结构是否正确 。
– 而后一种测试的难度和代价较之前一种要大得多 。
下一页
上一页
停止放映
第 15页
硬件生产率大幅提高
? 如今, 计算机的发展已进入一个新的历史
阶段；
? 硬件产品已系列化, 标准化,, 即插即
用, 。
? 硬件产品的生产可以采用最高精尖的现代
化工具和手段, 自动成批生产 。 生产效率
几百万倍的提高 。
? 生产能力过剩 。
返 回
下一页
上一页
停止放映
第 16页
软件生产率很低
? 伴随计算机的普及，整个社会对计
算机应用的需求越来越大。
? 但软件的生产却还沿用, 手工作坊,
的生产方式，人工编程生产。生产
效率仅提高了几倍。
? 生产能力极其低下。
返 回
下一页
上一页
停止放映
第 17页
硬、软件供需失衡
? 社会大量需求, 生产成本高, 生
产过程控制复杂, 生产效率低等
等因素构成软件生产的恶性循环 。
? 由此产生, 软件危机, 。
返 回
下一页
上一页
停止放映
第 18页
矛盾引发“软件危机”
? 软件危机是指在计算机软件的开发和
维护过程中所遇到的一系列严重问题。
? 为了研究、解决软件危机，诞生了一
门新兴学科 ——软件工程学。它把软
件作为工程对象，从技术措施和组织
管理两个方面来研究、解决软件危机。
下一页
上一页
停止放映
第 19页
软件危机的具体体现
（ 1） 软件开发进度难以预测
（ 2） 软件开发成本难以控制
（ 3） 用户对软件功能难以满足
（ 4） 软件产品质量无法保证
（ 5） 软件产品难以维护
（ 6） 软件缺少文档资料
下一页
上一页
停止放映
第 20页
（ 1）软件开发进度难以预测
? 拖延工期几个月甚至几年的现象并不罕见，这种
现象降低了软件开发组织的信誉。
? 以丹佛新国际机场为例 。 该机场规模是曼哈顿机
场的两倍, 宽为希思机场的 10倍, 可以全天侯同
时起降三架喷气式客机；投资 1.93亿美元建立了
一个地下行李传送系统, 总长 21英里, 有 4,000
台遥控车, 可按不同线路在 20家不同的航空公司
柜台, 登机门和行李领取处之间发送和传递行李；
支持该系统的是 5,000个电子眼, 400台无线电接
受机, 56台条形码扫描仪和 100台计算机 。 按原定
计划要在 1993年万圣节前启用, 但一直到 1994年 6
月, 机场的计划者还无法预测行李系统何时能达
到可使机场开放的稳定程度 。
下一页
上一页
停止放映
第 21页
（ 2）软件开发成本难以控制
? 投资一再追加, 令人难于置信 。 往往是
实际成本比预算成本高出一个数量级 。
? 而为了赶进度和节约成本所采取的一些
权宜之计又往往损害了软件产品的质量,
从而不可避免地会引起用户的不满 。
下一页
上一页
停止放映
第 22页
（ 3）用户对产品功能难以满足
? 开发人员和用户之间很难沟通, 矛盾很
难统一 。 往往是软件开发人员不能真正
了解用户的需求, 而用户又不了解计算
机求解问题的模式和能力, 双方无法用
共同熟悉的语言进行交流和描述 。
? 在双方互不充分了解的情况下, 就仓促
上阵设计系统, 匆忙着手编写程序, 这
种, 闭门造车, 的开发方式必然导致最
终的产品不符合用户的实际需要 。
下一页
上一页
停止放映
第 23页
（ 4）软件产品质量无法保证
? 系统中的错误难以消除 。 软件是逻辑产品,
质量问题很难以统一的标准度量, 因而造
成质量控制困难 。
? 软件产品并不是没有错误, 而是盲目检测
很难发现错误, 而隐藏下来的错误往往是
造成重大事故的隐患 。
下一页
上一页
停止放映
第 24页
（ 5）软件产品难以维护
? 软件产品本质上是开发人员的代码化的
逻辑思维活动, 他人难以替代 。 除非是
开发者本人, 否则很难及时检测, 排除
系统故障 。
? 为使系统适应新的硬件环境, 或根据用
户的需要在原系统中增加一些新的功能,
又有可能增加系统中的错误 。
下一页
上一页
停止放映
第 25页
（ 6）软件缺少适当的文档资料
? 文档资料是软件必不可少的重要组成部分 。
? 实际上, 软件的文档资料是开发组织和用
户的之间权利和义务的 合同书, 是系统管
理者, 总体设计者向开发人员下达的 任务
书, 是系统维护人员的 技术指导手册, 是
用户的 操作说明书 。
? 缺乏必要的文档资料或者文档资料不合格,
将给软件开发和维护带来许多严重的困难
和问题 。
下一页
上一页
停止放映
第 26页
软件生产随规模增大而复杂度增大
? 以美国宇航局的软件系统为例：
– 1963年 水星计划系统 200万条指令
– 1967年 双子星座计划系统 400万条指令
– 1973年 阿波罗计划系统 1000万条指令
– 1979年 哥伦比亚航天飞机系统 4000万条指令
? 假设 1个人一年生产一万条有效指令, 那么是否 4000
人生产一年, 或 400人生产 10年就能完成任务吗？ 答
案是否定的 。 一万条指令的复杂度决不仅仅是 100条
指令复杂度的 100倍 。
下一页
上一页
停止放映
第 27页
典型失败系统的例子
? IBM公司开发 OS/360系统, 共有 4000多
个模块, 约 100万条指令, 投入 5000人
年, 耗资数亿美元, 结果还是延期交付 。
在交付使用后的系统中仍发现大量
（ 2000个以上 ） 的错误 。
下一页
上一页
停止放映
第 28页
软件危机产生的原因
? 产生软件危机有两个方面的原因：
– 内部因素 。 与软件本身的特点有关 。
内在因素是客观的存在, 只能因势利
导加以解决 。
– 外部因素 。 与软件开发和维护的技术
方法有关 。 外部因素是可以完善, 提
高的 。
下一页
上一页
停止放映
第 29页
软件特点的因素
? 软件 是逻辑产品, 是代码化了的人的思维
活动 。 在总体构思时, 别人无法管理和干
预 。 在写出程序, 并在机器上运行之前,
进展情况难以掌握, 开发质量也无法评估 。
这些都给管理和控制带来不便 。
? 软件 是特定问题在计算机上的运行描述 。
实际问题的复杂性决定了一个实用软件系
统规模往往十分庞大 。 程序规模越大, 控
制, 管理难度也就越大 。
下一页
上一页
停止放映
第 30页
软件开发维护技术方法的因素
? 开发人员和用户之间的矛盾 。 许多软件系统开发失
败的主要原因是开发人员在没有准确, 完整地了解
了用户的需求后就急于编程；用户对需求也往往不
能准确, 完整地提出 。
? 软件产品有其生命周期 。 在周期的各个阶段有其具
体的任务, 如何完成任务, 各个阶段有不同的技术
方法和操作步骤 。 只有科学的按生命周期各阶段的
任务去组织实施, 才能保证质量, 降低成本；急于
求成, 不按科学规律, 方法实施, 只能, 事倍功
半,, 事与愿违 。
? 软件产品的使用寿命很长 。 在这期间因功能的增加,
硬件的更新换代, 都要对软件进行必要的修改 。 据
统计数据表明, 软件维护的费用占总费用的 55%~70%。
软件工程的一个重要目标就是提高软件的可维护性,
减少软件维护的代价 。
下一页
上一页
停止放映
第 31页
解决软件危机的途径
? 为了解决软件危机就要从 技术措施 和 组织
管理 两个方面去研究，不断总结经验教训，
提高软件产品的生产效率，降低软件开发和
维护的成本。
? 开发软件选用最好的开发工具是至关重要的，
即选择、设置良好的软件工程支撑环境。工
具选用的好，它可以, 放大, 人的智力，大
大加快软件开发速度，提高软件质量。
下一页
上一页
停止放映
第 32页
软件开发的演变过程
? 程序设计阶段
? 软件设计阶段
? 软件工程阶段
下一页
上一页
停止放映
第 33页
程序设计阶段 （ 1946年 ~1955年）
? 特点：
– 尚无软件的概念, 程序设计主要围绕硬件
进行开发, 规模很小, 工具简单, 无明确
分工 （ 开发者和用户 ）, 程序设计追求节
省空间和编程技巧, 无文档资料 。 主要是
用于科学计算 。
下一页
上一页
停止放映
第 34页
软件设计阶段 （ 1956年 ~1970年）
? 特点：
– 硬件环境相对稳定, 出现, 软件作坊, 的开发组
织形式 。 开始使用产品软件 （ 可购买 ）, 从而建
立了软件的概念 。 系统规模越来越庞大, 高级编
程语言层出不穷, 应用领域不断拓宽, 开发者和
用户有了明确分工, 社会对软件的需求量剧增 。
但是软件开发技术没有重大突破, 生产效率低下,
从而导致, 软件危机, 产生 。
下一页
上一页
停止放映
第 35页
软件工程阶段 （ 1970年 ~至今）
? 由于软件危机的产生, 迫使人们不得不研究, 改变
软件开发的技术手段和管理方法 。 从此软件生产进
入软件工程时代 。
? 特点：
– 硬件已向, 四化, （ 巨型, 微型, 网络, 智能 ）
发展, 数据库技术已成熟并广泛应用, 第三, 四
代语言出现 。
– 第一代软件技术 ——结构化程序设计在数值计算
领域取得优异成绩；
– 第二代软件技术 ——软件测试技术, 方法, 原理
用于软件生产过程；
– 第三代软件技术 ——处理需求定义技术, 用于软
件需求分析和描述 。
下一页
上一页
停止放映
第 36页
二、软件工程
? ―软件工程, 一词是 1968年北大西洋公约组
织的计算机科学家在当时联邦德国召开的
专门讨论解决, 软件危机, 的国际会议上
正式提出并使用的, 并由此诞生了一门新
兴学科 ——软件工程学 。
?, 软件工程学, 是一门交叉学科, 它涉及
计算机科学, 管理科学, 工程学和数学 。
? 计算机科学培养的是计算机科学家, 而 软
件工程 则是培养软件工程师 。
下一页
上一页
停止放映
第 37页
软件工程的目标
? 软件工程的基本目标是：
?开发尽可能多的软件产品；
?提高软件的生产效率；
?满足应用的功能需要；
?降低软件开发成本 。
下一页
上一页
停止放映
第 38页
软件工程的指导思想
? 为解决软件危机, 把, 软件, 这种特殊商
品的生产, 管理过程纳入传统工程管理的
轨道；
– 用计算机科学中的最新成果应用于软件
工程中
– 用管理学的原理和方法进行软件生产管
理
– 用工程学的观点进行核算, 制定工程进
度和实施方案
– 用数学方法建立软件的可靠模型和各种
有效算法
下一页
上一页
停止放映
第 39页
软件工程基本原理
? 自 1968年提出, 软件工程, 的概念以来，
专家学者又陆续突出了 100多条关于软件
工程的准则。
? 著名软件工程专家 B.W.Boehm于 1983年发
表的一篇论文中提出了软件工程的七条基
本原理。他认为这七条原理是确保软件产
品质量和开发效率的最小准则集合。
下一页
上一页
停止放映
第 40页
软件工程七条基本原理
– 用分阶段的生命周期计划严格管理
– 坚持进行阶段评审
– 实行严格的产品控制
– 采用现代程序设计技术
– 结果应能清楚地审查
– 开发小组人员少而精
– 承认不断改进软件工程实践的必要性
下一页
上一页
停止放映
第 41页
用分阶段生命周期计划严格管理
? 在软件的整个生命周期中应该制定并
严格执行六类计划：项目概要, 项目
进度表, 项目控制, 产品控制, 验证
及运行维护计划 。
? 不同层次的管理人员必须严格按照计
划各尽其职地去管理软件开发与维护
工作, 绝不能受客户或上级的影响而
擅自背离预定计划 。
下一页
上一页
停止放映
第 42页
坚持进行阶段评审
? 软件的质量保证工作不能等到编码阶段结束
之后再进行 。 这是因为：
– 大部分错误是在编码之前造成的 （ 根据
Boehm统计, 设计错误占软件错误的 63%，
编码错误占 37%） 。
– 错误发现与改正得越晚, 所付出的代价也
越高 。
因此, 在每个阶段进行严格的评审, 尽早发现
并修正各个阶段中所犯的错误是一条必须遵
循的重要原则 。
下一页
上一页
停止放映
第 43页
示意图关于阶段评审作用
下一页
上一页
停止放映
第 44页
实行严格的产品控制
? 在软件开发过程中不应随意改变需求 （ 改变
一项需求往往要付出很高的代价 ）, 但不能
禁止更改需求 。 当必须修改时, 为了保持软
件各配置成分的一致性, 必须实行严格的产
品控制 （ 主要是实行基准配置管理 ） 。
? 一切有关修改软件的建议 （ 特别是涉及到对
基准配置的修改建议 ） 都必须按照严格的规
程进行评审, 获准后才能实施修改 ） 。
? 绝对不能谁想修改就随意进行修改的行为 。
下一页
上一页
停止放映
第 45页
采用现代程序设计技术
? 以前的结构化程序设计技术, 如今的面
向对象程序设计技术都被实践证明是各
个不同历史阶段的优秀程序设计技术和
方法 。
? 采用先进的技术既可以提高软件开发的
效率, 又可以提高软件维护的效率 。
下一页
上一页
停止放映
第 46页
结果应能清楚地审查
? 软件产品是看不见, 摸不着的逻辑产品,
软件开发人员的工作进展情况可见性差 。
为了提高开发过程的可见性, 应根据软
件开发项目中的目标完成期限, 规定开
发组织的责任和产品标准, 使得到的结
果能够清楚的审查 。
下一页
上一页
停止放映
第 47页
开发小组人员少而精
? 开发小组成员的素质应该高，人员不宜
过多。人员素质和数量是影响产品质量
和开发效率的重要因素。
? 素质高的人开发效率比低的人高几倍甚
至几十倍，而错误则明显得少；
? 人数增加，管理难度也增加。
下一页
上一页
停止放映
第 48页
承认不断改进软件工程实践的必要性
? 要积极主动地采纳新的软件技术,
要不断总结经验；不能自以为是,
固步自封, 唯我独好 。
? 大千世界, 错综复杂, 只有不断学
习, 才能不断进取, 不断进步 。
下一页
上一页
停止放映
第 49页
软件工程应用范围
? 个人程序、中小型或一般程序同
开发人员之间的关联较小，应用
SE方法收效甚微。
? 大型程序要由若干个程序员小组
承担开发，相互关系极其复杂，
因此，必须自始至终坚持 SE方法。
下一页
上一页
停止放映
第 50页
应用程序分类
分类 程序规模 模块数 开发时间 开发人数
极小 500行以下 10~20 1~4周 1人
小 1K~2K行 25~50 1~6月 1人
中 5K~50K行 250~1000 1~2年 2~5人
大 50K~100K行 1000以上 2~3年 5~20人
甚大 1M行 4~5年 100~1000人
极大 1M~10M行 5~10年 2000~5000
下一页
上一页
停止放映
第 51页
传统软件工程模式
? 70年代, 计算机技术水平不高, 开发工具少而且性
能差 。 对于大型复杂问题的求解方法有很大的局限
性影响 。
? 软件工程采用的方法：把软件生存周期划分成若干
个阶段, 每个阶段的任务相对独立, 而且比较简单,
便于不同人员分工协作, 从而降低整个软件开发工
程的困难程度 。
? 在实现每个阶段的任务时, 采用的是系统化的技术
方法 ——结构化分析和结构化设计技术 。
? 传统软件工程模式的缺点,强调 了分阶段实施模块
化, 结构化程序设计技术和方法, 而 忽视 了人在软
件开发过程中的地位和作用 。
下一页
上一页
停止放映
第 52页
现代软件工程模式
? 现代软件工程是在传统软件工程模式的基础上, 为
了强调人在系统开发中的作用, 同时为了适应软件
新技术的发展趋势而提出的 。 其基本要点是：
1,以人为主, 充分利用软件开发方法及软件开发工具；
2,开发人员的组织管理对软件开发成功与否至关重要 ；
3,基于软件组件的软件开发技术 。 各种功能的可重用
软件组件不断问世 。 这使得在软件开发过程中编程
工作量日趋减少, 取而代之的是在设计好系统体系
结构后, 利用软件组件构造或重构软件系统 。
4,由于软件组件是 标准化设计, 成品化生产 的, 极易
构造使用, 从而大大简化了设计, 编程, 测试各个
环节的工作量, 提高了工作效率和生产效率 。
? 由于在软件开发过程中最大限度地采用软件组件,
使得软件开发过程变为系统分析, 系统构造, 系统
测试的集成过程 。
下一页
上一页
停止放映
第 53页
阶段的划分及主要任务
1) 系统分析
2) 系统设计
3) 系统测试
4) 软件组件
5) 系统开发人员的组织管理
下一页
上一页
停止放映
第 54页
系统分析
? 系统分析 从系统需求入手, 从用户观点出发建立系
统用户模型 。 用户模型从概念上全方位表达系统需
求及系统与用户的相互关系 。 系统分析在用户模型
的基础上, 建立适应性强的独立于系统实现环境的
逻辑结构 。
? 分析阶段 独立于系统实现环境, 可以保证建立起来
的系统结构具有相对的稳定性, 便于系统维护, 移
植或扩充 。
? 在 系统分析阶段, 系统的逻辑结构应从以下三方面
全面反映系统的功能与性能：
（ 1） 信息 。 完整描述系统中所处理的全部信息；
（ 2） 行为 。 完全描述系统状态变化所需处理或功能；
（ 3） 表示 。 详细描述系统的对外接口与界面 。
下一页
上一页
停止放映
第 55页
系统设计
? 在系统设计阶段, 首先考虑具体的实现环境 。 在设
计时, 可能会对系统结构作一些调整, 但为了保持系
统结构的稳定性, 应尽可能避免由于实现环境的特定
要求而改变系统结构 。
? 设计, 构造系统的软件组件 。 设计软件组件的主要
内容是定义组件的结构, 功能和外部接口, 以及组件
之间的相互关系和通信方式 。 对于复杂的大系统, 还
可以根据组件之间关联的紧密程度, 将关联密切的多
个组件形成一个子系统, 子系统之间具有松散的耦合 。
? 在系统实现阶段, 对于需要开发的软件组件, 选择
采用某种合适的程序设计语言编写相应的源代码程序,
完成系统实现工作 。
下一页
上一页
停止放映
第 56页
系统测试
? 系统测试包括单元测试, 集成测试和
系统测试 。 就功能而言与传统软件工
程模式中系统测试的功能相同 。
下一页
上一页
停止放映
第 57页
软件组件
? 在现代软件工程的开发过程中, 软件组件只是一
个辅助或支撑系统构造的一个过程 。
? 软件组件开发主要是开发与维护系统构造过程中
用到的组件 。 将软件组件作为一个单独的过程,
目的是将组件作为构造软件的, 零部件, 。
? 随着软件技术的不断发展及软件工程的不断完善,
软件组件将会作为一种独立的软件产品出现在市
场上, 供应用开发人员在构造应用系统时选用 。
下一页
上一页
停止放映
第 58页
系统开发人员的组织管理
? 现代软件工程不仅包括软件开发方法, 工具和过
程, 更强调人在开发过程中的作用 。 一个复杂的
系统开发过程, 涉及到众多的以人为主的各种开
发活动, 通过这些活动的有机配合与协调才能保
证系统开发的成功 。 因此, 系统开发人员的组织
管理是现代软件工程中的重要方面 。
? 组织管理方法有以下几个要点：
① 明确系统开发人员与用户之间的责任与义务；
② 明确各类开发人员的主要工作及责任；
③ 制定或选择工程开发规范 。
下一页
上一页
停止放映
第 59页
三、软件生命周期
? 软件生存周期 指从软件的需求分
析、设计、编程、测试、交付用
户使用到版本升级、或被被自然
淘汰的过程。
? 软件工程的应用模式也称为软件
生存周期模式。通常也称其为
“瀑布模型”（ B.W.Bohem提出
的该模型 )。
下一页
上一页
停止放映
第 60页
⒈ 软件生命周期各个阶段任务
? 需求分析、定义
? 系统总体设计
? 系统编程
? 系统测试
? 系统维护
下一页
上一页
停止放映
第 61页
⑴ 需求分析、定义
? 任务是,收集、分析、理解、确定用户的要求；
然后把用户的要求精确、完整地描述表达出来。
? 目的,要回答“要解决什么问题？”，
既系统” 做什么？“。
? 分两步骤：
– 可行性研究, 制定软件开发计划
– 进行需求分析
? 阶段结果,产生出：
– 可行性报告、软件计划、需求说明书
下一页
上一页
停止放映
第 62页
⑵ 系统总体设计
? 任务是,
– 设计软件系统的模块层次结构
– 模块间逻辑关系、参数
– 每个模块的功能
? 目的：要回答,如何解决该问题？”，
既系统” 怎样做？“。
? 分两步骤：
– 概要设计：解决系统的模块划分、模块的层次
结构及数据库设计。
– 详细设计,解决每个摸块内部算法和数据结构。
? 阶段结果； 产生出：
– 系统设计说明书和模块功能说明书。
下一页
上一页
停止放映
第 63页
⑶ 系统编程
? 任务是,
根据设计说明书中每个模块
的控制流程编出相应的程序。
? 阶段结果,
软件系统的源程序。
下一页
上一页
停止放映
第 64页
⑷ 系统测试
? 任务是：检查、发现程序中的错误，提高软件的可靠
性。回答：,该系统是否能实现规定的操作？”。
? 分三个阶段：
– 模块测试 测试每个模块的程序是否有错；
– 组装测试 测试模块之间的接口是否正确；
– 确认测试 测试整个软件系统是否满足用户功能、性能要求。
? 测试三大基本技术：
– 逻辑覆盖 （白盒法）
– 边值分析 （黑盒法）
– 等价类划分 （黑盒法）
? 阶段结果：测试报告；说明测试数据的选择，测试对
象、测试结果是否符合预期结果等。
下一页
上一页
停止放映
第 65页
⑸ 系统维护
? 任务是：改正软件系统在使用过程中
发现的隐含错误，扩充在使用过程中
的新的功能要求；
? 目的：维护软件系统的正常运行；
? 阶段结果：软件系统的问题报告和软
件修改报告（记录发现软件错误的情
况以及修改软件的过程）。
下一页
上一页
停止放映
第 66页
⒉ 瀑布模型
需求分析 7%
系统设计 6%
软件编程 7%
软件测试 13%
软件维护 67%
用户要求
分析报告
系统设计报告
源程序
测试报告
更改要求
U
A
M A
T
M
M
P
U
T
P U
A
M
P
A 系统分析员
M 项目管理员
P 程序员
T 高级程序员
U 用户
下一页
上一页
停止放映
第 67页
瀑布模型的特点
? 瀑布模型具有 顺序性 和 依赖性,即后一阶
段的工作必须在前一阶段的工作完成后才
能开始。
? 把逻辑设计与物理设计清楚地划分开，是
瀑布模型的重要指导思想。
? 瀑布模型强调的是优质，即每一步都循序
渐进，及早消除隐患，从而保证软件质量。
? 它的 致命缺点 在于只有做出精确的需求分
析，才能取得预期的结果。由于各种客观、
主观的原因，需求分析往往不很精确，常
常给日后的开发带来隐患。
下一页
上一页
停止放映
第 68页
⒊ 原型模型 —— 样品模型
? 原型模型的主要思想：
先借用已有系统作为原型模型，通过,样品,不断改进，
使得最后的产品就是用户所需要的。
? 原形模型的特点：
(1） 开发人员和用户在, 原型, 上达成一致 。 这样一来,
可以减少设计中的错误和开发中的风险, 也减少了对
用户培训的时间, 而提高了系统的实用, 正确性以及
用户的满意程度 。
（ 2） 缩短了开发周期, 加快了工程进度 。
（ 3） 降低成本 。
? 原型模型的缺点：
当告诉用户, 还必须重新生产该产品时, 用户是很难接
受的 。 这往往给工程继续开展带来不利因素 。
下一页
上一页
停止放映
第 69页
快速原型模型
分析原型
样品
模型 设计
编程
测试
使用
修改
与
改进
在系统分析与
设计中，采用
交互式，反复
修改与不断改
进的方式进行。
还有的把原型模式嵌套在瀑布模型中运用。
下一页
上一页
停止放映
第 70页
⒋ 螺旋模型
? 螺旋模型将工程划分为 4个主要活动：制定计划,
风险分析, 实现工程和用户评价 。 4个活动螺旋
式地重复执行, 直到最终得到用户认可的产品 。
① 制定计划,确定软件目标,选定实施方案,弄清项
目开发限制条件 。
② 风险分析,分析可选方案,分析识别风险,研究解决
化解风险的办法 。
② 实现工程,实施软件产品的开发 。
③ 用户评价,对当前工作结果进行评价, 提出改进
产品的建议 。
螺旋模型的缺点,很难让用户确信这种演化方法的结
果是可以控制的,
下一页
上一页
停止放映
第 71页
⒌ 其他模型
? 智能模型 也称基于知识的软件开发模型，它与专
家系统结合在一起。该模型应用基于规则的系统，
采用归纳和推理机制，帮助软件人员完成开发工
作，并使维护在系统规格说明一级进行。
? 该模型在实施过程中要建立知识库，将模型本身、
软件工程知识与特定领域的知识分别存人数据库。
以软件工程知识为基础的生成规则构成的专家系
统与含应用领域知识规则的其他专家系统相结合，
构成这一应用领域软件的开发系统。
? 面向对象生存周期模型 其 主导思想是：在整
个软件开发过程中将面向对象技术贯穿于整个生
存周期。当然，还要结合传统开发模式中好的、
已被无数成功开发活动证明是可行的经验和技术 。
下一页
上一页
停止放映
第 72页
四、软件工程管理
1,软件工程项目管理的任务
2,软件人员组织与管理
3,软件配置管理
4,软件知识产权保护
下一页
上一页
停止放映
第 73页
⒈ 软件工程项目管理的任务
? 软件工程项目管理所涉及的范围覆盖了整个软件
工程过程 。 它管理的任务是：根据项目合同书的
要求, 制定项目计划和工程进度安排, 监督和检
查项目实施过程, 保证工程满足要求的质量标准,
分析确定并排除风险, 在规定的期限和预算成本
内完成项目 。 包括：
项目计划和进度安排
项目追踪和质量保证
成本估算
风险分析
下一页
上一页
停止放映
第 74页
① 项目计划和进度安排
? 项目计划要列出软件开发要做的主要工作和任务
清单, 要回答, 软件工程项目做什么, 。
? 在工作和任务清单中要清楚地描述出：
– 项目划分的各个实施阶段
– 每个阶段的工作重点和任务是什么
– 完成本阶段工作和任务的人力, 资源需求,
时间期限
– 阶段工作和任务的成果形式
– 项目实施过程中对风险, 疑难, 其他不可预
见因素等的处理机制
– 各任务组及开发人员之间的组织, 协调关系
等 。
下一页
上一页
停止放映
第 75页
进度安排
? 在制定项目进度安排时，主要依据是合同书
和项目计划。通常的做法是把复杂的整体项
目分解成许多可以准确描述、度量、可独立
操作的相对简单的任务，然后安排这些任务
的执行顺序，确定每个任务的完成期限、开
始时间和结束时间。
? 开始需要考虑的主要问题是：
– 项目可以支配的人力及资源
– 项目的关键路径
– 生存周期各个阶段工作量的划分
– 工程进展如何度量
– 各个阶段任务完成标志
– 如何自然过渡到下一阶段的任务等。
下一页
上一页
停止放映
第 76页
② 项目追踪和质量保证
? 项目追踪实施由项目管理人员负责 。 他们必须按
进度安排表追踪检查每一个任务 。 如果任务实际
完成日期滞后于进度安排, 则管理人员可以行使
职权范围内的权力 采取各种补救措施以减少进度
误期所造成的影响 。 包括对资源重新定向, 对任
务重新安排, 甚至可以修改交付日期以调整已经
暴露的问题 。
? 质量保证在软件生存周期中是至关重要的 。 人们
在管理项目时往往只强调必须按期完成任务, 必
须遵循进度计划, 必须把成本控制在预算范围内,
却忽视了在生存周期各个阶段工作和任务应满足
规定的质量标准 。
下一页
上一页
停止放映
第 77页
软件质量主要因素包括
正确性 在预定的系统环境下能正确地完成预期的功能；
健壮性 在预定意外环境下系统能适当地给予预期的响应；
完整性 对未经授权的操作, 系统能够进行控制；
可用性 系统在完成预定任务的功能时能够圆满地实现；
灵活性 系统应能满足硬件环境升级和部分功能扩充需求；
可理解性 用户和维护人员应非常容易的理解和使用系统；
可维护性 用户按文档资料应能排除常见系统故障, 保持
系统正常运行；
可移植性 在厂家协助下, 系统可以移植到其他硬件环境
且费用可以接受；
可重用性 系统全部或部分代码可以在其他应用系统中被
使用；
可测试性 系统容易测试 。
下一页
上一页
停止放映
第 78页
保证软件质量的措施
? 为了保证软件质量，在软件开发过
程中应采取下列措施：
（ 1） 审查
（ 2） 复查和管理复查
（ 3） 测试
下一页
上一页
停止放映
第 79页
审查
? 在软件生存期各个阶段结束之前，都要对该阶段产
生的结果和软件配置文档进行严格技术审查。
? 审查过程包括：
① 计划：组织审查组、分发材料等；
② 概况介绍：对大的项目，让主程序员介绍概况；
③ 准备：评审员阅读材料，取得项目有关知识；
④ 评审会：目的是发现和记录错误；
⑤ 返工：开发者修改已经发现的问题；
⑥ 复查：检查返工是否真正解决了问题。
下一页
上一页
停止放映
第 80页
复查和管理复查
? 复查是检查已有的材料, 以断定本阶段
的工作是否能够开始或继续 。 每个阶段
开始时的复查是为了肯定前一个阶段结
束时确实进行了认真的复查, 已经具备
了开始当前阶段工作所必须的材料 。
? 管理复查是指：向开发组织或使用部门
的管理人员提供有关项目的总体状况以
及进度等方面的情况, 以便他们从管理
的角度对开发工作进行审查 。
下一页
上一页
停止放映
第 81页
测试
? 测试是用测试用例执行系统, 以检查测试结
果是否和预期结果一致 。
? 在测试过程中将产生以下文档,
① 测试计划,确定测试范围, 方法, 测试用例
和所需资源等；
② 测试过程,详细描述与每个测试方案有关的
测试步骤和数据 （ 包括测试预期结果 ） ;
③ 测试结果,把每次测试运行的结果归入文档,
如果运行出错, 则应产生问题报告, 并且要
通过调试解决所发现的问题 。
下一页
上一页
停止放映
第 82页
③ 成本估算
? 成本估算和成本管理是软件项目管理的核心任务
之一 。 在制定项目计划时, 就必须对项目需要的
人力及其他资源, 项目持续时间和项目成本做出
估算 。 如果新项目和以往的项目类似, 估算可以
参考以前的成本费用 。
? 现在已有一些用于软件成本估算的技术可供借鉴 。
这些估算技术各有其优缺点, 但以下几方面是共
同的：
– 事先建立软件的工作范围；
– 以软件度量 （ 经验度量, 相似工程类比的度
量 ） 为基础做出估算
– 把项目分解为可单独进行估算的小块
下一页
上一页
停止放映
第 83页
成本估算方法
? 就方法论而言, 有两种基本的成本估算方法：自
顶向下和自底向上 。
? 自顶向下法是对整个工程项目的总开发时间和总
工作量做出估算, 然后将它们按阶段, 步骤和任
务进行分配 。
? 自底向上法则正好相反, 先分别估算各个任务所
需要的工作量和开发时间, 再相加, 从而得到总
的工作量和总的开发时间 。 这两种方法都要求采
用某种方法做出估算 。
? 有许多估算方法可以利用, 大致划分为三类：专
家估算法, 类推估算法, 算式估算法 。
下一页
上一页
停止放映
第 84页
成本估算方法简介
? 专家估算法 依靠一个或多个专家对项目做出估算,
其精度主要取决于专家对估算项目的定性参数的了
解和他们的经验 。
? 类推估算法 在自顶向下法中, 类推估算法将估算
项目的总体参数与类似项目进行直接比较得到结果；
在自底向上法中, 类推是在两个具有相似条件的工
作单元之间进行 。
? 算式估算法 前两种估算法的缺点在于：它们依靠
的是带有主观猜测和盲目性的估算方法 。 算式估算
法则是企图避免主观因素影响的一种方法 。 算式估
算法有两种基本类型：由理论导出的算法和由经验
得出的算法 。
下一页
上一页
停止放映
第 85页
④ 风险分析
? 在开发新的软件系统过程中, 由于存
在许多不确定因素, 软件开发失败的
风险是客观存在的 。 因此, 风险分析
对于软件项目管理是决定性的 。 风险
分析实际上就是贯穿在软件工程过程
中的一系列风险管理步骤, 其中包括：
风险识别, 风险估计, 风险管理策略,
风险解决和风险监督等 。
下一页
上一页
停止放映
第 86页
主要风险因素
① 产品大小 。实践经验表明项目风险和产品的大小
成正比。公认产品大小度量单位是以代码行或功能
点计。
② 技术相关。 未曾使用过的新技术都存在风险。包
括未使用过的新型硬件、支持软件，缺乏标准与规
范的非传统的开发方法等。技术过时也是风险。技
术风险一般难于改正。
③ 开发环境 。适用的开发工具不足、不可靠、使用
不方便等因素，都会降低开发效率。
④ 组织规模和人员经验 。
⑤ 客户因素 。表现在客户需求经常矛盾，不了解客
户的特殊需要，客户不了解项目中采用的新技术，
且双方又难于沟通等。
下一页
上一页
停止放映
第 87页
⒉ 软件人员组织与管理
? 人员是软件工程项目最重要, 也是
最为活跃的资源因素 。 如何组织得
更加合理, 如何管理得更加有效,
从而最大限度地发挥这一重要的资
源潜力, 对于成功地完成软件工程
项目至关重要 。
1) 项目组的组织结构
2) 程序设计小组的组织形式
3) 软件项目的管理
下一页
上一页
停止放映
第 88页
⑴ 项目组的组织结构
? 开发组织采用什么形式, 要针对软件项目的特
点来决定, 同时也与参加人员的素质有关 。
? 建立项目组织时要考虑这样一些原则：
① 项目责任制度 。 项目必须实行项目负责人责
任制 。 项目责任人对项目的完成负全部责任 。
② 人员少而精 。 项目组成员之间的交流和协作
是项目成败的关键 。 人员少, 具有便于组织
管理, 合理分工, 减少通信等优点；人员精,
有利于互相激励, 发挥各自的特长优势, 提
高工作效率 。
下一页
上一页
停止放映
第 89页
选择组织结构的模式
（ 1） 按课题划分 按课题划分小组 。 小组成员自始至终参加
所承担课题的各项任务 。
（ 2） 按职能划分 按任务的工作阶段划分成若干个专业小组 。
例如, 分别建立计划组, 需求分析组, 设计组, 实现组,
测试组, 质量保证组, 维护组等 。 要开发的软件产品在每
个专业小组完成阶段加工后, 沿工序流水线向下传递 。 这
种流水线模式便于小组人员熟悉本组的工作, 进而变成这
方面的专家 。 但也有小组之间的通信接口增多, 通信路径
延长等问题 。
（ 3） 矩阵形模式 这种模式实际上是以上两种模式的结合 。
既设立项目经理负责项目的管理, 又成立一些专门组, 每
个成员参加其中一个组的实际工作 。 矩阵形结构组织的优
点是：参加专门组的成员可在组内交流其在各项目中取得
的经验, 这更有利于发挥专业人员的作用 。 而且各个项目
有专人负责, 有利于项目的完成 。
下一页
上一页
停止放映
第 90页
⑵ 程序设计小组的组织形式
? 一般情况下, 程序设计人员是在一定
程度上独立自主地完成各自的任务 。
但这并不意味着互相之间没有联系 。
事实上, 人员之间联系得多少和联系
方式与生产效率直接相关 。
? 程序设计小组内人数少, 如 2～ 3人,
则人员之间的联系比较简单 。 但随着
人数的增加, 相互之间的联系是按非
线性关系变得复杂起来 。 因此, 小组
内部人员的组织形式对生产率也有很
大的影响 。
下一页
上一页
停止放映
第 91页
① 主程序员组
? 组由主程序员, 程序员和后援工程师为核心组成 。
? 主程序员 是经验丰富能力强的高级程序员, 负责小组全部
技术活动的计划, 协调与审查工作, 还负责设计和实现项
目中的关键部分 。
? 后援工程师 协助和支持主程序员的工作, 为主程序员提供
咨询, 也做部分分析, 设计和实现的工作, 并在必要时代
替主程序员工作, 以便使项目能继续进行 。
? 程序员 负责项目的具体分析与开发, 以及文档资料的编写
工作 。 根据系统规模大小及难易程度, 小组还可以聘请一
些专家, 辅助人员, 软件资料员协助工作 。
? 主程序员组这种集中领导的组织形式突出了主程序员的领
导作用, 简化了人际通信 。 这种组织形式能否取得好的效
果, 很大程度上取决于主程序员的技术水平和管理才能 。
美国的软件产业中大多采用主程序员组的组织形式 。
下一页
上一页
停止放映
第 92页
② 民主小组
? 小组由经验丰富的技术人员组成 。 项目有关的所
有重大决策都由全体成员集体讨论, 确定解决 。
这种组织形式强调发挥每个成员的积极性, 要求
每个成员充分发挥主动精神和协作精神 。 通过充
分讨论, 也是在互相学习, 因而在组内形成一个
良好合作的工作气氛 。 但有时也会因此削弱个人
的责任心和必要的权威作用 。 有人认为这种组织
形式适合于研制时间长, 开发难度大的项目 。
? 日本软件产业中大多采用这种组织形式, 取得较
好的效果 。 这种组织形式在强调发挥每个成员的
积极性的同时, 也创造了一个尊重每个成员的良
好工作环境 。 由于小组成员在工作上能够很好地
配合, 因而做到了较长时间稳定的人员合作关系 。
这样的小组形式避免了美国因软件人员频繁流动
对工作造成的严重干扰 。
下一页
上一页
停止放映
第 93页
③ 层次小组
? 小组内人员分为 3级：组长, 高级程序员
和程序员 。
? 组长 负责全组工作, 包括任务分配, 技
术评审和复查, 掌握工作量和参加技术
活动 。 组长直接领导 2至 3名高级程序员 。
? 高级程序员 通过基层小组, 管理若干个
程序员 。 这种组织结构只允许必要的人
际通信 。 它比较适合项目本身就是层次
结构状的课题以及大型软件项目的开发 。
下一页
上一页
停止放映
第 94页
⑶ 软件项目的管理
? 软件项目管理包括项目指导和项目检验 。
? 指导的目的是在软件项目的实施过程中, 动
员和促进工作人员积极完成所分配的任务 。
? 检验是软件管理的最后一个方面 。 它是对照
计划检查执行情况的过程, 同时也是对照软
件工程标准检查实施情况的过程 。 在发现项
目的实施与计划或标准有较大的偏离时, 应
采取措施加以解决 。
? 管理内容包括：
指导工作的要点
检验管理的要点
检验管理的工作范围
下一页
上一页
停止放映
第 95页
指导工作的要点
① 鼓励 。 恰当而且及时地鼓励是非常重要的 。 要
建立健全竞争和激励机制, 它可使人们充满信心,
勇于继续克服困难, 愿意努力进一步提高工作效
率, 迎接新任务的挑战 。
② 引导 。 通常, 人们愿意追随那些能够体谅个人
要求或实际困难的领导 。 高明的领导人应能体察
到这些, 并能巧妙地把个人的要求和目标与项目
工作的整体目标结合起来, 至少应能做到在一定
程度上的协调, 或在一个工作周期内一致 。 要制
定相对优惠的, 留人, 政策, 稳定骨干队伍 。 从
风险分析中可知, 大幅度的人员调整是非常有害
的, 即使是人员的临时观念也会使项目付出无形
的代价, 因而蒙受无谓的损失 。
下一页
上一页
停止放映
第 96页
检验管理的要点
① 重大偏离 。 在软件项目实施过程中, 必须注
意：工作与计划之间, 任务与标准之间的重
大偏离 。 遇到有这种情况时应及时向管理部
门报告并采取相应的措施给予适当的处置 。
② 选定标准 。 检验管理需要事先确定应当遵循
的标准, 使得软件项目的工作进展可以用某
些客观, 精确且有实际意义的标准加以衡量 。
③ 特殊情况 。 管理人员必须注意软件项目实施
的一些特殊情况, 认真分析其中的一些特殊
问题, 加以解决 。
下一页
上一页
停止放映
第 97页
检验管理的工作范围
? 检验管理可能涉及到以下几个方面：
① 质量管理 。 包括明确度量软件质量的因素
和准则, 决定质量管理的方法和工具, 以
及实施质量管理的组织形式 。
② 进度管理 。 检验进度计划执行的情况 。
③ 成本管理 。 度量并控制软件项目的开销 。
④ 文档管理 。 检验文档编写是否符合要求 。
⑤ 配置管理 。 检验, 控制软件配置项的变更 。
下一页
上一页
停止放映
第 98页
⒊ 软件配置管理
? 软件配置管理是人们在软件工程实
践过程中总结出的一套管理办法和
原则 。 软件配置管理将伴随整个软
件生存周期 。
1) 软件配置管理和基线
2) 配置管理的任务
下一页
上一页
停止放映
第 99页
⑴ 软件配置管理和基线
? 什么是软件配置项？ 一般认为：软件生存周
期各个阶段活动的产物经审批后即可称之为
软件配置项 。
? 软件配置项包括：
① 与合同, 过程, 计划和产品有关的文档和
资料；
② 源代码, 目标代码和可执行代码；
③ 相关产品, 包括软件工具, 库内的可重用
软件, 外购软件及顾客提供的软件等 。
下一页
上一页
停止放映
第 100页
基线
? 什么是基线？ 第一次提出的软件配置项就构成基线配置
项 。 基线分类列表如下：
– 系统功能说明 。 系统模型, 项目计划, 进度安排；
– 软件需求规格说明 。 包括：图形分析模型, 过程, 原型, 数学
规格说明；
– 设计规格说明 。 包括：数据设计, 体系结构设计, 界面设计,
对象的描述等；验收规格说明；
– 测试规格说明 。 包括：测试计划, 测试用例, 测试预期结果,
测试记录等；
– 数据库描述 。 包括：数据模式, 记录结构, 数据项描述；
– 模块规格说明 。 包括：模块功能, 模块算法, 模块接口等描述；
– 运行系统 。 包括：模块代码, 链接模块, 数据库, 支持及工具
程序等；
– 用户文档 。 包括：安装说明, 操作说明, 用户手册等；培训计
划；维护文档, 包括：故障报告, 维护要求, 更改记录等；
– 项目采用的有关标准和规程 。
下一页
上一页
停止放映
第 101页
⑵ 配置管理的任务
① 标识软件配置项
② 版本控制
③ 变更管理
④ 审计
下一页
上一页
停止放映
第 102页
① 标识软件配置项
? 大型软件工程项目开发过程中可能会产生许多技
术文档 。 随着软件系统的变更, 有关文档也将发
生变化 。 因此, 对软件配置项的管理是一个动态
管理的过程 。 为了便于管理, 首先要便于检索 。
而要检索就必须对所有的配置项进行标识, 命名 。
标识软件配置项是配置项管理的重要基础工作 。
? 所有的软件配置项均可以当作对象来标识 。 例如,
基本对象可以是一段需求规格说明, 一个模块的
源代码清单, 一组测试用例等 。 将这些正文单元
命名后作为基本对象, 再将基本对象按内部逻辑
进行组合, 就形成复合对象 。 复合对象表示的是
一本设计规格说明书, 一个完整的源程序清单 。
下一页
上一页
停止放映
第 103页
② 版本控制
? 版本更新是软件生存期中的自然现象 。 软件系统每
做一次修改, 就应该变更一次版本 。 不同版本反映
的是不同时期, 不同硬件环境, 不同用户需求的该
软件系统的特定功能 。 为了保持该软件系统一脉相
承的完整性, 每一个软件配置项修改后的以前版本
都要保留 。
? 版本更新就好像一棵生长的树 。 所有版本均按版本
模型 （ 树形结构 ） 存放于仓储库中 。 为节省仓储库
的存储空间, 版本存放采用增量法, 即只存放新版
本与旧版本不同部分的内容 。
下一页
上一页
停止放映
第 104页
③ 变更管理
? 有变更的需求就要有变更的控制和
管理 。 它的主要任务包括：
1,分析变更的必要性和合理性, 确
定是否实施变更；
2,记录变更信息, 填写变更控制单；
3,做出更改, 并交上级审批；
4,修改相应的软件配置项 （ 基线 ）,
确立新的版本；
5,评审后发布新版本 。
下一页
上一页
停止放映
第 105页
④ 审计
? 软件配置项的更改反映了用户提高, 扩充软件系
统功能和性能的要求以及软件开发人员对软件需
求定义的认识的提高 。
? 如何保证变更需求和变更实施结果的一致性？ 如
何保证任何一个变更能顺利正确地完成？ 这正是
审计的作用 。 为保证软件配置项变更的合理性和
严肃性, 必须实行严格的审计控制 。
? 一般采用两种方法进行审计：
– 正式技术评审 着重检查对软件配置项的变更
的技术正确性 。 综合考虑此软件配置项的变更
对其它配置项乃至整个软件系统的潜在影响和
作用 。
– 软件配置审核 是审核变更的落实情况；变更
修改是否完成？ 变更手续是否完备？ 变更修改
有无违反标准？
下一页
上一页
停止放映
第 106页
⒋ 软件知识产权保护
? 计算机软件是人类知识, 智慧和创造性劳动的结晶, 软件
产业是知识和资金密集型的新兴产业 。 由于它具有开发工
作量大, 周期长, 而生产 （ 复制 ） 容易, 费用低等特点,
因此, 长期以来, 软件的知识产权得不到尊重, 软件的真
正价值得不到承认, 靠非法窃取他人软件而牟取商业利益
成了信息产业中投机者的一条捷径 。 因此, 软件产权保护
已成为急待解决的一个社会问题, 是我国软件产业健康发
展的前提 。
? 1967年在瑞典斯得哥而摩成立了世界知识产权组织 。 1980
年我国正式加入该组织 。 1990年 9月我国颁布了, 著作权
法,, 确定计算机软件为保护的对象 。 1991年 6月由国务
院正式颁布了我国, 计算机软件保护条例, 。
? 应该学习并掌握必要的软件保护法律知识 。 一方面要尊重
别人的智力劳动成果, 不应任意侵犯他人的软件版权；另
一方面要采取切实的保护措施保护自己以及本单位开发的
软件成果 。
下一页
上一页
停止放映
第 107页
⑴ 软件知识产权的法律保护
? 知识产权 又称为智力成果产权和智慧财产权, 是指对智力
活动所创造的精神财富所享有的权利 。
? 知识产权分为：工业产权和版权；前者主要包括专利权, 商标
专有权和制止不正当竞争权；后者专指计算机软件 。
? 知识产权的主要特点是：
① 无形性 。 是指其保护对象是无形的 。 知识产权的权利人只
有当其主张自己权利的时候, 才能确认为权利人 。
② 专有性 。 指未经知识产权人的同意, 除法律有规定的情况
外, 他人不得占有或使用该项智力成果 。
③ 地域性 。 指法律保护知识产权的有效地区范围 。 任何国家
法律所确认的知识产权, 只在其本国领域内有效, 除非该
国与他国签订有双边协定或该国参加了有关知识产权保护
的国际公约 。
④ 时间性 。 指法律保护知识产权的有效期限, 期限届满即丧
失效力 。 这是为限制权利人不致因自己对其智力成果的垄
断期过长而阻碍社会经济, 文化和科学事业的发展 。
下一页
上一页
停止放映
第 108页
⑵ 计算机软件是著作权保护的客体
① 软件著作权保护的基本条件 对计算机软件来说, 著作权法并
不要求软件达到某个较高的技术水平, 只要是开发者独立地自
行开发的软件, 即可享有著作权 。 一个仅处于作者构思过程中,
未表现出来的软件, 不享有著作权 。 一个软件必须在其创作出
来, 并固定在某种有形物体 （ 如纸, 磁带, 磁盘 ） 上面, 能为
他人感知, 传播, 复制的情况下, 才能享有著作权保护 。
② 软件著作权的特征 计算机软件的体现形式是程序和文件 。 文
件是受著作权法保护的 （ 包括：人无法识别的目标代码 ） 形式
的程序, 固化在只读存储器 （ ROM） 中的程序等 ） 。
③ 软件著作权的保护范围 著作权法的基本原则是：只保护作品
的表现, 而不保护作品中所体现的思想, 概念 。 因此, 在软件
中哪些是思想, 概念？ 哪些是表现？ 要确定著作权保护客体的
范围是比较困难的 。 目前人们比较一致的认为：软件的功能目
标应用属于思想, 概念, 不受著作权法的保护；而软件的程序
代码则是表现, 应属于著作权保护的客体之内 。
下一页
上一页
停止放映
第 109页
⑶ 软件著作权人享有的专有权力
? 根据我国著作权法的规定, 作品著作人 （ 或
称版权人 ） 享有５项专有权力：
① 发表权 。 决定作品是否公布于众的权力 。
② 署名权 。 表明作者身份, 在作品上有署名权 。
③ 修改权 。 修改或授权他人修改作品的权力 。
④ 保护作品完整权 。 保护作品不受篡改的权力 。
⑤ 使用权和获得报酬权 。 以复制, 表演, 播放,
展览, 发行, 摄制电影, 电视, 录像或改编,
翻译, 注释, 编辑等方式使用作品的权力,
以及许可他人以上述方式作为作品, 并由此
获得报酬的权力 。
下一页
上一页
停止放映
第 110页
⑷ 软件著作权的登记
?, 计算机软件保护条例, 中对办理软件著作权登记
有以下基本要求：
① 凡完成开发一年之内的软件均可向软件登记机
构办理登记申请 。
② 凡已在软件登记机构办理登记的软件, 在其专
有权力发生转让活动时, 受让方应在转让合同
正式签订后的两个月之内向软件登记机构备案 。
③ 当国籍或定居地为中国的著作权人或其受让者,
在中国境内开发的计算机软件的专有权力要向
境外许可或转让时, 许可方或转让方应首先报
请国务院有关主管部门批准, 并向软件登记机
构备案 。
下一页
上一页
停止放映
第 111页
⑸ 办理软件著作权登记的基本要求：
① 办理软件著作权和软件著作转让或许可的登记, 备案手续, 应
当到法定的或国家指定的软件登记机构办理 。
② 办理上述登记手续应当是软件专有权人 （ 包括公民, 法人或非
法人组织 ） 或者是软件专有权人委托的代理人 。 但代理人须向
软件登记管理机构出示写明委托权限的委托书 。
③ 通常一个独立的软件, 只能办理一次著作权的登记 。 若软件是
由多个独立的软件组成的, 也可以分别办理软件著作权的登记
手续 。
④ 办理软件著作权登记均应以书面的形式进行 。 在软件申请书
（ 登记表 ） 上应有申请者或代理人的签章 。
⑤ 办理软件著作权登记时, 申请者应提交该软件具有独创性事实
和转让, 许可证明等有关鉴别材料 。
⑥ 对于软件登记申请中出现的有关问题和遗漏, 软件申请者应积
极配合软件登记机构予以纠正 。
⑦ 所办理的软件登记手续, 均应在法定的期限内完成, 否则将失
去机会 。
⑧ 办理登记手续时, 应交纳法定的手续费 。
下一页
上一页
停止放映
第 112页
思考题
第 9章习题：
1~24
下一页
上一页
停止放映
第 113页
第 10周上机安排
班级 日期 时间 机房
电气 93 星期一 14～ 18,00 302
电气 92 星期一 14～ 18,00 302
电气 91 星期一 18～ 22,00 302
电气 94 星期四 18～ 22,00 302
电气 95 星期五 18～ 22,00 302
应化 01 星期四 18～ 22,00 302
应物 91 星期五 18～ 22,00 302
下一页
上一页
停止放映
第 114页
结束语
? 欢迎参加到中心网站, 软件基础, 课程的学习讨
论中来。
? 中心网址：
http,//ctec.xjtu.edu.cn
? 课件下载地址,
ftp,//ctec.xjtu.edu.cn
? 我的 E-mail地址,
LZQ_2668634@263.net
谢谢！
