重庆大学,软件工程IntroductionTSP2_第1页
重庆大学,软件工程IntroductionTSP2_第2页
重庆大学,软件工程IntroductionTSP2_第3页
重庆大学,软件工程IntroductionTSP2_第4页
重庆大学,软件工程IntroductionTSP2_第5页
已阅读5页,还剩67页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、Intruduction to the Team Software ProcessWatts S.HumphreyZengyiCollege of Computer Science and Engineering, ChongQing University, Chongqing 40044, ChinaE-mail: Telo)二部分: TSP过程n启动过程(3)n开发策略(4)n开发计划(5)n需求分析过程(需求分析过程(6)n设计过程(7)n实现过程(8)n测试计划(9)n事后分析(10)6 需求分析过程6.1 什么是需求nSRS应该对

2、产品是什么提供清晰的、不含糊的说明n大多数需求说明是模糊的、不准确的n需求过程可能含有假想或猜测nSRS应该包括评估产品的明确标准以保证完成的产品有期望的功能nSRS应该向用户提供反馈nSRS应该接触最终用户6 需求分析过程6.2 为什么需要需求n尽管SRS文档很有用,但需求开发过程更重要n在需求开发过程中需要审查客户需求n对产品将如何工作的问题作出简洁的描述n和小组成员讨论这些问题,确定了解哪些以及需要的进一步的信息n再次检查产生的新问题n得到小组在计划要建立什么上达成共识n小组每个成员参与定义需求很有必要nSRS文档必不可少6 需求分析过程6.3 需求的变化n需求的变化是个难题,除非人为冻

3、结n弄明白用户相信自己需要什么n帮助用户以产品功能条款方式来定义他们的需求n与用户探讨SRS是否很好地描述了他们的需求n需求变化耗费时间和金钱nSRS帮助你管理需求变化6 需求分析过程n需求导出的步骤主题列表n评估系统可行性n理解结构问题n确定系统的风险承担者n记录需求来源n评估商业问题n定义区域限制n记录需求的理论解释n将不好理解的需求原型化n定义使用界面n定义操作过程6 需求分析过程6.4 软件需求规格说明书SRSnTSP的SRS的主题n功能需求:输入、输出、计算和使用的事件n外部界面需求:用户、硬件、软件和通信n设计的限制:文件格式、语言、标准和兼容性n属性:可用性、安全性、可维护性、可

4、移植性n其他需求:数据库、安装等n主要目标:小组对功能和外部界面的理解的一致性。n需求的可跟踪性:策划阶段开始建立的可跟踪性保持到设计阶段。6.4 软件需求规格说明书SRSTSP的SRS内容范例1.内容列表2.导言 制作SRS的目的 问题陈述 小组工程信息3.功能需求的说明 系统功能需求的描述 周期1的需求 周期n的需求 组织管理的结构4.使用在需求中的规则的定义5.外部界面需求 用户界面 屏幕界面6.设计/实现限制 标准一致性 开发限制7.专门的系统需求 文档 兼容性8.参考资料和信息来源6 需求分析过程6.5 TSP需求草案TSP需求开发周期1:REQ1草案目的引导小组通过开发和检查针对小

5、组开发工程的第一周期的需求开始条件有一个开发策略和计划;有一个在开发策略期间形成的概念性的设计概要需求开发过程产生了SRS,SRS定义了 (1)产品要实施的功能(2)对每个正常和非正常功能的使用事项说明小组应该对需求的膨胀加以警觉 (1)没有相似应用的经验,看来简单的功能实际上要花比期望更多的工作 (2)以小的增量填加功能通常是明智的(3)如果时间剩余越多,加上的功能越多步骤活动描述1需求过程综述描绘需求过程和它的产品 (1)需求过程怎样被完成(2)需求检查是怎样被组织、报告2需要说明复核开发经理领导小组复核产品需要说明并对用户描述与以下有关的问题 (1)产品的不同版本要执行的功能(2)这些功

6、能怎样使用3需要说明的澄清开发经理与用户、小组一起讨论4需求任务开发经理领导小组通过(1)提出SRS文档的要点和要制作这个文档所需要的工作5任务分配小组领导帮助在小组成员中分配任务,并且得到他们将何时完成这些任务的承诺6 需求分析过程6.5 TSP需求草案TSP需求开发周期1:REQ1草案(续)步骤活动描述6需求文档每一个小组成员: (1)产生和复核自己那部分SRS文档(2)将这些提供给开发经理; 开发经理:制作SRS草稿7系统测试计划开发经理领导小组制作并复核系统测试计划8需要和系统测试计划的检查质量/生产领导小组通过(1)检查SRS草稿和系统测试计划(2)确定问题和困难(3)确定谁、何时解

7、决这些问题和困难(4)以表INS的形式将检查形成文档9需求的更新开发经理获取更新的SRS部分,并且(1)将他们组合成最终的SRS(2)对需要说明或其他原始资料验证可追踪性10用户复核SRS开发经理将最终的SRS副本给用户来获得同意;在同意后,小组整理已确定的问题11需求基准产品支持经理以SRS为基准结束标准一份完整并检查过的SRS文件和系统测试计划;一个完整的需求检查INS表格;将时间、缺陷和规模数据记入TSP支持系统;更新的工作记录手册6 需求分析过程6.5 TSP需求草案TSP需求开发周期n:REQn草案目的引导小组通过开发和检查针对小组开发工程的第一周期的需求开始条件小组有一个已更新的开

8、发策略和计划;概要更新更新SRS,以反映,以反映(1)先前周期的需求问题(2)还没有开发但先前已详细描述的SRS功(3)现在需求而先前没有描述的SRS功能小组应该对扩大需求的加以警觉小组应该对扩大需求的加以警觉 (1)没有相似应用的经验,看来简单的功能实际上要花比期望更多的工作 (2)以小的增量填加功能通常是明智的(3)如果时间剩余越多,加上的功能越多更新过的更新过的SRS定义新的产品功能,新的功能包括对每个用户行为的用户事件描述定义新的产品功能,新的功能包括对每个用户行为的用户事件描述步骤活动描述1需求更新考虑用户描绘出在上个需求过程中发现的问题将在这个周期中应被纠正2需要说明的复核(1)产

9、品的这一版本所实现的功能(2)这些功能怎样使用3需要说明的澄清开发经理将整理过的问题提供给用户、用户和小组一起讨论出答案4更新任务开发经理领导帮助小组进行(1)确定作出的需求变化(2)更新部件的功能分配5任务分配小组领导帮助小组成员中分配任务,以及(1)获得成员何时完成这些任务的承诺;6 需求分析过程6.5 TSP需求草案TSP需求开发周期n:REQn草案(续)步骤活动描述6更新文档(1)每一个小组复核、更新他自己的那部分SRS,并将之提供给开发经理(2)开发经理制作更新了的SRS7系统测试计划开发经理领导小组更新并复核系统测试计划8更新检查质量/生产领导小组通过(1)检查SRS草稿和系统测试

10、计划(2)确定问题和困难(3)确定谁、何时解决这些问题和困难(4)以表INS的形式将检查形成文档9需求的更新开发经理获取更新的SRS部分,并且(1)将他们组合成最终的SRS(2)对需要说明或其他原始资料验证可追踪性10用户复核SRS开发经理(1)将这些部分组合成更新的SRS(2)在同意后,小组整理已确定的问题11需求基准产品支持经理以更新的SRS为基准结束标准一个更新的且被检查过的SRS文档和系统测试计划;从需求检查中产生的完整的INS表格(检查表格);将时间、缺陷和规模数据记入TSP支持系统;更新的工作记录手册(有所有表格、SRS文档和系统测试计划等副本)第二部分: TSP过程n启动过程(3

11、)n开发策略(4)n开发计划(5)n需求分析过程(6)n设计过程(设计过程(7)n实现过程(8)n测试计划(9)n事后分析(10)7 小组设计n设计原则n以小组为单位的设计n设计的标准n设计的复用性n设计的可用性n设计的易测性n设计的复核和检查7 小组设计n设计过程的主要目标n为产品实现生成一个准确、完整、高质量的基础(即设计)n总体设计n总体设计中问题的发现n总体设计的修正n错误的设计会导致时间的浪费,引起严重的进程延迟7 小组设计n总体设计的过程由四步组成:n决定整体产品结构n将产品功能分配给部件n制作部件的外部规范n决定在每个开发周期中开发哪些部件和功能7 小组设计7.1 设计原则n总体

12、设计必须形成一个说明(设计草案DES1DESn )n每个部件n界面 完整的功能规格说明 n状态行为n详细设计(在实现草案IMP1IMPn中描述)n定义每个部件的逻辑结构n初始化及其他条件与循环n状态结构、状态转换n所有设计必须保证n源代码能够正确地执行由详细设计描述的功能、能适当地使用设备、能结合重用功能、遵循编码和系统标准与习惯7 小组设计7.2 小组设计n主要问题n如何生成一个设计n以何顺序来设计产品的不同部分n各部分应由谁来设计n这些部分如何组合到一起7 小组设计7.2 小组设计n建议n使用整个小组n总体设计方法选择n总体设计结构和逻辑n详细描述界面n部件功能分配n文档形成n设计研究n在

13、小组集体研究期间,考虑设计的其他方式n建立原型n界面原型n使用整个小组的才智n小组成员的想法的有效性n每个成员都应该贡献其经验和知识7 小组设计7.3 设计的标准n命名约定n技术支持经理建立系统词汇表n分层类型名n系统、产品、部件、模块、项n程序名、文件名、变量名、参数名n设置、控制、改变名称的过程中的规范n界面格式n内容和格式n系统消息和错误消息n建立标准的格式和程序n可重复使用的消息和设备n缺陷标准n建议采用PSP的10类标准nLOC的计算n设计之前一致的LOC计算n设计表示的标准n定义和使用标准特别重要n生成准确的设计7 小组设计7.4 设计的复用n在总体设计阶段,有效利用小组时间的一种

14、方式是定义小组的复用标准n可能的公共功能n可复用部分的一个初始集n对于小项目在设计阶段引入复用n对于大项目在需求和策略开发期间开始考虑复用7 小组设计7.4 设计的复用n主要问题之一n定义复用界面标准调用/返回界面n作为变量的参数n作为返回的参数n作为特殊消息和错误条件的参数n错误消息和条件的标准n对错误条件反应的标准n变量和参数及可重用部分设立命名约定7 小组设计7.4 设计的复用n主要问题之二n复用文档标准n文档标准是可复用部分和不可复用部分的区别所在n当工程师们不必看源代码就理解如何使用可复用程序时,小组复用就被最大化了n可复用部分包括每个部分的外部行为的完整的详细说明n源程序部分的顶部

15、应该有一个如何使用的注释段落7 小组设计7.4 设计的复用n 主要问题之三n高质量是复用策略的要素n一旦当用户发现复用部分有错误,就通常会放弃它n在决定复用一个已有的程序时,你应该考虑下列问题(是是):n程序有合适的功能吗?n程序界面适合于新的应用?n程序性能适合于新的应用?n所有需要的资料,如源代码、测试情况、测试数据和应用说明是否可以得到?n程序是否生成了合适的标准,诸如语言水平、编码标准、命名标准和帮助标准?n程序是否有可论证的高质量?7 小组设计7.4 设计的复用n主要问题之四n尽可能复用可得到的部件需要清楚的详细说明的索引n用小组简单会议方式复核设计者的正在开发的功能,更新可复用功能

16、的列表n产品支持经理要为支持可复用部分和保持对它们的完整记录承担责任n产品支持经理在总体设计中和设计及代码检查期间使小组注意力保持在复用上7 小组设计7.5 可用性设计n为每个关键的用户功能制作脚本n分析这些脚本确信它们反映了用户所想要的那种系统n用原型工具建立简单原型,可以帮助你更清楚了解功能7 小组设计7.6 可测性设计n尝试尽量少的测试代码的设计n进行一个详细的测试计划工作n使用白盒测试和黑盒测试n一般的测试工具n专用的测试代码或设施n设计和开发策略怎样使专门测试代码最小7 小组设计7.7 设计的复核和检查n有效的设计检查需要完全文档化的设计n应该检查每一个设计要素以确保它适当地工作n检

17、查界面n循环的初始化、步进、终止n分析状态行为n有经验的检查人员和检查小组的整体水平7 小组设计7.8 TSP设计草案TSP第一周期的设计:DES1草案目的指导小组完成关于小组开发工程的开发和检查软件设计规范开始标准1)一个开发策略和计划 2)一个完整的被检查过的SRS 概要设计过程生成软件设计详细说明书(SDS),SDS定义了第一周期的产品总体结构:1)主要产品部件和它们的界面规范 ;2)将使用情形分配给部件。SDS还应详细描述:1)文件和消息标准、定义、命名约定 2)设计表示法和标准步骤活动描述1设计过程的复核领导/主管描述:1)设计过程怎样执行 2)一个SDS样本 3)设计的检查怎样指导

