weixin_43394532的博客

大家好，这节我们学习软件项目管理----软件项目配置管理计划–软件项目配置管理过程。主要学习：前五个过程描述的是配置管理的主要活动，最后一个配置管理计划过程是来规划解决活动的。将软件项目中需要进行控制的部分拆分成SCI。例如需求可能有5个文件，那么5个配置项，代码就多了，有很多文件，那么就对应着很多配置项。那么这个配置项定义过程可能是一个拆分的过程，例如项目需求规格可以拆成多个文件。其实这个拆分成多个配置项，对项目管理是有好处的，在项目执行过程中，需求的不同部分，修改的频率是不同的，因此需求的不同配置项变更

大家好，这节我们学习软件项目管理----软件项目配置管理计划–软件配置管理基本概念。介绍配置管理，配置项，基线，SCCB等概念。配置管理的核心功能是版本管理、变更管理、当然配置管理也演变出其他功能，比如过程管理等等这个图示说明了配置管理的作用：开发过程中有很多中间产品，以及不同版本，他们都需要配置管理监管，配置管理相当于大的仓库，起到一个较比的作用。配置项即SCI，是受控于软件配置管理的细目，是配置管理的最小单位，即管理的最小文件，需求规格可能是一个文件也可能是多个文件，因此，需求规格可以是一个配置项，也

大家好，这节我们学习软件项目管理----质量计划–软件质量计划。软件质量计划是质量过程之一确定项目应达到的质量标准或者目标，同时，决定如何满足质量标准的计划安排和方法。为了达到质量目标，需要安排活动和方法。即将质量保证和质量控制活动规划出来。当然这个质量目标要适中，不能太高也不能太低。例如这是SPM项目的质量目标,首先设定质量模型，根据模型计算质量值。质量目标是质量分值大于85。那么质量计划的输出形式没有统一的标准，关键是将质量活动体现出来，以便项目将来执行过程中可以参照执行。第一种形式就是将质量活动体

大家好，这节我们学习软件项目管理----质量计划–敏捷项目质量活动。敏捷项目的质量管理特征如下：以下这些是具体的敏捷活动：这个图展示了结对编程过程，两个人一起在电脑前编码，互相评审代码。有数据证明，结对编程可以提高代码质量和项目效率，是一种代码检查行为。如图这个数据说明了结对编程测试案例通过的百分比提高。这个图示说明了结对编程提高了工作的效率。测试驱动开发即TDD，测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完成全部功能

大家好，这节我们学习软件项目管理----质量计划–软件项目质量活动。软件质量管理最主要的两个过程是：质量管理的对象：软件质量保证既QA，QA对已经完成工作的评价和审核。很多行业都有涉后的评价和审核过程，比如银监会对银行的审核，食品监督委员会对食品行业的审核等等都属于QA。这个图是展示了第三方检查过程，既QA过程。QA是通过评价项目整体绩效，建立对质量要求的信任。比如QA审核某项目，审核的结果是从60，70，80逐渐上升的趋势，大家对这个项目信任感，反之就没有信任感。大家通过QA提供项目和产品可视化的管理报

大家好，这节我们学习软件项目管理----质量计划–质量基本概念。介绍软件质量，质量模型，质量的形成等概念…比如说我们买手机，同牌子的手机有5000元，也有2000元的，我们不能说5000元的质量就高于2000元的，他们的功能需求都各不相同，这是等级的不同。使用说明书上有明确的使用说明，如果5000元的手机不能打电话或者不能发短信了这就是质量问题了。所以质量是满足要求的程度,包括符合规定的要求和满足顾客隐含需求.例如手机的使用说明书有明确的功能和性能描述，而操作方便、外观漂亮等可以是隐含的需求。软件质量是软件

大家好，这节我们学习软件项目管理----进度计划—项目进度模型（SPSP）。软件项目进度问题（Software Project Scheduling Problem，SPSP）模型是在给定的项目任务工作量及其关系和资源限制下，对项目确定合适的人员安排，以保证项目的时间最短、成本最小。例如：这是某项目的网络图，以及某个任务需要的技能和工作量。这是每个人员具备的技能和人力成本。我们根据这些前提条件进行进度编排。目标是成本少时间短，为次生成一个目标函数，因为成本和时间的单位不一致，所以在时间前乘以一个权值，成本

