2

个人软件过程(PSP) 旨在让软件工程师了解和改进他们的性能。PSP 使用脚本来指导从业者完成整个过程。每个脚本都定义了目的、进入标准、要执行的步骤和退出标准。PSP0 被设计成一个允许启动个人进程的框架。

PSP0 中使用的脚本之一是开发脚本，用于指导开发。一旦有需求陈述、项目计划摘要、时间和缺陷记录日志，以及建立缺陷类型标准，就会使用此脚本。该脚本的活动是设计、编码、编译和测试。当您拥有经过彻底测试的应用程序以及完整的时间和缺陷日志时，脚本将退出。

在代码阶段，您审查需求并进行设计，在日志中记录需求缺陷，并执行时间跟踪。在编译阶段，你编译，修复任何编译时错误，并重复直到程序编译，并记录任何缺陷和时间。最后，在测试阶段，您进行测试，直到所有测试运行没有错误并且所有缺陷都得到修复，同时记录时间和缺陷。

我关心的是在使用现代编程语言（尤其是 Python、Perl 和 Ruby 等解释型语言）和 IDE 时如何管理代码、编译和测试阶段。

我的问题：

  • 在解释语言中，没有编译时间。但是，执行过程中可能会出现问题。在单元（和其他）测试之外执行脚本是否被视为“编译”或“测试”时间？在跟踪缺陷时，执行错误是否应该被视为“编译”或“测试”错误？
  • 如果测试用例遇到语法错误，这是否被认为是代码缺陷、编译缺陷或测试缺陷？测试确实发现了错误，不过是代码问题。
  • 如果 IDE 在实际编译之前识别出会阻止编译的错误，是否应该识别出来？如果是这样，是否应该将其识别为编译错误或代码错误并进行跟踪？

看起来 PSP，至少是 PSP0 基线过程，被设计用于编译语言和使用文本编辑器（而不是 IDE）编写的小型应用程序。除了我的问题，我会感谢任何正在使用或曾经使用过 PSP 的人的建议和评论。

4

5 回答 5

1

一般来说，由于 PSP 是一个个人改进过程，只要您选择一个答案并始终如一地应用它，您的实际问题的答案并不重要。这样，您将能够衡量您在每个定义的阶段所花费的时间，这就是 PSP 所追求的。如果您的团队共同使用 PSP，那么您应该就使用哪些脚本以及如何回答您的问题达成一致。

我对实际问题的看法是（不是相关的）：

  • 在解释语言中，没有编译时间。但是，执行过程中可能会出现问题。在单元（和其他）测试之外执行脚本是否被视为“编译”或“测试”时间？在跟踪缺陷时，执行错误是否应该被视为“编译”或“测试”错误？

对我来说，测试时间是实际测试运行的时间，而不是其他时间。在这种情况下，我会将错误和执行时间都添加为“编译”时间，即用于生成和运行代码的时间。

  • 如果测试用例遇到语法错误，这是否被认为是代码缺陷、编译缺陷或测试缺陷？测试确实发现了错误，不过是代码问题。

语法错误是代码缺陷。

  • 如果 IDE 在实际编译之前识别出会阻止编译的错误，是否应该识别出来？如果是这样，是否应该将其识别为编译错误或代码错误并进行跟踪？

如果 IDE 是您的工具链的一部分，那么它看到错误就像您发现了错误一样，因此也发现了代码错误。如果您不经常使用 IDE，那么我会将它们视为编译错误。

于 2009-09-15T22:31:04.020 回答
1

我用PSP好几年了。正如其他人所说，这是一个个人过程，您需要改进 PSP0 以改进您的开发过程。尽管如此，我们的团队（均受过 PSP 培训）在多个方面努力解决这些问题。让我给你一个有关组件的想法，然后我会说我们是如何管理的。

我们有一个 PowerBuilder“层”；PowerBuilder IDE 甚至阻止您保存您的代码，直到它正确编译和链接。部分系统使用了JSP，虽然Java的数量很少，而且是样板，所以在实践中，我们根本没有计算它。系统的很大一部分是 JS/JavaScript；这是在精彩的 Ajax 库出现之前完成的，并且代表了大部分工作。另一大部分是 Oracle Pl/Sql；这有一个更传统的编译阶段。

在 PowerBuilder 中工作时，编译（和链接）阶段在开发人员保存对象时开始。如果保存成功，我们记录的编译时间为 0。否则，我们记录修复导致编译时缺陷的错误所花费的时间。大多数情况下，这些是在编码中注入的缺陷，在编译阶段被删除。

PowerBuilder IDE 的强制编译/链接方面迫使我们将代码审查阶段移至编译后。最初，这给我们带来了一些困扰，因为我们不确定这种变化如何/是否会影响数据的含义。在实践中，它成为一个非问题。事实上，我们中的许多人也将 Oracle Pl/Sql 代码审查移到了编译阶段之后，因为我们发现在审查代码时，我们经常会掩盖编译器会报告的一些语法错误。

