01- FUNCIÓN DE DESARROLLO

Objetivos

• Identificar los pasos principales en el ciclo de vida del desarrollo de software.

• Listar los principales modelos de desarrollo.

Función de desarrollo

El desarrollo de software proporciona una serie de pasos para que los programadores creen
programas de computadora. Este proceso constituye las fases del ciclo de vida del desarrollo
de software y métodos. Comprender el método de desarrollo de software ofrece amplias
oportunidades en la industria de TI.

El ciclo de vida incluye varias fases que proporcionan un método para crear productos que
cumplan con las especificaciones técnicas y los requisitos del usuario.

“El ciclo de vida del desarrollo del software proporciona un estándar internacional que las
empresas de software pueden utilizar para crear y mejorar sus programas informáticos”.

Ofrece una estructura definida para que los equipos de desarrollo la sigan en el diseño
creación y mantenimiento de software de alta calidad el objetivo del proceso de desarrollo
de software de ti es crear productos efectivos dentro de un presupuesto y un cronograma
definido

Pasos principales en el ciclo de vida del desarrollo de software

1. Identificación de necesidades. Antes que una empresa cree software debe realizar
una investigación de mercado exhaustiva para determinar la viabilidad del producto.
Los desarrolladores deben identificar las funciones y los servicios que el software
debe proporcionar para que sus consumidores objetivos lo aprovechen al máximo y
lo consideren necesario y útil hay varias formas de obtener esta información, incluido
en los comentarios de clientes y encuestas potenciales y existentes

Los equipos de ti y otras divisiones de la empresa también deben discutir las

fortalezas y debilidades y oportunidades del producto los procesos de desarrollo de
software comienzan solo si el producto satisface todos los parámetros necesarios
para su éxito.

2. Análisis de requisitos. El análisis de requisitos es la segunda fase del ciclo de vida

del desarrollo de software. Aquí las partes interesadas acuerdan los requisitos
técnicos y de usuario y las especificaciones del producto propuesto para lograr su
objetivo. Esta fase proporciona un esquema detallado de cada componente el
alcance las tareas de los desarrolladores y los parámetros de prueba para entregar
un producto de calidad.

La etapa de análisis de requisito involucra a desarrolladores usuarios, probadores

gerente de proyecto y aseguramiento de la calidad. Esta es también la etapa en la
que los programadores eligen el enfoque de desarrollo de software, como la cascada
o el modelo, el equipo registra el resultado de esta etapa en un documento de
 especificación de requisitos de software que los equipos siempre pueden consultar
durante la implementación del proyecto.

3. Diseño. El diseño es la tercera etapa del proceso de desarrollo de software. Aquí los
arquitectos y desarrolladores elaboran las especificaciones técnicas avanzadas que
necesitan para crear el software según los requisitos. Las partes interesadas,
discutirán factores como los niveles de riesgo la composición del equipo y la
tecnología aplicable, el tiempo, el presupuesto, las limitaciones del proyecto el
método y el diseño arquitectónico.

El documento de especificación de diseño define el diseño arquitectónico, los

componentes la comunicación, la representación del front-end y los flujos de usuarios
del producto. Este paso proporciona una plantilla para desarrolladores y evaluadores
y reduce las posibilidades de fallas y retrasos en el producto terminado.

4. Desarrollo e implementación. La siguiente etapa es el desarrollo e implementación

de los parámetros de diseño. El código de los desarrolladores se basa en las
especificaciones y requisitos del producto acordado en la etapa anterior siguiendo
los procedimientos y pautas de la empresa los desarrolladores de aplicaciones para
el usuario, crean interfaz y servicios de fondo. Mientras que los administradores de
bases de datos crean datos relevantes en la base de datos. Los programadores,
también prueban y revisan el código de los demás.

Una vez que se completa la codificación. Los desarrolladores implementan el

producto en un entorno en la etapa de implementación, esto les permite probar una
versión piloto del programa para que el rendimiento coincida con los requisitos.

5. Prueba. La fase de pruebas revisa el software en busca de errores y verifica su

rendimiento antes de entregarlos al usuario. En esta etapa los probadores expertos
verifican las funciones del producto para asegurarse de que funcione de acuerdo con
el documento de análisis de requisitos.

Los evaluadores utilizan pruebas exploratorias si tienen experiencia con ese software
o un script de prueba para validar el rendimiento de los componentes individuales del
software. Notifican a los desarrolladores sobre defectos en el código. Si los
desarrolladores confirman que las fallas son válidas mejoran el programa y los
probadores repiten el proceso hasta que el software esté libre de errores y se
comporte de acuerdo con los requisitos.

6. Despliegue y mantenimiento. Una vez que el solo esté libre de defecto los
desarrolladores pueden entregarlo a los clientes. Después del lanzamiento de la
versión de producción de un software la empresa de desarrollo de software de TI,
crea un equipo de mantenimiento para gestionar los problemas que encuentran los
clientes mientras utilizan el producto. El mantenimiento puede ser una solución
urgente si se trata de un problema menor pero las fallas graves del software requieren
una actualización.
Modelos de desarrollo de software

Los modelos de desarrollo de software son los distintos procesos o metodologías que se
están seleccionando para el desarrollo del proyecto en función de los objetivos y metas del
proyecto. Hay muchos modelos del ciclo de vida de desarrollo que se han desarrollado para
lograr diferentes objetivos requeridos. Los modelos especifican las distintas etapas del
proceso y el orden en que se llevan a cabo o podría incluir nuevas etapas o fusionar algunas.

La selección del modelo tiene un impacto muy alto en las pruebas que se realizan. Definirá
el qué, dónde y cuándo de nuestras pruebas planificadas. Influirá en las pruebas de
regresión y determinar en gran medida qué técnica de prueba a utilizar.

Existen varios modelos o metodologías de desarrollo de software algunos de ellos son:

• Modelo de cascada
• Modelo V
• Modelo incremental
• Modelo RAD
• Modelo ágil
• Modelo interactivo
• Modelo espiral
• Modelo de prototipo

Es muy importante elegir el modelo correcto para desarrollar el producto de la aplicación de

software. Sobre la base del modelo se lleva a cabo los procesos de desarrollo y pruebas.
MODELOS DE DESARROLLO
Objetivos:
✓ Introducir el estudiante a los modelos de desarrollo.
✓ Describir las características de los modelos predictivos.

Modelos de desarrollo
A través de tiempo los ingenieros de software han desarrollado diferentes modelos
de desarrollo cada uno con sus propios simpatizantes. Una gran cantidad de
personas han dedicado mucho esfuerzo y tiempo e ingeniería de software, durante
ese tiempo algunas personas notaron que había problemas muy frecuentes con los
métodos que estaban usando, quizás el desarrollo se desvió del plan original y los
programadores no probaron su código o el proyecto tardó tanto que cuando se
terminó las necesidades de los clientes habían cambiado.
Muchos decidieron estudiar esos problemas y proponer diferentes enfoques para
tratar de abordarlos, los modelos de desarrollo resultante tienden a enfatizar una
parte del desarrollo u otro, por ejemplo, los métodos ágiles permiten que los
objetivos de un proyecto cambien con el tiempo para arrastrar las necesidades
cambiantes del cliente.
El desarrollo guiado por pruebas obliga a los programadores a escribir pruebas para
su código, la programación extrema utiliza programación por pares para garantizar
que cada fragmento de código pase por una especie de revisión de código.
Hay mucha superposición entre los diferentes modelos por ejemplo muchos
desarrolladores notaron que los requisitos de los clientes a veces cambian por lo
que hay muchos métodos ágiles que intentan abordar ese problema.
Cada modelo tiene su propia filosofía, conjunto de reglas y listas de principios
importantes, pero en la práctica lo que realmente importa es producir software de
alta calidad razonablemente cerca del tiempo y dentro del presupuesto.
Muchos modelos de desarrollo utilizan técnicas inteligentes para hacer que el
desarrollo tenga más probabilidades de producir un buen resultado.

Modelos predictivos
Una manera de categorizar los modelos de desarrollo es la forma en que maneja en
los requerimientos. En un modelo de desarrollo predictivo se trata de identificar de
antemano lo que debe hacerse, utiliza los requerimientos para diseñar el sistema y
utiliza el diseño como modelo para escribir el código, usted prueba el código, hace
que los clientes firmen diciendo que realmente hace lo que la especificación dice
que debería.
Como analogía se construye una pared de ladrillo con un modelo predictivo, según
la experiencia pasada se sabe exactamente cuánto tiempo llevará construir una
pared del tamaño deseado, puede calcular fácilmente cuántos ladrillos necesitará,
luego puede adquirir los ladrillos, programar algunos albañiles y hacer el trabajo;
desafortunadamente a menudo es difícil predecir con anticipación exactamente qué
debe hacer una aplicación de software y cómo debe crearla, a veces las situaciones
comerciales cambiantes provocan que lo que los clientes necesitan al principio no
es lo que necesitan al final.
Un modelo de desarrollo adaptativo le permite cambiar el objetivo del proyecto si
es necesario durante el desarrollo, en lugar de elegir un diseño desde el principio y
avanzar laboriosamente hacia él, incluso cuando el diseño ya no es relevante.
Un modelo adaptativo le permite reevaluar periódicamente y decidir si necesita
cambiar de dirección, puede comenzar con una buena idea de cómo debería verse
la aplicación final; el modelo adaptativo solo le brinda la oportunidad de ajustar el
proyecto si es necesario, puede pensar que un modelo adaptativo siempre es
mejor que uno predictivo, pero hay casos en los que un modelo predictivo
funciona bastante bien, por ejemplo, los modelos predictivos funcionan bien cuando
el proyecto es relativamente pequeño, sabe exactamente lo que necesita hacer y el
plazo es lo suficientemente corto como para que los requisitos no cambien durante
el desarrollo.
El modelo predictivo puede ser adecuado cuando:
- Participación del usuario: Los usuarios ayudan a definir los requisitos
- Visión clara: Los clientes y los desarrolladores tienen la misma visión clara
sobre los objetivos del proyecto.
- Tamaño limitado: un proyecto de tamaño pequeño ayuda a los clientes y
miembros del equipo a ver la imagen completa de una sola vez y los
requisitos no tendrán tiempo de cambiar.
- Equipo experimentado: Es menos probable que los miembros del equipo
con experiencia diseñen algo que no puedan construir, tampoco se distraerán
escribiendo código que no funcione, claro que un equipo experimentado es
útil para cualquier proyecto.
- Tecnología establecida: Si se apega a la tecnología que ha usado antes
comprenderá cómo usarla correctamente,

Ventajas del modelo predictivo:

algunos de los principales beneficios del modelo predictivo son:
✓ Previsibilidad: Si todo sale de acuerdo con el plan entonces conoce con
exactitud cuándo ocurrirán las diferentes etapas, en particular sabe cuándo
terminará y cuánto esfuerzo necesitará.
 ✓ Estabilidad: Debido a que los requisitos están claramente definidos al
comienzo del proyecto los clientes saben exactamente lo que obtendrán, eso
es particularmente importante para los sistemas críticos para la vida como
los sistemas que controlan dispositivos médicos, automóviles y aviones.

✓ Ahorro de costos: Si el diseño es claro y correcto no perderá tiempo

siguiendo caminos de desarrollo que resultan ser inadecuados.

✓ Diseño detallado: Si diseña todo correctamente desde el principio no

debería perder el tiempo tomando muchas decisiones durante el desarrollo
posterior, eso hace que la programación sea más rápida y por lo tanto más
barata.

✓ Mejor documentación: Los modelos proyectivos requieren mucha

documentación antes de que comience la programación, eso facilita la
incorporación de nuevas personas al proyecto porque pueden leer la
documentación para ponerse al día.

✓ Mantenimiento sencillo: Dado que puede considerar la aplicación desde

una perspectiva más amplia puede crear un diseño más elegante, más
consistente y más fácil de mantener.

Desventajas del modelo predictivo:

Un proyecto productivo puede presentar algunas desventajas:
✓ Inflexible: El suponer que los requisitos no cambiarían, eso no significa que
no lo harán, si lo hacen acomodar los puede ser difícil si surge una nueva
oportunidad, idea tecnología u otras es probable que no pueda aprovecharla.

✓ Versión inicial tardía: Con un modelo predictivo los usuarios no obtienen un

producto usable hasta que finaliza el desarrollo.
Objetivos.
• Conocer la importancia del modelo en cascada y sus fases.
• Examinar las condiciones en que es aplicable el modelo en cascada.

Modelo de desarrollo en cascada.

El modelo en cascada clásicos es 1 de los modelos más comunes del proceso de desarrollo de
todos.

Este modelo se recomienda en situaciones en las que hay un cliente para el que se está
creando el software. Básicamente, el modelo nunca se aplica en situaciones en las que no hay
un cliente conocido. Como sería el caso del todo bar diseñado para el mercado comercial para
múltiples compradores minoristas.

También y muy importante en los casos en los que los éxitos de un problema están claramente
definidos.

Cuando el trabajo fluye desde la comunicación hasta la implementación de una manera

razonablemente línea.

Esta situación a veces se encuentra cuando se deben realizar a las estaciones o mejorar bien
definidas a un sistema existente.

Por ejemplo: Una adaptación al software de contabilidad que ha sido exigida debido a
cambios en las regulaciones gubernamental.

Pero solo cuando los requisitos están bien definidos y son razonablemente estables.
El modelo de cascada es un ejemplo de un proceso impulsado por un plan, se Inicia
planificando todas las actividades del proceso antes de comenzar el desarrollo del software.
Uno de los aspectos de mayor importancia del modelo en cascada es que sus etapas reflejan
directamente en las actividades fundamentales del desarrollo de software.

1. Análisis y definición de requerimientos: Los requerimientos, las limitaciones y los objetivos

del sistema se establecen mediante consultas con los usuarios del sistema. Luego se definen
en detalle y sirven como una especificación del sistema.

2.Diseño: Este proceso asigna los requisitos a los sistemas de hardware o software, establece
una arquitectura general del sistema; El diseño de software implica identificar y describir las
atracciones fundamentales del sistema y sus relaciones.

3. Construcción y pruebas unitarias: durante esta etapa, el diseño se realiza como un conjunto
de programas o unidades del programa. La prueba unitaria implica verificar que cada unidad
cumpla con sus especificaciones.

4. Integración y pruebas del sistema: las unidades por programas individuales del programa se
integra y prueban como un sistema completo para garantizar que cumplan con los
requerimientos iniciales. Después de la prueba, el sistema de software se entrega al cliente.

5. Operación y mantenimiento: normalmente esta es la fase del ciclo de vida más largo. El
sistema se instala y se pone en práctica. El mantenimiento implica corregir errores que no se
descubrieron en etapas anteriores del ciclo de vida. Mejorar la implementación de las
unidades del sistema y mejorar los servicios del sistema a medida que se descubren nuevos
requisitos.

Como se puede observar, es hasta las fases finales del ciclo de vida del software, se pone en
uso. Pueden surgir errores y omisiones en los requisitos originales. Errores de programa y
diseño o identificar la necesidad de una nueva funcionalidad. Por tanto, el sistema debe
evolucionar para seguir siendo útil.

Hacer estos cambios puede implicar la repetición de etapas anteriores del proceso.
 Desventajas del Modelo de desarrollo en cascada
El modelo en cascada es la metodología más antigua de la ingeniería de software. Sin embargo,
las críticas a este modelo de proceso han cuestionado su eficacia. Cuando se aplica el modelo
de cascada se puede dar los siguientes inconvenientes.

1 los proyectos comúnmente no siguen el flujo secuencial que propone el modelo. Aunque el
modelo lineal puede adaptarse a la interacción, lo hace indirectamente. Como resultado, los
cambios pueden causar confusión a medida que avanza el equipo del proyecto.

2. suele ser difícil para el cliente establecer todos los requisitos de forma explícita. El modelo
de cascada requiere esto y tiene dificultades para adaptarse a la incertidumbre natural que
existe al comienzo de muchos proyectos.

3. Él cliente debe de tener paciencia. Una versión funcional del programa no estará disponible
hasta etapas avanzadas en el período del tiempo del. Un error grave que no se detecta hasta
que se revisa el programa de trabajo, puede ser desastroso.

Sistemas compatibles al modelo

En realidad, que todo tiene que ser flexible y adaptarse a los cambios a medida que se
desarrolla. La necesidad de un compromiso temprano y una elaboración del sistema cuando se
realizan cambios significa que el modelo en cascada solo es apropiado para algunos tipos del
sistema.

1. Sistemas embebidos: donde el software debe interactuar con el hardware. Debido a la

inflexibilidad del hardware, normalmente no es posible retrasar las decisiones sobre la
funcionalidad del software hasta que se implementando.
2. Sistemas críticos: donde existe la necesidad de un análisis extenso de seguridad y
protección de la especificación y el diseño del software, en estos sistemas, los
documentos de justificación y diseño deben estar completos para que este análisis sea
posible. Los problemas relacionados con la seguridad en la especificación diseño
suelen ser muy costosos de corregir en la etapa de implementación.
3. Subsistemas de uno más amplio: Grandes sistemas de software que forman parte de
sistemas de ingeniería más amplios desarrollados por varias empresas asociadas.
Cuando participan varias empresas es posible que se necesiten especificaciones
completas para permitir el desarrollo independiente de diferentes subsistemas.
Modelo de cascada incremental.

Objetivos:

• Describir el funcionamiento del modelo de cascada incremental.

• Exponer las ventajas y desventajas del modelo incremental.

Existen situaciones en las que los requisitos iniciales de software están bien definido, pero el alcance
general del esfuerzo de desarrollo no es un proceso estrictamente lineal. Además, puede existir una
necesidad de proporcionar de manera rápida un Conjunto limitado de funciones y luego refinar y
ampliar esa funcionalidad en versiones de software posteriores. En tales casos, puede elegir un
modelo de proceso que esté diseñado para producir el software en incrementos.

El modelo de cascada incremental se basa en la idea de desarrollar una versión inicial, obtener
comentarios de los usuarios y evolucionar el software a través de varias versiones hasta que se haya
desarrollado el sistema requerido.

El modelo incremental aplica secuencias lineales de forma escalonada a medida que avanza el
tiempo del calendario. Cada secuencia lineal produce incrementos entregables de software. Cuando
se utiliza un modelo incremental, el primer incremento suele ser un producto central, es decir, se
toman los requisitos básicos, pero otras características complementarias no se incluyen. El producto
principal es utilizado y evaluado por el cliente. Como resultado de esta evaluación se desarrolla un
plan para el siguiente incremento.

El plan aborda la modificación del producto principal para satisfacer mejor las necesidades del
cliente y la entrega de características y funcionalidades adicionales. Este proceso se repite después
de la entrega de cada incremento hasta que se produce el producto completo.

Puede decirse que de cierta forma, el desarrollo incremental es ahora el enfoque más común para
el desarrollo del sistema de aplicaciones y productos de software. Este Enfoque puede estar
orientado a un plan ágil o una combinación de estos enfoques. A un enfoque basado en planes, los
incrementos del sistema se identifican de antemano si se adopta un enfoque ágil, se identifican los
primeros incrementos. Pero el desarrollo de los siguientes incrementos depende del progreso y las
prioridades del cliente.

El desarrollo incremental tiene 3 ventajas principales sobre el modelo en cascada:

1. Te reduce el costo de implementar cambios en los requisitos, la cantidad de análisis y

documentación que debe rehacerse es significativamente menor que la requerida con el modelo en
cascada.
2. Es más fácil obtener comentarios de los clientes sobre el trabajo de desarrollo que se ha realizado.
Los clientes pueden comentar las demostraciones del software y ver cuánto se ha implementado. A
los clientes les resulta difícil juzgar el progreso a partir de los documentos de diseño de software.

3. la entrega e implementación anticipadas de software útil al cliente, incluso si no se ha incluido

todas las funciones en comparación con el proceso en cascada, los clientes pueden utilizar y obtener
valor del software de manera temprana.

El enfoque incremental tiene 2 problemas:

1. El proceso no es visible. Los gerentes necesitan entregables regulares para medir el progreso. Si
los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen todas las
versiones del sistema.

2. La Estructura del sistema tiende a degradarse a medida que se agregan nuevos incrementos. Los
cambios regulares conducen a un código desordenado a medida que se agregan nuevas funciones
de cualquier manera posible.

Agregar nueva funcionalidad se vuelve cada vez más difícil y costoso. Para reducir la reparación
estructural y el desorden general del código, los métodos ágiles sugieren que se debería refactorizar,
mejorar y reestructurar el software con regularidad.

Los problemas de desarrollo incremental se vuelven particularmente agudo para los sistemas
grandes, complejos y de larga duración. Donde diferentes equipos desarrollan diferentes partes del
sistema.

Los sistemas grandes necesitan un marco o arquitectura estable y la responsabilidad de los

diferentes equipos que trabajan en cada parte del sistema deben estar claramente definidas con
respecto a esa arquitectura. Esto debe planificarse con anticipación en lugar de desarrollarse
gradualmente.

El desarrollo incremental no significa que tenga que entregar cada incremento al cliente del sistema.
Puede desarrollar un sistema de forma incremental y exponerlo a los clientes y otras partes
interesadas para que comenten sin necesariamente entregarlo e implementarlo en el entorno del
cliente.

La entrega incremental significa que el software se utiliza en procesos operativos reales. Por lo que
es probable que los comentarios de los usuarios sean realistas. Sin embargo, no siempre es posible
proporcionar comentarios, ya que experimentar con nuevos software puede interrumpir los
procesos comerciales normales.

La educación es el arma más poderosa que puedes usar para cambiar el mundo hasta la próxima.
Modelos iterativos

los objetivos de la clase son:

 presentar las bases de los modelos iterativos

 describir el funcionamiento del modelo de prototipado

modelos Iterativos
en esta vídeo clase se empezará a analizar una de las técnicas más fáciles de
aplicar a cualquier otro modelo de desarrollo la iteración

Es un modelo Iterativo la técnica donde la aplicación final se construye de

forma incremental, se comienza con un programa que funciona con algunas
características básicas y luego se agregan nuevas piezas haciéndolo cada vez
más completo hasta que la aplicación está terminada, esta idea es similar al
famoso ciclo de Deming o ciclo PDSA por sus siglas en inglés para planificar,
hacer, verificar y actuar la cual es una estrategia de la mejora continua de la
calidad.

en la sección anterior se estudió un

modelo con características iterativas
el modelo incremental en esta video clase
veremos otras variaciones iterativas
que pueden ayudar a mantener encaminados
los esfuerzos de ingeniería de software
entre las que examinaremos:

 El prototipado
 Modelo de espiral
 El proceso unificado

Prototipado:
un prototipo es un modelo simplificado que demuestra algún comportamiento
que desea estudiar normalmente, un prototipo de software es un programa que
imita parte de la aplicación que desea crear, la idea es brindar a los clientes
una sensación práctica más intuitiva sobre cómo se verá la aplicación
terminada y cómo se comportará de lo que puede obtener de las descripciones
de texto como historias de usuario y casos de uso.

Un simple prototipo de interfaz de usuario puede mostrar formularios que

contiene etiquetas, cuadro de texto y botones que muestran cómo se verá la
aplicación terminada, en un prototipo no funcional los botones menús y otros
controles de los formularios en realidad no harían nada su objetivo es ayudar a
validar los requerimientos de los
usuario, un prototipo funcional se ve y actúa tanto como lo hará la aplicación
terminada puede hacer algo que parece que funciona, pero puede estar
incompleto y probablemente no usará los mismos métodos que usará la
aplicación final. Puede utilizar algoritmos menos eficientes, cargar datos de un
archivo de texto en lugar de una base de datos o mostrar mensajes aleatorios
en lugar de obtenerlos de otro sistema incluso podría utilizar datos falsos
codificados de forma rígida

