SDLC – Software Development Lifecycle … what’s the point? (part 1 of many)

  • Article

On my way to the American continent I was pondering over the issue of process, of views, of strategies and of challenges in the software engineering world. Having been involved  with bits and bytes since the early 80’s I have been involved in many different project environments, ranging from terrifying and at times exciting chaos, to clear-cut and at times restrictive order … the software development lifecycle has become second nature, yet it is important to take a step back, invent a new blog post category SDLC, and dedicate a bit of time to the topic. Over time we can even start pondering about tools and technologies, such as Team Foundation Server, that can add value to this topic.

Common Questions

The questions I have been asking for years include:

  • Why are software projects always such a challenge to:
    • manage
    • deliver on time
    • complete as per ‘original’ specification
  • Why are costs and efforts required high and why do these often increment exponentially towards the end of a project?
  • Why are our customers finding the error in the software for us?
  • Why are so many software engineers against a process framework, a SDLC and the tools that allow us to track, control and predict software ecosystems?
  • Do software engineers actually understand the value of a SDLC and what concepts such as test and build automation could do to their productivity, stress levels and home life?

I do not have all the answers as yet and probably when I think I do, the world has magically evolved again, throwing me right back where I started in the 80’s. So instead of finding all the answers, let’s focus on some of the pillars and decide for ourselves whether there is value in a software development lifecycle.

Common Activities

image

The common activities apply whether we are working on a small edition of a calculator, a huge enterprise business solution or a proof-of-concept prototype. It all starts with communication, i.e. chatting about a problem or opportunity, progresses into a planning, design if viable, construction, deployment and eventually a release and maintain era at some point in time. While the diagram shows a sequential flow, we will see in later discussions that usually the flow is iterative, or a spiral, or if all else fails a chaotic flow of events.

Without deviating from the topic, it is important to mention that Team Foundation Server (TFS) is one of the tools that allow you to manage, evolve and improve the above ecosystem.

Summary of thoughts

What is important to realize, is that a process in any software engineering project will add value, by allowing the team to track, monitor, measure, assess risk, improve quality, improve working conditions and deliverables … if and only if implemented effectively. Walking into a chaotic development environment with the comprehensive Capability Maturity Model Integration (CMMI) process model as a magic potion would probably not have any favourable results, in fact it would just make things worse.

The best process for any ecosystem is one that is accepted by and of value to all stakeholders of a software project. If the developers or testers do not believe in the process, you might as well use a big stick instead … it will not work, it will make matters worse and it will never allow the value of a suitable process or tools to unfold itself like a beautiful butterfly from an ugly looking cocoon.

Now that we need to deliver service into a recession, it may be an opportunity to look at some ways of optimizing and improving the overall quality of solutions delivered … may just make us a bit more competitive than the competitor.

What we should do is look at and in a nutshell (the details are better covered in relevant books) understand what some of the common processes are.

Next … in this series …

A look at a generic process and some of the common models.