6 mejores prácticas
Post on 21-Dec-2015
223 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related