Whats in a Software Development Process?

What’s in a Software Development Process?

There are many different aspects to running a software development process. We could choose to adopt a rigorous, highly defined process in a pure waterfall fashion, with a hierarchically organized team distributed over three sites. We could choose a minimalist logical process like ICONIX, and phase it in highly iterative and incremental fashion (i.e., locating our team in a single room with lots of whiteboards to assist in discussion of issues, having daily standup meetings, etc.). And so on.

If we examine the decisions made when running a collaborative (multiperson) software development project, looking back over the last 30 years in particular, it is possible to discern a number of categories of the decisions to be made. These consist of the logical process, if any, adopted; the planning and phasing strategy adopted; the approach to human-centric and communication-related issues; and the regular working practices adopted. We discuss these categories in more detail in the sections that follow (also see Figure 2-2).

Figure 2-2: Like a good sandwich: layers of a development process

Logical Process

A logical process defines what sequence of substeps, if any, we can follow to assist us in getting from our starting point (i.e., some vague idea of the requirements our development is trying to satisfy) to our end point of a working software system that meets a much fuller (and we hope more correct) understanding of the same requirements. Candidates for logical processes include SSADM, ICONIX Process, and the Unified Process (UP), to name just a few.

It is important to note here that we can follow the same logical process using many different planning and phasing approaches. We could adopt a fully waterfall approach (analyze every use case, then design a solution for every use case, etc.) using the steps of UP, or we could adopt (as recommended in this book) a highly incremental approach (analyze the use cases for a prioritized subset of the overall requirements, then do some design for them, etc.) using the steps outlined by ICONIX Process. Put another way, the logical process and planning and phasing are orthogonal concerns.

This book focuses on ICONIX Process, a minimal UML-based logical process that promotes the use of an easy-to-digest subset of UML techniques as signposts to delivering working software. We discuss the qualities of ICONIX Process that make it a good candidate for agile software development later in this chapter.

Planning and Phasing Strategy

At its most fundamental, a project’s planning and phasing strategy dictates how often working software is delivered to the client.

Waterfall approaches to software development attempt to deliver software in one large drop at the end of the project, sometimes years, but generally many months, after the start of the project. Often, but not necessarily, waterfall approaches to development are tied to heavyweight, highly formalized logical processes such as SSADM (to give one example). Planning therefore tends to focus on the timing of the analysis phase, the design phase, and so on.

Iterative and incremental development approaches put the focus on delivering software at shorter intervals and gradually building up a full set of functionality over a period of time. Different approaches mandate different delivery timescales, but these are in general between a couple of weeks to 3 or 4 months. At the core of planning an iterative and incremental project is the decision of what functionality or features are to be delivered in what iteration of the project. The risk-reducing benefits of incremental development are (thankfully) generally accepted in the software development industry nowadays. However, few approaches explicitly deal with the downside of this approach—that the requirements of later increments may mandate a redesign (and subsequent code refactoring) of existing code if the system is not to be put into a state of terminal decline (as often happened in waterfall projects once the much-ignored maintenance phase was reached).

We discuss planning and phasing further in Chapter 9.

Human-Centric and Communication Issues

Do we situate the team in one or multiple locations (assuming we have the choice)? Do we encourage communication through the use of whiteboards and well-positioned “information radiators” (or via e-mail of electronic models)? Are team members assigned specific roles, or do we let roles emerge naturally? Is the development team actually a team? Do the team members pull together and help each other, or are they sniping at each other all the time? Are the team members’ aspirations, desires, and motivations being harnessed correctly by the project?

These concerns are, of course, mostly orthogonal to the logical process and planning/phasing strategy adopted by the project, although it can be argued that incremental development assists in team motivation as team members actually get to see the results of their labor in use at regular intervals.

We further discuss human-centric and communications issues later in this chapter.

Working Practices

Related to communication issues are the regular working practices employed by a project:

• Adopting daily stand-up or weekly sit-down team meetings

• Having (or not having) a formal review of prospective designs

• Ensuring a full set of automated functional tests is kept running at all times

• Putting time aside to refactor bad code when the need arises

• Adopting a code-based test-first design approach

• And so on

We also discuss working practices in the context of various agile processes in Chapter 4.

Guiding Philosophy

Our approach to the aspects of software development just mentioned may be guided by an overall “philosophy,” different flavors of which have been popular at various points in time. The following list presents some examples that we’ve attacked with our sense-of-humor hats on (also see Figure 2-3):

• Hacking: More a non-philosophy, this approach to development is, unfortunately, still present in the software industry. Most often the home of the “unconsciously unconscious,” hacking’s primary prerequisite is to ignore any consideration of the issues we’ve just discussed—or any other issues important to good software development, come to that.

• Agile: This philosophy is currently very much in vogue (hey, we’re writing this book, aren’t we?). The overriding objective is to deliver working software that does what your customer wants. All other aspects of the way you run your project are customized to this end and may change dynamically if they aren’t working. This is the first philosophy to really focus on human-centric issues. Momentarily confused with hacking by some, it has enough flavors to meet most needs.

• Formalism: Still with its (generally university-based) advocates, this philosophy involves proving (or at least knowing that you could prove) in a mathematic fashion that your software does what it’s supposed to do—and then not bothering to implement it as you’ve done the really interesting bit already. Generally, it has nothing to say about the human-centric or working-practices aspects of running a project, and very often little about logical process.

• High ceremony: Often seen on government projects or driven with the needs of the quality assurance (QA) department’s ISO8811-77c.44 certification in mind, this approach involves following and documenting every step of whatever logical process you’ve adopted (regardless of its relevance to your particular circumstances) to the nth degree. Sometimes characteristic of organizations that tend to ignore human-centric concerns, this philosophy’s most common working practice is ensuring all the right boxes are ticked, even if you have to pretend you’ve done the activity (one of the authors was really involved in doing this once). It’s often associated with waterfall development. Also, it’s generally inflexible, in that you can’t adjust things to meet your actual needs. One underlying assumption is that monitoring software development is akin to monitoring a well-defined industrial process, such as silicon-chip manufacturing or photographic-film production.

  
  Figure 2-3: Sliding from Hacking to High Ceremony