Skip to main content

Contexto y Alcance

1. Propósito del procedimiento

Establecer el procedimiento estándar para la creación de nuevos proyectos de software (Aplicaciones o APIs/Servicios) en el área de desarrollo. Este procedimiento permite asegurar que cada proyecto queda correctamente registrado, identificado y inicializado antes de comenzar su desarrollo técnico.

El objetivo principal es mejorar la trazabilidad, estandarizar el arranque de proyectos y reducir ambigüedades en la fase inicial.

2. Alcance del procedimiento

Este procedimiento aplica únicamente al desarrollo de software del área, en los siguientes casos:

  • Desarrollo de Aplicaciones
  • Desarrollo de APIs/Servicios

No aplica a prototipos, experimentos, pruebas de concepto ni a proyectos fuera del área de desarrollo.

3. Tipos de proyectos contemplados

3.1 Aplicaciones

Corresponden a sistemas con componentes UI (frontend) y backend, normalmente orientados a usuarios internos o externos.

3.2 APIs/Servicios

Corresponden a sistemas sin interfaz visual, orientados a exposición de servicios, integración con terceros o consumo interno.

4. Roles involucrados en la fase inicial

Durante la fase de creación del proyecto intervienen los siguientes roles:

  • Líder de Proyecto: responsable de iniciar el registro, asignar el nombre corto y seleccionar el template base.
  • Jefe de Área: responsable de validar y autorizar la creación del proyecto cuando corresponda.

No se contempla participación de QA, usuarios funcionales o equipo de DevOps en esta fase.

5. Nomenclatura de identificación del proyecto

Cada proyecto se identifica mediante un ID interno con la siguiente estructura:

Año-Consecutivo-Tipo-NombreCorto

Donde:

  • Año: año de creación del proyecto (generalmente coincide con el año de solicitud).
  • Consecutivo: número incremental que se reinicia cada año (ejemplo: `0001`).
  • Tipo: categoría del proyecto. Especialmente cuando son servicios o apis.
  • NombreCorto: identificador del proyecto en formato PascalCase.

Ejemplos por tipo:

  • Aplicaciones:
    • 2026-0001-SeguimientoBecarios
  • APIs/Servicios:
    • 2026-0001-Srv-NominaVehicular
    • 2026-0002-Srv-PagosCentral

6. Convención sobre el NombreCorto

El campo NombreCorto debe cumplir:

  • Formato PascalCase
  • Representar el nombre lógico del sistema
  • Evitar acentos, espacios y caracteres especiales
  • Mantener consistencia respecto al dominio funcional del sistema

Ejemplo de conversión:

  • Nombre funcional: Sistema de Seguimiento de Becarios
  • NombreCorto: SeguimientoBecarios

7. Responsable del registro

El registro del proyecto en la hoja de control administrativa es responsabilidad del Líder de Proyecto.

Este registro debe realizarse antes de crear el repositorio y antes de iniciar cualquier actividad técnica.

8. Reinicio del consecutivo por año

El consecutivo interno se resetea cada año. Ejemplo:

  • Año 2026 → inicia en `2026-0001`
  • Año 2027 → inicia en `2027-0001`

9. Objetivo técnico de esta etapa

Al finalizar esta etapa el proyecto tiene:

  1. Identificador único asignado
  2. Tipo definido (Aplicación o API/Servicio)
  3. NombreCorto definido
  4. Año y consecutivo asignado
  5. Responsable técnico asignado

Este es el estado mínimo requerido para pasar a la etapa de inicialización técnica.

10. Convención para nombres de repositorios y contenedores

Para mantener la trazabilidad entre el registro administrativo y los artefactos técnicos, se establece la siguiente convención:

  • El nombre del repositorio Git en GitHub debe ser exactamente igual al ID del proyecto.
  • El nombre del contenedor Docker también debe ser exactamente igual al ID del proyecto.

Es decir, se reutiliza el mismo identificador en los tres niveles:

  1. Registro administrativo (hoja de control)
  2. Repositorio de código fuente
  3. Contenedor en la plataforma de ejecución

10.1 Ejemplos

Aplicación

  • ID: `2026-0001-AplicacionSeguimientoBecarios`
  • Repositorio GitHub: `2026-0001-AplicacionSeguimientoBecarios`
  • Nombre de contenedor Docker: `2026-0001-AplicacionSeguimientoBecarios`

API/Servicio

  • ID: `2026-0002-Srv-PagosCentral`
  • Repositorio GitHub: `2026-0002-Srv-PagosCentral`
  • Nombre de contenedor Docker: `2026-0002-Srv-PagosCentral`

10.2 Consideraciones

  • El ID no debe alterarse ni abreviarse al crear el repositorio o el contenedor.
  • Si un desarrollador decide clonar el repositorio en una carpeta local con otro nombre, esto no afecta la convención oficial, pero se recomienda mantener el mismo nombre para evitar confusiones.
  • Cualquier automatización futura (scripts internos, n8n, herramientas de generación de proyectos, etc.) debe asumir que el ID es la fuente de verdad para nombrar repositorios y contenedores.
Back to top