测试团队工作计划范例6篇

前言:中文期刊网精心挑选了测试团队工作计划范文供你参考和学习,希望我们的参考范文能激发你的文章创作灵感,欢迎阅读。

测试团队工作计划

测试团队工作计划范文1

关键词:软件测试;测试管理;测试工具;Quality Center

软件开发团队的质量意识不断提升,团队对测试的重视与依赖程度也逐步提高。软件质量是各种特性的复杂组合,软件测试是软件质量保证的一个重要环节,通过软件测试来验证软件是否满足了需求,验证产品是否满足内部质量和外部质量。

复杂的项目和有限的工期,要求测试人员用更短的时间、更高的效率进行软件测试。测试人员组成的团队,需要有效而明确的管理。软件测试管理是一种活动,可以对各阶段的测试计划、测试用例、测试流程、测试文档等进行跟踪、管理并记录其结果。随着软件产品的迅速发展,软件复杂度逐渐提升,这给软件测试带来了更多挑战,测试的组织与执行成为软件工程的重要部分。

借助工具,可以使测试管理可视化,协助测试顺利进行。在IT企业的软件测试团队中,结合软件测试理论与方法,适当选择工具软件,可以促进企业工作规范化,提升团队工作效率,让多人协作完成复杂测试工作成为一项管理清晰、目标明确的系统工程。

1 Quality Center简介

Quality Center是HP(惠普)公司的软件测试管理产品,该产品前身是Mercury Iteractive(美科利)公司的Test Director,后被惠普公司收购,正式命名为HP Quality Center(后文简称QC)。QC是一个基于Web的测试管理工具,可以组织和管理应用程序测试流程的所有阶段,包括指定测试需求、计划测试、执行测试和跟踪缺陷。此外,通过Quality Center还可以创建报告和图来监控测试流程。

QC功能比较丰富,善用QC可以完成复杂的测试管理工作。相比其他过程管理与缺陷管理软件,QC是一个“重量级”的软件帮手。介于使用成本的限制,更适合于企业级应用。在系统测试的组织与管理方面,更显优势。

2 使用QC管理系统测试

QC软件模块较多,本文从最实用模块入手,主要包含版本管理、测试需求、测试版本管理、测试用例、测试执行与缺陷管理六个方面,完成整个测试过程的监控、管理与执行。下文将通过图文描述,展示具体的操作过程与方法。该测试方法的解决方案经过实际系统测试工作的检验,是一种有效的测试管理手段。

2.1 权限管理――自定义中的“组”

测试管理的主体是“测试人员”,测试人员在测试团队中有不同的分工,测试经理、测试用例设计人员、测试用例执行人员各司其职。根据项目复杂度的区别,人员配置会有不同。

测试经理的职责是制定测试计划和进度并及时反馈、建立与维护测试基线、团队成员能力了解与工作安排等[4];测试用例设计人员应掌握项目的具体细节和操作流程,设计出合理用例。在实际工作中,存在着人员复用情况。管理与设计人员需要拥有操作QC的较高权限。测试执行人员根据设计的用例进行执行,对整个测试需求、用例的修改需要较为慎重,所拥有的权限应较低。可以根据实际项目的人员分工设施操作权限。

设置权限的方法如下,管理员账号登陆,点击右上方“工具”--“自定义”,出现权限管理界面。点击“组”,可以建立或修改权限分类。点击“项目用户”,可以添加、编辑和删除用户,并确定测试人员所属的组。

2.2 测试需求――QC中“需求”模块

项目需求不同于测试需求,不能够指导实际的测试工作。而如何将项目需求转化为测试需求,考验着每一个测试经理的工作能力。使用QC,可以清晰地梳理测试需求,是需求处理工作的得力助手。

QC支持以树状结构建立需求,并为每一个需求分配ID。实际测试过程中,可以将“需求”模块用作测试需求的梳理,结合整体需求文档建立所需要测试的需求。每个功能需求均须有测试需求对应,根据实际情况,功能需求可能需要对应多个测试需求来进行测试。

2.3 测试版本――QC中“版本”模块

测试工作非一蹴而就,测试需求与用例都可能存在多个版本。可以在QC的“版本”模块建立相应的测试版本。版本名可以根据项目具体需要确定。在版本的下一级建立循环以表明测试的轮次,可以在每一轮次中,记录本轮次的开始日期和结束日期。

这里提供一些实用技巧:

当系统测试只涉及一个基线时,可以使用“轮次_基线”来命名测试轮次当系统测试包含几个基线时,可以使用“轮次”作为测试轮次名,在详细信息中写明所有系统的基线。在“详细信息”中写明所有系统的基线。

可以在每一轮次中,记录本轮次的开始日期和结束日期。

建议使用“系统名_模块名_基线日期”来规范基线名称。

2.4 测试用例设计――QC中“测试计划”模块

用例编写是测试工作的核心任务之一。

测试计划中包含所编写的所用用例,并可以控制用例的版本。介于QC的测试实验室部分展示不方便,所以实际的执行结果,也会体现在测试计划之中。

2.4.1 从“需求”导出“测试计划”中的用例

“需求”模块可以直接转换为测试计划中的用例或者文件夹,右键点击要转换的需求,选择“转换为测试..”,之后会弹出对话框,可以根据需求粒度,来选择转换方式。可以将最底层子需求转换为设计步骤、测试或主题。当需求较复杂,未拆分到具体步骤时,建议选择的是“将底层的子要求转换为测试”。转换后,测试计划中,就会生成与需求对应的测试主题,根据具体需求可以增减主题,调整目录结构,设计具体的测试用例。

2.4.2 关联用例与需求

设计用例时,可以让用例与需求关联,这样可以清晰显示测试需求的覆盖度与完成度。在每个用例中,点击“需求覆盖”,然后点击“选择需求”,右侧会出现具体的需求,选择相应需求则可以将此需求关联到用例中。

2.4.3 用例设计

具体到每一个用例,可以分为“步骤名称”“描述”和“预期结果”三个部分。不同项目对此三个模块的应用方式不同。以某具体项目为例,定义用例编写规范如下:

步骤名称:以步骤编号开头,并简要描述步骤执行的意义

描述:此步骤执行的具体方法,根据此描述,可以指导测试的输入

预期结果:这部分填写实际测试结果,记录真实的测试情况

2.4.4 保存每一轮次的用例

QC的测试实验室模块对测试结果的保存有待优化,所以,在非自动化执行的测试中,建议项目选用测试计划模块保存用例结果。值得注意的是,如果选择在测试计划中呈现具体的执行结果,即将“预期结果”填写为实际执行结果时,一定要注意:对于多轮测试时要复制测试计划中的用例,并单独与轮次关联和命名。

2.4.5 测试执行――QC中“测试实验室”模块

QC设计测试实验室模块是希望用此模块来记录实际测试的执行情况。但因为展现不清晰,所以,实际测试结果记录在了测试计划的“预期结果”中。这部分内容可以根据项目具体调整。此外,测试实验室还有以下作用:管理每一轮测试所执行的用例,监控本轮次用例状态、测试进度,以及分派测试任务。

测试实验室可以根据测试计划,来建立测试用例集。通常,测试计划的树状结构和测试实验室的树状结构是一致的,测试计划中最底层文件夹,对应测试计划中的一个测试集。当然,也可以建立一个测试集,将测试计划中所有的用例放置在一个测试集中,并分配测试给相关测试人员。具体建立测试集的方法如下:根据测试建立测试文件夹,在测试文件夹下建立测试集,并使用“选择测试”将测试计划中的测试用例拖入相应测试集中,分配测试给相关测试人员。

