International Software Process Workshop最新文献_第5页

S-RaP: A Concurrent, Evolutionary Software Prototyping Process S-RaP:一个并发的、进化的软件原型过程

International Software Process Workshop

Pub Date : 2005-05-25 DOI: 10.1007/11608035_16

Xiping Song, Arnold Rudorfer, B. Hwong, Gilberto Matos, Christopher Nelson

引用次数: 3

Process Definition Language Support for Rapid Simulation Prototyping 快速仿真原型的过程定义语言支持

International Software Process Workshop

Pub Date : 2005-05-25 DOI: 10.1007/11608035_34

M. Raunak, L. Osterweil

引用次数: 5

Requirements and Early Experiences in the Implementation of the SPADE Repository 实现SPADE存储库的需求和早期经验

International Software Process Workshop

Pub Date : 1993-11-04 DOI: 10.1007/3-540-57342-9_92

S. Bandinelli, L. Baresi, A. Fuggetta, L. Lavazza

引用次数: 17

Process Evolution in the Marvel Environment Marvel环境中的过程演化

International Software Process Workshop

Pub Date : 1992-11-08 DOI: 10.21236/ada267813

G. Kaiser, I. Ben-Shaul

We present a schema and process evolution tool, called the Evolver, for the M ARVEL process-centered environment. The Evolver analyzes the differences between the new and installed process models of an existing environment, detecting each case where the notion of consistency defined by the process model has been strengthened or weakened. The Evolver then automatically updates the environment's objectbase to guarantee that the objects are consistent according to the new specifications. The Evolver can be applied while the installed process is in progress, temporarily halting normal operation while it updates the objectbase, after which development continues using the new process. We have had several months of experience using the Evolver to make repeated changes in the process that supports our own further development of MARVEL, and include in this paper one small but practical example of a recent change made to a real MARVEL process.

我们为M ARVEL以过程为中心的环境提供了一个模式和过程演化工具，称为Evolver。演进器分析现有环境的新流程模型和已安装流程模型之间的差异，检测流程模型定义的一致性概念得到加强或削弱的每种情况。然后Evolver自动更新环境的对象库，以保证对象与新的规范保持一致。可以在已安装进程正在进行时应用Evolver，在它更新objectbase时暂时停止正常操作，之后继续使用新进程进行开发。我们有几个月的经验，使用Evolver在支持我们自己的MARVEL的进一步开发的过程中进行重复的更改，并在本文中包含一个最近对真正的MARVEL过程进行更改的小但实际的示例。

引用次数: 30

Policies (session summary) 策略(会话摘要)

International Software Process Workshop

Pub Date : 1990-10-01 DOI: 10.5555/317498.317689

P. Feiler

The session on policies was led by Mark Dowson as keynoter. A more detailed description of this session was phrased as “Discussion of experience with domains in actual models — the semantic concerns of process models. What are lessons to be learned about model specific semantics? Model independent semantics?”.In his presentation Mark Dowson focused on the term policies. Policies were described as constraints that facilitate coordinated performance of process steps by multiple agents. Different kinds of policies exist, and there are different forms of policies. Issues regarding the relationship between policies and processes were raised, and ways of applying policies were discussed. Formal and informal as well as automated and manual policies and processes involving humans both at the organizational level and at the level of individuals were considered.The discussion generated by the presentation was lively. Examples of processes and policies in a variety of domains including non-software engineering domains were presented. A spectrum of terms were used for the notion of policy ranging from laws and standards to procedures and methods. In the following the reader will find a capsule summary of the findings. This summary does not reflect the flow of the discussions, nor does it include all the examples mentioned. Instead, the summary attempts to present the essence of the messages communicated by the participants by abstracting out some of the characteristics of policies.Policies can be described as constraints with respect to certain processes. They are statements either in terms of the notation describing the process, or in terms of a notation whose interpretation establishes a mapping to the process. There are different degrees of compliance to these constraints and there are a number of ways this compliance can be achieved. In different domains people have identified constraints with certain characteristics and given them special labels. This was evident in the discussion by the usage of terms such as advice, culture, guideline, goal, law, method, objective, order, policy, practice, preference, procedure, rule, standard, strategy, etc. Some of these terms imply particular degrees of compliance and forms of enforcement, while others imply that the constraints apply to certain types of processes and that the constraints may be in terms of the process, in terms of an abstraction of the process, or in terms the process of managing the execution of a process — the latter two requiring interpretation to establish a mapping between the constraint and the process. In the remainder of this discussion we will use the term policy to mean a constraint.Processes and policies can be characterized according to whether they have an explicit or implicit representation, whether their representation is formal or informal, whether the process and the policies are described in the same of different representations, and whether they are interpreted manually or a

