Defining effective software development processes is difficult. One the one hand, you need to support constructive systems engineering. On the other hand, you need to be flexible enough to reflect the needs of projects. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden provide four reasons why defining software development process is difficult.
Four Reasons Why Defining Effective Software Processes is Tough
Alexander and Maiden identify four reasons why defining effective software development process is difficult:
- Muddled ‘process levelling’
- Insufficient attention paid to ‘project characterization’ at the outset of a project.
- The concept of ‘meta process’ does not seem to have occurred to most people.
- Silly and false demarcations between management and technical issues when it comes to process definition.
Muddled Process Leveling
Alexander and Maiden write that software processes are muddled together:
In any systems engineering process, there need to be two equally important levels working in concert, which we here refer to as Software Engineering ‘in the large’ and Software Engineering ‘in the small’.
Common Examples of Muddled Process Leveling
Alexander and Maiden give examples of muddled process leveling:
- Failing to recognize that these two levels even exist
- Muddling the two levels up
- Having insufficient variety or richness at either level
- Inappropriate programme ‘shapes’ that lead to process rigidity
- Inability to reduce risk systematically
- Inability to accommodate iteration
Key Take Aways
Here’s my key take aways:
- Think of software engineering process at two levels: macro and micro or ‘in the large’ and ‘in the small’
- When designing your software process, think in terms of a meta-process (a process for creating your process)
- Characterize your projects at the start (evolutionary, incremental, high-risk) so that you can choose the appropriate macro process