18、和报告 4)设计标准和约定 2总体设计开发经理领导小组完成:1)定义第一周期的产品结构 2)对产品部件命名 3)将使用情形分配给部件 4)确定要完成和文档化的设计任务3设计标准质量/过程经理领导努力制做名称词汇表和实际标准4设计任务开发经理领导小组完成:制定SDS文档的大纲和产生SDS文档的工作5任务分配小组领导帮助将任务分配给小组成员并得到成员何时完成这些任务的承诺7 小组设计7.8 TSP设计草案TSP第一周期的设计:DES1草案(续)目的指导小组完成关于小组开发工程的开发和检查软件设计规范步骤活动描述6详细设计说明每个小组成员:1)制作并复核他自己的那部分SDS文档;2)将SDS文档交给

19、开发经理。 开发经理制作一个完整的SDS草案。7集成测试计划开发经理领导小组制作并复核测试计划8设计和集成测试计划检查质量/过程经理领导小组检查SDS草稿和集成测试计划,以便:1)在设计中包含和加注了每种使用情形; 2)设计是完整的、正确的; 3)集成测试计划是充分; 4)每个问题被记录,修正责任被分配 。以INS表的格式检查文档化,缺陷记录被记录到LOGD中。9设计的更新开发经理得到已经更新的SDS部分并 1)将它们结合成最终的SDS;2)验证对SRS的可追踪性10更新基准产品支持经理以SDS为基准结束标准1)一个完整的被检查了的SDS和集成测试计划;2)设计标准和名词词汇表;3)已更新的S

