2.3 过程建模工具和技术
软件工程（第4版•修订版）
一旦你决定了要从过程模型中得到什么，会有很多建模工具和技术可供选择。从前面章节模型的描述中，我们已经了解了一些建模的方法。选择的建模技术是否合适，取决于你的目标和喜欢的工作方式。尤其是，对表示法的选择取决于你想要用模型表示的内容。表示法可以是从文本到图形的各种方式。文本方式把过程表示为函数，图形方式把过程描述成由正方形和箭头组成的层次结构，图形和文本结合的方式把图形化的描述与表格和函数结合在一起，共同对过程从较高层次进行说明。许多建模表示法也可用于表示需求和设计，我们将在后面的章节中对其中一些进行讨论。
在本章中，表示方法是从属于模型类型的。我们集中精力讨论两种主要的模型：静态模型和动态模型。静态模型（static model）描述过程，表明了从输入到输出的转换过程。动态模型（dynamic model）能够动态展现过程，这样用户能够看到中间产品和最终产品是如何随着时间的推移进行转换的。
2.3.1 静态建模：Lai表示法
静态建模的方式有许多种。在20世纪90年代早期，Lai设计了一种全面的过程表示法，目的是让人们能够在任何细节的层次上对任何过程都可以建模（Lai 1991）。它是在一种范型的基础上建立的，在这种范型中：人扮演角色，资源执行活动，从而产生制品。这个过程模型表明了角色、活动和制品之间的相互关系。而状态表说明在给定的时间内，每个制品完成情况的信息。
过程包含以下7种类型的要素。
(1) 活动：过程中将要发生的事情。该要素可以与下面几项相关联：该活动前后发生的事情、所需的资源、使活动开始的触发器、支配活动的规则、如何描述算法以及得到的经验教训，以及如何将该活动与项目团队联系起来。
(2) 序列：活动的顺序。序列可用触发器进行描述，也可以用程序结构、转换、排序或满足的条件来描述。
(3) 过程模型：是关于系统兴趣的观点。因此，部分过程可以用单独的模型表示，或者用以预测过程行为，或者用以检查某些特性。
(4) 资源：必要的项、工具或人员。资源可以包括设备、时间、办公空间、人员、技术，等等。过程模型确定每个活动对于每一个资源所需的数量。
(5) 控制：施加于过程执行的外部影响。控制可以是手工的或自动的、人工的或机械的。
(6) 策略：指导原则。它是影响过程执行的高层的过程约束，可能包含一个规定的开发过程、必须使用的工具或强制性的管理模式。
(7) 组织：过程代理的层次化结构，使物理的分组与逻辑分组及相关角色相对应。从物理分组到逻辑分组的映射必须足够灵活以便反映物理环境的变化。
过程描述本身具有若干层次的抽象，包括软件开发过程（它指导特定资源用于构造特定的模块）以及类似于螺旋模型或瀑布模型的一般模型。Lai表示法包括若干模板，例如，记录特定制品信息的制品定义模板。
Lai方法可以用于软件开发过程建模。在本章后面的论述中，我们将利用它为开发过程所涉及的风险建模。为了演示如何使用它以及它表示复杂活动多方面信息的能力，我们把它应用到相对简单、但又十分熟悉的过程中：驾驶汽车。表2-1是对这个过程中的关键资源——汽车（car）——的描述。
其他的模板定义了关系、过程状态、操作、分析、动作和角色。绘制的图表示要素之间的相互关系，保存主要关系和次要关系。例如，图2-11说明启动汽车的过程。“initiate”框表示进入条件，“park”框表示退出条件。条件框中的左列列出了制品，右列列出了相应制品的状态。
转换图是对过程模型的补充，它说明状态之间是如何联系的。例如，图2-12显示了汽车的状态转换。
关于如何用多个结构和策略来获取大量关于软件开发过程的信息，Lai表示法是一种很好的例子。而且，如汽车这个例子演示的那样，Lai表示法也可用于组织和描述有关用户需求的过程信息。
2.3.2 动态建模：系统动力学
过程模型的一个良好特性就是演示过程的能力，这样，随着活动的发生，我们就可以观察资源和产品发生了什么情况。换言之，我们想要描述这个过程的模型，并且在软件向我们展示资源流是如何通过活动成为输出的时候可以进行观察。这种动态过程的视图使我们能够模拟过程，并在实际消耗资源之前能够进行修改。例如，可以使用动态过程模型帮助我们确定需要多少名测试人员及必须何时启动测试才能够按进度完成。同样，可以增加或去除活动，看一看它们对工作量和进度的影响。例如，可以增加一个代码评审活动，对评审过程中发现的故障数量做出假设，以便确定评审是否明显地减少了测试时间。
建立动态过程模型的方法有很多种。Forrester于20世纪50年代提出了系统动力学方法。该方法在模拟不同的过程（包括生态、经济和政治系统）中一直很有用（Forrester 1991）。Abdel-Hamid和Madnick曾把系统动力学方法应用到软件开发中，使项目经理在开发人员中强行推行过程之前，能够对他们的过程选择进行“考验”（Abdel-Hamid 1989；Abdel-Hamid and Madnick 1991）。
要了解系统动力学方法是如何运作的，可以考虑一下软件开发过程是如何影响生产率的。我们可以构建包括开发人员时间在内的各种活动的描述性模型，然后考虑模型中的变化是怎样增加或减少设计、编写和测试代码所用的时间的。首先，必须确定哪些因素对总生产率有影响。图2-13描述了Abdel-Hamid对这些因素的理解。箭头表明一个因素中的变化是如何影响另一个因素中的变化的。例如，如果在分配给项目的人员中，有经验的职员所占比例从1/4增加到1/2，那么，我们预期平均生产率也会有所提高。同样，职员所占的比例越大（反映在职员规模上），那么用于项目团队成员之间交流的时间就越多（交流开销）。
从图2-13可以得知，名义平均潜在生产率受下面3种因素影响：有经验职员的生产率、有经验职员的比例以及新职员的生产率。同时，新职员必须了解这个项目。项目完成的部分越多，则新职员在他们能够成为团队中高产的成员之前，就必须了解得越多。
其他问题也会对总体的开发生产率产生影响。首先，必须考虑每个开发人员每天对项目贡献所占的比例，进度带来的压力会影响这个比例，开发人员对工作量的承受力会影响这个比例。职员规模也会影响生产率，但是职员越多，则项目团队成员用于交流信息的时间就越多。交流、动机以及潜在生产率（表示为图2-13的上半部分），三者合在一起给出了一种概括的软件开发生产率关系。
因此，使用系统动力学方法的第一步是将实证性证据、研究报告和直觉这三者结合在一起来标识这些关系。下一步是量化这些关系，量化可以包含直接的关系。例如，职员规模和交流之间的关系。我们知道，如果给一个项目分配n个人，那么可能有n(n1)/2对人员必须彼此交流和协调。对某些关系，尤其是那些涉及随时间变化的资源的关系，必须进行一些分配来描述资源的增加和减少。例如，在一个项目中，很少会出现每个人都在第一天开始工作的情况。系统分析员首先开始工作，当大量需求和设计构件文档化之后，编程人员才加入到项目中。因此，这种分配就描述了资源的增加和减少（甚至是波动，例如节日或暑假的出勤率）。
一个系统动力学模型可能包含大量信息并且非常复杂。例如，Abdel-Hamid的软件开发模型包含100多个因果链接，图2-14给出了他所定义的关系的总体描述。他定义了影响生产率的4个主要方面：软件生产、人力资源管理、计划以及控制。生产包括质量保证、学习和开发速率等相关问题。人力资源强调雇用、人事变动和经验。计划关心进度安排和由此带来的压力，而控制则强调过程测度和完成项目所需的工作量。
由于系统动力学模型中链接的数目可能相当大，所以存在一些支持软件可以获取链接和它们的量化描述，从而可以模拟整个过程或某些子过程。
系统动力学模型的强大功能给人们留下了深刻的印象，但是必须谨慎地使用这个方法。模拟的结果依赖于量化的关系，但量化的关系常常是启发式的或含糊不清的，它不是明确基于实证性研究的。然而，正如我们在后面的章节中将要看到的那样，使用一个包含开发各方面的测度信息的历史数据库，有助于我们对关系的理解，从而对动态模型的结果更有信心。
补充材料2-4 过程程序设计
在20世纪80年代中期，Osterweil提出应该使用数学描述的方法对软件开发过程进行说明（Osterweil 1987）。也就是说，如果过程被充分理解，我们就能够编写程序来描述这个过程，然后运行这个程序演示这个过程。过程程序设计的目标就是去除不确定性：通过充分理解一个过程来编写软件以抓住它的本质，并将这个过程转化成问题的确定的解决方案。
如果过程程序设计是可能的，那么我们就能够可见地管理所有过程活动、让所有活动自动化，并能轻而易举地协调及改变所有活动。因此，过程程序有可能成为生产软件的自动化环境的基础。
然而，Curtis、Krasner、Shen和Iscoe指出，Osterweil对计算机程序设计的类比没有抓住开发过程内在的变化（Curtis, Krasner, Shen and Iscoe 1987）。当编写完一个计算机程序之后，程序员假定实现环境工作正常，操作系统、数据库管理器和硬件都是可靠的、正确的。因此，计算机对运算指令的响应几乎不存在变化。但是，当一个过程程序对项目团队中的一个成员发布一条指令时，任务执行的方式和产生的结果都存在着很大的可变性。正如我们将在第3章中看到的那样，技能、经验、工作习惯、对客户需求的理解的差异和许多其他因素都可能极大地增加可变性。Curtis和他的同事建议，过程程序设计应当仅限于那些存在极小变化的情况。而且他们还指出，Osterweil的例子仅仅提供了关于任务序列化的信息；过程程序并没有就那些迫在眉睫的问题向管理人员发出警告。“创造性的智力任务的协调似乎并没有通过当前过程程序设计的实现而显著改善，因为进行协调的最重要的原因是确保所有交互的代理具有同样的关于系统如何运作的概念模型”（Curtis et al. 1987）。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。