The practice of prototyping in a software company

No, this article is not about the game about Manhattan and its mutants infected with the virus. We will talk about prototypes of another kind - software prototypes.



Software prototyping is becoming an increasingly popular and often used process in Russian IT companies. The reasons are the following: on the one hand, this is a definite homage to fashion, on the other, prototyping promises the company a number of significant advantages.



However, making the prototyping process useful and effective is not an easy task. There are pitfalls, questions arise. Who should prototype and when? How to make prototypes? How to use them? The answers to these questions and the next steps determine the success and usefulness of the innovation. If they are wrong, prototyping can be not only harmful, but also extremely costly.

')

In the article I want to share the experience of building a prototyping process in my company . I will tell you how we answered the voiced questions and what successes we have achieved.

When and how to use prototypes? Theories and Practices

To determine the place of prototyping in the software development process, we first turned to international standards in this area and collected the following information.

Subtotals. Squeeze from theory

So, based on the analysis of sources, the following options for the use of prototypes can be distinguished:

• As a tool for extracting, checking and approving requirements at the stage of working with requirements
• As the basis for writing SRS and TK at the design stage
• As a software design verification technique at the design stage
• As an object of usability testing at the testing stage
• As a sample for developers at the implementation stage (design)

But we use prototypes even more widely - I’ll add 4 more variants to the listed ones.

How else can a prototype be used?

At the stage of commercial offer

Sometimes we make prototypes at the stage of a commercial offer, i.e. even before the launch of the project and before the collection of requirements, based only on basic information from a potential customer. How we do it - I have already told .



What are we doing this for? Everything is simple: the prototype allows us to stand out from a dozen similar commercial offers and attract the customer.



We do this not always, because There is always a risk that the project executives will not choose us, and, accordingly, the prototyping work will not be paid.

As a sample when testing the finished software

We use the prototype as a model, not only when implementing the system, but also when testing it. Our testers are now at hand, in addition to the TK, there is always a prototype. Some interface functions are hard to describe and perceive as text, in which case the prototype is a good helper.

As a sample upon acceptance of work

Here, we are no longer using the prototype, but our customers. When accepting work, they now, in addition to, and sometimes instead of checking the functions according to the TOR, compare the implemented system with the prototype. It is beneficial to both parties. The customer has the right to make a complaint if there is something wrong in the implemented system as in the prototype. But we as a performer can protect ourselves from claims if we implement the system in the same way as in the prototype. The customer simply will not have reason to be dissatisfied. Thus, the performer gives, and the customer receives exactly what was agreed - no more, no less. Nobody does the extra work, and everyone is happy.

As an example of a solution for demonstrating to potential customers.

Sometimes we do not have the opportunity to demonstrate the finished system to the customer and we show him the prototypes developed and used on past projects.

Prototype life cycle

Now, when all the possible ways of using prototypes are listed, I will show the full cycle of using prototypes with us.

1. Establishing contact with a potential customer and receiving preliminary information from him. The manager creates a small interactive prototype. Itself, while without attraction of the designer. We send a commercial offer with a video recording of the prototype.
2. If we are selected as an executor of the project, then we instruct the designer to draw the UI components and refine the prototype. We go to the customer with an updated prototype. At the same time, if the customer and users are different people, we ask you to allow us to the end users: they directly on the prototype show what they like and what they want to change. Thus, we collect the requirements, change the prototype in accordance with them, and again go to the users. A few iterations of the prototype, and, accordingly, the functionality agreed.
3. When the functionality is agreed, we ask users to specify the functions that they are inconvenient, uncomfortable, unusual. We fix the prototype in accordance with the comments. This is a kind of usability testing.
4. In parallel with the communication with the user, we agree on a prototype with the developers. Find out whether it is possible and how difficult it is to implement what is shown in the prototype. If it is impossible to implement any function, then we come up with an alternative option and agree with the customer. In the end, we get a prototype, agreed with both the customer and the developers.
5. We remove screenshots from the prototype and make TK on their basis.
6. We give TZ and a prototype to developers. Developers implement the system using a prototype as a sample.
7. The finished system and its prototype are given to testers. They also use the prototype as a sample.
8. We hand over the system to the customer. It checks if the implemented system conforms to the prototype.
9. The prototype goes to the archive. But if the customer asks for revision, we will get a prototype and modify it to meet the new requirements. And then again on the cycle from the second step.

Implications of prototyping

After the introduction of prototyping, we have changed the whole software development process. As can be seen from the life cycle, the prototype permeates the entire development process. The prototype has become an element that everyone sees and that everyone discusses: from the user to the programmer. He became a kind of unifying, central link. He brought the communication both with the customer and within the company to a new level. The loss of information along the way from the customer to the programmer has significantly decreased, because everyone sees the same prototype.



If earlier the process of information transfer looked like this:







it now represents something like this:







He borrowed the pictures from the presentation of Gennady Dragun, for which he is very grateful.

Prototypes are different ...

There are many opinions about what should / can be considered a prototype and what characteristics it should have. In order not to expose my subjective vision for the truth, I will again turn to the SWEBOK body of knowledge. He says that both “paper” models and pilot subsystems implemented as independent (in terms of resource management) projects or beta versions of products can be considered as a prototype.



Prototypes can be divided into 2 large groups depending on how they are created and subsequently used:

