Posted on

Advantages and Disadvantages of Waterfall

We’ll take a look at a number of pros and cons of the Waterfall model. But before we do, I first want to cover some of the main high-level advantages and disadvantages to this development process.
The first advantage is that by splitting your project deliveries into different stages, it is easier to maintain control over the development process. This makes it much easier for schedules to be planned out in advance, making the project manager’s life much easier. It’s for this reason I’ve found that experienced project managers tend to favor the Waterfall process. By splitting a project down into the various phases of the Waterfall process, you can easily
departmentalize the delivery of your project, meaning that you can assign different roles to different departments and give them a clear list of deliverables and time scales. If any of these departments can’t deliver on time for various reasons, it’s easier for a project manager to adjust the overall plan.

Unfortunately, in reality I’ve seen a plan adjusted where the implementation phase gets squeezed more and more, which means the development team has less time to deliver a working solution. Shortcuts tend to be taken, and the quality can suffer as a result. It’s normally code-base unit integration testing that gets affected first. The testing teams in the test phase get a solution that contains more problems, which makes their lives very hard. So while
departmentalization is seen as an advantage, it can easily become a disadvantage if another team is late delivering their part of the project.

Now, let’s take a look at some of the high-level disadvantages. The Waterfall model doesn’t allow any time for reflection or revision to a design. Once the requirements are signed off on, they’re not supposed to change. This should mean that the development team has a fixed design that they’re going to work towards. In reality, this does not happen, and changes in requirements can often result in chaos as the design documents need updating and re-signing off on by stakeholders.

By the time the development team starts its work, team members are pretty much expected to get it right the first time, and they’re not allowed much time to pause for flaws and reflection on the code that they have implemented. By the time you get to the point where you think a change of technical direction is required, it’s normally too late to do anything about it unless you want to affect the delivery dates. This can be quite de-motivating for a development team, as they have to proceed with technical implementations that are full of compromises and technical
debts. Once a product has entered the testing stage, change is virtually impossible—whether to the overall design or the actual implementation.

Now we’ve seen some of the high-level advantages and disadvantages. Let’s take a deeper look at more of the benefits of the Waterfall model. Waterfall is a simple process to understand, and on paper it looks like a good idea for running a project. Waterfall is also easier to manage for a project manager, as everything is delivered in stages that can be scheduled and planned in advance. Phases are completed one at a time, where the output from one phase is fed into the input of the next phase. Waterfall generally works well for smaller projects where the risk of changing requirements and scope is lower. Each stage in Waterfall is very clearly defined. This makes it easier to assign clear roles to teams and departments who have to feed into the project. Because each stage is clearly defined, it makes a milestone set up by the project manager easier to understand. If you’re working on a stage like Requirements

Analysis, you should clearly understand what you need to deliver to the next phase, and by when.
Under Waterfall, the process and results of each stage are well documented. Each stage has clear deliverables that are documented and approved by key project stakeholders. And finally, tasks in a Waterfall project are easy to arrange and plan for a project manager. The Waterfall model fits very neatly into a Gantt chart, so a project manager is generally happiest when they can plan everything out and view a project timeline in an application like Microsoft Project.

The biggest disadvantage of the Waterfall model is you don’t get any working software until late in the process. This means that your end users don’t get to see their vision come to life until it’s too late to change anything. It can be very hard for non-technical people to be really clear about how they want an application to operate, and it isn’t normally until they can visualize an application that they can really give good feedback. You can mitigate this a bit by doing some prototyping in the system design phase to help users visualize their system, but there is nothing like giving them actual working code to try out.

The Waterfall model can introduce a high level of risk and uncertainty for anything but a small project. Just because a set of requirements and a design has been approved does not mean that the requirements won’t change. Waterfall is all about getting the requirements, design, and implementation right the first time. This is a grand idea, but in the real world it is very rarely the case, and this is a big risk to a project. We have talked about how Waterfall is better for small projects, but it is possible to have a small, but very complex project. The more complexity that is involved, the more likely it is that change will be needed further down the line. Complexity in the system is also very hard to implement and test, and can often cause delays in the later stages of the Waterfall software development lifecycle.
If you’re working on a project where change is expected, then Waterfall is not the right model for you. I’ve worked on projects for a financial services company where changes in the law were causing compliance regulations to change.

Unfortunately, these rules are very open to interpretation, which meant the legal team was involved at a very early stage. This meant that the interpretation changed a few times during the course of the project. If this had been a
Waterfall project, we would have been in big trouble, as projects normally come with very hard
and fixed set of deadlines.

This project was a perfect fit for an Agile project. If you are working on a large project and the scope changes, the impact can be so expensive and costly that the original business benefit for the project can evaporate, and then the project is cancelled. I’ve seen this happen a couple of times, and it’s a real shame, as projects that show promise are stopped due to restrictions in the process.

Finally, the integration and delivery of a project is done as a “big bang” on a Waterfall project. This means you’re introducing huge amounts of change all at once. This can very easily overwhelm testing teams and your operational teams.

Posted on

Waterfall software development process

Brief History of Waterfall software development process

