+

微软的软件测试报告及文档的编写

Path: localhost!not-for-mail
From: "吕布" <[e-mail]>
Newsgroups: CCU.Programming.Engineering
Subject: : 微软公司软件开发模式简介
Date: Tue, 31 Aug 1999 13:29:04 +0800
Organization: ChinaCode TianJin Main Site
Lines: 614
Message-ID: <7qfpfc$hh6$[e-mail]>
Reply-To: "吕布" <[e-mail]>
NNTP-Posting-Host: 202.130.3.250
X-Trace: chinacode.online.tj.cn 936077612 17958 202.130.3.250 (31 Aug 1999 05:33:32 GMT)
X-Complaints-To: [e-mail]
NNTP-Posting-Date: 31 Aug 1999 05:33:32 GMT
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Xref: localhost CCU.Programming.Engineering:16


社区服务： 查询网友  寻呼台  传纸条  个人订阅  进站画面  资料配置


标 题共1篇    讨论区: SystemAnalysis[ 系统分析]

[首] [尾]  返回

----------------------------------------------------------------------------
----
  作 者: hyenachenyao (BlueHyena) 1999.08.27 转贴 打包 回复
--摘自北京大学出版社出版的《微软的秘密》一书

北京大学出版社96年底所出的《微软的秘密》一书是目前我所见到的对微软公司
软件
产品开发过程介绍的最专业、最深入的一本书。通过本书，我们可以看到微软公
司是
如何对科学地对软件产品开发进行有效地管理，我想这些经验对于中国的广大软
件开
发人员，尤其是关心中国软件产业发展的各位朋友是大有益处的。所以特将此书
中涉
及软件产品开发的部分内容摘录出来(第四章"产品定义与开发过程")，与大家共
同
分享。本文作为摘录，自然是挂一漏万，所以建议大家若有时间还是找来原书一
读。

在产品定义与开发过程中，微软件遵循着一种可称之为"靠改进特性与固定资源来
激
发创造力"的战略。该战略可分为五个原则：

一、 将大项目分成若干里程碑式的重要阶段，各阶段之间有缓冲时间，但不进行
单独
的产品维护。

　　二、运用想象描述和对特性的概要说明指导项目。

　　三、根据用户行为和有关用户的资料确定产品特性及其优先顺序。

　　四、建立模块化的和水平式的设计结构，并使项目结构反蚋产品结构的特点
。

　　五、靠个人负责和固定项目资源实施控制。

原则一：将大项目分成若干里程碑式的重要阶段，各阶段之间有缓冲时间，但不
进行单独
的产品维护。

　　项目进度安排与里程碑

微软通常采用"同步－稳定产品开发法"。典型项目的生命周期包括三个阶段：计
划阶
段完成功能的说明和进度表的最后制定，开发阶段写出完整的的源代码，稳定化
阶段
完成产品，使之能够批量生产。这三个大阶段以及阶段间内在的循环方法与传统
的"瀑
布"式开发方式很不相同，后者是由需求、详尽设计、模块化的代码设计与测试、
集
成测试以及系统测试组成的。而微软的三个阶段更像是风险驱动的、渐进的"螺旋
"
式的生命周期模型。

计划阶段的产品是想象性描述与说明文件，用来解释项目将做什么和息么做。在
管理
人员拟定进度表、开发员写出代码之前，这些东西都促进了人们对设计问题的思
考与。
讨论开发阶段围绕三次主要的内部产品发布来进行；称定化阶段集中于广泛的内
部与
外部测试。在整个产品生产周期中，微软都使用了缓冲时间的概念。缓冲时间使
开发
组能够对付意外的困难和影响到时间进度的变故，它也提供了一种手段，可以缓
和及
时发货与试图精确估计发货时间之间的矛盾。

