In this lesson, you're going to learn about what software development looks like.
So what you will hear or see if you're part of a software development team.
I'm also going to take you to a journey
that software industry took over last several years.
That means you're going to hear lot of new terms.
So fasten your seat belt as you're about to get overwhelmed.
Before we get into a software development process,
let's take a look at a process that you might be familiar with like building a house.
So if you were to build a house,
you will probably reach out to a builder and tell about your needs.
Like, "I need two bedrooms.
I need a bigger great-room.
I need room on the basement.
And yada yada yada."
And builders may give you some option and then you
will have to do some analysis and come back with your choice.
In the end of this phase,
you will come up with exactly what you're looking for.
Then builder is going to go back and going to create a floor plan.
And then he's going to show you the floor plan and you might make some adjustment.
Once that is done,
builder is going to create a detailed map or
a detailed plan about where the foundation is going to be,
where the electricity is going to be,
where the plugs are going to be,
where the plumbing is going to be.
And then, they're going to start building the home.
And as they are building the home,
they're going to call the inspection people to come and inspect the house.
For example, let's say the foundation is done,
they're going to get the foundation approved.
When the plumbing is done,
they're going to get the plumbing approved and so on.
And once the house is ready,
he's going to call you to say whether you like the house,
is that what you expected.
And then once you approve it,
then you're going to start staying in that house or living in that house.
And of course, there comes the maintenance of the house.
Let's see how software development is similar or different than this.
So when you're building a software,
similar to building a house,
you're looking at requirements or you're looking at what exactly you need to build.
And during that time,
you will do analysis of different options or you
might do a prototype and show it to your customer and just say,
"Is this what you're looking for?"
But at the end of this phase,
you have exactly what you're looking to build.
Then comes the architects and the software developers.
They're going to design the system,
they're going to architect the system,
and say what are the different components that they need
to build and how they're going to work together.
Once the design is done,
they're going to start coding and start doing unit testing.
So each of the sub teams are going to start building their components and test it.
Once all the components are ready,
they're going to bring all of these components together and do
integration testing or card verification and they will do functional testing.
And when the software is ready from the developer point of view,
then they're going to invite the user and they will do a testing called UAT,
User Acceptance Testing in which a user said, "Yup.
This is what I was looking for."
Or, "No. This is not what I was looking for."
And then once everything is done,
then the software goes into production which means the user is going to start using and
they might ask for some changes or you may have to fix some defects and so on.
So that's called the operation and maintenance.
So as you can see,
it's quite similar to building a house.
The model that we just reviewed is got
a waterfall method where you go from phase to phase to phase.
Requirements, design, implementation.
As industry started to use this method,
they ran into several issues.
For example, they found that it's very difficult to
predict the requirements one year or two a year
ahead as the market changes or sometimes it's just
really difficult to predict what a user will like or not like.
And since the cycle is a year or two year,
it is possible that the developers or the architects misinterpreted the requirements.
And so that misinterpretation will go undetected all the way to design,
implementation, and the verification.
And similarly, the integration issues between the different components
go undetected for a year while the software is being developed.
So as these issues were coming up,
other variant of Waterfall started to evolve.
Like V Model which focuses a lot on testing or
Sashimi Model or RUP Model that focuses a lot on overlapping different phases.
And then the Incremental Model where you do
the requirements in one shot but then you do the design,
testing, and deployment in increments.
And then there's the Spiral Model which is a very risk driven approach.
As all of these variants we're coming along,
there was another thought process that were
evolving in the software industry called Agile.
Agile is not a model, it's a mindset.
There were lot of top leaders in
software industry that were building the software very successfully.
And so they came together and said,
"What is it that we are doing that is making us successful?"
And they articulated what we call now the Agile Manifesto and Principles.
And as this Manifesto and Principles were crafted,
there were models like Scrum and Kanban and XP that helped implement this mindset,
that promote this mindset.
So you can see it's not just these three but many other models came into being.
The basic idea behind all of this model was that
instead of building this whole one year cycle,
you build in short cycles.
So you define little,
you build, you test,
and you learn, and then again,
you just keep doing this.
That way, you can adjust to the market
quickly and then you are learning from your users quickly.
And so the change became a norm because after every cycle,
you may have a change.
Software industry also has to learn how to
respond to this change quickly and confidently.
And the idea of continuous integration where a developer who is building the code,
as soon as he commits the code or as soon as he finishes the code,
it's integrated with all the other components of that software.
And then all the tests that verifies whether the system is running are run.
They are called the automated testing.
So as soon as you come into code,
all of test is tested to make sure nothing else is broken in the system.
All of this deployment is automated,
so as soon as the code is committed,
it's deployed automatically so that there is
no manual errors and as well as it reduces the effort to deploy a code.
And not only just these three,
many other practices evolved.
The safety net of automated testing and
this automation help developers respond quickly and confidently to
Praveen MittalAdjunct Professor
