Introduction to METRIC V3

Whenever you start developing applications for third parties, it is advisable to have a set of tools and steps to follow to define the scope of the project. This helps in creating a well-defined budget, minimizing risks. Below, we present a series of steps that can be followed.

ARTECO CONSULTING SL

Java, Software, Websites, SEO, and Training

Get to know us

What is a software development methodology

Methodologies are nothing more than guidelines to standardize the processes of creating or manufacturing more or less complex systems. The aim is to unify the way necessary activities are carried out, minimizing the problems that can arise from doing things differently or skipping a step in production. Like in most manufacturing sectors, software is no different; it also requires following some steps to tackle large projects or to unify the approach of the entire development team.

In the field of information technology, software is commonly referred to as Information Systems because it involves not only programs but also infrastructures with communications, databases, backups, and other elements that enable providing the necessary service and being available most of the time. Therefore, methodologies often refer to Information Systems to consider all the actors involved.

Which Methodology to Follow for Developing an Application

Within the world of computer applications, two traditionally used approaches are quite different. The agile approach, where its main exponent is the Scrum methodology, allows starting from a somewhat loose starting point and refining the system through successive deliverables. Or the rigid or cascade systems, which require the previous phase to be closed before moving on to the next. The primary exponent of the latter type in Spain is Métrica V3. It is advisable for individuals with little experience in developing information systems.

In the following lines, a simple methodology extracted from Métrica V3 with personal touches is explained. This will serve as a starting point for programmers who are just starting and are not very clear about the path to follow when tackling a small-scale project.

Project Phases

When following a cascade methodology such as Métrica V3, there seems to be a consensus on the order of phases, which are then broken down into activities to be carried out by different profiles. Some tasks can be executed in parallel by different members with specific roles in the development of the information system.

In general, the following list of phases is accepted:

1. Information Systems Planning
2. Development of Information Systems
   1. Feasibility study of the system
   2. Analysis of the information system
   3. Design of the information system
   4. Construction of the information system
   5. Implementation and acceptance of the system
3. Maintenance of Information Systems
4. Project Closure

Which Methodology to Follow for Developing a Simple Project

Ideally, it would be preferable to strictly follow Métrica, carrying out all the activities it indicates and in the way they are described. However, for simple projects, it is too complex and requires a lot of effort, as it is designed for large initiatives of the Public Administration or complete corporate systems. Nevertheless, it serves perfectly as a basis to identify the steps to follow in any application.

---

Simple Software Development Methodology

The following proposed methodology for developing software applications and computer programs should be taken as a reference and a useful guide for those who are starting to program. This recommendation is not relevant for experienced programmers or programming teams. In these cases, it is more advisable to apply the agile Scrum methodology or follow the cycles outlined in Métrica.

0 – Define the System Objectives

The first step in carrying out any activity is to specify what you want to achieve. Defining the objectives is the most important step on which all other activities will depend. Therefore, its concretization is the critical part in the development of a computer program. Changing objectives halfway through the project may require discarding all the work done and starting over.

Therefore, the objectives should be defined as detailed as possible following the SMART rule:

• S-pecific – Specific
• M-easurable – Measurable
• A-chievable – Achievable
• R-ealistic – Realistic
• T-imely – Time-Bound

The objectives should not be many; the fewer, the better, since an information system should primarily be designed to address ONE need. Although, over time, the system may grow. It should be remembered that, just like programs grow in complexity exponentially based on the number of variables they use, the same will happen based on the number of objectives it must achieve.

1 – Identification of User Profiles

Once it is clear what you want to achieve with the information system, the next step is to classify the different user profiles that will interact with the application. It should be noted that users can be individuals or other systems interconnected via a communication network. Whatever the case, it is necessary to specify who will use the new system.

2 – Definition of Functionalities by Profile or Role

The next natural step is to determine for each user profile, also known as a role, which program functionalities they will use and therefore, which options they should have available and which ones they should not.

It is common at this point for some security mechanism to appear that prevents certain users from performing certain actions within the software, avoiding information leaks or unauthorized access to personal information (protected by the European GDPR regulation) or confidential corporate information.

As a result of this analysis of functionalities by role, the catalog of functional requirements is obtained, determining the use cases of the application.

Some example requirements could be:

• the customer can connect to the system to print the purchase invoice in PDF
• the accountant can create purchase invoices for a given customer and one or more items
• the customer cannot delete purchase invoices with already delivered products