在测试过程中根据测试用例的实际执行情况,由测试人员将测试用例的状态置为:

测试未执行,状态为“No Run”

测试正在执行,状态为“Not Completed”

测试执行完成并通过,状态为“Pass”

测试失败,状态为“Failed”

2.5 缺陷管理――QC中“缺陷”模块

使用工具管理缺陷,可以清晰地向开发人员反馈问题,记录问题沟通和修改状况,是测试历史过程的重要参考。

缺陷由测试人员根据实际情况填写,进入“缺陷”模块,点击“新建缺陷”,并根据提示填写“摘要”、“测试版本”、“测试轮次”、“测试日期”、“测试者”、“模块”、“缺陷状态”、“严重程度”、“原因分类”以及“描述”,并将缺陷与引发此缺陷的测试用例关联起来。在笔者工作过程中发现,缺陷的描述越清晰对开发人员定位问题越有帮助。

一个完整的缺陷描述应包含以下元素:

测试数据:运行该测试用例时建立的数据,如指令内容、输入字符串等。

测试步骤:执行该测试用例的操作过程。如果是前台程序,需要详细描述打开界面的title、录入的内容、点击的按钮等;如果是后台程序,需要详细描述测试环境(服务器、环境变量)运行的指令、SQL语句等。

期望结果:根据需求确定该测试用例的预期。

实际结果:测试用例执行后的真实结果 试用例执行后的真实结果,可以用文本形式或截图形式来展现。

3 结论

QC工具拥有自身的一些特点,会给测试工作带来一定影响。通过企业级项目测试的应用,发觉QC最大的优点是使得工作分配与测试用例完成情况可视化,并可以清晰地梳理测试用例等。而同样有QC带来的缺点,最显著的缺点是网页反应慢,操作耗时长,贴图不方便,内容导出困难等。

在笔者工作的测试团队中,同样一个项目的测试人员来自不同的部门,甚至所属不同城市。这时,测试的管理是非常棘手的问题。多人合作的项目测试,使用QC管理带来的好处完全弥补了它的不足。使用QC进行系统测试的维护和管理,能够达到降低沟通成本、明确任务划分、实时反馈测试问题的良好效果。

参考文献

[1]苏秦,何进,张涑贤.软件过程质量管理[M].北京:科学出版社,2008.

[2]吴慧韫,李卓群.基于H 模型的软件测试管理应用模型研究[J].计算机工程与设计.2006,27(11):1993-1995.

[3]Black.R,龚波.软件测试过程管理[M].北京:及其工业出版社,2003.10:1-53.

[4]http://

测试团队工作计划范文2

关键词:敏捷开发 Scrum 敏捷测试

中图分类号:TP31 文献标识码:A 文章编号:1674-098X(2014)09(a)-0255-01

随着社会的发展,行业竞争的加剧,原有的螺旋和RUP模型已无法适应企业快速的需求变化。为了解决这个问题,我们引入了敏捷开发和敏捷测试的概念,该文主要阐述了敏捷方法及如何在企业中实施敏捷测试。

1 敏捷开发的概念和构成

1.1 敏捷开发的概念

敏捷开发是一种以人为核心,迭代、循环渐进的开发方法。在敏捷开发中,软件项目的构建被切成多个项目,各个子项目的成果都经过测试,具备集成和可以运行的特征。

1.2 敏捷开发的构成

Scrum是一个敏捷开发框架,是一个增量的,迭代的开发过程。在这个框架中,整个开发周期包括若干个小的迭代周期,每个小的迭代周期称为一个Sprint,每个Sprint的建议长度2到4周。在Scrum中,使用产品Backlog来管理产品或项目的需求,产品Backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。

Scrum的开发团队总是先开发对客户具有较高价值的需求。在每个Sprint中,Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析,讨论和估算,得到一个Sprint的任务列表,我们称它为Sprint Backlog。在每个迭代结束时,Scrum团队将交付潜在可交付的产品增量。

2 敏捷测试开发的特征、原则、及框架

敏捷测试即是不断修正质量指标,正确建立测试策略,确认客户的有效需求得以圆满实现和确保及时最终产品。

敏捷测试特征:敏捷测试的成员需要有自发组织能力,敏捷测试需要编写需求备份列表。

敏捷测试原则:敏捷测试的原则是确保所交付的软件满足客户的需求。

敏捷测试的框架:敏捷测试框架主要包括3个角色,5个会议,3个产物,两个过程控制物。三个角色:敏捷测试管理中,角色分为三种,测试经理,测试组长,测试工程师。

3 敏捷测试的管理职责及五个会议

3.1 测试职责

确定测试需求,将测试任务分解成多个task并分发给测试组长。与客户沟通并确定测试优先级。每个Sprint,根据需求调整测试策略及优先级。接受或拒绝测试团队的工作成果;参与Scrumplanning;为项目盈利能力负责。

测试组长职责:保证资源完全被利用并全部是高产出;保证各个角色及职责的良好协作;解决测试过程中的障碍;作为测试团队与外部的接口,屏蔽外界对团队成员的干扰;保证测试过程按计划进行;组织DailyScrum、Sprint Review和Sprint PlanningMeeting。

测试工程师职责:评估工作量,拆分工作量并定义任务,评估资源利用率及工作时间,确保测试质量;改进测试流程。

3.2 敏捷测试的五个会议

(1)Product backlog估算会议:确定具体的测试需求,确定做还是不做。(2)评估storypointSprint计划会议:确定Sprint目标和每日立会的时间地点。任务拆分,工作量和point合计调整。(3)每日站立会:收集障碍,领取或分配任务,更新任务版和燃尽图。(4) Sprint评审会议:向客户提交测试成果并以之创建或变更backlog。(5)Sprint回顾会议:吸取经验教训,改进迭代过程,重点是改进团队和组织的工作流程。

4 敏捷测试的输出

敏捷测试的输出的三个产物:

Product Backlog,Sprint Backlog,

work software;两个过程控制物:燃尽图,障碍backlog。

5 案例分析

目的:为企业提供高效的测试服务,满足企业快速发展的需求。

解决方案:采用敏捷测试方法(图1)。

首先,测试经理将与客户一起参加 Sprint meeting并获取客户的测试需求,然后记录Product Backlog,其中包括待办事项,测试任务的优先级,测试周期等。然后测试经理将测试任务分发给测试组长并记录 Sprint Backlog。其中包括待办事项,测试任务的优先级,测试周期,测试计划等。确定测试任务后测试组长再与测试工程师进行开会讨论,安排测试资源、测试策略、测试周期、每日站立会时间地点。测试工程师明确测试任务后,开始开展测试工作。每天测试组长和测试经理会利用10分钟的每日站立会收集测试障碍信息,测试进度等信息并在Sprint Backlog中记录这些信息。测试任务完成后,向客户提交测试结果。测试结束后测试相关人员要吸取经验教训,改进测试流程。

6 结语

随着敏捷开发Scrum的广泛应用,敏捷测试也并将成为测试领域的发展趋势。我们也可以从敏捷测试中寻找到更多的发展机遇,为企业的快速发展和需求提供更好的解决方法,更好的为企业服务。

参考文献

[1] 王璇.敏捷测试理论与实践[J].软件导刊,2009(1):38-39.

[2] 陶凌燕.基于Scrum的敏捷软件测试模型研究与应用[D].华中科技大学,2011.