hay un par de cosas que puede hacer con un prototipo una vez
construido:

puede usarlo para definir y refinar los requisitos, puede mostrárselos a los
clientes y en función de sus comentarios pueden modificarlos para que se
ajuste mejor a sus necesidades, eventualmente puede comenzar a reemplazar
el código de prototipo y los datos falsos con código de calidad de producción y
datos reales, con el tiempo puede evolucionar el prototipo a versiones cada vez
más funcionales hasta que finalmente se
convierta en la aplicación final este tipo de prototipo a veces denomina
prototipo evolutivo.

El paradigma de creación de prototipo como se muestra en la figura

comienza con la comunicación se reúne con otras partes interesadas para

definir los objetivos generales del software, identificar los requisitos que se
conocen y describir las áreas en la que es obligatorio una definición más
detallada se planifica rápidamente una
iteración de creación de prototipo y se produce el modelado en forma de diseño
rápido

un diseño rápido se centra en una representación de aquellos aspectos del

software que serán visibles para los usuarios finales por ejemplo el diseño de
interfaz humana o formatos de visualización de salida el diseño rápido conduce
a la construcción de un prototipo el prototipo se implementa y evalúa por las
partes interesadas que brinda comentarios que se utilizan para refinar aún más
los requisitos.
La iteración se produce cuando el prototipo se ajusta para satisfacer las
necesidades de las diversas partes interesadas y al mismo tiempo le permite
comprender mejor lo que debe hacerse.

Beneficios o ventajas de la creación de prototipos:

Requisitos mejorados:
los prototipos permiten a los clientes ver cómo se da la aplicación terminada
eso les permite proporcionar comentarios para modificar los requisitos al
principio del proyecto
a menudo los clientes pueden detectar problemas y solicitar cambios antes, por
lo que el resultado final es más útil para los usuarios.

visión común:
los prototipos permiten a los clientes y desarrolladores tener la misma vista
previa de la aplicación terminada por lo que es más probable que tengan una
visión común de lo que
debería ser la aplicación y cómo debería verse.

mejor diseño:
los prototipos permiten a los desarrolladores explorar rápidamente partes
específicas de la aplicación para aprender en qué consisten, los prototipos
también permiten a los desarrolladores probar diferentes enfoques para ver
cuál es el mejor, los desarrolladores pueden usar lo que aprenden de los
prototipos para mejorar el diseño y hacer que el
código final sea más elegante y robusto.

La creación de prototipo viene con algunas desventajas:

visión restringida:

La gente tiende a centrarse en el enfoque específico de un prototipo más que

en el problema que aborda, cuando les muestra a los clientes y desarrolladores
un prototipo es menos probable que piensen en otras soluciones que podrían
hacer un mejor trabajo, para evitar este problema no cree un prototipo hasta
que haya considerado posibles alternativas o cree varios prototipos para elegir.

impaciencia del cliente:

un buen prototipo puede hacer que los clientes piensen que la aplicación está
casi
terminada para evitar esto asegúrese de que los clientes estén conscientes de
que el prototipado no está ni cerca de la aplicación finalizada.
06 - MODELO EN ESPIRAL

Objetivos

• Que el estudiante comprenda el funcionamiento y característica del modelo de espiral.

• Presentar las ventajas y desventajas de este modelo.

Modelo de espiral

El modelo en espiral fue descrito por primera vez en 1986 por Barry Boehm, uno de los pioneros
de ingeniería de software, propuso un modelo de proceso incremental basado en riesgo cuya
fase se representa como una espiral y no como una secuencia de actividades. Cada bucle de la
espiral representa una fase del proceso del software el modelo en espiral supone que los cambios
son el resultado de los riesgos del proyecto y propone gestionarlos para reducirlos.

La figura anterior muestra el enfoque general en espiral el cual consta de cuatro fases básicas:

• En la primera fase, llamada fase de planificación se determinan los objetivos del ciclo
actual, se determinan las alternativas y limitaciones de los objetivos.

• En la segunda fase se realiza un análisis de riesgo para determinar cuáles son los factores
más importantes que podrían impedirle alcanzar los objetivos de este ciclo se gestionan
los riesgos y se construye un prototipo para lograr los objetivos, es importante notar que
no necesariamente debe ser un programa, por ejemplo, si el objetivo del ciclo actual es
construir requisitos entonces será un conjunto de requisitos de prototipo.

• La fase de ingeniería es la tercera fase y es donde se utiliza el prototipo que se acaba de

construir para evaluar la solución se realizan simulaciones y modelan problemas
específicos para ver si se está en el camino correcto, por ejemplo, se puede ejecutar una
serie de escenarios operativos para ver si los requisitos del prototipo pueden manejarlos,
se utiliza lo que se aprende a lograr los objetivos originales después en esta fase se debe
tener algo concreto que mostrar.
 • En la cuarta fase se evalúa el progreso obtenido hasta ahora y se asegura de que las
principales partes interesadas del proyecto estén de acuerdo en que la solución que se
obtuvo es correcta y que el proyecto debe continuar. Si se detecta un error se realiza otra
vuelta a la espiral para arreglar los problemas que quedan, identificar los objetivos
perdidos y evaluar las alternativas identificar y resolver los riesgos y producir otro
prototipo. Después de estar seguro de que está en el camino correcto se planifica el
próximo ciclo alrededor de la espiral.

Desde que describió inicialmente el enfoque en espiral, Boehm ha hecho varias aclaraciones
principalmente para corregir los errores que se cometieron al interpretar el método. Esas
declaraciones incluyen lo siguiente:

• No se trata simplemente de una serie de modelos en cascada dibujados en espiral y

ejecutados uno tras otros para formar un enfoque incremental, de hecho, podría usar
múltiples espirales para construir diferentes versiones de una aplicación.

• No es necesario que las actividades sigan una sola secuencia en espiral, por ejemplo,
puede convertir el diseño de la interfaz de usuario y el diseño de la base de datos en
espirales completamente independiente que un ciclo general del proyecto.

• Puede agregar elementos, eliminar o cambiar el orden en un modelo de espiral específico,

según sea necesario, las actividades que necesita realizar dependen del proyecto.

Boehm definió, además, seis características que deben seguir los ciclos de desarrollo en espiral:

1. Defina tareas al mismo tiempo. No es necesario realizar todo de forma secuencial.

2. Realice las siguientes 4 fases en cada ciclo.
3. Utilice el riesgo para determinar el nivel de esfuerzo
4. Utilicé riesgo para determinar el nivel de detalle.
5. Utilice hitos de anclaje.
6. Concéntrese en el sistema y su ciclo de vida en lugar de cuestiones a corto plazo como
escribir un diseño inicial o escribir un código.

Ventajas

El enfoque espiral se considera uno de los enfoques de desarrollo más útiles y flexibles la
siguiente lista resume algunas de sus principales ventajas:

• Proporciona muchos puntos para revisar y tomar decisiones.

• Destaca el análisis de riesgo. Se identifica y resuelve los riesgos correctamente, debería

conducir al éxito final.

• Puede adaptarse al cambio razonablemente bien. Simplemente realice los cambios

necesarios y luego ejecute un ciclo para identificar y resolver los riesgos que crean.

• Las estimaciones como el tiempo y el esfuerzo requeridos se vuelven más precisas en el

tiempo a medida que se completan los ciclos y se eliminan los riesgos del proyecto.
Desventajas

La siguiente lista resume algunas de las mayores desventajas del enfoque en espiral.

• A menudo requiere más recursos que los enfoques más simples.

• El análisis de riesgo puede resultar difícil y la complicación no siempre vale la pena el

esfuerzo, especialmente para proyectos de bajo riesgo.

• Las estimaciones de tiempo y esfuerzo inicialmente pueden no ser buenas, se vuelven

más precisas a medida que se completan los ciclos, pero inicialmente esas estimaciones
pueden ser no buenas.

• No funciona bien con proyectos pequeños podría terminar dedicando más tiempo al
análisis de riesgo del que necesitaría para crear la aplicación completa con un enfoque
más simple.
Proceso Unificado
Objetivos

• Examinar las fases del proceso unificado

• Que el estudiante conozca las ventajas y desventajas del proceso unificado.
El proceso unificado es un marco de desarrollo interactivo e incremental que puede
personalizar para adaptarse al negocio y proyecto el enfoque del proceso unificado se
divide en las siguientes cuatro fases:
1. Inicio: es aquí donde surge la idea del proyecto debe ser una fase corta en la que
se proporciona un caso de negocio se identifican los riesgos se proporciona un
cronograma inicial y los aspectos generales de las metas del proyecto no debe
incluir requisitos detallados que puedan restringir a los desarrolladores.

2. Elaboración: durante esta fase se crean los requisitos del proyecto se elaboran
casos de uso de gran masa arquitectónicos y jerarquías de clase se debe
especificar el sistema, pero aun así no se desea restringir a los desarrolladores
con requisitos innecesariamente detallados los principales objetivos son identificar
y abordar los riesgos para que el proyecto no fracase más tarde normalmente esta
fase se divide en varias interacciones. La primera aborda de los riesgos más
importantes.

3. Construcción: durante esta fase se escribe prueba y depure el código esta fase
divide en varias iteraciones cada una de las cuales termina con un programa
ejecutable probado y de alta calidad que puede lanzar al usuario, las integraciones
se implementan las más importantes características primero.

4. Transición: durante esta fase transfiere el proyecto a los clientes y al equipo de

mantenimiento a lo largo del plazo según los comentarios de los usuarios puede
realizar cambios y mejoras y luego lanzar una nueva versión por lo que esta fase
puede incluir varias iteraciones esta fase incluye todas las tareas de transición
habituales como la puesta en marcha, la creación del entorno del usuario,
computadoras, redes entre otras, La documentación del usuario y la capacitación
del usuario.
Se pueden agregar más fases si lo desea, por ejemplo, puede agregar las siguientes dos
fases para modelar el ciclo de vida de la aplicación después de la transición:

• Producción: en este punto el usuario utiliza en la aplicación el proceso unificado

normalmente asume que el equipo de desarrollo no continúa produciendo nuevas
versiones de la aplicación durante esta fase.

• Eliminación: durante esta fase elimina la aplicación y mueve al usuario a un

sistema de reemplazo, si está construyendo el reemplazo esta fase se superpone
con la fase de transición del nuevo proyecto.
La siguiente figura muestra los tamaños relativos de las fases del proceso unificado, la
altura de un rectángulo representa los recursos necesarios para esa fase principalmente
la cantidad de personas en el equipo, el ancho de un rectángulo representa la cantidad de
tiempo dedicado a esa fase. Puede observar que la fase de construcción está
representada por el rectángulo más alto y más ancho lo que significa que consume más
recursos y lleva más tiempo.

Esta nueva figura muestra la cantidad relativa de diferentes tipos de trabajo durante las
fases del proyecto y las integraciones dentro de esas fases por ejemplo el trabajo de
implementación programación es relativamente ligero durante el inicio y la elaboración se
recupera durante las iteraciones de construcción y luego disminuye durante la transición
El proyecto que se muestra en la figura tiene tres iteraciones de elaboración cuatro
iteraciones de construcción y dos en la fase de transición
Ventajas del proceso unificado.
Algunas de las principales ventajas del enfoque de proceso unificado son:
El enfoque interactivo de las fases de elaboración construcción y transición le permite
definir de manera incrementar los requisitos y ensamblar la aplicación, las iteraciones de
elaboración se centran en los riesgos y la mitigación de riesgo para mejorar las
posibilidades de éxito del proyecto puede adaptarse a diferentes modelos de desarrollo de
forma flexible por ejemplo podría utilizar una serie de cascada o un enfoque ágil para la
fase de construcción la fase de inicio y elaboración generan mucha documentación que
puede ayudar a nuevos desarrolladores a unirse al equipo más adelante.
Desventaja del proceso unificado.
Algunas de las desventajas del enfoque del proceso unificado son similares a las del
enfoque en espiral debido a que es complicado a menudo requiere más recursos que los
enfoques más simples, el análisis de riesgo puede resultar difícil la complicación no
siempre vale la pena el esfuerzo especialmente para proyectos de bajo riesgo no funciona
bien con proyectos pequeños podría terminar dedicando más tiempo al inicio y la
elaboración del que necesitaría para crear la aplicación completa con un enfoque más
simple al igual que el enfoque en espiral el enfoque del proceso unificado es más útil con
grandes proyectos de alto riesgo y proyectos con requisitos inciertos o cambiantes
Desarrollo Rápido de Aplicaciones (RAD)
Objetivos:
✓ Explorar los principios y técnicas RAD.
✓ Exponer las ventajas y desventajas de metodologías RAD.

Desarrollo Rápido de Aplicaciones (RAD)

De manera fundamental la ingeniería de software tiene como objetivo producir
software útil lo más rápido posible. Los modelos de desarrollo de software que
se han descrito hasta el momento se enfocan en el primero de esos objetivos.

Producir aplicaciones útiles, intentan que el resultado cumpla con las

especificaciones y que las especificaciones representen algo útil los modelos
iterativos como la cascada incremental y el proceso unificado le permite cambiar
la dirección del proyecto en caso de que se desvíe o los requisitos cambien con
el tiempo. Técnicas como la creación de prototipos ayudan a garantizar que la
especificación proporcione al cliente un resultado útil. Los modelos como el
proceso unificado enfatizan la gestión de riesgo para garantizar que el esfuerzo
de desarrollo tenga éxito. Todos los modelos dedican al menos algún esfuerzo a
fomentar buenas técnicas de programación para que el resultado sea robusto y
fácil de mantener.

Ninguno de los modelos descritos hasta ahora se centra realmente en el segundo

objetivo de la ingeniería de software. producir software rápidamente eso no
quiere decir que esos modelos fomenten un desarrollo lento sin embargo los
modelos discutidos hasta ahora no se enfocan en aumentar la velocidad de
desarrollo, implícitamente hacen cosas para limitar la cantidad de errores lo que
puede ahorrarle tiempo a largo plazo, pero no proporciona técnicas para acelerar
el desarrollo.

Descripción de los modelos de Desarrollo Rápido de Aplicaciones (RAD)

Estos modelos incorporan algunas de las mejores características de los modelos
descritos en las sesiones anteriores, además de nuevas características que
ayudan a los desarrolladores a brindar resultados útiles rápidamente.

Principios RAD
✓ Cambio constante.
Una de las ideas básicas de RAD es que las cosas siempre cambian, en
ocasiones al terminar un proyecto, los clientes se dan cuenta de que los
requisitos no describen con precisión sus necesidades, aunque la
aplicación satisface los requisitos no satisface sus necesidades, lo que a
final de cuentas resulta ser más importante. Otro caso es cuando las
necesidades de los clientes cambian durante el desarrollo del proyecto,
los objetivos de la empresa, la competencia o los deseos del cliente
cambian, por lo cual cuando la aplicación está lista nadie la quiere.
✓ Satisfacción.
Esos hechos conducen a un problema obvio con los modelos de gran
diseño inicial cuando se termina una aplicación no satisface las
necesidades de los clientes. Los modelos iterativos ayudan a mantener
un proyecto encaminado si realiza una nueva iteración cada año más o
 menos podría desviarse mucho antes de darse cuenta de que se dirige en
la dirección equivocada. Los métodos RAD llevan las ideas iterativas al
extremo en lugar de utilizar iteraciones que duran meses o años sus
iteraciones duran un mes, una semana o incluso menos, algunas técnicas
RAD también aplican la iteración a todo, no sólo a la programación,
aplican la iteración a la recopilación de requisitos, la validación de
requisitos y el diseño.

Algunas Técnicas Más Comunes Utilizadas En Los Modelos De Desarrollo

RAD.
• Equipos pequeños. Aproximadamente media docena de personas o
menos. Eso conduce a proyectos de alcance limitado, aunque existen
extensiones para proyectos más grandes.
• Recopilación de requisitos a través de grupos focales. Talleres, reuniones
facilitadas, creación de prototipo y lluvia de ideas. Validación de requisitos
a través de prototipos iterados casos de uso.
• Pruebas constantes de diseño por parte del cliente.
• Constante integración y prueba de nuevo código en la aplicación.
• Revisiones informales y comunicación entre los miembros del equipo.
• Iteraciones cortas que duran entre unos meses y tan sólo una semana.

Ventajas generales del desarrollo rápido de aplicaciones:

• Requisitos más precisos. Los clientes pueden ajustar los requisitos según
sea necesario durante el proyecto.
• Seguimiento de los requisitos cambiantes. Si los requisitos deben cambiar
dentro de lo razonable el proyecto puede comenzar a rastrear los nuevos
requisitos en la siguiente iteración.
• Comentarios y participación frecuente de los clientes. Además de ayudar
a mantener el proyecto en marcha esto mantiene a los usuarios
comprometidos con el proyecto.
• Reducción del tiempo de desarrollo. Si todo va bien no dedicará tanto
tiempo a redactar requisitos con excesivo detalle.
• Fomenta la reutilización del código. Una de las ideas clave de RAD es
hacer lo que sea necesario para realizar la iteración actual, si un
fragmento de código existente hace lo que se necesita que haga le anima
a usar ese código en lugar de escribir algo nuevo.
• Posibles versiones iniciales con funcionalidad limitada. Las pruebas
constantes promueve un código de alta calidad y alivia los problemas de
integración.
• Mitigación de riesgo. Antes de cada iteración puede buscar riesgos
potenciales y manejarlos.
• Mayor probabilidad de éxito. Los incrementos frecuentes permiten que los
proyectos RAD detecten y corrijan los problemas rápidamente antes de
que se vuelvan insuperables.

Desventajas generales del desarrollo rápido de aplicaciones:

• Resistencia al cambio. Puede resultar difícil conseguir que los grupos de
ingeniería de software adopten nuevos modelos RAD sobre todo teniendo
en cuenta lo extraño que puede parecer algunas de sus técnicas.
• No maneja bien los sistemas grandes. Los grandes sistemas requieren
mucho esfuerzo y por lo general eso significa mucha gente, la sobrecarga
de comunicación por sí sola dificulta la ejecución de grandes proyectos en
un modelo RAD, si puede dividir el proyecto en partes bien desconectadas
es posible que tenga una oportunidad.
• Requiere miembros de equipo más capacitados. No es necesario que
cada miembro del equipo sea un programador experto, pero los equipos
de RAD pequeños no pueden incluir demasiados principiantes.
• Requiere acceso a recursos escasos. La iteración frecuente con el cliente
es esencial para mantener el proyecto en marcha, a menudo esa iteración
debe ser con clientes que son expertos en sus campos y esas personas
tienden a tener una gran demanda y tiempo limitado.
• Menor control gerencial. Muchos gerentes tienen problemas para permitir
que un proyecto avance en su propia dirección cambiante.
• Impredecibilidad. Algunos clientes sólo quieren saber la duración y costo
del proyecto y realmente no están interesados en participar en dar forma
a la aplicación durante su desarrollo.
PROGRAMACION EXTREMA (XP)

Objetivos:
✓ Describir la metodología de desarrollo programación extrema.
✓ Presentar los roles y valores de Programación extrema.

Programación Extrema (XP)

La Programación Extrema (XP) debe su calificativo de “extrema” porque lleva las
prácticas de programación normales a niveles extremos, no se trata de programar
todo el tiempo desde el primer momento.

Revisiones de código
Por ejemplo, si consideramos las revisiones de códigos los modelos de
programación tradicionales utilizan revisiones periódicas de código para mejorar la
calidad de este, aproximadamente cada semana, algunos o todos los
desarrolladores se reúnen para revisar el código de alguien y buscar problemas y
posibles mejoras, las revisiones de código también le permiten determinar si el
código satisface sus requisitos de diseño.
Las revisiones de código son una buena práctica, pero tienen un par de
inconvenientes, por un lado las revisiones de código pueden llevar mucho tiempo si
todos los miembros del equipo dedican un par de horas a la semana a revisiones
de código es el tiempo en el cual no están escribiendo código, para ahorrar tiempo
las revisiones de código a menudo cubren sólo una pequeña parte, los miembros
del equipo pueden aplicar las ideas y técnicas discutidas durante una revisión a otra
parte del código pero sería mejor si se revisarán todas las partes del código.
Pueden mejorar las revisiones de código examinando más código y haciéndolo más
cerca del momento en que se escribió, en lugar de revisar el 20% del nuevo código
semanalmente, qué pasaría si podía revisar el 40% del código dos veces por
semana o el 75% del código cada dos días llevando esta idea al extremo, qué
pasaría si pudiera revisar cada comentario y línea de código a medida que se
escribe suena extremo no.

Programación en pareja (pares)

En realidad, es exactamente lo que hace la técnica de programación extrema de
programación por pares, en la programación de pares dos o incluso tres
programadores se sientan frente al mismo monitor y trabajan juntos en un fragmento
de código, uno de ellos llamado controlador o conductor controla el teclado mientras
escribe, el conductor mantiene un monólogo constante explicando lo que está
haciendo, un beneficio del monólogo es que ralentiza al conductor y lo obliga a
pensar en su propio código, a menudo explicar lo que uno hace en el código es
suficiente para que encuentre sus propios errores; el segundo programador del par
llamado observador o navegador revisa cada línea de código a medida que se
escribe, el observador se asegura de que el código tenga sentido y haga lo que el
controlador cree que hace, el observador también puede pensar en posibles
mejoras o futuros cambios, básicamente el observador realiza una revisión extrema
de código línea por línea en tiempo real, los dos programadores cambian de roles
con frecuencia para que ambos se mantengan actualizados.
En la práctica se ha mostrado que la programación por pares tiene varias
ventajas:
Mejora la calidad en gran parte porque el código es revisado constantemente por
dos programadores con puntos de vista ligeramente diferentes.
La programación en pareja lleva más tiempo en horas personas, pero compensa
con creces a reducir la cantidad de errores, los programadores confían más en su
código aprenden a comunicarse más fácilmente y comparten conocimientos,
constantemente para que puedan aprender nuevas habilidades.

Roles en XP
Los roles en programación extrema más comunes son:
- Cliente: Es quien define los requisitos, verifica que la aplicación satisfaga las
necesidades de los usuarios y proporciona comentarios frecuentes para
mantener el desarrollo en marcha, a veces varios clientes pueden estar
involucrados, pero a diario un solo cliente en el sitio generalmente juega el papel
principal de cliente.

- Rastreador: Supervisa el progreso de los miembros del equipo y proporciona

métricas útiles.

- Programador: Define la arquitectura de la aplicación y escribe el código.

- Entrenador: Ayuda al equipo a trabajar de forma eficaz, a organizarse por sí

mismo y a utilizar buenas prácticas de programación extrema.

- Evaluador: Ayuda al cliente a escribir y realizar pruebas de aceptación para

casos de uso, busca requisitos faltantes y problemas en el diseño.

- Administrador: Configura y mantiene las computadoras, la red y las

herramientas de desarrollo de los miembros del equipo.
Los roles exactos que se utilizan en diferentes proyectos varían un poco, por
ejemplo, algunos equipos agregas roles adicionales como:
- Un gerente: Que va a las reuniones y generalmente actúa como una interfaz
entre el equipo y el mundo exterior.
Algunos de estos roles también se pueden combinar, por ejemplo, el administrador
suele ser también un programador y el administrador también puede ser el
rastreador, no se deben permitir algunas combinaciones de roles, por ejemplo, un
programador probablemente no debería combinarse con el cliente, el evaluador
o el rastreador.

Valores de programación extrema (XP)

Los siguientes son los valores que encontramos en programación extrema:
✓ Comunicación: Los requisitos deben ser comunicados por los clientes a los
desarrolladores para que todos adquieran una visión común de los objetivos
del sistema, la comunicación se ve favorecida por diseños simples, una
amplia colaboración e interacción frecuente, metáforas compartidas y
comentarios regulares.

