Saltar al contenido principal

Buscar en Expertiot

/ abrir · Esc cerrar

Trazabilidad técnica y defensa documental para proyectos IoT y software

Cuándo el componente IoT, software embebido o industrial es elegible como I+D+i, y cómo defenderlo frente a la evaluación.

Cuándo es elegible un desarrollo software como I+D+i

La pregunta nuclear no es “¿qué tecnología usa?”, sino “¿qué incertidumbre tecnológica resolvió?”. Un desarrollo de software es elegible como I+D+i cuando:

  • Existe novedad objetiva frente al estado del arte público disponible.
  • Hubo incertidumbre tecnológica que requirió experimentación, no diseño deductivo.
  • La trazabilidad del proceso de resolución técnica es documentable.

El uso de un stack moderno, un framework reciente o una arquitectura cloud no califica automáticamente: lo califica la resolución de problemas técnicos concretos en su contexto de aplicación.

IoT industrial: combinación de códigos UNESCO

Los proyectos IoT industriales suelen combinar varios códigos UNESCO:

  • 1203 Ciencia de los Ordenadores — algoritmia, IA, tratamiento de datos y sistemas de información.
  • 3304 Tecnología de los Ordenadores — arquitectura, sistemas en tiempo real y software embebido sobre hardware propio.
  • 3311 Tecnología de la Instrumentación — sensorización, métrica, calibración.
  • 3310 Tecnología Industrial — integración con procesos productivos.

La elección entre 1203 y 3304 no es cosmética: determina qué evaluador se asigna al expediente, y conviene justificarla en la memoria.

La defensa técnica debe articular cómo el sistema en conjunto aporta novedad, no atomizar cada componente.

Apoyo de Expertiot

  • Trazabilidad técnica de desarrollos: mapa de decisiones de arquitectura, ramas, ensayos comparativos, log de experimentación.
  • Identificación de incertidumbres tecnológicas resueltas desde un enfoque experimental, no documental cosmético.
  • Defensa documental ante evaluación bajo UNE 166.001 y peticiones de aclaración del Experto Técnico.
  • Criterio sobre el alcance elegible vs no elegible — qué partes del desarrollo soportan la calificación y cuáles no.

Preguntas frecuentes

¿Cuándo es elegible un desarrollo software como I+D+i?

Cuando hay novedad técnica objetiva (no se reduce a aplicar tecnología existente) e incertidumbre tecnológica resuelta (problemas que requirieron experimentación o arquitectura no estándar). El simple uso de stacks modernos o frameworks no es elegible per se; lo es la resolución de problemas técnicos no triviales en su contexto de aplicación.

¿Y un desarrollo IoT industrial?

Los proyectos IoT industriales combinan típicamente 1203 o 3304 —según pese más la algoritmia o la arquitectura embebida— con 3311 (Tecnología de la Instrumentación) o 3310 (Tecnología Industrial). La elegibilidad pasa por documentar la novedad en el conjunto sensores+procesado+integración, no en cada componente por separado.

¿Qué documentación pide un evaluador para defender un proyecto software?

Arquitectura técnica con justificación de decisiones, log de incertidumbres y experimentación, ramas/branches del control de versiones que evidencien iteración técnica, ensayos y benchmarks comparativos, diferencias frente al estado del arte. La memoria debe explicar qué se intentó, qué falló y qué se acabó adoptando.

¿Vale el código fuente como evidencia?

El código fuente es evidencia complementaria, no nuclear. Lo nuclear es la trazabilidad de la decisión técnica: por qué se eligió esa arquitectura, qué alternativas se descartaron y por qué, qué problemas concretos se resolvieron. El código sin contexto no defiende; el contexto técnico bien documentado sí.

¿Tienes un expediente que necesita criterio técnico?