Software Process Reengineering Working Group Final Report


Walt Scacchi, ATRIUM Laboratory, and Center for Software Engineering, University of Southern California. 213-740-4782, 213-740-8494 (fax) (Scacchi@gilligan.usc.edu).

Overview

This report provides a summary of the working group on software process reengineering. Broadly construed, the summary addresses two kinds of results:
Each of these will now be further described in turn.

Recurring themes and topics

Three themes or topic areas that garnered an emerging consensus for their importance to software process reengineering were:
Each of these can be further examined as follows.

Process Metrics

Faced with the challenge of how to summarize the many different issues and positions taken within the WG on the topic of software process metrics, the WG agreed to simply state a following set of questions which highlight their discussion:
The consensus view within the WG was these questions represent topics appropriate for academic research, and perhaps the research funding agencies could be tapped to support such investigations.

Institutionalizing process reengineering and change

Changing, renovating, or innovating the current ways and means that industrial firms and government organizations do (or do not) formulate, perform, measure, and redesign their software development processes in a major challenge for both practice and research. The concerns raised in this regard posed in the following questions:
Here, the was some debate as to whether their was an relevant research at hand to shed light on these questions, as well as whether current academic or industrial research projects would be able to address these questions. Thus, in a sense, these questions point to the problematic gap in our collective understanding of what is needed to institutionalize a "new" culture that fosters the continuous proactice of software process reengineering.

Reengineering process engineering paradigms

Given the preceding questions and dilemmas, the WG discussed and debated the relative merits of adopting radically new ways of thinking about the "theory and practice" software process reengineering.
might require and benefit from different or more specialized development processes. For example, the ongoing development of operating systems software within a computer manufacturer is generally overwhelmed by the large size and complexity of the (a) software source base, (b) development team, and (c) insatiable volume of requested software alterations. In such a setting, software process reengineering may be a luxury that can only be undertaken infrequently and with low risk. Alternatively, a software systems consultancy may be able to heavily invest in software process improvements and radical redesigns if they can enable the development of new classes of software products or services, or new sources of revenue associated with existing software development engagements. Thus, the concensus within the WG was that software processes need to be (re)engineered with respect to the type of software development activity, system, and workplace at hand.
  • What about workflow-driven approach to software process (re)design? While we are beginning to see the influence of "groupware" tools and techniques entering into software development processes and support environments, there is little citable crossover of approaches (or results) employed in workflow technologies. Thus, whether or not there can or should be some crossover of concepts and mechanisms from workflow remains an open question. However, addressing such a question is well within academic research capabilities.
  • How is business process redesign similar to or different from software process redesign? All members of the WG could cite cases or tales of successful business process reengineering efforts, which in some instances produced "silver bullet" class results (i.e., factor of 10 or greater improvements in throughput or reduction in cost/cycle time). What is it about BPR that can lead to such dramatic results? What can we learn from BPR that can be applied to SPR? Again, this seemed to be an area that should be readily addressable by academic research.
  • As far as the nascent practice of software process redesign has developed so far, there was some recognition of the need to address questions such as (a) how to avoid process suboptimization, and (b) how do we determine, change, or shift process "granularity" to accomodate:
    • Radical vs. incremental process evolution
    • Global process redesign
    • Redesign of selected or "appropriate" subprocesses
    Each of these questions again raised an awareness of the need for further research and exploration, together with the overall view that such topics might be best addressed through academic and industrial R&D collaborations.
  • Technology roadmap: needs and research efforts at USC

    At this point, the WG sought to articulate some overall statement of direction for what's needed or sought by the CSE industrial affiliates by way of future research (3-5 years out) in the area of software process reengineering. Two topics were then identified:
    Each is described in turn. However, to be accurate, the following descriptions outline more of a statement of possible direction for research investigation, rather than a detailed technology roadmap. Time constraints did not permit such an elaboration by the WG. Nonetheless, these directions can be presented on their own terms as follows.

    Developing a distributed automated software engineering capability

    The overall view of both industry and government affiliates in the WG was that future software environments must accomodate processes that support:
    Accordingly, the affiliates expressed desire to see ongoing CSE research activity in this area. In response, it was noted that USC CSE and ATRIUM Lab projects are currently researching this area. Professors Boehm and Scacchi are now working on a research project sponsored by the USAF through Rome Laboratories to develop a roadmap and demonstration prototype for how models and simulations of software subsystems for domains such as C3I and MIS can be incorporated into the "front-end" of software acquisition, requirements analysis, and architectural specification processes. Professor Scacchi is also leading a project sponsored by ONR that is investigating tools and techniques for supporting and integrating distributed, heterogeneous, and autonomous information systems, data sets, and repositories across wide-area networks. Thus, there is effort now in place at USC that is investigating this topic area, thereby posing the opportunity for future contributions to CSE industrial affiliates.

    Process-driven operating system for virtual organizations.

    A more ambitious formulation of the preceding problem area was cast under the heading of developing a process-driven operating system for virtual organizations. This was seen as a long-term, high-risk, high reward type of endeavor. It can be briefly characterized as follows. An organizational operating system is a computing environment that supports the development, use, and evolution of complex business processes. These processes include, but are not limited to, software (re)development processes, and they are specialized to represent and address organizational requirements while supporting high-performance process work teams. Processes are enacted in the environment to create products or provide services using available resources that are connected to, or embedded within, an organization's information infrastructure. Accordingly, business goals and organizational objectives can be formulated as computational processes that can be iteratively executed, monitored, and continuously improved.

    Advanced organizational operating systems will operate over wide-area networks, and support the integration of heterogenous, autonomous software applications, tools, data sets, and repositories, whether new or legacy, and whether located within or across organizational boundaries. The required support will need to include process construction, modeling, analysis, resourcing, enactment, measurement, verfication and validation, and management of process assets and repositories.

    It was then noted that Professor Scacchi is currently directing USC ATRIUM Lab projects researching this area. At present, this includes activity addressing process life cycle engineering environment (see http://www.usc.edu/dept/ATRIUM/Process_Life_Cycle.html) and a distributed, wide-area hypermedia infrastructure for integrating tools, data, repositories, and processes (see http://www.usc.edu/dept/ATRIUM/Papers/DHT-95.ps). Thus, as above, there is effort now in place at USC that is investigating this topic area, thereby posing the opportunity for future contributions to CSE industrial affiliates.

    Final note

    In closing, we note that there is an accompanying interactive presentation of this report posted on the WWW that can be found at http://www.usc.edu/dept/ATRIUM/SPR.html. This report and presentation were prepared and maintained by Walt Scacchi who can be reached at the e-mail address noted above.