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 through a journey that the software industry took over the last several years. That means you're going to hear a lot of new terms. So fasten your seat belt as you're about to get overwhelmed. Before we get into the 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 a room in the basement." And yada yada yada. And the 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 the 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 adjustments. Once that is done, the 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 it 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 come 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 are they 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 verification and they will do functional testing. And when the software is ready from the developer's 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 called a Waterfall method where you go from phase to phase to phase. Requirements, design, implementation. As the 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 years 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 years, 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 variants of Waterfall started to evolve. Like a V Model which focuses a lot on testing or Sashimi Model or RUP Model that focus 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 was evolving in the software industry called Agile. Agile is not a model, it's a mindset. There were a lot of top leaders in the 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 these Manifesto and Principles were crafted, there were models like Scrum and Kanban and XP that helped implement this mindset, that helped 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 these models 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. And so, the 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 verify whether the system is running are run. They are called the automated testing. So as soon as you commit the code, all of the tests are 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 are 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. And so, the safety net of automated testing and this automation help developers respond quickly and confidently to the changes.