20、UMP和SUMQ表以及INS检查表;3)已更新的工程笔记本7 小组设计7.8 TSP设计草案TSP第n周期的设计:DESn草案目的指导小组完成关于第二个或后继的开发和检查软件设计规范开始标准1)小组有已更新的开发策略、计划和SRS 概要对后继周期的设计过程产生一个更新的SDS,SDS定义了1)第二或后继周期的产品总体结构;2)新的或修改过的产品部件;3)已更新的部件界面的详细说明 ;4)将新的使用情形(即功能)分配给部件。 在这个周期,小组还更新了:1)文件和消息标准、定义、命名约定 2)设计表示法和标准步骤活动描述1设计过程的复核领导/主管描述这个周期的设计过程:1)产品升级要考虑的事情;2

21、)共同的升级问题和陷阱;3)前一个周期的设计过程、方法或标准中的问题在这个周期被纠正 2总体设计开发经理领导小组完成:1)定义下一个开发周期的产品结构 2)为新的产品部件命名 3)将新用户使用情形分配给新的或修改过的部件 4)确定要完成和文档化的设计任务3设计标准质量/过程经理领导努力制做名称词汇表和实际标准4设计任务开发经理领导小组完成:制定SDS文档的大纲和产生SDS文档的工作5任务分配小组领导帮助将任务分配给小组成员并得到成员何时完成这些任务的承诺7 小组设计7.8 TSP设计草案TSP第n周期的设计:DESn草案(续)目的指导小组完成关于小组开发工程的开发和检查软件设计规范步骤活动描述