测试团队工作计划范文3

关键词:软件工程;网络课程;教学实践;Jazz

中图分类号:G642 文献标识码:B 文章编号:1673-8454(2012)07-0061-04

一、引言

随着远程教育需求的日益增长和网络教育支撑技术的飞速发展,设计适用于网络上教学的高质量课程已经成为网络教育发展的一项重要课题。

“软件工程”课程的目的是使学生能够系统地掌握软件工程的基本概念和原理,以及实用的开发方法和技术,了解软件工程各领域的发展方向,学习用工程化的思想和方法开发和管理软件项目,了解软件开发过程中应遵循的流程、准则和规范,为从事软件工程研究或应用开发工作打下坚实的基础。[1-3]考虑到软件工程是一门注重工程实践能力的课程,课程的学习既要求要掌握软件工程基本理论,又要求锻炼运用这些理论知识解决实际问题的能力,做到理论与实践相结合。

当前“软件工程”网络课程的设计日益受到重视,但在实际教学中还存在着一些问题,包括:在理论课程中贯穿整个软件工程过程的系统化案例不多,以及实践课程中项目开发实践平台不完善等。[4-6]这些缺陷都影响了学生对于软件工程整体思想的理解与实践。

解决上述问题已成为当前“软件工程”网络课程设计的迫切需求。因此,本文以理论结合实践的方式将IBM公司的下一代软件开发协作平台Jazz整合到课程的设计中:使用基于Jazz平台的工具集(尤其是其中的RTC、RRC、RQM,以及ClearCase和ClearQuest),提供对软件工程生命周期各阶段任务的支持,并将Jazz平台跨地域的团队协作能力和适用于敏捷软件开发的特点充分利用到学生的工程实践中,具有一定的创新性,取得了良好的效果。

二、“软件工程”网络课程的总体教学设计

本文在“软件工程”网络课程的教学设计中注重理论知识的掌握,同时以培养工程实践能力为导向, 强调学生能力的培养。通过对该课程的学习,让学生理解工程化方法在软件开发中的应用,以理论结合实践的方式进行同步教学:理论讲授部分采用网络多媒体教学模式,辅之以课后测验和课后作业,课程实践部分采用学生分组完成一个中小规模软件项目开发的教学模式。

在课程开展的可行性方面,苏州大学计算机科学与技术学院在与IBM公司的合作框架下,能够获取学生课程培训与实践所需要的工具和相关电子资源。此外,通过校、院或系一级的教学管理系统和FTP服务器建立教师与学生的互动平台。教师可以通过网络教学课件和案例分析等电子资源,还可以布置课后测验、课后作业以及实践项目;学生则可以通过网络下载教学资源进行课程学习,也可以通过网络进行课后测验、提交课后作业以及参与实践项目的开发。

该课程的教学设计分为两个部分:授课部分和学生工程实践部分,其中授课部分又可进一步分为理论知识授课部分和工具培训授课部分。这两部分的结合能达到配合理论教学,进行工具使用能力训练,并提高学生工程实践能力的目的。

1.授课部分

(1)理论知识授课:本部分由主讲教师完成,提供网络多媒体教学课件。理论知识授课部分主要介绍软件工程的历史、现状,以及发展趋势,以软件工程发展历史上的两个主流方法学(结构化软件工程和面向对象软件工程)为基础,深入讲解软件工程的基本原理、方法和技术,并涉及软件工程的管理话题,如软件质量管理、配置管理、过程管理、项目管理等。该课程的理论知识授课内容可以划分为结构化软件工程,面向对象软件工程,软件过程管理与质量这三个主要部分。在课程教学中,注重提供贯穿整个软件工程过程的系统化案例,使得学生能够对于软件工程的理论知识有一个全面、直观、感性的认识。

(2)工具培训授课:本部分由辅讲教师和工具提供商工程师完成授课和辅导,与理论授课部分同步进行,采用专题讲座方式进行相关工具的使用培训。工具培训授课部分主要针对IBM公司新一代的软件开发协作平台Jazz,采用IBM公司Jazz平台系列集成工具的培训教材和教学资源,对学生进行Jazz平台及相关工具体系的使用方面的培训,并对工具使用的实验进行指导,该实验也可通过网络完成。

2.学生工程实践部分

本部分由辅讲教师和助教完成,指导学生分组完成软件项目的开发。学生工程实践部分主要参考IBM公司的Jazz平台实验方案,选用一组典型的中小规模软件项目,由学生分组并选择适当的项目进行开发。在软件开发过程的不同阶段中,学生项目组需要展示对理论课程内容的掌握程度和工具使用的熟练程度,每周就项目进行进展报告,并提交各阶段相应的成果。教师需要对学生项目组进行过程管理和技术辅导,并对集中的问题进一步进行辅导。

三、IBM-Jazz平台简介

Jazz平台是IBM推出的面向跨地域团队的下一代团队协作平台,也是一个整合软件工程生命周期各阶段任务的软件开发平台。[7]

1.Jazz平台的特点

Jazz平台的主要特点包括下述三项,这些特点使得Jazz平台能够提供对于“软件工程”网络课程工程实践的支持:

(1)跨地域的开发团队实时协作能力。Jazz平台支持Web2.0技术,能帮助分散的软件开发团队克服地域障碍,搭建实时协作的平台。Web2.0技术支持实时的信息和信息反馈,通过网络,分布在各地的开发团队成员都可以在Jazz上了解最新的开发进度,提交最新的开发和测试结果,找到应遵循的工作流,在该工作流的指引下循序渐进地工作,而不必担心偏离了开发目标。项目的管理者也能够在Jazz上找到需要了解的信息,包括团队的进度、每位开发者的现状,以及资源的配置等,从而帮助其配置资源,确保开发按时按目标完成。这种通过网络提供的协作能力很适合网络课程中工程实践部分的团队协作工作,包括了学生的参与和教师的管理。

(2)支持整个软件生命周期各阶段任务的无缝集成。Jazz平台提供了对于软件开发和管理流程的定义和执行能力,在这些自定义流程的基础上,能够跨越包括需求、设计、编码、测试、配置与交付等软件生命周期的各个阶段,对各阶段的任务进行无缝集成。Jazz平台对软件工程生命周期各阶段任务的支持,符合“软件工程”课程的工程实践要求,使得学生能够对于软件工程过程有一个全面和系统的理解和实践。

(3)支持敏捷软件开发。Jazz平台还预定义了一些适用于敏捷软件开发的流程,对RUP的支持使得最新的需求能及时交付给软件开发项目的提出者,并且能很快得到最新的反馈意见。Jazz平台对于敏捷软件开发提供了支持,符合“软件工程”网络课程的工程实践部分中“开发中小规模软件项目”的要求。

2.Jazz平台工具集

从2008年开始,IBM陆续推出了基于Jazz平台的工具集,这些工具都是以与Jazz平台集成的插件或连接器的形式的。主要的工具包括:

(1)Rational Team Concert(简称RTC):RTC是IBM推出的第一个基于Jazz平台的产品。作为一个协作软件交付平台,RTC通过提供整合的项目计划、工作管理、配置管理、团队构建、版本构建、报告能力等,为整个开发团队提供了协作的基础。RTC还能够帮助开发团队简化、自动化和监管整个软件交付过程。

