Softw. Process Improve. Pract. 5 Understanding Software...

SOFTWARE PROCESS IMPROVEMENT AND PRACTICESoftw. Process Improve. Pract. 2000; 5: 183–195 (2000)

Understanding SoftwareProcess Redesign usingModeling, Analysis andSimulation

Research SectionWalt Scacchi*,†

Institute for Software Research and Information and Computer ScienceDepartment, University of California at Irvine, Irvine, CA 92697-3425USA

Software process redesign (SPR) is concerned with the development and application ofconcepts, techniques and tools for dramatically improving or optimizing software processes.This paper introduces how software process modeling, analysis and simulation may be usedto support software process redesign. This includes an approach to explicitly modelingprocess redesign knowledge, analyzing processes for redesign, and simulating processesbefore, during and after redesign. A discussion follows which identifies a number of topicareas that require further study in order to make SPR a subject of software process researchand practice. Copyright 2000 John Wiley & Sons Ltd

KEY WORDS: software process; process redesign; business process redesign; process modeling and simulation

1. OVERVIEW

Software process improvement (SPI) has traditionallybeen focused on addressing how to improve thecapabilities of a software development organizationthrough maturing and comparative benchmarkingof its software processes. The Capability MaturityModel from the Software Engineering Institute isthe most visible SPI initiative of its kind. However,the CMM is targeted to incremental improvement ofexisting software processes. The CMM top-mostlevel, Optimization (level 5), characterizes those

*Correspondence to: Walt Scacchi, Institute for SoftwareResearch and Information and Computer Science Department,University of California at Irvine, Irvine, CA 92697-3425, USA†E-mail: WscacchiKics.uci.eduContract/grant sponsor: Office of Naval Research;contract/grant number: N00014-94-1-0889Contract/grant sponsor: Defense Acquisition University;contract/grant number: N487650-27803

Copyright 2000 John Wiley & Sons, Ltd.

organizations whose software processes areincrementally improved and refined through moni-toring, measurement and reflexive analysis of well-defined and well-managed processes. However, theCMM does not provide specific guidance for howto improve specific software development or softwareuse processes, nor does it provide guidance for howto redesign legacy processes or how to design newprocesses. In addition, there is no maturity level thatprescribes how to dramatically optimize softwareprocesses to achieve a 10× improvement in pro-ductivity or quality through radical transformation(Shelton 1999). Are radical transformations ofsoftware processes of the same kind as incrementalevolutionary improvements? Probably not, thoughthey appear to lie along a common dimension ormetric that characterizes the scale or scope of processchange that is sought. As such, software processredesign (SPR) merits investigation to determinewhether and how it might lead to dramatic improve-ments in process efficiency or effectiveness.

Research Section W. Scacchi

The study presented in this paper describes howconcepts, techniques and tools for software processmodeling, analysis and simulation may beemployed to support SPR studies. In particular,three research questions that explore and elaboratethese topics can be identified as follows:

I What is software process redesign?I How can modeling, analysis and simulation

help in redesigning software processes?I What approach is needed for acquiring, check-

ing and applying the knowledge required todramatically and continuously improvesoftware processes?

Accordingly, in the sections that follow, eachof these questions is addressed, elaborated andinvestigated in turn.

2. WHAT IS SOFTWARE PROCESSREDESIGN

SPR is concerned with identification, applicationand refinement of new ways to dramaticallyimprove and transform software processes.Software processes of interest include not onlythose associated with software development, butalso those for software system acquisition, use andevolution (Scacchi and Boehm 1998, Scacchi andMi 1997, Scacchi and Noll 1997). Process redesignheuristics, and the source materials from whichthey are derived, serve as the main source ofknowledge for SPR (see Scacchi and Noll 1997,Valente and Scacchi 1999). Process redesign heuris-tics can be independent of application domain andtherefore applicable to a large set of processes(Bashein et al. 1994, Caron et al. 1994). Alternatively,redesign heuristics may be domain-specific, thusapplicable to specific processes in particular set-tings. In examining how SPR heuristics are applied,we can learn the circumstances in which differenttypes of heuristics or practices are most effectiveor least effective (see Software Programs ManagersNetwork 1999). Similarly, we can learn whichprocess redesigns are considered most effectiveand desirable in the view of the participantsworking in the redesigned process, and whattechniques should be employed to facilitate processtransformation and change management (Kettingerand Grover 1995, Scacchi and Noll 1997, Valenteand Scacchi 1999). Therefore, both domain-Copyright 2000 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2000; 5: 183–195

184

independent and domain-specific SPR heuristicsare of interest, as are techniques for determininghow to transform the organizational settings inwhich they are to be applied.

