Automated tools are often used to support software development workflows. Many of these tools are aimed toward a development workflow that relies implicitly on particular supported roles and activities. Developers may already understand how a tool operates; however, developers do not always understand or adhere to a development process supported (or implied) by the tools, nor adhere to prescribed processes when they are explicit. This chapter is aimed at helping both developers and their managers understand and manage workflows by describing a preliminary formal model of roles and activities in software development. Using this purely descriptive model as a starting point, the authors evaluate some existing tools with respect to their description of roles in their processes, and finally show one application where process modeling was helpful to managers. We also introduce an extended model of problem status as an example of how formal models can enrich understanding of the software development process, based on the analysis of process roles
People sometimes make errors. The problem here was not the error, it was the failure of NASA’s systems engineering, and the checks and balances in our processes to detect the error. That’s why we lost the spacecraft.
NASA’s Associate Administrator on the loss of the $327 million Mars Climate Orbiter. IntroductionTop
Many automated tools are available to support software development. There are two main reasons for an organization to use these tools:
Much of software development takes place in distributed environments, or at least where the participants have difficulty meeting regularly face-to-face. Automated (often web-based) tools allow them to collaborate in a generally cost-effective way compared to travel and shipping costs.
Software development workflows prescribe various activities to be tracked and artifacts to be created and maintained. Even when developers are able to collaborate in person, the number of these can become large and therefore requires organizing tools and a central repository.
As with all tools, their effectiveness is determined by how well participants understand how to use them. There is ample evidence that mere use of tools is not sufficient to support an effective workflow. Even if developers understand a tool’s basic operation, they often do not understand or adhere to any development process supported (or implied) by the tool. This chapter examines some popular web-based software engineering tools from a pragmatic role-oriented perspective. That is, we intend to focus on the roles and purposes within the context of the development process, rather than characteristics of artifacts or products.
Our ultimate goals in developing these models is the following:
To better describe and analyze the processes themselves.
To formally analyze and evaluate tools with respect to generally accepted process models, and
To formally compare and contrast the models with each other.
To provide formal definitions based on process models.
The approach in this chapter illustrates all four of these goals. First we motivate the general value of formal models in analyzing process, and then provide some background on workflow modeling with respect to the software development process. The main body of the chapter applies this approach to one particular sub-process (namely bug tracking). Each of the four goals is discussed in turn, using examples to illustrate the approach.
This work continues in the spirit of previous work in modeling development processes (Delugach, 2007) (de Moor & Delugach, 2006) and in using conceptual graphs for modeling communication (Delugach, 2006) and software development (Delugach, 1996) (Delugach, 1992). In this chapter, we use conceptual graphs—a well-known knowledge representation—as a clear and effective way of formally representing the parts of a workflow. In future work, some automated analysis may use conceptual graphs’ formal basis in logical reasoning and inference; however, this chapter does not exploit those capabilities for these illustrations.Top
The Value Of Formal Modeling
At this point, it is useful to evaluate the role of formal modeling in software system development. While nearly all developers acknowledge the value of formally modeling the software system itself, there is less agreement on the role of formal modeling of the process of software development. Resistance to this idea is usually caused by “horror stories” of:
Incorrect or incomplete models of a process, which initially give the impression of soundness but then later reveal themselves to be inappropriate
Models that have been imposed on a development team by either upper management without proper evaluation, or by contractual obligations that are included as “boiler plate” requirements without any evaluation as their appropriateness
Models that are perceived as reducing someone’s power or control, infringing on their “turf” or responsibilities to the overall project.
Key Terms in this Chapter
Workflow Model: A process model specifically aimed at representing a development process, as opposed to an algorithm or program.
Conceptual Graphs: A knowledge modeling approach based on semantic networks and first-order logic, first introduced by Sowa, whereby knowledge is represented by concepts and relations linked together in a bipartite graph.
Software Issue Tracking: Also called “bug tracking”; a process by which issues (errors, defects, faults, problems) in some software component are identified, evaluated, analyzed, authorized and implemented.
Process Model: Any description of a process (not necessarily formal), that shows a series of steps aimed at accomplishing some goal.
Requirements Change Process: A systematic series of steps by which changes to formal software requirements are identified, evaluated, approved and incorporated.
Deontic Effect: A feature of an activity assigning to it some role’s obligations, such as whether the role is required to perform the activity, permitted (but not required) to perform it, or prohibited from performing it.
Formal Model: Any model with well-formed syntax and semantics, such that it is amenable to systematic (usually automatable) processing and analysis subject to logical rules.
Software Development Process: The overall process of software development, from initial inception through analysis, design, implementation, test and deployment.
Complete Chapter List
Brian Whitworth, Aldo de Moor
Brian Whitworth, Aldo de Moor
Prologue: General Socio-Technical Theory
Ann Borda, Jonathan P. Bowen
Ken Eason, José Abdelnour-Nocera
Cleidson R.B. de Souza, David F. Redmiles
Prologue: Socio-Technical Perspectives
Petter Bae Brandtzæg, Jan Heim
Wilson Huang, Shun-Yung Kevin Wang
Elayne W. Coakes, Peter Smith, Dee Alwis
Prologue: Socio-Technical Analysis
Jonas Sjöström, Göran Goldkuhl
Paul J. Bracewell
Mikael Lind, Peter Rittgen
Harry S. Delugach
Dorit Nevo, Brent Furneaux
Prologue: Socio-Technical Design
Anders I. Mørch
Manuel Kolp, Yves Wautelet
Anton Nijholt, Dirk Heylen, Rutger Rienks
Jos Benders, Ronald Batenburg, Paul Hoeken, Roel Schouteten
Mary Allan, David Thorns
Rebecca M. Ellis
Christopher A. Miller
Prologue: Socio-Technical Implementation
Laura Anna Ripamonti, Ines Di Loreto, Dario Maggiorini
Mohamed Ben Ammar, Mahmoud Neji, Adel M. Alimi
Pernilla Qvarfordt, Shumin Zhai
Claire de la Varre, Julie Keane, Matthew J. Irvin, Wallace Hannum
Jeremy Birnholtz, Emilee J. Rader, Daniel B. Horn, Thomas Finholt
Prologue: Socio-Technical Evaluation
John M. Carroll, Mary Beth Rosson, Umer Farooq, Jamika D. Burge
Tanguy Coenen, Wouter Van den Bosch, Veerle Van der Sluys
Olga Kulyk, Betsy van Dijk, Paul van der Vet, Anton Nijholt, Gerrit van der Veer
Janet L. Holland
David Hinds, Ronald M. Lee
Bertram C. Bruce, Andee Rubin, Junghyun An
Prologue: The Future of Socio-Technical Systems
Peter J. Denning
Theresa Dirndorfer Anderson
Laurence Claeys, Johan Criel
Kenneth E. Kendall, Julie E. Kendall