Large software projects will never be without some risk, but if risks can be brought down to acceptable levels, that will be a good beginning. | ||
| --Capers Jones, 1998 | ||
The process of understanding the project and its goals, building it, and delivering it to users is often referred to as the Software Development Life Cycle (SDLC). Such a process sounds straightforward, but this is not the case, as more than 50% of all development projects fail. The project is canceled before the product is completed, the product is never used after it is deployed, or the end result fails to provide the outcomes that were expected. Presented in this topic are several fundamental concepts and pragmatic techniques that you can use to increase the probability that your project will be successful.
The development life cycle is composed of four phases: planning, analysis, design, and implementation. Although the focus and approach to each may differ among projects, all projects have elements of these four phases. Each phase is composed of a series of steps, which produce deliverables that provide understanding about the project. The development life cycle is a process of iterative refinement, where each phase takes in a deliverable from the previous phase, and further outlines in more detail how the product will be built, eventually leading to a finished product. Each phase generally proceeds in a logical path from start to finish, though some project teams move through the steps consecutively, iteratively, or incrementally.
There are many more variations of the development life cycle than what is being described throughout this chapter, though the rudiments behind each phase remain the same.
In many ways, the development life cycle is similar to building a house. First, the original idea for the house is presented. Second, this idea is transformed into a simple drawing that is refined over several iterations until the customer agrees that the drawing depicts what he or she wants. Third, a set of blueprints is created that presents extensive detail about the house, including power outlets, support beams, and door arches. Finally, the house is built following the blueprints, often with changes made by the customer as the house is being constructed.
It is important to mention that the length of and approach to each phase of the software development life cycle is dependent on the methodology used. This chapter covers only the waterfall approach, although there are roughly six other methodologies that are used in software development. There is no right approach; each methodology has a purpose and a place. The waterfall approach is covered in this chapter because it is the easiest and shortest to cover. Other methodologies, like the Rational Unified Process (RUP), are more complex and detailed.
The first phase of the development life cycle is the fundamental process of understanding why a product should be built, and determining how the project team will go about building it. It is in this stage that the value to the developers is identified, and technical, economic, and organizational feasibility are determined. This is known as a feasibility analysis.
A feasibility analysis evaluates if the final outcome of the project will lower costs or increase profit, and whether or not there are enough organizational and technical resources to build it. The level of risk is also assessed, contributing to the final decision about whether or not the project is a worthwhile investment. Are the developers familiar with the application and technology utilized? Less familiarity generates more risk because now the developers have to conduct additional research to build the final product and support it. How large is the project? Larger projects also generate more risk, due to the extensive scope that must be managed through development. What will be the development and operating costs? Do the costs of managing this project outweigh the benefits of the expected outcome? All of these factors must be addressed before development can continue to the next phase.
If the project is evaluated and developers are given the go-ahead, the resultant deliverable of this phase is a project plan that describes how the project team will go about developing the product. The project plan is composed of a technical brief, business rules, development requirements, milestones, deliverables, budget, and quality assurance procedures. This deliverable is given to the development team for design and implementation.
The second phase of the development life cycle answers the questions of what the product will do, who will use the product, and when and where the product will be used. During this phase, the project team develops a concept for the new product. If a product already exists, then the project team identifies areas to improve on the existing design.
The project team sets out on an information-gathering process, where the main users of the product are interviewed or fill out a questionnaire. The analysis of this information, in conjunction with input from the project sponsor and project team managers, leads to a concept for the new product. The product concept is then used as a guide to produce a set of business analysis models that identifies how the product will be used within the company.
The analysis, product concept, and models are combined into a deliverable called the product proposal, which contains a high-level initial design.
After the strategic decisions have been made in the previous two phases, the design phase determines how the product will operate in terms of hardware, software, and network infrastructure. Several specifications are created that detail the various components of the product.
The first step in the design phase is to develop the design strategy specification. This specification describes whether the product will be developed by programmers employed by the company, whether the product will be outsourced to another firm (usually a consulting firm), or whether the company will buy an existing software package. This leads to the architecture specification, which describes the hardware, software, and network infrastructure that will be used.
After the architecture specification is completed, the project team develops the interface specification, which specifies how the users will interact with the system (e.g. navigation methods such as menus, buttons, or command line input). Next, the database and file specifications are developed, which define exactly what data will be stored, including where it will be stored. Finally, the analysis team develops the program specification, which defines the programs that need to be written and exactly what each program will do.
All these specifications form the system specification deliverable that is handed to the programming team for implementation.
This is the phase where the product is actually built. Notably, this phase gets the most attention because it is the longest and most expensive part of the development process.
The first step in the implementation phase is construction, during which the product is built and then tested to ensure that it performs the way it was designed. Testing and quality assurance are the most critical steps in this phase, because the cost of bugs can be immense. The majority of companies spend more time on quality assurance than on the actual development of the product.
Once the product has passed acceptance, it is ready to be installed. If an existing product was in place before this new one, both products move through conversion. This is a process by which the old product is deactivated, and the new product is activated.
The conversion process may be a direct cut-over approach (in which the new product immediately replaces the old product), a phased approach (in which the new product is installed in one division of the company as a trial before installing it in the other divisions of the company), or a parallel approach (in which both the old and new products are operated for a couple months until the support team is sure there are no bugs in the new product).
One of the most critical aspects of the conversion process is the creation of a training plan to instruct users on how to operate the new product, and help manage the changes caused by the new product.
Once the product has been deployed and tested, the project team establishes a support and maintenance plan for the new product. This plan usually includes a post-implementation review, as well as a method to identify the changes needed for the product. Optionally included are retirement plans for the product, generally affected by changing technology and business rules.
The development methodology described in this topic is commonly known as the Waterfall approach. This model is one of the oldest versions of the software development life cycle. The Waterfall model is linear and sequential, and once a stage has been completed, there is no turning back.
Imagine a waterfall rushing over a rocky cliff. Once the water has flowed over the cliff, it cannot turn back. This is the same idea behind waterfall development. Once a phase transitions into another, there is no turning back.
Waterfall development is advantageous in that it allows for managerial control. A schedule is set with deadlines for each development stage, and the product can proceed through the development process and be delivered on time, in theory. Each phase of development transitions into the next phase in strict linear order, without any overlapping or iterative steps.
The disadvantage to the waterfall development model is that it does not allow for reflection or revision. Once an application is in the testing phase, it is very difficult to modify something that was not explored in the concept state.
There are a number of popular software development methodologies, and each model works best for different types of companies. Other development methodologies include SCRUMAgile, iteration and increment, eXtreme programming (XP), feature-driven development, Rational Unified Process (RUP), and Microsoft Solutions Framework (MSF).
Development of a game itself generally utilizes the SCRUMAgile approach, whereas tools development typically follows either the waterfall approach or a custom model when there are only a handful of developers working on it.
The best development methodology to use depends on your company and project.