(2)Rational Requirements Composer(简称RRC):RRC是基于Jazz平台的需求开发管理平台。辅以Rational DOORS Requirements Professional,RRC将各种需求定义手段和需求相关人员有机地结合在统一的集成协作平台上,实现协作化的需求定义与需求管理。RRC采用多种需求开发方法和协作技能,使需求相关人员能更好地进行需求的获取、分析、精化、管理、评审以及验证。使用RRC能够尽量确保在开发之前将需求定义清楚,减少因为需求定义不良为后续开发带来的问题。

(3)Rational Quality Manager(简称RQM):RQM是基于Jazz平台的全生命周期质量管理协作平台。RQM在整个软件工程生命周期中提供了从测试需求管理、测试计划、测试用例设计、测试执行、测试评价和缺陷管理等完整的测试生命周期管理方法,能够简化和自动化繁杂的测试任务,支持手工测试以及自动测试。通过与其扩展组件Rational Test Lab Manager的集成,RQM还能提供自动化的测试环境和测试资源的管理,从而提高测试的效率。

(4)Rational Project Conductor(简称RPC):RPC是基于Jazz平台的项目及资源管理平台。RPC可以帮助项目经理进行项目计划、制定项目进度,为项目和任务安排合适的资源。RPC还提供了对项目状态和进度进行管理监控和可视化的功能,可以作为项目开发的核心数据库。

(5)Rational Insight:Insight可以帮助获取关于开发团队的度量数据,客观地度量开发的状态和进度。Insight能够提供关于系统和软件交付准确的深入信息,确认高优先级的业务目标,并给出软件交付的最佳实践,从而更好地定位开发团队的目标、度量最佳实践和业务成果。

(6)Rational Build Forger(简称RBF):RBF是基于Jazz平台的过程执行框架,可以对软件工程生命周期中重复的开发任务和构建过程进行自动化的安排、管理和追踪。RBF支持主流的开发语言、工具及平台,能够在沿用现有开发资源的同时,增加有价值的自动化、加速、通知和日程安排等功能。

(7)Rational Asset Manager(简称RAM):RAM可以帮助组织了解所拥有资产的状况,资产之间的关系,以及资产所交付的业务价值,从而使组织能够基于一致的可重用资产更快地向市场交付高品质的软件解决方案,并减少解决方案实现和维护的成本。

除了上述工具外,IBM还将陆续基于Jazz平台推出相关工具,并进行众多上一代Rational工具的Jazz化过程,已完成的包括ClearCase和ClearQuest等。

在“软件工程”网络课程中,主要涉及的基于Jazz平台的工具是:Rational Team Concert、Rational Requirements Composer、Rational Quality Manager,以及ClearCase和ClearQuest。

四、“软件工程”网络课程的工程实践部分设计

“软件工程”课程具有实践性强的特点,其工程实践环节既重要又困难,需要深入研究该课程整个工程实践环节的教学内容和方法,确保相关实践平台,设计完整的实践体系,包括:实验大纲、计划、教材等。本章中对于“软件工程”网络课程,即所述“学生工程实践部分”做进一步研究。

1.工程实践部分的目的

(1)让学生在实践环节中加深对软件工程课程理论知识的理解,通过让学生参与一个中小规模软件开发的完整过程,建立对软件开发过程各阶段活动的全面、直观、感性的认识。

(2)要求参与的学生在实践环节中分成若干个项目组,并以项目组为单位完成软件系统从需求分析到测试交付的完整过程,在该过程中学习有效的沟通方法,培养团队合作精神,为将来进入软件工程行业做好准备。

(3)让学生通过实践环节掌握Jazz平台系列工具的使用方法,培养学生灵活运用所学理论知识分析和解决问题的能力。

“软件工程”网络课程的工程实践部分的总体要求包括:遵循敏捷软件开发的定义,各个学生项目组独立完成从需求获取与分析、设计与建模、编码、测试、配置与交付、过程管理等软件工程关键活动,熟练使用各种工具完成上述活动,养成规范化软件开发的习惯,并根据国标版软件开发文档模板最终提交相应的软件制品与规范化文档。

2.工程实践部分的具体要求

(1)项目管理与计划。根据实验课程的安排,各学生项目组首先进行的是基于项目管理知识使用Jazz-Rational Team Concert进行所选项目的开发过程管理,使用Jazz-ClearCase实施配置管理,基于Jazz-ClearQuest进行缺陷与变更管理。需要学生项目组制定项目计划,包括过程计划、开发计划、测试计划、配置管理计划等,在网上提交相关文档和进展报告。

(2)需求获取与分析。在该阶段中要求各学生项目组获取并分析目标软件项目的需求,采用用例模型描述系统的需求规约,使用Jazz-Rational Requirements Composer管理需求分析阶段的结果并进行需求评审。需要学生项目组给出需求规约文档,在网上提交相关文档和进展报告。

(3)设计与建模。在该阶段中要求各学生项目组以需求阶段的结果为基础,使用工具Rational Software Architect为目标软件项目进行设计和建模(注:IBM尚未为该阶段提供基于Jazz平台的工具),基于模型描述系统的设计规约。需要学生项目组给出设计规约文档,在网上提交相关文档和进展报告。

(4)软件编码。在该阶段中要求各学生项目组以设计阶段的结果为基础,完成目标软件项目的最终编码过程,并对软件产品进行评审。需要学生项目组给出源代码和可执行的系统,在网上提交相关软件制品和进展报告。

(5)软件测试。在该阶段中要求各学生项目组使用Jazz-Rational Quality Manager及其他测试工具完成测试:设计测试用例,完成测试脚本的编制,实现自动化测试执行,进行测试结果的收集和分析,进行测试评估,将确认的缺陷提交到缺陷追踪系统中。需要学生项目组给出测试文档,在网上提交相关文档和进展报告。

(6)软件部署与项目总结。在该阶段中要求各学生项目组结合实际运行环境,完成目标软件项目的部署,并对各个阶段的执行情况进行总结,必要时可录制系统演示。需要学生项目组在网上提交报告和相关资料。

五、结束语

针对当前“软件工程”网络课程的现状,本文在对该课程的设计中整合了IBM公司的下一代软件开发协作平台Jazz,利用该平台对软件工程生命周期各阶段任务的支持,及其跨地域的团队协作能力和适用于敏捷软件开发的特点,以理论结合实践的方式设计了该课程的总体教学计划:着眼于培养学生的工程实践能力,从授课部分(包括理论知识和工具培训)以及学生工程实践部分两个方面展开,在实践中取得了良好的教学效果。

参考文献:

[1]Roger S. Pressman. Software Engineering: A Practitioner's Approach, 7th edition[M]. McGraw-Hill,2009:928.

[2]Ian Sommerville. Software Engineering, 9th edition[M]. Addison Wesley,2010:792.

[3]Shari L. Pfleeger, Joanne M. Atlee. Software Engineering: Theory and Practice, 4th Edition[M]. Prentice Hall,2009:792.

[4]许家,白忠建,吴磊.软件工程――理论与实践, 第2版[M].北京:高等教育出版社,2009:399.

[5]黄河笑,杨焕宇, 陈海建等.“软件工程”网络课程的设计与开发[J].计算机教育,2009(22):93-96.

测试团队工作计划范文4

