软件工程复试——十三、软件项目管理

十三、软件项目管理

管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源用以达到既定目标的过程。

软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算。

估算软件规模

代码行技术

代码行技术依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。是一种比较简单的定量估算软件估摸的方法。

估计程序的最小规模（a）、最大规模（b）和最可能的规模（m）,分别算出这3种规模的平均值后，再用下式计算程序规模的估计值：

优点：

① 代码是所有软件开发项目都有的“产品"，而且很容易计算代码行数。
② 有以往开发类似产品的历史数据可参考时，估计出的数值比较准确。

缺点：

① 源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模不太合理。
② 用不同语言实现同一个软件所需要的代码行数并不相同。
③ 不适用于非过程语言。

功能点技术

功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。用功能点（FP）为单位度量软件规模。是为了克服代码行技术的缺点，提出来的新技术。

信息域特性：

① 输入项数（Inp）：用户向软件输入的项数，这些输入给软件提供面向应用的数据。
② 输出项数（Out）：软件向用户输出的项数，它们向用户提供面向应用的信息。
③ 査询数（Inq）： 一次联机输入，它导致软件以联机输出方式产生某种即时响应。
④ 主文件数（Maf）：逻辑主文件（数据的一个逻辑组合）的数目。
⑤ 外部接口数（Inf）：机器可读的全部接口数量，用这些接口把信息传送给另一个系统。

步骤：

• 计算未调整的功能点数UFP
• 计算技术复杂性因子TCF
• 计算功能点数FP

工作量估算

​ 软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模的函数，工作量的单位通常是人月（pm）。没有一个估算模型可以适用于所有类型的软件和开发环境。

静态单变量模型

静态单变量模型的总体结构形式如下:

其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量(KLOC或FP)。

分类

（1）KLOC的估算模型

（2）面向FP的估算模型

这些模型的使用范围有限，因此必须根据当前项目的特点选择适用的估算模型。

动态多变量模型

动态多变量模型（软件方程式）是根据从4000多个当代软件项目中收集的生产率数据推导出来的。该模型把工作量看作软件规模和开发时间这两个变量的函数。

估算模型如下：

其中，E是以人月或人年为单位的工作量；t是以月或年为单位的项目持续时间；B是特殊技术因子，对于较小的程序(KL0C=5〜15), B=0.16,对于超过70 KLOC的程序，B=0.39； P是生产率参数，它反映了以下因素对工作量的影响：
a. 总体过程成熟度及管理水平。
b. 使用良好的软件工程实践的程度。
c. 使用的程序设计语言的级别。
d. 软件环境的状态。
e. 软件项目组的技术及经验。
f. 应用系统的复杂程度。

COCOMO2模型

COCOMO是构造性成本模型(constructive cost model)的英文缩写。COCOMO2给出了 3个层次模型，这3
个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。这3个模型如下：
① 应用系统组成模型：主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。
② 早期设计模型：适用于体系结构设计阶段。
③ 体系结构模型：适用于完成体系结构设计之后的软件开发阶段。

特点：
① 这个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。
② 这些模型既可以用于不同类型的项目，也可以用于同一个项目的不同开发阶段。

形式：

其中：E是开发工作量（以人月为单位）；a是模型系数；KLOC是估计的源代码行数（以千行为单位）；b是模型指数；fi （i=l〜17）是成本因素。

模型指数：

COCOMO2釆用了的b分级模型，是使用5个分级因素Wi (l<i<5),其中每个因素都划分成从甚低(Wi=5)
到特高 （wi=0)的6个级别，用下式计算b (1.01〜1.26)的数值：

COCOMO2的5个分级因素
① 项目先例性：指出对于开发组织来说该项目的新奇程度。
② 开发灵活性：反映出为实现预先确定的外部接口和为了及早开发出产品而增加的工作量。
③ 风险排除度：反映了重大风险已被消除的比例。
④ 项目组凝聚力：表明了开发人员相互协作时可能存在的困难。
⑤ 过程成熟度：反映了按照能力成熟度模型度量出的项目组织的过程成熟度。

进度计划

​ 一个有效的软件过程应该定义一个适用于当前项目的任务集合。一个任务集合包括一组软件工程工作任务、里程碑和可交付的产品。为一个项目所定义的任务集合，必须包括为获得高质量的软件产品而应该完成的所有任务，但是同时又不能让项目组承担不必要的工作。

项目管理者的任务

项目管理者的工作
① 目标
定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，保证及时发现拖延进度的情况。
② 方法
管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。

进度安排

① 定义
软件项目的进度安排通过把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工作量分布于计划好的项目持续期内。进度计划将随着时间的流逝而不断演化。
② 流程
a. 在项目计划的早期，制定一个宏观的进度安排表，标识出主要的软件工程活动和这些活动影响到的产品功能。
b. 随着项目的进展，把宏观进度表中的每个条目都精化成一个详细进度表，标识出完成一个活动所必须实现的一组特定任务，并安排好实现这些任务的进度。