✓ Simplicidad: La Programación Extrema (XP) fomenta los diseños simples,

la aplicación debe comenzar con el enfoque más simple posible y luego se
agregan más funciones solo si es necesario.

✓ Comentarios: Las pruebas de unidad y de integración frecuentemente

proporcionan comentarios sobre la calidad del código, los clientes brindan
comentarios a través de revisiones periódicas cada dos semanas sobre la
dirección y la usabilidad de la aplicación, los desarrolladores dan
retroalimentación a los clientes sobre los difíciles y lentos que serán los
cambios. Finalmente, los programadores en pareja se retroalimentan
constantemente sobre sus diseños y códigos.

✓ Coraje: Los desarrolladores deben tener el coraje de:

o Empiece con Soluciones Sencillas incluso cuando conozcan

enfoque más complicado,
o Resuelva los problemas de hoy y no los de mañana, Refactorizar el
código cuando sea necesario.
o Desechar el código cuando sea necesario.
o Proporcione Comentarios.
o Respecto esto incluye el respeto por los demás y respeto por uno
mismo, los miembros del equipo respetan el proyecto al esforzarse por
lograr una mayor calidad, respetan a los demás y consideran sus
comentarios.
 Prácticas en la XP

objetivos
Que el estudiante conozca las diferentes prácticas que se utilizan en programación extrema.

Prácticas en programación extrema.

Los proyectos de XP utilizan una variedad de prácticas para satisfacer los valores, Algunas de las
prácticas más comunes son:

1. Tener un cliente en el sitio: Si es posible, mantenga un cliente en el sitio para que los
desarrolladores puedan hacer preguntas cuando sea necesario. Idealmente ese cliente debería
tener la autoridad para tomar decisiones para que el trabajo pueda seguir avanzando sin esperar
la aprobación de la gerencia.

2. El juego de la planificación: El juego de la planificación tiene dos partes, Planificación de

lanzamiento y planificación de iteración.

a) Durante la planificación de lanzamiento, el equipo se centra en el próximo lanzamiento

del cliente. Para hacer eso, las historias de los usuarios se escriben en tarjeta. El equipo
baraja las cartas y trata de determinar cuántas de las cartas se pueden implementar a
tiempo para la próxima versión del cliente. Donde los desarrolladores se aseguran de
que las estimaciones de tiempo para las historias sean razonables, los clientes ayudan a
decidir qué historias son las más importantes. Juntos, los desarrolladores y los clientes
crean un plan de lanzamiento que sea realista y que le brinde a los clientes la
funcionalidad que más necesitan lo más rápido posible.

b) La segunda parte del juego de planificación es la planificación de interacción. Al

comienzo de cada interacción, generalmente cada una a 3 semanas, el equipo se reúne
para desarrollar un plan para esa interacción. El equipo selecciona las historias de
usuario del plan de lanzamiento actual, comenzando con las historias destacadas más
importantes. Una vez que el equipo ha elegido las tareas más críticas para agregar a la
siguiente interacción. Los desarrolladores eligen las tareas que realizarán de manera
auto organizada. Cada desarrollador estima la cantidad de tiempo necesario para las
tareas que eligió, idealmente cada tarea no debería tomar más de 1 a 3 días.

3. Reuniones de sincronización: Se empieza cada día con una reunión de sincronización,

generalmente estando de pie, una reunión breve que dura 15 minutos o menos. Todos los
miembros del equipo, incluido el cliente en el lugar, deben asistir a la reunión de sincronización
y contar brevemente lo que hicieron desde la última reunión. Lo que esperan lograr antes de la
próxima reunión y cualquier problema que prevén para realizar ese trabajo.
4. Pequeños lanzamientos frecuentes: Idealmente, cada lanzamiento debe tener un período de
tiempo relativamente corto para que pueda aproximar a los clientes del todo útil lo antes
posible.

Esto también le permite obtener comentarios frecuentes de los clientes. Las interacciones
frecuentes también obligan a realizar pruebas de integración para que pueda eliminar los
errores antes.

5. Utilice metáforas instintivas: Si es posible, utilice metáforas fáciles de entender para describir
el sistema. Si los clientes y los desarrolladores comparten una metáfora común, es más probable
que compartan una visión común de la aplicación, por ejemplo. Muchos sitios web utilizar la
metáfora del carrito de compra, el simple hecho de decirles a los militantes que tienen un carrito
de compras les permite hacer varias suposiciones razonables, por ejemplo, sabes que pueden
agregar cosas al carrito, quitar cosas del carrito e ir al área de pago para comprar lo que haya en
el carrito que en este momento. Otras metáforas de programación comunes incluyen la
papelera, el escritorio, el archivo y el documento.

Si puedes describir tu sistema como una metáfora digestiva, será más fácil para los usuarios
aprender.

6. Diseño simple y refactorizar cuando sea necesario: Manténgalos diseño simple, utiliza el
diseño más simple que pueda manejar la tarea inmediata, si es necesario, puede modificar el
diseño más tarde para satisfacer necesidades posteriores, si hace que el diseño sea demasiado
complicado desde el principio, puede terminar perdiendo mucho tiempo, construyendo una
característica que nunca se usa.

Refactorizar cuando sea necesario debido a que mantiene el diseño simple, a veces tendrá que
volver a trabajar con el código activo. Para que hagas cosas nuevas, no tenga miedo de factorizar
cuando sea necesario. Programación extrema le dice que use el diseño más simple posible para
manejar sus necesidades actuales y luego lo de factorice más tarde. Si es necesario para que se
acerque al diseño final.

7. Utiliza estándares de codificación: Para facilitar que cada miembro del equipo modifique
cualquier parte del código, el equipo debe adoptar estándares y convenciones de codificación;
si todo el Código utiliza un estilo coherente, es más fácil de leer, comprender y modificar para
cualquiera.

8. Promover la generalización: anime a los miembros del equipo a aprender sobre cada parte
del sistema, idealmente todos deberían saber tanto como sea posible sobre cada rincón y grieta
de la aplicación.

Eso permite que cualquiera trabaja en cualquier parte del código y adquirir nuevas habilidades
para convertirse en miembros más valioso del equipo. Para las tareas de programación más
típicas, como el diseño de bases de datos, la creación de interfaces de usuario y la integración
con sistemas externos, Todos deberían al menos aprender los conceptos básicos.
9. Programación por pares: Esto le brinda revisiones de Código constante y aumenta la calidad
del código.

10. Probar constantemente: Pruebe a fondo. Pruebe todo. Prueba a menudo, incluso si un
fragmento de código pasa todas sus pruebas en una interacción. Sigan probándolo, en futuras
integraciones, automatice la mayor cantidad de pruebas posibles para que sea más fácil
ejecutarla.

11. Integrar continuamente: Toda la aplicación debe reconstruirse, integrarse y probarse con la
mayor frecuencia posible para eliminar errores.

Muchos equipos reconstruyen y prueban el sistema semanalmente o incluso todas las noches.
Si la prueba es automática, puede iniciarla antes de apagar las luces cuando salga por la puerta
y luego revisar el registro de prueba a primera hora de la mañana.

12. Trabajar de forma sostenible: Debe establecer un ritmo de trabajo que todos los miembros
del equipo puedan mantener indefinidamente. Los ciclos breves de publicación e iteración
brindan muchos beneficios, pero debe mantenerlos breves al no incluir demasiado en cada ciclo.

No al hacer que los desarrolladores trabajen 60 horas a la semana anime por la fuerza si es
necesario a los desarrolladores a trabajar solo 40 horas a la semana y desaliente las horas extras.
Empujar al equipo para que cumpla con plazos arbitrariamente abreviados conduce al
agotamiento, Mal humor y rotación de empleados. Los desarrolladores descansados son más
especialistas y productivos.

13. Utiliza el desarrollo basado en pruebas:

En el desarrollo basado en pruebas TDD, comienza con un fragmento de código que inicialmente
puede estar vacío o un código auxiliar que no hace nada. Luego elija una función que el código
debería realizar y escriba una prueba que verifique que la función trabaje correctamente. A
continuación, verá si pasa la prueba. Normalmente el código falla porque aún no le ha
proporcionado ningún código para realizar la función que está probando. Después de que el
código falle, escriba un código nuevo para que pase la prueba. Agregue el fragmento de código
más simple que pueda satisfacer las pruebas y nada más, no anticipé funciones futuras,
escribiendo código para manejarlas también. Llegará a eso más tarde.
SCRUM

Objetivos:

• Conocer el marco de trabajo de SCRUM

• Exponer los componentes de SCRUM

SCRUM

La guía de SCRUM de scrum.org define SCRUM como un marco de trabajo por el cual las personas
pueden abordar problemas complejos a la vez que entregan productos del máximo valor posible de
forma productiva y creativa. Es un conjunto de buenas prácticas para la gestión de proyectos.

SCRUM tiene como base entregas parciales y regulares del producto final iniciando con las
funcionalidades más importantes para el cliente. Está especialmente indicado para proyectos donde
se necesita obtener resultados pronto o donde los requisitos son cambiantes y la competitividad, la
flexibilidad y la productividad son vitales. Esto permite no alargar demasiado las entregas y
reaccionar ante cualquier cambio no previsto.

El marco de trabajo de SCRUM está formado por:

Roles: compuestos por el propietario del producto el equipo de desarrollo y el SCRUM master, son
los encargados de entregar productos de forma interactiva e incremental maximizando las
oportunidades de retroalimentación.

Eventos: son utilizados para crear regularidad y minimizar la necesidad de reuniones no definidas.

Artefactos: representan trabajo o valor para brindar transparencia y oportunidades de inspección y

adaptación.

Reglas: se encarga de unir los roles, eventos y artefactos gobernando las relaciones y la interacción
entre ellos. De esta regla seguiremos hablando en este vídeo clase en forma de principios,
fundamentos y valores, dejando los otros componentes para sesiones posteriores.

Principio de SCRUM.

SCRUM es uno de los modelos más utilizados dentro de las metodologías ágiles muchos de los
valores y principios del manifiesto ágil tiene su origen en SCRUM

1. Individuos e interacciones sobre procesos y herramientas. Este principio destaca la importancia

de la confianza hacia las personas, sus interacciones y los equipos. El equipo SCRUM identifica lo
que hay que hacer y debe tomar la responsabilidad de hacerlo, solventando posibles impedimentos
los que estén en su alcance.

2. Software funcionando sobre documentación extensiva: se requiere que al final de cada sprint se
entregue un producto funcionando la documentación es vista como un producto intermedio sin
valor de negocio
3. Colaboración con el cliente sobre la negociación contractual: el dueño del producto es
responsable de las relaciones que existe con los clientes finales y parte del equipo de SCRUM y debe
asegurarse que el producto construido tenga el mayor valor para el negocio

4. respuesta al cambio sobre seguir un plan: el progreso es medido al final de cada sprint y la lista
de características pendiente está visible continuamente y para todos los miembros, esto permite
que el alcance del proyecto cambie constantemente en función de la retroalimentación provista por
los clientes, fomentar el cambio es una ventaja competitiva.

Fundamentos de SCRUM

SCRUM tiene como base la teoría de control de procesos empíricos, esta afirma que el conocimiento
procede de la experiencia y de tomar decisiones tomando como punto de partida lo que ya se
conoce. SCRUM utiliza un enfoque interactivo e incremental para optimizar la predictibilidad y el
control de riesgo.

Los pilares de la implementación del control de procesos empíricos son transparencia, inspección y
adaptación.

Transparencia: todos los aspectos relacionados al proceso deben estar disponibles para aquellos
que son responsables del resultado. La transparencia requiere que dichos aspectos sean definidos
por un estándar común logrando que todos compartan un entendimiento común de lo que se están
viendo.

Inspección: el equipo de SCRUM y demás involucrado debe revisar frecuentemente a los artefactos
de SCRUM y avanzar hacia la meta del sprint, esto para identificar posibles variaciones no deseadas.
Su inspección no debe ser tan frecuente que interfiera con el trabajo.

Adaptación: si en una inspección se determina que uno o más aspectos de un proceso se desvían
fuera de los límites aceptables y que el producto resultante será inaceptable, se debe replantear el
proceso, se debe realizar un ajuste lo antes posible para minimizar una mayor desviación.

SCRUM utiliza cuatro eventos formales para inspección y adaptación: planificación de sprint, SCRUM
diario, revisión de sprint, retrospectiva del sprint.

Valores de SCRUM

Cuando los valores de coraje, enfoque, compromiso, respeto y apertura son incorporados y vividos
por el equipo SCRUM, los pilares de SCRUM de transparencia inspección y adaptación cobran vida y
generan confianza para todos. Los miembros del equipo de SCRUM aprenden y exploran esos
valores mientras trabajan con los roles, eventos y artefactos de SCRUM.

Coraje: los miembros del equipo de SCRUM tienen el coraje de hacer lo correcto y trabajar en
problemas difíciles, deben apoyarse entre compañeros y así tener el coraje de asumir compromisos
desafiantes, que le permitan crecer como profesionales y como equipo.

Enfoque: todos se enfocan en el trabajo del sprint y el objetivo del equipo SCRUM, esto permite
que al final de cada sprint, se entregue un producto de alta calidad.

Compromiso: las personas se comprometen personalmente a lograr los objetivos del equipo SCRUM
Respeto: los miembros del equipo de SCRUM se respetan entre sí para ser personas capaces e
independientes. Debido a que los miembros del equipo trabajan de forma conjunta, compartiendo
tanto éxito como fracaso, se fomenta el respeto mutuo

Apertura: el equipo SCRUM y sus partes interesadas acuerdan estar abiertos sobre todo al trabajo
y los desafíos para llevarlos a cabo. El marco de trabajo enfatiza la transparencia y la discusión
abierta de los problemas

La educación es el arma más poderosa que puede usar para cambiar el mundo hasta la próxima
Roles scrum

bienvenido a esta video clase los objetivos que veremos en esta vídeo clase
son

 identificar los roles principales

 conocer las funciones de cada rol

roles de scrum

según la guía de scrum el equipo está formado por un propietario o dueño de

producto, el equipo de desarrollo y un scrum master.

Los equipos scrum tienen como características que son auto organizados y
multifuncionales, los equipos auto organizados deciden sobre la mejor manera
de realizar su trabajo en lugar de ser dirigido por otros fuera del equipo, los
equipos multifuncionales tienen todas las competencias necesarias para
realizar el trabajo sin depender de otros que no formen parte del equipo, el
modelo de equipo en scrum está diseñado para optimizar la flexibilidad la
creatividad y la productividad

Los equipos de scrum entregan productos de forma iterativa e incremental

maximizando las oportunidades de retroalimentación, las entregas
incrementales del producto terminado garantizan que siempre está disponible
una versión potencialmente útil del
producto.

según la guía de scrum

El equipo está formado por un propietario o dueño de producto, el equipo de
desarrollo y un scrum master; los equipos de scrum tienen como características
que son auto
organizados y multifuncionales los equipos auto organizados deciden sobre la
mejor manera de realizar su trabajo en lugar de ser dirigidos por otro fuera del
equipo
los equipos multifuncionales tienen todas las competencias necesarias para
realizar el trabajo sin depender de otros que no forman parte del equipo, el
modelo de equipo en scrum está diseñado para optimizar la flexibilidad la
creatividad y la productividad.

Los equipos de scrum entregan productos de forma iterativa e incremental

maximizando las oportunidades de retroalimentación. las entregas
incrementales de producto terminado garantizan que siempre esté disponible
una versión potencialmente útil del
producto.
El propietario del producto
la guía de scrum plantea que el propietario del producto es responsable de
asegurar el
máximo valor del producto como resultado del trabajo del equipo de desarrollo
la forma en que se hace esto puede variar ampliamente entre organizaciones,
equipo scrum e individuos

El propietario del producto es la única persona responsable de gestionar la

cartera de productos lo cual incluye:

 Expresar claramente los elementos de la pila del producto

 Ordenar los elementos en la pila del producto para lograr mejores

objetivos y misiones.

 Optimización del valor del trabajo que realiza el equipo de desarrollo

 Asegurarse de que la pila del producto sea visible, transparente y clara

para todos y muestre en que trabajara el equipo scrum a continuación.

 Asegurarse de que el equipo de desarrollo comprenda los elementos de

la pila del producto al nivel necesario.

El propietario del producto es una persona no un comité pueda representar los

deseos de un comité en pila del producto, pero aquellos que desean cambiar la
prioridad de un elemento le deben dirigirse al dueño del producto

El equipo de desarrollo
de acuerdo a la guía de scrum el equipo de desarrollo está formado por
profesionales que realizan el trabajo de entregar un incremento de producto
terminado al final de cada sprint se requiere un incremento de listo en la
revisión de sprint sólo los miembros del equipo de desarrollo crean en el
incremento

los equipos de desarrollo están estructurados y facultados por la organización

para organizar y gestionar su propio trabajo. Las sinergias resultantes
optimizan la eficiencia y eficacia general del equipo de desarrollo

Los equipos de desarrollo tienen las siguientes características:

 son auto organizados, nadie ni siquiera el scrum master le dice al equipo

de desarrollo cómo convertir la pila del producto e incrementos
funcionales.

 los equipos de desarrollo son multifuncionales con todas las habilidades

necesarias como equipo para crear incrementos del producto.
  scrum no reconoce títulos para los miembros del equipo de desarrollo
independientemente del trabajo que está realizando la persona.

scrum no reconoce sub equipos en el equipo de desarrollo independientemente

de los
dominios que deban abordarse como pruebas, arquitectura, operaciones o
análisis de negocio, los miembros del equipo de desarrollo individual pueden
tener habilidades especializadas y áreas de enfoque, pero la responsabilidad
pertenece al equipo de desarrollo en su conjunto.

tamaño del equipo de desarrollo

el tamaño del equipo de desarrollo óptimo es lo suficientemente pequeño como
para
seguir siendo ágil y lo suficientemente grande como para completar un trabajo
significativo dentro de un sprint menos de tres miembros del equipo de
desarrollo reducen la iteración y dan como resultado ganancias de
productividad menores

los equipos de desarrollo más pequeño pueden encontrar limitaciones de

habilidades durante el sprint lo que hace que el equipo de desarrollo no puede
entregar un
incremento potencialmente liberable

tener más de nueve miembros requiere demasiada coordinación los grandes

equipos de desarrollo generan demasiada complejidad para que un proceso del
perico sea útil los roles de propietario del producto y scrum master no se
incluye en este recuento a menos que también estén ejecutando el trabajo del
sprint.

El scrum master es responsable de promover y apoyar al proceso como se

define en la guía de scrum

el scrum master ayuda a todos a comprender la teoría las prácticas, las reglas
y los
valores de scrum

el scrum master es un líder servidor del equipo scrum

el scrum master ayuda a quienes están fuera del equipo de scrum a

comprender cuáles de sus integraciones son útiles y cuáles no.

el scrum master ayuda a todos a cambiar estas integraciones para maximizar el

valor creado por el equipo scrum

el scrum master colabora con propietario del producto de las siguientes formas:

 asegurar que los objetivos el alcance y el dominio del producto sea

entendido por todo el equipo scrum
  encontrar técnicas para una gestión eficaz de la pila del producto

 ayudar al equipo scrum a comprender la necesidad de elementos claros

y concisos en la pila del producto

 comprensión de la planificación de productos en un entorno empírico

 asegurarse de que el propietario del producto sepa cómo organizar la

cartera de producto para maximizar el valor

 comprender y practicar la agilidad

 facilitar los eventos de scrum según se solicite o sea necesario

El scrum master apoya al equipo de desarrollo de las siguientes maneras:

 Guía al equipo de desarrollo en auto organización y funcionalidad

cruzada

 ayuda al equipo de desarrollo a crear productos de alto valor

 eliminación de impedimentos al progreso del equipo de desarrollo

 facilitar los eventos de scrum según se solicite o se necesite

 orienta el equipo de desarrollo en entorno organizacionales en los que

scrum aún no se ha adaptado comprendido por completo

según la guía de scrum el scrum master sirve a la organización de varias

maneras que incluyen:

 Liderar y asesorar a la organización en su adopción de scrum

 Planificación de implementaciones de scrum dentro de la organización

 Ayudar a los empleados y a las partes interesadas a comprender y

aplicar scrum
 y el desarrollo de productos empíricos

 Causar cambios que aumenten la productividad del equipo

 Trabajar con otros scrum master para incrementar la efectividad de la

 aplicación de scrum en la organización
12 - EVENTOS DE SCRUM

Objetivos

• Conocer los eventos de scrum

• Identificar la forma de aplicación de los eventos

Eventos de scrum

Los eventos de scrum tienen bloques de tiempo definidos que nos limita a una
duración máxima. Una vez que comienza un sprint su duración es fija y no se puede
acortar ni alargar. Los eventos restantes pueden terminar cuando se logre el
propósito del evento. El objetivo es que se invierta una cantidad adecuada de tiempo
sin permitir el desperdicio en el proceso.

Además del sprint en sí, en el cual ocurren los demás eventos cada uno de estos
representa una oportunidad para inspeccionar y adaptar algo, permitiendo una
transparencia e inspección crítica y no incluir a alguno de estos eventos supondrá
una reducción en la transparencia y se pierde la oportunidad de inspeccionar y
adaptar.

La guía de scrum reconoce los siguientes eventos:

El sprint

Es el elemento fundamental de scrum. Posee un bloque de tiempo de un mes o

menos durante el cual se crea un incremento de producto terminado.
El sprint contiene los siguientes eventos:

Durante el sprint debemos tomar en cuenta las siguientes consideraciones:

• No realizar cambios que pongan en riesgo la meta del sprint

• Los objetivos de calidad no se pueden disminuir.
• El alcance puede aclararse y renegociarse, entre el propietario del producto y
el equipo de desarrollo a medida que se aprende más.
• El sprint está limitado a un mes calendario. El sprint permite la previsibilidad
al garantizar la inspección y adaptación del progreso hacia una meta, al menos
cada mes calendario.

Planificación del sprint

El trabajo a realizar en el sprint se planifica de forma colaborativa por todo el equipo

scrum. La planificación del sprint tiene un bloque de tiempo máximo de 8 horas para
un sprint de un mes, el scrum master asegura que el evento se lleve a cabo y que
los asistentes comprendan su propósito.

Durante la planificación del sprint se realizan dos tareas:

1. La primera determinar ¿qué se puede hacer en este sprint? El equipo de

desarrollo trabaja para pronosticar la funcionalidad que se está desarrollando
durante el sprint.
El propietario del producto analiza el objetivo que debe alcanzar el sprint y los
elementos de la pila del producto que se tomará. La entrada de este evento es
 la pila del producto, el último incremento de producto, la capacidad proyectada
del equipo de desarrollo durante el sprint y el desempeño anterior del equipo
de desarrollo. La cantidad de elementos seleccionados de la pila del producto
para el sprint depende únicamente del equipo de desarrollo. Solo el equipo de
desarrollo puede evaluar lo que pueden lograr durante el próximo sprint.

2. La segunda tarea a considerar durante la planificación del sprint es especificar

¿cómo se realizará el trabajo elegido? habiendo establecido el objetivo del
sprint y seleccionado los elementos de la pila del producto para el sprint. El
equipo de desarrollo decide cómo construir esta funcionalidad de un
incremento de producto terminado durante el sprint.

Los elementos de la pila del producto seleccionados para este sprint más el
plan para entregarlos se dominan pila del sprint. El equipo de desarrollo
generalmente comienza diseñando el sistema y el trabajo es necesario para
convertir la pila del producto en un incremento de producto funcional.

