Software process

The term Software Process means the organized use of methods for software development, with the goal of increasing the productivity and effectiveness of the production effort, while reducing the cost and increasing the quality of the product.

Process elements

A process is an organized set of activities. Each activity locally transforms input artifacts into outputs artifacts. For example, the coding activity takes a design description artifact in input, and translates it into implementation, yielding code artifacts in output. Process descriptions encapsulate knowledge and techniques describing how to build engineering artifacts, and allows this general knowledge to be reused in specific situations. For example, the design activity can be achieved with object-oriented design, or other techniques when OO is not suitable. Activities can be broken down in lower level tasks, e.g. writing design diagrams, which can also be specialized by requiring the use of the UML. Each activities and task are to be achieved by different roles, e.g. programmer, database designer, quality assurance officer, etc, who are assigned to people that demonstrate the necessary skills to fulfill these roles.

The breaking of production into process elements and sub-artifacts permits a better control over how the software is built, and in particular enable the verification of quality upon production of each artifact in the process by adding verification and validation tasks at the end of each activity in the process.

Process variability

Most processes are describing a generic set of prescriptions to be followed in the general case. Practically speaking, a process inevitably has to be tailored to the specific needs pertaining to the building of a specific artifact. For example, two different projects might require the use of different technologies for their implementation, such as a standard OO programming language versus low-level assembly language for another, requiring different techniques to be used for the design, implementation, and testing activities and tasks.

Some software processes, like the Rational Unified Process, will specify exactly the nature of the artifacts, and define in detail how each artifact is to be produced. Some other processes will define in general terms what activities are to be undertaken, merely giving guidelines rather than an exact process specification. The strict definition of the process down to the level of tasks enables a better assignment of duties by the project manager. Knowing the capacities of his project staff, and knowing from the process description what are all the tasks to be achieved in the project, the project manager can more efficiently assign duties to individuals, and generally have better predictability and control over the project planning. The use of a strictly defined process somewhat introduces overhead, and removes freedom of action in the project. So smaller and ill-defined projects require light-weight processes. On the other side, large and well-defined projects can greatly benefit from all the control points provided by a well-defined process.

In software engineering, a wide variety of processes have been defined. Each of these processes are suitable for the development of software development projects with specific characteristics. Each of these processes can be tailored to be efficiently applied to various kinds of projects. For example, a company might adopt a specific development process, and have various versions of this process tailored for specific kinds of projects. Process variability can be influenced by many factors, including:

Organization-related factors

• Technical maturity of the company and its employees.
• Software engineering disciplinary involvement of the company.
• Organizational culture of the company, etc.

Project-related factors

• Application domain.
• Size of the project.
• An important stakeholder imposing the use of its own process or process elements.
• Complexity of the project, etc.

Variability continuum

Some advocate that the software development methods and processes exist on a continuum defined in terms of "well-definedness", or "discipline", meaning that the more elaborated process are very well defined and enforce dicsipline, whether other methods at the other end of the spectrum are "sloppy" and cannot enforce discipline. The latter view misleading and wrong in some cases.

One of the main differentiation factors among processes is how they can cope with change. Some projects are more ill-defined, chaotic and genrally slippery than others. In such projects, it is hard to accurately predict future directions. In these cases, a more flexible approach is necessary.

In contrast, some other projects are very well defined and operate in a well-structured organization. Some of these projects will also necessitate extreme quality of work at all levels of development, strict division and hyper-specialization of work in order to achieve quality and productivity.

Thus, it is more appropriate to say that software development methods exist on a continuum from "adaptive" to "predictive."

Adaptive methods 

focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes with it. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.

Predictive methods 

in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.

References

• Barry Boehm, Richard Turner. Balancing Agility and Discipline: A Guide for the Perplexed, Addison Wesley Professional, 2003. 0-321-18612-5

• Stephen R. Schach. Object-oriented and classical software engineering. Fifth edition. McGraw-Hill, 2002. 0-07-112263-X

• Craig Larman, Agile and Iterative Development: A Manager's Guide, Addison Wesley Professional, 2003. 0-13-111155-8

• Gary Pollice, Liz Augustine, Chris Lowe, Jas Madhur. Software Development for Small Teams: A RUP-Centric Approach. Addison Wesley Professional, 2003. 0-321-19950-2

• Lethbridge and Laganiere. Object Oriented Software Engineering: Practical Software Development Using UML and Java, Second Edition. McGraw Hill, 2001. 0-07-710908-2