4第四章-软件开发过程微软过程PPT课件
- 格式：ppt
- 大小：958.50 KB
- 文档页数：131
下载文档原格式
合集下载
软件开发流程介绍PPT学习课件
计························11
（五） 编
码··························12
（六） 测
试··························152
（七） 维
开发流程总图
可行性分析和项目开发计划 ↓
需求分析 ↓
概要设计 ↓
详细设计 ↓
编码 ↓
测试 ↓
维护
仓库 经理
含义
用例及说明
表示数据的源点或终 点
表示数据流动
7
（三）概要设计
概要设计是把软件“做什么”的逻辑模型变换为“怎么做”的物理模型，把 软件需求转换为软件表示，描述软件的总的体系结构。 概要设计任务： 1设计软件系统结构 （1）采用某种设计方法，将一个复杂的系统按功能划分成模块。 （2）确定每个模块的功能 （3）确定模块之间的调用关系 （4）确定模块之间的接口 2 数据结构及数据库设计
需求分析是指，开发人员准确理解用户的要求，进行细致的调查分析， 将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相 应形式的功能规约（需求规格说明书）的过程。 需求分析的任务： 1 问题识别 （1）功能需求：所开发的软件必须具备什么样的功能，这是最重要的。 （2）性能需求：待开发的软件的技术性能指标。 （3）环境需求：软件运行时所需的软，硬件的要求。 （4）用户界面要求：人机交互方式等等。 2 分析与综合，导出软件的逻辑模型
根据软件内部数据传递，变换的关系，自顶向下逐层分解，描绘出满足功能要求的 软件模型。 描述工具： 数据流图（DFD）：以图形方式描绘数据在系统中流动和处理的过程。
数据字典(DD)：为分析人员查找数据流图中有关名字的详细定义而服务。
6
（五） 编
码··························12
（六） 测
试··························152
（七） 维
开发流程总图
可行性分析和项目开发计划 ↓
需求分析 ↓
概要设计 ↓
详细设计 ↓
编码 ↓
测试 ↓
维护
仓库 经理
含义
用例及说明
表示数据的源点或终 点
表示数据流动
7
（三）概要设计
概要设计是把软件“做什么”的逻辑模型变换为“怎么做”的物理模型，把 软件需求转换为软件表示，描述软件的总的体系结构。 概要设计任务： 1设计软件系统结构 （1）采用某种设计方法，将一个复杂的系统按功能划分成模块。 （2）确定每个模块的功能 （3）确定模块之间的调用关系 （4）确定模块之间的接口 2 数据结构及数据库设计
需求分析是指，开发人员准确理解用户的要求，进行细致的调查分析， 将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相 应形式的功能规约（需求规格说明书）的过程。 需求分析的任务： 1 问题识别 （1）功能需求：所开发的软件必须具备什么样的功能，这是最重要的。 （2）性能需求：待开发的软件的技术性能指标。 （3）环境需求：软件运行时所需的软，硬件的要求。 （4）用户界面要求：人机交互方式等等。 2 分析与综合，导出软件的逻辑模型
根据软件内部数据传递，变换的关系，自顶向下逐层分解，描绘出满足功能要求的 软件模型。 描述工具： 数据流图（DFD）：以图形方式描绘数据在系统中流动和处理的过程。
数据字典(DD)：为分析人员查找数据流图中有关名字的详细定义而服务。
6
软件开发过程总结 ppt课件
严格按照软件生存周期各个阶段来 进行开发，上一阶段的输出即是下 一阶段的输入，强调每一阶段的严 格性。
瀑布模型的优、缺点
提供了软件开发的基本框架，有 利于大型软件开发过程中人员的 组织、管理。
有利于软件开发方法和工具的研究 与使用。
在软件开发的初期阶段就要求做出正 确、全面、完整的需求分析对许多应用 软件来说是极其困难的。
如：DeRemer定律、银弹定律、…
➢ 最佳实践：由法则衍生的应用或技术实例
如：需求分簇实践
理念 定律
常识 概念
法则
最佳 实践
软件工程概论
软件工程 基本思想与目标
发展史 知识体系 四大挑战 原则与方法
软件工程 - 基本思想
著名的软件工程专家B. W. Boehm于1983年提出
巴利·玻姆（Barry W. Boehm）—软件工程估 算模型COCOMO模型之
软件工程 基本思想与目标
发展史 知识体系 四大挑战 原则与方法
※ 变更创造一切，但同时又毁掉一切
软件必然会持续变更，且还将更加频 繁。 变更的影响范围必须得到有效控制， 以避免对软件整体造成不必要的负面影响 。
※ 软件过程欠缺可重复性
➢ 受影响的因子过多，无法控制
※ 工程师和团队也无法保持稳定的生 产性能
原型模型的优、缺点
原型模型法可以得到良好的需求 定义。
能够有效处理用户的模糊需求， 开发者和用户得到充分的协作。
开发者常常需要实现上的折衷，以使原 型能尽快工作。
其实软件质量和可靠性难以保证； 资源规划和管理较为困难，更新文档工 作量繁重。
螺旋模型 Spiral Model
综合了瀑布模型和原型模型 的优点，即将两者结合，并 加入了风险分析机制。
瀑布模型的优、缺点
提供了软件开发的基本框架，有 利于大型软件开发过程中人员的 组织、管理。
有利于软件开发方法和工具的研究 与使用。
在软件开发的初期阶段就要求做出正 确、全面、完整的需求分析对许多应用 软件来说是极其困难的。
如：DeRemer定律、银弹定律、…
➢ 最佳实践：由法则衍生的应用或技术实例
如：需求分簇实践
理念 定律
常识 概念
法则
最佳 实践
软件工程概论
软件工程 基本思想与目标
发展史 知识体系 四大挑战 原则与方法
软件工程 - 基本思想
著名的软件工程专家B. W. Boehm于1983年提出
巴利·玻姆（Barry W. Boehm）—软件工程估 算模型COCOMO模型之
软件工程 基本思想与目标
发展史 知识体系 四大挑战 原则与方法
※ 变更创造一切，但同时又毁掉一切
软件必然会持续变更，且还将更加频 繁。 变更的影响范围必须得到有效控制， 以避免对软件整体造成不必要的负面影响 。
※ 软件过程欠缺可重复性
➢ 受影响的因子过多，无法控制
※ 工程师和团队也无法保持稳定的生 产性能
原型模型的优、缺点
原型模型法可以得到良好的需求 定义。
能够有效处理用户的模糊需求， 开发者和用户得到充分的协作。
开发者常常需要实现上的折衷，以使原 型能尽快工作。
其实软件质量和可靠性难以保证； 资源规划和管理较为困难，更新文档工 作量繁重。
螺旋模型 Spiral Model
综合了瀑布模型和原型模型 的优点，即将两者结合，并 加入了风险分析机制。
《微软软件介绍》课件
微软办公软件
Word文档处理软件
功能：文字编辑、排版、打印等 特点：界面友好，操作简单，功能强大 应用：广泛应用于办公、教育、科研等领域 版本：包括Word 2003、Word 2007、Word 2010等
Excel电子表格软件
功能：数据管理、数据分析、数据可视化
特点：易用性、灵活性、扩展性
微软软件的主要产品线
Windows操作系统：包括Windows 10、Windows 8.1、Windows 7等
Azure云计算平台：包括Azure云服 务、Azure SQL数据库等
Office办公软件：包括Word、Excel、 PowerPoint等
Windows Server服务器操作系统： 包括Windows Server 2016、 Windows Server 2012等
界面设计：简洁明了，易 于操作
搜索功能：提供强大的搜 索功能，方便用户查找信 息
Internet Explorer浏览器的市场份额
2007年，市场份额下 降至76%
2013年，市场份额下 降至20%
2017年，市场份额下 降至2%
2021年，市场份额下 降至0.1%
2023年，市场份额下 降至0.001%
2000年，市场份额达 到96%
2010年，市场份额下 降至59%
2015年，市场份额下 降至10%
2020年，市场份额下 降至0.5%
2022年，市场份额下 降至0.01%
Microsoft Edge浏览器的未来发展
性能提升：Edge浏 览器将不断优化性 能，提高网页加载 速度和响应速度
安全性增强：Edge 浏览器将加强安全 防护，保护用户隐 私和数据安全
最完整的Scrum敏捷软件开发过程ppt课件
总之:
› 提高了生产率; 减少“浪费” （不需要的文档，重复工作等） ， 项目的每次迭代都有明确的目标.
› 提高客户满意度; 短期内产生成效, 按预期交付软件, 每次迭代结 束产生可以运行的软件.
› 改善员工的满意度; 团队精神，减少官僚，能够规划和管理自己 的工作，减少“恐慌” ，稳定的工作量（可持续的步伐）.
Scrum 团队中的角色是不分等级的; 不应当出 现“我是开发人员我不作测试”.
› 团队按照最有利于项目的原则来分担责任 (如组件
的所有权等 ).
18
主要职责
› 参与迭代任务清单的创建 › 执行为干系人创造价值的工作 › 根据团队的承诺完成所需的各项任务 › 将工作中的各项障碍迅速与Scrum Master 进行沟
› 个人：负责指导过程的执行
Scrum Team – Scrum团队:
› 承诺完成工作，向干系人交付产品价值
17
Scrum 团队是Scrum的中心角色， 产品交付 要依靠团队.
Scrum 团队自我组织、自我管理
Scrum 团队是职能交叉的， 包含产品交付的 所有角色:开发人员、测试人员、build managers, 文档编写, 界面设计人员.
Scope frozen new PBL items to next Sprint
Initial Size Estimates As Story Points
Long term planning (best guess at the moment): 32 SP of functionality, Team Velocity 8 SP/Sprint 4 Sprints Target Sprint for each PBL item set, feasible implementation Order.
› 提高了生产率; 减少“浪费” （不需要的文档，重复工作等） ， 项目的每次迭代都有明确的目标.
› 提高客户满意度; 短期内产生成效, 按预期交付软件, 每次迭代结 束产生可以运行的软件.
› 改善员工的满意度; 团队精神，减少官僚，能够规划和管理自己 的工作，减少“恐慌” ，稳定的工作量（可持续的步伐）.
Scrum 团队中的角色是不分等级的; 不应当出 现“我是开发人员我不作测试”.
› 团队按照最有利于项目的原则来分担责任 (如组件
的所有权等 ).
18
主要职责
› 参与迭代任务清单的创建 › 执行为干系人创造价值的工作 › 根据团队的承诺完成所需的各项任务 › 将工作中的各项障碍迅速与Scrum Master 进行沟
› 个人：负责指导过程的执行
Scrum Team – Scrum团队:
› 承诺完成工作，向干系人交付产品价值
17
Scrum 团队是Scrum的中心角色， 产品交付 要依靠团队.
Scrum 团队自我组织、自我管理
Scrum 团队是职能交叉的， 包含产品交付的 所有角色:开发人员、测试人员、build managers, 文档编写, 界面设计人员.
Scope frozen new PBL items to next Sprint
Initial Size Estimates As Story Points
Long term planning (best guess at the moment): 32 SP of functionality, Team Velocity 8 SP/Sprint 4 Sprints Target Sprint for each PBL item set, feasible implementation Order.
软件项目开发过程PPT课件
• 过程模块： – 过程设计包括将在分析阶段制定的过程定义转换为代码模 块。 – 过程设计记录在过程设计文档中。
精品ppt
18
设计编码标准
• 设计的过程模块需要进行标准化 • 标准化包括设置程序和数据库的名称约定 • 标准化使代码的可读性更强，更易于维护 • 常规编码标准 • 函数声明的编码标准
精品ppt
– 颜色 – 字形 – 标题和标签的尺寸 – 页眉和页脚的外观 – 控件的主题、位置和尺寸
精品ppt
16
设计界面
• 根据 GUI 标准集设计屏幕的布局 • 可以是用户输入或显示信息的报表 • 记录在界面设计文档中
精品ppt
17
设计数据库和过程模块
• 数据库： – 根据 ERD 中包含的信息设计数据库。 – 表设计将遵循规范化的规则。 – 表设计记录在表设计文档中。
28
开发管理的一些指南
• 建立原代码互审的管理制度 ― 每个软件开发工程师遍写的原代码都有致少一个以上的同事对程序 进行审查。
• 建立原代码编写的规范 ― 每个软件开发工程师都应按照规范进行程序设计, 包括编写的风格, 格式, 组件接口的规范, 解说词的撰写, 等等。
29
测试管理的一些指南
• 根据设计构划书撰写测试计划 ― 测试计划要请项目经理和开发工程师一起进行审查。 ― 测试计划用列表式将所有的测试方案写下。 ― 每个具体地的测试方案都有专人执行，并记录每个测试方案的结果 . 任何缺陷都记录下来。
精品ppt
4
软件项目基本流程
启动
计划
执行
控制
结束
5
流程示意图
6
软件项目开发的流程及特征
• 此通用流程时间表为各种开发项目的参考，各工作项目的时间长短视项 目具体的要求来决定, 且有的流程可有可无。
精品ppt
18
设计编码标准
• 设计的过程模块需要进行标准化 • 标准化包括设置程序和数据库的名称约定 • 标准化使代码的可读性更强，更易于维护 • 常规编码标准 • 函数声明的编码标准
精品ppt
– 颜色 – 字形 – 标题和标签的尺寸 – 页眉和页脚的外观 – 控件的主题、位置和尺寸
精品ppt
16
设计界面
• 根据 GUI 标准集设计屏幕的布局 • 可以是用户输入或显示信息的报表 • 记录在界面设计文档中
精品ppt
17
设计数据库和过程模块
• 数据库： – 根据 ERD 中包含的信息设计数据库。 – 表设计将遵循规范化的规则。 – 表设计记录在表设计文档中。
28
开发管理的一些指南
• 建立原代码互审的管理制度 ― 每个软件开发工程师遍写的原代码都有致少一个以上的同事对程序 进行审查。
• 建立原代码编写的规范 ― 每个软件开发工程师都应按照规范进行程序设计, 包括编写的风格, 格式, 组件接口的规范, 解说词的撰写, 等等。
29
测试管理的一些指南
• 根据设计构划书撰写测试计划 ― 测试计划要请项目经理和开发工程师一起进行审查。 ― 测试计划用列表式将所有的测试方案写下。 ― 每个具体地的测试方案都有专人执行，并记录每个测试方案的结果 . 任何缺陷都记录下来。
精品ppt
4
软件项目基本流程
启动
计划
执行
控制
结束
5
流程示意图
6
软件项目开发的流程及特征
• 此通用流程时间表为各种开发项目的参考，各工作项目的时间长短视项 目具体的要求来决定, 且有的流程可有可无。
微软的开发过程简介
3．4 微软的软件开发过程简介一、微软的特点和成就1．微软的成就微软公司是当今世界上最大的，也是最成功的PC软件生产厂家，有20500个雇员，250种产品，年收入达8.7billion美元（按1996年估计）。
已开发了许多产品如EXCEL、OFFICE，PUBLISHER，WINDOWS95，WINDOWS NT，WORD WORKS，IE等等。
这些庞大而复杂的软件系统包含了几百万行代码，如WINDOWS95的代码量已超过了11million行，需要200名以上的程序员进行编程和测试。
这些庞大的产品已被人们普遍的接受。
80年代中期，微软和其他PC软件公司已认识到必须改进开发软件产品的方法以获得高质量的产品和有能力及时交付使用，并已致力于这方面的研究。
2．微软的哲理微软与SEI的CMM，或ISO所推崇的结构化软件工程方法不同。
微软的哲理是追求高度灵活。
企图把一种松散（有时称hacker）组织成的小组风格提升正规的产品开发。
3．微软的目标要达到有自由，又有严格性。
使许多小的，平行的小组（每个小组约3~8人）或单个程序员能一起合作工作，成为一个单一相当大的组织，并能以相对快的速度开发大型产品。
每个程序员及小组自由地、自动地进行设计及开发动作。
这些小型平行小组自主地发展产品的功能特性。
随着整个产品扩大的同时，随时会引入新技术、新概念。
由于开发者可以自由地进行创新，就如同他们单独工作一样。
关键是要保持各个部分经常同步其变化，使产品部件可以共同工作。
二、“同步稳定”方法1．“创意要通过特性的演进及固定资源来发挥”采用什么方法来开发软件要考虑许多因素：公司的目标、市场策略、资源约束、软件可靠性需求以及企业开发文化等等。
在高技术公司中雇佣具有创新能力的人才是很重要的，但更重要的是指导其创新性。
否则，开发人员会分散精力，经常凭灵感改变各种相关部件，或不考虑用户的真正要求，软件公司不会有极大的风险：无法控制公司的资源投资及无法同步众人的工作，进而永远不能把任何东西投入市场。
《云计算(第二版)》—第四章 微软云计算Windows Azure
1）Queue通信机制 Web Role和Worker Role之间进行通信的详细过程 （1）接受任务 （2）消息入队 （3）消息出队 （4）任务执行 （5）消息删除
Queue通信机制
Windows Azure存储服务
3．Windows Azure Queue
2）用Queue构建云端应用程序的优点 （1）由于应用程序各个部分之间松散耦合，应用程序可以根据业务量对各 个部分进行扩展 （2）使用Queue可以更加灵活地构建应用程序 （3）提供了缓存机制来处理突发流量及应用程序组件失效 3）Windows Azure Queue数据模型 Queue服务定义了参数 （1）MessageID （2）VisibilityTimeout （3）PopReceipt （4）MessageTTL
Windows Azure应用场景
1．创建可伸缩的Web应 用
应用负载变化十分显著， 如在线售票系统、视频网 站 Windows Azure上创建 这类应用，组织机构可以 根据需要扩充和缩减实例 的数量。用户可以使用 Web Roles和Tables在 Windows Azure上创建一 个可伸缩的Web应用
Fabric控制器
Fabric控制器是一个分布式应用，拥有计算机、交换机、负载均衡 器等各种资源
Fabric控制器作用很广，它可以控制所有运行的应用
Fabric控制器在创建VMs后，还监控VMs
针对Web Role和Worker Role，Fabric控制器能够管理他们每个实 例中的操作系统，包括更新操作系统补丁和其他操作系统软件
IPsec连接
Windows Azure CDN
目的：提高访问性能 注意:Blob所存放容器都能够被标记为Private或Public READ
课件-4 第四章 软件开发过程 微软过程
必须调整项目进度的时候，项目组也应当遵照 严格的变更管理程序完成进度调整工作
点评：在具体制定项目进度表方面，借鉴AP的策略， 即制定一种细致度逐渐降低的进度计划以保持足够的 灵活性
4.3.1
MP的过程原则
7．使用小型项目组并发完成工作，并设 置多个同步点
微软公司的项目组善于将较大的项目分解成多个子 项目
微软开发过程与RUP、敏捷过程有何区别、有无共同点？
4.1 微软过程概述
微软解决方案框架
（Microsoft Solution Framework，MSF）
MSF的提出
微软顾问咨询部于1994年根据微软公司成功的产品开发经 验总结、设计而成的框架体系
MSF发展史
微软将公司内部的产品开发人员、顾问咨询人员以及微软 公司全球的客户和合作伙伴们在项目设计、开发和管理方 面经过实践检验、可重复、可借鉴的成功经验都集成到了 MSF之中
后冻结
产品冻结发生在项目过程后期的稳定和测试阶段，基线库中的配置项一经 冻结，就不能再随意更改，对配置项的冻结有利于与产品发布相关的工作
顺利进行
点评：冻结思想与AP不同，AP倡导即使到了开发的后期，也 欢迎改变需求
4.3.1
MP的过程原则
10．避免产品走形
检查和审视当前项目状态、产品特性是否和 产品的功能说明书相吻合 点评：对照而言，RUP中避免产品走形的方法 是用例驱动
比尔盖茨也经常参加重要产品的评审会
4.3.1
MP的过程原则
举例：
IE项目组没能及时推出IE的Beta2测试版，他们召开工作会议对这一情况进 行考察和讨论。在会上发现，大多数小项目组都按时完成了工作，只有一 个项目组例外，但是大家没有简单地责怪他们，而是一起帮助这个项目组 寻找工作延期的原因。后来发现，这个项目组无法按时完成开发工作的原 因是他们负责的产品特性比预计的要复杂得多，即使换了其它项目组也没 有办法在预定的时间里完成所有开发工作。找到了问题的根源之后，项目 组采取了相应的解决办法：为该项目组补充了人员，并砍掉了一些次要的 产品特性。这样一来，项目组就可以很好地完成产品开发工作了
软件过程与管理软件过程规范PPT课件
TSP工作流程 TSP-Team Soft Process
.
11
软件过程管理概述
5、项目估算和资源管理，项目风险管 理、项 目跟踪和监督
6、软件过程的评估和改进 7、软件过程的管理实践 8、最后通过具体的应用实践对软件过
程管理 做了全方位的阐释。
.
12
——James Harrington （美）如是说
软件生存周期过程示意图
软件生存周期过程
主过程
合 获取过程 同 供应过程
工 开发过程 程 维护过程
运 行
运行过程
支持过程
文档过程 配置管理 质量保证过程 验证过程 确认过程 联合评审过程 审计过程 问题 解决过程
辅助过程
基础设施过程 管理过程 培训过程
过程改进过程
ISO/IEC 12207 软件生存周期过程标准框架
.
15
课程目标
通过本课程的学习，可以了解并掌握：
软件过程规范的内容、影响和作用 软件过程不成熟的特点、软件过程成熟的标准 软件过程的可视性和过程能力 软件过程文化、环境和过程框架 如何定义组织过程并对过程剪裁以获得项目过程 软件过程的需求管理 、项目管理和质量管理 软件过程的技术管理和集成管理 如何实施软件过程的评估和改进
软 件 生 存 周 期 过 程
使用
获取过程
供应过程 合同视图 需方供方
使用
使用
管理过程
管理视图 管理者
支 使用 持
使用 使用 使用
运行过程
运行视图 运行管理者用户Βιβλιοθήκη 过使用使用
程 使用 维护过程 使用 开发过程 工程视图 开发者、维护者
文档 配置管理 问题解决 质量保证
验证 确认 联合评审 审计
.
11
软件过程管理概述
5、项目估算和资源管理，项目风险管 理、项 目跟踪和监督
6、软件过程的评估和改进 7、软件过程的管理实践 8、最后通过具体的应用实践对软件过
程管理 做了全方位的阐释。
.
12
——James Harrington （美）如是说
软件生存周期过程示意图
软件生存周期过程
主过程
合 获取过程 同 供应过程
工 开发过程 程 维护过程
运 行
运行过程
支持过程
文档过程 配置管理 质量保证过程 验证过程 确认过程 联合评审过程 审计过程 问题 解决过程
辅助过程
基础设施过程 管理过程 培训过程
过程改进过程
ISO/IEC 12207 软件生存周期过程标准框架
.
15
课程目标
通过本课程的学习，可以了解并掌握：
软件过程规范的内容、影响和作用 软件过程不成熟的特点、软件过程成熟的标准 软件过程的可视性和过程能力 软件过程文化、环境和过程框架 如何定义组织过程并对过程剪裁以获得项目过程 软件过程的需求管理 、项目管理和质量管理 软件过程的技术管理和集成管理 如何实施软件过程的评估和改进
软 件 生 存 周 期 过 程
使用
获取过程
供应过程 合同视图 需方供方
使用
使用
管理过程
管理视图 管理者
支 使用 持
使用 使用 使用
运行过程
运行视图 运行管理者用户Βιβλιοθήκη 过使用使用
程 使用 维护过程 使用 开发过程 工程视图 开发者、维护者
文档 配置管理 问题解决 质量保证
验证 确认 联合评审 审计
微软的软件开发过程课件
2. 组队模型 Team Model
2.2 组队模型的基本原则
7）分享产品的前景（shared project vision)
项目组内所有成员都应该对产品前景有清晰和明 确的认同
每一位成员都应该在产品前景的激励下努力工作 每一位成员都应该能为产品的美好前景贡献力量
而自豪
2. 组队模型 Team Model
2.4 组队模型中的项目组的六大工作目标
项目组的六大工作目标与六大角色的关系
提高客户满意度 增强产品的可用性 严格依据用户的业务需求和
产品功能说明书开发产品
--产品管理角色 --用户体验角色
--开发角色
在充分测试、定位了所有 已知问题的前提下发布产品
在有限的时间和资源条件下开发产品 做好产品的发布和后续的管理工作
微软的软件开发过程
-软件开发过程与案例
陈宏刚 熊明华 林斌 张高 张益肇 张亚勤
1.微软解决方案框架MSF
1.1 观点：技术不是项目成功与否的惟一 决定因素。
一个成功的IT项目中，开发人员、开发过程 以及风险管理等因素起着至关重要的作用。
预见性地、可持续地管理和控制项目风险 有效地进行协作和沟通 确保技术方案与商业需求的一致
在小型的、多元化的项目组中，交流成本、运营成 本、管理成本低，决策和执行速度快，产品发布周 期短，产品质量高。
2. 组队模型 Team Model
2.2 组队模型的基本原则
2）角色依赖和职责共享（interdependent roles and shared responsibilities)
在项目组内，每一个角色都对项目本身以及他们 各自的主管部门负责，以实现该角色的工作目标。 整个项目的各项工作职责通过对等团队的结构被项 目中不同的角色和成员共享，项目目标也通过不同 角色的工作目标得以实现。
微软的软件产品开发过程
产品部
技术部
产品 规划人员
产品 管理团队
软件 开发团队
软件 测试团队
四、微软的软件开发特点
管理上
(1) 文档齐全，项目规范清楚 (2) 开发人员相互阅读其他人新编写代码 (3) 所有代码都有清楚的注释
调试版本 (Dev)
产品版本 发布版本 (Ship)
软件开发第一阶段各团队分担的任务
团队名称
产品管理 项目管理 软件开发
400余篇
国际专利
微软专家 顾问委员会
潘云鹤校长
迟惠生校长 张钹 教授 Victor Zue 刘明雷先生 郑南宁副校长
现任院长 兼首席科学家 张亚勤博士 现任副院长： 张宏江博士 沈向洋博士
百余项 Windows XP Office XP
微软研究院的研究方向
微软研究院 的神圣使命 微软研究院的科研方向
Exchange 2000 中的人员结构 和Windows 2000
Exchange 2000 项目经理 开发人员 测试人员 25人 140人 350人
Windows 2000 约 250人 约1700人 约3200人
测试人员/开发人员
2.5
1.9
----- 微软现代软件开发的典型体系
软件研究院
测试
经理（Test Manager ）
Exchange Server 4.0 和 4.5 ， Internet Explorer 4.0 和 4.5，
参加过微软产品 Windows 95,
SQL Server 2000
的开发和测试
三、微软的产品团队
软件开发 项目管理
软件测试
互相沟通
产品管理 用户培训 后勤管理
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
首先编制单页功能说明书，它概要性的描述所有产品 特性的功能、性能及其在项目中的优先级，通常该说 明书占一页纸的篇幅，需要2到5天的时间就可以完成
在此基础上编制详细功能说明书，从技术细节上详细 描述如何实现所有的产品特性，该说明书占用的篇幅 较长，一般需要1～3个月的时间来编写
4.2 微软过程术语
MSF发展史
微软将公司内部的产品开发人员、顾问咨询人员以及微软 公司全球的客户和合作伙伴们在项目设计、开发和管理方 面经过实践检验、可重复、可借鉴的成功经验都集成到了 MSF之中
4.1 微软过程概述
MSF设计目的
帮助企业提升利用IT技术解决商务问题 的能力
为不同规模的组织结构和不同类型的IT 项目提供从项目组织规划和产品发布管 理的全方位的指导和帮助
使用组队模型和过程模型支持实现、操作和技术上的 方案
4.1 微软过程概述
微软过程（MP，Microsoft Process）
从MSF中抽取出项目开发准则中的过 程模型和组织模型 构成了一套软件过程模式
内容涵盖软件过程中的过程、人员及组织、方 法、产品等不同方面
4.2 微软过程术语
1．项目前景(Vision)与项目范围(Scope)
4.3.1 MP的过程原则
1Hale Waihona Puke 制定计划时兼顾未来的不确定因素任何项目都包含不确定因素，如
需求可能不断变化 技术可能不断变化 市场环境可能变化
考虑到未来可能发生的不确定因素
制定项目计划、进度表时，为不可预期的项目变更及项目风 险留出一定的余地
点评：这一原则与AP第4条价值观“响应变化胜 过遵循计划”异曲同工
未通过CMM认证，也未宣称使用过RUP或AP
微软有他自己的软件开发过程
其过程被几十年实践证实是非常成功且行之有效 微软开发过程与RUP、敏捷过程有何区别、有无共同点？
4.1 微软过程概述
微软解决方案框架
（Microsoft Solution Framework，MSF）
MSF的提出
微软顾问咨询部于1994年根据微软公司成功的产品开发经 验总结、设计而成的框架体系
每日生成制度（Daily Build）
在项目开发早期就会创建可以编译、生成的代码框架，并对每个项目组成员 的代码进行同步处理 每天，开发工作结束前，项目组成员都会将一天中对代码所做的修改检入到 版本库中 所有的代码检入操作之后都要生成一个完整地、可执行的产品版本，并对生 成结果进行快速测试——这种测试通常被称为“生成验证测试（Build Verification Test，BVT）” 当日的修改中可能出现的、影响到产品编译、连接的Bug就可以被及时发现 并及时排除，每天工作结束后，项目组总能提供一套可执行的过渡产品版本
点评：在最大程度上保证整个产品开发过程可管理、可预期，并能增强产 品的稳定性，类似AP的持续集成 Square-Cal3.0失败的主要原因
4.3.1 MP的过程原则
4．快速循环、递进的开发过程
要求项目组在开发过程中迅速完成每一次递进 过程，并在每一个开发周期中都能切实地增加 产品特性，提高产品质量 点评：和敏捷过程所强调的不断重复产品的生 命周期、以递进的方式推出版本的要求相似
是一套高效、灵活、可扩展的软件开发 管理体系
4.1 微软过程概述
MSF内容：框架结构的经验知识库
企业结构设计方案
采用交互的方式，侧重于制定长期规划，同时也能完成短期目标
项目开发准则
包括组队模型和过程模型，用于建立高效的项目组，管理项目组 的生命周期
应用程序模型
用于支持设计复杂的分布式企业应用
企业信息基础设施的实施方法
项目前景是对项目要解决什么问题的 开放性描述，它代表项目的远景目标
项目范围描述的则是在项目的限制条 件内，需要完成哪些具体的目标，这 主要是指所有特定的近期目标而言
4.2 微软过程术语
2．功能说明书
内容
功能说明书阐释了软件每一个特性的功能和执行方式，以 及所有特性的组合关系和整体架构
形式：包括单页和详细两种形式
4.3.1 MP的过程原则
2．通过有效的风险管理减少不确定 因素的影响
有效管理和控制不确定因素的最好方法—— 使用成熟的风险管理模型 点评：对照而言，RUP提出的风险管理方法为 在每次迭代中都要解决最突出的风险问题, 两者互补
4.3.1 MP的过程原则
3．经常生成过渡版本并进行快速测试来提高
产品的稳定性及可预测性
用途
可以与客户确认要开发的究竟是什么样的软件 是项目计划的标准和依据 可以告诉开发人员将要开发的是什么样的软件 是所有项目组成员同步各自工作的基石
4.2 微软过程术语
3．程序经理（Program Manager）
程序经理的职责是在规定的项目资源、期限等 限制条件下，确保产品能够如期发布，为此程序 经理需要制定和管理项目日程、费用预算、产品 特性说明书等文档，确保项目发起人的意图得到 落实，并负责推动产品开发过程顺利进行，确保 项目组可以在合适的时间交付合适的产品
第四章 微软过程
4.1 微软过程概述 4.2 微软过程术语 4.3 微软过程基本原则 4.4 微软过程特点——MP与AP、RUP 4.5 微软过程实施策略 4.6 微软过程案例——IE浏览器经典战役 4.7 本章小结
4.1 微软过程概述
微软的成功
世界上最大的、也是最成功的软件公司
产品涵盖编程工具（如VC、VB、.NET）、操作系统（如 Windows、WindowCE）、数据库（如SQL Server）、网络 产品（如IE、MSN）、办公产品（如Office）等多个领域
4.3.1 MP的过程原则
5．从产品特性和成本控制出发创造 性地工作
时刻关注产品特性的开发和项目资源的控 制之间的平衡
因为任何商业软件开发项目的最终目标都是以有限的成本实 现所有客户需要的产品特性
程序经理不同于传统的项目经理
在微软的团队组织结构中，六个组队角色的地位是相互平 行、相辅相成，程序经理只是项目开发过程的组织者、管 理者和决策者，不是项目的领导者
4.3 微软过程基本原则
从MSF的立场观点，论述MP 过程原则 组队原则
4.3 微软过程基本原则
MP的过程原则 MP的组队原则
在此基础上编制详细功能说明书，从技术细节上详细 描述如何实现所有的产品特性，该说明书占用的篇幅 较长，一般需要1～3个月的时间来编写
4.2 微软过程术语
MSF发展史
微软将公司内部的产品开发人员、顾问咨询人员以及微软 公司全球的客户和合作伙伴们在项目设计、开发和管理方 面经过实践检验、可重复、可借鉴的成功经验都集成到了 MSF之中
4.1 微软过程概述
MSF设计目的
帮助企业提升利用IT技术解决商务问题 的能力
为不同规模的组织结构和不同类型的IT 项目提供从项目组织规划和产品发布管 理的全方位的指导和帮助
使用组队模型和过程模型支持实现、操作和技术上的 方案
4.1 微软过程概述
微软过程（MP，Microsoft Process）
从MSF中抽取出项目开发准则中的过 程模型和组织模型 构成了一套软件过程模式
内容涵盖软件过程中的过程、人员及组织、方 法、产品等不同方面
4.2 微软过程术语
1．项目前景(Vision)与项目范围(Scope)
4.3.1 MP的过程原则
1Hale Waihona Puke 制定计划时兼顾未来的不确定因素任何项目都包含不确定因素，如
需求可能不断变化 技术可能不断变化 市场环境可能变化
考虑到未来可能发生的不确定因素
制定项目计划、进度表时，为不可预期的项目变更及项目风 险留出一定的余地
点评：这一原则与AP第4条价值观“响应变化胜 过遵循计划”异曲同工
未通过CMM认证，也未宣称使用过RUP或AP
微软有他自己的软件开发过程
其过程被几十年实践证实是非常成功且行之有效 微软开发过程与RUP、敏捷过程有何区别、有无共同点？
4.1 微软过程概述
微软解决方案框架
（Microsoft Solution Framework，MSF）
MSF的提出
微软顾问咨询部于1994年根据微软公司成功的产品开发经 验总结、设计而成的框架体系
每日生成制度（Daily Build）
在项目开发早期就会创建可以编译、生成的代码框架，并对每个项目组成员 的代码进行同步处理 每天，开发工作结束前，项目组成员都会将一天中对代码所做的修改检入到 版本库中 所有的代码检入操作之后都要生成一个完整地、可执行的产品版本，并对生 成结果进行快速测试——这种测试通常被称为“生成验证测试（Build Verification Test，BVT）” 当日的修改中可能出现的、影响到产品编译、连接的Bug就可以被及时发现 并及时排除，每天工作结束后，项目组总能提供一套可执行的过渡产品版本
点评：在最大程度上保证整个产品开发过程可管理、可预期，并能增强产 品的稳定性，类似AP的持续集成 Square-Cal3.0失败的主要原因
4.3.1 MP的过程原则
4．快速循环、递进的开发过程
要求项目组在开发过程中迅速完成每一次递进 过程，并在每一个开发周期中都能切实地增加 产品特性，提高产品质量 点评：和敏捷过程所强调的不断重复产品的生 命周期、以递进的方式推出版本的要求相似
是一套高效、灵活、可扩展的软件开发 管理体系
4.1 微软过程概述
MSF内容：框架结构的经验知识库
企业结构设计方案
采用交互的方式，侧重于制定长期规划，同时也能完成短期目标
项目开发准则
包括组队模型和过程模型，用于建立高效的项目组，管理项目组 的生命周期
应用程序模型
用于支持设计复杂的分布式企业应用
企业信息基础设施的实施方法
项目前景是对项目要解决什么问题的 开放性描述，它代表项目的远景目标
项目范围描述的则是在项目的限制条 件内，需要完成哪些具体的目标，这 主要是指所有特定的近期目标而言
4.2 微软过程术语
2．功能说明书
内容
功能说明书阐释了软件每一个特性的功能和执行方式，以 及所有特性的组合关系和整体架构
形式：包括单页和详细两种形式
4.3.1 MP的过程原则
2．通过有效的风险管理减少不确定 因素的影响
有效管理和控制不确定因素的最好方法—— 使用成熟的风险管理模型 点评：对照而言，RUP提出的风险管理方法为 在每次迭代中都要解决最突出的风险问题, 两者互补
4.3.1 MP的过程原则
3．经常生成过渡版本并进行快速测试来提高
产品的稳定性及可预测性
用途
可以与客户确认要开发的究竟是什么样的软件 是项目计划的标准和依据 可以告诉开发人员将要开发的是什么样的软件 是所有项目组成员同步各自工作的基石
4.2 微软过程术语
3．程序经理（Program Manager）
程序经理的职责是在规定的项目资源、期限等 限制条件下，确保产品能够如期发布，为此程序 经理需要制定和管理项目日程、费用预算、产品 特性说明书等文档，确保项目发起人的意图得到 落实，并负责推动产品开发过程顺利进行，确保 项目组可以在合适的时间交付合适的产品
第四章 微软过程
4.1 微软过程概述 4.2 微软过程术语 4.3 微软过程基本原则 4.4 微软过程特点——MP与AP、RUP 4.5 微软过程实施策略 4.6 微软过程案例——IE浏览器经典战役 4.7 本章小结
4.1 微软过程概述
微软的成功
世界上最大的、也是最成功的软件公司
产品涵盖编程工具（如VC、VB、.NET）、操作系统（如 Windows、WindowCE）、数据库（如SQL Server）、网络 产品（如IE、MSN）、办公产品（如Office）等多个领域
4.3.1 MP的过程原则
5．从产品特性和成本控制出发创造 性地工作
时刻关注产品特性的开发和项目资源的控 制之间的平衡
因为任何商业软件开发项目的最终目标都是以有限的成本实 现所有客户需要的产品特性
程序经理不同于传统的项目经理
在微软的团队组织结构中，六个组队角色的地位是相互平 行、相辅相成，程序经理只是项目开发过程的组织者、管 理者和决策者，不是项目的领导者
4.3 微软过程基本原则
从MSF的立场观点，论述MP 过程原则 组队原则
4.3 微软过程基本原则
MP的过程原则 MP的组队原则