ANÁLISIS Y DESARROLLO

DE SISTEMAS DE INFORMACIÓN

FASE IDENTIFICACIÓN

PROCESOS
deL SOFTWARE
pROCESO DEL SOFTWARE - mODELOS
Procesos del software comerciales o metodologías de desarrollo

ACTIVIDAD DE PROYECTO
1. Determinar las especificaciones
funcionales del Sistema de
Información.

ACTIVIDAD DE APRENDIZAJE
2. Diseñar los mapas de procesos de
las áreas involucradas en el sistema
de información a desarrollar.

De clase mundial
 MODELOS
Modelo de procesos en Cascada

Modelos procesos Incrementados

6
Creative

Commos

Este material puede ser distribuido, copiado y exhibi-

do por terceros si se muestra en los créditos. No se

Modelos de procesos Evolutivos
puede obtener ningún beneficio comercial y las obras

derivadas tienen que estar bajo los mismos términos

Modelos orientados a la Reutilización
de licencia que el trabajo original.

Fase identificación
CON- PROCESOS DEL
SOFTWARE COMERCIALES
O
METODOLOGÍAS DE DESARROLLO
16

TENIDO 4
PROCESO
DEL SOFTWARE

18

Glosario

Referencias
ADSI

ADSI - Análisis y
desarrollo de sistemas de información - SENA, DE CLASE MUNDIAL ADSI - Fase 1
identificación - Procesos del Software
]
Análisis y desarrollo de sistemas de información

Fase identificación

ceso

Aunque existen muchos procesos diferentes de softwa-

re algunas actividades fundamentales son comunes para

[

todos ellos como lo plantea (Sommerville, 2005):

Proceso del software

1.

Especificación de sof- 3. Validación del software,

tware o ingeniería de se debe validar el softwa-

requerimientos: debe re para asegurar que hace

El software se construye de la
misma forma que cualquier otro producto: aplican- definir la funcionalidad
lo que el cliente desea.
do un proceso de producción,
dicho de otra manera siguiendo una serie predeci- del software y las
restric-
ble de pasos, por tanto
involucra modelos de calidad de proceso y de producto. ciones en su
operación.
Un proceso del software está
formado por un conjunto de actividades y resultados
asociados que generan un
producto de software. 2. Diseño e 
implementa- 4. Evolución del software, Otros autores anteriores
plantean el ciclo

ción del software, se el software debe evo- de vida del desarrollo

de software con las

debe producir software lucionar para cubrir las etapas de Análisis,

Diseño, Desarrollo (o

pro-

que cumple su especifi- necesidades cambiantes Codificación),

Implementación, Pruebas y
cación. del cliente. Evolución. Etapas que
concuerdan con las

La existencia de un proceso de sof-

etapas genéricas de un proceso de softwa-

tware no es garantía que el software

re planteadas por (Sommerville, 2005).

será entregado a tiempo, que satisfa-

ga al cliente y cumpla con sus expec-

La conclusión es que todos los procesos

tativas. Para el aseguramiento de la

del software involucran un ciclo de vida,

calidad en los procesos del software

así como el ciclo de vida del ser humano

se trabaja a la par estándares de ca-

es nacer, crecer, reproducirse y morir; los

lidad. Los ISO 9000 y 9001 son nor-

software poseen también su ciclo de vida.

mas genéricas que actualmente se

“Ciclo de vida del SW es el marco de refe-

aplican a cualquier organización que

rencia que contiene los procesos, activida-

SENA, DE CLASE MUNDIAL

desee conseguir el aseguramiento

des y tareas involucradas en el desarrollo,

de la calidad de sus productos, siste-

operación y mantenimiento de un producto

mas o servicios que provee.

SW, abarcando desde la definición de los

requisitos hasta la finalización de su uso”.

ADSI

5
4
]

Modelos
Análisis y desarrollo de sistemas de información

del proceso del software

Un modelo de proceso del
software es una descripción simplificada de un proceso del software,
Análisis de los requisitos del sof- esta tarea. Si el diseño se realiza de
es decir es el modelo o “molde,
base” del cual se basa el proceso del software. El modelo gené-
tware: el proceso de recopilación una manera detallada la codificación
rico o modelo básico se denomina
Ciclo de Vida del Software.
de los requisitos se centra e inten- puede realizarse mecánicamente.

sifica especialmente en el software.

