Embed Size (px)
Citation preview
Rational Agile Day
Caso de éxito
Agenda
15:00 a 15:15 Apertura - Presentación de los ponentes, contexto de desarrollo ágil Ariel Súcari, Director de Operaciones ItEra 15:15 a 16:00 Metodologías de desarrollo Amaury Quintero, Arquitecto de soluciones para desarrollo ágil
16:00 a 16:30 Cofee Break 16:30 a 17:30 Rational Team Concert – Presentación y DEMO José M. Ordax, RTC Technical Specialist, IBM 17:30 a 18:00 Caso de éxito – Tracsa Caterpillar José Manuel Acosta, Consultor en TRACSA
Agenda
15:00 a 15:15 Apertura - Presentación de los ponentes, contexto de desarrollo ágil Ariel Súcari, Director de Operaciones ItEra 15:15 a 16:00 Metodologías de desarrollo Amaury Quintero, Arquitecto de soluciones para desarrollo ágil
16:00 a 16:30 Cofee Break 16:30 a 17:30 Rational Team Concert – Presentación y DEMO José M. Ordax, RTC Technical Specialist, IBM 17:30 a 18:00 Caso de éxito – Tracsa Caterpillar José Manuel Acosta, Consultor en TRACSA
Flexibilidad de Negocio y Gobierno es lo de Hoy
Los clientes y ciudadanos exigen:
Mayor calidad
Mayor seguridad de su información
Precios más bajos
Eficiencia en los servicios
Mayor rapidez
Mayor calidez
Mayor valor añadido
Mayor agilidad en los servicios
El entorno está:
Globalizado
Más participativo
e - gobierno
Conectado
Rendición de Cuentas
Un solo punto de contacto
Legislación más estricta
La competencia y transparencia es:
Mayor
Más agresiva en la oferta
Cada vez más preparada
Innovadora
Las necesidades del ejecutivo de negocio
y funcionarios públicos son…
… son los retos del ejecutivo de TI
Proporcionar rumbo y certeza
Incrementar ganancias o servicios mientras se reducen los costes.
Agilidad de respuesta a los cambios para concretar nuevas oportunidades de servicios
Mejorar la capacidad y habilidades de la organización para sustentar el crecimiento, efectividad y cambio
Alinear TI a las metas del negocio para incrementar ganancias o servicios y contener costes
Facilitar la agilidad de la organización mediante servicios de TI
Hacer más efectiva a la gente y a los equipos mediante TI
¿A qué nos dedicamos? Factores para Elevar la Calidad
Personas
Mejora Iterativa de Procesos
Tecnología Procesos
Todos reconocemos la importancia de tener un equipo de trabajo de calidad, motivado pero ….
BPM
SCRUM
Es importante integrar todas las iniciativas de mejora en un programa integral
Muchas organizaciones concentran sus esfuerzos en arreglar los errores en vez de prevenirlos
Soluciones con IBM Rational
Ciclos de vida de desarrollo: • Definición de procesos ágiles • Automatización de procesos con
Rational Team Concert • Formación en procesos y herramientas • Especialistas en: Rational ClearCase,
ClearQuest, Doors, Quality Manager, Software Architect, RAD i y z Series.
• Websphere Portal y HATS
Desarrollo seguro de aplicaciones: • Análisis de riesgos y vulnerabilidades • Auditorías de código seguro • Adaptación de procesos • Tablero de control de vulnerabilidades • Implantación de Rational Appscan
Soluciones de productividad, calidad visibilidad
Oficinas de proyectos y/o calidad: • Definición • Implantación • Automatización • Ejecución
Implantación CMMI v1.3: • Desarrollo, Adquisiciones y
Servicios • Implantación • Automatización • Evaluación (SCAMPI) • Formación
Soluciones de formación
Cursos Presenciales: • PMP, RMP • CMMI V1.3 • CEH V7, CHFI, ECSP • Lead Auditor ISO 27001, 20000 • ITIL & ITIL Expert • Cobit • TOGAF • CBCI • SCRUM Cursos LIVE ONLINE: • ITIL Foundation, Expert • ISO 27002
Algunos clientes
Introducción
http://www.implementingscrum.com/translations/
Varias compañías están utilizando Ágil.
Por qué?
Acaso la inversión paga la
transición?
Están evaluados los riesgos?
Introducción
“El 80% del negocio de IBM proviene de clientes existentes/retornados”
Problemas de calidad
Entrega tardía
Situaciones críticas
Solución: Ágil?
Canada
Toronto,Ottawa
Montreal, Victoria
Edinburgh
London / Staines
Milton Keynes
Haifa Rehovot
China
Beijing
Shanghai Yamato
Taiwan
Paris Pornichet
Beaverton
Kirkland
Seattle
Foster City
San Francisco
SVL/San Jose
Almaden
Agoura Hills
Irving
El Segundo
Costa Mesa
Las Vegas
Andover Bedford, MA Bedford, NH Lexington
Westborough Westford
Cambridge
Cork
Dublin
Galway
India
Bangalore
Pune
Hyderabad
Gurgaon
Cairo
Rome
Gold Coast
Sydney
Canberra
Fairfax
Raleigh
Charlotte
Lexington, KY
Atlanta
Boca Raton
Tampa
Perth
Krakow
Warsaw
Sao Paulo
Malaysia
Delft Stockholm
Pittsburgh
Poughkeepsie
Somers
Rochester, MN
Boulder
Denver
Lenexa, KA
Tucson
Phoenix
Austin
Dallas
Boeblingen
Hursley
Warwick
York
Southbury
New York City
Princeton
US
Canada
Latin America
EMEA
AP
Total
11,000
3,500
100
3,900
6,600
25,100
Equipo de desarrollo de IBM
Debemos demostrar beneficios económicos:
Productividad
Calidad de la oferta
Satisfación
Coste de desarrollo
Valor al negocio
¿Cómo evaluarlo?
Datamatrix, o codificación de datos 2D, es un nuevo sistema industrial de codificación bidimensional que permite la generación de un gran volumen de información en un formato muy reducido, con una alta fiabilidad de lectura gracias a sus sistemas de información redundante y corrección de errores (legible hasta con un 20%-30% dañado). Además no es necesario un alto contraste para reconocer el código. El código está formado por celdas de color blanco y negro (perforadas o no perforadas en el caso de la micropercusión) que forman una figura cuadrada o rectangular. Cada una de esas celdas representa un bit de información. La información puede estar codificada como texto o datos en bruto (raw data en inglés).
Agenda
15:00 a 15:15 Apertura - Presentación de los ponentes, contexto de desarrollo ágil Ariel Súcari, Director de Operaciones ItEra 15:15 a 16:00 Metodologías de desarrollo Amaury Quintero, Arquitecto de soluciones para desarrollo ágil
16:00 a 16:30 Cofee Break 16:30 a 17:30 Rational Team Concert – Presentación y DEMO José M. Ordax, RTC Technical Specialist, IBM 17:30 a 18:00 Caso de éxito – Tracsa Caterpillar José Manuel Acosta, Consultor en TRACSA
Métodologías de Desarrollo Ágiles
¿Qué, cómo, cuándo y dónde?
Preparado por: Amaury Quintero
Agenda
• ¿Qué es Desarrollo Ágil?
• Retos del Desarrollo Ágil
• Mejorando Ágil
• ¿Podemos utilizar RUP en Ágil?
• Tomando lo necesario
• Conclusiones
Un Proceso Malo es un Proceso Malo sin importar la
metodología que uses
¿Qué es Desarrollo Ágil?
• Un enfoque iterativo e incremental (evolucionario) ejecutado en un ambiente altamente colaborativo con solamente la justa cantidad de ceremonia para producir software de alta calidad de una manera efectiva y con costos adecuados, que satisface los requisitos cambiantes del cliente.
• Principios Básicos
– Sólo use el proceso necesario
– Pruebas y validaciones continuas
– Colaboración consistente entre el equipo
– Rápida respuesta a cambios
– Participación del cliente
– Entrega frecuente de software
http://www.agilemanifesto.org/
Planificación Tradicional vs. Ágil
La Planificación Tradicional hístóricamente define el alcance para todo el sistema
Crea el plan, ejecuta el plan
El plan se basa en tareas arquitectónicas y detalle de como construir cada componente
Es una metodología predictiva
Ágil enfatiza entregar el mayor valor posible al negocio
Trabaja en las tareas de mayor valor primero
No planifica el sistema completo, usa iteraciones (2 semanas – 1 mes)
Planifica y prioriza basado en “User Stories”
Introducción Visual a Scrum
Release burndown
Sprint backlog
Task Board
Sprint Planning (Sprint goals) Sprint Review & Sprint Restrospective
Métricas Ágiles Comunes
Nuestra Historia…
• Iniciamos con un pequeño grupo
• Puesta en Producción
• El equipo creció a 70, mas desarrollo externo
• Nuestro producto comenzó a brindar servicios compartidos a toda la organización
…un poco mas de Historia
• Empezamos a depender de otros servicios empresariales para nuestro producto
• Nuestro producto se convirtió en un producto de productos
Queremos seguir teniendo el valor de lo ágil…
…pero no encajamos en el perfil ágil
Ágil sólo ofrece Cobertura Parcial
Mike Griffiths, Leading Answers http://www.leadinganswers.com
Retos del Desarrollo Ágil
Desarrollo Ágil
Mismo sitio
Distribución Geográfica
Global
Cumplimiento de Estándares
Bajo riesgo
Crítico, Auditado
Complejidad Técnica
Simple, única plataforma
Compleja, multi-plataforma
Contratación distribución (outsourcing, convenios)
Tamaño del Equipo
<10 100+
Grado de Gobierno
En casa Terceros
Informal Formal
Complejidad de procesos, políticas, gente
Mínima Significante
RUP - “Agility@Scale”
Scrum no es suficiente
• Caso de Negocio
• Visión
• Backlog (¿De donde viene?)
• Arquitectura
• Documentación
• Planes de Despliegue y Roadmaps
¿Cómo hacemos que esto funcione?
• Tome lo que es bueno de ágil, lo que escala y lo que lo estimula
• Reemplace lo que no le alcance con ciertos componentes de RUP
• Mantenga las cosas lo mas simple posibles
RUP: Procesos Predefinidos
• RUP for Service-Oriented Modeling and Architecture
• RUP for Maintenance Projects
• RUP for COTS Package Delivery
• RUP for System z
• RUP for Small Projects
• RUP for Medium Projects
• RUP for Large Projects
• RUP for Systems Engineering
• RUP for Compliance Management
• RUP for Asset-Based Development
• RUP for Globally Distributed Development (beta)
Mitos comunes sobre RUP
• RUP es muy grande
• RUP se enfoca demasiado a documentos
• RUP no es configurable
La gente de la comunidad Ágil realmente ODIA en Proceso Unificado de Rational
Las Verdades
• RUP está diseñado para ser configurable
• En la práctica la gente lo ejecuta muy pobremente
• Lo aplican como un proceso en cascada
• Puede ser tan ágil como se quiera si se le da el enfoque adecuado
Scrum pero introduzca Manejo de Riesgos
• Desviandonos un poco de lo ágil introducimos la Administración de Riesgos
• Necesitamos saber como mitigar los riesgos
Mitigando los Riesgos
• Cuando escalamos el equipo, necesitamos tener un poco mas de formalidad
• Mas control intelectual sobre la arquitectura
• Mas control intelectual sobre los requisitos
Método de Soluciones Ágiles basadas en RUP (Agility@Scale)
Basada en las prácticas de IBM Rational Method Composer para escalar el Desarrollo Ágil
Una combinación de Ágil y RUP
Mayor reutilización de estándares
Durante el ciclo de vida, mantiene foco en el par “Riesgo”/”Valor para el Cliente”
Arquitectura – Las Grandes Ideas
• La Arquitectura debe ser una parte importante de un desarrollo ágil disciplinado
• Establecer algún tipo de visión de la arquitectura al principio
• La arquitectura se deberá probar con código ejecutable
• Esta arquitectura va evolucionar a lo largo del proyecto ágil
• No haga demasiada arquitectura al principio
• Lo arquitectos trabajan muy cerca de los desarrolladores
• Un enfoque ágil para la arquitectura es crítico para tener exito con los factores de Agility@Scale
• Modelado y documentación no deben dejarse a un lado, sin perder foco en los ejecutables
• Hay dos apectos arquitectónicos, Negocios y Técnico.
• Estos dos aspectos vienen del equipo no sólo de los arquitectos
Complejidad del Dominio
Sencillo Intrincado, emergente
Cumplimiento de Estándares
Bajo riesgo Críticos, auditados
Tamaño del Equipo
Menos de 10 1000+
Mismo sitio
Distribución Geográfica
Global
Disciplina Empresarial
Foco en Proyecto
Foco en Empresa
Complejidad Técnica
Homogénea Heterogénea,
legada
Organización (outsourcing, convenios)
Colaborativo Contractual
Agility@Scale (factores)
Disciplined Agile
Delivery
Flexible Rígida
Complejidad de la Organización
Método de Soluciones Ágiles basadas en RUP
Incrementar el rigor del control de cambios a medida que el proyecto progresa
Métricas
Cosas que debo mantener de Ágil
• Pequeños equipos, equipos de equipos si es necesario
• Ciclos cortos de planificación
• Visibilidad, inspección, adaptación
• Reuniones Retrospectivas
• Comunicación cara a cara con el cliente
• Elaboración progresiva de la planificación
• Historias de Usuario pequeñas e independientes
• Autonomía y auto-organización
• Propiedad y responsabilidad
Cosas que debo eliminar de Ágil
• Excesiva carencia de documentación
• La no planificación
• Arquitectura Emergente
• Propiedad compartida y universal del código
¿Qué debo modificar de Ágil?
El cliclo de vida Ágil
Cosas que debo mantener de RUP
• El Espíritu de RUP
• Fases
• Iteraciones
• Casos de Uso
• Arquitectura Deliberada
• Algunos artefactos
¿Qué debo fusionar de RUP y Ágil?
El ciclo de vida de entrega Ágil disciplinado
(DAD)
Qué debo eliminar de RUP
• Definición de roles exhaustiva
• Guía del proceso, a menos que algo de valor en su contexto
• La mayoría de los artefactos
Manifiesto Ágil – Valores
Individuos e
interacciones
Procesos y
herramientas
Software
funcionando
Documentación
exhaustiva
Colaboración
con el cliente
Negociación de
un contrato
Respuesta a
cambios
Seguimiento a un plan
"Agile"
|
|
|
|
|
|
|
|
Tradicional
La Agilidad es un término relativo
RUP - Valores
• El “Espíritu” de RUP – Linea Base
Arquitectura
– Uso de Componentes
– Trabajo en Equipo
– Calidad, una forma de vida
• Fases
• Iterationes
• Casos de Uso
• Arquitectura
• Algunos otros artefactos
F
E
D
C
B
A Adaptar el proceso
Balancear prioridades de los involucrados
Colaborar entre equipos
Demostrar Valor iterativamente
Elevar el nivel de abstracción
Foco continuo en la calidad
Recomendaciones
Proceso Adaptable
• Requisitos inciertos o volatiles
• Desarrolladores responsables y motivados
• Clientes que entienden y se involucran
• Fase de Ingeniería del Proyecto
Proceso Predictivo
• Un equipo de mas de 100
• Un precio fijo, o mas concretamente un alcance o contrato fijo
• Fase de Producción del proyecto
•No se preocupes si ud. Tiene un equipo ágil, pequeño y ubicado en el mismo sitio •Sea pragmático acerca de la modificación del proceso y adopte elementos que hagan sentido para el tamaño y la complejidad de su organización
Haga lo mas simple posible
La motivación de los desarrolladores es lo que más influye en la productividad
Conclusión
Algunas Estadísticas de la Industria
• Adopción: – 76% de las organizaciones han
adoptado técnicas ágiles
– 44% de los proyectos, en promedio, dentro de las organizaciones han adoptado ágil
– Fuente: DDJ Julio 2009 State of IT Union survey
• Efectividad: – Promedio de éxito ágil: 70%
– Promedio de éxito tradicional: 66%
– Los proyectos ágiles e iterativos han batido a los tradicionales en cuestiones de calidad entregada, habilidad de entregar funcionalidad necesaria, retorno de inversión, y time to value
– Fuente: DDJ 2008 Project Success Survey
0.8
0.8
2.7
0.4
0.8
0.2
1.8
2.3
4.0
3.0
5.6
5.0
4.4
3.9
6.0
4.9
Tiempo
Dinero
Funcionalidad
Calidad
Ágil
Iterativo
Tradicional
Ad-Hoc
Encuesta disponible en www.ambysoft.com/surveys/
60
48%
55%
55%
59%
65%
69%
73%
74%
72%
73%
79%
80%
62%
66%
70%
71%
Ad Hoc
Tradicional
Ágil
Iterativo
Promedio
Mismo Sitio
Cercanos
Lejanos
Porcentaje de Exito: Desarrollo Distribuido
Fuente: Dr Dobb’s Project Success Survey
Gracias!!!
Amaury Quintero Arquitecto de soluciones para desarrollo ágil
Agenda
15:00 a 15:15 Apertura - Presentación de los ponentes, contexto de desarrollo ágil Ariel Súcari, Director de Operaciones ItEra 15:15 a 16:00 Metodologías de desarrollo Amaury Quintero, Arquitecto de soluciones para desarrollo ágil
16:00 a 16:30 Cofee Break 16:30 a 17:30 Rational Team Concert – Presentación y DEMO José M. Ordax, RTC Technical Specialist, IBM 17:30 a 18:00 Caso de éxito – Tracsa Caterpillar José Manuel Acosta, Consultor en TRACSA
Agenda
15:00 a 15:15 Apertura - Presentación de los ponentes, contexto de desarrollo ágil Ariel Súcari, Director de Operaciones ItEra 15:15 a 16:00 Metodologías de desarrollo Amaury Quintero, Arquitecto de soluciones para desarrollo ágil
16:00 a 16:30 Cofee Break 16:30 a 17:30 Rational Team Concert – Presentación y DEMO José M. Ordax, RTC Technical Specialist, IBM 17:30 a 18:00 Caso de éxito – Tracsa Caterpillar José Manuel Acosta, Consultor en TRACSA
Proyecto: Desarrollo Ágil con Soluciones
Rational
Agenda
Antecedentes.
Objetivos
Elementos del Proceso.
TRACSA UNIFIED PROCESS.
Arquitectura Conceptual.
Conclusiones
Servicios Soluciones Integrales
TRACSA fue fundada en Agosto de 1974 mediante la adquisición de los activos del distribuidor anterior , Agro-mecánica S.A., en aquel tiempo solo contaba con sucursales en Guadalajara, Celaya, Colima y Lázaro Cárdenas, dando servicio a los segmentos de construcción, agrícola y minero principalmente y ofreciendo soluciones de venta, renta de maquinaria nueva y seminueva, refacciones y servicio, principalmente de la marca Caterpillar.
http://www.tracsa.com.mx/
Antecedentes
TRACSA decide el cambiar su ERP actual “Core” puesto que ya no cubre las necesidades actuales del negocio. Por parte de la Dirección de TI se toma la decisión estratégica de para desarrollar un nuevo ERP el cual tiene como alcance: Implantar una nueva metodología de trabajo ágil. Implantar herramientas que ayuden a soportar el modelo ágil para desarrollo y mantenimiento. Seguir las mejores prácticas en procesos y herramientas en base a estándares y modelo de automatización.
Se diseña un plan de mejora para dar solución a esas necesidades con la plataforma mas robusta para desarrollo en ambiente colaborativo (IBM Rational), con las mejores prácticas de los marcos de referencia de mayor presencia en la actualidad y la experiencia de It Era en la mejora de procesos y automatización.
Agenda
Antecedentes.
Objetivos
Elementos del Proceso.
TRACSA UNIFIED PROCESS.
Arquitectura Conceptual.
Conclusiones
GESTION DEL CICLO DE VIDA DEL PRODUCTO
Definición, Implementación y Automatización de Procesos con base a Estándares y Mejores Prácticas
Agilidad
Procesos Operativos
Calidad
Evaluación Continua
Trazabilidad
Control y seguimiento
Visibilidad
Reportes y Métricas
Integración
Trabajo en
Equipo
Objetivos
Agenda
Antecedentes.
Objetivos
Elementos del Proceso.
TRACSA UNIFIED PROCESS.
Arquitectura Conceptual.
Conclusiones
Preparado por: Itera
Elementos del Proceso
Se toma como marcos de referencia las mejores prácticas: Las disciplinas del RUP, Metodologías OpenUP y Scrum
Agenda
Antecedentes.
Objetivos
Elementos del Proceso.
TRACSA UNIFIED PROCESS.
Arquitectura Conceptual.
Conclusiones
TRACSA UNIFIED PROCESS (TUP)
RSA
Software Arquitect for WebSphere
RQM
Quality
Management
Application Lifecycle Management
TUP
Solicitudes
Dirección
Desarrollo Calidad de Software
Despliegue Requerimientos Arquitectura Operación
RTCp
Team Concert for p
Medición y Análisis
Control
RMC
Method Composer
Ente
ndim
iento
de
la N
ecesid
ad d
el
Negocio
Comité de Cambios y Requerimientos
RRC Requirements
Composer
TUP -Procesos de Modelado de Negocios y Requerimientos
Procesos de Negocio
Casos de Uso Texto
enriquecido
Objetivos de Negocio
Procesos de Negocios
Casos de Uso
Prototipos
Infraestructura Colaborativa
Obtener, capturar, elaborar, revisar y discutir los
requerimientos.
Requerimientos con texto enriquecido
TUP - Áreas de trabajo de Requirements Composer
Diagramas de Flujo
Rich Authoring Environment Web Review and Approval
Glosario
Casos de Uso
Requirementos con texto enriquecido
Interfaz con estilos WIKI. Categorias / Etiquetas. Comentarios. Revisión / Aprobación.
Server Colaborativo
Compartir trabajo al instante . Usuarios / equipos / autorizaciones. Vínculos entre todos los artefactos. Control de versiones.
TUP - Áreas de trabajo de Team Concert
Uso de Dashboards para la Gestión del Proyecto.
Espacio de Trabajo Integrado y colaborativo.
TUP - Áreas de trabajo de Quality Manager
Uso de Dashboards para la gestión de la calidad.
Manejo de Planes, Casos, Guiones y Resultados de Prueba.
Vinculación con los Requerimientos establecidos.
TUP -Procesos de Modelado de Negocio
Usuarios de Negocio
Ing. de
Procesos
• Define las actividades de
su Procesos.
• Define las Reglas de Negocio.
• Dicta Necesidades mismas que serán atendidas en la etapa de requerimientos.
• Entrega documentación de Soporte.
• Facilita Entrevistas para las diferentes iteraciones del proyecto.
• Acepta entregables.
• Entiende el trabajo a
realizar. • Realiza el trabajo conforme
lo explicado. • Generar y Ajustar los
productos comprometidos.
• Utilizar los manuales de
procedimiento como entrada.
• Asistencias a reuniones
Comité de Procesos Consultores
• Entiende los objetivos. • Transfiere el conocimiento
de cómo debe realizarse el trabajo.
• Colaborar en la definición de los trabajos a realizar.
• Asesora en el trabajo y productos generados.
• Apoyar en el monitoreo y
control del avance del los entregables
.
• Unifica los
criterios
TUP - Requerimientos Ingeniero de Requerimientos
(IR) Revisor Interno
(RI) Usuario de Negocio
(UN)
El Ingeniero de Requerimientos se presenta e informa las actividades a Realizar
El IR presenta al UN los Casos de Uso de Sistema (Inventario de Casos de Uso de Sistema) identificados a partir del documento del Modelado de Negocio
El IR lleva a cabo el proceso de Obtención de Requerimientos con el UN
El UN dicta los Requerimientos Funcionales y No Funcionales de manera clara al IR
El IR Recolecta y administra requerimientos funcionales y no funcionales del sistema.
Documenta con base en las técnicas para obtención de requerimientos: • Especificación de Casos de Uso. • Especificaciones Suplementarias. • Complementar el documento de Reglas de Negocio. El IR deberá subir los productos generados al Repositorio
EL RI descargará del Repositorio los productos generados por el IR para colaborar en la revisión.
Verifica y valida los productos generados, de acuerdo a la técnica empleada.
Asesora al IR en el trabajo y productos generados.
TUP - Requerimientos Ingeniero de Requerimientos
(IR) Revisor Interno
(RI) Usuario de Negocio
(UN)
Realiza modificaciones a los productos generados.
Si el RI identifica inconsistencias en los productos generados por el IR, se le notificarán estas observaciones para su corrección
El IR realiza la impresión de los productos generados
Sólo se validará una vez los productos generados por el IR
Una vez actualizados los productos generados el IR deberá subirlos al Repositorio como una nueva Versión.
El IR revisa los productos generados con el UN
El UN verifica y valida los productos generados.
Si el UN identifica inconsistencias en los productos generados por el IR, se le notificarán estas observaciones para su corrección.
Realiza modificaciones a los productos generados y los sube al Repositorio como una nueva versión .
El IR realiza la impresión de los productos generados
Dará el Vo.Bo. los productos generados.
TUP – Aseguramiento de Calidad Ingeniero de Pruebas (IP) Desarrolladores
(DEV) Usuario de Negocio
(UN)
Con base a las Especificaciones de Modelado y Requerimientos el Ingeniero de Pruebas analizará y diseñará Pruebas.
Si el IP o el UN identifica inconsistencias en los productos generados por el DEV, se le notificarán estas observaciones para su corrección.
Se ejecutaran pruebas funcionales y de sistema previas a las pruebas de Usuario.
El IP Programará las etapas de pruebas con el UN para revisar los productos generados
Si el UN identifica inconsistencias en los productos generados por el IR, se le notificarán estas observaciones para su corrección.
Dará seguimiento a las Incidencias Reportadas por el UN hasta su corrección y programará la sesión de pruebas.
Dará el Vo.Bo. los productos generados.
El UN verifica y valida los productos generados.
El DEV realizará la corrección de las incidencias Reportadas y Entregara los productos corregidos para su Revisión
Agenda
Antecedentes.
Objetivos
Elementos del Proceso.
TRACSA UNIFIED PROCESS.
Arquitectura Conceptual.
Conclusiones
Arquitectura Conceptual
IBM i OS on the Power Systems platform -DB2 for p -WAS for p
IBM
Windows Server
Nuevo ERP
Agenda
Antecedentes.
Objetivos
Elementos del Proceso.
TRACSA UNIFIED PROCESS.
Arquitectura Conceptual.
Conclusiones
Conclusiones - Resultados
Para el primer modulo de “Maquinaría” se logró especificar los requerimientos de negocio y funcionales en los tiempos establecidos logrando agilizar la participación de los usuarios en la acreditación de los mismos.
Se ha logrado una dinámica de colaboración y trabajo en equipo que esta permitiendo cumplir en los tiempos establecidos para cada iteración en la implementación
Mediante la integración de la plataforma de herramientas se están generando los elementos de trazabilidad que permiten identificar las dependencias entre los componentes del sistema, mismas que facilitaran en un futuro las estimaciones de impacto a los cambios y nuevos desarrollos.
La Gestión de Calidad, está logrando garantizar el cumplimiento de los requerimientos solicitados por el usuario y el entregar compontes libres de defectos.
Conclusiones - Beneficios
Se logró fortalecer la forma de trabajo del área para Desarrollo de Nuevas Aplicaciones, con la adopción de prácticas que les han permitido estandarizar su proceso de desarrollo de forma rápida.
Con la documentación del conocimiento y las lecciones aprendidas disponen de herramientas que en corto y mediano plazo les dan una base de conocimiento y activos reutilizables que les permitirá reducir tiempos y costos en los futuros desarrollos y mantenimientos de sus aplicativos.
Gracias!!!
José Manuel Acosta Consultor en Tracsa - Caterpillar
Credits
Ariel Sucari Amaury Quintero Jose M Ordax José Manuel Acosta Dudas, consultas, sugerencias: [email protected] Rational Team Concert: http://www-01.ibm.com/software/rational/products/rtc/index.html
