F136 - tech blog

Logo

A simple blog in the complex world of healthcare telematics.

Visit us:

29 September 2026

Modernizing Legacy Software with ISO/IEC 25010 and AI

by Zhenwu Duan, reading time: 13 mins

Modernizing Legacy Software with ISO/IEC 25010 and AI

1. Introduction

Software quality is difficult to assess without a clear framework. For many teams, especially those working with older systems, quality problems remain hidden behind urgent bug fixes, tactical patches, and years of feature-driven development. Over time, redundant code, outdated dependencies, missing tests, and legacy technologies can accumulate until the system becomes harder to evolve and harder to trust.

This is where ISO/IEC 25010 becomes useful. It is a standard published by the International Organization for Standardization (ISO) and belongs to the broader ISO/IEC 25000 SQuaRE family. It gives teams a structured way to evaluate software quality and to discuss software quality in a common, objective language.

The standard becomes even more useful when combined with AI. Instead of relying solely on manual review, we can create reusable evaluation skills and prompts that assess a project consistently. This allows us to generate an initial quality score, identify the main pain points, and use these findings to create a modernization plan.

ISO/IEC 25010 has been published in two editions relevant to this discussion: the original 2011 edition and the revised 2023 edition. The 2023 edition is the more current reference for modern software, while the 2011 edition remains valuable for continuity and historical comparison. For teams evaluating new or modernized systems, the 2023 edition is usually the better choice.

2. What ISO/IEC 25010 Is and What It Does

ISO/IEC 25010 is a quality model. It does not prescribe specific implementation patterns or force a single technology stack. Instead, it defines dimensions of software quality that organizations can use to assess products and systems in a structured way.

The most common quality characteristics include:

It also includes quality-in-use characteristics such as:

This structure is important because software quality is not only about whether the code compiles or the system runs. It is also about whether the system meets user needs, behaves safely in production, remains maintainable, and can evolve over time.

3. AI Support for Evaluation Based on ISO/IEC 25010

With AI, the evaluation process becomes faster and more repeatable. Instead of manually reviewing large codebases in an ad hoc way, a team can define a reusable evaluation skill that follows the ISO/IEC 25010 model.

3.1. A Typical AI-Based Evaluation Workflow Looks Like This:

  1. Create a reusable evaluation skill for the project or project family.
  2. Provide a prompt that asks the AI to assess the project using ISO/IEC 25010.
  3. Collect evidence from requirements, code, tests, architecture, deployments, monitoring, and user feedback.
  4. Score each quality characteristic from 1 to 5.
  5. Identify weaknesses, missing evidence, and the main risks.
  6. Produce a prioritized modernization plan and a follow-up evaluation strategy.

In practice, each quality characteristic in ISO/IEC 25010 can be represented by a dedicated skill. Such a skill acts as a bridge between the abstract quality model and the concrete project context. The AI can then apply the same assessment logic consistently across different projects, libraries, and components, which improves comparability and makes reuse much easier.

3.2. An Example Skill

Let’s take a look at the requirement “Maintainability Reviewer: Assess analyzability, modifiability, stability, testability, and reusability. Review architecture, code structure, tests, and technical debt. Identify changes that are hard or risky to make.” The skill for this requirement is shown below:

“ISO25010-Maintainability

Purpose: Evidence-based assessment of a project’s maintainability according to ISO/IEC 25010. Act as a senior software quality assessor according to ISO/IEC 25010. Evaluate only the maintainability of this project.

Focus:

  • Analyzability
  • Changeability
  • Modularity
  • Reusability
  • Testability
  • Technical debt In particular, assess:
  • Architecture and responsibilities
  • Code structure and coupling
  • Duplication and reuse
  • Tests, test coverage, and testability
  • Documentation and understandability
  • Dependency management and update capability
  • Complexity, hotspots, and maintenance risks

Use only reliable evidence from code, architecture, documentation, CI/CD, tests, build configuration, dependencies, and known runtime/operational artifacts. Strictly separate observations, derived risks, and recommendations. Do not invent project details; if evidence is missing, state this explicitly and mark the assessment as provisional.

Assessment rules:

  • Assign a score from 1 to 5
  • Describe strengths and weaknesses
  • Provide concrete evidence for each statement
  • Derive technical debt only from verifiable indicators
  • Make modernization recommendations that are prioritized and actionable

