 Hi! In this video, I will introduce the prototyping model. I will present the idea behind this model and several approaches, how to implement it. Later we will discuss the advantages and disadvantages of a model. And finally, we will see when to use it. So, let's start! To talk about software prototyping, we need to have a similar understanding. What is a software prototype? A software prototype is an incomplete software dedicated to demonstrating various aspects of the software, such as design, functionality and others. The idea of prototyping is to validate software to be created by using a working prototype instead of using images and descriptions. The prototyping software development model is an iterative incremental model. The software is created iteratively as whole or in small increments. The prototyping practice appears in the famous book of Frederick Brooks, the mythical man-month released in 1975. Prototyping is a frequent technique in nowadays software development, but prototyping as software development model is not used frequently. Anyway, let's get familiar with the idea of prototyping. Let's suppose that we face several uncertain factors such as not-clear requirements or new technologies that are not well understood. So, we gather the initial abstract requirements from the customer and build the initial prototype. That prototype is provided to a customer for evaluation. The customer evaluates the prototype and provides feedback. Now, the development team discusses the feedback and if prototype is not adequate, the team refines the prototype and provides the improved prototype for evaluation. The team receives feedback for other discussions. This cycle continues until a customer is happy with the prototype. And now, the team proceeds. How? It depends on the specific prototyping method. So, let's investigate them. There are two major methods. The first one is fraui prototyping, sometimes prototyping. It's logical. If you need to fraui your prototype, better do it fast so you don't get attached to your prototype and the work on the software to be fraun away is minimized. One might ask why there is such a method at all. Well, this is balancing between your pros and cons of a prototyping method. We will get to it, but you should know that sometimes it works very well. So, the start is the same as in the previous diagram. The development team gathers the initial requirements and builds the software prototype. The prototype is provided to the customer for the evaluation. The customer gives us feedback and our development team refines the prototype if it is not good enough. Until this moment, everything went the same as I presented in the previous slide. The difference is the outcome when the customer and the team find the prototype to be adequate. The useful things we discovered such as requirements, designs, working algorithms and other are provided for a development team that uses another software process to create the actual software. And then the software prototype is fraun away. Still, it's a bit of pity to fraui the work you have done. Why not keep it and improve so eventually the prototype becomes the actual working software. Yes, it is possible. I will present the second major method evolutionary prototyping. Evolutionary prototyping is very similar to fraui prototyping. The development team gathers the initial requirements and builds the software prototype. The prototype is provided to the customer for the evaluation. The customer gives us feedback and our development team refines the prototype. Take into account that in this model the software system as such is evaluated. Therefore, quality methods should be applied to verify and validate software in contrast to fraui prototyping. When the system becomes adequate, it's deployed. Before discussing the advantages and disadvantages, I'll take it to special cases. The first one is related to the deployment of the software using small increments. It means that the software is split into a number of subsystems and each subsystem is being developed using evolutionary prototyping. Again, the development team gathers the initial requirements and builds the software prototype. The prototype is provided to the customer for the evaluation. The customer gives us feedback and our development team refines the prototype of the increment if it's not good enough. The software increment is a part of the whole working software system. Therefore, quality methods should be applied to verify and validate software as well as well. In the case the increment is good enough, it is deployed. Now, the team proceeds the next subsystem or the process finishes if all subsystems are implemented. The extreme prototyping method was initially related to the projects. The mockups of a user interfaces were created in HTML and provided for customers to validate it. Nowadays, we can achieve similar results for many other platforms. Therefore, this method is not dedicated exclusively to web projects. So let's start with gathering the addition requirements. Now, as you will see, the prototype creation is split into three parts. First, we create a user interface design. Next, we add the behavior so we can simulate how the software will work. And finally, we create the services that implement that behavior. Note that the customer should not wait until the development team creates the working prototype. The customer can evaluate the design and behavior before we start implementing the required functionality. It allows saving a lot of time. After the software becomes adequate, we can deploy it in increments or as whole. Now, you will see a video that demonstrates an envisioned prototyping. From the studio launcher, you can start on a new idea from scratch or pick up where you left off on an existing project. With vector drawing tools, boolean operations, masks, and layer styling properties, you'll be composing beautiful design work in no time. We know it's never too early to test out what your screens will look and feel like when they come to life. To rapidly transform your designs into an interactive prototype, select any element and press C on the keyboard to connect it to another artboard. Choose a transition and you're done. Then, you can preview your ideas directly inside studio and make edits in real time without losing your flow. When you're ready to take the fidelity of your prototypes to the next level, the motion transition gives you complete control over the animation that takes place between every single layer. Studio automatically links up the matching layers between the two screens and animates the differences. The transition editor then allows you to fine tune the timing of each layer and even preview in slow motion for outrageous precision. As your projects begin to scale, design elements can be turned into components for reusability and consistency across every screen. You'll find your organized component library at the top of the layers panel on the left hand side, where you can drag and drop directly onto the canvas. You can select and edit a component to update every single instance effortlessly. For the occasional exception, the properties of each layer within a component instance can be edited and overridden for just that one individual instance. Studio's seamless connection to Envision makes it fast and easy to publish and republish your work with a click. When viewing a studio prototype on the web, you'll see exactly what you saw in the Studio Preview window. Same animations, same fidelity, without any compromise. When it's time to share your prototype, collaborators can use comments to share and address instant feedback. And when you're ready to start building, Inspect allows developers to view specs, grab assets, and even code directly from your prototype. All of this happens in one place. Welcome to Envision Studio. The model inherits many advantages of the iterative models. There is quite an intensive customer involvement, even more intensive when compared to agile methods. The early determination of the user needs sometimes allows us to build software faster. Because of frequent customer involvement, the missing functionalities can be easily figured out. Also, this model embraces the changes as the refinements are a part of the model. On the other hand, there are challenges as well. This model is a risky one, and it has difficulties in planning because of uncertain number of iterations. Also, if the team focuses on prototyping, it can lead to overlooking better solutions. If we use rapid prototyping, developers may end up with suboptimal solutions because of the rush. The important thing is that the system structure tends to degrade if the team uses evolutionary prototyping. For example, at some point the team might find out that we have chosen the wrong architecture to accommodate newly discovered requirements. Prototypes are not documented very well because of its nature. And sometimes there are issues with customers who do not understand prototyping and confuse a prototype with the finished system. Usually, there is a long way from the prototype to the complete software. In the beginning, I said that this model is not used frequently. Also, we have reviewed several drawbacks of this model. Still, it doesn't mean that this model is not useful. Let's see when to use this model. As the name implies, we should use this model when facing uncertain things such as obscure or unstable requirements, new technologies, or other. The prototyping allows removing such obstacles of a project. Therefore, it's an excellent model to demonstrate the technical disability or proof of a product's concept. It is good to prove that some products could be created otherwise versa. For example, there are popular events called hackathons. Typically, there are given three days to develop the prototype and demonstrate an idea of a product. The best ideas and prototypes are rewarded, and the creators are encouraged to develop their idea further. Many games are born in such a way. As I mentioned before, this model is suitable for developing user interfaces, high technology intensive systems, and systems with big complexity. This model is popular in scientific institutions such as research institutes or universities. The scientists create prototypes proving that some inventions can work. Later on, the prototypes are adopted by software companies through a technology transfer process. Larger companies themselves have R&D departments that have a similar purpose. To conclude, the prototyping model is an iterative model that can use incremental deployment. The main idea is to validate software to be created by using a working prototype. This model is good when we face uncertain factors such as unclear requirements or new technologies. One of the best ways to solve it is to use prototyping. On the other hand, this model is a risky one. It's challenging to plan development of a project because of the uncertain number of iterations.