Pub Date : 1991-10-21DOI: 10.1109/ICSP.1991.664351
Mark A. Gisi, Gail E. Kaiser
TheMarvel environment supports rule based modeling of software processes Marvel invokes external tools to carry out steps in a software process One of the major objectives of this research is to invoke existing external tools without needing to modify them This is achieved by encapsulating tools in envelopes designed to abstract the details of a tool from the Marvel kernel thereby providing a black box interface Initially we used the Unix shell language to write envelopes Due to several limitations of the shell language however the black box abstraction could not be fully supported We describe these limitations and discuss how we extended the shell language to obtain a new envelope language that fully supports the black box abstraction c Mark A Gisi and Gail E Kaiser This version appears in the First International Conference on the Software Process October Gisi is supported in part by National Science Foundation grant CCR Kaiser is supported by National Science Foundation grants CCR CDA and CCR by grants from AT T BNR DEC IBM SRA and Xerox by the New York State Center for Advanced Technology on Computer and Information Systems and by the NSF Engineering Research Center for Telecommunications Research Introduction Marvel is a rule based environment that assists users with the software development process and stores software components their attributes and relations in an objectbase Unlike most other process modeling systems Marvel employs existing external tools to carry out the steps of a software process Since tools are expensive to develop in terms of both time and cost a major objective is to employ existing tools without modifying them We achieve this by encapsulation of external tool interactions within envelopes The envelope concept was introduced in the ISTAR environment Each step of a process is represented in the process model by an activity An activity may involve building an executable running a test suite or simply invoking an editor An activity s execution often involves the invocation of one or more commercial o the shelf COTS tools To support the integration of COTS tools without modi cation or even access to their source code the Marvel kernel views each activity as a black box it only knows the activity s input and output re quirements In addition an activity should know nothing about the Marvel kernel For example suppose we want to execute an activity that compiles a C le The activity needs the C source le a set of header include les and the object code le location The activity invokes cc the C compiler with these parameters When the activity completes it returns a status code to the Marvel kernel indicating the status of cc s execution e g success failure An envelope represents an activity s implementation It abstracts the details of the interface of a tool Envelopes were initially written in the Unix shell language which has several advantages it already exists many reusable Unix utilities are available and it provides a means
Marvel环境支持基于规则的软件过程建模，Marvel调用外部工具来执行软件过程中的步骤，本研究的主要目标之一是调用现有的外部工具而无需修改它们，这是通过将工具封装在信封中来实现的，这些信封旨在从Marvel内核中抽象出工具的细节，从而提供一个黑盒接口我们描述了这些限制，并讨论了我们如何扩展shell语言以获得一个完全支持黑盒抽象的新信封语言。这个版本出现在10月的第一届软件过程国际会议上，Gisi得到了美国国家科学基金会的部分支持CCR CDA和CCR由AT T BNR DEC IBM SRA和Xerox由纽约州计算机和信息系统高级技术中心和NSF电信研究工程研究中心授予介绍Marvel是一个基于规则的环境，它帮助用户进行软件开发过程，并将软件组件的属性和关系存储在对象库中。与大多数其他过程建模系统不同，Marvel使用现有的外部工具实施以来的一个软件过程的步骤方面的工具是昂贵的开发时间和成本的主要目标是利用现有工具无需修改我们实现这一外部工具的封装交互信封内信封ISTAR环境的概念被引入流程的每一步都是在流程模型的代表一个活动活动可能涉及构建一个可执行的运行一个测试套件或只是调用一个编辑器活动年代执行通常需要调用一个或多个商业o架子上COTS工具支持COTS的集成工具没有莫迪阳离子甚至访问他们的源代码奇迹内核将每个活动视为一个黑盒,只知道输入和输出活动年代再保险quirements另外一个活动应该一无所知奇迹内核例如假设我们想执行一个活动,le活动需要编译C C源勒一套头le位置活动包括莱斯和对象代码调用cc与这些参数C编译器活动完成时,它返回一个状态码奇迹内核的状态指示cc s执行e g成功失败信封是一个活动年代实现抽象的接口工具的细节信封最初用Unix shell语言编写的,有几个优点它已经存在许多可重用的Unix实用工具,它是可用的提供了一种方法将现有工具联系在一起的不同有用con gurations然而shell语言至少有两个限制在支持黑盒抽象它不支持活动的声明接口我e输入输出没有办法声明类型的传入和传出的数据在一个干净的控制方式它不支持任意数量的数据值的回归一个shell脚本只能返回一个整数通过退出状态码命令有时是需要返回一个活动的更多信息,我们讨论如何扩展shell语言消除这些限制奇迹规则和工具每个活动都封装在一个规则由三个部分组成的一个条件的活动以及一个或多个e格式前一个活动可以执行其条件逻辑表达式必须满意ed活动执行后返回一个状态码,用于选择合适的e等断言的一些变化图中提供了一个编译C文件的规则示例。变量f表示一个变量被赋予一个具有编译状态属性的对象。objectbase的类层次结构是由数据模型设计的。图中显示了一小段我们搜索的代码行
{"title":"Extending a Tool Integration Language","authors":"Mark A. Gisi, Gail E. Kaiser","doi":"10.1109/ICSP.1991.664351","DOIUrl":"https://doi.org/10.1109/ICSP.1991.664351","url":null,"abstract":"TheMarvel environment supports rule based modeling of software processes Marvel invokes external tools to carry out steps in a software process One of the major objectives of this research is to invoke existing external tools without needing to modify them This is achieved by encapsulating tools in envelopes designed to abstract the details of a tool from the Marvel kernel thereby providing a black box interface Initially we used the Unix shell language to write envelopes Due to several limitations of the shell language however the black box abstraction could not be fully supported We describe these limitations and discuss how we extended the shell language to obtain a new envelope language that fully supports the black box abstraction c Mark A Gisi and Gail E Kaiser This version appears in the First International Conference on the Software Process October Gisi is supported in part by National Science Foundation grant CCR Kaiser is supported by National Science Foundation grants CCR CDA and CCR by grants from AT T BNR DEC IBM SRA and Xerox by the New York State Center for Advanced Technology on Computer and Information Systems and by the NSF Engineering Research Center for Telecommunications Research Introduction Marvel is a rule based environment that assists users with the software development process and stores software components their attributes and relations in an objectbase Unlike most other process modeling systems Marvel employs existing external tools to carry out the steps of a software process Since tools are expensive to develop in terms of both time and cost a major objective is to employ existing tools without modifying them We achieve this by encapsulation of external tool interactions within envelopes The envelope concept was introduced in the ISTAR environment Each step of a process is represented in the process model by an activity An activity may involve building an executable running a test suite or simply invoking an editor An activity s execution often involves the invocation of one or more commercial o the shelf COTS tools To support the integration of COTS tools without modi cation or even access to their source code the Marvel kernel views each activity as a black box it only knows the activity s input and output re quirements In addition an activity should know nothing about the Marvel kernel For example suppose we want to execute an activity that compiles a C le The activity needs the C source le a set of header include les and the object code le location The activity invokes cc the C compiler with these parameters When the activity completes it returns a status code to the Marvel kernel indicating the status of cc s execution e g success failure An envelope represents an activity s implementation It abstracts the details of the interface of a tool Envelopes were initially written in the Unix shell language which has several advantages it already exists many reusable Unix utilities are available and it provides a means","PeriodicalId":309190,"journal":{"name":"Proceedings. First International Conference on the Software Process,","volume":"14 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124209650","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}
Pub Date : 1991-10-21DOI: 10.1109/ICSP.1991.664347
N. Belkhatir, J. Estublier, W. Melo
{"title":"A Support to Large Software Development Process","authors":"N. Belkhatir, J. Estublier, W. Melo","doi":"10.1109/ICSP.1991.664347","DOIUrl":"https://doi.org/10.1109/ICSP.1991.664347","url":null,"abstract":"","PeriodicalId":309190,"journal":{"name":"Proceedings. First International Conference on the Software Process,","volume":"115 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117290870","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}
Pub Date : 1991-10-21DOI: 10.1109/ICSP.1991.664349
Peiwei Mi, W. Scacchi
Current software process modeling techniques do not generally support articulation work. Articulation work is the diagnosis, recovery and resumption of development activities that unexpectedly fail. It is an integral part of software process enactment since software processes can sometimes fail or breakdown. This paper presents a knowledge-based model of articulation work in software engineering processes. I t uses empirically-grounded heuristics t o address three problems in articulation work: diagnosing failed development activities, determining appropriate recovery, and resuming software processes. We first investigate the role and importance of articulation work with respect t o planned software development activities. We then outline a knowledge-based model of articulation work. The model has been implemented in a knowledgebased software process modeling environment called the Articulator. Combining the available software process modeling techniques and the model of articulation leads to a better foundation in process improvement and evolution.
{"title":"Modeling Articulation Work in Software Engineering Processes","authors":"Peiwei Mi, W. Scacchi","doi":"10.1109/ICSP.1991.664349","DOIUrl":"https://doi.org/10.1109/ICSP.1991.664349","url":null,"abstract":"Current software process modeling techniques do not generally support articulation work. Articulation work is the diagnosis, recovery and resumption of development activities that unexpectedly fail. It is an integral part of software process enactment since software processes can sometimes fail or breakdown. This paper presents a knowledge-based model of articulation work in software engineering processes. I t uses empirically-grounded heuristics t o address three problems in articulation work: diagnosing failed development activities, determining appropriate recovery, and resuming software processes. We first investigate the role and importance of articulation work with respect t o planned software development activities. We then outline a knowledge-based model of articulation work. The model has been implemented in a knowledgebased software process modeling environment called the Articulator. Combining the available software process modeling techniques and the model of articulation leads to a better foundation in process improvement and evolution.","PeriodicalId":309190,"journal":{"name":"Proceedings. First International Conference on the Software Process,","volume":"22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127008233","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}
Pub Date : 1991-10-21DOI: 10.1109/ICSP.1991.664345
R. Bruynooghe, J. M. Parker, J. Rowles
This paper describes the PSS process support environment. PSS supports the enactment of process programs written in PML. We discuss our approach to developing process programs, and describe the PML language in which we encode them. Though PSS was initially envisaged as a support system for the software development process, we believe it can be used to support processes from other domains. As evidence of this claim, we describe a process program which was written to demonstrate the ability of PSS to support the activities of a Customer Support Department.
{"title":"PSS: A System for Process Enactment","authors":"R. Bruynooghe, J. M. Parker, J. Rowles","doi":"10.1109/ICSP.1991.664345","DOIUrl":"https://doi.org/10.1109/ICSP.1991.664345","url":null,"abstract":"This paper describes the PSS process support environment. PSS supports the enactment of process programs written in PML. We discuss our approach to developing process programs, and describe the PML language in which we encode them. Though PSS was initially envisaged as a support system for the software development process, we believe it can be used to support processes from other domains. As evidence of this claim, we describe a process program which was written to demonstrate the ability of PSS to support the activities of a Customer Support Department.","PeriodicalId":309190,"journal":{"name":"Proceedings. First International Conference on the Software Process,","volume":"29 1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134568865","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}
Pub Date : 1991-10-21DOI: 10.1109/ICSP.1991.664343
H. Yeh
This note reports experiences in an enhancement release where development process built around small, empowered, interdisciplinary teams reduced cycle time by 25% and at the same time improved quality in significant ways. These changes are the results of effective process re-engineering to incorporate software process quality principles and to reorganize people from internally-focused, functionally-aligned groups into focused-on-customers, interdisciplinary teams. Goals and strategies, process specifics, and implementation details are also discussed.
{"title":"Re-Engineering a Software Development Process for Fast Delivery - Approach & Experiences","authors":"H. Yeh","doi":"10.1109/ICSP.1991.664343","DOIUrl":"https://doi.org/10.1109/ICSP.1991.664343","url":null,"abstract":"This note reports experiences in an enhancement release where development process built around small, empowered, interdisciplinary teams reduced cycle time by 25% and at the same time improved quality in significant ways. These changes are the results of effective process re-engineering to incorporate software process quality principles and to reorganize people from internally-focused, functionally-aligned groups into focused-on-customers, interdisciplinary teams. Goals and strategies, process specifics, and implementation details are also discussed.","PeriodicalId":309190,"journal":{"name":"Proceedings. First International Conference on the Software Process,","volume":"55 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125651142","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}
Pub Date : 1991-10-21DOI: 10.1109/ICSP.1991.664346
C. Fernstrom, L. Ohlsson
In this paper', "process enactment" refers to the simultaneous and synchronized execution of a human-oriented development process and an executable model of this process in order to enhance the computer-based support given to the human-oriented process. The aims of process enactment in a software engineering environment can be considered through different perspectives, such as those of the software developing organization, the team and the individual user. This paper is mainly concerned with process enactment from the individual user's point of view. Starting from the general problem of achieving integration while retaining independence between tools, the specific needs on tool independence originating from process enactment of the environments is discussed, leading up to requirements on the environment and on tools. An experimental SEE, developed by Cap Gemini Innovation within the context of the Eureka Software Factory (ESF), which exhibits a number of the required characteristics, is presented in some detail.
{"title":"Integration Needs in Process Enacted Environments","authors":"C. Fernstrom, L. Ohlsson","doi":"10.1109/ICSP.1991.664346","DOIUrl":"https://doi.org/10.1109/ICSP.1991.664346","url":null,"abstract":"In this paper', \"process enactment\" refers to the simultaneous and synchronized execution of a human-oriented development process and an executable model of this process in order to enhance the computer-based support given to the human-oriented process. The aims of process enactment in a software engineering environment can be considered through different perspectives, such as those of the software developing organization, the team and the individual user. This paper is mainly concerned with process enactment from the individual user's point of view. Starting from the general problem of achieving integration while retaining independence between tools, the specific needs on tool independence originating from process enactment of the environments is discussed, leading up to requirements on the environment and on tools. An experimental SEE, developed by Cap Gemini Innovation within the context of the Eureka Software Factory (ESF), which exhibits a number of the required characteristics, is presented in some detail.","PeriodicalId":309190,"journal":{"name":"Proceedings. First International Conference on the Software Process,","volume":"122 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132427819","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}
Pub Date : 1991-10-21DOI: 10.1109/ICSP.1991.664340
D.J. Frailey, R. Bate, J. Crowley, S. Hills
{"title":"Modeling Information in a Software Process","authors":"D.J. Frailey, R. Bate, J. Crowley, S. Hills","doi":"10.1109/ICSP.1991.664340","DOIUrl":"https://doi.org/10.1109/ICSP.1991.664340","url":null,"abstract":"","PeriodicalId":309190,"journal":{"name":"Proceedings. First International Conference on the Software Process,","volume":"365 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126959649","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}
Pub Date : 1991-10-21DOI: 10.1109/ICSP.1991.664348
M. Kellner, P. Feiler, A. Finkelstein, T. Katayama, L. Osterweil, M. H. Penedo, H. D. Rombach
{"title":"ISPW-6 Software Process Example","authors":"M. Kellner, P. Feiler, A. Finkelstein, T. Katayama, L. Osterweil, M. H. Penedo, H. D. Rombach","doi":"10.1109/ICSP.1991.664348","DOIUrl":"https://doi.org/10.1109/ICSP.1991.664348","url":null,"abstract":"","PeriodicalId":309190,"journal":{"name":"Proceedings. First International Conference on the Software Process,","volume":"87 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124855620","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}
Pub Date : 1991-10-21DOI: 10.1109/ICSP.1991.664337
M. Kellner
This paper demonstrates the application of a specific software process modeling approach to certain key managerial activities: ex ante planning, monitoring and recording progress, and dynamic replanning. A realistic example process, with assumed task durations and outcomes, forms the foundation for the illustrations. Automated, quantitative simulations are used to derive schedules, required work effort, and required staffing profiles. Cases of both point estimates (deterministic modeling) and uncertain estimates (stochastic modeling) are discussed, and resource constraints are also considered. This modeling approach is shown to offer distinct advantages over traditional project management approaches such as the critical path method and PERT.
{"title":"Software Process Modeling Support for Management Planning and Control","authors":"M. Kellner","doi":"10.1109/ICSP.1991.664337","DOIUrl":"https://doi.org/10.1109/ICSP.1991.664337","url":null,"abstract":"This paper demonstrates the application of a specific software process modeling approach to certain key managerial activities: ex ante planning, monitoring and recording progress, and dynamic replanning. A realistic example process, with assumed task durations and outcomes, forms the foundation for the illustrations. Automated, quantitative simulations are used to derive schedules, required work effort, and required staffing profiles. Cases of both point estimates (deterministic modeling) and uncertain estimates (stochastic modeling) are discussed, and resource constraints are also considered. This modeling approach is shown to offer distinct advantages over traditional project management approaches such as the critical path method and PERT.","PeriodicalId":309190,"journal":{"name":"Proceedings. First International Conference on the Software Process,","volume":"53 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122125377","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}
Pub Date : 1991-10-21DOI: 10.1109/ICSP.1991.664341
S. Sutton, H. Ziv, D. Heimbigner, H. Yessayan, M. Maybee, L. J. Osterweil, Xiping Song
Software-process programming is a comparatively new approach to the speci cation of software processes. It has attracted widespread interest but has not yet received general acceptance. For process programming to be accepted the issues involved must be better understood and its feasibility must be demonstrated. To these ends we have undertaken the development of REBUS, a prototype process program for the speci cation of software requirements. Through the development of REBUS we hoped to acquire knowledge about basic issues in process programming. In the REBUS program we hoped to o er an example of a plausible process program. In this introduction we review the advantages of process programming and argue that prototyping is an appropriate way to advance the state of the art; in the remainder of the paper we report on REBUS. A software-process program is the encoding of a software process in a formal, process-programming language [Ost87]. Software-process programming is the activity of developing software-process programs from requirements, through design, to code, followed by testing, analysis, use, and maintenance. Process programming is thus modeled after conventional programming. Processprogramming languages (i.e. process coding languages) are analogous to conventional programming languages, and process programs are analogous to conventional application programs. The di erence is that processprogramming languages and process programs apply to the domain of software processes and products. Software processes present new and challenging aspects not found in most conventional applications, for example, the need to accommodate both manual and automated activities and the need to manage highly complex, diverse, and interrelated persistent objects. The goal of process programming is to bring increased rigor and consistency to the representation and application of software development methodologies. Software development methodologies are intended to improve software development by specifying the products to be created, describing the activities to be performed, and guiding the execution of these activities and the use of the products. Examples include the Waterfall model [Roy70], Spiral model [Boe88], Jackson System Development [Jac83, Cam86], Booch Object-Oriented Design [Boo83, Boo86], Structured Analysis and Modeling [RJ77, GS86, BBD77, EFRV86], and Structured Design [Mye78, Ber78]. Several problems prevent current software methodologies from being fully and generally successful. The speci cations of software processes and products are too often semi-formal or informal (if speci ed at all), the processes rely on manual interpretation and control, and the products may be managed and accessed haphazardly. A process may not be clearly understood, and to the extent that it is understood it may be di cult to modify e ectively. Consequently, software processes are often executed uncertainly and inconsistently, and software products are more likely to be
{"title":"Programming a Software Requirements-Specification Process","authors":"S. Sutton, H. Ziv, D. Heimbigner, H. Yessayan, M. Maybee, L. J. Osterweil, Xiping Song","doi":"10.1109/ICSP.1991.664341","DOIUrl":"https://doi.org/10.1109/ICSP.1991.664341","url":null,"abstract":"Software-process programming is a comparatively new approach to the speci cation of software processes. It has attracted widespread interest but has not yet received general acceptance. For process programming to be accepted the issues involved must be better understood and its feasibility must be demonstrated. To these ends we have undertaken the development of REBUS, a prototype process program for the speci cation of software requirements. Through the development of REBUS we hoped to acquire knowledge about basic issues in process programming. In the REBUS program we hoped to o er an example of a plausible process program. In this introduction we review the advantages of process programming and argue that prototyping is an appropriate way to advance the state of the art; in the remainder of the paper we report on REBUS. A software-process program is the encoding of a software process in a formal, process-programming language [Ost87]. Software-process programming is the activity of developing software-process programs from requirements, through design, to code, followed by testing, analysis, use, and maintenance. Process programming is thus modeled after conventional programming. Processprogramming languages (i.e. process coding languages) are analogous to conventional programming languages, and process programs are analogous to conventional application programs. The di erence is that processprogramming languages and process programs apply to the domain of software processes and products. Software processes present new and challenging aspects not found in most conventional applications, for example, the need to accommodate both manual and automated activities and the need to manage highly complex, diverse, and interrelated persistent objects. The goal of process programming is to bring increased rigor and consistency to the representation and application of software development methodologies. Software development methodologies are intended to improve software development by specifying the products to be created, describing the activities to be performed, and guiding the execution of these activities and the use of the products. Examples include the Waterfall model [Roy70], Spiral model [Boe88], Jackson System Development [Jac83, Cam86], Booch Object-Oriented Design [Boo83, Boo86], Structured Analysis and Modeling [RJ77, GS86, BBD77, EFRV86], and Structured Design [Mye78, Ber78]. Several problems prevent current software methodologies from being fully and generally successful. The speci cations of software processes and products are too often semi-formal or informal (if speci ed at all), the processes rely on manual interpretation and control, and the products may be managed and accessed haphazardly. A process may not be clearly understood, and to the extent that it is understood it may be di cult to modify e ectively. Consequently, software processes are often executed uncertainly and inconsistently, and software products are more likely to be ","PeriodicalId":309190,"journal":{"name":"Proceedings. First International Conference on the Software Process,","volume":"36 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131072392","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}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：