Personal Software Process（PSP）旨在让软件工程师了解并改进其性能。 PSP使用脚本来指导从业者完成整个过程。每个脚本都定义了目的，条目标准，要执行的步骤以及退出条件。 PSP0旨在成为一个允许启动个人流程的框架。
PSP0中使用的一个脚本是开发脚本，用于指导开发。一旦有需求声明，项目计划摘要，时间和缺陷记录日志，并建立缺陷类型标准，就会使用此脚本。该脚本的活动包括设计，代码，编译和测试。当您拥有经过全面测试的应用程序以及完整的时间和缺陷日志时，将退出该脚本。
在“规范”阶段，您将查看要求并进行设计，在日志中记录要求缺陷并执行时间跟踪。在编译阶段，您编译，修复任何编译时错误，并重复直到程序编译，并记录任何缺陷和时间。最后，在测试阶段，您将进行测试，直到所有测试都运行正常且所有缺陷都已修复，同时记录时间和缺陷。
我关注的是如何在使用现代编程语言（特别是Python，Perl和Ruby等解释语言）和IDE时管理代码，编译和测试阶段。
我的问题：
似乎PSP（至少是PSP0基线流程）设计用于编译语言和使用文本编辑器（而不是IDE）编写的小应用程序。除了我的问题，我将非常感谢任何正在使用或使用过PSP的人的建议和评论。
答案 0 :(得分：1)
一般而言，由于PSP是个人改进流程，只要您选择一个答案并始终如一地应用，您实际问题的答案就无关紧要了。这样你就可以测量你在每个定义阶段所花费的时间，这就是PSP所追求的。如果您的团队共同使用PSP，那么您应该同意使用哪些脚本以及如何回答您的问题。
我对实际问题的看法（并非它们是相关的）：
- 在解释型语言中，没有编译时间。但是，有可能 是执行中的问题。正在执行 脚本，在单位之外（和 其他）测试，被认为是“编译”或 “测试”时间？应该有错误 执行被认为是“编译”或 跟踪缺陷时出现“测试”错误？
对我来说，测试时间是实际测试运行的时间，而不是其他任何东西。在这种情况下，我将错误和执行时间都添加为“编译”时间，即生成和运行代码所用的时间。
- 如果测试用例遇到语法错误，则认为是代码 缺陷，编译缺陷或测试 缺陷？测试实际上找到了 错误，但这是一个代码问题。
语法错误是代码缺陷。
- 如果IDE识别出之前会阻止编译的错误 实际编译，应该是 确定了吗？如果是的话，应该是 识别并跟踪为编译 错误或代码错误？
如果IDE是工具链的一部分，那么它看到错误就像你自己发现了错误，从而编码错误。如果您不定期使用IDE，那么我会将它们视为编译错误。
答案 1 :(得分：1)
我多年来一直使用PSP。正如其他人所说，这是一个个人过程，您需要发展PSP0以改进您的开发过程。尽管如此，我们的团队（所有接受过PSP培训的团队）都在几个方面努力解决这些问题。让我告诉你所涉及的组件，然后我会说我们是如何管理的。
我们有一个PowerBuilder“层”; PowerBuilder IDE阻止您甚至保存代码，直到它正确编译和链接。虽然Java的数量很小，但是系统的一部分使用了JSP，但是在实践中，我们根本没有计算它。该系统的很大一部分是JS / JavaScript;这是在精彩的Ajax库出现之前完成的，并代表了大部分工作。另一大部分是Oracle Pl / Sql;这有一个更传统的编译阶段。
在PowerBuilder中工作时，编译（和链接）阶段在开发人员保存对象时启动。如果保存成功，我们记录的编译时间为0.否则，我们记录了修复导致编译时缺陷的错误所花费的时间。大多数情况下，这些是在编码中注入的缺陷，在编译阶段被删除。
PowerBuilder IDE的强制编译/链接方面迫使我们将代码审查阶段转移到编译后。最初，这给我们带来了一些困扰，因为我们不确定这样的改变将如何影响数据的含义。在实践中，它变得没有问题。实际上，我们中的许多人也在编译阶段之后也将我们的Oracle Pl / Sql代码评论移动到了，因为我们发现在查看代码时，我们经常会掩盖编译器会报告的一些语法错误。
编译时间为0时没有任何问题，只是测试时间为0时有任何问题（意味着你的单元测试通过而没有检测到错误，并且运行速度明显快于你的测量单位）。如果这些时间为零，那么您不会删除这些阶段中的任何缺陷，并且您不会遇到div / 0问题。您还可以记录1分钟的标称最小值，如果这样可以让您更舒服，或者您的度量需要非零值。
您的第二个问题与开发环境无关。当您遇到缺陷时，您会记录您注入的阶段（通常是设计或代码）以及您删除它的阶段（通常是设计/代码审查，编译或测试）。这为您提供了称为“杠杆”的度量，它表示在特定阶段删除缺陷的相对有效性（并支持“常识”，即更快地删除缺陷比在此过程中删除缺陷更有效）。注入缺陷的相是其类型，即设计或编码缺陷。删除缺陷的阶段不会影响其类型。
同样，使用JS / JavaScript，编译时间实际上是无法估量的。我们没有记录编译阶段的任何时间，但是再一次，我们没有删除该阶段的任何缺陷。大部分JS / JavaScript缺陷都是在设计/编码中注入的，并在设计评审，代码审查或测试中被删除。
答案 2 :(得分：0)
听起来，基本上，就像你的正式程序与你的练习过程不符。退一步，重新评估你在做什么，以及你是否应该选择不同的正式方法（如果实际上你需要一个正式的方法开始）。
答案 3 :(得分：0)
- 在解释型语言中，没有编译时间。但是，有可能 是执行中的问题。正在执行 脚本，在单位之外（和 其他）测试，被认为是“编译”或 “测试”时间？应该有错误 执行被认为是“编译”或 跟踪缺陷时出现“测试”错误？
错误应根据创建时间进行分类，而不是在找到错误时进行分类。
- 如果测试用例遇到语法错误，则认为是代码 缺陷，编译缺陷或测试 缺陷？测试实际上找到了 错误，但这是一个代码问题。
与上述相同。总是回到最早的时间点。如果在编码时引入了语法错误，那么它对应于编码阶段，如果在修复错误时引入，那么它就处于缺陷阶段。
- 如果IDE识别出之前会阻止编译的错误 实际编译，应该是 确定了吗？如果是的话，应该是 识别并跟踪为编译 错误或代码错误？
我认为不应该被识别出来。这只是编写代码所花费的时间。
作为旁注，我使用了Process Dashboard工具来跟踪PSP数据并发现它非常好。它是免费的，基于Java的，所以它应该在任何地方运行。你可以在这里得到它： http://processdash.sourceforge.net/
答案 4 :(得分：0)
在阅读Mike Burton，Vinko Vrsalovic和JRL的回复后，重新阅读PSP中的相应章节：软件工程师的自我改进流程，我已经上来了我自己承担了这些问题。然而，有趣的是，我在书中找到了一个部分，当我将两页粘在一起时，我最初错过了这一部分。
- 在解释型语言中，有 没有编译时间。但是，有可能 是执行中的问题。正在执行 脚本，在单位之外（和 其他）测试，被认为是“编译”或 “测试”时间？应该有错误 执行被认为是“编译”或 跟踪缺陷时出现“测试”错误？
根据这本书，它说“如果你使用的是不能编译的开发环境，那么你应该只是跳过编译步骤。”但是，它还说如果你有一个构建步骤，“你可以在编译阶段记录构建时间和任何构建错误。”
这意味着对于解释型语言，您将从跟踪中删除编译阶段，或者使用构建脚本替换编译。因为PSP0通常用于小型应用程序（类似于您在大学实验室中所期望的那样），我希望您不会有构建过程而只是省略该步骤。
- 如果测试用例遇到语法 错误，是一个代码 缺陷，编译缺陷或测试 缺陷？测试实际上找到了 错误，但这是一个代码问题。
我会在他们所在的位置记录错误。
例如，如果测试用例有缺陷，那将是测试缺陷。如果测试运行，并且在测试的应用程序中发现错误，那将是代码或设计缺陷，具体取决于问题的实际来源。
- 如果IDE识别出错误 会阻止编译 实际编译，应该是 确定了吗？如果是的话，应该是 识别并跟踪为编译 错误或代码错误？
如果IDE识别出语法错误，则与执行前实际发现错误的情况相同。正确使用IDE，没有什么借口可以让缺陷影响执行（例如，导致应用程序执行错误而不是逻辑/实现错误）。