This catalog is high-level and specifies business functionalities in a non-technical and understandable language for users, and therefore for the potential client of our programming services. They should understand what we have identified as needs that the system must cover to authorize it and give their approval as if they were the "blueprints of the house." At the same time, it serves as a guarantee to limit our responsibility and to confirm that the request has been understood.

Many times, clients are asked to sign the catalog of functional requirements, just as the client is requested to sign an architecture project, to avoid conflicts between what the client requested and what the provider delivered as completed work. This process usually requires document revisions until the version is agreed upon by the client.

It is important to add a clause to the catalog that indicates that what is not specified in that document will not be planned, will not be estimated in costs, and will not be carried out. In fact, this document is often the basis in many projects for creating the budget.

3 – Catalog Information Entities

With the functionalities per user concretized and agreed upon, the scope of the system can be obtained, allowing for the creation of a budget. Additionally, it allows technical personnel to identify the information entities that the program must handle. In other words, it allows to define the data model that will host the storage and processing of the application's records.

Management applications typically use SQL relational database management systems to store information consistently. So at this point, defining the data model is usually equivalent to defining tables and columns in the database. If you want to learn more about SQL databases, you can check out the Structured Query Language (SQL) Tutorial we have prepared.

The data model must support and be consistent with each and every one of the functional requirements. If any requirement shows that the model is not sufficient, the corresponding tables or columns should be reconsidered to support the needs outlined in the requirements catalog.

4 – Define Functional Processes

The requirements catalog is usually organized by user profile, which implies that some functionalities are available for more than one type of user. For this reason, phase 4 aims to unify the actions that can be executed in the application into business processes, as part of standardizing the flow of information from the user interface to the database and vice versa.

Writing processes is equivalent to creating flowcharts or sequence diagrams, indicating what actions should be taken at each step to complete the process. For example, when consulting a PDF invoice, the system must first check that the user has permission to perform such an action. Second, retrieve the invoice from the database. And third, convert the raw data into a PDF file. This sequence could have been described as:

PROCESS: PDF Invoice Inquiry

1. Check that the user is identified
2. Obtain the company associated with the user
3. Verify that the requested invoice belongs to the user's company
4. Retrieve the details of the invoice from the database
5. Identify the template for PDF generation given the user's company
6. Execute PDF generation given the template and invoice details
7. Serve the PDF to the user who made the request

Executors: administrator, client, …

Requirements: user identified in the system

Other process characteristics…

The description of this process is an example but covers two important objectives. First, it is a confirmation that all the functionalities identified in the requirements catalog are accounted for. Second, the breakdown into smaller actions allows for identifying and grouping similar functionalities to implement, such as the need to create a security module, which, according to the example, will likely be used in most processes and should provide the possibility of obtaining the company of a connected user.

5 – Group Processes into Modules

The same decomposition of processes into activities from the previous step allows identifying application modules, such as the aforementioned security module. The example also highlights the need for another module for PDF generation, given a template, and even another for invoice management. Modules are groupings of actions performed on the same information entity and can serve one or more different modules.

Identifying modules and their methods before starting development greatly simplifies the programming effort, providing a comprehensive view to the technician of everything that needs to be built, allowing the identification of reusable components or the incorporation of existing libraries.

From the perspective of Java programmers using Spring Boot, a module will become a service class annotated with @Service. And each action of the module will be a method of that class. If you want to learn more about programming with Spring Boot, you can check the Spring Boot programming tutorial.

6 – Software Development Phase

At this point, all the analysis work (and part of the design) has already been done, so there should be a very clear vision of how the information system will be. From here, the more mechanical work of programming begins, not without creativity, as it involves creating classes and methods. Performing inheritance, building components, separating responsibilities are tasks that the programmer will be able to do based on experience. As the programmer works on similar projects, they will see how the written code is drastically reduced by incorporating the functionalities provided by the framework used.

If you have doubts about how to approach a project and which technology to use, we strongly recommend using Java as the best programming language. Along with Spring Boot as the best framework for building applications in Java. With this choice, you can build robust and professional applications with minimal effort, gaining highly desirable skills in companies.

Whenever developing new applications, with existing ones it may not be trivial. It is advisable to apply the test-driven development methodology, also known as TDD. With this approach, the programmer starts by writing validation tests and then implements the algorithms. This way, a large battery of tests is obtained that checks the correct functioning of the information system after each change and before deploying the system openly in production.

These tests are automatically executed by Maven during the build of the Java application, preventing a new version from being released that does not pass all the tests successfully, offering a high level of assurance that the changes will not introduce problems once the deployment is made.

