Proyecto Integrador

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

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.

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.

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

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.

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

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

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.

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]

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

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

(anlisis).

(anlisis).

(anlisis).
Modelo
de
escenarios.
anlisis
basado
en
Modelo funcional: casos de uso y
escenarios.
Modelo de Objetos: diagramas de clases y
objetos.

(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

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

(anlisis).

(anlisis).

(anlisis).

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

(anlisis).
Diagrama de Clases Conceptuales.

(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

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

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

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

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

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

(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

(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

(diseo).
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

(diseo).
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.

(diseo).
Mensajes.

(diseo).
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)

(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

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

(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

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

(diseo).
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

(diseo).
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

(diseo).

(diseo).
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

(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

(diseo).
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

(diseo).
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

(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

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

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.

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

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

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.

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

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.

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

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.


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.

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

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.

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

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

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.

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.

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.

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.

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.

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

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

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

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

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.

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.

Clasificacin
de
los
ceremonia y ciclos.
mtodos
por

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.

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.

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.

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.

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

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

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

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

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.

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

Proyecto Integrador - U1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Proyecto Integrador - U1

Загружено:

Авторское право:

Доступные форматы

1.1 Que es el anlisis y diseo

1.1 Que es el anlisis y diseo

1.1 Que es el anlisis y diseo

1.1 Que es el anlisis y diseo

1.1 Que es el anlisis y diseo

1.1 Que es el anlisis y diseo

1.1 Que es el anlisis y diseo

1.1 Que es el anlisis y diseo

identificacin de clases semnticas,

1.1 Que es el anlisis y diseo

Como resumen final, se podra afirmar que

1.2.1 El espacio del problema

1.2.1 El espacio del problema

del problema, no en la manera de definir la

1.2.1 El espacio del problema

sistema en lenguaje natural.

1.2.1 El espacio del problema

1.2.1 El espacio del problema

1.2.1 El espacio del problema

Modelo funcional: casos de uso y

1.2.1 El espacio del problema

punto de vista de un observador externo.

1.2.1 El espacio del problema

1.2.1 El espacio del problema

1.2.1 El espacio del problema

1.2.1 El espacio del problema

1.2.1 El espacio del problema

que usa el sistema.

1.2.1 El espacio del problema

1.2.1 El espacio del problema

1.2.1 El espacio del problema

1.2.1 El espacio del problema

1.2.1 El espacio del problema

1.2.1 El espacio del problema

desde el punto de vista de los actores.

(derivados de los requisitos no funcionales).

1.2.1 El espacio del problema

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

El DOO proporciona un mecanismo que permite

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

diseo ayuda al diseador a descomponer un problema en

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

Descripcin de la implementacin: Muestra

los detalles de cada una de las operaciones

1.2.2 El espacio de la solucin

descripcin de la interfaz son un

1.2.2 El espacio de la solucin

1.2.2 El espacio de la solucin

1.3.1 Desarrollo Iterativo.

1.3.1 Desarrollo Iterativo.