在第四种方式中，过程描述是从过程模板中提炼出来的。检查政策以确保改进不违反规定。在这种情况下，尝试静态地检查策略遵从性。最后一种方法是类似于第一种方法的过程构建过程。不同之处在于，策略是正式表达的，而流程定义的生成是自动执行的。上面的一些方法将策略嵌入到流程中，并通过执行流程的制定来执行策略的遵从性。这种方法允许对流程进行认证以满足某些策略。认证依赖于流程的合规制定。其他方法，特别是那些涉及到由人来解释政策或流程的方法，具有一定程度的遵从性。不同程度的遵从性有效地提供了不同程度的灵活性。灵活性是处理异常的必要条件，特别是在涉及人工的流程中。策略的遵从性总是与它所应用的流程相关。例如，可能存在一个策略，要求始终完成一个测试步骤。本政策可以完全遵守。但是，该策略没有指定任何有关要应用的测试质量的内容。遵守政策只有在对不遵守的行为进行惩罚的情况下才有意义。如果对不遵守没有惩罚，那么就没有满足政策的强制功能，也没有政策的目的。一般来说，可以用两种方式解释策略。策略可以被看作是一种限制，一种控制流程的机制。或者，它们可以被看作是指定自治范围的工具——通过在适当的抽象级别上指定策略并通过分离关注点来允许权力和自由。流程可能受到许多策略的约束。政策之间可能存在冲突。这种冲突必须是可识别的。在非正式政策中，当发现冲突时，通常由解释政策的人来决定如何解决冲突。在许多由流程和策略建模的系统中，将优先级分配给策略，并根据策略的遵从性指定优先级顺序。基本上，不遵守不同政策的惩罚是相互权衡的。有些系统允许更改策略和流程。在这种情况下，可以调整流程和策略，以避免策略之间或策略与流程之间的冲突。例如，在商业组织中存在一个政策层次结构。最高层是公司政策。在司一级有被称为惯例的政策。最后，这些被细化为称为过程的操作策略。对公司策略的更改可能会导致与其他公司策略的冲突，可以在其生效之前解决。新的公司政策也影响到实践。可能的冲突可以通过使实践适应新政策，以及针对无法解决的冲突提出调整公司政策的建议来解决。将策略应用于流程本身就是流程。如上所述，这个过程可以采取多种形式。但是请注意，作为一个过程，它可以由策略进行管理。结果是我们有了政策(应用)政策。更确切地说，这些策略分为关于创建策略的策略、关于策略演变的策略，即策略的变化，以及关于应用和验证策略遵从性的策略。这就产生了一种将组织视为生长有机体的模型。立法是组织发展的基础。这被认为是一个深刻的问题。在一个组织中，有生产产品的过程。这些过程是受管理的。管理本身就是一系列过程的集合。有些过程与监控和改进生产过程有关。其他过程与组织各部分之间的资源分配有关。管理程序受到其他管理程序的审查。这些过程被授权执行特定的过程，以及负责监视和改进管理过程的过程。实际上，一个组织可以被看作是一个过程和政策系统的引导和动态演变。在讨论期间，收集了许多策略和策略承诺的属性。策略的属性包括起源、范围、绑定、变更、责任、解释、制定、一致性分析、有效性。承诺的属性包括对谁的承诺、由谁承诺、由谁知道的承诺、承诺的条件、遵守承诺的监督和报告、承诺的可信度。综上所述，还有其他一些问题

