20221114汽轮行业MES整体解决方案

项目管理方法7.1上海XXX科技项目管理方法论7.1.1上海XXX科技采用微软项目管理方法MSF在本项目的实施过程中将采用微软提出的微软解决方法体系（MSF，MicrosoftSolutionsFrameworks），简称MSF。MSF是一套大型系统开发指南，用于指导企业如何管理项目中每一阶段的开发和实现的步骤。微软的顾问咨询机构采用了这种管理方案，把MSF的项目管理方式应用到为客户设计、构建和实现商业应用的顾问咨询服务中。采用MSF的项目管理模式，能够使工作流程更加有效，提高快速反应和决策能力；开发者和用户的交流更加紧密；能更高效的使用客户/服务器结构来支持企业日益增长的商业运作等。此外，MSF是建立在软件开发的工业化的基础上，从而能更加切合软件开发的基本原理，减少开发过程中出现的问题。这些都是传统软件开发模式无法解决的问题。而在MSF中，实现客户的商业目的是整个MFS管理的核心，整个开发过程都围绕这一目标去展开和细化。MSF是一项实践性非常强的复杂的管理过程，是一种观念的传播。具有决策或是可以影响决策的人士接受了这样的观念，MSF就有实施的可能，整个项目才可能进一步得益于MSF。MSF的核心有八个基础原理：推动开放式沟通为共同的前景而工作赋予小组成员权力建立清晰的责任和共同的职责关注交付业务价值保持灵巧，预测变化质量投资学习所有的经验这些原理共同传达了MSF观点，构成了一种统一方法的基础，这一方法用来组织项目所需的人员和过程，以便交付技术解决方案。它们是MSF结构和应用的基础。尽管每个原理都已经显示出了自身的优势，但是它们很多都是相互依存的，因为其中任何一个的应用都对另一个的成功起到了支持作用。在依次应用的时候，它们建立了一个稳固的基础，使得MSF能够很好地适用于规模、复杂程度和类型都不相同的多种项目。MSF过程模型每个项目都要经过一个生命周期，这是一个包含项目里所有活动的过程，而这些活动的发生要到项目结束并过渡到操作状态才会结束。生命周期模型的主要功能是建立活动进行的顺序。正确的生命周期模型能够简化项目，并帮助确保每一个步骤都会让项目更加接近成功。下面是MSF过程模型生命周期的一个简图：MSF过程模型MSF过程模型把来自传统的瀑布模型和迭代模型的概念结合起来，并利用了两者各自的长处。过程模型把瀑布模型基于里程碑的规划的优势与迭代模型不断增加的反复项目交付内容的长处结合了起来。MSF过程模型以阶段和里程碑为基础。在一个层次上，阶段能够被简单地看作是一段时间，只不过强调了为该阶段生产相关交付内容的特定活动。但是，MSF阶段要比这复杂；每个阶段都有其自身的特色，每个阶段的结束都代表了项目进展和中心点的变化。阶段可以被先后看作是探索的、调查的、创造性的、专心的和合乎规范的。里程碑是检查和同步点，用来确定阶段的目标是否已经实现。里程碑为小组提供了明确的机会，以调整项目的范围，反映客户或者业务要求的变化，并解决项目过程中可能会出现的实际风险和问题。此外，里程碑是每个阶段的结束，它让指导很多活动的职责进行转化，并鼓励小组以新的视角来看待下一阶段的目标。结束由小组在每个阶段生产的实际交付内容来说明，还有小组和客户对这些交付内容的评价意见来说明。这个结束，以及相关的结果，将成为下一阶段的起始点。MSF过程模型允许小组响应客户的请求，并在需要的事后在解决方案的中途作出变化。它还允许小组交付解决方案的关键部分，这要比以往的做法更快，因为它首先集中交付优先权最高的特性，然后转到不太重要的特性上，直到最终发布。过程模型是MSF的一个灵活组件，MSF已经被用来成功地改善项目控制、将风险最小化、提高产品质量，以及加快开发速度。MSF过程模型的五个阶段让其足以灵活地应付任何技术项目，无论是应用程序开发、基础结构部署，还是这两者的结合。MFS这种以目标为管理核心的模式能建立良好的项目队伍，使各自发挥所长、各尽其责，以里程碑方式驱动整个项目的滚动前进。在实施中注重项目各阶段的结果，在项目管理过程中及时地进行风险评估和控制，能大量地缩短项目的开发周期，已经在实践中被证明是一种快速开发的方法。MSF组队模型MSF组队模型定义了小组同级成员的一些角色和职责，这些成员都在以相互依存的跨学科角色进行信息技术项目工作。下面的图表对该模型的逻辑进行了描述：MSF组队模型MSF组队模型基于这样一种前提，即任何技术项目都必须达到特定的关键质量目标才能够被认为是成功的项目。达到每个目标都需要相关的、不同技能及知识领域的应用，它们每一个都包括在一个小组角色群（通常被简称为角色）里。相关的技能和知识领域被叫做基础领域，它们定义了每个角色的域。例如，程序管理角色群包括项目管理、解决方案体系结构、过程保证和管理服务等职能领域。总体来说，这些角色都具有这样的广度来满足项目成功的所有标准；如何任何一个角色无法实现其目标，这都会将危及整个项目。因此，这个同级小组里的每个角色都被认为是同等重要的，重要的决定都要共同作出。相关的目标和角色见下面的表格：关键质量目标MSF小组角色群在项目约束内的交付程序管理对产品规范的交付开发解决所有问题之后的发布测试顺利的部署和前进中的管理发布管理增强的用户表现用于体验满意的客户产品管理MSF组队模型是行业里用于被赋予权力的小组工作和技术项目的最佳做法的汇编，它把重点放在了取得这些目标上。它们然后被应用到MSF过程模型里，以概括活动并创建小组所要生产的具体交付内容。这些主要的质量目标会定义和推动小组进行工作。要注意的是，一个角色不同于一个个人—多个人员可以担当一个角色，或者一个个人可担当多个角色—例如，在模型需要缩小规模以适应小型项目的时候。在采用MSF小组模型上重要的一点是，所有的质量目标都应该在小组里体现出来，而且项目的各种利益相关人都应该知道项目里的哪个人在负责质量目标。MSF组队模型解释了这些角色的组合能够如何被用来扩大规模以便利用大量的人员来支持大型的项目，即通过定义两种类型的子小组：职能小组和特性小组。职能小组是由职能角色组织起来的单领域子小组。开发角色常常有一个或者多个职能小组来承担。第二种类型是特性小组，它们是跨专业的子小组，把主要精力放在构建解决方案的特定特性或者能力上。MSF组队模型可能是MSF里最与众不同的部分。组队模型的核心是，技术项目必须符合各种利益相关人完全不同的，且常常并列的质量观点，这包括操作、业务和用户。MSF小组模型推动了各种观点的这种融合，因此承认技术项目不单单就是IT的工作。MSF风险管理技术项目由组织来承担，以支持其在新业务和技术领地的风险投资，并期望其投资能够获得回报。风险管理是对技术项目里固有的不确定性的响应，固有的不确定性意味着不可避免的风险。但是，这并不意味着就是要去承认和管理风险就一定会阻碍对机遇的创造性追求。虽然很多技术项目都没有能够有效地管理风险，或者没有考虑到项目的成功交付需要风险管理，但是MSF就使用了风险管理来实现项目的成功。MSF把风险管理看作是MSF规范中的一个，它需要被集成到项目生命周期里，并被包含在每个角色的工作里。基于风险的决策是MSF的基础。通过给风险排序和制定优先顺序，MSF会确保风险管理过程是有效的，而不是一个累赘。预见性的风险管理意味着项目小组有一个确定的和可见的过程来管理风险。这个项目小组对可能出错的东西进行一个初步的评估，确定必须处理的风险，然后实现风险管理的策略（行动计划）。评估活动是在整个项目过程中持续进行的，是所有阶段里进行决策信息来源。被确认的风险（及其行动计划的进展）会被跟踪，直到它们被解决或者变成问题再处理。下面图表就是预见性的风险管理过程。MSF风险管理这个由六个步骤组成的风险管理过程通过对角色职责的定义与小组模型集成在一起，通过指定的行动和里程碑交付内容与过程模型集成在一起，这就创造了一种进行项目风险管理的综合方法。这个过程最终以学习这一步结束—项目风险的捕捉与保留、减轻策略和可能性策略，以及未来检查和分析所需要的已完成的行动。这一与风险相关的信息知识仓库是创建学习型组织必不可少的一部分，它能够利用以往的项目知识，并以其为基础。利用MSF进行风险管理的方法与众不同的地方在于，测量成功与否的标准是做了什么，而不是填了什么表格。在很多项目里，风险管理是付费的口头服务，它不是被完全忽略了（也许就在一开始草率的风险评估之后），就是被当作了官僚作风。MSF会避免过于繁重的过程，但是把风险管理放在了项目决策的核心。质量管理在MSF项目实施小组中，所有成员都感到要对产品的质量负责。产品质量责任不能由一个小组成员委托给另一个小组成员或部门。同样，每个小组成员都要作为客户的拥护者，在整个开发周期中考虑最终产品的可用性。测试管理组将对整个产品的质量负责。目标是只有当所有的产品质量问题被识别出来并被处理后，才可以批准发布。所有被交付的产品都是有缺点的，关键的目的是在发布产品之前，确保那些缺陷被识别出来并被处理。交付一个缺陷已知且被处理的有解决解决方案的产品，比起交付一个有着未被识别的缺陷的产品要好得多。测试管理组会从如下方面开展工作：测试规划：测试规划致力于使小组知道如何确保所有的产品质量问题被识别且处理。确定测试方法和计划，并为小组测试解决方案之策略描绘轮廓。这些规划包括具体类型的测试、具体测试区域、测试成功标准、和资源（硬件和人员都是）中需要测试的信息。测试规划职能领域的一个重要部分就是通过为项目小组的质量控制方法和规则提供输入，参与设置质量规则，以确保解决方案的成功。测试工程：致力于完成测试规划中定义的行为，这是确保所有产品质量问题被识别出来且被处理所必须的。测试工程的责任是：开发和维护测试案例的具体职责；开发工具、脚本、以及文档来执行测试功能；进行日常构建的管理，以确保测试规程能以单个参考标准执行和报告；还有管理测试以准确确定产品开发的状态——同当前的构建一起，通过运行测试案例、工具、和脚本来识别问题。跟踪和报告：致力于清晰的向项目小组表达解决方案中普遍错误的和普遍正确的是什么，从而使开发状态能被精确的描绘出来。问题跟踪的执行是为了确保所有被识别出来的问题在发行之前已经被解决。问题状态文档包括了分配、优先级、决定、和解决，它们全部都频繁的向小组提供与当前产品质量状态和详细趋势分析有关的数据。7.1.2微软系统运维方法MOF系统运营与维护作为完整的IT生命周期的一部分，系统运行和维护的生命周期中需要保障系统的高可用性、性能、安全性、可伸缩性等等。而系统管理的科学性日益成为维护系统成功平稳运行的重要因素。微软公司在自身IT系统运行与开发的过程中总结开发出了一套保障系统运营与维护的一套方法学，称为微软运行框架(MicrosoftOperationFramework，即MOF)。移动统一信息平台项目中，微软企业技术支持服务将与移动一道，在MOF框架下进行运行维护工作。MOF是一个衡量、管理和改善IT运行的框架，可以专门地用于微软环境。它基于ITIL，使用ITIL通用的语言和结构。因此它特别可以专门用于微软的环境。我们想通过ITIL提供高级别的认识，也提供了细节的、底层的信息使客户可以在可管理的环境中使用微软产品。随着时间的推移，将越来越专门性，使微软的产品与操作架构捆绑起来。MOF的目标在于：强调微软平台上的规程、组织、技术操作的规范化减少消耗时间和复杂性扩展微软产品的运行知识的可访问性推动微软和合作伙伴的服务承诺MOF由三个模型构成：规程模型，团队模型，风险模型。以下分别进行介绍。规程模型这里是规程模型的笼廓。规程模型是一个生命周期。这些规程在运行环境中随时进行。多个规程在同一时间同时进行。它们都运行在生命周期中。生命周期有四个阶段，更改阶段、运行阶段、支持阶段和优化阶段，与四个阶段对应，存在四个审核。审核模型两个审核是基于事件的。发布准备就绪审核是基于事件的审核。当购买了新的产品或开发团队提交了一个新的产品，需要进行审核决定是否已经准备好在运行环境中部署。可以操作它吗？有能力做吗？能支持吗？因此它是一个基于事件的审核。之后，进入更改阶段，开始实施新产品。在运行环境中完成实施后，需要完成实施审核。依然是基于事件的审核，察看每件完成好的事情和每件错误的事情，然后进行改善。记录下所有步骤，在下次实施其它项目时重复这一步骤。运行阶段。这是每日的运行操作，如打印报告、改变口令等这些小事情。由于没有事件激发审核，因此是基于时间的审核。必须设置时间表来对企业有影响的操作进行审核。目标是简单地审核所有的每日操作。再一次，检查做得好的事情和做错的事情，记录下好的方法，对不好的方法寻找途径改善，避免未来的问题。现在进入支持阶段，它与运行阶段紧密相连、同时发生。包括支持人员和管理员更正问题等这些操作。没有事件触发审核，因此审核是基于时间的。周期性的，你需要审核支持阶段和SLA–服务级别承诺。审核在哪里符合或没有符合组织的服务等级承诺，每件事的审核都要基于是否符合SLA。什么帮助我们达到了SLA的要求，什么事情导致没有完成服务等级承诺，如何在将来改善？下一个阶段是优化阶段。这是对自身的审核。优化阶段的工作时改善整个生命周期。审核发生在不同的时间点，审核整个生命周期，确定所有事情工作高效，发挥出最大的能力。团队模型团队模型是MOF三个模型中的一个，它用最为实用的角色群来构成运行团队。它完全独立于人事系统的职称，因此，不需要通过人事系统改变很多。也不必要担心改变职称和职称重要性引起的人员心理伤害。它是一整套角色，有很好的定义，以文字表示。也许会有人同时担任很多角色。通过文字标注和定义可以很容易地管理人员。我们记录下关键活动和每个角色间的竞争。我们对角色组合给出指南。角色组合的意思是有些角色可以有很多人担任，而有些人会担任很多角色的情况。一些角色可以很方便的合并，而另外一些则有风险。我们将就此给出指南。一件非常好的事情是书面记录角色间的沟通信息。有文档告诉我们关于不同角色之间需要什么样的沟通。因此，当某人被指派某个角色时，他知道需要与谁沟通、需要什么沟通，从而顺利完成任务。这也允许经理根据沟通信息来管理人员。如果沟通被中断，我们知道在哪里中断、是否重要，然后采取方法去改善。风险模型业务交易越来越依赖于IT。我们为业务运行提供各种各样的工具，突然之间，业务越来越依赖这些工具。因此，一旦IT服务消失了，业务就会受到损害。IT的环境越来越复杂、IT对基础架构的控制力越来越小、IT失败的外部可见性越来越强、恢复系统的时间要求越来越短。IT通过各种各样的方法另业务正常进行，也会有新的方法令业务停顿。因此三四年前，我们做错的事无关紧要，但今天，将对业务有巨大影响。所有这些因素，使得在IT运行的过程中面临着比以往更多的风险，所以需要对风险进行有效的管理。以下是风险管理过程：五步风险管理是一个生命周期过程，该过程中包括：区分风险，生成风险描述，将它们记录下来；对风险进行分析，它们可能如何发生？它们可以带来什么样的业务影响？对延续进行计划。如果发生了，我们应该如何去做？跟踪风险，风险随着时间在变化。有可能恶化，也可能变好，也可能消失了。需要对风险进行控制。如果风险消失，需要将它取消。不是将它删除或忘记它，而是将它放入数据库作为过期的风险。围绕它的所有规程和过程均被保留。在某个点上它可能重新回来成为业务的一部分，这时我们可以重新将它激活。手边保留所有文档可以保证不总是从头开始。经常的对过期的风险进行评估，确定它们是否依旧过期，依旧不是环境的一部分。对此过程的持续进行是一个活动的风险评估文档，计划每个过程。书面记录基于专业的风险管理，可以告诉你什么是最重要的风险，只要有可能发生对业务产生影响。需要对格式进行组织，告诉你什么是你最担心的。那里你会投入有限的资源减少风险，需要有一个计划应对情况恶化，告诉我们需要如何去做。任何过程都会有风险，由于最终会有一个会恶化，如果没有计划，没有人知道如何去做，业务会受到影响。7.2具体项目管理方法遵循MSF和MOF方法论的指导，结合XXXMES项目我们将制定如下的项目管理方法，并在项目计划阶段进行完善。7.2.1项目质量管理在XXXMES项目的整个开发、实施过程中，我们需要规定各种必要的质量保证措施，以保证所交付的项目成果能够满足项目委托书或合同中规定的各种需求，能够满足经XXX评审的该项目需求规格说明书中规定的各种具体需求。组织机构与职责我们将设立如下的虚拟项目组织架构，由XXX和上海XXX科技人员组成，并规定各自的职责。角色与职责角色角色成员职责项目指导委员会XXX:上海XXX科技:确定项目质量目标，审核项目过程及结果质量，批准过程改进建议项目经理XXX:上海XXX科技:项目实施及进度控制、质量管理；项目组成员XXX:上海XXX科技:产品实现、遵守软件质量保证与配置管理等规范质量保证人员XXX:上海XXX科技:软件质量保证，并监管软件配置管理评审内容我们将制定以下的项目责任矩阵来评审项目交付物。项目阶段交付物名称审阅方式责任人内部审阅人员交付物负责人外部审阅人员交付物签收人员计划需求分析架构设计开发测试上线部署日常项目管理评审流程我们将制定以下的评审流程来评审项目交付物。问题的报告和纠正操作质量保证人员对应公司的软件质量规范，根据项目计划和质量保证计划跟踪软件项目进度及参与各阶段评审和负责评审问题的汇报、跟踪，把评审中发现的问题反馈给相关责任人，相关责任人（项目经理协助）评估此问题，提出解决意见（包含解决人、解决方式、解决时间），若确实不解决，给出不解决的理由。7.2.2项目风险管理我们对此次项目的风险进行了仔细的研究并提出了相应的风险管理方法，如下：总体风险因素风险分类风险内容风险影响微软解决方案人员风险人员流动风险长期出差容易产生人员流动，因项目较复杂，新人上手需要相当多的时间，会带来知识流失,对项目产生不利影响1.通过KT的形式增加全体项目组成员对系统的认识，尽量避免人员流失带来的知识流失2.改进项目管理方式，在项目过程采取结队方式，保证所有的模块都有backup的人3.建议客户分阶段不同开发模式，有些开发可以采取local开发模式，降低出差带来的影响。业务风险上海XXX科技在MES行业经验的不足对项目的实施带来一定风险影响项目的进度和系统的可用性组建业务需求分析团队，聘请有相关行业经验的专家参与需求调研对业务的复杂性进行细分，并制定好详细的需求调研的计划制定需求分析方案，从大流程到TO-BE流程逐层的细化内部Review和互相学习分享的方式来增强业务分析队伍的业务素质通过客户Review的方式提高需求调研效果通过文档体系保证业务知识的沉淀通过Demo的方式完成需求原型，通过用户的体验来确认需求系统风险MES是制造业非常复杂的核心系统，自主开发产品的稳定性是潜在的风险对系统的稳定性带来不利影响，严重则导致项目失败以风险管理为核心的项目管理方法，制定系统和业务的应急方案需求、设计和测试一体化和一致化确保了系统的质量和稳定良好的架构确保了系统的稳定和可扩展性专业测试队伍和制造业测试方法确保了系统的质量充分的架构Review和论证确保了系统的稳定性微软全球技术中心是系统按时按质完成的强大后盾项目过程风险控制：项目阶段风险内容风险影响微软解决方案项目启动前认识上的风险，没有对项目足够的风险认识是最大的风险影响项目过程中的风险控制要主观上足够的认识，并且提前识别和制定风险对策计划阶段项目计划阶段由于需求等不够明确导致对Effort估算的失误1.人力资源不足2.造成项目无法按时按质完成制定详细的项目计划，根据计划估算工作量并申请相应的资源需求分析阶段用户的需求是无止境的，对需求控制存在一定风险影响项目的进度和质量对需求进行详细分析，并按照项目范围进行归类划分，并分阶段实现设计阶段系统架构设计缺乏足够的评审系统有可能出现以下等问题：扩展性不够稳定性不够高复杂度影响开发效率定义系统架构的功能和非功能标准对架构进行团队内部、IT部门和微软权威部门（CTC）Review开发阶段项目的时间、开发人员技术水平等会影响代码质量1.影响项目的进度2.导致系统无法正常运行3.对系统性能致命影响1.定义代码编写规范2.开发人员参与技术培训3.定期对代码进行CodeReview4.应用代码分析工具对代码进行分析并改进测试阶段测试覆盖率无法达到100%系统质量无法得到保障按照业务流程和逻辑设计流程设计正常案例和反常案例跟业务部门和IT部门Review测试案例有计划的执行测试案例并在执行中不断完善案例实施阶段系统的复杂性和多接口等特点决定系统实施存在风险系统上线失败制定详细的上线计划各个系统做好联通测试跟业务部门和IT做好应急方案，一旦失败做好回滚并实行应急操作数据准备及录入风险，数据的整理实施人员的责任心有很高的要求，如果责任心不强或心态不正确，会极大地降低数据的正确率。

