软件工程/项目管理导论
软件项目管理是计划和领导软件项目的艺术和科学[1]。它是项目管理的一个分支，其中软件项目被计划、监控和控制。
软件项目管理的历史与软件的历史密切相关。在面向对象编程的概念在 1960 年代开始流行之前，软件是为专用机器开发的，用于专门用途，从而为软件行业创造了可重复的解决方案。由于基于组件的软件工程，专用系统可以适应其他用途。公司很快就了解到软件编程相对于硬件电路的相对易用性，软件行业在 1970 年代和 1980 年代迅速发展。为了管理新的开发工作，公司应用了成熟的项目管理方法，但在测试运行期间项目进度却落后，尤其是在用户规格说明和交付的软件之间存在灰色区域时，会发生混淆。为了避免这些问题，软件项目管理方法侧重于将用户需求与交付的产品匹配起来，这种方法现在被称为瀑布模型。从那时起，对软件项目管理失败的分析表明，以下是最常见的原因：[2]
- 不切实际或未明确表达的项目目标
- 对所需资源的估计不准确
- 系统需求定义不明确
- 项目状态报告不完善
- 风险管理不善
- 客户、开发人员和用户之间沟通不良
- 使用不成熟的技术
- 无法处理项目的复杂性
- 粗心大意的开发实践
- 项目管理不善
- 利益相关者政治
- 商业压力
上述列表中的前三项表明了以一种可以使适当的资源交付适当的项目目标的方式来表达客户需求的难度。特定的软件项目管理工具是有用的，通常是必要的，但软件项目管理的真正艺术在于应用正确的方法，然后使用工具来支持该方法。没有方法，工具就毫无价值。自 1960 年代以来，软件制造商为自身使用开发了几种专有的软件项目管理方法，同时计算机咨询公司也为其客户开发了类似的方法。如今，软件项目管理方法仍在不断发展，但当前趋势是远离瀑布模型，转向更循环的项目交付模型，该模型模仿软件发布生命周期。
软件开发流程主要关注软件开发的生产方面，而不是技术方面，例如软件工具。这些流程主要用于支持软件开发的管理，通常偏向于解决业务问题。许多软件开发流程可以以与一般项目管理流程类似的方式运行。例如
- 风险管理是衡量或评估风险，然后制定策略来管理风险的过程。一般来说，采用的策略包括将风险转移给另一方、避免风险、减少风险的负面影响，以及接受某个或所有特定风险的后果。软件项目管理中的风险管理始于项目的商业案例，其中包括成本效益分析以及项目失败的备用方案列表，称为应急计划。
- 风险管理的一个子集，即“机会管理”，正越来越受到关注。机会管理与风险管理含义相同，只是潜在的风险结果将产生积极影响，而不是负面影响。尽管在理论上以相同的方式处理，但使用“机会”而不是“风险”这个略带负面意义的词语，有助于让团队专注于项目中任何给定风险登记簿中可能产生的积极结果，例如衍生项目、意外之财和免费的额外资源。
- 需求管理是识别、征求、记录、分析、追踪、优先排序和达成一致需求，然后控制变更并与相关利益相关者进行沟通的过程。新或更改的计算机系统[1]需求管理，包括需求分析，是软件工程过程的重要组成部分；业务分析师或软件开发人员通过此过程来识别客户的需求或要求；在识别这些要求后，他们就可以设计解决方案。
- 变更管理是识别、记录、分析、优先排序和达成一致变更范围（项目管理），然后控制变更并与相关利益相关者进行沟通的过程。新或更改范围的变更影响分析，包括变更级别的需求分析，是软件工程过程的重要组成部分；业务分析师或软件开发人员通过此过程来识别客户的更改的需求或要求；在识别这些要求后，他们就可以重新设计或修改解决方案。从理论上讲，每次变更都会影响软件项目的进度和预算，因此根据定义，在批准之前必须包括风险效益分析。
- 软件配置管理是识别和记录范围本身的过程，即正在进行的软件产品，包括所有子产品和变更，并能够与相关利益相关者进行沟通。一般来说，采用的流程包括版本控制、命名约定（编程）和软件存档协议。
- 发布管理是识别、记录、优先排序和达成一致软件发布，然后控制发布时间表并与相关利益相关者进行沟通的过程。大多数软件项目都可以访问三个可以发布软件的软件环境：开发、测试和生产。在非常大的项目中，如果分布式团队需要在向用户发布之前整合他们的工作，那么在发布到用户验收测试 (UAT) 之前，通常会有更多用于测试的环境，称为单元测试、系统测试或集成测试。
- 发布管理的一个子集，即数据管理，正越来越受到关注，因为很明显，用户只能根据他们知道的数据进行测试，而“真实”数据只存在于名为“生产”的软件环境中。因此，为了测试他们的工作，程序员也必须经常创建“虚拟数据”或“数据存根”。传统上，以前曾使用生产系统的旧版本来实现此目的，但随着公司越来越依赖外部贡献者来进行软件开发，公司数据可能不会发布给开发团队。在复杂的环境中，可能会创建数据集，然后根据测试发布时间表将这些数据集迁移到测试环境中，这与整体软件发布时间表非常类似。
项目规划的目的是识别项目的范围，估计所涉及的工作，并创建一个项目时间表。项目规划从定义要开发的软件的需求开始。然后，制定项目计划来描述将导致完成的任务。
项目监控和控制的目的是让团队和管理层了解项目的进度。如果项目偏离计划，则项目经理可以采取措施纠正问题。项目监控和控制包括状态会议，以收集来自团队的状态。当需要进行更改时，可以使用变更控制来使产品保持最新。
在计算中，术语问题是指为了在系统中实现改进而要完成的工作单元。问题可以是错误、请求的功能、任务、缺少的文档等等。单词“问题”通常被误用，代替了“问题”。这种用法可能与之相关。 [需要引用]
例如，OpenOffice.org 曾经将其修改后的 BugZilla 版本称为 IssueZilla。截至 2010 年 9 月，他们将其系统称为问题跟踪器。
问题会不时出现，及时解决这些问题对于实现系统的正确性并避免产品交付延迟至关重要。
问题通常按严重程度分类。不同的公司对严重程度的定义不同，但一些最常见的严重程度是
- 严重
- 高 - 错误或问题影响了系统的关键部分，必须修复才能恢复正常运行。
- 中等 - 错误或问题影响系统的一小部分，但对系统运行有一些影响。当系统的一个非核心需求受到影响时，会分配此严重性级别。
- 低 - 错误或问题影响系统的一小部分，并且对系统运行几乎没有影响。当系统的一个非核心需求（且重要性较低）受到影响时，会分配此严重性级别。
- 外观 - 系统正常工作，但外观与预期不符。例如：颜色错误、内容之间间距过多或过少、字体大小不正确、错字等。这是最低优先级的問題。
在许多软件公司中，问题通常由质量保证分析师在验证系统正确性时进行调查，然后分配给负责解决问题的开发人员。它们也可以在用户验收测试 (UAT) 阶段由系统用户分配。
问题通常使用问题或缺陷跟踪系统进行沟通。在其他情况下，可以使用电子邮件或即时通讯工具。
作为项目管理的一个分支学科，有些人认为软件开发管理类似于制造管理，可以由具有管理技能但没有编程技能的人员执行。约翰·C·雷诺兹反驳了这种观点，并认为软件开发完全是设计工作，并将不会编程的经理比作不会写作的报纸主编。[3]
- 来自 Steve McConnell 的软件项目管理资源：http://www.construx.com/Page.aspx?nid=22
- 来自 Dan Galorath 的软件项目管理资源：http://www.galorath.com/wp/category/project-management
- ↑ a b Stellman, Andrew; Greene, Jennifer (2005). 应用软件项目管理. O'Reilly Media. ISBN 978-0-596-00948-9.
- ↑ IEEE 杂志文章“为什么软件会失败”
- ↑ John C. Reynolds，关于教授编程和编程语言的一些想法，SIGPLAN 通知，第 43 卷，第 11 期，2008 年 11 月，第 108 页：“有些人认为，在没有编程能力的情况下，可以管理软件生产。这种信念似乎源于对软件生产是一种制造形式的错误看法。但制造是重复构建相同的物体，而软件生产是构建独特的物体，即整个过程都是一种设计形式。因此，它更接近于报纸的制作——因此，不会编程的软件经理就如同不会写作的主编。”
- Jalote, Pankaj (2002). 软件项目管理实践. Addison-Wesley. ISBN 0201737213.