FN-FORUM: RE: From SSADM to real-world product

date posted 8th February 2007 12:08

Hi Andy.

I'd go with what Gary said.

SSADM comes from the school of thought that says the software
development process can be tightly controlled and is predictable. It's
this idea that building software is like building cars on a factory
floor. This is useful for only a small number of applications where
you, and your client, knows almost exactly how the end product will
walk and talk (embedded systems, aircraft autopilot software,
heart-rate monitors... you get the idea).

For most business and end user software, this is not the case because,
like Gary said, everyone on the project learns something new as the
project progresses, and this new knowledge feeds back into
requirements and design - i.e. everyone changes their mind all the
time.

If you want to look for a methodology to work with, find something
that is the least restrictive, that embraces requirements and design
changes in the project lifetime and most importantly, that focuses on
getting the software built rather than paperwork. There isn't a
one-size-fits-all method... find one that's closest to how you work
and customise it accordingly. You can do worse than look up any of the
'Agile' approaches
(http://en.wikipedia.org/wiki/Agile_software_development)

And your methodology too will change as you use and learn more about it!

Cheers,
Farez




> Thursday 8th February 2007 10:54:51
> RE: FN-FORUM: From SSADM to real-world product - Gary Short [EMAIL REMOVED]
>
> Hello Andy,
>
> I would advocate a different methodology. I have been working as a developer and
> architect in "the enterprise" for a number of years now and would favour an
> iterative methodology over a waterfall methodology every time. There are many
> reasons for this, far too many for a posting like this, (please feel free to
> contact me off line if you would like to discuss them in more in detail) but the
> killer argument is this; no matter how much the customer thinks he knows about
> his business he will always learn something as the project progresses, i.e. he
> will go through some kind of learning curve. If you were to graph this with time
> along the X axis and knowledge along the Y axis it would appear steep at first
> and then tapering off at a point where he knows the most about the business.
>
> If you are working in a waterfall methodology, if you graph time along the X
> axis and cost of change along the Y axis you will see that the cost starts off
> low and then, as you get further along the X axis, the cost of change goes up
> steeply. Unfortunately, you will also see that the time that the customer knows
> most about the business is the same time as it costs the most to make changes,
> when using a waterfall methodology. This is why many waterfall projects run over
> time and budget.
>
> An iterative methodology prevents this by keeping the cost of change the same
> throughout the project. The American Department of Defense (once a strong
> advocate of the waterfall method) has now moved to insist on an iterative
> methodology because of this.
>
> If you would like more information, don't hesitate to contact me off line.
>
> --
> Cheers,
> Gary
> http://www.garyshort.org
>
>
> > -----Original Message-----
> > From: [EMAIL REMOVED] [EMAIL REMOVED] On Behalf Of Andrew
> > J.Baker
> > Sent: 08 February 2007 11:14
> > To: FN-FORUM / [EMAIL REMOVED]
> > Subject: FN-FORUM: From SSADM to real-world product
> >
> >
> > Morning all,
> >
> > I'm currently evaluating the viability of employing SSADM for the
> > creation of an enterprise system. I was wondering whether anyone knows
> > of any literature (on-line or print) covering acceleration from the
> > outputs of an SSADM study to development in an OOP language such as C++,
> > Java, etc.
> >
> > I'm hoping that a formal procedure exists whereby the required system
> > components highlighted through SSADM can be implemented in a high-level
> > language. Much of what I've read with respect to SSADM is a little
> > woolly with regards to the implementation phase (understandably, SSADM
> > covers design not development).
> >
> > Any ideas? Or should I consider a different methodology?
> >
> > Cheers, Andy.
> >