{"title":"Policies (session summary)","authors":"P. Feiler","doi":"10.5555/317498.317689","DOIUrl":"https://doi.org/10.5555/317498.317689","url":null,"abstract":"The session on policies was led by Mark Dowson as keynoter. A more detailed description of this session was phrased as “Discussion of experience with domains in actual models — the semantic concerns of process models. What are lessons to be learned about model specific semantics? Model independent semantics?”.\u0000In his presentation Mark Dowson focused on the term policies. Policies were described as constraints that facilitate coordinated performance of process steps by multiple agents. Different kinds of policies exist, and there are different forms of policies. Issues regarding the relationship between policies and processes were raised, and ways of applying policies were discussed. Formal and informal as well as automated and manual policies and processes involving humans both at the organizational level and at the level of individuals were considered.\u0000The discussion generated by the presentation was lively. Examples of processes and policies in a variety of domains including non-software engineering domains were presented. A spectrum of terms were used for the notion of policy ranging from laws and standards to procedures and methods. In the following the reader will find a capsule summary of the findings. This summary does not reflect the flow of the discussions, nor does it include all the examples mentioned. Instead, the summary attempts to present the essence of the messages communicated by the participants by abstracting out some of the characteristics of policies.\u0000Policies can be described as constraints with respect to certain processes. They are statements either in terms of the notation describing the process, or in terms of a notation whose interpretation establishes a mapping to the process. There are different degrees of compliance to these constraints and there are a number of ways this compliance can be achieved. In different domains people have identified constraints with certain characteristics and given them special labels. This was evident in the discussion by the usage of terms such as advice, culture, guideline, goal, law, method, objective, order, policy, practice, preference, procedure, rule, standard, strategy, etc. Some of these terms imply particular degrees of compliance and forms of enforcement, while others imply that the constraints apply to certain types of processes and that the constraints may be in terms of the process, in terms of an abstraction of the process, or in terms the process of managing the execution of a process — the latter two requiring interpretation to establish a mapping between the constraint and the process. In the remainder of this discussion we will use the term policy to mean a constraint.\u0000Processes and policies can be characterized according to whether they have an explicit or implicit representation, whether their representation is formal or informal, whether the process and the policies are described in the same of different representations, and whether they are interpreted manually or a","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"136 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115592083","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

引用次数: 0

Emerging issues (session summary) 新出现的问题(会议摘要)

International Software Process Workshop

Pub Date : 1990-10-01 DOI: 10.5555/317498.317692

D. Garlan

It would be a mistake to infer from the title of this session that discussions of emerging issues were postponed until this final session of the workshop. On the contrary, all of the preceding sessions devoted a large proportion of the discussion to identifying issues that are poorly understood and much in need of further research. In leading this session, Sam Redwine did a remarkable job of condensing this multi-leveled, wide ranging spectrum of issues into a coherent outline. His presentation consisted of two major parts: first he delivered (without interruptions) a summary of the issues discussed in previous sessions; next he highlighted topics for future work and outlined specific actions that should be taken. This was followed by a discussion covering a range of topics relating to Redwine’s presentation, the agenda for the next meeting, and other topics.

如果从本届会议的标题推断对新出现问题的讨论推迟到讲习班的最后一届会议，那将是错误的。相反，前几届会议都把很大一部分讨论用于确定人们了解甚少和非常需要进一步研究的问题。在主持这次会议时，Sam Redwine做了一项出色的工作，将这些多层次、广泛的问题浓缩成一个连贯的大纲。他的发言由两个主要部分组成:首先，他(不间断地)概述了前几届会议讨论的问题;接着，他强调了今后工作的主题，并概述了应采取的具体行动。随后的讨论涵盖了一系列与Redwine的演讲、下次会议议程和其他主题相关的话题。

引用次数: 2

Data (session summary) 数据(会话汇总)

International Software Process Workshop

Pub Date : 1990-10-01 DOI: 10.5555/317498.317690

M. Penedo

This session addressed the object base and typing issues needed in support of the modeling and implementation of the life-cycle process. In this summary the terms process and life-cycle process are used interchangeably. However, I do not believe that was the case during the workshop; sometimes it seemed that the term process was used in an abstract way1, which led, at times, to some conceptual misunderstandings.Jack Wileden was the keynote speaker for the session. He started by trying to differentiate between two (2) roles in process modeling:The actual modeling of the process, i.e., how do we describe the process independent of its implementation.Process enaction and the environment needs in support of the process model descriptions.He felt most position papers dealt with the second role, even though a few talked about the first. There was not too much discussion with respect to the differences of those roles but performance was mentioned as a key issue for the second role.Wileden proceeded to distinguish an overall “world view” on data issues from specific dimensions of the data support problem (see section 2 for his list of specific dimensions). He listed several possible world views with respect to data in support of life-cycle processes, including: i) typed objects as in programming languages, ii) files (e.g., documents, code, etc), iii) traditional database view. He described his own view as based on the notion of an “object space” (i.e., collections of objects). This more modern view appears to be shared by many of the workshop participants, as reflected in many of the position papers. The group decided not to debate on the definition of the word object, but to consider it related to the concept of abstract data types. (Note: I like to think of objects as the units of data which are identifiable and accessible within a Software Engineering Environment (SEE) and of an Object Management System (OMS) as the SEE component whose objective is to manage those objects; a precise definition of an object is largely dependent on the type model provided by an OMS.)This session did not try to generate lists of issues or requirements. The objective seemed to be to discuss items which were felt important by the group. There were few agreements. Nonetheless, an emerging consensus seemed to be that the current state of the art and state of the practice in database management systems (or object management systems) do not support all the needs of process programming.This summary will concentrate on some of the key items and/or issues discussed, followed by some observations made during the session.

该会议讨论了支持生命周期流程的建模和实现所需的对象基和类型问题。在这个总结中，过程和生命周期过程这两个术语可以互换使用。然而，我认为在研讨会期间情况并非如此;有时，过程这个术语似乎是以抽象的方式使用的，这有时会导致一些概念上的误解。Jack Wileden是这次会议的主讲人。他首先尝试区分流程建模中的两种角色:流程的实际建模，即我们如何独立于流程的实现来描述流程。流程制定和环境需要支持流程模型描述。他认为，大多数立场文件都涉及第二种角色，尽管有一些谈到了第一种角色。对于这两种作用的差别没有进行太多讨论，但提到绩效是第二种作用的一个关键问题。Wileden接着将数据问题的整体“世界观”与数据支持问题的特定维度区分开来(参见第2节，他列出了具体维度)。他列出了支持生命周期过程的数据的几种可能的世界观，包括:i)编程语言中的类型化对象，ii)文件(如文档、代码等)，iii)传统数据库视图。他将自己的观点描述为基于“对象空间”(即对象的集合)的概念。正如许多立场文件所反映的那样，许多讲习班与会者似乎都赞同这种更现代的观点。小组决定不讨论对象这个词的定义，而是考虑它与抽象数据类型的概念有关。(注意:我喜欢把对象看作是软件工程环境(SEE)中可识别和可访问的数据单元，把对象管理系统(OMS)看作是SEE组件，其目标是管理这些对象;对象的精确定义在很大程度上取决于OMS提供的类型模型。)这次会议没有试图产生问题或需求清单。目的似乎是讨论小组认为重要的项目。几乎没有达成什么协议。尽管如此，一个逐渐形成的共识似乎是，数据库管理系统(或对象管理系统)的当前技术状态和实践状态并不能支持过程编程的所有需求。本摘要将集中讨论一些关键项目和(或)讨论的问题，然后是在会议期间提出的一些意见。

