Papers

• Software Development Processes Contrasted
• Drip..Drip..Drip

Introduction

This paper presents the reader with background on the different software development processes. The comparison of the different processes should help a software manager to wisely chose a process – or combination of processes – that will allow him to successfully deliver his products.

The process of developing software has changed many times over the years, usually for the best. The question of how successful a process is often depends on how committed a company is to follow the process. Sometimes implementations are best led by consultants that have extensive experience with a methodology, and who will mentor company employees to continue the process.

The basic software development phases are:

• Requirements analysis
• High-level design
• Detailed-level design
• Coding
• Unit testing
• Integration testing
• Acceptance testing, and delivery

While the phases remain constants, the timing and utilization of a particular phase will change depending on the process.

Waterfall Process

Traditional “old school” development utilizes the waterfall process. This process requires that each phase be completed before the next one is started. This concept came out of the manufacturing world where products are built in strict sequential order – each assembly step completed before the next one is started. In software, the requirements and design are fully documented before proceeding to coding so the implementation is fairly straightforward. The reality of software development for a project of any size, is that the requirements and design are never cast in concrete before implementation begins, leading to project delays and cost overruns.

This process also adapted the idea of putting in a lengthy design phase prior to coding. Since studies had shown that the earlier a bug is found in the development process, the less it costs to fix, putting a majority of the schedule time into design should reduce the rate of bugs introduced into the product.

The weakest part of this process is the integration phase where the individual components interact for the first time and flaws in the design are exposed. The first crash of the software usually occurs at this point. Depending on the severity of the crash it could be a simple fix to get the software to run again. Or if the problem turns out to be one in which an improper assumption was made about the requirements or the design, a considerable amount of time could be spent fixing the problem.

Another disadvantage of the waterfall process is that it assumes a stable set of requirements. All planning is based around this assumption.

Iterative Development

Iterative development takes a different approach. Basic design requirements are captured and an initial version of the product is generated. Multiple iterations are created with each one adding new functionality. When designing the software the idea is to look to the creation of components. By incorporating a design-by-contract approach for interfacing components, the interfaces will be defined and the software built with the interfaces in place and working. Incomplete components will still satisfy the contracts by stubbing out the necessary data. Each subsequent prototype adds more functionality.

Ultimately there is a prototype that fullfils all the requirements. Since each iteration is an incremental increase in functionality, if changes or additions to requirements occur, they can be more easily managed. Continuous integration and test is also a part of the iterative method; by eliminating a separate integration phase, there are no surprises when all of the components have been completed and assembled. Iterative development serves as the foundation for other software development methodologies such as the Rational Unified Process (RUP), Extreme Programming (XP), and Agile software development (these are discussed below).

Some disadvantages attributed to iterative development are:

• Not enough design is done up front
• It is difficult to estimate by cost or schedule since all of the requirements have not yet been fully captured
• It is unknown what the final delivery date will be

A perceived disadvantage is that the continuous testing can contribute to cost. However, one has to wonder if this is really a problem when you consider that the increased testing should result in a better product.

Rational Unified Process (RUP)

This process builds upon the foundation of iterative development described above. RUP was was created by Rational Software which was later acquired by IBM. Rational provided modeling and design tools to be used with its process. It is a heavyweight iterative process that produces many artifacts with an emphasis on modeling documentation.

There are four phases in RUP:

• Inception where an initial evaluation of the project is done
• Elaboration which defines the high level use cases and where the initial iteration planning is laid out
• Construction where functionality is implemented
• Transition where the project moves from development to production

During inception phase the scope of the project will be determined, the high level use cases will be created, a basic risk assessment will be done, and a project plan will be generated.

The elaboration phase is where the problem domain is analyzed. More detailed use cases will be completed and a basic architecture will be drawn up. The project plan will be revised and the iterations and criteria for each will be written up.

The construction phase is where the main development takes place.

Requirements analysis, design, implementation, and testing are done within each iteration. As the iterations progress less and less of the requirements and design work is needed.

Six best practices are defined for RUP:

• Develop iteratively
• Manage requirements
• Use components
• Model visually (emphasis on Unified Modeling Language)
• Verify quality
• Control change

Because of the heavyweight nature of RUP and the expense of the tools, RUP is most widely used in large corporations.