大家好，这节我们学习软件项目管理----进度计划编排–敏捷计划方法。敏捷计划采用的是远期计划和近期计划的双重计划，而且采用远粗近细的原则，远期计划是发布计划，近期计划是迭代计划。我们通过将概要的项目整体规划和详细的近期迭代计划有机结合，可以提高计划的准确度和项目按时交付的能力。我们看这个图：发布计划规定了迭代次数，迭代计划安排了每个功能的开发。下面这个图是Scrum模型，是一个典型的敏捷模型，他的核心过程就是迭代过程，那么每个迭代是2-4周。计划任务从产品Backlog中选择，选择任务之后，就开始迭代开

大家好，这节我们学习软件项目管理—进度计划编排—资源优化方法。根据资源供需情况，调整活动的开始和完成日期。同时进行资源优化配置。例如：使资源前置的时间最小化，而且尽量避免出现资源超出能力的范围。那么资源优化主要有两个方法：资源平衡是为了在资源需求和资源供给之间取得平衡，根据资源制约因素对开始日期和完成日期进行调整的一种技术。例如：一个资源在同一时间内，分配给多个活动，这就需要通过调整任务的时间来协调资源的冲突。那么资源平衡往往导致关键路径的改变。例子：这个项目网络图中，A、B、C三个任务，A需要2天且2个开

大家好，这节我们学习软件项目管理----进度计划编排–时间压缩法。时间压缩法是在不改变项目范围的前提下缩短项目工期的方法。这边介绍两个方法：这个方法可能增加成本，但是我们希望增加的成本最小且换来项目时间的压缩。那么赶工时间与赶工成本是什么关系呢？如下图一样，一般项目经理希望多压缩一些时间，成本少增加一点，但这是一个美好的愿景。...

大家好，这节我们学习软件项目管理—进度计划编排–关键路径法。例如：我们看这个任务是10天，最早开始时间ES=1，最早完成时间EF=11，最晚开始时间LS=5，那么对应最晚完成时间LF=15。浮动时间是一个任务的机动性，它是一个任务在不影响其它任务或者项目完成的情况下可以延迟的时间量。例如：下图这个刚才的任务，可以1号开始，也可以5号开始，有4天的浮动，这就是浮动，这个浮动基本就是个总浮动的概念，我们一般说的浮动也是总浮动。如下图示的任务有4天的总浮动，但是不一定可以自由的使用。总浮动是在不影响项目最早完

大家好，这节我们学习软件项目管理—进度计划编排方法。这是某项目的进度计划编排结果，所以为了完成项目需要采用进度编排方法。进度编排的基本方法：这节我们介绍超前与滞后方法 。表示两个任务A和B，结束-开始的逻辑关系，进行任务编排的时候，在A和B之间增加一个延迟的时间Lag，这是一种等待的时间。举例：如果Lag=3，表示任务A完成3天，任务B就开始，延迟的时间量为3天。表示两个任务A和B是结束-开始的逻辑关系，进行任务编排的时候，将任务B的开始时间提前一个时间量Lead。例如：Lead=3，表示任务A在完成时

大家好，这节我们学习软件项目管理—敏捷历时估算。敏捷历时估算包括开发速度稳定前和开发速度稳定后两种情况。开发速度稳定前可以采用举手表决方法，类似快速故事点估算法，举手表决是从投票方法衍生出来的一种形式。项目经理组织举手表决：项目经理让团队成员针对某个决定进行举手表决经过几个迭代之后，开发速度稳定了，团队就能比较准确预测一个任务或项目将花费的时间。那么我们就可以采用基于故事点生产率的估算或者迭代生产率的估算。前提是要有稳定的故事点生产率。例如每个故事点的生产率是3天，比较稳定，那么目前项目共有30个故事点，则