估算开发时间

模型估计：

其中E是开发的工作量。

当小组人员越来越多时个人生产率将下降，导致开发时间与从事开发的人数并不成反比关系。

因为：你人越多通信成本就越高，大家在一起通信的时间就会增多，而且新人也得学习下你这个开发的技术，占用其他人时间。

Brooks 规律：
向一个已经延期的项目增加人力，只会使得它更加延期。

甘特图

用例子说话！

假设有一座陈旧的矩形木板房需要重新油漆。这项工作必须分3步完成：首先刮掉旧漆，然后刷上新漆，最后清除溅在窗户上的油漆。假设一共分配了 15名工人去完成这项工作，然而工具却很有限：只有5把刮旧漆用的刮板，5把刷漆用的刷子，5把清除溅在窗户上的油漆用的小刮刀。怎样安排才能使工作进行得更有效呢？

下面是各道工序估计所花费的时间

可以以下Gantt图描绘上述流水作业过程：
① 在时间为零时开始刮第1面墙上的旧漆；
② 两小时后刮旧漆的工人转去刮第2面墙，同时另5名工人开始给第1面墙刷新漆
③ 当给一面墙刷完新漆之后，第3组的5名工人立即清除溅在这面墙窗户上的漆。

优点：

① 很形象地描绘任务分解情况，以及每个子任务(作业)的开始时间和结束时间。
② 容易掌握、容易绘制。
缺点：
① 不能显式地描绘各项作业彼此间的依赖关系。
② 进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象。
③ 计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。

工程网络

工程网络可以描绘任务分解情况以及每项作业的开始时间和结束时间，它还显式地描绘各个作业彼此间的依赖关系。

表示：

① 用箭头表示作业，作业通常既消耗资源又需要持续一定时间。
② 用圆圈表示事件（开始或结束），事件是明确定义的时间点，并不消耗时间和资源。
③ 用虚线箭头表示虚拟作业，虚拟作业是为了显式地表示作业之间的依赖关系。

估算工程进度

完善工程网络：

① 把每个作业估计需要使用的时间写在表示该项作业的箭头上方。
② 为每个事件计算最早时刻EET和最迟时刻LET,分别写在表示事件的圆圈的右上角和右下角。

最早时刻EET：

① 定义
事件的最早时刻是该事件可以发生的最早时间。通常工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。
② 计算规则
a. 考虑进入该事件的所有作业。
b. 对于每个作业都计算它的持续时间与起始事件的EET之和。
c. 选取上述和数中的最大值作为该事件的最早时刻EET。

最迟时刻LET

① 定义
事件的最退时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻。最后一个事件的最迟时刻就是它的最早时刻。其他事件的最迟时刻在工程网络上从右至左按逆作业流的方向计算。
② 计算规则
a. 考虑离开该事件的所有作业。
b. 从每个作业的结束事件的最迟时刻中减去该作业的持续时间。
c. 选取上述差数中的最小值作为该事件的最迟时刻LET。

关键路径

由最早时刻和最迟时刻相同的事件定义了关键路径，在图中一般由粗线箭头表示。关键事件必须准时发生，组成关键作业的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。

特点
① 处于关键路径之外的任务进度拖后，不会影响整个项目的完成时间。
② 处于关键路径之中的任务进度拖后，则整个项目的完成日期就会拖后。

机动时间

​ 不在关键路径上的作业有一定程度的机动余地一实际开始时间可以比预定时间晚一些,或者实际持续时间可以比预定的持续时间长一些，而并不影响工程的结束时间。
(2) 计算
一个作业可以有的全部机动时间等于它的结束事件的最迟时刻减去它的开始事件的最早时刻,再减去这个作业的持续时间：
机动时间=(LET)结束-(EET)开始-持续时间
(3) 表示
工程网络中每个作业的机动时间写在该项作业的箭头下面的括号里。在制定进度计划时仔细考虑和利用工程网络中的机动时间，往往能够安排出既节省资源又不影响最终竣工时间的进度表。

人员组织

​ 现有的软件项目组的组织方式很多，通常，组织软件开发人员的方法，取决于所承担的项目的特点、以往的组织经验以及管理者的看法和爱好，主要有3种典型的组织方式。

民主制程序员组

​ 民主制程序员组中小组成员完全平等，享有充分民主，通过协商做出技术决策。即小组成员之间的通信是平行的，如果小组内有n个成员，则可能的通信信道共有n (n-1) /2条。
要求

• 小组人员不能过多（减少通信问题）
• 采用非正式的组织方式（名义上有个组长，但是名存实亡）