Los
modelos planteados en este numeral son denominados modelos
El ingeniero de software (Analistas) Integración y pruebas: una vez que

descriptivos es decir cualquier organización constructora de software

debe comprender el ámbito de la se ha generado el código comienza
puede
describir un conjunto único de actividades dentro del marco de
información del software, así como la prueba del programa. La prueba se

trabajo para el (los) proceso(s) de software que adopte. Sin importar el

la función, el rendimiento y las in- centra en la lógica interna del softwa-

Fase identificación

modelo del proceso seleccionado, el equipo de desarrollo debe elegir

terfaces requeridas. re, y en las funciones externas, reali-
[

de
manera tradicional un marco de trabajo genérico para el proceso,
zando pruebas que aseguren que la
el
cual puede incluir las etapas propuestas anteriormente, seguir el
Diseño: el diseño del software se en- entrada definida produce los resulta-
ciclo
de vida o definir un marco basado en: comunicación, planeación,
foca en cuatro atributos distintos del dos que realmente se requieren.

modelado, construcción y desarrollo. Note que siguen siendo las mis-

programa: la estructura de los datos,
 mas
etapas solo que varían su nombre.
la arquitectura del software, el detalle Operación y mantenimiento: el sof-

procedimental y la caracterización de tware sufrirá cambios después de

del

la interfaz. El proceso de diseño tradu- que se entrega al cliente. Los cam-

ce los requisitos en una representación bios ocurrirán debido a que hayan

del software con la calidad requerida encontrado errores, a que el softwa-

Modelo de cascada
antes de que comience la codificación. re deba adaptarse a cambios del en-

torno externo (sistema operativo o

Es el
más conocido, está basado en el ciclo de vida tradicional del sof-
Codificación: el diseño debe tradu- dispositivos periféricos), o debido a

tware, el paradigma del ciclo de vida abarca las siguientes actividades:

cirse en una forma legible para la ma- que el cliente requiera ampliaciones

quina. El paso de codificación realiza funcionales o del rendimiento.

Figura 1.

Requerimientos

Modelo en cascada

Desventajas:

mo-

Diseño
• Los proyectos reales raramente siguen el flujo secuencial que

propone el modelo, siempre hay iteraciones y se crean pro-

blemas en la aplicación del paradigma.

Codificación y Test

Unitario
• Normalmente, es difícil para el cliente establecer explícitamen-

te al principio todos los requisitos. El ciclo de vida clásico lo

requiere y tiene dificultades en acomodar posibles incertidum-

SENA, DE CLASE MUNDIAL

Integración del
bres que pueden existir al comienzo de muchos productos.

Sistema

• El cliente debe tener paciencia. Hasta llegar a las etapas fina-

les del proyecto, no estará disponible una versión operativa

Operación y del programa. Un

error importante no detectado hasta que el

Fuente: Mantención
programa esté funcionando puede ser desastroso.

Adatado de (Sommerville, 2005)

La ventaja de este método radica en su sencillez ya que sigue los

ADSI

pasos intuitivos necesarios a la hora de desarrollar el software

7
6
]
Análisis y desarrollo de sistemas de información

Modelos de proceso
incrementales
En muchas
situaciones los requisitos iniciales del sof-
tware están bien
definidos en forma razonable, pero el
enfoque global del
esfuerzo de desarrollo excluye un
proceso puramente
lineal. Además, quizá haya una ne-

