软件项目管理

软件项目

一个软件项目是从需求收集到的测试和维护软件开发的整个过程。在特定的时间段把它执行根据执行的方法以达到预期的软件产品.

软件项目管理的必要性

软件被认为是一种无形的产品。软件开发是一种在世界上所有的商业新流，有一个在建的软件产品非常少的经验。大多数软件产品是量身定制的，以满足客户的需求。最重要的是，底层的技术改变和前进如此频繁和快速地一种产品的经验可能不被施加到另一个。所有这样的业务和环境的制约带来的风险中的软件开发，因此有必要有效地管理软件项目.

上图显示了软件项目的三重约束。它是软件组织的重要组成部分，以提供高品质的产品，保持内客户的预算约束的成本和按照预定的交付项目。有几个因素，包括内部和外部，这可能会影响到这三重约束三角形。所有三个因素会严重影响其他两个.

因此，软件项目管理是必不可少把用户的需求以及预算和时间的限制.

软件项目经理

软件项目经理是谁的人承担执行软件项目的责任。软件项目经理是彻悟SDLC的各个阶段，该软件会通过的。项目经理可能不会直接参与生产的最终产品，但他控制和管理参与生产活动。.

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

让我们来看看一些责任，一个项目经理做 -

管理人员

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

项目管理

定义和设置项目范围
管理项目管理活动
监控进度和性能
风险分析，在每一个阶段
采取必要的步骤，以避免或来的问题了
作为项目的代言人

软件管理活动

软件项目管理包括了一系列活动，其中包括项目的规划，确定软件产品，在各个方面的估计成本，任务和事件的调度和资源管理的范围。项目管理活动包括:

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

项目规划

软件项目计划的任务，这是生产软件的真正开始之前进行。这是那里的软件生产，但涉及与软件生产任何方向的连接没有具体的活动;相反，它是一组多个进程，这有利于软件的生产。项目规划可能包括以下内容:

范围管理

它定义项目的范围;这包括所有的活动过程中需要为了使可交付的软件产品实现。范围管理是必不可少的，因为它通过明确界定什么项目可以做，什么不可以做创建项目的界限。这使得项目以包含有限的，可量化的任务，它可以很容易地进行记录，进而避免了成本和时间溢出.

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

定义范围
确定其核查和控制
除以该项目转化为易于管理的各个小的部分
验证范围
通过将变更范围控制范围

项目估算

对于各项措施的有效管理准确的估计是必须的。有了正确的估计经理可以管理和更有效地控制项目。

项目估算可能涉及以下内容:

软件规模估算
软件大小可能无论是在KLOC（典千线）的条款或通过计算软件的功能点数量进行估算。代码行数取决于编码实践和功能点，根据用户或软件的要求而有所不同.
工作量估算
管理人员估计在人员的要求，须出示该软件工时方面的努力。对于工作量估算软件规模应该知道。这可以通过管理者的经验中得到，组织的历史数据或软件大小可以通过使用一些标准的公式转换成工作
估计时间
一旦尺寸和努力估计，需要对所生产的软件的时间可被估计。需要努力分隔成子类别按要求的规格和软件各组成部分的相互依存关系。软件任务被划分为更小的任务，活动或工作突破结构（WBS）的事件。在任务安排在一天到一天的基础上，或在日历月.

时间的总和，完成在几小时或几天内的所有任务所需的投资，以完成该项目的总时间.
成本估算
这是因为它依赖于比任何以往的多个元件可能被认为是最困难的。估算项目成本时，需要考虑 -
- 软件大小
- 软件质量
- 硬件
- 额外的软件或工具，许可证等
- 技术人员与特定任务的能力
- 旅游
- 通信
- 培训和支持

项目估算技术

我们讨论了涉及工程估算各种参数，例如大小，精力，时间和成本.

项目经理可以评估使用两种广泛认可的技术所列出的因素 –

分解技术

这种技术假设软件的各种组合物的产物.

主要有两种模式 -

代码估计行做代表 在软件产品的代码行数.
功能点 估计是做代表的软件产品功能点数量.

经验估计法

这种技术使用经验导出的公式来作出估计。这些公式是基于LOC或帧.

普特南模型
这种模式是由劳伦斯·普特南，它是基于诺顿的频率分布（瑞利曲线）进行。普特南模型映射的时间和规模的软件需要努力.
COCOMO
COCOMO代表建设性的成本模型，由巴里·W·贝姆发展。它把软件产品分为三类软件：有机，半独立式和嵌入式。.

项目调度

在项目工程调度指的是所有活动的路线图，将与指定的顺序，并在时隙分配给每项活动完成。项目经理往往倾向于定义各种任务和项目里程碑，并安排他们保持各方面的因素考虑。他们寻找的任务在于附表关键路径，这是和（因为任务相互依赖性）严格分配的时间内要完成的具体方式。任务安排，在于出关键路径都不太可能影响整个项目的所有计划.

调度项目，有必要 -

