| Ítem | Observaciones | Ponderación |
|
1
Metodología de trabajo
|
Rango Descripción de lo esperado
0 Metodología difusa o ausente: no detalla herramientas ni pasos.- No menciona análisis estático ni validación de documentación.
40 Describe algunas fases genéricas (“revisión de código”), pero sin herramientas concretas.- Menciona documentación de Caché/Lanchester sin detallar validación.
60 Expone fases (análisis estático, validación Caché, validación Lanchester, documentación), pero con poco detalle de herramientas (solo menciona SonarQube sin justificar).- Cronograma parcial sin hitos claros.
80 Define con claridad cada etapa: análisis con SonarQube y FxCop, validación de diagramas mediante PlantUML, inspección de fórmulas con pruebas unitarias.- Incluye cronograma con hitos (informes intermedios).
100 Metodología integral: especifica herramientas (Roslyn Analyzers, InterSystems Studio para Caché, PlantUML, Dapper/EF Core para migración), procesos de validación cruzada (ej. matriz de trazabilidad), pruebas automatizadas para modelos Lanchester.- Cr
|
16%
|
|
2
Experiencia relevante del equipo
|
Rango Descripción de lo esperado
0 No aporta evidencia de experiencia en C#/.NET 4.5 ni en Caché.- No hay referencias a proyectos de simulación ni migraciones.
40 Menciona experiencia genérica en .NET, pero sin detallar versión 4.5.- Conoce bases de datos relacionales, sin experiencia en Caché.
60 Equipo con experiencia en C# 4.x y .NET Core genérico, pero sin casos concretos de proyectos con Caché ni modelos dinámicos.- Un miembro conoce Lanchester, pero no hay proyectos documentados.
80 Presenta al menos un proyecto de auditoría de código en .NET 4.5 y otro de migración a .NET Core.- Experiencia comprobable en bases Caché (p. ej., migración de globals).- Casos de simulación (modelos basados en ecuaciones diferenciales).
100 Vasta experiencia: múltiples proyectos con .NET 4.5 → .NET 6/7, migraciones de Caché a base de datos relacional open-source elegida (incluyendo ETL), y simulaciones de combate (Lanchester) documentadas.- Referencias sólidas (clientes, resultados) y certificacione
|
16%
|
|
3
Equipo Propuesto
|
Rango Descripción de lo esperado
0 No detalla roles ni experiencia de cada integrante.- Equipo genérico, sin perfil técnico.
40 Indica roles (líder, desarrollador), pero sin especificar años de experiencia ni proyectos previos.- Falta perfil en Caché/ base de datos relacional open-source elegida.
60 Roles definidos con experiencia mínima en C#/.NET y bases de datos relacionales, pero no en Caché
• Años de experiencia específicos (.NET 4.5, Caché, Base de datos relacional).
• Proyectos similares (auditado sistema de simulación, migrado Caché → base de datos relacional open-source propuesta).
• Certificaciones (InterSystems Certificate, Microsoft MVP/.NET). |
|
8%
|
|
4
Consideraciones Legales y de Confidencialidad
|
0 No menciona contratos de confidencialidad ni mecanismos de protección.- No hay plan de eliminación de datos sensibles.
40 Indica que firmarán NDA, pero sin detallar procesos de resguardo ni eliminación segura.- Falta protocolo de acceso a código.
60 Menciona NDA y repositorio privado, pero sin detallar restricciones de acceso (por rol) ni planes de eliminación de backups.
80 Describe NDA para todos los miembros, repositorio Git privado con control de accesos, bitácora de actividades sobre el código.
100 Plan completo de confidencialidad:
• Contratos NDA individuales con cláusulas específicas (propiedad intelectual, no divulgación).
• Entorno de trabajo aislado (VPN, servidores internos sin acceso público).
• Procedimiento de eliminación segura de todos los backups temporales y discos al finalizar proyecto.
• Control y auditoría de accesos (logs detallados, revisiones periódicas).
|
4%
|
|
5
Plazo de Ejecución
|
Rango Descripción de lo esperado
0 - Cronograma ausente o simplemente menciona “X semanas” sin desglose.- No cubre validación ni documentación.
40 - Cronograma somero (por ejemplo, “1 mes para análisis, 1 mes para documentación”) sin hitos intermedios ni fechas específicas.
80 - Incluye fases (análisis, validación, documentación) con fechas aproximadas, pero no hitos de entrega intermedios (solo final).
100 - Cronograma detallado por semanas:
• S1–S2: revisión de código y documentación.
• S3–S4: validación Caché/Lanchester.
• S5–S6: generación de diagramas UML y mapeos.
• S7–S8: elaboración de scripts y manual de despliegue.- Sin márgenes de contingencia ni revisiones formales con el cliente.
| 81 – 100| - Cronograma con:
• Semanas y fechas exactas (ej. 01/07–14/07)
• Hitos intermedios claramente definidos (entrega informe preliminar, entrega diagramas, prueba de migración POC).
• Buffer de 1–2 semanas para imprevistos.
• Fechas de revisión conjunta con el cliente.
|
8%
|
|
6
Oferta Económica
|
Para este criterio, el puntaje (0–100) se calcula en función de la Oferta Mínima detectada entre todos los oferentes:
Identificar Oferta Mínima
– Sea P_min el menor monto ofertado.
Calcular Relación para cada Oferente
– Si un oferente propone P_x, entonces
Relación=P_min/P_x (valor entre 0 y 1)
Asignar Puntaje Económico (0–100)
Puntaje económico=(Relación) x 100.
– El oferente con P_x=P_min obtiene puntaje 100.
– Cualquier otro recibe un puntaje proporcional.
No se usan rangos discretos (0–20, 21–40, …) sino esta fórmula directa, que genera un puntaje real de 0 a 100.
Cálculo del Puntaje Final
Asignar puntajes (0–100) para cada criterio 1–7 según los rangos descriptivos anteriores.
Calcular puntaje económico (0–100) con la fórmula:
Puntaje económico=(P_min/P_x ) x 100
Obtener puntaje ponderado para cada criterio i:
〖Ponderado〗_i=(〖Puntaje〗_i x 〖Peso〗_i)/100
Se sumarán los ocho ponderados para obtener el Puntaje Final (sobre 100).
Se ordenarán las propuestas de mayor a men
|
20%
|
|
7
Comprensión del proyecto y los activos
|
Rango Descripción de lo esperado
0 No evidencia conocimiento del alcance: confunde objetivos.- No reconoce los activos entregados (código, documentación).
40 Entiende parcialmente el objetivo (análisis vs. ingeniería inversa).- Menciona activos, pero sin detalle de uso.
60 Describe correctamente el alcance general: análisis, validación y documentación.- Reconoce los activos (código, Caché, Lanchester) pero sin profundizar en cómo aprovecharlos.
80 Explica con claridad el enfoque (análisis estático, validación de documentación, generación de nuevos artefactos).- Detalla brevemente cómo utilizarán código y documentos existentes.
100 Presenta una comprensión profunda: diferencia análisis de “ingeniería inversa”, identifica riesgos (compatibilidad .NET 4.5, complejidad de Caché).- Explica exactamente cómo extraerán valor del código fuente y documentación actual.
|
16%
|
|
8
Calidad y Detalle de los Entregable
|
Rango Descripción de lo esperado
0 Entregables poco claros, sin formato estandarizado.- Diagramas faltan detalle o carecen de notación UML.
40 Documentos superficiales; algunos diagramas actualizados, pero sin indicaciones de migración.- Descripciones parciales de módulos.
60 Entregables completos (documentación, diagramas), pero con escasa trazabilidad entre teoría, código y base de datos.- Faltan notas de migración y detalles técnicos.
80 Documentación bien organizada: diagramas UML (componentes, clases), manual de despliegue actual y propuesto.- Incluye mapeos de tipos de datos Caché → base de datos relacional open-source elegida, pero con ejemplos limitados.
100 Entregables exhaustivos y pulidos:
• Diagrama de arquitectura (estado actual y futuro) con PlantUML.
• Mapeo matemático–código–base de datos–migración en formato tabla.
• Scripts SQL para base de datos relacional open-source elegida y ejemplos de refactorización a .NET Core.
• Manual de despliegue en ambos entornos.
• Índi
|
12%
|