22、6详细设计说明每个小组成员:1)制作并复核他自己的那部分SDS草案;2)将SDS文档交给开发经理。 开发经理制作一个完整的SDS草案。7集成测试计划开发经理领导小组制作并复核集成测试计划8设计和集成测试计划检查质量/过程经理领导小组检查已更新的SDS草稿和集成测试计划,以便:1)在设计中包含和考虑了每个新的使用情形; 2)设计的变化是完整的、正确的; 3)集成测试计划是充分; 4)每个问题被记录,修正责任被分配 。以INS表的格式检查文档化,缺陷记录被记录到LOGD中。9设计的更新开发经理得到已经更新的SDS部分并 1)将它们结合成已更新的最终的SDS;2)为使用情形交叉引用更新产品元素;3)

23、为改变控制提交SRS10更新基准产品支持经理以更新了的SDS为基准结束标准1)这个周期有一个完整的被检查了的SDS文档;2)已更新的SUMP和SUMQ表以及INS检查表;3)已更新的名词词汇表和工程笔记本7 小组设计引用功能周期LOC周期小时数123123计数器1.1A2.3B4.7C 部件分配的STRAT表格 姓名: 小组: 日期: 周期: 部件/层次: 部件第二部分: TSP过程n启动过程(3)n开发策略(4)n开发计划(5)n需求分析过程(6)n设计过程(7)n实现过程(实现过程(8)n测试计划(9)n事后分析(10)8 产品实现8.1 设计完成标准n在开始实现之前,检查是否真真完成了总

24、体设计n设计应该分为层次n系统n子系统n产品n部件可以开始实现n模块可以开始实现n每个层次都应该有外部规范n基本元素小到可以实现8 产品实现8.2 实现标准n标准的复核n命名、界面、消息标准n编码标准n惯例、注释、删除等n大小标准nLOC、SRS、SDS、详细设计、屏幕和报告、数据库、信息、测试草案等n度量:重要的产品类型所用时间的大小度量并能从中得到收益n缺陷标准n缺陷类型的划分n缺陷类型的划分应该有助于过程改进n缺陷类型标准仅当它们很少时才有用n预防标准n缺陷原因的理解有助于预防缺陷n关键在于寻找可以预防缺陷的改变在工程初期用少量时间定义标准,在工程初期用少量时间定义标准,以后就能节约大量

25、时间。以后就能节约大量时间。8 产品实现8.2 实现标准n预防缺陷的措施n教育:学习有关语言、环境和应用的更多知识;n交流:修正这个过程;n事务处理:使用更好的工具;n监督:改善你的过程,使用更好的方法。n分析缺陷原因的方法n选择出那些看来引起绝大多数麻烦的缺陷类型;n检查这种类型的一些缺陷来确定专门的缺陷原因,决定应强调哪些原因;n当你看到一个你认为自己能避免的缺陷时,你要做出一个过程改变来避免它;n如果这种方式有效,则开始寻找下一个缺陷类别。8 产品实现8.3 实现策略n实现策略通常应和设计策略保持一致n复核n在设计时,从大局大局入手逐渐深入深入到细节细节n在复核时,从细节细节入手逐渐拓宽

26、拓宽到大局大局n复用n遵循惯例n检查复用库n测试n在实现之前复核开发策略以确信程序实现的循序与测试计划一致8 产品实现8.4 复核和检查n以下几点适合于复核和检查n随机缺陷编辑错误n随机缺陷对测试的影响随机缺陷难于通过测试发现,如设计测试用例,要用所有的程序路径和可能的数据n详尽测试的困难随机缺陷导致了程序的无逻辑性n对源程序的复核和检查发现一个复杂的设计缺陷是困难的,因为有文档和编码细节。8 产品实现TSP第一周期的实现:IMP1草案目的指导小组实现和检查周期1的软件产品开始标准1)一个开发策略和计划 (1)SRS和SDS规范和名称词汇表(2)代码和其他标准概要实现过程完成了一个复核过、检查

