Software Development Lifecycle

If you want to learn about different approaches on how best to create software products, there is no shortage of reading material covering the topic.  The number of books ranges in the thousands, then add the Internet into the mix and there is more written material then any individual could ever read in their lifetime.  Just to get a taste of the variety of methods, I will refer to Wikipedia's coverage of Software Development Process

So you might surmise, all these different approaches to producing software is a good thing.  You know, lots of competition keeps prices low and is better for the consumer, right?  Wrong.  A colleague of mine once said - "Do you know why there are so many choices of any given thing?  Because none of them are really all that good". 

"OK, reading material is one thing, actual practice is another.  Surely, there is process overlap between companies creating software?"  Well, at the highest level, I would say yes.  Just about all companies implement a process that covers the basic steps outlined below.  But once you start peering beyond those basic steps there can be a lot of variance.  As a matter of fact, it's common to find high degrees of variance with respect to process adoption between different teams within the same company.  You might ask - "Well, true because many software development firms aren't operating at CMM Level 3 or higher".  That's a fair assessment, but even then there are still quite a few options.  And how can you possibly choose the most optimized approach for developing the highest quality product which totally fulfill the highest priority requirements?

Traditional Model

Iterative Model

 

The first problem to address is managing the options.  Here is a list of just some of the decisions that must be made.

  1. Which approach to take for moving through the steps.  With a traditional waterfall approach, each step is mostly completed before the next step commences.  An iterative or agile approach, breaks the requirements down into effectively small deliverable chunks which can flow entirely through a complete process cycle before another is started.  The more you read on the Internet the more you will conclude agile is the way to go.  And being somewhat biased I would tend to agree.  However, you need to be careful with large projects that have many integration points.  Also, there are a number of different ways to do agile development. 
     

  2. Deciding how to accomplish each individual step.  Take for example just the requirements phase. 
     

    Now for each step, there is the same if not more multiplicity of options.
     

  3. Company organization.  How are the various project teams comprised?  Are there separate QA, Test, Document, Development, Planning, Project Management, Support, Document, Release Management teams?  Or are some combined and which one's report to what managers?  What is the right number of people assigned to which projects?  What is the proper ratio of QA, Development, Product/Project management? Are they all located in the same facility or distributed globally?  Are parts of the projects outsourced, is it all outsourced, or is it all done in-house?
     

  4. Company culture.  What's the management style of department/division/product head?  Does everyone collectively agree on a common methodology or does each implement his or her own way of running their portion of the process.  Do the leaders call the shots or are their reports given latitude to do their own thing.  How good is the leadership?  Are your leaders delivering the proper balance of tactical and strategic initiatives?

Even with this incomplete list it doesn't take long to imagine perhaps a couple hundred ways to accomplish all the steps.  Next factor in people with varying management styles and organizational structure.  Multiply that all together and basically derive there are an infinite number of permutations to accomplish the goal of producing software.

(To be continued)