除了软件编码,在软件项目管理阶段所需要进行哪些工作
发表时间:2023-10-16 08:03:55
文章来源:炫佑科技
浏览次数:199
菏泽炫佑科技
除了软件编码,在软件项目管理阶段所需要进行哪些工作
你好! 我是灰小猿,一个有故事、爱分享、无技能的程序员。
今天大灰狼就来和大家聊聊在软件项目管理阶段除了软件编码之外还需要做哪些工作。 预祝您从技术人员晋升为产品总监一切顺利!
很多刚进入软件行业或者正在学习的朋友都有这种感觉。 他们认为编码阶段是软件开发的关键步骤,但事实上并非如此。 如果我们把软件开发过程比作建造一座桥梁,那么编码阶段只是建筑工人添砖加瓦的施工过程,更多的环节还包括软件的设计、管理、维护等。 这也是软件开发过程中必不可少的阶段和过程。
软件项目管理阶段所需的工作有:软件规模评估、工作量评估、进度规划、人员组织、质量保证、软件配置管理、能力成熟度模型。
接下来大灰狼就和大家说说各个阶段的任务和考核方法。 (文章较长,朋友们可以保存下来,以后学习)
软件项目管理
首先,什么是软件项目管理?
所谓管理,就是通过计划、组织、控制等一系列活动,合理配置和使用各种资源,以实现既定目标的过程。
软件项目管理在任何技术活动之前开始,并持续贯穿软件的整个生命周期。
软件项目管理流程从一组基于工作量估计和完成期限估计的项目规划活动开始。
为了估计项目的工作量和截止日期,您首先需要估计软件的大小。
软件规模评估
常用的软件规模评估方法有代码行技术和功能点技术。 这两种评估方法各有优缺点。 接下来大灰狼就和大家一起分析一下:
1. 行代码技术
代码行技术是一种相对简单的定量估计软件大小的方法。
根据以往开发类似产品的经验和历史数据,估算实现某个功能所需的源程序行数。
当有同类产品过去开发的历史数据可供参考时,估算值相对准确。 通过累加实现每个功能所需的源程序行数,我们就可以得到实现整个软件所需的源程序行数。
估算方法:
估算由多名经验丰富的软件工程师分别进行。
每个人估计程序的*小尺寸 (a)、*大尺寸 (b) 和*可能的尺寸 (m)。
分别计算出这三个大小的平均值和总和后,使用以下公式计算程序大小的估计值:
单位:LOC 或 KLOC。
行代码技术的优点:
行代码技术的缺点:
2、功能点技术
功能点技术根据软件信息领域特征和软件复杂度的评估结果来估算软件规模。
此方法以功能点 (FP) 为单位测量软件大小。
1. 信息领域特征
功能点技术定义了信息域的五个特征:
每个特征根据其复杂程度分配一个功能点,即信息域特征系数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
功能点技术优势:
与使用的编程语言无关,它比代码行技术更合理。
功能点技术缺点:
在判断信息领域特征的复杂程度和技术因素的影响程度时,主观因素较大,对经验的依赖性较强。
工作量评估
工作量的评估通常包括:静态单变量模型、动态多变量模型、模型、
值得注意的是,大多数估计模型的经验数据都是从有限数量的项目样本集中总结出来的。
没有一种估算模型适合所有类型的软件和开发环境。
明确了以上两点之后,接下来就是各个模型的评估方法。
1. 静态单变量模型
整体结构形式如下:
E = A + B × (ev) C
其中,A、B、C 为经验数据得出的常数,E 为人月工作量,ev 为估计变量(KLOC 或 FP)。
1. 面向KLOC的估计模型
(1)型号
E=5.2×(KLOC)0.91
(2)型号
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) & 型号
E=-13.39+0。
(2)、型号
E=585.7+15.12FP
2. 动态多变量模型
动态多变量模型,也称为软件方程,将工作量视为两个变量的函数:软件大小和开发时间。
动态多元估计模型的形式如下:
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。 适用于当前项目的生产率参数值可以从历史数据中得出。
3. 型号
它是结构成本模型(cost model)的英文缩写。
Boehm于1981年在《软件工程经济学》中首次提出该模型。
Boehm 等人提出的模型。 1997年的模型是原模型的修订版,反映了十多年来在成本估算方面积累的经验。
给出了三级软件开发工作量估算模型。 在估计工作量时,这三级模型逐渐提高了考虑软件细节的详细程度。
三个层次的估计模型是:
应用系统组成模型:该模型主要用于估算构建原型的工作量。 该模型的名称意味着在构建原型时使用了大量现有组件。
早期设计模型:该模型适用于建筑设计阶段。
架构后模型:该模型适用于架构设计完成后的软件开发阶段。
该模型将软件开发工作表示为代码行数的非线性函数 (KLOC):
其中,E为开发工作量(以人月为单位),a为模型系数,KLOC为预计源代码行数,b为模型指数,fi(i=1~17)为成本因素。
每个成本因素根据其重要性和对工作量的影响被分配一个特定的值(称为工作量系数)。
与原模型相比,模型中使用的成本因素有以下变化。
为了确定工作量方程中模型索引 b 的值,使用了更加精细的 b 分级模型。 该模型使用5个分级因子Wi(1≤i≤5),其中每个因子分为从非常低(Wi=5起有6个级别)到超高(Wi=0),然后使用以下公式计算 b 的值:
因此,b的取值范围为1.01~1.26。 显然,这种评分模式比原来的模式更加精细和灵活。
使用的 5 个评分因素如下所述:
项目先例:该评分因素表明该项目对开发组织的新颖程度。
开发灵活性:该评分因素反映了实现预定的外部接口要求和尽早开发产品所需的更多努力。
风险消除程度:该分级因素反映了已消除的重大风险的比例。
项目团队凝聚力:此评分因素表明开发人员在相互协作时可能遇到的困难。
过程成熟度:该分级因素反映了通过能力成熟度模型衡量的项目组织的过程成熟度。
进度计划 进度计划概述
软件项目计划通过将工作量分配给特定的软件工程任务并指定完成每个任务的开始和结束日期,在计划的项目持续时间内分配估计的项目工作量。
时间表将随着时间的推移而变化。
1. 预估开发时间
估计各种模型的开发时间的方程非常相似,例如:
T=2.5E0.35
T=2.5E0.38
T=3.0E0.33+0.2×(b-1.01)
T=2.4E1/3
其中,E为开发工作量(人月),T为开发时间(月)。
经验告诉我们,随着开发团队规模的增加,个人生产力会下降,因此开发时间与开发人员数量并不成反比。 出现这种现象主要有以下两个原因:
当团队规模变大时,每个人都需要花更多的时间与团队中的其他成员讨论问题、协调工作,从而增加了沟通开销。
如果在开发过程中增加更多的团队成员,项目团队的整体生产力在初期不仅不会增加,反而会下降。
规则:向已经延迟的项目增加人力只会让项目更加延迟。
存在一个*优的项目团队规模Popt,该规模的项目团队整体生产力*高。 项目团队的*优规模为5.5人,即Popt=5.5。
2. 甘特图
甘特图是一种历史悠久且广泛使用的制定时间表的工具。
例子:
老木屋粉刷工程(工人15人,工具5件)
甘特图的主要优点:
甘特图的 3 个主要缺点:
3、工程网络
工程网络是制定进度表时常用的另一种图形工具。 它们还描述了任务的分解以及每项活动的开始和结束时间。
它可以明确地描述各种作业之间的依赖关系。
工程网络是系统分析和系统设计的强大工具。
象征:
4. 估算项目进度
工程网络必备信息:
每个作业所需的预计时间:箭头的长度与其代表的作业的持续时间无关。 箭头仅代表依赖关系,其上方的数字代表作业的持续时间。
*早时间 EET:事件可能发生的*早时间。
*晚时间LET:在不影响完成时间的情况下该事件可以发生的*晚时间。
机动时间:实际开始时间可以晚于预定时间,或者实际工期可以长于预定工期,不影响项目结束时间。
*早时刻的计算:
事件的*早时刻是指该事件*早发生的时间。
通常将工程网络中**个事件的*早时刻定义为零,并按照事件发生的顺序在工程网络上从左到右计算其他事件的*早时刻。
计算*早时间 EET 使用以下三个简单规则:
■考虑进入事件的所有操作;
■对于每个作业,计算其持续时间与启动事件的EET之和;
■选择上述总和中的*大值作为事件的*早EET时间。
*晚时间的计算:
事件的*晚时间是指在不影响项目完成时间的情况下该事件可以发生的*晚时间。
按照惯例,*后一个事件(项目结束)的*新时刻是其*早时刻。 其他事件的*新时间在工程网络上按照与作业流程相反的方向从右到左计算。
下面3条规则用于计算*晚时间LET:
■考虑离开活动的所有工作;
■从每个作业*晚结束事件的时间中减去该作业的持续时间;
■选择上述差值中的*小值作为事件的*晚时间LET。
5. 机动时间
有些工作有一定的回旋余地——实际开始时间可以晚于预定时间,或者实际工期可以长于预定工期,而不会影响项目的完成时间。
机动时间=(LET)结束-(EET)开始-持续时间=右下角-左上角-持续时间
在制定进度表时,仔细考虑和利用工程网络中的机动时间通常可以得到节省资源而不影响*终完成时间的进度表。
6. 关键路径
*早时间和*晚时间相同的事件(机动时间为0的操作)定义了关键路径,图中用粗箭头表示。
关键路径上的事件(关键事件)必须按时发生,并且构成关键路径的活动(关键活动)的实际持续时间不能超过预计持续时间,否则项目将无法按时结束。
人事组织 人事组织概述
为了成功完成软件开发工作,项目团队成员必须以有意义且有效的方式进行互动和沟通。
管理者应合理组织项目组,使项目组具有较高的生产力,能够按照预定的进度完成其所承担的工作。
除了追求更好的组织方式之外软件开发,每个经理的目标都是建立有凝聚力的项目团队。
一个高度凝聚力的团体是由一群紧密团结在一起的人组成,他们的集体力量大于个人力量的总和。
1.民主程序员团
民主程序员群体的一个重要特点是,群体成员完全平等,享有充分的民主,通过协商做出技术决策。 因此,小组成员之间的交流是并行的。 如果组中有n个成员,则有n(n-1)/2个可能的通信通道。
编程团队的人数不能太多,否则团队成员之间沟通的时间会比编程的时间多。
民主程序员团体通常采用非正式的组织方式,即虽然有一个名义上的小组领导,但他和小组的其他成员完成相同的任务。
民主程序员团体的优点:
■团队成员对发现错误有积极的态度,这有助于更快地发现错误并产生高质量的代码;
■团队成员充分民主,凝聚力高,学术氛围浓厚,有利于攻克技术难点;
■如果小组中的大多数成员都有经验,那么这种组织方法将会非常成功。
民主程序员团体的缺点:
如果团队中大部分成员技术水平较低,或者是缺乏经验的新手,那么团队成员之间就会因为没有明确的权限来指导开发项目而缺乏必要的协调,*终可能导致项目失败。
2. 主要程序员组
采用这种组织方法的原因:
大多数软件开发人员都相对缺乏经验;
编程过程中有很多事务性任务,比如大量信息的存储和更新;
多通道通信非常耗时,并且会降低程序员的工作效率。
高手程序员群体的两个重要特征:
1、专业化。 团队的每个成员只执行他们接受过专业培训的任务。
2. 等级制度。 主程序员指导成员的工作并全面负责。
一个典型的主程序员团队由一名主程序员、一名后备程序员、一名编程秘书以及1至3名程序员组成。
主程序员组核心人员分工:
主程序员既是一位成功的管理者,又是一位经验丰富、技术精湛、能力强的高级程序员。 负责关键部分的架构设计和详细设计,并负责指导其他程序员完成详细设计和编码工作。
后备程序员还应该是一名熟练且经验丰富的程序员,他协助主程序员并在必要时接管(例如,如果主程序员生病、出差或“跳槽”)。
编程秘书负责完成与项目相关的所有事务性工作,例如维护项目数据库和项目文档,编译、链接和执行源程序和测试用例。
首席程序员小组的组织方式不切实际:
首先,主力程序员应该是高级程序员和优秀管理人员的结合体。 通常,成功的管理者和熟练的程序员都短缺。
其次,后备程序员更难找到。
第三,编程秘书也难找。
3. 现代程序员群体
实际的“首席程序员”角色应该由两个人共同承担:
一个技术负责人负责团队的技术活动,参与所有的代码评审工作,因为他对代码各方面的质量负责;
负责所有非技术事务管理决策的行政人员不能参与代码审查,因为他的工作是评估程序员的表现。 行政团队负责人应在定期安排会议期间了解每个团队成员的技术能力和表现。
由于程序员小组成员的数量不宜过多,因此当软件项目规模较大时,应将程序员分成若干小组。 该图描绘了技术管理组织结构,非技术管理组织结构类似。
另一种结合民主程序员群体和大师程序员群体优势的方法是在适当的情况下使用去中心化决策。 有利于形成畅通的沟通渠道,让每个程序员充分发挥积极性和主动性,集思广益,攻克技术难关。
质量保证 1. 软件质量
简而言之,软件质量是“软件符合显式和隐式定义的需求的程度”。
软件质量是指软件符合明确规定的功能和性能要求、文档中明确描述的开发标准以及任何专业开发的软件产品应具有的隐含特征的程度。
该定义强调了以下三点:
■软件需求是衡量软件质量的基础。 与要求不一致意味着质量低下。
■特定的开发标准定义了一套指导软件开发的指南,不遵守这些指南几乎肯定会导致软件质量低劣。
通常,存在一组未明确描述的隐含要求。 如果软件满足明确规定的要求但不满足隐含的要求,那么该软件的质量仍然值得怀疑。
影响软件质量的主要因素是从管理角度对软件质量的衡量。 这些质量因素可以分为三组,分别反映了用户在使用软件产品时的三种不同倾向或观点。 这三种倾向是:产品运营、产品修改、产品转移。
2、软件质量保证措施
软件质量保证(SQA)措施主要包括:
■基于非执行测试(或),主要用于保证编码前各阶段生成文档的质量;
■程序编写完成后需要进行基于执行的测试(软件测试)。 是保证软件质量的*后一道防线;
■程序正确性证明,用数学方法严格验证程序与其描述是否完全一致。
1、技术审查的必要性
正式技术审查的一个显着优势是及早发现软件错误,从而防止它们传播到软件过程的后续阶段。
统计显示,在大型软件产品中检测到的错误中,60%到70%是规范错误或设计错误,而正式的技术评审在发现规范错误和设计错误方面的效率高达75%。 通过能够检测并消除大多数错误,审查可以显着降低后续开发和维护阶段的成本。
正式技术评审是软件质量保证措施的一种除了软件编码,在软件项目管理阶段所需要进行哪些工作,包括演练()和评审()等具体方法。 排查涉及的步骤比检查少,而且不像检查那么正式。
2. 演练
演练团队由 4 至 6 名成员组成。 演练团队负责人指导团队成员浏览文档,尝试找出尽可能多的错误。
演练团队的任务只是标记错误而不是纠正错误。 纠错工作应由文件编写团队完成。
*长演练时间不应超过 2 小时。 这个时间应该用来发现和标记错误,而不是纠正错误。
演练的方法主要有两种:
■参与者驱动的方法
■文档驱动法
3. 回顾
■概述:负责编写文档的团队成员向审核小组审核该文档。
■准备:审阅者仔细阅读文档。
■审核:审核小组仔细审阅整个文档。
■返工:文档作者负责解决审阅报告中列出的所有错误和问题。
■跟进:团队负责人必须确保提出的每个问题都得到圆满解决。
一般情况下,审核小组由4人组成。 组长既是评审组的经理,又是技术组长。 审核过程不仅比演练步骤更多,而且每个步骤都是正式的。
4. 程序正确性证明
20世纪60年代初,人们开始研究程序正确性证明技术,并提出了许多不同的技术方法。
手动证明程序的正确性对于评估小程序可能有一定的价值,但是当涉及到证明大型软件的正确性时,不仅工作量太大,更重要的是,证明过程中很容易出现错误,所以不实用。 出于实用目的,有必要研究能够证明程序正确性的自动化系统。
用于证明LISP程序正确性的程序系统已经开发出来,并且这些系统正在被评估和改进。 目前这些系统只能评估较小的程序。
软件配置管理 软件配置管理概述
软件配置管理是一组用于管理整个软件生命周期中的变更的活动。
具体来说,这组活动用于:①识别变化; ②控制权变更; ③ 确保变更得到适当实施; ④ 将变更情况报告给需要了解信息的人员。
软件配置管理的目标是使变更更加准确、更容易适应,减少需要变更时所需的工作量。
一、软件配置 1、软件配置项
软件过程的输出信息可以分为3类:
■计算机程序(源代码和可执行程序);
■描述计算机程序的文档(供技术人员或用户使用);
■数据(包含在程序内或程序外)。
以上几项构成了软件过程中产生的所有信息。 我们统称为软件配置,这些项就是软件配置项。
2. 基线
基线是一种软件配置管理概念,可以帮助我们控制更改,而不会严重妨碍合法更改。
IEEE 将基线定义为已通过正式审查并可作为进一步开发的基础且只能通过正式变更控制流程进行更改的规范或中间产品。
简单来说,基线就是通过正式审核的软件配置项。
2.软件配置管理流程
具体来说,软件配置管理有五个主要任务:识别、版本控制、变更控制、配置审计和报告。
1. 识别软件配置中的对象
为了控制和管理软件配置项,每个配置项必须单独命名,然后使用面向对象的方法进行组织。 可以识别两种类型的对象:
■基本对象是软件工程师在分析、设计、编码或测试过程中创建的“文本单元”。
■聚合对象是基本对象和其他聚合对象的集合。
2.版本控制
版本控制使用过程和工具的组合来管理在软件工程过程中创建的配置对象的不同版本。
借助版本控制技术,用户可以通过选择合适的版本来指定软件系统的配置。
3. 变更控制
一个典型的变更控制流程如下:
■首先评估变更的技术得失、可能产生的副作用、对其他配置对象和系统功能的总体影响以及预计的修改成本。
■为每个批准的变更生成“工程变更单”。 要修改的对象从项目数据库中“提取”、修改并应用适当的 SQA 活动。
■*后,修改后的对象被“提交”到数据库,并使用适当的版本控制机制创建软件的下一个版本。
4. 配置审计
通常从以下两个方面采取措施:
■正式技术审查,重点关注修改配置对象的技术正确性。
软件配置审核通过评估审核过程中通常不考虑的配置对象的特征来补充正式的技术审核。
5. 状态报告
编写一份配置状态报告来回答以下问题:
■发生了什么事?
■这是谁干的?
■这是什么时候发生的?
■还会影响哪些其他事情?
能力成熟度 能力成熟度模型概述
能力成熟度模型( Model,CMM)是美国卡内基梅隆大学软件工程研究所在美国国防部的资助下于20世纪80年代末建立的用于评估软件组织软件过程能力成熟度的模型。
of CMM: CMM is a of the of a 's of , , , , and its .
A of CMM-based a CMM :
The basic idea of the Model is that the use of new does not and are by ways in which we . The model helps a and .
The of is a based on small steps one after , than a . CMM the of from to order into 5 , and sorts these to form 5 that are .
三坐标测量机
CMM the :
The of CMM:
, using CMM to the of the of the and its and
is used by to the of and . Based on the , it from low-level to -level and for .
, used by or to the risks of a with a .
1. level
are by and chaos. Few are (that is, there is no model), and the of a on the of the .
at this level do not have a sound . Their on the of the team, so it is . When the , the will also .
2. level
basic ( ) that track cost, , , and . have been , and the and for new is based on the of , so that with can again.
The of a at Level 2 can be as: the and of are and have a with a that can . are under the of the and plans based on the of .
3. level
The has a ( model), and the has been and . All teams use , to and . This level all the of level 2.
The of a at level 3 can be as, both and are . The cost and of as well as the and of the are all , and the of the is . This is based on a of the , , and of a model the .
4. level
The has for the ( model and ) and , and all of the are . This and and uses them to and and , and lays the for the and of the . This level all the of level 3.
The of a at level 4 can be as: the is and the a range. This level of to and a range, take to when they occur, and can be to be of high .
5. level
focus on of . A at this level is an whose goal is to . It has the to weak links in and has means to them. In such an , data on the of can be , which can be used to cost/ of new and the best new that can be in . This level all the of level 4.
The of a at level 5 can be as the is . at this level can their , not only and , but also with the help of new and .
The above are the main tasks and of the seven major of . If there are any , I hope will put them in time for .
炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等