Introduction to MÉTRICA V3

Whenever you start building applications for third parties, especially in demanding corporate environments, it pays to have a set of tools and steps to follow to define the scope of the project. In 2026, improvisation in software development is no longer an option for companies looking for profitability and scalability. A clear roadmap lets you produce a tight budget while minimising the risk of cost overruns, which is vital for start-ups and established businesses in the Balearic Islands operating in competitive markets such as tourism or the marine industry. Below we set out a series of steps grounded in the technical and architectural experience we have built up in mission-critical environments.

What a software development methodology is in the age of AI

Methodologies are not mere bureaucratic paperwork; they are strategic guides for standardising the way complex systems are built. Their purpose is to unify how technical activities are carried out, keeping to a minimum the technical debt and architectural inconsistencies that arise from a lack of order. As in any precision industry, software needs rigorous engineering to tackle large-scale projects or to coordinate distributed development teams that must deliver high-quality code predictably. Today this also means integrating applied artificial intelligence to automate workflows and enable predictive analysis.

In modern IT we prefer to talk about Information Systems (IS), a concept that goes well beyond source code. An IS brings together programs, cloud infrastructure, communications networks, resilient databases and high-availability systems optimisation practices. Today's methodologies have to take all of these elements into account so that the service is not only functional but also secure and available under any traffic load, particularly in seasonal sectors such as distribution channels for tourism products.

Which methodology to follow to build a robust application

In software engineering today, two approaches coexist and often complement each other. On one side is the agile approach, best represented by the Scrum methodology. It lets the system evolve through iterative deliverables, which makes it ideal for highly uncertain contexts such as building new SaaS for property management. On the other side are rigid or waterfall systems, which require each phase to be fully closed before moving on, giving far stronger control over documentation and risk on long-running projects.

The leading example of this model in Spain is still MÉTRICA V3, the methodology published by the Spanish public administration. Some may call it old-fashioned, but its rigour is indispensable for projects with strict legal requirements, or for developers taking their first steps in managing small projects who need a framework that keeps creative chaos at bay. In the sections below we break down a simplified methodology derived from MÉTRICA V3, refined with practices from our 2025 technology stack and the distributed architecture trends that dominate 2026.

What phases a business software project goes through

Following a waterfall methodology such as MÉTRICA V3 provides a structural consensus on the order of the phases. That predictability is what lets CTOs and IT managers sleep at night when facing complex integrations. Tasks are broken down into specific activities carried out by specialist profiles, from business analysts to DevOps engineers, ensuring that every component of the system has been validated before moving on to the next stage.

Broadly speaking, the industry-accepted hierarchy of phases is:

1. Information Systems Planning (PSI): aligning the IS with the company's business objectives and analysing the existing technology architecture.
2. Development Cycle:
   1. System Feasibility Study (EVS): analysis of technical, financial and legal risks. This is where you assess whether custom development or a third-party integration makes more sense.
   2. Information System Analysis (ASI): a thorough technical definition of the requirements, including process modelling.
   3. Information System Design (DSI): definition of the software architecture, data model and interface design.
   4. Information System Construction (CSI): coding, unit testing and deployment to staging environments.
   5. System Implementation and Acceptance (IAS): user acceptance testing (UAT), data migration and go-live.
3. Evolutionary and Corrective Maintenance (MSI): managing the system's lifespan, from evolutionary maintenance for housing management to any other sector-specific asset.
4. Closure and Knowledge Capitalisation: final audit, archiving of assets and transfer of know-how.

Which methodology to follow for a simple project without losing rigour

Ideally you would apply MÉTRICA V3 to the letter, but on medium-sized projects or start-up MVPs the administrative overhead can be stifling. Its structure still serves as a basis for identifying the critical milestones. For more dynamic developments, we recommend our guide to agile technical practices in software development, which combines analytical rigour with the pace of modern delivery.

---

A simple software development methodology for 2026

What follows is a pragmatic synthesis for building robust applications. It is especially useful for anyone leading their first technical projects, or for teams that need to bring order to their workflow. For more complex architectures, it is always better to evolve towards approaches such as Scrumban.

0 – Objective Definition and Strategic Vision

The most common and most expensive mistake is to start writing code without being clear about the "why". Defining the objectives is the cornerstone on which every other technical activity hangs. A change of direction halfway through a waterfall project can mean throwing away weeks of work. It is essential to apply the SMART rule so that objectives are specific, measurable, achievable, realistic and time-bound. In 2026, this includes anticipating how applied artificial intelligence can strengthen those objectives.