27、过、被单元测试过的产品,它必须(1)完全包含了SDS、SDS的功能和使用情形;(2)符合确定的编码和设计标准;(3)遵循PSP过程步骤活动描述1实现过程综述领导/主管简介过程:1)质量实现的重要性;(2)编码标准的必要性和包含内容;(3)处理低质量部件的策略 2实现计划开发经理领导小组完成:1)定义和计划实现任务(SUMP,SUMQ)3任务分配小组领导在小组成员中分配任务,并 (1)获得关于他们何时完成这些任务的承诺4详细计划工程师们完成细节设计(1)使用完全的设计复核方法完成设计复核(2)完成LOGD和LOGT表格5单元测试计划工程师们制定出单元测试计划6测试计划工程师们按照UT草案开发单元

28、测试条件、测试过程和测试数据8 产品实现TSP第一周期的实现:IMP1草案(续)目的指导小组实现和检查周期1的软件产品步骤活动描述7详细设计检查质量/进度监督经理领导小组对每个部件进行DLD检查(INS草案、INS表格和LOGD)8编码工程师们完成部件源代码(1)使用个人检查表来完成代码复核(2)编译并修改代码,直到编译不再出错(3)完成表格LOGD和LOGT9代码检查质量/进度监督经理领导小组完成对每个部件的DLD检查(INS草案、INS表格和LOGD)10单元测试工程师们按照UT草案(1)进行单元测试,完成LOGD和LOGT表格11部件质量复核质量/进度监督经理领导小组复核每个部件的数据,

29、以确定部件质量是否符合确定的小组标准(1)如果符合则部件可以接受集成测试(2)如果不是,则质量过程经理建议:(1)产品重新检查并返工;(2)或彻底摒弃,重新开发12部件执行当部件都令人满意地实现和检查后,工程师们就把他们交给技术支持经理;技术支持经理将这些部件加入配置管理系统结束标准1)完成的、检查过的配置控制部件(2)完成的设计和编码检查INS表格(3)单元测试计划和支持材料(4)已更新的SUMP、SUMQ、SUMS、LOGD、LOGT表格(5)已更新的工程笔记本8 产品实现TSP错误记录日志:错误记录日志:LOGD表格表格姓名: 日期: 组别: 部件/层次: 周期: 日期编号类型引入排除处

30、理时间处理错误描述:描述:发现错误的日期错误类型引入错误的时间排除错误的时间处理错误的时间记录在处理另一个错误时引入的本错误编号,或计入X错误编号简洁描述该错误,如果该错误是前面的周期里引入的,请给出该周期的编号使用本表格来维护关于你发现和纠正的错误的数据8 产品实现TSP时间记录日志:时间记录日志:LOGT表格表格姓名: 日期: 组别: 部件/层次: 周期: 日期开始停止中断时间时间增量阶段/任务部件注释输入你记录下该条的日期使用本表格来记录用于每项工程任务的时间从事该项工作的停止时间记录下所有中断的时间记录实际用于该项任务的时间输入你所从事的阶段或工作名称或其他标识如果该项任务是一个独立产

31、品,则输入该产品名任何与众不同的详情从事该项工作的开始时间TSP检查报告:检查报告:INS表格表格姓名: 日期: 小组: 部件/层次: 周期: 检查人: 所有人:工程师数据工程师数据姓名错误预备数据预计收益主要次要大小时间速度总计错误数据错误数据编号错误描述错误工程师(发现主要错误的)主要次要AB总计独有错误主要是指修改了源代码的错误检查小结检查小结 产品大小: 大小度量标准:A错误总计: B错误总计: C(一般):错误总计(AB/C): 发现的数量(A+B-C): 剩下的数量:会议时间: 总检查小时数: 全面评价:重大和细微缺陷编号检查的源代码LOC、行数或页数,时间,速度(LOC、行数或页

32、数/小时数)检查员的姓名缺陷编号,通常用文本行号和页码勾选发现缺陷的每个工程师文本页数或伪码行数或源代码LOC确定单独发现缺陷最多的工程师,并在A列列出其发现的每一个缺陷;在B列列出其他工程师发现的缺陷统计A列和B列都有的缺陷数C估计产品中的总缺陷数检查中发现的总缺陷数余下缺陷数= (AB/C)- (A+B-C)当A4、B4且A-C1、A-B1时这种估计方法有效确定单独发现缺陷最多的工程师有多个,重复下列计算,并以得到的最大值作为估算的总缺陷数估计产品中遗留的缺陷数8 产品实现TSP第一周期的实现:IMPn草案目的在小组开发过程中指导一个小组实现和检查周期2或后继周期的软件产品开始标准1)小组

