软件项目管理 - 软件工程教程

上一章软件工程教程请查看：软件开发生命周期

从事软件开发的IT公司的工作模式可分为两部分：

软件创建
软件项目管理

项目是定义良好的任务，它是为了实现一个目标(例如，软件开发和交付)而进行的若干操作的集合。一个项目可以被描述为：

每个项目都可能有一个独特的目标。
项目不是日常活动或日常操作。
项目有开始时间和结束时间。
项目在其目标实现时结束，因此它是组织生命周期中的一个临时阶段。
项目需要充足的时间、人力、财力、物力和知识库。

软件项目

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

软件项目管理需求

软件是一种无形的产品。软件开发是一种全新的业务流程，在软件产品的开发方面经验非常少，大多数软件产品都是为满足客户的需求而定制的。最重要的是，潜在的技术变化和进步如此频繁和迅速，一种产品的经验可能不适用于另一种产品。所有这些业务和环境约束都给软件开发带来了风险，因此有效地管理软件项目是至关重要的。

上图显示了软件项目的三重约束。交付高质量的产品，将成本控制在客户的预算范围内，并按计划交付项目，是软件组织的重要组成部分。有几个因素，内部和外部，可能会影响这个三重约束三角形。这三个因素中的任何一个都会严重影响另外两个。

因此，软件项目管理对于结合用户需求以及预算和时间约束是非常重要的。

软件项目经理

软件项目经理是负责执行软件项目的人。软件项目经理完全了解软件将经历的SDLC的所有阶段，项目经理可能永远不会直接参与生产最终产品，但他控制和管理生产活动。

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

让我们看看项目经理所承担的责任吧

管理人员

担任项目负责人
与利益相关者
管理人力资源
建立报告层次结构等。

管理项目

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

软件管理活动

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

项目计划
范围管理
项目评估

项目计划

软件项目计划是一项任务，它是在软件产品真正开始生产之前执行的。它的存在是为了软件生产，但不涉及与软件生产有任何方向联系的具体活动;相反，它是一组促进软件生产的多个过程。项目规划可包括以下内容：

范围管理

它定义了项目的范围;这包括所有的活动，过程需要做为了使一个可交付的软件产品。范围管理是必不可少的，因为它通过清楚地定义在项目中可以做什么和不可以做什么来创建项目的边界。这使得项目包含有限的和可量化的任务，这些任务很容易被记录下来，从而避免了成本和时间的超支。

在项目范围管理中，有必要进行以下工作

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

项目评估

为了有效的管理，准确的估计各种措施是必须的。有了正确的评估，管理者可以更有效地管理和控制项目。

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

软件规模估算

软件大小可以根据KLOC(千行代码)或通过计算软件中的功能点数量来估计。代码行取决于编码实践，功能点根据用户或软件需求而变化。

工作评估

管理人员根据人员需求和生产软件所需的工时来评估工作。对于工作量估计，软件大小应该是已知的。这可以由管理人员的经验、组织的历史数据或软件大小得出，也可以通过使用一些标准公式将其转换为工作。

时间估计

一旦估算出规模和工作量，就可以估算出制作软件所需的时间。根据需求规范和软件各个组件的相互依赖性，将所需的工作划分为子类别。软件任务按照工作突破结构(Work Breakthrough Structure, WBS)被划分为更小的任务、活动或事件。这些任务是按日或按日历月安排的。

以小时或天为单位完成所有任务所需的时间总和就是完成项目所投入的总时间。

成本估算

这可能被认为是最困难的，因为它比前面的任何一个都要依赖更多的元素。在估算项目成本时，需要考虑-

大小的软件
软件质量
硬件
附加软件或工具、许可证等。
具有特定任务技能的熟练人员
旅游涉及
沟通
培训和支持

项目评估技术

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

项目经理可以使用两种公认的技术来估计列出的因素

分解技术

这种技术假设软件是各种组合的产品。

主要有两种模式

代码行估计是代表软件产品中的代码行数进行的。
功能点估计是根据软件产品中功能点的数量来进行的。

实证估计技术

该方法利用经验公式进行估算。这些公式基于LOC或FPs。

Putnam模型

该模型由Lawrence
H. Putnam根据Norden的频率分布(Rayleigh曲线)建立。Putnam model映射了软件大小所需的时间和工作量。

COCOMO

COCOMO代表由Barry W. Boehm开发的建设性成本模型。将软件产品分为三类：有机软件、半分离软件和嵌入式软件。

项目调度

项目中的项目调度是指在分配给每个活动的时间段内，按照指定的顺序完成所有活动的路线图。项目经理倾向于定义各种任务和项目里程碑，并将它们安排在心中，以保持各种因素。他们寻找的任务位于计划中的关键路径，这些路径对于以特定的方式完成任务是必要的(因为任务相互依赖)，并且严格地在分配的时间内完成。位于关键路径之外的任务安排不太可能影响整个项目的进度。