El trabajo planificado para los primeros días del sprint por el equipo de
desarrollo se descompone en tareas al final de esta reunión. A menudo en
bloque de tiempo de un día o menos, si el equipo de desarrollo determina que
tiene demasiado o muy poco trabajo puede renegociar los elementos
seleccionados de la lista de trabajos pendientes con el propietario del
producto.

El equipo de desarrollo también puede invitar a otras personas a asistir para

brindar asesoramiento técnico. Al final de la planificación del sprint el equipo
de desarrollo debería poder explicar al propietario del producto y al scrum
master cómo pretende trabajar como un equipo auto organizado para lograr el
objetivo del sprint.

Scrum diario

El scrum diario es un evento con un bloque de tiempo de 15 minutos y se lleva a

cabo todos los días. Aquí se planea el trabajo para las próximas 24 horas, esto
optimiza la colaboración y el rendimiento del equipo al inspeccionar el trabajo desde
el último scrum diario. Se recomienda que el scrum diario se lleve a cabo de pie, a la
misma hora y en el mismo lugar todos los días. El equipo de desarrollo utiliza el
scrum diario para inspeccionar el progreso hacia el objetivo del sprint. Todos los días
el equipo de desarrollo debe comprender cómo pretende trabajar en conjunto con un
equipo auto organizado para lograr el objetivo del sprint y crear el incremento al final
del sprint.

La estructura de la reunión la establece el equipo de desarrollo y puede llevarse a

cabo de diferentes maneras si se enfoca en el progreso hacia el objetivo del sprint.
Por ejemplo, cada miembro del equipo se puede enfocar y responder las siguientes
preguntas:
 • ¿Qué actividades realice ayer?
• ¿Qué actividades realizaré hoy?
• ¿Veo algún impedimento? para alcanzar el objetivo del sprint

El equipo de desarrollo o los miembros del equipo a menudo se reúnen

inmediatamente después del scrum diario para discusiones detalladas o para adaptar
o volver a planificar el resto del trabajo del sprint. El scrum master asegura que el
equipo de desarrollo tenga la reunión, pero el equipo de desarrollo es responsable
de realizar el scrum diario, el scrum master le enseña al equipo de desarrollo a
mantener el scrum diario dentro del bloque de tiempo de 15 minutos. El scrum diario
mejora la comunicación elimina otras reuniones e identifica impedimentos para el
desarrollo para su eliminación, resaltan y promueve la toma de decisiones rápida y
mejoran el nivel de conocimiento del equipo de desarrollo. Esta es una reunión clave
de inspección y adaptación.

Revisión del sprint

Al final del sprint se lleva a cabo una revisión para inspeccionar el incremento y
actualizar la pila del producto. Durante la revisión del sprint el equipo scrum y las
partes interesadas colaboran sobre lo que se hizo en el sprint. Esta es una reunión
informal no una reunión de estado y la presentación del incremento está destinada a
generar comentarios y fomentar la colaboración.

Esta es una reunión con un bloque de tiempo de 4 horas como máximo para un sprint
de un mes, el scrum master asegura que el evento se lleve a cabo y que los
asistentes comprendan su propósito, el scrum master les enseña a todos los
involucrados a mantenerlo dentro del bloque de tiempo.

La revisión del sprint incluye los siguientes elementos:

 • Asiste el equipo scrum y las partes interesadas invitadas por el propietario del
producto.
• El propietario del producto explica qué elementos de la pila del producto se
han terminado y cuáles no.
• El equipo de desarrollo explica lo que se realizó durante el sprint los problemas
que encontró y cómo se resolvieron esos problemas.
• Todo el grupo colabora sobre qué hacer a continuación de modo que la
revisión del sprint proporciona información valiosa para la planificación del
sprint siguiente.
• Revisión de la línea de tiempo, el presupuesto y las capacidades potenciales
para las próximas versiones anticipadas de la funcionalidad o capacidad del
producto.

El resultado de la revisión del sprint es una pila del producto revisada que define los
elementos probables para el próximo sprint. La pila de producto también se puede
ajustar en general para encontrar nuevas oportunidades.

Retrospectiva del sprint

La retrospectiva del sprint, es una oportunidad para el equipo scrum se inspeccione

a sí mismo y cree un plan para implementar mejora durante el próximo sprint. Ocurre
después de la revisión del sprint y antes de la siguiente planificación del sprint.

Este evento tiene un bloque de tiempo de 3 horas como máximo para sprint. El scrum
master asegura que la reunión se lleve a cabo sea positiva y productiva.

El propósito de la retrospectiva del sprint es:

• Inspeccionar cómo fue el último sprint. Con respecto a las personas las
relaciones los procesos y las herramientas

• Identificar elementos para mejorar.

 • Plan de mejoras. Para implementar mejoras en la forma en que el equipo
scrum hace su trabajo.

Durante cada retrospectiva de sprint, el equipo scrum plantea forma de aumentar la

calidad del producto mejorando los procesos de trabajo o adaptando la definición
determinada si corresponde y no riñe con los estándares del producto o de la
organización. Al final de la retrospectiva del sprint el equipo scrum debería haber
identificado las mejoras que implementará en el próximo sprint
Artefactos de Scrum
Objetivos

 Conocer los principales artefactos de Scrum.

 Exponer la función de cada artefacto.
Artefactos de Scrum según la guía de Scrum los artefactos están diseñados
específicamente para maximizar la transparencia de la información más importante para
que todos tengan la misma comprensión, los artefactos son:

 Pila del producto.

 Pila del sprint.
 Incremento de producto
Pila del producto.
El principal artefacto de Scrum es la pila del producto este consiste en una lista ordenada
de todo lo que se necesita en el producto es la única fuente de requisito para cualquier
cambio que se realiza en el producto el propietario del producto es responsable de la pila
del producto incluido su contenido y disponibilidad.
Es de suma importancia que exista una clara priorización ya que esta priorización
determina el orden en el que el equipo de desarrollo transformará las características los
ítems en un producto funcional terminado la pila del producto es dinámica se mantiene en
constante cambio para identificar lo que el producto necesita para ser apropiado
competitivo y útil el desarrollo más temprano del mismo establece los requisitos
inicialmente conocidos y mejor entendibles y evoluciona a medida que evoluciona el
producto y el entorno en el que se utiliza
la pila el producto enumera todas las características funciones requisitos mejoras y
correcciones que constituyen los cambios que se realizarán en el producto e inversiones
futuras los elementos de la pila del producto tienen los atributos de descripción pedido
estimación y valor. a menudo incluyen descripciones de las pruebas que demostraran su
integridad cuando se termina a medida que un producto se usa y gana valor y el mercado
proporciona retroalimentación la pila del producto se convierte en una lista más grande y
exhaustiva los requisitos nunca dejan de cambiar por lo que es un artefacto activo los
cambios en los requisitos comerciales las condiciones del mercado o la tecnología pueden
provocar cambios en la pila del producto.
Eficiencia en la pila del producto el refinamiento de la pila del producto es el acto de
agregar detalles estimaciones y pedidos a los elementos de la pila del producto este es un
proceso continuo en el que el propietario del producto y el equipo de desarrollo colaboran
en los detalles de los elementos invierte en esfuerzo de exploración y especificación de la
manera más inteligente posible para evitar duplicar el esfuerzo y desperdicios por esto se
fomenta que los elementos más prioritarios están expresados con un nivel de detalle
mucho mayor que los ítems de menor prioridad los cuales están descritos a un nivel más
alto ya que son los más susceptibles de ser alterados o reemplazados con la priorización
en mente y aplicando el principio de Pareto podemos decir que el 20 por ciento de las
características de un producto resuelven el 80% de la necesidad de negocio que le da
origen de manera recursiva el 20 por ciento de las características que quedan solventarán
el 80 por ciento de las necesidades restantes por esta razón priorizar los elementos en la
pila el producto es un factor vital.
Pila del Sprint
La pila del sprint es el conjunto de elementos que fueron seleccionados de la pila del
producto para realizar en el sprint más un plan para entregar el incremento del producto y
alcanzar el objetivo del sprint, la pila del sprint es una estimación realizada por el equipo
de desarrollo sobre qué funcionalidad estará en el próximo incremento y el trabajo
necesario para entregar esa funcionalidad en un incremento terminado la pila el Sprint
hace visible todo el trabajo que el equipo de desarrollo identifica como necesario para
alcanzar la meta del sprint la pila el sprint es un plan con suficiente detalle para que los
cambios en progreso se puedan entender en el Scrum diario el equipo de desarrollo
puede modificar la pila del sprint a medida que se desarrolla a medida que se requiere
trabajo nuevo el equipo de desarrollo lo agrega a la pila de sprint a medida que se realiza
o completa el trabajo se actualiza el trabajo restante estimado cuando los elementos del
plan se consideran innecesario se eliminan con el equipo de desarrollo puede cambiar su
pila de sprint este artefacto es una imagen muy visible y en tiempo real del trabajo que el
equipo de desarrollo planea realizar durante el sprint y pertenece únicamente al equipo de
desarrollo.
Incremento.
Este artefacto es la suma de todos los elementos de la pila del producto que fueron
completados durante un sprint y el valor de los incrementos de todos los sprint anteriores
al final de un sprint el nuevo incremento debe estar terminado lo que significa que debe
estar en condiciones de uso y cumplir con la definición de terminado del equipo Scrum. El
incremento es un paso hacia una visión o una meta el incremento debe estar en
condiciones utilizables independientemente de si el propietario del producto decide
liberarlo
DevOps
Objetivos
✓ Describir la metodología DevOps.
✓ Presentar las razones para utilizar DevOps.
El término DevOps proviene de la combinación de dos palabras en inglés
desarrollado y operaciones, DevOps se utiliza para definir un movimiento que
nace de la necesidad de reducir las barreras entre los equipos de desarrollo
y operaciones de una empresa.

DevOps y sus prácticas técnicas, arquitectónicas y culturales representan

una convergencia de muchos movimientos filosóficos y de gestión. DevOps
es el resultado de aplicar los principios más confiables y conjunto de
conocimientos de Lean, teoría de las restricciones, el sistema de producción
de Toyota, ingeniería de resiliencia organizaciones de aprendizaje, cultura de
seguridad, factores humanos y muchos otros.

Otros contextos valiosos de los que se basa DevOps incluye confiar en las
culturas de gestión, el liderazgo de servicio y la gestión del cambio
organizacional, si bien se puede considerar que la base de DevOps se deriva
de Lean, la teoría de las restricciones y el movimiento Toyota muchos
también ven a DevOps como la continuación lógica del software ágil.

El resultado es calidad, confiabilidad, estabilidad y seguridad a un costo y

esfuerzo cada vez más bajos, con un flujo y confiabilidad acelerados en toda
la cadena de valor de la tecnología, incluida la gestión de productos,
desarrollo, control de calidad y operaciones de las unidades de TI.

De manera simplificada DevOps es un proceso para desarrollar, entregar y

operar software, hay muchas definiciones impulsadas comercialmente que
relacionan estrechamente DevOps con algunas herramientas de
construcción y entrega o plataforma de infraestructura en la nube.
Podemos decir que DevOps es un enfoque basado en los principios “Lean”
y “Ágiles”, mediante los cuales los dueños de la empresa y los departamentos
de desarrollo, operaciones y calidad, colaboran para entregar el software de
forma continua, permitiendo a la empresa aprovechar con mayor rapidez las
oportunidades del mercado y reducir el tiempo necesario para incorporar la
retroalimentación de los clientes.

Razones para utilizar DevOps.

❖ Mejora la comunicación.
❖ Cartera de productos comunes.
❖ Mejorar calidad.
❖ Metodologías comunes.
❖ Gestionar lanzamientos.
❖ Entrega continua.
❖ Integración continua.
❖ Infraestructura como código.
Hay diferentes razones por las que una empresa decide adoptar DevOps,
normalmente la adopción de la filosofía DevOps está relacionada con la
mejora en la calidad del software y una mejor forma de gestionar su
lanzamiento cuando una empresa adopta DevOps el primer paso es mejorar
la comunicación entre equipos. Esta característica de DevOps es compartida
por las metodologías ágiles y sólo se puede implementar con una
armonización de las herramientas utilizadas en toda la empresa. Este cambio
no siempre es aceptado fácilmente por todos los empleados de TI, la
resistencia inicial suele ser el cambio de cultura necesario para adoptar
DevOps.
Adoptar DevOps significa cambiar la forma en que pensamos en la
infraestructura, cuando sea posible migrarla a la nube, adoptar la
infraestructura como código y adoptar la compatibilidad del caso utilizando
sprint para administrar el trabajo, esto exige que todos los equipos utilicen
metodologías de proyectos comunes y creen una cartera de productos común
que se comparta con el equipo de desarrollo, en particular cuando el proyecto
involucra nueva infraestructura con DevOps podemos aceptar algún
procedimiento para mejorar la calidad del software, para ello debemos tener
una integración continua y una entrega continua, con esto es fácil identificar
errores cuando insertamos el código en el repositorio, además debido a que
contamos con entrega continua podemos pasar el software directamente a
control de calidad más veces al día, esto asegura una verificación continua
del software y una retroalimentación continua.

La cadena de DevOps.
La coordinación es tan importante en DevOps debido a que se progresa de
acuerdo con una cadena de herramientas, básicamente esta cadena de
herramientas se utiliza para definir cada paso del proceso de producción en
la diapositiva se muestran las fases de DevOps de una versión de software
cada fase puede ser gestionada por un equipo diferente por esta razón es
importante una coordinación y una comunicación sólidas y claras.
✓ La primera fase es el código. Durante esta fase se crea el código
para el software cada desarrollador coloca el código en un repositorio
común por ejemplo Git y esto conduce al siguiente eslabón de la
cadena.
✓ La segunda fase es la construcción. Esta fase está directamente
relacionada con la práctica de integración continua, el código
previamente comprometido se descarga en el servidor de compilación
y luego se construye de forma automática, al mismo tiempo se realiza
una prueba por primera vez, si todos los elementos de la prueba tienen
éxito comienza la siguiente fase.
✓ La tercera fase. Es la fase de prueba, el software construido
previamente se prueba mediante algún proceso automático, pero esta
vez el software se prueba por completo, en la fase de compilación solo
se ejecuta la prueba unitaria relacionada con la funcionalidad
específica que lanzamos, si el sistema no encuentra ningún problema
el software pasa a la siguiente fase, en caso de falla el software será
rechazado por un sistema automático, avisará al desarrollador de eso.
✓ La cuarta fase. Es la configuración, esta fase requiere una clara
distinción cuando contamos con buenas prácticas de DevOps
podemos tener un lanzamiento continuo, es decir el lanzamiento
continuo del software a producción, sin embargo, para el software que
es de misión crítica esta fase normalmente se divide en dos partes
diferentes:
• La primera versión está destinada a un número limitado de
servidores destinados para probar nuevo software.
✓ La quinta fase es la liberación. En esta fase se configura el servidor,
así como la infraestructura para el nuevo software, esta fase define la
infraestructura como código, el servidor se crea y administra mediante
el código, la infraestructura como el código es el núcleo DevOps, esta
brinda la capacidad de crear la infraestructura para un nuevo servidor,
esto garantiza la integridad de cada nueva versión porque se reduce
la interacción humana y se mejora la integridad de la versión.
✓ La sexta fase es el seguimiento. Esto es extremadamente importante
para proporcionar comentarios continuos sobre nuestro software e
infraestructura, el monitoreo es muy importante en DevOps porque
permite al desarrollador obtener comentarios sobre el software,
incluido un promedio de falla, el tipo de falla, entre otros; al mismo
tiempo puede usarse para verificar las métricas del servidor y
 proporcionar comentarios para el ajuste de escala automática. La
coordinación y la comunicación son cruciales para poner en marcha la
cadena de DevOps completa, esto se debe a que cada fase requiere
una buena coordinación en cada paso. Debemos garantizar una
retroalimentación confiable en cada paso porque debemos reaccionar
rápidamente a los errores y ajustar el sistema para evitar nuevos
errores.

Ciclo de vida de DevOps.

DevOps ofrece un enfoque que permite que el negocio, el desarrollo y las

operaciones colaboren continuamente para entregar software e incorporar los
comentarios de los clientes en menos tiempo y aprovechar las brechas en el
mercado donde actualmente no existe una solución.

El ciclo de vida de DevOps permitirá identificar elementos que estén

provocando desperdicios, duplicación de esfuerzo y los cuellos de botella en
el proceso mediante el establecimiento de un ciclo de retroalimentación de
innovación y mejora continua entre los clientes, los gerentes de producto, el
desarrollo de software y fabricación y soporte operativo, reducirá el tiempo
para obtener comentarios de los clientes y actuar sobre ellos, acelerará la
entrega de software y equilibra la velocidad, la calidad, el costo y el riesgo.
 16- FUNDAMENTOS DE DEVOPS
Objetivos.

• Presentar los pilares de DevOps

• Conocer las fases de evolución de DevOps.

Fundamento de DevOps

Si bien no existe una forma exacta de implementar DevOps que sea idéntica para todas las
organizaciones. Existen cuatro temas comunes en los que cualquier equipo u organización que
busque implementar DevOps deberá dedicar tiempo y recursos.

Estos son los cuatro pilares de uno DevOps efectivo.

• Colaboración
• Afinidad
• Herramientas
• Escalamiento

La combinación de estos cuatro pilares le permitirá abordar los aspectos culturales y técnicos de
la organización. Puede que una organización se concentre en uno o dos pilares a la vez mientras
intenta hacer cambios, pero en última instancia es la combinación de los cuatro pilares lo que
permitirá un cambio duradero y efectivo.

Es importante no pasar por alto los dos primeros pilares que abarcan las normas y valores.

El uso efectivo de herramientas es necesario para una transformación de DevOps exitosa pero
no es suficiente resolver los conflictos interpersonales y entre equipos que surgen dentro de las
organizaciones es fundamental para fomentar las relaciones duraderas que en última instancia
crean un entorno DevOps.

Colaboración

Colaboración es el proceso de construcción hacia un resultado específico a través de

interacciones de apoyo y el aporte de varias personas.
Un principio rector que dio forma al movimiento DevOps fue la corporación de los equipos de
desarrollo y operaciones de software. Antes de que un equipo pueda trabajar con éxito con otro
equipo que tiene un enfoque diferente las personas de un equipo deben poder trabajar entre
Sí.

Afinidad

Además del crecimiento y mantenimiento de las relaciones de colaboración entre individuos,

equipos y departamento dentro de una organización y en toda la industria en general. Es
necesario tener relaciones sólidas.

La afinidad es el proceso de construir interrelaciones de equipo, navegando por diferentes metas

o métricas teniendo en cuenta los objetivos organizacionales compartidos y fomentando la
empatía y el aprendizaje entre diferentes grupos de personas.

La afinidad también se puede aplicar entre organizaciones, lo que permite a las empresas
compartir historias y aprender unas de otras a medida que construimos un cuerpo colectivo de
conocimiento cultural y técnico dentro de nuestra industria.

Herramientas

Las herramientas son un acelerador que impulsan el cambio en función de la cultura y la dirección
Actual.

Las opciones de herramientas pueden percibirse como ganancias fáciles. Comprender por qué
son beneficiosos y su impacto en la estructura existente es importante para evitar problemas
ocultos en equipos y organizaciones.

No examinar los problemas en valores normas y estructuras organizacionales conduce a

condiciones invisibles de falla a medida que se acumula la deuda cultural.

Si las herramientas o la falta de ellas se interponen en el camino de que las personas con los
equipos trabajen bien juntos sus iniciativas no tendrán éxito. Si el costo de la colaboración es
alto no invertir en herramientas o peor aún invertir en herramientas deficientes aumenta este
costo.

Escalamiento

Es un enfoque en los procesos que las organizaciones deben adoptar a lo largo de sus ciclos de
vida. Más allá de simplemente considerar lo que significa abordar DevOps en grandes
organizaciones empresariales. El escalado tiene en cuenta como los otros pilares de DevOps
efectivos se pueden aplicar en todas las organizaciones a medida que crecen y maduran. Existen
diferentes consideraciones tanto técnicas como culturales para las organizaciones que operan a
diferentes escalas.

Evolución de DevOps

En el informe del estado de DevOps publicado por Puppet Labs, se identifican cinco prácticas
más una previa que las ordenaciones deben adoptar para tener éxito en su evolución con
DevOps.
Etapa 0 Construir las bases
Etapa 1 Normalización
Etapa 2 Estandarización
Etapa 3 Expansión
Etapa 4 Entrega de infraestructura
automatizada
Etapa 5 Autoservicio

Etapa 0: Construir la base.

• El monitoreo y las alertas son configurables, por el equipo que opera el servicio.
• Reutiliza los patrones de implementación, para crear aplicaciones o servicios.
• Reutiliza patrones de prueba, para crear aplicaciones o servicios
• Los equipos aportan mejoras a las herramientas proporcionadas por otros equipos.
• Las configuraciones se gestionan mediante una herramienta, de gestión de la
configuración

Etapa 1: Normalización

• Uso de un sistema de control de versiones.

• Las implementaciones se realizan en un conjunto estándar de sistemas operativos.

Etapa 2: Estandarización

• Las implementaciones se realizan en un solo sistema operativo.

• Se utilizan tecnologías estándares para el desarrollo.

Etapa 3: Expansión

• Las personas pueden trabajar sin un manual aprobado fuera del equipo.
• Se reutilizan los patrones de implementación para crear aplicaciones o servicios.
• Los cambios en la infraestructura son probados antes de implementarlos en producción.

Etapa 4: Entrega de infraestructura automatizada

• Las configuraciones del sistema están automatizadas.

• El aprovisionamiento está automatizado.
• Las configuraciones del sistema están en control de versiones.
• Los equipos de infraestructura utilizan el control de versiones.
• La configuración de las aplicaciones está en control de versiones.
• La configuración de las políticas de su seguridad está automatizada.
Etapa 5: Autoservicio

• Las respuestas a incidentes están automatizadas.

• Los recursos están disponibles a través de autoservicio.
• Las aplicaciones se reestructuran según las necesidades comerciales.
• Los equipos de seguridad participan en el diseño y desarrollo de tecnología.

Según el informe en la etapa 4 de la evolución de DevOps los equipos automatizaban las

configuraciones de las políticas de seguridad. Esto ayudó a los equipos a avanzar a la etapa 5
donde encontramos la práctica clave de la respuesta automatizada a incidentes. También las
organizaciones en la etapa 5 involucraron a sus equipos de seguridad en el diseño y la
implementación de tecnología.

Los equipos altamente evolucionados habían cultivado una poderosa combinación de entornos
de alta confianza, equipos autónomos y un alto grado de automatización y colaboración
interfuncional entre los equipos de aplicaciones operaciones y seguridad. El resultado, la
seguridad se convierte en una responsabilidad compartida entre los equipos de entrega que
están capacitados para realizar mejoras de seguridad. Los equipos de seguridad pueden actuar
como asesores lo que lleva a capacidades que mejoran la seguridad y ahorran tiempo como la
respuesta automatizada a incidentes.
FUNCION DE PRODUCCION

Objetivos:
✓ Identificar como la automatización de procesos ha llegado a beneficiar a la
industria.
✓ Comprender cómo el manejo de datos puede ayudar a la industria a
incrementar su productividad y eficiencia en sus procesos.

