Sei sulla pagina 1di 134

Proyecto Integrador

Unidad 1:
Introduccin

1.1 Que es el anlisis y diseo


OO?
El marco de desarrollo de una aplicacin
software estara formado por las tres fases
tradicionales:
anlisis,
diseo
e
implementacin.
El anlisis es la fase cuyo objetivo es
estudiar y comprender el dominio del
problema, es decir, el anlisis se centra en
responder al interrogante QU HACER?
El diseo, por su parte, dirige sus esfuerzos
en desarrollar la solucin a los requisitos

1.1 Que es el anlisis y diseo


OO?
La fase de implementacin sera la
encargada de la traduccin del diseo de la
aplicacin al lenguaje de programacin
elegido, adaptando por tanto la solucin a
un entorno concreto.

1.1 Que es el anlisis y diseo


OO?
La transicin entre las fases de anlisis y
diseo en la orientacin al objeto es muy
suave lo que puede provocar confusin
entre las etapas.
Esto implica que sea difcil determinar donde
acaba el Anlisis Orientado a Objeto (AOO) y
donde comienza el Diseo Orientado a
Objeto (DOO), siendo la frontera entre
ambas fases totalmente inconsistente, de
forma que lo que algunos autores incluyen
en el AOO otros lo hacen en el DOO.

1.1 Que es el anlisis y diseo


OO?
El objetivo del AOO es modelar la semntica
del problema en trminos de objetos
distintos pero relacionados. Por su parte, el
DOO conlleva reexaminar las clases del
dominio
del
problema,
refinndolas,
extendindolas y reorganizndolas, para
mejorar su reutilizacin y tomar ventaja de
la herencia.
El anlisis casa con el dominio del problema
y el diseo con el dominio de la solucin; por
lo tanto el AOO enfoca el problema en los

1.1 Que es el anlisis y diseo


OO?
Los objetos del dominio del problema
representan cosas o conceptos utilizados
para describir el problema, recibiendo el
nombre de objetos semnticos porque ellos
representan las abstracciones que encierran
el significado del dominio del problema.
El anlisis se centra en la representacin del
problema, es decir, en la identificacin de
las abstracciones que representen el
significado de las especificaciones y de los
requisitos del sistema.

1.1 Que es el anlisis y diseo


OO?
El nfasis del diseo se centra en la
definicin de la solucin. Los objetos
semnticos sern refinados durante la fase
de anlisis y de diseo, siendo completados
con los objetos propios del dominio de la
solucin.
Los objetos del dominio de la solucin
incluyen: objetos de interfaz, objetos de
aplicacin y objetos base o de utilidad. stos
no forman parte directamente de los objetos
del dominio problema, pero representan la

1.1 Que es el anlisis y diseo


OO?
Una vez realizada esta introduccin al AOO y
al DOO se puede proceder a dar una
definicin ms concreta de ambos procesos.
AOO: Es el proceso que modela el dominio
del problema identificando y especificando
un conjunto de objetos semnticos que
interaccionan y se comportan de acuerdo a
los requisitos del sistema.
DOO: Es el proceso que modela el dominio
de la solucin, lo que incluye a las clases

1.1 Que es el anlisis y diseo


OO?
En el AOO deben llevarse a cabo las
siguientes actividades:
La

identificacin de clases semnticas,


atributos y servicios
Identificacin de las relaciones entre
clases (generalizaciones, agregaciones y
asociaciones).
El emplazamiento de las clases, atributos y
servicios.
La especificacin del comportamiento
dinmico mediante paso de mensajes.

1.1 Que es el anlisis y diseo


OO?
En el DOO deben llevarse a cabo las
siguientes actividades:
Aadir las clases interfaz, base y utilidad.
Refinar las clases semnticas.

Como resumen final, se podra afirmar que


el AOO y el DOO no deben verse como fases
muy
separadas,
siendo
recomendable
llevarlas a cabo concurrentemente, as el
modelo de anlisis no puede completarse en
ausencia de un modelo de diseo, ni

1.2.1 El espacio del problema


(anlisis).
El anlisis orientado a objetos es el proceso
que modela el dominio del problema
identificando y especificando un conjunto de
objetos semnticos que interaccionan y se
comportan de acuerdo a los requisitos del
sistema.
[Monarchi y Puhr, 1992]

1.2.1 El espacio del problema


(anlisis).
El anlisis se centra en la investigacin

del problema, no en la manera de definir la


solucin. Por ejemplo, si se necesita un
nuevo sistema de biblioteca, Cules
procesos de la institucin se relacionan con
su uso?
Durante el anlisis orientado a objetos se
procura ante todo identificar y describir los
objetos o conceptos dentro del dominio
del problema.
Identificar los requisitos: documentos de
anlisis.

1.2.1 El espacio del problema


(anlisis).
Especificar los requisitos: documento de

especificacin de requisitos.
Documento tcnico.
Organizacin y clasificacin de los requisitos.
La especificacin de requisitos describe

el

sistema en lenguaje natural.


Analizar: Modelos de anlisis.
Estudio de posibles escenarios: casos de uso.
Otras tcnicas: fichas CRC, orientados al flujo,
etc.
Validar.

1.2.1 El espacio del problema


(anlisis).

1.2.1 El espacio del problema


(anlisis).

1.2.1 El espacio del problema


(anlisis).
Modelo
de
escenarios.

anlisis

basado

en

Modelo funcional: casos de uso y

escenarios.
Modelo de Objetos: diagramas de clases y
objetos.

1.2.1 El espacio del problema


(anlisis).
Casos de uso.
Describen qu hace el sistema desde el

punto de vista de un observador externo.