导致系统无法正常运行制定方便可用性高的数据整理模板通过技术手段对数据进行校验和排错做好数据的验证方案运维阶段一线运维无法定位系统的问题解决问题的效率低，导致停线时间长形成日志辞典，便于问题和解决方案的定位清晰完整的运维手册系统的复杂性增加了二线运维人员对代码理解和扩展的难度无法及时的修复系统问题或者自主开发完成需求变更开发清晰详细的设计文档足够多的代码注释系统开发过程同时对二线运维人员的技术培训运维人员尽早的加入项目团队，从需求到开发都全程参与系统升级阶段系统升级存在一定风险系统升级失败，导致生产停线系统必须先经过回归测试制定详细的升级策略和步骤按照升级步骤在模拟环境进行演练利用技术（比如智能升级）对系统进行升级做好系统回滚方案7.2.3项目时间进度管理XXXMES项目任务繁重，时间紧迫。怎样有效的管理时间进度也是一个很重要的任务。我们认为应该在以下几方面给予重视，以保证进度管理的效用：进行充分的需求调研在项目中一个经常碰到的问题是，前期需求调研不够充分，导致在后期项目实施的过程中，冒出大量的新需求，影响项目的进度。项目调研一定要抓住企业的核心业务流程，对于重点、难点流程不能漏过一个，因为其处理要么比较复杂，要么关系到其他多个业务，若在后期实施阶段，再去考虑的话，则很可能前期的工作都要白费。甲乙双方的有效沟通在项目的进行过程中，需要建立起一个机制，保证甲乙双方的沟通协调，确保进度的一致性；在需要赶工和资源调配时能够做到及时高效。关注薄弱环节，实现动态平衡项目的进度管理并不是一个静态的过程，项目的实施与项目的计划也是互动的，在项目进度的管理过程中，需要不断调度、协调，保证项目的均衡发展，实现项目整体的动态平衡。进度管理是一门艺术。在资源供应方面，按照资源供应计划，即时组织资源的供应工作，保证项目最需要资源支持的环节能及时得到资源。项目的关键路径始终是项目负责人最为关心的，但随着项目的实施，关键路径可能会由于一些情形而发生变化，项目的延迟可能导致原来不在关键路径上的任务成为关键路径的必经之路，因此，项目成员需要随时关注项目进展，跟踪项目的最新计划，确保即时关键路径上任务的进度。明确每个成员的责任在项目中要定任务、定人员、定目标，进一步明确责任，确保关键任务的进度。从普遍意义上说，应当根据项目的特点，建立项目组织的各种责任制度，做到责权利一体化。克服不稳定因素因为此次项目涉及范围比较广，项目周期比较长。在这中间，可能会出现一些人为控制因素。如项目组成员的流失、项目成员的变动等。这些因素都会影响项目的进度。对于这些因素，我们需要尽量的防范，作一些后备。如在条件允许的情况下，扩大项目组的成员，或者采取一些激励措施，以保证实施团队的稳定，等等。7.2.4项目变更管理变化并不是人们最害怕的，最怕的是跟不上变化的步伐。同样，在项目开发过程中需求的变更会给开发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，项目开发的进度、成本和质量也就有了安全的基础。需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新技术通常会改变他们的工作方式;或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目进度拖延、成本不足、人力紧缺，甚至导致整个项目失败。我们实施需求变更管理将会遵循如下原则：建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。需求变更后，受影响的项目计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。妥善保存变更产生的相关文档。7.2.5项目开发代码管理代码的管理主要从三方面进行管理，一个是代码规范，一个是架构清晰化，最后是配置管理规范。1）代码命名和书写规范项目开始必须做出代码规范文档，在开发人员入场或者新员工入职，必须对其进行代码规范的培训，并定期对代码进行CodeReview，看是否有遵守规范。