Output format:

  1. Executive summary
    • Overall maintainability assessment
    • Maintenance risk: low / medium / high
    • Main justification
  2. Assessment by sub-characteristic For each of the six sub-characteristics:
    • Score
    • Status: strong / medium / weak
    • Evidence
    • Risks
    • Measures
  3. Technical debt
    • Recognizable debt drivers
    • Affected areas
    • Estimated modernization pressure
  4. Prioritized recommendations
    • Top 5 measures
    • Expected benefit
    • Priority
  5. Conclusion
    • Confidence level of the assessment
    • Whether the project appears more modern, stable, or legacy

Additional rules:

  • No blanket statements without evidence
  • No mixing of observation and evaluation
  • Do not overrate individual metrics without context
  • If context is missing, explicitly mark the uncertainty

Short form: structured, traceable, evidence-based, with clear prioritization.

File output: After the assessment is complete, write the complete result unchanged in a Markdown file named ISO25010-Maintainability-Evaluation-<ProjectName>-<DD.MM.YYYY-HH-MM>.md.

This is valuable because it creates a stable evaluation method that can be reused across similar projects. The same skill can be applied to different services, libraries, or project components, making assessments more consistent and easier to compare.

3.3. Scoring a Software System

After an AI-assisted evaluation, each quality characteristic is assigned a score, the main weaknesses are identified, and a prioritized modernization plan is derived. This creates a transparent baseline for the current state of the system and makes quality issues visible in a structured, comparable way. The plan can then be executed in a controlled manner, and the system can be re-evaluated to confirm whether the modernization work has actually improved software quality.

Scoring rubric:

3.4. An Example of an Evaluation Result Using the Maintainability Skill Is Shown Below:

ISO25010 Maintainability -ProjectName–28.08.2026-11-10

Executive Summary

  • Overall maintainability assessment: medium
  • Maintenance risk: medium
  • Main justification: The project is clearly structured, well tested, and built with Java 17 and Spring Boot. Weaknesses include the concentration of business logic in Processor.java and the lack of a technical debt strategy.

Assessment by Sub-characteristic

Analyzability — Score 3, Status: medium

  • Evidence: README.md and classes such as AppController, UserService, Processor, and Parser show clear responsibilities.
  • Risks: XML and schema rules are complex and concentrated in a small number of classes.
  • Measures: Document critical rules and extract them into dedicated components.

Modifiability — Score 3, Status: medium

  • Evidence: pom.xml uses Spring Boot 3.4.13, Java 17, JaCoCo, and Spotless; many tests are present.
  • Risks: Processor.java combines XML detection, filtering, parsing, validation, and CSV export.
  • Measures: Split the processing logic into services and adapters.

Modularity — Score 3, Status: medium

  • Evidence: A layered structure (app, process, utils, model) is present.
  • Risks: Business logic and I/O are not fully separated.
  • Measures: Introduce interfaces for parser, export, and validation services.

Testability — Score 4, Status: strong

  • Evidence: Maven tests completed successfully; the repository includes JUnit 5, Testcontainers, JaCoCo, and many unit and integration tests.
  • Risks: Some tests are tightly coupled to specific files and paths.
  • Measures: Add a test matrix covering XML variants.

Technical Debt — Score 3, Status: medium

  • Evidence: Processor.java shows signs of long, complex methods with multiple responsibilities.
  • Risks: Changes to XML and schema rules may increase modification risk.
  • Measures: Prioritize a refactoring roadmap and a review of code hotspots.

Technical Debt

  • Debt drivers: XML and schema logic, local path handling, and centralized CSV export logic
  • Affected areas: Processor.java, Parser.java, UserService.java
  • Estimated modernization pressure: medium

Prioritized Recommendations

  1. Split Processor.java into smaller services (high)
  2. Cover critical XML rules with a test matrix (high)
  3. Consolidate CI checks for refactoring and code quality (medium)
  4. Simplify domain and error hierarchies (medium)
  5. Add architecture documentation for the export workflow (medium)

Conclusion

  • Confidence level: medium
  • Assessment: The project is well tested and understandable, but its core business logic has enough legacy characteristics to warrant targeted modernization.

4. Generation of AI Skills and System Analysis

A reusable skill is helpful because it turns evaluation into a repeatable process. It standardizes the criteria and improves comparability. Instead of each review depending on the reviewer’s background or memory, the AI applies the same logic across projects.