33、已升级了开发策略和计划 (1)SRS和SDS规范和名称词汇表概要实现过程完成了一个产品,它必须(1)被彻底地复核、检查并被单元测试过; (2)完全包含了SDS、SDS的功能和使用情形; (3)符合确定的编码和设计标准;步骤活动描述1实现过程综述领导/主管简介过程:1)提高产品质量时需要考虑的问题;(2)任何在前面周期中实现过程、方法或标准中出现,并且需要在本周期中改正的问题2实现计划开发经理领导小组完成:1)定义和计划实现任务(SUMP,SUMQ)3任务分配小组领导在小组成员中分配任务,并 (1)获得关于他们何时完成这些任务的承诺4详细计划工程师们完成细节设计(1)使用严密的设计复核方法完成设

34、计复核(2)完成LOGD和LOGT表格5单元测试计划工程师们制定出单元测试计划6测试计划工程师们按照UT草案开发单元测试条件、测试过程和测试数据8 产品实现TSP第一周期的实现:IMP n草案(续)目的在小组开发过程中指导一个小组实现和检查周期2或后继周期的软件产品步骤活动描述7详细设计检查质量/进度监督经理领导小组对每个部件进行DLD检查(INS草案、INS表格和LOGD)8编码工程师们完成部件源代码(1)使用个人检查表来完成代码复核(2)编译并修改代码,直到编译不再出错(3)完成表格LOGD和LOGT9代码检查质量/进度监督经理领导小组完成对每个部件的DLD检查(INS草案、INS表格和L

35、OGD)10单元测试工程师们按照UT草案(1)进行单元测试,完成LOGD和LOGT表格11部件质量复核质量/进度监督经理领导小组复核每个部件的数据,以确定部件质量是否符合确定的小组标准(1)如果符合则部件可以接受集成测试(2)如果不是,则质量过程经理建议:(1)产品重新检查并返工;(2)或彻底摒弃,重新开发(如图所示)(如图所示)12部件执行当部件都令人满意地实现和检查后,工程师们就把他们交给技术支持经理;技术支持经理将这些部件加入配置管理系统结束标准1)完成的、检查过的配置控制部件(2)完成的设计和编码检查INS表格(3)单元测试计划和支持材料(4)已更新的SUMP、SUMQ、SUMS、LO

36、GD、LOGT表格(5)已更新的工程笔记本8 产品实现n成员质量图帮助帮助判断质量判断质量n区域说明n1完好n2设计重新检查n3代码重新检查n4程序返工1232和3编译缺陷数/KLOC单元测试 缺陷数/KLOC55010204第二部分: TSP过程n启动过程(3)n开发策略(4)n开发计划(5)n需求分析过程(6)n设计过程(7)n实现过程(8)n测试计划(测试计划(9)n事后分析(10)9.集成和系统测试9.1 测试原则n在TSP中,测试的目的是为了评估产品,而不是为了修正它;n在测试阶段前你应该已经发现和修正了几乎全部的缺陷;n一个产品的质量是在它被开发时决定的;n当你测试一个质量差的产品

37、时,测试之后得到的仍是质量差的产品。9.集成和系统测试9.2 测试策略n在TSP中,目标是对优质程序进行测试n在测试中,验证这个产品是否是高质量的n主要的TSP测试活动如下n使用已开发的单元测试过的部分来建立系统n集成测试这个系统来验证它是否被适当地建立起来了,所有的部分是否都存在,以及它们是否能共同工作n系统测试这个产品来确认它满足了系统需求n确认质量差的模块或部件以及确认那些除去缺陷之后仍令人头疼的质量差的部件,返还给质量/进度监督经理进行返工或替换9.集成和系统测试9.3 建立和集成策略n建立过程的目的是保证有所需要的部分n装配好一个工作系统,且为这个系统提供好集成测试和系统测试nBig

38、-Bang策略n将所有部分放在一起来观察它们是否能工作n对于大的、复杂的、质量不高的系统该策略不好n每次一个策略n每次添加一些部分,能够发现添加部分的问题n聚类策略n每次以类的方式添加部分,这能减少对专门的测试驱动或设施的需求n平面系统策略n每次集成一层,然后逐层往下进行,能发现早期系统的范围的问题9.集成和系统测试9.4 系统测试策略n系统测试的目标n系统是否展示了其被要求具备的功能?n系统是否达到了它的质量目标?n在正常情况下系统是否能适当地运作?n在非正常情况下系统是否能适当地运作?n相关问题n安装与启动?要求的功能?可恢复?响应时间?吞吐量?容量?方便?9.集成和系统测试9.4 系统测

39、试策略n制定策略(4种)n首先测试系统每一个预期的功能n重点条件下检查操作、评价可用性n关注选择出来的功能区n功能区中的每个方面n没有充分检查系统的整体的执行情况n从低层次到高层次(自底向上)n正常情况、不正常情况、重点条件下n从高层次到低层次(自顶向下)n及早了解系统问题9.集成和系统测试9.5 测试计划n完整的测试计划应该包括n运行什么测试n运行顺序n所需测试材料n测试草案或脚本如何覆盖需求区域n哪些需求区域已被详细测试过n对每个预期的测试命名、产生的效果、运行时间n估计在每个测试阶段发现的缺陷数、修改缺陷时间、总共的测试时间n交互测试、测试数据、测试草案等等9.集成和系统测试9.5 测试

40、计划n在结束测试计划时,应该有(1)n所有要执行的测试步骤清单n每个测试所需要的支持材料n测试产生的结果n估计每个测试的无缺陷运行时间,发现的缺陷数,以及总时间n在测试计划中要求开发的每个条款所需的工作的估计9.集成和系统测试9.5 测试计划n在结束测试计划时,应该有(2)n所有需要的测试支持材料和它们支持的测试n每个测试的目标n期望这些材料是多大n它们的开发可能要用多长时间n由谁开发每个测试的支持条款n这些开发任务何时完成n最后开发测试材料n包括自检的测试情况n需要一系列完整的测试工具9.集成和系统测试9.6 跟踪和度量测试n如果你预期运行许多测试,你将需要关于测试有效性的数据每个测试揭示出

41、多少个每个测试揭示出多少个缺陷缺陷n使用这些缺陷/小时数据作为选择测试的标选择测试的标准准包括反复测试的地址n因为在每个TSP开发周期中你将运行一个完整的测试集,所以有一些测试的度量测试的度量是有用的9.集成和系统测试9.6 跟踪和度量测试1)测试日志日期测试/阶段产品开始时间停止时间中断时间测试净时间问题注释测试日志样本:测试日志样本:LOGTEST表表姓名: 日期: 小组: 部件/层次: 周期: n测试的附加信息n被测的系统配置n任何使用了的特殊工具和设施n操作员的干涉是否需要,需要多少9.集成和系统测试9.6 跟踪和度量测试2)有缺陷倾向的模块n在测试中你发现的缺陷越多,那么你没有发现的

