Procesos de Negocio: Clase 1 Manuel Torres Pereira

Procesos de Negocio
Clase 1
Manuel Torres Pereira
torres.pereira.manuel@gmail.com
Qu es un proceso de negocio?
Proceso
Conjunto ordenado de paso que tienen como fin
alcanzar un objetivo.
Proceso de Negocio
Conjunto de tareas o actividades que se
encuentran relacionadas, que hacen uso de los
recursos de una organizacin para proveer
resultados establecidos, con el fin de alcanzar los
objetivos del negocio.
Cubren necesidades
Siempre de se debe preguntar:
Quin es el cliente de este proceso?
Qu necesidades resuelve?
Cul es el mejor caso o el desempeo exitoso?
Agrega valor?
Si no se puede definir un fin que entregue valor.
Por qu se ejecuta?
Otras caractersticas
Responden a eventos
Son realizados por roles (personas) o
mquinas.
Automatizados o no.
Una parte o completos.
Pueden ser parte de otro proceso (Sub

procesos).
Funcin de Negocios
Conjunto de tareas relacionadas a un negocio
o rea de negocio.
Un rea de desarrollo que involucra trabajo
similar, empleados habilidades y conocimientos
especficos.
Ejemplos: Contabilidad, Finanzas, RRHH, Etc
Ejemplos
Produccin.
Ensamblar, Realizar calidad, Producir.
Ventas.
Identificar clientes, fidelizacin, vender.
Contabilidad y Finanzas.
Pagar cuentas, Generar facturas, Administrar
cuentas.
RRHH
Contratar, Evaluar, Afiliar.
Sistemas de Informacin
Ayudan a:
Generar eficiencia al automatizar procesos.
Re disear y hacer ms eficientes los procesos.
La mayora estn enfocados a la funcin de

negocio.
Dan apoyo a una nica funcin.
Hoy en da existen sistemas multi-funcionales.

ERP, CRM, SCM, etc
De lo tradicional a lo nuevo
Procesos de Negocio Multi-funcional

Transversales entre diferentes reas.
Generan equipos multidisciplinarios, con
diferentes funcionalidades para completar
cierta actividad o trabajo.
Ejemplo:
Completar un pedido de compra de un cliente.
Ejemplo
Procesos Crticos
El norte de una organizacin es analizar y
mejorar los procesos crticos, que entregan
valor al cliente.
Por lo general, son procesos multi-funcionales
que tienen como objetivo final el cliente de la
empresa, que idealmente deben estar
alineados con la estrategia del negocio.
Procesos No Crticos
No son esenciales.
Mejora a travs de centralizar funciones.
Estandarizar.
Simplificar.
Externalizar y automatizar actividades que no
agregan valor.
Ineficiencia
Mejora contina
Automatizacin.
Aumentar el rendimiento y productividad.
Racionalizacin.
Aumentar eficiencia de procedimientos.
Reingeniera de Procesos.
Cambio radical.
Cambio de paradigma.
Riesgo VS Retorno
BPM (Business Process Management)

Mtodos, tcnicas y software, con el flujo de
actividades y eventos que ejecutan las
organizaciones para cumplir los objetivos.
Complemento a una visin funcional de la
organizacin.
Con la tecnologa, permite hacer realidad la
entrega de valor del BPM para el negocio.
BPM
Los procesos.
Sus tareas.
Sus Ejecutores.
Sus Entradas y salidas.
Recursos.
Organizacin.
Estrategia y objetivos.
Sistemas de medicin e incentivo.
Responsabilidades.
Entorno
Clientes.
Proveedores
Otros.
BPM en Chile
El rea de BPM encargada de liderar proyectos
de procesos de negocio, de manera
centralizada.
rea BPM
Se considera la existencia
cuando al menos un
empleado se dedica a estos
temas.
Hoy, esta rea depende
principalmente de la Gerencia
de Informtica.
reas pequeas
reas pequeas
Centro de Excelencia (BPM-CoE)

Unidad encargada de proveer consultora
interna respecto al uso de BPM a las otras
reas del negocio.
Otorga principalmente un mayor beneficio
que un rea de BPM.
BPM CoE
Servicios BPM-CoE
Ms que modelar y documentar procedimientos.

Ms que automatizacin.
Modelacin de Procesos de Negocio
Modelos
Representacin abstracta de la realidad.
Representaciones pictricas de la realidad.
Para que sirven?

Elimina el sesgo.
En particular los que resultan de analizar un sistema
en base a como esta definido actualmente o como
una persona piensa que debe estar implementado.
Centralizado en lo importante.
Reduce el riesgo de olvidar requerimientos del
negocio porque estamos centrados en los resultados
tcnicos.
Comunicacin.
Con los usuarios finales (lenguaje menos tcnico).
Modelacin
Se busca:
Comprender funcionamiento actual.

Desarrollar una nueva visin.
Describir procesos.
Identificar responsabilidades y roles.
Por qu?
Un organigrama no es suficiente para entender el
negocio.
Vista dinmica del negocio.
Modelo de negocio es una representacin esttica de
la estructura y una vista dinmica de los procesos.
Propsito
Comprender problemticas actuales e identificar
mejoras para la organizacin.
Determinar el impacto de cambios en la
organizacin.
Entregar una comprensin clara de la
organizacin a los clientes, usuarios y otros.
Definir requisitos que debe cumplir un sistema
computacionales para apoyar la organizacin.
Entender como un sistema se adapta a la
organizacin.
Qu esperamos?
Constante adaptacin.
Permitan modelar el negocio para solucionar
problemas e identificar oportunidad de mejora.
Reducir costos, mejora calidad, otros.
Entendible para distintas audiencias.

Lenguaje no tcnico.
Modelacin simple y comprensible con una
notacin comn.
Describir en diferentes niveles de abstraccin.
Qu esperamos?
Son tiles para construir sistemas de
informacin.
Describen el contexto organizacional.
Ayuda en la toma de decisiones.
Que permita generar valor a los clientes.
BPMN (Business Process Model and

Notation)
Es una notacin grfica que se encuentra
estandarizada para diagramar proceso de
negocios en un workflow.
Busca ser entendible por todos los
involucrados.
Puente de comunicacin (rea tcnica y
comercial)
Actividad
Identificar un proceso crtico y no crtico de la
organizacin que se va utilizar para el
proyecto final.
Modelar los procesos utilizando BPMN
El trabajo debe ser en grupos de no ms de 5
alumnos.
Debe entregar los diagramas ms una
descripcin del proceso (breve).
Procesos de Negocio
Clase 2
Elementos de un Proceso de Negocio
Entidades
Son los elementos que son utilizados o generador
durante la ejecucin del proceso.
Fluyen a travs del proceso.
Pueden ir transformndose, a medida que avanza por el
proceso.
Es el contenido y no el medio.
Orden de compra (datos) puede ser enviada de manera
impresa, digital u otros.
Pueden ser de diferentes tipos.

Personas -> Empleados, clientes, pacientes.
Objetos -> Documentos, partes, seales.
Abstractos -> rdenes, quejas.
No es lo mismo que infraestructura.
Entidades
Tipos:
Entradas del proceso:
Entidades que se crean fueran del
alcance del proceso y se utilizan
dentro del mismo.
Salidas del proceso:

Entidades que se crean dentro del
proceso, y se utilizan fuera del alcance
del mismo.
Internas:
Entidades que se crean y se utilizan
dentro del proceso.
Actividades
Son los distintos pasos del proceso de
transformacin de las entidades, las que
requieren un esfuerzo para ser completadas.
Deben tener un nombre claro:
Verbo en infinitivo + sustantivo.
Ejemplos:
Entregar producto o entrega de producto.
Generar factura.
Entregar orden de compra.
Ejemplos de entidad y actividades

Ejemplo de una cafetera:
Cuando un cliente llega a una cafetera, tiene la intencin de
satisfacer una necesidad de tomar caf.
Esta necesidad se traduce en una orden, que fluye a travs del
proceso, comunicando la necesidad expresada por el cliente.
La orden del cliente (entidad) puede ser un documento fsico o una
orden verbal,
La orden cambia de forma a medida que transita por el proceso.
Por cada actividad se agrega un grado de cumplimiento a la

orden a medida que est avanza por el proceso.
Al finalizar el proceso la orden completa es entregada.
Para el cliente, la salida del proceso es una taza de caf.
Para el responsable del proceso, la salida es una orden completa de
manera satisfactoria.
Roles
Un rol corresponde a un nombre genrico para
los recursos de la organizacin que realizan las
actividades en uno o ms procesos.
Son desempeados por personas o sistemas.
De capacidad limitada.
Su trabajo tiene un costo para la organizacin.
Usualmente se agrupan de acuerdo a sus habilidades
y/o competencias (funcional).
En funcin del contexto, las personas, sistemas o

