1

“AÑO DEL BICENTENARIO DEL PERÚ: 200 AÑOS DE

INDEPENDENCIA”

FACULTAD DE INGENIERÍA INDUSTRIAL

ESCUELA PROFESIONAL DE INGENIERÍA

INFORMÁTICA

CURSO: Ingeniería de Software

DOCENTE: Ing. Moisés David Saavedra Arango

TEMA: Metodología RUP

INTEGRANTES: Roque Zegarra Rigoberto Junior

Lizano Mejía Rosaly

Paiva Paiva Milagros Karina

Viera Vilcherrez Julio

PIURA – PERÚ

2021
 2

ÍNDICE

INTRODUCCIÓN 2

OBJETIVOS 2

REDACCIÓN DE LA METODOLOGÍA 2

CAPÍTULO I : DEFINICIÓN 2

CAPÍTULO II : OBJETIVOS 2

General 2

Específicos 2

CAPÍTULO III : FUNCIONAMIENTO 3

CAPÍTULO IV: PRINCIPIOS 3

Adaptar proceso: 3

Equilibrar Prioridades: 3

Demostrar Valor Iterativamente: 3

Colaboración entre equipos: 3

Elevar el nivel de abstracción: 3

APLICACIÓN DE LA METODOLOGÍA 4

MODELADO DE CASOS4

FUNCIONES DEL PRODUCTO 4

REQUERIMIENTOS FUNCIONALES 5

REQUERIMIENTOS NO FUNCIONALES 7
 3

ANEXOS 9

BIBLIOGRAFÍA 9

I.- INTRODUCCIÓN

Durante los últimos años, los mercados han logrado expandirse en todo el mundo a través de

una nueva modalidad del comercio que han empleado las empresas para ofertar sus productos y

servicios en línea conocido como “comercio electrónico”, el mismo que ha sido un elemento

clave para llevar a cabo sus negocios dentro y fuera del país. Por lo que se puede considerar al

comercio electrónico como una evolución de cambio debido a las necesidades que tiene la

sociedad y la inclusión de tecnología en comunicación e información que se fusionan para

revolucionar la manera en que las empresas realicen los negocios.

Así, con el pasar de los años el comercio electrónico se logró establecer como una

herramienta fundamental de las negociaciones, en el que las compras se mueven en un escenario

digital, donde los proveedores de bienes y servicios y consumidores finales tienen acceso y

transmisión mundial de la información, En el presente trabajo se decidió tomar a la empresa

“Clavijo” por los años que lleva posicionada en el mercado, siendo nacionalmente conocida en el

rubro de ventas de artículos electrónicos ,industriales, ferretería ,etc.; se le implementó una

solución de comercio electrónico permitiendo así la optimización en las ventas, integrando a la

empresa a la era digital y de esta manera expandir el negocio en los diversos escenarios

digitales, trayendo consigo cambios tecnológicos favorables para la empresa.

 4

II.-OBJETIVOS

Aplicación de la metodología RUP para el desarrollo rápido del sistema web.

III.-REDACCIÓN DE LA METODOLOGÍA

CAPÍTULO I: DEFINICIÓN

Como menciona [ CITATION Tec \l 3082 ]La metodología de desarrollo RUP

proporciona una forma estructurada para que las empresas visualicen la creación de

programas de software. Dado que proporciona un plan específico para cada paso del proceso

de desarrollo, ayuda a evitar el desperdicio de recursos y reduce los costos de desarrollo

inesperados.

Mientras que [ CITATION Uni06 \l 3082 ]“Su meta es asegurar la producción del software de

alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo

establecidos”.

Al final, el RUP trata de conjunto de pasos necesarios para el desarrollo y mantener gran

cantidad de sistemas en diferentes áreas de aplicación, para ayudar en la toma de decisiones.

CAPÍTULO II: OBJETIVOS

General

Diseñar y construir un sistema web para el negocio Clavijo, con la finalidad de que ésta

promueva y venda sus productos, a través de internet, y le permita llevar un control sobre los

productos, clientes y registro de los pedidos.

Específicos
 5

· Describir el funcionamiento de la metodología RUP, lenguaje UML

· Documentar el proyecto y su metodología.

· Mantener involucrado al cliente sobre el desarrollo del producto.

· Entregar el proyecto en el tiempo establecido.

CAPÍTULO III: FUNCIONAMIENTO

Según [ CITATION Uni15 \l 3082 ] “El nombre Proceso Unificado se usa para describir

el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los

refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado

de Rational o RUP son marcas registradas de IBM”.

Por lo tanto, su función es definir quien hace que, cuando y como de forma disciplinada

mediante tareas y responsabilidades en cada fase.

Ilustración 1: Funcionamiento RUP

CAPÍTULO IV: PRINCIPIOS

Los principios de la metodología RUP son diversos e importantes para hacer un buen uso

de esta metodología.

Según menciona [ CITATION Rub17 \l 3082 ]: “El RUP  está basado en  6 principios

clave que son:

 6

Adaptar el proceso

“El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante

interactuar con él. Las características propias del proyecto u organización”.

En este principio nos deja en claro que para poder aplicar la metodología RUP  se deberá

investigar las necesidades del cliente, del proyecto y organización, de sus características y por

supuesto su alcance.

Según [ CITATION Fer14 \l 3082 ] nos asisten con los demás principios:

Balancear Prioridades

“Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o

disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos”.

La idea mencionada anteriormente nos comunica que debe haber un balance entre los

requerimientos de todos los inversores.

Esto permite un desarrollo más ágil y profundo. 

Colaboración entre equipos 

“El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe

haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes,

resultados, etc. “

Tiene mucho sentido, y de esta forma, el desarrollo se hace más fácil y de forma paralela

se puede ir trabajando.

Demostrar valor iterativamente

 7

“Los proyectos se entregan, aunque sea de modo interno, en etapas iteradas. En cada

iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina

la dirección del proyecto así como también los riesgos involucrados. “

Esto nos quiere decir que el desarrollo del trabajo se hará en etapas, dando así a un

desarrollo más pausado.

Elevar el nivel de abstracción 

“Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del

software, lenguajes 4GL o frameworks por nombrar algunos. Estos se pueden acompañar por las

representaciones visuales de la arquitectura, por ejemplo con UML, el control de calidad no debe

realizarse al final de cada iteración, sino en todos los aspectos de la producción”

Esto nos dice que para poder aplicar RUP en un sistema, debemos abstraer conceptos de

arquitectura, y enfocarnos en la calidad desde el inicio de cada iteración.

CAPÍTULO V: FASES

