Software Development Lifecycle - which one do you choose, and why?

Having spend most of this afternoon racking my brains for some sort of holy grail of software development lifecycle that will ensure success in every possible scenario… I quickly remembered my Software Design lecturer words…

"If you can read, understand and interpret the ISO 12207 (International Standard of Software Lifecycle Processes) document then you are well on your way to being as confused about things as everyone else seems to be"

The document, unless you want to read all 18 pages of it, is basically an overview of what needs to happen in a Software Development Lifecycle… My favourite quote from it is:

"The standard is flexible and usable with: any life cycle model (such as, Waterfall, incremental, evolutionary, Spiral, or other); any software engineering method (object-oriented design, structured coding, top-down testing, or other); or any programming language (Ada, assembly, machine, or other). These are very much dependent upon the software project and state-of-the-technology, and their selection is left to the user of the standard."

Okay, so the joke is on me.. the document doesn’t really give me anything that I didn’t already know… As a software team leader or software project manager it is down to you to make the difficult decision as to which approach to adopt.

Right, so I reckon you can decide based on:

  1. Software Engineering Method (OO, Structured etc.)
  2. State-of-the-technology used on the project (e.g. workflow technologies, AJAX, C++)
  3. Past experience
  4. Company ethos
  5. Delivery timescale

1 and 2 are basically driven by your user and system requirements… as you can’t build what you want in any way you like, you need to pick a selection of technologies that can deliver your project in the required timescale… well, I guess you could do it any way you liked if it was a student project, or you had a ridiculously big budget, or if it was part of the project to work out the most effective solution in every conceivable technology.

3 only applies if you’ve ‘been there and got the T-shirt’… It wont give you much if all your projects have been run in the same way, as you don’t have the visibility of other methodologies… so more than likely you’ll adapt your current way of thinking and tweak it to improve efficiency. This is not necessarily a bad thing.

4 is more down to the organisation you work in… are there rigid corporate standards to adhere to? … do you have to talk to twenty people to get a slight change to policy approved? Can you really decide how you wish to develop your product? If you can… then if it all goes well, a hero you will become… I hate to think about the price of failure when a new development strategy is adopted.

5 is really important, and I think it is not really considered in enough detail… so you want to adopt a certain development strategy… how does this impact your development team, and more importantly your stakeholders… does your customer insist that you follow a certain strategy? are you tied down to a contract that means you cannot perform a true iterative approach?

Hmm… so all I’ve done so far is to help stir up the murky waters a little more.

Is change for the point of change a bad thing?

The development strategies (that for the purposes of this argument are the ones under consideration)

  1. Waterfall, and for those in a comedy mood: waterfall 2006 conference :-D
  2. Agile (e.g. Scrum, Lean etc.) … I’m also going to group iterative or incremental development into this category
  3. Automated Software Synthesis - you need ACM access to read the full article, but you can search for free results :-)

The waterfall model has many critics… many of the criticisms are valid, however don’t be too quick to ignore that it has to offer, if you know what you are building, and the requirements are 90% stable, then it might be exactly what you are looking for. In terms of fixed price contracts, I think that the waterfall model has a great deal to offer, the future can be planned, and progress can be measured in deliverables rather than other intangible means

Agile development is (IMHO) the new word for a structured, defined and industry standard of iterative or incremental software development. To be honest with you, if it wasn’t for the reading of Andrew Woodward’s blog, I wouldn’t have had the foggiest idea about what it could offer. I also cast eye over Hillel Glazer’s Agile CMMi blog… since my organisation is a CMMi level 3 operation now :-). Where to begin with Agile… well it is a daunting task for any PM for Software Team Lead to take in all the information I’ve just been though… and getting your development team to adopt a new way of thinking will just as daunting as the learning.

"Although there are some evidences that CMMI and Agile can coexist, the overall impression of people dealing with process improvement is that there are still important cultural differences between the two communities" - from CMMI: Less Hyped Than Agile but Equally Popular on devagile.com

Oh boy have you got an uphill battle if you, like me, are in a CMMi ordained organisation… or perhaps not, it depends on how you approach the change.

Automated Software Synthesis is something I had never considered until I utilised K2 [blackpearl] and K2 [blackpoint]. Essentially your design when using those particular technologies is a high level business process that you wish to implement. You can’t really go about doing a detailed UML model of how each of the classes in the system will work - because it engineers itself through the tools provided, be it K2 Studio or Visual Studio. Yes you can write your own code, but it forms a small part of your development if you can utilise the technology to your advantage. You still need to gather requirements though… which is really important! Other such examples include rapid application development tools that can write your code based on a detailed design… I’ve got no experience of these.

I’m still none the wiser, and the deadline looms in the distance… and upper management are after those darn estimates.

…. SpittingCAML




You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

6 Responses to “Software Development Lifecycle - which one do you choose, and why?”

  1. Chris Geier Says:

    Great write up. Thanks! let me know if you ever want to publish anything on K2underground

  2. SpittingCAML Says:

    Thanks Chris, glad it meant something to someone :-). I will let you know about publishing - I’m very keen to do that once we’ve got a handle on the RTM version of BlackPoint.

  3. David Longstreet Says:

    Nice post, you may find my new online book and companion videos intersting. The name of the book is Reboot! Rethinking and Restarting Software Development. It is free and can be found online at http://www.RebootRethink.Com

    David Longstreet
    Reboot!

  4. Richard Harbridge Says:

    Another really interesting article. It looks like I will have to read most of these at this rate.

    I am curious to know if you have ever read the Mythical Man Month. Pretty much ‘the book’ for software development, planning and management. Even though it’s considerably old it still has many if not all of the same lessons/concepts we employ in todays world.

    I have been lucky enough to have managed a couple different development teams and I have to say in all honesty the team or people you have working for you (if under 20 developers) almost have more impact on the way you structure your lifecycle model than the industry standards. You use the skill and abilities of your staff fully and so for me personally I have had to take a pretty flexible approach.

    In fact depending on the ability of supporting groups such as QA, Business Analysts, Consultants and Designers the entire process for managing the development lifecycle might need to change. In my opinion it’s an evolving and constantly changing thing. However it never hurts to understand all the processes and tools available to help us manage those people.

    I think I rambled and digressed a bit there, but wanted to add my two cents.

    I would love to hear how implementation of the model you select goes. :)

  5. SpittingCAML Says:

    Richard, I’m very pleased you’ve taken the time to respond in so much detail!

    Yes - I do own a copy of the mythical man month, a book that’s been sat on my bookshelf since my University days. I’ve discounted it too frequently for being ‘old’. Perhaps I will skim through it once again to refresh the basics.

    I must admit, I do agree with your comment about making sure the lifecycle you choose properly engages your team. I think in the past we’ve had lifecycles dictated on us, that enforce a rigidity that compromises creative thinking, both in terms of management and implementation.

    I will get back to you on the decision we take, as you’ll no doubt experienced yourself, once you open the can of worms, it is very difficult to get the blighters back in the can! The worms are definitely missing, and much discussion and debate will now commence. Ah the life of a large corporation :-)

  6. SpittingCAML » Delivery of an important project, thanks to some clever shortcuts Says:

    [...] of you who have read my blog before will remember my ramblings about which software development methodology should you choose. We chose to use OpenUP, which is the open source version of the Rational Unified Process. I was a [...]

Leave a Reply