mquinas pueden desempear uno o ms roles
de un proceso.
Clientes
Es cualquier persona u organizacin que recibe las salidas del
proceso (producto, un servicio, informacin, etc.) que son
generados como resultado del proceso.
Pueden ser:
Clientes externos.
Suelen pagar por el producto o servicio final.
Clientes Internos.
Procesos posteriores.
Procedimientos de control
Sistemas
Ocasionalmente se deben considerar ambos tipos de clientes.

Quin recibe un elemento de una actividad para ejecutar otra del
mismo proceso no corresponde a un cliente.
Clientes
Ejemplos de clientes.
Proceso de venta de un producto.
Comprador.
Proceso de pago de un cheque.

Titular de la cuenta corriente.
Persona que cobra un cheque.
Proceso de reclutamiento de personal.

Gerente de rea que solicit nuevo personal (interno).
Nuevo personal reclutado (externo).
Proveedores
Proveedor es cualquier persona u organizacin que entrega
las entradas (productos, servicios, informacin, etc.) que
son necesarias para la ejecucin del proceso.
Pueden ser:
Proveedores internos.
De una etapa anterior.
Sistemas
Proveedores externos
Empresas externas que entregan insumos o servicios.
Quien genera un elemento de una actividad para la ejecucin

de otra del mismo proceso, no es un proveedor.
Proveedores
Ejemplos.
Proceso de venta de productos.
Productores de materia prima.
Proveedores de insumos de produccin.
Proceso de pago de cheque.

Titular de la cuenta corriente.
Persona que cobra el cheque.
Proceso de reclutamiento de personal.

Bolsas de empleo.
Universidades.
Insumos de oficina y hardware.
Descubrimiento de procesos
Aunque no haya proceso definidos o
documentados, generalmente hay conciencia de
que existen.
Es por ello que es descubrimiento y no
definicin.
Es importante salir del paradigma de funciones y
centrarse en uno enfocado a las actividades y el
valor que estas generan al cliente.
Lo primero: escoger un nombre

Usar nombres que hagan sentido al cliente (V + S).
Proveer servicio = Instalacin de equipo +
Activacin de nmero.
Entregar producto = Empaque de producto +
Despacho del producto.
Que se buen nombre

Que comunique el sentido del proceso.
Proceso de call center
Entrega de respuesta a reclamo
Que defina un alcance que entregue valor al

cliente.
Recibir solicitud de compra
Vender productos
Que sea independiente de los recursos utilizados.

Publicacin de resultados va sistema ALFA
Publicacin de resultados
HERRAMIENTAS PARA EL
DESCUBRIMIENTO DE PROCESOS
Matriz de descubrimiento
Al comenzar a trabajar con un proceso se
formulan la siguientes preguntas:
Desde donde hasta donde va mi proceso?
Quines pueden saber informacin relevante del
proceso?
Es importante definir el alcance del trabajo

antes de comenzar a trabajar.
Matriz de descubrimiento
Muy til y sencilla para definir el mbito sobre
lo que se trabajara.
Ejemplo Reparar auto
SIPOC (Supplier Input Process

Outputs Customers)
Una vez identificado un proceso, es normal que
surjan preguntas como:
Cules son los limites del proceso?
Que es interno, que es externo.
Quines interactan con el proceso?

A quienes debo satisfacer y a quien necesito para funcionar.
Cules son los elementos que fluyen desde y hacia el

proceso?
Que esperan del proceso y que necesita para funcionar.
SIPOC es una metodologa til para definir estas

caractersticas.
SIPOC
Proviene de la etapa Definir de la metodologa
Six Sigma (DMAIC).
Se desarrolla para definir el alcance del proyecto,
al identificar para cada proceso:
SIPOC - Metodologa
Centrado en el Cliente, empezando por:
SIPOC - funcionamiento
SIPOC Ejemplo: Reparar un auto
SIPOC Ejemplo: Reparar un auto
RECI
Muchas veces uno encuentra un proceso en que:
Hay falta de claridad en la asignacin de actividades.
Quin hace qu?
Hay problemas de gobernabilidad sobre el proceso.

Quin decide (polticamente) en cierta actividad?
No hay claridad sobre quin debe saber qu o aportar

con qu.
A quin se invita a opinar o a quin se le comunica
decisiones sobre ciertos aspectos del proceso?
RECI es una metodologa til para definir estas

situaciones.
RECI
Es una matriz de asignacin de
responsabilidades.
Se disea para asignar roles y responsabilidades
en la gestin e implementacin de procesos de
una organizacin.
Especialmente til en procesos transversales a
distintas reas, donde la responsabilidad de las tareas
puede no estar claramente definida.
RECI
RECI - formato
RECI - metodologa
RECI - Consideraciones
Siempre debe haber un nico Responsable (R) para
cada actividad.
Toda actividad debe tener al menos un Ejecutor (E).
En caso de que una actividad tenga ms de un ejecutor hay
que cuestionarse si es conveniente dividir la actividad o
generar un sub proceso.
Los dems asociados a RECI pueden repetirse o no

estar en una actividad.
Puede existir un Responsable que adems Ejecuta la
misma actividad (R/E).
Un sistema de informacin puede ser Ejecutor (E), pero
no Responsable (R).
RECI - Ejemplo
Primer paso asignar los roles a las fases
definidas.
RECI - Ejemplo
Primer paso asignar los roles a las fases
definidas.
RECI - Ejemplo
Detectar ambigedades y/o brechas para
resolverlas, dividiendo las fases en actividades
ms precisas.
RECI - Ejemplo
Actividad
Utilizar las tcnicas vistas en la clase de hoy a uno
de los procesos de la organizacin de estudio.
Matriz de descubrimiento.
SIPOC.
Matriz RECI.
Presentar la solucin propuesta en grupos.

Discusin de los resultados.
Debe considerar que el proceso sea crtico.
Procesos de Negocio
Clase 3
Modelo de Madurez de Procesos

MMPE: Modelo de Madurez de Procesos y
Empresa
Fuente: La auditora de procesos,Michael
Hammer, Harvard Business Review Amrica
Latina, Abril 2007.
Introduccin
El MMPE fue desarrollado por Michael Hammer
(1948 2008).
Padre de la reingeniera.
El objetivo principal de desarrollar el MMPE fue

crear un marco de referencia organizacional para
garantizar el buen desempeo de los procesos
durante el tiempo.
Se llama Sustentabilidad.
Lo modelos de madurez son:

Una medida relativa del lugar donde la empresa est.
Una manera eficiente de decidir hacia dnde ir.
Una herramienta para medir el progreso hacia esta
meta.
Existen varios modelos de madurez para las

distintas actividades de procesos.
CMMI para desarrollo
CMMI para adquisiciones.
Cobit.
Modelo de Madurez de Procesos y

Empresa
MMPE plantea:
Un modelo de madurez que contiene facilitadores de
procesos.
Mide el estado de los elementos que contribuyen a la
sustentabilidad de los procesos.
Evaluacin para cada proceso.
Se evala con un grupo de responsables y ejecutores del
proceso seleccionado.
Un modelo de madurez de capacidades de empresa.

Mide el grado de madurez de la empresa para apoyar los
procesos de negocio.
Evaluacin nica para toda la empresa.
Se evala a partir de la plana gerencial de sta.
MODELO DE MADUREZ DE
FACILITADORES DE PROCESOS
Elementos del modelo de madurez
Madurez de procesos en Chile

Mucho camino por recorrer respecto de los mecanismos de
gestin de procesos, como la existencia de un dueo de proceso.
Actualmente nadie se quiera hacer responsable de los procesos.
Nivel de madurez de facilitadores

Por cada facilitador se desglosa entre 2 y 3 elementos.
Existen cuatro niveles para cada elemento P1 hasta P4.
Hay una afirmacin para cada elemento, la cual se
marca con colores segn el cumplimiento de est en el
proceso:
Rojo (0% - 19%): no cumplido.
Amarillo (20% - 79%): alcanzado en cierta medida
Verde (80% - 100%): absolutamente cubierto.
Un proceso se encuentra en un cierto nivel de madurez

si todos sus elementos correspondientes a los 5
facilitadores estn en verde.
Evaluacin del nivel de madurez

Ejemplo

El elemento esta al menos en P-1. Se puede
pasar al siguiente nivel.

El elemento tiene aspectos que revisar en P-2,
pero se puede avanzar al siguiente nivel.

El elemento no cumple con el nivel de madurez P-3. No
es posible avanzar en la evaluacin de este elemento. El
elemento esta en nivel P-1.

Proceso en nivel P-0.
Es importante revisar
los elementos que
impiden que el
proceso avance al
siguiente nivel.
Definicin de los niveles

