Software quality from a broader to a concrete point of view

The content here is under the Attribution 4.0 International (CC BY 4.0) license

Software quality has many shades. In this post, I will explore the different aspects of software quality and how they can affect your work as a developer, more specifically focused on an approach that goes from a broader perspective to a concrete one (towards implementation).

Quality on an broader perspective

The ISO 25010 standard defines software quality in a broader terms, it is divided into three sections: Functional Quality, Structural Quality, Process Quality. Functional Quality is the quality of the software from the user perspective, it is divided into, structural quality, which is the quality of the software from the developer perspective, and process quality, which is the quality of the software from the process perspective.

Another model to keep into mind is CISQ that focuses on: Software sizing, Code Quality, Technical Debt. Which is more specific than the ISO but still broad.

The two approaches provide a broader overview and lacks the concrete aspects of software quality, which has many shapes, and will be further explored in this post.

Quality on a concrete perspective

Wihtin the concrete perspective, we can explore the different aspects of software quality that are more specific to the implementation of the software. These aspects are: Architecture, Code Quality, Team Dynamics. All of them are embedded into the broader perspective, think of it as a layered cake, where the broader perspective is the cake and the concrete perspective is the filling. It is possible to have a cake without the filling, but it is not possible to have a filling without the cake.

Architectural styles

The architectural styles are the first aspect of software quality that we will explore. The architectural styles are the most important aspect of software quality, because they define the structure of the software. The architectural styles are divided into many shapes and sizes. Lets explore some of them (this is by no mean an exhaustive list).

MVC/Layered

MVC is a pattern that separates the software into three layers: Model, View and Controller. The Model is the data layer, the View is the presentation layer and the Controller is the business logic layer. This pattern is widely used in web applications, but it can be used in other types of applications as well.

Layered architecture is a pattern that separates the software into layers. Each layer has a specific responsibility and communicates with the layers above and below it. This pattern is widely used in enterprise applications, but it can be used in other types of applications as well.

@startuml
'This PlantUML code will be rendered soon. Meanwhile, you can check the source:

package "Presentation Layer" {
  [UI Component]
}

package "Business Logic Layer" {
  [Service]
  [Business Rules]
}

package "Data Access Layer" {
  [Repository]
  [Database]
}

[UI Component] --> [Service] : Calls
[Service] --> [Business Rules] : Executes
[Business Rules] --> [Repository] : Accesses
[Repository] --> [Database] : Queries
@enduml

In my opinion, MVC is a kind of layered, however, layered supports more layers than MVC. For example, you can have a layered architecture with a data access layer, a business logic layer and a presentation layer. In this case, the data access layer is responsible for accessing the data, the business logic layer is responsible for the business logic and the presentation layer is responsible for the presentation.

Hexagonal architecture

The hexagonal architecture is a pattern that separates the software into two layers: Adapter and Application. The Adapter layer is the driver that will receive the inputs from the outside and the outputs that will return something to the outside world, the Application layer is responsible for the business logic.

Clean Architecture

Clean architecture is a pattern that separates the software into layers, but it is more flexible than the layered architecture. The clean architecture is divided into four layers: Entities, Use Cases, Interface Adapters and Frameworks and Drivers. The Entities layer is the core of the application, the Use Cases layer is responsible for the business logic, the Interface Adapters layer is responsible for the presentation and the Frameworks and Drivers layer is responsible for the infrastructure.

The clean architecture is a more flexible approach than the layered architecture, because it allows you to change the implementation of the layers without changing the core of the application. This is a very important aspect of software quality, because it allows you to change the implementation of the software without changing the core of the application.

Architectural styles vs deployment units

The architectural styles are the most important aspect of software quality, because they define the structure of the software. The deployment units are the second most important aspect of software quality, because they define how the software is deployed. The most popular ways of deployment units are divided into two types: monoliths and microservices.

@startuml
'This PlantUML code will be rendered soon. Meanwhile, you can check the source:

node "Client Device" {
  [Frontend Application]
}

node "Load Balancer" {
  [Reverse Proxy]
}

node "Server Cluster" {
  node "Monolith Server" {
    [Monolith Application]
  }

  node "Microservices" {
    [Service A]
    [Service B]
    [Service C]
  }
}

node "Database Cluster" {
  [Primary Database]
  [Replica Database]
}

[Frontend Application] --> [Reverse Proxy] : HTTP Request
[Reverse Proxy] --> [Monolith Application] : Route to Monolith
[Reverse Proxy] --> [Service A] : Route to Microservice A
[Service A] --> [Service B] : Communicates with
[Service B] --> [Service C] : Communicates with
[Monolith Application] --> [Primary Database] : Query
[Service A] --> [Primary Database] : Query
[Primary Database] --> [Replica Database] : Replication
@enduml

Closing notes

At to my knowledge there is not accepted standard way of implementing the architectural styles, the variance between programming languages and interpretations to whom is implementing them apply here.

Code quality

In addition to the known data structure and algorthims, there are other aspects of code quality that are important to explore and understand. These aspects are: Code Quality, Code Review, Code Smells, Design Patterns which we will navigate in this section.

Design Patterns

Design patterns are a way to solve common problems in software development. They are not a standard, but they are widely used in the industry. The most popular design patterns are: Singleton, Factory, Observer, Strategy, Command, Adapter, Decorator, Proxy, Composite, Template Method.

Team dynamics

The process of software development is a team effort. The team dynamics are the most important aspect of software quality, because they define how the team works together. The most popular team dynamics are: Scrum, Kanban, XP, FDD, DSDM, Crystal, Lean [1] [2].

Test Driven Development

Test Driven Development (TDD) is a software development process that relies on the repetition of a very short development cycle: write a test, run all tests, and then refactor the code to pass the new test. The process is repeated until the software is complete. TDD is a very powerful tool for improving software quality.

References

1. [1]F. Anwer, S. Aftab, U. Waheed, and S. S. Muhammad, “Agile software development models tdd, fdd, dsdm, and crystal methods: A survey,” International journal of multidisciplinary sciences and engineering, vol. 8, no. 2, pp. 1–10, 2017.
2. [2]S. Gadani, U. Mankad, and M. Gahlawat, “Comparative Analysis of Agile Software Development Methodologies: A Literature Review,” in International Conference on ICT for Sustainable Development, 2024, pp. 229–249.