为了安排一个项目，有必要-

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

资源管理

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

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

资源管理包括-

通过创建一个项目团队并为每个团队成员分配职责来定义适当的组织项目
确定特定阶段所需的资源及其可用性
通过在需要资源时生成资源请求并在不再需要时释放资源来管理资源。
项目风险管理
风险管理包括与项目中可预见和不可预见风险的识别、分析和准备相关的所有活动。风险可能包括以下方面：
有经验的员工离开项目，新的员工加入。
组织管理的变化。
需求变更或误解需求。
低估了所需的时间和资源。
技术变化，环境变化，商业竞争。

风险管理过程

风险管理过程包括以下活动：

识别-记录项目中可能出现的所有风险。
分类-根据已知风险对项目可能产生的影响，将其分为高、中、低风险强度。
管理-分析风险在各个阶段发生的概率。制定计划以避免或面对风险。尽量减少它们的副作用。
密切监测潜在风险及其早期症状。还应监测为减轻或避免它们而采取的步骤的影响。

项目执行与监控

在这个阶段，项目计划中描述的任务是根据它们的时间表执行的。

执行需要监视，以检查是否一切都按照计划进行。监控是观察风险发生的可能性，并采取措施应对风险或报告各项任务的状态。

这些措施包括：

活动监控——可以对某些任务中安排的所有活动进行日常监控。当一个任务中的所有活动都完成时，它就被认为是完成了。
状态报告——报告包含在给定时间范围内完成的活动和任务的状态，通常为一周。状态可以标记为已完成、未决或正在进行中等。
里程碑检查表——根据SDLC的阶段，每个项目被划分为多个阶段，其中主要任务被执行(里程碑)。里程碑检查表每隔几周编制一次，并报告里程碑的状态。

项目沟通管理

有效的沟通对项目的成功起着至关重要的作用。它在客户和组织之间、团队成员之间以及项目中的其他利益相关者(如硬件供应商)之间架起了桥梁。

沟通可以是口头的，也可以是书面的。沟通管理流程可分为以下几个步骤：

计划——这一步包括确定项目中所有的利益相关者以及他们之间的沟通方式。它还考虑是否需要任何额外的通信设施。
共享——在确定了计划的各个方面之后，经理关注于在正确的时间与正确的人共享正确的信息。这使每个参与项目的人都能及时了解项目进展及其状态。
反馈——项目经理使用各种措施和反馈机制，并创建状态和性能报告。这种机制确保来自各种涉众的输入作为他们的反馈反馈给项目经理。
收尾——在每一个重大活动结束时，SDLC的一个阶段或项目本身结束时，正式宣布行政收尾，通过发送电子邮件、分发纸质文件或其他有效沟通的方式更新每个利益相关者。

结束后，团队转移到下一个阶段或项目。

配置管理

配置管理是一个跟踪和控制软件在需求、设计、功能和产品开发方面的变化的过程。

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

一般来说，一旦SRS完成，用户要求更改的机会就会减少。如果发生了这些变化，只有在高层管理人员事先批准的情况下才能进行处理，因为可能会出现成本和时间超支的情况。

基线

SDLC的一个阶段如果是基线化的，则被认为是结束了，即基线是定义了一个阶段的完整性的度量。当与阶段相关的所有活动都完成并形成良好的文档时，该阶段就被基线化了。如果不是最后阶段，它的输出将在下一个直接阶段使用。

配置管理是组织管理的一门学科，它负责在一个阶段的基础上发生的任何变化(过程、需求、技术、战略等)。CM会检查软件中所做的任何更改。

变更控制

变更控制是配置管理的功能，它确保对软件系统所做的所有变更都是一致的，并按照组织的规章制度进行变更。

产品结构的改变要经过以下几个步骤

标识——变更请求来自内部或外部源。当更改请求被正式标识时，它被适当地记录下来。
验证——检查变更请求的有效性，确认其处理程序。
分析——根据计划、成本和所需的工作，分析变更请求的影响。分析了预期变化对系统的总体影响。
控制——如果预期的变更影响了系统中太多的实体，或者是不可避免的，那么在将变更纳入系统之前，必须获得高级主管部门的批准。它决定了变更是否值得合并。如果不是，则正式拒绝更改请求。
执行——如果前一个阶段决定执行变更请求，那么这个阶段将采取适当的行动来执行变更，如果需要，将进行彻底的修订。
关闭请求——验证更改是否正确实现并与系统的其余部分合并。软件中这个新合并的变更被适当地记录下来，请求正式关闭。