ACIS Product Engineering Por Bernardo Díaz Arias berdiaz@yahoo.com.

Presentación del tema: "ACIS Product Engineering Por Bernardo Díaz Arias berdiaz@yahoo.com."— Transcripción de la presentación:

1 ACIS Product Engineering Por Bernardo Díaz Arias

2 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.

3 Product Engineering 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) ).

4 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.

5 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.

6 Product Engineering

7 Product Engineering 1. Disciplinas Funcionales: Business Modeling
Requirements Engineering

8 Product Engineering 2. Disciplinas Técnicas: Analisis & Design
Implementation Testing Deployment

9 Product Engineering 3. Disciplinas Administrativas: Project Management
Configuration & Change Mgmt Environment Mgmt

10 Product Engineering Las Fases son etapas de tiempo con objetivos claramente definidos: Incepción: Análisis del negocio/problema, Planeación del proyecto y gestión de requerimientos. 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%). Construcción: Generar una versión completamente funcional y estable del sistema (alfa). 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.

11 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 % 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).

12 Product Engineering

13 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.

14 Product Engineering Fases vs. Iteraciones:

15 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)

16 Product Engineering

17 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.

18 Product Engineering Cada disciplina RUP consta de:
Quién?: Workers/Roles Cuando y Como?: Workflows y Actividades Que?: Artefactos/ Entregables.

19 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.

20 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: Visión de Negocio Glosario de Negocio Plan del Proyecto Modelo de Requerimientos Modelo de Casos de Uso Documento de Arquitectura Plan de Pruebas Plan de Administración de la Configuración Según el tamaño del proyecto variaría el contenido de los mismos.

21 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.

22 Product Engineering

23 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

24 Product Engineering 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.

25 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

26 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).

27 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).

28 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): Completitud Consistencia Correctitud Complejidad

29 Product Engineering Atributo 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)?

30 Product Engineering Atributo 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?

31 Product Engineering Atributo 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?

32 Product Engineering Atributo 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?

33 Product Engineering 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).

34 Software Architecture
Product Engineering Software Architecture

35 Product Engineering Analisis & Design: MDA

36 Product Engineering Analisis & Design: MDA
MDA se basa en tres principios (paralelos): Modelo de Procesos (del software) = Requerimientos Normalizados Modelo de Integración = Modelo de Subsistemas y Módulos Modelo de Datos (Conceptual o de dominio y físico) 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.

37 Product Engineering

38 Product Engineering

39 Product Engineering

40 Product Engineering

41 Product Engineering Administrar Captura de Pedidos
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

42 Product Engineering

43 Product Engineering

44 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)

45 Product Engineering

46 Product Engineering

47 Product Engineering PDA SERVIDOR DE CONSOLIDACION ERP ETL
Aplicación Web Admin & Reportes PDA ERP Distrito 1 ETL Aplicación Captura de Pedidos Base de datos Consolidada Modulo ETL Replicación Modulo de Sincronización ERP Distrito 2 ETL Pocket DB Carpeta Entrada ERP Repositorio temporal Modulo de Sincronización Carpeta Salida ERP Tarjeta SD ERP Distrito N ETL

48 Product Engineering PDA SERVIDOR DE CONSOLIDACION ERP ERP Aplicación
Base de datos Consolidada Aplicación Web Admin & Reportes Aplicación Captura de Pedidos ERP Pocket DB ERP Modulo ETL Replicación Pocket DB Aplicación Captura de Pedidos Servidor Web IP Publica Módem

49 Product Engineering

50 Product Engineering

51 Product Engineering

52 Product Engineering

53 Product Engineering

54 Product Engineering

55 Product Engineering

56 Product Engineering

57 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.

58 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.

59 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”

60 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 ($$$).

61 Product Engineering Desarrollador Senior: Arquitecto:
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 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

62 Product Engineering Desarrollador Senior: Arquitecto:
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… 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)…

63 Product Engineering Analisis & Design: Business Integration
La globalización ha traído un problema que en este instante la industria del 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).

64 Product Engineering Business Integration

65 Product Engineering 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.

66 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…

67 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.

68 Product Engineering TESTING:

69 Product Engineering Fases de Prueba (ciclos y estados del producto) Alfa (final de la fase de construcción) = Funcionalidad Completa Beta (primer ciclo de transición) = Producto Estable - Candidato Aceptación de Usuario (segundo ciclo de transición) Pruebas de Instalación (checklist de entrega a producción) Piloto en Producción 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) Individual Integrado (módulo/subsistema) Sistema

70 Product Engineering

71 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.

72 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.

73 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: Pruebas de Validación (por campo) Pruebas de Control (por forma/pantalla/proceso) Pruebas de lógica (workflow del caso de uso) Pruebas de lógica inversa (flujos alternos o de excepción) Pruebas de navegación (entre pantallas y opciones menú) Pruebas de interacción funcional (otros módulos) Pruebas de consistencia / integralidad (de los datos)

74 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!!!).

75 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…!!!

76 Product Engineering

77 Product Engineering

78 Product Engineering

79 Product Engineering

80 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…

81 Product Engineering PROJECT MANAGEMENT: PMI Estrategia de Desarrollo:

82 Product Engineering Config & Change Mgmt:
Administración de los cambios Administración de la configuración

83 Product Engineering Config & Change Mgmt:
Administración de los cambios Administración de la configuración

84 Product Engineering

85 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.

86 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.

87 Product Engineering Config & Change Mgmt:
Administración de los cambios Administración de la configuración

88 Product Engineering Repositorio de artefactos
Políticas de Versionamiento y Líneas Base: [MajorRelease].[Phase].[iter/test-cycle] (pe , 2.1.0) Ítems de Configuración. Identificación Relaciones Seguimiento control y bloqueo

89 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.

90 Product Engineering Trazabilidad: Elementos
Auditorias de la Configuración . Matriz de Trazabilidad.

91 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

92 Product Engineering DEPLOYMENT: Integration Procedures
Deployment Mgmt Plan Integration Procedures Deployment Procedures

93 Product Engineering 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?)

94 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)

95 Product Engineering Incepción: Entregables
Dimensión Administrativa y de Soporte Plan General del Proyecto ( Integra subplanes) Scope Mgmt Plan (WBS + Plan de Aceptación) HR Mgmt Plan Comm Mgmt Plan Procurement Mgmt Plan Quality Mgmt Plan (Metodología Proyecto + Plan de Auditorias + Plan de Revisiones + Plan de Pruebas) Risk Mgmt Plan Schedule (Cronograma) Budget Demás Planes de Gestión / Disciplinas RUP

96 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)

97 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)

98 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

99 Product Engineering Distribution Of Work Across Phases:

100 Product Engineering Distribution Of Work Across Phases:

101 Product Engineering Estratégias de Adopción de RUP Versiones Por Fase
Múltiples Versiones / Generaciones

102 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

103 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

104 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

105 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

106 Product Engineering Grand Design Strategy Project Characteristics
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

107 Product Engineering Estratégias de Uso de UP Visión y Alcance Entrega
Paso a producción Visión y alcance aprobada Requerimientos detallados visión y alcance Visión y Alcance Entrega Informe Final de Pruebas Acta de Inicio Versión final de la solución Pruebas Análisis y Diseño Plan aprobado del Proyecto Plan de pruebas beta Diseño de solución Construcción Software versión Alfa Documento de diseño

108 Product Engineering Estratégias de Uso de RUP (2) Versiones Por Fase

109 Product Engineering Estratégias de Uso de RUP Multiples Versiones

110 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

111 Product Engineering Estratégias para Agrupar Disciplinas
Agrupar Disciplinas RUP en Macro Roles Orientados al Cliente.

112 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.

113 Product Engineering Estratégias para Organizar Roles
Agrupar Roles (Orientación al Cliente) Equipo = Equipo Interno + Equipo Externo

114 Product Engineering Estratégias para Organizar Equipos (4)
Por Macro Roles

115 Product Engineering Estratégias para Organizar Equipos (4)
Por Subsistemas

116 Product Engineering Estratégias para Organizar Equipos (4)
Por Tipo de Rol

117 Product Engineering Estratégias para Organizar Equipos (4) Mixtos

118 Product Engineering Equipo Mínimo

119 Product Engineering Tabla de Compatibiliad de Roles

120 Muchas Gracias por su tiempo !!!
Finalmente… Muchas Gracias por su tiempo !!!