Función de producción
El cambio tecnológico se ha definido en términos generales como “el proceso
mediante el cual las economías cambia a lo largo del tiempo con respecto a los
productos y servicios que producen y lo procesó utilizado para producirlos”.
El cambio tecnológico puede implicar un cambio en la producción, las materias
primas la organización del trabajo o las técnicas de gestión, pero en todos los casos
afectaría la relación entre trabajo capital y otros factores de producción.
Funciones de producción y cambio tecnológico
Una función de producción intenta especificar el resultado de un proceso de
producción (en función de los diversos factores de producción, por ejemplo, trabajo,
capital, tecnología, administración u organización).
Automatización de procesos
Uno de los mayores atributos de la tecnología es probablemente su capacidad para
automatizar muchos procesos que las industrias han encontrado que requieren
relativamente mucho tiempo, gracias a la automatización los fabricantes de todo el
mundo pueden dejar tareas repetitivas y tediosas para que las maneje la tecnología.
También se da el caso que en la fabricación; los procesos más especializados y
complejos ahora tienen soluciones con máquinas y herramientas automatizadas
complejas y sobre todo confiables, lo que significa que la necesidad de trabajadores
capacitados también puede disminuir, además de esto se dice que la industria 4.0
que es una tendencia actual de automatización e intercambio de datos en
tecnologías de fabricación también mejora la productividad, la calidad y la eficiencia
en las empresas de fabricación.
Maximizando la eficiencia
Una de las primeras formas en que la tecnología puede mejorar su negocio de
fabricación es maximizando la eficiencia, esto significa que la tecnología es capaz
de garantizar que el tiempo se utilice de la mejor manera posible a reducir los
tiempos de producción y automatizar las tareas tediosas y que consumen mucho
tiempo.
Un ejemplo tecnología que podría mejorar una fábrica en la impresión 3D. Esta
tecnología está transformando la industria manufacturera, ya que puede reducir el
tiempo de diseño a producción y el tiempo de espera de fabricación, además de
reducir el desperdicio y garantizar una mayor flexibilidad en la producción, de hecho
la impresión 3D se está volviendo tan efectiva que a los trabajadores de la industria
manufacturera les preocupa que los reemplacen.
Hay muchas áreas del negocio de fabricación que pueden hacer eficientes, por
ejemplo, automatizar los correos electrónicos siempre que sean personalizados e
incluso invertir en un sistema de recursos humanos que les permita a los empleados
complicar sus propios datos personales, solicitar tiempo de vacaciones y trabajar en
tiempo real para que los departamentos de recursos humanos no tengan que lidiar
con tareas minúsculas. Se considera que la línea de producción es la parte más
crucial del negocio para maximizar la eficiencia; sin embargo, necesitan mejorar
todas las áreas del negocio desde finanzas y recursos humanos hasta marketing e
incluso ventas.
Manejo de datos
Como empresa de fabricación es probable que gestionen datos masivos. Al igual
que con cualquier dato, puede volverse problemático si no se tiene el conocimiento
adecuado sobre cómo administrarlo.
Dado que se dice que una mejor gestión de datos mejora la rentabilidad de una
empresa de fabricación es conveniente encontrar formas más eficaces de hacerlo
que es donde entra la tecnología.
Algunas organizaciones transnacionales se especializan en gestionar toda la nube,
lo que podría ayudar a garantizar que muchos datos estén todos de forma segura
en un solo lugar. También debe pensar en encontrar un software de gestión de datos
eficaces que sean capaces de ayudar a clasificar y dar sentido a los datos que están
recopilando.
Sin embargo, la gestión de datos conlleva una gran responsabilidad. Los datos son
increíblemente valiosos por lo que debe asegurarse de tomar las medidas
adecuadas cuando se trata de almacenar los datos de los clientes, deben cifrarse
estos datos, hacer una copia de seguridad de ellos en caso de ciberdelito y tener la
protección adecuada contra software malicioso.
Debe informarse a todos los miembros de la organización sobre cómo mantener sus
computadoras seguras mediante la protección con contraseñas y el buen juicio de
los enlaces y los correos electrónicos no confiables. Si bien es posible no considere
la industria manufacturera como un semillero de delitos cibernético, de hecho las
empresas más pequeñas y aquellas que se consideran menos de riesgo están de
hecho amenazadas, los ciberdelincuentes buscan industrias que puedan ser más
laxas en la protección de sus datos.
Incrementando la productividad
La productividad es clave en la gestión de un negocio de fabricación, ya que cuanto
mayor sea la productividad, más podrá producir. La tecnología también juega un
papel importante en la productividad por lo que buscar soluciones de software puede
ser edad para el negocio.
Por ejemplo, se podría dedicar tiempo a encontrar soluciones de software que
ayuden con la programación, el inventario y la supervisión de flujo de trabajo.
Tener en cuenta la automatización también es una buena idea, ya que puede ayudar
a reducir el riesgo de error, lo que también puede afectar sus niveles de
productividad ya que a menudo crear contratiempo, se ha pronosticado que el
aprendizaje automático reducirá el pronóstico de la cadena de suministro en un 50%
y reducirá las ventas perdidas en un 65%, esto refleja cómo la tecnología puede
ayudar a mejorar sus resultados cuando se usan de la manera correcta.
Siempre hay margen de mejora en los negocios, y esto es especialmente cierto en
la industria manufacturera. Dado que puede ser relativamente técnico y constar de
tareas repetitivas, la tecnología puede contribuir a optimizar los procesos para
ayudar a garantizar la máxima productividad, al hacerlo debería descubrir que un
negocio puede alcanzar mayores alturas y que puede alcanzar los objetivos
comerciales fácilmente.
Tecnologías modernas que impactan a los fabricantes
La industria manufacturera siempre ha tenido apetito por la tecnología. Desde el
análisis de big data hasta la robótica avanzada, los beneficios revolucionarios de las
tecnologías modernas están ayudando a los fabricantes a reducir la intervención
humana, aumentar la productividad de la planta y obtener una ventaja competitiva.
Las tecnologías sofisticadas, como la inteligencia artificial, el internet de las cosas y
la impresión 3D entre otras, están dando forma al futuro de la fabricación a reducir
el costo de producción, mejorar la velocidad de las operaciones y minimizar los
errores, dado que la productividad es fundamental para el éxito de una planta de
fabricación se espera que todos los fabricantes realicen inversiones significativas
en estas tecnologías

5 Tecnologías que están impactando positivamente en la industria

manufacturera
 1. El internet industrial de las cosas (IoT)
La capacidad de internet de las cosas se está implementando rápidamente en el
dominio industrial y de fabricación, proporcionando a los propietarios de planta una
forma de aumentar la productividad y disminuir la complejidad de los procesos, se
espera que la cantidad de dispositivos habilitados para el internet de las cosas
alcance más de 25 mil millones.
El internet industrial de las cosas (IIoT) es una función de varias tecnologías, como
aprendizaje automático, big data, datos de sensores e integración en la nube y
automatización de máquinas, estas tecnologías se están empleando en áreas como
mantenimiento productivo y proactivo, monitoreo en tiempo real, optimización de
recursos, visibilidad de la cadena de suministro, análisis de operaciones entre
instalaciones y seguridad, lo que permite a los gerentes de planta minimizar el
tiempo de inactividad y mejorar la eficiencia del proceso.
Por ejemplo, el mantenimiento y las reparaciones regulares son esenciales para el
buen funcionamiento de la planta.
Sin embargo, no todos los equipos, dispositivos necesitan mantenimiento al mismo
tiempo, el internet de las cosas permite a los gerentes de planta emplear monitoreo
de condición y mantenimiento predictivo del equipo, la supervisión de rendimiento
en tiempo real les ayuda a planificar su programa de mantenimiento, cuando sea
realmente necesario lo que reduce la probabilidad de interrupciones no planificadas
y la consiguiente pérdida de productividad.
De manera similar, los equipos con sensores integrados y habilitados para que el
internet de las cosas pueda comunicar datos que ayudan al equipo de la cadena de
suministro a rastrear los activos (utilizando sensores de RFID y GPS), hacer un
inventario, pronosticar, medir las relaciones con los proveedores y programar el
programa de mantenimiento predictivo.

2. Análisis de macrodatos
El análisis de macrodatos o big data puede ofrecer varias formas de mejorar el
rendimiento de los activos, agilizar los procesos de fabricación y facilitar la
personalización del producto.
Alrededor del mundo los fabricantes ya están invirtiendo en análisis de big data.
Estos fabricantes pueden tomar decisiones utilizando datos de rendimiento de
residuos y productividad proporcionados por el análisis de big data reduciendo los
costos operativos y aumentando el rendimiento general.
 3. Inteligencia Artificial y aprendizaje automático

Durante varias décadas, los fabricantes han empleado la robótica y la mecanización

para aumentar la productividad y minimizar los costos de producción por unidad, la
inteligencia artificial y el aprendizaje automático parecen ser la próxima ola en la
fabricación.
La inteligencia artificial (IA) está ayudando a los equipos de producción a analizar
datos y utilizar la información para reemplazar el inventario, reducir los costos
operativos y ofrecer un control de calidad sin interrupciones en todo el proceso de
fabricación.
La era de los robots poco inteligentes dedicados a tareas de producción cíclica ha
terminado.
La inteligencia artificial y el aprendizaje automático hacen posible que los robots y
los humanos colaboren entre sí creando procesos de fabricación ágiles que
aprenden mejoran y toman decisiones de fabricación inteligentes, en consecuencia,
los fabricantes pueden emplear la robótica industrial y la automatización inteligente
para administrar tareas básicas y enfocar su tiempo y recursos en tareas
generadoras de ingresos como investigación y desarrollo, extensión de la línea de
productos y un mejor servicio al cliente

4. Impresión 3D
La tecnología de la impresión 3D o de fabricación de capas adictivas están
destinadas a tener un gran impacto en industrias de alto nivel como la aeroespacial,
maquinaria minera, automóviles, armas de fuego, maquinaria comercial y de
servicios y otros equipos industriales, esta tecnología revolucionaria permite a los
fabricantes crear productos físicos a partir de diseños digitales complejos
almacenados en archivos de diseño asistido por computadoras en 3D
Se pueden utilizar materiales como caucho, nailon, plástico, vidrio y metal para
imprimir objetos reales de hecho, la bioimpresión tridimensional ha hecho posible la
fabricación de tejidos vivos y órganos funcionales para la investigación médica.
A diferencia del proceso de fabricación tradicional, las impresoras 3D pueden crear
formas y diseños complejos sin costo adicional, lo que ofrece una mayor libertad a
los diseñadores e ingenieros, además las crecientes aplicaciones de la impresión
3D en la fabricación están dando lugar a la fabricación como servicio, lo que permite
a las empresas mantener una infraestructura actualizada que atiende a múltiples
clientes y que elimina la necesidad de comprar nuevos equipos.
 5. Realidad virtual
La realidad virtual está simplificando el proceso de diseño de productos al eliminar
la necesidad de construir prototipos complejos, los diseñadores e ingenieros están
utilizando la realidad virtual para crear modelos de productos realistas, lo que les
permite ver digitalmente su diseño y solucionar problemas potenciales antes de
comenzar la producción, los clientes también pueden revisar e interactuar con estos
diseños digitales, simulaciones y dispositivos integrado, lo que reduce
significativamente el tiempo necesario para enseñar y fabricar el producto terminado
Por ejemplo, los fabricantes de automóviles ahora están utilizando la realidad virtual
para garantizar que sus automóviles se prueben en una fase temprana del proceso
de desarrollo del vehículo, lo que reduce el tiempo y el costo involucrados en la
modificación de los diseños, las tolerancias y las características de seguridad.
Dado que el análisis predictivo es fundamental para la eficiencia operativa de una
instalación de fabricación, se espera que los gerentes de planta dependan cada vez
más de la realidad virtual para revisar los flujos de trabajo, mejorar los procesos de
evaluación comparativa y mantener el cumplimiento a través de protocolos de
capacitación.
El impacto de la tecnología en la producción
La tecnología tiene un gran impacto en las empresas, tanto en términos de
actualización de productos existentes como de búsqueda de nuevas formas de
fabricar productos. La tecnología beneficia a las empresas ya que les permite
producir mayores cantidades, hacer que los productos sean más consistentes y
rentables, las empresas necesitan equilibrar:
Costos: Comprar tecnología cuesta dinero, pero reduce el costo de producir
productos.
Por ejemplo, el uso de maquinaria para completar tareas peligrosas significa que
una empresa ya no tiene que pagar los costos salariales más altos asociados con
trabajo riesgoso, esto reduce los costos y mejora la salud de los empleados.
Productividad: Utilización de maquinaria para mecanizar o automatizar parte del
proceso de producción, conducen a un aumento de la productividad, esto significa
que una empresa puede reducir sus precios para seguir siendo competitiva o
aumentar sus márgenes de beneficio.
Calidad: Las empresas deben ser consistente en la calidad de los productos que
produce, mecanizar o automatizar partes de la producción puede ayudar con esto.
Flexibilidad: Las empresas a menudo necesitan equilibrar la tecnología con la
flexibilidad humana, la automatización es buena para la producción en masa, pero
no funciona también para los productos que se personalizarán para satisfacer las
preferencias de los clientes individuales.
Por ejemplo, en la industria de los automóviles de lujo los clientes tienen una amplia
variedad de extra opcionales para elegir que pueden necesitar ser terminados a
mano
 29 USO E IMPLEMENTACIÓN DE SISTEMAS DE PRODUCCIÓN Y
SISTEMAS RELACIONADOS

Objetivos

Identificar la importancia de la gestión de producción y planificación en los sistemas

computacional.

Interpretar la información brindada para conocer la importancia de la administración de

actividad.

Uso e implementación de sistemas de producción y sistemas relacionados.

Independientemente del tamaño de una empresa, la fabricación es una tarea compleja.

Implica personas, materiales, equipos y muchas otras variables para convertir los
componentes básicos en productos terminados.

Algunos casos, la producción puede ser un proceso simple de unos pocos pasos, pero en la
mayoría de las operaciones de fabricación. La producción implica numerosos pasos de su
procesamiento o paso de ensamblaje que agregan complejidad.

¿Qué es la gestión de producción?

El objetivo de todas las empresas de aplicación es maximizar las ganancias. Esto se logra
mediante la utilización de un proceso de producción bien diseñado que persigue
continuamente mejoras de proceso y ganancias en eficiencia.

Este proceso requiere una gestión de producción sólida para realizar estas ganancias y
aplicarlas a resultado final.

Como parte integral de la gestión empresarial general, la gestión de la producción es el

proceso de transformación de materias primas o componentes en productos, termina.

Es la gestión de los materiales físicos, el cumplimiento de las especificaciones de diseño, la

utilización del equipo, el rendimiento y la mano de obra para implementar la estrategia de
producción de la empresa.

La gestión de la producción requiere la coordinación y supervisión de personas, materiales y

equipos.

Eso requiere que los gerentes tomen decisiones continuamente en cuatro áreas clave.

1. La planificación de la producción: Es la etapa en la que se produce el programa maestro.

Requiere que los gerentes decidan donde comenzará la producción, por ejemplo, qué máquina
o qué instalación.

También requiere decidir cuándo comenzará la producción. Los diferentes productos

funcionan a diferentes velocidades y requieren numerosas entradas para completar. Por lo que
la edición de cuando se basa en la combinación general del producto.
2. El control de producción: El control de producción es la aplicación a nivel del suelo de las
especificaciones de diseño. Aquí, al igual que un oficial de tránsito en una intersección
concurrida, los gerentes dirigen al personal y al equipo para que realicen los pasos para
completar su parte de un bien terminado.

Eso también implica una gestión activa frente a los estándares de calidad, así como una
estrecha supervisión de la velocidad de producción frente a los tiempos de ejecución medidos
establecidos.

3. la mejora del proceso: Todos los gerentes de producción son responsables de monitorear e
impulsar la mejora continua. Muchas empresas pueden utilizar metodologías como six Sigma
para formalizar los esfuerzos, pero incluso sin tales metodologías, ningún proceso estático y la
gestión de la producción requiere depender del perfeccionamiento y la aprobación de las
actividades del proceso de nivel de piso de equipo y mano de obra.

4. Mantenimiento de equipo: Asi como los gerentes de producción necesitan monitorear y

entrenar al personal para realizar tareas usando paso eficiente, también es necesario
administrar el equipo para mantenerlo en óptimas condiciones de funcionamiento.

Los costos de mantenimiento generalmente se incorporan a los productos terminados con el

costo total, especialmente para los fabricantes que utilizan un sistema de costo adicional para
determinar los costos y fijar precios. Debido a esto, la actividad general del equipo es vital.

¿Por qué es importante la gestión de la producción?

Sin una gestión eficaz a nivel de piso de los procesos de producción que el error y la
ineficiencia serían más comunes dentro de una fábrica.

Hay otras razones por las que la gestión de la producción es importante para las operaciones
comerciales.

Reduce el costo de fabricación: al maximizar los resultados y minimizar los insumos, la gestión
de la producción reduce el costo requerido para producir productos terminados. Esto se puede
utilizar para mejorar el margen de beneficio o se puede transferir al cliente para asegurar una
ventaja competitiva.

Mejora la competitividad: Sabes que los productos adecuados están disponibles a tiempo y se
entregarán a tiempo, significa que una empresa siempre está en el juegos, en cualquier
mercado.

Alcanza los objetivos comerciales.

La gestión de la producción ayuda a las empresas a producir productos terminados de manera

eficiente.

Debido a que estos productos terminados siempre se fabrican con alta calidad y se entrega
cuando es necesario, las empresas pueden aprovechar esas cosas para hacer crecer el negocio,
asegurar capital para mejorar y aumentar la satisfacción del cliente.
Mejora la imagen de marca.

Muchas empresas de fabricación operan hoy en día parte o toda su producción de forma
directa al consumidor.

Como resultado, la imagen de marca se vuelve importante, una buena gestión de la

producción significa que los clientes confían en los productos y pueden tener confianza en su
calidad y disponibilidad, mejorando así la imagen de marca en general.

Una buena imagen de marca es importante, ya que sus productos sean diseños bajo pedido,
fabricación por pedido o fabricación por stock.

Optimiza el uso de recursos.

La gestión de la producción significa que la mano de obra, el equipo y los recursos se

optimizan en el esfuerzo del producto.

Esto puede reducir los niveles de desperdicio y crear un entorno para los empleados que sean
positivos y bien equilibrado. Con el énfasis en el equilibrio, trabajo vida actual, y las iniciativas
ecológicas para reducir la huella de carbono. Una gestión de producción eficaz que optimiza el
uso de los recursos puede ayudar a cumplir ambas tendencias.

Producción y gestión de operación.

Si bien está integralmente vinculado, existe una diferencia entre la producción y la gestión de
operación.

En cualquier fábrica el gerente de producción aplica principios de gestión específicamente al

proceso de destrucción. Por otro lado, la función de la gestión de operaciones es más amplia
que en lo que respecta a las actividades comerciales fuera de la fábrica.

Los gerentes de operaciones aplican principios de gestión empresarial para garantizar que toda
organización, y no sólo la producción, funcione sin problemas y de manera eficiente. Eso no
son, implica una entrada directa en el proceso de producción, también incluye la
responsabilidad de los servicios que pueden acompañar a la producción, como el servicio al
cliente o el servicio de campo.

La gestión de operaciones también abarca:

• el inventario,
• el almacenamiento
• y la cadena de suministro.

Esto puede incluir sistemas de compra y entrega y también puede gestionar departamentos de
calidad e iniciativas de calidad.

Otras funciones involucradas en la gestión de operaciones incluyen.

Plan estratégico: la administración de operaciones, que está involucrada en asegurarse que se
desarrollen estrategias efectivas para maximizar todos los recursos de la empresa en conjunto.

Finanzas: La administración de operaciones a menudo está involucrada en la planificación y en

el presupuesto operativo y de capital.

Diseño de producto: los gerentes de operaciones son responsables de garantizar que los
productos desarrollados pueden ser fabricados por la fábrica de manera eficiente y a un costo
optimo.

Previsión: la gestión de operaciones es un puente entre las ventas y la producción. Pueden

cargarse la previsión para predecir qué productos y servicios se requieren para el futuro.

Si bien la decisión puede ser algo borrosa en las pequeñas y medianas empresas (PYMES)
donde gerentes tienen muchos roles, la administración de operaciones y la administración de
producción son diferentes significados alcance enfoque y estructura Organizacional.

Implementación del sistema de producción.

Maximizar la efectividad de la cadena de suministro a través de un sistema de producción

implementado globalmente. Crea enfoques de trabajo, estándares basados en las mejores
prácticas. Y una cultura de mejora continua esto asegura un enfoque incesante en eficiencia de
la cadena de suministros y permite que los productos y procesos que se ubiquen fácilmente si
cambia la dinámica del costo del servicio.

El diseño estructurado el sistema de producción combina análisis, observación y auditoría para

crear una comprensión objetiva única de las fortalezas y limitaciones de la cadena de
suministro central.

La introducción de nuevos productos y su gestión a lo largo de su ciclo de vida y la eficacia con

la que se planifica y ejecuta la demanda a través del modelo cooperativo.

El desarrollo de tecnologías digitales novedosas conectadas a Internet de las cosas, junto con
los avances en inteligencia artificial y automatización. Estás permitiendo una nueva ola de
innovación en la fabricación. La innovación de proceso es la implementación de métodos de
producción o entrega nuevos significativos, mejorados. Esto incluye cambios significativos en
técnicas y equipos o software.

En el sentido más simple, definir la tecnología de producción sería incluir cualquier máquina
que haga posible la creación de un producto físico tangible para una empresa.

Para la pequeña empresa esto significa un taller como mínimo con operaciones más
elaboradas que hacen uso de máquinas y líneas de montaje.
Se habla mucho de la capacidad de la robótica y la automatización para realizar tareas
repetitivas y realizar trabajos que podrían resultar demasiado agotadores físicamente o
peligrosos para los humanos.

Los trabajadores generalmente deben configurar los controles de la máquina en una operación
automatizada, supervisar la calidad de la producción y realizar cualquier mantenimiento
requerido.

Esta tecnología tiene efectos directos sobre el crecimiento de las industrias productoras de TI.
También aumentan la eficiencia y la productividad de las industrias que utilizan las tecnologías
de la información.
La función de mantenimiento tecnológico en la organización

Objetivos

 comprender el impacto que genera en las tecnologías obsoletas en una

organización

 considerar la importancia de la seguridad de información y la legalidad de está

dentro de una institución

función de mantenimiento
la tecnología toca todos los aspectos de una organización desde las operaciones
comerciales y la comunicación hasta la salud y la seguridad la tecnología no se limita a
computadoras, teléfono móviles e impresoras son las máquinas de tarjetas que los
clientes usan para pagar los productos o servicios de una empresa

todos estos diferentes tipos de tecnología deben formar parte de la estrategia de

gestión tecnológica continua de las empresas que tienen como objetivo garantizar que
se esté
avanzando con los cambios tecnológicos

tiempo de inactividad y fallada el riesgo de tener hardware antiguo es la

imprevisibilidad de saber si el hardware admitirá la próxima actualización de
software o los cambios implementados por un proveedor de hardware la tecnología
antigua se vuelven menos confiables con el tiempo y las oportunidades de que
ocurran fallas se vuelven más comunes

aunque la instalación del nuevo hardware puede resultar en un nivel de tiempo de

inactividad programada el objetivo del nuevo hardware es reducir la cantidad de
tiempo de inactividad no programado a largo plazo al tener la capacidad de
planificar y programar el tiempo de inactividad necesaria para actualizar la
tecnología una empresa puede gestionar el efecto en su negocio y trabajar para
garantizar una eficiencia óptima durante este tiempo

actualizaciones antiguas de hardware y software

las empresas continuamente realizan mejoras o crean nuevas características para sus
productos para mantenerse al día con la última tecnología

mantener la ventaja competitiva y brindar a su cliente el mejor producto disponible

a medida que se realizan estos nuevos desarrollos y cambios el mantenimiento

de la versión original del producto se vuelve menos prioritario

el hardware más antiguo es incapaz de mantenerse al día y desafortunadamente

