 mentioned and that are often used as a reference when you discuss for example a specific case at industry or if you want to discuss how one process is different to another. And when describing these models what we typically do is that we describe what activities we are doing. So as already discussed are we for example specifying something when are we doing it. We often discuss products or artifacts. So what are the things that we are producing in each activity. For example if you do requirements specification you might produce a specification document. So that's one thing we could describe. Another very common thing is to discuss which roles are involved. So what are the people that are doing the activities and delivering producing the products? Are they developers? Are they testers? Are they customers? Are they users? What are they? What is their role? And then finally something that we can discuss are pre or post conditions. So what is necessary before we start an activity? What is the precondition to get started? What is the post condition? So a typical example is that we should not be deploying the system before all the tests pass for example. It could be a precondition. So these kind of things we can use to describe what processes we are using, what they are. And probably the most well-known process model is the so-called waterfall model. So the waterfall model describes a process in which things happen after each other and it sort of is often drawn like this. It goes from top to bottom. It flows like a waterfall essentially. And the activities we are doing is requirements, elicitation, requirement specification, all the activities around figuring out and specifying what the requirements are. Then we're doing design of our system. We do implementation. I'll just write in pull here. And very often in this step you also talk about unit testing. So testing small parts of our system like a class or a function and testing all together and then finally when we are ready with everything we need to operate the system. And as discussed there are always changes, there are always evolutions. So we also need to do maintenance. Now what's special about this is that the activities are strictly sequential. So we are not starting with one activity until the other one is done. So the precondition for design is that we have finished, we have completed the requirement specification phase. And when we have finished with design we continue with the next and so on. And then of course since we do maintenance things might change. So there is the potential that we go back to any of these steps. So if we for example just discover a small bug that we could fix then maybe we just go back to implementation and testing. But maybe we also discover new needs and we need to go all the way back here. So this is how the waterfall model looks like.