PROFESOR:

Tacubeo
EQUIPO:
Hernndez Amaro Jos Adalberto
Burgos Ortiz Edson Orlando
Ramrez Tllez Gerardo
Muoz Eduardo
MATERIA:
Ingeniera de Software
GRUPO:
4601
CARRERA:
Ing. En Sistemas Computacionales
SEMESTRE:
6

Tabla de contenido
Objetivos........................................................................................................ 3

Marco terico.................................................................................................. 4
UML............................................................................................................. 4
RESUMEN....................................................................................................... 5
UML................................................................................................................ 6
DIAGRAMA DE CASOS DE USO....................................................................6
SISTEMA......................................................................................................... 7
Casos de uso............................................................................................... 7
ACTORES..................................................................................................... 8
RELACIONES................................................................................................ 8
DIAGRAMAS DE SECUENCIAS.........................................................................9
ROL DE LA CLASE........................................................................................ 9
ACTIVACION................................................................................................. 9
MENSAJES.................................................................................................. 10
LINEAS DE VIDA......................................................................................... 11
DESTRUCCION DE OBJETOS......................................................................11
LOOPS....................................................................................................... 12
DIAGRAMAS DE CLASE................................................................................. 12
CLASE ABSTRACTA.................................................................................... 13
CLASE AVIONES......................................................................................... 13
ASOCIACIONES.......................................................................................... 14
MULTIPLICIDAD.......................................................................................... 14
ASOCIACION TRIPARTITA........................................................................... 15
COMPOSICION Y AGREGACION..................................................................15
Pres Servi Game........................................................................................ 16
1er DIAGRAMA DE CASO DE USO...................................................................18
DIAGRAMA DE SECUENCIA........................................................................20
2do DIAGRAMA DE CASO DE USO..................................................................21
DIAGRAMA DE SECUENCIA........................................................................23
er

3 DIAGRAMA DE CASO DE USO...................................................................24

DIAGRAMA DE SECUENCIA........................................................................25
Diagrama de estado....................................................................................... 26
Diagrama de paquetes................................................................................... 26
Punto de venta.............................................................................................. 27
Bibliografa................................................................................................... 28

Objetivos
Objetivo General:

 Realizar un sistema que permita tener un mayor control sobre los

productos.

Contar con la presencia de personal altamente capacitado para

poder aclarar las dudas del cliente
Aumentar el porcentaje de exportaciones
Incrementar la productividad
Alcanzar un mayor alcance a nivel nacional e internacional
Aumentar las ventas
Mantenerse actualizado al tanto de nuevos productos

Objetivo especfico:

El cliente evitara esperar largo tiempo en poder finalizar con su

compra

El cliente quedara satisfecho y tonalmente seguro de la compra a

realizar

Tener suficiente publicidad acerca de nuestro producto

Reducir los costos de nuestros paquetes

Expandir nuestros puntos de venta, abriendo ms sucursales

Aumentar las ventas anuales un 50%

El cliente podr disfrutar de los nuevos beneficios recin

actualizados

Duplicar la produccin para que no haya agotamiento de

productos.

Marco terico
UML
La creacin de algn sistema requiere de anlisis minucioso, pues de ello
depender el funcionamiento del mismo. Una mala planeacin en el anlisis
podra traer consecuencias desagradables.
Para efectuar el modelado de un sistema existen muchas herramientas, sin
embargo, grandes desarrolladores han unidos esfuerzos para unificar
criterios, estos criterios se hicieron convergentes desde la creacin de UML;
inicialmente, se puede pensar que UML es un lenguaje de programacin,
pero no es as, simplemente es una herramienta indispensable que permite
el modelado de un sistema en una descripcin muy general o muy
particular, segn el inters o la necesidad de detallarlo.
En este proyecto se realiz tanto el modelamiento como la implantacin del
sistema, pero, considerando que para que la implantacin se aproxime al
modelamiento inicial, es necesario que quien desarrolle el sistema en algn
lenguaje en particular, entienda los conceptos de UML, sus diagramas,
relaciones y elementos, ya que sin ese conocimiento previo es poco
probable una relacin intrnseca del modelo y sistema.
En UML a su vez, se puede detallar la estructura esttica y el
comportamiento dinmico de un sistema permitiendo tener vistas que
anteriormente no haba forma de especificarlas, ahora es posible con estos
diagramas, definir desde aspectos de interaccin de software y procesos
hasta la relacin existente entre el equipo perifrico. Es importante
mencionar que, un sistema se modela como una coleccin de objetos
discretos que interactan para realizar un trabajo que finalmente beneficie
al usuario final.
Los diagramas UML varan, as no es necesario que se utilicen todos los
diagramas para modelar un sistema, aun as entre los diagramas
recomendados para cualquier sistema fueron utilizados en este trabajo, son
los diagramas de clase y diagramas de caso de uso con sus respectivas
interacciones y adems para un sistema cliente-servidor, como es este el
caso, dependiendo de la complejidad del mismo.
El tiempo dedicado a la realizacin de los diagramas es proporcional al
tamao del producto a realizar, as en la realizacin del modelado es comn,
realizar diagramas y corregir, replantear sobre el sistema que es necesario,
aunque conforme se avanza en el modelado, las correcciones van siendo
mnimas, hasta llegar a lo representativo del sistema.

