1. No category

3476
IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 10, OCTOBER 2015
Representation Of CMMI-DEV Practices In The
Semat Kernel
C. M. Zapata, J. Valderrama and L. D. Jiménez
Abstract— CMMI-DEV model framework includes a set of
practices for developing products and services. CMMI-DEV
Graphical representations exhibit a general composition of the
model structure, the component hierarchy and eventually the
obligatory nature the model elements. However, CMMI-DEV
graphical representations exclude some of the CMMI-DEV
practices, sub-practices, and examples. The Semat (Software
Engineering Methods and Theory) kernel has essential elements
that are common in all of the software engineering methods. We
can describe practices by using the universal language provided
by the Semat kernel in order to ease the model manipulation
and contribute to the thinking framework used for evaluating
effort and quality. In this paper we describe a representation of
the proposed CMMI-DEV practices and its components by
using the Semat kernel. We aim to contribute to the
development and consolidation of the software engineering
theory.
1
Keywords— CMMI-DEV, method, kernel, practices, graphic
representation, Semat
L
I. INTRODUCCIÓN
A INTEGRACIÓN de modelos de madurez (CMMI por
sus siglas en inglés) se desarrolló inicialmente en la
Universidad Carnegie-Mellon para el SEI (Software
Engineering Institute) y se define como un marco de
referencia, que contiene modelos que orientan el desarrollo de
procesos en distintas áreas de interés. El modelo denominado
CMMI para desarrollo (CMMI-DEV) reúne un conjunto de
prácticas de ingeniería de software que facilitan la mejora en
los procesos de gestión de proyectos, gestión de procesos,
ingeniería y soporte. El modelo CMMI-DEV proporciona una
guía de orientación para aplicar las buenas prácticas CMMI en
una organización durante el ciclo de vida de un producto,
desde la concepción hasta su entrega y mantenimiento. Las
buenas prácticas del modelo se centran en actividades para
desarrollar productos y servicios de calidad con el fin de
satisfacer las necesidades de los usuarios finales.
CMMI-DEV es un modelo extenso debido a que propone
un conjunto de prácticas específicas que describen las
actividades consideradas importantes para satisfacer un área
de proceso. Estas prácticas se asocian con los objetivos del
área y describen qué hacer para cumplirlos. El modelo CMMIDEV propone algunas sugerencias sobre cómo implementar
las prácticas, a manera de subprácticas, e indica los productos
de trabajo que típicamente se deberían producir al realizarlas.
C. M. Zapata, Universidad Nacional de Colombia, Medellín, Colombia,
[email protected]
J. Valderrama, Universidad Nacional de Colombia, Medellín, Colombia,
[email protected]
L. D. Jiménez, Universidad Nacional de Colombia, Medellín, Colombia,
[email protected]
Las representaciones gráficas existentes de CMMI-DEV
muestran la jerarquía entre los componentes del modelo.
Algunas representaciones son mapas conceptuales en los
cuales se resume la estructura de todos sus elementos,
diagramas del proceso del modelo, la relación jerárquica
entre los componentes y el carácter obligatorio o no de su
aplicación. Algunos de estos autores representan una
composición general de la estructura del modelo CMMIDEV, mientras que otros fragmentan la representación de su
composición en gráficas distintas para especificar los tipos
de representaciones que el modelo CMMI-DEV propone.
Sin embargo, en las representaciones se presenta una falta
de especificación de componentes como prácticas,
subprácticas y ejemplos de trabajo y la relación entre estos
elementos, los cuales proporcionan orientación para la
implementación de las prácticas propuestas en el modelo
CMMI-DEV.
Semat es una iniciativa que crearon Ivar Jacobson,
Bertrand Meyer y Richard Soley con el objetivo de apoyar
la idea de refundar la ingeniería de software, basándose en
una teoría sólida, principios probados y mejores prácticas.
A diferencia de otros intentos para crear una teoría general
de la ingeniería de software, en Semat se generaliza la
ingeniería de software identificando acciones y elementos
universales, que se describen mediante un lenguaje sencillo
y universal que permite la descripción de los métodos y las
prácticas. Su núcleo incluye un grupo de elementos
esenciales que son universales para todo esfuerzo de
desarrollo de software y extensibles para usos específicos,
lo que permite asumir que Semat no se resiste ante nuevas
ideas, ya que cualquier metodología se puede representar
mediante sus elementos en el núcleo.
En este artículo se propone la representación de prácticas
de CMMI-DEV en el núcleo de Semat, ya que una
representación gráfica de las prácticas y sus componentes
facilita la manipulación del modelo, permitiendo un balance
entre la densidad de la información y la legibilidad. Más
que un modelo conceptual, el núcleo de Semat proporciona
un marco de pensamiento para que los equipos de trabajo
razonen sobre los progresos y las decisiones de sus
esfuerzos, permitiendo mejorar continuamente su forma de
trabajo; a partir del núcleo, esos equipos obtienen una base
común para la discusión, la mejora, la comparación, el
intercambio de los métodos de la ingeniería de software y
la definición de prácticas independientes para evaluar la
calidad del producto de software.
Este artículo se organiza de la siguiente forma: en la
Sección II se profundiza acerca del modelo CMMI-DEV y
Semat, en la Sección III se muestran los antecedentes en las
representaciones gráficas del modelo CMMI-DEV, en la
Sección IV se propone la representación gráfica de prácticas
ZAPATA JARAMILLO et al.: REPRESENTATION OF
del modelo CMMI-DEV con los elementos del núcleo de
Semat y finalmente en la Sección V se concluye y se
propone el trabajo futuro.
II. MARCO TEÓRICO
A. Capability maturity model integration-development
El modelo CMMI-DEV (Fig. 1) contiene un conjunto de
áreas de proceso, las cuales cubren los conceptos básicos para
la mejora de procesos en una organización. Un área de
proceso es un grupo de prácticas relacionadas que, cuando se
implementan conjuntamente, satisfacen un conjunto de metas
que son fundamentales para mejorar los procesos. Las metas
se agrupan de dos formas: metas específicas, las cuales
describen las características únicas que se deben considerar
para satisfacer un área de proceso en particular, y metas
genéricas que aplican para múltiples áreas de proceso. De
igual manera, las prácticas también se dividen en específicas y
genéricas con el fin de cumplir las respectivas metas. Las
prácticas se componen de subprácticas y ejemplos de trabajo
que proporcionan el detalle para interpretar e implementar una
práctica específica o genérica.
Figura 1. Componentes del modelo CMMI.
El modelo CMMI-DEV define dos caminos de mejora o
tipos de niveles (también llamados “representaciones”):
niveles de capacidad y niveles de madurez. La
representación continua se relaciona con el nivel de
capacidad y la representación escalonada con el nivel de
madurez. Para alcanzar un nivel de capacidad o un nivel de
madurez, se deben satisfacer todas las metas definidas para
las áreas de proceso que se quieren mejorar.
Los niveles de capacidad o representación continua se
enfocan en la capacidad de un área de proceso individual, en
este caso, en mejorar los procesos de la organización vistos
como áreas de proceso individuales. Los niveles de madurez
o representación escalonada se refieren a la mejora de
procesos de una organización vistos como un conjunto de
áreas de proceso, lo que supone una visión global de la
organización y sus procesos. En la Tabla I se presenta un
comparativo de los niveles de madurez y capacidad
correspondientes a cada una de las representaciones:
3477
Nivel
Nivel 0
Nivel 1
Nivel 2
Nivel 3
Nivel 4
Nivel 5
TABLA I. NIVELES DE CAPACIDAD Y MADUREZ.
Representación continua
Representación por etapas
Niveles de capacidad
Niveles de madurez
Incompleto
Realizado
Inicial
Gestionado
Gestionado
Definido
Definido
Gestionado cuantitativamente Gestionado cuantitativamente
En optimización
En optimización
En la representación por etapas, el punto de partida es el
nivel Inicial, correspondiente al nivel Realizado en la
representación continua. La diferencia radica en que la
representación escalonada se enfoca en la mejora de un
conjunto de áreas de proceso dentro de un nivel de
madurez, por lo que no se considera importante si el
proceso se realizó o está incompleto, lo cual sí es relevante
en la representación continua, ya que se enfoca en la mejora
de un área de proceso particular desde la definición del
proceso.
B. Software Engineering Method and Theory (Semat)
Semat es una iniciativa que se enfoca en dos objetivos
principales: encontrar un núcleo de elementos ampliamente
aceptados y definir una base teórica sólida, con el propósito
de redefinir la forma en que las personas trabajan con los
métodos de desarrollo de software.
El enfoque del núcleo permite definir una base común
para cualquier esfuerzo de desarrollo de software y
construir métodos a partir de prácticas que se puedan definir
y aplicar de manera independiente. Las prácticas se agrupan
para formar métodos que se ajusten a las necesidades ya sea
de la organización, de un proyecto o equipo de trabajo.
El núcleo se puede describir usando un pequeño conjunto
de elementos, los cuales se agrupan en tres áreas de
conocimiento: cliente, solución y esfuerzo. Cada área de
conocimiento se enfoca en un aspecto específico de la
ingeniería de software y se distingue por un color, el cual
permite comprender a nivel gráfico, la relación de las áreas
de conocimiento con cada uno de los elementos agrupados
en ellas. Los elementos que componen cada una de las áreas
de conocimiento y que a su vez definen el núcleo son: alfa,
espacios de actividad y competencias.
Alfa: se puede definir como la representación de las cosas
esenciales para trabajar; provee una descripción de la clase
de cosas que un equipo debe gestionar, usar y producir en
cualquier esfuerzo de desarrollo de software. Un alfa
representa un indicador crítico de todo lo que es más
importante para monitorear y que sigue una línea de
progreso (Fig. 2).
Espacios de actividad: complementan los alfas, ya que
proporcionan el conjunto de actividades esenciales que
normalmente se hacen en ingeniería de software (Fig. 3).
Competencias: representan las habilidades clave que se
requieren para el desarrollo de software.
3478
IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 10, OCTOBER 2015
básica del modelo, definiendo la jerarquía y la relación
entre los elementos (Fig. 5); otros se enfocan en la
representación de los componentes que conforman su
estructura de aplicación (Fig. 6). Sin embargo estas
representaciones se concentran en mostrar todos los
elementos de manera general, algunos innecesarios al
momento de implementar el modelo CMMI pues carecen de
la definición de las prácticas, metas, subprácticas y
ejemplos de productos de trabajo.
Figura 2. Alfas del núcleo.
Figura 5. Elementos del modelo CMMI-DEV.
Figura 3. Espacios de actividad del núcleo.
Figura 6. Componentes del modelo CMMI-DEV.
Figura 4. Competencias del núcleo.
III.
ANTECEDENTES
Las representaciones del modelo CMMI-DEV existentes
buscan, entre otros asuntos, tener un conocimiento general
del modelo, garantizando el entendimiento sobre cómo
implementar las mejoras propuestas. Sin embargo, las
representaciones encontradas carecen de la profundización
en la especificación de componentes como prácticas,
subprácticas y ejemplos de trabajo y la relación entre estos
elementos, los cuales proporcionan orientación para la
implementación de las prácticas propuestas en el modelo.
CMMI-DEV integra elementos como área de procesos,
metas específicas y genéricas, prácticas específicas y
genéricas, subprácticas, productos de trabajo, guías de
adopción de prácticas y los tipos de representación, continua
y escalonada, con sus niveles de madurez o capacidad
respectivamente.
Una de las representaciones gráficas encontradas en la
literatura acerca de la estructura de CMMI-DEV, se basa en
mapas conceptuales que representan una composición
Existen algunos diagramas que especifican la relación
solo de algunos conceptos que son importantes al
diferenciar los tipos de representación que especifica el
modelo CMMI-DEV, tal como se puede apreciar en la Fig.
7; otros esquemas incorporan a la representación anterior el
carácter obligatorio u opcional del uso de los componentes,
tal como se puede ver en la Fig. 1. En este tipo de
representaciones se visualiza la funcionalidad del modelo
CMMI pero no se logra entender cómo aplicar estos
elementos al implementar el modelo sin conocer su teoría.
Figura 7. Tipos de representaciones del modelo CMMI-DEV.
IV. REPRESENTACIÓN
En este artículo se propone una representación específica
ZAPATA JARAMILLO et al.: REPRESENTATION OF
de las prácticas, subprácticas y ejemplos de trabajo del
modelo CMMI-DEV en el núcleo de Semat con la cual se
pretende cubrir aspectos como:
Realizar una abstracción del modelo general,
haciendo énfasis en los aspectos básicos, relacionando los
productos de trabajo que el marco define para cada una de las
prácticas y subprácticas correspondientes.
Facilitar la visualización y entendimiento del
modelo CMMI-DEV, haciendo énfasis en cada uno de los
elementos que componen una práctica en particular.
Representar las prácticas en función de los
elementos del núcleo, partiendo de la característica de que el
núcleo es aplicable a cualquier esfuerzo de desarrollo de
software, facilitando así la implementación de las prácticas.
Esta representación ayuda a los profesionales en la
implementación de las prácticas y el seguimiento de las
mejoras implementadas.
Implementar las prácticas de acuerdo con las
características propias de un proyecto o las necesidades de
una empresa.
Para realizar un acercamiento a la forma de representar
CMMI-DEV con los elementos del núcleo de Semat, se
seleccionó el área de procesos “Desarrollo de requisitos”
(RD por sus siglas en inglés). Esta área de procesos describe
tres tipos de requisitos: de cliente, producto y componente de
producto. Estos requisitos tratan las necesidades de las partes
interesadas
relevantes,
incluyendo
las
necesidades
pertinentes a las diferentes fases del ciclo de vida del
producto y a los atributos del producto, y abarcan las
restricciones causadas por la selección de soluciones de
diseño.
En la Tabla II se muestran los elementos, metas y
prácticas, definidas para esa área de procesos.
3479
modelo CMMI, las demás prácticas se representan de forma
análoga. A continuación, se presentan las subprácticas y
ejemplos de trabajo que componen las prácticas escogidas
para su representación:
TABLA III. PRÁCTICA 1.1.
Práctica
Práctica
Subprácticas
Ejemplos de
productos de trabajo
Elemento
Objetivo específico 1
Práctica específica 1.1
Práctica específica 1.2
Objetivo específico 2
Práctica específica 2.1
Práctica específica 2.2
Práctica específica 2.3
Objetivo específico 3
Práctica específica 3.1
Práctica específica 3.2
Práctica específica 3.3
Práctica específica 3.4
Práctica específica 3.5
DESCRIPCIÓN
El propósito del Desarrollo de Requisitos (RD)
es educir, analizar y establecer los requisitos
de cliente, de producto y de componente de
producto
Desarrollar los requisitos de cliente
Educir las necesidades
Transformar las necesidades de las
partes interesadas en requisitos de
Desarrollar los requisitos de producto
Establecer los requisitos de producto y de
componente de producto
Asignar los requisitos de componente
de producto
Identificar los requisitos de interfaz
Analizar y validar los requisitos
Establecer los conceptos y los escenarios
de operación
Establecer una definición de la
funcionalidad y de los atributos de calidad
Analizar los requisitos
Analizar los requisitos para conseguir
un equilibrio
Validar los requisitos
En este artículo, por razones de espacio, solo se muestran
las representaciones para las prácticas 1.1, 1.2 y 2.2 (véanse
las tablas III, IV y V). Dada la estandarización que posee el
TABLA IV. PRÁCTICA 1.2.
Transformar las necesidades de las partes
interesadas en requisitos de cliente
Traducir las necesidades, las expectativas, las
restricciones y las interfaces de las partes
interesadas en requisitos documentados del cliente
Establecer y mantener una priorización de los
requisitos funcionales de cliente y de los atributos
de calidad
Definir las restricciones para la verificación y la
validación
Requisitos de cliente priorizados
Restricciones de cliente para llevar a cabo la
verificación
Restricciones de cliente para llevar a cabo la
validación
TABLA V. PRÁCTICA 2.2
Práctica
Subprácticas
TABLA II. DESARROLLO DE REQUISITOS.
Propósito
Educir las necesidades
Comprometer a las partes interesadas relevantes
usando métodos para educir las necesidades, las
Subprácticas
expectativas, las restricciones y las interfaces
externas
Ejemplos de productos Resultados de las actividades de educción de
requisitos
de trabajo
Ejemplos de
productos de trabajo
Asignar los requisitos de componente de producto
Asignar los requisitos a las funciones
Asignar los requisitos a los componentes de
producto y a la arquitectura
Asignar las restricciones de diseño a componentes
de producto y a la arquitectura
Asignar requisitos a las entregas incrementales
Documentar las relaciones entre requisitos
asignados
Hojas de asignación de requisitos
Asignaciones provisionales de requisitos
Restricciones de diseño
Requisitos inferidos
Relaciones entre requisites inferidos
Para los elementos relacionados en las tablas III, IV y V,
se propone una representación en el núcleo de Semat como
se muestra en las Fig. 9, 10 y 11. Tal como se puede
apreciar en la Tabla VI, las prácticas del modelo de
desarrollo CMMI- DEV se representan mediante un
hexágono en el núcleo de Semat. Cada una de las
subprácticas que derivan de las prácticas del modelo
CMMI-DEV, en Semat se representa como actividad, pues
indica qué se debe hacer para llevar a cabo la práctica en
particular sin importar el orden de su ejecución. Cada una
de las subprácticas se asocia con ejemplos de trabajo y en el
núcleo de Semat se representa como productos de trabajo.
Los alfas y los espacios de actividad se identifican de
acuerdo con el objetivo que tiene el área de procesos
seleccionada. Desarrollo de requisitos es un área que
involucra el desarrollo de actividades para entender las
necesidades del interesado y determinar los requisitos del
3480
IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 10, OCTOBER 2015
producto que se planea realizar.
TABLA VI. COMPONENTES DE CMMI-DEV Y ELEMENTOS DEL
NÚCLEO DE SEMAT.
Componente de CMMIPráctica
Elemento en el núcleo de Semat
Práctica
Subpráctica
Actividad
Ejemplo de
producto de trabajo
Producto de trabajo
Para la práctica “Educir las necesidades” (Fig. 8), se
identificaron los alfas Interesado y Oportunidad. Al alfa
Interesado se le adicionó un producto de trabajo y se definió
una actividad relacionada con el espacio de actividad
Comprender las necesidades del interesado.
Figura 8. Representación de la práctica educir las necesidades.
Para la práctica “Transformar las necesidades de las
partes interesadas en requisitos de cliente” (Fig. 9), se
identificaron los alfas: Requisitos y Oportunidad. Al alfa
Oportunidad se le adicionaron tres productos de trabajo y se
definieron tres actividades relacionadas con el espacio de
actividad Comprender las necesidades del interesado.
Figura 9. Representación de la práctica transformar las necesidades de
las partes interesadas en requisitos de cliente.
Para la práctica “Asignar los requisitos de componente de
producto” (Fig. 10), se identificó el alfa Requisitos, al cual
se le adicionaron cinco productos de trabajo y se definieron
cinco actividades relacionadas con el espacio de actividad
Comprender las necesidades del interesado.
V. CONCLUSIONES
La representación de las prácticas de CMMI-DEV en
Semat permite identificar los elementos que hacen parte de la
definición de las prácticas en sí mismas y que, a su vez,
facilitan su entendimiento y guían su aplicación. Esto
representa una ventaja para las personas que requieran
implementar las prácticas de CMMI-DEV de manera
individual, de acuerdo con sus proyectos o necesidades
particulares.
La asociación de las subprácticas (actividades) y los
productos de trabajo con los Alfas definidos en el núcleo de
Semat, genera el espacio para realizar un monitoreo y
seguimiento de la evolución e implementación de estos
elementos en un proyecto, facilitando la adecuada
implementación de las prácticas CMMI y alertando sobre
riesgos y dificultades a nivel del proyecto y/o del equipo de
trabajo.
El núcleo de Semat es extensible, lo cual no sólo va
orientado a la posibilidad de representar nuevas prácticas o
métodos,
sino
que
permite
construir
diversas
representaciones de una determinada práctica a partir de la
forma en que se relaciona con los elementos definidos en el
núcleo y a los elementos que se consideren dentro de las
mismas prácticas para su representación (tal es el caso de las
subprácticas y los productos de trabajo como elementos de
las prácticas de CMMI).
Para la realización de la representación que se presentó en
este artículo, el alto grado de estandarización de CMMIDEV facilitó la correlación de los diferentes elementos con
sus equivalentes en el núcleo de Semat. De hecho, algunos
de los elementos comparten la misma terminología en ambos
modelos, tales como las prácticas y los productos de trabajo.
Como líneas de trabajo futuro correspondientes a este
proyecto, se identifican las siguientes:
Desagregar las características de algunos elementos
que, como las actividades, aún no alcanzan un nivel de
granularidad atómico para su representación. Es posible que
ciertos elementos como el nivel de detalle, que pertenece a la
especificación avanzada del núcleo, puedan contribuir a
especificar de forma más refinada estos elementos.
Realizar un estudio a nivel de subprácticas en
relación con los verbos que hacen parte de su descripción. Se
pudo constatar que algunos de esos verbos corresponden a
verbos considerados de objetivos y, por ende, podrían
inducir a errores parciales cuando se representan en forma de
actividades.
Representar los demás modelos de calidad
pertenecientes a CMMI y otros que se podrían considerar
complementarios, como ISO 25000 o estándares de temas
más específicos como los de IEEE.
ZAPATA JARAMILLO et al.: REPRESENTATION OF
3481
Figura 10. Representación de la práctica asignar los requisitos de componente de producto.
Dada la naturaleza general del modelo CMMI-DEV,
es necesario realizar un análisis que permita establecer la
manera de representar ejemplos concretos de los productos
de trabajo. Productos como “resultado de las actividades de
educción de requisitos” podrían ser historias de usuario o
casos de uso, los cuales suelen ser candidatos para su
representación en forma de productos de trabajo.
Nuevamente, los niveles de detalle podrían suministrar pistas
importantes para la representación.
AGRADECIMIENTOS
El proyecto identificado con el código 18907 y que lleva por título
“Especificación formal en OCL de reglas de consistencia entre métodos de
desarrollo basados en planes representado en el núcleo de SEMAT”, que
financia la Dirección de Investigación de la Sede Medellín (DIME),
adscrita a la Universidad Nacional de Colombia suministró los fondos para
la realización de este artículo.
REFERENCIAS
H. Arboleda, A. Pazby R. Casallas. “Metodología para implantar el
Modelo Integrado de Capacidad de Madurez en grupos pequeños y
emergentes”. Estudios Gerenciales 29, 2013, pp. 177–188.
SEI Administrative Agent, “CMMI-DEV: Improving processes for
developing better products and services”. V 1.3, 2010.
I. Jacobson, P. Ng, P.E. McMahon, I. Spence and S. Lidman. The
Essence of Software Engineering: The SEMAT Kernel.
Communications of the ACM, vol. 55, no. 12, 2012, pp. 42-49.
Essence – Kernel and Language for Software Engineering Methods. V 1.3,
2013.
F. Yucalar, S.Z. Erdogan. A questionnaire based method for cmmi level 2
Maturity assessment. Journal of aeronautics and space technologies,
vol. 4, no. 2, 2009, pp. 39-46.
L.F. Campo. Marco metodológico para la administración de proyectos de
software utilizando las mejores prácticas propuestas por el modelo
CMMI-DEV. Tesis de maestría. Colombia, Departamento de
Sistemas y Computación, Universidad de Norte, 2008.
D. Gefen, M. Zviran, and N. Elman. What Can be Learned from CMMI
Failures?. Communications of AIS, vol. 17, Article 36, 2006.
J. Garzás, F.J. Pino, M. Piattini, C. M. Fernández. “A maturity model for
the Spanish software industry based on ISO standards”. Computer
Standards & Interfaces 35, 2013, pp. 616–628.
C.G. von Wangenheim, D.A. da Silva, L. Buglione, R. Scheidt, R.
Prikladnicki. “Best practice fusion of CMMI-DEV v1.2 (PP, PMC,
SAM) and PMBOK 2008”. Information and Software Technology
52, 2010, pp. 749–757.
S. Garg. “Higher education-cmmi: beyond the software frontier (with
specific reference to Higher education in indian knowledge
economy)”. Proceedings of world academy of science, engineering
and technology vol. 41, 2009.
Jorge Valderrama ingeniero de sistemas e informática
de la Universidad Nacional de Colombia, Sede
Medellín, en el año 2010. Actualmente es estudiante de
especialización en ingeniería de sistemas en la misma
institución.
Leidy Diana Jiménez Pinzón ingeniera de sistemas e
informática de la Universidad Nacional de Colombia,
Sede Medellín, en el año 2013. Actualmente es
estudiante de maestría en ingeniería - ingeniería de
sistemas en la modalidad de investigación en la misma
institución.
Carlos Mario Zapata se desempeña actualmente como
Profesor Asociado del Departamento de Ciencias de la
Computación y de la Decisión de la Universidad
Nacional de Colombia, Sede Medellín. Es, además,
presidente del Comité Ejecutivo del Capítulo
Latinoamericano de Semat y también es uno de los
traductores oficiales del libro “La Esencia de la
Ingeniería de Software: aplicando el núcleo de Semat”.