Source materials represent on-line narrativereports from formal analyses, case studies, bestpractices, experience reports and lessons learnedfor how to dramatically improve the cycle time,defect prevention and cost effectiveness of variouskinds of software/business processes. Increasingly,these materials can be found on the World-Wide Web as on-line publications or hypertextdocuments. For example, we can all use searchengines on the Web to conduct a global searchand information retrieval. Though we may findlittle matching a search for ‘software processredesign’, a search for ‘process redesign’ or ‘processre-engineering’ will return much more. Here wemight find case studies, experience reports, bestpractices or lessons learned as narrative documentsposted on academic, non-profit or commercial sites.Clearly, the quality of the ‘knowledge’ and resultsgleaned from sources on the Web may be morevariable than those found in system researchstudies, but in searching for SPR heuristics, whenpotentially relevant source materials are found,hyperlinks can be used to designate the connectionbetween the materials and the heuristics theyinstantiate. In turn, when a heuristic is a potentialcandidate for use in redesigning a software process,its source materials can be browsed and re-examined to help determine its similarity, rel-evancy, trajectory or outcome. Subsequently, asinterest in SPR activities and outcomes grows, thenmore SPR case studies, experience reports, lessonslearned, best practices, counter-examples andcaveats may soon find their way onto the Web(Maurer and Holz 1999). Thus, the developmentof SPR heuristics or SPR knowledge repositoriesshould be viewed as areas for further research,while their application should be integrated incontinuous process improvement initiatives, ratherthan as topics that can be exhaustively analyzedwith limited effort.

3. HOW CAN MODELING, ANALYSISAND SIMULATION HELP SPR

There is a growing body of studies and techniquesthat address the modeling, analysis and simulation

Research Section Software Process Redesign

of software processes (ProSim 1999), yet none ofthe extant studies addresses the subject of SPR astheir primary focus. However, SPR is often implicitas a motivating factor in practical applications ofsoftware process modeling and simulation. Assuch, how can modeling, analysis and simulationof software processes be employed to directlysupport SPR?

3.1. Modeling Process Redesign Knowledge

As already noted, SPR knowledge is often cast asheuristics derived from results of empirical ortheoretical studies. These results may then becoded as production rules for use in a rule-basedor pattern-directed inference system (Nissen 1997),or as tuples (i.e. records of relation attributeinstance values) that can be stored in a relationaldatabase (Kuh et al. 1996). These mechanisms canthen be integrated with other tools for softwareprocess engineering (Brownlie et al. 1997, Scacchiand Mi 1997). However, these alternative represen-tation mechanisms do not focus on what needs tobe modeled, which is the focus here.

From a modeling standpoint, there is need topotentially model many kinds and forms of SPRknowledge. These include: (a) the process to beredesigned in its legacy ‘as-is’ form before redesign;(b) the redesign heuristics (or transformations) tobe applied; (c) the ‘to-be’ process resulting fromredesign; and (d) the empirical sources (e.g. narra-tive case studies) from which the heuristics werederived. Furthermore, we might also choose tomodel (e) the sequence of steps (or the ‘here-to-there’ process) through which different redesignheuristics were applied to progressively transformthe as-is process into its to-be outcome. Modelingthe processes identified in (a), (c) and (e) isalready within the realm of process modeling andsimulation capabilities. However, (b) and (d) posechallenges not previously addressed by softwareprocess modeling technologies. Furthermore, (b)and (d) must be interrelated or interlinked to theprocess models of (a), (c) and (e) to be of greatestvalue for external validation, traceability andincremental evolution purposes (Valente and Scac-chi 1999, Zelkowitz and Wallace 1998). Finally,software process modeling will play a role in (f)facilitating the continuing evolution and refinementof the SPR knowledge web.Copyright 2000 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2000; 5: 183–195

185

3.2. Analyzing Processes for Redesign

Software process models can be analyzed in anumber of ways (Mi and Scacchi 1990, Scacchi andMi 1997). These analyses are generally targeted toimproving the quality of the process model, aswell as to detect or prevent common errors andomissions that appear in large models (Scacchi1999). None the less, software process redesignposes additional challenges when analyzing pro-cess models.

First, it is necessary to analyze the consistency,completeness, traceability and correctness of mul-tiple, interrelated process models (e.g. the as-is,here-to-there and to-be models). This is somewhatanalogous to what happens in a software develop-ment project when multiple notations (e.g. forsystem specification, architectural design, codingand testing) are used, therefore requiring analysisacross, as well as within, different softwaremodel notations.

Second, it is necessary to account for softwareprocess resources throughout the redesign effort.For example, are resources that appear in an as-isprocess replicated, replaced, subsumed or removedin the to-be process? SPR can change the flow ofresources through a process, and thus we want toobserve and measure these changes on process per-formance.

