What is a software process?
Traditionally, most software development has been done in an ad-hoc manner: in a code and fix style, and without a clear and consistent set of rules to drive the development effort. The ad-hoc manner has brought about chaos in the development process, leading to many problems that plague the software industry today. There have been countless cases of software failures that have sometimes proved to be fatal - largely attributable to a chaotic style of development. Owing to the lack of a consistent process, budget overruns and schedule overruns have been the norm in many software firms.
To remedy this problem software development attempts to develop an orderly, predictable and disciplined process that has certain rules and policies. In essence, these set of rules and policies set forth and followed by a software development team can be termed: the Software Process.
Process Models: Templates for the Software Development Process
Since the early days of software development, various models have been proposed around which to build effective software processes. These process models are largely formed by putting together methods, which have been tested over time.
The process models can be broadly classified into two groups:
- Plan based
- Iterative and incremental
Plan Based Approach: What is wrong with it?
A plan based approach is founded on the premise that the software industry is similar to the manufacturing industry. In the manufacturing industry, formulating a plan, and then rigorously following through on that plan ensures a smooth manufacturing process - resulting in quality product. People are plugged into a well thought out plan, and their intrinsic capabilities, or lack thereof, have little influence on quality of product. However, the notion that the software industry is like the manufacturing industry is false. Unlike in the manufacturing industry, it takes creativity, imagination, insight, and innovation from the people involved to develop quality software. Therefore, the plan based approach that works for the manufacturing industry is unsuitable for software industry.
The Waterfall Model is a prime example of the plan based software process. Waterfall has a set of stages in its development cycle, namely – requirement identification, design, implementation, testing, and maintenance. This process is rigid in nature because there is little room for deviation from or changes to the plan. In the software development industry, making changes to fit the customer’s needs is a necessity.
Another downside to this model is that it calls for heavy documentation and lengthy meetings. Every stage in the Waterfall model is supposed to produce documentation, e.g. a SRS (System Requirements Specifications) document after the requirements identification stage, design documentation at the end of design stage, and so forth. Moreover, since the stress is on detailing elaborate plans, this plan based model necessitates long meetings. Producing heavy documentation and conducting long meetings slow down the development process by using up the resources that could otherwise be used in developing software.
A Viable Alternative – Iterative and Incremental Model
Various iterative and incremental process models have emerged as alternatives to the plan based approach. One of these processes, that is currently in vogue, is the agile process.
Agile, by definition, suggests light-weight, fast, nimble and flexible. The agile process has gained popularity in organizations – large and small – in part due to its ability to speed up development and its receptivity to change. Essentially, it is a lean methodology without the excess 'fat' of heavy documentation and lengthy meetings.
The Agile Manifesto (www.agilemanifesto.org), reproduced below, was collectively drafted and signed by the pioneers of various agile methodologies. It nicely sums up the priorities of agile process.
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Fig 1: The Agile Manifesto
As evident from the manifesto, the agile process gives more importance to people and the interactions among them.
A welcome departure from the plan based approach; agile process recognizes that people are the most important components of software development. While the plan based approach relies on the assumption that if we have a good plan and good tools, people can simply be plugged into the equation to do the work, conversely, the agile process is centered around and supports the people.
Agile clearly values working software over comprehensive documentation, another clear contrast to plan based approach. Agile also advocates minimum documentation. It is based on the idea that code should be so simple that it can substitute for documentation.
Agile is about flexibility and directly involving the customer in the development process. Rather than having working around a contract that denies the customer flexibility, agile allows collaboration with the customer.
Perhaps the most important aspect of agile is that it welcomes change at any stage of the development process.
Of course, the items on the right in the manifesto have value, but the items on the left are valued more in agile.
Agile processes have proven with time to be the best practices.
Some of the popular agile processes are:
- Extreme Programming (XP)
- Feature Driven Development (FDD)
- Adaptive Software Development (ASD)
These different processes are called various flavors of agile. Although specifics of these various flavors may differ, they share common underlying principles.
Principles of agile methodologies:
The agile process aims to satisfy the customer through the timely and continuous delivery of valuable software. This means that working software with essential features is delivered to the customer as early as possible so that customer can get value out of the software early in the development stage. In addition, allowing the customer to use the software early in development means that the customer can provide feedback for improvements to the development team.
In XP, for example, releases are planned in the order of a month or two; releases are further broken down to iterations; and requirements are expressed as user stories.
People building software with the agile process should not only be given an environment and support necessary to complete their tasks, but they should also be trusted to get the job done. For example, in XP, there is a concept called collective code ownership, by which anyone in the team can access any part of the code. This would not be possible if the team lacked trust from leaders and within itself.
In agile, working software, as opposed to documentation or other artifacts, is regarded as the primary way to measure progress.
Agile encourages sustainable development. Projects should have an indefinite constant pace. There should not be cases where sometimes you are rushed and other times you are relaxed.
Simplicity is the goal in agile. In XP, for example, constant re-factoring, in order to simplify and improve the design is recommended.
As agile promotes flexibility, agile teams can reflect on ways to become more effective, and adjust their behavior accordingly
Agile in a nutshell
Agile ensures customer satisfaction by providing working software that caters to customers’ needs. The process places more emphasis on the people involved in development, and in doing so, encourages them to harness their innovation towards building quality software