Fase identificación
cesidad imperiosa
de proporcionar de manera rápida
[

un conjunto
limitado de funcionalidad para el usuario y
después refinarla y
expandirla en las entregas posterio-
res del software.
En estos casos se elige un modelo de
proceso diseñado
para producir el software en forma
incremental
(Pressman, 2005).

Una vez que un incremento se completa y entrega, los clientes pueden po-

nerlo en servicio. Esto significa que tienen una entrega temprana de parte de

la funcionalidad del sistema. Pueden experimentar con el sistema, lo cual les

ayuda a clarificar sus requerimientos paralos incrementos posteriores y para

Modelo Incremental
las últimas versiones del incremento actual. Tan pronto como se comple-

tan los nuevos incrementos, se integran en los existentes de tal forma que

La figura 2 presenta el modelo de proceso incremental. En un proceso de de-

la funcionalidad del sistema mejora con cada incremento entregado. Los

sarrollo incremental, los clientes identifican, a grandes rasgos, los servicios

servicios comunes se pueden implementar al inicio del proceso o de forma
que proporcionará el sistema. Identifican qué servicios son más importantes
incremental tan pronto como sean requeridos por un incremento.
y
cuáles menos. Entonces, se derivan varios incrementos en donde cada

uno proporciona un subconjunto de la funcionalidad del sistema. La asigna-

En (Sommerville, 2005) se plantean algunas ventajas de este modelo:

ción de servicios a los incrementos depende de la prioridad del servicio con

los servicios de prioridad más alta entregados primero (Sommerville, 2005).

• Los clientes no tienen que esperar hasta que el sistema completo se entregue

para sacar provecho de él. El primer incremento satisface los requerimientos

Figura 2. más críticos de tal forma que pueden utilizar el software

inmediatamente.

Modelo de proceso incremental

•Los clientes pueden utilizar los incrementos iniciales como prototipos

Sin embargo, existen algunos proble-
Definir esbozo
Asignar requerimientos Diseñar la arquitectura y
obtener experiencia sobre los requerimientos de los incrementos mas
en el desarrollo incremental. Los
de
requerimientos a los incrementos del sistema
posteriores del sistema.
incrementos deben ser relativamente

pequeños (no más de 20.000 líneas

• Existe un bajo riesgo de un fallo total del proyecto. Aunque se pueden en-
de código) y cada uno debe entre-

SENA, DE CLASE MUNDIAL

contrar problemas en algunos incrementos, lo normal es que el sistema gar

alguna funcionalidad del sistema.

se entregue de forma satisfactoria al cliente.

Puede ser difícil adaptar los requeri-
Desarrollar
incrementos Validar Integrar Validar
mientos del cliente a incrementos de
del sistema
incrementos incrementos sistema •
Puesto que los servicios de más alta prioridad se entregan primero, y los
tamaño apropiado. Más aún, muchos

Sistema incrementos posteriores se integran en ellos, es inevitable que los

servi- de los sistemas requieren un conjun-
final cios más importantes del sistema sean a los que se les hagan más
pruebas. to de recursos que se utilizan en di-

Sistema incompleto Esto

significa que es menos probable que los clientes encuentren fallos de ferentes
partes del sistema. Puesto

funcionamiento del software en las partes más importantes del sistema. que
los requerimientos no se definen
Fuente:
ADSI

(Sommerville, 2005)
en detalle hasta que un incremento

se implementa, puede ser difícil iden-

tificar los recursos comunes que re-

quieren todos los incrementos.

9
8
 ]

Figura 3.

Modelo DRA

Equipo #n
Análisis y desarrollo de sistemas de información

Modelado

modelado del negocio

modelado de los datos

modelado del proceso

Construcción

reutilización de

Equipo #2 componentes

Comunicación
generación

Modelado de código

modelado del negocio automático

modelado de los datos pruebas

modelado del proceso

Fase identificación

Planeación

Construcción
[

Equipo #1 reutilización de Despliegue

componentes integración
Modelado generación de entrega

modelado del negocio código automático retroalimentación

modelado de los datos pruebas

modelado del proceso

Construcción

reutilización de

componentes

generación automática

Desarrollo Rápido Modelo de

proceso del desarrollo del software lineal secuencial que enfati-
za un ciclo
de desarrollo extremadamente corto. Es una adaptación a “Alta

de código

pruebas

de Aplicaciones, velocidad”
en el que se logra el desarrollo rápido utilizando un enfoque de

construcción basado en componentes. Si se comprenden bien los requisi-

DRA tos y se
limita el ámbito del proyecto, el proceso DRA permite al equipo de
desarrollo
crear un “sistema completamente funcional” dentro de periodos
cortos de
tiempo (Pressman, 2005). La figura 3 presenta el modelo DRA.
Fuente:

60 - 90 días

(Pressman, 2005)

Ventajas de este modelo: En (Pressman, 2005) se

establecen al- • No todos los tipos de aplicacio- • Enfatiza el
desarrollo de compo-

gunas desventajas para este modelo: nes son apropiados para DRA.
nentes de programas reutiliza-

• Permite el desarrollo de • Permite integrar diferen-

Si un sistema no se puede dividir bles. La reutilización es la piedra

productos en periodos tes recursos humanos. •Para proyectos grandes

aunque en módulos adecuadamente, la angular de las
tecnologías de ob-
cortos de tiempo. por escalas, el DRA
requiere re- construcción de los componen- jetos, y se
encuentra en el mode-

SENA, DE CLASE MUNDIAL

cursos humanos suficientes como tes necesarios para DRA presen-

lo de proceso de ensamblaje.

para crear el número correcto de tará problemas.

equipos DRA.

• No es adecuado cuando los ries-

• Requiere clientes y desarrollado- gos técnicos son altos. Esto ocu-

res comprometidos en las rápidas rre cuando una nueva aplicación

actividades necesarias para com- hace uso de tecnologías nuevas,

pletar un sistema en un marco de o cuando el nuevo software re-

tiempo abreviado. Si no hay com- quiere un alto grado de intero-

ADSI

promiso, por ninguna de las par- perabilidad con programas de

tes constituyentes, los proyectos computadora ya existentes.

DRA fracasarán.

11
10
 ]
