第3章 CHAPTER 3 项目范围管理 项目管理过程中最重要也是最困难的方面之一是明确项目计划。项目计划是指根据对未来的项目决策，项目执行机构选择制定包括项目目标、工程标准、项目预算、实施程序及实施方案等的活动。在一个具体的项目环境中，可作为预先确定的行动纲领。制定项目计划旨在消除或减少不确定性； 改善经营效率； 对项目目标有更好的理解及为项目监控提供依据。项目计划活动首先要进行的就是估算——估算项目的时间、估算项目的工作量、估算项目所需人员数量、估算项目所需要的资源量（硬件及软件）和项目可能遇到的风险。 而在制定项目计划中，要明确项目的需求及其管理的范围； 而软件项目的范围首先从软件项目的需求开始。 3.1 项目范围 管理 3.1项目范围管理 项目范围是指开发项目产品所包括的工作及产生这些产品所包含的全过程，在此基础上，项目范围管理是界定和控制项目中包含什么和不包含什么的全过程。这个过程确保项目团队和项目干系人对项目的可交付成果以及生产这些可交付成果所进行的工作达成共识。在项目范围管理中，首先要明确定义项目的范围，它是项目实施的依据和变更的输入，只有对项目的范围有了明确的定义，才能进行项目规划。项目范围管理主要包括如下4个阶段。 （1） 项目需求： 定义并记录项目最终产品的特点和功能，以及创造这些产品的过程。例如： 盒马鲜生物流系统可以实现网上零售管理、产品配送管理、财务管理和人力资源管理等功能。 （2） 范围定义： 根据项目需求分析的成果，把项目的主要可交付产品和服务分为更小的、更容易管理的单元，即形成工作分解结构(Work Breakdown Structure, WBS)。例如： 根据学校图书馆的实际项目需求，为图书馆管理系统建立工作分解结构。 （3） 范围核实： 指对项目范围的正式认定，项目主要干系人（如项目客户和项目发起人等）要在该过程中正式接受项目可交付成果的定义。该过程可以确保项目范围能得到很好的管理和控制。例如项目经理和客户通过召开需求会议的方式，确定物流系统的可交付成果（包括项目计划、工作分解结构、进度计划、状态报告、产品、服务和用户手册等）。 （4） 范围控制： 指对有关项目范围的变更实施控制。主要的过程输出是范围变更、纠正行动与教训总结。例如，项目干系人不断通过访谈等形式对用户的实时需求进行了解，从而保证范围变更在可控范围内。 3.2软件项目管理 软件项目管理的对象是软件工程项目，所涉及的范围涵盖了整个软件工程过程。软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员（People）、产品（Product）、过程（Process）和项目（Project）进行分析和管理的活动。 软件项目管理的根本目的是保证整个软件项目在整个软件生命周期（从软件分析、软件设计到软件运行与维护）都在管理者的控制之下，以预定成本和质量按期完成软件并交付用户使用。 软件项目管理和其他的项目管理相比有相当的特殊性。首先，软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以保证。第二，软件系统的复杂性也导致了开发过程中各自风险的难以预见和控制。第三，软件项目实现的结果与软件需求分析的结果息息相关。 因此，软件项目需求管理是项目范围管理的起始点，也是软件项目规划与实施的基础，软件需求管理的结果将直接影响项目的成败。 3.2.1软件需求管理 启动软件项目的原因是软件需求的存在，软件开发模型有瀑布模型、快速模型和增量模型等，但无论采用哪一种模型，软件需求分析是软件开发过程的基础。在软件开发统计数据中，软件项目中40%~60%的问题都是在需求分析阶段埋下的隐患。而在以往失败的软件项目中，80%的失败项目是由于需求分析的结果不明确造成的。因此，一个软件项目成功的关键因素之一就是对需求分析的把握程度，而软件项目的整体风险往往表现出需求不明确、业务流程不合理，所以，需求管理是项目管理的重要一环。 软件需求是： ①用户为解决某一问题或达到某一目标所需条件或权能； ②系统或系统构件为了满足合同、规约、标准或其他正式实行的文档所需具有的条件或权能； ③一种反映上述①或②所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，例如性能要求、质量标准，或者设计限制。 软件需求就是指用户希望软件能做什么事情，实现什么样的功能，达到什么样的性能。因此，软件项目管理人员要准确地理解用户所提出的要求，进行细致的需求调查分析，将用户的非形式化的需求陈述转化为完整的需求定义，并依据此定义转化为需求规格说明书。 软件需求分为三个层次： 业务需求（business requirement）、用户需求（user requirement）和功能需求（functional requirement）。最后据此确定软件需求规格（software requirement specification, SRS）。业务需求一般说明在范围文档中，它是指组织机构或客户对系统、产品高层次的目标要求，由管理人员或市场分析人员确定； 用户需求可以在用例或场景中进行说明，它必须与业务需求一致，描述了用户通过使用本软件产品必须要完成的任务； 功能需求是指开发人员必须实现的软件功能，使用户通过使用此软件能够顺利完成任务，从而实现业务需求。软件需求规格则描述了软件系统应该具有的外部行为特征，包括了软件必须遵从的标准、规范和合约； 外部界面特点； 非功能性要求（例如性能要求等）； 设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品特点进行描述，从而反映产品功能。上述关系如图31所示。 图31软件需求的层次 有效的软件需求管理可以大大减少开发后期和整个维护阶段返工的工作量。Boehm(1981)验证发现，改正在产品应用后发现的需求方面的错误比在需求阶段改正同一错误多付出68倍的成本。20世纪80年代后期，逐渐产生了软件工程的分支领域——需求工程（Requirement Engineering,RE），它是指应用已经证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的学科，它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。 软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换为软件的需求描述和一些性能参数。其目的是在客户和遵循客户需求的软件项目之间建立一种共同的理解，但在实际软件需求管理过程中尚存在如下问题： （1） 范围界定方面： 系统的目标、边界未被良好地定义，用户对此容易混淆。 （2） 理解问题方面： 用户不能完全了解自己需要什么，对系统的能力、局限更不清楚。软件工程师不理解用户的问题域和应用环境，相互之间的沟通存在问题。 （3） 易变性方面： 随时间的变化，系统需求会发生变化。 3.2.2需求获取 软件需求获取是指通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求的过程，是整个软件项目开发过程中最为关键的输入。软件需求获取具有模糊性、不确定性、易变性和主观性。 软件需求获取是项目干系人、用户之间为了定义新系统而进行的交流。需求获取是需求分析的前提，需求获取是获得系统必要的特征，或者是获得用户能接受的、系统必须满足的约束。用户来自不同的行业，对所要开发的系统的目标已做出总体的规划，但由于用户缺乏专业的软件开发经验和技术，同时，虽然项目干系人对开发软件过程中有丰富的经验，但对于用户所在行业内容知识了解较少。如果双方所理解的领域内容在系统分析、软件设计过程中出现问题，通常在开发过程的后期才会被发现，将会使整个系统交付延迟，或上线的系统无法或难以使用，最终所开发的系统以失败告终，从而出现严重的软件危机。例如遗漏的需求（丢失了系统必须支持的功能）或错误的需求（不正确的功能描述或不可使用的用户界面）。需求获取的目标是提高开发者与用户之间沟通的能力，进而构造应用系统的领域模型。 在面向对象的方法中，项目干系人选择用户易于理解的表达方式，通过使用用例（用例图）来获取软件的需求。用例通过描述“参与者”和“系统”之间的交互方式描述系统的行为。用例方法最主要的优点在于以用户为导向，用户可根据自身所对应的用例不断细化自己的需求。与此同时，使用用例还可方便地得到系统功能的测试用例。 1. 需求获取的输入和开始准则 为了对系统有全面的理解，需要确定初始的范围，从较高的层次描述软件项目需要实现什么，该范围作为需求收集阶段的输入。根据能够得到的必要信息，客户和竞标项目的组织拟定一份合同，合同规定了每一方的义务。在签署合同之前，每个组织应反复讨论协商并评审项目范围，确保没有做出无法实现的承诺。经过项目经理批准后，该高层次项目范围确定了要开发的软件部分，软件部分的细节成为软件需求获取的内容。 2. 软件需求获取内容 将需求获取看成是项目能够最大限度地满足客户的方法，而不是局限于狭窄的范围，仅仅作为获取一个给定系统的功能性需求的技术过程。软件需求获取主要包括4个方面。 1) 职责 正确的需求获取是后续活动成功的基础。如果没有正确地获取需求，无论后续步骤执行得多么到位，都不可能构建一个真正满足用户的系统。保证这一步正确是首先要解决的方面。促使这方面获得成功的措施有确定单一联系点和最终的决定权、确定和建立解决问题的服务级别合约、确定变更控制规范和确定法规的遵循问题。 理想情况下，为了说明和仲裁需求，应该从客户组织中一个单一且最终的联系点开始。这个单一联系点应该由客户组织的高层经理提名，并正式通知组织的其余人员。为凸显软件项目的合法性和权威性，该单一联系点通常为软件项目的项目经理或首席信息官。项目经理(或项目首席信息官)是资源分配和谈判的渠道。 任何软件系统中都有一个无法避免的事实，即需求的变更。变更是无法避免的，是不以主观愿望为转移的。更确切地说，变更必须预料到，并且按照适当的变更控制规范进行管理。变更控制解决变更中的请求、识别、评估的程序问题。在需求阶段，当系统的定义仍旧在演化时，变化几乎同步发生。通过使用最终决定权和单一联系点，需求的变更内容可以被汇集和合并。与此同时，在系统设计和系统运行和维护阶段中，需求变更需要花费巨大的成本，并且使软件开发的进度变缓，不能按期交付客户使用。因此，在承诺的条件下，识别什么类型的变更可以请求，如何决定一个特别的变更是否值得做以及带来的花费是什么，是十分重要的。 2) 需求调查形式 需求获取的主要任务是和用户方的领导层、业务层人员的访谈式沟通，目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织结构、业务流程、硬件环境、软件环境、当前运行的系统等具体情况和客观信息，建立起良好的沟通渠道和方式。在根据客户的要求确定系统的整体目标和系统的工作范围后，需对客户进行访谈和调研。交流的方式可以为会议、电话、电子邮件、小组讨论和模拟演示等不同形式。对于每一次交流均要进行记录，并对于交流的结果进行具体的分类，便于后续活动的进行。例如将一个图书馆管理系统的需求细分为功能需求、非功能需求(如响应时间、平均无故障工作时间、自动恢复时间等)、环境限制、设计约束等类型。对此，需求调查形式有以下四个方面：  需求专题讨论会。它是指在一段短暂但紧凑的时间段内，把所有与需求相关的人员集中到一起，围绕产品或者项目的目标进行研究和讨论，并总结出初步的需求。需求专题讨论会需要有经验的人(例如需求工程师)组织才能保证成功。  电视电话会议访谈。电视电话会议访谈是一种自由的、开放的获取需求的方式，可以深入探究用户对某些问题的回答，从而得到更准确的信息。  Q&A列表邮件提问。该方法是向用户调查需求的主要方式。它是指对软件产品需求不明确的问题，整理归纳成Q&A列表，通过邮件方式获取用户的需求。Q&A列表可以详细记录需求问题从不明确到清晰的完整过程，但获取需求的进度取决于用户能否及时地回复邮件，因此需要花费大量的时间。  自行搜集需求。对于用户不能明确提供的需求，根据自行调查相关的行业标准、同类标准，总结出功能、非功能需求。并将需求点通过需求专题讨论会和电视电话会议访谈的方式与客户委托方进行确认。 3) 系统需求分析 需求分析也称为需求建模，是需求获取后为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述，并尽可能多地捕获现实世界的语义。需求分析的任务就是借助当前系统的逻辑模型导出目标系统逻辑模型，解决目标系统“做什么”的问题。从当前系统转化为目标系统的需求分析模型如图32所示。 图32需求分析模型 当前系统需求可以分类为： ①功能需求,为系统应该做什么，提供了定性的描述； ②性能需求,规定了应用要满足的性能，是严格的定量描述； ③可用性需求,对各种部件正常运行时间的期望描述； ④安全需求,决定谁有权利使用系统的哪一部分(以及使用多少次)，安全需求必须在需求阶段的早期确定； ⑤环境定义,系统将要运行于其上的软件和硬件平台方面的限制。 4) 目标系统的需求 为成功部署软件产品，确保项目正常实施，在需求管理阶段，不仅要准确分析客户对于软件产品的需求，还要考虑客户所需要的非软件方面，其中包括： （1） 文档： 每个产品都需要文档，需要到何种程度取决于产品的复杂度和达成的合约。一个产品需要的文档类型包括用户手册、设计和内部文档、安装指南和在线帮助。 （2） 培训： 一旦产品开发完成，可能需要培训客户。对不同的客户可能有不同层次的培训。需要培训客户如何使用模块(数据输入格式、菜单、报表等)； 对系统管理员培训安全、系统备份、恢复等功能； 如果产品的后续维护移交给客户，则可能需要培训客户组织中的开发人员了解真实的程序以及如何维护该程序。因此，需要什么程度的培训，决定了要付出的工作量。 （3） 后续支持： 一旦系统被部署在用户那里，将会需要后续的支持，在这方面必须回答的问题包括需求变更由什么构成以及如何处理它、代码改正的周期、产品维护周期、变更范围。 3. 软件需求获取遵循的步骤 需求获取的步骤如下： (1) 开发高层的业务模型。客户和开发组织确定各自的单一联系点，授予做决定的权利，并代表各自的组织利益行事。在此基础上，项目干系人需对所开发领域进行充分了解，并建立业务模型，描述用户的业务过程，确定用户的初始需求。最后通过迭代，更深入地了解应用领域，并对初始业务模型进行改进。 (2) 定义项目范围和高层需求。在软件项目开始之前，应当在所有项目相关方面建立一个共同的愿景，即定义项目范围和高层需求。项目范围描述系统的边界与外部事物(包括组织、人、硬件设备、其他软件等)的关系。高层需求不涉及过多的细节，主要表示系统需求的概貌。 (3) 识别用户类和用户代表。保证软件开发组织分析需求的一致性和完整性。在此基础上确定目标系统的不同用户类型，在需要项目澄清时，接触客户组织中适当的联系点并解决问题。 (4) 获取具体需求。获取开发组织以需求规格说明文档的形式得出讨论结果。 (5) 确定目标系统的业务工作流。根据客户组织中的人员评审需求规格说明文档，确保目标系统业务工作的一致性和完整性。在需要变更的情况下，与软件项目干系人进行磋商，保证双方对需求有一致的、完整的、无二义性的理解。 (6) 需求整理与总结。对上述步骤的需求资料进行整理和总结，确定对软件系统的综合要求，即软件系统的需求，并提出这些需求实现条件，以及需求应达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求等。 4. 需求阶段的输出和质量记录 需求收集过程的主要输出是需求规格说明文档（Software Requirement Specification,SRS），需求分析完成的标志是提交一份完整的软件需求规格说明书(SRS)。该说明书以一种开发人员可用的技术形式陈述了一个软件产品所具有的基本特征和性质，以及期望和选择的特征和性质。对于一个软件项目来说，软件需求规格说明书(SRS)和工作陈述(Statement of Work，SOW)是极为关键的文档，SRS的编写可以参照甲方提供的SOW的相关信息进行，SRS为客户和开发者之间建立一个约定，准确地陈述了要交付给客户的内容。软件需求规格说明书(SRS)包括客户和开发组织最终都同意的所有信息，它有各种可能的格式。 在需求收集阶段需要获得的主要质量记录包括为讨论需求而举行的各种会议的备忘录、为了阐明或者解决需求中的冲突而写的任何来往信件、变更请求及其影响、有决定权的人员的签字。 5. 需求获取技能和存在的问题 需求获取阶段以很高的客户能见度和互动为特征，比其他阶段更需要高层次上的沟通，并伴有很大程度上的流动性。基于所有这些因素，领导或者参与需求收集阶段的人员需要7种技能： 从客户的视角看待需求的能力、领域知识、技术意识、人际交往技巧、谈判技巧、对不明确因素有一定的承受能力，以及沟通技能。 进行需求获取时应该注意如下问题： (1) 识别真正的客户。软件项目在开发过程中会面对多方的客户，不同类型客户的素质和背景都不一样，不同客户之间可能不存在共同的利益，例如： 销售人员希望系统使用方便，会计人员希望系统可以对销售的数据进行有效的统计，人力资源部门更关注系统如何管理和培训员工，不同客户之间的利益还可能存在冲突。因此，需要清楚地认识影响项目的不同客户，并对多个客户的需求进行排序，如果与项目无干人参与项目，需暂缓考虑其需求。 (2) 正确理解客户的需求。在访谈过程中，客户并不能有效表达真正的需求，可能提供一些混乱的信息，甚至会夸大或者弱化真正的需求。因此，项目干系人在了解客户所在行业的专业知识外，还要了解客户的业务和社会背景，有选择地过滤需求，理解和完善需求，确认客户真正需要的东西。例如，在买衣服时，客户都会谈论衣服颜色、款式和面料等方面的需求，但买衣服中隐含的需求(御寒、漂亮或体面等)并不会直接表达。 (3) 具有较强的忍耐力和清晰的思维。进行需求获取的时候，应该能够从客户凌乱的建议和观点中整理出真正的需求，不能对客户需求的不确定性和过分要求失去耐心，甚至造成不愉快，要具备较好的协调能力。 (4) 说服和教育客户。需求分析人员可以同客户密切合作，帮助他们找出真正的需求，通过说服、引导等手段，也可以通过培训来实现； 针对需求变更，要与客户进一步交流，并告知客户需求变更为正常项目开发所带来的影响。 (5) 建立需求分析小组。在软件项目开发过程中，需求分析人员应成立专门的需求分析小组，进行充分交流，对客户所提出的需求进行实地考察访谈，并收集相关资料，在必要时可以采用图形表格等工具。 3.2.3需求验证 需求获取完成，提交需求规格说明后，软件分析人员需要与客户对需求分析的结果进行验证，以需求规格说明为输入，通过符号执行、模拟和快速原型等途径，分析需求规格的正确性和可行性。需求验证通常包括如下6个方面。 1. 正确性 软件分析人员需要和用户一起进行需求的复查，以确保将用户的需求充分、正确地表达出来。每一项需求都必须准确地陈述其要开发的功能。如果软件需求与对应的系统需求相抵触，则验证是不正确的。需要注意的是，只有用户代表才能确定用户需求的正确性。 2. 一致性 这里的一致性是指与其他软件需求或高层需求不互相冲突。在开发前必须解决所有需求间的不一致部分。验证所获取的需求没有冲突和二义性。 3. 完整性 验证是否所有可能的状态、状态变化、产品和约束都在需求中描述，不能遗漏任何必要的需求信息。因此，在进行软件开发前，必须解决和补充需求中所有的遗漏项。 4. 可行性 验证需求是否可行，每一项需求都必须在已知系统和环境的约束范围内可以实施。 5. 可追溯性 验证需求是否是可被追溯的，即应该在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起连接，这种可追溯性要求每项需求以一种结构化的方式编写。 6. 可检验性 检查每项需求是否能通过设计测试用例或其他的验证方法。若需求不可验证，则其正确性便失去了客观依据。例如，“界面友好”“性能优越”等模糊定性的需求便是不可检验的，这可能导致后期的软件验收问题。 如果软件项目缺乏合理的需求验证，就可能导致因不能实现预期的功能而需要在后期进行高代价的修正、拖期和超出预算等问题。 3.2.4需求变更 需求变更是软件项目区别于传统项目的显著特点。在软件开发过程中的需求变更会给软件开发带来不确定性，因此，需求变更管理主要从如下几方面入手展开。 1. 建立需求基线 需求基线指是否允许需求变更的分界线，它是需求变更的依据。在需求被确定和评审后，可以建立第一条需求基线。每次需求变更都需要对需求基线进行重新确定。当软件分析人员与客户进行沟通建立了需求文档，则该文档经过评审后即可建立第一条需求基线。 2. 确定需求变更控制过程 需求基线建立后，需要制定有效的变更控制流程文档，所有变更都需要遵循该流程文档进行控制。 3. 建立变更控制委员会 变更控制委员会由包括项目用户方和开发方的决策人员在内的人员共同组成，该委员会负责裁定接受变更的范围。 4. 进行需求变更影响分析 进行需求变更影响分析可以对申请的需求变更有深刻的理解，从而对进行中的工作做出调整部署。 5. 跟踪所有受需求变更影响的产品 需求变更后，记录每个需求变更文档的版本号、日期以及变更的原因和内容，以使更新后的软件计划、活动与变更后的需求保持一致。 6. 衡量需求稳定性 如果需求变更过于频繁，则说明对需求的认识不够深入； 如果需求变更的总体数量过高，则意味着项目范围确定存在问题。 3.3 WBS 3.3项目工作分解 项目管理计划是描述项目范围如何进行管理，项目范围怎样变化才能与项目要求相一致等问题的。它还包括对项目范围稳定的预期而进行的评估(例如项目需求的变更、变化频率等)。范围管理计划也应该包括对变化范围确定，变化分类等问题的清楚描述。 范围计划编制是将产生项目产品所需进行的项目工作(项目范围)渐进明细和归档的过程。在进行范围计划编制工作是需参考大量的信息(例如产品描述)，需要清楚最终产品的定义，从而保证规划工作的实施。项目章程是该过程的主要依据，范围计划是在此基础上进一步深入和细化。 当解决问题过于复杂时，可以将问题分解成容易解决的子问题，在规划软件项目时，从任务分解角度出发，需将一个软件项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作，从而提高软件项目估算成本、时间和资源的准确度。完成软件项目是一个极其复杂的过程，必须采取分解的手段把主要的可交付成果分成更容易管理的单元，并最终得出项目的分解结构。 3.3.1创建工作分解结构 工作分解是对需求的进一步细化，是最后确定项目所有工作范围的过程。工作分解的结果便是工作分解结构(Work Breakdown Structure, WBS)。WBS是面向可交付成果的对项目元素的分组，组织并定义了整个项目的范围，是一个分级的树型结构，是对项目由粗到细的分解过程。WBS以可交付成果为中心，采用自顶向下、自底向上或类比的方法，将项目中所涉及的工作进行分解，定义出项目的整体范围。工作分解结构把项目工作分成较小和更便于管理的多项工作，每下降一个层次意味着对项目工作更详尽的说明。工作分解结构是当前批准的项目范围说明书规定的工作。构成工作分解结构的各个组成部分有助于利害关系者理解项目的可交付成果。因此，WBS由以下四部分构成。 (1) 编码。编码是最显著和最为关键的WBS构成因子，首先编码用于将WBS彻底地结构化。通过编码体系，项目干系人很容易识别WBS元素的层级关系、分组类别和特性。随着计算机科技的高速发展，编码实际上使WBS信息与组织结构信息、成本数据、进度数据、合同信息、产品数据、报告信息等紧密地联系起来。 (2) 工作包。工作包(work package)是WBS的最底层元素，一般的工作包是最小的“可交付成果”，这些可交付成果很容易识别出完成它的活动、成本和组织以及资源信息。例如： 管道安装工作包可能含有管道支架制作和安装、管道连接与安装、严密性检验等几项活动； 包含运输焊接和管道制作人工费用、管道和金属附件材料费等成本； 过程中产生的报告和检验结果等问题； 被分配的工班组等责任包干信息等。因此，一个用于项目管理的WBS必须被分解到工作包层次才能够使其成为一个有效的管理工具。 (3) WBS元素。WBS元素是指WBS结构上的每一节点。可以通俗地理解为“组织结构图”上的一个个“方框”，这些方框代表了独立的、具有隶属关系和汇总关系的“可交付成果”。工作包是最底层的WBS元素。 (4) WBS字典。WBS字典是用于描述和定义WBS元素中的工作的文档。字典相当于对某一WBS元素的规范，即WBS元素必须完成的工作以及对工作的详细描述； 工作成果的描述和相应规范标准； 元素上下级关系以及元素成果输入输出关系等。同时WBS字典对于清晰地定义项目范围起到规则作用，从而确保WBS易于理解和被组织以外的参与者接受。在建筑业，工程量清单规范就是典型的工作包级别的WBS字典。 3.3.2工作分解的过程 创建工作分解结构的主要输入是项目范围说明书、组织过程资产和批准的变更请求。工作分解需要的主要工具和技术是分解，即把项目可交付成果分成较小的、便于管理的组成部分，直到工作和可交付成果定义到工作细目水平。工作分解的主要输出是项目范围说明书、工作分解结构、工作分解结构词汇表、范围基准、项目范围管理计划和请求的变更。 进行工作分解的标准应该统一，不能有双重标准。选择一种项目分解标准之后，在分解过程中应该统一使用此标准，避免因使用不同标准而导致的混乱。可以采用生存期为标准、产品的功能为标准或者以项目的组织单位为标准。进行任务分解的基本步骤如下。 (1) 确认并分解项目的主要组成要素。通常，项目的主要要素是这个项目的工作细目。以项目目标为基础，作为第一级的最整体的要素。项目的组成要素应该用有形的、可证实的结果来描述，目的是使绩效易检测。 (2) 确定分解标准，按照项目实施管理的方法分解，而且分解的时候标准要统一。分解要素是根据项目的实际管理而定义的。不同的要素有不同的分解层次。例如： 项目生存期的阶段可以当作第一层次的划分，把第一层次中的项目细目在第二阶段继续进行划分。 (3) 确认分解的详细程度以及作为费用和时间估计的标准，明确责任。工作细目的分解如果在很久的将来才能完成，就不存在确定性。 (4) 确定项目交付成果。根据项目规范的衡量标准检测交付结果。 (5) 验证分解正确性。验证分解正确后，建立一套编号系统。 3.3.3工作分解的类型 合理的WBS制定应该按照逐层深入的思想，先确定软件项目框架，再逐层向下进行分解。WBS中的每一个具体分节应该标明唯一的编码，编码不仅使工作分解层次清晰，还可以充当项目经理、项目团队以及客户代表的共同认知的符号标记。WBS中的编码与分节结构条目应该具有一一对应的关系。 例如，在盒马鲜生管理信息系统中有如下功能： 在入库管理子系统中，实现货物品质检测，冷链存储，复核更新货物信息； 在出库管理子系统中，能实现查询货物仓位，冷链包装，以及复核更新货物信息； 在物流配送管理子系统中，能实现车队信息管理与考核，订单分配与车辆分配，以及货物跟踪； 在结算管理子系统中，能够实现供应商财务结算，客户订单查询结算取消，以及员工工资结算； 在企业情报管理子系统中，能够实现企业历史运营数据管理，企业未来决策数据分析； 在订单管理子系统中，能实现对订单信息进行管理、查询和修改，订单信息转换、确认和打印，以及交接单信息管理； 在人力资源管理子系统中，能对人力资源进行规划化，人员分配、培训和考核，以及薪酬福利管理； 在信息维护子系统中，能够进行用户识别与信息反馈，并对系统进行维护和运行管理。 工作分解可采取清单类型和图表类型两种形式。 1. 清单类型 采用清单类型的分解方式，就是将任务分解的结果以清单的表述形式进行层层分解的过程，类似于图书的目录结构，如表31所列。 表31清单类型 模 块 等 级模 块 名 称 1盒马鲜生管理信息系统 1.1入库管理 1.1.1货物品质检测 1.1.2冷链存储 1.1.3复核更新货物信息 1.2出库管理 1.2.1查询货物仓位 1.2.2冷链包装 1.2.3复核更新货物信息 1.3物流配送管理 1.3.1车队信息管理与考核 1.3.2订单分配与车辆调配 1.3.3货物跟踪 1.4结算管理 1.4.1供应商财务结算 1.4.2客户订单查询结算取消 1.4.3员工工资结算 1.5企业情报管理 1.6订单管理 1.7人力资源管理 1.8信息维护管理 2. 图表类型 采用图表类型的任务分解就是进行任务分解时采用图表的形式进行层层分解的方式，如图33所示。 图33图表类型 3.3.4工作分解的用途及种类 WBS是面向项目可交付成果的成组的项目元素，项目元素定义和组织软件项目的总的工作范围，未在WBS中包括的工作就不属于项目的范围。WBS每下降一层就代表对项目工作更加详细的定义和描述。较好的工作分解可以防止遗漏项目的可交付成果，帮助项目经理关注项目目标和澄清职责，建立可视化的项目可交付成果，以便估算工作量和分配工作； 帮助改进时间、成本和资源估计的准确度； 帮助项目团队的建立和获得项目人员的承诺； 为绩效测量和项目控制定义一个基准，辅助沟通清晰的工作责任； 为其他项目计划的制定建立框架，帮助分析项目的最初风险。 WBS具有4种主要用途： ①WBS是一个描述思路的规划和设计工具，它帮助项目经理和团队确定和有效地管理项目的工作； ②WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具； ③WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具； ④WBS定义了里程碑事件，可以作为项目状况的报告工具,向高级管理者和客户报告项目完成情况。 制作工作分解结构过程生成的关键文件是实际的工作分解结构。分解结构每一组成部分包括工作细目与控制账户，赋予一个唯一的账户编码标识符。这些标识符形成了一种费用、进度与资源信息汇总的层次结构。 工作分解结构不应与其他用来表示项目信息的“分解”结构混为一谈。在某些应用领域或其他知识领域使用的其他结构包括以下几类： (1) 组织分解结构(Organizational Breakdown Structure,OBS)： 按照层次将工作细目与组织单位形象地、有条理地联系起来的一种项目组织安排图形。 (2) 材料清单(Bill of Material,BOM)： 将制造产品所需的实体部件、组件和组成部分按照组成关系以表格形式变现出来的正式文件。 (3) 风险分解结构(Risk Breakdown Structure,RBS)： 按照风险类型形象而又有条理地说明已经识别的项目风险的层次结构的一种图形。 (4) 资源分解结构(Resource Breakdown Structure,RBS)： 按照种类和形式而对将用于项目的资源进行划分的层次结构。 3.4盒马鲜生管理信息系统案例分析 本项目需求分析阶段，项目干系人缺乏对物流管理信息系统的相关知识，不能充分理解客户的真实需求。随着对系统组织结构的深入了解，发现部分存在不合理或不完整或缺失的需求，必然会引起需求变更。为了避免不必要的需求变更，在开发盒马鲜生管理信息时，从系统所在企业的组织需求分析，具体分析每个子系统的业务需求，并绘制数据流图。在此基础上，项目组与用户通过访谈等形式确定需求规格。本项目采用原型分析法确定需求，然后根据用户确认的原型系统，并结合每个子系统的数据流图编写软件需求规格说明书。最后，根据软件需求规格说明书形成该项目的最后范围计划，即WBS结果。 3.4.1结算管理子系统 结算管理子系统是对销售收入以及人力、物力资本支出等进行结算处理，系统可以每月进行一次成本和利润的核算，对内部资金流进行有效处理。结算管理子系统对顾客、管理人员及普通员工开放不同功能。对管理员而言，主要包括费用种类、收款处理、付款处理、应收款查询、应付款查询等功能； 对顾客而言，主要包括查询个人订单查询、订单支付、订单取消等功能； 对供应商而言，主要包括供应商账单结算和账单查询，其中账单查询包括应收款明细查询、已结算账单明细查询。对于同时具备多重身份的人员登录系统时，需要进行身份选择，以分别进入不同的结算管理操作界面。结算管理子系统的数据流图如图34所示。 图34结算管理子系统数据流图 如图34所示，该子系统在识别用户身份之后，根据不同权限开放不同功能。工作人员可以通过该系统对已经结算的客户费用作收款记录，对已经结算承运人的运费作付款记录，并且实时查询客户的应收款、应付款情况。客户或工作人员可以通过该系统查询不同业务的计费标准以及该企业提供的业务种类。并且系统可以通过对每一笔业务成本和利润的核算，快速准确地完成费用结算，并通过资金流和信息流对账单进行有效的处理。 3.4.2企业情报管理子系统 该子系统可以实现商业数据存储、整理、分析等工作，具有很强的数据处理能力，是紧密联系商业市场发展、应用大数据技术进行数据工作的系统。企业情报管理子系统的数据流图如图35所示。 图35企业情报管理子系统数据流图 在图35中，企业情报管理子系统主要由三个部门协同构建——运营零售部、采购部、财务部。三个部门在日常运营中会产生大量的订单、报表等即时单据，这些单据在发挥商业效用的同时，副本被存储在企业数据库中。每一季度末，对将收货清单、采购清单和财务报表进行大数据分析，以历史数据为训练数据集、以上一季度数据为测试数据集，则可评估出上一季度的企业运行情况和问题，并以此支持商业决策。 3.4.3入库管理子系统 该子系统处理客户的各种收货指令及提供相应的查询服务，并保证生鲜类货物的冷链存储，主要功能有受理方式、订单类型、入库方式、货物品质检测、货物验收、库位分配、冷链存储等。入库管理子系统数据流图如图36所示。 (1) 受理方式： 直接受理、电话受理、传真受理、Email受理、网上受理等。 (2) 订单类型： 先入库，再配送处理； 先提货，再入库，再配送处理； 先提货，再入库处理。 (3) 入库方式： 一次性入库、分批入库。 (4) 货物品质检测： 货物名称、货物类型、货物品质要求等。 (5) 货物验收： 货主、货物名称、规格、货物等级、接收数量、破损数量、搁置数量、货物重量、货物体积、生产日期等。 (6) 收货单打印： 该功能是打印出收货单据。单据内容有： 收货日期、订单号、收货流水号、客户、客户通知编号、货物代码、货物名称、规格、单位、通知数量、接收数量、破损数量、搁置数量、生产日期、货物重量、货物体积等内容。 (7) 库位分配： 对要入库的货物进行库位分配，分配原则有两种——按货物分配库位和按库位分配货物。 (8) 库位清单打印： 根据预先安排的库位，打印出货物库位清单，以便保管员对号入库。 (9) 预入库确认： 当所有的货物已经入库后，按库位清单的实际入库数量进行入库确认。同时，把预入库类型由预定入库改成销售入库。 (10) 直接入库处理： 为了操作简便，根据实际情况，有些货物可经验收后不作库位分配，而直接进行入库处理。 (11) 冷链存储： 生鲜类货物名称、最佳存储温度、存储方式等。 图36入库管理子系统数据流图 在图36中，系统收到供应商的货物订单后，在产品记录里查找产品，仓库检测员根据收货检测单进行货物品质检测，确认合格，并对供应商进行信贷检查并更新记录，接单入库，否则拒绝并通知供应商。生成入库单交给门店管理员进行仓位处理，再生成仓位单，交给装卸工进行卸货搬运。对于搬运的货物，从运营零售部提取冷链存储信息进行冷链存储。之后门店管理员复核货物信息，接着进行货物的残损处理。最后进行库存处理，并同时在库存记录中更新货物信息。 3.4.4出库管理子系统 出货管理子系统是对货物的出库进行处理，主要包括出库类型、货物调配、拣货清单打印、拣货处理、预出库调整、预出库确认、直接出库处理、冷链包装、送货单打印。 (1) 出库类型： 根据出库目的的不同可分为销售出库、领用出库、抽样出库、调整出库、内拨出库、盘点出库、退货出库、调换出库、包装出库、报废出库。 (2) 货物调配： 根据发货通知单对货物进行调配处理，即从不同的仓库进行合理的拣货处理。根据处理方法可分为人工调配和自动调配两种。 (3) 拣货清单打印： 该功能是打印货物库位清单。根据清单用途，可分为外部拣货清单和内容拣货清单两种。 (4) 拣货处理： 该功能是把出库的货物从原库位拣货到拣货区，以便提高出库的工作效率。拣货条件可按出库日期、仓库、客户、货物等内容进行查询。 (5) 预出库调整： 把货物从存储区转移到拣货区时发生操作失误时，按先进先出原则把该货物退回存储区。 (6) 预出库确认： 当承运车辆来提货时，根据该车辆的货物配载情况，从拣货区出库，做出库处理。 (7) 直接出库处理： 针对某些客户的要求，为了操作上的简便，可根据实际情况对有些货物不经调配而直接进行出库处理。 (8) 冷链包装： 对货物进行冷链包装。 (9) 送货单打印： 该功能是根据不同客户打印出货物配送单。 出库管理子系统的数据流图如图37所示。 图37出库管理子系统的数据流图 在图37中，该子系统接收到订单，由管理货架的后台电子便签系统查询出对应的货物仓位信息，并将订单传送给门店管理员，门店管理员进行复核查询处理得出实际货物仓位单，拣货员根据冷链包装信息进行货物拣选打包，装卸完成之后，门店管理员进行仓库货物检查，整理出发货单、损坏过期单和仓库余货单、顾客余货单，并进行数据存储，便于下次查询。 3.4.5订单管理子系统 订单管理子系统是盒马鲜生日常销售的核心模块。它对每时每刻生成的订单进行及时处理和派发，以保证商品尤其是生鲜类商品能及时送到顾客手中，具有很强的及时性和数据处理能力。同时，它还会定期进行订单的分析处理，用数据支持门店经理进行经营决策和修改经营策略。 订单管理子系统主要分为5个模块，分别是①订单处理模块，主要负责处理系统工作期间随时生成的订单，核实库存； ②配送派发模块，主要负责及时将配送单派发给物流运输部，完成拣货与配送工作； ③票据模块，主要负责生成消费票据并存档，以规范和避免商业和法律问题； ④订单变更模块，主要负责更正可能出现错误记录的订单，保证企业数据库中历史商业数据的准确性； ⑤订单数据分析模块，主要负责定期进行历史数据分析，以便支持决策部门进行商业决策。 订单管理子系统数据流如图38所示，需要完成订单的收集、修改、查阅等基本操作，并将历史数据存档留证。此外，还需要完成流水单生成和发票的打印，以便发票能第一时间随商品送达给顾客。在决策阶段，订单管理子系统需要进行数据的初步分析，以帮助经理进行公司决策。 图38订单管理子系统数据流图 它通过对客户生成的订单进行全方位的跟踪来获取订单处理过程中的全部信息，用以保证第三方物流企业在服务过程中的效率和质量。 订单管理子系统主要分为六大子模块： 订单信息管理模块，包括对订单类型的分类、订单信息的录入、订单信息的修改等功能； 订单转换模块，主要负责订单向运单和交接单的转换； 订单查询模块，支持管理员通过订单号、客户、日期等信息对订单进行查询； 订单确认模块，对已完成的订单的数量、实际发收的数量等信息进行最终确认； 订单打印模块，按客户需求对各种订单采用不同的打印格式； 交接单管理模块，包括交接单的新增管理和紧急订单的处理两大功能。 3.4.6人力资源管理子系统 人力资源管理子系统从人力资源管理的角度出发，用集中的数据将几乎所有与人力资源相关的信息(包括组织规划、招聘管理、绩效管理、考勤管理、计时工资、计件工资等)统一管理起来。 人力资源管理模块涉及员工管理的大部分核心流程，其内容基本涵盖了管理业务的全部。目前，大多数第三方物流管理的人力资源管理模块下又分设了六大子模块，分别是人力资源规划、人员招聘分配、人员培训、社保管理、绩效考核管理、薪资管理。 (1) 人力资源规划主要包括企业组织结构的设置和调整、企业人事制度的制定以及人力资源管理费用的确定和执行。 (2) 人员招聘分配包括招聘需求的分析、招聘流程的制定、招聘考核的标准、招聘渠道的选择以及目标部门的分配。 (3) 人员培训主要包括培训需求调查、培训计划、培训实施情况、培训评价管理、培训资源管理、培训数据分部门管理等。 (4) 社保管理模块包括自定义各类保险福利类别、创建保险账户、离职员工退保、社保缴费自动核算、社保报表。 (5) 绩效考核管理包括绩效制度的制定、绩效考核的实施、绩效考核的评价以绩效考核的改进。 (6) 薪资管理包括薪酬分析、薪资核算、薪资汇总等。 如图39所示，人力资源系统主要涉及人事部、财务部、其他相关部门及应聘者。具体工作流程为： 人事部分析人才需求，审核通过后拟定招聘计划； 进行人力资源规划，审核通过后生成人力资源计划书； 根据应聘者投递的简历和招聘计划进行招聘，将合格者计入录取名单，并录入员工档案； 人员定岗后，签订劳动合同，记入档案； 制定考核规划，审核通过后生成考核计划书，依据此计划书进行考核； 同时，员工培训、员工考核、员工考勤结果生成反馈信息，反馈给相关部门及员工； 人事部依据劳动合同规定，进行薪资管理，生成员工工资表； 依据绩效规则实施绩效管理，生成绩效评估表，与工资信息一同录入员工档案； 最后，对员工进行社会保障，生成社会保障单。 图39人力资源管理子系统数据流图 3.4.7物流配送管理子系统 物流配送管理子系统是对顾客订单进行货物配送安排，物流配送管理员通过对订单、拣货员以及配送骑手的合理安排，为客户提供方便快捷的生鲜购物体验。主要包括顾客订单汇总、订单配送状态查询、配送骑手的调度、配送路线的选择、订单分配配送方案、货物物流跟踪反馈等功能，图310为物流配送管理子系统数据流图。 (1) 顾客订单汇总： 该子系统通过从订单管理子系统中获取顾客订单的信息，按照先后顺序及送往地区分类汇总整理，以便为订单安排骑手进行配送。 (2) 订单配送状态查询： 物流配送管理员通过登录系统，统计顾客订单，实时查询订单配送状态，如正在配送、等待配送、完成配送等。 (3) 配送骑手具体信息查询： 骑手的具体信息包括骑手配送的货物、路线以及往返时间等。 (4) 配送路线规划： 根据客户订单及所在地区进行分类，在同一时间段内优先路程较远的订单进行配送，对骑手路线规划能够有效地利用时间，高效完成配送。 (5) 订单分配配送方案： 根据骑手信息、顾客下单以及路线规划情况，系统根据整体最优原则自动生成订单分配配送方案。 (6) 货物物流跟踪反馈： 在骑手进行订单配送时，系统会实时记录货物配送进度，运营零售部将这些信息实时反馈给客户，并且订单送达时，需要顾客进行订单确认，一次配送才算完成。 图310物流配送管理子系统数据流图 在图310中，用户下单和配送骑手接单信息都会提交到配送中心，通过业务受理进行订单汇总、订单分配以及货物跟踪，同时将这些信息提交给运营零售部，运营零售部将这些方案分别反馈给相应的用户和供应商。 3.4.8信息维护子系统 信息维护子系统其主要职能是对系统进行运作管理和维护管理。由于系统设计线上订购与线下配送，在此过程中会产生大量数据，可以通过数据挖掘分析等技术对收集的数据进行数据分析、概括，为客户提供有效的信息反馈。图311为信息维护子系统数据流图。 图311信息维护子系统数据流图 1. 系统运作管理  管理员管理 管理员管理主要是对系统管理员进行信息管理，管理员可以修改自己的密码，并且将管理员按级别来分，可分为全面管理(获得系统全面管理权限)和部分管理(仅对系统有部分管理权限)两种，分别给予两类管理员不同的管理权限。  信息反馈 系统可以接受客户的指令，自动进行数据挖掘，为对应的客户提供信息反馈。 2. 系统维护管理  每日数据备份 数据备份是为了避免因系统数据损坏而导致系统瘫痪。所以每天都要做好数据备份。  每年数据备份 为了保持系统运行速度，在年度转换时，要对系统数据进行年度数据备份以及该年数据转结。  数据恢复 当系统数据损坏后，在毫无办法用其他工具对数据进行修复时，用数据恢复功能。 在图311中，信息维护子系统主要功能为数据备份、数据挖掘和故障恢复。维护人员进入登录界面，修改密码后，存入管理员数据库。 (1) 在数据备份方面，定期将数据报表提交给系统，系统信息分类后对数据进行存储，存入系统数据库。 (2) 在数据挖掘方面，维护人员可根据客户需求进行需求评定，生成需求表，按要求进行数据挖掘后，生成反馈表提交给特定顾客。同时，也可以依据筛选要求进行信息筛选，在备份数据库中存档。 (3) 在故障恢复方面，查询故障原因，通过备份数据库进行数据恢复。 3.4.9组织结构简介 该第三方物流公司有总经理一人，副总经理三人，分管行政后勤部、财务部、人事部，仓储管理部、市场部、技术部，运输部、服务部、运营部，共计九大职能部门。 其中，技术部主要负责对盒马鲜生管理信息系统的设计、运营、维护和优化，下设四大中心： ①仓储管理中心，主要负责出入库系统、货物信息管理和冷链存储等一系列与物流运输中的仓储管理环节有关的功能开发，以及运营中的信息实时更新和传递，主要负责协助仓储管理部的工作； ②物流管理中心，主要负责车队管理系统和路线规划系统的开发，建立决策系统为配送自动优化选择适合的车队和最优的路线，与运输部实时交流，保障货物运输； ③运营管理中心，主要负责企业情报管理系统、结算系统、人力资源管理系统、订单管理系统的开发以及开发后的运营管理，对企业数据资源以及人力资源进行管理，对订单实时管理并对完成的订单进行结算以及客户的后续服务，主要负责协助财务部、人事部、运营部、服务部等部门工作； ④系统管理中心，主要负责整个系统在运转过程中的信息反馈和系统维护，主要职能为在系统运行过程中查找系统漏洞并修复，及时更新优化系统功能，保证系统可以正常且高效地服务广大的用户。图312描述了系统组织结构图。 图312盒马鲜生信息管理系统的组织结构图 3.4.10系统WBS 根据上述各子系统的业务流程分析和数据流图，结合该系统所应有的背景和专业知识背景，对本项目的需求规格进行分析，采用图表方式进行任务分解，其分解结果如图313所示(图中F2~F7采用标准重用技术，分解方式与F1和F8相同)，它是按照系统模块标准进行的入库管理子系统和出库管理子系统部分的任务分解，其中没有包括质量、功能等相关的任务，WBS可以随着系统的完善而不断增加和完善。 图313盒马鲜生信息管理系统工作分解结构 3.5本章小结 本章介绍了项目管理计划、项目管理范围和项目需求，在此基础上着重介绍了软件项目需求管理以及任务分解的过程。需求管理过程包括需求获取、需求分析、需求验证、需求变更。项目干系人首先应该通过访谈等方式与用户进行深入的需求交流，并形成一个可以作为开发图纸的软件需求规格。同时，本章重点讲述了软件项目的分解技术，在了解软件项目所在企业背景和专业知识下，分析项目的业务流程和数据流图，通过任务分解技术，将项目分解成很多更小、更方便管理和操作的子项目，使项目更加容易管理和进行。任务分解可以采用清单或者图表的形式，分解时采用的标准应该统一。通过任务分解可以界定项目总范围，并将软件需求规格说明书(SRS)和工作分解结构(WBS)作为主要提交文档。 习题三 1. 选择题 (1) 项目范围()。 A. 在项目执行阶段通过变更控制步骤进行处理的问题 B. 从项目概念阶段到收尾阶段都应该加以管理和控制 C. 在授权项目的合同或其他文件得到批准后就不再重要 D. 只在项目开始时很重要 (2) 下面哪一项不是WBS重要性的体现？（） A. 防止遗漏工作B. 帮助组织工作 C. 为项目估算提供依据D. 确定团队成员责任 (3) 范围变更是指()。 A. 对批准后的WBS进行修改B. 对范围陈述进行修订 C. 修改技术规格D. 修改需求规格说明文档 (4) 需求管理是说明系统必须()的问题。 A. 怎么做B. 做什么 C. 何时做D. 谁来做 (5) 下列哪一项不是需求管理的内容？() A. 需求变更B. 需求获取 C. 需求设计D. 需求验证 (6) 任务分解可以()，它是范围变更的一项重要输入。 A. 提供项目成本估算结果B. 提供项目范围基线 C. 规定项目采用的过程D. 提供项目的关键路径 2. 判断题 (1) 需求分析过程是确定项目如何实现的过程，并确定项目采用的技术方案。 () (2) 对于以前没有做过的项目，在开发WBS时，可以采用自底向上的方法。() (3) 在需求获取过程中，项目干系人不需要与客户进行访谈等交流，只需召开需求专题讨论会。() (4) 为了提高软件项目成本、时间和资源的准确性，需要将软件项目拆分成很多更小、更易管理、更易操作的子项目。() (5) 范围计划主要是对项目的范围进行分析，得出范围说明，提交的文档主要是需求规格说明书(项目范围说明书)以及WBS。() 3. 名词解释 项目计划； 项目范围； 项目管理范围； 软件项目需求； WBS。