The Waterfall software development process was introduced by computer scientist Winston Royce in 1970. Royce first wrote about Waterfall in an article called, Managing the Development of Large Software Systems. Although Royce didn’t directly refer to his model as Waterfall, the article was actually about a process that was flawed for software development. Royce’s model allowed for more repetition between stages of the model, which Waterfall doesn’t allow you to do.
Royce’s actual model was more iterative in how it worked and allowed more room to maneuver between stages. We will discuss a more iterative way of working when we discuss Agile later on in the blog. Although Royce didn’t refer to his model as the Waterfall model directly, he is credited with the first description of what we refer to as the Waterfall model.
Royce’s original article consists of the following stages, which we’ll go into more detail on in a moment. Those stages are:
 Requirements Specification
 Detail Design
 Construction, where developers start crafting code
 Integration, where all the code is brought together and compiled into a run-able solution
 Testing and Debugging, where your testing will try to find defects that the developers
will fix
 Installation, where you deploy your system so that it can be used by your end users.
 Maintenance, where you fix any issues that are raised by the users.

How waterfall Process Works

The Waterfall process is split into separate stages, where the outcome of one stage is the input for the next stage. In the first stage, Requirements Specification, all possible requirements for the system to be developed are captured and documented in a requirement specification document. This document normally requires sign-off by key project and business stakeholders.
This part of the Waterfall model is typically organized by the business analysts, but depending on the size of your project, team, or organization, other members of your development team may be involved. This stage is about teasing out the requirements of the system from your stakeholders. This would include the required functionality, documentation of business rules and processes, and capturing any regulatory and compliance requirements that will affect the overall system


The next stage is System Design. The requirement specifications from the first stage are inspected, and the system design is put together. This design helps in specifying the system design requirements, and also helps with designing the overall system’s architecture. It is this stage where architects, solution designers, and developers will work together to decide how the overall system will be constructed. This is from a code perspective, and also a technology
choice and infrastructure perspective.

The next phase is Implementation. This is the phase where the developers take the design and start producing code to turn the design into a reality. The developers may also write automated unit and integration tests at this stage.
After the Implementation phase, we have the Integration and Testing phase. This is where all the deliverables from the implementation phase are brought together and tested as a whole.
The testing team should be working to a defined test plan. Once the system has been tested and signed off by the test team, the next stage is deploying the solution to your end users. Your end users may be internal customers within your organization, or customers.

Once the solution has been deployed, it goes into the Maintenance phase, where any issues that are reported will need fixing and re-deploying. This would generally be in the form of release patch fixes to your system. You may also perform small enhancements to the system at this phase. If an enhancement is quite large in scope, then you might start the Waterfall process again and start capturing further requirements.
All of these phases are cascaded, where progress is seen as flowing steadily downwards like a waterfall. The next phase is started only after a pre-defined set of goals are achieved from the previous phase. In this model, the phases do not overlap.

Posted on

History of Statistical Learning

Though the term statistical learning is fairly new, many of the concepts that underlie the field were developed long ago. At the beginning of the nineteenth century, Legendre and Gauss published papers on the method
of least squares, which implemented the earliest form of what is now known as linear regression. The approach was first successfully applied to problems in astronomy.

Linear regression is used for predicting quantitative values, such as an individual’s salary. In order to predict qualitative values, such as whether a patient survives or dies, or whether the stock market increases
or decreases, Fisher proposed linear discriminant analysis in 1936. In the 1940s, various authors put forth an alternative approach, logistic regression.

In the early 1970s, Nelder and Wedderburn coined the term generalized linear models for an entire class of statistical learning methods that include both linear and logistic regression as special cases.
By the end of the 1970s, many more techniques for learning from data were available. However, they were almost exclusively linear methods, because fitting non-linear relationships was computationally infeasible at the
time. By the 1980s, computing technology had finally improved sufficiently that non-linear methods were no longer computationally prohibitive. In mid 1980s Breiman, Friedman, Olshen and Stone introduced classification and
regression trees, and were among the first to demonstrate the power of a detailed practical implementation of a method, including cross-validation for model selection. Hastie and Tibshirani coined the term generalized additive
models in 1986 for a class of non-linear extensions to generalized linear models, and also provided a practical software implementation.
Since that time, inspired by the advent of machine learning and other disciplines, statistical learning has emerged as a new subfield in statistics, focused on supervised and unsupervised modeling and prediction. In recent
years, progress in statistical learning has been marked by the increasing availability of powerful and relatively user-friendly software, such as the popular and freely available R system. This has the potential to continue
the transformation of the field from a set of techniques used and developed by statisticians and computer scientists to an essential toolkit for a much broader community

Posted on

What is object-oriented programming?

Object-oriented programming (OOP) is a type of computer programming in which the codes declare both, the data type of a data structure, and also the types of functions that can be operated on thevdata structure.
In this way, the data structure can be used as an object with both data and functions as its properties. In addition, developers can establish connections between two different objects. For example, one object can inherit all the properties of another object and yet have its own different roperties which makes it unique.

Examples of OOP implementations are:

CSE205 Object Oriented Programming And Data Structures Homework 3

CSE205 Object Oriented Programming And Data Structures Programming Project 4 Solved


More Object Oriented programming implementions can be found on my store