This is especially useful for large systems made up of many subprojects and internal libraries. In such environments, a project may appear stable from the outside while still containing multiple hidden quality problems. The AI can help reveal those issues by systematically checking:

The result is a score-based quality assessment, not just a generic opinion. This gives technical leadership something concrete to work with: a prioritized list of pain points and a measurable baseline.

A set of ten skills is created to cover the main quality characteristics defined in ISO/IEC 25010. These skills are stored in a shared repository and committed to GitLab so they can be reused across projects. Because they are generic and technology-neutral, they can be applied to different software systems and adapted to the specific context of each project.

The evaluation skill set is designed to be reusable, neutral, and project-independent. It does not encode a specific application domain or technology stack, which makes it suitable for many software systems and helps ensure consistent, repeatable assessments over time.

5. Experience: Modernization of a Large Legacy Software System in the Smart Card Team

The need for this kind of evaluation becomes very clear in legacy systems. In many organizations, older software systems continue operating for years and are extended through patches, bug fixes, and incremental features. These systems still deliver business value, but they may no longer have a coherent modernization strategy.

In our case, the system consisted of three active projects, three projects that had been inactive for a long time, and more than ten internal libraries developed over the past decade. It was built on older technology and evolved continuously through many extensions and fixes. There was no consistent modernization effort across the whole platform. As a result, the system accumulated:

From the outside, the system still worked. But from a quality perspective, it was far from healthy.

This is exactly where ISO/IEC 25010 becomes valuable. It helped us move from an informal, intuition-based discussion to a structured quality assessment. We could identify which characteristics were weak and where the biggest risks were. The evaluation helped us see the real pain points: maintainability, security, dependency health, and long-term evolvability.

With the help of AI, we could run this assessment faster and more consistently. A reusable AI skill based on ISO/IEC 25010 evaluated each project and library, reviewed architecture, tests, dependencies, deployment, and operational evidence, and produced a score for each quality characteristic. This provided a common language for engineers and management alike.

The next step was not a large reimplementation. Instead, we focused on the main pain points. We replaced outdated technology with modern alternatives, reduced redundant logic, improved test coverage, updated dependencies, and addressed the most critical security exposures. The goal was not to rewrite everything at once, but to improve the core weaknesses with minimal disruption to ongoing delivery.

After this modernization effort, we evaluated the system again using the same ISO/IEC 25010-based skill. The score improved substantially. This was important because it showed not only that the code had been cleaned up, but that the modernization work had actually improved system quality in a measurable way.

The result was a revitalized system with better maintainability, a stronger security posture, cleaner dependencies, stronger tests, and clearer room for future development. Most importantly, this happened without interrupting delivery to end users.

6. Why This Approach Is Valuable

This approach is useful because it combines standards, AI, and practical modernization work in a disciplined loop:

  1. Evaluate the current system. (AI-assisted)
  2. Identify the main quality gaps. (AI-assisted)
  3. Plan targeted modernization work.
  4. Replace old technology and clean up the pain points.
  5. Re-evaluate the system. (AI-assisted)
  6. Repeat the process for the next priority area.

This is a much safer and more effective path than trying to modernize everything at once or making changes based only on gut feeling. With AI and ISO/IEC 25010, we can move faster, identify the real issues, and create a modernization roadmap that is grounded in evidence.

Evaluation and Modernization Flow

ISO/IEC 25010 evaluation and modernization flow

7. Conclusion

ISO/IEC 25010 provides a strong foundation for evaluating software quality in a structured and objective way. The 2011 edition remains important as a classic reference, while the 2023 edition is increasingly relevant for modern systems and current engineering practice.

When combined with AI, the standard becomes much more actionable. A reusable skill can evaluate an old software system quickly, score each quality characteristic, identify the major pain points, and help shape a realistic modernization plan. This is especially valuable for large legacy systems where the challenge is not only technical debt, but also the risk of continuing to evolve without a clear view of the system’s actual health.

In practice, the benefit is significant: we can evaluate early, focus on the biggest gaps, modernize in controlled steps, and then evaluate again to confirm real improvement. That is how an old system can regain momentum without interrupting business delivery.

About The Author

Zhenwu Duan is responsible in the Smartcard team for the development and maintenance of test tools. His interests include various programming languages such as Java, Go, C#, TypeScript, as well as system testing and PKI technology.