分解成更小的，易于管理的形式将项目任务
找出各种任务和它们相关联
需要为每个任务估计时间框架
除以时间投入到工作单位
分配的工作单位足够数量的每项任务
计算从开始项目所需的总时间来完成

资源管理

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

该资源在组织作为资产池数量有限，并住宿提供。资源短缺阻碍项目的发展，它可以滞后的调度之后。分配额外资源增加，最终开发成本。因此，有必要估算，分配足够的资源用于该项目.

资源管理包括 -

创建一个项目组，并分配责任落实到每一个团队成员定义适当的组织工程
确定在一个特定的阶段，其可用性所需要的资源
管理资源通过生成的时候都需要和去分配他们的资源请求时，他们没有更多的需要

项目风险管理

风险管理涉及的所有活动有关的识别，分析和决策提供项目中的可预见和不可预见的风险。风险可能包括以下内容:

经验丰富的工作人员离开该项目，并在新员工的到来.
改变组织管理.
要求改变或曲解的要求.
低估所需的时间和资源.
技术的变化，环境的变化，企业的竞争.

风险管理过程

有参与的风险管理流程如下活动:

识别 - 使所有可能的风险，这可能会发生在项目注释.
群归类 - 每对项目可能产生的影响进行分类的已知风险分为高，中，低风险的强度.
管理 - 在不同阶段分析发生风险的概率。令计划，以避免或面临风险。尽量减少其副作用。.
监测 - 密切监测潜在的风险和他们的早期症状。同时监测，以减轻或避免它们采取措施的效果。.

项目执行与监控

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

执行需要以监视检查按计划一切是否会。监测观察，检查风险的可能性和采取措施，以解决风险或报告的各项任务的状态.

这些措施包括 -

活动监控 - 定中的一些任务的所有活动，可以在一天到一天的基础上进行监控。当在一个任务中的所有活动完成后，它被认为是完整的.
状态报告- T该报告包含了一个星期给定的时间内完成，一般的活动和任务的状态。状态可以标记为已完成，或正在申请中的工作进展情况等.
里程碑清单 - 每个项目都被划分成主要任务是执行（里程碑）基于SDLC的阶段多个阶段。这一具有里程碑意义的清单准备每隔数周，并报告里程碑的地位.

项目沟通管理

有效的沟通起着一个项目的成功至关重要的作用。它填补了空白客户端和组织之间，团队成员以及其他利益相关者在项目中，如硬件供应商之一.

通信可以是口头或书面的。通信管理过程可具有以下步骤:

规划 - 这一步包括所有的利益相关者在项目的鉴定和它们之间的沟通模式。它还认为，如果任何额外的通讯设施是必需的 .
共享 - 在确定规划的各个方面，管理的重点是用正确的人在正确的时间分享的正确信息。这样可以使每一位参与该项目使用最新项目进展与现状.
反馈 - 项目经理使用各种措施和反馈机制，建立状态和性能报告。这种机制保证了各利益相关者的输入来的项目经理为他们的反馈.
关闭 - -在每一个重大活动结束，SDLC或项目本身的结束一个阶段的结束，封闭管理正式宣布，通过发送电子邮件，通过分发的文件或通过有效沟通等均值的硬拷贝来更新每个利益相关者 .

关闭后，球队移动到下一个阶段或项目.

配置管理

配置管理是跟踪和控制的要求，设计，功能和产品的开发方面的变化，软件的处理.

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

通常，一旦将SRS定稿有来自用户的变化的需求的机会较少。如果它们发生，变化只涉及较高的管理的事先批准，因为有成本和时间的可能性溢出.

基线

SDLC的阶段是在假设，如果它的基准，即基线测量，定义了一个阶段的完整性。相位为基准，当有关它的一切活动都是成品，有据可查。如果它不是最后阶段，它的输出将在下一阶段立即使用。配置管理是组织管理，其中一个相位基准后，负责发生任何变化（过程中，要求的技术，战略性等）的一门学科。 CM不断检查软件进行任何.

配置管理是组织管理，其中一个相位基准后，负责发生任何变化（过程中，要求的技术，战略性等）的一门学科。CM不断检查对软件做任何改变.

变更控制

变更控制的配置管理，从而确保软件系统进行的所有更改都一致并按照组织的规章制度的作用。.

在产品配置的变化经过以下步骤 -

识别 - 无论从内部或外部源的改变请求到达。当更改请求正式确定，这是适当的记录.
验证 - 有效的变更请求的检查及处理程序确认.
分析 - 变更请求的影响，进度，成本和所需的工作条件进行了分析。对系统的潜在变化的整体影响进行了分析.
控制 - 如果未来的变化既影响了太多的实体系统，或者是不可避免的，它是强制性的要高主管部门批准变更纳入系统之前。如果变化是值得纳入与否判定。如果不是的话，改变请求正式拒绝.
执行 - 如果前一阶段确定执行的变更请求，这个阶段采取适当的行动来执行的变化，做了彻底的修改，如果有必要的.
关闭要求 - 换作是正确实施验证，并与系统的其余部分合并。这在软件新成立的改变记录正常，请求正式关闭.