• Disposable prototypes
• Evolutionary prototypes

One-time prototypes are the interface layout, which later will not become part of the finished system and at a certain stage will be “thrown away”. Such prototypes are created and changed quickly, because they do not require high-quality implementation. Often they are created in specialized tools without programming.



An evolutionary prototype is a preliminary implementation of the program, an alpha version, which as it develops becomes closer and closer to the finished product and eventually becomes it. Evolutionary prototypes are less flexible, their creation and modification is longer and more expensive. Since not all requirements are known and approved at the initial stage, a prototype can be patched up during its development. With this approach, there is a big risk to get a product of unsatisfactory quality. The advantage of evolutionary prototypes is that, firstly, at the early stages, the customer gets a working system, secondly, no need to spend resources on creating a prototype, which will then be “thrown away”.



Each approach has its advantages and disadvantages. Everyone decides for himself which prototypes to create depending on the problem being solved, on the particularities of the software development process in the company, on the qualifications of the employees. We decided to use one-time prototyping as the most flexible, efficient and less risky tool. I emphasize it.

What prototypes are we using?

One-time prototypes are divided in turn by:

• degree of interactivity,
• detail, accuracy, proximity to the final design.

Most of us make paper prototypes at the very beginning of the requirements gathering phase. Then, as requirements become more precise, the accuracy of the prototypes increases. Someone stops at a wirframe (an interface frame without a final design), someone brings to mockups with a design that is close to the final one. But the most interesting are interactive prototypes. They will allow to fully engage the user, to show the system entirely and in action. For us, interactive prototypes are the most effective, which is why we use them in our activities.

Prototyping in the post-Soviet space

Now a summary of the distribution and trends of prototyping in Russia and the CIS countries. As the survey , conducted by Pavel Konoplitsky on Habré, shows, in half of the companies there is no prototyping process.







However, the realization that the prototyping situation in the company is unsatisfactory is encouraging. This is evident from the results of another survey : more than 70% of respondents are not satisfied with the current situation and almost half of them are currently looking for a good method and tool. Good trend.

Who should prototype?

Let's return to the first survey. If you look at the performers, prototyping in most projects involved technical experts. For me, this was a surprise: as I said, most standards and publications consider prototyping primarily as a tool for extracting and approving requirements. And who collects the requirements? Manager or analyst, but not a technical specialist. If he does this - we will again have big losses of information, the manager will play the role of a broken phone. Therefore, we believe that the manager should prototype, as the central link of the project team and as the person who is in direct contact with the customer. In our company, the position of manager and analyst is combined, which is another factor in favor of prototyping by managers.

How do we make prototypes?

We set two conditions: first, prototypes must be interactive, and second, managers must prototype. We needed a tool that allows us to create interactive prototypes without programming, because managers generally do not know how to program. We tried Visio - but the interactivity of the prototypes created in it was low. We tried GUI Design Studio. But he did not catch on.



As a result, we came to our own development and made it the way we want to see the prototyping tool. If not enough of any features - added. As a result, the development has grown to a quality product, and we launched it to the market. Called the GUI Machine . Now it is a cross-platform prototyping tool that allows you to create interactive prototypes of desktop and web applications without programming.



Using your own tool to create prototypes has both positive and negative sides. The downside for the company is the need to allocate resources for the development of the GUI Machine. With the introduction of the product to the market, the number of required resources only increases: the tool must be promoted, developed and supported. The advantages of our product are that we can make a tool the way we want it to be. In addition, the product began to generate commercial profits.

Behold the root. Search for answers

I want to note that the tool is just a means of ensuring the prototyping process. The process is primary. Without a built and streamlined process, no prototyping tool “will not shoot”. First you need to answer the questions:

• why prototype?
• who should prototype?
• when do you need to prototype?

And only then decide how to do it. Only then will you understand what tool you need.

Do you prototype?

As a result - the pros and cons of the implementation of the prototyping process.

-

• A waste of extra effort at the pre-project stage, which the customer is not always ready to pay
• Time to learn the prototyping tool.

+

• New level of communication with the customer and within the company
• Errors made in the beginning of the project and found at the end of it are the most expensive. Prototyping allows you to detect mistakes made at an early stage and minimize the appearance of new
• Improving quality by reducing the number of errors
• Reducing the time and cost of development due to the development of "the first time" without the need for refinement - saving the developer’s scarce time
• Users do not experience rejection, because they are already familiar with the prototype, and the system interface does not become a surprise for them
• Users who have worked with the prototype do not need to be trained in working with the system.
• Increase customer loyalty.

Numbers

It is difficult to incite all projects under one scale: they are all very individual, vary greatly in duration and cost, as well as in the layout of work during development. Therefore, the figures below are estimated and averaged:

• Duration of work with requirements and design increased by 50%
• Dates of implementation were reduced by from 20 to 35%
• Dates of testing decreased by 30%

In our projects, work with requirements and design occupy about 30% of the entire project duration, implementation - about 40%, testing - about 30%. Based on this, it can be calculated that the total project time was reduced by a value of 2 to 8%.







These are only dry numbers, but, as I have already said, prototyping gives far more than just a reduction in terms.

Conclusion

For us, the prototyping process has become definitely profitable and useful.



If you are not yet prototyping - try, you will not regret.