 Okay, we've covered a lot of different generic process models, but there is one last that Summer will mention, but I have it here in a special video because I consider it sort of more of a standard activity rather than an actual process, and that's reusing existing software. So the idea is that you integrate existing components rather than implementing everything from scratch. So you specify and then you jump into implementation, but instead of implementing everything you first check whether there is something that does what you need. And these are typically referred to as components of the shelf, COTS. So the idea from traditional manufacturing is that you have your shelf with different things. You take one off the shelf, you put it into the software, you put it in place. In practice, this requires a lot of configuration, and by configuration I do not only mean writing a configuration file, but typically you need to write some code around it, glue code adapters so that the component actually fits. And this is then the actual implementation work. This kind of activity is a standard in many businesses. So for example, Netflix has the policy that before you implement something you first check whether there is something within the company because they have a lot of small components that do repetitive tasks. It's also very common in ERP enterprise resource planning systems like salary staff systems because they need to be tailored to different contexts. So for instance, if the university would need a new ERP system, they would probably go to a company that has a lot of different components and they would then configure the system according to what is needed here, according to Icelandic legislation, according to the policies and the size of the university for instance. So reuse is an extremely common process and the other important thing, almost the most important thing in software development is being able to handle change because software changes all the time and it changes because our business might change. So different competitors, for example, change in the market, technology change. So a new version of an Android phone, the new iPhone or a different library or just a really radically new technology coming that you somehow need to integrate into your software system. And finally, we very often have changes due to changes in legislation. So new laws, changes in laws and they tell us, for example, now you need different privacy settings. If we can't deal with this, we're very quickly out of business and on the other hand, if we can deal with this very, very well, we're having competitive advantage over our competitors. So this is really, really important and there are essentially two ways of dealing with this. You can anticipate change or you can tolerate change. And anticipation in this case means you have, for example, an activity in your process that is sort of building a rapid prototype in the very beginning showing it to your customer and users and then discarding it entirely and starting from scratch based on what you learned. So you really anticipate that this step will be, in a way, a waste of work. We will not use the prototype afterwards, but it's necessary. The toleration step or the toleration idea in the process is more to accommodate for constant changes, for example, by doing incremental development. So what we already discussed, you can develop in iterations or you can also deliver in iterations. So after a couple of weeks, you actually deliver the first product to the customer, but then there are changes. You will change it and deliver again. So this is already something that we discussed and what we'll discuss based on this next is the very, very influential idea of doing so-called agile development. So a form of incremental development in which you essentially tolerate change, you change things about every two to four weeks.