Lightweight vs. heavyweight processes: is this even the right question?

ABSTRACT

Interest in the use of processes to provide assistance in software development activities remains at a high level. But the focus of attention has shifted in recent years. Early work emphasizing the study of languages for defining processes was rapidly eclipsed by process evaluation and improvement work, most notably the Capability Maturity Model (CMM). As process improvement has matured as a strategy and philosophy it has also given rise to a strong reaction to the perception that it is unduly ponderous and constraining. Movements such as Extreme Programming (XP) have cast themselves as lightweight alternatives, emphasizing the primacy of freedom and flexibility. Both philosophies and communities continue to grow in size, development, and depth of understanding.The goal of this panel will be to explore the differences between these major approaches to the use of process in software development by bringing together leading articulate exponents of the approaches. Each panelist will be charged with presenting a very concise characterization of the approach being represented. But the focus of the panel will be on understanding the nature of the differences in approach, and the reasons for these differences. Similarities will be sought as well.An underlying hypothesis of the panel is that the differences in approach arise in large measure from differences in objective and differences in assumptions about the software development context. Thus, for example, one approach may be intended to support very long range organizational objectives, while the other may be more tactically oriented. One approach may assume that evolvability is an overriding objective, while another may be more focused on speed to market. One may make stronger assumptions about the skills and training of project personnel. The panel will attempt to delve into these issues to see if it may be possible to suggest criteria for suggesting which approach (and possible adaptation) should be selected for a given development situation.In a larger sense, the goal of this panel is to suggest the possibility of a discipline of software process engineering. Insofar as the panel is able to suggest that development situations can be used to guide the selection of process approaches to the provision of assistance, might this then be an indication that process formalisms could play a role in subsequent specification of detailed processes, and evaluation of their effectiveness?The panel will react to this and related questions. While lively interchanges among the panelists will be stimulated and expected, similar interchanges with the audience will also be cultivated.

INDEX TERMS

Primary Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
      D.2.3 Coding Tools and Techniques
          Subjects: Structured programming

Additional Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
      D.2.3 Coding Tools and Techniques
          Subjects: Top-down programming
      D.2.9 Management
          Subjects: Software process models (e.g., CMM, ISO, PSP)

General Terms:
Algorithms, Design, Performance