{"title":"A behavioral approach to software process modelling","authors":"L. Williams","doi":"10.1145/75110.75143","DOIUrl":"https://doi.org/10.1145/75110.75143","url":null,"abstract":"Recently, the software engineering community has focused its attention on the process of software creation and evolution as well as the products of that process. Much of this attention has focused on modeling the software process. Software process models are seen as important vehicles for understanding and reasoning about software creation and evolution activities. Software process models may also provide a basis for structuring automated software environments. Environments whose structures embed knowledge about the software process can provide advanced assistance such as automatic tool invocation, automatic detection of certain errors, such as constraint violations, and assistance or enforcement in the use of a particular software development method.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"30 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":"125137494","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":"Applying software process models to the full lifecycle is premature","authors":"D. Notkin","doi":"10.1145/75110.75130","DOIUrl":"https://doi.org/10.1145/75110.75130","url":null,"abstract":"The focus of this workshop is on “executable or interpretable (`enactable`) models of the software process, and their prescriptive application to directly controlling software project activities.” Research and development efforts that focus on relating such models to the full software lifecycle are premature, with insufficient reward to risk ratios. Alternative (and not particularly novel) research approaches, each of which has good reward to risk ratios, are likely to lead us more effectively to the ultimate objective of producing, at reasonable cost, high-quality full lifecycle software development environments\u0000Process programming [3] has been developed to support the construction of a family of environments, each with a distinct and possibly evolving view of the appropriate lifecycle for a specific domain and project. In particular, the intent is to produce a software development environment kernel that can be parameterized by a process program.\u0000Although process programming is not strictly linked to full lifecycle environments, the connection is strong: “We believe that the essence of software engineering is the study of effective ways of developing process programs and of maintaining their effectiveness in the face of the need to make changes.” [3,p.12] Since software engineering addresses the full lifecycle, process programming must do so as well.\u0000Why is applying process programming to the full lifecycle premature? Because computer science history tells us so. Consider both compilers and operating systems.\u0000At first, compilers were thought to be extraordinarily difficult to build. Some, such as the initial Fortran compilers, were built using a variety of ad hoc techniques. As the task became somewhat better understood, formal notations (such as BNF) were developed, along with associated implementations (such as Early's parsing algorithm), to ease the process. Over time, given lots of attention by many researchers, the notions of lexing, parsing, tree attribution, flow analysis, and such became well-known techniques. The technical results demanded significant insights by both theoretical and experimental researchers.\u0000The cost of developing individual compilers, even given these powerful techniques, was still significant. Tools to generate pieces of compilers—such as parser generators—were then developed. These tools, based on formal descriptions, have greatly decreased the cost of constructing compilers. But even current compiler generation technology is not perfect. Front-ends are relatively easy to generate, but there is not yet any truly effective approach to generating back-ends that produce high-quality code.\u0000Now consider operating systems, which are in many ways indistinguishable from environments [1]. There is no operating system generating system; indeed, virtually every piece of each operating system is still constructed from scratch. Even though many operating systems have been constructed, we still do not have a handle on how to red","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"140 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":"121890097","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":"Rule-based modelling of the software development process","authors":"G. Kaiser","doi":"10.1145/75110.75123","DOIUrl":"https://doi.org/10.1145/75110.75123","url":null,"abstract":"MARVEL is a knowledge-based programming environment that assists its users during the implementation, testing and maintenance phases of software projects. It currently addresses the technical aspects of building software systems rather than the managerial aspects of supporting large software projects. MARVEL’S knowledge is supplied as a collection of srraregies, which are combined to define the structure and behavior of the programmin g environment. Each strategy defines facilities appropriate to some specific programmin g language, programming methodology, scale of the target software project, phase of the software life-cycle, and/or personnel role in the software process. The strategies are written in advance by a superuser familiar both with MARVEL and the site’s family of projects, and are later configured to describe the appropriate facilities currently required by the given user.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"2007 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":"116936804","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":"Facilitating process prototyping by controlling the impact of change","authors":"J. Wileden, L. Clarke, A. Wolf","doi":"10.1145/75110.75142","DOIUrl":"https://doi.org/10.1145/75110.75142","url":null,"abstract":"The UMass Software Development Laboratory (SDL), in collaboration with our colleagues in the Arcadia consortium [7], is working toward the development of advanced software environments. An important goal of this work is to support research on software processes. It is increasingly clear that such research must be based on experimental, exploratory, prototyping activities. It is equally clear that process prototyping will require a corresponding ability to rapidly produce and easily modify prototype software environments. As a result, one important element of SDL's environment research has been the development of appropriate tools and techniques to facilitate environment prototyping.\u0000An application-oriented notation and a software reuse capability are two frequently proposed approaches for supporting software prototyping in many traditional application areas. Another common approach is the use of a high-level language that is interpreted rather than compiled. Often the language is weakly typed, or typeless, and any type checking that it might provide is done at run time rather than statically. For certain well-understood applications, the language may be application-oriented. More often it is a general-purpose language such as LISP. Such languages facilitate rapid development and easy modification in part because avoiding the time required to compile or type check reduces development and modification time.\u0000While these approaches are beneficial for rapid creation of a software system, they are not as valuable for supporting the easy modification that is required in experimental situations. This is particularly true if the prototype system being modified is large and complex. Realistic process experimentation will require the use of full-fledged software environment prototypes. Such prototypes are by nature large, complex and highly interrelated collections of components. Those components include tools, such as editors, compilers, testing and debugging support systems and the like, and also data objects, such as source text, abstract syntax trees, object modules, symbol tables, test data sets, test results and many others. The components are highly interrelated in that a typical activity by an environment user will involve coordinated actions by several tools affecting several (typically shared) data objects. These characteristics of environment prototypes have led us to conclude that tools and techniques for controlling the impact of change are of primary importance for facilitating the prototyping of environments.\u0000Controlling the impact of change in environment prototyping is intimately related to the information visible through the interfaces of environment components. A change to an environment component can only have an impact on another component if that other component can observe the change. Thus, the more that a component's interface conceals information about aspects of the component that may change, the less chance there is for a change t","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"111 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":"121634095","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":"Software reuse processes","authors":"S. Redwine, W. Riddle","doi":"10.1145/75110.75135","DOIUrl":"https://doi.org/10.1145/75110.75135","url":null,"abstract":"Fourteen U.S. aerospace companies have established the Software Productivity Consortium to increase the productivity of their software-related personnel and the suitability of the software systems they produce. The Consortium’s efforts are focused on making prototyping and reuse a routine part of the development and maintenance of complex, embedded software systems. The Consortium’s products include software engineering tools and library facilities supporting both prototyping and reuse, and tools supporting the configuration of integrated environments composed of tools and library facilities obtained from diverse sources. In developing these products the Consortium is pursuing the productivity-improvement benefits to be derived from automation, elimination, integration and reorganization of software process activities.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"49 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":"128471839","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":"Limits to the mechanization of the detailing step paradigm","authors":"C. J. Koomen","doi":"10.1145/75110.75126","DOIUrl":"https://doi.org/10.1145/75110.75126","url":null,"abstract":"In this paper it is argued that complete formalization of design processes is impossible under the assumption of fully deterministic models of such design processes.\u0000It is argued that non-determinism is needed to allow the designer to come up with solutions for problems which could not have been derived from the initial assumptions using a deterministic problem solving method. Hence, views on the design process should be based on two principles: (1) the use of a formalism to enable a systematic capture and usage of design knowledge, and (2) the assumption of an underlying `noisy` mechanism.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"17 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":"117261317","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":"Software process models and programs: observations on their nature and context","authors":"C. Tully","doi":"10.1145/75110.75141","DOIUrl":"https://doi.org/10.1145/75110.75141","url":null,"abstract":"The author is currently co-principal investigator in a project entitled The Information Systems Factory Study. The other principal investigator is Gavin Qddy , of GEC Marconi Research Centre. The project is fully funded by the UK Government, through the Alvey Directorate of the Department of Trade and Industry. It started in February 1987 and will publish its results in July 1988. Its objectives are to make recommendations (1) on the desirability and feasibility of ISFs, and on strategies for their development, (2) on the requirements and architecture for ISFs. VI and PI are interim deliverables from the Study: both are available on request from the author of this paper.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"200 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":"116169272","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":"Some reservations on software process programming","authors":"M. Lehman","doi":"10.1145/75110.75128","DOIUrl":"https://doi.org/10.1145/75110.75128","url":null,"abstract":"In what follows the term `process programs` is used as shorthand for the stated intended workshop focus `executable and interpretable (surely `interpretable and executable`?) models of the software (`development?`) process and their prescriptive application to directly controlling software project activities`.\u0000At the recent ICSE9 conference [LEH87] I indicated my strong reservations about process programs and the role they could or should play in software development. I questioned whether their pursuit or development would yield more insight into the software development process, produce better understanding of that process or lead to its significant improvement. I also expressed some concern at popularisation of process programming. These reservations and concerns have been intensified by the workshop announcement which appears to reflect the very euphoria I feared. There is no need to repeat the details here and I use this opportunity to briefly explore some underlying and intrinsic reasons for my attitude and concern.\u0000Process programming is, unquestionably, one approach to process modelling. Superficially it appears to have an advantage over other, less formalised, approaches in that its models can be machine interpreted and can, therefore, be used as a process control mechanism. It may for example, be suggested that a program driven mechanism can be used to select and invoke the application of a sequence of IPSE tools. The IPSE itself could then be tuned to the needs of a particular application of the process by preparing and loading an appropriate process program or by adjusting parameters in a program already loaded. Any benefit from an implementation of this approach would, however, be virtual rather than real. The implementors, the manager responsible for progress and the software engineer {LEH86} responsible for the dynamic process composition would have to intervene on completion of each constituent activity to select the next action on the basis of circumstance dependent considerations that cannot be predicted; that must be determined in real time. Indeed, where such intervention is considered to be never necessary, tools being used, and the actions they implement, would be coupled and comprises an entity. In so far as a, so called, process program determines that coupling it simply represents a part of a more complex tool.\u0000With this view the process program is seen to comprise a series of calls for specific actions with a human having to take the decision as to which action — and tool — is next to be invoked.\u0000This situation arises because the process is heavily context dependent. The direction and nature of further progress from any stage is a function of progress already made and how it was achieved; on the nature and properties of the continuously developing process product and on the essential and central role of human creativity in the creation of that product. The process followed to implement a particular program or software sys","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"1 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":"129266191","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号
