房
房客
Unregistered / Unconfirmed
GUEST, unregistred user!
怎样把个体软件过程融入后CASE时代?
____
个体软件过程(Personal Software Process,PSP)是一个过程描述、测度和方法的结构化集合，能够帮助软件工程师改善其个人性能。它提供了表格、脚本和标准，以帮助软件工程师估算和计划其工作。它显示了如何定义过程及如何测量其质量和生产率。
PSP由五级组成，每一级都试图指出过程缺陷并提供解决方法。五级分别为PSP0, PSP1, PSP2, PSP3 and TSP[35]，每个都包括几个单独的步骤。这个专题主张把个体过程并入后CASE系统中，并试图证明它的可用性。
本专题分几个部分来讨论：
目前软件工程师使用的方法 - (PSP0)
编码标准 - (PSP0)
代码尺寸测量 - (PSP0)
记录过程缺陷 - (PSP0)
记录缺陷的解决办法 - (PSP0)
代码尺寸估算 - (PSP1)
时间估算 - (PSP1)
资源估算 - (PSP1)
进度表安排 - (PSP1)
状态跟踪 - (PSP1)
设计完成标准 - (PSP2)
代码回顾 - (PSP2)
瞄准大程序 - (PSP3)
TSP – 组过程
软件工程师目前使用的方法-PSP0
这一过程建立了包括测量和报告格式的基线,对测量进展和详细说明的基础提供了一致的根据。这一步骤记录了软件工程师在工程中使用的具有代表性的软件开发方法和在当前工程中使用的方法。
这一级别简单地接受软件工程师所使用的独特的方法列表。这些方法应该用对测量有意义的方式表现。例如，方法可以存放在关系数据库中，增加额外的字段标示花了软件工程师多少时间来编制标准算法，也可有一字段说明软件工程师使用这些方法的舒适度。
编码标准-(PSP0)
一般来讲软件工程师来自不同的背景和拥有不同的软件开发风格，约束他们的设计方法，采用由组织规定的设计方法学和编码标准已被建议。
这一过程在后CASE系统实现的形式是，对设计过程、开发过程和设计语言结构进行约束。例如，在C语言的IF-then
-else
语句中使用SWITCH语句不被认为是专业编程，这种方式在后CASE时代被丢弃。同样地，后CASE工具也对软件工程师设计的模块强行约束。一般地，统一的编码标准能够通过后CASE系统使用约束实现。
代码尺寸测量-(PSP0)
代码尺寸测量的一个理想化的观点是能够断言说明X（或设计Y,或程序Z）有下列尺寸：长度有l单位，功能有f单位,（程序）复杂度有c单位。视应用程序的情况，我们可能也希望增加再利用数，如长度的r1单位，整个功能的r2单位，及冗余量等等。软件工程师渴望在尺寸的测量上，能够有一个一致的意见。在这个PSP级别上，根据情况和测量标准只能测量尺寸。
这一步骤在后CASE系统中的实现是基于测量基线已经存在，软件工程师可以选择一个基线并修改之。基本上，软件工程师渴望明白在后CASE环境中精确的尺寸测量基线是如何获得的。例如，如果LOC被用在尺寸测量上，那么软件工程师也应该明白其他相关的测量。比如，LOC=NCLOC+CLOC，NCLOC和CLOC分别是非注释行和注释行，程序中注释行的密度为CLOC/LOC。
记录过程缺陷-(PSP0)
软件工程师应该能够记录他们注入软件中的缺陷。代替随便记录他们得到的缺陷，后CASE系统能够提供在系统中观测到的典型缺陷标准列表，软件工程师可以从列表中选择。这有助于软件工程师把典型缺陷标准化。
例如，一个后CASE工具能够提供一列软件工程师所遇到的标准的和C语言的错误/缺陷，并加以分类，顶级语言结构象control structure,pointers,input-output等等。在开发软件产品期间，软件工程师能更新该列表。他们也能记录被观测到的缺陷的次数，以提醒注意那些他们经常加入到系统中的缺陷。
记录缺陷解决办法-(PSP0)
当记下软件中的缺陷时，软件工程师也能记录他们尝试解决错误的办法。软件工程师能记录纠正错误的所有方法步骤。
例如，后CASE系统能够提供对C语言陷阱和缺陷的提示集合。软件工程师无论什么时候遇到一个新的错误都能增加到列表中。他们需要知道怎样对新的缺陷归类并记录。同样地，后CASE系统也提倡使用软件工程方法建立设计项目的预定义的步骤列表。
使用后CASE记录过程解决办法的另一个例子是在OMT中和功能模型一起使用。建造系统的功能模型以列出系统的输入输出值开始，在系统与外部世界之间有参数。为了显示每个输出值怎样由输入值计算得到，一个数据流图(DFD)被构造。在构造了一个精确的DFD模型后，在系统中扮演角色的功能能被标示和描述。这些描述可以是声明式的、程序式的或非正式的。然而，后CASE方法能够记录被软件工程师采用的描述风格，如声明式的、程序式的或非正式的，并且显示一个合适的界面。
代码尺寸估算 - (PSP1)
在写代码之前有经验的软件工程师一般凭经验估计代码的尺寸。这种预测代码的大小的能力是通过长期的编程经验获得的。在 PSP0级,软件工程师学习如何测量代码的尺寸。在 PSP1级,软件工程师试图预测他们所要写的任务模块或算法的可能尺寸。
例如,一个模块的代码尺寸能够根据模块的算法复杂度来测量。在 原始图中,结构图显示了软件系统划分成模块层次的分割图。原图能被修改以至软件工程师能根据 Asymptotic Time Complexity Notation (Big-O notation)明确记载模块的算法复杂度。本质上,软件设计者将看算法必需的实现模块和列出每算法的Gib-O时间复杂度。给出任何二个Big-O时间复杂值,软件工程师能在Metaview中定义如何解释结果复杂度,或者作为最坏情况的复杂度或作为平均情况的复杂度或作为最好情况的复杂度。因此在 Metaview EARA模型中定义的每个模块能有一个时间复杂度Big-O,与它有关的是许多复杂度度量能被计算以决定一个模块或一组模块或整个程序的代码尺寸。
时间估算-(PSP1)
经验丰富的软件工程师能够估计编码所需的时间，因为他们了解编程任务组件的复杂性。他们知道他们使用某种语言的某种数据结构编写一个特定逻辑的能力。他们知道在他们的编程任务中需要用到那些子模块，任务的估算时间有多长。而新手软件开发人员感到预计需要的开发时间是困难的，因为他们缺乏经验，不明白编程任务的复杂度。
后CASE系统应该允许软件工程师明确地拼出一个模块的所有不同部分，对每一部分的开发提供估算时间。这样，后CASE系统能被用来监视代码开发的进度，根据时间计划表对开发的程序评定。后CASE系统也提醒新手软件工程师把注意力放在按时完成项目/模块上。这节提供了一个后CASE在项目计划方面项目时间评估方法的使用。
在原始图中，一旦设计样子已形成，软件工程师能给出在结构图中模块的估算时间。原始图应该对模块的不同抽象层提供缚上估算时间的工具。例如，软件工程师能在第一抽象层缚上时间估算，第一抽象层也能被分割成几个下面的抽象层。另一方面，软件工程师也能从最后抽象层开始提供时间估算，并且传播估算值直到第一抽象层。
软件工程师被期望依赖于他们的能力和生产力提供模块的估算时间。一个模块的估算时间涉及软件工程师认为完成模块可能需花费编码时间。例如，在结构图中一个模块的时间估算是5-10-20，5代表乐观时间，10代表可能时间，20代表悲观时间。时间单位可以是小时、天、人月或人年。
乐观时间指在每一件事都进展得很好且不复杂的情况下，完成一个特定模块需要的时间。按照规律比乐观时间还少的编码时间仅占十分之一。
可能时间指在正常情况下完成一个特定模块所需时间。如果一个特定模块被不同的软件工程师完成了许多次，那么出现频率最多的编码时间即是可能时间。
悲观时间指在不利条件下完成一个特定模块所需时间。例如不寻常的和无法预料的复杂性如机器崩溃。按照规律比悲观时间还多的编码时间仅占十分之一。
使用这三种时间估算，原始图应该能使用B概率分布计算平均估算时间。
进度表计划-(PSP1)
许多项目的计划和安排技术是由网络安排方法例如PERT，CPM等等变化而来。软件工程师应该理解网络安排技术的计划策略。一个后CASE系统可以提供由软件工程师使用的自动的网络安排技术。例如，基于事件和模块的网络安排技术在后CASE系统中能被单独作成模型。软件工程师能用一个计划表表达项目，并使用后CASE系统传递给另一个。
资源估算-(PSP1)
对于软件开发的一段生存期，软件工程师也需要预测所需的资源。资源包括软件资源、硬件资源和人件资源。人件资源包括人力需求，人力成本估算和项目管理标准。
例如,在 原结构图中,软件工程师应该能预测模块集的资源要求,或实现整个系统功能的资源需求。
状态跟踪-(PSP1)
状态跟踪是根据进度表对软件工程师的工作跟踪。在后CASE系统中大多估算的时间会通过软件工程师的适当输入实现。但是有一些信息必需从项目管理者处得到，例如，关于项目开发的有效性，同步及各个阶段的文档。
例如，期望的项目完成时间基于后CASE系统计算的几个软件工程师的进度。
设计完成标准-(PSP2)
设计完成涉及检查设计和它的一致性。检查设计中期望的功能不能完全自动操作。但是检验设计的后CASE方法能提供深入的指数。例如，一个后CASE方法能提供代码重用的百分率、代码的冗余、代码完整性及协作性。这些设计问题对评估设计质量是必需的，并且它们能通过使用一个后CASE系统自动完成。
同样的，检查设计的一致性涉及一致的结构化（例如，控制和数据流）、耦合的一致性、轻便和互用的一致性。许多一致性问题不能自动操作。但是估算在后CASE中能够使用一致性测量得到。
编码回顾-(PSP2)
这是软件工程师的一个重要任务。有一个研究报告显示了在PSP的帮助下，组合的设计和代码回顾使每KLOC的平均缺陷数由150减少到100，生产力增加了30%。
使代码回顾过程完全自动实现是不可能的。相反，后CASE系统能提供一些方法，使用它们模块、程序和项目的代码回顾能被部分执行。例如，一个后CASE系统能够混合一组标准来从事代码回顾和提供给软件工程师评论代码。Werth提出了一组包括在代码评论章节中的软件过程评估调查表。调查表从事代码回顾标准，代码评论应用，代码评论覆盖，代码评论数据搜集，代码评论表示法，代码评论分析和代码评论效率。
PSP2不仅从事设计过程，而且提供其他软件工程过程，如需求说明、文档开发、和测试开发。它使组织达到在它们的PSP2过程中决定的深度级别。PSP2级一个有趣的方面是阶段入口和阶段出口标准的鉴定。没有它们，做有效的阶段评论或清楚地定义开发状态是困难的。
在后CASE系统中代码和设计的评论自动实现，对其它软件工程标准如文档、需求说明，依赖于后CASE系统提供标准的能力。在大多情况下，使评论过程完全自动实现是不可能的。相反，后CASE系统能提供数据，利用数据，软件工程师能推断需求信息。
瞄准大程序-(PSP3)
PSP2主要针对建造小程序的线性过程。但是，当他们开发大型的程序时PSP3过程引进了个体使用的方法。在把PSP2应用到大项目时，这个方法已经把开发大型程序的个体过程细分为可应用PSP2的片段。这些更大的程序已经被设计来循环增加地开发。在任何时间点，只有一个PSP2级过程是活动的。因此后CASE大多数PSP2级的详细资料能够在此级被使用。
TSP-(组过程)
TSP包括组过程，训练，协作等等。这些过程在PSP的结构中没有被定义。因此它们不能自动实现。但是一般来说，协作学习和协作训练调查方法能作为TSP过程的一部分被观看。
因此，PSP的演变过程能根据它们在后CASE系统中的实现被讨论。
____
个体软件过程(Personal Software Process,PSP)是一个过程描述、测度和方法的结构化集合，能够帮助软件工程师改善其个人性能。它提供了表格、脚本和标准，以帮助软件工程师估算和计划其工作。它显示了如何定义过程及如何测量其质量和生产率。
PSP由五级组成，每一级都试图指出过程缺陷并提供解决方法。五级分别为PSP0, PSP1, PSP2, PSP3 and TSP[35]，每个都包括几个单独的步骤。这个专题主张把个体过程并入后CASE系统中，并试图证明它的可用性。
本专题分几个部分来讨论：
目前软件工程师使用的方法 - (PSP0)
编码标准 - (PSP0)
代码尺寸测量 - (PSP0)
记录过程缺陷 - (PSP0)
记录缺陷的解决办法 - (PSP0)
代码尺寸估算 - (PSP1)
时间估算 - (PSP1)
资源估算 - (PSP1)
进度表安排 - (PSP1)
状态跟踪 - (PSP1)
设计完成标准 - (PSP2)
代码回顾 - (PSP2)
瞄准大程序 - (PSP3)
TSP – 组过程
软件工程师目前使用的方法-PSP0
这一过程建立了包括测量和报告格式的基线,对测量进展和详细说明的基础提供了一致的根据。这一步骤记录了软件工程师在工程中使用的具有代表性的软件开发方法和在当前工程中使用的方法。
这一级别简单地接受软件工程师所使用的独特的方法列表。这些方法应该用对测量有意义的方式表现。例如，方法可以存放在关系数据库中，增加额外的字段标示花了软件工程师多少时间来编制标准算法，也可有一字段说明软件工程师使用这些方法的舒适度。
编码标准-(PSP0)
一般来讲软件工程师来自不同的背景和拥有不同的软件开发风格，约束他们的设计方法，采用由组织规定的设计方法学和编码标准已被建议。
这一过程在后CASE系统实现的形式是，对设计过程、开发过程和设计语言结构进行约束。例如，在C语言的IF-then
-else
语句中使用SWITCH语句不被认为是专业编程，这种方式在后CASE时代被丢弃。同样地，后CASE工具也对软件工程师设计的模块强行约束。一般地，统一的编码标准能够通过后CASE系统使用约束实现。
代码尺寸测量-(PSP0)
代码尺寸测量的一个理想化的观点是能够断言说明X（或设计Y,或程序Z）有下列尺寸：长度有l单位，功能有f单位,（程序）复杂度有c单位。视应用程序的情况，我们可能也希望增加再利用数，如长度的r1单位，整个功能的r2单位，及冗余量等等。软件工程师渴望在尺寸的测量上，能够有一个一致的意见。在这个PSP级别上，根据情况和测量标准只能测量尺寸。
这一步骤在后CASE系统中的实现是基于测量基线已经存在，软件工程师可以选择一个基线并修改之。基本上，软件工程师渴望明白在后CASE环境中精确的尺寸测量基线是如何获得的。例如，如果LOC被用在尺寸测量上，那么软件工程师也应该明白其他相关的测量。比如，LOC=NCLOC+CLOC，NCLOC和CLOC分别是非注释行和注释行，程序中注释行的密度为CLOC/LOC。
记录过程缺陷-(PSP0)
软件工程师应该能够记录他们注入软件中的缺陷。代替随便记录他们得到的缺陷，后CASE系统能够提供在系统中观测到的典型缺陷标准列表，软件工程师可以从列表中选择。这有助于软件工程师把典型缺陷标准化。
例如，一个后CASE工具能够提供一列软件工程师所遇到的标准的和C语言的错误/缺陷，并加以分类，顶级语言结构象control structure,pointers,input-output等等。在开发软件产品期间，软件工程师能更新该列表。他们也能记录被观测到的缺陷的次数，以提醒注意那些他们经常加入到系统中的缺陷。
记录缺陷解决办法-(PSP0)
当记下软件中的缺陷时，软件工程师也能记录他们尝试解决错误的办法。软件工程师能记录纠正错误的所有方法步骤。
例如，后CASE系统能够提供对C语言陷阱和缺陷的提示集合。软件工程师无论什么时候遇到一个新的错误都能增加到列表中。他们需要知道怎样对新的缺陷归类并记录。同样地，后CASE系统也提倡使用软件工程方法建立设计项目的预定义的步骤列表。
使用后CASE记录过程解决办法的另一个例子是在OMT中和功能模型一起使用。建造系统的功能模型以列出系统的输入输出值开始，在系统与外部世界之间有参数。为了显示每个输出值怎样由输入值计算得到，一个数据流图(DFD)被构造。在构造了一个精确的DFD模型后，在系统中扮演角色的功能能被标示和描述。这些描述可以是声明式的、程序式的或非正式的。然而，后CASE方法能够记录被软件工程师采用的描述风格，如声明式的、程序式的或非正式的，并且显示一个合适的界面。
代码尺寸估算 - (PSP1)
在写代码之前有经验的软件工程师一般凭经验估计代码的尺寸。这种预测代码的大小的能力是通过长期的编程经验获得的。在 PSP0级,软件工程师学习如何测量代码的尺寸。在 PSP1级,软件工程师试图预测他们所要写的任务模块或算法的可能尺寸。
例如,一个模块的代码尺寸能够根据模块的算法复杂度来测量。在 原始图中,结构图显示了软件系统划分成模块层次的分割图。原图能被修改以至软件工程师能根据 Asymptotic Time Complexity Notation (Big-O notation)明确记载模块的算法复杂度。本质上,软件设计者将看算法必需的实现模块和列出每算法的Gib-O时间复杂度。给出任何二个Big-O时间复杂值,软件工程师能在Metaview中定义如何解释结果复杂度,或者作为最坏情况的复杂度或作为平均情况的复杂度或作为最好情况的复杂度。因此在 Metaview EARA模型中定义的每个模块能有一个时间复杂度Big-O,与它有关的是许多复杂度度量能被计算以决定一个模块或一组模块或整个程序的代码尺寸。
时间估算-(PSP1)
经验丰富的软件工程师能够估计编码所需的时间，因为他们了解编程任务组件的复杂性。他们知道他们使用某种语言的某种数据结构编写一个特定逻辑的能力。他们知道在他们的编程任务中需要用到那些子模块，任务的估算时间有多长。而新手软件开发人员感到预计需要的开发时间是困难的，因为他们缺乏经验，不明白编程任务的复杂度。
后CASE系统应该允许软件工程师明确地拼出一个模块的所有不同部分，对每一部分的开发提供估算时间。这样，后CASE系统能被用来监视代码开发的进度，根据时间计划表对开发的程序评定。后CASE系统也提醒新手软件工程师把注意力放在按时完成项目/模块上。这节提供了一个后CASE在项目计划方面项目时间评估方法的使用。
在原始图中，一旦设计样子已形成，软件工程师能给出在结构图中模块的估算时间。原始图应该对模块的不同抽象层提供缚上估算时间的工具。例如，软件工程师能在第一抽象层缚上时间估算，第一抽象层也能被分割成几个下面的抽象层。另一方面，软件工程师也能从最后抽象层开始提供时间估算，并且传播估算值直到第一抽象层。
软件工程师被期望依赖于他们的能力和生产力提供模块的估算时间。一个模块的估算时间涉及软件工程师认为完成模块可能需花费编码时间。例如，在结构图中一个模块的时间估算是5-10-20，5代表乐观时间，10代表可能时间，20代表悲观时间。时间单位可以是小时、天、人月或人年。
乐观时间指在每一件事都进展得很好且不复杂的情况下，完成一个特定模块需要的时间。按照规律比乐观时间还少的编码时间仅占十分之一。
可能时间指在正常情况下完成一个特定模块所需时间。如果一个特定模块被不同的软件工程师完成了许多次，那么出现频率最多的编码时间即是可能时间。
悲观时间指在不利条件下完成一个特定模块所需时间。例如不寻常的和无法预料的复杂性如机器崩溃。按照规律比悲观时间还多的编码时间仅占十分之一。
使用这三种时间估算，原始图应该能使用B概率分布计算平均估算时间。
进度表计划-(PSP1)
许多项目的计划和安排技术是由网络安排方法例如PERT，CPM等等变化而来。软件工程师应该理解网络安排技术的计划策略。一个后CASE系统可以提供由软件工程师使用的自动的网络安排技术。例如，基于事件和模块的网络安排技术在后CASE系统中能被单独作成模型。软件工程师能用一个计划表表达项目，并使用后CASE系统传递给另一个。
资源估算-(PSP1)
对于软件开发的一段生存期，软件工程师也需要预测所需的资源。资源包括软件资源、硬件资源和人件资源。人件资源包括人力需求，人力成本估算和项目管理标准。
例如,在 原结构图中,软件工程师应该能预测模块集的资源要求,或实现整个系统功能的资源需求。
状态跟踪-(PSP1)
状态跟踪是根据进度表对软件工程师的工作跟踪。在后CASE系统中大多估算的时间会通过软件工程师的适当输入实现。但是有一些信息必需从项目管理者处得到，例如，关于项目开发的有效性，同步及各个阶段的文档。
例如，期望的项目完成时间基于后CASE系统计算的几个软件工程师的进度。
设计完成标准-(PSP2)
设计完成涉及检查设计和它的一致性。检查设计中期望的功能不能完全自动操作。但是检验设计的后CASE方法能提供深入的指数。例如，一个后CASE方法能提供代码重用的百分率、代码的冗余、代码完整性及协作性。这些设计问题对评估设计质量是必需的，并且它们能通过使用一个后CASE系统自动完成。
同样的，检查设计的一致性涉及一致的结构化（例如，控制和数据流）、耦合的一致性、轻便和互用的一致性。许多一致性问题不能自动操作。但是估算在后CASE中能够使用一致性测量得到。
编码回顾-(PSP2)
这是软件工程师的一个重要任务。有一个研究报告显示了在PSP的帮助下，组合的设计和代码回顾使每KLOC的平均缺陷数由150减少到100，生产力增加了30%。
使代码回顾过程完全自动实现是不可能的。相反，后CASE系统能提供一些方法，使用它们模块、程序和项目的代码回顾能被部分执行。例如，一个后CASE系统能够混合一组标准来从事代码回顾和提供给软件工程师评论代码。Werth提出了一组包括在代码评论章节中的软件过程评估调查表。调查表从事代码回顾标准，代码评论应用，代码评论覆盖，代码评论数据搜集，代码评论表示法，代码评论分析和代码评论效率。
PSP2不仅从事设计过程，而且提供其他软件工程过程，如需求说明、文档开发、和测试开发。它使组织达到在它们的PSP2过程中决定的深度级别。PSP2级一个有趣的方面是阶段入口和阶段出口标准的鉴定。没有它们，做有效的阶段评论或清楚地定义开发状态是困难的。
在后CASE系统中代码和设计的评论自动实现，对其它软件工程标准如文档、需求说明，依赖于后CASE系统提供标准的能力。在大多情况下，使评论过程完全自动实现是不可能的。相反，后CASE系统能提供数据，利用数据，软件工程师能推断需求信息。
瞄准大程序-(PSP3)
PSP2主要针对建造小程序的线性过程。但是，当他们开发大型的程序时PSP3过程引进了个体使用的方法。在把PSP2应用到大项目时，这个方法已经把开发大型程序的个体过程细分为可应用PSP2的片段。这些更大的程序已经被设计来循环增加地开发。在任何时间点，只有一个PSP2级过程是活动的。因此后CASE大多数PSP2级的详细资料能够在此级被使用。
TSP-(组过程)
TSP包括组过程，训练，协作等等。这些过程在PSP的结构中没有被定义。因此它们不能自动实现。但是一般来说，协作学习和协作训练调查方法能作为TSP过程的一部分被观看。
因此，PSP的演变过程能根据它们在后CASE系统中的实现被讨论。