Análisis y desarrollo de sistemas de información

Figura 5 Modelo de construcción por prototipos

Modelos

Fase identificación
de procesos evolutivos
[

Plan rápido

Comunicación

El software, como todos los

sistemas complejos, evoluciona con el tiempo. Los modelos
Modelado
de proceso evolutivos de se
basan en la idea de desarrollar una implementación inicial,
Diseño rápido
exponiéndola a los comentarios
del usuario y refinándola a través de las diferentes versio-
nes hasta que se desarrolla un
sistema adecuado.

Las actividades de
especificación, desarrollo y validación se entrelazan, en vez de separar-
se, con una rápida
retroalimentación entre éstas como se muestra en la figura 4

Desarrollo

Entrega y
Figura 4. Modelo evolutivo
Construcción retroalimentación
Construcción

del prototipo

Actividades

concurrentes de prototipos

A menudo un cliente define un con-

Fuente: (Pressman, 2005)

Especificación Versión inicial

junto de objetivos generales para el

software, pero no identifica los re- La figura 5 ilustra que la construcción de

prototipos se inicia con la comu-

quisitos detallados de entrada, pro- nicación. El analista y el cliente

encuentran y definen los objetivos globales

cesamiento o salida. En otros casos, para el software, identifican los

requisitos conocidos y las áreas del esque-
Esbozo
Versiones el responsable del desarrollo del sof- ma en donde es
necesaria más definición. Entonces se plantea con rapidez

Desarrollo
de la descripción
intermedias tware está inseguro de la eficacia de una iteración de
construcción de prototipos y se presenta el modelado (en

un algoritmo, de la adaptabilidad de la forma de un diseño rápido). El diseño

rápido se centra en una represen-

un sistema operativo o de la forma tación de aquellos aspectos del software

que serán visibles para el cliente

SENA, DE CLASE MUNDIAL

que debería tomar la interacción hu- o el usuario final (por ejemplo, la

configuración de la interfaz con el usuario

Validación Versión final mano-máquina. En estas, y

muchas y el formato de los despliegues de salida). El diseño rápido conduce
a la

otras situaciones, un paradigma de construcción de un prototipo. Después, el

prototipo lo evalúa el cliente/

construcción de prototipos puede usuario y con la retroalimentación se

refinan los requisitos del software

ofrecer la mejor alternativa para el que se desarrollará. La iteración ocurre

cuando el prototipo se ajusta para

desarrollo (Pressman, 2005). satisfacer las necesidades del cliente

(Pressman, 2005)

Fuente: (Sommerville, 2005)

ADSI
13
12
 ]
Análisis y desarrollo de sistemas de información

Modelo en
espiral
Propuesto
originalmente por Boehm, es un modelo de proceso de software
evolutivo que
conjuga la naturaleza iterativa de construcción de prototipos
con los
aspectos controlados y sistemáticos del modelo lineal secuencial.
Proporciona el
potencial para el desarrollo rápido de versiones incrementa-
les del
software. Cuando se aplica el modelo en espiral, el software se desa-
rrolla en una
serie de entregas evolutivas. Durante las primeras iteraciones,
la entrega tal
vez sea un documento del modelo o un prototipo. Durante las
últimas
iteraciones se producen versiones cada vez más completas del siste-
Modelos
ma
desarrollado. Un proceso en espiral se divide en un conjunto de activida-
des del marco
de trabajo que define el equipo de ingeniería del software. La
Orientados

