软件项目管理

从事软件开发的IT公司的职位模式可以分为两部分

软件创建
软件项目管理

项目是一个明确定义的任务，它是由若干操作按顺序执行以实现目标的集合（例如，软件开发和交付）。项目可以描述为：

每个项目可能都有一个独特且不同的目标。
项目不是例行活动或日常运营。
项目有开始时间和结束时间。
项目在其目标实现后结束，因此它是组织生命周期中的一个临时阶段。
项目需要充足的资源，包括时间、人力、资金、材料和知识库。

软件项目

软件项目是软件开发的完整过程，从需求收集到测试和维护，根据执行方法，在规定的时间内完成以实现预期的软件产品。

软件项目管理的必要性

软件被称为无形产品。软件开发是世界商业中一种全新的潮流，在构建软件产品方面经验很少。大多数软件产品都是定制的，以满足客户的需求。最重要的是，底层技术变化和进步如此频繁和迅速，以至于一个产品的经验可能无法应用于另一个产品。所有这些业务和环境限制都会给软件开发带来风险，因此有效地管理软件项目至关重要。

上图显示了软件项目的三重约束。对于软件组织来说，在保持成本在客户预算限制内的同时，按计划交付高质量的产品是至关重要的。有几个内部和外部因素可能会影响这个三重约束三角形。任何三个因素中的一个都可能严重影响其他两个因素。

因此，软件项目管理对于结合用户需求以及预算和时间限制至关重要。

软件项目经理

软件项目经理是一个承担执行软件项目责任的人。软件项目经理充分了解软件将经历的SDLC的所有阶段。项目经理可能从未直接参与最终产品的生产，但他控制和管理生产中涉及的活动。

项目经理密切监控开发过程，准备和执行各种计划，安排必要的和充足的资源，维护所有团队成员之间的沟通，以解决成本、预算、资源、时间、质量和客户满意度的问题。

让我们看看项目经理肩负的一些职责 -

人员管理

担任项目领导
与利益相关者联络
管理人力资源
建立汇报等级等。

项目管理

定义和设置项目范围
管理项目管理活动
监控进度和绩效
每个阶段的风险分析
采取必要的步骤来避免或解决问题
担任项目发言人

软件管理活动

软件项目管理包括许多活动，其中包括项目规划、确定软件产品的范围、估算各种方面的成本、任务和事件的调度以及资源管理。项目管理活动可能包括：

项目规划
范围管理
项目估算

项目规划

软件项目规划是在软件实际生产开始之前执行的任务。它为软件生产服务，但不涉及任何与软件生产有直接联系的具体活动；而是一组促进软件生产的多个过程。项目规划可能包括以下内容：

范围管理

它定义项目的范围；这包括为了制作可交付的软件产品而需要完成的所有活动和流程。范围管理至关重要，因为它通过明确定义项目中将完成哪些工作以及不完成哪些工作来创建项目的边界。这使得项目包含有限且可量化的任务，这些任务可以轻松记录，从而避免成本和时间超支。

在项目范围管理期间，有必要 -

定义范围
决定其验证和控制
将项目分解成多个较小的部分，以便于管理。
验证范围
通过合并对范围的更改来控制范围

项目估算

为了有效管理，准确估算各种指标是必须的。通过正确的估算，管理人员可以更有效地管理和控制项目。

项目估算可能包括以下内容：

软件规模估算
软件规模可以用KLOC（千行代码）来估算，也可以通过计算软件中的功能点来估算。代码行数取决于编码实践，功能点根据用户或软件需求而变化。
工作量估算
管理人员根据生产软件所需的人员需求和工时来估算工作量。对于工作量估算，应该知道软件规模。这可以通过管理人员的经验、组织的历史数据获得，或者可以使用一些标准公式将软件规模转换为工作量。
时间估算
一旦估算出规模和工作量，就可以估算出生产软件所需的时间。根据需求规范和软件各个组件的相互依赖性，将所需的工作量细分为子类别。软件任务通过工作分解结构 (WBS) 分解成更小的任务、活动或事件。任务按天或日历月安排。

完成所有任务所需时间的总和（以小时或天为单位）是完成项目所需的总时间。
成本估算
这可能是所有估算中最困难的，因为它依赖于比任何先前因素更多的元素。为了估算项目成本，需要考虑 -

软件规模
软件质量
硬件
额外的软件或工具、许可证等。
具有特定任务技能的熟练人员
差旅费用
沟通
培训和支持

项目估算技术

我们讨论了项目估算中涉及的各种参数，例如规模、工作量、时间和成本。

项目经理可以使用两种广为认可的技术来估算上述因素 -

分解技术

这种技术将软件视为各种成分的产物。

主要有两个模型 -

代码行数估算基于软件产品中的代码行数。
功能点估算基于软件产品中的功能点数。

经验估算技术

此技术使用经验得出的公式进行估算。这些公式基于LOC或FP。

普特南模型
此模型由劳伦斯·H·普特南创建，基于诺登的频率分布（瑞利曲线）。普特南模型将所需的时间和工作量与软件规模对应起来。
COCOMO
COCOMO代表建设性成本模型，由Barry W. Boehm开发。它将软件产品分为三类软件：有机型、半独立型和嵌入型。

项目进度安排

项目进度安排是指所有活动的路线图，这些活动需要以指定的顺序并在分配给每个活动的时段内完成。项目经理倾向于定义各种任务和项目里程碑，并考虑到各种因素来安排它们。他们寻找计划中关键路径上的任务，这些任务需要以特定方式（由于任务相互依赖）并在分配的时间内严格完成。安排关键路径之外的任务不太可能影响项目的整体进度。

