软件工程-实践者的研究方法讲义第十八章 项目管理概念.ppt

产品 从软件工程项目一开始，软件项目经理就面临着进退两难的局面。需要定量地估算成本和有组织地计划项目的进展，但却没有可靠的信息可以使用。虽然对软件需求的详细分析可以提供必要的估算信息，但需求分析常常需要数周甚至数月的时间才能完成。更糟糕的是，需求可能是不固定的，随着项目的进展经常发生变化。不过，无论如何计划总是“眼前”就需要的！ 因此，从软件工程项目一开始，就要研究应该开发哪些产品以及要解决哪些问题。至少，要建立和界定项目的范围。 软件范围 软件项目管理的第一项活动是确定软件范围。软件范围是通过回答下列问题来定义的： 项目环境。要开发的软件如何适应于大型的系统、产品或业务环境，该环境要施加什么约束？ 信息目标。软件要产生哪些客户可见的数据对象来作为输出？需要什么数据对象作为输入？ 功能和性能。软件要执行什么功能才能将输入数据变换成输出数据？软件需要满足什么特殊的性能要求吗？ 软件范围 软件项目范围在管理层和技术层都必须是无歧义的和可理解的。对软件范围的描述必须是界定的。即，要明确给出定量的数据；说明约束和限制，并且描述其他的缓解因素。 问题分解 问题分解，有时称为问题划分或问题细化，它是软件需求分析的核心活动。在确定软件范围的活动中，并不试图去完全分解问题，只是分解其中的两个主要方面：(1)必须交付的功能；(2)所使用的过程。 在面对复杂问题时，常常采用分而治之的策略。就是将一个复杂的问题划分成若干较易处理的小问题。这是项目计划开始时所采用的策略。在开始估算前，必须对软件范围中所描述的软件功能进行评估和精化，以提供更多的细节。因为成本和进度估算都是面向功能的，所以对功能进行某种程度的分解是很有益处的。 过程 刻画软件过程的框架活动适用于所有软件项目。问题是项目团队要选择一个适合于待开发软件的过程模型。 项目经理必须决定哪一个过程模型最适合于：(1)需要该产品的客户和从事开发工作的人员；(2)产品本身的特性；(3)软件项目团队工作的项目环境；当选择一个过程模型后，项目团队可以基于一系列过程框架活动来制定一个初步的项目计划。一旦确定了初步计划，过程分解就开始了。也就是说，必须制定一个完整的计划，来反映框架活动中所需要的工作任务。 合并产品和过程 项目计划开始于产品和过程的合并。软件项目团队要完成的每一项功能都必须通过针对软件组织而定义的一系列框架活动来完成。 完成任何一项功能的项目团队成员都要将各个框架活动应用于该功能的实现上。实质上，产生了一个类似于图18-1所示的矩阵。每个主要的产品功能显示在第一列，框架活动显示在第一行。软件工程工作任务列在紧接下来的行中。项目经理（和其他团队成员）的工作是估算每一个矩阵单元的资源需求，与每个单元相关的任务的开始和结束日期，以及每项任务所产生的工作产品。 合并产品和过程 图18-1 合并产品和过程 过程分解 软件团队在选择最适合项目的软件过程模型时，应该具有很大的灵活性。一旦选定了过程模型，项目团队可以根据需要灵活地确定过程模型中应包含的软件工程任务。较小的项目如果与以前已开发过的项目相似，可以采用线性顺序模型。如果时间要求很紧，而且问题能够被很好地划分，RAD模型可能是正确的选择。如果时间要求太紧，不可能完成所有功能时，增量模型可能是最合适的。同样，如果项目具有其他特性，可能会选择其他的过程模型。 过程分解 一旦选定了过程模型，就要根据所选的过程模型对过程框架做适应性修改，但在所有情况下前面讨论过的通用框架活动——沟通、策划、建模、构建和部署——都可以使用。过程框架既适用于线性模型，也适用于迭代和增量模型、演化模型、甚至是并发模型或构件组装模型。过程框架是不变的，是软件组织所进行的所有软件工作的基础。 过程分解 但实际的工作任务是不同的。例如，一个小型的比较简单的项目在沟通活动中可能需要完成下列工作任务： 1、列出需澄清的问题清单。 2、与客户见面说明需澄清的问题。 3、共同给出范围陈述。 4、和所有相关人员一起评审范围陈述。 5、根据需要修改范围陈述。 过程分解 考虑一个比较复杂的项目，它具有更广的范围和更重要的商业影响。这样一个项目在沟通活动中可能需要完成下列工作任务： 项目 为了成功地管理软件项目，必须了解可能会出现什么问题。在一篇关于软件项目的优秀论文中，[REE99]定义了10个表示信息系统项目正处于危险状态的信号： 软件人员不了解其客户的要求。 产品范围定义得很糟糕。 没有很好地管理变更。 选择的技术发生了变化。 业务需求发生变化。 最后期限是不切实际的。 客户抵制。 失去赞助。 项目团队缺乏具有合适技能的人员。 管理者没有很好地利用已学到的最佳实践和教训。 项目 1、在正确的基础上开始工作。通过以下两点来完成：首先努力地正确理解要解决的问题，然后为每个参与项目的人员设置现实的