大家好，这节我们学习软件项目管理—传统历时估算，进入项目进度计划的第三个过程-历时估算。历时估算就是估算持续的时间，包括任务、路径、项目的持续时间。历时估算分为传统历时估算方法和敏捷历时估算方法，这节主要介绍传统历时估算方法。定额估算法的思路比较简单，公式：T=Q/(R*S)其中T：活动历时，Q：任务工作量，R：人力数量，S：工作效率（贡献率）。举例：比如 任务工作量=6人天，人力数量=2人，工作效率=1，则活动历时为3天。如下图所示：这个估算方法适合规模比较小的项目，或者某个任务的历时估算。经验导出模型

大家好，这节我们学习软件项目管理—进度基本概念。首先介绍进度计划的重要性：进度是对执行的活动和里程碑制定的工作计划日期表。WBS定义了交付成果，为了完成项目的各个交付成果，所必须进行的所有具体活动就是项目任务。例如这是某项目的WBS，其中这个设计工作包交付成果就是设计说明书，为次需要两个任务，任务一和任务二。任务一是编写设计说明书，任务二是设计评审，以此类推，我们定义所有的项目任务。项目的任务之间存在一定的关联关系，例如编写设计说明书之后，才可以进行设计评审。由于项目各项任务之间存在一定的关联关系，需要根据

大家好，这节我们学习软件项目管理—成本预算。成本预算是将项目的总成本按照项目的进度分摊到各个工作单元中去。既将总的成本安排到各个用例中，这些任务项是基于WBS任务分解的结果。因此成本预算是形成以时间为基准的成本预算曲线，成本预算的目的是产生成本基线。可以作为将来成本控制的标准。是根据每个任务的资源分配情况来计算这个任务的成本预算。资源成本与资源的费率相关，所以要设置资源费率。例如资源费率是每天1000元，这个任务需要3人天的工作量，则这个任务的预算是3000元。当一个项目的资源需要固定数量的资金时，客户可

大家好，这节我们学习软件项目管理—敏捷估算法既Story point估算方法。大家知道，敏捷项目的需求采用story进行描述，那么工作量的估算则采用Story point估算方法。Story point概念为：即故事点，用来度量实现一个Story需要付出的工作量的相对估算。所以我们关注最后得到的相对估算结果，例如估算 故事A为1个Story Point,故事B为2个Story Point,则B的工作量是A的两倍。Story Point估算是一个相对估算的过程，需要确定相对的估算标准。这里给出两个常用的标准，

大家好，这节我们学习软件项目管理—专家估算法由多位专家进行成本估算，一个专家可能会有偏见，最好由多位专家进行估算，取得多个估算值,最后得出综合的估算值。其中Deiphi专家估算法是著名的专家估算法：Deiphi专家估算法基本步骤如下：例如某多媒体信息查询系统，采用专家估算方法进行估算。共有两个专家进行估算，第一个专家估算值分别是1,8,9 。第二个专家估算值分别是4,6,8 。则第一个专家最后估算值为7，第二个专家最后估算值为6，两个专家给出的估算值偏差在可以接受的范围内，所以最后的估算值为6.5 。到这里

大家好，这节我们学习软件项目管理—参数估算法，重点介绍COCOMO模型。参数估算也称为模型估算，是根据项目数据集合出来的模型，代码行，人数，时间，工时等都是项目数据。所以参数估算模型是通过统计技术得出的数学模型，然后根据这个模型估算软件项目的规模或者成本，参数模型是基于历史项目数据，项目类型不同，项目环境不同，项目数据也就不同，数据不同得出的模型也就不同。有很多组织根据自己的研究对象得出不同的估算模型。例如：这些模型的输入是代码行（LOC）这些模型的输入是功能点（FP）尽管模型各不相同，但是有基本相似的公式