Last, one approach to determining when domain-independent process redesign heuristics can applyresults from measuring structural attributes of theformal or internal representation (e.g. a semanticnetwork or directed attributed graph) of a processas index for selecting process redesign heuristics(Nissen 1997, Nissen 1998, Scacchi and Noll 1997).Each of these challenges necessitates furtherdescription and refinement, as well as characteriz-ing how they can interact in a simplifying orcomplicating manner.

3.3. Simulating Processes Before, During andAfter Redesign

Software process models can be simulated in anumber of interesting and insightful ways usingeither knowledge-based, discrete-entity or systemdynamics systems (ProSim 1999, Scacchi 1999).However, is there still need for another type ofsystem to simulate processes performed by processusers, and under their control?


When considering the role of simulation insupporting software process redesign, a numberof challenges arise. For example, how much ofa performance improvement does an individualredesign heuristic realize? Will different processworkload or throughput characterizations lead tocorresponding variations in simulated performancein both as-is and to-be process models? Howmuch of a performance improvement do multipleredesign heuristics realize, again when consideredwith different workloads or throughputs? Cansimulation help reveal whether all transformationsshould be applied at once, or whether they shouldbe realized through small incremental redesignimprovements? As such, simulation in the contextof SPR raises new and interesting problems requir-ing further investigation and experimentation.

As suggested earlier, there is need to simulatenot only as-is and to-be processes but also thehere-to-there transformation processes. Followingfrom the results in the BPR research literature,transforming an as-is process into its to-be counter-part requires organizational change managementconsiderations. The process users who should beenacting and controlling the transformation processcan benefit from, and contribute to, the modelingand analysis of as-is processes (Scacchi and Mi1997, Scacchi 1999). Similarly, users can recognizepossible process pathologies when observinggraphic animations of process simulations. How-ever, the logic of the process simulation may notbe transparent or easy to understand in terms thatprocess users can readily comprehend.

Conventional approaches to process simulationmay not be empowering to people who primarilyenact software use processes (see Scacchi and Noll1997). Instead, another option may be needed: onewhere process users can interactively traverse (i.e.simulate) a new to-be process, or the here-to-there process, via a computer-supported processwalkthrough or flythrough. In such a simulation,user roles are not simply modeled as objects orprocedural functions; instead, users play their ownroles in order to get a first-person view and feelfor the new process. This is analogous to how‘flight simulators’ are used to help train aircraftpilots. In so doing, user participation may raise ashared awareness of which to-be alternatives makethe most sense, and how the transformationsneeded to transition from the as-is to to-be processshould be sequenced within the organizationalCopyright 2000 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2000; 5: 183–195

186

setting. As such, simulation for SPR raises theneed for new approaches and person-in-the-loopsimulation environments.

4. APPROACH AND RESULTS

Given the challenges identified in the previoussection on how modeling, analysis and simulationcan support SPR, this section presents the approachand initial results from an effort in each of thesethree areas.

4.1. Modeling Approach and Results

In developing models of processes for SPR, weused two tools. First, in order to represent SPRknowledge formally and reason with it, the Loomknowledge representation system was selected(MacGregor and Bates 1995). Loom is a maturelanguage and environment for constructingontologies and intelligent systems that can beaccessed over the Web (Valente et al. 1999). Byusing Loom to re-implement the Articulator processmeta-model ontology (Mi and Scacchi 1990, 1996),formal models of software (or business) processes,classification taxonomies and process redesignheuristics can be represented and manipulated. Inturn, process knowledge can be analyzed, queriedand browsed, while relevant redesign alternativesfor processes can be identified and linked to sourcematerials on the Web. None the less, Loomdoes impose a discipline for formally representingdeclarative knowledge structures in terms of con-cepts (object or pattern types), relations (link typesthat associate concepts) and instances (concept,link, attribute values).

Loom’s deductive classifier utilizes forward-chain-ing, semantic unification and object-oriented truthmaintenance technologies. This capability enablesLoom to compile the declarative knowledge intoa semantic network representation designed toefficiently support on-line deductive query pro-cessing (MacGregor and Bates 1995, Valente et al.1999). Further, Loom’s classifier can be usedto taxonomically classify and update the SPRknowledge base as new SPR cases are entered andformally modeled. This in turn enables the SPRknowledge web to evolve with automated support(Valente and Scacchi 1999).

Second, in order to support the visualization of