Como menciona [ CITATION Blo12 \l 3082 ]”RUP divide el proceso en 4 fases, dentro

de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que

se hace un mayor o menor hincapié en los distintas actividades”.

En base de lo mencionado podemos definir las fases como aquellas oportunidades para

identificar actividades que permitan mejorar el proyecto.

 8

Ilustración 2: Fases de RUP

La duración y esfuerzo dedicado en cada fase es variable dependiendo de las características

del proyecto. Sin embargo, la Figura 3 ilustra porcentajes frecuentes al respecto. Consecuente

con el esfuerzo señalado, la Figura 4 ilustra una distribución típica de recursos humanos

necesarios a lo largo del proyecto.[ CITATION Rat \l 3082 ]

Ilustración 3: Distribución de esfuerzo y tiempo

Ilustración 4: Distribución de recursos humanos.

V.I.-Concepción
 9

“Esta fase tiene como propósito definir y acordar el alcance del proyecto con los

patrocinadores o alumnos de un proyecto en el cual tenemos que, identificar los riesgos

asociados al proyecto, proponer una visión muy general de la arquitectura de software y

producir el plan de las fases y el de iteraciones posteriores”.[ CITATION met17 \l 3082 ].

“Se define el alcance del proyecto con los clientes, se identifican los riesgos asociados al

proyecto, se elabora el plan de las fases y el de la iteración posterior, se detalla de manera

general la arquitectura del software”.[ CITATION Met14 \l 3082 ].

En síntesis, es la toma de conocimiento, en ésta fase se conoce realmente el negocio.

[Link].-Elaboración

“En la fase de elaboración se seleccionan los casos de uso que permiten definir la

arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los

casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la

solución preliminar”. [ CITATION met17 \l 3082 ].

“Se diseña la solución preliminar, se selecciona los casos de uso que permiten definir la

arquitectura base del sistema y se desarrollara el primer análisis del dominio del problema”.

[ CITATION Met14 \l 3082 ].

Lo mencionado nos dice que es aquí donde tomaremos conocimiento de los requerimientos,

de casos de usos, que es lo que nos ayuda o no.

[Link].-Construcción
 10

“El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben

clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones

realizados por los usuarios y se realizan las mejoras para el proyecto”. [ CITATION met17 \l

3082 ].

“La función de esta fase es completar la funcionalidad del sistema, se clarifican los

requisitos pendientes, se administran los cambios de acuerdo a las evaluaciones realizadas por

los usuarios, y se realizan las mejoras para el proyecto”.[ CITATION Met14 \l 3082 ].

Por lo tanto se comprende el diseño del sistema, cómo implementar y ejecución de pruebas.

Para mejoras en el proyecto.

[Link].-Transición

“El propósito de esta fase es asegurar que el software esté disponible para los usuarios

finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los

usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con

las especificaciones entregadas por las personas involucradas en el proyecto”.[ CITATION

met17 \l 3082 ].

“Fase de cierre, el propósito es asegurar que le software esté disponible para los usuarios

finales, se ajustan los errores y defectos encontrados en las pruebas de aceptación, se

capacitan a los usuarios y se provee el soporte necesario.”[ CITATION Met14 \l 3082 ].

En esta última fase es poner en marcha, ejecutar ya el software.

Pressman (2010) nos indica que esta fase incluye las últimas etapas de la actividad general de

construcción, entrega y retroalimentación. El software se entrega a los usuarios finales para

las pruebas beta, quienes tienen que reportar tanto los defectos como los cambios necesarios.
 11

Además, el equipo de software genera la información de apoyo tales como los manuales de

usuario, guías de solución de problemas, procedimientos de instalación, etc.

Fuente:[ CITATION
CAPÍTULO VI: CARACTERÍSTICAS DE LAMET17 \l 3082 ]
METODOLOGÍA RUP

Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado

por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como,

por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña

una persona en un determinado momento, una persona puede desempeñar distintos roles a lo

largo del proceso).

 Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y

cómo)
 Pretende implementar las mejores prácticas en Ingeniería de Software
 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelado visual del software
 Verificación de la calidad del software

Guiado/Manejado por casos de Usos

 12

Según menciona (Martínez, Martinez,2014) “Un caso de uso es una facilidad que el

software debe proveer a sus usuarios. “El caso de uso es el que especifica todos los escenarios

posibles para una parte de funcionalidad dada. Esto es fundamental para el desarrollo del

sistema porque constituyen una guía para las actividades que se realizan a lo largo de todo el

proyecto, ya sea el diseño, la implementación y las pruebas del sistema.

Centrado en Arquitectura

Según (Martínez, Martínez,2014) “La arquitectura involucra los elementos más

significativos del sistema y está influenciada entre otros por plataformas software, sistemas

operativos, manejadores de bases de datos, protocolos, consideraciones de desarrollo como

sistemas heredados y requerimientos no funcionales”

Según menciona (Cabrera,2018) “[...] RUP presta especial atención al establecimiento

temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios

posteriores durante la construcción y el mantenimiento ”, por lo que entonces podemos

concluir que este tipo de metodología, además de representar el sistema al que se va a

desarrollar, este siempre tiene cuidado especial los elementos de dicho sistema sus influencias

tales como plataformas software, sistemas operativos, manejadores de bases de datos, etc..

Interactivo e Incremental

(Martínez, Martínez,2014) “Para cada ciclo se establecen fases de referencia, cada una de

las cuales debe ser considerada como un mini proyecto cuyo núcleo fundamental está
 13

constituido por una o más iteraciones de las actividades principales básicas de cualquier

proceso de desarrollo”.

(Torossi,2004) menciona que “[...] Las iteraciones en las primeras fases tratan en su mayor

parte con la determinación del ámbito del proyecto, la eliminación de los riesgos críticos, y la

creación de la línea base de la arquitectura.” En concreto RUP divide el proceso en cuatro fases,

dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las

que se hace un mayor o menor hincapié en las distintas actividades.

CAPÍTULO VII: DISCIPLINAS DE LA METODOLOGÍA RUP

Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas

a un área específica dentro del proyecto total. Las más importantes son: Requerimientos,

Análisis, Diseño, Codificación, y Prueba. El agrupamiento de actividades en disciplinas es

principalmente una ayuda para comprender el proyecto desde la visión tradicional en

cascada”.

El Proceso Unificado consiste en una serie de disciplinas o flujos de trabajo que van

desde los requisitos hasta las pruebas. Los flujos de trabajo desarrollan modelos desde el

modelo de casos de uso hasta el modelo de pruebas.

