FRINK Linked Data Fragments server

Matches in SemOpenAlex for { <https://semopenalex.org/work/W2014484893> ?p ?o ?g. }

• W2014484893 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 environmentsProcess 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.Although 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.Why is applying process programming to the full lifecycle premature? Because computer science history tells us so. Consider both compilers and operating systems.At 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.The 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.Now 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 reduce the cost of their development through parameterization. One reason may be that there is less similarity among different operating systems than among different programming languages. However, this is not the entire problem. Rather, the problem is largely due to our inability to identify and formalize the key aspects of operating systems, as we have so successfully done in compilers.The key lesson from these examples is that experience in building many complete instances is necessary before you can hope to generate instances. And even that is not sufficient if enough formal notations, useful for the actual parameterization, have not been developed.What about environments? The biggest problem is that we simply do not have sufficient instances of full lifecycle environments. In fact, there are no commercially successful instances at all. Without appropriate instances, how can one expect to construct useful environments through parameterization using process programs? How can one determine the key pieces that can be parameterized? How can one hope to combine these pieces effectively? Without a large number of such instances, research in parameterizing full lifecycle environments seems too difficult. Even with such instances, the operating system example indicates that we might ultimately be disappointed anyway.Two not-so-surprising alternatives seem appropriate. First, we need to develop full lifecycle environments, such as those under development in the ISTAR [2] and the Arcadia [4] efforts.1 At the very least, we need experience in environments that address more than a small range of lifecycle activities. Second, we need to focus on narrow ranges of lifecycle activities, with the intention of producing parameterizable efforts in these areas.Work in the first category is of a scope that is beyond the resources available in most academic environments. Douglas Wiebe, one of my Ph.D. students, is working on a dissertation that fits into this second category [5]. He has identified a small, but important, area in which parameterization and generation is promising: the verification of semantic properties of software configurations.Wiebe's research is motivated by the observation that existing systems each have fixed definitions of valid configurations. For instance, Xerox's DF subsystem includes tools that check for completeness and consistency (for precise definitions of these terms), while the UNIX make program places simple temporal constraints on configurations. Wiebe is developing notations and mechanisms that will support the construction of a parameterizable configuration verifier. The foundation of the approach is the development of an interconnection algebra to describe system models, combined with first order predicate calculus as a constraint language to describe the restrictions on the interconnections.Even in this small area, progress is challenging. Similar investigations on other aspects of the software lifecycle, along with aggressive efforts to construct full lifecycle environments, are more appropriate research approaches than is process programming as applied to the full lifecycle." @default.
• W2014484893 created "2016-06-24" @default.
• W2014484893 creator A5011262764 @default.
• W2014484893 date "1988-01-01" @default.
• W2014484893 modified "2023-09-25" @default.
• W2014484893 title "Applying software process models to the full lifecycle is premature" @default.
• W2014484893 cites W2020679989 @default.
• W2014484893 cites W2095958260 @default.
• W2014484893 cites W2105780301 @default.
• W2014484893 cites W3012165363 @default.
• W2014484893 doi "https://doi.org/10.1145/75110.75130" @default.
• W2014484893 hasPublicationYear "1988" @default.
• W2014484893 type Work @default.
• W2014484893 sameAs 2014484893 @default.
• W2014484893 citedByCount "2" @default.
• W2014484893 crossrefType "proceedings-article" @default.
• W2014484893 hasAuthorship W2014484893A5011262764 @default.
• W2014484893 hasConcept C115903868 @default.
• W2014484893 hasConcept C160145156 @default.
• W2014484893 hasConcept C169590947 @default.
• W2014484893 hasConcept C180152950 @default.
• W2014484893 hasConcept C186846655 @default.
• W2014484893 hasConcept C199360897 @default.
• W2014484893 hasConcept C2777904410 @default.
• W2014484893 hasConcept C41008148 @default.
• W2014484893 hasConcept C42669973 @default.
• W2014484893 hasConcept C529173508 @default.
• W2014484893 hasConceptScore W2014484893C115903868 @default.
• W2014484893 hasConceptScore W2014484893C160145156 @default.
• W2014484893 hasConceptScore W2014484893C169590947 @default.
• W2014484893 hasConceptScore W2014484893C180152950 @default.
• W2014484893 hasConceptScore W2014484893C186846655 @default.
• W2014484893 hasConceptScore W2014484893C199360897 @default.
• W2014484893 hasConceptScore W2014484893C2777904410 @default.
• W2014484893 hasConceptScore W2014484893C41008148 @default.
• W2014484893 hasConceptScore W2014484893C42669973 @default.
• W2014484893 hasConceptScore W2014484893C529173508 @default.
• W2014484893 hasLocation W20144848931 @default.
• W2014484893 hasOpenAccess W2014484893 @default.
• W2014484893 hasPrimaryLocation W20144848931 @default.
• W2014484893 hasRelatedWork W1510412245 @default.
• W2014484893 hasRelatedWork W1816021846 @default.
• W2014484893 hasRelatedWork W193520560 @default.
• W2014484893 hasRelatedWork W1965820406 @default.
• W2014484893 hasRelatedWork W1985927726 @default.
• W2014484893 hasRelatedWork W2005159791 @default.
• W2014484893 hasRelatedWork W2069417548 @default.
• W2014484893 hasRelatedWork W2104586319 @default.
• W2014484893 hasRelatedWork W2156298208 @default.
• W2014484893 hasRelatedWork W2157566669 @default.
• W2014484893 hasRelatedWork W2161266370 @default.
• W2014484893 hasRelatedWork W2246727402 @default.
• W2014484893 hasRelatedWork W2397203449 @default.
• W2014484893 hasRelatedWork W2400282065 @default.
• W2014484893 hasRelatedWork W2762317461 @default.
• W2014484893 hasRelatedWork W2898333406 @default.
• W2014484893 hasRelatedWork W2903431435 @default.
• W2014484893 hasRelatedWork W2998127210 @default.
• W2014484893 hasRelatedWork W3006715821 @default.
• W2014484893 hasRelatedWork W1738974586 @default.
• W2014484893 isParatext "false" @default.
• W2014484893 isRetracted "false" @default.
• W2014484893 magId "2014484893" @default.
• W2014484893 workType "article" @default.