INFORME DE PRACTICA EMPRESARIAL

DESARROLLO DE UNA APLICACIÓN PARA LA GENERACIÓN DE LOS

CERTIFICADOS TRIBUTARIOS DEL GRUPO BANCOLOMBIA

PRACTICANTE:

WILLIAM ALEJANDRO CABEZAS POSSO

INGENIERIA DE SISTEMAS

ASESOR TÉCNICO

EDER A. ACEVEDO MARIN

UNIVERSIDAD COOPERATIVA DE COLOMBIA

FACULTAD DE INGENIERÍA

MODALIDAD DE GRADO PRÁCTICA EMPRESARIAL

MEDELLÍN

27/05/2018

Contenido

1. Introducción ................................................................................................................... 4

2. Objetivo general ............................................................................................................. 5

3. Objetivos específicos ...................................................................................................... 5

4. Marco teórico ................................................................................................................. 6

4.1. Software .................................................................................................................... 6

4.2. Sistema ..................................................................................................................... 7

4.3. Ingeniería de sistemas ............................................................................................ 7

4.4. Sistemas operativos ................................................................................................ 8

5. Descripción de actividades desarrolladas en la Práctica Empresarial ..................... 9

5.1. Desarrollo de la aplicación ..................................................................................... 9

5.1.1. Roles ............................................................................................................ 10

5.1.1.1. Product Owner ................................................................................ 10

5.1.1.2. Srum Master .................................................................................. 10

5.1.1.3. Development Team ......................................................................... 10

5.1.2. El Sprint ...................................................................................................... 10

5.1.2.1. Planeamiento del Sprint/Sprint Planning ..................................... 11

5.1.2.2. Reunión de Equipo de Scrum/Scrum team meeting .................... 11

5.1.2.3. Refinamiento del Backlog/Backlog Refinement ........................... 11

5.1.2.4. Revisión del Sprint/Sprint Review ................................................. 12

5.1.2.5. Retrospectiva del Sprint/Retrospective ........................................ 12

5.1.3. Herramientas Scrum - ¿Por qué? ¿Cómo? ............................................. 12

5.1.3.1. Backlog de Producto/Product Backlog .......................................... 12

5.1.3.2. Historias de Usuario /User Stories ................................................. 12

5.1.3.3. Backlog del Sprint/Sprint Backlog ................................................ 12

5.1.3.4. El panel de Tareas/The Taskboard ............................................... 13

5.1.3.5. Definición de “Listo” /Definition of Done ..................................... 13

5.2. Soporte ................................................................................................................... 14

5.3. Documentación ..................................................................................................... 16

6. Fundamentos teóricos o ingenieriles para el desarrollo de la práctica ..................... 17

7. Logros formativos obtenidos en el proceso ..................................................................... 18

8. Fortalezas demostradas en la Práctica Empresarial .................................................... 19

9. Limitaciones o debilidades en la Práctica Empresarial ............................................... 20

10. Aportes relevantes de aprendizaje como futuros profesionales de la ingeniería ... 21

11. Propuesta académica para los futuros practicantes o para los profesionales ......... 22

12. Conclusiones ........................................................................................................................... 23

13. Bibliografía ............................................................................................................................. 24

1. Introducción

Accenture es una empresa de servicios profesionales líder a nivel mundial que brinda una

gama de servicios y soluciones de estrategia, consultoría, tecnología, operaciones y digitales.

Dentro de los proyectos realizados por Accenture, se participó en uno de ellos, desempeñé

funciones como Analista desarrollador de Software, bajo la modalidad llamada Application

Outsourcing trabajando al interior de las instalaciones del cliente y con la metodología Scrum

- Agile.

El proyecto se desarrolló junto con Bancolombia una institución financiera de servicio

completo que brinda una gama de productos y servicios financieros a una base diversificada

de clientes individuales y corporativos en toda Colombia, este proyecto consistió en el

desarrollo de una aplicación que se integrara con los sistemas ya existentes del banco para