Cada nivel representa un nivel de integracin y mbitos
de accin del proceso.
P0: No definido.
Proceso poco definido, ejecutado de manera ad-hoc.
P1: Definicin de actividades.

Proceso segmentado, definido a nivel de reas funcionales.
P2: Definicin del proceso Integracin intra-proceso.

Proceso integrado entre diversas reas funcionales.
P3: Integracin inter-procesos, intra-empresas.

Proceso integrado con los dems proceso de la organizacin.
P4: Integracin inter-procesos, inter empresas.

Proceso integrado a nivel industria, cohesionado a travs de los
lmites de diversas organizaciones.
FAQS
Hasta que nivel debo llegar en el proceso N?
Depende de la criticidad del proceso.
Garantiza llegar al nivel Y un mejor

desempeo?
No, solo garantiza una mayor sustentabilidad.
Quin es el responsable?
Un alto rola dentro de la organizacin, pero no
necesariamente un Jefe Comn.
Madurez de facilitadores de procesos

Utilidad.
Entrega de informacin sobre la infraestructura que facilita la
sustentabilidad de los procesos.
Comunica un lenguaje de procesos a quienes participan de la
evaluacin.
Rpida aplicacin.
Enfoca las iniciativas de mejora de los procesos.
Aplicacin.
Se realiza una evaluacin para cada proceso.
Los niveles de los facilitadores se designan en torno al consenso.
Debe aplicarse en dos reuniones: una con grupo de ejecutores y
otra con grupo de responsables del proceso.
Metodologa de medicin del nivel de

madurez de los facilitadores de procesos.
1.- Definicin del proceso de negocio.

El primer es definir que se evaluar.
Escoger el proceso de negocio.
Nombrarlo de acuerdo a la convencin V+S.
Emisin de facturas.
Despacho de productos.
Reponer inventario.
Se recomienza completar la matriz de descubrimiento.
2.- Investigacin y levantamiento

Una vez seleccionado el proceso, es necesario
definir:
Actividades que lo componen.
Roles involucrados en la ejecucin de actividades.
3.- Evaluacin de madurez

En esta etapa se evala el nivel de madurez
del proceso en base a consenso.
Definir dos equipos que participarn en reuniones
independientes.
Ejecutores (RECI).
Responsables (RECI).
Agendar reuniones de aplicacin para cada

equipo.
Aplicacin de la herramienta MMPE.
3.- Evaluacin de madurez

Aplicar la herramienta de MMPE y guiar la conversacin.
En esta tarea se debe recoger la mayor parte de informacin para
evaluar el nivel de un proceso.
Es responsabilidad del moderador lograr un buen entendimiento
del significado de los facilitadores y de las aseveraciones planteadas
por MMPE entre los participantes.
Es importante documentar el estado del proceso y todos aquellos
comentarios que entreguen informacin relevante para mejoras.
3.-Evaluacin de madurez
Consejos:
Al evaluar los elementos se debe siempre mantener la
mirada de extremo a extremo.
Poner nfasis a los participantes que las afirmaciones se
aplican desde el inicio hasta el fin del proceso.
Evitar evaluar un proceso que est siendo mejorado o

reestructurado.
Es difcil evaluar las afirmaciones en estos casos.
Mejor evaluar una versin estable del proceso.
Evitar incluir a participantes ajenos a la organizacin

(outsourcing)
4.- Interpretacin de resultados y

elaboracin de propuestas.
Se debe analizar la evaluacin de los
facilitadores descrita por ambos grupos
y definir el nivel del proceso.
Es importante detectar diferencias
importantes de percepcin entre los
grupos (Responsables v/s Ejecutores) y
diagnosticar la causa.
Se deben identificar los facilitadores.
4.- Interpretacin de resultados y

elaboracin de propuestas
Elaboracin de propuestas.
El centro de anlisis debe ser como mejorar los
facilitadores ms dbiles que impiden el paso del
proceso a otro nivel de madurez.
Tambin se deben proponer acciones para mejorar
diferencias de evaluacin entre lderes/ejecutores o
entre distintas reas funcionales.
Las propuestas de mejora tienen que apuntar a
mejorar las condiciones de evaluacin de los
facilitadores.
Madurez de capacidades de la
empresa
Madurez de gestin de proceso en las

empresas
Ms de la mitad no cuenta con un mapa de
procesos formal.
Madurez de capacidades de la
empresa
Utilidad.
De manera anloga a los proceso, la evaluacin de capacidades
entrega informacin sobre las condiciones culturales y tcnicas
de la empresa que facilitan la sustentabilidad de los procesos.
Comunica un lenguaje de procesos a quienes participan de la
evaluacin.
Aplicacin.
La evaluacin de la matriz se hace de la misma manera que para
la evaluacin de los facilitadores de proceso.
Sin embargo, es slo una evaluacin, que aplica a la madurez de
las capacidades de toda la empresa.
Por lo mismo, se debe aplicarse slo a la alta gerencia y/o
personal que tenga influencia en la direccin de la organizacin.
Los 4 niveles del modelo de madurez

de capacidades.
E1.
Se poseen capacidades adecuadas para la administracin
ad-hoc de algunos procesos de la organizacin.
E2.
Se poseen capacidades para la administracin sistemtica
de varios procesos de la organizacin.
E3.
Se poseen capacidades para la administracin integrada de
los procesos ms importantes de la organizacin.
E4.
Se poseen capacidades para la orquestacin de los
procesos de toda la industria.
Anlisis crtico del MMPE

Desventajas
Debilidades de la herramienta.
El modelo no entrega una conexin entre los niveles
de madurez y el resultado financiero del negocio.
El modelo no incluyen un alineamiento a la estrategia
de la organizacin.
Crtica al modelo:
El modelo propone que todos los factores deben estar
en el mismo nivel. Esto no necesariamente aplica en
todos los casos, cada organizacin es nica.
Enfoque cualitativo y poco cuantitativo.

Ventajas
Herramienta simple.
Tras una breve introduccin, todos pueden crear e
interpretar las dos matrices.
Sirve de ayuda a construir un lenguaje de procesos.
Permite comunicar inquietudes entre Ejecutores y
Responsables.
Se aplica de forma participativa.

Los participantes se involucran en el proceso de
investigacin y transformacin.
Se introduce a los participantes en una mirada de procesos.
Se puede aplicar en forma autnoma.

No requiere consultora y se puede repetir peridicamente,
permitiendo evaluar efectividad de mejoras.

Ventajas
Aplicacin concreta.
Permite diagnosticar de manera rpida el nivel de
desarrollo de los procesos de negocio y las
capacidades actuales de la empresa.
Ofrece un marco de referencia para disear
mejoras a los procesos que me permita mejorarlos
gradualmente y de manera equilibrada.
Favorecer el aprender-haciendo.
Permite educar a las personas en cmo debe ser
una organizacin orientada los procesos.
Conclusin
Importancia.
Incentiva a una mirada integral al anlisis de
procesos.
Permite evaluar de manera sencilla y rpida.
Comunica en un lenguaje comn los requisitos
para que los procesos estn alineados con el
desempeo del negocio.
Permite recoger inquietudes propias de los
ejecutores y lderes, que con metodologas
estrictas son difcil de capturar.
Ingeniera de Software
Clase 4
Qu es?
Enfoque sistemtico.
Cuantificable.
Principios y calidad.
Trabaja utilizando modelos y metodologas.
Diseo de software.
Orientado al desarrollo y mantencin de
software.
Qu es?
El establecimiento y uso de principios de ingeniera
robustos, orientados a obtener econmicamente
software que sea fiable y funcione eficientemente
sobre mquinas reales. << F.L. Bauer Software
Engineering. Information Processing 71., 1972>>.
Ingeniera del software. (1) La aplicacin de un enfoque
sistemtico, disciplinado y cuantificable del desarrollo,
la operacin y el mantenimiento del software; esto es,
la aplicacin de ingeniera de software. (2) El estudio
de enfoques tales como (1). << IEEE Std 610-1990>>
Qu es?
Ingeniera es la aplicacin sistemtica de conocimiento
cientfico en la creacin y construccin de soluciones,
que satisfacen una buena relacin efectividad/precio,
de problemas prcticos al servicio de la humanidad. La
ingeniera de software es la forma de ingeniera que
aplica los principios de las ciencias de la computacin y
las matemticas en la obtencin de soluciones de los
problemas del software que satisfacen una buena
relacin efectividad/precio.
<< SEI Report on Undergraduate Software Engineering
Education, 1990>>
Qu no es IS?
Las ciencias de la computacin.
Fundamentos tericos y aspectos fundamentales
de la computacin.
Ingeniera de sistemas.
Aspectos de desarrollo basados en computadoras,
hardware , software y la ingeniera de procesos.
Bases de datos, control de aplicaciones, etc.
Para qu la IS?
Popularizado a fines de los aos 60.
Aparece en funcin de la crisis del software.
Hardware aumenta mucho ms rpido que el
software.
El desarrollo de software de grandes dimensiones
no generaba buenos resultados.
Retraso en plazos.
Problemas de presupuesto.
Calidad del producto baja.
Para qu IS?
Proyectos grandes necesitan un equipo
multidisciplinario.
La calidad de comunicacin entre los
miembros es un problema real.
Beneficiarse con experiencia de proyectos
anteriores.
Necesidad de planificar la evolucin y el
mantenimiento.
Para qu IS?
Priorizar la comunicacin entre el cliente y los
usuarios.
Comprender los requisitos del cliente.
Ejemplo: Programacin extrema: el cliente tiene
un representante en el equipo de desarrollo.
Para qu IS?
Existe la necesidad de estimar el dinero,
tiempo y esfuerzo necesario.
Estimacin por comparacin contra proyectos
anteriores.
Cunto cobramos? O Cunto nos costara?.
COCOMO (Constructive Cost Model).
Una de las partes ms difciles.
Proceso de desarrollo
Proceso.
Serie de actividades o tareas que sirven para
alcanzar un objetivo.
Proceso de desarrollo de software.

