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
______________________________ _____________________________