微软解决方案框架结构MSF的学习资料Word格式.docx
《微软解决方案框架结构MSF的学习资料Word格式.docx》由会员分享，可在线阅读，更多相关《微软解决方案框架结构MSF的学习资料Word格式.docx（99页珍藏版）》请在冰豆网上搜索。
MSF收集了一组集成的资源和准则来指导项目组走向成功。
它包括明确的概念、详细的工作指南和微软最好的实践经验，保证您能立即开始工作。
这些资料可由以下途径得到：
联机资料
CD-ROM知识库
教学课程
完整的参考手册
因为CD光盘中的内容是由HTML文档组成，所以要使用MicrosoftInternetExplorer阅读这些资料。
此外，CD光盘中还有更详尽的指南讨论在参考手册中提出的概念。
它在不断发展
MSF是一个框架结构，它不是一成不变的。
相反，MSF会随我们从微软的客户和合作伙伴那里的学习而不断的发展和完善，新的思想和准则会不断地被引进MSF。
这些发展将适应技术的更新、商业需求的变化，并支持构建更好的软件解决方案。
技术上的变化会导致MSF作出相应的变化。
我们会不断地在参考资料上增加更多的指南、介绍和更新的概念，根据当前的思维增进我们的教学课程。
例如：
我们认识到Internet强大的生命力和影响力，我们就在我们的资料上很快的作了针对Internet的更新,补充介绍我们的概念如何应用于开发基于Internet/Intranet基础和结构的应用程序。
MicrosoftSolutionsFramework-概述二
为什么应用MSF?
商业问题
商业策划者在面对世界上不断变化的复杂技术时，必须确定自身企业总体技术策略的方向。
最大的挑战来自于保证商业目标和技术目标间的一致。
当前，信息技术的投资较以往越来越高。
投资以不仅仅局限在数据中心方面，更多的倾向于分布式网络的增值、群组工作软件和提高使用者的生产力，保证信息技术投资得到有效的控制。
即便完全不考虑这些投资，错误的使用技术给商业带来的负向费用的影响，也是不容质疑的。
所以新技术的成功实现将给企业带来重要的机会：
今天的分布式组件技术允许更大的弹性，包括集成不同的协议、应用程序接口、应用程序、操作系统和硬件。
今天的技术也通过消息传递、事务处理协调、复制、数据仓库、多层结构的设计和鲁棒性的客户机/服务器开发工具包提供对商业处理过程和活动的支持。
基于组件的技术提供了一种在商业方案中集成组件行业最好产品的能力。
组件同样也允许随企业结构和商业处理过程的变化，更快地重新配置应用系统。
今天的技术能够在不瓦解企业的基础结构设施的情况下，不断的适应发展变化中的商业需求。
多层结构的应用程序允许分离用户、事务和数据服务，保证新版本的组件在不影响整个系统的情况下加以实现。
降低费用
客户机/服务器技术可以降低系统整体费用。
但是企业必须重新评估它们的基础结构设施和商业运作过程，来保证多余的费用真正被消除（例如：
传统的功能转移到更低廉的平台，旧系统停止使用，新的商务处理过程最大的提供了增值能力等等。
）
MSF如何帮助解决问题?
MSF通过五个基本模型的应用，帮助企业认识到采用新技术的优点。
这些模型适用于规划、构建和维护整个过程中不同方面的问题。
（参见图1）
图1：
MSF强调的几个领域
MSF企业总体结构
MSF企业总体结构模型提供了一系列指南，用于规划企业的基础技术设施，流程化商业的运作过程，并鼓励重用性。
这种模型是描绘构建于用户服务、事务服务和数据服务基础上的，多层应用开发的MSF应用模型的基础。
图2：
企业总体结构模型
MicrosoftSolutionsFramework-概述三
图3：
MSF应用模型
MSF组队模型
MSF组队模型展示了如何组织项目队伍，在时间控制和连续不断发展计划的要求下，有效的交付系统的解决方案。
它描述了六种基本的角色（程序管理、产品管理、开发、测试、系统实现和用户教育）。
图4:
MSF组队模型
MicrosoftSolutionsFramework-概述四
MSF过程模型
MSF过程模型解释了如何基于：
范围、进度和资源，规划和控制面向结果的项目。
它是基于四个可见里程碑交互的、允许修改的过程模型。
过程模型中的“设计”阶段在面向商业解决方案内容，结合过程模型、组队模型和应用模型的组件方案设计过程（DesigningComponentSolutionsProcess）中，进行了详细的介绍。
图5：
MSF过程模型
图6：
组件方案设计过程
MSF的组成元素
规划
企业总体结构规划
应用三个基本模型可以帮助整体的理解企业。
企业总体结构规划提供了分析企业组织机构运作和商业应用集成和处理的基准。
企业总体结构是包含四个方面的框架：
事务、应用、信息和技术。
这些模型不仅仅描绘了企业总体结构的组成部分，还通过以上各个方面在集成系统中的应用，帮助企业有效地实现每一个方面。
企业总体结构规划的过程，提供、揭示了商业运作的标准和所受的局限，使商业运作过程更易管理、费用更有效。
MSF的方法以“边规划、边设计”为基础，这意味着企业总体结构规划过程，一直伴随着商业需求变化和技术发展的连续过程。
企业总体结构规划使用了MSF的一些基本原则，如：
风险控制的时间安排、固定的产品发布时间、基于活动的设计、外部可见的里程碑、小组模型、并行的结构设计、最大的限制、连续的方案开发和结果实现。
对比以往的自上而下的方法，现在项目不仅由企业模型所控制，它们还将直接受企业总体结构发展的影响。
构建
方案开发准则--SolutionsDevelopmentDiscipline（SDD）
软件开发是一种复杂的、有创造力的过程。
在较大的开发队伍中，采用自上而下的方法，将会抑制创造力、有效的交流和真正的方案开发。
SDD通过在软件开发过程中应用MSF基本模型，帮助软件组织克服这些障碍。
组件方案设计--DesigningComponentSolutions（DCS）
DCS详细解释了MSF过程模型中“设计”阶段的内容。
DCS基于方案设计过程，覆盖了为给出满足商业需求的功能设计，所必需进行的设计活动。
DCS的概念帮助理解和融合使用者和商业的需求（在项目层次上）。
它强化应用程序的逻辑结构，以达到简化复杂性的目标。
这种设计过程允许有效地分派各种具备专业技能的人，以使特定的需求得到满足。
这种技术同样保证在设计过程中维护应用程序的一致性。
整个设计体系使用场景分析描绘概念设计，使用对象和服务描绘逻辑设计，使用组件描绘物理设计。
重用性设计--DesigningforUsability（DFU）
DFU提供了大量简明的概念和实际的经验，进行以用户为中心的基于Windows的程序设计。
它侧重Windows应用程序的物理设计，强调用户界面和操作衔接等原型技术。
维护
基础设施实现和维护
MSF建立起对三个基本MSF模型中的角色、关系和应用的一致理解，解决实现、管理和维护技术基本结构的问题。
MSF包含IT基础结构实现要求的、有效的组队模型和过程模型，确定了关键的项目构成因素和最终交付的成果，强调一致的规划和管理模型给系统带来的好处和费用的降低。
开发大型复杂的软件项目是一项充满风险的工作。
统计结果表明大型IT项目的失败比例相当高，失败有很多原因：
不断变更的需求，不稳定的或不完善的需求说明书，低质量的编码，过大的应用范围，不合适的组队模式，低效的工作过程，不明确的目标等等。
微软解决方案框架结构（MSF）通过其核心模型来解决这些问题。
组队模型着重于解决在复杂软件工程项目中如何组建项目组、分配合适的角色、项目组的管理、职责划分和质量控制等问题。
虽然组队模型是起源于软件开发过程中的规范和准则，但它也同样被成功的应用于基础信息结构设施的实现过程。
组队模型
简介
微软解决方案框架结构（MSF）通过其核心模型来解决这些问题。
MSF组队模型
高效项目组的特点
一个高效的项目组能够赋予项目组成员权力、并明确他们的责任。
明确的责任与权力会消除获得成功过程中的障碍，并使项目组成员专注于自己的工作目标。
高效的项目组能够保证项目的目标和进度可以达到。
每个项目组中的成员根据他所负责的任务进行时间、进度的估计和安排。
项目组中的每个成员都需要理解客户和最终使用者的需求，这样他们就能够基于使用者和客户的期望作出良好的决策。
高效项目组的质量目标
高效项目组的质量目标：
满足客户的期望
在项目的限定条件下交付产品
在交付产品之前，确定并解决所有对客户和最终用户来说都很重要的问题
保证使用者知道如何使用这个产品
确保产品的平滑移交与发布
MSF组队模型由六个明确定义的角色组成：
开发、测试、系统实施、
用户教育、产品管理、程序管理。
项目组成员之间无限制的交流是一个潜在的成功因素。
除了系统实施角色外，其他角色在众多的微软产品开发组中都可以见到。
对大型企业的IT机构来说，可能还有其它的用于补充项目组的被称为“支持角色”的人员，如：
数据库管理员、产品质量监督员等。
图1.MSF组队模型
同等关系的组队角色
MSF组队模型定义了相互依赖、相互协作、同等角色关系的工作模型。
每个组中的成员在项目中都有一个明确定义的角色，并且关注于一种特定的任务。
这种方法鼓励各个角色的所有感，最终结果是产生更好的产品。
每种角色小组的领导者负责管理、指导和协调，小组中的成员专注于执行他们的任务。
基于项目的大小，每个角色被分配给一个人或有人领导的一个小组。
同样，一个人也可以承担多种角色。
每个小组成员都要估算他自己的工作量，估算的结果用于作为他们各自角色的项目计划参考，各个角色的项目计划又是项目总体计划的一部分。
在一个成功的项目组中，每个成员都要感觉到对产品的质量负有责任。
不能出现由一个小组成员代表另一小组成员对质量负责的情况。
类似地，每个小组成员都是客户利益的维护者。
同等关系组队角色的特点
成功的应用同等关系的组队角色模型将有以下特点：
各个角色之间相互依赖、相互协同的工作
每个成员都有明确定义的角色和特定的任务
组长负责管理、指导和协调
每个人都关注于自己任务的执行
交流不受限制
每个人都对交付产品的质量负责
每个工作组成员都在维护客户的利益。
组队模型不是组织结构图
有一个关于MSF组队模型的问题：
谁是主管？
MSF组队模型定义了角色和责任，但没有定义项目组的管理模式和结构。
项目组可以由一个部门经理负责管理，或根据项目的需要由几个不同的部门成员组成。
组织结构图确定出谁是主管，MSF组队模型定义了工作划分和由谁负责完成该项工作。
采用MSF组队模型的优点
项目组的每个成员都为产品的成功作出贡献。
建立了一种鼓励“明确、高效、参与”的企业文化。
增强所有角色的责任感。
鼓励一种面向客户的开发过程。
MSF组队模型的这些优点已经被使用这种模式的组织机构所证实，其中包括微软公司。
实现MSF组队模型的条件
为在企业机构内实现“同等关系的组队模型”，企业机构必须理解以下原则：
应用“同等关系的组队模型”并不需要重新定义企业的组织机构。
每个项目组中的成员，都要感到他们的工作是同样重要和有价值的。
所有项目组中的成员（或至少要求项目组的负责人）要为项目开发的全过程作出贡献。
每个组中的成员都要对产品或服务的质量负责。
产品的质量是由客户的需求或期望确定的。
注:
MSF组队模型可能由于文化背景的不同，不能被所有的组织机构或地区采用。
成功的关键在于每个MSF组队角色的目标在项目组中都有人负责实现。
MSF组队角色
产品管理
产品管理的任务
产品管理负责为产品或服务确定一个方向，获取并量化用户的需求，开发、维护商务关系和商业环境，并管理客户的期望值。
这种角色的目标是确保清晰地表述客户的期望值，并使其为项目组所理解，并使功能规定与客户的业务优先级相吻合。
产品管理负责“前景陈述文档”。
“前景陈述”表达了要开发产品或要实现服务的关键商业目标，（例如“顾客必须要在60秒或更短的时间内完成退房手续”）。
产品管理负责项目的高层次交流和协调，如商务立项、项目费用、合同谈判、演示，以及产品定位。
产品管理所需的技能
产品管理这种角色的成员无须具备开发技能，但是他们应该对技术有深刻地理解并知道技术会给目标客户带来哪些潜在收益。
最重要的是，产品管理这种角色应该以用户的语言说话，并具有商业领域应用的经验。
目标客户中能够理解自身业务的人将是项目组产品管理角色较合适的人选。
产品管理在软件开发组中所担任的角色
收集项目需求并确定其优先级
将量化后的使用者和客户的需求讲解并提交给项目小组
为产品确定方向
确保功能规定能够体现业务需求
协调项目组与外部的交流，如：
商业立项
给客户群体作演示
将功能特性集成
产品的定位与范围确定
费用和合同的谈判
管理产品中非软件元素的集成与交付（例如，参考卡片、模板等等）
推出一个合格的产品
程序管理
程序管理的任务
程序管理的任务是控制决策的各种因素，以保证在合适的时间推出合适的产品。
同时程序管理创建功能规定文档，并将它作为如何实施产品或服务的一种决策工具。
最后程序管理将面对，使产品或服务与组织标准和操作目标相一致的日常协调工作。
程序管理是一个关键的交流与协调的角色。
基于前景陈述文档，程序管理勾画出并维护功能定义。
程序管理负责所有与分析、定义和系统结构相关的活动。
在开发人员的配合下，程序管理必须确保功能规定在现有的资源下，技术上是可以实现的。
定义项目如何与外部标准相协调，并使外部群体参与项目的审查过程。
维护与外界的技术合作与交流，这是确保开发小组不受外界干扰，并有效工作的一个关键因素。
同样它也会使项目组能够发现并重用其他人的工作。
在特定发布所包含的功能完成后，对功能规定进行修改控制。
合并各个角色小组产生的项目进度，并管理主进度（每一个项目组中的成员都有义务，根据他们的职责在整个项目中安排他们自己的时间进度）。
程序管理所需的技能
程序管理需要具有很强的技术能力，以与开发人员相配合作出关键的决策。
他们需要理解项目体系结构的实质，他们常常是项目组中最有经验的成员。
程序管理必须跟踪项目的进展。
另外，程序管理还需要具有很强的交流和讲解的才能，以便更有效地进行协调和谈判。
程序管理在开发组中所担任的角色
根据其他组的负责人提供的信息创建功能规定：
定义产品如何与外部软件系统及组件互操作。
执行产品规定的技术审核。
对功能规定文档进行修改控制。
在每个项目里程碑处，协调项目组的审核；
如有必要对进度和功能进行调整。
跟踪项目进展并管理项目进度。
交付一个合格的产品。
开发
开发的任务
开发的任务是构造或实现一种满足规定和用户期望的产品或服务。
开发这种角色是用于交付一个完全服从讨论过的功能规定的系统。
这种角色很重要的一个方面就是积极地参与构建功能规定的过程。
与瀑布式过程模型中的开发继承功能规定的方式相反，MSF组队模型中开发组的负责人与程序管理一起工作，共同构建验证结构的演示模型，提供技术解决的方法，探索设计中的各种选择。
当功能规定成为基准线后，开发角色开始承担负责开发时间计划的责任。
在软件开发的项目中，开发也负责审查测试计划。
开发必须及时改正程序中的错误，对代码的质量负责。
在基础信息设施实现的项目中，软件是购买而不是开发的。
开发角色的任务是提供各种选择的技术评估、构造演示环境、配置系统、并集成新的方案到现有的基础信息结构设施中去。
开发所需的技能
客户机—服务器系统的开发，需要熟悉C语言编程、MicrosoftVisualBasic编程、网络、通讯、数据库设计和数据库性能调整。
尽管一个人不可能在所有这些技术方面都是专家，但是在一个开发组中包含所有这些方面的专长的开发人员非常重要。
开发的经理通常是一个有系统结构实现经验的总体设计师，或者是一个在项目的所有技术领域里能够理解和懂得关键问题的开发人员。
开发在开发组中所担任的角色
积极地参与功能规定的创建和复查。
与程序管理一起工作，构建验证概念或结构的演示模型。
创建“自下而上”的开发进度表。
审查测试计划。
开发和构建产品（代码的集成编译可以由测试来执行）。
及时地找出和修改代码错误。
交付一个高质量的产品。
测试
测试的任务
测试的任务是保证产品或服务交付之前，能够发现所有存在的问题。
测试要准备测试计划、测试规定和测试的案例，这些文档用于拓宽测试范围和进行足够的可使用性测试。
在软件开发的项目中，测试必须针对所有的接口，包括用户界面和API的每个方面。
将新软件集成到现行系统时也必须进行测试。
测试人员通常开发自动测试程序，这样开发人员在把代码提交给测试人员以前，就可以使用它们对自己的代码进行测试。
测试要管理错误跟踪数据库，并对错误报告的质量负责。
错误数据库对于产生针对进度跟踪项目状态的统计报告来说，是一种重要资源。
错误报告也用于确定项目进度中的、关键部分的风险。
测试这种角色必须独立于开发才是真正有效的。
联系时间进度，测试需要提供产品质量稳定性的独立验证。
注
重要的是要认识到测试不仅是包含代码上的，测试还应用在功能规定、系统的性能、用户界面和实施计划上。
测试所需的技能
测试组必须由一个熟悉测试过程、统计学和软件开发的人来领导。
由于大多数测试组要编写自动测试程序，所以一个好的测试经理必须也是一个有经验的开发者，他必须胜任领导同样大小的一个开发项目。
对于客户机—服务器系统来说，测试计划和过程可能很复杂。
他们必须考虑到桌面系统的用户配置特性、网络问题、桌面系统连接问题。
对于事件驱动的编程、多网络传输协议、不同的服务器、主机或者后台系统互操作问题、数据和数据库管理问题等，测试工作可能会变得更为复杂。
测试组必须认识到应用配置之间复杂的相互作用。
测试在开发组中所担任的角色
开发软件测试计划、规定和测试的案例。
测试用户界面、应用程序接口。
开发和维护自动测试程序。
跟踪所有的错误和问题，保证它们在产品提交以前被解决。
构建并管理产品的集成和控制（同样也可以由开发来完成）。
提供给开发组与产品质量、进度和风险相关的测试衡量数据。
测试对比质量保证
测试与质量保证有着重要的区别：
测试针对一个项目，包含详细的技术工作，它是项目组的一个核心角色。
质量保证通常是公司的一个职能部门，它在一个负责企业质量和标准实施和监督的人领导下工作。
质量保证也负责在不同的项目组之间共享最好的实践经验。
用户教育
用户教育的任务
用户教育的任务是通过方案演示和系统培训，最大可能性地使系统的使用者得到相关产品和服务的价值。
用户教育的第二个任务是通过使产品更容易理解和使用，降低系统技术支持的费用。
作为使用者利益的倡导者,用户教育参与系统和用户界面原型的设计和构造，也包括程序的安装过程。
用户教育也开发伴随系统的打印文档或电子联机文档。
如果需要的话，用户教育还要准备并交付系统的培训材料。
通过推动和参予产品的可使用性测试，用户教育与程序管理在设计用户界面的过程中有着紧密的联系。
用户教育也同程序管理和开发一起工作，确保产品的范围、设计的任何改动，反映在文档的内容中，并相应的调整培训内容。
用户教育所需的技能
用户教育必须熟悉用于编写产品打印文档和联机帮助的工具。
他们必须能够理解并实现项目要求的系统方案演示。
这包括对现有系统和未来系统的分析，帮助有效地做演示系统的设计。
因为培训是最终产品或服务的一个组成部分，用户教育也必须胜任教学和教学设计的工作。
用户教育在开发组中所担任的角色
设计和开发系统的展示手段，如联机帮助、工作指南、智能帮手等。
进行使用者分析。
编写用户手册。
设计和开发展示、宣传和评估的方法。
参与产品使用性测试。
创建培训计划和相关材料、环境。
培训用户。
交付
升级会员 