Bear in mind that a system's complexity grows exponentially with the number of variables and objectives. When building a custom ERP with agile deployments, for example, it is better to meet one critical business need really well than to try to cover every feature in a mediocre way. The vision must be shared by every stakeholder to avoid scope creep.

1 – Identifying System Profiles and Actors

Once the vision is set, we need to identify who or what will interact with the system. In 2026, "users" are not just people; they are often other systems, AI bots or IoT devices integrated into an IoT platform for supply control. Cataloguing these profiles lets you design interfaces and permissions consistently, closing security gaps from the very first minute.

In the Balearic Islands, where the service sector dominates, it is common to find actors ranging from the end customer to external service providers. For complex systems it is vital to define how identity and access management (IAM) will be handled, integrating solutions that allow B2B process automation for the marine and charter sector to be carried out securely.

2 – Catalogue of Functional Requirements by Role

This step is about deciding which features each profile will have. It is the moment to build in advanced security mechanisms to prevent data leaks and to comply with the GDPR and other data protection regulations. The result is the functional requirements catalogue, a technical and legal document that works like the blueprints of a house. Non-functional requirements must not be forgotten either: performance, scalability and maintainability.

This document is the basis for the budget and for resource planning. At Arteco we always insist that the client signs off this catalogue. Anything not in the catalogue does not exist as far as initial planning or cost estimation are concerned. It protects both supplier and client, and confirms that the preliminary technology consulting has done its job and captured the essence of the business.

3 – Data Modelling and Information Entities

With the requirements closed, the technical team can define the data model. For business management applications we still favour relational systems for their consistency. Defining tables, columns and indexes is critical to future performance. If you want to go deeper into this, our SQL tutorial gives you the foundations for building solid structures, complemented by the use of containers in our PostgreSQL tutorial with Docker.

The data model must mirror the functional requirements. Any inconsistency here will turn into costly bugs during construction. In the age of Big Data, it is highly advisable to validate the model against real use cases and to consider whether advanced data analysis techniques will be needed for decision-making.

4 – Defining Business Processes and Flowcharts

Phase 4 is about bringing actions together into logical flows. Knowing what the system does is not enough; you need to know how it does it. Writing processes down as flowcharts or sequences of steps makes it possible to spot bottlenecks and redundancies. For example, when building APIs for textile product sales, stock validation and tax calculation flows are critical and must be fully documented.

At this stage, modelling tools such as BPMN 2.0 are standard practice to make sure business and IT speak the same language. A well-defined process makes it far easier to implement a real-time business rules engine, allowing the logic to change without rewriting the core of the system.

5 – Modularisation and Component Architecture

Breaking down the processes leads us to identify the application's modules. Grouping similar features enables code reuse and efficient integration of third-party libraries. In today's ecosystem, this translates into microservices or well-defined modular systems. Our Spring Boot tutorial will help you understand how to structure these modules to modern standards.

In 2026 we are also seeing widespread adoption of WebAssembly to move heavy logic into the browser. The architecture should also allow for asynchronous communication through message queues if you are aiming for a genuine migration to Spring Cloud and PostgreSQL.

6 – Construction and Technical Development

This is where theory becomes reality. Thanks to the earlier analysis, programming becomes a task that is both mechanical and creative, applying design patterns and SOLID principles. It is essential to make the most of the advantages of programming in Java, given its robustness in corporate environments, and of modern features such as those covered in our introduction to Java lambdas.

In this phase, applying test-driven development (TDD) is non-negotiable. Writing tests before the code ensures every component does its job and lets you refactor safely. The whole process must be managed through rigorous use of Git, following our Git tutorial, to guarantee traceability and team collaboration.

7 – Validation, Integration and E2E Testing

Unit tests are the first level, but not the only one. We need integration tests to certify that our application communicates correctly with databases or external systems such as hotel booking engines. Tools such as Testcontainers are vital here.

Performance cannot be ignored: Java performance tuning and garbage collection is critical before going live. End-to-end (E2E) tests are what ultimately guarantee that users will be able to complete their tasks successfully, simulating real flows from start to finish.

8 – Deployment, Production and Orchestration

Going live in 2026 almost always means using containers. Mastering our Docker tutorial is essential to guarantee parity between environments. We recommend scalable infrastructure and Kubernetes for projects that require high availability and automatic load balancing, integrating agile cloud platforms to maximise resilience.

Deployment should be automated through CI/CD (Continuous Integration / Continuous Deployment) pipelines. This minimises human error and enables frequent releases. Orchestration covers not only the software but also secrets management and dynamic environment configuration.