the knowledge bases and process models that havebeen constructed, a Web browser interface tothe Loom system is used (Valente et al. 1999).Ontosaurus (1999) is a client-side tool for accessinga Loom server loaded with one or more knowledgebases. It supports queries to Loom and producesWeb pages describing several aspects of a knowl-edge base, including hypertext links to materialson the Web. It is also able to provide simplefacilities for editing the contents of knowledgebases. Figure 1 shows a browser window accessingOntosaurus. The display consists of three windowpanels: Toolbar (top); Reference (left side), andContent (right side). The Toolbar panel consists ofbuttons to perform various operations such asselect domain theory, display theory, save updates etc.The Reference and Content panels are designed todisplay contents of a selected ontology. Links inboth panels display their contents in the Contentwindow. This facilitates exploring various linksassociated with a word or concept in the Referencewindow without the need to continuously go backand forth. The bookmark window holds user-selected links for Web pages to Ontosaurus pages,and is managed by the buttons in the bottom ofthe bookmark window.

Figure 1. Ontosaurus display with Process concept definition loaded in the Reference window and a process redesigninstance in the Contents window

Copyright 2000 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2000; 5: 183–195

187

Loom and Ontosaurus were used to prototypea knowledge-based system that can representand diagnose software process models, redesignheuristics and taxonomies, as well as managehyperlinks to materials accessible on the Web.The system employs the Articulator ontology ofsoftware and business processes (Mi and Scacchi1990, 1996) that are expressed as concepts, attri-butes, relations and values in Loom. Loom providesa semantic network framework based on descrip-tion logics. Nodes (objects) in a Loom representationdefine concepts that have roles or slots to specifytheir attributes. A key feature of description logicrepresentations is that the semantics of the represen-tation language are very precisely specified. Thisprecise specification makes it possible for theclassifier to determine whether one concept sub-sumes another based solely on the formal definitionsof the two concepts. The classifier is an importanttool for evolving ontologies because it can be usedto automatically organize a set of Loom conceptsinto a classification hierarchy or taxonomy basedsolely on their definitions. This capability is parti-cularly important as the ontology becomes large,since the classifier will find subsumption relationsthat people might overlook, as well as modeling


errors that could make the knowledge base incon-sistent.

Overall, 30 process redesign heuristics wereidentified and classified. Six taxonomies were alsoidentified for grouping and organizing access tothe process redesign materials found on the Web.These taxonomies classify and index the casesaccording to:

I Generic type of organization or application domainfor process redesign – financial, manufacturing,research, software development etc.

I As-is ‘problems’ with existing process – off-lineinformation processing, workflow delays, lackof information sharing etc.

I To-be ‘solutions’ (goals) sought for redesignedprocess – automate off-line information pro-cessing tasks, streamline workflow, use e-mailand databases to share information, etc.

I Use of intranet, extranet or Web-based processredesign solutions – build intranet portal forproject staff information, store version-controlled software development objects onWeb server, use HTML forms for data entryand validation process steps etc.

I SPR how-to guidelines or lessons learned – explicittechniques or steps for how to understandand model the as-is process, identify processredesign alternatives, involve process users inselecting redesign alternatives etc.

I SPR heuristics – parallelize sequence of mutuallyexclusive tasks, unfold multi-stagereview/approval loops, disintermediate or flat-ten project management structures, move pro-cess or data quality validation checks to thebeginning, logically centralize information thatcan be shared rather than routed etc.

In turn, each of these taxonomies could be rep-resented as hierarchically nested indices of Weblinks to the corresponding cases. Navigationthrough nested indices that are organized andpresented as a ‘portal’ site is familiar to Web users.Typically, each taxonomy indexes 60–120 casestudies or narrative reports out of the total of morethan 200 that were found on the Web and studied(Valente and Scacchi 1999). This means that somecases could appear in one taxonomy but notanother, while other cases might appear in morethan one, and still others might not appear in anyof these taxonomies if they were judged to notCopyright 2000 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2000; 5: 183–195

188

possess the minimal information needed for charac-terization and modeling.

4.2. Analysis Approach and Results

The first challenge in analyzing processes forredesign points to three types of problems thatarise when processes. First, consistency problems canappear. These denote conflicts in the specificationof several properties of a given process. Forexample, a typical consistency problem is to havea process (e.g. for Software Design) with the samename as one of its outputs (a software design).This is something that occurs surprisingly often inpractice, perhaps because the output is often themost visible characteristic of a process. Second,completeness problems cover incomplete specifi-cations of the process. For instance, a typicalcompleteness problem occurs when we specify aprocess with no inputs. Such a process can beconsidered a ‘miracle’, since it can produce outputswith no inputs. Similarly, a process that lacksoutputs denotes a ‘black hole’, where processinputs disappear without generating any output.Third, traceability problems are caused by incorrectspecification of the origin of the model itself: itsauthor; the agent(s) responsible for its authoringor update, and source materials from which it wasderived. Subsequently, a process model that isconsistent, complete and traceable can be said tobe internally correct. Thus, solving these model-checking problems is required once process modelsare to be formalized.