RESUMEN
En este manual se explica cmo poder resolver un diagrama de caso de uso
as como la importancia a lo que se basa cada uno de los siguientes
diagramas:
Diagrama de caso de uso
Diagrama de secuencia
Cada uno explicando la importancia para poder ponerlo en prctica dentro
de nuestra empresa, siguiendo paso a paso podemos llegar a la conclusin
de poder formar cada uno de nuestros diagramas con sus respectivos
actores.

UML
UML est compuesto por diversos elementos grficos que se combinan para
conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas
para combinar estos elementos. La finalidad de los diagramas es presentar
diversas perspectivas de un sistema, a las cuales se les conoce como modelo.
(Longman, 1998 )
El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y
diagramas estndar para modelar sistemas orientados a objetos, y describe la
semntica esencial de lo que estos diagramas y smbolos significan. Mientras
que ha habido muchas notaciones y mtodos usados para el diseo orientado
a objetos, ahora los modeladores slo tienen que aprender una nica notacin.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de
software, sistemas de hardware, y organizaciones del mundo real. (BOOCH,
2000)

DIAGRAMA DE CASOS DE USO

Los casos de uso son una tcnica para especificar el comportamiento de un
sistema:
Un caso de uso es una secuencia de interacciones entre un sistema y alguien
o algo que usa alguno de sus servicios.
Todo sistema de software ofrece a su entorno aquellos que lo usan una serie
de servicios. Un caso de uso es una forma de expresar cmo alguien o algo
externo a un sistema lo usa. Cuando decimos alguien o algo hacemos
referencia a que los sistemas son usados no slo por personas, sino tambin
por otros sistemas de hardware y software.
Por ejemplo, un sistema de ventas, si pretende tener xito, debe ofrecer un
servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario
accede a este servicio, podemos decir que est ejecutando el caso de uso
ingresando pedido. (Gutierrez, Abril 2011)

SISTEMA

El rectngulo representa los lmites del sistema que contiene los casos de uso.
Los actores se ubican fuera de los lmites del sistema.

Casos de uso

Se representan con valos. La etiqueta

sistema.

en el valo indica la funcin del

ACTORES

Los actores son los usuarios de un sistema.

Un actor puede ser cualquier cosa que se comunica (interacciona) con el
sistema y que es externo a l.
Los actores no necesariamente coinciden con los usuarios. Un usuario
puede interpretar distintos roles, correspondientes a distintos actores.
Los actores representan papeles (ROLES) que interpretan personas,
perifricos u otros sistemas cuando el sistema est en uso.
Un actor puede desempear distintos papeles dependiendo del caso de
uso en que participe.
Un actor representan un conjunto coherente de papeles que los usuarios
de una entidad (sistema, subsistema, clase) pueden desempear al
interaccionar con la misma.

RELACIONES

Las relaciones entre un actor y un caso de uso, se dibujan con una lnea
simple. Para relaciones entre casos de uso, se utilizan flechas etiquetadas
"incluir" o "extender." Una relacin "incluir" indica que un caso de uso es

necesitado por otro para poder cumplir una tarea. Una relacin "extender"
indica opciones alternativas para un cierto caso de uso. (Press, 1984)

DIAGRAMAS DE SECUENCIAS
Los diagramas de clases y los de objetos representan informacin esttica. En
un sistema funcional, los objetos interactan entre s, y estas interacciones
suceden con el tiempo. El diagrama de secuencias UML muestra la mecnica
de la interaccin con base en tiempos.
Los diagramas de secuencia es un elemento muy importante para el diagrama
de caso de uso se enfoca a los diferentes estados de un objeto esto es solo
una pequea parte del cuadro, establece el siguiente paso y le muestra la
forma en que los objetos se comunican entre s al transcurrir el tiempo.

ROL DE LA CLASE

El rol de la clase describe la manera en que un objeto se va a comportar en el

contexto. No se listan los atributos del objeto. (Soto, Octubre 2008)

ACTIVACION

Los cuadros de activacin representan el tiempo que un objeto necesita para

completar una tarea. (Soto, Octubre 2008)

MENSAJES
Un mensaje que va de un objeto a otro pasa de la lnea de vida de un objeto al
de otro. Un objeto puede enviarse un objeto a si mismo es decir de su lnea de
vida as propia lnea de vida.
Un mensaje puede ser simple, sncrono y asncrono

Mensaje simple: es la transferencia del control de un objeto a otro.

Mensaje sncrono: es cuando el objeto espera la respuesta a ese

mensaje antes de continuar con su trabajo.

Mensaje asncrono: es cuando el objeto no espera la respuesta a ese

mensaje antes de continuar.

Los mensajes son flechas que representan comunicaciones entre objetos. Las
medias flechas representan mensajes asincrnicos. Los mensajes asincrnicos
son enviados desde un objeto que no va a esperar una respuesta del receptor
para continuar con sus tareas. (Soto, Octubre 2008)

LINEAS DE VIDA
Las lneas de vida son verticales y en lnea de puntos, ellas indican la
presencia del objeto durante el tiempo.
Una lnea de vida representa un participante individual en un diagrama de
secuencia. Una lnea de vida usualmente tiene un rectngulo que contiene el
nombre del objeto. Si el nombre es self entonces eso indica que la lnea de vida
representa el clasificador que posee el diagrama de secuencia. (Gutierrez, Abril
2011)

DESTRUCCION DE OBJETOS
Los objetos pueden ser eliminados tempranamente usando una flecha
etiquetada "<<destruir>>" que apunta a una X.

LOOPS
Una repeticin o loop en un diagrama de secuencias, es representado como un
rectngulo. La condicin para abandonar el loop se coloca en la parte inferior
entre corchetes. (Pealvo, 1998)

DIAGRAMAS DE CLASE
Los diagramas de clases describen la estructura esttica de un sistema.
Las cosas que existen y que nos rodean se agrupan en categoras. Una clase
es una categora o grupo de cosas que tienen atributos (propiedades) y
acciones similares. Un ejemplo puede ser la clase Aviones que tiene atributos
como el modelo de avin, la cantidad de motores, la velocidad de crucero y
la capacidad de carga til. Entre las acciones de las cosas de esta clase se
encuentran: acelerar, elevarse, girar, descender, desacelerar.
Un rectngulo es el smbolo que representa a la clase, y se divide en tres
reas. Un diagrama de clases est formado por varios rectngulos de este tipo
conectados por lneas que representan las asociaciones o maneras en que las
clases se relacionan entre s. (Pealvo, 1998)

CLASE ABSTRACTA

Las clases se representan con rectngulos divididos en tres reas: la superior

contiene el nombre de la clase, la central contiene los atributos y la inferior las
acciones.

CLASE AVIONES

En el rea superior figura el nombre de la clase que utilizamos como

ejemplo, en la central estn sus atributos y en la inferior las acciones que
ella realiza. Las acciones llevan parntesis al final del nombre porque las
mismas son funciones y por lo tanto devuelven un valor.

ASOCIACIONES

Las asociaciones son las que representan a las relaciones estticas entre las
clases. El nombre de la asociacin va por sobre o por debajo de la lnea que la
representa. Una flecha rellena indica la direccin de la relacin. Los roles se
ubican cerca del final de una asociacin. Los roles representan la manera en
que dos clases se ven entre ellas. No es comn colocar los dos nombres, el de
la asociacin y el de los roles a la vez. Cuando una asociacin es calificada, el
smbolo correspondiente se coloca al final de la asociacin, contra la clase que
hace de calificador. (Longman, 1998 )

MULTIPLICIDAD

Las notaciones utilizadas para sealar la multiplicidad se colocan cerca del final
de una asociacin. Estos smbolos indican el nmero de instancias de una
clase vinculadas a una de las instancias de la otra clase. Por ejemplo, una
empresa puede tener uno o ms empleados, pero cada empleado trabaja para
una sola empresa solamente.

ASOCIACION TRIPARTITA

COMPOSICION Y AGREGACION

Composicin es un tipo especial de agregacin que denota una fuerte posesin

de la Clase Todo, a la Clase Parte. Se grafica con un rombo diamante
relleno contra la clase que representa el todo.
La agregacin es una relacin en la que la Clase Todo juega un rol ms
importante que la Clase "Parte", pero las dos clases no son dependientes una
de otra. Se grafica con un rombo diamante vaco contra la Clase Todo.
GENERALIZACION

Generalizacin es otro nombre para herencia. Se refiere a

una relacin entre dos clases en donde una Clase
Especfica es una versin especializada de la otra, o Clase
General. Por ejemplo, Honda es un tipo de auto, por lo que
la Clase Honda va a tener una relacin de generalizacin
con la Clase Auto.
(BOOCH, 2000)Solucin
DESARROLLO

Pres Servi Game

Nuestra empresa se encarga de la rentar de videojuegos que solo puede ser

usado teniendo internet, se puede usar en cualquier video juego que se pueda
conectar a internet y tambin se necesita de un disco para poder seleccionar
todos los juegos que ofrecemos.
Terminos y condiciones:

Se realiza un contrato de conformidad y acuerdo con el cliente.

El cliente al hacer el contrato con Pres Servi Game se le entrega un
aparato el cual contiene integrados juegos.
Ofrecemos diversos paquetes cada uno de ellos con distintos juegos.
Cada paquete contiene 40 juegos, si se desea otro juego que no se
encuentre en el paquete y quiere adquirirlo tiene que informarlo al
proveedor y por cada juego que se adquiera se debe pagar por
separado.
Los juegos pueden variar dependiendo del paquete que se contrate.
Cada corto tiempo los paquetes pueden actualizarse, esto depende de
los proveedores de los juegos.
La forma de pago depende del tipo de paquete que el cliente desee, esto
puede variar.
El pago es mensualmente, si esto no se hace conforme al contrato el
aparato es recogido al cliente, hasta que la deuda este liquidada el
cliente no podr obtener el servicio de Pres Servi Game.
Los pagos son el primer lunes de cada mes.
El primer mes de contrato es gratis solo se cobrara el trmite del
contrato.
Si se desea cancelar el servicio de Pres Servi Game solo tiene que
acudir a nosotros o llamar a nuestros telfonos y un ingeniero acudir a
su casa a cancelar el contrato y retirar el aparato que Pres Servi Game
le ofrece por nuestros servicios.

