SDLC

[Scott Ambler]

Tried to reply to the original SDLC discussion, but it was closed for some reason.

Anyway, at Choose the Right Software Method for the Job I overview a range of methods, including both RUP and XP, compare and contrast them, and provide URLs to main sites for more detail.

- Scott

[Ilja Preuss]

Originally posted by Scott Ambler:
Tried to reply to the original SDLC discussion, but it was closed for some reason.

I'm sorry, that was by accident...

[Andrew Moores]

Hi Scott

I enjoyed your article and will be spending some time following the links to get some more background. I have a few comments that I would like to hear your opinion on.

Code and fix is often the way maintenance programmers have to work when they have to fix something or introduce a "simple" new feature and get it into production yesterday. This works well in an unbelievable number of cases but no-one who cares about what their doing wants to work this way for long.

Taking a toolkit approach is how I like to work as well. Some clients I've had don't include use cases in their required artifacts lists, but I use them for my own benefit on the way to delivering the requirement artifact in the format required by the client.

Its strange that when we're building software we'll look to re-use code; search out design patterns and new algorithms; and pick up third party APIs to help build better software but rarely do organisations allow this approach to their development methodologies. If you�re following DSDM you can not start creating use case diagrams! But if they are useful to you at that point then why not?

I try to find the best techniques to fit the people involved as you advocate. But I'm also happy to combine things from various methodologies if they work as I need them to. One example is uses cases. Use cases are a great way to document requirements but they can be put together in a very "flexible" manner (i.e. they are difficult to structure). I find that designing the structure (i.e. the template and guidelines) of a use case based on how the stakeholders are describing the requirements to me always works best. For instance if a stakeholder can only make a requirement clear with the aid of a diagram that is peculiar to him I'll always include that in a use case. Obviously an explanation of what it means and how to read it is needed but it keeps everyone who is working from the use case in touch with the domain experts way of thinking.

An organisation needs to pick a methodology that suits a project type. But I would say they also need to be flexible and bring in elements from other methodology�s and devise their own artifacts if required. However, there are benefits to be gained from sticking to a methodology with some rigour as it can allow junior employees to be used well and if you suffer from high staff turnover (lots of contractors or off-shoring) a fixed and predictable methodology is easier to get into than a bespoke methodology.

As you say its always about finding the sweet spot. Listen to a particular methodology�s evangelists and then take the best bits back to the real world to use.

Andrew

[Stan James]

Scott maintains an uncommonly balanced point of view on a wide variety of ideas. He's a valuable calming force in this contentious area. To read many authors and discussion board posters you would not believe that any software was ever developed successfully before they made their particular contribution to the world. Alistair Cockburn is another balanced commentator. His book "Agile Software Development" is a book-length comparison of popular agile methods.

[peter wooster]

I find SDLC to be an overused and poorly defined term.

First, its acronym conflicts with a well known IBM network protocol Synchronous Data Link Control. If you look it up in google that meaning still gets top billing. Maybe this was intentional to lead all those mainframe guys astray.

Second, all software, like insects, have a life cycle. There's the egg stage where its just an idea, the larval stage where its under development, the pupal stage where its forgotten on the shelf and the adult stage where it lays an egg. Some even eats it young.

Third, the way its often described sounds like a euphemism for the old waterfall model.

So, when someone asks if I understand SDLC, I'll compare it to HDLC, frame relay and IP. And if they ask about a software development life cycle, I'll ask for clarification, do they mean waterfall, spiral, UP, RUP, or whatever the latest scheme is to convince developers that codeAndFix isn't actually the only way to go.