One of the main reasons Loom is interesting asa formal process representation language is itscapability to represent the abstract patterns of datathat are the very definition of the problemsdiscussed above. This capability is useful in produc-ing simple and readable representations of model-checking analyses. For example, it is possible todefine incomplete process model in plain Englishas ‘a process with no outputs’, or as a black-hole . This can be described in Loom as a processthat provides exactly zero resources:

(defconcept black-hole:is (:and process

(:exactly 0 process-provide-resource)))

Using the process modeling representations dis-cussed above, the user describes a process model


through Ontosaurus for processing by Loom. Thenthe system diagnoses the model provided. One ofthe advantages of using Loom is that once wedefine an instance, Loom automatically applies itsclassifier engine to find out what concepts matchand apply to that instance. This offers a bigadvantage, since there is no need to specify analgorithm for the analysis process: instead, processmodels are analyzed automatically as a new modelis specified. In addition, the classifier performstruth maintenance. Therefore, if a process modelis updated to correct a problem found by thesystem, the classifier will immediately retract theassertion that the problem applies to that process.Thus, the classifier automates this activity forknowledge acquisition and update.

In order to provide a more direct interfaceto the diagnostic process analysis system, theOntosaurus browser was extended to display twonew types of pages. The first displays a descriptionof process in a less Loom-specific way (e.g. forreporting purposes). The second displays a list ofall problems found in the current process modelwe input. Figure 2 shows a screenshot of the Webpage constructed by the server to describe theproblems found in a model of a sample process.

The other two challenges for analyzing processesto support SPR can be addressed with a commoncapability that builds on the one just described.Since a formal representation of a software processmodel can be viewed as a semantic network ordirected attributed graph, it is possible to measurethe complexity attributes of the network/graph asa basis for graph transformation, simplification oroptimization. This means that measures of arichly attributed ‘process flow chart’ could revealattributes such as the number of process steps, thelength of sequential process segments, the degreeof parallelism in process control flow, and others(Nissen 1997, 1998). Subsequently, redesign heuris-tics can be coded as patterns in the structure of aprocess representation. In turn, it then becomespossible to cast a process redesign heuristic as apattern-directed inference rule or trigger whoseantecedent stipulates a process complexity measurepattern, and whose consequent specifies the optim-ization transformation to be applied to the processrepresentation (Nissen 1998). For example, whenanalyzing a software process model, if a sequenceof process steps has linear flow and the inputsand outputs of the steps are mutually exclusive,Copyright 2000 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2000; 5: 183–195

189

then the process steps can be performed in parallel.Such a transformation reduces the time requiredto execute the redesigned process sequence.

Thus, process analysis for SPR can focus onmeasurement of attributes of a formal represen-tation of a software process model that is internallycorrect. This is similar to how compilers performcode optimizations during compilation, after pars-ing and semantic analysis while prior to codegeneration (see Mak 1996).

4.3. Simulation Approach and Results

Questions pertaining to simulated process through-put performance or user workloads before/afterprocess redesign can already be addressed byprocess simulation tools and techniques (ProSim1999). No significant advances are required for this.Similarly, knowledge-based simulation capabilitiescan be employed to determine process performanceimprovements when multiple redesign heuristicsare used to create alternative scenarios for softwareprocess enactment (see Caron et al. 1994, Scacchi1999). None the less, the challenge of how to supportthe transformation of as-is software processes intoto-be redesigned alternatives is not addressed byexisting process simulation approaches. Thus anew approach is required.

One key requirement for managing the organiza-tional transformation to a redesigned softwareprocess is the engagement, motivation andempowerment of process users. The goal is toenable these users to participate and control processredesign efforts, as well as to select the processredesign alternatives for implementation and enact-ment. As the direct use of available simulationpackages may present an obstacle to many processusers, another means to support process manage-ment and change management is needed.

The approach we chose was to engage a processuser community in a multi-site organizationalsetting and partner with them in redesigning theirsoftware use processes (Scacchi and Noll 1997). Inparticular, we developed, provided and demon-strated a prototype wide-area process walkthroughsimulator that would enable the process redesignparticipants with a means to model, redesign andwalkthrough processes that span multiple settingsaccessed over the Internet. With this environment,10 process redesign heuristics were found appli-cable, while the process users chose 9 to implement


Figure 2. Generated report from Loom analysis of a process redesign case

(Scacchi and Noll 1997). In so doing, they eventuallyachieved a factor of 10× in cycle time reduction,and reductions in the number of process stepsbetween 2–1 and 10–1 in the software use processesthat were redesigned (Scacchi and Noll 1997). Aprocess simulator played a central role in theredesign, demonstration and prototyping of theseprocesses. How was this realized?

4.3.1. A Process Simulator ExampleProcess prototyping is a computer-supported tech-nique for enabling software process models to beenacted without integrating the tools and artifactsrequired by the modeled process (Keller and Teufel1998, Scacchi and Mi 1997). It provides processusers the ability to interactively observe and browsea process model, step by step, across all levels ofprocess decomposition modeled, using a graphicCopyright 2000 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2000; 5: 183–195

