My company does not follow any well defined process for software development. I want to implement a simple but effective process which will suit my company.
We have all sets of resources right from project managers to developers and testers.
Please provide some references or process templates that I can use.
You are really not describing the characteristics of your company or the main challenges you are facing, so it's hard to give good advice. You could try something like scrum if you want something lightweight, which is probably a good idea if you have little or no existing process.
The process selected will vary heavily depending on what sort of software you're developing. The nature of the process needed for game development is vastly different to the nature of the process needed to develop embedded software for pacemakers.
What sort of software are we talking about?
cheers,
Rob
If you are using C++ and thinking about including a coding standard in your process, you might be interested in this thread:
http://stackoverflow.com/questions/242728/most-crucial-elements-in-a-light-weight-c-coding-standard
Jim Highsmith's book, Agile Software Development Ecosystems, provides a good overview of the main agile software development methods. I'd suggest checking it out of the library or buying a copy to get a feel for the different possibilities and see which (if any) fit your company and products best. Other processes that you may want to look at include the IBM Rational Unified Process (there is an agile version of this as well) and the Team Software Process.
The pushback you are going to get from your people is that every project requires a slightly different process (depending on the size, complexity, and parameters of the project).
What I would do is make a process for the biggest project you expect to perform, and then build a check-list from it. When you are about to start a new project, take out the check list and make informed decisions about each piece in the project and decide whether you need to use that part of the proces (e.g., you may not need to have stress testing for a 3 user app, but a web portal - think youTube you would).
As others suggested without more information about your company, project and domain it is hard to give valuable recommendation. When you have no defined process about any defined process would do better.
My advice would be to start with something small rather than full-blown deployment of any given methodology. Find something that causes most pain for you and your colleagues; understand why it is painful and define a procedure that will avoid this pitfall. Try to have everyone's buy-in into this by explaining the value of following a procedure. When the team is comfortable using this procedure find next problem and do the same.
I'm not sure if you already have this, but if you don't, single most important thing that you can do would be deployment of issue tracking tool like JIRA or Trac and start tracking what are the issues discovered by testers or reported by users and how they are resolved.
We are into customized software development also having a couple of products like a payroll application, mutual funds and ecommerce. The technology we use is .net 2.0 with sql 2005.
Before adding templates and processes, I think you need to 'reflect' on the issues you are encountering, review the many available base project management/software development processes and determine which would suit your group the best, how they will be implemented and over what time frame, how to provide training, etc.
It's anything else, resist the urge to change until you know the why, how, when what and who - and make sure you have a way to track progress and success...otherwise you won't know if you achieved what you were going after
Process is also a governance issue. Adopting a governance structure that doesn't have management participation is an exercise in futility. (Pointy hair boss says, "We start writing code today! We deploy on Friday! You're clever use cases won't tell me how to run my shop!") Also, scale is important. Many processes are ways to have someone check on someone checking on someone to make sure they did their job right. If you are on a team of one, then this amounts to you checking your own work. It is also rare case where someone other than the developer cares about process. Federal SDLC, CMMI, are examples of huge processes that assume dozens of people passionately care about process, an often unmet assumption.