大家好，这节我们学习软件项目管理—三点估算法。三点估算法是基于任务成本的三种估算值来计算预期成本的方法。这三种估算值分别是：最可能成本，最乐观成本，最悲观成本。最可能成本是比较现实的估算成本，既这个估算值成本的概率最大。最乐观成本是最好情况下所得到估算成本。最悲观成本是最差情况下所得到的的估算成本计算预期成本需要根据概率分布图情况来获得，有两种常用的概率分布，分别为三角分布和贝塔分布三角分布：预期成本=（最乐观成本+最可能成本+最悲观成本）/3贝塔成本：预期成本=（最乐观成本+4倍的最可能成本+最悲观成本）

大家好，这节我们学习软件项目管理—自下而上估算法。自下而上估算法的前提是任务分解完成，既WBS完成。估算的时候从最低层的工作包开始估算，然后自下而上，将估算值进行累加，最后得出上面的估算结果。采用自下而上估算方法是比较准确的，因为他是针对每一个工作包进行估算，他的准确度来源于每个任务的估算，另外WBS分解时也要求分解到足够详细，所以有准确估算的基础。那么这是一个银行业务估算的例子：采用自下而上估算法，首先进行任务分解，对分解后的每个工作包进行估算。估算的时候先确定各个子工作包投入的人力时间，从而估算成本，然

大家好，这节我们学习软件项目管理—类比估算方法。这是两个类似的产品，有相似的产品属性，在估算另一个产品时，可以参照这个产品的属性值。同理，采用类比估算方法，估算软件项目时，可以找一个相似的项目，根据相似项目总的工作量，成本来估算本项目的总规模成本，然后估算各个工作单元的规模成本，所以是一种自上而下的估算形式。那什么情况下采用类比估算呢？当项目信息不足的时候，要求不是非常精确估算的时候，有类似的历史项目数据。那如何确定项目相似呢？理论上需要计算相似度。例如：我们希望判断项目P0是否和P1或者P2相似，首先选择

大家好，这节我们学习软件项目管理—用例点估算法。用例点估算是基于需求用户视图的估算方法，通过需求用户视图中的角色，用例，以及相应的复杂度来确定项目的用例点。通过用例视图确定用例和角色以及相应的复杂级别。然后确定用例权值和角色权值，相加后获得未调整的用例点，再计算技术复杂度因子，通过这些因子来调整未调整的用例点获得用例点数，最后通过项目生产力将用例点换算为工作量。因此用例点估算方法的基本步骤如下：从公式看到UAW等于角色数乘以相应的权重之和，公式中的C是复杂度级别，aCardinality是相应级别的角色数量

