14/11/2009

Sistemas UNI Hoja 1

1

Seis “Mejores Prácticas”

Controlar Cambios

Administrar requerimientos

Arquitecturas

Basadas en

Componentes

Desarrollar

Iterativamente

Verificar

CalidadModelizar

Visualmente

2

PlaneamientoInicial

Planeamiento

Requerimientos

Análisis y Diseño

Implementación

Prueba

Distribución

Evaluación

Ambiente deAdministración

1. Desarrollar Software Iterativamente

Cada iteración resulta en un release ejecutable

14/11/2009

Sistemas UNI Hoja 2

3

1. Desarrollar Software Iterativamente

Los desentendimientos se evidencian temprano

Feedback del usuario

Testing continuo e iterativo

Carga de trabajo mejor repartida en el tiempo

Evidencias concretas a los sponsors

Se facilita la reutilización

Arquitectura más robusta

4

2. Administrar los requerimientos

Obtener, organizar y documentar la funcionalidad y restricciones requeridas a un sistema.

Analizar los cambios solicitados y evaluar impactos.

Registrar y documentar las alternativas y decisiones tomadas.

14/11/2009

Sistemas UNI Hoja 3

5

2. Administrar los requerimientos

Los requerimientos pueden ser adecuadamente

capturados y comunicados a través de Casos de Uso

Los Casos de Uso son importantes instrumentos de

planificación

Modelo de DiseñoModelo de Implementación Modelo de Test

verificaRealización influenciados porLos Casos de Uso direccionan el trabajo desde el análisis hasta el test

Modelo de Casos de Uso

6

Beneficios

Las comunicaciones están basadas en

requerimientos bien definidos.

Los requerimientos pueden ser priorizados, filtrados y

monitoreados.

Es posible realizar evaluaciones objetivas acerca del

éxito de un proyecto.

Las inconsistencias se detectan fácilmente.

Con herramientas adecuadas: repositorio de

requerimientos, con atributos y relaciones.

14/11/2009

Sistemas UNI Hoja 4

7

3. Arquitecturas Basadas en Componentes

La Arquitectura de Software representa el conjunto

de decisiones significativas sobre la organización de

nuestro sistema

selección de los elementos estructurales, y sus

interfaces

comportamiento

composición en subsistemas de los elementos

estructurales y de comportamiento

estilo de arquitectura que guía a la organización

8

3. Arquitecturas Basadas en Componentes

Vista

Lógica

Usuario

Funcionalidad

Vista de

Implementación

Programadores

Administración del Software

Vista del

ProcesoPerformance

Escalabilidad

Rendimiento

Integradores

Vista de

Desarrollo Topología

Distribución,

Instalación

Comunicación

Ingeniería

ConceptualFísica

Vista de Caso de

Uso

14/11/2009

Sistemas UNI Hoja 5

9

3. Arquitecturas Basadas en Componentes

Un componente de software puede definirse como un

módulo o un subsistema con una función y límites claros

pudiendo ser integrado en una arquitectura bien definida.

Realización física de una abstracción en el diseño

System-software

Middleware

Negocio

Aplicación

Arquitectura basada en componentes

10

3. Arquitecturas Basadas en Componentes

Industria de infraestructura de componentes

COM+ - Microsoft Component Object Model

CORBA - Common Object Request Broker Architecture -

OMG

JavaBeans - SUN

14/11/2009

Sistemas UNI Hoja 6

11

4. Modelar Software Visualmente Diagramas de Casos de Uso

Diagramas de Clases

Diagramas de Estados

Diagramas de Componentes

Diagramas de Implementación

Código

Clases

Subsistemas

Modelización Visual

eleva el nivel de

abstracción

12

Beneficios

Los casos de uso permiten especificar

comportamiento sin ambigüedades

Quedan expuestas las arquitecturas inflexibles o no

modulares.

El diseño refleja sus inconsistencias más

rápidamente.

Existen herramientas que proveen soporte para la

modelización visual.

14/11/2009

Sistemas UNI Hoja 7

13

5. Verificar la Calidad del Software

La actividad fundamental de esta práctica es el testing

Evaluar continuamente la calidad de un sistema con

respecto a funcionalidad, confiabilidad, performance

Desarrollo Implementación

CostoEncontrar y reparar un problema de software después de la implementación puede resultar de 100 a 1000 veces más costoso

14

Beneficios

La evaluación del estado del proyecto es objetiva,

se evalúan resultados de test.

Se exponen inconsistencias en requerimientos,

diseños e implementaciones

Se focaliza en las áreas de riesgo más alto.

Los defectos se identifican en forma temprana.

Existen herramientas automatizadas para el testing

de funcionalidad, confiabilidad y performance.

14/11/2009

Sistemas UNI Hoja 8

15

6. Controlar los Cambios al Software

Controlar, registrar y monitorear los cambios para

posibilitar el desarrollo iterativo

Establecer “workspaces” seguros para cada

desarrollador

Automatizar la integración y la administración de

“builds”

ALERTREPORT

Workspace

de Administración

Integración

Desarrollo en

paralelo

Administración

del Build

16

Beneficios

Las solicitudes de cambios formales facilitan la claridad de comunicación.

Los espacios de trabajo aislados reducen la interferencia entre los miembros del equipo que trabajan en paralelo.

Las estadísticas de cantidad de cambios permiten evaluar objetivamente el estado del proyecto

La propagación del cambio es evaluable y controlable.

Los cambios pueden ser mantenidos en sistemas automáticos.

14/11/2009

Sistemas UNI Hoja 9

17

Rational Unified Process (RUP)Provee:

Lineamientos, templates para herramientas, que guían una implementación efectiva de las6 Mejores Practicas

Controlar

Cambios

Administrar Requerimientos

Arquitecturas

Basadas en

Componentes

Desarrollar

Iterativamente

Verificar

CalidadModelizar

Visualmente

18

La Visión de Rational

“The Rational Way”

Orientado a Objetos Iterativo e Incremental Administrado y Controlado Altamente Automatizado

Centrado en tres Puntos: Personas Procesos Herramientas y métodos

14/11/2009

Sistemas UNI Hoja 10

19

El Ciclo de Vida del Software - Etapas

Concepción La idea. La visión del producto y su objeto de negocio

Elaboración Planeamiento de actividades. Recursos. Cualidades.

Arquitectura

Construcción Construcción del producto. Evolución de la visión, Arquitectura,

Planes

Transición Liberación del producto a la comunidad de usuarios

Evolución Siguientes versiones

20

El Ciclo de Vida del Software - Etapas

La “Evolución”

14/11/2009

Sistemas UNI Hoja 11

21

El Ciclo de Vida del Software -

Perspectivas

Dos Perspectivas

22

Estructura Estática de RUP

Entorno

Modelado del negocio

Implementación

Prueba

Análisis & Diseño

Preliminary Iteration(s)

Iter.#1

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Implantación

Manejo de configuraciones

Requerimientos

Elaboration TransitionInception Construction

Administración del proyecto

Workflows de Soporte

Workflows de Proceso

Fases

14/11/2009

Sistemas UNI Hoja 12

23

Rational Unified Process (RUP) y UML Desarrollados en armonía por Rational

RUP y Unified Modeling Language

(UML)

24

Un lenguaje de

modelización, no

es suficiente

Desarrollo Basado

En Equipos

Lenguaje de

ModeladoUnified

Process