How is the software development cycle followed the companies?

Hi Brijesh,

There is no single design pattern that you can consider the best. best design comes by combining various design pattern to give meaningfull solution, and as far as development cycle is concerned it is decided based on wants of your product and client the project that I am working on follows Agile development strategy.

Brijesh, after you question I went over couple of forums and from one of them as an answer to one of the questions this is what I found:-

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.