Disciplinas Modelos
Requisitos Modelo de Casos de Usos
Análisis Modelo de Análisis
Diseño Modelo de Diseño – Modelo de Despliegue
Implementación Modelo de Implementación
Prueba Modelo de Prueba
 14

Por otro lado algunos autores como en el caso de (……….). Considera estas disciplinas en la
Metodología Rup.

Modelado de Negocios

Los propósitos que tiene el Modelo de Negocios son:

 Entender los problemas que la organización desea solucionar e identificar mejoras

potenciales.
 Medir el impacto del cambio Organizacional.
 Asegurar que clientes, usuarios finales, desarrolladores y los otros participantes tengan
un entendimiento compartido del problema.
 Derivar los requerimientos del sistema de Software, necesarios para dar soporte a los
objetivos de la organización.

Requerimientos
Esta disciplina tiene el propósito de:

 Establecer y mantener un acuerdo con los clientes y los otros interesados acerca de que
debe hacer el sistema.
 Proveer a los desarrolladores del sistema de un mejor entendimiento de los
requerimientos del sistema.
 Definir los límites (o delimitar) del sistema.
 Proveer una base para la planeación de los contenidos técnicos de las iteraciones.
 Proveer una base para la estimación de costo y tiempo necesarios para desarrollar el
sistema.
 Definir una interfaz de usuario para el sistema, enfocada en las necesidades y objetivos
del usuario.

Análisis y Diseño

 El propósito del Análisis y Diseño es:

 15

 Transformar los requerimientos a diseños del sistema.

 Desarrollar una arquitectura robusta para el sistema.

 Adaptar el diseño para hacerlo corresponder con el ambiente de implementación y

ajustarla para un desempeño esperado.

Implementación

 El propósito de la implementación es:

 Definir la organización del código, en términos de la implementación de los

subsistemas organizados en capas.

 Implementar el diseño de elementos en términos de los elementos (archivos fuentes,

binarios, ejecutables y otros)

 Probar los componentes desarrollados como unidades.

 Integrar los resultados individuales en un sistema ejecutable.

Pruebas

Actúa como un proveedor de servicios a las otras disciplinas en muchos aspectos. Se

enfoca principalmente en la evaluación y aseguramiento de la calidad del producto,
desarrollado a través de las siguientes practicas:

 Encontrar fallas de calidad en el Software y documentarlas.

 Recomendar sobre la calidad percibida en el Software.
 Validar y probar las suposiciones hechas durante el diseño y la especificación de
requerimientos de forma concreta.
 Validar que el Software trabaja como fue diseñado.
 Validar que los requerimientos son implementados apropiadamente.
 16

Transición

Esta disciplina describe las actividades asociadas con el aseguramiento de la entrega

disponibilidad del producto de Software hacía el usuario final.

Administración y Configuración del Cambio

Consiste en controlar los cambios y mantener la integridad de los productos que incluye el
proyecto:
 Identificar los elementos configurables.
 Restringir los cambios en los elementos configurables.
 Auditar los cambios hechos a estos elementos.
 Definir y mantener las configuraciones de estos elementos.

Los métodos, procesos y herramientas usadas para proveer la administración y configuración

del cambio pueden ser considerados como el sistema de administración de la configuración.

Administración de Proyectos

 El propósito de la administración de proyectos es:

 Proveer un marco de trabajo para administración los proyectos intensivos de Software.
 Proveer guías prácticas para la planeación, soporte, ejecución y monitoreo de
proyectos.
 Proveer un marco de trabajo para la administración del riesgo.

Ambiente

Se enfoca en las actividades necesarias para configurar el proceso al proyecto.

 17

 Describe las actividades requeridas para desarrollar las líneas guías de apoyo al
proyecto.
 El propósito de las actividades de ambiente es proveer a las organizaciones de
desarrollo de Software del ambiente necesario (herramientas y procesos) que den
soporte al equipo de desarrollo.

CAPÍTULO VII: ROLES DE LA METODOLOGÍA RUP

Dentro de esta metodología se presentan varios roles en el proceso de desarrollo y sus

fases. Se agrupan en 5 grandes categorías, y cada una de ellas le comprende varios sub-roles

con sus respectivas asignaciones.

Analistas

Como su nombre lo dice, analizan el proyecto, estableciendo los requerimientos, el

sistema y el modelo del negocio. Son los encargados de definir el proyecto o producto y

los recursos a utilizar.

 Analista de procesos de negocio.

 Diseñador del negocio.
 Analista de sistema.
 Especificador de requisitos.

Desarrolladores

Este rol se encarga de diseñar y desarrollar el software, se comienza a trabajar en el

proyecto y escribir el código utilizando la información previamente proporcionada por

los analistas.

 Arquitecto de software
 Diseñador
 Diseñador de IU
 18

 Diseñador de cápsulas
 Diseñador de base de datos
 Implementador
 Integrador

Gestores

Son los encargados de administrar, supervisar y controlar el análisis, desarrollo y pruebas

del proyecto. Estos deciden los cambios a implementarse en el software y la realización de
pruebas.
 Jefe de proyecto
 Jefe de control de cambios
 Jefe de configuración
 Jefe de pruebas
 Jefe de despliegue
 Ingeniero de procesos
 Revisor de gestión del proyecto
 Gestor de pruebas

Apoyo

Sirven como utilidad para el desarrollo y complementación del proyecto de software.

 Documentador técnico
 Administrador de sistema
 Especialista en herramientas
 Desarrollador de cursos
 Artista gráfico

Pruebas
 19

Categoría que comprende la verificación y prueba del software, declarando los puntos
a reparar o mejorar.

 Especialista en pruebas (tester)

 Analista de pruebas
 Diseñador de pruebas
Otros roles

No son necesariamente importantes, pero toman un papel considerable en la

planeación, desarrollo y distribución del software.

 Stakeholders
 Revisor
 Coordinación de revisiones
 Revisor técnico
 Cualquier rol

CAPÍTULO VII: VENTAJAS DE LA METODOLOGÍA RUP

El RUP mejora la productividad del equipo ya que permite que cada miembro del grupo

sin importar “su responsabilidad específica pueda acceder a la misma base de datos

incluyendo sus conocimientos. Esto hace que todos compartan el mismo lenguaje, la misma

visión y el mismo proceso acerca de cómo desarrollar un software”[CITATION MET12 \l

3082 ].

La metodología RUP es adaptable a cualquier proyecto

El diseño ascendente se realiza a partir de la agrupación de clases ya identificadas. Se

proponen subsistemas que empaquetan clases en unidades claramente definidas. El diseño

descendente, implica la definición previa por parte del arquitecto de los subsistemas de más