190

user interface or Web browser. Creating a basicprocess execution run-time environment entailstaking a prototyped process model and integratingthe tools as helper applications that manipulateprocess task artifacts attached to manually orautomatically generated Web/intranet hyperlinkURLs (Noll and Scacchi 1999). Consider the follow-ing example of a simple software developmentprocess displayed in Figure 3 (Noll and Scacchi1999).

This process can be modeled in terms of theprocess flow (precedence relations) and decompo-sition. It can also be attributed with user roles,tools and artifacts for each process step. Further,as suggested above, the directed attributed graphthat constitutes the internal representation of theprocess can be viewed and browsed as a hyper-linked structure that can be navigated with a Web


Figure 3. A simple software development processdepicted as a directed graph

browser. The resulting capability enables processusers to traverse or walkthrough the modeledprocess, task by task, according to the modeledprocess’s control flow. This in turn can realize aWeb-based or intranet-based process simulatorsystem (Noll and Scacchi 1999, Scacchi and Noll1997). Figure 4 provides a view of a set of artifactsthat might be associated with the process in Figure3. Figure 5 provides a similar view of a selectedtask (‘edit’), tool (the Emacs editor), and artifact(loaded in the Emacs edit buffer) associated witha user role as a ‘developer’ (not shown). In addition,the lower right frame in Figure 5 displays a recordof the history of process task events that havetranspired so far.

Using this process prototyping technology, wecould work with process users to iteratively andincrementally model their as-is or to-be processes.Subsequently, modeled processes could then be

Figure 4. A set of artifacts associated with the software process in Figure 3


191

interactively traversed using a Web browser inter-face to the resulting process simulator. Processusers, independent of the time or location of theiraccess to the process model, could then providefeedback, refinement or evaluation of what theysaw in the Web-based process simulator.

Simulators are successful in helping processusers to learn about the operational sequences ofproblem-solving tasks that constitute a softwareprocess (see Kettinger and Grover 1995, Scacchiand Mi 1997). Flight simulators have alreadydemonstrated this same result many times overwith flight operations process users (aircraft pilots).Process walkthrough simulators can identify poten-tial patterns of software process user behavior,as well as potential performance or workflowbottlenecks in their use. This information in turncan help to identify parameter values for a discrete-event simulation of the same process. However,this has not yet been attempted.

Overall, discrete-event and knowledge-basedsimulation systems, together with processwalkthrough simulators, constitute a learning,knowledge sharing, measurement and experimen-tation environment that can support and empowerprocess users when redesigning their softwareprocesses (see Bashein et al. 1994, Kettinger andGrover 1995). Therefore, these process simulation


Figure 5. A software process enactment step presented in a process simulator

capabilities, together with other organizationalchange management techniques, should help min-imize the risk of failure when redesigning softwareprocesses used in complex organizational settings.

5. DISCUSSION

Given the introduction to the subject of SPR, anexplanation of what it is, an explanation of howsoftware process modeling, analysis and simulationfit it, and a demonstration of how it can operatethrough examples, there is still more work to bedone. Thus, the purpose of this discussion is toidentify some of the future needs that have becomeapparent from this investigation.

First, whether dealing with a legacy softwareprocess in a real-world setting, or when browsinga process description found on the Web, capturing,formalizing or otherwise modeling as-is processesis cumbersome. Part of the problem at hand isthat most organizations lack explicit, well-definedor well-managed processes as the starting pointfor an SPR effort. Consequently, attention is oftendirected to focus only on creation of to-be alterna-tives, without establishing an as-is baseline. With-out a baseline, SPR efforts will increase theirlikelihood of failure (see Bashein et al. 1994, Ket-Copyright 2000 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2000; 5: 183–195

192

tinger and Grover 1995). Thus, there is need fornew tools and techniques for the rapid captureand codification of as-is software processes tofacilitate SPR.

Second, there is need for rapid generation of to-be and here-to-there processes and models. SPRheuristics, as well as the tools and techniques foracquiring and applying them, appear to havesignificant face value. They can help to morerapidly produce to-be process alternatives. How-ever, knowledge for how to construct or enact thehere-to-there transformation process in a way thatincorporates change management techniques andprocess management tools is an open problem.Further study is needed here.

Third, SPR heuristics or transformation taxo-nomies may serve as a foundation for developinga theoretical framework for how to best representSPR knowledge. Similarly, such a frameworkshould stipulate what kinds of software processconcepts, links and instances should be represented,modeled and analyzed to facilitate SPR. None theless, there is also a practical need to design andtailor SPR taxonomies to specific software processdomains and organizational settings. At this point,it is unclear whether heuristics for redesigningsoftware use processes are equally applicable tosoftware acquisition, development or evolution