los ciclos continuos de actualización del software hacen que sea más probable que el
rendimiento de los dispositivos más antiguos se vea afectado

tiempo de inactividad interrupciones y fallas cuando se trata de aplicaciones de

misión crítica o calidad de rendimiento del centro de datos las empresas están
dispuestas a realizar grandes inversiones desafortunadamente estas inversiones no
siempre dan resultados completos
hacer frente al tiempo de inactividad del sistema a pesar del esfuerzo invertido en la
robustez de la infraestructura muchas organizaciones de TI continúan lidiando con
incidentes de tiempos de inactividad de base de datos, hardware y software que duran
desde unos pocos minutos hasta varios días incapacitando por completo a la empresa
y causando enormes pérdidas

tiempo de inactividad esperado a pesar de la variedad de soluciones avanzadas y

los datos de montaje recopilados por los principales proveedores de software
empresarial y departamento de ti las interrupciones siguen siendo una amenaza válida
y aterradora para la industria por otro lado, las fallas de ti se han convertido de alguna
manera en una parte inherentemente aceptada incluso esperada de la vida
empresarial

revisión del tiempo de inactividad de TI

si bien los profesionales de TI se encuentran enfrentando tiempos de inactividad de
vez en cuando y luego están completamente concentrados en tratar de controlarlos

la organización empresarial en su conjunto sufre el dolor financiero por los efectos que
tienden a ser muy significativos

las organizaciones deben abordar y evaluar las amenazas a sus operaciones de TI

incluidos los sistemas las aplicaciones y los datos mediante el análisis de puntos de
referencia sólidos y establecidos que representan los costos potenciales detrás del
tiempo de inactividad y las interrupciones

elegir la estrategia de actualización óptima mantener actualizados los sistemas de

TI de la oficina a nuestro cargo es más que implementar un ciclo máximo de
reemplazo de hardware de 5 años también se debe decidir cuáles de los últimos
desarrollos tecnológicos tienen el potencial de mejorar la eficiencia y la eficacia del
negocio y cuáles probablemente sean menos costosos

actualizaciones y actualizaciones de software la actualización o sustitución de

software suele ser más barata y sencilla que la sustitución de hardware además el
hardware que se cree que funciona mal puede de hecho ser perfectamente adecuado,
pero se ve obstaculizado por problemas de software.

podemos realizar evaluaciones ad-hoc o periódicas para comprobar que los

dispositivos están configurados correctamente protegidos contra virus y malware y
tienen todas las
actualizaciones de software y sistemas operativos relevantes también se puede
asesorar si un software alternativo puede ofrecer la misma funcionalidad, pero
funcionar mejor en su hardware existente

reemplazo de actualizaciones de hardware debido al ritmo de la evolución del

hardware y al hecho de que el hardware más antiguo puede tener muchos puntos de
falla a menudo, es más rentable reemplazarlo que repararlo cuando esté cuando este
sea el caso o cuando sea el momento de un reemplazo periódico de hardware
podemos hacer asesorarlos sobre las mejoras opciones actuales.

virtualización
si la empresa utiliza servidores locales es posible que pueda beneficiarse de la
tecnología de virtualización como alternativa a la compra de hardware adicional esto
permite que un servidor físico albergue varios servidores virtuales.
la virtualización de servidores tiene la siguiente ventaja
mejor utilización del hardware lo que se traduce en una reducción de los costes
generales de hardware

gestión y mantenimiento más fácil y centralizada

menores costos de energía

la confiabilidad de un entorno virtualizado sin virtualización si un servidor físico

tiene un problema de hardware todos los servicios proporcionados por él se
degradarán hasta que se repare esa máquina en particular con la virtualización si un
servidor o físico tiene un problema de hardware los servidores virtuales ubicados en él
se pueden mover rápidamente a otro servidor físico en funcionamiento por lo que
habrá una interrupción mínima de los servicios

la configuración o la migración a un entorno virtualizado

requiere experiencia detallada y las opciones pueden depender significativamente del
hardware particular de sus servidores

riesgos principales del uso de tecnología obsoleta

fallos y tiempo de inactividad del sistema las excusas son la versión actual del
perro que comió mi tarea sin embargo esa excusa ha pasado realmente a ser un
elemento común en las escuelas y empresas a ser socialmente inaceptable en su
mayor parte este cambio se debe en gran parte al aumento de los servicios en la nube
las aplicaciones de software como servicio que almacenan datos de forma segura en
sistemas remotos.

hoy vivimos en una cultura de ahora si las fallas y el tiempo de inactividad del sistema
resultante impiden suministrar lo que quiere y esperan muchos dudaran en llevar su
negocio a otra parte. Y puede apostar que la mayoría de las veces hay un competidor
esperando entre bastidores con la tecnología adecuada y funcional para darles lo que
quiere y esperen ahora

aumento de los costos en poca palabra la tecnología obsoleta puede ser costosa de
mantener realmente no es muy diferente a mantener una casa o un vehículo muy
antiguo excepto que la tecnología envejece a un ritmo mucho más rápido de hecho
cuesta casi el doble reparar un sistema que tiene 4 años o más

disminución de la productividad la tecnología antigua funciona más lentamente

tarda más en ejecutar las tareas y requiere mucho más mantenimiento parches
actualizaciones y llamadas al servicio de asistencia técnica que sus contrapartes más
nuevas la disminución de la productividad puede costarle a una empresa tanto en
términos de ingresos como de retorno de inversión roi obtiene mucho más de los
empleados productivos de que aquellos que dedican parte de su día a que sus
herramientas funcionen correctamente

una excelente opción para minimizar el riesgo asociado con las actualizaciones de
hardware es: hardware como servicio que brindan algunos proveedores de hardware y
servicio administrado una de las principales ventajas de hardware como servicio es
que paga una tarifa mensual razonable
agujeros de seguridad el uso de tecnología antigua puede abrir una empresa a un
mundo innumerables lo que aumenta constantemente las vulnerabilidades de
seguridad si está ejecutando windows xp en una computadora tendría seis veces más
probabilidades de estar infectado con amenazas de malware que si está ejecutando
windows 10

cuando se avisa al final del soporte de un software en específico significa que ya no

habrá actualizaciones de seguridad crítica la mejor manera de asegurarse de estar
siempre actualizado es a través de la documentación de lo que se tiene y la
frecuencia con la que debe actualizarse como una hoja de ruta tecnológica y un
conjunto sólido de procesos de mantenimiento y actualización

riesgos de cumplimiento legal y regulatorio los auditores pueden multar a las

empresas que no hagan la transición de software o sistemas no compatibles además,
los sistemas obsoletos pueden convertirse en un objetivo principal de ataques
cibernéticos y posibles violaciones de datos que pueden tener consecuencias
catastróficas para un negocio

las pequeñas y mediana empresas ya no pueden asumir que son demasiado

pequeñas o poco importantes para que los piratas informáticos y los ciberdelincuentes
se dirijan a ellos las pequeñas medianas empresas también tienden a ser el más
egoístas a la hora de actualizar su tecnología lo que aumenta drásticamente su
vulnerabilidad y atractivo para los ciberdelincuentes el hecho de que no sea una firma
de abogado o de atención médica no significa que sean inmunes a los riesgos de
cumplimiento legal y regulatorio hay muchos requisitos y cumplimientos que se aplican
a todas y cada una de las empresas
20- PLANES DE MANTENIMIENTO PREVENTIVO Y CORRECTIVO

Objetivo

• Analizar la importancia del mantenimiento que se realizan a los equipos informáticos en

una institución.
• Identificar los distintos tipos de mantenimiento informático que se realizan en una
institución.

Planes de mantenimiento preventivo y correctivo

El mantenimiento incluye tanto el hardware como el software de las computadoras y servidores

los distintos tipos de mantenimiento pueden funcionar simultáneamente en el caso de
mantenimiento correctivo actuara si el mantenimiento predictivo o el mantenimiento preventivo
no logran anticipar el problema.

Mantenimiento predictivo

Es un tipo de mantenimiento que se realiza mediante herramienta de diagnóstico con el fin de

anticipar posibles averías y tratar de evitarlas antes de que se produzcan.

El mantenimiento predictivo es el mantenimiento que monitorea el rendimiento y el estado del

equipo durante el funcionamiento normal para reducir la probabilidad de fallas.

El objetivo del mantenimiento predictivo es la capacidad de predecir primero cuándo podría

ocurrir una falla del equipo. En función de ciertos factores seguido en la prevención de la falla
mediante un mantenimiento correctivo y programado regularmente.

Antes de establecer un programa de mantenimiento predictivo una organización debe tomar

varios pasos que incluyen:

• Analizar la necesidad y el historial del equipo.

• Revisar todos y cada uno de los registros disponibles sobre tiempo de inactividad.
Defectos del equipo pérdidas, rendimiento y energía posibles multas regulatorias y
seguridad en el lugar de trabajo.
• Establecer definiciones y conceptos, así como construir un caso.
• Educar las principales partes interesadas y lograr la aceptación.
• Completar un inventario de equipo y evaluar las condiciones actuales del equipo.
• Selección de equipo para implementación inicial del programa.
• Desarrollar detalles del sistema tomando como base sistemas o componentes
individuales. Evaluar cualquier mantenimiento preventivo y predictivo existente.
• Decidir qué sistemas incluir y qué inspeccionar.
• Definir la criticidad del programa y establecer la frecuencia de mantenimiento predictivo y
el tipo de horario.
• Evaluar los recursos previstos y asignar roles y responsabilidades al personal.
• Organizar el programa e integrarlo en el sistema de programación.
• Educar y obtener la aceptación de las operaciones y el mantenimiento.
• Actualización de equipos y realización de capacitaciones.
• Creación de un sistema de gestión de mantenimiento computarizado
Mantenimiento preventivo

Se trate de un tipo de mantenimiento muy frecuente que se realiza con el fin de prevenir posibles
averías y mejorar el funcionamiento de un sistema, pero también para alargar la vida útil de los
diferentes componentes del sistema.

El mantenimiento preventivo es útil en muchos aspectos por ejemplo disminuye la cantidad de

tiempo de inactividad del sistema o puede reducir la cantidad de reparaciones y también puede
detectar puntos débiles en el sistema que podrían afectar su funcionamiento. Cuando hablamos
de mantenimiento preventivo de hardware solemos hablar de dos tipos diferenciados que son
tareas como la limpieza periódica de los equipos y sus componentes o el mantenimiento
preventivo activo. La salud y la confiabilidad de una pc depende de su capacidad para cuidarlo
por dentro y por fuera.

Cuidado físico

La computadora incluye en varias estructuras internas sensibles y es importante proteger el

bienestar físico de un pc para mantener los componentes internos que la hacen funcionar.

Se debe asegurar de tomarse el tiempo para limpiar un pc de polvo y escombro con regularidad.
Se debe inspeccionar la fuente de alimentación y los dispositivos es muy probable que se utilice
protectores contra sobretensiones o dispositivos similares para alimentar la computadora.

Desempeño interno

Limpiar las computadoras internamente significa mantener su sistema para asegurar un

rendimiento óptimo. Además, el mantenimiento adecuado ayudará a mantener sus archivos
seguros un sistema con un mantenimiento deficiente o que rara vez se actualiza es más
vulnerable a los métodos de piratería sofisticados

Rutinas

Ejecutar antivirus: la computadora puede tener vulnerabilidades que no se notan hasta que es
demasiado tarde. Es importante ejecutar el análisis de antivirus todos los días para asegurarse
de que los cambios que realizaron o los archivos que descargaron no hayan comprometido el
sistema.

Escanear archivos del disco duro

Con el tiempo, el disco duro puede ralentizarse debido a archivos desordenados. Cuando se
escanea el sistema en busca de errores usando un desfragmentador de disco o un programa
similar, esencialmente se está eliminando el espacio desperdiciado y ayudando a que la pc
funcione de manera más eficiente.

Actualizar las copias de seguridad de los datos

Se debe tener al menos un método para hacer una copia de seguridad de los datos, ya sea un
servidor de almacenamiento en la nube o un disco duro externo. Se debe asegurar tomarse el
tiempo para actualizar las copias de seguridad todos los días.
Limpiar el navegador web

Cada vez que se conecta, los sitios que se visitan almacenan archivos temporales como cookies
y un historial de navegación. Se debe borrar estos archivos para ayudar a evitar que ataquen el
sistema.

Concientizar a los usuarios que apaguen correctamente

Al final del día los usuarios deben asegurarse de guardar su trabajo antes de cerrar todo su
programa y apagar su pc. Dejar su pc encendida cuando no está en uso durante periodos
prolongados evita que se enfríe y puede afectar el rendimiento de la máquina.

Diferencia entre mantenimiento predictivo y mantenimiento preventivo

El mantenimiento preventivo ha implicado inspeccionar y realizar el mantenimiento de la

maquinaria, independientemente. De si el equipo necesitaba mantenimiento, este programa de
mantenimiento se basa en un desencadenante de uso o de tiempo.

Mientras que el mantenimiento preventivo se determina utilizando el ciclo de vida promedio de

un activo, el mantenimiento predictivo se identifica en función de las condiciones preestablecidas
y predeterminadas de pieza específica de equipo utilizando diferentes tecnologías el
mantenimiento predictivo también requiere más inversiones en personas, capacitación y equipos
que el mantenimiento preventivo pero el ahorro de tiempo y de costos será mayor a largo plazo.

Mantenimiento correctivo

Esta es la solución que se debe aplicar cuando los mantenimientos predictivos y preventivos no
han funcionado correctamente o cuando esto no han podido evitar la falla.

Hay ocasiones en las que un equipo o sistema falla por ejemplo debido a un fallo de hardware.
Una de las consideraciones para tener en cuenta con respecto a este tipo de mantenimiento es
que no sólo será importante solucionar la avería, sino que también debemos determinar cuál fue
la causa de la misma con el fin de encontrar las posibles repercusiones que pudieran haber
afectado a otras partes del sistema y para evitar que vuelva a suceder en el futuro

Mantenimiento evolutivo

Este tipo de mantenimiento no está destinado a corregir o prevenir posibles fallas, sino a
desarrollar los recursos informáticos disponibles. Con el mantenimiento evolutivo queremos que
los sistemas informáticos no queden obsoletos, sino que se mantenga actualizado para ofrecer
a los usuarios las mejores opciones tecnológicas en función de las posibilidades de cada
empresa y organización.
Mantenimiento de Servidores

Objetivos:

 Conocer sobre el proceso de mantenimiento de servidores.

 Identificar los distintos tipos de servidores que se utilizan dentro de una organización.

Mantenimiento de servidores

El mantenimiento del servidor, es el proceso de mantener un software de servidor actualizado y

en funcionamiento para que una red de computadoras pueda funcionar sin problemas y evitar el
tiempo de inactividad o la pérdida de datos. El mantenimiento regular mantendrá el servidor
funcionando como se espera y ayudará a evitar una falla total o parcial de la red.

Si sabe cómo mantener su servidor con tan solo un poco de tiempo se puede obtener el máximo
rendimiento para inversión y prolongar significativamente su vida útil.

Cómo funcionan los servidores

Un servidor es una computadora independiente que proporciona datos y otros servicios a una o
varias computadoras en una red determinada. El principal beneficio de un servidor es que permite
la administración y el monitoreo centralizado del acceso a la red y los datos de la red.

Tipos de servidores

Servidor de archivos: un almacenamiento central para archivos al que puede acceder las
computadoras cliente.

Controlador de dominio: un servidor que responde a las solicitudes de autenticación de seguridad,

inicia sesión, verificación de permisos etcétera dentro de la red.

Servidor de escritorio remoto (terminal): un servidor de escritorio remoto o servicio de terminal

proporciona acceso remoto seguro a aplicaciones de oficina y de línea de negocio a empleados o
contratistas desde un servidor centralizado.

Servidor web: almacena y comparte sitio web a través de internet.

Servidor en la nube: un servicio en la nube es un servidor virtual en lugar de un servidor físico que
se ejecuta en un entorno de computación en la nube. está construido alojado y entregado a través
de una plataforma de computación en la nube, a través de internet y se puede acceder a él de
forma remota.

A continuación se muestran otros tipos de servidores más comunes que se utilizan en la

actualidad:

Servidores de aplicaciones: a veces denominados un tipo de middleware los servidores de

aplicaciones ocupan una gran parte del territorio informático entre los servidores de bases de
datos y el usuario final.

Servidores cliente: en el modelo de promoción cliente servidor un servidor es un programa que

espera y satisface las solicitudes de los programas clientes en la misma computadora o en otras.
Servidores de colaboración: software de colaboración diseñado para permitir a los usuarios
colaborar independientemente de su ubicación a través de internet o una intranet corporativa y
trabajar juntos en una atmósfera virtual.

Servidores FTP: uno de los servicios de internet más antiguo el protocolo de transferencia de
archivos, hace posible mover uno o más archivos de forma segura entre computadoras, al tiempo
que proporciona seguridad y organización de archivos así como control de transferencia.

Servidores de lista: los servidores de lista ofrecen una manera de administrar mejor las listas de
correo ya sean discusiones interactivas abiertas al público o listas unidireccionales que entregan
anuncios boletines o publicidad.

Servidores de correo: casi tan generalizados y cruciales como los servidores del web los servidores
de correo mueven y almacenan correo a través de redes corporativas, a través de redes LAN y
WAN y a través de internet.

Servidores de código abierto: desde su sistema operativo de servidor de código abierto

subyacente hasta el software de servidor que lo ayuda a realizar su trabajo, el software de código
abierto es una parte fundamental de muchas infraestructuras de ti.

Servidores Proxy: los servidores proxy se encuentran entre un programa cliente normalmente un
navegador web y un servidor externo, normalmente otro servidor en la web, para filtrar
solicitudes, mejorar el rendimiento y compartir conexiones.

Servidores Telnet: un servicio telnet permite a los usuarios iniciar sesión en una computadora
remota y realizar tareas como si estuvieran trabajando en la propia computadora.

Servidor virtual: en el año 2009 el número de servidores virtuales desplegados superó el número
de servidor físico. Hoy en día la virtualización de servidores se ha vuelto casi omnipresente en el
centro de datos, desde hipervisores hasta nube híbridas.

Exchange Server: diseñado para brindar la seguridad y confiabilidad de nivel empresarial que
requieren las empresas Microsoft Exchange, proporciona correo electrónico, calendario y contacto
en su pc teléfono y navegador web.

SharePoint server: un producto de servidor que proporciona un marco consistente y familiar para
listas, biblioteca, administración y personalización de sitios.

SQL server: SQL server es un sistema de instalación de bases de datos relacionales de Microsoft
diseñado para el entorno empresarial.

Windows server: como la versión del servidor de Windows 10, Windows server 2016, redefine la
categoría servidor ofreciendo cientos de nuevas características y mejoras que abarcan
virtualización, redes, almacenamiento, experiencia de usuario, computación en la nube,
automatización y más.

El mantenimiento del servidor generalmente requiere lo siguiente:

 Comprobar los archivos de registro del servidor y evaluar el espacio en el disco duro.
 Examinar los permisos de la carpeta.
 Monitoreo de aplicaciones de temperatura de red.
 Garantizar la redundancia adecuada en los sistemas.
 Examinar las características de seguridad.
 Instalar parches de software de seguridad.
 Leer los registros del servidor en busca de alertas de seguridad o evidencia de intento de
piratería informática.
 Actualizar el software antivirus en todos los equipos de red.
 Actualización de paquetes de servicios críticos y actualizaciones de software.
 Realizar copias de seguridad periódicas para garantizar que los datos vitales se puedan
recuperar de lanzamiento en caso de una falla del sistema.
Funciones de soporte técnico
Objetivos

 Identificar los conocimientos y certificaciones que un programa en soporte técnico

debe poseer.
 Conocer la función y las tareas que desempeña el responsable del soporte técnico
en una
Institución.
Función de soporte técnico.
Los ingenieros de soporte técnico brindan servicios de soluciones de problemas y soporte
técnico a una amplia gama de clientes internos y externos en muchas industrias incluidas
las telecomunicaciones la atención médica y los servicios financieros casi todas las
grandes empresas tienen su propio departamento de ti y la función principal de ese
departamento es brindar soporte técnico, a las empresas medianas y grandes a menudo
dividen su soporte técnico en dos áreas.

 Aquellos ingenieros que ayudan a los departamentos internos y a los empleados.

 Los representantes que están de cara al cliente hablando con los clientes que han
llamado o iniciado un chat en vivo en busca de ayuda.
Conjunto de habilidades

 Conocimientos técnicos
 Habilidades blandas (comunicación, flexibilidad, paciencia y resolución de
problemas)
Soporte técnico vs soporte cliente
Ingeniero de soporte técnico con cualquier otro nombre puede tener el mismo objetivo
brindar soporte técnico cuando sea necesario para elevar la experiencia del cliente a una
positiva. el equipo de soporte técnico también se puede llamar equipo de soporte al
cliente dependiendo de si los clientes son internos o externos, independientemente del
tamaño o la solidez del equipo de soporte técnico las responsabilidades del ingeniero de
soporte técnico siguen siendo notablemente similares eso incluye solucionar problemas
de hardware y software, responder consultas y documentar los resultados.
Funciones y responsabilidades
Un ingeniero de soporte técnico puede tener una variedad de responsabilidades lo que
requiere un conjunto de habilidades diverso.
Sistemas de seguimiento.
El monitoreo continuo de sistemas y software es una parte fundamental de ser un
ingeniero de soporte técnico los ingenieros de soporte técnico pueden usar una variedad
de herramientas de monitoreo tanto ofensivas como defensivas. Las herramientas de
monitoreo se pueden desarrollar a medida o comprar a través de un proveedor de
servicios empresariales será trabajo del ingeniero de soporte técnico:
1. Determinar qué herramientas son las mejores y más apropiadas para usar
 2. Capacitar a todas las partes necesarias sobre cómo usarlos incluidos otros
empleados de la mesa de ayuda
3. Documentar y resolver cualquier problema
4. Solución de problemas diagnóstico resolución y escalamiento.
El área de soporte técnico suele tener una cola de problemas en ejecución que están
trabajando para resolver el responsable de priorizar y gestionar el flujo de trabajo hasta su
resolución.
Interactuar con los clientes.
Los ingenieros de soporte técnico pueden estar obligados a:
1. Participar en foros o sesiones de clases magistrales en toda una organización
2. Prestar su voz a los tutoriales de capacitación o en una presentadora clave en un
seminario web
3. Pasar la mayor parte del día hablando con otras personas.
Conocimientos técnicos
La mayoría de las organizaciones esperan ser un recurso de información y conocimiento
técnico con mayor frecuencia esto proviene de la experiencia práctica y el desarrollo
profesional que solo del aprendizaje académico.
Habilidades necesarias
Las empresas buscan determinadas competencias y las más importantes son los
conocimientos técnicos una base sólida en informática es el primer paso a partir de ahí las
empresas buscarán habilidades que se adapten a sus necesidades empresariales esto
puede incluir el conocimiento de lo siguiente:
1. Seguridad de red
2. Amplio conocimiento de entornos virtuales
3. Redundancia y tecnología vpn
4. Otras medidas de seguridad experiencia con software empresarial específico}
5. Sql
6. Comprender el código fuente
7. Escribir comandos y procesos de flujo de trabajo
8. Usando software de monitoreo
9. Experiencia comprobada de resolución de problemas y diagnóstico de problemas
10. Experiencia en hardware empresarial
11. Desarrollo profesional
Como recurso respetado dentro de una oración se espera que el ingeniero de soporte
técnico busque el desarrollo profesional para mantenerse informado sobre las tendencias
del mercado hay muchas certificaciones disponibles para los empleados de la mesa de
ayuda algunas de las certificaciones más valiosas incluyen

 La certificación de administrador de sistemas Apple, está dirigida a el profesional

