In the following paragraphs we introduce some commonly used software engineering methodologies and assess their advantages and disadvantages. We look first at the traditional models: Code and Fix, Waterfall, V, Spiral, Staged Delivery, and Evolutionary Prototyping. Then we look at the more dynamic models: Scrum, Adaptive Software Development, the Unified Process (UP), and Extreme Programming.
A software development model should not be dumped blindly onto the project but rather should be carefully chosen according to the project, the environment, and your goals. After a certain model is chosen, it must be adapted to fit the project and organizational culture. All the models discussed here are flexible enough that you can adjust them to the environment they are used in.
Before we get to the models, we want to say a few words about a new practice called Agile software development. This approach is not a lifecycle model, as many people believe it is. Instead, it is a methodology that is put on top of the lifecycle models. Agile software development was proposed by representatives of a number of software development methods, including Extreme Programming, Scrum, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation-driven, heavyweight software development processes. The core values defined by Agile development are as follows:
These core values are used on top of a software development process to do Agile software development. For more information on Agile development see http://www.agilemanifesto.org.
2.3.1 The Code and Fix Software Development Model
This is not really a development model but nevertheless it is a very common practice in software development. Developers begin work without a set of good requirements or a vision, writing code as long as there is time and money. The release of a product depends on a miracle, as shown in Figure 2.1.
Figure 2.1. The Code and Fix Software Development Model
In the Code and Fix model, no real process is followed. The developers start hacking without a detailed idea of what the program should do and how the functionality should be implemented. If the project gets lucky and a little magic happens, the product will be released. Otherwise, the money or time runs out and the project becomes an entry in the statistics of canceled projects.
In many real-world projects, some sort of Code and Fix technique is used. Even when a process is in place or at least known, projects may resort to Code and Fix because of time pressure. It seems a waste of time to first plan the project properly in order to define requirements and design, and Code and Fix produces code fast. But that's an illusion. Even though Code and Fix might seem to produce a result faster than any other model, it is very unlikely that the result will satisfy the customers' wishes or needs. Nor will it achieve extensibility or maintainability, attributes that require a well-defined design.
This model is pure hacking or coding, and it has nothing in common with a well-structured approach that promises success. From our experience, Code and Fix works only for rapid prototyping. Do not use this model for product development.
This approach has no planning phase and therefore yields early results.
It is not predictable and therefore depends highly on the individual. High maintenance and rework effort are the result of using the Code and Fix model.
2.3.2 The Waterfall Software Development Model
The Waterfall model is considered the grandmother of all the software engineering models and is the most well known of all software engineering methodologies. The Waterfall model works well in an environment of well-understood requirements. For the model to work well, you need to make sure that you eliminate the possibility of a lot of midstream requirements changes. This avoids a common source of problems when using this development model.
The Waterfall model is a sequential, document-driven methodology. To advance from the current phase to the next phase, the project team must review and release an artifact in the form of a document. The release of the corresponding document triggers the end of one phase and the beginning of the next (see Figure 2.2).
Figure 2.2. The Waterfall Software Development Model
The Waterfall software development model uses sequential, non-overlapping phases and carries over documents from phase to phase. The project flow is as follows:
In the pure Waterfall model, the document of a given phase must be completed, reviewed, and released before the project can proceed to the next phase. It is easy to see that the process assumes that the problem, the domain, and the technologies are well understood. You must have this understanding in order to complete the planning before the implementation can start. If, during later phases, a problem is found that requires changes to previous phases, the project must roll back and correct all the affected documents before it can proceed.
The Waterfall model works well in projects that have stable requirements in a known technical domain, even with complex tasks. The Waterfall model enables planning and analysis of complex problems early in the project and therefore removes some of the risk from later phases, when it is much more expensive to fix problems. The model also works well with inexperienced or technically weak project teams because it adds a structured, well-planned approach to the project. Therefore, it minimizes unnecessary work due to inexperience or lack of technical knowledge.
On the downside the Waterfall model is sensitive to changes in phases that are already finished. It is often difficult to specify all the requirements before you do some of the design work. If it's necessary to make changes to requirements after the initial design work, the project must revisit the previous phase and adjust the work (or documentation) of that phase. These changes might trigger changes in the work that has been done in the earlier phase and consequently to its work artifact. Before the project can continue to the next phase, all the changes to all previous phases continue to be propagated upstream until they have been incorporated. It is easy to see that changes made midstream can cause massive rework.
The Sashimi model is named after the Japanese style of presenting fish in overlapping slices. This approach modifies the Waterfall by allowing for overlapping phases. The main advantage is that it reduces documentation and gives you the freedom to proceed with incomplete phases. The problem with this model is that the milestones are no longer obvious, and progress cannot be tracked as easily as with the pure Waterfall model.
Another variation, the Waterfall with Subprojects approach, allows for subprojects that can be executed independently. This lets you implement easily implemented features at an earlier stage, before the more complex and unknown features are completely planned. This approach is problematic if unforeseen dependencies are uncovered during later stages.
To reduce risk, you can modify the Waterfall model by adding a risk reduction spiral at the beginning. For example, you might define requirements and create the architectural design in a spiral development cycle and then use the Waterfall model for the remaining phases. You can extend this risk reduction to develop some high-risk subprojects in a complete Spiral model (see section 2.3.4) before committing to a full-scale project.
2.3.3 The V Software Development Model
The V model is a popular software development model for projects that have stable requirements within a known technical domain. It is an extended Waterfall model, adding more details on the validation and verification side. For each phase in development, there is an associated phase to verify and validate the result produced.
The V model is a sequential, document-driven software development model. At the end of each phase a document is produced that allows the project to proceed to the next phase.
Figure 2.3 shows the flow of the V model.
Figure 2.3. The V Software Development Model
The project runs through the following phases:
The flow through the various phases shows that the V model is derived from the Waterfall model.
The V model works well in environments of stable requirements and wellknown technical domains. The advantage of the V model is its focus on verification and validation. Each artifact on the left side of the V has a matching verification mechanism on the right side. The approach also works for larger teams.
If requirements change during the project, a lot of rework is necessary to update the relevant documents in order for the project to proceed. In many cases the documents on the left side of the V are ambiguous and therefore cannot be used directly for deriving tests. As in the Waterfall model, all the project planning must be done up front. This can be very difficult in a complex project or in unknown technical domains.
The W model adds a second V dedicated to testing, thereby adding even more focus on testing. The inserted V shows the collaboration between testing and development from the very early stages of development. So the model looks like V/, or a W, as the name suggests. For more information please refer to http://www.stickyminds.com and search for the W model.
2.3.4 The Spiral Software Development Model
The Spiral model breaks the project down into risk-oriented subprojects. At the beginning of each phase or subproject, the risk is analyzed. Then the project team first addresses the subproject that implies the highest risk, followed by the one with the second-highest risk, and so on until all the risks are addressed. Risks can include unknown technology, possible performance problems, a poorly understood architecture, and others. The Spiral model then ends in a Waterfall lifecycle model.
Figure 2.4 shows the Spiral (or cinnamon roll) model with its iterative steps. Each iteration in the model forms one circle around the origin to form a spiral after all the iterations are performed.
Figure 2.4. The Spiral Software Development Model
The Spiral model consists of the following major activities to reduce the risk in a project:
The number of iterations and the order of the six steps are suggestions that work for most projects, but the model can be tailored to the needs of the project. In practice, the Spiral lifecycle model is often used in combination with other lifecycle models to effect risk reduction in early stages of the project. After the risks are addressed, another lifecycle model, such as the Waterfall model, is then used.
The advantage of this model is the breakdown of the development into small pieces so that the areas of risk can be tackled at the beginning of the project. It seems reasonable to deal with risks first. The more effort that is spent here, the less risk will be left in the project and the less likely it is that unpleasant surprises will be found toward the end of the project. The Spiral model can be used with other models, providing risk reduction in early stages of development. If no risk is involved, the risk analysis step can be skipped.
The Spiral model is quite complex. It requires management to be knowledgeable and thoughtful. It is sometimes difficult to define the milestones to decide whether the project is ready for the next iteration (especially if development is being done in parallel iterations or cycles).
As stated earlier, the Spiral model can be combined with any other lifecycle model for risk reduction in the beginning of the project
The WinWin Spiral software development model adds three extra activities to circumvent problems observed in the "basic" Spiral model. The activities added are as follows: identify the system's or subsystem's key stakeholder, identify the stakeholder's win condition, and negotiate a win-win reconciliation of the stakeholder's win condition. For more information on the WinWin Spiral software development model, see the references section.
2.3.5 The Staged Delivery Software Development Model
Staged Delivery is a lifecycle model that provides the software in staged releases; the most important features are developed in the early deliverables. Staged Delivery shows incremental progress at each delivery to the client. This enables faster feedback from the customer on the currently implemented functionality. As a result, this model minimizes the risk of delivering a product that does not fulfill the customer's expectations. Furthermore, this model lets you incorporate changes as early as the feature is delivered to the customer. A working product can be shipped in short intervals.
Staged Delivery works well in areas of well-understood requirements, large projects, customers that want to use subsets of the features very early, and a project in which functionality can be split into subsets that can be developed independently (or at least with a sequential order).
The Staged Delivery lifecycle model is based on the Waterfall model (see Figure 2.5). It follows the Waterfall model throughout the concept, requirements, and high-level design phases. After completion of the high-level design, the Staged Delivery model proceeds through the detailed design, implementation, and testing phases in each stage. A releasable product is produced at the end of every stage.
Figure 2.5. The Staged Delivery Software Development Model
The flow through the phases is as follows:
The main benefit of the Staged Delivery model is the increased visibility it gives you of the project's progress and its support for frequent and predictable product releases. As a result, customer satisfaction increases. In addition, because the project team receives customer feedback quickly, it is easier to make customer-driven changes midstream.
If the software cannot be broken down into subsystems that can be delivered in stages, then staged delivery is not an option. Also, customers may change their minds after seeing the features implemented, and that may cause feature creep within a single stage because of changed requirements.
The Evolutionary Delivery approach is a mixture of the Evolutionary Prototyping model (discussed next) and the Staged Delivery model. Iterations are very short, and the project is released to the customer for feedback after each iteration. Depending on how many customer requests are taken into account, the development will look more like either Evolutionary Prototyping or Staged Delivery. If most of the customer feedback is implemented in the next iterations, the project cycle will look like Evolutionary Prototyping. If very few customer requests are honored, the project cycle will look like the Staged Delivery model.
2.3.6 The Evolutionary Prototyping Software Development Model
In the Evolutionary Prototyping model, you develop the system concept while moving through the project. In most projects that use Evolutionary Prototyping, the most visible aspects of the system are developed first and are shown to the customer. Based on customer feedback, the prototype is altered or extended, including requirements analysis, design, and maintenance. These incremental releases to the customer are repeated until the customer is satisfied with the solution and the project is released, or until the time and money for the project run out.
As its name suggests, in Evolutionary Prototyping (see Figure 2.6) the system starts with an initial idea or proposal, which is then prototyped and released to the customer in incremental releases based on feedback.
Figure 2.6. The Evolutionary Prototyping Software Development Model
The structured project flow looks like this:
In environments of fast-changing requirements, uncertain requirements, or lack of application knowledge by the customer and project team, or when the team is unsure of the best technical solution, Evolutionary Prototyping works very well. The obvious advantage is the visible signs of progress produced in each of the short iterations.
In the beginning of the project, it is not possible to know how many iterations it will take or how much time it will take to produce an acceptable product. With this approach, it is also possible to keep the project going until the product is released at the end of money or time.
Another drawback is that this approach is often used as an excuse for Code and Fix development. In contrast to Code and Fix, real Evolutionary Prototyping includes requirements analysis, design, and the production of maintainable code for every iteration.
Evolutionary Delivery is a mixture of Evolutionary Prototyping and Staged Delivery. It is discussed in section 2.3.5.
2.3.7 The Scrum Software Development Model
First used in 1987 by Ikujiro Nonaka and Hirotaka Takeuchi, Scrum is a highly productive software development model. Scrum is not an acronym but a term from rugby. It refers to a tight formation of forwards, who bind together in specific positions to get an out-of-play ball back into play (an action called a "scrumdown"). The Scrum software development model is an enhancement of the iterative and incremental approach of software development. Scrum implements a framework that empowers teams and strives for changes at any time in the development process. The two pillars on which Scrum is built are team empowerment and adaptability. To support the two pillars, Scrum defines a vocabulary and rules to reinforce common practices such as using small teams, enforcing a rule of not interrupting people who are working, and having a single source of work prioritization.
The goal of Scrum is to control the unpredictability and risk involved in software development. The result is the flexibility to change at any time in the process, leading to responsiveness and reliability.
The various phases defined in a Scrum project are shown in Figure 2.7.
Figure 2.7. The Scrum Software Development Model
The planning, architecture, and closure phases are linear in flow, whereas the sprints are iterative development cycles:
Develop: For all changes to the system the following tasks are performed: A work packet is opened, and the team proceeds to the domain analysis, design, implementation, testing, and documentation of the changes.
Wrap: The packets are closed, the executable version of the changes is created, and a description is provided of how backlog requirements have been implemented.
Review: The members of all teams meet to present their work and review work in progress, raising and resolving issues and problems and adding new items to the backlog. In addition, the risk is reviewed and appropriate mitigations are defined.
Adjust: All the information from the review meeting is gathered and implemented in packets.
The Scrum model is designed to respond to the unpredictability of changes in external conditions and in the development environment throughout the cycle. In addition, the methodology frees the developers to focus on project development as learning occurs and the environment changes. Object-oriented technologies provide the basis for the Scrum technology. Objects, or product features, offer a discrete and manageable environment.
Procedural code development is inappropriate for the Scrum model because of its high number of intertwined interfaces. Also, in stable environments the traditional methodologies might be more efficient.
2.3.8 The Adaptive Software Development Model
Unlike the traditional software development models, the Adaptive Software Development model takes into consideration that the system is not completely known at the start of the project and that the requirements can change rapidly. This is reflected in the three components of this model:
The Adaptive Software Development model is an iterative, risk- and mission-driven, component-based, time-boxed, and change-tolerant process.
Figure 2.8 illustrates the Adaptive Software Development model.
Figure 2.8. The Adaptive Software Development Model
The Adaptive Software Development model consists of the following activities:
The learning loop shown in Figure 2.8 is more than the kind of feedback loop found in other software development models. The learning loop in the Adaptive Software Development model answers the questions of step 4 and therefore gives vital information for the succeeding steps of the project. In addition, the released product is not necessarily the exact product that was originally speculated about but rather is the product that the customer wants or needs. This difference is crucial. Objectives, technologies, and requirements often change during the course of a project, but they are not considered because the process cannot react to changes midstream. The goal of the Adaptive Software Development model is to consider midstream changes as the natural flow of projects and to incorporate them into the development model.
The Adaptive Software Development model works very well for smaller teams (four to eight people) when the requirements technologies are uncertain or domain knowledge is missing. The model allows the team to speculate about the final product without providing a detailed plan up front. In this way, the team can continuously adjust the final product over the course of the project. The model also includes processes for tracking progress and identifying problem areas (scope, schedule, changing requirements) early on.
In areas of predictable requirements and technologies, the traditional methods will probably work more efficiently than the Adaptive model. In addition, managing an Adaptive project is very different from managing projects developed with the traditional models because the Adaptive approach is result-oriented rather than flow-oriented (like the Waterfall model).
2.3.9 The Unified Process Software Development Model
The authors of the Unified Modeling Language (UML) defined a software engineering model called the Unified Process (UP). The Unified Process is a risk- and use-driven, architecture-centric, iterative and incremental software development model. This is a mature and open model. You may be familiar with the Rational Unified Process (RUP), which is a commercial extension of the Unified Process. The Rational Unified Process is entirely compatible with the Unified Process, but the RUP is more comprehensive and detailed.
The Unified Process is built on three basic principles:
Figure 2.9 shows the Unified Process Software Development Model.
Figure 2.9. The Unified Process Software Development Model
The Unified Process defines four phases. Each phase consists of one or more iterations, and each iteration is divided into five core workflow items: requirements, analysis, design, implementation, and test. The time spent in each part of the workflow depends on the phase the project is in. For example, in the inception phase most of the time is typically spent in the requirements part. In contrast, in the implementation phase most of the time is spent in the construction workflow.
Following is a breakdown of the phases, including their definitions and focuses:
Requirements: Requirements are captured to help to scope the project.
Analysis: A business analysis is done and the risk is analyzed.
Design: The initial architectural document is developed.
Implementation: A proof of concept or technology prototype might be developed.
Test: Testing is usually not conducted because the prototypes typically are thrown away. But if the prototypes are evolved to a product, then testing might take place in this workflow.
Requirements: Requirements are refined.
Analysis: System goals are defined, and risk assessment is updated.
Design: A solid architecture is created.
Implementation: The baseline for the architecture is implemented.
Test: The new architectural baseline is reviewed and tested.
Requirements: Requirements are completed, with special attention paid to ensuring that none were missed.
Analysis: The system model is completely analyzed.
Design: The design model is completed.
Implementation: The initial product is implemented.
Test: The initial product is tested.
Requirements: Usually not applicable in this phase. Requirements that are found to have problems may be deleted from the current release and deferred to a later release.
Analysis: Usually not applicable in this phase. Problems that are found during testing may be analyzed for deferral to the next version.
Implementation: Bugs found during testing may be corrected at this stage
Design: The design may be adapted if problems are found in testing.
Test: Integration testing, system testing, and acceptance testing are performed.
The Unified Process is a mature software engineering model. It is an iterative, requirements-driven, architecture-based approach to development. At the end of each phase, a go/no-go decision point provides visibility to managers on the status of the project.
The Unified Process does not cover the entire software life cycle. For example, maintenance and support are not covered. Therefore, it can be seen as strictly a development process.
The Rational Unified Process adds three core supporting workflowsconfiguration and change management, project management, and environmentto the model. It also adds more details and supporting tools. The Enterprise Unified Process (EUP) adds an infrastructure management workflow.
2.3.10 The Extreme Programming Software Development Model
Like the Adaptive Software Development model, the Extreme Programming (XP) model is a flexible, lightweight, people- and result-oriented development process that allows for requirements changes at any time during development. Extreme Programming defines 12 core practices that are essential to the success of an XP project:
Any project using XP will use all of these 12 core practices. The practices complement each other and make Extreme Programming work.
Figure 2.10 shows the Extreme Programming software development model.
Figure 2.10. The Extreme Programming (XP) Model
For a team using all 12 core practices, the development process can be broken down into the following phases:
As you can see, communication and team effort are key focus points of Extreme Programming. An on-site customer implies a close relationship between the developers and the customer. Pair programming and the planning game help the team's internal communications.
For small project teams (up to about 12 programmers) in an environment of fast-changing or uncertain requirements, the Extreme Programming model works very well. It enables close customer interaction with short release cycles to show progress. It prioritizes tasks so that the customer's most important functionality is implemented first. The short iteration cycles enable adjustment of the release plan according to the actual progress made.
For large or distributed project teams, Extreme Programming is difficult because it depends heavily on the interaction among all participating parties. In addition, for projects with stable requirements, the traditional models work more efficiently. To achieve the best possible efficiency in Extreme Programming, even the office space should be set up to support close communication and pair programming.