Processes are a series of repeatable tasks completed by people to achieve a single objective. Processes have a beginning (entry point) and an end, and can optionally branch at decision points. They can also optionally include management metrics and communications at each process point (Ruderman, 2013).
For software projects, processes are the tasks completed by project team members, such as software testers, to deliver and test software from concept to end-of-life. Project processes are procedures governed by organisational policies and guidelines, which may in turn be governed by industry standards and jurisdictive laws and regulations ((ISC)², n.d.). Processes don’t always need to be defined or followed, particularly agile advocates “people over processes”, but in such circumstances its useful to reflect why the project team deviated from the usual process or whether a new corollary process existed at that moment in time (Beck et al, 2001) (Ruderman, 2013).
For software programs, processes are the tasks completed by users with software to help with their own project processes. In this way, they can be represented as user stories, use cases, user journeys or user functions taken to achieve capability quality. Processes are changes enacted within the software program or its context and are closely tied to the code functionality of the software itself.
While processes themselves can be informal and implicit, they can be explicitly modelled with flow diagrams. This has a number of benefits (Ruderman, 2013):
- It helps to identify what’s really happening within a software program or project team
- It helps to identify accountability for tasks within a project team
- It enables discussions around changes and improvements to a software program or project team
- It can be used to introduce and train new people on current software programs and project processes
- It can help to design tests for a software program
There can be many processes in a software product or project but trying to map them all accurately is an impossible task, so like all models, process flow diagrams are a simplified representation that’s otherwise useful. To help with modelling of processes for simplicity, different levels of process can be created (e.g. high-level, mid-level and low-level) that represent narrowing focus but increasing levels of detail. Each individual process of a higher level can then be broken down into a process flow diagram of a lower level (Ruderman, 2013).
The basic blocks of the process flow diagram:
- Process is the unit of work that a project team member, user or software program must do to continue the process
- Entry criteria are the conditions that must be met before the process can be started otherwise the flow remains held at this point
- Exit criteria are the conditions that must be met before the process can be considered completed and the flow moves onto the next process
- Communications (optional) are who is informed about the status of the process such as when the process is started, completed, held or fails
- Metrics (optional) are measurements taken from the process to help monitor the process for problems or to see how long it takes for future estimates
In addition, there can be branching paths within a process flow diagram represented as decision points with two outcomes. In project processes, this can be review points that cause a project process to repeat.
- Question helps to frame the decision that has to be made which could be a process fork or a project review point
- Option A is one of two binary outputs to the decision point and the first answer to the question
- Option B is one of two binary outputs to the decision point and the second answer to the question
- (ISC)², n.d. Chapter 1 Resource: Security Principles. (ISC)² Certified in Cybersecurity. p. 2. Available at: link
- Beck, K., 2001. Manifesto for Agile Software Development. [online]. Available at: link
- Ruderman, M. 2013. Processes: Your Management Foundation. Management for Everyone: Your Keys to Success. [eBook] Ch. 2.