processes. The same can be said for any othercombination of these types of software processes.

Fourth, in the preceding section, software toolsthat support the modeling, analysis and simulationof software processes for redesign were introduced.However, these tools were not developed from thestart as a single integrated environment. Thus theircapabilities can be demonstrated to help elucidatewhat is possible, but what is possible may not bepractical for widespread deployment or productionusage. Thus, there is a need for new environmentsthat support the modeling, analysis and simulationof software processes that can be redesigned,lifecycle engineered and continuously improvedfrom knowledge automatically captured from theWeb (see Brownlie et al. 1997, Maurer and Holz1999, Scacchi and Mi 1997, Valente and Scacchi1999).

Last, as highlighted in the results from researchstudies in business process redesign (Bashein et al.1994, Caron et al. 1994, Kettinger and Grover 1995),and from first-hand experience (Scacchi and Noll1997, Scacchi 1999), process users need to beinvolved in redesigning their own processes.Accordingly, the temptation to seek fully automatedapproaches to generating alternative to-be processdesigns from the analysis of an as-is processmodel must be mitigated. The concern here is tounderstand when or if fully automated SPR isdesirable, and in what kinds of organizationalsettings. For example, there can be SPR situationswhere automated redesign may not be a suitablegoal or outcome. This is in organizational settingswhere process users seek empowerment andinvolvement in redesigning and controlling theirprocess structures and workflow. In settings suchas these, the ability to access, search/query, selectand evaluate possible process redesign alternativesthrough the system capabilities described abovemay be more desirable (see Scacchi and Noll 1997).Thus the ultimate purpose of support environmentfor SPR may be in supporting and empowering processusers to direct the redesign of their processes,rather than in automating SPR.

Beyond this, one of the goals of SPR should beto minimize the risk of a failed SPR effort. Solutionsthat focus exclusively on technology-driven ortechnology-only approaches to SPR seem doomedto fail. Thus, there remains a challenge for thosethat exclusively choose the technology path to SPRto effectively demonstrate how such an approachCopyright 2000 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2000; 5: 183–195

193

can succeed, in what kinds of organizationalsettings, and with what kinds of skilled processparticipants.

6. CONCLUSIONS

This paper addresses three research questionsthat identify and describe what software processredesign is, how software process modeling andsimulation fit in, and what an approach to SPRmight look like. SPR is proposed as a techniquefor achieving radical, order-of-magnitude improve-ments or reductions in software process attributes.SPR builds on empirical and theoretical resultsin the area of business process re-engineering.However, it also builds on knowledge that can begathered from the Web. Though the quality ofsuch knowledge is more variable, the sources fromwhich it is derived – experience reports, casestudies, lessons learned, best practices and similarnarratives – can be formally represented, hyper-linked and browsed during subsequent use orreuse. A central result from the knowledge collectedso far is that SPR must combine its focus to bothtechniques for changing the organization wheresoftware processes are to be redesigned, as wellas for identifying how software engineering andinformation technology-based process managementtools and concepts can be applied.

Software process modeling, analysis and simul-ation technology can be successfully employed tosupport SPR. In particular, knowledge-based tools,techniques and concepts appear to offer a promisingavenue for exploration and application in thisregard. However, new process modeling, analysisand simulation challenges have been also identified.These give rise to the need to investigate newtools and techniques for capturing, representingand utilizing new forms of process knowledge.Knowledge such as SPR heuristics can play acentral role in rapidly identifying process redesignalternatives. Software process simulation tech-niques in particular may require computer-supported person-driven process simulators, whichenable process users to observe walkthrough orflythrough process redesign alternatives. Finally,software process modeling, analysis and simulationcapabilities that support SPR activities may needto be deployed in ways that engage and facilitatethe needs of users who share processes across


multiple organizational settings, using mechanismsthat can be deployed on the Web.

Last, an approach to SPR that utilizes Web-based tools for software process modeling, analysis,and person-driven simulation has been presented.Initial experiences in using these tools, togetherwith the business process re-engineering andchange management techniques they embody, indi-cates that the objective of order-of-magnitudereductions in software process cycle time andprocess steps can be demonstrated and achievedin complex organizational settings. Whether resultssuch as these can be replicated in all classes ofsoftware processes – acquisition, development,usage and evolution – remains the subject offurther investigation. Similarly, other research prob-lems have been identified for how or whereadvances in software process modeling and simul-ation can lead to further experimental studies andtheoretical developments in the art and practice ofsoftware process redesign.

ACKNOWLEDGEMENTS