{"title":"Data (session summary)","authors":"M. Penedo","doi":"10.5555/317498.317690","DOIUrl":"https://doi.org/10.5555/317498.317690","url":null,"abstract":"This session addressed the object base and typing issues needed in support of the modeling and implementation of the life-cycle process. In this summary the terms process and life-cycle process are used interchangeably. However, I do not believe that was the case during the workshop; sometimes it seemed that the term process was used in an abstract way1, which led, at times, to some conceptual misunderstandings.\u0000Jack Wileden was the keynote speaker for the session. He started by trying to differentiate between two (2) roles in process modeling:The actual modeling of the process, i.e., how do we describe the process independent of its implementation.\u0000Process enaction and the environment needs in support of the process model descriptions.\u0000\u0000He felt most position papers dealt with the second role, even though a few talked about the first. There was not too much discussion with respect to the differences of those roles but performance was mentioned as a key issue for the second role.\u0000Wileden proceeded to distinguish an overall “world view” on data issues from specific dimensions of the data support problem (see section 2 for his list of specific dimensions). He listed several possible world views with respect to data in support of life-cycle processes, including: i) typed objects as in programming languages, ii) files (e.g., documents, code, etc), iii) traditional database view. He described his own view as based on the notion of an “object space” (i.e., collections of objects). This more modern view appears to be shared by many of the workshop participants, as reflected in many of the position papers. The group decided not to debate on the definition of the word object, but to consider it related to the concept of abstract data types. (Note: I like to think of objects as the units of data which are identifiable and accessible within a Software Engineering Environment (SEE) and of an Object Management System (OMS) as the SEE component whose objective is to manage those objects; a precise definition of an object is largely dependent on the type model provided by an OMS.)\u0000This session did not try to generate lists of issues or requirements. The objective seemed to be to discuss items which were felt important by the group. There were few agreements. Nonetheless, an emerging consensus seemed to be that the current state of the art and state of the practice in database management systems (or object management systems) do not support all the needs of process programming.\u0000This summary will concentrate on some of the key items and/or issues discussed, followed by some observations made during the session.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"124 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133271588","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

引用次数: 0

Control (session summary) 控制(会话摘要)

International Software Process Workshop

Pub Date : 1990-10-01 DOI: 10.5555/317498.317691

D. Perry

Bob Balzer initiated the discussion with the contentious claim that planning languages are the proper basis for process models. He then divided the participants into two general camps according to their position papers: those for and those against the planning thesis with subgroups of zealots, believers and supporters.The argument for the thesis is exemplified by two approaches taken by the zealots: 1) [Huff's view] process definition as a plan instantiation — plan construction is subgoaling, envisionment is done via explicit pre and post conditions, and exceptions are handled via replanning; and 2) [Thomas' view] process as a goal-directed activity — where planning separates and systematizes execution dynamics from model dynamics and the paradigm is plan, instantiate, and replan. Balzer listed (by first author on the basis of the position papers) Curtis, Dieters, Heimbigner, Kaiser, Roberts and Balzer as believers in this position, and Boehm, Carr, Cheatham, Feiler, Finkelstein, Kishida, Lehman, Matsumoto, Nakajima, Redwine, Rombach, Scacchi, and Zave as supporters of this position.The argument against the thesis is exemplified by the process programming camp where it is held that process languages will strongly resemble programming languages and that properly conceived and developed environments can support both process and product development. Implicit in this approach is the claim that current languages are sufficient and that there is experience to support this claim. Balzer remarked that the examples in the position papers did not supply a sufficient basis for this claim. Unfortunately, Lee Osterweil had been unable to attend and support his position (though it was in fact supported rather eloquently by others). Garlan, Kellner, Nakagawa, Sugiyama and Wileden were listed by Balzer as believers, and Katayama was listed as a supporter. (Humphrey, Minksy, Penedo, and Reiss were listed as “other”.)The force fit into one of two camps was strongly objected to. Dowson noted that we need to look at the harder issues and support for them, provide abstract arguments and reasoning about them. There may be elements of planning languages and elements of standard languages in a multiparadigm environment. It was also noted that there was as little evidence on the planning paradigm side as was claimed for process programming. In particular, we have not seen any non-trivial plans.Finkelstein noted that the “pro” camp was anyone with a slightly AIish flavor and that his work stressed the local management of the process where the dominant features result from the manipulation of the minutia of work rather than of overall goals. Further we need to keep the methodic angle in full view — that is, we are concerned with more than just the invocation of tools.Further discussion centered on modeling and the levels of description required — for example, descriptions that range from very general goals to explicit, detailed descriptions of how things are to be don

