{"title":"Process modelling in software environments","authors":"V. Ashok, J. Ramanathan, S. Sarkar, V. Venugopal","doi":"10.1145/75110.75112","DOIUrl":"https://doi.org/10.1145/75110.75112","url":null,"abstract":"A tension connector, and offshore platform mooring system embodying the connector, characterized in that the connector can be made up remotely and released remotely. The connector comprises a male connector member, typically attached to a string of pipe which serves as a mooring element, and a female connector member, typically secured to an anchoring base at the bottom of a body of water. The connector is made up simply by inserting the male member downwardly into the female member by manipulating the pipe string. Advantageously, two remote release means are provided, one operating hydraulically, the other by manipulation of the pipe string.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"11 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126313373","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}
{"title":"Capturing software processes through the generated objects","authors":"M. Rueher, Didier Ladret, B. Legeard","doi":"10.1145/75110.75138","DOIUrl":"https://doi.org/10.1145/75110.75138","url":null,"abstract":"This paper mainly focusses on the representation of actual specification processes. However, the proposed scheme can be extended to the whole software process.\u0000The specification process is the sequence of operations required for building up a complete specification. Performing these operations mainly yields information objects that can be as various as informal statements, exploratory prototypes, test cases, axiomatic descriptions, user constraints for the elaboration process, etc.\u0000Thus, we propose to materialise the specification process through the representation of all the useful characteristics of these objects. The reason for this choice is the fact that objects are easier to comprehend than processes [Ost87].","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"97 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116613710","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}
{"title":"Probing limits to automation: towards deeper process models","authors":"K. E. Huff","doi":"10.1145/75110.75121","DOIUrl":"https://doi.org/10.1145/75110.75121","url":null,"abstract":"Recent progress in specifying and prescribing software development processes has demonstrated that automated support is an achievable goal. Automated support can, for example, prevent a programmer from starting compilations before an appropriate environment is set up, enforce a policy of regression and performance testing before a customer release, and insure that new source versions are checked back into the source code control system. Such support will be valuable to programmers, whose intellectual energies can be freed from many process details in order to be directed towards other pressing concerns; and, it will be. valuable to managers, who can be assured that certain project policies and conventions are routinely observed.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"50 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128900806","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}
{"title":"Advanced models of the software process","authors":"W. L. Sutton","doi":"10.1145/75110.75140","DOIUrl":"https://doi.org/10.1145/75110.75140","url":null,"abstract":"This paper describes key perspectives on the software process that have evolved as a result of on-going U.S. Navy work to address critical software problems. The paper focuses on structure as it relates to the software process, to process models, and to formal process models. As used in this paper, the term “process” or “software process” refers to the identification and ordering of the activities involved in the development and life-cycle support of a softwarebased system.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"102 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123079502","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}
{"title":"Process programming with Prolog","authors":"Autsuo Ohki, K. Ochimizu","doi":"10.1145/75110.75131","DOIUrl":"https://doi.org/10.1145/75110.75131","url":null,"abstract":"We are developing an integrating mechanism for controlling tool invocations or human design activities. One of the purposes is to construct mechanisms which can acquire the routine work of expert designers. The success of a software project usually depends on the abilities of project members, especially those of designers. If we can make the working behaviour of expert designers clear, and represent them in an executable way, we can provide a way to reuse their design processes. We think that design activity is a problem solving activity where a goal is solved by solving subgoals. A rule-based representation of designers' processes, hence, is one of the promising approaches for realising executable process programming proposed by Osterweil [l].","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"57 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126724833","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}
{"title":"Problems of scale and process models","authors":"D. Perry","doi":"10.1145/75110.75133","DOIUrl":"https://doi.org/10.1145/75110.75133","url":null,"abstract":"While software projects come in a wide variety of sizes and kinds, there are sufficient similarities among them so that we may abstract the general from the particular characteristics. These general characteristics then serve as basic issues in the creation of software processes. Some of these issues are moderately wellunderstood — such as various techniques of refining designs into implementation — while others are not. Scale is one of those important issues that have not been considered sufficiently and it is the issue of scale that I address in this paper.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"39 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122564844","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}
{"title":"Automated support for the enactment of rigorously described software processes","authors":"L. Osterweil","doi":"10.1145/75110.75132","DOIUrl":"https://doi.org/10.1145/75110.75132","url":null,"abstract":"There are many advantages to developing rigorously described software processes. Certainly, they provide the basis for improved project visibility, communication, and coordination. If they are sufficiently rigorous they also provide the basis for effective analysis and error detection which can be used to improve processes. Of the many advantages, however, none strikes me as being more important than the opportunity which rigorous process specifications present for directing the coordination of human and computer resources in support of the effective enactment of software processes.\u0000A number of researchers, both at this Workshop and elsewhere, have recognized this opportunity and have begun to study ways of taking advantage of it. Most of this work has focussed on the development of software environments in which explicit software process representations are used to coordinate the application of software tools. As such, this work is forming an important bridge between our software process research community and the software environments research community.\u0000Most current research seems to be focussing on 1) what language should be used to express the process description, 2) what should the architecture of a process enaction support environment be like, and 3) what object management facilities should the environment have? In each of these three areas, there are important subissues which I believe are not receiving sufficient attention. In addition, it seems to me that the issues of 1) providing adequate user interfaces to such environments and 2) evaluating process descriptions and environments to support their enaction are both not receiving sufficient attention.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"90 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125907454","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}
{"title":"A manager/controller for the software development process","authors":"C. A. Fritsch, D. L. Perry","doi":"10.1145/75110.75119","DOIUrl":"https://doi.org/10.1145/75110.75119","url":null,"abstract":"Enhanced management and control of the product realization process is required by today's marketplace. We propose a computer aided facility for such an enhanced realization of switching system products that are largely software based. This facility, called the Manager/Controller, is based on a three layer architecture which consists of a process description layer which reads and writes to a product definition (information) layer and is managed by a control layer that has both broad and detailed knowledge of the realization activity. In this paper, we will sketch the characteristics of processes that we must control and outline the nature of the Manager/Controller.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"41 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133741436","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}
{"title":"Constructing a dialogic framework for software development","authors":"A. Finkelstein, H. Fuks, Celso Niskier, M. Sadler","doi":"10.1145/75110.75118","DOIUrl":"https://doi.org/10.1145/75110.75118","url":null,"abstract":"The most significant informal motivation for using an understanding of dialogue to explicate program development is readily available. The notion of software development as a dialogic activity coincides with the traditional conception of client(s) and developer(s) sitting face to face across a table the client explaining the requirements and the developer occasionally asking guiding questions, seeking clarification, pointing out inconsistencies and raising unanticipated consequences.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"436 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123608645","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}