Commonly Used Software Development Models

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:

• Individuals and interactions are more important than processes and tools.
• Working software is more important than comprehensive documentation.
• Customer collaboration is more important than contract negotiation.
• Responding to change is more important than following a plan.

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

Characteristics

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

Definition

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.

Pro

This approach has no planning phase and therefore yields early results.

Cons

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

Characteristics

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.

Definition

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:

1. Concept phase: In this first step the business goals and constraints of the project are discussed, and the initial effort estimate is provided. The phase ends with the release of the concept document.
2. Requirements phase: After the concept document is reviewed and agreed upon, the requirements are engineered. The project team must completely understand the system, technologies, and constraints at this point in order to define a complete set of requirements for the system. The transition to the next phase occurs after the requirements document is approved.
3. High-level design phase: In this phase the system's overall architectural design is developed, and the functional modules are identified. At the end of this phase, the high-level design document is the milestone necessary to proceed to the detailed design phase.
4. Detailed design phase: After the functional modules are identified, the detailed design of these modules is worked out. At the end of this phase the detailed design document is released, providing the base for the implementation by the developers in the next phase.
5. Code implementation phase: The system is implemented according to the system documents produced in earlier stages. In many projects, unit testing is also part of this phase. At the end of the phase the code is implemented and is unit-tested as proof of the (correct) implementation.
6. Test phase: After implementation and unit testing of the code, the integration and acceptance testing takes place to verify that the system works as described and agreed upon. The test documentation and the passed test records are the final documents that are released before the product is shipped to the customer.

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.

Pros

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.

Cons

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.

Variations

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

Characteristics

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.

Definition

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:

1. Requirements phase: The customer, in cooperation with the project team, usually engineers the requirements. At the end of the phase an approved requirements specification is released with an initial effort estimate.
2. Architectural design phase: The project team breaks the requirements down into functional pieces, defines how the different pieces of the system work together, and updates the effort estimate. The functional specification document is approved before the team moves on to the detailed design phase.
3. Detailed design phase: The team decides on the detailed design of the functional items. The end of this phase is marked by the release of the design specification.
4. Implementation: The code is implemented according to the specification.
5. Unit test phase: Unit tests are written and executed to verify that the design works as described in the design specification. For the project to move to integration test, the unit test records must show that all test cases passed.
6. Integration test phase: The integration tests verify that the software behaves as described in the functional specification. Integration records are produced for the test runs.
7. System test phase: The system tests validate that the system meets the requirements in the requirements specification. The passed system test records indicate that the system is ready for release.

The flow through the various phases shows that the V model is derived from the Waterfall model.

Pros

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.

Cons

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.

Variations

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

Characteristics

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.

Definition

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:

1. Determine goals, alternatives, and constraints: In the first step of the iteration, you elaborate the goals for the product.
2. Evaluate alternatives: In this step you evaluate the alternatives collected in step 1. Typically you use a prototype implementation to determine the best possible solution or, in the worst case, to determine that the project is infeasible.
3. Identify and mitigate risks: After assessing the alternatives, you identify possible risks and mitigations. Identifying risks can turn out to be difficult in some cases. The risks to consider include technological risks, process risks, requirements changes, people risks (key people could leave), and safety issues (for example, in the medical domain patients could be at risk if images are displayed wrong and, because of that, the diagnosis is wrong). It is important to evaluate the input from all participating parties.
4. Develop the deliverables for the current iteration and verify that they are correct: This step is the implementation and verification of the artifacts for the current iteration.
5. Plan for the next iteration: After you have verified the currently implemented artifacts, you must plan the next iteration (if any). You should document possible improvements and evaluate known bugs (to fix them either in the current or in a later iteration).
6. Decide and commit on the next iteration(s): The last step of the current iteration (or the first step of the next iteration) is to decide and commit on the next iteration. You determine which new features will be implemented and which bugs will be fixed in the next iteration. (The latter point assumes that software is never perfect and there are known bugs at this point. But even if there are no known bugs, there will surely be bug reports or requests for different behavior in implemented functionality). If another iteration is decided upon, the next iteration starts again at step 1.

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.

Pros

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.

Cons

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).

Variations

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

Characteristics

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).

Definition

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:

1. Concept phase: In this first step of the Waterfall model, the business goals and constraints of the project are discussed, and the initial effort estimate is provided. The phase ends with the release of the concept document.
2. Requirements phase: After the concept document is reviewed and agreed upon, the requirements are engineered. The project team must completely understand the system, technologies, and constraints at this point in order to define a complete set of requirements for the system. The transition to the next phase occurs after the requirements document is approved.
3. High-level design phase: In this phase the system's overall architectural design is developed, and the functional modules are identified. At the end of this phase, the high-level design document is released and the process moves to the low-level design phase.
4. Staged delivery phases: After the high-level design phase for the overall system is completed, n numbers of deliveries follow. Each delivery includes low-level design, implementation, debug, test, and delivery of a subset of functionality (see also the Waterfall model, steps 4 to 6). The number of staged delivery phases will depend on the point at which the customer is satisfied with the project and doesn't need any more improvements or the system is completed according to the specification.

Pros

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.

Cons

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.

Variations

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

Characteristics

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.

Definition

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:

1. Concept phase: The starting point is an initial concept or project proposal. This document may comprise the business goals for the project or the idea for an innovative new product.
2. Requirements phase: Based on the initial idea, the requirements are gathered for a prototype of the current iteration.
3. Design phase: The requirements are broken down into functional pieces, which drive the design of the system in the current iteration.
4. Implementation phaseprototype release: The system is implemented based on the specified design. The prototype is then released to the customer for review.
5. Customer review and feedback: The customer reviews the prototype and provides feedback on changes and new features to be built in the next iteration as requirements. Or the prototype is accepted and becomes the final released product.

Pros

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.

Cons

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.

Variations

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.

Definition

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:

1. Planning phase: The new release definition is created based on the current known backlog of uncompleted tasks. In addition, a cost and schedule estimate is developed. If a new system is planned, then both conceptualization and analysis are done. For existing systems, this phase consists of limited analysis of the new functionality.
2. Architecture/high-level design phase: The architectural design, modifications, and high-level design of new or additional features are defined.
3. Sprints: These are the iterative cycles of software development. To proceed to the closure phase, management determines when the time, competition, quality, or functionality goals have been met and the iterations are complete. This approach is also known as concurrent engineering. A sprint is usually defined for one- to four-week periods of development; the interval time depends on complexity, risk, and the degree of oversight desired. The risk is assessed continuously, with risk controls and mitigations defined. One or more development teams work on one or more sprints at the same time. Each sprint consists of the following activities:

   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.

4. Closure phase: If the management team feels that the variables of time, competition, requirements, cost, and quality support release of the product, the release is declared closed and the closure phase is entered. The main focus of this phase is to prepare the product for general release. This includes tasks such as integration, system test, user documentation, and preparation of training and marketing materials.

Pros

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.

Cons

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.

Variations

None.

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:

1. Speculate: This is the planning activity, when the goal or vision is defined (in traditional models this is the requirements engineering component). The word "planning" is avoided because the model anticipates that the goal will change during the course of development. This means that the product that was originally planned for might be different from the end solution. But the product that will be developed is what the customer really wants. This is in contrast to what often happens: The product meets the requirements but is not what the customer wants and needs.
2. Collaborate: This is defined as active communication between all parties involved. Open and active communication is identified as the base of success for the project.
3. Learn: This component involves evaluating the products of short iterations and learning from mistakes. Implementing ideas for improvement is a key practice in Adaptive Software Development.

The Adaptive Software Development model is an iterative, risk- and mission-driven, component-based, time-boxed, and change-tolerant process.

Definition

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:

1. The project initiation phase: The executive sponsor gathers information on the intent of the project, a firm idea of its scope, the intended schedule, and a projected resource utilization plan. For the customer, the project initiation phase constitutes a cost and benefit analysis and identification of the needed business functionality. The developer obtains information about the product to be developed as well as business information showing the intent behind the project.
2. The adaptive cycle planning phase: The first step in the cycle planning is to determine the project time-box. This is followed by the determination of the optimal number of cycles, including their time frames. For each cycle, a statement of objectives is written. In addition, the primary components, technologies, and support components are assigned to the cycles. The final step is to develop a project task list.
3. Concurrent component engineering phase: In this phase, the components are engineered and implemented. To speed development time and to produce more features in one cycle, more than one component can be developed in parallel.
4. Cycle review phase: The review at the end of a cycle should answer the following questions: Is the project on track (schedule, scope, defect level, resources)? Are the project artifacts still valid? Does each delivered component comply with the quality standards, technical specifications, and customer expectations? Has the work been done efficiently and effectively? All that information is used to make sure that the software delivered is actually the software the customer wants. The result of the review is fed into the learning loop to be used in improving and adapting the forthcoming cycles.
5. Final QA and release: After the final cycle is finished, a final quality audit is performed to make sure all the goals of the project have been achieved before the product is released to the customer.

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.