Both the Java project files and the unit test files are considered part of the project's source code, so it is advisable to have them under a version control system like git to avoid problems if there is more than one programmer or if the programmer works on the project from different locations. Additionally, it provides an excellent backup system in case of an erroneous modification of any file.

7 – Validation Testing Phase

Although unit tests are very useful, they are not sufficient to certify that an application works correctly. Unit tests tend to test very specific parts of the application and do not check the entirety of the application. Unit tests focus on testing one or more methods of a class but are not usually programmed to make a web request or read an automatically generated PDF. So, other types of tests are required to fill in the gaps left by unit tests.

The next battery of tests usually performed is integration tests. In these tests, external tools are used to check that the application can connect to other systems, such as databases, FTP systems, or even other web applications or microservices. And, as the name suggests, they verify that configurations and integrations with other applications work correctly in a specific environment, for example, in pre-production. JMetric or SOAPUi is commonly used to automate batteries of automated tests.

If the information system is the last in the service chain, for example, an application open to the internet, the tests are called end-to-end (E2E) tests since they check that the program works well, but also all the systems below that are consumed by it. E2E tests are those that provide more guarantees of operation and may even be seen as executed directly on production systems, although with many limitations to avoid irreversible changes or saturating the system, preventing its proper operation.

In any case, the final testing step should be carried out by the client or end-user, who provides their approval of the work done and the suitability of the solution to the need outlined at the beginning of the project.

8 – Production Deployment Phase

The production deployment will depend heavily on the technology used to develop the application. If Spring Boot has been used, the application must be generated with Maven, creating a JAR file that can be executed by the Java Virtual Machine (JVM) on virtually any operating system, whether real or virtual in the cloud.

We recommend deploying applications in sets of machines that take into account load balancing and high availability, such as those offered by the most used cloud infrastructure called Kubernetes. However, for small applications or personal developments, it may be complex to have and manage a set of virtual machines. In these cases, we recommend using Docker, as it is more adapted to small environments and is a necessary prerequisite to take applications to Kubernetes if the project scales in size.

9 – Maintenance of the Information System

The effort required during the maintenance phase should not be underestimated, especially if there is an ongoing warranty commitment or if a pool of hours has been established for adjustments and evolutionary developments to the information system.

Post-sales maintenance and adjustments often consume a large part of the project budget since users, unless they are other IT professionals, usually do not provide all the information generally, either due to lack of knowledge or to avoid obtaining a high budget. Then, they usually make excuses that the system does not work correctly because basic elements for its operation have been left out of scope. Hence, it is important to involve the user in the requirements catalog and mention that points not included will not be planned, estimated in costs, and will not be carried out. This document is often the basis for budgeting in many projects.

In conclusion, users ALWAYS want changes, so it is advisable to be prepared so that the cost of those changes does not eat up the potential benefits of the project, either by billing additional hours or through a contract for a pool of hours for evolutionary developments.

The technical aspects of this phase do not differ from the previous ones since they simply consist of carrying out an analysis of the changes, implementing them, and deploying a new version of the application. In a way, changes and evolutionary developments are smaller cycles of analysis, design, implementation, testing, and deployment. So, the same instructions as before can be followed.

It is important to keep in mind that all changes made to the application must be subject to source code control with Git or similar, correctly archiving, with branches and tags, the different released versions. Especially if several versions of the same application coexist in different clients simultaneously.

Do not forget to introduce, if necessary, backup systems or to create and execute contingency plans to make the application operational again if necessary and in the event of any disaster, whether from the database or the service that keeps the application running.

10 – Project Completion or Closure

Every beginning has its end, and sometimes there's no choice but to press the off button on an application developed with a lot of effort. Nevertheless, it shouldn't be seen as a defeat, but rather as the achievement of its goal at the right moment and the acquisition of knowledge gained in each of the phases, often translated into the acquisition of know-how in the business or sector at hand.

In any case, many of the problems solved tend to be recurrent. The written code may be reusable later in a new initiative. So, it is advisable to establish an archiving mechanism that allows retrieving useful parts for future occasions. This will also enable providing a more accurate budget and, therefore, be more competent by reusing previously written and validated code.

Conclusions

We hope that this guide has helped you clarify the steps that must be followed in the development of a software project, website, or mobile application for a client. In these situations, it is advisable to close the commitment acquired regarding the expected functionalities and the economic consideration for the work done and future obligations such as warranties or maintenance.

If this is your case and you have completed a project, share your experience with us or let us know which steps have worked well for you to share with the community.