软件工程 第十一章
合集下载
[计算机软件技术基础(第三版)麦中凡 苗明川 何玉洁]第十一章_软件开发与软件维护
![[计算机软件技术基础(第三版)麦中凡 苗明川 何玉洁]第十一章_软件开发与软件维护](https://img.taocdn.com/s3/m/37950616c5da50e2524d7fce.png)
返回
20
一个圈就是一个过程/函数，可退化为一 个语句，也可再分解为一个子DFD图，出入的数
据流不变。 返回
21
控制流图
扩充DFD图为CFD(Control Flow Diagram)图，把控制动作以虚 线表示，非控制动作仍如DFD图。大圆圈依然是处理功能，虚箭头上 标明控制项(或事件)名。同样，平行虚线表示控制项存储(图11.14中 未示出)，竖线条表示控制(规格)说明，即系统的行为。下面是复印 机的控制流图。
返回
15
状态图(State)
状态图描述某个对象实体因事件改变其状态，也就是行 为的综合快照，即在什么事件驱使下状态有什么改变。在需求 分析和设计中可以帮助找出遗漏和不太明确的功能(事例)。例 如旅店系统中的客房，用RoomState类来描述客房状态，则用 状态图对它建模，如图11.10所示。
返回
返回软件需求的目标是把用户的“需要”变成系统开发 的“需求”，或称需求规范。这个工作大体上分三 步：收集用户、市场、公司对本项目的需要；经过 分析建立解题模型；细化模型，抽取需求。请注意， 这个需求每一条都是系统测试的验收准则，所以模 型要细化到能写出可验收需求的程度，决不能太笼 统，如“开发一个办公室系统要灵活、方便好用。” 就不是一个好的需求，因为它既不能指导开发，也 无法验收。好的需求具有众多特点，归纳下来主要 有：一致的，完整的，可理解的，无二异的，和可 测试的。
返回
17
活动图(activity)
在分析和设计时，UML的活动图十分有用。它把传统的流 程图(Flowchart，只描述程序的动作步骤)和数据流图(DFD，只 描述动作后输入/输出数据的改变，不看步骤先后)结合在一起。 活动图既有控制流(顺序、分支、循环)又有数据流(每个动作点 前后数据变化)，增加了数据、动作的同步分支，并且给每个对 象一个泳道，清晰地描述了对象间数据传递。较粗的活动图用于 分析，在设计时细化。在下节给出例子。
《软件工程》教学教案
《软件工程》教学教案一、第一章：软件工程概述1. 教学目标了解软件工程的定义、目的和重要性，掌握软件开发的基本过程和原则。
2. 教学内容软件工程的定义和重要性；软件开发的基本过程；软件工程的原则和方法。
3. 教学方法采用讲授法，结合案例分析，让学生了解和掌握软件工程的基本概念和原则。
4. 教学资源教材、课件、案例分析。
5. 教学评价通过课堂提问和案例分析，评估学生对软件工程的理解和应用能力。
二、第二章：软件需求分析1. 教学目标掌握软件需求分析的基本概念、方法和过程，能够运用需求分析工具进行需求收集和分析。
2. 教学内容软件需求分析的基本概念；需求分析的方法和过程；需求分析工具的使用。
3. 教学方法采用讲授法和实例分析，让学生了解和掌握需求分析的方法和过程。
4. 教学资源教材、课件、实例分析。
5. 教学评价通过课堂提问和实例分析，评估学生对需求分析的理解和应用能力。
三、第三章：软件设计1. 教学目标掌握软件设计的基本概念、方法和过程，能够运用设计工具进行软件架构和详细设计。
2. 教学内容软件设计的基本概念；设计方法和过程；设计工具的使用。
3. 教学方法采用讲授法和实例分析，让学生了解和掌握软件设计的方法和过程。
4. 教学资源教材、课件、实例分析。
5. 教学评价通过课堂提问和实例分析，评估学生对软件设计的理解和应用能力。
四、第四章：软件实现1. 教学目标掌握软件实现的基本概念、方法和过程，能够运用编程语言进行软件编码和测试。
2. 教学内容软件实现的基本概念；实现方法和过程；编程语言和测试工具的使用。
3. 教学方法采用讲授法和编程实践，让学生了解和掌握软件实现的方法和过程。
4. 教学资源教材、课件、编程环境和测试工具。
5. 教学评价通过编程实践和测试结果，评估学生对软件实现的理解和应用能力。
五、第五章：软件维护1. 教学目标掌握软件维护的基本概念、方法和过程，能够进行软件维护和优化。
2. 教学内容软件维护的基本概念；维护方法和过程；软件优化技巧。
软件工程第十一章面向对象设计
THANKS
感谢观看
01
抽象类是一种不能被实例化的 类，它只能被其他类继承。
02
抽象类可以包含抽象方法和具 体方法。抽象方法是没有具体 实现的方法，需要在继承抽象 类的子类中实现。
03
通过继承抽象类，子类可以继 承抽象类的属性和方法，并且 可以重写或实现抽象类中的方 法。
接口与抽象类的选择
在设计软件时，选择使用接口还是抽象类取决于具体需求和设计目标。
关系
关系描述了对象之间的交互和联系。 常见的关系包括关联、聚合和继承。
继承与多态的设计
继承
继承是一种实现代码重用的方式，子类可以继承父类的属性和方法，并可以扩展或覆盖它们。通过继承，可以建 立类之间的层次结构，使得代码更加清晰和易于维护。
多态
多态是指一个接口可以有多种实现方式，或者一个对象可以有多种形态。多态可以提高代码的灵活性和可扩展性， 使得程序更加易于维护和修改。
02
类与对象的设计
类的定义与属性
类的定义
类是对象的抽象，它描述了一组具有相同属性和行为的对象。类定义了对象的结构、行为和关系。
属性
属性是类中用于描述对象状态的变量。每个对象都有其自己的属性值，这些属性值决定了对象的状态 。
对象的行为与关系
行为
行为是类中定义的方法，用于描述对 象可以执行的操作。方法定义了对象 的行为和功能。
高层模块不应该依赖于低层模块，它们都应 该依赖于抽象。
面向对象设计的优势
提高代码可重用性
通过类和继承实现代码重用，减少重 复代码。
提高代码可维护性
面向对象设计使得代码结构更加清晰， 易于理解和维护。
提高开发效率
通过快速原型开发，快速构建软件系 统。
《软件工程》教学课件 第11章 软件项目管理
式为组织型、半独立型或嵌入型。
下 表 是 根 据 63 个 项 目 的 数 据 统 计 结 果 ， 按 照 基 本 的 COCOMO模型估算的工作量和进度。
总体类型 组织型
半独立型 嵌入型
工作量 MM=10.4（KLOG）1.05 MM=3.0（KLOG）1.12 MM=3.6（KLOG）1.20
进度 TDEV=10.5（MM）0.38 TDEV=10.5（MM）0.35 TDEV=10.5（MM）0.32
i1
其中:ai — 估计的最小行数 bi — 估计的最大行数 mi — 最可能的行数
将估算的源代码行数，乘以根据经验推算的每行源代 码所需成本，即为该软件的成本。
IBM 估算模型
1977年由Waiston 和 Felix 总结了IBM联合系统 分部（FSD）负责的６０个项目的数据，利用最小二 乘法拟合，得到如下估算公式：
PERT（Program evaluation & review technique)计 划评审技术或CPM（Critical path method）关键路径法， 都是采用网络图来描述项目的进度安排。如图描述了开发 模块A、B、C的任务网络图。各边上所标注的数字为该任 务所持续的时间，数字结点为任务的起点和终点。
70
任务
月份 １ 2 3 4 5 6 7 8 9 10 11 12
60
需求分析 ▲ ▲ ▲
50
总体设计
▲ ▲▲
40
详细设计
▲▲
30
编码 软件测试
▲ ▲▲
20
10
▲▲▲
0 一月
二月
三月
四月
五月
六月
进度表
2.甘特图（Gantt Chart）
下 表 是 根 据 63 个 项 目 的 数 据 统 计 结 果 ， 按 照 基 本 的 COCOMO模型估算的工作量和进度。
总体类型 组织型
半独立型 嵌入型
工作量 MM=10.4（KLOG）1.05 MM=3.0（KLOG）1.12 MM=3.6（KLOG）1.20
进度 TDEV=10.5（MM）0.38 TDEV=10.5（MM）0.35 TDEV=10.5（MM）0.32
i1
其中:ai — 估计的最小行数 bi — 估计的最大行数 mi — 最可能的行数
将估算的源代码行数，乘以根据经验推算的每行源代 码所需成本，即为该软件的成本。
IBM 估算模型
1977年由Waiston 和 Felix 总结了IBM联合系统 分部（FSD）负责的６０个项目的数据，利用最小二 乘法拟合，得到如下估算公式：
PERT（Program evaluation & review technique)计 划评审技术或CPM（Critical path method）关键路径法， 都是采用网络图来描述项目的进度安排。如图描述了开发 模块A、B、C的任务网络图。各边上所标注的数字为该任 务所持续的时间，数字结点为任务的起点和终点。
70
任务
月份 １ 2 3 4 5 6 7 8 9 10 11 12
60
需求分析 ▲ ▲ ▲
50
总体设计
▲ ▲▲
40
详细设计
▲▲
30
编码 软件测试
▲ ▲▲
20
10
▲▲▲
0 一月
二月
三月
四月
五月
六月
进度表
2.甘特图（Gantt Chart）
软件工程智慧树知到答案章节测试2023年山东财经大学
第一章测试1.软件没有相应的文档，且最终不能满足用户要求是软件危机的一种表现。
（）A:错B:对答案:B2.软件本身的不可见性和复杂性随规模的增加呈指数上升是产生软件危机的主要原因。
（）A:错B:对答案:A3.开发软件就是写程序。
（）A:错B:对答案:A4.开发软件所需高成本和产品的低质量之间有着尖锐的矛盾，这种现象称（）。
A:软件危机B:软件工程C:软件产生D:软件周期答案:A5.以下对软件工程描述正确地是（）。
A:结合最好的技术方法。
B:经济地开发出高质量的软件并有效地维护它。
C:一门工程学科。
D:采用经过时间考验而证明正确的管理技术。
答案:ABCD6.软件生命周期中所花费费用最多的阶段是（）。
A:需求分析。
B:软件总体设计。
C:软件实现。
D:软件维护。
答案:D7.软件是（）。
A:计算机系统。
B:处理对象和处理规则的描述。
C:程序。
D:程序、数据及其文档的集合。
答案:D8.同螺旋模型相比，原型模型主要缺少（）。
A:客户评估B:制定计划C:风险分析D:实施工程答案:C9.在软件生存周期模型中，不适应变化需求的软件开发模型是（）。
A:原型模型B:瀑布模型C:螺旋模型D:增量模型答案:B10.针对高质量软件的生产的软件过程模型（）。
A:RUP模型B:基于构件的模型C:净室模型D:增量模型答案:C第二章测试1.可行性研究的技术可行性是指现有技术是否可行。
（）A:对B:错答案:A2.可行性研究的成本效益分析是从经济方面讨论是否可行。
（）A:对B:错答案:A3.可行性分析研究的目的是（）。
A:功能内聚B:项目值得开发否C:开发项目D:争取项目答案:B4.描绘物理系统的传统工具是（）。
A:程序流程图B:系统流程图C:数据流程图D:软件结构图答案:B5.数据字典的基本功能是（）。
A:数据维护。
B:数据通信。
C:数据定义。
D:数据库设计。
答案:C6.使用数据流图对工资系统进行需求分析建模，外部实体是（）。
A:工资单B:工资系统代码C:工资数据库维护D:接受工资单的银行答案:D7.数据流图的作用包括（）。
软件工程第四版课后答案
20
作业及解答（第3章）
ER模型
本问题中共有两类实体，分别是“储户”和“储蓄所”，
E2 业务员
13:07:42
F8储蓄利率
D2存款利率
19
重庆工学院计算机科学与工程学院 李梁(liliang@)
作业及解答（第3章）
F2取款单 无效取款信息 D1存款信息 F7密码 F7密码 P3.2 密码校验 P3.1 输入取款信息 F5存款信息
E1 储户
13:07:42
重庆工学院计算机科学与工程学院 李梁(liliang@)
13:07:42
重庆工学院计算机科学与工程学院 李梁(liliang@)
4
作业及解答（第1-2章）
(1)在1985年对计算机存储容量的需求，估计是
M 4080 e
0.28(19851960)
4080e 4,474,263(字)
7
如果字长为16位，则这个存储器的价格是 19851974
73,577,679条指令。 在1995年一名程序员每天可开发出30条指令，每月可开 发出600条指令，为了开发出可装满整个存储器的程序， 需要的工作量为 73577679 122 629(人月) ， 600
13:07:42 重庆工学院计算机科学与工程学院 李梁(liliang@)
13:07:42
重庆工学院计算机科学与工程学院 李梁(liliang@)
15
作业及解答（第3章）
电话号码=[校内电话号码|校外电话号码] 校内电话号码=非零数字+
3 位数字 //后面继续定义 校外电话号码=[本市号码|外地号码] 本市号码=数字零+8位数字 外地号码=数字零+3位数字+8位数字 非零数字=[1|2|3|4|5|6|7|8|9] 数字零＝0 3位数字＝3{数字}3 //3至3个数字 8位数字=非零数字+7位数字 7位数字=7{数字}7 数字＝[0|1|2|3|4|5|6|7|8|9]
软件工程导论第11章
22
【还可以把适配接口再进一步细分为转换接口和扩充接口。转换接口， 是为了克服与表示方法、数据结构或硬件特点相关的操作给重用带来 的困难而设计的，这类接口是每个类构件在重用时都必须重新定义的 服务的集合。当使用C++语言编程时，应该在根类(或适当的基类)中， 把属于转换接口的服务定义为纯虚函数。如果某个服务有多种可能的 实现算法，则应该把它当作扩充接口。扩充接口与转换接口不同，并 不需要强迫用户在派生类中重新定义它们，相反，如果在派生类中没 有给出扩充接口的新算法，则将继承父类中的算法。当用C++语言实现 时，在基类中把这类服务定义为普通的虚函数。】
4. 弱耦合 耦合：指一个软件结构内不同模块之间互连的紧 密程度。 在面向对象方法中，对象是最基本的模块，因此， 耦合主要指不同对象之间相互关联的紧密程度。 弱耦合是优秀设计的一个重要标准。
5
对象之间的耦合分为两大类： (1) 交互耦合： 对象之间的耦合通过消息连接来实现。 使交互耦合尽可能松散，应遵守下述准则： 尽量降低消息连接的复杂程度。 应该尽量减少消息中包含的参数个数，降低参数的复 杂程度。 减少对象发送(或接收)的消息数。 (2) 继承耦合 与交互耦合相反，应该提高继承耦合程度。 通过继承关系结合起来的基类和派生类，构成系统中 粒度更大的模块。设计时应该使特殊类尽量多继承并 使用其一般化类的属性和服务，从而更紧密地耦合到 其一般化类。
13
2. 软件成分的重用级别 (1) 代码重用 源代码剪贴：最原始的重用形式。 复制或修改原有代码时可能出错，存在严重的配臵 管理问题，人们几乎无法跟踪原始代码块多次修改 重用的过程。 源代码包含：许多程序设计语言都提供包含库中 源代码的机制。配臵管理问题有所缓解，修改了库 中源代码之后，所有包含它的程序自然都必须重新 编译。 继承：利用继承机制重用类库中的类时，无须修 改已有的代码，就可以扩充或具体化在库中找出的 类，基本上不存在配臵管理问题。
【还可以把适配接口再进一步细分为转换接口和扩充接口。转换接口， 是为了克服与表示方法、数据结构或硬件特点相关的操作给重用带来 的困难而设计的，这类接口是每个类构件在重用时都必须重新定义的 服务的集合。当使用C++语言编程时，应该在根类(或适当的基类)中， 把属于转换接口的服务定义为纯虚函数。如果某个服务有多种可能的 实现算法，则应该把它当作扩充接口。扩充接口与转换接口不同，并 不需要强迫用户在派生类中重新定义它们，相反，如果在派生类中没 有给出扩充接口的新算法，则将继承父类中的算法。当用C++语言实现 时，在基类中把这类服务定义为普通的虚函数。】
4. 弱耦合 耦合：指一个软件结构内不同模块之间互连的紧 密程度。 在面向对象方法中，对象是最基本的模块，因此， 耦合主要指不同对象之间相互关联的紧密程度。 弱耦合是优秀设计的一个重要标准。
5
对象之间的耦合分为两大类： (1) 交互耦合： 对象之间的耦合通过消息连接来实现。 使交互耦合尽可能松散，应遵守下述准则： 尽量降低消息连接的复杂程度。 应该尽量减少消息中包含的参数个数，降低参数的复 杂程度。 减少对象发送(或接收)的消息数。 (2) 继承耦合 与交互耦合相反，应该提高继承耦合程度。 通过继承关系结合起来的基类和派生类，构成系统中 粒度更大的模块。设计时应该使特殊类尽量多继承并 使用其一般化类的属性和服务，从而更紧密地耦合到 其一般化类。
13
2. 软件成分的重用级别 (1) 代码重用 源代码剪贴：最原始的重用形式。 复制或修改原有代码时可能出错，存在严重的配臵 管理问题，人们几乎无法跟踪原始代码块多次修改 重用的过程。 源代码包含：许多程序设计语言都提供包含库中 源代码的机制。配臵管理问题有所缓解，修改了库 中源代码之后，所有包含它的程序自然都必须重新 编译。 继承：利用继承机制重用类库中的类时，无须修 改已有的代码，就可以扩充或具体化在库中找出的 类，基本上不存在配臵管理问题。
第11章净室软件工程19991
(4)达到几乎零缺陷的水平。在团队的复审过程中， 每个控制结构的每个正确性条件被依次验证。每 个团队成员必须就每个条件都是正确的达成共识， 这样只有团队的每个成员均未能正确地验证某条 件时，才有可能出现错误。
2.条件loop可能以两种方式之一出现：(1)直接从init(此时 loop 条件被直接满足)，或(2)通过穿过条件cont 的控制流。 因为条件cont与条件loop相同，因此，不管从哪条路径到 达它，条件loop 都为真。
3.条件cont:只有在y值被递增1后，才能遇到条件cont 。另外， 只有在条件yes也为真时，才能调用到达条件cont 的控制 流路径。因此，如果(y+1)2≤x，则y2≤x，条件cont成立。
11.3 功能规格说明
净室软件工程通过使用盒结构规格说明的方法来遵 从操作分析原则。
一个“盒”在某个细节层次上封装系统(或系统的 某些方面)。
通过逐步求精的过程，盒被精化为层次。“每个盒 规格说明的信息内容足以定义其精化，不需要依赖 任何其他盒的实现” 。
这使得分析员能够按层次划分一个系统——从顶层 的基本表示到底层实现的特定细节。
(1)增量策划。制定一个采用增量策略的项目计划， 确定每个增量的功能、预计规模、及净室开发进 度。
(2)需求收集。为每个增量开发更详细的客户级需 求描述。
11.2 净室策略
(3)盒结构规格说明。运用盒结构的规格说明方法描 述功能规格说明。遵从操作分析原则，盒结构 “在每一个精化级别上使行为、数据及过程的创 造性定义独立”。
设计求精与验证
定义入口和出口条 件。
为了证明设计的正 确性，需要证明图 中表示的条件init、 loop、cont、yes 和exit 在所有情形 下都是正确的。
2.条件loop可能以两种方式之一出现：(1)直接从init(此时 loop 条件被直接满足)，或(2)通过穿过条件cont 的控制流。 因为条件cont与条件loop相同，因此，不管从哪条路径到 达它，条件loop 都为真。
3.条件cont:只有在y值被递增1后，才能遇到条件cont 。另外， 只有在条件yes也为真时，才能调用到达条件cont 的控制 流路径。因此，如果(y+1)2≤x，则y2≤x，条件cont成立。
11.3 功能规格说明
净室软件工程通过使用盒结构规格说明的方法来遵 从操作分析原则。
一个“盒”在某个细节层次上封装系统(或系统的 某些方面)。
通过逐步求精的过程，盒被精化为层次。“每个盒 规格说明的信息内容足以定义其精化，不需要依赖 任何其他盒的实现” 。
这使得分析员能够按层次划分一个系统——从顶层 的基本表示到底层实现的特定细节。
(1)增量策划。制定一个采用增量策略的项目计划， 确定每个增量的功能、预计规模、及净室开发进 度。
(2)需求收集。为每个增量开发更详细的客户级需 求描述。
11.2 净室策略
(3)盒结构规格说明。运用盒结构的规格说明方法描 述功能规格说明。遵从操作分析原则，盒结构 “在每一个精化级别上使行为、数据及过程的创 造性定义独立”。
设计求精与验证
定义入口和出口条 件。
为了证明设计的正 确性，需要证明图 中表示的条件init、 loop、cont、yes 和exit 在所有情形 下都是正确的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
· 开放式范型：这种范型试图以一种既具有封闭 式范型的控制性，又包含随机式范型的创新性的方式
来组织项目组。通过大量协商和基于一致意见做出的
决策，项目组成员相互协作完成工作任务。用开放式 范型组织起来的项目组很适于解决复杂问题，但是可 能没有其他类型小组的效率高。 · 同步式范型：按照对问题的自然划分，组织项 目组成员各自解决一些子问题，他们之间很少有主动 的通信需求。
11.4.2 四种组织范型 Constantine提出了软件工程小组的下述4种“组 织范型”。 · 封闭式范型：按照传统的权力层次来组织项目 组(类似于CD小组)。当开发与过去已经做过的产品相 似的软件时，这种项目组可以工作得很好，但是，在 这种封闭式范型下难以进行创新性的工作。 · 随机式范型：松散地组织项目组，小组工作依 靠小组成员发挥个人的主动性。当需要创新或技术上 的突破时，用随机式范型组织起来的项目组能工作得 很好。但是，当需要“有次序地执行”才能完成任务 时，这样的项目组就可能陷入困境。
11.3 现代程序员组
实际的“主程序员”应该由两个人来担任：一个 技术负责人，负责小组的技术活动；一个行政负责人， 负责所有非技术的管理决策。这样的组织结构如图 11.2所示。
图11.2 现代程序员组
由于程序员组的成员人数不宜过多，当软件项目 规模较大时，应该把程序员分成若干个小组，采用图 11.3所示的组织结构。该图描绘的是技术管理组织的 结构，非技术管理组织的结构与此类似。由图可以看
小组规模小，不仅可以减少通信问题，而且还有 其他好处。例如，容易确定小组的质量标准，而且用 民主方式确定的标准更容易被大家遵守；组员间关系 密切，能够互相学习等。 民主制程序员组通常采用非正式的组织方式，也 就是说，虽然名义上有一个组长，但是他和组内其他 成员完成同样的任务。在这样的小组中，由全体讨论 决定应该完成的工作，并且根据每个人的能力和经验 分配适当的任务。
上下级之间的通信。 · 控制集权式(Controlled Centralized，缩写为 CC)：小组负责人管理顶层问题的解决过程并负责组内 协调。负责人和小组成员之间的通信是上下级式的。
选择软件工程小组的结构时，应该考虑下述7个项 目因素。 · 待解决的问题的困难程度； · 要开发的程序的规模(用代码行或功能点度量)； · 小组成员在一起工作的时间(小组生命期)；
必须改变评价程序员价值的标准，每名程序员都 应该鼓励该组其他成员找出自己编写的代码中的错误。 不要认为存在错误是坏事，而应该认为是正常的事情， 应该把找出模块中的一个错误看作是取得了一个胜利。
任何人都不能嘲笑程序员所犯的编码错误。程序员组
作为一个整体，将培养一种平等的团队精神，坚信 “每个模块都是属于整个程序员组的，而不是属于某 个人的”。一组无私的程序员将构成一个民主制程序 员组。
出，产品的实现作为一个整体是在项目经理的指导下
进行的，程序员向他们的组长汇报工作，而组长向项
目经理汇报工作。当产品规模更大时，可以增加中间
管理层次。
图11.3 大型项目的技术管理组织结构
把民主制程序员组和主程序员组的优点结合起来 的另一种方法，是在合适的地方采用分散做决定的方 法，如图11.4所示。这样做有利于形成畅通的通信渠 道，以便充分发挥每个程序员的积极性和主动性，集 思广益攻克技术难关。这种组织方式对于适合采用民 主方法的那类问题(例如，研究性项目或遇到技术难题 需要用集体智慧攻关)非常有效。
为了使少数经验丰富、技术高超的程序员在软件 开发过程中能够发挥更大作用，程序设计小组也可以 采用下一小节中介绍的另外一种组织形式。
11.2 主程序员组
美国IBM公司在20世纪70年代初期开始采用主程序 员组的组织方式。采用这种组织方式主要出于下述几 点考虑： · 软件开发人员多数比较缺乏经验； · 程序设计过程中有许多事务性的工作，例如，
CC
× ×
×
模块化程度 高 低 可靠性 高 低 支付日期 紧 松 社交 高 低
× × × ×
×
× × × × × × ×
集权式结构能够更快地完成任务，它最适于处理
简单问题。分权式的小组比起个人来，能够产生更多， 更好的解决方案，这种小组在解决复杂问题时成功的
可能性更大。因此，CD或CC小组结构能够成功地用来
解决简单的问题，而DD结构则适于解决难度较大的问 题。 小组的性能与必须进行的通信量成反比，所以开 发规模很大的项目时最好采用CC或CD结构的小组。
小组生命期长短影响小组的士气。经验表明，DD
小组结构能导致较高的士气和较高的工作满意度，因 此适合于生命期长的小组。
DD小组结构最适于解决模块化程度较低的问题， 因为解决这类问题需要更大的通信量。如果能够达到 较高的模块化程度(人们自己独自做自己的事情)，则 CC或CD结构更适宜。 人们曾经发现，CC和CD小组产生的缺陷比DD小组 少，但是这些数据在很大程度上取决于小组采用的质 量保证活动。 完成同一个项目，分权式结构通常需要比集权式 结构更多的时间，不过当需要高社交性时分权式结构 是最适宜的。 历史上最早的软件项目组是控制集权式(CC)结构， 当时人们把这样的软件项目组称为主程序员组。
· 问题能够被模块化的程度；
· 对待开发的系统的质量和可靠性的要求； · 交付日期的严格程度； · 项目要求的社交(通信)程度。 表11.1概括了项目特性对项目组组织方式的影响。
表 11.1 项目特性对项目组结构的影响小组 小组类型 DD CD 项目特性 困难程度 高 × 低 × 规模 大 × 小 × 小组生命期 短 × 长 ×
大量信息的存储和更新；
· 多渠道通信很费时间，将降低程序员的生产率。
Baker描述的一个典型的主程序员组如图11.1所 示。该组由主程序员、后备程序员、编程秘书以及1～ 3名程序员组成。在必要的时候，该组还有其他领域的 专家(例如，法律专家，财务专家等)协助。
图11.1 主程序员组的结构
· 控制分权式(Controlled Decentralized，缩写 为CD)：这种软件工程小组有一个固定的负责人，他协
调特定任务的完成并指导负责子任务的下级领导人的
工作。解决问题仍然是一项群体活动，但是，通过小 组负责人在子组之间划分任务来实现解决方案。子组
和个人之间的通信是平行的，但是也有沿着控制层的
民主制程序员组的一个重要特点是，小组成员完 全平等，享有充分民主，通过协商做出技术决策。因 此，小组成员间的通信是平行的，如果一个小组有n个 成员，则可能的通信信道有n(n-1)/2条。 一般说来，程序设计小组的规模应该比较小，以
2～8名成员为宜。如果项目规模很大，用一个小组不
能在预定时间内完成开发任务，则应该使用多个程序 设计小组，每个小组承担工程项目的一部分任务，在 一定程度上独立自主地完成各自的任务。系统的总体 设计应该能够保证由各个小组负责开发的各部分之间 的接口是良好定义的，并且是尽可能简单的。
第11章 组织
11.1 民主制程序员组
11.2 主程序员组 11.3 现代程序员组
11.4 软件项目组
11.5 小结
退出
11.1 民主制程序员组
有两种极端方法可用来组织程序员组，这两种组 织方法分别称为民主制程序员组和主程序员组。本节 介绍民主制程序员组，下节介绍主程序员组。 构成民主制程序员组的基本概念是“无私编程”。
图11.4 包含分散决策的组织方式
11.4 软件项目组
如前所述，程序员组的组织方式主要用于实现阶 段，当然，也适用于软件生命周期的其他阶段(当考虑 在更广阔范围的应用时，把程序员组更名为软件项目 组更恰当一些)。本节从更广阔的角度进一步讨论软件 项目组的组织方式。
11.4.1
三种组织方式
Mantei提出了下述的三种通用的项目组组织方式。 · 民主分权式(Democratic Decentralized，缩写 为DD)：这种软件工程小组没有固定的负责人，“任务 协调人”是临时指定的，随后将由协调别的任务的人 取代。用全体组员协商一致的方法对问题及解决问题 的方法做出决策。小组成员间的通信是平行的。
11.5 小结
对任何软件项目而言，最关键的因素都是承担项 目的人员。必须合理地组织项目组，使项目组有较高 生产率。“最佳的”小组结构取决于管理风格、组里 的人员数目和他们的技术水平，以及所承担的项目的 难易程度。 本章具体介绍了国外比较流行的民主制程序员组、 主程序员组和现代程序员组的组织方式，讨论了不同 组织方式的优缺点和适用范围。然后又从更广阔的角 度进一步讨论了通用的软件项目组的组织结构问题。