hi,

Im just doing an assignment on System Life cycles models.

I've decided to compare the Waterfall and Evolutionary model.

As a Programmer / Analyst what makes you choose one model over another?

thanks for any advice or information or diagrams

Cheers

Si

 

Unisys use the "V" diagram, which is a sort of mix of the waterfall / evolutionary mix. Waterfall, but with another side that goes up

 

Yeah ive got that actually are a variant of the waterfall!



ive got these as the main process's
1. Requirements Analysis
2. Software Specification
3. Software Design
4. Implementation
5. Testing
6. Quality Assurance
7. Documentation
8. Acceptance Test and Delivery
9. Maintenance and Evolution
10. Throw it Away

Si

 

Add "Requirements Capture" to you list as it is somewhat important.

Apart from that, we do not bother formally drawing diagrams or even verbalising the method we will use.

We basically write a list of the tasks (like you have) and put some estimated man-hour timings against each with some slack for back-tracking. Job done We did have some formal methodology thrust upon us, but we told the management where to stick it.

Cheers

Ian

 

i want to keep the list sequential so where would that go?

Could you give me a bit of general info about that process

Done this so far
1. Requirements Analysis

This is where the user/customer actually stages what they are after in there system. The requirements are very often written in non-computing terms. Here all the constraints and goals are established.

The following stage is were the Systems Analyst turns this document into the specification

2. Software Specification

The software specification is what the actual building of the software relates to. The specification tells the programmer what exactly is needed in computer related terminology. This document must be agreed upon by both customer and the developer. Work cannot progress until both sides agree on this.


2500 words need 800 so far

Si

[Edited by super_si - 9/24/2002 10:32:20 AM]

 

Si, Whats wrong with you I actually understand what your on about!

David

 

i cheat now i use word

unfortunately I need to be serious for once so I don’t mess up anymore

[Edited by super_si - 9/24/2002 10:43:17 AM]

 

Lol.... good idea

 

Si,

Aha the good old uni theory and ideals on software development.

Well fact is in the *real* world you have to do what is commerically viable and they ain't the same!

Ok methodolgies you'll probably find a hybrid used by alot of people. I use elements of full project life cycle (High and Low level design documentation) coupled with RAD (check out www.dsdm.org.uk i.e. iterative prototyping)

If you are doing work off your own back then you must get a spec. signed off so you can get paid and there is no dispute over deliverables! Also means that you start the design with database schema and if you want to avoid *major* headaches this design must be set in stone.

These days dev. tools let you rapidly design screens (and hash things up!) don't skimp on the testing phase of the dev. cycle this should normally be 30% of actual project length but normally gets shorten when timescales get tight - which won't happen if you've done your design and got sign off from day one.

So there you go, In the real world it's what works best, at uni it's errr....ummmm.....o we have time to potter around and do whatever cos it don't matter...a f**king joke if you ask me but thats just my two cents!

Gary

 

lol cheers gary

ive got these percentages


10% Req. + spec
10% Design
10% Implement
20% testing
50% Evolution + Maintenance
Si

 

Si,
See modifications and enhancements (IMHO) wouldn't form part of the initial effort and more importantly from a commercial viewpoint they would be separate charges. I normally do something like:

10% High and Low Level Design
10% Database Design
50% Design and Build
25% Testing (Volume and Stress)
5% User Acceptance Testing

But everyone has their own way of doing things.

Gary

 

the URL doesnt work either Gary.

Good old Sommerville Engineering book

 

As a developer in a commercial environment, the choice is always evolutionary - we call it 'iterative'. However, this is usually as a result of insufficient specs and business models on the first cycle, meaning that it's only when the users see the 'first cut' that they actually realise what they want or don't want. By the 2nd or 3rd iteration/evolution of the software they've narrowed it down to something close to what they're trying to achieve, and on the 4th or 5th iteration they usually realise that actually something else would be much cooler. A quick re-design later and they're happy, and we can actually start rigorous testing.

Waterfall? Wassat?

 

Si,

When I say "requirements capture", I mean actually go out and capture what they actually want. This is subtley different from your definition of "requirements analysis" where the customer tells you what he wants, but as he isn't a programmer will miss stuff out etc.

I actively go out and talk to the customer(s) and use RAD tools to demonstrate interfaces/mock-ups. This way, this step of "requirements" is a single pass stage. I.e. spec gets set in stone which avoids feature creep.

Cheers

Ian

 

Try reading some of these they outline the differences between waterfall and the iterative development model.

 

Si,

oops sorry it's www.dsdm.org but hey you could have worked that out couldn't you? Its good for a methodology (because for once its practical!) and there's just the bare bones.

Gary

 

cheers lads, gary site hasnt worked again. ive reset my connection and ill try it again

was the connection

SI

[Edited by super_si - 9/24/2002 2:44:58 PM]