小组软件开发过程ppt课件

第八章产品的实现，本章介绍了实现过程，从设计完成标准、实现标准、实现战略、探讨和检验开始。 然后根据IMP1和IMPn的草案进一步描述TSPi的实现过程。 1，8.1设计完成标准，在开始实现之前，先检查你是否真的完成了整体设计。 在大系统中，总体设计往往需要一些阶段。 在第一层，系统分为子系统、部件和模块。 此任务必须使用第7章中介绍的DES1或DESn过程中的步骤。 最后，必须对每个子系统、部件或模块进行外部详细说明，以提供系统的最高级别的详细设计。 2、2、2,8.1.1设计层次，如果这些子系统相当大，则各个子系统和部件应该重复整个设计过程。 最后，每个子系统部件都需要一个外部规范，而且还需要为子系统成员进行最高级别的详细设计。 根据系统的大小，重复这个过程。 最后得出系统最底层原子模块的外部规范。 那是你从总体设计进入实现的时候了。 对于真正的大型系统，连续的系统级别可以是.系统、子系统、产品、部件和.模块。 3、重复所述设计过程直到获得系统的真正基本要素的外部规范为止。 这些元素小到可以直接实现的程度，通常为150以下的LOC大小。 虽然这些模块可能包含较低级别的目标和程序，但这些附属程序并不是很小，它们可能是开发、多路复用或可用的库功能。 虽然要达到最低级别的详细说明可能需要很多努力，但是请重复DES1和DESn草案，除非您准备好进入实现阶段。 但是，在大型系统中，在完成其他部分的设计之前，可能需要实施特定的产品元素。 4、4、4,8.1.2的并行实现，有充分的开发团队，完成部件的外部规范后，即可实现。 尽管在定义最高级别的所有规范之前，实现系统的所有部分都存在风险，但是通过将大型系统分割为部件，在成员的外部规范完成并检查之后实现，可以将风险降至最低。 如果开发周期短很重要的话，这个方法可以大幅节约时间。 实现5，8.2标准，关于标准的重要性可以说很多，但实际上开发和使用标准不应该占很多时间。 在施工初期用少量时间定义标准，以后可以节省很多时间。 首先，如果一个小组对于必要标准的意见一致，我们会分配一两个小组成员来开发这个草案。 然后，小组可以有效地讨论这个草案，使他们使用的具体标准内容一致。 质量进展监督管理人员指导组制定这些标准的活动。 实现标准，追加扩大了设计阶段定义的标准。 在一些部分，我们正在研究这些标准问题：6，标准研究.命名，接口和消息标准：代码标准；预防尺寸标准缺陷标注缺陷。 通常，预防缺陷不被视为标准问题，但由于其与缺陷标准密切相关，因此在此进行讨论。 注意7、7、7,8.2.1标准的探讨、实用性。 如果您认为建议的标准有用，请使用它，在完全了解之后再进行改进。 不要第一次制定完美的标准。 在讨论抽象建议时很容易浪费很多时间。 以合理的草案为出发点，试用后再更新，可以在很少的时间内制定出好的标准。 考虑在设计阶段完成的命名、接口和信息标准，以确保它们仍然合理、正确地使用。 它还检查可重复使用的程序列表是否完整，以及所有团队成员是否正在使用它们。 8、然后，复查命名词汇表，确保所有人在同一条款中使用相同的名称，并且在词汇表中记录整个系统的名称。检查零件和子元素的名称，并检查共享的变量、参数和文件名是否匹配。 此外，检查接口和消息以确保所有系统中的外部接口和消息都已定义、记录在术语表中，并且已被所有团队成员理解和使用。 9，9，8.2.2编码标准，如果计划使用PSP课程中使用的语言，可能会使用相同的编码标准。 但必须确保整个小组同意使用相同的标准。 共同的编码标准确保团队的所有代码看起来相同。 这种一致性使代码检查更快、更高效。 细心构建的编码标准还定义了注释规则。 良好的注释约定加速了代码的探讨，使在今后的开发周期中升级变得容易。 通用的编码标准还可以简化团队成员之间的代码共享。 如果程序看起来像是你写的代码，使用相同的规则或注释规则，可能正考虑在程序中对其进行多路复用。 此类复用通常可节省许多设计和实现时间。 的双曲馀弦值。 需要10、8.2.3尺寸标准、共同的组标准。 如果不同意设计阶段的标准，请立即制定标准。 除LOC外，大多数项目都生产SRS和SDS文档等几种产品。 TSPi建议您使用页数来测量文档的大小。 以下产品元素可能需要测量尺寸。 需求文件(SRS )整体设计文件(SDS )细节设计.画面和报告.测试数据库.信息草案和测试资料。 11、如果需要，可以使用文章页数、段落数和shall进行计数。 shall定义计划产品所需的功能。 shall描述通常用于表示预期功能。 例如，“4.M是某行的代码被删除时，程序在该行被删除的地方用注释保存被删除的行”的整体设计的最简单的测量方法是模板的页数、文本行数、使用状况。 在详细的设计中，伪代码行数是一种测量方法。 对于小程序，使用LOC进行估计。 然后，如果有实际的LOC数，则使用实际的LOC测量详细的设计产品的大小。 12、8.2.4测量其他类型产品的大小，其馀部分比较困难。 如果你的团队在一个学期的课程中实现了相对较小的产品，可能不需要考虑文本页数和LOC以外的大小的测量。 为了制作这个产品我不得不集中精力。 如果还需要额外的测量，请考虑两个问题。 第一，时间用于表示工程整体工作的重要部分的产品类型吗？ 否则，工程从测量中获得的收益小或无。 有关工程的工作可能这么小，无法判断有关大小的估计和计划。 想测量大小的主要原因是有助于工作的估算和追踪。 如果某种产品类型的工作只是总工作的一小部分，则无需知道大小的估计，只需估计工作所需的时间。 13、假设某种产品类型代表工作的重要部分，则需要测量此产品开发所需时间的大小。 那样的测量就足够了。 如果不行，只能用产品要素的数量作为尺寸的估算。 例如，对于屏幕，使用屏幕数和开发1个屏幕的平均经验时间进行估算。 对于相当多的数据，PSP可以使用与目标LOC所使用的流程相同的流程。 把这些画面数据分成几个类。 PSP中使用的方法将数据分为特小(VS )、小(s )、中(m )、大(l )、特大(VL )的类别。 请把你的经验数据分成这些班级，给每个班级制定平均开发时间。 如果有很多数据，可以将这些产品数据分为多种类型，如数据输入、菜单选择等。 14、然后，在计划时，估计需要多少画面，判断进入这5个类别的有多少。其他大小的测量也可以使用同样的方法。 有关如何以这种方式估计大小和使用大小数据的信息，请参见软件工程规则。 15、8.2.5缺陷标准、标准的PSP缺陷类型应该足以满足您的需求。 但是，PSP没有讨论测试资料的缺陷。 在创建新的缺陷类型之前，请考虑以下几点。 第一，有无数种定义缺陷类型的方法。 因此，你和你的团队成员可能会花费时间讨论喜好的类型。 其次，将缺陷分为几类，目的是帮助分析和改进开发过程。 虽然缺陷类型有助于对大量的缺陷数据进行分类，但是必须仔细查阅关于特定缺陷的报告以改善流程。 做这件事的共同步骤是首先分析你的数据确认重要的类型。 针对个别的缺陷类型(例如类80的功能缺陷)，详细地检查特定的类80缺陷报告中哪种类型正在引起问题的大部分。 在确定关键问题区域时(例如，仅缺少一个问题)，必须确定如何在设计和编码方面发现这些缺陷。 然而，将类别80分解成多个子类别是困难的。 因为其他类别包括很多情况。 如果有足够的分解可以避免此问题，则会有一个非常大的缺陷类型列表。 该名单只能用于研究，不值得实用。 第17、第3，缺陷类型的标准仅在它们较少时有效。 标准中的类型越多，选择缺陷类型时所犯的缺陷就越多，各缺陷的分类和记录需要时间。 这表示只有在有足够的新类型的缺陷数据时，才需要将其添加到PSP标准中。 许多人把缺陷的原因和缺陷类型混为一谈，认为缺陷类型是不完整的需求，是贫乏的应用知识，对设计的误解和语言缺乏经验。 这些不是缺陷类型，而是缺陷的原因。 例如，大多数早期未修复的需求缺陷导致了最终产品的功能缺陷。 虽然此类缺陷可发生于需求分析阶段中，且通常归因于较少定义的需求，但缺陷类型通常为数据(70 )、功能(80 )或系统(90 )。 18、8.2.6预防缺陷，了解缺陷原因有助于预防缺陷。 很难对缺陷原因进行分类。 回顾特殊缺陷报告，理解问题，找到预防办法。 这里的困难很普遍。 为了限制原因类型的数量，这些类型必须非常普通，但不能制定普通原因的预防措施。 19、建议从以下四类开始： 教育：学习更多关于语言、环境、应用的知识交流：修正这个过程的事务处理：使用更好的工具.监督：改善你的过程，使用更好的方法。 20、预防缺陷有很多分析缺陷原因的方法，笔者发现以下方式是最有效的。选择引起几乎所有问题的缺陷类型。 这些缺陷可能浪费大部分测试时间，诊疗和修正困难，甚至令人厌烦。检查此类缺陷，确定特定缺陷的原因，并决定应强调哪些原因。看到自己认为可以避免的缺陷时，为了避免缺陷必须改变程序。如果这个方法有效的话，就开始寻找下一个缺陷类别，进行同样的处理。21、预防缺陷的关键是寻找可以预防缺陷的变化。 然后在你的过程中把这些变化结合起来。 下一步是跟踪和执行这种变化是如何工作的。 如果这些缺陷类型仍然存在，请确定以前变化无法正常工作的原因，然后重新调整。 知道缺陷的原因后，填写LOGD表的注释。 但是，如果以相同的标准混淆缺陷类型和缺陷原因，则数据是浪费的。原因是缺陷类型不能按频率排列，因为相同的缺陷类型可能出现在若干不同的位置。 实现22、8.3战略，实现战略通常应与设计战略一致，即应与设计方法一致实现程序。 为避免实现和测试问题，建议考虑以下三个主题。审查.多路复用：测试。23、8.3.1实现战略：探讨、设计时应从大局逐步深入。 但是在讨论时，必须考虑从细节向大局扩展。 笔者发现的最有效的策略是从下面探讨。 首先，考虑所有没有从属部分的最低层对象。 如果确信这些原子的对象符合外部的说明，就进入下一个水平。 当您在下一层考虑这些对象时，您可以信任它们，不必再考虑它们。 为了遵从最底层的策略，要实现同样的事情，首先从最低层次的对象开始，然后移动到稍高一点的层次。 这通常是查看最低级别对象规范问题的最快方法。 通过尽早发现这些详细说明的问题，可以在广泛实现之前进行修正。 这项工作还可以节省大量的测试和重做时间。 最下层的原子对象最容易被再利用，所以来自底部的实现战略也容易被再利用。24、8.3.2实现战略：多路复用，遵循一些简单的实现规则，使程序的多路复用更加容易。 例如，对每个源程序采用标准注释头。 此标题应集中提供所有重要的使用信息，以便潜在用户能够快速了解此程序正在进行什么操作。 用户部分从程序名和紧跟在标志块下面的源代码列表的开头开始。 用户部分简要说明该程序正在做什么，详细说明调用和返回格式，并命名所有变量和参数。 决定变量的范围、类型和形式，记述变量值的限制、溢出条件、精度限制等其他条件和警告。 应用“粗体大写”(BOLDCAPITAL )将列出所有这些限制，以免丢失。 每天短小的小组会议讨论实现计划，可以提高多路复用。 在讨论中，检查再利用库，询问别人是否有你需要的再利用对象。 也观察正在开发的对象中是否有其他人可以使用的东西。 如果适用，请命名产品支持经理，将其添加到重复使用列表中，并附加功能规范。 每天几分钟做这个可以大幅节省实现时间。 25、8.3.3实现战略：测试、开发战略应注意的地方是测试可能性。 因此，在实现之前，先研究开发战略，确信程序的实现顺序与你的测试计划一致。26、8.4探讨和检验，8.4.1随机缺陷多为按钮随机缺陷造成的简单打字错误。 按下每个LOC的键时发生28个错误。 此外，这些错误与程序逻辑无关。 因为这些按钮的随机缺陷是不合逻辑的。 随机地分散在程序中。 这些惊人的错误在编程语言的规则中产生了无效的代码。 因此，编辑器无法发现这些类似句的错误。 c 10编辑器只能发现造句和造句相似错误的9.4%。 编辑后，在你的程序中，每千LOC约有23个随机按钮错误。 27、8.4.2对测试的影响，在200loc程序中，这些数量的随机缺陷似乎并不重要。 即使是5000LOC的小系统，也只添加了1015个逻辑缺陷和代码缺陷。 但是，在测试时发现这些缺陷是非常困难的。 由有经验的工程师开发的4000LOC计划需要两个月的时间进行系统测试，以便在系统测试中发现并修复38个缺陷。 另一个使用PSP和TSP开发的8000LOC的业务流程只有一个缺陷，系统测试需要一周时间。随机缺陷的发现是困难的。 因为测试只能用于发现在专业的测试环境中遇到的缺陷。 因此，为了保证发现所有随机缺陷，必须使用所有程序逻辑路径，在所有可能的数据和操作环境中进行测试。 28，8.4.3详细测试困难，为了广泛测试59-LOC程序，需要67种测试环境，368条逻辑路径，65536个数值。 这些只是为了59LOC。 这些联盟中的很多在逻辑上是