 Welcome to module two of this course, which is on the topic of software development processes. What we'll discuss in this module is in the beginning what these processes are. So what do we understand under a software development process? What are generic process models that exist? We'll just discuss a couple of these. Then we'll discuss common activities that are part of the different processes, and they typically show up over and over again, even if we use a different process model. Then as a very important central topic, we discuss how we can react to change. So things changing, how do we deal with that? And then finally, we'll finish up on the topic of industry use. So what of all of this is actually used in the software development in the IT industry nowadays? To start off with the first topic, what are processes? What we typically understand under a process is a set of activities. So a set of things, a set of tasks that you do for developing software, a structured set that you follow, and typical activities that we have, for example, the specification. So for example, as we discussed in the first module, the specification of requirements, the specification of needs, the specification of the design of the system. And then we have, as a next step, design, so breaking down the system in subsystems, deciding how to structure it and things like that. Then we get into implementation, so the actual programming, the actual coding of the software code. And this is typically followed by what is known as validation. So validating, making sure that what you have implemented is actually correct. It corresponds to what you have specified. It corresponds to what the user, the customer, the different stakeholders actually need. And then no system is complete. There is always some kind of evolution. So things change. Bugs might be discovered that we have to fix new stakeholders, new users are added and we need new requirements, for example. So systems evolve over time. And these activities are very typical things that you will find in a lot of different processes. But it's important to remember that these might not always be explicit. So it might not always be that someone says, now we do design, for example. But it could be something that just happens accidentally. While you think about how to implement your code, you make some design decisions, for example. And it could be that you don't write down your requirements, but nevertheless you will try to understand what is necessary in order to satisfy the customer the stakeholder needs. So these are what processes are. And the reason we have them is that we can discuss how software is developed in a good way, in a systematic way. And we can give these kind of specifications, these structured set of activities to, for example, companies and say, this is a good practice, this is something that you should follow so that your software product has the right quality. Because remember, software engineering is all about having a systematic approach so that the quality gets better, the quality gets predictive, for example. So this is why we have these process models.