Conjunto de actividades, mtodos o tcnicas
utilizadas en la produccin y evolucin de un
software.
Proceso de desarrollo de software

Puede incluir.
Un modelo de ciclo de vida.
Divide el desarrollo del software en fases y define actividades que
deben efectuarse en cada fase.
Entrega directrices para definir cuando se ha terminado una fase y
continuar con la siguiente.
Define artefactos por cada fase.
Herramientas y equipamiento.
Organizacin y personal.
Restricciones.
Proceso de desarrollo de software = ciclo de vida de
software.
Ciclo de vida de software

Corresponde al periodo que inicia cuando se
concibe un software y finaliza cuando el
producto ya no esta disponible para su uso.
Incluye las fases de requisitos, diseo,
pruebas, una de instalacin y aceptacin y una
fase de operacin y mantenimiento.
Ciclo de vida de software.

Un modelo de ciclo de vida es una abstraccin
particular que representa un ciclo de vida
software. Un modelo de ciclo de vida se
denomina con frecuencia un ciclo de vida de
desarrollo de software (SLDC) << IEEE
Standard Glossary of Soft. Eng. Terminology >>
Modelado de software
Tan antiguo como la ingeniera.
Primero siempre se construyen modelos y se
aprende de ellos para construir el ente real.
Caractersticas.
Abstracto.
Comprensible.
Preciso
Predictivo.
Que no sea costoso
Propsito de un modelo
Comprender problemticas complejas
mediante el anlisis y la simulacin.
Comparar soluciones e investigar.
Ayudar en la comunicacin de ideas sobre un
problema o su solucin.
Deteccin de errores u omisin en el diseo.
En el software:
El modelo se convierte en la implementacin de
un software.
Por qu estudiar modelos?

Elevados costos en el desarrollo de software.
Comportamiento y funcionalidad del sistema
actual poco satisfactorio.
Alinear las necesidades de la organizacin con
la aplicacin de tecnologas de la informacin
de manera adecuada.
Proceso de desarrollo de Software

Necesidades de la organizacin.
Definir las actividades requeridas para el
desarrollo de sistemas de informacin completos
(personas, software, hardware y procesos).
Mantener coherencia en todos los proyectos de
una misma organizacin.
Involucrar puntos de control para realizar
revisiones de calidad y toma de decisiones.
El proceso de desarrollo de software

Divisin del producto.
Dividir el software a realizar en partes funcionales,
de tal manera que cada miembro del equipo de
desarrollo pueda desarrollar cada una de ellas.
Divisin del proceso

Significa dividir el desarrollo del sistema en
fases o etapas y normalmente se habla de
especificacin, diseo y construccin.
Qu?
Cmo?
Construccin.
Pruebas.
Modelo de ingeniera de software

(Thayer)
En un mundo ideal
El Cono de helado
Propuesta de Yourdon
Ciclo de vida del software: No olvidar

Contiene.
Los procesos.
Las actividades y tareas asociadas al desarrollo.
Explotacin y mantenimiento del software.
Incluyen la vida del sistema desde el inicio hasta la
finalizacin.
Definiciones
Ciclo de vida: Conjunto de etapas que ayudan en la
creacin de un sistema informtico.
Mtodos: directrices que se han de seguir en una tarea
(qu).
Tcnicas: modo de representacin para solucionar un
problema especifico (cmo).
Herramientas: proporcionan soporte automtico o
semi-automtico para el procesos y los mtodos.
Metodologa: conjunto coherente de mtodos y
tcnicas que cubren ms de una etapa del ciclo de vida.
Modelos de desarrollo o Paradigmas

Los paradigmas o modelos de desarrollo de software
sirven como estrategias de desarrollo para organizar las
diversas etapas y actividades del ciclo de vida del
software.
Describe las transiciones entre las etapas,
especificando qu actividades desarrollar.
La seleccin de un modelo depende de:
Naturaleza del proyecto.

Los mtodos.
Herramientas.
Controles.
Entregables.
Fases fundamentales
Definicin.
Que informacin ser procesada.
Funcin y rendimiento deseado.
Comportamiento del sistema.
Interfaces que se deben establecer.
Restricciones del diseo y lmite del sistema.
Criterios de validacin.
Definicin
En funcin del modelo o paradigma se sub
divide en:
Ingeniera de sistemas.
Planificacin del proyecto de software.
Anlisis de requisitos.
Fase de desarrollo
Definicin de estructuras de datos.

Como se caracterizarn las fases.
Diseo en programacin.
Pruebas y como se realizarn.
Tareas Principales:
Diseo.
Generacin de cdigo.
Pruebas.
Fase de mantenimiento
Centrada en:
Correccin de errores.
Adaptacin a medida que evoluciona el entorno
del software.
Cambios por los requerimientos cambiante del
software.
Correccin.
Adaptacin.
Mejora.
Prevencin (reingeniera)
Fase de mantenimiento
Actividades principales.
Gestin de riesgos.
Revisin de tcnicas formales.
Mediciones.
Calidad del software.
Seguimiento y gestin del proyecto.
Reutilizacin.
Esto implica que..

Si agrupamos las 3 fases anteriores se llega a:
Identificacin del sistema y definicin de
requerimientos.
Anlisis.
Diseo.
Desarrollo e implementacin.
Integracin y prueba del software.
Documentacin.
Entrenamiento y uso.
Mantenimiento del software.
Clase 5
Principales Modelos de Desarrollo
Ciclo de vida en cascada (tradicional).

Prototipo.
Modelo o ciclo de vida en espiralProgramacin exploratoria.
Transformaciones formales.
Modelos de desarrollo orientados a objetos.
Cascada o modelo tradicional

El objetivo de este modelo es establecer
orden en el desarrollo de grandes productos
de software.
Las etapas son procesadas de manera lineal.
Es la base de otros modelos, que es levemente
mejorada y retocada a travs del tiempo.
Sigue siendo utilizado.
Cascada o modelo tradicional

Se enfoca en especificar lo que el sistema tiene
que hacer (definicin de requerimientos) antes
de la construccin del sistema.
Define todos los componentes y su interaccin.
Gestiona la identificacin de errores y mejoras.
Genera un conjunto de documentos, que son
utilizados para validar la calidad y realizar el
mantenimiento del sistema.
Reducir costos en desarrollo y mantenimiento.
Etapas del modelo tradicional

Definicin de requerimientos.
Estudio con alto nivel de detalle con la situacin
actual del problema.
Definicin de los requerimientos del nuevo
sistema.
Anlisis y diseo del sistema.

Divisin modular del sistema.
Descripcin detallada de cada mdulo y sus
interrelaciones, con el fin de apoyar la fase de
codificacin.

Implementacin.
Por cada mdulo definido de la fase anterior, se
codifica con una herramienta o lenguaje, con el
que se realizar la construccin del sistema.
Integracin y pruebas.
Comprobar el correcto funcionamiento de cada
mdulo y todo el sistema una vez integrado.
Identificar errores en la codificacin, definiciones
de requerimientos y diseo.

Explotacin y mantenimiento.
Garantizar el mantenimiento del sistema.
Correccin de los errores identificados,
modificacin del sistema de acuerdo a los cambios
en el entorno.
Cul es la etapa que consume mayor tiempo?

Explotacin y mantenimiento, se considera un
costo adicional para el cliente.
Modelo tradicional: Desventajas