一旦机械完整性覆盖的范围确定,将主要集中在完善和执行检查、测试和预防性维护项目。预防性维护包括所有主动性维修任务预防或预测机械完整性项目覆盖的设备的失效,检验、测试和预防性维护,目的是识别和执行维修活动确保设备的完整性。这样做有机会减免故障维修而转向更主动地维护设备的完整性。为此,检验、测试和预防性维护的完善和实施包括计划、执行和监控2个阶段。1)检验、测试和预防性维护任务计划。这个阶段的活动包括识别和归档所需检验、测试和预防性维护任务确定执行这些任务的频率。接下来这些任务转化为计划。此时的计划应该是以保证设备的可靠性和安全性以及工厂运营成本的经济性为基础。充分考虑到4个方面制定计划:①为什么要检验该设备?需要检查和测试哪一种类型的缺陷?②从设备的哪些部件检查设备缺陷?已有的检验手段是否可以查找到缺陷位置?③怎样能发现缺陷的最佳技术?怎么测量破坏形式如壁厚减薄、裂纹等?④什么时候是最佳的检验时间?2)检验、测试和预防性维护任务执行和监控。让有资质的人员根据计划表执行这些任务的计划。为了达到此目的,检验、测试和预防性维护项目需要监测进度表,任务结果及整个项目实施的效果。为了实施检验、测试和预防性维护项目,所有相关部门人员要检查识别和归档检验、测试和预防性维护任务并为重复发生的任务制定计划表。参考重复任务的一览表和检验、测试和预防性维护项目相应的计划表,计划的主要因素包括:①包含机械完整性覆盖范围内所有设备重复的检验、测试和预防性维护任务;②定义每个检验、测试和预防性维护任务的基础和相应的时间间隔;③提供相应的程序和其他必要的参考(如原始设备制造商的手册);④为每个检验、测试和预防性维护项目定义各自的验收标准。工厂决定最合适的格式来搜集和归类结果。根据工厂的档案保管要求,每个在机械完整性程序过程中的检查和测试应形成书面纪录,并保持至少3年。关于管道系统,压力容器,储罐和其他管道系统部件的检查记录应以持续进行,在整个设备生命周期过程中予以保管。在识别机械完整性项目过程中,工厂对检验、测试和预防性维护注重落实。机泵P3005入口过滤器的缺失造成金属异物进入泵体,在随着叶轮转动过程中,进而引起轴头断裂和叶轮叶片损坏(见图1),对工艺生产造成停工。为此,团队识别其设备和工艺的重要性,将该泵作为生产关键安全设备,在进口管线增加进口过滤器,并在维护项目中增加每半年拆卸过滤器,检查过滤器是否有堵塞或破损,维修工单完成后由机械完整性工程师全部检查。检验、测试和预防性维护是动态持续改进的过程。按照普遍认可的良好的工程实践编制的检验、测试和预防性维护程序既需要符合制造商的建议和良好的工程实践经验,必要时也需要根据生产运营经验增加检验和测试的频率。某公司制定了新的涂料生产车间的粉尘防爆的标准,并且在中国等地区大力推行粉尘爆炸知识的宣讲。机械完整性团队理论联系实际,开始关注涂料生产车间的粉尘安全隐患,除尘区域内的关键安全设备的识别和实施预防措施。首先要求车间严格控制潜在点火能量,包括日常的生产工艺操作和维修作业,降低一次爆炸的可能性。其次加强车间粉尘堆积的管理,尽可能避免粉尘二次爆炸的风险。根据机械完整性团队对于涂料生产车间的安全评估,测量到车间的粉尘累计厚度已达8mm(见图2),车间需要停工后先进行切断电源再人工清扫和吸尘,彻底清除各设备上和车间桁架的粉尘。整个高空清扫工作完成后,收集的可爆炸性粉尘重量累计710kg。为了防止静电积聚引起火花,机械完整性团队考虑到潜在的粉尘爆炸风险,在所有输送爆炸性粉尘的设备和管道间增加跨接线,并在检验、测试和预防性维护增加了检查跨接线是否完好、万用表检查跨接线的电阻须小于10Ω的内容(见图3)。检查和测试周期在Maximo设定为季度工单。在进行溶剂系统设备的检验、测试和预防性维护审核时,发现由于工厂溶剂输送管道系统垫片选用错误,所有的垫片均为乙丙橡胶垫片,而按照规范正己烷溶剂属于易燃化学品,管道垫片应该采用金属石墨缠绕垫片(见图4)。某公司机械完整性团队立即将这一情况与工厂经理进行反映,并制定施工作业安全评估,对该系统垫片进行升级更换。

2员工培训和质量保证

员工培训是一个有效机械完整性的重要因素。合适的培训确保实施机械完整性任务的员工有能力完成自己在整个体系中的职责,正确始终如一的执行机械完整性任务如减少人为失误的机会。减少人为失误可以极大减少整个设备失效率。要评估当前人员和新员工与需工作要求的知识结构,知道差距在哪里以便工厂提供培训或借助于外部帮助使员工得到更进一步的培训和资质要求。除了工厂提供的培训,还应该参加政府部门安排的培训和考试,取得法规要求的资质培训。质量保证涵盖了设备设计、制造、安装和维修等各个阶段,是机械完整性项目的重要保障。在设备制造过程中,工厂需要确认制造商有适当的质量保证体系,并且派人参与监督设备的关键制造步骤和环节。任何对于设备设计参数的改变,需要经过机械完整性项目相关的工程师审查,并且需要遵照变更管理程序。建设和安装必须安排合格的有资质的人员如焊接作业人员。安装说明书对安装人员有很重要的指导作用。竣工安装的检查和测试必须进行的特别测试包括压力设备的水压试验、仪表的联锁调试。规范的作业程序或检查表有助于执行的一致性和质量检测。设备试车运行安全检查是识别质保的最终机会,在此期间,可以比较安装的设备和设计文件,确认项目具体的安装要求。工厂应该记录设计与安装的差异,评估差异是否可以允许,在设备投用前进行必要的改进措施,归档记录并关闭所有识别的项目。备品备件管理必须建立机械完整性设备中影响工艺安全的关键零备件的清单,并列出其技术参数等信息。严格控制备品备件的采购、验收、保管和使用,防止错误使用。使用不同于原始部件的替代需要按照进行变更管理程序[3]。

3结论

测试团队工作计划范文5

2009年2月25日至4月17日,礼平老师提出将学院大三的“软件项目管理”和“软件项目开发实践”两项课程相结合,让学生完成一个网上书城系统。项目历时52天,在两位老师的悉心指导下,整个学院的同学组成20多个团队,开始了开发历程,在这个过程中,着重培养了学生获取知识、共享知识、应用知识、总结知识和传播知识的能力。

作为其中一个团队的小组长,我深为自己所在的团队“喜羊羊与灰太狼”感到自豪,它对于我以及我们组员的影响都是“前所未有”,并且是长远的。说其前所未有,缘于这次开发就如大学前几年的一次总结,帮助我们汇总学习方法,融会贯通所学知识;说其影响深远,缘于其对我们后期课程乃至下一届或下几届学弟学妹们的帮助。

“喜羊羊与灰太狼”是一个由5个女生、2个男生组成的团队。这是一个奇怪而又强大的组合,这7个人没有任何相关领域的开发经验,没有任何组队共同开发的合作经验。在团队中,有的活泼可爱,有的深沉内敛,有的认真细致,有的想法独特,当组合在一起之后,我们有过争执,有过失望,但是最终我们却提交了一份令人满意的成果,包括7个完整版本的源代码和32万字的文档,还有每一位成员在未来学习中取之不尽的开发经验。

2 实际开发结果

2.1 产品

产品功能如图1所示。

2.2工作量

编码工作完成情况:

・C#代码:9712行:

・数据库代码:299行;