42、缺陷也就越多n将模块的缺陷数据排序来发现每次测试中哪个模块有最多的缺陷n如果一些模块看来特别差,应暂时停止测试来检查n在继续测试之前,再检查和修正这些有缺陷倾向的部件/模块9.集成和系统测试9.6 跟踪和度量测试3)有缺陷倾向的模块的确定nSUMDR表格在左边的栏目中列出了模块号和名称,在右边列出了各阶段排除的缺陷数量n制作一个对单个模块的质量测试的SUMQ表n有了这些数据,可以确定有缺陷倾向的部件/模块n通过每个周期的清除缺陷阶段,可以确定一个模块问题开始出现的那个阶段9.集成和系统测试9.6 跟踪和度量测试4)追踪缺陷数据n为追踪和分析有缺陷倾向的模块,你需要每个测试的有关每个缺陷的数据n

43、在每个星期的会议上和整个小组复核复核在建立、集成测试、系统测试中发现的缺陷,这些缺陷逃过了整个开发过程:n缺陷跳过了哪些过程?n怎样改变步骤以免缺陷不再发生?n怎样修改开发过程来预防缺陷发生?n在系统哪里存在未发现的类似缺陷?n现在你怎样发现这些缺陷并修改它们?9.集成和系统测试9.7 文档n文档是每个软件产品的必需部分,没有文档的程序是无用的n把一个功能文档化的最佳时机是在你设计完它之后n用户手册不是围绕产品设计而组织的n文档应该关注:n使用词汇表来定义不在标准词典中的条款n应包含关于缺陷消息、故障检修步骤和恢复步骤n提供一个关键论题的索引和一个内容的细节表n应该有一个提纲并应讨论和复核它(

44、内容够吗?准确性、可读性、易懂性)n应该注意书写风格n用新手来测试用户手册,以便发现问题和返工9.集成和系统测试TSP第一周期的集成和系统测试:TEST1草案目的引导小组对进入第一周期的工作系统的集成和测试产品部件开始条件(1)小组有一个开发策略和计划(2)完整的被检查过的SRS和SDS规范 (3)在配置控制下已经实现且被检查和单元测试过的部件概要当在建立、集成或系统测试时发现了缺陷,质量/过程经理决定测试是否继续;每个在集成或系统测试中发现的缺陷记录在缺陷日志中(LOGD)并被整个小组复核以决定:(1)在产品中何处仍可能存在类似的缺陷;(2)怎样发现这些缺陷以及何时修正这些缺陷;(3)过程改

