Recommended SDLC Steps for small companies

Dear all,

Thanks in advance.

I am working for a small concern (we have <10 employees). In SDLC (Software development Life Cycle) there are so many steps to follow. It may be suitable for corporate companies and it is difficult that what we will follow all from that list. Especially there are so many diagrams (Process flow diagram, UML, DFD, SFD, etc.).

Suggest us what are compulsory for small companies like us.

Note: We are in the growing stage now and soon we will expand our company by adding more staffs.

TalktoPriest

Not sure but I think this might have been discussed before. Have you tried searching the forum? The steps involved would most likely be the same no matter the size of the company. Not sure if this would help?

There is no right answer to theis except: it depends.

First of all, what documentation is compulsory? OK, that one's easy. Whatever documents the customer demands. If the customer doesn't demand it then it's not compulsory and you don't have to produce it.

There's a follow on question to that though: what documentation is useful? The answer to that one is: whatever you find to be useful. Try creating and filing some of the documents that are suggested out there. Revisit your filing in 6 months time and see which files have got dust on. Basically, if you find you're not going back to a particular type of document then you're not using it and that's probably because it's not useful... so stop producing it.

In my experience (which has mainly been small to medium business apps but some of them have been pretty extensive) almost all documentation is a burden that far outweighs it's benefit. I therefore tend to keep it to an absolute minimum.

The two documents I do find useful are a user requiremenets specification and a user acceptance, both of which require signing off by the customer. The reason these are useful is that they represent your contract with the customer - you want to be able to prove what you agreed to do.

Actually the other type of document that I've found very useful is a gaant chart. They're almost never used by most companies I've worked for but I find them really useful to let me know where I'm at and keep me focused on the goal. They also help me identify if I'm slipping early and let me take corrective steps - which may include telling the customer I'll be late and manage their expectations. You do have to manage it constantly though. It's not a static document and you should be checking and updating it weekly if not daily. Don't use MS project for this - it's rubbish. I personally think that post it notes on a wall can't be beaten (though they do tend to get start falling off in month 2 and need replacing).

As for which methodologies you should use, again, it depends. I had a manager once who formulated that decision quite well. He identified two axes along which you should judge your project: Risk and Familiarity. A project is high risk if getting it wrong or delivering it late would have major cost implications. A project is familiar if we know the problem space well, e.g. we've delivered similar projects many times before. Note, complexity and scale are not an axis.

High risk projects tend to benefit from heavy, structured methodlogies like waterfalls and prince because they identify key milestones and testable deliverables up front. That makes the project easier to plan and makes it easier to spot drift early.

Unfamiliar projects tend to benefit from lighter, more reactive aproaches like agile because these allow you to explore the problem space with your customer. They assume that you're not going to make all the right decisions up front and make changing those decisions later more simple.

So that gives you 4 breeds of project:-
1. Low Risk, High Familiarity: Who cares what methodology you pick. This is going to be a breeze so go with your current favourite. Maybe use it as an excuse to try out some new methodology you haven't tried before.
2. High risk, High Familiarity: Go with a heavy methodlogy. Waterfall it with hard milestones and get all documentation formally signed and agreed at each stage.
3. Low Risk, Low Familiarity: Keep it light and reactive. Agile methodlogies are perfect. Meet with your suatomer regularly and keep them involved so you can learn about the problem together.
4. High Risk, Low Familiarity: OK, first of all, why did you take on this contract you scheister? You're clearly not the right man for the job. But since you have, I'd recommend a light stage up front where you use some agile type methodlogies to do some early prototyping and learn about the problem space. Your goal is to turn it into a High Risk High Familiarity project. Once you've done that you can then take a heavy formal aproach.

I really liked that formulation. It's not precise and there'll always be shades of grey but it provides a pretty good indication of what you should be doing... and it gives the lie to the many software houses I come across who dogmatically stuck to waterfall methodlogies all the way through the 90's and then wondered why half their projects failed. Those same companies are now dogmatically sticking to Agile and, if I'm any judge, will soon be wondering why half their projects failed.

Dear All,

Thanks for you reply.

and FunkyDexter thanks for the big reply and it must be useful for me.

TalktoPriest