Contenido. Introducción. Buenas Prácticas. Buenas Prácticas. Introducción al RUP. Disciplina Requerimientos. Conclusiones. Desarrollo Iterativo

Transcripción

1 Contenido Introducción Buenas Prácticas Introducción al RUP Disciplina Requerimientos Conclusiones Buenas Prácticas Desarrollo Iterativo Administración de Requisitos Arquitectura basada en componentes Modelado Visual - UML Verificación continua de la Calidad Administración del Cambio 1

2 Buenas prácticas: Desarrollo Iterativo Definición Es una técnica usada para liberar la funcionalidad de un sistema en una serie de sucesivas versiones. Estas se van incrementando en funcionalidad hasta llegar a la versión final Cada versión es desarrollada en una porción específica de tiempo.. llamada Iteración Cada iteración se centra en Definir, Analizar, Diseñar, Construir y Testear un conjunto de requerimientos Modelo en cascada Características Análisis Diseño Codificación Integración Aceptación Administración de riesgos tardía Estimación de tiempos pobre Integración y pruebas tardías Aparición de actividades no planificadas Entregables al usuario, solo al final Los problemas se resuelven al final 2

3 Buenas prácticas: Desarrollo Iterativo Cada vuelta es una iteración de cada Iteración resulta una versión ejecutable El RIESGO está presente! Todos los proyectos involucran Riesgos Cuanto mas precisa haga su planificación, puede que logre identificar muchos riesgos Pero, indefectiblemente, muchos riesgos aparacen recién al momento de integrar el sistema No prodrá predecir todos los riesgos, a pesar de tener un equipo de desarrollo muy experimentado 3

4 Buenas prácticas: Desarrollo Iterativo Las iteraciones nos ayudan a: Resolver riesgos importantes antes de hacer grandes inversiones Activar tempranamente el feedback de los usuarios Hacer testing e integración en forma continua Dirigir el proyecto enfocándose en objetivos a corto plazo, alcanzables Posibilitar el despliegue de implementaciones parciales Buenas prácticas: Desarrollo Iterativo Riesgos en el modelo iterativo vs el modelo cascada 4

5 Origen de los errores en el software Programación 7% Otros 10% Diseño 27% Análisis 56% Caracterización de los errores Requerimientos correctos Requerimientos incorrectos Catarata de errores de Mizuno Análisis correcto Análisis incorrecto Análisis s/req. incorrectos Diseño correcto Diseño incorrecto Diseño s/análisis incorrecto Diseño s/análisis s/req. incorrectos Programa correcto Programa con errores Programa no corregible Programa con errores ocultos Programa con errores ocultos 5

6 Buenas Prácticas: Administración de Requisitos Qué es la administración de requerimientos? Es un enfoque sistémico para Encontrar, organizar, documentar y coordinar los requerimientos. Permite establecer u mantener el acuerdo entre el cliente/usuario y el equipo del proyecto sobre los cambios en los requerimientos. La clave para una administración de requerimientos efectiva, es mantener una clara definición de los requerimientos mediante sus atributos y la trazabilidad Buenas Prácticas: Administración de Requisitos En qué consiste la AR? Analizar el problema Entender las necesidades Definir el sistema Administrar el Cambio Redefinir el sistema Administrar el cambio en los requerimientos 6

7 Buenas Prácticas: Administración de Requisitos Trazabilidad entre los niveles de requerimientos Trazabilidad Necesidades del negocio Características de la solución Requerimiento de software Espacio del problema Espacio de la solución Buenas Prácticas: Arquitectura basada en componentes Qué es un componente arquitectónico? Porciones de código (fuente o ejecutable) con interfaces y comportamiento bien definidos que proveen una fuerte encapsulación de sus contenidos, siendo, por lo tanto, reutilizables para qué sirve? La arquitectura basada en componentes tiende a reducir considerablemente el tamaño y complejidad de la solución, haciéndola mas robusta. 7