为了安排项目，有必要 -

将项目任务分解成更小、更易于管理的形式
找出各种任务并关联它们
估算每个任务所需的时间范围
将时间划分为工作单元
为每个任务分配足够数量的工作单元
计算从项目开始到结束所需的总时间

资源管理

用于开发软件产品的所有元素都可以被认为是该项目的资源。这可能包括人力资源、生产工具和软件库。

资源的数量有限，并作为资产池保留在组织中。资源短缺会阻碍项目的开发，并可能落后于进度。分配额外的资源最终会增加开发成本。因此，有必要估算和分配项目所需的充足资源。

资源管理包括 -

通过创建项目团队并将责任分配给每个团队成员来定义合适的组织项目
确定特定阶段所需的资源及其可用性
在需要资源时生成资源请求，并在不再需要时取消分配资源。

项目风险管理

风险管理包括所有与识别、分析和为项目中可预测和不可预测的风险做准备的活动。风险可能包括以下内容：

经验丰富的员工离开项目，新的员工加入。
组织管理的变化。
需求变更或误解需求。
低估所需的时间和资源。
技术变化、环境变化、商业竞争。

风险管理流程

风险管理流程中涉及以下活动：

识别 - 记录项目中可能发生的所有风险。
分类 - 根据已知风险对项目可能造成的潜在影响，将其分类为高、中和低风险强度。
管理 - 分析风险在各个阶段发生的概率。制定规避或应对风险的计划。努力将风险的负面影响降到最低。
监控 - 密切监控潜在风险及其早期征兆。同时监控为减轻或避免风险而采取的措施的效果。

项目执行与监控

在此阶段，项目计划中描述的任务将按照其进度执行。

执行需要监控，以检查一切是否按照计划进行。监控是指观察以检查风险的概率，并采取措施来解决风险或报告各种任务的状态。

这些措施包括 -

活动监控 - 可以对任务中安排的所有活动进行每日监控。当任务中的所有活动都完成后，则认为该任务已完成。
状态报告 - 报告包含在给定时间段（通常为一周）内完成的活动和任务的状态。状态可以标记为已完成、待定或进行中等等。
里程碑检查表 - 每个项目都细分为多个阶段，在这些阶段中根据SDLC的阶段执行主要任务（里程碑）。此里程碑检查表每隔几周准备一次，并报告里程碑的状态。

项目沟通管理

有效的沟通在项目的成功中起着至关重要的作用。它弥合了客户与组织之间、团队成员之间以及项目中的其他利益相关者（例如硬件供应商）之间的差距。

沟通可以是口头的或书面的。沟通管理过程可能包括以下步骤

计划 - 此步骤包括识别项目中的所有利益相关者以及他们之间的沟通方式。它还考虑是否需要任何额外的沟通设施。
共享 - 在确定计划的各个方面之后，管理者专注于在正确的时间与正确的人分享正确的信息。这使每个参与项目的人都了解项目的进度及其状态。
反馈 - 项目经理使用各种措施和反馈机制，并创建状态和绩效报告。此机制确保来自各个利益相关者的投入作为他们的反馈传达给项目经理。
结束 - 在每个重大事件结束、SDLC阶段结束或项目本身结束时，将正式宣布管理结束，通过发送电子邮件、分发文档的硬拷贝或其他有效的沟通方式来更新每个利益相关者。

结束之后，团队将转入下一阶段或项目。

配置管理

配置管理是一个跟踪和控制软件变化的过程，这些变化涉及产品的需求、设计、功能和开发。

IEEE将其定义为“识别和定义系统中的项目，控制这些项目在其整个生命周期中的变化，记录和报告项目和变更请求的状态，以及验证项目的完整性和正确性的过程”。

通常，一旦SRS最终确定，用户就很少需要更改需求。如果发生更改，则只有在获得高级管理层的批准后才能处理这些更改，因为这可能会导致成本和时间的超支。

基线

如果某个SDLC阶段已建立基线，则认为该阶段已结束，即基线是定义阶段完整性的度量。当与某个阶段相关的所有活动都已完成并有良好文档记录时，该阶段就已建立基线。如果它不是最终阶段，则其输出将用于下一个直接阶段。

配置管理是组织管理的一门学科，它负责处理在阶段建立基线后发生的任何变化（流程、需求、技术、策略等）。CM会检查软件中所做的任何更改。

变更控制

变更控制是配置管理的功能，它确保对软件系统进行的所有更改都是一致的，并且符合组织的规则和规章。

产品配置的更改将经历以下步骤 -

识别 - 变更请求来自内部或外部来源。当正式识别变更请求时，会对其进行适当的记录。
验证 - 检查变更请求的有效性并确认其处理程序。
分析 - 就进度、成本和所需工作量而言，分析变更请求的影响。分析预期的更改对系统的整体影响。
控制 - 如果预期的更改会影响系统中的许多实体，或者它是不可避免的，则必须在将更改纳入系统之前获得高级管理人员的批准。确定更改是否值得纳入。如果不是，则正式拒绝变更请求。
执行 - 如果上一阶段决定执行变更请求，则此阶段将采取适当的措施来执行更改，如有必要，将进行彻底的修订。
关闭请求 - 验证更改是否已正确实施并与系统的其余部分合并。软件中新合并的更改将被妥善记录，并且请求将被正式关闭。