优点：

a. 组员们对发现程序错误持积极的态度，有助于更快速地发现错误，提高代码质量。
b. 组员们享有充分民主，小组凝聚力高、学术空气浓厚，有利于攻克技术难关。
缺点：
没有明确的权威指导开发过程，组员间将缺乏必要的协调，最终可能导致工程失败。

主程序员组

主程序员组用经验多、技术好、能力强的程序员作为主程序员，同时利用人和计算机在事务性工作方面给主程序员提供充分支持。结构如下

其中核心人员及其分工如下：

a. 主程序员
既是成功的管理人员又是经验丰富、技术好、能力强的高级程序员，负责体系结构设计和关键部分的详细设计，并且负责指导其他程序员完成详细设计和编码工作。
b. 后备程序员
技术熟练而且富于经验，协助主程序员工作并且在必要时接替主程序员的工作。具体工作是设计测试方案、分析测试结果及独立于设计过程的其他工作。
c. 编程秘书
负责完成与项目有关的全部事务性工作。

它拥有两个重要特性（优点）：

a. 专业化：该组每名成员仅完成他们擅长的工作。
b. 层次性：主程序员指挥组员工作，并对项目全面负责

但是缺点就是现在符合这种人才标准的人才很难找到。

现代程序员组

其技术结构如下

其中主程序员有两个人共同担任

a. 技术负责人
负责小组的技术活动，参与全部代码审査工作，并且对代码的各方面质量负责。
b. 行政负责人
负责非技术性事务的管理决策。不参与代码审查，其职责是对程序员的业绩进行评价。

特点：

①主程序员由两人共同担任

② 制定针对公共职责范围内的事务的处理方案
③ 实行分组策略

④分散决定

质量保证

软件质量是软件与明确地和隐含地定义的需求相一致的程度，即软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。

特点：

① 软件需求是度量软件质量的基础，与需求不一致就是质量不高。
② 指定的开发标准定义了指导软件开发准则，没有遵守这些准则，会导致软件质量不高。
③ 软件满足明确描述的需求，但不满足隐含的需求，那么软件的质量是值得怀疑的。

软件质量因素：

软件质量保证措施

措施：

① 基于非执行的测试（复审或评审）：主要用来保证在编码前各阶段产生的文档的质量。
② 基于执行的测试（软件测试）：在程序编写完后进行，保证软件质量的最后一道防线。
③ 程序正确性证明：使用数学方法严格验证程序是否与对它的说明完全一致。

技术复审：

正式技术复审的优点是能较早发现软件错误，防止错误被传播到软件过程的后续阶段。包括走査和审查等具体方法。

方法：

（1）走查法

​ 走査组由4〜6名成员组成。成员包括负责起草文档的人、负责该文档说明的管理员、客户代表、下阶段开发组的代表、SQA小组的代表（作为组长）。

方式：

第一，参与者驱动法
参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须回答每个质疑。
第二，文档驱动法（更有效）
文档编写者向走査组成员仔细解释文档。走査组成员在此过程中针对事先准备好的问题或解释过程中发现的问题提出质疑。

(2)审查

审查过程主要包括下列步骤：

• 综述
• 准备
• 审查
• 返工
• 跟踪

审查过程步数比走查更多。审査过程每个步骤都是正规的仔细划分错误类型，并把这些信息运用在后续阶段的文档审査中以及未来产品的审査中。

（3）程序正确性证明

​ 正确性证明的基本思想是证明程序能完成预定的功能。应提供对程序功能的严格数学说明，然后根据程序代码证明程序确实能实现它的功能说明。

方法：人工证明、自动系统方法

软件配置管理

软件配置管理是在软件的整个生命期内管理变化的一组活动。其主要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告。

它主要用来：

• 标识变化
• 控制变化
• 确保适当的实现了变化
• 向需要知道这类信息的人报告变化

软件配置

软件配置项：

软件过程的输出信息主要分为3类：

• 计算机程序
• 描述计算机程序的文档
• 数据

基线：

​ 基线是已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它，即基线就是通过了正式复审的软件配置项。基线有助于人们在不严重妨碍合理变化的前提下来控制变化。

软件配置管理过程

软件配置管理是软件质量保证的重要一环，它的主要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告，具体来说，软件配置管理主要有5项任务:
标识、版本控制、变化控制、配置审计和报告。

管理过程：

• 标识软件配置中的对象
• 版本控制
• 变化控制
• 配置审计
• 状态报告

能力成熟度模型

能力成熟度模型（CMM）是用于评价软件机构的软件过程能力成熟度的模型。它为大型软件项目的招投标活动提供一种全面而客观的评审依据。它应用于许多软件机构内部的过程改进活动中。

它在改进软件过程中有以下作用：

