How to present software to a client? Learn about the C4 model

A software product has several features, such as: design, user interaction, data persistence, integration with other software, server structure, and many others.  It is often difficult to know how to present software to stakeholders in a clear way, so that they understand how each of these features will be present in a given product.

One of the challenges of software engineering is explaining a software product to its stakeholders. That is why it is common for professionals in this area to make a comparative analysis with civil engineering in the academic environment.

The “model” of software engineering

While in civil engineering you can count on plans and models to show anyone what a house that has not yet been built will look like, in software engineering you have dozens of diagrams and documentation that are often too abstract to be understood by those who are not familiar with it.

Another difficulty encountered when documenting software is its dynamic nature. Unlike a building, which, once constructed and delivered, is unlikely to have its structure modified, software continues to be constantly updated and maintained even after its first delivery to users.

Therefore, extensive documentation with many complex diagrams can easily become out of date due to the difficulty and cost of time and money to ensure its maintenance.

So how do you present software to a client?

In this scenario, the C4 model emerges, which, although it is not a definitive answer to the aforementioned problem, helps to simplify the way in which some of the software’s characteristics can be presented.

This model consists of a set of four diagrams: context; containers; components and code . And that’s where its name, C4, comes from.

The C4 model diagrams

The main idea of ​​the model is to be able to look at the software as if it were a map. Each diagram of the model, starting with the context diagram and ending with the code diagram, presents the reader with an approximation of the software map.

Making an analogy with cartographic maps, while the context diagram can be compared to a view of countries, the code diagram could be compared to a view of streets and houses. Between these two views there are those of states and cities that parallel the container and component diagrams .

Since the model only has four diagrams and is easy to understand, it is likely to be much easier to maintain. This helps to maintain a minimum documentation of a software solution that will be available whenever a presentation is needed or a member of the development team has a question.

Understanding the diagrams

Each of the diagrams also aims to present the software to specific audiences. While the context diagram is sufficient to show company directors which systems are involved in a software solution, it may not be sufficient to show software architects which containers and components each system contains.

In accordance with this, we will now highlight what each of the diagrams is about.

The context diagram

Here you will see an overview of the systems and personas (user profiles) involved in a software solution or product. This diagram also shows the relationships between these elements.

The container diagram

This diagram aims to provide more details about the systems presented in the context diagram. Here, the containers that make up a software system are presented and how they relate to each other.

The component diagram

Just as the container diagram represents the details of one of the systems presented in the context diagram, the component diagram aims to enter a container and demonstrate which elements are part of it.

The code diagram

At this point, at the most detailed level of the model, we have a diagram similar to the class diagram of the UML model. However, it is not necessary for the definitions of the code classes to have as much detail as the UML diagram. The most important thing is to show which classes a component has and how the relationship between them will be.

Other diagrams

Although the core of the model is concentrated in the four diagrams mentioned above, the model allows for extension if necessary.

An additional view that may be useful for professionals who will be responsible for maintaining the infrastructure of a software product is the deployment diagram. This diagram is also based on a UML diagram and, unlike other diagrams in the C4 model, it presents another point of view that indicates which hardware or cloud components will execute the software.

Just like the deployment diagram, there are others that can be useful in specific situations or for specific audiences who may be interested in a software product.

C4 model is an effective method

While there is no definitive solution for documenting or providing a vision of what software will look like, the C4 model diagrams provide a simple way to do this.

The diagrams in this model can be very useful in presentations to clients, directors and even other technical professionals or new members of a development team who need to know the characteristics of the software they will maintain.

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *