Software Development Life Cycles

krono9

Senior Member
Joined
Sep 5, 2009
Messages
916
Reaction score
16
Location
Durbanville, Cape Town
Hi, im busy with software engineering studies currently.... and they basically teach us the following software development life cycles:

1.Waterfall
2.Agile
3.Agile-Extreme Programming
3.RAD
4.Scrum
5.Prototyping
6.Boehm's Spiral Model

I wanted to know, in the real world, what are the recommended software development life cycles used for small projects and for large projects.

Thnx
 
Waterfall and Agile are methodologies. Scrum is more of a project management style which is typically used in agile projects. Prototyping is something you may possibly do in both waterfall and Agile projects at the very start of development.

I work for a bank and we use Waterfall most of the time although I personally prefer Agile. Smaller projects really don't need Waterfall
 
I have to aggree with dexster, I treat SDLC as seperate to methodologies.

We use a Agile/Scrum method. Scope session, basic outlay documented, code and release, review progress and scope meet again to either extend functionality or tackle a different aspect. More rigid methodologies work in the cases of contract or outsourced work and there it just makes plain sense. For in house development of systems that are not critical line of businesss, agile in many forms can be used. For inhouse, it really depends on the companies expected ROI what methodology you use. There is also nothing stopping you from extending a agile methodology with more rigidity for critical systems and then toneing it back down when you are in the re-evaluation phases.

It's a sad thing but most small-medium companies are far more intrested in results than developers or IT pro's maintaining documentation. Quite often I have to argue for a time out to actually produce proper documentation or revisit code and embed good comments.

I try follow OOP principles irrespective of language, with seperation between presentation - business logic and data. It's far easier these days with the newer object persistence frameworks becoming mainstream ( Entity, nHibernate, Gentle to name a few for the .net stack ).
 
Also never be afraid to change, adapt or try new things. I'm focusing very heavily on BI at the mo, from basic tables and data to data marts, cubes and transforms and then allowing that to be used by intelligant tools.

My sympathy for the poor soul who has to examine some of my db store procs and views :p
 
IMO principles (like SOLID) are more important than methodologies. As a developer you'll generally not have control about what methodology you have to follow, but principles are something you can always follow and will always be applicable.
 
It really depends on the client, for instance in government they usually dont know what they want never mind how to put requirements together so if you try a waterfall approach your in for a tough time.

But some pvt companies we have done projects for really knew what they wanted and how they wanted it and it was all well documented so there was minimum scope changes and the waterfall approach worked well.

EDIT: We mostly do large projects that take 2-3 years.
 
Last edited:
Top
Sign up to the MyBroadband newsletter
X