开发
当分工明确、任务明确、工期限定以后,产品的设计与开发工作正式开
始。微软的软件设计和开发没有清晰的阶段划分,即,边设计,边开发。这时,产品功
能说明书及其它设计文档已经编成,但仍然处在修改阶段。在开发进行到一定阶段后,
当感觉产品特性需要冻结时,则进入开发后期,即产品特性稳定阶段,在此以前,可以
看作前期开发阶段。当产品发布以后,进入总结阶段。
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 产品发布以后,召开总结会有何意义?