・CSS代码: 633行;

・存储过程:1711行。

预计的生产效率:70行/人/日

程序的平均生产效率为:12355/7/14=126行/人/日

实际效率大于预计效率原因:

(1)开发团队中有技术很好的成员,当遇到问题后,可以通过请教相互沟通,能够很快地解决问题,不落下进度。

(2)开发人员自学能力好,通过第一、第二阶段的开发,积累了一定的经验,在后期三四阶段的开发中将效率提高。

(3)所有成员都十分努力,同时团队的管理机制很好,项目开发严格按照计划进行,按时完成任务甚至超前完成,工作效率很高。

2.3 对生产效率的评价

经过统计,整个网站系统的代码数量为:C#代码9712行,数据库代码299行,CSS代码633行,存储过程1711行,此部分都是开发人员手动开发的代码,总共为12355行。前期的开发时间为14天。那么程序的平均生产效率为12355/7/14=126行,人/日,这已经大大超出我们所预计的生产效率70行/A/日。虽然量增多了,但是质量依旧控制在计划之内。

经过统计,所产生文档字数大约为:75870字。所统计的文档包括需求、概要设计、详细设计、数据库设计、开发计划、测试计划等项目所需文档。那么文件的平均生产效率为:75870/1000/7/7/=1.5千字数/人/日,这明显不足于我们所预期的2.5千字数/人/日。这是因为我们还有其他很多文档并没有统计进去,例如小组的沟通,小组每周的会议记录,小组每周的总结,个人总结等。因此,如果包括所有的文档,估计能有3千字数/人/日左右。

因此我们的生产效率是能达到我们预期的要求的。

3 开发历程

从以上的开发成果看,这已经是一个完整的开发项目。这不同于课程的开发作业,也不同于科技创新项目,课程初期,礼平老师接受同学们的建议,结合同一学期着重技术讲解“软件开发实践”课程,提出共同完成同一个项目的观点,两门课程从不同的角度,即技术讲解和项目管理指导两个方面指导项目开发。这样大大减少了课程内容的重复和冲突,集中了同学的时间和精力,让我们更加具体细致地完成一个项目。

3.1 相关课程的结合,集中学生经历

随着学校对于学生动手能力的要求提高,每一门专业课程基本都要求学生开发一个小型项目以增加对于专业知识的了解。然而过多的课程导致了较大的项目压力,最后学院的同学们都不堪重负。实际上,学生一直在忙于完成各种不同的项目,并没有达到实际的学习效果。

因此,当我们对礼平老师的教育理念还没有理解时,我们只是觉得能够将有关的课程相结合,是多么令人开心的事情。

“软件项目开发实践”课程老师由浅入深地对我们所遇到的技术问题进行指导:“软件项目管理”课程随着软件生命周期的进行讲述不同阶段应该要采用的软件工程项目管理方法。

然而,这不只是两门课程的结合。在后期的软件测试课程中,我们再次将自己完成的系统作为测试对象,对其中重要的功能点采用一套完整的测试方案,对其进行测试评估。因为被测系统是由自己开发,在测试过程中,我们可以很顺利地对缺陷进行修复。

3.2 软件产品的开发生命周期同课程的结合

以软件开发周期作为课程的大环境,两位老师由浅入深,从需求分析开始,到设计、实现、测试和维护,一步一步带领我们进行开发。

这像是对所有课程的总结,其中包括编程的基础课程、Web开发的相关技术、软件工程的相关课程、项目管理。在这样一个短暂的不到两个月的时间内,我们实现了基础课程中的理论知识,我们重现各类开发和设计模型。在需求分析中,我们采用“面向对象”课程中的需求分析方法,力求通过标准的需求建模方法,明确系统功能和性能要求:在设计和开发过程中,我们采用迭代的开发方法,运用所学的Web开发课程和C#编程的内容;在测试阶段,我们采用软件测试课程中学到的测试策略,对每一个阶段的测试,运用有关的测试工具开展测试过程。

现在课程结束已经快一年了,但在后期的像“软件开发实习”这样的课程中,我们却总是不自觉地会将这次开发的经验作为我们开发的依据。通过这样一次完整的项目开发过程,我们了解了整个产品的开发周期,明确每个阶段应该完成的任务,熟悉各个阶段所可能遇到的问题以及应该采用的方法,甚至对于风险的估计都更加准确了。

3.3 老师的指导,我们前行的指明灯

摒弃了传统的教授方式,在礼平老师的教育理念指导下,我们开始走上讲台讲述自己所遇到的问题、采用的解决方法,老师让我们开展讨论,让我们团队内部或者不同团队之间共同交流来寻求解决方案。另一位“软件工程实践”课程教师,他采用问题驱动的教学方式,对我们不同开发阶段遇到的技术问题进行汇总统一,提供出可选的技术解决方案,不同的团队可以依据自己项目的特点采用合适的解决方案,并通过自学的方式了解该解决方案的技术细节,从而顺利解决问题。同时我们也了解到了相关其他解决方案适用的情景,让我们在今后的开发中“有法可依”。

在这场互动式的教学中,老师并没有因为学生的主动而减轻了工作压力,他们需要及时调整我们到合适的方向上,这得益于老师自身丰富的开发经验。礼平老师会在我们停滞不前的时候,建议我们应该先完 成一个静态Demo来帮助了解需求:在我们对项目计划感觉茫然的时候,他会拿出自己多年的开发经验告诉我们,应该如何在计划和开发上平衡时间;当我们对自身网站的特色定位不清楚的时候,他会让我们注重细节的完善而不是新颖的功能,让我们最终以一个稳定而完整的系统获胜。当初的我们甚至以为一个项目开发就是一次集体编写代码,然而老师却教会我们需要确定需求,将设计工作做得完整,实际的开发时间只需要两个星期,事实确实是如此,在严格的项目进度控制中,组员在两周之内竟然基本完成了系统功能。

就是这样,起初懵懂的我们对“项目”的过程完全不知所措,而现在,任何项目到我们手中,无论其采用的技术如何,无论其要求时间是多久,我们总能得心应手地为其制定开发计划并开展工作来实现它。这些知识在别人看来就像是与生俱来的,然而只有我们知道,正是通过了这样一次完整的开发过程,让软件工程领域的知识成为我们自己的“天赋”,随手拿来,即人们常说的“经验”。

在这个成长的过程中,老师并没有说,如果遇到了这样的问题,有多少伟大的人发明了多少模型我们可以采用,这种模型的构建过程是这样,那种模型的适用情况又是如何。若老师仅是这样用生硬的文字告诉我们,用我们做20年学生的经验来看,不出一个月这些知识就会模糊,不出半年这些知识又会变成新的知识。而在这一次的开发过程中,老师却像路标,告诉我们正确的方向,或者可能的路线,而其中探索的过程却是由我们来实现,前进的道路由我们自己来选择。我们变得习惯于独立思考,我们变得善于表达,我们开始熟悉这条成功之道。

3.4 综合性学习经验,我们最终的目标

获取知识(自学)、共享知识(团队工作)、应用知识(解决问题)、总结知识(创新)和传播知识(沟通)的能力,这是CDIO要求学生在基于项目的学习过程中需要得到的综合能力。

我们从不纠结于某一个技术问题,从不局限使用某一种开发模型,项目的内容也不限定,通过一次完整的项目开发过程,着眼于学生综合能力的提高,培养学生成为能够与国际接轨的高等工程师。