Extreme Programming (XP)

XP builds upon the foundations of iterative development and brings with it the concepts of pair programming, short development cycles, code refactoring, simple designs, and test first development.

Pair programming is a style that requires active communication between two developers. It is not one person typing while the other person watches. The pair simultaneously analyzes and develops the code. One person may be more senior than the other, presenting a mentoring situation. Pair programming allows for real-time code review. Studies have shown that with two people working together on code, there are fewer bugs and quicker turnaround. It should be noted that it does take the right personalities to work together, and some people are not comfortable working so closely with someone else.

With short development cycles the idea is to have each cycle last only as long as necessary to add in agreed upon features. A cycle may be one month, 2 months or longer, but should never go as long as six months. If it goes too long, the cycle should be broken down to add fewer features per release.

XP keeps designs simple. This allows for clearer communication and rapid response. A simple design has fewer pieces to go wrong. The code shouldn't be burdened with “what if” code – code that is intended to only be executed in certain conditions – ones that may never occur.

Refactoring takes place when it appears that the code could be made simpler by such things as eliminating duplicate code.

All feature code should have tests written for the parts of the code that might be susceptible to bugs, e.g., user interface code. This leads to a test suite that can be automated and run over and over again as more code is added. Straightforward design simplifies testing.

XP calls for integration testing to be done every few hours or at the end of the day. Integration should be done with one set of changes at a time.

One of the biggest factors in XP is the role the customer plays in the development process. This allows for constant feedback and improvement prior to delivery. Requirements may change frequently because of this feedback, and the changes can be incorporated more quickly.

Another idea that XP introduced was that of the 40-hour week. Traditional software development often requires overtime in order to meet release schedules. However, studies have shown that excessive overtime results in lower productivity. It also shows that the project is in trouble.

Agile Development

Agile software development was a natural successor to XP. It formally came about in 2001 with the writing of the “Agile Manifesto” which defined Agile development and the Agile principles. The goal behind this movement was to deliver software faster and be more customer-oriented. Agile methodologies came to include Scrum, XP, and feature driven development.

Some of the key principles of Agile Development include:

• Active user involvement
• Team empowered to make decisions
• Develop several incremental releases
• Complete each feature before moving to the next
• Testing throughout the project lifecycle

Agile methods are geared toward adapting to changing requirements, short release cycles, continuous testing (both unit and integration), and being customer-focused. Agile releases are also timeboxed – that is the iterations are based on a fixed period of time, which is normally 30 days.

One very important aspect of Agile development is that it strongly recommends that team members be co-located. Co-location helps to reduce communication issues because the team is together and they typically sit in an open environment.

Agile Development is gaining in popularity, but still has some trouble gaining a foothold on large projects, or being integrated with existing company standards.

Comparison of Development Processes

The waterfall process is a predictive type. The overall time period for the project is divided to give so much to requirements analysis, so much to design, so much to implementation, so much to integration, and so much to delivery.

The iterative process is called adaptive because it is more readily able to handle changes in the environment, particularly in requirements. The waterfall process requires stable requirements.

The waterfall process produces more deliverables such as documentation for requirements, design, and traceability matrices. The Agile methods are more focused on delivering a working product as quickly as possible in conjunction with input and reviews from the customer.

Barry Boehm and Richard Turner have suggested that Agile development requires fewer developers and they tend to be more senior. Waterfall-type processes have larger teams with more junior staff.

The biggest difference waterfall and iterative methods is that the waterfall process is driven by contractual requirements versus being customer-driven with the iterative methods. Though not all iterative methods are equally customer-oriented, use cases and user stories are generated with customer input.

Conclusion

The general bent of this paper has been to show that iterative processes are more adaptable to changing requirements (which happens on every software project), can deliver working code sooner, and has fewer delivery problems due to continuous integration during development. Even with compliance-heavy, mission-critical software, iterative methods can work due to the frequent testing that demonstrates required features.

Regardless of the method used to develop software, the success of the project ultimately rests on the ability of the organization to commit resource to the chosen method. An organization may say that it is using iterative methods but still demand a large upfront design phase with limited or no customer input. Team members must understand the process, while must manage expectations. Iterative development allows for input from both sides and delivers a robust product that meets the client's needs.