① 指导软件机构通过确定当前的过程成熟度并识别出对过程改进起关键作用的问题，明确过程改进的方向和策略。
② 通过集中开展与过程改进的方向和策略相一致的一组过程改进活动，软件机构便能稳步而有效地改进其软件过程，使其软件过程能力得到循序渐进的提高。

能力成熟度有以下五个等级

① 初始级（1级）
软件过程能力是不可预测的，其软件过程是不稳定的，产品质量只能根据相关人员的个人工作能力来预测。
② 可重复级（2级）
软件项目的策划和跟踪是稳定的，已经为一个有纪律的管理过程提供了可重复以前成功实践的项目环境。
③ 已定义级（3级）
无论是管理活动还是工程活动都是稳定的。软件开发的成本和进度以及产品的功能和质量都受到控制，而且软件产品的质量具有可追溯性。
④ 已管理级（4级）
软件机构对软件过程和软件产品都建立了定量的质量目标，所有项目的重要的过程活动都是可度量的，软件过程在可度量的范围内运行。

⑤优化级（5级）
软件机构能够不断地改进其过程能力，既对现行的过程实例不断地改进和优化，又借助于新技术和新方法来实现未来的过程改进。这一级的软件机构是一个以防止出现缺陷为目标的机构，它有能力识别软件过程要素的薄弱环节，并有足够的手段改进它们。

课后题

4、

答：（1）由于待开发的应用系统类似于以前做过的系统，开发人员已经积累了较丰富的经验，没有多少技术难题需要攻克。为了减少通信开销，充分发挥技术骨干的作用，统一意志统一行动，提高生产率，加快开发进度，项目组的组织结构以基于主程序员组的形式为宜。
（2）针对待开发的系统，客户已经写出了完整的需求文档，项目组又有开发类似系统的经验，因此，可以釆用广大软件工程师熟悉的瀑布模型来开发本系统。

5、

答：（1）由于是技术上具有创新性的产品，所以需要采用民主制程序员组，大家可以集思广益，共同攻关技术难题。
（2）要求把虚拟现实硬件和最先进的软件结合在一起，所以需要采用一种完整而且完美的模型进行开发，所以RUP最为合适。

6、
答：（1）应该选择现代程序员组，因为小组成员都能对发现程序错误持积极、主动的态度。能更好的适应竞争。
（2）大型软件应采用演化模型中的螺旋模型。

7、

答：（1）软件质量是软件与明确地和隐含地定义的需求相一致的程度。
（2）软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。软件可靠性是程序在给定的时间间隔内按照规格说明书的规定成功地运行的概率。

8、

答：（1）软件可靠性是程序在给定的时间间隔内按照规格说明书的规定成功地运行的概率。软件可靠性既包含正确性又包含健壮性，即不仅在预定环境下程序应该能正确地完成预期功能，而且在硬件发生故障、输入的数据无效或用户操作错误等意外环境下，程序也应该能作出适当的响应。
（2）如果一个程序在预定环境下能够正确地完成预期的功能，但是在意外环境下不能作出适当的响应，则该稈序就是既正确又不可靠。

10、

答：(1)基线是已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。
(2)建立基线的三大原因
① 重视性
重视性是指及时返回并重新生成软件系统给定发布的能力,或是在项目中的早些时候重新生成开发环境的能力。
② 可追踪性
可追踪性建立项目工件之间的前后继承关系，其目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。
③ 报告
报告来源于一个基线内容同另一基线内容的比较。基线比较利于调试并生成发布说明。

11、

答：（1）正式的技术复审关注被修改后的配置对象的技术正确性。
（2）复审者审査该对象以确定它与其他软件配置项的一致性，并检査是否有遗漏或副作用。软件配置审计通过评估配置对象的那些通常不在复审过程中考虑的特征，而成为对正式技术复审的补充。

12、

答：（1） CMM的基本思想是，由于软件危机是因对软件过程管理不善而引起的，所以新软件技术的运用并不会自动提高软件的生产率和质量，提高软件生产率和软件质量的关键是改进对软件过程的管理。
（2）对能力成熟度划分的原因
① 对软件过程的改进，是在完成一个又一个小的改进步骤基础上不断进行的渐进过程。
② 这5个成熟度等级定义了一个有序的尺度，用以测量软件机构的软件过程成熟度和评价其软件过程能力，
这些等级还帮助软件机构把应做的改进工作排出优先次序。
③ 成熟度等级是妥善定义的向成熟软件机构前进途中的平台，每个成熟度等级都为软件过程的继续改进提供了一个台阶。

完结撒花!!!

这堆文章里面如有错误还请多多包涵哈！！！各位可以在B站搜索软件工程导论听大连理工的一个胖胖的女老师讲的课加深理解！希望各位能够复试成功！！！