 | Just imagine the situation: you deliver a completed software product to the client, he installs it, launches it in a flurry of excitement, staring at the screen and… pure disappointment! - This is absolutely not what I expected! You start analyzing the product. - Was it developed in accordance with the specification? - Yes, it was. - Were all the functions implemented? - Sure. - Were the requirements met? - Oh, yes! - Gosh, than what is the problem? - This is not what I wanted to see! |
Today, when almost every software development company has in-house testers and analysts why do such situations occur? May be the answer is in the approach to software development process organization. Let’s have a look at the most common software development schemes.
- Traditionally software products have been developed in accordance to the following scheme: after the analysts gathers all the requirements and creates the SRS, the development team just uses it as a guide in project delivery process.
User interface is created after the functionality is delivered. As a result the client is unhappy and the development team is puzzled: all the requirements have been met, what’s wrong? - Then someone doubted the practicality of completing a program to find out that the interface is not user-friendly. That was how the idea of creating working prototypes appeared.
Creating a prototype takes much less time than creating a working program. But still, the prototype is closely connected with the program functionality. And therefore if the user is unhappy with the prototype appearance a lot of work may turn out to be done in vain. It inevitably leads to serious alterations. - Soon still another approach occurred. It consists in division of the software development process into program functionality implementation and graphic user interface creation. These two aspects of a program are developed independently.
.jpg)
This method allows increasing the speed of the development process. It’s cheap and easy to create an image of the future program interface. Besides it makes it possible to visualize a program before it is completed. And if something goes wrong you can always reshape the process until the desired result is achieved.
Nevertheless when you present the image to the client a lot of minor arguments can occur concerning the shape of the buttons, logo, background colour and etc. So, have patience!
A piece of advice: pass on to another screen image discussion only after the client approves the previous one. Otherwise you may drown in minor alterations. - The progress doesn’t stand still and finally software developers arrived to the idea that the process of interface creation can be as well subdivided into design creation and content elaboration. What the user sees as the development process goes on is a sketch of the future program interface. Therefore there is no risk that he gets confused by the design, working buttons, etc. Screen acceptance passes much quicker. The main requirement here is that the sketches should be developed by a professional with considerable experience, whose work costs a lot.
.jpg)
The first time we tested this approach in our work was very successful. We managed to cut down project delivery time considerably due to the following factors:
- Division of the whole development process into minor aspects helped us avoid the “absolutely-not-what-I-wanted” situation. Instead effective discussion of separate issues and remarks took place.
- It revealed many faults and imperfections in the project.
- Necessary functionality that wasn’t specified by the client at the initial stage came to light. The problem of missing functionality was quickly settled.
- It became clear what are the project aspects that require special attention.
The sketch-based approach paid for itself and ensured the project success.
.jpg) | Posted by Ekaterina Molchanova, QA Analyst |
| Bookmark or share: |          |