Tambien por medio de nuestro receptor que se les da al contratar uno de los
paquetes que ofrecemos, el receptor contiene controles, al igual que tambin
con sistema de prepago donde puedes pagar por adelantado cuando se acabe
tu crdito se saldr de nuestra pagina y podr volver a jugar si paga para otro
cierto tiempo, contamos con los mejores juegos de las marcas de Xbox y
playstation.

SERVI GAME
Nombre comercial: Pres Serv Game
460

Versin:

Especificacin del caso de uso: Centro de venta

Diciembre-2015

Fecha: 25-

Actor principal: Cliente

Producciones: Renta de videojuegos y Venta de codificador
Garantas de xito: Existencia de Videojuegos y codificador

1er DIAGRAMA DE CASO DE USO

VENTA DEL PRODUCTO

1.
2.
3.
4.
5.
6.
7.
8.

El cliente llega con su producto al punto de venta

El cajero inicia una nueva venta
Introducir el nmero y modelo del producto
Muestra la descripcin del producto y el precio
Calcula el monto del producto, importe, IVA, cantidad
Se registrar el monto total de los productos
Indicarle al cliente el monto a pagar
Se cobra la venta

Excepciones:
1. EL SISTEMA FALLA
a. El sistema intenta auto recuperarse
b. Reiniciar el equipo completo
c. Comunicarse con soporte tcnico
d. Esperar a que la falla sea completamente resuelta
2. REGISTRO DEL PRODUCTO
a) Comunicarse con soporte tcnico para poder activar el producto
b) No coincida el clave de producto con la descripcin
c) Comunicarse con soporte tcnico para solicitar otro cdigo con el
mismo precio incluido
d) Se llamara a un gerente en caso de que no se pueda activar el
producto

DIAGRAMA DE SECUENCIA

SERVI GAME
Nombre comercial: Pres Serv Game
460

Versin:

Especificacin del caso de uso: Centro de venta

Diciembre-2015

Fecha: 25-

Actor principal: Cliente

Producciones: Renta de videojuegos y Venta de codificador

Garantas de xito: Existencia de Videojuegos y codificador

2do DIAGRAMA DE CASO DE USO

VENTA DEL PRODUCTO

1.
2.
3.
4.
5.
6.
7.
8.
9.

El cliente ingresa a la pgina web de PressServiGame

El sistema despliega los productos con su precio
El cliente seleccionara su producto
Se agregara la compra al carrito
El sistema mostrar el monto del pedido, importe, IVA, cantidad
Mostrar la descripcin del pedido y precio total
Ya confirmado su pedido seleccionara la forma de pago
El sistema Indicara al cliente el monto total a pagar
El Cliente aceptara los trminos y condiciones para poder realizar
la compra

10. Si el cliente cuenta con tarjeta de crdito se realizara

satisfactoriamente la compra.
11. Se registra la compra

Excepciones:
3. EL SISTEMA FALLA
a.
b.
c.
d.
e.
f.
g.

El sistema intenta auto recuperarse.

Deber esperar el usuario a su total recuperacin.
En caso de seguir con la falla, llamar a soporte tcnico.
Se brindar asesora en caso de que la falla contine.
Se mandara un tcnico a revisar la falla ocasionada
Si la compra falla se revisaran inventarios de compra
Si dentro de la garanta falla el decodificador este ser repuesto o
reparado

4. El producto no tiene precio.

a. Llamar al centro de atencin a clientes para verificar el precio
9. El cliente no acepta las condiciones para poder realizar la compra
a) El cliente podr cancelar su producto o no lo registra
REGISTRO DEL PRODUCTO
e) Comunicarse con soporte tcnico para poder activar el producto
f) No coincida el clave de producto con la descripcin
g) Comunicarse con soporte tcnico para solicitar otro cdigo con el
mismo precio incluido
h) Se llamara a un gerente en caso de que no se pueda activar el
producto

10. El sistema no acepta la tarjeta para la compra.

a)
b)
c)
d)
e)

El nmero de cuenta no coincide con el nombre del titular

La tarjeta ha vencido
No cuenta con dinero disponible para la compra
Los datos de la tarjeta no son los correctos
El banco o la entidad emisora de la tarjeta ha rechazado el uso de
la misma
f) El pago ha sido denegado por el sistema de seguridad interno
g) Cada del sistema de la pgina web

DIAGRAMA DE SECUENCIA

SERVI GAME
Nombre comercial: Pres Serv Game

Versin: 460

Especificacin del caso de uso: Centro de venta

Diciembre-2015
Caso de uso: Paquetes

Fecha: 25Tcnico: Burgos

Actor principal: Cliente

Producciones: Renta de videojuegos y Venta de codificador
Garantas de xito: Existencia de Videojuegos y codificador

3er DIAGRAMA DE CASO DE USO

12345678-