La definicin explicita de la totalidad de
requerimientos al principio del desarrollo.
Muy poca flexibilidad para modificaciones en
el sistema, no existe interactividad entre las
fases.
No existen resultados intermedios, hasta el
final. Por lo tanto la validacin de los
requerimientos iniciales no se realiza hasta
terminado el sistema.
Modelo tradicional: Desventajas

La implementacin de forma ascendente
implica:
Pruebas modulares.
Despus los subsistemas.
Sistema completo.
Existen problemas en la integracin de

subsistemas.
Objetivos por cada fase

Estudio del sistema actual y viabilidad del nuevo
sistema.
Identificacin de usuarios relacionados.

Estudio de su lugar de trabajo.
Deficiencia actuales.
Sugerencia hacia el futuro.
Definir objetivos del nuevo sistema.
Determinar la viabilidad proponiendo diversas
alternativas de solucin.
Planificacin del desarrollo.

Anlisis
Diagramas para especificar de manera estructurada
cada uno de los requerimientos, con el fin de modelar
el nuevo sistema. Considerando tambin el estudio de
situacin actual.
Diseo.
Definir un conjunto de mdulo e interfaces entre
ellos, desglosando la especificacin obtenida de la
fase anterior.
Sirve para apoyar la fase de codificacin, de tal
manera de transformar modelos lgicos a fsicos.

Implementacin
Obtener un producto final, con todos los
requerimientos inicialmente definidos, mediante
el uso de un lenguaje de programacin u
herramienta.
Generacin de pruebas de aceptacin.

Especificacin de un conjunto de pruebas
De funcionalidad, de carga de trabajo, de caja
negra o caja blanca, etc.

Garanta de calidad.
Entregar como resultado un producto de calidad.
Descripcin de los procedimientos.

La totalidad de documentacin que es necesaria
para describir tanto los procesos como el
producto resultante.
Instalacin e implantacin del nuevo sistema

en el entorno.
Instalar el producto resultante.
Modelo tradicional
La documentacin es transversal.
Modelo de Prototipo
Se utiliza principalmente cuando existe poca
claridad de los requerimientos o la rpida
evolucin de estos a travs del tiempo.
Recoger requerimientos => diseo rpido.
El diseo rpido se focaliza en la representacin
de los aspectos ms esenciales y qu sern vistos
por los usuarios.
Esto implica la construccin de un prototipo que
es evaluados por el cliente y el usuario, esta
autorizado a ir refinando los requerimientos del
software a ser desarrollado.
Modelo de Prototipo
Fases:
Anlisis y especificacin de requerimientos del
usuario.
Diseo e implementacin de un prototipo.
nfasis en las interfaces de usuario, equipos
pequeos para minimizar los costos de
comunicacin.
Modelo de Prototipo
Fases:
Utilizacin de herramientas de apoyo al
desarrollo.
Generadores de cdigo.
BPMS.
CMS.
Aplicaciones prefabricadas.
Ejercicio del prototipo, refinamiento iterativo del

prototipo.
Modelo de Prototipo
Fases:
Refinamiento de los requerimientos.
A partir de la fase 6 se sigue con el estndar del
ciclo de vida clsico.
Modelo de Prototipo
Obtencin
Especificacin
Construccin
Prototipo
Aceptado
Evaluacin
Cliente
Mejora de la
Especificacin
NO Aceptado
Ciclo de
Vida
Clsico
Modelo de Prototipo
Modelo de Prototipo: Desventajas

Muchas ocasiones el realizar un diseo rpido,
implica la utilizacin de fragmentos de
programas que ya existen y herramientas de
rpida generacin de software, lo que significa
que:
No se tiene en cuenta la calidad del software final.
No existe preocupacin por el mantenimiento.
Ineficiencia del programa resultante, utilizacin de
recursos, capacitacin y utilizacin de lenguaje
inadecuados.
Modelo de Prototipo: Utilidad

Cuando el o los clientes no saben lo que
quieren, pero indican que sabrn cuando lo
vean.
Cuando no quieren revisar modelos abstractos
(DFD, CU, etc).
Sistemas en lnea, importancia en la interfaz
ms que en los procesos.
Modelo espiral
Se genera una cada de continua de productos, los
cuales estn disponible para ser examinados y
evaluados por parte del cliente (iteraciones).
Entrega mecanismos para asegurar la calidad del
software.
Existe una re evaluacin al terminar cada fase,
que permite ajustar los cambios en la percepcin
de los usuarios, avances tecnolgicos o puntos de
vista econmicos.
Modelo espiral
Planificacin.
Se realiza la determinacin de objetivos, alternativas
de solucin, restricciones y elaboracin del plan de
desarrollo para el ciclo actual.
Anlisis de riesgos.
Evaluacin de alternativas, identificacin y resolucin
de riesgos.
Plan de mitigacin, impacto, probabilidad y planes de
contingencia.
Se decide si sigue el proyecto o no.
Modelo espiral
Ingeniera.
Desarrollo del producto siguiendo un modelo
tradicional, prototipo u otros.
Evaluacin.
Valoracin de resultados.
Validacin por parte del cliente.
Modelo espiral
Modelo espiral: Ventajas

Sirve de ayuda para eliminar errores en las
fases iniciales.
Es el mismo modelo para el desarrollo y
mantenimiento (iteraciones).
Entrega mecanismos para asegurar la calidad.
Sirve para proyectos complejos, dinmicos e
innovadores.
Modelo espiral: Ventajas

La re evaluacin luego de cada fase permite,
adaptarse a los requerimientos cambiantes de
los usuarios, modificar en funcin de los
avances tecnolgicos y econmicos.
Centrado en los objetivos y limitaciones,
ayuda a asegurar la calidad.
Modelo espiral: Dominio

Donde aplicar.
Proyectos complejos.
Dinmicos.
Innovadores.
Gran escala.
Todo tipo de proyectos.
Donde no aplicar.
Problemas de fcil resolucin.
Consume mucho tiempo en la definicin y mitigacin
de riesgos.
Modelo de programacin exploratoria.

Esta basado en el desarrollo de una
implementacin inicial, poniendo como base para
la opinin del usuario y luego se va refinando a
travs de varias etapas hasta llegar al resultado
adecuado.
Sistemas en los que es difcil establecer una
especificacin (IA, DM u otros).
No existen criterios de validacin claramente
medibles, por lo tanto implica una apreciacin
subjetivas por parte del clientes.
No sirve para grandes sistemas.
Modelo de programacin exploratoria.
Modelo de transformaciones formales

Se define de manera formal los requerimientos
del sistema, de manera metdica hasta llegar al
sistema definitivo.
Se puede demostrar el cumplimiento de los
requerimientos por validacin.
Aplicacin:
Nuevos S.O.
Dispositivos mdicos.
Lo ambiguo, lo incompleto, la inconsistencia se

descubre y corrigen ms fcil.
Ingeniera Inversa o Reingeniera

Analizar un programa y representar con un mayor
nivel de abstraccin que el cdigo fuente.
Se extrae la informacin a partir del diseo de
datos, de la arquitectura y del detalle mismo,
para lograr entenderlo.
La Reingeniera no solo sirve de ayuda para
recuperar informacin sobre el diseo de un
programa existente, sino que utiliza informacin
para reestructurar o reconstruir un programa
existente, con miras a adaptarlo a un cambio,
ampliarlo o mejorar su calidad.
Modelo de Orientacin a Objetos.

El uso de tcnicas de programacin centradas
en la orientacin a objetos, dio paso a un
nuevo modelo de diseo orientado a objetos.
Describe e implementan los sistemas de
informacin desde un punto de vista ms real.

Por lo general los modelos usuales estn
basados en el proyecto y los beneficios.
El Modelo de orientacin a objetos esta
centrado en el producto y la inversin.

Trminos importantes a considerar.
Reusabilidad:
Los nuevos sistemas OO pueden ser creados a partir de
otros sistemas OO ya existentes.
Extensibilidad:
Los sistemas nuevos OO son de fcil crecimiento, sin
tener que refinar los mdulos empleados en su
construccin.
Modelo Orientacin a Objetos.

Caractersticas principales:
Identidad:
Organizacin de datos en entidades discretas llamadas
objetos.
Los objetos pueden ser concretos o abstractos, pero
cada objeto tiene propia identidad.
Dos objetos son distintos incluso an en el caso que los
valores de sus atributos sean iguales.

Clasificacin:
Los objetos que tengan los mismo atributos y
comportamientos, son agrupados en clases.
Una clase es una abstraccin de la realidad que
describe propiedades (atributos y comportamiento)
que son importantes para una aplicacin determinada,
ignorando el resto.
Ejemplo.: una manzana tiene atributos comunes, tales
como tamao, peso y grado de maduracin.
Comportamiento, tal como mover, comer y coger.