alto nivel[CITATION Tor \p 14 \l 3082 ].

 20

Tiene una visualización muy gráfica del proyecto y se realiza incrementalmente

Las fases de elaboración y construcción se orientan al desarrollo de la arquitectura y para cada

iteración se selecciona algunos Casos de Uso y se refina el análisis y diseño además se

procede a su implementación y pruebas[CITATION Lop15 \p 8 \l 3082 ] .

Garantiza la calidad del producto final

Un punto álgido es la dura crítica a estas metodologías debido al tiempo destinado en la

construcción del software y a la excesiva documentación empleada en la misma. Esto sucede

sobre todo en el caso de RUP, pues ha sido una de las más utilizadas en todo el orbe durante

varios años antes de la aparición de las hoy reconocidas metodologías ágiles.[CITATION

Uni16 \l 3082 ]

Se basa en las mejores prácticas de software.

CAPÍTULO VII: DESVENTAJAS DE LA METODOLOGÍA RUP

Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se

procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se

realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del

producto[ CITATION ElP18 \l 3082 ].

Para proyectos pequeños puede ser muy pesado y complicado

Cuando uno busca información acerca de RUP, descubre que se caracteriza por ser

iterativo e incremental, estar basado en componentes, tener una real detección de riesgos de

manera temprana y efectiva debido al alto grado de retroalimentación y

reutilización[ CITATION Uni16 \l 3082 ]

Se requiere conocimiento previo UML

 21

IV.-APLICACIÓN DE LA METODOLOGÍA

IV.I.-modelado de negocio de un comercio electrónico

En este apartado definiremos que hace el sistema, sus funciones a implementar y los
actores de cada función.
IV.I.I.- ¿Qué hace el sistema?

El sistema consiste en que el usuario interactúe con la tienda virtual, ya sea visualizar,

comprar ingresar, eliminar, productos según el tipo de usuario registrado.

IV.I.I.- ¿Qué genera el sistema?

El sistema genera una interacción dinámica, que el cliente pueda realizar sus pedidos las 24

horas del día en cualquier momento sin disponer de algún vendedor o representante.

IV.I.I.- ¿Qué funciones cumplirá el sistema?

El sistema funciona en un servidor web y está compuesta por módulos para cada tipo de
usuario, como los siguientes:

Tienda virtual: Toda persona que ingrese a la web, visualiza los productos disponibles,
gestionar carrito de pedido y registrarse.

Cliente registrado: Aquellos clientes registrados en el sistema tienen acceso a los pedidos
que han realizado, ver los detalles del producto, realizar su pedido.

Administración: Administra todo el sistema, tendrá acceso a visualizar todos los pedidos
hechos por los clientes, podrá imprimir dicho reporte, administrar productos, usuarios,
proveedores, categorías.

IV.I.I.-Especificaciones de casos de usos

 22

CASO DE USO DE CLIENTE Y CLIENTE REGISTRADO

 23

CASO DE USO 1 Navegar por la pá gina web

ACTORES Cliente y Cliente Registrado.
DESCRIPCIÓ N Este caso de uso les permite a los
usuarios navegar por los diferentes
ítems del sistema.
PRECONDICIONES
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Usuario ingresa a la pá gina web 2.-El sistema muestra contenido e
[Link] ítems como Inicio, Productos,
Administració n, Carrito, Cuenta.
POST CONDICIONES

CASO ALTERNO:
 24

CASO DE USO DE CLIENTE REGISTRADO.

CASO DE USO 2 Iniciar sesió n

ACTORES Cliente registrado.
DESCRIPCIÓ N Este C.U. permite que cada usuario
inicie sesió n y tenga un acceso a
funciones predeterminadas.
PRECONDICIONES Estar anteriormente registrados
para poder ingresar.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Usuario ingresa a la pá gina web. 2.-El sistema muestra contenido e
ítems como Inicio, Productos, Carrito,
Cuenta.
3.-Selecciona opció n cuenta. 4.-Despliega un formulario con los
ítems “iniciar sesió n” o “registrarse”.
5.-Seleccionar “iniciar sesió n” e 6.-Verifica datos de usuario.
ingresa nombre, contraseñ a y tipo de
usuario. Luego clic en “Iniciar sesió n ”
7.-Permite el acceso del usuario.
POST CONDICIONES El usuario registrado ingresa a sus
respectivas funciones.

CASO ALTERNO:
Datos incorrectos o no vá lidos
El sistema en el punto 6 arroja un mensaje “Su nombre y contraseñ a no
coinciden” y retoma el punto 5. Registrar usuario.
 25

CASO DE USO DE CLIENTE Y CLIENTE REGISTRADO

CASO DE USO 3 Visualizar productos

ACTORES Cliente y cliente registrado.
DESCRIPCIÓ N Este caso de uso les permite a los
clientes ver los productos y precios
ingresados por el administrador del
sistema.
PRECONDICIONES El cliente debe seleccionar el ítem
de productos en el menú principal, se
despliega una lista de productos
destacados del sistema.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Usuario ingresa a la pá gina web. 2.-El sistema muestra contenido e
ítems como Inicio, Productos, Carrito,
Administració n, Cuenta.
3.-Selecciona el ítem de Productos 4.-Despliega contenido como ítems
 26

en el menú principal. de productos y categorías.

5.- Selecciona la categoría. 6.-Despliega una lista de productos
disponibles junto con sus respectiva
categoría.
POST CONDICIONES Muestra los productos destacados o
productos ligados a una categoría
especifica.
CASO ALTERNO:

CASO DE USO DE CLIENTE Y CLIENTE REGISTRADO

 27

CASO DE USO 4 Gestionar Carrito

ACTORES Cliente y cliente registrado.
DESCRIPCIÓ N Este caso de uso les permite a los
clientes seleccionar productos y
agregarlos al carrito de pedidos con
opció n de vaciar todo su carro de
pedidos.
PRECONDICIONES El cliente debe seleccionar elegir el
botó n “Añ adir” ubicado en la parte
inferior de la descripció n de cada
producto.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Usuario ingresa a la pá gina web. 2.- El sistema muestra contenido e
ítems como Inicio, Productos, Carrito,
Administració n, Cuenta.
3.-Selecciona el ítem de Productos 4.- Despliega contenido como ítems
en el menú principal. de productos y categorías.
5.-Escoge el producto a agregar y 6.- Muestra una tabla de los
clic “añ adir”. productos escogidos. Nombre, Precio,
cantidad.
7.-Escoge la cantidad que requiera 8.- El sistema aumenta o disminuye
haciendo clic en el símbolo “+”, “-” la cantidad del producto seleccionado.
POST CONDICIONES Muestra los productos
seleccionados por el usuario con la
posibilidad de eliminarlos o agregar
má s productos y realizar el pedido.