编译时间为 0 没有任何问题，就像测试时间为 0 也没有任何问题（这意味着您的单元测试通过而没有检测到错误，并且运行速度明显快于您的度量单位）。如果这些时间为零，那么您不会删除这些阶段中的任何缺陷，并且您不会遇到 div/0 问题。如果这让您更舒服，或者您的测量需要非零值，您还可以记录名义上的最短 1 分钟。

您的第二个问题与开发环境无关。当您遇到缺陷时，您会记录您将其注入到哪个阶段（通常是设计或代码）以及您删除它的阶段（通常是设计/代码审查、编译或测试）。这为您提供了称为“杠杆”的度量，它表明在特定阶段消除缺陷的相对有效性（并支持“常识”，即尽早消除缺陷比在过程中稍后消除缺陷更有效）。注入缺陷的阶段是其类型，即设计或编码缺陷。去除缺陷的阶段不会影响其类型。

同样，对于 JS/JavaScript，编译时间实际上是无法估量的。我们没有记录编译阶段的任何时间，但话又说回来，我们没有删除该阶段的任何缺陷。大部分 JS/JavaScript 缺陷是在设计/编码中注入的，并在设计审查、代码审查或测试中删除。

于 2010-09-27T14:16:56.490 回答
0

这听起来，基本上，就像你的正式过程与你的练习过程不匹配。退后一步，重新评估你在做什么以及是否应该选择不同的正式方法（如果实际上你需要一个正式的方法开始）。

于 2009-09-15T21:53:34.643 回答
0
  • 在解释语言中，没有编译时间。但是，执行过程中可能会出现问题。在单元（和其他）测试之外执行脚本是否被视为“编译”或“测试”时间？在跟踪缺陷时，执行错误是否应该被视为“编译”或“测试”错误？

错误应根据创建时间进行分类，而不是根据您找到它们的时间。

  • 如果测试用例遇到语法错误，这是否被认为是代码缺陷、编译缺陷或测试缺陷？测试确实发现了错误，不过是代码问题。

和上面一样。总是回到最早的时间点。如果语法错误是在编码时引入的，那么它对应于编码阶段，如果它是在修复错误时引入的，那么它处于缺陷阶段。

  • 如果 IDE 在实际编译之前识别出会阻止编译的错误，是否应该识别出来？如果是这样，是否应该将其识别为编译错误或代码错误并进行跟踪？

我认为不应该被识别。这只是花在编写代码上的时间。

附带说明一下，我使用 Process Dashboard 工具来跟踪 PSP 数据并发现它非常好。它是免费的并且基于 Java，因此它应该可以在任何地方运行。你可以在这里得到它：http: //processdash.sourceforge.net/

于 2009-09-15T22:46:46.483 回答
0

在阅读了Mike Burton、Vinko Vrsalovic和JRL的回复并重新阅读了 PSP: A Self-Improvement Process for Software Engineers 中的相应章节后，我对这些问题提出了自己的看法。然而，好的是我在书中找到了一个我最初在两页粘在一起时错过的部分。

  • 在解释语言中，没有编译时间。但是，执行过程中可能会出现问题。在单元（和其他）测试之外执行脚本是否被视为“编译”或“测试”时间？在跟踪缺陷时，执行错误是否应该被视为“编译”或“测试”错误？

根据这本书，它说“如果您使用的是不编译的开发环境，那么您应该跳过编译步骤。” 但是，它还说，如果您有构建步骤，“您可以在编译阶段记录构建时间和任何构建错误”。

这意味着对于解释型语言，您将从跟踪中删除编译阶段或用构建脚本替换编译。因为 PSP0 通常用于小型应用程序（类似于您在大学实验室中所期望的），所以我希望您不会有构建过程并且会简单地省略该步骤。

  • 如果测试用例遇到语法错误，这是否被认为是代码缺陷、编译缺陷或测试缺陷？测试确实发现了错误，不过是代码问题。

我会记录错误所在的位置。

例如，如果一个测试用例有缺陷，那将是一个测试缺陷。如果测试运行，并且在被测试的应用程序中发现错误，那将是代码或设计缺陷，具体取决于问题的实际来源。

  • 如果 IDE 在实际编译之前识别出会阻止编译的错误，是否应该识别出来？如果是这样，是否应该将其识别为编译错误或代码错误并进行跟踪？

如果 IDE 识别出语法错误，则与您在执行之前实际发现错误相同。正确使用 IDE，几乎没有任何借口可以让会影响执行的缺陷（例如，导致应用程序执行的错误，而不是逻辑/实现错误）通过。

于 2009-09-15T23:14:19.413 回答