软件开发一直以来都被认为是一项很控制的过程. 为了一如既往地开发出好的软件,你需要经过长期的学习, 有关如何改进开发过程的书籍也是层出不穷, 但是至今也没有什么特别有效的好的方法可以降低此过程的复杂性. 问题的关键在于开发人员很难将这些方法由始至终地运用在软件开发的实际过程中. 采用人工管理的方法, 开发人员在不自觉中就偏离了原有的理论, 或者由于害怕麻烦而忽略了其中的一些步骤. 所以拥有一套能够很好地管理软件开发全生命周期的工具,将有利于在软件开发的过程中严格的遵守相应的软件开发方法学,为我们带来有效的开发管理过程, 从而开发出强健的软件产品.
微软为我们带来了他的全生命周期管理工具Visual Studio® 2005 Team System,旨在改善软件开发方法在实际开发过程中的有效实施.VSTS扩展了Visual Studio 2005的功能,提供了新的源代码管理工具, 同时还为开发者提供了单元测试工具和代码分析工具. 不过VSTS 这次并不是将焦点全放在开发者身上, 它还提供了一系列支持整个开发团队的工具. VSTS为项目经理, 架构师, 开发者, 测试人员甚至开发经理都提供了相应的支持工具. VSTS提供了一套追踪软件开发过程的任务管理工具, 为了使整个团队的软件开发的过程能够清晰可见,VSTS还提供了自动生成项目门户网站(Web Portal)的工具.
Project Methodology
在过去, Visual Studio仅仅是开发者的工具. 因此它对软件开发的其他过程,比如需求分析,设计,测试等等几乎没有提供什么支持. Visual Studio® 2005 Team System将不再仅仅是开发者的玩具, 它将在软件开发的全生命周期中发挥作用, 并为该生命周期所涉及到的所有人提供相应的支持工具.
Visual Studio® 2005 Team System最重要的一个特性就是它对过程的理解,所谓的理解就是它能知道目前你所属的开发阶段, 以及你下一步所需要做的事情. 如何支持该功能? VSTS的优点就在于它并没有将此过程定死, 而是提供了一个方法学的模板, 你可以通过定制这个模板来改变整个开发流程的走向. 这样你就可以开发出自己的模板, 使用VSTS随带的默认模板,甚至是第三方的模板比如最近流行的XP方法.
由于定义正式的软件开发过程需要投入大量的精力和财力, 很多公司可能并没有一个很正规的开发过程, 然而当你拥有了VSTS之后, 软件开发过程的将伴随在你每天的开发中, 这时软件开发过程将不再是高高在上的理论, 每一个参与开发的人都将真实的感受到它的存在, 以及它带来的效率,软件开发过程的概念也将被更多的团队所乐于接受.
微软目前建立有它自己的一套软件开发方法the Microsoft® Solutions Framework (MSF).目前它的版本是3.0. MSF并没有广泛被采用甚至是在微软内部, 究其原因大概就是它看上去太复杂,不方便学习和使用. 目前微软正在将其升级为MSF4.0, 并伴随VSTS作为其中的方法学模板一起发布. 在VSTS中将有两个版本的MSF, 一个是MSF Fomal(MSF for CMMI Process Improvement)另一个是MSF Agile(MSF for Agile Software Development). 前者相当于CMMI 3级的标准.本文将主要围绕后者的功能展开. 并应用到后者所支持的下面5个角色: Architect, Business Analyst, Developer, Project Manager, and Tester.
不难想象在VSTS发布之后, 很多公司会将自己开发方法移植到VSTS上, 或者直接使用VSTS自带的两个模板.
当然不是所有的开发过程中的成员都会拥有Visual Studio, VSTS还提供了两种访问的方法,一种是通过项目的门户,这意味着访问者将不需安装任何软件,只需拥有一个上网的工具例如IE.就可以访问到相应的文档, 并查看到项目的进展情况等等信息. 另一个方法就是通过Team Foundation Client这个工具.该工具就是将Visual Studio中所有有关开发的功能去掉后,而保留所有和VSTS有关功能的一个精简版的Visual Studio. 毕竟对于非开发者来说那些功能是没必要花钱购买的.
Creating a Team Project
目前有关的背景介绍已经足够多了.让我们从一个叫portfolio的项目(该项目将包含在下一个版本的VSTS)来开始我们的软件开发过程. 在启动Visual Studio2005之后, 你首先需要连接Team Foundation Server (TFS), 它可能运行在某个其他机器上或者虚拟机上. TFS是VSTS的服务器的平台, 它提供了VSTS的很多重要功能.,比如新的源代码管理工具, 任务跟踪管理以及团队门户网站.
连接成功以后你将看到Team Exlporer窗口, 这个窗口将频繁使用到, 以后你会对它很熟悉.
此时你可以建立你的Team Project, 这是TFS的主要功能之一. 通过Team Project你可以访问到所有与项目相关的资源,如设计文档,工作任务项(Work Item),项目计划. 每建立一个开发项目就需要建立相应的Team Project.
在Team Exlporer窗口下, 点击"New Team Project" 工具栏按钮,选择相应的方法学模板.(如图1)此时,你还可以为你的项目设置源代码存放的文件夹,或者从已有的源代码库中拉一个分枝.( branching an existing code base.) 在本例中,使用MSF Agile模板.
图1 创建新的Team Project
在你建立新的Team Project的过程中, 在后台做了很多工作. 其中非常重要的一项就是利用Windows SharePoint® Services (WSS)建立了你的团队的项目门户网站. TFS集成了WSS用于提供许多有关文档管理的功能. 此时打开浏览器输入http://tfsserver/sites/project 就会出现TFS自动生成的项目首页, 这是一个WSS站点, 可以被任何具有相应权限的人访问相应的资源. 通过这个网站, 软件的交付用户和软件开发的管理者可以很容易的了解项目的一些情况.
当你建好一个Team Project之后, 首先会想到去对它进行一些配置. 在Team Exlporer窗口,右键点击项目选择Team Project Settings | Classifications. 在设置菜单中你可以设置有关安全权限,源代码管理策略以及项目的组织结构. 如果你选择的是MSF Agiel将默认有三个迭代过程.你可以对它进行添加,修改以及删除. 随后你可以建立相应的工作项,并把他们和特定的迭代周期绑定. 记住一点, 方法学的模板可以完全由你定制, 你不必受到它的约束.
Project Plans and Work Items
在VSTS中有很多很cool的功能, 相比单元测试, 源代码管理, 代码分析这些另开发者很感兴趣的功能, 任务追踪(Work Item Tracing)的功能则更吸引项目经理这类管理性的人员.
软件开发过程中的所有活动都被设计成一个个的Work Item,其中包括文档任务,设计任务,开发任务,bugs,需求. 这时你可能会想到你以往已经使用 Microsoft Project设置Excel来管理追踪这些任务. 但是大部分的开发人员仅仅是使用某种工具建立的一系列的任务来并没有在实际的开发过程中追踪和管理它们.
试想下面这些问题:
设计文档是否完成? 某个开发人员被分配了多少任务?哪些任务已经完成?下一步的任务是什么?哪个任务不能及时完成对项目的影响最大?
可能有不少公司回答不出来,当然也有相当多的公司可以回答出.但是这个答案可能需要项目经理和其他的众多的项目参与人员进行大量的交流才能得出. 并且项目经理需要向很多不同的人汇报项目各个方面的情况. 这些过程在以前往往是通过项目会议, 单独的交流以及e-mail来进行的, 必然会耗费大量的精力, 而通过VSTS的Work Item Tracing, 这些工作将贯彻在整个开发的过程中. 你可以随时轻松地查看任意有关的项目信息, 并且这些信息还是实时的.
一旦你选择了相应地开发方法学模板, VSTS就会根据模板地内容自动地建立好一些任务(Work Item). 因为每种开发方法其中必然包含了一系列特定地任务.图2中你可以看到MSF默认建立的一些任务.
图2 MSF中的任务
Work Item和Microsoft Project 中的Task的概念很像, 它可以被分配到某个人, 拥有状态以及持续时间等等属性. 当某个开发人员完成了相应的任务就会将该任务的状态标记为完成.
并且这些变化会及时体现在VSTS以及项目的网站上. WSS还会利用SQL Server™ Reporting Services 的功能为我们提供有关项目信息的各种各样的报表,并且你还可以自定义报表的格式.
Project Documentation
在MSF的开发方法中开始的一个步骤就是编写项目文档. 根据你所处的项目开发阶段, 会要求你开发不同的文档,比如一个business case, 一个场景 scenario, 甚至项目计划书. 创建哪些文档将由你采用的开发方法决定.你可以使用Team Explorer,在VSTS的环境下创建这些文档.(你也可以通过项目网站创建文档).在Team Explorer中选择Document节点, 点击右键你将可以选择Add a Document菜单., 这时将会根据你选择的开发方法出现一系列的文档类型供你选择. 当你选择了某个特定文档, VSTS将会打开在Word(Excel)中打开相应的文档, 这些文档已经提供了原始的框架, 你只需填写必要的项就可以了. 你所建立的文档将被保存在WSS中并由它管理, 这样在你公司与该项目的相关人员只需通过浏览器就可以访问到相应的文档. 当然添加到WSS的文档也会出现在Team Explorer的窗口中.你所要做的就是右键点击Document节点选择刷新菜单.
由于VSTS对Work Item Tracing的良好支持,使得项目计划的编写显得很有意义也更加有趣.
使用VSTS建立项目计划很简单,你只需在Team Explorer窗口中选择Documents | Project Management然后点击右键,将会出现一个上下文菜单其中包含了Create Microsoft Project Plan的选项. VSTS同样也支持使用Excel创建项目计划.方法和上面的差不多.
VSTS对Microsoft Project 以及 Excel提供了新的扩展,当你在安装完VSTS后, 你会发现在Microsoft Project 和 Excel多出了新的菜单和工具栏, 主要用于和VSTS同步.
创建项目计划和导入已有的Work Item(原来在MS Project中的)是创建Team Project的一个部分, 然后你可以在VSTS中添加并分配新的任务,这些修改都将同步保存在项目的数据库中.当开发人员完成任务并签入代码的时候,他们可以通过Visual Studio更新任务的状态(比如更新为完成).这些更新也会被保存在数据库中. 项目的网站也会从数据库中得到最新的有关任务的状态.并生成报表. 项目经理当然也可以通过MS Project从数据库中得到最新的任务状态情况.
图3显示了MS Project从VSTS中导入的Work Item被显示为Task. 并且你会注意到一个新的用于和Team Foundation Server同步的工具栏. 这样原来习惯使用MS Projec的用户可以继续使用MS Projec来完成项目的部分管理而不用每时每刻都使用VSTS.
图3 向MS Project加载Work Item
一旦项目计划完成. 开发人员就可以在Visual Studio中Team Explorer窗口中的My Work Items中查看到分配给自己的任务, 这个过程甚至不需要开发者离开Visual Studio窗口, 而不再象以往那样需要通过开会或者邮件才能知道自己的任务.
Design Your Application
就开发者而言,一旦被分配了任务,下一步就是设计以及编码,幸运的是VSTS提供了一系列的设计工具. 你可以通过他们轻松的完成设计任务,并自动生成相应的代码. 代码和模型之间还是双向同步的. 具体有关设计的信息,你可以查看WhiteHorse的资料.
Team Foundation Version Control
在你进行设计以及编码之前, 你可能会想先设置好你的源代码管理策略. VSTS中使用的源代码管理工具(Team Foundation Version Control)的产品代号为"Hatteras”. Hatteras比微软以前所深受诟病的Microsoft Visual SourceSafe® 的功能要强大的多. Hatteras使用了SQL2005作为它的备份工具. Hatteras还提供了SourceSafe所不具备的两个功能. Hatteras能够方便的进行分支以及合并(branching and merging), 这样就使得它具有了多人签出的功能(multi-checkout). 在Hatteras还提供了一个叫”shelving"的功能,用中文描述类似于挂起. 使用它你可以将你暂时的工作保存在服务器的代码库中, 而不会签入到项目的主分支. 开发者可以方便的将一些临时工作(比如午餐的时候)很好的保存,而不会影响主要的代码库. Hatteras还允许对签入政策进行管理,这样你可以规定什么样的代码才可以签入到源代码库中,从而保证代码的质量.
不过SourceSafe并没有被微软所弃用, 还得到了升级, 它也可以配合Visual studio2005一起使用.不过它仅仅适合那种开发小型的项目的小团队.
Writing Better Code
VSTS在IDE中集成了一些用于提高代码质量的工具.其中包含了测试系统潜在性能的profiler, 以及对managed和unmanaged代码进行静态检查的代码分析工具.代码分析工具在VSTS推出之前已经存在,不过此次和IDE良好的集成在一起unmanaged代码使用的是PREfast, 而managed代码则使用FxCop. VSTS中的单元测试的工具很象目前广泛使用的NUnit,不过在VSTS中将变的更容易使用, 创建测试代码的时间也将得到缩短, 使得人们更乐于使用它. 单元测试工具同时还集成了代码覆盖率的功能, 用于判断有多大比率的代码得到了测试, 结合报表的输出功能可以让你随时对于代码的安全性有所了解,对你的代码更加有信心,从而轻装上阵.
Managed Code Analysis
如果你已经熟悉了FxCop, 你将会对VSTS的代码分析工具很满意,因为它已经和IDE良好的集成在一起. 你只打开你的项目属性, 找到Code Analysis标签页(Tab), 你就可以很方便的设置是否需要代码分析的功能, 以及运用何种规则进行代码分析.
很多公司如果以前没使用过FxCop,可能需要先禁止该功能, 因为你会发现你的代码充满了不符合规则的警告和错误提示. 不过当你适应了它的规则后, 将使得你的代码的安全性以及质量得到很大程度的提高.
当你开启代码分析的功能之后, 在你编译代码的时候, 代码分析的结果将伴随Build输出报告, 以警告和错误的形式输出, 就有点象你的编译出错报告那样. 你可以自由的控制何时使用它, 一个推举的做法就是在编译Debug版本的时候关闭它, 而在编译Release版本的时候打开它. 因为如果项目庞大的话, 代码分析过程将很漫长. 代码分析另一个很值得一提的功能就是你可以在指定签入政策的时候, 规定只有经过代码分析的代码才能签入. 这样能更好的避免不符合质量要求的代码被提交.
Unit Tests
单元测试基本原理就是将一段一段的代码隔离(通常是以类为单位), 然后根据某些特定的输入, 使得测试的结果满足特定的输出, 从而保证代码在各自单元内的正确性. 单元测试即使在没有任何帮助的情况下也可以很容易的实现. 不过为了提高生产率, VSTS在单元测试的创建,组织管理以及测试结果的输出上还是做了很多的辅助工作, 使的单元测试在VSTS中能够更方便更高效的被开发者所使用.
VSTS提供了自动生成部分测试代码的功能(当然只是针对Managed代码).VSTS使用属性来区分测试代码和源代码. 并且很好将测试代码组织在Test Lists中, 使得开发者可以很方便的从中查看以及运行测试, 并且将测试结果输出到专门的Test Results窗口.
当你想为你的代码添加测试代码的时候, 只需在源代码上点击右键选择Create Tests菜单, 如图4所示.
图4 生成测试代码
举一个例子所示范:
Public Class Math
Public Function Add(ByVal Value1 As Integer, _
ByVal Value2 As Integer) As Integer
Return Value1 + Value2
End Function
End Class
这段代码的功能就是将输入的两个变量相加然后将和返回.利用VSTS自动生成的代码如图5所示:
图5 自动生成的测试代码
可以发现测试的框架已经为你搭好, 你只需要为它添加一些简单的代码就可以完成测试代码的编写.注意最后一条语句,它是用于提醒开发者不要忘记添加自己有意义的测试代码. 当然你也可以通过测试属性的Configuration标签页(Tab)关闭此功能.
为了运行测试, 你需要先编译你的代码(包括测试代码), 然后打开Test Manager窗口通过它你可以查看到你的所有测试,在这里你可以更好的组织好你的测试代码,比如将所有有关业务逻辑的代码放在一起.当你运行测试代码的时候你可以对一些选项进行控制. 比如你可以打开测试代码覆盖率的功能. 因为测试代码只有达到一定的比率才能真正的保证你的代码的质量. 当你运行完测试后, 你可以通过Test Results窗口(如图6)和Code Coverage Results窗口(如图7)查看测试运行的结果.
图6 Test Results
图7 Code Coverage Results
从图6中你会发现有一个测试标记为Inconclusive, 显然是因为我们没有添加真正的测试代码以上的测试代码全是VSTS自动生成的. 我们将测试代码修改一下,加入有意义的测试代码.如图8:
图8 修改过的测试代码
经过修改,加入我们想要测试的内容,再次运行,测试就会通过了.
除了通过Code Coverage Results视图, 我们还可以打开代码着色显示的功能用于提醒我们测试代码覆盖的结果.如图9所示:
图9 代码着色显示测试覆盖率
从图中可以发现有测试代码的方法被标记为绿色, 而没有测试代码的方法被标记为红色. 这样我们可以很容易的定位到那些没有被测试覆盖的方法.
测试代码的结果以及代码覆盖率的结果可以发布到Team Foundation Server上并被保存在数据库中, 这样就可以通过Team网站以报表的形式将代码的质量清楚的展示出来.
Load Testing
除了单元测试, VSTS还提供了Web压力测试的功能. 这块功能和以前的Application Center Test所提供的功能很接近, 只是更加强大并且和IDE集成的更加紧密,方便使用.
你可以记录下当前的浏览器的session用于以后在一台或者多台机器上使用,它还提供了处理ASP.NET forms authentication以及ASP.NET ViewState的工具.
要使用压力测试的功能,最方便的方法就是新建一个测试项目, 这是VSTS中新支持的一个可以添加到你的Solution中的项目. 在测试项目添加完成后,你可以通过右键从上下文菜单中不断地添加新的测试(从Test Manager window中选取).
VS2005中的Web测试和压力测试不是一个概念.Web测试可以通过宏记录将测试的过程(鼠标点击的行为等等)录制下来, 然后在以后的测试中不断播放.而压力测试主要用于模拟在一定网络压力的情况下(比如一定人数同时访问时)程序的表现. 你可以在压力测试中使用之前创建的Web测试来测试你的Web应用的性能.
Testers, Manual Testers, and Bug Tracking
VSTS提供了单元测试以及Web应用的压力测试的支持, 不过并没有提供对no-Web UI的应用的自动化测试.( Compuware公司将把TestPartner集成到VS.net 的IDE中).
你的QA小组将得到VSTS对测试管理以及Bug追踪的良好支持. Bug其实就是特殊的Work Item, 你可以用类似任务的追踪一样为它分配责任人,状态等等.同样系统Bug的概况也可以通过Team的网站查看到.
VSTS对测试的支持还体现在对各种类型测试的良好集成,甚至包括了对手工测试的支持. 以往测试的时候可能会使用到Word文档,一些脚本文件, 在VSTS中你可以把这些手工测试和单元测试,压力测试都保存在TFS中一起管理,.并且可以在Visual Studio中运行这些测试.
当然手工测试运行的时候, 会要求你手工填写该测试是否通过的信息. 由于VSTS对测试的良好支持, 使得开发人员可以和测试人员可以在同样的环境中更好的合作.
Team Build
随Net2.0一起发布的MSBuilder是一个具有可扩展功能的构建引擎(build engine). Team Build正是利用它实现的.在Team Build中有一个构建服务器,它将根据网络上其他客户的要求自动运行存储在Team Foundation Version Control中的构建脚本(build scripts)来构造我们开发的应用程序.你可以使用Visual Studio的构建向导(其中包含了很多类型的脚本框架)来创建构建脚本, 其中你可以为它设置很多的选项,比如是否在构建的时候自动运行代码分析(FxCop)和单元测试. 你也可以设置是否在构建完成时自动更新相应的Work Item的状态或者发出一些通知.当然Team Build还支持每日构建, 也就是你可以在设置好构建的过程, 然后在每天晚上由服务器自动完成源代码的编译,分析,测试并将新版本的Build更新到测试服务器, 这样第二天早上所有的开发人员将收到项目最新的报告, 测试人员也将得到对测试服务器上新版本Build进行详细测试的通知.
The Team Site and Reporting
Team System很重要的一个特点就是不再仅仅是开发人员的工具.如何将项目的情况反映到外界, 在以前可能是一件很困难很麻烦的事情. 在Windows SharePoint® Services (WSS)的支持下, 通过整个系统统一的数据库, 我们可以很方便的在Team网站上看到有关项目的各种信息, 并且这些信息是自动的,即时的,形式多样的.你可以从网站上看到项目的进度, Bug的数量和严重性, 获得项目过程中产生的各种文档,还有一些相关的报表. 以上这些功能基本满足了各种项目参与人员(开发者, 项目经理,业务经理,测试人员,客户)的需求.
Conclusion
总体而言,利用VSTS,你将获得以下的好处:
1. 降低软件开发的复杂性
2. 促进团队成员的合作
3. 拥有定制和扩展的能力
在最后值得一提的是VSTS具有很强的扩展能力, 对于那些已经拥有很好的开发方法的公司可以在VSTS中定制适合自己的开发方法模板,. VSTS还提供了第三方工具的扩展功能, Borland公司就准备把他们的CaliberRM(需求管理工具)集成到VSTS中. 这样就填补了VSTS对需求管理的空白. 如果VSTS在某方面无法满足你的需求, 你可以尝试寻找合适的第三方工具.