Pros

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.

Cons

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).

Variations

None.

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.

Definition

The Unified Process is built on three basic principles:

• Use cases and risk identification plus mitigation
• Architectural design
• Iterative and incremental development

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:

1. Inception phase: The goal of the inception phase is to get the project started. Tasks include conducting a feasibility study, creating a business case, capturing requirements, and identifying risks. The focus in each of the five core workflow items is as follows:

   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.

2. Elaboration phase: In the elaboration phase the architectural baseline is created, the risk assessment is refined, quality attributes are defined, use cases are captured for 80 percent of the functional requirements, a detailed construction plan is defined, and a project plan (including cost, resources, time, equipment, and staff) is formulated. The tasks to be accomplished in the five core workflows for this phase are as follows:

   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.

3. Construction phase: The construction phase focuses on the completion of the requirements, analysis, and design. In addition, the implementation is finished without compromising the design. The goal is to avoid "quick fixes" that often occur under time pressure and corrupt the design, resulting in low quality and high maintenance costs.

   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.

4. Transition phase: The transition phase starts after the initial product testing has been performed and the system has been finally deployed. The goal is to release the product to the customer. All problems found in testing are fixed or deferred to the next version, and the product is prepared for rollout.

   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.

Pros

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.

Cons

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.

Variations

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:

• Test-driven development: Development depends heavily on tests. This can go as far as the test being written before the code to be tested is implemented.
• Planning game: Planning is done at the team level to ensure buy-in by the developers, as well as accurate estimates and simple, maintainable solutions.
• On-site customer: Requirements are written by the customer in the form of user stories. Thus, it is important to have a customer on site to quickly resolve questions that arise during development.
• Pair programming: Two people program together to ensure quality, code review, and mentoring.
• Continuous integration: Code modules are integrated into the project continuously to avoid a "big bang" at the end of the project.
• Refactoring: This practice keeps the code maintainable and the design as simple as possible.
• Small releases: Release cycles are usually two weeks.
• Simple design: The software is not overengineered; the simplest effective solution is implemented, and overhead is avoided.
• System metaphor: An explanation is developed of how the software will work.
• Collective code ownership: Everyone should know every part of the project.
• Coding conventions: Compliance with coding guidelines is important to keep the code easy to read and consistent.
• Sustainable pace: Developers work 40-hour weeks with overtime only if necessary. The project should not turn into a death march and burn people out.

Any project using XP will use all of these 12 core practices. The practices complement each other and make Extreme Programming work.

Definition

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:

1. Customer input, architectural spike (a spike is an experiment that can be done by a single developer): In the beginning of the project, the requirements are established with so-called user stories. User stories are basically descriptions of the features the customer wants in the customer's language. In addition to the user stories, a system metaphor is defined to explain in plain language how the overall system works. Defining a metaphor can be seen as the vision statement for the project.
2. Release planning phase: The developers review the user stories and estimate the difficulty of implementing the features. The customer then prioritizes the requested features and lays out an initial project plan. The initial release plan will not be accurate, but it is good enough to get started. Later in the project the team will revise the project plan using the knowledge gained through experience in several iterations.
3. Iteration: Each iteration starts with the planning of the current iteration. An iteration usually lasts no more than two weeks, and at the end useful, running software is delivered to the customer. The customer presents the features desired for the next iteration. The programmers break the user stories down into tasks and estimate the work necessary to implement them based on the work accomplished in earlier iterations. The iteration plan then drives the development. If there are unfinished tasks at the end of the iteration, they are fed into the iteration planning for the next iteration. From development, new user stories may evolve, and information on the project velocity is extracted to feed into the iteration planning of later iterations.
4. Acceptance test phase: The customer tests the functionality of the current iteration. The functionality then is either approved for release or is rescheduled for changes or fixes in later iterations.
5. Small releases: The release cycle for small releases is about two weeks.

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.

Pros

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.

Cons

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.

Variations:

None.