Polimorfismo:
Permite que una operacin pueda ser realizada de
forma diferente en clases distintas.
Por ejemplo la operacin de mover, es distinta para una
pieza de ajedrez que para una ficha de damas.
Una operacin, corresponde a una accin que realiza
un objeto. Las operaciones se conocen como mtodos,
para una determinada clase.

Herencia:
Los objetos comparten atributos y operaciones,
mediante una relacin jerrquica (padre e hijo).
Una clase se puede definir de forma global y luego y
detallndose mediante subclases.
Cada subclase hereda las propiedades de su clase padre
(atributos y acciones) y aade sus propiedades
especficas.

Etapas.
Fase de planificacin y especificacin de
Requerimientos.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Definir el Plan-Borrador.
Crear el Informe de Investigacin Preliminar.
Definir los Requerimientos.
Registrar Trminos en el Glosario.
Implementar un Prototipo. (opcional)
Definir Casos de Uso (de alto nivel y esenciales).
Definir el Modelo Conceptual-Borrador.
Definir la Arquitectura del Sistema-Borrador.
Refinar el Plan.

Etapas.
Anlisis
1.
2.
3.
4.
5.
6.
Definir Casos de Uso.

Refinar diagramas de casos de uso.
Refinar modelo conceptual.
Refinar glosario.
Definir diagramas de secuencia.
Definir diagramas de estados o actividades.

Etapas.
Diseo.
Definir casos de uso reales.

Definir interfaz de usuario.
Definir arquitectura del sistema.
Definir diagramas de interacin (modelo del dominio).
Definir diagrama de clases.
Definir modelo de bases de datos.
Implementacin y pruebas.
Clase 6
Pregunta 1
Alternativas
Metodologas giles
Una seria de tcnicas para la gestin de
proyectos.
Contraposicin de los mtodos clsicos de
gestin.
CMMI.
Cascada.
Espiral.
Transformaciones formales.
Orientacin a objetos.
Metodologas giles
Las metodologas giles cumplen con el
manifiesto gil.
El manifiesto es un compendio de doce principios
que se agrupan en 4 valores principales.
Los individuos y su interaccin, por encima de los
procesos y las herramientas.
El software que funciona, frente a la documentacin
exhaustiva.
La colaboracin con el cliente, por encima de la
negociacin contractual.
La respuesta al cambio, por encima del seguimiento
de un plan.
Metodologas giles
Nuestra mayor prioridad es satisfacer al cliente mediante la
entrega temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en
etapas tardas del desarrollo. Los procesos giles
aprovechan el cambio para proporcionar ventaja
competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de tiempo
ms corto posible.
Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo el
proyecto.
Metodologas giles
Los proyectos se desarrollan en torno a
individuos motivados. Hay que darles el entorno y el apoyo
que necesitan, y confiarles la ejecucin del trabajo.
El mtodo ms eficiente y efectivo de
comunicar informacin al equipo de desarrollo y entre
sus miembros es la conversacin cara a cara.
El software funcionando es la medida principal de
progreso.
Los procesos giles promueven el desarrollo sostenible. Los
promotores, desarrolladores y usuarios debemos ser
capaces de mantener un ritmo constante de forma
indefinida.
Metodologas giles
La atencin continua a la excelencia tcnica y
al buen diseo mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad
de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseos
emergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre
cmo ser ms efectivo para a continuacin
ajustar y perfeccionar su comportamiento en
consecuencia.
SCRUM
Metodologa de desarrollo de proyectos de
software gil, que permite obtener el mejor
resultado posible en la gestin de un
proyecto.
Sirve de ayuda para proyectos complejos.
Se necesita ver los resultados de manera
acelerada.
Viene del trmino mel en Rugby, cuyo
significado es trabajar todos en equipo.
SCRUM
Caractersticas.
Colaboracin cercana al cliente.

Respuesta al cambio y predisposicin.
Desarrollo incremental con entregables a corto plazo.
Comunicacin verbal directa.
Compromiso y responsabilidad del equipo, auto
gestin.
Simplicidad en procesos.
Evasin de la burocracia.
SCRUM
Factores relevantes.
La toma de decisiones se realiza mediante equipos
auto-organizados.
Sentido de responsabilidad y autodisciplina.
El trabajo se centra en el compromiso del
desarrollo (entregables).
Entrega de informacin oportuna, transparencia y
visibilidad del proyecto.
Fases del desarrollo acopladas.
SCRUM
Factores relevantes.
La incertidumbre como elemento consustancial,
que el entorno asume y existe cultura
organizacional.
Aplica la transferencia y difusin del
conocimiento, tcnico o del negocio.
No existe un control exigente para cada individuo
del equipo, prioriza la auto gestin.
SCRUM
Sprint.
El proyecto avanza en medida que se van
cumplimiento bloques de trabajo, que se denominan
Sprint.
Tienen una duracin entre 2 a 4 semanas y al finalizar
cada uno se entrega una nueva funcionalidad.
Por cada Sprint se gestiona la evolucin del proyecto,
mediante reuniones de seguimiento breve.
Se realiza revisin del hito anterior y el plan para el
siguiente hito.
Las reuniones de seguimiento deben ser diarias (Daily
Sprint).
SCRUM
SCRUM
Sprint.
No existen cambios en un Sprint.
La duracin del Sprint va variar en funcin del
tiempo en que se compromete la nueva
funcionalidad.
En el caso de querer abortar un Sprint solo el
Scrum Master puede llevar a cabo esta accin.
La tecnologa no funciona.
Han cambiado la circunstancias del negocio.
Existen interferencias en el Scrum Team.
SCRUM
Componentes.
Roles.
Dueo del producto.
Scrum Master.
Scrum Team.
Reuniones.
Planificacin del Sprint.

Revisin del Sprint.
Retrospectiva del Sprint.
Reunin diaria Scrum.
Artefactos.
Pila de producto.
Pila de Sprint.
Grfica BurnDown.
SCRUM
Dueo del producto.
Es el responsable de la pila del producto y la correcta
priorizacin.
Define las prioridades de las funcionalidades en
funcin del valor de negocio.
Puede realizar modificaciones de funcionalidad y
prioridades para cada Sprint, pero no durante su
ejecucin.
Acepta o rechaza los resultados de cada entregable.
Es quin es el responsable del producto.
SCRUM
Scrum Master.
Esta encargado de la productividad y la funcionalidad
del equipo.
Es un facilitador encargado de eliminar la barreras
tcnicas y comunicacionales.
Favorece la cooperacin entre todos los roles y
funciones.
Evita que factores externos interfieran al equipo.
Asegura el correcto uso de SCRUM entre el equipo y el
dueo del producto.
Es responsable de todo el funcionamiento.
SCRUM
Scrum Team.
Define y selecciona el objetivo de cada Sprint.
Corresponde a un equipo multidisciplinario, que
es necesario para cumplir el objetivo de cada
Sprint.
Son auto-organizados con respecto a su trabajo.
Hacen visibles sus problemas para cumplir sus
objetivos especficos.
Su responsabilidad es el desarrollo.
SCRUM
Roles.
Cerdos (comprometidos con el proceso).
Gallinas (no son parte del proceso pero se deben
considerar)
SCRUM
Roles.
Cerdos (parte del proceso).
Scrum Master, el facilitador que asegura, gua y elimina la
grasa del proceso.
Dueo del producto, que existe en representacin del
cliente.
Scrum Team, responsables de la construccin del producto.
Gallinas ( no son parte del proceso).

Usuarios, quienes harn uso del producto.
Stakeholders (usuarios, sponsor, etc.).
Gerentes.
SCRUM
Reuniones (pauta)
Determinar la meta de la reunin.

Identificacin de implicados.
Definicin clara de duracin y objetivos.
Establecer reglas, revisin de contexto, moderado e
imparcialidad.
Toma de notas.
Al finalizar efectuar resumen de objetivos definidos.
Enviar acta a todos los participantes.
SCRUM
SCRUM
Planificacin del Sprint.
Dueo del producto, Scrum Master y Scrum Team.

