[微软] 项目团队解决方案的构思MSF

100 第3章 解决方案的构思 105 第3章 解决方案的构思 第3章 解决方案的构思 项目是否能够成功取决于项目团队成员和客户之间能否对项目的目的和目标有一个清楚一致的看法。团队在 Microsoft® 解决方案框架（MSF）过程模型的构思阶段定义项目的远景。在接下来的四课中，将会学习构思阶段以及在这个阶段中团队成员的角色和责任。此外还会学习如何定义项目的远景，以及如何分析项目相关的风险。 学习完本章后，将能够： · 描述 MSF 过程模型构思阶段的目的、活动和交付成果 · 确定远景/范围文档的组成部分 · 确定项目结构文档的组成部分 · 分析项目中的风险 3.1 构思阶段 所谓构思阶段是这样一个时期，在这个时期内团队、客户和发起人定义高层次业务需求和项目的总体目标。其主要目的是确保一个共同的远景，而在项目对组织是否有价值，以及项目是否能够取得成功等方面，团队成员也需要达成一致意见。构思阶段的工作重点是明确地定义问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 。构思阶段最后到达远景/范围认可里程碑。 学习完本课后，将能够： · 描述构思阶段的目的 · 描述在构思阶段团队成员的角色和责任 · 列举组建项目团队的指导方针 · 描述构思阶段的交付成果 3.1.1 构思的目的 图3-1 构思的目的 MSF 过程模型的第一个阶段是构思阶段。在这个阶段中，团队对要解决的业务问题，以及这些问题与公司、客户和环境的关系创建一个概括说明。这样就帮助团队清楚地认识到必须为它的客户实现什么。对于一个成功的项目，你需要知道客户想要通过解决方案实现什么。 图3-2说明了构思阶段在整个 MSF 过程模型中的位置。 图3-2 构思阶段在整个 MSF 过程模型中的位置 例如，假设一个组织想要你为它开发一个 Web 站点。“我们需要一个 Web 站点”是开发这个 Web 站点项目一个很好的原因，但是它不是一个好的远景。要创建最有效的解决方案，团队应该确定组织想通过构建和部署这个 Web 站点要达到什么样的目标。此外，团队还需要确定该 Web 站点是否具有能够让组织从中获取最大利益的惟一特点。组织是想要一个复杂的站点，还是想要一个支持用户数逐渐增多的站点？组织有可能既需要计划复杂性，又需要计划可扩展性吗？团队应该考虑潜在的市场和站点期望的访问量，另外还需要考虑组织的品牌和其在市场中的声誉。 （1） 构思阶段的目的 构思阶段有很多目的。团队使用构思阶段来： · 确定项目目标和项目约束 · 回答可行性问题，得到主要干系人的认同，从涉及到的每个人中获得一组共同的期望 · 奠定一个基础，然后项目中团队成员基于这个基础创建解决方案 · 定义项目的范围，这样有助于下一阶段详细的计划工作 · 估计开发解决方案所需的资源 · 确定项目的主里程碑并对其进行进度安排 3.1.2 团队成员的角色和责任 图3-3 团队成员的角色和责任 虽然项目团队作为一个整体到达构思阶段的远景/范围认可里程碑，但在项目生命周期的每一个阶段，每个角色都有一个特定的工作重点。 图3-3给出了在构思阶段项目团队的角色。 （1） 团队角色和责任 MSF 组队模型为一个项目在构思阶段指定了六个角色： · 产品管理角色。产品管理角色保证团队满足客户的需求。产品管理角色与程序管理角色合作，保证建立一个一致的项目远景。要达到这一目标，产品管理角色要研究和分析业务问题、业务需要、项目远景和用户档案 · 程序管理角色。程序管理角色建立项目设计目标，定义成功的因素和测量标准（metric），阐明解决方案的概念，建立项目基础结构 · 开发角色。开发团队为团队提供以下方面的反馈：开发产品中涉及到的技术，及解决方案概念的可行性 · 测试角色。测试团队为团队提供解决方案质量目标的反馈，并指出要达到质量等级要求所需的工作。测试团队然后将有关质量目标的决策应用到测试策略和接受标准上，接受标准将用于测量质量 · 发布管理角色。发布管理团队确定部署产品都需要哪些东西，产品如何部署、什么时候部署，以及部署是否还需要额外的基础结构等 · 用户体验角色。用户体验团队分析用户的性能需要和支持问题，考虑满足这些需要所要关联的产品 3.1.3 组建项目团队 在构思阶段要完成的任务之一是组建团队。项目团队成员必须胜任工作，并且能够完成创建解决方案所须的任务，这一点是非常重要的。组建团队的任务是集合成功完成项目所必须的技能。在为一个项目确定合适的团队成员时，需要考虑每个成员以下的方面： · 知识。表示每个人要能胜任地完成工作，必须掌握的知识，比如说计算机科学基础知识等 · 技能。表示形成才能（competency）的行为和能力，比如说数学逻辑或艺术能力 · 绩效等级。表示表示可行的执行过程达到目的的能力及所期望的结果,例如，在选人的时候，你可以选择一个能够按时按质完成任务的人 （1） 选择团队的考虑 除了考虑每个人的能力之外，在选择团队成员时还有一些实际的东西需要考虑，包括： · 团队成员的可用性 · 成本预算或项目预算 · 团队成员的背景调查 3.1.4 准备构思阶段的交付成果 虽然在构思阶段有中间里程碑，比如说核心团队的组建，远景/范围草案文档版本的创建、风险评估草案文档版本的创建等等，但是构思阶段有三个主要交付成果。这三个交付成果分别为： · 远景/范围文档。远景/范围文档描述项目目标和项目约束。它概括了要开发的产品，以及它要满足的需要、它的特性和一个初步的进度表 · 项目结构文档。项目结构文档概括项目组织结构，描述项目管理过程。它概括谁应该负责 MSF 组队模型的哪一个角色，并确定每个角色的团队领导 · 风险评估文档。这个评估文档初步地确定和分析与项目有关的风险，以及风险管理中的减轻计划和应急计划 （1） 构思阶段的其他交付成果 依据项目的范围，构思阶段的交付成果可能包括： · 可测试功能的一个初始列表 · 初步需求和用例 · 初步体系结构 · 一个用户图形界面（GUI）记事板 （2） 团队内部文档 除了与客户共享的文档之外，项目团队还要开发以下文档供内部使用： · 用户目录 · 业务规则目录 · 术语表 注意：我们已经在本书的第2章“收集和分析信息”中学习过这些文档。 3.2 创建远景/范围文档 构思阶段最后的里程碑是经过认可的远景/范围文档。将在本课学习如何创建项目的远景/范围文档。 学习完本课后，将能够： · 描述远景/范围文档的内容 · 创建问题说明 · 创建远景说明 · 创建用户档案 · 定义项目范围 · 创建解决方案概念 · 确定项目目标 · 验证远景/范围文档 3.2.1 远景/范围文档 远景/范围文档是构思阶段最后的交付成果之一。该文档包含业务解决方案的目标和约束。远景/范围文档代表项目涉及的所有人之间达成的第一个共识。它指导团队实现具体的业务目标。最初，项目非常依靠远景/范围文档来决定项目是否继续。在项目得到批准以后，团队使用远景/范围文档来组织项目剩余部分的计划工作。 要创建远景/范围文档，团队与客户及干系人进行更多访谈，将业务的高层次用例，分析为更加详细的用例，确定业务的假定和约束。记住在 MSF 过程的所有阶段都要继续收集信息和分析信息。 （1） 远景/范围文档的内容 远景/范围文档的焦点必须是理解和定义问题。远景/范围文档的内容包括： · 问题说明 · 远景说明 · 用户档案 · 项目范围 · 解决方案概念 · 项目目标 · 业务目标 · 设计目标 · 关键的成功因素 · 初始的进度表 3.2.2 创建问题说明 问题说明 通常是一小段叙述性文字，用来说明公司希望项目解决的问题。它本质上与业务活动的当前状态相关。问题说明定义地越准确，就越能够测量它对组织业务需要的影响。 因为任何项目的目标是解决一个问题，所以对问题的理解决定了解决方案的设计。问题说明概括团队试图解决的业务问题。问题说明必须提供业务问题的充分信息。新的团队成员使用问题说明和文档的其余部分就可以融入到项目中。 （1） 问题说明的例子 下面是一些问题说明的例子： · 电话操作员不能处理大量的呼叫，因为运行当前的应用程序以及与这些应用程序交互需要花费时间 · 组织需要消除与老版本软硬件有关的日常成本 · 在出现错误时，用户需要使用系统弄清问题来源，并解决错误 · 我们需要 Web 站点更加易于浏览，从而增加在线注册的数量 3.2.3 创建远景说明 远景说明的目的是建立一个共同的远景，并在团队成员之间就项目对组织有价值以及项目可能成功达成一致意见。远景文档还保证整个团队对项目的未来有一致意见。 （1） 远景说明的特点 远景说明必须足够短，以便记忆；足够清楚，以便理解；足够强，以使其自身具有动机性。一个好的远景说明有以下五个特点： · 具体。远景说明应该具体，并包括业务问题的理想状态，以使得最后的结果有意义 · 可测量。通过创建可测量的远景说明，项目团队可以确定项目的成功以及项目是否满足业务目标 · 可实现。如果给定资源、时间期限和团队成员的技能，那么远景说明应该是可以实现的。一个可实现的远景说明能够激励团队完成项目 · 有意义。远景说明应该与待解决的问题相关。如果远景说明不相关，项目团队可能发现他们正在试图解决不存在的业务问题，而且项目可能会失去资助 · 基于时间。远景说明应该清楚地指出交付解决方案的估计时间期限 注意：上面的远景说明的质量也叫做 SMART 特点，所谓 SMART 是五个特点的首字母缩写。 （2） 远景说明的例子 假设有一个组织的电子商务 Web 站点的在线销售量远低于其竞争对手。在解决这个业务问题的构思阶段，我们可以使用以下远景说明： 在今年年底前，我们将通过增加在线销售使自己成为业界收入最高的公司。 再看另外一个例子。比如说某在线图书馆有一个图书、杂志、论文、白皮书和期刊的大型目录。组织希望这个图书馆的订阅者不管使用哪一台计算机访问这个 Web 站点，他们都能跟踪自己想要再次搜索的目录中的所有项。这样一个项目的远景说明可能如下： 在目前这个财政年度，我们将要让所有订阅者能够从我们的 Web 站点所选择的页面上创建书签，从而使他们能够从任何最终用户都可以使用的计算机或设备上访问加了书签的页面。 注意前面这两个远景说明都有五个 SMART 特点。两个远景说明都是具体的、可测量的、可实现的、与业务问题相关的并且有一个估计的可用时间。 3.2.4 创建用户档案 一个业务解决方案由一组客户使用。在进一步深入设计解决方案之前，理解正在开发的解决方案都有哪些用户是非常重要的。为了清楚地描述每个用户，团队需要创建用户档案。用户档案确定用户，从而使团队能够评估项目的期望、风险、目标和约束。 （1） 创建用户档案所需的信息 在创建用户档案时，需要考虑以下方面： · 目标。最终用户的目标将会包括客户希望通过与产品交互来完成的一系列事情 · 约束。理解有哪些因素可能影响用户使用解决方案的能力是非常重要的，比如硬件因素和软件因素等等。例如，对于某个解决方案，你可能需要考虑目前所有用户正在使用的操作系统。如果组织内的用户正在使用几种不同的操作系统，那么就没有理由设计一个只能用于某个特定操作系统的解决方案 · 支持问题。用户档案中还包含用户在使用相似产品时所遇到的问题。这些信息将有助于对用户在使用新产品可能需要的支持特性做出计划 · 全球用户。决定解决方案是否要支持不同的文化和本地化需要 · 地理边界。描述用户的位置，包括地理位置和物理位置，每个站点的用户数以及连接不同站点的网络的带宽和使用情况 · 用户之间的信息流。描述发生在用户之间的通信，包括通信的类型、重要性，以及不同用户群体之间的数据流量 · 用户功能。描述用户完成的任务，比如“完成客户档案”和“编辑客户订单及详细信息”。这些信息将要开发到用例中 · 组织通信。一些组织有严格的级别划分，限制某人如何、为什么以及什么时候可以跨级别线进行通信。在这样一个解决方案中，我们需要满足这些限制。将组织级别的组成和边界编制成文档 · 决策策略。描述直接影响提议的解决方案有效实现的决策策略 · 其他因素。我们还应该把每个用户所在位置的资源可用性和资源使用情况编制成文档，确定任何额外的因素，比如可能影响一个基于地理的解决方案成败的不兼容 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 、网络操作系统和应用程序等 3.2.5 定义范围 项目成功的关键因素之一是明确地定义项目的范围。范围定义了项目中应该包括什么，不应该包括什么。范围使用远景说明中定义的项目远景，还包括了资源、时间和其他限制因素对项目的约束。范围由用户认为解决方案必须提供的功能来定义。团队必须在解决方案的第一个发行版本中提供这些功能。在定义范围时，团队可以决定在项目以后的发行版本中再加入那些与解决方案的核心功能不直接相关的功能。未被考虑到范围内的功能应该记录在一个next-version或future-project文档中。 在开始定义项目范围时，要继续开发为分析业务和记录初始业务需求而创建的初步用例。为了定义范围，在用例中要确定直接影响业务挑战和解决业务的地方。你可能需要区分业务挑战的优先级，确定那些可以在解决方案的后续版本中处理的业务挑战。一般可以在初步用例的相关部分画一个方框，并得出在项目中接下来要使用的新的用例图。 图3-4给出了表示一部分业务的用例图。项目范围包在一个方框中。 图3-4 表示一部分业务的用例图 图3-4给出了表示这个项目范围的用例图。在与客户讨论有关范围的问题时，客户和团队一致认为与销售及 Web 站点相关的功能对于增加收入的影响最大，所以其他所有用例都推迟到将来的版本。这个范围将会包括所有的附属用例，这些附属用例是在构思阶段中提出的。 注意：图3-4只给出了目前在项目范围之内的用例。本书第5章“逻辑设计的创建”中将给出整组用例和使用场景。 （1） 完善需求 定义项目范围的一项重要活动是完善需求。记住在构思和计划阶段都要继续分析和完善需求。在构思阶段中，分析所收集到的信息，并确定能产生需求陈述的具体短语。然后查看这些短语，用表达业务需要和希望的语言来表达需求。还可以通过直接从访谈和其他来源收集客户语言。考虑以下初步需求： 系统必须支持本地化以迎合最终用户的文化。 在构思阶段对其进行完善，得到如下需求： 系统必须具有用于全球化、本地化和可访问性的程序。 （2） 平衡三要素和优先级别 定义范围意味着平衡各类最终用户的需要，考虑客户规定的其他优先级。几个变量可能会影响项目成败，这几个变量包括成本、资源、进度表、功能和可靠性。定义范围的关键是找出这些变量之间适当的平衡。 图3-5中的平衡三要素给出了在调整项目范围时三个最关键的元素。平衡三要素指出，资源、进度表和功能是任何项目的三个互相关联的元素；平衡三要素还指出，限制或增强其中的一个或多个元素需要对三者进行权衡。 图3-5 平衡三要素 （3） 版本化的角色 在定义项目范围时，确定将放在解决方案的不同版本来解决的问题。在构思阶段，定义解决方案需要处理哪些用例以及哪些相关的候选需求。 解决方案的功能对应于需求。解决方案是否应该提供某个功能，取决于该功能与用例的第一个版本中选定业务问题的相关程度，以及该功能会影响多少用户。对于那些影响用户最多的功能，我们应该给予最高的优先级。 在确定了业务问题并区分了其优先级别之后，我们就可以着重于那些与优先级最高的问题相关的用例。在每一个版本中，着重解决最紧要问题的功能以及影响用户数最多的功能，去除少数用户要求以及解决其他问题的功能。这样我们就能够为每个版本以及整个项目定义解决方案的范围。 更多信息：记住，在计划阶段，逻辑设计接近尾声时，需求陈述将开发成为功能列表。在本书第5章“逻辑设计的创建”中，我们将会学习逻辑设计。 （4） 假定和约束的角色 项目范围还受公司和客户所做的假定和约束的影响。一般情况下，假定会增加项目的约束。下面是一些假定的例子： · 我们将使用 Microsoft .NET Framework 来开发 · 我们将使用两个开发团队 · 我们有 OLAP系统和 OLTP 系统 约束指出最后的业务解决方案必须符合的参数。它们是业务环境不能或者不会改变的方面。这些约束通常会变成应用程序的设计目标。如果没有正确地确定约束，那么项目团队设计的产品可能就不能部署到公司中。 以下是应该编制成文档的一些可能的约束： · 预算限制 · 早期支持系统的特点 · 网络系统体系结构 · 安全需求 · 操作系统 · 计划的技术升级 · 网络带宽限制 · 维护和支持协议及结构 · 开发人员或支持人员的知识水平 · 用户的知识限制 列出会影响业务挑战和潜在解决方案的约束。项目团队使用这些约束设计一个优化需求的、符合约束所建立参数的解决方案。 （5） 估计的作用 根据项目的假定和约束，可以对开发解决方案进行一个估计。估计对象包括时间、努力和成本。估计构建解决方案所需的时间、资源，以及资源的成本和所需的工作。 而且，还需要在估计部分添加免责声明和 合同 劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载 细节。这样有助于阐明你在项目中所负责任的范围。 （6） 定义范围的优点 定义项目范围的一些优点如下： · 范围能够让团队将着重于确定必须要做的工作 · 范围能够让团队把大的任务和含糊的任务划分成小的更具体的任务 · 范围能够帮助指定解决方案的每个版本应该包含的功能 · 范围包含功能集和功能，这样有助于在子承包商或合作伙伴之间分配工作 · 范围阐明在当前的交付成果中团队要对什么负责，不对什么负责 （7） 修订范围 在构思阶段，项目变量开始变得明显。但是如果有一个更详细的计划过程的帮助，那么团队就可以更加彻底地理解项目变量。在构思阶段的这一时期，团队可能只在一个基础层面上认识项目变量。定义和平衡项目变量是一个反复的过程。随着分析、原型化和计划活动向前推进，团队可能需要修订范围，以实现以下目的： · 加入对用户需求的更好的理解 · 加入业务需求的变更 · 根据技术问题或风险调整解决方案 · 对资源、进度表和功能等项目变量做出权衡，因为项目变量已经发生了变化 （8） 找出遗漏的需求 遗漏需求是最常见的需求过失，因为它们是不可见的。下面的方法能够帮助 检测 工程第三方检测合同工程防雷检测合同植筋拉拔检测方案传感器技术课后答案检测机构通用要求培训 未发现的需求： · 将高层次需求分解为足够详细的需求，以展现客户的要求 · 确保已经提供了所有的用户种类，而且每个用例必须至少有一个确定的操作者 · 跟踪系统需求、用例、事件响应列表和业务规则，以确保分析人员得出了所有必要的功能 · 检查遗漏需求的边界值 · 以多种方式表示需求 · 使用复杂的布尔逻辑检查不完整的需求集 3.2.6 创建解决方案概念 解决方案概念概括了团队为达到项目目标而采用的方法，同时为进入计划阶段提供了基础。在确定业务问题和定义远景及范围之后，团队创建解决方案框架，这个框架使用通用术语解释团队打算如何实现项目需求。 图3-6展示了针对于Adventure Works Cycles所确定范围的一个示例解决方案概念。 图3-6 示例解决方案概念 （1） 创建一个面向业务的草案 解决方案概念可以充当一个业务基础。因为它只注重概念，而不注重解决方案的细节，所以它的技术性不强。对于请求批准和资金的团队，团队应该建立一个决策发起人，该人将使用远景/范围文档建立资金。 解决方案概念包括系统的软件体系结构和硬件体系结构的一个概念模型。解决方案概念是解决范围中所确定问题的建议方法。团队必须评估不同的选项，然后选择最适合具体情况的一个。团队然后可以将解决方案概念选项缩小到几个可选方法的范围。 例如，在一个电子商务 Web 站点的情况中，可选方案有以下几个：（1）完全由公司内部构建一个电子商务站点，（2）雇请外部公司构建一个电子商务站点，（3）购买一个商用解决方案。相似的问题存在于电子商务站点所处的位置：站点应该放在本地服务器上还是使用一个服务提供商的服务器？ （2） 解决方案概念的要素 在评估了它的选项之后，团队选择一个实现起来最能满足其需要、资源和时间期限的一个解决方案概念。解决方案概念包括以下要素： · 项目成功因素和接受标准。这些标准包括一个需求清单，指出在解决方案成为产品之前必须实现的需求 · 开发和交付解决方案的初始方法。这些方法包括站点的示例场景和实现解决方案的方法，使用新解决方案的用户数，为使新解决方案运营所必须交付产品的一个完整列表 · 将解决业务问题的解决方案的初始功能描述 注意：在解决方案设计中，创建用户档案和解决方案概念不需要是一个线性过程，这些步骤可以同时完成。 3.2.7 确定项目目标 为了使项目成功，正确地确定项目目标是非常重要的。项目目标可以分为以下两类： · 业务目标 · 设计目标 （1） 业务目标 业务目标代表客户想从解决方案中得到什么。业务目标构成了判断解决方案是否成功的标准基础。定义业务目标的目的是清楚地阐明项目目标，保证解决方案支持那些业务需求。团队需要找出最好的方法来确定目标并使大家认同这个目标。 在整个项目生命周期中团队对资源、进度表和功能做出权衡。区分业务目标的优先级可以让团队清楚地理解客户认为哪些目标最重要，以防有些目标不能实现，这一点非常重要。 （2） 业务目标的例子 对于一个电子商务项目，业务目标可能包括以下这些： · 拓展公司的地理市场，使其不受物理店铺当前的范围所限制 · 拓展公司的国内市场，使客户群包括具有较多可任意支配收入的年轻消费者，以及在线购物比当前的客户要频繁的年轻消费者 · 通过使用更有效的在线站点来缩短产品销售时间 · 通过使用工作流过程整合全球的供应商，缩短定购和交付周期时间 （3） 设计目标 设计目标在很多方面与业务目标类似。两者的区别在于设计目标更多强调解决方案的属性，而更少关心解决方案为公司实现什么。设计目标不仅解决团队需要使用解决方案完成的事情，还解决团队不打算使用解决方案完成的事情。需要根据业务目标区分设计目标的优先级，以使团队知道在万一不能实现所有目标的情况下必须实现哪些目标。 （4） 设计目标的例子 对于一个电子商务 Web 站点，在线购物车的设计目标可能包括： · 通过将页面下载等待时间减少到5秒钟或更短，改进用户体验 · 限制对服务器连通性的依赖 · 减少用户完成在线注册的时间和步骤 对于移动应用程序的界面的设计，设计目标可能包括： · 用户必须能够很容易输入和检索信息 · 必须可以根据预期的移动设备定制应用程序 （5） 业务需求的冲突 来自于多处的业务需求可能相互冲突。假设有一个包含内嵌软件的展台，该展台由一个零售商店的客户使用。展台开发人员的业务目标包括： · 通过把展台租赁或销售给零售商获得收入 · 使用展台卖消费品给客户 · 吸引客户了解品牌 · 使产品的可用性很广 零售商的业务兴趣可能包括： · 从可用的地板空间获得最大的收入 · 吸引更多客户来到商店 · 展台替代手工操作，会带来销售量和利润率的增长 开发人员、零售商和客户通常有不同的目标、约束和成本因素。项目发起人必须解决这些冲突，分析人员才能够完善展台的系统和软件需求。 3.2.8 验证远景/范围文档 在创建了远景/范围文档的早期版本之后，团队复查和修改文档。构思阶段最后达到远景/范围认可里程碑。这个里程碑代表项目团队和客户已经就项目的总体方向达成共识，其中包括解决方案的范围。文档的基线版本是项目后续阶段将要用到的一个项目交付成果。 远景/范围文档在远景/范围会议上得到正式认可。团队与干系人验证在用例、使用场景和使用档案中所完成的工作。（这个验证是在整个项目中都会发生的过程。）通过让客户验证已完成的工作，团队准备让客户理解在定义范围时所做的权衡。团队还对客户培训项目的概念和团队的工作方式，使他们认识到参与到项目中可以大大减少达成共识的困难，以及在对将来的功能进行讨论过程中遇到的困难。 （1） 远景/范围会议 远景/范围会议保证团队和客户对以下事情有共同的理解，即对于已经定义的范围来说，提议的解决方案将如何解决业务问题，如何应用到当前的业务场景中。 这个会议是团队与客户分享观点并达成共识的一个机制。这个会议还能够让客户知道团队正在听取他们的意见，并且使客户主动地参与到项目中。团队根据这个会议决定项目是否要继续下去。可用的资源和潜在的收益可能抵不上项目的总成本。这个验证步骤允许团队要么重新定义解决方案，要么重新定义资源和约束。 通过认可远景/范围文档，项目团队的成员、客户和干系人对以下事情达成共识： · 对解决方案要满足的业务需要的一个大体理解 · 项目的远景 · 解决方案的设计目标 · 承担项目可能遇到的风险 · 项目管理层对业务解决方案的初始概念 · 项目团队的成员 · 管理项目的机制 在光盘上：Adventure Works Cycles 案例研究的完整的远景/范围文档叫做 AWC – Vision Scope.doc，该文档可以在培训材料光盘根目录下的Appendices\Mod03文件夹中找到。Adventure Works Cycles 团队已经定义了该项目第一版的范围，该范围包括销售订单和销售分析、联系人管理、以及 Web 定货过程。至于产品跟踪、人事关系文档编制和供应商数据则放到将来的版本或项目中。 如果团队发现了任何会对项目范围或交付成果有显著影响的问题，那么团队可能需要再进行更多的讨论或者再举行一次远景/范围会议。 3.3 创建项目结构文档 项目结构文档是构思阶段一个主要的交付成果。本课描述创建项目结构文档的目的，并详细说明该文档的主要部分。 学习完本课后，将能够： · 描述项目结构文档的用途 · 描述项目结构文档的组成部分 3.3.1 项目结构文档 项目结构文档定义组织项目和管理项目的方法。该文档说明团队的管理结构、管理标准和管理过程，以及项目资源和项目约束。它是项目团队成员成功合作的一个主要参考。 项目结构文档可以作为项目中每个 MSF 团队角色需要遵从的方法的正式文档。而且，它记录将要为项目实现的变更管理和配置管理方法。项目结构文档的详细程度取决于项目。如果你认为在项目的后期阶段将会有很多的变更，那么项目结构文档就应该详细说明团队将如何处理这些变更。 （1） 项目结构文档的示例部分 下面给出了 Adventure Works Cycles 应用程序项目结构文档的变更管理部分。在这个例子中，项目涉及到的两家公司分别是 Adventure Works Cycles 和Contoso, Ltd。 变更管理 在 Adventure Works Cycles 应用程序中最重要的是到项目结束日期交付第一个功能集。（由项目主要计划的完成所决定。估计 Web 站点的完成日期是2003年9月1日，销售自动化项目的完成日期是2003年9月15日。）因此，变更控制程序将实现为以下内容 变更控制过程和文档所有者 程序经理将负责变更控制过程和文档。变更控制过程管理由客户提出的变更，Adventure Works Cycles 的应用程序项目经理将是变更控制过程的主要决策者 分版本标识功能 在计划、需求收集、和功能 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 开发过程中，每个功能都被标识为关键 V1.0、希望 V1.0，关键 V2.0、希望 V2.0，关键 V3.0 或 希望 V3.0 变更咨询委员会 变更咨询委员会由 Contoso, Ltd （开发团队和程序经理）、Adventure Works Cycles 团队（项目经理和开发人员）的成员组成，他们之中所有人都可以要求改变功能集。其他的团队成员可以把自己的功能集建议提给变更咨询委员会的任何成员，然后变更咨询委员会成员就可以将建议添加到建议列表中， 以在下一次状态会议中进行讨论。如果这个成员认为他接收的建议非常关键，那么就可以将这些建议列为关键问题，直接在下一次状态会议之前开始评估 功能评估 团队评估功能定义及其对设计的影响，对解决方案的影响，对1.0版本（或者任何其他版本）的价值，以及它的风险 功能权衡 将功能与其他功能对比，确定任何可能的权衡 资源权衡 复查平衡三要素，添加或删除适当的元素（资源或功能）。（进度表是固定的。） 将功能分解到设计中 当一个功能被分解为关键 V1.0，V2.0，或 V3.0 或希望 V1.0，V2.0 或 V3.0 并添加了资源，或者其他功能被删除或缩减之后，功能就进入设计过程的适当点。预算和合同将要调整。（如果 Adventure Works Cycles 认为为了某个功能，值得调整进度表，那么他们可以要求改变进度表，并对合同、设计、预算和进度表做出适当的调整。） 变更截止期限 两家公司都赞同一旦范围完成里程碑完成了70%，那么任何新的功能就只能添加到 V2.0 或 V3.0 列表中 （2） 团队角色和责任 程序管理角色负责推动项目结构文档的创建。团队成员提供主要输入。 （3） 项目结构文档的组成部分 项目结构文档有三个主要的组成部分： · 团队和结构 · 项目估计 · 项目进度表（早期版本） 项目结构文档是一个记录项目执行和管理的决策的工具，包括： · 团队和客户角色及责任 · 交流管理 · 后勤决策 · 变更管理决策 · 进度评估决策 3.3.2 角色和责任决策部分的内容 项目结构文档的角色和责任部分列出了项目参与人员的姓名和他们的联系信息，比如说电话号码、电子邮件地址等。而且这一部分还描述了项目后续阶段期间在不同角色责任方面的决策。 （1） 计划阶段期间的决策 在计划阶段，团队需要做出决策来回答以下问题： · 项目计划将如何开发 · 在创建项目计划的过程中，团队如何使用从其他项目评审中获取的知识和经验 · 团队是否已经计划了整个项目的状态会议 · 客户多久评审一次 · 功能将如何分布到解决方案的不同版本中 · 谁将会确定与项目相关的风险并定义不可预见的费用 · 将使用哪些工具来开发和跟踪项目计划 · 在计划阶段团队是否举行评审会议？谁将参与评审会议 （2） 开发阶段期间的决策 在开发阶段团队需要做出决策回答以下问题： · 在项目中团队将会与哪些组、组织和外部供应商交互？谁负责创建和管理与第三方供应商的合同 · 在开发工作中每个团队领导的角色和责任是什么 · 如果解决方案的不同组件由不同的团队开发，那么在项目中每个组件团队领导的角色和责任是什么 · 每个组件团队都将分配一个技术支持、一个用户体验团队和一个测试团队吗 · 项目中高级管理人员的角色是什么 · 在项目中如果需要子承包商，那么他们的角色是什么？谁负责选择子承包商并监控他们的工作 3.3.3 交流决策部分的内容 项目结构文档的交流决策部分指定团队在项目中要遵从的交流过程。这些过程应用到团队和客户的交流之中。团队做决策回答以下问题： · 计划决策需要通知谁 · 如何将计划决策通知客户、干系人和团队 · 需要举行什么类型的会议，在哪里举行，谁参加哪种类型的会议 · 谁负责制定会议的议程 · 谁负责推动会议 · 谁负责准备和分配会议时间 · 项目的进度必须通知哪些人，怎样通知他们 （1） 关于项目文件的决策 一般情况下，在一个组织中每个项目都会维护一个文件。这个文件包含合同、进度表和计划等信息。在项目结构文档中，团队决定项目文件需要维护什么信息？对项目文件必须做的一些决策包括： · 在项目文件中需要包含哪些信息？比如说项目规范、进度表、计划、突出问题、合同等信息 · 谁负责创建和维护项目文件 · 谁能够访问项目文件 · 在项目完成之后谁负责保存项目文件，项目文件要保存多长时间 （2） 关于实现后（post-implementation）评审的决策 实现后评审是项目的一个重要部分。实现后评审能帮助评估项目是否成功，并确定需要提供哪些支持。关于实现后评审的一些决策包括： · 什么时候进行实现后评审，哪些人将参加这个评审 · 在实现后评审中将解决哪些主题 · 在项目生命周期中需要收集哪些信息来推动实现后评审？谁负责收集这些信息 3.3.4 后勤决策部分的内容 项目结构文档的后勤决策部分记录解决方案的部署方面的决策。团队做决策回答以下问题： · 使用哪些开发实践来做项目？下面是一些可能的开发实践 · 开发方法，比如说产品说明书检查和零缺陷清单之类等 · 测试方法 · 文档编制方法 · 市场推广方法 · 谁负责定义产品说明书的内容？在项目中谁将使用产品说明书，他们怎样使用说明书 · 使用哪些工具定义解决方案功能 · 产品说明书的完成标准如何制定 · 谁将为团队提供产品说明书的更新 · 团队将提供给参与项目的每个外部供应商哪些规范？谁负责创建这些规范 · 如何为项目定义和实现零缺陷方法 · 谁负责估计项目所需的工作和时间？这个估计的基础是什么（个人经验，实现后评审等等） · 谁需要解决方案支持的技术和技能方面的培训？比如项目管理培训等。在计划阶段期间谁需要有关解决方案的培训 3.3.5 变更管理决策部分的内容 项目结构文档的变更管理决策部分涵盖了团队在处理项目的任何变更时要遵从的过程。对变更管理所做的一些决策包括： · 如何定义项目的变更（例如，进度表的变更或项目成本的增加） · 发布日期是哪一天？发布日期由谁决定，如何决定 · 谁负责定义将要使用的变更管理过程 · 提议的变更如何确定和跟踪？谁负责跟踪这些信息 · 如何评估变更的影响？你最多可以接受多大程度的变更 3.3.6 进度评估决策部分的内容 项目结构文档的进度评估决策部分涵盖了团队跟踪和评估项目进度要遵从的过程。对项目进度评估所做的一些决策包括： · 如何评估项目进度？要测量进度必须收集哪些信息 · 如何从项目成员获得每个任务的进度信息？这些信息多长时间收集一次 · 组进度表多久更新一次？主项目进度表多久更新一次 · 谁负责确定和评估每次变化的影响 · 谁将参与开发自适应动作？谁将推荐和证明自适应动作？如何跟踪这些动作的效果 · 如何记录、跟踪和监控任何突出的问题 · 使用什么标准定义异常报告中的异常？谁参与评估和解决这些异常 · 如何解决不同团队之间的难题和问题？如果一个难题或问题不能在团队之间解决，需要提到管理层来解决吗？如果是，谁将上升为管理层来解决这个问题 3.4 风险分析 风险可以定义为不是所希望出现的结果。风险是一个损失的概率。损失可以是任何东西，包括解决方案的质量下降以及成本增长、错过交付期限或项目失败等。 学习完本课后，将能够： · 描述 MSF 风险管理过程 · 确定风险评估文档的内容 · 确定一个项目的风险 3.4.1 风险管理过程 图3-7 风险管理过程 开发成功的解决方案的一个重要方面是控制和降低项目与生俱来的风险。多数人将风险的概念与项目的价值、控制、功能、质量或按时完成等的潜在损失关联起来。然而，项目风险还包括不能在一个机会中获得最大的利润，以及不确定一个决策是否可能导致错过一个业务机会。 如图3-7所示，在 MSF 风险管理过程中团队在整个项目中不断地实践，因此该过程是一个主动的方法。团队不断地评估什么地方可能出错以及如何阻止或最小化任何损失。MSF 提倡使用一个正式的风险评估文档并区分风险的优先级来跟踪风险。 （1） MSF 风险管理过程的步骤 MSF 风险管理过程定义六个步骤，团队通过这六个步骤管理当前的风险，计划和执行风险管理策略，将知识编制成文档供将来的项目使用。MSF 风险管理过程的六个步骤如下： 1. 风险确定。确定风险，使团队认识到潜在的问题。 2. 风险分析和区分优先级。将与潜在风险相关的信息和数据转换成一种信息，团队可以使用这种信息为减轻风险做出决策并优化资源。 3. 风险计划和进度安排。使用风险分析阶段得出的信息，规划减轻风险的策略、计划和动作。在项目计划中为风险计划分配时间。 4. 风险跟踪和报告。监控特定风险的状态以及特定风险减轻计划的进度。报告这个进度给团队、客户和主要干系人。 5. 风险控制。执行风险减轻计划，报告风险状态给团队和客户。 6. 风险学习。将从项目中学习到的东西编制成文档，使团队和组织能够重用这些信息。 注意：风险管理的步骤是逻辑步骤；它们不需要遵从时间顺序。团队通常在确定、分析和计划步骤中反复，这个时候他们在项目中积累了一组风险经验，而只在定期地返回到学习步骤。 3.4.2 风险评估文档的内容 图3-8风险评估文档的内容 在构思阶段，团队通过以下方式实施风险管理：创建一个风险评估文档，确定和记录所有已知的风险，评估风险发生的概率及其影响。 （1） 风险评估文档的要素 风险评估文档必须包含以下项： · 风险说明，描述每个风险的性质 · 风险概率，描述风险发生的可能性 · 风险严重级，指出风险的影响 · 风险权值，指出风险的总体威胁。由风险概率与风险严重级相乘所得 · 风险减轻计划，描述阻止或尽量减小风险的计划 · 应急计划和触发条件，指定在一个风险发生时需要采取的步骤以及什么时候采取这些步骤 · 风险负责人，指出负责定期监控风险的团队成员姓名 3.4.3 创建风险评估文档 程序经理负责创建风险评估文档。在编制解决方案概念文档之前，团队可以将相关的风险与不同解决方案概念的风险进行对比。 例如，假设你正在创建一个电子商务 Web 站点。一种做法是从头创建一个新站点。然而，这就要求分配和管理大量的开发资源。而且完成这个项目可能还需要很多的时间。另外一种做法是使用 Microsoft Solution Accelerator for the Internet Storefront 快速地进入开发过程。预先配置好的源代码，MSF 项目计划原则，以及具有引用文档和工具的资源工具包可以帮助团队实现其业务目标。而且，使用这个工具可以帮助你减少完全重新构建电子商务站点相关的风险。 （1） 计算风险 在创建风险评估文档时，要为风险概率和影响赋予一个数值。概率测量一个损失发生的可能性；影响测量那个损失发生后的严重程度。之后通过将这两个数字相乘便得到每个风险的权值。通过这个过程我们可以对风险进行比较，确定它们的相对严重级和优先级。例如，使用1到4之间的数字来标示每个风险的概率和影响，4表示最高，1表示最低。通过将表示一个风险的概率和表示其影响的两个数字相乘，就可以得出一个1到16之间的权值因数。这个过程允许确定最严重的风险并首先解决它们。 要点：不需要用相同的数值范围来估计概率和影响。但是必须使用一致的范围来计划所有风险的概率及影响。如果可以精确地计算由每个风险带来的财务损失，那么就可以用财务术语来表达影响。然而，如果使用一个数字表示一些风险的影响，而使用财务术语表示其他的影响，那么就不能比较不同风险的权值。 （2） 创建一个前十位列表 在创建了风险评估文档并根据每个风险的权值对其进行排序之后，我们可以创建一个最大风险的列表，这样团队就可以着重对待它们。这个列表通常叫做前十位列表，但是并不是说一定要正好是十个风险。程序经理应该经常查看这个列表，并根据风险的重要性更新该列表。 在一个电子商务项目中所暴露的风险表示了当前解决方案所特有的以及新的方面。电子商务项目的一些风险可能包括： · 不熟悉 Web 站点的创建、部署和日常支持 · 潜在的债务，比如说如果站点不能正确地运行，或者遭遇不可用问题时，对公司声誉或品牌的损害 · 安全风险，包括恶意用户入侵系统，或者信用卡号之类的机密客户数据被盗取 警告：不要仅仅因为找出了风险就假设风险在你的控制之下。要在项目进度表中为风险管理安排足够的时间，这样才能够不浪费在风险计划上的投入。风险减轻活动、风险状态报告和风险列表更新都应该写入项目的任务列表中。 课堂活动 开发一个远景/范围文档 课堂活动预估时间：30分钟 在本次活动中，将使用本章所学知识完成一个项目的构思阶段。可以三四个同学组成一组完成这个练习。在完成所有的练习之后，与班上其他同学分享答案。每个练习都是基于 Adventure Works Cycles 场景的。如果要阅读这个场景，可以从培训材料光盘根目录下的 Appendices\Mod01 文件夹中打开 AWC-CaseStudy。 练习1 写出问题说明 阅读描述 Adventure Works Cycles 销售部门的示例场景，为所描述的项目写出问题说明。确保写出的问题说明概括了业务问题，并能为这个场景中的项目团队提供方向。 在实验文件夹\Practices\Mod03\Solution文件夹下的 C03Ex1_Answer.doc 中有一些示例问题说明的例子。 练习2 写一个远景说明 为示例场景中描述的应用程序写一个远景说明。远景说明应该具体、可测量、可实现、现实、并基于时间。下面是一些远景说明的例子： · 由 John F. Kennedy 创建 Apollo任务的远景说明：“在未来10年内将一个人送到月球。” · 在接下来的18个月内，将我们最畅销的三种产品的销售量增加25% 在实验文件夹\Practices\Mod03\Solution 文件夹下的 C03Ex2_Answer.doc 给出了这个练习的参考答案。 练习3 制定项目目标 从给出的场景，确定项目目标，包括业务目标和设计目标。 在实验文件夹\Practices\Mod03\Solution 文件夹下的 C03Ex3_Answer.doc 给出了该练习的参考答案。 解决方案文档叙述 为了阐明本章讨论的设计活动，我们对与本章相关的解决方案文档进行了如下分析。在构思阶段团队已经收集了大部分需要的信息，发现了完整的用例集合，并且已经决定将项目范围缩小为首先实现销售应用程序和 Web 应用程序。团队在到达远景/范围认可里程碑时创建构思阶段交付成果的一个基线版本。在接下来的几节中，这些文档以大概的创建顺序列出，但是要注意一点，这些文档大部分是同时开发的。 （3） User Profiles.doc 和 AWC – Actors Catalog.xls 用户档案文档包括用户的初步描述、他们的主要功能以及他们与之交互的主要数据类型。用户被划分成不同的角色组，变成“操作者”，然后维护在操作者编录中。操作者角色将在用例中用到，而一些操作者将不会出现。例如，虽然副总裁和生产职员都能编辑产品规格，但是（在用例、测试脚本和其他设计文档中）表示两者的操作者标题都标为生产职员。 （4） AWC – Business Rules Catalog.doc 该文档列出解决方案必须遵守的业务规则。 （5） AWC Use Cases – Chapter 3.vsd Initial Use Case 选项卡。该选项卡给出了在当前的状态下，项目范围确定之前发现的完整用例集。 Revised Use Case 选项卡。该选项卡给出了团队决定系统允许客户添加、编辑和跟踪订单之后的用例。 Use Case In Scope 选项卡。该选项卡给出了在范围讨论中取得一致意见的用例集。 Concept Model 选项卡。该选项卡给出 Adventure Works Cycles 提议的解决方案的一个概念模型。它描述项目团队对模块和包的远景。它还描述在必须的解决范围中模块和包之间的关系。概念模型通常依赖于用例以及开发得较好的需求文档。一般，用到的技术（标示为“Browser”的方框）将不在概念阶段声明。然而，因为有一些具体的需求，包括销售人员需要使用现有的运行 Microsoft Window® CE 的设备、便携式计算机、桌面计算机，Web 客户需要从 Internet 访问产品接口，所以说在这个概念模型中已经包含了这些技术。 Solution Concept 选项卡。该选项卡为不需要详细概念模型的干系人提供了一个粗略版本。 （6） AWC – Requirements Document – Chapter 3.xls 该文档列出了需求，这些需求仍然在开发中，因为它们在确定范围时才为人所知。该文档在用例发现的时候开始。问题应该被记录和回答。 （7） AWC – Simple Risk Assessment Tool 和 AWC – Risk Tool 提供这两个工具是为了给你带来方便。根据项目的具体需要，可能只会用到其中一个工具。简单的风险评估工具对于大多数需求来说已经足够，但是大的风险工具文档将提供更多的跟踪和变更控制能力。对于一个具体的项目来说，团队喜欢选择哪个工具全看他们自己。即使项目很小，大的风险工具文档也同样适用。 （8） Project Plan.mpp 该文档列出项目的任务、初步进度表和资源。在项目结构文档中有它的一个摘要版本。 （9） Cost Model.xls 这个文档列出项目的预算估计，它是项目结构文档的一部分。 （10） AWC – Vision Scope.doc 该文档作为一个例子提供。用户档案、用例、操作者编录、业务规则编录以及需求中的信息决定了这个文档的内容。 （11） AWC – Project Structure.doc 该文档作为一个例子提供。它提供了成本估计和进度表估计。Cost Model 工作表和 Project Plan.mpp 是项目结构文档的两个主要的来源文档。该文档还描述了团队结构，并记录了在这一点有关合作的任何协议。 本章小结 · 构思让团队清楚地认识到他们需要为客户实现的功能 · 团队成员必须胜任和熟练在开发解决方案中所要完成的任务 · 项目范围指定什么应该包含在项目中，什么不应该包含在项目中 · 构思阶段的交付成果包括远景/范围文档，风险评估文档，以及项目结构文档 · 项目团队还开发其他一些文档供内部使用，包括操作者编录、业务规则编录和术语表 · 远景/范围文档包括以下信息：团队和项目结构、问题说明、远景说明、项目范围、解决方案概念、用户档案和项目目标等 · 远景说明说明要解决业务问题的长期解决方案 · 问题说明指出要由解决方案解决的问题 · 项目范围受项目假定、项目约束和项目估计的影响 · 解决方案概念指出团队打算如何实现项目目标 · 用户档案确定解决方案的所有可能用户以及他们的期望、目标、风险和约束 · 业务目标表示客户想要使用解决方案解决的问题 · 设计目标表示项目团队要开发的解决方案的属性 · 项目结构文档包含以下信息：团队的管理结构、管理标准和管理过程，以及项目资源和项目约束等 · 项目结构文档的主要组成部分有 · 团队和结构 · 项目估计 · 项目进度表（早期版本） · 项目结构文档是一个文档工具，它记录有关项目的执行和管理的决策，包括 · 团队角色、责任以及客户角色、责任 · 交流决策 · 后勤决策 · 进度评估决策 · 构思阶段最后得出一个认可的远景/范围文档 · 团队、主要干系人和客户认可远景/范围文档表示构思阶段的完成 · MSF 提倡在整个项目生命周期内进行持续的风险管理 · MSF 风险管理过程定义六个步骤，团队通过这六个步骤管理当前的风险，计划和执行风险管理策略，为企业记录知识。这六个步骤为 · 风险确定 · 风险分析和区分优先级 · 风险计划和进度安排 · 风险跟踪和报告 · 风险控制 · 风险学习 · 在构思阶段，团队通过创建风险评估文档来实施风险管理。风险评估文档的内容包括 · 风险陈述 · 风险概率 · 风险严重级 · 风险权值 · 减轻风险的计划 · 应急计划和触发条件 习题 一家网上商城为了整合三地的仓储资源，加快物流速度，决定聘请一家著名的ERP咨询公司实施新的库存管理系统，你是这个项目产品经理。 1. 以下哪些内容你会考虑放在远景/范围文档中？会如何组织？ a) 客户在全国三地有仓储资源，并能覆盖周边地区 b) 客户分散的仓储无法跨区及时调配和优化 c) 客户希望通过实施库存系统，整合三地资源，加快物流速