In this video we're going to talk about Sashimi Model. So, in Sashimi Model the idea is that we allow to overlap the different phases of software development lifecycle. For example, while you're working on the requirements, instead of waiting for the requirement phase to complete, you will start with your design while the requirements are being created. And so basically, we'll just say well the requirements are not done, how can I start with design? Well, when you're doing requirements, you build the requirements for part of the application and when those requirements are ready, the architects or the designers they can actually start working on the requirements that are already created. So that's how you can overlap different phases of the Sashimi Model. And so similarly, if the part of the application is design, you can start the implementation phase and so on. And so the primary idea behind this phase is that the next phase doesn't have to wait for the previous phase to start, right? You don't have to wait for the previous phase to finish for you to start your existing phase. Now, you can overlap in this model, you can overlap your phase so much so that sometimes you can have even more than one phase be overlapping. So in this case, at this point where the red line is showing, we have requirements going on, we have the design going on, we have the implementation going on, and we also have some testing going on. And so again, it depends on what works for the team but you can have less overlap or more overlap. So in terms of where does it stand in the predictive and the adaptive scale, I would say it's not 100% predictive because based on, while you're working on the requirements and if you started designing and if you learn something, you can still fix your requirements. So, there is a scope of adaptability as you're working in it. So, it's a little bit going towards adaptive, but still it's primarily a predictive model. In terms of pros and cons, this model can be really useful if you want to shorten your development time, because you're overlapping these layers, or these phases. And so I was just kind of showing it symbolically here, that a 12 months project could be done in 9 months, if you overlap some of these layers. And then another benefit of this approach is that people with different skills can start working on the project without waiting for the work done for the previous phase, which required a different scale. In this case, the architect can start working on the project before even the analyst or who are doing the requirements are done. And then, another side benefit of this model is that you can sometimes do a learning spike early. So the line that I was showing, you have all your architects ready, available, not ready, they are available, you're developers are ready. So if you want to do a small spike to learn about something specific during the requirement phase, you can create a small, something that you build and test it out during the requirement phase, so it can help you do some spikes during the requirement phase. In terms of cons of this model, it may result in some rework because you started the design before all the requirements were done. Which means that if you find something later, during the requirement phase, you might have to adjust your design. And if you have already started coding, then that requirement change may also result in some rework. So that's the con of this model. So where do you use this model? Well, if you want to shorten your time scale, then you could potentially use this model. Or if you have all the resources available, and you want them to get started on the project soon, then also you can use this model to overlap this.