La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

ACIS Por Bernardo Díaz Arias Product Engineering.

Presentaciones similares


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

1 ACIS Por Bernardo Díaz Arias Product Engineering

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

4 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

5 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

6

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

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

12

13 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

14 Fases vs. Iteraciones: Product Engineering

15 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

16

17 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

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

19 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

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

21 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

22

23 Project ManagementAnalysis & Design Project ManagerSoftware Architect Project ReviewerDesigner EnvironmentDatabase Designer Process EngineerDesigner Reviewer Tool SpecialistTest System AdministratorTest Manager Business ModelingTest Analyst Business Process AnalystTest Designer Business DesignerTester Business Model ReviewerDeployment RequirementsDeployment Manager Systems AnalystCourse Developer Requirements SpecifierGraphic Artist Requirements ReviewerTechnical Writer User Interface DesignerChange & Configuration Mgmt ImplementationConfiguration Manager ImplementerChange Manager Code ReviewerIntegrator

24 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

25 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

26 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

27 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

28 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.Completitud 2.Consistencia 3.Correctitud 4.Complejidad Product Engineering

29 AtributoNivel ConceptualNivel 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 AtributoNivel ConceptualNivel 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 AtributoNivel ConceptualNivel 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 AtributoNivel ConceptualNivel 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 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

34 Software Architecture

35 Analisis & Design: MDA Product Engineering

36 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ódulos b.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

37

38

39

40

41 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

44 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

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

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

49 Product Engineering

50

51

52

53

54

55

56

57 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

58 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

59 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

60 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

61 Arquitecto: Predomina el p ensamiento 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

62 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

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

64 Business Integration

65 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

66 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

67 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

68 TESTING: Product Engineering

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

70

71 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

72 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

73 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

74 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

75 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

76

77

78

79

80 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

81 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 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: Deployment Mgmt Plan Integration Procedures Deployment Procedures

93 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

94 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

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

96 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

97 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

98 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

99 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 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 Requerimientos detallados visión y alcance Visión y Alcance Análisis y Diseño Construcción Pruebas Documento de 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 Pruebas Plan de pruebas beta Acta de Inicio

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…


Descargar ppt "ACIS Por Bernardo Díaz Arias Product Engineering."

Presentaciones similares


Anuncios Google