礼平老师强调我们要不断总结,并把这个过程运用到其他地方,不仅是软件产品的开发,从确定需求、制定计划、设计和实现的过程来看,我们可以将各种模型甚至运用到制定个人规划,还有那些需要考研的同学的考研计划中。在项目完成后,老师欣喜地翻阅每一位同学的心得体会。作为小组长我也看过组内每一位成员的总结,每个人的教训和经验都不尽相同,也许这就是我们学习的目的,每个人都能有所收获,从不同的角度,不同的领域培养不同的能力,收获不同的知识。

3.5课程考核,不仅仅是分数

与往常的课程考试不同,我们采用的考核方式是多样的,包括平时的讨论、组内的互评,答辩的结果和最终的产品质量。

平时讨论作为考核的内容之一,增加了平时课堂讨论的参与度,使得同学们更加积极地投入到课堂交流,为每一次的成果汇报作好充分的准备,积极主动地思考解决方案。

组内互评是我们的一大特色,我们采用礼平老师号称的“雷达图”来评定每一位成员在开发过程中的表现。这种评定方法通过不同方面评定每个人的能力,让每位成员能够更加清楚地认识自己,并依据其在组内的贡献作为评分依据,计算出组内互评的最终得分,“雷达图”示意图如图2所示。

答辩是最后的考验,我们为此做足了准备,甚至排练了多次。经过之前多次的中期检查,我们慢慢学着如何更好地展示和表达我们的成就,让老师和其他项目组在答辩的短暂十分钟之内看到我们的努力和优秀的产品。终期答辩推动着我们不断完善系统,因为考虑到老师要进行任何操作,提出各种疑问,所以我们从用户的角度考虑一切有可能出现的操作,尽可能地保证系统的实用性、便捷性和稳定性,这样大大提高了产品的质量。在后期的总结中,我们发现这样的方式运用到实际的产品开发中也是如此的有效,因为时刻从客户的角度考虑,是保证产品质量的重要因素。

正是这样的考核方式,不仅让我们学会如何有效表达、了解自己,更在一定程度上学会考虑如何成就一个成功的项目。

3.6 团队合作,我们最宝贵的经验

人际交往技能即团队协作和交流,是CDIO工程教育模式所提倡的应该培养学生的技能。对我们来说,团队培养的协作关系是我们宝贵的财富,团队合作也成为我们最宝贵的经验。

为了能够顺利完成每个阶段的计划,我们的小组成员常在一起整合到凌晨,为问题开会讨论好几个小时,我们会将设计制定的细致再细致,只为其他队员能够减少理解时间。当然,因为我们性格各异,所以也会对他人的行事风格不理解,也会出现推脱责任的时候,也有不能达成一致意见而发生争执的时候。可是因为大家有共同的目标,抱着对项目负责的态度,我们逐渐建立起默契,渐渐开始为对方考虑。每个小组成员都很细致地对待自己负责开发的模块,尽量减少出现缺陷,避免其他功能的开发遭到停滞或者增加整合人员的工作量。

很多人都知道,团队合作会保证项目的顺利进行,减少项目风险,构建一种良好的团队氛围,而对于我们来说,团队合作更让我们关注自己的工作,在很大程度上保证了产品开发的质量。通过团队开发的方式,让我们在开发过程发现协作的意义,更让我们收获了友谊。

4 CDIO之我见

礼平老师的课堂带给我们收获和成果,作为软件学院的学生,作为CDIO工程教育理念的受益者,我们有自己的理解和感受。

在有限的大学4年教育中,我们希望自己能够承受一定的压力并收获有用的知识,能让我们在未来的职业领域有所发展。同时我们了解,作为工科学生,工程实践经验尤为重要,而从小学到中学,理论为主的教学模式让我们深感自己经验不足,动手能力不强,对于实际的公司项目更是束手无策。成为社会肯定的具有良好综合素质的毕业生,这是我们对自身的要求,也是我们对于学校教育的期望。

测试团队工作计划范文6

J2EE技术提供了一个基于组件的、多层分布式计算平台。在J2EE的应用系统的开发过程中,由于使用了中间件,开发人员可以把工作重点放在系统功能的建模、设计与实现上。此外,J2EE技术结合了软件设计中的最佳实践(best practices),如以架构为中心的软件体系结构、基于组件的架构等等。这一切都对现有的软件工程过程提出了新的挑战。所以,裁剪RUP并且使其在J2EE项目中起更大的作用是非常有意义的。

本文讲述了如何把RUP应用到小型项目团队开发J2EE应用系统的过程中,并且结合J2EE技术的特点从项目管理、架构设计、开发和测试等方面重点阐明了对RUP的裁剪。

图1 一个复杂的BUS的实现方法

项目管理

在RUP中,角色定义了个人或团队的行为和职责,包括分析设计人员、编程人员、测试人员、项目管理人员和辅助人员,一个人可以同时担当几个角色.一个角色也可以由几个人来共同承担。针对J2EE系统的开发和维护,J2EE规范中也定义不同的角色,包括J2EE产品供应商、应用组件供应商、人员、系统管理员等等。

在实际的项目运行中.要根据软件开发组织的实际情况来确定角色的定义和分配。项目经理是必不可少的一个角色,通常是一个人来担任。项目经理代表整个项目与软件客户进行沟通和协商,并且制定软件开发计划等等。架构师也是一个必须的角色,通常由一名经验丰富的软件开发人员来担任。

在项目运行的前期,架构师负责设计软件架构和原型系统。在项目运行后期,架构师可以参与到具体的软件开发中。SQA同样是必不可少的,通常是一名经验丰富的软件开发人员来担任。SQA在整个项目的运行过程中负责监督和改进软件质量,包括制定系统测试方案、用户接受测试方案等等。开发人员是组成团队的主要力量,负责系统的设计、开发和测试。如果可能的话,团队中必须设立业务分析员的角色,负责商业建模等,通常由有特定行业经验的人来担任。

迭代开发计划

RUP的精髓之一迭代式的开发,它是基于Spiral模型翻的。整个软件开发周期由很多个迭代组成,其中初始迭代最为重要。其它每个迭代都为了实现软件的部分功能。在完成所有迭代后,软件的所有功能都已实现并且通过测试。

图2 基于Tier层的J2EE应用系统架构

初始迭代又叫作0迭代,它开始于项目的启动。结束于RUP初始阶段(inception phase)的完成。初始迭代在整个软件项目中起着十分重要的作用,这是因为在这个迭代中,项目团队和客户必须对软件项目的范围、成本、进度和应用系统的边界以及功能等达成一致的理解。

在初始迭代中,最重要的活动有明确项目的范围、商业需求和提出至少一个可用的软件架构方案。在明确项目范围的过程中,项目经理就项目的边界、产品、限制条件等与软件客户进行协商,从而达成一致认识。同时,在理解客户需求的基础上,项目经理或者业务分析员以需求说明书和功能说明书的形式把客户的需求记录下来。并且和客户达成一致理解。在此基础上,架构师提供至少一个合适的软件架构方案,并且完成原型系统。原型系统的目的不但是为了验证技术上的可行性,而且是为了给客户一个感性的认识,更好地完善对需求的理解。

需求说明书从客户的角度简要地描述了系统要具备的功能,它包含了很多商业用例。通常情况下,需求说明书还不能够全面地描述整个应用系统,所以软件开发组织还要从不同角度来描述系统的功能和特征,这就是功能说明书。功能说明书中包含了很多系统用例。功能说明书和需求说明书必须征求客户的意见,直到客户满意为止。

