ExpressionLab

In episode 25 of Software Engineering Radio, Michael and Markus continue on the fundamentals of software architecture by discussing quality attributes of software architecture and how they relate to each other. Here is the summary.

Quality requirements of software architecture can be grouped in different categories:

a) Operational requirements (run-time characteristics)

1. Performance

Performance has 2 measures:

1. Latency: this describes the time the system needs to react on an external event. This is very important in real-time systems and is usually relevant to embedded systems.
2. Throughput: this describes how many events can be processed by the system per second. This is more relevant to transactions systems.

Performance depends on several factors like algorithms, memory, bandwidth and communication overhead. Also, performance is defined for specific use cases and well-defined system configuration.

2. Scalability

Scalability is the ability of a system to keep its performance, or degrade slightly, when the load increases. So when the load doubles on a scalable system, you should get the same performance by doubling the hardware resources. And when you keep the hardware the same, if the load doubles, you should only get half of performance. This is especially important for enterprise systems where the load is not always known and can't be expected.

3. Availability

Availability is the ability of a system to be up and running, with a specified level of quality, in a percentage of the time. This can be calculated by: uptime / (uptime + downtime). For example, a system that fails every hour and automatically reboots in a second has a high availability.

4. Reliability

Reliability describes how often failure occurs in the system. A failure can be missing a deadline in a real-time system, or having low throughput, etc.

5. Usability

Usability has 3 measures:

1. Learnabiliy: how long does it take for a user to learn how to use the system and how efficient can a user operate the system. For example, web interfaces are very easy to learn but not very efficient to use if you have to do a lot of work.
2. Memorability (re-learnabiliy): how much a user can remember to achieve a certain task.
3. Developmental time: how easy the API is to learn and how it protects the programmer from making mistakes.

6. Security

• Authentication is about who can use the system. Authorization is about what an authenticated user can do, which parts they can access.
• A secure system needs to encrypt data sent over a network, avoid buffer overflow, be safe against denial-of-service attacks, etc.
• Security should be planned and can't be implemented after the fact.

b) Developmental requirements (structural attributes)

1. Maintenability

Maintenability is the ability to extend or change your system by refactoring, removing features, supporting new scenarios, different platforms, etc.

2. Portability

Portability is the ability to run the system on different platforms, operating systems, networks, etc. This is usually not trivial require code changes.

3. Reusability

Reusability is the ability to use parts or components of the system in different systems.

4. Integratability (modularizability)

Integratability is the ability to develop parts of the system separately to be integrated later on. This is important with big systems that can't be developed by one team or in one location.

5. Testability

Testability is the ability to demonstrate that your system does what it is supposed to do. This includes unit tests, module tests and integration tests. Testability is a property of the architecture and is usually used to measure the quality of it.

c) Business requirements

1. Time to market

When it is expected to deliver the system to the first customer.

2. Cost

This includes how many resources, developers, managers can be afforded by the customer, how much effort should be spent in testing, etc.

3. Rollout schedule

Does the system have to be full up and running with no bugs, or some bugs can be accepted. Sometimes, you launch the system with some bugs because the time to market is more important. No system is free of bugs but you need to know how critical they are.

Sometimes, business aspects are in conflict with technical aspects. So it is always recommended that technical leaders get involved in these business aspects to get better idea of business constraints and customer priorities. It is important to keep the development team informed by the these business aspects but not stressed.

Relationships between quality requirement

There is no ideal system and you often have to compromise. For example, you may have to reduce the maintenability to get a better performance. But you should discuss these aspects with the customer to know their priorities and make such decisions explicit from the beginning.

Also, you can't maintain all quality attributes in parallel and you often have to balance the forces and make some trade offs to resolve conflicts. Some typical conflicts are:

• Performance vs Scalability: to achieve an optimal performance, you can fine tune the system to a very specific environment, but scalability would decrease.
• Performance vs Maintainability: to achieve high maintainability, you can separate every functionality with its own interface, but performance would decrease.
• Performance vs Portability: to achieve high portability, which is a special case of maintainability, you can use several layers which separation of concerns, but performance would decrease.
• Performance vs Availability: to achieve high availability, you can use several check points, and persist several states so it is easy to resume and minimize the down time but this usually is too expensive and adds performance overhead. For example, using redundant resources like duplicating all information between 2 databases.
• Security vs Usability: to achieve high security, you may require users to fill a lot of forms and go through several steps, which conflicts with usability. For example, the firewall of Microsoft Windows was not turned on by default before XP SP2 because they didn't want to bother users with a lot of questions and messages.

On the other hand, some quality attributes can support each other. For example, maintainability can help availability as maintainable systems are usually faster to fix.

Did you like this article? Bookmark it:

• 
• 
• 
• 
•