Actores:
quin
interacta
con
el
sistema?. Tambin pueden ser otros
sistemas.
Un escenario es un ejemplo de lo que
ocurre cuando uno o varios actores
interactan con el sistema.
Caso de uso: conjunto de escenarios
(secuencias de interaccin de los actores y

1.2.1 El espacio del problema


(anlisis).
Casos de uso. Pasos a seguir.
Identificar los lmites (alcance) del sistema.
Identificar los actores principales.
Para cada uno, identificar sus objetivos.
Definir casos de uso que satisfagan sus

objetivos.

1.2.1 El espacio del problema


(anlisis).

1.2.1 El espacio del problema


(anlisis).

1.2.1 El espacio del problema


(anlisis).

1.2.1 El espacio del problema


(anlisis).
Modelos de Anlisis Basados en Clases.
Analizar los documentos de anlisis, o casos de

uso.
Clases que pertenecen al espacio de la solucin
vs. espacio del problema.
Aislar los sustantivos:
Entidades externas: producen o consumen informacin

que usa el sistema.


Cosas (informes, seales, etc.): informacin que
necesita el sistema.
Sucesos o eventos que ocurren durante la operacin del
sistema.
Papeles que desempean los usuarios.

1.2.1 El espacio del problema


(anlisis).
Diagrama de Clases Conceptuales.

1.2.1 El espacio del problema


(anlisis).
Clasificacin de clases.
Tipos de clases:
De entidad (a.k.a. de modelo o de
negocio). Son clases que persisten durante
la aplicacin. Representan informacin
relevante para la aplicacin.
De frontera (a.k.a. de contorno). Clases
que crean la interfaz que el usuario ve y
con la que interacciona.
De control. Realizan una unidad de
trabajo: crean o actualizan objetos de

1.2.1 El espacio del problema


(anlisis).
Diagrama de clases de anlisis.
Caso de uso Procesar Venta.

1.2.1 El espacio del problema


(anlisis).
Mtodo de Clase-ResponsabilidadColaborador (CRC)
Facilitan la colaboracin entre

desarrolladores.
Una ficha por cada clase relevante.
Se identifican sus responsabilidades.
Divisin de responsabilidades, relaciones de
colaboracin.
Jerarquas de
generalizacin/especializacin.

1.2.1 El espacio del problema


(anlisis).
Mtodo de Clase-ResponsabilidadColaborador (CRC)

1.2.1 El espacio del problema


(anlisis).
Del Anlisis al Diseo.
El modelo de anlisis describe el sistema

desde el punto de vista de los actores.


No contiene informacin de la estructura
interna del sistema, esto es del cmo.
Diseo del sistema:
Objetivos de diseo que se deben optimizar

(derivados de los requisitos no funcionales).


Una arquitectura software: descomposicin en
subsistemas, dependencias entre ellos, etc.

1.2.1 El espacio del problema


(anlisis).
Del Anlisis al Diseo.
Diseo detallado (de objetos).
Refinamiento del diseo del sistema.
Diseo de las clases de la solucin, interfaces.

1.2.2 El espacio de la solucin


(diseo).
El Diseo Orientado a los Objetos (DOO)
crea una representacin del problema del
mundo real y la hace corresponder con el
mbito de la solucin, que es el software.
A diferencia con otros mtodos de diseo, el
DOO produce un diseo que interconecta
objetos
de
datos
y
operaciones
de
procesamiento para esos objetos, de forma
que se modulariza la informacin y el
procesamiento, en lugar de aislar el
procesamiento.

1.2.2 El espacio de la solucin


(diseo).
Todos los mtodos de diseo
desarrollar software basndose en:

intentan

Abstraccin.
Ocultamiento de informacin.
Modularidad.

El DOO proporciona un mecanismo que permite


al diseador consigue estas tres caractersticas
sin dificultad.
El AOO, el DOO y la POO comprenden un
conjunto de actividades de la IS para la

1.2.2 El espacio de la solucin


(diseo).
Objetos, operaciones y mensajes.
El funcionamiento del software se consigue al
actuar uno o ms procesos sobre una
estructura de datos de acuerdo con un
procedimiento de invocacin.
Para conseguir un DOO, tenemos que
establecer un mecanismo para:
Representar la estructura de datos
Especificar el proceso
Realizar el procedimiento de invocacin

1.2.2 El espacio de la solucin


(diseo).
Objetos, operaciones y mensajes.
Objeto: Componente del mundo real que se
hace corresponder con el software. En un
Sistema
de
Informacin
basado
en
Computador, un objeto es un producto o
consumidor de informacin, o un elemento de
informacin.
Cuando se hace corresponder un objeto con
su realizacin software, implementamos una
estructura de datos y usa serie de procesos

1.2.2 El espacio de la solucin


(diseo).
Objetos, operaciones y mensajes.
Operaciones,
mtodos
o
servicios:
Procesos a los que se le permite transformar
estructuras de datos.
Mensajes: Peticiones que se realizan a los
objetos para que realicen alguna de sus
operaciones. Las operaciones contienen
construcciones procedimentales y de control,
que se invocan mediante un mensaje.

1.2.2 El espacio de la solucin


(diseo).
Objetos, operaciones y mensajes.
Mensajes.

1.2.2 El espacio de la solucin


(diseo).
Objetos, operaciones y mensajes.
Al definir un objeto con parte privada y
proporcionar mensajes para invocar al
procedimiento adecuado conseguimos el
ocultamiento de informacin. De esta
forma dejamos ocultos al resto de los
elementos de programa los detalles de
implementacin del objeto.
Los objetos con sus operaciones proporcionan
una modularidad inherente, es decir los
elementos del software (datos y procesos)

1.2.2 El espacio de la solucin


(diseo).
Aspectos de diseo.
Meyer sugiere cinco criterios para evaluar la
calidad de un mtodo de diseo a partir de la
modularidad.
Descomponibilidad: Facilidad con la que un mtodo de

diseo ayuda al diseador a descomponer un problema en


sub-problemas ms sencillos.
Componibilidad: Grado en el que un mtodo de diseo
permite la reutilizabilidad de mdulos.
Compresibilidad:
Facilidad
para
comprender
un
componente del programa sin tener que hacer referencia a
otros mdulos.
Continuidad: Capacidad de realizar cambios en un

1.2.2 El espacio de la solucin


(diseo).
Aspectos de diseo.
A partir de estos criterios, Meyer sugiere la
derivacin de cinco principios de diseo para
arquitecturas modulares:
Unidades modulares
Pocas interfaces
Interfaces pequeas (acoplamiento dbil)
Interfaces explcitas
Ocultamiento de informacin.

1.2.2 El espacio de la solucin


(diseo).
Aspectos de diseo.
Para conseguir un acoplamiento dbil, se
debe minimizar el nmero de interfaces entre
mdulos y minimizar la cantidad de
informacin que se mueve a travs de una
interfaz.
Siempre que los mdulos tengan que
comunicarse tiene que hacerlo de forma
clara, mediante interfaces explcitas, y no
mediante una zona global de datos, ya que la

1.2.2 El espacio de la solucin


(diseo).
Clases, instancias y herencia.
Muchos objetos del mundo real tienen
caractersticas prcticamente iguales y
realizan operaciones prcticamente similares.
Por ejemplo, si observamos un conjunto de
vehculos, vemos que existen motos,
automviles y camiones. Aunque todos estos
objetos son diferentes, todos pertenecen a
una clase superior, llamada vehculo.

1.2.2 El espacio de la solucin


(diseo).
Clases, instancias y herencia.
Todos los objetos de la clase vehculo tienen
atributos comunes (marca, modelo, ...) y
realizan una serie operaciones comunes
(acelerar, frenar, ...).
Las implementaciones en software de objetos
del mundo real se hacen de forma muy
similar. Todos los objetos son miembros de
una clase mayor y heredan la estructura de
datos privada y las operaciones que se hayan

1.2.2 El espacio de la solucin


(diseo).
Clases, instancias y herencia.
Es decir una clase es un conjunto de objetos
que tienen las mismas caractersticas. As, un
objeto es una instancia de una clase mayor.
Pero, qu ocurre cuando una instancia de
una clase mayor contiene una serie de
atributos y/o operaciones que son propias de
la instancia?
La solucin a este problema es la creacin de
subclases, que heredara los atributos y las
operaciones de la clase superior, y permite

1.2.2 El espacio de la solucin


(diseo).
Clases, instancias y herencia.

1.2.2 El espacio de la solucin


(diseo).
Clases, instancias y herencia.
El uso de clases, subclases y herencia tiene
mucha importancia
en la Ingeniera del
Software moderna.
La reutilizacin de componentes del software
(que
nos
permite
conseguir
la
componibilidad) se lleva a cabo creando
objetos (instancias) que se forman sobre los
atributos y las operaciones de una clase o
una subclase. Slo hay que especificar cules

1.2.2 El espacio de la solucin


(diseo).
Descripciones de los objetos.
La descripcin del diseo de un objeto (una
instancia de una clase o de una subclase)
est compuesta de dos partes:
Descripcin

de la interfaz: Establece la
interfaz del objeto, definiendo los mensajes que
puede recibir el objeto y las operaciones que
puede realizar cuando el objeto recibe el
mensaje.

Descripcin de la implementacin: Muestra

los detalles de cada una de las operaciones

1.2.2 El espacio de la solucin


(diseo).
Descripciones de los objetos.
Los detalles de implementacin incluyen
informacin sobre la parte privada del objeto,
es decir, los detalles de las estructuras de
datos y los detalles procedimentales que
describen las operaciones.
La

descripcin de la interfaz son un


conjunto de mensajes con sus comentarios
correspondientes.
La descripcin de la implementacin
debe contener la informacin suficiente para

1.2.2 El espacio de la solucin


(diseo).
Descripciones de los objetos.
A la diferencia entre la forma de especificar
qu es lo que se desea y cmo se proporciona
ese servicio es lo que se conoce como
encapsulamiento.
Por tanto, el paradigma orientado a objetos
persigue el encapsulamiento, es decir,
mostrar slo las operaciones visibles, y
ocultar los detalles de implementacin,
creando una sensacin de cajas negras a las

1.2.2 El espacio de la solucin


(diseo).
Mtodos de diseo Orientado a Objetos.
Debemos comprender la diferencia entre el
Anlisis Orientado a Objetos, que es una
actividad de clasificacin, y el Diseo
Orientado a Objetos, que define los objetos
que se derivan de cada clase, se tiene que
indicar las relaciones que existen entre ellos
mediante una notacin.

1.3.1 Desarrollo Iterativo.


El desarrollo iterativo es un enfoque para
construir software (o cualquier cosa) en el
cual el ciclo de vida se compone por varias
iteraciones en secuencia.
Cada iteracin es un mini-proyecto autocontenido compuesto por actividades como
anlisis de requisitos, diseo, programacin y
pruebas.
El objetivo final de una iteracin es obtener
un release de iteracin: un sistema

1.3.1 Desarrollo Iterativo.


Es decir: Todo el software a travs de todos
los equipos de desarrollo se integra en un
release en cada iteracin.
Los release pueden ser internos (para el
equipo de desarrollo) o externos (para el
cliente).

1.3.1 Desarrollo Iterativo.


Longitud de las iteraciones.
Muchos

proyectos tienen al menos tres


iteraciones antes de un release al pblico
final.

En

los mtodos modernos, la longitud


recomendada de una iteracin oscila
entre 1 y 6 semanas.

1.3.1 Desarrollo Iterativo.


Los mtodos IID promueven una combinacin
de prioridades dirigida por el cliente y por
los riesgos.
Desarrollo
riesgos:

iterativo

dirigido

por

los

Seleccione los elementos ms riesgosos y

difciles para las primeras iteraciones.

Ejemplo.- Un cliente podra decir: Deseo


que las pginas Web sean verdes y que el
sistema
maneje
5,000
transacciones
simultneas

1.3.1 Desarrollo Iterativo.


Desarrollo
cliente:
La

iterativo

dirigido

por

el

eleccin de caractersticas para cada


iteracin debe venir del cliente cualquiera que
sea lo que l considera de mayor valor.
De esta forma el cliente conduce el proyecto,
iteracin
por
iteracin,
solicitando
las
caractersticas que en ese momento considera
de mayor valor.
De esta forma el cliente adaptativamente
planea la seleccin para la siguiente iteracin,
brevemente antes de iniciarla, basado en la
experiencia adquirida en la iteracin previa, ms

1.3.1 Desarrollo Iterativo.


Aplique ambas tcnicas
Porque:
Los clientes no siempre son capaces de

percibir lo que tcnicamente es ms difcil


o riesgoso.
Los desarrolladores no siempre aprecian lo

que es de ms alto valor para el negocio.

1.3.1 Desarrollo Iterativo.


El principio de Timeboxing.
Es la prctica de mantener fija la fecha
final de la iteracin y no permitir cambios.
Este principio debera aplicar tambin para la
fecha final de todo el proyecto.
Si
eventualmente
sucediera
que
las
solicitudes hechas (mbito) para una
iteracin no pueden satisfacerse dentro del
timebox, entonces en lugar de cambiar la
fecha final, el mbito se reduce (colocando
las prioridades de ms bajo riesgo al final de

1.3.1 Desarrollo Iterativo.


El principio de Timeboxing.
Esto con el fin de que se obtenga un sistema
parcial (pero creciente) en un estado
estable y probado.
Es importante que el Timeboxing no se
utilice para presionar a los desarrolladores
para que trabajen largas horas para cumplir
con la inminente fecha de terminacin. Si el
paso normal de trabajo es insuficiente, haga
menos.

1.3.1 Desarrollo Iterativo.


El principio de Timeboxing.
No todos los time-box necesitan ser iguales:
La primer iteracin puede ser 4 semanas.
La segunda iteracin 3 semanas, etc.

Como
ya
mencionamos
la
recomendada es: 1 a 6 semanas.

longitud

1.3.1 Desarrollo Iterativo.


El principio de Timeboxing.
Se ha demostrado que Pasos cortos poseen:
Menor complejidad.
Menor riesgo.
Mejor retroalimentacin.
Ms alta productividad.
Mayor razn de xito.

Todos los mtodos modernos (incluyendo


Scrum, XP o UP) requieren o recomiendan
aplicar timeboxing a las iteraciones.

1.3.1 Desarrollo Iterativo.


El principio de Timeboxing.

1.3.1 Desarrollo Iterativo.


Beneficios de Timeboxing.
Enfoque:

El enfoque psicolgico que


promueve una fecha de terminacin fija de
3 semanas es muy diferente al que
promueve una de 3 meses. Time boxing es
un antidoto a la Ley de Parkinson: El
trabajo se expande para ocupar todo el
tiempo disponible.

Las

personas recuerdan ms fechas


postergadas
que
caractersticas
postergadas: es un capricho de la
naturaleza humana.

1.3.1 Desarrollo Iterativo.


Beneficios de Timeboxing.
Forzar a atacar niveles pequeos de

complejidad:
la
investigacin
ha
demostrado que pasos de complejidad baja
se realizan ms productivamente.
Forza

tempranamente
a
tomar
decisiones difciles y de compensacin:
se obliga a ser realista en lo que se har y
en lo que no se har. Obliga al manejo de
prioridades.

1.3.2 Desarrollo Evolutivo.


Desarrollo iterativo-evolutivo.
Los

requisitos, planes, estimaciones y


soluciones evolucionan o se refinan en el
transcurso de las iteraciones.
En lugar de ser completamente definidos
o congelados en un esfuerzo maysculo
de especificacin antes de que el
desarrollo iterativo empiece.
Los mtodos evolutivos son consistentes con
el patrn de descubrimiento y cambio no

1.3.2 Desarrollo Evolutivo.


Desarrollo adaptativo.
Es un trmino relacionado con evolutivo.
Implica que los elementos se adaptan en

respuesta al feedback del trabajo


anterior feedback de usuarios, testers,
desarrolladores, etc.
La

intencin es la misma que en el


desarrollo evolutivo, pero el nombre sugiere
un mecanismo ms fuerte de repuestafeedback en la evolucin.

1.3.2 Desarrollo Evolutivo.


Anlisis evolutivo de requisitos.
En el desarrollo evolutivo y adaptativo no

se trata de que los requisitos estn sin


lmite o cambiantes continuamente.

Al contrario, mucho del descubrimiento y

refinamiento ocurre durante las primeras


iteraciones.

La

atencin ms temprana es dada a


entender
los
requisitos
arquitectnicamente ms significativos

1.3.2 Desarrollo Evolutivo.


Planeacin evolutiva y adaptativa.
Igual que con los requisitos, la planeacin

adaptativa y evolutiva no se trata de que los


estimados y fechas se desconozcan por
siempre.
Esto es, debido a que los primeros
requisitos son muy cambiantes (y a otros
factores), existe una fase inicial de alto
nivel de incertidumbre, la cual declinar
conforme el tiempo avance y la informacin
se acumule.
Esto
ha sido llamado el cono de

1.3.2 Desarrollo Evolutivo.


Respuesta iterativa a la incertidumbre.
La respuesta iterativa a la incertidumbre es

postergar los estimados semi-confiables de


costo, esfuerzo o tiempo hasta que unas
pocas de las iteraciones han pasado.
Razonablemente un 10% o 20% del
proyecto.
Esto es consistente con otras prcticas

administrativas en otros dominios de


desarrollo de nuevos productos, donde es
comn una fase exploratoria inicial.

1.3.2 Desarrollo Evolutivo.


Respuesta iterativa a la incertidumbre.
An

ms, se motiva a la planeacin


adaptativa ms que a la planeacin
predictiva.

Es decir, una planificacin detallada no se

crea hasta que se ha avanzado ms all de


un breve tiempo, de tal manera que el nivel
de detalle y compromiso se consensa con la
calidad de la informacin.

1.3.2 Desarrollo Evolutivo.


Contratos de precio fijo.
Con respecto a hacer una oferta de precio fijo
y estimaciones evolutivas, algunos mtodos,
IID recomiendan realizar el proyecto en un
contrato de dos fases, cada uno de
mltiples iteraciones timeboxed.

1.3.2 Desarrollo Evolutivo.


Contrato de dos fases.
Primera fase:
Un contrato relativamente pequeo de

tiempo fijo
cumplirse
haciendo
parcial) de
requisitos.

y precio fijo, con el objetivo de


en unas cuantas iteraciones,
desarrollo
temprano
(pero
software y anlisis evolutivo de

El resultado de la fase incluyendo el software


base- se comparte con los clientes para el
contrato de precio fijo de la segunda fase.

1.3.2 Desarrollo Evolutivo.


Contrato de dos fases.
El
refinamiento
evolutivo
de
las
especificaciones y cdigo en la fase uno
ofrece datos de mayor calidad para los
estimadores de la fase dos y al mismo tiempo
ofrece avances del software.

1.3.2 Desarrollo Evolutivo.


Entrega Incremental.
Es la prctica de entregar repetidamente

un sistema a produccin (o al mercado)


en
una
serie
de
capacidades
extendidas. Es una prctica promovida por
los mtodos giles e IID.

Las entregas incrementales son en un rango

de 3 a 12 meses.

Esta prctica no debe confundirse con el

desarrollo iterativo. Un ciclo de entrega de 6


meses
podra
componerse
por
10

1.3.2 Desarrollo Evolutivo.


Entrega Evolutiva.
Es un refinamiento de la entrega

incremental.

Con la diferencia de que aqu existe un

inters muy marcado por obtener


feedback respecto al producto instalado
y usar este feedback para guiar la
siguiente entrega.

El objetivo es conocer necesidades

difciles de predecir.

1.3.3 Desarrollo gil.


Los mtodos giles aplican:
Desarrollo

evolutivo

iterativo

timeboxed.
Planeacin adaptativa.
Promueven entregas evolutivas.
Incluyen otros valores y prcticas que
motivan la agilidad-respuestas rpidas y
flexibles al cambio.
Su lema es: Enfrentar el cambio.
Su punto estratgico es: Maniobrabilidad

1.3.3 Desarrollo gil.


No es posible definir exactamente a los
mtodos giles, porque las prcticas varan.
Pero
las
siguientes
prcticas
compartidas por diversos mtodos:

son

Iteraciones pequeas timeboxed.


Refinamiento adaptativo y evolutivo

de planes y objetivos

1.3.3 Desarrollo gil.


Adems los mtodos giles promueven
prcticas y principios que reflejan una
sensacin de agilidad como: simplicidad,
ligereza,
comunicacin,
equipos
autodirigidos,
programacin
sobre
documentacin y ms.
Ejemplos de prcticas giles en Scrum son:
Un lugar comn para el proyecto.
Equipos auto-dirigidos que se coordinan a

travs de reuniones diarias con preguntas

1.3.3 Desarrollo gil.


Ejemplos de prcticas giles en XP son:
Usar notas concisas en papel (story cards)

para sumarizar requisitos.


Programar en parejas.
Trabajar
en un lugar comn con
participacin de tiempo completo de
proveedores de requisitos para que los
requisitos
escritos
puedan
complementarse
con
explicaciones
verbales.

1.3.3 Desarrollo gil.


Como concepto de proceso de software, gil
es ms nuevo que el enfoque iterativo.
Muchos mtodos IID (Evo o UP) no fueron

diseados como giles en su definicin


original, pero se pueden aplicar en un
espritu gil.

Aunque podramos imaginar mtodos IID nogiles, la mayora (por no decir todos) estn
adoptando los valores y prcticas giles es
raro que alguien promueva la no-agilidad.

1.3.3 Desarrollo gil.


Clasificacin
de
los
ceremonia y ciclos.

mtodos

por

1.3.3 Desarrollo gil.


Principios giles.
1. Nuestra ms alta prioridad es satisfacer

al cliente a travs de entregas continuas


y tempranas de software valuable.
2. Bienvenidos los cambios de requisitos
an en etapas posteriores al desarrollo.
Los procesos giles aprovechan el cambio
a favor de la ventaja competitiva del
cliente.
3. Entrega
frecuente
de
software
trabajando, desde pocas semanas hasta
pocos meses. Prefiera escalas breves de
tiempo.

1.3.3 Desarrollo gil.


Principios giles.
4. La

gente
del
negocio
y
los
desarrolladores deben trabajar en
conjunto
diariamente a lo largo del
proyecto.
5. Construye el proyecto con gente
motivada. Dales el ambiente y soporte
necesario y confa en que harn bien el
trabajo.
6. El mtodo ms eficiente y efectivo para
conllevar informacin hacia y dentro el
equipo de desarrollo es la conversacin
cara-a-cara.

1.3.3 Desarrollo gil.


Principios giles.
7. Software

trabajando es la medida
principal de progreso.
8. Los
procesos
giles
promueven
el
desarrollo sustentable.
9. Los
patrocinadores, desarrolladores y
usuarios deben mantener una paz
constante indefinidamente.
10. Atencin constante a la excelencia
tcnica y el buen diseo aumenta la
agilidad.

1.3.3 Desarrollo gil.


Principios giles.
11. Simplicidad-el

arte de maximizar el
monto de trabajo no hecho-es esencial.
12. Las mejores arquitecturas, requisitos y
diseos emergen a partir de equipos
auto-organizados.
13. A
intervalos
regulares,
el
equipo
reflexiona sobre como ser ms efectivo,
acorde
a
lo
cual
ajusta
su
comportamiento.

1.3.3 Desarrollo gil.


Mtodos giles especficos.
De acuerdo a una encuesta de Shine, XP y

Scrum son los mtodos


ampliamente utilizados.

giles

ms

Scrum:

su nfasis distintivo entre los


mtodos es su fuerte promocin a los
equipos auto-organizados, a la medicin
diaria de los equipos y el evitar seguir pasos
predefinidos.

XP:

es el mtodo gil ms conocido;


enfatiza la colaboracin, rpida y temprana

1.3.3 Desarrollo gil.


Mtodos giles especficos.
XP se fundamenta en 4 valores:
Comunicacin.
Simplicidad.
Retroalimentacin
Coraje o valor.

1.3.3 Desarrollo gil.


Modelado gil.
Es un conjunto de principios y prcticas

para el anlisis de requisitos y modelado


que complementa a muchos mtodos IID.
El Modelado gil promueve la creacin
colaborativa low-tech, high-touch con
modelos que ayuden ms al entendimiento
y la comunicacin.
Sus
prcticas
promueven
velocidad,
simplicidad y creatividad

1.3.3 Desarrollo gil.


Prcticas del Modelado gil.

1.4 El Framework del UP

Introduccin
Qu es Ingeniera de Software ?
El establecimiento y uso de principios de
ingeniera robustos, orientados a obtener software
econmico que sea fiable y funcione de manera
eficiente sobre mquinas reales. (Fritz Bauer 1969)
La ingeniera de software es la aplicacin de un
enfoque sistemtico, disciplinado y cuantificable al
desarrollo, operacin y mantenimiento del software.
[IEEE93]

Introduccin
Orientacin a Objetos
Vivimos en un mundo de objetos. Estos objetos
existen en la naturaleza, en entidades hechas por el
hombre, en los negocios y en los productos que
usamos.
Pueden
ser
clasificados,
descritos,
organizados, combinados, manipulados y creados.
Por eso no es sorprendente que se proponga una
visin orientada a objetos para la creacin de
software de computadora, una abstraccin que
modela el mundo de forma tal que nos ayuda a
entenderlo y gobernarlo mejor.

Introduccin
Orientacin a Objetos
El trmino orientado a objetos significa que el
software se organiza como una coleccin de objetos
que contienen tanto estructuras de datos como
comportamiento.

Introduccin
OBJETOS BICICLETA
Bicicleta
Se hace una
abstraccin
que resulta
en

Tam.del cuadro
Tam. De la
rueda marchas
material
Cambiar
marcha()
mover()
reparar()

Introduccin
Orientacin a Objetos
El atractivo intuitivo de la orientacin a objetos es
que proporciona conceptos y herramientas con las
cuales se modela y representa el mundo real tan
fielmente como sea posible. Estos conceptos y
herramientas orientados a objetos son tecnologas
que permiten que los problemas del mundo real
sean expresados de modo fcil y natural.

Introduccin
Programar es divertido, pero desarrollar software de
calidad es difcil.
Entre las ideas esplndidas, los requisitos y un
producto software funcionando, hay mucho ms que
slo programar:
Debemos realizar los planos (anlisis y diseo) que

definen cmo solucionar el problema para obtener


un producto software.
Definir el modelo arquitectnico
Aplicar la ingeniera de usabilidad.
Disear la Base de Datos
Etctera.

Introduccin
Qu es el anlisis?
Es el estudio de un dominio que da como resultado
los modelos que describen sus caractersticas
estticas y dinmicas. Se centra en las cuestiones
del que en lugar del como. Pone nfasis en una
investigacin del problema y los requisitos, en vez
de ponerlos en una solucin.
Anlisis es un trmino amplio, es ms adecuado
calificarlo como anlisis de requisitos (un estudio de
los requisitos) o anlisis de objetos (estudios de
objetos del dominio)
Qu es el anlisis orientado a objetos?
Es un mtodo de anlisis que examina los requisitos
desde la perspectiva de las clases y objetos que se

Introduccin
Anlisis Orientado a Objetos.
Se presta especial atencin a encontrar y
describir los objetos en el dominio del
problema. Ejemplos:
En el caso del sistema de renta de auto:

Auto, Cliente, Aseguradora, etc.


En el caso del sistema de la biblioteca:
Libro, Biblioteca, Socio
En el caso del sistema de vuelos:
Pasajeros, Aviones,

Introduccin
Diseo:
Pone nfasis en una solucin conceptual que satisface los

requisitos, en vez de ponerlo en la implementacin.


Diseo orientado a objetos:
Se presta especial atencin a la definicin de los objetos
software y en cmo colaboran para satisfacer los requisitos.
Ejemplos:

ESPACIO DE LA SOLUCIN

Objeto
LIBRO

Titul
o
GetCap(int
c)

Atribut
o
Operacin

Una habilidad crtica en el desarrollo OO es la asignacin inteligente de


responsabilidades a los objetos software

Introduccin
Anlisis y Diseo Orientado a Objetos.

Plane
tailNumber

domain concept

representation in an
object-oriented
programming language

visualization of
domain concept

public class Plane


{
private String tailNumber;
public List getFlightHistory() {...}
}

Introduccin
Anlisis y Diseo Orientado a Objetos.
El anlisis y diseo se han resumido en las
freses:
Hacer lo correcto
(anlisis)
Hacerlo correcto
(diseo)

Proceso de desarrollo de
software
Un proceso de desarrollo de software es un

conjunto de actividades necesarias para


transformar los requerimientos del usuario en
un sistema de software.

Requerimientos
del usuario

Proceso de Desarrollo de
Software

Sistema Software

Proceso de desarrollo de
software
Hoy en da la tendencia del software es hacia

sistemas ms grandes y complejos. Esta


tendencia tambin ha sido influenciada por el
extensivo uso del internet para intercambiar todo
tipo de informacin. Queremos software que est
mejor adaptado a nuestra necesidades, aunque
ste sea cada vez ms complejo. En resumen
queremos cada vez ms.

Tambin lo queremos ms rpido, el tiempo para

construirlo es otro factor importante. Nuestra


demanda de software complejo y poderoso no
concuerda con el cmo ser desarrollado dicho
software. Hoy en da, la gente desarrolla software
usando mtodos que fueron usados desde hace
35 aos.

Proceso de desarrollo de
software
La comunidad de desarrollo de software

necesita una manera de controlar el


trabajo. Se necesita un proceso que
integre las muchas facetas del desarrollo
de software.

Proceso de desarrollo de software


Necesitamos un mtodo comn, un proceso
que:
Proporcione una gua para el orden de las

actividades del equipo


Dirija las tareas de los desarrolladores
individualmente y del equipo como un
todo.
Especifique que artefactos deben ser
desarrollados
Ofrezca criterios para monitorear y medir
las actividades y productos de un
proyecto.

Unified Process (UP) Framework


La presencia de un proceso bien definido
y bien manejado es un discriminador
clave entre un proyecto productivo y
exitoso y uno que no lo es.
El proceso unificado, se ha convertido
en un proceso de desarrollo de software
de gran xito para la construccin de
sistemas orientados a objetos.

Unified Process (UP) Framework


El UP utiliza el lenguaje unificado para la

creacin de modelos (UML).

UML es una parte integral del Proceso

Unificado, fueron desarrollados a la par.

Los aspectos que realmente distinguen al

Proceso Unificado se capturan en tres


frases claves:
Conducido por casos de uso
Centrado en la arquitectura
Iterativo e incremental

El PU conducido por casos


de uso
Ejemplo: uso de un cajero automtico.

El usuario inserta una tarjeta, responde a las


preguntas que emite el cajero en su pantalla
y recibe una suma de efectivo.
En respuesta a la tarjeta del usuario y sus
preguntas, el sistema realiza una secuencia
de acciones
que provee al usuario un
resultado de valor, llamado retiro de fondos.
Una interaccin de este tipo es un caso de
uso.

El PU conducido por casos


de uso
Un caso de uso es una pieza de funcionalidad

en el sistema que da al usuario un resultado


de valor.
Los casos de uso capturan los requerimientos
funcionales.
Todos los casos de uso juntos, construyen el
modelo de casos de uso el cual describe la
funcionalidad completa del sistema.

El PU conducido por casos


de uso
Los casos de uso no solo son
una
herramienta
para
especificar
los
requerimientos de un sistema; tambin
conducen su :
Diseo,
Implementacin y,
Prueba.

Es decir:

Los casos de uso conducen el


proceso de desarrollo.

El PU centrado en la
arquitectura
El rol de la arquitectura del software

es similar en naturaleza al rol que juega la


arquitectura en la construccin de un
edificio.
El edificio es observado desde varios
puntos de vista: estructura, servicios,
electricidad, etc.
Similarmente,
la arquitectura en un
sistema de software se describe con
diferentes vistas del sistema que ser
construido.

El PU centrado en la
arquitectura
La arquitectura est influenciada por otros factores
tales como:
La plataforma sobre la cual se va a ejecutar el

sistema.
Bloques reusables disponibles.
Consideraciones de distribucin.
Sistemas
heredados
y
requerimientos
funcionales.

no

Requerimientos no funcionales: en la ingeniera de


software es un requerimiento que especifica criterios
que pueden usarse para juzgar la operacin de un
sistema en lugar de sus comportamientos
especficos, ya que stos corresponden a los
requerimientos funcionales.

El PU centrado en la
arquitectura
A un sistema se le puede pedir que muestre en tiempo
real la cantidad de datos de una base de datos: se es
un requerimiento funcional. En cunto tiempo debera
el sistema actualizar su verificacin interna de cantidad
de datos es, en cambio, un requerimiento no funcional.
Cmo se relacionan los casos de uso y la arquitectura?
Cada producto tiene funcin y forma. Uno o el otro no
es suficiente.
Estas dos fuerzas deben estar
balanceadas par obtener un producto exitoso. En este
caso la funcin corresponde a los casos de uso y la
forma a la arquitectura. Se necesita, por lo tanto, la
interaccin entre los casos de uso y la arquitectura.

El PU centrado en la
arquitectura
El arquitecto moldea el sistema en una

forma. Esa forma, la arquitectura, debe


ser diseada de manera tal, que permita
al sistema evolucionar, no solamente a
travs de su desarrollo inicial, sino a
travs de futuras generaciones.
Para encontrar tal forma, los arquitectos

deben tener un entendimiento general


de las funciones claves, esto es,
los
casos de uso claves del sistema.

El PU es iterativo e
incremental
Bajo

este enfoque, el desarrollo se


organiza en una serie de mini-proyectos
cortos, de duracin fija (por ejemplo,
cuatro semanas) llamados iteraciones.
El resultado de cada uno es un sistema
que puede ser probado, integrado y
ejecutado.
Cada
iteracin incluye sus propias
actividades de anlisis de requisitos,
diseo implementacin y pruebas.

El PU es iterativo e
incremental
El

ciclo de vida iterativo se basa en la


ampliacin y refinamiento sucesivos del
sistema mediante mltiples iteraciones, con
retroalimentacin cclica y adaptacin como
elementos principales que dirigen para
converger hacia un sistema adecuado.
El sistema crece incrementalmente a lo largo
del tiempo, iteracin tras iteracin, por eso se
dice que es iterativo e incremental.
Proceso Iterativo Incremental: se dice que un
proceso es iterativo incremental cuando en
cada iteracin de sus pasos se alcanza una
mayor cercania con los objetivos finales. Esto
es, se aade algo nuevo de valor en cada
iteracin.

Requisitos

Requisitos

Diseo

Diseo
Implementacin &
Prueba & Integracin & ms diseo

TIEMPO

Integracin final &


Pruebas de sistema

Implementacin &
Prueba & Integracin & ms diseo

La retroalimentacin
de la iteracin N
nos lleva a refinar
y adaptar los
requisitos y diseo
de la iteracin N+1.

Integracin final &


Pruebas de sistema

4 semanas (por ejemplo)


Se fija la duracin de
Las iteraciones

El sistema crece
de manera incremental

El PU es iterativo e
incremental
El resultado de cada iteracin es un sistema
ejecutable, pero incompleto; no est preparado
par ser
puesto en produccin. El sistema
estara listo despus de muchas iteraciones por
ejemplo, 10 o 15.
La salida de una iteracin no es un prototipo

experimental o desechable, y el desarrollo


iterativo no es prototipado.
Ms bien, la salida es un subconjunto con
calidad de produccin del sistema final.

El PU es iterativo e
incremental
Los desarrolladores basan la seleccin de lo
que ser desarrollado en cada iteracin
tomando en cuenta dos factores:
Primero: La iteracin trata con un grupo

de casos de uso que juntos amplan la


utilidad del producto, segn lo desarrollado
hasta ahora.
Segundo: La iteracin se ocupa de los
riesgos ms importantes.

Beneficios del desarrollo


iterativo
Mitigacin tan pronto como sea posible de los

riesgos altos (tcnicos,


usabilidad y dems).

requisitos,

objetivos,

Progreso visible en las primeras etapas.


Una temprana retroalimentacin, compromiso de

los usuarios y adaptacin que nos lleva a un


sistema refinado que se ajusta ms a las
necesidades reales del personal involucrado.

Gestin de la complejidad, el equipo no se ve

abrumado por la parlisis del anlisis o pasos


muy largos y complejos.

El conocimiento adquirido en una iteracin se

puede utilizar metdicamente para mejorar el


propio proceso de desarrollo, iteracin tras

EN RESUMEN
Los conceptos:
Dirigido por casos de uso.
Centrado en la arquitectura.
El desarrollo es iterativo e incremental.

Son igualmente importantes. La arquitectura


proporciona la estructura en la cual se gua el
trabajo en las iteraciones, mientras que los
casos de uso definen las metas y conducen el
trabajo de cada iteracin. El quitar una de
estas tres ideas reducira severamente el valor
del proceso unificado.

Las Fases del PU


Un proyecto con el PU organiza el trabajo y las
iteraciones en 4 fases fundamentales:
Inicio:

visin aproximada, anlisis del negocio,


estimaciones imprecisas de plazos y costos. Se
define la viabilidad del proyecto.
Elaboracin:
visin
refinada,
implementacin
iterativa del ncleo central de la arquitectura,
resolucin de los riesgos altos, identificacin de
ms requisitos y alcance, estimaciones ms
realistas.
Construccin: implementacin iterativa del resto de
requisitos de menor riesgo y elementos ms fciles,
preparacin para el despliegue.
Transicin: pruebas beta, despliegue.

Las Fases del PU


La fase de inicio NO es una fase de requisitos;
sino una especie de fase de viabilidad, donde
se lleva a cabo solo el estudio suficiente para
decidir si continuar o no.
La fase de elaboracin NO es la fase de
requisitos o de diseo, sino una fase donde se
implementa
de
manera
iterativa,
la
arquitectura, que constituye el ncleo central
y se mitigan las cuestiones de alto riesgo.

La vida del PU
Cada fase esta subdividida en iteraciones

Inicio
Iter.
#1

Elaboracin

Construccin

Iter.
# 2..

Transicin
Iter.
#n-1

versiones
Un ciclo con sus fases y sus iteraciones

Iter.
#n

The UP Disciplines
Process Disciplines

Phases

Inception Elaboration

Construction

Transition

Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment

Supporting Disciplines
Configuration Mgmt
Management
Environment

Preliminary
Iteration(s)

Iter.
#1

Iter.
#2

Iter.
#n

Iter. Iter.
#n+1 #n+2

Iterations

Iter.
#m

Iter.
#m+1

Disciplinas del PU (flujos de trabajo)


Informalmente

una disciplina es un
conjunto de actividades (y artefactos
relacionados) en un rea determinada
como las actividades en el anlisis de
requisitos.
En el PU, un artefacto es el trmino
general para cualquier producto del
trabajo: cdigo, grficos Web, esquema de
base de datos, documento de texto,
diagramas, modelos, etctera.
Nos
centraremos en 3 disciplinas:
modelado del negocio, requisitos y diseo.

Disciplinas del PU (flujos de trabajo)


Modelado del negocio

Una vez que los miembros del equipo de requisitos


se han familiarizado con el lenguaje, el siguiente
paso es:
construir el modelo del negocio inicial, que es una

descripcin de los procesos de una empresa (ejemplo: un


banco incluye aceptar depsitos de los clientes, conceder
prstamos a los clientes y hacer inversiones).

La razn para construir un modelo de negocios es


que proporciones una comprensin de los negocios
del cliente como un todo,
con este conocimiento es posible aconsejar al cliente

respecto de qu porciones del sistema de informacin


computarizar.

Disciplinas del PU

modelado del

negocio

Ejemplo: los procesos de negocios de una empresa


de servicios de banquetes incluyen:
comprar los ingredientes,
preparar los alimentos,
servir la comida

El proceso comprar ingredientes refinado


El encargado del servicio de banquetes ordena los
ingredientes a un mayorista
El mayorista entrega los ingredientes al encargado del
servicios de banquetes
El mayorista enva una factura al encargado de banquetes
El encargado de banquetes paga la factura

Disciplinas del PU

modelado del

negocio

Pueden usarse una serie de tcnicas para


obtener
informacin
necesaria
para
construir
el
modelo
de
negocios,
principalmente la entrevista.
Requisitos: anlisis de requisitos para la
aplicacin, escritura de casos de uso e
identificacin de requisitos no funcionales.

Disciplinas del PU

modelado del

negocio

El objetivo de esta disciplina es asegurar que los


desarrolladores
construyan
el
sistema
de
informacin correcto.
Esto se logra al describir el sistema de informacin
objetivo de una manera suficientemente clara y
precisa como para que los dos involucrados
principales (cliente y desarrolladores) puedan
ponerse de acuerdo en lo que debe y no debe hacer
el sistema de informacin.
Con el fin de lograr esto, lo requisitos tienen que
ser comprendidos por el cliente. Una manera de
lograrlo es usar el PU, porque sus diversos modelos
ayudan al cliente a obtener la comprensin
detallada necesaria de lo que se va a desarrollar.

Disciplinas del PU

modelado del

negocio

Anlisis.
El propsito de esta disciplina es examinar y refinar
los requisitos. Al hacerlo se logra la comprensin
detallada de los requisitos que deben tener para
desarrollar
correctamente
un
sistema
de
informacin y darle mantenimiento con facilidad.
por qu tener la disciplina de anlisis?
El punto clave es que los artefactos de la disciplina
de requisitos deben expresarse en el lenguaje del
cliente, es decir en un idioma natural (espaol,
ingls, armenio,), pero todos los lenguajes
naturales de alguna manera son imprecisos y
conducen a malas interpretaciones.

Disciplinas del PU

Anlisis

Ejemplo: Se tiene el siguiente requisito.


Un registro de partes y un registro de las planta
de fabricacin de las mismas se buscan en una
base de datos. Si el registro contiene la letra A
justo despus de la Q, entonces se calcula el costo
de transportar esa parte a la planta.
A primera vista ese requisito parece perfectamente
claro. Pero a qu se refiere el registro (registro
de partes o registro de plantas).
Con la disciplina de requisitos se formula en el
lenguaje del cliente y la disciplina de anlisis es un
lenguaje ms preciso que asegurar que las
disciplinas de diseo e implementacin se llevarn
a cabo correctamente.

Disciplinas del PU
Diseo.
En esta disciplina se refina los artefactos del
anlisis hasta que el material est en una
forma en que los programadores puedan
implementar.
Adems una serie de requisitos necesitan
familiarizarse en este momento, incluyendo
la eleccin del lenguaje de programacin,
as como la reutilizacin y los problemas de
portabilidad.

Disciplinas del PU
Implementacin.
El objetivo de esta disciplina es instaurar el
sistema de informacin deseado en el
lenguaje deseado.
En cuanto el componente se ha codificado,
el programador lo prueba, una vez que el
programador est seguro de que el
componente es correcto, se pasa al grupo
de aseguramiento de la calidad para una
prueba posterior.

Disciplinas del PU
Pruebas.
Esta disciplina es responsabilidad del grupo de
aseguramiento
de
la
calidad.
Cada
componente que se ha terminado se prueba, a
esto se le llama prueba de unidad.
Al final de cada iteracin se realiza la prueba
de integracin. Aqu los componentes que se
han completado y a los cuales se les han
aplicado las prueba de unidad, se compilan y
se ligan y luego se prueban con varios casos
de prueba.
Cuando el producto parece estar completo, se
prueba en conjunto: a esto se llama prueba de
producto.

Disciplinas y
modelos en el PU

Requerimientos
Modelo de
casos de uso
Anlisis
Modelo de
anlisis
Diseo

Modelo de
diseo

Modelo de
distribucin

Implementacin
Modelo de
implementacin
Prueba

Modelo de
pruebas

Buenas prcticas del PU adicionales


Lo fundamental para apreciar y aplicar el PU es el

desarrollo iterativo (fijando iteraciones cortas) y


adaptable.
Uso de tecnologas de objetos (A/DOO Y POO).
Abordar cuestiones de alto riesgo en las primeras
iteraciones.
Involucrar
continuamente a los usuarios para
evaluacin, retroalimentacin y requisitos.
Construir en las primeras iteraciones una arquitectura
que constituya un ncleo central consistente.
Verificar la calidad continuamente; pruebas muy
pronto, con frecuencia y realistas.
Aplicar casos de uso.
Modelar software visualmente (UML).
Gestionar los requisitos con cuidado.
Manejar
peticiones de cambio y gestin de