Bob Balzer提出了一个有争议的主张，即计划语言是过程模型的适当基础。然后，他根据参与者的立场文件将他们分为两大阵营:支持和反对规划论文的人，以及狂热者、信徒和支持者的小群体。狂热者采用的两种方法例证了该论文的论点:1)[Huff的观点]过程定义作为计划实例化-计划构建是子目标，设想是通过明确的前置和后设条件完成的，异常是通过重新规划处理的;2)[托马斯的观点]过程是一个目标导向的活动——其中计划将执行动力学与模型动力学分离并系统化，范式是计划、实例化和重新计划。Balzer将Curtis、Dieters、Heimbigner、Kaiser、Roberts和Balzer列为这一立场的支持者，而Boehm、Carr、Cheatham、Feiler、Finkelstein、Kishida、Lehman、Matsumoto、Nakajima、Redwine、Rombach、Scacchi和Zave则是这一立场的支持者。反对的观点是例证过程编程阵营认为过程语言的地方将强烈类似于编程语言和适当的构思和开发环境可以同时支持过程和产品开发。这种方法隐含的意思是，现有的语言就足够了，而且有经验可以支持这种说法。Balzer指出，立场文件中的例子并没有为这一说法提供充分的依据。不幸的是，李·奥斯特威尔未能出席并支持他的立场(尽管事实上他的立场得到了其他人的有力支持)。Garlan, Kellner, Nakagawa, Sugiyama和Wileden被Balzer列为信徒，Katayama被列为支持者。(汉弗莱、明斯基、佩内多和赖斯被列为“其他”。)这支部队属于两个阵营之一，遭到强烈反对。道森指出，我们需要关注更困难的问题，并为它们提供支持，提供抽象的论点和推理。在多范式环境中，可能有规划语言的元素和标准语言的元素。也指出,有尽可能少的证据在规划范式方面声称在编程过程。特别是,我们还没有看到任何有价值的计划。芬克尔斯坦指出，“亲”阵营是任何有点爱尔兰风味的人，他的工作强调过程的局部管理，其中主要特征来自对工作细节的操纵，而不是总体目标。此外，我们需要保持全面的方法论视角——也就是说，我们关心的不仅仅是工具的调用。进一步的讨论集中在建模和所需描述的层次上——例如，描述的范围从非常一般的目标到如何完成事情的明确、详细的描述。Wileden指出，规划语言对于如何实现目标非常模糊，但非常善于识别已经完成的工作。Kellner指出，在一个模型中可能有各种各样的目标，这些目标可能因环境而异。为了充分比较目标，我们需要确定上下文。例如，在学习的背景下，一般目标可能不是特别有用。我们可能需要更多关于如何实现目标的指导，需要更多的结构，需要更详细的“路线图”。从这个意义上说,计划往往是“隐性”比“明确”,尽管它常常声称的相反。总的来说，我们需要各种各样的计划，从总体目标到详细描述。Feiler和Zave一致认为我们需要多种范式:在构建系统的情况下，我们可能只需要总体目标;就培训而言，我们需要细节。罗伯茨同意道森的观点，并继续指出，计划是相关的，因为这是我们在实际过程中所做的:我们计划、分析、设计、实例化、评估和重新计划。Huff指出，我们需要在流程中涵盖一系列计划。一些环境需要高度结构化的流程，而另一些则不需要。我们需要牢记过程和产品(两者密不可分)。Thomas正确地指出，底层的计算模型在考虑表达过程的所有一般性和细节的语言时极其重要。动力是另一个重要的讨论话题。Balzer指出，在制定过程中，流程创建的问题由于创造性的人力投入和计划外的反应性因素而变得更加复杂。一些讨论围绕着“创造”的含义展开。Balzer指出，他在这里关心的是填充一个通用流程，或者实例化一个流程，而不是定义一个新流程。 Perry指出，这就是他和Kaiser的Infuse原型中发生的事情:模块更改和模块集成过程是根据特定时间的产品结构动态实例化的。计划的相对优势在于它对过程有更明确的表示(从而提供更强的理解)，并且它更模块化(因此更可进化)。此外，由于新的能力、新的限制或新的目标，过程演化的问题(即过程性质的变化)也随之产生。在命令式方法中，需要添加新定义并以可操作的方式集成它，而在计划方法中，添加新定义并自动集成。Tully回应说，将非计划与势在必行的区分过于简单化。巴尔泽对此表示赞同，但他辩称，他是在试图描述一整类语言。这引发了对“善意谎言”规范问题的讨论。Finkelstein区分了“善意的谎言”的两种含义:含义一是我们从一个不正确的规范开始，并系统地纠正它;意思二是我们坚持认为暂时的谎言是一个令人满意的解释，但我们遇到了我们试图掩盖的小问题。意义1对规划语言有影响;意义2对命令式语言有影响。巴尔泽回答说，他相信两种情况:在试图让某人了解情况的情况下，一个人提供善意的谎言;试图理解的东西,人们经常认为善意的谎言,还不知道是不完全正确的。根据Scacchi的说法，流程片段提供了所需的模块化。AI/计划有一些不适合流程建模的缺点。我们可以从计划中获得灵活性，但是我们需要与多范式方法相结合的封装。凯尔纳指出，在人类思维中，我们有一种极其复杂的平衡行为。计划能处理好吗?我们能确定人类的目标是什么，他们隐藏的议程是什么吗?你怎么出来的人,利用过程模型?在非计划方法中，我们关注程序问题——我们关注人们做什么，以便更好地理解如何去做。但是我们怎么得到计划呢?威尔登指出，规划要简洁得多。为了在其他语言中得到等价的东西，我们必须明确地写出实现目标的方法。因此，计划语言更隐式，而不是更显式。如果我们已经有了满足目标的方法，那么将目标集成到模型中就很容易了。但是，如果我们有了一个新的目标，那么我们需要一些东西来告诉我们何时使用它以及如何实现它。Balzer提出了两个观点:1)在实施计划系统时，可以使用命令式语言;2)规划语言的优势也是守卫命令语言的优势——人们必须将模型与显式表示区分开来。Thomas指出，计划语言比守卫命令语言更具动态性。如果你添加一个新的守卫，你仍然有相同的计算模型。柯蒂斯的规划语言支持者被要求描述最大的使用规划构建语言。赫夫在斯坦福研究院为移动机器人SITE命名。系统的大小定义为可选方案的数量。这些备选方案之间的相互作用会导致时间的增加。然而，在半分钟的执行时间内实现了几百个子目标。这个例子是针对单个代理的。问题是我们在软件开发过程中有多个代理交互。道森指出，我们在建筑系统中做项目计划。有些人成功了，有些人没有。例如，考虑执行和维护计划的以下条件:在100页左右的页面中描述了40年的实现工作，使用各种工具并提供相当完整的详细描述，等等。我们希望能够1)支持它们的执行(也就是说，使它们的各个方面可以机器解释，使文书部分自动化，等等)和2)提供从实际计划中抽象出来的方法来表示它们并对它们进行推理。有很强的理论问题，我们需要适当的计算模型。Tully指出，我们需要对方法做同样的事情。如果我们能在计划和方法上都做到这一点，那么我们就做了一件有价值的事情。配置管理(CM)是贯穿各个会议的一条主线。在这里Feiler指出CM是对软件开发过程的控制功能。我们有定义的方法和工具来支持，我们可以从中学习。 CM可以被认为是1)对管理软件演进的支持，2)对

