Officially, it’s the structured set of activities you do to develop a software system. This commonly involves the steps: specification, design and implementation, validation and evolution. Some sort of perspective of a process.
If you’re a reader of my blogs (Hi there, then!), you’ll find familiar some of the processes I’ll mention now.
There are also various different ways of executing these processes:
There are also various different ways of executing these processes:
- plan-driven: All activities are planned in advance. Upon the realization of these, progress is measured.
- agile-processes: This one’s different. Cooler, in my opinion. Planning is incremental, so the process changes with respect to changing customer requirements.
- both: Yes. In reality, most real-world practices are done with a combination of the previous two.
- Waterfall model: Another plan-driven one. Although here, it’s typical to separate each phase of development.
- Incremental development: This one is also a combination. Specification, development and validation are over-lapsed. It’s not necessarily agile, though. It can also be plan-driven.
- Reuse-oriented: It’s assembled from existing components. Also, plan-driven or agile. You’re finding this weird already? Stay with me. Please :)
You see, it’s not like there are some wrong, never-do software processes. It really all comes down to each particular case. Let’s analyze some of these in more detail.
The waterfall method consists of, mainly, 5 different phases:
- requirements definition
- system and software design
- implementation and unit testing
- integration and system testing
- operation and maintenance
Now, don’t get too excited. This method’s most important weakness is that once the process starts, it’s very hard to go back (try going backwards in a real life waterfall!) some phases in case somethings needs to be changed. One phase must be completed 
you move on to the next, also. You might think these so called “changes” would not be such a problem, but they can surely be. Customer requirements can change anytime, as they should. The circumstances around us define our needs, and none of them are constant. Neither should your software process.
That said, the waterfall method is used in some large systems engineering projects where development occurs at multiple sites. In this cases, this method can help coordinate the work.
Now let’s focus on the Incremental Development. This one’s a bit more merged than the waterfall. Also, much less analysis and documentation needs to be done. Mainly, because customer feedback is received in multiple steps of the process. This all leads to faster software delivery and deployment.
But as always, there are some downsides too. One of these is that it may not be very cost-effective to have continuous deliverables.
This process has the following stages:
- component analysis
- requirements modification
- system design with reuse
- development & integration
I hope you now have a different, wider view of what processes are, why we should make a careful analysis of which can be of better purpose to us and how these decisions can impact you and your team, overall.
