Choosing process model

The selection of process model for a software project is a tedious task. There are many factors affecting the optimal choice of software process framework for a process. When selecting a process model, one must carefully assess the context of the project:

• Is the project small or large in terms of effort, schedule, or business value?
  
• How much risk is involved in the project? What is the relative importance of this project in comparison to other projects, and the overall activities of the company?
  
• How much changes can be anticipated? Is it possible to come up with stable, definitive requirements for the project up-front, or do we have to work on something, and rely on customer feedback for next steps?
  
• How many people are involved in the project, both directly and indirectly? How competent are they? Are they familiar with the process we are planning to use?
  
• Is the whole team located at same room, floor, building? How are we going to communicate during the project?
  

Also, in reality, there are several constraints in selecting the process model, often leading to suboptimal process choice for a given project. Especially in larger companies, there are often only one (or at most, a couple) process framework, that must be followed in all endeavours of the organization. If you are planning to use e.g. agile practices, and the organization is not familiar with the principles, are you able to get management buy-in for your ideas?

While the evolution of software process models have historically moved from document-driven (or plan-driven), waterfallish models towards more flexible agile methods, there still is no silver bullet process framework. New process models often aim to fix the problems of earlier paradigms and models, but as with most improvements, this often leads to other challenges. There is still relatively few research on using agile practices in producing large, complex software systems. In general, agile practices shed little (if any) light into issues related to software maintenance, or software as a service. Document-driven methods are strong with requirements engineering, while e.g. Scrum hides the issue behind the concept of Product Owner, and backlog items. On the other hand, agile practices highlight the importance of team motivation and (informal) communication; an aspect document-driven models often neglect.

The selection of process model affects management of software project in several ways. The pace and contents of interaction with the customer / end-user are highly affected by the software process model in use. The roles used by software development organization should be aligned with the software process model. Even the structure of the product to be developed must match with the chosen organization and practices of the software project team.

When considering issues with software processes, it is very important to keep critical attitude, and ask questions. There still are no simple answers to difficult questions.

For those more interested in software processes, TKK provides an excellent course on the topic.