El cliente llama al gerente para escoger su paquete.

El gerente describe cada paquete.
El cliente selecciona el paquete que desea adquirir.
El gerente confirma la seleccin del paquete obtenido por
el cliente.
El gerente le da el nip para ingresar en el codificador.
El cliente ingresa el nip en el codificador para
complementar el uso del paquete.
El cliente indica al gerente( el codificador acepto el nip)
Se termina la configuracin del paquete.

4.- El sistema se cae.

a) Cambios repentinos en el paquete seleccionado.
6.- El codificador no acepta el nip.
a) Reiniciar el equipo.
b) Comunicarle al gerente para proporcionar nuevo nip.

DIAGRAMA DE SECUENCIA

Punto de venta

Diagrama de

estado

Inicia

Analizand
Procesan

Procesan

Realizando

Introduccin

Procesan

Autorizan

Diagrama de paquetes

Servigame

html

php
Ventas

css

Punto de venta

Modelo cascada

El modelo de la cascada es uno de los primeros modelos empleados en el

desarrollo de software, se popularizo en 1970 por Winston Royce y an est
vigente en algunos desarrollos. ste modelo se define como una secuencia de
actividades a ser seguidas en orden, donde la estrategia principal es definir
y seguir el progreso del desarrollo de software hacia puntos de revisin bien
definidos, es decir, se codifica y reparan los errores; es un proceso continuo de
codificacin y reparacin.
Sus caractersticas principales son:
Es lineal
Las actividades estn relacionadas secuencialmente

 Cada etapa tiene una entrada y una salida

Es rgido y sistemtico: La entrada de una actividad es la salida de la
etapa anterior, por lo cual no se puede dar inicio a la siguiente fase.
Es monoltico: Existe una nica fecha de entrega.
La implementacin se pospone hasta que no se comprendan los
objetivos.
Los documentos a entregar rigen el proceso de software
Las fases que contempla el modelo de la cascada son al Anlisis
y especificacin de requerimientos, diseo, codificacin, integracin y
pruebas, liberacin y mantenimiento.

Su ciclo de vida abarca las siguientes actividades:

In

Ingeniera y Anlisis del Sistema:

Debido a que el software es siempre parten de un sistema mayor el trabajo
comienza estableciendo los requisitos de todos los elementos del sistema y
luego asignando algn subconjunto de estos requisitos al software.
Anlisis de los requisitos del software:
El proceso de recopilacin de los requisitos se centra e intensifica
especialmente en el software. El ingeniero de software (Analistas) debe
comprender el mbito de la informacin del software, as como la funcin, el
rendimiento y las interfaces requeridas.
Diseo:
El diseo del software se enfoca en cuatro atributos distintos del programa: la
estructura de los datos, la arquitectura del software, el detalle procedimental y
la caracterizacin de la interfaz. El proceso de diseo tradcelos requisitos en
una representacin del software con la calidad requerida antes de que
comience la codificacin.
Codificacin:
El diseo debe traducirse en una forma legible para la mquina. El paso de
codificacin realiza esta tarea. Si el diseo se realiza de una manera detallada
la codificacin puede realizarse mecnicamente.
Prueba:
Una vez que se ha generado el cdigo comienza la prueba del programa. La
prueba se centra en la lgica interna del software, y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los
resultados que realmente se requieren.
Verificacin:

Es la fase en donde el usuario final ejecuta el sistema, para ello el o los

programadores ya realizaron exhaustivas pruebas para comprobar que el
sistema no falle.
Mantenimiento:
El software sufrir cambios despus de que se entrega al cliente. Los cambios
ocurrirn debido a que hayan encontrado errores, a que el software deba
adaptarse a cambios del entorno externo (sistema operativo o dispositivos
perifricos), o debido a que el cliente requiera ampliaciones funcionales o del
rendimiento.

Herramientas que se utilizan para cada fase:

Anlisis de requisitos
Personal administrativo des el jefe hasta la persona de menor rango.
Diseo del Sistema
Arquitectura pura de donde se va trabaja teniendo dependencia a su vez del
hardware.
Diseo del Programa
Todo el hardware y el software que se usara para eldesarrollo del sistema
Codificacin
De igual manera el hardware y el software para desarrollar el programa
Pruebas
Personal capacitado para realizar las acciones del sistema.
Verificacin
Personal capacitado para verificar que todo est en orden.
Mantenimiento
Desarrolladores para la actualizacin y estabilidad del sistema.

Ventajas:

Permite la departamentalizacin y control de gestin.

El horario se establece con los plazos normalmente adecuados para
cada etapa de desarrollo.
Este proceso conduce a entregar el proyecto a tiempo.
Es sencilla y facilita la gestin de proyectos.
Permite tener bajo control el proyecto.
Limita la cantidad de interaccin entre equipos que se produce durante
el desarrollo.

Desventajas:

Los proyectos reales raramente siguen el flujo secuencial que propone el