de la mesa ayuda el coordinador técnico o el usuario avanzado que administra
redes o brinda soporte técnico a usuario mac.
  Certificación CompTIA A+ 2.219, es un certificado de la industria específico para el
soporte técnico y los roles operativos de TI
 Certificación ITIL que puede ayudar a los profesionales que buscan comprender el
marco ITIL y cómo puede mejorar la gestión de servicios de TI
Panorama
En un mercado donde los servicios de soporte están impulsados internamente por altos
costos de subcontratación y tasas de rotación es más importante que nunca para la
empresa encontrar ingenieros de soporte técnico de carrera para respaldar los equipos y
las necesidades de ti en crecimiento.

 Ser un profesional de la mesa de ayuda ofrece una forma gratificante de adquirir

una gran experiencia en TI que brinda innumerables oportunidades para estudiar
una carrera profesional
Algunas rutas fuera del soporte que los ingenieros de soporte técnico exploran o recorre
incluyen
1. Ingeniero de software.
2. Ingeniero de redes.
3. Administrador de sistemas.
4. Desarrollador senior de software.
5. Gerente de TI
6. Gerente de proyecto o producto
Responsabilidades primarias
Aquí hay una lista no exhaustiva de tareas comunes que se espera que completen los
especialistas en soporte técnico.

 Instalar y configurar nuevas tecnologías a ser utilizadas por la empresa como

hardware sistema operativo y otros programas o aplicaciones.
 Dar mantenimiento regular al hardware y sistemas informáticos existentes.
 Brindar asistencia al personal de la empresa o cliente con problemas relacionados
con la tecnología.
 Explicar el problema al miembro del personal o al cliente.
 Solución de problemas de sistemas y aplicaciones.
 Encontrar soluciones para cualquier problema e implementarlo.
 Pedido de piezas nuevas cuando no hay existencia.
 Redacción de informes sobre el estado de todo el hardware y software de la
empresa.
 Implementar y ayudar en el despliegue de nuevas aplicaciones o sistemas
operativos.
 Ejecutar pruebas antes de implementarlas en todos los sistemas.
Tareas Diarias
1. Comprobación del estado de todos los sistemas en hardware.
2. Responder a solicitudes de ayuda de miembros del personal o clientes.
3. Instalación y configuración de nuevos sistemas y hardware.
4. Reemplazo de hardware defectuoso o dañado.
5. Software de solución de problemas.
6. Probar evaluar y aprender sobre actualizaciones y nuevas tecnologías
Ciclo de vida del servicio técnico
Objetivos
✓ Comprender el ciclo de vida de soporte técnico dentro de una
organización.
✓ Identificar y analizar los diferentes tickets de soporte técnico en una mesa
de ayuda.

Ciclo de vida del servicio técnico

Las gerencias de tecnología de información son las responsables de establecer
el periodo de tiempo para resolver casos. Están obligados a brindar y satisfacer
las necesidades de los usuarios o de la organización misma, establecido por la
mesa de ayuda, asignando los casos, plazos y recursos por medio de tickets.

Un ticket de TI, es el medio básico para rastrear el proceso de resolución de

solicitudes de servicio, informes de incidentes y otras órdenes de trabajo que se
enrutan a través del servicio de atención de TI.
Los tickets de ti pueden organizarse en un sistema de ticket basado en software
que actúa como un único punto de contacto entre la organización de TI y la
unidad de negocio.

Estos registros ayudan a la organización de TI a aumentar su base de

conocimientos y mejorar el manejo de tickets de la mesa de ayuda de TI y los
procesos de cumplimiento de solicitudes para satisfacer mejor las expectativas
de los clientes.

Ciclo de vida del soporte técnico basado en tickets.

Algunas normativas internacionales proporcionan a las organizaciones de TI un
marco de mejores prácticas en la industria para la gestión de servicios de TI.
Asimismo, incluyen varias prácticas que tratan directamente con la gestión de
tickets de TI y el ciclo de vida de los tickets.

Se ha descubierto un proceso básico del ciclo de vida del ticket como parte del
proceso de gestión de incidentes:
• Detección y registro de incidentes.
• Notificación y comunicación de incidentes.
• Clasificación prioritaria y soporte inicial.
• Investigación y análisis.
• Resolución y registro.
• Cierre de incidentes.

Diferentes tickets de TI.

Los tickets de TI se puede utilizar para muchos tipos de actividades que caen
dentro del ámbito de responsabilidad de los agentes u operadores de TI.
Cualquier trabajo orientado a tareas para un agente u operador desde TI puede
y debe solicitarse con un ticket, una práctica que puede impulsar la productividad
del operador al tiempo que crea y aplica la responsabilidad por los resultados.

Cuatro tipos de tickets de TI diferentes:

 • Entradas para eventos: un evento es un registro de algo que sucedió en
el entorno de TI. Los eventos se pueden detectar mediante herramientas
de monitoreo de red que capturan y agregan registro de eventos de
aplicaciones de toda la red.
• Entradas de alerta: las alertas son generadas por herramientas
automáticas de monitoreo de red. Pueden desencadenarse por eventos
anómalos como infracciones de acuerdos de nivel de servicio (SLA) o
indicadores clave de rendimiento (KPI) que se evalúan en función de los
datos de referencia.
• Tickets de incidentes.
Se define un incidente como: una interrupción no planificada de un
servicio de TI o una reducción en la calidad de un servicio de TI o una falla
de un elemento de configuración que aún no ha impactado un servicio de
TI.

Solicitar entradas.
Las solicitudes de servicio para la organización de TI se realizan a través del
sistema de emisión de boletos, incluida la provisión de servicios de rutina como
la instalación de software, la asignación de hardware o el cambio de contraseña
u otros datos de autenticación.

Creación de tickets de TI.

El primer paso en el ciclo de vida del soporte en TI es la creación de un ticket.
Con base en el valor del mantenimiento de registros del seguimiento preciso de
tickets.

En general, se debe crear un ticket de soporte siempre que se cumpla una de

estas condiciones:
• Se necesita un agente de TI para realizar una tarea.
• Se detectó un problema que afecta o podría afectar la productividad del
usuario o disponibilidad del servicio.
• Crear un registro de algo tiene valor comercial ya sea para incluir el
registro en el análisis de datos o para respaldar la toma de decisiones en
el futuro.
• Un incidente o incidente potencial se resolvió mediante procesos
automatizados (sin intervención humana).
• Un usuario resolvió un problema o una solicitud de servicio con
autoservicio.

Manejo de problemas en la administración de una mesa de ayuda para

empresas.
Cuando un cliente llama a la mesa de ayuda, generalmente significa que no
puede realizar su trabajo al máximo o, en algunos casos, no puede realizar su
trabajo en absoluto.
Hay distintos grados de importancia para cada llamada, no puede utilizar un
enfoque de primero en llegar, primero en ser atendido, en una mesa de ayuda.
Una mesa de ayuda debe equilibrar dos esfuerzos principales en todo momento:
✓ Resolver los problemas que son más críticos para el funcionamiento del
negocio de la empresa antes que otros problemas menos importantes y,
en segundo lugar.
✓ Asegurarse de que se lleve a cabo el trabajo que ha planificado que
mejorará el rendimiento.

Estableciendo prioridades.
La administración de la mesa de ayuda debe asegurarse de que no todos los
recursos se dirijan a una sola dirección y deben asegurarse de que el trabajo
planificado y el no planificado se realice al tiempo que atiende las necesidades
de los clientes mediante la reducción de problemas.

Hay dos preocupaciones principales que determinan el impacto en el

negocio.

1. Importancia del componente.

Al establecer la prioridad de una llamada entrante, lo primero que debe
hacer es establecer la importancia del componente involucrado. Un
componente puede ser, tecnología, impresoras, computadoras, etc.
proyectos o personas.
La persona que inicia la llamada también es un componente importante
para determinar el impacto en el negocio. Algunos presidentes de
empresas, por ejemplo, que son trabajadores muy prácticos deben
considerarse una prioridad más alta que otros empleados.
2. La gravedad del evento.
La gravedad de un evento se mide por la cantidad de funcionalidad que
ha perdido el componente. Por ejemplo, si el componente es una
computadora que ha dejado de funcionar por completo, la gravedad es
muy alta, pero si la computadora está funcionando a un nivel alto, pero
simplemente no puede enviar documentos a una impresora, la gravedad
es mucho menor.

Al determinar la gravedad, también se debe tener en cuenta el impacto en otras

personas. En el ejemplo anterior, si una computadora no puede imprimir
documento, esto podría afectar a una persona, pero si esa computadora es
compartida, que se usa para todos los consultores en su oficina, el problema de
esa computadora está afectando a toda la oficina. La gravedad en este caso es
mucho mayor.

Escalas de prioridad y gravedad.

La mayoría del software de gestión de la mesa de ayuda permitirá establecer la
prioridad y la gravedad de una llamada de asistencia mediante balanzas. Una
escala típica suele ser de 1 a 5, siendo 1 la gravedad más alta y 5 una gravedad
menor.
Mejora continua del servicio técnico.
Objetivos:

 identificar las funciones de una buena mesa de ayuda en la organización.

 conocer los procedimientos de gestión de una mesa de ayuda.

Mejora continua del servicio técnico

Los documentos técnicos de mejora del soporte técnico brindan información sobre los enfoques
estratégicos y las mejoras prácticas para el servicio y el soporte de ti. La mejora de la calidad del
soporte técnico puede proporcionar a las mejores organizaciones el soporte una ventaja
competitiva real.

Estos documentos técnicos de mejora el soporte técnico exploran los desafíos de soporte y
servicios de ti en un entorno global de problemas cada vez más complejos y clientes exigentes. El
proceso centrado en pregunta y el enfoque estratégico para mejorar la experiencia del cliente es
utilizado por muchas de las principales organizaciones de soporte global.

¿Que hace que una mesa de ayuda sea buena?

1. crear un catálogo de servicio: lo primero que se debe hacer es desarrollar un catálogo de

servicio de ti, esta hoja de ruta de diseñarse pensando en el usuario final e incluir toda la
información que necesita para abrir un ticket y solicitar el servicio. algunas de las piezas clave
que necesita su catálogo de servicios son: nombre el artículo de catálogo, categoría, software,
hardware, soporte, infraestructura, estructura de aprobación, costo de servicio, permisos de
seguridad y acceso, proceso de seguimiento de problemas, expectativa de entrega, punto de
contacto para consultas
2. ofrecer una base de conocimiento o un portal de autoservicio: uno de los grandes problemas
con los que se encuentran los empleados cuando solicitan ayuda a ti, es saber a quién
preguntar. en primer lugar el conocimiento institucional nunca parece estar escrito y cambia
constantemente. una mesa de ayuda interna o un flujo de trabajo basado en directorio,
ayuda a dirigir las preguntas automáticamente al departamento correcto.
3. desarrollar una cultura de ayuda: si el gerente de la mesa de ayuda está demasiado enfocado
en minimizar los costos entonces se terminará brindando un soporte al cliente deficiente, sin
embargo, si se concentra en brindar a los usuarios todo lo que necesita para realizar su
trabajo, entonces gana proactividad.
4. contratar buenos empleados para retener a los grandes empleados: una cosa es contratar
personas excelentes y otras mantenerlas y eso tiene mucho que ver con la experiencia de sus
empleados. los empleados comprometidos que se sentían personalmente involucrados en su
trabajo, estaban más dispuestos o empoderados para impactar la experiencia del cliente. hay
algunas cosas que se pueden hacer para prepararse para el éxito, se debe invertir y
capacitaciones en servicio al cliente para equipar a todo el equipo con las herramientas que
necesitan para tener éxito.
5. crear un flujo de trabajo que realice un seguimiento de los problemas de principio a fin.
brindar un soporte interno continuo es clave para el éxito de una empresa. tanto el cliente
 como el personal de la mesa de ayuda deberían poder ver el estado del problema de manera
inmediata. cualquier empleado de la mesa de ayuda debería poder intervenir en cualquier
ticket, en cualquier momento y ver el flujo de trabajo completo del problema para poder
avanzar hacia la resolución.

Gestión de problemas

Procedimientos: ayuda a garantizar la coherencia sus clientes merecen un servicio correcto y

parte de ese servicio debe implicar una experiencia constante en el trato con la mesa de ayuda.
Los procedimientos debidamente documentados también ayudan a facilitar la automatización. Si
se crea un procedimiento es mucho más fácil establecer un proceso automatizado, un ejemplo de
esto podría ser que su software de administración de la mesa ayuda podría disfrutar
automáticamente la llamada a un analista específico.

Los procedimientos deben estar escritos de manera breve, manteniendo lo simple.

Los procedimientos deben almacenarse en un solo lugar que sea accesible para todos en la
empresa. El mejor lugar es un sitio de intranet si la empresa usa uno o en una carpeta en su red a
la que todos tengan acceso.

Cada procedimiento debe revisarse con regularidad quizás anualmente o con mayor frecuencia si
es necesario su procedimiento deben estar fechados y deben contener información básica como
quien los escribió.

Hay algunas consideraciones que se deben evitar al escribir procedimientos:

 No duplique simplemente la información que está almacenada en otro lugar, en su lugar

debería hacer referencia a la información.
 No intente capacitar a las personas sobre cómo usar una herramienta en un
procedimiento, los manuales de formación deben estar separados de los procedimientos.

¿Qué procedimientos necesita el soporte técnico para la mejora continua?

Es imposible dar una lista completamente completa de los tipos de procedimientos que debe
tener cada mesa de ayuda, porque los objetivos de cada mesa ayuda son únicos, sin embargo,
existen algunas tareas universales como procesar una llamada de soporte.

Los procedimientos sobre cómo manejar una llamada debe incluir información sobre cómo
saludar a los clientes cómo registrar la llamada qué información deberá administrarse y qué
tecnología debe usarse para registrar la llamada.

cómo resolver un problema: este procedimiento debe incluir información como cómo aceptar un
problema cómo asignárselo a usted mismo, cómo asumir la responsabilidad de un problema,
cómo verificar las tendencias en la lista de problemas, obtener ayuda de otras personas y cómo
cerrar el problema.

Comunicar problemas a los clientes: como se comunicará con sus clientes, utilizar el correo
electrónico o el teléfono, qué información se debe transmitir siempre.
Cómo responder a una pregunta: este procedimiento debe escribir como determinar si el cliente
ha hecho la pregunta anteriormente, descubriendo así una tendencia, cómo hacer
recomendaciones al cliente como cursos o materiales de capacitación y cómo reenviar la llamada
si el analista no puede para responder a la pregunta

Cómo manejar una emergencia: por lo general a las emergencias se les asigna un nivel de
prioridad 1 su mesa de ayuda puede tener un proceso separado para llamadas con este nivel de
prioridad.

Procedimientos de recuperación ante desastres: ¿cómo funcionaría su mesa de ayuda sin

electricidad? es necesario formular este tipo de preguntas y deben documentarse en sus
procedimientos de recuperación ante desastres.
ESTANDARES DE GESTION

Objetivos:
✓ Identificar las habilidades necesarias para una buena gestión de TI
✓ Conocer el propósito de los estándares de gestión de TI

Estándares de Gestión
Cuando se trata de la gestión de TI en las empresas, la credibilidad del servicio es
esencial para un éxito operativo duradero. La credibilidad se gana cuando la
comunidad de usuarios finales acepta que el departamento de TI es capaz y está
equipado para cumplir.
Cómo se gana la credibilidad
Se necesitan las habilidades adecuadas, los estándares de sentido común y la
voluntad de aceptar todos los desafíos clave.
Gestión de TI
Como disciplina de gestión, la gestión de ti se define por las prácticas, políticas y
procedimientos utilizados para gestionar la selección, implementación, uso y
mantenimiento de todo tipo de tecnología de la información en todo tipo de entorno
empresariales, la gestión de ti es más que instalar y mantener la tecnología que ya
es bastante importante, también se trata de usar la tecnología de una manera que
soporte y transforme y se necesita una cartera diversa de habilidades de gestión
para construir una credibilidad de TI duradera.
Los gerentes y profesionales de TI también deben tener un conocimiento sólido de
las prácticas generales de administración y operaciones comerciales

Habilidades de Gestión:
1- Priorizar las solicitudes de trabajo: de acuerdo con las necesidades y
capacidades.
2- Manejar las quejas sin ponerse a la defensiva: Tener la piel dura.
3- Comunicarse de manera efectiva: Verbalmente y por escrito.
4- Reconocer y aprender de los errores: Reconocerlos.
5- Leer a las personas, las situaciones y saber cómo responder en
consecuencia.
6- Estar abiertos a riesgos razonables y calculados.
7- Delegar responsabilidades laborales según corresponda.
 8- Anticipar las objeciones y anticiparse a los problemas.
9- Hacer que cada usuario final se sienta “importante” y bien atendido.
10- Mantener la mente abierta: Mantenerse alejado del síndrome de aquino se
inventó
11- Mostrar voluntad de actuar: Evitar la parálisis del análisis
12- Evitar la tendencia a la micro gestión como un medio instintivo de
simplemente hacer las cosas.
Propósito de los estándares de gestión de TI
Los estándares de gestión de TI predefinidos proporcionan esa hoja de ruta,
brindándole prácticas y procedimientos probados para guiar las acciones y
decisiones de planificación.
Los estándares establecen una línea de base sobre cómo se administran los
proyectos y se prestan los servicios lo que ahorra tiempo, mejorar la calidad y reduce
los costos.
La visión de TI
En términos más amplios una “visión” de TI es un enfoque estratégico para
administrar los departamentos y funciones de tecnología de la información (TI).
dentro de entornos comerciales
Cuál es el propósito de una visión de ti
Para comprender el valor de administrar según una visión, primero debe
comprender la naturaleza de la función de TI dentro de la empresa. Las
responsabilidades de gestión de TI suelen estar a cargo de organizaciones,
departamentos de TI internos; estas organizaciones cumplen una doble función, por
un lado:
Los departamentos de TI operan para servir a los intereses comerciales
maximizando las inversiones en tecnología para cumplir con las metas y los
objetivos comerciales;
por otro lado:
También satisfacen las necesidades de “uso” del día a día de los usuarios finales,
empleados de la empresa, a medida que realizan las tareas asignadas y cumplan
las responsabilidades asignadas; esto convierte a los usuarios finales en los
consumidores de primera línea de los servicios de TI internos.
Metas y objetivo de la visión

Objetivo final de una visión estratégica: Es optimizar las funciones de TI y

maximizar los beneficios relacionados en cuatro aspectos claves
• Productividad: Hay que asegurar que TI cumpla su misión de la manera
más productiva posible, considerando en los servicios prestados, la
financiación disponible, las capacidades organizativas y las prioridades
establecidas.
• Relevancia: Hay que asegurar que los servicios de TI y la misión
organizacional sean consistentemente relevantes para el uso de la
tecnología, los objetivos organizacionales y las necesidades operativas.
• Sensibilidad: Asegurarse de que la organización de TI y responda total y
constantemente las necesidades existentes es decir consciente,
comunicativa y capaz de actuar y se mantenga el día con las necesidades de
circunstancias cambiantes.
• Aceptación: Asegurarse de que los servicios las políticas y los
procedimientos de TI se comuniquen por completo y se aplique de manera
coherente para lograr la máxima aceptación por parte de la comunidad de los
usuarios finales.

Las visiones de TI exitosa cumplen cada función Al ceñirse a cuatro principios

claves:
• Alineación: Para garantizar que el modelo organizativo de TI y todos los
servicios y deberes operativos relacionados estén correctamente alineados
con todas las metas y objetivos comerciales subyacentes.

• Compromiso: Asegurar que todos los interesados en la “visión” de ti estén

completamente comprometidos con la planificación relacionada con la
tecnología y los parámetros operativos de la cartera de servicios de TI.
Mejores prácticas
Asegurar que TI opere de manera estandarizada, confiando en estándares prácticos
de gestión y estrategias adecuadamente dimensionadas para las necesidades
tecnológicas y las capacidades organizativas.
Compromiso con el servicio al cliente
Asegurar que los servicios de TI se brinden de manera oportuna y de alta calidad
diseñados para hacerte valer las necesidades operativas de los usuarios finales de
primera línea, trabajando dentro de los límites establecidos por los intereses
comerciales y las mejores prácticas tecnológicas.
Condiciones de los estándares de gestión
Los estándares de gestión representan un conjunto de condiciones que:
➢ Demuestran buenas prácticas a través de un enfoque de evaluación de
riesgo paso a paso.
➢ Permite la evaluación de la situación actual utilizando datos, encuestas y
otras técnicas preexistentes.
➢ Promueve la discusión activa y el trabajo en asociación con los empleados y
sus representantes para ayudar a decir sobre las mejores prácticas que se
pueden realizar.
Errores de gestión comunes y cómo se puede evitarlos
Todo gerente comete errores. Una vez que ocurre un error, sólo hay una opción:
aceptarlo y solucionarlo. Asumir la propiedad nunca es fácil especialmente para los
gerentes que como líderes y mentores a menudo deben soportar el peso de los
errores que no han cometido. Un “error” es una acción específica que está mal
encaminada desde el principio y podría haberse evitado con un poco de
pensamiento atención y esfuerzo; si bien los errores pueden tomar cualquier forma
según el proyecto o la operación en curso, el gerente ti inteligente siempre puede
evitar las heridas auto infligidas del error común.
No comunicarse
Para evitar errores, los gerentes deben poder comunicarse claramente con
diferentes personas en diferentes niveles y autoridades dentro y fuera de la
organización, para evitar fallas en la comunicación los gerentes deben tomar
medidas proactivas para agudizar todas las habilidades de comunicación incluida la
comunicación verbal, la comunicación escrita, el don de la persuasión y las
habilidades de escucha crítica.
Al comunicarse los gerentes deben ser claros, concisos empáticos y seguros. La
clave es practicar, practicar, practicar. Nunca envíes correos electrónicos
confidenciales de inmediato se debe redactar dejarlo reposar volver a leer y luego
enviarlo, la comunicación eficaz requiere práctica y paciencia.
No delegar
No delegar es un error administrativo muy común. Es entendible. A veces más fácil
hacerlo uno mismo, bueno puede que sea más fácil pero no es prudente, los
gerentes deben tener confianza en sí mismo y en su personal para delegar el trabajo
de manera efectiva sabiendo que se puede delegar y que no.
Los gerentes también deben hacer una supervisión efectiva sobre el trabajo
delegado a través de estándares y pautas y deben mantener la responsabilidad por
las asignaciones de trabajo, delegar no puede ser simplemente entregar una tarea
y luego marcharse, el personal debe sentirse confiado, pero también debe saber
que se le pedirá que rinda cuenta y si es necesario que el gerente esté listo para
ayudar y brindar orientación.
 Introducción a la ISO 20000-1

Objetivos

• Conocer los entornos de la aplicación de la ISO 20000-1

• Identifica la función de la implementación de la ISO 20000-1 en una organización.

Introducción a la ISO 20000-1

Es el estándar internacional para la gestión de servicios, se usa con mayor frecuencia para
servicios de YI y administración de instalaciones y se aplica a organizar de grandes y pequeñas
que brindan soporte a clientes donde las áreas de riesgo pueden afectar las operaciones.

Esta normativa se ha preparado para especificar los requisitos para establecer, implementar,
mantener y mejorar continuamente un sistema de gestión de servicios.

Un sistema de gestión de servicio respalda la gestión del ciclo de vida del servicio, incluida la
planificación, el diseño, la transición, la entrega y la mejora.

La implementación y operación de un sistema de gestión de servicios proporciona visibilidad

continua, control de los servicios y mejora continua.

Esta normativa específica los requisitos para que una organización establezca, implementen,
mantenga y mejore continuamente un sistema de gestión de servicios.

