程序员一定要会的软件项目管理评估方案，不做只会敲代码的码农！
[1. 标识软件配置中的对象](about:blank#1.%20%E6%A0%87%E8%AF%86%E8%
BD%AF%E4%BB%B6%E9%85%8D%E7%BD%AE%E4%B8%AD%E7%9A%84%E5%AF%B9%E8%B1%A1)
Hello！我是灰小猿，一个有故事、爱分享、没技术的程序猿，
今天大灰狼来和大家聊聊除了软件编码，在软件项目管理阶段所需要进行哪些工作。提前祝大家从技术佬晋升产品总监！
很多刚步入软件行业或者正在学习的小伙伴都有这样的感觉，觉得编码阶段是软件开发中的关键步骤，但其实不然，如果我们把软件开发的过程比作建造一座大桥的话，编码阶段只不过是建筑工人添砖加瓦的建造过程，更多的方面则是软件的设计、管理、维护等阶段的进行，同样这也是一个软件开发过程中必不可少的阶段和流程。
软件项目管理阶段所需要进行的工作分别是：软件规模评估、工作量评估、进度计划、人员组织、质量保证、软件配置管理、能力成熟度模型七个阶段。
下面大灰狼和大家聊一下每个阶段的任务和评估方法，（文章较长，小伙伴们可以收藏以后慢慢学习）
软件项目管理
==========
首先，什么是软件项目管理？
所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。
软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。
软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算。
为了估算项目的工作量和完成期限，首先需要估算软件的规模。
软件规模评估
======
常用的软件规模评估的办法是代码行技术和功能点技术。这两种评估方法各有利弊，接下来大灰狼和大家分别分析一下：
一、代码行技术
代码行技术是比较简单的定量估算软件规模的方法。
依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。
当有以往开发类似产品的历史数据可供参考时，估计出的数值还是比较准确的。把实现每个功能所需要的源程序行数累加起来，就可得到实现整个软件所需要的源程序行数。??
估算方法：
由多名有经验的软件工程师分别做出估计。
每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)。
分别算出这 3 种规模的平均值、和之后，再用下式计算程序规模的估计值：
单位：LOC 或 KLOC。?
代码行技术的优点：
代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数；
有大量参考文献和数据 。
代码行技术的缺点：
源程序仅是软件配置的一个成分，由源程序度量软件规模不太合理；
用不同语言实现同一个软件所需要的代码行数并不相同；
不适用于非过程性语言。
二、功能点技术
功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。
这种方法用功能点(FP)为单位度量软件规模。?
1. 信息域特性
功能点技术定义了信息域的 5 个特性：
输入项数(Inp)：用户向软件输入的项数，这些输入给软件提供面向应用的数据。
输出项数(Out)：软件向用户输出的项数，它们向用户提供面向应用的信息。?
查询数(Inq)：查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。
主文件数(Maf)：逻辑主文件的数目。
外部接口数(Inf)：机器可读的全部接口的数量，用这些接口把信息传送给另一个系统。?
每个特征根据其复杂程度分配一个功能点数，即信息域特征系数 a1，a2，a3，a4，a5，见下表。
2. 估算功能点的步骤
(1) 计算未调整的功能点数 UFP
首先，把产品信息域的每个特性都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数。
然后，用下式计算未调整的功能点数 UFP： UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf
其中，ai(1≤i≤5)是信息域特性系数，其值由相应特性的复杂级别决定，如表 13.1 所示。?
(2) 计算技术复杂性因子 TCF
这一步骤度量 14 种技术因素对软件规模的影响程度。在表 13.2 中列出了全部技术因素，并用 Fi(1≤i≤14)代表这些因素。
根据软件的特点，为每个因素分配一个从 0（不存在或对软件规模无影响）到 5（有很大影响）的值。
然后，用下式计算技术因素对软件规模的综合影响程度 DI：
技术复杂性因子 TCF 由下式计算：?
TCF = 0.65 + 0.01 × DI
因为 DI 的值在 0~70 之间，所以 TCF 的值在 0.65~1.35 之间。
(3) 计算功能点数 FP
FP = UFP × TCF
功能点技术优点：
与所用的编程语言无关，比代码行技术更合理。
功能点技术缺点：
在判断信息域特性复杂级别和技术因素的影响程度时主观因素较大，对经验依赖性较强。
工作量评估
=========
工作量的评估通常有：静态单变量模型、动态多变量模型、COCOMO2 模型，
值得注意的是，大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的。
没有一个估算模型可以适用于所有类型的软件和开发环境。
明确了以上两点之后，接下来就是各个模型的评估方法了，
一**、静态单变量模型******
总体结构形式如下：?
E = A + B × (ev) C
其中，A、B 和 C 是由经验数据导出的常数，E 是以人月为单位的工作量，ev 是估算变量（KLOC 或 FP）。
1. 面向 KLOC 的估算模型
(1)Walston_Felix 模型??
E=5.2×(KLOC)0.91
(2)Bailey_Basili 模型
E=5.5+0.73×(KLOC)1.16
(3)Boehm 简单模型??
E=3.2×(KLOC)1.05
(4)Doty 模型（在 KLOC>9 时适用）
E=5.288×(KLOC)1.047
2. 面向 FP 的估算模型
(1)Albrecht & Gaffney 模型??
E=-13.39+0.0545FP
(2)Maston,Barnett 和 Mellichamp 模型??
E=585.7+15.12FP?
二、动态多变量模型
动态多变量模型也称为软件方程式，该模型把工作量看作是软件规模和开发时间这两个变量的函数。
动态多变量估算模型的形式如下：?
E=(LOC×B0.333/P)3×(1/t)4
其中 E 是以人月或人年为单位的工作量；t 是以月或年为单位的项目持续时间；B 是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=5~15），B=0.16,对于超过 70 KLOC 的程序，B=0.39；?
P 是生产率参数，它反映了下述因素对工作量的影响：?
总体过程成熟度及管理水平；
使用良好的软件工程实践的程度；
使用的程序设计语言的级别；
软件环境的状态；
软件项目组的技术及经验；
应用系统的复杂程度。
开发实时嵌入式软件时，P 的典型值为 2000；开发电信系统和系统软件时，P=10000；对于商业应用系统来说，P=28000。可以从历史数据导出适用于当前项目的生产率参数值。?
三、COCOMO2 模型
COCOMO 是构造性成本模型（constructive cost model)的英文缩写。
1981 年 Boehm 在《软件工程经济学》中首次提出了 COCOMO 模型。
1997 年 Boehm 等人提出的 COCOMO2 模型，是原始的 COCOMO 模型的修订版，它反映了十多年来在成本估计方面所积累的经验。?
COCOMO2 给出了 3 个层次的软件开发工作量估算模型，这 3 个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。
3 个层次的估算模型分别是：?
****应用系统组成模型：****这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。
****早期设计模型：****这个模型适用于体系结构设计阶段。
****后体系结构模型：****这个模型适用于完成体系结构设计之后的软件开发阶段。?
该模型把软件开发工作量表示成代码行数（KLOC）的非线性函数：
其中，E 是开发工作量（以人月为单位），a 是模型系数，KLOC 是估计的源代码行数，b 是模型指数，fi (i=1~17)是成本因素。?
每个成本因素都根据它的重要程度和对工作量影响大小被赋予一定数值（称为工作量系数）。
与原始的 COCOMO 模型相比，COCOMO2 模型使用的成本因素有下述变化。?
新增加了 4 个成本因素，它们分别是要求的可重用性、需要的文档量、人员连续性（即人员稳定程度）和多地点开发。?
略去了原始模型中的 2 个成本因素（计算机切换时间和使用现代程序设计实践）。
某些成本因素（分析员能力、平台经验、语言和工具经验）对生产率的影响（即工作量系数最大值与最小值的比率）增加了，另一些成本因素（程序员能力）的影响减小了。?
为了确定工作量方程中模型指数 b 的值，COCOMO2 采用了更加精细得多的 b 分级模型，这个模型使用 5 个分级因素 Wi(1≤i≤5),其中每个因素都划分成从甚低（Wi=5)到特高（Wi=0)的 6 个级别，然后用下式计算 b 的数值：
因此，b 的取值范围为 1.01~1.26。显然，这种分级模式比原始 COCOMO 模型的分级模式更精细、更灵活。?
COCOMO2 使用的 5 个分级因素如下所述：
****项目先例性：****这个分级因素指出，对于开发组织来说该项目的新奇程度。
****开发灵活性：****这个分级因素反映出，为了实现预先确定的外部接口需求及为了及早开发出产品而需要增加的工作量。
****风险排除度：****这个分级因素反映了重大风险已被消除的比例。
****项目组凝聚力：****这个分级因素表明了开发人员相互协作时可能存在的困难。
****过程成熟度：****这个分级因素反映了按照能力成熟度模型度量出的项目组织的过程成熟度。
进度计划
====
进度计划总述
软件项目的进度安排通过把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工作量分布于计划好的项目持续期内。
进度计划将随着时间的流逝而不断演化。
一、估算开发时间
各种模型估算开发时间的方程很相似，例如：?
Walston_Felix 模型??
T=2.5E0.35
原始的 COCOMO 模型??
T=2.5E0.38
COCOMO2 模型??
T=3.0E0.33+0.2×(b-1.01)
Putnam 模型??
T=2.4E1/3
其中，E 是开发工作量（以人月为单位），T 是开发时间（以月为单位）。?
经验告诉我们，随着开发小组规模扩大，个人生产率将下降，以致开发时间与从事开发工作的人数并不成反比关系。出现这种现象主要有下述两个原因：?
当小组变得更大时，每个人需要用更多时间与组内其他成员讨论问题、协调工作，因此增加了通信开销。
如果在开发过程中增加小组人员，则最初一段时间内项目组总生产率不仅不会提高反而会下降。
Brooks 规律：向一个已经延期的项目增加人力，只会使得它更加延期。
存在一个最佳的项目组规模 Popt，这个规模的项目组其总生产率最高。项目组的最佳规模是 5.5 人，即 Popt=5.5。
二、Gantt 图
Gantt(甘特)图是历史悠久、应用广泛的制定进度计划的工具。
例子：
旧木板房刷漆工程(15 名工人，工具各 5 把)?
Gantt 图的主要优点：
Gantt 图能很形象地描绘任务分解情况，以及每个子任务(作业)的开始和结束时间。
具有直观简明和容易掌握、容易绘制的优点。
Gantt 图的 3 个主要缺点：
不能显式地描绘各项作业彼此间的依赖关系；
进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象；
计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。?
三、工程网络
工程网络是制定进度计划时另一种常用的图形工具，它同样能描绘任务分解情况以及每项作业的开始时间和结束时间。
它能显式地描绘各个作业彼此间的依赖关系。
工程网络是系统分析和系统设计的强有力的工具。
符号：
四、估算工程进度
工程网络必要的信息：
****每个作业估计需要使用的时间：****箭头长度和它代表的作业持续时间没有关系，箭头仅表示依赖关系，它上方的数字才表示作业的持续时间。
****最早时刻 EET：****该事件可以发生的最早时间。
****最迟时刻 LET：****在不影响竣工时间的前提下，该事件最晚可以发生的时刻。
****机动时间：****实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些，而并不影响工程的结束时间。?
最早时刻的计算：
事件的最早时刻是该事件可以发生的最早时间。
通常工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。
计算最早时刻 EET 使用下述 3 条简单规则：?
■考虑进入该事件的所有作业；
■对于每个作业都计算它的持续时间与起始事件的 EET 之和；
■选取上述和数中的最大值作为该事件的最早时刻 EET。?
最迟时刻的计算：
事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻。
按惯例，最后一个事件(工程结束)的最迟时刻就是它的最早时刻。其他事件的最迟时刻在工程网络上从右至左按逆作业流的方向计算。
计算最迟时刻 LET 使用下述 3 条规则：?
■考虑离开该事件的所有作业；
■从每个作业的结束事件的最迟时刻中减去该作业的持续时间；
■选取上述差数中的最小值作为该事件的最迟时刻 LET。?
五、机动时间
某些作业有一定程度的机动余地——实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些，而并不影响工程的结束时间。
机动时间=(LET)结束－(EET)开始－持续时间=右下角－左上角－持续时间
在制定进度计划时仔细考虑和利用工程网络中的机动时间，往往能够安排出既节省资源又不影响最终竣工时间的进度表。?
六、关键路径
最早时刻和最迟时刻相同的事件(机动时间为 0 的作业)定义了关键路径，在图中关键路径用粗线箭头表示。
关键路径上的事件(关键事件)必须准时发生，组成关键路径的作业(关键作业)的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。
人员组织
====
人员组织总述
为了成功地完成软件开发工作，项目组成员必须以一种有意义且有效的方式交互和通信。
管理者应该合理地组织项目组，使项目组有较高生产率，能够按预定的进度计划完成所承担的工作。
除了追求更好的组织方式之外，每个管理者的目标都是建立有凝聚力的项目组。
一个有高度凝聚力的小组由一批团结得非常紧密的人组成，他们的整体力量大于个体力量的总和。
一、民主制程序员组
民主制程序员组的一个重要特点是，小组成员完全平等，享有充分民主，通过协商做出技术决策。因此，小组成员之间的通信是平行的，如果小组内有 n 个成员，则可能的通信信道共有 n(n-1)/2 条。
程序设计小组的人数不能太多，否则组员间彼此通信的时间将多于程序设计时间。
民主制程序员组通常采用非正式的组织方式，也就是说，虽然名义上有一个组长，但是他和组内其他成员完成同样的任务。
民主制程序员组的优点：
■组员们对发现错误抱着积极的态度，有助于更快地发现错误，导致高质量的代码；
■小组成员享有充分民主，有高度凝聚力，学术空气浓厚，利于攻克技术难关；
■若组内多数成员经验丰富，那么本组织方式会非常成功。
民主制程序员组的缺点：
如果组内多数成员技术水平不高，或是缺乏经验的新手，由于没有明确的权威指导开发工程的进行，组员间将缺乏必要的协调，最终可能导致工程失败。?
二、主程序员组
采用这种组织方式的原因：
软件开发人员多数比较缺乏经验；
程序设计过程中有许多事务性的工作，例如，大量信息的存储和更新；
多渠道通信很费时间，将降低程序员的生产率。
主程序员组的两个重要特性：
1、专业化。该组每名成员仅完成他们受过专业训练的那些工作。
2、层次性。主程序员指挥成员工作并全面负责。
典型的主程序员组由主程序员、后备程序员、编程秘书以及 1~3 名程序员组成。?
主程序员组核心人员的分工：
主程序员既是成功的管理人员又是经验丰富、技术好、能力强的高级程序员，负责体系结构设计和关键部分的详细设计，并且负责指导其他程序员完成详细设计和编码工作。?
还未添加个人签名 2021.03.18 加入
还未添加个人简介
评论