modelo, siempre hay iteraciones y se crean problemas en la aplicacin
del paradigma.
Normalmente, es difcil para el cliente establecer explcitamente al
principio todos los requisitos. El ciclo de vida clsico lo requiere y tiene
dificultades en acomodar posibles incertidumbres que pueden existir al
comienzo de muchos productos.
El cliente debe tener paciencia. Hasta llegar a las etapas finales del
proyecto, no estar disponible una versin operativa del programa. Un
error importante no detectado hasta que el programa est funcionando
puede ser desastroso.
La ventaja de este mtodo radica en su sencillez ya que sigue los pasos
intuitivos necesarios a la hora de desarrollar el software.

El Modelo V tiende a ser muy relacionado con el Modelo de Cascada puesto

que es una evolucin del mismo.

Los planes de prueba son el nexo entre el desarrollo y la verificacin

OPERACION
Y MANTENIMIENTO

ANALISIS DE
REQUERIMIENTOS

Plan de Pruebas
de Aceptacin

PRUEBA DE
ACEPTACION

Validar requerimientos
DISEO
SISTEMA

Plan de Pruebas
del Sistema

PRUEBA
SISTEMA

Verificar diseo

DISEO
DETALLADO

Plan de Pruebas
de Integracin

PRUEBA DE
INTEGRACION

IMPLEMENTACION
DE PROGRAMAS Y
PRUEBA UNITARIA

Puede notarse que su primera mitad es similar al Modelo en Cascada, y la otra

mitad tiene como finalidad hacer pruebas e integracin asociado a cada una de
las etapas de la mitad anterior.

Se puede identificar una ventaja principal con respecto al Modelo Cascada ms

simple, y se refiere a que este modelo involucra chequeos de cada una de las
etapas del modelo de cascada.

CONCLUSIN

La aplicacin de la metodologa en cascada se orienta mejora el desarrollo de

proyectos de corto plazo, de poca innovacin y proyectos definitivos y
detallados. Para comenzar la aplicacin de la metodologa en cascada se
necesita tener el anlisis de los requerimientos bien definidos, el resultado del
desarrollo depender de que estos requerimientos sean los adecuados para
satisfacer la necesidad del proyecto. Se caracteriza por cumplir un orden
secuencial en el desarrollo de sus tareas esto implica retardar el avance del
proyecto ya que cada etapa inicia cuando haya finalizado la anterior siempre y
cuando se haya realizado la evaluacin respectiva y resuelto los errores en
caso de que los hubiera tenido. Los resultados del proyecto solo se pueden
conocer a partir de que se llegue a la aplicacin, hasta entonces el cliente
deber tener paciencia para esperar los resultados.

Ejemplo

Modelo en espiral
Las actividades de este modelo se conforman en una espiral, cada bucle
representa un conjunto de actividades. Las actividades no estn fijadas a priori,
sino que las siguientes se eligen en funcin del anlisis de riesgos,
comenzando por el bucle anterior. Boehm, autor de diversos artculos de
ingeniera del software; modelos de estimacin de esfuerzos y tiempo que se
consume en hacer productos software; y modelos de ciclo de vida, ide y
promulg un modelo desde un enfoque distinto al tradicional en Cascada: el
Modelo Evolutivo Espiral. Su modelo de ciclo de vida en espiral tiene en cuenta
fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello,
se comienza mirando las posibles alternativas de desarrollo, se opta por la de
riesgos ms asumibles y se hace un ciclo de la espiral. Si el cliente quiere
seguir haciendo mejoras en el software, se vuelven a evaluar las nuevas
alternativas y riesgos y se realiza otra vuelta de la espiral, as hasta que llegue
un momento en el que el producto software desarrollado sea aceptado y no
necesite seguir mejorndose con otro nuevo ciclo. Este modelo de desarrollo
combina las caractersticas del modelo de prototipos y el modelo en cascada.
El modelo en espiral est pensado para proyectos largos, caros y complicados.
Esto modelo no fue el primero en tratar el desarrollo iterativo, pero fue el primer
modelo en explicar las iteraciones. Este modelo fue propuesto por Boehm en
1988 en su artculo A Spiral Model of Software Development and
Enhancement. Bsicamente consiste en una serie de ciclos que se repiten en
forma de espiral, comenzando desde el centro. Se suele interpretar como que
dentro de cada ciclo de la espiral se sigue un modelo en cascada, pero no
necesariamente ha de ser as.
Este sistema es muy utilizado en proyectos grandes y complejos como puede
ser, por
Ejemplo, la creacin de un sistema operativo. Al ser un modelo de ciclo de vida
orientado a la gestin de riesgos se dice que uno de los aspectos
fundamentales de su xito radica en que el equipo que lo aplique tenga la
necesaria experiencia y habilidad para detectar y catalogar correctamente
riesgos.

Para cada ciclo habr cuatro actividades:

1. Determinar o fijar objetivos:

Fijar tambin los productos definidos a obtener: requerimientos,

especificacin, manual de usuario.
Fijar las restricciones
Identificacin de riesgos del proyecto y estrategias alternativas para
evitarlos
Hay una cosa que solo se hace una vez: planificacin inicial o previa

2. Anlisis del riesgo:

Se estudian todos los riesgos potenciales y se seleccionan una o varias
alternativas propuestas para reducir o eliminar los riesgos
3. Desarrollar, verificar y validar (probar):
Tareas de la actividad propia y de prueba
Anlisis de alternativas e identificacin de resolucin de riesgos
Dependiendo del resultado de la evaluacin de riesgos, se elige un
modelo para el desarrollo, que puede ser cualquiera de los otros
existentes, como formal, evolutivo, cascada, etc. As, por ejemplo, si los
riesgos de la interfaz de usuario son dominantes, un modelo de
desarrollo apropiado podra ser la construccin de prototipos evolutivos.
4. Planificar:
Revisamos todo lo que hemos hecho, evalundolo y con ello decidimos
si continuamos con las fases siguientes y planificamos la prxima
actividad. El proceso empieza en la posicin central. Desde all se
mueve en el sentido de las agujas del reloj.

Las cuatro regiones del grfico son:

La tarea de planificacin: para definir recursos, responsabilidades,
hitos y planificaciones
La tarea de determinacin de objetivos: para definir los requisitos y
las restricciones para el producto y definir las posibles alternativas
La tarea de anlisis de riesgos: para evaluar riesgos tanto tcnicos
como de gestin
La tarea de ingeniera: para disear e implementar uno o ms
prototipos o ejemplos de la aplicacin
Ventajas
El anlisis de riesgos se hace de forma explcita y clara. Une los mejores
elementos de los restantes modelos. Entre ellos:

Reduce riesgos del proyecto

Incorpora objetivos de calidad
Integra el desarrollo con el mantenimiento

Adems es posible tener en cuenta mejoras y nuevos requerimientos sin

romper con el modelo, ya que el ciclo de vida no es rgido ni esttico.
Mediante este modelo se produce software en etapas tempranas del ciclo de
vida y suele ser adecuado para proyectos largos de misin crtica.

Ejemplo
El objetivo
de este
de
La
idea es que
antes
este
sistema
es
de que el producto
mejorar
forma de
salga
a lalaventa,
juego
en
los
sacaremos un
videojuegos
y as
prototipo
para
que la
poder
dar
un
paso
gente que quiera
adelantenuestros
trayendo
adquirir
mejoras y

Si al cliente no le
El sistema intenta auto
interesa
nuestro
recuperarse
producto,

Reiniciar el equipo completo

simplemente
Comunicarse conse
soporte
anula
eltcnico
contrato y se

Esperar a que la falla sea

retiran
los aparatos de
completamente resuelta
Pres Servi Game

MODELO INCREMENTAL
El modelo incremental combina elementos del modelo lineal secuencial
(aplicados repetidamente) con la filosofa interactiva de construccin de
prototipos. Aplica secuencias lineales de forma escalonada mientras progresa
el tiempo en el calendario.
Es decir, bajo este modelo se entrega software por partes funcionales ms
pequeas, pero reutilizables, llamadas incrementos. En general cada
incremento se construye sobre aquel que ya fue entregado.

CARACTERISTICAS

Cada incremento agrega funcionalidad adicional o mejorada sobre el

sistema.
Cada etapa debe cumplir con los requisitos de las desarrolladas La
propuesta del modelo es disear sistemas que puedan entregarse por
piezas.
A partir de la evaluacin se planea el siguiente incremento y as
sucesivamente.
Es interactivo por naturaleza.
Es til cuando el personal no es suficiente para la implementacin
completa.
En lugar de entrega del sistema en una sola entrega, el desarrollo y la
entrega estn fracturados bajo incrementos, con cada incremento que
entrega parte dela funcionalidad requerida.

Los requerimientos del usuario se priorizan y los requerimientos de

prioridad ms altos son incluidos en los incrementos tempranos.
Hechos de incrementos tempranos como un prototipo, ayudan a obtener
requisitos para los incrementos ms tardos.
Los usuarios no tiene que esperar.
El desarrollo incremental es el proceso de construccin siempre
incrementando subconjuntos de requerimientos del sistema.
Se evitan proyectos largos y se entrega Algo de valor a los usuarios
con cierta frecuencia.

VENTAJAS

Los clientes no tienen que esperar hasta que el sistema se entregue

completamente para comenzar a hacer uso de l.
Los clientes pueden usar los incrementos iniciales como prototipo para
precisarlos requerimientos posteriores del sistema.
Minimizacin del riesgo de falla en el proyecto porque los errores se van
corrigiendo progresivamente.
El resultado puede ser muy positivo.

DESVENTAJAS

Difcil de aplicar a sistemas transaccionales que tienden a ser integrados

y a operar como un todo.
Riesgos largos y complejos.
Pueden aumentar el coste debido a las pruebas.
Los errores en los requisitos se detectan tarde.