CASO ALTERNO:

CASO DE USO DE CLIENTE Y CLIENTE REGISTRADO

 28

CASO DE USO 4.1 Eliminar carrito

ACTORES Cliente y cliente registrado.
DESCRIPCIÓ N Este caso de uso les permite a los
clientes y clientes registrados vaciar el
carrito de pedidos.
PRECONDICIONES El carrito de pedidos debe tener
productos agregados para poder poner
el carrito de compras en 0.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Usuario ingresa a la pá gina web. 2.- El sistema muestra contenido e
ítems como Inicio, Productos, Carrito,
Cuenta.
3.-Selecciona el ítem de producto en 4.-Despliega una lista de productos
el menú principal. disponibles.
5.-Escoge el producto a agregar, y 6.- Muestra un listado de los
clic “añ adir”. productos escogidos.
7.-Selecciona el producto y clic 8.-Elimina el producto seleccionado.
botó n con la imagen de una tacho de O Vacía completamente el carrito.
basura. O vacía totalmente el carrito
haciendo clic “Vaciar carrito”.
POST CONDICIONES Deja sin productos el carrito de
compras.

CASO ALTERNO:
 29

CASO DE USO DE CLIENTE

CASO DE USO 5 Registrar usuario

ACTORES Cliente
DESCRIPCIÓ N Este caso de uso les permite a los
clientes registrarse en el sistema para
poder realizar el pedido de sus
productos o ser un cliente registrado
en el sistema.
PRECONDICIONES
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Usuario ingresa a la pá gina web. 2.- El sistema muestra contenido e
ítems como Inicio, Productos, Carrito,
Administració n, Cuenta.
3.-Despues de seleccionar el 4.-Muestra mensaje de “debe
producto a pedir y la cantidad, hace registrarse para esta operació n”
 30

clic en “confirmar pedido”

.4.-Clic en la opció n “Cuenta”. 5.-Despliega ítems “iniciar sesió n” o
“registrarse”.
6.-Seleccionar “registrarse”. 7.- Despliega un formulario.
8.-Ingresa datos (Nombre, nombre
usuario, contraseñ a, sus nombres,
apellidos, email, etc.).
9.-Click en “registrarse”. 10.- Muestra mensaje “usuario
registrado”.
POST CONDICIONES Pedido realizado.

CASO ALTERNO:
Datos no completos
El usuario debe ingresar todos los campos del formulario, si no los ingresa lo
devuelve al punto 8.

CASO DE USO DE CLIENTE REGISTRADO.

 31

CASO DE USO 6 Realizar Pedido.

ACTORES Cliente Registrado.
DESCRIPCIÓ N Este caso de uso les permite a los
clientes registrados ver los productos
ingresados por el administrador del
sistema y que su estado es disponible.
PRECONDICIONES El cliente debe estar registrado para
poder iniciar sesió n y realizar su
compra.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.- Selecciona el ítem de producto en 2.- Despliega una lista de productos
el menú principal disponibles.
3.-Agregar productos al carrito. 4- Despliega tabla de productos
adquiridos por el usuario.
6.-Oprime en el botó n “Confirmar 7.-Muestra ventana que solicita
pedido”. datos de usuario.
7.-Ingresa datos del cliente.
8.-Selecciona botó n “registrar” 9.-Valida datos.
10.-“Registro exitoso”.
POST CONDICIONES Se realiza el pedido de los
productos.

CASO ALTERNO:

Datos incorrectos o no vá lidos

El sistema en el punto 9 arroja un mensaje “Su nombre, contraseñ a y/o tipo
de usuario no coinciden” y retoma el punto 7. Registrar usuario.
 32

CASO DE USO DE CLIENTE REGISTRADO

CASO DE USO 6.1 Registrar Pago

ACTORES Cliente Registrado.
DESCRIPCIÓ N Este caso de uso permite a los
clientes registrados ingresar datos del
medio de pago.
PRECONDICIONES El cliente debe estar registrado para
poder iniciar sesió n.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Confirma pedido del producto. 2.-Verifica datos.
3-Muestra formulario de pago.
4.- Ingresa datos solicitados.
5.- Clic en botó n “pagar ahora”. 6.-Validad datos.
7.-Muestra mensaje de confirmació n
de pedido.
8.-Envia reporte de pedido al correo
del usuario.
POST CONDICIONES El cliente registrado ha realizado
con éxito su compra.

CASO ALTERNO:

Datos incorrectos o no vá lidos

El sistema en el punto 6 arroja un mensaje “datos erró neos” y retoma el punto
4.
 33

CASO DE USO DE ADMINISTRADOR.

CASO DE USO 7 Navegar por la pá gina web

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso le permite al
usuario navegar por los diferentes
ítems del sistema.
PRECONDICIONES
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Usuario ingresa a la pá gina web 2.-El sistema muestra contenido e
[Link] ítems como Inicio, Productos, Carrito,
Cuenta.
POST CONDICIONES
CASO ALTERNO
 34

CASO DE USO DE ADMINISTRADOR.

CASO DE USO 8 Iniciar sesió n

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso permite que cada
usuario inicie su sesió n y tenga acceso
a las funciones predeterminadas de él.
PRECONDICIONES Estar anteriormente registrados
para poder ingresar.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Usuario ingresa a la pá gina web. 2.- El sistema muestra contenido e
ítems como Inicio, Productos, Carrito,
Cuenta.
3.-Selecciona opció n de Cuenta 4.-Despliega un formulario para
ingresar nombre y contraseñ a.
5.-Ingresa nombre, contraseñ a y 6.-Verifica datos del administrador.
tipo de usuario. Clic en “Iniciar Sesió n”.
7.-Permite el acceso del
administrador.
POST CONDICIONES El administrador ingresa a sus
respectivas funciones.
 35

CASO ALTERNO:
Datos incorrectos o no vá lidos
El sistema en el punto 6 arroja un mensaje “Su usuario y contraseñ a no
coinciden” y retoma el punto 5. Registrar usuario.

CASO DE USO DE ADMINISTRADOR.

CASO DE USO 9 Visualizar pedidos.

ACTORES Administrador.
DESCRIPCIÓ N Visualizar los pedidos que los
clientes registrados han realizado en el
 36

sistema, muestra el estado del pedido,

