Calculadora KLOC: líneas de código y esfuerzo COCOMO🌎
Actualizado junio de 2026Ver cálculo paso a paso
La calculadora de KLOC (Kilo Lines of Code) te convierte la cantidad total de líneas de código fuente de tu proyecto a miles de líneas (KLOC = LOC ÷ 1000) y estima el esfuerzo de desarrollo usando el modelo COCOMO I básico de Barry Boehm (1981). Para proyectos orgánicos (equipos pequeños, dominio conocido) la fórmula es Esfuerzo = 2,4 × KLOC^1,05, expresado en meses·persona. Usás esta métrica para comparar tamaños de bases de código, justificar recursos ante un cliente o aplicar modelos de estimación estándar de la industria.
Cuándo usar esta calculadora
- Estimar cuántos meses·persona llevará desarrollar un sistema de gestión empresarial de 80 KLOC antes de presentar el presupuesto al cliente.
- Clasificar una base de código heredada (legacy) para decidir si conviene refactorizarla o reescribirla desde cero, usando la categoría de complejidad.
- Comparar la productividad de dos equipos de desarrollo midiendo cuántos KLOC entregaron por sprint en proyectos del mismo rango de tamaño.
- Aplicar la métrica KLOC como insumo para modelos de estimación de defectos: la industria reporta entre 1 y 25 bugs por KLOC según el tipo de proyecto.
Ejemplo: sistema de e-commerce (50 000 LOC)
- Líneas de código (LOC): 50 000
- KLOC = 50 000 ÷ 1 000 = 50 KLOC
- Categoría: Enterprise / Grande
- Esfuerzo COCOMO (orgánico) = 2,4 × 50^1,05 = 2,4 × 63,4 ≈ 152 PM
- Con un equipo de 8 personas: 152 ÷ 8 ≈ 19 meses de calendario
Cómo funciona
4 min de lecturaCómo se calculan KLOC y el esfuerzo COCOMO
Paso 1 — Convertir LOC a KLOC
KLOC = LOC ÷ 1 000
Ejemplo: 50 000 LOC ÷ 1 000 = 50 KLOCPaso 2 — Estimar esfuerzo con COCOMO I básico
El modelo COCOMO I básico de Barry Boehm (1981) tiene tres modos según el tipo de proyecto:
Modo Orgánico → Esfuerzo = 2,4 × KLOC^1,05 (equipos pequeños, dominio conocido)
Modo Semi-acoplado → Esfuerzo = 3,0 × KLOC^1,12 (sistemas intermedios mixtos)
Modo Embebido → Esfuerzo = 3,6 × KLOC^1,20 (tiempo real, restricciones duras)
Tiempo calendario = 2,5 × Esfuerzo^0,38 (meses, independiente del equipo)El resultado es en meses·persona (PM) — la suma del trabajo de todos los integrantes.
---
Tabla de referencia por tamaño de proyecto
| LOC | KLOC | Categoría | Esfuerzo orgánico | Tiempo calendario (equipo 4) | Ejemplos reales |
|---|---|---|---|---|---|
| 500 | 0,5 | Script / Trivial | ~1 PM | ~0,3 meses | Script de automatización, CLI simple |
| 2 000 | 2 | App pequeña | ~5 PM | ~1,3 meses | App mobile MVP, bot de Telegram |
| 5 000 | 5 | App pequeña-mediana | ~14 PM | ~3,4 meses | Microservicio, API REST simple |
| 10 000 | 10 | Aplicación mediana | ~26 PM | ~6,4 meses | CRM básico, sistema de facturación |
| 30 000 | 30 | Grande | ~84 PM | ~13,5 meses | Plataforma e-commerce, ERP pequeño |
| 50 000 | 50 | Enterprise | ~152 PM | ~19 meses | ERP mediano, plataforma SaaS |
| 100 000 | 100 | Enterprise grande | ~330 PM | ~29 meses | Suite ERP, sistema bancario regional |
| 500 000 | 500 | Muy grande | ~2 050 PM | ~62 meses | OS embebido, suite ofimática |
| 1 000 000+ | 1 000+ | Masivo | > 4 300 PM | > 88 meses | Kernel Linux (27 000 KLOC), Windows |
> Nota de densidad de bugs: proyectos sin testing intensivo: 15–50 defectos/KLOC durante el desarrollo; software comercial en producción: 1–7 bugs/KLOC; software de alta confiabilidad (aeronáutico/médico): < 0,1 bugs/KLOC. (Fuente: Capers Jones, Applied Software Measurement, 3ª ed., 2008.)
---
Casos de uso con números reales
Caso 1 — Sistema de gestión de turnos (8 500 LOC)
KLOC = 8 500 ÷ 1 000 = 8,5 KLOC → Categoría: Mediano
Esfuerzo (orgánico) = 2,4 × 8,5^1,05 ≈ 2,4 × 9,54 ≈ 22,9 PM
Tiempo calendario = 2,5 × 22,9^0,38 ≈ 2,5 × 3,97 ≈ 9,9 mesesUn equipo de 3 personas lo entrega en aproximadamente 10 meses.
Caso 2 — Plataforma e-commerce (50 000 LOC)
KLOC = 50 000 ÷ 1 000 = 50 KLOC → Categoría: Enterprise
Esfuerzo (semi-acoplado) = 3,0 × 50^1,12 ≈ 3,0 × 84,4 ≈ 253 PM
Tiempo calendario = 2,5 × 253^0,38 ≈ 2,5 × 8,0 ≈ 20 mesesCon un equipo de 12 personas, el plazo estimado es ~21 meses.
Caso 3 — Microservicio de autenticación (1 200 LOC)
KLOC = 1 200 ÷ 1 000 = 1,2 KLOC → Categoría: Script/App pequeña
Esfuerzo (orgánico) = 2,4 × 1,2^1,05 ≈ 2,4 × 1,22 ≈ 2,9 PM
Tiempo calendario = 2,5 × 2,9^0,38 ≈ 2,5 × 1,65 ≈ 4,1 mesesUn desarrollador senior puede entregarlo en ~4 meses trabajando en paralelo con otras tareas.
---
Errores comunes al medir KLOC
1. Contar líneas en blanco y comentarios: KLOC debe medirse sobre líneas de código fuente lógicas (SLOC), excluyendo comentarios y líneas vacías. Incluirlas infla el número hasta un 30 % y sobrestima el esfuerzo.
2. Usar el mismo modo COCOMO para todo: aplicar el modo Orgánico a un sistema embebido subestima el esfuerzo real en un factor de 2× a 3×.
3. Equiparar LOC entre lenguajes: según Capers Jones, Python necesita ~5× menos líneas que C para la misma funcionalidad. Para comparaciones entre lenguajes, usá puntos de función (Function Points) o normalizá a un lenguaje de referencia.
4. Ignorar código auto-generado: los frameworks modernos generan miles de líneas de scaffolding que deben excluirse o marcarse por separado.
5. Tomar COCOMO como cifra contractual: el modelo da un margen de error del ±20 % para proyectos bien caracterizados y hasta ±50 % en fases tempranas.
Preguntas frecuentes
¿Qué es KLOC y cómo se diferencia de LOC?
LOC (Lines of Code) es la cantidad absoluta de líneas de código fuente. KLOC es simplemente LOC ÷ 1000, una unidad de escala para manejar proyectos grandes sin números de seis cifras. Por ejemplo, 75 000 LOC = 75 KLOC. También existe MLOC (millones de líneas): el kernel de Linux supera los 27 MLOC.
¿Qué es COCOMO y para qué sirve?
COCOMO (Constructive Cost Model) es un modelo de estimación de esfuerzo de software creado por Barry Boehm en 1981. Dado el tamaño del proyecto en KLOC, calcula cuántos meses·persona se necesitan para desarrollarlo. Es el estándar académico más citado para estimación de proyectos de software y sirve para presentar presupuestos y planificar equipos antes de iniciar el desarrollo.
¿Cuántas líneas de código tiene un proyecto típico?
Como referencia: un script de automatización tiene < 1 KLOC; una app mobile MVP, 2–10 KLOC; un sistema ERP pequeño, 30–100 KLOC; el kernel de Linux supera 27 000 KLOC; el código fuente de Windows se estima en más de 50 000 KLOC. Un proyecto 'mediano' en el ámbito empresarial típicamente está entre 10 y 50 KLOC.
¿El modelo COCOMO sigue siendo válido en 2026 con metodologías ágiles?
COCOMO I (1981) y COCOMO II (2000) siguen siendo referencias de benchmarking, pero no reemplazan la planificación ágil por sprints. Su valor actual es orientativo: te da un orden de magnitud del esfuerzo total antes de descomponer en historias de usuario. Para proyectos ágiles, muchos equipos usan COCOMO II con los factores de escala del USC COCOMO II Model Definition Manual (University of Southern California, 2000).
¿Cómo afecta el lenguaje de programación a la métrica KLOC?
Significativamente. Según la tabla de niveles de lenguajes de Capers Jones, para implementar la misma funcionalidad necesitás aproximadamente: Assembler 320 LOC, C 128 LOC, Java 53 LOC, Python 32 LOC, SQL 12 LOC. Comparar KLOC entre lenguajes sin normalizar lleva a conclusiones erróneas sobre productividad o complejidad. La alternativa es usar Puntos de Función (Function Points) que son agnósticos al lenguaje.
¿Qué herramientas se usan para contar KLOC en proyectos reales?
Las herramientas más usadas son: cloc (Count Lines of Code, open source, disponible en GitHub), SonarQube (análisis estático con dashboard de métricas, muy usado en empresas), tokei (alternativa en Rust, muy rápida), y SLOCCOUNT de David Wheeler. Todas excluyen comentarios y líneas en blanco por defecto, dando el SLOC real.
¿Cuál es la densidad de bugs esperada según el tamaño del proyecto?
La industria reporta: software sin testing intensivo, 15–50 defectos/KLOC durante el desarrollo; software comercial lanzado al mercado, 1–7 bugs/KLOC; software de alta confiabilidad (aeronáutico, médico), < 0,1 bugs/KLOC. (Fuente: Capers Jones, Applied Software Measurement, 3ª edición, 2008.) Estos números empeoran significativamente si no se hacen code reviews ni tests automatizados.
¿Por qué hay diferencia entre el esfuerzo (PM) y el tiempo calendario?
Porque el esfuerzo total en meses·persona se distribuye entre los miembros del equipo, pero no de forma perfectamente lineal. La Ley de Brooks indica que agregar más personas a un proyecto tarde lo retrasa, no lo acelera. COCOMO separa ambas cosas: el esfuerzo total puede ser 100 PM, pero con 10 personas el calendario no baja a 10 meses por el overhead de coordinación, revisiones y dependencias entre tareas.
¿Qué diferencia hay entre COCOMO orgánico, semi-acoplado y embebido?
Los tres modos reflejan la complejidad del entorno: Orgánico (coef. 2,4) es para equipos pequeños con experiencia en el dominio y poca rigidez en los requerimientos — la mayoría de las apps empresariales entran aquí. Semi-acoplado (coef. 3,0) aplica a proyectos más grandes con partes del equipo sin experiencia previa en el dominio. Embebido (coef. 3,6) es para sistemas con restricciones duras de hardware, tiempo real o normativa estricta (firmware médico, aviación, fintech regulado).
Fuentes y referencias
También te puede interesar
Metodología y confianza
Contenido revisado por el equipo editorial de Hacé Cuentas, con apego a nuestra política editorial y metodología de cálculo.
Última revisión: 03 de junio de 2026. Los parámetros fiscales, legales y datos se verifican periódicamente con las fuentes citadas.
Los cálculos corren 100% en tu navegador. No guardamos ni transmitimos tus datos. Leé nuestra política de privacidad.
Resultados orientativos. Para decisiones financieras, médicas o legales críticas, consultá con un profesional.