大家好，这节我们学习软件项目管理—功能点估算法。代码行估算法与项目的实现语言等技术相关。而功能点估算与实现的语言和技术没有关系，用系统的功能数量来测量项目规模，是通过评估，加权，量化得出功能点。功能点公式：FP=UFC*TCF。其中UFC为未调整功能点计数，是未调整之前的数量。TCF是技术复杂度因子，是对UFC的调整因子。UFC是从五个角度得出的。五个功能计数项：“外部输入”，“外部输出”，“外部查询”，“外部接口文件”，“内部逻辑文件”。1.外部输入(External Inputs： EI）：给软件提供

大家好，这节我们学习软件项目管理—代码行估算法。即工作量，例如：软件规划，软件管理，需求分析，系统设计，编码，测试，以及后期维护等任务的工作量总和即为项目规模。代码行，功能点，人月，人天，人年等都可以是规模单位。有了软件项目规模就可以表示出项目成本。完成软件规模相应付出的代价就是软件成本，我们可以采用货币单位来表示软件成本。代码行估算法就是从软件程序量的角度定义项目规模。例如：某项目的规模是C语言1000代码行，那么代码行估算法与具体的编程语言相关。例如C语言的1000代码行用JAVA语言可能是600代码

【公众号 “项目管理研究所” 将会第一时间更新文章并[分享行业分析报告]】 归档于软件项目管理初级学习路线第五章 软件项目任务分解《初级学习路线合集 》前言大家好，这节我们学习软件项目管理—敏捷任务分解方法。一、敏捷项目的任务分解敏捷开发过程是通过用户故事，将需求具体化成可以进行迭代开发的任务。Epics是由许许多多小大的，不确定的需求组成，不能直接通过迭代开发，需要划分为较小的，真正的user stories。另外Epics有时包含着太多且模糊的需求，所以常常包含着不同的特性，.

【公众号 “项目管理研究所” 将会第一时间更新文章并[分享行业分析报告]】 归档于软件项目管理初级学习路线第五章 软件项目任务分解《初级学习路线合集 》前言大家好，这节我们学习软件项目管理—任务分解方法。介绍类比，模板参照，自上而下，自下而上的WBS任务分解方法、一、类比方法有些项目有相同或相似的周期，因此而形成的相同或相似的工作细目，那么这些项目进行任务分解的时候，可以采用类比的方法。二、模板参照如果某项目有可以参照的WBS模板，例如这个图就是用项目可以参照的WBS模板，在进行任务.

大家好，这节我们学习软件项目管理—任务分解基本概念，介绍任务分解，WBS，工作包，WBS字典等概念…

软件项目管理 4.3.敏捷需求建模方法【公众号 “项目管理研究所” 将会第一时间更新文章并分享行业分析报告】 归档于软件项目管理初级学习路线第四章 软件需求管理《初级学习路线合集 》前言大家好，这节我们学习软件项目管理—敏捷需求建模方法。一、建模方法敏捷思维认为项目需求是慢慢清楚的过程，对需求可以采用渐近明晰的方法应对变化。敏捷需求从Product Backlog(产品待办事项列表)开始，需求的来源包含产品想法的一个有序列表，一个长短不定列表，可以是模糊的或是不具体的，逐渐完善，越

大家好，这节我们学习软件项目管理—传统需求建模方法，接下来通过例子介绍主流建模方法，我们介绍：1.原型方法 2.基于数据流建模 3.基于UML建模。

软件项目管理 4.1.软件需求管理过程【公众号 “项目管理研究所” 将会第一时间更新文章并分享行业分析报告】 归档于软件项目管理初级学习路线第三章 生存期模型《初级学习路线合集 》前言大家好，这节我们学习软件项目管理—软件需求管理过程，需求管理过程分两个部分。第一个部分需求确认即确认需求规格，包括四个过程，需求获取，需求分析，需求规格编写，需求验证。第二个部分是开发过程中的需求管理即需求变更过程。既需求管理有五个过程：需求获取，需求分析，需求规格编写，需求验证，需求变更、一、需求

软件项目管理 3.5.敏捷生存期模型【公众号 “项目管理研究所” 将会第一时间更新文章】 归档于软件项目管理初级学习路线第三章 生存期模型《初级学习路线合集 》前言大家好，这节我们学习敏捷模型，前面介绍的几种生存期模型在实际应用过程中遇到的一些挑战，有时不能很好地适应需求的快速变化，为此软件界比较流行敏捷生命期模型。一、敏捷模型《敏捷宣言》价值观，原则，和通用实践之间的关系：敏捷模型符合敏捷宣言，并通过满足12个原则和实践体现出来的，敏捷模型结合了迭代和增量方法可以适应更频繁的变更和

软件项目管理 3.4.增量生存期模型【公众号 “项目管理研究所” 将会第一时间更新文章】 归档于软件项目管理初级学习路线第三章 生存期模型《初级学习路线合集 》前言大家好，这节我们学习软件项目管理—增量生存期模型，顾名思义，增量模型就是一个增量一个增量的开发过程，每一个增量是一个交付成果。一、增量模型增量模型向客户提交完成的可交付的成果，让用户可以立即使用，如果有些项目是为了加快交付速度，频繁交付少量的可交付成果，就可以采用增量模型。增量模型的策略是不同时开发项目的需求，而是分增量开

软件项目管理 3.3.迭代生存期模型【公众号 “项目管理研究所” 将会第一时间更新文章】 归档于软件项目管理初级学习路线第三章 生存期模型《初级学习路线合集 》前言大家好，这节我们学习软件项目管理—迭代生存期模型，迭代型是通过连续的原型概念验证，来改进产品或结果，每一个新的原型都能带来新的相关反馈和团队见解。一、迭代模型迭代有利于识别和减少项目的不确定性，迭代模型称为原型模型，不断对部分完成工作和未完成的工作进行反馈，从而对该工作进行改进和修改。原型模型的策略是通过构造原型来应用需

软件项目管理 3.2.预测生存期模型【公众号 “项目管理研究所” 将会第一时间更新文章】 归档于软件项目管理初级学习路线第三章 生存期模型《初级学习路线合集 》前言大家好，这节我们学习预测生存期模型，预测模型是一种传统模型，项目具有高确定性和很明确的需求，项目活动通常以顺序的方式执行，没有反馈。预测型模型主要有瀑布模型和V模型。一、瀑布模型瀑布模型是最经典，最传统的模型，他严格的要求项目按照秩序来执行，单向的如同瀑布一样，只能从上往下，不能返回，编码阶段不能执行修改需求和设计。瀑布模型

软件项目管理 3.1.生存期模型选择【公众号 “项目管理研究所” 将会第一时间更新文章】 归档于软件项目管理初级学习路线第三章 生存期模型《初级学习路线合集 》前言大家好，这节我们学习软件项目管理—生存期模型选择，为了提交一个满意的项目，需要选择项目实施的策略，选择策略的过程就是选择生存期模型的过程一、软件开发模型变迁软件开发模型总体上经历了从传统到敏捷的变迁过程1.从最开始的作坊式的单打独斗2.到cmm过程改进式的过程控制3.再到敏捷模型4.敏捷模型也发展出更多的模型，例如

软件项目管理 2.3.项目章程【公众号 “项目管理研究所” 将会第一时间更新文章】 归档于软件项目管理初级学习路线第二章 软件项目确立《初级学习路线合集 》前言大家好，这节我们学习软件项目章程概念一、项目章程项目章程是证明项目存在的正式书面说明和证明文件。由高级管理层签署，规定项目范围，如质量、时间、成本和可交付成果的约束条件，授权项目经理分派组织资源用于项目工作。通常是项目开始后第一份正式文件。主要包括两方面内容：一是项目满足的商业需求，二是产品描述。通常也会包括对项目经理,项目工作

软件项目管理 2.2.项目招投标流程【公众号 “项目管理研究所” 将会第一时间更新文章】 归档于软件项目管理初级学习路线第二章 软件项目确立《初级学习路线合集 》前言大家好，这节我们学习软件项目招投标过程，立项之后如果决定项目是委托外部来开发，可以通过招投标过程来选择合格的开发商即乙方一、项目招投标过程1.甲方招标书定义：招标书的定义主要是甲方的需求，即采购的内容，软件项目的验收标准等提交招标书2.乙方项目分析：乙方看到招标书后分析任务，如果可以参与竞标，既要提交标书即建议书。3，

软件项目管理 ——2.1.项目立项 归档于软件项目管理初级学习路线第二章 软件项目确立《初级学习路线合集 》前言大家好，这节我们学习软件项目立项概念一、项目启动背景项目启动的背景大致可以分为四类：1.符合法规，法律或者社会要求2.满足相关方的要求或需求3.执行，变更业务或技术战略4.创造，改进或修复产品，过程或服务二、软件项目启动启动项目是因为客户的需求，然后实现这个要求，最后提交给客户。但是 不是所有的需求都可以被

软件项目管理 ——1.3.敏捷项目管理概念 归档于软件项目管理初级学习路线第一章 软件项目管理基本概念文章目录软件项目管理 ——1.3.敏捷项目管理概念前言一、敏捷项目的由来？软件项目很特殊传统开发面临的挑战产生新的管理需求敏捷模型敏捷的核心价值敏捷原则项目管理核心三角形比对互联网企业敏捷转型补充：总结前言大家好，这节我们学习敏捷项目管理基本概念，说到软件项目管理不得不提敏捷管理，它的发展和应用是有目共睹的，最新的PMBOK也配套了敏捷实践指南一、敏捷项目的由来？软件项目很特殊软件项目的特殊决定了全部工程化