Why Usability

The first thing we have to take into account is that the software is used by humans and because of that fact, the software and the systems must be easy to learn, efficient to use, effective and simple to remember. The developers and the stakeholders should think about those factors when they are designing and developing a new software system.

Usability is needed to measure the quality of the user experience when interacting with a product or a system. It depends on several factors such as the degree of satisfaction of the user needs or the easiness level for navigating through the system.

The importance of usability applied to software products can make the difference between performing a task correctly or not, helping the user to perform it or being a nightmare. Usability can be the key factor for success or failure of a product.

The Benefits

There are benefits for both sides. The providers can reduce the amount of hours and costs used for development, training and support. For the users’ point of view, they will enjoy interacting and using the product, achieving goals, working effectively and efficiently and their satisfaction.

The investment on usability is a powerful weapon for the companies, if it is correctly used the profits can be increased and also the customer satisfaction, customer confidence and performance while working with the software. If the customer is satisfied with the program and enjoys working with it, he/she will keep using it and probably recommend it. This opens the market of the companies and also reduces their costs as the software has no errors and they don’t need to spend either money or time on debugging and fixing errors.

As a conclusion, including usability on the development process at the beginning can be an investment but at the end will generate profits and benefits for the companies providing the software and also for the users who will obtain better products.


Review of “Metaphor, myth and mimicry: The bases of software engineering”

In his paper, Antony Bryant presents different metaphors, myths and different points of view to explain the term Software Engineering and its consequences on the how society views the production of software. All the several points of view mentioned on the paper suggest that the development of software is a complex task which sometimes needs some tools of the regular engineering to be successful.

From my point of view, seeing the programmers as engineers can lead to give them the construction specifications instead of a list with many ideas about what the software should do.

The metaphor used for the communication and requirements engineering process (the toolmakers paradigm) clearly shows what happen many times when the requirements are established: the stakeholders and the developers talk on different languages or see the problem form different perspective. People involved in requirements need human, communication, listening and understanding skills in order to obtain as much information as possible to develop correctly the list of requirements needed.

The author also mentions the use of scenarios as a way to reduce complexity and to help to encourage the interdisciplinary learning. In those scenarios, the stakeholders and the developers can communicate in the same language and under the same context.  Miscommunication is shown as a barrier and also as a normal difficulty depending which of the metaphors are we looking at.

As a conclusion, miscommunication exists and is a real problem and the possible solution to it is a collaborative environment where all the participants are involved into a defined context for establishing the requirements and reaching an agreement about the software features.