Waterfall Model

This is one of the sequential activity centered models. All of the software development activities are performed in sequence and there is no iteration. All requirements for one activity are completed and reviewed before the next activity starts. The goal is to never turn back once an activity is completed.

This model is quite easy to understand by each of the parties involved in the process.

However, due to its sequential nature, this model is not capable of dealing with iterations and evolutions. It can't deal with changes and problems that arise during one of the activities since it does not consider a second iteration in one stage. Furthermore, tests aren't mapped to the corresponding activity. Once a phase has been considered complete the results are not going to be changed and are used as input for the next phase. Most of the time, this is too rigid.

Once a project is cancelled, no prototypes or solutions are present that could be reused since the whole development process has to be aborted once a problem is found that had to be dealt with in an activity before the problem arose. The whole development process is lost and no money can be made out of single components or modules that were already developed.

The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

Spiral Model

This is one of the activity based iterative models. It deals with iterations and changes in activities. All of the waterfall's activities are extended into a cycle. Each cycle consists of four phases. In the first phase determination of objectives, alternatives and constraints happens. Alternatives are evaluated as well as risks being identified and resolved in the second phase. In the third phase the development and verification of the current cycle happens. The last phase is used to plan the next cycle. For each cycle the distance from the center measures its proximity to the final product and cost whereas its angular coordinates show the overall progress.

An advantage of this model is its ability to connect objectives to product developments. Risks management is also considered as well as iterations of tasks. It actually combines both development and evolutionary approaches. But the most important advantage is that there are prototypes even if the whole project has to be cancelled.

Nevertheless, it's quite hard to apply in real world scenarios. This model demands many activities in each cycle and requires quite some knowledge in risk management to consider all of the necessary circumstances. Changes in between the cycles are possible but not within one cycle.

Agile Model

Most people have heard of this already as it's been relatively new and most controversially discussed. However, it might also be the one closest to real life scenarios.

There are only four activities: coding, testing, designing and communicating. All of these activities are performed by each of the programmers involved in the project. No documentation is produced as the code represents all design decisions and thus all the knowledge. Pair programming is one of the key concepts in AGILE: two programmers sit in front of the screen and share both knowledge and decisions. While one of them is writing code the other one is keeping an eye on design errors or implementation errors. This way small parts of the system are developed, errors are supposed to be small and there is another person at hand who knows how to move on when one gets ill. The customer is always ready to hand, so that if requirements problems or other problems arise there's always someone to ask.

Together with the manager the customer divides the program into sub-projects that can be dealt with in a certain amount of time (normally one week). This way the customer has the possibility to control the development, costs and can change requirements in between each of the phases. By letting the customer write acceptance tests first, the programmers understand what their goal is, what their program is supposed to do. But the programmers write tests, too, to see if smaller components of the system act the way they're supposed to. After each week the programmers and the manager meet in order to discuss the status and the achievements of the developers. In those meetings the other members are only supposed to listen. After those meetings the members could discuss certain things or have a look at the code.

One of the main advantages is that the customer is involved during the whole development process. And by dividing the project into smaller projects the customer is even able to redefine goals in between the phases. The programmers concentrate on programming and deal with what they're supposed to deal with most of the time: the code. Repeated and also regression tests are used to guarantee quality code.

The drawbacks are obvious: as all of the programmers are dealing with the complete code and all of them are responsible for the whole code, it's hard to catch up at large projects. Empirical studies have shown that AGILE only scales up to 10 programmers. Everything above that creates an immense amount of work for each of the developers.

SDLC Models Summary

As mentioned before: there is neither a worst nor best model. And there is also no generally good or bad approach to managing software development. Each model has its own advantages and disadvantages. And each model is meant to deal with (sometimes only slightly) different aspects than the other. Which of these models should be applied to a certain problem depends on the number of persons involved, the complexity of the software to be developed and the goals and even more aspects. The above introduction might already help evaluating the correct choices for each case. Most of the time the model is chosen indirectly by the way the software is supposed to be delivered and developed. If you really have the chance to choose a model for a future project, it might be best to not only think about the software lifecycle at hand but also about the tools, frameworks, and knowledge in need to support this kind of development.

Project Lifecycle

Like organic entities, projects have lifecycles. From a slow beginning they progress to a buildup of size, then peak, begin a decline & finally must be terminated. Also, like other organic entities, they resist termination!

A project starts with the customer’s need to improve, solve or fix a problem he faces in his domain. The idea or the need develops throughout the different project’s phases, known as the project lifecycle, till the project’s delivery.

 

Note: It is assumed that your project has already been selected, and that a Project Charter has been produced. A Project Charter is generally a document that provides a short description of the project and designates the Project Manager. Sometimes a commercial contract also leads to the initiation of project especially in firms specialized in providing professional/consulting services.

Project Initiation

During the initiating process, you will refine the project goals, review the expectations of all stakeholders, and determine assumptions and risks in the project. You will also start project team selection -- if the project team has been imposed, then you need to familiarize yourself with their skill set and understand their roles in the project. At the end of this phase you will produce a Statement of Work (SOW), which is a document that provides a description of the services or products that need to be produced by the project.

Project Planning

During the planning process, you will detail the project in terms of its outcome, team members’ roles and responsibilities, schedules, resources, scope and costs. At the end of this phase, you will produce a project management plan, which is a document that details how your project will be executed, monitored and controlled, and closed. Such a document also contains a refined project scope, and is used as the project baseline.

Project Execution

During the executing process, you apply your project management plan. In other words you direct your team so that it performs the work to produce the deliverables as detailed in the plan. The executing process also involves implementing approved changes and corrective actions.

Project Closure

During the closing process, you formally accept the deliverables and shut down the project or its phases. You will also review the project and its results with your team and other stakeholders of the project. At the end of the project you will produce a formal project closure document, and a project evaluation report.

Monitoring & Controlling

During the monitoring & controlling process, you supervise project activities to ensure that they do not deviate from the initial plan and scope. When this happens, you will use a change control procedure to approve and reject change requests, and update the project plan/scope accordingly. The monitoring & controlling phase also involves getting approval and signoff for project deliverables.