在开发和稳定化阶段的所有时间中，一个项目通常会将2/3的时间用于开发，1/3
的时
间用于稳定化。(Office部门副总裁曾这样概述通常的进度："一般说来，在总的
进度
表中，用一半的时间写出产品，留下另一半的时间调试或应付意外事故。这样，
如果
我有一个两年的项目，我会用一年来完成事先想好的东西……如果事情有点麻烦
，我
便去掉我认为不太重要的特性。")这种里程碑式的工作过程使微软的经理们可以
清楚
地了解产品开发过程进行到了哪一步，也使他们在开发阶段的后期有能力灵活地
删去
一些产品特性以满足发货时期的要求。

　　计划阶段

计划阶段是在一个项目的生命周期中，所有于开发前进行的计划所占用的时间。
计划
阶段产生出想象性描述、市场营销计划、设计目标、一份最初的产品说明、为集
成其
他组开发的构件而规定的接口标准、最初的测试计划、一个文档策划(印刷品和联
机帮
助形式的)以及一份可用性问题清单。计划阶段从想象性描述开始。想象性描述来
自产
品经理以及各产品单位的程序经理；它是对产品作业的市场营销设想，包括了对
况争
对手产品的分析以及对示来版本的规划。想象性描述也可能讨论在前一次版本中
发现
面必须解决的问题以及应添加的生要功能。所有这些都基于对顾客和市场的分析
以及
从产品支持服务组处得到的资料。

说明文件从一个大纲开始，然后定义出新的或增加的产品特性，并对其赋以不同
的优
先级。说明文件只是产品特性的一个预备性概览；从开始开发到项目完成它要增
加或
变化20% - 30%。虽然在生命周期的后期说明变化一般较小，但越到后期，开发员
就
越是必须具充分的理由来作改变。


通常程序经理使用VB创建项目原型。他们也开展设计可行性研究以了解设计中的
取
舍情况，尽快做出涉及产品说明的决定。

对于重要产品的说明需由公司高层领导进行复审。对于不太生要的产品，则由部
分经
理去完成。

　　开发阶段

开发阶段的计划对三四个主要的里程碑版本都个咖分配一组特性，规定出特性的
细节
和技术上的相关性，记录下单个开发员的任务以及对进度的估计。在开发阶段中
，开
发员在功能性说明的指导下写源代码，测试员写出测试项目组以栓查产品的特性
与工
作范围是否正常，用户教育人员则编写出文档草案。

当测试员发现错误时，开发员并不是留待以后处理，而是马上改正，并在整个开
发阶
段内使测试不断地、自动地进行。这就改善了产品的稳定性并且使版本发布日期
更易
估计。当达到项目中的一定阶段点后(40%时)，开发员就试图"锁定"产品的主要功
能
要求或特性，从此只允许小的改动。如果在此点之后开发员想作大的改动，他们
必须
与程序经理以及开发经理，问题也许还要征求产品部门经理的意见。

一个项目是围绕着3或4个主要的内部版本，或"里程碑子项目"来组织开发阶段的
。
一般用2至4个月来开发每一个主要的里程碑版本。每个版本都包括其自身的编码
、
优化、测试以及调试活动。项目为意外事故保留总开发1/3的时间，即"缓冲时间
"。
(苹果公司的小组是割裂的，独立的，各自开发各自的东西。在还有3个月就要发
货时，
才会将所有的东西集成起来；Boland公司以一种渐近的方式进行开发，即把工作
分成
许多小的部分，并且总是让开发的东西能够运转。看起来似乎这种渐进的方法费
时较
长，但实际上几护没有用过很长时间，因为这使你总是能掌握住事情真实的情况
。)


当对最后一个主要的里程碑版本做了测试与稳定化之后，产品就要进行"外观固定
"，
即确定产品的主要用户界面，如菜单、对话框以及文件窗口等。此后有关用户界
面将
不再进行大的改动，以免引进同步修改相应文档的困难。

　　稳定化阶段

稳定化阶段着重于对产品的测试与调试。项目在此阶段尽量不再增加新的功能，
除非
是竞争产品或者市场发生了变化。稳定化阶段也包括了缓冲时间，以应付不可预
见的
问题或者延迟。

　　项目进度表中的缓冲时间

微软使用缓冲计划，以在最高的效率与较好地对未来作预计之间求得平衡。这种
应付
突发事件的时间在开发和稳定化过程中是每一个主要里程碑的一部分。缓冲时间
主要
用于弥补由于对特性的不完全理解，或者是技术困难或是由于疏忽而忘记把任务
写入
进度，或者是未料到的难题而形成的漏洞。缓冲时间有助于一个项目适应意料之
外的
事件。

原则二：运用想象性描述和对特性的概要说明指导项目

为了给出足够的开发框架以使工作能持续进行，并且能容纳开发过程中出现的变
化并
保持足够的灵活性，微软采用想象性描述和概要的说明来指导项目开发，而不是
在一
开始就努力写出一份完整和详细的说明。所谓想象性描述是由程序经理和来自市
场营
销组的产品计划人员共同编写的一份非常短的文件，在其中主要是定义产品开发
的目
标(不涉及产品的具体细节！)。通常对一个全新的产品，想象性描述一般会相对
较详
细，在其中还含有一份粗略的说明文件。总的来说，微软对于想象性描述的要求
是：
越短越好，尽量说明"产品不做什么"(而不是"产品要做什么"！)。

运用想象性描述，程序经理开始编写功能说明文件，该文件解释产品的特性是什
么以
及这些特性如何与其他特性及产品发生关系。最初它只是一个概要性的说明文件
，随
着项目的进展，程序经理会随时向其中添加更多的细节，最终的说明文件将变得
象用
户手册一样。完整的说明不只起着对产品最新功能的描述作用，而且它还是在产
品投
产与发货之前进行测试与评估的主要依据。

　　想象性描述有助于决定删除哪些特性

微软内的各个开发组采用想象性描述帮助细化产品版本的规定主题，然后以此主
题来
决定是否需要增加产品各个可能的特性。通常不要轻易改变所确定的主题，否则
可能
造成产品开发上的混乱。

　　编写说明文件

说明文件在产品小组的所有成员之间，产品小组之间以及产品小组与管理部门之
间起
着传递产品的设想与要求的作用。在说明文件中必须清楚地描述产品特性(描述每
个特
性如何工作，外观如何以及从用户的角度出发如何与用户交互。如果特性有一个
界面，
还应包括一张示意图，以显示出界面的效果)并赋于其相应的优先级。程序经理据
此建
立起项目的开发起度表。此外在其中还应包括以下各项内容：用一句话表示的项
目开
发目的，关于产品是什么与不是什么的清单，对顾客的定义，对竞争产品的定义
，产
品对系统的要求(包括操作系统版本、最小内存要求、硬盘空间、处理器速度以及
显示
器分辩率)，对第三方(如打印机驱动程序、组件)的任何依赖性。