The research described in this paper resulted fromcollaborations with the following people at theUSC ATRIUM Laboratory. Dr Andre Valente, nowat Fastv.com, developed the modeling and analysissystem prototype with Loom and Ontosaurusdisplayed in Figures 1 and 2. Professor JohnNoll, now at the Computer Science Department,University of Colorado at Denver, developed themodeling and process simulation walkthroughshown in Figures 4 and 5. The process measurementtechnique and rule-based formulation used forautomated process redesign analysis was firstdeveloped by Professor Mark Nissen, now at theSystems Management Department, Naval Post-graduate School, Monterey, CA. Finally, thisresearch was supported by grants from the Officeof Naval Research (N00014-94-1-0889) and theDefense Acquisition University (N487650-27803).All of these contributions are gratefully acknowl-edged.

REFERENCES

Bashein BJ, Markus ML, Riley P. 1994. Preconditions forBPR success: and how to prevent failures. InformationSystems Management 11(2): 7–13.


194

Brownlie RA, Brown PE, Culver-Lozo K, Striegel JJ.1997. Tools for software process engineering. Bell LabsTechnical Journal 2(1): 130–143.

Caron JR, Jarvenpaa SL, Stoddard DB. 1994. BusinessReengineering at CIGNA Corporation: experiences andlessons learned from the first five years. MIS Quarterly18(3): 233–250.

Keller G, Teufel T. 1998. SAP R/3 Process-OrientedImplementation. Addison-Wesley Longman Limited:Essex, England.

Kettinger WJ, Grover V. 1995. Special section: toward atheory of businesss process change management. Journalof Management Information Systems 12(1): 9–30.

Ku S, Suh Y-H, Tecuci G. 1996. Building an intelligentbusiness process reengineering system: a case-basedapproach. Intelligent Systems in Accounting, Finance andManagement 5(1): 25–39.

MacGregor R, Bates R. 1995. Inside the LOOM descriptionclassifier. SIGART Bulletin 2(3): 88–92.

Mak R. 1996. Writing Compilers and Interpreters. Wiley:New York.

Maurer F, Holz H. 1999. Process-oriented knowledgemanagement for learning software organizations. TwelfthWorkshop on Knowledge Acquisition, Modeling andManagement, Banff, Canada, http://sern/ucalgary.ca/KSI/KAW/KAW99/papers.html

Mi P, Scacchi W. 1990. A knowledge-based environmentfor modeling and simulating software engineering pro-cesses. IEEE Transactions on Knowledge and Data Engineer-ing 2(3): 283–294.

Mi P, Scacchi W. 1997. A meta-model for formulatingknowledge-based models of software development.Decision Support Systems 17(3): 313–330.

Nissen ME. 1997. Reengineering the RFP processsthrough knowledge-based systems. Acquisition ReviewQuarterly 4(1): 87–100.

Nissen ME. 1998. Redesigning reengineering throughmeasurement-driven inference. MIS Quarterly 22(4):509–534.

Noll J, Scacchi W. 1999. Supporting software developmentprojects in virtual enterprises. Journal of Digital Infor-mation 1(4).

Ontosaurus Web Browser. 1999. http://www.isi.edu/isd/ontosaurus.html.

ProSim. 1999. Selected Papers from the ProSim’99 Work-shop, Special Issue on Software Process SimulationModeling. Journal of Systems and Software 46(2/3).


Scacchi W. 1999. Experiences with software processsimulation and modeling. Journal of Systems and Software46(2): 183–192.

Scacchi W, Boehm BE. 1998. Virtual system acquisition:approach and transitions. Acquisition Review Quarterly5(2): 185–216.

Scacchi W, Mi P. 1997. Process life cycle engineering: aknowledge-based approach and environment. IntelligentSystems in Accounting, Finance and Management 6: 83–107.

Scacchi W, Noll J. 1997. Proccess-driven intranets: lifecycle support for process reengineering. IEEE InternetComputing 1(5): 42–49.

Shelton R. 1999. The Long Game: Revolutionary Change


195

through Radical Innovation. Prism, Third Quarter, ArthurD. Little: Cambridge, MA; 27–39. http://www.arthurdlittle.com/prism/prism.html.

Software Program Managers Networks. 1999.http://www.spmn.com.

Valente A, Russ T, MacGregor R, Swartout W. 1999.Building and (re)using an ontology for air campaignplanning. IEEE Intelligent Systems 14(1): 27–36.

Valente A, Scacchi W. 1999. Developing a knowledgeweb for business process redesign. IJCAI-99 Workshopon Workflow and Process Management, Stockholm,Sweden, August 1999.

Zelkowitz M, Wallace DR. 1998. Experimental modelsfor validating technology. Computer 31(5): 23–31.

Softw. Process Improve. Pract. 5 Understanding Software...

Documents

Transcript of Softw. Process Improve. Pract. 5 Understanding Software...