The Spiral Model [Boehm,19S6; Belz,19S6] provides a candidate approach to determining the requirements, architecture, and design of a software process. The Spiral Model activity of determining mission objectives and constraints addresses the requirements for the process: the nature of the product required; budget and schedule constraints; organizational and procedural (e.g. contracting) constraints, etc. The Spiral Model "alternatives" activity addresses process architecture and design considerations: the use of prototypes, simulations and competitive concept definition phases; the choice of incremental products, cutover strategies, and integration strategies; the use of design-to-cost, independent V & V contractors, etc. The choice of process architecture is obtained in the Spiral Model by determining which alternative process architecture minimizes the risk of not meeting the system objectives within the system constraints.
{"title":"Applying process programming to the spiral model","authors":"B. Boehm, F. Belz","doi":"10.1145/75111.75114","DOIUrl":"https://doi.org/10.1145/75111.75114","url":null,"abstract":"The Spiral Model [Boehm,19S6; Belz,19S6] provides a candidate approach to determining the requirements, architecture, and design of a software process. The Spiral Model activity of determining mission objectives and constraints addresses the requirements for the process: the nature of the product required; budget and schedule constraints; organizational and procedural (e.g. contracting) constraints, etc. The Spiral Model \"alternatives\" activity addresses process architecture and design considerations: the use of prototypes, simulations and competitive concept definition phases; the choice of incremental products, cutover strategies, and integration strategies; the use of design-to-cost, independent V & V contractors, etc. The choice of process architecture is obtained in the Spiral Model by determining which alternative process architecture minimizes the risk of not meeting the system objectives within the system constraints.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"162 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1989-11-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116327760","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}
Software development embodies a range of software processes. Such processes can be captured in software process models. Two of the reasons for describing software processes through models are to document and communicate a particular process to others, and to encode knowledge of the process in a form processable by computer. Software process modeling has received attention by researchers in recent years - as this series of workshop indicates. Efforts are expended on determining what processes are to be modeled, what of power of the modeling language is, and how the model can be instantiated and executed. This position paper examines a different trend to supporting software processes. Software development environments (SDE) support the evolution of software through teams of developers by providing software version and configuration management and system build functionality. This SDE functionality supports and embodies certain aspects of the software process. We have examined and experimented hands-on with a number of commercial software development environments. The environments include the Rational Environment, Apollo DSEE, Sun NSE, IST Istar, BiiN SMS, and Atherton Software Backplane. These environments have advanced the functionality provided to support software evolution over commonly used development support tools such as Unix Make/RCS, and DEC VMS MMS/CMS. A number of observations can be made about these environments and the way they have attempted to - at least partially - capture (i.e., instantiate) software processes. Separation of mechanisms and policy: This notion has been in practice in operating systems for a number of years. The primitives (mechanisms) should be abstract enough to contain some of the semantics of the process model to be instantiated. For example the concept of managed workspace or transaction provides a higher-level abstraction than the check-out/check-in primitives and a working directory. A good set of primitives does not unnecessarily restrict the ability to build desirable executable process models. Such restrictions are detected when process model instantiations and executions are attempted. For example, the check-out operation usually performs two functions - making a program unit modifiable, and locking the unit to prevent concurrent modification. If optimistic development (i.e., permit concurrent development) is to be supported the user would have to resort to the branching function. Sun NSE directly supports optimistic development, but currently does not provide the primitives to provide serialized development (i.e., locking). Policies can generally be encoded by writing an envelope of functions on top of the available primitives. In summary, slow progress is being made in separation of mechanism and policy and in encoding process models. Source code control evolves to software configuration management: Development support in common practice provides source code control for individual files and a system build
{"title":"Software process support through software configuration management","authors":"P. Feiler","doi":"10.5555/317498.317702","DOIUrl":"https://doi.org/10.5555/317498.317702","url":null,"abstract":"Software development embodies a range of software processes. Such processes can be captured in software process models. Two of the reasons for describing software processes through models are to document and communicate a particular process to others, and to encode knowledge of the process in a form processable by computer. Software process modeling has received attention by researchers in recent years - as this series of workshop indicates. Efforts are expended on determining what processes are to be modeled, what of power of the modeling language is, and how the model can be instantiated and executed.\u0000This position paper examines a different trend to supporting software processes. Software development environments (SDE) support the evolution of software through teams of developers by providing software version and configuration management and system build functionality. This SDE functionality supports and embodies certain aspects of the software process. We have examined and experimented hands-on with a number of commercial software development environments. The environments include the Rational Environment, Apollo DSEE, Sun NSE, IST Istar, BiiN SMS, and Atherton Software Backplane. These environments have advanced the functionality provided to support software evolution over commonly used development support tools such as Unix Make/RCS, and DEC VMS MMS/CMS.\u0000A number of observations can be made about these environments and the way they have attempted to - at least partially - capture (i.e., instantiate) software processes.\u0000Separation of mechanisms and policy: This notion has been in practice in operating systems for a number of years. The primitives (mechanisms) should be abstract enough to contain some of the semantics of the process model to be instantiated. For example the concept of managed workspace or transaction provides a higher-level abstraction than the check-out/check-in primitives and a working directory. A good set of primitives does not unnecessarily restrict the ability to build desirable executable process models. Such restrictions are detected when process model instantiations and executions are attempted. For example, the check-out operation usually performs two functions - making a program unit modifiable, and locking the unit to prevent concurrent modification. If optimistic development (i.e., permit concurrent development) is to be supported the user would have to resort to the branching function. Sun NSE directly supports optimistic development, but currently does not provide the primitives to provide serialized development (i.e., locking). Policies can generally be encoded by writing an envelope of functions on top of the available primitives. In summary, slow progress is being made in separation of mechanism and policy and in encoding process models.\u0000Source code control evolves to software configuration management: Development support in common practice provides source code control for individual files and a system build","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"19 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1989-10-10","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128456421","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}
Information systems continue to provide more sophisticated services and we are all more and more reliant on computer systems. Our sofware production techniques need to progress in order to cope with development pressures. However, in many areas of software engineering we are struggling. We must improve our methods and follow predictable development routes without being restrictive. We have to coordinate the parallel activities of staff and machines to improve productivity and reliability.
{"title":"Describing and acting process models with PML","authors":"Clive Roberts","doi":"10.1145/75110.75136","DOIUrl":"https://doi.org/10.1145/75110.75136","url":null,"abstract":"Information systems continue to provide more sophisticated services and we are all more and more reliant on computer systems. Our sofware production techniques need to progress in order to cope with development pressures. However, in many areas of software engineering we are struggling. We must improve our methods and follow predictable development routes without being restrictive. We have to coordinate the parallel activities of staff and machines to improve productivity and reliability.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"44 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":"124204614","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}
Software engineering is distinct from programming methodology but additional assumptions may lead to a useful interpretation of an "execution mechanism" and corresponding process programs. This paper reports experiences with quantitative evolutionary software processes in which procedural process programs were used to control the development of routine process-control software. The paper presents a pragmatic viewpoint. We took the evolutionary approach to attain change locality and avoid diseconomies of scale. Our functional requirements domain was stabilised and parametrised so that a non-functional quantitative approach could have been taken.
{"title":"Enactable models for quantitative evolutionary software processes","authors":"L. Krzanik","doi":"10.1145/75110.75127","DOIUrl":"https://doi.org/10.1145/75110.75127","url":null,"abstract":"Software engineering is distinct from programming methodology but additional assumptions may lead to a useful interpretation of an \"execution mechanism\" and corresponding process programs. This paper reports experiences with quantitative evolutionary software processes in which procedural process programs were used to control the development of routine process-control software. The paper presents a pragmatic viewpoint. We took the evolutionary approach to attain change locality and avoid diseconomies of scale. Our functional requirements domain was stabilised and parametrised so that a non-functional quantitative approach could have been taken.","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":"131141559","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}
A method is basically a set of operations together with rules about where and when particular operations can be applied. An implemented method is put into practice by a combination of human and mechanical agents there is a division of labour between man and machine. Our aim is for all algorithmic operations to be performed by machine, leaving to human deveiopers only those operations requiring “expert” decision-making or the input of novel information.
{"title":"A functional paradigm for software development","authors":"R. MacLean","doi":"10.1145/75110.75129","DOIUrl":"https://doi.org/10.1145/75110.75129","url":null,"abstract":"A method is basically a set of operations together with rules about where and when particular operations can be applied. An implemented method is put into practice by a combination of human and mechanical agents there is a division of labour between man and machine. Our aim is for all algorithmic operations to be performed by machine, leaving to human deveiopers only those operations requiring “expert” decision-making or the input of novel information.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"193 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":"132200722","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}
The purpose of an information base is to mirror software engineering projects (e.g., softwar engineering processes, methods and tools) in a natural way. The changing nature of software engineering projects due to changing objectives or environment characteristics requires the information base to be tailorable. Otherwise it would not be capable of modeling different projects in a natural way, nor would it provide a basis for easily comparing data points from different projects. We believe that we can achieve this tailorability of the information base with the concept of a meta information base. The key idea of a meta information base is that a specific (part of an) information base schema will be generated from a specification of the software engineering project aspect of interest.
{"title":"A specification framework for software processes: formal specification and derivation of information base requirements","authors":"H. D. Rombach","doi":"10.1145/75110.75137","DOIUrl":"https://doi.org/10.1145/75110.75137","url":null,"abstract":"The purpose of an information base is to mirror software engineering projects (e.g., softwar engineering processes, methods and tools) in a natural way. The changing nature of software engineering projects due to changing objectives or environment characteristics requires the information base to be tailorable. Otherwise it would not be capable of modeling different projects in a natural way, nor would it provide a basis for easily comparing data points from different projects. We believe that we can achieve this tailorability of the information base with the concept of a meta information base. The key idea of a meta information base is that a specific (part of an) information base schema will be generated from a specification of the software engineering project aspect of interest.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"26 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":"125256936","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}
With the growing interest in the software engineering process, it is increasingly important to define what we mean by these words. This, however, also requires definitions for software and software engineering as well as some agreement on the scope and boundaries of these activities.
{"title":"The software engineering process: definition and scope","authors":"W. Humphrey","doi":"10.1145/75111.75122","DOIUrl":"https://doi.org/10.1145/75111.75122","url":null,"abstract":"With the growing interest in the software engineering process, it is increasingly important to define what we mean by these words. This, however, also requires definitions for software and software engineering as well as some agreement on the scope and boundaries of these activities.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"12 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":"126763301","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}
Aspect is an integrated project support environment (ipse) that has been developed under the auspices of the Alvey Directorate. The project partners are Systems Designers plc., MARI, ICL and the Universities of Newcastle and York. The project started in April 1984 with initial funding for three years. Following a successful demonstration at the Alvey Conference in August 1987, the project has been extended for another year. It is primarily an ipse kit, in the sense that Aspect would be populated with a particular set of tools to provide a customised ipse for ultimate use. Its architecture is defined by its public tool interface used by providers of tools which will run in Aspect. This interface has three main components: the Information Base, the Human Computer interface, and the Target Interface.
{"title":"The process model of the aspect IPSE","authors":"P. Hitchcock","doi":"10.1145/75110.75120","DOIUrl":"https://doi.org/10.1145/75110.75120","url":null,"abstract":"Aspect is an integrated project support environment (ipse) that has been developed under the auspices of the Alvey Directorate. The project partners are Systems Designers plc., MARI, ICL and the Universities of Newcastle and York. The project started in April 1984 with initial funding for three years. Following a successful demonstration at the Alvey Conference in August 1987, the project has been extended for another year. It is primarily an ipse kit, in the sense that Aspect would be populated with a particular set of tools to provide a customised ipse for ultimate use. Its architecture is defined by its public tool interface used by providers of tools which will run in Aspect. This interface has three main components: the Information Base, the Human Computer interface, and the Target Interface.","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":"129076173","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}
At the end of any software project one could, at least in theory, draw a data flow diagram of all the activities performed, together with the respective inputs and outputs. We could consider such a description as a “trace” of the software project’s history. To arrive at a Software Process Model, one has to abstract from the individual processes (“traces”) to derive a generally applicable basic framework. In this paper we will adopt the terminology of ADPS [IBM_871 where the term “activity type” is used for activity descriptions in the model and “activity” for one instance of an activity type. The term “work item” is used for both inputs and results and “work item type” for the descriptions of work items in the model.
{"title":"Duplicate instances of elements of a software process model","authors":"G. Chroust","doi":"10.1145/75110.75116","DOIUrl":"https://doi.org/10.1145/75110.75116","url":null,"abstract":"At the end of any software project one could, at least in theory, draw a data flow diagram of all the activities performed, together with the respective inputs and outputs. We could consider such a description as a “trace” of the software project’s history. To arrive at a Software Process Model, one has to abstract from the individual processes (“traces”) to derive a generally applicable basic framework. In this paper we will adopt the terminology of ADPS [IBM_871 where the term “activity type” is used for activity descriptions in the model and “activity” for one instance of an activity type. The term “work item” is used for both inputs and results and “work item type” for the descriptions of work items in the model.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"77 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":"124061127","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}
Research into describing software processes (such as design, development, maintenance and reuse) is attracting much attention in the software engineering community. There are a variety of views, ranging from pessimistic to optimistic, about whether it is possible to describe real and practical software processes in such a way as to guide human users in performing software activity: the process of software design, for example, is one of the most creative of human activities, and it may not be possible to achieve a complete formalisation of it at the present time. We are, however, justified in working on software process description for several reasons: every scientific study begins with description; software methods, on which a great deal of work has been done, need to be described in some language so that they can be better used and communicated; and the software industry needs some means of process description to achieve better quality control over products.
{"title":"A hierarchical and functional approach to software process description","authors":"T. Katayama","doi":"10.1145/75110.75124","DOIUrl":"https://doi.org/10.1145/75110.75124","url":null,"abstract":"Research into describing software processes (such as design, development, maintenance and reuse) is attracting much attention in the software engineering community. There are a variety of views, ranging from pessimistic to optimistic, about whether it is possible to describe real and practical software processes in such a way as to guide human users in performing software activity: the process of software design, for example, is one of the most creative of human activities, and it may not be possible to achieve a complete formalisation of it at the present time. We are, however, justified in working on software process description for several reasons: every scientific study begins with description; software methods, on which a great deal of work has been done, need to be described in some language so that they can be better used and communicated; and the software industry needs some means of process description to achieve better quality control over products.","PeriodicalId":414925,"journal":{"name":"International Software Process Workshop","volume":"128 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":"129190351","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
扫码关注我们
求助内容：
应助结果提醒方式：