Definicin del objetivo a cumplir con el Sprint.
4 horas como mximo.
Debe estar basada en la visin del dueo del producto
(Product Owner).
Elementos priorizados de acuerdo al valor del cliente.
Equipo define estimaciones desde la pila del producto
(Product Backlog).
El equipo escoge una meta en funcin de su velocidad,
estimaciones, productividad, etc..
Se hace uso del Tablero Sprint (Sprint Backlog).
SCRUM
Los elementos terminados, deben estar
conciliados por todos los miembros y en
particular por el dueo del producto.
SCRUM
Daily Scrum (reuniones diarias).
Reuniones de 15 minutos de manera diaria y que
debe ser de pie.
No es una reunin para solucin del problemas.
Todo el mundo esta invitado.
Solo el ScrumMaster, Product Owner y el Scrum
Team pueden dirigir la palabra.
Sirve para evitar las reuniones innecesarias.
SCRUM
Daily Scrum (reuniones diarias).
Sus principios estn enfocados en 3 preguntas.
Qu hiciste ayer?
Qu vas hacer hoy?
Hay obstculos en tu camino?
No es entregar un estado actual, si no tener claro
los compromisos frente al equipo.
SCRUM
Revisin del Sprint.
Anlisis y revisin de la funcionalidad o incremento
generado.
Se realiza la presentacin de los resultados del equipo.
Es una reunin donde participa tanto cerdos como
gallinas.
Duracin mxima de 4 horas.
Objetivo principal: presentar la o las nuevas
funcionalidades implementadas.
Todo el equipo participa.
Si existen modificaciones deben ser a solicitud del
Product Owner.
SCRUM
Retrospectiva del Sprint.
Al finalizar cada Sprint.
Son reuniones centradas en analizar el trabajo del
Scrum Master y el Scrum Team (opcionalmente el
Product Owner).
No superiores a 30 minutos.
Todos responden.
Qu cosas funcionaron bien?
Qu se podra mejorar?
Scrum Master anota las respuestas y mejoras, para ser

incluidas en el Product Backlog como elementos no
funcionales.
SCRUM
Product Backlog (Pila del producto).
Listado de funcionalidades y requisitos del producto.
Documento real.
Todos los integrantes del equipo de desarrollo pueden
contribuir en su construccin.
El responsable de la pila del producto y la priorizacin
es el Product Owner.
Debe estar al alcance de todos.
Originado principalmente por el plan de negocio
creado junto al cliente.
SCRUM
Se recomienda que el listado incluya:
Identificacin de la funcionalidad o tarea.

Descripcin.
Prioridad.
Estimacin.
Observaciones.
Criterios de validacin para ser terminado.
Nmero del Sprint en el que se llevara a cabo.
SCRUM
SCRUM
Sprint Backlog.
El equipo es el responsable.
Tiene el detalle de tareas de desarrollo que son
requeridas para completar los elementos de la pila del
producto.
Las tareas son estimadas y se van actualizando
diariamente.
No tienen un responsable al principio de cada Sprint,
cualquiera puede tomar una tarea (auto-gestin).
La pila del Sprint se debe manejar cerrada para
cualquier persona que no sea parte del equipo.
SCRUM
Sprint Backlog.
Cada miembro del equipo elige las tareas a realizar.
Nunca se debe asignar el trabajo por otra persona.
La estimacin del trabajo que falta, se actualiza
diariamente.
Cualquier miembro del equipo puede aadir, borrar o
cambiar el Sprint Backlog.
Si la tarea o trabajo no esta totalmente claro, se
puede modificar la cantidad de tiempo y subdividirla
luego.
Actualizar los tiempos de trabajo en medida de lo que
ms se conoce, dada la experiencia.
SCRUM
Sprint Backlog.
SCRUM
Sprint Backlog.
SCRUM
Burn-Down.
Se utiliza para el seguimiento de trabajo del Scrum Team.
Actualizacin diaria.
Sirve para visualizar si la meta original del Sprint ser
alcanzada o no.
SCRUM
Cmo estimar?
Planning poker.
Cartas de tipo numricas (0,
,1,2,3,5,8,13,20,40,100).
Valores altos implican:
Baja granularidad.
Alta complejidad.
Kanban
Viene definida como una metodologa para la
gestin de proyectos.
Su origen viene de la automotriz Toyota.
Kan: visual Ban: tarjeta o tablero.
Tarjeta visual o tablero visual.
Es un sistema utilizado para controlar el flujo

de actividades a travs de pequeas tarjetas,
que sirven para indicar el estado de cada una
de estas.
Kanban
Cada tarjeta esta asociada a una actividad que
debe ser desarrollada durante todo el
proceso, hasta que finalmente llegue a su
finalizacin.
Kanban
Par que sirve?
Balanceo de la capacidad y su demanda.
Limitar el trabajo que se encuentra en proceso,
mejorar el flujo de trabajo y descubrir problemas.
Sirve para controlar el orden de trabajo, coordinar,
sincronizar y descubrir cuellos de botella, con el
objetivo de tomar decisiones.
Auto organizacin de los equipos de trabajo.
Generar cultura organizacional para optimizar los
procesos.
Kanban
Beneficios.
Generar reglas simples para optimizar el trabajo
diario.
Probar nuevas formas de trabajo.
Aumentar la colaboracin entre el equipo de
trabajo.
Mejorar el ritmo de trabajo.
Tener visualizacin del trabajo que realiza cada
personas.
Kanban
Reglas de Kanban.
Mostrar el proceso.
Limitar el trabajo en curso.
Optimizar el flujo de trabajo.
Kanban
Mostrar el proceso.
Visualizacin de todo el proceso de desarrollo a
travs de la utilizacin de un tablero de tarjetas.
Objetivo: entender de mejor manera el proceso
actual.
Kanban
Limitar el trabajo en curso.
Con el fin de evitar la saturacin del proceso y las
personas.
Cuando existe un alto nivel de tareas en proceso, es
necesario tomar decisiones para delegar o solicitar
apoyo de terceros para finalizar una actividad.
Kanban
Optimizar el flujo de trabajo.
Principalmente asociado a la mejora continua
(Kaizen).
En medida que se adopta una cultura
organizacional del funcionamiento de la
metodologa, se generar instancias para mejorar el
proceso de construccin.
Optimizacin estacionaria por cada actividad.
Cul es mejor?
Scrum.
Pila del producto priorizada.
Sprints.
Proyectos grandes con entregas incrementales.
Equipo multidisciplinario.
Kanban.
Tareas no esperadas.
Flujo constante de trabajo.
Funciona bien con equipos especializados o
multidisciplinarios.
Clase 7
UML
Lenguaje unificado de modelo, permite
modelar, construir y documentos los
elementos o requerimientos que forma un
software.
Uno de los objetivos principales de la creacin
de UML era entregar el intercambio de
modelos en distintas herramientas CASE que
eran orientadas al mercado. Para eso se define
una notacin y semntica comn.
UML
Diagrama de
Casos de Uso
Diagrama de
Clases
Diagrama de
Estados
Diagrama de
Objeto
Esttica
Actividad
Diagrama de
Actividad
Diagrama de
Componentes
Diagramas
Interaccin
Diagrama de
Secuencia
Implementacin
Diagrama de
Colaboracin
Diagrama de
Despliegue
Diagramas de Clases
Define la estructura esttica del sistema.
Representa el conjunto de clases, interfaces y
colaboraciones, as como las diferentes
relaciones, abarcando una vista de diseo del
sistema.
Persona
Nombre: String
Estudiante
Promedio: double
Universidad
Estudia en
0..*
Nombre:String
Diagrama de Objetos
Es muy similar al diagrama de clases, pero
representa un conjunto de objetos, sus
relaciones con un estado particular.
Diana: Estudiante
Nombre: Diana Martnez
Promedio: 16,5
Estudia en
UCV: Universidad
Nombre: Univ. Central de Vzla
Diagrama de Componentes
Muestra la organizacin y las dependencias de
un conjunto de componentes software.
Cubren la vista de implementacin de un
sistema y describen la interaccin entre
diferentes componentes de software.
Diagrama de despliegue
Describe la disposicin del hardware.
Representacin grfica del hardware a utilizar
por el sistema, los nodos de proceso y los
componentes fsicos.
Casos de Uso
Describe las principales funcionalidades de un
sistema a partir de las interacciones del
usuario.
Diagrama de Casos de Uso

Describen lo que hace el sistema
completamente, poniendo nfasis en el que
en vez del cmo.
Describen las funcionalidades del sistema a
partir de las interacciones del usuario.
Como debe interactuar el usuario con el sistema o
lo que se espera.
Visualizacin del comportamiento del sistema.
Diagrama de Casos de Uso

Actores.
Puede ser una entidad externa que interacta con
el sistema.
Entidades diferentes a los usuarios del sistema.
En algunas ocasiones, representan cierta funcin
que un usuario va realizar en el sistema
Personas, sistemas, componente de software u
organizacin.
Nombre del Actor
Relaciones entre actores

