Category Archives: SCM is SDLC

What about CMM?

SCM is SDLC

At one point in my career, I thought using the Capability Maturity Model (CMM) was enough. Simply work your way up through 5 levels to reach the optimizing stage, continuously improve SCM processes, and call it good. What I have discovered is the CMM model measures one aspect of what you are doing, but not necessarily how effective you are at doing it. What if you are optimizing so slowly it will take ten-years to reach an acceptable level?

We have all seen different kinds of informal process comparisons, passionate discussions, and perhaps even formal certification programs like CMM. There is a plethora of instructions regarding software process improvement and process change skills development training out there on the internet. How many of them are structured using basic SDLC techniques? What does it look like if we start by developing a set of requirements for the business software development project, and then develop, build, test, and deploy the appropriate set of tools, systems, and process based on the requirements?

Now, don’t get me wrong here, I like CMM. Period.   CMM is a good thing and software organizations should work toward the optimization level – either formally or informally – to improve process control. What I am suggesting is a need for augmenting CMM (if you have it) with SDLC techniques. After all, if you are developing software, you are already in the middle of an SDLC for your SCM environment; perhaps just not a good one. You see, an SDLC can – and is – happening even in the midst of software organizations operating within the chaos of CMM level 1.

Every software development organization already has this internal process SDLC in place in one form or another. As is the case with many organizations I’ve been involved with, I suspect that scrutinizing the current methods used for developing SCM process – i.e. the other, internal SDLC – would be frowned upon as poor, non-repeatable, development practices. I think this because I don’t see any books or blogs written from this perspective. Please post a comment if I missed it somewhere! The notion of using SDLC in addition to working toward a higher CMM level makes sense to me. After all, it’s a process we should already know and we simply need to consider applying it in a slightly different way. You can start today, no matter what CMM level you are at, just by thinking about stakeholders and requirements up front.

These are the kind of flexible, organic solutions I like to champion. The application of known solutions for solving different types of problems. Just remember …

SCM IS SDLC

SCM IS SDLC

About This Site, SCM is SDLC

Software Configuration Management is typically considered a supporting activity of the Software Development Life Cycle; and this is by all means true.

But what would you think if I suggested that Software Configuration Management is a Software Development Life Cycle? Suppose for a moment that SCM is an SDLC.

Every software development professional knows a little something about the SDLC. The acronym brings out visions of incessantly long, drawn-out waterfall processes for some. Others simply think of this as “what we doSCM is SDLC” when developing software products. Of course, many of the new age developers use modern SDLC processes called lean or agile or SCRUM or some variant of these. Our personal views of software development processes are shaped by our education and experiences. The variety of opinions is inherently clear in the on-going discussions we have regarding the best and worst ways of doing common ordinary things like version control or bug tracking.

The SDLC not only impacts the speed with which we develop our products; it also impacts the functionality and all of the other characteristics of the products themselves. And since the main purpose for many of our products is to solve business problems, I think it’s fair to say that a variety of SDLCs are needed to satisfy the vast array of challenges ahead of us. This line of thinking might be just another way of reaching the same “no silver bullet” conclusion that Fred Brooks describes in the Mythical Man Month, but perhaps more from a customer needs perspective as opposed to reaching this conclusion from a study of development organizational structures.

The appropriate SDLC process depends on the business problem being solved by the products we are developing. Software in games is developed differently from the software in an airport control tower because the business problem is different for the two projects. All of the various SDLCs are good when implemented on the right project; and bad when used on the wrong project. It’s not the processes that are good or bad, it’s the fit that is good or bad.

So if we put two and two together, we can say that an SDLCs job is to solve a business problem by creating and implementing the right product, and since SCM problems are business problems, it stands to reason SDLCs can be used to define the SCM processes [which are nothing more than the set of SDLC processes]. You might be thinking this presents a bit of a chicken-and-egg problem because you can’t use an SDLC to create an SDLC until you first have an SDLC; but fortunately for us, that problem is gone now.

SCM IS SDLC

I’ve been working as a dedicated continuous integration engineer for over 15 years, and this is how I frame my work; as an SDLC process. Inspired early on by Martin Fowlers flagship integration book, http://martinfowler.com/articles/continuousIntegration.html, I am one of the few software engineers who stayed working in the SCM arena instead of moving off to become a software developer or QA engineer because I like it here.

This purpose of this new website is to facilitate academic style discussions regarding the use of the SDLC processes to solve the internal business problems of SCM and other SDLC processes used inside software development organizations; the utilization of SDLC to select and create SDLC.