la fecha del pedido y los datos del
cliente que compro el artículo.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber iniciado
sesió n correctamente e ingresar al
ítem de pedidos en el menú principal
del sistema.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa Nombre y contraseñ a 2.-Verifica datos del administrador.
3-Permite el acceso del
administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítems de 6.-Arroja varios ítems como
administració n en el menú principal. Proveedor, Productos, Categorías,
Usuarios y Pedidos.
7.-Selecciona “Pedidos”. 8.-Muestra tabla de datos de
pedidos realizados.
POST CONDICIONES El administrador visualiza todos los
pedidos realizados por los clientes.

CASO ALTERNO:
Pedidos no realizados.
Falta de informació n, arroja mensaje “no se ha realizado ningú n pedido”.

CASO DE USO 9.1 Reporte de pedidos.

ACTORES Administrador
DESCRIPCIÓ N Permite generar un reporte para
después ser enviado al cliente, para
verificar el pedido.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber iniciado
sesió n correctamente e ingresar al
ítem de pedidos en el menú principal
del sistema.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa ID y contraseñ a. 2.-Verifica datos del administrador.
3-Permite el acceso del
 37

administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítem “administració n” 6.-Arroja varios ítems como
en el menú principal. Proveedor, Productos, Categorías,
Usuarios y Pedidos.
7.-Click en la opció n “Pedidos”. 8.-Muestra reporte con la
descripció n del pedido, cantidad,
valores subtotal y valores total del
pedido y datos del cliente.
9.-clic “Imprimir reporte”. 10.-Imprime el reporte.
POST CONDICIONES Se genera reporte del pedido.

CASO ALTERNO:

CASO DE USO DE ADMINISTRADOR.

CASO DE USO 10 Administrar usuarios.

ACTORES Administrador.
 38

DESCRIPCIÓ N Este caso de uso le permite al

administrador le permite crear nuevos
administradores o eliminar existentes.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber iniciado
sesió n correctamente.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa nombre, contraseñ a y 2.-Verifica datos del administrador.
tipo de usuario. Clic “iniciar sesió n”
3-Permite el acceso del
administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítem “administració n” 6.-Arroja varios ítems como
en el menú principal. Proveedor, Productos, Categorías,
Administració n, Usuarios y Pedidos.
7.-Seleccionar “Usuarios”. 8.-Muestra datos de los
administradores registrados.

POST CONDICIONES Visualizar administradores

registrados

CASO ALTERNO:

CASO DE USO 10.1 Agregar usuario.

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso le permite al
administrador agregar nuevos
usuarios al sistema.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber iniciado
sesió n.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa nombre, contraseñ a y 2.-Verifica datos del administrador.
tipo de usuario.
3-Permite el acceso del
administrador.
 39

4.-Muestra funciones del

administrador.
5.-Selecciona ítems “administració n” 6.-Arroja varios ítems como
en el menú principal. Proveedor, Productos, Categorías,
Usuarios y Pedidos.
7.-Clic “Usuarios”. 8.-Muestra formulario
9.-Ingresa datos nombre y
contraseñ a.
10.-Selecciona botó n agregar. 10.-Registra administrador nuevo
11.-Muestra tabla actualizada.
POST CONDICIONES Muestra los usuarios registrados en
el sistema.

CASO ALTERNO:
Datos no vá lidos.
En el punto 11 si el administrador no llena los campos requeridos, el sistema
le muestra que campo le hace falta llenar.

CASO DE USO 10.2 Eliminar usuarios.

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso le permite al
administrador eliminar usuarios en el
sistema.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber
administrador existente.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa Nombre, contraseñ a y 2.-Verifica datos del administrador.
tipo de usuarios.
3-Permite el acceso del
administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítems “administració n” 6.-Arroja varios ítems como
en el menú principal. Proveedor, Productos, Categorías,
Usuarios y Pedidos.
7.-Clic “Usuarios”. 8.-Muestra ventana para ingresar
nombre de administrador.
9.-Ingresa o selecciona nombre
 40

10.-Selecciona botó n “eliminar” 11.-Elimina usuario existente.

12.-Muestra tabla de usuario
actualizada.
POST CONDICIONES Muestra los usuarios registrados en
el sistema.

CASO ALTERNO:

CASO DE USO DE ADMINISTRADOR

CASO DE USO 11 Administrar Productos.

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso le permite al
administrador le permite visualizar e
ingresar productos o eliminar
existentes.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber iniciado
sesió n correctamente.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa Nombre, contraseñ a y 2.-Verifica datos del administrador.
tipo de usuarios.
 41

3-Permite el acceso del

administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítem “administració n” 6.-Arroja varios ítems como
en el menú principal. Proveedor, Productos, Categorías,
Usuarios y Pedidos.
7.-Seleccionar “Productos”. 8.-Muestra datos de los productos
registrados.

POST CONDICIONES Visualizar productos registrados

CASO ALTERNO:

CASO DE USO 11.1 Agregar producto.

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso le permite al
administrador agregar productos al
sistema.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber iniciado
sesió n.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa Nombre, contraseñ a y 2.-Verifica datos del administrador.
tipo de usuarios.
3-Permite el acceso del
administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítems “administració n” 6.-Arroja varios ítems como
en el menú principal. Proveedor, Productos, Categorías,
Usuarios y Pedidos.
7.-Clic “Productos”. 8.-Despliega ventana con formulario
9.-Ingresa datos como nombre,
 42

precio, cantidad disponible”.

10.-Selecciona botó n “agregar” 11.-Registra producto.
12.-Muestra tabla actualizad de
productos.

POST CONDICIONES Muestra los productos registrados

en el sistema.

CASO ALTERNO:
Datos no vá lidos.
En el punto 11 si el administrador no llena los campos requeridos, el sistema
le muestra que campo le hace falta llenar.

CASO DE USO 11.2 Eliminar productos.

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso le permite al
administrador eliminar productos en
el sistema que no tengan disponibles.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber
productos registrados.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa Nombre, contraseñ a y 2.-Verifica datos del administrador.
tipo de usuarios.
3-Permite el acceso del
administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítems “administració n” 6.-Arroja varios ítems como
en el menú principal. Proveedor, Productos, Categorías,
Usuarios y Pedidos.
 43

7.-Clic “Productos”. 8.-Muestra ventana para ingresar

nombre del producto
9.-Ingresa o busca nombre de
producto.
10.-Selecciona botó n “eliminar” 11.-Elimina producto existente.
12.-Muestra tabla actualizada de
productos registrados.
POST CONDICIONES Muestra los productos registrados
en el sistema.

CASO ALTERNO:
 44

CASO DE USO DE ADMINISTRADOR

