Applying software process models to the full lifecycle is premature

• Authors: D. Notkin
• Venue: ISPW '88 Proceedings of the 4th international software process workshop on Representing and enacting the software process
• Year: 1988

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.