图3 基于Layer的J2EE应用系统架构

迭代计划是项目计划的一部分,指如何把要实现的系统分解成更小的子系统和如何在不同迭代中(除初始迭代之外)划分子系统,从而使每个迭代的目标明确,不同迭代之间的依赖关系达到最低。通常情况下,从逻辑上看,应用系统可以划分成多个BUC,而每个BUC又可以进一步划分成SUC;因此,可以从BUC的角度出发,根据相互之间的依赖程度来进行划分,把依赖程度低的BUC划分到不同的迭代中,从而确定每一个迭代的范围。一个复杂的BUC可以把它分解成独立的几个小BUC在几个迭代中来实现。(如图1所示)

一个应用系统也是由很多组件组成的。一个或者几个组件组合起来可以实现一个SUC或者一个BUC的要求。在设计迭代计划的时候,要考虑到组件之间可能存在的约束关系。基于J2EE的应用系统是基于组件架构的,因此,最小化迭代之间的依赖是一个最重要的衡量标准。

采用这种迭代办法后,每个迭代的范围限制在一个或者几个相互独立的BUC中。这样做的好处在于降低需求变化带来的风险。

图4 BUS的组成结构

风险管理

采用迭代式开发的一个很重要的原因是,项目的风险能够在早期的几个迭代中暴露出来。风险有两个基本的属性,一个是它发生的概率,还有一个是风险发生后对项目的影响。风险管理的目的是为了尽量降低风险发生时对项目的影响。

在风险管理中,首先要识别项目中存在的风险。其次根据风险发生的概率和风险发生后对项目的影响来分析存在的风险。通常采用量化风险的办法。给概率和影响分别赋予一定的数值,经过分析,把概率的数值和影响的数值相乘后的结果风险量化后的值。接着,对于量化后值比较高的风险制定相应的风险规避计划。在项目运行过程中,要不断地监督风险的变化。

架构设计

RUP采用基于组件的软件架构和以架构为中心的开发方式。J2EE技术强调基于组件的软件架构,能够很好地体现RUP的架构思想。根据3D方法可以把一个J2EE应用系统的架构从三维进行分析,分别是Tier、Layer和Systematic Quality。在设计系统架构的时候,可以从这三个角度考虑。

Tier

从Tier层的角度进行考虑,一个J2EE应用系统的架构可以分为以下几个部分:客户端层、表示层、业务逻辑层、集成层、资源层,如图2所示。每层都是按系统中业务逻辑而划分的,它具有唯一的职责。每层与相邻层都是松散耦合的。

图5 应用实例

在实现的时候,需要结合项目的具体情况而定。基于MVC设计模式的J2EE Web应用系统中,客户一般访问JSP。然后由Control层进行处理:如果需要进行复杂的业务逻辑处理并且已经有后台实现,业务逻辑使用Facade模式进行封装,形成统一的接口,业务逻辑层实现复杂的事务处理;如果需要访问资源层,再经过DAO层访问资源。

Layer

从Layer的角度进行考虑,一个J2EE应用系统的架构可以分为几个部分:最下层为操作系统、Java虚拟机和网络,它们负责系统的底层操作和网络数据的传输;之上是J2EE服务层,一般由J2EE服务器(如WebSphere,WebLogic等)提供各种基础服务,如事务的管理(JTS)、命名目录服务(JNDI)、负载均衡(Load Balancing)、容错(failover)、安全(security)等;其次是通用业务层,它一般完成与具体业务无关的基本操作,由通用的组件来实现,如数据库处理组件、系统错误处理组件、字符处理和数值处理组件、日志(10g)处理、数据转化和编码维护等;最上层才是具体业务逻辑模块,它完成具体的业务逻辑。(如图3所示)

在实现的时候.底层一般是不需开发人员关心的操作系统和网络环境,并且不同J2EE服务器厂商都提供了相应J2EE服务层, 开发人员需要关心上面两层的实现。如果是J2EEWeb应用体系,应用服务层一般会使用Struts框架。log服务一般选择log4j等。最上层才是具体业务模块。

Systematic Quality

这是指在软件架构中通过一定的办法或者使用一定的工具来达到系统要求的QoS,一般指可扩展性、可移植性、可维护性、安全等等,而这些恰恰是J2EE架构本身所带来的好处。

实现和测试

实现是软件开发人员编写代码来完成每一个组件。测试是用来保证软件质量的重要手段。采用RUP的软件工程过程后,整个项目被划分成不同的迭代。每个迭代(除了初始迭代)的范围是一个或者多个独立的BUC, 目标是编写代码实现BUC并且保证软件的质量。

在实现和测试的时候,集成(integration)是很重要的。这是因为整个软件开发过程分成多个迭代来完成,每个迭代(除初始迭代外)都是为了实现应用系统的一个部分。对于相邻的两个迭代。后者是在前者的基础上进行开发的,是实现功能上的一个增量。因此,相邻迭代之间需要功能上的集成。此外,每一个迭代都是由BUC组成的。从逻辑上来看,一个BUC是由一个或者多个SUC组成的。从实现上来看,每个SUC是由一个或者多个组件(component)组成的。因此,每一个迭代中都需要组件之间的集成,如图4所示。

根据集成程度的不同,可以划分几个不同的开发集成和测试:

首先是SUC集成和单元测试。这个是粒度最小的集成,它把几个不同的组件集成起来,实现同一个SUC。例如,SUC1是通过集成C1和C2来实现的。同时,在集成完成后,进行相应的单元测试。

其次是BUC集成和集成测试。BUC集成是把几个相关的组件集成起来,来实现它的功能。图4中BUC的实现需要集成4个组件。同时,在集成完成后进行相应的集成测试。

再次是迭代内集成和系统测试。迭代内集成从功能上来看,就是把这个迭代包含的所有BUC集成起来;从代码上看,是把所有和BUC相关的组件集成起来。同时,在集成完成后进行系统测试。系统测试分两步,首先是从功能上来测试每个BUC,其次是测试不同BUC之间的依赖和约束。

最后是迭代间集成和回归测试。对于相邻的两个迭代,从功能上来看,后者是前者基础上的一个增量。迭代间集成把这个增量准确地集成到应用系统上。同时,在集成完成后进行衰减测试。回归测试不但要测试功能增量的正确性.而且要测试增量发生后系统原来功能的正确性。

实例研究

笔者在Trade Manager项目中运用了上述的方法。TradeManager是一个关于金融软件研究的项目,开发基于J2EE技术的金融订单管理系统。项目由12个人的团队来进行开发。团队成员分工明确,有项目经理、架构师、测试员和SQA等等。项目采用迭代式的开发方式。在初始迭代中,项目双方对项目范围、功能需求及架构达成一致,并签字同意。整个开发分为三个迭代阶段,根据功能点来划分,每个迭代分别实现交易前、交易中和交易后的功能。每个迭代的开发时间在六个星期。

这个软件采用J2EE 的架构,如图5所示。其中UI和Delegate层在客户端,采用Swing技术来实现。是一个典型的肥客户端。Facade、Business Logic和DAO在J2EE服务器端,采用EJB技术来实现,它与客户端的通讯是典型的RMI/IIOp协议,采用的服务器是WebSphere。后台采用Oracle数据库来存放各种系统数据。同时,采用SiteMinder来实现系统的认证和授权。用log4j来实现logging/auditing功能。由于采用WebSphere集群技术,系统的可扩展性和高可用性得到了保证。