CASO DE USO 12 Administrar Categoría.

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso le permite al
administrador le permite visualizar e
ingresar categoría de productos o
eliminar existentes.
PRECONDICIONES El administrador tiene que estar
 45

registrado en el sistema, haber iniciado

sesió n correctamente.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa nombre, contraseñ a y 2.-Verifica datos del administrador.
tipo de usuario.
3-Permite el acceso del
administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítem “administració n” 6.-Arroja varios ítems como
en el menú principal. Proveedor, Productos, Categorías,
Usuarios y Pedidos.
7.-Seleccionar “Categoría”. 8.-Muestra datos de las categorías
de los productos registrados.

POST CONDICIONES Visualizar productos registrados

CASO ALTERNO:

CASO DE USO 12.1 Agregar categoría.

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso le permite al
administrador agregar categorías de
los productos al sistema.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber iniciado
sesió n.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa nombre, contraseñ a y 2.-Verifica datos del administrador.
tipo de usuario.
3-Permite el acceso del
administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítems “administració n” 6.-Arroja varios ítems como
 46

en el menú principal. Proveedor, Productos, Categorías,

Usuarios y Pedidos.
7.-Clic “Categorías”. 8.-Muestra tabla con formulario.
9.-Ingresa datos de la categoría
11.-Selecciona botó n “agregar” 12.-Registra categoría del producto.
13.-Muestra tabla actualizad de las
categorías.
POST CONDICIONES Muestra las categorías de los
productos registrados en el sistema.

CASO ALTERNO:
Datos no vá lidos.
En el punto 11 si el administrador no llena los campos requeridos, el sistema
le muestra que campo le hace falta llenar.

CASO DE USO 12.2 Eliminar categoría.

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso le permite al
administrador eliminar categoría de
productos en el sistema.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber
categoría existente.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa Nombre, contraseñ a y 2.-Verifica datos del administrador.
tipo de usuario.
3-Permite el acceso del
administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítems “administració n” 6.-Arroja varios ítems como
en el menú principal. Proveedor, Productos, Categorías,
Usuarios y Pedidos.
7.-Clic “Categoría”. 8.-Muestra tabla para ingresar
nombre de categoría.
9.-Ingresa o busca nombre de
categoría.
10.- Selecciona “eliminar” 11.-Elimina categoría existente
12.-Muestra tabla actualizada de las
 47

categorías.
POST CONDICIONES Muestra las categorías de los
productos registrados en el sistema.

CASO ALTERNO:

CASO DE USO DE ADMINISTRADOR

CASO DE USO 13 Administrar Proveedor.

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso le permite al
administrador le permite visualizar e
ingresar proveedores de productos o
eliminar existentes.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber iniciado
sesió n correctamente.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
 48

1.-Ingresa nombre, contraseñ a y 2.-Verifica datos del administrador.

tipo de usuario.
3-Permite el acceso del
administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítem “administració n” 6.-Arroja varios ítems como
en el menú principal. Proveedor, Productos, Categorías,
Usuarios y Pedidos.
7.-Seleccionar “Proveedores”. 8.-Muestra datos de los proveedores
de los productos registrados.

POST CONDICIONES Visualizar proveedores de

productos registrados.

CASO ALTERNO:

CASO DE USO 13.1 Agregar Proveedor.

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso le permite al
administrador agregar proveedores de
los productos al sistema.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber iniciado
sesió n.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa nombre, contraseñ a y 2.-Verifica datos del administrador.
tipo de usuario.
3-Permite el acceso del
administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítems “administració n” 6.-Arroja varios ítems como
en el menú principal. Proveedor, Productos, Categorías,
Usuarios y Pedidos.
7.-Clic “Proveedor”. 8.-Despliega ventana con
 49

formulario.
9.-Ingresa datos del proveedor.
10.-Selecciona “agregar”. 11.-Registra proveedor del
producto.
12.-Muestra tabla actualizada del
proveedor.

POST CONDICIONES Muestra los proveedores de los

productos registrados en el sistema.

CASO ALTERNO:
Datos no vá lidos.
En el punto 11 si el administrador no llena los campos requeridos, el sistema
le muestra que campo le hace falta llenar.

CASO DE USO 13.2 Eliminar proveedor.

ACTORES Administrador.
DESCRIPCIÓ N Este caso de uso le permite al
administrador eliminar proveedor de
productos en el sistema.
PRECONDICIONES El administrador tiene que estar
registrado en el sistema, haber iniciado
sesió n correctamente.
CURSO NORMAL DE EVENTOS
ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA
1.-Ingresa Nombre, contraseñ a y 2.-Verifica datos del administrador.
tipo de usuario.
3-Permite el acceso del
administrador.
4.-Muestra funciones del
administrador.
5.-Selecciona ítems “administració n” 6.-Arroja varios ítems como
en el menú principal. Proveedor, Productos, Categorías,
Usuarios y Pedidos.
7.-Clic “Proveedor”. 8.-Muestra ventana para ingresar o
buscar nombre del proveedor.
9.-Ingresa o busca nombre del
proveedor
10.-Selecciona “eliminar”. 10.-Elimina proveedor existente.
11.-Muestra tabla actualizada de los
 50

proveedores.
POST CONDICIONES Muestra los proveedores de los
productos registrados en el sistema.

CASO ALTERNO:

[Link].-REQUERIMIENTOS FUNCIONALES

Los requisitos funcionales para el sistema de ventas por internet están contemplados en

función a los tipos de usuarios que tendrá el sistema: usuario cliente, usuario cliente registrado

y administrador.

Para ello se necesitará los siguientes requerimientos funcionales:

CC
CODIGO DESCRIPCIÓ N
RF1 El sistema web debe permitir navegar por la tienda virtual.
RF2 El sistema web debe permitir iniciar sesió n a diferentes tipos de
usuarios.
RF3 El sistema web debe permitir añ adir productos al carrito
RF4 El sistema web debe permitir vaciar productos del carrito.
RF5 El sistema web debe permitir registro de usuarios.
RF6 El sistema web debe permitir registro de productos.
RF7 El sistema web debe permitir registro de categorías.
RF8 El sistema web debe permitir registrar pedido.
RF9 El sistema web debe permitir gestionar usuarios.
RF10 El sistema web debe permitir gestionar productos.
RF11 El sistema web debe permitir gestionar categoría.
RF12 El sistema web debe permitir generar reporte de pedido.
RF13 El sistema web debe permitir enviar reporte de pedido.

[Link].-REQUERIMIENTOS NO FUNCIONALES
 51