45、变以预防将来有类似的缺陷步骤活动描述1测试过程综述领导/组长描述集成测试和系统测试过程(1)在测试之前对高质量部件的需要(2)测试标准的需要及测试标准的内容(3)处理质量差的部件的策略2测试开发开发经理或其他人来领导测试的开发;小组领导帮助小组成员的测试任务的分配;测试人员执行他们的测试任务(1)定义任何需要的建立过程和程序(2)开发集成测试程序和设施(3)开发系统测试程序和设施(4)对每个测试估计大小和运行时间(5)复核测试材料并纠正缺陷3建立小组建立产品并检查它的完整性(1)验证手中所有的需要的部分(2)建立产品并把它提供给集成测试(3)产品所有者(开发者)在缺陷日志(LOGD)中记录所有

46、的缺陷9.集成和系统测试步骤活动描述4集成开发经理或其他人来领导集成任务:(1)检查完整性并集成测试产品(2)在测试日志(LOGTEST)中记录所有的测试活动(3)产品所有者(开发者)在缺陷日志(LOGD)中记录所有的缺陷5系统测试开发经理或其他人来领导系统测试任务(1)在正常和重点条件下测试产品(2)测试产品的安装、升级和恢复(3)在测试日志(LOGTEST)中记录所有的测试活动(4)产品所有者(开发者)在缺陷日志(LOGD)中记录所有的缺陷6文档开发经理或其他人来领导小组进行(1)制作用户文档提纲和任务(2)将这些任务分配给制作文档小组(3)和测试小组一起复核提纲的完整性(4)起草第一周期

47、的用户文档(5)复核、纠正并制作用户文档结束标准(1)完成的、被检查和控制配置的部件(2)进行设计和代码的检查完成的INS表(3)单元测试计划和支持材料(4)更新的SUMP、SUMQ、SUMS、LOGD、LOGT表(5)更新的项目手册TSP第一周期的集成和系统测试:TEST1草案(续)9.集成和系统测试目的引导小组对下一个周期的工作系统的集成和测试产品部件开始条件(1)小组有一个开发策略和计划(2)完整的被检查过的SRS和SDS规范 (3)在配置控制下已经实现且被检查和单元测试过的部件概要当在建立、集成或系统测试时发现了缺陷,质量/过程经理决定测试是否继续;每个在集成或系统测试中发现的缺陷记录

48、在缺陷日志中(LOGD)并被整个小组复核以决定:(1)在产品中何处仍可能存在类似的缺陷;(2)怎样发现这些缺陷以及何时修正这些缺陷;(3)过程改变以预防将来有类似的缺陷步骤活动描述1测试过程综述领导领导/组长描述前一个周期的集成和测试过程的问题,这些问题在这个周期被组长描述前一个周期的集成和测试过程的问题,这些问题在这个周期被纠正(纠正(1)进行回归测试的原因()进行回归测试的原因(2)如何进行回归测试)如何进行回归测试2测试开发开发经理或其他人来领导测试的开发;小组领导帮助小组成员的测试任务的分配;测试人员执行他们的测试任务(1)定义任何需要的建立过程和程序(2)开发集成测试程序和设施(3)

49、开发系统测试程序和设施(4)对每个测试估计大小和运行时间(5)复核测试材料并纠正缺陷3建立小组建立产品并检查它的完整性(1)验证手中所有的需要的部分(2)建立产品并把它提供给集成测试(3)产品所有者(开发者)在缺陷日志(LOGD)中记录所有的缺陷TSP第n周期的集成和系统测试:TESTn草案9.集成和系统测试步骤活动描述4集成开发经理或其他人来领导集成任务:(1)检查完整性并集成测试产品(2)在测试日志(LOGTEST)中记录所有的测试活动(3)产品所有者(开发者)在缺陷日志(LOGD)中记录所有的缺陷5系统测试开发经理或其他人来领导系统测试任务(1)在正常和重点条件下测试产品(2)测试产品的

50、安装、升级和恢复(3)回归测试系统)回归测试系统(4)在测试日志(LOGTEST)中记录所有的测试活动(5)产品所有者(开发者)在缺陷日志(LOGD)中记录所有的缺陷6文档开发经理或其他人来领导小组进行(1)制作用户文档提纲和任务(2)将这些任务分配给制作文档小组(3)和测试小组一起复核提纲的完整性(4)起草下下一周期一周期的用户文档(5)复核、纠正并制作用户文档结束标准下一周期的已经集成且测试了的系统下一周期的已经集成且测试了的系统(1)对所有测试完成了LOGD和LOGTEST表格; (2)更新了且复核过的用户文档; (3)计入时间、大小和缺陷数据TSP第n周期的集成和系统测试:TESTn草案(续)10.后期维护10.1 为什么需要一个后期维护n软件的提高重复做同样的工作并期待着一个不同的结果n跟上技术步伐n满足更有挑战性的需要n后期维护阶段是一个合适的时间去发现特定的提高机会,决定在哪里和怎样将这些变化融入你个人和小组的过程中去n学会怎样连续改进你个人的工作(个人的做法、改进的工具、过程变化、其他任何方面)10.后期维护10.2 TSP后期维护:PM1草案目的收集、分析和记录工程数据;评价小组和每个角色的工作;找出改进第二周期过程的方法;写出第一周期

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论