Fase identificación
figura 6
plantea una serie de etapas que como se indicó deben ser definidas
por el equipo
de desarrollo. (Pressman, 2005)
a la Reutilización
[

Figura 6.
En la mayoría de los proyectos de software

Planeación
Modelo en espiral

estimación existe algo de

reutilización de software. Por

itinerario lo general, esto pasa

cuando las personas

análisis de riesgos
que trabajan en el proyecto conocen diseños

o código similares al requerido. Los buscan,

Comunicación

los modifican acorde a lo requerido y los in-

corporan en el sistema. La reutilización es a

menudo indispensable para el desarrollo rá-

Modelado

análisis pido de sistemas. Esta reutilización informal

diseño es independiente del proceso genérico que

Inicio se utilice. Sin

embargo, en años recientes, ha

surgido un enfoque de desarrollo de software

(ingeniería de software basada en componen-

tes) que se basa en la reutilización, el cual se

Despliegue

está utilizando de forma amplia.

entrega Construcción

retroalimentación código Fuente: (Pressman, 2005)

El modelo orientado a la reutilización tiene la

prueba ventaja obvia de reducir la cantidad

de sof-

tware a desarrollarse y también reduce los

Cada una de las actividades del marco de trabajo representa

costos y los riesgos. Por lo general, también
un
segmento de la ruta en espiral que se presenta en la figura.
conduce a una entrega más rápida del softwa-

Cuando comienza este proceso evolutivo el equipo de softwa-

re. Sin embargo, los compromisos en los re-
re
realiza actividades implicadas en un circuito alrededor de la
querimientos son inevitables y esto conduce

espiral que tiene una dirección en el sentido del movimiento de

a un sistema que no cumple las necesidades
SENA, DE CLASE MUNDIAL
las
manecillas del reloj, y que se inicia desde el centro. El riesgo
reales de los usuarios. Más aún, si las nuevas
es
un factor considerado en cada revolución. El primer circuito
versiones de los componentes reutilizables no

alrededor de la espiral quizá genere el desarrollo de una espe-

están bajo la vigilancia de la organización que

cificación del producto; los pasos subsecuentes alrededor de

los utiliza, se pierde el control sobre la evolu-
la
espiral se pueden aprovechar para desarrollar un prototipo
ción del sistema (Sommerville, 2005).
y
después, en forma progresiva, versiones más elaboradas del

software. Cada paso a través de la región de planeación resul-

ta
en ajustes al plan del proyecto. Los costos y el itinerario se
ADSI

ajustan con base en la retroalimentación derivada de la relación

con
el cliente después de la entrega. Además, el administrador
del
proyecto ajusta el número de iteraciones planeado que se

requiere para completar el software (Pressman, 2005).

15
14
 Análisis y desarrollo de sistemas de información

ciales
[

•Procesos tradicionales: procesos donde

lo importante es la documentación de-

tallada de cada parte del desarrollo del

Fase identificación

producto software, usualmente estos

procesos involucran aseguramiento de

la calidad. La interacción con el cliente es

planificada y acordada previamente. De-

nominados también procesos pesados o

no ágiles. Ejemplos de estos procesos se

tienen: Proceso Unificado de Desarrollo

(RUP), Métrica 3, MSF entre otros.

comer-
Procesos del software
comerciales o metodologías
de desarrollo
Actualmente la
decisión de cual proceso de produc- •Procesos ágiles: procesos cuya caracte-
ción de software
emplear para desarrollo está deter- rística es la gran interacción que tienen

SENA, DE CLASE MUNDIAL

minado por dos
tendencias, los procesos tradicionales los analistas con todos los implicados
en
o pesados y los
procesos ágiles: el desarrollo. La documentación que se

realiza de los componentes del software

se reduce a lo más mínimo pasando a un

segundo plano. Ejemplos de estos pro-

cesos: XP, SCRUM, FDD entre otros.

ADSI

17
16
 ]
Análisis y desarrollo de sistemas de información

•Debrauwer, L., & Heyde, F. (2009). UML (segunda edición ed.).

España, Barcelona: eni ediciones

GLOSARIO
[

Arquitectura de software: [Bass

et al., Feature Driven Development (FDD): OO (Orientación por Objetos):
En- •Pressman, R. (2005). Ingeniería del software, un enfoque práctico
(sexta edición ed.).

Fase identificación
1998]: La arquitectura de un
programa Metodología ágil de desarrollo. No foque para el desarrollo de
sistemas
McGraw-Hill.
o sistema de computación es la
es- requiere un modelo específico de de software que representa el
domi-
tructura o estructuras del
sistema, que proceso y se complementa con otras nio de aplicación de forma
natural
están compuestas de componentes
metodologías. Enfatiza cuestiones y directa basándose en los objetos
software, de las propiedades
visibles de calidad y define claramente en- que se implican en dicho
dominio.
de esos componentes, y las
relacio-
nes entre ellos.

tregas tangibles y formas de evalua-

ción del progreso. FDD consiste en

cinco procesos secuenciales durante

Emplea diversos métodos para repre-

sentar de forma abstracta los objetos,

referencias
Ciclo de vida del software: El
con- los que se diseña y construye el sis- definiendo su estructura,
comporta-
junto de procesos sistemáticos
que tema: Desarrollo del modelo general miento, agrupaciones, estados,
etc.
tienen lugar durante la
existencia del – Construcción de la lista de rasgos
producto, desde su concepción
ini- – Planeamiento por rasgo – Diseño Las estrategias de orientación
por •Sommerville, I. (2005). Ingeniería del software
(sexta edición ed.).
cial hasta que la organización
decide por rasgo – Construcción por rasgo. objetos han desarrollado
metodolo- madrid:
Pearson Educación.
no continuar manteniéndolo.
gías tanto para requisitos, como para

Metodologías ágiles: Estrategias de análisis, diseño y programación.

Extreme Programming (XP): Meto-
desarrollo de software que promue-
dología heterodoxa de
programación. ven prácticas que son adaptativas Rational Unified
Process (RUP): Pro-
Es la más popular de las
denomina- en vez de predictivas; centradas en ceso de Ingeniería del
Software que
das metodologías ágiles.
Surgida a las personas o los equipos, iterati- proporciona un enfoque
disciplinado
partir de la metodología de
trabajo vas, orientadas hacia la funcionali- para asignar tareas y
responsabilida-
empleada Kent Beck, Wark
Cunnin- dad y la entrega, de comunicación des en las organizaciones
de desarro-
gham y Martin Fowler en el
desa- intensiva y que requieren implica- llo de software. Se trata
de un proceso
Glosario de Ingeniería del Software. Recuperado de:
rrollo del proyecto C3 para
Chrysler. ción directa de cliente. integrado en un producto,
desarro-
Extreme Programming (XP) se
funda llado y mantenido por
Racional Sof-
en cuatro valores:
comunicación, Microsoft Solutions Framework tware, e integrado
en su conjunto de
simplicidad, feedback y coraje.
(MSF): Marco para desarrollo de siste- herramientas de desarrollo. Se en-

SENA, DE CLASE MUNDIAL

mas de software basado en principios, cuentra disponible a través de IBM.

modelos, disciplinas, conceptos, prác-

http://www.planetacodigo.com/wiki/glosario:indice el 10 de Agosto de 2012.

ticas y recomendaciones propias, SCRUM: Metodología ágil, aplicada

derivadas de la experiencia de Mi- originalmente por Jeff Sutherland y

crosoft. Se autodefine como “mar- elaborada más formalmente por Ken

co” y no como metodología, porque Schwaber. Scrum aplica principios

considera que no hay una única es- de control industrial, junto con ex-

tructura de procesos válida para to- periencias metodológicas de Micro-

dos los proyectos. El marco MSF se soft, Borland y Hewlet Packard.

ADSI

adapta de forma flexible a las carac-

terísticas de cada proyecto.

19
18
LÍDER DEL PROGRAMA ADSI ASESORÍA PEDAGÓGICA ILUSTRACIÓN PORTADA
Vanessa Cristina Miranda Cano Claudia Herrera Cifuentes Saúl Suaza
vanessa24@misena.edu.co pipelore@yahoo.com ssuaza@gmail.com

COMPILACIÓN Y PREPARACIÓN LÍDER LÍNEA DE PRODUCCIÓN DIAGRAMACIÓN

Jorge Antonio Blanco Velandia Iliana Eneth Molina Cuarta Ricardo Burbano
Martínez
ilmocu@sena.edu.co ribuma@gmail.com

DISEÑO EDITORIAL Y PORTADA

Ricardo Burbano Martínez
ribuma@gmail.com