Você está na página 1de 24

Seis Mejores Prcticas

Administrar requerimientos

Desarrollar Verificar Modelizar Arquitecturas


Iterativamente Calidad Visualmente Basadas en
Componentes

Controlar Cambios

Prof. Wenceslao Chvez Bedoya


1
1. Desarrollar Software Iterativamente
Cada iteracin resulta en un release ejecutable

Requerimientos
Anlisis y Diseo
Planeamiento
Implementacin
Planeamiento
Inicial Ambiente de
Administracin

Distribucin

Evaluacin
Prueba

2
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 reutilizacin
Arquitectura ms robusta

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

4
2. Administrar los requerimientos
Los requerimientos pueden ser adecuadamente
capturados y comunicados a travs de Casos de Uso
Los Casos de Uso son importantes instrumentos de
planificacin
Modelo de Casos de Uso

Los Casos de Uso verifica


Realizacin influenciados por
direccionan el
trabajo desde el
anlisis hasta el
test Modelo de Diseo
Modelo de Implementacin Modelo de Test

5
Beneficios

Las comunicaciones estn 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 fcilmente.
Con herramientas adecuadas: repositorio de
requerimientos, con atributos y relaciones.

6
3. Arquitecturas Basadas en Componentes
La Arquitectura de Software representa el conjunto
de decisiones significativas sobre la organizacin de
nuestro sistema
seleccin de los elementos estructurales, y sus

interfaces
comportamiento

composicin en subsistemas de los elementos

estructurales y de comportamiento
estilo de arquitectura que gua a la organizacin

7
3. Arquitecturas Basadas en Componentes

Vista de
Vista Implementacin
Lgica
Programadores
Usuario
Administracin del Software
Funcionalidad
Vista de Caso de
Uso

Ingeniera
Vista del Vista de
Topologa
Integradores Proceso Desarrollo Distribucin,
Performance
Conceptual Instalacin
Escalabilidad Fsica Comunicacin
Rendimiento

8
3. Arquitecturas Basadas en Componentes
Un componente de software puede definirse como un
mdulo o un subsistema con una funcin y lmites claros
pudiendo ser integrado en una arquitectura bien definida.
Realizacin fsica de una abstraccin en el diseo

Aplicacin

Negocio

Arquitectura basada Middleware


en componentes
System-
software
9
3. Arquitecturas Basadas en Componentes

Industria de infraestructura de componentes


COM+ - Microsoft Component Object Model

CORBA - Common Object Request Broker Architecture -

OMG
JavaBeans - SUN

10
4. Modelar Software Visualmente
Diagramas de Casos de Uso
Diagramas de Clases
Diagramas de Estados
Diagramas de Componentes
Diagramas de Implementacin

Subsistemas

Clases
Modelizacin Visual
eleva el nivel de
abstraccin Cdigo

11
Beneficios

Los casos de uso permiten especificar


comportamiento sin ambigedades
Quedan expuestas las arquitecturas inflexibles o no
modulares.
El diseo refleja sus inconsistencias ms
rpidamente.
Existen herramientas que proveen soporte para la
modelizacin visual.

12
5. Verificar la Calidad del Software
La actividad fundamental de esta prctica es el testing
Evaluar continuamente la calidad de un sistema con
respecto a funcionalidad, confiabilidad, performance

Encontrar y reparar un Costo


problema de software
despus de la
implementacin puede
resultar de 100 a 1000
veces ms costoso Desarrollo Implementacin

13
Beneficios

La evaluacin del estado del proyecto es objetiva,


se evalan resultados de test.
Se exponen inconsistencias en requerimientos,
diseos e implementaciones
Se focaliza en las reas de riesgo ms alto.
Los defectos se identifican en forma temprana.
Existen herramientas automatizadas para el testing
de funcionalidad, confiabilidad y performance.
14
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 integracin y la administracin de
builds Desarrollo en
Workspace
de Administracin paralelo

REPORTALERT
Integracin Administracin
del Build

15
Beneficios
Las solicitudes de cambios formales facilitan la
claridad de comunicacin.
Los espacios de trabajo aislados reducen la
interferencia entre los miembros del equipo que
trabajan en paralelo.
Las estadsticas de cantidad de cambios permiten
evaluar objetivamente el estado del proyecto
La propagacin del cambio es evaluable y
controlable.
Los cambios pueden ser mantenidos en sistemas
automticos.
16
Rational Unified Process (RUP)
Provee:
Lineamientos, templates para herramientas, que
guan una implementacin efectiva de las
6 Mejores Practicas
Administrar Requerimientos

Desarrollar Verificar Modelizar Arquitecturas


Iterativamente Calidad Visualmente Basadas en
Componentes

Controlar
Cambios

17
La Visin de Rational

The Rational Way

Orientado a Objetos
Iterativo e Incremental
Administrado y Controlado
Altamente Automatizado

Centrado en tres Puntos:


Personas

Procesos

Herramientas y mtodos

18
El Ciclo de Vida del Software - Etapas
Concepcin
La idea. La visin del producto y su objeto de negocio
Elaboracin

Planeamiento de actividades. Recursos. Cualidades.
Arquitectura
Construccin
Construccin del producto. Evolucin de la visin,
Arquitectura, Planes
Transicin

Liberacin del producto a la comunidad de usuarios
Evolucin

Siguientes versiones

19
El Ciclo de Vida del Software - Etapas

La Evolucin

20
El Ciclo de Vida del Software -
Perspectivas

Dos Perspectivas

21
Estructura Esttica de RUP
Fases
Workflows de Proceso Inception Elaboration Construction Transition

Modelado del negocio


Requerimientos
Anlisis & Diseo
Implementacin
Prueba
Implantacin
Workflows de Soporte
Manejo de configuraciones
Administracin del proyecto
Entorno
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
22
Iter.
#m+1
RUP y Unified Modeling Language
(UML)

Rational Unified Process (RUP) y UML


Desarrollados en armona por Rational

23
Un lenguaje de
Desarrollo Basado
modelizacin, no En Equipos
es suficiente

Lenguaje de Unified
Modelado Process

24

Você também pode gostar