Question

How to decide software development process for developing a software, what are the key factors to be considered while deciding which development process to follow(e.g Agile,WaterFall,Spiral…).

Answer 1

There are lots of factors influencing this decision, including "technical" ones:

• what kind of project is it (e.g. in house, open source, shrink wrap, enterprise, device driver, …)
• predicted size of project (e.g. person years) and team
• predicted lifetime of project (ranging from throwaway prototype to mission critical enterprise app expected to run for the next 100 years)
• how often you can / are expected to deliver new releases

and social ones:

• are the users willing to cooperate with the team in agile style
• what is the culture, the "normal way of doing things" within the organization
• how open is management (and developers) to new ideas, can they be convinced of new approaches (with good arguments and evidence)
• is the team colocated or physically separated

Note that the latter are at least as much, if not more, important factors than the former!

Technical factors

The nature and size of your project strongly constrain how often you can publish new releases, which in turn has an effect on how agile you can be. E.g. some open source projects can be released as often as you wish, while according to Joel, shrink wrap software should not be upgraded more often than every 1,5 years.

As the size of the team grows, the communication tends to become more formal, and the team becomes less agile. Also the more critical the project, the more rigorous and formal the process tends to become.

Social factors

If your users are not willing, or can’t coopoerate directly with your team, agility is limited. If management is stuck with conventional thinking and methods, again agility is limited. Same for a physically separated team.

---

The bottom line is: you don’t need to choose a process once and for all. Also, names and fashionable acronyms are not as important as what your team is really doing day by day. You can do Waterfall or RUP in agile style, just as well as you can effectively turn XP or SCRUM into a rigid, formal process. In a good project, the process is constantly reviewed, fine-tuned and improved as the situation and the team’s needs require. Start with something which seems good enough (and as simple as can be), then do regular retrospective meetings to gather feedback about what is going well, what went wrong, and what could be improved.