开发
当分工明确、任务明确、工期限定以后，产品的设计与开发工作正式开
始。微软的软件设计和开发没有清晰的阶段划分，即，边设计，边开发。这时，产品功
能说明书及其它设计文档已经编成，但仍然处在修改阶段。在开发进行到一定阶段后，
当感觉产品特性需要冻结时，则进入开发后期，即产品特性稳定阶段，在此以前，可以
看作前期开发阶段。当产品发布以后，进入总结阶段。
1.1 前期开发阶段这个阶段主要任务是设计、开发产品特性，在开发工程中细
化、修订、更新、增减、实现产品特性，并修改相关文档。开发工程师编码，测试工程
师测试，程序经理管理进度和产品特性的增减。当特性冻结以后，该阶段结束。
1.1.1 安装、配置环境
进入开发阶段，首先要安装配置开发、测试、管理使用的计算机软硬件环境。包括pc机
和服务器的分配，操作系统、数据库、开发工具、调试工具及其他常用的工具软件的安
装。另外，开发工程师还要配置源代码的目录结构，制定
检入制度和进度表。
测试工程师则要准备编译、生成用的计算机和服务器，制定生成计划，安装配置Bug数据
库。
程序经理则要安装配置项目组网站，定义项目组的邮箱（Team alias），制定项目会议
计划。
1.2 日常开发工作日常开发工作每日的主要产品是源码和文档。微软怎样管理这
些产品呢？
1.2.1
代码检入（Check-In）
IE开发团队使用一个统一的数据库来管理每日生成的源码和文档产品。每天开发结束
后，开发工程师要把新开发的代码送入产品代码库，这个过程叫做
代码检入。
检入前，开发工程师首先要在自己的计算机上同步新代码。以保证自己新编
的代码与其它开发人员开发的代码不发生冲突。
然后，交给另一名有经验的程序员阅读审查，该审查能够减少大约60%的
Bug。
新代码还要通过BAT、BVT等最低测试。
再然后，在规定的时间段检入自己的新代码。大型项目组一般规定不同功能
的开发人员在不同的时间段检入代码，这样，当产品生成失败后容易定位Bug的位置。
检入后，发送检入邮件通知整个项目组，告知代码已经变更，邮件中还包含
代码变更的目的、代码审查员、修改过的文件和测试条件等内容。
1.2.2 每日生成（Daily Build）
每日生成是指，每天在固定的时间，在所有新检入代码基础上编译并生成完整的新的可
执行版本。这是微软最重要的开发制度之一。其过程如下：
每天在同一时间同步所有检入的代码，生成一个新的源代码树拷贝。
编译链接生成新的可执行代码。
运行BAT、BVT测试，检验生成版本的可用性。
向开发团队发送每日生成状态邮件和同步日志。
在公共服务器上公布生成后的新产品版本。
上述过程都是自动完成的。
1.2.3 管理bug库
测试工程师创建、更新和管理一个集中的产品Bug库，产品Bug包括代码缺陷和不完善的
产品特性。Bug库更新过程如下：
测试工程师每日把测试获取的Bug送入Bug库
程序经理每天浏览Bug库，并为开发人员分配修改任务。
开发工程师修改Bug，并将结果发回给测试人员。
测试人员使用每日生成来检验Bug是否已经修改，如该Bug已经更改，则关闭
该项Bug。
1.2.4 特性的更新
在开发前期，产品的特性并不是固定的。产品特性的变化包括：
已有产品特性的细化。这是正常的开发结果。
特性的变异。即在开发过程中发现原来的设想不十分恰当，需要做适当的调
整。
新增加特性。当市场竞争对手推出一个富有竞争力的新特性，或关键客户需
要一个新特性，或开发团队在开发过程中确认需要增加一个新特性，等等。
需要放弃的特性。在开发过程中发现该特性不可能实现；或其它特性或特性
的组合可以代替；或市场反馈不需要该特性等等。
特性级别的变更。在开发过程中发现该特性实现难度大，在本次版本中可能
实现不了；或用户要求强烈，必须首先完成；或该特性是另外特性的基础，需要提前完
成，等等。
特性的变化不是随意的，需要经过一定的程序和审批。当审批通过后，相关文档要做相
应的调整。
1.2.5 相互交流
软件开发过程需要交流。交流的内容包括对产品特性的看法，对源码的看法，对进度的
看法等等。交流的方式也是多方面的，包括电子邮件、会议和当面交流。微软提倡当面
交流，并认为当面交流效果能明显提高生产率；交流最为频繁的是开发与测试工程师派
对。
1.3 产品特性稳定阶段1.3.1 特性冻结
当开发进行到一定阶段，产品的特性必须冻结，即在本次版本开发中，现有的产品特性
不能再更改，除非出现非常大的更改理由。即使万一需要更改，也必须通过严格的审批
程序。
因为如果产品的特性不冻结，开发工作就会无休止的进行下去，产品的发布也会遥遥无
期。但是，过早的冻结特性，会导致产品出现过多的先天缺陷，也可能导致开发失败。
所以，微软的开发原则是，早基线，晚冻结。
1.3.2 代码完成
当特性冻结以后，开发人员需要完成代码的最后编写工作。当所有的特性代码完成以
后，并检入到代码库中，则进入代码完成阶段。
在代码完成阶段，测试人员做系统集成测试；程序经理每天关注、评审Bug，并监控和分
配修改任务；开发人员每天的任务是修改Bug。
1.3.3 界面冻结
当代码完成后，经过讨论，和一定的审批通过，用户界面开始冻结。用户界面冻结后，
用户培训师开始完善联机帮助和用户手册。本地化工作开始。
1.3.4 Beta版本发布
当界面冻结、基本的集成测试通过后，可以发布Beta版本。Beta版本是提供给外部主要
用户和合作伙伴的产品版本。该版本已经具有产品的基本特性和功能。发布Beta版本可
以推动合作伙伴的项目进展，更好地收集客户的反馈信息，进一步扩大产品的测试平台
和测试队伍。
1.3.5 正式发布
当Beta版本发布后，开发团队完成用户主要的反馈信息处理工作，开发人员完成所有必
需修改的Bug修改工作，则开发工作到达0Bug阶段，这时可以向社会发布产品。
产品发布以后，开发团队应在24小时修正新发现的重大Bug；修改完成后，将发布一个新
的候选版本。这时，产品特性的变更审批将更为严格。
IE4.0发布后，在14天内不断发现新的重大Bug，开发团队及时修改并发布新的版本，从
RC0、一直到RC14，才得到一个相对稳定的候选版本。
发布的方式有两种，一种为盒装产品发布，一种是基于Web的发布。只有修正了所有重大
Bug，测试人员才会签字发布新的发布版本。签字后，如发现新的重大bug，则需要从生
产线上“召回”正在生产的产品，召回工作必须经过总经理或主管副总裁的签字同意。
当测试人员签字同意发布后，程序经理也要签字确认。
1.4 总结阶段当产品发布稳定以后，由程序经理负责召集项目组的总结会。会
上，每个人准备一份总结报告，并在会上发言。其目的是认真总结工作得失。
在小型会议的基础上还要召开产品部门的大型会议。其目的是改进开发过程，提高开发
水平。
会议结束前，每人都要提出行动计划，以便在今后的开发过程提高开发和管理水平。
1.5 讨论题a 在IE的开发过程中为什么要冻结产品特性？产品特性冻结后还能不
能再更改？
b IE开发中主要的日常工作有哪些？
c 在IE开发阶段，开发人员、测试人员和程序经理的主要工作是什么？
d 在IE开发阶段，设计工作是否结束？
e 为什么要发布Beta版本？
f 正式发布以后，产品还有Bug码？
g 产品发布以后，召开总结会有何意义？