Product Engineering
Problema: “La gerencia del proyecto debe conocer en detalle el proceso de construcción de software para asegurar que nada se deje al azar, para generar la estrategia de desarrollo adecuada y para la toma de decisiones”.
“El no conocer el cómo se hacen los productos de software crea una brecha mutua entre proveedor y cliente y entre gerente del proyecto y el equipo”.
“Es responsabilidad de la gerencia el facilitar y abstraer al cliente y al equipo del proyecto de los detalles de la metodología.”
Solución Propuesta: El Proceso Unificado de Desarrollo, originalmente un enfoque metodológico integral para desarrollar cualquier producto de software (1998) y finalmente un producto de IBM (desde 2002) es la base de diferentes especializaciones como SUN TONE, EUP, Métrica 3, IBM BUP, etc.
Fortalezas:
Puede ser adaptado a cualquier tipo de desarrollo de software
No deja nada al azar (9 disciplinas estructuradas)
Hace énfasis en continuamente administrar y controlar los riesgos del proyecto
Fuerte base conceptual (UML).
Orientado a generar resultados de calidad y ágiles para el cliente.
Promueve las entregas cortas y ágiles por medio del concepto de desarrollo iterativo, incremental basado en ejecutables.
Implícitamente incluye las dos técnicas más exitosas de optimización de tiempos ( Fast-tracking (trabajo progresivo con entregas cortas sucesivas) y Crashing (trabajo en paralelo) ).
Product Engineering
Debilidades:
No existe documentación clara de cómo adoptar el RUP en un proyecto o compañía.
Requiere experiencia y conocimiento para usarlo correctamente.
Sobrecarga y crea dependencia del rol de Arquitecto.
El trabajo de cada disciplina se centra en los casos de uso, esta dependencia minimiza la oportunidad de optimizar el trabajo en paralelo.
El modelamiento por casos de uso no es la alternativa recomendable para proyectos técnicamente complejos y con baja interacción funcional.
No es fuerte en administración cuantificada de los procesos.
No presenta una solución directa al factor humano como origen de los problemas en proyectos de software.
Product Engineering
Oportunidades:
Se basa y complementa muy bien con PMI.
Utilizarlo en conjunto con metodologías que definan la administración cuantificada de procesos de software (PSP/TSP).
De la experiencia práctica se pueden identificar soluciones a cada una de sus debilidades y amenazas.
Se complementa con las técnicas de desarrollo ágil.
Amenazas: Su dificultad para ser usado y
entendido en la práctica ha generado muchas malinterpretaciones (incluso por “expertos”).
El hecho de que se halla convertido en producto comercial minimiza su difusión e interpretación metodológica y agrega un factor de costo a su adopción.
Product Engineering
Product Engineering
Product Engineering
1. Disciplinas Funcionales:
Business Modeling
Requirements Engineering
Product Engineering
2. Disciplinas Técnicas:
Analisis & Design Implementation Testing Deployment
Product Engineering
3. Disciplinas Administrativas:
Project Management
Configuration & Change Mgmt
Environment Mgmt
• Las Fases son etapas de tiempo con objetivos claramente definidos:
1. Incepción: Análisis del negocio/problema, Planeación del proyecto y gestión de requerimientos.
2. Elaboración: Definir y evaluar la arquitectura de referencia, Madurar y detallar los requerimientos como casos de uso. Minimizar los riesgos del proyecto (aprox. 70%).
3. Construcción: Generar una versión completamente funcional y estable del sistema (alfa).
4. Transición: Gestiona la adopción del software en la compañía mediante ciclos de pruebas (beta y aceptación), documentación y capacitación acerca del producto (técnica, administrativa y funcional) y finalmente su paso a estado productivo.
• Las fases ayudan a gestionar el alcance ya que implican que se cierren formalmente etapas en la vida del proyecto.
Product Engineering
En el tiempo el proyecto se divide en fases con objetivos definidos:
Incepción (aprox. 5 – 20% total). Planeación detallada del proyecto. Conocimiento del negocio Especificación funcional y técnica
Elaboración (aprox. 15 – 30% total). Definir la arquitectura de referencia. Implementar Pruebas de Concepto (Verificación Arquitectura) Diseño detallado Definir estrategia de implementación Implementar módulos utilitarios (seguridad, auditoria, pantalla principal)
Construcción (aprox. 30 – 50% total). Desarrollo de los módulos del sistema, distribuidos según prioridad, complejidad y dependencias.
Transición (aprox. 15 - 30% total). Estabilización y Entrega del sistema. Pruebas funcionales Pruebas técnicas (carga, estrés, volumen, seguridad, concurrencia, etc.) Pruebas de aceptación de los usuarios finales
Pruebas de instalación Piloto en Producción
Documentación manuales Capacitación Usuarios Entrega a producción (cierre contractual del proyecto)
Cada fase consta de iteraciones de su mismo tipo (p.e. IC1, IC2, IC3, corresponden a iteraciones de la fase de construcción).
Product Engineering
Product Engineering
Elaboración: Regla del 70%
Identificar, priorizar, formalizar el cierre de los casos de uso del sistema con el cliente al finalizar la fase de elaboración.
Realizar las pruebas de concepto que permitan verificar la plataforma tecnológica y arquitectura de la solución. Formalizar y cerrar con el cliente la arquitectura de la solución al finalizar la fase de elaboración.
Iniciar el desarrollo del sistema con los casos de uso más complejos y prioritarios lo más temprano posible en el proyecto (incepción de ser posible).
Realizar una planeación detallada en la fase de incepción.
Detallar los Casos de Uso con Diagramas de Actividades.
Product Engineering
Fases vs. Iteraciones:
Product Engineering
• Las entregas cortas (Iteraciones) facilitan:
• Retroalimentación constante con el cliente en aspectos funcionales, administrativos y técnicos del proyecto.
• Controlar, probar y ajustar productos pequeños (aprox. 4 – 8 semanas) frente a productos grandes (medidos en meses y años)
Product Engineering
Product Engineering
• Los Entregables son el producto percibido por el cliente frente a una entrega (documentos y piezas de software).
• Los entregables son la medida ideal para centrar la estimación, el monitoreo y control de actividades ya que son los productos finales de la iteración.
Product Engineering
Cada disciplina RUP consta de:
1. Quién?: Workers/Roles
2. Cuando y Como?: Workflows y Actividades
3. Que?: Artefactos/Entregables.
Product Engineering
• Para simplificar el entendimiento del modelo se recomienda agrupar los flujos de actividades de las disciplinas en funcionales, técnicas y administrativas.
• El RUP se puede interpretar desde la perspectiva pedagógica de que enseña el “como” desarrollar productos de software.
• El RUP se puede interpretar desde la perspectiva práctica de que cada una de las disciplinas debe adoptarse/personalizarse ante las necesidades de cada proyecto.
• RUP NO obliga a usar toda la carga de artefactos o roles posibles para cada proyecto.
Product Engineering
• Se recomienda para la adopción práctica de RUP que se identifiquen (por disciplina) los artefactos y roles obligatorios o mínimos para cualquier proyecto:
1. Visión de Negocio2. Glosario de Negocio3. Plan del Proyecto4. Modelo de Requerimientos5. Modelo de Casos de Uso6. Documento de Arquitectura7. Plan de Pruebas8. Plan de Administración de la Configuración
• Según el tamaño del proyecto variaría el contenido de los mismos.
Product Engineering
• Es un aporte importante de RUP que los roles sean asociados a grupos de actividades comunes y específicas ya que facilitan su adopción práctica: “Estos pueden ser desde una persona con diferentes roles en diferentes instantes de tiempos (proyectos pequeños) hasta equipos de trabajo que representan un rol (proyectos grandes)”.
• En la práctica es crucial la confianza del PM en el arquitecto para agilizar la toma de decisiones técnicas.
Product Engineering
Product Engineering
Product Engineering
Project Management Analysis & Design
Project Manager Software Architect
Project Reviewer Designer
Environment Database Designer
Process Engineer Designer Reviewer
Tool Specialist Test
System Administrator Test Manager
Business Modeling Test Analyst
Business Process Analyst Test Designer
Business Designer Tester
Business Model Reviewer Deployment
Requirements Deployment Manager
Systems Analyst Course Developer
Requirements Specifier Graphic Artist
Requirements Reviewer Technical Writer
User Interface Designer Change & Configuration Mgmt
Implementation Configuration Manager
Implementer Change Manager
Code Reviewer Integrator
Business Modeling:• De forma análoga a la terminología
industrial, busca especificar los procesos de información de la organización.
• Desde la perspectiva del proveedor, es útil para entender el problema organizacional que es causa del proyecto de software.
• Desde la perspectiva del cliente sirve para organizar una propuesta de proyecto a partir de un problema.
Product Engineering
Business Modeling:
• Los procesos de negocio deben estar clara y detalladamente definidos y optimizados antes de convertirse en procesos del software.
• En UML los procesos se modelan desde D. CU y D.Actividades
Product Engineering
Requirements:• De forma análoga a la terminología industrial, busca
especificar los procesos de información del software a partir de identificar y normalizar las necesidades y requerimientos del cliente.
• Para facilitar su gestión se recomienda agruparlos por subsistemas y módulos.
• A nivel de industria de software no existe un proceso definido, formal y maduro de normalización de requerimientos.
• El resultado final de los requerimientos son Casos de Uso (Procesos del Software).
Product Engineering
Requirements:
• Una causa típica de fallos en los proyectos es que se definen como casos de uso macroprocesos/módulos y no procesos específicos (atómicos).
• A nivel de industria existe el error de definir los Casos de Uso tomando como base el texto, causa frecuente de malintepretaciones entre usuarios y proveedor dada su ambigüedad.
• En la práctica se recomienda que la definición de los Casos de Uso se base en modelos UML de casos de uso para macroprocesos hasta procesos atómicos. Y diagramas de actividades para modelar el workflow detallado de cada proceso atómico (Caso de Uso).
Product Engineering
Requirements: Normalización
• Actualmente existen esfuerzos en definir reglas para determinar el nivel de detalle al que se debe llegar para la definición de procesos del software (casos de uso):
1. Completitud2. Consistencia3. Correctitud4. Complejidad
Product Engineering
Product EngineeringAtributo Nivel Conceptual Nivel Especificación
Completitud ·Factor 1. ¿Han sido involucradas todas las área funcionales relevantes a las cuales apoyará el sistema?
·Factor 2. ¿Han sido involucradas todas las área funcionales secundarias a las cuales apoyará el sistema?
·Factor 3. ¿Han sido definidos todos los roles relevantes de usuario encargados de generar/modificar o consultar información?
·Factor 4. ¿Han sido definidos todos los roles secundarios de usuario encargados de generar/modificar o consultar información?
·Factor 5. ¿ Han sido considerados todos los sistemas externos con los cuáles interactuará el sistema?
·Factor 6. ¿Se presenta una descripción resumida (descrpción de alto nivel) de todos los casos de uso del negocio?
·Factor 7. ¿Están definidos todos los requisitos que justifican la funcionalidad del caso de uso?
·Factor 8. ¿Existen requisitos que no han sido considerados en algún caso de uso?
·Factor 9. ¿Han sido definidos todos los roles de usuario encargados deactividades de soporte/ mantenimiento / auditoría?
·Factor 10. ¿Se presenta una descripción detallada (descripción extendida esencial) de todos los casos de uso del negocio?
·Factor 11. ¿Están todas las acciones del flujo de eventos redactadas en función del responsable?
·Factor 12. ¿Se describen las condiciones de excepción relevantes que debe contemplar cada flujo de eventos?
·Factor 13. ¿Todos los casos de uso del negocio han sido clasificados de acuerdo a su relevancia (primario / secundario / opcional)?
Product EngineeringAtributo Nivel Conceptual Nivel Especificación
Consistencia Factor 14. ¿El nombre dado a los casos de uso es una expresión verbal que describe alguna funcionalidad relevante en el contexto del usuario?
·Factor 15. ¿Representa el caso de uso una interacción observable por un actor?
·Factor 16. ¿No existe solapamiento en la funcionalidad que representan los diferentes casos de uso?
·Factor 17. ¿Existen acciones en el flujo de eventos asignadas a un responsable que no le corresponde?
·Factor 18. ¿Está adecuadamente redactado (en el lenguaje del usuario) el flujo de eventos?
·Factor 19. ¿La descripción del flujo de eventos seinicia con la descripción de una acción externaoriginada por un actor o por una condición interna del sistema claramente identificable? ·Factor 20. Si en el caso de uso interviene mas de un actor, ¿existe claridad en cuál de ellos es el actor iniciador?
·Factor 21. ¿Existe una adecuada separación entre el flujo básico de eventos y los flujos alternos y/o flujos subordinados?
Product EngineeringAtributo Nivel Conceptual Nivel Especificación
Correctitud ·Factor 22. ¿Existe para cada caso de uso de negociopor lo menos un usuario responsable?
·Factor 23. ¿Representa el caso de uso requisitos comprensibles por el usuario?
·Factor 24. ¿Se ajusta la representación del diagrama del caso de uso de acuerdo a lo normado en la metodología?
·Factor 25. ¿Las interacciones definidas describen la funcionalidad requerida del sistema?
·Factor 26. ¿Las interacciones definidas introducen mejoras al proceso actual? ·Factor 27. ¿Se ajusta la representación del diagrama del caso de uso de acuerdo a lo normado en la metodología?
Product EngineeringAtributo Nivel Conceptual Nivel Especificación
Complejidad·Factor 28. ¿En sistemas relativamente grandes se harealizado una agrupación de los casos de uso en paquetes?
·Factor 29. ¿Los elementos dentro del diagrama están adecuadamente ubicados de manera que facilitan su interpretación?
Analisis & Design:
• Problema: Existe dependencia y centralización del Arquitecto. Desafortunadamente el Análisis y Diseño se basa en el “criterio del experto” (Arquitecto/Diseñador) ya que no se ha formalizado un proceso que sustente la toma de decisiones de diseño.
• Solución Propuesta: En la práctica se han desarrollado productos como GeneXus que generan código para cualquier plataforma tecnológica a partir de un modelo de requerimientos. Actualmente se está madurando este concepto en un estándar del OMG llamado MDA (Model Driven Architecture).
Product Engineering
Product Engineering
Software Architecture
Analisis & Design: MDA
Product Engineering
Analisis & Design: MDA• MDA se basa en tres principios (paralelos):
1. Modelo de Procesos (del software) = Requerimientos Normalizados
2. Modelo de Integración = a. Modelo de Subsistemas y Módulosb. Modelo de Datos (Conceptual o de dominio y
físico)
3. Modelo de la Plataforma tecnológica = Arquitectura de referencia, combinación de capas y patrones de diseño estándar para una plataforma de software.
Product Engineering
Product EngineeringSistema de Admon y Captura en campoSubsistema Seguridad
Subsistema Captura PedidosMódulo Admon Visitas
(4)
Módulo Admin
Pedidos(7)
Módulo Admon Cliente
(2)
Módulo Admon Cartera
(6)
Módulo Admon
Productos(3)
Módulo Admon Precios
(5)
Módulo Autenticaci
ón(1)
Subsistema Sincronización
Módulo Importación
(10)
Módulo Exportación
(11)
Sistema Almacenamiento y Consolidacion
Subsistema Sincronización
Módulo Exportación
(12)
Módulo Importación
(13)
Subsistema Reportes
ERP Cobol N
Subsistema Reportes
Módulo Reportes
(8)ERP Cobol 1
ERP Cobol 2
.
.
.
.
.
.Base de Datos
Módulo Reportes
(9)
Subsistema Inconsistencias
Módulo Inconsistencias
(9)
Product Engineering
Sistema Admon Captura Campo
Autenticación Usuario
Usuario Movil
Vendedor Supervisor Admin Aplicacion
Product EngineeringSistema Admon Captura Campo
VendedorAdmin Captura Pedidos
Sincronización
Admin Pedido
AdminClientes
Admin Cartera
Admin Precios
Admin Productos
Admin Visitas
Importar
Exportar
Editar Pedido ConsultarPedidos
CrearPedido
ConsultarClientes
ConsultarCartera
ConsultarPrecios
Consultar Inventario
Consultar Visitas
Actualizar Visitas
Product EngineeringSistema Admon Captura Campo
Usuario Movil
Admin Reportes Consultar Reporte
Vendedor Supervisor
Product Engineering Tipos de Usuarios de la Aplicación Móvil.
Vendedor: Administrar Captura de Pedidos
Registrar Pedido (incluye validaciones cartera, inventario, precios) Modificar Pedido Cancelar Pedido Consultar Pedidos Consultar Clientes Consultar Cartera Consultar Precios Consultar Productos Consultar Visitas Modificar Visita
Sincronizar Datos Con el Servidor Central Exportar Datos Cargar Datos
Supervisor Consultar Reportes Vendedor
Control de presupuesto de ventas diario y acumulado mensual por producto y canales (también aplica para el usuario Vendedor)
Control de cumplimiento de visitas objetivo, realizadas y efectivas Control de clientes realizados, nuevos o recuperados
Administrador Aplicación Móvil: Administrar Usuarios y Roles
Product Engineering
Autenticación Usuario
Usuario Web
SupervisorAdmin Aplicacion
Sistema Almacenamiento y Consolidación
Product EngineeringSistema Almacenamiento y Consolidación
Supervisor
Admin Reportes Consultar Reporte
AdmininstradorApplicación
Consolidacion
Admin Usuarios
Admin Roles
Admin Permisos
Sincronizar
Importar
ExportarAdministrarInconsistencias
Crear Usuario Editar UsuarioConsultar Usuarios
Crear Rol Editar Rol Consultar Rol
Crear Permiso Editar Permiso Consultar Permisos
Asignar Rol-Permiso
Asignar Usuario-Rol
Product Engineering Tipos de Usuarios del Servidor de
Consolidación.
Supervisor Consultar Reportes Consolidados
Administrador Servidor de Consolidación Administrar Inconsistencias Cargue de Datos
Crear, Modificar, Consultar y Eliminar Usuarios Crear, Modificar, Consultar y Eliminar Roles Asignar Roles a Usuario
Sincronizar Datos Vendedores Sincronizar Datos ERP (COBOL)
Product Engineering
Cliente
PK Cod_Cliente
Nombre Direccion Telefono FaxFK2 Cod_Tipo_Identificacion Nro_IdentificacionFK5 Cod_ZonaFK5 Cod_SubzonaFK6 Cod_Canal Condicion_Pago DescuentoFK7 Cod_Lista_Precio Codigo_Cargo Pendientes Parciales Retencion Cupo_CreditoFK8 Cod_BloqueoFK9 Cod_CobradorFK1 Cod_VendedorFK3 Cod_CiudadFK7 Columna_Precio
Vendedor
PK Cod_Vendedor
FK1 Cod_SupervisorFK4 Cod_ZonaFK4 Cod_SubzonaFK2 Cod_BloqueoFK3 Cod_Canal Nombre Cobrador Direccion Telefono Cod_Ciudad
Supervisor
PK Cod_Supervisor
Nombre Direccion Telefono
Zona
PK Cod_Zona
Descripcion
Subzona
PK,FK1 Cod_ZonaPK Cod_Subzona
Descripcion
Tipo_Identificacion
PK Cod_Tipo_Identificacion
DescripcionCiudad
PK Cod_Ciudad
Descripcion
Visita
PK,FK1 Cod_VendedorPK,FK2 Cod_ClientePK Fecha_Planeada_Visita
Fecha_Realizacion_Visita Orden_VisitaFK4 Cod_Tipo_VisitaFK3 Cod_Estado_Visita Observaciones
Pedido
PK Nro_Pedido
FK2 Cod_VendedorFK1 Cod_Cliente Fecha_Pedido Observaciones EstadoPedido
Detalle_Pedido
PK,FK1 Nro_PedidoPK Cod_Producto
FK4 Cod_Lista_PrecioFK4 Columna_PrecioFK2 Cod_Unidad_Medida Cantidad
Unidad_Medida
PK Cod_Unidad_Medida
Descripcion
Canal_Ventas
PK Cod_Canal
Descripcion
Producto
PK Cod_Producto
DescripcionFK1 Cod_Categoria_Producto
Lista_Precio
PK Cod_Lista_PrecioPK Columna_Precio
Factura
PK Nro_Factura
FK1 Cod_Cliente Fecha Total SaldoPendiente
Usuario
PK Cod_Usuario
Clave Nombres Apellidos
Rol
PK Cod_Rol
Descripcion
Permisos_Funcionalidad
PK Cod_Permiso_Funcionalidad
Descripcion
Usuario_Rol
PK,FK1 Cod_UsuarioPK,FK2 Cod_Rol
Rol_Permiso
PK,FK1 Cod_RolPK,FK2 Cod_Permiso_Funcionalidad
Bloqueo
PK Cod_Bloqueo
Descripcion
Detalle_Lista_Precio
PK,FK2 Cod_Lista_PrecioPK,FK2 Columna_PrecioPK,FK1 Cod_Producto
Cod_Unidad_Medida Valor
Inventario
PK,FK2 Cod_ZonaPK,FK2 Cod_SubzonaPK,FK1 Cod_Producto
CantidadFK3 Cod_Unidad_Medida
Estado_Visita
PK Cod_Estado_Visita
Descripcion
Presupuesto_Ventas
PK MesPK,FK1 Cod_VendedorPK,FK3 Cod_CanalPK,FK2 Cod_Ciudad
FK4 Cod_Categoria_Producto Dias_Habiles Obj_Mensual Total_Ventas_Mes
Control_Clientes
PK MesPK,FK1 Cod_VendedorPK,FK2 Cod_Ciudad
Obj_Mensual_Clientes_Nuevos Obj_Mensual_Clientes_Recuperados Cant_Clientes_Nuevos_Mes Cant_Clientes_Recuperados_Mes Cant_Clientes_Perdidos_Mes
Categoria_Producto
PK Cod_Categoria_Producto
Descripcion
Tipo_Visita
PK Cod_Tipo_Visita
Descripcion
Product EngineeringSistema Captura en CampoVendedor
Seleccionar Cliente
Desplegar Datos Cliente
Desplegar Datos del Pedido
Diligenciar Detalle Pedido
Consultar Cliente
Calcular y Desplegar Totales
Generar Alerta de Cupo
Generar Alerta de Cartera
Registrar Pedido
Aplicar Descuento Cliente
Integridad Datos valida?
Valor Total Pedido<=CupoCrédito Cliente?
Nro Dias Mora<=Condición Pago Cliente?
Continuar Pedido?
Si
No
Si
Si
No
No
Si
No
CodigoNombresApellidosNombre NegocioDirecciónTeléfonoCondición PagoCupo CreditoZonaSubZonaVendedor
Nro PedidoFecha PedidoEstado Pedido
Por cada línea de pedido:
Cod ProductoDesc. ProductoCantidadUnidad MedidaValor
Valor SubTotal Pedido (Antes Descuento)Valor DescuentoValor Total Pedido
Product Engineering
PocketDB
AplicaciónCaptura de
Pedidos
Modulo deSincronización
Base de datosConsolidada
Modulo ETLReplicación
AplicaciónWeb Admin &
ReportesERP
Distrito 1 ETL
Carpeta Entrada ERP
Modulo deSincronización
Repositorio temporal
ERP Distrito N ETL
ERP Distrito 2 ETL
SERVIDOR DE CONSOLIDACION
PDAERP
Carpeta Salida ERP
Tarjeta SD
Product Engineering
Base de datosConsolidada
AplicaciónWeb Admin &
Reportes
ERP
SERVIDOR DE CONSOLIDACION
PocketDB
AplicaciónCaptura de
Pedidos
PDA
ERP
PocketDB
AplicaciónCaptura de
Pedidos
Módem
ServidorWeb
IP Publica
Modulo ETLReplicación
Product Engineering
Product Engineering
Product Engineering
Product Engineering
Product Engineering
Product Engineering
Product Engineering
Product Engineering
Analisis & Design: MDA• El cruce de los tres principios genera
el Diseño Detallado del software.
• Los procesos (funcionales) son ortogonales a la arquitectura (software).
• Finalmente a partir del diseño detallado se genera el código.
Product Engineering
Analisis & Design: MDA
• MDA puede interpretarse desde la perspectiva comercial para definir un estándar de productos CASE.
• MDA puede aprovecharse desde la perspectiva metodológica para definir un proceso formal y estándar de Análisis y Diseño independiente de la plataforma tecnológica y el criterio experto.
Product Engineering
Analisis & Design:
La industria del software tiene un problema crítico asociado a la alta dependencia del rol de arquitecto frente a la falta de formalización del proceso de análisis y diseño:
“Se confunde un arquitecto con un desarrollador senior lo cuál afecta el grado de correctitud del producto, así a nivel funcional este cumpla con los requerimientos”
Product Engineering
Analisis & Design:
• Los defectos arquitectónicos difícilmente se detectan durante las pruebas funcionales.
• Los defectos arquitectónicos se detectan durante etapas post-productivas a la hora de realizar mantenimientos y mejoras a la aplicación (cuando queda poco o nada por hacer !!!).
• El impacto de los cambios es impredecible. Un cambio inestabiliza varias partes del código y/o toma mucho tiempo realizarlo.
• El conocimiento de un arquitecto es escaso y más aún para que un proyecto tenga un arquitecto revisor adicional al que ejecuta el proyecto ($$$).
Product Engineering
Arquitecto:
Predomina el pensamiento abstracto y organizado
Hábil para estructurar un modelo
Evalúa la viabilidad de la solución
Actúa de forma independiente de la plataforma tecnológica
Desarrollador Senior:
Predomina el pensamiento específico y creativo
Hábil para entender código
Generalmente es experto y actúa de acuerdo con los lineamientos de una plataforma tecnológica
Product Engineering
Arquitecto: Evalúa el uso de
frameworks
Busca la solución más simple para el proyecto
Busca el mejor balance costo-beneficio al mediano y largo plazo para el cliente
Odia los EJB de Entidad (J2EE)…
Desarrollador Senior: Adopta el uso de
frameworks por tendencia
Busca la solución más simple de programar
Piensa en lograr los objetivos puntuales del proyecto
No sabe no responde o le encantan los EJB de Entidad…
Product Engineering
Analisis & Design: Business Integration
La globalización ha traído un problema que en este instante la industriadel software no ha solucionado de manera formal, definitiva y contundente:
• Las organizaciones necesitan realizar negocios globales y para ello requieren información consolidada y en tiempo real.
• Lo anterior implica que los diferentes sistemas de información que conforman la organización se encuentren integrados.
• A nivel técnico existe una tendencia llamada SOA (Arquitecturas Orientadas a Servicios) que consiste en tipos de productos que intentan solucionar ese problema a partir de dos enfoques, el antiguo (mensajería empresarial) y el nuevo (Web Services).
Product Engineering
Product Engineering
Business Integration
Analisis & Design: Business Integration
• Otra tendencia frecuentemente malinterpretada es BPM.
• Tanto la mensajería como los web services y BPM tienen escenarios bien definidos donde deben o no aplicarse.
• En el mundo de los web services solo existen 3 estándares (WSDL, SOAP, WS-Security) si se usan según el WS-I.
• Por otro lado existen muchas propuestas de estándares que erróneamente pretenden reinventar el software empresarial pero programando XML.
• XML y SOAP deben entenderse como un lenguaje estándar para comunicar aplicaciones, no una nueva manera de desarrollarlas.
Product Engineering
Analisis & Design: Business Integration
• Finalmente, sea cual sea el desenlace en la estandarización de productos de Business Integration, sabremos si la solución es correcta si al usarla no nos obliga a depender directamente de web services, mensajería o BPM sino que integra transparentemente “servicios”, de negocio…
Product Engineering
TESTING:
• En la industria es marcada la falta de estandarización en la terminología de pruebas.
• No son claras las dependencias y tipos de pruebas y por tanto la estrategia para usarlas…
• Para proyectos de software, testing es un factor de costos decisivo para el Project Manager.
• Usualmente se disminuye el énfasis en estas para alcanzar los costos del proyecto.
Product Engineering
TESTING:
Product Engineering
QA (metodologías y buenas prácticas) y QC (Revisión y evaluación del producto, Testing)
Niveles de Prueba (Independiente del tipo de prueba)
1. Individual2. Integrado
(módulo/subsistema)3. Sistema
Fases de Prueba (ciclos y estados del producto)
1. Alfa (final de la fase de construcción) = Funcionalidad Completa
2. Beta (primer ciclo de transición) = Producto Estable - Candidato
3. Aceptación de Usuario (segundo ciclo de transición)
4. Pruebas de Instalación (checklist de entrega a producción)
5. Piloto en Producción
Product Engineering
Product Engineering
Un factor crítico para el éxito es realizar Pruebas Unitarias exhaustivas. Por clase y método público del sistema. “La estabiliad del todo se basa en la estabilidad de las partes…”
Es recomendable automatizar y agrupar las pruebas unitarias por clase, paquete y sistema (Test Cases & Test Suites).
Las pruebas unitarias deben ser autónomas e independientes de los datos, por tanto no deben existir dependencias en su orden de ejecución.
Todo lo anterior finalmente concluye en un esquema automatizado para Pruebas de Regresión.
Product Engineering
Las pruebas de regresión son una inversión costosa pero a todas luces sacrificable…
El no realizarlas es la causa más común de defectos recurrentes en entregas a producción después de haber realizado “supuestamente” varios ciclos de pruebas.
Product Engineering
Pese a su aparente falta de rigurosidad, las Pruebas de Guerrilla son la herramienta más ágil de encontrar defectos.
Se recomienda que se agrupen por tipos:
1. Pruebas de Validación (por campo)2. Pruebas de Control (por forma/pantalla/proceso)
3. Pruebas de lógica (workflow del caso de uso)4. Pruebas de lógica inversa (flujos alternos o de excepción)
5. Pruebas de navegación (entre pantallas y opciones menú)6. Pruebas de interacción funcional (otros módulos)7. Pruebas de consistencia / integralidad (de los datos)
Product Engineering
En nuestro medio se menosprecia el valor de las Pruebas de Performance pero es frecuente que la misma funcionalidad “estable” para un usuario, no lo sea ante casos de múltiples usuarios, condiciones de concurrencia y de carga.
Conociendo lo anterior es un riesgo asignarlas exclusivamente en fase de transición (el uso frecuente!!!).
Product Engineering
El cliente debe interpretar las pruebas como la última línea de defensa para implantar o no un software en producción.
Generalmente es más costoso para el cliente implantar un software inestable y que no cumpla con la funcionalidad requerida que cancelar su instalación productiva o invertir en pruebas en etapas tempranas del proyecto.
En administración de las pruebas es posible que la empresa de software registre niveles altos de calidad (0.3 defectos /KLOC) pero en las pruebas de aceptación y en producción la realidad sea distinta = No hicimos pruebas lo suficientemente exhaustivas…!!!
Product Engineering
Product Engineering
Product Engineering
Product Engineering
Product Engineering
Todos entendemos la importancia de las pruebas pero no las hacemos respetar…
Finalmente, la única gran verdad en pruebas es que el software nunca se deja de probar, las pruebas simplemente se abandonan…
Product Engineering
Product Engineering
PROJECT MANAGEMENT:
PMI
Estrategia de Desarrollo:
Product Engineering
Config & Change Mgmt:
Administración de los cambios Administración de la configuración
Product Engineering
Config & Change Mgmt:
Administración de los cambios Administración de la configuración
Product Engineering
Comité ejecutivo de informática
Consejo asesor
de cambios
Administrador de cambios
Propietario del cambio
Proceso de cambio
urgente
Adm
inis
tra
ción
d
e p
ub
lica
cion
es
Adm
inis
trac
ión
de c
am
bios
ENVÍO EVALUACIÓN APROVACIÓN PROGRA-MACIÓN
IMPLEMEN-TACIÓN
VALORACIÓN
Rechazo o se requiere más información
Cambio grande o importanteCambio urgente
Cambio estándar o pequeño
Rechazo
Cambio grande o
importante
Administrador de cambios
Iniciador del cambio
Product Engineering
Evaluación Compartida. El proceso de gestión de cambio será evaluado y aprobado por personal de Red Colombia y del equipo del proyecto en el cliente.
Hitos Por Fase UP. El control de los cambios al proyecto se basará en los hitos estándar de cada fase del proceso unificado.
Incepción. Formalización línea base de planeación de la generación.
Elaboración. Formalización línea base de requerimientos y Formalización de línea base de arquitectura.
Construcción. Formalización línea base del producto a entregar.
Product Engineering
Cualquier cambio o nuevo requerimiento en la planeación se someterá al procedimiento de control de cambios si se realiza después de formalizada la línea base de planeación de la generación.
Cualquier cambio o nuevo requerimiento funcional / no funcional del producto se someterá al procedimiento de control de cambios si se realiza después de formalizada la línea base de requerimientos de la generación.
Cualquier cambio o nuevo requerimiento en la arquitectura de la solución se someterá al procedimiento de control de cambios si se realiza después de formalizada la línea base de arquitectura de la generación.
Product Engineering
Config & Change Mgmt:
Administración de los cambios Administración de la
configuración
Product Engineering
Repositorio de artefactos
Políticas de Versionamiento y Líneas Base: [MajorRelease].[Phase].[iter/test-cycle] (pe. 1.1.1, 2.1.0)
Ítems de Configuración. Identificación Relaciones Seguimiento control y bloqueo
Product Engineering
Trazabilidad:
En términos tecnológicos es un concepto que permite asociar versiones y crear dependencias entre ítems de configuración.
En términos funcionales, es un mecanismo para garantizar que cada artefacto de un proyecto se encuentra asociado a un requerimiento del producto y que al final del proyecto se pueda determinar con hechos y datos que el producto final es consistente con las necesidades de negocio del cliente.
Product Engineering
Trazabilidad: Elementos
Auditorias de la Configuración .
Matriz de Trazabilidad.
Product Engineering
ENVIRONMENT:
Configure the project tools
Process Adoption Plan: Templates Config.
Purchases required products & services to develop the project product.
Set the project environment: Development Testing CM
Product Engineering
DEPLOYMENT:
Deployment Mgmt Plan
Integration Procedures
Deployment Procedures
Incepción: Entregables = Major Milestones = Objetivos
Dimensión Técnica Visión Técnica
Modelo Subsistemas y Módulos (D. UML de Componentes) Módelo Entidad Relación Req. No Funcionales (Características Sistémicas requeridas, restricciones,
riesgos, métricas)
Modelo Interface de Usuario Reporte Pruebas de Concepto Instalables Pruebas de Concepto Instalable Módulo Seguridad Prototipo del Sistema (Evolutivo?)
Product Engineering
Incepción: Entregables
Dimensión Funcional
Modelo de Negocio (Opcional según condiciones) Visión Funcional
Req. Funcionales: Modelo de Casos de Uso + Reglas de Negocio (D. Actividades)
Req. Suplementarios (Adicionales como normatividad legal)
Product Engineering
Incepción: EntregablesDimensión Administrativa y de Soporte
Plan General del Proyecto ( Integra subplanes)
1. Scope Mgmt Plan (WBS + Plan de Aceptación)
2. HR Mgmt Plan3. Comm Mgmt Plan
4. Procurement Mgmt Plan5. Quality Mgmt Plan (Metodología Proyecto + Plan de Auditorias + Plan de
Revisiones + Plan de Pruebas)
6. Risk Mgmt Plan7. Schedule (Cronograma)8. Budget9. Demás Planes de Gestión / Disciplinas RUP
Product Engineering
Elaboración: Entregables = Major Milestones
Dimensión Técnica Req No Funcionales (versión Final) Documento de Arquitectura (Cierre de Diseño)
Instalable Primera Versión del Sistema
Dimensión Funcional Modelo Casos de Uso Versión Final (Cierre de Req) Scripts de Pruebas
Dimensión Administrativa y de Soporte Plan de Construcción ( 9 Subplanes por Disciplinas RUP ) Plan de Pruebas (versión Final)
Product Engineering
Construcción: Entregables = Major Milestones Dimensión Técnica
Versión Funcional del Sistema ( Estado Alfa ) Reporte de Pruebas / iteración (Funcionales y técnicas) Manual Técnico V 1.0 Manual de Instalación V 1.0
Dimensión Administrativa y de Soporte Plan de Transición (o al final de elaboración)
Plan de Cierre Administrativo y Contractual (PMI) Plan de Deployment Plan de Capacitación Plan de Pruebas (de Transición) Plan de Aceptación (probablemente actualizado)
Product Engineering
Transición: Entregables = Major Milestones Dimensión Técnica
Versión Final del Sistema ( Estado Productivo ) Reporte Final de Pruebas Manual de Administración de la aplicación
Dimensión Funcional Manual de Usuario Final Documentación de Capacitación
Dimensión Administrativa y de Soporte Acta de Aceptación del Producto Acta de Cierre del Proyecto
Product Engineering
Product Engineering
Distribution Of Work Across Phases:
Product Engineering
Distribution Of Work Across Phases:
Product Engineering
Estratégias de Adopción de RUP
Versiones Por Fase Múltiples Versiones / Generaciones
Product Engineering
A set of iteration types with a particular configuration of lengths, numbers and objectives that is appropriate for projects with certain characteristics.
Analogous to design patterns
Product Engineering
Incremental Strategy
Strategy determine user needs define the system requirements perform the rest of the development in a sequence of builds, each
build adding more capabilities until the system is complete. Project Characteristics
The problem domain is familiar. Risks are well-understood. The project team is experienced.
Iteration Pattern a short Inception iteration to establish scope and vision, and to define
the business case a single Elaboration iteration, during which requirements are defined,
and the architecture established several Construction iterations during which the use cases are
realized and the architecture fleshed-out several Transition iterations to migrate the product into the user
community
Product Engineering
Evolutionary Lifecycle
Strategy acknowledges user needs are not fully understood all requirements cannot be defined up front, they are refined in each
successive build Project Characteristics
The problem domain is new or unfamiliar. The team is inexperienced
Iteration Pattern a short Inception iteration to establish scope and vision, and to define the
business case several Elaboration iterations, during which requirements are refined at
each iteration a single Construction iteration, during which the use cases are realized
and the architecture is expanded upon several Transition iterations to migrate the product into the user
community
Product Engineering
Incremental Delivery
Strategy phased deliveries of incremental functionality to the customer time-to-market pressures, where delivery of certain key features early can yield
significant business benefits requires a very stable architecture
Project Characteristics The problem domain is familiar:
the architecture and requirements can be stabilized early in the development cycle
there is a low degree of novelty in the problem The team is experienced. Incremental releases of functionality have high value to the customer.
Iteration Pattern a short Inception iteration to establish scope and vision, and to define the business
case a single Elaboration iteration, during which a stable architecture is baselined a single Construction iteration, during which the use cases are realized and the
architecture fleshed-out several Transition iterations to migrate the product into the user community
Product Engineering
Grand Design
Strategy traditional waterfall approach hard to avoid additional iterations in the transition phase.
Project Characteristics a small increment of well-defined functionality is being added to
a very stable product the new functionality is well-defined and well-understood The team is experienced, both in the problem domain and with
the existing product Iteration Pattern
a short Inception iteration to establish scope and vision, and to define the business case
a single very long Construction iteration, during which the use cases are realized and the architecture fleshed-out
several Transition iterations to migrate the product into the user community
Product Engineering
Estratégias de Uso de UP
Requerimientos detallados Requerimientos detallados visión y alcancevisión y alcance
Visión y Alcance
Análisis y Diseño
Construcción
Pruebas
Documento de Documento de diseño diseño
Visión y alcance aprobada
Entrega
Plan aprobado del Proyecto
Diseño de solución
Software versión Alfa
Versión final de la solución
Paso a producción
Informe Final de PruebasInforme Final de Pruebas
Plan de pruebas Plan de pruebas beta beta
Acta de Acta de InicioInicio
Product Engineering
Estratégias de Uso de RUP (2)
Versiones Por Fase
Product Engineering
Estratégias de Uso de RUP Multiples Versiones
Product Engineering
Estratégias para Agrupar Disciplinas:
Funcionales: Coordinada por Líder de Negocio Business Modeling Requirements Engineering
Técnicas: Coordianada por Líder Técnico Analisis & Design Development Testing Deployment
Administrativas: Coordinada por el PM Project Management Environment Management Admin & Config Management
Product Engineering
Estratégias para Agrupar Disciplinas Agrupar Disciplinas RUP en Macro Roles
Orientados al Cliente.
Product Engineering
Estratégias para Agrupar Disciplinas No se debe confundir una comunicación
abierta y eficiente entre los representantes de cada grupo con que NO debe existir jerarquía organizacional definida, lo cuál sería erroneo.
Product Engineering
Estratégias para Organizar Roles Agrupar Roles (Orientación al Cliente)
Equipo = Equipo Interno + Equipo Externo
Product Engineering
Estratégias para Organizar Equipos (4) Por Macro Roles
Product Engineering
Estratégias para Organizar Equipos (4) Por Subsistemas
Product Engineering
Estratégias para Organizar Equipos (4) Por Tipo de Rol
Product Engineering
Estratégias para Organizar Equipos (4) Mixtos
Product Engineering
Equipo Mínimo
Product Engineering
Tabla de Compatibiliad de Roles
Muchas Gracias por su tiempo !!!
Finalmente…