{"title":"Control (session summary)","authors":"D. Perry","doi":"10.5555/317498.317691","DOIUrl":"https://doi.org/10.5555/317498.317691","url":null,"abstract":"Bob Balzer initiated the discussion with the contentious claim that planning languages are the proper basis for process models. He then divided the participants into two general camps according to their position papers: those for and those against the planning thesis with subgroups of zealots, believers and supporters.\u0000The argument for the thesis is exemplified by two approaches taken by the zealots: 1) [Huff's view] process definition as a plan instantiation — plan construction is subgoaling, envisionment is done via explicit pre and post conditions, and exceptions are handled via replanning; and 2) [Thomas' view] process as a goal-directed activity — where planning separates and systematizes execution dynamics from model dynamics and the paradigm is plan, instantiate, and replan. Balzer listed (by first author on the basis of the position papers) Curtis, Dieters, Heimbigner, Kaiser, Roberts and Balzer as believers in this position, and Boehm, Carr, Cheatham, Feiler, Finkelstein, Kishida, Lehman, Matsumoto, Nakajima, Redwine, Rombach, Scacchi, and Zave as supporters of this position.\u0000The argument against the thesis is exemplified by the process programming camp where it is held that process languages will strongly resemble programming languages and that properly conceived and developed environments can support both process and product development. Implicit in this approach is the claim that current languages are sufficient and that there is experience to support this claim. Balzer remarked that the examples in the position papers did not supply a sufficient basis for this claim. Unfortunately, Lee Osterweil had been unable to attend and support his position (though it was in fact supported rather eloquently by others). Garlan, Kellner, Nakagawa, Sugiyama and Wileden were listed by Balzer as believers, and Katayama was listed as a supporter. (Humphrey, Minksy, Penedo, and Reiss were listed as “other”.)\u0000The force fit into one of two camps was strongly objected to. Dowson noted that we need to look at the harder issues and support for them, provide abstract arguments and reasoning about them. There may be elements of planning languages and elements of standard languages in a multiparadigm environment. It was also noted that there was as little evidence on the planning paradigm side as was claimed for process programming. In particular, we have not seen any non-trivial plans.\u0000Finkelstein noted that the “pro” camp was anyone with a slightly AIish flavor and that his work stressed the local management of the process where the dominant features result from the manipulation of the minutia of work rather than of overall goals. Further we need to keep the methodic angle in full view — that is, we are concerned with more than just the invocation of tools.\u0000Further discussion centered on modeling and the levels of description required — for example, descriptions that range from very general goals to explicit, detailed descriptions of how things are to be don","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"11 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129518219","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

引用次数: 0

Describing working environments in OPM 描述OPM中的工作环境

International Software Process Workshop

Pub Date : 1990-10-01 DOI: 10.5555/317498.317749

Y. Sugiyama, E. Horowitz

In OPM, each software process provides a working environment in which programmers can actually work in order to accomplish a designated task, rather than prescribing the algorithm of the task [1], or giving a behavioral description of the task [4]. A process will (i) collect necessary resources, (ii) collect necessary activities, and (iii) specify certain constraint on the execution of activities. A process will also (iv) navigate activities to be performed by a human, (v) execute activities asked by a human, and (vi) execute some activities automatically when certain conditions are met. Each working environment may consist of a different set of resources and activities depending on the task to be performed within it. Thus the software development environment as a whole will be a collection of smaller and heterogeneous working environments.In OPM, process templates are described in a process programming language called Galois [3] which is an extension of C++ [2]. As an example consider the working on bug process illustrated in Figure 1. In the working on bug process, a typical edit-compile-run cycle will be performed in order to fix a bug of given source files. Figure 2 will give a skeleton of the working on bug process in Galois.

在OPM中，每个软件过程都提供了一个工作环境，程序员可以在其中实际工作，以完成指定的任务，而不是规定任务的算法[1]，或者给出任务的行为描述[4]。流程将(i)收集必要的资源，(ii)收集必要的活动，以及(iii)对活动的执行规定一定的约束。流程还将(iv)导航由人工执行的活动，(v)执行人工请求的活动，以及(vi)在满足某些条件时自动执行某些活动。每个工作环境可能由一组不同的资源和活动组成，这取决于其中要执行的任务。因此，软件开发环境作为一个整体将是一个较小的异构工作环境的集合。在OPM中，过程模板是用一种名为Galois[3]的过程编程语言描述的，Galois是c++[2]的扩展。作为一个例子，请考虑图1所示的bug处理过程。在处理bug的过程中，为了修复给定源文件的bug，将执行一个典型的编辑-编译-运行周期。图2给出了在Galois中处理bug过程的框架。

{"title":"Describing working environments in OPM","authors":"Y. Sugiyama, E. Horowitz","doi":"10.5555/317498.317749","DOIUrl":"https://doi.org/10.5555/317498.317749","url":null,"abstract":"In OPM, each software process provides a working environment in which programmers can actually work in order to accomplish a designated task, rather than prescribing the algorithm of the task [1], or giving a behavioral description of the task [4]. A process will (i) collect necessary resources, (ii) collect necessary activities, and (iii) specify certain constraint on the execution of activities. A process will also (iv) navigate activities to be performed by a human, (v) execute activities asked by a human, and (vi) execute some activities automatically when certain conditions are met. Each working environment may consist of a different set of resources and activities depending on the task to be performed within it. Thus the software development environment as a whole will be a collection of smaller and heterogeneous working environments.\u0000In OPM, process templates are described in a process programming language called Galois [3] which is an extension of C++ [2]. As an example consider the working on bug process illustrated in Figure 1. In the working on bug process, a typical edit-compile-run cycle will be performed in order to fix a bug of given source files. Figure 2 will give a skeleton of the working on bug process in Galois.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"16 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127211847","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

引用次数: 1

Review of the state-of-the-art (session summary) 最新技术回顾(会议总结)

International Software Process Workshop

Pub Date : 1990-10-01 DOI: 10.5555/317498.317687

W. Humphrey

The opening session of the 5th International Software Process Workshop covered a wide range of topics so it is not possible to capture its full scope in this brief summary. This paper briefly outlines the main views expressed by the participants and then provides a precis of the participants' comments. Because of the dynamic nature of those discussions, however, I have taken the liberty of grouping related points for a more coherent presentation. I also take full responsibility for any errors or omissions.Even though this first session was entitled “state-of-the-art,” there was little discussion of actual process modeling experience. From the many examples given in the proceedings, however, there was considerable evidence of practical experience and the discussions reflected a general consensus that process modeling methods have been found both practical and helpful. While no examples were given of the unsuccessful application of formal methods, there was a strong minority view that such low-technology methods as procedure manuals and software standards were widely used and are often quite effective.There was also general agreement that tools which include an implicit process were not true process models. To qualify as a process model, the process used by the tool should be explicitly defined. A strong consensus also held that the time had now come to more broadly apply these modeling methods to a range of well-known software process activities. It was felt this would provide useful insights on their development and introduction.While there was no focused discussion on the objectives of process modeling, the purposes noted fell into three general categories:to provide a precise framework for understanding, experimenting with, and reasoning about the process;to facilitate process automation;to provide a basis for process control.An important role of process models is improvement of the combined human/technology activities involved in producing software. Because of the dynamic nature of such people intensive work, it was suggested that these models should include the recursive capability to improve themselves.A subject that was widely discussed and returned to again in subsequent workshop sessions was the special impact of the human element in software process models. While it was agreed that the human element adds considerable complexity, there were widely divergent viewpoints. These ranged from considering human-related issues as outside our area of competence to believing that such issues were central to all process work.Bill Curtis opened this first session with a discussion of key issues and the following challenge: “How much of actual software development behavior will be affected (by process modeling) and what will be the benefit?” He then divided software process issues into two classes: the control process and the learning process. The former concerns management's need for an orderly framework for evaluating progress while the lat

Colin Tully指出，对于过程程序，我们试图描述不完全由机器执行的过程。在这个过程中，我们倾向于接受现有的软件开发范例。由于这些似乎不太吻合，他质疑我们是否走在正确的轨道上，以及我们是否知道哪种范式是最合适的。Gail Kaiser和Frank Belz都认为我们可以从实时系统设计范式中学到很多东西，因为它们都涉及复杂活动的多个异步视图。Peter Feiler质疑过程模型是否与其他涉及人员和工具的领域有如此大的不同。一个常见的问题是寻找有前途的自动化领域。Karen Huff随后观察到，当我们与人打交道时，我们通常会关注我们想要做什么，而不是如何完成的更明确的细节。汉弗莱补充说，应该区分与机器打交道和与人打交道。例如，对于人来说，指令集的模拟既不清晰，跨环境的一致，也不稳定。还有动机和准确性的问题，正如制造业经验所证明的那样，当把人当作机器对待时，人的表现并不好。正如日本的汽车生产或美国铝业公司的铝板生产所证明的那样，当人们感到他们拥有他们正在使用的过程时，人类的表现就会得到提高。在这种情况下，这是通过让他们参与持续的过程改进来实现的。Colin Tully指出这是Manny Lehman关于过程编程的问题。戴夫·加兰接着问道，为什么在一个最先进的会议上，我们没有听到太多关于经验的内容。是因为没有真正的成功吗?Lolo Penedo指出PML-PCE的工作(在Roberts和Snowdon的论文中描述)就是一个很好的例子。威廉·谢弗(Wilhelm Schaefer)指出，他们在为一家大型软件公司的柏林总部正式建模方面取得了相当大的成功。Dieter Rombach说，建模经验越来越多，如果在选择正确的形式主义上投入太多精力，我们可能会重复徒劳的编程搜索，寻找一种正确的语言。因为不可能有一个最好的形式，我们应该选择一些真实的过程示例，并使用可用的方法对它们建模。Bill Curtis接着提出了过程项目的资格问题。例如，MAKE是一个过程程序吗?Bob Balzer认为，一个带有内建过程(虽然不是明确的)的工具不是一个过程程序。Dewayne Perry表示同意，尽管他认为MAKE在一定程度上是合格的，因为它可以协调其他工具的操作。Frank Belz随后指出了将隐含过程构建为工具的危险之一。通过选择一种方法来完成一项可以用几种不同方法完成的工作，整个过程就被限制在这一种选择上。塔利·明斯基指出了工具和控制它们的更大的过程之间的重要区别。例如，对于配置管理，我们不是在处理一个人的系统。通常一个人的行为会影响到很多人。这通常需要一个一致的决策系统。当要更改或提升一个模块时，必须咨询其他相关模块。当冲突出现时，必须在采取建议的行动之前标记并解决这些冲突。这就需要一套规则，这进一步提出了一个问题，即什么规则是合适的，谁来编写这些规则(参见第3部分关于策略的讨论)。塔利还建议，可能应该有一个规则制定等级制度，不同的人有不同的规则制定权力。Bob Balzer随后建议分离流程建模问题。一类涉及我们可以学习和机械化的活动领域。当我们看到什么是成功的，我们可以进行更改以提供进一步的改进。另一个问题涉及过程的正式表示，包括它对工具的使用。马克·道森反对这种整洁的范例。他把鲍勃·巴尔泽的意思解释为:你首先设计一个感兴趣的活动的模型，然后形式化它的表示，最后将其机械化以供执行。他觉得，实际的流程不是这样运作的。我们通常从如何进行的模糊概念开始，破解一个工作的机械化，然后改进它，直到它有效地执行。当我们用它工作了足够长的时间后，我们可能最终理解了这个过程，实际上可能会在大致相同的地方结束。Steve Reiss建议，在这项工作中，我们应该区分那些可以机械化的模型和那些不能机械化的模型。他认为，后者必须是动态的，因为它们通常处理人类行为和管理问题。Watts Humphrey建议Bob Balzer加入第三个类别:发展和改进

{"title":"Review of the state-of-the-art (session summary)","authors":"W. Humphrey","doi":"10.5555/317498.317687","DOIUrl":"https://doi.org/10.5555/317498.317687","url":null,"abstract":"The opening session of the 5th International Software Process Workshop covered a wide range of topics so it is not possible to capture its full scope in this brief summary. This paper briefly outlines the main views expressed by the participants and then provides a precis of the participants' comments. Because of the dynamic nature of those discussions, however, I have taken the liberty of grouping related points for a more coherent presentation. I also take full responsibility for any errors or omissions.\u0000Even though this first session was entitled “state-of-the-art,” there was little discussion of actual process modeling experience. From the many examples given in the proceedings, however, there was considerable evidence of practical experience and the discussions reflected a general consensus that process modeling methods have been found both practical and helpful. While no examples were given of the unsuccessful application of formal methods, there was a strong minority view that such low-technology methods as procedure manuals and software standards were widely used and are often quite effective.\u0000There was also general agreement that tools which include an implicit process were not true process models. To qualify as a process model, the process used by the tool should be explicitly defined. A strong consensus also held that the time had now come to more broadly apply these modeling methods to a range of well-known software process activities. It was felt this would provide useful insights on their development and introduction.\u0000While there was no focused discussion on the objectives of process modeling, the purposes noted fell into three general categories:to provide a precise framework for understanding, experimenting with, and reasoning about the process;\u0000to facilitate process automation;\u0000to provide a basis for process control.\u0000\u0000An important role of process models is improvement of the combined human/technology activities involved in producing software. Because of the dynamic nature of such people intensive work, it was suggested that these models should include the recursive capability to improve themselves.\u0000A subject that was widely discussed and returned to again in subsequent workshop sessions was the special impact of the human element in software process models. While it was agreed that the human element adds considerable complexity, there were widely divergent viewpoints. These ranged from considering human-related issues as outside our area of competence to believing that such issues were central to all process work.\u0000Bill Curtis opened this first session with a discussion of key issues and the following challenge: “How much of actual software development behavior will be affected (by process modeling) and what will be the benefit?” He then divided software process issues into two classes: the control process and the learning process. The former concerns management's need for an orderly framework for evaluating progress while the lat","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"19 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126919262","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

引用次数: 0