Modelo en V
El modelo en v se desarroll para terminar con algunos de los problemas que
se vieron utilizando el enfoque de cascada tradicional. Los defectos estaban
siendo encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no
se introducan hasta el final del proyecto. El modelo en v dice que las pruebas
necesitan empezarse lo ms pronto posible en el ciclo de vida. Tambin
muestra que las pruebas no son slo una actividad basada en la ejecucin. Hay
una variedad de actividades que se han de realizar antes del fin de la fase de
codificacin. Estas actividades deberan ser llevadas a cabo en paralelo con las
actividades de desarrollo, y los tcnicos de pruebas necesitan trabajar con los
desarrolladores y analistas de negocio de tal forma que puedan realizar estas
actividades y tareas y producir una serie de entregables de pruebas. Los
productos de trabajo generados por los desarrolladores y analistas de negocio
durante el desarrollo son las bases de las pruebas en uno o ms niveles. El
modelo en v es un modelo que ilustra cmo las actividades de prueba
(verificacin y validacin) se pueden integrar en cada fase del ciclo de vida.
Dentro del modelo en v, las pruebas de validacin tienen lugar especialmente
durante las etapas tempranas, por ejemplo, revisando los requisitos de usuario
y despus por ejemplo, durante las pruebas de aceptacin de usuario. El
modelo en v es un proceso que representa la secuencia de pasos en el
desarrollo del ciclo de vida de un proyecto. Describe las actividades y
resultados que han de ser producidos durante el desarrollo del producto. La
parte izquierda de la v representa la descomposicin de los requisitos y la
creacin de las especificaciones del sistema. El lado derecho de la v
representa la integracin de partes y su verificacin. V significa Validacin y

Verificacin.

Realmente las etapas individuales del proceso pueden ser casi las mismas que
las del modelo en cascada. Sin embargo hay una gran diferencia. En vez de ir
para abajo de una forma lineal las fases del proceso vuelven hacia arriba tras la
fase de codificacin, formando una v. La razn de esto es que para cada una
de las fases de diseo se ha encontrado que hay un homlogo en las fases de
pruebas que se correlacionan.
Ventajas
Las ventajas que se pueden destacar de este modelo son las siguientes:
Es un modelo simple y fcil de utilizar.
En cada una de las fases hay entregables especficos.
Tiene una alta oportunidad de xito sobre el modelo en cascada debido
al desarrollo de planes de prueba en etapas tempranas del ciclo de vida.
Es un modelo que suele funcionar bien para proyectos pequeos donde
los requisitos son entendidos fcilmente.
Inconvenientes
Entre los inconvenientes y las crticas que se le hacen a este modelo estn las
siguientes:

Es un modelo muy rgido, como el modelo en cascada.

Tiene poca flexibilidad y ajustar el alcance es difcil y caro.
El software se desarrolla durante la fase de implementacin, por lo que
no se producen prototipos del software.
El modelo no proporciona caminos claros para problemas encontrados
durante las fases de pruebas

Modelo iterativo
Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir
el riesgo que surge entre las necesidades del usuario y el producto final por
malos entendidos durante la etapa de recogida de requisitos. Consiste en la
iteracin de varios ciclos de vida en cascada. Al final de cada iteracin se le
entrega al cliente una versin mejorada o con mayores funcionalidades del
producto. El cliente es quien despus de cada iteracin evala el producto y lo
corrige o propone mejoras. Estas iteraciones se repetirn hasta obtener un
producto que satisfaga las necesidades del cliente.

Este modelo se suele utilizar en proyectos en los que los requisitos no estn
claros por parte del usuario, por lo que se hace necesaria la creacin de
distintos prototipos para presentarlos y conseguir la conformidad del cliente.
Una de las principales ventajas que ofrece este modelo es que no hace falta
que los requisitos estn totalmente definidos al inicio del desarrollo, sino que se
pueden ir refinando en cada una de las iteraciones. Igual que otros modelos
similares tiene las ventajas propias de realizar el desarrollo en pequeos ciclos,
lo que permite gestionar mejor los riesgos, gestionar mejor las entregas
Inconvenientes
La primera de las ventajas que ofrece este modelo, el no ser necesario tener
los requisitos definidos desde el principio, puede verse tambin como un
inconveniente ya que pueden surgir problemas relacionados con la
arquitectura.

Bibliografa
Beluche, O. (2003). UML y patrones. Prentice Hall.
Bondaruk, C. (1996). Modelado y diseo orientado a objetos con aplicacion.
adison wesle.
BOOCH, G. (2000). MANUAL DE UML. Mexico: Rama.
Fonticelli, A. (1993). Ingenieria del sofware un enfoque practico. Pressman:
Manantial.
Gutierrez, D. (Abril 2011). Conocimientos de ingenieria de sofware. Brasil:
Hausse.
Longman, A. W. (1998 ).
Pealvo, G. (1998). Abya yala.
Press, Y. (1984). Importancia de la ingenieria. washinton: edebe.
Sipino, S. B. (2002). ingenieria de sofware, teoria y practica. Prentice Hall.
Soto, A. M. (Octubre 2008).

METODOLOGIA CASCADA
http://www.ptolomeo.unam.mx:8080/xmlui/bitstream/handle/132.248.52.100/175/A5%2
0Cap%C3%ADtulo%202.pdf?sequence=5

http://www.academia.edu/6362716/METODO_EN_CASCADA

http://librosweb.es/libro/tdd/capitulo_1/modelo_en_cascada.html

http://www.northware.mx/wp-content/uploads/2013/04/Desarrollo-cascada-vsDesarrollo-Agile.pdf

http://ele-mariamoliner.dyndns.org/~fperal/proy/ingenieriaSW.pdf