ACIS Por Bernardo Díaz Arias [email protected] Product Engineering.

ACIS

Por Bernardo Díaz [email protected]

Product Engineering

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


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?


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?


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

http://www.smartdraw.com/tutorials/software-uml/uml4.htm






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


Pedidos

PDA

ERP

PocketDB


Pedidos

Módem

ServidorWeb

IP Publica

Modulo ETLReplicación

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


• 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


• 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

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

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

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…

ACIS Por Bernardo Díaz Arias [email protected] Product Engineering.

Documents

Transcript of ACIS Por Bernardo Díaz Arias [email protected] Product Engineering.