Esta normativa puede ser utilizada para:

o Un cliente que busca servicio y requiere garantía con respecto a la calidad de esos
servicios.
o Un cliente que requiera un enfoque coherente del ciclo de vida del servicio por parte
de todos sus proveedores de servicios, incluidos los de una cadena de suministro.
o Una organización para demostrar su capacidad para la planificación, diseño, transición,
entrega y mejora de servicios.
o Una organización para monitorear, medir y revisar los sistemas de gestión de servicios
y los servicios.
o Una organización u otra parte que realice evaluaciones de la conformidad con los
requisitos especificados, un proveedor de información o asesoramiento en gestión de
servicios.

Este estándar garantiza que los procesos del sistema de gestión de servicios de TI de una
oración estén alineados con las mejores prácticas internacionales.

Así como las necesidades de la propia organización y se enfoca en:

✓ Liderazgo de servicio.
✓ Desarrollo de servicios.
✓ Entrega de servicios.
✓ Relaciones de servicio.
✓ Resolución de servicio.
✓ control de servicio.
 Términos y definiciones.

Disponibilidad

La disponibilidad es una característica que se aplica a un servicio o componente de servicio, un

servicio o componente servicio está disponible y es capaz de realizar su función requerida en
un momento específico o de acuerdo con un programa de tiempo preestablecido.

Línea de base de configuración.

Una línea de base configuración es una descripción oficial de un servicio o componente de

servicio que ha sido designado formalmente en un momento específico de su ciclo de vida.

Elemento de configuración.

Un elemento de configuración es cualquier elemento que necesita ser administrado y

controlado para asegurar la entrega exitosa de un servicio o servicio.

Por ejemplo: Incluyen elementos de software como aplicaciones, sistemas y módulos y

elementos de hardware como computadoras, herramientas, equipos, muebles y edificios.

Base de datos de gestión de la configuración.

Una base de datos de gestión de la configuración almacena datos sobre los atributos de los
elementos de configuración y las relaciones entre estos elementos.

Se utiliza para controlar elementos, realizar un seguimiento de cómo cambian a lo largo de su

ciclo de vida.

Mejora continua.

La mejora continua es un conjunto de actividades recurrentes que las organizaciones llevan a

cabo para mejorar su capacidad para cumplir con los requisitos del servicio.

Se pueden lograr mejoras continuas mediante realización de auditorías, revisiones y medición.

Acción correctiva.

las acciones colectivas son pasos que se toman para eliminar las causas de las no
conformidades eficientes, con el fin de evitar que se repitan.

Cliente.

Los clientes pueden ser personas u organizaciones y pueden ser externos o internos a la
organización del proveedor de servicios.
Documentos.

Cuando la información se coloca en un soporte, se convierte en un documento. Los ejemplos

incluyen políticas, procedimientos, planes, acuerdos, contratos, registro y descripciones de
procesos.

Efectividad.

La eficacia se refiere al grado en que se logra un efecto planificado. Las actividades planificadas
son efectivas y están actividades se llevan a cabo realmente y resultados planificados son
efectivos. Si estos resultados se logran realmente.

Incidente.

Un incidente es cualquier interrupción no planificada del servicio o cualquier reducción en la

calidad del servicio.

El término incidente también incluye cualquier evento que aún no haya interrumpido el
servicio al cliente o reducido su calidad.

Seguridad de la información.

El propósito de la seguridad de la Información es proteger y preservar la confidencialidad,

integridad y accesibilidad de la información.

Incidente de seguridad de la información.

Un incidente de seguridad de la información se compone de uno o más eventos de seguridad

de la información no deseados o inesperados que posiblemente podrían comprometer la
seguridad de la información, y debilitar o perjudicar las operaciones comerciales.

Parte interesada

Una parte interesada es una persona o grupo que tiene interés en el éxito o en el desempeño
de las actividades de un proveedor de servicios.

Las partes interesadas pueden provenir de dentro o fuera de prevención. Ejemplo de partes
interesadas incluyen clientes, proveedores, propietarios, socios, empleados, sindicatos,
banqueros o miembros de la general.
Introducción a COBIT Parte I
Objetivos:

 Conocer la función del marco de gestión de COBIT dentro de una organización.

 Identificar los componentes del marco de gestión de COBIT.

Introducción a COBIT

COBIT abreviatura de objetivos de control para tecnologías de la información y afines, se

desarrolló por primera vez para guiar el gobierno y la gestión de ti. COBIT es uno de esos marcos
de mejoras prácticas pero su alcance es único entre la mayoría de los marcos en el sentido de que
se centra estrictamente en la seguridad la gestión de riesgos y la gobernanza.

Si se está buscando optimizar los procesos comerciales, sincronizar la TI con las necesidades
comerciales, modificar su infraestructura ti o administrar la nube múltiple, COBIT no es la
respuesta. COBIT es esencial para desarrollar controlar y mantenerle el riesgo y la seguridad de las
empresas de todo el mundo, independientemente de su industria.

Estructura COBIT

Desde el nivel más alto COBIT el crea una estructura de tres niveles compuesto por los siguientes
segmentos:

Requisitos comerciales criterios de información incluidas métricas como integridad, efectividad

disponibilidad, eficiencia, cumplimiento, confidencialidad y confiabilidad.

Los recursos de ti incluida la infraestructura, las aplicaciones, la información y las personas.

Procesos de ti divididos en procesos de dominios.

Todos los procesos del cubo se enumeran en cuatro dominios: planificar y organizar, adquirir e
implementar, entrega y soporte, monitorear y evaluar

Especificaciones del marco COBIT

la orientación comercial y la forma de operación de COBIT comprende la vinculación de los

objetivos comerciales con los objetivos de ti proporcionando métricas de información y modelo de
madurez para determinar el nivel de logros y señalar las responsabilidades interrelacionadas de los
propietarios de procesos de ti y negocios.

Para comprender completamente el alcance del modo de operación del marco COBIT, se
proporcionan dos parámetros principales:

1. el control es la forma de procedimientos, prácticas, políticas y estructuras organizativas

diseñadas para proporcionar un nivel aceptable de garantía de que se alcancen los
objetivos y estrategias comerciales y que los incidentes no deseados se detectaran y
corregirán de manera rápida y concisa
2. el objetivo de control de TI es una declaración del nivel de resultados aceptables que se
deben lograr mediante la implementación de procedimientos de control relacionados con
una operación de ti en particular.
Hay dos clases distintivas de modelo de control disponible en la actualidad:

 Los de la clase de modelo de control empresarial.

 Los modelos de control más enfocados para TI.

COBIT tiene como objetivo cerrar la brecha que existe entre las 2. Además de ser más integral para
la gestión COBIT también opera a un nivel más alto que los estándares de tecnología para la
gestión de sistemas de información.

el concepto básico subyacente del marco COBIT es que el control en TI se logra al enfocarse en la
información que se requiere para respaldar los objetivos o requisitos comerciales y al tratar a la
información como resultado de la aplicación combinada de recursos relacionados con TI que
deben ser gestionados por procesos de TI.

Los componentes de COBIT incluyen:

Marco de referencia: organiza y categoriza los objetivos de gobierno de ti y la buena práctica por
dominios y procesos de ti antes de asociarlos con tus respectivos requisitos comerciales.

Descripciones de proceso: un modelo de proceso de referencia y un lenguaje común para todos en

una empresa.

Objetivo de control: utiliza este conjunto completo de requisitos de alto nivel para un control
eficaz de cada proceso de ti.

Pautas de manejo: asigna responsabilidades, acuerda objetivos, mide el desempeño e ilustra la

interrelación con otros procesos.

Modelo de madurez: evalúa la madurez y la capacidad por proceso y ayuda a abordar las brechas.

Beneficios de COBIT

COBIT ofrece modelos para ayudar a maximizar el valor y la confianza en ti y estas pautas
extendidas brindan a los profesionales de consultoría de seguridad riesgo recompensa negocio y ti
un marco más extenso para ayudar a entregar y mantener los objetivos estratégicos
empresariales.

Algunos de los numerosos beneficios de COBIT se enumeran a continuación:

Ayuda a lograr la excelencia operativa a través de la aplicación eficiente y efectiva de tecnología y

confiabilidad.

Optimiza el costo de los servicios y la tecnología de ti

Ayuda a gestionar y mantener los riesgos relacionados con las ti

Garantiza el uso de ti de manera eficaz e innovadora para alinearse con los objetivos comerciales
estratégicos.

Mantiene información de alta calidad para ayudar a respaldar las decisiones comerciales.
Ofrece soporte completo para firma de ti que cumplen con políticas regulaciones leyes relevantes
y acuerdos contractuales orientados al negocio

Quien usa COBIT

Debido a que COBIT 2019 es un marco empresarial, tres tipos de personas suelen interactuar
directamente con el marco COBIT:

 Gestión. COBIT ayuda a los gerentes de empresas a equilibrar el riesgo con la recompensa
y a controlar las inversiones en un mundo de ti en constante cambio.
 Auditores. COBIT ayuda a los auditores a obtener una opinión aceptable sobre la tasa de
seguridad sobre el tema que se audita y ofrece asesoramiento a la administración sobre
los controles internos.
 Usuarios: los usuarios empresariales generalmente empleados de té interno pueden
comprometerse con los principios de COBIT para garantizar la seguridad y los controles de
los servicios de ti proporcionados por partes internas o externas.
Introducción a COBIT (Parte 2)
Marcos de gobernanza alternativos a COBIT
Todos los marcos de gobierno tienen el mismo objetivo:
• Implementar las mejores técnicas operativas para pérdidas financieras
mínimas por fallas de cumplimiento. Estos marcos tienen como objetivo
facilitar que las empresas se sometan y aprueben auditorías
reglamentarias.

Comparemos el concepto
• ITIL: un conjunto de publicaciones de mejores prácticas para la gestión
de servicios de TI.
• COBIT: un marco empresarial para la gobernanza y la gestión de la TI
empresarial.
• ISO 20000: un estándar internacional para los requisitos del sistema de
gestión de servicios de TI.

Según su tiempo
• ITIL: cinco publicaciones principales con un total de aproximadamente
1800 páginas, más publicaciones complementarias.
• COBIT: publicación básica en 94 páginas, más 230 páginas para
procesos de habilitación y otras publicaciones.
• ISO 20000: la parte 1 (requisitos del sistema de gestión de servicios) tiene
36 páginas, hay otras partes que cubren otros aspectos.

¿Cómo se ve en el mercado?
• ITIL: se centra en los procesos internos. Las versiones recientes han
incorporado un ciclo de vida del servicio y un mayor enfoque en el valor y
los clientes.
• COBIT: proviene de un historial de auditoría y cumplimiento. La última
versión se ha movido hacia el gobierno y la gestión de servicios de TI.
• ISO 20000: es un estándar internacional y el objetivo principal es lograr la
certificación para demostrar el cumplimiento del estándar.

¿Quién lo usa generalmente?

• ITIL: cualquier organización que brinde servicios de TI internos o
externos. Se utiliza con mayor frecuencia en departamentos operativos de
TI.
• COBIT: organizaciones de TI internacionales de grandes empresas.
Utilizado a menudo por equipos estratégicos y personas responsables de
auditoría y cumplimiento.
• ISO 20000: organizaciones de TI que quieran demostrar que cumplen con
un estándar definido externamente.

¿Para qué se utiliza principalmente?

• ITIL: ayudando a definir los procesos operativos de gestión de servicios
de TI.
• COBIT: definición de requisitos de auditoría y cumplimiento para TI.
• ISO 20000: demostrar que la organización de TI cumple con un estándar
reconocido.
COBIT describe un estándar como una práctica comercial o un producto
tecnológico que generalmente es aceptado y respaldado por la empresa o el
equipo de administración de TI.

¿COBIT es adecuado para todas las empresas?

Al igual que con cualquier marco o protocolo de mejores prácticas, la estructura
es solo eso: un camino a seguir.

La implementación exitosa que da como derivación los resultados comerciales

necesarios para una empresa se basan en una combinación de adopción interna
generalizada, análisis basados en datos y la combinación adecuada de personas
y cultura.

El cambio no es fácil y el cambio lleva tiempo; ambos son factores clave para
saber si COBIT puede ayudar a respaldar la mejora de la gobernanza y la
seguridad de TI.
Introduccion a ITIL Parte1

Objetivos

 conocer qué es la gestión o marco ITIL

 identificar la estructura de la actividad que se necesita para una buena gestión ITIL

Introducción ITIL

ITIL se ha convertido en el estándar de

facto en la gestión de servicios de ti y
ayuda a organizaciones de todo tipo de
industria a ofrecer su servicio de una
manera económica y basada en la calidad.

la biblioteca de infraestructura de tecnología de la información útil por sus siglas en inglés

es un conjunto de mejoras prácticas para brindar servicios de ti estandarizada la selección
la planificación entrega y soporte de los servicios de TI para maximizar la eficiencia y
mantener niveles predecibles de servicio y tiene varios principios clave que se realizan a
través de cinco componentes centrales algunos conceptos y principios clave de ITIL son:

1. Entregando el máximo valor a los clientes

2. Optimización de recursos y capacidades
3. Ofreciendo servicios útiles y confiables
4. Procesos de planificación con objetivos específicos en mente
5. Definir roles de forma clara para cada tarea

Términos clave de ITIL

Capacidades: las habilidades especializadas que una organización aplica a los recursos
para crear valor
Funciones: subconjuntos autónomos de una agregación destinados a realizar tareas
específicas, suelen adoptar la forma de un grupo de personas y las herramientas que
utilizan
Procesos: conjunto estructurado de actividades diseñadas para lograr un objetivo
específico

Las características básicas de los procesos son:

los procesos tienen las siguientes características: transforman entradas en salidas,

entregan resultados a un cliente o interesado específico, son mensurables, son
desencadenados por eventos específicos, recursos, las materias primas que contribuyen
a un servicio como dinero equipo tiempo y personal.

Otros términos clave de ITIL son:

Roles: colecciones definidas de responsabilidades y privilegios los roles pueden estar a

cargo de individuos o equipos
Activos de servicio: también conocido simplemente como activos se refiere a los recursos
y capacidades que un proveedor de servicio debe asignar para ofrecer un servicio
Gestión de servicio: capacidades especializadas para ofrecer valor a los clientes en forma
de servicio
Servicios: un medio de ofrecer valor a los clientes sin exigirles que asuman costos y
riesgos específicos

Valor utilidad y garantía

El valor de servicio consta de dos componentes utilidad y garantía los servicios deben
ofrecer utilidad y garantía para tener valor la utilidad también llamada idoneidad para el
propósito se refiere a la capacidad del servicio para eliminar restricciones aumentar el
rendimiento al cliente.
la garantía también llamada idoneidad para el uso es la capacidad del servicio para operar
de manera confiable

Marco ITIL

El marco de ITIL se divide en cinco grandes etapas o categorías:

1. Estrategia de servicio.
2. Diseño de servicios.
3. Transición del servicio
4. Operaciones del servicio.
5. Mejora continua

Estrategia de servicio.

El propósito de la estrategia de servicio de proporcionar una estrategia para el ciclo de

vida del servicio la estrategia debe estar sincronizada con los objetivos comerciales la
utilidad y la garantía de este componente están diseñados para garantizar que el servicio
sea adecuado para su propósito y acto para su uso respectivamente. Cada categoría
principal tiene subcategorías dentro de la categoría de estrategia de servicio hay cuatro
categorías

a) Gestión de la cartera de servicios: la cartera de servicio es el conjunto completo

de servicios gestionados por un proveedor de servicio, consta de tres partes
principales: canalización de servicio, catálogo de servicios y servicios retirados
b) Gestión de la demanda: el proceso de la gestión de la demanda se ocupa de
comprender e influir en la demanda de los clientes se tratan de perfiles de usuario
que garantiza diferentes grupos típicos de usuarios para un servicio determinado y
patrones de actividad empresarial
c) Gestión financiera: el proceso de gestión financiera proporciona un medio para
comprender y gestionar los costes y las oportunidades asociadas con los servicios
incluye las siguientes actividades básicas: contabilidad, seguimiento de cómo
gasta el dinero un proveedor de servicio, elaboración de presupuestos,
planificación de como un proveedor de servicio gastará el dinero cobro asegurar el
pago de los clientes por los servicios prestados
d) Operaciones estratégicas: las operaciones estratégicas aseguran que los
servicios como el cumplimiento de las solicitudes de los usuarios la resolución de
fallas del servicio la resolución de problemas y la realización de tareas operativas
de rutina se realizan de manera eficiente y efectiva
Diseño de servicios

La fase del ciclo de vida del diseño del servicio trata sobre el diseño de los servicios y
todos los elementos de apoyo para su introducción en el entorno en vivo las 4p del diseño
de servicio representan áreas que deben
tenerse en cuenta al diseñar un servicio, ellos son:
 Personas recursos humanos y estructuras organizativas necesarias para dar
soporte al servicio
 Procesos gestión de servicios necesarios para respaldar el servicio
 Productos tecnología y otra infraestructura necesaria para respaldar el servicio
 Socio terceros que ofrecen soporte adicional requerido para respaldar el servicio

Dentro del diseño del servicio tenemos las siguientes subcategorías:

a) Gestión de catálogo de servicio: el catálogo de servicios es un subconjunto que
contiene servicio disponible para clientes y usuarios a menudo en la única parte de
la cartera de servicio visible para los clientes por lo general actúa como portal de
entrada para todos los servicios de información en el entorno en vivo
b) Gestión del nivel de servicio: la gestión del nivel de servicio se encarga de
asegurar y gestionar los acuerdos entre los clientes y el proveedor de servicios
con respecto al nivel de rendimiento utilidad y el nivel de fiabilidad garantía
asociado Con servicios específicos
c) Gestión de la disponibilidad: el proceso de gestión de la disponilidad se ocupa
de la gestión y el logro de los requisitos de disponibilidad acordados según lo
establecido en los acuerdos de nivel de servicio en ITIL la disponibilidad se define
como la capacidad de un sistema servicio o elemento de configuración para
realizar su función cuando sea necesario
d) Gestión de la capacidad: la gestión de la capacidad se ocupa de garantizar que
en todo momento exista una capacidad rentable que cumpla o supere las
necesidades de la empresa según lo establecido en los acuerdos de nivel de
servicio
e) Gestión de la continuidad del servicio: el proceso de gestión de la continuidad
del servicio garantiza que el proveedor de servicios siempre pueda proporcionar
los niveles de servicio mínimos acordados la gestión de la continuidad del servicio
de ti utiliza técnicas como el análisis de impacto empresarial y la gestión de riesgo.
f) Gestión de la seguridad de TI: la gestión de la seguridad y se centra en proteger
estas cualidades básicas de los activos de información.
Garantía de confidencialidad de que el activo está disponible sólo para las partes
apropiadas
Garantía de integridad que el activo no ha sido modificado por partes no autorizadas
Disponibilidad, garantía que el activo puede utilizarse cuando sea necesario
Autenticidad, garantía que las transacciones y las entidades de las partes de las
transacciones son genuinas
Garantía de no repudio de que las transacciones una vez completadas, no pueden
revertirse sin aprobación

g) Gestión de proveedores: la gestión de proveedores se encarga de obtener una

buena relación calidad-precio de los proveedores externos desempeña un papel
muy similar al de la gestión del nivel de servicio, pero con respecto a los
proveedores externos en lugar de los proveedores y los clientes internos externos
Transición del servicio el objetivo del proceso de transición del servicio es construir e
implementar servicios de ti asegurando de que los cambios en los servicios y los
procesos de gestión del servicio se lleven a cabo de manera coordinada.
En esta fase del ciclo de vida el diseño se construye, se prueba y se traslada a la
producción para permitir que el cliente comercial logre el valor deseado

Hay siete procesos dentro de la categoría de transición del servicio:

a) gestión de cambios
el objetivo de esta actividad de procesamiento es controlar el ciclo de vida de
todos los cambios con una interrupción mínima de los servicios de ti

b) evaluación
el objetivo del proceso de evaluación es evaluar los cambios importantes como
la introducción de un nuevo servicio o un cambio sustancial en un servicio
existente antes de que se permita que esos cambios pasen a la siguiente fase
de su ciclo de vida

c) planificación y apoyo a la transición

este proceso se enfoca en planificar y coordinar el uso de recursos para
implementar una versión importante dentro de las estimaciones de costos,
tiempos y calidad prevista.

d) gestión del lanzamiento y despliegue

el objetivo de este proceso es planificar programar y controlar el movimiento de
las versiones a los entornos de prueba y en vivo asegurando que la integridad
del entorno en vivo esté protegida y que se liberen los componentes correctos.

e) validación y prueba del servicio

este proceso garantiza que las versiones implementadas y los servicios
resultantes cumplan con las expectativas del cliente y verifica que las
operaciones de ti pueden respaldar el nuevo servicio.

f) gestión de activos y configuración del servicio

el objetivo es mantener información sobre los elementos de configuración
necesario para ofrecer un servicio de ti incluidas sus relaciones.

g) gestión del conocimiento

el objetivo es recopilar, analizar, almacenar y compartir conocimiento e
información dentro de una organización mejorando la eficiencia a reducir la
necesidad de redescubrir el conocimiento.

operaciones de servicio
esta etapa se enfoca en satisfacer las expectativas de los usuarios finales mientras
que equilibran los costos y se descubre cualquier problema potencial. esta es la única
categoría de las cinco que tiene funciones además de procesos hay cinco procesos y
cuatro funciones

Los procesos de la operación de servicios son:

a) gestión de eventos
el objetivo es asegurarse que los elementos de configuración y los servicios se
supervise constantemente y filtrar y categorizar eventos para decidir las
acciones adecuadas.
 b) gestión de incidentes
el objetivo es gestionar el ciclo de vida de todos los incidentes devolviendo
servicios de ti a los usuarios lo más rápido posible.

c) solicitud de cumplimiento
el objetivo es cumplir con las solicitudes de servicios que en la mayoría de los
casos son cambios menores, por ejemplo, solicitudes de cambio de contraseña
o
solicitudes de información

d) gestión de acceso
el objetivo de otorgar al usuario autorizado el derecho a utilizar un servicio y al
mismo tiempo evitar el acceso a usuarios no autorizados

e) gestión de problemas
el objetivo de gestionar el ciclo de vida de todos los problemas evitando que
ocurran incidentes y minimizando el impacto de los incidentes que no se
pueden prevenir

Las funciones de las operaciones de servicios son:

a) gestión de operaciones de ti
el objetivo es monitorear y controlar los servicios de ti y su infraestructura
subyacente ejecutando las tareas rutinarias del día a día relacionadas con la
operación de los componentes y aplicaciones de la infraestructura

b) mesa de servicio
este es el punto de contacto entre los usuarios y el proveedor de servicio una
mesa de servicios generalmente maneja la comunicación con los usuarios y
también maneja incidentes y solicitudes de servicio

c) gestión de aplicaciones
la administración de aplicaciones es responsable de administrar las aplicaciones a
lo largo de su ciclo de vida

d) gestión técnica
la gestión técnica proporciona experiencia técnica y soporte para la gestión de la
infraestructura de ti

mejora continua del servicio

el objetivo de esta etapa es utilizar métodos de gestión de la calidad para aprender de
los éxitos y fracasos pasados su objetivo es mejorar continuamente la eficacia y la
eficiencia de los procesos y servicios de ti de acuerdo con el concepto de mejora
continua, adoptado en ISO 2000. Sólo hay un proceso en esta área y consta de siete
pasos:

1) identificar estrategias de mejora

2) definiendo lo que se medirá
3) reuniendo Datos
4) procesando datos
5) analizando datos
6) presentar y utilizar la información extraída de los datos
7) usando la información para mejorar