9 – Evolutionary Maintenance and Technical Debt Management

Maintenance typically accounts for 70% of a software product's total cost of ownership. Ignoring this phase dooms the project to failure. It is vital to set aside banks of hours for enhancements so the system can adapt to new needs. Sometimes the best strategy is to remove legacy code such as Oracle Forms before the system becomes a technical millstone.

Technical debt has to be managed proactively. Regular refactoring and keeping dependencies up to date (as shown in our Maven tutorial) keep the system secure and efficient in the long run.

10 – Project Closure and Technical Asset Management

At the end, the knowledge must be archived. Well-documented code and validated processes are assets that will lower the cost of future developments. Capitalising on know-how is what sets a services company apart from a true software engineering consultancy. This is the moment to check whether we have lived up to our quality policy.

---

MÉTRICA V3 and the Integration of Generative AI (RAG)

In 2026, the Analysis (ASI) and Design (DSI) phases of MÉTRICA V3 have evolved to include the data architecture that AI systems require. Defining a relational schema is no longer enough; we need to plan how the system's data will feed language models to provide conversational interfaces or intelligent assistance. This is where RAG (retrieval-augmented generation) comes in, a data-architecture technique we have applied to AI for the Balearic marine sector that lets the AI query the corporate database in real time to give accurate answers.

This integration has to be planned from Phase 0. Functional requirements (Phase 2) now include the system's "cognitive capabilities". This is not marketing but technical architecture: defining vectors, vector databases and data-cleansing pipelines. MÉTRICA V3 provides the ideal framework to ensure these new components do not become isolated patches but integral parts of the IS.

FinOps and Cloud Governance: Technical Budgeting in the Balearic Islands

Applying rigid methodologies in public cloud environments calls for an extra layer of management: FinOps. In the Balearic Islands, where many start-ups scale quickly but on tight budgets, keeping cloud spending under control is vital. Planning based on MÉTRICA V3 makes it possible to identify, from the design phase onwards, which resources will be the most expensive and to plan FinOps strategies to optimise cloud spend.

Scalability must not be an afterthought. When defining the data model (step 3), we need to consider whether traditional SQL is the right choice or whether the read/write load calls for multi-cloud and edge data synchronisation. A wrong choice of database, or the absence of policies to shut down development resources, can push running costs to unsustainable levels within just a few months. The methodology obliges us to document and approve these costs before construction.

Security by Design: Building in the ENS and GDPR from Planning

Given today's threat landscape, security cannot be a phase tacked on at the end of the project. It has to be built in through a secure development methodology. From the identification of profiles (step 1), we must apply the principle of least privilege. This is especially critical in highly sensitive applications such as building a financial investment platform.

For companies that work with the public sector or in regulated industries, compliance with Spain's National Security Framework (ENS, Esquema Nacional de Seguridad) is a requirement. This means the analysis phase (step 2) must include a formal risk analysis (MAGERIT or similar) and the definition of technical controls that will be validated in the testing phase (step 7). Failing to build this in from the outset is an unacceptable reputational and legal risk, which MÉTRICA V3 helps to mitigate thanks to its emphasis on documentary traceability.

Critical Technical Mistakes in the Move from Waterfall to Agile

Many teams try to mix methodologies without understanding their technical foundations. One of the most serious mistakes is "Water-Scrum-Fall", where analysis is rigid and deployment slow, yet development is supposed to happen in agile sprints. The result is a lack of technical visibility and constant blockers for the development team.

Another common mistake is neglecting technical documentation in the name of a misunderstood "agility". Without a clear design baseline (DSI), code quickly turns into hard-to-maintain legacy riddled with anti-patterns. To avoid this, we recommend following our Javañol practices guide, which sets quality and documentation standards that survive any change of methodology and ensure the system can be maintained by any professional team.

Conclusions

MÉTRICA V3 remains an exceptional compass for navigating the complexity of business software development, provided it is adapted to the technologies and economic realities of 2026. The key to success lies in balancing analytical rigour with the flexibility of modern development tools. Whether for a mobile app for the public sector or a core banking system, the methodology is the guarantee that the final product will be what the business needs.

If you are planning a custom software project in Mallorca, or need to professionalise your internal processes to scale your SaaS, discipline is your best ally. A well-planned architecture today means lower maintenance costs tomorrow. Take a look at our technology consulting section to see how we can help you turn your technical vision into a scalable, profitable architecture.

---

About to start a custom software project? At Arteco we help you plan, document and deliver your development with a proper methodology and engineering rigour. Talk to a specialist →