By: Gabriel Dias
We all, in higher or lesser extent, depend on softwares to perform various tasks of our personal and professional day-to-day. is dependence leads us to expect programs (applications from simple to highly complex systems used in businesses) that meet our goals in the shortest time possible, e ciently and awlessly. The focus of this article is to show how important it is both those who develop the program and who is requesting to have a single view of what will be delivered and what would be a way that both can have the same view during the process of developing a software.
The center of the development process
When a software will be created, we already have two kinds of people involved in this process: one that will tell you what you need and one that will create the solution to the need of the rst. You may already be wondering what happens if one side does not understand what the other wants: an end result completely unacceptable.
And we must remember that often those who request do not know exactly what they want and end up passing wrongly what they want the program to do. Who develops a program will always be subject to the risk of having to modify and reshape much of the program that is developing for the client – that one who ordered – didn’t informed everything the system needed to do or brought new ideas that resulted in changes during the development process. And let’s assume that this has not happened, and the development has been “stable”. What prevents the same user to question and even reject the delivered software saying it has a complex functioning?
is shows that the analyst, project manager or even the developer himself needs to keep in touch with your customer. A very common mistake that happens both from professionals who develop software as the clients who request them is to think that a brief (and usually only) conversation between customer and developer on the system with a simple explanation on the objectives and functions of the it will be enough to develop it properly. Believe me, it never is.
Over the years, many articles, books and methodologies were developed trying to minimize the consequences of what has been noted above. Because the user requirements are as important as urgent for them and who develops the program has to be agile to produce and rapidly deliver what was asked.
In 2001, a group of software development experts met at Snowbird Resort in Utah and published what became known ever since as the Agile Manifesto. We will not here go into the details of it but just remember in its basic pillars:
• Individuals and interactions rather than processes and tools;
• Software that works instead of extensive documentation; • Direct collaboration with the client rather than negotiating one or more contracts;
• Responses to changes instead of following a plan.
These pillars tell us that the development of systems, programs and applications, as important as knowing
develop is to know where it wants to go and understand what the user wants to turn this expectation into reality.
For this to be something plausible it is necessary that both the client and the developer are with the same vision of what will be developed and delivered. One of the ways to establish this line between them is using mockups.
The use of Mockups
I ended up graduating in Electronic Engineering, but the rst 4 semesters were the elementary of the course. ere, during the technical drawing classes, what we always heard, especially from the Civil Engineering people, was that we could x a project mistake on the drawing board with a rubber or later at the construction site with a sledgehammer. Which of these alternatives you believe you have the lowest cost?
One way to deal with this was to create a scale or actual size model of a project or device, used for teaching, demonstration, design evaluation, promotion and other purposes. is model was called mockup (can also be written mock-up) which is nothing more than a prototype that allows a project test. ey are mainly used by designers to receive feedback from users.
e most common use of mockups in software development is the creation of system screens sketches that show the end user how the developer is thinking of mounting the screens that the software will not have to build the program itself. User interface mockups can range from very simple hand- drawn screen layouts to realistic designs for user interfaces created in a software development tool. For this, I use initially the old pencil and paper and then the program called Balsamiq Mockups.
The mockup by itself solve all the problems mentioned here? Of course not. It is a tool for the user to see what the developer is planning to be delivered. Read again the 4 pillars of agile development mentioned above and notice that mockups were not mentioned in any time. A mockup is actually a result of the practical application of the 4 pillars.
Basically, we seek to incrementally develop the application, that is, rather than trying to specify everything before you start, we try to create the rst features from the initial speci cation, testing ideas by drawing sketches of screens and gathering feedback from users. is coding style is not always easy to apply because it requires a very close cooperation with the users of the application. But even if the access to users is not so simple, we can not forget that the sooner we nd a mistake, the less expensive will it be to correct it.
The starting point is to de ne the entities that will use the system and especially how they intend to use it and what results expect to obtain. is is called a use case. Determining who will use and what we will do, we go to the how, which consists in the rst mockups. I particularly like to have an idea of the main pages and screens of applications design and how users will navigate between them. I particularly like to have an idea of the main pages and screens of the applications I design and how users will navigate between them. Of course at the beginning of a project such ow of navigation between pages is incomplete, but anyhow they will help the team to focus on what needs to be done and also understand how the actions are sequenced.