CC
CODIGO DESCRIPCIÓ N
RF1 El sistema web debe tener una interfaz fá cil de entender, diseñ o
acorde y fá cil interacció n con el usuario.
RF2 El sistema web debe ser eficiente, toda respuesta al usuarios es
menos de 5 segundos, operar con 10 000 usuarios.
RF3 El sistema web debe contar un acceso de 24/7
RF4 El sistema web debe proporcionar mensajes de error que sean
informativos y orientados al usuario final.

[Link].-DIAGRAMAS

[Link].I.-Diagramas de Secuencias.
 52

Diagrama de secuencia navegar página web. Cliente y Cliente Registrado.

Fuente: Los alumnos

 53

Diagrama de secuencia gestionar carrito. Cliente y Cliente Registrado.

Diagrama de secuencia visualizar productos disponibles. Cliente y Cliente Registrado

 54

Fuente: Los alumnos

Diagrama de secuencia iniciar sesión. Cliente Registrado.

Fuente: Los alumnos

Diagrama de secuencia registrar. Cliente Registrado.

 55

Fuente: Los alumnos

Diagrama de secuencia iniciar sesión. Administrador.

Fuente: Los alumnos

Diagrama de secuencia Visualizar pedidos. Administrador.

 56

Fuente: Los alumnos

Diagrama de secuencia Registrar usuarios. Administrador.

Fuente: Los alumnos

Diagrama de secuencia Eliminar Usuario. Administrador

 57

Fuente: Los alumnos

Diagrama de secuencia Registrar Productos. Administrador.

Fuente: Los alumnos

Diagrama de secuencia Eliminar Producto. Administrador.
 58

Fuente: Los alumnos

Diagrama de secuencia Registrar Categoría. Administrador

Fuente: Los alumnos

Diagrama de secuencia Eliminar Categoría. Administrador.
 59

Fuente: Los alumnos

Diagrama de secuencia Registrar Proveedores. Administrador

Fuente: Los alumnos

Diagrama de secuencia Eliminar Proveedor. Administrador
 60

Fuente: Los alumnos

[Link].-Diagrama de actividades
 61

Iniciar Sesión. * admin: cuenta

Registrar usuario
 62

Añadir carrito
 63

Realizar pedido
 64

Gestionar Administrador
 65

Gestionar Productos
 66

Gestionar Categoría
 67

Gestionar Proveedor
 68

[Link].-Diagrama de clases
69
 70

[Link].-Diagrama de la base de datos

[Link].V.-Diagrama de despliegue
 71

[Link].-MOCKUPS
 72

Cliente y Cliente registrado.

Ilustración 1: Prototipo interfaz-Pantalla principal

Ilustración 2: Prototipo interfaz-Ítem Product

 73

Ilustración 3: Prototipo interfaz-Detalle Producto.

Ilustración 4: Prototipo interfaz-Ítem Iniciar Sesión

 74

Ilustración 5: Prototipo interfaz-Gestionar carrito

Ilustración 6: Prototipo interfaz-Solicitud de datos

 75

Ilustración 7: Prototipo interfaz-Registro de Cliente.

Ilustración 8: Prototipo interfaz-Registro de pago.

 76

ADMINISTRADOR

Ilustración 9: Prototipo interfaz-Gestión de Productos

 77

Ilustración 10: Prototipo interfaz-Actualización de datos de productos.

Ilustración 11: Prototipo interfaz-Gestión de proveedor.

 78

Ilustración 12: Prototipo interfaz-Actualización de datos del proveedor.

 79

Ilustración 13: Prototipo interfaz-Gestión de categorías.

 80

Ilustración 14: Prototipo interfaz-Actualización de datos de categorías.

 81

Ilustración 15: Prototipo interfaz-Gestión de usuarios.

Ilustración 16: Prototipo interfaz-Eliminar pedidos.

 82

V.-CONCLUSIONES

La Metodología RUP es completa y extensa que intenta abarcar todo el mundo del

desarrollo software, tanto para pequeños proyectos, como proyectos más ambiciosos de varios

años de duración. Por lo que existe una gran cantidad de documentación sobre el mismo, tanto

en libros como en la red, eso sí en inglés. Es sin embargo difícil empezar a aplicar esta

metodología en una organización. Por eso esperamos que este documento sirva tanto para

familiarizar con el Proceso Unificado a aquellos que no lo conocían, así como de servir de

guía durante la ejecución del mismo.

VI.-RECOMENDACIONES

Para contar con un enfoque disciplinado en la asignación de tareas y responsabilidades

dentro de una organización de desarrollo, es necesaria la aplicación de una metodología, con

la cual se puede mantener una fácil administración de este proceso; como por ejemplo de la

metodología RUP.

Para obtener un máximo control de variables que conlleva un desarrollo de aplicaciones y

poder mantener una ordenada implementación de estas, es importante seguir metodologías y

estándares que nos lleven a estar en competitividad en todo momento

 83

VII.-REFERENCIAS BIBLIOGRÁFICAS

(RUP), R. U. (s.f.). Rational Unified Process (RUP). Obtenido de

[Link]
El Proceso Unificado de Rational . (25 de mayo de 2018). Obtenido de entrada de blog:
[Link]
GrupNADD. (Julio de 2012). METODOLOGIA RUP. Obtenido de entrada de blog:
[Link]
Lopez Rosciano, R. A., & Pech Montejo, J. A. (Julio 2015). Desarrollo de herramienta de
gestion de proyectos RUP usando metodologia SCRUMP + XP : Pruebas.
metodolorup. (23 de 10 de 2017). Obtenido de Metodologia rup:
[Link]
RUP, M. (23 de 10 de 2017). METODOLOGÍA RUP. Obtenido de
[Link]
RUP, M. d. (24 de 3 de 2014). Fases Metodologia RUP. Obtenido de Metodologia desarrollo
software - RUP: [Link]
[Link]
Software, B. I. (27 de 11 de 2012). Metodologia de Software. Obtenido de Blog Ingeniería en
Software: [Link]
rup_27.html
Software: ventajas de la metodologia de diseño RUP. (12 de octubre de 2016). Obtenido de
entrada de blog: [Link]
metodologia-de-diseno-rup/
TechLib. (s.f.). Obtenido de TechLib: [Link]
Torrosi, G. (s.f.). El Proceso Unificado de Desarrollo de Software.
Universidad Autónoma de Baja California. (1998). Metodología RUP.
Universidad Autónoma de Baja California. (23 de 02 de 2015). Metodología RUP. Obtenido de
Universidad Autónoma de Baja California:
[Link]
Universidad de San Carlos de Guatemala. (marzo de 2006). Julio César. Obtenido de
[Link]