2）系统框架要足够清晰，容易进行维护系统架构要清晰，多层的架构便于代码的理解和团队的分工。在开始编码前，所有人都要参与架构的Review，并写出第一个功能模块，供架构师Review。只有Review通过后编码人员才能开始系统开发编码。3）配置管理规范应用TFS来作为代码管理和版本控制工具，所有人员都必须通过配置管理的培训，配置管理只是一种代码管理的工具，正确使用才是关键。要养成好的习惯，如，每次修改文件之前要先更新代码，提交代码时要对修改的内容做一个明确的说明，以方便其他开发人员查看。7.2.6项目人力资源管理项目是由人来完成的。此次MES项目由于项目规模相对较大，涉及项目人员很多，我们需要仔细考虑、加强项目人力资源管理。团队成员组成项目成员按角色分为：项目经理-负责整体项目管理，系统开发技术咨询和关键代码审核，项目实施管理系统架构师-负责系统架构设计，关键技术点咨询和指导，系统架构审核需求分析师-负责项目整体需求的收集，分析。程序开发人员-负责系统实际开发，代码编写，项目实施和技术维护。系统测试人员-负责系统测试案例编写及执行，提供产品质量保证。需要在项目初期就挑选出合适的人员担任不同的项目角色。明确项目职责、成员的职责，介绍项目的背景和项目要求，确定项目的目标，通过动员会鼓舞并增强项目成员完成项目的信心。为支持项目经理营造一个良好环境和氛围，避免团队不协调、不团结、项目成员对项目经理工作不支持、不配合的局面出现，杜绝个人英雄主义，特别强调并赋予项目经理的权力此外我们还需要项目委员会的指导，支持团队对项目对项目的支持，以及QA团队对项目的保障。拟定的项目组织架构图如下：团队建设团队组建完成并不等于团队建设的完成，团队建设是伴随项目团队的整个生命周期的活动。团队建设活动包括为提高团队运作水平而进行的管理和采用的措施。例如：在项目制定计划过程中由非管理层的团队成员参加，建立一套用于发现和处理冲突的基本准则；明确项目团队的方向、目标和任务，同时为每个人明确其职责和角色；邀请团队成员积极参与解决问题和做出决策；积极放权，使成员进行自我管理和自我激励；设立WarRoom以增进相互之间的交流。正确处理人员离任大型项目的一个突出特点就是工作需要多种角色人员共同努力才能完成，为减少由于某个技术高手的突然离开给项目带来的负面影响，必须采取必要的措施，确保项目阶段成果的及时沉淀。做到项目成员对项目都有一个比较好的了解，不仅要文档齐全、规范、有效，而且项目成员对相互工作有一个了解。软件项目最难以控制的是代码质量，代码是软件产品的核心，也是容易出问题的地方。所以，我们需要整个项目启动时就规范代码的要求，并形成正式的规范标准，对代码的规范、注释提出具体的标准，不仅提高了代码易读性，也便于程序员离开时工作的交接。建立沟通机制要做到大型项目的人力资源管理，必须建立良好的沟通渠道和机制，通过沟通才能了解项目成员的想法，消除理解偏差，达成共识。我们在项目的开发实施过程中，需要多种沟通方式：会议、文件、电子。7.2.7项目沟通管理对于项目来说，要科学地组织、指挥、协调和控制项目的实施过程，就必须进行信息沟通。沟通对项目的影响往往是潜移默化的，所以，在成功的项目中人们往往感受不到沟通所起的重要作用，在失败项目的痛苦反思中，却最能看出沟通不畅的危害。没有良好的信息沟通，对项目的发展和人际关系的改善，都会存在着制约作用。沟通失败是IT项目求生路上最大的拦路虎。除了加强项目组成员的沟通技巧外，我们还需要制定沟通计划。沟通计划的主旨是在项目实施过程中将正确的信息在适当的时间传递给合适的对象。项目工作组之间的联系人如下：沟通范围联系人在项目工作小组之间小组负责人是主要联系人项目经理是上一级联系人公司与公司之间项目经理是主要联系人项目指导委员会是上一级联系人项目日常沟通会议及报告计划如下：7.2.8项目测试方法MES项目的测试包括功能测试、集成测试、性能测试和用户测试功能测试流程功能测试案例设计原则根据界面测试标准文档对每个界面功能设计正常，异常的测试用例依据：界面测试标准文档根据需求文档和设计文档编写模块功能的测试用例依据：需求设计文档每个测试用例必须包含相应的输入，输出和预期结果集成测试流程集成测试案例设计原则根据定义的子流程设计测试用例依据：TestFlow流程图根据上下游系统接口说明设计接口部分测试用例依据：接口定义列表整理场景日志对照表，根据对照表设计用例依据：日志对照表数据关联性测试依据：数据关联字典监控程序贯穿于整个测试过程自下而上的集成测试方案所有的测试流程都对应于业务流程所有的测试流程都有对应的测试案例测试案例分正常案例和异常案例接口和监控将贯穿于测试过程中性能测试方案性能测试模型基于产品生产力(JPH)产生的业务数据来进行测试基于一定生产力(比如60JPH)一倍、两倍、三倍递增测试，观察生产力的提高系统性能的变化在可预知的最大生产力的压力下，系统不间断运行，持续1个月的压力考验浪涌测试：定时集中插入大量数据7.2.9项目验收项目验收方案 上海XXX科技实施的此项目的总体验收目标，应该以招标书中定义的需求功能以及项目合同中的硬件设备清单为依据。 因为MES系统涉及到软件和硬件的内容比较多，整个项目实施的周期跨度较长。为了减少项目风险、及时辨识项目实施过程中出现问题，我们将项目验收的过程贯穿整个项目实施周期，而不是以往采用的在项目结束时的一次性验收的方式。 通过对各个阶段验收，能及时发现问题，对于不达标的地方及时整改。这样，所有的问题都能控制在项目的各个阶段内，使项目管理者能够更好的控制项目各阶段的节点，保证项目正确有效的按照约定的进度完成。 每当具备阶段性验收条件后，开始进行验收工作，通常一次验收的过程如下：提出验收书面申请客户方审核是否具备验收条件，如不符合暂不验收客户方和供应商共同准备验收标准和相关验收材料客户方组织相关人员参与验收通过验收，生成验收报告验收不通过，进行整改 对于验收中发现的硬件和软件的问题，我们将明确问题所在，并责成相关人员进行整改，问题整改完成后再次进行验收，直到验收通过。 另外，阶段性的验收结果也将用于项目阶段性付款的依据。项目各阶段验收内容及相关约定.1定制硬件验收 验收时间：定制硬件工厂制造完成 验收内容：MES系统的ANDON板是根据用户需求特别定制的，当ANDON板出厂运到工厂前，需要进行出厂前的验收。 验收遵循标准：检查ANDON板的式样、技术指标及制造工艺是否符合LED板设计标准；检验ANDON板合格证、电器图纸和出厂检验报告等相关资料是否齐全。.2硬件设备安装前验收 验收时间：当MES系统的硬件运抵工厂准备安装前进行验收 验收内容：依据项目合同中包含的设备清单对运抵工厂的硬件设备进行验收，检验通过后方可进行现场安装。 验收遵循标准：该阶段主要是对硬件设备的型号、设备数量以及设备保修资料等进行核对，检验到厂硬件是否和标书中约定的一致。.3网络联通性验收 验收时间：车间内网络部署完成 验收内容：检验车间网络内各网络节点的联通性是否正常，检验各网络节点的速率是否达标，网络通讯速率10/100Mbs（各设备网卡不同）；检验机加工区域网络和总装配线网络通讯是否正常；检验车间网络和办公区网络通讯是否正常。 验收遵循标准：详细验收参考国标《基于以太网技术的局域网系统验收测评规范》.4机床设备接口验收 验收时间：上海XXX科技完成现场设备硬件线数据采集，开始验收。 验收内容：上海XXX科技通过硬接线方式从机床设备获取相应信号，并通过ANDON板、界面报表显示。 验收遵循标准：ANDON板、界面报表显示的设备状态信息和现场设备实际情况一致。.5文档及图纸收 验收时间：项目试运行后。 验收内容：用户方检验上海XXX科技提供的MES项目的各种文档，以及各硬件安装图纸是否齐全，内容是否真实。 验收遵循标准：所需提交资料包括《硬件清单》、《硬件设计图纸》、《硬件安装图纸》、《系统需求说明书》、《系统设计说明书》、《安装手册》、《用户操作手册》、《系统维护手册》、《系统验收报告》和《培训资料》。.6MES系统总验收 验收时间：项目试运行合格，准备正式上线 验收内容：对系统的所有软件和硬件进行最终联合验收。该验收结束后系统正式上线运行，整个项目则进入到售后维护阶段。 验收遵循标准：参考上述各项的标准。培训以及知识转移经过多年的项目经验，我们建立了一整套的服务培训体系，我们服务培训体系的宗旨是：为客户提供合适、有效、成功的培训，并与客户保持良久的合作关系。培训策略本项目培训考虑分阶段进行。在部署前对客户直接配合人员作一次集中培训，培训完开始部署，项目每告一段落，对直接配合人员进行不同模块的培训或相同模块不同深度的培训，项目实施完毕进行一次总体培训。并可对用户方的附属机构进行培训。培训人员培训人员将为项目经理、专职培训师。经过多年的项目经验，我们建立了一整套的服务培训体系，我们服务培训体系的宗旨是：为客户提供合适、有效、成功的培训，并与客户保持良久的合作关系。客户培训体系的服务范围：包括授课、交流、咨询等服务。客户培训体系的响应速度：计划内培训，严格按照与用户确定培训计划时间执行；计划外培训，在客户提出培训请求后24小时内，向客户反馈培训计划并在得到用户认可后按照计划执行。完善的人员培训是一切现代科技应用之基础，也是项目按既定目标实施的关键。我们将为客户订立一整套计划，针对各个层次的工作人员，由经验丰富的工程师，施以专业的培训，使我们的建议方案，能够发挥最大的效益。培训内容本项目培训分现场实施培训、脱产集中授课培训二种方式。现场培训是指在系统安装调试过程中，由我们的专业技术人员在现场指导和解答，培训对象可以涉及到系统的所有相关人员，现场培训的时间一直维持到系统正式交付为止，本阶段培训安排在工程安装期间及工程施工现场进行，目的在于使技术人员加深对本系统的整体性了解，并掌握安装调试方法，以及加强对常见故障的现场处理能力，从而使技术人员能够对整个系统进行独立管理、故障处理、测试维护、日常操作等工作，确保系统能正常安全进行。集中培训主要是指为便于系统管理员和系统操作人员熟练管理并操作应用系统而提供的培训，主要采用定点集中的方式由我们进行相应的内容培训。培训的对象领导阶层：着重于介绍新技术及国内外成功的样板，导入先进的服务项目及最优质服务目标。工程师：工程师的培训以详细介绍、操作原则及流程的制定及相关经验的交流为重点，能在最短时间内，达成本项目的既定目标。系统操作、维护人员：对于一般操作、维护人员的培训目标，是确立他们对于系统软硬件的特性与操作程序的了解，以提高系统的服务品质，发挥最大效益。培训目标通过培训，使XXXMES项目的技术人员能独立掌握系统的配置、故障诊断、维护管理、日常操作等技术，使之能适应系统正常运行、维护、管理和操作的需求。1系统管理员培训要求熟悉整个系统的硬件和软件结构、系统的配置熟练掌握系统基本组成及原理熟练掌握系统的操作与运行管理熟练掌握权限、用户配置等系统管理熟练掌握系统的安装、检测、维护熟练掌握排除故障的基本技术熟练掌握信息的发布与管理2管理层成员培训要求了解系统基本组成及原理熟练掌握制造执行系统操作步骤现场操作工成员培训要求了解系统基本组成及原理熟练掌握生产控制模块操作步骤3企业成员培训要求了解系统基本组成及原理熟练掌握制造执行系统企业子系统操作步骤4现场操作人员培训要求了解系统基本组成及原理熟练掌握PDA系统操作步骤培训计划根据应用系统软件用户对象的不同，培训分为四个部分，分别针对网站系统管理维护人员、XXX管理用户、现场操作用户。1．针对系统管理维护人员的培训。主要包括：◆软件系统的安装、配置和调试；◆网站数据的备份；◆网站的参数设置、用户管理、权限管理、授权阅读管理◆软件系统的操作◆通过培训，网站系统管理员可以独立完成网站系统的日常管理和维护。2．针对XXX管理层用户的操作培训◆制造执行系统各子模块培训◆通过培训，XXX管理层用户可以独立完成制造执行系统各子模块的业务操作。3．针对现场管理用户的操作培训◆企业门户各子模块培训◆通过培训，企业用户可以独立完成企业门户各子模块的业务操作。4．针对现场终端用户的操作培训◆移动终端业务操作◆移动终端日常维护◆移动终端数据同步◆通过培训，移动执法终端用户可以独立完成移动终端的日常管理和维护。通过培训，用户的操作人员可以独立进行网站信息组织、编辑和发布工作，具体内容如下：具体培训课程及培训人数可根据业主方实际情况作调整。课程名称提供的资料持续时间授课教师培训对象及人数培训地点制造执行系统各子模块日常应用操作培训上海XXX科技自制教材2天上海XXX科技公司资深培训讲师系统管理员和系统用户XXX门户各子模块培训上海XXX科技自制教材5天上海XXX科技公司资深培训讲师系统管理员、XXX管理用户和现场用户XXX各应用系统安装部署及开发培训上海XXX科技自制教材2天上海XXX科技公司资深培训讲师系统管理员XXX操作系统、数据库、中间件安装部署及日常维护系统专用培训教材2天上海XXX科技公司资深培训讲师系统管理员XXX质量保证以及服务承诺9.1技术支持承诺我们在项目验收后，将提一年的系统售后维保服务。提供上海总部的快速立体化响应服务。内容主要包括：1、由我公司售后服务部门统一为客户提供产品使用解答和技术支持的内部协作，保证系统的正常稳定运行；2、故障报修的响应时间为即时，到达现场的时间为2小时，故障恢复时间为4个小时；3、提供产品终身咨询服务；4、提供日常5*8小时（周一至周五的8：30AM-5：30PM）服务部门电话/公司传真；5、提供7*24小时400求助电话和客户服务负责人电话。6、售后服务期内，提供本项目中所有产品升级服务。提供系统应急恢复服务。7、定期巡检，对用户的系统运行情况的定期检查和优化，对潜在的故障点进行预防。8、免费期满后，我们将继续提供技术服务，费用由双方商定,但不大于本合同总额的10%；9.2服务方案9.2.1产品升级服务1、服务期内提供产品升级。2、用户在使用过程中提出的共性功能需求升级。3、产品中已有功能的必要性完善。升级工作将确保在系统数据完整备份的情况下进行9.2.2产品日常使用技术支持主要是针对产品日常使用方面的问题，提供远程技术解答。提供产品使用设置和页面修改的远程指导，必要时进行协助工作。为保障网站的日常运行，提供以下系统维护服务：操作系统维护：每月对操作系统进行一次全面维护；数据库维护：每月对数据库进行一次全面维护，包括垃圾数据清理、log日志整理、数据备份等；服务器维护：每月定时对服务器进行维护，包括网络安全和网络性能检查和修正；提供阶段性系统维护和升级建议；及时提供操作系统和数据库的补丁包；针对节假日和重要时期提供特别的网络安全和网站安全服务。9.2.3系统维护服务项目验收交付后，项目经理将提供系统数据备份方案和基础备份数据。在维护期内，售后服务部会及时提醒用户做好系统的备份工作；售后服务部会为每位用户保存项目交付时的基础备份数据。9.2.4确保投入的维护力量我公司成立专门的安全技术支持小组提供门户网站安全技术支持，小组将及时、快速地协调、处理各种事件或者事故；及时响应、处置预警和问题通报。9.3服务响应对于用户而言不同的故障对业务的影响是不同的。普通的故障不会给用户带来太大的麻烦，而严重的故障则可能导致系统全面瘫痪。因此针对较为严重的系统故障，承建方必须以最快的速度解决用户的问题，这样就需要对所有故障事件进行分类和界定，以决定采取什么样的服务响应速度。为了减少客户损失，充分利用公司资源，我们将客户的系统故障（CASE）分成4个级别。具体的标准如下：一级故障（CASE）：由于硬件或系统软件的原因造成现有的系统停机，或对用户的业务运作有严重影响。二级故障（CASE）：现有系统的操作性能严重下降，或由于系统性能明显下降，使用户的业务运作受到严重影响。三级故障（CASE）：系统的操作性能受损，但用户大部分业务运作仍可正常工作。四级故障（CASE）：对用户的业务运作几乎无影响，或没有影响。服务人员在接到客户求助电话时，严格按照CASE的建立流程工作。9.4服务策略9.4.1提供多方式服务用户可以通过不同方式向客户服务响应中心提出服务申报。如：通过客户服务部电话、公司传真、信函、E-mail和来访。另外用户还可以访问我公司网站“服务咨询”频道，该频道5*8小时（周一至周五的8：30AM-5：30PM）由专人值守。5*8小时之外，用户可以直接拨打客户服务部负责人的手机，我们保证用户的问题在任何时间都能得到及时的响应。9.4.2现场服务我公司在接到产品故障通知或服务要求后立即作出响应，如果远程技术支持无法解决的，2小时内到达现场，提供现场技术服务，4小时完成修复。9.4.3及时通知服务我公司提供的及时通知服务，是把刚刚发现的关键问题或软件错误问题提前告知客户。使客户在遇到技术问题之前就已解决，使用户防患于未然。9.4.4电话、网络指导和互动服务如果用户在使用过程中遇到相关问题需要