8 Buenas Prácticas: Arquitectura basada en componentes Se busca una arquitectura resistente basada en componentes Resistente - flexibilidad Conocer requerimientos actuales y futuros Mejorar la extensibilidad promover la reutilización promover el encapsulamiento Basada en Componentes Componentes reutilizables y parametrizables Seleccionar componentes disponibles comercialmente Evolucionar incrementalmente el software existente Buenas Prácticas: Un modelo es: Modelado Visual Una simplificación de la realidad que provee una descripción acabada de un sistema desde una perspectiva particular (ocultando los detalles innecesarios) Para qué construimos modelos? Para entender mejor el sistema que estamos modelando 8

9 Buenas Prácticas: Modelado Visual Entonces en qué nos ayudan los modelos? Entender sistemas complejos Explorar y comparar alternativas de diseño a bajo costo Formar una fundamentación para la implementación Capturar requerimientos de forma precisa Comunicar decisiones sin ambiguedades Buenas Prácticas: Modelado Visual - UML secuencia Casos de Uso Colaboración Estados Múltiples vistas Modelos Sintaxis y semántica precisas de Clases Componentes actividad Despliegue Objetos 9

10 Herramientas del UML Modelado de requerimientos Modelado de la estructura Modelado de la interacción Modelado del comportamiento Herramientas de diseño Organización del modelo de casos de uso de clases de objetos de secuencias de colaboraciones de estados de actividades de componentes de despliegue de paquetes Buenas Prácticas: Verificación continua de la Calidad cuanto antes se descubran los errores, mas barato será su corrección Costo de la repación Costo de Oprtunidad Costo de Pérdida de Clientes Los problemas en el software son de 1 a 100 veces mas costosos para Encontrarlos y repararlos después del deployment 10

11 Buenas Prácticas: Verificación continua de la Calidad Testeo para distintas dimensiones de la Calidad Funcionalidad verificando el correcto funcionamiento de los escenarios Usabilidad desde la perspectiva del usuario final Confiabilidad verifica un comportamiento consistente y predecibles Rendimiento se verifica la respuesta ante la carga Mantenimiento La habilidad de mantenimiento al ponerlo en producción Buenas Prácticas: Administración del Cambio El coordinar las actividades y artefactos de los desarrolladores y los equipos, involucra establecer procedimientos repetibles para administrar cambios del software y otros artefactos de desarrollo permitiendo una mejor asignación de recursos Y un monitoreo continuo de estos cambios 11

12 Buenas Prácticas: Administración del Cambio Controlando Cambios del Software: Ofrece soluciones para las causas de los problemas del desarrollo El workflow de requerimientos de cambio está definido Los requisitos de cambio facilitan una clara comunicación Workspace bien definidos evitan interferencias ente los miembros de los equipos que trabajan en paralelo El valor estático de cambio es una buena métrica para evaluar el estado del proyecto la propagación de los cambios es evaluada y controlada Los cambios pueden se mantenidos en un sistema robusto y parametrizable BP Ejercicio práctico Dados los siguientes síntomas problemáticos en el desarrollo de software. Para cada uno de ellos, una con líneas a la/s causa/s que usted piensa está/n originando el problema Luego, teniendo en cuenta las Buenas Prácticas para el desarrollo de software Para cada una de las causas, señale la práctica aplicable para erradicarla 12

13 Buenas Prácticas Ejercicio Síntomas Necesidades no encontradas Requerimientos mezclados Módulos no integrables Díficil mantenimiento Descubrimiento tardío Baja calidad Baja performance Colisión de desarrolladores Causas Insuficientes toma de requerimientos Comunicación ambigua Arquitectura frágil Complejidad abrumadora Inconsistencias no detectadas Testing probre Definiciones subjetivas Desarrollo en cascada Cambios descontrolados Automatización insuficiente Buenas Prácticas Desarrollo iterativo Adm de Requerimientos Uso de CA Modelado c/uml Continuo control Q Adm. del Cambio 13