poder soportar la generación anual de los certificados tributarios del grupo Bancolombia.

2. Objetivo General

Se busca la aplicación, el desarrollo, la extensión de los conocimientos, actitudes, y

habilidades, previamente adquiridos en el programa académico. Alcanzando las

competencias y la capacidad para desempeñar las tareas y roles que se esperan de un

Ingeniero en Sistemas. Esto con el fin de complementar la formación integral y de cumplir

con las exigencias del mercado laboral desarrollando una aplicación la cual soporte la

generación anual de los certificados tributarios para el grupo Bancolombia.

3. Objetivos Específicos

Aprender a desarrollar en diferentes lenguajes de programación tales como:

.NET(c#), Java, JavaScript, Bases de datos Oracle y Sql Server.

Construir y actualizar la documentación de la aplicación detallando información de

requisitos funcionales, no funcionales, casos de uso.

Brindar soporte a nivel de aplicación.

Capacitar a los usuarios internos en el funcionamiento de la nueva aplicación.

4. Marco Teórico

4.1. Software

Como lo define (Wikipedia, 2018) se conoce como software al soporte lógico de un sistema

informático, que comprende el conjunto de los componentes lógicos necesarios que hacen

posible la realización de tareas específicas, en contraposición a los componentes físicos que

son llamados hardware. La interacción entre el software y el hardware hace operativo un

ordenador (u otro dispositivo), es decir, el Software envía instrucciones que el Hardware

ejecuta, haciendo posible su funcionamiento.

Los componentes lógicos incluyen, entre muchos otros, las aplicaciones informáticas, tales

como el procesador de texto, que permite al usuario realizar todas las tareas concernientes a

la edición de textos; el llamado software de sistema, tal como el sistema operativo, que

básicamente permite al resto de los programas funcionar adecuadamente, facilitando también

la interacción entre los componentes físicos y el resto de las aplicaciones, y proporcionando

una interfaz con el usuario.

El software en su gran mayoría está escrito en lenguajes de programación de alto nivel, ya

que son más fáciles y eficientes para que los programadores los usen, porque son más

cercanos al lenguaje natural respecto del lenguaje de máquina. Los lenguajes de alto nivel se

traducen a lenguaje de máquina utilizando un compilador o un intérprete, o bien una

combinación de ambos. El software también puede estar escrito en lenguaje ensamblador,

que es de bajo nivel y tiene una alta correspondencia con las instrucciones de lenguaje

máquina; se traduce al lenguaje de la máquina utilizando un ensamblador.

4.2. Sistema

Tal como lo define (Blanchard, 1995) en su libro de Ingeniería de Sistemas, un sistema es

una combinación de medios (como personas, materiales, equipos, software, instalaciones,

datos, etc.), integrados de tal forma que puedan desarrollar una determinada función en

respuesta a una necesidad concreta. Los sistemas se clasifican como naturales o artificiales,

físicos o conceptuales, abiertos o de lazos cerrados, estáticos o dinámicos. Los sistemas

analizados en esta monografía son artificiales, ocupan un espacio físico, son dinámicos por

naturaleza, y son abiertos por la posibilidad de ser interactivos y de modificar los márgenes

de su campo de actuación. Más aún, los pasos específicos, la terminología, los tipos de

especificaciones, los elementos orgánicos, etc.

Un sistema puede variar por su forma, adecuación, y/o función. Se puede tratar con un grupo

de aviones desarrollando una misión en una situación geográfica concreta, un barco o una

capacidad de dirigir el combate, una red de comunicaciones capaz de distribuir información

a nivel mundial, un sistema de distribución de energía que abarque canales y plantas

generadoras de energía, una planta de fabricación capaz de producir «x» productos en un

tiempo determinado, o un pequeño vehículo terrestre que realice el transporte de cierto tipo

de carga de un lugar a otro. Cada sistema está formado por componentes, y éstos a su vez

pueden descomponerse en otros más pequeños. Si en un sistema determinado se establecen

dos niveles jerárquicos, al inferior se le suele denominar «subsistema». Por ejemplo, en un 1

3 Introducción sistema de transporte aéreo, los aviones, las terminales, el equipo de apoyo

terrestre y los controles son subsistemas. Los equipos, las personas y la información son

componentes. Por ello los métodos para designar sistemas, subsistemas y componentes son

relativos, ya que un sistema situado en un nivel jerárquico puede ser el componente de otro

de nivel superior. Así, para una situación determinada, es esencial definir el sistema

considerado especificando claramente sus límites y fronteras.

4.3. Ingeniería de sistemas

Como lo define (Wikipedia, 2017), La ingeniería de sistemas es un modo de enfoque

interdisciplinario que permite estudiar y comprender la realidad, con el propósito de

implementar u optimizar sistemas complejos. Puede también verse como la aplicación

tecnológica de la teoría de sistemas a los esfuerzos de la ingeniería, adoptando en todo este

trabajo el paradigma sistémico. La ingeniería de sistemas integra otras disciplinas y grupos

de especialidad en un esfuerzo de equipo, formando un proceso de desarrollo centrado.

La Ingeniería de Sistemas tiene, como campo de estudio, cualquier sistema existente. Por

ejemplo, la ingeniería de sistemas puede estudiar el sistema digestivo o el sistema

inmunológico humano, o quizá, el sistema tributario de un país específico. Como es natural,

los sistemas informáticos son una pequeña parte de un enorme abanico de posibilidades.

La ingeniería de sistemas es la aplicación de las ciencias matemáticas y físicas para

desarrollar sistemas que utilicen económicamente los materiales y fuerzas de la naturaleza

para el beneficio de la humanidad.

Una de las principales diferencias de la ingeniería de sistemas respecto a otras disciplinas de

ingeniería tradicionales, consiste en que la ingeniería de sistemas no construye productos

tangibles. Mientras que los ingenieros civiles podrían diseñar edificios o puentes, los

ingenieros electrónicos podrían diseñar circuitos, los ingenieros de sistemas tratan con

sistemas abstractos con ayuda de las metodologías de la ciencia de sistemas, y confían

además en otras disciplinas para diseñar y entregar los productos tangibles que son la

realización de esos sistemas.

4.4. Sistemas operativos.

Como lo definen (Pérez, Carballeira, Anasagasti, & Costoya, 2001), el sistema operativo es

un software cuya labor es administrar todos los dispositivos de una computadora y

proporcionar una interfaz más sencilla a los programas de usuario para comunicarse con el

hardware.

5. Descripción de actividades desarrolladas en la Práctica Empresarial

5.1. Desarrollo de la aplicación

En el proceso del desarrollo de la aplicación trabajamos bajo el marco de trabajo Scrum,

Scrum es un Framework para trabajar en equipo en una serie de iteraciones.

Las fases en las que se divide y define un proceso de SCRUM son las siguientes:

El ¿Quién? y el ¿Qué?: identifica los roles de cada uno de los miembros del equipo y

define su responsabilidad en el proyecto.

El ¿Dónde? y el ¿Cuándo?: que representan el Sprint.

El ¿Por qué? y el ¿Cómo?: representan las herramientas que utilizan los miembros de

Scrum.

João, G (2016) Que es Scrum. [Imagen]. Recuperada de https://proyectosagiles.org/que-es-

scrum/

5.1.1. Roles

5.1.1.1. Product Owner

El Product Owner/Dueño del producto: es la “voz del cliente” y el responsable de desarrollar,

mantener y priorizar las tareas en el backlog.

5.1.1.2. Srum Master

El Scrum Master: es responsable de asegurarse que el trabajo del equipo vaya bien siguiendo

las bases de Scrum. Además, se encarga de remover cualquier obstáculo que pueda encontrar

el equipo de desarrollo.

5.1.1.3. Development Team

Los Development Team Members/Miembros del Equipo de desarrollo: son los encargados

de escribir y probar el código.

5.1.2. El Sprint

Sprint es la unidad básica de trabajo para un equipo Scrum. Esta es la característica principal

marca la diferencia entre Scrum y otros modelos para el desarrollo ágil. Es una simple

iteración llevada a cabo por los miembros del equipo. Un equipo puede completar varios

Sprints durante el desarrollo del proyecto. Un Sprint inicia con un equipo que se compromete

a realizar el trabajo y finaliza con la demostración de un entregable. El tiempo mínimo para

un Sprint es de una semana y el máximo es de 4 semanas. Dentro del desarrollo de un Sprint

se llevan a cabo ciertos eventos, estos reciben el nombre de Eventos Scrum. Walter Lara

(2015).

5.1.2.1. Planeamiento del Sprint/Sprint Planning

Todos los involucrados en el equipo se reúnen para planificar el Sprint. Durante este evento

se decide qué requerimientos o tareas se le asignará a cada uno de los elementos del equipo.

Cada integrante deberá asignar el tiempo que crea prudente para llevar a cabo sus

requerimientos. De esta manera se define el tiempo de duración del Sprint. Walter Lara

(2015).

5.1.2.2. Reunión de Equipo de Scrum/Scrum team meeting

Estas reuniones se deben realizar diariamente con un máximo de 15 minutos. Siempre en el

mismo horario y lugar. En ellas, cada miembro del equipo deberá responder tres simples

preguntas:

¿Qué hiciste ayer?

¿Qué tienes planeado hacer hoy?

¿Qué obstáculos encontraste en el camino?

Estas reuniones sirven para que todos los miembros del equipo se apoyen entre ellos. Si

alguno de ellos tiene algún inconveniente que tome más tiempo del asignado en resolverse;

este debe tratarse más a fondo en una reunión enfocada en buscar la mejor solución para ello.

Walter Lara (2015).

5.1.2.3. Refinamiento del Backlog/Backlog Refinement

El Product Owner revisa cada uno de los elementos dentro del Product Backlog con el fin de

esclarecer cualquier duda que pueda surgir por parte del equipo de desarrolladores. También

sirve para volver a estimar el tiempo y esfuerzo dedicado a cada uno de los requerimientos.

Walter Lara (2015).

5.1.2.4. Revisión del Sprint/Sprint Review

Los miembros del equipo y los clientes se reúnen para mostrar el trabajo de desarrollo de

software que se ha completado. Se hace una demostración de todos los requerimientos

finalizados dentro del Sprint. En este punto no es necesario que todos los miembros del

equipo hablen. Pueden estar presentes pero la presentación está a cargo del Scrum Master y

el Product Owner. Walter Lara (2015).

5.1.2.5. Retrospectiva del Sprint/Retrospective

En este evento, el Product Owner se reúne con todo su equipo de trabajo y su Scrum Master

para hablar sobre lo ocurrido durante el Sprint Walter Lara (2015). Los puntos principales a

tratar en esta reunión son:

Qué se hizo mal durante el Sprint para poder mejorar el próximo

Qué se hizo bien para seguir en la misma senda del éxito

Qué inconvenientes se encontraron y no permitieron poder avanzar como se tenía

planificado

5.1.3. Herramientas Scrum - ¿Por qué? ¿Cómo?

Para poder definir las respuestas a estas preguntas, se hace uso de ciertas herramientas que

Scrum nos provee.

5.1.3.1.Backlog de Producto/Product Backlog

Esto puede referirse a todo elemento que sea parte del proyecto. Puede ser un bug, una

referencia o parte de un requerimiento. Brindan información muy general del proyecto y

muchas veces no son tomados como requerimientos oficiales Walter Lara (2015).

5.1.3.2.Historias de Usuario /User Stories

Es un elemento especial del product Backlog. Son llamados Historias porque en ellos se

proporciona información sobre cómo debe ser el comportamiento del requerimiento que se

está trabajando. De igual manera, proporciona información directa del cliente en caso de

existir algún cambio. Generalmente estos sí son tomados como requerimientos oficiales

Walter Lara (2015).

5.1.3.3.Backlog del Sprint/Sprint Backlog

Es el conjunto de elementos tomados del Product Backlog que fueron priorizados, medidos

y aceptados en las reuniones de Sprint Planning. Estos, en conjunto con sus respectivos User

Stories, forman oficialmente los requerimientos a elaborar en cada uno de los Sprints que

tendrá el proyecto Walter Lara (2015).

5.1.3.4.El panel de Tareas/The Taskboard

El panel de tareas muestra todas y cada una de las tareas que tienen asignadas cada uno de

los miembros del equipo. Esta tabla se divide en tres columnas que representan el estado de

la tarea:

Por hacer

Haciendo

Terminado

Al inicio del Sprint todas están en la primera columna. Al momento de pasar una tarea a la

columna número dos, indicará al Scrum Master y al Product Owner qué está haciendo cada

miembro del equipo y cuánto tiempo lleva trabajando en dicha tarea. Al finalizar la tarea,

esta debe cambiarse a la última columna. Esto quiere decir que está listo para que QA haga

las pruebas necesarias Walter Lara (2015).

5.1.3.5.Definición de “Listo” /Definition of Done

Todo equipo eficaz y ágil tiene ciertos acuerdos que deben cumplirse antes de dar por

finalizado un Proyecto. Estos son:

Todas las tareas están completas

Revisión de Código / Code Reviewed

Pruebas realizadas a cada elemento desarrollado

Revisión por parte de los clientes (que cumpla sus necesidades)

La revisión de las condiciones de Aceptación por parte del Product Owner

Estas herramientas son útiles no sólo durante un Sprint; sino que ayudan a lo largo del

proyecto, ya que ayudan al equipo a entender por qué hacen lo que están haciendo. Son

visibles para cada uno de los miembros del equipo y para las personas que están fuera

también. Walter Lara (2015).

5.2. Soporte de la aplicación

Trabajando bajo las reglas del banco para poder realizar el soporte a la aplicación debí

ceñirme a los estándares establecidos por este, los cuales detallare a continuación.

Implementar, soportar las aplicaciones y las herramientas de Colaboración que estén

implementadas bajo plataformas Windows y Linux para garantizar a los clientes en todas las

regiones la oportunidad, confiabilidad y disponibilidad de los servicios prestados, sobre una

infraestructura tecnológica actualizada.

Para la atención de incidentes, es necesario el uso de una herramienta llamada IT Service

Desk Manager desarrollada por la empresa CA Technologies, proporciona capacidades

innovadoras de administración de cambios, automatización amplia y contenido de mejores

prácticas predefinidas que ayudan a implementar un enfoque proactivo para la administración

de servicios de TI y reducir los costos y riesgos para el negocio.

CA Service Desk Manager está diseñado para ayudar a los analistas del service desk de TI a

que cada momento cuente a través de una experiencia dinámica que les permita ofrecer un

servicio al cliente sin procesos o métricas excesivos.

En Bancolombia, esta herramienta se divide en dos programas, el primero (USM) es donde

se solicita permisos a recursos compartidos o permisos para acceso a los servidores y donde

se solicitan las herramientas necesarias para que el personal pueda cumplir con todas sus

labores. El segundo y más usado (USD) tiene como objetivo listar eventos, incidentes,

problemas y ordenes de cambio (OC), que son las tareas que se recibe por el área de soporte,

como también permite la creación de estas tareas en caso tal de que se necesitara apoyo por

parte de otra área. A continuación, se dará una breve explicación de en qué consiste cada una

de estas tareas:

Evento: Una o varias alertas tempranas que se presentan por una actividad inusual o

excepción en el comportamiento de un servicio y que requiere acción en un periodo

de tiempo corto.

Incidente: Cualquier evento que no forma parte de la operación estándar de un

servicio y que causa o puede causar una interrupción o reducción de la calidad del

mismo.

Problema: La causa desconocida que subyace a un incidente. Un problema puede ser

la causa de varios Incidentes. Se convierte en Error Conocido cuando se determina la

causa raíz.

Ordenes de cambio (OC): Solicitudes que llegan por parte de usuarios de otras áreas

de la organización, donde se realizan modificaciones o se da acompañamiento para

la configuración de un aplicativo o servidor.

5.3. Documentación.

Gestionar la documentación de aplicación, realizando modificaciones para entregar

información actualizada, con el fin de que la organización requiera de un respaldo

documental necesario para auditorias, análisis y mejoramiento de procesos del banco y apoyo

por parte de futuras generaciones para que tengan una base de las actividades que se deben

realizar.

6. Fundamentos teóricos o ingenieriles para el desarrollo de la práctica.

El mundo laboral es muy competitivo, por tal razón la experiencia es un pilar fundamental

para encontrar empleo o velar por mantener el puesto si ya se tiene. Los estudiantes tienen la

oportunidad de comenzar y ganar experiencia desde temprana edad por medio de las prácticas

empresariales, estas son importantes para el desarrollo profesional, donde les ayuda a aplicar

todos los conocimientos adquiridos en el centro educativo y a conocer como es el mundo

laboral y cuáles son las necesidades o perfiles que necesita una empresa.

La práctica empresarial ayuda al estudiante a que reflexione sobre lo que en realidad quieren

hacer, así como conocer sus fortalezas y debilidades en el ámbito laboral, y que es difícil

conocerse a sí mismo cuando no tienes un punto de comparación.

7. Logros formativos obtenidos en el proceso.

La práctica en Accenture fue una gran experiencia donde tuve la oportunidad de crecer

personal y profesionalmente, como también adquirir varios conocimientos ya que la empresa

brinda capacitaciones y cursos a sus empleados. También se obtuvo varios logros durante

este proceso. Los conocimientos y logros obtenidos fueron:

Logros obtenidos:

Reconocimiento y felicitaciones de Accenture y Bancolombia por lograr

desarrollar la aplicación en tiempo récord.

Vinculación directa con Accenture por el buen trabajo realizado.

Conocimientos Obtenidos:

Trabajo en equipo.

Aprender a desarrollar en diferentes lenguajes de programación tales como:

.NET(c#), Java, JavaScript, Bases de datos Oracle(Pl/Sql) y Sql

Server(Transact/Sql).

Construir documentación de aplicaciones detallando información de requisitos

funcionales, no funcionales, casos de uso y casos de prueba.

Ser capaz de brindar soporte a nivel de aplicación.

Con el conocimiento adquirido ser capaz de dictar capacitaciones a usuarios y

compañeros de trabajo.

Administración, solución de problemas y buenas prácticas en Internet Information

Services (IIS).

Manejo de servidores Windows, Linux, máquinas virtuales y servidores de

aplicación.

Web Services y certificados digitales.

8. Fortalezas demostradas en la Práctica Empresarial

Las fortalezas demostradas en la práctica son:

Empatía con las demás personas.

Saber escuchar.

Responsabilidad y compromiso de las tareas que se me asignaron.

Humildad a la hora de enseñar a personas sin conocimiento.

Conocimientos en sistemas operativos Windows y Linux.

Fácil comprensión de actividades a desarrollar.

Buen trato con la gente.

Curiosidad, deseo por aprender.

Trabajo en equipo.

Positivismo y perseverancia.

Puntualidad.

Autodidacta.

9. Limitaciones o debilidades en la Práctica Empresarial

Las debilidades demostradas fueron:

Nerviosismo.

Indecisión.

Complejo de inferioridad.

Falta de confianza.

No saber manejar el estrés bajo presión, causando mal genio.

No expresar bien mis ideas a los demás.

Carencia de experiencia.

Desconocimiento en desarrollo de software.

10. Aportes relevantes de aprendizaje como futuros profesionales de la ingeniería.

Definir el futuro es algo que nos cuesta, es importante tener en cuenta pensar en quien quieres

ser, ya que el dinero no lo es todo a la hora de elegir tu futuro, ya que probablemente puedas

escoger algo, pero no es realmente lo que te apasione y como conclusión no te vas a sentir a

gusto con tu labor y no vas a dar el mejor rendimiento profesional.

Si se opta por la ingeniería de sistemas, es importante saber que es fundamental en el ámbito

empresarial, ya que las empresas deben pensar a futuro para no estancarse, implementar

nuevas tecnologías para mejorar tanto el rendimiento de la empresa, como también brindar

una buena experiencia para los usuarios finales.

Como futuro profesional en la ingeniería se debe desarrollar la habilidad para investigar y a

aportar nuevas ideas y conocimientos a la sociedad, como también es importante desarrollar,

administrar y sobre todo saber solucionar problemas relacionados a la informática, que se

esté capacitado para desarrollar una herramienta que permita automatizar y reducir costos en

una empresa.

11. Propuesta académica para los futuros practicantes o para los profesionales.

Es importante saber que, para enfrentarse al mundo laboral, no solo se debe mostrar interés

en los gustos y las cosas que apasionan, sino también la habilidad para aprender y aplicar

todas tus fortalezas, sin temor a fallar, ya que de los errores se aprende. También es

importante, y como se mencionó anteriormente, que la decisión que hayas tomado sea la

correcta y que te apasione hacerlo para poder desempeñarte a plenitud y estar en constante

mejora tanto personal como profesionalmente.

Es significativo que en el lugar donde te desenvuelvas, que aportes nuevos conocimientos,

así como ideas para el mejoramiento, y ayudar a ejecutarlas, ya que tanto las personas como

las empresas deben de estar en constante crecimiento, y adoptar las nuevas herramientas o

formas de laborar, dejarán marcado un buen posicionamiento en el mercado.

12. Conclusiones.

Accenture me ha dado la oportunidad de conocer un mundo empresarial donde no había

estado anteriormente, una organización tan grande e importante para el mundo donde hay

que ser responsable en cada procedimiento que se maneje, y sobre todo en el desarrollo de

software, ya que estas aplicaciones soportan día a día el trabajo de las demás personas y un

solo fallo puede generar una serie de problemas tipo bola de nieve.

Este complemento académico como requisito de grado no lo veo como un proceso más para

poderme graduar, si no de una oportunidad de aprender, y tengo que dar las gracias a

Accenture y Bancolombia por su compromiso y acompañamiento que tuvo para enseñarme

y seguir con mi trabajo y con mis objetivos.

13. Bibliografía

João, G (2016) Que es Scrum. https://proyectosagiles.org/que-es-scrum/

Wikipedia. (2018). Scrum (software development)

https://en.wikipedia.org/wiki/Scrum_(software_development)

Walter, L. (2015). Metodología Scrum: Cómo funciona la metodología de trabajo

Scrum https://platzi.com/blog/metodologia-scrum-fases/

James, M. (2017) Metodología de Scrum. http://scrummethodology.com/

Blanchard, B. S. (1995). Ingeniería de sistemas. Isdefe.

Wikipedia. (2017). Ingeniería de sistemas.

https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_sistemas

Pérez, J. C., Carballeira, F. G., de Miguel Anasagasti, P., & Costoya, F. P.

(2001). Sistemas operativos. McGraw-Hill Interamericana.

Finanzas Personales. (2017). ¿Para qué sirven las practicas empresariales?

http://www.finanzaspersonales.co/gaste-eficientemente/articulo/para-que-sirven-las-

practicas-empresariales/37604

Firma del practicante y del asesor.

William Alejandro Cabezas Posso Eder A. Acevedo Marin

Practicante Asesor

______________________________ _____________________________