软件工程导论概述-----MP微软编程和MSF

微软过程MP与MSF

微软过程

– MP，Microsoft Process
– 从MSF中抽取出项目开发准则中的过程模型和组织模型构
成了一套软件过程模式
– 内容涵盖软件过程中的过程、人员及组织、方法、产品等
不同方面

微软解决方案框架

– Microsoft Solution Framework，MSF
– 微软顾问咨询部于1994年根据微软公司成功的产品开发经
验总结、设计而成的框架体系

MSF内容

框架结构的经验知识库

– 企业结构设计方案
– 采用交互的方式，侧重于制定长期规划，同时也能完成短
期目标
– 项目开发准则
– 包括组队模型和过程模型，用于建立高效的项目组，管理
项目组的生命周期
– 应用程序模型
– 用于支持设计复杂的分布式企业应用
– 企业信息基础设施的实施方法
– 使用组队模型和过程模型支持实现、操作和技术上的方案

微软过程原则

– 制定计划时兼顾未来的不确定因素
– 通过有效的风险管理减少不确定因素的影响
– 经常生成过渡版本进行快速测试来提高产品的稳定性及可
预测性
– 快速循环、递进的开发过程
– 从产品特性和成本控制出发创造性地工作
– 创建确定的进度表

– 使用小型项目组并发完成工作，并设置多个同步点
– 将大型项目分解成多个可管理的单元，以便更快地发布产
品
– 用产品的前景目标和概要说明指导项目开发工作–先基
线、后冻结
– 避免产品走形
– 使用原型验证概念，进行开发前的测试
– 零缺陷观念
– 非责难式的里程碑评审会

MSF 的核心有八个基础原理：

– 推动开放式沟通
– 为共同的前景而工作
– 赋予小组成员权力
– 建立清晰的责任和共同的职责
– 关注交付业务价值
– 保持灵巧，预测变化
– 质量投资
– 学习所有的经验

MP的过程原则

1)．制定计划时兼顾未来的不确定因素

– 任何项目都包含不确定因素，如
• 需求可能不断变化
• 技术可能不断变化
• 市场环境可能变化
– 考虑到未来可能发生的不确定因素
• 制定项目计划、进度表时，为不可预期的项目变更及项目风险留
出一定的余地
– 点评：这一原则与AP第4条价值观“响应变化胜过遵循计
划”异曲同工

2)．通过有效的风险管理减少不确定因素的影响

– 有效管理和控制不确定因素的最好方法——使用成熟的风
险管理模型
– 点评：对照而言，RUP提出的风险管理方法为在每次迭代
中都要解决最突出的风险问题, 两者互补

3)．经常生成过渡版本并进行快速测试来提高产品的稳定性及可预测性

– 每日生成制度（Daily Build）
– 点评：在最大程度上保证整个产品开发过程可管理、可预
期，并能增强产品的稳定性，类似AP的持续集成

4)．快速循环、递进的开发过程

– 要求项目组在开发过程中迅速完成每一次递进过程，并在
每一个开发周期中都能切实地增加产品特性，提高产品质
量
– 点评：和敏捷过程所强调的不断重复产品的生命周期、以
递进的方式推出版本的要求相似

5)．从产品特性和成本控制出发创造性地工作

– 时刻关注产品特性的开发和项目资源的控制之间的平衡
– 因为任何商业软件开发项目的最终目标都是以有限的成本
实现所有客户需要的产品特性
– 微软提倡“聪明地工作”
– 项目组并不对其成员每天的工作时间作硬性的规定，而是
要求其成员能够创造性地工作

6)．创建确定的进度表

– 点评：在具体制定项目进度表方面，借鉴AP的策略，即制
定一种细致度逐渐降低的进度计划以保持足够的灵活性

7)．使用小型项目组并发完成工作，并设置多个同步点

– 微软公司的项目组善于将较大的项目分解成多个子项目，
由多个小型项目组并发地完成工作
– 要在项目过程中设置多个同步点（Synchronization
point）
• 保证所有小型项目组之间工作目标的统一和工作任务的同步
• 里程碑是最为重要的项目同步点

8)．将大型项目分解成多个可管理的单元，以便更快

地发布产品
– 大型项目分解成不同的产品单元的拆分方法：
• 根据产品特性
• 每一个产品单元拥有自己特定的工作目标并由一个小型项目组负
责

9)．用产品的前景目标和概要说明指导项目开发工作

——先基线化，后冻结
– 点评：冻结思想与AP不同，AP倡导即使到了开发的后期
，也欢迎改变需求

10)．避免产品走形

– 检查和审视当前项目状态、产品特性是否和产品的功能说
明书相吻合
– 点评：对照而言，RUP中避免产品走形的方法是用例驱动

11)．使用原型验证概念，进行开发前的测试

– 原型验证概念（proof-of-concept prototyping）
• 内容：在产品开发工作开始之前，项目组应使用原型对产品需求
、技术可行性和项目范围进行早期论证
• 作用：这种开发前的测试可以有效减少不确定因素的影响，避免
项目风险

12)．零缺陷观念

– 零缺陷（zero-defect）并不意味着产品中没有Bug
– 首先按零缺陷这一高标准进行要求
– 具体实施时，项目组在产品的每一个阶段、在发布产品的
每一个版本之前，都对已发现的产品Bug进行了有效的管
理和控制，改正了影响产品使用的Bug，对不影响产品使
用、且因资源有限无法及时修改的Bug进行跟踪和记录，
确保产品中所有已发现Bug都在项目组的控制范围之内，
都可以在适当的时机得到修正

13)．非责难式的里程碑评审会

– 里程碑评审会——质量保证会议
– 会议主旨不在于追究项目组或项目组成员的责任
– 目的发现项目中存在的问题并及时解决问题
– 讨论项目中哪一些产品特性没有完成、哪一个阶段工作延
期了、为什么没有完成、为什么延期、是否需要再追加投
入、是否需要调整项目组的人员结构等等
– 比尔盖茨也经常参加重要产品的评审会