Generalizacin.
Cuando diferentes actores
realizan tareas o mantienen
roles similares, pueden heredar
de un actor en comn.
Secretaria
Tcnico
Administrador
Actores
Ejemplos
Base de Datos Reservaciones
Sistema de
Reservaciones de
Vuelos
Usuario
Base de Datos de Registros
Sistema de
Computacin
Usuario
Administrador
Programador
Operador
Casos de Uso
Un caso de uso define la funcionalidad de un
sistema.
Casa caso de uso constituye un flujo de
eventos, que derivan en un flujo principal y
uno alternativo.
Cada caso se uso genera un resultado
observable y vlido para el actor involucrado
en la secuencia de acciones.
Son verbos, por lo tanto implican acciones.
Tipos de Relaciones en CU
Generalizacin.
Relacin que define la
especializacin de un caso de uso.
Casos de uso abstractos describen
parte similares y pueden ser
instanciados de manera
independiente.
Los casos de uso concretos
describirn el comportamiento
especifico.
Caso Abstracto
Caso Concreto
Pagar Reservacin
Pagar con Tarjeta
Pagar con
Transferencia
Tipo de Relaciones en CU
Extensin (<<extend>>)
Especifica como un caso de uso
puede estar al interior de otro
para extender la funcionalidad
del caso de uso base.
El caso alternativo es una
extensin del base.
Una instancia del caso base,
puede incluir o no el
comportamiento especificado
por el opcional.
Caso Base
<<extend>>
Caso Opcional
Hacer Reservacin
<<extend>>
Pagar Reservacin
Tipos de Relaciones CU
Include (<<include>>).
Inclusin define que un caso
de uso es parte obligatoria
de un caso base.
El caso base incluye el caso
obligatorio.
Siempre un caso base
incluye el comportamiento
especificado por un caso de
uso obligatorio.
Caso Base
<<include>>
Caso Obligatorio
Consultar
Informacin
<<include>>
Validar Usuario
Ejemplos
Especificacin de Casos de Uso
Nombre del caso de uso.

Actores involucrados (primarios y secundarios).
Propsito del caso de uso.
Precondiciones.
Flujo de Eventos Principal.
Sub Flujos.
Excepciones.
Postcondiciones.
Ejemplo
Diagramas de Clases
El diagrama de clases describe la estructura
esttica del sistema, mostrando las diferentes
clases y las relaciones que existen entre ellas.
Una clase por definicin corresponde a un
objeto con un conjunto de caractersticas y
comportamiento similares.
Nombre Clase
Nombre Atributo: Tipo Atributo
Atributos
Mtodos
Nombre Mtodo (parmetros) : Tipo Retorno
Tipos de Clases
Abstractas.
No maneja instancias directas, pero sus clases
descendientes tienen instancias directas.
Concretas.
Aquellas que pueden ser instancias.
Trabajador
Licenciado
Ingeniero
Obrero
Relaciones entre clases

Conexin semntica entre diferentes
elementos del modelo.
Tipos de relaciones.
Asociacin.
Agregacin.
Composicin.
Generalizacin / Especializacin.
Dependencia.
Tipos de Relaciones
Asociacin.
Relacin significativa entre 2 o ms clases.
Segn notacin de UML, la asociacin comprende
los siguientes aspectos.
Descripcin.
Rol (responsabilidad de la clase en la relacin).
Multiplicidad.
0 o ms *.
1 o ms .*
Etc.
Clase A
<rol A>
<mult A>
<Descripcin>
<rol B>
<mult B>
Clase B
Tipos de Relaciones
Asociacin.
Se determina en funcin del grado de asociacin
que viene dado por el nmero de clases
conectadas entre s.
Ejemplo asociacin ternaria.
Estudiante
Universidad
Profesor
Tipos de Relaciones
Asociacin.
Las asociaciones pueden ser reflexivas, pueden
mantener una relacin con diferentes objetos de
una misma clase.
Persona
pariente de
Tipos de Relaciones
Agregacin.
Es una relacin donde se especifica el es parte
de o contiene.
Especifica una relacin parte de entre el agregado
y el componente parte.
Universidad
Estudiante
*
Tipos de Relaciones.
Composicin.
Viene de la definicin compuesto por
Relacin de agregado especial donde las partes no
pueden existir sin que exista el objeto todo.
Cuerpo
Brazo
2
Tipos de Relaciones
Generalizacin / Especializacin.
Generalizacin: Se construye una sper clase, que
generaliza propiedades o atributos entre
diferentes clases.
Especializacin: En funcin de una clase particular,
se crean otras clases o subclases que especializan
la clase dada, agregando diferencias.
Persona
Estudiante
Profesor
Empleado
Tipos de Relaciones
Dependencia.
Corresponde a una conexin entre diferentes
clases que implica que un cambio en la clase B,
puede afectar a una clase A que la utiliza.
Clase_A
Clase_B
Atributo1:int
Metodo (b: Clase_B)
Diagrama de Actividades
Definen la lgica de los procedimientos,
procesos del negocio y flujos de trabajo del
sistema.
En particular un diagrama de actividades
demuestra una serie de actividades que deben
ser realizadas en un caso de uso, as como los
diferentes
caminos
que
pueden
ir
desencadenando el caso de uso.
Diagrama de Actividades.
Elementos.
Actividad representa una
accin que ser realiza por el
sistema.
Actividad inicial.
Actividad final.
SubActividad
Nombre de la Actividad
Actividad Compuesta
Actividad 1
Actividad 2
Ramificacin.
Surgen cuando existe la posibilidad de que un
flujo pueda tomar ms de un camino.
Se representa a travs de un rombo.
Validar Usuario
[Usuario Vlido]
Ver Informacin
[Usuario Invlido]
Mostrar Mensaje de Usuario Invlido
Join.
Divisin.
Unin.
Seales.
Seales de tiempo.
Envo de seal.
Recepcin de seal.
Reservar Solicitud
Enviar Solicitud
Esperar 30 seg
Cancelar Registro
Solicitud
Aceptada
Guardar Solicitud
Diagramas de Secuencia
Diagrama principalmente utilizado para
modelar la interaccin entre distintos objetos
en un software.
Su principal propsito es poner nfasis en el
orden y el momento en que se envan los
mensajes a travs de los distintos objetos.
Mostrar la secuencia del comportamiento del
caso de uso.
Diagrama de Secuencias
Material de Apoyo
Como escribir buenos casos de uso (IBM).
Ingeniera del Software 7ma Ed.

Procesos de Negocio: Clase 1 Manuel Torres Pereira

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Procesos de Negocio: Clase 1 Manuel Torres Pereira

Загружено:

Авторское право:

Доступные форматы

Procesos de Negocio

Pueden ser parte de otro proceso (Sub

La mayora estn enfocados a la funcin de

Hoy en da existen sistemas multi-funcionales.

Procesos de Negocio Multi-funcional

BPM (Business Process Management)

Centro de Excelencia (BPM-CoE)

Ms que modelar y documentar procedimientos.

Modelacin de Procesos de Negocio

Para que sirven?

Comprender funcionamiento actual.

Entendible para distintas audiencias.

BPMN (Business Process Model and

Elementos de un Proceso de Negocio

Pueden ser de diferentes tipos.

Salidas del proceso:

Ejemplos de entidad y actividades

Por cada actividad se agrega un grado de cumplimiento a la

En funcin del contexto, las personas, sistemas o

Ocasionalmente se deben considerar ambos tipos de clientes.

Proceso de pago de un cheque.

Proceso de reclutamiento de personal.

Quien genera un elemento de una actividad para la ejecucin

Proceso de pago de cheque.

Proceso de reclutamiento de personal.

Lo primero: escoger un nombre

Que se buen nombre

Que defina un alcance que entregue valor al

Que sea independiente de los recursos utilizados.

Es importante definir el alcance del trabajo

Ejemplo Reparar auto

SIPOC (Supplier Input Process

Quines interactan con el proceso?

Cules son los elementos que fluyen desde y hacia el

SIPOC es una metodologa til para definir estas

SIPOC Ejemplo: Reparar un auto

SIPOC Ejemplo: Reparar un auto

Hay problemas de gobernabilidad sobre el proceso.

No hay claridad sobre quin debe saber qu o aportar

RECI es una metodologa til para definir estas

Los dems asociados a RECI pueden repetirse o no

Presentar la solucin propuesta en grupos.

Modelo de Madurez de Procesos

El objetivo principal de desarrollar el MMPE fue

Lo modelos de madurez son:

Existen varios modelos de madurez para las

Modelo de Madurez de Procesos y

Un modelo de madurez de capacidades de empresa.

Elementos del modelo de madurez

Madurez de procesos en Chile

Nivel de madurez de facilitadores

Un proceso se encuentra en un cierto nivel de madurez

Evaluacin del nivel de madurez

Evaluacin del nivel de madurez

Evaluacin del nivel de madurez

Evaluacin del nivel de madurez

Evaluacin del nivel de madurez

Definicin de los niveles

P1: Definicin de actividades.

P2: Definicin del proceso Integracin intra-proceso.

P3: Integracin inter-procesos, intra-empresas.

P4: Integracin inter-procesos, inter empresas.

Garantiza llegar al nivel Y un mejor